Porting Quake II to MS-DOS pt4

Posted on by
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 everything 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!

15 thoughts on “Porting Quake II to MS-DOS pt4”

    • 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.

  2. 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.

  3. >Do you have a better shot of all the wires running to the card edge connector?

    vga card? least hassle is buying PCIE ribbon riser cable on ebay for $1.5 free shipping

    • 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.

  5. How to I get CD Music to work on this directly from the CD? I have DOSBOX SVN-Daum with the QII cd (in .bin format) mounted on drive D.

    • I would assume it would be something along the lines of this. The builds have support for MSCDEX, and all of that good fun.

      Although the ogg file support is much quicker/easier TBH.

      • Thanks! I finally got it to work. And it’s not hard at all.
        1. I just edited line one of QII.cue from “Quake II.Bin” to “QII.BIN”
        2. then mount .cue file to imgmount d: QII.cue -t iso

        Then it works like a charm! But could you support GPU acceleration? e.g. Like Glide? The game is a bit choppy. But it only drops the frames on waters etc.. But still choppy 🙁

Leave a Reply