Two steps forward, one step back, and perhaps one sideways as well

Trying to track down why the C65 ROM was continually redrawing the startup banner, I discovered that part of the ROM in memory was wrong.  Either it was being corrupted, was being loaded incorrectly from the SD card, or the copy of the ROM on the SD card was corrupted.

It turns out that two of these had happened.

During some earlier testing of the DMAgic controller, it seems that a DMA happened that wrote to the SD card registers, resulting in at least one sector of the C65 ROM being overwritten with gibberish.

That was fairly easy to fix.  However, once it was done, the startup banner was not being displayed at all.

I hadn't changed anything else, so I knew it had to be something related to the ROM.

Some poking around confirmed that at least part of the ROM was still not being loaded correctly, and that it seemed to change behaviour if I deleted and recreated the ROM file so that it had different cluster numbers on the FAT file system.

So I wrote a little utility in C that replicates the FAT file system code in the kickstart ROM to make sure that that logic was okay.

That was fine.  So I wrote another utility that can read the memory out of the machine while running to see exactly what parts of the ROM were corrupt.

It turned out that $06A00-$06FFF and $16A00-$16FFF were consistently being loaded with the wrong contents, suggesting a reproducible file system bug.

The addresses affected were bizarre.  I managed to find the location on the SD card that was being loaded, and augmented the kickstart ROM to show the location of each sector being loaded.

The sector addresses were nicely incrementing by 512 ($200) bytes, until it reached $004FFE00, after which it advanced to $014F0000 instead of $00500000.  I had found my bug.

A quick patch to the "increment address of next sector" routine in the kickstart ROM did the trick (fortunately not requiring a 2hour FPGA rebuild to test).  The result was all the odd ROM misbehaviours I was seeing earlier disappeared. But some strange side-effects have popped up, as can be seen in the screen shot.  (I had to restrict the screen shot to the upper left so that the camera would get the exposure reasonable):

Two things in this image:

1. For the first time, I have the C65 ROM displaying a READY prompt! This is really good.  This is the two steps forward.

2. For some unknown reason, the colour RAM is being filled with $E6 instead of $06 for blue. $E6 has bold attribute is set, causing it to use palette entry $16 instead of $06, and that palette entry is black. This is weird, because it looks like the DMA to fill the screen is okay.

3. Starting with IRQs enabled, or enabling IRQs still causes major problems.  I need to keep debugging what is going on with the VIC-IV raster interrupt implementation, since that seems to be the source of the problem in one way or another.  It is a bit annoying to debug, because the raster interrupts are happening at 60Hz, which makes it tricky to see just what is going on. Until IRQs work, keyboard entry won't work.

So a bit of a mixed bag of progress.