Generates fully compliant 640x480 @ 60Hz VGA syncs and blanking signals with a low number of standard TTL ICs

Similar projects worth following
After a post on Facebook by the moderator of the Z80 DIY group I decided to make the schematics and simulate the VGA sync/blanking generator that I've been thinking of for a while.

The ultimate goal is to make this circuit into a 80x25 character "video card" that uses only plain TTLs, a Character ROM and some RAM.
So far I''m using three counter ICs and 6 logic gates ICs for a total of 9 ICs, but I also use 3 diodes and a pulldown resistor as a discrete NOR (cheating a bit)

Simulations in Logisim is ok, and an actual build on a solderless breadboard measures as expected on my oscilloscope.

Next step is to hook it up do a monitor and XOR one bit each of the Ver- & Hor-counters together to get a nice checkerboard pattern on the monitor.


Eagle schematics

sch - 285.76 kB - 01/13/2019 at 12:59



Proper schematics

Adobe Portable Document Format - 22.97 kB - 01/13/2019 at 12:59



Eagle schematics

brd - 69.82 kB - 01/13/2019 at 12:59



Logisim simulation

circ - 17.85 kB - 01/12/2019 at 22:19


  • 3 × 74HCT393 Dual 4-bit counters
  • 2 × 74HCT00 Quad 2-input NAND
  • 1 × 74HCT10 Triple 3-input NAND
  • 2 × 74HCT20 Dual 4-input NAND
  • 1 × 74HCT04 Hex inverter

View all 8 components

Enjoy this project?



Andre Baptista wrote 01/21/2019 at 18:33 point

Just to share information:

This guy makes VGA timing using a "round" clock of 20MHZ:

It may be possible, by dividing the horizontal pixels by 4 to use a 5MHz clock, as seen this sheet:

  Are you sure? yes | no

Ted Yapo wrote 01/19/2019 at 18:28 point

Very nice, I love the idea!

I think you're pushing the specs on the 74HCT393, though. The VGA dot clock is 25.175 MHz, which is probably not an issue unless you care about all the temp/voltage corners. Note that this implies a 39.8 ns period.

However, being a ripple counter, the outputs don't all change at the same time. This is a much bigger problem. The datasheet specs the typical propagation delay from CP to C0 at 20 ns, then from Qx to Q(x+1) as 6 ns. So, if you have a 10-bit counter with the '393, the last bit takes 20 + 10*6 = 80 ns (typ) to change. This is 2x as long as your clock cycle. It's actually worse than this, because you have chained sections of '393, and pay the 20 ns multiple times. You might luck out and get it to work with specific really good instances of the '393 at some voltage and temperature, but I don't  think it would be reliable.

I went through the same thing a couple of years ago, and documented my dislike for ripple counters.

I ended up with 74VHC163 synchronous counters, but thought at the time that 74HC163s might be doable.

EDIT: I found the log where I looked at this problem on the scope:

  Are you sure? yes | no

matseng wrote 01/19/2019 at 19:51 point

Yup, the ripple can clearly be seen on my scope.  I really should analyze how the runts caused by the counter ripple thru combinatorial logic could affect the state transitions for the syncs and see if it actually could cause any problems with premature triggering.

Originally I planned to use synchronous counters, but I didn't have any at home so I just used whatever I had at hand to see if if would at least count at lower speeds as intended (with ripple and all). It did, so I just jacked up the speed to the 25.175 (well, actually just 25.000 since I didn't have any 27.175). And it still works.

It actually works fine over the entire range I tested. At 5 volt it pulls about 13 mA, so I was thinking - hmmm... this is coincell territory, so I dropped the voltage down to 3 and then the current was down to about 2 mA and it still worked. (even though I have a mix of HC and HTC ) 

Switching over to '163 would increase the chip count by 3 - but it probably will be a more stable product so it might be worth it.

Speaking of "having at home" - when I soldered up the PCB-version of it I discovered that I didn't have any 14-pin sockets. So I just used a row of four 20pins (with one leg removed every 7 pins) to fit the five dips with 0.1" space between them.  One gotta improvise or else nothing will be done ;-)

  Are you sure? yes | no

Ted Yapo wrote 01/19/2019 at 20:02 point

So, the problem isn't necessarily that the timing logic gets busted, it's more that you may not have stable outputs long enough to address the RAM or whatever gets hooked to the counter outputs. You can see this on the scope if you look at the LSB and MSB for either H or V - how much window do you have when all the output lines are correct? I would not be at all surprised to find that they are *never* correct at the same time at 25 MHz. I saw this with 74HC4020s, 100 MHz counters that above 18 MHz never show the output bits at the same time.

  Are you sure? yes | no

matseng wrote 01/19/2019 at 20:30 point

Luckily enough I don't need to handle the ram lookups at 25MHz - but at a bit more leisurely pace at 3.14MHz.  The ultimate goal (now) is to get a 80x24 character mode video device working.  But I still will have some issues at every 8 pixels....  I haven't been thinking this thru all the way yet.

My original goal was just to make a VGA sync/blanking generator out of a low count of ICs. (The Masochists Video card basically does what I do here but is using 34 ICs...). 

If I can make this work (possibly by having the first pixel always blank in each character) or by having a separate counter chain for the RAM (that maybe could also give me a contiguous linear addressing of the RAM).

If not I'm happy with just having done a low-chip-count 74-logic VGA sync gen ;-)

  Are you sure? yes | no

Ted Yapo wrote 01/19/2019 at 23:13 point

Oh, if you can make these character counters, you're might be fine. At pi MHz, the ripple counters are probably sufficient. Then maybe there's some way to add a faster dot clock for the 8 pixels inside each char.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates