I was writing "FF40" as "FF48": 1111 1111 0000 instead of 1111 1111 00.
This sequence of four zeros will not allow the real hardware to synchronize
to the bitstream.
With this change, I was able to boot a DOS 3.3 disk I rearranged into
"physical" order; some 'there's a disk error' raspberries occur (probably
indicating a data error within a sector) during the boot process, so
something is still obviously marginal, but this is a huge step forward.
`readRaw8` throws an exception if you run out of data. This did not
turn up during my testing, because I was reading back a disk written by
fluxengine, so everything was aligned to the index pulse and no sector
ever straddled a revolution. On a "real" apple2-written disk, this was
not the case.
Incidentally, the "extra 0" problem exists on a real apple2-written
floppy as well.
It's not OK to call seek() here. Instead, add a function which can read
an apple 8-bit flux value in terms of readRaw8 and readRawBits. Apply
this function to all the data bytes, rather than just the first one.
seekToPattern() can skip the index hole if it doesn't find the
SYNC pattern. If this happens too close to the end of the flux
stream, it can result in a conflicted sector. In this case,
discard the sector.
seekToPattern() can skip the index hole if it doesn't find the
SYNC pattern. If this happens too close to the end of the flux
stream, it can result in a conflicted sector. In this case,
discard the sector.
Vector MZOS uses a different sector checksum than the standard
Micropolis checksum used by MDOS, CP/M and OASIS. Automatically
detect the checksum on the disk by default, but allow the user
to force the use of a specific checksum using the
--decoder.micropolis.checksum_type parameter.
* Discard a partial sector at the end of the track.
* Do not seek to the index mark for the first sector.
* Use a 64-bit pattern to match the SYNC.
* If SYNC is found too early, search for a subsequent SYNC.
* While decoding the sector record, enforce the SYNC pattern
and track ID.
fluxmap. This requires resetting the FluxDecoder, which loses any pending
state, resulting in bad reads for (some) formats which don't have gaps between
sectors --- the DVK MX is the main victim.
