Generates fully compliant 640x480 @ 60Hz VGA syncs and blanking signals with a low number of standard TTL ICs
To make the experience fit your profile, pick a username and tell us what interests you.
We found and based on your interests.
sch - 285.76 kB - 01/13/2019 at 12:59
Adobe Portable Document Format - 22.97 kB - 01/13/2019 at 12:59
brd - 69.82 kB - 01/13/2019 at 12:59
circ - 17.85 kB - 01/12/2019 at 22:19
Create an account to leave a comment. Already have an account? Log In.
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:
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 ;-)
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.
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 ;-)
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.
Become a member to follow this project and never miss any updates
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: