Another day, another update.

As you might have already seen on GitHub, I’ve managed to implement mostly functional support for TNDLPT and CMSLPT. I was also able to fix the correct detection of TNDLPT mode (the README file will reflect this soon). Speaking of entering the "alpha 1" stage, I have (mostly) implemented all the devices I wanted, including their detection routines. The only thing missing is the reset signal for TNDLPT, which I am currently working on — it shouldn’t be too hard to implement (at least I hope).

There are two more things I want to complete before officially declaring the project in the alpha phase. First, I plan to design the PCB so that anyone can build their own device if they want. I already have a prototype and will soon order it; if it works, I will release it publicly. Second, I want to add support for software mode switching. As I have already suggested, I will use a combination of the AUTOFEED and SELIN pins (these are inverted, so I may need to incorporate another pin — presumably INIT, since this port is not inverted — to safely recognize whether the PC is powered on) along with the Data pins to determine the control sequence, such as switching between modes or setting the volume. I am already running tests with my trusty old Toshiba and will also test it on my other computers. I hope this feature will be available very soon.

Additionally, since I improved the sound quality on most devices (and added some new ones), I will probably make new test recordings soon. I hope the recordings I’ve already provided are at least somewhat useful and that you’re interested in hearing more. As I mentioned before, if you have any DOS games or software you would like to hear tested using my not-an-ideal test setup, just let me know here (or in DMs — I can’t respond to them directly since my rank is still Newbie, but I do read them, don’t worry).

To keep this message visible to everyone, I will not spam all the new information about Picovox to this thread. Instead, I will provide bigger update summaries. If you don’t want to miss any updates, be sure to watch my GitHub project page: https://github.com/picovox/picovox. As you can see, I created the Picovox organization to group together the firmware, hardware design, and DOS mode-switching program, without keeping everything in a single repository (thanks @digger again).

TL;DR:

• Alpha 1 progress: All devices implemented, detection routines work, PCB and software mode switching in progress.
• New sound recordings coming soon; if you want something tested, let me know.
• Keep track of the project: https://github.com/picovox/picovox

Thank you for the update, jansakos! Great progress, good to see the project moving forward. Having Covox and DSS support already makes this very appealing to me.

That said, how realistic would it be to add support for Digispeech? Do you have a unit available to reverse-engineer?

Bondi wrote on 2026-01-10, 06:48:

Thank you for the update, jansakos! Great progress, good to see the project moving forward. Having Covox and DSS support already makes this very appealing to me.

That said, how realistic would it be to add support for Digispeech? Do you have a unit available to reverse-engineer?

To be fair, apart from a DIY Covox clone, I don’t own any of these devices. As I mentioned earlier, I would like to support more devices in the future, but Digispeech will definitely not be part of alpha 1. This does not mean that I don’t want to support the device at all; it will simply have to wait until work on a later alpha version begins. At the same time, I’m not entirely sure how difficult the implementation would be, or whether the Pico 2 is even capable enough. However, once alpha 1 is released, I will look into it in more detail.

jansakos wrote on 2026-01-10, 10:50:

At the same time, I’m not entirely sure how difficult the implementation would be, or whether the Pico 2 is even capable enough. However, once alpha 1 is released, I will look into it in more detail.

Someone managed to port Doom to the RP2040 (Pico 1), with graphics, OPL2 emulation and 9 channels of stereo PCM, all while running the game at a good framerate.

Emulating a Digispeech (with OPL2 FM synthesis and a single 16-bit stereo PCM output channel) should be a lot less demanding than that, since there is not also graphics and a fully running game to consider.

So even an RP2040 should be able to emulate a Digispeech. Then it should definitely be feasible on an RP2350, which is quite more powerful than its predecessor.

It's the reverse-engineering part that will be the hardest to figure out, I believe. I don't think you need to emulate the exact hardware in the device. If the bitstream between a PC and an actual Digispeech device could be snooped and dumped while having the device perform certain actions, particularly FM synthesis and PCM sound playback, that could provide some clues on how to decode the protocol through which the driver interacts with the device over the parallel port.

But thinking about it more, the Digispeech devices aren't supported natively by any games. They work with a Sound Blaster emulation TSR or through a Windows driver. And as far as I know, that TSR only works with real mode games, since the challenge of emulating a Sound Blaster with support for both real mode and protected mode games wasn't solved until very recently with SBEMU and VSBHDA.

