Central Point Image File Format

The image file produced by the option board contains a raw bit image of the apple disk. Although it is very much like a nibble disk, it contains the extra bits on sync bytes and any other bits picked up by the heads. It also seems to be able to handle double-sided disks, however I have been unable to accurately transfer such disks. It seems that the physical tracks are offset from one side to the other, which means that the first few are lost and the last ones are garbled.
The first 64 bytes of the file contain the text description that was entered when the image was created. These can essentially be ignored for disk translation purposes.

The next 624 bytes are unknown to me.

The next 400 bytes contain the starting locations for each track in the disk image file. Each pair is the address shifted right by 8 bits. The sides are interleaved so that track 0 side 1 comes right after the pair for track 0 side 0.

The next 400 bytes contain the lengths of each track. These are in the same format as the above.

There seem to be 3 more blocks of 400 bytes that follow, that I cannot figure out. They don't seem to be important though.

After these blocks the track data follows. The tracks are simple bit-images so they need to be read in (as the Disk II hardware does), and converted into their associated bytes before they can be used in an emulator.

In short, the image looks like this:
64 byte header 
224 byte block 
400 byte block 
400 byte block of starting addresses 
400 byte block of track lengths 
400 byte block 
400 byte block 
400 byte block 
400 byte block 
Track data

My current listing for the image file is available for those who wish to look at it. However, please remember that the source is commented so that I can understand it. Also, I haven't worked on this in quite a while, part of the reason I'm making it available is so that others can continue working on it.

Update: A program to create simple "Nibble" format files is also available for those who are interested in it. This simply takes the track data and copies it (byte for byte) into the propper format for a nibble image (note that it's necessary to strip off the extra bits on a self-sync byte since the nibble format doesn't contain them.)

Update #2: An updated version if the img2dsk.c program is available. This version (img2dsk2.c) performs better checksum checking, and will also process the reverse side of disks. NOTE: Due to the way that the heads are aligned on PC drives, the first four tracks of a floppy will be lost when reading them with the Option Board. The only reliable way to read the disk is to punch a second index hole opposite the first.

Christopher Bachmann <cbachman@ece.nwu.edu>