IBM PCjr From 1984 Keeps Today’s Clocks Running In Sync

A PCjr running an SNTP server

We’ve gotten used to the fact that the clocks on our internet-connected computers and smartphones are always telling the right time. Time servers, provided by a variety of government agencies as well as tech giants, provide them with the exact time and date thanks to accurate atomic clocks and the clever Network Time Protocol (NTP). But it wasn’t always like this: back in the 1990s when many computers didn’t have an internet connection, we had to adjust our computers’ clocks manually. Go back one more decade, and many PCs didn’t even have a battery-backed clock at all; you either set the proper date and time when the computer booted, or just lived with the fact that all new files were timestamped 01-01-1980.

[Michael Brutman] decided to mix today’s world of network time synchronization with the old world of batteryless PCs, and built an SNTP Time Server that runs on a DOS PC. He tried it with two different hardware setups: a 40 MHz 386 PC from 1993, and the (in)famous IBM PCjr from 1984. A standard GPS module serves as an accurate time reference; these units can often be directly connected to old hardware thanks to the eternal RS-232 standard.

Simply having an accurate clock was not enough though: the original IBM hardware had its internal clock only updated every 55 milliseconds, which is not fast enough for a proper NTP server. [Michael] therefore had to tweak the hardware clock’s update rate, taking care not to overload the CPU with too many interrupts. The slow CPU and limited memory anyway required him to implement the Simple Network Time Protocol (SNTP), a stripped-down version of the more common NTP, which leaves out some of the more complex features that deal with synchronizing multiple servers. The network interface is handled by [Michael]’s own mTCP package, which is a TCP/IP stack designed for DOS machines with limited memory.

Tests comparing the DOS time server to the one run by Google showed an offset of no more than a few milliseconds, which should be just fine for keeping all PCs on your home network in sync. Although using an old PC is not the most practical way to run your own time server, [Michael]’s blog post is a fascinating deep dive into the finer points of PC clock architecture and network time synchronization approaches. We’ve seen a time server implemented on ESP8266 hardware before; but you could also dispense with the (S)NTP protocol entirely and directly connect a GPS module to your Raspberry Pi for accurate timing.

