Writing a Human68k Boot Screen System Information Program

The Sharp X68000 remains one of the most elegant home computers ever produced, and getting it to greet you with useful hardware details on power-up feels like a small ritual of preservation. A custom Human68k program that runs at boot can show CPU clock speed, memory size, SCSI device count and a friendly timestamp before the usual CONFIG.SYS chatter scrolls past. For hobbyists in Brisbane, Melbourne or anywhere with a flaky internet connection, having on-screen diagnostics eliminates guesswork when troubleshooting a temperamental machine after a long hiatus in the cupboard.

This article walks through the practical steps of building such a program, from assembling the toolchain on a modern PC to transferring the binary onto a real X68000 using a Gotek floppy emulator or SCSI MO cartridge. The code stays small enough to fit inside the boot sector region reserved by Human68k, and the source uses standard M68K assembly so anyone with prior 68000 experience can follow along. Australian collectors often share schematics and ROM dumps through local Discord servers and the quarterly meetups held at the Powerhouse in Ultimo, so the techniques described here slot neatly into that communal workflow.

A few readers will notice that some Human68k documentation is only available in scanned Japanese, which can slow things down for English-first developers. The good news is that the boot environment is remarkably well documented in the open X68000 technical references, and most system calls follow the same trap-based convention as the rest of the Human68k API. Once the build environment is in place, the rest of the project tends to fall into place naturally.

Setting Up Your Human68k Toolchain

The first practical hurdle is choosing an assembler that targets the M68K instruction set and produces a Human68k-compatible binary. The GNU m68k-elf-as toolchain works well when paired with a custom linker script that places the code at the appropriate load address, while the older has060 assembler remains a favourite among purists who want byte-for-byte compatibility with mid-90s development workflows. Either approach produces a flat binary that the boot loader recognises without modification.

On a modern Windows or Linux workstation the toolchain installs in minutes, but the workflow differs slightly from typical cross-compilation. The build script needs to invoke the assembler with -m flags set to the 68000 CPU variant, then run the resulting object through objcopy to strip symbols and produce a raw binary. Australian hobbyists often run this build cycle on a ThinkPad running Fedora, since those machines tend to be cheap second-hand and have native serial ports for talking to the X68000's RS-232C interface. The serial transfer utility x68k_send handles the XMODEM protocol reliably at 115200 baud, which is the practical ceiling for the X68000's stock serial hardware.

A typical Makefile might look like this:

AS = m68k-elf-as
LD = m68k-elf-ld
OBJCOPY = m68k-elf-objcopy
CFLAGS = -mcpu=68000 -nostdlib

boot.bin: boot.s
    $(AS) $(CFLAGS) -o boot.o boot.s
    $(LD) -T linker.ld -o boot.elf boot.o
    $(OBJCOPY) -O binary boot.elf boot.bin

The linker script reserves the first 512 bytes of the binary for the boot header, which Human68k inspects to determine load address and entry point. Skipping this header produces a binary that loads correctly and crashes immediately, a frustrating failure mode that has caught out plenty of newcomers at the Melbourne retro computing meetups held every few months at the Flagstaff Gardens community hall.

How the Boot Process Loads User Programs

Human68k starts by reading the first sector of the boot device into memory at address $FF0000, then transfers control to the entry point specified in the boot header. This little routine has roughly 256 bytes to perform any initialisation before the kernel proper takes over and begins executing CONFIG.SYS. Anything loaded in that window runs before the IOCS initialisation, which means the screen is still in a 512×512 16-color graphical mode and the text console has not yet been set up.

Because of this timing, the boot program must configure the graphics hardware itself if it wants to print text rather than manipulate pixels. The IOCS provides trap #2 calls for screen drawing, but at this early stage IOCS vectors may not be installed yet, so direct programming of the VASM and CRTC registers is the safer path. Australian developers familiar with the Amiga will recognise the challenge: setting up a copper-like display list before the operating system expects to take control of the hardware.

The boot header itself is a simple structure:

Offset	Size	Field	Purpose
0x00	4	Magic	Bytes $00 $EB $00 $EB identifying a Human68k boot sector
0x04	4	Load address	Where Human68k should copy the program
0x08	4	Entry point	Address to jump to after loading
0x0C	4	Size	Length of the binary in bytes
0x10	...	Program data	The actual code and data payload

The load address must point to a region that survives into the runtime environment, which means anywhere in the lower 4 MB of RAM works. Choosing $001000 keeps the program out of the way of the interrupt vectors and the Human68k system globals, a small detail that matters when the boot code shares memory with later drivers. Many of the existing X68000 boot utilities documented at the community links page follow exactly this convention, so newcomers can compare their headers against known-working examples before flashing anything to ROM.

Crafting the Display Routine in 68000 Assembly

The display routine itself is straightforward 68000 assembly once the screen mode is configured. After initialising the CRTC for a 768×512 31kHz display, the code clears video RAM, draws a border, then writes ASCII characters by mapping each glyph to an 8×8 tile stored in a small font table. The X68000's text VRAM is organised linearly rather than as a tile map, so each character requires eight consecutive byte writes to render properly.

A minimal text-output subroutine looks like this:

print_string:
    movem.l d0-d1/a0-a1,-(sp)
    movea.l #vram_base,a0
.loop:
    move.b (a1)+,d0
    beq.s .done
    lsl.w #3,d0
    lea font_table,a1
    adda.w d0,a1
    rept 8
    move.b (a1)+,(a0)
    adda.w #screen_pitch-1,a0
    endr
    bra.s .loop
.done:
    movem.l (sp)+,d0-d1/a0-a1
    rts

This routine reads bytes from the string pointed to by a1, looks up each character in the font table, and blits the 8-byte glyph into video RAM. The screen_pitch constant accounts for the X68000's 1024-byte row stride, which leaves room for the border and overscan without having to recalculate pixel positions for every glyph. Australian builders tend to optimise the font size down to a 4×6 monospace variant when space is tight, since the boot region has hard limits on how much code can fit before it overlaps the next stage of the loader.

For colour, the X68000 offers a 16-color paletted mode that is perfect for boot screens. A few well-chosen entries in the palette register produce a clean cyan-on-black display reminiscent of early CRT terminals, the kind of look that appeals to hobbyists in Adelaide who restore vintage computing hardware as a side interest. Setting palette index 0 to black and index 1 to a warm cyan creates good contrast for the system information text, while reserving index 2 for a soft amber accent lets the timestamp stand out from the rest of the output.

Pulling System Info from Hardware Registers

The interesting part of the project is reading actual system data from the hardware rather than printing static text. The X68000 exposes a surprising amount of diagnostic data through memory-mapped registers, including the CPU type, MMU presence, memory size and the contents of the real-time clock chip. The MMU configuration register at $00E8_0000 reveals whether the machine has been upgraded with the 68881 or 68882 FPU, which is useful for collectors who swap motherboards between machines without keeping careful notes about which one has the math coprocessor installed.

Reading the real-time clock requires care, because the RTC chip updates its registers asynchronously. The standard pattern is to read the seconds, minutes, hours, day, month and year registers in a tight loop until two consecutive reads agree on the seconds value, which guarantees the other registers were not updated mid-read. The Mitsubishi M6242AFP chip used in most X68000 models follows this protocol, and the trick is documented in the official service manual. Australian owners who purchased their machines second-hand from Japanese auctions often have no idea whether the RTC battery has been replaced, so displaying the date and time on boot is a small but welcome convenience.

Memory detection uses a simple walking-bit test that writes a pattern to each 64K block, reads it back, then restores the original contents. The test should skip the first 64K because that region is occupied by Human68k system globals and the interrupt vector table, but everything from $00100000 upward is fair game. The code reports the largest contiguous block found, which on a stock XVI Compact is 2 MB and on a fully expanded ACE is the full 12 MB supported by the original architecture. Developers at the Brisbane retro computing collective often pool results from memory tests across multiple machines to verify that no two production runs had different memory layouts.

Compiling, Linking and Burning to ROM

With the source code written, the next step is producing the final bootable image. The build process produces a flat binary, which then needs to be wrapped in a Human68k boot sector wrapper that prepends the header structure described earlier. Tools like mkhboot accept the raw binary plus the desired load address and produce a sector image suitable for writing to a floppy disk or MO cartridge.

Transferring the image to physical media depends on the equipment available. Owners with a Gotek floppy emulator running FlashFloppy can drop the image onto a USB stick in the proper /X68K/BOOT/ directory structure, which the emulator exposes as drive 0. Those with SCSI hardware can use a Macintosh running ASV to write the image directly to a 128 MB MO cartridge, which is a popular method in Sydney retro computing circles because the cartridges are still relatively cheap on the second-hand market compared to original X68000 floppies. The cost of a blank MO in AUD is usually between fifteen and twenty-five dollars, which works out cheaper than buying individual floppies for testing iterations.

ROM burning requires an EPROM programmer capable of handling 27C256 or 27C512 chips, depending on whether the boot code is stored in 16K or 32K. The X68000's ROM socket accepts either with the right adapter, and the process is identical to burning a ROM for any other 68000-based machine. Australian hobbyists with access to a Pickit or TL866 programmer typically burn their boot ROMs during weekend sessions, since the equipment is shared across a small group of friends who all live within driving distance of each other. The first successful boot often feels anticlimactic: the screen clears, the text appears, and that is exactly what should happen.

Testing on Real X68000 Hardware

Testing boot code carries real risk, because a faulty image can prevent the machine from reaching CONFIG.SYS or even the IOCS initialisation screen. The safe approach is to keep a known-good boot floppy in drive 0 and use a separate SCSI drive for the experimental boot code. If the experimental boot fails, holding down the OPT.1 key during power-on forces the X68000 to boot from the keyboard-selected device, which lets the operator recover without opening the case.

A logic analyser or even a basic oscilloscope helps diagnose problems with the boot sequence, particularly when the machine seems to hang immediately after the screen clears. Watching the address bus during the first few milliseconds after reset confirms whether the boot ROM is being read at all, which is the first question to answer when nothing appears on screen. The signals are fast, so a 100 MHz scope is the practical minimum, but most Australian retro computing enthusiasts already own something in that range from earlier Atari ST or Amiga projects.

When the program finally works as intended, the boot screen should display something like:

X68K System Information
CPU: 68000 @ 10MHz
FPU: 68881
Memory: 2 MB
Date: 2026-01-15 14:23:01
Boot device: SCSI ID 0

The exact format is a matter of personal taste, but consistency with existing Human68k utilities helps when other developers want to incorporate the routine into their own projects. The local Sydney retro computing group maintains a Git repository of community boot utilities, and the most polished submissions tend to use a consistent header layout that includes the author's call sign and a build date. Adopting that convention makes the code easier to maintain and share across the wider X68000 community.

Refining and Sharing the Result

Once the basic version works, refinements tend to focus on visual polish and additional diagnostic data. Adding a small bitmap logo using the X68000's GPU sprites produces a more professional appearance, and reading the IOCS version from the system globals lets the boot screen confirm which operating system revision is loaded. The IOCS call _B_VERSION returns a packed version number, which can be decoded into major and minor components before printing.

Sharing the finished work with the wider community usually involves posting to the X68000 Discord, writing a short post on a personal blog, or contributing patches to one of the open-source Human68k utility projects. The project diary on X68K.NET documents progress on related Nereid-X expansion board work, and many of the techniques described here overlap with the diagnostic routines being developed for that hardware. Cross-pollinating between projects helps the community grow, and getting feedback from other developers before publishing the final version often catches subtle bugs.

Australian retro computing has a strong sense of mateship, and sharing source code under permissive licences keeps the ecosystem healthy. Posting the final assembly source, the build script and the binary image together means other hobbyists can verify the code against their own machines and report any compatibility issues. The X68000 remains a niche platform, but the people who keep it alive tend to be generous with their time and their work, which makes boot screen projects like this one a pleasant way to contribute something useful back to the community.