Hi George,
I think I have solved it. In writing the following reply I came up with a hypothesis that I have gone on to test with satisfactory results. I'll post them at the bottom along with some new scope shots.
gfoot wrote:
So what I'm seeing is kind of what I was worried about - the traces for the non-inverted version look a lot better.
...
This delay is likely due to the counter, AND gate, and inverter, along that path, and as I feared it looks like it adds up to about the same as the 20ns delay caused by inverting the clock. This means that in the inverted clock case, the shift register's clock edges (red) come extremely close to the edges in the shift-or-load signal. In the datasheet it probably has a setup time requirement and maybe a hold time requirement, which could be violated here.
...
In contrast when the shift register receives the raw clock, its rising edges (yellow) fall nicely in the middle of the "load notch" - you couldn't really ask for a better result unless you planned it. So I'd much prefer the uninverted clock.
Of course, I did plan it.
In the original version, with a separate `163 to generate the load pulse, I figured since the `163 and the `166 were both driven by the dot clock, the load pulse would lag the clock by about 20ns, giving roughly 20ns before the next rising edge of the pixel clock. This should meet the `166's setup time requirement (it has no hold time requirement). I guess this is an "expectation vs. reality" discussion. This version never did work well; in addition to the missing character, it rarely produced artifact free video. That it could SOMETIMES produce artifact free video seemed to suggest to me that the issue was with the relationship of the load pulse to the HSYNC/VSYNC signals, since the `163 generating the load pulse was the only thing not clock-locked. Also, on the scope, the load pulse seemed to lag much less than the typical propagation delays listed in the data sheets suggested it should.
Moving on to the new version, the `11 has a typical propagation delay of about 10ns, so I would expect the the inverted dot clock to be about 1/4 of a cycle behind the "pure" dot clock. Meanwhile, the `163 is a bit on the slow side at 15ns. The typical propagation delay for the load pulse from OSC -> `163 -> `11 -> `14 -> `163 should be about 35ns, or just shy of 1 whole pixel:
Attachment:
20230704_142654.jpg [ 2.73 MiB | Viewed 625 times ]
But in reality, the inverted clock is no where near that out of phase with the pure clock, and the load pulse seems to lag by substantially less. This is a bit of a head-scratcher for me: when I start moving the design to perfboard how much change to expect? Maybe the "by the sheet" version will work, and the "inverted clock" version only works because of some contingent breadboard thing, like some particular long wire, or excessive inductance. (What I mean is, they appear to be almost not out of sync at all. But maybe they're so out of sync that the inverted signal is a bit more than a whole cycle late.)
gfoot wrote:
I don't think any of these are what you're seeing though. To really see these you need a special font that deliberately has pixels in both the left and right columns of the character cells - I'd probably use a diagonal line of pixels through the character cell, with a marker of some sort to show where the character boundaries are, e.g. a short line along the top of the character cell, but not intersecting the line because we need that to be a completely clean 45 degree line of pixels. Armed with that, you should then be able to see pixels being too fat, too thin, missing, unstable, etc.
I like capital 'V.' In this character set it's full width (except for a one pixel spacer column). I have seen some of the pixel "shimmering" you're talking about. It's usually (always?) at the left hand side of the screen.
gfoot wrote:
But then the question is, what are you actually seeing? And secondarily, how is it caused/resolved by inverting the clock? It is very odd that it repeats every 10 characters (not 8 or 16). It looks very much like the kind of effect you get when the monitor adjusts its pixel clock incorrectly due to e.g. you not outputting all 640 pixels in each row - or outputting too many. It looks like in that case you did only show 79 characters. So I wonder whether this is some kind of sampling artifact from stretching 632 pixels out to 640 pixels, and then eight times during the character row the monitor is sampling your RGB levels during a transition between pixels.
Yes, that matches my observations too. It's not always 10 characters; sometimes it's more or less. It seems to be to do with crowding or stretching as you say. On the IBM monitor, if the clock is off by one pixel I'll get 1 vertical bar, which means occasionally I can manually adjust out the artifacts. I haven't been able to do that on "Fussy." It usually seems to have more, and adjusting the clock settings seem to just move them around or shrink / expand them.
gfoot wrote:
Great, and I guess that ROM is driven by counters that are clocked by something like the shift register's load/shift signal? Or something else? The point during the character's width when the counters tick up is important as you then need to allow the latency of the RAM and character ROM before you next load the shift registers, so the load/shift signal is actually a pretty good choice for triggering the counters as it's about the earliest time you can get away with doing it. It does mean though that potentially the horizontal blank signal might go active nearly a whole character cell early, unless you delay it through a D flipflop until the next shift register load enable pulse, and maybe that's what's causing you to only output 79 characters.
It's pretty much your circuit. I have two `590s scanning through the timing ROM and a `273 latching the output. Here's my system timing diagram:
Attachment:
20230704_131411.jpg [ 2.96 MiB | Viewed 625 times ]
You may be wondering where the characters are coming from, since there's no framebuffer or X/Y counters. The answer is, I have A4..A11 of the character ROM jumpered to the power rails so I can select different characters by wiring up different bit patterns. The circuit just fills the screen with whatever character the ROM is wired to produce.
OK, and now the exciting conclusion. My scope has a x10 knob so I can kind of "zoom in" to .005 µS. I thought it might be useful to examine those load pulse edges more closely:
Attachment:
20230704_160229.jpg [ 3.18 MiB | Viewed 625 times ]
Hypothesis: the rising edge of the clock pulse and the falling edge of the load pulse are like ships passing in the night - they're so close together the `166 is shifting on that clock, and not loading until the
next following clock. In effect, inverting the clock had the effect of delaying the load pulse, rather than the reverse. To test this, I went back to the original (non-inverted) dot clock, and ran the load pulse through a flip flop:
Attachment:
File comment: Original, vs. flip-flopped load pulse
20230704_162848.jpg [ 3.11 MiB | Viewed 625 times ]
Attachment:
File comment: Dot clock vs. flip-flopped load pulse
20230704_164852.jpg [ 3.17 MiB | Viewed 625 times ]
This seems just about perfect.
Login
Register
FAQ
Search
) The 25MHz dot clock is sort of just barely within its power, but it looks pretty spiky. It's not so bad that doing what you suggest wouldn't give some useful info though. I'll try to remember to do that tomorrow and take some comparison photos. 
IT'S ALIIIIIIIVE! 
