Keep it strange.

 a single nop between a write-transaction and a read-to-verify-transaction results in an error-rate of roughly 10% to increase to something like 500%... weee!

Indeed, it would seem to be a sync-issue combined with my funky-bus-implementation. 

But the odd thing is that even though my bus-implementation is funky when compared to the spec, it should still be aligned, properly, with clock-edges, no matter when it's called. And, bus-spec-wise, there's nothing stating that it should be a certain number of bus-clocks between one transaction and the next. All I've done, bus-wise, is insert another clock-cycle during the idle-state. Which, on an 8088 would be the same as running a really long instruction inbetween...

...so then, I guess, this must be something with the CGA card... wherein I've looked into the IBM techref on their implementation as well as the 8088's BIOS assembly-listing accessing the CGA card, and it would seem neither are affected by a few delays here or there (in the form of instructions, nevermind unpredictables such as bus-waits due to DMA, etc.). CGA-card-wise, there's the fact it's been physically abused... but it does seem to work properly, in these regards, under POST and DOS.

The best technically-sound explanation I can come up with is that maybe the clone CGA card doesn't allow bus writes/reads to VRAM when it's being accessed for pixel-updates on-screen. Maybe inserting that NOP somehow aligned my writes/reads with the pixel-accesses. But utterly-shocking to imagine a card which can *only* be accessed during h/v-retrace. (what happens when a read of the status-register indicates it's retracing and thus OK to write, the next instruction being a write to VRAM, but that VRAM-write is delayed due to a background/timed DMA transaction such as DRAM-refresh?)

The *best* explanation I can come up with is that it's possessed by demons. That'd probably go along with your System-Error during posting :)

Yeahp, more experiments tonight... At this point I think I'm at pretty much over-doing the process of assuring it *should* work. I'm checking for h-refresh between every write-read operation between every byte, and still getting about 50% writes. Even weirder is that it's claiming to be verified, but the actual on-screen data isn't correct.

Maybe it's an ISA thing. Debating how to check that... Maybe a memory-card with only an SRAM on it. Maybe I could write/read a register on e.g. the serial-card or parallel-port.

Calling it quits for the night. This is crazy.

I looked into the original IBM card's schematics and I don't see an IRQ nor DMA line in there... 

I did write/read/verify testing on the parallel-port (which is onboard the same card) with no errors!

The latest log is more-informative... I thought I had it, and then I didn't.

checking for h-refresh before *every* read or write transaction, first it worked perfectly, then I inserted a NOP, and it didn't. Insert a few more and we're almost exactly right back to where we started (even before hsync-testing).

I suppose if I want to be scientific about this, I should probably repeat this same code in DOS on the original 8088. And/or actually try to debug the weird-character-printout issue (shorted/floating traces?). Ahhh, maybe I'll try shutting off the video-output and writing... make sure it's pixel-drawing-related.