Crafting a Human68k Benchmark Tool for CPU and Memory Analysis

The Sharp X68000 occupies a special place in Japanese computing history, and a small but devoted community keeps the platform alive through restoration, expansion hardware, and original software development. Writing a native utility for Human68k offers a satisfying way to combine assembly programming with hands-on hardware evaluation, especially for enthusiasts who want to compare accelerators, RAM upgrades, and the many aftermarket CPU boards produced over the years.

Building a benchmark from scratch on such a legacy system forces the developer to think carefully about cycle counts, memory wait states, and the quirks of the Motorola 68000 family. Whether you are sitting at a desk in Adelaide with a CZ-601BE monitor or working remotely from Perth with a stack of SCSI peripherals, the principles remain the same. A well-designed tool can reveal how different configurations actually perform in practice, rather than relying on the often optimistic claims printed on period advertisements.

Planning the Benchmark Architecture

Before writing a single line of code, it pays to sketch out what the utility should actually measure. The classic X68000 base configuration pairs a Motorola 68000 CPU running at 10 MHz with wait states inserted on memory accesses, depending on the video screen mode and the region of RAM being touched. Later machines moved to a 68030, 68040, or 68060, and accelerator boards such as the Nereid-X push performance much further. A benchmark suite should account for integer throughput, memory bandwidth, and ideally some measure of cache and bus behaviour where applicable.

A practical starting point is to separate the tool into three logical modules: a CPU test loop, a memory test loop, and a Human68k command shell wrapper that handles command line parsing and result output. The CPU module can implement compact loops using instructions like ADD, MUL, DIV, and DBcc, while the memory module can move blocks of varying sizes to expose how the system handles bursts versus single-word transfers. Keeping the modular structure also makes it easier to add tests for the 68881/68882 floating point coprocessor on machines that support it.

For timing, the X68000 offers a straightforward path through the MFP timer registers. The 68901 chip provides timer D, which is commonly used by Human68k itself for the system clock. By reading the timer before and after a benchmark loop runs a known number of iterations, the tool can calculate elapsed microseconds with reasonable accuracy. Some developers prefer the vsync counter for longer tests, but the MFP approach works well for short measurement windows where interrupt latency would otherwise contaminate the numbers.

Choosing the Right CPU Performance Metrics

Raw MIPS ratings tell only part of the story. The 68000 executes most instructions in a known number of cycles, but the effective throughput depends on instruction mix, branch behaviour on these older cores, and the cost of memory fetches. A balanced benchmark should exercise simple register operations, multiply and divide sequences, and memory-to-register moves that stress the data path without becoming dominated by bus wait states.

Dhrystone remains a popular synthetic test, and adapting the public domain version 2.1 source to Human68k is a familiar project for Australian hobbyists who grew up reading imported computing magazines at the local library in Brisbane or Melbourne. Translating the C source into hand-tuned assembly yields tighter numbers, but for cross-platform comparisons keeping the C version is more useful. The resulting Dhrystone score can be divided by the original VAX 11/750 reference number to produce DMIPS, a metric that still appears in retro computing discussions today.

Integer-only benchmarks ignore the contribution of the 68881/68882 floating point unit, which is optional on the original X68000 but present on many later models. A simple loop that performs FMUL and FDIV operations on double precision values will measure coprocessor throughput separately, allowing owners of accelerator boards to see exactly how much their FPU has improved. Remember that the 68882 is roughly twice as fast as the 68881 at most operations, and that some aftermarket boards skip the FPU entirely to reduce cost.

Measuring Memory Throughput on the X68000

Memory performance is where the X68000 becomes particularly interesting. The system has multiple regions of RAM with different wait state characteristics: text VRAM, graphics VRAM, the main system RAM region used by Human68k, and any expansion memory on accelerator boards. The base 1 MB of system RAM runs without wait states on most configurations, but the upper regions may add cycles depending on the memory controller design.

A useful memory benchmark reads and writes blocks ranging from 16 bytes up to 64 KB, reporting throughput in megabytes per second for each block size. The smaller sizes expose the cost of instruction fetch and loop setup, whereas the larger sizes approach the theoretical bus bandwidth. For a stock 68000 at 10 MHz, expect around 9 to 10 MB/s for sequential reads from fast RAM, dropping significantly when the test touches VRAM regions during active display periods.

Practical experimentation at Sydney retro meetups has shown that some aftermarket memory boards actually slow down under certain access patterns, an effect invisible to simple throughput averages. Including a non-sequential access pattern in the test, where addresses jump pseudo-randomly within a buffer, surfaces this kind of behaviour. Combined with sequential tests, it produces a more honest picture of how the machine will feel under real workloads like loading a large image into pixel VRAM or processing a long document through a word processor.

Building the Human68k Command Line Interface

Human68k provides a DOS-compatible command structure, so wrapping the benchmark in a CLI tool means supplying a small startup routine that parses the command tail and dispatches to the chosen test module. The startup code needs to set up the stack, save the original command tail, and return an exit code that Human68k recognises through the value passed back in register d0. Most existing utilities follow this pattern, and the Human68k Programmer's Guide documents the conventions in detail.

Output can go to the console using the standard IOCS calls, or to a file using Human68k file handles. Writing results to a text file makes it easier to compare runs over time, especially when sharing findings with other enthusiasts at events in Adelaide or posting to local bulletin boards. A typical output format includes the machine configuration, test parameters, raw cycle counts, and derived metrics such as MB/s or DMIPS. Including a timestamp and the Human68k version number helps when revisiting old logs.

Error handling deserves attention too. The benchmark should detect missing arguments, report invalid test numbers, and gracefully handle cases where the requested memory size exceeds available RAM. Some accelerator boards present their expansion memory in unusual configurations, and the benchmark should fail cleanly rather than crash if it cannot allocate the requested region. Returning a non-zero exit code allows the benchmark to be used inside batch files for automated comparison runs.

Interpreting Results and Comparing Hardware Revisions

Numbers on their own mean little without context. A practical benchmark tool prints not only the raw metrics but also a brief reference table showing expected values for stock configurations: the original 68000 at 10 MHz, the 68030 at 16 MHz in the XVI, and the 68030 at 25 MHz in later accelerators. Comparing your actual numbers against this baseline reveals whether the machine is performing as designed or whether some hidden wait state is dragging it down.

In Australian workshops, where heat and dust take a steady toll on vintage hardware, a benchmark often serves as a quick diagnostic. If the memory throughput is well below the expected value, the technician knows to reseat SIMMs, inspect for leaky battery damage near the RAM sockets, or check for cold solder joints on the memory controller. The same tool that compares accelerators can therefore help keep an aging machine running reliably through another decade of use.

For owners of FPGA projects and modern replication hardware, the benchmark becomes a way to validate that the new implementation behaves like the original. Comparing results against a known good CZ-652CE running the same test confirms whether cycle accuracy is preserved across different memory subsystems. The ongoing FPGA sound replication project on the site touches on similar questions for audio, and benchmark numbers help complete the picture by quantifying how the rest of the system responds.

Once you have a working benchmark binary on a floppy or compact flash card, the natural next step is to share results with the wider community. Posting findings to the X68K project diary invites other enthusiasts to run the same tool on their hardware and contribute comparable numbers, building a small but valuable dataset of real-world performance across the entire X68000 family.