Don't worry about that modebw.wad message, B&W modes try to load it automatically. If someone create a PLAYPAL/COLORMAP better fitted for those modes, just add them to file modebw.wad and it will load automatically.

@ujav What monitor and video card are you exactly using? I'll create add an issue to the project and try to fix that bug. None of my Hercules cards have problems with the 640x400 mode, and all of them are tested on an IBM 5151. And yeah the FDSetup program doesn't work right now with Hercules/MDA cards, it's a known bug that has to be fixed. I don't know if i'll be able to, because the setup screens are prebuilt with the Laughing Dog Screen Maker tool and designed for 80x25 and 16 color modes.

@0x90 I'll test the PR as soon as possible, huge thanks for the effort!!

@xcomcmdr the original 32x port had access to the original source code while the SNES port no, I guess if Randy Linden had access to that source code the port could have been much more similar to the DOS version

I just started programming a new FDSETUP from scratch which will be buildable using 16-bit Open Watcom, and which will just draw everything on the fly instead of using predefined data from object files generated byLaughing Dog, with support for both colour and monochrome text mode. We'll see if it goes anywhere anytime soon. 😜

Or should I rather use 32-bit Watcom with #ifdefs for DJGPP compatibility? Hmm... It'll bloat the setup program a bit but shouldn't matter much otherwise, and it would allow building everything using DJGPP only if and when FastDoom itself becomes DJGPP compatible.

Just tested and merged the PR, everything is working fine!

I guess it's better to make the FDSETUP program a 32-bit executable (Doom won't run on 16-bit real mode, so there's no need for 286 or 8086 support), and have the possibility to build it with either DJGPP or Watcom. The main idea is to be able to build the whole project with DJGPP, as it has better support and GCC is a much better compiler.

ViTi95 wrote on 2021-12-22, 08:16:

@ujav What monitor and video card are you exactly using? I'll create add an issue to the project and try to fix that bug. None of my Hercules cards have problems with the 640x400 mode, and all of them are tested on an IBM 5151.

Card is Tidalwave TM6310
Like this but older revision with a pass-thru components instead of SMD http://www.vgamuseum.info/index.php/cpu/item/ … idalwave-tm6310

Monitor is a late Hercules with 16 shades of amber ability, works even with EGA. So I think it's just this card, not capable of 400 lines and displaying weird 350 ones instead.

By the way, dithered Doom is running pretty well on this 8-bit card even on Pentium-120, so I guess there is still room for 720x350 mode. Like, doubling every 8th pixel horizontally, and removing every 7th scanline, for example.

Hi,
Does mode 80x50 have no mistake here? textdestscreen += 4128;

1#if defined(MODE_T8050) || defined(MODE_T80100)
2    // Change video page
3    regs.h.ah = 0x05;
4    regs.h.al = textpage;
5    regs.h.bh = 0x00;
6    regs.h.bl = 0x00;
7    int386(0x10, &regs, &regs);
8
9    textdestscreen += 4096; //4128
10    textpage++;
11    if (textpage == 3)
12    {
13        textdestscreen = (unsigned short *)0xB8000;
14        textpage = 0;
15    }

That line of code gave me lot's of headache. The theory is that each video page uses 4096 bytes, but using that displacement the screen flickers like crazy. I had to guess that value by trial and error, and it works on almost every VGA card i've tested. Don't know exactly why it works. The only videocard that doesn't work correctly in 80x50 or 80x100 mode is the Cyrix MediaGX integrated one.

¯\_(ツ)_/¯

Yeah, latest fdoomt50.exe(and 52 too) flickers like crazy in DosBox, in every build and fork I tested.
But since it's working fine on almost every real video card, not a big deal I guess?

ujav wrote on 2022-01-01, 17:58:

Yeah, latest fdoomt50.exe(and 52 too) flickers like crazy in DosBox, in every build and fork I tested.
But since it's working fine on almost every real video card, not a big deal I guess?

Interestingly, there's no such issue in DosBox-X.

Speaking about 'real' video cards, fdoom50 / 52 are also not working properly on a Voodoo3.

In my testings DosBox flickers when the video card is an EGA. This is due to EGA cards not supporting the 80x50 mode, those can only address 80x43 characters (the plane size is smaller, happens on both DosBox and real cards)

I'll try if setting the plane size to 4096 fixes the problem with the Voodoo's and the Cyrix MediaGX.

Small update: I've just discovered what made text mode 80x50 (and 80x100) screen flicker on some video cards. Older video cards use 8256 bytes per video page on 80x50 mode, while some new video cards use 8000 bytes per video page. For example:

- 8000 bytes/page: Voodoo Banshee and later cards, Nvidia Riva TNT2, Cyrix MediaGX
- 8256 bytes/page: Cirrus Logic GD-542x, Trident Paradise PVGA1A, Oti 087x, Matrox Millenium II, Alliance Semiconductor AT25

