Simulating the X68000 with a custom HDL core

Recreating a Sharp X68000 in programmable logic is more than placing a 68000-compatible processor inside an FPGA. The original machine is a collection of tightly timed devices: a custom video system, DMA channels, interrupt sources, floppy and SCSI controllers, sound hardware, RAM, ROM, and a set of buses whose behavior software can observe. A convincing hardware description language core must reproduce those relationships as carefully as it reproduces instruction results.

That makes the project valuable for both preservation and experimentation. An FPGA implementation can provide a dependable way to run disk images, test software, inspect bus transactions, and explore hardware that is increasingly difficult to maintain. It can also complement physical restoration work, such as the documented process of recapping the X68000 monitor, by preserving the computer’s behavior independently of aging capacitors and custom chips.

The goal should be defined before any RTL is written. A cycle-accurate reproduction of every model revision is a substantial research project, while a practical FPGA recreation may begin with a compatible CPU, core memory map, display output, keyboard input, and a small set of storage devices. Both approaches are legitimate, but they require different priorities, test methods, and compromises.

Start with the machine’s observable contract

The most useful specification is not a list of internal chips. It is the behavior visible to software and external devices. Programs expect particular addresses to respond, interrupts to arrive under recognizable conditions, video memory to behave in a certain way, and peripherals to preserve ordering across reads and writes. These details form the platform’s observable contract.

The 68000 bus is an important starting point. A core must account for address, data direction, byte enables, asynchronous device completion, interrupt acknowledge cycles, and reset behavior. The original processor presents separate upper and lower data strobes, so a memory subsystem that treats every access as a simple aligned word transaction will eventually fail on byte operations. Odd addresses, peripheral registers, and unaligned sequences deserve dedicated tests.

The X68000 family also contains model differences. Memory capacity, video features, expansion hardware, and storage arrangements vary between machines, so a single implementation should expose configuration options rather than silently assuming one exact motherboard. A compatibility profile can select RAM size, ROM contents, display timing, and optional devices while retaining a common bus architecture.

Divide the core into testable devices

A clean HDL design separates the CPU, bus fabric, memory controller, video subsystem, sound interfaces, timers, DMA, interrupt controller, and storage adapters. This is not merely a matter of style. Independent modules allow a developer to compare a video renderer against reference images without involving floppy emulation, or to test interrupt behavior while the processor executes a small ROM monitor.

The CPU itself may be an existing 68000-compatible HDL implementation, a soft processor adapted from another project, or a custom core developed for the purpose. Reusing a tested CPU can shorten the schedule, but its bus timing and exception behavior still need to be checked against X68000 software. Differences in prefetch behavior, read-modify-write cycles, trace mode, and illegal instructions can expose assumptions in operating systems and games.

The memory map should be represented by explicit address-decoding rules. Fast RAM, system ROM, video RAM, expansion space, and I/O registers should not be scattered across unrelated conditional statements. A centralized decoder makes unmapped accesses, wait states, and bus errors easier to model. It also provides a natural place to add a diagnostic trace containing cycle type, address, data, device selection, and completion timing.

DMA deserves its own design rather than being treated as a faster CPU copy loop. It competes for memory access, can interact with video timing, and may alter the order in which peripherals see data. A first implementation can use a deterministic arbitration policy, but that policy should be documented and adjustable. Software that relies on transfer completion or interrupt timing may reveal problems long before visual output appears incorrect.

Treat video as a timing problem

Video is usually the most visible part of an FPGA recreation and one of the most difficult to reproduce convincingly. The X68000 display system combines multiple graphics functions, several pixel formats, programmable screen modes, and access to video memory that may be visible to the CPU while a frame is being generated. A renderer that produces the correct final image but ignores access timing can still break demos, raster effects, and scrolling techniques.

A practical design starts by identifying the minimum display modes required by the target software. Each mode should have a defined pixel clock, active area, blanking interval, synchronization behavior, and memory layout. The renderer can then be built as a pipeline: fetch graphics data, decode pixels or planes, apply priority rules, compose layers, and convert the result to an HDMI, VGA, or digital video format suitable for modern hardware.

