This shell line creates a simple TZX with a raw data block:
echo -ne "ZXTape!\x1A\x01\x10\x15\x0a\x00\x00\x00\x04\x03\x00\x00\xf0\xf0\xb0"
Here's the binary representation of the data (last 3 bytes):
11110000 11110000 10110000
Each bit is 10 tstates, so here's the expected output when read with libspectrum (note: the value of "Used bits in last byte" is 4):
tstates: 40, flags: level_high
tstates: 40, flags: level_low
tstates: 40, flags: level_high
tstates: 40, flags: level_low
tstates: 10, flags: level_high
tstates: 10, flags: level_low
tstates: 20, flags: level_high
tstates: 0, flags: end-of-block stop end-of-tape
Here's the actual output (note: after applying the fixes for [bugs:#369] and [bugs:#444]):
tstates: 40, flags: level_high
tstates: 40, flags: level_low
tstates: 40, flags: level_high
tstates: 80, flags: level_low
tstates: 0, flags: end-of-block stop end-of-tape
The problem is that the libspectrum_tape_raw_data_next_bit() code takes the least significant bits from the last byte (0000 in this case) instead of the most significant ones (1011).
Here's the patch.
This TZX file illustrates the problems described in [bugs:#369], [bugs:#444] and in this one.
It's a standard BASIC header (just the header), and it consists on 4 raw data blocks:
1) The pilot tone
2) The first sync pulse (the data block uses only 1 bit of data)
3) The second sync pulse (again, only 1 bit of data)
4) The header data
Fuse cannot load it because of the three bugs that I just mentioned, but with all of them fixed the output of libspectrum matches the exact data stored in the TZX file and it is loaded correctly by Fuse.
Related
Bugs:
#369Bugs:
#444I'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, added with regression test case.