Hey, jansakos! It’s a great idea to have all in one lpt port sound device. I’ll be looking forward to seeing the end result and building one for myself.

Very interested in this too. Would it be possible to add a PC-Speaker IN connector to it in order to have this output in better quality for the very early stuff.

Amazing! 🤩

Thanks for starting this project and opening a dedicated thread for it, @jansakos!

I'd be happy to help with testing, or working on the software-side of things. Perhaps some kind of DOS driver that can switch the Picovox into different emulation modes?

Also, at some point, maybe Sound Blaster emulation could be accomplished by extending or forking VSBHDA or SBEMU to support the Picovox as an output device.

Oh, and your English is fine, by the way!

digger wrote on 2025-11-19, 11:08:

Amazing! 🤩 […]
Show full quote

Amazing! 🤩

Thanks for starting this project and opening a dedicated thread for it, @jansakos!

I'd be happy to help with testing, or working on the software-side of things. Perhaps some kind of DOS driver that can switch the Picovox into different emulation modes?

Also, at some point, maybe Sound Blaster emulation could be accomplished by extending or forking VSBHDA or SBEMU to support the Picovox as an output device.

Oh, and your English is fine, by the way!

I would love to incorporate some sort of software switching, but I am not really sure how to do it since all the output pins are used by at least one device. To give you an idea, here are all the pins and their usage:

PC output pins:
Data pins 0–7: used by all the sound devices for data transmission
Strobe: Stereo-on-1 as a right/left switch, OPL2LPT and CMSLPT as A0 input, TNDLPT as CE
Autofeed: CMSLPT as CS for one chip
Init: OPL2LPT, CMSLPT and TNDLPT as WE
Selin: CMSLPT as CS for the other chip, TNDLPT as reset, DSS as a ready signal

PC input pins:
ACK: TNDLPT ready pin, DSS buffer full signal
Paper End: FTL for detection

