Abstract: This technical brief gives a background on the development of the real-time clock (RTC) in the personal computer, and discusses Y2K issues.

Time has become one of the most dominant factors in our society. We wear watches to keep track of it in order to get to an appointment on time. We use alarm clocks to insure that we wake up in time to start our day. Time has gained even more importance with the development of the computer and data communications networks. When we make a long distance telephone call, the telephone company records the time and length of the call. Credit card companies can now record millions of customer purchases per day and store the information in their database for later recall. When the information is recalled on the billing date, it is used to calculate interest due and the payment amount.

Problems on the Horizon

As we move closer to the year 2000, inconsistencies are starting to show up in the way computers handle dates. Consider a credit card with an expiration date of July 2000. The expiration date on the credit card is shown as 7/00. Many people were surprised when their attempt to make a purchase with the new card was rejected at some locations and accepted at others. Somewhere in the chain between the merchant and the credit card company, the expiration date of 7/00 was treated as July 1900 instead of July 2000 and the card was considered to be expired. Some credit card companies re-issued cards with an expiration date in 1999 in order to gain time to resolve the problems. The problem may not necessarily be with the credit card company. The entire network has to be checked for inconsistencies in date handling. It has to be standardized starting with the merchant, the service provider used by the merchant, the transaction clearing house and the credit card company.

Many computerized systems will experience problems when the year changes from 1999 to 2000 because of the way the systems handle dates. The problem extends well beyond database systems. It encompasses application programs and operating systems as well as hardware. There is a massive, world-wide effort under way to convert systems to properly handle dates beyond 1999. Millions of lines of code have to be converted from handling 2-digit years to 4-digit years. The same applies to applications programs and operating systems.

When an applications program makes a get-date call to the operating system, will the operating system (OS) return 2000, 1900 or 00 for the year? Will the system treat 2000 as a leap year?

2000 is a Leap Year

Everyone knows the 4-year rule which simply states that if a year is evenly divisible by 4, it is a leap year. The exception to the 4-year rule is that a year evenly divisible by 100 is not a leap year. The exception to the 100 year rule is that a year evenly divisible by 400 is a leap year. Figure 1 contains an algorithm for calculating leap years. Since 2000 is evenly divisible by 400, it is a leap year.


Figure 1. Leap Year calculations.

When testing the leap year rules we find that every year evenly divisible by 4 between the years of 1901 and 2099 is a leap year. The year 1900 was not a leap year and 2100 will not be a leap year. For all practical purposes, assuming that a year evenly divisible by 4 is a leap year will provide correct leap year adjustment up to 2099.

All Real Time Clocks made by Dallas Semiconductor treat 2000 as a leap year.

Learning a Lesson From the IBM PC

The original PC XT design did not have provisions for a hardware Real Time Clock. The user had to enter the time and date when the system was turned on. The time and date were stored in the processor memory space where they were updated by the processor based on a periodic interrupt. This software clock eventually became known as the DOS clock. The DOS clock uses the number of days since January 1, 1980 as the basis for calculating the current date. Having the DOS date in a binary form that increments once per day allows the DOS clock to flawlessly transition the year from 1999 to 2000, thus making the DOS clock year 2000-compliant.

When the IBM AT was introduced, its system definition included a hardware Real Time Clock. The hardware clock architecture is shown in Figure 2 as the DS1287. It consists of 14 bytes of timekeeping and control registers with 50 bytes of nonvolatile RAM. There is only a 2-digit year counter and no century counter. An NV RAM location was designated to store the century.


Figure 2. DS1287 Clock architecture.

The hardware clock in the AT is accessed only during the boot process. The date of the month, month, year counter and century NV RAM location are combined and translated into days since January 1, 1980. The translated value is then loaded into the DOS clock and the hardware clock is never accessed again.

When serious testing for year 2000 compliance began, the major problem found on the AT occurred when booting the system after the transition to 2000. The system date was set to January 4, 1980. The reason? The year counter in the Real Time Clock transitions from a count of 99 to 00, but the century location in NV RAM did not change from the value entered by the user during setup. When the system was powered up after the transition to 2000 the BIOS read the year counter as 00 and the century location as 19. With the 4-digit year being 1900, the BIOS read this as an out-of-range date and set the date in the Real Time Clock and the DOS clock to January 4, 1980.

Adding the Century Counter

Maintaining backward compatibility with the existing DS1287 clock architectures had a strong influence on the design of the first Y2K clocks. Since the DS1287 clock was the dominant clock architecture for personal computers and embedded systems, it was important to minimize both the hardware and firmware changes required to use the new clocks.

