Driving an LED matrix from a Human68k program on the Sharp X68000

The original Human68k operating system on the Sharp X68000 was never designed with hobby-grade LED signage in mind, yet the machine's generous memory-mapped I/O architecture makes it a surprisingly capable host for an external LED matrix panel. By tapping directly into the 68000 bus through the expansion slot, an enthusiast can turn a vintage workstation into a chunky, mesmerising scrolling marquee with very few additional components. This article walks through the practical steps of writing such a program, from initial hardware hook-up through to a working C library that paints text on a common 8x32 single-colour matrix module.

Parts for a project like this are readily obtainable across Australia. Core Electronics in Newcastle and Jaycar outlets from Brisbane down to Hobart stock common-cathode and common-anode matrix modules, along with 74HC595 shift registers and the chunky IDC connectors you will need for the X68000's expansion bus. Just remember that local mains sits at 240 volts, so if you decide to drive larger RGB panels from the same rig you will need a proper isolated power supply rather than a bashed-together phone charger.

Hardware setup and signal requirements

The Sharp X68000 exposes a 16-bit data bus on its expansion slot, which is overkill for an LED matrix that only consumes eight data lines plus a handful of strobes. Most builders start by buffering the bus signals through a 74LS245 transceiver so the matrix cannot back-feed noise into the host. A typical single-colour 8x32 module expects a row select, two column multiplexers (high and low) and an enable line, giving you five discrete outputs to drive. Power for the matrix itself should come from a separate 5-volt rail capable of sourcing at least two amps, since the X68000's internal supply is already heavily taxed by the floppy drives and SCSI bridge.

The trade-offs between different connection approaches used to drive an external LED matrix display from a Human68k program are compared below:

Approach	Typical Throughput	Wiring Complexity	Pin Footprint	Best Match for Human68k
Direct 8-bit parallel	Up to 1 MHz strobes	Low	11 lines minimum	Excellent when free I/O is mapped
74HC595 shift register chain	~500 kHz shift rate	Moderate	3 host lines	Most popular hobbyist route
I²C backpack (HT16K33)	100 kHz / 400 kHz	Low	2 lines	Needs bit-banged I²C in firmware
MAX7219 SPI driver board	Up to 10 MHz clock	Low	4 lines including load	Simplest host firmware

If you are chasing a richer visual effect, RGB panels with HUB75 connectors are available through Altronics in Perth and from the larger Australian online retailers, though the wiring count jumps from 12 lines up to around 16. For the purpose of this guide the single-colour variant keeps the firmware readable and the failure modes obvious, which matters when you are debugging late at night in a Brisbane share house and the neighbours have politely asked you to keep the noise down.

Preparing the Human68k development environment

Human68k ships with a perfectly serviceable command-line C compiler, often the Lattice port or a gcc-m68k cross-compiler that vintage Japanese developers used in the early 1990s. If you have the original compiler on floppy, wonderful; but most modern enthusiasts cross-compile on a Linux box using m68k-elf-gcc and then transfer the resulting .X executable across via the X68000's network card or a null-modem cable. The cross-compile approach makes source control with git straightforward and lets you write code from anywhere with a stable link to your retro lab.

Once your toolchain produces a binary, drop it into the root of a Human68k boot disk or a SCSI-attached MO cartridge and run it from the command prompt. Memory on the X68000 is mapped in 16-bit words, so structures that look natural on a modern PC sometimes need to be packed with __attribute__((packed)) to avoid misaligned access faults. With the right compile flags and a Makefile that pumps out both an ELF and a .X file, iteration cycles become quick enough to refine graphics routines without losing your enthusiasm halfway through a build.

Mapping I/O on the Motorola 68000 bus

The Motorola 68000 treats peripheral devices as memory locations, which is a wonderfully transparent model once you get past the initial strangeness. On the X68000, free address space above 0x00C80000 is generally unused by stock hardware, so dedicating a 64-kilobyte window to your LED controller leaves plenty of room for other expansions. A simple address decoder built from a 74LS138 selects the slot only when the upper address bits match the pattern you choose, generating a single chip-select line that the rest of the logic uses to latch data.

