Building a Human68k Disk Formatter with Adjustable Interleave

The Sharp X68000 remains one of the most distinctive home computers ever made, and its Human68k operating system offers a remarkably direct interface to the hardware. Enthusiasts who keep these machines running often need to prepare media in ways that the stock FORMAT.EXE cannot accommodate. This is especially true when a particular game or development workflow benefits from a non-standard sector layout on the floppy drive.

Sector interleave is the silent variable behind many performance quirks on vintage hardware. When sectors are numbered sequentially around the track, a fast controller can outrun the host computer, and the next sector requested rotates past before the drive is ready. By inserting gaps between logically adjacent sectors, the formatter can give the machine time to catch up. The X68000's floppy subsystem is more capable than most of its contemporaries, yet the default formatting tool ships with conservative choices.

This article walks through the design and construction of a small Human68k utility that lets the operator select any interleave factor supported by the drive. It targets the typical 2HD (1.2 MB) and 2DD (640 KB) media that the X68000 uses, and it keeps the command-line simple enough to drop into a bootable system disk. The result is a tool that an enthusiast in Brisbane or Perth can use to tune a disk for a specific application without resorting to a soldering iron or a second computer.

The work draws on the same spirit of preservation that drives the broader X68000 community. It complements hardware projects documented elsewhere on this site, including the upgrading the X68000 RAM from 2MB to 4MB using SIP modules page, and it treats software preservation as an ongoing task rather than a finished product.

Understanding Human68k Disk Geometry and File System

Human68k uses a proprietary file system loosely modeled on MS-DOS FAT but diverges in the way it records boot sectors, directory entries, and cluster allocation. The disk is divided into tracks, and each track contains a fixed number of sectors. On a 2HD disk, the geometry is typically 77 cylinders, 2 heads, 8 sectors per track, giving the familiar 1232 KB raw capacity. On a 2DD disk, the geometry is usually 80 cylinders, 2 heads, 8 sectors, for a raw total of 1280 KB. The formatter must respect these physical limits while leaving room for the boot sector.

The boot sector on a Human68k disk carries the OEM signature and the initial program loader that reads the command processor. It occupies the first sector of the first track and is duplicated on the second side for redundancy. Any utility that formats a disk must write a valid boot sector, or the system will refuse to boot from the media. The utility described here reuses a known-good boot sector image embedded in the binary.

Beyond the boot sector, Human68k expects a small system area and then the user data region. The exact layout is well documented in the original reference manual and in disassemblies of FORMAT.EXE. When designing a custom formatter, it helps to keep a reference disk image and compare the output of the new tool against it sector by sector. Australian collectors who participate in the Melbourne Retro Computing Club's swap meets regularly share such reference images on USB sticks or via the local BBS scene.

The Role of Interleave in Floppy Performance

Interleave determines the logical order of sectors on a track. With an interleave of 1:1, sectors are numbered 1 through 8 around the track. With an interleave of 2:1, the sequence becomes 1, 5, 2, 6, 3, 7, 4, 8. With 3:1, the sequence is 1, 4, 7, 2, 5, 8, 3, 6. The right choice depends on the rotational speed of the drive, the time the controller takes to process a sector, and the speed of the host CPU.

The X68000's built-in floppy controller operates at the standard 300 RPM for 2HD media. The host CPU is fast enough to read sequential sectors without the controller missing a beat in many cases. Some software loads many small files in succession, however, and the directory access patterns can starve the controller if the interleave is set to 1:1. Conversely, software that streams large sequential reads may benefit from 1:1 because there is no rotational delay between successive sectors.

Interleave	Best Use Case	Trade-off
1:1	Sequential reads, large file streaming	Higher CPU overhead for directory access
2:1	Mixed workloads, game loading with many small files	Balanced performance
3:1	Heavy directory traversal on slower drives	Slower sequential throughput
4:1	Very old drives or degraded media	Noticeable delay during large transfers

The formatter utility should let the user pick any of these values at the command line. A reasonable range is 1:1 through 4:1, with 1:1 as the default for users who want the original layout. The choice of interleave does not affect the total capacity of the disk, only the logical ordering of sectors on each track. Changing the interleave after the disk has been used is destructive, because the sector numbers themselves change, which means any existing files would point to the wrong physical sectors.

Choosing a Development Toolchain for Human68k

Several compilers and assemblers target the X68000 and Human68k. The classic choice is the SHARP C compiler that shipped with the machine, which produces compact binaries and understands the Human68k calling convention. Modern alternatives include GCC ports, which produce 32-bit code but can target the 68000 CPU when configured correctly. For a low-level disk formatter, hand-written 68000 assembly is often the simplest path, because the routine must interact directly with the floppy controller registers at fixed memory addresses.