32 thoughts on “IBM PCjr From 1984 Keeps Today’s Clocks Running In Sync

      1. Stone, we could dream of seeing a stone perhaps once before we died, if we were very lucky. We had to draw Roman numerals with our fingers in mud. And really it was nothing as glamorous as actual mud, when I say mud, it was just some dry sand that we liked to pretend was mud.

      2. We had to lug a slave with us everywhere, counting the seconds and chiming the hours. It was quite a luxury, because they would only last a few days before they started to count unreliably and had to be replaced. Probably due to lack of sleep. Some would even suddenly throw themselves in front of a horse after a few days. If we had a time-critical appointment, like an important orgy, we would have to replace the slaves about every 3 days, just to be sure that we wouldn’t miss it. Those times were hard for us, before the invention of the sundial. We had to expand our empire just to have access to enough slaves for our timekeeping. :(

  1. IRQ0 for timer interrupt… brings back memories of times long past. Back in the days when computers did exactly what the programmers intended for them to do (errors and all). And nothing more.

    Today, with n+1 layers of abstraction, virtualization and pre-emption, who knows what really happens, though usually the output jives with what the programmer intended.

    1. it’s weird to think back on it because the computer was so simple, yet so much of it was unknown to me. why did i never disassemble a bios?

      i’m pretty sure the answer is in its primitiveness…the bios was simple enough to understand but unfortunately so were all of the tools i had to look into it. the available disassemblers were pretty limited, as were editors and scripting languages i would (now) want to use to aid in the disassembly. and of course i’d want to keep copious notes but just editing a notes file at the same time as having the disassembler open was pretty much out of the question. and of course using git to keep my efforts organized, or sharing them with others or googling the really tricky parts, all out of the question.

      our mysteries seem to have been well-matched to our primitive investigative tools.

      1. IBM published the BIOS for the original PC and PC/XT, and possibly other models. The reference manual was very handy when I had to write drivers to support the IBM DACA board used in a physiology lab. I also made some custom I/O boards for a system built around a 1979 Apple ][ and Apple was kind enough to publish their boot ROM listings in a spiral bound book provided with each computer. It is nice these days not to have to work at a low level writing assembly code. Back then, one had to because that was the only way to get fast enough performance for many applications.

    1. The PC Jr had a clock. But it was an add-on. The picture shows two or three blocks on the right of the PC Jr. That was the expansion, they’d plug into each other. And one expansion block was a clock.

  2. “Go back one more decade, and many PCs didn’t even have a battery-backed clock at all; you either set the proper date and time when the computer booted, or just lived with the fact that all new files were timestamped 01-01-1980.”

    Nope, not all of us. There were third-party Real-Time Clocks sold for XTs. They came on multi-i/o cards (PC/XT bus cards aka “8-Bit ISA”) also that featured memory expansion or another LPT port.

    My father was using a receiver for DCF-77 in the late-80s/90s, also.
    It was connected via COM port to his 386DX PC running DOS 6.2 and Windows 3.1.
    No need for internet connection, at all.

    Sample video of such a device:
    https://m.youtube.com/watch?v=0JU_Ufovf9w
    https://m.youtube.com/watch?v=vzUTV66A_V8

    Nowadays, professional people and the amateur radio dudes use either radio-controlled clocks or the GPS signal for high-precision timing.

    That being said.. I totally love this article! Kudos! 😎👍
    DOS machines can use the PIT chip at a much higher resolution than Windows PCs, AFAIK.
    Even the advanced PIT found in Pentium and higher PCs are restricted under Windows. Or Linux.
    DOS, by contrast, is much closer to a RTOS (Real-Time OS).
    Things like Real/32 are DOS compatible, also.

  3. mTCP is great! I have a ibm 5155 that boots and gets its time from snpt by Michael Brutman. (wifi connected to an internally mounted pi zero w, passing internet over serial) ftp, ftpsrv are very good as well. With microweb the 1983 computer almost feels usable… text only, no images.. almost..

  4. While I’m happy NTP is so easy for PCs, the dream that manual setting of clocks has been eliminated everywhere is far from true. I’ve had multiple jobs now where the company was still running zOS on mainframes for batch processes. Whenever the time had to be set/changed on those systems, it was still ‘best effort’ based on the operator’s (wrist) watch or phone. When our servers had to push/pull data to/from the mainframe as part of the batch processes, we’d be able to calculate how far off the operator’s watch was from GTM. This wasn’t a “10 years ago” thing, but definitely still happening w/in the last 3-4 years.

    In all fairness, IBM does offer a module to support NTP on zOS to prevent manual configuration of the time/clock, but they still charge a ridiculous amount for it, which is baffling since it is so cheap/free for (generically) PCs.

  5. I remember an assignment for a pc based control system. The pwm output was to be through a printer port pin.
    In order to increace the resolution my application reprogrammed the timer chip on the xt pc. I knew my dates would be all wrong and the ockwoukd have to be reprogrammed after the application completed. What I didn’t realise was that the XT floppy drive was just a bunch of IO, all the timing was done under interrupt by the 8086 processor. I was unable to recover my saved file on the floppy.
    Fun with assembly.

    1. That is where the interrupt chaining trick comes in. You install a new interrupt handler, setup the 8253 to tick faster, and then use your new interrupt handler to keep track of the fast ticks. Every nth tick you call the original interrupt handler to allow BIOS to update the time at the correct interval.

      Woe to the person who tries to install multiple interrupt handlers this way … it is not going to work. ;-0

      (See the mTCP ping code for an example of this in action.)

  6. This is really cool!
    I have it in my wishlist of ideas to build a simple retrocomputer with an 8086 or 80186 just to live on my desk as a retro display clock.
    It would be cool to implement this as well!

  7. Back in my day we had to figure out the time, but we hadn’t invented 0’s and 1’s yet …

    No seriously, stay tuned – I intend to do a little more work and then open the PCjr up for public usage for a few days. I’m sure the accuracy will be fine, as the only additional time will come from network latency which I can already simulate on my network. But seeing how it behaves with a higher load will be more interesting. After that I’ll get the source code published.

    I’m also happy to help anybody who wants to recreate this silliness, hence the detailed instructions.

    -Mike

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.