Differences

This shows you the differences between two versions of the page.

--- doc:cbm:disk:image:g64 [2020/06/01 01:38] – eek
+++ doc:cbm:disk:image:g64 [2020/06/01 01:47] (current) – [Analysing the GCR data stream] eek
@@ Line 189: / Line 189: @@
 track is one constant speed, then  you  don't  need  the  extra  blocks  of
 information hanging around the image, wasting space.
 What may not be obvious is the flexibility of this format to  add  tracks
@@ Line 214: / Line 215: @@
 a SYNC mark of 40 'on' bits (10 'F's in a  row).  Note  that  there  are  2
 groups of SYNC marks quite close together, one for the  sector  header  and
-one for the sector data. In the above example, there is 2 groups of "FF  FF
+one for the sector data. In the above example, there is 2 groups of ''"FF FF FF FF FF"''.
-FF FF FF". The first one is the header SYNC and the second one is the  data
+The first one is the header SYNC and the second one is the  data
 SYNC.
@@ Line 232: / Line 233: @@
 FIXME
+The 10 header info bytes (#2) are GCR encoded and must be decoded down to
+it's normal 8 bytes to be understood. Once decoded,  its  breakdown  is  as
+follows:
+FIXME
+The header gap (#3) is 8 bytes on an early model 1540/1541, but  9  bytes
+on a later model 1541 and 4040. The 1541 doesn't read the header  gap,  but
+simply waits it out to write out the  sector  data.  When  sector  data  is
+written, the SYNC mark is re-written as well.
+There is some controversy over the header gap (#3). Most people assume it
+to be 9 bytes of ''0x55'' characters, but the early 1540/1541 drives used  only
+. This caused an write incompatability with the existing 4040 disks of the
+day. In 1541 ROM revision 901225-3 this error was fixed, and now all drives
+write out 9 of the ''0x55'' characters for the gap. The book "Inside  Commodore
+DOS"  by  Immers/Neufeld  documents  the  write  incompatibilty  and   what
+corruption happens at a low level when writing to a disk with a header  gap
+of 8 bytes on a disk that normally expects a gap of 9 bytes.
+The tail gap (#6) is the unused space between the end of one  data  block
+and the start of the next. It will vary in size depending on what track you
+are on, how fast the drive that created the disk was rotating at, and  what
+program was used to format the disk. The stock 1541 format code is supposed
+to determine how big a track is and divide up the extra unused  space  into
+each tail gap. However, many disks will show a much larger tail gap between
+the last sector and sector 0. In tests that the author conducted on a  real
+disk, gap sizes of 8 to 19 bytes were seen.
+The 325 byte data block (#5) is GCR encoded and must be  decoded  to  its
+normal 260 bytes to be understood. For comparison, ZipCode Sixpack  uses  a
+byte GCR sector (why?), but the last byte (when properly rearranged) is
+not used. The data block is made up of the following:
+FIXME
+The most reliable way to read G64 track data is to read it as  bits,  not
+bytes as there is no way to be sure that all the data is byte-aligned. This
+simulates the way a 1541 drive reads data as well as the  head  only  reads
+bits as well. The starting location of the track data is know, as  well  as
+the track size so the boundaries of the track limits (start  and  end)  are
+obtainable.
+What follows is a very simply  point-form  list  of  how  to  read  data,
+finding sync marks, header blocks and sector blocks.
+  - Search for SYNC (at least 10 or more 1 bits)
+  - Check for header id after SYNC (GCR ''0x52'')
+  - If header, read the remaining 9 header bytes
+  - Decode header and get sector value
+  - Search for SYNC again
+  - Check for data id after SYNC (GCR ''0x55'').
+  - If data, read and store with previous header.
+  - Have we finished reading the track... stop
+  - Start over