red_avatar wrote on 2025-01-23, 18:46:

SimonC wrote on 2025-01-23, 15:27:

Is there a way to buy the DAC for EU costumers ?

Redbook audio is the number one feature for me, untfortunately the DAC can only be purchased on the rabbit hole wesite at the moment.

I bought it with the DAC - you need to search for it:

https://studio-services.de/en/produkt/zuluide … -shield-bundle/

Thank you

Will there be a mounting frame / front panel as for the ZuluSCSI?
Both variants 5.25" and 3.5" would be nice.

crusher wrote on 2025-01-24, 07:37:

Will there be a mounting frame / front panel as for the ZuluSCSI?
Both variants 5.25" and 3.5" would be nice.

I could probably 3D design something but the PC I intend to use it for has no spare bays sadly enough - I'll need to receive more info about how Pico works to swap images.

red_avatar wrote on 2025-01-23, 19:20:

OK I have been properly reading up on it but I can't seem to find ANY info on how image swapping works in a DOS machine. I've gathered that I can use the DAC shield to attach a Pico but even that is incredibly vague - just that it uses a different firmware but no further info, no info on how to connect to the pico (I assume it gets an IP and then you go to its IP in a browser?). It would be nice for you to add this info somewhere. Or of course, a DOS utility that let's you swap images would be even better - a competing device has this ability.

Basically, can you give some more info? I'm sure a lot of other people will want to know this as well.

Yeah, this is something that's been in the hopper for quite a bit and is currently only doable on-the-fly either with the web interface (using a second Pi Pico W) or using the hardware interface. We want to have some kind of DOS utility (kind of like the PicoMEM has) that allows for the use of a keystroke to swap images, but managing to communicate that information back up the IDE bus has proved somewhat more challenging.

I'll work on putting that information up here on the wiki for the ZuluIDE this afternoon.

crusher wrote on 2025-01-24, 07:37:

Will there be a mounting frame / front panel as for the ZuluSCSI?
Both variants 5.25" and 3.5" would be nice.

The board, as of right now, comes in a small carrier designed to attach it to a 2.5" hard drive mounting slot. If you have a 2.5"-to-3.5" adapter frame, it will mount in there easily.

5.25" drive bay mounts are also being tossed around, and in amongst the other things I'm working on, I'm searching for specifications on 5.25" drive bays so I can come up with a 3D-printed model we can mount the board to that fits properly in things.

red_avatar wrote on 2025-01-23, 18:46:

SimonC wrote on 2025-01-23, 15:27:

Is there a way to buy the DAC for EU costumers ?

Redbook audio is the number one feature for me, untfortunately the DAC can only be purchased on the rabbit hole wesite at the moment.

I bought it with the DAC - you need to search for it:

https://studio-services.de/en/produkt/zuluide … -shield-bundle/

Thanks, ordered one for testing.
Do someone one how can I get "DIY guide" for gotek like front panel ?
Regards

red_avatar wrote on 2025-01-23, 19:20:

Basically, can you give some more info? I'm sure a lot of other people will want to know this as well.

If you're using the web interface to control the device, I've added that information to the Rabbit Hole Computing wiki here.

most interesting !!

dzeq_pl wrote on 2025-01-25, 22:19:

Thanks, ordered one for testing. Do someone one how can I get "DIY guide" for gotek like front panel ? Regards […]
Show full quote

red_avatar wrote on 2025-01-23, 18:46:

SimonC wrote on 2025-01-23, 15:27:

Is there a way to buy the DAC for EU costumers ?

Redbook audio is the number one feature for me, untfortunately the DAC can only be purchased on the rabbit hole wesite at the moment.

I bought it with the DAC - you need to search for it:

https://studio-services.de/en/produkt/zuluide … -shield-bundle/

Thanks, ordered one for testing.
Do someone one how can I get "DIY guide" for gotek like front panel ?
Regards

The control panel project is here - https://github.com/rabbitholecomputing/Zulu-C … ntrol-Board-i2c

Lostdotfish wrote on 2025-01-27, 10:13:

The control panel project is here - https://github.com/rabbitholecomputing/Zulu-C … ntrol-Board-i2c

Yep, there it is - you posted it before I got around to it.

Just be aware that while the hardware interface is entirely functional as it exists, what's in that repo might not look like or even function similarly to the form the interface takes when it reaches release status. It's been reworked about three times before the version that's in that repo, and it's entirely possible that it'll get reworked again.

