crazii wrote on 2023-02-28, 16:53:

Update:
1. added option /k to set sample rate. /k22050 or /k44100, default 22050

Thank you for adding /K option. This (28-Feb) version seems most stable by far on Intel High Def. audio. I noticed sample rate of 44.1khz works well, however, you were wise to not make it default, since original SB / SB Pro is limited to 22050 hz.

In my testing (HDA sound), now it is GREAT to be able to change settings "on the fly" with SBEMU. However, when changing th sample rate "on the fly" from 44100 to 22050, this results in silencing the output in the games I tested (real-mode games) ; strangely both OPL *and* digital audio go away when changing /K44100 to /K22050 "on the fly" without rebooting. The problem is easily rectified by simply rebooting and running SBEMU with /T1 or /T5 (and /K22050 default setting).

However, this is minor as the main news is that /K44100 does now work in playing .FLACs, .MODs, and .WAVs from CDs at the proper sample rate and fidelity -- and the quality is outstanding. The modern PCI onboard sound cards like HDA do not have the analogue noise issues that the old ISA cards did (they have better digital to analogue conversion and less distortion), so SBEMU is such a blessing, for it now enables to play high-fidelity 16-bit stereo audio in DOS with even better fidelity than these old, noisy DOS ISA cards did.

So, I'm glad to reboot the machine if I need to switch back to 22050 internal sampling rate for SB / SB Pro emulation instead.

Incidently, the DOS emulators I've tried so far work wonderfully with SBEMU. This includes Nesticle, ROCKNES, z26, ZSNES, PC Atari Emulator, ColEm, Mame. It is great to play "Super Mario Bros 3", "Galaga", "Prince of Persia" for NES, or Doom or "Ms. Pac Man" for SNES in (protected mode) DOS with full, wonderful, emulated digital sound. It is a fantastic result.

Only problem remaining for me on HDA is that many Real Mode games still produce only 1-2 seconds of (fast) digital audio, with perfect OPL sound, then cut out entirely with Digital audio, but not OPL. Nothing I've been able to do to rectify this with SBEMU settings alone. Some real mode games do this, some don't: Apogee games do, many others have perfect audio. I still couldn't get MDK to work with sound, either.

I should compile a list of working and non-working games (on HDA sound) and comments, if it would help others at all for troubleshooting.

zyzzle wrote on 2023-02-24, 03:08:

Except the three I (still) play the most after 30 years: NFS, Screamer, Screamer2, and Screamer Rally. That's OK, I'm super-happy *and* appreciative that you've worked on this project and have such a fantastic success rate so far.

I tested NFS, and found it prefers VCPI over DPMI and thus no io trapping occurs.

You need load JEMMEX.EXE in you config.sys before JEMM386.EXE
and then in autoexec.bat, AFTER hdpmi is loaded, run "JEMMEX.EXE NOVCPI"

This will disable vcpi and force NFS to use HDPMI.
as I tested, it will make NFS with sounds.
You can test Screamer series if they're with the same issue.

EDIT: I tested Screamer and it has sounds.

zyzzle wrote on 2023-03-02, 03:04:

Thank you for adding /K option. This (28-Feb) version seems most stable by far on Intel High Def. audio. I noticed sample rate o […]
Show full quote

crazii wrote on 2023-02-28, 16:53:

Update:
1. added option /k to set sample rate. /k22050 or /k44100, default 22050

Thank you for adding /K option. This (28-Feb) version seems most stable by far on Intel High Def. audio. I noticed sample rate of 44.1khz works well, however, you were wise to not make it default, since original SB / SB Pro is limited to 22050 hz.

In my testing (HDA sound), now it is GREAT to be able to change settings "on the fly" with SBEMU. However, when changing th sample rate "on the fly" from 44100 to 22050, this results in silencing the output in the games I tested (real-mode games) ; strangely both OPL *and* digital audio go away when changing /K44100 to /K22050 "on the fly" without rebooting. The problem is easily rectified by simply rebooting and running SBEMU with /T1 or /T5 (and /K22050 default setting).

