Masejoer wrote on 2023-03-28, 07:15:

I have a Freetech 486F30 or Genoa TURBOEXPRESS 486VL motherboard here that is stalling out on POST (no display) with code 08. AMI BIOS. Motherboard had light corrosion where the battery was, but cleaned up well and all the traces appear to be intact. I can follow AT pins 2, 3, 4, and 5 to the keyboard controller chip. I am unable to find where pin 1/clock goes. I don't get anything from pin1 to the keyboard controller, or any pins on the SiS chips.

You should double-check that you are counting the pins in the right way. Only four pins on the AT connector are supposed to be connected. Pin 3, originally a RESET signal for XT keyboards, is typically unconnected. The actual clock pin should be connected to Pin 1 of the keyboard controller.

Masejoer wrote on 2023-03-28, 07:15:

I was just looking at this area due to the battery corrosion and because AMI 08 says "BAT command to keyboard controller is issued, and "CMOS checksum started."

Not only the connections between the keyboard controller and the keyboard are suspect after battery leakage, but the connections between the keyboard controller and the chipset are suspect, too. Designers of PC/XT/AT BIOSes usually have in mind that something on the keyboard connection might be fishy, as it is an external connection, and programmed their system accordingly. On the other hand, distrust into the mainboard itself during POST was still a thing in the PC/XT days (the BIOS checked that all 8 data bits were actually functional on the PIC, the PIT, the DMA controller), but testing that stuff declined over the years. This decline makes sense, as most of those peripheripherals got integrated into a single chip, the ubiquitious 82C206, initially designed by C&T, but cloned by every chipset maker. Data lines inside a chip don't tend to break or have bad contact in the socket.

In the case of the AT keyboard controller, the BIOS needs to synchronize with the microcode inside the keyboard controller. For that to work, the keyboard controller needs to be executing its microcode (that is, it needs to get a valid clock signal), and furthermore the 8 data bits, the chip select, the register select and the read and write command lines need to be connected from the chipset to the keyboard controller. The issue you are facing hint to a communication problem between the processor and the keyboard controller.

In many boards, the keyboard controller and the BIOS chip have their data lines connected. Testing continuity between D0-D7 of the KBC to D0-D7 of the ROM BIOS are a good initial check for the data bits. Furthermore, the read and write line of the KBC are likely directly tied to ISA /IOR and ISA /IOW - another easy continuity measurement can confirm this. The register select line of the keyboard controller is supposed to be connected to address line A2, which can be shared with A2 on the BIOS ROM, A2 on the ISA bus, or both of them.

Masejoer wrote on 2023-03-28, 07:15:

I'm not sure where to go from here in troubleshooting the board. The BIOS chip is cleaned and I have used deoxit to make sure things are making good contact.

If you get that far into the POST, you can be confident that all the data pins and the chip select logic of the BIOS chip is working fine. A missing address bit on the BIOS chip might be possible, but is unlikely in my experience. I would postpone investigating the BIOS chip until you have excluded communication issues between the chipset and the KBC, which tends to be the culprit of issues like this more often.

Masejoer wrote on 2023-03-28, 07:15:

Everything else ohm-meter tests fine in the area of the AT connector/removed battery, besides not knowing how to follow the AT clock pin (no surface traces on bottom or top of the board - it goes into a middle layer).

The usual layer configuration of consumer 486 boards is a 4-layer configuration that only has +5V and GND on the inner layers. Some boards use a 6-layer configuration, but on most of those baords, the power planes are still in the center of the board (planes 3 and 4), and the space between 1 and 2, as well as 5 and 6 is so small that you can see traces on all of those four layers. So a valid rule of thumb is: If you can't see a trace on either side of the board (and that's not just because there is a component blocking you to look at the top side), that pin is connected to ground, to +5V or completely unconnected.

mkarcher wrote on 2023-03-28, 08:58:

You should double-check that you are counting the pins in the right way. Only four pins on the AT connector are supposed to be connected. Pin 3, originally a RESET signal for XT keyboards, is typically unconnected. The actual clock pin should be connected to Pin 1 of the keyboard controller.

You are right - I found a different diagram and that appears to be working correctly. It's "reset" that I don't seem to have (says not used). If the pins go 1-4-2-5-3, it's "3" that is not connected, but it sounds like that may be normal.

mkarcher wrote on 2023-03-28, 08:58:

Testing continuity between D0-D7 of the KBC to D0-D7 of the ROM BIOS are a good initial check for the data bits.

D7 has no continuity - I'm trying to locate the break now.

