I've got some good after-midnight Pacific Time news for you: hardware acceleration of lower resolutions is working!!! (Macrocell count: 137/144. Pushing it...)

This is a great result for slower-speed parts, since you can still get a usable resolution out of any VGA monitor you've got without forcing a "slide show" through 640x480 resolution.

Here are the stats for 8 bit color; bpS is 'bits per Screen'

• 640x480: 2,457,600 bpS
• 320x240: 614,400 bpS
• 160x120: 153,600 bpS
• 80x60: 38,400 bpS

So, if you only had 2 MHz SPI on your part, you were staring at .8 frames per second... but if you drop down to the hardware accelerated 160x120 you can now support 13!

Here's a quick snap of a desktop at 80*60, for the laughs and the proof (bonus: can you identify the single board computer at this puny resolution? I'll release a new Linux framebuffer driver drop after the VHDL is good!):

Pretty funny, eh? Well... I thought it was funny, anyway.

(Side note: everything is working beutifully in Linux; I can do my resolutions changes with 'fbset -fb /dev/<mine> -xres xxx -yres yyy' just fine. Props, too, for xserver dealing with 80x60...)

And the theory:

Rows are easy; for each drop in resolution, double the number of rows we 'loiter on'.

480 Rows = 1 Clock
240 Rows = 2 Clock
120 Rows = 4 Clocks
60 Rows  = 8 Clocks

Don't you love powers of two?

Columns are a little trickier - I had to find a way to skip ahead, but the 'loitering' part isn't that bad - for each drop in resolution, I shift the LSB. I'll write out the bits so you can see the pattern:

640 = 0000 0010 1000 0000
320 = 0000 0001 0100 0000
160 = 0000 0000 1010 0000
80  = 0000 0000 0101 0000

That beautiful shift is what allows us to force VGATonic to sit on a pixel fo a few clocks before shifting. I'll upload the VHDL soon, hopefully with color depth features added.

You know, if I can fit them into 7 macrocells.