POST Card Woes in PC-class/XT-class Systems

[cr1901]

Inspired by this thread, I bought a POST card to help with ROMable code, aware that DMA Refresh interferes with its function. I've been trying to play around with the card in DEBUG (o 80, ff etc), but I've had no success with getting writes to display the correct value (writes will work, but the value displayed is incorrect).

Sadly, it seems DMA Refresh ruins any utility that a POST card has on these old systems. I'm not capable of getting a proper write to the POST card, even with the small DEBUG program I have attached:

mov al, 1
out f, al
mov al, ff
out 80, al
int 3

The behavior is too consistent (much greater than 4/72 times) for me to chalk it up to "the POST card is being accessed during the recovery time of the previous memory refresh access from the DMA controller". Would've been great if the designers actually considered XT systems for this (there is a AEN signal on the ISA bus to distinguish DMA, after all).

After a certain point of repeated tests (-o f, 0 at the debug prompt), the RAM becomes corrupted to the point that what DEBUG thinks the CPU's register contents are is garbage . It's also probable that DEBUG is picking up keystrokes properly from the keyboard shift register, but is writing corrupted garbage from its line buffer to the program buffer when I hit ENTER. That said, even the first time executing the program after a reboot does NOT write the correct value to the POST card (it's always 0xE63C).

Does anyone have any ideas how to get a POST card to behave in an XT-class system? Perhaps I should burn some EPROMs and runs some small test programs from ROM. Maybe I should also just boot to ROM BASIC and use INB/OUTB (or whatever they are) instructions there.

 

[modem7]

Does anyone have any ideas how to get a POST card to behave in an XT-class system? Perhaps I should burn some EPROMs and runs some small test programs from ROM.

I pulled out of storage an IBM 5160 motherboard, and my POST card (monitors port 80h).

I burned the ROM image at [here] to a 27C256, and placed the 27C256 in socket U18.
Accordingly, at FFFF0 in the motherboard's address space was the code:

BO 33   MOV AL,33H
E6 80   OUT 80H,AL
F4      HLT

I powered on the 5160 motherboard, and as expected, saw "33" appear on the POST card.

My POST card is quite old, the one pictured at the bottom of [here]. I had recently obtained one of the various cheap Chinese POST cards from eBay, and decided to try that out. All that card did was display "FF--" instead of "33". I pushed the button on it a few times, which I believe displays any previous codes encountered, but nothing.

 

[modem7]

And, on my IBM 5160 motherboard, use of DEBUG is also reliably generating "33" on my POST card:

C:\>debug
-a100
10C0:0100 mov al,4
10C0:0102 out 8,al
10C0:0104 mov al,33
10C0:0106 out 80,al
10C0:0108 hlt
10C0:0109 
-g=100

 

[reenigne]

I think you're wrong about needing to disable DMA refresh to use port 80. Ports 80-83 map to the chip that holds the DMA page registers, but only 81-83 are actually used for DMA purposes - port 80 doesn't actually do anything (unless you plug in some other piece of hardware which intercepts writes to that port, like a POST card). Presumably that's why port 80 was chosen for this application.

 

[reenigne]

So, I think DMA refresh is a red herring. Perhaps the POST card is faulty, or doesn't work the way you think it does. What POST card is it? What's the relationship between the value that you write and the value that it displays? If you write all bytes (0x00-0xff) to port 0x80 in sequence, what's the sequence that is displayed on the card?

 

[cr1901]

I will test later today and get back to you re: the relationship between values written and values displayed. It's also possible that my POST card is poorly made- indeed it's one of the cheap Chinese ones.

Stopping DMA refresh indeed does stop the POST card from cycling through seemingly random values. My current theory is that the POST card isn't properly decoding AEN, so any address where A0-A9 equals 0x80, 0x84, or 0x300 is unintentionally accepted for writes into the post card. For DMA refresh, that happens (66000 Hz refresh/1024 ports before aliasing) * (3 ports where the POST card responds) = about 192 times per second.

Incidentally, I haven't tried reading from the card yet.

 

[reenigne]

Stopping DMA refresh indeed does stop the POST card from cycling through seemingly random values. My current theory is that the POST card isn't properly decoding AEN, so any address where A0-A9 equals 0x80, 0x84, or 0x300 is unintentionally accepted for writes into the post card.

Ah, interesting! In that case, maybe there is something I can suggest that will help. If you reprogram DMA channel 0 to accesses addresses 0x0100..0x02ff instead of addresses 0x0000..0xffff then perhaps you can refresh all the DRAM without touching the POST card. Though you may still get bogus values when accessing those addresses for other reasons (i.e. your program, stack or other data is there).

I wonder what machines this card would have worked correctly on. Is it one of those cards that has both ISA and PCI edges? Perhaps it was only ever tested in a PCI slot, and the designers made assumptions about compatibility of certain signals between ISA and PCI.

 

[cr1901]

Ah, interesting! In that case, maybe there is something I can suggest that will help. If you reprogram DMA channel 0 to accesses addresses 0x0100..0x02ff instead of addresses 0x0000..0xffff then perhaps you can refresh all the DRAM without touching the POST card. Though you may still get bogus values when accessing those addresses for other reasons (i.e. your program, stack or other data is there).

I wonder what machines this card would have worked correctly on. Is it one of those cards that has both ISA and PCI edges? Perhaps it was only ever tested in a PCI slot, and the designers made assumptions about compatibility of certain signals between ISA and PCI.

Good news- your suggestion to reprogram the DMA controller DID stop DMA refresh from accessing the card WITHOUT taking the whole mainboard down with it!

For those following along, this is the program I entered into DEBUG:

-a
08F8:0100 out c, al
08F8:0102 mov al, 00
08F8:0104 out 0, al
08F8:0106 inc al
08F8:0108 out 0, al
08F8:010A mov al, ff
08F8:010C out 1, al
08F8:010E mov al, 1
08F8:0110 out 1, al
08F8:0112 int 3

Bad news- the value I write to the POST card is still garbage .

Yes, it is both a PCI and ISA POST card, so maybe the manufacturers made some assumptions about the ISA bus in these machines (I seem to recall that modern ISA slots don't meaningfully support 8237 DMA xfers via the SuperIO chip, FWIW).

 

[sergey]

A POST card is a really simple device. Basically an 8-bit latch, with clock/set connected to an address decoder + /IOW + /AEN. And a hexadecimal decoder with display attached to the latch output.
It shouldn't be affected by DMA/ memory refresh. In this case AEN and IOW are both HIGH and latch won't be written. This is true for any PC compatible system...
Most new PC's contain 8237 DMA functionality as a part of LPC bus. That is used at least for attaching super-io chip, which usually includes floppy disk support.

 

[modem7]

Yes, it is both a PCI and ISA POST card, so maybe the manufacturers made some assumptions about the ISA bus in these machines (I seem to recall that modern ISA slots don't meaningfully support 8237 DMA xfers via the SuperIO chip, FWIW).

My 'new' POST card is pictured at [here].

I tried it in a 6 MHz IBM 5170 (IBM AT), and it works; I saw the expected DD pattern after I removed a RAM chip.
I moved it back to my IBM 5160, and 'no dice' using the DEBUG code that works when I use my 'old' POST card instead (same slot used, to reduce variable count).

So, something about the ISA bus in a 5160 (and presumably also a 5150) that my 'new' card cannot cope with.

 

[modem7]

It shouldn't be affected by DMA/ memory refresh.

The DEBUG code that I showed at post #3 works (with my 'old' POST card).
Remove the first two lines, lines that disable the DMA controller, and the code no longer works.
The question is, why?

I discovered this behaviour whilst injecting POST codes into snippets of the IBM 5150's POST. For POST codes issued before DMA is initialised, the two lines are not required. After DMA is initialised, the two lines are required.

 

[reenigne]

My 'new' POST card is pictured at [here].

I see it uses a microcontroller with its own crystal. I wonder if it's just too fast for the XT? Perhaps it's reading some of the lines before they are ready. That would explain it working on the AT. Maybe "underclocking" it by changing the crystal would work.

 

[cr1901]

My 'new' POST card is pictured at [here].

I tried it in a 6 MHz IBM 5170 (IBM AT), and it works; I saw the expected DD pattern after I removed a RAM chip.
I moved it back to my IBM 5160, and 'no dice' using the DEBUG code that works when I use my 'old' POST card instead (same slot used, to reduce variable count).

So, something about the ISA bus in a 5160 (and presumably also a 5150) that my 'new' card cannot cope with.

I have the same exact POST card. So it seems that I can at least conclude that the card itself is the problem, not anything I'm necessarily doing.