Differences

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

--- doc:cbm:disk:image:g64 [2020/06/01 01:35] – [File Format] eek
+++ doc:cbm:disk:image:g64 [2020/06/01 01:47] (current) – [Analysing the GCR data stream] eek
@@ Line 126: / Line 126: @@
 FIXME
-The track offsets rquire some explanation. When one is set to all 0's, no
+The track offsets require some explanation. When one is set to all 0's, no
 track data exists for this entry. If there is a value, it  is  an  absolute
 reference into the file (starting from the beginning of the file).
@@ 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 201: / Line 202: @@
 FIXME
+===== Analysing the GCR data stream =====
+Since the information stored in the track data area is in GCR format,  it
+is not as simple to analyse as a normal 256-byte sector would be. Here is a
+dump of a portion of the GCR data, and what to look for...
+FIXME
+We need to establish a marker by which one can  start  to  interpret  the
+data. Always look for a group of at least 10 1-bits (two 'F's in a row  and
+a bit more), as they establish the SYNC mark. The 1541 actually writes  out
+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 FF FF FF"''.
+The first one is the header SYNC and the second one is the  data
+SYNC.
+An important point here: some documentation refers to  the  minimum  SYNC
+mark as being at least 12 bits wide, and claims that one of  that  size  is
+still not entirely reliable. Thus Commodore chose to use 40  bits  for  the
+SYNC mark, making it impossible for the drive read electronics to miss.
+If the GCR data is not in the standard sector layout, then anything  goes
+for interpreting the data. If no standard SYNC  mark  can  be  found,  then
+there is no simple way to extract any useful data.
+Here's the layout of a standard low-level pattern on a 1541 disk. Use the
+above example to follow along.
+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