trunk70 wrote on 2026-02-01, 09:18:

Oh thank you! But i live in Europe (Belgium) and I already have 3D printed the 5.25 enclosure :-) (I'm new in 3D Printing, Bamb […]
Show full quote

mbalmer wrote on 2026-01-31, 23:58:

Front-panel board designer and enclosure designer here. […]
Show full quote

trunk70 wrote on 2026-01-31, 12:05:

Page 4... Sorry for asking.

It's a shame that we can't buy it officially and that this isn't clearly stated on the official website (on the store page). 🙁

Front-panel board designer and enclosure designer here.

Part of the reason it wasn't there from the start is that when the ZuluIDE was first conceived, a front panel wasn't seen as needed because the initial assumption was that it would largely be used in cases where the media wasn't being changed often or where the media could be cycled using the OS's software-eject mechanism (think Mac OS 9, OS X, modern Windows and Linux versions).

Obviously, that assumption didn't hold up very long. 🤣

At the same time, one of the major pushes that we've been trying to make has been largely in the realm of device speed -- which, as you noted earlier, is the best amongst the bunch of IDE device emulators out there -- something we're definitely proud of.

That said, the consistent need for a hardware-based front panel is definitely something we're on. It's DIY at the moment primarily for a few reasons: first, getting it to work consistently at the start wasn't particularly simple and it's needed a lot of internal revisions to get to the point where it's as polished as it is; second, much like the DAC add-on board, not everyone wanted it, and the number of people who did want it and couldn't make their own with a small amount of effort was very, very small -- to the point where I've actually made a few of them myself and shipped them to a couple of folks who contacted me privately in that circumstance; third, because so much of the codebase is shared with the sister ZuluSCSI project, we've actually been trying to marry the two devices together in that regard so that both the ZuluIDE and the ZuluSCSI have workable, functional front panel controls.

If you're in the US (or really, anywhere that the US can ship to) you can always PM me and I will be happy to look up how much it would take for me to make up a front panel board on its own or a full 3D-printed 5.25" drive bay enclosure for you and ship it to you. Just please be aware that if I have to ship it internationally, there may be additional duties necessary for you to receive it.

Oh thank you! But i live in Europe (Belgium) and I already have 3D printed the 5.25 enclosure 😀 (I'm new in 3D Printing, Bambulab P2S 😉 ).

I need the parts :

-Oled screen
-Rotary Encoder
-Push buttons

But I don't know what and where to order (I have the Zulu IDE V1 + DAC + PICO) and how to assemble the all parts. I don't understand very well the use of Qwiic port.

The final goal is to put the Zulu IDE in my main MS-DOS machine (i don't like the web interface and i switch often CD-ROM for my testing purpose).

Thanks 😀

There is an updated version of the enclosure that closes the gaps around the SD card slot and USB port and also provides a nice footprint to plop down the control board. There's two options with the updated enclosure: a full-length bracket that's intended to fit in a full-depth 5.25" bay, and a "stubby" version that fits in small cases where the full 5.25" bay width and height are present, but the depth of the bay is reduced. I've attached STL files for those for those that want them here.

As for the interface board, it's not terribly difficult to put it together from a blank PCB and parts but it does require some surface-mount soldering skills. The interface isn't quite as simple as the Gotek -- unlike the Gotek, where the screen is the only external device on the I2C bus, the ZuluIDE has to combine the screen, rotary encoder, and pushbuttons together all onto the I2C bus. As a result, the interface board needs a little I/O expander chip that allows us to combine all of those signals together in a fashion that doesn't cause problems.

If you're comfortable putting that together on your own, I'm happy to provide you with instructions on how to do that, but if not, I'm happy to make up a board for you and send it your way with instructions on how to either finish the through-hole parts off yourself, or fully-assembled and ready to plug in to your ZuluIDE.

I am very comfortable with SMD soldering and would love such instructions. Printed the carrier, so just waiting for the front panel now 😀

buffi wrote on 2026-02-02, 19:50:

I am very comfortable with SMD soldering and would love such instructions. Printed the carrier, so just waiting for the front panel now 😀

Where are you located? We can send you one.

aperezbios wrote on 2026-02-02, 20:31:

buffi wrote on 2026-02-02, 19:50:

I am very comfortable with SMD soldering and would love such instructions. Printed the carrier, so just waiting for the front panel now 😀

Where are you located? We can send you one.

Sweden!

Also, I'm a little curious how the carrier is supposed to be printed. I had the best result with printing it with the front facing panel face-down, and then using organic supports for the rest, but it doesn't really feel like it's designed for printing like that since there's just a lot of overhangs which could be designed to not need supports...

That's kindof true for printing it with uh.. bottom down as well though 😀

... sorry for spamming but I can't seem to figure out how to edit posts on this forum.

Anyways, I was planning to modify the carrier a bit to have it more printable, but there's also some weird bugs in the model above, like the beam here is hollow, causing it to not print well.

https://imgur.com/a/5HzCnlY

buffi wrote on 2026-02-03, 17:43:

Anyways, I was planning to modify the carrier a bit to have it more printable, but there's also some weird bugs in the model above, like the beam here is hollow, causing it to not print well.

Before you do that, try this revised bracket design instead:

https://www.thingiverse.com/thing:7167806

aperezbios wrote on 2026-02-04, 01:42:

buffi wrote on 2026-02-03, 17:43:

Anyways, I was planning to modify the carrier a bit to have it more printable, but there's also some weird bugs in the model above, like the beam here is hollow, causing it to not print well.

Before you do that, try this revised bracket design instead:

https://www.thingiverse.com/thing:7167806

This printed fine with faceplate down, and supports for the part in the far back.
I noticed that the side screwholes were smaller in this one, which caused the screws to not thread into them well, but found some other screws that worked.

@mbalmer, @aperezbios,

I've received my ZuluIDE V2, however i've noticed a important issue.

With the new ZuluIDE V2, the ZuluIDE V2 CD Audio DAC ouput is way lower compared to the ZuluIDE V1 CD Audio DAC.

I need increase a lot my sound volume to ear it correctly. The problem it's on many games i can't change the sound effects volume so sounds effects are very high obviously.

It is a firmware issue or a hardware issue ?

For reference, the ZuluIDE V2 Audio DAC comes from Serdashop and i've not changed the max_volume setting in config as i've wrote it (so should be at 100 already).
And i'm using the second port for CD Audio with a added CD Audio connector as can't use the first one as his place is not reachable in my setup (was same setup for V1 with added port too).

Also i've noticed under WIndows 98 when loading a image it takes around 35 seconds to load it (wasn't the case with V1), on DOS however it's instant.

TgamesFR wrote on 2026-02-06, 02:47:

@mbalmer, @aperezbios, With the new ZuluIDE V2, the ZuluIDE V2 CD Audio DAC ouput is way lower compared to the ZuluIDE V1 CD Aud […]
Show full quote

@mbalmer, @aperezbios,
With the new ZuluIDE V2, the ZuluIDE V2 CD Audio DAC ouput is way lower compared to the ZuluIDE V1 CD Audio DAC.

I need increase a lot my sound volume to ear it correctly. The problem it's on many games i can't change the sound effects volume so sounds effects are very high obviously.

It is a firmware issue or a hardware issue ?

Without knowing which version of the firmware is currently on your ZuluIDE, I can't be certain, but I am relatively certain that electrically, there's no difference between the ZuluIDE V1 DAC board and the ZuluIDE V2 DAC board. It's literally the same schematic, so it seems likely to be firmware-related. Either way, this isn't a support forum, so feel free to report it via the proper channels, and we will investigate.

aperezbios wrote on 2026-02-06, 03:03:

Without knowing which version of the firmware is currently on your ZuluIDE, I can't be certain, but I am relatively certain that electrically, there's no difference between the ZuluIDE V1 DAC board and the ZuluIDE V2 DAC board. It's literally the same schematic, so it seems likely to be firmware-related. Either way, this isn't a support forum, so feel free to report it via the proper channels, and we will investigate.

Thanks for your fast answer,

I'm using lastest firmware, i've reported it on the github.

So i've did a speed benchmark of the ZuluIDE V2.

I did it on Windows XP (in case there was a bottleneck under Windows 98).

And so far, it seems (on slot 1 UDMA 2 - ATA 33 board) it goes slower than the V1.
Ofc ZuluIDE have DMA enabled in Windows and bios detected it as UDMA 2 mode.

Here the ZuluIDE V2 benchmark :

And here my SSD benchmark :

As you can see, on the SSD benchmark it goes up to 30.03 MB/sec max who is normal as my system cannot go further than 33 MB/S with UDMA 2 - ATA 33.

However on the ZuluIDE V2, it stuck at maximum 3 MB/s (20X) who is way way slower than with the V1, i was around 6-7 MB/S (40X-46.7X).

Just to be really sure i've used others tools to benchmark and it was exactly same results sadly.

My MicroSD card is a Sandisk 128GB Extreme Pro (A2) who is one the fastest MicroSD card who exist.
And my ZuluIDE config is that :

1[IDE]
2enable_usb_mass_storage = 1
3no_media_on_init = 1
4reinsert_media_after_eject = 0
5reinsert_media_on_inquiry = 0
6init_with_last_used_image = 0
7quiet_image_parsing = 1
8
9[UI]
10wifipassword="XXXX"
11wifissid="XXXX"

For more informations, the ZuluIDE is plugged as primary/slave drive on the same IDE cable as my SSD.

For the moment, i will switch back to the V1, i hope it's a fixable bug otherwhise i will have to return it.
I will post it also on github.

TgamesFR wrote on 2026-02-07, 02:39:

%< snip >% […]
Show full quote

%< snip >%

My MicroSD card is a Sandisk 128GB Extreme Pro (A2) who is one the fastest MicroSD card who exist.
And my ZuluIDE config is that :

Copy code to clipboard

1[IDE]
2enable_usb_mass_storage = 1
3no_media_on_init = 1
4reinsert_media_after_eject = 0
5reinsert_media_on_inquiry = 0
6init_with_last_used_image = 0
7quiet_image_parsing = 1
8
9[UI]
10wifipassword="XXXX"
11wifissid="XXXX"

For more informations, the ZuluIDE is plugged as primary/slave drive on the same IDE cable as my SSD.

For the moment, i will switch back to the V1, i hope it's a fixable bug otherwhise i will have to return it.
I will post it also on github.

Just to mention it (because I know @aperezbios will ask eventually if he hasn’t already) you’ll want to have debug logs available to help clarify what’s going on here. You can either add debug = 1 to your zuluide.ini file or physically flip the debug switch on the board to enable logging.

There are potentially a million reasons why the V1 performs faster while the V2 performs slower depending on your hardware configuration, so that will be something the team will definitely want to figure out.

mbalmer wrote on 2026-02-08, 17:28:

Just to mention it (because I know @aperezbios will ask eventually if he hasn’t already) you’ll want to have debug logs available to help clarify what’s going on here. You can either add debug = 1 to your zuluide.ini file or physically flip the debug switch on the board to enable logging.

There are potentially a million reasons why the V1 performs faster while the V2 performs slower depending on your hardware configuration, so that will be something the team will definitely want to figure out.

@mbalmer,
Yes i've shared yesterday, a full log with debug=1.
Here included now too.

@aperezbios, told me in reply that while checking logs the ZuluIDE was not showing why it was slow, because the ZuluIDE says set to UDMA 2
On my side, the bios was detecting the ZuluIDE V2 as UDMA 2 so it's not a problem on my side.
Because right away, i've swapped the ZuluIDE with a SSD and i was able to reach 30MB/S on the same primary slave slot on the IDE cable.
So cleary my hardware is able to output that speed.

At the moment, i've remounted back the V1, because the main reason i've upgraded to V2 was the advertised increased speed (on website and here in that topic).
And i've redid a benchmark and on the V1 i still get ~6MB/S (under DOS, Windows 98 and XP) (which is expected for the V1) but strangely twice the speed of the V2 (~ 3MB/S).

I know 28 MB/s is theorical, but i was expecting at least 2x-3x times the speed of the V1 (something like 16MB/s at least) not lower xD.

To be really sure, i've also plugged the V2 on another computer, this one support UDMA 6 ( ATA 133), and same the ZuluIDE V2 was stuck at 3MB/S.

For the CD audio low volume, Serge from Serdashop sended me a DAC board replacement to try out if it's that the problem.
I don't know if others people noticed the problem, as to really notice it you need direct compare with the V1 on same speaker levels.
I've calculated it was around 2.5x lower in output.

And lastly, i don't know where the issue comes for Windows 98 accessing the ZuluIDE V2, but everytimes it try to access it (after a image change, after a reboot...) it freeze and takes 35 seconds to be able to access it).

In case the issue is not resolvable, (i really hope it will be), do you still have ZuluIDE V1 stock in replacement ?

Hello, I just got a ZuluIDE v2 with the Audio+PicoShield v2.
I looked at the github, documentation and made a few searches, but I didn't find a definitive answer on how to populate the daughter board.
Are the i²C pull-ups ( R103-R104-R105-R106) mandatory if I add a PicoW ? If so what value should they be and what size to order ( 0402, 0603 ? )

Jacky_Hicks wrote on 2026-02-12, 18:13:

Hello, I just got a ZuluIDE v2 with the Audio+PicoShield v2.
I looked at the github, documentation and made a few searches, but I didn't find a definitive answer on how to populate the daughter board.
Are the i²C pull-ups ( R103-R104-R105-R106) mandatory if I add a PicoW ? If so what value should they be and what size to order ( 0402, 0603 ? )

Great question. I have my Pico populated on a V1 board with a V1 (I purchased mine quite literally only 1 month before they released the V2, otherwise I would have waited!!!) board, and the logging tells me that it isn't finding any I2C server, and it certainly isn't connecting to my wifi.

trumpetlicks wrote on 2026-02-13, 19:41:

Jacky_Hicks wrote on 2026-02-12, 18:13:

Hello, I just got a ZuluIDE v2 with the Audio+PicoShield v2.
I looked at the github, documentation and made a few searches, but I didn't find a definitive answer on how to populate the daughter board.
Are the i²C pull-ups ( R103-R104-R105-R106) mandatory if I add a PicoW ? If so what value should they be and what size to order ( 0402, 0603 ? )

Great question. I have my Pico populated on a V1 board with a V1 (I purchased mine quite literally only 1 month before they released the V2, otherwise I would have waited!!!) board, and the logging tells me that it isn't finding any I2C server, and it certainly isn't connecting to my wifi.

I've got the V1 board populated with a Pico W and no pullups. You shouldn't need to populate the pullup footprints, but if for some reason it becomes necessary, they're 0603 and they would ordinarily be 10K pullup resistors. Also, if you look closely, two of the four footprints are for the I2C coming from the ZuluIDE, and the other two are for the second I2C channel on the Pico W. They're there primarily for daisy-chaining purposes for any other potential add-ons that might be designed so there's always a place to stick a device on the bus.

The documentation on how to solder down a Pico W to the shield board and flash the firmware to it can be found on the Rabbit Hole Computing wiki here.

Working on Serdaco version of ZuluIDE panel
this is the first iteration

Still wanting to change:
- shorter nicer encoder, probably with a 3d printed knob on it
- change panel design more ? - suggestions welcome

dreamblaster wrote on 2026-02-14, 10:24:

- shorter nicer encoder, probably with a 3d printed knob on it
- change panel design more ? - suggestions welcome

Larger LCD... there is a lot of empty real estate on that front panel.

Matchstick wrote on 2026-02-15, 01:54:

dreamblaster wrote on 2026-02-14, 10:24:

- shorter nicer encoder, probably with a 3d printed knob on it
- change panel design more ? - suggestions welcome

Larger LCD... there is a lot of empty real estate on that front panel.

We've talked about that. Believe me, it's been talked about repeatedly, and while I was working on the initial design of the carrier, I looked at several dozen options for larger displays because @aperezbios definitely wants that.

The issue is that the typically-available (and inexpensive) I2C screens are either the size you see, or literally just too large to fit properly in a 5.25" drive bay unless you have a way to secure the OLED glass to the front panel without breaking the glass or the flex PCB tail -- and even then, it's a REAL tight fit. There are sizes in the middle that can be bought easily, but they tend to be extremely expensive when compared to the typical sizes and also don't necessarily work out-of-the-box with the I/O libraries that the existing hardware interface code is compiled against.

While a custom solution could potentially pull this off, the cost to make that happen is ... well, prohibitive, to say the least.

Believe me, I want to see it be a reality, too, but until the inexpensive choices are available in a size in between the 0.96" displays or the larger 2.42" displays, we're kinda stuck.

Side note: Yes, I'm aware that there are 1.3" displays, but they use a different controller. I'm unsure as to whether they would function without a substantial amount of code rewriting, and it's also possible that it would bifurcate the codebase which makes things even more complicated to maintain.