A convection cooled 486-33 is perfectly OK, but it is supposed to get hotter than comfortable to touch. A case temperature of around 45°C to 50°C is likely fine.

The UMC82C206L chip is one of a (it feels like) a million of clones of the classic C&T 82C206 chip, which is part of the NEAT AT chipset. While possibly this clone is uncommon on 486 mainboard, most ISA and VL boards up to 486 boards have a 82c206 clone. Even some 486 PCI chipsets still mention in their datasheet that the south bridge "contains a 206 macrocell", which means they cut-and-pasted the 82c206 as a part of a bigger chip. Other parts of the chip may be created from assembling complex logic from simple cells using a hardware modelling process, the 206 is a ready-made block (not a simple cell, but a "macro-cell"). The 206 contains most of the basic Intel chips that make up an 80286 mainboard, for example the DMA controllers, the Interrupt controllers, the Programmable Interval Timer. The 80c206 is (mostly) just an ISA device, and as every board with ISA slots has an ISA bus, it universally fits with any ISA-based board. The presence of a 206 does not tell you anything about the board architecture (except that it is not EISA, because EISA replaced the DMA controller which was originally intended for computer designs of the early 80s with something slightly more sensible in an AT environment).

So, you face general instability of your system. The POST codes you mention look like the boot process of a boot-block based Award BIOS. This type of BIOS has a small recovery BIOS and a decompressor at the end of the ROM chip which initializes RAM, then decompresses the actual BIOS into a portion of RAM. I'm surprised to see a boot-blocked based BIOS on a mainboard of that generation, because this kind of BIOS layout makes more sense with a flash ROM, in which an untempered boot block is still enough to re-flash your BIOS. Your system, though, does not contain a flash ROM chip, but a classic UV-erasble ROM. POST codes C0..C5 are used during memory initialization and decompression of the actual BIOS by the boot block, before control is transfered to a standard Award BIOS, which starts at POST code 00.

Your symptoms scream "memory issues" to me. So my recommendation is to strip down the memory system to the minimum possible. Pull the cache chips (no need to change jumpers, the BIOS is supposed to detect missing cache chips and just not enable cache), and reduce to 4 SIMMs. Likely you only need SIM1..SIM4 for operation. If you still get the same issue, swap the SIMMs in the board with the 4 SIMMs you just pulled from SIM5..SIM8. Connect a PC speaker, because beep codes may be interesting. Your POST card might contain a speaker and a cable you can use to connect that speaker to the mainboard.

You can try carefully reseating the cache ICs, keyboard controller and BIOS, sometimes it helps.

Ahh, and some 486 motherboards just plain refuse to boot without a battery connected.

You can try to connect the pc speaker, in case something decide to beep, it can help. You can remove all SIMMs and inspect the sockets' condition, and clean it with a brush and alcohol of needed. Inspect the SIMM memories contact pads themselves, sometimes they're corroded or worn from usage, which can cause issues. You can select the 4 most preserved SIMMs and plug them into Bank 0 for testing. If you can test these SIMMs on another machine (if you have or a friend of yours has one available) it will reduce the testing guess-work. Also

Also, the usual boring stuff will also help - check the voltages are within range (especially the +5V), check for +5V on the VCC pins of the bigger/more important chips on the pcb, check the oscillators are running and producing well-formed clock signals (if you have a scope), check the ISA bus clock, check the reset signal pulses during power-on and reset button press.

I think that if the POST card is showing different codes, this means cpu is highly unlikely to be fried. If you can cause RAM error beeps during start-up, that's also good - the beeps are generated by the cpu+kbd controller so they are working. The cpu being hot is quite normal - that's 2.5W of power that has to be dissipated somehow.

Thank you for your help, picmaster and mkarcher! Only today was I able to get back to this board, and I started testing your suggestions.

To begin, I plugged my POST card and my speaker. I also put a heatsink on the CPU, to prevent it from getting too hot.

As first step, I soldered a lithium battery with a diode to the battery terminals. This seemed to stabilize the boot process, as after that I no longer got any "random" codes in the POST card, and I started getting "C5 C1" consistently, except a few times where it would show "d0 C5". Some progress at last!

Then I removed the RAM sticks, put some contact cleaner in the slots and tried to clean them with a toothbrush, and used an eraser on the contacts on the sticks. I hadn't noticed before, but there were two sets of sticks, four with golden contacts and four with silver contacts. Just to choose one, I put the 4 with the golden contacts in BANK0 and turned on the PSU...

