LocalBus wrote on 2022-02-01, 17:00:

Here goes, out of necessity I needed to lift it 😀

So looking up the datasheet for the D27C010, pin 1 is a 12V programming pin, so should be at 5V unless you want to make it possible to program the chip. Hopefully others can use that BIOS dump. I did notice the string 2A5ULT40 in it, which led here: https://loyalp.tripod.com/tonym/numbers.htm, which gives it as an "Opti 82C822/571/572 Chipset (Pentium based m/b)" "2A5ULT40: Taken (model: ???) ", so looks like Taken is correct.

Looking forward to seeing what Jan says about it.

There is certainly no lack of engagement in this forum, thanks a lot!!

Yes indeed, very much looking forward to hear the outcome from Jan 😀

Ok I have found one obvious trace damage going into pin 132 on OPTi 82C571 chipset:

This is obviously not good but not sure what it does (cannot find a datasheet for 82C571).

Nothing that a soldering iron cannot fix 😀

I have also been tracing / probing like nuts and have managed to trace at least all Xd[7:0] (Pins 18:25) from the 82C206 to 82C572.

In addition I have traced XA1 and XA0 from 82C206 to 82C572.

What is interesting is that from 82C206, XA0 and XA1 also interconnects with the BIOS ROM (via 74F244P) and Xd0 and Xd1 directly to the BIOS ROM.

XA0 and XA1 are also handled separately from 82C572 and I cannot find that these addresses are buffered in the same way as XA[9:2] ?

With the limited knowledge I have about the BIOS I have gathered as far as address 70h and 71h are used for CMOS read/write - thus those can be addressed by XA[1:0] and Xd[1:0] address and data pins respectively?

You can clearly see those vias adjacent to pins 18, 19 (Xd0, Xd1) and pins 41, 39 (XA0, XA1):

Well spotted. That's not going to help. I don't have a picture of the right bit of the back of the board, so can't trace it. Maybe (wild guess time) it's an address line to the BIOS? Not one that breaks reading some blocks out of the ROM (so a higher address line), but does cause problems when the BIOS does its checksum and is trying to read the whole thing. I think that was one of the possible reasons for a B0 error given in the general POST code lists.

snufkin wrote on 2022-02-02, 20:53:

Well spotted. That's not going to help. I don't have a picture of the right bit of the back of the board, so can't trace it. Maybe (wild guess time) it's an address line to the BIOS? Not one that breaks reading some blocks out of the ROM (so a higher address line), but does cause problems when the BIOS does its checksum and is trying to read the whole thing. I think that was one of the possible reasons for a B0 error given in the general POST code lists.

Thanks! We'll you are the GIMP master 😀 let me know if these pictures can help in any way:

Thanks. Not certain, but it looks like it goes to pin 115 of the 82c822, which does have a datasheet, which says it's LGNT#, which I think signals to cards on the local bus (in this case, PCI cards, maybe some other stuff?) that they've been granted access. So not the BIOS.

Not certain because at some point the trace is on the top surface and goes under the resistor network and JP32. It does split at a via just before pin 115, goes along under the 288, then comes back up again somewhere around pin 85, but still underneath the 288, so would need to check for continuity around there.

snufkin wrote on 2022-02-02, 21:27:

Thanks. Not certain, but it looks like it goes to pin 115 of the 82c822, which does have a datasheet, which says it's LGNT#, which I think signals to cards on the local bus (in this case, PCI cards, maybe some other stuff?) that they've been granted access. So not the BIOS.

Not certain because at some point the trace is on the top surface and goes under the resistor network and JP32. It does split at a via just before pin 115, goes along under the 288, then comes back up again somewhere around pin 85, but still underneath the 288, so would need to check for continuity around there.

Thanks, yes I think made the same conclusion from the pictures. Tomorrow I will repair the trace and probe from there!

