VOGONS


SBEMU: Sound Blaster emulation on AC97

Topic actions

Reply 960 of 1403, by rasz_pl

User metadata
Rank l33t
Rank
l33t

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:

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

allregs 24d5 8086> okregs.log
ac97dump xxxx > okcodec.log

where xxxx is that number after mixport

and do the same on computer where sound doesnt work:

sbemu-debug.exe> bademu.log

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

allregs 24d5 8086> badregs.log
ac97dump 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

allregs 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

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

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 961 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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

Attachments

  • Filename
    OKREGS.LOG
    File size
    4.98 KiB
    Downloads
    40 downloads
    File license
    Public domain
  • Filename
    OKEMU.LOG
    File size
    2.55 KiB
    Downloads
    34 downloads
    File license
    Public domain
  • Filename
    OKCODEC.LOG
    File size
    48 Bytes
    Downloads
    39 downloads
    File license
    Public domain

Retro-Gamer 😀 ...on different machines

Reply 962 of 1403, by rasz_pl

User metadata
Rank l33t
Rank
l33t

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

ac97dump 2C00> okcodec.log

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 963 of 1403, by thp

User metadata
Rank Member
Rank
Member

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.

Reply 964 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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.

Attachments

  • Filename
    BADREGS.LOG
    File size
    4.98 KiB
    Downloads
    36 downloads
    File comment
    FSC-E600 AD1980 MSDOS
    File license
    Public domain
  • Filename
    BADEMU.LOG
    File size
    2.56 KiB
    Downloads
    37 downloads
    File comment
    FSC-E600 AD1980 MSDOS
    File license
    Public domain
  • Filename
    BADCODEC.LOG
    File size
    693 Bytes
    Downloads
    35 downloads
    File comment
    FSC-E600 AD1980 MSDOS
    File license
    Public domain
  • Filename
    98REGS.LOG
    File size
    4.98 KiB
    Downloads
    35 downloads
    File comment
    FSC-E600 AD1980 WIN98
    File license
    Public domain
  • Filename
    98CODEC.LOG
    File size
    693 Bytes
    Downloads
    36 downloads
    File comment
    FSC-E600 AD1980 WIN98
    File license
    Public domain

Retro-Gamer 😀 ...on different machines

Reply 965 of 1403, by thp

User metadata
Rank Member
Rank
Member
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.

--- BADREGS.LOG	2023-10-06 22:44:58.035979116 +0200
+++ OKREGS.LOG 2023-10-05 21:50:55.048857002 +0200
@@ -14,20 +14,20 @@
0E, 00 = 0000.0000
0F, 00 = 0000.0000
10, 01 = 0000.0001
-11, 28 = 0010.1000
+11, 2C = 0010.1100
12, 00 = 0000.0000
13, 00 = 0000.0000
14, 01 = 0000.0001
-15, 24 = 0010.0100
+15, 28 = 0010.1000
16, 00 = 0000.0000
17, 00 = 0000.0000
18, 00 = 0000.0000
19, 0C = 0000.1100
-1A, 00 = 0000.0000
+1A, 08 = 0000.1000
1B, D0 = 1101.0000
1C, 00 = 0000.0000
1D, 08 = 0000.1000
-1E, 00 = 0000.0000
+1E, 08 = 0000.1000
1F, D0 = 1101.0000
20, 00 = 0000.0000
21, 00 = 0000.0000
@@ -41,10 +41,10 @@
29, 00 = 0000.0000
2A, 00 = 0000.0000
2B, 00 = 0000.0000
-2C, 34 = 0011.0100
-2D, 17 = 0001.0111
-2E, 20 = 0010.0000
-2F, 10 = 0001.0000
+2C, CF = 1100.1111
+2D, 10 = 0001.0000
+2E, 2F = 0010.1111
+2F, 12 = 0001.0010
30, 00 = 0000.0000
31, 00 = 0000.0000
32, 00 = 0000.0000

Reply 966 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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)

Retro-Gamer 😀 ...on different machines

Reply 967 of 1403, by thp

User metadata
Rank Member
Rank
Member

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:

-BAD
+W98

byte offset (because of little-endian 16-bit data layout)
0100 0302 0504 0706 0908 0b0a 0d0c 0f0e

-00: 0090 0e0e 0000 8000 0000 0000 8008 8008
+00: 0090 0303 0303 0003 0000 0000 8008 8048
^^^^ mic volume (+gain boost +mute)
^^^^ mono volume (+mute)
^^^^ headphone volume
^^^^ master volume

-10: 8808 8808 0000 8808 0000 0000 8000 0000
+10: 8888 0c0c 0000 8888 0707 0000 0808 0000
^^^^ record gain
^^^^ PCM out volume (zero means full gain)
^^^^ AUX volume
^^^^ CD volume (CD is muted in SBEMU?)
^^^^ line in volume

-20: 0000 0000 0000 000f 03c3 01c1 5622 bb80
+20: 0000 0000 0000 000f 03c3 3831 49b3 bb80
^^^^ PCM front DAC rate (22050 vs 18867?)
^^^^ ext'd audio stat/ctrl

30: bb80 bb80 0000 8080 8080 2000 0000 0000
40: 0000 0000 0000 0000 0000 0000 0000 0000

-50: 0000 0000 0000 0000 0000 0000 0000 0000
+50: 0000 0000 0000 0000 0000 0000 1000 0000
^^^^ undocumented / not in data sheet

60: 8080 0000 0000 0000 0000 0000 0000 0000

-70: 0000 0008 1001 0000 0000 0000 4144 5370
+70: 0000 0a88 7000 e428 0000 0000 4144 5370
^^^^ misc control bits
^^^^ serial configuration
^^^^ jack sense

register 0x2A values:

BAD = 0x01c1 = 0b0000000111000001
W98 = 0x3831 = 0b0011100000110001
^ EVRA = enable variable rate audio
^ EDRA
^ ESPDIF
x
^^ SPSA[1,0] = SPDIF Slot Assignment Bits (r/w)
^ ECDAC = Center DAC status (read only)
^ ESDAC = Surround DAC status (read only)
^ ELDAC = LFE DAC status (read only)
x
^ SPCV
^ PRI = Center DAC power down (1 = turned off)
^ PRJ = Surround DACs power down (1 = turned off)
^ PRK = PCM LFE DAC power down (1 = turned off)
x
^ vforce bit
Show last 63 lines

It seems like the Win98 driver can power down some DACs to
save power when not needed(?), and this is reflected in the
status bits

register 0x72 values:

BAD = 0x0008 = 0b0000000000001000
W98 = 0x0a88 = 0b0000101010001000
^ JS0 INT (jack interrupt)
^ JS1 INT (jack interrupt)
^ JS0 ST (jack state pin)
^ JS1 ST (jack state pin)
^ JS0 MD
^ JS1 MD
^ JS0 TMR
^ JS1 TMR (Timer Enable)
^ JS0 EQB
^ JS1 EQB (EQ Bypass)
^ JS MT0
^ JS MT1 (Mute Enable differs)
^ JS MT2
^ JS0 DMX
^ JS1 DMX
^ JS1 SPRD

The Win98 driver enables some jack sensing here, see
table IX in the data sheet what JS MT (0, 1, 0) means.

register 0x74 values:

0b1111111111111111
BAD = 0x1001 = 0b0001000000000001
W98 = 0x7000 = 0b0111000000000000
^ SPLNK = SPDIF link (1 = linked, 0 = not linked)
............
^ REGM1 (slave 1 codec register mask(??))
^ REGM2 (slave 2 codec register mask(??))
^ SLOT16

Seems like Win98 disables the SPDIF link (the default is
for it to be enabled, which is what we see for SBEMU).

register 0x76 values:

0b1111111111111111
BAD = 0x0000 = 0b0000000000000000
W98 = 0xe428 = 0b1110010000101000
...
^ VREFH (Vrefout / MIC bias 2.25 V vs 3.7 V)
.
^ LOSEL (line out amp input select)
....
^ HPSEL (headphone amp input select)
^ CLDIS (center and LFE disable)
^ LODIS (line out disable)
^ MSPLT (mute split -> allow left/right mute)
^ AC97NC (ADI vs AC97 volume ctrl compatibility mode)
^ DAC zero-fill under starved condition

Here we meet out friends HPSEL and LOSEL again. For some reason
this isn't set properly.

Reply 968 of 1403, by thp

User metadata
Rank Member
Rank
Member

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:

diff --git a/mpxplay/au_cards/sc_ich.c b/mpxplay/au_cards/sc_ich.c
index 0df0f76..db3da96 100644
--- a/mpxplay/au_cards/sc_ich.c
+++ b/mpxplay/au_cards/sc_ich.c
@@ -292,6 +292,9 @@ static void snd_intel_prepare_playback(struct intel_card_s *card,struct mpxplay_
snd_intel_codec_write(card,AC97_SPDIF_CONTROL,cmd);
pds_delay_10us(10);

+ // Hack for AD1980
+ snd_intel_codec_write(card, 0x76, snd_intel_codec_read(card, 0x76) | 0x0420);
+
//set analog ac97 freq
mpxplay_debugf(ICH_DEBUG_OUTPUT,"AC97 front dac freq:%d ",aui->freq_card);
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

Attachments

  • Filename
    sbemu.exe
    File size
    316 KiB
    Downloads
    39 downloads
    File comment
    Drop-in replacement sbemu.exe for AD1980
    File license
    GPL-2.0-or-later

Reply 969 of 1403, by rasz_pl

User metadata
Rank l33t
Rank
l33t
thp wrote on 2023-10-06, 21:11:

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

yes

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

snd_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

AC97TEST 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:

ac97dump 2C00> okcodec.log

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 970 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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

Attachments

  • Filename
    OKREGS.LOG
    File size
    4.98 KiB
    Downloads
    31 downloads
    File comment
    C610 SB-EMU-DEBUG "2C00"
    File license
    Public domain
  • Filename
    OKEMU.LOG
    File size
    2.55 KiB
    Downloads
    35 downloads
    File comment
    C610 SB-EMU-DEBUG "2C00"
    File license
    Public domain
  • Filename
    OKCODEC.LOG
    File size
    693 Bytes
    Downloads
    34 downloads
    File comment
    C610 SB-EMU-DEBUG "2C00"
    File license
    Public domain

Retro-Gamer 😀 ...on different machines

Reply 971 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

FSC E600 NAMBAR VERSION

Attachments

  • Filename
    NAMBCODE.LOG
    File size
    693 Bytes
    Downloads
    32 downloads
    File comment
    FSC-E600 NAMBAR Version
    File license
    Public domain
  • Filename
    NAMBARRE.LOG
    File size
    4.98 KiB
    Downloads
    33 downloads
    File comment
    FSC-E600 NAMBAR Version
    File license
    Public domain
  • Filename
    BADNAMBA.LOG
    File size
    2.68 KiB
    Downloads
    33 downloads
    File comment
    FSC-E600 NAMBAR Version
    File license
    Public domain

Retro-Gamer 😀 ...on different machines

Reply 972 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

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

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

Attachments

  • Filename
    NBADREGS.LOG
    File size
    4.98 KiB
    Downloads
    33 downloads
    File comment
    FSC-E600 latest SBEMU
    File license
    Public domain
  • Filename
    NBADCODE.LOG
    File size
    693 Bytes
    Downloads
    37 downloads
    File comment
    FSC-E600 latest SBEMU
    File license
    Public domain
Last edited by dr.zeissler on 2023-10-07, 18:36. Edited 1 time in total.

Retro-Gamer 😀 ...on different machines

Reply 974 of 1403, by thp

User metadata
Rank Member
Rank
Member
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).

Reply 975 of 1403, by thp

User metadata
Rank Member
Rank
Member

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.

Attachments

  • Filename
    sbemu.exe
    File size
    316 KiB
    Downloads
    38 downloads
    File comment
    Updated win98 register write with fixed register offsets
    File license
    GPL-2.0-or-later

Reply 976 of 1403, by rasz_pl

User metadata
Rank l33t
Rank
l33t

>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

do{
if(snd_intel_read_32(card,ICH_GLOB_STAT_REG) & codec)
break;
pds_delay_10us(10);
}while(--retry);
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.

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 977 of 1403, by dr.zeissler

User metadata
Rank l33t
Rank
l33t
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!

Retro-Gamer 😀 ...on different machines

Reply 978 of 1403, by rasz_pl

User metadata
Rank l33t
Rank
l33t
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

Open Source AT&T Globalyst/NCR/FIC 486-GAC-2 proprietary Cache Module reproduction

Reply 979 of 1403, by thp

User metadata
Rank Member
Rank
Member
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.