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!

Windows 3.0 Debug Release 1.14

Well from popular request I finally got around to loading this up.  I went ahead with my favourite retro emulator, PCem for this, as it can nicely emulate an EGA display, unlike most emulators which do VGA, however when it comes to older versions of Microsoft products they really can detect the difference between EGA and VGA.

So to start off, I downloaded from the project page, this version of PCem, compiled it, and installed MS-DOS 4.01 , from April of 1989.  The Windows 3.0 Debug Release 1.14 itself is dated from February 22nd, 1989.  Which I figured is close enough to the time period.  I’m using the 486SX2/50 because I’m too impatient for the 386 speeds, but it does work fine on 386 or higher emulators.  It does NOT work with any 286 emulation. I’m also using the HIMEM.SYS from MS-DOS 4.01 vs the one with the Windows 3.0 (Alpha? Beta? Technical Preview?) since it is slightly newer.

There is no setup program per say, rather it just xcopies all the files to a directory, and from there you run ‘d.bat’ and away you go.  This version is hard coded to an EGA display, which again is the reason I went with PCem.  Once you start it up, you are greeted with:

Win

Windows v3.0 Debug Release 1.14

And it identifies itself as Windows Version 2.1

w

Look at all the memory!

And first thing to notice is that on my setup with 8MB of ram, I have over 6MB of RAM free.  Compare this to regular Windows 2.1 which gives me 399Kb of ram in my current setup.

Windows 2.1 running in real mode

Windows 2.1 running in real mode

And with Windows/386 Version 2.1 it provides 383Kb of real memory, along with 6.7MB of EMS memory, as the Windows/386 Hypervisor includes EMS emulation.

Windows/386 memory

Windows/386 memory

Of course the major limitation of Windows 2 is that it runs in real mode, or in the case of Windows/386 an 8086VM.  As I mentioned a while back in a post about Windows 3.0,  This was game changing.

As now with Windows running in protected mode, all the memory in my PC is available to Windows, and I am using MS-DOS, with nothing special.

Besides the limitation of being EGA only, the Debug version of 3.0 is that there is no support for MS-DOS applications, as WINOLDAP.MOD is missing.

NO MS-DOS for you!

NO MS-DOS for you!

This is clearly an interim build of Windows 3.0 as mentioned in Murray Sargent’s MSDN blog Saving Windows from the OS/2 Bulldozer.  As mentioned from the article they began their work in the summer of 1988, so considering this is early 1989 it shows just how much progress they had made in getting Windows 2 to run in protected mode.  Along with Larry Osterman’s MSDN blog post Farewell to one of the great ones, which details how the Windows 3.0 skunkworks project was writing the new improved 386 hypervisor, and how Windows 3.0 got the green light, and changed the direction of not only Microsoft but the entire software industry.

I’ve been able to run most of the Windows 2.1 applets, however I’ve not been able to run Excel 2, or Word 1.  I suspect at this point that  only small memory model stuff from Windows 1 or 2 is capable of running.  Although at the same time, when 3.0 did ship, you really needed updated versions of Word 2 and Excel 3 to operate correctly.

Windows 3.0 Debug Release 1.14

Windows 3.0 Debug Release 1.14 on a 12MB system

The applets from Windows 2.1 seem to work a LOT better than the one from Windows/386 2.1 if that helps any.

This is an interesting peek at an exceptionally early build of Microsoft Windows.

PCem

PCem v9

PCem v9

From the main page:

PCem v9 released. Changes from v8.1 :

  • New machines – IBM PCjr
  • New graphics cards – Diamond Stealth 3D 2000 (S3 ViRGE/325), S3 ViRGE/DX
  • New sound cards – Innovation SSI-2001 (using ReSID-FP)
  • CPU fixes – Windows NT now works, OS/2 2.0+ works better
  • Fixed issue with port 3DA when in blanking, DOS 6.2/V now works
  • Re-written PIT emulation
  • IRQs 8-15 now handled correctly, Civilization no longer hangs
  • Fixed vertical axis on Amstrad mouse
  • Serial fixes – fixes mouse issues on Win 3.x and OS/2
  • New Windows keyboard code – should work better with international keyboards
  • Changes to keyboard emulation – should fix stuck keys
  • Some CD-ROM fixes
  • Joystick emulation
  • Preliminary Linux port

Thanks to HalfMinute, SA1988 and Battler for contributions towards this release.

Very excellent!

MS-DOS Player updates

Poorly translated from TAKEDA toshiya’s blog..


2014/4/15
I has integrated source of i386 and i286 edition edition. 
In addition, in the i286 version, I added support for int 10h/16h. equivalent to 0.149 MAME, I was replaced with a 0.152 equivalent MAME core i386 i286 core. However, the i386 core, I have omit the TLB around.

Which is very cool, although I wasn’t sure about the MAME source code being open to other projects…?  I tried to contact the i86/i386 author vlinde but he then pulled his contact page.  I wanted to use i386 for something of my own, but the whole “Redistributions may not be sold, nor may they be used in a commercial product or activity.” really puts the damper on it.

I was able to get some simple XMS test program to run, but nothing of any substance.  No DOS4G/W or anything like that.  But if you re-build it specifying MS-DOS version 5.0, some of the MS-DOS utils and even command.com work!

The weird issue I had was running out of conventional RAM, because this program gives you nearly 1MB of conventional RAM… I was surprised, as I wasn’t expecting that much!

Terminator Rampage.

terminator rampage front

Terminator Rampage

Back in October of 1993, this cool looking game, The Terminator Rampage was released.

But sadly I had a lowly 4MB 386sx-16 with CGA, so things like this game with it’s awesome VGA graphics were an impossibility.

Even more sad at the time was that ‘primitive’ 3d games like wolfenstein 3d also required VGA.

But as we all know a few short months later, DOOM was released, and then Terminator Rampage was quickly swept off the face of the earth.

I recently came across this page,  and I thought I’d give it a shot.  The requirements are pretty ‘minimal’:

  • Minimal 386DX-25 with 4MB of Ram, VGA & 18MB of disk space
  •  Recommended 386DX-33 or 486DX-33

So I was thinking Qemu could easily run this game.  Long story short, it doesn’t work.  Turns out Rampage needs EMS.  And for whatever reasons, running emm386.exe on Qemu (I tried a handful of versions) just crash on Qemu after initialization.  Failing with stock Microsoft EMM386, I tried JEMM, which loaded, and ran it’s built in EMS diagnostics OK, but trying to run Rampage resulted in a nice crash.

Qemu crash

Qemu crash

So giving up on Qemu, I tried it on DOSBox.  It runs but it is incredibly jerky.  So I thought I’d try PCem, and see how it runs there.

So the plus side is that PCem, is able to run MS-DOS & EMM386.EXE without issues.  It only took a few minutes to install MS-DOS 5.0 and Rampage on my ‘virtual’ 486DX2/66 with 8MB, of ram, and load up Rampage to be greeted with it’s jerky motion.

Thinking its something with emulation in general I fire up Norton SI to get some PCem scores how it benches against known good samples.

pcem 8.1 386DX33 Norton SI score

386DX-33Mhz 37.4

pcem 8.1 486DX2-66 Norton SI score

486DX/2-66Mhz 136.8

pcem 8.1 WinChip90 Norton SI score

WinChip-90 186

Then comparing the scores to this handy (if not ancient) Norton Si benchmark spread we see:

Pentium 60mhz
=============
IBM Clone               P5/60              256k              187.2
w/ Premiere MB

486 DX2/66mhz
=============
Elitegroup (ECS)       iDX2/66             256k              147.3
SA486P AIO-II
INTEL CDC,SIO&DPU

386 DX 33mhz
=============
Forex 36C100 iDX/33 128k 35.9

Well now that interesting, so at a ‘raw’ CPU level, PCem is delivering on what would be classical performance.  So for the heck of it, I load up DOOM, and it runs a bit choppy on the 386, but flies on the 486 & Winchip emulation.  Now that is strange.  And just to confirm…

Terminator Rampage Box (back)

Terminator Rampage Box (back)

They really thought this would be playable on a 486 @ 33Mhz.

So how does it choke?  While going straight is ‘ok’ turning around is so utterly sluggish that there is no feeling of immersion.  It feels like you are driving an incredibly slow tank.  At the same time, the more realistic sprites, and textures serve to make it look even more unrealistic.

