Using an FPGA to simulate an X68000 main board for peripheral testing

The Sharp X68000 is an unusually rewarding platform for hardware experimentation. Its 68000 processor, custom graphics and sound devices, expansion connectors, and highly distinctive peripheral interfaces provide plenty of opportunities for repairers and developers. They also make testing difficult when an original main board is expensive, incomplete, or unreliable.

An FPGA-based test platform can reproduce the digital behaviour that an expansion board expects without requiring a fully working X68000 for every experiment. Used carefully, it becomes a controllable substitute for the computer’s bus, memory map, interrupts, and selected peripheral signals. It will not automatically reproduce every analogue characteristic or timing quirk, but it can greatly reduce the risk and cost of developing modern replacements for ageing hardware.

What the FPGA needs to reproduce

The first decision is whether the FPGA will act as a complete X68000 replacement or as a focused motherboard simulator. A full recreation requires a compatible 68000 implementation, RAM, ROM, video hardware, interrupt logic, DMA behaviour, and many custom chips. That is a substantial computer architecture project. A peripheral test fixture can be much smaller: it may generate bus cycles, respond to reads and writes, provide interrupt inputs, and expose the signals needed by one expansion board.

The X68000’s main bus is central to this approach. A test design needs to model address and data lines, read and write strobes, bus arbitration where relevant, reset, clocking, and interrupt levels. It also needs to respect the electrical direction of each signal. A peripheral may drive data only during a read cycle, while the simulator drives it during a write. Incorrect tri-state control can cause contention between the FPGA and the device under test.

A useful architecture separates the FPGA logic into three layers. A bus engine produces realistic 68000-style transactions, a peripheral model translates those transactions into expected device behaviour, and a test controller records results. This makes it possible to test a Nereid-style network or storage interface without first implementing every X68000 video and audio function.

Choosing a practical hardware platform

A development board should provide enough FPGA I/O, suitable voltage translation, reliable clock sources, and a convenient way to capture test results. Many modern FPGA boards use 3.3-volt I/O, while vintage expansion hardware may expect 5-volt TTL levels or have signals that should never be connected directly to a contemporary FPGA pin. Bidirectional level shifters, buffers, series resistors, and proper direction control are essential.

The connector deserves as much attention as the HDL. An adapter board can reproduce the relevant X68000 expansion socket, add labelled test points, and isolate the original peripheral with removable links. This is safer than wiring a development board directly to a rare expansion card. Include protection for reset and external clock signals, and provide a controlled way to power the device under test. A separate bench supply is preferable to drawing unknown current through a small FPGA board.

Australian availability affects component selection. Boards and logic parts may arrive through element14, RS, Jaycar, or specialist eBay sellers, with shipping times and stock changing quickly. A design that depends on an obscure Japanese connector can stall for weeks, so it is sensible to document compatible substitutes and order spare sockets. Builders in Melbourne, Sydney, Brisbane, or Perth may also need to account for different access to local electronics shops and repair facilities.

An FPGA with internal block RAM is useful for ROM images, scripted bus transactions, and diagnostic buffers. A board with a USB connection can stream traces to a computer, while an SD card can hold test scripts or firmware images. The ideal platform is not necessarily the largest device; predictable I/O timing and easy probing are usually more valuable than unused logic capacity.

Building the bus model

A bus model should begin with simple transactions rather than attempting to imitate an entire operating system. Generate a reset sequence, place an address on the bus, assert the correct read or write control, wait for the peripheral’s response, and release the lines cleanly. Start with one address range and a small set of registers. Once that works on a logic analyser, add wait states, interrupts, and more complex accesses.

Timing needs to be measured in clock edges, not described vaguely as “fast enough”. The peripheral may expect setup time before a strobe, a minimum pulse width, or a response within a particular number of cycles. FPGA logic is synchronous, so an internal clock several times faster than the simulated bus can provide useful resolution. A phase accumulator or clock-enable scheme can then produce repeatable bus timing without relying on unstable software delays.

Some X68000 peripherals behave as though they are attached to a processor bus, but their real-world signals may include asynchronous inputs. Interrupt requests, DMA acknowledgements, cartridge detection, and external clocks must be synchronised before entering the FPGA’s main clock domain. Use two-stage synchronisers for ordinary control inputs, and use handshaking or asynchronous FIFOs when event loss would affect the test.

A recorded trace from a functioning X68000 is particularly valuable. Capturing address, data, control, interrupt, and relevant peripheral signals during boot or a known diagnostic operation creates a reference waveform. The FPGA can replay that trace, compare a device’s response against expected values, and flag differences at the first failing transaction. A project diary can also provide useful context about repair observations, board revisions, and the sort of undocumented behaviour that a formal schematic may omit.

Modelling peripherals and failure conditions

Peripheral testing becomes useful when the simulator behaves like a difficult, imperfect host rather than an endlessly cooperative one. A network or storage expansion card may need to handle sequential register accesses, interrupts arriving at inconvenient times, and bus cycles separated by variable gaps. Test scripts should include normal operation, delayed responses, repeated reads, invalid commands, reset during activity, and unexpected termination of a transfer.

For a Nereid-like board, the FPGA could expose its memory-mapped registers, provide a simulated boot environment, and emulate the host actions needed to initialise the controller. It could then verify that status bits change in the correct order, interrupts are asserted and cleared properly, and the interface remains usable after a reset. The actual Ethernet transceiver or physical network connection would still require separate testing, since digital register behaviour cannot prove analogue signal integrity.

