Hello, and congratulations on your troubleshooting work.

Personally, I would make sure that the CPU is working, but here from the link I see that it is welded, but there is the possibility of adding a socket for CPU 386 (normal), here maybe it would be interesting to add the socket, and see if deactivating the welded CPU, something changes.

It is not necessary to disconnect the 386DX, just connect a PIN, if I remember correctly.

Then anyway, the socket could be used for a possible faster CPU, if by chance you have a 486DLC or similar.

Yes, I already did a socket mod on similar board and I just sucked solder out of vias make it ready for PGA socket, so that's the plan to try with PGA CPU but I have a feeling that's not the problem. But it's faster than searching a broken trace...

RayeR wrote on 2026-01-30, 00:38:

Yes, I already did a socket mod on similar board and I just sucked solder out of vias make it ready for PGA socket, so that's the plan to try with PGA CPU but I have a feeling that's not the problem. But it's faster than searching a broken trace...

Ok Thanks, in my opinion since it is not working, try a different CPU, it can make it clear if the other (welded) has a problem, as you suggested it could be a trace, I don't know if you tried to see the individual PINs, if someone moves it means that you need to renew the weld, if you haven't already done it.
If you're interested, in the link I'm adding, it's working on a 3/486 PC, but for now it's reached part 2, but maybe you can find some things to try, I hope it can help.
https://www.dosdays.co.uk/topics/386_motherbo … _repair_pt2.php

Hi, nice job...
Sorry for the rather naive question, but did you measure the resistance of the D7 line to +5V?

Yes, I used diode-test to measure Vf of PN-junction of input diodes and D7 on CPU doesn't indicate any difference to other Dxx pins...

I explored chipset pins connection on donor board with desoldered chipset. There I found direct connection of D7:D0 between both chips. But on my MB, that I repaired, it was isolated by 74F245 driver. While 83C306 has connection of D7:D0 directly to ISA bus, 83C305 has D7:D0 behind the driver so this caused that I before could't find the direct data connection but of course it is there. I updated the picture in 1st post and added a netlist of some MB components interconnection. Maybe it help someone else...

So the root cause of problem was broken PCB trace between 83C306 and ISA bus pin D7. It was connected to ISA slot 9 which is closest to SIMM slots and battery too! The trace goes from chip on bottom side then through one via under SIMM slot and continues on top side to ISA bus pin A2 (D7) and this is the place where trace was eroded from via of ISA pin. As it is under ISA slot it was not clearly visible. But I managed to solder a hook-wire around the pin and connect it to the trace and yeah, POST started!

But there's another problem with keyboard - sytem halts at CMOS setting mismatch press F1... and POST code 85h but it doesn't respond to keyboard. I checked takt traces KBCLK and KBDATA goest from KBD DIN to KBC inputs 1 and 39 and also to some invertors 7405, 7404.
I tried to swap KBC from similar MB and this KBC is working in that board but swapped KBC doesn't work either. 🙁
No idea, is there some schematics of KBC circuit of similar MB for reference?

I also did PGA socket mod. There's a solder jumper below onboard TQFP CPU (pin 54 - FLT# to GND) so I soldered a tiny SMD switch to it...

I looked at KBCLK and DATA with scope and there seems to be some problem witk KBCLK.
After I hit some key 1st time the clock and data seems to be OK except the CLK never return high as it does on MB with working kbd...

