Merging Human68k Disk Images into a Single Archive for the Sharp X68000

The Sharp X68000, a powerhouse home computer released by Sharp Corporation in the late 1980s, shipped with Human68k as its native operating system. Many software titles, development libraries, and demo scene productions for this platform were distributed across multiple floppy disks, forcing users to swap media every few minutes. Modern preservation efforts often need to consolidate these scattered disk sets into manageable bundles without losing the original structure. Building a small command-line utility that merges several Human68k disk images into a single archive simplifies archival, reduces file system clutter, and makes it easier to share complete software collections with other enthusiasts.

For hobbyists in Australia, the challenge of juggling multi-disk sets is compounded by shipping delays when ordering replacement parts or software from Japan, plus customs paperwork when importing older hardware across the Pacific. A custom merge utility written specifically for Human68k disk images offers a lightweight solution that respects the quirks of the platform while running comfortably on modest modern hardware. This guide walks through the format analysis, design choices, coding approach, and packaging steps needed to produce such a tool.

Human68k disk image formats and their quirks

Human68k reads physical floppy disks formatted with a 1.2 MB capacity in the standard MFM layout, and most preservation work revolves around capturing those disks as image files. The most common container formats encountered in the X68000 community are DIM, HDM, XDF, and D88. DIM stores a raw sector dump with a small header that records the protected mode flag and density. HDM is a variant of DIM that adds support for hard disk partitions, while XDF is a Sharp-specific extended format allowing up to 1.6 MB per floppy through non-standard sector sizes. D88 originated on the NEC PC-9800 series but is widely used by multi-platform emulators because it can describe multiple disks within a single file, each holding separate headers and track layouts.

When merging disk images into one archive, the tool must decide whether to preserve track-level granularity or simply concatenate the raw sectors. Preserving granularity gives users the ability to extract individual disks later, which matters when an archive contains a software bundle where one floppy might be a boot disk and another might hold data files. Losing the per-disk header information would render many Human68k installers unreadable, since programs like the standard SCSI manager or early version of Human68k itself check disk density bits at boot.

Designing the merger utility

A sensible architecture splits the project into three modules: a reader that parses the input format, a writer that emits the chosen archive container, and a command-line front-end that orchestrates the process. Readers can be implemented as separate functions per format, each returning a normalised structure containing the disk label, density flag, sector count, and raw track data. The writer module takes a list of these structures and produces a single output file with a master index.

For the command-line interface, two styles work well. The classic Human68k style passes options after the program name on a single line, such as MERGE -o ARCHIVE.DAT DISK1.DIM DISK2.HDM DISK3.D88. A more familiar style borrowed from Unix tools accepts flags in any order and reads a list of filenames from a response file when the line would exceed the 127-byte Human68k command buffer. Both approaches should be supported, since the Human68k \* wildcard is limited compared to what many developers are used to on modern systems.

Choosing a programming language depends on the target deployment. Writing the core in portable C with a small makefile allows the same source to compile on a modern Linux workstation for development and on a Human68k host for testing. A second build target can target the X68000's native GCC cross-compiler available through the NetBSD or Vincent Stahl-hosted toolchains, producing a standalone .X executable that runs directly under Human68k without any runtime support beyond the standard IOCS calls.

Choosing the development toolchain

Toolchain	Host platform	Output format	Typical use case
GCC 12.x cross-m68k	Linux, macOS, Windows (WSL)	ELF, flat binary	Cross-development from modern desktop
HASM.X (Human68k assembler)	X68000 native	.X executable	Native assembly on original hardware
GCC 2.95.3 retro	Human68k / NetBSD	.X executable	Authentic 1990s-era build environment
VBCC 0.9h	Cross-platform	Flat binary, .X	Compact code with m68k backend

Cross-compiling from a Linux box such as an Ubuntu 22.04 install or a Fedora workstation is the most practical path for most developers. The toolchain produces a small binary that can be transferred to an X68000 through an SCSI card, a MO drive, or a CF adapter that emulates an IDE device. Developers working in Sydney or Melbourne often keep a vintage machine on a shelf near their main workstation so they can flash a freshly compiled binary and immediately test it without leaving their desk.

Implementing the core merge logic

The heart of the utility is a loop that opens each input file, validates its header, allocates a buffer large enough to hold the largest disk in the set, and copies the track data into an in-memory image of the output archive. Because some Human68k disk images use non-standard sector numbering, the reader must respect the interleave table embedded in the XDF header. Failing to honour the interleave turns readable disks into scrambled noise when the tool later extracts them back to physical media.

A typical implementation reads the first sector of each input to detect the format magic number, then dispatches to the appropriate parser. For DIM files, the parser skips the 256-byte header, reads the density byte at offset 0, and confirms that the file length matches the expected sector count for that density. For HDM, an additional partition table at offset 0x100 must be preserved verbatim, since some Human68k boot loaders rely on the partition descriptor to find the system files. For D88, each disk entry has its own 688-byte header followed by variable-length track data, so the parser walks the entries sequentially until the file end marker is reached.

Once all disks are loaded into memory, the writer walks through them in user-specified order and emits a custom archive format. A practical format uses a 32-byte master header containing the magic value XMERGE01, the disk count, and a CRC32 of the index section. Each disk record in the index stores the original filename, format type, offset, size, and CRC32 of its payload. This layout keeps the archive forward-compatible, because new fields can be appended after the existing ones without breaking older readers.

Testing the merged archive under Human68k

Verification matters as much as the merge itself. The tool should produce a small companion program that can read the archive, extract individual disks to temporary files, and write them back to physical media through the Human68k disk and format commands. Running the extraction tool on the actual X68000 hardware confirms that the round-trip preserves every byte, which is essential when the archive contains protected software that checks disk serial numbers during installation.

A common pitfall involves the way Human68k handles file attributes. Some installers read the read-only flag from the directory entry to decide whether a file should be overwritten, so the extraction tool must restore attributes after writing each file. Another pitfall involves long filenames: Human68k supports up to 18.3-character names in its standard filesystem, but DIM archives sometimes carry longer labels for documentation purposes. The merge utility should truncate or hash these labels to fit the Human68k directory entry, and it should warn the user when truncation occurs.

Australian developers working late at night might find that the X68000's real-time clock disagrees with AEST during daylight saving transitions. Setting the clock before testing ensures that any timestamp-sensitive code in the installed software behaves consistently. Likewise, when sourcing disk images from Japanese collectors through Yahoo Auctions Japan or Mandarake, paying attention to the seller's description of disk condition helps avoid buying mouldy media that would otherwise fail to image cleanly.

Packaging, distribution, and community use

Distributing the finished utility benefits from bundling the source, a precompiled Human68k binary, a Linux command-line build, and a short README explaining the supported input formats. Hosting these files on a dedicated page linked from the main X68000 preservation hub ensures that the tool remains accessible even as forum posts age. The archive format itself should be documented openly so that other developers can write compatible extractors in Python or C# for users who only need to unpack disks without installing the original Human68k binary.

Australian hobbyists importing pre-built X68000 hardware or software for testing should familiarise themselves with the Customs Act 1901 and the relevant tariff codes for vintage computing equipment. The Department of Home Affairs generally allows personal imports under the low-value threshold, but items manufactured before 1985 sometimes require additional documentation to clear customs. Posting in local groups such as the Brisbane Retro Computing Meetup or the Melbourne-based Vintage Computer Festival Australasia mailing list helps newcomers find collaborators who have already navigated these procedures.

Anyone interested in expanding the project can fork the source from the central repository at https://x68k.net/ and add support for additional formats such as the less common HDI files used by some Sharp development tools. Pull requests that include both code and a small set of test images are always welcome, and contributors who document their format findings help the wider X68000 community keep the platform alive for another generation of curious users.