Building a bootable diagnostic ROM for the X68000 expansion slot

A bootable diagnostic ROM can turn an X68000 expansion slot into a practical service tool. Instead of relying on a working hard disk, floppy drive or operating-system installation, the computer can start from a small ROM board, test essential hardware and report useful results through the display, serial port or simple status indicators. This is especially valuable when restoring a Sharp X68000 that has been stored for decades.

The project sits at the intersection of 68000 programming, bus timing, ROM hardware and X68000-specific video access. A successful design must do more than contain executable code: it must be electrically safe, mapped into an address range the machine can reach, and able to start before the normal boot process depends on untested components. Careful staging turns the expansion card into a repeatable diagnostic platform rather than another source of faults.

Understand the expansion bus before writing code

The first task is to identify exactly what the expansion slot provides on the target X68000 model. Different machines and expansion boards may expose different signals, address decoding arrangements and mechanical formats. Documentation from the service manual, a trusted pinout, or a known-working interface board should be treated as the authority. Do not assume that a connector described as an “expansion slot” behaves like a modern plug-and-play bus.

A 68000-family bus commonly involves address lines, data lines, read and write strobes, address strobe, data transfer acknowledgement, reset, clock and power rails. A ROM board needs to respond to the correct chip-select or decoded address range and must observe the bus timing expected by the computer. If the board drives the data bus when another device is active, the result can be unreliable operation or permanent damage to a custom chip.

The reset behaviour is equally important. A ROM fitted to an expansion connector will not automatically execute merely because it contains valid 68000 instructions. The X68000’s IPL process must either recognise the expansion ROM, jump to its mapped address, or be modified through a suitable boot mechanism. Some designs therefore use a ROM board that occupies a known boot-visible region, while others rely on a small loader or an existing IPL extension.

Before fabricating a PCB, make a written map of the target signals:

• Power rails and their permitted voltage ranges
• Ground pins and connector orientation
• Address and data bus width
• Upper- and lower-byte selection signals
• Read, write, acknowledge and reset timing
• ROM enable or board-select logic
• Address configuration links or switches
• Any signals that must remain high impedance during reset

This documentation becomes the foundation for both the schematic and the diagnostic software.

Choose a ROM architecture that can be serviced

A simple diagnostic board can use a mask ROM, EPROM, EEPROM or flash device. The best option depends on how often the program will change and how closely the device matches the expansion bus. A UV EPROM is historically appropriate and easy to verify, but erasing and programming it is slow. Parallel EEPROM or flash allows faster development, although some parts require voltage levels and write-control arrangements that are unsuitable for a direct bus connection.

The 68000 has a 16-bit data bus, so the ROM arrangement needs attention to byte lanes. A board may use one 16-bit-wide memory device, a pair of 8-bit devices, or a narrower ROM with suitable multiplexing. Upper-byte and lower-byte strobes must be connected correctly. A swapped lane can produce an apparently dead machine, a screen full of invalid opcodes or a reset loop that looks like a software problem.

Include a way to isolate the ROM during troubleshooting. A jumper, socketed logic device or removable address-select link can prevent a faulty decode circuit from holding the bus. Series resistors on control or data lines may help limit contention during early testing, although they are not a substitute for correct logic design. Add decoupling close to every memory and logic IC, and keep the reset and enable paths short.

The diagnostic image should be reproducible. Store the source code, linker script, ROM-generation script and checksum in the project repository. Record the exact memory device, programming voltage and board revision. A small label on the physical ROM showing the build identifier is useful when several versions are being tested on the bench.

Build a diagnostic program that starts with almost nothing

The boot image needs a minimal 68000 entry point. At reset, the processor obtains an initial supervisor stack pointer and program counter from the vector area. The ROM image must place valid values where the machine’s boot path expects them, or provide the format required by the expansion-ROM loader. The first instructions should establish a known stack, disable or mask interrupts and avoid calling routines that depend on RAM, the operating system or uninitialised custom hardware.

A staged startup makes faults easier to localise. Begin with a short delay and a visible heartbeat. Next test a small region of RAM with patterns such as alternating bits, walking ones and walking zeroes. Only after the stack and working memory have passed should the program enable more advanced output, interrupts or disk-related tests.

Video output is attractive because it needs no external equipment, but direct X68000 video access must be approached carefully. The diagnostic can initialise only the minimum graphics registers required for a stable text display, or write to a known text or bitmap area after confirming the relevant VRAM and display mode. A serial console is often simpler during development, especially if the machine’s display hardware is also under suspicion. A few output methods make the tool more useful:

• A serial message for detailed logs
• A compact on-screen status line for normal bench work
• A hexadecimal error code for machines with limited video
• A heartbeat LED or logic probe point for early execution
• A checksum or build identifier shown before testing begins

The test suite should avoid false confidence. A passing ROM checksum proves that the image is intact, not that the expansion bus is reliable. A passing RAM test does not validate the floppy controller, graphics hardware or DMA. Report each result separately, with clear boundaries such as “ROM execution”, “stack RAM”, “video output”, “interrupt response” and “storage interface”.

Diagnostic approach	Hardware required	Main advantage	Typical limitation
Direct boot ROM	ROM device, address decoding and bus interface	Starts without disk media or operating system	Must match the X68000 boot and mapping behaviour
ROM plus serial console	Direct boot ROM and serial connection	Detailed logs and simple display-independent debugging	Requires a compatible serial adapter and terminal
ROM plus video test	Direct boot ROM and video initialisation code	Convenient standalone results	Video registers and VRAM may be part of the fault
Loader from disk	Working floppy or hard disk plus loader software	Easier image updates and larger test programs	Cannot help when storage or boot firmware is broken
External logic analyser	Probe points and test equipment	Reveals bus cycles, timing and contention	Does not provide a self-contained diagnostic result

