Den mån 15 feb. 2021 kl 20:51 skrev Fred Cisin via cctalk <
cctalk@classiccmp.org>:
> On Mon, 15 Feb 2021, Mattis Lind via cctalk wrote:
> > My guess is that the data that follows the sector ID is some kind of
> > checksum.
>
> yes. well, sorta. 16 bit CRC
>
>
> A typical IBM/WD style format has:
>
> a gap
> Index Address Mark
> a gap (note that WD can use a shorter post index gap than NEC can)
>
> and then, repeated for each sector:
> {
> a gap
> ID Address Mark,
> C Cylinder number
> H Head number (0,1)
> R Sector number
> N Sector Length (0:128, 1:256, 2:512, 3:1024)
> 16 bit CRC of the sector header
> a gap
> Data Address Mark
> Sector data (128, 256, 512, or 1024 bytes. Larger is possible, but
> unlikely)
> 16 bit CRC of the data
> a gap
> }
>
>
Well. Now this is NOT a standard 179x that has written this. As I mentioned
early on in this thread it was not at all possible to read the disks with a
standard controller. The bit rate was off by quite a bit and the general
format is different. So this is not necessarily a CRC at all. The machine
that has written these is the Q1 Lite computer. A very odd mid-seventies
system. http://bitsavers.trailing-edge.com/pdf/q1/Q1_Sales_Brochure.pdf.
Here is an example header:
CNT: 021D5 ADDRESS MARK: 55424954 00000001 01000101 01000110 00010000
000000V00 00000000 00000000 00000000 00000000 00000000 0V0100100 0V00
"V" is for MFM violation, most likely due to write splicing after the
header when enabling writing. This means that the header is at most 4
bytes. First bytes is track, second byte is sector. The third byte appears
to be the sum of the track and sector byte. The fourth byte is unknown. In
all the tracks it seems to have the same value.
/Mattis
> (This is from memory (error prone?). The WD1791 datasheet should have
> more detail, including CRC algorithm?, the specific requirements for the
> address marks, and gap contents (write splice, synchronization, etc.))
>
>
> --
> Grumpy Ol' Fred ci...@xenosoft.com
>
