What it is
The D64 GoDrive lets the 6502 load programs from a .d64
disk image. These images live on a second SD card (the
sd2_* data disk, FAT32-formatted); the first card with the ROM loader is
untouched. The trick: all FAT32 and D64 parsing happens in FPGA logic. The 6502 only ever sees
plain 256-byte sectors and never has to parse FAT32.
What it does
From EhBASIC, the drive is operated with familiar commands:
| Command | Effect |
|---|---|
| LOAD "!" | Interactive arrow-key menu of all .d64 images |
| LOAD "$" | List the directory of the mounted image |
| LOAD "NAME" | Load a program (printing its CALL address) |
| CALL <addr> | Run the loaded program |
Structure in logic
Four RTL layers under rtl/core/peripherals/ work together:
- d64_sector_map.vhd — combinational D64 track/sector → linear index conversion.
- d64_drive.vhd — read-only sector engine: mount metadata, T/S→LBA, 512→256 half-sector capture, 256-byte buffer.
- fat32_reader.vhd — autodetects MBR or superfloppy, parses the BPB, scans the root
directory for the first
.D64and checks FAT chain contiguity. - d64_subsystem.vhd — the 6502 register interface at
$8824that wraps both engines and arbitrates the single SD read channel.
Robust against real SD cards
Windows-formatted SD cards are often superfloppy (no MBR, BPB at LBA 0) with
large geometry, and contain entries such as System Volume Information,
long-filename entries or a deleted .D64 before the wanted file. The reader
handles all of these. Verified on a real 32 GB card: mount the image, read the BAM, list the
directory and load a program into the correct address range.
Tooling
Under tools/d64/ sit Python tools that use the same sector mapping as the
hardware: create images (create_test_d64.py), list them, extract programs
and build FAT32 card images for simulation.