Writing the relevant register from C is then no different from writing to an ordinary variable. A pointer cast to a volatile uint16_t * and assigned the value you want transmitted gives the compiler no opportunity to optimise the write away. This direct memory access approach is far cleaner than bit-banging a general-purpose pin because timing is dictated by the 68000's own bus cycles, which run at a predictable 10 MHz on the original machine. The predictable timing is also what makes the resulting display rock-solid even when the rest of the system is busy with disk I/O.

Writing the bit-banging routines in C

With the I/O window mapped, the LED matrix library can be expressed as a thin layer of functions that toggle the row, column and strobe lines. A typical initialisation routine zeroes the display, sets the column multiplexers to scan row zero, and pulls the enable line high. The pixel buffer lives in a small array indexed as display[row][column], and the interrupt handler copies a row from the buffer to the panel before moving on to the next.

For scrolling text, the trick is to render the character glyphs into a wider offscreen buffer and shift the visible window left by one column every few milliseconds. The Human68k timer tick at 100 Hz provides a perfectly serviceable heartbeat. Avoid floating-point maths inside the interrupt service routine; the 68000 has no hardware FPU, and even emulated floating point in software will wreck your refresh rate on anything bigger than a 16-column panel. If you need trigonometry for wavy effects, pre-compute a sine lookup table at startup instead.

Driving a scrollable display loop

Once the primitives work, a scrolling marquee can be built on top in surprisingly few lines. Define a font table covering ASCII, render a string into the offscreen buffer, and animate a pointer that walks left through the buffer at a configurable speed. The main loop becomes a tight sequence of buffer updates and vertical sync waits, leaving the rest of the CPU free for whatever else you fancy running alongside the display.

Tuning the visual feel comes down to experimenting with column delays and the row scanning order. A 1-of-8 multiplex with a row dwell time of around 800 microseconds tends to look crisp without obvious flicker on a phosphor-adjusted screen, though visitors from Melbourne to Adelaide have all reported slightly different perceived brightness depending on the ambient light in their workshops. Storing pre-shifted frames in a lookup table lets you trade a little memory for noticeably smoother animation on machines without accelerator boards.

Handling refresh, ghosting and power stability

LED matrices ghost when charge lingers in the wrong column between row scans. The fix is to blank the display for a few microseconds before switching rows, usually by toggling the enable line low, updating the column select, then re-enabling. A small busy-wait loop calibrated against the 68000's bus cycle count keeps the blanking interval consistent regardless of compiler optimisation choices. A global brightness limiter that scales the row dwell time will save your eyes during long debugging sessions.

Power stability matters just as much as firmware. Australian mains can dip during summer brownouts in regional New South Wales, and a sagging 5-volt rail shows up as random pixels instead of clean characters. A bulk capacitor of at least 1000 microfarads across the matrix supply rail smooths out the worst spikes, and a polyfuse on the data lines protects the X68000 if you happen to short a connector while you are having a go at cable management at 2 am.

Sharing results across the Australian scene

The Australian retrocomputing community is smaller than Japan's but enthusiastic. The annual Sydney Retro Computing Festival and various Brisbane and Melbourne meet-ups welcome new faces keen on Sharp hardware, and mailing lists like Oz-M68K have quietly kept the platform alive since the days of dial-up BBS. A handful of Australian makerspaces, including the Brisbane Makerspace and the Sydney Hackerspace, lend bench space and oscilloscopes to members resurrecting their old X68s.

If you build something worth showing off, drop a note on the X68K.NET projects page where the Nereid-X expansion board and various power supply repair write-ups already live. Sharing your firmware and schematics keeps the pool of working examples growing, and helps the next person who decides to wire up a Human68k program to an external LED matrix display from their garage in Geelong or a suburban spare room in Penrith. The X68000 community is small enough that every contribution genuinely matters, and the next person stuck on a multiplexer fault may well be reading your debug log from a café somewhere in Carlton.

Fire up your cross-compiler, double-check that you have got the right IDC connector gender, and start prototyping. There is something deeply satisfying about watching characters crawl across a chunky matrix panel that is unambiguously being driven by a 35-year-old computer, and the photographs you take will be a small but real contribution to the ongoing story of the Sharp X68000.