mbalmer wrote on 2025-10-30, 16:05:

If your Slot 1 build has a "quick boot" option in the BIOS, you can switch it off and it will extend the boot process long enoug […]
Show full quote

If your Slot 1 build has a "quick boot" option in the BIOS, you can switch it off and it will extend the boot process long enough for the ZuluIDE to finish its job.

Sometimes, instead of a "quick boot" option, you'll get an "Above 1MB memory test" option instead, and in that case, turn it on instead.

Quick Boot usually skips any extended memory testing and doesn't generally probe for device changes from boot to boot unless explicitly told to. If it does test all of the memory, it's usually only one pass, and it's over pretty quickly.

The Above 1MB Memory Test is exactly what it says on the tin -- a lot of BIOSes would only test the first 1MB of memory and then skip testing the rest (it would merely count the rest, usually by toggling all of the address lines sequentially and seeing where changes are to determine where the "end" of memory was).

Considering the age of a lot of our retro equipment, forcing the board to run the full suite of POST tests instead of a quick version is usually a good idea, IMO. Another option that's sometimes present is to increase the timeout value on the BIOS's scan of the IDE bus, but that option isn't present in all BIOSes.

Fun fact, since last update the ZuluIDE is now fast enough to always be detected in bios.
I've posted on github, few code fixes from recents bugs i've found here : https://github.com/ZuluIDE/ZuluIDE-firmware/issues/259
I guessing @morio not retested his code on the RP2040 so he left over a bug related to USB Card Reader mode and his new code to parse .cue file have a issue with \0 (visible in logs if you checking too with bigger files names).

Except that so far i've encountered a smooth experience recently with the device.
The only downside is the I2C board who use the Raspberry Pi Pico, his Wifi is so weak and only detect 2.4Ghz wifi, i wonder if in a new revision we could use something better.
I can deal with 2.4Ghz only but the main issue is sometimes the I2C board not catch the wifi so cannot init his IP.
The "fix" i've found was to move my PC in the room, to get a stable connection. Many others of my devices catch the wifi without any issue.
Strangely trying to mount a Wifi hotspot from phone or PC never works with the I2C board, it seems he wants only my main Wifi (probably encryptions related things no idea).

TgamesFR wrote on 2025-11-30, 14:46:

Fun fact, since last update the ZuluIDE is now fast enough to always be detected in bios. I've posted on github, few code fixes […]
Show full quote

Fun fact, since last update the ZuluIDE is now fast enough to always be detected in bios.
I've posted on github, few code fixes from recents bugs i've found here : https://github.com/ZuluIDE/ZuluIDE-firmware/issues/259
I guessing @morio not retested his code on the RP2040 so he left over a bug related to USB Card Reader mode and his new code to parse .cue file have a issue with \0 (visible in logs if you checking too with bigger files names).

Except that so far i've encountered a smooth experience recently with the device.
The only downside is the I2C board who use the Raspberry Pi Pico, his Wifi is so weak and only detect 2.4Ghz wifi, i wonder if in a new revision we could use something better.
I can deal with 2.4Ghz only but the main issue is sometimes the I2C board not catch the wifi so cannot init his IP.
The "fix" i've found was to move my PC in the room, to get a stable connection. Many others of my devices catch the wifi without any issue.
Strangely trying to mount a Wifi hotspot from phone or PC never works with the I2C board, it seems he wants only my main Wifi (probably encryptions related things no idea).

This is all good to hear.

As for the WiFi strength thing, it's definitely something we've thought about and are trying out some other ideas to see how well they might work, but each of those involves a pretty significant hardware redesign so it's not high on the priority list right now.

mbalmer wrote on 2025-11-30, 21:37:

This is all good to hear.

As for the WiFi strength thing, it's definitely something we've thought about and are trying out some other ideas to see how well they might work, but each of those involves a pretty significant hardware redesign so it's not high on the priority list right now.

Thanks for your reply.
Right now i've moved back my PC to his original position and i'm using a old TP-Link Wifi Router who do 2.4Ghz not connected to internet (so only LAN) it does the trick.
Can access the webpage from my smartphone fine on 1st try. Before using my home wifi was very erratic even moved to a different location.

TgamesFR wrote on 2025-11-30, 14:46:

Fun fact, since last update the ZuluIDE is now fast enough to always be detected in bios.
I've posted on github, few code fixes from recents bugs i've found here : https://github.com/ZuluIDE/ZuluIDE-firmware/issues/259
I guessing @morio not retested his code on the RP2040 so he left over a bug related to USB Card Reader mode and his new code to parse .cue file have a issue with \0 (visible in logs if you checking too with bigger files names).

As I mentioned in the issue linked above, I believe we have resolved the two separate issues you experienced, so please do try the development build I linked to in the GitHub issue, and let us know if it resolves these two outstanding issues for you.

TgamesFR wrote on 2025-11-30, 14:46:

The only downside is the I2C board who use the Raspberry Pi Pico, his Wifi is so weak and only detect 2.4Ghz wifi, i wonder if in a new revision we could use something better.
I can deal with 2.4Ghz only but the main issue is sometimes the I2C board not catch the wifi so cannot init his IP.
The "fix" i've found was to move my PC in the room, to get a stable connection. Many others of my devices catch the wifi without any issue.

The Infineon https://www.infineon.com/part/CYW43439 radio module used on the Pico W/2W is a single-band 2.4GHz radio, so single-band Wi-Fi is all it is capable of. The transmit power of the Infineon-manufactured 2.4GHz radio module has very low very transmit power, about 10 milliwatts, and depending on the quality of the receive antennas in your Wi-Fi router. There are many factors that can affect wireless performance, including the density of building materials in the walls of your building, the overall noisefloor in the 2.4GHz band, etc etc. It's less about the Pico W's radio "catching" your in-home Wi-Fi, and far more likely to be that your router simply cannot "hear" (at an RF level) the Pico W transmitting, because it is an inherently low power hardware design. This can be further worsened by if your ZuluIDE is mounted in a metal/steel computer enclosure, which can have the effect of acting like a (leaky) faraday cage, significantly diminishing signals from reaching receivers, such as your Wi-Fi router, that are outside of the enclosure.

TgamesFR wrote on 2025-11-30, 14:46:

Strangely trying to mount a Wifi hotspot from phone or PC never works with the I2C board, it seems he wants only my main Wifi (probably encryptions related things no idea).

The current firmware implementation requires you to connect the Wi-Fi control board to an access point, and it does not support ad-hoc wireless connections, such as the ones you are describing. This is not expected to work.

aperezbios wrote on 2025-12-03, 00:33:

As I mentioned in the issue linked above, I believe we have resolved the two separate issues you experienced, so please do try the development build I linked to in the GitHub issue, and let us know if it resolves these two outstanding issues for you.

Thanks for your replies and for quick fixes.

I've confirmed today on the Github issue post that both issues are fixed.
Tested around 30+ bin/cue games under Windows 98 SE and DOS 7.1 all redbook audios are readable.
Same for USB Mass Storage who works too on Windows 10.

Just another thing i've noticed... (but not related to this report and was already like this before the fix).
Under DOS 7.1 (the pure DOS of Windows 98 SE) sometimes if you swap to a new bin/cue image it won't read the redbook audio in the next game. Doing a reboot of the PC and go back to DOS fix the issue by itself and it read it. That bug not happen at all on Windows 98 SE so no idea if it's really related to ZuluIDE.

About that DOS issue, it can occurs like right on the 2nd game, sometimes after 4/5 games.
All dumps are fine and checked and their cue files are corrects ofc.

1Few tests i've done on Dos 7.1: 
2
3ESPN Extreme Games (OK) -> Tomb Raider (no music)
4reboot
5Tomb Raider (OK) -> ESPN Extreme Games (no music)
6reboot
7Screamer 2 (OK) -> Screamer (OK) -> Tomb Raider (no music)
8reboot
9Tomb Raider (OK) -> Screamer (OK) -> Quake (OK) -> Screamer 2 (no music).

Doing the exact same test directly on Windows 98 using the Music CD Player i don't have any issue.
So idk probably something related to eject under DOS ? Because as soon i reboot it auto-fix itself.
For all my tests i'm using the http webpage to change the image.

TgamesFR wrote on 2025-12-03, 16:59:

I've confirmed today on the Github issue post that both issues are fixed.
Tested around 30+ bin/cue games under Windows 98 SE and DOS 7.1 all redbook audios are readable.
Same for USB Mass Storage who works too on Windows 10.

Great, thanks for confirming. As stated in the issue, I've gone ahead and made a new ZuluIDE firmware release this morning, which incorporates these two bugfixes.

The new firmware is downloadable at https://github.com/ZuluIDE/ZuluIDE-firmware/r … tag/v2025.12.03

