## OpenWatcom for the DEC Alpha

Someone had contacted me about running some Fortran programs on the DEC Alpha with Windows NT. Now I know that DEC had released some compilers for the Alpha, the Digital Visual Fortran thing which some people still sell for around \$600 USD.

OUCH.

But luckily a friend mentioned that I should look at the source code for Open Watcom.

So, I figure for the hell of it, I’ll show how to build a Dec Alpha cross compiler for both C & Fortran. First I’m using Open Watcom 1.8, the current ‘release’ version. You are on your own for older or newer versions.

First install Open Watcom 1.8, with whatever your host is (I’m running on win64, so I’m using the win32 install), and set the target for 32bit NT. We will need the headers so this is the easiest way to ensure your Watcom can make NT exes.

Next you are going to need the file owaxp0401.zip. This is a pre-compiled version of the compiler & libraries for the DEC Alpha. All we need from this is the libaxp directory, which you can just unzip to your Watcom directory.

Now we’ll need to copy some files to satisfy the build process.

C:\WATCOM\binnt>copy wcl386.exe bwcl386.exe
C:\WATCOM\binnt>copy wlib.exe bwlib.exe
C:\WATCOM\binnt>copy wrc.exe bwrc.exe

Ok, now with that out of the way, run c:\watcom\owsetenv.bat to setup your environment, and now let’s extract the source to 1.8. I’m just going to use c:\temp as a place to put it. Also you will have to edit the setvars.bat file, and change the following:

set OWROOT=c:\temp\ow18src
set WATCOM=c:\watcom
set DOC_BUILD=0

Now I suppose you could save this into a batch file, and kick that off, and this will build the needed libraries, then the C compiler.

cd c:\temp\OW18src\bld\builder\nt386
wmake
cd c:\temp\ow18src\bld\dwarf\dw\osi386\
wmake
cd c:\temp\OW18src\bld\yacc\nt386
wmake
copy yacc.exe \WATCOM\binnt\byacc.exe
cd c:\temp\OW18src\bld\re2c\nt386
wmake
copy re2c.exe \WATCOM\binnt\re2c.exe
cd c:\temp\ow18src\bld\cg\risc\axp\nt386\
wmake
cd c:\temp\ow18src\bld\sdk\rc\wres\flat386\mf_r
wmake
cd c:\temp\ow18src\bld\cfloat\osi386
wmake
cd c:\temp\ow18src\bld\as\alpha\inline\osi386\
wmake
cd c:\temp\ow18src\bld\owl\osi386\
wmake

Now this will build the cross compiler…

cd c:\temp\OW18src\bld\cc\wcl\nt386.axp
wmake
copy wclaxp.exe \WATCOM\binnt
cd c:\temp\OW18src\bld\cc\nt386.axp
wmake
copy wccaxpc.exe \WATCOM\binnt\wccaxp.exe
copy wccdaxpc.dll \WATCOM\binnt\wccdaxp.dll
cd c:\temp\OW18src\bld\as\alpha\nt386
wmake
copy wasaxp.exe \WATCOM\binnt

Now for the Fortran 77 compiler. Please note that the default flags include -we which will cause the compiler to error if there is a warning. And as luck would have it, one function doesn’t declare a prototype… So you can either remove the -we flat from the mif file, or fix the c file… The choice is yours.

cd c:\temp\OW18src\bld\f77\wfl\nt386.axp
wmake
copy wflaxp.exe \WATCOM\binnt
cd c:\temp\OW18src\bld\f77\wfc\nt386.axp
wmake
copy wfcaxp.exe \WATCOM\binnt
attrib c:\temp\OW18src\bld\f77\f77lib\flags.mif -r

Do a search and replace on -we and replace it with nothing…

cd c:\temp\OW18src\bld\f77\f77lib\winnt.axp\_s
wmake
copy flib.lib \WATCOM\libaxp

With all that out of the way, let’s build some test programs…

Let’s start with hello.f for the Fortran compiler.

C234567
program hello
print *, ‘Hello!’
end

c:\temp>wflaxp hello.f
Open Watcom F77 Alpha AXP Compile and Link Utility Version 1.8
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
wfcaxp hello.f
Open Watcom FORTRAN 77 Alpha AXP Optimizing Compiler Version 1.8
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
hello.f: 3 statements, 40 bytes, 1 extensions, 0 warnings, 0 errors

Open Watcom Linker Version 1.8
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
searching libraries
creating a Windows NT(AXP) character-mode executable

c:\temp>

Ok, now that’s enough for now…! Later I’ll show how to build these compilers so they’ll run on the Dec Alpha.

## Some more random stuff.

Well while I was playing with NeXTSTEP on my P4, I managed to screw up the BIOS settings… The sound card I have is the AWE 64, one of those great ISA Plug & Play cards. The crazy thing is the only way to configure it properly is with a Pnp capable OS..

But back in the day, you could configure these things under MS-DOS with the ICU, or ISA configuration utility.. Which has become nearly impossible to track down, but I did manage to find a copy from Dell ICU-143N.EXE. It’s a bit crazy to setup, but once you go through the motion you can setup the IRQ dma etc etc, and with one more bit of ‘trickery’ on the nextstep pnp sb16 driver it’ll work. Naturally mine needed a different hex code 0x08ec009d

phew.

With that out of the way, I found another program for the NeXT, str a port of a SUN mod player.. Oddly enough it’s too slow to run on my m68k next cube, but it runs great on my white box now that I’ve managed to run the thing. At least it’ll be some kind of starting point for audio for Quake.

In other news Artyom managed to get Solaris 2.3 installed & running on Qemu.

I know people wanted me to go over AIX for the pc, but it tends to corrupt itself like crazy, however I got a tip that if you boot from floppy all the time, then have it mount the hard disk as multi user it doens’t freak out with hdintr issues…

That’s about it for today.

## NeXTSTEP audio & mod files…

Well I’ve been looking for a way to get some audio out of Quake for NeXTSTEP… and it’s incredibly complicated. I found some ‘smallish’ program for the m68k black hardware that is a MOD player, modPlayer 2.5 which also included source!

However, for me I can’t run it as the monitor to my cube is busted… But I was able to compile it to verify the source ‘works’. I then built it on my white box (P4 2.4Ghz 1GB of ram, and a real soundblaster 16!) and, after removing the reference to the decrunch routine it produced.. noise, and lots of it. But I did feel like I was getting *somewhere*.

I figure the main reason it’s exploding is that the m68k port uses the same CPU as the Amiga for these MOD files, so no doubt there is some bit flipping needed to go from big endian to little endian, but I know *nothing* about the MOD format.. So after a quick google search on basic mod players, I found qmod, a module player written in Quick Basic!!

So I looked around for a copy of Quick Basic 4.5, and tried to build the program, and it was all crash & burn.

At work we have a copy of PDS, the Professional Development System, also known as Basic 7.1 .. This thing is still useful, it will target OS/2 so you can write these massive programs (and run them under Windows 2000). So I figured I could use that to get the thing to build.. And I ran into the same errors about overflows, and all kinds of crap.

So the next thing to try was a copy of Visual Basic 1.0 for DOS that I got from ebay a while back.. I made images of the disks, which was fun, installed the thing to get.. the exact same errors. But I have to say VB for DOS was cool in that the output window can be in a windows (although text one) and you can trace and see at the same time… If only this was on store shelves in 1992!!!!

Anyways after looking at the command line options for VB for dos, I spotted this…

/Ah Enable huge dynamic arrays

I was surprised! So it would seem the answer was in the compiler, not the nice interface.. I just has ‘assumed’ that the interface would provide all the options.. Not so.

So I re-extracted the qmod source as I’d hopelessly altered it, then ‘fixed’ the one line that prevented compilation…

DEF SEG = VARSEG(mixarea(0))

I just removed that line, and ran the compiler & linker.. and it runs!

C:\TEMP>bc /Ah /O qmod.bas

Microsoft (R) Visual Basic (TM) for MS-DOS (R)
Compiler – Professional Edition Version 1.00

Object Filename [qmod.obj]:

Source Listing [nul.lst]:

42555 Bytes Available
33278 Bytes Free

0 Warning Error(s)
0 Severe Error(s)

Microsoft (R) Segmented Executable Linker Version 5.31.009 Jul 13 1992

Run File [qmod.exe]:
List File [nul.map]:
Libraries [.lib];
Definitions File [nul.def]:

C:\TEMP>

Now this program does require a sound blaster card, and it also requires the blaster environment variable set properly… So for Virtual PC it’s simply

SET BLASTER=A220 I5 D1 H5 T4

Then run qmod and the supplied mod file, and away it goes!

And I have to say it’s really cool to listen to this thing work, only using peek/poke (ok it’s inp/out in the new syntax…) but it’s playing the soundblaster, and it sounds GREAT.

So going back to PDS & Quick Basic 4.5 they all support the /Ah flag.. So it’ll build on any of them.

So for those who aren’t inclined to play compiler games, here is a pre-built version of Qmod, and it includes a mod file.

Now for those of you who don’t have Virtual PC, or not running on Windows, the program will run on DOSBox as well!

I just found I had to tweak the cpu config a little to make it run.. This is my CPU block in the configuration file.

[cpu]
#core=auto
core=simple
#cputype=auto
cputype=486_slow
cycles=auto
cycleup=500
cycledown=500

Now when you launch DOSBox, it’ll pick some low cpu cycle number and stay there when you launch qmod.. And it’s too low so it’ll sound horrible. So hitting CTRL+F12 will increase the cycles. Set it to 25000, and it’ll run fine. If you set it too high, CTRL+F11 will bring it down. DOSBox already sets the blaster environment variable for you, so it should ‘just work’.

