*** SixPack Zipcode (6-file version, 1!!xxxxx, 2!!xxxxx, etc)
*** Document revision: 1.4
*** Last updated: March 11, 2004
*** Contributors/sources: Paul David Doherty,
Wolfgang Moser
This is another rare form of ZipCode, spanning six files, and hence the
use of the name SixPack. Notice how the filename uses two "!!" characters
in it, versus one for the other 4-file or filepacked zipcode formats.
Name Track Range
-------- -----------
1!!xxxxx 1 - 6
2!!xxxxx 7 - 12
3!!xxxxx 13 - 18
4!!xxxxx 19 - 25
5!!xxxxx 26 - 32
6!!xxxxx 33 - 35 (or 40 for 40-track images)
The format for these is *nothing* like the 4-pack, as it contains no
compression or track/sector references. Rather, all the sector data is
stored in GCR code (Group Code Recording). GCR is the method used to store
information, at the lowest level, on a 1541 diskette. It converts 4-bit
nybbles (2 nybbles per byte, upper 4 bits and lower 4 bits) into an encoded
5-bit GCR code. The conversion chart for 4-bit to 5-bit conversion is as
follows:
Hex Binary GCR (dec) Hex Binary GCR (dec)
--- ------ ---------- --- ------ ----------
0 - 0000 - 01010 (10) 8 - 1000 - 01001 (9)
1 - 0001 - 01011 (11) 9 - 1001 - 11001 (25)
2 - 0010 - 10010 (18) A - 1010 - 11010 (26)
3 - 0011 - 10011 (19) B - 1011 - 11011 (27)
4 - 0100 - 01110 (14) C - 1100 - 01101 (13)
5 - 0101 - 01111 (15) D - 1101 - 11101 (29)
6 - 0110 - 10110 (22) E - 1110 - 11110 (30)
7 - 0111 - 10111 (23) F - 1111 - 10101 (21)
If you look over the GCR table, there are two details that should be noted.
1. You *cannot* combine any group of GCR nybbles into a sequence of bits
that contain more than 8 consecutive 1-bits. At least ten (or more)
consecutive 1-bits is used for a SYNC mark, used to tell the disk
controller that sector data is coming up. (In actual fact, the 1541
records an overkill of 40 sequential 1-bits to the disk as a SYNC mark
to ensure the controller can find the mark!).
Note that some documents refer to a minimum of 12 bits needed for a
SYNC mark. This is likely why Commodore chose to use 40 bits for the
standard mark, as the overkill makes it almost impossible to miss.
2. There will never be any more than two consecutive 0-bits. This is done
to insure the accuracy of clocking data back to the 1541 controller.
Too many zero bits, and the clock will go out of sync and start
clocking in phantom '1' bits.
Using the above table, let's convert some numbers. For reasons I will
explain later, we must work in groups of four bytes in order to convert
normal HEX to GCR.
Using these HEX numbers...
0D F5 E4 37
now, split these values into nybbles and convert to binary...
0 D F 5 E 4 3 7
---- ---- ---- ---- ---- ---- ---- ----
0000 1101 1111 0101 1110 0100 0011 0111
convert nybbles to GCR using the conversion table...
0000 1101 1111 0101 1110 0100 0011 0111
----- ----- ----- ----- ----- ----- ----- -----
01010 11101 10101 01111 11110 01110 10011 10111
now, recombine the bit into groups of 8...
01010 11101 10101 01111 11110 01110 10011 10111
| || || || || |
| byte 1|| byte 2 || byte 3 || byte 4 || byte 5|
| || || || || |
------- ---------- --------- ---------- -------
01010111 01101010 11111111 00111010 01110111
and convert back to HEX...
01010111 01101010 11111111 00111010 01110111
-------- -------- -------- -------- --------
57 6A FF 3A 77
So, now we have converted a group of 4 bytes into 5 GCR bytes. The reason
we must encode in groups of 4 is that it is the *minimum* number of bytes
which, when converted to GCR bits, is divisible by 8 bits without any
remainder... 1 byte would be 10 bits, 2 bytes would be 20, 3 bytes would be
30, but 4 bytes is 40 bits, divisible by 8 since it leaves us with 5 groups
of 8 bits.
Now that we have a foundation of GCR encoding, we can begin to analyse
the layout of the 6-pack zipcode. Below is a sample of the beginning of the
first file (1!!xxxxx):
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ASCII
----------------------------------------------- ----------------
0000: FF 03 24 52 55 25 29 4B 9A E7 25 55 55 52 55 35 ??$RU%)K??%UURU5
0010: 2D 4B 9A E7 25 55 55 52 54 A5 49 4B 9A E7 25 55 -K??%UURT?IK??%U
0020: 55 52 54 B5 4D 4B 9A E7 25 55 55 52 55 65 39 4B URT+MK??%UURUe9K
0030: 9A E7 25 55 55 52 55 75 3D 4B 9A E7 25 55 55 52 ??%UURUu=K??%UUR
0040: 54 E5 59 4B 9A E7 25 55 55 52 54 F5 5D 4B 9A E7 T?YK??%UURT?]K??
0050: 25 55 55 52 55 A5 25 4B 9A E7 25 55 55 52 55 B5 %UURU?%K??%UURU+
0060: 65 4B 9A E7 25 55 55 52 54 95 69 4B 9A E7 25 55 eK??%UURT?iK??%U
0070: 55 52 55 95 6D 4B 9A E7 25 55 55 52 55 E5 35 4B URU?mK??%UURU?5K
0080: 9A E7 25 55 55 52 55 55 75 4B 9A E7 25 55 55 52 ??%UURUUuK??%UUR
0090: 54 D5 79 4B 9A E7 25 55 55 52 55 D5 55 4B 9A E7 T?yK??%UURU?UK??
00A0: 25 55 55 52 57 25 A9 4B 9A E7 25 55 55 52 57 35 %UURW%?K??%UURW5
00B0: AD 4B 9A E7 25 55 55 52 56 A5 C9 4B 9A E7 25 55 ?K??%UURV??K??%U
00C0: 55 52 56 B5 CD 4B 9A E7 25 55 55 52 57 65 B9 4B URV+-K??%UURWe?K
00D0: 9A E7 25 55 55 29 0F 05 C0 99 00 02 C8 D0 D4 A9 ??%UU)??+???????
00E0: 02 8D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ????????????????
00F0: 00 00 00 00 00 00 00 00 00 41 4D 45 3A 20 31 32 ?????????AME:?12
0100: 33 34 15 D4 B5 2D 4B 52 D4 B5 2D 4B 52 D4 B5 2D 34??+-KR?+-KR?+-
0110: 4B 52 D4 B5 2D 4B 52 D4 B5 2D 4B 52 D4 B5 2D 4B KR?+-KR?+-KR?+-K
0120: 52 D4 B5 2D 4B 52 D4 B5 2D 4B 52 D4 B5 2D 4B 52 R?+-KR?+-KR?+-KR
0130: D4 B5 2D 4B 52 D4 B5 2D 4B 52 D4 B5 2D 4B 52 D4 ?+-KR?+-KR?+-KR?
0140: B5 2D 4B 52 D4 B5 29 4D 55 55 D4 A5 2D 4B 52 D4 +-KR?+)MUU??-KR?
0150: B5 2D 4B 52 D4 B5 2D 4B 52 D4 B5 2D 4B 52 D4 B5 +-KR?+-KR?+-KR?+
Each file starts with a 3-byte signature, $FF, $03, and then either a $24
for a 35 track image, or a $29 for a 40 track image.
0000: FF 03 24 .. .. .. .. .. .. .. .. .. .. .. .. ..
Track information follows, and is comprised of a 256 byte track
descriptor block (mostly GCR encoded), followed by sector information at
326 bytes/sector. The track descriptor contains the header information of
each sector in that track, as well as the number of sectors encoded on that
track.
The descriptor block is broken up into groups of 10 bytes. Each of these
groups contains the header information of a sector stored in the track.
Sectors are stored in the header in linear order, but not necessarily
starting at sector 0. If the numbers doesn't start at sector 0, then it
will go something like this: 4, 5, 6, 7, 8...16, 17, 18, 19, 20, 0, 1, 2,
3. Since this track started on sector 4, notice the wrap-around from sector
20 back to 0 and up to 3.
Here is the layout from the above sample block...
Pos Byte CGR Contents Normal Contents (decoded)
--- ---- ----------------------------- --------------------------------
Sig Chk Sec Trk Id2 Id1 OffBytes
0 00: 52 55 25 29 4B 9A E7 25 55 55 08 02 00 01 31 32 0F 0F
1 0A: 52 55 35 2D 4B 9A E7 25 55 55 08 03 01 01 31 32 0F 0F
2 14: 52 54 A5 49 4B 9A E7 25 55 55 08 00 02 01 31 32 0F 0F
3 1E: 52 54 B5 4D 4B 9A E7 25 55 55 08 01 03 01 31 32 0F 0F
4 28: 52 55 65 39 4B 9A E7 25 55 55 08 06 04 01 31 32 0F 0F
5 32: 52 55 75 3D 4B 9A E7 25 55 55 08 07 05 01 31 32 0F 0F
6 3C: 52 54 E5 59 4B 9A E7 25 55 55 08 04 06 01 31 32 0F 0F
7 46: 52 54 F5 5D 4B 9A E7 25 55 55 08 05 07 01 31 32 0F 0F
8 50: 52 55 A5 25 4B 9A E7 25 55 55 08 0A 08 01 31 32 0F 0F
9 5A: 52 55 B5 65 4B 9A E7 25 55 55 08 0B 09 01 31 32 0F 0F
10 64: 52 54 95 69 4B 9A E7 25 55 55 08 08 0A 01 31 32 0F 0F
11 6E: 52 55 95 6D 4B 9A E7 25 55 55 08 09 0B 01 31 32 0F 0F
12 78: 52 55 E5 35 4B 9A E7 25 55 55 08 0E 0C 01 31 32 0F 0F
13 82: 52 55 55 75 4B 9A E7 25 55 55 08 0F 0D 01 31 32 0F 0F
14 8C: 52 54 D5 79 4B 9A E7 25 55 55 08 0C 0E 01 31 32 0F 0F
15 96: 52 55 D5 55 4B 9A E7 25 55 55 08 0D 0F 01 31 32 0F 0F
16 A0: 52 57 25 A9 4B 9A E7 25 55 55 08 12 10 01 31 32 0F 0F
17 AA: 52 57 35 AD 4B 9A E7 25 55 55 08 13 11 01 31 32 0F 0F
18 B4: 52 56 A5 C9 4B 9A E7 25 55 55 08 10 12 01 31 32 0F 0F
19 BE: 52 56 B5 CD 4B 9A E7 25 55 55 08 11 13 01 31 32 0F 0F
20 C8: 52 57 65 B9 4B 9A E7 25 55 55 08 16 14 01 31 32 0F 0F
D2: 29 0F 05 C0 99 00 02 C8 D0 D4 garbage
DC: A9 02 8D 00 00 00 00 00 00 00 garbage
E6: 00 00 00 00 00 00 00 00 00 00 garbage
F0: 00 00 00 00 00 00 garbage
F6: 41 4D 45 3A 20 31 32 33 34 garbage "AME: 1234"
FF: 15 Number of valid sectors contained
with this track ($15=21 dec)
Each sector header block is laid out in the following order (after
decoding the 10 GCR bytes to 8 normal bytes):
Byte: $00 - Header block descriptor value $08 (SIG value)
01 - Header checksum (EOR of bytes 02-05) (CHK value)
02 - Sector number (SEC)
03 - Track number (TRK)
04 - Second byte of disk ID (ID2)
05 - First byte of disk ID (ID1)
06-07 - "OFF" bytes ($0F's). These "fill" up the header to make it
a multiple of 4 bytes, necessary in order to convert it to
GCR (as six bytes would be too short to convert)
The entries for Sectors 17-20 will only be valid if the track being
operated on has that many sectors in it. If the value at $FF is $00, then
we have an empty track (bad track from the original disk, and the whole
track should be set to error code 21). When this happens, all the sector
header info in the track descriptor block will be invalid. If we only use
up to sector 16 (for tracks 31 and up), then all the info following the
entry for sector 16 will be invalid. Invalid data can be anything, just
ignore it.
All of the sixpack files I have either created or received contain the
string "AME: 1234" at the end of the track descriptor block. It is likely a
"garbage" string, and can be useful in locating the descriptor blocks when
manually looking over the sixpack files with a HEX editor, but it shouldn't
be used in any other capacity. You also can't easily tell what track you
are on, but given the track ranges covered by each file, and the sector
count at the end of the descriptor block, it is possible to figure it out.
Each sector is 326 bytes long (GCR encoded), and each track is 256 bytes
+ (# of sectors/track * 326) bytes. Track 1 would be 256 + (21 * 326) =
7102 bytes. The sector information stored in a specific interleave pattern,
depending on the track we are on (unlike the entries in the descriptor
block, which are stored in linear order). Note that if this was a 40 track
image, the interleave pattern for the last set of tracks would apply up to
track 40 instead of 35.
Note that the numbers referred to in the "Sector Data Interleave" portion
of the table do *not* refer to actual sector numbers, but correspond to the
group position in the header descriptor block. Thus header group 0 is at
interleave position 0, header group 1 is stored at interleave position 8,
etc. The header and sector data must be recombined this way before decoding
the header to see what the real sector value is.
Track Sector Data interleave reading pattern
----- ----------------------------------------------------
1-17 - 0,8,16,3,11,19,6,14,1,9,17,4,12,20,7,15,2,10,18,5,13
18-24 - 0,8,16,5,13,2,10,18,7,15,4,12,1,9,17,6,14,3,11
25-30 - 0,8,16,6,14,4,12,2,10,1,9,17,7,15,5,13,3,11
31-40 - 0,8,16,7,15,6,14,5,13,4,12,3,11,2,10,1,9
The data within each sector is in two sections, and is stored *out of
order*. This is partially due to the way the 1541 reads the data. The first
256 GCR bytes are read into a buffer, then the remaining 70 GCR bytes are
read into an "overflow" buffer. In the Sixpack image, the last 70 bytes (of
the 326) are first, then the first 256 bytes follow, for reasons left up
the author of the sixpack format. You need to re-arrange the data to be in
the correct order before decoding it. We actually only decode 325 bytes
(from 0-324, this 325 bytes, divisible by 5), so the last byte is left out.
Once decoded, we have the following information:
Bytes: $000 - Data block descriptor value $07
001-100 - Normal sector info
101 - Sector checksum (EOR of the data block, from 001-100)
102-103 - "OFF" bytes ($00's), used to "fill" up the sector, to
make it a multiple of 4 bytes.
ZipCode disks are usually used to transfer disks which contain errors
(copy-protected disks). It also is used for those disks which use unusual
fastloaders such as Vorpal or Warp25, which use different low-level
encoding methods.
The offset for each track into its respective file can vary. Assuming
that the image contains no errors, we can look at each file and calculate
the offset position of where each track should be.
File 1!! Offset File 2!! Offset
-------- ------------- -------- -------------
Track 1 $0003 (3) Track 7 $0003 (3)
Track 2 $1BC1 (7105) Track 8 $1BC1 (7105)
Track 3 $377F (14207) Track 9 $377F (14207)
Track 4 $533D (21309) Track 10 $533D (21309)
Track 5 $6EFB (28411) Track 11 $6EFB (28411)
Track 6 $8AB9 (35513) Track 12 $8AB9 (35513)
File 3!! Offset File 4!! Offset
-------- ------------- -------- -------------
Track 13 $0003 (3) Track 19 $0003 (3)
Track 14 $1BC1 (7105) Track 20 $1935 (6453)
Track 15 $377F (14207) Track 21 $3267 (12903)
Track 16 $533D (21309) Track 22 $4B99 (19353)
Track 17 $6EFB (28411) Track 23 $64CB (25803)
Track 18 $8AB9 (35513) Track 24 $7DFD (32253)
Track 25 $972F (38703)
File 5!! Offset File 6!! Offset
-------- ------------- -------- -------------
Track 26 $0003 (3) Track 33 $0003 (3)
Track 27 $17EF (6127) Track 34 $16A9 (5801)
Track 28 $2FDB (12251) Track 35 $2D4F (11599)
Track 29 $47C7 (18375) Track 36 $43F5 (17397)
Track 30 $5FB3 (24499) Track 37 $5A9B (23195)
Track 31 $779F (30623) Track 38 $7141 (28993)
Track 32 $8E45 (36421) Track 39 $87E7 (34791)
Track 40 $9E8D (40589)
Looking at the error codes for a normal 1541 disk, let's look at how some
of the errors can be stored in the ZipCode images. The following chart is
in reverse order of appearance, with the first errors being the earliest
detected.
Note that the description of the error may not be *completely* correct
compared to how the drive DOS actually works, but serves as a reasonable
explanation in understanding where the error comes from.
Err# Error description and method
---- -----------------------------------------------------------------
21 No SYNC character
Before we can read any sector from a track, the drive will look
for a special "sync" marker, a minimum series of 10 1-bits. If a
sync marker is not found, the track is presumed bad or
unformatted. The SixPack will not contain any sector data
following the 256-byte header as there is no track data to store.
The sector count byte in the track descriptor block will be set
to zero.
20 Header block descriptor not found
This applies to individual sectors where the header ID ($08, from
above) isn't seen where it should be. The actual header is still
read and stored, and the data should still be there.
27 Header block checksum error
The checksum stored in the sector header block doesn't correspond
to the checksum calculated for the header. The data block should
still be there.
29 Disk ID mismatch
The ID's contained in the sector header block don't match the
disk master ID (from the header block of track 18/0, not the one
at offset $A2/A3 of the sector data). The data block is still
present.
22 Data block descriptor not found
If the special value $07, preceeding the sector data isn't seen
where it should be, this error is generated. The SixPack will
still contain the sector data.
23 Data block checksum error
This one comes from the checksum value stored after the sector
data. If the checksum present doesn't match the checksum you
calculate, this error is generated. The data block is still
present in the SixPack.
When decoding these files, and attempting to determine what errors exist,
here are a few tips to work by...
1. Any errors detected in the track descriptor block (20, 27, 29) occur
in linear order (sector 0,1,2,3, etc)
2. Any error detected in the data block (22, 23) is *out* of order, and
follows the previously laid-out sector interleave pattern for the
given track.
The real strength of this format is its usefulness in transmitting
error-protected and non-standard low-level fast-loaded disks. If the disk
you wish to transmit has no errors, using this format would be a waste as
almost *any* other format will use much less space.
One caveat to this format is the unforgiving nature of the 6-pack
creation utility on the C64. The one I used would generate a bad sector if
it encountered a sector that was only slightly bad, but would normally read
back fine on the 1541 (due to the drive's error-correcting nature).
|