Further analysis of the MFM data. I have modified the PushBit code to pull out data bits and ignore clock bits once the sync marker has been found. The first 32 actual bits on mt first break point looks like this: 0xF012F010
According to RKRM: Devices page 572 after the sync words we should get:
one byte of format byte (Amiga 1.0 format = $FF)
one byte of track number
one byte of sector number
one byte of sectors until end of write (NOTE 1)
[above 4 bytes treated as one longword for purposes of MFM encoding]
So my data from above looks wrong. But reading further on page 573 is states that encoding is done in blocks. Odd bits are encoded first and then even bits.
Taking that into account 0xF012F010 converts to FF 00 03 08. This looks much more like it. FF = yes. 00 = yes we were on track 0. And lastly 3 + 8 = 11 sectors. It’s looking good… so let’s check the next breakpoint.
0xf001f023 is the next value which converts to FF 00 04 07. Excellent, sector number went up and number of tracks to write went down. We’re cooking on gas alright.
Taking all this odd/even encoding into account I suppose I’d better write a piece of code to decode it before I go any further. All this manual decoding is not good for the brain.
A strange thing occurred to me. Using my little PIC and some intelligent firmware it should be theoretically possible to read an entire Amiga disk and convert it to ADF just using the PC and the logic analyser. Hm. Must think about this. Must look at the SDK features of the Saleae device.