KormaX wrote on 2023-02-23, 17:40:

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

UPDATE: There's no improvement on the emulation :D, but on the TSR part. now SBEMU can change parameters without rebooting. Note […]
Show full quote

UPDATE:
There's no improvement on the emulation 😁, but on the TSR part. now SBEMU can change parameters without rebooting.
Note that the default parameters takes effect on initial run. after that, you can only change parameters through command line. hope this will help most parameters for the initial startup.
e.g. initial parameter: /PM1 /RM0
then "SBEMU /PM0" will disable all emulations, the default parameter [/RM1] has no effect, only specified parameters have effect.

SBEMU.zip

This version became extremely incompatible and unstable. Blood, for example can only freeze and hang with it.

Weird, I almost changed nothing with existing code, only added new irrelevant codes. I'll check it again.

EDIT: I fixed critical bugs with my port trapping code in HDPMI and didn't update it. my bad. Sorry for the inconvenience. ZIP reuploaded in the original post.

crazii:
I've not yet tested the new version (23-Feb) posted above, but I have some further observations on the emulation of your 22-Feb (replaced .ZIP with IRQ 0/1 hack):
The keyboard problems continue, so it seems that leaving IRQ 0/1 alone doesn't help, for me at least (Intel HDA).

Also, now, after paying more attention since other users have also reported it, the keyboard mess-up / random keys, and/or lack of being able to use arrow keys or other keys affects most Apogee real-mode games with SBEMU loaded:
Major Stryker
Blake Stone
Wolfenstein 3D
Monster Bash
Corridor 7
Halloween Harry
Commander Keen series (but note, there's a Protected mode CWSDPMI DOS "remake" of CK 4-6 which does work perfectly!)
(PC Atari Emulator, ver. 2.5 still has problems with arrow keys / phantom keys as well with this IRQ 0/1 "fixed" SBEMU .zip)

Keys "disappear" and / or become unstable, making most of the games unplayable with sound. Not sure how to best fix this; but it seems a trouble spot in general.
And, on most of those real-mode Apogee games, I could only get OPL3 sound emulation (music) to play on my Kaby Lake HDA system. The two Broadwell chipset laptops with Intel HDA PCi onboard audio did play both digital effects and music. If it would help troubleshoot, I can list the PCI Hardware ID of my Kaby Lake vs my Broadwell onboard Audio) . The DOS settings are the same. The laptops are all three Dell laptops.

I've found for a few real-mode games, manually setting /T1 makes them work magically, vs not working with /T5 or /T6:
Invasion of Mutant Space Bats of Doom
Disney's Coaster
Galactix
Prince of Persia 2

I couldn't get Prince of Persa 1 working at all with SBEMU. Great game to replay again after 35 years!!

That is why i think "dynamically" being able to load and change the "/T" parameter without rebooting would save loads of time in testing the real mode games. Kormax above posted it's instable, but I'll test and report back.

Protected mode games seem much more "compatible" with SBEMU. Almost all that I've tested work. Except the three I (still) play the most after 30 years: NFS, Screamer, Screamer2, and Screamer Rally. That's OK, I'm super-happy *and* appreciative that you've worked on this project and have such a fantastic success rate so far.

(I didn't test Blood yet, will do and see if KormaX's report of instability / unplayable results of 23-Feb .zip vs. 22-Feb zip. )

Finally, I found that the DOS compile of MPLAYER movie player works perfectly with its Allegro drivers and detects the emulated SB16 and will play wonderful-fidelity music at 16-bit 44100 stereo of my media files: flac, mp3, aac, and will play films as well: mpeg2, h.264, AVI codecs with wonderful sound. This miracle on "bare metal" DOS on a "new" vintage laptop system. What a blast from the past...

With the /T6 parameter, what is SBEMU's "internal" samplerate: is it 16-bit 44100 hz stereo little-endian PCM audio?

Thanks for your continual work and progress on SBEMU.

KormaX wrote on 2023-02-23, 07:27:

I uploaded it here, or I hope so (I'm from DOS with Links, so I can't be sure until the comment is submitted XD). […]
Show full quote

I uploaded it here, or I hope so (I'm from DOS with Links, so I can't be sure until the comment is submitted 🤣).

Well, JEMM386 can NOT be unloaded once loaded, at least, not by any means I'm aware of. It can be loaded in fly using loaders, like Loadsys (with LOADSYS /OD, because it's a device driver.) Maybe devload also works, IDK. DDL doesn't. I tried loading it with LOADSYS /R /OD so it could later be removed by LOADSYS /U, but it installs itself some funny way and Loadsys can't track it. It thinks Jemm is failed to load and won't be on it's list, redirected interrupts not recorded. I also tried to mark the system state with Marknet and then restore with Relnet, but it just hung the system. Maybe they couldn't remove Jemm, maybe they did but the CPU remained in PM without the monitor 🤣 Thus, QPIEMU.DLL also stays in the memory.

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

My command line is:
LOADSYS /R /i08 /i09 /i0A /i0B /i0C /i0D /i0E /i0F /i1C /i70 /i71 /i72 /i73 /i74 /i75 /i76 /i77 SBEMU.EXE

Thanks for uploading your custom-compiled version of JEMM386. I'll test it tonight vs. the version of JemmEX included in the SBEMU distribution .ZIP files. But, yes, I was a little confused when you said it can't be loaded / unloaded, as I've always been able to do this. Similarly there is a DOS EMS manager called EMS Magic, which one can dynamically load and unload via commandline, for providing up to 32M of EMS, with pageframe.

zyzzle wrote on 2023-02-24, 03:08:

Keys "disappear" and / or become unstable, making most of the games unplayable with sound. Not sure how to best fix this; but it seems a trouble spot in general.

This problem seems to have disappeared with the newest hdpmi.

However, since crazii's sbemu is NOT compatible with the standard hdpmi ( and I cannot use his hdpmi because it's incompatible with HX ), you can only try the new hdpmi with my adjusted version of sbemu, which - among other things - still lacks the SB16 feature.

zyzzle wrote on 2023-02-24, 03:08:

I've found for a few real-mode games, manually setting /T1 makes them work magically, vs not working with /T5 or /T6: Invasion o […]
Show full quote

I've found for a few real-mode games, manually setting /T1 makes them work magically, vs not working with /T5 or /T6:
Invasion of Mutant Space Bats of Doom
Disney's Coaster
Galactix
Prince of Persia 2

I couldn't get Prince of Persa 1 working at all with SBEMU. Great game to replay again after 35 years!!

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.

One interesting thing found today: if I hook the IVT with sound card irq, the key release problem of Wolf3D is gone.
It must be the IVT not the real mode interrupt vector of HDPMI.
The difference between hooking IVT and using PM vector or RM vector of HDPMI is that hooking IVT uses the real mode call back of DPMI API, while the others uses HPDMI's internal implementation: intrmcb.
Such behavior indicate the problem lies in the internal implementation perhaps?

Baron von Riedesel wrote on 2023-02-24, 05:34:

zyzzle wrote on 2023-02-24, 03:08:

Keys "disappear" and / or become unstable, making most of the games unplayable with sound. Not sure how to best fix this; but it seems a trouble spot in general.

This problem seems to have disappeared with the newest hdpmi.

However, since crazii's sbemu is NOT compatible with the standard hdpmi ( and I cannot use his hdpmi because it's incompatible with HX ), you can only try the new hdpmi with my adjusted version of sbemu, which - among other things - still lacks the SB16 feature.

Can post a list of commits that fix the problem? I can integrate your changes to my fork 😁

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

Can post a list of commits that fix the problem? I can integrate your changes to my fork 😁

Well, there's just one. 😀

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

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

Can post a list of commits that fix the problem? I can integrate your changes to my fork 😁

Well, there's just one. 😀

My fork is already 8 commits behind, is that Commit on Dec 14, 2022? Can you be more specific?
It might be off topic but can your explain the fix? It seems no keyboard problem on my machine anyway. 🤣

crazii wrote on 2023-02-24, 08:02:

My fork is already 8 commits behind, is that Commit on Dec 14, 2022? Can you be more specific?
It might be off topic but can your explain the fix? It seems no keyboard problem on my machine anyway. 🤣

It must be the last commit, since I experienced that Wolf3D "key swallow" problem with the standard v3.20 version.
The idea of the "fix" is to route protected-mode IRQs to the true IVT vector if the protected-mode vector hasn't been modified by the client.

Baron von Riedesel wrote on 2023-02-24, 08:36:

crazii wrote on 2023-02-24, 08:02:

My fork is already 8 commits behind, is that Commit on Dec 14, 2022? Can you be more specific?
It might be off topic but can your explain the fix? It seems no keyboard problem on my machine anyway. 🤣

