VOGONS


Reply 40 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

Some updates:
I've improved the OPL3 emulation now it is better, with little distortion.

Since OPL3 emulation only involves port IO and its much simpler, the major problem is to emulate the SB. in VirtualBox, Miles Sound SETSOUND's delay method (like AIL2.0, reading some VGA ports) is not working properly, with not enough delay time so it won't detect the emulated sound card - the IRQ sent when it finished its delay and uninstall its IRQ handler. I tried to hack its delay by trapping the VGA port with empty loops and it will freeze, maybe I need a real machine to test.

For all the games I've tested, only The Jungle Book and Skyroads worked fine, Warcraft2's setup can detect the emulated sound card and play "You Sound Card works Perfectly" in a distorted way.
I also tested the Lion King which uses auto-init mode to play digital music, but it will crash on the IRQ request. If I change the IRQ to 7, it plays OK.
I think there's a long way to go to make a usable pure soft SB emulation.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 41 of 406, by Bondi

User metadata
Rank Oldbie
Rank
Oldbie
crazii wrote on 2023-01-27, 08:47:
Bondi wrote on 2023-01-15, 08:45:
Hey, crazii. Good to see things are moving on! I'm wondering how ICH sound device works, given it's a PCI device. I may be compl […]
Show full quote
crazii wrote on 2023-01-15, 00:55:

Yes I'm now working on SB emulation, I think the distorted sound might be fixed later.
What's your Discord account? You can PM me.

Hey, crazii. Good to see things are moving on!
I'm wondering how ICH sound device works, given it's a PCI device. I may be completely wrong, but If I understand correctly there is no "DMA controller" within PCI architecture, rather every device can read from memory directly. So no need for the TSR to feed data to the sound chip, just need to tell the sound card the address and legth of the sample?
Is it the case? Or you do it differntly? Could you tell a little how the SB portion is going to work.

Basically yes, But some cards didn't support 8bit PCM and others, so the actual thing I'm doing is to 1.convert the data located at DMA address to 16bit pcm, to another memory location 2.duplicate channels into 2 (stereo) 3.convert the samples to a fixed sample rate(frequency), i.e. 22050 (44100 might be the most compatible sample rate for AC97). and then feed the data to the sound card.

That's very interesting. Too bad 8 bit is not supported, it adds a lot of work for the TSR. Given the amount of processing it will require a powerful cpu. Do you have the estimates of what is the minumum processor that would do?
And I wonder if the data is fed at the sampling rate(like covox, or SB direct ode) or the chip takes care of that?
Still it's very promising that you have the first signs of life 😀 Did you try Wolf3D?

And do you plan to release the code at some point? I'm lobbying for the PCMCIA cards as always 😁 There are many cards that have a real SB DSP that sits on the usual 220h port, but they all lack DMA. So your TSR should be easy to modify to feed the data in SB direct mode. That would be a revolution after all these DMAless years.

PCMCIA Sound Cards chart
archive.org: PCMCIA software, manuals, drivers

Reply 42 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
Bondi wrote on 2023-01-27, 15:06:
That's very interesting. Too bad 8 bit is not supported, it adds a lot of work for the TSR. Given the amount of processing it wi […]
Show full quote
crazii wrote on 2023-01-27, 08:47:
Bondi wrote on 2023-01-15, 08:45:

Hey, crazii. Good to see things are moving on!
I'm wondering how ICH sound device works, given it's a PCI device. I may be completely wrong, but If I understand correctly there is no "DMA controller" within PCI architecture, rather every device can read from memory directly. So no need for the TSR to feed data to the sound chip, just need to tell the sound card the address and legth of the sample?
Is it the case? Or you do it differntly? Could you tell a little how the SB portion is going to work.

Basically yes, But some cards didn't support 8bit PCM and others, so the actual thing I'm doing is to 1.convert the data located at DMA address to 16bit pcm, to another memory location 2.duplicate channels into 2 (stereo) 3.convert the samples to a fixed sample rate(frequency), i.e. 22050 (44100 might be the most compatible sample rate for AC97). and then feed the data to the sound card.

That's very interesting. Too bad 8 bit is not supported, it adds a lot of work for the TSR. Given the amount of processing it will require a powerful cpu. Do you have the estimates of what is the minumum processor that would do?
And I wonder if the data is fed at the sampling rate(like covox, or SB direct ode) or the chip takes care of that?
Still it's very promising that you have the first signs of life 😀 Did you try Wolf3D?

