Anyway, with that bit of pointless exposition out of the way, I’d like to introduce you to the HLT instruction. It takes no operands, and simply tells the CPU to halt: that is, it will just stop what it’s doing and enter a low-power state until an interrupt wakes it up. It’s employed by operating systems today to conserve energy when the system is idle, but the intended use doesn’t really matter for this article. I was puzzled for a very long time when I came across a HLT instruction in Jazz Jackrabbit some time ago (more specifically, it was in the protected-mode extender that came with Turbo Pascal 7). I figured no DOS game would have any reason to use this instruction intended for operating systems, so I tried in vain to find an emulation bug in Aeon that would explain why a JMP instruction pointed to a HLT.

I finally fired up a debugger on a real DOS system and determined that there was no bug in Aeon. Jazz Jackrabbit was actually trying to halt the CPU. (Never thought I would write that sentence…) Actually, it was trying to halt the CPU from user mode, which according to the Intel documentation on the instruction should cause a General Protection Fault exception. This exception would then be handled in kernel mode, and in the case of Jazz Jackrabbit’s DOS extender, a handler would examine the user mode stack and take some action, then eventually return control to user mode. Basically, they had used a General Protection Fault exception to transfer control to kernel mode.

Why would anything do this? It made no sense to me, but once I implemented this behavior the game loaded up and worked just fine (well, except for the distorted sprites… bah, that’s another story)

Well, recently I’ve finally gotten a copy of Raymond Chen’s book. In it (also on his blog), he relates a story that Windows ended up spending a lot of its time handling Invalid Instruction Exceptions because at the time, causing one of those was the fastest way to switch to kernel mode. Doesn’t seem like much of a stretch that the authors of Turbo Pascal 7’s DOS extender would have used a similar technique…

One mystery solved. Now if only I could figure out those sprites.

• Optimized instruction decoding: emulation is much faster on x64 and a little faster on x86
• Fixed CD-ROM bug where Aeon wasn’t detecting some of the content in directories with lots of files
• Fixed bug where VGA VerticalEnd register was ignored

As always, the download is here.

I like them, but these games are really pretty strange – part adventure game, part RPG, part parody, and they somehow managed to be both epic and farcical. Not too many games could pull off the sheer number of puns they used. That being said, they aren’t without their problems – the combat ranges from clunky at best to aggravating at worst, although due to the game design fortunately most of it could be avoided.

One of the cool things about these games was how the solutions to most of the puzzles were completely different depending on whether you played the game as a fighter, mage, or thief, and the fact that you could import your character from one game to the next, so your character stats would follow you through every game. Five Quest for Glory games were made, the first four work in Aeon, but the fifth one was made for Windows 95 – there is no DOS version. Unfortunately, it pretty much only runs on Windows 95 too, so you’d have trouble running it outside of a virtual machine or an old PC. The final game is generally considered the weakest in the series, so it’s not that big of a deal, but I still like it as a nice epilogue to the first four adventures.

If you’ve never played these before, I’d still recommend them (if you can find them): simple, goofy fun, with some really great music. I should also mention, however, that Quest for Glory II was the only game in the series to never receive an official VGA makeover – instead, some very dedicated and talented fans created one a few years ago. They made a huge number of improvements over the original, but kept all the charm – and you can download it for free. Best of all, you don’t even need an emulator to run it :)

Anyway, the game port interface is actually pretty interesting in that it provides essentially no abstraction from the hardware. Learning how it worked made me finally understand what the deal was with every game needing calibration to work properly, and those weird dials on analog joysticks that I always had to fiddle with to keep the controls from drifting. If you already know how this works or don’t care, you won’t find this article very interesting, so you should probably stop now. Otherwise, read on…

Using a Joystick in DOS

DOS provides essentially no abstraction on anything except the disk (I guess that’s why it’s the Disk Operating System), so to work with the joystick, games would have to read a byte from the game port. Four of the bits of this byte are used to indicate the status of the first four buttons (or the first two buttons of each joystick if two are attached). The other four bits are used to indicate the position of the first four analog axes (again, or the first two of each joystick if two are attached).

