zyga64 wrote on 2023-02-15, 09:07:

I can now confirm that DOOM 1 and DOOM 2 work perfectly on my Pentium M laptop with FM sound and SFX in plain dos (HP NX7000 - i855PM, Radeon Mobility 9000/9200, AC97 AD1981B(L)).
Duke 3D also works but there is no volume control for SFX (switching SFX off works).

Good to hear that!
Yes the master volume register is not handled yet. I'm planning to that support, plus external hotkeys to adjust volumes, i.e. "RCtrl"+"RAlt"+"-/=".

Baron von Riedesel wrote on 2023-02-15, 07:59:

As for me, I avoid testing it on VBox or Qemu, these are not the target platforms for SBEMU.

Agreed. I just need a convenient environment to debug. real machine is not my type. 🤣

crazii wrote on 2023-02-15, 09:40:

AFAIK PVI is only effective in protected mode, it's called Protected mode Virtual Interrupt anyway. the similar one VME is working in VM86. they are supported if CPUID has "Virtual 8086 mode extensions" feature.

Yes, I mixed them incorrectly because they are very similar but still V8086 is as a protected mode too therefore PVI may be effective in V8086 too...

crazii wrote on 2023-02-15, 09:32:

you mean the INS/OUTS string instructions?

Yes - see https://github.com/Baron-von-Riedesel/HX/blob … MI/HDPMIAPI.TXT for details.

I attached the source of the binaries, just in case.

https://www.felixcloutier.com/x86/popf:popfd:popfq
>The protected-mode virtual-interrupt feature — enabled by setting CR4.PVI — affects the CLI and STI instructions in the same manner as the virtual-8086 mode extensions. POPF, however, is not affected by CR4.PVI

http://www.rcollins.org/ftp/articles/pvi1/pvi1.txt is not clear either

https://xem.github.io/minix86/manual/intel-x8 … 80e0ce-996.html

When the PVI flag is set to 1, the CPL is 3, and the IOPL is less than 3, the STI and CLI instructions set and clear the VIF fl […]
Show full quote

When the PVI flag is set to 1, the CPL is 3, and the IOPL is less than 3, the STI and CLI instructions set and clear
the VIF flag in the EFLAGS register, leaving IF unaffected. In this mode of operation, an application running in
protected mode and at a CPL of 3 can inhibit interrupts in the same manner as is described in Section 20.3.2, “Class
2—Maskable Hardware Interrupt Handling in Virtual-8086 Mode Using the Virtual Interrupt Mechanism”, for a
virtual-8086 mode task. When the application executes the CLI instruction, the processor clears the VIF flag. If the
processor receives a maskable hardware interrupt, the processor invokes the protected-mode interrupt handler.
This handler checks the state of the VIF flag in the EFLAGS register. If the VIF flag is clear (indicating that the active
task does not want to have interrupts handled now), the handler sets the VIP flag in the EFLAGS image on the stack
and returns to the privilege-level 3 application, which continues program execution. When the application executes
a STI instruction to set the VIF flag, the processor automatically invokes the general-protection exception handler,
which can then handle the pending interrupt. After handing the pending interrupt, the handler typically sets the VIF
flag and clears the VIP flag in the EFLAGS image on the stack and executes a return to the application program. The
next time the processor receives a maskable hardware interrupt, the processor will handle it in the normal manner
for interrupts received while the processor is operating at a CPL of 3.

Still doesnt affect POPF. Now Im lost. Whats the point of PVI? How does it help with silently ignored POPF? It looks like with PVI hypervisor can keep receiving interrupts thus doesnt hang, but you still dont know when to start sending them down to client/application?

rasz_pl wrote on 2023-02-15, 17:28:

Still doesnt affect POPF. Now Im lost. Whats the point of PVI? How does it help with silently ignored POPF? It looks like with PVI hypervisor can keep receiving interrupts thus doesnt hang, but you still dont know when to start sending them down to client/application?