"beep"

...

It booted! It complains about a few things, but cache size is correct, image is crap likely due to my video card, but the board works!

Now, about the errors:
* When I put the rest of the RAM sticks the board boots, but RAM size displayed doesn't change. So it seems I do have an issue with my other RAM sticks
* The keyboard is not working. I have just one keyboard I can test, and I know the keyboard itself works, so I'll see if there is any issue with the keyboard traces or the keyboard controller chip

In any case, I have a working board, thank you very much for your help!

picmaster wrote on 2025-10-23, 23:22:

If you can cause RAM error beeps during start-up, that's also good - the beeps are generated by the cpu+kbd controller so they are working.

I know people generally say that "the keyboard controller" is used for interfacing with the PC speaker, but technically, this is wrong. As the original poster is having keyboard issues, I think it is fair to point out that beeps do not tell you anything about the condition of the keyboard controller chip.

The technical details are like this:

1. On the original IBM PC/XT, there was no keyboard controller, but just a general-purpose interface chip, which handled keyboard input and some other things. The code of the key you pressed or released was captured using a discrete TTL shift register, and then presented as 8-bit parallel data to that interface chip. The interface chip on the PC/XT is an 8255, which has 3 "ports" of 8 bits each, named "Port A", "Port B" and "Port C". Port A is used to read the data from the keyboard shift register and the mainboard DIP switches. Port B is used to control various things on the mainboard, like resetting the parity error / ISA NMI latch, selecting whether port A reads keybaord codes or DIP switches, and it controls pins that are involved with the PC speaker. Port C is used as status feedback port, for example to detect the source of an NMI. As the PC speaker control bits are generated using the same chip that also handles keyboard input on these computers, this is where the connection between "PC speaker" and "keyboard" comes from. The ports A, B and C of the 8255 are mapped to ISA I/O addresses 60h, 61h, 62h
2. On the IBM PC/AT (and all clones or later AT compatible system), the primitive I/O chip was replaced by an 8042-based microcontroller, which handles Port 60h (for XT-compatible keyboard input), and it can receive commands on a new port: Port 64h. This chip is what we know today as "the keyboard controller", and it was never involved with the PC speaker. On the AT, ISA port 62h does no longer exist, and ISA port 61h is handled by logic that is completely unrelated to the keybaord controller.

In short: On the PC/XT, keyboard and speaker were indeed handled using the same chip, but it is not really valid to call that chip a controller. On the AT and newer, there is a keyboard controller, but that chip is no longer involved with the PC speaker. So the claim that "the keyboard controller handles the PC speaker" was technically never true on any kind of IBM-compatible system.

carlitosbala wrote on 2025-10-26, 12:30:

It complains about a few things, but cache size is correct, image is crap likely due to my video card, but the board works!

You seem to be using an LCD monitor. That monitor samples every pixel generated by your VGA card. The LCD monitor likely knows that each line in VGA text mode consists of 720 pixels, and samples a part of the scan line that is assumed to be the visible part 720 times. As you can clearly see, the monitor does not display the full width of your text screen, so the 720 samples it takes during each line are not distributed over the full text width, but over something that looks more like 700 to 710 pixels. This will result in some samples taken "in the center" of a pixel and other samples to be taken "between pixels". It is usual for VGA cards to produce some "switchng noise" between pixels, so if the monitor samples the VGA output near the switching point, a different intensity than "at the center of the pixel" is not unexpected. Long story short: If you use the auto-adjust button on your LCD monitor, not only the image size should be correct afterwards, but also those ugly vertical stripes will be gone, because after that auto-adjust procedure, the monitor will sample all pixels at the perfect time that there is no switching noise.

Except for the keyboard error, all other errors are due to the CMOS being unconfigured.

carlitosbala wrote on 2025-10-26, 12:30:

I have just one keyboard I can test, and I know the keyboard itself works, so I'll see if there is any issue with the keyboard traces or the keyboard controller chip

The keyboard controller also works. I know it because in an AT system, the keybaord controller is actually a general-purpose controller that handles some system-management function besides its core job of handling the keyboard interface. One of the system control duties of the keyboard controller is configuring the mainboard into an XT-compatible mode, in which only 1MB of address space is accessible, and an "extended mode", which allows even DOS software to access nearly 1088KB of address space instead of just 1024KB of address space like on the XT. If that control function fails, the POST will stop way before the point you took the picture at. So you know that the keyboard controller is executing its control program. Thus, checking the keyboard traces is a good idea. Checking the keyboard socket (might be correded, it is often next to a leaky CMOS battery) is also a good idea, as is checking whether the +5V from the power supply reach the keyboard connector. If your keyboard blinks during power-up, it does receive power, but if all LEDs stay off the whole time, there either is a connection issue or a component in the +5V supply is blown. Most mainboards have an anti-interference inductor and/or a fuse between the +5V from the AT power supply and the keyboard socket. If there is no fuse, the anti-interference inductor may burn out instead if there is a short circuit at the keybaord connector.

mkarcher wrote on 2025-10-26, 13:40:

I know people generally say that "the keyboard controller" is used for interfacing with the PC speaker, but technically, this is wrong. As the original poster is having keyboard issues, I think it is fair to point out that beeps do not tell you anything about the condition of the keyboard controller chip.

Hi mkarcher. Thanks for the clarification. I just looked around to see why I had the wrong impression regarding the kbd controller involvement with the pc speaker. I guess the 1st diagram on this page is what misguided me initially:

Also these notes from Bochs ports listing, and specifically:

10061	w	KB controller port B (ISA, EISA)   (PS/2 port A is at 0092) system control port for compatibility with 8255
2		 bit 7	(1= IRQ 0 reset )
3		 bit 6-4    reserved
4		 bit 3 = 1  channel check enable
5		 bit 2 = 1  parity check enable
6		 bit 1 = 1  speaker data enable
7		 bit 0 = 1  timer 2 gate to speaker enable
8
90061	r	KB controller port B control register (ISA, EISA) system control port for compatibility with 8255
10		 bit 7	 parity check occurred
11		 bit 6	 channel check occurred
12		 bit 5	 mirrors timer 2 output condition
13		 bit 4	 toggles with each refresh request
14		 bit 3	 channel check status
15		 bit 2	 parity check status
16		 bit 1	 speaker data status
17		 bit 0	 timer 2 gate to speaker status

But I also checked 82C836 datasheet (386SX AT chipset) I have available, and here is an extract supporting your statement:

Seems that port 0x61 has a dedicated i/o address decoder and register, all unrelated to the kbd controller. And of course pc speaker is connected to a chipset dedicated pin, and not to a 8042 pin. Which makes me agree with your remarks.

Regards.

Ha, glad it started to work 😀

carlitosbala wrote on 2025-10-26, 12:30:

It complains about a few things, but cache size is correct, image is crap likely due to my video card, but the board works!

I have 1 or 2 ISA video cards with somewhat similar crappy output, and my assumption is either bad power filtering (maybe bad caps? too lazy to check it) or just coupled noise from the mainboard into video dac. Or just overall crappy video card, who knows. I've also put other cards (both ISA and PCI) on the same mobo and all the others have nicer output on the same LCD.

So I bet your issue is also a crappy VC.

You can clear CMOS with JP7, this can help get rid of some of the error messages.
Also you can try to temporarily disable the keyboard diagnostic (JP19 = open) and see if the boot advances a little bit more.

picmaster wrote on 2025-10-27, 00:37:

Hi mkarcher. Thanks for the clarification. I just looked around to see why I had the wrong impression regarding the kbd controller involvement with the pc speaker. I guess the 1st diagram on this page is what misguided me initially

I don't blame you for having this wrong impression. As you noticed yourself, the claim that Port 61h is associated with the keyboard controller is very widespread. There are many sources that are misleading or just plain wrong, even in files shared via BBSes before worldwide public Internet access was a thing. The diagram from the OSDev Wiki is plain wrong. The page that contains this diagram is mostly correct, and just deals with the actual keyboard controller ports 60 and 64, even the diagram has these port numbers explicitly listed, but those ports have undoubtedly no association with the speaker at all. The top part of the diagram needs to be removed. Timer 3, the and gate and the speaker do not belong into this diagram.

picmaster wrote on 2025-10-27, 00:37:

Also these notes from Bochs ports listing

I believe you, even without following that link, that you found this listing in the Boxes repository. Nevertheless, I want to point out the original origin of that snippet: It is part of "Ralph Brown's Interrupt List" (RBIL), one of the most comprehensive resources about DOS and BIOS services, as well as I/O port level programming of common PC hardware. It wrongly calls it "keyboard controller", but at the same time correctly refers to the name "port B" of the 8255 I/O interface chip of the PC/XT. This level of inaccuracy is the norm.

