Sometimes, in order to move forward, you have to take a step back. When last we met Veronica, she had a VGA signal generator cranking out sync pulses, and dumping pixels from a 256×240 resolution frame buffer built from a pair of 32k SRAMs. So far so good, right? All we need now is to interface with Veronica’s bus and we’re done, right?
Well, not so fast. Actually, that’s a funny choice of words, because speed is in fact the problem. So far I’ve been developing this video board all on solderless breadboards, and it’s been going pretty well, despite some fairly constant battles with noise. When it came time to add glue logic between Veronica and this video board, two things happened. First, I ran out of breadboards. Second, the noise simply overwhelmed my attempts to develop and debug the glue logic. After banging my head on this for a while, I decided I’m going about this the wrong way. I can’t continue to run this sub-system from a breadboard and have any hope of debugging it.
This became even more clear when I unpacked Veronica following the move to new space. Here’s how I had left the video system:
Yes, that plastic disaster runs at 20 MHz, kids. This is a perfect example of, “I didn’t know enough to know it shouldn’t work, so I just did it”. Some of human history’s greatest achievements have come from that kind of rebellious can-do attitude. Of course, so have most colossal failures. This is somewhere in between.
In any case, this was unsustainable and I couldn’t make forward progress through all the signal noise and erratic behaviour I started to get. As surprisingly well as my VGA generator worked, the glue logic pushed it over the edge. I decided that what I needed was a “VGA dev board” of sorts. I needed a reliable, stable platform that was the core of the video board, with which I could experiment and test the interface to the main Veronica system.
I started by stripping down what you see above into just the core video system (sync pulse generator and VRAM). I was throwing away all the glue logic and a lot of code that I had developed since last time, but honestly it was no great loss. I need a fresh start on this problem anyway. I decided to take a subset of my video board and move it onto a real PCB. It’s not worth etching something, so I’m just going to throw it up on protoboard, taking care to make it noise-resistant and suitable for 20Mhz (as much as I can, anyway).
Alrighty, fast foward a couple of hours, and here’s the same circuit. I tried to keep all the high-speed lines as short and straight as possible. I also wanted to eliminate one of my SRAMs, to get the chip count down. Unfortunately, 64K SRAMs are kinda hard to come by in DIP form, and I only have 32k ones. Until I can get my hands on a 64k chip, I opted to try a really old-school technique- piggy-backing the chips. Every single pin on the two SRAMs is actually connected into the circuit in the same places, except the Chip Select line. So, you can actually just stack the chips on top of each other, and bend that one /CS pin out of the way to be routed manually. This eliminates a lot of wiring and thus should be more resistant to noise. It was also fun to try!
Okay, with the circuit assembled, it’s time to give it a go! After a thorough visual inspection for flaws and some basic meter-testing for shorts, here’s what the first power-up netted me:
It took no time at all to realize my mistake here. As part of rebuilding the circuit, I decided to swap the PORTC and PORTD buses on the AVR chip. For some reason, I was using PORTC as my VRAM data bus on the breadboard, but that makes no topological sense, because PORTA and PORTC are adacent on the chip. They should form the address bus, and PORTD (which is by itself) should be data. I swapped the buses on the board, but neglected to modify the AVR code to match. So what we’re seeing on the screen is the result of using the data lines as the most-significant byte of the VRAM address bus. Hah!
So, with the code corrected, my second power-up brought this to my screen:
A cursory glance at this, and it’s pretty obvious I’ve bungled the color data lines. In fact, I reversed them all, as you can tell if you remember your RGB color wheel. So, warm up the soldering iron again, reverse all the data lines, and remind myself to be more careful.
Also, you may notice the noise is gone. This was simply a matter of needing a better power supply. I was running my protoboard directly from my bench supply, which seems to be a little noisy. I ran it through JuiceBridge, and the noise went away. Not bad!
If you look closely, you can also see that the edges of the letters are a little furry. This was an issue with my horizontal pixel clock timing. A little massaging of the code (moving some NOPs around) cleaned that up.
It was a few hours work to basically get back to the same place I was, but now I can start to make progress again. Sometimes a project can get caught in a local maxima, and you have to kick it in the family jewels to get out. That was a tortured metaphor, but I think you catch my drift. Now, hopefully I can get back to interfacing Veronica with this beast.
I’ll leave you with a few parting shots from the old macro lens.
Won’t someone think of the children?