ViTi95 wrote on 2021-07-04, 20:43:

2) Those images look very very good, can you share the source code of your implementation? I've been looking for an implementation that generates good results, but most of them require very fast CPUs.

https://www.upload.ee/files/13288525/vjkrogjf.zip.html

I will try the newest build on my U5S-SUPER33 system tonight 😀

Now, now, there's no call to be embarrassing all those DX2s 🤣

BitWrangler wrote on 2021-07-05, 17:48:

Now, now, there's no call to be embarrassing all those DX2s 🤣

I wish I had a SUPER40. I wonder if it is safe to OC mine to such. It is the only U5S I own though so I do not dare. It would probably reach DX2-66 speeds that way. The SUPER33 easily does DX2-50 speeds.

Tested mine at 50 a decade or so back, and it was outbenching my Pentium 60 on some things, gotta get my 486 60Mhz board back in fine fettle and try it in that (With huge heatsink)

I have 2 U5S 40mhz and noone of them work at 50 unlucky :\
I heard they were not overclockable at all

Yah, you have to work on one problem at a time, like stick a DX50 in the board, run with ISA i/o and vid with the ISA divider set low, and figure out if the chipset and RAM is even gonna be stable at 50, then when you've got that worked out, try adding your PCI or VLB graphics and test that at 50, then test i/o at 50, then test gfx and i/o together, THEN you can see if other CPUs will overlock to 50 on it. Takes a pile of patience and pile of alternate cards really.

Interesting phenomenon on U5S 33MHz and CL-GD5428, timedemo demo3 with no sound:

Ultimate Doom 6409 realticks
Fdoom 4843 realticks
Fdoom13h 5188 realticks

How come 13h is slower? Using latest stable binary on git.

Some systems are just faster in mode Y, it mainly depends on how fast are cache / RAM transfers. Also happens that Cirrus Logic cards work very similar in both modes, mainly because the card itself can't do 32-bit transfers (it transform internally to two 16-bit transfers), losing the 32-bit transfers advantage.

There is another possibility, maybe the U5S doesn't like REP MOVs instructions and are just slow on those processors (used to transfer the backbuffer to video memory). I've recently acquired one U5S 33MHz, will do some testing with it.

BTW, that U5S at 33MHz is faster than my ST486DX2-80GS 🤯🤯🤯🤯

Interesting, I will replace the GD5428 with an F64300 and retest next week! Looking forward to your tests as well.

Yes U5S is a beast. I so want a 40MHz version..

I've tested my U5SX 33MHz, definitely is such a beast! I've been able to overclock it to 50MHz without problems.

https://youtu.be/qI6qR2uWETU

I see you ran fdoomvbr? Is this the vesa version? I don't think that VLB card has VBE 2.0 though?

Oh wait you have UNIVBE in Autoexec. That explains it. I'll try my U5S with UNIVBE this weekend as well 😀 I will then do a head to head benchmark between CL-GD5428 and CHIPS F64300 in vanilla, fast, 13h and vbr modes.

Yes, fdoomvbr is the standard VBE2 executable. The Trident TGUI9440AGi doesn't support VBE2 but UniVBE enables it and extra video modes, which are required to run properly. This mode is the fastest with this video card, as it uses the LFB and the full 32-bit bus of the VLB. Your F64300 should perform well on VBE2 modes.

I recommend to use SciTech Display Doctor 5.3a, for me it's a little bit more stable and uses less resources.

ViTi95 wrote on 2021-07-08, 07:10:

Yes, fdoomvbr is the standard VBE2 executable. The Trident TGUI9440AGi doesn't support VBE2 but UniVBE enables it and extra video modes, which are required to run properly. This mode is the fastest with this video card, as it uses the LFB and the full 32-bit bus of the VLB. Your F64300 should perform well on VBE2 modes.

I recommend to use SciTech Display Doctor 5.3a, for me it's a little bit more stable and uses less resources.

I'll do that this weekend.

On a related note; I found both Windows and DOS versions of SDD 5.3a. I was wondering if the Windows drivers are worth installing? I also found F64300's own Windows 3.1 drivers and was going to install this.

