I wanted to rush and get this checkbox checked tonight - I've got very basic 'Hardware Acceleration' working in VGATonic!
The quotes? Just to protect me from your arguments on the definition of 'acceleration' - we literally picked fruit from the lowest possible branches on this one. And, yes, it's a subtle feature anyway - I'll prove it not with a screenshot but with the code:
WRITE_ROW <= '0' & -- 9 ( WRITE_DATA(7) and WRITE_DATA(6) ) & -- 8 ( WRITE_DATA(7) and (not WRITE_DATA(6))) & -- 7 '1' & -- 6 '1' & -- 5 ( WRITE_DATA(7) xor WRITE_DATA(6) ) & -- 4 ( WRITE_DATA(6) ) & -- 3 "000"; -- 2, 1, 0
Catch that? (bonus if you catch the wrong math - will be fixed, but after midnight PST, haha!).
That's right - all we're doing is letting the control bit move where we are writing to the framebuffer. With 2 bits, we can divide the screen into quarters (for tonight that was the goal: I only wanted 2 bits - if you move to 3 bits, 80x60 resolution won't divide evenly into 8s!). This presents a very, again, subtle improvement in some cases - say, moving the mouse near the bottom of the screen.
Previously, you were blasting an entire framebuffer every screen write, even if the top of the screen was static (say... a menubar?). That means the old math applied - if your bottom right pixel updated, you were doing 2.5 million transfers (for 640x480x8bpp). At 32 MHz, say, on an Odroid C1... that's 13 frames a second. Now you're doing 1/4 the transfers, which means your throughput can be 52 frames per second for many refreshes.
Remember I joked about Doom not being a good idea at 25 frames per second? It's a bit better at 100* - considering you're now outrunning the VGA refresh rate of 60 Hz on a Raspberry Pi refreshing 1/4 of a screen.
*(Of course, video games tend to redraw screens a bit more than your desktop or TV Tropes binge).
Okay, I'll post my status report in a few minutes here.