picmaster wrote on 2025-10-27, 00:37:

Seems that port 0x61 has a dedicated i/o address decoder and register, all unrelated to the kbd controller. And of course pc speaker is connected to a chipset dedicated pin, and not to a 8042 pin. Which makes me agree with your remarks.

On the original AT mainboard, the speaker is connected to a transistor, driven by the output of an AND gate (the gate shown in the OSDev diagram), which combines the output pin of the timer with bit 1 of "Port B". Furthermore, bit 0 of "Port B" is connected to the "gate" input of the speaker timer channel. All of these parts: The 8254 timer, the system control port B and the AND gate are integrated in the 82c206, while the 8042 KBC is not.

Hi again,
I didn't answer it before, but the behaviour I see from the keyboard is that it flashes twice when the board turns on. That's all.

I checked if all pins in the keyboard connector linked with pins in the KBC, and they do:

KBC pin 1 is CLK
KBC pin 5 is +5V
KBC pin 20 is GND
KBC pin 39 is DATA

I have an usb oscilloscope, so I tried it on those pins in the KBC and it seems both DATA and CLK are being pulled up to +5V and staying there. Both have 4.7k ohm resistance to +5v, so that I guess is correct.

I removed the sticker on the KBC, the model is NEC D80C42C-317, so a microcontroller. I found a datasheet for a slightly different model and assuming pins match, I think CS and RESET signals are correct, but of course can't be sure. In different pins I see an 8MHz sinusoidal, a 500kHz pulse, and some signal activity, but nothing on the pins that are actually connected to the keyboard.

Just to try something different, with the battery on and the board off, I shorted the "82C206 DISCHARGE" jumper and left it for around 10s. That got rid of the "KEYBOARD ERROR OR NO KEYBOARD PRESENT" message in the boot screen, but did nothing to make the keyboard work.

As a second "just to try" thing, I put a different KBC in the socket, after verifying the pins I had identified matched. I got the same behavior: same messages, same two blinks of the leds, and no working keyboard.

I guess it is time to start following traces and checking logic chips, especially those below the kbc. But it would be very useful if you had any more specific suggestion than that 😀

By the way, to answer the questions I still didn't answer:
* Indeed using the auto-adjust feature of the monitor got rid of the bands and gave me solid color 😀
* Shorting JP19 causes a boot loop, instead of staying at the error screen the motherboard shows a message like "MANUFACTURED POST LOOP" at the bottom and restarts after the POST process finishes.

carlitosbala wrote on 2025-10-28, 19:50:

As a second "just to try" thing, I put a different KBC in the socket, after verifying the pins I had identified matched. I got the same behavior: same messages, same two blinks of the leds, and no working keyboard.

Two blinks is actually interesting. You expect one blink from a typical keyboard on the power-up reset, but the second blink would indicate the keyboard controller sent a reset command to the keybaord (which it is supposed to do during POST). As you said you see nothing on CLK/DATA, I wonder whether you missed that single byte that causes the reset, or the reason for the second blink is entirely different.

Are you aware that there are two kinds of keyboard controllers? There are AT-style keyboard controllers that can interface with one AT-type device (the keyboard), and PS/2-style keyboard controllers, that can interface with two AT-type devices (a keyboard and a PS/2 mouse). Those are not interchangable! Some modern keyboard controllers can detect whether they are installed in an AT-style mainboard or a PS/2-style mainboard, but it might be that your spare KBC is PS/2 only.

It's OK you see +5V on the CLK and DATA line, because, as you said, there are 4.7k pull-up resistors. It's not OK that these lines stay high all the time, though. The keyboard controller is supposed to send the RESET command during POST, so you should see activity. Oh, wait! There is another chip in the equation: A driver chip. You traced the keyboard to pins 1 and 39, which are input pins to the keyboard controller. The keyboard controller is too weak to drive the keyboard cable, so it has a "little helper", typically an 7406 hex inverter chip, which is used to send signals to the keyboard. Pin 38 of the 8042 is the data output and Pin 37 is the clock output. On AT-style keyboard controllers, clock is inverted twice, but data is only inverted once using gates in the 7406. If the 7406 is broken or has no power, it will not drive the keyboard lines low.

