VOGONS


First post, by PCGamingTimeMachine

User metadata
Rank Newbie
Rank
Newbie

Hi everyone, I've been working on adding CD audio support to the excellent VSBHDA, SHSUCDX and SHSUCDHD programs for a couple of months. Before I go ahead, I'd like to give a disclaimer + assurance:

AI help was used for bootstrap code for some functionalities, debugging and code cleanup/formatting. However I did manually verify everything and manually built on top of initial bootstrap code blocks if AI was used. I think it's fair since a large chunk of the effort was manual and I tried my best to review everything. Plus without AI help with debugging this project would've taken much longer.

I also acknowledge I'm nowhere nearly as good or experienced of a DOS programmer as the original authors of VSBHDA (and every other software it's based on) and authors of SHSUCD. So I'd be very grateful for any feedback, suggestions or comments from the more experienced DOS/system programmers. The code is very likely far from perfect.

With that said, I'm at the stage where the modified programs work and I'm comfortable releasing this as a pre-alpha.

Links:
- https://github.com/PCGamingTimeMachine/VSBHDA … s/tag/Pre-alpha
- https://github.com/PCGamingTimeMachine/shsucd … s/tag/Pre-alpha

Modified SHSUCDX + VSBHDA allow you to run games with Red Book / mixed-mode CDs, and get fully working in-game and CD audio. Please go through README.txt in the modded shsucd and VSBHDARB.txt in the modded VSBHDA packages, respectively.

Quick usage guide if you have a physical CD drive:
1. Load the CD driver in config.sys. What works well for me: DEVICEHIGH=UIDE.SYS /D:MSCD001 /N1 /UX
2. Run modified SHSUCDX via: SHSUCDX /D:MSCD001 /A:1
3. Run vsbhdarb.exe via: VSBHDARB /CDA

You can also get such games working without a CD drive if you additionally use the modded SHSUCDHD program. Basically in that case you'll have to convert a .bin/.cue image set for a Red Book game to a CD metadata (.CDM) + consolidated BIN format (I've included instructions for that in the modded SHSUCD release's README.txt). Then you will need to run:
1. SHSUCDHD /F:<path to CDM file>
2. SHSUCDX /D:SHSU-CDH /A:1
3. VSBHDARB /CDA

I'll edit this post with more details and instructions later on, but I hope this is sufficient info for you to get started. Please back up your DOS partition before trying it in a bare-metal DOS machine - I've not faced any issues so far on my own PC or 86Box VMs, but it's not possible for me to test it on all possible hardware configurations. So just to be safe, please back up.

Please let me know if you have any questions and I'll try my best to answer.

Demo for physical CD + modded SHSUCDX + modded VSBHDA: https://youtu.be/QUDK3KzQmc8

Limitations (as far as I'm aware of)
- The CPU does quite a bit of heavy-lifting in not just running the game and emulating digital audio, but also doing raw reads from the game CD and mixing that into the regular audio stream, so this probably won't work well on older computers with period-accurate processors
- Raw read speed also depends on the CD drive's speed, so performance may vary from one CD drive to another. e.g. in my case a SATA CD/DVD drive performed better than an IDE CD drive
- Modified SHSUCDX works with UIDE, UIDEJR and GCDROM drivers, but may not necessarily give CD audio functionality (even if invoked via appropriate flag during SHSUCDX initialization) with some other CD drivers. I'm not sure why that is but I'll try to figure it out eventually

Reply 1 of 7, by PCGamingTimeMachine

User metadata
Rank Newbie
Rank
Newbie

I'm unable to edit my original post, so I'll put any additions here:

Acknowledgements
Thanks to Japheth for VSBHDA and authors of all programs that VSBHDA is based on or uses - SBEMU (crazii), VSBHDASF (Cacodemon345), DosBox, MpxPlay, TinySoundFont, etc. Thanks also to Jason Hood and John McCoy for their amazing work on the shsucd suite.

Also thanks a lot to @wierd_w for his insights on how digital CD audio could be achieved. His ideas formed the skeleton of this project.

Reply 2 of 7, by wierd_w

User metadata
Rank Oldbie
Rank
Oldbie

As I said then, Ideas are free, implementations are not.

This is an implementation, and I am *VERY* happy to see it. 😁

I do question why you are gobbling this much XMS though. The idea with using a much smaller dual buffer would let you get away with maybe 1 or 2mb of XMS used. Just enough for a few seconds of redbook audio each, with them cycling regularly.

Was this a performance ceiling issue?

Reply 3 of 7, by wierd_w

User metadata
Rank Oldbie
Rank
Oldbie

I have played with this today.

It seems that shsucdhd is not freeing XMS memory when it unloads.

Some ugliness with quake not being able to run a second time after exiting, with cdda support enabled, without fully unloading then reloading the audio stack.

But, it works quite well on my asus otherwise!

Reply 4 of 7, by jh80

User metadata
Rank Newbie
Rank
Newbie

Very interesting. I wonder how much CPU overhead there is. Could a Pentium MMX 200 handle it for games that typically ran fine on something like a 486-66, or are we talking much more CPU required?

Reply 5 of 7, by NeoG_

User metadata
Rank Oldbie
Rank
Oldbie
jh80 wrote on 2026-04-27, 01:49:

Very interesting. I wonder how much CPU overhead there is. Could a Pentium MMX 200 handle it for games that typically ran fine on something like a 486-66, or are we talking much more CPU required?

There’s basically no performance metrics at the moment, some members of the community will need to test it on various systems

98/DOS Rig: BabyAT AladdinV, K6-2+/550, V3 2000, 128MB PC100, 20GB HDD, 128GB SD2IDE, SB Live!, SB16-SCSI, PicoGUS, WP32 McCake, iNFRA CD, ZIP100
XP Rig: Lian Li PC-10 ATX, Gigabyte X38-DQ6, Core2Duo E6850, ATi HD5870, 2GB DDR2, 2TB HDD, X-Fi XtremeGamer

Reply 6 of 7, by PCGamingTimeMachine

User metadata
Rank Newbie
Rank
Newbie
wierd_w wrote on 2026-04-26, 22:31:
I have played with this today. […]
Show full quote

I have played with this today.

It seems that shsucdhd is not freeing XMS memory when it unloads.

Some ugliness with quake not being able to run a second time after exiting, with cdda support enabled, without fully unloading then reloading the audio stack.

But, it works quite well on my asus otherwise!

Thank you for testing! And yeah there are rough edges - I'll only remove that "pre-alpha" tag after a bit more polishing. You're right - before relaunching the game (or launching a new game), it's generally better to unload VSBHDARB, then shsucdx, then shsucdhd, and then re-load shsucdhd, then shsucdx, then VSBHDARB. It's a pain but users need to bear with this for a while.

Glad to hear it's working well apart from the above though!

Reply 7 of 7, by PCGamingTimeMachine

User metadata
Rank Newbie
Rank
Newbie
jh80 wrote on 2026-04-27, 01:49:

Very interesting. I wonder how much CPU overhead there is. Could a Pentium MMX 200 handle it for games that typically ran fine on something like a 486-66, or are we talking much more CPU required?

Currently I estimate it will not run smoothly on older systems at all (i.e. the sound/music will play in a slow motion way) because the CPU is doing a bunch of heavy lifting - emulating in-game digital audio (VSBHDA's vanilla functionality), running the game, making data reads from image/CD drive, making raw reads from XMS, and mixing the audio streams.

My rationale was: generally the older vintage systems could anyways support full game audio since they could use sound cards with native DOS support - either ISA sound cards or PCI cards connected to PC-PCI header on motherboard. My idea was to make this primarily targetted to more modern systems since PCI cards generally don't have native DOS drivers, so even with an analog connection between CD drive and sound card, it's still not possible to get CD audio on the modern systems. And even more modern systems may not even have PCI slots, but if they have onboard audio with VSBHDA support, then this set of modified programs would be useful to get that full DOS audio.

It's not to say that I don't want this to be usable in older systems at all, but it will still require optimization or code refactoring, which I want to keep as a secondary objective. My primary objective with this is to get it in a good enough shape for bare metal "modern" or semi-modern systems, so that I can remove the pre-alpha status of this. And then I'll shift focus to getting this working (or maybe a separate version) on older systems (e.g, testing with 86Box). Hope that makes sense.