It's great to see this device maturing. There's only one thing stopping me buying one right now - a DOS-based utility to swap CD disc images. Here's my scenario - I have a 486DX2 with about 300 games installed. Most of those are directly installed on the 2GB HDD partition, but larger titles use CDs, either for CD audio or just size reasons. I have those CDs in a binder, and need to pull them out and put them in the drive to play. I use LaunchBox for DOS as a menu, and already run launch scripts per game to configure the system for the requirements of that game, such as enabling speed throttling, or unloading drivers to free up conventional memory. What I want is to just be able to run a dos utility that basically says "ZuluMnt "SomeImage.cue" and the ZuluIDE swaps to that image for me, without needing to physically do anything. That would allow me to automatically mount the required disc image when launching the game, and unmount it when done.

I saw someone asked about this before, but I want to ask something very specific. Has any thought been given to simply mapping an unused ATAPI command code to trigger this behaviour? There's a bunch of unused byte codes in ATAPI. It seems to me, since we're emulating the entire device, it should be possible to (optionally) enable a feature to map one or more of these commands for our own purposes. It should then also be possible to send those custom commands from a trivial DOS utility that instructs the drive to change disc images. Has any thought been given to this idea? Can anyone see any reason why it couldn't work? I'd personally prefer this to a physical control panel, although there's nothing stopping both things co-existing.

DivByZero wrote on 2025-12-04, 22:13:

There's only one thing stopping me buying one right now - a DOS-based utility to swap CD disc images. Here's my scenario - I have a 486DX2 with about 300 games installed. Most of those are directly installed on the 2GB HDD partition, but larger titles use CDs, either for CD audio or just size reasons. I have those CDs in a binder, and need to pull them out and put them in the drive to play. I use LaunchBox for DOS as a menu, and already run launch scripts per game to configure the system for the requirements of that game, such as enabling speed throttling, or unloading drivers to free up conventional memory. What I want is to just be able to run a dos utility that basically says "ZuluMnt "SomeImage.cue" and the ZuluIDE swaps to that image for me, without needing to physically do anything. That would allow me to automatically mount the required disc image when launching the game, and unmount it when done.

I saw someone asked about this before, but I want to ask something very specific. Has any thought been given to simply mapping an unused ATAPI command code to trigger this behaviour? There's a bunch of unused byte codes in ATAPI. It seems to me, since we're emulating the entire device, it should be possible to (optionally) enable a feature to map one or more of these commands for our own purposes. It should then also be possible to send those custom commands from a trivial DOS utility that instructs the drive to change disc images. Has any thought been given to this idea? Can anyone see any reason why it couldn't work? I'd personally prefer this to a physical control panel, although there's nothing stopping both things co-existing.

From a purely-technical POV, there's nothing to prevent such a thing from being implemented. As one might expect, the only limiting factors are time and money. In addition to the ZuluIDE firmware enhancements that would be required, a separate DOS/Windows utility would also need to be authored, and then maintained indefinitely. It's definitely one of those "easier said (or asked for, in this case) than done" sort of situations. If a third party wanted to work on such a thing, I'd be happy to assist them in doing so, but in the near-term, there are no immediate plans to implement such functionality.

It should be noted, though, that it's already possible to do media selection via a web UI. That HTTP server also has a JSON API/service, which is documented here: https://github.com/ZuluIDE/ZuluIDE-HTTP-PicoW … the-web-service.

If you'd like, I could send you one of these assemblies for you to experiment with on a trial basis. Where are you located?

aperezbios wrote on 2025-12-04, 23:34:

From a purely-technical POV, there's nothing to prevent such a thing from being implemented. As one might expect, the only limit […]
Show full quote

DivByZero wrote on 2025-12-04, 22:13:

There's only one thing stopping me buying one right now - a DOS-based utility to swap CD disc images. Here's my scenario - I have a 486DX2 with about 300 games installed. Most of those are directly installed on the 2GB HDD partition, but larger titles use CDs, either for CD audio or just size reasons. I have those CDs in a binder, and need to pull them out and put them in the drive to play. I use LaunchBox for DOS as a menu, and already run launch scripts per game to configure the system for the requirements of that game, such as enabling speed throttling, or unloading drivers to free up conventional memory. What I want is to just be able to run a dos utility that basically says "ZuluMnt "SomeImage.cue" and the ZuluIDE swaps to that image for me, without needing to physically do anything. That would allow me to automatically mount the required disc image when launching the game, and unmount it when done.

