VOGONS


486 no POST, stuck ISA lines

Topic actions

First post, by wbahnassi

User metadata
Rank Oldbie
Rank
Oldbie

Hi guys, looking for a suggestion on what could be wrong in this case. I'm trying to repair this motherboard:
https://theretroweb.com/motherboards/s/qdi-v4s471-g

Initial symptoms: POST card shows just two dashes -- and the Reset signal never turned off. Investigated a bit and found the main chipset had some floating pins. After repairing them, the reset signal now properly goes off after a second of powering on the mobo.

The POST card is still not showing any numbers. Probed the CPU pins and they look fine. CPU has 5V+ VCC, Reset responds correctly to the reset jumper (high then low), HOLD pin is low, and clock is good (25MHz). It starts to warm up upon power on. I also tried a different 486 CPU, and same thing.
Checking the ISA slots, I found that Data1-Data8 are all stuck high, and all address lines are stuck low with no activity.

I checked the transceivers, and they're fully connected to the ISA slots from one side, and to the main chipset from the other side. The chipset side of the transceivers isn't receiving any signal when turning on the MB, so no wonder I don't see anything on the ISA lines.

Is this a case of a dead chipset? Or is there something else that could hinder these lines from activity?

Cheers!

Turbo XT 12MHz, 8-bit VGA, Dual 360K drives
Intel 386 DX-33, Speedstar 24X, SB 1.5, 1x CD
Intel 486 DX2-66, CL5428 VLB, SBPro 2, 2x CD
Intel Pentium 90, Matrox Millenium 2, SB16, 4x CD
HP Z400, Xeon 3.46GHz, YMF-744, Voodoo3, RTX2080Ti

Reply 1 of 29, by BitWrangler

User metadata
Rank l33t++
Rank
l33t++

It is not one of those awkward buggers that need the keylock switch jumpered to boot is it?

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 2 of 29, by wbahnassi

User metadata
Rank Oldbie
Rank
Oldbie
BitWrangler wrote on 2026-01-15, 18:59:

It is not one of those awkward buggers that need the keylock switch jumpered to boot is it?

Eh, never came across that behavior before. But I just tried shorting pins 4-5 on the keylock jumper and it didn't make any difference.

Turbo XT 12MHz, 8-bit VGA, Dual 360K drives
Intel 386 DX-33, Speedstar 24X, SB 1.5, 1x CD
Intel 486 DX2-66, CL5428 VLB, SBPro 2, 2x CD
Intel Pentium 90, Matrox Millenium 2, SB16, 4x CD
HP Z400, Xeon 3.46GHz, YMF-744, Voodoo3, RTX2080Ti

Reply 3 of 29, by BitWrangler

User metadata
Rank l33t++
Rank
l33t++

They are rare enough to catch you out once every few years. All three I've come across personally have been AMIBIOS boards, not sure if that's a coincidence or not.

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 4 of 29, by wbahnassi

User metadata
Rank Oldbie
Rank
Oldbie

Found the main chipset's data sheet here:
https://theretroweb.com/chips/2549

I've traced all the clocks (in and out) and they are all good. Chipset receives clock and divides it as needed. CPU reset and power good pins are all good as well. I think the chipset might be good afterall.

Turbo XT 12MHz, 8-bit VGA, Dual 360K drives
Intel 386 DX-33, Speedstar 24X, SB 1.5, 1x CD
Intel 486 DX2-66, CL5428 VLB, SBPro 2, 2x CD
Intel Pentium 90, Matrox Millenium 2, SB16, 4x CD
HP Z400, Xeon 3.46GHz, YMF-744, Voodoo3, RTX2080Ti

Reply 5 of 29, by snufkin

User metadata
Rank Oldbie
Rank
Oldbie

I think some boards don't start without a battery. Looks like there's a 4 pin header just below J39 near the 8 bit ISA slot that might be an external battery header.

Reply 6 of 29, by Susanin79

User metadata
Rank Member
Rank
Member

I'd read the BIOS and compare it with the one from the retroweb, may be the BIOS is corrupted

Reply 7 of 29, by MikeSG

User metadata
Rank Oldbie
Rank
Oldbie

RAM, cache, BIOS oxidised pins can cause no activity also. Isopropyl alcohol & a toothbrush on RAM slots, cache and BIOS can be reseated. Reseat jumpers.

Reply 8 of 29, by wbahnassi

User metadata
Rank Oldbie
Rank
Oldbie

