Well it mostly works now. But did we ever have the biggest fun with the sound and SVGA.
So [HCI]Mara’akate integrated all the Q1 sound code, got it to compile, but nothing not a peep from the sound card. While I was busy trashing the video code, he spent way too much time on the audio, and then for the heck of it I thought I’d look at the code, although I’m really stabbing in the dark when it comes to audio. Imagine my surprise when I compiled the code, and ran it and got the sound blasting at full volume! It turns out that I had my audio set to ‘high quality’ in the client, while he had his set to ‘low quality’. What it does is govern the frequency between 11Khz and 22Khz. And if you get this wrong you get *NO* audio. OOPS. At least it was one of those feeling vindicated moments that his efforts for sound really did work.
Now with audio, it was my time to hurry up and get the video going. I had basic VGA working so I figured I didn’t want to spend a lot of time on this, so I was going to go with the VESA 2.0 linear frame buffer. Well this once more again proved to be a bit more involved as the only way I really have to test is emulation via DOSBox and Qemu. And naturally both of them worked fine, but when [HCI]Mara’akate ran it on his real DOS Box (with GUS of course) it crashed wonderfully.
Now I had taken the VESA init code from Quake 1 to build a table of what 8bit modes are supported, and used the VESA code to switch, along with drawing to the buffer with a simple memcpy. And we got nothing but crashes.
After looking more around, I found that you had to add 0x4000 to the VESA mode you want if you wanted to access it’s LFB. Did that work? No still crashed.
Later in the adventure we noticed to get proper access you had enable ‘near pointer acess’ with a call to :
So naturally I would disable it when I’m done, making the call look like this:
WRONG. Oh so WRONG. Well OK technically it did work, but if sound is enabled (and why wouldn’t it be?) it would immediately crash with an error in the DMA code. We ended up wasting over a day trying to figure this one out until I just said screw it, let’s never dsiable the nearpointer, leave it unprotected. Naturally that actually worked. The hint is in map_in_conventional_memory, where __djgpp_nearptr_enable(); is called, but of course there is no calls to __djgpp_nearptr_disable(); I’ve thought about going back through the source to ‘clean’ it up to make it lock and unlock memory as needed, but this is 2015 not 1997 so good enough is well, good enough.
So now with VESA and Sound, I thought this would be a great time to tackle the dynamic loading of gamex86. We will have to re-compile whatever gamex86 DLLs are out there as of course DOS is DOS. The HX DOS guy Japheth seems to have died, as his site and all the info on that extender seems to have mostly vanished. I have an old copy, but I never could make it call DOS stuff if you had WIN32 stuff going on. And if he’s really dead it’s too late to ask him.
Ages ago I remembered this DLL support for DJGPP called DLM, so I thought I’d give that a try. I was able to take our ‘null’ version of Quake II, and get it to where it can load and unload the gamex86.dlm at will. So I figured this was going to be an easy win, right?
Wrong again. Once I started to put in the MS-DOS specific code I got this fun crash:
DLM -> Exiting due to signal SIGSEGV at
0x0014f59d SYM: _dos_lockmem+0x9 DLM: q2.exe [0xf5000]
possibly because of undefined reference to symbol ‘___djgpp_base_address’
So apparently it doesn’t export (or import) djgpp stuff like the base address calculations so we can’t do direct memory access, which means no video and no sound. Ouch. I’ll have to hit the lists to see about support. I don’t like the DXE’s because they cannot be unloaded, so that isn’t much good. And of course things like the JVM inside of gamex86.dll is right out as JAVA inside of MS-DOS? in 64MB of RAM? Dream on.
So for now, the gamex86.dll is statically linked into the executable. You are restricted to vanilla gameplay for now.
As an added bonus, I used Rufus 2.2, to setup a bootable MS-DOS USB stick, slapped everything onto there, and booted up on my Xeon, and it works!
Now as a super bonus, [HCI]Mara’akate went above and beyond by adding in a bunch of fixes, and updates from 3.24 and varous stuff from Knightmare. And then the best part is integrating libogg, so it can now play the ogg sound track! Really, just place the ogg files in the baseq2\music directory and away you go!
Continuing in this series on porting Quake II to MS-DOS, we get to touch some of the fun stuff. The first big ‘fun’ thing is networking.
Now in my prior work with the MS-DOS version of Quake, I had used the WATTCP library to bring networking to the otherwise Windows/UNIX specific fun of network deathmatch back to MS-DOS. Quake by default had support for the Beame & Whiteside’s TCP/IP stack which for all intents and purposes has vanished from the face of the Earth (does anyone have a copy?!). So at the time, I thought it’d be cool to try to interface WATTCP with Quake, and it worked on the first attempt as WATTCP is a very competent TCP/IP stack.
So I took the Linux networking file net_udp, and compiled it, and I got an executable!
When it comes to testing WATTCP though, I prefer to use Qemu instead of DOSBox as it can not only emulate various network cards to which I can find packet drivers (yes even the evil PCI NE2000!) but it has a built in SLiRP network stack that let’s me NAT on my desktop without any crazy network configs.
And for the sake of testing, I setup a ‘null’ text mode server, figured out some flags, and I was able to connect!
Very exciting stuff indeed!
Now for some interesting stuff. First I noticed that MS-DOS 5.00 with himem.sys is almost unplayable because it is so slow. MS-DOS 4.01 without himem.sys is actually faster. No, I’m not kidding.
Next is that some levels LOVE to gobble up RAM. Maps like city1 will need at least 192MB of ram. I haven’t even tried playing with the virtual memory of DJGPP, and I really don’t want to. And let’s face if, if you even try to load Quake II on a MS-DOS machine, it better be a ‘big’ one. This means you should be using the ‘dos’ from Windows 98, or perhaps FreeDOS, although I haven’t tested that at all.
So far from our limited testing the networking seems to be pretty good. And at least that is one function we didn’t have to really pour a lot of effort into. Although the payoff of being able to connect to servers on the LAN and even the internet is a good thing.
(In this series, I’m going to go over the process of porting Quake II to MS-DOS. Now of course the question will pop up why? And the answer is simple enough, after [HCI]Mara’akate added in gamespy support, something was noticeably off, and that is fewer and fewer people are playing Quake 1 these days. So what to do?
Well apparently Quake II has an active following, so it’s time to move our creeky but favorite OS, MS-DOS into the Quake II Arena!
So the first thing to do is to grab a copy of the GPL source to Quake 2, along with a copy of the game, and get started on making a ‘null’ version of the game. Null versions of the game have no graphical output, no sound, and ‘function’ at a very basic level. It’s something to strive for as a first base in hitting that home run of a functional port. Thankfully iD wrote really portable and modular software. Unfortunately they tended to let their ports drift as they were writing the engine so the null code doesn’t actually work out of the box. And the project makfiles leave a little to be desired for me, as they have a bunch of i386/Dec Alpha magic which doesn’t leave much in the room for weird ports like MS-DOS.
Now I should mention that before I’d gotten started the first thing I decided that like QuakeWorld for MS-DOS (and OS/2) I would use GCC as it is a known working compiler out of the box. If you can, don’t fight so many battles of unknowns at once. Another thing is that I am going to cross compile from OS X and test with DOSBox. Of course you may want to use something else, and I know my tastes drift, but for now this is what I’m using. I’m using my old OSX to DJGPP cross compiler with GCC 2.95.3, which serves me well.
So the first thing was to compile and run the null version with native tools on OS X. After a bit of struggle I got here:
One thing I did to make it easier to work with the flow of Quake is to make the Sys_Error procedure contain a divide by zero. Now why would I purposely put a divide by zero in the code? Simple it lets me back trace the code when Quake catches it’s own faults so I can see what went wrong where, vs what would look like a clean exit. From my example:
We can see that the vid.width/vid.height aren’t being setup correctly. Turns out there was a bunch more work to be done setting up vid_null!
After looking closer at the files, I notice as I’m stitching them together is that Quake II relies on DLL’s as part of it’s base functionality. I drifted out of Quake after Quake 1, so I never played II before. So I didn’t know this. Obviously DJGPP doesn’t support DLL’s that can be loaded and un-loaded at will (Yes I know about DXE’s, but as the FAQ states, they cannot be un-loaded. And I’m not going to fight DJGPP’s LIBC). So looking further in the source, I saw these fun defines:
So at one point there was support for ‘hard linking’ in the ‘REF’ video driver, and the ‘game’ logic driver. But it did kind of drift out of the code. But looking at the Win32 version I could see that putting this functionality back in should be easy. And to be honest if I learned any lesson from this, is that I should have been pulling the Win32 version apart by injecting null into it until it ran as a null platform, then use that as the basis. Lesson learned. Always start with a known good! Quake II was built with Visual C++ 6, but I only have Visual C++ 4.2 installed on Crossover. Yes I know again this is me being difficult. But it didn’t take much time to get a simple project that has two DLL’s and a Win32 exe running. Then I took on the ‘ref’ video driver and got that linking inside of the main EXE. Now with one DLL ‘eliminated’ it was time to work on the game dll.
The game DLL posed the biggest challenge because it passes a reference to internal functions to it, and exports various functions back to the game engine. So I ended up altering the engine to not call the game import/export directly but setting it up myself. The hardest thing was that I couldn’t pull in the game header file, but rather I had to copy the prototypes myself. Another interesting thing with the way Quake II works is that the game dll has to be able to be unloaded and loaded at will. It wasn’t hard to simulate this, but I wasn’t expecting it. Again this is probably because I never really played Quake II.
Now that I had Quake II building without DLL’s I could then take the next step of removing all the IO and re-replacing it with the null code, and now I had something that looked like it was doing something.
This turns out because I didn’t allocate the screen properly. Looking at the code:
if ((x < 0) || (x + w > vid.width) ||
(y + h > vid.height))
ri.Sys_Error (ERR_FATAL,”Draw_Pic: bad coordinates”);
We can see it pretty plainly.
Now since we were going somewhere I started to write some MS-DOS code, and switch out of the null set of mind!
First a simple VGA mode 13 setup which gives us 320×200 resolution with 256 available colours. And for good measure I did a simple VGA palette setup that I knew worked from a prior program. Next we just blit our buffer onto the screen, and we get this:
Which is exciting and disappointing at the same time. I then took the palette code from DOS Quake, and got something just as ugly. I tried the code from OS/2. Same thing. I tried all kinds of things and was going nowhere.
At this point Mara’akate added in the Linux clock code, and now we had this!
It wasn’t until much more digging around I saw some 320×240 screen setups that I realized there was something wrong there, and then I saw this gem in the linux port’s code:
** System specific palette setting routine. A NULL palette means
** to use the existing palette. The palette is expected to be in
** a padded 4-byte xRGB format.
In traditional VGA palette setups it’s 768 bytes that needs to be read/and pushed to the card. I even checked Quake 1 is 768 bytes, but now in Quake II, it’s 1024 bytes! OOPS! Sometimes (ok a lot of times) you really need to check other ports or a ‘known good’ to see how they did things.
So where to go from here? Obviously things like better keyboard input, the mouse, sound and networking need to be done.
I went with MVDsv, which I could just unpack the i386 executable on my VPS, allowing me to go ahead with my lovingly stock id1 pak files. MVDsv requires just paste this into the console, or add it to the server.cfg
MVDSV Project home page: http://mvdsv.sourceforge.net
======== QuakeWorld Initialized ========
couldn’t open accounts
Client MS-dos connected
Couldn’t download skins/base.pcx to MS-dos
MS-dos entered the game
Now when I jump in I get monsters!
One thing I had screwed up was the samelevel command on my server, setting it to two would kill the player if they tried to exit the level. Ugh. There is a guide here, but of course co-op isn’t the same as death match!
So I spent a few hours updating some QuakeWorld clients.. for reproducibility sakes, I built out the MS-DOS one and that worked fine. The OS/2 one ‘works’ but the keyboard isn’t working. Not so sure why not. The Win32 version works fine, although I’m building with Visual C++ 4.0, and no assembly or DirectX. Just straight GDI.
Next will be Linux with svgalib.
So my work is here. I could go more into how to build, but I don’t know if anyone cares.
I know this may sound silly, but I’m a silly person. And yes, QuakeWorld used to build cleanly and fine on Linux. However it doesn’t anymore, things have changed a *LOT* in the world of Linux, since the birth of QuakeWorld in 1996. A different LIBC standard or two, and all kinds of other changes in the compiler. Not to mention I have a x86_64 machine, and I want a pure 32bit binary, so the best way to go about that is to setup a 32bit virtual machine, and build from there. I know I could cross compile, but on the otherhand I don’t want to install all this kind of crap on my server if I don’t have to. So there is all kinds of reasons why you may want to build your own. Not to mention if you are running Linux, but on a non x86 platform. I guess the Raspberry Pi would be a good choice now that it is over two million units sold.
The first thing you need of course is the source code to Quake, from iD (my mirror). Next you’ll need a more up to date Makefile. I used the one from the LinuxGL-QuakeWorld-mini-HOWTO. Don’t worry about the client stuff, it doesn’t matter the first thing it does anyways is build the server.
For the sake of preserving it, here is the makefile:
With that saved into a file, it is time to build. Unzip the source code into a directory, and then from the QW directory run the new Makefile. If your GCC is new enough it’ll complain about the -m486 directive. Just remove that from the Makefile. On my bare build system it compiles the server in a few seconds, but then fails to build the GLQuake client because I don’t have any OpenGL installed. But again this is fine, I just want the server.
The next part is to copy in the pak0.pak & pak1.pak from your registered copy of Quake 1 into /usr/local/quake/id1. You can always buy it on steam, although it is so old I’m sure you’ve already acquired a copy or two in the last few years. Note that pak0.pak is the shareware portion of the datafile! To be a server you require pak1.pak from the registered copy of Quake. Although the source to the maps has been released, I’m pretty sure you will be missing all kinds of otherthings from pak1.pak.
Ok now with the pak’s in place, you need the QuakeWorld scripts in place. Copy the ‘progs’ directory into the qw directory
However you probably will want a server.cfg. And incase the page goes offline here is a pretty basic config:
hostname ”Your Quake DM Server”
serverinfo admin ”[email protected]”
serverinfo url “http://www.yourwebsite.com”
floodprot 4 8 30
floodprotmsg “You have activated the flood protection and will be silenced for 30 seconds”
Naturally you may want to change things. Save the config file into the id1 directory.
Now when it comes to running the server, the console will want to be interactive to the user. If you nohup the process it’ll go bezerk. The best way to do this is with screen. In my /etc/rc.local I add the following line:
screen -dmS quake /usr/local/quake/quake.sh
And of course the shell script is:
Very simple stuff. If the server crashes or stops for any reason it’ll restart.
By default QuakeWorld will listen on UDP port 27500. The next thing you’ll need is a client to test. I’m kind of partial to the MS-DOS (qemu) and OS/2 clients.
And there we go, now you too can host your own QuakeWorld server. And for those who can’t compiler, you can try my x86 binary here.