DOS ain't dead

Yes, that may be possible with the next release of vsbhda - it has support for 16-bit DPMI.

Tyrian2k revealed a couple of bugs in the current SB emulation code - they're not 100% fixed, SFX sound crackles quite a bit. And I guess there's also a crash later. Perhaps those things got fixed for the final release.

Since Win3.1 in standard mode is a 16-bit client, it might also work with vsbhda - I haven't tried yet. The Creative SB software makes use of undocumented DSP cmds, as I had learned...

https://github.com/Baron-von-Riedesel/VSBHDA/releases/download/v1.4pre1/vsbhda14.zip

Btw, some technical info: the 16-bit variant has been created with OW 2.0 ( like the 32-bit variant ), although OW does NOT contain any 16-bit DOS extender. So it's still pure 32-bit code (wcc386 used as compiler), just made sure that both EIP and ESP registers always have their hiwords cleared.

[Added 21.3.:
A little addition to handle the infamous "Runtime Error 200" for quite a few 16-bit Borland binaries. Now Jazz Jackrabbit should also work...
]

---
MS-DOS forever!

> Yes, that may be possible with the next release of vsbhda - it has support
> for 16-bit DPMI.
>
> [Added 21.3.:
> A little addition to handle the infamous "Runtime Error 200" for quite a
> few 16-bit Borland binaries. Now Jazz Jackrabbit should also work...
> ]

There's actually a modern rewrite (C w/ SDL) called OpenTyrian. Feel free to test it under HX!

> There's actually a modern rewrite (C w/ SDL) called
> OpenTyrian. Feel free
> to test it under HX!

Why we should play OpenTyrian if we can play original Tyrian?

---
DOS-u-akbar!

> There's actually a modern rewrite (C w/ SDL) called
> OpenTyrian. Feel free
> to test it under HX!

Thanks for the info! However, I'm not interested in this clone.

Things that I'm interested in are:

1. vsbhda keeps silent in VirtualBox v7. Is there a known problem with the HDA emulation? ( mpxplay also remains silent ).* Strangely, the VirtualBox HDA offers no "lineout" ( at least no analog one ), but OTOH it offers 2 (analog) "speakers" on the "rear panel" with colors black and green! Is this a bug?

2. there's a HDA driver for Win9x, even supporting Win31. Do you have any experience with that? Does it "work"?

3. Try to run Jazz Jackrabbit in Qemu. What a mess! What are those guys doing all the time? Qemu is more that 20 years old and still has no proper VGA emulation? They should at least be able to copy/paste the relevant code from DosBox...

Edit: *Works in VirtualBox, so long as you don't choose the ICH9 chipset!!! Actually, works significantly better than the VBox SB emulation!

---
MS-DOS forever!

> Yes, that may be possible with the next release of vsbhda - it has support
> for 16-bit DPMI.
>
> Tyrian2k revealed a couple of bugs in the current SB emulation code -
> they're not 100% fixed, SFX sound crackles quite a bit. And I guess there's
> also a crash later. Perhaps those things got fixed for the final release.

Outstanding work!

I can report both Tyrian 2k and Jazz Jackrabbit work on my i5-8250u Dell laptop with HDA audio card:
Intel HDA: Intel SKL (Kabylake-LP) (80869D71) -> Realtek (10EC0256) (max 192kHz/24bit/8ch)

I did not experience any crash yet in Tyrian, but did hear the cracking audio you reported. Has been almost 30 years since I played in it real bare metal DOS with sound.

However, VSBHDA still doesn't work on my other netbook, which has strange IRQ 25 PCI Realtek ALC269 card, on the Apollolake chipset. (This was reported back in Feb '24 on VOGONS forum, and you had suggested the possibility of trying to change the interrupt line in the configuation space of the HDA).

Many thanks for getting VSBHDA working with 16-bit DPMI host games!

> ... and you had suggested the
> possibility of trying to change the interrupt line in the configuation
> space of the HDA).

Yes, but this approach is not very promising, I wouldn't spent time on this.
Almost certainly the only fix - besides a fixed BIOS - is an external timer source ( that APIC thing! ).

---
MS-DOS forever!

> Yes, but this approach is not very promising, I wouldn't spent time on
> this.
> Almost certainly the only fix - besides a fixed BIOS - is an external timer
> source ( that APIC thing! ).
I see. There's little hope of a fixed BIOS - and trying to disassemble the encrypted BIOS is neigh impossible, so that leaves APIC left !

Also, I did see the crash in Tyrian. It happens at the same time always for me, only when my ship is destroyed - and near the very end of that (and long, loud explosion sound), the system always hard freezes. Something about that sound it doesn't like (amplitude too high? ADPCM compressed format sound > 64 kb perhaps?).

The hard system freeze doesn't happen if I enable the invulnerability cheat. This is done by pressing F2 + F3 + F6 all at once while in the flying mission. Then, the ship never crashes, and the game never crashes... Strange, but true!

Also, I tested another 16-bit protected mode game called 4th Generation. It didn't produce any sounds at all (either digital or OPL3) under the 16-bit version of VSBHDA, strangely - even though its setup program detected Soundblaster correctly.

> Also, I did see the crash in Tyrian. It happens at the same time always for
> me, only when my ship is destroyed - and near the very end of that (and
> long, loud explosion sound), the system always hard freezes. Something
> about that sound it doesn't like (amplitude too high? ADPCM compressed
> format sound > 64 kb perhaps?).
>
> The hard system freeze doesn't happen if I enable the invulnerability
> cheat. This is done by pressing F2 + F3 + F6 all at once while in the
> flying mission. Then, the ship never crashes, and the game never crashes...
> Strange, but true!

Confirmed. It's rather a "freeze" than a crash, with the sound hardware "eternally" repeating the current content of the sample buffer. Actually, it's one of those "IRET doesn't restore interrupt flag in protected-mode if IOPL==0" problems, that the rational extender DOS4GW also suffers from.

It's hopefully fixed in the newest version - just download the binary again. Those "fixes" are all a bit hackish, but they work surprisingly well...

---
MS-DOS forever!

> It's hopefully fixed in the newest version - just download the binary
> again. Those "fixes" are all a bit hackish, but they work surprisingly
> well...
Confirmed as fixed, it's working perfectly now. That was a fast fix.

I did a bit of testing VSBHDA.
1) a question - is HDPMI32I.EXE meant to be compatible between VSBHDA and SBEMU or does every need it's own version? In my case I got a crash when loading SBEMU with the new HDPMI32I.EXE from VSBHDA package (below).

2) VSBHDA output plays at significantly lower level on my SB Audigy line out even with /vol9 compared to SBEMU or YMF724 soundcard (I usually have volume button on my PA at 5%, with VSBHDA I need turn on to 50%)

3) Tyrian 2000 works with sound for me :)

4) Dynablaster doesn't play, resp. no music and sfx via PC speaker only. I remember that Crazii did some specific fix to SBEMU to support Dynablaster.


JLoad: 'C:\DOS\qpiemu.dll' loaded successfully.                       
HDPMI32 now resident                                                     
                                                                         
