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

[Zare]

@aperezbios

If you just put bunch of code up with a generic licence file (the one that's in the repo you posted), somebody is able to derivate without denoting the original author as none was noted.In that case a forker is using the original licence, and can add themselves to the authors if they change a single byte of something. Then I come in, fork that version, and revert the byte. I cannot delete the 'forker' from the authors list, just add myself in. Now I have the exact same code of original author, with two unrelated authors listed, but everything is legit, including the fact that original author is attributed nowhere.

For instance a BSD licence states "only include the original author copyright somewhere". It's useless if someone doesn't put their name in.

Rebrand · BlueSCSI/BlueSCSI-v2@cc2c128

Contribute to BlueSCSI/BlueSCSI-v2 development by creating an account on GitHub.

github.com

The rebranding part, and they say they made a nod to ZuluSCSI somewhere latteral. Which is not what should be happening. Your files should've had proper headers and they would not be able to remove your name(s) from your work, regardless of building upon it.

https://github.com/freebsd/freebsd-src/blob/main/sbin/bsdlabel/bsdlabel.c

freebsd-src/sbin/dmesg/dmesg.c at main · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src

github.com

Author of the work, card blanche or building atop of derivative, gets the choice of attributing themselves. As you can see from links above FreeBSD does not actually attribute themselves in the files above, but in case of bsdlabel OpenBSD people did.

 

[GiGaBiTe]

I recently picked up one of these myself and have been having nothing but problems, unfortunately. I don't know if the problem is the ZuluIDE or the BIOSes on my test rigs, but every time I try to use it with any of my retro machines, it either bogs down the system so badly that it becomes effectively unusable or simply causes the computer to become unresponsive during the detection process during POST.

It sounds like the device is timing out or taking excessively long to respond to the host controller.

IDE is unfortunately really dumb, and if an IDE device doesn't respond in a way that the controller expects, it can cause the system to lock up until it does, or the device is removed from the bus.

 

[thisisamigaspeaking]

@aperezbios @Androda

I have a ZuluSCSI 1.2 in my SPARCStation 10. I am now setting up a Centris 650 and was considering going with BlueSCSI v2 WiFi. I did assume the BlueSCSI was a totally different product, especially given being based on a Pi Zero rather than just a Pi chip. The WiFi part is also an innovation. I was under the impression that BlueSCSI is better suited for Macs, while strangely doesn't list any compatibility with Sun which ZuluSCSI obviously has.

I don't like to see bad blood in the community like this. As far as GPL, to me, if you start with GPL code and build a project on it, you know other people are going to be able to use your code for their own project. That's just how it works. That's the point in fact. Especially given that it wouldn't have been practical to start the project from scratch, from what aperezbios said!

Let's build community, and build bridges rather than put up walls. Open source benefits everyone.

 

[mbalmer]

It sounds like the device is timing out or taking excessively long to respond to the host controller.

IDE is unfortunately really dumb, and if an IDE device doesn't respond in a way that the controller expects, it can cause the system to lock up until it does, or the device is removed from the bus.

I tried a couple of things on the Pentium machine, and got it to respond now. I was using a UDMA cable (the 80-conductor cable) and had the hard disk attached to the "slave" spot in the cable and the ZuluIDE attached to the "master". What's unusual to me, though, is that I specifically had cable-select turned off on both devices. Maybe there's some BIOS setting buried deep in the thing that turns on cable-select when it sees an 80-conductor cable.

Even though I got the device to work, the listed way to swap images (perform a hardware eject through the OS) doesn't seem to work -- I right-click in WinXP, click Eject, and it briefly goes empty, but then it just reloads the same image. I know that the devs were working on an external controller that allows you to select images like a Gotek, but it seems like the current firmware revision (July 2) requires this control board to allow you to pick images.

As for the 486, I've still not had any luck with it. It sees and detects a standard CD drive just fine, but for whatever reason, it flat-out refuses to acknowledge the ZuluIDE.

 

[GiGaBiTe]

I tried a couple of things on the Pentium machine, and got it to respond now. I was using a UDMA cable (the 80-conductor cable) and had the hard disk attached to the "slave" spot in the cable and the ZuluIDE attached to the "master". What's unusual to me, though, is that I specifically had cable-select turned off on both devices. Maybe there's some BIOS setting buried deep in the thing that turns on cable-select when it sees an 80-conductor cable.

UDMA IDE controllers can detect the difference between a 40 and 80 wire IDE cable, but cable select is a different type of cable. Cable select cables have a notch cut in the cable near the motherboard end to make the positions on the cable permanently master and slave. Usually the connector farthest from the motherboard is master and the middle position is slave. If you mix the direction of the cable up and plug the motherboard side into a device, it can cause strange problems. As can if you don't have both IDE devices set to cable select.

Here's an example of a cable with the notch: https://static4.depositphotos.com/1009306/280/i/950/depositphotos_2804235-stock-photo-ide-cable.jpg

As for the 486, I've still not had any luck with it. It sees and detects a standard CD drive just fine, but for whatever reason, it flat-out refuses to acknowledge the ZuluIDE.

If the ZuluIDE isn't presenting itself with fixed CHS values, it could be the reason. Early IDE controllers often have problems with LBA only devices and won't work properly with them. It's a similar reason why CF cards won't work, unless they're specifically designed to fudge CHS values to the IDE controller.

 

[mbalmer]

UDMA IDE controllers can detect the difference between a 40 and 80 wire IDE cable, but cable select is a different type of cable.

That's kind of what I mean. When I was first setting it up, the BIOS yelled at me that it had a hard drive attached, but that I wasn't using an 80-conductor cable. My guess is that when it sees an 80-conductor cable, it expects to see the drives in cable select mode. 80-conductor cables don't need a notch cut in them as they usually are modified from the start for it; that's why the two drive ends use different-colored IDC connectors. Supposedly, the "slave" connector (the middle one) has pin 28 pulled from it on these cables so that there's no soldering or cutting necessary, but it's not clear whether all 80-conductor cables are like this -- but every one I've ever had has different color IDC connectors for the motherboard end, master, and slave positions.

Nonetheless, there seems to still be an issue in swapping images because the newest firmware seems to expect a way to select images that doesn't involve ejecting them through the operating system.

 

[GiGaBiTe]

That's kind of what I mean. When I was first setting it up, the BIOS yelled at me that it had a hard drive attached, but that I wasn't using an 80-conductor cable. My guess is that when it sees an 80-conductor cable, it expects to see the drives in cable select mode. 80-conductor cables don't need a notch cut in them as they usually are modified from the start for it; that's why the two drive ends use different-colored IDC connectors. Supposedly, the "slave" connector (the middle one) has pin 28 pulled from it on these cables so that there's no soldering or cutting necessary, but it's not clear whether all 80-conductor cables are like this -- but every one I've ever had has different color IDC connectors for the motherboard end, master, and slave positions.

80 conductor IDE cables are not all designed to support cable select out of the box. While some color coded cables do have the notch cut in them to force cable select, not all do. I have literally drawers full of them, and they don't support cable select, except for the very few that have the notch cut in them.

Cable select 80 wire cables are actually much less common than normal 80 wire IDE cables. Out of my probably hundred or so of IDE cables, less than 10 of them are cable select cables.

While there may be some oddball 80 wire IDE cables that have a hidden notch cut in them under the cable crimp, that's unlikely, since it would increase the possibility of a bad crimp and the cable not working. I've crimped many a ribbon cable over the years, and the last thing you want is a missing conductor in the crimp area, it makes the crimp harder to perform correctly.

 

[aperezbios]

Even though I got the device to work, the listed way to swap images (perform a hardware eject through the OS) doesn't seem to work -- I right-click in WinXP, click Eject, and it briefly goes empty, but then it just reloads the same image. I know that the devs were working on an external controller that allows you to select images like a Gotek, but it seems like the current firmware revision (July 2) requires this control board to allow you to pick images.

This regression was recently fixed with a firmware update, so you'll want to start there. The latest as of today is at https://github.com/ZuluIDE/ZuluIDE-...oad/v2024.08.02/ZuluIDE_RP2040_2024-08-02.bin, so please download that and copy the .bin file to your ZuluIDE SD card, then power it on. It will self-update, which takes a couple of seconds.

As for the 486, I've still not had any luck with it. It sees and detects a standard CD drive just fine, but for whatever reason, it flat-out refuses to acknowledge the ZuluIDE.

Please reach out to me directly, using the e-mail address that's on your ZuluIDE. If we need to exchange your unit for another, we will do so.

 

[mbalmer]

This regression was recently fixed with a firmware update, so you'll want to start there.

I'm also happy to report that @aperezbios and team have been extremely responsive and helpful in picking through things with respect to not only the disk-swap issue, but the issue about the device not enumerating on my 486. We're not to the bottom of that last one yet, but we're working on it.

Again, I will reiterate that the device is still not quite ready for prime-time, but it is definitely taking steps toward that and it's awesome to have a helpful, responsive dev with stuff like this.

 

[0xDEADBEEF]

How exciting. I ordered one.
How about hard disk emulation? Some people will ask why. And the reason is simple, so it could replace one of these cursed Conner drives that some old Toshiba and GRiD portables use. They are hardcoded in BIOS and cannot be replaced with anything else without at least patching the BIOS.

 

[slewlimit]

How exciting. I ordered one.
How about hard disk emulation? Some people will ask why. And the reason is simple, so it could replace one of these cursed Conner drives that some old Toshiba and GRiD portables use. They are hardcoded in BIOS and cannot be replaced with anything else without at least patching the BIOS.

This is also a problem for video game consoles. The Sony PSX (Japan exclusive PlayStation 2 with tuner and DVR functionality) will refuse to boot without a special Sony branded IDE drive loaded with custom firmware at the factory. If you have one (from a PS2 Network Adapter box or a Linux Kit) you can revive a dead PSX with a firmware update disc or HDD sector image, otherwise you're sunk. An ATA emulator that can be reprogrammed to perform whatever magic handshake the PSX is expecting would be a godsend, most PSX consoles in the wild are paperweights because of this problem.

 

[aperezbios]

An ATA emulator that can be reprogrammed to perform whatever magic handshake the PSX is expecting would be a godsend, most PSX consoles in the wild are paperweights because of this problem.

Agreed, there are many niche use cases like this that will undoubtedly grow over time. As of a few firmware versions ago, it's now possible for end users to easily set the ATA and ATAPI device and vendor strings to whatever is desired, via optional ini file parameters:

[IDE]
# atapi_vendor = "vendor" # max length 8 characters
# atapi_product = "product name" # max length 16 characters
# atapi_version = "vrsn" # max length 4 characters

# ide_model = "ide model name" # max length 40 characters
# ide_serial = "ide serial" # max length 20 characters
# ide_revision = "revision" # max length 8 characters

How exciting. I ordered one.

Great, I hope you enjoy it. Feel free to ask questions about it at https://github.com/ZuluIDE/ZuluIDE-firmware/discussions/categories/q-a

How about hard disk emulation? Some people will ask why. And the reason is simple, so it could replace one of these cursed Conner drives that some old Toshiba and GRiD portables use. They are hardcoded in BIOS and cannot be replaced with anything else without at least patching the BIOS.

We're working on it, and at our table at VCF West, we demonstrated a Macintosh Quadra 630 booted from the ZuluIDE as a rigid IDE hard drive. In this limited use case, it works (reliably, but slowly), however rigid disk emulation doesn't work with most PCs *yet*. With a subsequent firmware update, we expect to be able to fix that.

 

[thisisamigaspeaking]

Anyone know if this works with McIDE-CF?

 

[hunterjwizzard]

Will you have a molded plastic bezel for this think like the Zulu SCSI?