Building an Arduino SCSI to SD card bridge

A compact SD card can provide a practical replacement for aging hard disks, removable media, and unreliable SCSI storage in an X68000. The attractive part is the storage capacity: a modern card can hold several disk images while consuming little power and producing no mechanical noise. The difficult part is making a small microcontroller behave like a genuine SCSI target on a bus designed around strict timing and electrical conventions.

An Arduino-based adapter is therefore more than an SD socket connected to a few digital pins. It must interpret SCSI phases, respond to commands, manage bus ownership, translate voltage levels safely, and present sectors from an SD card as a predictable block device. The hardware can remain inexpensive, but the firmware and signal integrity deserve the same care as any other retrocomputing modification.

For an X68000 project, the best result is usually a conservative bridge: support the commands the computer actually uses, keep the SCSI bus electrically correct, and make the storage image easy to replace from a modern computer. That approach is easier to debug than attempting to reproduce every feature of a commercial SCSI drive.

Define the storage target before building

Start by deciding whether the adapter will expose a raw disk image, a collection of removable images, or a filesystem directly readable by the Arduino. A raw image is usually the most compatible option. The host sees a conventional hard disk, while the firmware converts logical block addresses into offsets within a file or fixed region on the SD card.

A direct FAT32 file interface is convenient for moving images, but it adds latency and complexity. Opening a file, seeking to a sector, and writing cached data can take unpredictable amounts of time. SCSI devices are allowed some delay, yet the firmware must remain responsive to the bus and assert the expected handshake signals in the correct phase. Preallocating image files and keeping a small sector cache can reduce fragmentation and timing surprises.

The intended X68000 software also determines the image format. Some environments expect a specific sector size, geometry, or partition arrangement, while others are satisfied with standard SCSI block commands. Preserve a known-good image from an original disk whenever possible, and test copies before modifying the only surviving media. This is especially important when the bridge is being used as part of a wider hardware restoration.

A target ID must be selected so it does not conflict with another device. SCSI ID 0 is commonly associated with the host adapter, although the exact arrangement depends on the machine and expansion hardware. The bridge should offer jumpers or a small configuration menu for the ID, enable or disable termination, and select the active image.

Build the SCSI electrical interface carefully

Classic 8-bit SCSI uses a single-ended, open-collector style bus. Data lines, control lines, and phase signals are generally pulled high through termination and asserted by devices pulling them low. An Arduino pin should not simply drive these lines high and low as if they were ordinary CMOS logic. Direct push-pull contention can damage the microcontroller or another SCSI device.

A safer interface uses transistor arrays, open-drain buffers, or suitable bus transceivers. The bridge needs to sense the bus without loading it and pull individual lines low only when it is permitted to assert them. A 5 V Arduino Mega is convenient for many legacy systems, but its pin protection does not make it a SCSI transceiver. The SD card, meanwhile, is a 3.3 V device and requires proper level conversion on SPI signals and power.

Termination is part of the interface rather than an optional accessory. In a short desktop connection, the host and the physical end device should normally provide termination, while intermediate devices should leave it disabled. If the bridge is placed at the end of an external cable, its termination may be needed. Use a switch or jumper, label it clearly, and avoid powering multiple termination networks from an already weak supply.

Before connecting an expensive computer, test the adapter with current-limited power and a logic analyzer. Check that inactive lines float to the expected level, asserted lines reach a valid low level, and no output remains enabled after reset. A reset during bus activity must leave the bridge electrically passive; otherwise it can hold BSY, ACK, or data lines and prevent every device from recovering.

Power deserves equal attention. An old computer may have a worn connector, cracked solder joint, or switch with high contact resistance, so verify the supply rails under load rather than assuming the connector is healthy. The documented power switch repair is a useful reminder that small power-path faults can look like failures in a much more complicated expansion circuit.

Choose an Arduino platform that leaves room

An Arduino Uno can demonstrate SCSI signaling, but it is a constrained choice for a dependable disk bridge. It has limited RAM, few convenient pins, and little room for a FAT library, command parser, sector buffer, and diagnostic code at the same time. Interrupt latency and SPI activity can also interfere with tight bus handshakes.

An Arduino Mega 2560 offers more I/O and memory, making it a sensible starting point for a prototype. Its 5 V logic requires careful translation to the SD card and the SCSI interface, but the pin budget allows separate control of data direction, phase detection, and diagnostic indicators. A faster compatible board may improve throughput, although speed alone does not solve incorrect bus arbitration or poor timing.

The firmware should use a state machine rather than a long sequence of blocking delays. Important states include bus free, selection, command, data in, data out, status, message in, and disconnect or reset handling. The target waits for selection by its ID, identifies the initiator, accepts the command bytes, transfers data in the requested direction, returns status, and completes the message phase.

A logic analyzer trace is invaluable here. Label the SCSI signals and capture a complete INQUIRY, READ, and WRITE transaction. Compare the order of BSY, SEL, C/D, I/O, MSG, REQ, and ACK transitions with the SCSI phase rules. A bridge that works only because the host is unusually forgiving will eventually fail during formatting, booting, or error recovery.

Implement a useful command set first

A minimal block target does not need to support every SCSI command. It does need to answer the commands expected during identification, media checking, reading, writing, and error handling. INQUIRY should return stable vendor, product, and revision strings. TEST UNIT READY should report whether an image is mounted and available.

READ(6) and READ(10) are common essentials, with WRITE(6) and WRITE(10) required if the host will modify the disk. REQUEST SENSE is vital because the host uses it to understand why a previous command failed. MODE SENSE can be implemented with conservative geometry and caching information, while MODE SELECT may initially return an appropriate unsupported-command response.

The status byte must be meaningful. GOOD indicates a completed operation, while CHECK CONDITION should be followed by useful sense data such as not ready, illegal request, medium error, or write fault. Returning GOOD for a failed SD write is particularly dangerous because the operating system may consider corrupted data safely stored.

Sector arithmetic should use wide integer types. A six-byte command has a smaller address range than a ten-byte command, but the image offset can still exceed 16 bits. Check that the requested logical block and transfer length remain inside the configured image before touching the SD card. Reject invalid requests cleanly instead of allowing arithmetic overflow to wrap around into another part of the card.

Compare storage and bridge strategies

The hardware choice affects compatibility, development time, and how much control the project retains. A ready-made SCSI-to-SD product can provide excellent performance, but an Arduino design is easier to inspect and adapt for unusual vintage systems. A simple SD breakout is cheap, though it leaves the designer responsible for every electrical and software detail.

Approach	Strengths	Limitations	Best use
Arduino Mega with SD card	Inexpensive, hackable, easy to instrument	Modest speed and RAM; firmware work is substantial	Learning, restoration, custom X68000 projects
Dedicated SCSI-to-SD device	Mature timing, enclosure-ready, broad compatibility	Higher cost and less control over behavior	Reliable daily operation
Raspberry Pi or similar computer	Large storage, advanced image management, network access	Operating-system latency and greater software complexity	Multi-image libraries and remote administration
Raw flash or SRAM emulator	Very predictable access time	Limited capacity and awkward image replacement	Fixed diagnostic or boot media
Arduino with an external SCSI controller	Better bus handling and reduced pin pressure	Extra parts, driver complexity, possible availability issues	A more robust custom production design

For a first prototype, the Mega approach is attractive because every transaction can be observed and changed in firmware. Once the command set and electrical design are proven, the same protocol model can move to a faster microcontroller or a dedicated controller chip without changing the image format.

The bridge should also distinguish between a storage image and the SD card’s own filesystem. Keeping a small configuration file alongside disk images makes image selection practical, but the target should expose only the selected image to the SCSI host. Exposing the whole FAT volume as a disk can confuse older operating systems and may allow them to overwrite the management files.

Make image handling safe and recoverable

