Using a Logic Analyzer to Reverse-Engineer the X68000 Floppy Controller

The Sharp X68000 floppy system is an excellent target for practical reverse engineering. Its drives, controller logic, DMA transfers and operating-system routines form a compact chain, so a captured signal can often be connected to a visible result such as a directory listing, disk error or successful boot. A logic analyzer turns that chain into evidence instead of guesswork.

The work is especially useful when restoring a machine with an unreliable drive, adapting replacement hardware or documenting an undocumented custom circuit. It also suits the way many Australian owners acquire these computers: a Japanese import from eBay, a parts machine found through Gumtree, or a long-stored unit brought out at a Melbourne, Sydney or Brisbane retrocomputing meet.

Investigation stage	Signals or evidence	Useful result
Controller discovery	Chip markings, address lines, read/write strobes	Identifies the controller and bus interface
Drive command tracing	Select, motor, direction, step and write-gate lines	Shows how the X68000 positions and writes media
Read-data capture	Raw flux-derived pulses, index and ready	Reveals sector timing and drive behaviour
DMA observation	Data bus, address bus, acknowledge and request lines	Explains transfers between controller and RAM
Error analysis	Interrupts, status reads and retry sequences	Separates media, drive and software faults

Establishing A Safe Test Setup

Begin with the service documentation, board photographs and a clear record of the machine revision. X68000 models differ in mechanical details, connector arrangements and custom logic, so a signal name copied from an ACE may not map directly to an XVI or Compact. Photograph every connector before probing, then mark pin numbers and wire colours on a working diagram.

A logic analyzer must share a reliable ground with the computer. Use a short ground lead, preferably attached close to the controller or drive connector, rather than relying on a long flying lead. Long ground wires can turn fast bus edges into ringing and false transitions. An inexpensive 8-channel USB analyzer is enough for drive-side work, while a 16-channel unit is more comfortable when address, data and control signals must be observed together.

Take care around the power supply. Japanese X68000 machines are associated with 100-volt mains, while Australian outlets provide 230–240 volts, so an appropriate step-down transformer and correctly rated replacement supply are essential. Never clip a grounded USB analyzer to an unknown mains-referenced point. Work on the low-voltage digital side, with the chassis stable and exposed conductors insulated.

Start with passive observation. Confirm that the analyzer input threshold suits the machine’s logic family, commonly 5-volt TTL or closely related circuitry. Do not assume that a modern 3.3-volt analyzer is 5-volt tolerant. A level shifter or buffered probe can protect both the instrument and a rare custom gate array.

Finding The Controller And Its Bus

The first task is locating where the floppy controller meets the 68000 system bus. Depending on the board revision, functions may be provided by a dedicated floppy disk controller, a custom Sharp LSI, glue logic, or a combination of those devices. Look for traces leading from the drive connector towards a controller IC and for a cluster of address, data and control lines connected to the main bus.

A schematic or continuity map is more valuable than probing every pin at random. Identify the eight-bit data bus, address selection, read and write strobes, chip select and interrupt output. Labels such as /RD, /WR, /CS, /IRQ and /DRQ are common, but active-low notation matters: a low-going pulse is an asserted event, not an absence of activity.

Use a slow capture first. Trigger on a controller chip-select line and inspect the accompanying address and data values during a disk access. A single status read may show the CPU polling for drive readiness, while a command write can reveal motor control, head movement or a read-sector operation. Repeated accesses are useful because software often polls a status register many times before issuing the next command.

Where possible, compare a healthy machine with the faulty unit. The X68000 community has accumulated valuable repair knowledge, and specialist archives such as S-MB research notes can provide useful context for identifying older Japanese hardware and signal conventions. A known-good capture gives you a practical reference when board markings are obscure.

Capturing Drive Commands

At the drive interface, concentrate on signals with clear mechanical meaning. Drive select chooses the unit, motor-on starts spindle rotation, direction controls head movement, and step advances the head by one track. Index marks one revolution. Track-zero, write-protect and ready report physical conditions back to the controller.

Probe one command group at a time. Trigger on a step pulse and measure the interval between pulses, the direction level and the delay after drive selection. A boot or directory operation may produce a burst of steps as the controller seeks to a track, followed by a settling pause before data is read. If the direction line changes but step never toggles, the problem may be in the controller output stage, a cable connection or drive selection logic rather than the mechanism.

Motor timing can reveal another class of fault. Some drives need time to reach stable speed before read commands are attempted. Capture motor-on, index and read activity together. If index pulses never appear, check spindle operation, sensor circuitry and drive power before blaming disk format. If index is present but data reads fail, the fault is further along the signal path.

The write path deserves extra caution. The write-gate line usually enables the drive’s write current, while write-data transitions encode the magnetic pattern. Do not connect a probe in a way that loads this line or accidentally asserts it. A protected test point or high-impedance buffer is preferable. For a first investigation, read-only captures provide plenty of information without risking a valued disk.

Interpreting Read Data And Disk Timing

The drive’s read-data output is a stream of transitions derived from magnetic flux changes. It is not normally a clean byte-wide signal. The controller converts those transitions into clock and data information, checks address marks and sector structure, then presents assembled bytes to the CPU or DMA engine.

Capture read-data alongside index and the controller’s data-request or interrupt signals. Measure the interval between transitions rather than treating each edge as a logical one or zero. Depending on the recording method and controller, the disk may use MFM or a related frequency-modulation scheme. The important observation is the timing pattern: short and long intervals can reveal clock cells, data cells, missing address marks and malformed sectors.

A logic analyzer’s default protocol decoders may be misleading here. A UART decoder or generic clocked-byte decoder cannot understand raw floppy flux transitions unless the signal has already been conditioned and sampled correctly. Export the capture as timestamps or a digital waveform, then analyse it with a purpose-built script or disk-recovery tool. Keep the original capture untouched so later decoding experiments can be repeated.

Index is a valuable reference point. Compare the first valid sector after index across several revolutions. Stable timing suggests the drive and media are behaving consistently; drifting transitions, excessive noise or missing regions point towards alignment, head contamination, media degradation or spindle-speed problems. On an old Japanese disk, preservation comes first: use a write-protected working copy and avoid repeated reads of a fragile original.

Following DMA And Interrupt Activity

Once the drive-side sequence is understood, follow how bytes reach memory. A sector read may involve the controller requesting service through /DRQ, a DMA controller acknowledging it, and a block of bytes being written into RAM without the 68000 handling every byte directly. Other operations may use programmed I/O, especially for status and command registers.

Probe the request and acknowledge lines with the bus read/write strobes. If a request pulse appears but no corresponding transfer follows, investigate DMA enable, channel configuration and bus arbitration. If transfers occur but the buffer contains shifted or repeated data, examine data-bus timing, terminal-count behaviour and whether the controller is being reset between commands.

Interrupt timing helps connect hardware events to software. A controller may interrupt when a command completes, an error occurs or a sector is ready. Capture /IRQ together with the final status read and the last data transfer. The sequence can distinguish a genuine media error from a software timeout. An interrupt that arrives normally but is ignored may indicate an operating-system or configuration problem rather than damaged electronics.

The X68000’s 68000 bus is relatively spacious by modern standards, but a low sample rate can still miss narrow strobes. Set the analyzer to a rate comfortably above the shortest observed pulse, then increase memory depth so a full seek and sector read remain in one capture. Several short captures with clear triggers are usually more useful than one enormous recording with uncertain timing.

Turning Captures Into A Repair Method

A good reverse-engineering log records the machine state, disk used, command performed, trigger condition, analyzer sample rate and interpretation. Save the raw capture, an annotated screenshot and a text file containing measured timings. Use consistent names such as xvi_driveA_read_track00_good and xvi_driveA_read_track00_fail, rather than relying on memory weeks later.

Compare working and failing cases at the same stage. If both have identical select, motor, direction and step activity but only the faulty machine lacks index, concentrate on the drive mechanics or sensor. If index and read-data are present but controller status never changes, inspect the controller input path, clock and reset. If the controller reports completion but RAM is wrong, move towards DMA, bus timing or memory selection.

A repair can then be tested as a hypothesis. Reflowing a cracked connector, replacing a tired electrolytic capacitor, cleaning a drive head or repairing a broken trace should produce a measurable change in the waveform. Avoid replacing several parts at once, because that removes the evidence needed to identify the original failure.

This approach is practical for Australian restorers dealing with limited local stock. A replacement Japanese drive may cost more after postage, GST and international shipping, while common capacitors, headers and logic buffers are easier to source through electronics suppliers in Melbourne or Sydney. Capturing the fault before ordering parts can prevent an expensive guess and may preserve an otherwise irreplaceable original mechanism.

Preserving Knowledge For Future Hardware

The most useful result is often a documented signal map rather than a single repaired computer. Record connector pin numbers, active levels, typical timing, controller register activity and differences between model revisions. Include uncertainties clearly. A note that says “likely ready signal, confirmed during motor startup” is more valuable than an overconfident but incorrect label.

Share captures in formats others can inspect. A screenshot is convenient, but a CSV export, Saleae session or equivalent raw file permits independent measurement. Annotated board photographs should identify probe locations without exposing private serial numbers or personal information. A short explanation of the disk image, drive model and test conditions makes the data reproducible.

The Nereid-X expansion board is a reminder that preservation work often connects original hardware with practical modern additions. Expansion projects, repaired power supplies and floppy investigations all benefit from the same habits: document revisions, respect electrical limits and test one variable at a time. This keeps the X68000 useful rather than reducing it to a display piece.

When the captures are organised, they become a reference for future owners in Australia and elsewhere. Someone in Adelaide restoring a machine from a Japanese auction lot may be able to identify a missing pulse before shipping another drive across the Pacific. Someone at a Perth retrocomputing gathering may diagnose a cable fault with a borrowed analyzer instead of discarding a working controller.

A logic analyzer makes the floppy controller visible as a sequence of decisions: select the drive, start the spindle, seek the track, recognise index, decode transitions, transfer bytes and report status. Capture that sequence carefully, compare it with a known-good operation, and publish the evidence alongside the repair notes. That is how an ageing X68000 becomes easier to maintain, understand and use for another generation.