Capturing Human68k boot traces with a USB logic analyzer

When the Sharp X68000 powers on, a small choreography of signals races across the motherboard before the familiar Human68k prompt ever appears. The 68EC000 or 68000 CPU manages cache, the IPL ROM hands control to the SCSI or SASI firmware, and the boot loader finally reads the first sector from disk. Every one of those steps leaves an electrical fingerprint, and a modern USB logic analyzer lets hobbyists in Brisbane, Melbourne, or anywhere else with a sharp eye and a steady hand record that fingerprint in real time.

For owners of a vintage machine, a captured trace is more than nostalgia. It is a way to confirm that a freshly recapped power supply is delivering clean rails, to verify that a homemade expansion like the Nereid board is responding on the bus, or to diagnose why a particular disk refuses to boot. A few hundred milliseconds of activity, sampled at tens of megahertz, can settle arguments that would otherwise need an oscilloscope, a ROM emulator, and a free weekend.

Australians chasing this kind of work have a few advantages. Local suppliers such as Jaycar and Altronics stock entry level analyzers, Australia Post delivers small parcels quickly between capital cities, and the country's strong maker community means that troubleshooting advice is rarely more than a forum post away. The challenge is matching the tool to the vintage hardware without overspending on sample rate or channels that the X68000 simply does not need.

Choosing the right analyzer for a 10 MHz bus

Model	Channels	Max Sample Rate	Approx. AUD Price	Software Notes
Saleae Logic 8	8	500 MS/s	A$189	Proprietary, polished UI
Kingst LA2016	16	1 GS/s	A$95	Sigrok compatible
Hantek 6022BE	16	48 MS/s	A$65	Sigrok, basic decoding
ikalogic SP209	9	200 MS/s	A$149	Standalone and USB modes
sigrok FX2 clone	8	24 MS/s	A$25–40	Open source, hobbyist build

The X68000 CPU runs at 10 MHz, so anything beyond 50 MS/s per channel captures the bus with comfortable margin. Realistic boot traces fit easily inside 100 megasamples of memory, which even the cheapest FX2 based clones can handle. For most users, a clone board sourced from a local importer around seventy Australian dollars is plenty, while those who value a tidy interface and easy protocol decoding gravitate toward Saleae or Kingst.

Buyers should also confirm the unit carries the Australian RCM mark before plugging it in. Importing unbranded electronics through the regular post can attract GST and inspection fees, and devices without proper compliance documentation can be refused at the border by the Australian Border Force. A small premium for a properly certified unit is cheaper in the long run.

Setting up the X68000 safely

Before any probe touches the motherboard, the machine needs a proper service position. That means the lid off, the keyboard detached, the SCSI cable disconnected from any external drive, and a known good power supply feeding the unit. Anyone in Australia living near the coast should also consider running a dehumidifier for an hour before opening the case, because salt laden air corrodes the edge connectors on the X68000 faster than almost any other aging factor.

A clean 5 V rail is the foundation of a useful trace. The original power supply is famous for dried out capacitors, and a sagging rail produces noise that looks like bus contention even when the logic is perfectly healthy. A multimeter across the 5 V test point should sit between 4.95 V and 5.05 V under load. If it dips below that range, replacing the supply or installing an ATX conversion is the first step, and only then should probing begin.

Grounding the analyzer is equally important. The ground clip of the USB logic analyzer must attach to a chassis screw or the logic ground near the debug header, never to an audio ground or a floating shielding can. A floating ground adds fifty or sixty hertz of mains pickup to every channel, which in Australian households running at 230 V and 50 Hz is particularly nasty. Tie the grounds together once, firmly, and leave them alone.

Wiring the probe points

The X68000 was not designed with modern debuggers in mind, so the trick is finding stable test points. Three locations cover most of what a Human68k trace needs: the data lines of the MPU bus as it exits the CPU socket, the chip select pin of the IPL ROM, and the busy or acknowledge line of the SCSI controller. Each of these is a square wave during boot, easy to identify with a multimeter in continuity mode and a photocopy of the service manual.

Clip leads work but introduce inductance. For permanent fixtures, a small Pomona style grabber or a Dupont socket soldered to a thin wire gives a cleaner signal. Australian hobbyists often reuse parts harvested from decommissioned telecom gear, which became plentiful after the national broadband rollout upgrades of the past decade. Whatever connector is chosen, keep leads short, ideally under ten centimetres, and route them away from the power supply harness.

Channels should be assigned with intent. One channel for the IPL chip select marks the moment the ROM takes over from the reset vector. A second channel for the HBL or bus request line shows DMA activity during disk access. A third for the reset signal itself provides a clean time zero. The remaining channels are free for address bits or write enables if deeper analysis is needed, and most eight channel clones are sufficient. Projects that add their own debug headers, such as the Nereid expansion board, expose more of these signals in a tidy, labelled row that saves hours of probing.

Triggering on the boot sequence

A logic analyzer without a good trigger is just an expensive way to fill a buffer. For Human68k boot traces, the most useful trigger is a rising edge on the reset line combined with a falling edge on the IPL chip select. That pair captures everything from the moment power stabilises through the first ROM instruction. Some analyzers expose this as a sequential trigger, while sigrok compatible units describe it as a simple state machine language.

Sample rate also deserves attention. Sampling at the full one gigasample per second of a Kingst LA2016 burns through memory in seconds and rarely adds information, because the slowest signal of interest during the boot phase is the SCSI handshake at a few megahertz. A rate of 100 MS/s is more than enough for the MPU bus, and 50 MS/s still captures every transition with comfortable margin. Adjusting the rate before the run saves post processing time later.

Compression and decoding deserve a final pass before pressing start. Enabling RLE compression on sigrok based tools extends capture depth, while the Saleae software applies its own lossless scheme automatically. Protocol analyzers for SPI or I2C can be turned off for now, because the X68000 does not use those buses during boot, and leaving them on just clutters the timeline view.

Reading the resulting trace

Once the capture completes, the waveform shows a story in three acts. The first is the reset stretch, where all lines settle and the CPU drives the address bus to the reset vector. The second is ROM execution, marked by steady chip select pulses on the IPL line as the firmware runs through its POST routines. The third is the handoff, when the IPL loads the Human68k IPL loader from the boot device and the operating system kernel finally takes control.

Look for anomalies at the boundaries between those acts. A reset that lingers past the expected few milliseconds suggests a power supply fault. A missing chip select on the IPL ROM means the socket or the ROM chip itself is suspect. A SCSI handshake that never completes usually points back to the drive, the cable, or the termination. Each of those conclusions comes straight off the waveform without needing to swap any boards.

A captured trace also makes a permanent record. Saving the session file alongside a dated note about the machine's serial number, the supply voltage measured that day, and the version of Human68k in use builds a small archive that grows more valuable over time. When the day comes that a rare fault reappears, a comparable trace from a known good unit speeds diagnosis dramatically.

For enthusiasts ready to share findings, swap captures, or hunt down a particular ROM, the community links index gathers software archives, discussion forums, and active X68000 owners across Australia and the wider Japanese retrocomputing scene. Pinning a thread there with the saved trace often brings replies within a day, and occasionally uncovers someone else documenting the exact fault.