Close

Don't Trust Schematics!

A project log for Improbable AVR -> 8088 substitution for PC/XT

Probability this can work: 98%, working well: 50% A LOT of work, and utterly ridiculous.

eric-hertzEric Hertz 02/03/2017 at 07:450 Comments

-----------

I'll come back to that.

First things first: Make sure you actually *call* your "init" function... Otherwise, yahknow, ports may not be initialized. And then you might see some interesting effects like "I know I'm writing 0 to that pin, why doesn't the 'scope trigger on it?!"

--------

Alright, now the 'scope shows it. Excellent.

Next step: Check that the 8288's responding to my AVR's control signals...

Checking the 8288's ALE output I see: Yep, there's a nice pulse coming out of the 8288's ALE. Excellent! Somewhere in my understanding of the 8088's bus-timings, I think I got *something* right!

Checking the 8288's /MRDC output I see... It's constantly high.

My ramblings from the other day led me to the conclusion that there's a case (especially when DMA is used) where the 8088 and the 8288 work together, regardless of the fact that the bus might be in use by other devices (such as DMA). The address-latching is definitely a part of that.

*IF* I can trust the schematic, (and, again, I'm working with a *clone* motherboard, not the IBM original that the schematic is supposed to relate to) the result is that when a DMA is in progress, the 8088 can still perform the vast-majority of a bus-transaction, but will be stalled by the READY signal's being unasserted. That means that the 8288's ALE must be strobed, to latch the 8088's requested-address, because the address-request happens *before* the READY signal affects the bus-transaction (by inserting wait-states).

So far, this is all looking pretty good.

In other ramblings from the other day I also came to the conclusion that I've left a few control-signals floating, which could feed back into the system causing trouble... The DMA controller, for instance, might be allowed to take control (even though it's not initialized). Or, judging by the slew of glue-logic that controls such things, it's entirely plausible the 8088 outputs I didn't implement (which are floating) might make it *look* like the DMA's doing its thing.

OK then.

Some questions: If the schematic matches, and If I understand the schematic correctly, I shouldn't be getting READY, ever. In which case, my software should be stalling, waiting for the memory device to become ready. It's not stalling, it's reading back 0xff.

But, more interesting is the fact that the 8288's ALE happens but /MRDC doesn't... Because... I've checked the /AEN and CEN inputs... and both are low. So, address-enable is active, but command-enable is not active. That makes sense from the descriptions of these pins in the 8288 datasheet. But it DOES NOT match the PC/XT schematics, which clearly shows that /AEN is the Q output of a flip-flop, while CEN is the /Q output from the same flip-flop (and the 74LS175 doesn't allow for Q == /Q, unlike the 74LS74, where both Q and /Q can be high at the same time).

So... I think we've run into the first confirmed difference between the IBM PC/XT motherboard schematic and the clone motherboard I'm working with!

-------

The ramblings from the other day, again, listed several 8088-outputs I've not implemented. It was a bit ridiculous to think I could just leave them floating. I'll solder-up some pull-resistors next.

Discussions