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.

I'm loving the SVGA modes and they seem to work really well - the inbuilt benchmark is also fantastic.

Apologies if this has been asked before or if it's just some side effect of the higher resolution that I'm not aware of, but the SVGA modes are much brighter than non-SVGA (on my system at least). I'm using the lowest gamma option but rooms are still brightly lit, which does take away some of that classic DOOM atmosphere. Are there any additional settings around this?

Thanks!

On a CRT, a higher refresh rate usually had thinner scanlines so it'd be comparatively darker than a 60hz mode that SVGA would tend to be, with 640x400 being the common exception.

There is definitely a bug in the VESA modes that makes illumination brighter, @DEAT also noticed it.

leileilol wrote on 2024-05-20, 00:43:

On a CRT, a higher refresh rate usually had thinner scanlines so it'd be comparatively darker than a 60hz mode that SVGA would tend to be, with 640x400 being the common exception.

I have generally noticed that this is more down to the comparative TLV of the tube and the deflection circuit rather than the chosen resolution. A very high TVL monitor will have bigger gaps between the drawn lines on a lower resolution and be darker, not brighter at the same G2 level. However, a monitor will generally be able to achieve higher contrast (white point) when the resolution is lower because it isn't pushing as much bandwidth through the cable/circuitry and so it can resolve more information per pixel before reflections and such begin to distort and smear the image. This is especially apparent on very high resolution CRTs; when you use a cheaper cable at 1600x1200, you will tend to get smearing and distortion.

Maybe I'm missing something, but I've never heard of refresh rate being tied to the thickness of scanlines.

7F20 wrote on 2024-05-21, 13:43:

Maybe I'm missing something, but I've never heard of refresh rate being tied to the thickness of scanlines.

Think of drawing on newspaper type paper with a felt-tip or fibre-tip pen, if you draw a line fast, it's thin, if you draw it slow it's thick where the ink soaks in. It's kinda the same with phosphor glow, the glow "sinks in" and makes more phosphor around the glowing phosphor glow.

BitWrangler wrote on 2024-05-21, 14:15:

7F20 wrote on 2024-05-21, 13:43:

Maybe I'm missing something, but I've never heard of refresh rate being tied to the thickness of scanlines.

Think of drawing on newspaper type paper with a felt-tip or fibre-tip pen, if you draw a line fast, it's thin, if you draw it slow it's thick where the ink soaks in. It's kinda the same with phosphor glow, the glow "sinks in" and makes more phosphor around the glowing phosphor glow.

Okay. That makes sense. It's the duration of the frame leading to phosphor persistence, not the width of the scanlines.

New release! FastDoom 0.9.9d

Changelog:

* VESA 400x300 modes support
* Fixed issue #181 (FastDoom crashes on exit when using AWE32 music device + SoftMPU). Thanks @TheElf01 for finding this issue.
* Multiple optimizations (C)
* New VGA 320x100 executable. Uses same direct rendering method as vanilla Doom, but with half height resolution. High detail resolution is 320x100, low detail 160x100 and potato detail 80x100. Recommended for slow 386 cpu's with VGA cards. 2D elements also have half height resolution, so text is pretty much unreadable (unless someone creates a WAD with optimized fonts for this mode)
* Fixed issue #192 (Save game buffer overflow). Now saving on MAP24 of Hell Revealed doesn't crash. Thanks @deat322 for finding this issue.
* Added debug to file support for debugging (only for developers)

https://github.com/viti95/FastDoom/releases/tag/0.9.9d

ViTi95 wrote on 2024-05-30, 20:20:

2D elements also have half height resolution, so text is pretty much unreadable (unless someone creates a WAD with optimized fonts for this mode)

Having a hard time picturing *how* one might engineer UI for this...

ViTi95 wrote on 2024-05-30, 20:20:

2D elements also have half height resolution, so text is pretty much unreadable (unless someone creates a WAD with optimized fonts for this mode)

Miniwi is the smallest readable font I know. I use it to run Debian consoles on low-res monitors and it's totally readable.

https://github.com/a780201/miniwi

I'm thinking something along the lines of the Wing Commander/System Shock origin smallfont

7F20 wrote on 2024-05-31, 02:10:

ViTi95 wrote on 2024-05-30, 20:20:

2D elements also have half height resolution, so text is pretty much unreadable (unless someone creates a WAD with optimized fonts for this mode)

Miniwi is the smallest readable font I know. I use it to run Debian consoles on low-res monitors and it's totally readable.

https://github.com/a780201/miniwi

That is actually entirely legible for what it is. I guess it was made for dot matrix screens? I can swear this font was used on my Casio fx-6300g I used in high school and university. Ages ago..

Doom smallest font (HUD ammo count, just numbers) use 4x6 pixels, which it's already veeeery small. So for half height resolution is even worse, we only have 4x3 available. The small text font are made of 8x8 maximum pixels, so same problem of very low height available (8x4).

EDIT: Maybe I can adapt one of the smalles fonts I've ever used, I tested this font once in an Arduino project for my simracing hub display (I changed it to a bigger one since it was too small for what I needed):