Still haven't found what makes the OPL music volume low, I've checked that the volume levels get into the Apogee Sound System library fine, but haven't found yet how the library uses that volume with OPL data.
New release: 0.9.6
* Add executable filename to benchmark (CSV)
* Fix wrong fps display if 0XX after decimal point (@RamonUnch #145)
* New invisible column renderer: Flat Sega Saturn (@RamonUnch idea)
* Small code optimizations
* Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0)
ViTi95 wrote on 2023-05-13, 18:34:New release: 0.9.6 […]
New release: 0.9.6
* Add executable filename to benchmark (CSV)
* Fix wrong fps display if 0XX after decimal point (@RamonUnch #145)
* New invisible column renderer: Flat Sega Saturn (@RamonUnch idea)
* Small code optimizations
* Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0)
Thank a lot! i just was reading the thread
I will test as soon i can
I have a question, i was testing PCM music, i make 8bit, 44khz, mono PCM , select 44khz pcm.in setup,and sound fine, but quality is not good, like too much noise. But same wav in a wave player sound much better
tested fastdoom pcm in two computers, DX266 and pentium 2 333, both awe64, same problem
any tips?
Probably is an audio convert issue. I use sox to convert the audio files, for example:
sox D_E1M1.ogg -r 44100 -e unsigned -b 8 -c 1 MUS_1.RAW
I've uploaded the script I used to convert IDKFA album to PCM music: https://github.com/viti95/FastDoom/blob/maste … vert/convert.sh
ViTi95 wrote on 2023-05-14, 09:33:Probably is an audio convert issue. I use sox to convert the audio files, for example: […]
Probably is an audio convert issue. I use sox to convert the audio files, for example:
sox D_E1M1.ogg -r 44100 -e unsigned -b 8 -c 1 MUS_1.RAWI've uploaded the script I used to convert IDKFA album to PCM music: https://github.com/viti95/FastDoom/blob/maste … vert/convert.sh
Hi!!! sorry delay to answer!!!
I came here to say THANK YOU! one of my dreams came true, doom in DOS with music and sound in my old Toshiba T2130CS
This nice 640x480, DX4/75mhz 486 dont have any sound card, of course i can use a pcmcia sound, external opl or serial midi, but my dream was just using pcspeaker or a home made covox in real DOS (not a port in windows/linux)
Performance is amazing
TIMEDEMO3 without sound = 30.96
TIMEDEMO3 covox PCM+FX sound 11khz = 25.08
TIMEDEMO3 pcspeaker 1bit+11khz PCM+FX sound = 24.56
WOW!!!
Now using fastdoom i can enjoy my toshiba again, thanks man!!!! i upload a youtube video, covox sound amazing, pcspeaker more or less tolerable, maybe is possible to make pcs sound better?
I have a question, a 320x240 mode, with hub on bottom do you think is possible? jaja, to fill toshiba screen and 60hz will be perfect for lcd 😀
Yeah PC Speaker it's not that great, don't know if there is any way to make it sound better (both PWM and 1-bit modes). I'm not that good at sound programming, it still gives me lot's of headaches. For now I'm focusing on performance improvements, next release will have multiple codepaths for some architectures (386SX, 386DX, Intel 486, Cyrix 486, UMC Green 486...) which will increase framerate a bit depending on each CPU, plus more optimizations for all architectures.
The 320x240 idea is good, my Toshiba has the same issue. The aspect ratio won't be right, but at least it will be fullscreen on those devices. I'll try to implement it.
ViTi95 wrote on 2023-05-13, 18:34:* Sound Blaster MIDI support (for Sound Blaster 1.0, 1.5, 2.0, Pro 1.0 and Pro 2.0)
Thanks for this! It was always mildly annoying in the 1990s that there was essentially no support for SBMIDI in games (not that it mattered much, I didn't own an external General MIDI device until 2008 or so).
I was under the impression that the MIDI DSP commands couldn't be used while DMA-mode PCM audio was playing (I'm not sure where I got that from)... maybe this is true of earlier DSP versions, but both are working perfectly fine at the same time on an SBPro2 (CT1600, DSP version 3.xx).
On the other hand, attempting to use both SBMIDI and Direct Mode PCM freezes my system right after S_Init...
Ooops forgot to try the SB Direct mode + SB Midi, I'll take a look. Don't know if it will work though, both devices use the DSP so maybe they are conflicting.
BTW it would be great if someone try the new SB Midi support with older cards, as I only have SB16 cards and I had to emulate on 86Box the rest
ViTi95 wrote on 2023-05-25, 06:43:Ooops forgot to try the SB Direct mode + SB Midi, I'll take a look. Don't know if it will work though, both devices use the DSP so maybe they are conflicting.
BTW it would be great if someone try the new SB Midi support with older cards, as I only have SB16 cards and I had to emulate on 86Box the rest
I have a SBpro and and MT32/SC88/SC55
I will try as soon i can
Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now.
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU. The available command lines are:
So any benchmark with these options is welcome as I'm tuning each architecture.
ViTi95 wrote on 2023-05-25, 15:09:Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now. […]
Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now.
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU. The available command lines are:
- -umc486
- -intel486
- -cyrix486
- -386dx
- -386sx
- -cyrix5x86
- -k5
- -pentium
So any benchmark with these options is welcome as I'm tuning each architecture.
How do you need the test to be done?
Without and with switch to check the performance difference?
I can take care of testing the 486 cpus.
ViTi95 wrote on 2023-05-25, 15:09:BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU. The available command lines are:
Fantastic! Is this automatically detecting CPU and only being overridden by command line? or runs generic path unless manually selected?
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module for AT&T Globalyst
https://github.com/raszpl/386RC-16 memory board
https://github.com/raszpl/440BX Reference Design adapted to Kicad
https://github.com/raszpl/Zenith_ZBIOS MFM-300 Monitor
For now you have to select it manually, don't know if i'll add autodetection.
@Nemo1985 try multiple architectures for each single type of CPU with a single benchmark:
fdoom -timedemo demo3 -umc486 (-386sx, -intel486... and so on)
The idea is to find the best path for each architecture so I can optimize even further. Changing between types of CPU is kinda shitty with 486 cpu's, everytime I have to change lots of jumpers. Also I still have to make Ken Silverman's ideas to work (https://github.com/viti95/FastDoom/issues/143), so any help with this would be awesome.
EDIT: Base path will be Intel 486, it will work on any architecture properly
ViTi95 wrote on 2023-05-25, 18:26:Also I still have to make Ken Silverman's ideas to work (https://github.com/viti95/FastDoom/issues/143), so any help with this would be awesome.
>Do aligned 32-bit writes to video memory. Easy for ceilings. Yes it's possible for walls (which are rendered in the vertical direction) too! The trick is: you render 4 vertical wall lines simultaneously.
hey, thats My idea!!1 Re: FastDoom. A new Doom port for DOS, optimized to be as fast as possible for 386/486 personal computers! and only 30 years later 😁
What about other side of the engine, how much is spend traversing bsp tree?
https://probablydance.com/2023/04/27/beautifu … -binary-search/ https://orlp.net/blog/bitwise-binary-search/ might be worth investigating new algorithms there.
https://github.com/raszpl/FIC-486-GAC-2-Cache-Module for AT&T Globalyst
https://github.com/raszpl/386RC-16 memory board
https://github.com/raszpl/440BX Reference Design adapted to Kicad
https://github.com/raszpl/Zenith_ZBIOS MFM-300 Monitor
ViTi95 wrote on 2023-05-25, 15:09:Please @CODOR try this bugfix executable, I've tried it on my SB16 and it works now.
It works on my SBPro2, thanks!
BTW this executable includes a new configurable option, now it's possible to use render code for each CPU architecture. This allows for more performance on the selected CPU.
This also interests me as this machine happens to have a Cyrix 486DLC.
Tested system: 486DLC@33MHz, 8MB RAM, MS-DOS 6.22, Trident TVGA9000i, SBPro2 CT1600
fdoom.exe (from supplied fdoomtest.zip), doomu.wad, demo1 (1710 gametics), size 10, using DMA-mode SB and SBMIDI
The following are with HIMEM and EMM386 running:
-cyrix486 wins at low detail but loses at potato and is 1 realtic away from the bottom at high (it ties or comes close to -386sx each time). The results seem odd to me so to rule out EMM386 I tried it again with only HIMEM (too lazy to try all the tests, just the default renderers and -cyrix486):
These are so close that I'm wondering if I remembered to type -cyrix486 in 😜
I probably won't have a chance to try again until after the weekend but I can build it from source and will test fdoom13h.exe then, too.
Here are the tests with 486, I used the very same pc of last time(MB: Biostar MB-8433UUD-rev2, 256kb cache, 32mb, s3 virge dx 4mb) results in realticks (lower score more fps), used the switch as following fdoom -timedemo demo3 -*cpuswitch*:
I still don't understand why the intel 486 dx4 cpu performs better than amd and cyrix (100 mhz), they shouldn't be the very same? At least with amd 486?
Also are you willing to write a data path for the amd 5x86? It's always the faster 486 fake cpu, it surely deserve it more than cyrix 5x86.
If anyone is willing to do the tests with 386 and socket 7 cpu it would be nice otherwise I will be able to do them too.
Do you need to be tested just the Pentium and k5? No k6 or some weird cpu like mp6?
As for 386 I just have those cpus:
Intel i386 A80386DX-33 IV ΣΣ version
Amd Am386 DX/DXL 40
TI TX486DLC/E-40GA
Could you please add the render code used in the benchmark result screen, just to be sure I used the right switch. Thanks.
PS: On my previous round up vs vanilla doom I used the 13h version if it matters.
Intel doubled the L1 cache when they launched the DX4 chips. AMD (and I assume Cyrix as well) did not AFAIK, it was only with the 5x86 that the cache was doubled, which should explain the performance discrepancy.
Garrett W wrote on 2023-05-26, 07:16:Intel doubled the L1 cache when they launched the DX4 chips. AMD (and I assume Cyrix as well) did not AFAIK, it was only with the 5x86 that the cache was doubled, which should explain the performance discrepancy.
I didn't know. So we have Amd and Intel with the very same architecture but different cache amount and then Cyrix with a different architecture and cache, is that right?
The Cyrix 486 architecture is a little worse compared to the Intel 486, there are multiple instructions that are slower, that's why is usually slower. And the difference between Intel and AMD 486 comes when AMD had to remove the ICE code, I've seen slower performance on those "N" cpu's. Also the 8kb vs 16kb L1 cache makes a difference, but even with the same amount of cache the AMD is a little slower.
One question, are you executing the benchmarks with sound/music enabled? I've discovered that enabling sound makes the benchmark results a bit unstable, if possible execute the with sound and music disabled.
Nemo1985 wrote on 2023-05-26, 04:23:Also are you willing to write a data path for the amd 5x86? It's always the faster 486 fake cpu, it surely deserve it more than cyrix 5x86.
The AMD 5x86 is basically an AMD 486 with higher clock and 16Kb of L1 cache, so no need to create a different codepath for it.
ViTi95 wrote on 2023-05-26, 07:48:The Cyrix 486 architecture is a little worse compared to the Intel 486, there are multiple instructions that are slower, that's […]
The Cyrix 486 architecture is a little worse compared to the Intel 486, there are multiple instructions that are slower, that's why is usually slower. And the difference between Intel and AMD 486 comes when AMD had to remove the ICE code, I've seen slower performance on those "N" cpu's. Also the 8kb vs 16kb L1 cache makes a difference, but even with the same amount of cache the AMD is a little slower.
One question, are you executing the benchmarks with sound/music enabled? I've discovered that enabling sound makes the benchmark results a bit unstable, if possible execute the with sound and music disabled.
Nemo1985 wrote on 2023-05-26, 04:23:Also are you willing to write a data path for the amd 5x86? It's always the faster 486 fake cpu, it surely deserve it more than cyrix 5x86.
The AMD 5x86 is basically an AMD 486 with higher clock and 16Kb of L1 cache, so no need to create a different codepath for it.
I used the switch you pasted before some messages ago. There is no sound card installed. The sound and music then should be disabled I guess?
