ViTi95 wrote on 2022-11-18, 19:46:

I'm still looking for a way to dynamically link code on runtime

dudes (neozeed?) who ported Quake 2 to dos made it work http://dk.toastednet.org/Q2DOS/ https://bitbucket.org/neozeed/q2dos/src/master/
something about .dxe DJGPP DLL like mechanism for dos, but later they managed to work with ordinary openwatcom? .ovl files (glide)
I remember reading whole blog update about that, but cant find it anymore 🙁 I did find this mentioning it https://www.bttr-software.de/forum/mix_entry.php?id=16158
edit: found 5 entries blog series mentioning it https://virtuallyfun.com/2015/06/02/porting-q … -to-ms-dos-pt1/

Yeah Watcom at least USED to have dynamic linker support, but I think it only works with certain DOS extenders (maybe not DOS/32A)

theelf wrote on 2022-11-21, 14:49:

One think will be amazing, i dont know how difficult will be to implement is AudioCD. If i dont remember bad, Ultimate Doom soundtrack is something like 50-55min longer and Doom 2 70-75, perfect to fit in a cdrom

Mmmm interesting idea, I've never worked with the MSCDEX but will take a look into it. Is there any Doom port that already implements this?

rasteri wrote on 2022-11-21, 22:50:

Yeah Watcom at least USED to have dynamic linker support, but I think it only works with certain DOS extenders (maybe not DOS/32A)

Is there any tutorial or example on how to develop this? I think this will be extremely helpful reducing the number of executables (and executable size)

ViTi95 wrote on 2022-11-23, 07:38:

theelf wrote on 2022-11-21, 14:49:

One think will be amazing, i dont know how difficult will be to implement is AudioCD. If i dont remember bad, Ultimate Doom soundtrack is something like 50-55min longer and Doom 2 70-75, perfect to fit in a cdrom

Mmmm interesting idea, I've never worked with the MSCDEX but will take a look into it. Is there any Doom port that already implements this?

Hi, thanks

Yes, DosDoom 0.653 support audiocd and is AMAZING, plus, i get some extra fps compared to opl music, at least in dosdoom benchmarks, and i think this is the goal of fastdoom too

The problem of dosdoom is that you need to manually change the tracks, the idea will be that fastdoom have hardcoded track numbers for every level (e1m1-track1, e1m2-track2, etc) and detect audio cd finish to start track again

http://www.doomworld.com/3ddownloads/ports/dd0653b.zip

source

https://www.doomworld.com/idgames/historic/dd0653

thanks!

ViTi95 wrote on 2022-11-23, 07:38:

Is there any tutorial or example on how to develop this? I think this will be extremely helpful reducing the number of executables (and executable size)

Sorry this is just my memory going back to the 90s...

I did find this though - https://open-watcom.github.io/open-watcom-v2- … docs/lguide.pdf - check section 4.3 (Overlays)

If you're going to make CD-Audio available, it might be a good idea to make sure it will play arbitrary Audio CDs. I have fond memories of just plopping in whatever CD I wanted to with Quake and it will sequence the tracks with levels. It skips track 1 iirc (for the data).

hello. i am interested in this port, and i have a few questions:
1. is it fully demo compatible with vanilla doom?
2. will there be a 160*100*256c mode? that is, 256 color version of FDOOMC16 and FDOOMC16.
3. is there any plan of porting to djgpp? because djgpp is usually supposed to generate faster binaries than watcom.

Hi @noshutdown!

noshutdown wrote on 2022-12-08, 08:34:

1. is it fully demo compatible with vanilla doom?

Latest release it's as compatible with Vanilla Doom as possible, any bug related to desync on demos will be studied and fixed.

noshutdown wrote on 2022-12-08, 08:34:

2. will there be a 160*100*256c mode? that is, 256 color version of FDOOMC16 and FDOOMC16.

