So, I've been wracking my brains trying to come up with a fast way of clocking video data out of a low-end micro without tying up the CPU overmuch.

I was reading up about SPI, as I remembered that was the port Sprite was using on the SE/ARM to direct-drive the Mac's 1-bit video. And about DMA, as that is pretty much all about getting bits in and out of the micro with minimal CPU intervention.

Every micro under the sun seems to have SPI, and all but the very cheapest seem to have at least one or two DMA channels: the Cypress PSoCs for example allow DMA between any port and any internal logic block and in between and vice versa and so forth.

I can't find the relevant piece to quote here, but I recall Gorgonops mentioning that Sprite's SE/ARM (LCP ARM running a b&w compact Mac CRT, acting as an external GPU for another ARM via USB) only achieved four frames per second. Having read this though:

{SPI clock} frequencies are commonly in the range of 1–100 MHz. {*}

Click to expand...

I thought to myself, huh? That should be plenty fast enough to drive a compact Mac CRT, so what's the glitch here? 

* Yes, I know "clock" =/= bps

I went over to have a closer read of that part of his project, this being the most relevant section (my emphasis added):

I also had some speed issues. The LPC has no problem pushing the pixels to the display quickly enough thanks to the SPI controller I used, and even with the tedious task of fetching the data from the external RAM first, it ran just fine. Problems started appearing when I wanted to implement the USB-interface to actually make the Dockstar write to display RAM: The ARM still had enough power to actually perform the tasks, but I ran into timing issues. Basically, I couldn't handle the USB-transfers quickly enough to be done before I had to write another line to the CRT, thereby throwing off the timings and introducing many ugly glitches in the image. I solved that my creating a routine estimating the time I had left before I had to write another line, and only processing as many bytes as I could do in that time. The disadvantage was that a routine like that introduces a lot of overhead in switching over the DRAM; in the end I could only upload about 4 full frames per second to the GPU. Luckily, implementing RLE acceleration was already planned from the start, making me only hit the 4FPS worst-case-scenario when the complete screen had to be redrawn.

Click to expand...

So, thoughts:

It seems a bit like by introducing a second device to act as a GPU, he's actually made this more complex than it needed to be. Now, I get that his desire was to offload video wrangling from the Dockstar, so it could just get on with the task of running smoothly as a server.

But, if that's not your desire, hijacking an SPI output pin from the main device to drive 1-bit video directly seems like a much less clunky approach that should in theory be fast enough to smoothly update a screen - especially if you can drive the SPI from DMA. Ditching the external SRAM (or not using it for video) and using a micro with enough on-die RAM that you can reserve 171 kbits/21kB for video (512*342) should speed things up too, neh?

Going for a smaller screen rez is also an option: QVGA (320x240) LCDs are common, and require only 9.6kB of RAM @1bpp. Alternatively, I *think* you should be able to make the bit width of the Mac screen any arbitrary size without any hardware mods, as it's just pulses to drive the level of the electron gun up and down. 480x342 for example, or 480x320 (half-VGA) with a few blank lines. Even if that's not possible, a smaller screen could be displayed within the 512x342 by just padding it out with zeros at either end.

NB: altering the vertical linecount of the Mac screen is basically not doable.

Alternatively, I wonder why he didn't link the two devices directly via SPI rather than via USB, with all its issues.

One tidbit in particular from the SPI article on wikipedia caught my eye:

Arbitrary choice of message size, content, and purpose

Click to expand...

So (and other text on the SE/ARM sort of implies this might have been Sprite's approach), it seems like it should be possible for the micro to do the following:

• Set SPI clock to Mac CRT scan rate *
  Initiate SPI transfer at the start of each scanline
  Order DMA controller to begin transfer of 512 bits from location Y

And you're done.

* independently of CPU master clock, unless I'm reading everything wrong