I also have an oscilloscope on order from AliExpress
that sound ominous and not all that encouraging 😀
Oscilloscopes are not like multimeters where you get something ok with not a lot of money. There is a big cliff below $300 ($200 used) 200MHz Rigols, then another one below $100 with those almost usable but not really multimeter scopes. you can get a lot more done when fixing boards with $70 Logic Analyzer https://www.cnx-software.com/2025/11/12/69-si … -150-protocols/ than any scope.
Thanks, I might pick up one of those as well. Great suggestion.
After reading a bunch on EEVblog, I had ordered a DreamSourceLab DS4T252. I need it to be compact as I don't have a lot of space for a large scope - and this seemed to be a good tradeoff for price/capabilities although limited to 50MHz so workable for 486 board work but limited for anything more.
Curious of the opinion on that PicoPOST. PCBWay can do a full assembly of it but they want a minimum order of 5. So if it is useful I could order 5 of them and resell the others at original cost here or elsewhere.
On one hand its one of those handheld scopes, on the other its from DreamSourceLab so it might actually be usable minus the frustration of no buttons and dials.
100MSPS/s in two channel mode should be enough, barely.
I love the idea of Pico Post card - in theory if could be infinitely useful logging everything that happens on ISA bus
- all IO accesses. definitely KBC but might also include chipset integrated peripherals
- all ISA memory reads. That usually includes reading BIOS as BIOS chip on X-bus usually shares address bus with ISA
Such card could show not only last POST code but also CPU execution trace leading to that POST code letting one quickly jump into disassembler and see where the problem lies by looking at the code.
But last update is one year ago and no one seems to be raving about it. picogus should be able to perform POST card functionality with custom firmware.
- all ISA memory reads. That usually includes reading BIOS as BIOS chip on X-bus usually shares address bus with ISA
Such card could show not only last POST code but also CPU execution trace leading to that POST code letting one quickly jump into disassembler and see where the problem lies by looking at the code.
For compressed BIOSes, I suppose you'd only get the execution trace for the initial decompression phase? Since, once it switches over to shadow RAM, the accesses should become invisible to the ISA slots.
Right now I think it's going to be around $53 per card for each Pico Post fully assembled by PCBway. It's interesting enough for me to give it a try, even if the latest firmware for it is a year old. I don't think people are raving about it because few if any people other than the original authors have gone to the trouble of actually building it. And even with PCBway I've had to go back and forth a bunch to get to the correct parts.
I do have a Picogus as well, I just don't know it well enough to design a custom firmware for it.
If for nothing else this thread has led me to a robust set of tools to test and repair vintage boards. Now I just need to get this one up and going again and into the case.
The LP-560 logic probe showed up today so I did some initial testing at the BIOS ROM. The probe was powered from BIOS pin 28 (+5 V) and pin 14 (GND), and HIGH/LOW operation was verified against those pins first.
BIOS pin 20 (/CE): Normally sits HIGH. At power-on/reset it briefly goes LOW and then returns HIGH. In MEM mode the pulse indicator latches, confirming activity.
BIOS pin 22 (/OE): Normally HIGH. I don't visibly see it go LOW, but the LP-560 pulse indicator latches almost immediately after power-on/reset, so it is detecting a transition.
I then checked some BIOS address lines:
Pin 10 / A0: briefly HIGH, then LOW and remains LOW.
Pin 9 / A1: lots of activity — HIGH and LOW indicators active, pulse indicator latched, lots of probe audio.
Pin 8 / A2: similarly active — starts LOW, then HIGH/LOW activity with the pulse indicator and audible transitions.
I also checked BIOS data outputs:
Pin 11 / Q0 (D0): substantial activity after reset.
Pin 12 / Q1 (D1): substantial activity as well, possibly even busier than Q0.
So it appears the ROM is being selected/addressed and is putting changing data onto the bus. This doesn't look like a board where the BIOS is simply never being accessed.
The POST card nevertheless remains at ----. The separate MiGron ISA clock card also continues to report approximately 7.16 MHz, so ISA clock is present.
Combined with the earlier tests, we now have good power rails, working reset-switch behavior, ISA clock, BIOS control/address/data activity, a verified BIOS dump, and repaired/verified keyboard DIN Clock/Data connections. Still no POST code.
Next step: tomorrow I'm going to move the logic probe to the CPU side. I plan to verify CPU RESET directly at the socket, then CPU CLK, followed by CPU address/data activity. The goal is to determine whether the CPU is actually coming out of reset and executing bus cycles, rather than inferring CPU execution solely from activity seen at the ROM.
If any of you have other tests to suggest I'm happy to accept advice! Thanks all.
do you have CGA/MDA graphic card? those dont require running video bios and Iv seen cases of boards with ISA problems still init video with those
if you are seeing all this activity on BIOS chip then CPU reset works fine
put that probe on ISA B13 IO-Write
I don't have a CGA card unfortunately. But thank you for the suggestion to start probing the ISA bus — that turned out to be a very useful direction.
I started with ISA B13 /IOW. It sits HIGH normally, but in MEM mode the probe captures a transition at power-on. If I clear the latch while the board is running, switch back to MEM, and press RESET, it captures another transition. So there is definitely at least one ISA I/O-write cycle associated with reset.
ISA B14 /IOR stays HIGH and I don't see a pulse at power-on or after RESET.
I also checked ISA A7. It stays LOW and I don't see it transition HIGH after RESET. Since port 80h requires A7 HIGH, I don't currently see evidence that the /IOW activity is actually a POST-code write. The POST card still shows ----.
I then moved to the CPU socket and found the most interesting result so far.
I positively identified CPU socket C16 / RESET on the underside of the board. C16 stays LOW continuously. Pressing and holding the motherboard RESET switch does not change it. I also tested C16 in MEM mode during a cold power-on: it immediately shows LOW and captures no pulse.
For comparison, ISA B2 / RESET behaves exactly as expected:
LOW normally
HIGH while the reset button is held
LOW again when released
I also checked CPU socket C10 / SRESET. It is HIGH from power-on and remains HIGH regardless of the reset switch.
So the current discrepancy is:
ISA RESET works, but I cannot detect CPU RESET ever being asserted at C16 — even during cold power-on.
That's where I'm focusing now. The board is powered off and I'm tracing/beeping C16 backward through the board as far as I can go, through vias and components, to figure out what actually drives CPU RESET and where that path leads.
For context, earlier probing of the BIOS showed /CE, /OE, address-line activity, and data-line activity, so the board is definitely doing something rather than being completely inert.
The 16-channel SLogic16U3 logic analyzer shipped and looks like it will arrive next week, which should eventually make it much easier to capture /IOW and the ISA address bus at the same time.
you can ignore C10 SRESET, its for something power management.
>For context, earlier probing of the BIOS showed /CE, /OE, address-line activity, and data-line activity, so the board is definitely doing something rather than being completely inert.
this is actually bad 😀 what would be flipping all those pins if CPU wasnt reset? Check with no CPU installed.
SiS85C471 https://theretroweb.com/chip/documentation/85 … 87929110712.pdf generates cpu reset on pin 91 RSTCPU, ISA reset pin 205 RSTDRV. Chipset generates its own reset using 113 PWRGD input.
You can try pulsing 5V thru 1K resistor to CPU C16 to see if it will come to life, afaik chipset doesnt actively drive that line and its normally pulled low with resistor somewhere. Also I would measure C16 to ground resistance, maybe something is shorted not letting chipset drive reset.
I’ve made quite a bit of progress with a 16-channel logic analyzer and an ISA breakout board, although I still haven’t found the actual fault. Protip: the ISA breakout board with headers was 1000% required here, those little clips that come with the logic analyzer are impossible to attach to ISA pins.
The current test configuration is an Intel DX4ODPR100, four known-good 30-pin SIMMs, and no external cache/TAG. I’ve also tested without RAM, and previously tried another 486 CPU without changing the basic no-POST symptom.
Things that have been checked/eliminated so far:
BIOS EPROM has a solid 5 V supply and reads correctly in a programmer.
I also programmed a replacement EPROM with an independently sourced 11/26/94 BIOS image. That EPROM/image is known-good, but the board behaves essentially the same, so the original BIOS chip/content is looking unlikely as the cause.
Removing all cache SRAM and TAG made no difference.
Reset is not stuck. The J6 reset input works normally and the ISA RESET signal releases.
CPU/clock/cache/CMOS/etc. jumpers have been audited against the manual and nothing obvious is misconfigured.
The CPU is definitely executing BIOS code.
Using /SMEMR plus the ISA address bus, I can see a repeatable block of early memory reads immediately after reset. A later capture including the upper address lines proved these accesses are in the F8000h–FFFFFh BIOS ROM region, not RAM.
There is a particularly repeatable initial sequence of 64 BIOS reads. Across multiple boots the addresses and timing are essentially identical.
The interesting part is what happens after that.
With the same CPU, RAM, and BIOS, different power-ons take substantially different paths. For example, one boot may stop after the initial 64 ROM reads, another may continue through hundreds of memory cycles, and another may enter a very long repetitive memory-read loop. In one capture I saw hundreds of thousands of repeated reads continuing for many seconds.
Adding RAM makes a huge difference compared with running without RAM: with no SIMMs there is very little ISA-visible activity, while installing four known-good SIMMs allows the BIOS to get much farther. However, it still does not POST reliably and the execution path varies from boot to boot.
A useful control was done with the replacement BIOS. Two captures with the same replacement EPROM showed the same first 64 ROM-read data bytes, byte-for-byte, but the machine behaved completely differently immediately afterward. That makes an unstable BIOS ROM read less likely and points more toward something that happens during/after early chipset and DRAM initialization.
One other thing we’ve established: the cheap ISA POST card’s numeric display is not trustworthy here. The card often rapidly cycles things resembling C0C0, C000, 00C0, and sometimes similar patterns involving E. It changes much too quickly to look like normal POST progress.
I captured the full ISA data bus together with /IOW and enough address bits while the POST card was visibly cycling those values. The analyzer showed no actual writes of C0 to port 80h during that period—in fact, no matching port-80 writes at all. So the card appears to be latching unrelated ISA activity/timing artifacts rather than displaying genuine Award POST codes. I’m therefore ignoring its numeric display for diagnosis, although its power/clock/reset indicators are still useful.
At this point the working suspicion (with the help of ChatGPT's analysis) has shifted toward an intermittent motherboard-level problem in the memory/chipset path rather than CPU, BIOS EPROM, cache, or reset.
The next planned test is to look directly at the DRAM control signals on the 30-pin SIMM bank—/RAS, /CAS, and /WE—and compare a “short” boot with one of the boots that runs much farther. The goal is to see whether the SiS chipset is issuing a consistent DRAM initialization sequence or whether the memory-control behavior itself changes from boot to boot.
I'm not sure of the best way to attach the analyzer to the SIMM pins, so far the best suggestion was to solder wires on to the bottom of the board which seems sub-optimal. It would be excellent if a memory "breakout board" of some kind existed.
So the current high-level picture is:
reset works → CPU fetches and executes BIOS → initial BIOS fetch is repeatable → execution becomes inconsistent around early memory/chipset initialization.
If anyone familiar with the SiS 85C471/85C407 chipset or this GA-486VF revision has suggestions for particularly useful DRAM/chipset signals to probe next, I’d be interested.
Good luck. I had one of those mini 486 boards with a soldered on UMC Green CPU in a similar condition and tried to get it working--to the point of even making a custom "BIOS" that was just a bunch of nops or a jmp $ or whatever to keep the code execution simple--and never got anywhere and ended up giving the board away.
With the same CPU, RAM, and BIOS, different power-ons take substantially different paths. For example, one boot may stop after the initial 64 ROM reads, another may continue through hundreds of memory cycles, and another may enter a very long repetitive memory-read loop.
There is a big difference between cold boot and reset. Bios checks for this in first instructions before deciding what to execute
One other thing we’ve established: the cheap ISA POST card’s numeric display is not trustworthy here. The card often rapidly cycles things resembling C0C0, C000, 00C0, and sometimes similar patterns involving E. It changes much too quickly to look like normal POST progress.
I captured the full ISA data bus together with /IOW and enough address bits while the POST card was visibly cycling those values. The analyzer showed no actual writes of C0 to port 80h during that period—in fact, no matching port-80 writes at all.
You can scroll POST codes back with a button on most post cards to verify if those are random or always there. Some Post cards also allow switching listening port, maybe yours is listening to non standard port for some crazy reason? 😀
The next planned test is to look directly at the DRAM control signals on the 30-pin SIMM bank—/RAS, /CAS, and /WE—and compare
there is no point doing this if as you are claiming bios execution is random and you get no port 80 writes
setup capture at lets say 20MHz for A1-7, /IOW, D0-7 and run it couple of times from cold boot and couple resets making separate capture files every time and naming them so its obvious which is which
reset works → CPU fetches and executes BIOS → initial BIOS fetch is repeatable → execution becomes inconsistent around early memory/chipset initialization.
do you have a trace log of BIOS execution?
setup capture at lets say 20MHz for A0-15
then switch to A0-7 D0-7 and same thing
again run it couple of times from cold boot, and couple resets making separate capture files every time and naming them so its obvious which is which
It might only look like execution is non deterministic if you keep resetting the system at different stages of boot.
I followed up on the suggestion to make more controlled captures and separate cold-boot behavior from reset behavior. One clarification from my earlier post: all of my previous captures had been from true cold boots, not from pressing Reset at different points in POST.
For the first test I captured:
/IOW + A1-A7 + SD0-SD7
at 20 MHz for 10 seconds, with no trigger, starting the analyzer before power-on. I made three separate cold boots with a full power-off between each.
The results were not the same. Two boots produced no convincing ISA I/O activity after the initial power-on settling. The third boot, about 0.6 seconds after power-on, produced 15 clean /IOW cycles around 750-800 ns wide. So identical cold boots can apparently reach different amounts of ISA-visible execution.
I then repeated the experiment around a warm reset, initially with the same wiring. Two reset captures followed an almost identical sequence of five /IOW cycles with the same data:
65 6D 55 25 7D
while another reset produced no genuine /IOW cycles.
Because reset timing itself was a possible variable, I sacrificed an address bit and captured RESET directly along with /IOW, address bits and SD0-SD7. The three manual reset assertions were all substantial and similar:
Capture RESET duration
1 ~248 ms
2 ~235 ms
3 ~259 ms
The automatic power-on reset was also essentially identical in all three at about 392.6 ms.
Despite comparable reset pulses, the post-reset behavior differed dramatically. One run produced six normal /IOW cycles, one produced about 3,939 normal /IOW cycles, and one produced none. So the differing behavior does not appear to be explained simply by different reset-button duration.
Next I followed the suggestion to look at BIOS memory accesses.
I captured:
/SMEMR + A0-A14
at 20 MHz, again for three separate cold boots.
All three start with the same initial 64 /SMEMR accesses, with the captured A0-A14 address sequence matching across all three. The block is also very similar in timing, taking roughly 52 µs.
After that they diverge. Two captures stop showing ISA memory reads after those 64 accesses. In the third, after a gap of roughly 614 ms, the board resumes with a very large amount of /SMEMR activity — about 173,000 reads. Most of that later activity is a very regular loop over captured low addresses:
07E0 ... 07EF
repeated many thousands of times.
So I agree that the huge repeated-read sequences I saw earlier could simply be BIOS polling/delay-loop behavior; by themselves they are not evidence of corruption.
I then rewired for:
/SMEMR + A0-A6 + SD0-SD7
to compare the data returned during those initial ROM reads.
The important result there is that the initial 64 returned data bytes are identical across all three cold boots as well. So both the initial ISA-visible ROM address pattern and the ROM data are repeatable. The boots still diverge afterward.
I realize /SMEMR on ISA is not a literal CPU instruction trace, so I don't want to overstate this as proving the exact point at which CPU execution branches. What I think we can safely say at this stage is:
cold boot/reset is repeatable enough to reach the same initial ROM accesses and return the same ROM data, but subsequent ISA-visible activity can differ substantially between otherwise identical starts.
My next thought is to follow the suggestion from rasz_pl to burn a deliberately tiny diagnostic BIOS that does essentially nothing except execute from ROM and repeatedly write a known sequence such as:
11 22 33 44 55 AA
to port 80h, without depending on DRAM or a stack. That should give us a much simpler test of whether basic reset → ROM execution → ISA I/O is itself deterministic.
I also have an ISA CGA video adapter on order, along with an MCE2HDMI. The motherboard currently has no usable video output, so if we can get it far enough to initialize even a basic CGA card, finally having a picture may give us another useful diagnostic channel instead of relying entirely on the POST card and logic analyzer.
More to come as I write the junk BIOS and test with it.
Two boots produced no convincing ISA I/O activity after the initial power-on settling. The third boot, about 0.6 seconds after power-on, produced 15 clean /IOW cycles around 750-800 ns wide. So identical cold boots can apparently reach different amounts of ISA-visible execution.
no, afaik cold boots are pretty deterministic, plus cant boot without any /IOW. One of teh very first things BIOS does is reading CMOS. To read Cmos you start by writing port number to port 0x70.
Despite comparable reset pulses, the post-reset behavior differed dramatically. One run produced six normal /IOW cycles, one produced about 3,939 normal /IOW cycles, and one produced none.
few and then nothing could be explained by some stuck hardware making the BIOS panic, but none at all is definitely bad unless chipset filters port 0x70 CMOS writes from ISA bus. Try capturing /IOR too, maybe its getting stuck on /IORs not liking KBC responses. First thing BIOS does is read KBC.
Next I followed the suggestion to look at BIOS memory accesses.
The important result there is that the initial 64 returned data bytes are identical across all three cold boots as well. So both the initial ISA-visible ROM address pattern and the ROM data are repeatable. The boots still diverge afterward.
looking at the listing now the very first IO Write is either
- 1000h zeroes written to 0xE1 (dummy address)
or
- 0x8F written to CMOR address reg 0x70h. 0x8F is really 0x80 (special NMI flag) + 0xF = CMOS_0Fh_Shutdown_Status so the BIOS can check what happened last time it was powered.
If you have a rpi pico board it might be worth experimenting with gusmanb/logicanalyzer Re: Vintage 8088 motherboard repair and capturing 24 IOs at the same time
Thanks — your latest post helped clarify what we should be looking for, and I think it changes the next phase of testing in a useful way.
To go back to a point from earlier in the thread (and I reminded ChatGPT of this as well): this board originally had battery leakage around the keyboard connector / 8042 / SIMM area. It was cleaned thoroughly and the battery replaced. I’ve done quite a bit of continuity testing in that area and haven’t found an obvious open trace, but obviously I can’t claim every trace/via has been exhaustively checked. So the KBC/CMOS possibilities you mentioned are particularly interesting here.
In the meantime I had been experimenting with a few deliberately tiny BIOS images to try to establish how far the CPU was getting.
v1 was basically a minimal execution test. It produced BIOS-ROM activity, but the POST-card values were inconsistent and I couldn’t confidently associate them with the code.
v2 repeatedly wrote a known sequence:
11 22 33 44 55 2A
to port 80h.
We captured /IOW, A0-A7 and SD0-SD6. Although we could see ROM fetches from the area containing the diagnostic code, we never saw the expected repeating 80h write/data pattern on ISA.
v3 followed the suggestion here to also use a supposedly-unused port. Each marker was written to both 80h and E1h:
11 -> 80h
11 -> E1h
22 -> 80h
22 -> E1h
...
I took several 200M-sample/20 MHz captures, including cold boots and RESET while powered.
None showed the expected continuous 80/E1 pattern. There were occasional isolated 80h-looking cycles, but with the wrong data and no corresponding E1h, so I don’t believe those were our diagnostic loop.
v4 tried to avoid I/O completely. It repeatedly read six marker bytes from fixed ROM locations:
0100 -> 11
0120 -> 22
0140 -> 33
0180 -> 44
01A0 -> 55
01E0 -> 2A
I tried to observe that through ISA /SMEMR. The cold boot showed very little useful activity, while after RESET there was a large amount of memory-read activity, including long sequential address runs. Unfortunately ISA /SMEMR did not give a clean enough representation of the BIOS-ROM accesses to say that v4 passed or failed.
So at that point the remaining question was simply: is the CPU actually executing sustained code correctly after the reset vector, or are we only observing ROM fetch activity before things go wrong?
Your latest post convinced me that rather than keep inventing synthetic ROM tests, we should use the real Award BIOS as the roadmap.
I have now dumped and had the bot start disassembling the exact BIOS currently used on this board:
11/21/94-SIS-85C471B/E/G-2C4I9G01-00
The early path in this version is very similar to what you found:
FFFF0
-> F000:E05B
-> F000:DAB2
and the first explicit I/O operation is:
IN AL,64h
TEST AL,04h
So, exactly as you suggested, the 8042/KBC is involved essentially immediately.
The interesting part is what happens next.
If bit 2 from port 64h is clear, this BIOS loads CX=1000h and executes:
OUT E1h,AX
LOOP ...
4096 times.
That immediately makes one of my previous captures much more interesting: one reset run contained about 3,939 normal /IOW cycles. I had treated that only as “a lot more activity than the other boots,” but now it looks very plausible that I captured most of this exact 4096-write loop.
On the other branch, the BIOS performs the sequence:
OUT 70h,8Fh
OUT E1h,AX
IN AL,71h
OUT E1h,AX
CMP AL,1Ch
So we now have a much better set of expected signatures than simply counting /IOW pulses.
Because of your advice, I’m changing the next tests as follows:
Go back to the original 11/21/94 Award BIOS, rather than continuing with custom v5/v6/etc. ROMs.
Capture /IOR as well as /IOW.
Look specifically for the initial read from port 64h and record the returned data.
Use that value to determine which branch the BIOS should take.
Then look for the expected E1h loop or the 70h/E1h/71h/E1h sequence.
Record address + data pairs, not just the data bytes, including going back to the earlier 65 6D 55 25 7D capture you asked about.
That should let us stop saying “this boot had six I/O cycles and that one had 3,939” and instead say something much more useful, such as:
“The BIOS read KBC status from 64h, got XXh, took branch Y, completed Z transactions, and then stopped before the next expected instruction.”
Given the battery damage location, if execution consistently stalls around the 8042 or CMOS transactions, that gives me a very concrete area of the board to start checking electrically.
Your Raspberry Pi Pico / gusmanb/logicanalyzer suggestion is also noted. My current SLogic channel count makes capturing both strobes plus enough address/data lines simultaneously a little awkward, so a 24-channel capture may become useful once we know exactly which signals we want. I also looked into 32 channel options and they are pretty expensive.
I also have a OneROM 28-pin USB-C unit on order, which should at least eliminate the repeated EPROM erase/program cycle, and may eventually give us another way to observe ROM accesses.
So I think the main takeaway is: the custom BIOS tests were useful for establishing that ISA-visible behavior was not straightforward, but your disassembly gives us a much better path now. We’re switching from generic bus-activity counting to following the actual early Award BIOS execution sequence instruction-by-instruction.
>v2 repeatedly wrote a known sequence:
>11 22 33 44 55 2A
>never saw the expected repeating 80h write/data pattern on ISA.
This is worrying.
>Each marker was written to both 80h and E1h:
this is for adding delay, cheaply implemented hardware cant handle rapid IO writes. It was cheaper to simply demand some delay (like dummy IO or even a short jump) instead of implementing wait states etc.
Do you still have working GA-486VF rev6? Try it with POST card and logic analyzer to see if you can reliably capture IO writes just to sanity check the capture setup.
You can also try capturing directly on pins of KBC, no pinout for the 20pin version, but you can trace its pins to 40 pin pinout for important signals.
What are the voltages on /IOR /IOW? maybe its something as stupid and simple as cracked resistor network meant to pull those up?
Thanks — the sanity-check suggestion with the working Rev.6 turned out to be extremely useful, and I also read through the VCFed thread you linked. There are some striking parallels.
I do still have a working GA-486VF Rev.6, so today I set it up as closely as practical to the faulty Rev.8B:
- same exact 11/21/94 Award BIOS image
- same functional jumper settings
- same Intel DX4ODPR100 CPU, physically moved between boards
- same analyzer and capture settings
- same basic ISA configuration
The Rev.6 still has its known-good cache/TAG installed, while the Rev.8B currently has no cache/TAG. Since we are concentrating on the first few BIOS operations, I left the working board intact rather than deliberately removing working cache from it.
The Rev.6 boots normally with this setup — video appears and RAM counts.
More importantly, the logic analyzer works perfectly on the Rev.6.
With /IOR, /IOW, A0-A7 and selected data bits captured, the good board follows the disassembled BIOS path exactly:
1IN 64h
The returned KBC status has bit 2 clear, after which the BIOS executes the CX=1000h delay loop:
1OUT E1h,AX
4096 times.
Your explanation of E1h as a cheap I/O delay mechanism makes sense here.
One correction to my previous post: because this is a 16-bit OUT starting on an odd port, every OUT E1h,AX appears as two ISA byte cycles:
1E1h 2E2h 3E1h 4E2h 5...
so the complete healthy loop produces 8192 /IOW cycles, not 4096. The Rev.6 gives exactly that.
Afterward it proceeds into the expected 70h/71h CMOS activity and then normal initialization/POST.
So the analyzer/wiring is now well sanity-checked. The absence of our expected 80h/E1h loops in the little test ROMs on the Rev.8B really is concerning rather than an analyzer artifact.
The faulty Rev.8B behaves very differently.
I took three nominally identical cold-start captures:
1rev8b_bad_cold_01: 2 large 82h/83h I/O burst, 3 followed by sustained repeating activity around 82h 4 5rev8b_bad_cold_02: 6 essentially nothing except a few 82h/83h accesses 7 8rev8b_bad_cold_03: 9 no meaningful ISA I/O at all
None shows the healthy:
1IN 64h 2-> E1/E2 delay loop 3-> CMOS activity
So the bad board’s ISA-visible behavior genuinely varies quite a lot between nominally identical cold starts.
I then did two longer captures with the Rev.8B already powered and pressed RESET at about 10 seconds.
RESET clearly affects the machine — bus activity stops while RESET is asserted and resumes after release — but in both captures there are zero /IOR and zero /IOW cycles after reset.
I repeated the same reset experiment on the working Rev.6. It comes straight back with:
1IN 64h 2-> exactly 4096 OUT E1h,AX 3-> CMOS 4-> POST
So I then stopped looking at ISA I/O and probed the BIOS ROM control pins directly:
1/CE 2/OE
On the good Rev.6, after reset there is sustained heavy ROM activity and execution continues normally.
On the faulty Rev.8B, the BIOS ROM is definitely being accessed after both cold power-on and hardware reset. The interesting part is that the initial organized ROM activity lasts only about 67 µs and then collapses into much sparser/repeating ROM accesses.
So the current picture is:
1Good Rev.6: 2RESET 3-> ROM fetch 4-> sustained execution 5-> IN 64h 6-> E1 delay 7-> CMOS 8-> POST 9 10Bad Rev.8B: 11RESET 12-> ROM fetch begins 13-> ~67 µs of organized activity 14-> normal execution goes wrong 15-> never reaches the first ISA-visible IN 64h
This also makes the apparently random ISA behavior a little easier to interpret: the initial ROM-side failure looks much more repeatable, while the machine may subsequently fall into different abnormal states.
The VCFed thread you linked is especially interesting because it is almost a parallel case. That poster also had a GA-486VS Rev.8B with the SiS 85C471/407 and the 11/21/94 Award BIOS.
He likewise found no /IOR or /IOW activity with the normal BIOS, then confirmed that the ROM started fetching at FFF0.
His reset vector also jumps to F000:E05B, but he became suspicious that the subsequent ROM-address sequence was not following the BIOS code correctly.
Interesting that he created almost the same synthetic test we did: an infinite loop writing a known value to port 80h. He observed the expected value once, but the loop did not continue.
That sounds uncomfortably similar to our v2/v3 result: the ROM is accessed, but a trivial continuous I/O loop does not execute normally.
His case does differ in one important respect: he reported no battery corrosion, whereas my Rev.8B definitely had battery leakage concentrated around the keyboard/KBC/SIMM area. So I’m not assuming the physical cause is necessarily the same.
He also suspected that the data coming out of the ROM did not match the bytes actually stored in it, although his measurement setup required capturing address lines separately and he wasn’t confident in the result.
That may now be exactly the next question:
1During those first ~67 µs, is the CPU/chipset fetching the correct ROM addresses and receiving the correct bytes?
I considered clipping a dozen address lines directly onto the EPROM, but that’s enough probes on adjacent pins that I’d rather not introduce another source of trouble. I have a OneROM on order, so I’m planning to use that for the next ROM-side investigation/address monitoring rather than turn the EPROM into a porcupine.
In the meantime I can easily follow up on your simpler hardware suggestion: compare the idle/high voltages of /IOR and /IOW on the good Rev.6 versus the faulty Rev.8B, and inspect the associated resistor-network/pull-up area. If one of those lines isn’t being pulled up properly on the Rev.8B, that would be a much nicer explanation than a chipset fault.
I’m also keeping the KBC-area suggestion in mind because of the battery leakage location. But based on the reset comparison I’m hesitant to blame the KBC itself yet: the bad board appears to lose normal execution before the BIOS ever generates its first IN 64h.
