Category Archives: MS-DOS

Links 386 Pro

Posted on by
7

Out on the course

Links 386 is one of those programs that is very easy to love to hate.  It was 1992, and PC’s were mostly being used for business, and high powered 32-bit machines were still insanely expensive.  And then Links 386 happened.  Before there was DooM, Links 386 was the ‘must have’ executive ball clacking device.  And the specs that you needed to run this game were really over the top.  At it’s heart was the Phar Lap 386 Dos extender, along with the virtual memory module.. Which most people would have to rely on.  Links 386 really needs over 8MB of RAM to run.  Yes, that is correct, in 1992 you were recommended to get 8MB (which should have been about $400-800 USD) So you can golf at your desk.  But as the name implies you also needed a 386 classed computer, although ideally you would have one of those new 486’s!  Links 386 also pushed the edge by wanting a VESA capable SVGA card that could use mode 101, 103, or 105.  Although the higher resolutions modes just ended up with logos everywhere, it really didn’t take enough advantage of the higher resolution modes.

Another interesting thing is not only does Links 386 have sound drivers (which means you need a sound card!) but it’ll do voice through the AdLib card.  Also it has a driver model, the WLZ, which I don’t know if they ever published or if people wrote additional sound drivers.

Links 386 installer

The installer is kind of cute, in that it’s flat shading is so old it’s now modern.  How’s that for crazy?

Installation is a snap, at only four diskettes.  They sold additional courses, and I only have one additional course, although oddly enough finding others online is pretty trivial.  However I had far less luck finding the program.  One nice tip to Infocom is that the courses include a score card, like the ones you would get on actual courses.  It really tied the package together.

Don’t copy that floppy!

Although for me, I really bought it for the manual.

Pebble Beach

And I have to admit it, Access Software did a great job.  Even all these years later, it looks great.  But no doubt scaling and placing all the textures is SLOW.  Incredibly slow.

Back in the 90’s I had a lowly support job, and I’d get flown all over the country to help out with issues, and it’d never fail that the regional director would have ‘issues at home’ and amazingly they’d always ask about running Links 386 Pro.  No doubt a lot of people upgraded machines, and got to brag to their buddies on how fast Links would now load.  Running at actual 386 speeds will take nearly a minute to render the screen between shots.

The DOS Extender was forever very touchy.  It took a bit of work to get around it’s issues, with the continuous conflicts with TSR’s, drivers, sound cards, video cards.. It was a nightmare of compatibility issues.  Not to mention that although Phar Lap 4.1 was DPMI compatible, it really didn’t play that nice with OS/2 or Windows.  Microsoft would later come to the rescue for this costed gamer market in the form of buying Links away from Access software, and putting out Microsoft Golf.  And much like SimCity, being able to run this under Windows make it immensely popular in the workplace, as all you needed to find were Windows drivers for your hardware, which vendors did actually support, unlike games.

It’s amazing how companies like Phar Lap, or Rational never did try to make an actual gaming platform for their extenders, leaving it all up to individuals.  My older self says that Microsoft’s rise to prominence in the 90’s was mostly due to their competitors incompetence, rather than their brilliance.

Although DOS Extenders like Phar Lap have been around since the introduction of the 80386, Links 386 Pro is the oldest one I know of.  If you like programs that try their best to bend the limits of what you can or should do, certainly check out Links 386 Pro!

EtherDFS

Posted on by
8

I saw this the other day, although haven’t had a chance to write about it.

EtherDFS just needs a packet driver on MS-DOS, and it implements it’s own re-director to communicate with a Linux file-server, using it’s own raw protocol.

It certainly looks cool, and looking at how it works, it should be possible to write other drivers to read/write other filesystems for MS-DOS.  It’d be more interesting (to me anyways) if you can write an INT 14 re-director using a 32bit DOS extender to make things easier regarding filesystem ports.

When I get back home, I’ll have to test this on my retro machine, as the idea of just needing a packet driver + TSR sure sounds like a LOT less memory than the Microsoft re-director.

Porting Catacomb3D to MS-DOS (DJGPP v1/GO32).

Posted on by
Reply

Catacomb 3-D for GO32

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!

At current I just put the source up, you can git it here.

Uploaded my cross DJGPP v1 environment to sourceforge

Posted on by
2

project is here.

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.
Download crossdjgppv1
Download crossdjgppv1

Epyx Rogue 1.48

Posted on by
9
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

Posted on by
Reply

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

Posted on by
2

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://takeda-toshiya.my.coocan.jp/msdos/index.html

 

 

 

MS-DOS 5.0 DPMI

Posted on by
6

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.