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.
