Quake1 & MS-DOS

And because I had a request for it, here is a 7zip containing a makefile, and source suitable for building quake under MS-DOS.

I sourced it from the Doom makefile, and cross built it under OS X… It builds in under 5 seconds using all 4 cpu’s on my OS X box with my OS X to MSDOS DJGPP cross compiler…. I had forgotten that the gpl’d source included MS-DOS support.. I had taken the video part from Chi Hoang’s DOS port of DOOM and gotten it to run until I remembered.. Oh well a few hours wasted.

So there it is, Quake1 built on a mac, and running on DOSBox on a PC.....

And speaking of Quake, it’s on sale too!

But just for today, on steam…..

Doom for MS-DOS

Today while checking out eets on steam ( yeah I know… ) I came across this sale… It’s Doom, Doom II, and Doom III all together, with all the expansion sets for $8.74 USD!

Well needless to say I couldn’t resist the offer, so I bought it. While playing around with Doom, I was wondering what was the first port of the Linux X11 doom back to MS-DOS. A bit of googling brought me to the doom wiki, and from there it seems that “DOSDoom” version is the first source port returning DOOM back to MS-DOS.

As mentioned in Chi Hoang’s notes, it took him 4-5 hours to do the initial port. So I figured it’d be worth re-creating the 0.1 version of his work, under DOSBOX with DJGPP.

I did find out the hard way that there is a single assembly clause that breaks under newer versions of DJGPP, and there is a small issue with the HOME environment variable that if it’s not set it’ll crash DOOM. So I ‘fixed’ that to use the current directory.

To install this legacy version of DJGPP, I found the needed files..

*bnu27b.zip
*csdpmi7b.zip
*djdev201.zip
*gcc2721b.zip
*gdb418b.zip
*mak3791b.zip
*pat253b.zip

Simply unzip all of this into a directory that your DOSBox mounts, and alter your dosbox.conf something like this:

[autoexec]
# Lines in this section will be run at startup.

mount c c:\dos
c:
set PATH=C:\DJGPP\BIN;z:\
set DJGPP=C:\DJGPP\DJGPP.ENV

Then you should be able to extract the doom source that I’ve patched up, and run make to re-build the exe. I’ve included a shareware wad file that won’t explode on missing demos…

So the end result is the following:

DOSDoom 0.1

DOSDoom 0.1

Which… has no networking support, no audio, but it does work! This port is overall minimally invasive to the code, and I’d suspect it’d make it a very easy starting point for yet even more ports of doom… I think there is over 40 out there.

That’s the one great thing about making the source available, is that the product lives on and on!

Building 32bit binaries on x86_64 Debian 7 / Wheezy

I’ve been going in circles with slirp trying to really get it to run on x86_64 mode so far to no avail…

So first thing, hello from the future of 2020 (I wrote this quick blurb in 2010), and Wheezy has been pulled from the main mirrors. So annoying! You need to update your apt sources to use the archive:

deb http://archive.debian.org/debian/ wheezy main
deb-src http://archive.debian.org/debian/ wheezy main
deb http://security.debian.org/ wheezy/updates main contrib
deb-src http://security.debian.org/ wheezy/updates main contrib

Do your apt-get update;apt-get upgrade and you’ll be ready to roll!

But it’d sure help to be able to compile code in 32bit/64bit on the same machine. Anyways after looking for far too long I managed to find that it’s really simple.

apt-get install lib32bz2-dev

And away we go!

Naturally, you’ll need a compiler already installed ( build-essential).

# cat x.c
#include
int main(){printf(“int is %d\n”,sizeof(int));return 0;}
#
# gcc -m64 x.c -o x64
# gcc -m32 x.c -o x32
# file x32 x64
x32: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
x64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
# ./x32
int is 4
# ./x64
int is 4

Which alone is… interesting.

SIMH benchmark numbers…

I have to admit, I’m really surprised. In the past Visual C++ had been a clear winner every time I’d checked performance vs Gcc. And the tide seems to have really turned under Windows 7 x64. While not a massive lead, the winner after all these iterations of my simh benchmark was Gcc 4.5.2 for x86_64.

Just in the same fashion here, it seems that on some platforms -O1 is faster then -O2, and you really won’t find out until you run some comparisons.

gcc version 3.4.5 (mingw-vista special r3)

gcc O0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 23
This machine benchmarks at 21739 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 20
This machine benchmarks at 25000 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second

gcc O1
15.33333333333333
Dhrystone(1.1) time for 500000 passes = 16
This machine benchmarks at 31250 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 15
This machine benchmarks at 33333 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 15
This machine benchmarks at 33333 dhrystones/second

gcc 02
12.33333333333333
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

gcc version 4.5.2 20101002 (prerelease) [svn/rev.164902 – mingw-w64/oz] (GCC)

gcc O0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 22
This machine benchmarks at 22727 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second

gcc O1
13.33333333333333
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

gcc O2
12
Dhrystone(1.1) time for 500000 passes = 11
This machine benchmarks at 45454 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64

VC /Od /Bi0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 22
This machine benchmarks at 22727 dhrystones/second

VC /O2 /Ob2 /Oi
13
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

VC /O2
13.66666666666667
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second

Vc /Og /Ox
13
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80×86
VC /Og /Ox
13.33333333333333
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

And this is on my laptop, an Intel Core i7 Q 720 running at 1.6Ghz with 4GB of ram & Windows 7 Home Premium.

MinGW-w64

Well after yesterdays x86_64 excitement, I figured I’d take a look in the windows area to see about the 32bit vs 64bit performance on Windows…

I know this isn’t the ‘best’ test as I’m using VMWare Fusion on OS X and running Windows XP x64 sp2 (the 2007 edition, not the 2003 one).

If anyone wants to know how to get a 64bit gcc on windows, this is the best formula I’ve come up with so far.

First download a build of mingw-w64-bin_x86_64 from sourceforge… Right now I’m using a ‘Personal Build’ from sezero_20101003, because… it’s recent, and I would imagine a personal build has some hope of actually working.

I downloaded that, and extracted to the root of the C drive. Then I renamed the mingw64 to mingw.

Next up, I downloaded and installed MSYS 1.0.11, and installed that. I selected the default options, and of course specified my mingw is installed in

C:/mingw

After that, I install the MSYS DTK 1.0, again with default options.

The final part is some kind of editor, I like VIM but it’s… involved to download as the default package ‘vim-7.2-1-msys-1.0.11-bin.tar.lzma’ is in a 7zip compatible archive that needs a bit of tweaking to get a tar file out of. I can provide it here in gzip format, that you can simply extract within the msys command prompt in the /usr directory.

Now with all that done, you should be in business!

$ gcc -v
Using built-in specs.
Target: x86_64-w64-mingw32
Configured with: ../gcc44-svn/configure –host=x86_64-w64-mingw32 –target=x86_6
4-w64-mingw32 –disable-multilib –enable-checking=release –prefix=/mingw64 –w
ith-sysroot=/mingw64 –enable-languages=c,c++,fortran,objc,obj-c++ –enable-libg
omp –with-gmp=/mingw64 –with-mpfr=/mingw64 –disable-nls –disable-win32-regis
try
Thread model: win32
gcc version 4.4.5 20101001 (release) [svn/rev.164871 – mingw-w64/oz] (GCC)

 

But will it run Dungeon?

What is also cool, is that this build of mingw includes gfortran, which is a Fortran 95 compiler with various 2003 & 2008 enhancements. So for the heck of it, I’ve rebuilt the makefile from dungeon-2.5.6 and tweaked the machdep.f to at least call the ITIME function to get the current time. The resulting archive runs pretty well!

Windows XP x64 - dungeon

Yes, it runs! And without a *32 meaning this is a 64bit binary!

 

Onward with SIMH

So going back to SIMH as my benchmark, here is the vax780 with -O0/-O0

Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 20
This machine benchmarks at 25000 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second

Which comparing it to the native x86_64 build is pretty good considering I’m running this in a VM (VMware Fusion!). Now the same test with -O1/-O1

Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Which is pretty good! Now for the finally with -O2/-O1

Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Which is interesting in that there is no appreciable difference in the -O2/-O1 vs the -O1/-O1 build. Although I kind of expect different results on a native machine. If anyone else cares to test, I’m going to make available the whole project here. This includes the source and the pre-built binaries.

Unzip it on a win64/win32 machine and it should be somewhat straightforward to build / run. You can alter the makefile and change the primary CC flags from O0 to O1 or O2 if you so wish… just run make and it’ll generate a vax780.exe . Then in the test directory you can bench your exe like this:

