Around 6 months ago, we looked at three solutions for replacing SCSI hard drives with something a little less…. spinny. You can read that article here, covering the RaSCSI, the BlueSCSI and the SCS2SD. Spoiler: All three were good, but for different reasons and at the time of writing I still use all three in different machines.
A new contender has entered the arena, however. The ZuluSCSI is from Rabbit Hole Computing, creators / maintainers of the SCSI2SD device range, and it was created as a result of shortages of the Cypress microprocessor that the SCSI2SD uses. It’s closely related to the BlueSCSI in that it uses the same STM microprocessor (BlueSCSI itself is derived from an older project ArdSCSIno-stm32) and then Rabbit Hole then redesigned the hardware to align it to the SCSI2SD form factor, and merged their refined SCSI2SD code in.
When we first reviewed the BlueSCSI, we found some compatibility issues on the Amiga and it outright refused to work on some controllers. Since then it’s been installed in a GVP HD8+, but with continued use it showed another problem; an inability to work alongside other SCSI devices. Further research showed that this was due to a lack of transceivers, where the STM32 was unable to properly drive the SCSI bus when other devices were also connected. This has been fixed in some BlueSCSI forks but the good news here is that one of the improvements that the ZuluSCSI has is transceivers are used for better compatibility. It also speaks proper SCSI-2 (as opposed to SCSI-1 of the BlueSCSI) for performance benefits. In all other respects though, it works in exactly the same way.
Looking at the hardware, the ZuluSCSI arrives fully built, there’s no option for a kit to build. You get a 50 pin SCSI connector on one side, and a full size SD card slot on the other. There’s a set of DIP switches for termination, diagnostics and a specific mode to work with some classic Macintosh machines but really it’s just a case of connecting it to your SCSI bus. You don’t need to provide external power in most cases, with the STM being lightweight enough to be powered by the SCSI cable itself. Host machines provide “termination power”, 5 volts designed to power active terminators but this is enough to operate the ZuluSCSI in normal circumstances. If you need external power, perhaps using a non-standard controller, there are pins to solder a floppy-style Berg connector on or you can buy with this pre-soldered from some retailers.
You can also optionally specify a 25-pin connector, which would be useful if you intent to use this externally, and the last pair of holes you can solder to is an LED header. Although there’s an activity LED mounted to the board itself, some machines may not have an external indicator for the SCSI bus so you can wire an LED in here. For example, the A3000 came with SCSI from the factory so the case LED is used, but the A4000 will be using an expansion card so you’d want to wire the case LED into these headers.
To operate it, Rabbit Hole have gone with the BlueSCSI method rather than their rather complex app. There’s no longer a need to write settings to the flash memory on the card; instead the filenames of the images are used to specify just a couple of options. Placing an 8GB file called “HD1.img” on the SD card will tell ZuluSCSI to present an 8GB drive on SCSI ID 1. You can also optionally specify a sector size – this defaults to 512, but larger drives may work better with 1024, 4096 or 8192 which are all supported sizes. This is also put in the filename, such as “HD1_4096.img”. To help you organise your files, you can write extra text after this second number, so “HD1_4096_Workbench3.2Boot.img” is valid. Note that this sector size should match what you set in HDToolbox, and sometimes this is automatically set to 4096 if you’re working with a large drive so do check before committing data that everything matches!
You can then go to the next step, which is to have multiple files on the SD card. For example
- HD1_img
- HD2_4096.img
- CD4.iso
would provide two hard drives (one on ID 1, one on ID2 with a 4K sector size) and a CD drive on ID4. Wait, what? Yes – like the RaSCSI we looked at last time, the ZuluSCSI can mount an ISO image of a CD as if it were a real drive. It’s slightly less useful as there’s no interface to insert/eject images, but may be handy in situations where you need to install from CD on a machine with no physical drive.
Much like BlueSCSI and RaSCSI, you can also fill a large card with images that aren’t always in use. Either moving them to a folder other than root (such as “storage/”, or changing the filename so it doesn’t start with HD or CD, will “hide” that image so you could end up with a repository of images you’re able to deploy on different machines. Again, this image management does have to be done before you insert the card and power the host machine up.
Performance-wise, this is quite speedy. On a stock A3000/030, where BlueSCSI was showing around 1MB/sec, the ZuluSCSI will more than quadruple that at 4.4MB/sec. That’s also faster than the 1.3MB/sec SCSI2SD v5.2 we tested, although on paper it’s still going to fall short of the 6-10MB/sec that SCSI2SD v6 should offer. However, there do appear to be bottlenecks; write speed is less than 300KB/sec and can give quite a feeling of grinding to a halt. The good news is that in day to day use, the read speed is far more important. The tests were also recreated on an A4000/060 using the Cyberstorm SCSI adaptor with similar speeds (including the rather relaxed write speed).
If you’re wondering about compatibility, don’t. Rabbit Hole have signed up AmigaKit in the UK to distribute this device, meaning they’re happy that it offers compatibility beyond the Apple ecosystem that other devices often focus on. We tested this in a GVP HD8+, an A3000 and an A4000 using a CyberSCSI controller and it was flawless on all. It starts up immediately, with no waiting for an OS to boot like on RaSCSI. There were a few problems experienced on larger partitions – anything over 4GB was being corrupted – but this was identified as an issue on the launch firmware which has since been corrected. Flashing the new firmware is as easy as putting it on the SD card and powering up – it’s read, installed, and then boots as normal.
Overall, this really hits a spot between price, performance and features. Especially as SCSI2SD may become harder to get as the chip shortage carries on, this has better performance (than v5) at a lower cost (£63 at time of writing), and all the flexibility of BlueSCSI/RaSCSI in terms of image files. Perhaps the only concern at the time of writing is that it feels a little bit beta, but as the firmware matures this will improve. It would perhaps be prudent not to have the only copy of any important data on an SD card in this device, but for bulk-copying of WHDLoad files etc it should be pretty reliable.
Last time we looked at solid-state SCSI, the SCSI2SD was really my go-to device for internal use (the RaSCSI still wins when installed in an external, powered enclosure) but I really didn’t get on with the app needed to set the parameters, and it then felt like you were very much locked in to that setup. I love the flexibility here, the file based images that can be copied to and from, all different size drives deployed in seconds.
Verdict: A very worthy contender, and my new go-to device offering (mostly) great performance at an amazing price. It combines all the things I loved from the BlueSCSI (instant startup and flexible image handling) with greater compatibility and performance. Buy direct from RabbitHole or one of their suppliers
Test setup: Amiga 3000/030, built-in SCSI, OS3.2, Sandisk SD card; Amiga 4000, Cyberstorm/060 with SCSI kit, OS3.2, Kingston SD card.
Update: Nov 2022. Rabbithole have reached out in the comments with some concerns over the slow write speed I experienced using this device, which does fall short of their own testing. If we can work out why this is happening when tested with SysSpeed2.6 I’ll update again – for now, be assured that in normal use you should get better write speeds.
Does this offer better R/W performance compared to an IDE to CF adapter?
Around the same read performance, although the two are rarely found in the same machine. Typically a CF to IDE in an A600 or A1200 will be 1.4MB/sec – but they generally won’t have a SCSI controller.
Write speed is pretty low though, compared to the CF card.
300kb write speed is unacceptable, read speed also has room for improvement.
I’ll stick with my physical drives for now, hopefully a better solution appears in the future.
300kB/second for write speed isn’t a device limitation. ZuluSCSI V1.1 is capable of well over two megabytes/sec for write, so the bottleneck is something that’s possibly specific to the controller being used when the write test was done.
Someone, presumably the admin, deleted my previous comment regarding the write performance speed of ZuluSCSI, which is approximately two megabytes/second, not 300KB/sec. The bottleneck in this case isn’t the hardware.
It wasn’t deleted – unfortunately we get a lot of spam, and it simply hadn’t been approved as everything needs approving manually.
It would be good to work out why I experienced such slow speeds, I’ve now tried it in two different Amigas using two different SCSI controllers and a range of SD cards and always find it has a significant performance hit compared to the published speeds. In fact only this week I repeated the test and got similar results. If you do have the time, and I can obtain any logging which would help, would you help speed things up? In the mean time I’m happy to update the article with some comments around performance.
The RP2040 version ZuluSCSI, with Firmware 1.2.0 does 5.57MB/s Read and 3.43 MB/s write in my Amiga 1200 with 040 accelerator and DMA capable SCSI controller,
I wrote an article about it here: https://github.com/ZuluSCSI/ZuluSCSI-firmware/discussions/133
I also wrote a tips & tricks article: https://github.com/ZuluSCSI/ZuluSCSI-firmware/discussions/134