Building a Human68k Utility for Temperature and Fan RPM Monitoring

Many enthusiasts keep Sharp X68000 systems alive through spare parts harvested from older Japanese electronics. In Sydney and Melbourne, weekend meetups often turn into impromptu repair sessions where a cracked solder joint or a dried capacitor gets swapped before lunchtime. The same passion drives interest in writing modern utilities that report on the machine's internal environment, especially when the original 1980s power supplies start to feel their age.

Human68k, the official operating system bundled with the X68000, exposes most of the hardware through well-documented IOCS calls and direct I/O ports, which makes it an ideal target for homebrew monitoring software. A small utility that reads thermistor voltages from an expansion board and counts fan tach pulses can transform how owners care for aging machines. It also opens the door to logging data across long sessions, so thermal trends become visible long before something starts smelling wrong.

The hardware side of this kind of project lives or dies by the choice of sensor and the willingness to splice a few extra wires into a clean machine. Some builders prefer Dallas-style one-wire devices because they only need a single GPIO pin, while others lean toward an ADC chip wired over a slow serial bus. Fan RPM measurement is easier than it looks: most three-pin fans already produce a tachometer square wave, and a simple interrupt counter does the rest.

What follows is a walk-through of the choices, the code, and the gotchas encountered while building a working monitor for a real X68000. It assumes the reader is comfortable with assembly or C on a Motorola 68000 target, has access to a temperature probe, and is willing to spend a weekend getting the calibration right. For related hardware work, the article on real-time clock backup covers similar expansion-bus wiring, while later sections discuss how a status LED can feed back temperature alerts to the user without crowding the screen.

Picking sensors that survive Australian summers

The X68000 was not designed with thermal telemetry in mind, so any monitoring utility has to begin with components that can be trusted in a sealed case during a heatwave. A standard 10 kΩ NTC thermistor epoxied to the heatsink of the main CPU is the cheapest option and reads accurately enough between 25 °C and 75 °C, which covers everything from a Canberra winter to a Townsville summer where the machine sits in a non-air-conditioned study. For owners who want digital output and the ability to add multiple probes along the case, a DS18B20 one-wire sensor solves a lot of wiring problems at the cost of stricter timing requirements on the GPIO side.

When the goal is to measure fan RPM rather than absolute temperature, the tachometer pin of any standard 80 mm or 92 mm case fan is already pulled high internally and pulled low once per revolution by an open-collector transistor inside the motor. A Schmitt trigger buffer such as a 74HC14 cleans up the signal before it reaches the X68000, and a single counter/timer chip keeps the CPU out of the polling loop. Most Australian hobbyists source these parts from Jaycar or element14, both of which ship quickly to regional postcodes.

A third option worth considering is an I²C bus temperature sensor like the LM75 or the TMP102, which only needs two wires and integrates cleanly with a microcontroller that pre-processes the readings. That extra stage can be useful when the X68000's processor is busy with a long batch job and cannot afford to spend cycles bit-banging a one-wire protocol. The trade-off is one more device to power, mount, and protect from the kind of dry dusty air that settles on retro hardware after months of idle storage in a suburban garage.

Tapping the expansion bus without burning anything

Physically attaching a custom board to an X68000 is easier than many guides suggest because the system carries a generous bus with buffered signals. The Nereid-X expansion board, documented elsewhere on this site, already routes some of the address and data lines out to headers, which makes it a tempting base for sensor projects. The simplest approach is to mount a small piggyback PCB on one of the existing bus slots, pull +5 V and ground from the power connector, and reserve a few otherwise-unused I/O addresses for the new peripherals.

Address decoding on the 68000 uses a straightforward chip-select arrangement with a 74HC138 decoder, and the manual reserves ranges like $00E00000 to $00EFFFFF for user expansion on many motherboards. Choosing a base address that is unlikely to clash with installed SCSI controllers or MIDI boards is the first real exercise, and a quick scan of the IOCS _BPEEK and _POKE equivalents will reveal which bytes are already spoken for. Once a free range is identified, the new sensor board can be wired in with confidence.

For Australian builders who source old ISA-style prototyping boards from interstate traders on marketplace platforms, it is worth checking that any replacement chips are not counterfeit pulls from decommissioned server gear. Counterfeit 74-series logic is a known problem in the second-hand market, and a flaky decoder chip can introduce bus contention that slowly damages the CPU. Stick to reputable suppliers, and label each connection with a date and a wire colour so future repair work remains sane.

Choosing how often to read the sensors

Once the hardware is wired, the next decision is the sampling strategy. Polling is the easiest to implement but ties the CPU to a tight loop, while timer interrupts free the processor for other work at the cost of more careful state handling. The comparison below summarises the practical trade-offs observed while benchmarking on real hardware in Adelaide during a 38 °C December afternoon, with the case lid removed to mimic a worst-case scenario.

Method	CPU Load	Latency	Code Complexity	Best Use
Tight polling loop	High	~1 ms	Low	Short diagnostic runs
MFP timer interrupt	Low	~10 ms	Medium	Background monitoring
DMA-driven logging	Very low	~50 ms	High	Long unattended sessions
External MCU pre-empt	Negligible	~5 ms	Medium	Multiple probe arrays

The MFP (Multi-Function Peripheral) timer built into the X68000 is the most natural choice for periodic sampling because it can be programmed in milliseconds and already drives the system clock. A 100 ms cadence produces 600 readings per minute, which is plenty of resolution to catch a stalled fan without burying the rest of the system in interrupts. Developers who want richer logs should consider adding a small ring buffer in low memory so that the application can drain it whenever it next gets the CPU's attention.

A subtle point worth flagging: the original Human68k does not include any sleep primitive beyond the IOCS _ONTIME call, so a busy loop that polls too quickly will lock the machine at 100 % CPU even when nothing else is happening. Pairing a timer interrupt with a lightweight main loop that calls _BEEP on critical events keeps the system responsive while still reacting fast enough to prevent damage.

Putting numbers on screen without spaghetti code

The X68000 offers both a high-resolution text mode and a planar graphical mode that can hold its own against early VGA cards, so the choice of user interface comes down to whether the monitoring tool needs to coexist with another program. A simple text overlay drawn through the IOCS _PUTMES routine is enough for a diagnostic that runs once at boot, while a dedicated full-screen graphical panel is appropriate for a long-running dashboard. Reading values straight from memory-mapped I/O and formatting them with the standard printf-style routines avoids the need to write custom font rendering.

Status feedback that does not rely on the monitor at all is just as valuable. A single LED wired through the parallel port can blink once per degree Celsius, giving an at-a-glance indication of thermal headroom even when the screen is busy with another application. The exact pinout and wiring approach is described in the guide on reset and power LED, which uses similar logic-level translation to drive indicators from the bus. The same wiring can be reused for a tachometer LED that flashes on each fan revolution, doubling as a sanity check that the interrupt counter is still incrementing.

For users who prefer to log to a file rather than watch a screen, Human68k supports redirection of stdout, so piping readings through > into a RAM disk works without any extra code. CSV output with millisecond timestamps can then be imported into a modern spreadsheet, and graphs drawn in something like LibreOffice reveal trends that are invisible during a single play session. Owners who keep their X68000 in a dedicated workshop often leave the logging running overnight so that the morning reveals how the room temperature swings while they sleep.

Calibration, testing, and long-term trust

Calibration is where most of these projects either earn their keep or quietly start reporting nonsense. A thermistor paired with a fixed resistor forms a voltage divider, and the exact resistance curve varies between batches, which means the lookup table has to be filled in against a known reference. Sticking the probe in a glass of ice water and a kettle of boiling water gives two anchor points that bracket almost everything the X68000 will ever see, and a third measurement at room temperature catches any gross wiring error before the system logs bad data for months.

Field testing should cover both a cold start and a sustained workload. A long session of a CPU-heavy game such as the port of Cho Aniki is a reliable way to push the heatsink temperature above 50 °C, and the corresponding fan RPM should rise with it if the BIOS or IOCS fan curve is configured correctly. Discrepancies larger than a few hundred RPM between the tachometer reading and an optical tachometer point to electrical noise or a missing pull-up resistor rather than a software bug.

After a few weeks of trust-building logs, the utility becomes a maintenance record in its own right. A sudden upward drift in idle temperature often reveals a fan bearing that is on its way out, long before the noise gets loud enough to notice during a regular gaming session in a noisy Brisbane share house. Sharing those logs back with the wider X68000 community helps everyone spot failure modes that no single owner would see in isolation.

The source code described here is small enough to read in one sitting, and the resulting binary happily coexists with other Human68k software. Anyone with a working X68000, a spare evening, and a soldering iron can fork the project, swap in their preferred sensor, and publish new builds on the x68k.net project page. Pull requests with improved calibration curves, additional probe support, or a graphical front end are all welcome, and the existing community of Australian and Japanese builders is ready to help test the next revision on real hardware.