Understanding the X68000 Floppy Controller for Custom Disk Formats
The Sharp X68000’s floppy controller sits between two very different worlds. At the physical level, it deals with magnetic transitions, track positioning, head selection, sector IDs, gaps and CRC checks. At the software level, it presents a block device that the Human68k operating system can format, read and write. Custom disk formats become much easier to understand once those layers are kept separate.
This matters because an X68000 disk can be unusual without being mysterious. A game may use a non-standard sector arrangement, a copy-protection scheme may deliberately create unreadable areas, or a utility may place data outside the normal file system. For Australian owners working with ageing Japanese hardware, a sound understanding of the FDC helps avoid sacrificing rare media while experimenting with formats, repairs and modern imaging tools.
What the Floppy Controller Actually Controls
The floppy disk controller, or FDC, is responsible for translating commands from the X68000’s CPU into operations performed by the drive. Typical commands include seeking to a track, selecting a head, reading an address mark, reading sectors, writing sectors, formatting a track and checking drive status. The controller also monitors conditions such as write protection, index pulses, lost data and CRC errors.
The FDC does not understand files in the way Human68k does. It knows about cylinders, heads, sectors and byte counts. A file system driver decides that a particular collection of sectors represents a directory, allocation bitmap or executable file. This distinction explains why a disk can be perfectly readable at the controller level yet unusable to the operating system, or appear damaged to a file utility while still containing recoverable raw data.
Data is normally transferred through a programmed I/O or DMA path, depending on the operation and system software. The controller places bytes into a buffer while the CPU or DMA hardware moves them into memory. Timing is important: the drive motor, disk rotation and data separator must remain within tolerances, and a slow response can cause an overrun even when the magnetic recording itself is healthy.
From Magnetic Flux to Useful Bytes
A floppy disk does not store a neat row of bytes. It stores magnetic transitions arranged as encoded bit cells. The drive head converts those transitions into a stream, while the electronics recover clocking and data. MFM encoding is central to the X68000’s normal floppy operation, and the controller recognises address marks, synchronisation patterns, sector headers and data fields within that stream.
A formatted track contains more than payload data. It includes an index gap, preambles, ID address marks, cylinder and head numbers, sector numbers, size codes, CRC values, data address marks, data fields and inter-sector gaps. The gaps give the controller time to lose and regain synchronisation. Changing their lengths can affect how many sectors fit on a track and how reliably a particular drive can read them.
This is why a “custom format” may mean several different things. It could use ordinary sectors with an unconventional order, different sector sizes, unusual track numbering or a special file system. It could also involve deliberately malformed headers, duplicate sector IDs, missing address marks or raw track patterns that a standard read command cannot interpret. A normal disk image format may preserve the first category well but lose important information from the second.
The Normal X68000 Disk Geometry
The familiar X68000 floppy format is usually associated with 5.25-inch, high-density media and a capacity around 1.2 MB. A common layout uses 77 cylinders, two heads and eight sectors per track, with 1,024 bytes per sector. That arithmetic gives 77 × 2 × 8 × 1,024 bytes, or 1,261,568 bytes before any operating-system-level interpretation.
The exact values should still be treated as parameters rather than assumptions. Different software may use alternate sector numbering, interleave or track layouts. A utility disk, game disk and development disk can all occupy the same physical media while expecting different logical structures. Some titles also use extra information in boot tracks or reserve sectors that ordinary formatting tools would regard as unused.
| Layer | What it describes | Typical X68000 concern | What can go wrong |
|---|---|---|---|
| Media | Disk type, density and magnetic coating | 5.25-inch Japanese high-density media | Weak coating, incorrect media or damaged jacket |
| Track | Cylinder, head and physical recording area | Usually 77 cylinders and two sides | Seek errors, misalignment or marginal tracks |
| Sector ID | Cylinder, head, sector number and size | Often eight 1,024-byte sectors per track | Non-standard IDs or duplicate sector numbers |
| Data field | User bytes plus CRC | File-system blocks or custom payloads | Bad CRC, missing marks or altered bytes |
| File system | Directories, allocation and boot code | Human68k-compatible disk structures | Valid sectors but unreadable volume |
| Raw track format | Exact transition and gap pattern | Copy protection or unusual utilities | Lost by sector-only imaging |
The practical lesson is to record the geometry before changing anything. If a disk refuses to mount, do not immediately reformat it or assume the drive is faulty. First determine whether the failure occurs while seeking, identifying sectors, checking CRCs or interpreting the file system. Each symptom points to a different layer.
Designing a Custom Disk Format
Start with a specification that a person can implement without guessing. Define the number of cylinders and heads, the sector size, sector numbering, track ordering, interleave, gap lengths, boot-track contents and error-handling rules. State whether unused sectors contain a fixed pattern, random bytes or meaningful metadata. A custom format that exists only as a working program is difficult to preserve and almost impossible to reproduce reliably.
Sector numbering deserves special attention. Sequential IDs are simple, but they may force the CPU to wait while the disk rotates between requests. Interleaving places sectors in a deliberate order so that software has time to process one sector before the next requested sector arrives. Track skew serves a similar purpose when moving between cylinders. These optimisations can make a real difference on original hardware, especially when a format is accessed without generous buffering.
Choose the smallest level of customisation that meets the project’s needs. A standard sector layout with a custom header is easier to image than a track with deliberately invalid address marks. If protection or timing experiments require unusual structures, retain a conventional recovery path elsewhere on the disk. For example, a readable catalogue track can document the raw-track rules, tool version and intended geometry.
The controller’s command limitations should shape the design. A format that depends on precise flux timing, weak bits or specific write-splice behaviour may not be reproducible through ordinary BIOS calls. It may require direct FDC access, a specialised imaging device or custom hardware. The FPGA sound project is a useful reminder that reproducing an X68000 subsystem involves matching behaviour and timing, rather than merely copying a list of registers.
Reading and Writing Without Losing Evidence
When investigating an unknown disk, begin with read-only imaging. Make several passes if necessary, record every error and preserve the original media in a stable, dry environment. A raw image, a sector-level image and a flux capture are different assets; keeping more than one can be worthwhile when the disk contains unusual formatting or marginal sectors.
A conventional PC floppy drive may read some X68000 media, but compatibility is not guaranteed. Drive speed, head alignment, density selection and the ability to handle Japanese 5.25-inch formats all matter. Modern tools such as Greaseweazle can capture flux transitions, while software such as HxC tools or specialised X68000 utilities can help interpret sectors. These tools are complementary: a flux capture preserves evidence, whereas a decoded image is more convenient for emulation and file access.
Writing is riskier than reading. Use a known-good disk, verify the drive’s alignment and clean the heads according to the manufacturer’s service guidance. Avoid repeatedly testing on original software disks. A write-protected source should remain untouched while the custom format is refined on expendable media. Keep notes about drive model, controller settings, image tool, retry count and verification results so a successful disk can be recreated later.
Australian conditions add practical complications. A machine stored in a Brisbane garage can face heat and humidity that accelerate media problems, while a system moved between a Melbourne flat and a regional workshop may experience condensation. Replacement 5.25-inch disks are scarce in the local market, and eBay Australia or Gumtree listings often involve uncertain storage history and expensive postage. Treat suitable blank media as a limited engineering resource rather than assuming another box will appear next week.
Diagnosing FDC and Drive Errors
An error message such as “sector not found” is only a starting point. A seek failure suggests the stepper mechanism, track-zero sensor or alignment. A drive that reports ready but cannot identify any sectors may have a head, speed or density-selection problem. A single bad sector on an otherwise readable track may indicate media damage, while errors that move between sectors can point to unstable electronics or timing.
The index signal and rotation speed deserve attention when custom formats behave inconsistently. A drive that runs outside its intended speed changes the time available for each sector and can make tight gap layouts unreliable. The disk’s index hole also determines where a track capture begins, so tools that compare raw tracks need consistent index handling. If a format relies on a particular write splice or exact gap position, a sector image cannot prove that the physical layout matches the original.
Do not overlook the X68000 itself. A tired power supply can produce unstable behaviour across the floppy subsystem, and corroded connectors can create intermittent faults that resemble bad disks. The Australian mains supply is 230–240 V at 50 Hz, so imported Japanese equipment should use a properly rated transformer or conversion arrangement rather than an improvised adapter. A supply repair should include load testing and inspection of aged capacitors, not just measuring an apparently correct idle voltage.
When troubleshooting, change one variable at a time. Test a known-good commercial disk, then a known-good blank formatted by the machine, before testing a custom image. Swap the drive only after confirming cabling and power. Keep a distinction between a disk that fails on one drive and a format that fails on every drive; that simple record prevents many misleading conclusions.
Preserving the Format for Future Users
A custom disk format is preserved properly only when another person can understand and reproduce it. Store a human-readable specification beside the disk image. Include byte order, command assumptions, sector maps, expected CRC behaviour, boot requirements and examples of valid and invalid tracks. If a program writes directly to controller registers, document the register sequence and the reason for each timing decision.
Keep original captures immutable and create working copies for conversion. Use clear filenames that include the disk identity, capture date, drive and imaging method. Checksums protect against accidental changes, but they do not prove that a capture is complete or correctly decoded. Store the raw flux data, decoded sectors, extracted files and a note describing which sectors could not be recovered.
Physical documentation matters too. Photograph the disk label, jacket, write-protect notch and any handwritten notes before cleaning or repairing the media. If a reproduction is made, distinguish it from an original. The same attitude applies to small hardware parts: the 3D-printed expansion cover shows how documenting dimensions, materials and fit can turn a one-off repair into a useful preservation resource.
For Australian enthusiasts, sharing a verified image through a local retrocomputing group or an archive can reduce dependence on fragile physical media. A collector in Sydney may have a different drive alignment from someone in Adelaide, and a contributor in Perth faces very different postage and storage conditions from someone in Canberra. Recording those details makes community testing more valuable and helps separate regional hardware variation from flaws in the disk format.
Build a small test suite around the design: a blank disk, a valid disk with boundary values, a deliberately bad CRC, a missing sector and a complete bootable example. Test it on original X68000 hardware and in an emulator where possible. Then publish the specification, tools and images together on X68K.NET so the format remains usable when today’s drives and operating systems have disappeared.
Document the controller registers, preserve the raw captures and label every experiment before writing another disk. With a disciplined separation between magnetic layout, FDC commands and Human68k file-system structures, custom formats become measurable engineering projects rather than risky trial and error. Share reproducible results with the X68000 community, and help keep both the machines and their unusual software readable for the next generation.
Nereid-X Expansion Board
A personally-produced LAN+USB+Memory expansion board for Sharp X68000 series computers. Multiple production runs were offered, including a final batch and a later revival reproduction run.
Power Supply Repair
X68 power supply repair and modification services were offered by the site owner, with documentation shared through diary entries spanning 2001–2006.
Server & Networking
Notes on FreeBSD administration, ISP changes, server migration, and networking topics. The site itself ran on FreeBSD with the hns diary system and Namazu search integration.
Get in touch
X68K.NET connects Sharp X68000 enthusiasts through community links and shared projects. Reach out with questions about the Nereid project or X68 resources.