So surprisingly -O2 -m386 -m80387 produced the fastest code using GCC 126.96.36.199. On DOSBox so yeah that means literally nothing. Rebuilding DOSBox with no floating support code gave a weird error about the pov being out of range.
Obviously the next thing to do is run this stuff natively.. .which means GCC 188.8.131.52 for NT. Oh this is going to be fun, but utterly pointless. Or maybe not.
I re-ran the tests using VMware. There is no audio drivers involved just plain MS-DOS. The red is DOS-Box while green is VMware for the graph with FPS being the measurement. Interesting how the numbers aren’t as varied like DOSBox, however the -m386 -m80387 proved the be the worst for VMware, while the 386 soft float was so incredibly slow on DOSBox but performs great on VMware. yay?
That’s right it’s Flight Simulator 4! .. Although it was more fun downloading it directly from Microsoft back in the day. That said you may find this one, from archive.org more interesting as it’s got a patched exe giving et4000 support!
Naturally you need to configure dosbox, or pcem to use an ET4000 compatible adapter to play this, but the driver does support 800×600 gameplay!
Going back to the FTP site, you’ll find various test builds of Excel & Word for Win16, Win32, and Windows 95! This could be the thing you need if you have to work with old documents and don’t want to go through the conversion fun. It’s a treasure trove of testing apps for mucking around on a typhoon kind of day.
Yeah! Over the MS-DOS collection over at archive.org is well over 2,500! Isn’t that great?!?
Well let’s take a peek at a few favorites…
Sadly DataEast’s greatest hit RoboCop doesn’t work correctly on the site, however if you were to do something evil like open up the inspector, and manually download the asset yourself it’ll load fine in actual DosBox. It’s a great side scroller, even 30 years later. Yes, 1989 was a long long time ago.
And speaking of SSI, Curse of the Azure Bonds and it’s ilk are available as well! I’m not sure how a board game company with a vast library (and IP rights licensed) could possibly fail so hard. Maybe the games were too difficult? Maybe they were too involved? I guess I’m guilty of it too, as I’m the uncleansed masses that preferred Fallout 3 to 1&2. Just as Diablo took off as it removed the clock, and turned it into action.
Project-X was a favorite shoot-em-up on the Amiga, although it being PAL was surprisingly significantly harder to play on my NTSC Amiga, with not being able to see all the screen, running faster, and the insane blinking of some timing with the sprites. I didn’t know there was a PC version, but yeah it looks pretty much like the Amiga version. And it was one of the larger issues that a 386 PC with VGA & a SoundBlaster really not only was as good as an Amiga, but was just plain better as PC hardware kept on improving while Commodore trapped in their downward spiral just didn’t innovate.
Rise of the Triad – The Hunt Begins, this was a soso shooter, but where it really shone was it’s multiplayer maps and combat. It was a awesome time waster on the LAN. I never tried it dialup, or even in modern times, but many fond memories of this game. And it didn’t need insane requirements, unlike say Quake. And it was surprisingly more fast paced than DooM. I wonder sometimes if they had released the source code to ROTT (2002) much sooner than ID released DooM (1997), or around the same time if it’d have achieved more retro popularity? Or was it more of as LAN game, and my experience with it kind of lacking in single player the prevalent feeling?
MechWarrior was at first this incredible 3D game where you could pilot a battle mech in the 31st century! How awesome! It changed the world from the table top rules of BattleTech – The Crescent Hawk’s Inception into something action based. Amazingly the genre for some reason never seems to get the massive appeal I always felt it should have. Although Mark Kern is trying to do something with Mechs & Kaiju over at Em-8er.
Turbo Out Run, a SEGA classic game. The graphics are … well caught in a world between 1987 and 1990. I guess they either didn’t want to push the PC too hard, or accidentally release a superior game on a non SEGA platform? It could have looked better. It should have sounded better. It’s ‘fine’ but I kind of call shenanigans. Golden Axe is way better.
So this is by no means an exhaustive list, I left out a LOT, as 2,500 is way too much to give any reasonable review without it turning into a book, but I scanned the first hundred or so and picked out what caught my eye.
I thought this may be something cool, if not kind of pointless. Anyways the MPU401 UART can be run like a traditional serial port with an IRQ, in intelligent mode, or just as a ‘dumb’ device you can just bit bang to talk to MIDI devices. So while playing with DOSBox I thought it’d be fun to take it’s emulation and plug it into Qemu.
And this is the end result.
It’s far from perfect, when it works it does tend to work well, although it fails to work with things like Return to Zork, but it does work with DMX’s sound code in DooM and the MPU401 driver for Windows 3.1
While doing this I was originally struggling with mapping the IO ports. Qemu has some functions to map in the memory model to assign a function that will trap read/write space. In this case base is 0x330 the base of the MPU401 device.
I was thinking that the port 0x331 needed to be mapped in the same way, but it turns out after looking through more of the source, it’s actually a word aligned access. So in that case you can use a switch to see which port is actually being accessed.
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.
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 184.108.40.206 / 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!
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.
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