Announcing ZuluIDE - an ATAPI CD-ROM and Removable (read-write) media emulator

[aperezbios]

Rabbit Hole Computing, my company, has been working on such a thing quietly for the last year and a half. While it isn't 100% ready for prime time, it is available for those who wish to help improve the product. ZuluIDE is powered by an RP2040 microcontroller, in concert with a small Lattice iCE5 FPGA. ZuluIDE can currently emulate both ATAPI CD-ROMs (of arbitrary size, vastly larger than an original CD-ROM would allow for) as well as ATAPI removable Read-Write devices, such as Zip drive emulation, or generic ATAPI removable media, again, of arbitrary volume size. The maximum volume size is limited only by the machine you use it with. It's important to note that at the present time, ZuluIDE does not emulate rigid IDE hard drives.

For those of you familiar with ZuluSCSI, ZuluIDE Compact, the first entry in the ZuluIDE family, was designed to function in a similar manner, albeit with the ATA-imposed limitation of one device at a time. Future versions of ZuluIDE may support the ability to emulate both primary and secondary IDE devices at the same time, but that is currently NOT the case, for our first-generation hardware.

https://github.com/rabbitholecomputing/ZuluIDE-firmware and you can purchase one today at https://store.rabbitholecomputing.com/ZuluIDE.

The ZuluIDE firmware that runs on the RP2040 is open source, and anyone can build it from source, if they so desire. The FPGA which interfaces to the Parallel ATA bus and the RP2040 is closed source, and will likely remain this way indefinitely, in an effort to prevent clones. Rabbit Hole Computing has made a significant financial investment in this product, and we must now begin the process of recovering our initial cash investment. In the coming year, we expect to produce ZuluIDE in larger quantities, which will help us bring the manufacturing costs down, which I believe will in turn lead to a lower price point for ZuluIDE.

Currently, ZuluIDE supports PIO modes 0-3, as well as Ultra DMA 0. Real-world read speeds are around 7MB/second, which we expect to be able to improve significantly, via future firmware updates.

ZuluIDE has also been tested to work with FireWire to Parallel ATA, as well as inexpensive Serial ATA to Parallel ATA bridge products.

 

[Timo W.]

The FPGA which interfaces to the Parallel ATA bus and the RP2040 is closed source, and will likely remain this way indefinitely, in an effort to prevent clones.

I'm waiting for such a device since ages to replace the ancient one I own, but this is a no-go for me. I'm glad the world is full of smart people who do stuff like this for free. So good luck with "prevent clones". There is probably a "BlueIDE" around the corner already.

 

[aperezbios]

I'm waiting for such a device since ages to replace the ancient one I own, but this is a no-go for me. I'm glad the world is full of smart people who do stuff like this for free. So good luck with "prevent clones". There is probably a "BlueIDE" around the corner already.

I don't really understand this mentality at all, since it would appear that you've been deceived, and are not aware that the BlueSCSI V2 firmware is a straight rebranded derivative/fork of ZuluSCSI RP2040, then. It was publicly revealed a mere 70 days after ZuluSCSI RP2040 was made available for sale. Any user of BlueSCSI V2 has directly benefitted from the morally-bankrupt deception of the people who present BlueSCSI V2 as their own creation, since Rabbit Hole Computing financed the efforts to develop an RP2040-based SCSI emulator.

 

[EverStaR]

I am interested in this discussion. Recently I picked up an IDE to SATA solution $12, however, I don't have it working yet, likely a Master Slwve issue I just need to spend some time on. Also, if a system has a PCI slot, one could just get a SATA card. On my Amiga the IDE to SD and CF solutions work well enough. On the classic Mac PiSCSI works well.

CD ROM emulation could be nice, it's like the GoTek for CD-ROM, handy, how would I be getting my ISO and HD Images to the Micro SD card, FTP through the onboard Pi?

 

[aperezbios]

I am interested in this discussion. Recently I picked up an IDE to SATA solution $12, however, I don't have it working yet, likely a Master Slwve issue I just need to spend some time on. Also, if a system has a PCI slot, one could just get a SATA card.

Right, and ZuluIDE is by no means a replacement for a SATA controller. Commodity IDE to SATA adapters are cheap and plentiful, but they only allow for non-ATAPI (rigid disk) emulation.

CD ROM emulation could be nice, it's like the GoTek for CD-ROM, handy, how would I be getting my ISO and HD Images to the Micro SD card, FTP through the onboard Pi?

By simply copying ISOs and/or bin/cue files to your SD card.

 

[MattisLind]

