6502.org

Been trying to get VGA working and thought I'd share some photos.

Right now I have a ATF1502 generating the horizontal and vertical counts and sync pulses, and this seems to be working reasonably well enough, though periodically the picture blanks out, however the monitor doesn't indicate it has lost signal. I suspect right now the OE# of my 74HC574 is slightly off from the blanking signals causing the monitor to see some output from the picture before the '574 releases the circuit.

Here's some photos:

That could be an issue, however I've never had such problems with the ATF15xx parts with my CMOS logic before. VGA uses TTL logic for the vertical and horizontal sync levels, so that should be fine.
I'll look into finding an AHCT part; however, I think I was spot on. The signal I was generating to enable the output of the '574 was being inverted by a 74HC86, but the sync pulses were not being delayed; by placing both on the '86, that seems to have cleared up that issue for now.

Here I was able to get it to dump the contents of uninitialized SRAM in an 8-color mode:

Nice work!

I've found placing 47 Ohm resistors on the sync lines has fixed intermittent sync issues, causing the monitor periodically flicker. Any ringing on those lines can cause the monitor to misinterpret the signal as additional unwanted sync pulses.

Regarding synchronising the timing of sync signals with data signals, I have found that it can be an issue if the latency of your circuit between your clock and the monitor is different for the two signal paths, though most monitors still seem to do fine at automatically adjusting their timing based on the signal if you give them a good enough reference pattern to adjust to. I'm pretty sure old-fashioned CRT monitors wouldn't have cared about this at all of course, as they didn't need to discretely sample the pixel data.

Passing the HSYNC and VSYNC through a final stage of D flipflops, along with the final digital data signals, has always seemed to me like the right thing to do, as then they change in sync with the data, and the only step left for the data signals is digital-to-analogue conversion. This way it doesn't matter if there's quite a lot of latency from your counters through your video RAM and perhaps a palette lookup as well - so long as it all fits within one pixel, it gets synchronised back to the VGA clock at the end, and the sync signals are also then delayed by the same amount of time so it all matches up before going down the cable.

Similarly if you're dividing the clock down and outputting multiple pixels per memory read, if you have something like a palette lookup after your shift registers then you may again benefit from resynchronising the sync signals to change at the same time as the digital output from the palette, by running them all through another set of flipflops.

Again though, monitors are generally pretty good at dealing with minor timing offsets, so long as they are consistent.

You can also just pull down the data lines to the monitor for blanking and do this in sync with the clock as well (i.e. generate a blanking signal, and run that and the HSYNC and VSYNC signals through D flip-flops to change then in sync with the clock, and use the blanking signal to drive the bases of NPN transistors (or the gates of N-channel MOSFETs) that pull the R,G,B output lines to ground on the far sides of your series resistors) - this ensures that signals are definitely blanked where they ought to be, but I found it is then quite hard to avoid clipping the edges of the first and/or last pixels of each scanline. Doing the blanking earlier on, before the DAC, leads to much better results.

I've hooked up a ROM (AT28C64B) as a character font and got that displaying some characters: As you can see the characters are slightly offset, and I'm again having some syncing issues now that I've changed out the D-flip flop for a parallel to serial register; and once again I'm having some syncing issues. I'm sure a lot of this is due to timing issues that I need to figure out, but other than dropping out periodically the image is very stable, much more so than I had expected.

