No really, it’s Catacomb 3-D: The Descent. First ported to 32-bit SDL by NotStiller. Me being the person I am, I fixed a slight bug regarding binary files on Windows, and MS-DOS, then cleaned up some of the C++ syntax (yuck!) making it far more C89 friendly. And of course, hot off the heels of DooM for GO32 DPMI, I was able to get it to build and run using GCC 1.39 and GO32.
I know most people really won’t care, but I found it kind of interesting. I should try to see if it’ll run on actual hardware, just as a comparison of tightly optimized Borland C++ / Assembly vs 100% pure C on DJGPP. The best tech of 1991 for sure!
I also put up the source for my ‘null doom‘, for anyone who ever needs some massaged source to DooM that will compile with a C compiler, instead of needing something that can understand C++ style comments, although I know in cccp.c there is the ability to turn on cplusplus style processing. However since I did want something that would compile without altering the compiler (too much) I thought it was best to just change all the comments.
And a quick download link to the zip file with the source & binaries.
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.
Continuing in my quest of useless stuff, here is GCC 2.5.8 for EMX as a native Win32 executable set.
With some weirdness of inline not being recognized, I just commented that out. The GCC driver program does have some issues though, and Im just not in the mood to fully figure out why either the EMX or MS-DOS versions can’t correctly capture return codes, or if it was better to just use -pipe and _pipe with _O_TEXT mode set, but again how to figure out if the pipe closed cleanly or with errors? So for now it’ll always assume everything worked, but it will still print errors. Sigh.
With that said, the CC1, CC1OBJ, CC1PLUS drivers all built, so you can use C, ObjectiveC, and C++. yay.
The functional version of this is EMX 0.8H, with the gcc 2.5.8 update. Maybe I’ll put this all on sourceforge so people don’t have to deal with my crappy download system, but for now it’s on my site.
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
Turbo Link Version 5.0 Copyright (c) 1992 Borland International
Available memory 4215648
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.
While I’m waiting for my real PC-9821 to arrive, I’ve been playing with various software. One fun thing was the old DJGPP, as the version 1.x had a customized version of go32 to support the PC-98 hardware. This is cool, but I’d love to perhaps start down the road of porting something to the PC-98. There is no VGA adapter, and the I/O is mapped differently so naturally this is why they are only loosely compatible. So while I was looking for any kind of source code using DJGPP, I found the FCE: Family Computer Emulator (NES). It includes source code, which is great but it builds against DJGPP 2.x What makes it more interesting is that it has DPMI hooks in place, unlike the old DJGPP 1.x’s DOS extender which is DPMI incompatible. So how do you magically get a DPMI environment for MS-DOS? Well one way is to run it under Windows 3.0 or higher. And certainly with MS-DOS 3.30 that is an option. However lurking in the disk images of MS-DOS 5.00A was a fun program DPMI.EXE . Well now that is interesting!
Using a generic config.sys I have 600kb of low RAM available, and 7MB of extended RAM.
As you can see this is pretty much the 386 enhanced portion of Windows 3.0! So you get all of the DPMI services offered by Windows as part of the OS.
As you can see, with DPMI running I have access to EMS, and XMS memory now available. Additionally with paging you can even over commit memory.
My only question, is why was DPMI not an added in feature of the English versions of MS-DOS? Granted there was a LOT of OEM bundling with new machines so you were forced to purchase a copy of Windows along with MS-DOS on all new computers, regardless of what you were going to do with them, and this would have been a bit more interesting.
This kind of environment was extensively documented in the “Unauthorized Windows 95“, by Andrew Schulman that showed how DOSX.EXE could chain load Win386 + command.com achieving the same thing. The DPMI environment from MS-DOS 5.00A is dated 11/11/1992, I wonder if he knew about this going into the Windows 95 book. It’s been too long since I’ve read it to remember, but I don’t recall any details about Japanese PC-98 releases of MS-DOS. There was also a ‘MSDPMI’ environment created for the beta versions of Microsoft C 7.0, but I’ve been unable to find one to verify. MSC 7.0 was released in 1992, so it fits in the same timeframe, but the shipping products used QEMM’s DPMI server instead.
Binaries are built and tested mostly under Windows Vista Business (SP2)
Source RPMS needed for building Linux to DJGPP cross-compiler
Binary RPMs for both i686 and x86_64 are available. I built these binary RPMs
in CentOS 6.7 chroot under Fedora 23. Binaries are statically linked with GMP-6.1.0
MPFR-3.1.4 and MPC-1.0.3 to avoid unnecessary dependencies and increase
compatibility with other Linux distributions. For example they are expected
to work without problems in other reasonably recent Linux distributions
(like Fedora, RHEL-6 and newer, etc)
gcc610s2.zip is no more provided as patching GCC using DJGPP tools
has not been tested and even attempted by me for a long time.
DJGPP source file gcc610s.zip is a side product of building
gcc-6.1.0 Linux to DJGPP cross-compiler RPM packages. See source
RPM for patches applied to original FSF version of GCC-6.1.0.
You can find the same contents in the file
While I was looking for System16 stuff, I found the first version of MAME to include the UAE 68000 core starting in release MAME 28, although System16 emulation itself didn’t appear until MAME 33b3, but not playable until MAME 33b4.
So what does it mean? Well at the time the UAE core was the way to go. However from looking at the MAME source, the UAE core that they were using from System16 was already generated, while UAE still included the build68k program to parse the tables, and generate the 68000. Instead they were editing the outputted C. UAE wasn’t GPL until version 0.7(something), 0.7.6 for sure, so I don’t know why they weren’t using it from the source.
Eventually starting in MAME 35b2, the core was replaced with MUSASHI , so Among their reasons for dumping the early UAE CPU core was this laundry list:
New 68000 C core. For testing purposes, this is also being used in the DOS
version instead of the asm core. [Karl Stenerud]
1. Faster. This code is, barring ram fetch time, almost twice as fast as the existing C core in MAME. I’ve done extensive speed profiling on both engines. The only problem now is the slow memory access in MAME due to bankswitching et al.
2. Emulation more correct. I found many bugs in the MAME engine (and many, many more in mine for that matter) when I pitted them head-to-head. I have run random instructions from each opcode class at least 10 million times, comparing the resultant CPU states, and have left it running random instructions for 1 billion iterations. In every case, I have adhered to the specs defined in M68000PM/AD REV. 1.
3. Disassembler is correct. The current M68000 disassembler in mame has a tendency to disassemble instructions that have an invalid EA mode.
4. Cycle counting is 99.9% correct. The only instructions which don’t have correct cycle counts are divs, divu, muls, mulu, and they’re not worth counting correctly. (I’m not about to waste emulation time counting 0-1 and 1-0 sequences).
5. > 32 bit friendly. I’ve taken care to ensure maximum portability without sacrificing speed. The result is conditional compiling dependant on your architecture. I’ve also implemented and tested a compatible solution for architectures that lack 8, 16, or 32 bit signed storage types.
6. The code is carefully laid out to be readable.
Also in MAME 35b4 added in was emulation of the NEC uPD7759 chip for speech, fleshing out the System16 emulation.
To compile these ancient versions, and inbetween I was using my Candadian cross DJGPP GCC 4.12 Win32 cross compiler. For Allegro I’ve always found it builds far easier using GCC 188.8.131.52, a vintage compiler from back in the day I could just run in DOSBox.
Obviously with today’s machines, these ancient versions of MAME run fine on DOSBox! It’s really amazing in the scope of emulators running emulators.