search

crazii / SBEMU

legacy sound blaster emulation for DOS
GNU General Public License v2.0
617 stars 33 forks source link

Update SBEMU to work with the the the port-trapping API in the upstream HX version #40

Open volkertb opened 11 months ago

volkertb commented 11 months ago

@crazii To prevent yourself from having to maintain a fork of the HX project indefinitely, perhaps it's better to update SBEMU to be compatible with the port-trapping API that was introduced in more recent releases of the upstream HX/HDPMI project?

This is what I'm referring to: https://github.com/Baron-von-Riedesel/HX/issues/11#issuecomment-1773962231

Thanks.

crazii commented 11 months ago

I don't remember the details but SBEMU uses some extra functions that were added to the fork. It should be checked whether it could be removed easily.

Torinde commented 10 months ago

Would be great if those get in sync. DOSbox-X uses HX and I would like to use that together with SBEMU on a laptop with Intel HDA and booting DOS directly.

crazii commented 10 months ago

Would be great if those get in sync. DOSbox-X uses HX and I would like to use that together with SBEMU on a laptop with Intel HDA and booting DOS directly.

HX has VSBHDA (https://github.com/Baron-von-Riedesel/VSBHDA), it's like SBEMU and works with latest HX, have you tried it?

Torinde commented 10 months ago

Will try. And now I see somebody tried already at Baron-von-Riedesel/VSBHDA/issues/2 (although with quite old version of DOSbox-X).

Still, it seems better if VSBHDA / SBEMU converge instead of diverge as currently.

Torinde commented 9 months ago

Besides the fixe for MDK's keyboard / "Get Interrupt Context" function, is there something else required to add into upstream HX in order for SBEMU to work with it?

volkertb commented 9 months ago

As answered here, the port-trapping API in the upstream HX project is documented at https://github.com/Baron-von-Riedesel/HX/blob/master/Src/HDPMI/HDPMIAPI.TXT.

So the question is if this provides all the needed functionality, or if some things are still unclear or missing.

crazii commented 8 months ago

As answered here, the port-trapping API in the upstream HX project is documented at https://github.com/Baron-von-Riedesel/HX/blob/master/Src/HDPMI/HDPMIAPI.TXT.

So the question is if this provides all the needed functionality, or if some things are still unclear or missing.

No. DPMI host with IOPL0 needs virtual interrupts, currently SetPVI is a unsafe hack that might cause problems. after digging into the freeze problem recent days, now I have to stick to the HDPMI fork with more code changes. see this comment for detail: https://github.com/crazii/SBEMU/issues/13#issuecomment-1938457427 Current HDPMI cannot work perfectly without huge changes/additions.

The idea of a new DPMI host comes to me recently that we solve this once and for all, and also for 16 bit protected mode games( ONE DPMI host can support 32bit and 16bit at the same time). I could use the usbddos' 16bit DPMI code as code base, it is working with basic DPMI functions. it's hard (especially for compatibility tests/debugging) but very possible. By using C code we have some performance loss but more efficient in developing. Besides the Open Watcom is a very optimized compiler set - far more optimized than Borland C last time I checked the assembly output.

if it is done, I can also create PRs for ADLiPT and SoftMPU so that they support PM games without big changes, even almost 0 changes/cost.

Sounds intriguing, doesn't it? at least it does to me. :)

Torinde commented 8 months ago

The idea of a new DPMI host comes to me recently that we solve this once and for all, and also for 16 bit protected mode games( ONE DPMI host can support 32bit and 16bit at the same time).

Sounds good!

But what about running DOSbox-X HXDOS edition together with SBEMU? From what you describe it seems that won't be possible? Or you can make the new DPMI host somewhat compatible with HX?

crazii commented 7 months ago

you can make the new DPMI host somewhat compatible with HX?

It's definitely possible. I can try it. I'm currently coding on it but there's more details in DPMI api than I thought, I'm not finishing the codes yet, and haven't started any tests/debugs yet. The DPMI in usbddos implements only a small core portion of DPMI api, there's much more to do.