Dallas Semiconductor made major enhancements to the basic DS1287 architecture in 1992 by adding a century counter, serial number, wakeup, kickstart, 32 kHz oscillator output, 3V or 5V operation and extended NV RAM densities up to 8 k bytes as illustrated in Figure 3. The century counter in the DS1687 coupled with the year counter provide hardware Y2K compliance in the form of a true 4-digit year counter. When the system boots after the 1999 to 2000 transition, the BIOS reads the year counter and an actual century counter to get a true 4-digit year of 2000.


Figure 3. Y2K RTC memory map.

The architecture was extended by increasing the address space from 64 bytes to 128 bytes and using bank switching that swaps the upper 64 bytes in the address space between NV RAM and the enhanced feature registers. The DS1287 architecture is always present when either bank is enabled since it occupies the lower 64 bytes of the address space. With the DS1287 architecture always present, the date and time routines in the firmware only need to be modified to handle the century counter while new firmware routines are added to use the new extended features.

Switching to Bank 1 gives access to all of the extended features in the newer clocks. A unique serial number that can be used to identify the system occupies locations 40h to 47h. The first byte of the serial number is the model byte that also identifies the device type for firmware to use in determining the amount of extended NV RAM in the clock. Extended NV RAM densities are 128 bytes, 2 k, 4 k and 8 k bytes. Since the devices in the family are pin-compatible, systems can be optioned as needed from the lowest to the highest density NV RAM without changing the firmware.

The century counter is at location 48h. When the year counter overflows from 99 to 00, the carry-forward will increment the century counter. The wakeup alarm and kickstart can power up a system or interrupt the processor to perform a task, then shut down under software control. Wakeup uses the time of day and the date of the month to schedule tasks. Kickstart functions from a ground closure on the kickstart pin. The ground closure can come from a key on a keypad or a modem ring detect signal, for example.

The hardware differences between the DS1287 and the DS1687 Y2K clock are illustrated in Figure 4. Three pins were changed to accommodate the kickstart and wakeup features. In a typical DS1287 design, Pin 1 is connected to ground, Pin 18 is connected to Vcc and Pin 22 is floating.


Figure 4: Y2K RTC new functions.

Pin 1 on the DS1687 is an output driven by an open drain MOSFET that pulls down to a logic 0 under one of two conditions. One condition is matching the requirements for a wakeup alarm. The other is receiving a ground closure on Pin 18, the KS* pin. The logic low output on the PWR* pin can be used to turn on a dc/dc converter to power up an entire system or a smaller portion of a system. Wakeup and kickstart will work with or without Vcc applied.

Pin 22 on the DS1687 is the auxiliary battery input. Every time power is applied to the DS1687, the 32 kHz oscillator will turn on and 32 kHz will be present on the SQW output pin. The 32 kHz output can be used for various system management functions. In some cases, the 32 kHz output is needed while the clock is not powered. Connecting a battery or low-current power supply to the Vbaux pin will supply the current to support the 32 kHz output while the DS1687 is in battery backup. This prevents draining the battery inside the module. The maximum voltage on the Vbaux pin for the 5V version of the DS1687 is 5.2V. The higher voltage allows a wide selection of voltage sources. If kickstart is not used the 32 kHz output is not needed while in battery backup, the Vbaux pin should be grounded.

To upgrade an existing system board that uses the DS1287 in the most common design requires that Pin 22 be grounded and a firmware change to program the additional features and read the century counter. This is shown in Figure 5.


Figure 5. Y2K RTC board upgrade.

Other Clock Families

Enhanced versions of the DS164x family of Real Time Clocks with NV RAM are just starting to sample. The DS164x clocks have a separate address and data bus. The DS1643 architecture is shown in Figure 6. It is a basic Real Time Clock with 8 kbytes of NV RAM. The clock occupies the upper 8 bytes of the memory space.


Figure 6. DS1643 clock architecture.

Figure 7 shows the DS1743 Y2K version of the DS1643. Two changes were made to the DS1643. The century counter and low-battery detect were added. To upgrade a design from the DS1643 to the DS1743 only requires a firmware change to handle the century counter and the low-battery flag.


Figure 7. DS1743 clock architecture.

Y2K Checklist

For hardware designs that require year 2000 compliance, the following is recommended.

1. Require 4-digit date entry. Treat a 2-digit date as invalid and ask again for the date.
2. Insure that the operating system and firmware return a 4-digit year result from a get-date system call.
3. Make sure the clock, OS and firmware treat 2000 as a leap year.

More Information

For more information on any of the Dallas Semiconductor products mentioned in this article, please contact Jim Lott or any of our authorized sales representatives or distributors. Also, be sure to see the information on our Timekeeping Family.