[wesbiggs]

This is part 2 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 block device onto the shared engine from #88.

Depends on #88. Only the last commit (f2e7a9e0) is new here, so please review that one. Once #88 merges, I'll rebase this branch onto main and it will shrink to that commit.

Rationale

TRBlockImage did its own track/sector arithmetic on top of the GEOS installer's format table, which knows only the three plain image sizes. A D64 with the error bytes some copiers append, or a 40-track D64, therefore mounted as no image.

State of affairs after this PR

The block device backend opens the image with the engine (d64_open_exact, added here) and reads and writes through d64_block_read/d64_block_write, so its geometry is the one VDrive uses. D64s with error bytes and 40-track D64s now mount. The error table is left unread: the driver has no status for a bad sector, so it gets the sector's bytes, as a drive that read it anyway would give them. A file of any other size still mounts as no image. The GEOS installer still has its own copy of the image code; the next PR moves it over.

Memory

• The new backend functions are FLASHMEM, and the engine's are VD_COLD, which is FLASHMEM on the firmware. None of it is on the PHI2 path: block transfers run from the polling handshake, as before.

• The one table added (d64_open_exact's track counts) is PROGMEM.

• No malloc and no new RAM2 use. The image state lives in the existing static TRBlockImg, which now holds the engine's d64_t in place of a format pointer.

• RAM, from the link report of the shipping builds (npm run build:tr, npm run build:tr-plus, so the TR+ carries the extension loader), at main (d2faddce) and at this commit:

  Image	RAM1 free for local variables	RAM1 padding	RAM2 variables
  TR main	122748 → 122748 (no change)	6136 → 6008 (ITCM code +128)	17600 → 17600
  TR+ main	79868 → 79836 (−32, variables +32)	25864 → 25864	17600 → 17600

  MinimalBoot (TR and TR+) and the TR+ extension image report the same FLASH, RAM1 and RAM2 numbers before and after.

Docs

• docs/TR_Block_Device.md: which image files mount, that error bytes are not read, and the 40-track D64's sectors per track.
• docs/Architecture/Disk-Images.md: d64_open_exact, and the block device as the engine's first caller.

Testing

• Source/Teensy/tests/trblock.test.js now runs the block device on a 40-track D64, and on a D64 and a D81 with error bytes, alongside the plain D64, D71 and D81. Truncated and padded files, the D81 with error bytes included, mount as no image.
• Source/Teensy/tests/disk-image.test.js checks that d64_open_exact takes only the sizes in the table, with or without error bytes, and nothing between them.
• npm test passes at this commit.
• Host build only, not hardware tested. A GEOS launch beside GeoRAM, or on the TR+ under REU+USB Mouse/Disk, goes through this path.

Compatibility

The C64-side contract in docs/TR_Block_Device.md doesn't change: INFO still reports 1 D64, 2 D71, 3 D81, and the status codes are as before. A 40-track D64 reports as a D64 with its larger block count. 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