Will add a command line to fix this issue for newer cards. Still don't know why the video pages on the old cards use extra 256 bytes for padding.

I have been making some progress on the new setup utility. (finally)

I'm also having some real trouble with the attribute bits in monochrome text mode though. Conflicting and confusing information and tables about these can found on the web. In addition, PCem set to emulate a MDA or Hercules card and DOSBox with machine=hercules don't even seem to treat all settings the same. No real hardware to test on unfortunately.

Am I even supposed to be able to have both reverse text with a bold (high intensity) background, and reverse text with a regular (dim) background on the screen at the same time somehow? I have disabled hardware blinking of course. Seems in PCem reversed text ALWAYS has a bright background, while in DOSBox it never has, then eg. 0x78 / 0xF8 is reversed in PCem vs. DOSBox and underlining is different too... does either emulated behaviour even match real hardware?

If people with real monochrome video cards want to run this little program I've attached and take some GOOD photos of their monitors, that could be helpful. (DO NOT run it if using a colour card, especially if you've set up UMBs at 0xB000)

Also, is there a better way to autodetect whether a mono or colour card is present than just attempt to set the text mode cursor position and then read it back via certain I/O ports which are different between mono and color cards? (this is the method Open Watcom's graphlib uses)

I'll try it on my Hercules cards when my vacation finish. In my testings PCem is much more accurate than DosBox, DosBox-X is a little bit better but again less accurate than PCem.

Have few questions regarding benchmarking via fastdoom. I have quite a lot of pre vga cards and no way how to compare their speed except diag software. So this is nice chance to fill missing gaps in my benchmarks.
Probably will do ega and older cards on my Intel 486DX4-100, Asus PVI-486SP3 (ISA/VLB/PCI). And all cards till agp but not at once on my Athlon XP setup (ISA/PCI/AGP). But before i start need confirmation that i have everything set right. Will be unlucky to hear that i should switched something after testing many cards....
Using doom2.wad version 1.9. No sound card.

1)My bat file looks like this... something else to add?

1fdoom.exe -ram -logtimedemo -forcehq -novsync -timedemo demo1

2)My config file - something to change? Not sure what to choose at various options in game like Sprite Culling, Invisible rendering, Melting load effects etc to make game look as close as possible to original. Looking for benchmark comparsion, not fastest speed possible on slow cpus.

1mouse_sensitivity		5
2sfx_volume		8
3music_volume		8
4show_messages		1
5key_right		77
6key_left		75
7key_up		72
8key_down		80
9key_strafeleft		51
10key_straferight		52
11key_fire		29
12key_use		57
13key_strafe		56
14key_speed		54
15use_mouse		1
16mouseb_fire		0
17mouseb_strafe		1
18mouseb_forward		2
19screenblocks		12
20detaillevel		0
21showfps		1
22uncapped		1
23flatsky		0
24near		0
25nomelt		0
26flatShadows		0
27saturnShadows		0
28untexturedSurfaces		0
29flatSurfaces		0
30vsync		0
31autorun		65536
32monosound		0
33snd_channels		3
34snd_musicdevice		0
35snd_sfxdevice		0
36snd_sbport		544
37snd_sbirq		5
38snd_sbdma		1
39snd_mport		816
40usegamma		0

3)which executives to use on various cards. did quick test on athlon xp and trio3D and found out some numbers. So far thinking about using - correct me pls if something wrong.
FDOOM.EXE - isa/vlb cards without vesa 2.0 - or rather use FDOOM13H.EXE?
FDOOMVBR.EXE - PCI/AGP cards with vesa 2.0
FDOOMVBD.EXE (triple buffered) - didnt worked with with trio3d - its for fast 3D cards like Voodoo 3????
FDOOMEGA.EXE - 320x200 16 color EGA - EGA cards?
FDOOMCGA.EXE - 320x200 4 color CGA - CGA?
FDOOMHGC.EXE - 640x400 monochrome Hercules - Hercules?
Want to test resolutions most similar to these used in games at its times. Just to see if some hercules cards were faster than others and same for egas....

There might be some surprisingly fast Hercules cards around... reason being that hercules/MDA remained a "thing" for retail terminals, travel agents, banking until the millennium. Though I guess most of the hardware would have been last made by mid 90s and just continued in service. Still, this means that there are herc/mono compatible cards around, single chip with relatively fast RAM, because that's the RAM that was "low end" when they last made them in the 90s. Though the performance wouldn't have been super well tuned in most instances, because the favored monitors to use with them would have been long persistence to reduce flicker. Anyway, had one of these "late" cards somewhere I was using in X windows in the early noughties (VGA monitors still expensive at the time) hopefully it will turn up sometime.

