Building a Digital I/O Card for the X68000 Expansion Bus

The Sharp X68000 is an unusually welcoming platform for hardware experimentation. Its Motorola 68000 processor, accessible expansion architecture, and well-understood peripheral ecosystem make it possible to add modern digital interfaces without hiding the machine behind a completely new controller. A carefully designed expansion card can provide GPIO, switch inputs, relay control, LED drivers, sensor connections, or a bridge to contemporary microcontrollers.

Using the X68000 expansion bus for a digital I/O card requires more than connecting an 8-bit port to the data lines. The card must decode addresses, respect the bus timing, isolate external voltages, and behave predictably when the computer accesses byte-wide or word-wide registers. The safest design is one that treats the expansion connector as a shared system bus rather than as a collection of convenient pins.

This work also fits the preservation goals documented throughout X68K.NET resources, where repair notes, expansion projects, and software tools help keep original hardware useful. A digital I/O board can be both a practical accessory and a compact lesson in how the X68000 communicates with custom peripherals.

Why the expansion bus is useful

The expansion bus exposes enough of the X68000’s system activity to support memory-mapped peripheral hardware. Instead of requiring a special serial protocol, an I/O card can appear at a fixed address range. Software writes a value to an output register, and the card changes its pins; software reads an input register, and the card returns the current logic state.

This approach is fast and natural for 68000 software. A simple output operation can update eight or sixteen lines with a single instruction, while input registers can be polled during games, laboratory experiments, or custom control applications. Interrupt support can also allow the card to notify the computer when an external signal changes, although interrupt wiring should be treated as an optional second stage rather than as a starting requirement.

The bus is shared with other hardware, so the card must never drive signals when it has not been selected. Address decoding and output-enable control are therefore central to the design. A board that produces the right result in a minimal test can still interfere with memory or another peripheral if its decode logic is too broad or its transceivers remain active during unrelated cycles.

Start with the electrical specification

Before drawing a schematic, establish the exact connector pinout and signal conventions for the X68000 model being used. Expansion arrangements and available signals can vary between machines or accessories, and a pinout copied from an unverified source can put a processor bus line at risk. The documentation collected in the hardware diary is useful background, but every design should still be checked against service information, continuity measurements, and the target computer.

A digital I/O card normally needs address lines, data lines, read and write strobes, a selection or bus-control signal, power, and ground. It may also use reset, interrupt, or timing signals. The design should identify which signals are actively low, when they are valid, and whether they are driven by the computer, the card, or both. Signal names with an overbar or a suffix such as “L” commonly indicate active-low behavior, but the schematic should state this clearly rather than relying on typography alone.

The external connector deserves separate attention. Original X68000 logic is based around 5 V-era digital circuitry, while modern sensors and microcontrollers often use 3.3 V. A 3.3 V input may be recognized by a 5 V logic input, but that assumption should be verified for each device. Outputs from the X68000 card should not expose 5 V directly to 3.3 V-only peripherals. Use level translators, open-drain interfaces, resistor dividers where appropriate, or dedicated buffer devices with defined voltage limits.

Pick a register and address strategy

A basic card can use a small programmable-logic device, an address decoder, and one or more octal bus transceivers. An alternative is a classic parallel I/O component such as an 8255-compatible interface, provided its timing and voltage requirements suit the bus. A microcontroller can add buffering and sophisticated protocols, but it should not replace transparent bus behavior with an unpredictable firmware dependency.

A compact register map might reserve four or eight addresses. One location can hold output data, another can report input data, and additional locations can contain direction, control, or interrupt status bits. If the board has two independent eight-bit ports, each port can receive a read register and a write register. Keeping the map aligned with the data width expected by the software makes driver code easier to audit.

The Motorola 68000 has important details concerning byte selection and bus cycles. The card should account for upper- and lower-byte strobes rather than assuming that every access is a full 16-bit transfer. A design that only connects eight data lines may need to respond to one selected byte lane and ignore the other. Register addresses should also be chosen so that the intended byte access is unambiguous in assembly language and C.

Design area	Conservative choice	Reason
Bus interface	Registered or buffered transceivers	Limits loading on the computer bus
Address decode	Full, explicit decode of the assigned range	Prevents accidental responses to other addresses
Data direction	Separate read and write enable control	Avoids contention during bus turnaround
GPIO voltage	5 V-tolerant buffers with protected external pins	Accommodates mixed-era equipment
Output reset state	All outputs inactive after reset	Reduces risk to attached devices
External protection	Series resistors, clamp strategy, and optional fuses	Helps survive wiring mistakes
Interrupts	Open-drain or otherwise shared-safe signaling	Prevents multiple cards from fighting the line
Software interface	Fixed registers with documented bit meanings	Makes drivers and test utilities maintainable

Build the bus interface in layers

The first layer should be the connector and protection network. Add a clearly marked ground reference, bulk decoupling near the connector, and local ceramic capacitors beside every logic device. Series resistors on fast external lines can reduce ringing, while resettable protection or small fuses can limit damage from a shorted peripheral. These parts do not make an unsafe circuit safe by themselves, but they improve the chance that an error remains local.

The second layer is address and control decoding. A GAL, CPLD, or small logic IC can combine address bits with read and write strobes to generate chip-select signals. Full decoding is preferable when practical. Partial decoding saves components but creates address aliases, which can confuse software and cause unexpected activation if another device accesses a similar address.

