There are no such dedicated pins on the CPU.

BIOS ROM CMOS NVRAM are devices that are mapped to I/O port and memory ranges and the CPU communicates with them using a general-purpose system bus just like with other devices on the motherboard.

Upon start, the CPU wakes up in real mode and begins execution at address FFFF:0000 which is where BIOS ROM should map itself to.

You can certainly try to debug this process. However, it can get quite complicated even on 486. If you have a damaged board it is usually better to do easier troubleshooting. such as using POST card, closely inspect mb for obvious damage, check/swap parts, etc.

So would the cpu talk directly to the south/north chipsets? I am mainly getting the cmos register error but I have also experienced other random bios beep errors so I believed this link you describe through the system bus is broken somewhere

yeah I have been troubleshooting quiet a bit already, I made a thread about it but I had this question specifically on how the cpu communicates with the cmos.

https://www.vogons.org/viewtopic.php?t=73084

this is my original thread

Perhaps describe the "CMOS register error" you see and how does it manifest.

If CPU data or address bus were broken the computer wouldn't be doing anything at all (not even beep) as it wouldn't be able to execute the BIOS code and know it has to beep 😀

The CPU bus is connected via northbridge to RAM. The BIOS ROM likely sits on the ISA BUS.

The CMOS and RTC can have many forms from integrated Dallas chip, a number of discreet devices up to being fully integrated into the chipset. If external it is usually connected to the chipset via ISA or dedicated multiplexed bus or I2C on newer systems. Depends on the motherboard.

As soon as I power on I get 1o beeps which is the cmos register read/write shutdown errror.

The cmos is integrated into the opti f82c206q chip on this board

Since I have a working copy of this motherboard this is what I have done first:

1. Verified cpu/ram working
2. removed cache
3. Tried Bios from working mb
4. Tried keyboard controller from working mb
5. Tried external bettery
6. Tried resetting cmos with cmos pin and by shorting the pins on the f82c206q chip as per pinout I found
7. Changed Tantalum capacitors on the power rails + around cmos/bios and chipset
8. Checked for shorts to ground on power rails, resistors, capacitors, bios, chipset, cmos - no shorts and different readings to working motherboard
9. Removed cmos hex inverter, tested in a external reader tl866 - passed test. Installed socket and tried a different hex inverter of same spec. (at one stage during this process I got 9 and perhaps 7 beeps then back to 10 beeps each time)
10. Finally sourced a new f82c206q cmos chip and removed old one and soldered new one, - still 10 beeps

So now I am back at square one, trying to follow the logic path of where this signal at start up would fail communicating with the cmos. Its my current theory anyway. I am putting it down to some trace, maybe a multilayer one being broken. But I have a working version so by comparing continuity readings and resistance I can find this just trying to narrow it down by the logic path of the cpu-bios-cmos and whatever else communication on post (which I am pretty clueless about)

But thank you for your help so far already told me some good information

Hello treeman,

It's hard for me to follow whether you're asking about the CMOS RAM, the BIOS itself, or both, and it seems like the 82C206 chip is both the BIOS ROM and the CMOS RAM?

In any case I'm not of much help other than here's some source code used on Linux when it wants to update the date/time stored in the CMOS. https://github.com/karelzak/util-linux/blob/m … /hwclock-cmos.c If you follow the code you can see there are reads and writes to IO ports 0x70 and 0x71. The pins the CPU uses to do in and out instructions would be used not just for CMOS but I/O to any device.

I'm not sure if the BIOS ROM reads from the CMOS the same way or if it has some kind of "shortcut" way to talk to the CMOS RAM. I've never thought about it that deeply.

When you say both 10 beeps and also CMOS register error, you're saying that's what the beeps mean? Or it actually gets to the point of showing video and prints CMOS register error

For Ami bios this is what I can find for 10 beeps

10 Short Beeps
Ten short beeps means that there has been a CMOS shutdown register read/write error

In my case the 82C206 has cmos ram integrated.

I get 10 beeps, no video, no other activity - cpu gets warm.

There is not much information on google about this error at all, so I have been looking up how the cmos communicates on post. I don't think the Bios rom here is part of the problem but because I am unsure exactly what the logic is I also mentioned it.

