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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 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 Yesterday, 23:44:

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

aperezbios wrote on Today, 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.