A battery-backed real-time clock for the X68000

The Sharp X68000 was designed to keep track of time even when switched off. Its real-time clock supports file timestamps, scheduled operations, system utilities, and software that depends on a valid date. After several decades, however, the backup battery, clock IC, or surrounding circuitry may no longer work reliably.

A practical repair starts by identifying the existing RTC circuit rather than immediately adding a modern module. Many X68000 systems use a battery-backed clock and CMOS-style registers connected to the system bus, but the exact implementation can vary between early machines, later revisions, compact models, and accelerator or replacement boards. The service manual and a clear photograph of the motherboard should guide every connection.

There are two sensible approaches. Restoring the original clock preserves the machine’s architecture and usually gives the best software compatibility. A retrofit can be useful when the original RTC chip is unavailable, damaged by battery leakage, or difficult to source. In either case, the design must provide a stable 32.768 kHz timebase, retain calendar data while power is removed, and avoid allowing the backup cell to feed the rest of the computer.

Establish the existing RTC circuit

Begin with a visual inspection while the X68000 is disconnected from mains power. Look for a cylindrical rechargeable cell, a coin cell holder, a black epoxy-covered battery, or corrosion near the clock and CMOS area. Battery leakage can travel beneath IC sockets and along internal power planes, so cleaning only the visible residue is rarely sufficient. Photograph the original wiring before removing any component.

The clock device may be identified by its marking, board reference, and relationship to the crystal. Common designs place a 32.768 kHz crystal close to the RTC IC, with a small backup supply path connected to a battery or supercapacitor. Some versions combine clock registers and a small amount of backed-up RAM. Do not assume that a replacement module with a familiar pinout can be connected directly.

Use a multimeter to locate the permanent supply rail, switched five-volt rail, ground, and backup node. With the machine off, the backup node should remain at the voltage required by the clock IC while the main supply falls to zero. With the machine running, check whether the original circuit charges the backup device. This distinction is critical: a CR2032 must never be connected to a circuit intended to recharge a NiCd or NiMH cell.

The enthusiast documentation collected by X68K.NET is useful for comparing board revisions, repair notes, and related hardware projects before committing to a modification. Schematics, photographs, and measurements from another model can provide direction, but they should not replace verification on the individual machine.

Choose between repair and a retrofit

Repairing the native RTC is the least invasive option. Replace the failed battery with the same electrical type, renew damaged traces, clean the socket, and confirm that the original oscillator starts. If the clock IC itself is defective, a compatible replacement from the same family may be possible. A direct replacement keeps the existing address decoding and operating-system drivers intact.

A retrofit is more appropriate when the original IC has failed or when a leaking battery has destroyed part of the board. A modern RTC such as the DS3231 provides excellent long-term accuracy because it includes temperature compensation, while a PCF8563 offers very low backup current and a simple register interface. The DS1307 is easy to find, but its accuracy is generally more dependent on the crystal and temperature.

Modern modules are commonly designed for I²C, whereas the X68000 exposes a Motorola 68000-style parallel bus. That means a module cannot usually be wired to the CPU address and data lines as if it were the original clock. An adapter needs bus transceivers, address decoding, and a small controller or bridge that translates X68000 register accesses into I²C transactions. For a repair project, a parallel RTC with a compatible register model may require less firmware.

A second option is to retain the original RTC interface and use a small microcontroller as an emulator. The microcontroller observes the selected address range, responds to read and write cycles, and maintains time using its own RTC or an attached I²C clock. This is flexible, but it introduces firmware, reset-state, timing, and bus-contention concerns. It is best treated as a designed expansion board rather than a point-to-point modification.

Design the backup power path safely

A backup supply should power only the RTC domain and any memory specifically intended to retain data. The simplest arrangement uses a non-rechargeable coin cell feeding the backup pin through a low-leakage isolation diode or an ideal-diode MOSFET arrangement. The main five-volt supply powers the clock during normal operation, while the diode prevents current from flowing back into the cell when the computer is on.

A CR2032 is attractive because it is widely available and has a useful service life at the low current demanded by many RTC chips. Its limitations matter: it is not rechargeable, its voltage declines gradually, and it should be protected against reverse charging. A holder with a removable cell is preferable to soldering the battery directly to an aged motherboard.

If the original X68000 circuit charges its backup battery, either preserve a compatible rechargeable cell or remove and redesign the charging path. A small series resistor alone may not provide safe charging control. A rechargeable lithium cell needs a proper charge-management circuit, and a CR2032 must be isolated from any positive charging voltage.

Measure backup current with the system switched off and the battery installed. Typical modern RTCs consume microamps or less, but an incorrectly connected pull-up, damaged IC, or powered-down interface can consume far more. Estimate service life using the battery’s usable capacity rather than its headline capacity, since coin cells perform poorly under continuous or pulsed loads. Also check leakage at the backup node after the machine has been off for several minutes.

Keep the backup trace short, clean, and physically separated from noisy switching supplies. Add a small ceramic bypass capacitor close to the RTC supply pins, following the device data sheet. Avoid placing a large capacitor directly across a coin cell unless the charging and startup-current implications are understood.

Connect a replacement to the X68000 bus

The X68000’s 68000-family bus uses address, data, read/write, upper- and lower-data strobes, and asynchronous acknowledge signals. An RTC adapter therefore needs to behave like a properly decoded peripheral. It must respond only to its assigned address range, place data on the bus during valid read cycles, and release the bus immediately afterward.

First determine the original RTC address range and access width from the service documentation or by tracing chip-select logic. Some clock devices expose eight-bit registers, so the adapter may need to respond on only one data byte lane. On a 68000 system, confusing UDS and LDS can produce a device that appears completely dead or that corrupts unrelated memory accesses.

A robust interface commonly includes a voltage-compatible bus transceiver, address decoding with suitable propagation time, and logic that generates the expected device acknowledge. Do not connect a 3.3-volt RTC or microcontroller directly to five-volt bus signals without checking absolute maximum ratings and input thresholds. Level translators should have defined behavior during reset and power sequencing.

For an I²C design, a small bridge can capture a register number and data value from the host bus, then perform the corresponding I²C operation. Reads require the bridge to complete the transaction before asserting acknowledge, so the design must either hold the bus cycle or use a simple status-and-data protocol. A fast CPU or accelerator can expose timing weaknesses that remain hidden on an unmodified machine.

The following choices illustrate the trade-offs involved in a clock restoration project:

Approach	Hardware effort	Accuracy	Software compatibility	Main risk
Repair the original RTC	Low to medium	Original specification	Highest	Corroded or unavailable parts
Compatible parallel RTC	Medium	Depends on crystal	Usually high	Register and timing differences
I²C RTC bridge	Medium to high	Good to excellent	Requires translation	Bus protocol and firmware errors
Microcontroller emulator	High	Depends on firmware	Can be tailored	Bus contention or reset faults
External time-setting tool only	Low	Depends on clock source	Limited	Time is lost when backup fails

Make calendar registers software-compatible

An RTC does more than count seconds. It presents registers for seconds, minutes, hours, day, month, year, weekday, control flags, and sometimes alarm or status functions. Many older devices store values in binary-coded decimal, where 25 is represented as hexadecimal 0x25 rather than binary 0x19. A replacement that returns ordinary binary values will confuse software expecting BCD.

Check whether the native clock uses 12-hour or 24-hour mode, whether the hour register includes an AM/PM bit, and how leap years are handled. The adapter should translate these conventions if the replacement chip differs. Preserve unused bits as the original device would, because diagnostic programs may examine them.

The year field deserves special attention. A two-digit RTC register cannot express the century by itself. The X68000 operating system or startup software may apply its own epoch rule, often based on a defined range rather than a true four-digit year. Test dates around the end of the supported range, including leap day, and verify that directory timestamps remain sensible after reboot.

Reading a clock safely can require a consistent snapshot. If software reads seconds, minutes, and hours while the clock rolls over, it may obtain an impossible combination. Native RTCs sometimes provide an update-in-progress flag, a latch command, or a prescribed read sequence. An emulator should reproduce that behavior, or the bridge should read the complete time internally and present a stable set of registers.

Writing the date should also be controlled. Validate the month length, leap-day rules, and legal hour, minute, and second values before sending them to the hardware. If a setup utility writes unsupported control bits, mask those bits rather than allowing the adapter to enter an undefined mode.

Test accuracy, retention, and failure behavior

Start testing with the original power supply disconnected from the clock board where appropriate and use a current-limited bench supply for the first powered test. Confirm that the RTC supply reaches its specified range, the oscillator runs, and the bus lines remain inactive until the device is selected. An oscilloscope is valuable for checking the 32.768 kHz waveform, but probing the crystal directly can stop or detune a low-power oscillator.

Set a known date and time, shut the computer down normally, and measure the interval over several days. Compare the displayed time with a reference clock, then calculate drift in seconds per day. A crystal-based RTC may gain or lose noticeable time over temperature, while a temperature-compensated device should perform better. Keep a log rather than judging accuracy from one restart.

Test cold starts, warm resets, long power-off periods, and a deliberately depleted or removed battery. The computer should boot without bus lockups when the backup source is absent. A missing battery may produce an invalid date, but it should not damage the system or prevent access to the rest of the I/O map.

Finally, test software that creates files, reads directory dates, sets the system clock, and uses scheduled operations. Confirm that time survives a full power removal and that the clock does not reset when an expansion board or accelerator is installed. Once the results are documented, add the board revision, battery type, measured current, register behavior, and wiring photographs to the project record.

A carefully isolated battery, a compatible register interface, and measured bus timing can give an aging X68000 dependable timekeeping for many more years. Document the repair and share the circuit with the wider preservation community so future owners can reproduce it safely. If your machine is losing its date or showing corrosion near the clock, begin with a board inspection and a backup-current measurement, then build or repair the RTC around verified electrical facts rather than assumptions.