6502.org

It's doing a fine job, nice and bright too - my main issue with my cheap analogue scope was that it was ridiculously dim and not possible to focus well!

So what I'm seeing is kind of what I was worried about - the traces for the non-inverted version look a lot better. Here I've superposed the raw clock below the one with the inverted clock, and marked some points of interest:
I marked the rising edge of the raw clock in yellow, at maybe two thirds of the way up to its peak; and the rising edge of the inverted clock in red. This is approximately when the shift register will either shift or load, in each case. Then in blue I've marked the apparent delay from the rising edge of the raw clock to the changes in the shift register's shift-or-load input. 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.

Now the question is, why are there image artifacts. The artifacts you're seeing aren't what I'd expect to see due to this clock alignment issue - what I'd expect to see there would be either image instabilities (single-pixel shimmering of the characters left and right), or missing pixel columns at the right hand edges of characters, or doubled-up pixel columns at the left edges of the characters. These are artifacts of sometimes or always performing two loads and six shifts, instead of one load and seven shifts. I guess another possible artifact is characters being entirely missing, due to not performing the load at all (both clock pulses just missing the edges) but it seems less likely.

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.

Equally most fonts don't really need one of these columns of pixels except for W and M characters, so in fact you might be able to get away with them not working particularly well!

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.
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.

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.
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: 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.)
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.
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.
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: 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: 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: This seems just about perfect.

Are the probes the original ones, or at least replacements that are worthy of 200MHz?

No; the scope was university surplus that I bought off eBay for a low low price. It came "as is" because it had no scopes and the seller didn't know how to test it. I got some Hantek probes for it: https://www.amazon.com/gp/product/B0779QN9TD

I would classify them as "adequate." They have the right specs, and seem to do what probes are supposed to do, and I get useful information using them. However, the cables could have better shielding. If I stretch them out long and waggle them around I can see the waveforms wobbling in reaction.

VGA circuit is all finished: And is working nearly perfectly[1] within the bounds that I'm able to test it at this point: This "video card" isn't "installed" in anything yet, so there's nothing writing to the other side of the dual-port RAM; right now it's just dumping whatever is randomly in there as character data. Still, it shows that at least for some area of the RAM, my timers are working. Once I rejigger Peanutbutter-1 a little (I'll have to mess with the decode logic to free up a block of address space) I'll be able to check and see if the corners / center are in the right place. Here's a little tour, from left to right, top to bottom.

- First breadboard: two `590 counters that scan the timing ROM, 25.175MHz oscillator, `163 used as prescaler, `163 used as scanline counter, `11 used to generate shift/load pulse.

- Second breadboard: 27c256 timing ROM, `273 octal flip-flops for latching the timing signals, 27c256 character generator ROM, `166 shift register for outputting pixels, `14 inverter used to generate shift/load pulse.

- Third breadboard: two `590 counters for X (7 bits) and Y (5 bits) column / row scan, and a `74 flip-flop used to delay the shift/load pulse a little.

- Fourth breadboard, the dual-port RAM and VGA adapters. These breakout boards were kind of expensive compared to everything else, but they really made things a lot cleaner / easier, so I'm glad I went ahead and bought them.

[1] Never a good idea to cry "perfect." If you look close, you can see that I have a little problem with the row counter. The bottom scanline is getting printed at the top of the character! I forgot to invert the row counter's clear input. *NOW* it's perfect:

Nice to see it coming together. Is that cut-up CAT5 cable that you're using?

Almost; it's this: https://www.amazon.com/gp/product/B00BNKN24W

IT'S ALIIIIIIIVE! I went ahead and installed it in Blue April: I haven't written any software for it yet, so I'm just using Pagimon to manually edit video RAM locations. But everything is in the right place!



Blue April here is moving at a dignified 4MHz using her CMD 65c02 and 65c22s. I had to steal an AHC138 from Peanutbutter-1 to do the address decoding. In some kind of fit of madness I only bought 5 of them.

Great job! Looks really good Nice font, good set of characters. Super awesome!

Chad

In a few weeks it will come time to move this off of breadboards and onto stripboard. When that happens, I will have a bit of a problem. The breadboard adapter I'm using is large, and it was kind of expensive. I do not want to permanently solder it onto my stripboard. Unfortunately, the standard right-angle solder-tail DE-15 plugs like you used to see on the back of a PC have a kind of staggered pinout that won't go into stripboard. I need something like this adapter that I found at Jameco: Unfortunately, it's discontinued and Jameco no longer sells it.

What I would really like is a DE-15 plug that is IDC terminated. Then I could just solder some pin headers onto the stripboard and connect to it with a cable like this one: https://www.pccables.com/VGA-Port-HD15F ... IDC16.html
I'm planning to have a front panel for this next build, which I could easily mount the plug in.

I don't know if PCCABLES is a trustworthy seller, or if their shipping is expensive, or anything like that. I suppose if I have to I will just buy that, or some similar thing, if I can find a seller that seems good. Still, I have all the stuff I need to make an IDC cable, except the VGA terminator. I know it exists, I just can't seem to find anyplace that sells them! I've been doing a lot of googling for things like "IDC DE-15 FEMALE" and variations, without much luck.

In the meantime, I'm wondering if you guys who have more experience building things with stripboard have tricks for attaching things with those zig-zag pin grids.

That's not a bad idea. I wasn't planning to start making PCBs for a while yet though. It seems like it's own complicated thing.
Georgia! We're practically neighbors. Thanks for the recommendation, that's good to know.

I have mounted the HD15 connector on 0.1” perf board by bending the center row pins one direction while bending the outer rows pins the other direction. With few nudges and adjustments, you can line up all 15 pins on 0.1” spacing and solder to the perf board. I’ve done this half a dozen times successfully.
Bill

Oddly I just stumbled on this sketch for a similar circuit, I don't remember drawing it though. I think the main difference is that for some reason I was planning 15 scanlines per character, perhaps because that fits in RAM more snuggly. I've spotted some mistakes in it, and details are left out, but thought I'd share anyway!

You can also buy cheap (<10USD) breakout boards with screw terminals for VGA.
you can directly connect to some wires to it and and then to a bread/perfboard.
Making a custom breakout board isn't that complicated, since your just adapting from one connector to another.
though be warned that it can be a slipery slope of "while i'm at it i might as well also throw xyz onto the PCB too".
i should know because that happend while i was making a little example breakout board.

Default, nothing extra: Slightly more advanced, with included 2-bit DAC for each color (RGB 222, resistor values are on the back):
(note that R/G/B0 refers to the LSB of the DAC while R/G/B1 is the MSB) i made sure that the connectors (which go on the back of the PCB) are spaces exactly like a DIP-40 wide IC. so it should fit onto a regular breadboard/stripboard or even in a DIP-40 (or similarly wide) socket.
also there are quite a lot of different connectors for VGA, specifically they differ in the distance between the rows of pins. this board is design around a 2.54mm distance between the rows. this one from Mouser should fit according to it's datasheet. though i can't 100% confirm that.

anyways, here the KiCad files for the DAC one, and the gerber files that you can upload to JLCPCB, PCBway, etc to order them: