Building a Human68k disk read speed benchmark

A small benchmark utility can reveal far more about an X68000 storage setup than a specification sheet. The same machine may show very different results when booting from a 5.25-inch floppy disk, an internal SCSI drive, a CompactFlash adapter, or a modern solid-state replacement. Human68k provides a useful environment for measuring these differences while keeping the program close to the hardware.

Creating a Human68k utility to benchmark disk read speeds also makes a valuable preservation tool. A result recorded today can help diagnose a failing drive, compare a repaired power supply, or document how a particular expansion board performs. The key is to measure consistently and explain exactly what the number represents.

Test target	What it measures	Main limitation	Useful comparison
Large sequential file	Practical DOS file-reading performance	Includes filesystem and cache effects	SCSI, CompactFlash and hard disk images
Small repeated reads	Overhead from calls and seek-like access	Less representative of loading large files	Utility and game loading behaviour
Raw or device-level sectors	Storage transfer path	Requires careful device handling	Media and controller performance
Cold-cache run	Approximate physical media response	Repeating it can be inconvenient	Floppy and mechanical hard disk health
Warm-cache run	Best-case filesystem response	Can hide slow media	Software launched repeatedly

Decide what the benchmark should measure

The first design choice is whether the utility measures a file, a device, or a complete application load. A file benchmark is usually the safest starting point. It can open a test file, read a known number of bytes, measure elapsed time, and report the transfer rate without risking directory structures or boot sectors.

A complete application load is useful for real-world comparisons, although it includes decompression, drawing, memory allocation and sound initialisation. A disk benchmark should therefore keep those activities outside the timed region. If the program reads 1 MB in 12 seconds, the result describes that read operation, not the time needed to display a game title screen.

The storage medium should be identified in the report. “SCSI drive” is too broad when an X68000 may be connected to an original 40 MB mechanism, a SCSI2SD board, or a CompactFlash device behind an adapter. Record the machine model, CPU accelerator, memory size, controller, media type, partition, Human68k version and compiler where possible.

Australian owners often assemble systems from several sources because local X68000 stock is limited. A drive bought through eBay Australia may arrive with unknown termination settings, while a Gumtree purchase in Sydney or Melbourne may include an untested external enclosure. Recording the complete configuration makes those results useful to other collectors.

Choose a repeatable test file

A test file should be considerably larger than the machine’s available disk cache. A 64 KB file may produce an impressive result on a cached second run while saying little about the storage mechanism. Larger files, such as 512 KB, 1 MB or 4 MB, give the benchmark more time to observe sustained transfer behaviour.

The file should contain ordinary data rather than a sparse placeholder or a file created by a tool that uses unusual filesystem features. A utility can generate a pattern in memory and write it to disk before testing, or the distribution can include a prepared file. Keeping the file size fixed is important when comparing a floppy image with a hard disk partition.

Read the file in blocks that fit comfortably in available memory. Block sizes of 1 KB, 4 KB, 8 KB and 16 KB can expose different overheads. Very small blocks increase the number of DOS calls, while very large blocks may reduce call overhead and produce a result that is less representative of older software.

A practical benchmark can offer two modes: a standard sequential test and a block-size test. The standard mode makes comparisons simple. The second mode helps explain why two utilities, or two versions of the same utility, report different speeds even when they use the same disk.

Build around Human68k conventions

The program should use the compiler’s normal Human68k file functions for its first implementation. Functions corresponding to open, read, close and file positioning are easier to port than direct hardware access, and they allow the benchmark to run across floppy, SCSI and other devices presented through the operating system.

Open the file in read-only mode, allocate a buffer, and keep reading until the requested byte count has been reached. The loop must handle short reads correctly. A read returning fewer bytes than requested is not necessarily an error, and treating it as a completed test can inflate the reported speed.

A simplified structure looks like this:

start = timer_ticks();

while (total < test_size) {
    wanted = block_size;
    if (test_size - total < wanted)
        wanted = test_size - total;

    got = read(handle, buffer, wanted);
    if (got <= 0)
        report_error();

    total += got;
}

elapsed = timer_ticks() - start;

The exact function names and timer interface depend on the compiler and library selected for the project. Older X68000 development environments may differ in naming, integer sizes and available headers, so isolate platform-specific code in a small module. The main benchmark logic should remain easy to inspect and rebuild.

Measure time without pretending to have laboratory precision

A speed result is calculated from bytes read divided by elapsed time. Convert the result to bytes per second, kilobytes per second and, if useful, megabytes per second. Define the units clearly: decimal kilobytes use 1,000 bytes, while binary kibibytes use 1,024. Retrocomputing reports often mix these conventions.

The timer resolution matters. If the clock advances only every few hundred milliseconds, a short test will produce coarse and unstable results. Use a test size large enough for several timer intervals, then repeat the run three to five times. Report the individual values and the median, rather than presenting a single unusually fast or slow run.