It must be the last commit, since I experienced that Wolf3D "key swallow" problem with the standard v3.20 version.
The idea of the "fix" is to route protected-mode IRQs to the true IVT vector if the protected-mode vector hasn't been modified by the client.

Great, sounds very similar to what I found today. 😁

Baron von Riedesel wrote on 2023-02-24, 08:36:

crazii wrote on 2023-02-24, 08:02:

My fork is already 8 commits behind, is that Commit on Dec 14, 2022? Can you be more specific?
It might be off topic but can your explain the fix? It seems no keyboard problem on my machine anyway. 🤣

It must be the last commit, since I experienced that Wolf3D "key swallow" problem with the standard v3.20 version.
The idea of the "fix" is to route protected-mode IRQs to the true IVT vector if the protected-mode vector hasn't been modified by the client.

BTW, does this fix MDK? MDK totally has no keyboard input.

crazii wrote on 2023-02-24, 10:23:

Baron von Riedesel wrote on 2023-02-24, 08:36:

crazii wrote on 2023-02-24, 08:02:

My fork is already 8 commits behind, is that Commit on Dec 14, 2022? Can you be more specific?
It might be off topic but can your explain the fix? It seems no keyboard problem on my machine anyway. 🤣

It must be the last commit, since I experienced that Wolf3D "key swallow" problem with the standard v3.20 version.
The idea of the "fix" is to route protected-mode IRQs to the true IVT vector if the protected-mode vector hasn't been modified by the client.

BTW, does this fix MDK? MDK totally has no keyboard input.

Can't wait to test it.
MDK is the only game that I had keyboard problems with on x60s.
On x230 still problems with Prince and stuck keys in Wolf3d.

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.

zyzzle wrote on 2023-02-24, 03:41:

KormaX wrote on 2023-02-23, 07:27:

I uploaded it here, or I hope so (I'm from DOS with Links, so I can't be sure until the comment is submitted XD). […]
Show full quote

I uploaded it here, or I hope so (I'm from DOS with Links, so I can't be sure until the comment is submitted 🤣).

Well, JEMM386 can NOT be unloaded once loaded, at least, not by any means I'm aware of. It can be loaded in fly using loaders, like Loadsys (with LOADSYS /OD, because it's a device driver.) Maybe devload also works, IDK. DDL doesn't. I tried loading it with LOADSYS /R /OD so it could later be removed by LOADSYS /U, but it installs itself some funny way and Loadsys can't track it. It thinks Jemm is failed to load and won't be on it's list, redirected interrupts not recorded. I also tried to mark the system state with Marknet and then restore with Relnet, but it just hung the system. Maybe they couldn't remove Jemm, maybe they did but the CPU remained in PM without the monitor 🤣 Thus, QPIEMU.DLL also stays in the memory.

But you can removeably load HDPMI32I and SBEMU. You have to load HDPMI with LOADSYS /R and SBEMU with LOADSYS /R /whattheheckisthis, where "whattheheckisthis" is a series of interrupts explicitly specified to record when loading, so it can be removed with LOADSYS /U later.

My command line is:
LOADSYS /R /i08 /i09 /i0A /i0B /i0C /i0D /i0E /i0F /i1C /i70 /i71 /i72 /i73 /i74 /i75 /i76 /i77 SBEMU.EXE

Thanks for uploading your custom-compiled version of JEMM386. I'll test it tonight vs. the version of JemmEX included in the SBEMU distribution .ZIP files. But, yes, I was a little confused when you said it can't be loaded / unloaded, as I've always been able to do this. Similarly there is a DOS EMS manager called EMS Magic, which one can dynamically load and unload via commandline, for providing up to 32M of EMS, with pageframe.

I know EMSMAGIC, I use it sometimes. The funny thing is that a long time ago I even used Jemm, and I remembered that it could be unloaded back then. But my brain filtered out everything below the main list, so I ended up not finding the LOAD and UNLOAD switches, even though I read the list multiple times. I was hurry, as I am now.

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

One interesting thing found today: if I hook the IVT with sound card irq, the key release problem of Wolf3D is gone. It must be […]
Show full quote

One interesting thing found today: if I hook the IVT with sound card irq, the key release problem of Wolf3D is gone.
It must be the IVT not the real mode interrupt vector of HDPMI.
The difference between hooking IVT and using PM vector or RM vector of HDPMI is that hooking IVT uses the real mode call back of DPMI API, while the others uses HPDMI's internal implementation: intrmcb.
Such behavior indicate the problem lies in the internal implementation perhaps?

I only experienced significant keyboard issues with one of your older test versions. The last three was without them, at least in Blood, Volfied and the Prince games. When I brows the directories with FAR, it sometimes jumps two entries instead of two, but that's all. The earliest version I tried, didn't react to enter and Bumpy hung the system entirely because it ended up waiting for keyboard input forever.

Now, with your fixed version, Blood runs well. There were unstability problems with SBEMU and Blood anyway, but if I edit the BLOOD.CFG file manually to set screen mode to "2" instead of "1", it works with higher resolutions as well without crushing. This was not the case with your buggy HDPMI32I version last time, but now, it's perfect.

I realized, that if I load up Windows 3.11 and execute games from it, they are less likely to hang the system, because if they would, Windows tend to take back control, so I might test more with the problematic ones that way.

Wacky Wheels tries to work, but can't 🤣 I mean, it initializes the sound card but hangs with any setup. I would try running these problematic DOS4GW programs with DOS32A, but unfortunately, the fail to see the driver when loaded with DOS32A. I'm gonna test it with different settings of DOS32A though.

KormaX wrote on 2023-02-24, 12:30:

Wacky Wheels tries to work, but can't 🤣 I mean, it initializes the sound card but hangs with any setup. I would try running these problematic DOS4GW programs with DOS32A, but unfortunately, the fail to see the driver when loaded with DOS32A. I'm gonna test it with different settings of DOS32A though.

DOS32A must be forced to use DPMI with the /DPMITST:1 option.

crazii wrote on 2023-02-24, 10:23:

BTW, does this fix MDK? MDK totally has no keyboard input.

I don't have that game installed, so can't test, but AFAIR it's a protected-mode game?

The biggest remaining potential problem with protected-mode games, AFAICS, is that the emulated SB interrupt is invoked from the context of the IRQ handler. Usually this is no problem at all, because an interrupt handler routine shouldn't make any assumptions about the values of segment or general purpose registers. But that's theory, in fact a game might very well assume that some segment registers have a defined value when the interrupt routine is entered.

DOS32A must be forced to use DPMI with the /DPMITST:1 option.

Another option is to enter "jemmex novcpi". This disables VCPI, so any DOS extender is forced to use DPMI - the already installed hdpmi32i in this case.

Baron von Riedesel wrote on 2023-02-24, 12:41:

I don't have that game installed, so can't test, but AFAIR it's a protected-mode game? […]
Show full quote

crazii wrote on 2023-02-24, 10:23:

BTW, does this fix MDK? MDK totally has no keyboard input.

I don't have that game installed, so can't test, but AFAIR it's a protected-mode game?

The biggest remaining potential problem with protected-mode games, AFAICS, is that the emulated SB interrupt is invoked from the context of the IRQ handler. Usually this is no problem at all, because an interrupt handler routine shouldn't make any assumptions about the values of segment or general purpose registers. But that's theory, in fact a game might very well assume that some segment registers have a defined value when the interrupt routine is entered.

DOS32A must be forced to use DPMI with the /DPMITST:1 option.

Another option is to enter "jemmex novcpi". This disables VCPI, so any DOS extender is forced to use DPMI - the already installed hdpmi32i in this case.

Yes it's a protected mode game, using DOS/4GW. and Yes, I've read the AIL2.0 source code of SB detection, that the real mode IRQ handler assumes the ds as it's own data segment. Fortunately Miles Sound 3.0 seems not doing that.
I have some experimental features but now removed, that get (sound IRQ) interrupt context from HDPMI, and pass it to the virtual IRQ, I can add it back to see what happens.
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.

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

Can't wait to test it. MDK is the only game that I had keyboard problems with on x60s. On x230 still problems with Prince and st […]
Show full quote

crazii wrote on 2023-02-24, 10:23:

Baron von Riedesel wrote on 2023-02-24, 08:36:

It must be the last commit, since I experienced that Wolf3D "key swallow" problem with the standard v3.20 version.
The idea of the "fix" is to route protected-mode IRQs to the true IVT vector if the protected-mode vector hasn't been modified by the client.

BTW, does this fix MDK? MDK totally has no keyboard input.

Can't wait to test it.
MDK is the only game that I had keyboard problems with on x60s.
On x230 still problems with Prince and stuck keys in Wolf3d.

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.

I used the latest code from HDPMI official repo and MDK still the same. But I believe wolf3d is OK as tested on my machine. I'll focus on the MDK keyboard issue.

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 ).