Rich Talbot-Watkins wrote:
So Rob, when are we going to see a video of this in action then?
I'll try to put something up tonight. I've put in a fast whole-row transfer and have been using the border to watch how much of the frame is taken up with each type of video update. It's much better than it was but still not quick enough to keep up when the screen is scrolling.
Loads are all LDA &abs and, if the data is all prepared first, there's no waiting for the parasite so anything >4 cycles should be computed on the Pi. (This also means that there's no point in soft-copying a scrolling screen using a back buffer on the host.)
The killers are the stores as I'm pretty much forced to use STA (scraddr),Y and I'm storing 8x the attribute data. I've done a reasonable amount of unrolling in the whole-row transfer and am going to look if I can do something similar (using self-modifying code) for the shorter transfers.
The ideal would be to be able to do LDA #immediate, STA &abs. At the Leicester ABUG, cmorley mentioned using the TUBE registers as a code buffer with the peripheral/parasite writing code in to them on the fly. I've only just remembered this, and it would need changes to the PiTubeDirect code, but I might look into it at some point!
The other thing I need to sort out is a timer to action border and sound updates at the correct point in the frame.
jgharston wrote:Also, I've lost track, what's the byte arrangement in screen memory when set up for Spectrum-style display? Using MODE 0 as the base suggests the Spectrum 1bpp display bitmap is mapped directly onto some of the BBC 1bpp display bitmap, but how are the attribute bytes mapped?
There's nowhere near enough room in the CPLD to hold all the attributes for a row/line so each attribute byte operates on just 8 pixels and is sent immediately before the pixels it operates on. So, 0x3000 contains the first attribute byte and 0x3008 contains the corresponding pixels etc.