IRC necromancy

I’m xorhash, a guest poster, here to talk about my tale going down a trip on the memory lane with QuakeNet’s service bot Q. If you’re not interested in IRC, you can probably skip this one.

On the Trails of Q

As far as I know, QuakeNet’s service bot Q went through these three major codebases:

a. the old Perl Q,
b. the first version written in C, and
c. Q as part of newserv.

There’s a reason I didn’t have anything to link for (a). That’s because to the best of my knowledge and research, no version has survived these past decades.

As for (b), it seems only the linked version 3.99 from the year 2003 was saved.
The CVS repository and thus commit history has been lost.

If anyone has either actual code for the old Perl Q or the CVS repo for the old
Q written in C, please reach out to me via `xorhash ++at++ protonmail.com’.
I’m most interested in looking through it.

However, not all hope was lost with the old Perl Q. As it turns out, most likely, the old Perl Q was actually based on an off-the-shelf product called “CServe”. What makes me think so?

Let’s take a look at [the QuakeNet Q command listing from 1998.

I picked the command “WHOIS” and googled its use “Will calculate a nick!user@host mask for you from the whois information of this nick.” This lead me to a help file for StarLink IRC. At the top, it reads:

CStar3.x User Command Help File **** 09/10/99
Information extracted from CServe Channel Service
Version 2.0 and up Copyright (c)1997 by Michael Dabrowski
Help Text (c)1997 (c)1997 StarLink-IRC (with permission)

Wait a second, “CServe Channel Service”? I know that from somewhere.

Q!TheQBot@CServe.quakenet.org

So the commands between that help file and the QuakeNet Q command listing match up and so does Q’s host today. Most likely, I’m on the right track with this. What’s left is to track down a copy of CServe.

Note: I’ve been on the old Perl Q for a while and this strategy didn’t use to work. It seems Google newly indexed these pages. For once I can sincerely say: Thank you, Google.

I found that CServe was hosted on these websites:

a. Version 3.0 on http://www.cs.cuc.edu/~mdabrows/cserve/,
b. Version 3.1 on http://www.wam.umd.edu/~devy/cserve/,
c. Version 4.0 on http://www.othernet.org/devon/cserve/, and
d. Version 5.0 and above on http://www.ircore.com/.

The only surviving versions are 3.0 and 5.1. CServe got renamed to “CS” starting with 5.0 and was rewritten in C by someone other than the original CServe author, going by the comments in the file header of CS5.1 `src/show_access.c’. CS was actually sold as a commercial product. I wonder how many people bought it.

QuakeNet most likely took a version between 2.0 and 4.0, inclusive, as the basis for the old Perl Q. Which one in particular it was, we may never know. If you have any details, please reach out to me at the e-mail address above.

I can’t make any clever guesses anyway since the only versions that the web archive has are 3.0 and 5.1. The latter is written in C, so it quite obviously can’t be the old Perl Q.

Making It Run

So now that I have CServe 3.0, I wanted to actually see it running.

There are three ways to reasonably accomplish this:

a. port CServe to a modern IRCd’s server-to-server protocol,
b. port an old IRCd to a modern platform,
c. emulate an old platform and run both IRCd and CServe there.

I chose option (b).
Once upon a time, I did option (a) for the old UnderNet X bot. It was a very painful exercise to port a bot that predates the concept of UIDs (or numeric nicks/numnicks as ircu’s P10 server-to-server protocol calls them). There’s nothing too exciting about doing (c) by just emulating a 486 or so and FreeBSD, just sounds like a boring roundtrip of emulation and network bridging.

Fortunately, the author was a nice person and wrote on the CServe website that version 3.0 requires “ircu2.9.32 and above”.

It seems the ircu2.10 series followed right after ircu2.9.32. While I’m sure there’s some linking backwards compatibility, determining which ircu in the ircu2.10 series still spoke enough P09 to link with CServe sounded like an exercise in boring excruciating pain. Modern-day ircu most certainly no longer speaks P09. Besides, what’s the fun in just doing the manual equivalent of `git bisect’?

So after grabbing ircu2.9.32, I tried to just straightforward compile and run it.

There’s a `Config’ script that’s supposed to be kind of like autoconf `configure’, but I’ve found it extremely non-deterministic. It generates `include/setup.h’. I’ve made a diff for your convenience. It targets Debian stable, and should work with any reasonably modern Linux. There are special `#ifdef’ branches for  FreeBSD/NetBSD in the code. This patchset may break for BSDs in general.

Do not touch `Config’, meddle with `include/setup.h’ manually. Remember this is an ancient IRCd, there are actual tunables in `include/config.h’.

The included example configuration file is correct for the most part, but the documentation on U:lines is wrong. U:lines do what modern-day U:lines do, i.e., designate services servers with uber privileges.

U:cserve.mynetwork.example:*:*

Excuse Me, But What The Fuck?

Of course, I’m dealing with old code. It wouldn’t be old code if I didn’t have some things that just make me go “Excuse me, but what the fuck?”

Looping at the speed of light


aClient *find_match_server(mask)
char *mask;
{
aClient *acptr;
if (BadPtr(mask))
return NULL;
for (acptr = client, (void)collapse(mask); acptr; acptr = acptr->next)
{
if (!IsServer(acptr) && !IsMe(acptr))
continue;
if (!match(mask, acptr->name))
break; continue;
}
return acptr;
}

See that `continue’ way on the left? What is it doing there? Telling the compiler to loop faster?

Carol of the Old Varargs

So apparently some of this code predates C89. Which means it uses old-style declarations, but that’s okay. It also uses old-style varargs, which is adorable.

The hacks around not even that being there are adorable, too:


#ifndefUSE_VARARGS
/*VARARGS*/
voidsendto_realops(pattern, p1, p2, p3, p4, p5, p6, p7)
char*pattern, *p1, *p2, *p3, *p4, *p5, *p6, *p7;
{
#else
voidsendto_realops(pattern, va_alist)
char*pattern;
va_dcl
{
va_list vl;
#endif
Reg1 aClient *cptr;
Reg2 int i;
char fmt[1024];
Reg3 char *fmt_target;

#ifdef USE_VARARGS
va_start(vl);
#endif

(void)sprintf(fmt, ":%s NOTICE ", me.name);
fmt_target = &fmt[strlen(fmt)];

for (i = 0; i <= highest_fd; i++)
if ((cptr = local[i]) && IsOper(cptr))
{
strcpy(fmt_target, cptr->name);
strcat(fmt_target, " :*** Notice -- ");
strcat(fmt_target, pattern);
#ifdef USE_VARARGS
vsendto_one(cptr, fmt, vl);
#else
sendto_one(cptr, fmt, p1, p2, p3, p4, p5, p6, p7);
#endif
}
#ifdef USE_VARARGS
va_end(vl);
#endif
return;
}

These functions were declared like this (the example chosen above actually has
no declaration because why not):

/*VARARGS1*/
extern void sendto_ops();

Whatcmp

There are `mycmp’ and `myncmp’ for doing RFC1459 casemapping string comparisons. `strcasecmp’ got `#define’d to `mycmp’, but in one case `mycmp’ got `#define’d back to `strcasecmp’. It seemed easier to just remove `mycmp’, replacing it with `strcasecmp’ and forgo RFC1459 casemapping. This is doubly useful because CServe doesn’t actually honor RFC1459 casemapping.

Waiting for the Cookie

ircu uses PING cookies. I was rather confused when I didn’t get one immediately after sending `NICK’ and `USER’. In fact, it took so long that I thought the IRCd got stuck in a deadloop somewhere. That would’ve been a disaster since the last thing I wanted to do is get up close and personal with the networking stack.

As it turns out, it can’t send the cookie:


/*
* Nasty. Cant allow any other reads from client fd while we're
* waiting on the authfd to return a full valid string. Use the
* client's input buffer to buffer the authd reply.
* Oh. this is needed because an authd reply may come back in more
* than 1 read! -avalon
*/


Nasty indeed.

I lowered `CONNECTTIMEOUT’ to 10 in the diff linked above. This makes the wait noticeably shorter when you aren’t running an identd.

CServe Isn’t Much Better

Not that CServe is much better. I have to hand it to Perl, I only needed to undo the triple-`undef’ on line 450 of `cserve.pl’ and it worked with no modifications. God bless the backwards compatibility of Perl 5.

That said, it has its own interesting ideas of code. This is the main command execution:


foreach $i (keys %commands)
{
if($com eq $i)
{ $found = 1; break; }
}
if($found == 1)
{
open(COMMAND, "<./include/$com");
@evalstring = <COMMAND>; close(COMMAND);
foreach $i (@evalstring) { $evals .= $i; }
eval($evals);
}
else
{
&notice("2No such command 1[4$com1]. /msg $unick SHOWCOMMANDS\n");
}

Yep, it opens, reads into an array, closes and then evals. For every command it recognizes. Of course, this means code hot swapping, but it also means terrible performance with any non-trivial amount of users.

Oh, and all passwords are hashed. But they’re hashed with `crypt()’. And a never-changing salt of ZZ.

End Result

up & running

Was it worth it?
No, not really.
Would I do it again?
Absolutely.

You probably do not want to expose this to the outside world.
The IRCd code is scary in all the wrong ways.

Further Links

Some other things if you’re into ancient IRC stuff:

Quakecon 2017

It’s that time of year again, QUAKECON.  If I were one to plan things, I’d be there either as an indie, with a table featuring such hits as QuakeWorld for OS/2, and of course the much beloved Quake II for MS-DOS.  But I’m a slacker, and things get forgotten.

As always, the old iD catalogue is on sale, featuring DooM!

Ultimate DooM is $9.75 HKD which is $1.25 USD.  So if for some reason you have never bought DooM, at this price it’s hard not to have it.  And of course all the old MS-DOS DooM can be had for $3.15 USD!  And of course for those who want to downgrade to version 1.1, don’t forget my ancient article “Just how ‘original’ is the Ultimate Doom on steam?

Meet the superfans who spent a decade bringing Daikatana back to life

Daikatana!

No, really I got an email today from Frank Sappone, that his passion project the fixing and overhaul of Daikatana was written up on PCGAMER.  Although my involvement may have gotten edited down, honestly all I did was give that little bit of a push and inspiration that it could be done by spending a good week on installing Solaris, and porting the dedicated server portion from SPARC Solaris, to x86 Solaris.  Once we had it running there, it was far easier to then get it running on Linux and OS X as a dedicated server.  Once we had that push Frank was able to use his great knowledge of Quake/QuakeWorld/Quake II and fix an incredible amount of bugs, and bring it into a fairly good state.

The real star here is of course the Johns, John Carmack for making the source code to Quake/QuakeWorld, Quake II, open so we could always refer back to this code, which Daikatana was based off an early beta of Quake II, and John Romero for giving us the needed source to make it all possible.

11.75 HKD is like $1.50 USD

It’s on sale right now at steam!

You can find Frank’s hard work here on bitbucket.org

For Windows users, you can simply download DK_EXE_030816_FULL.7Z, from his site (mirror).  And from the readme:

It’s a 7zip package. After you’ve downloaded the package you extract it to Daikatana’s folder. If you have Steam installed to it’s default path Daikatana’s folder is located in:

C:\Program Files\Steam\steamapps\common\Daikatana\

(or if you’re running 64-bit Windows):
C:\Program Files (x86)\Steam\steamapps\common\Daikatana\

If it asks if you would like to overwrite any files, do so and overwrite the files. End result is that when Daikatana starts you can see in the right bottom corner of the red area in main menu “1.3” instead of “1.2”. You’re also able to access for example the HD resolutions from the Video menu.

If you start playing multiplayer with Daikatana community, you’re also going to need:

dkcustom.rar (Pak9)

You extract that package into:

C:\Program Files\Steam\steamapps\common\Daikatana\data\

 

And to further celebrate this awesome press day, I’ve purchased a limited number of steam keys, reply with a comment (be sure to include a working email address!) and I’ll send you a key!  That’s right it’s the:

ON SALE DAIKATANA GIVEAWAY!

*Quantities limited.

Quake on HPPA (Gecko) NeXTSTEP

So forever ago I had done a super bare port of Quake to NeXTSTEP.  It was based on a copy of UAE 0.6.0 source code that included hooks for NeXTSTEP.  So seizing on this I built a shaky framework and amazingly got it to work.  Well work enough I had trouble with the mouse part, and never did get around to fixing it, but I kicked it out into the world.  And amazingly the HPPA cross compiled version that I compiled but never tested runs!

My whole misadventure is on nextcomputers.org, and blakespot has a blog about finding the gecko and it’s 32bit video modes here.

Porting Quake II to MS-DOS pt5 – 3DFX, GameSpy, Quake 2, and The Universe

The following is a guest post / wrap-up of the Q2DOS adventure by [HCI]Mara’akate.q2dos_3dfx_4
In the last update sezero and I([HCI]Mara’akate) tied up most loose ends with regards to Q2DOS.  Specifically: adding in DXE support for mods and cleaning up some code from the early efforts.  During this time, a forum user by the name of ggorts (strogg spelled backwards!) mentioned the possibility of using an old Mesa version with 3DFX support in DOS. I worked on separating the ref_soft from being statically linked into a DXE form and sezero cleaned up any potential problems there.

I mentioned the possibility of attempting the Mesa port to sezero and he thought it was probably a wasted effort and thought making a ref_glide depending only on glide3x.dxe would be a better way to go with less overhead.  I started some initial work on it but quickly abandoned this side-project as I have no real glide (or even OpenGL) knowledge and didn’t have enough time on my hands to play around with it.

Around this time, we also separated the GameSpy browser code into a separate DXE for potential legal issues.  The GameSpy code was publicly released, but never officially GPL’d.  Using this method, other port authors could link against a gamespy.dll to add in the browser capabilities that connect to my GameSpy master server emulator (see QDOS branch for source code to that particular project).

Ggorts also came up with some code for us to be able to finally use the banked modes and Mode-X 320×240.  Though 320×240 Mode-X seems to have some issues with certain emulator configurations, for the most part it works OK.  This also helped us to get some ASM rendering code in from Q1 and help clean up the original mess that was the SVGA driver; a lot of unused code from Q1 was removed and sezero found a clever way to send the video modes list between the game binary and renderer DXE.

In any event, one night I figured I’d take a stab at trying to get Mesa working in Q2DOS.  Checking out the Mesa3d FTP and researching the various changelogs it appears as if Mesa 5 series was the last true effort with Mesa 6.4.x series being the last maintained version with 3DFX specific code.  I got everything to compile but ran into hard-lock issues no matter what I attempted.  During this time, ggorts found out some various small, but now obvious issues. Including increasing the stack size to 1MB and he hard-coded the ref_gl to only work in 640×480.  It took a lot of pleading but eventually he released his source with a static compile for Voodoo 1 cards only as he was testing this on emulators like DOSBox with glide support and PCem dev branch.

I worked on cleaning up the source and he produced some glide3x libraries for me for Voodoo 2 and Voodoo 5 as these were the only cards I personally owned.  Imagine my surprise as I first loaded it up and it actually worked!  And it was smooth with no rendering issues!

q2dos_3dfx_3

At this point, sezero became involved and worked very hard to clean up the Mesa compile issues, including various scary warnings and helped to update us to the final glide3x commit pushed to the development branch and Mesa v6.4.3 which was an unreleased maintenance update for Mesa v6.4.2.

It was a long journey to get the code all working together just right, and a big thanks goes out to the early Mesa crew including Brian Paul, Daniel Borca, and “KoolSmoky” and the mysterious ggorts fellow who pushed hard for this feature.

To recap, Q2DOS from the last time we talked now has:

  • 3DFX Rendering with Mesa v6.4.3 for all Voodoo cards.
  • Separated renderer so it is no longer statically linked.
  • GameSpy is now a DXE.
  • WAV streaming, which is practically free as opposed to the OGG format.

q2dos_3dfx_1
q2dos_3dfx_8

We are about at the end of our Q2DOS journey.  A few odds and ends with Mesa and Voodoo 5 SLI issues remain (though nothing too show stopping) and there’s a small wishlist of some unnecessary features but it’s come a long way from the initial null driver effort!

q2dos_3dfx_2*Neozeed

I have to say it is simply incredible to see how Q2DOS went from a very primitive ‘wow it works’ port to a full featured port.  Simply amazing!

For those who missed the adventure it starts in Part 1, continued in Part 2, Part 3 and Part 4.

Porting Quake II to MS-DOS pt4

Bringing it all home for release day.

Bringing it all home for release day.

Since the last update we got some help in a few fields that have really fleshed out this ‘experimental’ port into a full fledged port.  First RayerR helped us with the fun of getting us onto the latest deployment of DJGPP, 2.05 (rc1).  It’s always nice to be in the latest available release.  Next in a passing comment, Ruslan Starodubov had mentioned that he had gotten a much older build of our QDOS to support the Intel HDA sound chipset via the  MPXPlay sound library.  I wrote to the author of MPXPlay, Pádár Attila asking for us to distribute his source in our project, and he granted permission.

So at this point things were looking good.  The only ‘feature’ that modern OS’s really held over us was the ability to dynamically load and unload game modules on the fly.  I had tried to use DLM, but it stripped the DPMI functionality out of the MS-DOS Extender making the port really useless.  I tried to build the newer DXE3 support but had no luck.  I suspect now my native tool chain was interfering with the build process. But Maraakate managed to get it to not only build, but to run!

Adding in DX3 support was relatively painless.  I first looked at DJGPP’s FAQ and downloaded the example code.  In the example code there was small helper functions to make unions and check the symbols.  If they didn’t exist a printf was spit out to alert you about it.  To resolve the issue you simply just add DXE_EXPORT to the other list of missing exports.

Compiling the game code was easy, again referring to the example I saw that basically they compiled it the same, but at link time you use DX3GEN and -U flag to ignore unresolved symbols.

The biggest head scratcher was the Sys_GetGameAPI failing to find GetGameAPI from the DX3.  After some piddling around I noticed that it listed GetGameAPI as _GetGameAPI inside the DX3 itself.  I added the underscore and it worked!

Other things that were relatively to easy to import was R1Q2’s HTTP downloading code.  Compiling CURL was kind of tricky because of the linking order, but thankfully neozeed figured it out quickly.

All of Yamagi’s Quake 2 updated game DLLs were all diff’d by hand using BeyondCompare to make sure I didn’t clash using some newer functions that weren’t available in DJGPP.  I also merged their Zaero code with their baseq2 code by comparing Zaeros code to the Quake 2 SDK, marking every thing that was changed.  The result is a really stable Zaero game code.  If you haven’t played Zaero check it out.  I think it’s a lot better than Rogue, but Xatrix is probably my favourite (even over stock Q2).

Other cool things I’m glad to get into the code was the GameSpy Browser.  It took me quite a bit of work to get it where it is, but it’s really nice to just be able to ping to a master server (a custom GameSpy emulator I wrote specifically for Q2DOS.  Source is not finalized yet, but will be available soon for those curious), pick a server and go!  All in DOS!

So here we are at the end of the journey.  Or at least safe enough for a 1.0 release.

To recap, we have:

* VGA
* SVGA (LFB modes only)
* Mouse
* Keyboard
* SoundBlaster and Gravis UltraSound Family
* CD-ROM music
* OGG music
* Networking (You need a packet driver)
* Loading/unloading game DLLs in DX3 format.
* Intel HDA support -hda
* Mouse wheel support with -mwheel

And I should add, that it works GREAT on my MSI Z87 motherboard.

You can download Quake II for MS-DOS on bitbucket.  And as always the source is available here.

Don’t forget you can always make bootable USB stick with DOS, or CD-ROMs.

Continued in Part 5!

Random links

No I’m not dead, just been busy.

But here is some interesting things I’ve seen the last while:

Infer: static code analysis from facebook of all people.  Supports C, Objective-C and Java.

Dr Jack Whitham’s blog, with some interesting stuff related to compiler optimizations and how they alter floating point results, along with ‘bug 323‘, and some DOOM fun!  Plus he has his updated source repositories online here.

And finally, Building A 10BASE5 “Thick ethernet” network.  A fun look at the first gen ethernet cabling on ‘slightly’ newer machines.

Porting Quake II to MS-DOS pt3

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 :

__djgpp_nearptr_enable();

So naturally I would disable it when I’m done, making the call look like this:

__djgpp_nearptr_enable();
memcpy(vid_resolutions[whatmodearewe].address+__djgpp_conventional_base,vid.buffer,(vid.height*vid.width));
__djgpp_nearptr_disable();

Right?

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’

DLM call frame traceback :
0x0014dcaf SYM: _Sys_PageInProgram+0x37 DLM: q2.exe [0xf5000]
0x0014e1c4 SYM: _main+0x18 DLM: q2.exe [0xf5000]
0x0000774e
0x00008b6e

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!

Quake II running on MS-DOS

Quake II running on MS-DOS

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!

For those who care the bitbucket of the project is here, and binaries are here.

**UPDATE**

For anyone who is interested, I’ve updated the binaries, to include the latest version with built in quakespy technology!  Run an /slist2 and get a list of servers!

/slist2 in action!

/slist2 in action!

For the more adventurous trying to build from source, we are using GCC 2.95.3 and DJGPP 2.04.  All of the sub libraries that you need to build are already pre-compiled in source drop.

At this point the ‘alpha 2’ version contains:

  • VGA
  • SVGA
  • Mouse
  • Keyboard
  • SoundBlaster and Gravis UltraSound Family
  • CD-ROM music
  • OGG music
  • Networking (You need a packet driver)

Installing the packet driver will require a driver from the crynwr project.  You can find a description of some of the drivers here.  Sadly for new cards I think we are left in the dark.

I’ve also compiled a ‘server’ for Linux based on the code, and put it online @ 87.117.247.11:27910

Continued in pt4, and part 5.

Porting Quake II to MS-DOS pt2

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!

Quake II for MS-DOS running on Qemu connected to a dedicated OS X server.

Quake II for MS-DOS running on Qemu connected to a dedicated OS X server.

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.

Continued in pt3, pt4, and part 5.