The output interface need not reproduce the original analog signal exactly. It does, however, need stable frame timing and a reliable relationship between emulated scanlines and generated pixels. If the external video timing differs from the simulated timing, a line buffer or frame buffer can isolate the two domains. That approach makes modern displays easier to support, although it can hide mid-frame effects unless the internal renderer remains faithful.

Video RAM access is a useful early stress test. Fill patterns, scrolling screens, sprite-heavy scenes, palette changes, and software that writes registers during active display can reveal errors in address translation and priority logic. Capturing a reference frame is helpful, but a trace of register writes and scanline state often explains a failure much faster than comparing screenshots alone.

Recreate peripherals at the right level

Storage support is essential because much of the X68000 software library is distributed as floppy or hard-disk images. A full FPGA implementation does not need to reproduce the magnetic medium physically. It needs to expose controller registers, status transitions, data transfer timing, and image-backed sectors in a way that software recognizes. An SD card, compact flash device, or host-side file interface can supply the data behind that model.

Floppy behavior is particularly sensitive to status and interrupt sequencing. Returning the correct sector data while asserting ready or completion signals too early can cause boot failures or unreliable disk utilities. A useful staged implementation begins with read-only disk images, then adds writes, track handling, error injection, and media-change behavior. This keeps the early debugging surface manageable.

Sound can follow a similar path. Reproducing the YM2151 synthesizer and OKI ADPCM device in HDL is possible, but audio accuracy involves clock division, register timing, envelope behavior, interpolation, and mixing. A hybrid design may initially connect compatible sound cores or delegate audio generation to a host processor while the main FPGA focuses on the CPU and video system. Later, those external dependencies can be replaced as test coverage improves.

Expansion hardware offers an opportunity to connect the recreation with current enthusiast projects. The Nereid-X expansion board demonstrates how practical interfaces can extend the original platform; an FPGA core can provide analogous network, storage, or diagnostic functions through a well-defined virtual device. Such additions should be optional and clearly separated from the compatibility layer so that software sees a recognizable base machine.

Choose a fidelity target deliberately

There is no single definition of an “X68000 core.” A compact implementation that boots Human68k and runs selected games may be more useful to many owners than a deeply cycle-accurate model that requires a large FPGA and extensive proprietary ROM investigation. The important decision is to state which behaviors are guaranteed and which are approximations.

Area	Practical FPGA recreation	High-fidelity preservation core
CPU	Compatible 68000 behavior with documented timing limits	Bus- and exception-level timing matched to reference hardware
Memory	Configurable RAM and mapped ROM	Model-specific memory sizes, wait states, and failure behavior
Video	Correct modes and stable modern output	Scanline effects, contention, register timing, and model variations
Storage	Image-backed floppy or SCSI device	Controller state machines, delays, errors, and DMA interactions
Sound	Existing compatible cores or host-assisted audio	Recreated chips, clocking, mixing, and peripheral timing
Expansion	Optional FPGA-native devices	Reproduction of original expansion buses and edge cases
Validation	Boot tests, software compatibility, screenshots	Logic traces, hardware captures, timing comparison, and regression suites

A staged target reduces risk. The first milestone might run a ROM monitor and access RAM. The next could boot from a disk image, followed by keyboard input, text display, graphics modes, and sound. Each milestone should be reproducible from a known HDL revision and a fixed set of test images. Without that discipline, new features can make an earlier subsystem appear functional while quietly changing its timing.

Compatibility should also include failure behavior. Software may poll a busy bit, issue a command while a device is unavailable, or depend on an interrupt being cleared by a particular register access. A model that only handles the happy path can boot demonstrations yet fail when running disk utilities, development tools, or diagnostic programs. Negative tests are therefore part of preservation, not an optional refinement.

Build a verification workflow before polishing

Simulation is the core advantage of an HDL implementation, but it only pays off when the project has useful reference data. Start with small directed tests: reset, word and byte memory accesses, interrupt entry, timer rollover, DMA boundaries, palette writes, and peripheral register side effects. These tests should run quickly in a simulator and produce readable traces when they fail.

