DOS ain't dead

Jemm386 5.86 is not yet officialy released but Japheth has in on his Github as prerelease version.
The very interresting point is the extension of the SB parameter.
I have SBLive card and I use the Creative's emulation driver and in the past everything worked great. But I uset it not so often because this machine I use mainly for development and work and for gaming I use rather another one with ISA slots and with SB AWE64.
So, I do not know why exactly the SB emulation stopped to work. It might be after some hardware changes or after some change in Jemm386.
I solved it with VSHBHA but it sometimes does not work so good as Creative's driver.
But fortunately, with Jemm386 5.86 it works again!
I don't know whether this is specific for my machine and my configuration but I suppose not - it is relevant for many people with SBLive card.

---
DOS-u-akbar!

> Jemm386 5.86 is great!
> The very interresting point is the extension of the SB parameter.

Thanks for your enthusiasm! However, if I may cite myself ( it's a reply to an issue in jemm github ):

But actually, this isn't really a new feature. Support for SB(E)INIT was removed in v5.85, because it seemed to be unstable and I also somewhat assumed that this driver has become obsolete with sbemu/vsbhda. Realizing that this was untrue ( the driver is still preferable for Pentium-class machines ), I just reintegrated the functionality by extending the SB option.

So the SB thing is more or less just a fix of a regression.

Btw, this is what I have found out about the SB emulation drivers:

- they need an XMS block with a physical address below 0x400000.
- they expect the EMM to have mapped this block "identical" ( physical == linear address ).
- they disable paging temporarily (I assume that's the easiest way to modify page tables of the EMM - which is needed to store the synthesizer data )
- they modify the EMM's IDT entries 0x01, 0x02 and 0x67 ( SBINIT.COM also 0x03 )
- they grab the EMM's last 3 GDT entries.
- they don't touch the IO permission bitmap - the SB and DMA ports a trapped by hardware ( with the help of INT 0x02 [NMI] ). This must be supported by the MB chipset!
- they use IO watchpoints to trap PIC ports 0x20 and 0xA0. Hence the drivers need at least a Pentium.
- the modified IDT vector 0x67 enables the driver to intercept int 67h, ax=DE01h and ax=DE0C. This makes it possible to intrude into any VCPI client's address space and IDT.

---
MS-DOS forever!

Yes, original Creative emu drivers are useless on newer machines. Last time (maybe 10+ yrs ago) I wrote an utility that enabled NMI to SERR routing in intel chipset that makes it work on some MBs but anything with core Nehalem and later is no go.

But for older computers one may prefer Creative driver because it supports wavetable midi music by loading original soundfont file. VSBHDA don't. Or has it changed? I only saw some fork of VSBHDASF: https://www.vogons.org/viewtopic.php?t=104645 Could it be merged?

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

> But for older computers one may prefer Creative driver because it supports
> wavetable midi music by loading original soundfont file. VSBHDA don't. Or
> has it changed? I only saw some fork of VSBHDASF:

It has changed - stole that nice feature from vsbhdasf; happened for v1.7 already.

---
MS-DOS forever!

> - they need an XMS block with a physical address below 0x400000.

Yes, the need of free memory block bellow 0x400000 is a problem because I use a disk cache and various TSRs and this memory is normally occupied.
So I use this trick.
In CONFIG.SYS:
device=tdsk.exe 8192
...disk cache driver...

In AUTOEXEC.BAT:
tdsk.exe 0
join f: c:\freedos\join_f

TDSK.EXE is a resizable ramdisk Turbo Disk.
It works perfectly but it is a bit complicated. Does exist some more elegant solution?

---
DOS-u-akbar!

> It has changed - stole that nice feature from vsbhdasf; happened for v1.7
> already.

To extend the praise:
I recently dug out a Celeron 600 based POS system I bought some years ago for ~30EUR. It runs Win98 w/ the option to boot into plain DOS 7.
I used it to demo DOjS on several occasions.

I had a really hard time to find some drivers for Win98 for that machine, but it wasn't really usable as a DOS gaming machine because of missing sound support.

Tried VSBHDA out of a hunch and now I have one another capable and compact DOS PC...
Only thing left to look into why E1000PKT hangs when VSBHDA is loaded. But that is for another day

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> It works perfectly but it is a bit complicated. Does exist some more elegant solution?

You can try xmsres.exe, supplied with vsbhda. I use it to make smartdrv.exe allocate its xms block at the highest possible address. In config.sys:

INSTALL=C:\VSBHDA\XMSRES.EXE -h 8
INSTALL=C:\DOS\SMARTDRV.EXE 8192
INSTALL=C:\VSBHDA\XMSRES.EXE -u

---
MS-DOS forever!

> It has changed - stole that nice feature from vsbhdasf; happened for v1.7
> already.

Aha, nice, I tried it and it works with 4M SF2 bank. So I can uninstall one more obsolete fork vsbhdasf...

Please could you also include fix for SB detection in Dynablaster game?
LINK REMOVED by rr (game starts but no sound at all)
Crazii fixed this for me some years ago in sbemu beta 2c.

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

> Please could you also include fix for SB detection in Dynablaster game?
> LINK REMOVED by rr (game starts but no sound at all)
> Crazii fixed this for me some years ago in sbemu beta 2c.

@RayeR Please respect forum rule #3 "No posts about or links to illegal content."

---
Forum admin

> Please could you also include fix for SB detection in Dynablaster game?

Hmm, the music is rather lame - IMO the game is better without sound ...

But besides the music quality there's no problem with sound on my machine.

edit: forgot to mention that I use the /CF1 cmdline option

---
MS-DOS forever!

> Hmm, the music is rather lame - IMO the game is better without sound ...
>

Sorry, my brain is permanently damaged after playing and listening this for many tens hours when I was young :)

> edit: forgot to mention that I use the /CF1 cmdline option

Nice, it plays now with /CF1 :)
Could it be possible to change this flags on the fly? Some other games may not like it so it would be nicer to change this via BAT file for specific game instead of having to reboot (as SBEMU/VSBHDA hangs when warm boot on my system I have to pass longer cold boot). Not sure if SBEMU has this option always enabled or uses it only in specific cases...

BTW Boost demo https://www.pouet.net/prod.php?which=6485 has better music but also don't play with SBEMU/VSBHDA, maybe some magic CFx would work? :)

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

> ... instead of having to reboot (as SBEMU/VSBHDA hangs when warm boot on

But vsbhda has the UNINST.EXE tool which should always work (if run from the command line).

> Boost demo https://www.pouet.net/prod.php?which=6485 has better music but also don't play with SBEMU/VSBHDA, maybe some magic CFx would work? :)

It's a pmode/w app - using OW's pmwsetup.exe tool may fix the issue: pmwsetup /M0 boost.exe

---
MS-DOS forever!

Thanks for pointing at UNINST.EXE it works, also solve fast boot problem when unloaded.
***
I tried to modify Boost demo with pmwsetup as you suggested and it almost works but with VSBHDA the sound has slight permanent stuttering, maybe a bit downtone while with SBEMU it plays smooth. I tried /CF1-8 and setpvi, just for a case, but no difference.
***
BTW dos4gw programs prefer VCPI or DPMI? How it changes things with SB emulation? Or is it specific just to programs with PMODE/W stub?
***
[br]<br>
BTW is is just me who see broken formatting of paragraphs without CRLF (break tag), just one huge ball of text (happened yesterday or a few days ago)?

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

> I tried to modify Boost demo with pmwsetup as you suggested and it almost
> works but with VSBHDA the sound has slight permanent stuttering, maybe a
> bit downtone while with SBEMU it plays smooth.

With HDA, it plays ok with vsbhda, while with sbemu sound "disappears" after 1/2 second playing ( and video rendering seems to enter a loop, so the demo won't finish ).

However, on another machine with a SB Live card there is some stuttering, compared to what is rendered in a Win9x DOS box. OTOH, with Creative's SBEINIT the demo just crashes.

> BTW dos4gw programs prefer VCPI or DPMI? How it changes things with SB
> emulation? Or is it specific just to programs with PMODE/W stub?

I remember CauseWay: as default, it prefers VCPI, but if environment variable CAUSEWAY contains DPMI, it changes its opinion.

---
MS-DOS forever!

> [br]<br>
> BTW is is just me who see broken formatting of paragraphs without CRLF
> (break tag), just one huge ball of text (happened yesterday or a few days
> ago)?

That's me, while trying to implement BBCode tags for unordered and ordered lists.

It's still WIP, because those regular expressions drive me crazy. Any regex experts here?

---
Forum admin

> However, on another machine with a SB Live card there is some stuttering,
> compared to what is rendered in a Win9x DOS box. OTOH, with Creative's
> SBEINIT the demo just crashes.

Did you tried SBEMU too? If you get smooth playback? So you can replicate the problem and have a chance to improve VSBHDA...

> I remember CauseWay: as default, it prefers VCPI, but if environment
> variable CAUSEWAY contains DPMI, it changes its opinion.

OK, also original CWSDPMI prefers VCPI over DPMI so I patched it some years ago. But it seems that some demos that use original cwsdpmi can play sound with VSBHDA/SBEMU even with preference of VCPI so I wonder why it is different in case of PMODE/W...

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

regexp? no, no ^_^

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

> OTOH, with Creative's SBEINIT the demo just crashes.
>
> Did you tried SBEMU too? If you get smooth playback? So you can replicate
> the problem and have a chance to improve VSBHDA...

SBEMU behaves as with HDA - sound stops after 1/2 second. I'm using a SBEMU binary from 29.4.2024, size 516096.

But I was able to run Boost with the Creative Driver SBEINIT.COM now ( by preloading hdpmi32 the demo no longer crashes ). Runs smooth...

The problem seems to be the value of the TIMER variable in the EMU10K1 - there's no documentation about it and hence it's initialized with a guessed value. VSBHDA initializes it with 0x1E0 ( copied that value from Win9x ), while SBEMU uses 0x1A. SBEINIT.COM doesn't set it at all!

You can experiment on your own. It's at offset 0x1A of EMU10K1's base address. On my system, that is 0xE400. So if I enter with DEBUG:

ow e41a 100

the demo sound significantly better with vsbhda on my "SB Live" machine (which is a P3 with 500 MHz)!

> But it seems that some demos that use original cwsdpmi can play sound
> with VSBHDA/SBEMU even with preference of VCPI so I wonder why it is
> different in case of PMODE/W...

Pretty unlikely, unless the programs use v86-mode for its sound code.

---
MS-DOS forever!

I experimented with Timer register value on my SB Audigy1.
PWR on default value is 0
VSBHDA sets 1E0h, SBEMU sets 1Ah, WinXP kX driver leaves 0.
So I tried to set 1Ah after VSBHDA loaded but still got stuttering, maybe a bit smaller. I have to lower the value to 1-3 to get smooth playback for Boost demo and value 1 for another demo Dream by Peon (compiled with DJGPP, probably more CPU intensive, https://www.pouet.net/prod.php?which=1110 ). Value 0 gives stuttering like other high values. So there must be dependency on something else. I dumped the regs with your SBLIVE.EXE tool and there are many more differences between VSBHDA and SBEMU initialisation values (I pressed the reset button between making second dump).
Here they are:
http://rayer.g6.cz/1tmp/vsbhda.txt
http://rayer.g6.cz/1tmp/sbemu.txt

BTW the Dream demo runs both with original CWSDPMI (prefers VCPI) and patched (prefers DPMI), also requires setpvi in my case...

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

> So I tried to set 1Ah after VSBHDA loaded but ...

Value 0x1A is inherited from mpxplay and has its origin in EMU10K1.H:

#define TIMER_RATE_MASK        0x000003ff
/* Timer interrupt rate in sample periods    */
/* 0 == 1024 periods, [1..4] are not useful    */
#define TIMER_RATE        0x0a00001a

Both use the TIMER_RATE value to write to the "timer" port. It's a dword, so outl() is used for writing. However, the port has WORD size only; at offset 0x1C there's the AC'97 data port, so the outl() writes 0xa00 to that port, which seems pretty hazardous and "buggy" to me (constant TIMER_RATE has vanished in current emu10k1.h in Linux ).

> I have to lower the value to 1-3 to get smooth playback for
> Boost demo and value 1 for another demo Dream by Peon (compiled with DJGPP,

As you can see from the comment in emu10k1.h, those values are "not useful".


> I dumped the regs with your SBLIVE.EXE tool
> and there are many more differences between VSBHDA and SBEMU initialisation
> values

Yes. There's a bug in sbemu, however, making it skip every second entry in the microcode array during initialization ( each entry is 64-bit ).

> (I pressed the reset button between making second dump).

I've got the impression that most EMU10K1 register values are not affected by reset, and there's no software reset either...

---
MS-DOS forever!

I made new dump that was done after power on, loading MS-DOS an loading the emu. Then power off and again. There a bit less differences now.
http://rayer.g6.cz/1tmp/vsbhda.txt
http://rayer.g6.cz/1tmp/sbemu.txt

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

> I experimented with Timer register value on my SB Audigy1.
> I have to lower the value to 1-3 to get smooth playback for Boost demo

I noticed that values 1-3 make vsbhda render the sound "faster" ( higher pitch ). It's easier to detect by comparison if you run a sample with speech...

Btw, the Boost demo renders sound with 44.1 kHz, 16-bit, stereo if a SB16 is detected.

Another btw: no need for register dumps. If I'm going to fix this issue, it will be by getting rid of the TIMER usage alltogether.

---
MS-DOS forever!