Again, my apologies if I'm answering questions you're not asking. However, making assumptions about what is being asked and what has been done can leave a hole in the answer... and render also of less use to another reader who may find this in a search for a similar problem.

I was unobservant in my post this morning: had I looked more closely I would have noticed that the scope trace in your second image is somewhat less than five volts rail to rail while the first image is five volts pretty exactly. The difference looks to be about 0.7v (though of course one should *never* trust an oscilloscope to give an accurate voltage reading; that's not what they're for!) which looks suspiciously like the voltage drop through a series diode. In this case, as I note you're supplying the whole circuit through the ENT pin (ENT to substrate to Vcc via diode, everywhere else fed from that Vcc pin). I wonder if you're simply isolating the oscillator from the rest of the counter by powering it this way? It would definitely be interesting to see the Vcc signal - you'd probably need to trigger the scope from the divided output to see if any noise on it is correlated.

For what it's worth, an HC163 on one of my protoboards, decoupled but without any great attention to wiring lengths, produces a very similar signal to your first scope shot.

Neil

I am pretty sure I am missing a lot in this thread, but are you really sure that they're not causing any problems?

One of my great learning experiences was watching a 74LS86 quad XOR gate function with a disconnected Vcc pin. Now that I've seen that, I'm very careful about making sure that every input is getting a signal.

_________________
Curt J. Sampson - github.com/0cjs

Yes, the shift registers do their own latching, so for things that are going through them, there's no need to add extra latching. It's mostly needed for the control signals because any glitches in those mess up the timing very badly, so we don't want those connected to something asynchronous like RAM or ROM that might not transition its data pin outputs very cleanly.

When I implemented a hardware sprite, this did come up again, but I don't think I bothered adding the latch as it wasn't very noticeable. The reason was a little different though - I had R/G/B outputs from the main framebuffer (background image) and R/G outputs from the sprite layer, and an "OR" gate comparing R and G to produce an A channel for the sprite. This A channel fed into a multiplexer to pick either the background R/G/B or the sprite's R/G with B=0 - however, there was therefore an extra gate delay on that alpha signal, and it led to some slight artifacts near the edges of the sprite because it didn't change exactly in sync with the R/G/B channels. It was minor, but is another reason you might consider adding more latching in more complex systems, to let various different inputs into the final output layer all settle all their transitions before you commit to what the actual outputs will be for a pixel's duration.

Regarding unused CMOS inputs, yes you should almost always tie them one way or the other, and they won't draw any current. Unless they're documented otherwise (e.g. in cases where the IC includes a "pin keeper" circuit), floating CMOS inputs are out of spec even if the IC isn't meant to be reacting to their state at the moment, as there could well be some circuitry that's active before the bit that chooses whether to react to the input or not; and due to the way CMOS inputs work, this can lead to excessive current draw (as both transistors on the input may conduct at once) and I think that can potentially destabilise the rest of the IC, e.g. by pulling the internal VCC too low.

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

Circuit #1:
Circuit #2:
That was a good idea, Niel. Could this noise actually be cross-talk from the `163's outputs, and not ground bounce or VCC noise generated by the oscillator? The spikes correlate with the oscillator's pulses, as expected, but they're bigger when more of the `163s outputs are switching at the same time.

Maybe it's worth reiterating that both these circuits work. Even the biggest spikes are not in danger of creating logic errors. However, AN-375 from my National Semiconductor HCMOS data book says that, as a good rule of thumb, it's generally good design practice to restrict both Vcc and ground noise to less than 250 mV. Since this counter is going to be clocking a pretty touchy and (for me) complex circuit, I'd like to get it as clean as possible. Is there some way to get the effect of circuit #1 without feeding the `163 through the wrong pin (and without the almost 1v drop)? My first thought would be just to send the outputs through a 74HC14 a couple of times. Anything better than that spring to mind?

Yes, I'm sure!

OK, though, BDD is right; "disabled" was an overstatement. The pins are not tri-stated. *However.* No less a visionary than Radical Brad left those inputs floating in Vulcan 74. gfoot himself (Hi George! Thanks for posting to the thread!) left them floating in his prototype of this selfsame circuit. That picture is still the cover flow photo of the project's Hackaday page! I'm not going to argue with anyone who says it's good practice to terminate CMOS inputs, or that leaving them floating is a bad habit. I, too, have accidentally powered a logic gate without connecting its VCC. But when I say that these four particular inputs are not causing any problems I mean that these four particular inputs are *in fact* not causing any problems, not that I assume they aren't, or believe they aren't. I know that they aren't because:

