Building MAME 0.1 for MS-DOS / DJGPP

So as promised, a while back I had built a GCC / 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.

Author: neozeed

I live in SE Asia, doing generic work, enjoying my life & family

18 thoughts on “Building MAME 0.1 for MS-DOS / DJGPP”

  1. MAME 0.1 only supported five games, right? Of course, later versions got more games but ran much slower. I think they dropped DOS target circa version 0.100 (2005??), and nowadays MAME is modern C++ (AFAIK).

    If you want “-mpentium”, you need at least GCC 2.8.1. And EGCS wasn’t merged in until 2.95 (circa 1999).

    DOSBox is bad for compiling, but presumably even QEMU is faster (or obviously VBox). How long would it take under QEMU + FreeDOS? How long does it take now, cross-compiling from scratch?

    The “current” stable DJGPP for a long time (until 2015) was 2.03p2. (I’m not sure I’d personally even risk trying anything older unless forced.) The “p2” part was backporting Win2k-compatible patches from “beta”. So 2.95.3 built by 2.03p2 was circa Dec. 2001, hence new enough to finally run on XP’s NTVDM without problems. I know that’s not quite “cross-compiling”, but it’s close enough. I know you already know this, but that’s the way most compilation was done back then.

    (Although I’m still partial to building stuff in native DOS, but Intel will kill the BIOS by 2020, so time’s running out there. Use a RAM disk and software cache, install compiler to RAM disk also, then it’s fairly fast. But presumably you don’t want to shutdown + reboot everything, though bootable USB makes it fairly easy.)

    DOSEMU2 has had a revival in recent months, but that’s Linux only.

    1. For me the biggest thing is that I’ve been using x64 / 64bit versions of Windows since the first public beta of XP/2003 for the AMD64 platform, and later to the now defunct Itanium. And what I wanted is a tool chain that’ll run on Win64 machines with some ability to run 32bit exectuables, and as you know this precludes NTVDM. While Qemu/VMWare/VBOX are options, I’ve always found DJGPP to be not only incredibly slow, but easily corruptible due to running on MS-DOS. There is no getting around it, modern OS’s are just so much faster as the IO model in NT may have seemed like a massive step backwards in 1988, but it’s working pretty well in the present.

      I know much of the compilation was done via native tools under mixed mode hypervisors, as I too ran them under OS/2, the later Windows 95/Windows NT, and what always amazed me was how Windows / OS/2 native versions of GCC ran much faster. And much like how I did the Linux/386BSD cross compiler stuff, instead of the more traditional setting up binutils/gcc for cross compilation what I’ve been doing (and probably should have gone into more detail) was to take a build of these tools that is native buildable, and then re-building that on Windows. So this is not the stock GCC –target=i486-pc-djgpp –host=i686-pc-mingw32 type thing, but localized source re-built using MinGW, which I’ve found has given me much better levels of compatibility, especially getting GCC 1.40 up and running and cross building early Linux kernels.

      I should imagine with the UEFI only machines, that it should be possible to port the seabios to use that backend and provide some kind of bridge, much like how EFI/UEFI Mac’s can run Windows… Wasn’t there a hacked up project to bring MS-DOS/Windows to the Intel macs before bootcamp?

    2. > DOSEMU2 has had a revival in recent months, but that’s Linux only.

      But Microsoft provide Linux for Windows now! I don’t know how well DOSEMU2 would work on that, I have no idea of its limitations. It would be funny if the best way to run DOS applications on Windows 10 64-bit eventually becomes via Linux.

    1. Not StarTrek, the first Intel Macs were OS X only, and there was a hack to make a boot loader that emulated enough of the BIOS to load up Windows. But then Apple released bootcamp so it basically was lost as a project, the XOM, Xp On Mac.

  2. “incredibly slow” … yes, newer versions of GCC are not speedy overall, even compared to older ones, but that’s always been true. But DJGPP is not horribly worse than others, generally speaking (minus obvious lacks like “make -j4”).

    “easily corruptible” … actually, DJGPP is quite robust, stable and reliable, easy to install. I think there’s still a lot good about it, even if only for DOS proper.

    Even ignoring native DOS + BIOS, NTVDM, or cross-compilers (have you tried Roboard’s?), you do really have to be aware of QEMU/KVM and VirtualBox and even DOSEMU2 nowadays. AMD64 kinda botched the lack of proper 16-bit support (“brain dead” like the 286), but VT-X eventually added it back. I know most people aren’t sympathetic, but it’s still legacy, which was once extremely popular, so it’s fairly ubiquitous.

    1. why would I give up a protected mode OS for real mode + dos extender to do development? Targeting it is one thing, but actually trying to program in MS-DOS with what, Qbasic editor?

      And yes, it is great doing -j4 or j16 on larger systems. The dos target really is just historic at this point, or just a “yes it could have worked, but with the rise of DirectX everyone ran away”.

      A win32 native chain targeting DJGPP will always run faster and far more reliably than anything actually running on MS-DOS, be it in v86 mode, or as a guest under a hypervisor. MS-DOS just sucks at opening a lot of files, and it’s disk access is down right primative. smartdrv cannot hope to compete with the NT kernel.

      1. Win32 runs better because MS didn’t bother fixing anything else. Most other subsystems were also abandoned. You were not expected to target anything else beyond native Win32. They weren’t really trying to be compatible with competitors. (I guess that changed later with things like WSL.)

        I’m not nagging you to forcibly use anything, much less something you consider “worse”. I’m just saying that NTVDM was once widely used for DJGPP, but the popularity of Win64 broke that (plus Vista 32-bit wasn’t great either). Lacking NTVDM, you really need VT-X. That’s probably the only good rationale for totally abandoning the native BIOS.

        And no, you don’t have to use QB’s editor (although few other editors are still actively supported either): GNU Emacs, VIM, VILE, SETEDIT, JED, TDE, FTE, etc.

        Is it really that strange to want to develop natively? Cross compilation is cool, but honestly, I’ll take whatever I can get. Seriously, DJGPP is not what I’d call slow (except under emulator without VT-X, now that is painful).

      2. > And yes, it is great doing -j4 or j16 on larger systems.

        When these old projects have to build different things when building on DOS, I imagine nobody ever did -j builds for DOS before and the dependencies could be broken. I’m not sure that I want to be the first person to ever try these parallel builds, fixing makefile bugs is no fun 🙂

    2. Roboard’s stuff is on cygwin (yuck) and uses newer stuff which won’t build Allegro, nor anything of that era so it’s really not any use to me.

      1. No, it has MinGW standalone versions, I’ve briefly tested that locally.

        Whether newer GCC will or won’t build ancient (and abandoned) Allegro is nobody’s fault, just an accident.

        It doesn’t have to support literally everything, just enough to be useful.

    1. Never heard of it. Apparently it’s a 1991 arcade game by Konami.

      According to the MAMEDEV wiki, 0.1 supported five games: Pac Man, Ms. Pac Man (bootleg), Crush Roller, Pengo, Lady Bug.

      MAME 0.1 was released on 5 February 1997. (21 years ago!)

    1. I kind of recall some issue with cross building ar as part of the djgpp source, you may want to try a straight cross compile of regular binutils and see how that goes. Or like the early linker there may be some G++ components required.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.