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

[mbliss11]

I grabbed a board have been wanting something like this for a long time! Any chance cd emulation had support with audio cards via aux cables? Would be awesome if we could connect them up and get cd track audio. I didn’t see any headers on the board that looked like that but maybe future boards will?

 

[mbbrutman]

Hi everybody.

The forum rules ask everybody to remain civil. The personal attacks need to stop and we need to get back to technical discussions.

 

[aperezbios]

I grabbed a board have been wanting something like this for a long time!

Great. Thanks! Feel free to report any issues if you encounter any, at https://github.com/rabbitholecomputing/ZuluIDE-firmware/issues

If you want to discuss something, or simply ask questions, you can do so at https://github.com/rabbitholecomputing/ZuluIDE-firmware/discussions/new/choose

Any chance cd emulation had support with audio cards via aux cables? Would be awesome if we could connect them up and get cd track audio. I didn’t see any headers on the board that looked like that but maybe future boards will?

It should be possible. At the moment, there is no audio CD support, but there is on the ZuluSCSI side. We haven't evaluated the level of effort required to bring that code over, but in theory, anyone who wanted to do so could.

On ZuluIDE RP2040 Compact, there are two unpopulated footprints for pin optional pin headers which anyone can install, J306 and J307.

J307 routes signals to three of the RP2040's GPIOs, GPIO12/13/14, in addition to +3.3V and ground pins.
J306 is for i2c, and carries SDA, SCL, +3.3V, ground, and an interrupt pin (which could always be used for other purposes). J305, at the lower-right-hand corner of the board carries the same i2c signals on a four-pin JST connector, but without the interrupt pin routed to it. (Qwiic)

 

[Obtainium Retro]

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.

There's no need to acquire the hardware, as it's not relevant to the point being made. The schematics are published under an open license. As I discovered above, you apparently duplicated early mistakes. I attribute that to the nature of open source, not maliciousness. It's all part of the XxxxSCSI family tree.

[EDIT to delete comment I misattributed before coffee.]

This is a product launch thread. I'm going to confine myself to asking questions about the new product.

What ATA bus speeds and modes can this support? Is it a fixed speed system or can it auto-negotiate?

 

[3lectr1c]

What I do consider malicious is statements like "Who cares if these clone boards violate EMI standards and are less reliable?" Wow! I hope this is the quote that is associated with your work forever. Thank you for sharing your design priorities so customers can make informed decisions.

@GiGaBiTe said that, not @Androda

 

[Obtainium Retro]

@GiGaBiTe said that, not @Androda

Noted. Written before coffee. Edited to remove misattributed comment. My apologies folks.

COFFEE! STAT!

 

[Obtainium Retro]

I *am* replying promptly. I'm a new user with less than 10 posts so my responses will be delayed by the needed mod approval. Please forgive what looks like tardiness.

Also, please forgive my constant apologizing. I am an English ex-pat.

Another question I thought of regarding ZuluIDE. Does it support 8 and/or 16 bit transfers?

 

[Lutiana]

I would like echo @mbbrutman and remind everyone that on this forum we stay civll. Disagreements are fine, but keep it from getting personal. I see some comments on here that might be considered over this line and I will be watching this carefully. Anyone who degrades into personal attacks or pretty much anything I consider rude, will get at least a warning and possibly a soft ban if it's particularly bad. Also, just so everyone knows, DMs are reportable, so please don't resort to them to fling insults.

In summary, if ya'll create more work for me, I'll be very cranky and heads will roll.

 

[Mu0n]

Help me understand what problem this product solves on a technical basis, because I'm curious to learn about what the list of its current features and planned features are.

This is my gear:
-a WeeCee (system-on-module from ICOP, based on a design by theRasteri, 486 800 MHz with built-in ethernet, uSD card storage). I already max out MSDOS 6.22 storage with close to 8gb divided in 4 partitions. I use SHSUCD to mount .ISO
-a 486 DX2/66 with spinning rust 320 MB, IDE to CF adapter that used to rock 512 MB because my BIOS was limiting me to 512MB partitions, but thanks to a nic card with XTIDE bios, I bust that open with a 2GB CF card instead.
-I use and abuse mbrutman's NETDRIVE for BOTH to make storage a moot issue that sits far behind in the rearview mirror, by being able to host a library of .ISO files on my modern PC that I can access without resorting to local vintage storage anyway
-MIDI devices such as roland MT-32, SC-88ST and even mt-32pi