The third layer is the actual port circuitry. Use a buffer that disconnects its outputs when the card is not selected, and ensure the read path is enabled only during a valid read cycle. Output latches should be separate from input buffers so the card can maintain an output value while sampling external inputs. If bidirectional GPIO is required, direction control must change only when the bus is idle or through a carefully defined register sequence.

A CPLD can combine decoding, wait-state generation, latching, and interrupt logic in one device. It is attractive for a refined revision, but a first prototype built from visible, replaceable logic is easier to probe. A diagnostic header for address, data, chip-select, and read/write signals can save considerable time when the board does not behave as expected.

Make timing and reset behavior predictable

The card must satisfy the setup, hold, and access-time requirements of the X68000 bus. A slow peripheral may need wait states if the expansion interface and target machine support them in the intended manner. If wait-state behavior is uncertain, begin with simple latch-and-buffer logic that responds well within the bus timing rather than adding a complex asynchronous path.

Read data should become valid only after the card is selected and a read cycle is active. It must be released before another bus master or peripheral drives the data lines. This is especially important when using discrete transceivers, because an incorrectly wired output-enable signal can create contention that is invisible in ordinary software but damaging electrically.

Reset handling deserves a defined policy. On power-up or system reset, outputs should default to a harmless state such as logic low, high impedance, or an inactive control level, depending on the attached equipment. A relay driver should not energize unexpectedly, a motor controller should remain disabled, and a connected microcontroller should not receive a stream of invalid commands while the X68000 is starting.

External inputs should also have known idle levels. Pull-up or pull-down resistors prevent floating CMOS inputs from producing random values. For switches and long cables, add debounce in hardware or software and consider transient protection. An input intended for a clean laboratory signal may need a Schmitt-trigger buffer when it is connected to a mechanical contact or a cable running near video and power wiring.

Write software that exposes the hardware clearly

A small test program should be written before the board is considered complete. Start by reading the input register repeatedly and displaying its value on the screen. Then write walking-bit patterns to the output register, followed by alternating patterns such as hexadecimal AA and 55. These tests reveal stuck lines, swapped bits, incorrect byte-lane handling, and outputs that are enabled at the wrong time.

The driver should define symbolic register addresses and bit masks rather than scattering numeric constants through application code. A simple API might provide functions for reading a port, writing an output value, changing direction, and clearing status flags. The implementation can be in C, assembly, or a small command-line utility, but the register behavior should be documented alongside the schematic.

Interrupts are useful for event-driven input, such as a rotary encoder, pulse counter, or alarm signal. They also introduce additional questions: which interrupt level is used, how is the source acknowledged, and how does the card avoid repeated interrupts while a condition remains active? Begin with polling, prove that the register interface works, and add interrupt logic only when the electrical and software behavior can be tested independently.

Test the card without risking the computer

Use a current-limited bench supply and inspect the board for shorts before inserting it into an X68000. Verify resistance between power and ground, check connector orientation, and confirm that every integrated circuit has its correct supply voltage. A logic analyzer or oscilloscope is valuable for checking chip-select timing, read-data enable, and whether the bus is released between accesses.

A loopback fixture makes testing repeatable. Connect output bits to input bits through resistors or a protected harness, then run patterns that exercise every line. Test the card with no external load, with expected loads, and with the longest intended cable. Measure voltage levels at the card and at the far end, since a signal that looks correct locally may degrade significantly on a poorly terminated cable.

Do not use valuable peripherals during the first tests. LEDs with suitable resistors, DIP switches, and protected logic inputs are better initial loads than motors, relays, or vintage equipment. Once the digital interface passes repeated reads and writes, add driver transistors or MOSFET stages for higher-current loads. Keep inductive loads away from the bus card unless flyback suppression, separate power wiring, and grounding have been planned.

Practical design choices for a first revision

A reliable prototype benefits from a deliberately modest feature set. Eight inputs and eight outputs are enough to prove the address map, bus timing, reset behavior, and external protection. Additional ports can be added after the basic card has survived long test runs on more than one machine.

• Use full address decoding and publish the selected address range in the hardware documentation.
• Add buffers between the expansion connector and every externally accessible signal group.
• Make the reset state safe for LEDs, switches, relays, and connected microcontrollers.
• Provide test points for power, ground, chip select, read, write, and at least one data line.
• Keep the first software utility small, deterministic, and capable of reporting raw register values.

The board documentation should include a schematic, connector orientation, register map, voltage limits, timing assumptions, and a warning about unsupported loads. Photographs of the assembled card and a record of measured signals are valuable to future builders. Good documentation turns a one-off experiment into a maintainable part of the X68000 hardware community.

A digital I/O card is most successful when it respects the character of the original machine while adding a carefully bounded modern capability. The expansion bus provides the connection, but disciplined decoding, buffering, protection, and software make that connection dependable. Once the basic card works, it can become a foundation for robotics controls, music hardware, test instruments, network accessories, or preservation projects.

Document each revision and publish the schematics, test programs, and observed timing so others can reproduce the work. Build the first prototype conservatively, verify it with inexpensive loads, and use the results to refine the next version of your X68000 expansion hardware.