Directory incorrect for D64 images with non-standard DOS version byte value

[0xa000]

Test Environment

• Platform: Wukong
• ROM Release: 920408
• Core Commit: cbd9e85

Describe the bug
Some D64 disk images either show an empty directory, or produce an illegal track/sector error when loading the directory, even though there are files on the disk. The freezer does show the correct directory listing in the right hand preview pane of the disk image selection screen.

To Reproduce

1. Obtain a non-empty D64 disk image with a non-standard DOS version byte value.
2. Mount the disk image in C65 basic, or via the freezer.
3. Issue the DIR command.
4. Observe an empty directory listing, or an illegal t/s error.

Expected behavior
The contents of the disk image should be listed as usual.

Additional context
The usual value of the DOS version byte (byte 2 of the BAM at track 18, sector 0) is $41. However, other values occur in the wild, most commonly $42. Looking at the ROM sources, specifically the function initdr in dos.scr, the DOS version byte is examined to determine the disk image type. If the DOS version byte is neither $41 (fmt2040), nor $44 (fmt1581) or $00, a fallback path is used that uses sector 3 (sysdirsec) of track 18 as the first directory sector. However, this is incorrect for D64 images. As a result, depending on the contents of sector 3, either an empty directory will be shown (if the t/s bytes are zero), or an illegal t/s error will be show (if the track byte is out of range).

The implementation of initdr contains a few oddities:

• It retrieves the DOS version byte (BAM sector byte 2) via buftab and stores it in dskver, yet several lines further down it again retrieves (the same?) DOS version byte via bmpnt.
• It examines dimag to decide it the disk is a D64 or D81 image, yet later it examines the DOS version byte to answer the same question. (The value of dimag comes from "the hardware", ie. $d68a).

If the dimag value is always available and accurate, it seems one approach to fix this issue would be to not examine the DOS version byte to decide the image type, but simply trust the dimag flag.

[dansanderson]

@0xa000 Would it be possible for you to produce a disk image that demonstrates this and attach it to the ticket?

[0xa000]

Here you go. Had to create a ZIP because github does not like D64 files.

OK.D64 - Normal working D64 image with DOS version byte $41
EMPTY.D64 - Same disk image, but with non-standard DOS version byte $42
ILLTS.D64 - Same as EMPTY.D64, but with different free sector contents

DISKIMAGES.ZIP

[0xa000]

When initdr sees a non-standard DOS version byte value, it will use track 18, sector 3 as the first directory track.

In EMPTY.D64, free (unused) sectors contain all zeros. This looks as an empty directory, since the (next) track number is zero, and the sector itself contains no directory entries.

In ILLTS.D64, unused sectors start with $4B and the rest is all ones. This is the DirMaster default, apparently. Anyway, the (next) track number is $4B, which is illegal, so you get an illegal track or sector error in this case.

[dansanderson]

Thanks very much!