The development environment does not need to be elaborate. A cross-compiler on a modern PC produces a Human68k .R file transferred via compact flash, SCSI, or a null-modem cable. Australian enthusiasts who run a Linux workstation in a home workshop can use make to rebuild the utility from a tarball that includes both source and prebuilt binary. The source should be written to be assembled with HAS.X, the Human68k assembler that comes with the original development kit, so that no extra dependencies are introduced.

A small amount of C glue around an assembly core is a practical compromise. The C code handles argument parsing and user prompts, while the assembly code issues the floppy controller commands and waits for the interrupts that signal completion. This division keeps the most timing-sensitive parts in assembly, where cycle counts are explicit, while leaving the rest of the program readable and easy to modify. Enthusiasts who learned their craft on the X68000 in the late 1980s often wrote code in exactly this style, and it remains the most reliable way to talk to the floppy subsystem.

Designing the Utility Interface and Workflow

The utility should present a single command-line interface, in keeping with Human68k conventions. A typical invocation might look like XFORMAT /D:1 /I:2 /V:MYGAME, where /D selects the drive, /I sets the interleave, and /V provides a volume label. The command should print a brief summary of the parameters, ask for confirmation, and then proceed. There is no need for a full-screen interface, because Human68k is a command-line operating system and a TUI would only add complexity.

During formatting, the utility should display a progress indicator. The X68000's text mode can scroll characters smoothly, and a simple rotating character or a percentage counter is sufficient. The user can watch the format progress and abort if a drive malfunction becomes obvious. After the format completes, the utility should write the boot sector and the system area, then verify a percentage of sectors to confirm that the media is readable. A full verify doubles the time taken and is rarely necessary for a known-good drive.

Error handling should be straightforward: if the controller reports an error, the utility prints the status register contents and exits with a non-zero return code. The utility should refuse to format the system drive, because formatting the boot disk while running from it would be catastrophic. A check against the default drive number catches the common mistake.

Implementing the Low-Level Formatting Routine

The floppy controller on the X68000 occupies memory-mapped registers similar to the NEC µPD72065. To format a track, the host writes the format command byte, sector size, sectors per track, gap length, and a buffer of desired sector numbers. The controller reads the sector numbers from memory and writes them to the track in order.

The assembly routine must build a sector number table in memory before issuing the format command. The table is an array of bytes, one per sector, where each byte is the logical sector ID. For interleave 1:1, the table is 1, 2, 3, 4, 5, 6, 7, 8. For interleave 2:1, the table is 1, 5, 2, 6, 3, 7, 4, 8. The pattern generalises to any interleave by stepping through with a stride of N. A simple loop computes the table in place, which keeps the code compact.

After the format command completes, the routine waits for an interrupt or polls the controller status register to confirm completion. The Human68k kernel provides a hook for floppy interrupt handling, and the formatter can either install its own handler or rely on the default one. Once the format completes, the routine reads back the sector IDs from the track to verify that they match the table, which catches cases where the drive head is dirty or the media is marginal. A single bad sector out of several hundred is enough to mark the track as suspect, and the utility prints a warning before continuing.

Testing, Pitfalls, and Hardware Considerations

Testing a disk formatter is straightforward but requires patience. A clean drive, a known-good disk, and a method for reading back the formatted image are the basic ingredients. The verification step inside the formatter catches most problems, but a sector editor running on the X68000 itself provides the strongest evidence. The author of this utility wrote a small Human68k program that reads the first track of the formatted disk and prints the sector order, which confirmed that the interleave was applied as requested. Such tools are easy to share via the Australian retro computing mailing lists.

Pitfalls include drives that need head cleaning, media past its useful life, and power supply issues that cause intermittent errors. The X68000 community in Sydney and Melbourne has long experience diagnosing these problems, and swapping known-good parts between machines is the standard diagnostic method. A formatter that produces inconsistent results on one machine but works perfectly on another usually points to a hardware fault rather than a software bug. The utility should make this distinction easy by reporting the controller status register on error, which lets the operator decide whether to clean the head or investigate further.

The formatter is small enough to fit on a single 2DD floppy alongside a few other diagnostic tools. Combined with a bootable system disk image, the operator can boot from known-good media, insert the target disk, and run the utility without loading Human68k from it. This workflow matches original Japanese developer practices and keeps the tool within reach for home workshops or community events.

The source code for the utility described above is published on this site, and the prebuilt binary is available for download alongside the memory expansion notes. Enthusiasts who build the formatter themselves are encouraged to share their results, report any bugs, and contribute patches through the contact page. Drop a line through the site if you would like a copy of the reference disks, or if you have formatted media to contribute to the collection.