Dossound shows nambar, I used these values for SBEMU.

Its a programmable number, we dont know its same in both cases

AC97TEST 2800 76 400 => value is accepted sound still muted
AC97TEST 2400 76 400 => value is rejected was ffff and stays ffff

allregs 24D5 8086 follows!

dr.zeissler wrote on 2023-10-03, 15:16:

Dossound shows nambar, I used these values for SBEMU.

Please stop using DOSSound for debugging an SBEMU issue. It doesn't have source available, is a separate program and cannot be used with SBEMU, anyway. It just complicates debugging and increases the search space, and trying to read values from it might be misleading or error-prone (it might also be that it returns the same values that happen to be assigned by the BIOS, and SBEMU also uses that, but that's already a few assumptions made that are hard to verify, and if the assumptions don't hold, we're trying perfectly valid "solutions" on the wrong registers/addresses, and then of course it doesn't work..).

Also, don't start DOSSound when running SBEMU or testing these things. Do a fresh cold reboot, then start SBEMU, then run the tool. Loading DOSSound or (in theory) even warm booting after playing around with DOSSound could interfere with the card settings.

dr.zeissler wrote on 2023-10-03, 16:52:

AC97TEST 2800 76 400 => value is accepted sound still muted

What is the default value (after a cold reboot and starting SBEMU, but not running anything else), i.e. what does this output:

1AC97TEST 2800 76

After you have recorded and reported the initial register value, try 420 and 20, too (and zero for good measure).

1AC97TEST 2800 76 420
2AC97TEST 2800 76 20
3AC97TEST 2800 76 0

As for the working Linux support - that's great! Kernel sources are here: https://github.com/torvalds/linux/tree/v2.6.12

In there, you will find the AD1980 patch function:

https://github.com/torvalds/linux/blob/9ee1c9 … 7_patch.c#L1466

Please don't use DOSSound to debug an SBEMU issue.

This in turn calls patch_ad1888(), which has:

1	/* Switch FRONT/SURROUND LINE-OUT/HP-OUT default connection */
2	/* it seems that most vendors connect line-out connector to headphone out of AC'97 */
3	/* AD-compatible mode */
4	/* Stereo mutes enabled */
5	misc = snd_ac97_read(ac97, AC97_AD_MISC);
6	snd_ac97_write_cache(ac97, AC97_AD_MISC, misc |
7			     AC97_AD198X_LOSEL |
8			     AC97_AD198X_HPSEL |
9			     AC97_AD198X_MSPLT |
10			     AC97_AD198X_AC97NC);