1. Logically, they shouldn't be.
2. Prototypes for much larger and less forgiving projects by designers whose works I admire and study leave them floating without issue.
3. The floating pins are common to both circuits #1 and #2 and are therefore not responsible for the difference in behavior between the two circuits.
4. I checked! C'mon guys! Since the point of isolating two ICs out of a much larger VGA circuit is to investigate how they respond to different conditions, and because tying off four pins is trivial, of course I've tied them to both VCC and to GND in both circuits while watching the scope. Those jumpers went away along with all the bypass caps into the category of "things that don't make a difference" before I took the breadboard photo, because I was trying to make it *visually simple* in order to focus on one variable: the difference in VCC wiring.

So BDD can relax:
They're terminated on my schematic, they're terminated on the full circuit on my big breadboard, and they've even been terminated every which way on the 2 IC isolated circuit.

Interesting, I just read that data sheet two days ago, and mine has no such note. Then again, mine is copyright 1982 even though the data book is from 1988, so...

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

Since HC163 slows down at lower voltage and therefore generates less noise, your less noisy waveform at 4.3V (circuit #1) may be the result of lower supply voltage. So reduce VCC of circuit #2 to 4.3V and see if the output becomes quieter. Conversely raise the voltage of #1 to 5.7V and see if it becomes noisy.
Bill

Circuit #2 at ~4.2V. Well now.

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

Ah very true, but we live and learn and after reading the same Texas Instruments application note that was linked earlier, I took this requirement on board and started paying more attention to this. As best practices go, it's a very easy one to follow!

It's also important to bear in mind that the failure mode discussed in the application note is nothing to do with the regular function of the pins - it's an artifact of the way the CMOS technology works. My shallow understanding of it is that there's a pair of transistors - one N-channel and one P-channel - across the power rails, and the input pin is connected to both of their gates. This is fine so long as they don't both conduct at the same time. If the input is clearly high or clearly low then only one of the transistors conducts, and there's no current flow between the power rails; but if it's in the middle it's possible for both transistors to be at least partially active, and then a current is flowing directly from VCC to GND. Floating inputs potentially fall into that category - it's possible that the charges on the gates are just right for this to occur - and so it's worth avoiding, given how easy it is to just tie these pins together and connect them to something fairly constant in the circuit (VCC, GND, or at a pinch a nearby low-frequency digital signal).

The thing is, because this is undefined behaviour, you can't really reason about it and say that it's definitely OK. Just because it works in your tests, or in my circuits or anybody else's, it doesn't mean it'll be reliable for everyone or every time. That's why it's worth avoiding.

For what it's worth, all my breadboard circuits suffer from quite noisy signals on the oscilloscope, perhaps due indeed to poor adherence to best practices, but on the whole I haven't found it really practical to do much about it on a breadboard. It's far from an ideal environment and I feel there are so many elements that I just can't control, in the end the circuit design just has to have enough headroom that the noise doesn't cause any visible issues. If you can get yours more under control though, it'll be nice to see!

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

Well now, I need to check the forum more often! Hi Paganini! Looks like you are on the next big project!

Everyone else is spending 2 cents on bubblegum, so I might as well also. I know there are some very bold folks out there using dozens of breadboards with big 'flying wires' and all that, and getting results. Good for them. I am currently working on my own mini project with CPLD's and using a breadboard, and getting the worst results in the whole wide world!

I remember a year ago I was working on some small circuit with a breadboard, and it was just NOT working. One thing would work, then another would break, etc. I would twist the thing and it would work suddenly. I would push my hand down on some wires and it would work suddenly. Then my wife came in to check on me. I looked up at her with wild eyes, held up the breadboard with wires and chips and all that, and then TOSSED it behind my shoulder, all without letting my eyes leave hers. It hit the wall, fell behind the bed, and remains there to this day.

So, be bold and do what you want! As for me, I am about an hours worth of work away from tossing this current breadboard over my shoulder like the last.

I think text mode for VGA is a really good idea! That's exactly what I'm working on right now as well. Can I ask some fun questions?

1) What font are you going to use?
2) What colors are you going to use?
3) How many characters will you fit on the screen?
4) Will you have the ability to change your characters (in RAM)?

Thanks for posting pictures, I'm looking forward to what you come up with!

Chad

Hi Chad! I am, and I amn't! Same big project as last time, in that I'm starting where I left off before with my VGA circuit. Last time it would only work well with one of my two test monitors, so I want to see if I can tweak the design to make it more robust.

