Do I remember right you have another computer with same AD1980 and working sbemu audio? if yes then we can use it for comparisons too. On that working one:

1sbemu-debug.exe > okemu.log

-search okemu.log for line with "vend_id dev_id ... mixport xxxx", remember number xxxx after mixport
-run something that uses sound and plays audio

1allregs 24d5 8086> okregs.log

1ac97dump xxxx > okcodec.log

where xxxx is that number after mixport

and do the same on computer where sound doesnt work:

1sbemu-debug.exe> bademu.log

-run something that uses sound and plays audio, doesnt matter you cant hear it

1allregs 24d5 8086> badregs.log

1ac97dump 2800 > badcodec.log

here we already know xxxx is 2800

After you get win98 going:
-load windows, make sure sound works
-open command window - start menu - run - type in command.com

1allregs 24d5 8086> winregs.log

-look at winregs.log lines 10 and 11, if its still 01 and 28 then we are fine, if its something else and line 10 byte doesnt end with 1 we will need to regroup 😀
-if it was 01 28 run

1ac97dump 2800 > wincodec.log

All those log files will let us compare if something strange happens. Would be great to also do it in linux and NT, but as thp stated NT requires special driver to touch hardware and linux is a complicated mess.

seems to be something wrong with mixerport 2C00 dump.
Taken from FSC C610 i865gv AD1980 working right out of the box.

I screwed up compiling ac97dump 😐 Re: SBEMU: Sound Blaster emulation on AC97 fix uploaded
rest looks ok, rerun just

1ac97dump 2C00> okcodec.log

As an update to the SIS7012 support, the ECS K7S5A board I have here apparently also has an onboard SIS7012 audio chip (the initial development happened on/for a Futro S400).

Quickly booted up the sbemu build with sis7012 support and it seems to work (e.g. Duke3D with OPL + PCM works).

Looking up the chipset names, this means it has been tested on the “SIS735” and “SiS 963L / SiS 741CX” (what parkytowers documents for the Futro S400) chipsets.

here you go, sound ist not working on MSDOS/AMITHLON, sound is working in Win98se Window.
All files from the "bad" machine FSC-E600 D1534 i865G AD1980.
It's obvious that 98codec.log (working win98) is different than badcodec.log (not working msdos) on that same machine.

dr.zeissler wrote on 2023-10-06, 20:19:

here you go, sound ist not working on MSDOS/AMITHLON, sound is working in Win98se Window.
All files from the "bad" machine FSC-E600 D1534 i865G AD1980.
It's obvious that 98codec.log (working win98) is different than badcodec.log (not working msdos) on that same machine.

(edit: removed the part about 98CODEC vs BADCODEC, these actually have content.. will check soon)

Running a diff between BADREGS.LOG and OKREGS.LOG, full diff attached below. They don't seem to correspond to the mixer registers, but PCI configuration space.

offset 0x11 is part of BAR0 (that's fine if it's different)
offset 0x15 is part of BAR1 (that's fine if it's different)
offset 0x1A is part of BAR2 (not sure why this is used?)
offset 0x1E is part of BAR3 (not sure why this is used?)
at offset 0x2C is the "subsystem ID" and "subsystem vendor ID"

BADREGS.LOG has: 0x1734 / 0x1020
OKREGS.LOG has: 0x10CF / 0x122F

Looking those up at https://pci-ids.ucw.cz/ gives:

vendor 1734 (from BADREGS) is listed as:

"# nee Fujitsu Siemens Computers GmbH
1734 Fujitsu Technology Solutions"

vendor 10CF (from OKREGS) is listed as:

"10cf Fujitsu Limited."

There's no difference between BADREGS.LOG and 98REGS.LOG (this is fine, it should be like that -- it's after all the same machine.

1--- BADREGS.LOG	2023-10-06 22:44:58.035979116 +0200
2+++ OKREGS.LOG	2023-10-05 21:50:55.048857002 +0200
3@@ -14,20 +14,20 @@
4 0E, 00 = 0000.0000
5 0F, 00 = 0000.0000
6 10, 01 = 0000.0001
7-11, 28 = 0010.1000
8+11, 2C = 0010.1100
9 12, 00 = 0000.0000
10 13, 00 = 0000.0000
11 14, 01 = 0000.0001
12-15, 24 = 0010.0100
13+15, 28 = 0010.1000
14 16, 00 = 0000.0000
15 17, 00 = 0000.0000
16 18, 00 = 0000.0000
17 19, 0C = 0000.1100
18-1A, 00 = 0000.0000
19+1A, 08 = 0000.1000
20 1B, D0 = 1101.0000
21 1C, 00 = 0000.0000
22 1D, 08 = 0000.1000
23-1E, 00 = 0000.0000
24+1E, 08 = 0000.1000
25 1F, D0 = 1101.0000
26 20, 00 = 0000.0000
27 21, 00 = 0000.0000
28@@ -41,10 +41,10 @@
29 29, 00 = 0000.0000
30 2A, 00 = 0000.0000
31 2B, 00 = 0000.0000
32-2C, 34 = 0011.0100
33-2D, 17 = 0001.0111
34-2E, 20 = 0010.0000
35-2F, 10 = 0001.0000
36+2C, CF = 1100.1111
37+2D, 10 = 0001.0000
38+2E, 2F = 0010.1111
39+2F, 12 = 0001.0010
40 30, 00 = 0000.0000
41 31, 00 = 0000.0000
42 32, 00 = 0000.0000

PCISNIF listed Fujitsu also

Vendor 8086h Intel Corporation
Device 24D5h 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller
Command 0007h (I/O Access, Memory Access, BusMaster)
Status 0290h (Has Capabilities List, Supports Back-To-Back Trans., Medium Timing)
Revision 02h, Header Type 00h, Bus Latency 00h
Self test 00h (Self test not supported)
PCI Class Multimedia, type Audio
Subsystem ID 10201734h Unknown
Subsystem Vendor 1734h Fujitsu Siemens Computers
Address 0 is an I/O Port : 00002800h
Address 1 is an I/O Port : 00002400h
Address 2 is a Memory Address (anywhere in 0-4Gb) : D0000C00h
Address 3 is a Memory Address (anywhere in 0-4Gb) : D0000800h
System IRQ 5, INT# B
New Capabilities List Present:
Power Management Capability
Supports power state D1
Current Power State : D0 (Device operational, no power saving)

The ac97dump utility would only need to do a 16-bit read at every 2 bytes, I was confused for a second 😀

tl;dr: HPSEL and LOSEL in register 0x76 are not set for some reason, so next step would be to figure out why the SBEMU code cannot write to these registers. As long as we don't see those two flags go up, I don't think you will hear audio.

Full annotated and hand-edited diff below:

1-BAD
2+W98
3
4byte offset (because of little-endian 16-bit data layout)
5     0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
6
7-00: 0090 0e0e 0000 8000 0000 0000 8008 8008
8+00: 0090 0303 0303 0003 0000 0000 8008 8048
9                                        ^^^^ mic volume (+gain boost +mute)
10                    ^^^^ mono volume (+mute)
11               ^^^^ headphone volume
12          ^^^^ master volume
13
14-10: 8808 8808 0000 8808 0000 0000 8000 0000
15+10: 8888 0c0c 0000 8888 0707 0000 0808 0000
16                                   ^^^^ record gain
17                         ^^^^ PCM out volume (zero means full gain)
18                    ^^^^ AUX volume
19          ^^^^ CD volume (CD is muted in SBEMU?)
20     ^^^^ line in volume
21
22-20: 0000 0000 0000 000f 03c3 01c1 5622 bb80
23+20: 0000 0000 0000 000f 03c3 3831 49b3 bb80
24                                   ^^^^ PCM front DAC rate (22050 vs 18867?)
25                              ^^^^ ext'd audio stat/ctrl
26
27 30: bb80 bb80 0000 8080 8080 2000 0000 0000
28 40: 0000 0000 0000 0000 0000 0000 0000 0000
29
30-50: 0000 0000 0000 0000 0000 0000 0000 0000
31+50: 0000 0000 0000 0000 0000 0000 1000 0000
32                                   ^^^^ undocumented / not in data sheet
33
34 60: 8080 0000 0000 0000 0000 0000 0000 0000
35
36-70: 0000 0008 1001 0000 0000 0000 4144 5370
37+70: 0000 0a88 7000 e428 0000 0000 4144 5370
38                    ^^^^ misc control bits
39               ^^^^ serial configuration
40          ^^^^ jack sense
41
42register 0x2A values:
43
44  BAD = 0x01c1 = 0b0000000111000001
45  W98 = 0x3831 = 0b0011100000110001
46                                  ^ EVRA = enable variable rate audio
47                                 ^ EDRA 
48                                ^ ESPDIF 
49                               x
50                             ^^ SPSA[1,0] = SPDIF Slot Assignment Bits (r/w)
51                            ^ ECDAC = Center DAC status (read only)
52                           ^ ESDAC = Surround DAC status (read only)
53                          ^ ELDAC = LFE DAC status (read only)
54                         x
55                        ^ SPCV
56                       ^ PRI = Center DAC power down (1 = turned off)
57                      ^ PRJ = Surround DACs power down (1 = turned off)
58                     ^ PRK = PCM LFE DAC power down (1 = turned off)
59                    x
60                   ^ vforce bit

61
62It seems like the Win98 driver can power down some DACs to
63save power when not needed(?), and this is reflected in the
64status bits
65
66register 0x72 values:
67
68  BAD = 0x0008 = 0b0000000000001000
69  W98 = 0x0a88 = 0b0000101010001000
70                                  ^ JS0 INT (jack interrupt)
71                                 ^ JS1 INT (jack interrupt)
72                                ^ JS0 ST (jack state pin)
73                               ^ JS1 ST (jack state pin)
74                              ^ JS0 MD
75                             ^ JS1 MD
76                            ^ JS0 TMR
77                           ^ JS1 TMR (Timer Enable)
78                          ^ JS0 EQB
79                         ^ JS1 EQB (EQ Bypass)
80                        ^ JS MT0
81                       ^ JS MT1 (Mute Enable differs)
82                      ^ JS MT2
83                     ^ JS0 DMX
84                    ^ JS1 DMX
85                   ^ JS1 SPRD
86
87The Win98 driver enables some jack sensing here, see
88table IX in the data sheet what JS MT (0, 1, 0) means.
89
90register 0x74 values:
91
92                 0b1111111111111111
93  BAD = 0x1001 = 0b0001000000000001
94  W98 = 0x7000 = 0b0111000000000000
95                                  ^ SPLNK = SPDIF link (1 = linked, 0 = not linked)
96                      ............
97                     ^ REGM1 (slave 1 codec register mask(??))
98                    ^ REGM2 (slave 2 codec register mask(??))
99                   ^ SLOT16
100
101Seems like Win98 disables the SPDIF link (the default is
102for it to be enabled, which is what we see for SBEMU).
103
104register 0x76 values:
105
106                 0b1111111111111111
107  BAD = 0x0000 = 0b0000000000000000
108  W98 = 0xe428 = 0b1110010000101000
109                                ...
110                               ^ VREFH (Vrefout / MIC bias 2.25 V vs 3.7 V)
111                              .
112                             ^ LOSEL (line out amp input select)
113                         ....
114                        ^ HPSEL (headphone amp input select)
115                       ^ CLDIS (center and LFE disable)
116                      ^ LODIS (line out disable)
117                     ^ MSPLT (mute split -> allow left/right mute)
118                    ^ AC97NC (ADI vs AC97 volume ctrl compatibility mode)
119                   ^ DAC zero-fill under starved condition
120
121Here we meet out friends HPSEL and LOSEL again. For some reason
122this isn't set properly.

I just noticed in snd_intel_prepare_playback() the codec is reset, and then we don't set the register values again, which would probably neuter any register settings done before.

So the following patch against the linux-cross branch (clone the source repo, apply the patch below, then build) might actually do something -- exe attached for testing:

1diff --git a/mpxplay/au_cards/sc_ich.c b/mpxplay/au_cards/sc_ich.c
2index 0df0f76..db3da96 100644
3--- a/mpxplay/au_cards/sc_ich.c
4+++ b/mpxplay/au_cards/sc_ich.c
5@@ -292,6 +292,9 @@ static void snd_intel_prepare_playback(struct intel_card_s *card,struct mpxplay_
6  snd_intel_codec_write(card,AC97_SPDIF_CONTROL,cmd);
7  pds_delay_10us(10);
8 
9+ // Hack for AD1980
10+ snd_intel_codec_write(card, 0x76, snd_intel_codec_read(card, 0x76) | 0x0420);
11+
12  //set analog ac97 freq
13  mpxplay_debugf(ICH_DEBUG_OUTPUT,"AC97 front dac freq:%d ",aui->freq_card);
14  if(card->ac97_clock_corrector){

If that works (I'm hopeful..), then the question is how to detect AD1980 and properly set this register value only when AD1980 is detected as codec (right now it'd be unconditionally applied for any ICH/AC97 card). But let's get it working first and if we know this fixes it, then we can think about that.

Edit: Seems like we can read registers 0x7C and 0x7E to read the vendor ID. The AD1980 data sheet says the value of 0x7C is 0x4144 and 0x7E is 0x5370.
Edit 2: Proposed PR candidate if this works: https://github.com/thp/sbemu/tree/ad1980

thp wrote on 2023-10-06, 21:11:

They don't seem to correspond to the mixer registers, but PCI configuration space.

yes

1allregs 24d5 8086> xxxregs.log

thp wrote on 2023-10-06, 22:22:

The ac97dump utility would only need to do a 16-bit read at every 2 bytes, I was confused for a second 😀

I just knew Ill make more than one mistake 😀 fixed Re: SBEMU: Sound Blaster emulation on AC97

thp wrote on 2023-10-06, 22:40:

I just noticed in snd_intel_prepare_playback() the codec is reset, and then we don't set the register values again, which would probably neuter any register settings done before.

1snd_intel_write_8(card,ICH_PO_CR_REG, snd_intel_read_8(card, ICH_PO_CR_REG) | ICH_PO_CR_RESET);

doesn this reset Intel AC97 engine portion, not the codec?
anyway 76 is 0 in the debug because dr.zeissler was running unpatched sbemu-debug.exe
the question is why didnt your sbemu-nambar.exe work? Your patch is in snd_intel_ac97_init together with volume settings. dr.zeissler said

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 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.

which isnt entirely clear. dr.zeissler can you run sbemu-nambar.exe again followed by

1AC97TEST 2800 76

thp wrote on 2023-10-06, 22:40:

If that works (I'm hopeful..), then the question is how to detect AD1980 and properly set this register value only when AD1980 is detected as codec (right now it'd be unconditionally applied for any ICH/AC97 card). But let's get it working first and if we know this fixes it, then we can think about that.

Edit: Seems like we can read registers 0x7C and 0x7E to read the vendor ID. The AD1980 data sheet says the value of 0x7C is 0x4144 and 0x7E is 0x5370.
Edit 2: Proposed PR candidate if this works: https://github.com/thp/sbemu/tree/ad1980

FSC C610 i865gv also uses AD1980 and is working fine without hacks, are you sure switching LINE_OUT routing wont screw with it?
Would be great to also see C610:

1ac97dump 2C00> okcodec.log

I retested C610 (= working AD1980 on i865gv)yesterday. Loaded SB-EMU-DEBUG

FSC E600 NAMBAR VERSION

FSC-E600 LATEST SBEMU-VERSION (logging broken!)

due to that "SBEMU > xx.log" is empty and cannot be uploaded.

None of these tests made any sound work on that FSC-E600 AD1980 i865G. Sorry guys 🙁

dr.zeissler wrote on 2023-10-07, 09:00:

None of these tests made any sound work on that FSC-E600 AD1980 i865G. Sorry guys 🙁

Looking at the logs, register 0x76 is now properly set. We should probably just try to set all the other registers based on your Win98 dump, and if that works, we just need to trim down to the offending register (remove changes again until it works).

Here's a build that takes your register dump from Win98 and forces all registers to the dump you provided. It also disables mixer writes from sbemu, so mixer settings won't work from SBEMU (and be fixed to whatever you set in Win98). This doesn't check read-only/read-write registers and just unconditionally sets all (except the first one, which would reset something?). Let me know if that helps (a better implementation would create a list of valid registers first, etc.. -- this is a rather brute force approach).

Source code here: https://github.com/thp/sbemu/tree/ad1980-win98regs

Edit: Broken version exchanged -- now the register offset is properly calculated.

>OKCODEC.LOG File size693 BytesDownloads2 downloadsFile comment
>C610 SB-EMU-DEBUG "2C00"

so C610 doesnt need any 0x76 shenanigans to play sound

>Fix register write offsets

hey, thats my ac97dump bug! 😀

BADEMU.LOG:>00:00:00.604 sc_ich.c 219 primary codec reset timeout:0

snd_intel_codec_ready

1do{
2  if(snd_intel_read_32(card,ICH_GLOB_STAT_REG) & codec)
3   break;
4  pds_delay_10us(10);
5 }while(--retry);
6 return retry;

it will return 0 if it runs out of retries? is it possible E600 has two codecs (soft modem is also a codec) or doesnt have primary? or we down wait long enough? ICH_DEFAULT_RETRY 1000 x pds_delay_10us(10) is only 100 milliseconds
compared to https://github.com/torvalds/linux/blob/827140 … ntel8x0m.c#L880 there is a lot of assumptions in sbemu, and linux waits good 250-1000ms.

thp wrote on 2023-10-07, 15:00:

Here's a build that takes your register dump from Win98 and forces all registers to the dump you provided. It also disables mixer writes from sbemu, so mixer settings won't work from SBEMU (and be fixed to whatever you set in Win98). This doesn't check read-only/read-write registers and just unconditionally sets all (except the first one, which would reset something?). Let me know if that helps (a better implementation would create a list of valid registers first, etc.. -- this is a rather brute force approach). Source code here: https://github.com/thp/sbemu/tree/ad1980-win98regs Edit: Broken version exchanged -- now the register offset is properly calculated.

Hi there, I don't know what you did, but I can hear audio for the first time on that AD1980 in MSDOS with SBEMU on my FSC-E600 D1534!! 😀 YEAH!

Here are my first impressions:
- does load a bit slow, seems there are "waits" up to 10 seconds while loading/initializing
- OPL sound OK to my ears, compatibility is OK, the high-end-stuff is not working, but not a big problem for me https://www.pouet.net/prod.php?which=5488 https://www.pouet.net/prod.php?which=5489
- SBL compatibility is rather low and SBL causes obvious stutter in the video, but also not a big problem.
- SBL seems to be a bit slow paced on point https://www.pouet.net/prod.php?which=68187
- SBL sound good in "setup" in Duke3D center, right and left test sounds a bit weird and high-pitched.

Thank you very much for all the work and troubleshooting...that was a big step forward.
Now it would be a hell of a thing to patch the AD1980 driver for Amithlon Kernel3.10 too.
Big thanks to everyone that made this possible!

dr.zeissler wrote on 2023-10-07, 20:46:

- does load a bit slow, seems there are "waits" up to 10 seconds while loading/initializing

it writes 64 registers twice, with potential of waiting up to 100 milliseconds per write if snd_intel_codec_semaphore times out = 2x 6.4 seconds = 12 seconds of additional wait

rasz_pl wrote on 2023-10-07, 17:22:

>Fix register write offsets

hey, thats my ac97dump bug! 😀

Hehe...

rasz_pl wrote on 2023-10-07, 17:22:

BADEMU.LOG:>00:00:00.604 sc_ich.c 219 primary codec reset timeout:0
[...]
it will return 0 if it runs out of retries?

That's true, well spotted - I didn't even look into those logs anymore.

dr.zeissler wrote on 2023-10-07, 20:46:

Hi there, I don't know what you did, but I can hear audio for the first time on that AD1980 in MSDOS with SBEMU on my FSC-E600 D […]
Show full quote

Hi there, I don't know what you did, but I can hear audio for the first time on that AD1980 in MSDOS with SBEMU on my FSC-E600 D1534!! 😀 YEAH!
[...]
Thank you very much for all the work and troubleshooting...that was a big step forward.
Now it would be a hell of a thing to patch the AD1980 driver for Amithlon Kernel3.10 too.
Big thanks to everyone that made this possible!

Well it's just a brute force "write all the register values" test program. Ideally we'd go and trim it down to just the minimal set of magic registers that makes it work (and then check if the other AD1980 devices you have still work with those registers, or if there's a way to detect the different models, or failing that, provide some kind of switch for it).

This does prove that it's just about register settings, one could use the annotation at Re: SBEMU: Sound Blaster emulation on AC97 to figure out which registers differ, then see if just setting those still work, and then apply some intelligent trial'n'error to figure out which matter and which don't matter.