$ make
gcc -O0 -c -o VAX/vax_cpu.o VAX/vax_cpu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_cpu1.o VAX/vax_cpu1.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 –
DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_fpa.o VAX/vax_fpa.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
VAX/vax_fpa.c: In function ‘op_cmpfd’:
VAX/vax_fpa.c:210: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:210: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:211: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:211: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘op_cmpg’:
VAX/vax_fpa.c:233: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:233: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:234: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:234: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘vax_fadd’:
VAX/vax_fpa.c:371: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:373: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:386: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘unpackd’:
VAX/vax_fpa.c:525: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:525: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘unpackg’:
VAX/vax_fpa.c:540: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:540: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘norm’:
VAX/vax_fpa.c:548: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:548: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:548: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:549: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:549: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:557: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘rpackfd’:
VAX/vax_fpa.c:574: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c:575: warning: integer constant is too large for ‘long’ type
VAX/vax_fpa.c: In function ‘rpackg’:
VAX/vax_fpa.c:597: warning: integer constant is too large for ‘long’ type
gcc -O0 -c -o VAX/vax_cis.o VAX/vax_cis.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_octa.o VAX/vax_octa.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 –
DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_cmode.o VAX/vax_cmode.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64
-DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_mmu.o VAX/vax_mmu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_sys.o VAX/vax_sys.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_syscm.o VAX/vax_syscm.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64
-DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_stddev.o VAX/vax780_stddev.c -I. -DVM_VAX -DVAX_780 -DU
SE_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_sbi.o VAX/vax780_sbi.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_mem.o VAX/vax780_mem.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_uba.o VAX/vax780_uba.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_mba.o VAX/vax780_mba.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_fload.o VAX/vax780_fload.c -I. -DVM_VAX -DVAX_780 -DUSE
_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax780_syslist.o VAX/vax780_syslist.c -I. -DVM_VAX -DVAX_780 –
DUSE_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_rl.o PDP11/pdp11_rl.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_rq.o PDP11/pdp11_rq.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_ts.o PDP11/pdp11_ts.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_dz.o PDP11/pdp11_dz.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_lp.o PDP11/pdp11_lp.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_tq.o PDP11/pdp11_tq.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_xu.o PDP11/pdp11_xu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_ry.o PDP11/pdp11_ry.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_cr.o PDP11/pdp11_cr.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_rp.o PDP11/pdp11_rp.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_tu.o PDP11/pdp11_tu.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_hk.o PDP11/pdp11_hk.c -I. -DVM_VAX -DVAX_780 -DUSE_INT
64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o PDP11/pdp11_io_lib.o PDP11/pdp11_io_lib.c -I. -DVM_VAX -DVAX_780 –
DUSE_INT64 -DUSE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o scp.o scp.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADDR64 -I VAX
-I PDP11
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:470: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:471: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:472: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:473: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:474: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:475: warning: integer constant is too large for ‘long’ type
scp.c:476: warning: integer constant is too large for ‘long’ type
scp.c:476: warning: integer constant is too large for ‘long’ type
scp.c:477: warning: integer constant is too large for ‘long’ type
scp.c:477: warning: integer constant is too large for ‘long’ type
scp.c:478: warning: integer constant is too large for ‘long’ type
scp.c:478: warning: integer constant is too large for ‘long’ type
scp.c:479: warning: integer constant is too large for ‘long’ type
scp.c:479: warning: integer constant is too large for ‘long’ type
gcc -O0 -c -o sim_console.o sim_console.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11
gcc -O0 -c -o sim_fio.o sim_fio.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADDR6
4 -I VAX -I PDP11
gcc -O0 -c -o sim_timer.o sim_timer.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_A
DDR64 -I VAX -I PDP11
gcc -O0 -c -o sim_sock.o sim_sock.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADD
R64 -I VAX -I PDP11
gcc -O0 -c -o sim_tmxr.o sim_tmxr.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADD
R64 -I VAX -I PDP11
gcc -O0 -c -o sim_ether.o sim_ether.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_A
DDR64 -I VAX -I PDP11
gcc -O0 -c -o sim_tape.o sim_tape.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DUSE_ADD
R64 -I VAX -I PDP11
gcc -O0 -c -o VAX/vax_cpu2.o VAX/vax_cpu2.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64 –
DUSE_ADDR64 -I VAX -I PDP11
gcc -O1 -c -o VAX/vax_cpu2.o VAX/vax_cpu2.c -I. -DVM_VAX -DVAX_780 -DUSE_INT64
-DUSE_ADDR64 -I VAX -I PDP11
gcc -o vax780 VAX/vax_cpu.o VAX/vax_cpu1.o VAX/vax_fpa.o VAX/vax_cis.o VAX/vax_
octa.o VAX/vax_cmode.o VAX/vax_mmu.o VAX/vax_sys.o VAX/vax_syscm.o VAX/vax780_st
ddev.o VAX/vax780_sbi.o VAX/vax780_mem.o VAX/vax780_uba.o VAX/vax780_mba.o VAX/v
ax780_fload.o VAX/vax780_syslist.o PDP11/pdp11_rl.o PDP11/pdp11_rq.o PDP11/pdp11
_ts.o PDP11/pdp11_dz.o PDP11/pdp11_lp.o PDP11/pdp11_tq.o PDP11/pdp11_xu.o PDP11/
pdp11_ry.o PDP11/pdp11_cr.o PDP11/pdp11_rp.o PDP11/pdp11_tu.o PDP11/pdp11_hk.o P
DP11/pdp11_io_lib.o scp.o sim_console.o sim_fio.o sim_timer.o sim_sock.o sim_tmx
r.o sim_ether.o sim_tape.o VAX/vax_cpu2.o -I. -DVM_VAX -DVAX_780 -DUSE_INT64 -DU
SE_ADDR64 -I VAX -I PDP11 -lwinmm -lwsock32

Administrator@JASON-4AC1B1EA0 /usr/src/simh
$ cd test/

Administrator@JASON-4AC1B1EA0 /usr/src/simh/test
$ ../vax780.exe bsd42.ini

VAX780 simulator V3.8-1
loading ra(0,0)boot
Boot
: ra(0,0)vmunix
199488+56036+51360 start 0x11a0
4.2 BSD UNIX #9: Wed Nov 2 16:00:29 PST 1983
real mem = 8384512
avail mem = 7073792
using 102 buffers containing 835584 bytes of memory
mcr0 at tr1
mcr1 at tr2
uba0 at tr3
hk0 at uba0 csr 177440 vec 210, ipl 15
rk0 at hk0 slave 0
rk1 at hk0 slave 1
uda0 at uba0 csr 172150 vec 774, ipl 15
ra0 at uda0 slave 0
ra1 at uda0 slave 1
zs0 at uba0 csr 172520 vec 224, ipl 15
ts0 at zs0 slave 0
dz0 at uba0 csr 160100 vec 300, ipl 15
dz1 at uba0 csr 160110 vec 310, ipl 15
dz2 at uba0 csr 160120 vec 320, ipl 15
dz3 at uba0 csr 160130 vec 330, ipl 15
root on ra0
WARNING: should run interleaved swap with >= 2Mb
Automatic reboot in progress…
Tue Nov 8 03:44:30 PST 1983
Can’t open checklist file: /etc/fstab
Automatic reboot failed… help!
erase ^?, kill ^U, intr ^C
# ./d2;./d2;./d2
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second
# sync
# sync
# sync
#
Simulation stopped, PC: 80001629 (BNEQ 80001630)
sim> q
Goodbye

Administrator@JASON-4AC1B1EA0 /usr/src/simh/test
$

The d0,d1,d2 are the dhyrstone benchmark compiled with -O0, -O1, and -O2 respectively. This gives you a chance to observe various optimizations in the GCC 2.7.2.2 for the VAX.

gcc on the x86_64

Today I thought I’d isolate the portion of simh that crashes 4.X BSD, when SIMH is built with GCC. I managed to find that the “op_ldpctx” and “op_mtpr” procedures of vax_cpu1.c become unstable when built with -O2 flags.

So I extracted the two procedures so I could then built the remainder of SIMH with GCC’s O2 flags. Before going too far, I first went to verify that the results would be consistent with the i386/32bit binaries…

However the results were.. interesting. By default SIMH will build with -O0 flags for the VAX giving the following dhrystone benchmark in 4.3 UWisc BSD:

Dhrystone(1.1) time for 500000 passes = 24
This machine benchmarks at 20833 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 24
This machine benchmarks at 20833 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 24
This machine benchmarks at 20833 dhrystones/second