So instead of emulating a Digispeech device, perhaps implementing a custom Picovox mode that offers simultaneous playback of music and PCM samples would be the way to go. As long as a Sound Blaster emulation TSR for DOS could be developed for it, perhaps by adding support for it to SBEMU or VSBHDA, or by forking one of those projects. This new custom mode could perhaps even be superior to the Digispeech (OPL3 instead of OPL2, MIDI support in addition to FM synthesis, perhaps also 9-pin joystick/controller input support like with the FTL Sound Adapter, in addition to both music and PCM output, all at the same time).

By the way, someone in Sweden has already been selling a functionally somewhat similar (though more limited) device on Tindie: https://www.tindie.com/products/kdehl/covox-s … source-ftl-snd/

That device can be switched (through dip switches) between DSS mode, Covox mode and FTL mode, but the FTL mode only allows it to be detected as such. It does not include the 9-pin joystick port. Also it doesn't emulate OPL2LPT or OPL3LPT, and it also doesn't appear to be an open source design.

To be fair, the device sold on Tindie doesn't appear to be built around a microcontroller. So I guess it could never support software switching between emulation modes either.

https://dosreloaded.de/forum/thread/9082-lpt2 … r-den-lpt-port/

maybe you can support LPT2IDE, i gathered some files together on Dosreloaded.de
Basicly its the CPLD Code, the Schematic for discrete version, drivers for win9x and dos.

digger wrote on 2026-01-12, 00:31:

By the way, someone in Sweden has already been selling a functionally somewhat similar (though more limited) device on Tindie: https://www.tindie.com/products/kdehl/covox-s … source-ftl-snd/

That device can be switched (through dip switches) between DSS mode, Covox mode and FTL mode, but the FTL mode only allows it to be detected as such. It does not include the 9-pin joystick port. Also it doesn't emulate OPL2LPT or OPL3LPT, and it also doesn't appear to be an open source design.

To be fair, the device sold on Tindie doesn't appear to be built around a microcontroller. So I guess it could never support software switching between emulation modes either.

thats shock_ dss combined with a dac on one device, you can find the project here on vogons.

Reversing the Disney Sound Source

digger wrote on 2026-01-12, 00:16:

But thinking about it more, the Digispeech devices aren't supported natively by any games. They work with a Sound Blaster emulation TSR or through a Windows driver. And as far as I know, that TSR only works with real mode games, since the challenge of emulating a Sound Blaster with support for both real mode and protected mode games wasn't solved until very recently with SBEMU and VSBHDA.

Digispeech (one model at least) is supported via DIGPAK. DIGPAK is mostly compatible with AIL2 as well so there's quite a few games in there.

carlostex wrote on 2026-01-13, 04:33:

Digispeech (one model at least) is supported via DIGPAK. DIGPAK is mostly compatible with AIL2 as well so there's quite a few games in there.

Wasn't that the serial port Digispeech device, which is PCM only? Also, the DIGPAK driver for that Digispeech device is a foreground driver, which unfortunately makes it incompatible with most games that use DIGPAK or AILv2 drivers. Foreground drivers don't hook the timer interrupt and such, which is needed to be able to play sounds "in the background", i.e. concurrently with gameplay, without pausing the entire system whenever a digital sample is played back.

Or do you perhaps know of a DIGPAK (background) driver that works with the parallel port Digispeech devices (with both FM and PCM support)?

Otherwise, it might be better to just write a DIGPAK background driver that supports the Picovox in a more optimal custom mode instead.

All of this would still be less practical that integrating support for the Picovox as a physical output/backend device for SBEMU and/or VSBHDA.

Hi @jansakos. I hope you're doing well. 🙂

I know I was the one who initially suggested it, but thinking about it more, I don't believe it makes much sense to go through the effort to implement hardware-level Digispeech compatibility in the Picovox.

The reason for this is because there are no games or applications that access Digispeech devices natively. All the Digispeech parallel port devices (DS301A, DS311 and DS311A, I believe) require either a Windows driver or a Sound Blaster emulator in DOS to work. So either way, there is already some kind of hardware abstraction layer in place between the device and any games or applications that could make use of it.

So the (already quite complex) effort of reverse-engineering the bitstream between the driver and the device through the parallel port would only result in people being able to use the original Digispeech Windows driver and Sound Blaster emulator with the Picovox. Neither the driver nor the emulator from Digispeech are supported anymore, and we can probably forget about ever getting the source code for them. Also, I believe I remember reading somewhere that the Digispeech devices only supported OPL2, not OPL3. And on top of that, it's also highly unlikely that the Sound Blaster emulation TSR provided by Digispeech would support Protected Mode games. It probably worked only with Real Mode games, as most of such Sound Blaster emulators did back in the day.

