PiSCSI: a Raspberry Pi as a SCSI bus for vintage Macs and Ataris

The problem is a bus that stopped being manufactured

PiSCSI is a virtual SCSI device emulator that runs on a Raspberry Pi through the PiSCSI hat. The description is precise about the use case, since it allows a Raspberry Pi to function as emulated SCSI devices, hard disk, CD-ROM and others, for vintage SCSI-based computers and devices. The situation it addresses is unglamorous and very real. A Macintosh from the early 1990s or an Atari expects a SCSI controller and a disk that speaks the protocol, and neither the disk nor, in many cases, the controller is still made. A modern replacement has to be small, cheap, and tolerant of the fact that the host software was written against a specific device with a specific vendor string and a specific command set. Emulating the device rather than replacing the machine is the approach here, and the project states its own goal as compliance with the SCSI specification and usability with any standards compliant SCSI controller, with a compatibility list maintained on the wiki. The point of the hat is that it puts a SCSI connector and transceiver on the Raspberry Pi's GPIO, so the Pi appears as a device on the same bus as the vintage machine, at the other end of a cable.

Userspace, multiple devices, and a live control interface

Three properties of the software are worth naming separately because they determine how it behaves in practice. The first is that the software runs in userspace, which means the emulation is a process on Linux rather than something wired into a kernel or a hypervisor, with the practical implication that it is easy to update, easy to inspect and easy to break without harming anything else on the Pi. The second is that it can emulate several SCSI devices at one time, so a vintage machine can be given a hard disk, a CD-ROM and a tape or scanner simultaneously, which matters because these machines booted from one device and expected the others to be there. The third is that there is a control interface to attach and detach drives during runtime, as well as insert and eject removable media. That last one is the feature that makes the emulator pleasant to use rather than merely functional, because you can change what the machine sees without powering it down, which is the difference between swapping a disk image by editing a config file and rebooting, and swapping it while the machine is running. The generated command documentation is browsable on the project's documentation site, so the command set is readable without reading the source.

Vintage Mac and Atari features, and the driver caveat

The project states plainly that a handful of PiSCSI features were written specifically for vintage Macintosh and Atari computers and may depend on non-free device drivers on the host machine. This is the caveat that most affects an adoption decision, and it deserves to be read as it is written rather than softened. The emulation itself is a SCSI device, but some of the convenience comes from the emulated disk advertising a particular identity, and the vintage operating systems on the other end may only install their driver for a disk with that identity. Where the driver is non-free, you may need to obtain it from the vendor or find an alternative, and a feature that works on one machine may not work on another. The repository topics reflect the audience, listing Macintosh, Raspberry Pi, SCSI, SCSI devices and vintage Macintosh computers, so the vintage Macintosh is clearly the centre of gravity and the Atari support is a second target. The fork relationship explains the structure of the audience too, since PiSCSI is a fork of RaSCSI by GIMONS and maintains compatibility with any RaSCSI hat, which means the hardware side of the project is shared with a wider community and you are not locked into one hat design.

A multi-language tree that separates device, firmware and web layers

The top level of the repository shows how much more this is than a single binary. There is a cpp/ directory, which holds the C++ implementation of the emulator itself, and the project lists C++ as its primary language. There is a go/ directory, which contains the web interface, since the localisation instructions for the web interface live in go/piscsi-web/README.md, so the control surface is a Go application. There is a proto/ directory for the protocol definitions that connect them, which is consistent with a design where a Go web service talks to a C++ device process over a defined interface rather than by sharing a process. There is hw/ for the hardware description, meson.build and meson_options.txt for the build system, plus a Dockerfile and a docker/ directory, a debian/ directory for packaging, an easyinstall.sh script, os_integration/ for hooking into the host operating system's image handling, a doc/ directory, and a docs-site/ directory that matches the published documentation site. An INSTALL.md sits at the root. The release tags follow a strict naming convention, with v26.08.01 from 2026-08-31, v25.12.01 from 2026-01-01 and v24.04.01 from 2024-04-29, and the versioning is defined in the README as year, month and a release number incremented for each subsequent release in the same calendar month, with the note that the leading zeroes appear only in the git tags while the software itself reports the unpadded form.

Gitflow with main frozen at the last stable release

The contribution model is described precisely enough that a contributor can follow it without guessing. PiSCSI uses a variant of the Gitflow workflow. The main branch should always reflect the contents of the last stable release, and the develop branch should contain the latest tested and approved updates, with pull requests used to merge changes into develop. The remaining feature branches are for developing new features. The default branch of the repository is develop, which is consistent with that scheme. The README asks contributors to use the GitHub forking and pull request workflow, to make changes in their own fork, and to always make pull requests against the develop branch. For translations, the same fork and pull request workflow applies after following the web interface localisation instructions. The variant from stock Gitflow is the frozen main branch, and it is worth understanding why it matters practically. A user who clones main gets the last stable release rather than a moving target, and a user who wants the current work knows to look at develop. It also means that a pull request is not automatically a change users will see on their next update, which keeps the stable line meaningful.

The licence is permissive, which suits a hardware project

PiSCSI is released under the BSD 3-Clause licence, and that choice is more significant here than it would be for a typical library. The project involves three parties who are not the same person, the person who writes the emulator, the person who designs and sells the hat, and the person who owns the vintage computer, and the BSD licence lets all three coexist without friction. Someone can build a hat, sell it, ship firmware with it, and let the buyer modify the software, with no requirement to publish anything and no requirement that a derived version stays under the same terms. The README also records the sponsorship that supports the development, thanking the GitHub sponsors and naming the Gold and Silver level ones individually, and it credits Lin van der Slikke for the red panda logo design. A project with this much of its running on a volunteer and hobbyist base is more likely to keep going when the licence lets people commercialise the hardware around it, and the maintenance record is consistent with that. The repository is not archived, the last push was on 2026-10-08, and the release list shows a tagged release roughly every few months, with a gap between the January 2026 and August 2026 tags that is worth noting if you plan to depend on a specific version.

Where PiSCSI is the wrong tool

The limits are real and they are not about the emulation quality. The first is that the emulated machine is still a vintage machine, so the CPU, the bus and the operating system are all as slow and as limited as they were, and the emulation does nothing to change that. A PiSCSI machine boots the software it always booted, which is the point, and also the limit. The second is the driver caveat again: some of the features depend on non-free device drivers on the host, so a feature that works for one vintage platform may be unavailable for another, and you are dependent on the vintage operating system's own driver supply. The third is that this is a hobbyist and enthusiast project with a volunteer maintainer and a sponsorship model, so a critical deployment, an industrial array replacement or a long-term support commitment is a poor fit. The fourth is the hardware requirement. You need the Pi, the hat, and a SCSI connection to the vintage machine, and the Pi is a single point of failure for whatever the machine does. The right use is a hobbyist machine that you want usable again, or a way to preserve a disk image and run it without the original hardware, and it is a good use for that.

Editorial conclusion

Adopt PiSCSI if you want to keep a vintage Macintosh or Atari usable with modern storage and without a period-correct SCSI disk, and you are comfortable with a Raspberry Pi, a hat and a SCSI bus. Skip it if you need a host that already speaks modern storage, if you want an industrial replacement for a failing SCSI array, or if you depend on the vintage drivers the project says some of its features rely on. Verify first that your controller appears on the project's compatibility list, that the drive images you plan to use are in a format the emulator supports, and that the drive you attach is the right device type for the host you are booting.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. PiSCSI/piscsi on GitHub
3. Project website
4. README
5. Releases