As you can see, there is no spare PC output pin that could be used as a Picovox operation pin. I have a feeling that you can use some of the pins on the LPT port as inputs even if they are configured as outputs, but I am not sure whether this is supported on all machines (I think it's not). Please, in case you have any tips on how to accomplish that, I would really appreciate it.

dr.zeissler wrote on 2025-11-19, 10:16:

Very interested in this too. Would it be possible to add a PC-Speaker IN connector to it in order to have this output in better quality for the very early stuff.

I am not really sure if that would be of much use here since I don't know any standard of PC speaker output in laptops. If you could explain it more thoroughly, I would be happy to learn something new.

jansakos wrote on 2025-11-19, 12:31:

As you can see, there is no spare PC output pin that could be used as a Picovox operation pin. I have a feeling that you can use some of the pins on the LPT port as inputs even if they are configured as outputs, but I am not sure whether this is supported on all machines (I think it's not). Please, in case you have any tips on how to accomplish that, I would really appreciate it.

What if the software-switching (or software configuration) could be triggered by sending it a sequence of bit patterns? Something like port knocking or how you have to flip a light switch on and off in a certain rhythm to tell an IKEA smart LED bulb to connect to a Dirigera smart hub? So for instance, hold pins 1 and 2 high for x milliseconds, then pull them low and set a combination of pins differently for y milliseconds or until ACK changes by itself, etc.

Of course, it would have to be sequence that would be extremely unlikely to be triggered randomly. Perhaps something with a challenge and a response.

Or maybe just a magic string to "print" to the LPT port, something like the Hayes AT command set for serial modems.

Does any of this make sense?

dr.zeissler wrote on 2025-11-19, 10:16:

I am not really sure if that would be of much use here since I don't know any standard of PC speaker output in laptops. If you could explain it more thoroughly, I would be happy to learn something new.

I think in general it would be useful to have a line-in port that would allow some other sound source (whether a PC speakers signal or something else) to be mixed in with the output of the device itself. Some hobbyists might have already modded their vintage laptops to have the PC speaker signal routed out through an external cable or something. But maybe that's a nice-to-have for a later revision of the design. 🙂

How to build the first crude prototype:
Even though I am still not ready for massive production (or production of any sort), you can still build your own version based on my naive, bare-bones sketch made in MS Paint. I know that it looks awful, but since I still don't have any final design ready, it's probably the best thing I can offer.

In the provided ZIP file you can find:
sketch.png – simple picture made in MS Paint depicting my current prototype, as if drawn by a three-year-old
picovox.uf2 – the file for the Raspberry Pi Pico 2 in binary form (you can simply upload it and run it)
info.txt – some information for building this device and getting it to work

If you just want to see the pin-to-pin connections:
GP0 – LPT Strobe
GP1 – LPT Data 0
GP2 – LPT Data 1
GP3 – LPT Data 2
GP4 – LPT Data 3
GP5 – LPT Data 4
GP6 – LPT Data 5
GP7 – LPT Data 6
GP8 – LPT Data 7
GP9 – LPT ACK (Input on PC)
GP10 – LPT PaperEnd (Input on PC)
GP11 – LPT Selin
GP12 – LPT Init
GP17 – Button for Mode switch (switch connects GPIO 17 with ground, not with 3.3V!)
GP26 – PCM5102 BCK
GP27 – PCM5102 LCK
GP28 – PCM5102 DIN

Thanks for sharing your progress!

I wonder what would happen if we fed your ZIP file to an LLM and told it to generate a KiCad schematic from it.

But then again, this is your bachelor's thesis, and I wouldn't be surprised if your university had strict rules against the use of AI for that.

Or don't they? Maybe they allow it, as long as you follow certain guidelines?

I don't want you to get suspended or anything! Your eventual graduation is the most important, of course.

Do you think it might be possible to have SoundBlaster support with a driver?

megatog615 wrote on Yesterday, 04:34:

Do you think it might be possible to have SoundBlaster support with a driver?

Yes, it is possible to have SB emulation on a parallel port device for real mode games. There is a VSB(virtual SB) driver that does that with Covox.
And also there is more advanced LPT device - Digispeech DS301 that has pretty good SB compatibility.

Bondi wrote on Yesterday, 08:30:

megatog615 wrote on Yesterday, 04:34:

Do you think it might be possible to have SoundBlaster support with a driver?

Yes, it is possible to have SB emulation on a parallel port device for real mode games. There is a VSB(virtual SB) driver that does that with Covox.
And also there is more advanced LPT device - Digispeech DS301 that has pretty good SB compatibility.

The OP mentioned Digispeech DS301 and DS311 (basically the same device, AFAIK) as a possible future emulation target for the Picovox.

However, the Digispeech DS301/DS311 required a Sound Blaster emulation driver (DOS TSR). There is no way to have Sound Blaster compatibility at the hardware level on a parallel port device. Some level of software emulation will always be needed.

Also, the old VSB driver does not work with Protected Mode games. And I believe that the original Digispeech Sound Blaster driver (emulator) has the same limitation.

Therefore it would be better to extend VSBHDA and/or SBEMU to add support for this device. That way, both real mode and protected mode games could (at least in theory) be made to work with something like a Picovox, even with both digital audio and FM music playback support, like with the aforementioned Digispeech devices.

digger wrote on Yesterday, 10:00:

The OP mentioned Digispeech DS301 and DS311 (basically the same device, AFAIK) as a possible future emulation target for the Pic […]
Show full quote

Bondi wrote on Yesterday, 08:30:

megatog615 wrote on Yesterday, 04:34:

Do you think it might be possible to have SoundBlaster support with a driver?

Yes, it is possible to have SB emulation on a parallel port device for real mode games. There is a VSB(virtual SB) driver that does that with Covox.
And also there is more advanced LPT device - Digispeech DS301 that has pretty good SB compatibility.

The OP mentioned Digispeech DS301 and DS311 (basically the same device, AFAIK) as a possible future emulation target for the Picovox.

However, the Digispeech DS301/DS311 required a Sound Blaster emulation driver (DOS TSR). There is no way to have Sound Blaster compatibility at the hardware level on a parallel port device. Some level of software emulation will always be needed.

Also, the old VSB driver does not work with Protected Mode games. And I believe that the original Digispeech Sound Blaster driver (emulator) has the same limitation.

Therefore it would be better to extend VSBHDA and/or SBEMU to add support for this device. That way, both real mode and protected mode games could (at least in theory) be made to work with something like a Picovox, even with both digital audio and FM music playback support, like with the aforementioned Digispeech devices.

Exactly, Digispeech has the same limitation as VSB - real mode games only.
As for adding support for it on Picovox device - that would be awesome. Yet it's probably not that straightforward as Covox or DSS. Is it known how it works? To my knowledge it uses some custom version of TI DSP chip. Anyways it would be so cool to have the support for it.
And, yes, the topic of adding suppoport for Covox to SBEMU has been discussed many times 😀) Hope it will happen some day. And being the ambassador of the SB Direct Mode, I can't not mention it too 😁

Just posting a quick update:
1) It seems like SN74LVC245AN can be used as a much better LLC. The only problem is that it only supports 8 channels and only 5V>3.3V direction, meaning instead of using 2×TXS0108E, I have to use either one TXS0108E and one SN74LVC245AN, or I have to use 2×SN74LVC245AN and one for the opposite direction (e.g. SN74HCT125N).

2) Even though there is no free pin for controlling the device from the PC, I think that it is safe to just use a combination of pins Autofeed and Selin (since Autofeed is used solely by CMSLPT to indicate writing to one chip, and Selin is used for the second chip, therefore both pins should never be high at the same time). The only problem is that I cannot use direct IRQ for two pins, but with PIO this should not be much of an issue.