VMWare Fusion 3.1 & KOTOR

Well let me be the first to say this is a little “modern” compared to all of my prior stuff, but anyways I’ve been enjoying life under OS X the last few days (along with crunch time @ work.. .sigh). As part of my day job I do still have to maintain some MS-DOS & Windows stuff, so while I do run Qemu under OS X, I’ve also purchased a copy of VMWare Fusion 3.1 (available online, and as a 30 day eval!). Ok so it’s $89 with the one year support, pretty snazzy stuff.

Now one thing that I find very interesting, is that unlike all the other more expensive versions of VMWare, Fusion for the MAC allows for SOME 3d apps to run!

I’m still kind of amazed at the stuff that does run and how cleanly it does so.

So I’ve installed good old Windows XP in a VM, then tried Fallout 3. No go. For the hell of it I tried Sims 3, and surprisingly it worked.. Even though it’s silly as there is an OS X version available.

So for today (I think it may be over in a few hours….) Steam is selling Star Wars Knights of the Old Republic for $2.50 USD!

Now KOTOR has been kind of finicky about what machines it’ll run on, in the past, but I have to say, much to my surprise the emulated 3d hardware ran KOTOR out of the box, without any modifications or anything!

So here it is, KOTOR in a ‘window’ on Windows XP in a Window on OS X.

KOTOR under XP VMWare Fusion in a window windowed
KOTOR under XP VMWare Fusion in a window windowed

And it’s playable at 1024×786.. and 1280×960, although at higher resolutions I’ve had issues with the mouse tracking.. .perhaps something about hardware/software mice support?

Anyways, emulation has now come to the point where 3d stuff really does run!

Duke 3d & the Build engine

Well I was looking at some stuff on old games, and naturally everyone always did love Duke Nukem 3D!

Now what is really cool, is that that the guy behind the build engine, Ken Silverman released the source to the ‘build’ engine, but also some of the builds of build as it progressed.

Ken is a big fan of QuickBasic, so to compile his earliest version, you’ll need QuickBasic 4.5, or the QBasic that came with MS-DOS 5.0 and above.

Download picrot4.bas, and run it through basic, and you’ll get this:

Qbasic 'Build'
Qbasic ‘Build’

Under some emulators (Virtual PC) you’ll get a corrupted screen at first, hit any of the arrow keys, and it’ll redraw the screen into what it should look like. Considering the 8kb of basic code includes the engine, and the map it’s pretty snazzy!

You can find the timeline, and other versions of the build engine as it progressed on Ken’s web page.

As the engine improved, and was ported into C, it only got better! Then it was sold and licensed out, which gave rise to great games like 3D Realms Duke Nukem!

Notice the similarities?
Notice the similarities?

After the build engine went open, 3D realms followed up, in releasing their extensive modifications to build which can be found here.

In the off chance you don’t have the game, you can still get the shareware version of it from 3D Realms here, and of course the full version on Good Old Games for $5.99 USD.

With the release of Build & Duke 3D, it’s only natural that they shed their humble MS-DOS beginnings and found their way onto Windows as full Win32 applications taking advantage of the hardware. Thanks to the work of Ken & Jonathon. You can find the results on Jonathon Fowler’s page here.

I suppose later I’ll have to see if it’ll build with the win64 tools… It’s be neat for a 64bit version of Duke!

Doom for UnixWare

Doom on UnixWare
Doom on UnixWare

I’d never actually built Doom from source before… It was more involved then Quake, or maybe I’ve done Quake too many times? Anyways one thing that stuck out to me, is that you HAD to define NORMALINUX, or it wouldn’t pick up wad files or much of anything…

I guess other then that, I didn’t even try for sound… As a matter of fact, I think I’m pretty much done with UnixWare, but at the same point it’s a little more ‘fun’ then I found it.

UnixWareDoom.tar.gz

Some notes on UnixWare

A long while back, I got this UnixWare 7 kit on ebay.. So I figured it was as good a time as any other to install it and give it a whirl…

Now one cool thing is that 7.1 will install on Virtual PC 2007, and runs quite nice.. The one trick is to not give it too much memory. I found that 1GB of ram made it run horribly, while 256MB had it running great.

Another weird thing is that if you suspend the VM for any reason, the network will stop working. The only fix is to reboot the VM. Also

Also the C compiler, while not the most feature rich one out there is amazingly fast.. It builds Quake in around 5 seconds, once all the source is ‘fixed’. Also if you want to build any X11 programs, be sure to install the linux compatibility, or have a handy source of X11 headers to grab, as for some reason my UW7 didn’t include them.. ?

So yes, with a bunch of tweaks from the SUN source version of QuakeWorld, here it is:

Quake-on-UnixWare

Quake 1 for UnixWare 7.

And naturally it’ll run Dungeon as well with some f2c magic. The only caveat is that you can’t build the libf2c with any optimizations or it’ll crash or give really strange results….

Dungeon 2.5.6 on UnixWare
Dungeon 2.5.6 on UnixWare

Dungeon 2.5.6 on UnixWare.

Other then that, UnixWare is just another SYSV wrapped up in CDE. But I do recall it being used in the call center world, in conjunction with some seriously old unix machines (think NCR 386!), mostly doing voicemail and other stuff. I think it was the UnixWare 2.x stuff that all included that PC emulation software that could run Windows with the Netware client.. OH the horrors of someone loading up that and lotus notes to check mail on the VM server.. people did notice!!!!!!

I’m not sure if people still use UnixWare with Avaya G3’s anymore.. I know the G3’s were busy moving to linux, but I don’t know about all the support stuff, so for all I know CMS & friends still run on Solaris/UnixWare.

It’s a shame UnixWare got a bad rep from the SCO lawsuits, as it’s a pretty fast & responsive Unix, and too bad they never did get it ported to the Itanium & x64. I mean it’s still not too late, but I suspect the required investment to make it happen is just too great.

pcap and IPX/SPX

I found this link where someone had implemented a virtual NE2000 for DosBOX, allowing you to run among other things DOOM!

This reminded me of my own work to add pcap into Qemu back in the 0.9.0 days… SO I figured I’d try to build the thing out and see how they interact!

So the first thing to do was build DosBOX, and add the patch. I found that 0.73 worked pretty well for this!

So after some hammering around, I got it to build, and launched it on two separate machines (one over terminal server) on my lan, and launched the oldest network doom version I could find to get things going.

Doom multiplayer IPX-SPX
Doom multiplayer IPX-SPX

And there we go. Now in the dosbox.conf you have to make sure that they have unique MAC addresses, and of course, that they are bound to the correct physical nic. in the config file, there is a list option that will print out the possible choices then you can just put the number, or the full name into the right spot on the ini file. I’ve build a prebuilt win32 version of this with all the DLL’s and the gravis ultrasound enabled… You can download it here.

The next thing I did was search high & lo for my patches to Qemu, and thankfully I’d emailed them to myself as it seems all the other places are dead… So with a little playing with Qemu 0.90 to enable the adlib, and remove some logging messages, I’d built a client machine again with Doom. Naturally I had the DosBOX & Qemu face each-other off.. Sadly this is a little SLOW.

DOSBox and qemu IPXSPX Doom
DOSBox and qemu IPXSPX Doom

For those that wish to download, you can find the Qemu client & server files.

Now for Qemu, you’ll need to get that full NIC name… Dosbox provides a great way to see what it is, just paste it into the batch files, and you’ll be good to go.

And remember you’ll need WinPcap installed!!!!!!

BSD-games & Solaris fun.

I was getting bored with a stock Solaris 2.4 system, so I decided to load up some basic BSD games. Since I like the torture of it, I went to build them from source.

OH MY GOD.

I don’t mean to complain too much, but holy crap, the configuration for the BSD games package is INSANE.