That said, suggestions on its function are absolutely welcome, and if you discover issues with it, please let us know.

The hardware interface, when assembled, is a board separate to the ZuluIDE and is attached directly to it via a Qwiic cable.

When assembling it, you only need to populate J6 (the Qwiic connector on the same side as the rotary encoder). J7 is there as a passthru for future I2C use if needed.

mbalmer wrote on 2025-01-27, 20:26:

Yep, there it is - you posted it before I got around to it. […]
Show full quote

Lostdotfish wrote on 2025-01-27, 10:13:

The control panel project is here - https://github.com/rabbitholecomputing/Zulu-C … ntrol-Board-i2c

Yep, there it is - you posted it before I got around to it.

Just be aware that while the hardware interface is entirely functional as it exists, what's in that repo might not look like or even function similarly to the form the interface takes when it reaches release status. It's been reworked about three times before the version that's in that repo, and it's entirely possible that it'll get reworked again.

That said, suggestions on its function are absolutely welcome, and if you discover issues with it, please let us know.

The hardware interface, when assembled, is a board separate to the ZuluIDE and is attached directly to it via a Qwiic cable.

When assembling it, you only need to populate J6 (the Qwiic connector on the same side as the rotary encoder). J7 is there as a passthru for future I2C use if needed.

As soon as this is a complete, bay mountable product, I'm all in.

Awesome to watch the development of this but it needs to consolidate into a single product with the DAC and control surface in a 3.5 or 5.25 bay form factor, with the SD card accessible from the front.

KVM Nerd wrote on 2025-01-20, 18:46:

Nice, this project looks very promising! […]
Show full quote

Nice, this project looks very promising!

However, it still lacks some features which are essential for my use case:

• Support for mounting network based images from a server (simple workaround: USB storage instead of SD card to mount images via a Raspi connected to the network, emulating USB mass storage)
• Wired and thus robust management interface for automation (the Pico W is still wireless) with some simple telnet-like command set
• (S/PDIF TTL-level out, more nice-to-have, but it somehow feels wrong when it lacks)

If it had those features, it would outrun all available solutions. Just my personal opinion, most users seem to have different requirements.

So, I had a chat with the developers over these three points, and here's what we came away with after investigating what it would take to add these things:

Network-based storage for images is currently not practical, given the limitations of the microcontroller. Additionally, the memory requirements to implement such a feature and the costs involved in redesigning the board to accommodate it would very quickly make it financially impractical to pursue, and even if we were to do it, it would inflate the end-user cost of the device to levels that place it firmly outside of the realm we're trying to stay within (the hobbyist/retrocomputing lover realm).

Wired ethernet access also falls into that same camp at the moment; the additional support components alone would rather dramatically inflate the cost of the device. Because we're pushing the existing hardware as hard as we are to get it to communicate at the speeds necessary for the IDE bus to function, we don't have a lot of room left to add other things -- which is why the existing HTTP-based interface requires an additional Pico W.

S/PDIF out is something that, on the surface, seemed trivial, but after looking, it's not as trivial as it first appeared. It would either need the microcontroller itself to generate S/PDIF signals on its own or it would need a separate I2S-to-S/PDIF circuit added, which again, increases cost.

As some others in the thread have already noted, the cost is already on the higher side, and we feel that the cost tradeoff doesn't really make it worth it to add at the moment. Nothing is being ruled out, but it would take seeing something come available that integrates some of the things you asked about natively without dramatically increasing costs to make it happen. If you happen to know of things that would make implementing these features easier, please feel free to reach out, but with what we've worked with so far, it's not really doable without a substantial product redesign along with greatly increased end-user cost.

Lostdotfish wrote on 2025-01-29, 19:18:

As soon as this is a complete, bay mountable product, I'm all in.

Awesome to watch the development of this but it needs to consolidate into a single product with the DAC and control surface in a 3.5 or 5.25 bay form factor, with the SD card accessible from the front.

You can help!

If someone can point me in the direction of the standard dimensional specifications for 5.25" and 3.5" drive bay form factors, I can start working on a 3d-printed mounting bracket that integrates the control surface and board together, sliding the SD card up against the edge so it peeks through a faceplate. The DAC add-on is meant to be plugged into the CD audio input on a sound card, so it wasn't really conceived with a front panel jack in mind.

A 3.5" drive bay might be a little difficult with the boards at the sizes they currently are, but a 5.25" bay should be relatively straight-forward with the existing board footprints as a quick stop-gap.