Validate the hardware without risking the computer

Initial testing should happen away from a valuable original machine where possible. Check continuity between every power pin and ground, verify connector orientation, and inspect for solder bridges under magnification. Measure resistance on the power rails before applying power. If a programmable logic device or decoder is fitted, test its programmed equations independently and confirm that unused outputs remain inactive.

Use a current-limited bench supply or a protected adapter during the first power-up. The original X68000 power supply is a known restoration concern, and its condition should be established before adding an experimental card. Australian owners also need to remember that Japanese X68000 systems were designed around Japanese mains conditions, commonly 100 V, while domestic Australian power is 230–240 V. A suitable step-down transformer, correct fusing and an inspected power supply are essential; an expansion ROM cannot compensate for an unsafe mains arrangement.

A logic analyser or oscilloscope can confirm that address, read and enable signals behave as expected. Look for a clean reset release, valid ROM selection, appropriate data setup and hold times, and the absence of two devices driving the bus simultaneously. If the processor repeatedly fetches the same address, inspect reset and acknowledge handling before changing the software. If it fetches varied addresses but displays nonsense, investigate byte ordering, vector placement and video setup.

Test progressively:

• Power the board with the ROM disabled.
• Confirm that the machine still starts in its ordinary configuration.
• Enable the ROM but use a minimal image that emits one known result.
• Add memory tests only after execution is stable.
• Compare bus captures between a working and failing build.
• Run the board for an extended period to expose heat and intermittent-contact faults.

Use an edge connector or adapter that fits firmly without forcing the X68000’s socket. Tarnished contacts are common on older Japanese hardware, but aggressive abrasion can remove plating. A proper contact cleaner and careful inspection are preferable to repeated insertion of a rough prototype.

Extend the tool for restoration work

Once the boot path is reliable, the diagnostic ROM can become a reusable platform for preservation projects. A board-identification screen can show the ROM revision, detected RAM size and enabled test modules. A memory map display can help identify address conflicts with Nereid-X or other expansion hardware. Optional tests can probe interrupt lines, DMA channels, timers and peripheral registers, provided each test is written to avoid destructive writes.

The ROM can also provide a controlled way to test repaired power supplies and intermittent hardware. For example, a long-running RAM pattern test can expose marginal memory chips, while a serial log can record resets or bus errors over several hours. A conservative temperature test is preferable to deliberately stressing a component beyond its normal operating conditions.

Storage diagnostics deserve special care. A floppy drive test should distinguish between motor operation, disk-change sensing, controller response and actual data transfer. Hard-disk or SCSI testing should begin with identification and read-only operations. A diagnostic image that writes automatically to an unknown disk can destroy valuable software, so destructive tests should be separated behind an explicit build option or physical switch.

The project is well suited to the Australian X68000 community, where replacement parts and donor machines may arrive through eBay Australia, Japanese auctions or local listings on Gumtree. Shipping a fragile system between Sydney, Melbourne, Brisbane or Adelaide for repair is expensive and risky. A small bootable test board lets owners collect meaningful fault data locally before sending hardware interstate or overseas. It also gives enthusiasts a common test method when documenting repairs for others.

Keep the software portable within reason. Separate the 68000 startup code, bus-level routines, video driver and individual tests into modules. Record which X68000 model and expansion configuration each test supports. A diagnostic ROM intended for an XVI may need different assumptions from one used with an early Compact or a machine fitted with third-party memory and accelerator hardware.

Document the build for future users

A useful project is more than a binary file and a photograph of a populated PCB. Publish the schematic, board files, pinout references, ROM address assumptions and programming procedure. Include warnings about power, connector orientation and incompatible revisions. A future maintainer should be able to reproduce the board without guessing which signals were measured and which were assumed.

The ROM source should include comments explaining every hardware register access and every deliberate delay. Linker symbols should make the reset vector, test entry points and output routines easy to locate. Add a version string to the image and print it at startup. When a test changes, increment the version even if the circuit board remains the same.

A fault-report template improves collaboration. Record the X68000 model, power-supply arrangement, expansion cards installed, ROM revision, observed screen output, serial log, logic-analyser notes and whether the normal IPL still works after removing the card. Photos of the connector and board orientation are often as valuable as the error code.

For enthusiasts in Australia, document sourcing alternatives as well. State whether a part is available from an Australian electronics supplier, requires importation, or can be substituted with a modern equivalent. Mention the programming hardware used and allow for the fact that local stock, postage times and voltage accessories differ from Japanese or European builds. This practical information helps preserve the platform beyond the original author’s workbench.

A bootable diagnostic ROM is most valuable when it remains understandable and repairable. Publish stable releases alongside experimental builds, retain old binaries, and mark any image that can write to storage or alter configuration registers. With careful electrical validation and a modest, transparent test program, the expansion slot becomes a dependable entry point for restoring and maintaining the X68000.

Build the first revision around a minimal boot message, a safe RAM test and a clear version identifier. Share the schematic, source and test results through X68K.NET so other owners can reproduce the design, compare hardware behaviour and extend the diagnostic library without repeating the same discovery work.