little update

XTAL 2 is grounded - hence no signal. Not sure whether it's not supposed to be grounded but it is and could not find a shorted component so far.

I then did a little patchwork, lifted some of the VIA legs, connected XTAL1 to GND and XTAL2 to clock. It was not very good so the connections were bad but... it booted up! The speaker kept beeping as if I was holding a key but everything worked. I ran doom and it worked fine for several minutes.

So I did a better patch work with the VIA chip and... nothing. For the life of me I was unable to make it work again. Board refuses to boot.

And yes, if I plug the VIA chip on another board, it still works. If I plug the original KBC on the affected board, the board still boots up fine. 😁

I'll keep testing! 😀

Question for the board: I've noticed that the data line of the KBC chip look very different on the affected MB than another one. On a working motherboard they look like usual: a mess of pulses. On the affected MB, there seem to be much less activity which slightly changes when using the keyboard.

When the keyboard crashes, the data lines change to a more "normal" behaviour, which is very weird.

Can I assume that the KBC shares the same ISA bus with all the other cards? I'm curious to see if there is a latch (buffer?) chip in between the CPU and the KBC chip to see if something happens to it and also to check the ISA data lines when the keyboard crashes.

With my very limited knowledge of electronics, could the fact that the KBC chip is getting "busier" data lines when the keyboard stops working mean that the latch of the KBC chip is malfunctioning and "opening" to the whole bus to the chip? This is assuming that there is a latch between the KBC chip and the bus. Apologies if I am saying rubbish here!

I still haven't fixed this motherboard - but I took a step back and decided I want to test it further as it's so weird that this issue only happens with Doom.

I tried loading Duke3D but it doesn't work on a 386 apparently?

Can someone recommend some demanding software which can run on a 386 with 8GB of RAM (no matter how fast) for me to test the system further?

Thank you!

tony359 wrote on 2022-02-15, 16:11:

Can someone recommend some demanding software which can run on a 386 with 8GB of RAM (no matter how fast) for me to test the system further?

If you have the diskspace, compiling a linux kernel might do. you'll need an old version of a linux distribution, one which works on a 386.

though with 8GB of RAM you won't need any swapspace 😁

I think any slackware pre v9 should work.

386 can only do 4GB physical and 4GB swap 😁

ahahah Sorry - so used to GB that I didn't realise what I typed! 🤣

I'll give that a go, thanks! Any chance you can point me to the right direction on "how to compile" slackware? I am a bit familiar with Linux but not enough...

Any demanding games you can think of?

tony359 wrote on 2022-02-15, 16:11:

it's so weird that this issue only happens with Doom

I found Doom to be extremly good at detecting bad cache chips or too aggresive timings set in BIOS. Keep in mind the keyboard only really works when connected to a PC, for example LEDs that light up when any of *Lock keys are pressed are controlled by PC, not the keyboard. It's not even down to KBC chip, it actually is BIOS code, so run by CPU.

Try more waitstates on RAM and cache (if installed). In fact set the worst timings you can, run Doom, if it still malfunctions it's not that, no need to run many tests. If it does cure the problem then you start lowering W/S one by one. Note that cache SRAM chips can degrade too, not just completly die with a busted location that has a stuck bit (or worse). That is difficult to find, usually needs swapping in some other chips. As a quick test you can disable the cache in BIOS, that will obviously have impact on performance but might tell you if the cache is unreliable.

a slackware 8.1 iso image can still be found on the internet. this, http://ftp.slackware-brasil.com.br/slackware- … ckware-8.1-iso/ was the first working internet link for me.
You will also need a boot and root floppy disk to start the install on a 386 if memory serves me right.

Deunan wrote on 2022-02-15, 23:40:

tony359 wrote on 2022-02-15, 16:11:

it's so weird that this issue only happens with Doom

I found Doom to be extremly good at detecting bad cache chips or too aggresive timings set in BIOS. Keep in mind the keyboard only really works when connected to a PC, for example LEDs that light up when any of *Lock keys are pressed are controlled by PC, not the keyboard. It's not even down to KBC chip, it actually is BIOS code, so run by CPU.

As a quick test you can disable the cache in BIOS, that will obviously have impact on performance but might tell you if the cache is unreliable.

I did test with cache disabled - and even with no cache if memory serves. At some point I got a "universal" KBC from VIA. Somehow it does not work on this board - but it works on all my other boards. Eventually I managed to have it working with some re-wiring, the connection was unreliable somehow but Doom did not stop working while testing. Since then, I've been unable to make it work that chip again on that board - but haven't tested much since.

But I agree with you and this is why I wanted to take a step backwards and look into other things before blaming the KBC chip.

My main concern is that when the keyboard "crashes" (ie, it's like one key is always pressed, the scene in doom keeps spinning and no other keys work) the rest of the system seems to be working: graphics and sound keep working. So my thought is: if the Keyboard fails because of an ISA bus issue, then the video card would crash as well, or not?

a slackware 8.1 iso image can still be found on the internet. this, http://ftp.slackware-brasil.com.br/slackware- … ckware-8.1-iso/ was the first working internet link for me.
You will also need a boot and root floppy disk to start the install on a 386 if memory serves me right.

I did find version 8.1. It's the "what do I do then"! 😀 Am I aiming to install or compile Slackware?

You know what? I believe I never posted the "part 1" repair video of this board! You can see the issue at 45:50

https://www.youtube.com/watch?v=Sva87qBiJfA

tony359 wrote on 2022-02-16, 10:17:

My main concern is that when the keyboard "crashes" (ie, it's like one key is always pressed, the scene in doom keeps spinning and no other keys work) the rest of the system seems to be working: graphics and sound keep working. So my thought is: if the Keyboard fails because of an ISA bus issue, then the video card would crash as well, or not?

Few things first: I see your mobo is jumpered to 40MHz operation, is that an Am386DX-40 under that heatsink? If you are overclocking a DX-33 it might just be glitching in Doom. And even if it is a 40MHz chip, did you try running it at 33MHz to see if that changes anything?
I also see some corrosion where the battery used to be, and these traces are usually to/from keyboard port, it's not impossible that some cross-talk due to conductive residue is perhaps fooling the KBC into thinking that data keeps coming in, constantly, and that breaks it. It's also close to the cache sockets - just one marignal via between memory and chipset could easily cause such problems. And these are a major PITA to find and fix.

To answer your question, I would say that broken ISA would affect graphics card way before you get any keyboard or other issues like HDD errors. So if I had these issues I'd go with:
- CPU, RAM or cache timings
- PCB damage (spill or mechanical) around cache or RAM sockets, something subtle because a clearly broken connection would kill the system completly
- PCB damage around KBC and/or local power delivery issues (though a single missing bypass capacitor should not cause such problems)
- KBC itself has somehow degraded and is glitching

Thanks Deunan,

All good points.
Yes, that's a DX40 - makes sense to try 33Mhz. I shall let you know.

The battery indeed corroded a lot, three traces were broken. I first bodged some wires at the back, then installed some thin wires. Since the issue was always there I got Necroware's (youtuber) dremel's bits, removed most components around the battery (including the cache socket), polished the solder mask away, re-tinned the traces, check for continuity and re-assembled. The issue is still there. Indeed those broken traces were the keyboard traces.

I have washed that side of the board with vinegar - can't remember if I washed the whole board in proper PCB cleaner (Electrolube SWAJ, amazing) but I think so.

I ran a memory test for hours, no issues. The only software that shows that issue is DOOM (haven't tried some others yet which I only loaded yesterday).
I have several 386 boards and I use the same RAM on all those boards and never has the same issue.
I've socketed and re-soldered the KBC chip

KBC chip: this is the fun part. It's different from any other chip I have. The generic VIA chip I bought works on my other boards (they all have the Jeti one) but not on this one. At some point I managed to get it to work by playing with the clock signals (apparently the current KBC has ground where you'd expect a signal and vice versa?): it was very glitchy but working and, most importantly, DOOM did work indefinitely with it.

Let me try some other games and underclocking the CPU, you never know! Is there also a way to "underclock" the RAM somehow? What parameters shall I change on the BIOS to make that happen?

Cheers for your help!

tony359 wrote on 2022-02-16, 10:17:

I did find version 8.1. It's the "what do I do then"! 😀 Am I aiming to install or compile Slackware?

Well,
first you install,
then you download and compile a contemporary kernel.

and then you wait for a day or so for the kernel to compile 😁 (could be shorter or longer)

tony359 wrote on 2022-02-16, 15:35:

Let me try some other games and underclocking the CPU, you never know! Is there also a way to "underclock" the RAM somehow? What parameters shall I change on the BIOS to make that happen?

No, on these mobos RAM runs 1:1 with CPU bus speed. What you can do is add waitstates, there should be an option (or two, for read and for write) in BIOS, in advanced / chipset section. You obviously want 0WS if possible but if the memory can't take it, or the mobo chipset can't deal with it, you have to go to 1, or even 2. Well if you have to go to 2 then either this RAM is very slow or there is some other problem with the mobo. Keep in mind that 0WS on one motherboard can mean something different to 0WS on another mobo, especially with different chipset and if one has no cache. So these are not RAM timings as such, rather chipset timings, and that also depends on the quality of the PCB signal routing - so some motherboards are just better or worse than average.

gotcha. I'll test.

Tonight I focussed on the bus around the KBC. The KBC is connected to the bus via a 74als245an which is a bus interface basically.
I scoped the signal and noticed that this motherboard's ISA data lines are... pretty bad (yellow line, the purple line is the other side of the chip connected to the KBC)
It looks like they are unable to go back to 5V in a timely manner. Maybe I should look at the pull-up resistors on the lines?

I'm also noticing that the data lines behind the 245 (which is the KBC chip) are only 4V p/p... I have some 245 on order.

I checked on a similar motherboard and, while the bus is still not perfect, it feels much better. (again, yellow line)

I'm wondering if there is something which makes the bus marginal and the 74als245an or the KBC chip simply fails at some point when high traffic happens (=doom running).

I would like to start removing all the interface chips, hoping to find one which is crippling the data lines (all lines look like that). Any thoughts?

tony359 wrote on 2022-02-16, 23:22:

I would like to start removing all the interface chips, hoping to find one which is crippling the data lines (all lines look like that). Any thoughts?

You seem to know a bit about digital electronics but I think you mostly deal with newer, CMOS stuff? If so here's a few things you might find useful:
* A lot of these are TTL chips since this is how PCs started - bipolar transistors and only NPN ones. You should probably look at what a simple TTL gate like 7400 looks like. Then what was modified in LS series to make it go faster and at lower power (answer: a lot of Schottky diodes, some as a bypass for NPN junctions to prevent saturation which is slow to reverse).
* Once you realize that TTL output can drive low pretty well, but can't really drive high, and never to VCC, you will know that the rising edges of signals are going to be way worse than falling ones.
* Unlike in CMOS which has the H level at about Vcc/2, in TTL the H level start at 2.0V, and low ends at about 0.8V. Anything between 0.8 to 2.0 is invalid and should only ever be a transition.
* Any TTL output that can reach 4V in reasonable time is a good one, and even with pull-ups (and keep in mind any TTL input is sort of a pull-up by itself, and thus TTL inputs can actually be left unconnected) will not get to 5V, though given sufficient time it'll creep up close.
* Rising slope that reaches some 3 to 3.5V fast and then slows down to 4V and above is pretty normal for TTLs. Now, and ALS class chip should be actually driving to 4V or even higher with decent speed, then it'll also hit a limit.
* Keep in mind the ALs245 is most likely driving all the 8 lower bits to all ISA slots and some chips, that's a lot of stray capacitance. Not helping the slope shape at all.
* Newer mobos will have resistor packs to terminate ISA to prevent reflections, these are usually pull-ups to 5V of some 330 ohms or thereabouts. This does improve signal quality and might help, but it's important to place those at the last slot. And it might affect the falling edges now, so it's not a perfect solution - though it has to be said it was used by mobo manufacturers for ISA from 386 onward. Early 386 mobos that were mostly 286 redesigns might not be as robust.

If you think TTL is bad, don't ever touch NMOS and PMOS tech - some of those chips required separate bus drivers to even talk to nearby chips, if there was more than one or two. Oh, and if you think you'll just replace the old 74ALS with something CMOS like 74HCT and it'll fix your troubles, think again. You migh get somewhere replacing ALS with AHCT since it has good current drive and speed, but only if there are no issues with reflections. If the mobo doesn't have terminators on ISA then introducing sharper edges of AHCT tech might actually make things worse...

EDIT: Forgot to add, a '245 is a tri-state buffer. Make sure what you've captured is L->H transitions and not going to Hi-Z, since that will look on the scope like going H (because every input on the bus is sourcing some current) but very slowly. That being said, these particular chips, the 245 buffers that drive ISA and RTC/CMOS/KBC, do degrade and even die. They live a hard life switching a lot of current and usually run somewhat hot because of that. If in doubt put in a socket and replace. You can use HCT as replacement in a pinch, it'll work better than broken ALS for sure, but you do want to put ALS or AHCT in there for things to work well.

Thanks Deunan

I am passionate about electronics and I have been learning "as I go" for many years! I am mostly a "tinkerer" but I love learning new things so let me thank you for the time you spent in teaching me something new, I really appreciate that!
It's a very interesting concept. I can indeed see the behaviour you describe on the second screenshot I posted: the signal rises up to 3.5V fast and then it slows down to 4V and above. Really good to know why - I was indeed wondering.

However the first screenshot shows a signal that creeps up very slowly from 0V. But as you say, if H level starts at 2V, I do see 2V on that line so maybe that's why it can function ok even with those slow rising edges.
I did not check what I was capturing to be honest (the T/R pin is always high as it's a keyboard and the blue line you see is the Enable pin) but the ISA signal is always showing that behaviour, I did not capture a specific moment which looked that way.

The second screenshot comes from a very similar motherboard and features 74LS245N buffers.

Based on what you explained me, would you agree that the ISA data lines seem a bit tired on the first picture - raising to H a bit slower than expected? Or am I chasing ghosts here?

Thank you!

tony359 wrote on 2022-02-17, 10:24:

Based on what you explained me, would you agree that the ISA data lines seem a bit tired on the first picture - raising to H a bit slower than expected?

It does look pretty lousy, and more importantly a bit weird in how the intial rise seems slow but then there's a sharp edge all the way up to Vcc. Makes me wonder if that is the chipset talkig to KBC because CMOS can pull the line high and sharp like this, and the slow initial buildup can be some tri-stating of the bus, or just capacitance.

Your scope seems pretty capable with more than 2 inputs so use another probe to test which direction the signal is going (that is, what side of the '245 is inputs and which is outputs - pin 1) and if it's driving or tri-stated (pin 19). I would expect ALS chip to have pretty nice falling and rising edges up to some 4V or so. If you're sure it's the '245 driving the lines, and they look like this, I'd replace the chip. You could also investigate further, take the probe off pin 1 or 19 and put on Vcc pin 20. See if there's a sudden drop in voltage when the outputs go high, which might indicate a power delivery problem. That can be also easily tested by simply adding a temporary wire bypass for Vcc directly from mobo PSU connector, and perhaps also a 100nF cap between pins 10 and 20. Just solder these on the bottom of the PCB and retest, if nothing improves then it's not power delivery issue.

Thank you

It's a 200Mhz 4ch scope so yes, a nice little thing! 😀

I checked pin 1 and it's always high, I guess it's normal for a keyboard to be "one way only"?
Cyan trace on the first picture is pin 19 to show whether it's driving or not. I'll check Vcc indeed.

The thing is that there are many 245 on the board so wondering which one may be causing this issue. Not a big deal to socket them all and test of course.

Below another example - cyan trace (O/E pin) is active so that means that 245 is driving the bus and the bus (yellow trace) looks lousy so... Unless there's something else on the bus creating havoc.

tony359 wrote on 2022-02-17, 16:52:

I checked pin 1 and it's always high, I guess it's normal for a keyboard to be "one way only"?

afaik num/caps/scroll lock diodes on the keyboard are being software controller by bios keyboard interrupt handler - pressing them will force write to keyboard controller

I've checked again and I was indeed mistaken. The T/R line (cyan above) is indeed active (ie it changes status low/high regularly). However, the OE line is tied to ground, hence always low and hence the chip is always active.
so at this point none of my readings I posted were in Z state.