Rabbit Hole Computing, my company, has been working on such a thing quietly for the last year and a half. While it isn't 100% ready for prime time, it is available for those who wish to help improve the product. ZuluIDE is powered by an RP2040 microcontroller, in concert with a small Lattice iCE5 FPGA. ZuluIDE can currently emulate both ATAPI CD-ROMs (of arbitrary size, vastly larger than an original CD-ROM would allow for) as well as ATAPI removable Read-Write devices, such as Zip drive emulation, or generic ATAPI removable media, again, of arbitrary volume size. The maximum volume size is limited only by the machine you use it with. It's important to note that at the present time, ZuluIDE does not emulate rigid IDE hard drives.

For those of you familiar with ZuluSCSI, ZuluIDE Compact, the first entry in the ZuluIDE family, was designed to function in a similar manner, albeit with the ATA-imposed limitation of one device at a time. Future versions of ZuluIDE may support the ability to emulate both primary and secondary IDE devices at the same time, but that is currently NOT the case, for our first-generation hardware.

https://github.com/rabbitholecomputing/ZuluIDE-firmware and you can purchase one today at https://store.rabbitholecomputing.com/ZuluIDE.

The ZuluIDE firmware that runs on the RP2040 is open source, and anyone can build it from source, if they so desire. The FPGA which interfaces to the Parallel ATA bus and the RP2040 is closed source, and will likely remain this way indefinitely, in an effort to prevent clones. Rabbit Hole Computing has made a significant financial investment in this product, and we must now begin the process of recovering our initial cash investment. In the coming year, we expect to produce ZuluIDE in larger quantities, which will help us bring the manufacturing costs down, which I believe will in turn lead to a lower price point for ZuluIDE.

Currently, ZuluIDE supports PIO modes 0-3, as well as Ultra DMA 0. Real-world read speeds are around 7MB/second, which we expect to be able to improve significantly, via future firmware updates.

ZuluIDE has also been tested to work with FireWire to Parallel ATA, as well as inexpensive Serial ATA to Parallel ATA bridge products.

Good work!

Personally I would be interested in an IDE hard disk emulator to replace the aging drive in my HP 16500 logic analyzer. It supports a very limited set of hard drives for some reason and if it would be possible to attach an existing harddrive to ZuluIDE and mirror it and its hard drive vendor specific data it would be really good!

 

[EverStaR]

Right, and ZuluIDE is by no means a replacement for a SATA controller. Commodity IDE to SATA adapters are cheap and plentiful, but they only allow for non-ATAPI (rigid disk) emulation.

By simply copying ISOs and/or bin/cue files to your SD card.

But this is an internal card, so I would have to have access inside the PC all the time to get the SD Card Out and Put it back in? I hope you all consider an easier way if that is the case. Thats what i like about my PiSCSI, you dont have to have access to the card.

 

[3lectr1c]

It probably wouldn’t be difficult to design a bracket to go in a 5.25” bay, gotek style. A different design of the board made around that idea would be ideal, but I think you can get SD Card extenders that you also use to do it.

 

[EverStaR]

I did visit the site, there are 3.25 brackets in black an white.

 

[GiGaBiTe]

I don't really understand this mentality at all, since it would appear that you've been deceived, and are not aware that the BlueSCSI V2 firmware is a straight rebranded derivative/fork of ZuluSCSI RP2040, then. It was publicly revealed a mere 70 days after ZuluSCSI RP2040 was made available for sale. Any user of BlueSCSI V2 has directly benefitted from the morally-bankrupt deception of the people who present BlueSCSI V2 as their own creation, since Rabbit Hole Computing financed the efforts to develop an RP2040-based SCSI emulator.

Ok, so you licensed ZuluSCSI under GPL, and then call someone who makes a derivative of said work with attribution to you morally bankrupt? Would they also be morally bankrupt if they cloned the code as-is and kept calling themself ZuluSCSI? Whenever someone clones a project and does significant work to it of their own, it effectively becomes theirs. Even if they don't and backport features from elsewhere, it's still their project that they're maintaining.

You don't get to have it both ways. If you want to open source it, open source it. But don't open source it, pretend like it's closed source and then fling insults at anyone that uses your open sourced code.

Since you half-assed it with ZuluIDE, someone, somewhere is still eventually going to get a clone out. If you used Chinese companies to make your product, you already lost the game. If you wanted to hold all of the cards and have nobody make derivatives or clones of your product, you should just close source everything and encrypt/obfuscate all of the chips to delay copying attempts for as long as possible.

I won't be buying one either, $120 is ridiculous for something that can be done in software for basically free.

 

[aperezbios]

Ok, so you licensed ZuluSCSI under GPL, and then call someone who makes a derivative of said work with attribution to you morally bankrupt?

It's just not that simple. ZuluSCSI was licensed under the GPL because it makes use of the now-decade-old SCSI2SD command handling library. That code is licensed under GPLv3, and if you know anything about how the mechanics of the standard GPL license works, all derivative works must also be licensed under the GPL, which I'm totally okay with. There's no choice here, though. Could we have done a clean-room reimplementation of all of that code? Yes, but it would frankly not have made financial sense to do so. There's nothing wrong with the core SCSI2SD V6 code (which BlueSCSI V2 now also uses, as a result of being a hard fork from ZuluSCSI) so why replace it?

The part that makes it morally bankrupt is when you fork a project where 95%+ of the code wasn't written by anyone having anything to do with your project, and present it to the world as if it was an original work. That's what happened in this case. Numerous efforts were made in the beginning to obfuscate the source of the fork. If you do that in a professional or academic context, it's called plagiarism. If you do it with appropriate references, then it isn't. In short, my take is that there's a respectful way to fork a project (being open, transparent, and respectful about its origins), and a disrespectful way to do so. There's plenty of evidence to support the argument that the latter approach was intentionally chosen in this case, and it doesn't really matter to me whether you or anyone else believes it or not.

Would they also be morally bankrupt if they cloned the code as-is and kept calling themself ZuluSCSI?

Well, that's a neither-here-nor-there question, as ZuluSCSI is a registered trademark.

Whenever someone clones a project and does significant work to it of their own, it effectively becomes theirs.

I don't disagree with you, however they didn't do "significant work" in this case. Don't take my word for it. Look at who actually wrote that specific code. The copyright headers on all of the RP2040-specific parts of ZuluSCSI code are there for everyone to see, but it does require you to remove your head from the sand, if you already believe that BlueSCSI V2 is better, faster, stronger, etc. Were there changes to what end-users see in the logging? Yes, absolutely. The internals of the actual code that makes it work were written by, and tested extensively by, Rabbit Hole Computing. You're entitled to your own opinions, but not your own facts.

Rabbit Hole Computing is the reason BlueSCSI V2 exists in the form that it does. The BlueSCSI V2 PCB design was reverse-engineered from the ZuluSCSI RP2040 board design, which is why BlueSCSI V2 was announced only 70 days after we began sales.

Even if they don't and backport features from elsewhere, it's still their project that they're maintaining.

That's the thing, they _did not_ do significant work on their own, if you actually go and look at the search-and-replace that was performed on the code base. Have they done substantive work in the year+ since the fork occurred? They certainly have, and they absolutely deserve credit for those improvements.

You don't get to have it both ways. If you want to open source it, open source it. But don't open source it, pretend like it's closed source and then fling insults at anyone that uses your open sourced code.

I'm not trying to, nor do I need to have it both ways. ZuluSCSI firmware is open source because it has to be, and I believe in open source software. I've used OSS for 25+ years. Nobody is "pretending" that anything is closed-source. That's a fantastic notion not supported by any actual evidence.

Since you half-assed it with ZuluIDE, someone, somewhere is still eventually going to get a clone out.

Yes, there is always a possibility, nobody said it was impossible to clone it. I'd be quite interested to know why you think ZuluIDE is "half-assed", since you've not bothered to explain why.

If you used Chinese companies to make your product, you already lost the game. If you wanted to hold all of the cards and have nobody make derivatives or clones of your product, you should just close source everything and encrypt/obfuscate all of the chips to delay copying attempts for as long as possible.

We actually have a production run of ZuluSCSI boards being assembled here in the US as I write this, and yes, we do have a trusted partner in China, which I've had relationships with for seven+ years, since 2017, and zero problems with.

It's easy to be a keyboard warrior when you don't have to take any real-world considerations into account.

I won't be buying one either, $120 is ridiculous for something that can be done in software for basically free.

Only if you don't place a value on time or expertise. Nobody is forcing anyone to buy anything, so please leave the hyperbole at the door.

As I stated in the original post, I expect to be able to bring the price down over time, but in order to do so, we need to be able to order in volume.

 

[Zippy Zapp]

Thanks for sharing and I am glad the ZuluIDE is on the horizon. I could probably use it now as is but my main use case is Fixed Disk HD emulation. That said I am open to supporting and will take the rest to email.

Thanks and please keep us updated on this thread if you can on major milestones.

 

[Obtainium Retro]

Ok, so you licensed ZuluSCSI under GPL, and then call someone who makes a derivative of said work with attribution to you morally bankrupt? Would they also be morally bankrupt if they cloned the code as-is and kept calling themself ZuluSCSI? Whenever someone clones a project and does significant work to it of their own, it effectively becomes theirs. Even if they don't and backport features from elsewhere, it's still their project that they're maintaining.

