perry@piermont.com said:
>  Ralf Brown's Interrupt List gives no other use for that part of the
> CMOS, and I've not yet encountered machines that don't use it that
> way. Are we sure there are  somet that don't?

I've got the information primarily from the german c't magazine which has
a number of articles about y2k problems in its latest issue.
It explicitely states that "the century in the CMOS is not standardized".
As example only the PS/2 is given, but otoh this doesn't imply that
the PS/2 is the only exception.

But also R.Brown's CMOS.LST says:
==========
00h-0Eh is defined by the clock hardware and all must follow it. Other 
manufacturers generally follow the same format as specified for the
region 10h - 2Fh. Some also follow the IBM format for 30h-33h but not all 
(Zenith in particular is different).
==========
PS/2s store a checksum at 0x32 which would explain that writing
a century there rendered the whole configuration invalid if Michael's
PS/1 uses the same layout.

I'd propose to save the information whether the century byte
is 19 or 20 in inittodr() and change resettodr() to skip the
update if it wasn't. This still leaves a chance of 2/256 that
a checksum byte is stepped on, but is still a good improvement
for its price.
If someone fears that his machine will be among the 2 unlucky,
the update could be made a compile-time option (with default "on"),
preferrably implemented as patchable kernel variable.

Fyi, the c't lists how various OS's deal with the CMOS century byte:
-DOS, W31, W95: use BIOS
-Linux: ignored, user tool ("hwclock") provided to update the byte in CMOS
-FreeBSD: compile-time option, "off" by default
-W98: CMOS is updated "as long as BIOS anomalies don't prevent it"
-NT: "undisclosed" - the CMOS is updated on explicite time changes

best regards
Matthias