So check for activity on pins 38 and 37. If there is activity (only for a brief moment during POST), but there is no activity on the keyboard clock/data lines, check the 7406.

Yeah, it's quite interesting that there are no visible pulses on the keyboard connector...

@carlitosbala, you said that you have tested successfully the keyboard on another machine. Can you check if your oscilloscope sees the power-on keyboard traffic with the other machine? Also, please double-check the pin-numbers of the keyboard connector to avoid mistakes, as sometimes we're trying to measure non-existing things...

U15 - I read it as 74HCT04 or 74HCT06, not sure.

Also, it's possible all the ICs to be properly working, but to have a pcb trace (between 8042 and connector) damaged underneath the mobo due to bad storage conditions. As mkarcher suggested, this can be easily verified.

Btw, the motherboard looks very neat, components are well-aligned, with lots of free space. Nice mobo!

New update 😀

I checked continuity for the "helper" chips:

pin 37 on the kbc -> input of 7404, output -> input of 7407 (below the KBC), output -> pin 1 of the kbc.
pin 38 on the kbc -> input of 7407 (a different one), output -> pin 39 of the kbc.

I checked with my scope but mistakenly got the idea one of the 740x was faulty. I took both out, tested them in my t48 programmer, and they are both ok, as I should have known...

[rant]This was a mistake, it was just my own impatience, and created some minor damage around the pins of the chips at the back of the board. Nothing too bad, barely a scratch, but a shame because the board was in almost mint condition before. I need to learn that taking components off should be a last resort option, but what's done is done. I was just lucky the board got back to its "normal" behavior once I put the chips back.[/rant]

That was a few days ago. Today I did something a bit smarter: I took the 386 board I got the other KBC from, and tested the one from the MORSE. It works just fine, but more importantly: I see pins 37 and 38 also at +5V in this board. I guess it might not make sense if those are supposed to be CLK and DATA, but that's what I see. I did see one difference, though, and that is on pin 6 (CS#). On the 386, the pin has "bursts", it changes values. On the Morse, the signal stays at +5, with a steady oscillation of 10kHz and around 20-30 mV of amplitude.

Following the trace (with some vias in between), I found pin 6 goes straight to pin 83 on the 91A402 (one of the "MORSE" chips). Which is disappointing, to be honest, as it seems it could be the end of the road.

Any idea on what might be causing the chip to keep the CS signal disabled? Nothing seems to be in the same trace between the kbc and the 91A402, and I tried a few jumper changes in case it could make any difference but it doesn't. I guess it is not a fault but the result of some condition in the board, but how can I find that condition?

The purpose of the CS# signal is to tell the keyboard controller that the CPU want to talk to it. The CS# signal to the keyboard controller is typically generated by an address decoder in the chipset if the CPU performs an I/O cycle to address 0x60 or 0x64. The RD# and WR# lines of the keyboard controller are typically connected to /IOR and /IOW of the ISA bus. Depending on the mainboard, you may get false chip selects to the keyboard controller when a memory access to an address ending in 060 or 064 happens. This is benign, because during a memory access neither /IOR nor /IOW is active, and the keyboard controller only responds if CS# is active and either RD# or WR# is active.

Also, more modern mainboards often share CS# between the keyboard controller and the BIOS ROM. This is possible because the keyboard controller only responds to I/O cycles and the BIOS ROM only responds to memory cycles (in case of flash BIOS, memory reads and memory writes).

So, possibly some mainboard generates way more pulses on CS# for the keyboard controller than another mainboard, because either it decodes it less strict, or it shares CS# between keyboard controller and BIOS. This does not mean either mainboard is faulty. On an unshared CS# for the keyboard controller, you might only get a very small amount of pulses during POST. I recommend to use "normal" or "single shot" triggering instead of "automatic triggering" if you want to verify that CS# for the keyboard controller is driven correctly.

Looking at the result of your first POST with the "keyboard error or no keyboard present" message, I am acutally quite confident that the CS# line for the keyboard controller does work. The keyboard controller is used to allow or prevent access to extended memory, and most BIOSes I know panic way earlier if the keyboard controller chip does not respond to the CPU. Yet, assuming your diagnosis that the keyboard controller indeed does not get selected is correct, the reason might be that the 91A402 chips does not properly receive the current bus address from the CPU (possibly due to a broken trace), so it never recognizes the number 0x60 or 0x64.