Building a Raspberry Pi Pico I/O Activity Logger for the X68000

The Sharp X68000 is an excellent platform for observing how period hardware actually works. Its Motorola 68000 bus exposes a useful mixture of address, data and control signals, while expansion devices often behave in ways that are easier to understand from live traffic than from a schematic alone. A small logic analyser can reveal a surprising amount, but a Raspberry Pi Pico offers a cheaper, more adaptable route for targeted logging.

The aim is not to turn the Pico into a universal 68000 analyser. It is better used as a focused instrument: watch a selected address range, capture read and write cycles, record the data value, and send useful events to a computer for later inspection. That approach suits fault finding, reverse engineering, prototype testing and preservation work.

This project requires care around voltage levels and timing. The Pico uses 3.3 V GPIO, while an X68000 expansion bus may expose 5 V logic and fast edges. A safe logger must isolate the computer, avoid loading the bus, and capture only the signals needed for the question at hand. With the right interface, the result can be a compact diagnostic tool for a workbench in Brisbane, Ballarat or anywhere else an X68000 is being kept alive.

What The Logger Needs To Observe

A 68000 bus transaction generally contains an address, a data value, and control signals that explain whether the processor is reading or writing. For I/O monitoring, the address is usually the most important filter. The X68000 uses memory-mapped I/O, so an apparent memory access may actually be a communication with a sound chip, peripheral controller, expansion board or custom hardware register.

A practical first version should capture only the lower address lines, the data bus, and the relevant strobe signals. Depending on the connection point and the diagnostic goal, those signals may include address strobe, read/write state, upper and lower data strobes, and a bus acknowledge or device-select signal. The exact names and polarity must be checked against the machine’s service documentation and the board being examined.

It is tempting to connect every available line to the Pico. That quickly consumes GPIO pins and makes the wiring fragile. A narrower design can monitor one known port or address window, using external decoding to tell the Pico when a transaction matters. For example, a small logic circuit can combine address lines into an active-low trigger, leaving the Pico to capture the data and timing information.

Protecting The X68000 And Pico

The Pico’s GPIO pins are not 5 V tolerant. Connecting a 5 V X68000 signal directly to a GPIO input can damage the microcontroller, even if the connection appears to work during a quick test. Use a proper level-translating arrangement, such as 74LVC-series buffers powered at 3.3 V when their inputs are confirmed to accept the bus voltage, or a suitable 5 V-tolerant interface buffer recommended by its datasheet.

Series resistors can reduce ringing and limit fault current, but they are not a complete level-shifting solution. A resistor divider may work for a slow control line, yet it can distort a fast bus edge or create an uncertain logic-high level. For address and data groups, matched buffers with short ground returns are a safer choice. Keep the logger electrically separate from the X68000 until the interface has been tested.

Power deserves particular attention in Australia. The X68000’s internal supply is connected to mains equipment designed for Japan, while local household power is nominally 230–240 V. A step-down transformer, a professionally repaired supply, or a correctly engineered replacement is essential; a plug adaptor changes the connector shape, not the voltage. Never probe an unisolated power supply casually, and keep the Pico powered from its own USB supply during early testing.

Before attaching the target machine, validate the interface with a signal generator, another microcontroller, or a spare logic source. Confirm that inactive lines sit at the expected levels, that no buffer output drives against the X68000, and that reset and bus-request states do not create unexpected contention.

Choosing A Capture Method

The Pico’s Programmable I/O blocks are well suited to repetitive digital sampling. A PIO state machine can wait for a trigger, sample several GPIO pins on a clock edge, and transfer words into a DMA buffer without requiring the Arm core to respond to every bus cycle. This is far more reliable than reading GPIO registers in a normal C or MicroPython loop.

A useful record might pack the address fragment, data byte or word, read/write state, byte-lane strobes and a short timestamp into 32 bits or 64 bits. DMA can fill a circular buffer while the main core checks for overflow and sends completed blocks over USB serial. The host computer can then decode each record into a line such as “write, port 0xE9A001, data 0x40”.