So what am I talking about?

Well here is a screenshot of Wolfenstein 3d on the 386DX-33 (and more than playable).

Wolfenstein 3d

Wolfenstein 3d

As you can see, there is no ceiling, and no floor textures.  The walls are all uniform height, and the textures were clearly drawn by hand, giving it a very fake and ’16bit’ feeling.  I should also add on a capable 286, this game is playable.

Terminator Rampage

Terminator Rampage

Now at first it looks like it has a lot in common with the soon to be release DOOM, with textured ceilings and floors.

Doom

Doom

Now as you can see the difference in DOOM is the 2.5D effect of there being lower areas so you can go up and down stairs (while you cannot go under them).  Also Doom introduces dynamic lighting, and better sound rendering.

While I do like Rampage’s upfront map, as you can see thought, it is very square. In a small effort to ‘speed’ up Rampage you can turn off the ceilings and floors revealing a very Wolf3d like environment.  Unfortunately the more they tried to give the world  detail, the more it well just looks flat.

No ceilings, No floors.

No ceilings, No floors.

Which kind of kills the whole thing.  Maybe they should have left out things like water fountains.

High detail sprites

High detail sprites

Then you get things like this computer setup (one of the programmers? The accountant’s lamp is a nice touch) but it’s a sprite, so as you rotate around it, you always see the same face.

Ironically it’s these high resolution background sprites that make the environment feel less real, as they make the rooms feel too open, and too sparse.

Too open, and yet too sparse

Too open, and yet too sparse

It is the real paradox that in a good shooter you have lots of room, and things to duck behind, but the rooms feel too large, and look bizarre with the massive open spaces.  But it is more so a limitation of the time, with the engine being more of an improved Wolf3d engine, than taking a larger leap into being something more 2.5d or 3d like Doom (or the distant Quake).

Another thing that really bugged me was the doors.

Doom door

Doom door

In doom, the doors felt more ‘natural’ in that they weren’t super wide.

Screen Shot 2014-04-28 at 10.44.09 PM

Generic office door in Rampage

But in rampage they are stretched wide giving the impression of why you can’t turn is you are incredibly wide..

Screen Shot 2014-04-28 at 10.43.16 PM

Rampage ‘exit’ door

Even the ‘exit’ door texture still feels too wide.

I could probably get by the empty spaces, but it takes so long to turn around, and the controls feel so unnatural (they don’t even try to be a Wolf3d control-a-like) that it really feels klunky.  No matter what speed you play it at.

It really was an exercise in frustration.

Qemu 1.7.0 released!

The main qemu page hasn’t been updated yet, but the download page has the source to the new version of Qemu.

I’ve gone ahead and built binaries for OS X, both a full version, and  a i386 minimal version.

As always testing is very minimal, all I’ve done is installed MS-DOS 6.22 & Doom 1.1, and tested the SoundBlaster 16 emulation.  And as with the pre-release versions, the adlib code is still broken.  And Ive done the ‘better’ fix in this code regarding that.

I haven’t run anything else, including fun things like the PowerPC & OS X emulation, MIPS with Windows NT, or even trying anything x64 based as I’m sure it is still broken from back in the Qemu 0.90 days.

Virtual Xenix & the internet

This is probably the most significant Xenix post I’ve made since the old days when I managed to get Xenix running in Qemu all those years ago.

3com network card

3comB network card

What has long been a frustration with the beleaguered Xenix community is that although there was a TCP/IP package for Xenix (and a much required streams package…) it only worked with a handful of ethernet cards.  And all of them were early 3com’s.  While the world was using NE2000’s on just about everything, the most common ethernet board Xenix would talk to was the 3c503, which is getting harder and harder to find as the years go on by.

But right now none of this matters.

I was looking at this article on setting up Apollo Domain UNIX, on MESS.  And apparently it will do networking!  Which is cool, so I poke around MESS, and what do I see? 3c503.c. Could it be true?

Now I ended up having to download the source to mame 0.151 (mame0151s.zip) and building it on OS X.  Of course remembering to alter the makefile to include the ‘USE_NETWORK=1’ statement, and build for Mess.  And just as it looks like something out of SIMH, Mess makes use of libpcap which means that you are *unable* to send/receive on the host computer. (OS X & Win32 binaries).  And of course you’ll need a ROM & Xenix diskettes.