For CGA cards the next release (0.9.3) will feature a "512 color" 80x100 mode, the same used on 8088MPH demos. Will require an original IBM CGA card with composite output. It's pretty much on the limit of what a CGA card can do. For VGA cards the only way to do 160x100@256 is by reducing the rendering resolution and doubling drawn vertical pixels in software because the minimum resolution is 320x200 on 256 colors with VGA hardware (unless there is some trick I don't know). With some tricks it's possible to write 2 or 4 pixels horizontal on a single write. That's why potato resolution is 80x200 and low is 160x200.

noshutdown wrote on 2022-12-08, 08:34:

3. is there any plan of porting to djgpp? because djgpp is usually supposed to generate faster binaries than watcom.

There is some work done to port FastDoom to DJGPP, but requires rewriting huge parts of the sound code and right now is non-functional. Being almost only one developer with limited time for the project, I haven't spent more time on this. Right now I prefer to optimize even further in Watcom and add support for more hardware. As always any help is very welcome.

ViTi95 wrote on 2022-12-08, 09:20:

For VGA cards the only way to do 160x100@256 is by reducing the rendering resolution and doubling drawn vertical pixels in software because the minimum resolution is 320x200 on 256 colors with VGA hardware (unless there is some trick I don't know).

i think thats what i intended to mean.

There is some work done to port FastDoom to DJGPP, but requires rewriting huge parts of the sound code and right now is non-functional. Being almost only one developer with limited time for the project, I haven't spent more time on this. Right now I prefer to optimize even further in Watcom and add support for more hardware. As always any help is very welcome.

for sound, maybe you can have a look at other dos ports and see how they did it, mbf and eternity comes to mind.

also, is this port limit-removing?

Those ports use the Allegro library for sound, that's another option. But any optimization or support for new sound card has to be redone for this library. About limit-removing, only unlimited sprites are included right now, I've also developed unlimited visplane support but won't be released until is 100% stable.

ViTi95 wrote on 2022-12-08, 09:20:

For CGA cards the next release (0.9.3) will feature a "512 color" 80x100 mode, the same used on 8088MPH demos. Will require an original IBM CGA card with composite output.

That means this will be impossible to try out in emulation, correct?

It's fully working on DosBox-staging, both old and new models of IBM CGA cards are supported. The 512 color mode doesn't require perfect timing cycles, so it should work on any emulator / computer (with the IBM CGA obviously). I still have to try on real hardware since my IBM CGA card composite output is dead.

cnlohr maintains slimmed down embedded doom fork he did for esp32 https://github.com/cnlohr/embeddedDOOM/
he recently ran it in his minimal (400 lines of code) RISC-V emulator
https://www.youtube.com/watch?app=desktop&v=uZMNK17VCMU

tldr: he implemented some extensive hacks to doom codebase to make it use less ram ("theoretically, you could run this on a system with only 384kB RAM", but probably not cpu), might be interesting checking his modifications.

ViTi95 wrote on 2022-12-08, 09:20:

For VGA cards the only way to do 160x100@256 is by reducing the rendering resolution and doubling drawn vertical pixels in software because the minimum resolution is 320x200 on 256 colors with VGA hardware (unless there is some trick I don't know

you can stretch scanlines vertically by setting height (minus one) to bits 0-4 of CRTC Maximum Scan Line register (0x3D4 index 9), additionally bit 7 of the same register further doubles line height:

13d4h index  9  (R/W):  CRTC: Maximum Scan Line Register
2bit 0-4  Number of scan lines in a character row -1. In graphics modes this is
3         the number of times (-1) the line is displayed before passing on to
4         the next line (0: normal, 1: double, 2: triple...).
5         This is independent of bit 7, except in CGA modes which seems to
6         require this field to be 1 and bit 7 to be set to work.
7      5  Bit 9 of Start Vertical Blanking
8      6  Bit 9 of Line Compare Register
9      7  Doubles each scan line if set. I.e. displays 200 lines on a 400
10         display.

By default, in 320x200 256 color VGA mode, this register has bits 0-4 set to 1 and doublescan bit reset, so as there are actually 400 scanines onscreen, every frame buffer line is displayed twice. setting those bits to 3 makes every line to be scanned 4 times, stretching 320x100 buffer to full screen. Or you can set those bits to 0 to create 320x400 mode, as one supported by Quake 😀

by the way, apart of known and currently used "write 2/4 bitplanes at once" method, you can create true 160x100/200/400 mode by tweaking CRTC to use timings from 320x200 16 color mode and halving pixel clock via Sequencer index 1. Unfortunately, it is not very compatible with some VGA cards (i.e. it needs vendor-specific /2 clock divider for Trident/Realtek, causes out of spec 140Hz vertical refresh on ET6000, and S3 cards either display solid color or mess up RAMDAC writes)

1printf("\n");
2    printf("test 160x200 256 color mode\n");
3    printf("this mode uses display timings from 320x200 16 color mode, and utilize\n");
4    printf("VGA 256 color pixel doubling to create extra-lowres mode :)\n");
5    printf("Some VGA cards (like S3 or Trident) are incompatible with this mode, or\n");
6    printf("require vendor-specific tweaks.\n");
7
8    printf("\n");
9    printf("select method:\n");
10    printf("  1) set 320x200 16 color mode, then switch ATC/GC to 256 color mode\n");
11    printf("  2) set regular mode 0x13, then tweak CRTC horizontal timings\n");
12    uint32_t baseMode = inputSelection(2); if (baseMode == -1) return true;
13
14    printf("select vendor-specific tweaks:\n");
15    printf("  1) none\n");
16    printf("  2) Trident (vendor-specific /2 clock divider)\n");
17    printf("  3) Realtek (vendor-specific /2 clock divider)\n");
18    printf("  4) S3      (vendor-specific /2 clock divider, may cause palette issues)\n");
19    uint32_t clockMode = inputSelection(4); if (clockMode == -1) return true;
20
21    if (baseMode == 0) {
22        // set 320x200 16 color mode, then switch ATC/GC to 256 color mode
23        setvgamode(0x0D);
24        set60hz();
25       // setLinear16c(); 
26       for (int i = 0; i < 16; i++) { inp(0x3da); outp(0x3c0, i); outp(0x3c0, i); } // attribute controller/EGA palette identity mapping
27        inp(0x3da); outp(0x3c0, 0x30); uint8_t atc = inp(0x3c1);
28        inp(0x3da); outp(0x3c0, 0x30); outp(0x3c0, atc | 0x40);
29        outp(0x3ce, 5); outp(0x3cf, inp(0x3cf) | 0x40);
30
31        // enable chain-4 (skip for Mode-X)
32        outp(0x3c4, 4);    outp(0x3c5, inp(0x3c5) | 0x08);
33        outp(0x3d4, 0x14); outp(0x3d5, inp(0x3d5) | 0x40);
34        outp(0x3d4, 0x17); outp(0x3d5, inp(0x3d5) | 0x40);
35
36    } else {
37        // set regular mode 0x13, then tweak CRTC horizontal timings
38        setvgamode(0x13);
39        set60hz();
40        outp(0x3d4, 0x11); outp(0x3d5, inp(0x3d5) & ~0x80);
41        outpw(0x3d4, 0x1413);
42
43        outpw(0x3D4, 0x2D00);
44        outpw(0x3D4, 0x2701);
45        outpw(0x3D4, 0x2802);
46        outp (0x3D4, 0x03);  outp(0x3D5, (inp(0x3D5) & ~(0x1F)) | 0x10);
47        outpw(0x3D4, 0x2B04);
48        outp (0x3D4, 0x05);  outp(0x3D5, (inp(0x3D5) & ~(0x9F)) | 0x8F);
49
50        // enable VGA DCLK/2
51        if (clockMode == 0) {
52            outpw(0x3c4, 0x0100);
53            outp(0x3c4, 1); outp(0x3c5, inp(0x3c5) | 0x08);
54            outpw(0x3c4, 0x0300);
55        }
56    }
57
58    if (clockMode > 0) {
59        // disable VGA DCLK/2 
60        outpw(0x3c4, 0x0100);

61        outp(0x3c4, 1); outp(0x3c5, inp(0x3c5) & ~0x08);
62        outpw(0x3c4, 0x0300);
63    }
64    switch (clockMode) {
65        case 1:
66            // Trident DCLK/2
67            outp(0x3C4, 0x0B); inp(0x3C5);  // select new mode
68            outp(0x3C4, 0x0D); outp(0x3C5, (inp(0x3C5) & ~0x6) | 2);
69            break;
70        case 2:
71            // Realtek DCLK/2
72            outp(0x3CE, 0x0B); outp(0x3CF, inp(0x3CF & ~3) | 2);
73            break;
74        case 3:
75            // S3 DCLK/2 (leads to palette issues as CPU accesses to RAMDAC are syncronized to DCLK,
76            // causing RAMDAC to miss palette writes/reads if DCLK is too low)
77            
78            // unlock S3 extensions
79            outpw(0x3C4, 0x0608);
80            outpw(0x3D4, 0x4838);
81            // use S3 method of VCLK/2
82            outp(0x3C4, 1);    outp(0x3C5, (inp(0x3C5) & 0xF7));
83            outp(0x3C4, 0x15); outp(0x3C5, (inp(0x3C5) | 0x10));
84            // lock S3 extensions
85            outpw(0x3C4, 0x0008);
86            outpw(0x3D4, 0x0038);
87            break;
88        default: break;
89    }

Doom on CGA without 16bit x86 support is a travesty
Harris 286-25 🙁 no doom

Doom alphas had 160x100 rendering too but I don't know how that's done exactly.

While developing optimizations for Potato mode i've just discovered a bug that I think it hasn't been documented and exists since... 1994 (!!) It just happens that Heretic has a rendering bug on R_DrawSpan (which is ASM optimized and it's much faster compared to Doom R_DrawSpan). It basically renders the first pixel twice and then continues rendering the rest without issues. It's hard to find on a 320x200 resolution, but it becames very obvious on FastDoom's potato mode (80x200):

Here is the bug on Heretic:

And here is the same bug on FastDoom's Potato mode:

Right now, the bug has been fixed and these are some performance numbers:

FastDoom 0.9.1: 27.632 fps
FastDoom 0.9.2: 33.860 fps

This is 22% faster, on a 386DX-40 (Ultimate Doom timedemo demo3, fullscreen+HUD and no sound). And here is the cool thing, the same optimization will be applied for low detail and high detail modes on Mode Y, so expect performance uplift on the next release 😁

rmay635703 wrote on 2022-12-10, 04:38:

Doom on CGA without 16bit x86 support is a travesty
Harris 286-25 🙁 no doom

Yeah I know, as is already been said, is very hard to port Doom to 16-bit only instruction set. Maybe some crazy developer (and more experienced than me) could achieve this. Or make Wolfenstein 3D Hercules/CGA/EGA compatible 😏

OMFG It's in Hexen too!

(Strife has been spared of this bug)

ViTi95 wrote on 2022-12-16, 09:33:

While developing optimizations for Potato mode i've just discovered a bug that I think it hasn't been documented and exists since... 1994 (!!) It just happens that Heretic has a rendering bug on R_DrawSpan (which is ASM optimized and it's much faster compared to Doom R_DrawSpan). It basically renders the first pixel twice and then continues rendering the rest without issues.

Interesting, the original DOS version of DOOM also used an ASM optimized version of R_DrawSpan (even though id Software never released the DOS version of the source code because of the DMX sound library, they added the ASM routines into the README.ASM file found in linuxdoom).

Or make Wolfenstein 3D Hercules/CGA/EGA compatible 😏

Wolfenstein 3-D alpha had a EGA version that was used in Catacomb 3-D, the direct predecessor. Some of the removed content and leftovers can be seen in the Development Info page of the game in The Cutting Room Floor and the source code respectively.

My Toshiba T5200 runs FastDoom quite nicely already (pimped with 486SXL2-40) but I'm gonna overclock it to 50MHz this weekend by swapping oscillator. Hope it'll be stable...