Howdy! I'm experimenting with a 74HCT14 to learn a bit more about how Schmitt triggers work. I've been trying to figure out VGA signals lately, so this seemed like a good opportunity to try the '14 as a way to clean up the signal coming out of the 27.175MHz oscillator in my circuit:



(The circuit also includes a .1µF decoupling cap, not pictured; also my can's datasheet says that Pin 1 should be NC.)

I'm seeing some really strange results that I don't understand on the 'scope. This is the input signal coming from the oscillator, as seen on Pin 1 of the '14 chip:



And this is what comes out on Pin 2:



I'm… pretty baffled; I expected a relatively nice square wave to show up on Pin 2, and this looks like anything but. I've swapped out both the oscillator and the IC, with no change. FWIW, this is currently on a breadboard—not sure if it could be problematic for something this simple.

Once again, I feel like I'm missing something obvious, and would be grateful for any guidance

Thanks!


Datasheets: ECS-100A oscillator and 74HCT14 (apologies for the links; for some reason, I can't seem to be able to upload files right now).

There might be an excellent answer to this, and I'd be interested to know it, but I don't have it. Bear with me while I chime in anyway - some of this you might well already know.

I'd like to note that the idea of a Schmitt input is that its logic threshold isn't constant: it's higher for rising and lower for falling edges. The idea is to react just once to a slowly changing signal, or even to a signal which is dithering about a bit.

That can be useful, especially when dealing with some kind of real-world signal.

But I don't think it's very usual to see them used generally in a simple microcomputer design: the clock does need to be glitch free, and it might need to meet some minimum edge time constraint, but I think I'm right in saying that one doesn't usually see Schmitt devices in the clock circuit.

The other thing to note is that what you see on a scope depends very much on your probes - not only should they be good probes, if you want accurate representation of what's happening without disturbing it, but also they need to be calibrated once in a while. Look up "scope probe calibration" - you should find procedures and also the reasoning behind it.

Which is to say, you need to know that the wiggly lines reflect what your circuit is actually doing, before reading too much into every wiggle.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks, Ed—I didn't know these things, so they're very useful.



Thanks for this, too—I think the probes are okay, as I see square waves elsewhere in the circuit at the same speed, but I'll give it a go. Cheers!

Hi Garth! Thanks for these notes—I had not considered the timing very carefully… I'm using an HCT (the HC is a mistake in my hastily-captured schema, sorry!), but even then the typical propagation delay of 12ns is nearly a third of the clock period, so the resulting inverted signal would be way out of phase.

I guess I'll have to rethink everything… my idea was to use opposing clock signals to alternate access to the memory between the video output and a CPU, but this clearly isn't going to work. Perhaps I should consider a different access scheme, or maybe look into how others have accomplished the same one.

Cheers!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks, Garth and BDD. The flip-flop was the first idea I thought about (I had seen it explained in a bunch of places), but then I got hung up on the fact that I couldn't find an oscillator that was exactly twice the frequency of VGA@640x480x60Hz. In hindsight, there has to be enough tolerance built into the standard that a 50MHz clock divided by two is probably good enough!

Oh well… I placed an order for some new parts (including some 74AC chips). For now, I just programmed a 16v8 PLD to generate the two clocks I wanted.



It's “slightly” overkill, but it gets me moving forward for now. I'll revisit the clock generator once the new parts arrive.

Thanks again for all the help!

I figured I'd post an update here, so that all those of you who chimed in know how much you helped me. I was away for work, but when I came back yesterday I started fresh and promptly ran into all kinds of problems, mostly caused by the cheap breadboard I use—I'm really starting to warm up to the idea of wire wrapping my prototypes

Anyway, I couldn't make things work at 25MHz; the output from the PLDs was just too glitchy. Eventually, I realized that I could simply divide the clock by 4 and then operate at ~6MHz, which caused fewer problems, and so I was promptly able to generate a 640x480@60Hz signal that my monitor could recognize. So, thank you all for your help… without it, I'm pretty sure I'd still be trying to square out the output from the crystal oscillator.

Now I need to figure out how to actually display something. Frustratingly, I can't seem to locate any SRAM that is big and fast enough… it seems impossible to source a DIP chip bigger than 32kB and faster than 40ns. I'm kinda hoping that a 55ns SRAM will be “fast enough,” but I guess that's a problem for future me to deal with.

Cheers!

Recent posts have mentioned UM61512 which is 64KB SRAM, 15nS access time in 32-pin skinny DIP. It is available on eBay and UTSource for around $1 each.
Bill

Brilliant, I ordered some. Thanks!