Knackered CMOS/clock chip?

I recently sold a spare RISC PC to a friend and naturally I am his after-sales support. :) After he changed the battery and cleaned up the mess left by the old battery it eventually runs fine and keeps it’s configuration. The only thing is: It forgets it’s time setting and resets on every cold start to the rather odd date of 1st Jan 2020. Now I am at the end of my wisdom as well. Is the chip broken or can this behavior be triggered by a dead track on the mainboard due to battery acid?

If you can find it, check the comp.sys.acorn FAQ. I dimly/vaguely remember something about the RTC getting “stuck” if the battery runs out.

This?

REM poke RTC control register
REM  Bit   0         1
REM   7   Count  ResetDivider
REM   6   Count  HoldLastCount
REM write 0 for normal operation, write &80 or &40 freezes RTC
DIM cmosdata% 16
!cmosdata%=&00000000
REM write 0 twice to RTC, first 0 is address- control reg
REM second is control reg value 0 is default i.e. clock on
SYS &240, &A0, cmosdata%,2
END

Relaying that to my friend, thanks in advance!

If you can find it, check the comp.sys.acorn FAQ. I dimly/vaguely remember something about the RTC getting “stuck” if the battery runs out.

It can happen, but is fairly rare. That exhibits as the clock still showing the date/time as when you last set it, though (ie. the clock doesn’t ‘tick’).

The date resetting to 1st Jan usually means that the clock chip itself is failing. If there was track damage so the clock chip wasn’t readable then you’d get a POST test message (flashed on the floppy drive light) on start up to show “CMOS unreadable”.

It’s possible to remove and replace the clock chip if you’re handy with a soldering iron, and the board hasn’t got any damage, or you can fit a clock podule (available from CJE) to a spare slot on the backplane.

CJE is across this sort of thing, http://www.cjemicros.co.uk/micros/products/rtc.shtml

No change after running the RTC fix program and doing a cold start. CMOS happily remembers the configuration, clock insists on starting in the year 2020. Starting with without running !Boot yield the same result, so nothing in the boot sequence can be blamed for fiddling with time.

Sounds very much like a (partially) failed CMOS chip then.

For completeness and information I have found an explanation of what the BASIC RTC poke prog above was specifically for.

http://www.riscos.org/csafaq/part3.html#3_4

It does not fix broken hardware.

I’d agree with Andrew, a dead track seems unlikely if it is keeping the settings. All the communication goes through the same two wires. Pins 5 and 6, you can continuity check them to a pair or resisters at the other end of the ram socket. Pins 1 & 2 go to the crystal, 3 & 4 ground. Then, if you have at least 1.2v between 4 & 8 when it’s switched off, you can be fairly happy the battery and all connections are good.
I my experience those chips don’t like being leaked on though, so you are probably looking at a faulty chip by now. To concur with others, you can get a new 8583 on eBay if you have the tools to fit it. Or… CJE is an easier route.

Hi….I think the RTC chip turning sour is incredibly far-fetched dependent on your depiction. I’d state it’s most likely Windows. I’ve been utilizing various and totally different OS on one machine (98SE and Freesco) and I’ve seen some seriously sunk up clock 98 after it was stacked after Freesco was running and changing the clock utilizing nntp.org.

Would you be able to set the check in the BIOS arrangement, and afterward do a clean introduce of 7?

I’d state it’s most likely Windows. I’ve been utilizing various and totally different OS on one machine (98SE and Freesco) and I’ve seen some seriously sunk up clock 98 after it was stacked after Freesco was running and changing the clock utilizing nntp.org.

MS went through several variations of how to deal with UTC +/- and daylight saving vs no daylight saving, which varied from bad to bloody awful. Freesco would be using the normal rest-of-the-computing-world standard, while certain Windows installs could happily give you two different time values depending on whether it was a GUI or command line query.
In the other part – RTC chips in the RPCEmu have been noted to die.

while certain Windows installs could happily give you two different time values

I wrote a little tool (in VB5) that scanned a directory (and subdirectories) and reported changes so I’d know what to upload to my site. It might have made up a tar file too, I don’t remember.

Anyway, it needed “special code” to deal with the fact that 98SE (and the Win32 flavours) handled daylight saving completely differently to XP. So it’s nice that there wasn’t even any consistency in getting it wrong. ;-)

Somewhere around the VMS3 or 4 era summertime adjustment meant altering the clock – not altering the way it is displayed. So in the Spring the clock jumped forward by an hour – done manually at the command line of course. Not a big problem. The problem occurred one day when I returned to work 8:30 on Monday morning in the autumn and put the clock back an hour. The first shift started on the line at 6am, and nobody could enter a transaction on the logging system from 8:30 to 9:30 because it wouldn’t accept a next step with an earlier timestamp than the previous step.

So thank goodness we now only alter the way time is displayed, and let the clocks go on increasing monotonically.