I'm trying to answer your posts all in a single message. In the absense 
of some explanation on your part, I'm moving this reply _back_ into the 
[OS2PROG] conference from where the thread originated. If you wish to 
move the discussion into another conference it is customary on FidoNet 
to include a brief explanation at the head of the message for the 
benefit of the echo participants.


JDBP> Very few hardware manufacturers have produced "PC-compatible" RTCs
JDBP> with proper century registers, which is, of course, the correct
JDBP> way to solve the problem.

Agree 100% with that!


JDBP> Some have, though.
JDBP> 
JDBP> According to its data sheet (which is, alas, short on details),
JDBP> the AMD 645 peripheral bus controller, which is one of those all-
JDBP> in-one "South Bridge" chips, implements a proper century register
JDBP> at location 0x7F in NVRAM.

7Fh?! Well, that certainly doesn't fall into _my_ definition of "PC-
Compatible".


JDBP> If AMD were simply saying that "by convention, the century byte is
JDBP> stored here", one would expect it not to be at location 0x7F, but
JDBP> at one of the locations (such as 0x32) where the century byte *is*
JDBP> conventionally stored.

Well... I've _heard_ of CMOS' which store their century byte (and other 
information) at a location other than 32h (or other than conventional), 
but I've never actually seen one, nor documentation on one. At what 
other "conventional" locations can the century byte be found?


JDBP> IM> Very, very sad. DOS is good until 2099.
JDBP> 
JDBP> If you discount those portions of DOS written in the C language,
JDBP> which will break in 2038;

Uh... well I suppose that's good theory, but how many portions of DOS 
suffer from that limitation? DOS (the versions which I've had here) 
correctly reports dates up to 31 December 2099, and correctly creates 
and reports file dates up to the same date. It would seem to me, 
therefore, that there are precious few "portions of DOs written in the C 
language" which actually suffer from this shortcoming of the C language.


JDBP> and if you discount the fact that most modern BIOSes will
JDBP> implement the same windowing fix as the OS/2 CLOCK01.SYS device
JDBP> driver does, meaning that the year 2079 limitation will be applied
JDBP> before DOS even gets a look-in.

Possibly, although I don't think you've enough of a sample to properly 
justify that "most modern BIOSes will". [:)


JDBP> IM> The RTC/CMOS itself is good up to the year 9999.
JDBP> 
JDBP> I disagree.

Can't say I'm surprised. [:)


JDBP>  Since the RTC doesn't have a century register, the RTC
JDBP> is really only "good" up until the year 99.

I think you're just being argumentative here. You're obviously a very 
highly educated person and I did say "RTC/CMOS". I'm certain you knew 
exactly what I meant. [:)


JDBP> If it doesn't properly increment a century register when the year
JDBP> number wraps from 99 to 00, because it doesn't *have* one, that
JDBP> doesn't qualify as "good" in my book.

You're certain free and welcome to write whatever you please in your 
book, but this simply sounds like the logic of the argumentative.

I reiterate, the design is such that it was understood that the RTC did 
not have a century byte. The century byte was provided in CMOS to be set 
by the "user". Each byte has a range of 00 to 99 BCD. Ergo, the RTC/CMOS 
is good until the the year 9999. Claiming otherwise, simply because the 
RTC by itself doesn't actually have control of the _existing_ century 
byte, simply ignores the existing facts and is simply being contrary for 
the sake of contrariness itself. 


JDBP> It's also worth noting that there isn't a standard place for the
JDBP> byte holding the century.

I disagree. (This _is_ Fight-O-Net, after all! [;) Since I've never seen 
a CMOS which didn't store it's century byte at 32h, I don't believe it's 
worth noting at all. It's a dubious fact which seems to have little to 
do with the discussion other than to introduce FUD. My experience is 
that the century byte is always stored at 32h. This may not be a de jure 
standard, but since it is followed so widely I think that we can call it 
a de facto standard.

IMO, of course. I've been repairing and upgrading clones professionally 
since about 1990.

I understand that there are proprietary pseudo-clones which may store 
their CMOS information in a format different from the de facto 
"standard", but these machines are notorious for not working with off-
the-shelf versions of DOS, and typically come with their own customized 
versions of DOS, Windows, or whatever operating system with which they 
ship.


JDBP> Because of this, the APCI standard, for example, provides a
JDBP> mechanism by which BIOSes can tell operating systems where the
JDBP> century byte is actually located in NVRAM.

I'm not familiar with this standard. Can you elaborate? Who is APCI? I'd 
support a standard such as this.


JDBP> IM> Too bad that IBM felt that they had to break that.
JDBP> 
JDBP> IBM *didn't* break it, though. The RTC design was already broken,
JDBP> inasmuch as it wasn't suitable for use as the RTC chip in a
JDBP> personal computer design that was to last for at least two
JDBP> decades. IBM didn't break the RTC design at all.

In your opinion.

More pedantism. The design worked as intended before the abortion and 
would allow a user to set any date up until the year 9999. Now the user 
is artificially and unnecessarily hobbled to 2079. I think that you and 
I have differing definitions of "break" as used in this context. Or as I 
said at the beginning of this discussion, perhaps you've suddenly 
developed a very flexible definition of "break". [;)


JDBP> It was an off the shelf part that was already designed that way.
JDBP> IBM *could* have picked another chip, from some other
JDBP> manufacturer, which *did* have a century register.

Well, I asked you this before, but please name such a chip which was 
_readily_ available in 1984.


JDBP> Indeed IBM, being IBM, could have manufactured such a chip itself
JDBP> if no such chip were available from a third party.

Non sequitur. That does not fit the historical facts as we know them. I 
wasn't into clones at the time and was a little young to even be 
employed by IBM, but it seems pretty obvious that the design philosophy, 
for whatever reason, was to use off-the-shelf components. It's all well 
and good, sitting up here at the end of 1999 after seeing the PS/2's, 
Blue Lightnings, PS/1's, etc., to cite what IBM _could_ have custom 
manufactured, but really all that matters is what their philosophy was 
for PC design _at the time_. And at the time we know that the philosophy 
was not to redesign anything, but to use off-the-shelf components.


JDBP> IBM didn't break anything. The design was already broken, in that
JDBP> it *wasn't* good up until the year 9999, but only up until the
JDBP> year 99. What IBM did was to choose poorly.

Again, this is all just argumentative. You're doing a lot of fast 
talking to justify your position in this discussion, a position which 
may or may not be your actual point of view or belief.

Take care and TTYL.

---
 þþ Very funny Scotty -- now beam down my clothes!                        

--- AdeptXBBS v1.11y (FREEWare/2)
382/92