I have been working on a VGA sync circuit as a first step to add display functionality to my SBC http://forum.6502.org/viewtopic.php?f=1&t=8062

After trying out different counter chips and solutions I found one that is working pretty well (a slightly modified version of the one made by James Sharman, https://youtu.be/KSuEKRjmtbw?si=FhozC73dRdo9pjk4 )

But, the top part is crooked, as can be seen in the image. I wonder if it is an artefact of a noisy circuit or if there is something wrong with the screen? It's 19 years old after all. The picture is rock stable in itself, just crooked at the top. I would expect noise to cause flickering or general instability but perhaps this can happen too?

The sync circuit made on solderless breadboards and the signal is pretty noisy according to my scope, as to be expected when not special care is taken to counteract the artefacts of solderless breadboards. I aim to clean it up somewhat and later build real PCBs for it but first I want to identify if the problem could be something else entirely. If it is due to noise I might even go for the PCB option sooner than later because having this on solderless breadboard is not that great anyway (I actually hate working with solderless breadboards but it's good for figuring out how chips interact which eachother). Any ideas?

I have attached a rough outline of the circuit exported from Kicad. In the photo I am not loading R G B but rather letting the 74HC163 that is connected to the VGA-connector count for each clock cycle to create the RGB-pattern, but the same crookedness happens if I connect a constant color which is loaded all the time.

EDIT: The inverters are not present on the breadboards, they were added in the schematics as I might be delaying the clock signals in the future.

Some info about the EEPROM contents. The sync clock (SCLK) runs at 25.175/16 MHz. The /RESET bit is set on byte 26249 which corresponds to 800*525/16 pixel clocks starting from 0. The DISPLAY bit is stored one byte before it is used due to it being clocked into the 74HC163N from the 74HC574 latch (1 SCLK delay).

Assuming the hardware is working correctly, my best guess is to take a look at the vertical sync timing, since its tearing only at the top.

thanks!
Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I seem to remember there's a potential problem chaining a bunch of 163 counters together like that.

(Here it is in the data sheet, on page 12: https://www.ti.com/lit/ds/symlink/sn54hc163.pdf)

George (gfoot) uses a pair of `590 counters to drive the EEPROM in his design (here: https://hackaday.io/project/175434-worl ... ga-circuit), and I followed his example with mine (here: viewtopic.php?f=4&t=7633).

What are those series resistors for on your sync signals?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Hm I will double check the vertical sync timing code when I get home. Late night Python coding is not a bullet-proof activity

There is a glitch, but according to the specification it is only relevant for speeds over 18 MHz. I am running the circuit at 1.5 MHz so in theory it shouldn't[tm] be an issue. I tried to use 590's in the beginning but found the double clock annoying and couldn't really get it to work satisfactory. Now it seems to be mostly working so I am hesitant to tear it apart a fourth time (this is the second '163 build, previously also built one '161 version and one '590 version )

The series resistors is a "i read it at some random forum that you should put some 47 ohm:ish resistors on sync signals" addition. They make no apparent difference what I can see so I might remove them again.

From my experience with such timing settings I also think this is a timing problem, and most likely vertical timing, I agree.

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Yeah, the 590 register can be kind of a pain. Sure is nice to only have 2 counter ICs per EPROM rather than 5 or 6 though!

Aha! LOL! I was just curious; I've never seen those before.

Here's the timing side of my VGA board. It's very similar to George's. I added a few signals, because my output side is different (using a character ROM to generate a text-only display). VGA is kind of simple, in a way. There are really only two problems you can have. If your timing signals (HSYNC, VSYNC) are out of spec, the display won't lock *at all* and you get nothing. You clearly are not suffering from this problem. If your timing signals are good, then the display will - mindlessly - present whatever comes in over the RGB lines. (This is assuming your display is a good one - hopefully by now you plugged it into something else to make sure it actually works! ) That means that *the display itself* is a kind of debugging of your output side logic.

In your picture, I see 40 columns that are good for a few scanlines, then each scanline gets off by one more pixel every line until everything has moved over more than one column, and then it *moves back the other way* a pixel at a time, but not every scanline, until it settles in and remains stable for the rest of the frame. I'm not sure which area is the correct one - do you expect to see a green bar or a black bar in the first column? Either way, this seems an awful lot like an out of phase counter.

Looking at your output register, it's clocked by SCLOCK, which is ~1.57 MHz, and reset by DISPLAY. I'd take a look at those two signals in addition to checking to make sure your timing ROM is correct. One thing you might try is setting the whole screen to white. Any irregular black areas will tell you about your front / back porch and blanking timing. Also, what happens if you never reset the output register? (This will show you exactly where the monitor thinks each frame begins and ends.) Or, what happens if you don't use the output register at all? (Just tie RGB high through resistors.) Do you get a square, or do you still see distortion?

Etc.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad