Using the X68000 expansion port with a logic analyzer

The X68000 expansion port provides an unusually useful view into the computer’s internal bus activity. With the right adapter, a logic analyzer can reveal address decoding, data transfers, interrupt behavior, wait states, and communication between the main system and an expansion board. It can also help distinguish a faulty peripheral from a problem in the computer’s bus, power supply, or timing logic.

This kind of investigation requires more preparation than attaching probes to a convenient row of pins. The expansion connector exposes digital signals that may be shared, driven by several devices, or connected directly to logic that is sensitive to accidental shorts. A disciplined setup protects the computer and produces captures that can be interpreted later.

The most useful results come from treating the analyzer as a bus-observation instrument rather than a simple waveform viewer. First identify the signals, establish safe electrical connections, and then capture short, repeatable transactions. The goal is to turn electrical activity into evidence about how the X68000 is operating.

What the expansion bus can reveal

The Motorola 68000 family uses a multiplex-free bus with separate address and data phases. During a typical access, the processor places an address on the address lines, asserts control signals, and either reads data from the selected device or writes data to it. Signals such as address strobe, read/write, upper and lower data strobes, and data transfer acknowledge provide the timing needed to understand that transaction.

An expansion connector may expose many of these bus signals, along with interrupt lines, reset, clock, power, and ground. The exact arrangement depends on the X68000 model, connector, and expansion hardware involved. Do not assume that a pinout from an XVI, Compact, or tower model applies unchanged to another machine. Verify the relevant service documentation, board markings, and continuity with power removed.

A logic analyzer can answer practical questions. Is the expansion board being selected at all? Does a read receive an acknowledge? Are byte lanes being strobed correctly? Does the bus stop during a failed access? Is a peripheral asserting an interrupt, or is the interrupt line stuck low? These observations are often more valuable than a general statement that the board “does not work.”

The analyzer will not automatically decode every X68000 transaction. Generic 68000 protocol decoders may require adjustment for signal names, active-low conventions, bus width, and timing. Even without a custom decoder, aligned digital traces can show whether an access repeats, whether an address changes, and where a transaction stops.

Preparing a safe connection

Use a sacrificial or purpose-built breakout adapter whenever possible. A short interposer board with labeled test points is safer than pushing individual jumper wires into a live connector. It also lets you connect the analyzer ground first, keep wires short, and remove the instrument without repeatedly stressing the original socket.

The analyzer and X68000 must share a reliable ground reference. Connect one or more ground leads close to the expansion connector, preferably using a ground pin on the same connector rather than a distant chassis point. Long ground wires add inductance and can turn fast signal transitions into ringing, overshoot, and false edges.

Never connect an analyzer input to an unknown pin simply because it appears beside a known signal. Establish whether the pin is ground, a power rail, an input, an output, or a bidirectional bus connection. Check resistance to ground and power with the machine unplugged, then confirm voltage levels with the computer powered on but the analyzer disconnected.

Most modern logic analyzers tolerate 5 V inputs, but not all do. Some low-cost units accept only 3.3 V, while others have a threshold that produces unreliable readings with older TTL logic. The X68000’s digital bus is generally associated with 5 V-era logic, but individual expansion boards may include buffers, pull-ups, or different logic families. An external level shifter or suitable high-voltage analyzer is safer than guessing.

Avoid powering the computer through the analyzer. The analyzer should receive power from its intended USB or external supply, and its ground should be shared with the target. If an adapter board includes level conversion, verify its direction and power sequencing before applying power to the X68000.

Selecting signals and sample settings

A full address and data capture can consume many analyzer channels. Begin with a reduced set that answers one question. For example, combine the clock, address strobe, read/write, one data strobe, and a few high-order address lines. Add data lines or lower address lines only after the basic transaction is visible.

The signal names printed in a schematic may use an overbar, slash, or suffix to indicate active-low operation. Logic analyzer software can display these signals inverted, which makes captures easier to read. Whether inversion is performed in hardware or only in the software display, document it clearly so a low level is not mistaken for an asserted high-active signal.

Sampling frequency must be high enough to show the edges of interest. A common starting point is at least four to ten times the fastest transition or clock frequency being examined, with a higher rate preferred when memory timing or ringing matters. For a roughly 10 MHz bus clock, a 50–100 MHz digital sample rate gives a more useful first capture than a marginal rate near the clock frequency.

Record a short pre-trigger period and a longer post-trigger period. Triggering on address strobe, a chip-select signal, or an interrupt edge is usually more productive than triggering on the clock, which may produce a constant stream of activity. If the expansion device has a known register address, trigger on the first control signal that should accompany access to that register.

Investigation goal	Useful first signals	Trigger idea	What the capture may show
Confirm bus activity	Clock, address strobe, read/write, data strobe	Address strobe edge	Whether the processor begins transactions
Check peripheral selection	Address strobe, address lines, device select, acknowledge	Device-select assertion	Whether address decoding responds
Diagnose a read	Read/write, data strobe, acknowledge, data lines	Read transaction	Returned data, floating lines, or a missing response
Diagnose a write	Read/write, data strobe, acknowledge, data lines	Write transaction	Correct data timing and register access
Investigate interrupts	Interrupt request, processor control lines, clock	Interrupt assertion	Whether the request occurs and clears
Find a stalled cycle	Address strobe, acknowledge, reset, clock	Address strobe	A transaction that never receives completion

Interpreting a 68000 bus transaction

