the index hole in the wrong place). Sector header record GCR is solved,
probably; data record GCR is partially solved, although kinda weird (should
check that my pulse train decoder isn't dropping bits).
then we read the pulsetrain into nice tidy bits with a proper clock, which
makes the decoder's job way easier. We can actually get rid of the entire MFM
decoder state machine. Also, after sorting out the magic bit patterns at the
beginning of records, we can now reliably pull them out of the bitstream
without needing to know anything about the records themselves.
big to time; so, redesign it. Now the longest transition is 0xfe ticks and a
pulse is inserted if it's too long. Capture is way more robust now and the
resulting pulsetrain is a solid 198ms; and I wrote my first readable disk! (A
PC HD disk. Sadly, writing to the Brother didn't work.)
this makes the hardware considerably simpler and more reliable (as I don't need
to spend time resetting the timers between pulses). Still doesn't help writes,
though. Simplify and improve clock detection; add an abortive attempt at an FM
decoder (turns out that the Brother doesn't use FM).
convert a fluxmap into an encoding_buffer, but locking each pulse to a us grid.
I'm not sure whether this is good enough for reliable decoding, but early
indications look promising.
board... so remove it. Better now. Also realise that PSoC Creator lies to you
about clocks, so adjust the sample clock to be derivable from the USB clock,
making it both the right frequency and much more accurate --- decode success is
dramatically improved (presumably due to less jitter). Redesign the capture
logic to use a timer; simpler now.
samples are more than 128 ticks apart! Doubled the settling time to make reads
more reliable; added disk change logic to rehome the disk when you replace
floppies.
what they are and how big they are. After lots of tinkering with the clock
code, it now correctly decodes a 720kB floppy into records. Something seems to
have gone wrong with 1.44MB floppy capture, though.
search for the sync region before each record and recalculate the clock from
that. Unfortunately, knowing when I've reached the end of a record and so
should start resyncing is hard without parsing the records themselves, and so I
frequently lose byte phase between records.
disk. Something's wrong with the DMA; requesting a transfer every 2us with a TD
size of 64 bytes is somehow leading to an nrq interrupt every 8us. Mysterious.
on Windows because libusb can't talk to any device without a signed driver.
Stupid Windows.
Luckily I can get 500+kB/s out of CDC, even on Windows, so let's use that.