So far did the following:

  • Attached an external battery
  • Jumpered the keylock
  • Dumped the BIOS, and tried other BIOSes from TRW for the same board (thus BIOS reseated). My BIOS is not like anyone from TRW. Attaching dump here
  • Removed cache chips completely
  • Tested the CPU and RAM chips on another 486 board and they worked flawlesly
  • Tested without the POST card, still no difference

One little detail (might be irrelevant).. whenever I turn on/off the board, the PC speaker makes a single click like one of those RAM test clicks. So there is a pulse going to the speaker at power on/off.

Turbo XT 12MHz, 8-bit VGA, Dual 360K drives
Intel 386 DX-33, Speedstar 24X, SB 1.5, 1x CD
Intel 486 DX2-66, CL5428 VLB, SBPro 2, 2x CD
Intel Pentium 90, Matrox Millenium 2, SB16, 4x CD
HP Z400, Xeon 3.46GHz, YMF-744, Voodoo3, RTX2080Ti

Reply 9 of 29, by PC@LIVE

User metadata
Rank Oldbie
Rank
Oldbie

Hello, I suggest you do some tests, first of all, you should be sure that all the pins of the socket (3?), are in place, that is, try the continuity from top to bottom, this could exclude that there is a problem with the socket, for convenience you can if you have one, use an interposer.
If instead you want to do without this control, you could try spraying a (professional) contact deoxidant on the CPU and then insert and remove it a few times, so that the socket pins also come into contact with it.
Last attempt, insert a minimum thickness under the CPU and close the lever, in this way you will get a contact in a different place (maybe better), then you can try to insert the CPU and close several times, if the problem is there, after a certain number of insertions, you will start to see one or more codes, or even a video BIOS screen.
I wish you good luck 🍀

AMD 286-16 287-10 4MB
AMD 386SX-33 4MB
AMD 386DX-40 Intel 387 8MB
Cyrix 486DLC-40 IIT387-40 8MB
486DX2-66 +many others
P60 48MB
iDX4-100 32MB
AMD 5X86-133 16MB VLB CL5429 2MB
AMD K62+ 550 SOYO 5EMA+ +many others
AST Pentium Pro 200 MHz L2 256KB

Reply 10 of 29, by wbahnassi

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for the suggestions. At this point I'm open to try everything.

So I traced the socket 3's pins from the upper side and ensured that they all connect cleanly with the opposite solder points on the motherboard's back. All checked fine. I used a dupont wire that I attached to the multimeter from one end, and its other end goes into each of the socket's pins. On the opposite side of the board, the other multimeter probe is touching the same pin's solder joint. Each pin showed 0-Ohm resistance with its matching pin from the opposite side.

Next, I powered the board with the CPU inserted, and started probing the CPU pins from the socket's solder points on the back of the board.

All readings match what I see on the ISA lines. Most address lines are at 5V, except here I see A13 was at 1.76V (?!)..
The reset signal is low, so the CPU should be going. Its input clock is 25MHz...

I really don't know why the CPU is halted like that... And that floating voltage 1.76 on A13 doesn't make any sense to me...

Turbo XT 12MHz, 8-bit VGA, Dual 360K drives
Intel 386 DX-33, Speedstar 24X, SB 1.5, 1x CD
Intel 486 DX2-66, CL5428 VLB, SBPro 2, 2x CD
Intel Pentium 90, Matrox Millenium 2, SB16, 4x CD
HP Z400, Xeon 3.46GHz, YMF-744, Voodoo3, RTX2080Ti

Reply 11 of 29, by myne

User metadata
Rank l33t
Rank
l33t

Dud decoupling cap?

I built:
Convert old ASUS ASC boardviews to KICAD PCB!
Re: A comprehensive guide to install and play MechWarrior 2 on new versions on Windows.
Dos+Windows 3.11+tcp+vbe_svga auto-install iso template
Script to backup Win9x\ME drivers from a working install
Re: The thing no one asked for: KICAD 440bx reference schematic

Reply 12 of 29, by mkarcher

User metadata
Rank l33t
Rank
l33t

I try you suggest to keep chasing the basics. You already started well by testing the usual stuff (operating voltage, clock, reset). Then, you observed that you don't observe cycles on the ISA bus. You also observed that this likely is not the root cause of the current issue, because you also don't observe cycles on the local bus (aka frontside bus or processor bus). Do you have equipment to check whether you get absolutely no cycles on the local bus or maybe a single cycle after reset? Typically, you would check stuff like that using an oscilloscope in "normal" (see footnote 1) or "single-shot" triggering mode. You can observe whether the 486 triggers a bus cycle by looking at /ADS. The signal is pulled low for a single clock if a cycle starts. We expect some bus cycles to fetch BIOS instructions after the internal reset of the 486 is complete. This is a fully internal operation and does not require a working mainboard, just a working processor. As I understand it, your processors can be treated as "known good", so if you don't see an /ADS response to reset (if an internal selft test is requested, it might take a human perceptable delay (more than 20ms) between releaing reset and getting the first /ADS pulse), you need to troubleshoot why the 486 processor is prevented from starting the BIOS fetch. The most likely reason for not starting the BIOS fetch is that the 486 doesn't know its OK to access the bus. So check HOLD, AHOLD, /BOFF pins. Note that AHOLD and HOLD are active high, so you need HOLD=low, AHOLD=low, /BOFF=high for the 486 to have full bus ownership.

Your observation regarding A13 is also interesting. There are multiple ways why A13 might end up at 1.76V as measured by a multimeter: The pin might be floating, there might be a bus conflict with one party driving it high and another party driving it low, or it might acutally be toggling between high and low. For the moment, I'm going to ignore the "toggling" reason (if your meter has a low-voltage AC range, you might want to use that to check for an AC component at that location). As the local bus is a bus, it is a valid state of that bus if a line is not driven by any participant on the bus. There is no hard requirement that every address line has a pull-up resistor, so seeing 1.76V on A13 by itself is not necessarily a hint that something is wrong on this line. On the other hand, I see that your board is equipped with 256K of L2 cache. In that case, the local bus A2..A17 lines (thus including A13!) need to be forwarded to the cache chips. This can either be a direct connection, or there may be buffer chips in between. On your board, the location of U24 and U25 make it likely that those chips, which provide 16 unidirectional buffers, may be used as address buffer. Those chips are 74F244, the "F" notifying a fast chip with a TTL-like input, which behaves like an internal pull-up. If the 74F244 is connected to A13, and you see 1.76V on that line, something is pulling it down. 74F type logic provides enough pull-up action, that a 1K pull-down might not be able to pull lower than 1.76V.

So, my suggestion for continuing is:

  • Verify HOLD, AHOLD, /BOFF while the system is running
  • Probe for connectivity from A13 at the 486 socket to the L2 cache (either some address pin of the cache or some input pin of either 74F244)
  • Probe for shorts between A13 and other signals.

1: If you are an oscilloscope noob, be aware that the triggering mode called "normal" is not the standard operating mode used in the last 40 years. The default triggering mode is "auto", and "normal" is an exception. If you have a really cheap scope (<50$ AliExpress) that does not provide a trigger mode setting at all, it will behave like "auto" triggering, not like "normal" triggering.

Reply 13 of 29, by Chkcpu

User metadata
Rank Oldbie
Rank
Oldbie
wbahnassi wrote on 2026-01-16, 17:00:
So far did the following: […]
Show full quote

So far did the following:

  • Attached an external battery
  • Jumpered the keylock
  • Dumped the BIOS, and tried other BIOSes from TRW for the same board (thus BIOS reseated). My BIOS is not like anyone from TRW. Attaching dump here
  • Removed cache chips completely
  • Tested the CPU and RAM chips on another 486 board and they worked flawlesly
  • Tested without the POST card, still no difference

One little detail (might be irrelevant).. whenever I turn on/off the board, the PC speaker makes a single click like one of those RAM test clicks. So there is a pulse going to the speaker at power on/off.

Hi wbahnassi,

Although you already tried other BIOSes, I did a check on your QDI_486.BIN dump.
It is a valid AMI WinBIOS for your board, the version INV 9.0. I’ve run it in an SiS471 emulated machine in 86Box and it works just fine.

The attachment Monitor_1_20260117-113156-147.png is no longer available

So the BIOS itself is not the issue. I hope you will find the culprit.

Cheers, Jan

CPU Identification utility
The Unofficial K6-2+ / K6-III+ page

Reply 14 of 29, by Mov AX, 0xDEAD

User metadata
Rank Newbie
Rank
Newbie

Have similar board (V4S471), a lot of jumpers, recheck again and if possible try run with different CPU vendors

Reply 15 of 29, by MikeSG

User metadata
Rank Oldbie
Rank
Oldbie

CMOS Clear jumper, and Reset possibly connected/jumpered wrong...? May line up with the one PC speaker click sound.