24 seconds, not so hot. Then the same thing with -O1 flags…

Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 18
This machine benchmarks at 27777 dhrystones/second

18 seconds! pretty good, thats a 33% increase! Now for my hybrid -O2/-O1

Dhrystone(1.1) time for 500000 passes = 17
This machine benchmarks at 29411 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 17
This machine benchmarks at 29411 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 17
This machine benchmarks at 29411 dhrystones/second

A 5% increase over the -O1 … Nothing too big, but still an INCREASE.

Now for the real fun, I re-ran these bulid factors with the x86_64 compiler.

The -O0/-O0 combination came in at 19 seconds!!

Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 19
This machine benchmarks at 26315 dhrystones/second

This is pretty amazing considering everything we do should make it faster… The next thing I tried was the -O1/-O1 combination and go the following:

Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

A 12.5 second average! This blew the doors off of the -O2/-O1 on the i386! Naturally I was hoping for at least a 5% increase going to the -O2/-O1 flags on the x86_64, however I got this…

Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

And I ran it numerous times, but the bottom line is that the O2 flags actually produces a SLOWER SIMH on OS X 10.6.4 then -O1 flags… The whole exercise is a tad perplexing to me, to say the least, but unless you bench it, you’ll never know if the compiler is getting confused somewhere, and going to throw a loop. I should also point out that SIMH will not run with full -O2 flags as there is something in the code that breaks under optimization so this very well may not hold true 100% of the time, but at the same point things still have to be tested…

Taking Clipper to the Harbour

In the last instance, I left with an example of running a Clipper 87 program compiled with a simple C routine, then rebuilt that with Clipper 5.3 using both a 286 & 386 Dos extender.

The next step will be taking that program and making a win32 exe.

And for that we are going to use this great program harbour.

Much like f2c, harbour translates dBase PRG files into either C, or a p-code VM just like clipper did. For this example, I just downloaded Harbour from sourceforge, and installed it in my c:\hmg directory.

Porting applications is pretty straight forward, however Harbour needs a ‘main’ procedure to exist in order to work correctly. So the first change to my simple clipper program is to create wrap my simple Clipper program in a main procedure.

HI.PRG

procedure main
? “hello from clipper”
? “”
c_hi()
return

Now the C program needs some changes as well. Notice how this looks very different from the old c program, but at the same time, it’s not too different. Also because harbour translates the clipper into C, stdio is now working correctly so I can use printf.

HI_C.C

#include “hbvmpub.h”
#include “hbinit.h”

HB_FUNC( C_HI )
{
printf(“hi from C\n”);
}

Now to setup the environment, translate the clipper, build the c program and link them together….

\hmg\MINGW\mingwvars.bat

\hmg\HARBOUR\bin\harbour.exe hi.prg -m

gcc hi_c.c -I\hmg\harbour\include -c

gcc -mconsole hi.c hi_c.c -I\hmg\harbour\include -mconsole -Wl,–start-group -lhbextern -lhbdebug -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lwinmm -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,–end-group -ohi.exe -LC:/hmg/HARBOUR/lib

And running this gives me:

C:\temp>hi

hello from clipper
hi from C

C:\temp>

Now I know there is all kinds of front ends and other fun stuff, however I think it’s good to know how the thing actually works…

What is even more cool about Harbour is that once you get your program working there, it can be easily rebuilt for OS/2, Linux, Win32, Win64, Windows CE and a few other platforms where GCC is available.

And the best part is that they won’t soak up 100% of your CPU!!!

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.

200th post!, and using ADA to fix your system…

Wow, so I was about to post this when I check to see how many posts I’ve done, and this will put me at 200.

It’s hard to believe it all started out on running Netware 3.12 on Qemu 0.9.0.

Ok, now let’s get on with today’s fun.

I’ve recently managed to get Solaris 2.4 running on Qemu, and it’s been all great, but I’d love to build some programs for it! Now there are binary builds of GCC for Solaris 2.4, but they are about 17MB compressed, and I think it was about 80 uncompressed!

Well that sounds great, except for 2 major limitations:

1. For some reason Solaris doesn’t want to mount any ISO I give it… I’m still kind of lost there.
2. The only networking I can get working is the usermode NAT, and Solaris 2.4’s ftp client/server is just too old for passive mode.

So what the heck can I do?

