crazii wrote on 2024-01-27, 17:30:

That's really interesting... Usually there's APIC on non ISA machine, but not enabled by BIOS by default.
Currently IRQ above 15 is treated as invalid, I'll change to 0xFF instead, on next release. 😀

OK, crazii, thanks for enabling IRQs above 15. I tested the latest 05-Feb userbuild of SBEMU on this system - a Lenovo 100e netbook based upon Apollolake chipset with:
1: Intel HDA: Intel SKL (Broxton-P) (80865A98) -> Realtek (10EC0269) (max 192kHz/24bit/8ch)

and it loads, detects proper settings, etc. But absolutely nothing, no sound, no beeps, nothing from any settings (with both -O0 and -O1).

Other programs like sbmixer give errors like "hardware detection error". Other games don't detect any Soundblaster at all despite proper BLASTER= settings when SBEMU is running.

Could it have something to do with HDPMI32i? (loaded with -r -x) I'm seeing strange ** 003F8 ** message in white text as SBEMU loads. This hex message displays before SBEMU prints anything on its program display.

Strangely, the HDAPLAY program *does* detect HDA based upon Intel SKL and plays a .wav without SBEMU loaded. And, as mentioned before, Mpxplay v 1.67 works fine.

VSBHDA by Baron-von-Riedesel appears to detect everything perfectly, but gives the same symptoms as SBEMU - absolute silence.

Any ideas? Is it a register problem or conflict? I'm stumped. Seems like SBEMU should work. This Lenovo E100 laptop does not generate any PC-SPEAKER 1-bit audio (UNMUTE program doesn't work nor do any '80s game produce PC-BEEPER sound), but it does have speakers and headphone output jack for PCM digital audio generated from the Realtek ALC269 PCI card).

Is there a way to further diagnose using a program which can view registers like DOSSOUND which dr.zeissler did above in debugging / diagnosing his AD1980 AC97 chipset to work with SBEMU?

zyzzle wrote on 2024-02-07, 00:27:

and it loads, detects proper settings, etc. But absolutely nothing, no sound, no beeps, nothing from any settings (with both -O0 and -O1).

Do you mean /O0 and /O1? SBEMU uses / in MS program format.

zyzzle wrote on 2024-02-07, 00:27:

Could it have something to do with HDPMI32i? (loaded with -r -x) I'm seeing strange ** 003F8 ** message in white text as SBEMU loads. This hex message displays before SBEMU prints anything on its program display.

It's a debug message newly added to HDPMI that should be removed, don't worry, it will be on next release. and 003F8 is also weird, it should be a 4 digit Hex number. F8 is okay but 3 is somehow indicating it is incompatible with the newly added compatibility improvements.

zyzzle wrote on 2024-02-07, 00:27:

Any ideas? Is it a register problem or conflict? I'm stumped. Seems like SBEMU should work. This Lenovo E100 laptop does not generate any PC-SPEAKER 1-bit audio (UNMUTE program doesn't work nor do any '80s game produce PC-BEEPER sound), but it does have speakers and headphone output jack for PCM digital audio generated from the Realtek ALC269 PCI card).

Is there a way to further diagnose using a program which can view registers like DOSSOUND which dr.zeissler did above in debugging / diagnosing his AD1980 AC97 chipset to work with SBEMU?

No, not yet. but I remember someone uses HDAPLAY to dump HDA registers. There's a similar issue on github that produces no sound, on a Cannon Lake PCH laptop (Lenovo P53), I'll get into this later. Currently I'm diving into the compatibility improvement that will benefits some PCs, i.e. it might fix the /I7 incompatibility issue posted above and maybe more.

The problem should still be your IRQ number. HDPMI doesn't handle IRQ number above 15, and SBEMU programs on legacy 2 cascade PICs which only have 16 bit masks. and also for IRQ above 15, the entry in interrupt vector table is unknown.
I believe legacy PIC still works, it should or DOS won't work properly, but we don't how it is implemented/emulated, it needs at least 1 master, 3 slaves to support IRQs up to 31. but the legacy mode might be limited that it still has 2 PICs, and the IRQs above 15 are never routed to PICs. and the IVT vector still remains a problem.