But "off screen" (so to speak) I'm optimistically preparing to combine all this stuff into one full featured system. I'm planning to use the construction method I used with Peanutbutter-1 to make a kind of "book of cards" connected with cables, a la Daryl's SBC-3 (I think it's 3), so I've been learning how to make cables. I'm planning to do a little more design and a little less experimentation as I go on this one. I'd like to include some basic stuff that I've been missing from other projects... such as a power switch! I sure get tired of plugging and unplugging my wall wart.

The creator of this spectacular system recently joined another retrocomputing forum I'm active on: https://pdxjjb-digital.blogspot.com/2023/06/yarc-yet-another-retro-computer.html

I do pretty well on breadboards, but my limit seems to be about 4 or 5. Once the wires get longer than about 1.5 breadboards long, I start having trouble, even with dedicated ground return wires. I guess there's something to be said for all that copper!

At first I was making my own using a bitmap editor and TextEdit. That became extremely tedious. Then I came across this site: https://int10h.org/oldschool-pc-fonts/fontlist/. IIRC, the "fontraption" program comes with the fontpack in flat binary files that are suitable for immediate burning to a character ROM. The character ROM has room for two character sets, and can easily be made jumper selectable. I like the ISO/8 version of the IBM DOS font.

Red, green, and blue! (The current design is monochrome, so I have a super simple resistor network generating a nice retro aqua kind of color. I also came up with a nice amber color. It wouldn't be too hard to make this programable. In fact, it would be fairly easy to do 8-bit color once monochrome is working. I would just need more video RAM.)

This will be 80 column text at 640 x 480. I think the glyphs are 16 dots tall, which works out to something like 30 lines per frame.

Not so far; everything on the video side of the dual-port RAM is automatic - no programming required or allowed!

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

Cool, would love to see pictures along the way



That's nuts! Well, again, if you or somebody else can get that stuff working, good on you. I have ONE breadboard, and if I *look* at it the wrong way it freaks out. I even got the breadboard brand that Ben Eater suggested! I even cut my own 22 gauge wires! AND THEY ARE SOLID COPPER!




Well, you say that now. "Just add more RAM". I will say that every bit of color or resolution you add will make the system harder to handle. Sometimes in more subtle ways. Video circuits have been my primary focus for the past (almost) two years now, and I am still learning the physical limitations.

For example, you want color text, so what data are you sending through this dual-port RAM? Are you sending the character value and then it's color value? Or do you limit it's character value potential to add more color options? If you switch from monochrome, it seems you would need extra instructions to send the pertinent color info and still have it display correctly.

Given your dual-port RAM is 8-bits wide, and if you are using the standard ASCII 128 character set, then you have one bit to modify (invert) color. You can either reduce your character set down to 64 characters (which is totally do-able), and get more color bits. OR you need to send a second packet of data each time, effectively doubling the time it takes to spit things out. I don't think it will make much of a difference with in text mode, but imagine if it were bitmap pixels, and things get tricky quickly. And even if this is dual-port RAM, you are still doubling the memory space required, just by adding a few colors. If you are overscanning like George (and I) do, that's at least 4K for monochrome and thus 8K for color text. Not terrible in text mode again, but something to think about.

All in all, I do think this is a super cool project, and I want to see your results! And I also want to see what design decisions you end up making

Thank you for sharing!

Chad

Yes, the outputs from the 163 likely share a common(ish) power rail within the chip (don't quote me, I'm not a chip designer and I've never looked at the die!) and so are likely to affect each other to some extent. It is entirely as expected that the noise on the power rail is closely correlated with the switching particularly as you are definitely powering the chip the 'wrong' way through its substrate diode and the ENT input.

CMOS logic takes current only when the internal gates change state and the reason for a 'high' capacitance, low inductance decoupling is to supply that current as and when required. I find 10nF is usually enough to keep things in check... but it may not do a lot in this case as the switched circuits are affecting each other.

Though your observation that the noise is not big enough to take the signal into improper voltage levels may well depend on the response of the scope; those signals could have high frequency components that your scope input amplifier simply can't handle. But I think you're fine. A buffer/inverter after the signals will probably clean them up.

Neil

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

Thanks Niel, this is making sense!



I just realized that if I buffer all the clock signals I may be able to get rid of some of the signal generators, and also get rid of some of the difficulties with propagation delay. Bonus!



It's on a breadboard; might that be enough parasitic capacitance?

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