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 BIOS

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 work properly.

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 on!

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.

Applications

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).

Testing

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 procedure:
• 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

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!

Leap Year

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.

Conclusions

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 ||