Does it crash right at the start? Or does it crash ingame? Also, does this happen with other executables such as fdoom.exe or fdoom13h.exe?

EDIT: I think I've found the issue, it's crashing on cards with 16Mb or more of VRAM

https://github.com/viti95/FastDoom/issues/185

EDIT2: NOLFB fixes this issue, not ideal but better than nothing until I fix the issue

EDIT3: I've fixed this! Turns out DPMI function 0x800 cannot map more than 8Mb of memory. Why? Really I don't know. I've added a cap to limit the VRAM memory available to 8Mb, now al "broken" cards work just fine

ViTi95 wrote on 2024-04-03, 07:29:

Does it crash right at the start? Or does it crash ingame? Also, does this happen with other executables such as fdoom.exe or fd […]
Show full quote

Does it crash right at the start? Or does it crash ingame? Also, does this happen with other executables such as fdoom.exe or fdoom13h.exe?

EDIT: I think I've found the issue, it's crashing on cards with 16Mb or more of VRAM

https://github.com/viti95/FastDoom/issues/185

EDIT2: NOLFB fixes this issue, not ideal but better than nothing until I fix the issue

EDIT3: I've fixed this! Turns out DPMI function 0x800 cannot map more than 8Mb of memory. Why? Really I don't know. I've added a cap to limit the VRAM memory available to 8Mb, now al "broken" cards work just fine

Thanks! I will try to compile and test again.

I'm going to upload a new bugfixing release, many cards do fail on VESA modes right now due to this issue.

ViTi95 wrote on 2024-04-03, 16:53:

I'm going to upload a new bugfixing release, many cards do fail on VESA modes right now due to this issue.

thanks, I do appreciate it! I am having little success trying to get Open Watcom to install in DosBox!

Is there any benefit in using the updated DOS32A?

New bugfixing release! FastDoom 0.9.9b:

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

Changelog:

• Hercules InColor support
• Mode-X 320x240 mode support (great for old laptops without VESA support and 640x480 display)
• Fixed MDA debug, now text don't blink all the time
• Fixed issue #183, random crashes on low-res executables
• Fixed issue #62, videocards with more than 8Mb crashed on VESA modes
• Removed "-singletics" commandline parameter. It was only used for debugging purposes.
• Upgraded build scripts
• Removed MS-DOS/Windows build scripts. Those were pretty much outdated, and all tooling now is Linux based. It's possible to build FastDoom on Windows using WSL2.

ViTi95 wrote on 2024-04-03, 17:19:

New bugfixing release! FastDoom 0.9.9b:
<snip>

Confirmed working on a GeForce 4 MX440 AGP.

It also worked previously on a 32mb TNT2 with BIOS 2.05.17.02.04. I flashed the BIOS from one card to another and that fixed it... So I wonder why that is.

Definetely there is a bug in the DOS Extender, DPMI function 0800H. It fails if we try to map more than 8Mb. This issue also happens on other games, and it turns out that's why NOLFB program was created (NOLFB - Disables LFB enabling DOS games to fallback to VESA 1.2 modes). There are cards that limit the amount of VESA VRAM available on the VBIOS, for example both my Geforce 256 cards (32Mb) were working totally fine, as they limit the amount available to 4Mb. I guess that's why one VBIOS did work for you and the other didn't, one had to limit VESA and the other don't.

ViTi95 wrote on 2024-04-03, 18:30:

Definetely there is a bug in the DOS Extender, DPMI function 0800H. It fails if we try to map more than 8Mb. This issue also happens on other games, and it turns out that's why NOLFB program was created (NOLFB - Disables LFB enabling DOS games to fallback to VESA 1.2 modes). There are cards that limit the amount of VESA VRAM available on the VBIOS, for example both my Geforce 256 cards (32Mb) were working totally fine, as they limit the amount available to 4Mb. I guess that's why one VBIOS did work for you and the other didn't, one had to limit VESA and the other don't.

Aha! That explains it... I wonder if there is a way to modify a newer GeForce BIOS to do this, but that's a different topic...

Today I tried to test version FastDoom 0.9.9 and found that compatibility with saves from version 0.9.7 is broken. I had to roll back to version 0.9.7. Perhaps I missed something and there is version 0.9.9?
If there are several wad files in the FastDoom directory, you can select the appropriate game option. This is a great idea. However, in my opinion, it has not been brought to its logical conclusion. It would be nice to have different saves for each option.
Many thanks to Viti for the work done.

Darmok wrote on 2024-04-04, 11:02:

Today I tried to test version FastDoom 0.9.9 and found that compatibility with saves from version 0.9.7 is broken. I had to roll back to version 0.9.7. Perhaps I missed something and there is version 0.9.9?
If there are several wad files in the FastDoom directory, you can select the appropriate game option. This is a great idea. However, in my opinion, it has not been brought to its logical conclusion. It would be nice to have different saves for each option.
Many thanks to Viti for the work done.

Mmmmm I'll take a look, savegames from 0.9.7 should be compatible with 0.9.9, so I'm pretty sure something not intended has changed (and probably is causing issues).

Bondi wrote on 2023-11-10, 08:32:

And it just occuretd to me that there is a very useful feature that you could add - MIDI to serial(COM) port output. That's waht SoftMPU can do for real mode games. For protected mode Cloudschatze has made patches for many games (Re: MPU-232 : RS-232 MIDI interface, compatible with SoftMPU)
This would be very useful for laptops that usually lack a gameport. One needs a 8-pin Mini-DIN to DE9 cable like Hosa DBK-103 which is compatible with Roland, Yamaha and Korg synthesizers. I have this cable and can do testing if you decide to take this up.
Details of the cable https://hosatech.com/wp-content/uploads/2013/ … -100_Pinout.pdf

BTW, I've been able to add serial-MIDI support, can you test it? Right now is fixed to COM1 and 38400 baud rate. I haven't tested this on a real midi device, but it seems to work fine on my laptop (Retro PC -> Serial port -> Serial-USB adapter -> Windows PC -> "Hairless MIDI<->Serial Bridge" -> Microsoft GS Wavetable Synth)

EDIT: Music sound device is 21 in case you need to modify the cfg

ViTi95 wrote on 2024-04-05, 05:38:

BTW, I've been able to add serial-MIDI support, can you test it? Right now is fixed to COM1 and 38400 baud rate. I haven't tested this on a real midi device, but it seems to work fine on my laptop (Retro PC -> Serial port -> Serial-USB adapter -> Windows PC -> "Hairless MIDI<->Serial Bridge" -> Microsoft GS Wavetable Synth)

FastDoom_RS232.zip

EDIT: Music sound device is 21 in case you need to modify the cfg

Yes, it's working! Tested with Roland SC-55K.

Nice! Now I have to add support for selectable COM ports and more baud rates. This will be available on the next release 😁

Also It shouldn't be hard to add LPT MIDI support, but I have no hardware to test with. And the DreamBlaster S2P is out of stock 😖

ViTi95 wrote on 2024-04-05, 07:02:

Nice! Now I have to add support for selectable COM ports and more baud rates. This will be available on the next release 😁

Also It shouldn't be hard to add LPT MIDI support, but I have no hardware to test with. And the DreamBlaster S2P is out of stock 😖

Awesome! That's a feature I'm going to use for sure.

FastDoom isn't a Swiss army knife, but a martian rover already 😁
Next thing to add is the direct support for AC97/Intel HDA. Which probably conflicts with the idea of a fast port for slow computers, but who cares 😀

Bondi wrote on 2024-04-05, 07:37:

Which probably conflicts with the idea of a fast port for slow computers, but who cares 😀

I do. Tbh I feels like this project has lost focus. Strip out networking to gain speed? Sure let's do that. (Fair enough, made sense at that time.) Add high res rendering which can only reasonably be used on faster machines? Alright. And let's remove cheat codes, just because. Emulate an entire sound card? Why not. Hey can we maybe have multiplayer back? Noooo, think of the poor low end machines... I've been thinking about whether I have the time to take all the enhancements, and only the enhancements, and move them into some kind of "Deluxe Doom", one that only builds up, never down (but while staying on DOS - otherwise one might just as well go with e.g. GZDoom).

This post just seems in bad faith but I'll reply anyway.

* Cheats have been disabled in Nightmare mode, as was true in the original game as well by the way

* "Emulate an entire sound card?" is this referring to SBEMU support? That doesn't work the way you think it does.

If you want networking just ask nicely and perhaps provide reasoning. Don't be entitled, if you want that bad, fork the project and do it yourself.

ViTi95 wrote on 2024-04-05, 07:02:

Nice! Now I have to add support for selectable COM ports and more baud rates. This will be available on the next release 😁

Also It shouldn't be hard to add LPT MIDI support, but I have no hardware to test with. And the DreamBlaster S2P is out of stock 😖

Nice! thanks too bad im.not in home to test

Using my raspberry pi in com1 is amzazing because i can select whatever soundfont i want, and there is one, arachne, that sound amazing in doom

i will test this sunday!

ViTi95 wrote on 2024-04-05, 05:38:

BTW, I've been able to add serial-MIDI support, can you test it? Right now is fixed to COM1 and 38400 baud rate. I haven't tested this on a real midi device, but it seems to work fine on my laptop (Retro PC -> Serial port -> Serial-USB adapter -> Windows PC -> "Hairless MIDI<->Serial Bridge" -> Microsoft GS Wavetable Synth)

FastDoom_RS232.zip

EDIT: Music sound device is 21 in case you need to modify the cfg

YES!!! I can also confirm operation... MT32-PI connected to Com1 with a serial to USB cable. THANK YOU!

elszgensa wrote on 2024-04-05, 09:04:

I do. Tbh I feels like this project has lost focus. Strip out networking to gain speed? Sure let's do that. (Fair enough, made sense at that time.) Add high res rendering which can only reasonably be used on faster machines? Alright. And let's remove cheat codes, just because. Emulate an entire sound card? Why not. Hey can we maybe have multiplayer back? Noooo, think of the poor low end machines... I've been thinking about whether I have the time to take all the enhancements, and only the enhancements, and move them into some kind of "Deluxe Doom", one that only builds up, never down (but while staying on DOS - otherwise one might just as well go with e.g. GZDoom).

Vanilla Doom didn't allow any cheats in Nightmare except two, IDCLEV and IDDT. And I think both were enabled due to mistakes in the coding, so that's why I removed them from Nightmare. Also I haven't said that I'll add a soundcard emulator, SBEMU support has already been fixed so no need to add it. All the features I've added work on 386 cpu's and doesn't make the game any slower (except obviously the newer higher resolution modes). Even with all new stuff the executable is smaller than vanilla.

Things could be done better? For sure. But again, this is open source and I code this on my free spare time, and same for other devs that have helped on the project.

New release!

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

Changelog:

* Serial MIDI support (fixed baudrate 38400, COM1 through COM4 selectable)
* Fixed 512x384 VESA modes

ViTi95 wrote on 2024-04-03, 18:30:

Definetely there is a bug in the DOS Extender, DPMI function 0800H. It fails if we try to map more than 8Mb. This issue also happens on other games, and it turns out that's why NOLFB program was created (NOLFB - Disables LFB enabling DOS games to fallback to VESA 1.2 modes). There are cards that limit the amount of VESA VRAM available on the VBIOS, for example both my Geforce 256 cards (32Mb) were working totally fine, as they limit the amount available to 4Mb. I guess that's why one VBIOS did work for you and the other didn't, one had to limit VESA and the other don't.

Is there any memory managers using V86 mode/VCPI interface active (such as EMM386 or JEMM)? Seems like you're running under one of these managers, and in that case, DOS extender runs with paging enabled. When DPMI fn 0x800 is called, the DOS extender needs to map physical memory in 4kb pages through page tables, and if there is not enough memory for these (each page table can map 1024*4096 = 4 MB), the mapping will fail.
Try re-running under clean environment (without any memory maganers or with XMS only present) and test if this issue reoccurs. IIRC there should be an option in the DOS extender, which sets count of page tables available for physical address mapping (at least PMODE/W can tweak this via PMSETUP.EXE, and I believe DOS32/A can do this too).

I remember having exactly this issue if WIn9x EMM386.EXE is loaded and >=512MB of RAM is installed, when neither PMODE/W nor DOS32/A can't map LFB of my card, making VESA modes fail.