Ok, so now I actually read the backlog of this thread and it seems like you tried some Linux kernel 2.6.x distro already, and it works there?

There was also a link somewhere to this patch in FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=140591

The description there says:

1+	 * AD198x register 0x76
2+	 * 0x0400: select mixer for SURR_OUT/HP_OUT output pins (default surround DAC)
3+	 * 0x0020: select surround DAC for LINE_OUT output pins (default mixer)
4[...]
5+	 * Fujitsu C610 seems to wire SURR_OUT/HP_OUT for 
6+	 * internal speaker, and LINE_OUT for lineout AND headphone jacks; 
7+	 * by setting previous 0x0420, internal speaker works but 
8+	 * no output for either jacks.
9[...]
10+	case 0x122f10cf:	/* Fujitsu C610 (perhaps for others) */
11+		ac97_wrcd(codec, 0x76, ac97_rdcd(codec, 0x76) | 0x0400);
12+		break;

The current FreeBSD source by default sets 0x420 (HPSEL = mixer, LOSEL = surround):

1void ad198x_patch(struct ac97_info* codec)
2{
3	switch (ac97_getsubvendor(codec)) {
4	case 0x11931043:	/* Not for ASUS A9T (probably else too). */
5		break;
6	default:
7		ac97_wrcd(codec, 0x76, ac97_rdcd(codec, 0x76) | 0x0420);
8		break;
9	}
10}

So this fix sets the bits 0x0400 in register 0x76. Bit 0x0400 is bit 10 when counting from the right and starting at 0.

Analog Devices still has the AD1980 data sheet online, which says that 0x76 is the "Miscellaneous Control Bit Register". Furthermore, D10 (the 10th bit, counting from zero) is "HPSEL", which the data sheet describes as:

1Headphone Amplifier Input Select. This bit allows the headphone power amps to be driven from the surround DACs or from the mixer outputs. There are two reasons for this: one is to allow 2-channel media to use the higher power headphone amplifiers available on the SURR/HP_OUT outputs; the other is to allow spreading of 2-channel media to the surround outputs.
2Together with the LOSEL bit (see above), this bit also provides for analog swapping of the mixer (front) and sur- round outputs.
30 = SURR_out/HP_out outputs are driven by the surround DACs (reset default).
41 = SURR_out/HP_out outputs are driven by the mixer outputs.

For completeness, the data sheet describes "LOSEL" as:

1LINE_OUT Amplifiers Input Select. This bit allows the LINE_OUT output amplifiers to be driven by the mixer or the surround DACs. The main purpose for this is to allow swapping of the front and surround channels to make better use of the SURR/HP_OUT output amplifiers. This bit should normally be used in tandem with the HPSEL bit (see below).
20 = LINE_OUT amplifiers are driven by the mixer outputs (reset default).
31 = LINE_OUT amplifiers are driven by the surround DAC outputs.

I assume that your line out is wired to the internal speaker, and headphone is line out and headphone. Also, "mixer outputs" is the normal output (that you want), and "surround DAC outputs" is something else that doesn't provide any audio in your case (i.e. virtually muted).

So in order to get mixer output on headphone/line out, you want to set bit D10 in the 0x76 register.
If you also want mixer output on the internal spaker, you want to clear bit D5 in the 0x76 register.

By default, LOSEL = 0 (internal speakers work?) and HPSEL = 0 (headphone/line out don't work).

Instead of using DOSSOUND, you should be able to just do port I/O at the NABM (native audio bus master) port address (BAR1) -- not to be confused with NAM (native audio mixer / BAR0) and add the offset 0x76.

So to read the register:

1inw(baseport_bm+0x76);

And to write the register:

1outw(baseport_bm+0x76, data)

In a previous message you write:

1E600 i865g D1980 (not working sound)
2NAMBAR 2800 NAMBAR 2400 IRQ5

One of these (0x2800 or 0x2400) is the NABMBAR (bm = bus master -> the one we want), one is NAMBAR (mixer -> not the one we want).

So IMHO what could "fix" the issue (in your particular case):

1int baseport = 0x2400; /* please put in the right NABMBAR value here! */
2outw(baseport + 0x76, inw(baseport + 0x76) | 0x0400);

If that doesn't fix it fully, you can also try clearing D5 (the LOSEL bit) to (re-)enable the internal speaker(?):

1int baseport = 0x2400; /* please put in the right NABMBAR value here! */
2outw(baseport + 0x76, inw(baseport + 0x76) & ~0x0020);

If that doesn't work, check out the other registers in the data sheet, e.g. "Jack Sense/Audio Interrupt Status Register (Index 72h)", if you clear D12, D11 and D10 (JSMT0, JSMT1, JSMT2), it should ignore any jack sense pin inputs and never mute based on jack sense.

Other than that, check out the data sheet and dump register contents to find something interesting.

HTH.

Ich habe absolut nix verstanden was du da geschrieben hat, aber es klingt nach einem Plan!

One install of DebianSarge (kernel 2.4 OSS soundsystem) outputs every audio on the internal speaker, the other one does not, even if the install was nearly identical (KDE<>kde-core), linux is "bastelbude". GamesKnoppix has 2.6x kernel and it just works right out of the box via sound-output on lline-out every startup(so seems to be already patched in kernel 2.6).
I setup a "B" machine which has Onboard-Sound activated and also a SB128 in the PCI slot in order to have sound in amithlon (kernel 2.4. oss-sound-> 68k ahi with redirected "newbear") .

I am thinking about what you just wrote...and try to make a new attempt-- but it's hard to understand something that is described with things I also don't understand....we will see...

Thx!

dr.zeissler wrote on 2023-10-01, 20:37:

I am thinking about what you just wrote...and try to make a new attempt-- but it's hard to understand something that is described with things I also don't understand....we will see...

Attached is a small utility (built with OpenWatcom and including source code) that can read and write the AC97 registers given the NABMBAR and register value (at least that's my understanding where those AD1980 registers are mapped). First, you have to figure out what your NABMBAR value is on the machine (i.e. where in I/O space the ports are mapped). Assuming this is e.g. 0x2400 (note that the app reads all values as hexadecimal) and you want to read the 0x76 register, you'd run it using:

1ac97test 2400 76

You can note the returned value. Note that NABMBAR might be different for each machine (and possibly even after every bootup?). Once you know the returned value (output as hex, like everything), you can then modify the value (OR the value with 0x0400, or AND the value with 0x0020, or both) and calculate a new value for this register. Let's assume you want to set it to 0x0400 (set all other bits in the register to zero), you'd do:

1ac97test 2400 76 400

If you don't want to modify the other bits, and the register doesn't read 0 at first, you have to calculate the new value manually.

This just does 16-bit reads and writes to the I/O address space. If you put in the wrong NABMBAR values or REG values, something bad might happen. You would run this after sbemu has been loaded/initialised and is running in the background.

Use at your own risk, this is pretty much untested and a shot in the dark 😀

So NABMBAR is just a IO port? I thought it would be somehow memory mapped in PCI address space. Is it really that simple?

1mov dx,2476
2in ax,dx
3or ax,400
4and ax,ffdf
5out dx,ax
6int 20

load sbemu
execute 2476.com
play something
if there is no audio execute 2876.com
play something

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

So NABMBAR is just a IO port? I thought it would be somehow memory mapped in PCI address space. Is it really that simple?

Well, it depends. It can be MMIO or I/O ports (depends on the least significant bit in the BAR address of the PCI config space). Practically, MPXPlay/sbemu don't check that and always assume I/O ports. Also, the I/O enable bit in the PCI Command Register must be set for the PCI device to react to I/O port access, this also is something that happens as a side effect of launching sbemu for AC97 (ICH) devices.

But again, that's just how I read the specs, and what sbemu does, I haven't tested this, and might be completely wrong here 😀

thp wrote on 2023-09-30, 20:58:

Pull request to add SIS7012 support to sbemu: https://github.com/crazii/SBEMU/pull/29 […]
Show full quote

Pull request to add SIS7012 support to sbemu: https://github.com/crazii/SBEMU/pull/29

Attached to this post you will find:

• an EXE build as drop-in replacement for sbemu 1.0 beta3 (download sbemu, then replace the single EXE file)
• a ZIP file with the exact source code from which the EXE was built (using DJGPP 12.2.1)

The EXE should identify itself as "1.0beta3-6-g89c8d6b", where 89c8d6b is the Git commit ID in the repo (full SHA1: 89c8d6b948b38e280f25bfa3c7d6b758ad0e0b19).

Source code is also available in the "sis7012" branch over at https://github.com/thp/sbemu

Testers welcome. Use at your own risk, I won't be held responsible if anything bad happens, etc etc. You can always take the source, study the source, and build it yourself. It Works On My Machine(tm).

That's really nice news!! I will try it end of this week or so on my sbemu 'silent' laptop.

Hm, OK, I went to FSC-S2 working AC97 in Dos/Amithlon/everywhere. I started dossound, it gave me back:
FSC-S2 => NAMBAR 2800 / 2000 Values for 76 were 10 / ffff (ac97test 2800 76 => 10, ac97test 2000 76 => ffff)

Now back to the not working machine:
FSC-E600 => NAMBAR 2800 / 2400 Values for 76 were 0 / ffff (ac97test 2800 76 => 0, ac97test 2400 76 => ffff)

So I changed the values of the not working FSC-E600 for 2800 0 => 10 (ac97test 2800 76 10) and startet dosamp to play a soundfile.
I can see that it is playing but I can't hear it on any output (line-in/out, pc-speaker)

What would you suggest next, or did I messed it up? Thx!

EDIT: I recheck AD1980 on working FSC-C610 perhaps it is different from the FSC-S2 which has AD1885)

dr.zeissler wrote on 2023-10-02, 17:49:

Hm, OK, I went to FSC-S2 working AC97 in Dos/Amithlon/everywhere. I started dossound, it gave me back: FSC-S2 => NAMBAR 2800 […]
Show full quote

Hm, OK, I went to FSC-S2 working AC97 in Dos/Amithlon/everywhere. I started dossound, it gave me back:
FSC-S2 => NAMBAR 2800 / 2000 Values for 76 were 10 / ffff (ac97test 2800 76 => 10, ac97test 2000 76 => ffff)

Now back to the not working machine:
FSC-E600 => NAMBAR 2800 / 2400 Values for 76 were 0 / ffff (ac97test 2800 76 => 0, ac97test 2400 76 => ffff)

So I changed the values of the not working FSC-E600 for 2800 0 => 10 (ac97test 2800 76 10) and startet dosamp to play a soundfile.
I can see that it is playing but I can't hear it on any output (line-in/out, pc-speaker)

What would you suggest next, or did I messed it up? Thx!

Try:

1ac97test 2800 76 400

Alternatively, also try 420 instead of 400 (you can also try 20 alone).

I wouldn't use dossound, as it just adds another layer of uncertainty and it might be fiddling with those registers in the background, etc... Use pure sbemu instead.

dr.zeissler wrote on 2023-10-02, 17:49:

EDIT: I recheck AD1980 on working FSC-C610 perhaps it is different from the FSC-S2 which has AD1885)