This distinction matters for storage, MIDI, and other expansion hardware as well. An FPGA can check register decoding, bus timing, interrupt handling, DMA descriptors, and firmware-visible errors. It cannot, by itself, validate SCSI termination, a MIDI optocoupler, analogue audio levels, connector shielding, or the quality of a differential Ethernet waveform. Those tests need oscilloscopes, protocol analysers, loads, or real companion devices.

Fault injection is one of the strongest benefits of a programmable test host. Add options to hold a status bit busy, delay an interrupt, return a parity-like error code, truncate a transfer, or reset the simulated CPU halfway through a command. A reliable peripheral should fail cleanly and recover predictably. This is much harder to repeat with a borrowed original computer and a collection of manually triggered faults.

Connecting original hardware safely

The simulator should be treated as laboratory equipment connected to vintage hardware, not as a casual development accessory. Confirm the pinout from several sources before applying power, especially if the connector can be inserted incorrectly or if documentation covers multiple X68000 revisions. Check continuity with a multimeter, verify ground locations, and measure the peripheral’s idle voltages before attaching an FPGA.

Power sequencing can be important. Some boards derive reset behaviour from the host supply, while others expect a stable clock or control signal before their logic becomes active. Use current limiting during the first test and monitor the 5-volt rail with an oscilloscope. A modern bench supply with adjustable current protection is safer than relying on an original switch-mode unit that has not yet been inspected.

Australian mains conditions add a practical safety concern. The local supply is nominally 230 volts at 50 Hz, whereas an X68000 was designed for Japanese mains conditions and may have been modified by a previous owner. The FPGA fixture should use its own certified low-voltage supply and should never become a reason to energise an exposed vintage power supply. For repairs in a home workshop in Adelaide or Canberra, an RCD-protected outlet and a properly earthed bench are sensible minimum precautions.

Mechanical strain is another common source of failure. Heavy expansion boards can flex an old connector when supported only by an adapter cable. Use a fixture that supports the board, keeps cables short, and separates test points from the insertion force. Label every cable and photograph the setup before changing it; this simple habit prevents many avoidable mistakes during repeated hardware tests.

Verification, firmware, and repeatable results

A good test system produces evidence rather than a vague pass or fail. For every transaction, record the simulated address, data, control state, response latency, and any interrupt event. A compact binary trace can be captured in block RAM and exported over USB after a run. Add a test identifier, firmware revision, FPGA bitstream hash, and supply voltage to the log so that later results remain meaningful.

Use layered verification. HDL simulation can check bus state machines before hardware is connected. Loopback tests can verify level shifters and connector wiring. A known-good peripheral can establish a baseline, followed by a repaired or newly manufactured board. When a test fails, compare the first divergent transaction rather than inspecting only the final symptom. A single missing wait state may eventually appear as a corrupt packet or a frozen boot screen.

For firmware development, a small monitor program is often enough. It can write a register, poll a status bit, trigger a transfer, and report the response through a serial console. More advanced designs may include a soft-core CPU inside the FPGA, allowing scripts to run locally and making the fixture independent of a host computer. Keep the test commands documented and version-controlled so another enthusiast can reproduce the setup.

The preservation value extends beyond one board. A carefully captured bus trace can help document undocumented expansion behaviour for future repairs. Notes about revisions, signal names, and observed timing should be stored beside schematics and HDL sources. The broader Nereid-X expansion project provides an example of why practical hardware notes matter: a working board is valuable, but a clearly recorded design and testing method makes that knowledge reusable.

Comparing testing approaches

Different projects call for different levels of emulation. A logic analyser is excellent for observing a real X68000, while an FPGA fixture is better for repeating controlled host transactions and injecting faults. A full FPGA recreation offers the greatest independence, though it demands substantially more development and verification.

Approach	Best use	Main advantage	Main limitation
Original X68000 main board	Final compatibility checks	Authentic timing and custom-chip behaviour	Age, cost, repair risk, and limited repeatability
Logic analyser on a working machine	Capturing reference activity	Shows real signals and undocumented sequences	Cannot actively replace the host or inject every fault
FPGA bus and peripheral simulator	Development and regression testing	Repeatable cycles, scripted faults, and detailed traces	Requires careful electrical and timing design
Complete FPGA computer recreation	Stand-alone platform testing	Can boot software without vintage hardware	Large implementation effort and possible behavioural gaps
Modern microcontroller fixture	Simple register-level tests	Low cost and quick firmware iteration	Less suitable for precise bus timing and high-speed parallel signals

The most practical route is usually incremental. Begin with a passive capture adapter, then add FPGA-driven bus cycles for one register block. Add interrupts, wait states, and error injection only after the electrical interface is trusted. Finally, connect a real X68000 for comparison. This staged method keeps the project useful at every milestone and prevents an ambitious recreation from becoming a substitute for testing.

A successful fixture should leave the original computer as the reference authority, not make it irrelevant. Test the peripheral against the FPGA, then confirm important results on a known-good X68000. Where the two disagree, preserve both traces and investigate clock sources, bus termination, wait-state assumptions, and custom-chip side effects before changing the device under test.

Build the simulator around one well-defined peripheral, publish the pinout and timing assumptions, and keep the HDL, test scripts, and captured traces together. That approach can turn scarce working hardware into a reference instrument rather than a disposable development target. For Australian enthusiasts preserving X68000 systems, an FPGA test bench offers a safer way to repair, reproduce, and extend the platform while keeping its original machines available for the tests that only authentic hardware can provide.