Let's build a Vector VGA

pbozeman

Member

Donor 2024-2025
Joined
Apr 24, 2024
Messages
86
Reaction score
97
Location
Woodacre, California
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.
 
Last edited:
Cool beans ! The ICE40 is a pretty good FPGA and a great value part. I've got a couple of HX4K and HX8K dev boards for experimenting with.
 
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:

View attachment 778452

View attachment 778453


HX4K (single sided)

View attachment 778454

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.

View attachment 778455

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

View attachment 778456
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.)

View attachment 778457

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.
Nice work so far, I've had multiple people ask me to do a replacement for the vector VGA so I know the demand is there. Yes, the existing one is one bit per color and as such only supports 8 colors, it's a very annoying limitation I've run into multiple times, I would definitely recommend at LEAST 3 bit/color. I would also suggest if you are going to design something new consider having an HDMI output at either 720 or 1080p, VGA displays are getting harder to find. You're definitely going to need to support persistence and likely dimming vs just removing the pixels. Keep in mind the refresh rates depending on the game are more in the 38-42HZ range so having no persistence will likely cause some strange beating between the refresh rates. If you need more memory bandwidth consider a wider memory bus using multiple SRAMs or even SDRAMs.
 
Cool beans ! The ICE40 is a pretty good FPGA and a great value part. I've got a couple of HX4K and HX8K dev boards for experimenting with.
Oh hey! Are you the jrok from the jrok multi williams?! I making a long drive on Monday to pickup a multi-williams that has the (supposedly bad) Clay/ArcadeShop 20-in-1. Assuming that sale goes through, I'm going to be buying one of your boards to put in it!
 
Nice work so far, I've had multiple people ask me to do a replacement for the vector VGA so I know the demand is there. Yes, the existing one is one bit per color and as such only supports 8 colors, it's a very annoying limitation I've run into multiple times, I would definitely recommend at LEAST 3 bit/color. I would also suggest if you are going to design something new consider having an HDMI output at either 720 or 1080p, VGA displays are getting harder to find. You're definitely going to need to support persistence and likely dimming vs just removing the pixels. Keep in mind the refresh rates depending on the game are more in the 38-42HZ range so having no persistence will likely cause some strange beating between the refresh rates. If you need more memory bandwidth consider a wider memory bus using multiple SRAMs or even SDRAMs.
I'm kinda doing this just for fun and to learn, to be honest. My background is in software dev. About a year ago I barely knew what a pull up resistor was. But, if I can sell enough to recoup my costs and cover my hobby expenses, I'll be happy :)

As for persistence / more memory bw... that's kinda what I was alluding to with needing to interleave. I'll see when I get there.

As for HDMI, that might be doable. My understanding is that it's not that big of a deal if you go the DVI over HDMI route as there is less signaling/negotiation to have to manage and isn't that much different than just doing 1080p VGA. (I only briefly looked at that when I started.) That said, there are external VGA to HDMI adapters. Do you think onboard HDMI is necessary?

And regarding color.. do you have recommendations or thoughts about using an ADC for the color channels v.s. loading a pallet for each game?
 
As for persistence / more memory bw... that's kinda what I was alluding to with needing to interleave. I'll see when I get there.
I wasn't clear on how you were using the term "interleaving", maybe it's the same thing I was suggesting? When you need more memory bandwidth to do the processing you can widen out the memory bus and process MULTIPLE pixels in 1 clock cycle. One of the advantages of an FPGA is the fact you can parallel process things by duplicating hardware. I guess you could consider this interleaving across multiple processing blocks.
As for HDMI, that might be doable. My understanding is that it's not that big of a deal if you go the DVI over HDMI route as there is less signaling/negotiation to have to manage and isn't that much different than just doing 1080p VGA. (I only briefly looked at that when I started.) That said, there are external VGA to HDMI adapters. Do you think onboard HDMI is necessary?
Yes, DVI is simpler than HDMI if you are going to actually code the transmitter in the FPGA. HDMI has the added benefit of carrying audio with it. When I was considering this, having the ability to transmit audio to the display would be a useful addition. There's two very distinct applications for the product. One is to allow an LCD to be used in place of a vector CRT in an actual game/cabinet. The more interesting one, for me anyways, is as a bench tool for troubleshooting vector PCBs. It's really helpful to have a bench display that doesn't get damaged when the game board is malfunctioning. Something an ACTUAL vector CRT doesn't handle well. In this application being able to use the speakers in the display for the games sounds would be beneficial. (less hardware/wiring on the bench). Either way I DO think HDMI (or DVI) is an important feature, there are transmitter ASICs available that are not too costly that do most of the work for you. You just need to provide RGB in a digital format (something you have to do for the DAC anyways) and the device does the rest. You may have to code some I2C communications just to initialize the chip but that's pretty straightforward as well.
And regarding color.. do you have recommendations or thoughts about using an ADC for the color channels v.s. loading a pallet for each game?
The problem with "loading a pallet" is you still only have 3 bits per pixel which only allows 8 colors. The issues I've encountered are games that support more than 8 colors. I can't imagine ANY application where a pallet would be helpful when you only have 8 colors and they are selected by three 1 bit signals (R, G and B). The question in my mind (assuming you want to do something better than the current solution) is if you do a FULL 24 bit 3 channel ADC or just build your own 3 or 4 bit flash ADCs with comparators (possibly just using multiple digital inputs and a resistor ladder) to save costs.
 
