DOS ain't dead

Hello,

a new version of vsbhda, the most important changes:

1. fixed a regression in v1.8 ( size DMA buffer < size SB buffer )
2. contains preliminary hdpmi v3.24

These changes make Open Cubic Player and game Redneck Rampage to work again.

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

---
MS-DOS forever!

Thank you!

---
DOS-u-akbar!

> Hello,
>
> a new version of vsbhda, the most important changes:
>
> 1. fixed a regression in v1.8 ( size DMA buffer < size SB buffer )
> 2. contains preliminary hdpmi v3.24
>
> These changes make Open Cubic Player and game Redneck Rampage to work
> again.
>
> https://github.com/Baron-von-Riedesel/VSBHDA/releases/tag/v1.9

Awesome to see! I'll pull these changes into the red book audio fork of VSBHDA some time next month.

Hello,

a new version of vsbhda has been released: https://github.com/Baron-von-Riedesel/VSBHDA/releases/tag/v2.0

Besides a few bug fixes the major changes are:

1. significant smaller default hardware buffer size. This reduces latency significantly, so the emulation feels like "real hardware". Also, the hardware buffer size is now configurable.

2. no samples rendered by the interrupt routine are dropped anymore, thus increasing emulation quality.

---
MS-DOS forever!

I found that with v2.0 compared to v1.8 I got more noisy/distorted sound in Future Crew Second Reality demo
http://rayer.g6.cz/1tmp/2ndreal.zip
(start by 2NDFIX.EXE and choose Soundblaster Pro stereo)
It's noticable in the beginning scene after subtitles when ships flies over before explosion. As I read that buffers was reduced in v2.0 maybe it needs manually tune /B for bigger value? Is it possible to adjust it at runtime or need to unload/load again?

EDIT: it's clearly noticable difference between choosing SB mono and SB Pro stereo from the playback beginning. While mono plays almost clear with occasional short pops the stereo is much more worse in v2.0. I tried to guess some /b [1-64] and /bp but not luck to find good values to reach at least the same result as with older v1.8.

EDIT2:
Surprisingly it helped to increase fs to 44k (default was 22k) by /f44100, /b has no effect...

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

> EDIT2:
> Surprisingly it helped to increase fs to 44k (default was 22k) by /f44100,
> /b has no effect...

If increasing the rate does improve sound quality then /bp should help even more ( try /bp256) - and /b has of course no effect.

On my HDA system sound quality of the demo is better with v2.0 than with v1.8, clearly detectable within the first few seconds playing.

btw, do you happen to have a Creative card with chip CA0106:
- SB Life 24
- SB Audigy LS
- SB X-FI (SB0790)

or another SB X-FI PCI ( with chip EMU20K1 [non-titanium] ) card?

I'd need someone for a few tests and don't want to spent money ...

---
MS-DOS forever!

Yes, it seems abs.logical that higher fs needs more buffering. I just tried random to lower at 11k - no change but higher 44k helped,no idea why...
I still use the same SB Audigy1 at PCI IRQ5 (shared with other PCI peripherals). I'll try bp256, I tried max 32 or 64...

I'll look for some other SB cards, I think the newest I have is Audigy2 and also have some low-profile card that's not based on EMU10k line but something cheaper...

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

> Yes, it seems abs.logical that higher fs needs more buffering. I just tried
> random to lower at 11k - no change but higher 44k helped,no idea why...

The demo ( SB Pro, sound quality "high" ) uses a sample rate of 40.000 Hz. Perhaps the resampling code has a problem if sound is to be downsampled to 22.050 Hz.

---
MS-DOS forever!

I tried /bp256 and no effect, seems to be something with resampling as you wrote. Do you also noticed difference between ver. 2.0 and 1.8/1.9?

For testing I can help with:
Sound Blaster Audigy LS PCI 2.1, CA0106 SB0570
Sound Blaster X-Fi SB0790 low-profile PCI
If I remember well both are capable to play under DOS with Mpxplay, I never tested them with SBEMU/VSBHDA.

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

> I tried /bp256 and no effect, seems to be something with resampling as you
> wrote. Do you also noticed difference between ver. 2.0 and 1.8/1.9?

I will have to check if downsampling has worsened. My test was with 44.1 kHz ( 22,05 not possible there ) - as already mentioned, then v2.0 was better than v1.8.

> Sound Blaster Audigy LS PCI 2.1, CA0106 SB0570
> Sound Blaster X-Fi SB0790 low-profile PCI

Both have CA0106 and hence are already "supported" by current SBEMU/VSBHDA.

"Supported" means: they are recognized and the emulator will install itself, but it can't work, because interrupt handling isn't correct - the "interrupt enable" register is queried/acknowledged instead of "interrupt status" register. The code is derived from MpxPlay, but MpxPlay doesn't use the sound hardware interrupt, so this program might actually work already...

I created an issue on GitHub/VSBHDA for the CA0106 cards: https://github.com/Baron-von-Riedesel/VSBHDA/issues/45

and will post an updated vsbhda there ASAP.

---
MS-DOS forever!

OK, I'll try to physically find at least one of them and prepare test PC. You can send me some test version with debug prints or register dump tool like sblive.exe and I collect the logs... AFAIK as I read somewhere this sound chip should be very similar to common AC'97/HDA, no any EAX HW 3D sound like on EMUks...

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

> I tried /bp256 and no effect, seems to be something with resampling as you
> wrote.

I tried the demo now on a P3 system with a SB Life. It seems the program adjusts the sample rate to the system it's running on - now it supplies samples with 20 kHz. So the "downsampling theory" of mine turned out to be wrong.

However, what came into my mind: did you run vsbhda with T4 in the BLASTER environment variable? As you may know, there's a known problem running SB Pro stereo commands on a SB16, so it's recommended to let vsbhda emulate a SB Pro in such cases.

---
MS-DOS forever!

I had set T6. When I changed to T4 (removed /f to let it set default 22kHz) then 2nd reality sound in SB Pro stereo mode plays at ~twice speed while SB mono plays at normal speed...

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

> When I changed to T4 (removed /f to let it set default 22kHz)
> then 2nd reality sound in SB Pro stereo mode plays at ~twice speed

I see. Try this ( v20a ): https://drive.google.com/file/d/1G7vDNNAwdrkdlMjf_Fhb8mPYsqY4O957/view?usp=drive_link

Be aware that the 2nd reality demo is one of those programs that change the SB Mixer to stereo mode, but forget to reset it to normal mode when exiting. This may give interesting effects ...

---
MS-DOS forever!

Thanks, I did a quick test and now it seems no more distorted/poppy sound with new version. I tried change both T4/T6 and fs 22k/44k and it doesn't affect sound, it behaves consistently. Only thing I can notice is verly slighy pich difference between mono and stereo playback in demo (mono seems to me a bit faster than stereo). I don't have absolute hearing so I can notice this only when running the demo with different setting as fast is possible between each other. If it could produce come clear tone I could measure it exactly...

For programs that manipulate mixer and other global settings, just an idea - vsbhda could have some option that would store settings at load and restore them automatically when program exits to prevent unwanted behavior/affect to other programs launched later...

BTW I still have minor issue that PC hangs at ctrl+alt+del when vsbhda or sbemu is loaded (using jemm fastboot option) so I need to unload it before to reboot normally otherwise reset button is needed.

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

> I tried change both T4/T6 and fs 22k/44k and it doesn't affect sound, it behaves consistently.

But there should be a difference - T6 (SB16) can play SB Pro stereo in mono only - I changed this only very recently for the next version. Or did this change find its way into the "bugfixed" v2.0a?

> Only thing I can notice is very slighy pitch difference between mono and
> stereo playback in demo (mono seems to me a bit faster than stereo).
> If it could produce some clear tone I could measure it exactly...

There's already a test program on github/vsbhda/test that emits a sine wave - but it's mono only - must be enhanced a bit for stereo.

> For programs that manipulate mixer and other global settings, just an idea
> - vsbhda could have some option that would store settings at load and
> restore them automatically when program exits to prevent unwanted
> behavior/affect to other programs launched later...

One problem is that vsbhda doesn't notice when a program "exits". For now I just made a little tool ( MIXMONO ) that will reset the SB Pro mixer to mono.

---
MS-DOS forever!

I did a quick test so I listen only a few seconds of demo sound. I concentrated on pitch not if it plays mono or stereo.