Hi
Loving this thread so far as Im balls deep into 486 motherboard schematics/pcbs at the moment myself 😀 (https://github.com/raszpl/M8SBC-486 <- fork of amazing https://maniek86.xyz/projects/m8sbc_486.php by Piotr Grzesik)

Keyboard interface is open-collector so either something wrong with pullup resistor between inductor and Q1/2 transistor, or insufficient keyboard supply voltage (L3? connector? cable?) making its mcu crash in the middle of communication?

I have found some reference PC AT KBC circuit in IBM manual. Yes it's simply 3 invertors with O.C. out because 8042 don't have bidir. ports. I already added connections to netlist in 1st POST and drawn schematic below...
I tested the invertor logic in static mode with KBC removed when I stimulated P26, P27 KBC pins and watch the CLK and DATA. Both responded as expected. Measured H ~ 4,9V and L ~ 0,35V that's in tolerance of datasheet. There seems to be other connections anywhere else like to chipset etc.

I also have suspection that problem may be caused by replaced chipset that I changed from xxFC to xxAFC version. As there's no datasheet nobody knows the difference. But as I see on photos on TheRetroweb the same MB sometimes have different chipset versions so probably nothing serious. To be sure I burned an EPROM with Mr.BIOS for Octek Jaguar V that existed with AFC chipset version. Mr. BIOS has one advantage that after reported CMOS error it doesn't display it next time and continues to boot. So my MB with XTIDE enabled IDE controller was able to boot in DOS fine! But damn still without working KBD input. I added to autoexec.bat calling of scancode utility but doesn't capture any but on scope I see one byte as above and CLK locked low - this is enforced by KBC that drives P26 high so invertor do what it is supposed to do - hold CLK low...

The BIOS even recognize if KBD is present or not - if disconnected it displays usual "Keyboard error". Also I notice that after HW reset I see KBD LED blinks for a moment as KBC performs KBD reset (also captured on scope, some Bytes transfered) so it seems the output from KBC to KBD works OK but not the opposite way... I also scoped voltage on DIN power for KBD but din't see any significant drops.

BTW I already found Manike's 486 MB but disappointed that it lacks DMA and second IRQ - maybe added in FPGA logic?

Hmm what Q1 Q2 transistors are for then? it seemed obvious those would be the buffers. Anyway clock held low deliberately is KBC inhibiting communication. Looking at that scope screen you got start bit 0, then 00000101, then bad parity bit 0 (should be 1), then KBC inhibits communication. Have you tried different keyboard?

Keyboard is working with other MBs. I got another idea. What if the problem is on the other side of KBC? I think it should generate some IRQ when scancode received and BIOS should read it. But what happens if IRQ doesn't arrive and KBC is not properly handled? Maybe it may tie down the clk to prevent keyboard sending more data (that will hold in keyboard buffer until read out). I can imagine there's another broken trace that is responsible for KBC-host signalling. Q1,2 dunno,.not related to kbd...

Yes, it proved to be KBC to chipset IRQ signalling problem. I tracked KBC pin 35 trace and it ends nowhere - eroded near the battery. It didn't look much bad but it was broken. It should go to 83C306 pin 123. Fixed by a thin wire and now the MB seems to be fully working, hope there are no more broken traces. Now doing some benchmarking to compare with KMC-A419-8 and Mr.BIOS vs AMI...
ISA doesn't run stable at 20MHz here, I had to drop down to 13MHz. Schema & netlist updated.

You posted just as I was preparing my reply 😀

RayeR wrote on 2026-02-01, 16:29:

I think it should generate some IRQ when scancode received and BIOS should read it. But what happens if IRQ doesn't arrive and KBC is not properly handled? Maybe it may tie down the clk to prevent keyboard sending more data (that will hold in keyboard buffer until read out).

Thats exactly what happens! Interrupt is held high until first 60h read.

RayeR wrote on 2026-02-02, 00:30:

Yes, it proved to be KBC to chipset IRQ signalling problem. I tracked KBC pin 35 trace and it ends nowhere - eroded near the battery. It didn't look much bad but it was broken. It should go to 83C306 pin 123. Fixed by a thin wire and now the MB seems to be fully working

This is bizarre. because it does look like keyboard is sending wrong parity on your scope shot, even number of data bits should be followed by active parity bit (https://youtu.be/7aXbh9VUB3U?t=1213), and that should trigger retry from KBC with no interrupt activity.
Glad it was an east interrupt line fix tho.

RayeR wrote on 2026-02-01, 05:23:

BTW I already found Manike's 486 MB but disappointed that it lacks DMA and second IRQ - maybe added in FPGA logic?

Im already working on it. This is Piotr Grzesiks first ever 4 layer pcb, and second ever fpga project. Dude is still in high school! He was space, cost and FPGA IO constrained (pcb donated, fpga from scrap) but still wanted to use real chips thus no cascaded PIC and no DMA. Keyboard implemented in fpga was a big compromise, so was janky ISA handling (bale permanently low hehe). Have a look at the vhdl and diagram. Its all super well documented, intuitive and approachable. Project is well structured and easy to follow, every single aspect feels obvious and easy, its a true hello world of implementing 386/486 chipset from scratch. Made me really excited about making my own version.

I'll have a look on parity but I scoped also the communication on good MB and data frame looks the same except CLK goes high after some delay so parity was the same too...

BTW I found this MB/chipset has stability issues with 4MB modules like some others. I tested the same chipset some years ago and it had problem too. I tried various modules, also my own made with pre-tested memory chips and nothing works stable. Win95 crashes very soon after boot, Quake was not able to complete timedemo... Even with relaxed timings. Some other 386 MBs are less picky but I still didn't find any which would be 100% stable with 8x4MB (32MB). While with 1MB modules it seems to be fine but Quack need more than 8MB I think...

Yes it's a nice FPGA project. Or some FPGA-based GPU or video scaler... I also have mined some old Xilinx FPGAs (Spartans and one Virtex) waiting for some day may be... but FPGA world is another deep rabbit hole that I don't have enough time to follow. I had one semester about PLD/FPGAs and found VHDL too 'mind-blowing' / buf for me hard to think differently compare dto classic sequential C/ASM programming of common MCU/CPU. It's a different world. Also I'm a bit scared of today FPGA dev tools taking tens-hundreds of GB space and hours of compiling. I have a few coleagues at work who do FPGA dev. and sometimes they get so frustrated by Xilinx dev. tools 😀

I uploaded here a bit zoomed scancode scope and manually decoded it.
I can't find any problem. The parity is odd, so there are 2 data bits=1 plus one parity bit=1 so it gives total 3 ones bits (stop bit is not counted in) - odd count. Data is 05h - scancode of F1 key that I really pressed.

Any Ideay why some 386 chipsets don't like 4M chips like TMS417400ADJ-60? I tried all my 4MB (old and homemade - A.Groza design) modules and all was very unstable so I was unable to finish benchmarks and have to replace it by 8 x 1MB modules and with them it's stable... Maybe is it something related to refresh? I can see in datasheet that refresh period of 4M chips and 1M chips differ: 16ms vs 32ms, there are some low-power variants with 128ms. As there's no datasheet noone knows if the chipset supports faster configuration...
Re: 386 Systems and Memory Instability With 4mb SIMMs? (Errors)