I was just alerted to this playthrough of Quake 2 for MS-DOS by TheSlipGateUser which showcases the game play under DOSBox.
Honestly I’m terrible at Quake, QuakeWorld and Quake 2, but it’s great to see someone who knows that they are doing, and more so that under emulation the game is holding up.
I know the MS-DOS port isn’t exactly the most popular in the world, although I suspect if it had been a thing in 1997 there would have been an audience with people that didn’t want to have Windows in the background as a distraction.
That said, any new people will of course want to check out the excellent (if I do say so myself!) series “Porting Quake II to MS-DOS“.
While building the latest DOSBox SVN using Visual Studio 2003 I found something kind of annoying under Windows 10. The first thing is that if I search through the source code base, the application locks up, hard. It turns out that this has been an ongoing issue with Windows 8 (maybe Vista/7?) with Aero rendering of all things. The fix is to disable Desktop Compositing & Desktop Themes, but the application comparability tab is hidden on many applications for Windows 10.
See how the application preview doesn’t render anything at all? This is the hint that it’s broken. I think it may be worth sharing this ‘fix’ as I’m sure that other applications that behave strangely have the same issue.
Which, will run Visual Studio as Administrator allowing you to debug, and disable all the Aero assists for the application allowing things like search to work again.
I had gone further and enabled the Windows XP SP3 compatibility settings, however on doing a clean build I was presented with this error:
fatal error C1033: cannot open program database ''
Which I never could find any good source on what caused it, other than by guessing to remove the Windows XP flag, and now I’m able to build.
In order to do a full build of DOSBox I had to re-build SDL, SDL-net, zLib, libPNG, and set them to a common C runtime linker setting to get a build where the final link didn’t complain. However when it came to existing project files I did have to find some older Visual C++ 6.0 stuff for many of the components, but using those I was able to ‘upgrade’ them to the 2003 environment and produce a working set.
I’ve got to say, that the AVI capture in the newer branches (I’m using build r4177) is really great!
So as promised, a while back I had built a GCC 18.104.22.168 / 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.
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!
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.
I don’t know why I never tried it before, but it actually works! And it’ll even spawn out to a window two. Although without share/record locking it’ll end up being a world of pain, I suspect. Maybe vDOS/vDosPlus will work? I know it’ll work fine if you boot MS-DOS inside of DOSBox, but for some reason I never actually tried to stress the v86 mode of DOSBox from within Windows.
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!
So I wanted to install Borland C++ 3.1 under DOSBox to compile something ancient. I’m on a MAC so MS-DOS player is not currently an option. I have disk images, which p7zip can happily break down into files, giving me a bunch of files in a single directory, the perfect thing to mount as a ‘disk’ under DOSBox. However I had subdirectories with patches, source and other stuff in my virtual ‘floppy disk’. And the installer bombed. Turns out it wasn’t any file limitation, or anything in the guest C: drive, no the Borland installer doesn’t like sub directories on the install source.
Remove those, and it’ll install just fine.
Also, maybe it’s the weird Borland extender, but Borland C 2.0 runs WAY faster under DOSBox than version 3.1
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:
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.
This has to be one of the coolest things I’ve seen in a long time.
Long story short, Wayne was able to exploit a ‘feature’ of older non random address location where a machine is configured the same way will always load the same program in the same address space. Using this knowledge he was able to work out in memory where the location of the plane was kept in memory. Adding a ‘server’ and two ‘client’ versions of DOSBox he could then transmit the location of the plane to the two other DOSBox client’s and then just set their viewports to left & right, and now he has an immersive simulation.
As you can see it clearly can see the USB device, but when it opens the device it fails. And yes I’ve tried Administrator. And for the hell of it, I fire up Windows XP on VMWare, connect the USB dongal, and amazingly:
MIDI:win32 selected USB Audio Device
MIDI:win32 selected USB Audio Device 
MIDI:win32 selected Microsoft GS Wavetable SW Synth
Yes, I can open the out port just fine. So now I run a virtualizer to run my emulator to drive a physical peripheral… Ugh. Has MIDI been this messed up all along and I never noticed?
Oh yeah, the GS Wavetable Synth works fine, as did MUNT before I uninstalled it, thinking it was somehow interfering with anything.
I know I’m using this fine device, the QinHeng USB MIDI adapter, which apparently is notorious crap, but my recently acquired Yamaha MU 80, works fine with it on Windows XP.