Installing Xenix is pretty straightforward as long as you know your system key, and how to navigate the mess UI without rebooting mess or exiting by mistake (scrolllock on the PC, function/Delete on OS X).

First create a hard disk, and as always it should be ~500MB max.

chdman.exe createhd -o xenix.chd -chs 1015,16,63
chdman – MAME Compressed Hunks of Data (CHD) manager 0.149u1 (Aug 10 2013)
Output CHD: xenix.chd
Compression: none
Cylinders: 1015
Heads: 16
Sectors: 63
Bytes/sector: 512
Sectors/hunk: 8
Logical size: 523,837,440

then with the disk in hand, I just setup a 486 like this:

./mess64 at486 -harddisk1 xenix.chd -isa2 3c503 -ramsize 8388608 -floppydisk1 xenix/n1.vfd

Naturally you’ll need to setup the CMOS, for your memory size, and the hard disk.  The BIOS I’m using didn’t autodetect the IDE drive, but it doesn’t matter as I know it’s characteristics as I created it.

From there Xenix was a pretty straight forward deal.  Mess has good floppy drive emulation so it just worked.  Adding TCP-IP was just as involved, and all went well.  When it came time to install TCP & the network driver, remember to use thinnet, as the thicknet transceiver isn’t connected (as it would seem).  The 3c503 is softset, so I went with IRQ 5, port 0x300, and thinnet, and it works fine for me!

mess xenix networking

Xenix TCP/IP in action, inside of MESS!

Remember you will not be able to attach to it from your computer.  Instead you must attach from another computer.

Also MESS tries to emulate true to hardware so it’ll be just as slow on MESS as it was on the real hardware.  I suppose you could go with the at386 driver, but yeah it’ll be slow.  The current at586 driver has issues booting from the hard disk, and I didn’t mess with it too much as Xenix is known to have issues with some Pentium systems.

Although I think the next place for adventure is the emulated Adaptec 1542CF.

Booting from USB in VMware Workstation

(note this is a guest post from Tenox)

Jason’s note on hybrid bootable ISO reminded me of a recent discovery. I have a bootable USB pen drive that I wanted to boot in VMware Workstation. Normally impossible, but there always is a work around! Turns out the problem is with the VMware built-in BIOS and more specifically lack of USB boot support. All you have to do is get a bootable media, floppy or CDROM with a boot loader that can redirect you to the USB device. I’m using Plop. Important thing to remember is to connect the USB pen drive to the virtual machine in a pass through mode. Also it’s very very slow.

Everyone mentioned this yesterday…

275,000 transistors of awesomeness!

275,000 transistors of awesomeness!

Kind of interesting is that Linux has finally dropped support for the 80386 microprocessor.

The 386 is perhaps one of the top ten things that has changed our world, along with 4.3BSD .

No, really!

The 386 microprocessor was the first CPU by Intel that was single sourced.  This means that Intel, and only Intel would fabricate the 386 processor.  Before this time, Intel had licensed their processors to other companies (Siemens, AMD, Harris, IBM etc) So that if there was some kind of production issue at Intel other companies could manufacture 8086,80186s and 80286s.  However this all changed with the 386, as Intel stopped renewing these agreements with other companies (IBM had a license that included the 386, although they were slow in making their own), so now Intel was in charge of its destiny.

The 386 brought three major changes onto the then champion processor the 286.  The first being a 32bit processor where it could handle larger data sizes than the 16bit 286 & 8086.  The 386 also included a larger memory model, the so called “flat mode” where it could directly address 4GB of combined code+data, while the 286 could address 1GB it was limited to 64kb segments.  Lastly the 386 introduced hardware virtualization, the “v86” mode where the 386 could emulate multiple 8086 processors, allowing people to have multiple ‘virtual machines’ on the desktop.