And do you plan to release the code at some point? I'm lobbying for the PCMCIA cards as always 😁 There are many cards that have a real SB DSP that sits on the usual 220h port, but they all lack DMA. So your TSR should be easy to modify to feed the data in SB direct mode. That would be a revolution after all these DMAless years.

The data are filled at the sampling rate when I used timer to do that, but it's taken care of by the sound card now. If configured properly, the sound card will generate a interrupt after a block of buffer is fetched, I just queue the new data in the interrupt handler. The interrupt rate is based on the buffer size and possibly sampling rate, so it should be a fixed rate too. That's how I improved OPL3 playback.

For current setting the interrupt handler will feed 512 bytes each time, so the data conversion might not take long, the OPL3 emulation might need more CPU power. I'm not sure how powerful a CPU it needs, guess 400~500MHz maybe? It really needs to be tested out.

I didn't try wolf3d yet, I can try it later. The source code is on my GitHub and I will post it later too. 😁

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 43 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

UPDATE:
Fixed some issues now prince of persia 2 tested working.
Tested on real machine: NEC Versa s260 with VT82C686B (VIASBCFG & VIAFMTSR failed to work in DOS on this machine), good news is Miles Sound on real machine can detect the emulated SB. VT82C686B is supported by MPXPlay, I just added some interrupt config. It's a 1.1Ghz machine so the games I tested all have good performance with the SB emulation on.
doom freeze on launch when set sound fx to sound blaster, as I checked it is incompatible with HDPMI, freeze even when SB emulation not installed. turning off sound fx will make it launch. still got a working OPL music at least.
also tried wolf3d on that machine, good news is music and sound effect works, bad news is it will soon freeze in the game, I cannot even open the first door. 🤣
still long way to go. 🤣

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 44 of 406, by Bondi

User metadata
Rank Oldbie
Rank
Oldbie
crazii wrote on 2023-01-29, 13:54:
UPDATE: Fixed some issues now prince of persia 2 tested working. Tested on real machine: NEC Versa s260 with VT82C686B (VIASBCFG […]
Show full quote

UPDATE:
Fixed some issues now prince of persia 2 tested working.
Tested on real machine: NEC Versa s260 with VT82C686B (VIASBCFG & VIAFMTSR failed to work in DOS on this machine), good news is Miles Sound on real machine can detect the emulated SB. VT82C686B is supported by MPXPlay, I just added some interrupt config. It's a 1.1Ghz machine so the games I tested all have good performance with the SB emulation on.
doom freeze on launch when set sound fx to sound blaster, as I checked it is incompatible with HDPMI, freeze even when SB emulation not installed. turning off sound fx will make it launch. still got a working OPL music at least.
also tried wolf3d on that machine, good news is music and sound effect works, bad news is it will soon freeze in the game, I cannot even open the first door. 🤣
still long way to go. 🤣

Nice!
Wolf3D freeze is most probably connected with DMA processing. It always freezes on me at the opening of the first door (first digital sound) if the card has no DMA.
So no chances for FX in DOOM?
I've checked your guthub, btw. It's cool you have the updated code there!
Unfortunately I know just a little assembly, but not C.

PCMCIA Sound Cards chart
archive.org: PCMCIA software, manuals, drivers

Reply 45 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

wolf3d can play digital sounds, I fired the gun, and used the knife when the ammo runs out. It seems the culprit is the 'buzz' sound when running towards walls, or action when long press space bar.

I've fixed some bugs on a Toshiba portege m200 with 1.5GHz CPU & 855pm mobo (ICH4, AD1981B sound card) and now it works.wolf3d works too.
but it still have random freeze when run & hit the walk. If I disable the sound effect (not the digitized sound. its the 1st option in sound settings) by using PC speaker, everything works fine. I played the 1st level and no freeze anymore. I wonder what that sound effect does. by checking the source code of wolf3d, it seems to operate on Adlib to generate some sound effects, with a lot (30+) of IN delays each time, with multiple operations of that. those IN 388h will be trapped, so it might be the QEMM's IO port trap problem or be that I used it incorrectly.

Ideally doom would work if the issue between hdpmi & doom were fixed, but I'm not sure I'm able to do that, maybe I can try it later, when the emulation becomes more stable. I'm a little rusty on assembly besides it would involve too much codes to do it in assembly. I'm not confident to do that. But It may increase the compatibility of the program. for example when trapping IO using QEMM in real mode(v86), currently the program will jump to protected mode to do the real work, it's a pure protected mode client anyway. I think a assembly program with mixed 16 & 32 bit segments and a custom loader would skip some mode switch. but that's too complicated, also need to adapt the OPL3 emulation C code into 16bit. For now the easiest way to do it is writing 16bit inline assembly, and copy it to conventional memory at runtime. maybe I can do that for reading port 388h only to see what happens.

UPDATE:
added directly handling of reading 388h, without switch to PM, still freezes. a switch to turn off PM mode support (all HDPMI port trappings) and turn it off, still the same. guess I'm out of luck.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 46 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

Did more tests, seems QEMM+HDPMI are the reason for doom's freeze:

QEMM+HDPMI(IOPL=0) = doom freeze
QEMM+HDPMI(standard) = doom ok
HDPMI(IOPL=0) no QEMM = doom ok.

Now I temporarily removed QEMM from config.sys and debug doom.
Same thing happens to duke3d, with QEMM removed, duke3d plays well with digital sound + FM both working.

UPDATE: It seems I was wrong, either doom or duke3d won't work with or without QEMM. I was testing with modified version of HDPMI so duke3d works.

Last edited by crazii on 2023-02-03, 13:10. Edited 1 time in total.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 47 of 406, by Bondi

User metadata
Rank Oldbie
Rank
Oldbie
crazii wrote on 2023-02-02, 12:51:
Did more tests, seems QEMM+HDPMI are the reason for doom's freeze: […]
Show full quote

Did more tests, seems QEMM+HDPMI are the reason for doom's freeze:

QEMM+HDPMI(IOPL=0) = doom freeze
QEMM+HDPMI(standard) = doom ok
HDPMI(IOPL=0) no QEMM = doom ok.

Now I temporarily removed QEMM from config.sys and debug doom.
Same thing happens to duke3d, with QEMM removed, duke3d plays well with digital sound + FM both working.

Don't quite get this. Isn't QEMM do the port trapping? How comes it works then? And if it works without QEMM, why then one needs it?
(sorry for all my lamer questions 😁)

PCMCIA Sound Cards chart
archive.org: PCMCIA software, manuals, drivers

Reply 48 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
Bondi wrote on 2023-02-02, 13:07:
crazii wrote on 2023-02-02, 12:51:
Did more tests, seems QEMM+HDPMI are the reason for doom's freeze: […]
Show full quote

Did more tests, seems QEMM+HDPMI are the reason for doom's freeze:

QEMM+HDPMI(IOPL=0) = doom freeze
QEMM+HDPMI(standard) = doom ok
HDPMI(IOPL=0) no QEMM = doom ok.

Now I temporarily removed QEMM from config.sys and debug doom.
Same thing happens to duke3d, with QEMM removed, duke3d plays well with digital sound + FM both working.

Don't quite get this. Isn't QEMM do the port trapping? How comes it works then? And if it works without QEMM, why then one needs it?
(sorry for all my lamer questions 😁)

QEMM is used to trap real mode games. HDPMI is for protected mode games. Both have limitation.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 49 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie

the reason to use QEMM is that, (according to some online docs) EMM386 doesn't support trapping port below 100h, which makes it unable to virtualize DMA & IRQ. I don't know about other memory managers. it'll be much appreciated if docs about other emms are provided.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 50 of 406, by Baron von Riedesel

User metadata
Rank Member
Rank
Member

hello,

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

HDPMI is for protected mode games. Both have limitation.

could you please list the hdpmi limitations? ( I'm the author of hdpmi )

The freezes are most likely due to bugs in the Rational DOS extender (DOS4G[W]). If a DPMI clien runs with IOPL == 0, instructions POPF and IRET don't restore the interrupt flag ( this peculiarity is covered by the DPMI specs ).

Reply 51 of 406, by rasz_pl

User metadata
Rank l33t
Rank
l33t
crazii wrote on 2023-02-02, 13:57:

EMM386 doesn't support trapping port below 100h, which makes it unable to virtualize DMA & IRQ.

Wouldnt it be easier to patch EMM386 instead of writing new code? Its not like Microsoft is releasing new DOS making it troublesome to keep up with versions.

BTW is that one of you guys: https://www.mail-archive.com/freedos-devel@li … t/msg13220.html ?
>I've been working on adding an implementation of I/O port trapping to JEMM
using the EMM386/QEMM API (INT 2F.4A15). I have it basically working.

AT&T Globalyst/FIC 486-GAC-2 Cache Module reproduction
Zenith Data Systems (ZDS) ZBIOS 'MFM-300 Monitor' reverse engineering

Reply 52 of 406, by digger

User metadata
Rank Oldbie
Rank
Oldbie
crazii wrote on 2023-02-02, 13:57:

the reason to use QEMM is that, (according to some online docs) EMM386 doesn't support trapping port below 100h, which makes it unable to virtualize DMA & IRQ. I don't know about other memory managers. it'll be much appreciated if docs about other emms are provided.

There may be another option: 386MAX, which was recently open-sourced by Bob Smith. It apparently implements the same INT 2Fh (ax=4a15) port trapping API as the one in Microsoft EMM386, and supposedly even improves upon it.

I found two posts by Bob Smith in this thread on the Computer Programming Language Forum, in which mentions that this API is supported in 386MAX as of version 7.02. he refers to this API as the "I/O Trapping Extensions Spec".

In this thread on the Programmers Heaven forum, a user named Bret mentions some interesting information about this as well. Apparently, he uploaded some relevant documentation in a file called `iotrap.zip`, but according to this Vogons post, that file can no longer be downloaded from the forum, since it had a makeover some years ago.

This user "Bret" may very well be Bret Johnson, who wrote DOS USB drivers that ship with FreeDOS. (Not to be confused with the DOS USB drivers that you forked from Google Code. Bret's drivers only support UHCI.)

What's of particular interest among Bret Johnson's DOS USB sources is the source file USBJSTIK.A36. This is apparently the source code for a driver for USB game controllers that support the USB HID device class. The driver uses port trapping to emulate a joystick in a 15-pin legacy game port. This should allow real-mode DOS games with joystick support to be played with USB joysticks and game controllers. The comments in the source file make multiple mentions of both EMM386 and 386MAX, and here and there it seems to imply that 386MAX has indeed improved upon the EMM386 API.

This part is the most interesting:

  ;----------------------------------------------------------------------------
;Minimum I/O Port Number allowed
;----------------------------------------------------------------------------
MinVIOPortNum EQU 100h ;386MAX allows any Port?

It seems like Bret used the documentation in the (seemingly lost) `iotrap.zip` file to write this joystick driver. And if the info that he based the assumptions and comments in this code on is true, than that would mean that 386MAX version 7.0.2 and higher not only support the same port trapping API as EMM386, but support it for I/O ports lower than 100h as well. 🙂

Version 8.03 of 386MAX can be downloaded from https://winworldpc.com/product/386max/8x

It would be even better if we could get 386MAX to be built from the sources on GitHub.

Also it might be useful to contact Bret Johnson and/or Bob Smith to ask if either of them still have a copy of that `iotrap.zip` file, which supposedly contains test reports, documentation and programming examples relating to I/O port trapping, using various EMM managers.

Hopefully this research is of use to you.

Reply 53 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
Baron von Riedesel wrote on 2023-02-02, 15:28:
hello, […]
Show full quote

hello,

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

HDPMI is for protected mode games. Both have limitation.

could you please list the hdpmi limitations? ( I'm the author of hdpmi )

The freezes are most likely due to bugs in the Rational DOS extender (DOS4G[W]). If a DPMI clien runs with IOPL == 0, instructions POPF and IRET don't restore the interrupt flag ( this peculiarity is covered by the DPMI specs ).

Hey good to see you here. the limitations is that it is only for protected mode games, like EMMs only for real modes. It's not a limitation of HDPMI, but of DPMI itself, the fields that DPMI covers are limited to protected mode only.
Is that even possible to write a EMM(V86 monitor)+DPMI host, 2 in 1 program?

BTW I was debugging HDPMI recently to find why doom freezes, as you said, HDPMI simulate the IF changes in #GP handler when client uses cli/sti, but how does it handle POPF? something like "pushf cli popf" won't restore IF at all. I didn't find any thing related in the DPMI specs, guess I missed something. UPDATE: I read though the DPMI spec, which says a client should do a virtual interrupt state get & disable, and then restore. I didn't do that my self. 🤣

EDIT:
one thing I forgot to mention, is that HDPMI store interrupt callbacks in local client data, it will copy the IVT on client startup, so after my program TSRed, the IVT changes won't reflected to the TSR's local data. if a frontend real mode program hooks IVT, call DPMI api: simulate real mode interrupt (int 31h, ax=0300h) in my TSR won't call the hooked handler, I have to read the "raw" IVT and call it manually. is it the right behavior?

Last edited by crazii on 2023-02-03, 06:42. Edited 3 times in total.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 54 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
rasz_pl wrote on 2023-02-02, 22:30:
Wouldnt it be easier to patch EMM386 instead of writing new code? Its not like Microsoft is releasing new DOS making it troubles […]
Show full quote
crazii wrote on 2023-02-02, 13:57:

EMM386 doesn't support trapping port below 100h, which makes it unable to virtualize DMA & IRQ.

Wouldnt it be easier to patch EMM386 instead of writing new code? Its not like Microsoft is releasing new DOS making it troublesome to keep up with versions.

BTW is that one of you guys: https://www.mail-archive.com/freedos-devel@li … t/msg13220.html ?
>I've been working on adding an implementation of I/O port trapping to JEMM
using the EMM386/QEMM API (INT 2F.4A15). I have it basically working.

Ahh, patch off the port range limitations? I didn't thing of that, and I never patched a DOS binary. Is it easy, or can you do it?
I didn't know Bret Johnson but as @digger posted, it reminds me that he's the author of the early USB drivers. I have actually read his code, learned some methods from it.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 55 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
digger wrote on 2023-02-02, 23:12:
There may be another option: 386MAX, which was recently open-sourced by Bob Smith. It apparently implements the same INT 2Fh (ax […]
Show full quote
crazii wrote on 2023-02-02, 13:57:

the reason to use QEMM is that, (according to some online docs) EMM386 doesn't support trapping port below 100h, which makes it unable to virtualize DMA & IRQ. I don't know about other memory managers. it'll be much appreciated if docs about other emms are provided.

There may be another option: 386MAX, which was recently open-sourced by Bob Smith. It apparently implements the same INT 2Fh (ax=4a15) port trapping API as the one in Microsoft EMM386, and supposedly even improves upon it.

I found two posts by Bob Smith in this thread on the Computer Programming Language Forum, in which mentions that this API is supported in 386MAX as of version 7.02. he refers to this API as the "I/O Trapping Extensions Spec".

In this thread on the Programmers Heaven forum, a user named Bret mentions some interesting information about this as well. Apparently, he uploaded some relevant documentation in a file called `iotrap.zip`, but according to this Vogons post, that file can no longer be downloaded from the forum, since it had a makeover some years ago.

This user "Bret" may very well be Bret Johnson, who wrote DOS USB drivers that ship with FreeDOS. (Not to be confused with the DOS USB drivers that you forked from Google Code. Bret's drivers only support UHCI.)

What's of particular interest among Bret Johnson's DOS USB sources is the source file USBJSTIK.A36. This is apparently the source code for a driver for USB game controllers that support the USB HID device class. The driver uses port trapping to emulate a joystick in a 15-pin legacy game port. This should allow real-mode DOS games with joystick support to be played with USB joysticks and game controllers. The comments in the source file make multiple mentions of both EMM386 and 386MAX, and here and there it seems to imply that 386MAX has indeed improved upon the EMM386 API.

This part is the most interesting:

  ;----------------------------------------------------------------------------
;Minimum I/O Port Number allowed
;----------------------------------------------------------------------------
MinVIOPortNum EQU 100h ;386MAX allows any Port?

It seems like Bret used the documentation in the (seemingly lost) `iotrap.zip` file to write this joystick driver. And if the info that he based the assumptions and comments in this code on is true, than that would mean that 386MAX version 7.0.2 and higher not only support the same port trapping API as EMM386, but support it for I/O ports lower than 100h as well. 🙂

Version 8.03 of 386MAX can be downloaded from https://winworldpc.com/product/386max/8x

It would be even better if we could get 386MAX to be built from the sources on GitHub.

Also it might be useful to contact Bret Johnson and/or Bob Smith to ask if either of them still have a copy of that `iotrap.zip` file, which supposedly contains test reports, documentation and programming examples relating to I/O port trapping, using various EMM managers.

Hopefully this research is of use to you.

Cool, it's worth a try. But I remember reading some comments in VSB that it only works with QEMM, doesn't that means other emms is not capable, or VSB didn't bother to support other emms?

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 56 of 406, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
crazii wrote on 2023-02-03, 01:56:

HDPMI simulate the IF changes in #GP handler when client uses cli/sti

This sounds dangerous. STI isn't meant to enable interrupts immediately, pending interrupts should not be raised until the instruction after STI has been executed. That won't be the case if it's being trapped and handled differently.

Reply 57 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2023-02-03, 06:06:
crazii wrote on 2023-02-03, 01:56:

HDPMI simulate the IF changes in #GP handler when client uses cli/sti

This sounds dangerous. STI isn't meant to enable interrupts immediately, pending interrupts should not be raised until the instruction after STI has been executed. That won't be the case if it's being trapped and handled differently.

Nah, I was too simply describing the method, what HDPMI actually does is modify the EFLAGS on the faulted stack, the flags will be updated when performing execution transition from DPMI kernel(ring0) to client (IRET).

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD

Reply 58 of 406, by Baron von Riedesel

User metadata
Rank Member
Rank
Member
crazii wrote on 2023-02-03, 01:56:

BTW I was debugging HDPMI recently to find why doom freezes, as you said, HDPMI simulate the IF changes in #GP handler when client uses cli/sti, but how does it handle POPF? something like "pushf cli popf" won't restore IF at all

hdpmi isn't notified when client code runs POPF, so it doesn't do anything.

one thing I forgot to mention, is that HDPMI store interrupt callbacks in local client data, it will copy the IVT on client startup, so after my program TSRed, the IVT changes won't reflected to the TSR's local data. if a frontend real mode program hooks IVT, call DPMI api: simulate real mode interrupt (int 31h, ax=0300h) in my TSR won't call the hooked handler, I have to read the "raw" IVT and call it manually. is it the right behavior?

Definitely NO. However, I doubt that HDPMI does that. It stores the IVT vectors of the IRQs ( int 8-0Fh and 70h - 77h ) internally and sets its own vectors for those, but this is just because, according to DPMI specs, these interrupts are always supposed to be handled in protected-mode first.

Reply 59 of 406, by crazii

User metadata
Rank Oldbie
Rank
Oldbie
Baron von Riedesel wrote on 2023-02-03, 08:12:
hdpmi isn't notified when client code runs POPF, so it doesn't do anything. […]
Show full quote
crazii wrote on 2023-02-03, 01:56:

BTW I was debugging HDPMI recently to find why doom freezes, as you said, HDPMI simulate the IF changes in #GP handler when client uses cli/sti, but how does it handle POPF? something like "pushf cli popf" won't restore IF at all

hdpmi isn't notified when client code runs POPF, so it doesn't do anything.

one thing I forgot to mention, is that HDPMI store interrupt callbacks in local client data, it will copy the IVT on client startup, so after my program TSRed, the IVT changes won't reflected to the TSR's local data. if a frontend real mode program hooks IVT, call DPMI api: simulate real mode interrupt (int 31h, ax=0300h) in my TSR won't call the hooked handler, I have to read the "raw" IVT and call it manually. is it the right behavior?

Definitely NO. However, I doubt that HDPMI does that. It stores the IVT vectors of the IRQs ( int 8-0Fh and 70h - 77h ) internally and sets its own vectors for those, but this is just because, according to DPMI specs, these interrupts are always supposed to be handled in protected-mode first.

I read some comments in HDPMI source, saying those callbacks are local because DOS/4GW may not restore them on exit. I was trying to call IRQ5/7 manually to simulate the sound card IRQ, and only reading from IVT works.

Toshiba Satellite Pro 4300 - YMF744, Savage IX
Toshiba Satellite 2805-S501 - YMF754, GeForce 2Go
IBM Thinkpad A21p - CS4624, Mobility Radeon 128
main: Intel NUC11PHKi7C Phantom Canyon: i7-1165G7 RTX2060 64G 2T760PSDD