Museum of the Game® & International Arcade Museum® Forums

About 5 months ago I started working on a Vector VGA replacement. I'm still many months away from being done, but I'm at a point where I have something to show. Inspired by DirtyMcDingus's "Let's design some POKEY replacements" thread, I decided to post progress so far. It's likely that as I get into the final phases of this that I could use some help, and thought it would be best to start sharing context early.

My eventual goal for this is to produce and sell a vector to vga adapter board, but I am also making this an open hardware and open source design. Right now, everything lives in a mono repo containing both the hardware designs and firmware at https://github.com/pbozeman/vanilla-ice40

I'm trying to keep this as cheap as possible, so I'm designing around a Lattice ICE FPGA as it's the cheapest FPGA with a lot of IO pins. It's possible that I'll be able to reduce the pin count low enough to use an HX4K TQFP package, but for now, I'm using an HX8K BGA. If this can be one on the HX4K, the board can be reduced to 4 layers and be single sided. These can be produced very cheaply, and even hand assembled. (I've personally hand assembled and soldered an HX4K dev board, and I suck at soldering.) If the HX8K is needed, then it will be a double sided 6 layer PCB.

Here is the approach I have taken, and where I'm at so far.

I've been taking a modular approach to the design, with each major component on it's own PCB, and mezzanine connectors to connect boards together. Unusued pins one one board pass through to another mezzanine connector, so boards can be daisy chained. My daughter calls it, "the snake."

While the final product will be a single PCB, this let's me build and iterate the design in sections, without having to re-assemble the entire board on every iteration.

There were no existing ICE 40 dev boards that exposed all the IO pins I needed. So, I started with the dev board. I have both HX4K and HX8K dev boards. These have onboard FTDI programmers, firmware flash, and 100 MHz oscillators. Every IO pin is broken out and passed to the mezzanine connectors.

HX8K front and back:

IMG_1333.jpeg

IMG_1335.jpeg


HX4K (single sided)

IMG_1336.jpeg

I have SRAM dev boards that can attach via the mezzanine connectors. These are 10ns SRAM and will be fast enough to support the pixel clock for a 1024x768 image.

IMG_1338.jpeg

I have an ADC board with a 65Msps dual 10-bit ADC, and 2 op amps to convert the X/Y signals into differential signals in range for the ADC. There is an onboard 50Mhz oscillator, and I can configure if I want the ADC to use it or a line from the FPGA. I haven't decided which configuration I want to use yet. I might also decide to build a final design around a single oscillator that the FPGA and ADC can share (and use a PLL to boost the internal FPGA clock.)

IMG_1337.jpeg
So where is all this at:

Here is an end-to-end test, driving the X and Y inputs from a signal generator. I'm feeding 2 sin waves offset by 90*, which, of course, renders as a circle. There is no clearing of old samples, so the circle is just drawing over itself every time. If I were to try to connect this to a real game PCB at this point, the screen would just fill up. I'm also not sampling colors yet and hardcoded the color to white. . (I haven't even populated the color test/injection points on the board.)

IMG_1332.jpeg

Next steps:

Support multiple resolutions: right now the output can only do 640x480@60hz. I want to add 1024x768 support. (Note: the original Vector VGA can only do 800x600)

Image position: the incoming signal is from 0 to 1024. Since that's substantially bigger than 640x480, so I'm crudely scaling it down. Both center the image and scale it correctly.

Color: sample the RGB lines to set the pixel color. Note: like the original, I'm currently only bringing in 1 bit of input per color. I was surprised to see that this is how the Vector VGA product worked. It implies that colors won't be correct from game to game if the games are actually producing slightly different RGB voltages. To get color right on different games, I will either add a color ADC (more expensive BOM), or provide the ability to load a color palette. How this is done will affect the number of bits per pixel I'm using in ram. Right now, I'm using 12 bits, which is obviously ridiculous if there is only 1 bit of incoming data per channel.

Persistence/fade: implement fading of pixels. I plan to use extra bits in memory to track what frame a pixel was sampled on. If rendering is more than some number of samples away, the pixel won't be shown. This might only need 1 frame, or it might need a few. I will experiment with how long to leave them on, and if they just disappear or dim out.

SRAM at higher pixel clocks: the higher res pixel clocks are fast enough that a single SRAM can't support both reads and writes into the same frame buffer. I either need to double buffer, or interleave them. How persistence works will have an impact on how this is done. (I have a double buffering POC of a test pattern, as I originally thought I was going to be double bufering, with alternating sampling into one sram and displaying out of the other. If 1 frame of persistence is fine, then double buffering will be the way to go. If more frames of persistence are needed, then I'll likely need to interleave.) I haven't thought this through fully yet.

Pin cushion removal: the image from a real PCB is going to be distorted on a VGA monitor because the original PCB is doing pin cushion correction for the curve of the vector monitor. This needs to be removed before going to a VGA monitor.

In any case, I feel like reaching a milestone of having XY input, using voltages expected from an Atari vector pcb, entering the ADC and displaying on a VGA screen was a big one. It means that my hardware design is largely working and I just need to move forward with the firmware/software side of things.
Back
Top Bottom