Looking in, I can see this from a few different angles. You're taking the view that it's not unreasonable with open licensed projects that are freely forkable to fork and carry on. That's normally very reasonable. I think once a project isn't just a software project, but is a hardware project or a hardware/software hybrid project, things get a little bit more murky. That said, the right to fork and go on still exists.

To me as a hardware developer, there's a huge difference between projects with software only and projects that have a custom hardware element. When developing open software, the thing being either donated or paid for is developer's time. With a hardware-based project, that completely changes. Hardware involved physical prototypes that cost money to develop, acquire parts for, assemble, test, quality control, and that's before you even come to the $$,$$$'s investment in funding a manufacturing run. In these cases, companies that do this and also open source the work take on a huge risk that someone will simply fork their design and make it without having incurred any of those expenses. That cost is a different beast to the donation of time of a software developer.

So in this case, the ZuluSCSI developed entirely new hardware, and vastly and significantly new software and they did it all on the clock, knowing there was a large risk that this could happen. I imagine Alex Perez hoped for more from the BlueSCSI team than that they would simply take the entire release and publish it as is instead of modifying it and developing it to be somehow differentiated from what he's done. Instead, they simply forked it, and have presented to the world as if they made that investment. They didn't. That is the shady thing I see here. I can see how Alex Perez might feel a lot more strongly about it, since it's his cash money investment.

I think the big problem here is that when you didn't have any development costs and you don't contribute anything back to the parent project, it's really easy to undercut them on price. You didn't pay for anything. The source project can't do that because they have to cover that investment. Sure, they knew the risk, but still the forking team definitely has an economic advantage. So the BlueSCSI RP2040 SCSI devices can undercut the developer who contributed significant new work, stripping him of not only the possibility of economic recovery, but also by abandoning his quality controls.

As a 40 year PCB layout engineer I took a look at the boards. The ZuluSCSI boards are well considered, designed conservatively for EMI and for reliability - something you want with your data storage devices. The BlueSCSI designs do not have this as a consideration. The stackups, the layout, everything seems best effort by self-taught hobbyists who really should know more before designing a data storage board. I don't want to come off as a ZuluSCSI fanboi. I just want to make it clear that ZuluSCSI are manufactured in a process that clearly includes a lot of testing and quality controls that a bunch of makers ordering from JLCPCB simply don't have access to.

So I read your complaint about Zulu**** products costing more than their Blue*** counterparts as a sideways compliment that ZuluSCSI is going to the extra expense.

Since you half-assed it with ZuluIDE, someone, somewhere is still eventually going to get a clone out.

I can't speak for ZuluIDE. I haven't had an opportunity to examine the schematic or layout yet. I read it's going to be an RP2040-based design that leans heavily on well established principles going back to ZuluSCSI, SCSI2SD, and back generations before to IDE cards I was working on in the early 90s. Buffering and latching data isn't exactly complicated. That's not where the magic lies.

But no matter. I understand the ZuluIDE is a just announced, still in the hot lava stage of rapid development new thing and that the offer was for early dev units. No doubt these will contain imperfections in hardware, omissions in software, missing or partial features and undocumented bugs. That's how dev works. I imagine those dev boards would have been free, but now they have to be charged for because the chances of recovering the development costs is vastly reduced when you can be sure BlueIDE will be out within a couple of months. Which, fair.... But also.... damn, don't hurt the projects you're forking from even if you really dislike their approach.

 

[Androda]

Hello, as the individual that designed BlueSCSI V2's hardware I would like to make one thing clear. I do not now possess, nor have I ever possessed, a ZuluSCSI RP2040 board. The BlueSCSI V2 PCB design was based on the software implementation and usage of similar chips. But I did not reverse engineer it from their RP2040 hardware.

 

[mbbrutman]

Without getting into the specifics, I can understand the frustration, and it happens quite often.

Open source is great when everybody plays by the same rules and correctly credits who did the work. We have too many cases (hardware and software) where that does not happen, or a cheap knock-off creates support problems for the originator of the project.

 

[aperezbios]

Hello, as the individual that designed BlueSCSI V2's hardware I would like to make one thing clear. I do not now possess, nor have I ever possessed, a ZuluSCSI RP2040 board. The BlueSCSI V2 PCB design was based on the software implementation and usage of similar chips. But I did not reverse engineer it from their RP2040 hardware.

