Tired latest version on my Toshiba 5205, but no luck. Says everything is fine, but games show wall of errors:

Don't use jemmex, use qemm386 or only himem.

dr.zeissler wrote on 2023-09-23, 16:50:

Don't use jemmex, use qemm386 or only himem.

Thx, will give a shot. I was just using what was packed in archive 😀

Guess I’m still doing smth wrong.

emm386 is not qemm386

Don't expect too much when using qemm386 instead of jemmex or himem+emm386.

Should the command "jload qpiemu.dll" be replaced with something else since you recommend not using jemmex? It's obvious that this command relies on it. Sorry for this newbie question, I'm definitely not good at all these DOS memory stuff. I simply copied and pasted from the readme and expected sound in DOS 😀

vorob wrote on 2023-09-24, 19:55:

Should the command "jload qpiemu.dll" be replaced with something else since you recommend not using jemmex? It's obvious that this command relies on it. Sorry for this newbie question, I'm definitely not good at all these DOS memory stuff. I simply copied and pasted from the readme and expected sound in DOS 😀

jload is used to load extensions to Jemmex. In this case, the extension being loaded, is emulating the quarterdeck Private API interface, which this software needs to go into protected mode, and trap interrupts, so they can be handled with software.

If you use actual QEMM, then you dont need to EMULATE that interface, because it is actually present. 😜

EMM386 does not offer support to have such extensions, so it can't be used for this purpose.

While looking for information on SIS7012, I found (as also mentioned in this thread) that it's mostly Intel ICH with some modifications. As I have a machine with a SIS7012, and sound output works great in Linux, I looked at the kernel sources. The SIS7012 driver is indeed implement in the same driver as the Intel ICH (sound/pci/intel8x0.c), and MPXPlay's sources also mention that it's based on ALSA (Linux driver) and ICH-DOS.

So, a quick look shows these changes are necessary between SIS7012 and "normal" ICH audio (refer to sound/pci/intel8x0.c in Linux):

• The channel mask bits (2, 4, 6 channels) in the global control block (register 0x2c) are different -- which is important for masking out the bits, but not important for setting bits, as SBEMU only uses 2-channel audio, and 2-channel audio is set by clearing the 4-channel and 6-channel bits -- that's ICH_PCM_246_MASK in both MPXPlay and Linux, Linux has the mask as ICH_SIS_PCM_246_MASK
• SIS7012 supports a "tertiary" codec with two additional flags (tertiary resume irq, tertiary codec ready)
• Linux assigns the device_type of DEVICE_SIS based on the PCI ID (MPXPlay has basically the same enum, the PCI ID is just commented out)
• In snd_intel8x0_setup_pcm_out(), the channel mask setting is different (see above)
• In snd_intel8x0_pcm_open(), both buffer_bytes_max and period_bytes_max are set to 64 KiB -- seems like we create smaller buffers anyway, so SBEMU is probably not affected by this
• In snd_intel8x0_ich_chip_init(), the LSB of register 0x4c is set, and the comment above it says "unmute the output on SIS7012", which is probably kind of important..
• Then, the ich_codec_bits[] has the tertiary for ICH4, but there's sis_codec_bits[] which has its own tertiary codec (ICH_SIS_TCR) bit
• In snd_intel8x0_init(), bdbars is 3 for DEVICE_INTEL and also 3 for DEVICE_SIS, so this is probably fine
• SIS7012 swaps the PICB (position in current buffer, offset 0x08) and SR (status, offset 0x06) registers, this is put into "roff_sr" and "roff_picb" of the ichdev, and then used throughout; would need checking/updating to fix all the occurences and swap around
• ichdev->pos_shift is 1 (divided by two) for normal ICH, and 0 (no division by two) for SIS7012, the comment above says "SIS7012 handles the pcm data in bytes, others are in samples" -- this also needs to be handled, and is mostly relevant in setting up DMA and when retrieving the PCM pointer (for writing?), there's also some reference to it in intel8x0_measure_ac97_clock(), but this seems to be only relevant for chips with a clock quirk
• Then, when setting up max_codecs, codec_bit and codec_ready_bits, it also takes care of the tertiary codec, but it might work just fine with two codecs initialized (like normal ICH)

And that's all the differences I can see in sound/pci/intel8x0.c.

I already tried patching and building a modified SBEMU, and it initializes and stuff, but no audio output is happening and PCM audio output locks up or cannot be initialized (SB emu side), OPL register writes seem to work, but again no audio output. Add to this some annoyances such as upper/lower case filenames and backslashes as path separator in #include directives, and compiling SBEMU on Linux is quite annoying (I use a recent DJGPP version to cross-compile on Linux).

Also, here's some debug output I get with my modified SBEMU (due to testing, some messages might not 100% match with the patch attached):

1SBEMU: Sound Blaster emulation on AC97. Version: 1.0 beta3
2Hello, world! device_type = 3
300:00:00.000 sc_ich.c      446 chip init : enable PCI io and busmaster
400:00:00.164 sc_ich.c      486 vend_id:1039 dev_id:7012 devtype:SIS7012 bmport:EA00 mixport:E000 irq:10
500:00:00.164 sc_ich.c      207 buffer init: pagetable:00100000 pcmoutbuf:00100100 size:4096
600:00:00.164 sc_ich.c      215 clear status bits
700:00:00.164 sc_ich.c      220 ACLink ON, set 2 channels
800:00:00.164 sc_ich.c      226 AC97 reset type: cold
900:00:00.164 sc_ich.c      235 AC97 reset timeout:1000
1000:00:00.164 sc_ich.c      239 primary codec reset timeout:1000
1100:00:00.164 sc_ich.c      250 unmute the output on SIS7012
1200:00:00.164 sc_ich.c      255 chip init end
1300:00:00.164 sc_ich.c      278 ac97 init end (vra:0)
14Found sound card: ICH AC97
15Real mode support: enabled.
16Protected mode support: enabled.
17OPL3 emulation enabled at port 388h.
18Sound Blaster Pro emulation enabled at Adress: 220, IRQ: 7, DMA: 1
1900:00:00.164 sc_ich.c      286 prepare playback: period_size_bytes:1024
2000:00:00.164 sc_ich.c      294 dma stop timeout: 1000
2100:00:00.164 sc_ich.c      301 dma stop timeout: 1000
2200:00:00.164 sc_ich.c      311 unmute the output on SIS7012
2300:00:00.164 sc_ich.c      340 AC97 front dac freq:48000 
2400:00:00.164 sc_ich.c      375 prepare playback end

In an application of Cunningham's Law, I'm posting my WIP code here, and together with the list above + the Linux kernel sources, it should be possible to add support for SIS7012 to SBEMU. Any other debugging outputs I can enable or things to test?

Edit: For cross-reference, SBEMU Github issue 27 filed.

thp wrote on 2023-09-27, 07:53:

While looking for information on SIS7012, I found (as also mentioned in this thread) that it's mostly Intel ICH with some modifi […]
Show full quote

While looking for information on SIS7012, I found (as also mentioned in this thread) that it's mostly Intel ICH with some modifications. As I have a machine with a SIS7012, and sound output works great in Linux, I looked at the kernel sources. The SIS7012 driver is indeed implement in the same driver as the Intel ICH (sound/pci/intel8x0.c), and MPXPlay's sources also mention that it's based on ALSA (Linux driver) and ICH-DOS.

So, a quick look shows these changes are necessary between SIS7012 and "normal" ICH audio (refer to sound/pci/intel8x0.c in Linux):

• The channel mask bits (2, 4, 6 channels) in the global control block (register 0x2c) are different -- which is important for masking out the bits, but not important for setting bits, as SBEMU only uses 2-channel audio, and 2-channel audio is set by clearing the 4-channel and 6-channel bits -- that's ICH_PCM_246_MASK in both MPXPlay and Linux, Linux has the mask as ICH_SIS_PCM_246_MASK
• SIS7012 supports a "tertiary" codec with two additional flags (tertiary resume irq, tertiary codec ready)
• Linux assigns the device_type of DEVICE_SIS based on the PCI ID (MPXPlay has basically the same enum, the PCI ID is just commented out)
• In snd_intel8x0_setup_pcm_out(), the channel mask setting is different (see above)
• In snd_intel8x0_pcm_open(), both buffer_bytes_max and period_bytes_max are set to 64 KiB -- seems like we create smaller buffers anyway, so SBEMU is probably not affected by this
• In snd_intel8x0_ich_chip_init(), the LSB of register 0x4c is set, and the comment above it says "unmute the output on SIS7012", which is probably kind of important..
• Then, the ich_codec_bits[] has the tertiary for ICH4, but there's sis_codec_bits[] which has its own tertiary codec (ICH_SIS_TCR) bit
• In snd_intel8x0_init(), bdbars is 3 for DEVICE_INTEL and also 3 for DEVICE_SIS, so this is probably fine
• SIS7012 swaps the PICB (position in current buffer, offset 0x08) and SR (status, offset 0x06) registers, this is put into "roff_sr" and "roff_picb" of the ichdev, and then used throughout; would need checking/updating to fix all the occurences and swap around
• ichdev->pos_shift is 1 (divided by two) for normal ICH, and 0 (no division by two) for SIS7012, the comment above says "SIS7012 handles the pcm data in bytes, others are in samples" -- this also needs to be handled, and is mostly relevant in setting up DMA and when retrieving the PCM pointer (for writing?), there's also some reference to it in intel8x0_measure_ac97_clock(), but this seems to be only relevant for chips with a clock quirk
• Then, when setting up max_codecs, codec_bit and codec_ready_bits, it also takes care of the tertiary codec, but it might work just fine with two codecs initialized (like normal ICH)

And that's all the differences I can see in sound/pci/intel8x0.c.

I already tried patching and building a modified SBEMU, and it initializes and stuff, but no audio output is happening and PCM audio output locks up or cannot be initialized (SB emu side), OPL register writes seem to work, but again no audio output. Add to this some annoyances such as upper/lower case filenames and backslashes as path separator in #include directives, and compiling SBEMU on Linux is quite annoying (I use a recent DJGPP version to cross-compile on Linux).

Also, here's some debug output I get with my modified SBEMU (due to testing, some messages might not 100% match with the patch attached):

Copy code to clipboard

1SBEMU: Sound Blaster emulation on AC97. Version: 1.0 beta3
2Hello, world! device_type = 3
300:00:00.000 sc_ich.c      446 chip init : enable PCI io and busmaster
400:00:00.164 sc_ich.c      486 vend_id:1039 dev_id:7012 devtype:SIS7012 bmport:EA00 mixport:E000 irq:10
500:00:00.164 sc_ich.c      207 buffer init: pagetable:00100000 pcmoutbuf:00100100 size:4096
600:00:00.164 sc_ich.c      215 clear status bits
700:00:00.164 sc_ich.c      220 ACLink ON, set 2 channels
800:00:00.164 sc_ich.c      226 AC97 reset type: cold
900:00:00.164 sc_ich.c      235 AC97 reset timeout:1000
1000:00:00.164 sc_ich.c      239 primary codec reset timeout:1000
1100:00:00.164 sc_ich.c      250 unmute the output on SIS7012
1200:00:00.164 sc_ich.c      255 chip init end
1300:00:00.164 sc_ich.c      278 ac97 init end (vra:0)
14Found sound card: ICH AC97
15Real mode support: enabled.
16Protected mode support: enabled.
17OPL3 emulation enabled at port 388h.
18Sound Blaster Pro emulation enabled at Adress: 220, IRQ: 7, DMA: 1
1900:00:00.164 sc_ich.c      286 prepare playback: period_size_bytes:1024
2000:00:00.164 sc_ich.c      294 dma stop timeout: 1000
2100:00:00.164 sc_ich.c      301 dma stop timeout: 1000
2200:00:00.164 sc_ich.c      311 unmute the output on SIS7012
2300:00:00.164 sc_ich.c      340 AC97 front dac freq:48000 
2400:00:00.164 sc_ich.c      375 prepare playback end

In an application of Cunningham's Law, I'm posting my WIP code here, and together with the list above + the Linux kernel sources, it should be possible to add support for SIS7012 to SBEMU. Any other debugging outputs I can enable or things to test?

Edit: For cross-reference, SBEMU Github issue 27 filed.

Thank you that might show the direction for solving my "muted/routet wrong" sound problem in DOS and AMITHLON on FSC-E600 D1534 AD1980!

I installed debian sarge (kernel 2.4,x) base install, the sound is routed directly to the PC-Speaker not to line-out. Sound is OSS not ALSA!
The mixer in KDE has to be controlled for "PCM" every other switch does not make any effect on the sound.
So OSS in DebianSarge routes the sound to "PCM" but the sound is played through the onboard-pc-speaker!

Amithlon also uses kernel 2.4.x and OSS, so if I can manager to get control over the AD1980 in DebianSarge I can get control
over the Linux-Side in Amithlon too and perhaps also solve the SB-EMU Problem, wich is probably not far away from the
other solutions.

Doc

https://web.archive.org/web/20070701062031/ht … nd.com/sources/

Installed QEMM, used auto installer. Now when I launch games with proper settings I’m getting this:

Yes, the compatibly of the SB-EMU is around 10-15% of my software, but I am not representative for what I regular use.
And the duke is played on sourceport on newer machines.

OK some updates. Both the SIS7012 and my USB controller share the same IRQ (10). I'm booting FreeDOS off a USB drive (the BIOS supports this, and makes the USB drive the "C:" drive as far as DOS is concerned).

