DOS BIOS Clock INT 1Ah: Tick Counts, Midnight Rollover, and Date Safety

The original PC BIOS offers system timer services through INT 1Ah. Function AH=00h returns a daily tick count in CX:DX and a midnight indication in AL. This is not a modern wall-clock timestamp: it is a counter maintained by the BIOS timer path, and the rollover information participates in DOS’s date-advance logic. Applications that poll the function casually can consume state that DOS itself expects to observe.

That behavior is a classic compatibility trap. A program may correctly see that midnight has passed and then leave DOS’s date one day behind because its own call cleared or consumed the BIOS indication first. BIOS variants also differ in whether AL behaves as a flag or a counter, and DOS releases have made different assumptions about that return value. A robust program should normally obtain calendar time through the DOS time/date interface rather than stealing a low-level BIOS rollover notification.

Tick counts are a daily counter, not elapsed-time precision

On conventional IBM PC-compatible systems, the BIOS timer advances roughly 18.2 times per second. RBIL records 0x1800B0 ticks per 24-hour day for the usual PC rate, with historical exceptions such as the Tandy 2000. INT 1Ah/AH=00h returns the count in CX:DX; it does not return hours, minutes, seconds, timezone, or date. The count resets or wraps at the day boundary according to the platform’s BIOS behavior.

A minimal real-mode call is:

        mov     ah, 00h
        int     1Ah
        ; CX:DX = BIOS ticks since midnight
        ; AL    = BIOS-specific midnight rollover result

This is a BIOS programming sketch, not a high-resolution clock API. The approximate tick interval is far too coarse for precise frame pacing, benchmarking, or sub-second timeouts. It can be useful for old software that needs a coarse day-relative counter, provided it handles midnight and platform differences correctly.

Midnight state is shared with DOS

BIOS timer code records that the daily count crossed midnight. The DOS kernel later consumes rollover information so it can advance the DOS date. RBIL warns that on IBM and many clone BIOSes AL behaves as a flag; if an application calls the BIOS time function after midnight before DOS does, the application’s read can clear the flag and DOS may not advance its date. It also records that some BIOSes and DOS versions use counter semantics instead, which changes how many rollovers can be represented or consumed.

Therefore, do not build an idle loop that repeatedly invokes INT 1Ah/AH=00h just to compare the current time. Prefer the DOS time function for application-level clock reads, and let DOS own synchronization between BIOS ticks and the date. If a program truly needs the raw BIOS counter, define whether it owns rollover consumption, how it coordinates with DOS, and which exact BIOS/DOS combinations are supported.

This is not merely a theoretical race between two CPUs. The compatibility problem is ownership of a single mutable status indication: software that acknowledges it first can prevent the operating system from seeing it later. The correct abstraction depends on the system contract, not on whether an individual BIOS call appears read-only by name.

Do not confuse BIOS ticks with the real-time clock

The BIOS tick counter is maintained through the periodic timer interrupt path, historically tied to the PC timer hardware and interrupt vector 08h. The CMOS real-time clock is a separate device/interface with calendar and time registers. INT 1Ah includes other subfunctions for clock access, and vendors added services, but the AH=00h tick query should not be confused with directly reading the RTC. Each interface has distinct update, rollover, and compatibility rules.

If software hooks the timer interrupt to perform periodic work, the handler must remain short, preserve required machine state, and chain to the previous BIOS handler as required by the platform. Never perform file I/O, DOS calls, or blocking waits inside a hardware timer ISR. DOS is not generally reentrant from arbitrary interrupt context. Use a small flag or counter and process the work later in the mainline code.

For precise measurements, use a timer source designed for the machine and period you need, with documented monotonic behavior. On a PC-compatible timer, high-resolution measurement often requires programming or reading a lower-level counter and dealing with wrap, latch, and virtualization behavior. That is a different engineering problem from reading INT 1Ah and must be validated against hardware and emulators separately.

DOS time/date interfaces preserve operating-system ownership

DOS exposes time and date through its own INT 21h services. Those calls provide the application-level interface and allow DOS to reconcile its date with timer rollover state. Applications should not silently set the system clock to compensate for a date that appears one day behind; first determine whether the BIOS flag was consumed by the program, a TSR, or another utility.

For diagnostic software, record both the DOS-reported date/time and the raw tick count only when you understand that reading the raw rollover function may mutate shared state. Reproduce the issue in an isolated DOS VM or emulator and observe the date before and after the call. Avoid running a clock diagnostic in production if its probes alter the behavior it claims to measure.

Compatibility varies by BIOS and DOS release

RBIL describes clone BIOSes that set AL as a rollover flag and DOS releases that interpret it as a day counter. Its notes identify historical configuration switches and DOS variants. Treat these details as compatibility records, not a single universal specification. A test on one FreeDOS build, PC emulator, or modern BIOS does not prove behavior on MS-DOS 3.x, PC DOS 7, DR-DOS, or vintage hardware.

When an application absolutely requires this function, document the tested matrix: BIOS vendor/revision, DOS version, emulator/hardware, number of midnights crossed, whether the BIOS tick count was already read by another program, and the DOS date observed afterward. If the application cannot know who owns the rollover state, avoid consuming it and use the OS-level time service instead.

A safe test plan

In a disposable DOS environment, establish a known date and time shortly before midnight. Record the DOS date, call INT 1Ah/AH=00h exactly once after rollover, and then allow DOS to perform its normal date check. Repeat with a diagnostic that does not call the BIOS function, then compare. Run the test with the relevant DOS version and BIOS/emulator combinations; do not alter the host clock or production machine to conduct it.

Also test more than one midnight interval without a read if your target may represent rollover as a flag. Observe whether AL is a boolean or accumulated count and whether DOS increments date once or more. Because that behavior is precisely what varies, the expected result must come from the platform documentation and tested target, not a generic assertion about all clones.

The practical rule is conservative: use DOS time/date APIs for ordinary applications, reserve raw BIOS tick reads for software that has a documented reason, and never consume midnight state without understanding DOS’s responsibility for date advancement.

Related:

Sources: