phatcode.net / articles / other / timing / periodic interrupts with the real time clock

Two previous versions of this technical note have been distributed before. The first one was a small program without any documentation (other than comments in the source), the second version had a decent explanation (I think) about the Real Time Clock hardware, but fell short in describing how the pieces fit together.

This version has expanded coverage on side issues, such as the Peripheral Interface Controllers and on compatibility with the BIOS. In addition, it contains an example in assembly.

Acknowledgements

History

The original IBM PC only kept the date and time while it was running. Each time you booted the computer, it reset the date to January 1, 1980, 0:00 hour. At these days, the AUTOEXEC.BAT file usually contained the DATE and TIME commands, so that you were prompted for the proper date at each boot.

The clock that keeps the current time and date is an 8253 or 8254 chip (or compatible) with three programmable counters. Two of these counters are used for DRAM refresh and to drive the speaker. The third one is hooked to IRQ 0 (interrupt 8) and the default handler for interrupt 8 in the system BIOS adjusts the current time in the BIOS data area at each "tick".

Over time, many programs that needed periodic service also hooked interrupt 8. The PRINT.COM program that comes with DOS is a good example. Some programs also require a faster period than the 18.2 ticks/second standard rate (for example, execution profilers). So they reprogram the timer.

Here the problems begin. First of all, the default BIOS ISR must still see 18.2 ticks per second to keep the time straight. For example, when you reprogram the timer to tick at 91 Hz and pass only one out of 5 interrupts to the previous interrupt handler, this one sees 91/5 = 18.2 ticks per second. If the new timer frequency is not a multiple of 18.2, the process is slightly more complicated, but it is still possible to pass 18.2 interrupts per second to the previous handler on the average.

But this trick only works if the ISR that uses the higher interrupt frequency is the last in the chain of interrupt 8 hooks. If another ISR hooks behind it, that one too will see the higher interrupt rate (and possibly draw incorrect conclusions about when to pop up). Worse yet, if that other routine also reprogrammed the timer... In conclusion, when you reprogram the timer in a TSR (where you cannot guarantee that you are the last in the chain), you may encounter conflicts with other TSRs and application programs. Microsoft Windows has a virtual timer device (VTD) to solve such conflicts between windows applications and DOS boxes.

These problems are what led me to investigate the use of another timer. One that also generates interrupts. One that almost no one uses.

The Real Time Clock

The use of the Real Time Clock is not a general solution to the conflicts outlined above. If enough programs use and/or reprogram the Real Time Clock, we have exactly the same situation. But for now, the use of the Real Time Clock has worked for me in situations that the interrupt 8 method did not.

Why isn't the Real Time Clock more widely used? There may be several reasons. I can think of these:

The RTC/CMOS chip

The chip that contains the Real Time Clock is a Motorola MC146818A CMOS chip. In addition to the Real Time clock, it contains 64 bytes of non-volatile RAM for machine status information. (This is the CMOS data that holds vital information on the type of the hard disk, the amount of memory, etc.)

The RTC/CMOS chip is programmed through the I/O addresses 70h and 71h. Port 70h is the index register and port 71h is the data register. Both ports can be read or written. All internal registers of the RTC/CMOS chip are accessed by setting an index at port 70h and reading from or writing to port 71h. To use the RTC/CMOS chip for periodic interrupts, we only need to consider four of these internal registers: the status registers A to D.

There are a few caveats when programming the RTC/CMOS chip. First of all, the index register is usually set to status register D, and it should remain set to this register. Secondly, after writing to port 70h, you must read from, or write to port 71h. There is no real purpose in writing to port 71h when status register D is selected, because it only indicates whether the RTC/CMOS chip still has power (battery). So after you read or write a value to an internal register, you reset the index register (port 70h) to 0Dh (status register D), and then do a read from port 71h.

Finally, there should not be a long delay between writing to port 70h and reading from or writing to port 71h. Waiting too long between the two operations can cause malfunction of the RTC/CMOS chip. Interrupts must be disabled while programming the RTC. The non-maskable interrupt (NMI) must also be disabled.

The NMI mostly requires you to reboot, so you may be inclined to say "What the heck, why bother to keep the chip in a good shape at an NMI. When an NMI occurs, I have a serious system failure and I'll probably need to do a cold start. So the chip restarts with a clean state anyway". Not so with the RTC/CMOS chip. Remember, this chip continues to work when the computer is switched off. The BIOS does not initialize the chip at boot time; on the contrary, the system reads values from the chip to determine vital parameters such as memory size and the fixed disk type. Malfunction in the RTC/CMOS chip is to be avoided at all cost. That is why you want to avoid an NMI when modifying the RTC, and turn it on afterwards.

Another reason to toggle the NMI is that it is equally simple to turn it off and on as to leave it unchanged. The NMI mask bit is accessed at the same I/O address as the RTC/CMOS index register: port 70h. Bit 7 of port 70h masks or unmasks the NMI at the same time as selecting the index for port 71h.

Now that the basics of the RTC/CMOS programming are covered, we can return to the main course: programming the RTC to generate interrupts.

Status register A is used to select an interrupt rate. The basic oscillator frequency (in the bits 4-6 of status register A) is set to 32,768 Hz. This setting indicates what kind of crystal is connected to the oscillator circuit of the MC146818A chip. On the IBM PC-AT, this is a 32 kHz crystal. Choosing a different frequency setting in status register A can cause the RTC/CMOS chip to update the time incorrectly.

The lower four bits (0-3) of status register A select a divider for the 32,768 Hz frequency. The resulting frequency is used for the periodic interrupt (IRQ 8). The system initializes these bits to 0110 binary (or 6 decimal). This selects a 1,024 Hz frequency (and interrupt rate). Setting the lowest four bits to a different value changes the interrupt rate without interfering with the time keeping of the RTC/CMOS chip.

The formula to calculate the interrupt rate is:

where '>>' stands for the 'shift left' operation and 'rate' is the value of the lower four bits of status register A. This value must be between 1 and 15 (selecting 0 stops the periodic interrupt). The interrupt frequency you can choose is thus always a power of 2 between 2 Hz and 32768 Hz. There is a caveat, however. With an input signal of 32768 Hz, the timer output 'rolls over' if you set the value 'rate' to 2 or 1. Instead of producing periodic interrupts of 61.0 �s or 30.5 �s respectively, they produce 7.81 ms and 3.91 ms interrupts. The fastest interrupt rate you can generate is 8 kHz (122 �s interrupts), by setting 'rate' to 3. Higher frequencies require a higher base frequency, and this would require a different crystal than is installed in the IBM PC-AT.

Status register B contains a number of flags. We are only interested in one of these flags: the "Periodic Interrupt Enable" or PIE bit. Setting this bit is the only thing left to start generating interrupts to IRQ 8. By the way, the choice of IRQ, interrupt and I/O port numbers is very confusing. When IRQ 8 fires, it generates INT 70h. This is just the way the secondary PIC is programmed. It has nothing to do with I/O port 70h, through which the RTC/CMOS chip is programmed. Also, INT 8 belongs to the standard timer, IRQ 8 to the RTC. We have just to be extra precise when talking about this subject.

When an IRQ 8 fires and interrupt 70h is called, status register C holds a bit mask that tells what kind of interrupt occurred: periodic interrupt, alarm interrupt or update ended interrupt. And unless you read status register C, IRQ 8 will not be generated again. This means that you must read status register C inside your ISR for interrupt 70h even when you normally don't care about its contents. Otherwise you will only see a single interrupt.

The bits in status register C are not used in the example program. They are useful when several interrupts of the RTC are connected to IRQ 8. The bits in status register C let you detect what interrupt caused IRQ 8.

The last thing we have to cover before leaving the RTC/CMOS chip is how to detect the chip. Two common methods are to check that the I/O ports are functioning (write a value into one of them and read it back), and to use a BIOS function that also uses the hardware and check the results. Although it looks cleaner, the BIOS function should be used with caution, because it might use different hardware to achieve the desired result. Indeed, the IBM PS/2 model 30, running on an 8086 processor, has Real Time Clock services, but not with the same hardware. The model 30 uses a VLSI gate array for the keyboard controller, mouse controller, real time clock and interrupt controller. There is only one interrupt controller (compatible with the 8259A PIC chip in the PC XT and AT computers), but all functionality is jammed inside the 8 lines of the PIC by connecting the keyboard, the mouse and the Real Time Clock to IRQ 1.

The Peripheral Interrupt Controllers

The Peripheral Interrupt Controller (PIC) converts IRQ signals to hardware interrupts. The original PC had only one PIC (chip 8259A) for eight IRQ lines. These IRQs 0 to 7 are normally redirected to (hardware) interrupts 8 to 0Fh. Many DOS extenders reprogram the primary PIC to relocate the interrupt range, because interrupts 8 to 0Fh collide with the processor exception interrupts.

The IBM PC-AT and compatibles have two PIC chips in a chain. The second PIC is chained to IRQ 2 of the first PIC. The RTC is connected to the first line of the secondary PIC. The IRQ lines of the secondary PIC are usually translated to interrupts 70h to 77h.

We deal with the PICs at two places. The first one is that an ISR for a hardware interrupt should send an "end of interrupt" (EOI) signal to the PICs before returning. Otherwise the PIC will not generate an interrupt for the IRQ or any IRQ of a lower level. In the case of the RTC, we must send a non- specific EOI to both PICs (since they are chained).