I added some debugging code to my SIS7012 version of SBEMU, to count how often an IRQ happens, and as it turns out, the counter stops counting quite soon after starting. So I tried copying SBEMU and my small OPL playback test app to my internal disk (which has DOS 7.1 from Windows 98 SE). Booting off the USB and then cd'ing to "D:" (that's the internal disk) and then launching sbemu seemed to work better, and the interrupt count keeps counting up. However, when starting my OPL playback test app, I see the access LED on the USB stick blinking (doh -- the COMMAND.COM is still read from C:, i..e the USB). So I copy the FreeDOS COMMAND.COM also to D: and start that (and only from that start SBEMU + then my OPL test program). This seems to work more reliably.

Long story short, it seems like SIS7012 support for sbemu is finally coming together, just need to figure out why interrupts stop firing (which might very well be something to booting off of USB, but maybe not...).

However, after removing an unrelated PCI card, and rebooting, IRQ10 isn't shared anymore (between PCI devices listed at bootup, anyway), but the issue is still occurring. So it might not be related to the IRQ 10 conflict, but something else is causing interrupts to stop being fired. Wonder if it's then just about some long-running task that would block interrupt handling (or something else) that would then cause the card to stop sending interrupts?

I guess one way to debug this is to find out if the IRQ handler (ISR pointer) is overwritten or not, and then go from there. If the ISR handler is still "installed", it might point to the AC97 just stopping to send interrupts (maybe an error condition / underrun?) or something. If the ISR handler is overwritten, it might be something else that's the culprit, and the SIS7012 might function just normally. Might be tricky to find out what the issue is, then...

If had so much knowledge, I would perhaps be able to fix my AD1980 issue too...but that is not going to happen in the near future. Thx for sharing that infos!

Another SIS7012 update. It seems that if all the buffers are finished playing with AC97, DMA transfers are stopped:

Unlike HDA's stream DMAs which can keep running in cycles by themselves, AC97's DMA will stop if its read pointer catches up with the write pointer.

This seems to happen in my case, I guess some part of the system gets "slow" enough to not fill up the DMA buffer in time (this also means that the whole INT 10 shared-with-USB thing was likely a red herring).

I still have to clean my code up a bit, but I have Duke3D with Adlib sound and digital sound effects working reliably now, have also tested Doom Shareware, where at least digital sound effects work.

Setting the ICH_PO_CR_LVBIE ("last valid buffer interrupt enable") flag in the PCM OUT register 0x1B and then when the interrupt gets triggered with ICH_PO_SR_LVBCI ("last valid buffer completion interrupt") flag in set in ICH_PO_SR_REG (register 0x18 on SIS, register 0x16 on "standard" AC97), I just re-enable DMA via the ICH_PO_CR_START flag. You can still "hear" the buffer underruns when data is loaded from disk, for example - my assumption is that any "crackle" would have caused playback to stop with the old code (buffer underrun followed by stopped DMA).

Has anyone else experienced sbemu's sound output cutting out on any ICH / AC97 output device?

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 is awesome work, well done!

@thp

What do you think about my issue with the muted/routed wrong AD1980 on intel ICH (865g)?
Do you think it can be fixed in dos/linux/amithlon, due to the fact that it is working fine in Win9x/2k/OS2 and WinOS2.

Thx!

dr.zeissler wrote on 2023-10-01, 11:23:

What do you think about my issue with the muted/routed wrong AD1980 on intel ICH (865g)?
Do you think it can be fixed in dos/linux/amithlon, due to the fact that it is working fine in Win9x/2k/OS2 and WinOS2.

I have no clue. Try with a recent Ubuntu Live CD with a more modern kernel. 18.04 still supports i386 (at least in the Lubuntu variant):

https://cdimage.ubuntu.com/lubuntu/releases/18.04/release/

Once booted, see if audio works and if any alsamixer settings cause the audio to be routed correctly.

Looks like there have been changes in Linux related to AD1980 as recently as July 2023:

https://github.com/torvalds/linux/commits/mas … codecs/ad1980.c

A quick look reveals this which might be interesting (Line / Headphone swap?):

1SOC_DOUBLE("Line HP Swap Switch", AC97_AD_MISC, 10, 5, 1, 0),

thp wrote on 2023-10-01, 17:21:

A quick look reveals this which might be interesting (Line / Headphone swap?): […]
Show full quote

A quick look reveals this which might be interesting (Line / Headphone swap?):

Copy code to clipboard

1SOC_DOUBLE("Line HP Swap Switch", AC97_AD_MISC, 10, 5, 1, 0),

> AC97_AD_MISC 0x76

we tried that, somehow dossound is able to play sound under dos while reporting this register contains 0 Re: SBEMU: Sound Blaster emulation on AC97 or is lying about it