Y2KURE Automatic CMOS RTC and BIOS Year 2000 Correction

• Introduction: Installing after 12-31-1999.
• Description of Y2Kure.
• Background.
• Problem #1 - Century Rollover With Power Off.
  • The Simple Solution.
  • The Y2Kure Solution.
• Problem #2 - Century Rollover While Running.
  • The Y2Kure Solution.
• Problem #3 - The Award BIOS v4.50 Problem.
  • The Y2Kure Solution.
• How to use Y2Kure.
• Special Y2Kure Features.
  • Forcing the Mode.
  • Forcing Installation.
  • Message Delays.
• Custom or Multiple Installations.
• Leap Year Loonies.
• Crouch-Echlin "Time Dilation".
• Older DOS Versions.
• IMPORTANT NOTE: CMOS Setup Utility.

INTRODUCTION - INSTALLING AFTER 12-31-1999:

HOWEVER, if the system has the defective Award v5.10 BIOS, there will be a problem. That BIOS won't allow any year after 1999 to be set, so the first time Y2Kure runs it will see an erroneous date (1994) as the current date. It will do a reboot test and detect the defective BIOS, and it will install a special driver to handle date requests from the system. But it will still think the current date is 1994.

In that case, you will need to use the included DATE-Y2K utility to set the proper date. (See the complete discussion of the Award BIOS problem and Y2Kure solution for an explanation of why DATE-Y2K is needed. Basically, it's needed for date changes of more than 4 years when the "defective BIOS" driver is used.)

Alternatively, if you already know or suspect that the system has a defective BIOS, you can set the date to 1999 before installing Y2Kure. Even the defective BIOS can handle that, and after Y2Kure runs on the next reboot, you can use the normal Windows or DOS DATE utilities to set the proper date.

Regardless of which of the above approaches you use, the normal Windows or DOS DATE utilities will work fine for routine date changes. You will only need DATE-Y2K for large (multi-year) changes.

DESCRIPTION of Y2KURE:

Y2Kure is being made available free of charge, as a public service of Interstellar Research. You are free to distribute the complete Y2KURE.ZIP file as long as it is not modified in any way, and no fee is charged.

Unlike other Y2K "fixes", Y2Kure does not require you to run any special test program first... you can just "set it and forget it" and it will do the rest. The first time you boot, it will perform a quick reboot test and determine the proper driver mode for your system. After that, your system will maintain the correct date through 2099. If Y2Kure finds that no driver is needed, it will not install one unless forced via the /I parameter.

If you are responsible for multiple computers that can't all be relied upon to have their system clocks updated by a network log-in, you will find Y2Kure to be a quick, sure, and safe solution.

NOTE, however, that Y2Kure only cures RTC and BIOS problems, insuring that your system always knows the correct date. It does not attempt to deal with dates stored as data in various applications, or the display of file dates in directory listings.

BACKGROUND:

The original IBM PC and XT had only the system timer, which was derived from a fairly accurate crystal oscillator running at 14.31818 MHz. This was divided by 3 to get a 4.77 MHz clock for the 8088 CPU, while a further division by 4 gave a 1.19318 MHz source for the 8253 or 8254 system timer chip.

For compatibility, the 1.19318 MHz system timer frequency has been maintained in all subsequent PC models and clones. The timer chip generates an interrupt after counting each 65536 pulses, which works out to about 18.2 interrupts or "ticks" per second.

The interrupt allows DOS to count these ticks, and it uses the count value to maintain the current time and date... assuming they have been set correctly at boot-up. The PC and XT required this to be done manually, since when the system was off there was no way to keep track of the time and date.

Beginning with the 80286-powered AT model, IBM added a battery- backed CMOS Real-Time Clock (RTC) and memory chip. This is essentially like a digital wristwatch with a date function, plus a small amount of general-purpose memory on the same chip. The CMOS memory holds critical setup information that the PC needs at start-up, before it can access the hard drive.

When the system starts, the RTC is read and the values are used to set the initial time and date into DOS. This is carried out by the BIOS (Basic Input-Output System), which is a collection of "firmware" routines resident in ROM (Read-Only Memory). The BIOS is typically a permanent part of the system, though some newer systems allow it to be upgraded via special software.

The date section of the RTC chip only updates a 2-digit year, which will roll from 99 to 00 at the end of the century. Century information is not part of the RTC; it's just a separate memory location on the chip that is normally set to 19, and will need to be set to 20. The RTC does not update this on present systems, although this feature may be available soon.

On most BIOSes older than a year or two, the RTC year and century are read and passed to DOS as-is, so when the year rolls from 99 to 00, the date given to DOS is 1900. Newer BIOSes read the 2-digit year, and if this is 00 to 79 then they set the century digits to 20; if it is 80 to 99, they leave the century digits unchanged. The correct date is thus passed to DOS, and the BIOS may also update the RTC so that future readings will have the correct century without needing this "pivot" at 1980.

PROBLEM #1 - CENTURY ROLLOVER WITH POWER OFF:

If you do nothing before the following session, the BIOS will again report a date in the early 1900s and DOS will again set the same default date of 1-4-1980 when it starts. Now there will be no way to tell older files from newer ones, even manually, since they will all have the same date. This will wreak further havoc with backup procedures.

THE SIMPLE SOLUTION:

THE Y2KURE SOLUTION:

PROBLEM #2 - CENTURY ROLLOVER WHILE RUNNING:

But some DOS programs like Daqarta disable the system timer interrupts for prolonged periods, to keep them from interfering with critical tasks like real-time data acquisition. (Older DOS games may also disable the timer for performance reasons.) This causes the DOS clock to stop, so when timer interrupts are later enabled after the critical task, the program must read the correct time and date from the RTC (via the BIOS) and use it to reset the DOS clock. If the century has been crossed in the meantime, the BIOS will yield "1900" and DOS will reset to 1980.

Note that this problem is only possible with DOS programs (including games) that run in "real mode". Windows applications always run in "protected mode", which prevents them from shutting off the timer interrupts. (Of course, the vast majority of applications have no need to shut of the timer interrupts anyway.)

Even DOS programs that are run from the "MS-DOS Prompt" are still in protected mode. There are only three basic ways for software to run in real mode:

• Boot to DOS directly, instead of to Windows.
• Use the "Restart in MS-DOS Mode" option from Windows 9x, or end your Windows 3.x session.
• Use a Windows 9x shortcut or launcher that runs a real-mode DOS application.

THE Y2KURE SOLUTION:

Essentially, Y2Kure just gives an old BIOS the same functions as a state-of-the-art new one.

PROBLEM #3 - THE AWARD BIOS v4.50 PROBLEM:

Since the true date is destroyed before before DOS loads any corrective driver (via CONFIG.SYS) that could read the RTC, this problem is widely acknowledged to be impossible to solve with software. Users are typically advised to purchase special BIOS update modules, or even to replace the whole computer.

THE Y2KURE SOLUTION:

If the BIOS won't allow the RTC to retain the proper date, then Y2Kure operates in a special "Failed BIOS" mode that uses only allowable dates. For these systems, Y2Kure sets a BIOS/RTC date in the range 1995 to 1998, and saves an "offset" amount that must be added to get the true year. Here are some examples:

  True Year =  RTC Year   +   Offset
    1999        1995            4
    2000        1996            4
    2001        1997            4
    2002        1998            4
    2003        1995            8
    2004        1996            8
    2005        1997            8
    2006        1998            8
    2007        1995            12
    ...          ...            ...
    2099        1995            104

Each time Y2KURE.SYS runs at boot time, it computes the true date from the RTC date plus the offset. It saves the true boot date as the file date of Y2KURE.DAT, a special 0-byte file in your root directory. From this date, it can determine the correct year offset at the next boot.

Note that this scheme only works if the system is turned on at least once every year or so. In the worst case, if the system is shut down in 2002 (for example), the RTC holds 1998. When 2003 arrives, the RTC will roll to 1999... still no problem, since Y2Kure can deal with that. (It just resets the RTC year to 1995 and sets the offset from 4 to 8. 1995 + 8 = 2003.)

But if the system stays off until 2004, then the RTC will roll to 1900 and the defective BIOS will reset the RTC (typically to 1994) on boot. Y2Kure will then detect that the date is not in the proper 1995-1998 range that it expects, and will alert you to reset the date manually. It can't perform an automatic correction, since the RTC year is destroyed by the defective BIOS... the true year might have been 2004, or any year beyond that, but the BIOS always resets to 1994.

That's the worst case, which only happens at the high end of each 4-year window. However, if you shut the system off in 1999 (when the RTC holds only 1995), you could leave it off until any date in 2003 without problems.

Note that the "Failed BIOS" Offset driver remains resident during operation, to handle the case detailed under Problem #2 above: If any application requests the date from the BIOS / RTC, the driver intervenes and supplies the correct date by adding the offset value to the RTC year.

There is only one small price to pay in exchange for not having to buy a replacement BIOS or a whole new system: If you want to manually change the year, such as to fool certain date-sensitive applications, the normal DOS or Windows date functions won't work if the change crosses a 4-year offset boundary (such as from 2002 to 2003, or 2006 to 2007). For that, you will need the supplied DATE-Y2K utility.

That's because the new date must be stored to Y2KURE.DAT so that the proper offset can be loaded into the driver at the next boot. But since DOS is not "re-entrant", the Y2Kure driver can't use DOS file access operations during the DOS date functions. (This is technically possible via circuitous means, but those could compromise the present rock-solid stability of Y2Kure.)

You don't need DATE-Y2K for every manual date change, only for those that affect the offset value. If you attempt to use the normal DOS or Windows date functions for these big changes, the DOS date will change only for that session. You will hear a beep to alert you that the BIOS/RTC date was not changed, and your changes will not affect the next boot session.

If you hear the beep, you can then use DATE-Y2K to set the desired date into the BIOS/RTC. DATE-Y2K will show you if it finds any differences between the DOS and BIOS dates.

Or, you can always use DATE-Y2K in place of the DOS DATE function, and never have to even think about this issue. This has the additional advantage that it keeps Y2KURE.DAT updated, so that at the next boot Y2Kure can alert you if the current date is earlier than the prior Y2KURE.DAT date.

However, for the vast majority of users who don't want to monkey around with the system date, the only time DATE-Y2K is really needed is after a CMOS battery replacement.

HOW TO USE Y2KURE:

    DEVICE=C:\UTIL\Y2KURE.SYS

If you want to save even this miniscule amount of low DOS memory, it's possible to install Y2KURE.SYS in the high memory area using the normal DEVICEHIGH command available with DOS 5.0 and later. Note that DEVICEHIGH requires not only HIMEM.SYS but also EMM386.EXE and DOS=UMB, as in the following:

    DEVICE=C:\WINDOWS\HIMEM.SYS
    DEVICE=C:\DOS\EMM386.EXE NOEMS
    DOS=HIGH,UMB
    DEVICEHIGH=C:\UTIL\Y2KURE.SYS

If you want to boot from a floppy for test purposes, just set it up with an appropriate CONFIG.SYS file. Note, however, that the Y2KURE.DAT file will be created in the root directory of that boot floppy. In the event that the system fails the 2000+ retention test, the RTC will be set with a date in the range 1995-1998. If you then boot from the hard drive, with no Y2KURE.SYS and no Y2KURE.DAT there to translate this date, you will have to set it manually.

SPECIAL Y2KURE FEATURES

FORCING THE MODE:

    DEVICE=C:\UTIL\Y2KURE.SYS /F

However, if the system passes originally, you can switch back and forth between modes as often as you want, simply by setting or omitting the /F parameter for subsequent boots. Y2Kure keeps track of the original test results and the prior mode, so it always knows how to set things correctly.

FORCING INSTALLATION:

You can force Y2Kure to install the "Failed"-type Offset driver using the /F parameter as noted above. But if you want to force the normal Pivot driver to be installed, use the /I parameter:

    DEVICE=C:\UTIL\Y2KURE.SYS /I

MESSAGE DELAYS:

• Error message, if the RTC is not operating, or there are errors accessing the Y2KURE.DAT file, or the RTC date is earlier than the date at last boot.

• Reboot message, noting that Y2Kure is about to reboot your system for the 2000+ retention test. This is only given the first time Y2Kure runs on your system.

• Status message, showing normal Y2Kure status, current Pivot or Offset mode, etc.

The time that each of these messages remains on the screen may be set via its respective parameter:

 /En     Wait n seconds after Error message. ( /E  default.)
 /Rn     Wait n seconds before Reboot test . ( /R  default.)
 /Sn     Wait n seconds after Status report. ( /S1 default.)

The default settings are shown above. Note that the 2000+ date retention Reboot test defaults to waiting for a key. This test only happens the first time Y2Kure runs, so the key wait provides time to read the summary of these parameter options... just in case this README was not actually read. (The summary is shown on each boot.)

The Error condition also defaults to waiting for a key, to allow you to see the error condition.

CUSTOM or MULTIPLE INSTALLATIONS:

Similarly, the /En option will supercede any Error key-wait. This may be desired if it is more important that an unattended system boot, than it is for it to have a correct date. If the system goes down due to a power failure, for example, it will then come up completely when power is restored. There will still be a beep alert along with the error message, but it will be overwritten after 'n' seconds of delay as the boot proceeds.

LEAP YEAR LOONIES:

The fear-mongers (and test software marketers) have pushed the idea that there is something "different" about the year 2000 regarding leap years, and in that they are correct. But what is different about it is that is NOT different from any other ordinary divisible-by-4 leap year.

Normally, every year that is divisible by 4 is a leap year EXCEPT century years... unless also divisible by 400, which is the case for 2000. So 2000 is just an ordinary leap year.

The reason for the 400 rule goes back to the original reason for leap years: To compensate for the fact that the actual astronomical year is not exactly 365 days. The divide-by-4 rule employed in the old Julian calendar (attributed to Julius Caesar) considers the year to be 365.25 days, and thus adds one extra day every 4 years. But in reality the true year is a bit shorter, closer to 365.2422 days. So if only the divide-by-4 rule was used, then in 400 years the calendar date would be ahead of the solar year by:

 (365.2500 - 365.2422) * 400 = 3.12 days.

Note that 2100 is not divisible by 400 and so it will NOT be a leap year... that's the first year that the RTC can't handle correctly on its own. Since the DOS file date system is "only" good to 2107 anyway, this is no great loss... even if you are a very optimistic computer museum curator!

CROUCH-ECHLIN "TIME DILATION":

Although this "effect" has received some notoriety on the Internet, independent verification has proved elusive... despite exhaustive efforts by Intel. Intel has never been able to recreate this phenomenon, even on a system provided by Echlin that was claimed to exhibit the problem. What Intel's analysis did uncover, however, were some problems with Echelin's test code. The code did not properly disable system interrupts at certain critical points and may have caused erroneous test results.

Of course, others will be glad to sell you a "fix" for this "problem", but the best way to prevent the Crouch-Echlin effect may be to simply avoid the test code!

On the other hand, if you run Y2Kure with the /F parameter, the RTC and BIOS will never handle any dates in the next century anyway. So even if turns out that there is some validity to the Crouch-Echlin effect, you will be protected automatically with Y2Kure.

OLDER DOS VERSIONS:

If you have an AT-class system running DOS 3.2 or earlier, the usual way to change the RTC date and time is via a CMOS Setup utility. This may be a separate program, or a BIOS feature that is activated by a system-specific key combination. Not only are these utilities awkward to use, but they also force you to reboot your system afterward.

When Y2Kure is used with one of these systems it does not install a resident driver to intercept requests for the BIOS date. Instead, it simply checks the date at boot time and applies the usual 1980 pivot. The corrected date is sent to DOS and the RTC.

Note that this does not provide any protection for programs that may be running during the midnight century transition and have had to shut off the DOS timer and later reset it, as discussed under Problem #2 above. When the RTC year rolls to 1900, such programs will read that and attempt to set the DOS date erroneously. The simple solution is to avoid running such programs at that time... or upgrade to a later DOS version.

However, as a convenience to users of these older systems, the included DATE-Y2K utility will update the RTC when you set the date. You no longer need the clunky CMOS Setup utility for this purpose, and no rebooting is needed.

In the highly unlikely event that you are running DOS 2.x on an AT-class system, you should note that these DOS versions have a further problem: The system date is always set to 1-1-1980, and it is done after CONFIG.SYS runs. So even though Y2kure will properly update the RTC and the system date, the system date will subsequently be overwritten with 1-1-1980. To fix this, put DATE-Y2K in your AUTOEXEC.BAT file (without, of course, giving it any date setting). It will detect the DOS version and update the system date from the RTC automatically, if needed.

Note that the AT-class BIOS will update the system time from the RTC automatically, regardless of DOS version.

DOS versions prior to 2.00 did not support CONFIG.SYS, so Y2Kure will not run on them.

IMPORTANT NOTE: CMOS Setup Utility

HOWEVER, if you have the defective AWARD v4.50 BIOS, it won't allow any year later than 1999 into CMOS. Y2Kure solves this problem by only storing years 1995 through 1998 in CMOS, and keeping track of the overall year via a "date offset" in the separate Y2KURE.DAT file. Hence, the CMOS date will appear to be wrong. If you try to change the CMOS date with the Setup utility (which doesn't take into account the subsequent handling by Y2Kure), you will end up with a wrong overall date.

Instead, wait for the system to boot normally and then set the date via Windows or the DOS DATE utility. If you are making a large (multi-year) date change, use DATE-Y2K for this. You will also need to use DATE-Y2K after a CMOS battery failure or replacement, or if a system crash, etc, corrupts the CMOS date.

• Daqarta download options.
• Daqarta home page.
• Daqarta Help contents.
• Daqarta Main Help Index.
• Daqarta Shareware Registration.
  . . . Remember: We can't make it without you!

Questions? Comments? Contact us!