I've been having some problems with my time/date clock on my IBM, 
hopefully someone here has some advice. Every so often, after the memory check
in my boot-up I get a message : Time/Date not set ... So I have to reset it
about once a day. I assume it's a problem with the clock battery or something.
Anyway, it's starting to annoy me and I'm sure there is a simple cure.

11 responses total.

Change the battery, see what that does. Though, assuming you've got some
config information also maintained by the battery, that would get wiped, too,
if it was the battery.
Ugh, that didn't make any sense.

I might try changing the battery but, it seems strange because the rest of the 
info : drive type, memory, etc. doesn't get lost. Anyway where can I get
another battery. I haven't looked inside yet - what kind of battery is it? 

Look it up in your docs, it's pretty much different from one to the next...

not all config info is battery backed - the old PCs weren't that sophisticated.
Change the battery. Before you do, copy as much of the setup information as
you can (drive type, etc). Otherwise you WILL forget.

Interesting.  The original PC and XT (8088 based) did their setup using
dip switches, & provided no battery clock by default.  If you wanted a
battery backed up clock, you had to acquire one of the many after-market
products, plus the software driver to teach the PC about it.  From the
AT onwards (286 and upwards), the a battery backed up CMOS clock chip is
used, and the setup information is stored in the "extra" RAM that the
particular chip IBM standardized on uses.  The meaning of all of the
bits depends (unfortunately) on the exact ROM bios you're using, and the
older ROM bios's don't provide any sort of setup service to change the
configuration.

I never understood why they just didn't use a good memory sizing
algorithm to count memory, put the disk type on some header block on the
drive, & other than that, performed some sort of general
"auto-configuration" process as part of bootup.  That way, there is no
redundant information to get trashed and render the machine
functionless, and if the hardware does get fried, the machine can still
boot up and function on what's left.  This isn't exactly a new idea --
Unix has been counting memory since its PDP-11 days, and BSD has been
performing device auto-configuration since 1979.  Even the lowly Atari
800 was capable of doing this sort of thing -- it autosizes memory, &
later polls the disk drives to determine number & type of drives, and
allocates buffer space accordingly.

The PC does count its memory automatically; however, for some strange reason
it also likes to have it stored in the CMOS.

PC's can't autoconfigure their floppy drives, because the system can't tell
the difference between 1.2MB 5.25" drives, 720K 3.5" drives, and 1.44MB
3.5" drives.  With Unix it doesn't matter, because you just use the proper
minor device number; with DOS, it does matter, because DOS has to figure
it out itself and use the right value without any help from the user.

I've never seen a PC rendered unbootable by the loss of config information,
anyway.  The setup program is usually on an EPROM and invoked on bootup
with a key sequence (DEL and Ctrl-Alt-Esc seem popular), and since the
machine can autosense the type of display adapter and memory size, you
can usually at least run setup to get the other information correct.

That's actually a fairly recent innovation.  With the PC & XT, if you
got the dip switches wrong, you were often screwed, & the only method of
recovering meant taking the case lid off, again.  With the AT, if you
got the CMOS config wrong, you had to run a special "setup" program,
which didn't come in the ROM bios, but on a floppy.  Fortunately (?),
there weren't quite so many kinds of indistinguishable floppy drives.
Just the 1.2M 5.25", and the 360K 5.25".  Oddly, the AT was actually
capable automaticaly sensing the difference between these two (if I
remember right), so the only information in the CMOS was the # of
drives.

Yes, the AT can tell the difference between 360K drives and "other"
drives, but unfortunately there's no way to tell the difference between
the different kinds of "other" drives.

Most newer PC's, at least, let you short out a jumper or connection on
the motherboard, or remove the on-board battery for a period of time,
to reset the CMOS to default values.  I don't know whether or not this
worked on the original AT.

I wish you would have written DOS 1.0 Marcus.  

Sometimes the clock will start to act up before the rest of the CMOS ROM 
loses it, as the battery voltage starts to taper off.  Some machines, in 
fact, will start to gain time as the battery wears out, often 2 or 3 
minutes a day.

The Atari wasn't the only machine to act that way.  The Apple ][-series 
used a similar method.  On startup, it'd check each slot, starting with 
slot 7 and going down the line, until it found a disk controller (usually 
in slot 6.)  I don't know how it figured the memory size -- jumper 
blocks, I think.

You don't need jumper blocks to find memory; you just need a half-way
decent memory test.  Actually, it can be disgustingly indecent.  I think
the Atari 800 just read, xor'd, wrote, xor'd, and rewrote the first byte
of each 256 byte block of RAM; this was enough to tell the difference
between DRAM, ROM, and nothing.  There were jumpers, of course, but they
weren't visible to the software or the user.  There was clever logic on
the memory cards and on the motherboard to deal with chip select logic;
so you could plug in up to 48K of memory, in 32K, 16K, and 8K
increments, so long as you put the larger memory in "first".

Adding memory to the apple II wasn't quite as nice; but as I recall, the
jumper blocks didn't select RAM size; they selected between 4k & 16k
DRAM chips.

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss