Category Archives: DPMI

Adding the missing part of DoomNew – audio

Posted on by
2

DoomNew, is a rather ambitious project by Maraakate, to attempt to revert the old linuxdoom-1.10 to something more akin to what shipped for DooM 1.9 using Hexen/Heretic source code to fill in many of the blanks in a very Jurassic Park like manipulation of it’s DNA (source code). It’s great and gives you a very cool MS-DOS based engine using the original Watcom tools. But there is always the one catch, which is that it relies on the original sound library, DMX.

And unfortunately, nobody has been able to get ahold of Paul Radek to see if he’d be okay with any kind of open-source license. So, sadly DMX has been a long-standing stumbling block for that ‘authentic’ super vanilla DOS DooM.

Enter the Raptor

Raptor: Call of the Shadows

Fast forward to a few days ago, and I come across dosraptor on github. I had a copy of this back in the day, it was bundled on CD-ROM or something. I am absolutely terrible at games like this, but I did remember this one being incredibly fluid, and fun despite me having no skill. Raptor was written by Scott Host, and it’s still on sale over on steam! The source had been cleaned up with help from skynettx, nukeykt and NY00123.

I went ahead and built it from source, and in no time I was up and running. I found Watcom 9.5 was the best path to go with. I even made a ‘release‘ for those who don’t want the joy of building from source, and of course picked up a copy on both steam and his site. While building the source code, and looking at the directory tree that’s when I noticed apodmx:

This is a DMX sound library wrapper, which is powered by the
Apogee Sound System, the latter being written by Jim Dose for
3D Realms. When used together, they form a replacement for DMX.

The DMX wrapper was written by Nuke.YKT for PCDoom, a DOS port
of id Software's Doom title from the 90s.

It also includes the mus2mid converter, contributed by Ben Ryves for
Simon Howard's Chocolate Doom port, as well as the PC Speaker frequency table, dumped by Gez from a DOOM2.EXE file and later also added to Chocolate Doom.

A few years later, this wrapper was modified by NY00123; Mostly to be built as a standalone library, while removing dependencies on game code.

So it turns out that Raptor used DMX, just like DooM!

Well, isn’t that incredible!

Now the first question I had, was apodmx a direct drop-in replacement for DMX? Well basically, yes! Let’s check out the Adlib driver!

DooM 1.9 intro
NewDoom intro

As you can hear, the intro is very different. But it’s playing at least. Ok how about E1M1?

DooM 1.9 E1M1
NewDoom E1M1

The Apogee Sound System is softer, and not quite the same as DMX, but compared to nothing I’m more than happy with it. The AdLib is kind of a weird card to drive, and I guess it’s not to surprising that there is such a variance.

How about a Roland Sound Canvas?

Nuked-SC55: Roland SC-55 emulation

Sadly, mine is inaccessible, but thanks to nukeykt there is the Nuked-SC55: Roland SC-55 series emulation. I had to setup the MidiLoop as expected, and configure DosBox for the Loop and now I have a virtual Sound Canvas. So let’s see how the two engines deal with a common instrument!

DooM 1.9 Sound Canvas 55
NewDoom Sound Canvas 55

Pretty cool, if I do say so myself.

ZeeDooM

I’ve uploaded my modifications to github, along with a copy of that old ZeeDooM I had slapped together ages ago. I’d taken the map source code from Romero, and the graphical/audio resources from Freedoom and slapped them together.

Building MAME 0.1 for MS-DOS / DJGPP

Posted on by
33

So as promised, a while back I had built a GCC 2.7.2.3 / Binutils 2.8.1 cross compiler toolchain suitable for building old Allegro based programs, such as MAME.  Of course the #1 reason why I’d want such a thing is that being able to do native builds on modern machines means that things compile in seconds, rather than an hour + compiling inside of DOSBox.

Why not use a more up to date version of both GCC/Binutils?  Well the problem is that the pre EGCS tools ended up with macro and inline assembly directives that were dumped along the way so that later versions simply will not assemble any of the later video code in Allegro, and a lot of the C needs updating too.  And it was easier to just get the older tool chain working.

