The D40 is an exercise in using my flexible image configuration. Its goal is to design the largest image possible, which still uses the header block (and only the header block) to store BAM entries.
In other words, this format uses the header block as its primary design limitation.
Header
The most efficient existing Commodore header is used by the D81. It makes a great place to start out.
The D81's header starts out the same as all others: a two-byte pointer to the first directory sector, then the DOS type, then one byte with $00, for a total of 4 bytes.
The label offset is at 0x04. All Commodore labels consist of a 16-byte label, two $A0 bytes, two bytes for the Disk ID, one more $A0, two bytes for the DOS Type, and a final $A0 byte, for a total of 24 bytes.
That leaves (256 - 28) = 228 bytes for the BAM. Now the fun begins.
BAM
The Block Allocation Map (BAM) consists of an array of records, one record for each track on the disk. The first byte of each record is the "sectors free" count for that track. The remaining data is a bitmap of the sector allocation for that track: a "1" means that sector is used, while a "0" means the sector is unallocated and free for use.
A little calculation will find several schemes which fits into 228 bytes. Larger bitmaps tend to be more efficient with the space available. The layout I select is 25 tracks of 64 sectors each. The number of bytes needed for the BAM is (25 x (1+64/8)) = 25 x 9 = 225 bytes.
The total capacity of this image would be (25 x 64) blocks = 1600 blocks, or 400k.
Layout
I like to see the header at track 1 -- it's easier for a programmer to get at than at midpoint. The directory can have the remaining 63 sectors in track 1, for a maximum of 63 * 8 = 504 files, which should be plenty.
The remainder of the disk is usable for file storage, for a total storage space of 400 - 8 = 392k.
Nerdy Musings on Nerdy Topics. WARNING: May contain Perl.
Wednesday, April 4, 2012
Tuesday, April 3, 2012
Commodore Disk Image headers, again
One minor nitpick about Commodore disk images is that they have no signature line. The only way you can tell what they are is to look at the extension, the file size, and perhaps try to jump to the header sector and "see" if it looks right. While this is not a major problem, I think there is a simple solution; namely, to add a signature to each disk image.
A signature is a small, initial data set which you can use to determine the nature of the disk unconditionally. My suggestion is to look for an optional 32 byte signature on all Commodore images; if it proves useful, then over time all such images will have this signature.
Examples.
D64 images will start with "1541 DISK IMAGE ".
D71 images will start with "1571 DISK IMAGE ".
D81 images will start with "1581 DISK IMAGE ".
D82 images will start with "8250 DISK IMAGE ".
...and so on.
The remaining 16 bytes should be used to specify the image configuration as clearly as possible. For example, the D64 should have a byte for how many tracks are present (i.e. 35, 40, or some other number), and a byte indicating whether or not error bytes are appended to the end of the image. I would also suggest another byte used to indicate an auxiliary directory track, but that starts to make things complicated.
As I said, this data can be inferred from the image itself, but it is much better to be explicit, and the simplest way to do that is to lead with a short signature block.
Having a "number of tracks" byte could be space-efficient as well, because many images have content much smaller than the disk's capacity; in these cases it would be possible to publish a smaller D64. Since the 18th track is required, the smallest D64 would be 18 tracks long, or about 95k -- almost half the size of the standard D64.
A signature is a small, initial data set which you can use to determine the nature of the disk unconditionally. My suggestion is to look for an optional 32 byte signature on all Commodore images; if it proves useful, then over time all such images will have this signature.
Examples.
D64 images will start with "1541 DISK IMAGE ".
D71 images will start with "1571 DISK IMAGE ".
D81 images will start with "1581 DISK IMAGE ".
D82 images will start with "8250 DISK IMAGE ".
...and so on.
The remaining 16 bytes should be used to specify the image configuration as clearly as possible. For example, the D64 should have a byte for how many tracks are present (i.e. 35, 40, or some other number), and a byte indicating whether or not error bytes are appended to the end of the image. I would also suggest another byte used to indicate an auxiliary directory track, but that starts to make things complicated.
As I said, this data can be inferred from the image itself, but it is much better to be explicit, and the simplest way to do that is to lead with a short signature block.
Having a "number of tracks" byte could be space-efficient as well, because many images have content much smaller than the disk's capacity; in these cases it would be possible to publish a smaller D64. Since the 18th track is required, the smallest D64 would be 18 tracks long, or about 95k -- almost half the size of the standard D64.
Subscribe to:
Comments (Atom)