Category: Veronica

Veronica – VGA Dev Board

Taking stock and making plans.

 

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:

I know, right?

 

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).

 

Back to basics. Pulse generator, VRAM, and basic code driving it all. From here, we can build once again.

 

Here’s what we’re going to move into a semi-permanent form. We can rebuild it! Better! Stronger! Exactly the same speed!

 

So long, ridiculous resistor blob. I’ll miss you, old friend.

 

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!

 

Here it is! I wired it all up in one go, since it’s really not that complex. In the middle there you can see my SRAM stack, with one of the decoupling caps straddling the top (the other one is under the board). I ended up with a few more big loopy wires than I intended. I could have laid this out smarter. In any case, it’s good enough for what I need.

 

Here we are on the underside. A bit hacky, but surely this will be more robust than the breadboards?

 

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:

 

Interesting! That’s actually pretty encouraging. Those are real pixels, and the monitor is locking to the signal. We should have an image though, not just horizontal stripes. Looks like we’ve got some noise, as well. The noise is confined to the top half of the screen, which suggests only one of the two SRAMs is having issues.

 

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:

 

Aha! So close, yet….

 

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.

 

Woohoo! Now we’re in business.

 

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.

 

My resistor blob DAC is all growed up! This one is a lot more reliable, but I don’t think it has as much charm.

Hot SRAM on SRAM action. Awww, yeah.  *bown*chikka*bown*bown*  We never claimed to be family-friendly here at Blondihacks.

 

Won’t someone think of the children?

 

 

Veronica