Reading button status is easy enough: just look for whether the appropriate bit is cleared, which indicates that the button is pressed. Getting the position of an axis is another story.

You might wonder how an analog value can be transmitted using a single bit. The answer is: time. A DOS program first writes a value to the joystick port (any value will do), then immediately goes into a loop continuously reading the status byte. The axis bits will all start out at 1, and eventually will all drop to 0. The amount of time it takes for this to happen is proportional to the joystick’s position in that axis. The amount of time this takes is device dependent and can be measured in microseconds, so a game would count the number of iterations it takes for the value to drop to 0, rather than using timers or anything sophisticated like that.

Weird, isn’t it? Well, it turns out this makes a lot of sense.

The Hardware

I mentioned before how DOS provides no abstraction for most hardware devices, so you are left communicating with them directly most of the time. Most devices have some degrees of abstraction themselves, so this isn’t a huge problem, but the game port has essentially none. The classic joystick design that it works with was little more than a couple potentiometers (basically adjustable resistors if you are unfamiliar with circuits). Writing a value to the port causes some capacitors in the device to become charged. The speed this charge is lost depends on how much resistance is in the potentiometers (which is controlled by the joystick position and those crazy dials).

So that’s really all there is to it. A charge is placed on a circuit and the program waits for it to go away.

Emulation

For me, it was important to understand how programs would use the game port for me to emulate it properly. Fortunately, modern API’s make it a lot easier to read a joystick position, so it was trivial to query DirectInput for this. That means I just had to translate this value into something resembling a decaying voltage.

Fortunately, I knew that this charge decayed so quickly that DOS programs would generally just count iterations in a tight loop that looks something like this:

          mov cx, 0        ; initialize cx to 0 for a counter
          mov dx, 201h     ; set game port 201h to the dx register
          out dx,al        ; write any value to the port
start:    inc cx,1         ; increment cx register by 1
          in al,dx         ; read current status of the game port
          test al,1        ; check whether the joystick 1 x-axis 1 bit is set
          jnz start        ; go to start if the bit is still set

So at the end of this loop, the CX register will contain the number of iterations it took for the bit to drop to 0. Knowing this, I can “cheat,” and just use a counter myself instead of doing any complicated high-resolution timing. All I have to do is scale the position of the joystick and decrement this value every time a program reads from the game port. When the value is greater than 0, Aeon returns a 1 for that axis; otherwise it returns a 0. This approach has worked perfectly in every game I’ve tried so far, and it was really easy.

Modern Controllers

Modern game controllers are more sophisticated than this – they are designed to communicate using USB or some other proprietary digital protocol and contain all of the logic needed to convert an analog position into a digital value, so fortunately modern game developers don’t have to be aware of the hardware implementation of how their input devices operate anymore. That’s fine with me. I for one have no desire to go back to the days of calibration and fidgeting with dials.

To be honest, I didn’t play the game so much as I played with it. The scope is huge, and the dungeons were randomly generated and extremely annoying (in my opinion). Also, it was a pretty buggy game – I remember an odd glitch that seemed to be unique to my computer at the time where my character was utterly incapable of falling; I would just glide in the air if I walked off an edge. Regardless of its problems, it’s still a fun sandbox to play in for a little while.

Bethesda (the company that made Daggerfall), released the game as freeware. You can download it from here. It runs pretty well in Aeon, provided you have a pretty fast machine.

• Added game port emulation for joystick support
• Fixed bug allowing an interrupt window after some pop ss instructions which caused random crashing
• Fixed bug preventing SVGA from being detected in some programs
• CD-ROM emulation is much more accurate when mounting a host drive or an iso
• Host CD drive can now be captured
• Minor performance improvements to a large number of instructions
• Major performance increase for 4-plane video modes (EGA, Mode X)
• Added support for launching commands with command.com /c
• Fixed memory corruption issue when too many files were opened at once
• Added "Check for Updates" option to Help menu

I finally added joystick support! It’s not very configurable yet – just giving you access to two axes and the first 4 buttons on any standard gamepad/controller/joystick. A more sophisticated button/key mapper will be added in a future version.

As usual, the download is here. I’ve redone the website as well. Hopefully most will consider this an improvement :)

Update: There is a bug in the installer that will report the incorrect version when upgrading. You’ll have to uninstall the old version first, then the install will run correctly.

• Fixed long-standing issue with the InterruptEnable flag not always getting reset after a system call
• Enabled UI elements for configuring emulated hardware
• Fixed minor bug causing too many bytes to be loaded from exe files
• DOS IOCTL Get Device Info function is more accurate and less of a hack
• Fixed another bug with handling invalid DOS file names
• Fixed bug preventing DOS FindFirstFile function from returning certain directory names
• Fixed bug causing child DOS processes to sometimes inherit the wrong environment block
• Fixed bug with some special DOS devices not being recognized (NUL, CON)
• Improved VESA VBE 1.2 implementation
• Partial VESA VBE 2.0 implementation
• Added AAM instruction
• Fixed improper Trap Gate emulation on interrupts
• General Protection Faults are now properly raised when an invalid selector is loaded
• Fixed stack alignment bug from an exception on a pop to segment register instruction

Download it here. I’ll have more information on what’s to come up on the blog in the near future.

I’m still a lot busier than I was last year at this time, but I’ve settled into enough of a routine now where I should be able to be able to make more time for Aeon development and blogging.  I’m also going to try to keep myself on some kind of schedule so I get blog posts out more regularly.  If you’re one of the few people that have read and enjoyed some of my posts, I’ll try not to disappoint.

I mentioned that I’ve been quietly working on Aeon.  I expect to have a new build released soon (probably early next week).  Until then, here’s some proof that I’ve made a few improvements:

Under a Killing Moon now works, though it’s a bit slow.  I’ve added some more programs to the compatibility list too, and I’ve fixed a number of long-standing bugs.  As the complexity of the software I’m trying to emulate increases, the difficulty in debugging emulation errors goes up with it.  Finding some of the protected mode issues was incredibly tedious.  I’ll just say that I have a tremendous amount of respect for what the DOSBox guys must have gone through getting the level of compatibility it has today.

Going forward, I’ll be resuming the same type of posting that I did before, and also addressing some common questions I’ve been getting (where is the source code? why is it slower than DOSBox? why would I ever use this?)

• Switched to .NET framework 4
• Implemented x86 protected mode task switching support (Quake, CWSDPMI, C&C)
• Fixed bug with 80-bit operand floating point instruction decoding (XCOM)
• Added a few missing floating point instructions
• Tweaked DOS emulation to get programs compiled with DJGPP working (Quake)
• PIC now allows its base interrupt vector to be reprogrammed
• Rewrote address decoder to improve emulation performance
• Finally fixed issue preventing Borland’s RTM extender from working (Jazz Jackrabbit)
• Improved Sound Blaster DSP audio, should hopefully eliminate most of the playback glitches
• VGA LineCompare register is now properly emulated (Jazz Jackrabbit, Incredible Machine 2)
• Implemented instruction tracing for CPU trap flag (Second Reality – at least the menu loads now)
• Fixed bug in DOS EXE loader where maximum memory field was not respected
• Added support for ADPCM compressed playback on Sound Blaster (Traffic Department 2192)

This is pretty much a compatibility and performance update with no new application features.  There’s still a lot of open issues I’m looking into, but this should be faster and more stable than 0.60.

Download here.

In addition to lots of compatibility fixes, I’ve also made some significant performance improvements, including a (highly experimental) x86 –> IL recompiler.  There won’t be any major new features next time I post a build, but you should find that a lot of games that didn’t work before will work now, and with better performance.  Oh, I’m also working on finally fixing that stupid “Speed:” emulation throttle so it isn’t completely useless on everything except 100%…

I’ve finally got some spare time again now at least occasionally so I’ll try to get back to posting more on this blog.  No promises though…