Is there a way to disable the onboard access LED?

Edit: Reason, I'm set up with an external LED and its redundant.

hasnopants wrote on 2025-07-17, 02:26:

Is there a way to disable the onboard access LED?

Edit: Reason, I'm set up with an external LED and its redundant.

At present, no -- the external LED header is simply in parallel with the existing onboard LED.

Okay, thanks for the quick reply.

When the ZuluIDE is installed in a PC case it's very complicate to access it to add/remove images (need move PC and unscrew).

A feature to add/remove images from the web interface will be a great thing to add.
Or if it's too complicated at least enable a FTP Access (at bare minimum).

Because everytimes i want add games, i need unscrew everything.

Optionnal: A way to also edit the config from the web interface could be great.

I don't know how feasible this would be, but if it was possible to expose the SD card's filesystem (or a partition) directly over IDE to the host as part of a "special passthrough operating mode", writing image files from the host, over IDE, might be a possible solution.

TgamesFR wrote on 2025-07-17, 10:37:

When the ZuluIDE is installed in a PC case it's very complicate to access it to add/remove images (need move PC and unscrew). […]
Show full quote

When the ZuluIDE is installed in a PC case it's very complicate to access it to add/remove images (need move PC and unscrew).

A feature to add/remove images from the web interface will be a great thing to add.
Or if it's too complicated at least enable a FTP Access (at bare minimum).

Because everytimes i want add games, i need unscrew everything.

Optionnal: A way to also edit the config from the web interface could be great.

As I mentioned above, the biggest hindrance to being able to use the Pico W as a means to write to the ZuluIDE's SD card comes down to the available I/O that's on the ZuluIDE itself -- the RP2040 on the ZuluIDE is being pushed to its limits dealing with IDE bus traffic and management of the SD card filesystem and there just aren't any more free I/O pins to handle reads/writes from an external source.

As for FTP access, you're running into the same problem: there's just not enough available I/O to handle filesystem access, and even if there were enough I/O pins, there simply isn't enough available bandwidth between the Pi Pico W and the ZuluIDE to make FTP access workable. The I2C bus only gives us 400Kbit/sec of bandwidth -- 50KBytes/sec -- and that would make for some excruciatingly slow file transfers.

That said, you're not entirely out of luck when it comes to not wanting to unscrew everything from the case. The suggestion that some others have used is to take an SD card extension cable and use that to bring the card out of the case. I've not tried it myself because I personally don't really trust them, but others have done it successfully.

HOWEVER: If you are able to plug the ZuluIDE's USB port into a second computer, you can get access to the SD card's filesystem that way as long as the ZuluIDE isn't connected to a host -- in other words, if it isn't actively functioning as an IDE storage device. Basically, if the ZuluIDE is powered off, but you then give it power via the USB port, it can boot up and expose the filesystem of the attached SD card via USB.

To do so, you'll need to add enable_usb_mass_storage = 1 to the [IDE] section of the zuluide.ini file on the SD card. The ZuluIDE will then appear as a generic USB mass storage device to the host it's attached to via USB. Just be aware that transfers over the USB port that way will be slow -- limited to about 1MB/sec, which is the maximum the onboard USB controller supports. That way, if you want to add images to the card without having to open the case, you could just run a USB cable out of it and do it that way.

The significantly faster way would be to use an SD card extension, especially for adding images to the SD card, but the option is there. However, for making INI file changes, this mode would be perfect.

darry wrote on 2025-07-17, 15:08:

I don't know how feasible this would be, but if it was possible to expose the SD card's filesystem (or a partition) directly over IDE to the host as part of a "special passthrough operating mode", writing image files from the host, over IDE, might be a possible solution.

What you're saying sounds like exposing the SD card's filesystem to the ZuluIDE's host, not another, external machine where disk images are being stored. Assuming this is what you mean, that is not possible, because the SD card's filesystem isn't going to be compatible with the host system in almost every use case -- and even if the SD card's filesystem was compatible, you wouldn't be able to expose it as such without forcing a reboot-and-rescan of the IDE bus, which only happens during the BIOS's startup sequence. The IDE bus doesn't support hot-swapping drives, which is what would be necessary to implement something like this.

Remember that the IDE standard (Integrated Device Electronics, also called ATA, meaning AT-Attachment) is a evolution of the old Winchester drive standard in the early 1980s that made it possible for drive manufacturers to move all of their dedicated controller circuitry to the drive instead of requiring a separate dedicated add-on card. While IDE evolved, it's still limited by the fact that it had to remain compatible with even the earliest of drives, which means there are a lot of legacy limitations (like no hot-swapping) that get in the way.