I can re-limit the IRQ number to 15, and use the real mode pci bios (currently protected mode is used and it crashes on your PC) to re-assign a IRQ, to test if the real mode pic bios works. it might freeze on some PCs.
or we can read the APIC to find the interrupt vector (it might be above 1M for UEFI which can be accessed in protected mode), and add support to it. but this needs a lot more works.

please also be aware that mpxplay doesn't uses IRQ to feed data to sound card, that's why it works, but SBEMU needs a working IRQ/interrupt.

EDIT: this zip will use real mode PCI bios to assign IRQ, you can test if it works:

Hmm my Toughbook CF-M34 complains about Invalid Sound card IRQ: 255, trying to assign a valid IRQ... when I start sbemu. It assigns the IRQ to 10 though, with SB Pro emulation at IRQ 7. Still have no sound. pcisleep L shows the device:

100.00.1 [8086:7195] 0401    Intel      audio

So, Intel ICH AC97. Linux lspci says it's a 82440MX AC'97 Audio Controller.

How mpxplay do sound playback without IRQ? Does it poll for playback current buffer position? As it can do decoding in small chunks and nothing else to do it's probably no problem.

Legacy BIOS should probably map all IRQs into range 0-15 using IRQ sharing when there are more IRQ sources. On modern systems that underatand APIC more IRQs can be used. As modern systems discard legacy code it probably leave APIC configured in mode for modern OS so he got soundcard IRQ assigned beyond 15. Then it would need some APIC reprogramming to map soundacd IRQ somewhere below 15 to legacy range at cost of IRQ sharing but it maybe shared with some unused peripheral like USB or eth. that would't be used under DOS anyway...

RayeR wrote on 2024-02-08, 00:05:

How mpxplay do sound playback without IRQ? Does it poll for playback current buffer position? As it can do decoding in small chunks and nothing else to do it's probably no problem.

Legacy BIOS should probably map all IRQs into range 0-15 using IRQ sharing when there are more IRQ sources. On modern systems that underatand APIC more IRQs can be used. As modern systems discard legacy code it probably leave APIC configured in mode for modern OS so he got soundcard IRQ assigned beyond 15. Then it would need some APIC reprogramming to map soundacd IRQ somewhere below 15 to legacy range at cost of IRQ sharing but it maybe shared with some unused peripheral like USB or eth. that would't be used under DOS anyway...

The BIOS on this Lenovo E100 netbook is very limited. It only has options for Legacy Boot, Intel Virtualization, and "Load Optimized OS settings". It does enable support for APIC2 (but not user configurable in BIOS settings), and I think that's why IRQs may be assigned past 15 (up to 63 in fact in Legacy Mode). I turned "Load Optimized OS settings" off since BIOS says this is related to UEFI. I also turned off Virtualization in bare metal DOS 7.1 loaded from USB memory stick which is my DOS used.

I also didn't know Mpxplay doesn't use IRQs. That explains the behavior I'm seeing. HDAPLAY.EXE must also not use IRQs, either. It plays but soft volume (but perfectly fine without cracks or dropouts). I'm going to immediately test the version of SBEMU with real-mode BIOS access that crazii kindly posted, and I'll report if successfully working with sound...

RayeR wrote on 2024-02-08, 00:05:

How mpxplay do sound playback without IRQ? Does it poll for playback current buffer position? As it can do decoding in small chunks and nothing else to do it's probably no problem.

It polls the registers for playback buffer position, but not in sound card interrupts, just in the normal way, no interrupts are used if it is in foreground, when in background (TSRed) it do polls in the timer (IRQ 0, int 08h)interrupts. The initial code of SBEMU also uses timer, but the sound FX will have more latency, even pops and cracks. and SBEMU cannot program the timer since usually games will do that. so the interrupting rates is fully dependent on games, which is not good.

megatog615 wrote on 2024-02-07, 23:10:

Hmm my Toughbook CF-M34 complains about Invalid Sound card IRQ: 255, trying to assign a valid IRQ... when I start sbemu. It assi […]
Show full quote

Hmm my Toughbook CF-M34 complains about Invalid Sound card IRQ: 255, trying to assign a valid IRQ... when I start sbemu. It assigns the IRQ to 10 though, with SB Pro emulation at IRQ 7. Still have no sound. pcisleep L shows the device:

Copy code to clipboard

100.00.1 [8086:7195] 0401    Intel      audio

So, Intel ICH AC97. Linux lspci says it's a 82440MX AC'97 Audio Controller.

Finally there's a successful case on assigning IRQ... but not fully functional yet. if there's conflicts in IRQ routing options from PCI BIOS, then SBEMU simply sets the IRQ LINE (INTRRUPT LINE) in PCI config registers without calling PCI bios (that works for my laptop but obviously is problematic), I should enable the warning that PCI BIOS is not called. it will help diagnose your problem.

crazii wrote on 2024-02-07, 19:39:

EDIT: this zip will use real mode PCI bios to assign IRQ, you can test if it works:

Just tried the test version you posted on my E100. It fails with same message as other versions of SBEMU before 4th-Feb: "Detected Intel HDA at IRQ 25, Invalid IRQ, trying to assign valid IRQ" and then aborts. It does not crash, nor sigfault this time, however. So, I guess it can't find a real-mode IRQ (below 15)?

Yes, of course I tested with /O0 and /O1 not -O0 and -O1
The message printed from HDPMI32i was 03F8, not 003F8, my mistake.

zyzzle wrote on 2024-02-08, 02:40:

Just tried the test version you posted on my E100. It fails with same message as other versions of SBEMU before 4th-Feb: "Detect […]
Show full quote

crazii wrote on 2024-02-07, 19:39:

EDIT: this zip will use real mode PCI bios to assign IRQ, you can test if it works:

Just tried the test version you posted on my E100. It fails with same message as other versions of SBEMU before 4th-Feb: "Detected Intel HDA at IRQ 25, Invalid IRQ, trying to assign valid IRQ" and then aborts. It does not crash, nor sigfault this time, however. So, I guess it can't find a real-mode IRQ (below 15)?

Yes, of course I tested with /O0 and /O1 not -O0 and -O1
The message printed from HDPMI32i was 03F8, not 003F8, my mistake.

