A Hardware Real-Time Clock for the X68000 Expansion Bus
The Sharp X68000 remains unusually rewarding to modify because its expansion architecture exposes enough of the machine to make practical hardware projects possible. A real-time clock (RTC) on the expansion bus can give software a dependable calendar and time source, even when the original machine has a missing battery, an unreliable clock circuit, or no convenient way to retain settings after power is removed.
The project involves more than connecting a clock chip to a few address lines. The board must decode an address range, translate the X68000’s 68000-family bus cycle into the RTC’s read and write signals, provide a stable 32.768 kHz time base, and protect the backup supply. A small amount of firmware is also required so the operating system or application software can access the registers consistently.
For Australian owners, practical details matter. Japanese X68000 hardware is often sourced through Japanese auction services, eBay Australia, or specialist retrocomputing groups, while replacement components may arrive from Mouser, Digi-Key, or local electronics suppliers. Mains safety is a separate concern when testing a machine built for Japan’s 100 V supply, and Australia’s daylight-saving rules make timezone handling just as important as the circuit itself.
Why Add a Clock To The Expansion Bus
An RTC preserves seconds, minutes, hours, day, month, year, and often weekday information while the computer is switched off. The oscillator continues running from a small backup cell, allowing the system to restore a meaningful date at boot. That is useful for file timestamps, save data, logs, compilers, communication software, and maintenance records.
A clock fitted to an expansion board also avoids disturbing the original motherboard. This is valuable on an X68000 with fragile traces, an undocumented modification, or a hard-to-replace custom component. The expansion board can be removed, repaired, or upgraded independently, and a damaged RTC battery is less likely to leak directly onto the computer’s main logic board.
The bus approach suits projects such as Nereid-X because an expansion card can combine the RTC with storage, networking, or diagnostic functions. The clock may occupy only a few registers, leaving the rest of the board available for other peripherals. It can also provide a consistent time source for a modern network interface, although network time synchronisation should remain an optional correction rather than the only way to set the clock.
Australia introduces a small software complication. A clock should generally store UTC or a clearly defined local time, while the operating system applies the chosen timezone and daylight-saving rule. Sydney, Melbourne, Canberra, and Hobart observe daylight saving; Brisbane, Darwin, and Perth do not. Treating a hardware clock as “Australian Eastern Time” without a policy can shift timestamps by an hour twice a year.
Selecting The RTC Device
A conventional parallel RTC is the simplest match for a 68000 expansion card. Parts such as the MC146818 family, DS12887-compatible devices, and several Japanese RTCs expose registers that can be read and written through a small address window. Some include alarm and periodic-interrupt functions, while others provide only basic calendar registers. Check the exact datasheet because register order, bus width, voltage range, and backup behaviour differ between families.
A DS1307-style I²C clock is inexpensive and readily available, but it cannot be connected directly to the X68000 bus. It needs an I²C controller, a small microcontroller, or programmable logic between the computer and the clock. That additional layer can be worthwhile if the board already contains a microcontroller, yet it adds firmware, startup sequencing, and another possible failure point.
The oscillator deserves equal attention. A 32.768 kHz crystal is standard, but the layout around its pins affects accuracy. Keep the crystal traces short, follow the manufacturer’s recommended load capacitors, and avoid placing fast bus signals beside the oscillator network. A temperature-compensated RTC can improve long-term accuracy, though an ordinary crystal RTC is normally adequate for file timestamps and daily use.
Battery selection requires care. A socketed CR2032 is convenient, but a rechargeable RTC circuit must not be paired with a non-rechargeable lithium cell. If the chosen chip includes charging circuitry, use the specified rechargeable cell or remove the charging path. A supercapacitor is another option for short storage periods, but it will not maintain the clock for months in a machine that is rarely switched on.
Mapping The Device Into The Bus
The expansion card needs a stable address decode before the RTC can be accessed. The decoder may use fixed logic, a GAL, CPLD, or logic already present on the board. Choose an address range documented for the particular expansion interface and avoid assuming that a range unused by one model is free on every X68000. Conflicts can produce symptoms that look like a bad clock: bus errors, corrupted reads, or software that hangs during probing.
The Motorola 68000 bus presents address and data signals separately, with control signals such as address strobe, read/write, upper data strobe, lower data strobe, and data acknowledge. An RTC designed for an Intel-style peripheral bus may instead expect chip select, read enable, and write enable. Glue logic must generate those signals with the correct polarity and timing.
A practical design can expose the RTC as an eight-bit peripheral on either the lower or upper data lane. The board should respond to the corresponding data strobe and return a valid data acknowledge. If the device is wired to D0–D7, software must use accesses that activate the correct lane; if it is wired to D8–D15, the address and byte placement will differ. This is a frequent source of apparently reversed or empty register values.
Avoid relying on slow firmware polling to hide a weak bus interface. The expansion logic should assert data acknowledge within the timing expected by the X68000, or deliberately insert wait states in a controlled manner. Oscilloscope checks on address strobe, chip select, read/write, and data acknowledge are more informative than repeatedly changing software delays.
Designing Power And Protection
Most vintage RTCs used with X68000-era hardware operate from 5 V, although modern replacements may use 3.3 V. Confirm the logic thresholds before mixing supply domains. A 3.3 V RTC connected to a 5 V bus may require level translation, while a 5 V device may damage a lower-voltage FPGA or microcontroller on the same card.
The backup circuit should prevent the battery from powering the entire expansion board when the computer is unplugged. Use the RTC’s recommended diode or power-switch arrangement, place local decoupling close to the IC, and measure the standby current before fitting the final battery. A current draw of a few microamps is normal for many devices; milliamps indicate a wiring error or an unintended load.
A socket makes maintenance safer, particularly for machines stored in warm rooms. Australian summers can be hard on old plastics, electrolytic capacitors, and batteries, especially in an uninsulated shed or spare room. Keep the cell away from hot regulators and provide a visible inspection path so leakage can be spotted before it reaches the board.
When testing a Japanese X68000 in Australia, use an appropriate step-down transformer or a professionally designed replacement power supply. The RTC itself is a low-voltage circuit, but a mistake on the mains side can destroy the computer and create a serious electrical hazard. Do not treat a plug adaptor as a voltage converter.
Writing The Driver And Utilities
The software interface should hide the electrical details from applications. Define a base address, register offsets, access width, and initialisation sequence. Many RTCs use binary-coded decimal, where the value 25 is stored as 0x25 rather than decimal 0x19. Status, control, and oscillator-stop flags also need to be handled during startup.
At first boot, the driver should determine whether the clock contains valid data. A cleared or failed battery may leave an impossible date, an oscillator-stop flag, or an invalid weekday. The utility can then accept a date and time from the keyboard, a file, or a network service. Keep the write process deliberate: update the clock only after validating ranges and disabling any required update-in-progress condition.
A useful command-line tool might support reading the raw registers, displaying local time, setting UTC, and selecting a timezone policy. For Australian installations, document whether the stored value is UTC, AEST, ACST, or AWST. A UTC-based approach avoids changing the battery-backed value when daylight saving begins or ends, while a local-time approach may integrate more easily with existing X68000 software.
The clock can also expose an interrupt for periodic ticks or alarms, but that feature should come after reliable polled access. Interrupt routing differs between expansion designs, and a poorly handled RTC interrupt can lock the machine during boot. Begin with a simple diagnostic program that reads the seconds register repeatedly, confirms rollover from 59 to 00, and verifies that the date advances at midnight.
Useful background material and community contacts are collected through the X68000 community links, where related hardware projects, software resources, and preservation efforts can help clarify model-specific behaviour.
Testing Accuracy And Long-Term Reliability
Testing should begin with the board outside the computer, using a current-limited bench supply and a known-good logic probe or oscilloscope. Confirm supply voltage, standby current, reset behaviour, and the absence of bus activity when the selected address is not present. Then test reads and writes with the machine powered on, followed by a power-down test that proves the clock continues running from the backup source.
Compare the RTC against a trusted reference over several days. A small crystal error is normal: a clock that gains or loses a few seconds each month may be acceptable for retrocomputing, while a large daily error suggests incorrect load capacitance, electrical noise, or a damaged device. Record the result rather than relying on a single quick check.
| Design choice | Advantages | Trade-offs | Suitable use |
|---|---|---|---|
| Parallel 5 V RTC | Direct bus interface and simple register access | Older parts can be difficult to source | Straightforward expansion card |
| 3.3 V modern RTC | Lower power and widely available modules | Requires voltage planning and bus translation | New FPGA or microcontroller design |
| I²C RTC with controller | Flexible and easy to extend | Needs firmware and an intermediary device | Multifunction network or utility board |
| Socketed CR2032 | Cheap, replaceable, and familiar | Must prevent charging and leakage damage | Long-term enthusiast ownership |
| Supercapacitor backup | No disposable battery | Shorter retention period | Frequently used computers |
| UTC storage | Handles Australian daylight saving cleanly | Existing software may expect local time | New driver and utility design |
| Local-time storage | Familiar display for users | DST changes require careful policy | Software tied to local wall time |
Before fitting the card permanently, inspect the expansion connector for oxidation and clean it with suitable contact cleaner. A slightly poor connection can mimic a decoding fault, particularly when the machine has been moved between rooms or transported to a retrocomputing event. Keep a backup of the driver source, register map, schematic, and programmed logic file; documentation is part of the repair.
An RTC expansion card is a compact project with a useful result: reliable timestamps, preserved settings, and a reversible way to extend an ageing computer. Start with a documented address decode, select a device whose electrical interface matches the bus, protect the backup supply, and write software that clearly defines timezone behaviour. Build the circuit, test it patiently, and publish the schematic and driver so the next X68000 owner can reproduce and improve the work.
Nereid-X Expansion Board
A personally-produced LAN+USB+Memory expansion board for Sharp X68000 series computers. Multiple production runs were offered, including a final batch and a later revival reproduction run.
Power Supply Repair
X68 power supply repair and modification services were offered by the site owner, with documentation shared through diary entries spanning 2001–2006.
Server & Networking
Notes on FreeBSD administration, ISP changes, server migration, and networking topics. The site itself ran on FreeBSD with the hns diary system and Namazu search integration.
Get in touch
X68K.NET connects Sharp X68000 enthusiasts through community links and shared projects. Reach out with questions about the Nereid project or X68 resources.