BTW I digged the SB X-Fi PCI soundcard SB0790. There's a sticker on the chip that I don't want to remove but it could be CA0106 soudchip you wanted to test.

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

> BTW I digged the SB X-Fi PCI soundcard SB0790. There's a sticker on the
> chip that I don't want to remove but it could be CA0106 soudchip you wanted
> to test.

Ok, here's the current vsbhda - CA0106 build in, but untested:

https://drive.google.com/file/d/1QDO-PA1CRR2WG6c4ln4vBt6DWD_mXnel/view?usp=sharing

If no sound is emitted, please try MpxPlay - this program uses the same driver code, but doesn't use the card's interrupt mechanism.

---
MS-DOS forever!

Thx, I'll try. If I remember well I tested this or the second card with CA0106 under MPXplay and it played well...

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

> > EDIT2:
> > Surprisingly it helped to increase fs to 44k (default was 22k) by
> /f44100,
> > /b has no effect...
>
> If increasing the rate does improve sound quality then /bp should help even
> more ( try /bp256) - and /b has of course no effect.
>
> On my HDA system sound quality of the demo is better with v2.0 than with
> v1.8, clearly detectable within the first few seconds playing.
>
> btw, do you happen to have a Creative card with chip CA0106:
> - SB Life 24
> - SB Audigy LS
> - SB X-FI (SB0790)
>
> or another SB X-FI PCI ( with chip EMU20K1 [non-titanium] ) card?
>
> I'd need someone for a few tests and don't want to spent money ...

Hi Japheth, I have a X-Fi Titanium PCI-e. I can help with tests if needed

> Hi Japheth, I have a X-Fi Titanium PCI-e. I can help with tests if needed

Good to know!

Support for CA0106 probably will be easily implemented, but the cards based on EMU20Kx chips will cause some headaches. There's no real documentation and the sources in ALSA are sparsely commented.

In the meantime I've bought a SB0730 ( EMU20K1 card ), so this will be next once CA0106 works...

---
MS-DOS forever!

Back from a vacation for a moment so I did a quick test with X-fi.
Machine: Pentium III@550, 440BX chipset, 128MB SDRAM, MSDOS 7.1
MPXplay plays smoothly.
VSBHDA 2.1 loads without errors, can hear a slight pop in phones when loading but Doom and Quake runs without sound at all. I tried emulated IRQ5 and 7, T4 and T6. Then I tried to run debug version, load log below. It makes anoying buzzing sound with some low-f popping/dropping ~10-20Hz. When Doom was run with debug version VSBHDA threw fatal error 4 at loading. I keep test setup lying around to be ready for futher testing...


Found sound card: Live! 7.1 24bit [unknown]
OPL3 emulation: enabled at port 388h (48000 Hz)                   
SB emulation: Addr=220, Irq=7, Dma=1, HDma=5, P=330, Type=6

SB values before cmdline: A=220 I=7 D=1 T=6 H=5 P=330
2?
AU_init
af, brk(40): new/old _curbrk 14f000/147000, _dynend=147000
AU_init: checking card ENS
AU_init: checking card ICH AC97
AU_init: checking card Intel HDA
HDA_close
HDA_adetect: no acceptable card found
AU_init: checking card SB Live!/Audigy
SBALL_adetect
SBALL_adetect: found device vendor=1102 device=7
snd_live24_selector: live24
MDma_get_bufsize(max=0x0,pgsiz=0x200)=0x1000
MDma_alloc_cardmem(0x1040)
MDma_alloc_cardmem: 14f000
buffer init: pagetable:  14f000 pcmoutbuf:  14f040 size:4096
snd_live24_hw_init: enter
snd_ca0106_hw_init
card ok, name=Live! 7.1 24bit [unknown], index=4, base=e400, irq=a
AU_init: found card Live! 7.1 24bit [unknown]
Found sound card: Live! 7.1 24bit [unknown]
AU_setmixer_one( channel=0, setmode=1, newvalue=77 )
AU_setmixer_one: function=0, channel=0, subchannelnum=2
AU_setmixer_one: set newpercentval to 77 % )
AU_setmixer_one: newchval=c4 max=ff
AU_setmixer_one: newchval=3b
AU_setmixer_one: newchval=3b000000 after shift
AU_setmixer_one: called card_readmixer(6a)=30303030 (max=ff, shift=24)
AU_setmixer_one: calling card_writemixer(6a, 3b303030) [currchval=303030]
AU_setmixer_one: newchval=c4 max=ff
AU_setmixer_one: newchval=3b
AU_setmixer_one: newchval=3b0000 after shift
AU_setmixer_one: called card_readmixer(6a)=3b303030 (max=ff, shift=16)
AU_setmixer_one: calling card_writemixer(6a, 3b3b3030) [currchval=3b003030]
AU_setmixer_one( channel=1, setmode=1, newvalue=77 )
AU_setmixer_one( channel=2, setmode=1, newvalue=77 )
AU_setmixer_one( channel=3, setmode=1, newvalue=77 )
AU_setmixer_one: function=0, channel=3, subchannelnum=2
AU_setmixer_one: set newpercentval to 77 % )
AU_setmixer_one: newchval=c4 max=ff
AU_setmixer_one: newchval=3b
AU_setmixer_one: newchval=3b000000 after shift
AU_setmixer_one: called card_readmixer(66)=30303030 (max=ff, shift=24)
AU_setmixer_one: calling card_writemixer(66, 3b303030) [currchval=303030]
AU_setmixer_one: newchval=c4 max=ff
AU_setmixer_one: newchval=3b
AU_setmixer_one: newchval=3b0000 after shift
AU_setmixer_one: called card_readmixer(66)=3b303030 (max=ff, shift=16)
AU_setmixer_one: calling card_writemixer(66, 3b3b3030) [currchval=3b003030]
AU_setrate(freq=22050, chan=2, bits=16) enter, freq_card=22050
MDma_initbuf(bufsize=0x1000)
buffer config: bufsize:4096 period_size:512
snd_ca0106_pcm_prepare playback: exit
PTRAP_Init_RM: QPI old callback=0:0
hdpmi_rmcbIO enter
PTRAP_AddRange(start=0x20, portmap=0x3) cntranges=0
PTRAP_AddRange(start=0xa1, portmap=0x1) cntranges=1
PTRAP_AddRange(start=0x2, portmap=0x3fc3) cntranges=2
PTRAP_AddRange(start=0xc4, portmap=0x5555005) cntranges=3
PTRAP_AddRange(start=0x81, portmap=0x404) cntranges=4
PTRAP_AddRange(start=0x220, portmap=0xd77f) cntranges=5
VSB_Mixer_Write(idx=0, data=0x1)
VSB_Init: dsp ver=405 Irq=7, lDma=1, hDma=5
PTRAP_AddRange(start=0x388, portmap=0xf) cntranges=6
OPL: InitTables
Chip::Setup(48000)
Chip::Setup exit
OPL3 emulation: enabled at port 388h (48000 Hz)
SB emulation: Addr=220, Irq=7, Dma=1, HDma=5, P=330, Type=6
1100af, brk(10004): new/old _curbrk 161010/14f000, _dynend=151000
SNDISR_Init: pPCM=162000
SNDISR_Init: v86 PT0=116000 mapped at 194000
SND_InstallISR enter
PTRAP_AddRange(start=0x330, portmap=0x3) cntranges=7
PTRAP_Install_PortTraps: range[0]: ports 20-21
PTRAP_Install_PortTraps: range[1]: ports a1-a1
PTRAP_Install_PortTraps: range[2]: ports 2-f
PTRAP_Install_PortTraps: range[3]: ports c4-de
PTRAP_Install_PortTraps: range[4]: ports 81-8b
PTRAP_Install_PortTraps: range[5]: ports 220-22f
PTRAP_Install_PortTraps: range[6]: ports 388-38b
PTRAP_Install_PortTraps: range[7]: ports 330-331
PTRAP_Install_PortTraps: cntranges=8 cntports=44
SB_InstallISR enter
SB_Notify31: CX:EDX=5b:25e
_InstallInt31 enter
snd_live24_pcm_start_playback
AU_start: card ctrlbits=0 infobits=1
AU_start: card dmasize=0x1000 dmalastput=0x0 dmaspace=0 buffer_protection=64
AU_start: card bytespersign=4 sampleshift=1
AU_start: freq_card=48000, chan_card=2, bits_card=16


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