It will print a message "Failed to assign a valid IRQ for sound card, abort" and then exit. This probably means the PCI BIOS call failed. On a modern PC, this PCI BIOS function may not bother to do the implementation at all (VirtualBox doesn't implemented it) and another issue on github also causes freeze. A good PCI BIOS implementation should reprogram APIC to get it routed to the right IRQ.

crazii wrote on 2024-02-08, 01:52:

The initial code of SBEMU also uses timer, but the sound FX will have more latency, even pops and cracks. and SBEMU cannot program the timer since usually games will do that. so the interrupting rates is fully dependent on games, which is not good.

wouldnt hijacking 0x40-47 timer accesses solve this?

I wrote the SBEMU-FD13-USB.img image to my 4GB USB stick using balenaEtcher, however the drive is created the exact size of the image and there is no room left to add games that I can test with.
Do you know how I can use all the space on the USB device without corrupting the FAT file system?

rasz_pl wrote on 2024-02-08, 03:32:

crazii wrote on 2024-02-08, 01:52:

The initial code of SBEMU also uses timer, but the sound FX will have more latency, even pops and cracks. and SBEMU cannot program the timer since usually games will do that. so the interrupting rates is fully dependent on games, which is not good.

wouldnt hijacking 0x40-47 timer accesses solve this?

You mean reprogramming the timer again after game runs?

With IO port trapping to 0x40-0x47, we can skip the reprogramming part, but with or without port trapping of the timer, the most tricky part is how to override and call games' handler in a reliable manner.

And the hack is too dirty - SBBEMU needs high frequency events (at least 1ms interval), so the problem is SBEMU's timer handler should be called BEFORE games to make it work - or the games will receive unexpected timer events which is not good.

When a game reprogram timer and install its own handler, then we need to write 08h in IVT/DPMI again to overwrite games handler in the 08h interrupt itself, and reprogram the timer, then we can send low frequency event to games by some calculation.
And detection is also needed when a real mode game uninstall its handler so it is not called by SBEMU anymore after uninstallation - this can be done by using 2 handlers with different addresses: when handler A is overridden by a game then use handler B to override it again, and when the B changed to A that means a game uninstall its handler... and things might be a little more complicated when a game install multiple handlers itself or uses speaker, I never tried that in SBEMU. I remember tried some similar approach in USBDDOS (the Retrowave OPL driver before I wrote SBEMU) without port trapping of the timer, but forgot the details and results.

vico wrote on 2024-02-08, 04:26:

I wrote the SBEMU-FD13-USB.img image to my 4GB USB stick using balenaEtcher, however the drive is created the exact size of the image and there is no room left to add games that I can test with.
Do you know how I can use all the space on the USB device without corrupting the FAT file system?

I tried that too, and I got the same results as yours. so I use Rufus to write its builtin FreeDOS image to the disk, and copy sbemu manually to the disk 🤣 . You may ask @digger how to use the image in a proper way.

crazii wrote on 2024-02-08, 04:41:

You mean reprogramming the timer again after game runs? […]
Show full quote

rasz_pl wrote on 2024-02-08, 03:32:

crazii wrote on 2024-02-08, 01:52:

The initial code of SBEMU also uses timer, but the sound FX will have more latency, even pops and cracks. and SBEMU cannot program the timer since usually games will do that. so the interrupting rates is fully dependent on games, which is not good.

wouldnt hijacking 0x40-47 timer accesses solve this?

You mean reprogramming the timer again after game runs?

With IO port trapping to 0x40-0x47, we can skip the reprogramming part, but with or without port trapping of the timer, the most tricky part is how to override and call games' handler in a reliable manner.

And the hack is too dirty - SBBEMU needs high frequency events (at least 1ms interval), so the problem is SBEMU's timer handler should be called BEFORE games to make it work - or the games will receive unexpected timer events which is not good.

When a game reprogram timer and install its own handler, then we need to write 08h in IVT/DPMI again to overwrite games handler in the 08h interrupt itself, and reprogram the timer, then we can send low frequency event to games by some calculation.
And detection is also needed when a real mode game uninstall its handler so it is not called by SBEMU anymore after uninstallation - this can be done by using 2 handlers with different addresses: when handler A is overridden by a game then use handler B to override it again, and when the B changed to A that means a game uninstall its handler... and things might be a little more complicated when a game install multiple handlers itself or uses speaker, I never tried that in SBEMU. I remember tried some similar approach in USBDDOS (the Retrowave OPL driver before I wrote SBEMU) without port trapping of the timer, but forgot the details and results.

There is an option to use the PC/AT RTC interrupt capability which I believe is not widely used by DOS games https://wiki.osdev.org/RTC ? At least that usage can be a command line option. Even if that approach induces RT clock inaccuracy I do believe nobody of the DOS game players these days would care about that inaccuracy.

georgel wrote on 2024-02-08, 05:25:

crazii wrote on 2024-02-08, 04:41:

You mean reprogramming the timer again after game runs? […]
Show full quote

rasz_pl wrote on 2024-02-08, 03:32:

wouldnt hijacking 0x40-47 timer accesses solve this?

You mean reprogramming the timer again after game runs?

With IO port trapping to 0x40-0x47, we can skip the reprogramming part, but with or without port trapping of the timer, the most tricky part is how to override and call games' handler in a reliable manner.

And the hack is too dirty - SBBEMU needs high frequency events (at least 1ms interval), so the problem is SBEMU's timer handler should be called BEFORE games to make it work - or the games will receive unexpected timer events which is not good.

When a game reprogram timer and install its own handler, then we need to write 08h in IVT/DPMI again to overwrite games handler in the 08h interrupt itself, and reprogram the timer, then we can send low frequency event to games by some calculation.
And detection is also needed when a real mode game uninstall its handler so it is not called by SBEMU anymore after uninstallation - this can be done by using 2 handlers with different addresses: when handler A is overridden by a game then use handler B to override it again, and when the B changed to A that means a game uninstall its handler... and things might be a little more complicated when a game install multiple handlers itself or uses speaker, I never tried that in SBEMU. I remember tried some similar approach in USBDDOS (the Retrowave OPL driver before I wrote SBEMU) without port trapping of the timer, but forgot the details and results.

There is an option to use the PC/AT RTC interrupt capability which I believe is not widely used by DOS games https://wiki.osdev.org/RTC ? At least that usage can be a command line option. Even if that approach induces RT clock inaccuracy I do believe nobody of the DOS game players these days would care about that inaccuracy.

I remember did that tests too, but I don't remember any details, but I changed to sound interrupts for some reason.
Checked commit history, INT70 is used before, but changed to sound interrupts before beta1, see this commit
It might worth a try, but no guarantee if it works, as someone in OSDEV says it doesn't work (in the link you posted).
And It is also not reliable if a game programs and uses it, by any chance. The only independent IRQ that won't be affected by games is a PCI IRQ.

crazii wrote on 2024-02-08, 05:57:

I remember did that tests too, but I don't remember any details, but I changed to sound interrupts for some reason. Checked comm […]
Show full quote

georgel wrote on 2024-02-08, 05:25:

crazii wrote on 2024-02-08, 04:41:

You mean reprogramming the timer again after game runs? […]
Show full quote

You mean reprogramming the timer again after game runs?

With IO port trapping to 0x40-0x47, we can skip the reprogramming part, but with or without port trapping of the timer, the most tricky part is how to override and call games' handler in a reliable manner.

And the hack is too dirty - SBBEMU needs high frequency events (at least 1ms interval), so the problem is SBEMU's timer handler should be called BEFORE games to make it work - or the games will receive unexpected timer events which is not good.

When a game reprogram timer and install its own handler, then we need to write 08h in IVT/DPMI again to overwrite games handler in the 08h interrupt itself, and reprogram the timer, then we can send low frequency event to games by some calculation.
And detection is also needed when a real mode game uninstall its handler so it is not called by SBEMU anymore after uninstallation - this can be done by using 2 handlers with different addresses: when handler A is overridden by a game then use handler B to override it again, and when the B changed to A that means a game uninstall its handler... and things might be a little more complicated when a game install multiple handlers itself or uses speaker, I never tried that in SBEMU. I remember tried some similar approach in USBDDOS (the Retrowave OPL driver before I wrote SBEMU) without port trapping of the timer, but forgot the details and results.

There is an option to use the PC/AT RTC interrupt capability which I believe is not widely used by DOS games https://wiki.osdev.org/RTC ? At least that usage can be a command line option. Even if that approach induces RT clock inaccuracy I do believe nobody of the DOS game players these days would care about that inaccuracy.

I remember did that tests too, but I don't remember any details, but I changed to sound interrupts for some reason.
Checked commit history, INT70 is used before, but changed to sound interrupts before beta1, see this commit
It might worth a try, but no guarantee if it works, as someone in OSDEV says it doesn't work (in the link you posted).
And It is also not reliable if a game programs and uses it, by any chance. The only independent IRQ that won't be affected by games is a PCI IRQ.

Sorry, but RTC interrupt is thousand times more reliable than the sbemu itself. Also sbemu has so many options different for different games that this RTC interrupt can be used only as an option and if and when needed. And, if you think you would be able to program another sound card just as a source for timer driven interrupt, you could use 2 PCI sound cards.

georgel wrote on 2024-02-08, 06:01:

crazii wrote on 2024-02-08, 05:57:

I remember did that tests too, but I don't remember any details, but I changed to sound interrupts for some reason. Checked comm […]
Show full quote

georgel wrote on 2024-02-08, 05:25:

There is an option to use the PC/AT RTC interrupt capability which I believe is not widely used by DOS games https://wiki.osdev.org/RTC ? At least that usage can be a command line option. Even if that approach induces RT clock inaccuracy I do believe nobody of the DOS game players these days would care about that inaccuracy.

I remember did that tests too, but I don't remember any details, but I changed to sound interrupts for some reason.
Checked commit history, INT70 is used before, but changed to sound interrupts before beta1, see this commit
It might worth a try, but no guarantee if it works, as someone in OSDEV says it doesn't work (in the link you posted).
And It is also not reliable if a game programs and uses it, by any chance. The only independent IRQ that won't be affected by games is a PCI IRQ.

Sorry, but RTC interrupt is thousand times more reliable than the sbemu itself. Also sbemu has so many options different for different games that this RTC interrupt can be used only as an option and if and when needed. And, if you think you would be able to program another sound card just as a source for timer driven interrupt, you could use 2 PCI sound cards.

Yes it's reliable, but don't you get what I means when it is used by another game?
There's no any specific options for different games if you can tell. Besides there is no timer driven interrupts that must be used, although timer driven might work, but it doesn't have to be.
A sound card IRQ is issued when the sound card finish playing back of a buffer, and it request you attention, you naturally feed more buffer to it and that's all. no timers needed.
I don't know what's your point, I already said it's worth a try, so if you want give me a PR, I'll appreciate very much.

crazii wrote on 2024-02-08, 04:41:

rasz_pl wrote on 2024-02-08, 03:32:

crazii wrote on 2024-02-08, 01:52:

The initial code of SBEMU also uses timer, but the sound FX will have more latency, even pops and cracks. and SBEMU cannot program the timer since usually games will do that. so the interrupting rates is fully dependent on games, which is not good.

wouldnt hijacking 0x40-47 timer accesses solve this?

With IO port trapping to 0x40-0x47, we can skip the reprogramming part, but with or without port trapping of the timer, the most tricky part is how to override and call games' handler in a reliable manner.

Yes, You would have to prevent client software from being allowed to change int handler, can we trap on write attempt to IVT?

crazii wrote on 2024-02-08, 04:41:

And the hack is too dirty - SBBEMU needs high frequency events (at least 1ms interval), so the problem is SBEMU's timer handler should be called BEFORE games to make it work - or the games will receive unexpected timer events which is not good.

Set timer to whatever you need, on game access to 0x40-47 (RTC reprogramming) calculate needed divider, increment variable on every interrupt, when it hits divider call game defined handler.

crazii wrote on 2024-02-08, 04:41:

And detection is also needed when a real mode game uninstall its handler so it is not called by SBEMU anymore after uninstallation

same IVT trap would handle that

crazii wrote on 2024-02-08, 04:41:

- this can be done by using 2 handlers with different addresses: when handler A is overridden by a game then use handler B to override it again, and when the B changed to A that means a game uninstall its handler... and things might be a little more complicated when a game install multiple handlers

turtles all the way down 😀

rasz_pl wrote on 2024-02-08, 07:22:

same IVT trap would handle that

Yes and no. a real mode game can not be trapped by DPMI, but maybe yes with another hack to the V86 monitor (usually an EMM manager, i.e. JEMMEX), I'm not sure - I haven't read any thing about VM mode in the Intel programming manual yet.

EDIT: currently HDPMI can trap the access to IVT by paging privileges mechanism in protected mode, and I think V86 monitors can do that too.