Yeah, that's kind of a bad comparison then, because AD1885 is a totally different chip with different register layout, so you cannot compare the contents of register 0x76, as it has completely different semantics on the other chip:

https://www.analog.com/media/en/technical-doc … eets/ad1885.pdf

SBEMU does only start when routed to IRQ7 (SET BLASTER =...I7), if I use I5 SBEMU quits without installing.
dossound does work on IRQ5 where the bios shows the AC97.

Therefore I used dossound because I think that using I7 could cause problems.

thp wrote on 2023-10-01, 22:37:

Well, it depends. It can be MMIO or I/O ports (depends on the least significant bit in the BAR address of the PCI config space). Practically, MPXPlay/sbemu don't check that and always assume I/O ports. Also, the I/O enable bit in the PCI Command Register must be set for the PCI device to react to I/O port access, this also is something that happens as a side effect of launching sbemu for AC97 (ICH) devices.

Thank you for the explanation. All makes sense now. Looks like SBEMU should report NABMBAR on command line when loading:
https://github.com/crazii/SBEMU/blob/0c857cfe … S/SC_ICH.C#L436
I dont know why fprintf(stdout doesnt print to the screen.

dr.zeissler wrote on 2023-10-02, 18:01:

SBEMU does only start when routed to IRQ7 (SET BLASTER =...I7), if I use I5 SBEMU quits without installing.
Therefore I used dossound because I think that using I7 could cause problems.

its an emulated interrupt, why do you think 7 would cause problems?

rasz_pl wrote on 2023-10-02, 18:05:

Thank you for the explanation. All makes sense now. Looks like SBEMU should report NABMBAR on command line when loading:
https://github.com/crazii/SBEMU/blob/0c857cfe … S/SC_ICH.C#L436
I dont know why fprintf(stdout doesnt print to the screen.

The debug prints seem to work (for things printed at startup, i.e. before sbemu goes into TSR mode) if you uncomment this line at the top of the file and rebuild:

1//#define MPXPLAY_USE_DEBUGF 1

If this is defined (before newfunc.h is included), then mpxplay_debugf() will print something, otherwise all debug prints are removed (in mpxplay/newfunc/newfunc.h):

1#ifdef MPXPLAY_USE_DEBUGF
2...
3#else
4 #define mpxplay_debugf(...)
5#endif// MPXPLAY_USE_DEBUGF

In my testing, mpxplay_debugf() didn't work for me when printing something after sbemu has gone into the background, but the message you linked above is indeed printed at startup when the MPXPLAY_USE_DEBUGF line is enabled.

Values for "76" are identical between a working machine (C610 AD1980 i865gv) and a not working machine (E600 AD1980 i865g).

dr.zeissler wrote on 2023-10-02, 18:48:

Values for "76" are identical between a working machine (C610 AD1980 i865gv) and a not working machine (E600 AD1980 i865g).

It doesn't matter if the registers are identical, how the chip is hooked up to outputs (and internal speakers) might very well vary between the different mainboard variants.

Does the non-working machine have working audio output under Linux 2.6.x? Better to compare the same machine with different software, otherwise it could just be a hardware fault or hardware differences to how the chip outputs are routed.

I retest linux with games-knoppix kernel 2.6x and report later/tomorrow. Thx!

FSC-E600 Mainboard D1534 i865g AC97 AD1980
- OS2/Warp4 driver 3.1.9 works in OS/2 Desktop and WinOS/2 (Fullscreen/Window) https://hobbes.nmsu.edu/?detail=%2Fpub%2Fos2% … ndMax_3-1-9.zip
- MSDOS not working in SBEMU/DOSSOUND (no error just silent)
- Amithlon Kernel 2.4x not working with Kernel 310 and drivers 0.90 (no error, just silent)
- Win2k working just fine with the driver FSC provided. https://support.ts.fujitsu.com/IndexDownload. … 5C-BD97CFEC0998

krotan wrote on 2023-08-05, 16:18:

P.S. config.sys: DEVICE=C:\SYS\SBEMU\jemmex.exe INSTALL C:\SYS\SBEMU\jload.exe C:\SYS\SBEMU\qpiemu.dll INSTALL C:\SYS\SBEMU\hdpm […]
Show full quote

P.S. config.sys:
DEVICE=C:\SYS\SBEMU\jemmex.exe
INSTALL C:\SYS\SBEMU\jload.exe C:\SYS\SBEMU\qpiemu.dll
INSTALL C:\SYS\SBEMU\hdpmi32i.exe -r -x -y
SET BLASTER=A220 I7 D1 T4
autoexec.bat:
C:\SYS\SBEMU\sbemu.exe
C:\SYS\SBEMU\hdpmi32i.exe -d
Asus Eee Pc 900

First of....
GREAT JOB TO crazii and everyone who involved in this AWESOME SOFTWARE!
I never thought I would live this long, to see the day that AC97 is possible, in MS-DOS/FREEDOS....

Okay, as for my test...
I tested on my HP Mini 110-3500 via FREEDOS, and it works. (Tested via Duke Nukem).
I can see that the OPL is really-really pushing it, as there are random short lag, for a few mili-seconds. It is fully playable, but laggy at times.
Turning off OPL in SBEMU, does make the game runs smooth without issue.

My question is, I tested this in FreeDOS,
The command above, works well with FreeDOS.
If I use MSDOS 6.22, How to replace:-

DEVICE=C:\SYS\SBEMU\jemmex.exe
INSTALL C:\SYS\SBEMU\jload.exe C:\SYS\SBEMU\qpiemu.dll

AFAIK, Jemmex.exe and jload.exe belongs to FreeDOS.
How About MSDOS 6.22? Native MSDOS 6.22, to replace and load them? (Appreciate to help a noob like me.. and my knowledge of DOS is kinda rusty.)

HP Mini 110-3500

Specs are:-
Processor Type
Intel Atom Dual Core N570

Processor Speed
1.5 GHz

RAM
1GB DDR3 RAM

Hard Disk
320 GB SATA HDD

Screen Size
10.1" HD LED Display

Webcam
1.3MP

Card Reader
Multi Card Reader
Battery
6 cell Battery with 5 hours Backup

Product Weight (Kg)
0.99 Kg

Video:-
Intel GMA3150

OK, then test OPL here:
https://www.pouet.net/prod.php?which=5488 (does not work for me)
https://www.pouet.net/prod.php?which=67581 (does not work for me)
https://www.pouet.net/prod.php?which=67506 (does not work for me)
https://www.pouet.net/prod.php?which=5936 (works for me)

If we are talking soundblaster please test:
https://www.pouet.net/prod.php?which=68187 (does not work for me)

thp wrote on 2023-10-02, 18:59:

Does the non-working machine have working audio output under Linux 2.6.x?

Can confirm GamesKnoppix 4.02 Live DVD with kernel 2.6.12 audio works just out of the box on KDE Desktop.
The crazy thing is that in the control-center on KDE Desktop shows no "sound-system" is activated...crazy...

EDIT: So perhaps no sound-server and just the working kernel AC97 audio? to bad I am far away from being a linux expert...
Doc

Panties wrote on 2023-10-03, 08:03:

If I use MSDOS 6.22, How to replace:- […]
Show full quote

If I use MSDOS 6.22, How to replace:-

DEVICE=C:\SYS\SBEMU\jemmex.exe
INSTALL C:\SYS\SBEMU\jload.exe C:\SYS\SBEMU\qpiemu.dll

AFAIK, Jemmex.exe and jload.exe belongs to FreeDOS.
How About MSDOS 6.22?

No need to replace. Use the same in MS DOS. Do not use himem.sys and emm386.exe...

dr.zeissler wrote on 2023-10-03, 09:03:

EDIT: So perhaps no sound-server and just the working kernel AC97 audio? to bad I am far away from being a linux expert...
Doc

linux audio used to be a garbage fire of a mess, dont worry too much about implementation details.
Have you tried SBEMU with

1ac97test 2800 76 400
2ac97test 2400 76 400

? you can also try ffff instead of 400 for laughs

1ac97test 2800 76 ffff

There is one more possibility, looking at SBEMU code its possible NABMBAR address might not be pre configured and dosemu sets it to 2800 but SBEMU sets it to something else entirely (0xF000 0xEF00). Since SBEMU doesnt have verbose mode and doesnt print NAMBAR we can either try blind

1ac97test F000 76 400
2ac97test EF00 76 400

or get to it somehow

1allregs .exe 24D5 8086

addresses we are interested in will be at offsets 16 and 20
#define PCIR_NAMBAR 0x10 // Native Audio Mixer Base Address
#define PCIR_NABMBAR 0x14 // Native Audio Bus Mastering Base Address