Building a Human68k multi-image virtual drive utility

The Sharp X68000 made good use of its two floppy drives, yet owners soon wanted more software than a pair of disks could hold. Modern emulators can attach several image files, but an enthusiast running original Human68k needs a way to expose those files as usable drives on the machine itself. A small native utility could turn disk containers into virtual devices while keeping the familiar Human68k command environment.

The goal is not to imitate a modern operating system’s folder tree. It is to provide dependable block storage for the tools that matter: game loaders, MIDI editors, compilers and utilities written for X68000 software. The design should preserve disk geometry, enforce sensible write rules and recover cleanly when an image is missing or damaged. It should also leave ordinary A: and B: floppy operation untouched.

Development is easiest when emulator testing and physical hardware are treated as equal partners. Emulator environments can expose failures quickly, while a real Sharp machine reveals BIOS assumptions, timing behaviour and controller quirks that software simulation may hide. For Australian collectors in Sydney, Melbourne and Brisbane, shipping a heavily modified system across the country adds cost and risk, so remote testing and reproducible release packages are especially useful.

This project begins with the storage path from Human68k to BIOS, then moves through image validation, device mapping, command design and testing. The finished utility should be usable without a mouse, keyboard shortcuts or obscure control codes. Its source, sample configuration and test images would make it easier for other hobbyists to maintain the X68000 platform for years to come.

Mounting approach	Where image mapping occurs	Multiple image support	Persistence	Main limitation
Emulator bridge	Host emulator	Extensive	Image files on the host	Does not test native hardware
Virtual disk controller	Controller firmware	Depends on hardware	Controller-backed media	Requires compatible hardware
BIOS-level dispatcher	Patched BIOS or service layer	Several devices	Local image files	Demands low-level compatibility work
Command wrapper	Human68k application layer	Only existing devices	No new storage by itself	Cannot create a block device

Selecting the correct integration layer

Human68k does not provide a universal hot-plug interface for disk containers. Applications ultimately request blocks through BIOS and controller-specific routines, so a command that merely renames a drive cannot create new storage. The utility needs a bridge beneath Human68k: an emulator service, a compatible virtual disk controller, or a carefully tested BIOS dispatcher.

Those routes differ considerably. An unmodified X68000 without suitable controller hardware can support only the drives its existing BIOS exposes. A RAM disk can provide temporary storage, but it does not solve the need for persistent images. This boundary should be settled before designing menus, commands or a graphical interface.

A practical design separates the native front end from a narrow block-device protocol. Requests can cover listing images, mounting, reading, writing, flushing and status reporting. The utility then acts as a client, while the bridge or controller verifies media geometry and performs each sector operation.

Handling images and filesystems

Disk containers commonly encountered in the X68000 community include .d88, .dim and raw sector images. The first two formats can preserve information such as media type and track layout, while a raw image requires explicit geometry. A useful utility should normalise these differences behind one internal representation rather than making every command format-aware.

A disk container and its filesystem are separate layers. The container describes sectors, tracks and sides; the filesystem normally uses FAT12 or FAT16 structures such as a boot sector, allocation tables and directories. The utility should mount a prepared image without unnecessarily rewriting its filesystem, while allowing a formatted image to be created when explicit permission is given.

An image catalogue can record the source path, format, sector size, geometry and mount order. During startup, the utility should reject truncated files, impossible geometry and inconsistent metadata. Checksums stored beside release images provide a second way to detect accidental corruption. A clear error should identify the affected image and field rather than leaving the user with a generic read failure.

Mapping virtual drives safely

Human68k normally assigns letters to physical and configured devices. A mounting utility should inspect current assignments, reserve letters already in use and give each virtual disk a predictable identifier. Fixed rules are preferable to silently choosing the next free letter, since software may contain drive-specific paths or expect a particular arrangement.

Read-only mounting should be the default. It protects an original disk image from accidental modification and makes it practical to distribute preserved software collections. When editing is required, copy-on-write operation can record changes in a separate delta file while leaving the master image untouched. A full writable mount should require an explicit option and a visible warning.