Do you know if CMOS RAM addressing is enough with just XA0 and XA1 adress bits? They are certainly treated differently.

I think there's generally something a bit odd about the first couple of address lines. The main RAM is 32 bit, but the CPU can still address down to 8 bit (or something like that, I think). So if the CPU wants a particular byte then the last couple of address lines don't actually matter, all 4 bytes are grabbed anyway and the CPU can read the 1 byte out of the 4 that it actually wants. But the ROM is 8 bit. So it does need the full address. Feels like a way to get backward compatibility for code that suddenly finds itself on a 32 bit machine.

I think CMOS reads are done by accessing registers in the 206, but I haven't read up how that's done.

snufkin wrote on 2022-02-02, 21:46:

I think there's generally something a bit odd about the first couple of address lines. The main RAM is 32 bit, but the CPU can still address down to 8 bit (or something like that, I think). So if the CPU wants a particular byte then the last couple of address lines don't actually matter, all 4 bytes are grabbed anyway and the CPU can read the 1 byte out of the 4 that it actually wants. But the ROM is 8 bit. So it does need the full address. Feels like a way to get backward compatibility for code that suddenly finds itself on a 32 bit machine.

I think CMOS reads are done by accessing registers in the 206, but I haven't read up how that's done.

From the 82C206 datasheet -> https://www.datasheetarchive.com/pdf/download … opti%252082C206

Signal Name: Xd[7:0]

Pins (100 PQFP): ​18:25

Signal Description:

"The Xd
data bus pins are also used as the multiplexed address/data bus for
the real-time clock (RTC) and CMOS RAM accesses"

Signal Name: XA[9:0]

Pins (100 PQFP): ​31:39, 41

Signal Description:

"X Address Bus bits 9 through 0: These pins are directly connected to
the XA bus in PC/AT-based designs. XA[8:0] are bidirectional pins
and XA9 is an input only pin.
During CPU I/O accesses to the 82C206, XA[9:0] are used for
addressing the Configuration Register and the internal registers of
the 8237, 8259A, 8254, RTC, CMOS RAM, and 74LS612."

Repaired trace from Pin 132 to pin 115 between 82C571 and 82C822, unfortunately no improvement:

Intermittent getting C5C1 when resetting too often:

As mentioned above, electrolytic capacitors are way past due date. But I recon it should cause more erratic behavior than constantly getting stuck at 0B 0A. Or maybe it is just too unstable to get past this point.

82C206 is at least somewhat warmer than fingerwarm, I have not yet managed to trace all address lines to it (trace disappears underneath 82C822 through via holes).

One thing that puzzles me, but seems to be same for all the MC74F245N transceivers, is that they have the BE (active low) pin floating. Shouldn't those report 0V potential against ground to be enabled?

Well, it needed to be fixed regardless. What graphics card are you trying to boot with?

snufkin wrote on 2022-02-03, 17:57:

Well, it needed to be fixed regardless. What graphics card are you trying to boot with?

Cirrus Logic Gp-5446

Do you have any ISA cards you could try with, in case there is a problem with the LocalBus -> PCI bridge?

LocalBus wrote on 2022-02-02, 21:33:

Do you know if CMOS RAM addressing is enough with just XA0 and XA1 adress bits? They are certainly treated differently.

CMOS is accessed by reading just two ports, so in theory one address bit + Chip Select + IOR + IOW is all that would be needed (like keyboard controller). In practice 206 is more than just RTC and needs all the address lines connected to CPU address buss.

LocalBus wrote on 2022-02-02, 21:33:

What is interesting is that from 82C206, XA0 and XA1 also interconnects with the BIOS ROM (via 74F244P) and Xd0 and Xd1 directly to the BIOS ROM.

all ROM data pins should be in parallel with 206 data pins - they are on same data bus

snufkin wrote on 2022-02-02, 21:46:

I think there's generally something a bit odd about the first couple of address lines. The main RAM is 32 bit, but the CPU can still address down to 8 bit (or something like that, I think). So if the CPU wants a particular byte then the last couple of address lines don't actually matter, all 4 bytes are grabbed anyway and the CPU can read the 1 byte out of the 4 that it actually wants. But the ROM is 8 bit. So it does need the full address. Feels like a way to get backward compatibility for code that suddenly finds itself on a 32 bit machine.

afair 486 was the first intel CPU with build in full data bus bifurcation, where you could tell CPU how wide the bus was for particular access (bs8 bs16) and it accommodated requests in 1-2-4 byte steps. 386 could only divide into 2 or 4 byte accesses (bs16) and still required discrete 8bit buss byte swap logic like 8086/286.
https://www.reddit.com/r/Z80/comments/lnl7wc/ … ory_addressing/

address bits 0 and 1 are special because they arent directly generated by the CPU. 386/486 doesnt have them, address bus is 2-31. They are generated by whatever controls(chipset/discrete logic) BS8 BS16 and reads BE0-3 from the CPU.
https://en.wikichip.org/w/images/d/d3/i ... (1990).pdf page 7-6 7-7

snufkin wrote on 2022-02-03, 18:07:

Do you have any ISA cards you could try with, in case there is a problem with the LocalBus -> PCI bridge?

its too early in the boot process for any cards to matter, if anything bad 206 will make ISA cards not respond.

snufkin wrote on 2022-02-03, 18:07:

Do you have any ISA cards you could try with, in case there is a problem with the LocalBus -> PCI bridge?

Yep a Trident card:

I have tried it before, but will give it another shot 😀

Rasz sounds right about the fact it's still too early in the boot process. I had seen one list that had Award BIOS 0B as including an initialisation of video interface, so thought it could be a problem. But most lists seem to start that around 0D, and 0B looks to be more CMOS related, and I don't have the skills to trace what the BIOS actually does.

The list here: http://mrbios.com/techsupport/award/postcodes.htm has for "Late Award BIOS (4.5x-non PnP)" that 0B is "Test CMOS RAM Checksum if bad or Insert key depressed; load defaults.". So maybe hold insert. OTOH, the same list does only show initialise keyboard at 0C, so I don't know how holding interrupt would help.

Well at least holding down a key generates complaints via the PC speaker and is stalling the POST check at 07 for a while before proceeding to 0B 0A.

Holding down the 'Insert' key unfortunately makes no difference. The purpose is to force it load defaults without really checking CMOS RAM settings?

So why on earth can't it load the defaults from BIOS ROM.

So all Xd[7:0] signals should go to the BIOS ROM. I will confirm this.

Edit: Confirmed, all Xd[7:0] goes to BIOS ROM. XA0 and XA1 as well. Are XA[9:2] supposed to go to BIOS ROM as well?

Next POST code: 0C is to set NumLock status?

POST code 07: "
Test CMOS Interface and battery status. Detects bad battery. BE and Chipset Default Initialisation. Program chipset registers with power-on BIOS defaults.".

So CMOS interface is good?

POST code 0C: "Initialise keyboard; Set NUM LOCK status."

I do wonder if something is fishy with 32kHz oscillator and RTC / CMOS after all... going in circles!

Stupid question, should the Xtal1 input on the keyboard controller pin 2 be shorted to GND?

Xtal2 pin 3 is connected to the reference 14.318 MHz clock (Chrontel clock generator).

Sounds ok. If the KBC is generating it's own clock from a separate crystal then it'll output a signal on pin 2 to the crystal, with the feedback coming in through pin 3. Here the Chrontel can drive the clock input (pin 3) directly.

Q1 (PNP) is done. I only get 3.7V to 82c206. I think we are finally getting somewhere. I could swear I measured this before!

Anyways, I will put an order on two fresh PNP and NPN BJTs along with new electrolytic capacitors.

Boy this mainboard have received some precious time and love!!