The reason that hot-swapping the SD card on the ZuluIDE works is that from the host system's perspective, the actual drive itself doesn't change -- only the media. Essentially, just like a floppy disk or an actual CD-ROM drive. From the host system's perspective, the ZuluIDE reports itself as one thing that doesn't change, and therefore, all of the methods and parameters the host system uses to access it remain the same, and therefore, the system could care less what the actual data stored on the drive is -- all it cares about are the specific parameters of the drive (or, more accurately, what the IDE controller that the ZuluIDE is emulating) are reported as.

If, instead, what you mean is being able to expose the SD card's filesystem to a machine while the ZuluIDE is attached over IDE to another, then the only real way to do this are the ways I've described above -- eject the SD card, write to it, and put it back; use an SD card extension to essentially do the same thing, or enable USB mass-storage mode and use a USB cable with the ZuluIDE's host turned off.

mbalmer wrote on 2025-07-17, 23:13:

What you're saying sounds like exposing the SD card's filesystem to the ZuluIDE's host, not another, external machine where disk […]
Show full quote

darry wrote on 2025-07-17, 15:08:

I don't know how feasible this would be, but if it was possible to expose the SD card's filesystem (or a partition) directly over IDE to the host as part of a "special passthrough operating mode", writing image files from the host, over IDE, might be a possible solution.

What you're saying sounds like exposing the SD card's filesystem to the ZuluIDE's host, not another, external machine where disk images are being stored. Assuming this is what you mean, that is not possible, because the SD card's filesystem isn't going to be compatible with the host system in almost every use case -- and even if the SD card's filesystem was compatible, you wouldn't be able to expose it as such without forcing a reboot-and-rescan of the IDE bus, which only happens during the BIOS's startup sequence. The IDE bus doesn't support hot-swapping drives, which is what would be necessary to implement something like this.

Remember that the IDE standard (Integrated Device Electronics, also called ATA, meaning AT-Attachment) is a evolution of the old Winchester drive standard in the early 1980s that made it possible for drive manufacturers to move all of their dedicated controller circuitry to the drive instead of requiring a separate dedicated add-on card. While IDE evolved, it's still limited by the fact that it had to remain compatible with even the earliest of drives, which means there are a lot of legacy limitations (like no hot-swapping) that get in the way.

The reason that hot-swapping the SD card on the ZuluIDE works is that from the host system's perspective, the actual drive itself doesn't change -- only the media. Essentially, just like a floppy disk or an actual CD-ROM drive. From the host system's perspective, the ZuluIDE reports itself as one thing that doesn't change, and therefore, all of the methods and parameters the host system uses to access it remain the same, and therefore, the system could care less what the actual data stored on the drive is -- all it cares about are the specific parameters of the drive (or, more accurately, what the IDE controller that the ZuluIDE is emulating) are reported as.

If, instead, what you mean is being able to expose the SD card's filesystem to a machine while the ZuluIDE is attached over IDE to another, then the only real way to do this are the ways I've described above -- eject the SD card, write to it, and put it back; use an SD card extension to essentially do the same thing, or enable USB mass-storage mode and use a USB cable with the ZuluIDE's host turned off.

I was a bit unclear, apologies. I meant exposing the SD card's file system to the host, over IDE, but not necessarily as a directly accessible usable (in15h) block device.
I was thinking of something similar to this, conceptually :

a) set a flag that enables a "special mode" on the next power cycle of the ZuluIDE and power cycle the ZuluIDE
b) Once booted, the ZuluIDE only exposes a small "virtual" IDE block device that is not directly backed by storage, but by a memory buffer (say a few MBs in size)
c) a "custom written DOS (or other OS) upload utility", is then used to copy an image, sector by sector, in chunks (each not exceeding the size of the virtual block device) until the image has been uploaded
d) On the ZuluIDE, in step with the upload utility running, the chunks are sequentially written to the SD card's filesystem by code designed for that purpose.
e) On the next power cycle, ZuluIDE returns to its normal operating mode.

Checksum info, flow control and various metadata could be communicated in-band over IDE by reserving certain designate blocks. Image deletion could be implemented in such a way too.

The objective would be to avoid needing to physically access/remove the SD card to upload images, even if power cycles are required.

Hopefully, this is clearer and possibly feasible without too much complexity and performant enough to be useful.

darry wrote on 2025-07-17, 23:44:

b) Once booted, the ZuluIDE only exposes a small "virtual" IDE block device that is not directly backed by storage, but by a memory buffer (say a few MBs in size)

...screech... We're operating in the land of microcontrollers. The RP2040 has · 264kB on-chip SRAM, for all application code Given this, your suggestion that "A few megabytes" is all we need is a non-starter. While the RP2040 _can_ execute code from flash, I don't think it would be possible to accomplish what you're proposing, given the hardware limitations. For the record, microcontrollers with more than a megabyte of SRAM have historically been extremely uncommon. They do exist today, but they'll generally cost you $8-15 each.
[snip]
Hopefully, this is clearer and possibly feasible without too much complexity and performant enough to be useful.
[/quote]

I don't think it's particularly feasible at all, since the memory you're referring to simply doesn't exist anywhere 😀

darry wrote on 2025-07-17, 23:44:

Hopefully, this is clearer and possibly feasible without too much complexity and performant enough to be useful.

aperezbios wrote on 2025-07-18, 00:34:

While the RP2040 _can_ execute code from flash, I don't think it would be possible to accomplish what you're proposing, given the hardware limitations. For the record, microcontrollers with more than a megabyte of SRAM have historically been extremely uncommon. They do exist today, but they'll generally cost you $8-15 each.

To add to what @aperezbios mentions above: This is staggeringly complex for multiple reasons, not the least of which is requiring what would effectively be multiple binaries that would be able to run on multiple processor architectures to handle what you're asking. The amount of development time and effort necessary to accomplish this and make it workable in the form of something a BIOS could see and then boot from would simply not be feasible, and even if it were, squeezing all of that into a microcontroller's SRAM would be nigh-impossible simply due to the wide number of platforms it would have to support to be effective.

@mbalmer:

Are there any news regarding pre-assembled Zulus with a drive mount?

crusher wrote on 2025-07-18, 06:12:

Are there any news regarding pre-assembled Zulus with a drive mount?

All ZuluIDE boards come pre-assembled and on a bracket. I assume you're actually wanting some sort of bundle. If so, it would be helpful to know _exactly_ what you want.

Hey all, I wanted to share how this project turned out for me.

Picked up the ZuluIDE + CD Audio board from Rabbit Hole Computing and it actually came preassembled even though I wasn't expecting that. I ended up deciding to not go the route of the addon board / OLED screen yet since it seems still mostly in the prototyping phase. With that being said, I did want some things to enhance the user experience to hold me over while that gets all ironed out...

Once I received the board, I grabbed the STL file that mbalmer created and is posted earlier in this thread and slightly modified it to suit my tastes. Thank you mbalmer for designing that.

After I modified the design, I grabbed a 5 mm led and 7mm push button pack both from Amazon and connected those up with some dupont wires I had laying around.

Next, I grabbed a Pico W also off Amazon for 11 bucks and connected that up to the CD audio board for web controls. I noticed after the fact that I didn't need to solder all 40 points and probably could have just connected the necessary ones and some corners....

Anyways it has been a fun project and I highly recommend the device. With the web interface I can easily handle my 80-90 images no problem and flipping between things as needed for installs or gaming is a breeze. I have tested CD Audio in DOS and Win 3.1 with nothing so far being bugged or broken, if your image is good, everything has worked as expected.

Finally, thanks again to the team that developed this, appreciate the great work.

mbalmer wrote on 2025-07-17, 23:13:

HOWEVER: If you are able to plug the ZuluIDE's USB port into a second computer, you can get access to the SD card's filesystem that way as long as the ZuluIDE isn't connected to a host -- in other words, if it isn't actively functioning as an IDE storage device. Basically, if the ZuluIDE is powered off, but you then give it power via the USB port, it can boot up and expose the filesystem of the attached SD card via USB.

To do so, you'll need to add enable_usb_mass_storage = 1 to the [IDE] section of the zuluide.ini file on the SD card. The ZuluIDE will then appear as a generic USB mass storage device to the host it's attached to via USB. Just be aware that transfers over the USB port that way will be slow -- limited to about 1MB/sec, which is the maximum the onboard USB controller supports. That way, if you want to add images to the card without having to open the case, you could just run a USB cable out of it and do it that way.

The significantly faster way would be to use an SD card extension, especially for adding images to the SD card, but the option is there. However, for making INI file changes, this mode would be perfect.

Thanks for the method, i wasn't able to use it with SD Extender as i had issues with the SDCard beeing detected (probably the extender was faulty).
And i don't liked using a SD Extender who floating outside a PC (nasty).
I couldn't use a 5.25" bay as it's a Micro ATX case who already use that bay for something else and all my PCI/ISA back brackets are used (had only 4, one for AGP, 1 for ISA card and 2 for PCI cards).

