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:
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 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 184.108.40.206, 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.
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.
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.
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!
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.
Sourceforge has been running ‘project of the month’ for a while now, and DOSBox won out! It is the second time they have actually won. For those of you living in a cave, DOSBox is a fantastic PC emulator geared at emulating not only early PC’s of the 1980’s and early 1990’s but also includes its own MS-DOS like operating system for running ancient video games. It also has been ported to numerous platforms, including Java, Android, OS X, Linux and of course Win32.
DOSBox is also used by some big companies (steam, gog) for the continued sale of old MS-DOS games. Who says old won’t sell?
I mashed in all you need to build it for MS-DOS under MS-DOS here.
It should be really simple, just run the Watcom C’s setvars, then go into the duke3d\source directory and run ‘wmake’ … All being well it’ll output some exe’s. I’ve also included the shareware data files so you can test your executables.