Understanding Floppy Disk Controller Commands on the X68000

The Sharp X68000 relies on a floppy disk controller that follows the command model established by the NEC uPD765 family. That design also appears in many Japanese computers and IBM-compatible systems, but the X68000 gives it a distinct setting through its 68000 processor, custom I/O hardware, disk formats, and operating-system conventions. Understanding the controller means learning how a command travels through the phases of a transfer, how status bytes describe the result, and how physical disk geometry affects every request.

A floppy operation is never just a single instruction such as “read sector.” The host must select a drive, define the cylinder and head, supply sector parameters, wait for data or status, and then interpret the controller’s response. A mistake in any parameter can produce a timeout, a seek error, a missing-address-mark error, or a result that appears valid while describing the wrong sector.

This knowledge is useful for more than writing a disk utility. It helps when diagnosing damaged disks, tracing boot failures, repairing expansion hardware, developing emulators, and preserving software whose original environment is becoming difficult to maintain. The command set is compact, but its timing and result phases reward careful observation.

The Controller’s Basic Conversation

A compatible floppy disk controller communicates through a sequence of phases rather than a simple register write. The host first places a command and its parameter bytes into the data register during the command phase. The controller may then enter an execution phase, during which it moves the drive mechanism, searches the disk, or transfers sector bytes. Finally, it enters a result phase and returns status information.

The main status register indicates whether the controller is ready to accept a byte, whether a byte is available to read, and whether the current phase is a command, execution, or result phase. Software must check these signals instead of assuming that a fixed delay is sufficient. Mechanical seek time, rotational latency, motor startup, and error recovery can all vary.

For a normal sector read, the host sends the Read Data command followed by drive and sector parameters. The controller selects the requested side, positions the read head at the requested cylinder, waits for the target ID field, and streams the sector data. After the final byte, it returns several result bytes. A write follows a similar pattern, except that the host supplies data during the execution phase.

The command protocol is therefore stateful. Sending a new command too early can corrupt the current transaction, while reading too few result bytes can leave the controller in an unexpected state. Low-level programs should model these phases explicitly and should record the exact byte sequence used for every test.

The Command Groups Worth Knowing

The most frequently used commands are Read Data and Write Data. Their operation codes are commonly shown as 06h and 05h, respectively, although command flags occupy some of the upper bits. Read Deleted Data, usually 0Ch, searches for a sector marked with a deleted-data address mark. Write Deleted Data, usually 09h, creates that form of sector. These commands matter when examining disks created by software that uses deleted sectors as metadata or protection information.

Format Track, 0Dh, initializes an entire track according to a supplied list of sector IDs. It does not receive ordinary sector contents in the same way as Write Data. Instead, the host sends four-byte ID entries containing cylinder, head, sector number, and size code. The controller uses those entries to construct the track layout, making the command especially important for nonstandard disk formats.

Read Track, commonly 02h, reads a complete track beginning at the current position and can expose sector ordering or unusual formatting. It is useful when a disk image tool needs to inspect more than a conventional sequence of logical sectors. Scan commands compare disk data with a supplied pattern and can be used for verification or specialized search operations, though they are less common in everyday X68000 software.

Several commands control positioning and state. Recalibrate, 07h, moves a drive toward cylinder zero and establishes a reference position. Seek, 0Fh, moves to a specified cylinder without performing a data transfer. Sense Interrupt Status, 08h, retrieves the result of a seek, recalibrate, or other interrupt-generating operation. Sense Drive Status, 04h, reports selected drive conditions, including track-zero and write-protect information on compatible implementations.

Specify, 03h, configures timing values such as step rate, head unload time, and head load time. Sense Error Status, often represented as 0Dh on uPD765-compatible documentation, has a role in some controller variants and software environments, but command availability and interpretation should be confirmed against the X68000 hardware documentation. Names and hexadecimal values are useful shorthand, not a substitute for checking the actual controller revision.

Parameters Define the Disk Geometry

A read or write command generally carries a drive/head byte followed by C, H, R, N, EOT, GPL, and DTL parameters. C identifies the cylinder, H the physical head, and R the sector number. N is the sector-size code: a value of 02h normally represents 512-byte sectors, while the formula is commonly 128 × 2^N for standard sizes.

EOT means the ending sector number for a multi-sector operation. If a command begins at sector 1 and EOT is 8, the controller may continue through sectors 1 to 8, provided the disk format and controller behavior permit it. GPL is the gap-length value used by the controller when reading or writing formatted media. DTL has meaning for certain sector-size configurations and should not be treated as an arbitrary filler.

The drive/head byte combines the selected unit with the head number. The command’s upper flags may also control multi-track behavior, such as moving from one head to the other without requiring a separate command. That feature must match the physical layout and the X68000 software’s assumptions. A disk image that interleaves heads differently from the original medium can produce confusing results even when every sector exists.

Format Track uses a different parameter arrangement. After the command and drive/head byte, the host supplies the size code, sector count, gap length, and a filler byte. It then sends the ID tuples for every sector on the track. The sector count must match the number of tuples that follow. Incorrect counts can cause the controller to consume later bytes as IDs, leaving the bus out of phase.

Command	Typical Code	Main Purpose	Important Result
Read Data	06h	Read one or more sectors	ST0, ST1, ST2, CHRN
Write Data	05h	Write one or more sectors	ST0, ST1, ST2, CHRN
Read Deleted Data	0Ch	Read deleted-mark sectors	Status and returned sector ID
Format Track	0Dh	Build a track from ID fields	ST0, ST1, ST2, CHRN
Read Track	02h	Stream a complete track	Status and final sector ID
Recalibrate	07h	Return toward cylinder zero	Checked with Sense Interrupt
Seek	0Fh	Move to a requested cylinder	Checked with Sense Interrupt
Sense Drive Status	04h	Inspect drive conditions	Drive status byte

The values in this table describe the standard uPD765-style command family. X68000 programs may access the controller through operating-system services rather than issuing these bytes directly, and hardware revisions or adapters can alter practical behavior. A logic analyzer trace and the relevant machine-level documentation should take precedence over a generic PC floppy reference.

Result Bytes Explain What Happened

The first result byte, ST0, summarizes the drive status and the broad outcome of the operation. It identifies the selected drive and head, indicates whether the controller completed normally, and reports conditions such as an abnormal termination or a seek-related fault. The exact bit names are important because a nonzero ST0 does not automatically mean that the disk data is unusable.

ST1 reports transfer and media conditions such as missing address marks, end-of-cylinder behavior, data errors, or a write-protect response. ST2 provides additional detail, including data errors, control-mark detection, and problems associated with the requested sector. Reading only ST0 throws away much of the diagnostic information needed to distinguish a bad disk from a bad parameter block.

The final result bytes usually repeat the controller’s view of C, H, R, and N. These values are valuable evidence. If the requested sector was C=12, H=0, R=3 but the result reports a different ID, the drive may have encountered an unexpected sector, a damaged ID field, or a disk layout unlike the one assumed by the program.

A deleted-data result deserves special care. The controller may report a control-mark condition in ST2 even though it successfully located and transferred the sector. Error handling that treats every set status bit as a fatal read failure can make preservation software discard recoverable content. Good tools display the raw status bytes and explain their meaning separately from the high-level success or failure label.

Positioning and Timing Are Part of the Protocol

Seek and recalibrate are often described as simple mechanical commands, but they still require a complete software sequence. After issuing Seek or Recalibrate, the host normally waits for the controller to signal completion and then sends Sense Interrupt Status. That result identifies the drive and reports the present cylinder, allowing software to detect an incomplete or failed movement.

The cylinder reported after recalibration is not merely a convenience. It allows a diagnostic program to determine whether the drive’s track-zero sensor, stepper motor, and controller state agree. Repeated recalibration failures can point to a dirty sensor, a mechanical obstruction, a damaged ribbon cable, or incorrect drive-selection signals rather than a bad floppy disk.

Timing parameters influence reliability. A step rate that is too aggressive may cause a marginal mechanism to miss steps, while unsuitable head-load or unload timing can create intermittent reads. A modern replacement power supply or expansion board may also affect the electrical conditions around the floppy interface. Repair notes and hardware documentation, such as the X68000 hardware notes, can provide useful context before software-level debugging begins.

The controller’s busy and data-ready indicators must be polled according to the machine’s hardware design. A program written for a standard PC-compatible register map should not be copied directly into an X68000 driver without confirming port addresses, interrupt behavior, and byte ordering. The 68000 architecture also means that assumptions about x86 I/O instructions and timing do not transfer automatically.

Working Safely With Real Disks

Direct formatting and writing should begin with known expendable media or a disk image workflow. A Write Data command can destroy a sector immediately, and Format Track can erase the structure needed to recover an entire track. Preservation work should first capture as much of the original medium as possible, including sector IDs, unusual gaps, deleted marks, and read errors.

A robust imaging tool logs the command parameters and all result bytes for every sector. It should distinguish a clean read, a corrected retry, a missing sector, and a sector whose data was obtained with an unusual status. Repeating a read several times can reveal whether an error is stable or caused by alignment, contamination, or marginal signal quality.

Disk geometry must also be recorded. Cylinder count, head count, sector numbering, sector size, interleave, and track gap values define how a disk is organized. X68000 software may use formats that do not resemble a default IBM PC disk, so blindly selecting a common 1.44 MB profile can lead to incorrect images or unnecessary write attempts.

For emulation, the same principle applies. An emulator should expose the command phase, execution timing, and result phase faithfully enough for software that polls status registers or relies on interrupt sequencing. It should preserve abnormal conditions rather than returning idealized data for every request. Compatibility often depends on the errors and delays that ordinary applications never document.

Practical Habits For Command-Level Work

Low-level floppy debugging becomes much easier when each experiment has a narrow purpose. Start with status reads and drive selection, then test recalibration and seek before attempting data transfers. Once positioning works, read a known-good sector and compare both its contents and its returned CHRN values.

Useful working habits include:

• Keep a hexadecimal log of every command, parameter byte, status transition, and result byte.
• Verify the selected drive, head, cylinder, sector, and size code before issuing a write or format operation.
• Preserve raw ST0, ST1, and ST2 values instead of converting them immediately into a generic error.
• Test retries and repeated reads on a copy or image before touching valuable original media.
• Compare direct-controller behavior with operating-system disk services to identify hardware and software differences.

These practices also make documentation more valuable. A command list without timing notes or example result bytes is difficult to apply, while a trace showing a complete successful read and a representative failure gives future developers something concrete to reproduce.

The uPD765-compatible command set is small enough to learn, yet rich enough to explain much of the X68000’s disk behavior. Once the phases, parameter fields, status bytes, and physical mechanics are considered together, floppy failures become evidence rather than mystery. That understanding supports safer disk preservation, more accurate emulation, and better repairs of aging machines.

Explore the broader X68000 documentation and contribute your own test results, command traces, repair notes, or software observations through the X68K.NET community. Careful records made today can keep the platform’s hardware and disk-based software usable long after original manuals and working drives have become scarce.