That may be true, however you don't need to physically possess a ZuluSCSI board in order to reverse engineer it, particularly when the pinout of the RP2040 and the pinout of the Pi Pico are both known quantities. We're talking about a two-layer board here, and there are only so many signals involved. Your first attempt at re-implementing ZuluSCSI RP2040 also resulted in a layout/design error we had made in our original RP2040 design also making an appearance in the BlueSCSI V2 desktop board, which, well... doesn't look good for you. In my view, it further supports the argument that BlueSCSI V2's hardware design was derived, and reverse engineered from, ZuluSCSI RP2040.

At the end of the day, however, whether or not the BlueSCSI V2 hardware design was or wasn't reverse engineered is not hugely relevant. The fact that you, in particular, have also cloned other hardware we've designed and productized, which you then productized yourself, further goes to demonstrate that you appear to be doing this repeatedly, for what appears to be petty and vindictive reasons.

 

[GiGaBiTe]

Yes, there is always a possibility, nobody said it was impossible to clone it. I'd be quite interested to know why you think ZuluIDE is "half-assed", since you've not bothered to explain why.

I went into detail about the half-assing. You clearly have a problem with other people using your open sourced code, yet you open source the majority of your code again, except for one seemingly critical part under the delusion it will prevent cloners from cloning your board. You want to have it both ways, you want to open source, but you also don't want people to release clone products. Your trashing of Androda shows it.

As I said before, someone, somewhere will clone the FPGA and release a clone of your product at some point, all you did is delay it.

We actually have a production run of ZuluSCSI boards being assembled here in the US as I write this, and yes, we do have a trusted partner in China, which I've had relationships with for seven+ years, since 2017, and zero problems with.

It's easy to be a keyboard warrior when you don't have to take any real-world considerations into account.

I've done extensive research of supply chains coming out of China. There are plenty of companies that said the same thing as you "I have a trusted guy in China that will do me good". All is fine for awhile, and then they vanish without a trace with all of their IP and trade secrets, only to show up later as a new company making said widget and running the original company out of business. IP and trade secret theft is rife in Asia. The slimy Chinese tech companies will lead someone along until they can stand up their own manufacturing using the stolen tech and then cut the original party out.

If multi-billion dollar corporations can't stop IP theft in China, you aren't going to either.

As a 40 year PCB layout engineer I took a look at the boards. The ZuluSCSI boards are well considered, designed conservatively for EMI and for reliability - something you want with your data storage devices. The BlueSCSI designs do not have this as a consideration. The stackups, the layout, everything seems best effort by self-taught hobbyists who really should know more before designing a data storage board. I don't want to come off as a ZuluSCSI fanboi. I just want to make it clear that ZuluSCSI are manufactured in a process that clearly includes a lot of testing and quality controls that a bunch of makers ordering from JLCPCB simply don't have access to.

Who cares if these clone boards violate EMI standards and are less reliable? The vast majority of computers that these devices go into are RF and EMI blunderbusses. Lots of them are on the knife edge of working or not because of poor design from the OEM company, the same with upgrade boards, and people paid thousands of dollars for those at the time. If you wanted to pass some sort of EMI test, you're going to have to redesign the entire machine along with the SCSI board. You'll also have to toss out the CRT along with it, because that's just a giant high power electromagnet. CRTs put out so much interference that you can mirror a display from hundreds of yards away with basically off the shelf equipment. Look up Van Eck Phreaking.

So I read your complaint about Zulu**** products costing more than their Blue*** counterparts as a sideways compliment that ZuluSCSI is going to the extra expense.

No, I'm not, and no I didn't. That's entirely a delusion of your own creation. More expense does not equal more better. Case and point, $400 Jucerio. I don't need a $400 machine to squeeze DRM packets of green goo into a cup. I also don't need an expensive IDE emulation board, when cheaper alternatives exist. There's this constant fear mongering that clone products are inferior and you shouldn't buy them. That's up for me, the end user to decide. I've bought plenty of cheap Chinese goods that served me fine for years, when the fearmongers said it would burn my house down, make my dog run away and cause a famine.

 

[GiGaBiTe]

Hello, as the individual that designed BlueSCSI V2's hardware I would like to make one thing clear. I do not now possess, nor have I ever possessed, a ZuluSCSI RP2040 board. The BlueSCSI V2 PCB design was based on the software implementation and usage of similar chips. But I did not reverse engineer it from their RP2040 hardware.

Thanks for the products you make, they've saved me on several occasions.

 

[MrImprovement]

Is there a plan to have a read/write functionality in the future? I can understand why you would start with read-only emulation of course.

 

[aperezbios]

Is there a plan to have a read/write functionality in the future? I can understand why you would start with read-only emulation of course.

There is already support for read/write functionality, in the form of ATAPI removable devices.