Then i got your idea to use the USB port and i have a empty USB front panel connector who was unused.

So i've tried with a adapter like this :

And it works fine, i connect a micro USB to USB femelle, then that USB adapter to it and to the USB 2.0 Internal 9 pins Femelle connector of my front panel IO.

Like this i can now access the SD Card on another PC when the PC is powered off.

I recommand doing that for people who have small cases and cannot do SD Extender/5.25 Bay method.

aperezbios wrote on 2025-07-18, 17:28:

All ZuluIDE boards come pre-assembled and on a bracket. I assume you're actually wanting some sort of bundle. If so, it would be helpful to know _exactly_ what you want.

I'm speaking of the Drive Mount mbalmer is working on.
Have a look here:

Re: ZuluIDE: A proper IDE device emulator for retro PCs

Btw i got a crash since lastest update :

1[0ms] Failed to open root directory.
2[0ms] Failed to open root directory.
3[11ms] Platform: ZuluIDE RP2040
4[11ms] FW Version: 2025.07.17-release Jul 18 2025 18:18:48
5[12ms] DIP switch settings: cablesel 0, drive_id 1 debug log 0
6[12ms] Flash chip size: 2048 kB
7[13ms] Flash unique ID: 0x22583D0F184064E6
8[99ms] FPGA initialization succeeded
9[99ms] I2S audio to expansion header enabled
10[100ms] -- System clock is set to 135428571Hz
11[101ms] Hardware UI not found.
12[101ms] I2C server found
13[102ms] Failed to open root directory.
14[140ms] SD card detected, FAT64 volume size: 121910 MB
15[140ms] SD MID: 0x03, OID: 0x53 0x44
16[140ms] SD Name: SR128
17[141ms] SD Date: 10/2024
18[141ms] SD Serial: 0xCF5AB48F
19[174ms] Waiting for USB enumeration to enter Card Reader mode.
20[1186ms] Initialized platform with filename request pipe
21[1189ms] Device is a CDROM drive
22[1224ms] Device 1 configuration:
23[1224ms] -- Max PIO mode: 3 (phy max 3)
24[1224ms] -- Max UDMA mode: -1 (phy max 0)
25[1225ms] -- Max blocksize: 4096 (phy max 4096)
26[1305ms] Initialized platform with device control.
27[1313ms] Set SSID from INI file to Livebox-0E22
28[1320ms] Set PASSWORD from INI file.
29[1320ms] Initialized platform controller with the status controller.
30[1322ms] Initialized platform controller with the display controller.
31[1322ms] Initialized platform controller with input receiver.
32[1361ms] Device 1 configuration:
33[1361ms] -- Max PIO mode: 3 (phy max 3)
34[1361ms] -- Max UDMA mode: -1 (phy max 0)
35[1361ms] -- Max blocksize: 4096 (phy max 4096)
36[2462ms] Loading last used image: "NoDisc.iso"
37[2462ms] Loading image "NoDisc.iso"
38[2480ms] Initialization complete!
39[2489ms] FPGA license request code: 0xE6 0x64 0x40 0x18 0x0F 0x3D 0x58 0x22 0xFF 0x7F 0xFF 0x36 0xEA 0xB0 0xD3 0xC2 0xE4 
40[2490ms] FPGA license accepted with status 0x83
41[2497ms] Max volume set to 100/100
42[2505ms] I2C Client subscribed to updates.
43[2532ms] Image response pipe is resetting
44[3605ms] Image response pipe is cleaning up
45[8075ms] --------------
46[8078075ms] CRASH!
47[8075ms] Platform: ZuluIDE RP2040
48[8076ms] FW Version: 2025.07.17-release Jul 18 2025 18:18:48
49[8076ms] SP: 0x20040F60
50[8077ms] PC: 0x000026EC
51[8077ms] LR: 0x1003701D
52[8077ms] R0: 0x00004000
53[8077ms] R1: 0x00000000
54[8078ms] R2: 0x0000BFF0
55[8078ms] R3: 0x00000000
56[8078ms] STACK 0x20040F60:    0x00004000 0x00000000 0x0000BFF0 0x00000000
57[8079ms] STACK 0x20040F70:    0x00000000 0x1003701D 0x000026EC 0x21000000
58[8080ms] STACK 0x20040F80:    0x2001A370 0x0000FFFF 0x00000000 0x200310DC
59[8080ms] STACK 0x20040F90:    0x200310E0 0x00000179 0x00000000 0x10028813
60[8081ms] STACK 0x20040FA0:    0x200310DC 0x20010D85 0x00000000 0x20038340