SBEMU  (https://github.com/crazii/SBEMU)                                 
Sound Blaster emulation on PCI sound cards for DOS.                     
Based on MPXPlay (drivers) and DOSBox (OPL-3 emulation).                 
                                                                         
Sound card: SB Live!/Audigy.                                             
Real mode support: enabled.                                             
Protected mode support: enabled.                                         
Exception 0E in ring 0                                                   
client CS:EIP=00AF:00017DFB SS:ESP=00B7:000EEF34                         
EAX=00005A7C EBX=00001BC0 ECX=000000AF EDX=00017CF2 ESI=00000388         
EDI=000083B0 EBP=000EEF88 ESP=00004B7C EFL=00010012 EIP=00005AEA         
CS=0020 (FF800000,0000905F,409B) SS=0028 (FF80A440,FFFFFFFF,CF93)       
DS=00B7 (00111000,0010BFFF,C0F3) ES=0068 (FF800000,0000905F,4093)       
FS=008F (00009D10,0000FFFF,40F3) GS=00C7 (00000000,0010FFFF,80F3)       
LDTR=0038 (FF811000,00000FFF,0082) TR=0030 (FF80A450,00003BB0,008B)     
ERRC=0000 (********,********,****) PTE 1. Page LDT=0446C467             
GDTR=07FF:FF810000 IDTR=07FF:FF810800 PTE CR2=00000006                   
CR0=80000013 CR2=00111388 CR3=0445D000 CR4=00000210 TSS:ESP0=00004BB8   
DR0-3=00000000 00000000 00000000 00000000 DR6=FFFF0FF0 DR7=00000400     
LPMS Sel=0087(00) RMS=D66A:0200 open RMCBs=0000/0000 ISR=0000           
   [EIP]=A5 A5 A5 07 EB 01 F9 61 C3 60 BF AC                             
   [ESP]=00B7 0000 0004 0000 0388 0000 EF88 000E                         
00004B8C=4BA0 0000 00B7 0000 7CF2 0001 00AF 0000                         
00004B9C=83AC 0000 1440 0000 7DFB 0001 00AF 0000                         
00004BAC=0246 0000 EF34 000E 00B7 0000 0048 0028                         
00004BBC=0000 0000 30CD 30CD 30CD 30CD 30CD 30CD                         
00004BCC=30CD 30CD 30CD 30CD 30CD 30CD 30CD 30CD                         


---
DOS gives me freedom to unlimited HW access.

> 1) a question - is HDPMI32I.EXE meant to be compatible between VSBHDA and SBEMU

No. It's mentioned in the readme of vsbhda that sbemu's hdpmi is incompatible with HX. For me it crashes even with rather simple DPMI test cases.

> 2) VSBHDA output plays at significantly lower level on my SB Audigy line
> out even with /vol9 compared to SBEMU or YMF724 soundcard (I usually have
> volume button on my PA at 5%, with VSBHDA I need turn on to 50%)

May very well be so. With vsbhda, only the /VOL cmdline argument will set the sound hardware's "master volume" - that's "by design".

---
MS-DOS forever!

> May very well be so. With vsbhda, only the /VOL cmdline argument will set
> the sound hardware's "master volume" - that's "by design".

SB Audigy (Live too) has front and rear output, maybe only one is set? MPXplay plays at normal level, I could try to run MPXplay before VSBHDA if it will set mixer properly.

---
DOS gives me freedom to unlimited HW access.

I tried to run MPXPLAY before VSBHDA and set volume to 100% (MPXPLAY itself played at normal level) but then games plaed still very silently. So I run MPXPLAY again after VSBHDA loaded and then also MPXPLAY plays silently and I couldn't boost volume to normal level even when I set volume to the max value of 700%.

---
DOS gives me freedom to unlimited HW access.

> I tried to run MPXPLAY before VSBHDA and set volume to 100% (MPXPLAY itself
> played at normal level) but then games plaed still very silently. So I run
> MPXPLAY again after VSBHDA loaded and then also MPXPLAY plays silently and
> I couldn't boost volume to normal level even when I set volume to the max
> value of 700%.

Interesting. Did you unload vsbhda before running mpxplay again? If no, did mpxplay run in "soundblaster mode" or did it ignore vsbhda and run still in "hda mode"?

---
MS-DOS forever!

I didn' unload VSBHDA and MPXplay then detected SB16. So it might work with emulated mixer only. Is it possible to force Mpxplay to use SB audigy instead? Then it would be higher chance it will fix the volume...

---
DOS gives me freedom to unlimited HW access.