A warm-cache result can be detected by comparing the first run with later runs. If the second pass is dramatically faster, the operating system or drive controller is serving data from memory. That does not make the result invalid; it simply describes cached file access. Label it clearly as a warm run.

For a cold-cache approximation, reboot between tests or use a file larger than the available cache. Do not claim that closing and reopening a file clears every layer of caching. The drive, controller, RAM expansion and operating system may each retain data. A careful utility should report the test procedure instead of pretending it has isolated the physical disk.

Account for floppy, SCSI and modern replacements

Floppy drives need special treatment because their access time is dominated by seeking, rotational delay and motor behaviour. A sequential read may look reasonable once the head is positioned, while a small-file test can be much slower. Test files should be large enough to avoid making one directory lookup the main event.

Mechanical SCSI disks reveal another pattern. Transfer speed may remain steady during a short test, then fall as the head moves towards slower outer or inner areas of the platter. Running the benchmark from several files placed at different locations can expose this variation, although the utility should describe the test as a file-position sample rather than a universal drive rating.

Solid-state replacements usually remove seek delays and may produce results limited by the X68000’s controller or software overhead. A CompactFlash card can therefore appear much faster than an original hard disk without reaching the card’s advertised modern speed. This is expected: the benchmark measures the complete X68000 storage path.

Local power conditions deserve a note in hardware records. An original Japanese X68000 power supply is designed for Japan’s nominal 100 V environment, whereas Australian mains is nominally 230 V. A proper step-down transformer, a correctly repaired supply or a suitable replacement is essential before any long test. An unstable supply can cause errors that look like poor disk performance, and repeated testing can place extra stress on ageing components.

Make the output useful to people

The screen should show enough information to make a result meaningful when copied into a forum post or a project log. Include the file size, block size, number of passes, elapsed time, bytes per second, and whether the run is marked cold, warm or unspecified. Also print a short platform description supplied by the user.

A compact output might look like this:

H68KREAD 0.10
File: TEST1.BIN
Size: 1048576 bytes
Block: 8192 bytes
Pass 1: 18.42 s  56.97 KiB/s
Pass 2:  7.11 s 147.66 KiB/s
Median: 12.77 s  82.20 KiB/s
Cache note: later pass may be warm

Avoid decorative graphics that consume memory or distract from the measurement. Text mode is ideal for floppy-based systems and serial capture. If a graphical front end is added later, keep the measurement engine separate. The X68000 palette guide is a useful reference when designing colour choices for a readable graphical display.

A log option is particularly valuable. The utility can append results to a text file, although writing the log during the timed read would contaminate the measurement. Store the result in memory and write it after the test completes. Use plain ASCII or a conservative Japanese-compatible encoding so the file can be read on another computer.

Validate results against real software

A benchmark becomes more credible when its numbers agree with practical observations. Compare the measured result with the time needed to copy a large file, load a disk image, or start a known application. These activities include other work, so they should not match exactly, but they can reveal a faulty benchmark loop or a misleading cache assumption.

Check file integrity before trusting a fast result. A read function that stops at a zero byte, ignores an error or uses the wrong file length may report excellent performance while reading only part of the test file. Add an optional checksum or pattern verification pass outside the timed section. This confirms that every byte was received without adding verification cost to the speed figure.

Run the same test after changing one variable at a time. Keep the machine, cable, termination, partition and test file unchanged when comparing block sizes. When comparing storage devices, record whether the benchmark was booted from floppy, hard disk or another device. Booting from a different environment can alter drivers and cache behaviour.

Project notes and dated observations can be preserved in the X68K.NET diary, giving future readers context for a result that may otherwise look mysterious. A benchmark log is especially useful when a drive gradually slows, a power supply repair changes stability, or a replacement controller is installed.

Share a durable benchmark record

The finished utility should include source code, a compiled executable, usage instructions and a short explanation of its limitations. State the compiler, required libraries, expected Human68k version and minimum memory. If direct device access is unsupported, say so plainly and describe the program as a file-level benchmark.

A release archive can include a sample test file, example output and a results template. Suggested fields include machine model, accelerator, RAM, storage controller, media, partition, block size, file size, pass number, elapsed time and cache state. This turns scattered enthusiast measurements into a dataset that can be compared years later.

For Australian users, practical documentation should mention 240 V power arrangements, local availability of adapters and the realities of importing Japanese hardware. A collector in Brisbane may test a CompactFlash setup assembled from imported parts, while someone in Adelaide or Perth may rely on second-hand listings and mail-order repairs. Clear records help separate storage performance from a faulty adapter, unsuitable transformer or damaged cable.

Build the utility, run it across the drives in your collection, and publish the raw results alongside the summary. A small Human68k program with transparent timing and repeatable test conditions can support repairs, preservation work and future hardware projects long after the original benchmark machine has changed.