Differences

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

--- doc:cbm:disk:image:g64 [2020/06/01 01:34] – 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 190: / Line 190: @@
 information hanging around the image, wasting space.
-  What may not be obvious is the flexibility of this format to  add  tracks
+What may not be obvious is the flexibility of this format to  add  tracks
 and speed offset zones at will. If a program decides to write a  track  out
 with varying speeds, and no speed offset exist, a new block will be created
@@ 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