Did you say that you've gotten 0.9.9c working in SBEMU / VSBHDA? I've tried all manner of settings for both programs, and also in FDSETUP.EXE, and always get a "Failed to detect music card -1" and the same "Failed to detect digital sound card -1" message, and FDOOM refuses to run; the only way to get it running is to disable both music and sound. Always the -1 error message, and in the FDOOM.CFG, the music and digital sound cards are set to -1, even though I chose Sound Blaster for both music and digital effects in the setup program. Is there a specific manual way to specify the "Sound Blaster" card in the .cfg program? -1 usually means "autodetect" or, confusingly "not detected".

Has anyone gotten any version of FASTDOOM working in bare metal DOS with SBEMU? Report how you got it working, please.

Also, confusingly, the VESA modes run perfectly, even though my reported VESA memory is 32 Mb, but always crash (hard freeze the system) only when *exiting* FASTDOOM. I can get around this by getting the program to error out, for example in reporting a missing / incompatible demo file, using one from Doom2.wad for instance while using the main Doom v. 1.9 wad instread. The text mode .exes don't crash upon exit, however.

zyzzle wrote on 2024-04-24, 00:03:

Has anyone gotten any version of FASTDOOM working in bare metal DOS with SBEMU? Report how you got it working, please.

It has been mentioned a few month ago that you have to disable VCPI before launching fastdoom:

1jemmex novcpi
2fdoom.exe
3jemmex vcpi

I'm sure there's also an option in the Dos32A extender to avoid this "hack", but I can't remember right now...

ViTi95 wrote on 2024-03-24, 19:00:

[*]Fixed SBEMU support (thanks to Crazii)

As much as I appreciate your help with that, this doesn't seem like the right approach. Isn't it the point of the emulator to be compatible with the games, and not the other way around?

If the previous implementation was working correctly with actual hardware, but not with SBEMU, shouldn't that be fixed in SBEMU instead?

It was easier to fix FastDoom than SBEMU, anyway I was using a non-standard configuration that didn't fit into DPMI specs:

crazii wrote:

A DOS protected mode program uses FLAT model (CS=DS=SS=ES) like a win32 one, but it's not always true when in interrupts when a […]
Show full quote

A DOS protected mode program uses FLAT model (CS=DS=SS=ES) like a win32 one, but it's not always true when in interrupts when a DPMI host is used, as the DPMI spec requires a Locked Protected Mode Stack (LPMS) for DPMI client interrupt handling.

DOS32A will provide a good stack segment(SS=DS) for interrupts when it gains full control of protected mode interfaces (i.e. entered PM from real mode or via VCPI), but it doesn't do that for DPMI mode. That's probably why it prefers VCPI over DPMI when both are available.

OpenWatcom may use EBP as a base register to access DGROUP data, when some conditions are met (few function parameters so they are passed by registers and local variables are optimized out using GPRs so that a function stack frame isn't needed).
Normally this is OK, since [EBP] equals SS:[EBP] and equals DS:[EBP] for FLAT model, but will be problematic in interrupt handler when a DPMI host is used.

The best way to solve that is to add an extra wrapper to DOS32A to switch stack for interrupt handlers for DPMI mode, like the _go32 api for DJGPP. But I'm not ready to touch dos32a yet for now, so the current method is used.

There might be other workarounds, i.e. force establishing a stack frame for specific functions, using #pragma aux somefunction __frame; so that EBP is forced as a stack frame base. but it's much less convenient because the calling trees are complicated, every function that get called directly/indirectly from a interrupt handler will need that.

I guess FastDoom doesn't like win9x for the same reason, but it will (or get more close to) be better now.

Other interrupt handlers might also needs this, including the DPMI real mode callbacks functions, but currently there's no case of using EBP so they're safe for now.

Baron von Riedesel wrote on 2024-04-24, 07:47:

It has been mentioned a few month ago that you have to disable VCPI before launching fastdoom: […]
Show full quote

zyzzle wrote on 2024-04-24, 00:03:

Has anyone gotten any version of FASTDOOM working in bare metal DOS with SBEMU? Report how you got it working, please.

It has been mentioned a few month ago that you have to disable VCPI before launching fastdoom:

Copy code to clipboard

1jemmex novcpi
2fdoom.exe
3jemmex vcpi

I'm sure there's also an option in the Dos32A extender to avoid this "hack", but I can't remember right now...

Thanks for the tip. Got VSBHDA working finally. I had tried getting rid of the DOS32A extender with D3STUB and that didn't help with the sound detection issue. But your JEMMEX /NOVCPI hint did.

digger wrote on 2024-04-25, 09:14:

ViTi95 wrote on 2024-03-24, 19:00:

[*]Fixed SBEMU support (thanks to Crazii)

As much as I appreciate your help with that, this doesn't seem like the right approach. Isn't it the point of the emulator to be compatible with the games, and not the other way around?

If the previous implementation was working correctly with actual hardware, but not with SBEMU, shouldn't that be fixed in SBEMU instead?

There's nothing SBEMU can do. It's just DOS32A not compatible with HDPMI (or probably any DPMIs).

Thanks for clarifying, @ViTi95 and @crazii. And thanks for the great work you're both doing!

digger wrote on 2024-04-30, 08:53:

Thanks for clarifying, @ViTi95 and @crazii. And thanks for the great work you're both doing!

From Ken Silverman's blog. He wrote NOLFB as a workaround when XP came out because of this issue. The sacrifice is that it kills off all the VESA 2.0 modes:

When DOS programs initialize the VESA 2.0 linear framebuffer mode, one of the steps (after the screen mode is set) is using DPMI function call (ax=0x800) to map video memory into a linear space. Under WinNT/2K/XP, this call always fails. I don't know why. My programs exit to DOS with this error message: "DPMI_mapPhysicalToLinear() failed!". Unfortunately, the screen is usually black or jumbled at this point, so to most people, it looks like a crash. (If you don't believe me, type "duke3d > error.txt" at the command prompt and look at error.txt after running it 😀 Here's my workaround:

NOLFB.ZIP (1,350 bytes) A TSR that patches the VESA driver by fooling DOS programs into thinking the VESA 2.0 linear framebuffer modes aren't supported. Source code is included. You must run this program at the command prompt. Double-clicking on NOLFB.COM in the windows explorer will NOT work! If you're unfamiliar with DOS commands, then please follow these instructions:

If I read the situation correctly, limiting available video memory seems like a logical trade off for more program compatibility.