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.
The addition of the new tcsetattr call fixes a problem where interrupting
fluxengine during a flux read will leave data in the device and/or Linux's
serial buffers, so that the next invocation of fluxengine will fail similar
to
```
Error: command returned garbage (0x27 != 0x0 with status 0x31)
```
(the specific value differs because it's actually flux data)
Merely changing the existing tcsetattr call to specify TCSAFLUSH was not
enough; moving it after the 200ms pause seems to be enough.
Note that it doesn't seem feasible in our USB stack to make DTR reset
the device, since that would take down the USB stack and require a fresh
USB connection.
The addition of the special case for `rlen == 0` in read is for when the
GW-compatible board is reset or crashes and usb-disconnects during a
reading operation. Without this change, fluxengine spins forever at 100%
of a CPU, repeating a read(). After the change, this will cause
the host computer to print messages like:
```
2.1: 200 ms in 68928 bytes
3.0: Error: serial read returned no data (device removed?)
```
and exit.
I only tested these changes on Linux (Debian with kernel 5.10) and in
particular I don't know if/how it will work on a Mac.
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.
This prevents a crash when more tracks were recorded than fit in an
scp image. When I first encountered a problem doing an 84-track operation,
this led to a segfault later on since memory was written past the end
of _fileheader, and (I think) stomped on a pointer.
According to version 2.2 of the SCP image specification
<https://www.cbmstuff.com/downloads/scp/scp_image_specs.txt>
the number of Track Data Entries for a floppy can be up to 168,
so that up to 84 tracks can be recorded (e.g., fluxengine -c 0-83).
> BYTES 0x10-0x2AF (for floppy image files) are a table of longwords with each entry being
> an offset to a Track Data Header (TDH) for each track that is stored in the image. The table
> is always sequential. There is an entry for every track, with up to 168 entries supported for
> floppy disks. This means that floppy disk images of up to 84 tracks with sides 0/1 are possible.
This assumes a 360rpm drive, and double stepping.
If fluxengine supports the concept of 40 vs 80 track drives in the
future, it might make sense for this to assume a 300rpm drive
instead.
