#431 MASK does not load at all

[Philip Kendall]

MASK does not load at all, not matter what options and manual starting/stopping of the tape I try. This applies to both the TZX available on World of Spectrum (sha256 9ae1017e5999d9b773d106a0bb623ee0057833475bfc567236d5a9a46c90e8b8) and the "v1.20" TZX available from the TZX Vault (sha256 e522f544f2d5330c42ebb9557d51b1aa0b29254570f0279883c0b77725bc43b4 - perhaps significantly, this turns out not to be a v1.20 TZX file at all!)

See also bug 23 - not sure if we ever saw a working version of MASK then.

[Fredrick Meunier]

We didn't see a working version of MASK then - I just assumed that we would see a TZX that forced the correct polarity be released once it was possible.

[Nicholas Naime]

Oddly enough, if you open TZX in Tapir and then feed the audio into a real machine, it won't load either. However, I managed to load the TZX in zxsp (an older emulator for macOS) and it worked fine. I then recorded the audio generated by zxsp to a WAV file and fed it directly to Fuse. It loaded every time.

Attaching the "good" WAV.

[Nicholas Naime]

Right, so I manually changed the polatiry in the offending data blocks to 10b (i.e. force low level), and the game loads fine now.

[Nicholas Naime]

Addendum. I just tested MASK on real hardware and got mixed results. Neither version loads. However, the +2A, sometimes starts loading the loading screen, which then gets corrupted about 1/3 of the way in (sometimes earlier, sometimes later), and then the machine resets when the block finishes loading. Sometimes the machine resets right away as soon as the block begins to load.

The 128K (Toastrack) simply doesn't see the data, and continues to treat it all as a pilot tone. It neither loads anything, nor does it reset.

Tested with all of the above files.

