The new dynamic recompiler appears to be much more faster, although if you want maximum performance, make sure to set your video card to the fastest possible performance.
I was doing my typical DooM thing, and the performance was abysmal. But I did have an 8bit VGA card selected, so what would I really expect? Interestingly enough in ‘low resolution’ mode it performed quite well, but setting it to the artificial ‘fastest PCI/VLB’ speed it was performing just great.
A while back while looking for old Rogue source, and resources I came across this page, which includes a lot of old versions, and source code, and the file rog11src.zip. But looking at the source in this directory the file rogue.h reveals that it is actually 1.48!
#define REV 1
#define VER 48
And the source is all timestamped from late 1984, and throughout 1985. Well isn’t that exciting! Also on the same site is rogue-1.48.zip, a binary distribution of Rogue 1.48. So I thought I’d give it a shot to build it. The source mentions needing the MANX C compiler, which of course a quick google search yields an ad:
Which has all kinds of fascinating information, such as the ability to cross compile from VAX BSD, or PDP-11 BSD, the Amiga, CP/M etc but they don’t actually give any information about versions.
There is, however an Aztec C museum, that hosts several versions. And they do have the versions, along with the years to show that the C86 compiler that they had for 1985 would be 3.4b
Compiler Aztec C 8086 3.40a 7-3-86
(C) 1982,83,84,85 by Manx Software Systems, Inc.
And conveniently, they do have a download link for the comiler here: az8634b.zip
Now, since I’m on Windows 10 x64 I can’t easily run MS-DOS based compilers from 1985 at my native CLI, without a tool, and I chose Takeda Toshiya’s MSDOS. I was able to ‘bind’ the azmake utility which then could call the needed compiler, assembler, and linker to build an executable without too much work. I just created a command file, ‘build.cmd’ in the src directory, to setup the paths and needed variables to quickly compile Rogue from the command line. And a quick attempt at playing it showed that although it does compile, it is unplayable!
Well isn’t that great. There is a copy protection scheme. But wait, we have source so can’t we just by pass it? Yes we can! In the file dos.asm there is some checks for the variables hit_mul & goodchk. So I did the logical thing, which is before it checks them I just set them to good values.
And the good news is that I would no longer get killed by the Mafia, but I couldn’t progress down any levels. So in the file oprotec.asm, I saw there is some disk check routine called protect, that I went ahead and bypassed by having it immediately jump down to the ‘good’ label. Everything compiles but it still locks up going down a level. So finally I check rogue.h and commend the #define PROTECT statement, and now it’ll run!
I don’t know if anyone would even care, but I added the PDF manual and all the zip files that I used to source this version. You can download it here:
If you don’t want to run it under MS-DOS, or something like DOSBox, you can use msdos to run it. The title screen is garbled as it doesn’t emulate CGA, but as the rest is just text mode, it’ll run just fine.
So what this means is that now you can make fully standalone Win32/Win64 executables out of CLI based MS-DOS applications.
D:\tcc>msdos\binary\i486_x64\msdos.exe tcc -Iinclude -Llib hi.c Turbo C++ Version 3.00 Copyright (c) 1992 Borland International hi.c: Turbo Link Version 5.0 Copyright (c) 1992 Borland International
Available memory 4215648
D:\tcc>c:msdos\binary\i486_x64\msdos.exe hi hi!
D:\tcc>c:msdos\binary\i486_x64\msdos.exe -c hi.exe ‘new_exec_file.exe’ is successfully created
Isn’t that great?
I’ve had one issue with Turbo C++ 3.00 and that is the embedded executable will run out of memory while linking, but invoking it by calling msdos.exe let’s it run fine. If you compile and link separately it’ll run just fine.
So how does it fare? I thought I’d take the old Wolf4GW, and compile it with this toolset. The first hurdle I hit was this fun feature:
The C++ compiler now treats warning W737, implicit conversion of pointers to integral types of same size, as an error.
Which is an integral part of wl_menu.cpp . So this was somewhat problematic, until I just commented out that block, and while I was expecting no working keyboard, I’m able to play, and load/save games…. Even the boss key works.
So with the W737 taken care of, I have to say this thing compiles FAST. Incredibly FAST. If for some reason you have to build 16bit or 32bit anything, you should look at a 64bit tool chain, well assuming you have a 64bit computer by now.
If anyone want’s to build their own Wolf4GW with the newer OpenWatcom, my source drop is here.
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!