We have a new proto board. I'm still waiting on my copy, but Delicon did some work on it over the weekend and I'm happy to announce that we've managed to reach the necessary timing constraint of 4 cycles between all queue reads.

Just to review, we had a hell of a time getting the ARM to be able to access the SRAM quickly through the CPLD. This was potentially going to make the queues in SRAM unusable if you couldn't sequentially read them. Now you can do something like this safely:

LDA QUEUE_0

LDY QUEUE_1

LDX QUEUE_2

This will provide maximum flexibility and speed boost in the kernel.

It also looks like we should provide some flexibility in how big the queues can be. It's a little complicated how that works but when we get to the point of writing technical docs I'll go into more detail.

We're still worried about the amount of time the ARM requires to seek a queue. This would be done during VBLANK. You'd normally want to set the starting index of the queue between frames. When you are doing this one at a time, there is already some natural padding by virtue of the Supercharger write method. But we also have "Seek groups" which let you seek batches of queues at once. This is important when you, let's say, have a bunch of queues represeting an entire playfield and its color changes. But this might tie up the ARM long enough as to prevent the VCS from doing enough other things with it during VBLANK. It can still do VCS-specific things in parallel, however. It's just that there are enough ARM features that in the end developers may have to pick and choose how much they want to use before it runs out of time during VBLANK to do them.

So he's looking into faster ways to write to the hotspots and more optimization to reduce the delay in queue seeking.