mbalmer wrote on 2025-01-29, 22:33:

You can help! […]
Show full quote

Lostdotfish wrote on 2025-01-29, 19:18:

As soon as this is a complete, bay mountable product, I'm all in.

Awesome to watch the development of this but it needs to consolidate into a single product with the DAC and control surface in a 3.5 or 5.25 bay form factor, with the SD card accessible from the front.

You can help!

If someone can point me in the direction of the standard dimensional specifications for 5.25" and 3.5" drive bay form factors, I can start working on a 3d-printed mounting bracket that integrates the control surface and board together, sliding the SD card up against the edge so it peeks through a faceplate. The DAC add-on is meant to be plugged into the CD audio input on a sound card, so it wasn't really conceived with a front panel jack in mind.

A 3.5" drive bay might be a little difficult with the boards at the sizes they currently are, but a 5.25" bay should be relatively straight-forward with the existing board footprints as a quick stop-gap.

Just happened to have a NEC DVD/RW drive handy so have taken some measurements.

The drive faceplate (the bit that protrudes through the case) is

147mm x 42mm x 5mm

The drive dimensions where it mounts to the case rails are as follows;

146mm x 41mm

There are 2 pairs of mounting holes that are M2.5 (I believe but might be worth checking this)

Vertically the pairs are spaced 12mm apart centre to centre

Horizontally the 2 pairs are 79mm apart (c2c)

The top hole is 19mm from the top edge of the drive (edge to hole centre)

The first pair of holes are 52.5mm from the very front of the drive.

Total drive length should not matter for this application as long as you have enough length to fit the mounting holes in. I've attached a photo to try and clarify the mounting hole spacing.

mbalmer wrote on 2025-01-29, 22:33:

You can help!

If someone can point me in the direction of the standard dimensional specifications for 5.25" and 3.5" drive bay form factors, I can start working on a 3d-printed mounting bracket that integrates the control surface and board together, sliding the SD card up against the edge so it peeks through a faceplate. The DAC add-on is meant to be plugged into the CD audio input on a sound card, so it wasn't really conceived with a front panel jack in mind.

A 3.5" drive bay might be a little difficult with the boards at the sizes they currently are, but a 5.25" bay should be relatively straight-forward with the existing board footprints as a quick stop-gap.

How much space on a 5 1/4" face plate does the display and controls take up? I'm wondering if it's possible to fit two screens, and an additional encoder wheel. Then a ZuluIDE and WP32 McCake could share a single slot.

I'm not sure on other's use cases, but I'd want this on a PC that uses DOS, which still puts it into the MT32 era. Once Windows is in the picture, CD software emulators there seem fine.

mbalmer wrote on 2025-01-29, 22:21:

KVM Nerd wrote on 2025-01-20, 18:46:

Nice, this project looks very promising! […]
Show full quote

Nice, this project looks very promising!

However, it still lacks some features which are essential for my use case:

• Support for mounting network based images from a server (simple workaround: USB storage instead of SD card to mount images via a Raspi connected to the network, emulating USB mass storage)
• Wired and thus robust management interface for automation (the Pico W is still wireless) with some simple telnet-like command set
• (S/PDIF TTL-level out, more nice-to-have, but it somehow feels wrong when it lacks)

If it had those features, it would outrun all available solutions. Just my personal opinion, most users seem to have different requirements.

mbalmer wrote on 2025-01-29, 22:21:

So, I had a chat with the developers over these three points, and here's what we came away with after investigating what it would take to add these things:

Thank you very much for the investigation!

mbalmer wrote on 2025-01-29, 22:21:

Network-based storage for images is currently not practical, given the limitations of the microcontroller. Additionally, the memory requirements to implement such a feature and the costs involved in redesigning the board to accommodate it would very quickly make it financially impractical to pursue, and even if we were to do it, it would inflate the end-user cost of the device to levels that place it firmly outside of the realm we're trying to stay within (the hobbyist/retrocomputing lover realm).

I totally understand it would blow the budget. But I was already suggesting a workaround: Using USB instead of SD card as the storage medium. This way a Raspberry Pi 4/5 could act as a network bridge by emulating a USB storage device which is connected to a server via network in the background. In other words, USB instead of SD card would make it network-based storage ready. Emulating an SD card would be much more difficult than USB which makes this no option. I know the RP2040 can act as a USB host with the pico-usb library, but I don't know if there are enough pins left to use it.

