[wesbiggs]

This is part 4 of a series of PRs to streamline and consolidate disk image (.d64/.d71/.d81) access, which will then be used to power the VDrive Special IO. It moves the TR menu's own D64/D71/D81 code, loading a file and listing a directory, onto the shared engine from #88. After it, the firmware has no disk image code of its own left, and the series stops here until the VDrive work proper.

Depends on #88, #89 and #90. Only the last two commits (b1010ded, 154ee102) are new here, so please review those. Once the others merge, I'll rebase this branch onto main and it will shrink to those two commits.

Rationale

D64.ino carried its own sector geometry, file-chain reader and directory walk: a fourth copy of what the engine does, and the least defended one. A file chain that loops or links off the image read until RAM ran out or seeked to a wrong offset, and the listing stopped a directory sector at its first empty slot.

State of affairs after this PR

• Loading a file (b1010ded) goes through the engine via DiskImage/MenuDisk.h, which also holds the menu's size tolerance: short D64s down to 171520 bytes (Realm.d64 is one) still open, and a sector past the file's end fails to read rather than the image being refused. Valid files load the same bytes as before. A chain that loops or links off the image now fails with "File could not be read", and the size limit is the buffer's exact size rather than 254 bytes short of it.
• Listing a directory (154ee102) goes through the engine's directory iterator, via MenuDiskList. This changes what the menu shows, to match a drive's own listing:
  • a deleted file (type byte 0, name still in the slot) is no longer listed;
  • an empty slot no longer ends its directory sector, so entries after a gap are listed.
• The listing still starts at the first directory sector (18/1, or 40/3 on a D81) rather than the header's link, as the menu always has.
• LoadDxxDirectory and LoadDxxFile keep their signatures, so every way into them (the menu, and DriveDirLoad.ino's callers) takes the new path.

Memory

• New functions in D64.ino and MenuDisk.h are FLASHMEM, and the engine's are VD_COLD, which is FLASHMEM on the firmware. None of it is on the PHI2 path.
• MenuDisk.h's size and track tables are PROGMEM, and the menu's two load-failure messages use PSTR().
• No new RAM2 use. Directory entries are still allocated one per listed file, as before.
• RAM, from the link report of the shipping builds (npm run build:tr, npm run build:tr-plus), at firmware: the GEOS installer and boot-file reader use the shared disk image engine #90's tip (81b2e06c) and at this branch's tip: no change. TR and TR+ main, MinimalBoot and the TR+ extension image report the same RAM1 free for local variables and padding and RAM2 variables before and after (TR main 122748 / 6008 / 17600, TR+ main 79836 / 25864 / 17600).

Docs

• docs/Architecture/Disk-Images.md: MenuDisk.h, and the TR menu as the engine's third caller, with what its listing shows.

Testing

• New host test Source/Teensy/tests/menu-disk.test.js lists directories and loads files the way the TR menu does, from each kind, short and odd-sized images, deleted entries, gaps, and chains that loop or link off the image.
• npm test passes at this branch's tip.
• Host build only, not hardware tested. Browsing into a D64, D71 or D81 from the TR menu and launching a program from it goes through this path.

Compatibility

The menu's listing of a disk image changes as described above: deleted files no longer show, and files after an empty directory slot now do. No change to the remote protocol (docs/ControlComms.md), the cartridge register map, the EEPROM settings or any timing.

License

My own work, MIT licensed like the rest of the repository.

🤖 Generated with Claude Code