the only feature I'm missing is getting access to redbook audio tracks since we can't (to my knowledge) mount a .cue/.bin pair. I tried asking/searching about that on vogons forum and got complicated answers, but the short of it is: nope.
if I'm really missing the redbook audio, I could be playing the tracks in parallel on my modern PC, heh.
the Venn diagram of games that only have DOS releases, have no equivalent Windows release (where .bin/cue mounting is possible) + have redbook audio + don't have an equivalent MIDI music audio choice is not a very long list in my personal experience.

 

[NeXT]

Price: $120.00

I'll just stick to the still large stockpile of IDE/ATAPI CD drives that still exist.

 

[flynnsbit]

In for one. I currently own a Tattiebogle IDE Simulator and it is unfortunately sold out (and a lot more expensive than the ZuluIDE. Two key features that it has are the ability to swap out the disc images using a dos utility. See: https://issues.tattiebogle.net/view.php?id=14 It works perfectly for scripting the disc swap outs for DOS Game packs that are easily dumped to a real machine. The second one, of course, is CD-Audio. I hope you will consider those features soon and I look forward to testing it.

 

[Svenska]

Since the project is basically open firmware for closed hardware (and the hardware is not available anywhere else), I see this as a commercial, closed-source project. Also, from my completely uninformed outsider perspective, the whole "which SCSI emulator is better" discussions kept me away from all SCSI emulation solutions until very recently. Even now, I am not happy with existing solutions. Turning retro computing into a commercial competition for money instead of working together just hurts everyone.

I do have a few technical questions though:

• Why not emulate hard drives? Is there a technical reason or is it just manpower/time?
• Is it possible to set a specific CD-ROM speed (possibly with even spin-up delays)?
• Is it possible to set specific manufacturer/device strings?
• What about DVD support? Is that on the roadmap? Possible at all?

 

[Maikudou]

Great release! Been waiting for someone to implement such a thing for some time. I imagine it will be possible to avoid an external scsi CD-ROM in addition to an IDE device for MCA PS/2s via mca2ide (zzxio or whatever) solution -> zuluIDE.
Regarding price, anyone who tried to check how much it costs to manufacture a PCB in low quantities, especially in the States and then factor cost of engeneering effort would say the price is totally reasonable.

 

[aperezbios]

Hey folks, apologies for lack of response here. Real Life(tm) got in the way.

My family had two pets die within a week (one suddenly, one which we knew was coming), and then my day job monopolized all of my attention. Fun times.

Since the project is basically open firmware for closed hardware (and the hardware is not available anywhere else), I see this as a commercial, closed-source project.

You can choose to see it however you like, but the core firmware is open-source, and GPLv3 licensed. Only the FPGA, which is what is handling the timing-sensitive bits of interacting with the ATA bus, is what's closed source. The original prototypes for ZuluIDE did not make use of an FPGA, as we had hoped we'd be able to implement support for it solely using the RP2040's PIO blocks. After quite a bit of time and money had been spent, we concluded that it simply wasn't possible to achieve what we wanted to with just an RP2040, at which point we didn't have much choice but to go back to the proverbial drawing board, and integrate an FPGA, which further drew out the development timeline, as well as added non-trivial additional costs.

Also, from my completely uninformed outsider perspective, the whole "which SCSI emulator is better" discussions kept me away from all SCSI emulation solutions until very recently. Even now, I am not happy with existing solutions.

Is this something you'd be willing to expand upon, with an explanation? What are the current limitations of existing solutions, in your view? If you'd rather not share the publicly, for whatever reason, feel free to DM me.

Turning retro computing into a commercial competition for money instead of working together just hurts everyone.

There's a built-in (and incorrect) assumption here that retro-computing is the only market for such products. This is an understandable misunderstanding, but it's important to point out that only about one third of our sales are to retrocomputing enthusiasts. This has not always been the case, but it has been the case for the last six years.

It's also worth pointing out that the revenue from sales of SCSI2SD boards was re-invested directly in to ZulusCSI development, both for the original GD32-based (STM32 clone) ZuluSCSI V1.x, as well as the successor ZuluSCSI RP2040. Nobody is getting rich here. My business has fixed monthly expenses (office, internet connectivity, utilities, payroll, taxes, etc) in addition to the (significant) non-recurring engineering expenses that we incur when we design new hardware and software.

I do have a few technical questions though:

• Why not emulate hard drives? Is there a technical reason or is it just manpower/time?

We've been actively working on this, and I'm pleased to report that it's now working in a controlled environment. That said, it doesn't yet work universally with all systems, which is what we're in the process of resolving.

• Is it possible to set a specific CD-ROM speed (possibly with even spin-up delays)?

At the moment, the only mechanism that's available for limiting throughput is setting the Programmed I/O mode in the ini file. As for spin-up delays, not at the moment, but if you need such a thing, it would not be difficult to add support for. Right now, we're focused on improving core functionality. Just yesterday, we released firmware to address a bug fix to data transfers, which only manifested when UDMA0 (AKA ATA/16) mode was negotiated.

• Is it possible to set specific manufacturer/device strings?

Not yet, but that can easily be added. Anyone who is capable of building the firmware, which can be done within VS Code (via the PlatformIO plug in, under Linux, macOS, or Windows), or standalone at a CLI with platformio, can change the vendor and device strings to whatever they may need.

• What about DVD support? Is that on the roadmap? Possible at all?

This isn't implemented yet, but there's nothing to prevent it from happening, either. There are some ATAPI-specific commands that would need to be implemented. That said, we already support "DVD sized" "CD" images (of arbitrary size) so you can already take a non-video (data) DVD ISO of an OS, for instance, and use it to boot/install from, which is useful if you're using a machine that's old enough to not have USB, or is not capable of booting from USB, for instance. There's plenty of hardware from the late 486 and early Pentium era that fits this bill, including a non-trivial amount of industrial/embedded equipment, much of which cannot be augmented with something as smiple as an add-in PCI/ISA card.

 

[skate323k137]

If and when proper DVD support is finished, there will be an immediate demand for these from arcade operators. Systems like the namco 256 keep [IDE] optical discs spinning all the time, in unfriendly environments, but are still in use. Along these lines, in an already real world example, I would say that a very large percentage of Capcom's CPS3 boards are using a SCSI2SD or similar. The original arcade setup uses a SCSI CD ROM Drive.

 

[Svenska]

You can choose to see it however you like, but the core firmware is open-source, and GPLv3 licensed.

Sure, but it cannot run on anything except your particular hardware, and that hardware is closed.
So from a practical point of view and for most people, the firmware might as well be closed-source, and that is your stated goal.

(SCSI solutions) Is this something you'd be willing to expand upon, with an explanation? What are the current limitations of existing solutions, in your view?

All of them are complex hardware solutions and quite expensive. When I looked at the stage a few years back, I found multiple devices with different compatibility and feature support and tables describing them. There was little commonality. To me, that smells of competition in the form of "not helping each other". Having official, white-listed stores only reinforces that image. Finding flamewars in forums didn't help, either.

From a technical point of view, I guess all solutions today work more-or-less. I've got two now and one does not work for me as planned, not sure why. For my needs, they all feel overengineered still - the systems I care about are slow. They cannot use high-performance drives, they don't need high-performance drive emulators.

As a contrasting point, I see various XTIDE (and other) hardware implementations all supported by the same XTIDE Universal BIOS. The feature set is the same everywhere (except for 8-bit hardware, obviously) and compatibility fixes benefit everyone. It's great and universal.

FlashFloppy supports cheaply available Gotek hardware. It's hard to beat that hardware price point. If there were better variants, I think the project would strive to support them. It also supports virtually every format people want, so there is little point in competing. Which means it's great and universal.

There's a built-in (and incorrect) assumption here that retro-computing is the only market for such products.

Well, in that case I am right - this is intended as a commercial operation with "retro-computing" as one of the target markets. I'm just additional income.

This isn't implemented yet, but there's nothing to prevent it from happening, either. There are some ATAPI-specific commands that would need to be implemented.

I was thinking more about the region code and encryption stuff. Not sure how that works internally, though. I know that the CSS master keys are public.