RAM slots (not sticks) still possibly oxidised.

Reply 16 of 29, by nuno14272

User metadata
Rank Member
Rank
Member

Can you have another look to the chipset pins ? you can have more not connected pins. just look againand try to move every pin.

1| 386DX40
2| P200mmx, Voodoo 1
3| PIII-450, Voodoo 3 3000

Reply 17 of 29, by wbahnassi

User metadata
Rank Oldbie
Rank
Oldbie

Ok, lots of suggestions, let me try to address each:

myne wrote on 2026-01-17, 03:17:

Dud decoupling cap?

I'll do a full pass on those later tonight. Thanks!

mkarcher wrote on 2026-01-17, 09:17:
So, my suggestion for continuing is: […]
Show full quote

So, my suggestion for continuing is:

  • Verify HOLD, AHOLD, /BOFF while the system is running
  • Probe for connectivity from A13 at the 486 socket to the L2 cache (either some address pin of the cache or some input pin of either 74F244)
  • Probe for shorts between A13 and other signals.

Yes, I'm a noob with the oscilloscope, but I think I managed to capture the /ADS signal on reset and it indeed behaves as you described. For this, I switched the oscilloscope's mode to Single and trigger on a rising edge. Upon reset, it immediately captured the profile you can see in the photo and paused. /ADS goes low for 150ms, then goes back to 5V and stays there.

The attachment ADS_Reset.jpg is no longer available

I then went to probe HOLD, AHOLD a BOFF. They are low,low,high respectively. So I think this all checks to your expectations...

I used to have cache chips installed on the board, but I removed them just to avoid one more potential source of error. I expect that the MB should work with no L2 cache installed at all. Haven't gotten to trace A13 yet, but I feel that the issue is wider than just A13..

Chkcpu wrote on 2026-01-17, 10:56:

Although you already tried other BIOSes, I did a check on your QDI_486.BIN dump.
It is a valid AMI WinBIOS for your board, the version INV 9.0. I’ve run it in an SiS471 emulated machine in 86Box and it works just fine.

Thanks Jan for confirming. This is good to know. Also, feel free to contribute this BIOS dump to TRW.

Mov AX, 0xDEAD wrote on 2026-01-17, 11:12:

Have similar board (V4S471), a lot of jumpers, recheck again and if possible try run with different CPU vendors

Yes, the number of jumpers are crazy. Do you have a photo of yours by any chance? I can try to match your jumpers if yours is in a working state. I'm testing right now with a DX 33 MHz CPU and I have my jumpers configured as such following the manual on TRW. Also would be great to confirm if the board works fine without any cache chips in the sockets.

MikeSG wrote on 2026-01-18, 15:26:

CMOS Clear jumper, and Reset possibly connected/jumpered wrong...? May line up with the one PC speaker click sound.
RAM slots (not sticks) still possibly oxidised.

Reset is unjumpered, until I manually do it for my testing purposes. It works fine. The clicking sound also occurs when I trigger a reset. I tried the CMOS clear jumper to be on both sides, but it didn't make a difference. It's JP39, and I leave it at [1-2] which is normal operation.
For the RAM slots, the board has two sets: 2 72-pin SIMMs and 4 30-pin SIMMs. I was using 72-pin memory sticks.. but I just tried a set of four 30-pin sticks and it didn't make a difference. Usually bad memory would cause the board to make continuous beeps.. but here it's just dead silent.

nuno14272 wrote on 2026-01-19, 15:06:

Can you have another look to the chipset pins ? you can have more not connected pins. just look againand try to move every pin.

Sure, though I checked them when I first did the soldering fix, I just checked them again and they're all solid and clean with no bridges.

Whew... that was a lot of things to try...

Turbo XT 12MHz, 8-bit VGA, Dual 360K drives
Intel 386 DX-33, Speedstar 24X, SB 1.5, 1x CD
Intel 486 DX2-66, CL5428 VLB, SBPro 2, 2x CD
Intel Pentium 90, Matrox Millenium 2, SB16, 4x CD
HP Z400, Xeon 3.46GHz, YMF-744, Voodoo3, RTX2080Ti

Reply 18 of 29, by butjer1010

User metadata
Rank Oldbie
Rank
Oldbie

My only advice for You is - Listen to mkarcher 😀
This guy is a genius, he did manage to help me repair EGA graphics card, which i thought it is for trash only! And i'm not an electrician, i'm just a guy who knows how to solder, and that's it! He did everything!
Try everything he will ask here, and there is a big chance to get this baby work again 😀
I only have one question - without RAM sticks, is there any sound on speaker?