PVI just skip a #GP exception and set VIF directly, in that case it doesn't handle POPF, only make STI/CLI a little faster, maybe fast enough to skip some problem I guess.

Baron von Riedesel wrote on 2023-02-15, 16:45:

crazii wrote on 2023-02-15, 09:32:

you mean the INS/OUTS string instructions?

Yes - see https://github.com/Baron-von-Riedesel/HX/blob … MI/HDPMIAPI.TXT for details.

I attached the source of the binaries, just in case.

OK, I tested some games and found no games uses INS/OUTS so I just leave it with a TODO. 🤣

I haven't check the source yet. Does that means you are planning to implement port trap API or already started? Or already done? Since I tested my SBEMU build with you HDPMI32i, it doesn't startup.
Last time I remember you didn't plan to add the port trap API so I forked my own, unprofessional implementations. It seems your don't like my PR, neither to PR to my code base, now we both have 2 different version of HDPMI and SBEMU. No offense, I'm really glad that you helped, I think you'll do far better than me. I was just thinking we probably need align to the same code base , it's my humble suggestion, a suggestion that I cannot even follow for now, since I have my local HDPMI modified too much for debugging. Now that you have the modified source uploaded, I'll check it later. 😁

BTW I've added a IRQ mask that can prevent any IRQ reentrance, I tested it for all IRQs or only IRQ10/11 (empty IRQ usually used for PCI sound card), and doom will run to the "set up heads up display", but still freeze. I got no idea now. Maybe the whole idea is wrong. need more debug.

Baron von Riedesel wrote on 2023-02-10, 06:19:

crazii wrote on 2023-02-09, 08:55:

Why there's a IRQs being handled while the previous IRQ isn't "finished"? I think the IF should be always cleared when handling IRQs.

Yes. Nevertheless, I added a little assenbly routine to function MAIN_InterruptPM():

NO, the IF is cleared only if an interrupt is serviced via an interrupt gate. If it is serviced via a trap gate then IF remains unchanged. Check your IDT (or more precisely the DOS4GW's and JEMM's IDTs), guys.

georgel wrote on 2023-02-15, 19:39:

Baron von Riedesel wrote on 2023-02-10, 06:19:

crazii wrote on 2023-02-09, 08:55:

Why there's a IRQs being handled while the previous IRQ isn't "finished"? I think the IF should be always cleared when handling IRQs.

Yes. Nevertheless, I added a little assenbly routine to function MAIN_InterruptPM():

NO, the IF is cleared only if an interrupt is serviced via an interrupt gate. If it is serviced via a trap gate then IF remains unchanged. Check your IDT (or more precisely the DOS4GW's and JEMM's IDTs), guys.

I didn't remember that. but I think Baron von Riedesel is pretty clear, he's been on the HDPMI project for many years that it's unlikely he made such mistakes. For me on the other hand, I haven't doing lowlevel programming for more than 10years and I need check a Intel manual on the fly. 🤣

BTW I check the code and all the gates for IRQs are interrupt gates.

crazii wrote on 2023-02-15, 18:53:

Does that means you are planning to implement port trap API or already started? Or already done?

It's done.

It seems your don't like my PR, neither to PR to my code base,

I'm not aware of any PRs. But you're right, I'm pretty hesitant to accept PRs for HDPMI - perhaps because I can't imagine that anyone except me is able to understand the source 😀.

I was just thinking we probably need align to the same code base , it's my humble suggestion, a suggestion that I cannot even follow for now, since I have my local HDPMI modified too much for debugging.

No need for a hurry. I guess in the long run you'll adjust your sbemu to the standard hdpmi. SBEMU is your project, I'm not planning to release a fork.

BTW I've added a IRQ mask that can prevent any IRQ reentrance, I tested it for all IRQs or only IRQ10/11 (empty IRQ usually used for PCI sound card), and doom will run to the "set up heads up display", but still freeze. I got no idea now. Maybe the whole idea is wrong. need more debug.