So in addition to setting LOSEL (0x0020) and HPSEL (0x0400), it also sets MSPLT (0x2000) and AC97NC (0x4000). The data sheet says MSPLT is "Mute Split", and AC97NC is "AC'97 No Compatibility Mode" (see the data sheet for explanations, "Mute Split" probably isn't relevant, but AC97NC might be). In that case, the value to try would be 6420 (or 4420 without Mute Split):

1AC97TEST 2800 76 6420

Ideally try all those settings after a fresh (cold) reboot, with only SBEMU loaded and then the command applied (then play sound using any known-working game/app that uses Sound Blaster.

You should not use DOSSound for debugging an SBEMU issue.

There's some other patches and overrides in the Linux kernel for AD1980, but maybe that single register is enough.

What does "cat /proc/ioports" output when running on Linux 2.6.x? Not implying that any mappings there would be the same as under DOS, but just to check how Linux "sees" the I/O mapping, and if the sound driver takes ownership of the I/O ranges). Also, can you post the output of "lspci -nn"?

Also, please don't use DOSSound for debugging an SBEMU issue.

Here's a SBEMU build with MPXPLAY_USE_DEBUGF defined to 1 in mpxplay/au_cards/sc_ich.c, which means it should print some useful information, including NABMBAR.

Source code is this branch https://github.com/thp/sbemu/tree/linux-cross with the following patch applied:

1diff --git a/mpxplay/au_cards/sc_ich.c b/mpxplay/au_cards/sc_ich.c
2index 0df0f76..45d408e 100644
3--- a/mpxplay/au_cards/sc_ich.c
4+++ b/mpxplay/au_cards/sc_ich.c
5@@ -15,7 +15,7 @@
6 //function: Intel ICH audiocards low level routines
7 //based on: ALSA (http://www.alsa-project.org) and ICH-DOS wav player from Jeff Leyda
8 
9-//#define MPXPLAY_USE_DEBUGF 1
10+#define MPXPLAY_USE_DEBUGF 1
11 #define ICH_DEBUG_OUTPUT stdout
12 
13 #include "mpxplay.h"

No more excuses to use DOSSound 😉

Sorry, default value is "0" every value set (6420,4420,420,400,20) is accepted but sound still muted.
"duke3d-soundsetup" and "setblaster" do not complain any error...but machine is still silent. Sorry 🙁

dr.zeissler wrote on 2023-10-03, 16:52:

allregs 24D5 8086 follows!

From your file:

110, 01 = 0000.0001
211, 28 = 0010.1000
3[...]
414, 01 = 0000.0001
515, 24 = 0010.0100

At offset 0x10 is the NAMBAR address (16-bit little endian):

0x2801

At offset 0x14 is the NABMBAR address (16-bit little endian):

0x2401

In both cases, the least significant bit is 1, which means it is indeed in I/O space. To get the I/O space base address, mask out the two least significant bits, which gives:

NAMBAR = 0x2800
NABMBAR = 0x2400

This means you should be using 2400 and not 2800.

The dump also gives:

106, 90 = 1001.0000
207, 02 = 0000.0010

This should be the Command Register, again in 16-bit little endian, gives:

0x0290 (0000.0010.1001.0000)

This suggests that I/O Space (bit 0) and Bus Master (bit 2) aren't enabled. Did you run SBEMU to initialize the card BEFORE running this command?

In any case, it seems like you got the right device:

101, 80 = 1000.0000
202, D5 = 1101.0101
303, 24 = 0010.0100

(offset 00 is missing, and probably has 0x86 as content, as the Vendor ID of Intel is 0x8086, and Product ID 0x24D5 is the "Intel(R) 82801EB AC'97 Audio Controller".

SBEMU is in autostart "autoexec.bat" so allregs should be run after SBEMU was startet, but I recheck this.
Please keep in mind that I already stated that changing 2400 76 was not accepted and stayed ffff.

I'm actually not sure if it's the mixer registers or the busmaster registers we should be writing. And whether or not some bits (e.g. the I/O port enable bits in PCI?) are disabled again after SBEMU has finished initialising (which is what the PCI Command Register contents would suggest if I'm not misreading it).

Two EXEs (can be used as drop-in replacement for the sbemu.exe in the 1.0 beta3 package) with corresponding source patch (both apply on top of https://github.com/thp/sbemu/tree/linux-cross) applied, one that tries setting it using NAMBAR and one using NABMBAR. Maybe you have better luck with those? They should be printing what they do on the terminal (debug mode is enabled).

That's my last shot at these, if it isn't working, I'm out of ideas - sorry 😀

Sorry, as you already guessed, the 2400 76 is ffff and stays ffff regardless what I do.
So if it's really 2400 76 then first the protection must be switched off in order to change the values.

Sorry 🙁

what about sbemu-nambar.exe then? still no sound?
Last option is dumping all codec registers in pre XP windows (allows access to hardware registers without drivers so ac97test should work) where sound works and comparing to what sbemu is programming in, maybe its something stupid like volume being turned to 0 or mixer redirecting sound to spdif etc.
do you have win98 running on that computer by any chance? can you test if ac97test is running fine under windows and able to read/change registers?

yes I tested everything and looked at the values with ac97test. Nothing, no sound at all 2400/76 is and stays at "ffff"
either 2400/76 is the wrong value or it is hardly blocked and therefore switched off or had a protection.

I changed the "SB-EMU" in my start.bat with all three versions linked hier (nambar, nabmar, debug) and startet different tests (fm/sb) they all do not complain an error but I don't hear anything. I think sound is muted and the working Warp4/WinOS2/Win2K/Linux 2.6.12 unmute it.

rasz_pl wrote on 2023-10-04, 17:56:

what about sbemu-nambar.exe then? still no sound?
Last option is dumping all codec registers in pre XP windows (allows access to hardware registers without drivers so ac97test should work) where sound works and comparing to what sbemu is programming in, maybe its something stupid like volume being turned to 0 or mixer redirecting sound to spdif etc.
do you have win98 running on that computer by any chance? can you test if ac97test is running fine under windows and able to read/change registers?

Do I understand you correctly? I should install Win9x and install the sound-drivers and make a dump (allregs 24d5 8086) in the command line?
you know that win9x has a soundblaster-emulation activated in dos-window or fulscreen.

Or should I only boot the dos7 prt of win9x and make a dump. what should be identical to the msdos dump?

@THP I can send you my "b" machine (E600 without SCSI/CATWEAZEL-MK4) for troubleshooting if you like. It only costs me about 33 Euros via DHL .

dr.zeissler wrote on 2023-10-04, 18:11:

yes I tested everything and looked at the values with ac97test. Nothing, no sound at all 2400/76 is and stays at "ffff"
either 2400/76 is the wrong value

2800 is the correct number, so sbemu-nambar.exe

dr.zeissler wrote on 2023-10-04, 18:11:

I changed the "SB-EMU" in my start.bat with all three versions linked hier (nambar, nabmar, debug) and startet different tests (fm/sb) they all do not complain an error but I don't hear anything.

you didnt happen to take a screenshot from sbemu-debug loading?

dr.zeissler wrote on 2023-10-04, 18:15:

Do I understand you correctly? I should install Win9x and install the sound-drivers and make a dump (allregs 24d5 8086) in the command line?
you know that win9x has a soundblaster-emulation activated in dos-window or fulscreen.

1 install Win9x, make sure sound is working, even play something in background
2 open command window
3 run 'allregs 24d5 8086'
4 look at lines 10 and 11, if its still 01 and 28 then we are fine, if its something else rest needs to be modified
4 run modified ac97test - that doest exist yet, 10 minutes to make one once you confirm 'AC97TEST 2800 76' works inside Win9x without throwing errors/blue screens etc 😀

The Win9x installation can be done this weekend...here are the requested screens with"nambar"

dr.zeissler wrote on 2023-10-04, 19:48:

The Win9x installation can be done this weekend...here are the requested screens with"nambar"

yep mixport 2800, so we were doing correct thing all along and it does look like there is more to it than just setting register 0x76 to 400 🙁 Hopefully full codec register dump will give us more clue.
Attached modified thp's ac97test which in theory should be able to do it, not tested.

version 0.3

compiled for DOS, fixed printing per byte

dr.zeissler wrote on 2023-10-04, 18:15:

Do I understand you correctly? I should install Win9x and install the sound-drivers and make a dump (allregs 24d5 8086) in the command line?
you know that win9x has a soundblaster-emulation activated in dos-window or fulscreen.

Or should I only boot the dos7 prt of win9x and make a dump. what should be identical to the msdos dump?

The thing is, you want to get the AC97 hardware in a state where it outputs audio when PCM data is written to AC97, this includes any registers that affect routing as well as mixer settings. You have to be inside WIn9x for that, it could be that if you "boot into MS-DOS mode" from Win9x,

We know that on Linux 2.6.12, it works (meaning the registers are set in such a way that you can hear audio on the desired output).

We know (assume?) that on Win9x with the right driver installed, it also works.

You obviously have it working on Win2k as well, but since it's NT-based, accessing I/O ports directly isn't as easy due to proper OS-level protections. Linux has similar protections, but there are ways to access it (e.g. /dev/port, but that depends on CONFIG_DEVPORT, which seems to only be available since 2.6.22. Other than that, I/O port programming is possible, but it could be that you can't access the I/O ports while the driver has claimed those ports (which makes sense). According to the ioperm(2) manpage, "Since Linux 2.6.8, 65,536 I/O ports can be specified.". In any case, it's probably more complicated for you to read register states on Linux if you don't know your way around it, hence Win9x register dumping is probably the easiest way.

The fact that Win98SE has built-in SB emulation doesn't really matter here. We're not trying to access the SB I/O ports or output audio under Windows. We are just trying to read the state of the PCI device's registers to compare with the state of registers we have in DOS after initializing.

This assumes that the reason why you don't hear anything is caused by wrong register settings. The fact that you do hear audio on the internal speaker(?) would suggest that at least PCM data is transferred, so we can assume that part works. Furthermore, since you DO hear audio, the mixer settings (at least the "global" ones, like PCM/WAVE and MASTER/MAIN volume) seem to be correct. Sometimes there are audio chip / mixer settings (iirc on one of my old MacBooks with Linux, there were some mixer settings I had to unmute to enable additional built-in speakers) where even if the normal mixer settings are fine, there are per-output mixer settings. This is also something to look into. It could be that it's a combination, e.g. you have to do the 0x0420 register write to fix the routing, but then also increase the mixer settings somewhere, and doing just one or the other will still result in silence.

One way to find out whether it could be mixer-related is to boot into Linux 2.6.12 (which clearly has the routing registers set up correctly), and then check with "alsamixer" if there's a single volume control that only affects the rear line out output but doesn't affect the internal speaker or the "global" volume. If you find such a setting, please write down the mixer setting name and share it here, as we could be able to figure out what register / mixer setting this belongs to (this makes the assumption that in addition to routing, there's a separate mixer volume control that just affects the line out output -- I don't know if this is the case).

Also interestingly from your logs, it seems like it's detected as ICH4 (there's the log message about ICH4 in your photos):

1#ifdef SBEMU
2 if(card->pci_dev->device_type == DEVICE_INTEL_ICH4)
3 { //enable leagcy IO space, must be set before setting PCI CMD's IO space bit.
4  mpxplay_debugf(ICH_DEBUG_OUTPUT,"Eanble legacy io space for ICH4.\n");
5  pcibios_WriteConfig_Byte(card->pci_dev, 0x41, 1); //IOSE:enable IO space
6 }
7 #endif

I don't know what it does or why it is needed (and SBEMU seems to do it anyway), but as it's related to I/O space, I thought I'd highlight it here (but could be a red herring and unrelated).

Ok thx to make it clear on linux:

1. Debian 3.1 sarge net install => Kernel 2.4x => first install => OSS not ALSA => PCM Mixer on KDE Desktop works, sound is played over internal PC-Speaker, no LINE-OUT!
2. Debian 3.1 sarge net install => kernel 2.4x => second install (other harddisk on "a" machine") => OSS not ALSA => sound does not work, it starts short on the PC-SPK and then breaks. Everything is identical to installation 1. (this confuses me!, why is that, it's identical!)
3. LiveDVD GamesKnoppix 4.04 Kernel 2.6.12 => sound works everytime right out of the box. There is no soundserver active in KDE desktop but sound works 100%, seems to be working due to the kernel support. Not possible to play two different sound at one time, but sound always works via LINE-OUT!

Let's hope that win9x let us make some progress...thx for your support, I really appreciate it!