Epyx Rogue 1.48

Rouge 1.48 title screen

Rouge 1.48 title screen

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:

Manx Aztec C86

Manx Aztec C86

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

Version 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!

Killed

Killed by the Copy Protection Mafia

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.

; fake copy protection
mov hit_mul_, 1
mov goodchk_, 0D0DH

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:

rogue-148_binary+source.7z

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.

EMX GCC 2.5.8 for Windows

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.

Here is my build, along with binaries:

emx_gcc_258_phase1_xgcc_cccp_cc1_cc1obj_cc1plus.7z

And the un touched source code, as provided in the 0.8H update

emx_gcc_258_virgin.7z

I’ve only tested it with MS-DOS, and PDOS.  I’m also using the ancient binutils from my GCC 1.40 on Windows experiment.

MS-DOS player can now embed executables

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

D:\tcc>new_exec_file.exe
hi!

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.

As always you can find the project page here:

http://homepage3.nifty.com/takeda-toshiya/msdos/

MS-DOS 5.0 DPMI

MSDOS 5.00A BOOT

MS-DOS 5.00A booting on Neko Project 21

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!

MSDOS 5.00A native memory

MSDOS 5.00A native memory

Using a generic config.sys I have 600kb of low RAM available, and 7MB of extended RAM.

Now the real interesting part is DPMI.INI

[386Enh]
ebios=
display=dddn.386
keyboard=*vkd
network=*vnetbios, *dosnet
device=*vpicd
device=*vtd
device=*vdmad
device=*vsd
device=*vsound
device=d86mgrn.386
device=*pageswap
device=*dosmgr
device=*vmpoll
device=*wshell
device=*vfd
device=*vscsid
device=dpdn.386
device=*parity
device=*biosxlat
device=dmcpd.386
device=*vhd
device=*vcd
device=*combuff
device=*resume
device=*la20hma
device=dpfd.386
Paging=Yes

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.

MSDOS 5.00A DPMI activated

MSDOS 5.00A DPMI activated

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.

[ANNOUNCE] DJGPP port of gcc-6.1.0

This is announcement of an update of DJGPP port of GCC-6.1.0

GCC used to stand for the GNU C Compiler, but since the
compiler supports several other languages aside from C,
it now stands for the GNU Compiler Collection.

See
https://gcc.gnu.org/ml/gcc/2016-04/msg00244.html
for original announcement of gcc-6.1.0 release


  • WARNING: This GCC port is for DJGPP v2.05 *
  • Build for DJGPP 2.03p2 is not and will not be available. *

Warning: DJGPP port of binutils-2.22 or newer is recommended.
Version 2.19 and 2.20 may work but are not tested
It is however recommended to use binutils-2.22
or newer

Use of DJGPP port of binutils-2.22 or newer is however required for

building gcc-6.1.0 for DJGPP.