At the time the only consumer grade 32bit processor was the hybrid 32/16 68000 from Motorola.  The 68000 could work with 32bit data, but it was restricted to a 16bit data bus, and only could address 24bits of RAM (16 megabytes).  The 68000 however did not include any kind of memory management unit (MMU) making things like porting UNIX improbable (The SUN-1 workstation included a custom MMU).  Because of the open nature of the IBM PC, clone manufacturers were able to leapfrog IBM, and release 386 based machines before IBM got around to releasing the PS/2 model 80.  It was this that effectively brought 32bit computing to the masses with the Compaq Deskpro.

Compaq's 386 Deskpro

Compaq’s 386 Deskpro

The 8086 processor could address 1MB of RAM, with its 20bit address bus.  However to preserve some compatibility with the 8080 processor it was decided that the 8086 (and 8088) CPUs would work with 64kb segments.  This became a massive headache for years as you could not easily contain more than 64kb of data at a time as you would exceed a segment.  Compiler vendors made some workarounds via the large & huge memory models, but porting a program from a 32bit minicomputer (VAX) would prove difficult if it addressed large amounts of memory, and would require a rewrite.  The 286 increased the addressable memory to 16MB, and included a limited MMU, which enabled an address space of 1GB.  However the 286 was flawed in that again the 286 could only work in 64kb segments, and in order to work with large amounts of memory, the processor had to be shifted to protected mode.  However in protected mode, you couldn’t (easily) switch back to real mode.  This needlessly delayed the adoption of protected mode environments, as you would then lose access to the sizable, and growing, library of MS-DOS programs.  Although workarounds were in place for things like OS/2 and DOS Extenders, they were hacks and couldn’t fix the fundamental 64kb issue.  The 386 built upon the 286’s foundation and included a flat memory model where it could address all 4GB of addressable memory in a single segment.  This meant that you could now use massive amounts of data on a consumer grade machine.

For a while the only 32bit environments were Xenix and MS-DOS via DOS Extenders this proved to be a huge liability and effectively stagnated the industry for a long while.  The 286 was a massive determent.  Making things worse was IBMs insistence that the new OS/2 be able to run on the 286, while Microsoft wanted to create OS/2 to run on the 386, and ignore the IBM AT all together. Basically the 286 was created with the assumption that the 8086 wouldn’t be anywhere near as popular as it was.

With the ability to address large amounts of RAM programs only seen on minicomputers and mainframes were finding their way to the microcomputer such as AutoCAD, Oracle, Links 386 Pro, and of course many in house programs where departments now wouldn’t have to pay to run on then ‘big’ minicomputers.  Combined with the 386’s MMU it was also possible to use more memory than was available in the computer, also known as virtual memory.  The 386 made this transparent to the program, only the 32bit environment needed to handle the swapping.

Finally the last big feature of the 386 was v86 mode.  V86 mode in short is a hardware virtualization platform where the 386 can emulate multiple 8086 processors in hardware.  Each virtual machine can get its own isolated memory space, virtual hardware.  Effectively 8086 programs (such as MS-DOS) can run unaltered inside of v86 mode, with the added benefit of being able to run more than one at a time. Windows/386 lead the charge into this new world of virtual machines for the end user.  Before this point, the only wide scale virtual machine environment was the IBM 370 mainframe which could also create virtual mainframes within itself allowing groups to share a single mainframe, but run incompatible software platforms all at the same time.

Thanks to its capabilities the 386 also brought UNIX to the end user.  First with Xenix, then Microport SYSV, and with the removal of AT&T code BSD was able to be released on the 386 via 386 BSD (and later BSDi’s BSD/OS).  During this timeframe the research OS, Minix was extended by Bruce Evans to be able to use some of the 386’s features which then gave rise to Linux.

Thanks to cheap commodity based 32bit computers, and the GNU projects development tools (binutils, gcc, bash) people could then finally realize GNU’s dream of bringing a free and open UNIX like operating system to the masses.

Needless to say, a lot has changed since 1991, and Linux now moving beyond the 386 processor is no surprise.  The rapid adoption of 64bit computing via AMDs extensions, and the new forthcoming 64bit ARM processors do signal the eventuality that one day Linux will even drop support for 32bit processors… Although I wouldn’t expect that for another 20 years.  Even Intel has ceased manufacturing the 386 processor in 2007.

So it is now time to say good bye to the 386 processor.  At the same time thanks to full software emulation, you will never truly be dead. And as always you can check out Linux’s early versions.