Sampling speed must be based on the actual bus timing, not the Pico’s headline clock rate. A single sample per cycle may miss a narrow strobe if the sampling edge is poorly aligned. Oversampling improves the chance of seeing transitions, while triggering on a qualified control signal produces cleaner records. If the bus is asynchronous to the Pico clock, capture multiple samples around the event and decode the stable portion afterwards.

The Pico SDK and C are preferable for sustained capture, although MicroPython is useful for early experiments and control commands. USB serial is convenient for short sessions, but a binary stream is more efficient than formatted text. Add a sequence number and overflow flag to each block so that the host program can distinguish “no activity” from “records were lost”.

Hardware Choices And Trade-Offs

There is no single best logger configuration. A portable setup for occasional debugging looks different from a permanent expansion-board monitor. The comparison below shows sensible starting points for several levels of ambition.

Approach	Useful For	Strengths	Limitations
Pico with buffered GPIO	One port or a small address window	Low cost, programmable filtering, easy USB output	Limited pins and capture depth
Pico with PIO and DMA	Repeated bus-cycle logging	Accurate timing, low CPU overhead, high event rate	Requires C or careful PIO development
Pico plus external decoder	A fixed I/O device or register block	Fewer Pico pins, clean trigger signal	Less flexible when the target address changes
Pico plus FIFO or SRAM	Longer bursts and busy buses	Stores more events before host transfer	Adds wiring, power and signal-integrity work
Commercial logic analyser	Broad exploratory work	Many channels, mature software, easy visual decoding	Higher cost and less tailored filtering

For a first build, a Pico, two or more 3.3 V interface buffers, a small address decoder and a removable test harness are enough. Use labelled headers rather than soldering permanently to a valuable mainboard. A short ribbon cable with a ground conductor between signal groups is preferable to a bundle of long jumper wires.

A basic logger can filter in hardware and capture only data associated with one device-select condition. A more advanced design can feed a complete address and data snapshot into the Pico, then apply software filters. The second method is flexible, but it increases pin count and can make simultaneous sampling harder. If the purpose is to study an unknown peripheral, flexibility is valuable; if the purpose is to diagnose one register, hardware filtering keeps the design dependable.

Local sourcing can be practical. Australian electronics hobbyists can often find headers, resistors and prototyping boards through Jaycar, element14 Australia or RS, while specialist 74LVC parts may require an online order. Allow time for shipping to regional areas, and consider ordering spare buffers because a wiring mistake is much cheaper to replace than an X68000 motherboard.

Firmware That Produces Useful Evidence

The firmware should record enough context to make each event meaningful. At minimum, include the captured address, data, transaction direction and a timestamp or event counter. Record reset transitions and buffer overflow conditions as separate flags. Without them, a log can look convincing while silently omitting the moment when the machine changed state.

Filtering can happen at several levels. A hardware decoder may assert a trigger only for the target I/O range. The PIO program can then wait for the read or write strobe and push a compact sample into the FIFO. The Arm core can discard irrelevant events, attach a wider timestamp, and move blocks to USB. This division prevents expensive parsing from interfering with capture.

On the host, a small Python utility can translate binary records into CSV, JSON or readable text. Group consecutive accesses by address and calculate intervals between them. Repeated writes may reveal a polling loop, while a single read after reset may identify a device-detection probe. Comparing logs from a working and faulty machine is often more informative than inspecting one trace in isolation.

Keep a record of the test conditions. Note the X68000 model, expansion board revision, software title, CPU speed, display mode and any accelerator or RAM board fitted. A capture from an XVI with modified hardware may differ from a compact model in ways that are easy to misinterpret later. The X68000 diary format of recording practical machine history is a useful reminder that dates, hardware versions and observations belong beside the raw data.

Capturing And Interpreting Port Activity

Begin with a harmless target such as a known status register or a device that is accessed during boot. Start the logger before powering or resetting the X68000, then capture a short, repeatable action. Reset the machine several times and compare the traces. Stable access sequences suggest that the electrical interface and decoder are behaving consistently; unexplained differences may point to timing, software state or a marginal connection.

A log becomes especially valuable when correlated with an external event. Press a key, start a disk operation, change a sound setting or access an expansion-board feature, then mark the approximate time. If a device-select signal is available, use it to separate the target from unrelated bus traffic. A simple trigger input connected to a pushbutton can also place a human-readable marker in the capture stream.

