For the most part, yes. Unfortunately on most 286 mobos (except the very late ones with advanced chipsets) the KBC does have several more functions than just keyboard I/O. It controls A20 gate/mask, it can reset the CPU (and NPU), and some input port pins might be connected to jumpers, things like color/mono monitor select for example. So a swap with different KBC won't always work. Frankly I had a pretty bad record of trying to do just that but then again I've read plenty of posts where it worked (at least good enough to figure out if original KBC was faulty) - so maybe I'm just that unlucky.

So, would it be worth trying a different one - yes, if you don't have to pay for it. A swap from another mobo you have in other words. Otherwise I'd wait for some more test results. Well, unless money is not a problem, then go ahead 😀

UPDATE: Here's a set of files to program and test. EVEN goes into what is U47, ODD into U48. These are 32k images but should hopefully also work if the mobo uses only upper 16k part. I was unable to test it on my 286 mobo, I messed up a few days ago and broke a pin on one of my W27E512 - and I only have 2, ordered more but haven't arrived yet. I don't want to solder it back as the solder blob could damage the socket, so I can only hope I didn't mess this up. You should see some values on the POST card, 3 sets actually but the first 2 could be very brief so try to maybe capture a video, or de-turbo the mobo to 6MHz, or both. After the last set the code will stop, so reset to make it run again.

Please report the codes shown, and if there are none it's likely there's some ROM addressing issues on your motherboard.

Well, we have developments, but unfortunately not good ones.
I tested both 74ALS245's near the keyboard controller, both test fine.
I also swapped in an Intel 8042 in place of the 8742 that was there. Interestingly, the PCB is actually marked 8042. But now it won't throw any post codes out at all with either keyboard controller installed. As soon as it is removed, we go back to 02,01 on the POST card.
Andrew

Ah, so you do get something on the POST card without the KBC chip? You see, the BIOS code first tests what KBC has to say about the reason for reset, is it cold or warm one. It will not show any codes before that and if the value it gets is warm reset, but it was actually a power-on, BIOS will fail to initialize the mobo properly - including rather important memory refresh. So chances are it would just freeze and show no codes. This can perhaps be tested.

Remove KBC, put one lead of 1k to 10k resistor into pin 14 (just touching is fine too), other lead of that resistor connect to +5V on first try, GND on second try. Boot the system with resistor in place. Do you get POST codes with resistor to GND and none with resistor to 5V?

Give me 5 minutes, I'll try it.
Just had another thought, I'd tried the 8042 keyboard controller out of my 386SX in the 286 with no joy. But what about the untested 8742 keyboard controller from this dead 286 board in the 386SX board.
Tried it, it works perfectly, at least enough to boot into the BIOS and navigate, change settings etc.
Andrew

Deunan wrote on 2022-02-18, 22:39:

Ah, so you do get something on the POST card without the KBC chip? You see, the BIOS code first tests what KBC has to say about the reason for reset, is it cold or warm one. It will not show any codes before that and if the value it gets is warm reset, but it was actually a power-on, BIOS will fail to initialize the mobo properly - including rather important memory refresh. So chances are it would just freeze and show no codes. This can perhaps be tested.

Remove KBC, put one lead of 1k to 10k resistor into pin 14 (just touching is fine too), other lead of that resistor connect to +5V on first try, GND on second try. Boot the system with resistor in place. Do you get POST codes with resistor to GND and none with resistor to 5V?

With pin 14 connected to either VCC or VSS, through a 2.2K resistor, I get post codes each time.
Andrew

Hm, so it doesn't seem to be the reset bit, but having KBC chip in does confuse BIOS. Is it always 01, 02 though? If so it's not reading the bit, but I would not try a resistor of lower value - this is a bus and if we drive it permanently it has to be current-limited. 2k2 should be enough to force H state if the buffer chips work as they should.

There should be 146818 RTC chip nearby, see what happens if you remove it. Try with and without KBC chip. BTW the numbering on KBC tells you if it's a ROM or EPROM version. 8042 is ROM, well actually should be ROM-less and 8342 is ROM IIRC but everybody uses just 8042 name. 8742 is EPROM variant. If it has a window it can be erased, without one it is OTP (one time programmable) chip.

In the mean time, I did drop to a 1K resistor, no change.
It is is always 02,01. From my understanding of these POST cards, that means it's halted on 02, 01 having been completed.
That makes sense about the keyboard controller. Mine is an erasable variant.
So;
8742 installed, 146818 removed - No POST codes, just --,--
8742 removed, 146818 removed - 02,01
8742 removed, 146818 installed - 02,01
Both installed - --,--

