Veronica gets VRAM and its own boot logo

[Quinn Dunki] just reported in on the latest iteration in her computer project which is called Veronica. This time she added RAM to increase the VGA performance of her build. Like just about every other part of the project, [Quinn] knew what she wanted to do, but had to overcome a lot of issues along the way.

The goal is to implement a 256×240 display with 8-bit color depth. [Quinn] says this is on par with game console technology from the 1980’s. The problem is that the 10MHz AVR controller can’t really keep up with the scan rate of this size of display. The answer is to add RAM which stores all of the color data, the microcontroller will simply advance the address pointer on the memory chips to match the sync rate of the VGA output.

After hooking up her hardware design she gets a screen full of uninitialized pixel data. But moving from there to the final product seen above was quite frustrating. It turns out that noise on the breadboard was most of the problem, further compounded by entire breadboard row which wasn’t contacting the wires to make the temporary connections. A bit of jockeying for position and by Jove, she’s got a boot screen.

Veronica’s color format is what I would call 2-bit color depth, or “6 bit true color” (as opposed to a palette-based color indirection system, as was also common in those days). It is perhaps most similar to the Apple //’s HiRes mode, although without the limits on which colors can coexist on adjacent pixels and such. The Woz pulled off some real voodoo to get the resolution he did in the memory he had, but there was a price to pay in flexibility.

I would describe Veronica’s color format as 2-bit color depth, or “6 bit true-color”. This would be as opposed to, say, the palette-based color indirection systems that were also popular in the 1970s and 1980s computers. Veronica’s system is probably most similar to the Apple //’s “Double HiRes” mode, but with a little more depth and without the restrictions on what colors can occupy adjacent pixels. Also, of course, the memory mapping is linear with no holes. The Woz did some amazing voodoo to get the resolution he did with the memory he had and such a low chip count, but there was a price paid in flexibility.

Sorry, I should have specified Apple //e and //c. Earlier Apple //s of course only had the HiRes and LoRes modes (pedant preemptive strike). The //gs’ Super HiRes mode was a revelation for those of us used to building jump tables just to draw a horizontal line. :)

This is much the same as the FPGA project I implemented last year: designing a 1980’s video game on a Spartan 3an. Essentially used two sets of dual port ram to implement a foreground and background set of sprites with a transparency applied to the foreground.

Oh man the burned out breadboard row :( That would indeed be frustrating. Any time test equipment gives false/dead readings, it can put a big rain cloud over the project. Kudos on pushing thru everything and getting your results, quinn! Keep it up :)

Why does she have to limit herself to 10MHz? All AVRs are specified up to 16, but in reality they easily can be overclocked to 20. And those specified up to 20 like mega*8, can do all 24 or maybe more.

A fair question! There are a number of reasons- any more than 10Mhz horizontal pixel frequency would require 16 bit horizontal addresses, which would be a real burden on the host 6502. Furthermore, I’m already set up for AVR development, and I just plain like them. The great thing about a hobby versus a job is that you can solve exactly the problem you want to. :)