> VSBHDA 2.1 loads without errors, can hear a slight pop in phones when
> loading but Doom and Quake runs without sound at all. ...
>
>
> Found sound card: Live! 7.1 24bit [unknown]
---
>

Thanks, will check this later!

However, since the logs may become quite large - if you have a github account, it's probably better to post your experiences there: https://github.com/Baron-von-Riedesel/VSBHDA/issues/45

---
MS-DOS forever!

The log that you posted comprises the init phase only. Since the card is successfully detected and setup, this phase isn't that interesting. I need the full log to see whether interrupts are generated multiple times with a correct timer value ( so there's no DMA underrun/overrun ).

---
MS-DOS forever!

OK,how do I capture log of TSR phase after init? I just added 2 >log in start.bat And as I wrote before it crashed when loading Doom - fatal error 4 (only when used debug version it started with normal version)

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

> OK,how do I capture log of TSR phase after init? I just added 2 >log in
> start.bat And as I wrote before it crashed when loading Doom - fatal error
> 4 (only when used debug version it started with normal version)

Vsbhda's debug version understands cmdline option /LF:

vsbhda /LF:log.txt

will write the log text in an xms buffer; when uninst.exe is launched, the contents of this buffer is written to file log.txt.

You don't need run Doom - a very simple test case is better.
For example, test01 or test02 from https://github.com/Baron-von-Riedesel/VSBHDA/tree/main/Test

---
MS-DOS forever!

> vsbhda /LF:log.txt
Before I read this reply I run another quick test and collect just text output on the screen if it helps (play.exe is complete output, play of the wav never ends until ctrl+c so seems IRQ was not fired)

doom.exe
... (repeat until ctrl+c)
Error [35]: General Protection Fault in DOOM.EXE at 00AF:7BE6                   
code=0000 ss=00D7 ds=00B7 es=00D7                                               
ax=0780 bx=0FA0 cx=03C0 dx=025E sp=1456 bp=1482 si=80A0 di=8000 SB_Notify31: CX:
Error [35]: General Protection Fault in DOOM.EXE at 00AF:7BE6                   
code=0000 ss=00D7 ds=00B7 es=00D7                                               
ax=0780 bx=0FA0 cx=03C0 dx=025E sp=1456 bp=1482 si=80A0 di=8000 SB_Notify31: CX:
Error [35]: General Protection Fault in DOOM.EXE at 00AF:7BE6                   
code=0000 ss=00D7 ds=00B7 es=00D7

play.exe tada.wav
DSP_Reset: 1                                                           
DSP_Reset: 0                                                           
DSP_Reset: 1                                                           
DSP_Reset: 0                                                           
DSP_DoCommand(40): set time constant=a6                                 
DSP_DoCommand(d3): speaker off                                         
DSP_DoCommand(40): set time constant=d3                                 
DSP_DoCommand(d1): speaker on                                           
VDMA.WritePage(0x83 [chn=1], 3)                                         
VDMA.WriteIdxCnt: 16bit=0, Base=0 CurPos/MaxPos=0/0 Reg[0]=0           
VDMA.WriteIdxCnt: 16bit=0, Base=0 CurPos/MaxPos=0/6c6e Reg[1]=6c6e     
DSP_DoCommand(14): single cycle, length=27758 (0x6c6e), Rate=0, started
^C


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

> Hi Japheth, I have a X-Fi Titanium PCI-e. I can help with tests if needed

Ok, there's now a first version for tests available.

Don't expect that you'll hear sound - currently it's just the init phase that should be "survived".

Non-Titanium X-Fi cards are also supported - this has been tested already.

Currently I/O instructions are used to access the card - the ALSA driver for X-Fi Titanium uses memory-mapped I/O instead. I don't know if the first access method is supported at all for Titanium.

https://github.com/Baron-von-Riedesel/VSBHDA/issues/107

---
MS-DOS forever!

> I run another quick test and collect just text
> output on the screen if it helps ...
> ... so seems IRQ was not fired)

Agreed. I checked the source and compared it with current ALSA, and there's indeed the most important register not set. Please try the updated debug variant:

https://github.com/Baron-von-Riedesel/VSBHDA/issues/45

---
MS-DOS forever!