Build for current stable version of DJGPP (djdev205) is
available
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/
and mirror sites (see http://www.delorie.com/djgpp/getting.html)

gcc610b.zip GNU GCC 6.1.0 for DJGPP V2
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gcc610b.zip

gcc610d.zip Documentation for GNU C compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gcc610d.zip

gpp610b.zip GNU C++ Compiler 6.1.0 for DJGPP V2
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gpp610b.zip

gfor610b.zip GNU Fortan 95 compiler 6.1.0 for DJGPP V2
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gfor610b.zip

gcc610s.zip GNU GCC 6.1.0 sources for DJGPP
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gcc610s.zip

objc610b.zip GNU Objective C and Objective C++ compiler and
runtime libraries v6.1.0
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/objc610b.zip

gfor610d.zip Documentation for GNU Fortran compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/gfor610d.zip

ada610b.zip GNU Ada compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/ada610b.zip

ada610d.zip Documentation for GNU Ada compiler
ftp://ftp.delorie.com/pub/djgpp/current/v2gnu/ada610d.zip

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

ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/djcross-gcc-6.1.0.tar.bz2
Cross-compiler SRPM:

ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/djcross-gcc-6.1.0-2ap.src.rpm

Cross-compiler binary RPMs (built under CentOS 5.11 i386, are expected to work on other recent enough RPM based Linux distributions, I myself have tried Fedora 19 x86_64):

GNU C compiler:
ftp://ftp.delori3.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-6.1.0-2ap.i686.rpm

GNU C++ compiler:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-c++-6.1.0-2ap.i686.rpm

GNU Ada compiler:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-gnat-6.1.0-2ap.i686.rpm

GNU Fortran compiler:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-gfortran-6.1.0-2ap.i686.rpm

GNU Objective C and Objective C++ compilers:
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-objc-6.1.0-2ap.i686.rpm

Tools for GCC 6.1.0 (currently only fixincl, most users do not need this):
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-tools-6.1.0-2ap.i686.rpm

Info files of GCC-6.1.0 (a separate RPM file as these files are expected to
conflict with system compiler info files, but You do not need to install them…):
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-gcc-6.1.0/i686/djcross-gcc-info-6.1.0-2ap.i686.rpm

Substitute i686 with x86_64 For x86_64 binary RPMs in the URLs above.

You need also cross binutils (choose required binary RPM file or build from SRPM)
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-binutils-2.24-1ap.src.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-binutils-2.24-1ap.i686.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcross-binutils-2.24-1ap.x86_64.rpm

You need also DJGPP development libraries, include files and some tools (eg. stubify)
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-2.05-5.i686.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-2.05-5.x86_64.rpm
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-2.05-5.src.rpm
Note that one can use
ftp://ftp.delorie.com/pub/djgpp/rpms/djcrx-bootstrap-2.05-1.src.rpm

for bootstrapping

See
http://gcc.gnu.org/gcc-6
for more information about GCC-6.1.0 and about changes in comparison
with earlier versions

Also see file gnu/gcc-6.10/readme.DJGPP (from gcc610b.zip and
gcc610s.zip) for more information about this port.

There is also my web page about DJGPP port of GCC

http://www.iki.fi/andris.pavenis/djgpp/gcc

I cannot promise however, that I’ll update it very often.
However new versions may appear there earlier (including ones not available
from ftp://ftp.delorie.com).

Andris Pavenis <andris DOT pavenis AT iki DOT fi>

UAE’s 68000 core actually was once in MAME

I was kind of surprised to find it.

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]
    Differences:

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 2.7.2.1, a vintage compiler from back in the day I could just run in DOSBox.

Alien Syndrome

Alien Syndrome

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.

System 16

A long long time ago, back when I got a Pentium 100 the wonderful world of emulation was really starting to be possible with such a high powered CPU.  First was the simple Game Boy emulators, then a Commodore 64 emulator, the incredible Amiga Emulator, the beginnings of SIMH (back when it was only a PDP-11 emulator), and then I found the SEGA emulator, System 16.

It was really cool being able to play 16bit arcade games on the desktop, although rather slowly.  From there everyone knows the rise of MAME.  But while looking around for a small 68000 C compiler, I came across the source code to an older version of System 16, 0.53 on archive.org.  Naturally it’s for MS-DOS, as was everything back in the day.  Also slightly interesting is the 68000 emulation, written by Bernd Schmitd of UAE fame.  So for the heck of it, I set about getting Thierry Lescot’s System 16 building again.  I’ve never used allegro before, so it was a bit of a fight to get a version of it to actually build.  It turns out that I should have been building version 2.11 with tools of that era (why on earth was I using GCC 4, and binutils 2.18?) and instead stick with GCC 2.7.2.2 and some much older binutils.  And in no time I had build the library, and it’s examples.  With that done, I was able to re-build System 16 with GCC 4.1.2 and get a binary!

Back in the day, I actually did have an Altered Beast arcade board.  Sadly it died in a move, someone near and dear just saw the PCB as “garbage” and tossed it.  Sigh, but I did have ROM dumps, as I did a refresh of it forever ago.  Anyways I still have the ROM files, so I guess that is nice.

Anyways I fired up the emulator and got what is known as the “jail bar” effect, which is from a bad ROM.

Corrupt tiles

Corrupt tiles

Notice the sprites

Notice the sprites

The System 16 splits it’s memory into a program space, a sprite memory bank, a tile memory bank, and RAM for stack and things like the palette.  As you can see the program is certainly running, and the sprites are good.  I did some poking around a bit later, and noticed that due to a logic bug, the texture ROMs are actually never loaded!

So a quick patch, and now we get Altered Beast up and running!

Altered Beast title screen

Altered Beast title screen

demo play

demo play

Well, now isn’t that great!

Not that I would imagine anyone would really care, I mean MAME is a thing, and even from the readme:

Altered Beast : No sound emulation

So it’s pretty quiet.  Additionally the source is pretty restrictive:

These sources can’t be used for commercial purpose, any new version of the
emulator done with these sources must specify my name somewhere on the screen
et docs and I must be informed about any new release of the emulator.

For anyone interested you can find the source & binaries out on sourceforge.

Just saw this gallery of old MS-DOS viruses on archive.org

And I have to say Casino is pretty funny…

From wikipedia:
The casino computer virus is a malicious virus that upon running the infected file, copies the File Allocation Tables (FATs) to random-access memory (RAM), then deletes the FAT from the hard disk. It challenges the user to a game of Jackpot of which they have 5 credits to play with, hence the name. No matter if they win or lose, the computer shuts down, thereby making them have to reinstall their DOS.

Visit the rest of the malware museum at archvie.org

 

Porting Quake II to MS-DOS pt5 – 3DFX, GameSpy, Quake 2, and The Universe

The following is a guest post / wrap-up of the Q2DOS adventure by [HCI]Mara’akate.q2dos_3dfx_4
In the last update sezero and I([HCI]Mara’akate) tied up most loose ends with regards to Q2DOS.  Specifically: adding in DXE support for mods and cleaning up some code from the early efforts.  During this time, a forum user by the name of ggorts (strogg spelled backwards!) mentioned the possibility of using an old Mesa version with 3DFX support in DOS. I worked on separating the ref_soft from being statically linked into a DXE form and sezero cleaned up any potential problems there.

I mentioned the possibility of attempting the Mesa port to sezero and he thought it was probably a wasted effort and thought making a ref_glide depending only on glide3x.dxe would be a better way to go with less overhead.  I started some initial work on it but quickly abandoned this side-project as I have no real glide (or even OpenGL) knowledge and didn’t have enough time on my hands to play around with it.

Around this time, we also separated the GameSpy browser code into a separate DXE for potential legal issues.  The GameSpy code was publicly released, but never officially GPL’d.  Using this method, other port authors could link against a gamespy.dll to add in the browser capabilities that connect to my GameSpy master server emulator (see QDOS branch for source code to that particular project).

Ggorts also came up with some code for us to be able to finally use the banked modes and Mode-X 320×240.  Though 320×240 Mode-X seems to have some issues with certain emulator configurations, for the most part it works OK.  This also helped us to get some ASM rendering code in from Q1 and help clean up the original mess that was the SVGA driver; a lot of unused code from Q1 was removed and sezero found a clever way to send the video modes list between the game binary and renderer DXE.

In any event, one night I figured I’d take a stab at trying to get Mesa working in Q2DOS.  Checking out the Mesa3d FTP and researching the various changelogs it appears as if Mesa 5 series was the last true effort with Mesa 6.4.x series being the last maintained version with 3DFX specific code.  I got everything to compile but ran into hard-lock issues no matter what I attempted.  During this time, ggorts found out some various small, but now obvious issues. Including increasing the stack size to 1MB and he hard-coded the ref_gl to only work in 640×480.  It took a lot of pleading but eventually he released his source with a static compile for Voodoo 1 cards only as he was testing this on emulators like DOSBox with glide support and PCem dev branch.

I worked on cleaning up the source and he produced some glide3x libraries for me for Voodoo 2 and Voodoo 5 as these were the only cards I personally owned.  Imagine my surprise as I first loaded it up and it actually worked!  And it was smooth with no rendering issues!

q2dos_3dfx_3

At this point, sezero became involved and worked very hard to clean up the Mesa compile issues, including various scary warnings and helped to update us to the final glide3x commit pushed to the development branch and Mesa v6.4.3 which was an unreleased maintenance update for Mesa v6.4.2.

It was a long journey to get the code all working together just right, and a big thanks goes out to the early Mesa crew including Brian Paul, Daniel Borca, and “KoolSmoky” and the mysterious ggorts fellow who pushed hard for this feature.

To recap, Q2DOS from the last time we talked now has:

  • 3DFX Rendering with Mesa v6.4.3 for all Voodoo cards.
  • Separated renderer so it is no longer statically linked.
  • GameSpy is now a DXE.
  • WAV streaming, which is practically free as opposed to the OGG format.

q2dos_3dfx_1
q2dos_3dfx_8

We are about at the end of our Q2DOS journey.  A few odds and ends with Mesa and Voodoo 5 SLI issues remain (though nothing too show stopping) and there’s a small wishlist of some unnecessary features but it’s come a long way from the initial null driver effort!

q2dos_3dfx_2*Neozeed

I have to say it is simply incredible to see how Q2DOS went from a very primitive ‘wow it works’ port to a full featured port.  Simply amazing!

For those who missed the adventure it starts in Part 1, continued in Part 2, Part 3 and Part 4.