Caching needs predictable boundaries. Reads may use a small buffer, but writes must reach stable storage before a close or flush command reports success. Open files and the current directory must also prevent unsafe removal of a mounted image. The mount state should persist across program exits, while a failure during dismount must leave the affected image marked rather than pretending the operation succeeded.

Building the Human68k interface

A sensible command vocabulary could include MOUNT, UNMOUNT, LIST and INFO. These would be proposed Human68k commands rather than claims about existing operating-system syntax. Each command should support a compact form for scripts and a readable response for interactive use. Drive letters, image paths and status messages must remain understandable without reference to a separate desktop computer.

The implementation may combine a resident dispatcher with a front-end program. The dispatcher answers block requests while the front end performs validation and presents the catalogue. Development should use a 68000 compiler and assembler that match Human68k’s calling conventions, memory model and executable format. Testing with a clean memory configuration can expose assumptions hidden by expanded or upgraded systems.

Error reporting should state what failed, whether the operation changed anything and what the user can do next. Examples include a missing image, a locked drive, invalid geometry and insufficient memory. Return codes can remain machine-friendly, but the displayed text should explain the problem in plain English. Consistent wording also makes later bug reports easier to compare across different X68000 configurations.

Testing across emulators and real hardware

Automated tests should mount images with different sector sizes, capacities and allocation patterns, then read every sector and compare the results with known hashes. Write tests can fill files, delete directories and verify changes after a reboot. Damaged-image tests should cover missing headers, truncated data and deliberately inconsistent geometry without allowing one fault to crash the whole utility.

Physical testing remains essential. The utility should operate alongside real floppy drives, a conventional hard disk and any supported SCSI or SASI equipment. For dependable timestamps, the X68000.NET battery-backed real-time clock project provides a useful reference for maintaining accurate event logs across power cycles.

Australia’s 230-volt mains supply also deserves attention when bringing Japanese hardware into service. Many X68000 power supplies are designed for 100 volts, so the label must be checked before connection and an appropriately rated isolation transformer may be required. Any powered accessory sold locally must meet applicable electrical safety and RCM requirements. Stress tests should then include repeated mounts, full disks, interrupted writes and controller resets.

Documenting, licensing and preserving access

Release documentation should cover supported image formats, drive-letter rules, configuration syntax and known hardware combinations. A small prepared image can demonstrate mounting without distributing copyrighted software. Source code needs a clear licence, while sample files should carry separate permissions. Build notes should identify the compiler, assembler and library versions needed to reproduce the executable.

Image preservation involves rights as well as storage. The Australian Copyright Act 1968 and individual software licences can restrict the copying and redistribution of commercial X68000 programs. A utility can mount lawfully obtained images without authorising their distribution. Projects offering paid hardware bundles must also provide clear disclosures consistent with Australian consumer law and avoid implying that preservation transfers ownership of original software.

Stable documentation and community references help keep small utilities alive. Broader software, emulation and hardware material from Gina Kaydaniel’s site can complement local testing by revealing established conventions and useful compatibility information. Where possible, maintainers should record failed approaches alongside successful ones so future changes do not repeat the same low-level investigation.

Releasing the utility and inviting field tests

The first public release should contain a native executable, source code, sample configuration, licence text and a short verification procedure. Version numbers should identify both the utility and the minimum bridge or controller revision. Test reports can then distinguish a filesystem problem from an image-format issue or a hardware incompatibility.

Australian collectors commonly search second-hand X68000 equipment through specialist forums and online marketplaces, with prices quoted in Australian dollars and items sent using Australia Post or commercial couriers. Releases should therefore use internationally understandable formats, avoid region-specific path assumptions and provide compact archives. Local meetups remain useful for comparing media geometry and testing images across different controller combinations.

Start with a legally obtained, read-only disk image, record the utility version and published drive map, and repeat the test after a clean restart. Share confirmed combinations, reproducible failures and patch notes through the X68000 hobbyist community. A successful release is one that another owner can install, verify and extend without relying on undocumented knowledge from its original developer.