Yes, please do. Like myself, you will finally realize that DJGPP's and DOS4GW's interrupt handling isn't compatible - they're probably compatible when running in a Windows DOS box, but HDPMI, unlike Windows, does not include a v86 monitor and hence has to behave differently in this regard.

Btw., two bugs that should be fixed in SBEMU:

- pressing Ctrl-C/Ctrl-Break causes the TSR to "exit" ( which usually results in a DOS MCB chain corruption ).
- if the emulated sound IRQ and the real sound HW IRQ are identical, the emulation doesn't work. This case can probably be handled properly, but for now it might be sufficient if SBEMU displays an error and exits.

georgel wrote on 2023-02-15, 19:39:

Check your IDT (or more precisely the DOS4GW's and JEMM's IDTs), guys.

To be even more precise: it's HDPMI's and JEMM's IDTs, because that's the idea of this project.

This seems like a dream project. Most of my modern systems (laptops) have Intel IHD / HDA audio, but I have a couple of desktops with AC'97 codec and I'll try them. Should I stick to DOS4GW (most of which I've stubbed over to DOS/32a, which claims to be 100% compatible and improve upon the original DOS4GW 1.97 / 2.01 versions) or should I focus on CWSDPMI games? I'll start with Doom, Doom2, Duke3d.

Note that for Intel HDA / IHD, there already exists a great library called libau which supports these modern chipsets using the -sndpci config option when starting Quake 1 or 2 through special binaries compiled with libau called Q1 / Q2dos, Hexen 2, Doom through a custon Zdoom binary compiled with libau library, etc.

However, your emulator TSR appears to be generic enough that it doesn't need special compiled binaries of the games, it just needs to be loaded first as a wrapper in memory?

I know that CWSDPMI and DOS4GW / Dos 32/A aren't compatible. Which ones have the best chance at working with your SB emulator for modern PCI chipset audio?

Once again, congrats on the project. Let's keep sound and modern PCI audio chipsets usable as long as possible. I strongly dislike being forced to work in abstraction layers, like DOSBOX, QEMU, et. al. It's so artificial and uses 10x the processing power to accomplish a task done far more efficiently, eloquenrly, and cleanly in bare DOS on modern CPUs.

Such a shame that 16-bit and BIOS / non-UEFI have been castrated by the usual suspects, Microsoft and Intel, because they're too lazy to spend a dime a part on legacy vBIOSes for their OEMs. Getting CSM VGA-compatible video working on modern systems should be a sister project to this audio emulator. Like a sort of Univbe for modern Intel onboard video chipsets!

Baron von Riedesel wrote on 2023-02-16, 04:03:

Yes, please do. Like myself, you will finally realize that DJGPP's and DOS4GW's interrupt handling isn't compatible - they're probably compatible when running in a Windows DOS box, but HDPMI, unlike Windows, does not include a v86 monitor and hence has to behave differently in this regard.

Incompatible how? Is there any workaround?
I believe it is not the reason causing doom freeze, at least not the only reason. because I've tested without SBEMU's IRQ handling - a version that did nothing but emulate the port io. and doom still freeze, or there's stack overflow. You can test it too, just change PM_ISR = TRUE and comment out the next line of PIC_UmaskIRQ, then there should be no interrupts handling in DJGPP, yet doom still freeze.
DJGPP's interrupt handling simply calls DPMI API - you can get the source code from DJGPP site. the go32 wrapper that SBEMU used, is very simple too, the source code is available at DJGPP site too and I've read it. Besides calling DPMI's API, the go32 allocate an extra stack and put some entrance executable opcodes there. the executable codes stores the interrupted context and load the DGJGPP app's segments, jump to the app handler and then restore context and return, nothing unordinary.

Here's the go32 wrapper code, I believe it is the only extra codes besides calling DPMI API to set/get pm interrupt vector.

1static unsigned char wrapper_intcommon[] = {
2/* 00 */ 0x1e,				/*     push ds              	*/
3/* 01 */ 0x06,				/*     push es			*/
4/* 02 */ 0x0f, 0xa0,			/*     push fs              	*/
5/* 04 */ 0x0f, 0xa8,			/*     push gs              	*/
6/* 06 */ 0x60,				/*     pusha                	*/
7/* 07 */ 0x66, 0xb8,			/*     mov ax,			*/
8/* 09 */ FILL, FILL,			/*         _our_selector	*/
9/* 0B */ 0x8e, 0xd8,			/*     mov ds, ax           	*/
10/* 0D */ 0xff, 0x05, 			/*     incl			*/
11/* 0F */ FILL, FILL, FILL, FILL,	/*	    _call_count		*/
12/* 13 */ 0x83, 0x3d,			/*     cmpl			*/
13/* 15 */ FILL, FILL, FILL, FILL,	/*         _in_this_handler	*/
14/* 19 */ 0x00,				/*         $0			*/
15/* 1A */ 0x75,				/*     jne			*/
16/* 1B */ 0x2F,				/*         bypass		*/
17/* 1C */ 0xc6, 0x05,			/*     movb			*/
18/* 1E */ FILL, FILL, FILL, FILL,	/*         _in_this_handler 	*/
19/* 22 */ 0x01,				/*         $1			*/
20/* 23 */ 0x8e, 0xc0,			/*     mov es, ax           	*/
21/* 25 */ 0x8e, 0xe0,			/*     mov fs, ax           	*/
22/* 27 */ 0x8e, 0xe8,			/*     mov gs, ax           	*/
23/* 29 */ 0xbb,				/*     mov ebx,			*/
24/* 2A */ FILL, FILL, FILL, FILL,	/*         _local_stack		*/
25/* 2E */ 0xfc,				/*     cld                  	*/
26/* 2F */ 0x89, 0xe1,			/*     mov ecx, esp         	*/
27/* 31 */ 0x8c, 0xd2,			/*     mov dx, ss           	*/
28/* 33 */ 0x8e, 0xd0,			/*     mov ss, ax           	*/
29/* 35 */ 0x89, 0xdc,			/*     mov esp, ebx         	*/
30/* 37 */ 0x52,				/*     push edx             	*/
31/* 38 */ 0x51,				/*     push ecx             	*/
32/* 39 */ 0xe8,				/*     call			*/
33/* 3A */ FILL, FILL, FILL, FILL,	/*         _rmih		*/
34/* 3E */ 0x58,				/*     pop eax                 	*/
35/* 3F */ 0x5b,				/*     pop ebx                 	*/
36/* 40 */ 0x8e, 0xd3,			/*     mov ss, bx               */
37/* 42 */ 0x89, 0xc4,			/*     mov esp, eax             */
38/* 44 */ 0xc6, 0x05,			/*     movb			*/
39/* 46 */ FILL, FILL, FILL, FILL,	/*         _in_this_handler	*/
40/* 4A */ 0x00,				/*         $0			*/
41/* 4B */ 0x61,				/* bypass:  popa		*/
42/* 4C */ 0x90,				/*     nop			*/
43/* 4D */ 0x0f, 0xa9,			/*     pop gs                   */
44/* 4F */ 0x0f, 0xa1,			/*     pop fs                   */
45/* 51 */ 0x07,				/*     pop es                   */
46/* 52 */ 0x1f				/*     pop ds                   */
47};
48
49static unsigned char wrapper_intiret[] = {
50/* 53 */ 0xcf,				/*     iret                     */
51};
52
53static unsigned char wrapper_intchain[] = {
54/* 53 */ 0x2e, 0xff, 0x2d,		/*     jmp     cs: 		*/
55/* 56 */ FILL, FILL, FILL, FILL,	/*     [_old_int+39] 		*/
56/* 5A */ 0xcf,				/*     iret                     */
57/* 5B */ FILL, FILL, FILL, FILL,	/*     old_address 		*/
58/* 5F */ FILL, FILL,			/*     old_segment 		*/
59};

Interesting project, thanks for it. This gives hope to add protected mode support to SoftMPU , but the damn differences in GNU-syntax here and the intel-syntax in SoftMPU will cause a lot of code redoing...
This project is not built in Watcom compiler because HDPMIPT.C has a lot of inline code in GNU-assembler syntax;
SoftMPU is not assembled in DJGPP because MIDI.C and MPU401.C has a lot of code in intel-assembler syntax.
And it is not clear - either change the code in SoftMPU so that it is compiled by DJGPP, or change the code in HDPMIPT.C so that it is compiled by Watcom or Microsoft C in general ...

crazii wrote on 2023-02-16, 09:38:

Incompatible how? Is there any workaround? I believe it is not the reason causing doom freeze, at least not the only reason. bec […]
Show full quote

Baron von Riedesel wrote on 2023-02-16, 04:03:

Yes, please do. Like myself, you will finally realize that DJGPP's and DOS4GW's interrupt handling isn't compatible - they're probably compatible when running in a Windows DOS box, but HDPMI, unlike Windows, does not include a v86 monitor and hence has to behave differently in this regard.

Incompatible how? Is there any workaround?
I believe it is not the reason causing doom freeze, at least not the only reason. because I've tested without SBEMU's IRQ handling - a version that did nothing but emulate the port io. and doom still freeze, or there's stack overflow. You can test it too, just change PM_ISR = TRUE and comment out the next line of PIC_UmaskIRQ, then there should be no interrupts handling in DJGPP, yet doom still freeze.
DJGPP's interrupt handling simply calls DPMI API - you can get the source code from DJGPP site. the go32 wrapper that SBEMU used, is very simple too, the source code is available at DJGPP site too and I've read it. Besides calling DPMI's API, the go32 allocate an extra stack and put some entrance executable opcodes there. the executable codes stores the interrupted context and load the DGJGPP app's segments, jump to the app handler and then restore context and return, nothing unordinary.

Then can you for testing purpose stop the IO port trapping but use a real ISA sound card instead. Just init and stay in memory and check if Doom still hangs under the very same EMM and DPMI server.

Tronix wrote on 2023-02-16, 09:58:

Interesting project, thanks for it. This gives hope to add protected mode support to SoftMPU , but the damn differences in GNU-s […]
Show full quote

Interesting project, thanks for it. This gives hope to add protected mode support to SoftMPU , but the damn differences in GNU-syntax here and the intel-syntax in SoftMPU will cause a lot of code redoing...
This project is not built in Watcom compiler because HDPMIPT.C has a lot of inline code in GNU-assembler syntax;
SoftMPU is not assembled in DJGPP because MIDI.C and MPU401.C has a lot of code in intel-assembler syntax.
And it is not clear - either change the code in SoftMPU so that it is compiled by DJGPP, or change the code in HDPMIPT.C so that it is compiled by Watcom or Microsoft C in general ...

GCC(DJGPP) also support intel syntax, but it have a different way to access local variables. There's a set macros in PLATFORM.H with hide the difference of C-Compilers inline assemblies.
An example is the void QEMM_RM_Wrapper() in QEMM.C, with _ASM(), _ASM_BEGIN and _ASM_END those macro should compile with both Watcom and DJGPP.
But the only problem's open watcom's 32bit compiler doesn't support 16bit inline assembly, if it matters to you.

georgel wrote on 2023-02-16, 10:01:

crazii wrote on 2023-02-16, 09:38:

Incompatible how? Is there any workaround? I believe it is not the reason causing doom freeze, at least not the only reason. bec […]
Show full quote

Baron von Riedesel wrote on 2023-02-16, 04:03:

Yes, please do. Like myself, you will finally realize that DJGPP's and DOS4GW's interrupt handling isn't compatible - they're probably compatible when running in a Windows DOS box, but HDPMI, unlike Windows, does not include a v86 monitor and hence has to behave differently in this regard.

Incompatible how? Is there any workaround?
I believe it is not the reason causing doom freeze, at least not the only reason. because I've tested without SBEMU's IRQ handling - a version that did nothing but emulate the port io. and doom still freeze, or there's stack overflow. You can test it too, just change PM_ISR = TRUE and comment out the next line of PIC_UmaskIRQ, then there should be no interrupts handling in DJGPP, yet doom still freeze.
DJGPP's interrupt handling simply calls DPMI API - you can get the source code from DJGPP site. the go32 wrapper that SBEMU used, is very simple too, the source code is available at DJGPP site too and I've read it. Besides calling DPMI's API, the go32 allocate an extra stack and put some entrance executable opcodes there. the executable codes stores the interrupted context and load the DGJGPP app's segments, jump to the app handler and then restore context and return, nothing unordinary.

Then can you for testing purpose stop the IO port trapping but use a real ISA sound card instead. Just init and stay in memory and check if Doom still hangs under the very same EMM and DPMI server.

It could be tested, but my ISA board is never used/tested when I bought it. I have a plenty of laptops with PCI cards. like YMF7x4, and ESS-Solo-1.

crazii wrote on 2023-02-16, 10:25:

georgel wrote on 2023-02-16, 10:01:

crazii wrote on 2023-02-16, 09:38:

Incompatible how? Is there any workaround?
I believe it is not the reason causing doom freeze, at least not the only reason. because I've tested without SBEMU's IRQ handling - a version that did nothing but emulate the port io. and doom still freeze, or there's stack overflow. You can test it too, just change PM_ISR = TRUE and comment out the next line of PIC_UmaskIRQ, then there should be no interrupts handling in DJGPP, yet doom still freeze.
DJGPP's interrupt handling simply calls DPMI API - you can get the source code from DJGPP site. the go32 wrapper that SBEMU used, is very simple too, the source code is available at DJGPP site too and I've read it. Besides calling DPMI's API, the go32 allocate an extra stack and put some entrance executable opcodes there. the executable codes stores the interrupted context and load the DGJGPP app's segments, jump to the app handler and then restore context and return, nothing unordinary.

Then can you for testing purpose stop the IO port trapping but use a real ISA sound card instead. Just init and stay in memory and check if Doom still hangs under the very same EMM and DPMI server.

It could be tested, but my ISA board is never used/tested when I bought it. I have a plenty of laptops with PCI cards. like YMF7x4 PCI card, and ESS-Solo-1.

If these sound cards can adjust their resources to ISA sound card addresses without leaving/relying after initialization on memory resident utilities then they are fine for the proposed test. Just make sure after their init there are no TSRs left in DOS memory or EMM/XMM handles allocated.

crazii wrote on 2023-02-16, 09:38:

Incompatible how? Is there any workaround?
I believe it is not the reason causing doom freeze, at least not the only reason. because I've tested without SBEMU's IRQ handling - a version that did nothing but emulate the port io. and doom still freeze, or there's stack overflow. You can test it too, just change PM_ISR = TRUE and comment out the next line of PIC_UmaskIRQ, then there should be no interrupts handling in DJGPP, yet doom still freeze.

The "incompatibility" I meant is not related to the "freeze", but to the "transfer stack overflow". It's caused by a PM-RM-PM-RM-PM-...-switch cascade, apparently because djgpp's and dos4gw's assumptions about some details of IRQ routing differ. At least that's my understanding and that's why I implemented some asm code to hide the HW sound IRQ from dos4gw.

The "freeze" is definitely a dos4gw bug. Might be interesting to try DOOM in a Win31 DOS box on a real machine. Win3x in enhanced mode was released before any PVI flag was invented, so according to that theory DOOM in a Win31 DOS box should also "freeze"...