Look for register access patterns rather than isolated values. A write followed by a status read may represent command completion. A stream of writes at regular intervals can indicate audio playback or serial transmission. Alternating reads from two addresses may be a polling loop. If the bus shows writes but the peripheral never responds, inspect acknowledge timing and byte-lane selection before assuming that the register map is wrong.

Be cautious with conclusions. The 68000 can perform byte and word accesses with different strobes, and a peripheral may respond only to one lane. Address decoding may mirror a register across several locations. Software may also access a port as part of a larger driver routine, so a trace shows what happened on the bus, not necessarily the programmer’s intention.

Applying The Tool To Expansion Hardware

An I/O logger is particularly useful when developing or repairing expansion hardware. It can confirm that a driver is reaching a board, reveal unexpected reset-time writes, and show whether an interrupt-related status register is being polled. For a new prototype, capture the known-good software path first, then compare it with the failing board under identical conditions.

When studying an IDE, SCSI, network or memory expansion adapter, log the smallest useful address region. A broad capture may produce thousands of unrelated cycles and hide the transaction of interest. Hardware filtering around the board’s decoded range gives a clearer signal and reduces storage requirements. Add an input for the board’s interrupt line if interrupt behaviour is part of the investigation.

Existing repair notes can provide valuable context before probing. The Supercharger IDE installation notes demonstrate the kind of machine-specific detail that matters when working around an X68000 expansion path. A capture should complement that information, not replace documentation: identify connector pins, verify active-low signals, and label every test lead before switching on.

The logger can also help preserve undocumented behaviour. Once a working board has been captured, store the firmware, wiring diagram, decoder equations and representative traces together. Include photographs and board revisions. If a replacement component is needed years later, those records may be more useful than a vague description that the device “talks to the computer”.

Making The Work Safe And Repeatable

Use a grounded, tidy bench and avoid connecting the Pico through a laptop that is simultaneously attached to other equipment with unknown ground relationships. USB isolation is worth considering for difficult setups, although it does not remove the need for safe mains practice. Keep the logger’s ground connection short and deliberate, and disconnect power before changing the harness.

Give every capture a filename containing the date, machine model and test action. Australian date formats can be ambiguous in mixed software environments, so an ISO-style name such as 2025-07-14_xvi_boot_port-test.bin avoids confusion. Store the raw binary file as well as decoded output. A later decoder revision may find information that an early script ignored.

For hobbyists sharing equipment through a club or local retrocomputing group, make a printed connection sheet and mark any non-standard modifications. A machine travelling by Australia Post between Sydney and Perth needs more than bubble wrap: removable probes, strain relief and a clear restoration plan reduce the risk of a connector being pulled from an old board. Keep the original machine reversible wherever possible.

Historical material benefits from the same discipline. A visual record such as this photo essay on preservation shows why hardware context matters alongside technical facts. Record what the computer looked like, which accessories were attached and what software produced the trace. Future researchers may need those details to reproduce the result.

Turning Captures Into A Preservation Resource

Once the logger is stable, publish the design in layers. Start with a wiring diagram and safety notes, then provide the Pico firmware, host decoder and sample captures. Explain which signals are mandatory and which are optional. This lets another enthusiast build a reduced version without having to reproduce an entire experimental bench.

A shared capture library could document common port sequences for sound hardware, storage adapters, serial devices and custom expansion boards. Each trace should include metadata, checksum information and a plain-language description. Avoid publishing only screenshots: the original binary data allows other tools to verify timing and reinterpret the events.

The project also fits naturally with broader X68000 preservation work. Port activity can expose undocumented initialisation sequences, confirm how software detects hardware, and help recreate a board whose original documentation has disappeared. A Pico is inexpensive enough to remain attached to a development machine, yet capable enough to answer questions that would otherwise require a costly analyser.

Build the interface conservatively, validate it away from the computer, and begin with a narrow logging goal. Once trustworthy captures are being produced, the same hardware can grow into a reusable bus monitor for repairs, software archaeology and new X68000 expansions.

A well-documented Pico logger turns fleeting bus activity into evidence. Share the circuit, firmware and example traces with the X68000 community, and preserve both the working machine and the knowledge needed to understand it.