The biggest issue with higher resolution is that you might have to consider handling wider beam widths and doing some anti-aliasing for a crisper image.
You'll need (low resolution ADCs) for the color channels since there's no real palette for the games and you wouldn't be able to access it from the RGBXY outputs even if there were.

It'd simplify things if you had access to VGGO and used that to double buffer and just display one frame while the other is being drawn -- then you wouldn't really have to emulate persistence/decay.
 
when choosing your color adc remember you need to sample the vector sparkles in major havoc id suggest 10msps or higher as the sparkles can reach 1.5mhz
 
I wasn't clear on how you were using the term "interleaving", maybe it's the same thing I was suggesting? When you need more memory bandwidth to do the processing you can widen out the memory bus and process MULTIPLE pixels in 1 clock cycle. One of the advantages of an FPGA is the fact you can parallel process things by duplicating hardware. I guess you could consider this interleaving across multiple processing blocks.

Ok, so we were talking about different things. Interleaving would be alternating between chips using different busses, i.e. odd pixels on chip 1 and even pixels on chip 2. I was thinking less about overall bandwidth, and more about the setup and hold times on the addr/data lines. Alternating chips allows for pipelining access.

Yes, DVI is simpler than HDMI if you are going to actually code the transmitter in the FPGA. HDMI has the added benefit of carrying audio with it. When I was considering this, having the ability to transmit audio to the display would be a useful addition. There's two very distinct applications for the product. One is to allow an LCD to be used in place of a vector CRT in an actual game/cabinet. The more interesting one, for me anyways, is as a bench tool for troubleshooting vector PCBs. It's really helpful to have a bench display that doesn't get damaged when the game board is malfunctioning. Something an ACTUAL vector CRT doesn't handle well. In this application being able to use the speakers in the display for the games sounds would be beneficial. (less hardware/wiring on the bench). Either way I DO think HDMI (or DVI) is an important feature, there are transmitter ASICs available that are not too costly that do most of the work for you. You just need to provide RGB in a digital format (something you have to do for the DAC anyways) and the device does the rest. You may have to code some I2C communications just to initialize the chip but that's pretty straightforward as well.

Ah. I'll think about this. I was planning on having something that plugged in place of the vector monitor. Sound isn't on that connector. If one were to do this with the color vectors you would need to plug into the output of the AR-II as well (or use some per game adapter between the main harness and the pcb)

And just to be clear, when I mentioned DVI, I meant just the video part of HDMI. My understanding is that there is a "simple HDMI" video signal that's basically the same as doing DVI, but still has a HDMI connector.

The problem with "loading a pallet" is you still only have 3 bits per pixel which only allows 8 colors. The issues I've encountered are games that support more than 8 colors. I can't imagine ANY application where a pallet would be helpful when you only have 8 colors and they are selected by three 1 bit signals (R, G and B). The question in my mind (assuming you want to do something better than the current solution) is if you do a FULL 24 bit 3 channel ADC or just build your own 3 or 4 bit flash ADCs with comparators (possibly just using multiple digital inputs and a resistor ladder) to save costs.

I was under the impression that the atari vector games used a single color. I'm really only deeply familiar with Tempest and other than this year at CAX, haven't played the others since the 80s. (And I haven't looked at their schematics either.) This comment + ArcadeJason's makes me realize that is wrong, and MH seems to use multiple values of each of the colors. All this pushes me towards an onboard ADC for the colors too.
 
It'd simplify things if you had access to VGGO and used that to double buffer and just display one frame while the other is being drawn -- then you wouldn't really have to emulate persistence/decay.

Ya. I'd have to run a line outside the standard connectors though, and I'd like this to be plug and play.

(It also isn't clear to me at what the relationship between VGGO and the final output vectors are. I thought it was more about the hand off for the memory shared between the cpu and the vector generator to hand off the vector commands, not the vector output itself... although, maybe this causes the signal to also be aligned with the final analog outputs too. I haven't looked into that at all.)
 
when choosing your color adc remember you need to sample the vector sparkles in major havoc id suggest 10msps or higher as the sparkles can reach 1.5mhz

So I'm trying to keep the component cost down so that the final product isn't stupid expensive like the previous Vector VGA. I believe I need to sample the colors at the same rate as X/Y or else things could get weird... maybe I'm wrong about that. But, if as someone mentioned earlier, 3 bits would be sufficient for each color (9-bit pixels), then an off the shelf ADC for each is going to be "pricy" and overkill as it's likely going to need to be a 50+ msps 8 bit adc and when I looked at those in the past, the cost was going to add up.

Do you all think I could get away with a DIY ADC for the colors? Something like this? Would this be decent enough quality?

adc.png

It would be 2 4x op amps and 1 priority encoder (plus passives) for each color. A quick digikey search shows that this would be less than a dollar per color, and the first priority encoder I found on digikey has a 16ns propagation time. That's plenty fast and has room to spare for the 50mhz clock I'm currently using on the x/y adc. I could add latches after the encoders and clock them along with the x/y outputs. (And sort out the differing propagation delays between the color and x/y in the fpga. I believe the adc I'm using for x/y has a 6 clock delay between input and output.)
 
Last edited:
So I'm trying to keep the component cost down so that the final product isn't stupid expensive like the previous Vector VGA. I believe I need to sample the colors at the same rate as X/Y or else things could get weird... maybe I'm wrong about that. But, if as someone mentioned earlier, 3 bits would be sufficient for each color (9-bit pixels), then an off the shelf ADC for each is going to be "pricy" and overkill as it's likely going to need to be a 50+ msps 8 bit adc and when I looked at those in the past, the cost was going to add up.

Do you all think I could get away with a DIY ADC for the colors? Something like this? Would this be decent enough quality?

View attachment 778535

It would be 2 4x op amps and 1 priority encoder (plus passives) for each color. A quick digikey search shows that this would be less than a dollar per color, and the first priority encoder I found on digikey has a 16ns propagation time. That's plenty fast and has room to spare for the 50mhz clock I'm currently using on the x/y adc. I could add latches after the encoders and clock them along with the x/y outputs. (And sort out the differing propagation delays between the color and x/y in the fpga. I believe the adc I'm using for x/y has a 6 clock delay between input and output.)
Since you likely have extra I/Os on the FPGA just put the priority encoder in it. That circuit is similar to what I was suggesting although you don't want to use op amps that way. You need high speed comparators. Op amps are subject to phase inversion when the inputs have a large differential voltage on them. They are designed for the + and - inputs to be VERY close voltage wise. They are also typically not very fast unless you choose very high GBW parts. Other than that, yes, that's what I was suggesting instead of an A/D conv.

RE DVI vs HDMI, yes you can supply DVI signaling on HDMI connectors. Most (if not all) displays will accept DVI on HDMI (connectors). There is actually a difference in how the video is encoded. Even though they both use TMDS, DVI doesn't have data islands which carry things like audio, info frames, AVMUTE flag etc. The TMDS symbols used for the SYNC are different on the two. Again almost every HDMI transmitter I've encountered will output either. If you are going to code the transmitter in the FPGA and use serdes for the output then DVI is definitely simpler. I would suggest using an ASSP HDMI transmitter to simplify the design.
 
Last edited:
Hit a significant milestone in that I'm actually displaying an image off a tempest pcb now. I expected it to look terrible, and it does :) But I was too excited about the possibility of seeing an actual display that I just hooked it up and went for it.

Since the last update I've been working on the verilog code for reading and writing to memory. There are 2 produces and 1 consumer. On the producer side there is 1) the incoming vector data an 2) the blanking/persistence update. On the consumer side, there is the frame buffer to vga signal reader. I spent what seemed like an inordinate amount of time getting that working while still meeting timing inside the fpga and also keeping up with the vga pixel clock. I originally, and mistakenly, thought that I was going to double buffer and flip between frame buffers. That actually makes no sense because this isn't like a computer that is generating frames, I just wasn't thinking clearly.

Instead, both producers and the consumer share a common frame buffer. I implemented a prioritized arbiter to the memory, and to meet the latency demands of the setup and hold times on the address lines, spread the addresses across 2 sram chips. I still need to think through/calculate how many I need for higher resolutions, but this bus arbiter/mux system will scale out fairly easily now.. and, I think I'm going to end up using the suggestion of having parallel chips each returning different parts of the pixel. So in the end, its going to be some NxM combo of N sets of addresses and M sets of data.

All that said, I might revisit how the arbitration and muxing work. I realized after I was mid way thorough this that it doesn't make sense for the 2 produces and the display to be all of equal priority. I should probably be aribrating/muxing the adc and the blanking down to 1 set of signals, and then arbitrating those with the display. That optimization/simplification is tbd.

The blanking right now is as simple as possible.. it doesn't fade, it just blanks as fast as it can. I just wanted to get something working. Once I was able to move the circle around by changing the offsets and amplitude on the signal generator, and it didn't leave images behind, I just yolo'd it and connected directly to Tempest. I just wanted to see something real!

As expected, it looks terrible. The resolution is still only 640x480, there's no pincushin adjustment, no anti aliasing, no sampling of RGB (so we see the retrace lines), and worst of all, the braindead blanking implementation makes it flicker so so so bad, as you (and I agreed) all said it would :) But, I was stoked to just see tempest up on the monitor.

What I didn't expect was that if I connect the X and Y to the right inputs, the screen is inverted horizontally. But, if I connect them to the opposite inputs (i.e. X to Y and Y to X), the screen looks correct, just in the wrong orientation. I haven't thought that through, but that seems weird to me.

I think I'm going to work on color next, using the circuit we discussed earlier in the thread. I'd like to see color and no retrace. I've already ordered the parts from digikey and I'm just going to breadboard it along side the PCB setup and feed it into the fpga from the pmod board that the vga is on. Then I'll get blanking to not suck, and then really think through the memory architecture to support higher resolutions.

IMG_1374.jpeg



IMG_1372.jpeg
 
What I didn't expect was that if I connect the X and Y to the right inputs, the screen is inverted horizontally. But, if I connect them to the opposite inputs (i.e. X to Y and Y to X), the screen looks correct, just in the wrong orientation. I haven't thought that through, but that seems weird to me.
I had the same issue with my Tempest on my Oscope the first time I hooked it up when I was bringing it up the first time after I got it home. That thread is HERE

D
 
I had the same issue with my Tempest on my Oscope the first time I hooked it up when I was bringing it up the first time after I got it home. That thread is HERE

D
I thought about this some more, and still don't get it. It would make more sense to me if X was always inverting, i.e. it would invert when I put it on the Y input... but it doesn't. When I swap the inputs to the X/Y terminals, I only get a mirror in one configuration, not the other. In any case, I moved the connections to the correct terminals and mirrored X across the Y axis in code.
 
Update: I decided to do the simple thing first and just use the color inputs I already had, rather than trying to breadboard up a dac and get it fed in via the pmod connections.

I didn't think about it originally, but just having black in the rgb colors wasn't enough to hide the movement lines. I didn't initially handle black as a blanking and was actually drawing the black lines on top of the color image. Once I fixed that, and implemented a first pass at some more intelligent fading of pixels, I ended up with the attached results. There's still a bunch more to do, but it's getting closer.

color.pngThe resolution is still very low (640x480), and the scaling is a bit weird, so the image is not so great.. but I'm a tad worried about little jaggies I get on the side of some of the lines. Hopefully these are just resolution artifacts and will go away at higher resolutions and/or with antialising.. but if not, then I might actually have some analog noise that I need to squash. If after the rest of the work that's where I'm at, I'll likely need to consult with someone better analog pcb design, because I have none. (My hookup to the PCB is also garbage.. in that I'm just using those little clips, and all the signals are sharing a single return path ground. The actual wiring harness for the monitor uses twisted pair for these for signal integrity, and each signal has it's own ground. I have no idea how much that matters, or if it's contributing to the issue, but I have the hookups on the board for it, but I ran out of grabbers)
 
Back
Top Bottom