crazii wrote on 2023-02-09, 22:18:

Baron von Riedesel wrote on 2023-02-09, 15:49:

crazii wrote on 2023-02-09, 13:22:

I've updated the HDPMI & SBEMU code following your advice, now IOPL0 is used and TF is also cleared.

Just for the record: the trace flag being cleared is preferable if one does single-step over an IN/OUT instruction. If TF is NOT cleared, the debugger stops inside the IO trap handler then.

Sure, I understand that. 😁

I disagree: the TF is cleared by the CPU when invoking a trap handler (in your case an IO trap) so this behavior won't be observed . The same way the debugger is not debugging its own INT1 trap handler.

georgel wrote on 2023-02-10, 02:40:

I disagree: the TF is cleared by the CPU when invoking a trap handler (in your case an IO trap) so this behavior won't be observed . The same way the debugger is not debugging its own INT1 trap handler.

We're talking here about PL0 code ( hdpmi) emulating a "trap" for ring3 code ( the debugger ). In that case, the PL0 code has to clear the "ring3 TF" "manually".

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():

1static void MAIN_InterruptPM()
2{
3    if(aui.card_handler->irq_routine && aui.card_handler->irq_routine(&aui)) //check if the irq belong the sound card
4	{
5        asmproc();
6        MAIN_Interrupt();

and that asmproc() displays a counter on the upper right corner of the screen. As soon as SBEMU is loaded, the counter starts ( no SFX or music is yet played ). And the call frequency is quite high, my rough estimate is 500 times a second. I wonder why this is done...

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

Yes. Nevertheless, I added a little assenbly routine to function MAIN_InterruptPM(): […]
Show full quote

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():

Copy code to clipboard

1static void MAIN_InterruptPM()
2{
3    if(aui.card_handler->irq_routine && aui.card_handler->irq_routine(&aui)) //check if the irq belong the sound card
4	{
5        asmproc();
6        MAIN_Interrupt();

and that asmproc() displays a counter on the upper right corner of the screen. As soon as SBEMU is loaded, the counter starts ( no SFX or music is yet played ). And the call frequency is quite high, my rough estimate is 500 times a second. I wonder why this is done...

It's a IRQ generated by the sound card, the interrupt frequency is based on the buffer size and the sample rate. The frequency used to be configured 1/8 of the current, but the virtual DMA counter advances too large that doom and doom2 read the counter wrong.
It can be replaced by a timer(int 08), but lower frequency still can cause emulation problems.

Even when no sound plays it's still needed to advance the buffer pointer register of the sound card. If start/stop is used to avoid that, then there's no good timing to do that, do it in the SB DSP command handling (Io port trap) as I last tried, will cause freeze. Besides OPL3 doesn't have start command, it just output sound samples constantly.

There might be improvement that can be done, but I guess it's not the culprit that causes doom freeze. So could be postponed too.

I'd propose you for testing purposes to make sure your interception of IO ports, DMA and IRQ emulation is fine and bug free to initially build a software that redirects virtual DMA/IRQ and IO ports to a physical ISA sound blaster or compatible sound card present in that very testing machine at different ports, DMA and IRQ and configure the games to use your virtual ports, DMA and IRQ resources.

georgel wrote on 2023-02-10, 09:24:

I'd propose you for testing purposes to make sure your interception of IO ports, DMA and IRQ emulation is fine and bug free to initially build a software that redirects virtual DMA/IRQ and IO ports to a physical ISA sound blaster or compatible sound card present in that very testing machine at different ports, DMA and IRQ and configure the games to use your virtual ports, DMA and IRQ resources.

I believe current problem exist between DOOM or DOS/4GW or maybe HDPMI, DOOM and Duke3D will freeze with HDPMI(IOPL0), without SBEMU.

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

georgel wrote on 2023-02-10, 09:24:

I'd propose you for testing purposes to make sure your interception of IO ports, DMA and IRQ emulation is fine and bug free to initially build a software that redirects virtual DMA/IRQ and IO ports to a physical ISA sound blaster or compatible sound card present in that very testing machine at different ports, DMA and IRQ and configure the games to use your virtual ports, DMA and IRQ resources.

I believe current problem exist between DOOM or DOS/4GW or maybe HDPMI, DOOM and Duke3D will freeze with HDPMI(IOPL0), without SBEMU.

That's even easier to test and not to believe in -- just run the game(s) on a computer with a real ISA SB compatible sound card under DOS extenders and the DPMI server you suspect to be problematic.

georgel wrote on 2023-02-10, 10:44:

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

georgel wrote on 2023-02-10, 09:24:

I'd propose you for testing purposes to make sure your interception of IO ports, DMA and IRQ emulation is fine and bug free to initially build a software that redirects virtual DMA/IRQ and IO ports to a physical ISA sound blaster or compatible sound card present in that very testing machine at different ports, DMA and IRQ and configure the games to use your virtual ports, DMA and IRQ resources.

I believe current problem exist between DOOM or DOS/4GW or maybe HDPMI, DOOM and Duke3D will freeze with HDPMI(IOPL0), without SBEMU.

That's even easier to test and not to believe in -- just run the game(s) on a computer with a real ISA SB compatible sound card under DOS extenders and the DPMI server you suspect to be problematic.

No, there's nothing todo with SB or SB emulation, just a POPF not really working when IOPL=0, stated by the Intel programming manual, and noted in the DPMI spec 0.9/1.0, that should be a programming flaw/bug of the original game, but I don't know how they worked under win9x. I tried some workaround but it does not works for all games.
(there might be more bugs if SB emulation is involved.)

crazii wrote on 2023-02-10, 07:28:

There might be improvement that can be done, but I guess it's not the culprit that causes doom freeze. So could be postponed too.

Agreed. I tested this mainly because there's a problem with Wolfenstein 3D. Sound works fine with SBEMU, but the game sometimes misses "key release" events. You should notice this too if you play the game for a few minutes ( I tried on 2 real DOS machines ). The cause may be either that there's a STI somewhere while in protected-mode that shouldn't be there or that the emulation overhead simply is too large.

If you know the address of the POPF instruction that works under win98 but as you claim causes problem in your context then you could install SoftICE and windows 98 and debug there to see how it works under win98. Alternatively you could use the VirtualBox built-in debugger. What is the exact problem you are facing with POPF?

Baron von Riedesel wrote on 2023-02-10, 11:22:

crazii wrote on 2023-02-10, 07:28:

There might be improvement that can be done, but I guess it's not the culprit that causes doom freeze. So could be postponed too.

Agreed. I tested this mainly because there's a problem with Wolfenstein 3D. Sound works fine with SBEMU, but the game sometimes misses "key release" events. You should notice this too if you play the game for a few minutes ( I tried on 2 real DOS machines ). The cause may be either that there's a STI somewhere while in protected-mode that shouldn't be there or that the emulation overhead simply is too large.

Yes I found it too. Another big problem for my laptop is it will freeze. 🤣

georgel wrote on 2023-02-10, 11:28:

If you know the address of the POPF instruction that works under win98 but as you claim causes problem in your context then you could install SoftICE and windows 98 and debug there to see how it works under win98. Alternatively you could use the VirtualBox built-in debugger. What is the exact problem you are facing with POPF?

With OPL=0, POPF/IRET won't change the IF flag. there's a brief ref: https://www.felixcloutier.com/x86/popf:popfd:popfq
That will make "PUSHF CLI ... POPF" or "PUSHF STI ... POPF" not working properly, interrupt will not enabled or disable. I'm not skilled enough to debug, but I may try.

crazii wrote on 2023-02-10, 11:38:

georgel wrote on 2023-02-10, 11:28:

If you know the address of the POPF instruction that works under win98 but as you claim causes problem in your context then you could install SoftICE and windows 98 and debug there to see how it works under win98. Alternatively you could use the VirtualBox built-in debugger. What is the exact problem you are facing with POPF?

With OPL=0, POPF/IRET won't change the IF flag. there's a brief ref: https://www.felixcloutier.com/x86/popf:popfd:popfq
That will make "PUSHF CLI ... POPF" or "PUSHF STI ... POPF" not working properly, interrupt will not enabled or disable. I'm not skilled enough to debug, but I may try.

Most likely these instructions are working properly as Intel designed them and documented them over 35 years ago. Maybe the way what you are trying to achieve is wrong. If you are not able to debug then you are like a blind. These days you have number of decent tools to debug. Not like it was back in 1989 for example - only those who possessed expensive ICEs were able to debug PM code.

georgel wrote on 2023-02-10, 12:09:

Most likely these instructions are working properly as Intel designed them and documented them over 35 years ago.

Yes, they work as documented. However, crazii is very well aware of that, he just expressed himself a bit unfortunate. If you had read this thread carefully, you should be able to realize that.

If you are not able to debug then you are like a blind. These days you have number of decent tools to debug. Not like it was back in 1989 for example - only those who possessed expensive ICEs were able to debug PM code.

Debugging DOOM in a Windows DOS box to see why it works there is not too promising. That's because the Tenberry DOS extender is aware of enhanced mode Windows and behaves differently there.

Good news! I found an article on microsoft's devblog: https://devblogs.microsoft.com/oldnewthing/20 … 411-00/?p=93281
long story short: in CLI's exception handler, it scan the instructions forward/backward to find a pushf/popf, if there's, it will check the (E)FLAGS on stack whether it matches current flag of client, if it matches, it will modify the (E)FLAGS on stack , to raise TF, then raise the IF in trap exception handler.
That's probably how win9x handles it.
I'm gonna give it a try. 😁

BTW I think the DOS/4GW Doom used is prior to win9x, that means it is not win9x aware, probably.

BTW just now I was using TF to trap every instructions after CLI, which is a little bit close to the win9x way, but much more slower.

You know, back in the day I was one of many who would dunk on Microsoft about how crappy and unstable Win9x was, and why they wouldn't just develop something like Windows NT for average home users instead.

It wasn't until much more recently, with info here in Vogons, and reading articles on Raymond Chen's blog of crazy developer stories from back in the day, that I came to actually appreciate the great lengths that the engineers behind Windows had to go through, just to retain such a high level of compatibility with DOS software, and games in particular.

Don't take me wrong: Microsoft was not a sympathetic company, and there were many legitimate reasons to dislike them. The respect I'm expressing here is intended for the software developers who made all this compatibility magic happen under the hood, in such a relatively seamless way, that it made it seem easy and trivial to us.

Again, kudos for figuring all of this out!

Another question for crazii and Baron von Riedesel: would it make sense to use some of your work done here so far to abstract away the ISA DMA emulation in the form of reusable higher level API that would allow others to write emulators for various specific sound cards themselves? (A GUS emulator, a WSS emulator, etc.) Having one monolithic emulator for all kinds of DOS-era ISA sound cards (with support for all sorts of various physical target devices) might not be the best way to go. Or would it? I know it's easy for me to talk, having not contributed any usable code to this effort so far...

crazii wrote on 2023-02-10, 14:22:

long story short: in CLI's exception handler, it scan the instructions forward/backward to find a pushf/popf, if there's, it will check the (E)FLAGS on stack whether it matches current flag of client, if it matches, it will modify the (E)FLAGS on stack , to raise TF, then raise the IF in trap exception handler.

Cool - and nasty - trick!
However: the 5 locations of CLI in doom2.exe that I found ( 32-bit code only ) don't use that code sequence. 3 locations use a CLI, with a corresponding STI, so no problem. The two remaining use

1PUSHFD
2POP EAX
3CLI

So yes, try it, but don't be too disappointed if it doesn't fully work.

BTW I think the DOS/4GW Doom used is prior to win9x, that means it is not win9x aware, probably.

Not Win9x aware, but "enhanced mode" aware - they use int 2Fh, ax=1681h/1682h ( enter/leave critical section), for example.

Baron von Riedesel wrote on 2023-02-10, 13:09:

Debugging DOOM in a Windows DOS box to see why it works there is not too promising. That's because the Tenberry DOS extender is aware of enhanced mode Windows and behaves differently there.

If you think so then use another DOS extender like DOS32/A which as far as I remember does not have any special treatment for windows' DPMI. But what is better -- it is open source and you can see how it manages interrupts. Or even modify it for your testing purposes. I admit I am not motivated by the goal of SB emulation (plenty of old machines around with cheap SB OPL compatible sound cards that are still scrapped) therefore I haven't payed attention to the whole thread for sure and I am unaware with the whole concept of your emulation. If one still wants to use emulated SB they already can use DOSBox or even better MAME. I treat this effort here as educational.

georgel wrote on 2023-02-10, 15:06:

Baron von Riedesel wrote on 2023-02-10, 13:09:

Debugging DOOM in a Windows DOS box to see why it works there is not too promising. That's because the Tenberry DOS extender is aware of enhanced mode Windows and behaves differently there.

If you think so then use another DOS extender like DOS32/A which as far as I remember does not have any special treatment for windows' DPMI. I admit I am not motivated by the goal of SB emulation (plenty of old machines around with cheap SB OPL compatible sound cards that are still scrapped) therefore I haven't payed attention to the whole thread for sure and I am unaware with the whole concept of your emulation. If one still wants to use emulated SB they already can use DOSBox or even better MAME. I treat this effort here as educational.

Older laptops without built-in sound cards, IBM PS/2 machines with MCA slots, later systems lacking ISA slots but still otherwise DOS compatible... Increasing rarity of some DOS-era sound devices... Plenty of use cases that make these efforts worthwhile!