Baron von Riedesel wrote on 2023-02-24, 14:37:

crazii wrote on 2023-02-24, 13:06:

I'm more worried about real mode, the context may be hard to get if interrupt happens in VM monitor IDT and routed to HDPMI, I guess. -OK, most real mode games have multiple segments so they usually don't make assumptions about data segments.

Real-mode isn't such a concern , because hdpmi takes care that the real-mode segment registers are restored when the emulated interrupt is launched. However, this is only true if you launch the interrupt with asm("int 7"), not if you launch it with the _dpmi_callrealmode_iret() function ( because in that case you have to provide the segment registers on your own ).

OK, I integrate your commit and now INT 0Dh/0Fh works, and I also added back getting interrupt context vendor api, if context is VM I'll use the call real mode method, if PM, I manually restore the context and then INT, everything works, games have sounds, but MDK still have no keyboard input. I think is a special incompatibility problem.

EDIT: tried MDK without SBEMU, keyboard not working either. tried MDK without HDPMI, keyboard working.

crazii wrote on 2023-02-24, 06:42:

It's weird that Prince of Persia 1 & 2 doesn't work on your PC. They are the very first games I tested on my 1.1GHz & 1.8GHz rea […]
Show full quote

It's weird that Prince of Persia 1 & 2 doesn't work on your PC. They are the very first games I tested on my 1.1GHz & 1.8GHz real machine, and they still work on mine, it might be possibly a CPU speed related problem.

/T6 still uses 22050Hz, I think it will cover most scenarios, maybe an extra parameter could be added to set the other sample rate.
BTW if your sound card don't support 22050/44100 (this is possible), then SBEMU will use 48000, which is mandatory for AC97/HDA.
44100Hz will use more CPU power for games, some games only have 11025 (or maybe even lower, 6k, 8k), to convert 11025 to 44100 there's precision lost(based on current interpolation method), and need to enlarge the samples to 4x size using interpolation.

I got both Prince of Persia 1 and 2 working, finally. There are two (DOS) versions of both POP 1 and POP2. The first release (1.0) of Persia didn't work, but installing the v. 1.4 release did. Prince of Persia 2 v. 1.0 and 1.2 both work for me with SBEMU now. I am sorry for the confusion; it seems to be no fault of SBEMU, but the (earlier) versions of those games I tested before.

And, I think an option to set internal sample rate (and bitdepth for 8 or 16 bit) of SBEMU will will an extremely useful, even critical feature. It is true most games don't use or need 16-bit stereo audio at 44.1 Khz or 48000 hz. However, if one plays CD audio files .WAV or .FLAC using MPXPlay or Mplayer, these are native 16-bit, unsigned little-endian 44100 hz stereo PCM audio. So, there should be an option within SBEMU to match this rate, especially in SB16 emulation mode. We are using "modern" fast systems here, mostly, so the additional system overheard / 4x increase in bandwidth should be totally OK on a modern fast core i3/i5/i7 system. If it's possible to make this a commandline option of SBEMU, that will be fantastic beyond words!

Bondi wrote on 2023-02-24, 12:01:

I also tried Duke 2 - a real mode game. Good news is that it runs stably and has music and Adlib effects. SB digital doesn't work, just some scratching gets through sometimes instead of a shot sound. Still not a bad result as it's a picky game if sound is concerned.

That's the same behavior for me on my HDA system ("scratchy" and "disappearing" digital audio on Apogee real-mode games). For most real-mode Apogee games, including Duke 2. Totally correct, wonderful Admib / SB music (using OPL 2/3) and scratchy or "disappearing" digitized sound effects. You can tell there is digital sound being send to the speaker, as sometimes I get a brief scratch or sound. Another strange Apogee game is Halloween Harry. Its "music" and "digital sound effects" are all sampled, and I get about 1-5 seconds of sound out of it, then silence. Using /T1 or /T6 parameter in SBEMU. My BLASTER config is A220 I7 D1. That config seems most stable in real-mode games I've tried.

SBEMU seems to work perfectly with HMI Sound library. I tried Abuse and Tunnel B1 games and they work fine. Both are protected mode games. The latter is a forgotten late DOS era game and is notable for being very heavy on CPU, and I've never seen run it smoothly in high detail on any system before 😁

crazii wrote on 2023-02-24, 17:16:

Baron von Riedesel wrote on 2023-02-24, 14:37:

crazii wrote on 2023-02-24, 13:06:

I'm more worried about real mode, the context may be hard to get if interrupt happens in VM monitor IDT and routed to HDPMI, I guess. -OK, most real mode games have multiple segments so they usually don't make assumptions about data segments.

Real-mode isn't such a concern , because hdpmi takes care that the real-mode segment registers are restored when the emulated interrupt is launched. However, this is only true if you launch the interrupt with asm("int 7"), not if you launch it with the _dpmi_callrealmode_iret() function ( because in that case you have to provide the segment registers on your own ).

OK, I integrate your commit and now INT 0Dh/0Fh works, and I also added back getting interrupt context vendor api, if context is VM I'll use the call real mode method, if PM, I manually restore the context and then INT, everything works, games have sounds, but MDK still have no keyboard input. I think is a special incompatibility problem.

EDIT: tried MDK without SBEMU, keyboard not working either. tried MDK without HDPMI, keyboard working.

I'm interested in this version. If you share this one as well, I'm gonna test it with the problematic games on my system.

zyzzle wrote on 2023-02-25, 01:38:

crazii wrote on 2023-02-24, 06:42:

It's weird that Prince of Persia 1 & 2 doesn't work on your PC. They are the very first games I tested on my 1.1GHz & 1.8GHz rea […]
Show full quote

It's weird that Prince of Persia 1 & 2 doesn't work on your PC. They are the very first games I tested on my 1.1GHz & 1.8GHz real machine, and they still work on mine, it might be possibly a CPU speed related problem.

/T6 still uses 22050Hz, I think it will cover most scenarios, maybe an extra parameter could be added to set the other sample rate.
BTW if your sound card don't support 22050/44100 (this is possible), then SBEMU will use 48000, which is mandatory for AC97/HDA.
44100Hz will use more CPU power for games, some games only have 11025 (or maybe even lower, 6k, 8k), to convert 11025 to 44100 there's precision lost(based on current interpolation method), and need to enlarge the samples to 4x size using interpolation.

I got both Prince of Persia 1 and 2 working, finally. There are two (DOS) versions of both POP 1 and POP2. The first release (1.0) of Persia didn't work, but installing the v. 1.4 release did. Prince of Persia 2 v. 1.0 and 1.2 both work for me with SBEMU now. I am sorry for the confusion; it seems to be no fault of SBEMU, but the (earlier) versions of those games I tested before.

And, I think an option to set internal sample rate (and bitdepth for 8 or 16 bit) of SBEMU will will an extremely useful, even critical feature. It is true most games don't use or need 16-bit stereo audio at 44.1 Khz or 48000 hz. However, if one plays CD audio files .WAV or .FLAC using MPXPlay or Mplayer, these are native 16-bit, unsigned little-endian 44100 hz stereo PCM audio. So, there should be an option within SBEMU to match this rate, especially in SB16 emulation mode. We are using "modern" fast systems here, mostly, so the additional system overheard / 4x increase in bandwidth should be totally OK on a modern fast core i3/i5/i7 system. If it's possible to make this a commandline option of SBEMU, that will be fantastic beyond words!

Great! I didn't know the difference between different prince of persia vesions, and I didn't even know the version I have.
I think it'll be no problem to add a option to set sample rate.

KormaX wrote on 2023-02-25, 12:01:

crazii wrote on 2023-02-24, 17:16:

Baron von Riedesel wrote on 2023-02-24, 14:37:

Real-mode isn't such a concern , because hdpmi takes care that the real-mode segment registers are restored when the emulated interrupt is launched. However, this is only true if you launch the interrupt with asm("int 7"), not if you launch it with the _dpmi_callrealmode_iret() function ( because in that case you have to provide the segment registers on your own ).

OK, I integrate your commit and now INT 0Dh/0Fh works, and I also added back getting interrupt context vendor api, if context is VM I'll use the call real mode method, if PM, I manually restore the context and then INT, everything works, games have sounds, but MDK still have no keyboard input. I think is a special incompatibility problem.

EDIT: tried MDK without SBEMU, keyboard not working either. tried MDK without HDPMI, keyboard working.

I'm interested in this version. If you share this one as well, I'm gonna test it with the problematic games on my system.

OK, I'll do more test, probably need 1 hour or 2.

I was debugging MDK using VirtualBox debugger today, it will hook IVT with a real mode keyboard driver, and a protected one, but the protected one does nothing, just call the real mode int09 handler (probably through int30h, or call real mode int, I didn't step into the end). However the irq is not routed to it's real mode handler, but to the original bios - I trapped 0x60 and 0x64 there's IO indeed, and when I quit the game using mouse, the command line will show the chars I pressed.

I recall that my TSR cannot call the newly hooked IVT for real mode games using call real mode int (I need to read IVT and use call iret), are those related?

crazii wrote on 2023-02-25, 12:48:

I was debugging MDK using VirtualBox debugger today, it will hook IVT with a real mode keyboard driver, and a protected one, but the protected one does nothing, just call the real mode int09 handler (probably through int30h, or call real mode int, I didn't step into the end). However the irq is not routed to it's real mode handler, but to the original bios - I trapped 0x60 and 0x64 there's IO indeed, and when I quit the game using mouse, the command line will show the chars I pressed.

I recall that my TSR cannot call the newly hooked IVT for real mode games using call real mode int (I need to read IVT and use call iret), are those related?

I see. Yes, that's a problem that cannot be really fixed by hdpmi, because it's a VCPI client. However, depending on how the real-mode handler is installed, MDK's keyboard might work if one set environment variable HDPMI=1 ( BEFORE hdpmi32i is installed! ).

Baron von Riedesel wrote on 2023-02-25, 13:03:

crazii wrote on 2023-02-25, 12:48:

I was debugging MDK using VirtualBox debugger today, it will hook IVT with a real mode keyboard driver, and a protected one, but the protected one does nothing, just call the real mode int09 handler (probably through int30h, or call real mode int, I didn't step into the end). However the irq is not routed to it's real mode handler, but to the original bios - I trapped 0x60 and 0x64 there's IO indeed, and when I quit the game using mouse, the command line will show the chars I pressed.

I recall that my TSR cannot call the newly hooked IVT for real mode games using call real mode int (I need to read IVT and use call iret), are those related?

I see. Yes, that's a problem that cannot be really fixed by hdpmi, because it's a VCPI client. However, depending on how the real-mode handler is installed, MDK's keyboard might work if one set environment variable HDPMI=1 ( BEFORE hdpmi32i is installed! ).

But I've already merged your commit which enables page0 guard, doesn't that do the same as set HDPMI=1, watching IVT?
MDK won't work before and after I merged your code. Is there any other workaround?

BTW MDK works with HDPMI32 (IOPL=3), is there anything related to IOPL0? I'm still unfamiliar with the source code.

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

But I've already merged your commit which enables page0 guard, doesn't that do the same as set HDPMI=1, watching IVT?

HDPMI=1 activates page0 guard. As a consequence, if the application modifies IVT directly in protected-mode, this is trapped and hdpmi is able to ensure that its own real-mode vector remains the first in the chain.

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

BTW MDK works with HDPMI32 (IOPL=3), is there anything related to IOPL0? I'm still unfamiliar with the source code.

Ok, if it works with standard HDPMI, the HDPMI=1 switch won't change anything.

Baron von Riedesel wrote on 2023-02-25, 13:27:

HDPMI=1 activates page0 guard. As a consequence, if the application modifies IVT directly in protected-mode, this is trapped and hdpmi is able to ensure that its own real-mode vector remains the first in the chain.

If you need your handler to stay on top of the chain then instead of relying on paging your program can periodically check the interrupt table entry/-ies of interest and hook them again if needed. I use this technique in DOS32AWE AFAIR.

I tested the games I have, most works fine, now virtual irq can work using call real mode int for real mode games, like direct int for protected mode games. except for Miles Sound.

Miles sound is running in real mode (only trappable using QEMM/JEMM), while it's been used in DOS/4GW games. I can see it hooks IVT 3Ch (int 0F addr for irq 7) in HDPMI debug log(with -i), but when I use -i option or HDPMI=1 for HDPMI32i, it still doesn't work properly.
the virtual IRQ is handled correctly and SETSOUND utility can detect SB. but it seems delayed. in game the sound is loop in small parts. This doesn't happen when reading IVT and call real mode iret.

This build includes:
1. changes merged from HDPMI official repo that might fix keyboard problems
2.added real mode IVT hook for sound card irq, fixing the Wolf3D keyboard release problem (the problem might also be fixed by 1, but I tested it working before merge the code)
the code that uses INT to restore the protected mode context is not used, it has problem with Miles Sound.
known problems: with this HDPMI version Miles sound will freeze on detecting SB, but will work detecting SB Pro.

crazii wrote on 2023-02-26, 17:14:

This build includes: 1. changes merged from HDPMI official repo that might fix keyboard problems 2.added real mode IVT hook for […]
Show full quote

This build includes:
1. changes merged from HDPMI official repo that might fix keyboard problems
2.added real mode IVT hook for sound card irq, fixing the Wolf3D keyboard release problem (the problem might also be fixed by 1, but I tested it working before merge the code)
the code that uses INT to restore the protected mode context is not used, it has problem with Miles Sound.
known problems: with this HDPMI version Miles sound will freeze on detecting SB, but will work detecting SB Pro.

SBEMU.zip

Great stuff, crazii! I ran through a couple of levels in Wolf3D and had no keyboard issues whatsoever with this release. 👍

PS The arrow keys in Prince turned out not to be related to SBEMU, as they don't work on X230 even if it's not loaded 🤣

Congratulations, keyboard issues seem fixed in your newest zip above (26-Feb). Outstanding progress. The generalized keyboard problems (freezing, missed keys / corrupted keys) under real mode games appear to be fixed as well. Wolf3d is completely playable, other Apogee games such as Major Stryker and Halloween Harry, and Monster Bash are now playable. No more keyboard ramdomness. My PC Atari Emulator seems mostly playable now. A few keyboard problems persist there, but it is 90% better; emulated games are now playable, with excellent, digitized sound at 8-bit 31400 hz (the PCAE program's internal sampling rate).

(Keyboard problems persist in Galactix v. 1.5, but are "better" now- game seems playable / useable. Digital Sound being sped-up and cutting out within 1 second or so, in that game, and in other Apogee games, persists. OPL music still plays perfectly.)

Super excited to continue testing. This is only a brief report to say, my hat is off to you (and to HPDPMI32 author for collaborating) for squashing the major KB problems in real mode games.

Hi,
First of all congratulations for the great progress.
I would like to ask how hard it would be to add support for other audio cards that are already supported by Mpxplay. I'm mainly thinking about Creative cards (Audigy 1/2/4) because their DOS SB emulation does not work anymore on newer chipsets yet they are still somewhat popular (I'm still using an Audigy 2 ZS). On Mpxplay's website there is an audio plugin example for Audigy cards (despite the fact that these cards are already supported internally by Mpxplay).
http://prdownloads.sourceforge.net/mpxplay/sc … 54.zip?download
Thanks in advance.

Falcosoft wrote on 2023-02-27, 06:00:

Hi, First of all congratulations for the great progress. I would like to ask how hard it would be to add support for other audio […]
Show full quote

Hi,
First of all congratulations for the great progress.
I would like to ask how hard it would be to add support for other audio cards that are already supported by Mpxplay. I'm mainly thinking about Creative cards (Audigy 1/2/4) because their DOS SB emulation does not work anymore on newer chipsets yet they are still somewhat popular (I'm still using an Audigy 2 ZS). On Mpxplay's website there is an audio plugin example for Audigy cards (despite the fact that these cards are already supported internally by Mpxplay).
http://prdownloads.sourceforge.net/mpxplay/sc … 54.zip?download
Thanks in advance.

I think it is possible. I checked the code and it has support for SB Live and Audigy series.
The main change of MPXplay drivers for SBEMU includes 2 points. 1, adaption from OpenWatcom to DJGPP, mainly involves PCI bus master DMA buffer allocation & linear to physical mapping (MPXPlay uses about 16K DOS memory for PCI DMA but we need preserve DOS memory for games). 2, add interrupt flags and IRQ handling, this need to check the SB Audigy spec (if it is public) or other online sources(e.g. ALSA project) to find the right registers and interrupt flags.
I can try it but it needs debugging and I don't have the hardware to debug it, so it's not guaranteed to work.

The author of MPXPlay agreed that SBEMU uses its source code, as long as its header comments unchanged, and SBEMU opens source. 😁
https://sourceforge.net/p/mpxplay/discussion/ … ead/ac6560662b/

Great news! We were not asking for a "clone" of MpxPlay, however just that the author is made aware of your fix to his code to make it work on some HDA chipsets. I am glad he agreed to it. However, it is hoped he will compile new DOS version with your fixes as described...