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

Click to expand...

So, it's not a bad idea at all. There are a few... semi-gotchyas:

1: Obviously it assumes that you're able to set the SPI speed to exactly the desired pixel clock. How trivially you can do that with a given MCU undoubtedly varies. (It may depend on you using an external clock crystal of an odd frequency so the dividers the hardware offers are appropriate.

2: You'll need a couple GPIO pins and some tightly-coded timing loops to generate the horizontal and vertical sync pulses. Not a huge problem certainly, but the video generation still won't be as "set and forget" as you might like.

3: The last bit. I hesitate to speak "authoritatively" on this point, but... the SPI protocol has "built in" to it the insertion of additional "0" bits in between data bytes. Which means that you can't just get a clean pixel stream out of it; you'll have a bit stuck on every 9th pixel. Here's someone complaining about that.

Note that the thread calls out the solution: at least some microcontrollers use hardware called a USART to accelerate serial bitstreams (including SPI), and if your chosen hardware supports using the USART in "Raw" mode without the SPI overhead you're still okay.

(And in fact, using the USART for this purpose is apparently fairly common for "toy" MCU video setups. Honestly I'd be sort of surprised if Sprite wasn't using a USART for the pixel clocking on his hardware setup... in fact, he says "The LPC1343 had almost everything I needed: enough flash to store a large program in, USB for the connection to the Dockstar, hardware timers to make the timing to the CRT easier and a SPI-port I could abuse to output pixels to the display without too much CPU overhead."... I'm sure by "SPI" he's actually using it in RAW USART mode.)

I suspect the real problem with his design achieving better than the "4FPS" raw framerate is the software overhead from driving the external RAM chip. An MCU that had enough onboard RAM to hold the framebuffer might well do much to solve that problem.