vlask wrote on 2022-01-22, 15:21:

...

1) The forceXX commands are case sensitive, so it's more correct to use "-forceHQ". Everything else is fine.

EDIT: "-logTimedemo" is also case sensitive

2) Default configuration is the best one, as close as posible to the original Doom. Just remove the .cfg and let the game create one (or use fdsetup program to create one)
3) There is a major thing to consider when selecting the executable to use. There are two ways to render the scene to the screen, one is directly onto the video card VRAM (direct render), and the other is using a backbuffer in RAM and then copy each frame from the backbuffer to the VRAM (backbuffer render). Each method has it's own advantages and disadvantages. With fast cpu's and ram, the second method is way faster than the first one, as the ISA/VESA bus usally bottlenecks the render process.

• Direct render executables:
  • FDOOM.EXE - This is exactly the same as Vanilla DOOM, triple buffered Mode Y
  • FDOOMVBD.EXE - This mode is designed for VESA 2.0 cards with Linear Frame Buffer (LFB) support. Most VLB cards are faster with this mode compared to FDOOM.EXE if supported (usually with UniVBE 5.3), but with fast cpu's/ram it's usually slower than FDOOMVBR.EXE

• Backbuffer render executables:
  • FDOOM13H.EXE - This mode achieves the maximum transfer speed for VGA modes with a fast cpu/ram combination. Most ISA cards are way faster with this mode (even more than 35 fps)
  • FDOOMVBR.EXE - Same as mode 13h, but for VESA 2.0 cards (LFB not required, some video cards are waaaay faster in this mode, for example the Rendition Verite or the Cyrix MediaGX)
  • FDOOMEGA.EXE - Converts the backbuffer to EGA 320x200 and 16 colors (mode D). Valid to benchmark EGA cards (fast cpu required). The backbuffer to VRAM copy is not optimized, it always copy the full backbuffer to the VRAM
  • FDOOMCGA.EXE - Converts the backbuffer to CGA 320x200 and 4 colors (mode 4). Valid to benchmark CGA cards (also fast cpu required). Has the same unoptimized method to copy from backbuffer to the VRAM
  • FDOOMHGC.EXE - Converts the backbuffer to Hercules 640x400 monochrome (non standard Hercules mode, very fast cpu required). Valid to benchmark some Hercules cards, may not work on some clone cards. The backbuffer to VRAM copy is also not optimized

New release! FastDoom 0.8.9 https://github.com/viti95/FastDoom/releases/tag/0.8.9

Changelog:

• Added new video modes. Huge thanks to @Frenkel (DoomWorld) !!
  • FDOOMC36.EXE => FastDoom CGA 80x100 (122 pseudocolors)
  • FDOOMV36.EXE => FastDoom VGA 80x200 (122 pseudocolors)
  • FDOOMATI.EXE => FastDoom ATI Small Wonder 640x200 (dithering 16 colors)
• Small optimization for Potato and Low detail column rendering
• Optimized Plantronics ColorPlus, EGA, CGA and Hercules modes
• Added custom palette for VGA 160x200 mode
• Optimized CGA 160x100 and VGA 160x200 rendering
• Remove FDOOMVBP.EXE. It was very buggy and problematic, and in 99% of the cases a little bit slower than FDOOMVBR.EXE
• Converted all ASM files to NASM. This allows to build FastDoom with 100% open source compilers. Borland Turbo Assembler requirement is now gone. Huge thanks to @0x90
• Fix screen flickering on 80x50 and 80x100 text modes. Use the parameter "-pagefix" in case it flickers
• New mode for PC Speakers. Based on the PWM method, a little bit better but uses more CPU

Ok, anyone have some numbers from EGA cards? Just tested few ones and seems to me, that they have limit around 13FPS. Guess its limit of 8bit ISA, but i'm not sure as im using quite late board (Via KT133A, Athlon XP) ...not sure about quality of implementation of ISA bus. View size seems to have very limited effect, so i'm testing at full view.... Anyone got more from their system?
13,048 FPS - Ati EGA Wonder 480 16899 256kB ISA8b 1987
8,304 FPS - Ati EGA Wonder 800+ 18800-1 256kB ISA 1989
13,077 FPS - Chips P82C435 256kB EGA ISA8b 1987
12,275 FPS - PC Chips G3101 256kB ISA8b 1986

I've tested a Paradise PEGA-1A (ISA 8-bit), and it won't get more than 13.3 fps on an AMD K6-2 550. EGA cards are usually very very slow, so I guess it's a normal result. Launching the same benchmark, on a Paradise PVGA-1A (also ISA 8-bit, same EGA mode) gets better result, about 26 fps.

Reducing the view size does almost nothing as of now, since the whole backbuffer is copied to the VRAM (yeah it still needs some optimization).

EDIT: Maybe the culprit on the EGA being slow is the method I use to change between video pages, right now I'm using the BIOS method. I guess I'll have to try changing the pages directly on hardware.
EDIT 2: Nah, tested to change the video pages directly without a BIOS call, and the result was pretty much the same. The culprit must be somewhere else.
EDIT 3: From another thread (EGA DOS benchmarks?) I think I know why VGA cards are faster than EGA cards in the same mode:

The original EGA chipset from IBM (along with the first clone EGA chipset from Chips & Technologies) clocks the video RAM at the dot clock frequency, which is 14.318Mhz for the 320x200 and 640x200 modes. The chipset sequencer coordinates the CRT and CPU accesses to video RAM. Over the course of 32 clock cycles the sequencer provides 5 opportunities to access the video RAM. The CRT needs 2 out of 5 accesses in 320 pixel modes and 4 out of 5 accesses in 640 pixel modes. When the CPU wants to read/write to video RAM, the video chipset inserts wait states until an access opportunity becomes available. (This will be quite a few wait states in the 640 pixel modes!)

So I think on these early EGA cards, the video RAM would actually be *faster* in 640x350 mode (since it uses a 16.257Mhz clock) as compared to 640x200 mode (which is using the standard 14.318Mhz clock). There's a "bandwidth" bit in the SR01 register that determines whether the CPU gets 1 access or 3 accesses during each 32 cycle group. I wonder what happens if you program the sequencer to give the CPU 3 accesses in a 640 pixel mode (which should starve the CRT of its required accesses). It might be safe to do so during the vertical blanking, providing a brief window of high performance access to the video RAM...

Anyhow, at some point the video chipsets began to incorporate a FIFO buffer, so that the CPU writes into the buffer and can be released immediately without any wait states, and also switched to clocking the video RAM with a faster clock that was decoupled from the video dot clock. Did any EGA chipsets use these techniques? The early VGA chipsets used essentially the same design as the original EGA, adding a whole bunch of wait states to synchronize the CPU writes with the gaps in the CRT reads.

The Paradise PVGA-1A has a high performance FIFO buffer (extracted info from the datasheet), while the Paradise PEGA-1A no, that's why the PVGA is nearly 2x times faster than PEGA

ViTi95 wrote on 2022-01-30, 23:15:

I've tested a Paradise PEGA-1A (ISA 8-bit), and it won't get more than 13.3 fps on an AMD K6-2 550. EGA cards are usually very very slow, so I guess it's a normal result. Launching the same benchmark, on a Paradise PVGA-1A (also ISA 8-bit, same EGA mode) gets better result, about 26 fps.

ok tested some few more cards...
15,374 - PVGA1A-JK 256kB 8bit ISA - VGA mode 13h, 11,093FPS in plain vga mode.
23,15 - PVGA1A-JK 256kB 8bit ISA - EGA mode
13,243 - Gemini VC-001 256kB 8bit ISA - EGA mode
13,198 - Citygate D10 ?kB ISA8b - EGA mode
26,254 - Paradise Systems PVC2 ISA8b 64kB - CGA mode

So yes, most EGA cards ends at 13FPS, but with better vga chip 23FPS can be archieved in EGA mode even on 8bit bus. Vga mode seems to be much slower, but still faster than EGA cards.
CGA mode seems to be very fast, compared to EGA. Still have to test Hercules modes, once i end with EGA cards....

These results seem normal to me, the ISA 8-bit bus is very slow, in my testings it can't do more than 1Mb/s. All comes down to how much data is transfered via the bus, that's why CGA is faster than EGA, and EGA faster than VGA:

• Hercules: 640x400, 1 bit per color, 8 pixels per byte written: 31,25kb per frame
• CGA: 320x200, 2 bits per color, 4 pixels per byte written: 15,625kb per frame
• EGA: 320x200, 4 bits per color (separated in 4 planes), 2 pixels per byte written: 31,25kb per frame
• Plantronics ColorPlus: 320x200, 4 bits per color, 2 pixels per byte written: 31,25kb per frame
• VGA high: 320x200, 8 bits per color, 1 pixel per byte written: 62,5kb per frame
• VGA low: 320x200, 8 bits per color, 2 pixels per byte written: 31,25kb per frame
• VGA potato: 320x200, 8 bits per color, 4 pixels per byte written: 15,625Kb per frame

There is also overhead on Hercules, CGA, EGA and Plantronics modes due to conversion routines from 256 colors and memory format for each mode. There's also overhead in VGA Mode Y modes, as the sprites and text messages overlap the rendered scene, and it requires to change planes for each column drawn. That's why VGA mode 13h is faster than VGA mode Y on fast processors. Yet there are optimizations to be made on those modes.

Also, can you test Plantronics mode on the PVC2 card? There aren't much Plantronics cards out there, so any testing is welcome.