Commodore 8-Bit Disk Image Utilities

Disk: none.

Notes

Supported Disk Image Formats

D64

Standard 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.)
40-track extensions by Dolphin-DOS, SpeedDOS, or PrologicDOS should be recognized, as well.
Non-standard 41/42 track extensions are recognized, if there is a reference to any such track either in the directory or in the sector links of a loadable file.

D80

The 77-track format of the Commodore 8050 drive for the Commodore PET.

D82

The 154-track format of the Commodore 8250 double-sided drive for the Commodore PET.
(Also used by the similar SFD-1001 and the 8250LP.)

These disk image formats mirror the raw data on the disk, less any of the low-level sytstem information like sync-marks or checksums. This is optionally followed by additional block error information (AKA error bytes), one byte per block. (Since there is no special header, there is no obvious indication of the file format, other than the file extension and typical file sizes.)

Supported File Formats (by File Extension)

.PRG

The standard Commodore format for programs. The first two bytes specify the load address (low byte, high-byte), followed by the raw 8-bit data stream of the program.
Internal type code on the drive: 2, listed as "PRG".

.SEQ

Sequential file, just a raw 8-bit data stream.
Internal type code: 1, listed as "SEQ".

.USR

User definable format, usually just the same as a SEQuential file.
Here, USR-files are handled exactly like SEQ-files.
Internal type code: 3, listed as "USR".

.REL

Relative files of a fixed record size (up to 720 records of a record size of up to 254 bytes).
Here, a REL-file is headed by the record size given in the first byte, followed by the sequential data stream. (I'm not aware of a well-documented, generic export format for REL-files. The format chosen follows the example of the PRG format and may have already been implemented elsewhere as the logical choice. For a standard solution see the P00-format, which explicitly includes an applicable record size.)

On disk, a REL-file consists of a sequential data stream and a chain of up to 6 so-called side sectors. These side sectors include a reference to the very disk block (by track and sector), the start of any record is located in, as well as links to any further of the up to 6 side sectors (including itself). Thus, with the current side sector already held in a buffer, any record may be accessed with a minimum amount of disk reads, as the position within a block can be derived from the fixed record size by simple calculations. Since there are 120 possible references in any side sector, this system also provides the maximum record number of 720 possible records per file. (Mind that opening a REL-file also allocates additional disk buffers and thus limits the number of concurrently opened files.)

Side sector information is not only entirely separate from the actual file data, it is also specific to the disk and its block allocation and meaningless outside this very specific context. Therefore, it is neither exported, nor expected on inport. The only information required to make this portable is the record size, which is stored along other basic information in the directory entry of the file.

While REL-files worked fine on the PET and its related IEEE-488 drives, there were reported issues with this file type on the 1471, leading to corrupted side sector information, for which it is seldom found in C64-context. (Since the side sector information isn't required for a sequential read-out, these files should be still accessible and exportable in and by the disk inspector.)

Internal type code: 4, listed as "REL".

.DEL

A deleted or invalid file (sometimes used for decarative purpose in the directory listing, as these files will still list). While deleted files may still point to a first block by track and sector, any of its blocks have been de-allocated in the Block Availability Map (BAM) and may have been overwritten, since. While it may be possible to reconstruct such a file by following the block links in the first two bytes of any block on disk (you may click these in the data view for unassociated single blocks to follow along and collect the data by copy & paste), there is no guarantee that this may be still valid.
Here, it is not possible to import or export a DEL-file, but you can create a (decorative) DEL-file in the D64 Composer.
Internal type code: 0, listed as "DEL".

.PET

Same as a PRG-file.

.P00

P00-files consist of a header, which encodes the actual file name in ASCII and, for REL-files, the record size, followed by the raw data (for programs inlucing the load address in the first two bytes).
File extensions provide by convention the file type in the first letter, followed by two figures (00…99).
(I.e., files with extensions ".Pnn", ".Snn", ".Unn", and ".Rnn".)
Here, for the purpose of the D64 Composer, the REL type is enforced whenever a non-zero record size is found in the header information, regardless of the type hinted at in the file extension.

Special Marks in Commodore Directory Listings

"*"

An asterisk before the file type (also known as "splat") indicates a file that wasn't closed properly. Since crucial information for the directory and in the BAM is only updated on the disk on CLOSE, these files are not loadable. "Splat files" are not included in the directory listing by default. (This includes any empty directory entries, consisting of all zero-bytes, which would also show up as "splat files".)

"<"

An angle bracket pointing to the left ("less than") after the file type indicates a locked file.

Fun Fact

The ROM for BASIC 1 on the PET 2001 didn't only feature non-standard and somewhat unfinished routines for LOAD and SAVE, non-compliant with IEEEE-488/GPIB protocol, it also didn't write the load address of any program to disk, like later versions of Commodore BASIC did. Rather, it implicitly assumed a load address of $400 and loaded unconditionally to that address, without relinking any BASIC programs. (This prominent feature of Commodore program files was only introduced as the VIC-20/VIC-1001 was in development and the need for relocating BASIC programs became apparent. Similarly, there is no secondary load address, as in “LOAD"*",8,1”, used by any of the subsequent versions of BASIC on the PET: programs are always loaded to the provided load address, and relinked, if this also happens to be the BASIC start address.) The BASIC start address was still $401, like with later revisions of the PET's ROMs, and programs were consequently headed by a mandatory zero-byte. Moreover, an extra byte (often $24) was stored after the actual end of the program, extending the file size by 1. Some of these programs can be still found on disk images, with an appropriate load address of $400, probably added by some kind of migration program.
You can inspect an example of such a disk image here: PETGMS08.D64.

Disclaimer

This is free software provided for free and as-is. Now warranties or guarantees given, all liabilities denied, use at your own risk.

The programs/tools run entirely locally in your browser, no information is uploaded or transmitted otherwise.

This is an entirely independent implementation from scratch (originally devised as tools for the PET 2001 emulator, where they should show up soon).
No AI was involved at any point.