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.

MIDI Mayhem on Windows 10

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:Opened device:win32
MIDI:win32 selected Microsoft GS Wavetable Synth
MIDI:Opened device:win32
MIDI:win32 selected USB2.0-MIDI
MIDI:Opened device:none
MIDI:win32 selected MIDIOUT2 (USB2.0-MIDI)
MIDI:Opened device:none

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:Opened device:win32
MIDI:win32 selected USB Audio Device
MIDI:Opened device:win32
MIDI:win32 selected USB Audio Device [2]
MIDI:Opened device:win32
MIDI:win32 selected Microsoft GS Wavetable SW Synth
MIDI:Opened device:win32

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.

QinHeng USB MIDI adapter

QinHeng USB MIDI adapter

Ugh.

Giving up on the MT-32

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.

Notice anything?

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:

mixer /listmidi

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:

midiconfig 2

And you are in business!  Fire up the UI and you’ll see:

DOSBox active on MUNT.

DOSBox active on MUNT.

Then configure your application for ‘general MIDI’ on port 0x330, and you should be good to go!

DOSBox DOOM v1.1 general midi

DOSBox DOOM v1.1 general midi

And, how does it sound?

Now for comparison, here is E1M1 with VirtualMIDISynth with SGM-V2.01 sound font.

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.

UAE’s 68000 core actually was once in MAME

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]
    Differences:

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
1-0 sequences).

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 2.7.2.1, a vintage compiler from back in the day I could just run in DOSBox.

Alien Syndrome

Alien Syndrome

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.

Just saw this gallery of old MS-DOS viruses on archive.org

And I have to say Casino is pretty funny…

From wikipedia:
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

 

Bringing back the WinZork demo via jsDOSBox

So with all the excitement with jsDOSBox it was about time I tried to get something from my old java dosbox stuff running again.

As a quick note, as of right now, you cannot boot into a disk image… Nor can you really run bat files, or any kind of drivers beforehand.  It’s basically either use a script that adds files one by one, or use an image file which gets mounted, and you run your exe/com file from that.

So here we go, back again is the old Fortran Dungeon (zork) compiled with QuickC for Windows, running on the working model version of Windows 3.0.

Dungeon via F2C

Dungeon via F2C

Click here, and enjoy!

For anyone interested my old post about this Fortran/Zork adventure is here.

 

JS-DOS

Well ever since Oracle managed to screw up Java into a mass of uselessness, it looks like javascript is going to save the day.

Yes that javascript.

That emscripten compiler now can build DOSBox.  Thats right, you can run DOSBox in your browser.  For more infomation check out EMDOSBox.

It works great with Chrome.

DOOM!

DOOM!

Check out this site, which has many games all configured.

I’ll have to convert out all my old stuff, which is just as well since java is effectively dead.

Blackthorne is now freeware!

From DOS ain’t dead: the game was added to battle.net as a free download (1,2).  But you don’t need a battle.net account to download it, just get the ‘executable’ here.

Then unpack with 7zip and rename some files:

$ mv _7770311E01264484BDC66FB81E4EF650 blthorn.exe
$ mv _126448A72F4442D39DCD600746EE09F7 data.dat
$ mv _C987F762EF304955BB86AB432FF6F847 manual.pdf

I set DOSBox to run about 20,000 cycles so it’s not tooo bad.

Blackthorne

Blackthorne

Wolfenstein 3D for DOS/4GW!

After reading about the Blake Stone compile fixes, as it was a Wolf3d port, I came across a post on the forum Wolf3d Haven about trying to find the source code to something called wolf4gw.  Now wolf4gw is a port of the Borland C source of Wolfenstein 3d to Open Watcom C++‘s 32bit MS-DOS extender DOS/4GW, done by ‘ripper’.

The project eventually gave way to wolf4sdl, and as they say the rest is history.

Sadly it seems that just about all the source copies of wolf4gw were lost, except I did manage to find an ‘improved’ version simply refered to as wolf3dx.  From the blurb:

Tricob has released the Wolf4GW-based source code of WolfDX. Included is a text file called (Tricob).TXT.

So I have been using Watcom 10.0 for Duke Nukem 3d, however, this version relies on the _asm inline assembler which was introduced in Watcom 11.  However Watcom 11c had issues with some of the assembly forcing me to go even further to OpenWatcom 1.3.  For me the install was easy, I used CrossOver to install OpenWatcom for DOS-DOS32bit only, copied the compiler into DOSBox, and played mostly with the makefiles, and finally got a working exe!

Screen Shot 2013-07-12 at 11.57.24 AM Screen Shot 2013-07-12 at 11.58.00 AM

I know it may not look like much, but really it is running in 32bit protected mode!

Since all of this is open/freeware/shareware I can redistribute OpenWatcom, the source to wolf3dx, and the shareware levels of Wolfenstein.  Naturally I’m using DOSBox to compile and test, but you can use anything that can run MS-DOS 32bit stuff.

Download my archive here.