From the pieces of informantion I have researching and just received on this thread this is how I see it:

1. Power on
2. power to cpu
3. cpu in real mode maps itself to bios rom (successful I think because we have next step)
4. 10 beeps because cpu can't make contact with the cmos

As I udnerstand now its not as simple as 1 pin going from cpu to cmos but interface over the system bus using i/o used by other devices too to map the memory locations for each device l.

Since I replaced the cmos+integrated cmos ram, bios rom I am troubleshooting that the signal is lost somwhere between cpu to cmos route.

I will look closer at both the chipsets as the next move, compare some readings from good motherboard chipsets to the faulty one

Yes I see the source code you provided, I think its very relevant because irs accessing the cmos ram doesn't matter what its doing inside the ram. So under the assumption cmos read/write register error is a problem accessing the cmos ram its the same function - IO ports 0x70 and 0x71

Now I need to try track down the hardware route

treeman wrote on 2020-06-13, 03:40:

Now I need to try track down the hardware route

I can see there were some repairs done to this mobo after the battery spill corroded some traces? In my experience any issues with accessing the CMOS or ISA bus in general are due to broken connection in that area. So double, triple check every piece of copper that looks even remotely affected - some might just have a dark spot and that's actually a clean break, copper eaten all the way through, on otherwise nice-looking race.

Inspect if the spill didn't travel a bit and got under a chip nearby. Often the exposed PCB will dry out quickly and looks untouched, but under the chip there's some nasty corrosion. That's especially the case for vertically mounted mobos - the spill can actually get all the way down and pool there, and the area in-between has next to no damage.

I removed the keyboard connector, everything has right continuity and resistance under it.

Checked voltages on the cmos chip, vcc pins have 5v.

Also checked vcc on the chipset also has 5v vcc pins

I need to inspect really good under the ram slots and keyboard controller again incase I missed some hidden acid there like you said.

Apart from that not really sure how to trace the signal.

cmos, chipset, cpu and bios are all powered and work yet somwhere between the communication is lost - needle in a haystack

Since its hobby I will keep pursuing this but slowly

I think you should focus more on the continuity testing, rather than resistance (to ground or to Vcc or whatever). Let's say one of the pins from the 82C206 shows 5Kohm to ground, but it is also connected to a chipset pin that maybe has 5Mohm to ground, in this case if you're testing near the CMOS you'll never know if the connection to the chipset is good or broken. (The above values are somewhat arbitrary, but you get the picture).

The datasheet/pinout of the chipset, if you can find it, will prove valuable for continuity testing. From what I remember, the data bus of the 82C206 is directly connected to the data bus of the KBC , it also might be directly connected to the chipset or there could be some 74F244/245 buffers/transceivers in-between. There is also a chip enable line from the chipset to the CMOS.

If the chipset datasheet cannot be found, you still have the advantage of having another working board, but there will be more work for you to draw a map of the connections from the CMOS to the chipset/KBC/ISA bus on the good board, and then comparing with the bad one.

I was looking at the theory how the signal gets to cmos. So it goes cpu - > north bridge - > south bridge - > cmos/bios (possibly through some invertors and buffers)

I started looking very closely at both chipsets (north and south bridges)

I noticed some green corrosion which camouflaged with the green pcb color between 2 resistor packs next to the south bridge (other side of motherboard where battery spilled)

Under the corrosion is a scotch mark between 2 points on 2 resistor packs. One pack has pins that interface with the south bridge.

Comparing both the motherboards the resistor still has the correct continuity to south bridge. However the 3 pins that connect to south bridge have a slightly lower resistance on the faulty board vs working
1.7 vs 1.9 other pins have exact same readings so going by the reading the lower resistance would suggest something is partially burnt/shorted.

I moved both the resistor packs from the good board to faulty, but no go. resistor packs are not faulty. This is pointing at the south bridge then I guess.

I will try to source a replacement... but defiantly won't be easy so this thread will be quiet for a while

Not sure how this happened, no way the battery acid jumped all the way to different end of the board, ill never know.