Comparing X68000 disk images with a Human68k command-line utility

An X68000 disk image is more than a folder of copied files. It preserves the exact arrangement of sectors that made a game, operating system, or application disk boot on original hardware. A purpose-built binary diff utility can reveal a changed byte, a reordered sector, a truncated image, or a wrapper header that was altered during conversion. For X68K.NET readers, that evidence supports careful restoration rather than guesswork.

Human68k provides a practical environment for such a tool: it runs on the X68000, accepts command-line arguments, and can redirect reports to a file. A small C program can compare two disk images without loading either file completely into memory. The result is useful on original hardware, in an emulator, and on a modern system running Human68k-compatible tooling.

The central design decision is whether a difference means “different byte” or “different disk sector”. Exact byte comparison is the dependable baseline because it works with raw images, header-bearing containers, and custom formats. Sector-aware reporting can then translate offsets into cylinder, head, and sector positions when the image geometry is known. Filesystem-level interpretation can be added later without weakening that core.

Australian collectors face a particular preservation problem: useful X68000 hardware, Japanese disks, and specialist adapters are often scarce and scattered between sellers in Sydney, Melbourne, Brisbane, and regional sheds. Purchases usually run through Australian-dollar marketplaces and couriers rather than a dense local shop network. The local scene is keen, and a working boot is often described as “all sorted”; an open, reproducible diff report helps that knowledge travel.

Choosing the comparison model

Choose the comparison model before writing code. A raw byte diff is simple, deterministic, and suitable for every format, but its output can look technical. Sector grouping makes reports easier to relate to a physical disk, while decoded comparison can describe changed files or directory entries. Each layer solves a different question and carries different assumptions.

Mode	Reported difference	Best use	Main limitation
Exact bytes	Offset, old byte and new byte	Finding every change	Can produce noisy output
Sector grouping	Sector position and changed bytes	Relating damage to a physical disk	Requires valid geometry
Decoded payload	Files, attributes and checksums	Explaining content changes	Needs format-specific code

For this project, make the exact byte comparison the canonical result and treat sector coordinates as optional context. The distinction between slide and negative scanning is a useful analogy: both operations may use similar equipment, yet comparing original captures and interpreting a transformed capture are separate tasks. A scan conversion artefact should not be confused with a change in the source bytes.

Decoded payload comparison should remain a separate mode, not a hidden assumption. Some X68000 disk containers include a header, creation timestamp, or sector encoding; those fields may differ even when the represented data is identical. Reporting the wrapper difference first keeps the utility honest and tells the user which layer needs further inspection.

Preparing a Human68k build environment

Build against a Human68k-capable C compiler and link the result as a DOS-style EXE loadable by Human68k. Cross-toolchain command names differ between established X68000 development packages, so use the target preset supplied with that toolchain rather than copying a generic Makefile from another 68000 platform. The important checks are the Human68k target, runtime library, and startup model.

Keep the source close to portable C90. Standard functions such as fopen, fseek, ftell, fread, fwrite, and printf are enough. Open images with the rb binary flag so the runtime never translates line endings or control characters. Use unsigned long for offsets where older compilers lack stdint.h, and retain the native 32-bit signed limit in mind for very large files.

Two fixed buffers of 32 or 64 KiB are enough for a streaming comparison. This avoids exhausting scarce X68000 memory and works just as well with a multi-megabyte floppy dump. Test the linked executable both on real hardware, if available, and in an emulator with Human68k command-line behaviour; an ELF binary or an emulator-only file API will not satisfy the target.

Defining the command-line interface

Give the utility a memorable DOS name and a simple contract. One workable syntax is HDIFF.EXE LEFT.IMG RIGHT.IMG [/LIMIT count]. With no options it reports every differing byte, the common length, each file’s size, and a final summary. /LIMIT caps displayed lines while the scan continues, allowing the total difference count to remain accurate even when hundreds of sectors differ.

Use a stable, machine-readable line such as 00012F80 5A A5 Z 0xA5: hexadecimal offset, old byte, new byte, and printable character notation. The offset is the most reliable field because it identifies the exact file position without assuming a container layout. A short context window can follow each change, but raw hexadecimal values should remain visible when a byte is non-printing.

The comparison loop is deliberately small. Read matching chunks, compare each byte, and advance the base offset by the chunk size:

while ((n1 = fread(a, 1, CHUNK_SIZE, fa)) != 0) {
    n2 = fread(b, 1, n1, fb);
    for (i = 0; i < n2; i++) {
        if (a[i] != b[i])
            report(base + i, a[i], b[i]);
    }
    base += n1;
}

After the loop, handle unequal sizes explicitly: report the extra range as EOF rather than inventing a byte value. Return 0 for identical files, 1 for differences, and 2 for a usage or I/O error. Human68k users can capture a report with HDIFF.EXE A.IMG B.IMG > DIFF.TXT and inspect it in an editor.

Translating offsets into disk locations

A raw floppy image makes byte offsets easy to convert into disk positions. With 512-byte sectors, 11 sectors per track, two heads, and 80 cylinders—a common X68000 2HD arrangement—the linear sector number is offset / 512. The byte within that sector is offset % 512; the one-based sector number is then (linear % 11) + 1.

The head follows the track and sector count: (linear / 11) % 2. The cylinder is linear / 22, with wrapping only relevant when the image exceeds 80 cylinders. This yields a report such as cylinder 12, head 1, sector 4, byte 128 for the corresponding raw offset. The image size for that arrangement is 901,120 bytes, a useful sanity check before interpreting results.

Do not apply those constants to an unknown container. A header-bearing image can place its first sector at a nonzero offset, while interleaved or transformed formats can use a different order. For those cases, keep the hexadecimal offset, expose the container’s payload base separately, and only map coordinates after validating the format. Endianness never alters the byte comparison itself.

Creating dependable disk images

Create a disciplined imaging workflow before trusting the diff. Make an image from the original disk, immediately copy that file, then acquire or create a second candidate under a different filename. Preserve the first image read-only, record the drive and software used, and compare the copies before any repair attempt. If the two acquisition passes differ, investigate the reading process before touching the disk.

Australian mains voltage deserves attention in the same workflow. Japanese X68000 equipment and many external drives were designed for 100 volts, while Australian supply is nominally 230–240 volts. Use a correctly rated, electrically safe step-down isolation transformer where appropriate; never rely on a travel adaptor or attempt improvised mains wiring. Imported equipment sold in Australian-dollar listings should have its voltage requirements checked before connection.

Summer heat, humidity, and dust also matter, particularly for external drives used in Perth, Brisbane, or Sydney. Stable temperatures and gentle airflow reduce rereads and inconsistent imaging. The X68000 case itself shows how tight airflow can become in the custom fan shroud build, a useful reminder that a computer can run perfectly while its peripherals are thermally stressed. Keep transport copies of irreplaceable media.

Testing edge cases and damaged media

Build a small regression set rather than testing only two identical files. Include byte-for-byte copies, a file with one flipped bit, an image with one sector rewritten, a truncated file, a file with extra trailing data, and two otherwise equal containers with different headers. Each case should produce a known offset, byte count, and exit status; identical files must produce no difference lines.

Exercise the limit option with both matching and mismatching data, test files at buffer boundaries, and confirm that redirects contain the complete summary. A sector-aware run should agree with the byte report at the shared offsets. If available, cross-check a result against a checksum or sector-level tool, but retain the raw diff because a checksum says that data changed while the diff says exactly where.

Damaged media can produce subtle evidence. A faint read may produce one changed cluster, while a retry may restore the original bytes; repeated imaging with retries can therefore look like a flaky image format. Record read errors and imaging settings alongside the report. That lets another Australian hobbyist distinguish physical decay, cable trouble, software re-encoding, and deliberate editing without relying on an unverified theory.

Preserving findings and sharing the result

Treat the report as evidence with context. An identical pair establishes that two files match, not that either disk is historically correct. A single changed byte may indicate accidental editing, while an entire changed sector can point to reformatting or copy protection. Header differences may reveal nothing more than metadata, and a changed image length can expose a failed conversion.

Archive the two filenames, file sizes, timestamps, acquisition details, command used, and full report together. A plain-text result is easy to search, quote, and publish on X68K.NET, where preserving the reasoning behind a repair is as valuable as preserving the final binary. The same report can accompany a mailing-list post or a community collection without asking every recipient to recreate the comparison.

Build HDIFF.EXE, test it with an untouched copy and one deliberately changed sector, then run it on the oldest pair in your collection. Save the report beside both images and share the method with an X68000 group so every repaired disk starts with documented, reproducible evidence.