My season got excessively busy towards the end, but it is finally over and I have some time on my hands again! I've been wanting to get back to my VGA project, so yesterday I (partially!) unpacked the electronics lab. I thought I would start a new thread for this since, strictly speaking, this isn't really a Blue April project, as you will see in the photos! Since I haven't thought about this stuff for a few months and I'm a little rusty, I thought a good baby-steps place to start would be to see if I could get my dual-port RAM to do anything. Here it is:

I've attached it to Peanutbutter-1 using this super expensive and high-tech connector to replace the usual SRAM IC:

Naturally all those long wires make it susceptible to interference:

You know what puts out an EXCESSIVE amount of noise? IBM model-M keyboards! I had it sitting on the bench next to the breadboard, and you could watch the glitches fly in the monitor program. Fortunately, the lesser of my two model-Ms has a really long cord, so I moved it down to the floor, and the glitches stopped.

For now I just have PB-1 hooked up to the left-hand port of the RAM. I figure that's good enough to do a basic test of all the dual port RAM ICs, and make sure I haven't misunderstood where any of the pins are. This is the first time I'm using a PLCC. I wonder how you get the chip back out of the socket...

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

I think you need one of these (link);

Seems awfully expensive.

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

Seems too cheap.

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

Here's a sketch of a logic / block diagram of my plan. This is more or less what I had working but with glitches before I put the project on hold.

Last time I ran into trouble trying to get all the counters to sync up at the start of the frame, so I need to come up with a workable reset signal based on VBLANK.

I'm also wondering if I should add a flip-flop to the output stage between the shift register and the resistor ladder ("pixels"). George (gfoot) latches everything with a `273, but his signals are coming right off his ROM. The `166 seems to use internal SR latches when it parallel loads, so maybe that's sufficient and I don't need an extra flip flop on the "pixels?"

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

I was reminded only today of the Chips 65535A VGA controller chip - half a meg of dram and the controller is a two-chip solution. Though you'd need to simulate a 16-bit address databus somehow which might slow things down a bit.

The chip is decades out of date but is apparently still available in bulk as NOS in China...

Neil

the F65535 is an interesting looking chip. datasheet
you could in theory have a 386 (DX or SX) with that thing on a seperate board to do the 16/32-bit interfacing and for "hardware" acceleration like block copying, drawing shapes, lines, etc.
then you just need a small interface between the main system and the 386, like a few FIFOs so it's asynchronous.

hmm, ok... maybe that's a bit overkill.

on another note, couldn't you use a second DP-RAM chip instead of a character ROM?
that way you could atleast change the look of the characters at runtime.

I used two 74HCT4040's with a pair of ATF16V8C PLDs and got some really tight timings, I was within 0.04uSec of the VGA spec.

Today I made a discovery, but I'm not sure what I have learned. Maybe someone here can interpret this strange oracle.

I've been having some trouble getting the signals coming off my clock prescaler (74HC163) as clean as I would like, so I moved just the oscillator and prescaler over to their own breadboard in order to isolate the problem and poke around at it:

And here's what my clock signal looks like:

HOWEVER, if I take away the orange wire on the far left that connects the two VCC rails, my clock signal looks like this:

In this configuration, the ONLY pins connected to +5 volts are one of the `163's enable pins, and its reset pin. All of the other VCC pins are connected to a floating power rail. What am I to make of this?

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

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

Naturally I started out with more decoupling. That one capacitor with the long leads, far from just being along for the ride, is in the one-and-only spot that does anything at all. I took all the others off in the "poking around" process. Bypassing is almost never the answer on breadboards; but, even so, why would disconnecting the power rail make things better?

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

Let's try this a different way. Here are two circuits. Both of them work, but #1 is better than #2. (I forgot to draw the clock pin in #2, but it does in fact still exist, and is still conected to the oscillator! )

In circuit #1, the Y outputs of the `163 are pretty clean. If you add a bypass cap across ENT and GND they are VERY clean. Circuit #2 is a noisy mess, no matter what you do with decoupling / bulk bypass capacitors. Why?

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

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

To emphasize BDD's answer: you have floating inputs on your CMOS inputs. Those *must* be tied to one or the other rail for proper operation (ideally through a resistor though I tend to just use copper in most cases); CMOS input impedances are so high that a few electrons floating around can cause inputs to be partially (or completely) active, and when partially active those inputs are operating in linear mode; not generally good for following circuitry.

Assuming the power supply is on the top rail - removing the orange wire means the 163 ENT input is floating, possibly calmed down by that smoothing cap. See above... that's an input that decides whether the part counts or not.

As you originally built it, you have a lot of wire between the supply and that ENT pin. That's all inductive, and again, you want to keep inductive loads/supplies as low as possible; that's why decoupling capacitors should be mounted as closely to the power pins as possible.

Another point on the same subject: the connection between your scope probe and the scope probe ground should be as short as possible. Your probe kit possibly has a clip-on earth spring that can significantly reduce that loop size (earth-scope probe-signal) and help to prevent signal being picked up in the loop that isn't really there.

Final (first) concern: you have possibly seen me rant about breadboards before... they have loads of stray capacitance and they have notoriously dodgy connections between the internal strips and the plugged in components. One aspect of CMOS parts which is rarely considered until it bites you is that most have a diode between any pin and the substrate, formed as part of the manufacturing. Any input pin which is held higher than the Vcc pin - as might be the case when the Vcc pin is open circuit - is quite capable of driving not only the specific part but in some cases the entire system to which it is attached...

Apologies if I'm telling you what you already know.

Neil

p.s. looking at the scope images: which signal are you probing? It appears that you have noise at exactly twice, four, eight, and sixteen times the fundamental; are you just looking at the final output from the divider or the clock input? I suspect the former...

First this part, as it seems most likely to be fruitful:

Now that is interesting. I observed on my scope that the schematic #2 'low' signal was much cleaner than the 'high' signal. So, theory: the `163 is struggling to locate +5 volts not because of ground bounce, but because of some other reason. When the pins all (but ENT) are connected together privately as in schematic #1 they come to their own conclusion about where +5 volts is, and ENT is capable of driving the whole system, as you describe. What could cause this confusion? It has to be something that isn't improved by bulk power supply decoupling. I will check what the oscillator is doing to VCC, as BDD suggested, but since it is part of the private network in schematic #1, it seems unlikely to be the culprit.

Second, your specific questions:

The four floating pins are the parallel load pins for the counting register. They're disabled when the load pin is held high and are not causing any problems. No doubt it would be good practice to tie them off with resistors in a final version.

When the orange wire is removed, ENT is connected directly to +5 volts. It's the only thing connected to +5 volts in schematic #1. In the breadboard photo RESET was also connected to +5 volts, because it was jumpered over to ENT. I subsequently updated the prototype to match schematic #1 to see if it made a difference (it didn't).

It didn't, but I bought some separately after the fact. I rarely use them because... they make very little difference. Again, I am probing both configurations with the same scope.

That's correct. The signal coming off of the 25.175MHz oscillator is a little too fast for my poor 200MHz scope. The spikes in the divided clock signals are expected, and (at least in the clean version of the signal) look just like the ones in the HCMOS app notes.

Finally, the part where I talk about my feelings:

I will mostly leave this part out, except to note that it's *REALLY FRUSTRATING* to receive answers that you already know to questions you didn't ask.

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