A differential test setup can compare the FPGA model with an existing emulator or a physical X68000. The comparison does not have to be cycle-for-cycle at first. Matching CPU-visible memory, register values, interrupt counts, and rendered frames at defined checkpoints can establish a strong baseline. For timing-sensitive features, logic-analyzer captures from real hardware provide valuable evidence, especially when emulator behavior is itself an approximation.

Known software is a practical validation suite. A boot ROM, Human68k command shell, text editor, disk formatter, graphics demo, sound test, and a selection of games each exercise different parts of the system. Homebrew programs are especially useful because their source code can expose the intended register sequence. Diagnostic software should be preserved alongside the core rather than treated as disposable setup material.

Regression testing matters as the implementation grows. Every change to the bus arbiter, clock generator, or video pipeline can affect unrelated devices. Automated builds can run HDL linting, unit simulations, ROM boot tests, and image comparisons. A small set of failure logs and waveforms is often more valuable than a large collection of undocumented screenshots because it records the precise condition that exposed the defect.

Account for clocks, licenses, and real hardware

Clock generation requires careful planning. The original system has relationships among the main CPU clock, video timing, sound clocks, peripheral rates, and memory access. An FPGA board may provide a convenient oscillator that does not divide cleanly into those frequencies. Multiple synchronous domains, clock enables, and carefully designed bridges are preferable to casually passing signals between unrelated clocks.

Reset sequencing deserves similar attention. The processor, video logic, audio devices, storage controllers, and external interfaces may require different initialization periods. A single reset pulse distributed everywhere can create race conditions or leave a device in an undocumented state. Explicit reset controllers and post-reset diagnostics make startup failures easier to distinguish from software bugs.

Hardware integration also affects the architecture. PS/2 or USB keyboards need a translation layer for the original keyboard protocol and scancode expectations. Modern video output may require TMDS encoding or a board-specific display pipeline. SD cards introduce their own clock and command domains. These interfaces should be isolated behind adapters so that the emulated machine remains stable when the FPGA board changes.

ROM and software distribution require care. Firmware images, operating systems, game disks, and sound data may have separate copyright and preservation rules. A project can publish HDL, test programs, address maps, and build scripts while asking users to supply ROM dumps from hardware they own. Clear provenance and checksums help researchers reproduce results without turning the core into an unexamined software bundle.

Recommended development priorities

A disciplined sequence keeps the project useful at every stage:

• Implement reset, CPU execution, RAM, ROM mapping, and a serial or diagnostic console first.
• Add the interrupt controller, timers, keyboard input, and a minimal text display before attempting advanced graphics.
• Build storage around read-only disk images, then verify command status, DMA, writes, and error handling incrementally.
• Use reference software, emulator comparisons, physical captures, and automated regression tests together.
• Separate original-machine compatibility from FPGA-native networking, debugging, and storage conveniences.

The core should expose diagnostic controls from the beginning. A memory-mapped trace buffer, selectable clock divider, frame counter, and breakpoint register can turn an opaque boot failure into a short investigation. These facilities need not be visible to ordinary software, but they should be stable enough for developers to use across revisions.

Documentation is another form of hardware preservation. Record address maps, timing assumptions, model differences, unsupported behaviors, and the source of every reference measurement. A future contributor should be able to determine whether a quirk is intentional, measured, inherited from an emulator, or simply unresolved. That history is as important as the RTL itself.

A custom HDL core becomes genuinely valuable when it is treated as a research instrument rather than a black-box console. Start with a narrow, testable machine profile, preserve every observation, and expand compatibility only when the existing behavior is understood. The result can serve original software, hardware developers, and historians while remaining flexible enough for new FPGA platforms.

Document the work alongside the source code, publish reproducible test cases, and connect the implementation to the wider X68000 community. Whether the first milestone is a booting ROM monitor or a complete disk-and-video system, each verified subsystem brings the machine’s architecture into a form that can be studied, repaired, and used for many years.