Daqarta for DOS Contents



Free Registration

Contact Us
Daqarta for DOS
Data AcQuisition And Real-Time Analysis
Shareware for Legacy Systems
(Use Daqarta for Windows with modern systems)

From the Daqarta for DOS Help system:

Y2KURE Automatic CMOS RTC and BIOS Year 2000 Correction


Most systems don't even need Y2Kure on 1-1-2000 or later. The vast majority only require a little "help" to initially get the century set properly, after which nothing more is needed. If you set the year to 2000 and reboot, and the year is still the same, then you don't need Y2Kure. If you do install Y2Kure on such a system, when it runs on future reboots it will find everything OK and it won't install any special driver.

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.


Y2Kure is a device driver that you load via your CONFIG.SYS file to cure problems related to the CMOS Real-Time Clock (RTC) and BIOS operation. It will work on any DOS system, including Windows 3.x and 95/98, even those with the supposedly "incurable" Award v4.50 series BIOS. It consumes only 128 to 256 bytes of RAM when running, and does not interfere with the normal system timer or slow operation in any way. Driver parameters allow for custom configurations where desired.

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.


There are two distinct timekeeping systems in modern PCs: the main system timer and the CMOS Real-Time Clock.

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.


DOS can only track dates from 1980 to 2099, so if the BIOS gives it an earlier date then DOS just sets a default of 1-4-1980. That's what most users will see when they first boot up in the year 2000. DOS only gets the date and time once, at boot, so if no other action is taken all files created during that session will have the wrong date. New files will appear to be older than other files, so backup systems may become confused.

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 solution is extremely simple: All you need to do is set the date manually the first time you start up in the new century. Although DOS only reads the RTC date once, it will properly set the RTC date, including the century, whenever you set the DOS date. (If your system is connected to a network, this may be done automatically by the server during log-in.) After that, the RTC will retain the correct century and the BIOS will pass the correct date to DOS on all future boot-ups.


Or, this can be done automatically by software: The Y2KURE.SYS driver checks the date at boot time, and applies the 1980 pivot as needed. If the BIOS reports a date between 1900 and 1979, the driver assumes it is really 2000 to 2079. It then resets both DOS and the RTC to the correct date, so future starts will be correct even if Y2Kure is later removed.


What if the system is running over midnight during the century transition? Normally, this just defers the need to set the RTC, and is no problem whatsoever while running: If DOS has the correct date when it starts in 1999, it will properly roll to 2000 and thus supply the correct date for files and programs. However, DOS doesn't automatically update the RTC, so at the next start the BIOS will see "1900" and you'll need to manually set it if Y2Kure is not present to do it for you, as noted above.

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.SYS driver intercepts requests to the BIOS date function. When an application asks for the date, the driver gets it from the BIOS as usual, then applies a 1980 pivot to the value just as it does at start-up: Dates from 1900 to 1979 are thus reported as 2000 to 2079.

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


Certain BIOS versions (notably Award v4.50 made between April 26, 1994 and May 31, 1995) have a much more serious problem: They don't allow any dates past 1999, or earlier than 1994. What makes this so serious is that if, at start-up, the BIOS gets a year outside this range from the RTC, it actually resets the RTC to a date in 1994.

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.


Y2KURE.SYS tests for this problem the first time it runs. It saves the current date, then tries to set the BIOS / RTC date to 2-2-2002. It then reboots and reads the date back. If the year is not 2002, the Y2Kure regards the BIOS as "Failed" for this date-retention test.

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
By using 4-year steps, the normal leap-year mechanism will continue to provide proper operation. The day-of-week section in the RTC will be wrong, but that is never used anyway: DOS just gets the raw date and performs its own day-of-week calculation, as it has always done since the original PC/XT.

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.


Just put a line in your CONFIG.SYS file to load Y2KURE.SYS. For example, if the Y2KURE.SYS file resides in the C:\UTIL directory, then use:
Then the next time you boot your system, Y2Kure will test for 2000+ date retention via a quick reboot, and install the appropriate driver function. For systems that pass the retention test and only need the 1980 pivot, the installed code consumes only 128 bytes of memory. For systems that fail, and thus need the 4-year-plus-offset operation, the installed code is 256 bytes.

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:

The problem with this is that EMM386 runs in protected mode, which is not compatible with applications like Daqarta that must run in real mode. Otherwise, this works just fine.

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.



The more recent Award BIOS version 4.51PG is reported to return an erroneous year of 2096 under certain unspecified conditions, even though it will otherwise pass the 2000+ date retention test. If you want to force Y2Kure to handle this or any other BIOS as if it had failed (and hence use the 4-year-plus-offset method), then add the /F parameter:
Note that there is no parameter to do the opposite: If the system fails the 2000+ retention test, it can't be made to work properly without the offset driver.

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.


If you install Y2Kure after the turn of the century and it detects a 2000+ date from the RTC, Y2Kure normally reports that it is not needed and doesn't install any driver. No 2000+ retention test is performed, since the system would obviously pass.

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:

Why would you want to do this? Because then Y2Kure will create the Y2KURE.DAT file and monitor the current date on each boot. If it ever detects a BIOS/RTC date that is earlier than the previous boot date (saved in Y2KURE.DAT), it will alert you that there is a potential problem with the RTC.


Y2Kure produces three different types of messages when it runs at boot time, in addition to a header and summary of all these parameter options:
  • 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.)
Where 'n' may be 0 to 9 seconds. If the parameter is given with no 'n' value, then the delay is indefinite and you will be prompted to "Press any key to continue..." along with a beep to get your attention. (Error messages always have an additional beep.)

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.


Administrators may wish to use the /Rn parameter in lieu of the key-wait default for the initial Reboot test. This allows an unattended system to complete the first boot without manual intervention, if there will be no operator there to read the parameter options or status anyway. After the initial boot, this parameter is ignored.

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.


Other Y2K software makes a big deal about testing various leap year conditions. This is complete nonsense: The RTC has a perfectly good leap-year mechanism that has never been found faulty. Since the RTC does not keep track of the century anyway, it is no more likely to have problems in the year 2000 and beyond than it has had in prior years... which is to say, never. Testing leap year handling in the next century makes about as much sense as testing midnight handling, or the transition between 2:25 and 2:46... the century has nothing to do with it.

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.
The Gregorian calendar (attributed to Pope Gregory XIII) that we use today eliminates 3 out of every 4 century leap years, so the cumulative error is reduced to only 0.12 days every 400 years.

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!


This mysterious effect was first claimed to be observed by historian Jace Crouch, and later supported by programmer Mike Echlin. They claim that after the year 2000, certain RTCs and/or BIOSes may start reporting random dates at boot time.

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.


Since the original IBM PC and XT did not have RTC chips, the DATE command on the early DOS versions just changed the DOS date without attempting to update the RTC. That feature first appeared in DOS 3.3 and has of course been continued in all later 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.


All AT-class systems have a CMOS Setup utility, typically invoked by hitting a special key like DEL, ESC, or F1 at the start of the boot sequence. This allows you to change information stored in CMOS memory regarding the system hardware, such as the type of drives or monitor installed. It also allows you to directly change the CMOS time, before Y2Kure has been loaded by CONFIG.SYS. Normally, this is not a problem.

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.

Download Y2KURE.ZIP now (15 Kbytes).

Questions? Comments? Contact us!

We respond to ALL inquiries, typically within 24 hrs.
25 Years of Innovative Instrumentation
© Copyright 1999 - 2006 by Interstellar Research