61[8082ms] STACK 0x20040FB0:    0x00000000 0x00000179 0x20030348 0x00000000
62[8083ms] STACK 0x20040FC0:    0x00000001 0x10026FD1 0x20018580 0x10026FD1
63[8083ms] STACK 0x20040FD0:    0x00000178 0x00000179 0xE000ED00 0x200114DF
64[8084ms] Only core 0 may attempt 'platform_emergency_log_save()'
65[26575ms] IDEATAPIDevice::cmd_identify_packet_device() response write timeout
66[26575ms] -- Command handler failed for IDE_CMD_IDENTIFY_PACKET_DEVICE

TgamesFR wrote on 2025-07-23, 00:15:

Btw i got a crash since lastest update :

Please submit an issue ticket on the Github repo with the crash log (it should be saved on the ZuluIDE's SD card as zuluerr.txt) and specific details about your hardware setup. Be sure to include:

• Motherboard manufacturer and model
• Chipset
• Processor and RAM count
• Additional items on the IDE bus other than the ZuluIDE
• Cards installed in the system

mbalmer wrote on 2025-07-23, 00:35:

Please submit an issue ticket on the Github repo with the crash log (it should be saved on the ZuluIDE's SD card as zuluerr.txt) […]
Show full quote

Please submit an issue ticket on the Github repo with the crash log (it should be saved on the ZuluIDE's SD card as zuluerr.txt) and specific details about your hardware setup. Be sure to include:

• Motherboard manufacturer and model
• Chipset
• Processor and RAM count
• Additional items on the IDE bus other than the ZuluIDE
• Cards installed in the system

That file wasn't generated it seems and now i don't have a crash just the message

"Command handler failed for IDE_CMD_IDENTIFY_PACKET_DEVICE".

I've noticed since the firmware updated on both ZuluIDE & PicoW, the device takes way longuer to start on cold boot.
The PC not detect the ZuluIDE and i need to do a reboot to get it detected (that behavior happens all the time now).
Then it's good as long i not poweroff the PC.
With firmwares downgraded the issue is gone.

Also the web interface seems very unresponsive too, takes like 2 minutes to load it the first time when i enter his IP.
And it happens that it just not load the gamelist (the UI loads but when i try select something nothing in the list) and i need refresh until i get it.

Very strange because once i've downgraded everything works great again.

I don't have many games only 40 images.

Hello! I am very interested in zuluide, but I have a number of questions. Please tell me, where can I buy zuluide with cd dac board? And how can you make a control board, preferably with buttons not with an encoder (I hate it). And the second question is, is the firmware for PLD publicly available?

TgamesFR wrote on 2025-07-23, 16:38:

That file wasn't generated it seems and now i don't have a crash just the message […]
Show full quote

That file wasn't generated it seems and now i don't have a crash just the message

"Command handler failed for IDE_CMD_IDENTIFY_PACKET_DEVICE".

I've noticed since the firmware updated on both ZuluIDE & PicoW, the device takes way longuer to start on cold boot.
The PC not detect the ZuluIDE and i need to do a reboot to get it detected (that behavior happens all the time now).
Then it's good as long i not poweroff the PC.
With firmwares downgraded the issue is gone.

Also the web interface seems very unresponsive too, takes like 2 minutes to load it the first time when i enter his IP.
And it happens that it just not load the gamelist (the UI loads but when i try select something nothing in the list) and i need refresh until i get it.

Very strange because once i've downgraded everything works great again.

I don't have many games only 40 images.

Regardless -- create an issue ticket on the github repo. That way all of the efforts to address things can be centralized there.

Mr.Hunt wrote on 2025-07-23, 17:49:

Hello! I am very interested in zuluide, but I have a number of questions. Please tell me, where can I buy zuluide with cd dac board? And how can you make a control board, preferably with buttons not with an encoder (I hate it). And the second question is, is the firmware for PLD publicly available?

You can buy the ZuluIDE with the DAC shield from several places. Check here and you can go directly to a shop based on region. If your region isn't listed, you can order it via the eBay listing linked on the "where to buy" page.

For the control board, there's only the one design at the moment.

Assuming that by "firmware for PLD" you mean the firmware for the microcontroller, then yes, the firmware for the RP2040 microcontroller is available on the Github repo.