First, I modified the kickstart ROM so that it looks for a file calles C65GS.D81 on the SD card. If present, and if the file is the right length, and contiguous on the SD card, it loads the starting sector into special registers at $D68C-$D68F that the floppy controller uses as a base address for disk accesses. It then sets some flags in $D68B to indicate that a disk is present and writable.
This is what the startup process looks like now. In this case, after finding and mounting the 1581 disk image, we see the ROM has already been loaded, as it passes the checksum test, and so doesn't need reloading. One day I will seriously pretty up the appearance of the kickstart ROM.
This made it much easier to debug the floppy controller, because it would boot up with a real disk image "in the drive". In C65 mode this gives the yellow border because the disk image lacks a C65 auto run file. In C64 mode, it means I can do a good old LOAD"$",8 (well, LOAD"$ since it is the C65's C64-mode kernel), and see what I get.
As you can see, I can get some partly sensible output from it. With a bit of fiddling, I can see part of a directory listing.
The directory header, not shown here, is messed up, and any program I load seems to be messed up as well.
I think what is probably happening here is that the ROM expects the SWAP flag of the FDC to work, which switches the two halves of a physical 512-byte sector in the buffer. This is used when accessing an odd numbered logical 256-byte sector on a track, which really lives in the upper half of a 512-byte physical sector.
It seems likely that with the SWAP flag implemented, I will be able to LOAD and RUN programs from the internal drive.
This will make further testing easier, as I can have a D81 file with all the CPU and other tests in place, and able to run with a shift-RUN-STOP in C64 mode.
That in turn should help me track down whatever the bug is that is stopping C65-mode from interpreting commands typed into BASIC.