Reply 19 of 29, by mkarcher

User metadata
Rank l33t
Rank
l33t
wbahnassi wrote on 2026-01-20, 22:55:

Yes, I'm a noob with the oscilloscope, but I think I managed to capture the /ADS signal on reset and it indeed behaves as you described. For this, I switched the oscilloscope's mode to Single and trigger on a rising edge. Upon reset, it immediately captured the profile you can see in the photo and paused. /ADS goes low for 150ms, then goes back to 5V and stays there.

It's nice you have a scope. That makes troubleshooting easier, but this picture means that something is severely off or you don't really know what you are doing with the scope. i suspect the issue is the latter. My primary issues with that image are:

  • You set triggering to the rising edge (you say so, and the screenshot icon confirms it), yet I see a falling edge at the center of the screen. The orange "T" inside an arrow at the top of the grid confirms that the center of the screen displays what happened at the trigger time.
  • You see a pulse of 150 milliseconds (as I understand the screenshot, you are reading it correctly, but /ADS should be low for an individual clock cycle of the processor to start a bus cycle, which is 40 nanoseconds.

I trust the scope to trigger on a rising edge. So there is a rising edge where you don't see any. The primary reason is: The time base (horizontal resolution) is way off a setting that would give good measurements. The signal on /ADS consists of sub-microsecond pulses, yet you configured the scope to display 100.000 microseconds per grid line. That's the "M: 100ms" in the top. You should be able to "zoom into" it by setting the time base to 100 nanoseconds instead of 100 milliseconds per grid line, and retry the measurement. I expect you will see a lot of pulses (at least that's what is expected). The issue you are facing here is a kind of aliasing caused by sampling way too little points to properly resolve what's going on. It's an easy trap to fall into, and if the general shape (like a pulse here) makes sense at first, hard to notice that you are not measuring what you think you are measuring. The seemingly wrong triggering behaviour might give a clue if you have some scope experience.

So, please redo that measurement. Single shot and vertical settings are fine, or at least may be fine. The scope screenshot doesn't show whether you are probing in 1x or 10x mode. For signals that exceed a couple of MHz (that is, pulses shorter than 300 nanoseconds), probing with your standard passive scope probes at 1x gives distorted results. It seems the scopes shipped with your scope are switchable. You only get the 70 MHz bandwidth (which we need) at the 10x setting. The 1x setting is typically limited to around 6 to 10 MHz. If you configure the probe into 10x mode, you either need to configure the scope accordingly (this is possible in all digital scopes I know), or you need to be aware that 5V will be displayed as 0.5V instead.

So, assuming you see some individual short pulses on /ADS, it seems like the CPU tries to access the BIOS to get started. As you have a scope, the next thing you should check is whether the BIOS is adressed. The BIOS chip has chip enable on pin 20 and output enable on pin 22. Both of these pins need to be low to get data from the BIOS. Please check whether this is the case.

wbahnassi wrote on 2026-01-20, 22:55:

I used to have cache chips installed on the board, but I removed them just to avoid one more potential source of error. I expect that the MB should work with no L2 cache installed at all. Haven't gotten to trace A13 yet, but I feel that the issue is wider than just A13..

Having cache removed is a good idea. The board is indeed supposed to boot without L2 cache, it should ignore the "external cache" setting in the BIOS, or display a clear error message like "cache memory bad: DO NOT ENABLE CACHE" if L2 is enabled without chips installed. A broken trace for A13 can suffice for the symptoms you are observing: This can result in the processor not being able to read the correct locations from the BIOS ROM, resulting in no sensible action. The processor starts executing at the last 16 bytes of ROM. There will be a jump instruction, but if the processor doesn't read it correctly, it will continue outside of ROM space and not access the ISA bus anymore very quickly.

While the suggestions about testing for beeps without RAM installed are quite good as general troubleshooting hints for no-POST 486 boards, you are already a step beyond that: You have a POST card. The first POST codes are visible long before the first serious RAM access will happen. Broken RAM might short some data lines on the bus, so testing without is good, but your primary goal should be to get at least a single code on your POST card (assuming the card is working at all; there are PCI/ISA post cards on which the ISA interface is fake). Installing good RAM in the wrong banks is supposed to result into beeps and POST codes, so we already know the issue is deeper than that.