After answering what feels like 100+ questions (it very well may be) you can eventually try to build BSD-games… but much to my dismay the 2.x series all hinges on you basically having a GNU environment, and well… I didn’t want to spend that much time just to run robots & fortune.

So thanks to this great page, there is some hints on building BSD=games 1.5 for Solaris… But where on earth to find something this old?! This is the weird thing, all of this older free software is being destroyed wholesale… I know right now people just don’t care, but there most certainly is this ‘digital’ divide that is coming, where most of our current history will be lost forever… Hell if nukes fell tomorrow, good luck to anyone decoding a DVD… And god help them if they succeeded. It certainly wouldn’t be worth the effort.

Anyways, with a bunch of searching I found a site in Germany with the goods.

Now the real fun starts…

I’m using gcc 2.8.1, because that is what was in the GNAT package. Anyways for some programs I was encountering errors like this:

gcc extern.o init_field.o main.o make_level.o move.o move_robs.o play_level.o query.o rnd_pos.o score.o flush_in.o -lncurses -lnsl -lsocket -L/usr/ucblib -R/usr/ucblib -lucb -o robots
Undefined first referenced
symbol in file
_tty main.o
_pfast main.o
_echoit main.o
_tty_ch main.o
_rawmode main.o
ld: fatal: Symbol referencing errors. No output written to robots
make: *** [robots] Error 1

I know.. .WTF?! So after building & rebuilding ncurses, I found on some obscure Fortran list that the linker in Solaris is… weird. So to save anyone the hell, here is the “correct” string in this instance.

gcc extern.o init_field.o main.o make_level.o move.o move_robs.o play_level.o query.o rnd_pos.o score.o flush_in.o -L/usr/ucblib -R/usr/ucblib -lcurses -ltermcap -lucb -lncurses -o robots

Notice the difference? Yeah, the big one, is that now it linked. The position of the -L & -R really matters to the SUN linker.

Another error I was getting (in this example from tetris) was this:

In file included from screen.c:59:
screen.h:62: parse error before `__P’
screen.h:63: parse error before `__P’
screen.h:64: parse error before `__P’
screen.h:65: parse error before `__P’
screen.h:66: parse error before `__P’
screen.h:67: parse error before `__P’
screen.h:68: parse error before `__P’

I assume in the future (or was it the past?) that this __P macro would be standard with GCC? Maybe it’s a linux-isim? I don’t know. What I do know is this block

#undef __P
#ifndef __P
#if __STDC__
#define __P(protos) protos
#else
#define __P(protos) ()
#endif
#endif

Will fix it.

Another weird error revolves around setjmp.h . Now I know in Solaris some headers have to be included in a certain order or all hell will break loose, or the part you are looking for just won’t be included. But I just mined out the relevant parts to get what I wanted…

In file included from /usr/ucbinclude/setjmp.h:44,
from screen.c:47:
/usr/include/sys/ucontext.h:24: parse error before `sigset_t’
/usr/include/sys/ucontext.h:24: warning: no semicolon at end of struct or union
/usr/include/sys/ucontext.h:25: warning: data definition has no type or storage class
/usr/include/sys/ucontext.h:28: parse error before `}’
/usr/include/sys/ucontext.h:28: warning: data definition has no type or storage class

So I just removed the reference to setjmp.h & instead put in this:

#define _JBLEN 10 /* ABI value */
typedef int jmp_buf[_JBLEN];

And it was happy. Now I know this is a HORRIBLE “FIX” but heh, sometimes you just want the dammed thing to compile!

Next I was getting these weird sigset_t errors…

screen.c: In function `stopset’:
screen.c:238: `sigset_t’ undeclared (first use in this function)
screen.c:238: (Each undeclared identifier is reported only once
screen.c:238: for each function it appears in.)
screen.c:238: parse error before `sigset’
screen.c:242: `sigset’ undeclared (first use in this function)
screen.c:244: parse error before `)’

And again I just mashed in the definition of:

typedef struct { /* signal set type */
unsigned long __sigbits[4];
} sigset_t;

Lastly was another error revolving around sig_t … So just inserting this:

typedef void (*sig_t) (int);

Into the code, got it to stop complaining.

So the upshot is that after manually linking a bunch of these programs, and manually installing the binaries & datafiles (Solaris 2.4’s install doesn’t work the way BSD-games 1.5 expects…) I finally could do this:

UNIX(r) System V Release 4.0 (solaris24)

login: rootb
Password:
Last login: Sat Dec 12 19:01:49 from qemunat
bash# fortune
There can be no twisted thought without a twisted molecule.
— R. W. Gerard
bash#

Now the big question…. Was it worth it?

Yeah sure, I learned a valuable lesson about the linker. The rest, not so valuable.

Frotz on Xenix

Well after having some fun with gcc, I wanted to try something a little more… “fun”. I’ve had good luck in the past with ‘dumb frotz‘ on the old BSD stuff (4.2/4.3 etc) but surprisingly I had no luck at all with gcc & xenix.

Well that was rather odd.

So in some crazed attempt I tried the regular version of Unix Frotz 2.32. Xenix was lacking the memmove procedure, but thanks to an old post here, I was able to get it running under Xenix.

Ok, fair warning it is SLOW. It’ runs the cpu into 1.0 levels… I don’t know why. My attempts at building gdb and using it from that old Soviet site hasn’t met with much luck.

Oh, and it was easier to massage some make files with gnumake.

But it does run!

If anyone want’s to give it a whirl it’s available here.

Dungeon on the DEC Alpha

I forgot to mention this, but f2c built, although there is probably some error with the floating point… I’ve had issues building f2c on OSF/1 on Alphas a while ago….

Anyways it can be found here.

One day I’ll have to try to debug the floatlib on the Alpha to see why f2c freaks out….

 

But then again, who still uses DEC Alpha’s?

Well today I got my new Dec Alpha running!

Ok, my friends say I’m insane to have bought this… but I couldn’t resist.

It’s a DEC Alpha 221164 machine, with 64MB of ram, and a 4GB disk!

It’s the best technology of 1996-1997!

So I’ve gone ahead and installed Windows NT 4.0 on the beast… at 600Mhz it’s pretty dammed fast… considering how old it is. Although I suspect a Pentium III I found in the garbage with a 1Ghz cpu is 2x faster…..

But at any rate, this is a DEC Alpha, the long time geek cpu of dreams etc…
What makes this slightly useful for me, is that I do have Visual C++ 4.0 & 6.0 for the Alpha. So at least I can build *SOME* stuff to run on the thing….

So I’ve been fighting the compiler, and it seems it’s default blended optimizations do *NOT* work on my machine.. I’m sure this will be fun down the road. However it seems setting the target cpu to the 21064 produces ok code.. I’ve got to bench the stuff, but at least my exe’s are not crashing.

So what have I manage to produce today so far?

Well…

unzip is a major one.. It’s hard to use a machine today without it.

The other thing I’ve manage to get running, is Quake! I’ve included my source & project trees as it was a feisty little thing to build..

I’m currently building & testing over terminal services so I don’t know what the speed is on the console… Also, this build does not include networking… I’m sure the winsock code will work just fine, I’m just not in a good position physically to test it, as Quake1 will *NOT NAT* correctly.. Also the SDL sound doesn’t actually output anything, so I’ve built it with the null sound driver..

I’d love to get that m68k->C build of frontier elite to go on the Alpha but I’m afraid my 64mb of ram will be a major constraint..

I know this isn’t much of an emulation thing, as the only emulator that possibly can run Windows NT for the Alpha costs upwards of $16,000 USD… It’s cheaper to score an alpha on ebay for $100 USD.

Well here is the screen shot…

Quake on the Dec Alpha

 

I know it’s not much to ‘look’ at, but the pallet is correct, because it’s a real Alpha!.. Unlike the MIPS thing.