Subversive Metadata for Existing Commodore Images

SYNOPSIS

Jim Brain has suggested a way to encode optional metadata into Commodore images.  Though there are problems with his suggestion, it has merit.

METHOD

Jim's suggestion is to put optional metadata into the final sector of the directory.  The reason given is that this sector is seldom used, since the directory is seldom filled up or exceeded, although this does happen from time to time.

The reason for making this metadata optional is because this sector can be used for other nonstandard purposes, as well as for directory entries.

METADATA

What sort of metadata could go into this block?  There is a lot of useful, but not critical, information that could go there.

1. Magic Strings.  A "magic string" is a short, constant data string that indicates the overall structure of the image.  This string could be scanned for, regardless of the file size, to verify how the file should be parsed.  For example, a D64 might have a magic string of "1541 Digital Image, 2014 January"-- a string that is highly unlikely to show up in any D64 file.  But if present, the parser can be certain that it's a D64 file.

2. Nonstandard Sizes.  Nonstandard image size data could go here.   For example, a byte that indicates the number of tracks present for this image could allow a D64 with 255 tracks, or as few as 18 tracks (stopping at the Directory track).

3. Nonstandard Formats.  Metadata may indicate that the image's format has been altered in specific ways.  For example, the BAM might be nonexistent, or error data is stored in data blocks as a file starting at a particular T/S link.  For that matter, the entire image may be rearranged, with the header at Block 0, the Directory pointed to with a T/S link, error data at another T/S link, and a disk structure having a variable number of tracks with 256 sectors each.  This sort of radical departure would require easy detection of a Magic String of course.

Absurd Commodore Disk Image Format, version 3

Whereas previously I tried to parameterize every possible physical image format, this time I'm just focusing on a more abstract but Commodore-friendly structure.  My purpose is to define a simpler format that is quite flexible, which carries data that can be transferred onto a true physical image with a minimum of fuss.

OVERVIEW

This meta-disk uses a virtual disk format with 256 sectors per track and a variable number of tracks (64k per track).  The image begins with Track 0, and has a maximum possible track number of 255. 
   
The number of tracks present in an image is always computable as:

    Number of Tracks = [Image Size in Bytes] / 65536;
Similarly, the total number of sectors present in an image is known:

    Sectors Per Track = 256;
    Number of Sectors = [Image Size in Bytes] / 256;
NO BAM

This format has no need for a Block Allocation Map (BAM). Being an image designed for virtual use rather than physical media, such a map would be presumably constructed and maintained in memory as the image is used.  If its contents are written to a physical format (e.g. a D64), the BAM would
be calculated as the target image is built, or the new image would be validated by some other means at hand.

I. Header block, 256 bytes.

   This is addressed as sector 0 of track 0, which is always a "null"
   pointer reference for data blocks.
  
   This block contains information about the disk image,
   plus meta-data found in every header block of a Commodore disk.
  
   IMAGE HEADER
  
   $00-$0c Magic Header ASCII = 'ABSURD FORMAT'
   $0d     $00    
   $0e     Header version
   $0f     $00
   $10-$1f Image Label, $a0 terminated
   $20-$21 First directory block (0/0 = none)
   $22-$23 First error block (0/0 = none)  
   (remaining bytes thru $3f Reserved)
  
   DISK HEADER
  
   $40-$4f Disk label, $a0 terminated
   $50     $a0
   $51-$52 Disk ID
   $53     $00
   $54-$55 DOS Type and Version
   $56     $00
   (remaining bytes thru $ff Reserved)

II. Directory Block, 256 bytes.
    Standard Commodore format.  Contains up to eight directory entries.
   
III. File Block, 256 bytes.
     Standard Commodore format.
   
IV. Error Block, 256 bytes.
    Similar in structure to a file block, but contains up to 254 error bytes
    per Error Block, corresponding to sector read errors (usually for 1541 error
    protection schemes).  A full 1541 image requires three Error Blocks.