Baron von Riedesel wrote on 2023-02-10, 15:03:

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 C […]
Show full quote

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

Copy code to clipboard

1PUSHFD
2POP EAX
3CLI

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

I tested just now and it still freeze, how does it restore IF? another "PUSH EAX & POPFD"?

digger wrote on 2023-02-10, 15:10:

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!

All these for most of people are rubbish, grab several suitable before being scrapped. If you really need them. Yes, it may not be a laptop of your taste but you'll live with it unless it is easier for you to create an emulator of a $30 sound card.

digger wrote on 2023-02-10, 15:10:

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!

+1

georgel is completely missing the point of this thread. Don't bother talking with him anyway, he hasn't learned anything when he was "absent".

unable to trap pushfd & pop eax, and push eax & popfd.
I think I need go back to my previous way to trap all instruction until a popf?
I be damned. 🤣

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

I tested just now and it still freeze, how does it restore IF? another "PUSH EAX & POPFD"?

Yes, exactly.

How about set SS to 0 and trigger a GP? I tested that way but it have bugs.
Since interrupt is disabled, DPMI kernel won't read SS anymore (OR NOT, client might call dpmi APIs), this might be safe? at least it will reduce the exceptions - not single step but stack related, like stack variables and such.

Oh, my mentor Gmlb256 ! The only thing I can learn from you is playing computer games 😉 I wasn't here because I wanted it this way!
@crazii you are still guessing what the problem is. If you prove it you'll be more effective in resolving it. When your machine freezes what is that? A tripple fault? Or an endless loop with interrupts disabled?

crazii wrote on 2023-02-10, 15:30:

How about set SS to 0 and trigger a GP? I tested that way but it have bugs.
Since interrupt is disabled, DPMI kernel won't read SS anymore (OR NOT, client might call dpmi APIs), this might be safe? at least it will reduce the exceptions - not single step but stack related, like stack variables and such.

Such types of suggestions reveal a certain level of despair already 😀.

IIRC the freeze in DOOM2 is during an SB reset: writing 01 to port 226h, wait a few microseconds, and then write 00 to port 226h. Since interrupts are disabled, the "wait a few microseconds" last "forever".

So what about trapping write of 01 to port 226h and, if caught, enable interrupts? And if the previous state of the IF was 0, disable interrupts again if a 00 is written to port 226h?

Baron von Riedesel wrote on 2023-02-10, 16:05:

IIRC the freeze in DOOM2 is during an SB reset: writing 01 to port 226h, wait a few microseconds, and then write 00 to port 226h. Since interrupts are disabled, the "wait a few microseconds" last "forever".

So what about trapping write of 01 to port 226h and, if caught, enable interrupts? And if the previous state of the IF was 0, disable interrupts again if a 00 is written to port 226h?

It might work for doom2, but won't it cause problem on other games? I'm quite worried 🤣.

BTW I tried trapping every instruction after CLI, and stop trapping until IRET/STI/POPF with IF set, and it works for doom2, but still got a transfer stack overflow for doom1.
EDIT: doom1 works this way without SBEMU.

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

BTW I tried trapping every instruction after CLI, and stop trapping until IRET/STI/POPF with IF set, and it works for doom2, but still got a transfer stack overflow for doom1.

There's a good probability that this transfer stack error isn't related to the "freeze" error. So I guess this will just be the next hurdle. That's why I suggested to postpone the doom fix and instead make sure that the emulation works without errors. That actually means that at this stage the best thing to do is to ensure that SB example programs using SFX ( with binary and source available ) work correctly.

Baron von Riedesel wrote on 2023-02-10, 16:24:

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

BTW I tried trapping every instruction after CLI, and stop trapping until IRET/STI/POPF with IF set, and it works for doom2, but still got a transfer stack overflow for doom1.

There's a good probability that this transfer stack error isn't related to the "freeze" error. So I guess this will just be the next hurdle. That's why I suggested to postpone the doom fix and instead make sure that the emulation works without errors. That actually means that at this stage the best thing to do is to ensure that SB example programs using SFX ( with binary and source available ) work correctly.

OK, I'll first check the emulation now.

I think doom comes to a dead loop after write dsp command 0FAh (SB16 command to write 8051 memory). after 0FAh command it keeps reading for something specific.
I read the dosbox-x source and found nothing to read related to this one.
EDIT: it doesn't finish the 0FAh command, the command need two other bytes but it doesn't write them, instead it keeps reading status / reading data.

> OK, I'll first check the emulation now.

I have two simple SB SFX test programs (binary + source), first runs in protected-mode, second in real-mode. They run ok, but sound is "noisy" with SBEMU. They work correctly with good sound in DosBox. Could you check the sound quality on your machines?

Baron von Riedesel wrote on 2023-02-10, 17:07:

> OK, I'll first check the emulation now.

I have two simple SB SFX test programs (binary + source), first runs in protected-mode, second in real-mode. They run ok, but sound is "noisy" with SBEMU. They work correctly with good sound in DosBox. Could you check the sound quality on your machines?

Yes, I can first test in on virtualbox.

I disabled interrupt for SBEMU, only port trapping left, then there's is still transfer stack overflow. I think it is literally a stack overflow.
since doom do DSP commands in int08, the stack setup might be small, and the IO port trap will copy ring0 stack frame (a PUSHAD and fault frame) to ring3 client so it uses much stack space, but in this way it support recursion. I'll try to copy the stack frame to host memory first.

EDIT: tried that method with much less client stack space used, still the same. 🤣

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

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.

Clever hack, and wow Intel what a shitshow to not trap on obvious privilege fault. I wonder why wasnt it fixed in hardware, its not like they got 386 right the first time, there were several hardware revisions with broken 32bit mode https://www.pcjs.org/blog/2015/02/23/. 386 came out in 1985, Windows 2.0 with Windows/386 (MS-DOS programs to run in parallel in "virtual 8086" CPU mode) in 1987, surely Microsoft spotted problem in less than a year, and MS would be the only early user of enhanced mode anyway.

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

Baron von Riedesel wrote on 2023-02-10, 15:03:

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 C […]
Show full quote

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

Copy code to clipboard

1PUSHFD
2POP EAX
3CLI

I tested just now and it still freeze, how does it restore IF? another "PUSH EAX & POPFD"?

I dont think it really matters how it restores it, as you need to patch the moment it saves it. Raymond says "pattern above or one of the common variations" which I suspect means replacing value on the stack is just one of them, with another one scanning code before CLI until pushf and analyzing whats between.

1pushfd
2pop x
3cli

where x is O/M https://www.felixcloutier.com/x86/pop

how virtualbox handles it: https://docs.oracle.com/en/virtualization/vir … rt-details.html

In particular, the recompiler is used when guest code disables interrupts and Oracle VM VirtualBox cannot figure out when they will be switched back on. In these situations, Oracle VM VirtualBox actually analyzes the guest code using its own disassembler.

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

unable to trap pushfd & pop eax, and push eax & popfd.
I think I need go back to my previous way to trap all instruction until a popf?

scan behind between cli and pushf, modify X appropriately, let the game restore X back kicking off the trap

rasz_pl wrote on 2023-02-11, 06:13:

Clever hack, and wow Intel what a shitshow to not trap on obvious privilege fault. I wonder why wasnt it fixed in hardware, its […]
Show full quote

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

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.

Clever hack, and wow Intel what a shitshow to not trap on obvious privilege fault. I wonder why wasnt it fixed in hardware, its not like they got 386 right the first time, there were several hardware revisions with broken 32bit mode https://www.pcjs.org/blog/2015/02/23/. 386 came out in 1985, Windows 2.0 with Windows/386 (MS-DOS programs to run in parallel in "virtual 8086" CPU mode) in 1987, surely Microsoft spotted problem in less than a year, and MS would be the only early user of enhanced mode anyway.

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

Baron von Riedesel wrote on 2023-02-10, 15:03:

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 C […]
Show full quote

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

Copy code to clipboard

1PUSHFD
2POP EAX
3CLI

I tested just now and it still freeze, how does it restore IF? another "PUSH EAX & POPFD"?

I dont think it really matters how it restores it, as you need to patch the moment it saves it. Raymond says "pattern above or one of the common variations" which I suspect means replacing value on the stack is just one of them, with another one scanning code before CLI until pushf and analyzing whats between.

Copy code to clipboard

1pushfd
2pop x
3cli

where x is any of https://www.felixcloutier.com/x86/pop

how virtualbox handles it: https://docs.oracle.com/en/virtualization/vir … rt-details.html

In particular, the recompiler is used when guest code disables interrupts and Oracle VM VirtualBox cannot figure out when they will be switched back on. In these situations, Oracle VM VirtualBox actually analyzes the guest code using its own disassembler.

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

unable to trap pushfd & pop eax, and push eax & popfd.
I think I need go back to my previous way to trap all instruction until a popf?

scan behind between cli and pushf, modify X appropriately, let the game restore X back kicking off the trap

Really good idea!
But it involves too much assembly codes - POP X have too many forms: different registers, including popping to memory with different segment prefix. Maybe @Baron von Riedesel can help with that. For now I'm sticking to trapping all instructions which is much simpler but maybe slower, I tested on real machine, still good. I gotta fix doom's stack overflow first.
If only registers are used, maybe I can just scan a PUSHF and half a POP instruction and scan all the registers values to match the EFLAGS. 😁

crazii wrote on 2023-02-11, 06:30:

Really good idea!
But it involves too much assembly codes - POP X have too many forms: different registers, including popping to memory with different segment prefix. Maybe @Baron von Riedesel can help with that. For now I'm sticking to trapping all instructions which is much simpler but maybe slower, I tested on real machine, still good. I gotta fix doom's stack overflow first.
If only registers are used, maybe I can just scan a PUSHF and half a POP instruction and scan all the registers values to match the EFLAGS. 😁

a quick path checking for [9c 58-5b fa] with slower fallback sounds good.
ps Underpants Gnomes reminded me XP code leaked few years ago (nt5src.7z). ReactOS can also run doom, sadly "ReactOS' NTVDM on the other hand, is a software emulator"
https://web.archive.org/web/20170723164052/ht … ss-ntvdm-part-1
https://web.archive.org/web/20151216085857/ht … ss-ntvdm-part-2

Hello,

there might be another problem, this time related to emulated interrupts. While that works for protected-mode emulation, it seems that no interrupts are generated in V86-mode.
I attached a simple test prog that should display strings "playing part 0" or "playing part 1". It does so on real machines and in DosBox, but not in SBEMU. I don't have the newest version of SBEMU available, though, so you might have fixed that in the meantime?

Baron von Riedesel wrote on 2023-02-10, 17:07:

> OK, I'll first check the emulation now.

I have two simple SB SFX test programs (binary + source), first runs in protected-mode, second in real-mode. They run ok, but sound is "noisy" with SBEMU. They work correctly with good sound in DosBox. Could you check the sound quality on your machines?

It seems there's a bug in resampling. I copy the code from MPXPlay and didn't check, now it is fixed but I didn't commit yet.
EDIT: this will also fix the QUAKE noise.