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 ClocksDon'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 0000That 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.