> 2) VSBHDA output plays at significantly lower level on my SB Audigy line
> out even with /vol9 compared to SBEMU or YMF724 soundcard (I usually have
> volume button on my PA at 5%, with VSBHDA I need turn on to 50%)
I noticed the lower volume level as well, not with Audigy line out, but in general over regular laptop speaker output. I tried SBMIX utility from rr and even when it's set to max volume and /VOL9 the output is still not as amplified as Mpxplay (ie, native HDA PCI drivers). Normally, on the Dell laptop I'm testing on, I keep Mpxplay volume at 50-60%, as 100% is far, far too loud out of the laptop speakers. However, with VSBHDA (and SBEMU) /VOL9 seems to be about 'equivalent' to 50% of Mpxplay's max (eg, 100%) output.

Yes, something is handled differently on native mixer code between mpxplay, sbemu and vsbhda... setting on emulated sb mixer is not the right way...

---
DOS gives me freedom to unlimited HW access.

> I didn' unload VSBHDA and MPXplay then detected SB16. So it might work with
> emulated mixer only. Is it possible to force Mpxplay to use SB audigy
> instead? Then it would be higher chance it will fix the volume...

"MPXPLAY -scs sba" does not work for you?
Other possibility is to delete the BLASTER environment variable. Then it also should preferably use SB Live/Audigy

---
DOS-u-akbar!

> Yes, something is handled differently on native mixer code between mpxplay,
> sbemu and vsbhda... setting on emulated sb mixer is not the right way...

The problem is that sbemu/vsbhda have to handle 2 inputs: SFX sound and OPL3 sound. Since they use 1 output stream only, they have to use a "software mixer" for those two sounds and to carefully ensure that this mixing won't overamplify the result.

---
MS-DOS forever!

> The problem is that sbemu/vsbhda have to handle 2 inputs: SFX sound and
> OPL3 sound. Since they use 1 output stream only, they have to use a
> "software mixer" for those two sounds and to carefully ensure that this
> mixing won't overamplify the result.
Does this mean that if one disables OPL3 entirely or vice-versa, that, in so only having one input thereby, the volume output stream would be maximum? Does the /OPL command in VSBHDA only enable or may it also disable OPL audio in the emulated SB16?

Yes, MPXPLAY -scs sba works after loading VSBHDA, it detects SBA and play music at normal level. But after I exit Mpxplay and try to play some DOS game it doesn't output any sound (even PA vol. 2 the max).

---
DOS gives me freedom to unlimited HW access.

I understand that for adding 2 signals together the sample value need to be halved before to avoid overflow/clipping the result but in my case it's not a half sound level but only 10% or even less. And SBEMU just do the same mixing of SFX and OPL too...

---
DOS gives me freedom to unlimited HW access.

> I understand that for adding 2 signals together the sample value need to be
> halved before to avoid overflow/clipping the result

It's not "halved", it's using kind of a "geometric mean", looks rather complicated ( because the sample values are "signed"):


for( i = 0; i < samples * 2; i++ ) {
   int a = (*(pPCM+i) * (int)voicevol / 256) + 32768;    /* convert to 0-65535 */
   int b = (*(pOPLPCM+i) * (int)midivol / 256 ) + 32768; /* convert to 0-65535 */
   int mixed = (a < 32768 || b < 32768) ? ((a*b)/32768) : ((a+b)*2 - (a*b)/32768 - 65536);
   *(pPCM+i) = (mixed > 65535 ) ? 0x7fff : mixed - 32768;
}


IIRC crazii found this somewhere on "stackoverflow". I will happily adjust vsbhda if you know something better.

---
MS-DOS forever!

> Does this mean that if one disables OPL3 entirely or vice-versa, that, in
> so only having one input thereby, the volume output stream would be
> maximum?

I'm not sure, but in such cases the software mixer has a lot less to do:


if( digital )
   for( i = 0; i < samples * 2; i++ ) *(pPCM+i) = ( *(pPCM+i) * voicevol ) >> 8;
else
   memset( pPCM, 0, samples * sizeof(int16_t) * 2 );


The "if( digital )" is the branch that's used when only SFX sound is to render, while the "memset()"-branch runs when even SFX sound is off - yes, it's true, in this case sbemu/vsbhda still runs in the background, interrupts every few millisecs, emitting "silence"...

---
MS-DOS forever!

why so complicated? I though that mixing is just a simple linear adding or superposing signals together. But even if so the same code is used by crazii sbemu why sbemu plays at normal level and vsbhda plays much more silent? If the mixing code is the same it should play the same output level. I still suspect the hw mixer of audigy is set differently...

---
DOS gives me freedom to unlimited HW access.

https://github.com/Baron-von-Riedesel/VSBHDA/releases

---
MS-DOS forever!

> https://github.com/Baron-von-Riedesel/VSBHDA/releases

Thanks! (Although I didn't test it.)

"open cube player" or "Open Cubic Player"?
https://github.com/Baron-von-Riedesel/VSBHDA/blob/main/src/MAIN.C#L462

---
Forum admin

> > https://github.com/Baron-von-Riedesel/VSBHDA/releases
>
> Thanks! (Although I didn't test it.)
>
> "open cube player" or "Open Cubic Player"?
> https://github.com/Baron-von-Riedesel/VSBHDA/blob/main/src/MAIN.C#L462
I never could get Open Cubic Player to work correctly with either SBEMU or VSBHDA. It seems that the 16-bit PCM audio output by Cubic is *un*signed, when it should be signed 16-bit (ie, -32768 to 32767 amplitude, not 0 to 65535 as output). It therefore sounds very, very distorted. I think this is a bug in Cubic Player itself, not SBEMU or VSBHDA. It's either this or an endian problem which transpose the 16-bit amplitudes of the sound (little-endian vs big-endian).

> I never could get Open Cubic Player to work correctly with either SBEMU or
> VSBHDA. It seems that the 16-bit PCM audio output by Cubic is *un*signed,
> when it should be signed 16-bit (ie, -32768 to 32767 amplitude, not 0 to
> 65535 as output).

For me it works. And your "argument" actullay is none - unsigned 16-bit PCM data, if it's really used by OCP ( I don't know) is supported by the SB16, so it has to be supported by emulators as well

The term "for me it works" has a small catch: it works, but I had to double an internal value from 64 kB to 128 kB, else OCP crashes on exit when a MP3 file has been played. This is a strange thing, for now I left it for a rainy day...

---
MS-DOS forever!

> The term "for me it works" has a small catch: it works, but I had to double
> an internal value from 64 kB to 128 kB, else OCP crashes on exit when a MP3
> file has been played. This is a strange thing, for now I left it for a
> rainy day...
Yes, you are correct: it DOES work! I had not yet tested the final version 1.4 of VSBHDA above. I did so with Open Cubic player v. 2.60 and, yes, its devsb driver works perfectly now.

SBEMU, on the other hand, does not work, and never has with the open Cubic Player, exhibiting the strange distortion referred to above. (All my settings kept with the same emulated IRQ, DMA, volume, etc between SBEMU and VSBHDA).

Several other programs now work with VSBHDA: I tested the audio playing of SEA v. 1.3 and Display v. 1.90td6. And of course it works exceptionally in QuickView 2.61 and the most recent Mplayer DOS port.

I notice some programs, like Sea 1.3 detect a DSP version of 4.5 for the emulated SB16.

One more fine victory for you... Thanks for that little hack (64kb to 128kb) which worked the magic.

> https://github.com/Baron-von-Riedesel/VSBHDA/releases

FYI: I created a SvarDOS package from and put it to the SvarDOS repo yesterday.

---
Forum admin

> https://github.com/Baron-von-Riedesel/VSBHDA/releases

XMS restrictor(xmsres.exe) by Japheth included in Sound blaster emulation for HDA (High Definition Audio) with io8emmok.sys driver by Dr. Pufeng Du allows you to run Windows 3.1 from MS-DOS 8.0 in 386 Enhanced Mode on real hardware.

> > https://github.com/Baron-von-Riedesel/VSBHDA/releases
>
> XMS restrictor(xmsres.exe) by Japheth included in Sound blaster emulation
> for HDA (High Definition Audio) with
> io8emmok.sys driver by
> Dr. Pufeng Du allows you to run Windows 3.1 from MS-DOS 8.0 in 386 Enhanced
> Mode on real hardware.

Also mentioned is that you can run Windows for Workgroups on FreeDOS (using a modified ecm FD kernel from last August, kwin31.zip).

> > https://github.com/Baron-von-Riedesel/VSBHDA/releases
>
> XMS restrictor(xmsres.exe) by Japheth included in Sound blaster emulation
> for HDA (High Definition Audio) with
> io8emmok.sys driver by
> Dr. Pufeng Du allows you to run Windows 3.1 from MS-DOS 8.0 in 386 Enhanced
> Mode on real hardware.

in MS-DOS 8, not only io8emmok, but also EMM386.EXE are required for running Windows 3.x correctly.

> > > https://github.com/Baron-von-Riedesel/VSBHDA/releases
> >
> > XMS restrictor(xmsres.exe) by Japheth included in Sound blaster
> emulation
> > for HDA (High Definition Audio) with
> > io8emmok.sys driver
> by
> > Dr. Pufeng Du allows you to run Windows 3.1 from MS-DOS 8.0 in 386
> Enhanced
> > Mode on real hardware.
>
> Also mentioned is that you can run
> Windows
> for Workgroups on FreeDOS (using a modified ecm FD kernel from last
> August, kwin31.zip).

My config.sys for Free DOS

The main thing is memory limitation

device=xmgr.sys
install=xmsres.exe 512

install=share.com

or
device=himemx.exe /MAX=524288
instead
device=xmgr.sys
install=xmsres.exe 512

My Demo
http://forum.old-dos.ru/viewtopic.php?f=2&t=1834&p=27721#p27644

> > > https://github.com/Baron-von-Riedesel/VSBHDA/releases
> >
> > XMS restrictor(xmsres.exe) by Japheth included in Sound blaster
> emulation
> > for HDA (High Definition Audio) with
> > io8emmok.sys driver
> by
> > Dr. Pufeng Du allows you to run Windows 3.1 from MS-DOS 8.0 in 386
> Enhanced
> > Mode on real hardware.
>
> in MS-DOS 8, not only io8emmok, but also EMM386.EXE are required for
> running Windows 3.x correctly.

My config.sys for MS-DOS 8.00
The main thing is memory limitation
device=io8emmok.sys
device=emm386.exe noems
install=xmsres.exe 512

install=w3xstart.com

> The main thing is memory limitation
> ...
> install=share.com
> ...
> device=himemx.exe /MAX=524288

Have you tried adding PageOverCommit=1 or 2 in
your [386enh] section of Windows system.ini to
support higher MAX values?

Windows 3.x uses PageOverCommit=4 as default,
but overflows if available memory * overcommit
factor > 2 GB, I think.

---
FreeDOS / DOSEMU2 / ...

> > The main thing is memory limitation
> > ...
> > install=share.com
> > ...
> > device=himemx.exe /MAX=524288
>
> Have you tried adding PageOverCommit=1 or 2 in
> your [386enh] section of Windows system.ini to
> support higher MAX values?
>
> Windows 3.x uses PageOverCommit=4 as default,
> but overflows if available memory * overcommit
> factor > 2 GB, I think.


[386enh]
display=*vddvga
keyboard=*vkd
mouse=*vmd
local=con
filesyschange=off
paging=0
pageovercommit=1
.
.
.


memory limit=512MB
> > device=himemx.exe /MAX=524288



http://forum.old-dos.ru/viewtopic.php?f=2&t=1834#p27644

I just found that VSBHDA 1.5 pre1 was silently released and it fixes the extreme low volume level. I checked on my SB Audigy and now the output volume is similar to SBEMU or MPXPlay as expected. Thx.
[ https://github.com/Baron-von-Riedesel/VSBHDA/releases/tag/v1.5pre1 ]

---
DOS gives me freedom to unlimited HW access.