The Apple II series (up until the IIgs) did not have a built in clock. As such, there were a few add-on devices that could be installed that would keep a battery-backed time that could be queried by software. With the introduction of ProDOS, Apple decided to add the ability for time stamping files and Apple decided to standardize on a device called the Thunderclock.

Though a few other time keeping devices came out for the machine, they were either Thunderclock compatible or needed custom software or patches to be recognized by ProDOS. In particular, one product called the No-Slot Clock was popular because it didn't take up a precious slot and also made it possible to use on the //c. However, it did require a patch to ProDOS to work.

These days, it seems that the only way to get time on your old Apple II is to purchase a reproduction of the No-Slot Clock and thus some time-dependent software seems to now be targeting that device probably because actual slot-based time cards weren't very common back in the day.

My question is whether the No-Slot Clock is compatible with the Thunderclock? I'm sure if you used ProDOS APIs to get to the time then it would be abstracted, but is it possible that people could be writing NSC software because there were extra features that could be exploited? Were they fundamentally different APIs? Does it make any sense to make software for the NSC versus the Thunderclock standard? Why did the NSC need a patch in ProDOS?

  • By patch do you mean driver? There are several NSC drivers for ProDOS. A "patch" for ProDOS is not needed for NSC support, but ProDOS only supports certain date ranges and needs to be patched for others. Jan 23, 2018 at 21:29

2 Answers 2


They are incompatible.

I found the manual for the Thunderclock at the Internet Archive. I found the manual for the classic No-Slot Clock elsewhere. I also looked at installation instructions for the modern version.

The no-slot clock, as you say, doesn't fill an expansion slot. Instead you install it between the ROM and the mainboard. It gets exactly the same signals as the ROM gets. In particular:

Communication with the No-Slot Clock is established by pattern recognition of a serial bit stream of 64 bits which must be matched by executing 64 consecutive write cycles, placing address bit A2 low with the proper data on address bit AO. The 64 write cycles are used only to gain access to the No-Slot Clock.

After which:

Information transfer into and out of the No-Slot Clock is achieved by using address bits AO and A2, control signals OE and CE and data line DQO. All No-Slot Clock data transfers are accomplished by executing read cycles to the mated memory address space. Write and read functions are determined by the level of address bit A2.

So you need to cause it to observe a specific 64-step access pattern to the ROM, after which it will activate and you can either feed it a bit stream by reading addresses that indicate the data you're writing, or read from it.

It's all a bit convoluted, but that's how you can fit it onto the existing bus.

Conversely, the ThunderClock (at least the Plus, for which I found the manual) exposes firmware and BASIC extensions for reading and writing; the documented assembly way of accessing it is via calls to Cx08 and Cx0B, where x is determined by the selected installation slot. It can provide interrupts. The documented version offers additional functionality such as BSR/X-10, which is for home automation — that idea is about as new as it is commercially successful.

Immediate conclusions then:

  • the officially documented way to access the ThunderClock is to use firmware extensions. The No-slot Clock does not offer those extensions. Therefore software written for the ThunderClock won't work on the No-Slot Clock;
  • the officially documented way to access the No-Slot Clock is by specially-crafted ROM access patterns that can be parasitically intercepted. The ThunderClock does not observe interactions with the main ROM. Therefore software written for the No-Slot Clock won't work on the ThunderClock;
  • because the ThunderClock uses some of the memory space reserved for its slot, an equivalent device that wasn't physically in a slot would nevertheless effectively cause one to be unavailable; and
  • the ThunderClock offers interrupt-driven time updates, but the No-Slot Clock does not even have access to the interrupt line. Therefore a No-Slot Clock could never be ThunderClock compatible.
  • AFAIR the patterns used to activate the NSC and the data formats where also not disclosed and had to be 'discovered' by analyzing the binary - at least that's what I remember.
    – Raffzahn
    Jan 19, 2018 at 14:48
  • 2
    Oh, and, since the NSC was based arround ROM access, it could be used with next to every computer offering a standard ROM socket.
    – Raffzahn
    Jan 19, 2018 at 14:49
  • 2
    @Raffzahn Indeed, the linked manual describes it as being for the Apple or the PC (i.e. the complete list of 'serious' American computers); I had otherwise forgotten that the PC's real-time clock didn't turn up until the AT. Anyway, funny that we posted within seconds of each other — if your answer had already been here, I wouldn't have bothered with mine. I think the two are very similar.
    – Tommy
    Jan 19, 2018 at 14:53

My question is whether the No-Slot Clock is compatible with the Thunderclock?

No. Thunderclock is a standard Apple II I/O Card, placing chip registers and ROM routines in memory areas provided for the slot they are in. All access is done either via direct hardware access or using the card ROM functions.

No-Slot-Clock is, as the name implies designed to use no slot resources. Therefore it can not provide a compatible interface at all. No ROM means no ROM calls via Cnxx, and no I/O Port means no access via C0nx.

The No-Slot-Clock's access is done via consecutive read access to a bunch of ROM addresses creating a serial protokoll to unlock and read or write information.

is it possible that people could be writing NSC software because there were extra features that could be exploited?

Yes, but it's not a feature of something more powerfull or whatsoever, but the fact, that this clock doesn't need I/O resources. Hence, No-Slot. I could be added to a fully cramped Apple II - or even an Apple IIc, which otherwise couldn't add a slot based clock.

In fact, the Thunderclock did provide more functionality. Not only could it provide time based interrupts (timers) but also handle a remote :)) So if you want to get more than just the time of day and data, you might want something else than a No-Slot-Clock.

Were they fundamentally different APIs?

Thunderclock did provide a nice ROM based high level interface suited for easy access by BASIC (DOS and ProDOS), and still somewhat good access by Assembly. The No-Slot-Clock always needed an additional binary driver to be read or set. No function available without.

Does it make any sense to make software for the NSC versus the Thunderclock standard?

More installations. Programming for the No-Slot-Clock allows your software to use the clock feature by installing a No-Slot-Clock. Even on an Apple IIc. Supporting only the Thunderclock restricts the clock feature to machines with slots (II/II+/IIe).

Why not support both (like with a loadable driver binary).

Why did the NSC need a patch in ProDOS?

Cause ProDOS knows about time (DOS doesn't) but didn't have a driver for the No-Slot-Clock build in? How else would one be able to change the driver than by patching ProDOS?

  • Given all the other changes Apple made to the Apple //e, I find it a little curious they didn't include any "background" time-keeping mechanism since that was one of the recognizable limitations of the Apple ][ compared with its contemporaries.
    – supercat
    Feb 21, 2018 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .