Build a Human68k Real-Time Clock Utility

Creating a Human68k utility to display a real-time clock on screen is a compact way to put the X68000’s own capabilities to work. The finished program can show a clock in a corner, update once per second and remain useful during demos, disk maintenance or long troubleshooting sessions. It also exercises the Human68k programming model: read system state, draw to the display and handle exit cleanly.

A clock utility sounds simple, but the X68000 is not a generic PC clone. Text memory, graphics modes and interrupt services differ from an IBM-compatible machine, while a Japanese-market system may have a dead battery, local time settings or a power supply needing attention. A careful build separates those hardware questions from the software path and defines what happens when the machine’s RTC cannot be trusted.

For Australian owners, the project gains useful local context. Sydney and Melbourne users may need AEDT rather than AEST, Brisbane stays on AEST, and second-hand systems are commonly offered through Gumtree or eBay Australia in Australian dollars. The utility can become both a practical desktop tool and a small preservation artefact, supported by source code, wiring notes and test records that keep the platform in active use.

Define the clock’s behaviour

Begin with a behaviour specification rather than a screen picture. A standalone text-mode clock could display HH:MM:SS, add DD/MM/YYYY, and use Australian 24-hour notation. Define whether it runs in the foreground, whether another Human68k program may own the screen, which key exits it and what appears after a hot-key interrupt. These decisions stop a neat overlay from damaging a text buffer the operating environment expects to keep.

Human68k provides date and time services normally exposed by compiler libraries as _getdate and _gettime; exact wrapper names and structures vary, so use the headers supplied with the compiler rather than copying a modern PC declaration. For background on the machine and related restoration work, the community project notes provide a useful reference, but the SDK remains the authority for the API on your build.

Write down the clock’s time basis before coding: local civil time, UTC, or a fixed offset. Also decide how summer time is represented. A display that silently adds an hour to an already adjusted system clock will be wrong twice each year. Keep the format, time zone and daylight saving policy in configuration or command-line options, and record the RTC’s time basis in the README.

Select and validate the time source

The internal battery-backed RTC is the preferred source when healthy. Human68k can return the stored date and time without the utility maintaining its own calendar, and the value survives a reboot. Read the date and time close together, then keep the previous value to detect a second boundary. Do not assume the RTC follows the host machine’s zone; it may still contain Japanese time or the last manually entered value.

Validate every returned field before formatting it. Years, months, days, hours, minutes and seconds should fall within expected ranges, and an impossible date should raise a clear RTC ERROR state rather than become a plausible-looking timestamp. Check the result immediately after setting the RTC through the Human68k setter. A flat battery can produce a valid-looking time for minutes and then drift, so compare it with a known-good clock.

Software timers and external modules are fallbacks, not equivalents. A timer driven by the system tick loses time across resets and becomes inaccurate if the machine sleeps. A serial RTC or GPS receiver can provide a clean reference, but adds wiring, configuration and another failure point. If no trustworthy source exists, say so and offer elapsed seconds instead of passing an unverified value as real time.

Compare the display methods

For a utility meant to run from a Human68k command line, direct text-plane output gives the cleanest result. On the X68000, the text plane is normally mapped at 0xE0000000, with character attributes stored separately, but the exact layout depends on model and display mode. Save the original characters and attributes beneath the clock, write only its narrow region and restore that region before exiting. This avoids scrolling the rest of the console.

Console output is simpler to code but can scroll the screen, and normal character output may be too slow for rapid repainting. Full-screen bitmap or windowed graphics provide flexible placement, yet they require saving graphics state, palette assumptions and more memory. They also make the utility harder to combine with other software. A fixed text overlay is usually the best balance for a clock that must stay readable and unobtrusive.

Choose the method according to where the utility will run, then document that restriction. A media-room display can justify graphics mode, while a diagnostic session on original hardware benefits from predictable text-mode behaviour. The comparison below focuses on practical trade-offs rather than maximum visual effect. Repaint only when the displayed second changes, and keep input handling independent of the drawing code.

Display method	Implementation effort	Update behaviour	Best suited to
Normal console output	Low	Easy, but repeated lines can scroll the screen	Command-line checks and temporary status displays
Direct text-plane writing	Medium	Fast, fixed-area updates; original cells can be restored	A persistent corner clock in text mode
Bitmap or windowed graphics	High	Flexible placement, with more state to preserve	Demonstrations and dedicated media-room displays

For the first prototype, use direct text-plane writing in a known text mode, with the console otherwise idle. Keep a mode-independent abstraction around the drawing functions so a bitmap version can be added later. This makes the clock logic testable without a graphics library and leaves the riskiest hardware assumption—the available display state—visible in the test plan.

Implement the Human68k utility

Start with a small C program whose only job is to read the clock and format one line. Human68k GCC and established X68000 compilers provide DOS or BIOS wrappers for the required services, although their names differ. Test that wrapper layer before adding graphics. A simplified core loop looks like this:

while (running) {
    read_human68k_clock(&now);
    if (now.second != last.second) {
        format_time(now, timezone, display_line);
        draw_clock(display_line);
    }
    wait_for_short_timer_tick();
}

Read the date and time close enough together to avoid a midnight mismatch, and compare the complete value so date boundaries redraw correctly. If the date changes between two reads, repeat the pair once. Format numbers explicitly instead of relying on the C locale. For an Australian display, 21:14:07 06/01/2026 is unambiguous; add AEDT only when the selected time-zone policy says it is active. If converting from UTC, apply the offset before formatting and update the date line separately.

Keep the drawing area as small as possible. A useful layout is eight characters for the time, two spaces and ten for the date. Cache each old cell and attribute, then update only changed glyphs. Detect a scroll or mode change by comparing the screen with the cached copy; at that point, redraw the clock or restore the original area and exit rather than writing into unrelated video memory.

Give the program an explicit lifecycle. It should detect Esc or Q, restore borrowed text cells, reset cursor attributes and return to the prompt. A Ctrl-C handler may be needed if the toolchain supports safe interception. A one-second DOS wait is adequate for a whole-second clock, though a timed tick gives steadier polling. If the RTC becomes invalid, clear the numeric field and show a short diagnostic instead of confidently displaying the wrong minute.

Test under Australian conditions

Time-zone testing matters more here than a simple comparison with the desktop clock. New South Wales, Victoria, Tasmania and the ACT use AEST, UTC+10, in standard time and AEDT, UTC+11, during daylight saving. Queensland, Western Australia and the Northern Territory do not observe it. South Australia uses ACST, UTC+9:30, and ACDT, UTC+10:30, while Lord Howe Island shifts by only 30 minutes. Those differences rule out one hard-coded summer rule.

Check the electrical arrangement before powering the computer. Japanese X68000 supplies commonly expect 100 V AC, whereas Australian mains is nominally 230 V at 50 Hz. A travel plug changes the connector, not the voltage. Use an appropriately rated isolating step-down transformer, confirm the machine’s voltage and polarity, and leave internal power-supply work to a qualified technician. This project is logic-level work, not a reason to bypass the original fuse.

Log results with Australian dates because January and July sit on opposite sides of the local seasonal calendar. Second-hand boards often arrive through eBay Australia or Gumtree in AUD, with Australia Post handling some international shipments and GST potentially applying to imports. Ask for the actual RTC reading, battery condition and original supply requirements. Those details are more useful than a vague statement that the machine is “working”.

Testing with other owners catches assumptions a solitary bench setup hides. Bring the utility to a Sydney or Melbourne retro-computing meetup, perhaps an arvo session where people compare displays over tea, and test a second machine with different video settings. Community preservation groups such as Melbourne Computer Bank and computing collections associated with Sydney’s Powerhouse Museum show why documented, reproducible software remains useful after a particular disk or hard drive disappears.

Release the source and preserve the platform

Package the utility as source, a build note and a short manual rather than only a compiled binary. State the tested compiler, Human68k libraries, supported X68000 models and text modes. Include a checksum for each executable so a damaged disk image can be distinguished from a deliberate update. Screenshots help, but a plain-text description of the display area and key bindings remains easier to search decades later.

Preserve photographs, board-layout sketches and handwritten calibration notes as readable files. Scanning paper records protects them from dust and fading; for a film-scanner-based archive, Nikon Coolscan servicing is a useful specialist reference when the scanner needs attention. Label each image with the X68000 model, monitor mode, RTC reading and test date, so future restorers can distinguish a design decision from a fault.

Publish the project with enough context for someone else to rebuild it. A maintained utility can become part of the broader X68000 software ecosystem rather than another isolated disk image. Release the source, document the Australian time-zone and mains-voltage assumptions, and invite Australian owners to test the clock on working original hardware.