SD cards are convenient but are not inherently reliable under sudden power loss. A WRITE command can reach the card’s internal flash translation layer after the Arduino has already returned status. Use a stable supply, avoid unnecessary writes, and consider a short write-back delay only if the firmware can report errors accurately. A physical write-protect option is useful when booting a preserved image that should never change.

Image switching must happen while the SCSI bus is idle. The bridge should not replace an image in the middle of a command, and it should return NOT READY until the new image has been mounted and validated. A reset input, status LED, or serial diagnostic port can make this behavior visible without affecting normal operation.

Keep at least two copies of important images. One copy can live on the working SD card and another on a computer or archival medium. Before testing an unfamiliar utility, duplicate the image and record its checksum. This preserves the original state and makes it possible to tell whether a problem comes from the host software, the bridge, or the card.

Mechanical construction matters in a vintage computer. Provide strain relief for the SCSI cable, avoid placing the SD socket where it can be touched while powered, and mount the Arduino so it cannot contact the chassis. If the adapter is installed internally, document its ID, termination setting, power source, and image-selection method on a small label.

Test the complete path in stages

Testing should proceed from the lowest layer upward. First verify the regulator output, ground continuity, and SD voltage. Then test the SCSI transceivers with the host disconnected. Confirm that reset places every driven line in its passive state, and use a resistor or current-limited setup to catch accidental contention before attaching the X68000.

Next, connect the bridge without a mounted image and check selection and INQUIRY. The host should identify a target without hanging during boot. Add TEST UNIT READY and REQUEST SENSE before attempting reads. A missing command response often appears as a frozen machine rather than a clear error message, so serial logging or a logic analyzer saves considerable time.

Read-only testing should come before writes. Boot a duplicate image, inspect directories, launch programs, and perform repeated reads across the image. Then test writes in a disposable image, including file creation, deletion, formatting, and a reboot. Compare the resulting image with a host-side disk utility to confirm that writes reached the intended sectors.

Watch for failures that occur only after sustained activity. They can indicate SD-card latency, insufficient decoupling, a weak 5 V rail, incorrect termination, or a firmware buffer overrun. Record the SCSI ID, image name, command, LBA, and error code in diagnostics. A small amount of structured logging turns an intermittent retro-hardware fault into something measurable.

Document the finished adapter for future repairs

A useful bridge is easier to preserve when its wiring and firmware are documented as carefully as its schematic. Record the Arduino board model, pin assignments, transceiver type, pull-up values, termination arrangement, SD module wiring, and firmware version. Include a diagram showing which side supplies 3.3 V and which side connects to the SCSI bus.

Store the source code with build instructions and a sample configuration file. Avoid relying on a particular SD card’s hidden behavior or on undocumented timing that cannot be reproduced. If the project uses a custom image header, explain its fields and provide a small conversion tool so another enthusiast can prepare media without reverse engineering the firmware.

A serial console can expose selected target ID, mounted image, capacity, last command, and sense data. These details are especially helpful when the bridge is installed inside a machine and the SD card cannot be removed easily. Diagnostic output should be disabled or isolated during normal SCSI operation so that logging never delays a handshake.

The strongest design is one that can be repaired years later. Use sockets or modular connectors where practical, identify polarity on every power connector, and keep the SCSI interface physically separate from noisy switching regulators and long SPI wires. A hand-built prototype can become a dependable preservation tool when its assumptions are visible and its failure modes are understood.

Put the bridge to work

An Arduino SCSI-to-SD adapter can give an X68000 a quiet, flexible, and serviceable storage device without hiding the engineering behind a sealed product. The essential work is disciplined bus interfacing, a phase-aware firmware state machine, a focused SCSI command set, and cautious image management. Capacity is easy to obtain; predictable behavior is what makes the project successful.

Begin with a spare image and a read-only target, capture the bus transactions, and add write support only after identification and reads are stable. Then publish the schematic, firmware, image conventions, and test results alongside the hardware notes so other X68000 owners can reproduce and improve the design. Build the bridge, document each revision, and use it to keep another aging system running for many more years.