Adding DOSBox’s MPU401 to Qemu 0.90

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.

register_ioport_write(base, 8, 1, mpu401_ioport_write, s);     register_ioport_read(base, 8, 1, mpu401_ioport_read, s);

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.

static uint32_t mpu401_ioport_read(void *opaque, uint32_t addr) {
     switch(addr&0xf)
     {
     case 0:
      return(MPU401_ReadData(addr,0)); break;
     case 1:
      return(MPU401_ReadStatus(addr,0)); break;
     default:
      return(0xff); break;
     }
  return(0xff);
}

Pretty simple, right?

And from there it’s a matter of mapping the DOSBox MPU code, along with the Windows interface code. Since I’m not using intelligent or IRQ mode, I just amputated the code where applicable.

If anyone wants to look at what I did to merge into anything else (and probably do a better job!) it’s on sourceforge as mpu401.c.

Otherwise the binary is available on sourceforge:

Download Qemu090b

Quake 2 for MS-DOS full playthrough

Playthrough by TheSlipGateUser

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“.

Visual Studio 2003 on Windows 10 & Errors with Desktop Compositing/Themes

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.

Broken Visual Studio

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.

I found the solution to this over on stackoverflow in this discusstion:[https://stackoverflow.com/questions/2422581/visual-studio-net-2003-on-windows-7-hangs-on-search].  The fix is a registry entry in the “HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers” key.

The required settings to devenv.exe is:

“^ RUNASADMIN DISABLEDWM DISABLETHEMES”

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!

Building MAME 0.1 for MS-DOS / DJGPP

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.

DOSBox 0.74 can run Windows 3.0/3.1 in 386 Enhanced mode!

DOSBox… in a box!

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.

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

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.

Installing Borland C++ 3.1 in DOSBox: Too many subdirectories!

too many subdirectories?!

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

Null DooM, GCC 1.39, GO32 and DPMI


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.

Calling MSSQL library from protected mode

I found this site, x86dos.gear.host with this incredible writeup on using a TSR to call a real mode ‘library’, which in turn calls another TSR.

call diagram

It’s really interesting.  And probably a lot more useful 10+ years ago.

In addition there is a patched version of DOSBox, that includes support for named pipes.

Hacking Flight Simulator 4 for multiple monitors

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.

It’s a great read here: on tinmith.net

And this also is why ASLR is so important on internet connected devices, and servers where you don’t want to have known addresses in RAM where you can find important ‘protected’ data structures.