CGA clock and AVR->8088 Bus Interface

The most-recently-logged experiments with CGA resulted in some interesting patterns. This is the most-boring image, but most-explanatory:

In the image, I attempted to write the letter 'A' to every location. Instead what I get appears a bit like "beating" in the physics/music-sense. It's almost as if the timing of the CGA card's clock and the timing of the CPU (an AVR, in this case) clock are slightly out-of-sync. So, most of the time, the two are aligned well-enough for the 'A' to be stored properly in the CGA's memory, but sometimes the timing is misaligned so badly that the 'A' comes through as some other value.

Frankly, I kinda dig the patterns it creates... it's a lot more visually-interesting than ones I can think to program...

(And check out previous logs for other interesting examples)

Those, again, are the result of nothing more than writing the letter 'A' to every location, and choosing different background/foreground colors. The above is with a foreground color of red and a background color of white. Where it differs, it appears that the background/foreground "attribute" byte wasn't written properly.

(Also, interestingly, the font appears to be messed-up with different color-choices. That's an effect I think due to the CGA card's age/wear, as it's visible as well in DOS, via the actual 8088 chip, and described in previous logs, as well.)

But, I suppose in the interest of science and progress, the trouble--of data not being written properly--needs to be shot.

-----------

A brief review, gone into a bit of detail in past logs:

The CGA card has a space for an onboard clock-generator crystal and space for jumpers to select it, but that circuitry was not populated, and the jumper was hard-wired to use the ISA-slot's clock-signal. In early issues setting up the system and trying to debug the weird-color-font problem, I wound-up adding an onboard clock-generator, and those jumpers, and have swapped those jumpers numerous times since.

----------

So, here's a result when the jumpers are set to use the ISA slot's clock:

This differs from the one at the top in several ways...

First, the white lines... My explanation for that is that those are "characters" that carried-over from a previous 'mode'. What I'm doing (now) is writing all the 'A's AND the attributes. The entire screen, currently, was supposedly filled with attribute=0x01 (=='mode 0x01'), which should be the letter 'A' in blue (if I recall correctly). But, in a previous mode it wrote 'A's with attribute=0x7f, which is white-on-white. So, again, it would appear these lines are the result of characters that weren't rewritten in this 'mode' (nor, apparently in mode 0x00).

OK. And that, too, might explain the black lines, as being carried-over from mode 0x00, which would be black-on-black.

Although, previously, I thought all bytes were being written, just incorrectly (e.g. the white/red 'brick' example, above). Maybe it's not that they're being written incorrectly, but that they're just not being written at all. Plausible, but questionable... So, the black characters in the 'brick' example are those that started either with attribute 0, or with a white-space character... either the character and/or the attribute were not written to those slots. Then there's the 'A' which comes through on a black-background. Where only the attribute wasn't written. OK. But then... this *is* the memory-initialization scheme (in that image), so those bytes likely weren't set to attribute 7, rather than just random-data... I dunno. Let's pretend the power-up default is an initialized memory suited for text-display, white-on-black. OK-then.

The problem with the theory that it's only *not* writing bytes (as opposed to writing invalid ones)...? Maybe nothing. For some reason I thought it was mis-writing data, earlier... e.g. ASCII character '0xff' appears as a space... this might result from reading a floating-bus, if the timings are wrong. OTOH, I can't think of any examples from before where those "errors" couldn't be explained by *not*-written data (as opposed to *mis*-written data).

Oh yes I can.

When I write the mode-number in the upper-left corner. The first incarnation of that code simply wrote the mode number and attribute ten times, to assure *exactly* that *not* written data would be overwritten. And yet, there were numerous times I could actually see it change from the proper character/attribute to another. Thus, I explicitly rewrote that routine to write-then-verify-then-repeat until verified correctly.

So, no, there should be cases where the attribute, at least, is *mis*-written. Bit I don't see that here (could that be a result of having switched to the ISA-clock?)

-------------

Oy, OK.

Observation Number 2. ALIGNMENT. Note how in this image all the errors are aligned vertically. In the earlier "brick" example, the errors were somewhat randomly staggered. This, initially, indicated to me that, indeed, the system-bus clock and the onboard CGA-clock were slightly off, and thus "beating".

But yet, why would we get perfectly vertical columns...? Or, let me step back further and start with: If they're no longer beating, and in fact perfectly-synchronized, then why isn't the screen, now, filled with 'A' all with the same foreground/background color...?

I suppose there are *numerous* other possible causes for "beating"... there's definitely the possibility that my AVR's bus isn't timed *exactly* right, and if it was *just* on the threshold of some setup/hold times, it might come through sometimes, but not others.

(I should interject: I've not noticed this effect when running DOS on the original 8088, and if it's as common as it appears here, DOS would probably be darn-near illegible).

There's another possibility I've just thought of... The BIOS assembly-listing explicitly waits until a horizontal-retrace (or vertical) before changing a character (in the cases I checked).

ACCORDING to the CGA-card reference from IBM, this shouldn't be *necessary* as the memory is multiplexed in favor of the 8088-bus (over the pixel-drawing), but the effect is allegedly that writing to the memory when a pixel is trying to read from it could cause visual artifacts *during that refresh*. No problem. But, these aren't visual artifacts that disappear after the next refresh! These are persistent artifacts.

OK. BUT the BIOS explicitly handles that... so, say... This CGA card is a clone... (I can't find any data on any of its markings). It was *probably* designed for PCs, which they probably knew to have retrace-testing. In which case, it's plausible, that the card isn't nearly as sophisticatedly-implemented as the original IBM one... in which case, if the pixel-drawer was trying to access the memory at the same time as a bus-access, it might just completely *block out* the bus-access. Plausible.

I think I had some other ideas, too... But let's stick with that one. THEN, that'd explain why I haven't seen this in DOS.

But then... what would explain why the "error" is perfectly aligned in columns...? I'm just looping through each memory-location writing the character and attribute, not paying *any* attention to the video-card's "safe to write" signal... Would seem utterly amazing if that loop just happened to align darn-near perfectly with horizontal-syncs.

------------

I'll leave it at that.

Here are a couple fun ones from the original completely unexplained groovy randomness (which may have as much to do with the as-yet unexplained timing/write-errors as with a bad trace or twelve on my CGA card) These are nothing but the letter 'A', background/foreground colors, and unknown-effects:

Graveyard: