Post navigation

Porting Quake II to MS-DOS pt4

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.

About neozeed

What is there to tell? I've loved UNIX like things since I was first exposed to QNX in highschool (we had the Unisys ICONS!), and spent the better time of my teenage years trying to get my own UNIX... I should have bought Coherent in retrospect.. Anyways latched onto Linux in 1992, and then got some old BSD admin books and have been hooked on the VAX BSD & other big/ancient things since...!

For me the online play is the ‘killer feature’ (pun intended). Now I just need to figure out what to do with this crappy “Killer E2200 NIC AKA Qualcomm Atheros AR8161” which seems to lack any real mode drivers.

Killer NICs used to be some weird stuff, but they’re bog standard Atheros now AFAIK. However, I don’t believe Atheros has any packet drivers or such. You may have better luck with Intel or maybe Realtek for Gigabit.

Maybe for network you would like to use a reliable Intel card with real DOS drivers in your machine, and for WLAN support just use a wireless bridge (any cheapo ebay Atheros crap router can become an useful WLAN bridge with the help of OpenWRT).

I really don’t recommend using any old wireless network card with DOS drivers, them only support B wlan protocol, and only WEP encryption.

The board has one slot. It’s occupied by the video card. The processor doesn’t have onboard video. So, DOS networking isn’t going to happen unless I write a driver. And that sounds like a lot of work… I’d probably just try to find some p4 throw away.

If you’re a bit hardware/electronic skilled guy you could take hot air gun and rip off the damned LAN chip and then reuse free PCI-E lane to connect some normal x1 LAN card. I did something similar when I connected PCI-E VGA card to 86Duino zero miniboard – it was only 3 twisted pairs + power and reset…https://www.youtube.com/watch?v=shlirczvcwg
Or maybe there it’s some better place to connect to unused PCI-E lane. Small MBs are good for connecting to TW and watch movies or so but for real work I prefer workstation with full size ATX board (and of course wits some PCI slots on it 🙂

Do you have a better shot of all the wires running to the card edge connector? I was always interested in doing that stuff. I’ve made a few adapters for a sega master system base converter for sega mega drive and that was like 30 or 40 wires and I used an old IDE cable, but man does it take a while to do it. I was triple checking the work as I did it.

Yes I saw some PCIE risers but not that one I exactly needed: a x1 female on one side and x16 female on other side. I saw only male-female configuration. I soldered the connectors out from some old MB and use few thin wires… In this case PCIE is a piece of cake and it’s fine it can automatically configure to different number of lanes. I wouldn’t like to do that on classic 32b PCI or even PCIX 🙂

I’m not sure how the lanes are connected between slots on MB, maybe it could be possible to split one x16 slot to two x8 slots. I don’t know how REFCLK signal is wired to slots – if it’s just common or every slot has some driver chip.