It's probably easier to just design and implement a new native fully-featured OPL3+MIDI+DAC mode for the Picovox that would enable it to simultaneously output music and digital audio, ideally with support for game controller input at the same time, and to write new Windows drivers and a Sound Blaster emulator (based on something like SBEMU or VSBHDA) to optimally make use of that new mode instead.

And perhaps at some point we could then also try writing game-specific drivers for it, such as DIGPAK drivers, AIL/32 drivers, HMI drivers, Sierra drivers, etc. Such drivers were never developed for the Digispeech drivers to begin with, at least not as far as I know.

Does this make sense to you? Or do you see an added value in emulating the Digispeech devices at the hardware level that I missed somewhere?

Hi there! Really sorry for making you all wait. I had to finish my exams on time and was also reinstalling my workstation, so there wasn’t much time left for Picovox. However, I hope that now I should be able to progress a bit faster.

Speaking of the current progress: as you might have noticed on my GitHub (https://github.com/picovox/picovox), I haven’t posted anything for quite some time. The reason is (apart from the already mentioned time constraints) troubles with software-based mode switching. Unfortunately, I discovered that my laptop sets the pins on the LPT port in a non-standard way, which made it impossible to properly test my configuration. Now I not only have access to a better machine that I will use as my reference, but I will also create a simple tool for my laptop to set the pins correctly (this should be easy to do and hopefully finished fairly quickly).

All of these testing repositories are stored locally on my computer, since they don’t bring anything useful to the community. But don’t worry—some progress is being made.

To share my plans with you: right now, the biggest priority is to implement software switching. After that, I can design the PCB. Before I release the PCB to the public, however, I need to do some basic testing, especially with filtering capacitors (believe me, they are needed—especially for the noisy 3.3 V rail from the Pico). Once I finally have a working prototype, I will release all the required files so that you can build your Picovox without major issues. I hope it will be worth the wait. When this is taken care of, we can finally move on to the alpha phase.

digger wrote on 2026-02-04, 15:34:

I know I was the one who initially suggested it, but thinking about it more, I don't believe it makes much sense to go through the effort to implement hardware-level Digispeech compatibility in the Picovox.

I don’t necessarily think that emulating such a device is completely useless; however, it’s not that important right now, so we can leave it as an idea for later. I also agree that some custom mode for the best sound support (combined DAC and OPL2/3) would probably see more use. Before designing something like that, though, I need to study the capabilities in more detail.

Focusing solely on sound devices, I think that something like SIDLPT would be possible. The Pico is powerful enough for SID chip emulation. Maybe we could even develop a driver for games that supported the Innovation SSI-2001 in the future. I was able to find a device that accomplishes this, called parasid. Sadly, its pinout is not compatible with our software mode switching. Still, I believe that the following pinout might be possible and hopefully functional:

D0–D7 — D0–D7 (in data mode)
CS — Strobe (data ready)
A0–A4, RW, RES — D0–D6 (in address mode)
INIT — switch between data and address mode

I’m not really sure whether this is enough to simulate the device, or whether this approach is even valid, but I do believe that with some tweaking we can make it work. If there is any SID chip expert here, I would be grateful for corrections to my mistakes.

Once again, all of these additional sound devices (and even non-sound ones like the printer simulator) are not a current priority, so they will not be part of alpha 1. Still, I think that a sound device like this would be nice to have.

digger wrote on 2026-02-04, 15:34:

Hi @jansakos. I hope you're doing well. :slight_smile: […]
Show full quote

Hi @jansakos. I hope you're doing well. 🙂

I know I was the one who initially suggested it, but thinking about it more, I don't believe it makes much sense to go through the effort to implement hardware-level Digispeech compatibility in the Picovox.

The reason for this is because there are no games or applications that access Digispeech devices natively. All the Digispeech parallel port devices (DS301A, DS311 and DS311A, I believe) require either a Windows driver or a Sound Blaster emulator in DOS to work. So either way, there is already some kind of hardware abstraction layer in place between the device and any games or applications that could make use of it.

So the (already quite complex) effort of reverse-engineering the bitstream between the driver and the device through the parallel port would only result in people being able to use the original Digispeech Windows driver and Sound Blaster emulator with the Picovox. Neither the driver nor the emulator from Digispeech are supported anymore, and we can probably forget about ever getting the source code for them. Also, I believe I remember reading somewhere that the Digispeech devices only supported OPL2, not OPL3. And on top of that, it's also highly unlikely that the Sound Blaster emulation TSR provided by Digispeech would support Protected Mode games. It probably worked only with Real Mode games, as most of such Sound Blaster emulators did back in the day.

It's probably easier to just design and implement a new native fully-featured OPL3+MIDI+DAC mode for the Picovox that would enable it to simultaneously output music and digital audio, ideally with support for game controller input at the same time, and to write new Windows drivers and a Sound Blaster emulator (based on something like SBEMU or VSBHDA) to optimally make use of that new mode instead.

And perhaps at some point we could then also try writing game-specific drivers for it, such as DIGPAK drivers, AIL/32 drivers, HMI drivers, Sierra drivers, etc. Such drivers were never developed for the Digispeech drivers to begin with, at least not as far as I know.

Does this make sense to you? Or do you see an added value in emulating the Digispeech devices at the hardware level that I missed somewhere?

It may be the case that Digispeech has more or less standard Sound Blasted DSP onboard. Which would only require the newly made device get detected as a Digispeech. If that’s indeed the case stock drivers + pico emulated sb dsp should work.

I played around with sidlpt/parasid, the software support is somehow limited.
Vice did not even recognize it without "tricks" and there is not really other software supporting it.
Also tried to use it on modern vice, but there is already decent emu so who needs to run a emulator on a usb/lpt port for vice.

But one could do SSI-2001 Support, peter de waechters adlipt driver would be not hard to modifiy to output the data to picovox.

digger wrote on 2026-01-12, 00:31:

By the way, someone in Sweden has already been selling a functionally somewhat similar (though more limited) device on Tindie: https://www.tindie.com/products/kdehl/covox-s … source-ftl-snd/

That device can be switched (through dip switches) between DSS mode, Covox mode and FTL mode, but the FTL mode only allows it to be detected as such. It does not include the 9-pin joystick port. Also it doesn't emulate OPL2LPT or OPL3LPT, and it also doesn't appear to be an open source design.

To be fair, the device sold on Tindie doesn't appear to be built around a microcontroller. So I guess it could never support software switching between emulation modes either.

Thank you for your message. I have already found this device, and although it shares some similarities with Picovox, I believe they have completely different goals. While the replica is based on discrete chips and, in my opinion, the sound is quite accurate, it lacks any meaningful expandability and is also somewhat expensive.

On the other hand, despite several drawbacks of Picovox (mainly related to emulation quality), I believe it can be expanded much more easily, and the final cost can also be lower, especially if you build the device yourself.

Additionally, Picovox should not be limited to sound output. As I mentioned earlier, I would like to implement many more modes, such as some form of mass storage, printer emulation, or even a Wi-Fi interface. I am trying to make the device as versatile as possible—otherwise I would not connect a bidirectional LLC to the data pins.

Regarding software-based mode switching, that would also be possible on such a device.

digger wrote on 2026-01-12, 00:16:

Someone managed to port Doom to the RP2040 (Pico 1), with graphics, OPL2 emulation and 9 channels of stereo PCM, all while runni […]
Show full quote

jansakos wrote on 2026-01-10, 10:50:

At the same time, I’m not entirely sure how difficult the implementation would be, or whether the Pico 2 is even capable enough. However, once alpha 1 is released, I will look into it in more detail.

Someone managed to port Doom to the RP2040 (Pico 1), with graphics, OPL2 emulation and 9 channels of stereo PCM, all while running the game at a good framerate.

Emulating a Digispeech (with OPL2 FM synthesis and a single 16-bit stereo PCM output channel) should be a lot less demanding than that, since there is not also graphics and a fully running game to consider.

So even an RP2040 should be able to emulate a Digispeech. Then it should definitely be feasible on an RP2350, which is quite more powerful than its predecessor.

It's the reverse-engineering part that will be the hardest to figure out, I believe. I don't think you need to emulate the exact hardware in the device. If the bitstream between a PC and an actual Digispeech device could be snooped and dumped while having the device perform certain actions, particularly FM synthesis and PCM sound playback, that could provide some clues on how to decode the protocol through which the driver interacts with the device over the parallel port.

But thinking about it more, the Digispeech devices aren't supported natively by any games. They work with a Sound Blaster emulation TSR or through a Windows driver. And as far as I know, that TSR only works with real mode games, since the challenge of emulating a Sound Blaster with support for both real mode and protected mode games wasn't solved until very recently with SBEMU and VSBHDA.

So instead of emulating a Digispeech device, perhaps implementing a custom Picovox mode that offers simultaneous playback of music and PCM samples would be the way to go. As long as a Sound Blaster emulation TSR for DOS could be developed for it, perhaps by adding support for it to SBEMU or VSBHDA, or by forking one of those projects. This new custom mode could perhaps even be superior to the Digispeech (OPL3 instead of OPL2, MIDI support in addition to FM synthesis, perhaps also 9-pin joystick/controller input support like with the FTL Sound Adapter, in addition to both music and PCM output, all at the same time).

Regarding your post, I agree that the RP2350 should be more than capable of running such an emulator. At the same time, as you mentioned, reverse engineering would likely take a significant amount of time, especially since I do not own the device.

Another challenge is my limited programming experience. For example, the DOOM port you linked is an impressive piece of work created and optimized by someone with a deep understanding of the architecture. That is also why its OPL2 emulation is used in PicoGUS, and therefore in Picovox as well.

I am not saying it is impossible—I believe it can be done—but I am not entirely sure whether I currently have the skills needed to complete such a task.

As for a custom mode, I do think it should be feasible. However, it is similar to Digispeech support: I would like to look into it later, but right now my main priorities are PCB design and software-based mode switching. Once these are resolved and implemented, I can focus on additional features.

If my previous messages sounded harsh or negative, I sincerely apologize—that was not my intention. I truly appreciate the information and suggestions you have shared.

matze79 wrote on 2026-02-22, 13:17:

I played around with sidlpt/parasid, the software support is somehow limited. Vice did not even recognize it without "tricks" an […]
Show full quote

I played around with sidlpt/parasid, the software support is somehow limited.
Vice did not even recognize it without "tricks" and there is not really other software supporting it.
Also tried to use it on modern vice, but there is already decent emu so who needs to run a emulator on a usb/lpt port for vice.

The attachment shit.jpg is no longer available

The attachment sid_emu.jpg is no longer available

But one could do SSI-2001 Support, peter de waechters adlipt driver would be not hard to modifiy to output the data to picovox.

I have examined this device before. While I would prefer to base my design on an existing solution, its LPT pinout does not allow reasonable mode switching or sufficient control from the host computer. Therefore, I decided to abandon Parasid compatibility and implement my own pinout, particularly since Parasid never received significant support. I hope my design will eventually have both an SSI-2001 driver and a native SID chip player.

jansakos wrote on 2026-02-22, 14:59:

If my previous messages sounded harsh or negative, I sincerely apologize—that was not my intention. I truly appreciate the information and suggestions you have shared.

Don't worry, you didn't come across like that at all. 🙂

Since this is a software-defined device, the best way to go would indeed be to offload the complexity to the host software side as much as possible, so as to keep the hardware design both a simple and as flexible as possible.

I completely agree with you that getting the primarily targeted devices (Covox, DSS, etc) emulated in a complete, fully compatible, reliable and high-quality way is the highest priority.

Beyond that, I'm just not sure if it's worth going the whole Digispeech reverse-engineering route, as opposed to just defining a simple protocol that allows multiplexing of digital audio and music (OPL2 and/or MIDI) output to the device concurrently, and then writing host-side drivers and emulators to take advantage of that.

But let's cross that bridge when we get there. 😅

The safest approach would probably be to aim for SSI-2001 compatibility. If it handles CE Logic properly, we could simply output the data to the device using a modified AdLib TSR.

I previously experimented with implementing parts of the Innovation SSI-2001 on an LPT plug. However, I never finalized the design. The main limitation is that only around 15 games support the SSI-2001. There are also some drivers available for systems like the Miles Sound System.

Most games that support the SSI-2001 are also compatible with other sound standards, so the effort might not be justified. As far as I know, there aren’t any titles that are exclusively SSI-2001-only.

matze79 wrote on 2026-02-23, 16:35:

Most games that support the SSI-2001 are also compatible with other sound standards, so the effort might not be justified. As far as I know, there aren’t any titles that are exclusively SSI-2001-only.

Well, SSI-2001 is THE BEST sound option for classics like 1987 version of Pirates! and Gunship. These also support Tandy 3 Voice, but i never managed to patch them due to how they are tied to the video. In fact, even against Tandy, the SSI-2001 will sound better from what i could compare.

I personally think the SSI-2001 is probably better done and more useful on an ISA device but would be cool nonetheless.