The other day, the SCSI harddisk in the IBM PS/2 P75 failed – just after I had done a fresh install of PCDOS, Windows 3.11 and OS/2 Warp.
I should have been warned – it made unhealthy noises during the OS/2 install but it went through and worked fine for the day. When I powered the box up a few days later, the disk sounded like the spindle motor was cutting-out and the seeking sound was different than before.
It showed more and more read-errors and in the end failed to boot up anything. The failing drive is a Quantum Lightning 700MB narrow, single ended SCSI-2 disk which I had swapped in replacing the super noisy IBM 0661 Type 467 400MB harddisk.
This particular IBM PS/2 requires SCSI disks with 1024 MB or less capacity, anything bigger causes issues. SCSI drives of this size in good shape are really hard to come by nowadays and if they show up on ebay, asking prices are crazy high and/or the drives are heavily used and sold „as-is“ (as was the Quantum Lightning…).
SCSI Emulation
Today we have SD cards and USB sticks that can store 40 times and more data than the IBM 0661 and there are products out there making them compatible with old-school SCSI hosts. I had this in mind for quite a while and looking back, I should have done it earlier instead of replacing one noisy harddisk with another one.
Originally coming from the Apple Mac / Amiga scene, products like SCSI2SD, BlueSCSI and RASCSI are geared towards replacing 50pin SCSI drives which is what we have in this IBM PS/2 machine too. For anything newer, wider, faster these solutions will be too slow though, however for upgrading a fast, wide drive in a SGI Octane there are other options anyway.
BlueSCSI
I have a spare BlueSCSI device around which I used via a 34->50pin adapter in the Macintosh Portable until I replaced it with one made specifically for this machine, so I decided it would probably be a good fit for the IBM and gave it a try.
Generally, the BlueSCSI is a nice, fool proof device – load it with disk images following a certain naming convention and you should be fine.
Not so in the IBM PS/2 – while it sees the drive presented as SCSI ID 0, LUN 0 with 976MB capacity, it also sees an unknown device on each of the other six LUNs. Since there were no disk images for LUNs other than 0, the IBM wouldn’t know what to do with them an error out.
Skipping the error with F1 let me boot DOS from a floppy-disk only to discover that FDISK would crash when trying to access the SCSI disk. Adding more disk images didn’t help either because this BlueSCSIs firmware doesn’t accept more than one additional LUN per ID, so still six of them showing up as unrecognized.
I guess this could be fixed with a firmware patch for the BlueSCSI, however reprogramming it requires some special tools that I don’t have, so it will wait for a use in another computer.
SCSI2SD
Since the BlueSCSI plan didn’t work, I took the SCSI2SD v5.1 from my HP 9000/712 computer. My plan was to try it out in the PS/2 and, if working, using the BlueSCSI in the HP machine. Spoiler: the HP 9000 doesn’t like the BlueSCSI either, it sees a drive but refuses to boot from it.
The SCSI2SD works well with the IBM PS/2 SCSI adapter, only caveat is that drives need to be less than 1GB in size to work which is a limitation of the PS/2s SCSI firmware. The SCSI2SD allows to define up to four targets which can be either hard-disk or CD ROM images, so I ended up in creating 4 x 967MB disk images on the SD card.
IBM treats SCSI devices from high to low ID numbers, so the CD-ROM drive shows up first after the adapter as ID 6. I had numbered the virtual hard-disks from 1 .. 4 so ID 4 is found next. Drive letters will be assigned in descending ID order, so ID 4 will be the C drive, ID 3 is D and so forth.
My plan is to install OS/2 with its bootmanager on the C drive and use it to multiboot into OS/2, DOS and other systems.
Update: That plan works to some extent, it is possible to get Windows, OS/2 and DOS multiboot working, however it requires a very specific sequence of installations, going back and forth between the OS/2 boot manager install and the OS.
It totally doesn’t work to multiboot into IBM AIX which gets confused by non Unix partitions ending with things messed up. The new plan is to use one SD card for each OS and swap out the cards to boot different OSs.
Sidenote on the SCSI2SD: it is somewhat complicated to configure since a) it requires an extra tool for setup and b) it does not work with files but with the start and end block addresses on the SD card that one needs to find out and plug into the config tool. Writing data to the SD card to exact block addresses is somewhat inconvenient as well since it involves several steps to in the end dd a raw file of certain length to a certain spot on the card.
Since I want a easy way to access the drive images individually on another system, I put together a little tool that will find the addresses of disk image files on the SD card and generate a scsi2sd-config.xml file which can be imported straight into the configuration utility.
Once I got the SCSI2SD to work, I needed to think about how to add it to the computer so that I can access the SD card from the outside. I found a MCA bracket on thingiverse that I 3d printed and with that could install it one free of the lower Microchannel slots. The SCSI2SD is powered from the SCSI bus and the internal wiring is long enough for a comfortable fit.
I decided to install the IBM 0661 drive in the drive bay lower right in the back of the computer, completing its original setup. The drive is left unconnected and thus noiseless 🙂
Speaking of noise – all that’s audible now is the PSU fan which I had replaced with a Noctua NF-A9. It’s not totally silent but has a nice, monotonous, low pitch sound – as opposed to the IBM 0661 and the Quantum Lightning. Either of them made a screaming, saw like sounds – probably due to worn out bearings along with heavy rattling head seek sounds, making the computer unpleasant to use for a longer time.
Below is a view into the back of the IBM PS/2 P75 as it stands now, pretty packed. Maybe one more Microchannel card will fit… thinking of a XGA-2 maybe 🙂
PiSCSI (was RASCSI)
RASCSI is a SCSI emulator software for the Raspberry PI which together with a hardware adapter on the GPIO pins can emulate all kinds of SCSI devices, including hard-disks, CD-ROMs but also Printers, network adapters and Video Devices.
Update: The RASCSI software has been forked into PiSCSI which is under current development. The UI got modernized, some bugs ironed out, support for 64bit Pis added.
Being a full blown RPi, the solution is pretty flexible, it allows for adding new disk images via FTP while in use, it has a web based UI to configure and store different SCSI setups and it has an active developer community around it.
The biggest drawback I see though is that the RAScsi is a complete computer system that takes quite some time to boot up itself, so in my mind it’s an excellent replacement for external devices like CD-ROM drives but not so much as primary computer drive.
With a library of ISOs on the device, mounting a new disk to install something on a target computer is just a few mouse clicks. Powering down requires to shutdown the RASCSI via the web UI first, just cutting power might lead to data corruption thus complicating its use as an internal drive.
Speed is another issue – with the SCSI protocol being emulated in software, it is not really fast, at least not on the RPi 3b+ I’m using it with where I’m getting peak write rates of 0.63 MB/s and read rates of 1.0 MB/s – this might look better with a Pi4. At some point, the narrow SCSI bus would naturally limit throughput, making it less interesting as a main hard-disk replacement for faster computers.
Same as back in the day, careful SCSI termination is absolutely needed. Most vintage machines are okay with the standard, passive, termination. Other boxes however require an active termination at the end of the SCSI bus, especially when using external cabling. Sadly, the onboard termination of the RASCSI hardware is passive, I got lots of SCSI errors with a SGI INDY. Adding an old-school, active terminator to the daisy chain port and disabling the onboard one fixed the issue and even allowed for 5MHz synchronous transfers, giving some higher r/w speed than before. 10MHz sync mode didn’t work however, the SGI would not boot and give SCSI bus errors.
CDROM emulation seems to have some teething pain as well with systems that need to switch between 512/2048 byte block sizes: When using the „regular“ CD rom device, ISO 9660 images mount perfectly on the SGI but none of the Silicon Graphics system CD images would work. Conversely, when masking the device as Generic 512 byte, the opposite was the case, ISO9660 images could not be read and the SGI CDs worked. This might be an issue of the IRIX OS though since initial system installation went just fine. The workaround is to simply define two CDROM drives with different properties 🙂
While testing the RASCSI, I found it and the BlueSCSI being incompatible to a point where neither would be accessible from the target computer. I haven’t found out which of the two devices doesn’t play nicely on the SCSI chain, however the issues with multiple ghost LUNs with the BlueSCSI point to that direction.
Finally, there are nice case designs for the PiSCSI – in case you own a 3D printer you can make yourself Mac style external enclosures: https://www.printables.com/de/model/52673-piscsi-mini-case
Note: The Pi3b gets quite hot, so maybe a small fan should be added into the case.
Conclusion
In conclusion, for 50pin SCSI hard-disk replacements I recommend the ZuluSCSI upgrade over real „Spinning Rust“ and over the BlueSCSI that the PS/2 and the HP9000 hated. The RASCSI is a super flexible system but in my mind unsuitable as a permanent internal drive. It plays out its powers as an external device like for instance as a CDROM library.
| SCSI2SD *) | BlueSCSI | PiSCSI w. Pi3b+ | ZuluSCSI | |
| Compatibility | Excellent | Poor | Good | Excellent |
| Speed | Excellent | Good | Poor | Excellent |
| Ease of use | Fair | Excellent | Good | Excellent |
| Cost | ~90 EUR | ~50 EUR | ~50 EUR (kit, excl. RPI) | ~80 EUR, 45 EUR as kit |
| Available as kit | No source found | Yes | Yes | Yes (ZuluSCSI Homebrew) |
| Personal Verdict | + Great as a permanent HDD replacement – Disk images difficult of exchange on SD card – Expensive; due to chip shortage prices go crazy | + Fine as a HDD replacement for vintage Macs, compatibility issues on others (IBM, Next, HP) + Changing disk images is easy via drag and drop to SD card + Affordable kit | – Not useful as a permanent HDD replacement – Relatively slow + Great flexibilty when used as an external SCSI device + Affordable addition to a spare PI (can get expensive when PI and cabling come on top) – Issues w. termination | + Like the SCSI2SD + much easier image handling + Available as a kit + Price is okay when buying several kits from the US store |
Note *) there is a successor named ZuluSCSI for the SCSI2SD which is based on concepts from the SCSI2SD and BlueSCSI. Currently Selling at 70 – 80 EUR this is a device I want to test out for use with my HP and Next machines.