(Now Go Bang!) Commodore 8-Bit 5 1/4 Inch Disk Images

August 12, 2026 Presenting a new (web) tool, also a general discussion of Commodore 5¼" disk images. So, Dear Reader, I’ve been working (busily) on a new version of the PET 2001 emulator. (Yes, again.) In essence, this is about a totally new implementation of the IEEE-488 / GPIB bus emulation and translation layer, from scratch. This not only includes implementing the IEEE-488 protocol itself (there are stories to tell, but this is for another time), an implementation of the DOS on the drives (some interesting details here, as well, but also, well, for another time), rewiring the entire command chain / glue logic behind file handling, but also an improved handling of disk images (aha, we’re finally arriving at the matter of this post!). This rewrite is not about emulating any of the drive hardware and subsequently running the ROM code on this, rather, it’s about re-implenting the interface as an entirely independent solution. The benefit of this will be that we’ll be able to do whatever we’d like to do with any files (local files, data stored on some media image, etc.) and supply them to the emulated PET as if it were delivered by a normal disk drive unit. Moreover, we finally have support for things like OPEN, PRINT#, INPUT#, GET#, CLOSE, CATALOG, etc., and some nice-to-have things, like “FILE NOT FOUND” (if we can find this, but this is yet another story — as already indicated, there are stories to tell). And, maybe, we may even have support for a printer emulation (why not, now that we have full GPIB?) Preview of things to come: CATALOG command of PET BASIC 4.0 and some fancy directory entries. So it’s really about mixing media: local files, data on disk image or tape image files, stand-alone files, etc., and presenting them in a transparent manner to the emulated PET. In order to close this information cycle, I thought, it would be nice to be able to peek into a disk image, to explore its content, and to copy and even export any data/files from this. Similarly, to finally close the gap between files stored on some media image and local files, especially for the purpose of distribution of any of your esteemed projects, it should be nice to have a tool for composing D64 disk image. This, actually turned out quite well. Since, I’m rather proud of this and also think that it may be of broader interest and utility (it may be hard to believe, but there’s more from Commodore than just the PET), I packed these two tools into an early “single release” of the new disk utilities as a stand-alone application. Or, in the (somewhat unrelated, but still immortal) words by Sir Clive (Sinclair), “I give you the ‘Commodore 8-Bit Disk Image Utilities’!” 1) The Commodore 8-Bit Disk Image Utilities As it ought to be, our “single release” from the programmatic album that is the PET 2001 emulator features two sides: Side A The Disk Image Inspector is essentially your very own point-and-click adventure to the mysteries of Commodore 8-bit 5¼" floppy disk images (D64, D80, D82 formats). Use the context menu to copy any data or to bring home any treasures, you may find, by exporting them as a file (generic .PRG, .SEQ, etc., or in P00-format). You may even use the context menu to navigate! No expenses were spared. Disk overview with BAM, disk header and directory data.(Mind the file association of blocks and selected file as shown by the highlighted blocks in the BAM view.) File/data view of the selected file.(Block/sector links and load address are pointed out in color.) Context menu with copy and export options. Side B The D64 Composer is a wizard to compose and finally download D64 (35-track) disk images. You may add any traditional Commodore file (e.g., as previously saved from the emulator, or as extracted from anouther disk image), rename and/or reorder them, change the file type attribute, exclude a file temporary from export. You may even add DEL-files for decorative purposes. Composing a fancy disk image.(Mind the trailing quotation marks preserving white space that would be discarded else.) CATALOG output listing our fancy directory. Moreover, you get some explanatory notes on Commodore file formats.Of course, this runs all locally in your browser and no data is transmitted anywhere. Also, this is an entirely new and independent implementation from scratch and no AI was involved at any point. But this is all easier shown than told, so, maybe just head over and give it a try? (There’s a link to load a PET disk image to play around with, but, of course, you can always bring your own.) 2) Commodore 8-Bit (5¼") Disk Images This brings us to our second part, namely, an overview on the various disk image formats for the Commodore 8-bits, that is: D64, D80, and D82, and how they relate to the actual disk. These disk images are sometimes described as raw representations of the respective disk images. This may be true insofar as these disk images do not have anything special about them: there is no header, no signature, just a stream of data as found on the disks. Apart from the file extension and maybe typical file sizes, there is no way of telling that this actually a disk image, just based on cursory inspection. On the other hand, there is much more on a Commodore floppy disk than just the data: there are sync marks, block headers and IDs, checksums for error correction, alignment gaps, etc., found at the low-level. Low-level structure of a block/sector on a Commodore floppy disk.Source: Commodore Computer Disk System User Guide; Commodore Electronics Limited, 1983; p.62.(Color added by me; N.L.) In the above image, only the part highlighted in orange, the payload data of any block/sector is represented in the disk image. (Both terms, “block” and ”sector”, may be used synonymously. I’ll go with “block”, since we’ll be more interested in the block-oriented nature of the medium than the physical layout.)On the other hand, a disk image may add an extra section to this representation, encoding block error information (the so-called “error-bytes”, referencing any read errors on image creation) at the very end, which is not found on the physical disk. The aspect of is that this to be aware of is not all information, there is, on the disk, and it may not be enough information to preserve a copy-protection scheme or similar low-level devices. It is rather a logical view of the data as laid out on the disk. But, before we (no, we can’t say “delve” in 2026, we could just add an em-dash, as well), so, well, “scrabble around” in blocks, we’ll have first a look at the greater picture, namely, the track structure those blocks are embedded in. Track and Image Formats D64Standard 35-track format, as used by the Commodore 2032, 4040, 1540, 1541, 1551 drives.(Within certain limitations this includes the 2031 drive, which uses the same format, but doesn’t store a valid Disk ID or a Disk DOS Version tag in the header block.)There are 40-track extensions by Dolphin-DOS, SpeedDOS, and PrologicDOS for the 1541.Non-standard tracks 41 and 42 are physically accessible by the drive, while not supported by the DOS (hence, may be part of a protection scheme, esp. on the C64/1541).Besides the standard 35-track format, the D64 format supports both 40-track extensions and #41/42 non-standard tracks. D80The 77-track format of the Commodore 8050 drive for the Commodore PET. D82The 154-track format of the Commodore 8250 double-sided drive for the Commodore PET.Also used by the similar SFD-1001 and the 8250LP. An important thing to note is how these tracks are numbered: tracks are numbered starting from 1, from the outside in. Meaning, for a 35-track disk (D64), these are tracks 1 to 35. A track reference of zero (0) always indicates the last block in any chain of blocks. Since tracks start at the outside (rim-ward ;-) ), we also find the largest number of blocks/sectors in the lower numbered blocks, with the number of blocks decreasing as we travel inwards. Since the Commodore drives feature variable speeds, we find these as stepped groups, rather than in any anaolog correspondance to the physical location on the disk. For 35-track disk this is: NUMBER OF BLOCKS PER TRACK TRACK NUMBER NUMBER OF BLOCKS 1 to 17 21 18 to 24 19 25 to 30 18 31 to 35 17 (with any 40-track extensions also featuring 17 blocks per track.) For 77-track disk this is (the double-side 154-track format just doubles this for second side, with the most outward 29-block track 78 following track 77.): NUMBER OF BLOCKS PER TRACK TRACK NUMBER NUMBER OF BLOCKS 1 to 39 29 40 to 53 27 54 to 64 25 65 to 77 23 Source: Commodore Computer Disk System User Guide; Commodore Electronics Limited, 1983. In graphical (spatial) terms, this means for a 35-track disk: Track/Sector 11111111112 012345678901234567890 1 xxxxxxxxxxxxxxxxxxxxx 2 xxxxxxxxxxxxxxxxxxxxx 3 .x.xxxxxxx.x.xxxxxxx. 4 xx.xxxxxx.xx.x.xxxx.x 5 xxxxxxxxxxxxxxxxxxxxx 6 xxxxxxxxxxxxxxxxxxxxx 7 xxxxxxxxxxxxxxxxxxxxx 8 .x.x.x.x.x.xxx.x.x.x. 9 xxxxxxxxxxxxxxxxxxxxx 10 xxxxxxxxxxxxxxxxxxxxx 11 xxxxxxxxxxxxxxxxxxxxx 12 xxxxxxxxxxxxxxxxxxxxx 13 xxxxxxxxxxxxxxxxxxxxx 14 xxxxxxxxxxxxxxxxxxxxx 15 xxxxxxxxxxxxxxxxxxxxx 16 xxxxxxxxxxxxxxxxxxxxx 17 xxxxxxxxxxxxxxxxxxxxx 18 **..*..*..*........ 19 xxxxxxxxxxxxxxxxxxx 20 xxxxxxxxxxxxxxxxxxx 21 xxxxxxxxxxxxxxxxxxx 22 xxxxxxxxxxxxxxxxxxx 23 xxxxxxxxxxxxxxxxxxx 24 xxxxxxxxxxxxxxxxxxx 25 xxxxxxxxxxxxxxxxxx 26 xxxxxxxxxxxxxxxxxx 27 xxx.....xxxxx....x 28 xxxxxxxxxxxxxxxxxx 29 xxxxxxxxxxxxxxxxxx 30 xxxxxxxxxxxxxxxxxx 31 xxxxxxxxxxxxxxxxx 32 xxxxxxxxxxxxxxxxx 33 xxxxxxxxxxxxxxxxx 34 xxxxxxxxxxxxxxxxx 35 x.xxxx.x..xxxxxx. 'x' ... data block '*' ... system block '.' ... not allocated (free) Typical view of the BAM (Block Availability Map) information of a 35-track disk, showing the deminishing track lengths. (You may copy data like this from the disk inspector! We may also notice something special about track #18 in the above representations, where all blocks are marked as “system block” (*). This is the header track,