mbalmer wrote on 2025-01-29, 22:21:

Wired ethernet access also falls into that same camp at the moment; the additional support components alone would rather dramatically inflate the cost of the device. Because we're pushing the existing hardware as hard as we are to get it to communicate at the speeds necessary for the IDE bus to function, we don't have a lot of room left to add other things -- which is why the existing HTTP-based interface requires an additional Pico W.

Even the wired ethernet access could be managed with an easy workaround: Expose a serial port with some telnet-like protocol, and the device could be managed by it. If we already connected a Raspberry Pi for network-based storage, we could also easily additionally connect it via serial to the ZuluIDE for management purposes. This way it wouldn't have a polished web interface, but at least it could be managed via wired network and it would be possible to write a web server for the Raspberry Pi to do what the Pico W does now.

mbalmer wrote on 2025-01-29, 22:21:

S/PDIF out is something that, on the surface, seemed trivial, but after looking, it's not as trivial as it first appeared. It would either need the microcontroller itself to generate S/PDIF signals on its own or it would need a separate I2S-to-S/PDIF circuit added, which again, increases cost.

Yeah, S/PDIF would not justify such an increase in cost just to be there. But maybe it would be possible to expose some I2S pins to connect an external S/PDIF module for those who want to add it?

mbalmer wrote on 2025-01-29, 22:21:

As some others in the thread have already noted, the cost is already on the higher side, and we feel that the cost tradeoff doesn't really make it worth it to add at the moment. Nothing is being ruled out, but it would take seeing something come available that integrates some of the things you asked about natively without dramatically increasing costs to make it happen. If you happen to know of things that would make implementing these features easier, please feel free to reach out, but with what we've worked with so far, it's not really doable without a substantial product redesign along with greatly increased end-user cost.

I don't know what it would take to make the ZuluIDE wired network ready as I explained above, but I think it shouldn't blow the budget as much as it seemed first by making the device itself wire networked. It would be nice to have it that way for people who decide to invest more and "upgrade" it with a Raspberry Pi 4/5 and/or an S/PDIF module. I hope I could make clear what I am aiming at: Making it a bit more modular/expandable for those who want to use additional functions and are willing for extra investment then.

Received my zuluide with dac today, works like a charm in my windows 98 machine.

I have to admit that launching quake II and hearing the music put a big smile on my face 😀

The only downside for the moment is switching between image file, because you have to go through the whole list everytime.

The controller board seems really promising, can't wait for it to be available.

KVM Nerd wrote on 2025-01-30, 14:40:

I totally understand it would blow the budget. But I was already suggesting a workaround: Using USB instead of SD card as the storage medium. This way a Raspberry Pi 4/5 could act as a network bridge by emulating a USB storage device which is connected to a server via network in the background. In other words, USB instead of SD card would make it network-based storage ready. Emulating an SD card would be much more difficult than USB which makes this no option. I know the RP2040 can act as a USB host with the pico-usb library, but I don't know if there are enough pins left to use it.

This is a complete non-starter because the RP2040 does not have high-speed USB. The SDIO interface can transfer many megabytes per second, and a PIO-emulated/assisted secondary USB port still can not sustain USB 2.0 High Speed throughputs.

Making suggestions such as these without having a basic understanding of the limitations of the underlying microcontroller is not particularly constructive. I'm sure you mean well, but if it were as easy as what you're proposing, we'd have done it already. It's fine if you want this product to be something other than what it is, and there will always be room for improvement in the future. The RP2040 is great but it has relativelylimited high-speed I/O capabilities, which is why ZuluIDE absolutely had to incorporate a small FPGA for it to be able to achieve the timing requirements of Ultra DMA 0.

Hi,
I am testing it with no luck on Pentium MMX, Pentium III and Pentium 4 MB.
I think this is a problem in my case, end of log file:

[2001ms] ERROR: FPGA license check failed with status 0x00
[2002ms] Please contact customer support and provide this log file and proof of purchase.
[2003ms] -------------------------------------------------

Any one has contact to custommer support 😀?
Regards
Jacek

dzeq_pl wrote on 2025-02-01, 20:14:

Any one has contact to custommer support 😀?
Regards
Jacek

Jacek,

For future reference, the support e-mail address for zuluide is support@zuluide.com. I've responded to your e-mail, and will be happy to assist in getting this issue dealt with promptly.