>From my memories of a Toshiba 1500 (a desktop Toshiba...erk), a basic XT
clone, and a real IBM PC original release - and some early reviews of the
PC-AT - the only "real-time clock" a PC had was in the form of an add-on
card...either built-in in the case of things like Amstrads or a real card in
most other cases. All of these had their own choices of I/O location, and
what clock-chip they used, and came with their own software to set the DOS
time to match the RTC time and set the RTC time.
MS-DOS always uses its own internal timers for the date/time, just on
startup it checks for an AT, and if it is one, it sets the date/time to the
AT RTC; regardless of date/time settings, if it doesn't find an AUTOEXEC.BAT
it will do a DATE and a TIME (and in later versions, set a PATH and PROMPT)
Some OEM's patched MS-DOS to treat the on-board clock in their XT's the same
way it'd treate an AT RTC - Amstrad did this for MS-DOS 3.2, and supplied a
patch for MS-DOS 3.3 to do the same thing.
>From an OS point of view, there is no RTC hardware in an XT, just the PIT
timers...the AT provided standardisation in this area.
----- Original Message -----
From: Dan Olson <[EMAIL PROTECTED]>
To: Jonathan Hall <[EMAIL PROTECTED]>
Cc: Mailing List <[EMAIL PROTECTED]>
Sent: Friday, June 25, 1999 4:39 PM
Subject: Re: 808x machines and Y2K?
> > All MS-DOS machines I've ever used ask for the date and time upon boot.
> > This includes all 808x machines I've ever used.
>
> My experience has been that any MS-DOS machine with no autoexec.bat will
> prompt you for the time and date, of course any machine without a battery
> powered clock will simply have the wrong date at power up, regardless of
> it prompting you or not.
> >
> > So, yes... they do have built-in clocks. They just don't have any
battery
> > to store the time and date.
>
> My assumption was that "clock" ment a battery backed real time clock,
> there are optional clock cards available for these machines, I thought the
> machines somehow calculated time by dividing CPU frequency, and that a
> true clock was an option.
> >
> > I imagine it would be more a software issue (OS issue) than a hardware
> > issue, though, whether or not they are y2k compliant.
>
> Either way, I'm sure it is, if the year isn't stored in hardware somehow,
> then software is all that's left to give you any trouble.
>
> Dan
>
> >
> >
> > On Thu, 24 Jun 1999, Dan Olson wrote:
> >
> > > > > Aren't most of the legacy systems going to have trouble Y2K? I
am very
> > > > > interested if you have a solution/answer because I have a ton of
> > > > > 8088-10/12MHz systems collecting dust. These systems may be not
heading
> > > > > to dumpster if there such a solution.
> > > > >
> > > >
> > > > I suspect the built in hardware clocks of these machines will not
survive
> > >
> > > Built in clock? I have a good dozen 8088s around, including the IBM
PC
> > > that I'm using right now, and I don't think any have a built in clock.
> > > They should all be 100% Y2K compliant because the only issue should be
> > > software, and if that ends up being a problem, I'll just find software
> > > that works.
> > >
> > > > the rollover, and may not work again afterwards, but assuming the
machines
> > > > can still boot after Y2K, ELKS does not rely on the CMOS clock. Any
method
> > >
> > > Still boot? I don't see how having the wrong date would affect
booting.
> > > If the machine booted when new in 1981, then I'll set the date to 1981
and
> > > it should operate as new :) The only issue that I know of would be
> > > programs getting the wrong date or weekday due to an incorrect year
being
> > > reported by the OS.
> > >
> > > > or querying a central server. You could even set the clocks back 10
years
> > > > deliberatly, and then configure ELKS to add 10 years to the time it
reads
> > > > from the hardware clock.
> > >
> > > There is actually an offset that will cause both the day of the week
and
> > > leap year to be correct. I don't recall the exact date, I want to say
> > > it's 27 years back, but that might not be correct.
> > >
> > > Dan
> > >
> >
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > Jonathan Hall * [EMAIL PROTECTED] * PGP public key available
> > Systems Admin, Future Internet Services; Goessel, KS * (316) 367-2487
> > http://www.futureks.net * PGP Key ID: FE 00 FD 51
> > -= Running Debian GNU/Linux 2.0, kernel 2.0.36 =-
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> >
> >
>
