|| WebHQ News
|| World News
|| Bios info
|| Windows Tools |||
|| Testing Tips
|| Diagnostic Tools
|| Help Desk
|| Home ||
Y2K - The Truth!
In case you're living on a desert island and thus haven't already heard
about the problem, the Year 2000 bug (Sometimes Called Y2K bug or Millennium
bug) is the suggestion that as soon as the year 2000 arrives, the majority
of the world's computers will go completely haywire, because they will
think it is "1900" not "2000". Some people would have you believe that
come 2000, disasters such as traffic lights failing, banks loosing all
your money, airplanes falling out of the sky, etc etc will befall
us. In truth, these stories are mostly just scare mongering and can mostly
be ignored. Clearly there will be some systems that have a problem come
2000, but the scale of the problem is grossly exaggerated by the otherwise
ignorant print and television media, not to mention the usuall assortment
of crackpots on the Internet.
There are those people out there who offer to charge you lots of money
to certify your computers as Year 2000 compatable. They're ripping you
off. This article will tell you how to test your machine for Y2K compatability
in as little as a few minutes.
The following text is an open and honest discussion of what the coming
of the Year 2000 will really have in store for IBM-PC (& compatibles)
owners. It focuses on the hardware side of the issues and totally debunks
many of the bold faced lies, mis-truths and errors that abound out there.
This text will be heavy going: it gets rather technical at times. Stick
with it... I will try to explain everything as I go, and try to keep from
straying too much! I will briefly touch on the operating system software
side of the problem, and mention in passing how application software may
be effected, however I will not concentrate on the software side of the
problem too much.
In the beginning...
The original hardware & BIOS design of the IBM PC AT is actually
100% Year 2000 compatible. Fact. Since every other 'clone' or enhancement
is backwards compatible with the IBM AT, by definition all clones much
also be Y2K compatible. Those clones that are not can simply be considered
incompatible "by design"... the number of truly incompatible machines is
VERY small!!! This fact alone immediately dismisses more than half the
arguments about Y2K compatibility.
There are many clones out there, however, that have problems in their
year 2000 support implementation. Here begins the technical discussion.
The RTC / CMOS chip
The IBM AT uses a Clock/Calander/RAM chip made by Motorola, the MC16848.
All date/time related operations can be traced back to this chip. This
RAM portion of this chip is used to store the computer's CMOS setup, and
the clock/calander section (hence referred to as the RTC) provides the
AT's clock/calander capabilities. The RTC continues to operate, even with
the computer's power off (It has a small battery to keep it running which
is normally built into the motherboard).
Please remember, however, that the CMOS RAM area and the RTC are two
independent functions of the same component... the proper operation of
the RTC is in no way effected by alterations of the RAM (and vice
versa).. They may as well be in separate physical chips because they have
ABSOLUTELY ZERO interaction with each other!!
IBM made a silly choice when designing the RTC.. they selected BCD as
the clock's operating mode (as opposed to 'normal' binary mode which would
have given a coverage of 256 years); as a result, the RTC only spans 100
years and only supports the two digit date system - 00 to 99. IBM could
have done better, but we are stuck with this system since changing it would
break basic IBM AT hardware compatability.
The system BIOS is responsible for interfacing between the operating
system, user applications and the actual RTC hardware. IBM forsaw the limitations
of the two digit date format of the RTC and added extra functionality to
the BIOS to convert the two digit dates stored by the RTC into 'normal'
four digit dates. IBM realized that somewhere they had to store an 'extra'
indicator of what century it was. This marker had to be saved even when
power was turned off; so the natural choice was to select a byte of the
CMOS memory to hold the century indicator. In the IBM AT and most
"clones" the century is stored in CMOS location 32h.
Every BIOS should read the century indicator whenever it calculates
the date; by taking the century byte into account, the BIOS always derives
the correct four digit date. The problem is that IBM didn't make it clear
when or how to determine that the century byte needs updating, or how to
actually go about doing so. (Remember that the century byte is part of
the CMOS and is not automatically updated by the RTC... it is left
to the BIOS to perform the update). As a result, BIOS manufacturers have
come up with several methods for handling the century byte problem; many
less successful than others.
BIOS Y2K handling & BIOS bugs
Most current modern BIOS's made in the last 1-2 years correctly recognize
when the century 'rolls-over' and immediately update the century
byte. These BIOS's have no problems what so ever, and all programs work
perfectly with no user intervention.
Many older BIOS's fail to recognize the 'instant' that the century rolls
over; therefore they do not update the CMOS century setting immediately.
This means that the BIOS will begin reporting 'incorrect' four digit dates
immediately after a century roll-over. Any program that asks the BIOS (or
directly access the RTC & CMOS) WILL get an incorrect date. On this
type of system, usually all that is required is a re-boot. During the reboot
the BIOS recognizes that the century byte is "19", yet the RTC's year is
less than it's year of manufacture (198x or 199x) .. it deduces from this
that a century roll-over has occurred and updates it's century byte to
"20". From that point on, the BIOS has the correct time and all applications
A very small number of BIOS's (about 5%) READ the century byte when
calculating the date; they just never update the century byte at all! You
can try manually forcing this type of BIOS to update the century byte by
entering the CMOS setup and manually setting the RTC to 20xx. This normally
fixes this type of BIOS permanently; from that point on, the BIOS has the
correct time and all applications work properly.
Very few older BIOS's (less than 1%) ignore or don't implement the century
byte. On these systems the BIOS can be considered faulty by design -- the
designers simply didn't follow IBM's conventions. In this case, you must
resort to throwing away the motherboard for one that fits one of the other
above mentioned categories.I have heard rumors of one NEC BIOS that crashes
when the year 2000 rollover happens. All that's required is a reboot and
it comes good, operating correctly in the year 2000. Clearly this is a
specific bug in this particular BIOS. I have never seen this bug personally,
so I can't do but mention it for the informative value "as is".
MS-DOS, Windows 3, etc.
All Microsoft Operating Systems have always been Year 2000 compatible.
These OS's have their date restrictions (DOS / FAT filing system has problems
at around 2068 or so) but Y2K isn't one of them. DOS/Windows 3 actually
maintains it's own 'software' clock. Once the RTC is read at boot time,
it is IGNORED after that. If you only use applications that get their date
info from DOS (as opposed to getting it from the BIOS or the hardware directly)
you can actually continue to use a non-Y2K compatible PC - just set the
date each time you boot up, before running your date sensitive applications.
Just type in DATE at the DOS prompt, input the correct date and continue
There are minor issues with some programs - for example the full
4 digits must be used when setting the date using DOS's DATE function after
1999 (2 digit date entry presumes "19" for the century). These issues are
really trivial, and don't take more than about 5 seconds to learn.
Every application stores it's date in a format chosen by the author
of the program. You should check with the author of the package to find
out if it's Y2K compatible or not. Remember that even though you have an
application that isn't Y2K compatible, that doesn't mean that the underlying
computer hardware must also be incompatible!!! (and vice versa).
So, how do I prepare for the coming of the year 2000? It's dead easy!
Test your system today and find out. There are expensive (and free) Y2K
testers out there, but it's much easier than all that. Just follow this
- 1. Back up everything (just in case).
- 2. Set your computer's date & time to December 31, 1999, 23:59:00.
- 3. power off, wait two minutes, power on again.
- 4. Test everything! Thoroughly! See that the system thinks the year
is 2000 and that all applications do too.
- 5. Restore the 'proper' date and time.
- 6. If you think your data is trashed, restore it from your backups.
I'm sure that in 95% of cases you'll find absolutely zero ill effects.
If your machine thinks it's 1900, enter the CMOS setup and force the date
to 2000. If the machine STILL thinks it's 1900, you'll need to update the
machine by getting a Y2K compatible BIOS, changing to a Y2K compatible
motherboard or buying a new machine.
If the system recognizes that it's 2000, yet a software package thinks
it's 1900, get in contact with the software's authors and demand they fix
what is their problem!
Windows NT 4.0 service pack 3 & Windows NT 3.51 service pack 5 contain
code to automatically correct the RTC of a faulty M/B in the event that
it doesn't transition to 2000 correctly. Those running this software should
simply leave the computer on during the 2000 transition and NT will do
all the hard work!
A reader recently asked me to comment on the leap-year associations
with Y2K. Here is the real story: 2000 *IS* a leap year; therefore after
February 28, 2000 should come February 29, 2000 (not March 1, 2000). Again,
the RTC's internal design controls this, and the MC16818 *DOES* correctly
handle the leap-year, so most PC's will operate correctly. Some 'clone'
chipsets may fail to copy the MC16848's operation properly, and thus ot
roll over to the correct day; however the number of systems failing this
check will be minutely small (only those systems built around the bad chipset).
This fault has *NOTHING WHAT SO EVER* to do with Y2K problems - it is
simply more mis-used fuel for the Y2K scare campaign! Many Y2K testers
now also check this rollover as well as the Y2K rolover, however I've never
seen a PC that fails it (And I've tested quite a few hundred now). If by
chance you do have a PC that fails this check (use the same test as above,
but substitute Feb 28, 2000 as the date in step 2, and check that the date
is Feb 29, 2000 in step 4), the solution would simply to set the date manually
that day. Again, this is a once-only problem - not something that
will have an ongoing effect.
Many current Pentium Class machines will continue to run throughout
the change over to 2000 without a hitch. Many older PC's will simply need
to be re-booted, or at the worst the CMOS setup will need to be entered
and manually set to 2000. No matter what option is required, these changes
will only take a few minutes, and will be so trivial as to be forgotten
almost immediately -- remember, this only needs to be done once ever..
the year 2000 only rolls over once, after all. For the very small number
of machines that truly cannot cope with the year 2000, they will
need replacing. The good news is these machines can be tested today, and
planned for upgrading or replacement in plenty of time.
Application software may need updating (operating systems probably won't).
Again, this can be purchased from the authors of the package in plenty
of time. Some users running packages no longer supported may have to consider
an investment in a current product.
No matter what happens, the year 2000 will come and go for most PC Users
with hardly a whimper. Be happy!
|| TOP ||