First post, by VileR
- Rank
- l33t
A little while ago I came across a strange little CGA issue, where certain writes to the 6845 CRTC registers were causing unexplained visual glitches.
This didn't seem to be documented anywhere else, and looking into it led me down an interesting rabbit hole. I ended up detailing my findings over two blog posts, but here's the EXTREME TL;DR EDITION:
* If the Vertical Sync Position register (R7) is modified during the active raster period, the CRTC may output an unintended vsync pulse at the instant of the *write* operation.
* This occurs even though the character row counter doesn't match the target value - a specific correlation must exist between the old *and* new R7 values and the current character row.
* There are other factors at work, such as the timing of the write operation (w.r.t. the character clock cycle), and evidently the chip's temperature(!) as well.
If you want the complete lowdown, see these links. You'll find some video examples of what I'm talking about, a lot of theoretical ramblings and bitwise formulas, and automated test results laid out in a bunch of charts.... which have a surprising relationship with the Sierpinski Triangle fractal set, of all things:
1. Old Chips, New Glitches: the CGA/CRTC "Phantom" VSync
2. More CGA CRTC Glitching: HD6845(R) vs. MC6845
At this point, I believe I have a good-enough characterization of how this glitch behaves on IBM CGA boards, at least on the 4.77 MHz PC/XT bus - whether they use Motorola's MC6845 or Hitachi's HD6845(R). We've gotten a full set of results from both chips, and the analysis is complete enough to be useful, so that pretty much ticks the boxes I really wanted to tick.
Still, it could be educational to broaden the scope of the research a bit. Evidently this behavior depends on the silicon implementation, and there were plenty of CGA clones which used other 6845-type CRTCs:
- Hitachi's HD6845S
- CIC's "8645BE"
- UMC's UM6845(R)
- the Bulgarian CM607
...and so on. Also, due to the nature of this glitch, faster ISA clock rates may change the picture as well.
If anyone feels like helping out with that, here are a few test programs:
R7MIN.COM is a cut-down version of the automated test run described in my blog posts:
- This one should run in ~6 minutes (as opposed to 20+ hours) - it covers only a small subset of test cases, but I hand-picked them to be somewhat representative.
- All status reads will be logged to a .CSV file; if you post it here, we could compare the results against the existing MC6845/HD6845R data.
- This test reduces the DRAM refresh rate (Timer 1) quite a lot, for reasons detailed in my posts. This wasn't a problem on the two systems we tested on; but if your PC hangs or becomes unstable, you can add /S on the command line, and it'll keep to the "safe" default (the results will be different, but perhaps still useful).
VSPOS-L.COM and VSPOS-U.COM won't log anything, but you can dial in any combination of parameters (old R7 value, new R7 value, CRTC character row), and see for yourself whether the telltale flickering black bar shows up. Might be helpful, especially if the automated test picks up no glitches at all - which could very well be the case, depending on the CGA card/CRTC/bus speed.
"-L" lets you test the lower range of CRTC character rows (00h-54h), "-U" is for the upper ones (55h-7Fh).
- If the selected character row is equal to one of the R7 values ("from"/"to"), you'll naturally see a stable, non-flickering black bar: this isn't a glitch - just the standard expected behavior. The interesting cases are those where all three values are different.
- R7 is in fact rewritten on *every* row. In the row you select, it'll test the desired parameters and check the status register for a vsync pulse. Elsewhere, the rewrites will simply set a default value to maintain a stable vertical sync.
So if you see the 'phantom' black bar, look for changes in the "VSync status reads" counter: if it keeps going up, your selected parameters are the ones truly causing the glitch. But if it doesn't move, then the glitch is actually being caused by the changes between one of your selected values and the default vsync position. The real values responsible for it will typically be found on the following or preceding row. - the "/S" argument won't work here, but you can explicitly specify a custom DRAM refresh rate on the command line, in hexadecimal. E.g. "VSPOS-L 12" will set it to 12h, which is the PC's normal rate. Either way, pressing space will change it to 13h, which is exactly 1/4 of the horizontal scan rate, so the glitch will appear to "stabilize"; but testing should be done with the default value (4Bh) if possible.
It'd be especially interesting to see data from one of those other 6845-compatible chips, or from any 6845 running on a >4.77 MHz ISA bus. But even if you test the same hardware we did (IBM CGA, MC6845 or HD6845R, 4.77 MHz PC/XT), the results could still be valuable. Who knows - perhaps different batches of the same chips have a different response to the marginal write timings that seem to be causing this phenomenon.
I'm not including the full two-pass automated test that truly checks every combination. That one takes a long time to run, but more importantly, the set of test-cases for the second pass depends on the results of the first one - and right now it doesn't parse them directly, so they're hard-coded into the second pass and may need to be regenerated. But if someone really wants to try it, let me know.
If you try it out, and can post your .CSV output, please note the relevant details - CGA card make and model, CRTC chip designation, machine type and CPU/bus speed. Thank you!
(Yes, some non-CGA video setups use the 6845 as well - MDA, Hercules/"MGA", PCjr, and so on. But as I don't have the hardware, I can't come up with suitable test setups, so these programs will only work on CGA).