I saw someone asked about this before, but I want to ask something very specific. Has any thought been given to simply mapping an unused ATAPI command code to trigger this behaviour? There's a bunch of unused byte codes in ATAPI. It seems to me, since we're emulating the entire device, it should be possible to (optionally) enable a feature to map one or more of these commands for our own purposes. It should then also be possible to send those custom commands from a trivial DOS utility that instructs the drive to change disc images. Has any thought been given to this idea? Can anyone see any reason why it couldn't work? I'd personally prefer this to a physical control panel, although there's nothing stopping both things co-existing.

From a purely-technical POV, there's nothing to prevent such a thing from being implemented. As one might expect, the only limiting factors are time and money. In addition to the ZuluIDE firmware enhancements that would be required, a separate DOS/Windows utility would also need to be authored, and then maintained indefinitely. It's definitely one of those "easier said (or asked for, in this case) than done" sort of situations. If a third party wanted to work on such a thing, I'd be happy to assist them in doing so, but in the near-term, there are no immediate plans to implement such functionality.

It should be noted, though, that it's already possible to do media selection via a web UI. That HTTP server also has a JSON API/service, which is documented here: https://github.com/ZuluIDE/ZuluIDE-HTTP-PicoW … the-web-service.

If you'd like, I could send you one of these assemblies for you to experiment with on a trial basis. Where are you located?

Why not just define a simply API/command set, exposed over a serial port, for example, and let people write their scripts/TSRs, etc to do this for any OS they need want ?

darry wrote on 2025-12-05, 00:30:

Why not just define a simply API/command set, exposed over a serial port, for example, and let people write their scripts/TSRs, etc to do this for any OS they need want ?

With which serial port, exactly? We've considered this as well, it's "just" easier said than done 😀 All (especially embedded) hardware has limitations.

Since we do already have a USB serial console, that would be the most sensible way to implement this, actually taking into consideration the hardware design and available I/O's.

aperezbios wrote on 2025-12-04, 23:34:

From a purely-technical POV, there's nothing to prevent such a thing from being implemented. As one might expect, the only limit […]
Show full quote

DivByZero wrote on 2025-12-04, 22:13:

There's only one thing stopping me buying one right now - a DOS-based utility to swap CD disc images. Here's my scenario - I have a 486DX2 with about 300 games installed. Most of those are directly installed on the 2GB HDD partition, but larger titles use CDs, either for CD audio or just size reasons. I have those CDs in a binder, and need to pull them out and put them in the drive to play. I use LaunchBox for DOS as a menu, and already run launch scripts per game to configure the system for the requirements of that game, such as enabling speed throttling, or unloading drivers to free up conventional memory. What I want is to just be able to run a dos utility that basically says "ZuluMnt "SomeImage.cue" and the ZuluIDE swaps to that image for me, without needing to physically do anything. That would allow me to automatically mount the required disc image when launching the game, and unmount it when done.

I saw someone asked about this before, but I want to ask something very specific. Has any thought been given to simply mapping an unused ATAPI command code to trigger this behaviour? There's a bunch of unused byte codes in ATAPI. It seems to me, since we're emulating the entire device, it should be possible to (optionally) enable a feature to map one or more of these commands for our own purposes. It should then also be possible to send those custom commands from a trivial DOS utility that instructs the drive to change disc images. Has any thought been given to this idea? Can anyone see any reason why it couldn't work? I'd personally prefer this to a physical control panel, although there's nothing stopping both things co-existing.

From a purely-technical POV, there's nothing to prevent such a thing from being implemented. As one might expect, the only limiting factors are time and money. In addition to the ZuluIDE firmware enhancements that would be required, a separate DOS/Windows utility would also need to be authored, and then maintained indefinitely. It's definitely one of those "easier said (or asked for, in this case) than done" sort of situations. If a third party wanted to work on such a thing, I'd be happy to assist them in doing so, but in the near-term, there are no immediate plans to implement such functionality.

It should be noted, though, that it's already possible to do media selection via a web UI. That HTTP server also has a JSON API/service, which is documented here: https://github.com/ZuluIDE/ZuluIDE-HTTP-PicoW … the-web-service.

If you'd like, I could send you one of these assemblies for you to experiment with on a trial basis. Where are you located?

I'd be happy to develop this functionality TBH. For me it'd be a killer feature, and I'm sure others would find it useful too. I've had a quick poke around the firmware, and it looks pretty logical and well structured. I have some time coming up over the new year when I could do some work on this, and I honestly don't think it'd take all that long to get working (famous last words). I'm located in Australia. Feel free to drop me a DM and we can discuss details if you're interested.

I wonder if this can utilize the cd audio cable people would've used for games back in the day. No idea how implementation would work, if at all.

RetroLizard wrote on 2025-12-05, 02:26:

I wonder if this can utilize the cd audio cable people would've used for games back in the day. No idea how implementation would work, if at all.

I don't understand what you mean. ZuluIDE already supports Red Book CD Audio playback emulation, with the DAC "hat".

aperezbios wrote on 2025-12-05, 00:37:

darry wrote on 2025-12-05, 00:30:

Why not just define a simply API/command set, exposed over a serial port, for example, and let people write their scripts/TSRs, etc to do this for any OS they need want ?

With which serial port, exactly? We've considered this as well, it's "just" easier said than done 😀 All (especially embedded) hardware has limitations.

Since we do already have a USB serial console, that would be the most sensible way to implement this, actually taking into consideration the hardware design and available I/O's.

The optional Pi zero W USB used for the WEB server UI has a UART, AFAIU. Activating it disables the WIFI and Bluetooth, again, AFAIU. Would adding control through serial I/O as a switchable option be feasible ?

Anything older than a Pentium won't have USB ports, but COM ports are ubiquitous.

darry wrote on 2025-12-05, 03:32:

aperezbios wrote on 2025-12-05, 00:37:

darry wrote on 2025-12-05, 00:30:

Why not just define a simply API/command set, exposed over a serial port, for example, and let people write their scripts/TSRs, etc to do this for any OS they need want ?

With which serial port, exactly? We've considered this as well, it's "just" easier said than done 😀 All (especially embedded) hardware has limitations.

Since we do already have a USB serial console, that would be the most sensible way to implement this, actually taking into consideration the hardware design and available I/O's.

The optional Pi zero W USB used for the WEB server UI has a UART, AFAIU. Activating it disables the WIFI and Bluetooth, again, AFAIU. Would adding control through serial I/O as a switchable option be feasible ?

Anything older than a Pentium won't have USB ports, but COM ports are ubiquitous.

It's certainly possible, yes, but converting between a serial UART and virtual USB serial is relatively trivial. Also, you'd almost surely need an RS-232 line driver to adapt from RS-232 voltage levels to TTL levels anyways.

aperezbios wrote on 2025-12-05, 02:28:

RetroLizard wrote on 2025-12-05, 02:26:

I wonder if this can utilize the cd audio cable people would've used for games back in the day. No idea how implementation would work, if at all.

I don't understand what you mean. ZuluIDE already supports Red Book CD Audio playback emulation, with the DAC "hat".

I mean connecting the ZuluIDE device to the sound card via an analog audio cable, like one might have done back in the day.

RetroLizard wrote on 2025-12-05, 04:45:

aperezbios wrote on 2025-12-05, 02:28:

RetroLizard wrote on 2025-12-05, 02:26:

I wonder if this can utilize the cd audio cable people would've used for games back in the day. No idea how implementation would work, if at all.

I don't understand what you mean. ZuluIDE already supports Red Book CD Audio playback emulation, with the DAC "hat".

I mean connecting the ZuluIDE device to the sound card via an analog audio cable, like one might have done back in the day.

Yep, it supports it, which is why I believe this project is now a viable CD drive replacement. You need the DAC "hat" he's talking about though, which you can see here:
https://shop.rabbitholecomputing.com/products … -zuluide-owners
Plugs into the board, gives you decoded redbook audio out via the analog audio connector to your sound card.

Oh. That's cool. I didn't realize it was already implemented.

Definitely gonna pick one of these up.

aperezbios wrote on 2025-12-03, 17:41:

Great, thanks for confirming. As stated in the issue, I've gone ahead and made a new ZuluIDE firmware release this morning, which incorporates these two bugfixes.

The new firmware is downloadable at https://github.com/ZuluIDE/ZuluIDE-firmware/r … tag/v2025.12.03

@aperezbios , the lastest issue #263 i had was fixed today by @morio, you can push it for new release.

it's great because it was the last bug i had with the device when i was loading specifics games before others.

So far i don't have any others bugs.

TgamesFR wrote on Yesterday, 15:37:

@aperezbios , the lastest issue #263 i had was fixed today by @morio, you can push it for new release.

it's great because it was the last bug i had with the device when i was loading specifics games before others.

So far i don't have any others bugs.

The bugfix has now been incorporated into the https://github.com/ZuluIDE/ZuluIDE-firmware/r … tag/v2025.12.06 firmware release.

I'm sure there are other bugs that will eventually be discovered and squashed 😀 Such is the nature of something as complex as the ATA & ATAPI specifications.

Overall, however, I'm quite pleased with where we're currently at, thanks to your help testing and reporting.