This shell line creates a simple TZX with a raw data block containing two full pulses:
echo -ne "ZXTape!\x1A\x01\x10\x15\x1E\x02\x00\x00\x08\x02\x00\x00\xf0\xf0"
Each bit is 542 tstates, so with the data contained in the last two bytes (1111000011110000) here is the expected output when read with libspectrum:
tstates: 2168, flags: level_high
tstates: 2168, flags: level_low
tstates: 2168, flags: level_high
tstates: 2168, flags: level_low
tstates: 0, flags: end-of-block, stop, end-of-tape
Here's the actual output:
tstates: 542, flags: level_low
tstates: 2168, flags: level_high
tstates: 2168, flags: level_low
tstates: 2168, flags: level_high
tstates: 2168, flags: level_high
tstates: 0, flags: end-of-block, stop, end-of-tape
There's two problems here:
1) The last pulse has the wrong level.
2) There's a spurious pulse at the beginning.
Problem 1 is making Fuse fail to load WAVs created from the tapes saved by the emulator, and it is dealt with in [bugs:#369].
Problem 2 can cause load failures depending on where the raw data block is located on the tape.
This patch fixes the latter problem by correcting the initialization of raw data blocks.
Note: there's one more bug with raw data blocks, and it's how libspectrum handles the value of "Used bits in last byte". This patch does not make it better, so I reported [bugs:#445] to deal with it.
In that bug report there's a patch and also a test case that exposes all the problems that I've found with raw data blocks in libspectrum.
Related
Bugs:
#445I've tested this patch (isolated from the rest) with check_loaders (fuse-automation) and there isn't any variation with the expected results in 215 tapes. Doesn't seem to break anything.
Thanks Sergio. Even if this particular patch doesn't break any test, this one should be applied together with the one in [bugs:#445].
Related
Bugs:
#445Thanks. I meant isolated from [bugs:#431].
Related
Bugs: #431
Thanks Berto!