A normal transaction should have a recognizable relationship between address, control, data, and completion. The processor presents a stable address, asserts the appropriate strobe, and waits for the selected device to acknowledge the transfer. During a read, the peripheral drives the data bus at the required time. During a write, the processor drives data and the peripheral captures it while the write strobes are active.

The exact timing includes setup and hold intervals, so the signal that changes first is not always the signal that carries the important meaning. Use the clock as a reference, but pay close attention to the width and ordering of address strobe, upper data strobe, lower data strobe, and data transfer acknowledge. Acknowledge arriving too early, too late, or not at all can explain software hangs and bus errors.

A 16-bit 68000 data bus uses separate upper and lower byte strobes. A byte access may activate only one lane, while a word access normally involves both. If an expansion device responds to the wrong lane, software may read an unexpected value even though the address decode appears correct. Capturing both data strobes is therefore important when diagnosing registers that are accessed as bytes.

Tri-state behavior deserves special attention. Data lines should not be driven continuously by an idle peripheral, because the processor and other devices must share the bus. A line that remains fixed high or low may indicate a short, a failed buffer, an incorrect enable signal, or simply a pull-up. Compare the suspect line with a known-good transaction and inspect whether it becomes high impedance between accesses.

A stalled bus cycle can be especially revealing. If address strobe remains active while acknowledge never appears, the processor may be waiting for the expansion device or for external logic to complete the transfer. If acknowledge appears but the data is invalid, investigate data direction, byte strobes, and signal integrity. If the whole machine resets or locks immediately after a transaction, capture reset and power-related signals as well as the bus.

Working with captures and decoders

Save captures in the analyzer’s native format and export a text or CSV version when possible. Record the X68000 model, expansion board revision, software action, analyzer sample rate, probe arrangement, and whether the machine was cold or already running. Reproducibility matters because a single capture can contain startup activity unrelated to the fault.

Start by finding a transaction that is known to work. A board identification command, a simple status read, or a deliberate write to a harmless register creates a reference waveform. Once that pattern is understood, compare it with the failing operation. Differences in address, strobe width, acknowledge delay, or data direction often stand out more clearly than an isolated failed capture.

Protocol decoding is useful when it is grounded in the electrical evidence. A script can combine address lines into hexadecimal values, identify read or write cycles, and report the timing between strobe and acknowledge. It should also flag incomplete cycles rather than silently discarding them. A decoder that assumes every event is valid can hide precisely the fault being investigated.

Use the wider X68000 community as a source of cross-checks rather than treating every posted waveform as universal. Hardware revisions, accelerator boards, repaired power supplies, and aftermarket expansions can change loading and timing. The X68000 resource links provide a useful route to documentation, projects, and related technical references while you build a model of the particular system on the bench.

Avoiding misleading measurements

Digital analyzers report threshold crossings, not the complete analog shape of a signal. A waveform may look like a clean logical pulse while suffering from slow rise time, ringing, or a voltage level that is marginal for the receiving chip. If the capture changes when the probe ground is moved, the setup is affecting the circuit.

Keep each signal lead short and route groups of related wires together. Excessive flying leads increase crosstalk, especially around clock and strobe lines. If the breakout board permits it, use a ground beside every group of high-speed signals. Passive analyzer probes are usually adequate for first-pass bus work, but an oscilloscope is valuable when edge quality or overshoot is suspected.

Do not probe a live connector while holding loose metal tips near adjacent pins. Power down before changing the wiring, and inspect for solder bridges or shifted headers before powering up again. If the expansion board has exposed edge contacts, protect unused pins and use keyed connectors where practical.

Power problems can imitate bus faults. A weak supply, damaged filter capacitor, or poor connector contact may cause intermittent logic errors that appear only during disk access or graphics activity. Before relying on a difficult capture, verify the 5 V rail at the computer and expansion board under load. A repair record such as CRT flicker troubleshooting also illustrates why symptoms elsewhere in a vintage system can originate in power or signal conditions rather than in the most visible component.

A repeatable bench procedure

The following sequence keeps the investigation controlled and makes each capture easier to compare:

• Confirm the connector pinout and identify ground, power, clock, control, address, and data signals from reliable documentation.
• Build or use a labeled breakout adapter, then verify continuity and the absence of shorts with the X68000 unplugged.
• Measure the target voltage and confirm that the analyzer inputs are rated for the observed logic levels.
• Capture a known-good access with a moderate channel count before adding every available bus line.
• Repeat the same software action several times and compare timing, acknowledge behavior, and data values.

Once the basic transaction is stable, add channels according to the fault hypothesis. Include interrupt lines when software waits for an event, reset when the system unexpectedly recovers, and chip-select or decoder outputs when the address appears correct but the board does not respond. Change one physical or software variable at a time.

For a custom expansion such as a memory, storage, network, or serial interface board, capture both sides of the interface if test points are available. Comparing the X68000 bus with the board’s internal decoded select or peripheral control lines can show whether the problem occurs before or after address decoding. This divide-and-measure approach prevents unnecessary changes to working circuitry.

Treat every modification as reversible. Keep original connectors, label adapters, and save the working capture before changing termination, pull-ups, firmware, or bus timing. A logic analyzer is most effective when it supports careful preservation work rather than encouraging repeated trial-and-error on irreplaceable hardware.

Use the captured evidence to document the expansion interface for future repairs and projects. Share pinout corrections, timing observations, and board-specific findings with clear model and revision details, then apply those records when maintaining your own X68000. Connect the analyzer, capture a known-good cycle, and turn the next unexplained bus error into a trace that can be inspected, compared, and understood.