dr.zeissler wrote on 2025-11-23, 07:51:

That would be the ultimate sound solution for my PS/2E and you can put me on the first buyers list if this comes out. Thx!

Thank you. Not sure if the device will be for sale anywhere (at least not by me), but all the required files will be publicly available, meaning that anyone would be able to build it and I would not hesitate to have the device available through a store (if they contact me).
Anyway, really cool machine, it would make me happy to see it upgraded with this device.

DarcTangent wrote on 2025-11-22, 23:24:

Wow, awesome project! I'd love to see ESS AudioDrive support for ESFM capability in Windows like the Micro Solutions backpack LPT CD-ROM drives. It would be incredible to add DOS support like the OPLxLPT family for the ESS chips (DOS TSR). CD-ROM emulation would be cool too. I look forward to seeing how this project grows. Cheers!

We'll see what will be possible for this device. As I have already mentioned, it is in its early stages of development, therefore I cannot guarantee anything as of now. The main goal is to implement sound devices mentioned in the original post. Then we can try to build on top of it.

digger wrote on 2025-11-22, 07:56:

Thanks for the update!

As with any newly designed product, you will likely be able to iteratively improve the design in later revisions.

Glad you found a possible combination to allow for software-controlled mode-switching. Having a batch file for each game to set the ideal mode will be much more convenient than having to manually toggle between modes with a button on the device, depending on what game you want to play or what application you want to run.

Yes, after some thinking I came up with another enhancement. Since the data lines on LPT port should preferably be bidirectional for better support of other devices (such as some sort of WiFi adapter, storage device etc.), I consider using three different chips for LLC, apart from the ones already mentioned, also the SN74LVC8T245 which is bidirectional and would suit the project really well. The main problem is that this chip is not sold (at least as far as I know) in a DIP package; therefore, I need to design PCB with SMD components in mind. So DIY assembly won’t be as easy as I had hoped.

Nice,