I have 1 bug resolved I want to report: The menu crashes I had were indeed due to my overclock being unstable and have now been resolved, so I closed the bug report on github.

With that out of the way here are some interesting results from my 5x86-100 with a Riva128 PCI:

Benchmark with -nosound -timedemo demo3 results:
-Ultimate Doom 3937 realticks
-Fdoom 2539 realticks
-Fdoomvbr 2239 realticks
-Fdoom13h 1817 realticks

I've seen VBE do some amazing things for some CPUs earlier on in this thread but for a 5x86 (or a Riva128, which has VBE3.0) it seems to help marginally. 13h is still faster but has tearing, so I stick with VBR for now.

That said, I have 3 questions I wanted to ask:

1. When using General Midi/Sound Canvas options in Fdsetup, Music volume is low. Like, very low. It's much lower than what regular Doom has. Is this intentional, and can it be fixed?
2. I put Fdoom in the same folder as Ultimate Doom but when I try to start a new game I do not see Episode 4 (Thy Flesh Consumed) as an option. Why?
3. If I put Fdoom in the same folder as Doom 2, will it automatically launch that? Is there a way to have both Ultimate Doom and Doom 2 in the same folder as Fdoom and maybe a command line switch or a startup menu for which wad to load or something? I can probably do this as a batch file menu, but just asking before I put in the effort.

1- I'll look into it, i'm pretty sure that's a bug.
2&3- FastDoom 0.8 onwards can select between multiple wads located in the executable folder, and there is a small change for the Ultimate Doom WAD (now it's called doomu.wad). The supported wads are the following:

• DOOM.WAD -> DOOM Registered (3 episodes)
• DOOM1.WAD -> DOOM Shareware (1 episode)
• DOOMU.WAD -> Ultimate DOOM (4 episodes)
• DOOM2.WAD -> DOOM II
• PLUTONIA.WAD -> Final DOOM The Plutonia Experiment
• TNT.WAD -> Final DOOM TNT Evilution

This way you can use FastDoom as a standalone port, without requiring anything from Vanilla Doom (except the WADs, obviously).

Do you have plans to support Romero’s sigil.wad?
https://romero.com/

ViTi95 wrote on 2021-05-24, 20:17:

SIGIL support is in the to-do list, the problem adding SIGIL support is that it requires uprising some vanilla doom limits, and that makes the executable use more ram memory.

I see, thanks!

New release! FastDoom 0.8.5

Just a few new video modes:

• FDOOMVBD.EXE => FastDoom for VBE 2.0 cards with LFB (triple buffered)
• FDOOMT1.EXE => FastDoom 40x25 16 colors text mode
• FDOOMT12.EXE => FastDoom 40x25 16 colors text mode (virtual resolution of 40x50)

The new video mode for is meant for VBE 2.0 cards with LFB enabled. This mode is better for slow 486 processors (20~33 MHz) with slow RAM or limited available cache, i've tested it to be between 1 and 2 fps faster than the normal VBE 2.0 mode (backbuffer) on a 486SX at 25 MHz with a Cirrus Logic GD-5426 VLB. It works very similar to the Mode Y, it renders directly onto the video card, and it's page flipped so it doesn't suffer from vertical retrace problems. Fast systems are usually slower in this mode.

The last two ones are more kind of a joke, since it's practically impossible to play with such a low resolution. But well they make the game at least playable with very slow 386SX processors (16~20 MHz) and solves the IBM CGA snow problem. The funny thing is that those modes would run decent even on a 286 processor.

https://www.youtube.com/watch?v=5j6Dn-UVQgY

Also forgot to mention that I released before the 0.8.4 version with the new PC Speaker mode and the COVOX support.

Edit: Do exist any ISA video card that supports LFB? The only card I have that is supposed to support it is a Cirrus Logic GD-5429, but UniVBE doesn't enable it at all (even with less than 16Mb of RAM). The same motherboard works fine with a GD-5426 and LFB enabled. Maybe someone here can try this new mode with a compatible ISA one.