#445 "Used bits in last byte" takes the LSB in raw data blocks

[Alberto Garcia]

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).

[Alberto Garcia]

Here's the patch.

[Alberto Garcia]

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.

[Sergio Baldoví]

I'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.

[Fredrick Meunier]

Thanks, added with regression test case.