That is something I wanted to do if I had more time (and not the PicoMEM/PicoCPC/Other project in progress 😀

With a MicroSD, you can even plan for ZIP drive, Parallel port Wifi, MIDI ? support.

FreddyV wrote on 2025-11-25, 17:10:

Nice,

That is something I wanted to do if I had more time (and not the PicoMEM/PicoCPC/Other project in progress 😀

Hmmm... "Other project"? Curious to learn more about that, once you have something to reveal about it. 😁

With a MicroSD, you can even plan for ZIP drive, Parallel port Wifi, MIDI ? support.

All cool ideas, although MIDI is probably better handled through the serial port with something like the MPU-232, right? That has the added advantage of MIDI and digital working side by side in an easy way, with music over serial and PCM through the parallel port.

Perhaps at some point in the future, a later revision of this device could be improved so that it plugs into both a parallel port and a serial port (and optionally perhaps the PS/2 mouse/keyboard port available on many laptops as well), and then allowing it to support a lot more stuff for older laptops and PS/2 computers, such as USB keyboard and mice, USB joysticks and game controllers, MIDI over serial, plus all the parallel port devices it can emulate.

But maybe that's best to do in a separate project to prevent scope creep.

MIDI on LPT is actually possible.

My PCB based on eigenco's LPT2MIDI.

https://github.com/eigenco/LPT2MIDI

but this design still had some issues, like missing notes
i bet this is because the port is split and arduino code is not optimal.

matze79 wrote on 2025-11-26, 09:35:

MIDI on LPT is actually possible.

I'm aware that it's possible. I know of such projects.

It just makes more sense to me to do MIDI over serial, so the parallel port stays free for PCM output.

With very few exceptions (such as certain Tandy 1000 models), pretty much any non-ISA PC or laptop that has a parallel port also has a serial port anyway.

From what I've understood, the MIDI interface is basically a serial interface already, just with a bit rate that PC serial ports don't support. And devices such as the MPU-232 offer solutions for that.

But yeah, I have no objections to adding MIDI functionality to the Picovox over the parallel port. The more flexibility, the better, of course. 🙂

I guess it might be useful when the serial port is already in use for something else, such as a serial mouse.

FreddyV wrote on 2025-11-25, 17:10:

Nice,

That is something I wanted to do if I had more time (and not the PicoMEM/PicoCPC/Other project in progress 😀

With a MicroSD, you can even plan for ZIP drive, Parallel port Wifi, MIDI ? support.

Not really sure about the MIDI support, I don't think that even Pico 2 is powerful enough for any meaningful MIDI sound production. It would totally be possible to add a MIDI output port but the question is whether that is really needed since you can do it via serial port. But LPT WiFi and some mass-storage media (whether ZIP drive or something else) were on my mind for quite some time already. Also, adding an SD-card reader would make it possible to store and easily modify some configuration, such as the default simulated device, volume levels and even stored WiFi credentials. All these ideas I had already been thinking about were also the reason I decided to use a bidirectional LLC instead of a unidirectional one.

digger wrote on 2025-11-26, 09:04:

Hmmm... "Other project"? Curious to learn more about that, once you have something to reveal about it. :grin: […]
Show full quote

FreddyV wrote on 2025-11-25, 17:10:

Nice,

That is something I wanted to do if I had more time (and not the PicoMEM/PicoCPC/Other project in progress 😀

Hmmm... "Other project"? Curious to learn more about that, once you have something to reveal about it. 😁

With a MicroSD, you can even plan for ZIP drive, Parallel port Wifi, MIDI ? support.

All cool ideas, although MIDI is probably better handled through the serial port with something like the MPU-232, right? That has the added advantage of MIDI and digital working side by side in an easy way, with music over serial and PCM through the parallel port.

Perhaps at some point in the future, a later revision of this device could be improved so that it plugs into both a parallel port and a serial port (and optionally perhaps the PS/2 mouse/keyboard port available on many laptops as well), and then allowing it to support a lot more stuff for older laptops and PS/2 computers, such as USB keyboard and mice, USB joysticks and game controllers, MIDI over serial, plus all the parallel port devices it can emulate.

But maybe that's best to do in a separate project to prevent scope creep.

Pretty much sums up all my thoughts. Extension of the project for multiple ports seems a bit far-fetched. I don't think that one device should occupy all your ports, especially if their function would be almost completely unrelated. Probably the only good reason for this approach would be to power the device from PS/2's 5V supply instead of an external microUSB power brick (still I would like to add two holes for a jumper where you can provide any 5V input). I think that it is totally reasonable to make another device connecting Pico to the COM port and adding support for different standards there.

digger wrote on 2025-11-26, 09:58:

I'm aware that it's possible. I know of such projects. […]
Show full quote

matze79 wrote on 2025-11-26, 09:35:

MIDI on LPT is actually possible.

I'm aware that it's possible. I know of such projects.

It just makes more sense to me to do MIDI over serial, so the parallel port stays free for PCM output.

With very few exceptions (such as certain Tandy 1000 models), pretty much any non-ISA PC or laptop that has a parallel port also has a serial port anyway.

From what I've understood, the MIDI interface is basically a serial interface already, just with a bit rate that PC serial ports don't support. And devices such as the MPU-232 offer solutions for that.

But yeah, I have no objections to adding MIDI functionality to the Picovox over the parallel port. The more flexibility, the better, of course. 🙂

I guess it might be useful when the serial port is already in use for something else, such as a serial mouse.

Yeah most Laptops only have one, so you have to decide.
That was my reason also for LPT MIDI Adapter.

If this really gets into shape, it would be nice to make a all in one tsr with some sort of communication do get the plug auto switch the devicetype maybe by issue a command from cmd.

Any news on this project? Do you need some help testing, @jansakos?

I can try soldering one together based on your initially shared designs, if that helps.

Anybody else here willing to contribute to the project as well? Thanks.

It’s not so much about testing right now, the main problem is that there isn’t enough time for the project itself. But don't worry, it's not abandoned, I am running some tests with improved filtering of the 3.3 V rail and also some sketches for the PCB. Here’s a quick overview: I have decided to go with three different chips for LLC, one for 3.3V -> 5V, one for 5V -> 3.3V and one for 3.3V <-> 5V (switchable). With this approach the device shall be able to simulate both SPP and PS/2 mode (bi-directional), and possibly additional advanced modes for higher speeds. Also, I have decided to connect each pin of the LPT to the Pico so that you aren’t limited and can use every pin. I will try to order the first prototype of the PCB and if it all works (I hope it will), I will share all the files for the PCB itself. As for the source code, it works reasonably well at the moment (the same version I provided in my earlier post), but I want to add TNDLPT and CMSLPT support and clean up the code before releasing it publicly. You are free to build the provided prototype, but I am experiencing trouble with noise and I hope I have found a solution to that.

@jansakos Hackaday published an article yesterday about level-shifting.

It mentions verious approaches, and also links to a YouTube video.

Could some of that be useful for this project, maybe? 🙂

To give you all a quick update, I was busy, so I really did not progress that far. Thank you for sending me the article; after reading through it, I have ensured that my approach with LLC chips is probably the best for the device since I need all the signals of the LPT port to be shifted (that is 17 pins, I don’t think that an individual MOSFET approach would end up cheaper). A voltage divider might be cheaper, but since we also need multiple pins to be stepped up (I don’t want to limit usability by sending 3.3V to a 5V LPT port; some devices might have trouble with detection), and especially since in bidirectional mode (which I want to implement in order to not cause any major limitations with modem emulation, etc.) I would need to switch them somehow. Sadly, I will probably design the device to use SMD components instead of DIP, but I will at least try to use types solderable by hand.

To give a quick insight of what I am up to, I will test a redesign of the device on several of my computers, and if the buzzing is (at least mostly) resolved, I will make the final PCB design based upon it and share it publicly. Right now, I am working on adding support for TNDLPT and CMSLPT. I hope I have managed to overcome the most difficult parts (by which I mean dealing with C++ code, ugh), so that I can finally release the source code for everyone to use freely.

TL;DR: The project is not abandoned, although much progress has not been done yet. Stay tuned.

Thanks for the update, @jansakos, and Happy New Year! 🌟

As for your struggles and annoyances with C++, have you considered coding the firmware in Rust instead? 🦀

digger wrote on 2026-01-02, 04:58:

Thanks for the update, @jansakos, and Happy New Year! 🌟

As for your struggles and annoyances with C++, have you considered coding the firmware in Rust instead? 🦀

The problem is not my part of code (it is written in pure C thankfully), but some libraries that are written in C++. (Regarding Rust, it is a language that I would like to learn in the future, but I am not ready to write something bigger in it as of now.) Since I was fed up, I instead focused on some code cleanup and in the meantime changed Stereo-on-1 routine so that it works as expected (still working on it, but the main parts are already done).

Information regarding Stereo-On-1:
Up until now I have used fairly simple design, simply described as Covox + STROBE switching between right and left channel. I was not really sure why some software could not detect my device as Stereo-on-1 (since there was no possible detection) and I could not find much information regarding the proper design. That was until I read through the hardware.doc file of ModPlay Pro written by Mark J Cox. Not only is the design of the device itself described, but also provided is a sketch of the correct connection. To give you an idea: data pins (D0–D7) are shared between both right and left channels (unsurprisingly, otherwise my naive implementation would not work at all). Next up are STROBE and AUTOFEED pins. They serve as read pins! STROBE is low when you should latch the data pins for right channel and AUTOFEED is low when the data pins should be latched for left channel. Autodetection is done simply by connecting D7 with BUSY (a similar approach to the FTL sound adapter). I am not really sure if this has already been discussed somewhere, if so, you can safely ignore this little message 😀, if not, here you go.

I am also slowly working on the TNDLPT support (since I had to rewrite a significant portion of the codebase, it should be much easier now), then will come the CMSLPT support. Also, for all of you hungry for the PCB design and the option to build the device yourself, I am progressing on it slowly. I was finally able to (hopefully) get rid of the buzzing (or at least most of it) so I believe I am now ready to build the first PCB prototype. I have unfinished sketches for the PCB itself, I need to implement a few details and after I test that the PCB design is not totally flawed (it might be flawed, as this is my first time designing a PCB) I will release the files needed for it. In the meantime, I wish all the best. And in case you might be interested in hearing how the device sounds, I might upload something if you want.

Yes, please upload some samples here if you have time.

Thanks for your update and your continued work on this!

To give you some insight into the progress of the PiCovox, here are some audio tests. Everything (except for PC speaker noises in Wolfenstein 3D) is produced by the PiCovox device. I am mostly interested in the accuracy of the OPL2 emulation, please let me know how far from perfect it is (especially compared to PicoGUS), since I have nothing to compare it against.

Here is the current playlist of all the tests I have captured: https://www.youtube.com/playlist?list=PLtJDb9 … QN5QYUzFtO6zPUx

Please let me know if the videos are accessible and whether there is any other software you would like me to test.

jansakos wrote on 2026-01-04, 17:17:

To give you some insight into the progress of the PiCovox, here are some audio tests. Everything (except for PC speaker noises in Wolfenstein 3D) is produced by the PiCovox device. I am mostly interested in the accuracy of the OPL2 emulation, please let me know how far from perfect it is (especially compared to PicoGUS), since I have nothing to compare it against.

Here is the current playlist of all the tests I have captured: https://www.youtube.com/playlist?list=PLtJDb9 … QN5QYUzFtO6zPUx

Please let me know if the videos are accessible and whether there is any other software you would like me to test.

Small update regarding the footage provided above:
I fixed most of the crackling in the Covox/FTL sound adapter in the simplest way imaginable. I changed the sound generation routine to sample at 288 kHz instead of 96 kHz and take the median of the three values as the sample. It works well enough without degrading the sound (I don’t believe that this principle can make any audible difference at these sound rates). The crackling seems to be gone, and the sound is better now. So next up on my list of devices to fix is the Disney Sound Source, with its awful sound quality (sadly, the fix here will not be so simple).

jansakos wrote on 2026-01-05, 15:28:

jansakos wrote on 2026-01-04, 17:17:

Here is the current playlist of all the tests I have captured: https://www.youtube.com/playlist?list=PLtJDb9 … QN5QYUzFtO6zPUx

Small update regarding the footage provided above:
I fixed most of the crackling in the Covox/FTL sound adapter in the simplest way imaginable. I changed the sound generation routine to sample at 288 kHz instead of 96 kHz and take the median of the three values as the sample. It works well enough without degrading the sound (I don’t believe that this principle can make any audible difference at these sound rates). The crackling seems to be gone, and the sound is better now. So next up on my list of devices to fix is the Disney Sound Source, with its awful sound quality (sadly, the fix here will not be so simple).

Another quick update (I almost feel like I’m spamming right now): it seems I have mostly resolved the issues with the Disney Sound Source emulation. It still sounds horrible, but not necessarily much worse than the original. Buffer timing has not changed, so I hope there is no new issue with detection in games. If you wish, I might add recordings of the fixed Covox and DSS to the playlist.

No, dont't worry, that's not spam at all! 😃 It's 100% on-topic, and people here (myself included) are following your work and progress with great interest.

Thanks for continuing to share this!

I’ve released the source code along with some information in the README file on GitHub. Please do not send any pull requests yet; I will specify clearly how contributions can be made in the future (probably alpha 1). The code is currently under heavy development, and I’m slowly making it more readable. Thank you for your patience.

GitHub link: https://github.com/jansakos/picovox/

Whoohoo! 🥳 Awesome to see your project appear on GitHub. Thanks!