A late thanks! This is useful as vanilla quake is a jerk to compile. I have not tested it at the moment, since I nuked my compiling environment (Win98SE VirtualPC VM)

A late thanks! This is useful as vanilla quake is a jerk to compile. I have not tested it at the moment, since I nuked my compiling environment (Win98SE VirtualPC VM)

I built it yesterday, and it seems to work fine under DOSBox (I seem to prefer 640x400). A bit troubling is the few warnings about "indirect jump without *" in some of the assembly .s files, though, but I have no idea and yet it seems to work anyways (and not using CWSDPMI r1, which I renamed). I guess I should use an old BinUtils from that era (2.6? 2.9?) and disassemble its output to verify correctness.

EDIT: No warnings with GAS 2.8.1, but it chokes later on on "filds" (eh?).

1# math.s, line 125
2	jmp		Ljmptab(,%eax,4)
3
4# GAS 2.16.1
5  a7:	ff 24 85 00 00 00 00 	jmp    *0x0(,%eax,4)
6
7#GAS 2.8.1
8  a7:	ff 24 85 64 02 00 00 	jmp    *0x264(,%eax,4)

Does it matter? What does this do?? Argh, I have no idea (sorry). But it doesn't stay this way in the final .EXE, the linker does something, so maybe it's just a bogus warning. 🙁

redir -eo make > warnings.txt
grep indirect warnings.txt

d_polysa.s:850: Warning: indirect jmp without `*'
d_parta.s:223: Warning: indirect jmp without `*'
math.s:125: Warning: indirect jmp without `*'

as.info wrote:

9.13.8 Memory References ------------------------ […]
Show full quote

9.13.8 Memory References
------------------------

An Intel syntax indirect memory reference of the form

SECTION:[BASE + INDEX*SCALE + DISP]

is translated into the AT&T syntax

SECTION:DISP(BASE, INDEX, SCALE)

where BASE and INDEX are the optional 32-bit base and index registers,
DISP is the optional displacement, and SCALE, taking the values 1, 2,
4, and 8, multiplies INDEX to calculate the address of the operand. If
no SCALE is specified, SCALE is taken to be 1.
...
Absolute (as opposed to PC relative) call and jump operands must be
prefixed with `*'. If no `*' is specified, `as' always chooses PC
relative addressing for jump/call labels.

BTW, Why even need a VM? If you're not on 64-bit, just use NTVDM. DJGPP does work there (though you need the DPMI limit registry hack for Vista). Worst case scenario, I could post my build somewhere. And I have plenty of FreeDOS floppy images if you want to build from there (easier to install, I assume). I guess you know that DOSBox is way too slow for compiling stuff. 🙁

P.S. I was told that DJGPP 2.00 libc had lots of functionality missing, hence why the typical Quake binary (404,480 bytes) is smaller than mine (562,176 bytes). But that's not UPX'd! 😀

P.P.S. Using my mini DJGPP, it only takes 46 secs. to compile (P4 2.52 Ghz).

I tested DOSEMU (both 32-bit under gNewSense and 64-bit under XUbuntu x86-64), and the Quake recompile worked flawlessly under both for me. DOSBox is like 90% fast enough too. But I suspect it'd be much easier / faster to just use DOSEMU for development than VirtualPC.

I also posted some useful Quake/DJGPP links on comp.os.msdos.djgpp yesterday, if you're curious.

Almost all Doom ports need Allegro, but CDoom either doesn't or else indirectly just lumped the parts it needed in with itself that it used MUSLib (I didn't look too close).

The problems with Allegro are several, though: most DOS versions of Doom need Allegro 3.x, last / best DOS-only version is 3.12 (patches.dat and added VBEAF.DRV support) which most default compiles (Boom, Eternity) didn't use. Also, the last DOS version of Allegro was 4.2.2 (later dropped entirely!), and it was buggy. So buggy that the RAINE guy hacked up his own patched version (see bottom of page) for his surprising DOS update a few months ago.

Thanks though in the end I removed allegro anyway. I want to use the Apogee sound system from ROTT instead but that's all Watcom.

This is what i've done so far. NOTE: NO EGA STUFF IN IT 🙁

Rugxulo wrote:

I tested DOSEMU (both 32-bit under gNewSense and 64-bit under XUbuntu x86-64), and the Quake recompile worked flawlessly under b […]
Show full quote

I tested DOSEMU (both 32-bit under gNewSense and 64-bit under XUbuntu x86-64), and the Quake recompile worked flawlessly under both for me. DOSBox is like 90% fast enough too. But I suspect it'd be much easier / faster to just use DOSEMU for development than VirtualPC.

I also posted some useful Quake/DJGPP links on comp.os.msdos.djgpp yesterday, if you're curious.

Almost all Doom ports need Allegro, but CDoom either doesn't or else indirectly just lumped the parts it needed in with itself that it used MUSLib (I didn't look too close).

The problems with Allegro are several, though: most DOS versions of Doom need Allegro 3.x, last / best DOS-only version is 3.12 (patches.dat and added VBEAF.DRV support) which most default compiles (Boom, Eternity) didn't use. Also, the last DOS version of Allegro was 4.2.2 (later dropped entirely!), and it was buggy. So buggy that the RAINE guy hacked up his own patched version (see bottom of page) for his surprising DOS update a few months ago.

Have you ever managed to setup a development environment in Linux using DOSEMU and DJGPP?