It took a bit of messing around building certain portions inside of each step of the tools, but after a while I had a satisfactory chain capable of building what I had needed.

So for our fun, we will need my cross DJGPP v2 tool chain for win32, MAME 0.1, Allegro 3.12 and Synthetic Audio Library (SEAL) Development Kit 1.0.7 .

Lib Allegro is already pre-built in my cross compiler tool chain, all that I needed to add was SEAL, with only one change, 1.0.7 is expecting an EGCS compiler, which this is not, so the -mpentium flag won’t work, however -m486 will work fine.

Otherwise, in MAME all I did was alter some include paths to pickup both Allegro and SEAL, and in no time I had an executable.  And the best part is checking via DOSBox, it runs, with sound!

MAME 0.1 on DOSBox PACMAN hiding

Thankfully MAME has been really good about preserving prior releases, along with their source tree, and it’s pretty cool to be able to rebuild this using the era correct vintage tools, and I can’t stress how much more tolerable it is to build on faster equipment.

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!

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.

Null DooM, GCC 1.39, GO32 and DPMI

Posted on by
2

phew.

DooM via DJGPP v1 GO32

Around the time of the x68000 port of DooM, I was cutting down the DooM source for a null/portable version.  I never could get it to actually run either using EMX or  DJGPP 1.03, as I couldn’t get it to link to save my life with a constant never ending battle of unresolved symbols. After a while I just used what I had towards the x68000 version and concentrated on getting it up and running, and just shelved the null/portable effort.

Later on I wanted to get it running again as part of messing with another cross compiler, as DooM isn’t a trivial application to port and verify correct operation. And in the process of trying to get the null version to build and run on Windows using TDM GCC, I wanted to make sure it at least kept compiling with GCC v1.x.

Once more again I was able to compile individual files but unable to link.  But this time, I just looked at the diffs for binutils, I thought it should be somewhat easy to get hosted on Windows.  Although versions may point to binutils 1.0, I had to use binutils-1.9.tar.gz even though the diffs are against Mar 24 1991, and the source for 1.9 is dated April 17 1991.

My first effort gave me a linker that would happily link, but go32 would either refuse to run the executable, or just crash.  I was going to give up again, but I found mention in another file that DJGPP actually uses the linker from G++, the C++ compiler which was a separate thing in the late ’80s and early’90’s.  This time it worked, and I could link a trivial hello world style application!

Now that I finally had a cross linker actually working, I didn’t want to compile under emulation, so looking at the other diffs, they didn’t look too extensive. I went ahead ,and took DJGPP v1.06 and patched up the compiler & assembler to get a full cross toolchain.  And in no time, I had a null version of DooM running on MS-DOS well at least tested on DOSBox.

This was fun, and all but I didn’t see any easy way to do fun things like hook interrupts so I could get the keyboard & clock like any good MS-DOS program.  DPMI greatly eased this kind of stuff, so looking at the DJGPP history, DJGPP v1 version 1.10 actually adds preliminary DPMI support!  And in the next version, DPMI was much more better supported, however the binary format had changed from a.out to COFF as part of the move to v1.11. I was able to take the memory, and DPMI portions from the final v1.12 libc, and manually build and run them against the v1.06 library / dev tools.

And much to my surprise, it actually worked!  At least having the wrong format didn’t have any effect on how GO32 worked for me.

So feeling lazy, I snagged some of the support code from Maraakate’s revamp of DooM, just to make sure of the timer code, and the keyboard code, and again verified that I can build with the keyboard & timer ISR and I’m able to play the v1.9 shareware & commercial levels fine.  I haven’t done a thing to clean up or update the DooM source itself against all the dozens of bugs and issues with Ultimate DooM, or other games like Chex Quest etc.

I’m sure 99% of people wouldn’t care but you can download it here:

Win32_DJGPPv1_DooM.7z
Download crossdjgppv1

Although I’m using DPMI to drive realtime events, if I looked further at the GO32 v1.06 environments I could either figure out how it operates it’s timer, or modify the extender directly to drive the PIC timer and keyboard as I need.  But overlooking that, the vintage 1991 software is more than capable of running DooM.

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.