However, this is minor as the main news is that /K44100 does now work in playing .FLACs, .MODs, and .WAVs from CDs at the proper sample rate and fidelity -- and the quality is outstanding. The modern PCI onboard sound cards like HDA do not have the analogue noise issues that the old ISA cards did (they have better digital to analogue conversion and less distortion), so SBEMU is such a blessing, for it now enables to play high-fidelity 16-bit stereo audio in DOS with even better fidelity than these old, noisy DOS ISA cards did.

So, I'm glad to reboot the machine if I need to switch back to 22050 internal sampling rate for SB / SB Pro emulation instead.

Incidently, the DOS emulators I've tried so far work wonderfully with SBEMU. This includes Nesticle, ROCKNES, z26, ZSNES, PC Atari Emulator, ColEm, Mame. It is great to play "Super Mario Bros 3", "Galaga", "Prince of Persia" for NES, or Doom or "Ms. Pac Man" for SNES in (protected mode) DOS with full, wonderful, emulated digital sound. It is a fantastic result.

Only problem remaining for me on HDA is that many Real Mode games still produce only 1-2 seconds of (fast) digital audio, with perfect OPL sound, then cut out entirely with Digital audio, but not OPL. Nothing I've been able to do to rectify this with SBEMU settings alone. Some real mode games do this, some don't: Apogee games do, many others have perfect audio. I still couldn't get MDK to work with sound, either.

I should compile a list of working and non-working games (on HDA sound) and comments, if it would help others at all for troubleshooting.

OK, I tested 44100 works and I never switch back and test again 🤣, the bug will be fixed in next release.
I also fixed some sped up issue but not sure if it related to your games, you can test on next release.

crazii wrote on 2023-03-02, 01:43:

digger wrote on 2023-03-01, 22:40:

"You can't use this to make a clone of certain other software" is an additional restriction that the GPL doesn't have, and therefore make DOSBox sources and Mpxplay sources incompatible with one and other.

OK, I didn't know DOSBox has such restriction, Does that makes DOSBox source code not reusable for any purpose? Even the clone of DOSBox, like DOSBox-X or DOSBox-SVN-Daum are not permitted?
Use another sound card driver can be done but it is expensive, meaning starting over and testing again for every games, I'm not ready to do this. I think use another OPL emulation code might be more easy.

Hi,
I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thus DosBox code has NO such restriction. But GPL/DosBox code has a restriction that it cannot be used together with more restrictive other codes (such as mpxplay's more restrictive code).

The Nuked OPL3 emulation library is less restrictive than DosBox OPL emulation towards more restrictive codes 😀
Nuked OPL3 is LGPL which allows the library to be linked to even closed source projects.
https://github.com/nukeykt/Nuked-OPL3/blob/master/LICENSE

BTW, Nuked OPL3 is currently considered to be the most precise OPL emulation library.

crazii wrote on 2023-03-01, 09:14:

The most possible reason is that the interrupt is not enabled. I'll check what I can do.

Hello,

I'm also interested in the SBLive/Audigy working with SBEMU - and I also have such hardware available to test.

However, is there any good documentation available, a programming model for the SBLive? It seems a bit tiresome if the only "docs" to use are the - mostly uncommented - mpxplay and alsa source codes.

As an example, I found this in the current sbemu source:

1 emu10k1_writeptr(card, INTE, channel,  emu10k1_readptr(card, INTE, channel)|INTE_FXDSPENABLE);

But shouldn't it be like this instead:?

1 emu10k1_writefn0(card, INTE,  INTE_FXDSPENABLE); 

having to make "wild guesses" is not very promising...

Baron von Riedesel wrote on 2023-03-02, 08:18:

Hello, […]
Show full quote

crazii wrote on 2023-03-01, 09:14:

The most possible reason is that the interrupt is not enabled. I'll check what I can do.

Hello,

I'm also interested in the SBLive/Audigy working with SBEMU - and I also have such harware available to test.

However, is there any good documentation available, a programming model for the SBLive. It seems a bit tiresome if the only "docs" to use are the - mostly uncommented - mpxplay and alsa source codes.

As an example, I found this in the current sbemu source:

Copy code to clipboard

1 emu10k1_writeptr(card, INTE, channel,  emu10k1_readptr(card, INTE, channel)|INTE_FXDSPENABLE);

But shouldn't it be instead:?

Copy code to clipboard

1 emu10k1_writefn0(card, INTE,  INTE_FXDSPENABLE); 

having to make "wild guesses" is not very promising...

No, I searched on the web for multiple times and nothing useful found related to the emu10k1 chip, no specs, no datasheets. The only ones are from ALSA / linux kernel / emu10k1 project on source forge, which all uses the same header, Otherwise I wouldn't do it this way. 🤣 It's not an open spec like AC97 anyway.

Yes, it is a problem I didn't read the code much, do you have any improvements after change this?

I know that this is Windows(tm) specific, but maybe ? https://github.com/kxproject/kx-audio-driver
also
https://github.com/kxproject/kX-Audio-driver-Documentation

zyga64 wrote on 2023-03-02, 10:40:

I know that this is Windows(tm) specific, but maybe ? https://github.com/kxproject/kx-audio-driver
also
https://github.com/kxproject/kX-Audio-driver-Documentation

Checked the source code, still the same. the docs contains a emu10k1 PDF which is not quite useful and also can be found in the ALSA open docs.

crazii wrote on 2023-03-02, 09:43:

do you have any improvements after change this?

Well, what I finally did: insert a display in the ISR, install sbemu and then write - with good old DEBUG - values to the "interrupt enable register" ( offset 0x00C ) until I got messages onto the screen. Seems that bit 2 of INTE must be set to get periodic interrupts ... 😀

UPDATE:
1.fix SB16 mixer volume bug
2.fix mono/stereo bug that cause playback sped up.
3.work around Miles Sound freeze/ring0 fault on detection SB when emulated SBPro(/T5) and Miles Sound uses SB driver instead of SBPro. - didn't find the reason, just pure workaround.
4.fix /k (sample rate) switch bug
5.tiny changes on HDPMI to make MDK keyboard work.
6. SBLive/Audigy bugfix and test (WIP)

Note: Some DOS/4GW games (like NFS) prefer VCPI over DPMI, you might run "JEMMEX NOVCPI" after loading HDPMI.

Baron von Riedesel wrote on 2023-03-02, 12:23:

crazii wrote on 2023-03-02, 09:43:

do you have any improvements after change this?

Well, what I finally did: insert a display in the ISR, install sbemu and then write - with good old DEBUG - values to the "interrupt enable register" ( offset 0x00C ) until I got messages onto the screen. Seems that bit 2 of INTE must be set to get periodic interrupts ... 😀

Good!
I think it'd be tested out but I don't have any HW to test with.

But the header says "Timer interrupt", it's periodical but not based on the input buffer, the one that I was going to try but not did yet. 🤣
EDIT: there's also a register (0x1A or 0x0A00001A) to configure timer interval but the comment is unclear.

Here's the code if it helps

1#define INTE_INTERVALTIMERENB    0x00000004    /* Enable interval timer interrupts        */
2
3#define TIMER            0x1a        /* Timer terminal count register        */
4                        /* NOTE: After the rate is changed, a maximum    */
5                        /* of 1024 sample periods should be allowed    */
6                        /* before the new rate is guaranteed accurate.    */
7#define TIMER_RATE_MASK        0x000003ff    /* Timer interrupt rate in sample periods    */
8                        /* 0 == 1024 periods, [1..4] are not useful    */
9#define TIMER_RATE        0x0a00001a

BTW The ICH & HDA are configured that each interrupt happens on each "period", one period is about 512 bytes buffer (can be changed).

Falcosoft wrote on 2023-03-02, 07:27:

Hi, I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thu […]
Show full quote

crazii wrote on 2023-03-02, 01:43:

digger wrote on 2023-03-01, 22:40:

"You can't use this to make a clone of certain other software" is an additional restriction that the GPL doesn't have, and therefore make DOSBox sources and Mpxplay sources incompatible with one and other.

OK, I didn't know DOSBox has such restriction, Does that makes DOSBox source code not reusable for any purpose? Even the clone of DOSBox, like DOSBox-X or DOSBox-SVN-Daum are not permitted?
Use another sound card driver can be done but it is expensive, meaning starting over and testing again for every games, I'm not ready to do this. I think use another OPL emulation code might be more easy.

Hi,
I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thus DosBox code has NO such restriction. But GPL/DosBox code has a restriction that it cannot be used together with more restrictive other codes (such as mpxplay's more restrictive code).

The Nuked OPL3 emulation library is less restrictive than DosBox OPL emulation towards more restrictive codes 😀
Nuked OPL3 is LGPL which allows the library to be linked to even closed source projects.
https://github.com/nukeykt/Nuked-OPL3/blob/master/LICENSE

BTW, Nuked OPL3 is currently considered to be the most precise OPL emulation library.

Thanks for clarifying my earlier reply.

Note however, that LGPL code may be combined with GPL-incompatible code only when linked as a dynamic library. (Having the emulation cores be loadable modules would also be nice from a technical perspective, since it would make it easier to swap them out and to add support for addional emulated sound cards and such, but I believe that such a structure would still require some refactoring of SBEMU in its current form.)

A BSD-licensed alternative for OPL3 emulation that was mentioned in this thread earlier is ymfm. BSD-licensed code can be combined with more restrictive sources.

https://github.com/aaronsgiles/ymfm

digger wrote on 2023-03-02, 13:11:

Thanks for clarifying my earlier reply. […]
Show full quote

Falcosoft wrote on 2023-03-02, 07:27:

Hi, I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thu […]
Show full quote

crazii wrote on 2023-03-02, 01:43:

OK, I didn't know DOSBox has such restriction, Does that makes DOSBox source code not reusable for any purpose? Even the clone of DOSBox, like DOSBox-X or DOSBox-SVN-Daum are not permitted?
Use another sound card driver can be done but it is expensive, meaning starting over and testing again for every games, I'm not ready to do this. I think use another OPL emulation code might be more easy.

Hi,
I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thus DosBox code has NO such restriction. But GPL/DosBox code has a restriction that it cannot be used together with more restrictive other codes (such as mpxplay's more restrictive code).

The Nuked OPL3 emulation library is less restrictive than DosBox OPL emulation towards more restrictive codes 😀
Nuked OPL3 is LGPL which allows the library to be linked to even closed source projects.
https://github.com/nukeykt/Nuked-OPL3/blob/master/LICENSE

BTW, Nuked OPL3 is currently considered to be the most precise OPL emulation library.

Thanks for clarifying my earlier reply.

Note however, that LGPL code may be combined with GPL-incompatible code only when linked as a dynamic library. (Having the emulation cores be loadable modules would also be nice from a technical perspective, since it would make it easier to swap them out and to add support for addional emulated sound cards and such, but I believe that such a structure would still require some refactoring of SBEMU in its current form.)

A BSD-licensed alternative for OPL3 emulation that was mentioned in this thread earlier is ymfm. BSD-licensed code can be combined with more restrictive sources.

https://github.com/aaronsgiles/ymfm

I'll ask the author of MPXPlay again to make sure he can changes the license of drivers to GPL 🤣

crazii wrote on 2023-03-02, 13:24:

digger wrote on 2023-03-02, 13:11:

Thanks for clarifying my earlier reply. […]
Show full quote

Falcosoft wrote on 2023-03-02, 07:27:

Hi, I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thu […]
Show full quote

Hi,
I think you misunderstood what digger wrote. The quote in his text referred to mpxplay and digger suggests that GPL and thus DosBox code has NO such restriction. But GPL/DosBox code has a restriction that it cannot be used together with more restrictive other codes (such as mpxplay's more restrictive code).

The Nuked OPL3 emulation library is less restrictive than DosBox OPL emulation towards more restrictive codes 😀
Nuked OPL3 is LGPL which allows the library to be linked to even closed source projects.
https://github.com/nukeykt/Nuked-OPL3/blob/master/LICENSE

BTW, Nuked OPL3 is currently considered to be the most precise OPL emulation library.

Thanks for clarifying my earlier reply.

Note however, that LGPL code may be combined with GPL-incompatible code only when linked as a dynamic library. (Having the emulation cores be loadable modules would also be nice from a technical perspective, since it would make it easier to swap them out and to add support for addional emulated sound cards and such, but I believe that such a structure would still require some refactoring of SBEMU in its current form.)

A BSD-licensed alternative for OPL3 emulation that was mentioned in this thread earlier is ymfm. BSD-licensed code can be combined with more restrictive sources.

https://github.com/aaronsgiles/ymfm

I'll ask the author of MPXPlay again to make sure he can changes the license of drivers to GPL 🤣

It's interesting that MpxPlay's SBLive/Audigy related code contains GPL code 😀. So actually MpxPlay cannot restrict its code to be more restrictive than GPL. I would say that this way MpxPlay's code cannot be other than GPL compatible.
EMU10K1.H from MpxPlay's source package:

fndef __SOUND_EMU10K1_H #define __SOUND_EMU10K1_H […]
Show full quote

fndef __SOUND_EMU10K1_H
#define __SOUND_EMU10K1_H

/*
* Copyright (c) by Jaroslav Kysela <perex@suse.cz>,
* Creative Labs, Inc.
* Definitions for EMU10K1 (SB Live!) chips
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/

Falcosoft wrote on 2023-03-02, 14:03:

It's interesting that MpxPlay's SBLive/Audigy related code contains GPL code :). So actually MpxPlay cannot restrict its code to […]
Show full quote

crazii wrote on 2023-03-02, 13:24:

digger wrote on 2023-03-02, 13:11:

Thanks for clarifying my earlier reply. […]
Show full quote

Thanks for clarifying my earlier reply.

Note however, that LGPL code may be combined with GPL-incompatible code only when linked as a dynamic library. (Having the emulation cores be loadable modules would also be nice from a technical perspective, since it would make it easier to swap them out and to add support for addional emulated sound cards and such, but I believe that such a structure would still require some refactoring of SBEMU in its current form.)

A BSD-licensed alternative for OPL3 emulation that was mentioned in this thread earlier is ymfm. BSD-licensed code can be combined with more restrictive sources.

https://github.com/aaronsgiles/ymfm

I'll ask the author of MPXPlay again to make sure he can changes the license of drivers to GPL 🤣

It's interesting that MpxPlay's SBLive/Audigy related code contains GPL code 😀. So actually MpxPlay cannot restrict its code to be more restrictive than GPL. I would say that this way MpxPlay's code cannot be other than GPL compatible.
EMU10K1.H from MpxPlay's source package:

fndef __SOUND_EMU10K1_H #define __SOUND_EMU10K1_H […]
Show full quote

fndef __SOUND_EMU10K1_H
#define __SOUND_EMU10K1_H

/*
* Copyright (c) by Jaroslav Kysela <perex@suse.cz>,
* Creative Labs, Inc.
* Definitions for EMU10K1 (SB Live!) chips
*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
*/

That's good news. 🤣
Have you tested the latest release? I can modify the code again to test... 🤣

crazii wrote on 2023-03-02, 03:44:

I tested NFS, and found it prefers VCPI over DPMI and thus no io trapping occurs. […]
Show full quote

I tested NFS, and found it prefers VCPI over DPMI and thus no io trapping occurs.

You need load JEMMEX.EXE in you config.sys before JEMM386.EXE
and then in autoexec.bat, AFTER hdpmi is loaded, run "JEMMEX.EXE NOVCPI"

EDIT: I tested Screamer and it has sounds.

I tried this, but am a little confused. I think you meant to say JEMMEX should be loaded before HDPMI32 and, once HDPMI32 is loaded, run JEMMEX again from commandline with the NOVCPI switch.

(You can't run JEMMEX *and* JEMM386 both at the same time, can you? Says JEMMEX already loaded when I try to load JEMM386 as well)

Anyway, my sequence was:
1. DEVICE=JEMMEX.EXE in CONFIG.SYS
2. load HDPMI32 from commandline with switches /X /R
3. from commandline JEMMEX NOVCPI. Output from JEMMEX = "settings passed to JEMMEX configuration".
4. load SBEMU with options /T6 /O1 /rm0 /K44100

Then load NFS executable bound with DOS4GW.EXE .

and got sound working in NFS very, very unstable. It worked with SB16 sound for anywhere from 1 to 60 seconds before HARD crashing the system. A few times crashed with Ring 0 errors in HDPMI32, a few times just hard crash, other times with strange error messages from the NFS.EXE file. NFS also had some keyboard problems, when I was able to play it with sound (about 1 out of every 5 attempts, again with exact same sequence above). When these keyboard 'randomness happened', NFS hard crashed within a few seconds these keyboard problems started. NFS never worked with SB or SB Pro sound -- hard crash every time.

I must be doing something wrong. May you give your exact CONFIG.SYS and AUTOEXEC.BAT so that I might replicate your DOS config as closely as possible?

I couldn't get Screamer working at all, even following exact same sequence above. Same behavior as other previous SBEMU versions. Configures OK, SB16 detected, in setup program, sound plays well in setup program. When starting SCREAM.EXE DOS4gw banner comes up, screen goes blank, hard freeze, hard reboot required. The end... Repeat.

crazii wrote on 2023-03-02, 14:26:

That's good news. 🤣
Have you tested the latest release? I can modify the code again to test... 🤣

I have just tested it. No difference compared to the previous version.

zyzzle wrote on 2023-03-02, 14:28:

I tried this, but am a little confused. I think you meant to say JEMMEX should be loaded before HDPMI32 and, once HDPMI32 is loa […]
Show full quote

crazii wrote on 2023-03-02, 03:44:

I tested NFS, and found it prefers VCPI over DPMI and thus no io trapping occurs. […]
Show full quote

I tested NFS, and found it prefers VCPI over DPMI and thus no io trapping occurs.

You need load JEMMEX.EXE in you config.sys before JEMM386.EXE
and then in autoexec.bat, AFTER hdpmi is loaded, run "JEMMEX.EXE NOVCPI"

EDIT: I tested Screamer and it has sounds.

I tried this, but am a little confused. I think you meant to say JEMMEX should be loaded before HDPMI32 and, once HDPMI32 is loaded, run JEMMEX again from commandline with the NOVCPI switch.

(You can't run JEMMEX *and* JEMM386 both at the same time, can you? Says JEMMEX already loaded when I try to load JEMM386 as well)

Anyway, my sequence was:
1. DEVICE=JEMMEX.EXE in CONFIG.SYS
2. load HDPMI32 from commandline with switches /X /R
3. from commandline JEMMEX NOVCPI. Output from JEMMEX = "settings passed to JEMMEX configuration".
4. load SBEMU with options /T6 /O1 /rm0 /K44100

Then load NFS executable bound with DOS4GW.EXE .

and got sound working in NFS very, very unstable. It worked with SB16 sound for anywhere from 1 to 60 seconds before HARD crashing the system. A few times crashed with Ring 0 errors in HDPMI32, a few times just hard crash, other times with strange error messages from the NFS.EXE file. NFS also had some keyboard problems, when I was able to play it with sound (about 1 out of every 5 attempts, again with exact same sequence above). When these keyboard 'randomness happened', NFS hard crashed within a few seconds these keyboard problems started. NFS never worked with SB or SB Pro sound -- hard crash every time.

I must be doing something wrong. May you give your exact CONFIG.SYS and AUTOEXEC.BAT so that I might replicate your DOS config as closely as possible?

I couldn't get Screamer working at all, even following exact same sequence above. Same behavior as other previous SBEMU versions. Configures OK, SB16 detected, in setup program, sound plays well in setup program. When starting SCREAM.EXE DOS4gw banner comes up, screen goes blank, hard freeze, hard reboot required. The end... Repeat.

You have the same config.sys and autoexec as mine, I don't know what the problem is, I just simply test it in virtualbox, enter games, enter race, and exit, maybe it do have some problems, it's really bad news.
1.config.sys: DEVICE=JEMMEX.EXE
2.autoexec.bat: HDPMI32i.EXE -x -r
JEMMEX.EXE NOVCPI
3.commandline: SBEMU.EXE
4.commandline: TNFS SB

EDIT: I tried NFS more times and it has problems, but problems I've never seen before, not sure I can fix this but I'll try first.

Falcosoft wrote on 2023-03-02, 14:35:

crazii wrote on 2023-03-02, 14:26:

That's good news. 🤣
Have you tested the latest release? I can modify the code again to test... 🤣

I have just tested it. No difference compared to the previous version.

I've enable the half loop interrupt, last time tried period interrupt it seems doesn't have one.
zip updated in here:
Re: Possibility to write OPL3 sound driver for protected mode games

crazii wrote on 2023-03-03, 03:15:

I've enable the half loop interrupt, last time tried period interrupt it seems doesn't have one.

Since I have a good test environment, I played with the SBLive support and got it working - well, kind of...

I used the simple periodic timer interrupt, though, no "loop" or "half-loop" interrupt. It works pretty well, frequency seems to be ~ 50 Hz.

Most importantly, there's a bug in sc_sbliv.c, funcion snd_emu10kx_buffer_init().
Problem is that djgpp doesn't provide a true zero-based flat model and the macro "pds_cardmem_physicalptr()" cannot always hide this entirely:
Here's my modifcation:

1	pcmbufp=(uint32_t)card->pcmout_buffer;
2	//pcmbufp<<=1;
3	for(pagecount = 0; pagecount < (card->pcmout_bufsize/EMUPAGESIZE); pagecount++){
4		//card->virtualpagetable[pagecount] = pcmbufp | pagecount;
5		//card->virtualpagetable[pagecount] = (uint32_t)pds_cardmem_physicalptr(card->dm,pcmbufp) | pagecount;
6		card->virtualpagetable[pagecount] = ((uint32_t)pds_cardmem_physicalptr(card->dm,pcmbufp)<<1) | pagecount;
7		//dbgprintf("snd_emu10kx_buffer_init: %u: %X\n", pagecount, card->virtualpagetable[pagecount] );
8		//pcmbufp+=EMUPAGESIZE*2;
9		pcmbufp+=EMUPAGESIZE;
10	}

Second, the timer interrupt has to be "acknowledged":

1#ifdef SBEMU
2static int snd_emu_10kx_isr(struct emu10k1_card *card)
3{
4	int interrupts = inl(card->iobase + IPR) & IPR_INTERVALTIMER;
5	if ( interrupts )
6		emu10k1_writefn0(card, IPR, IPR_INTERVALTIMER );
7	return interrupts;
8}
9#endif

Well, it "kind of" works, there are - at least - 2 issues as of yet
- the volume is rather low, I have to call creative's mixerset tool to change the master vol.
- doom/doom2 do have problems with SFX - it's "distorted" and has "echos". DOOM "MBF" has no such problems...