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!
At current I just put the source up, you can git it here.
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.
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.
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.
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.
So I know it’s ‘probably’ the super cheap generic USB to MIDI dongal I got on the cheap, but it just doesn’t work on Windows 10.
Using DOSBox, I get the following output when cycling between devices on the console:
MIDI:win32 selected Microsoft GS Wavetable Synth
MIDI:win32 selected USB2.0-MIDI
MIDI:win32 selected MIDIOUT2 (USB2.0-MIDI)
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.
What do you mean, giving up? Well I’ve been trying to buy one, and I’ve lost every auction. So I figured I’d check up the emulation scene and see what is up. Then I heard this video:
And this one.
Or at least to my ears, MUNT, sounds the same as the real thing!
So, how to use the thing? Well in Windows Vista onward (8/8.1/10..) Microsoft decided to hide the MIDI selection tools, making this a mission to see what mapper you are using. But using DOSBox it’s easy to see which is which. In DOSBox run:
0 “CoolSoft VirtualMIDISynth”
1 “Microsoft GS Wavetable Synth”
2 “MT-32 Synth Emulator”
In this case the MT-32 emulator is #2 on my system. Then to select this device, just type in:
And you are in business! Fire up the UI and you’ll see:
Then configure your application for ‘general MIDI’ on port 0x330, and you should be good to go!
And, how does it sound?
It’s impressive when you put them next to say the Adlib.
So maybe it was a good thing I kept on losing the auctions… But it’d still be neat to drive a real MIDI peripheral on a modern machine. Maybe I’ll win, one day.
I was kind of surprised to find it.
While I was looking for System16 stuff, I found the first version of MAME to include the UAE 68000 core starting in release MAME 28, although System16 emulation itself didn’t appear until MAME 33b3, but not playable until MAME 33b4.
So what does it mean? Well at the time the UAE core was the way to go. However from looking at the MAME source, the UAE core that they were using from System16 was already generated, while UAE still included the build68k program to parse the tables, and generate the 68000. Instead they were editing the outputted C. UAE wasn’t GPL until version 0.7(something), 0.7.6 for sure, so I don’t know why they weren’t using it from the source.
Eventually starting in MAME 35b2, the core was replaced with MUSASHI , so Among their reasons for dumping the early UAE CPU core was this laundry list:
- New 68000 C core. For testing purposes, this is also being used in the DOS
version instead of the asm core. [Karl Stenerud]
1. Faster. This code is, barring ram fetch time, almost twice as fast as the
existing C core in MAME. I’ve done extensive speed profiling on both
engines. The only problem now is the slow memory access in MAME due to
bankswitching et al.
2. Emulation more correct. I found many bugs in the MAME engine (and many,
many more in mine for that matter) when I pitted them head-to-head.
I have run random instructions from each opcode class at least 10 million
times, comparing the resultant CPU states, and have left it running random
instructions for 1 billion iterations. In every case, I have adhered to
the specs defined in M68000PM/AD REV. 1.
3. Disassembler is correct. The current M68000 disassembler in mame has a
tendency to disassemble instructions that have an invalid EA mode.
4. Cycle counting is 99.9% correct. The only instructions which don’t have
correct cycle counts are divs, divu, muls, mulu, and they’re not worth
counting correctly. (I’m not about to waste emulation time counting 0-1 and
5. > 32 bit friendly. I’ve taken care to ensure maximum portability without
sacrificing speed. The result is conditional compiling dependant on your
architecture. I’ve also implemented and tested a compatible solution for
architectures that lack 8, 16, or 32 bit signed storage types.
6. The code is carefully laid out to be readable.
Also in MAME 35b4 added in was emulation of the NEC uPD7759 chip for speech, fleshing out the System16 emulation.
To compile these ancient versions, and inbetween I was using my Candadian cross DJGPP GCC 4.12 Win32 cross compiler. For Allegro I’ve always found it builds far easier using GCC 22.214.171.124, a vintage compiler from back in the day I could just run in DOSBox.
Obviously with today’s machines, these ancient versions of MAME run fine on DOSBox! It’s really amazing in the scope of emulators running emulators.
And I have to say Casino is pretty funny…
The casino computer virus is a malicious virus that upon running the infected file, copies the File Allocation Tables (FATs) to random-access memory (RAM), then deletes the FAT from the hard disk. It challenges the user to a game of Jackpot of which they have 5 credits to play with, hence the name. No matter if they win or lose, the computer shuts down, thereby making them have to reinstall their DOS.
Visit the rest of the malware museum at archvie.org