Each PIC has an 8 bit mask that disables selected IRQs. Masked IRQs are not passed through to the microprocessor. The BIOS by American Megatrends Inc. (AMI) disables IRQ 8 (bit 0 in the mask of the secondary PIC) at start-up. We need to unmask IRQ 8 when initializing the RTC. Many BIOSes (e.g. those by Phoenix and those found in the IBM PS/1 and PS/2 series) enable IRQ 8 by default, but it doesn't harm to enable it again. Although the secondary PIC is chained to the primary PIC on the IRQ 2 line, it is usually not necessary to reprogram the mask of the first PIC. IRQ 2 is always enabled, since the hard disk and other essential hardware is also connected to the secondary PIC.

Compatibility with the BIOS

The goal is to be able to jump to the previous INT 70h handler after your handler has done its work. This is common practice when writing ISRs. But in the case of the RTC, you have to deal with the irritating feature of the default INT 70h handler, which shuts the RTC down after the time period in the BIOS data area has expired.

My demo program avoids all this by not jumping to the previous INT 70h handler. After all, the intent is to show the workings of the RTC, not that of the BIOS.

A simple way to solve this is to disallow the BIOS functions that use the RTC. To do this, you set the byte at address 0040h:00A0h to 1. This value tells the BIOS that the RTC is in use, and makes functions 83h and 86h of interrupt 15h fail (return with carry flag set). Then, before jumping to the previous INT 70h handler, you store at address 0040h:009Bh a double word value that is at least 976. The default interrupt handler subtracts 976 from the value at that address and halts the RTC periodic interrupts if at drops below zero (976 is the time in microseconds that passes between two invocations of INT 70h if the RTC is ticking at its default frequency of 1024 Hz).

If you require that the BIOS functions 83h and 86h of interrupt 15h keep working, the best solution probably is to take over interrupt 15h. You then need to simulate these functions. That means that you must update the BIOS data area, detect a time-out and handle accordingly. If you choose this path, remind that the default INT 70h handler also issues INT 4Ah on time-out (in addition to shutting the RTC periodic interrupt down).

Strapping it all together (the program)

I fear of viruses, I only distribute source. You will need an assembler to get the demonstration program running. Considering that you are probably a low level programmer if you are interested in this, I hope this is not too inconvenient.

The demonstration program has been tested on the following hardware:

It has also been tested with the following software environments:

Now that we have finished our journey through the peculiarities of the Real Time Clock, it is time to discuss where it can be used.

What led me to investigate the RTC, were audio drivers for an audio product that my company makes. This device connects to the printer port; the printer itself is chained on the back of the plug. The concept is very similar to that of the Disney Sound Source.

To generate sound on the device, I had to push a sample through the printer port 8000 to 22000 times per second. The first drivers did this in the foreground by polling (even without reprogramming, you can get very accurate timing read-outs from the 8253 chip, but that's a different story). Later drivers played sound in the background and were, therefore, interrupt driven. I first used interrupt 8h and a reprogrammed 8253. Although there were some compatibility problems, on the whole it worked reasonably well.

The real problem was the Microsoft Windows drivers. Windows virtualizes the 8253 timer chip, meaning that the chip cannot be touched from the outside. It is protected. There is one loophole, called a VxD (short for Virtual Device Driver). If you write a VxD, you can modify the timer, but Microsoft strongly warns against such practices and I feared Windows' instability might be blamed on my driver if it did these tricks. (This is not far fetched. I already got several reports from a customer that their machine hangs at times when my driver, based on the RTC, is installed. The machine also hangs periodically when the driver is not installed, but then, apparently, less frequent. With quite a lot of talking over the telephone, I traced down two of the three bug reports: one was due to a third party DLL that they use, the second to a faulty screen driver. In all fairness I must say that I also corrected a bug in my driver, but one that was never reported.) So I was looking for other timers, and I was convinced that I would need to a one in the audio plug. The stories I heard about IRQ conflicts with parallel ports and cheap multi-I/O boards that do not handle the IRQ line correctly were not very encouraging. We would only be able to sell these plugs if the installation was effortless. Always!

So you can imagine my excitement when you came upon a remark in one of the IBM Technical References that said the "BIOS sets the Periodic Interrupt rate of the Real Time Clock to 1024 ticks per second". Wait a minute, would that mean that you can achieve higher interrupt frequencies?

Other people have also used the Periodic Interrupt for the Real Time Clock, and sent me a message (and I highly appreciate that, thank you). Here is what the Real Time Clock is used for:

Articles

Other

Periodic Interrupts with the Real Time Clock

Article Text