From there I’d recommend sites like Amiga Music Preservation, or Mod Archive. Qmod can play quite a few of the files with the MOD extension, but not all.. But it’s a great small example program.

As luck would have it, my whitebox is having some weird boot issue, so I can’t go any further on this… But I figure I’d share this much with the world…

## Package for Quake on NeXTSTEP

Ok, I’m getting nowhere quick on the sound thing so I’ll release what I have now. Thanks to the instructions here, I’ve setup a package which can be easily installed on NeXTSTEP.

Simple, right? Just download the package, and you should be able to install it with no issues. I’ve built it for all the CPU types that NeXTSTEP supported so let me know if you have any luck…

Also I’m going to leave the quake server running on my server, the only issue is that the hostname is too long for Quake to deal with, so you’ll have to type in the ip address (75.127.119.16). Also you’ll have to launch this from the command line… 😐

If anyone has any hints on audio streams on NeXTSTEP drop me a line…..

## Multiuser on Quake for NeXTSTEP!

The picture says it all…

I took the unix timer code, and got that working (not surprising, NeXTSTEP still is 4.3 BSD at heart), and I fixed enough of the key bindings so it’s getting playable. In addition I went back through the WinQuake source and pulled out the BSD networking and that works great. There was a sound driver in there for the next, but it lacks the output functions…. So it would seem that’s the last thing to hack through for a more ‘complete’ Quake experience.. well that & the mouse.

I’ll probably dig around to find out how to make one of those nifty NeXT packages, and release a test version since it’s playable ‘enough’…

In other news, Qemu 0.12.4 has been released! I haven’t even tried it yet, but on my page “MIPS blast from the past” it’s said to be usable…

## Quake on NeXTSTEP 3.3

I’m one third of the way there…..

At least the video is kind of working… Right now I’m still using the cannibalized stuff from the UAE project’s port to NeXTSTEP. This is what I used for Frontier, although I’d like to think I’m getting a slightly better handle on it. Right now I just have to figure out why my keyDown & keyUP handlers are not working…. And implement the timer so it doesn’t run at warp speed. With the timer in place it should be able to do network play.

I suspect this would be FAR too slow to play on the m68k,Sparc or HPPA hardware but then who knows… My monitor for my m68k is broken so I can’t run it to find out…

This runs VERY fast on Qemu 0.90 I may have to rewire some stuff to run in on my whitebox, but I have a feeling I’m going to have to re-install… I forget where I left off on my NeXTSTEP setup on the old P4.

Anyways that’s what I have for the last few hours….

## The old AT&T "you will" ad campaign

So while I was looking at an iPad for no real reason, something told me I’d seen this thing before…. Something familiar..

Then I remembered this old thing.. The old AT&T you will from the early 1990’s.

The killer in retrospect, is that in the early 1990’s most people were lucky to have pagers, cellphones were bulky and cost prohibitive (lol nothings changed there), I went from a regular pager, to a 2 way pager, then to a nextel, then to a Motorola startac..

Ok, it’s not emulation, but it really is funny to see these future forward things, and how much we take for granted now, and just how… different things changed.

## Mini Vmac’s Macintosh II

While browsing around, it came to my attention that the great project Mini vMac‘s Macintosh II emulation has now progressed to the point where it can actually start running stuff!

So I downloaded it, searched high & low for the necessary files, and was booting in no time!

While it’s not as full featured as Basilisk II, it is a *LOT* smaller, and easier to work with. By default it’ll emulate a Macintosh II with 8 MB of ram. Hard disks & floppies are only supported through the shim method of the older Mini vMac, so you can just drag & drop your images onto the screen. I tested it with an old game I had floating around on my Mac SE30 Space Quest…

And it runs well enough.

Over all I have to say it’s easy to use, very responsive, and just GREAT!

If you have a need for 68000 MAC programs, you may want to give this one a shot… And it’s so small, the Win32 binary is 144kb!!!

## Slackware 3.5

A friend of mine was having a hard time trying to configure XF86 from the old Slackware 3.5 days… 1998.

Wow time sure has flown!

Anyways I kind of liked Linux back then as a lot of distros had OpenLook, which made my Linux box feel like a way cheaper SUN box.

While Slackware 3.5 installs great on Virtual PC, the networking just crashes out… So I thought I’d just fire it up on Qemu.

qemu.exe -net nic,model=ne2k_pci -net user -hda Slackware 3.5 Hard Disk.vhd” -L pc-bios -redir tcp:58080::80

And with a bit of tweaking I managed to get it running!

Although with normal VGA there is some weird issues with the cursor…

It was about as hard as I remember for the xf86config days… you kind of had to mash a few together to get it working…

And if it saves anyone the hassle, here is the XF86Config. (gzipped!)

This is basically regular VGA with a PS/2 mouse… It works on Qemu & Virtual PC, so I’m sure your favorite emulator ought to work as well.

## 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)