Current circuit below (be warned, this is very much a work in progress, so a lot of stuff isn't connected correctly or might not even make sense): And here's the current working font if anyone is curious, based somewhat on the C64 font, but I've made a number of changes: I will give that a shot thanks!
Probably so, I'm sure a lot of those older CRTs had a lot of slop in the lines back when VGA was still considered cutting edge. Once monitor resolutions got higher and higher I'm betting those tolerances tightened up.
One idea I had was to have the sync signals travel down a shift register as different stages of the video processing pipeline (such as it is) would end up getting spit out once the pixels are ready. To the monitor it would see the sync signals at the right times despite however long (provided it's within a pixel as you put it) it takes to get there.

I will be putting the D-flipflop back in shortly, mostly so I can get some color support which will do some DAC look ups.
I thought about adding some NPNs to ensure it's completely pulled to ground, haven't done that yet. Also I tend to notice a bit of noise in the brightness of the pixels. Not sure if I need a filter cap or something to sort that out, but it's very minor and not worth the effort just yet to fix.
And this is what happens when you feed your ICs a steady diet of free electrons.

For initial testing of colour graphics circuits I usually connect one colour's high bit to H0 and maybe H2 or H3 on a lower bit for that colour; and another colour connects to V0 and maybe V2 or V3, and the third colour connects to my blanking signal, giving overall a kind of tartan pattern that makes it easy to see what's going on at the edges of the screen - you can see by eye whether the left/right/top/bottom pixel rows and columns are the same width as the others, and count the repetitions of the secondary lines to check the overall resolution is what you expected - it's easy to have 1/2/4/8 pixels missing from one edge or the other if you get the blanking wrong, and sometimes I've gone ahead for ages without realising I'd done this!

If you're using shift registers e.g. for text output then you can instead just connect the bottom few bits of each of the H and V counters to some of the shift register inputs - bypassing any character ROM - to get a really distinctive binary counting pattern that lets you spot if you're missing pixels or even characters at the edge of the display area. I also tweak the monitor settings back and forth so that I can see the edges of the area that it's receiving when checking these things.

For the flickering though, maybe you could post a video that shows it, so we can see it? I do think that what J64C and BDD were saying is probably true if you're seeing flickering - something is wrong with the sync signals, maybe not all of the time. In my experience modern monitors are more fussy about the consistency than the specific timing. I always try carefully to get the official timing but it doesn't seem to matter much in practice - but if you get a random spike on one of the sync signals mid-frame then it can cause a lot of glitching.

I would look at them on an oscilloscope (on the far side of your series resistor) and check firstly that the timing is what you expect, then see if you're getting at least let's say 3.3V when they're high, how stable that signal is, what the rise/fall times are like when loaded - these should be less than a pixel - and whether there are any obvious reflection effects. The load at the other end of the monitor cable should be high impedance, so it shouldn't draw much current in the steady state, but during switching I wonder if it is drawing more current than the ATF1502 is capable of providing, leading to slow switching times which might upset the monitor. (I don't know the device but the datasheet seems to give a maximum figure in microamps - not milliamps - for a high output to achieve 3.1V.)

FWIW though I have driven VGA sync signals directly from ATF16V8Bs without problems, so if they have similar drive capabilities then I'd have thought yours would be fine too. But it might depend on the monitor cable, and also the ATF1502 is more complex and may be more sensitive to things like drops in VCC caused by excessive current draw from its output pins. Buffering them through an external flipflop register would be an easy way to ease that burden.

I have plenty of designs driving VGA signals directly with CPLD (Altera EPM7xxx) without drive issues, in fact, I’ve driven the three RED, BLUE, GREEN signals with one CPLD output because I’ve ran out of I/O pins. Yes, the screen is not 100% bright, but perfectly readable. ATF150x should have same or better drive spec as Altera EPM7xxx.
I also wonder about the external logic. ATF1502 with 32 macrocells should be able to generate horizontal, vertical syncs and shift register for shifting pixels. So external buffers should not be necessary. In case the logic won’t fit, ATF1504 has same pin out as ATF1502, so that’ll give you twice the number of macrocells.
Bill

What polarity do you have for your hSync and vSync?

I have seen people swear by Ben Eater a being the perfect source in his video, but even he made a few errors in his “Worlds worst GPU” video. The big one being the incorrect polarity of the sync pulses, even though he has the sheet right in front of him when he makes the error.

This is often the source of the issue where people often say “it works perfect on this screen but not on that one”. Some screens are more tolerant than others.

Side note: it's probably down to the change in technology between CRTs and LCD (and similar, like OLED) screens.

All a CRT display has to do is detect the sync pulses and restart the appropriate scan, something easily done with a handful of analogue components (later, sync detector chips became more common, but the whole video signal was intentionally designed to make building displays as inexpensive as possible). Displaying the actual video was simply a question of driving the display tube base with the amplified video signal(s) and the resolution available was a question of the frequency response of the entire system. As the default was to use TVs in home computer displays, with the initial digital signal being modulated onto RF, then demodulated in the TV before display, the theoretical bandwidth in the signal chain is a touch over 5MHz. Which would give a theoretical 5 lines per microsecond, so around 260 lines per horizontal scan, for a dot clock of around 10MHz. Which you never saw... because the colour burst filters at around 3.5MHz would eat most of that signal. So it's really convenient to have a dot clock of 5MHz, thus a maximum frequency of 2.5MHz, and around 250 pixels per line.

Equally, the simple video circuits didn't generate the half-lines required to create an interlaced display with full vertical resolution of 475 or 575 line (NTSC/PAL) so you would see around 200 to 256 vertical lines.

But the actual timing of the video to the sync pulses is immaterial, provided your picture doesn't overlap the sync pulses. The image will shift, but it will be stable as long as the sync pulses can be isolated by the display.

When you get to fixed pixel displays, you have a problem. Syncs are now (almost) always carried separately rather than as part of a composite signal, so they're easy to isolate, and their frequency and polarity informs the display of the resolution of the video signal. The snag is, what do you do with an image which has fewer pixels than the display can show? If you want to show your 640x480 VGA image on a 1920x1200 display, people are likely to complain if you just stuff it in the middle of the screen. The image and the screen don't even have the same aspect ratio: 4:3 vs 8:5 (and that might be physically 9:5).

So you stretch it to display it. Vertical is easy. The display has 2.5 vertical lines per single line of signal. You can share two input lines between five output lines; the simplest way is to use two lines for even input lines and three lines for odd, though that will show jaggies on diagonal lines. More complex algorithms are available, and easy to implement in hardware if you have a delay memory. Horizontal is no more tricky. If you want to maintain your aspect ratio, you do the same tricks as you did vertically to share the pixels, 2.5 output pixels to 1 input and fill the edges with black. Or if you want to fill the screen, probably a more common requirement irrespective of the picture distortion, 3 pixels per input pixel.

But the timing between the horizontal sync pulse and the video signal is _critical_. The display has to unambiguously know where the video actually is relative to the sync so it can sample it. VGA is still an analogue signal; the display has to sample it at the right time and probably use a phase locked loop to derive its phase, at least initially (i.e. when you push the 'auto' button!). The net result of this is that any disturbance in the syncs will at least temporarily break the system. It may result in jitter, longer term picture shift, or even a black screen while the display works out what's going on.

As stated upthread, the syncs must be of the correct polarity, the consistent voltage (nominally 5v, though 3v3 will usually work), and with fast edges without significant bounce. Note though that the analogue nature of the signal gives scope for out-of-spec signals happily working: the 25.175MHz dot clock for VGA 640x480 can be considered more of a guideline than a rule and most LCD displays will happily continue to show a perfect image - provided the image and the syncs come from the same generator - several percent away from the official frequency.

Neil

Figured out that I wasn't properly blanking the signal as well as added those 47 ohm resistors. The image is now very stable, I also corrected the vertical scaling: No more squished letters! \o/
I did a bit of that; however, using the character font gives me a recognizable pattern to look for; as well as giving me some options for some asymmetrical glyphs so I could make sure I was shifting in the right direction. The '299 can shift left or right, and seems completely backwards to how I think of shift left or shift right.... And yes... I did have it shifting the wrong way around at first, causing some of the characters to appear backwards.
I'll keep that in mind. Right now I'm pretty sure that I have the following issue:
The top line appears to be half the size of what it should be, implying that I'm I'm somehow moving to the next line before I should be. I think this is likely because I'm incrementing the vertical count on a rising edge instead of a falling one.

The left most character seems to be completely missing, I'm convinced this is because I'm trying to load that character right on the zero horizontal count, causing me miss the first one as the very slow ROM tries to settle out.

I'm also getting what looks like a couple of pixels shifted over to the left, causing one or two extra columns to appear on the right side of the monitor.

The binary pattern will definitely help with identifying the exact count.
I can, though at the moment it's pretty stable. (Also have to see if I can figure out how to record a decent video of any sort, that's not something I have any kind of setup for.)

There's the flickering and the drops.

I'm guessing the flickering I mentioned, is mostly due to the fact that the signal is getting trashed by going through that really terrible breakout cable I made, having fairly long unshielded wires, plus being loosely connected into a breadboard. Like I said, it's REALLY minor, it might not even show up very well on any video I take, and my suspicion is that it will get cleaned up if/when I move to a proper PCB for this.

As for the drops, I'm fairly sure a lot of that is more due to me sending pixel data in the blanking period than the quality of my signals. The 47 ohm resistor that J64C recommended helped a lot; but also I'm currently relying on the idea that the CPLD will stop telling the '299 to load character data at the right times, thus it will start shifting in 0s from the ground pin as the shift clock continues to run; if that gets off the shift register will continue to send pixels that are on, thus upsetting the monitor's circuitry that tries to workout what level "black" is. If it happens to do this when there's a white pixel being transmitted, then the screen goes dark for a frame or two. This can be exacerbated by selecting a different character to display.

It almost certainty would be better if I were to have this on some kind of tristated latch and then feed that into a transistor that can pull the signal to ground on my end as you recommended before. Thus I could completely disable any possibility of any errant output.
Yep, actually checked the signals on the scope before I even attempted to connect it to a monitor. The signals as near as I can tell seem pretty good. The timings are very close to spec and the levels are all really good.

Horizontal Blank: Vertical Blank: It does appear there's a consistant 1V spike in the vertical blank there; less than TTL's 1.5 cross over point, but still in that grey area.... Hrm.....
The ATF1502 breakout board has it's own 10uF electrolytic cap for handing some demand spikes here and there, and each one of it's VCC pins has another 0.1uF ceramic cap for filtering any noise as per typical. The bench power supply shows that I'm drawing right about 0.1 amps while the circuit is running, and I've allowed up to a generous 2 amps. I can double check the power rails, but I'm pretty sure it's all stable.

I still want to place some kind of flip flop at the end if for no other reason than to make sure all the signals are arriving at the same time.

Obviously he's not a perfect source; he's going for ease of explanation/understanding than being perfectly correct.* He does talk about the pulses being negative level logic, so I'm getting the impression that by polarity you mean something other than that.

* The number of time's I've tried to explain a programming topic to someone only for them to get confused by, or hung up on, the error checks in the example code..... x_x
Indeed, with the older analog monitors my guess is they effectively "smeared" the pixels as the beam swept over the phosphors. At least that seems to be my understanding with how older TVs worked with various video game consoles; I presume older analog VGAs did the same thing. (I've been watching too many retro repair videos lately....) With LCDs this needs to get scaled up digitally in some way, either in hardware or software.

I have two LCDs that will still take a standard VGA input, both are 4:3:

One of them is much older and it's scaling is really ugly, it just clumsily doubles up on some pixels. This leads to some pixels being doubled and others not and gives rather uneven sized pixels when you aren't in it's preferred resolution. Not ideal if you're trying to work out if that pixel is being doubled by your bad circuit timing or if it's being done by the monitor itself to just scale the image.

This Dell monitor does a better job of making the scaling look even and correct, despite it's native resolution being 1024x768. It does occasionally "complain" that it's optimized for 1024x768 when I start seeing these sync issues. The implication being there's something not quite right about how I'm sending these signals and it knows it.
What I'm seeing is the picture will drop for a couple of seconds.

Don't get me wrong. He's the reason I got back in to electronics, back in 2019. He's a fantastic source of information. But, I have found along the way that a couple of things, like the aforementioned sync polarity, would cause locking issues etc on some of my screens until I worked out what was going on. Was just checking that you aren't chasing your tail by replicating the same boo boo's.

You still haven't told us what your sync pulses are yet or what VGA mode you are running for that matter (unless I missed that somewhere).
I'm guessing that it is one of the 640 x 480 modes. Even though it is displaying ~626 pixels on the horizontal axis. The vertical looks correct at 480 pixels.

What clock frequency are you using? is it 25.175 MHz? Or are you rounding down to 25?

If you are using 25 MHZ, you will lose 8 pixels on the horizontal, which would account for why we are only seeing 39 characters.

Opps, stupid oversight on my part.

I'm going for 640x480 @ 60Hz; the end goal is to get a 320x240 by doubling the pixels for the 6502 and that nice retro style pixelated graphics.

As for the sync pulse timings, see my photos of my scope.

Horizontal is showing right around 3.9 usec (VGA Timing says it should be 3.81 usec)
Vertical is getting around 63.8 usec (VGA Timing says 63.5 usec)

Okay, so it is what I thought it was. I'm using negative sync pulses (I.e. normally high until sync, then goes low, see scope); this is what I see listed on the VGA Signal Timing website for 640x480 @ 60Hz

(Looks like positive going signals are for when you're doing 800x600 @ 40Hz)

However this did bite me, but for all of maybe 2 seconds when I was like, "is it negative to trigger sync or positive" and then looked it up.

Also helps that they are being fed through a 74HC86. I can very quickly switch them just by flipping the other input on the XOR.

That's what threw me as you labelled them as being horizontal and vertical "blanking period".