Well back in college we had this RS/6000 that was cool, *BUT* for some reason I don’t recall it couldn’t build and use mtools (among other things) but from what we had heard is that if we had gcc, it’d run fine. Except without a working C compiler, how does one get GCC running on a RISC machine?

Well, thanks to the fine people that maintain GNAT, the GNU ADA translator, they provide some ready to run versions of GCC. Well not to complain but as the years drag on, lots of mirrors are gone, and there are only a handful of copies left, but they currently have:

*Dec Alpha OSF4
*HP HPPA HPUX 10.20
*i386 Solaris 2.6
*SUN Sparc Solaris 2.5.1
*IBM PowerPC AIX 4.1

And let me tell you, if you were ever given any of the above machines, you’ll be so grateful for this massive leg-up! Now these are *NOT* full development systems, as they are geared towards translation, they are lacking the libc/include files. You’ll have to source those from somewhere, but thankfully as part of the Solaris install there is an option for headers and libraries.

So, while this is all very good, how do you get this stuff to run on your SPARC?

Well.. It’s tedious! but this method is what I used to get gcc running on the RS/6000 years ago, and on the sparc. Unpack that GNAT distribution, then use uuencode/uudecode on the minimal files.. Then paste them into a console window and be sure to have turned messages off!… It’s not “sexy” but it works!

Naturally since there is no gzip for Solaris (you’d have to send one over first!) don’t bother compressing anything with gzip/bzip2… although you could us the old unix compress command, which is what I ended up doing.

So at a minimum the following files are needed to build some programs…

cc1 crt1.o crtend.o crtn.o libgcc.a
cpp crtbegin.o crti.o gcc

Yes, really!

# cat one.c

#include <stdio.h>
void main(void)
{
printf(“hi\n”);
}
# gcc -v one.c -o one
Using builtin specs.
gcc version 2.8.1
cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=8 -Dsparc -Dsun -Dunix -D__svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__GCC_NEW_VARARGS__ -Acpu(sparc)
-Amachine(sparc) one.c /var/tmp/cca000KP.i
GNU CPP version 2.8.1 (sparc)
#include “…” search starts here:
#include <s…> search starts here:
/usr/include
End of search list.
cc1 /var/tmp/cca000KP.i -quiet -dumpbase one.c -version -o /var/tmp/cca000KP.s
GNU C version 2.8.1 (sparc-sun-solaris2.5.1) compiled by GNU C version 2.8.1.
one.c: In function `main’:
one.c:4: warning: return type of `main’ is not `int’
/usr/ccs/bin/as -V -Qy -s -o /var/tmp/cca000KP1.o /var/tmp/cca000KP.s
/usr/ccs/bin/as: SC3.1 dev 09 May 1994
/usr/ccs/bin/ld -V -Y P,/usr/ccs/lib:/usr/lib -Qy -o one /lib/crt1.o /lib/crti.o /usr/ccs/lib/values-Xa.o /lib/crtbegin.o -L/usr/ccs/bin -L/usr/ccs/lib /var/tmp/cca000KP1.o -lgcc -lc -lgcc /lib/crtend.o /lib/crtn.o
ld: Software Generation Utilities (SGU) SunOS/ELF (LK-1.4 (S/I))
# ./one
hi
#

After an hour of struggling with uuencode, and pasting the results with putty into Qemu running Solaris 2.4 I’ve managed to cook up the following programs:

gzip-1.24
httpd-0.5
ircII-4.4
lynx-2.8.2
make-3.75
unzip-5.52

And I’ve got to admit, that using lynx to download new stuff is a VAST improvement! So for the hell of it, I went ahead and built my favorite f2c/libf2c & dungeon-2.5.6!

Solaris 2.4 running dungeon

So there it is, Dungeon in all of its “glory”.

Now one important ‘tip’ to share, is that if you follow this path, it’s possible to run into some weird vararg issues… The problem is that gcc works better with it’s own headers for varargs, not any OS version… Everyone recommends you build GCC on your machine yourself to get all the headers in place. The GNAT packages do include the needed vararg stuff, you can simply change the lines that use something like this:

#include <varargs.h>

to

#include “/tmp/gnu/varargs.h”

And life will be good.. That’s basically what I was needing to get lynx to run.

Well, that’s the end of this adventure, hope to post at least another 200 more!

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.