Another contender is Lone Wolf III. In Fuse, you can coax it to load by repeatedly reloading the offending blocks. It takes a gazillion tries (and the loader, although self-recovering, isn't very cooperative, so you have to improvise), but it gets there in the end.

On real hardware, I can get most blocks to load most of the time on my Toastrack and none on the +2A. Go figure.

I could open a separate ticket for Lone Wolf III, but these two might be related.

P.S. What do you know? I decided to retry Lone Wolf III on the Toastrack, and it loaded right away—no retries. (I guess the machine had warmed up.)

[Luis Faria]

Nicholas, there is a similar ticket for Lone Wolf III, already: bug 352

[Nicholas Naime]

I see it now. Thanks!

[Alberto Garcia]

Hi,

Lone Wolf's loader is sensitive to the tape signal level, if you set the level to low before each turbo block then it loads perfectly fine.

I attached a script to [bugs:#352] that can do that to a TZX file.

The interesting thing with MASK is that if I set the level to low (either with my script or with your modified TZX) then it loads fine in 128K mode but fails in 48K mode.

However if you set the level to high then it loads fine in 48K mode but fails in 128K mode.

Other emulators (I tried ZEsarUX and RetroVirtualMachine) can load the original unmodified TZX file in both modes.

[Alberto Garcia]

The interesting thing with MASK is that if I set the level to low (either with my script or with your modified TZX) then it loads fine in 128K mode but fails in 48K mode.

Update: I can load my modified TZX in 48K mode if I use --no-issue2. With your modified TZX I can get the loading screen but then it crashes halfway the loading process.

[Nicholas Naime]

Lone Wolf's loader is sensitive to the tape signal level, if you set the level to low before each turbo block then it loads perfectly fine.

You mean it loads fine in an emulator or on real hardware? I'm going to try your method of lowering the level on both of my Spectrums and see what happens. (Alas, I don't have an Issue 2 48K Speccy—only a Toastrack and a +2A.)

[Alberto Garcia]

You mean it loads fine in an emulator or on real hardware?

I meant in an emulator, I don't have real hardware here to try.

In the turbo blocks immediately after the pilot tone there's two sync pulses, the first one longer than the second, you can see that if you convert the tzx to wav. The first pulse must be low for the game to load. PlayTZX generates the correct polarity, Fuse's tape2wav doesn't (unless you apply the patch that I posted on this bug).

About the Issue 2 Speccy, maybe I didn't explain myself correctly: at least in the emulator if you use a 48K Issue 2 the game won't load, I can load it only with later models (which makes sense, the game is from 1991 after all).

[Nicholas Naime]

I can see that the first sync pulse is longer in Tapir as well, and it generates a wave file with the correct polarity. The file still wouldn't load properly on real hardware, though. I just don't see how PlayTZX can generate a different wave file, as there doesn't seem to be anything in the TZX specs to define the plarity of sync pulses. General data bit pulses—yes, but not the sync pulses. So, how does it know to do that?

Also, just so we're on the same page, by low level, do you mean that the signal goes high after that?

pilot ends   second sync
         |   |
         v   v
    ------  --- --
    |    |  | | |
----     ---- ---
          ^
          |
 first sync

[Alberto Garcia]

Also, just so we're on the same page, by low level, do you mean that the signal goes hight after that?

Yes, I mean that. I'm attaching the screenshots of the sync pulses of the first turbo block as generated by Tapir, PlayTZX and Fuse (tape2wav).

I tried with Fuse and ZEsarUX and the results are the same: the wav created by Fuse doesn't work at all, the one created by PlayTZX works perfectly. The one created by Tapir is a bit more irregular and works for a while but then some blocks are not detected properly.

This is by the way the experience that I remember from loading the original game from tape, I had to rewind some blocks occassionally because it wasn't completely reliable.

[Nicholas Naime]

Oh, now I get it. So, I've been experimenting with the correctly generate wave file, then. That, couple with this:

This is by the way the experience that I remember from loading the original game from tape, I had to rewind some blocks occasionally because it wasn't completely reliable.

makes me think I know what's going one with Lone Wolf.

I think its loader is just extremely sensitive to pulse timings. I manually normalized the timings of all the blocks in Tapir and was able to load it on the Toastrack with near 100% reliability. I had to reload an occasional block or two, but that was it. Mind that I couldn't load it on a +2A, which is strange for a 1990 game.

Here's what I think is the culprit.

1. Port 254 in 48 and 128K machines is contended. Even more so, if the high byte is within the $40–7F range.
2. On the +2A it's not contended (at least when the high byte is out of that range).

This, in turn, presents several problems:

1. The port sampling loop in a loader will execute at different speeds on different machines and the loop counter will return different values, even if the period between pulses is exactly the same.
2. Emulators will internally generate pulses from TZX files based on the CPU clock frequency of the currently selected machine.
3. Tapir, PlayTZX, and even tape2wav I think will always generate wave files based on the CPU clock of 3.5 MHz, i.e. assuming it's a 48K machine, so the pulses will be a little longer.

There used to be an iOS app called Speccy Tape, which had an option to play back TZX/TAP files at 3.5469 MHz. Unfortunately, the app stopped working after Apple pulled the plug on 32-bit apps and the author never updated it.

To make the game load from the TZX, it simply needs to have the pulse lengths adjusted to work with 128K timings.

Now, the phase inversion of Fuse/tape2wav is a separate issue and certainly needs to be addressed, but it won't fix Lone Wolf in and of itself. It seems to be inheretantly broken.

[Alberto Garcia]

I manually normalized the timings of all the blocks in Tapir and was able to load it on the Toastrack with near 100% reliability. I had to reload an occasional block or two, but that was it. Mind that I couldn't load it on a +2A, which is strange for a 1990 game.

I had my original tape in a +2A, fwiw (it was the Spanish release but it was identical to the English one from what I can remember, although I didn't compare the TZX files).

Here's what I think is the culprit.

1. Port 254 in 48 and 128K machines is contended. Even more so, if the high byte is within the $40–7F range.
2. On the +2A it's not contended (at least when the high byte is out of that range).

I can confirm that with the patched Fuse there are differences between those models as well. In my case the +2A loads the game from start to end without problems, and with the 128K I need to occasionally rewind some blocks. So I suspected that port contention had something to do with it.

(I would also expect that the game was originally developed and tested for a +2A, which was the available model at the time)

Tapir, PlayTZX, and even tape2wav I think will always generate wave files based on the CPU clock of 3.5 MHz, i.e. assuming it's a 48K machine, so the pulses will be a little longer.

I confirm that Fuse uses 3.5 MHz for this. Moreover, the TZX spec says that The ZXTape format has ALL timings written according to a 3.5MHz clock [...] so if the tape should be used on an Amstrad CPC with 4MHz clock then you should multiply ALL timings [...].

And Lone Wolf in particular has separate 48K and 128K versions on each side of the tape, but I don't know if the loaders are adjusted to their respective clock differences (I can load the 48K version on the emulator without problems fwiw).

To make the game load from the TZX, it simply needs to have the pulse lengths adjusted to work with 128K timings.

That would make sense. I wonder if it's worth having an option to do that or if Lone Wolf is the only case where this is important.

[Nicholas Naime]

That would make sense. I wonder if it's worth having an option to do that or if Lone Wolf is the only case where this is important.

Did some more experiments today with my turbo loader. I made several audio recording from my original TZX and compared them. Looks like aside from Tapir, few other methods can produce an audio file that is equivalent to it. I'm attaching my original TZX and a screenshot demonstrating how each audio file lines up at the end of the recording (all files are aligned from the start). The files are as follows:

—AL3 Fuse TZX audio 48K: audio recorded as Fuse generated it while loading from the TZX file on an emulated Spectrum 48K
—AL3 Tapir: audio generated by Tapir from the same TZX
—AL3 zxsp TZX audio 48K: audio recorded from zxsp (a Spectrum emulator for Mac OS), while loading it from the TZX file on an emulated Spectrum 48K
—AL3 zxsp TZX audio +2A: audio recorded from zxsp, while loading it from the TZX file on an emulated Spectrum +2A
—AL3 zxsp TZX audio 128K: audio recorded from zxsp, while loading it from the TZX file on an emulated Spectrum 128K
—AL3 Fuse Util (tape2wav): audio generated by the tape2wav tool from the Fuse Utilities package
—AL3 winTZX: audio generated by winTZX v0.9a
—AL3 Fuse TZX audio +2A: audio recorded as Fuse generated it while loading from the TZX file on an emulated Spectrum +2A
—AL3 Fuse TZX audio 128K: audio recorded as Fuse generated it while loading from the TZX file on an emulated Spectrum 128K
—Fuse 48K from Tapir WAV: audio recorded as Fuse generated it while loading from the WAV file generated by Tapir from the TZX file on an emulated Spectrum 48K
—Fuse +2A from Tapir WAV: audio recorded as Fuse generated it while loading from the WAV file generated by Tapir from the TZX file on an emulated Spectrum +2A
—Fuse 128K from Tapir WAV: audio recorded as Fuse generated it while loading from the WAV file generated by Tapir from the TZX file on an emulated Spectrum 128K

As you can see, tape2wav produces audio that is by far the outlier here. It is much longer than what is generated by Tapir, which in turn, for all intents and purposes is identical to what Fuse actually plays back while loading the TZX on an emulated 48K machine, and what zxsp generates for all machines.

What is even more disconcerting is that when Fuse reads pulses from an audio file, it—as I suspected earlier—times them (albeit not very accurately) to the CPU clock of the selected machine. Note, however, that even on a 48K Spectrum, the timing is not quite right.

When reading TZXs, Fuse will also not adjust the timings appropriately and will default them to the current clock speed.

I believe, at least when dealing with TZX/TAP files, Fuse should offer an option to recalculate the periods between pulses based on the CPU clock of the currently running machine. For reading audio files, however, this should simply be the only option, otherwise it kind of defeats its own purpose. Moreover, it makes it virtually impossible to develop custom loaders, as there's currently absolutely no way of making Fuse load TZX files with correcting timing on anything other than the 48K Spectrum.

The second part of the post is something that I'm sure you've already found a solution to, but it might be helpful.

Now, my loader is unusual in that it only looks for a single edge, rather than the usual two. However, it's still polarity-ambivalent.

I used the three audio files generated from my TZX and tested them in Fuse and on real hardware. Here are the results:

—Fuse will skip the last bit of the audio generated by winTZX, but will load it if I invert the phase of the audio.
—Fuse will load the audio generated by tape2wav, but will fail if I invert the phase of the audio.
—Fuse will load the audio generated by Tapir with either polarity.
—All files will load on real hardware with either polarity.

I don't have PlayTZX (the latest Windows version I found did not play ball with Generalized Data TZX blocks), so I can't say anything about how accurately it works, but as for the other tools, it seems Tapir is the only one that faithfully reproduces all the timings.

P.S. I recorded an audio of my saving a standard screen file from a real +2A and converted it to TZX via audio2tape. It failed to add a proper pause between the header and the data block, but correctly recognized the pulse lengths:

Pilot pulse: 2139
Pilot length: 8060
Sync 1: 714
Sync 2: 675
Zero: 844
One: 1685

These do indeed differ from standard 48K timings by as much as the ratio between the clock speeds of 128K and 48K Spectrums, which makes sense.

[Alberto Garcia]

As you can see, tape2wav produces audio that is by far the outlier here. It is much longer than what is generated by Tapir

I don't understand that, I just tried with tape2wav and WinTZX and the results have very similar length and size on my computer ... (around 670 KB).

Fuse will skip the last bit of the audio generated by winTZX, but will load it if I invert the phase of the audio.

I confirm that this is the same as [bugs:#369] and the patch that I posted there on the 11th of January solves the problem and allows Fuse to load this file.

The rest of your comment contains very useful information, I'd like to give it a closer look when I have more time, although first I want to fix once and for all the TZX polarity problem tat is preventing us from loading MASK, Lone Wolf and friends.

[Nicholas Naime]

I just tried with tape2wav and WinTZX and the results have very similar length and size on my computer ... (around 670 KB).

Odd, indeed. In this instance, both are incorrect results. These are much shorter than they should be, which is about 724 KB.

On a related note, I just tried the version of Lone Wolf III posted by Sergio in https://sourceforge.net/p/fuse-emulator/bugs/352/#d9df, and was finally able to load it on my +2A. Here's what I did:

1. Converted the TZX to WAV in Tapir
2. Boosted the level by about 6 db

It now loads every time without errors.

Inverting polarity prevents the data from loading.

With Basil, I did something similar. I converted it to WAV in Tapir, then boosted the signal by 6 db and then I did invert the polarity. Now, for the first time, I was able to load it on my +2A.

Preliminary conclusions:

1. Some loaders are, indeed, polarity sensitive
2. Many are also extremely speed sensitive, so fixing how Fuse treats TZX files is also crucial (i.e. recalculate each to use the 3.5 MHz clock, rather than rely on the currently selected machine's clock)

It's also important to keep in mind, that most modern audio sources are designed to drive low impedance earphones and produce an output signal of an amplitude of around 1 V (1.5 V in the case of most Apple devices). Spectrums were designed to be used with older tape recorders, which could drive higher-impedance loads and produce signals of up to 5 V in amplitude. There's also a clamping diode on the ULA's EAR input, which makes sure that the incoming signal always stays positive, which further how the ULA determins the state of Bit 6 of Port 254. The shape and the amplitute of the input signal matters.

[Alberto Garcia]

Re-reading your comment I noticed something that I had overlooked before:

Emulators will internally generate pulses from TZX files based on the CPU clock frequency of the currently selected machine.

I can't talk about how other emulators work, but in the case of Fuse as far as I'm aware it simply asks libspectrum "how long until the next edge from the tape?" and libspectrum returns the number of tstates exactly as written on the TZX file regardless of the machine model.

[Alberto Garcia]

I just don't see how PlayTZX can generate a different wave file, as there doesn't seem to be anything in the TZX specs to define the plarity of sync pulses.

The spec says:

"An emulator should put the 'current pulse level' to 'low' when starting to play a TZX file, either from the start or from a certain position"

and also

"At the end of a 'Pause' block the 'current pulse level' is low (note that the first pulse will therefore not immediately produce an edge)"

What I understand from this: in the Lone Wolf case the first turbo block has 2998 pilot pulses of 1436 tstates each. This means that when the pilot starts the signal is low, and after the first 1436 tstates it goes high for the second pulse. Since the pilot tone has an even number of pulses then immediately after it the level of the first sync pulse is necessarily low.

But this is not what Fuse is doing, it does not ensure that the pulse level is low after a pause (PlayTZX does that indeed). That's what the patch that I sent the other day does.

(for clarity I'm talking about Lone Wolf 3 - The Mirror Of Death.tzx from WoS, MD5 sum bab8428d8a90956f894dcb63c247f4f0)

P.S. to make things more complicated the spec also says "This document refers to 'high' and 'low' pulse levels. Whether this is implemented as ear=1 and ear=0 respectively or the other way around is not important, as long as it is done consistently.", so if we assume that high means "ear=0" then this would not work.

All the TZX files that I can load after my patch work with the assumption that high means ear=1, but there's no guarantee that all other TZX files do the same. So if we want to add this to Fuse we probably want an option to invert the polarity of tape signals. This way one should be able to load all games I suppose.

[Nicholas Naime]

if we assume that high means "ear=0" then this would not work.

I think this is machine-dependent. On the 48K/128K, both EAR and MIC signals of the ULA are linked together (well, it's just a single pin on 48K machines). On the +2 and +2A, they are separate pins and are not linked together directly. I was experimenting with updating my turbo loader recently, and discovered that depending on the state of MIC and EAR bits in a port write (along with the border change), I could make or break the loader on the Toastrack but not on the +2A. Fuse, however, would happily gobble up my loader in both cases. So it seems that Fuse got the MIC/EAR bits not quite right.

How exactly different machines implement the state of the output based on the state of the MIC/EAR bit, I don't know.

[Nicholas Naime]

All the TZX files that I can load after my patch work with the assumption that high means ear=1, but there's no guarantee that all other TZX files do the same.

This could be related (even though indirectly), but at least on the 48K/128K, when outputting to port 254, a 1 in the MIC bit means low. So, to have the output low, MIC (Bit 3) must be 1 and EAR (Bit 4) 0. This may or may not be true for the +2 and later, since, as I mentioned earlier, manipulating these bits produces different results on these machines, but not in Fuse.

[Alberto Garcia]

This could be related (even though indirectly), but at least on the 48K/128K, when outputting to port 254, a 1 in the MIC bit means low. So, to have the output low, MIC (Bit 3) must be 1 and EAR (Bit 4) 0.

Oh, I see, but what differences are you expecting to see in Fuse?

In the case of Fuse writing to port 254 changes the border color and the beeper, but the bits 3 and 4 are not used to produce any output (i.e. you cannot create a WAV file from what you write to that port).

As far as I can see those two bits are only used to change the value that you get when you read from that port, which differs between the 48K Issue 2 and all other models.

http://www.worldofspectrum.org/faq/reference/48kreference.htm#PortFE

[Nicholas Naime]

but the bits 3 and 4 are not used to produce any output

But they are. When I was experimenting with my loader, I accidentally incorrectly left bits 3 and 4 in a "wrong" state while outputting to Port 254. This resulted in Fuse outputting a louder volume during a load, but the load proceeded as normal.

I became curious and decided to do some test on real hardware. I couldn't get anything to load on the Toastrack (it just didn't see any valid signal and produced some crackling sounds), but the +2A loaded everything fine with no perceivable change in the tone volume.

The 48K Issue 2 quirk (which I'm well aware of), might have produced a third set of results with the same loader, but—as I mentioned earlier—I don't have that model at hand and cannot test my hypothesis.

I'll see if I can reproduce the mistake I made in my code, but it's clear that manipulating bits 3 and 4 produces results in Fuse that are different from the real hardware, and—which is a bit disconcerting—they are false positive results.

[Alberto Garcia]

you cannot create a WAV file from what you write to that port

Sorry what I wrote earlier is obviously not true, Fuse does indeed allow you to record the output to a file.

The code does use bits 3 and 4 to produce that sound, but it seems to be the same code for all machines.

[Alberto Garcia]

I became curious and decided to do some test on real hardware. I couldn't get anything to load on the Toastrack (it just didn't see any valid signal and produced some crackling sounds), but the +2A loaded everything fine with no perceivable change in the tone volume.

I have no idea about this thing, but a quick look at the reference manuals says that in the original models EAR and MIC are the same pin but separated with a resistor, and later ULAs had different configurations.