• Please review our updated Terms and Rules here

Vintage Laptop Fault - PhoenixBIOS CPU Detection failure, Real Time Clock Error, bootlooping

3lectr1c

Veteran Member
Joined
Nov 28, 2022
Messages
1,218
Location
USA
I'm writing this in order to help get ideas on what could be causing a failure on multiple vintage laptops I've run into.
The issue goes like this:

On a cold boot (off for a day or so), the laptop will usually work just fine. If it's been on for more than a few minutes, if the laptop is rebooted, it will do the following:
- CPU fails to detect properly and will show the type as incorrect "386" or "Overdrive" or "???" when "Pentium" is correct, and/or show the clock speed as incorrect or "???"
- BIOS throws a "Real Time Clock Error"
- Entering into BIOS will show the time and date being displayed as garbage characters that cycle in and out with more garbage, and time/date cannot be set
- Laptop will eventually get stuck in a reset loop while trying to pass POST, usually locking up and resetting when it hits "Real Time Clock Error"

This is all very inconsistent and sometimes certain failure modes happen while others don't.
To be clear, "Real time clock error" in this case is indicating a failure of the real time clock, not a bad CMOS battery. On successful boots, this error will not display.

I first encountered this issue on not one but two Alpha-Top Green751 laptop motherboards. These are generic/white-label Pentium 1 laptops: https://macdat.net/pc/alphatop/green751_home.html
On one of the two boards with the issue, I replaced the RTC crystal and the RTC chip itself, neither of which corrected the problem.
I figured this was an issue isolated to this model, until another person with an AST Ascentia M Series laptop had a very similar problem. Said laptop was wrecked and had more or less been stored outside for over a decade. Despite this, the motherboard survived and it posted first try. Like some laptops do, it could not save BIOS settings at all (even over a reboot, so he couldn't get it to save HDD info) without a working CMOS battery, so he replaced the battery. After this, the laptop kept date and time but would still not save any BIOS settings. He also noticed that while it saved date and time (even when the laptop was unplugged), time would not tick forward at all. On multiple occasions, the CPU stopped reporting correctly as described earlier.

Then, today the third case showed up. This time it was a CTX EzBook 700, which is a Pentium 1 laptop from 1996. This one displayed the EXACT same symptoms as the Alpha-Top, down to the T. Completely identical, no notes needed.

The only common factors here are that all three laptops use PhoenixBIOS. Both my laptops have had the CMOS batteries removed, while the AST owned by someone else has a working CMOS battery. The Alpha-Top used a VARTA NiMH CMOS battery, and the CTX used a VL1220 Lithium battery. Both of my laptops had the battery soldered, and I think the AST also did (might be wrong).

The next thing obviously to try would be installing a new battery on the CTX and/or the Alpha-Top and seeing what happens. The type of failure though doesn't seem consistent with a laptop needing a working CMOS battery, I'd expect a different type of failure in such a case. I also can't prove the RTC chip and crystal (harvested from a third alpha-top parts board) were good, but I feel like the chances of all three being bad are incredibly low.

So my question - if it isn't the RTC chip or the crystal, what is it?
 
On a cold boot (off for a day or so), the laptop will usually work just fine. If it's been on for more than a few minutes, if the laptop is rebooted, it will do the following:
Suggesting heat sensitivity. Badly deteriorated thermal past between CPU and its heatsink, resulting in the CPU overheating ?
 
Heat may indeed play a role. Both laptops run very hot, for sure. They're both using desktop chips in a laptop (although the Green751 is a supposed lower-voltage "mobile" version, but both are socket 7), and neither have fans, just passive cooling via a heatpipe.

The Alpha-Top is especially bad in this regard, as its heatsink is bent and doesn't fit right. I might have solved this now, but I know it wasn't making proper contact for a while. The CTX definitely was making proper contact but still got hot as hell, both do inside after running for a few minutes.

I'm not sure it's the cause though - particularly because of the inconsistent nature of the issue. Sometimes, the Alpha-Top will have been off for a week, then will present the issue right on first cold-boot. I'll repaste the CTX though, it has some nasty old thermal pad on it now. So does the Alpha-Top but I'm nearly certain it's not heat on that one based on what I said a couple sentences back.

Oh, and also - on a successful boot, the Alpha-Top can run for an hour/indefinitely and never locks up or crashes. If it gets passed BIOS with the CPU properly detected as a Pentium 75, it will run as long as I don't reboot it. The real time clock still doesn't work right in Windows though.
 
Someone in a discord server told me the glitchy date and time (at the very least) is a problem he's run across before with PhoneixBIOS and that those need a good CMOS battery. I do hope that fixes it!
 
After this, the laptop kept date and time but would still not save any BIOS settings. He also noticed that while it saved date and time (even when the laptop was unplugged), time would not tick forward at all.
That is a very good indication that the battery voltage is too low.

Generally, always make sure both the CMOS and RTC are *fully* working before doing any trouble shooting. Most people seem not to be aware of all the weird issues that can randomly appear when either the CMOS or the RTC is not working. These components are simply mandatory for any AT-class machine to work correctly.
 
I have now installed a working battery in the Alpha-Top and the RTC still isn’t working. It worked for a while, but now fails to advance time again. Jury is still out on whether it’s going to stop detecting the CPU properly.
 
For the CTX, I’ve noticed it intermittently will throw a beep error on POST that translates to a CMOS RAM read/write failure. So that one perhaps has an issue with the CMOS RAM. Could it be corrected with a new CMOS battery? I’ll find out at some point in the future.
What I do know is that for some reason, that CTX was parted out, probably around 20 years ago. It had broken plastics, but perhaps the motherboard in it had that problem then and that’s why. Hard to say.

I did more probing on the Alpha-Top, and the RTC chip is getting VCC (5V) and it’s getting voltage in from the battery (3.6v), so it’s not an issue with it not receiving power. The laptop is also holding CMOS settings now (such as the hard drive parameters), it just doesn’t have a working RTC. The next thing to try might be to source a brand new RTC chip and crystal (rather than one harvested from another old board which I’ve already tried).
The Alpha-Top still hasn’t failed to detect the CPU since installing the battery.
 
I did more probing on the Alpha-Top, and the RTC chip is getting VCC (5V) and it’s getting voltage in from the battery (3.6v), so it’s not an issue with it not receiving power.
So you measured 3.6V on the pin of the RTC chip.
And presumably, you know from the datasheet of the RTC chip, that 3.6V is above the minimum spec.

The laptop is also holding CMOS settings now (such as the hard drive parameters), it just doesn’t have a working RTC.
The clock inside an RTC chip is normally 'ticked' by an external clock.
As an example, the diagram at [here] shows that the RTC chip within an IBM AT (IBM 5170) receives a 32.768 kHz clock signal.

If the RTC clock (different to the DOS clock) does not advance, even with the computer powered on, then the presence of the 32.768 kHz clock signal is something to look for.

If the RTC clock advances as expected when the computer is powered on, but stops or loses time when the computer is off, that is 'classic' of low battery voltage (causing the 32.768 kHz oscillator to become intermittent, and then eventually stop).
 
And presumably, you know from the datasheet of the RTC chip, that 3.6V is above the minimum spec
3.6V is the rated voltage of the CMOS battery the laptop shipped with, so I’d presume it is correct for the RTC chip the laptop uses.

There is a clock crystal that I can trace and tone out that goes directly into the RTC chip. This should be the 32.768 kHz oscillator. I do not have an oscilloscope so I cannot verify if it is working. What I have done is replaced it with the crystal from one of my parts boards.
I have three motherboards for this Alpha-Top Green751 laptop, and only one I have working in the current state. My second board had the same issue with the RTC that board #1 has, but it stopped powering on, so I cannot test with it further. The third board is in unknown condition as it is missing the power jack and has broken pins on the chipset IC.
The RTC chip and crystal that are currently on board #1 came from that 3rd parts board.
So point being - unless all three boards had bad RTC chips and/or crystals, that really shouldn’t be the problem.
Without a scope though, all I can really do to 100000% rule that out is to buy a new crystal and install it. That way it’s known-good.


What I can say is that installing an RTC battery corrected the CPU detection issue and the bootlooping problem. I had it running for hours today and it passed post every single time with the correct CPU identified. The RTC of course was still not working.
 
... is to buy a new crystal and install it. That way it’s known-good.
Although, be careful there. If a crystal, as distinct from an oscillator module (some people call them crystals), note that some IC datasheets are specific about certain crystal properties, shunt capacitance being a common property that I see.
 
I’ll check the data sheet again and note any special requirements. If there something I’m unsure on, I’ll let you know here.
 
If the RTC clock advances as expected when the computer is powered on, but stops or loses time when the computer is off, that is 'classic' of low battery voltage (causing the 32.768 kHz oscillator to become intermittent, and then eventually stop).
If someone with a PS/2 is reading this, note that for some PS/2 models, use of DASDDRVR.SYS might be the answer.
See [here].
I remember experiencing 'RTC does not advance at all when the computer is off' on some PS/2 model 50's, and DASDDRVR.SYS was the fix.
 
Back
Top