I have also seen that the 146818 is compatible with the HM6818P in my 386SX board, so swapped the 146818 into that. All seems to work fine.

Andrew

02 code for your BIOS seems to be RTC/CMOS related - do you have a speaker/buzzer connected? Your POST card should have one, and a 2-pin connector + short cable to hook that up to mobo. Does this make any beeps, because a hang on 02 code should beep.

Please check if the RTC chip is getting power, that's pin 24, and if /STBY (pin 16) is driven high. It should be held low by reset signal and go (and stay) high otherwise. If it's not high, perhaps you have some issues with PWR_GOOD signal from the PSU (that or or a corroded trace, that's quite common).

EDIT: If /STBY is high or even tied to Vcc, check /CE (pin 13) for the same reset behaviour. Sometimes the mobo uses that to disable access to the RTC chip instead.

Deunan wrote on 2022-02-18, 23:48:

02 code for your BIOS seems to be RTC/CMOS related - do you have a speaker/buzzer connected? Your POST card should have one, and a 2-pin connector + short cable to hook that up to mobo. Does this make any beeps, because a hang on 02 code should beep.

Please check if the RTC chip is getting power, that's pin 24, and if /STBY (pin 16) is driven high. It should be held low by reset signal and go (and stay) high otherwise. If it's not high, perhaps you have some issues with PWR_GOOD signal from the PSU (that or or a corroded trace, that's quite common).

EDIT: If /STBY is high or even tied to Vcc, check /CE (pin 13) for the same reset behaviour. Sometimes the mobo uses that to disable access to the RTC chip instead.

Speaker is connected, a known working one too. I have also tried the piezo beeper on the POST card. It beeped at me once this evening, but I was so taken aback, I didn't make note of what code it output. I have been unable to get it to repeat this behaviour.
On the RTC chip, pin 16 does not appear to go anywhere on the board, I can't see any traces from it, nor pick up continuity from it anywhere else on the board. With the board powered on, it shows neither high nor low on my logic probe. I tried tying it high with a 5k resistor, no change to the behaviour of the board. Pin 13, CE is held high briefly, then goes low.
The power good wire on the PSU is held low, then goes high.
Andrew

Ah, so probably non-A 146818 RTC. The older ones didn't have /STBY signal at all, so it's OK if that pin is unused. /CE behaviour is correct. That being said, the test for 02 code is rather simple - BIOS writes RTC register that has some bits non-writable, then checks if those are set. If not, it goes into error loop that should beep.

So apparently this test fails, KBC is causing problems, and there isn't any beeping. So it all looks like something is wrong with the inter-IC bus for those chips on the mobo. Same 8 bits also drive ISA and you do get correct codes, so it's probably a different driver chip? BTW I've updated my post earlier, there's a BIOS test you can try, see if and how that works. Tomorrow I'll look at some 286 schematics to try and figure out what could be messing up that bus.

UPDATE: Here's another test BIOS. Rather than test BIOS ROM addressing this one tests I/O to CMOS NVRAM, since this is where original BIOS seems to die. As before, EVEN=U47 and ODD=U48, code is only in upper 16k of each file and should work in any jumper configuration.
The BIOS test is actually not a simple zero/non-zero check but a bit-walk pattern, I missed that, but it's still very simple. This test program does the very same thing, except the test is looped forever and the results are shown on the POST card - hopefully I got the delays calibrated right to actually see that. So you should get 01FE / 02FD / 04FB ... or XXYY where XX is 1 walking left and YY is the same pattern except negated. Pay attention to YY, if it is not equal to negated XX some bit is glitching (stuck at 0 or 1).

Deunan wrote on 2022-02-18, 18:57:

For the most part, yes. Unfortunately on most 286 mobos (except the very late ones with advanced chipsets) the KBC does have sev […]
Show full quote

For the most part, yes. Unfortunately on most 286 mobos (except the very late ones with advanced chipsets) the KBC does have several more functions than just keyboard I/O. It controls A20 gate/mask, it can reset the CPU (and NPU), and some input port pins might be connected to jumpers, things like color/mono monitor select for example. So a swap with different KBC won't always work. Frankly I had a pretty bad record of trying to do just that but then again I've read plenty of posts where it worked (at least good enough to figure out if original KBC was faulty) - so maybe I'm just that unlucky.

So, would it be worth trying a different one - yes, if you don't have to pay for it. A swap from another mobo you have in other words. Otherwise I'd wait for some more test results. Well, unless money is not a problem, then go ahead 😀

UPDATE: Here's a set of files to program and test. EVEN goes into what is U47, ODD into U48. These are 32k images but should hopefully also work if the mobo uses only upper 16k part. I was unable to test it on my 286 mobo, I messed up a few days ago and broke a pin on one of my W27E512 - and I only have 2, ordered more but haven't arrived yet. I don't want to solder it back as the solder blob could damage the socket, so I can only hope I didn't mess this up. You should see some values on the POST card, 3 sets actually but the first 2 could be very brief so try to maybe capture a video, or de-turbo the mobo to 6MHz, or both. After the last set the code will stop, so reset to make it run again.

Please report the codes shown, and if there are none it's likely there's some ROM addressing issues on your motherboard.

I've just tried the ones here, POST3
The first couple time I got FF,D3, but only that, unless the first couple had gone before the POST card had time to come to life. No sign of a reset switch on this board, so I guess I'll have to pull the reset line on the CPU low to reset it?
After a couple time, I was just getting FF,--
Will try POST4 now
Andrew

So, POST 4 , I get;
01,--
02,01
04,02
08,bb (66?)
10,08
20,10
40,20
80,40
01,80
02,b9 (69?)
04,02
08,04
10,08
20,10
40,66
80,40
01,80
02,01
04,02
08,bb (66?)

So, that doesn't tie up at all with what you said I should see. My understanding though is that the first 2 characters on the post card are the current code and the next two are the previous one. But maybe this is only when the BIOS is outputting codes to it, your code could be doing something different.
If I can figure out exactly where each code fits into the grand scheme of things, then I guess converting each to binary would help figure out which bits are stuck?
This is all a bit over my head, but still incredibly interesting, so I'm very grateful for your help.
Andrew

Skip94 wrote on 2022-02-19, 17:03:

I've just tried the ones here, POST3
The first couple time I got FF,D3, but only that

That's a good result - means CPU executed every instruction in BIOS ROM from 0x8000 to 0xFFFF (a couple of bytes are not tested but it's virtually impossible to have just these addresses not work when everything else does). So at least you can be reasonably sure that addressing works, bits A0 to A14 anyway. Possibly you only see that one result because the test executes too fast and also only starting at 0x8000 with your current jumper config. That is not a perfect test for all the bits on the address bus, but I think we can for now assume it works as well - since the code did execute properly.

As for the other test, the problem with POST cards is they are not very fast. I did put some delays when outputting the data, this was actually tested on my hardware and works well on 486DX2 machine, so I figured it'd be enough for 286. But possibly your card is a bit different of I didn't account for ISA waitstates properly - that might be why you see only half of the expected result. Let me look at the code and see if I can fix that.

EDIT: Oh, and another issue with POST codes is most card will not show the same code twice. So writing 0x11 to the card will show 11--, but writing 0x11 again will be ignored instead of showing 1111. This makes presenting the test progress a bit more difficult.

UPDATE: Here's another test. This time I've added more patterns then just walking bit, to also test the data bus, and more delay between writes to the POST card. Not tested though, but it's simple enough, should work. See what it does.

Deunan, does this bios code have any chipset specific code ?

It's not really a BIOS of any sort, merely a short loop of instructions for a low-level test. But no, no chipset specific code, except this particular one is for 286+ CPUs since I'm trying some of the tricks the original BIOS used for I/O delays.

I've run the latest one you posted up Deunan, rather than typing out what I get, I've taken a video of it.
https://youtu.be/kC70e06ZmBU
The 0.25 playback speed makes it so much easier to keep track of whats going on!!!
Andrew

I can make the delay longer, but I figured you'd video it anyway and this makes the entire pass a bit faster. So whatever you find easier to work with, let me know.

I'm still not 100% sure it isn't some sort of bug in my code that I'm not seeing right now, still no spare chips to actually test this properly on 286 mobo, but I do see some pattern now. So this is what the 2 writes to port 0x80 should be, what it should result as on the POST card, and what you actually get:

FE,01 -> 01FE -> 01B6
FD,02 -> 02FD -> 02B5
FB,04 -> 04FB -> 04B7
F7,08 -> 08F7 -> 08B7

So it looks like bit 3 and 6 are stuck at one (the result is negated) during reads. But this is not 100% consistent across the entire test run, weird. So I have a suggestion - pull out all the "big DIP" chips from the motherboard except what is needed to run the test. Remove both 8259A interrupt controllers, both 8237A DMA controllers, and there's still two big ones nearby that I can't read, those two as well (and please write down what these are, or maybe make another photo of that area).

Also keep the KBC out of the socket, and I see your mobo has integrated serial ports, pull that 16450 out as well. Or is that actually a 550?
Run POST4 test again with those chips out, they are not needed and I have seen those die and in such a way that they would load the bus and prevent CPU talking to other mobo chips. So this is to test that theory. It looks like writes, at least to ISA, happen properly or else we would not have aything (or not sensible) on the POST card. It could be that only I/O reads don't work, but then it should not affect the speaker, it should still beep. Unless it's only writes to ports below 0x80 that fail, which might be bad since I would expect this to de decoded by the chipset (and you tested the smaller logic chips as well). But perhaps it would be a bad contact in the socket or broken connection, not a bad chip.

Videoing works fine for me, makes it nice and easy to share too.
The two other big DIP IC's are;
Directly under the two 8237A's, its a SN74LS612N and next to the 8259 its a P8254 "interval timer"
I have now removed everything in a big DIP package except the P82C202 and both 8237's, as once they are removed, I get no activity at all. I have tried both 8237's in a turbo XT board I have laying around and they seem to at least POST, so seem to be ok.
With everything removed, I seem to see a similar sequence, I get 01,B6 -> 02,B5 -> 04,02 -> 08,B7. I do need to run this a few times though, to make sure this is repeatable, I ran out of time tonight.
Andrew

SN74LS612N is an extra chip the DMA controllers need to extend their 16-bit address bus, aka page register, in case you were wondering. Curious that the system doesn't work without DMA chips, good chances are the reason is trivial, the missing HRQ signal is detected by chipset as active and the whole thing goes into neverending bus hold. This can be tested, remove DMA chips again and pull down pin 10 of each socket to ground via 330 ohm resistor. You can use something between 220 and maybe up to 1k but the higher the value, the higher the chance it'll not be able to pull the signal low enough since some of the chipset inputs might have internal pull-ups.

Now that you've mentioned the P82C202 memory controller I realized this mobo is using Intel's AT chipset, you can find the datasheet here: https://datasheet.datasheetarchive.com/origin … DSAP0054354.pdf

So the problem we have is a write to RTC NVRAM and a read from the same location do not match. This is a very basic test and fails already, but on the bright side it's easy to verify and it's repeatable. Here's a few ideas of what could be causing it:
- Bad addressing of the mobo chips, it's not actually reaching the NVRAM
- Glitched data bus or a buffer, or one of the control signals (read/write)
- Broken or marginal connection to the 74ALS245 direction pin, which means we don't realiably switch between read and write states

Things to try:
- Gently pry other 82C20x chips out of their sockets and re-insert them. We need them all, but perhaps a bad contact is preventing correct operation? Unless you already did that.
- Write another test or two, rather than NVRAM we can target some other mobo chips that have registers we can use as a single memory cell, to see if write+read works on these

UPDATE: Two more test programs this time. Modified POST4 with longer delay and sort of sanity check, it should start by displaying 0xC003 and linger on that a few seconds, then proceed to the test proper.
POST5 does pretty much the same thing that POST4 does, except it reads and writes DMA1 count register. For this test put the DMA chips back (if not in already), and remove RTC. Let's see if that works.

Next update!
Even with pin 10 pulled to ground on the two sockets that the 8237's go in, nothing.

Deunan wrote on 2022-02-21, 22:31:

- Gently pry other 82C20x chips out of their sockets and re-insert them. We need them all, but perhaps a bad contact is preventing correct operation? Unless you already did that.

They have all been reseated already, I pulled everything when I first got it, to give the board a good wash, it was filthy.
All the chip legs have been cleaned up and all the sockets have had some contact cleaner in them. They aren't the greatest sockets in the world, but I think they are ok. Worst case, I'll just start pulling them and putting new ones in.

The modified POST 4 seems to work exactly as expected, holding on C0,--, then 00,C0, before running the test as before.

POST 5 runs, but again, not overly sure if what it is doing is right. I'll upload the video in a few minutes.
Cheers
Andrew