Thanks mkarcher, that got me on the right track. I'll have to remove the keyboard controller to find the break likely underneath it (I will install a socket when some arrive), but I ran a bodge wire between BIOS and KEYBOARD D7, and the board is booting now.

Thanks again!

Well...I made a mistake. I had three other traces that needed to be repaired (turbo header wasn't working - clock speed was limited to low), and one time when plugging back in to keep testing, the AT power connectors were offset by one pin. I didn't even know that was possible, but I never paid that much attention beyond grounds in center. My view wasn't good as my office chair broke a few hours ago and now I'm on an awkwardly low dining chair. I don't know what all is dead, but I lost five caps by the power connector, and one resistor. Not sure what else.

PWR-Good/P8-1 didn't receive any signal (not connected)
-5V received the +5V PWR-Good signal
+12V received -5V
-12V received +12V
Ground received -12V
-5V received Ground

I don't have much faith in it now from this stupid mistake, but will try to find replacement components and see if the parts near the power connector are all that died.

The CPU, RAM, videocard, controller card, POST diagnostic card all still work fine in another motherboard.

This was going so well too - I thought I was done, minus solder mask, and I'd no longer have a clocked-down 486 on this board.

Masejoer wrote on 2023-03-29, 21:35:

PWR-Good/P8-1 didn't receive any signal (not connected)

That's harmless.

Masejoer wrote on 2023-03-29, 21:35:

-5V received the +5V PWR-Good signal

You must have looked at http://www.hilmanind.com/pinouts/atpwr.htm or a copy of that. The description for Pin 2 is wrong. That pin is +5V, not -5V. Connecting PWR_GOOD to +5V won't damage the board, but it might damage the PWR_GOOD circuit inside the power supply. If you have some experience and saftety awareness, fixing a blown PWR_GOOD circuit in an AT power supply is easily doable with hobbyist tools.

Masejoer wrote on 2023-03-29, 21:35:

+12V received -5V

That's actually +5V. Harmless undervoltage.

Masejoer wrote on 2023-03-29, 21:35:

-12V received +12V

This will blow one or two capacitors on the -12V rail. If you had a multi-I/O card installed, the serial port level converters (usually in a dedicated chip doing just that) possibly are fried. If you are lucky, the level converters are the standard MC1488/MC1489 aka 75188/75189 chips, which can be easily replaced.

Masejoer wrote on 2023-03-29, 21:35:

Ground received -12V

As well as ground. So essentially -12V was shorted. The short on the motherboard between the ground pins is way stronger than the ability of the power supply to drive -12V. This might have caused damage to the power supply, but not to the board.

Masejoer wrote on 2023-03-29, 21:35:

-5V received Ground

Harmless.

Masejoer wrote on 2023-03-29, 21:35:

I don't have much faith in it now from this stupid mistake, but will try to find replacement components and see if the parts near the power connector are all that died.

I wonder why so many caps failed. The only deadly mistake according to my analysis was putting +12V into the -12V rail, and there shouldn't be "five caps" (citing your post) on that rail. Looking at your photo, I only see one of the caps near the power connector (C6) to have failed. You can just remove it, and test the system. This may increase noise levels on -12V, but with no really ill consequences.

Masejoer wrote on 2023-03-29, 21:35:

The CPU, RAM, videocard, controller card, POST diagnostic card all still work fine in another motherboard.

This basically prooves that +5V had no overvoltage. For most components on the board, that's the only voltage rail connected, so the board is likely fine except for one or two capacitors. Seems like you got away without serious damage. Test the PWR_GOOD signal of the supply, if you can. It should emit +5V like 0.1s later than you get +5V on the actual +5V line.If you don't get +5V at all on PWR_GOOD, that's detectable using a standard meter. A digital storage scope (even the cheapest toy-like ones) can be used to confirm the delay between +5V and PWR_GOOD.

Masejoer wrote on 2023-03-29, 21:35:

PWR-Good/P8-1 didn't receive any signal (not connected) -5V received the +5V PWR-Good signal +12V received -5V -12V received +12 […]
Show full quote

PWR-Good/P8-1 didn't receive any signal (not connected)
-5V received the +5V PWR-Good signal
+12V received -5V
-12V received +12V
Ground received -12V
-5V received Ground

mkarcher wrote on 2023-03-30, 07:30:

You must have looked at http://www.hilmanind.com/pinouts/atpwr.htm or a copy of that. The description for Pin 2 is wrong. That pin is +5V, not -5V. Connecting PWR_GOOD to +5V won't damage the board, but it might damage the PWR_GOOD circuit inside the power supply. If you have some experience and saftety awareness, fixing a blown PWR_GOOD circuit in an AT power supply is easily doable with hobbyist tools.

so lucky 😮 almost like maybe someone designed it deliberately this way to not cause too much damage if plugged one off
I wouldnt be surprised if everything works after cutting off fried shorted Tantalum capacitor

Interesting, and yes, I did pull Voltages from that one link.

I'm using an ATX to AT converter - there is no real "+5V POWER-GOOD" signal. I wouldn't want to reuse the 30 year old AT psu without a refurb. While only one is visibly popped, the caps I drew around "failed"/reports open-loop on an in-circuit test with a mesr100 meter. Other caps in the area tested in-circuit fine. The resistor at R3 also shows open loop, after putting fresh solder on it to make sure there's no oxidation on the surface. The other resistors to the right of the power connector test fine, to spec.

Now THAT ALL SAID, I removed the one cap that was visibly broken...and the system POSTs again fine. Perhaps this mesr-100 meter isn't as useful as some people say it is, but the same/similar caps between the ISA slots test fine. I'm not sure what R3 is used for, but the system still works with it testing open.

Lastly, of course turbo now works correctly and the CPU is no longer running at 1/2 to 1/4 the proper speed. Turbo wasn't working before, so something like topbench would only return a score of 70 (DX33), but after looping for awhile, it began to fluctuate between 40-70, eventually getting stuck at 40, even after being powered off to cool down. I figure the second trace next to the turbo line had something to do with that, and running the system slowly burned through the rest of a failing section of that trace.

I still have a lot to learn about these old systems/how motherboards work, and it seems the third VLB slot doesn't work consistently (16-bit ISA is fine), but this system is limping along okay right now!

You guys helped me with everything I needed to get the board to where it is now. Thank you!

Masejoer wrote on 2023-03-30, 16:04:

I'm using an ATX to AT converter - there is no real "+5V POWER-GOOD" signal.

That's surprising. The ATX standard also includes a POWER-GOOD signal, on pin 8 of the ATX connector. A proper adapter should connect that to pin 1 of the AT connector.

Masejoer wrote on 2023-03-30, 16:04:

I wouldn't want to reuse the 30 year old AT psu without a refurb.

That's not a bad idea. Although most of the time, those supplies do not fail in a way that they kill connected components, sometimes they do. I never had an AT supply kill any components, but Adrian Black recently got a 386SX VL board killed by a failing supply, see https://www.youtube.com/watch?v=Dd5vPt64XSQ .

Masejoer wrote on 2023-03-30, 16:04:

While only one is visibly popped, the caps I drew around "failed"/reports open-loop on an in-circuit test with a mesr100 meter. Other caps in the area tested in-circuit fine. The resistor at R3 also shows open loop, after putting fresh solder on it to make sure there's no oxidation on the surface. The other resistors to the right of the power connector test fine, to spec. [...] but the same/similar caps between the ISA slots test fine.

The resistor R3 is marked "513" which means 51 kiloohms. This is outside the measurement range of the mesr100 (which goes up to 100 ohms), so "O.L." is expected. On the other hand, the in-circuit test of the other caps is supposed to work and shouldn't report O.L., but a maximum value of 2 ohms. I suppose you had contact issues if all those caps measured open loop. That area is quite close to the battery area, so there might be corrosion due to battery leakage making the contact more difficult. These 4 caps are on all the rails. One on -12V (which blew up), one on +12V, one on -5V and one on +5V. At least on +5V, there are a couple of caps distributed over the board. You should get similar ESR values measuring the +5V-to-ground ESR anywhere on the board. The "similar caps between the ISA slots" are (at least most of them) likely on +5V, possibly you got another quartet of caps covering all rails near the ISA slots. If you get good ESR values there, the measurement at the power connector caps is likely false.

Masejoer wrote on 2023-03-30, 16:04:

Perhaps this mesr-100 meter isn't as useful as some people say it is, but the same/similar caps between the ISA slots test fine.

If the mesr100 delivers what the chinese specs promise, it is a very useful tool. You might need better quality probe leads than the one supplied with the instrument to make reliable good contact, though. ESR meters really shine on diagnosing Super-Socker-7 boards and Pentium-II/Pentium-III boards. That was the time of cheap bad-quality caps hitting the market and high-power switch-mode converters (with high demands to capacitor quality) starting to appear everywhere.

Masejoer wrote on 2023-03-30, 16:04:

Lastly, of course turbo now works correctly and the CPU is no longer running at 1/2 to 1/4 the proper speed. Turbo wasn't working before, so something like topbench would only return a score of 70 (DX33), but after looping for awhile, it began to fluctuate between 40-70, eventually getting stuck at 40, even after being powered off to cool down. I figure the second trace next to the turbo line had something to do with that, and running the system slowly burned through the rest of a failing section of that trace.

The symptom you observed here is most lilkely an "open CMOS input", not some burning trace. The input pin of CMOS chips don't source or sink current (except for some picoamps leakage). You can think of input pins to CMOS chips as small capacitors (around 2-5pF). You need to send current into the chip to charge or discharge the capacitor, but in the static case, no current flows through that pin. This implies that if a CMOS input pin is not connected to anything, it will not be pulled high or low, but behaves mostly randomly. In practice, when you power up the machine, capacitive coupling pulls the pin to some level, at which it will remain until leakage current might pull it slowly to a different level. In your case, the "turbo" input to the chipset is very likely a CMOS-type input which gets pulled to the "turbo" level at power on, and then slowly drifts toward the "no turbo" level. It doesn't need any trace for it, that's already built into the chipset (as unwanted side effect). Electronic engineers know that leaving CMOS inputs open is a bad idea and results in unpredictable behavior.

Masejoer wrote on 2023-03-30, 16:04:

I still have a lot to learn about these old systems/how motherboards work, and it seems the third VLB slot doesn't work consistently (16-bit ISA is fine), but this system is limping along okay right now!

Contact issues with VLB slots are common. Try reseating a VL card multiple times and/or applying contact cleaner like DeoxIT. Also, sometimes a contact in a VL slot is bent. In that case, the VL slot is likely fixable only by replacing it, which is a tedious thing to do (although it should be possible with a hot-air rework station.

mkarcher wrote on 2023-03-30, 21:56:

The resistor R3 is marked "513" which means 51 kiloohms. This is outside the measurement range of the mesr100 (which goes up to 100 ohms), so "O.L." is expected.

My resistor measurements are with Fluke 87V meters, not the esr tester.

The performance drop thing was weird - non-turbo is supposed to be about half the turbo speed and initially it was only running at that half speed, but over time began to sag to almost 1/4 the cpu's speed. The bus speeds were staying the same, but the performance just began to droop to oddly low levels. Not something that I ever expected would happen!

Anyway, the components are back in the original case and working fine. I'll want to fashion some type of heatsink for this thing - I almost feel like I need to create (not use the one on thingiverse) a 3d printable heatsink holder for these as clip and slide on heatsinks aren't a common thing I come across anymore, and I specifically look at surplus shops' heatsink/fan boxes for retro-compatible gear. That or throw on a pentium overdrive, but I'd like to keep this system a DX33.

Masejoer wrote on 2023-03-30, 22:51:

The performance drop thing was weird - non-turbo is supposed to be about half the turbo speed and initially it was only running at that half speed, but over time began to sag to almost 1/4 the cpu's speed. The bus speeds were staying the same, but the performance just began to droop to oddly low levels. Not something that I ever expected would happen!

Bus speed staying the same is expected on early 486 boards. In contrast to the 286 and 386, which received a 2x clock input (you provide 66MHz, the processor operates at 33MHz), the 486 receives the actual operating clock. Nevertheless, it still requires a double clock inside. Intel added a PLL-based circuit into the 80486 to double the clock or generate a phase-shifted version of the external clock. This circuit doesn't like sudden changes in the input clock, even if it is "glitch-free", i.e. no high or low phase is shorter than allowed. Changing the bus clock of a 486 processor works only if you softly slide the clock with IIRC less than 0.1% change per clock period. Later 486 clock generators for "green" motherboards could do it, but early ones don't.

Instead, most 486 chipsets implemented deturbo mode by adding wait states to the front side bus. There were different approaches to it: Some chipsets disable L2 cache alltogether, so every cycle that would have been served from cache (at 33MHz, hopefully withing 5 clocks) will now be served from memory (which takes a lot longer, likely around 12 clocks at 33MHz). Other chipsets just add wait states to the L2 hit timing (I've recently seen a speedsys memory timing curve that showed the L2 being slower than main memory in deturbo mode), and yet other chipsets just block the frontside bus alltogether periodically to throttle it by faking a busmaster getting a grant to the bus.

What might have happened on your board is that originally the turbo signal was oscillating between turbo and deturbo mode, and finally drifted into full deturbo. Another possiblity with cache-basesd deturbo methods is that physical memory layout of the benchmark changed. The direct-mapped L2 cache can be very sensitive to the physical addresses of the areas actively accessed.