Hiya,
One of the features of the fantastic Previous is that the hard drive images are compatible with BlueSCSI.
That means that I can use the same image without any extra hassle with Previous or with BlueSCSI in my NeXTcube.
Do other emulators for other platforms (e.g. for Intel) offer the same functionality? Such as 86box, VirtualBox, qemu or others?
And, NeXT-unrelated, even emulators for other operating systems, such as Mac OS or Mac OS X?
Thanks for your help!
All the best,
Kokomuck
I haven't tested this but in theory a SCSI image should mount in any compatible system. I've mounted a raw SCSI image of a IRIX disk in MAME just fine.
86Box should work fine for NeXT as you can configure it with a compatible SCSI adapter. I love it for PC emulation. The range of customisation puts it way ahead of QEMU or VirtualBox.
For 68k Mac, MAME has SCSI support and I think QEMU does too. QEMU's PPC emulation uses IDE. There's another PPC Mac emu called DingusPPC that I haven't looked at yet.
Brilliant!
Thanks for the detailed reply. I will have a look how to best emulate NEXTSTEP/OPENSTEP on white hardware. I am trying to build a system with real hardware and BlueSCSI, so it might be handy if I could swap hard drive images without any hassle.
Thanks again,
Kokomuck
Quote from: kokomuck on Sep 21, 2025, 06:32 AMHiya,
One of the features of the fantastic Previous is that the hard drive images are compatible with BlueSCSI.
There's no such thing as a "BlueSCSI image" Both ZuluSCSI and BlueSCSI just use raw HDD images, like you would read from a mechanical HDD or SSD with DD or any other raw disk imaging utility.
For the record, the BlueSCSI V2 firmware is a knock-off "re-branded" ZuluSCSI. Back in early 2023, they took the ZuluSCSI firmware (which is GPLv3-licensed) and "re-branded" it, (mass search-and-replace), dropped non-RP2040 platform support, since they had no need for it, and then announced BlueSCSI V2 less than 70 days after I'd launched ZuluSCSI RP2040. This is not a coincidence.
They also did other shitty things in blatant violation of US Copyright Law, like attach copyright notices claiming copyright to dozens of source and header files they _knew_ they had not authored, and ended up learning the hard way that just because software is GPL-licensed, US copyright law still applies.
There's a reason why "Copyright <year> Rabbit Hole Computing" appears over 70 times in the current BlueSCSI V2 firmware repository. We wrote nearly all of it, including the SCSI initiator mode support, which they later added to a revision of BlueSCSI V2 hardware, and subsequently enabled in the BlueSCSI V2 firmware.
The initial BlueSCSI V2 (Pico/RP2040-based) public announcement was made on Jan 25, 2023, just a bit over two and a half years ago. Since then, we've merged in additional functionality that was developed for BlueSCSI, post-fork, as is our right to do. Multiple people have informed me that this did not go over well with the BlueSCSI maintainers, which comes across as an absurd double-standard from my perspective.
Over the course of the past ten months, my company, Rabbit Hole Computing:
* Ported ZuluSCSI to the RP2350 microcontroller (merged in more or less verbatim to the BlueSCSI V2 code base)
* Released ZuluSCSI Blaster (https://shop.rabbitholecomputing.com/products/zuluscsi-blaster) (RP2350B-based) (code that's since been merged back in to the BlueSCSI V2 code base, naturally)
* Released ZuluSCSI Wide (https://shop.rabbitholecomputing.com/products/zuluscsi-wide) (16-bit single-ended Ultra Wide SCSI) and have continued to innovate on other fronts.
A couple of years ago, the BlueSCSI V2 maintainer had the audacity to claim the following, in a still-publicly-available thread on Reddit: "I think mainly the difference is BlueSCSI is not a commercial project, we just give away everything, hardware, designs, etc. We don't pay contractors to write the software,
we write it ourselves." (emphasis mine)
Making statements like this when they know exactly where the majority of the BlueSCSI V2 source code came from is precisely the sort of grandstanding I've come to expect from the BlueSCSI maintainers.
The dig about contractors is a veiled reference to Rabbit Hole Computing, since the individual I hired to originally design the ZuluSCSI RP2040 hardware and firmware was and remains a contract developer. They don't seem to have a problem profiting off of the work of others, while at the same time shit-talking the concept of contract development work that they're directly benefiting (and profiting) from.
While it's cute that he claims that BlueSCSI is non-commercial, the reality is that he and his co-maintainer are both paid per-unit-sold royalties for every fully-assembled BlueSCSI sold by his authorized resellers. This is yet another disengenuous attempt to whitewash their shitty behavior in the eyes of their user base. Another example is when they chose to distribute
Claiming that BlueSCSI is "not commercial" because the hardware designs are open source, while at the same time collecting per-unit-sold royalties from a handful of different "makers" who re-sell the BlueSCSI V2 hardware designs that are commercially-licensed to them is ethically questionable at best, and I personally find it to just be a downright shitty thing to do. Multiple attempts were made to obfuscate the true origins of the BlueSCSI V2 code base (https://github.com/BlueSCSI/BlueSCSI-v2/issues/9), and despite claims to the contrary, the motive for doing so is highly questionable. Every time someone buys a BlueSCSI, they're effectively rewarding/enabling shitty behavior, whether they realize it or not, and putting money in to the pockets of those who claim to not be operating a commercial enterpise.
Please consider purchasing a ZuluSCSI (https://shop.rabbitholecomputing.com/collections/zuluscsi) the next time you have need of a quality SCSI emulator. We have distributors/resellers in the EU, UK, Canada and Australia. Without Rabbit Hole Computing and ZuluSCSI RP2040, there would be no BlueSCSI V2 as you currently know it. It cost me many tens of thousands of dollars to develop it, and Rabbit Hole Computing is a tiny two-person company, not some hugely-profitable enterprise. We put a lot more effort into our hardware designs (reviewed by actual Electrical Engineers), and yes, this costs real money, but it's worth it.
I had no idea about this history. Thanks for sharing it. Knowing ZuluSCSI is "the real thing", it being the original, will be the only one I recommend going forward.
Thanks for your contribution to the retro world!
Hiay,
Thanks for the clarification re. the raw HDD images - very much appreciated.
Also, I want to thank you for clarifying the BlueSCSI/ZuluSCSI relationship. I was not aware of those issues.
So far, I bought BlueSCSI and ZuluSCSI devices to serve my various needs. Practically, there is a BlueSCSI reseller here in Belgium, that's why I chose BlueSCSI. Another reason was the availability of different adapters and cases, which werew not available for ZuluSCSI.
For ZuluSCSI, there is one retailer in Germany, who sells a subset of the products offered by ZuluSCSI/Rabbit Hole Computing.
There is one retailer for ZuluSCSI in the UK, but I have to check shipping and customs as the UK left the EU.
Another retailer in the EU with the same products as in the USA would be fantastic!
Anyhow, I am completely with you in that issue, and I will not buy any further BlueSCSI devices, but will buy ZuluSCSI instead.
Thanks again for explaining the situation!
And please keep up the development of future products, I am looking forward to buying the ZuluSCSI Wide, which I read about in the other NeXT forum.
All the best,
Kokomuck
To get at your original question. Basically all of these platforms you mentioned just have raw block storage in a file format. So they all have various tools for use, but basically yes. You can image from these virtual environments to the real environment as long as the virtual environment emulates the boot process and hardware close enough (which they probably do or else the OS would not run).
So the exception would probably be if you install MacOS for Intel in one of these and try to image it to an Intel Mac, it would probably not work because of all the hacks that need to be done to make Mac OS boot on generic X86 hardware.