Bob’s Fury Update: Bug Squished!

For quite some time I’ve had a very nasty bug in my game, where basically it would lock up whenever a sound was played through any sound device on my microbyte 386sx machine. What made this bug tricky to fix is that it worked perfectly fine on other hardware I had available and on the emulation I was using for testing (which was Dosbox).

I had already discounted any results from Dosbox, as it is widely known that the emulation is not hardware accurate. So I tested on the hardware I had available. Unfortunately I don’t have a lot of old 286 and 386 machines laying around, so I tested on the Microbyte 386sx and my Pentium MMX system. The big clue I got from that is that the sound code worked fine on the Pentium but not on the 386.

This is where I was stalled for quite a while, I tested much of the code and couldn’t figure out the fault. What I needed was another 286 or 386 machine to be sure it wasn’t just a quirk of the Microbyte, but this wasn’t something I could do easily. Recently I found an alternative solution that helped me solve the problem.

I have been watching some of Jim Leonard’s videos, as he makes some really good content about PC’s and is generally extremely knowledgeable. He had some of the same sorts of issues with developing DOS software using Dosbox for emulation, which is why he tends to use real hardware where possible. However he did recommend a PC emulator I hadn’t heard of called 86box.

So I downloaded 86box and fired it up. I was able to set up a virtual machine fairly quickly and found I could change some key configuration options I would later need. Most importantly I could replicate the crash in the emulator and experiment to find the cause.

Knowing that some aspect of the hardware configuration was causing the crash, I changed the configuration of 86box until the game didn’t crash, the key element turned out to be enabling the NPU. With it enabled the sound code worked a treat even on an emulated 386 system.

The reason for the crash, whilst difficult to work out, is actually quite simple. I have an interrupt hooked on $1C for playing sounds of any type, during the interrupt it would figure out the length of the next sound in timer ticks. This would use some simple floating point arithmetic.

Because I had configured the pascal compiler to use 80287 instructions and included emulation for when a NPU isn’t present the code would crash during the $1C interrupt. This would happen because of how the NPU emulation works. If a 286+ CPU encounters a floating point instruction and there is no NPU present it fires an interrupt, which redirects to the software emulation.

The problem plays out like this: In the main code there were some floating point calculations, these would use the emulation which could then be interrupted by more code also needing the NPU. This would mess up the internal state of the emulation causing a crash. This can’t happen with a real NPU because it can’t be interrupted mid instruction.

The solution was fairly simple, I turned off 80287 instructions and emulation and made minor adjustments to code so as to not require it. This got it working on real machines without a math-coprocessor and in 86box so I was quite pleased. I’m not entirely sure why I had used the 80287 code generation in the first place, but I can see why it persisted in my code for so long. Many of the machines I had tested on over the years were 486+ class computers, these all have the co-processor built in, so the problem wouldn’t appear. Dosbox didn’t expose the bug because there is no configuration option for turning off NPU support.

There is more work yet to do, such as implementing a lookup table to save on some of the calculations, and fixing other bugs. I’m now automatically packaging a download based on my most recent subversion revision which you can find here. I’m thinking about eventually hosting the binaries and code on somewhere like github.

Bob’s Fury Update: Bug Hunting

I’ve been doing some coding on Bob’s fury lately, basically making adjustments and making code faster in the hope that I could make it work well on a 286 class machine. I have been using dosbox to develop and test, but this doesn’t fully test the compatibility or stability of software as dosbox has its own quirks and does not behave exactly as real hardware does. This is where my old Microbyte 386sx computer steps in, here’s a photo from when I first bought it.

It has been very useful for performance testings as it has a turbo feature that is software controlled. You can not only toggle the CPU speed with a key stroke, but you can set the slower speed in the BIOS configuration. This has allowed me to test with the machine running at its stock 20Mhz as well as a slower speed, I’ve used 10Mhz for my testing as a rough equivalent of many 286 machines. The testing I was able to do has shown that my game should be playable on a 286 depending on the video mode. CGA and VGA both have acceptable speed for game play, whilst EGA is marginal.

The testing did however uncover a rather annoying and difficult to squish bug. If I have the sound turned on (PC speaker is all this machine supports) the system will freeze when a game event that plays the explosion sound happens. Hunting bugs such as this are difficult as there is little feedback about the potential causes. It sounds like the code supporting the PC speaker should be at fault, so that’s where I began the search for the bug.

For the PC speaker I found a support library many years ago that allowed you to use the music macro language used by the play statement in GWbasic and QBasic. It hooks interrupt 1Ch (the system timer interrupt) to update the state of the PC speaker. Whilst I haven’t had any previous issues I wondered if there was a fault that could cause the crash. At first I wondered if using floating point instructions could have been the cause. The library has a small section using floating point to determine the number of ticks a note should last. On a system such as the 386sx without a FPU such instructions cause an interrupt so that emulation in software can take over. This interrupt within an interrupt was what I thought may be the cause.

So I constructed a test program hooking the same interrupt and performing a series of floating point calculations as a test, this didn’t yield the result I’d hoped as the test program worked fine. So I then wondered if the 386 was getting another type of problem that would cause an unwanted interrupt. So I copied sections of code from the library into the test program to run in a normal procedure that would show run-time error messages and debug information I could use. No run-time errors appeared and the results of the required calculations appeared to be correct.

I have a few ideas left to test, but I’m left with quite a puzzle regarding the cause. This does illustrate the need for testing on actual hardware, it’s usually better to test on many machines. Unfortunately I don’t have a large supply of 286 and 386 class machines, although I have a few I may be able to repair. I need to test on another machine because there could be something specific in the design of the Microbyte machine that isn’t compatible and is causing the issue.

Bob’s Fury progress update

You may have noticed that I’ve been playing with a number of homebrew MS-DOS games lately. This has given me a little more motivation to work on my own project, my simple flick-screen platform game Bob’s fury.

The main body of work left is to create the levels for the game and any content required for them. For me this has been the hardest and most time consuming aspect of making the game as it requires a lot of play testing and planning. Recently whilst visiting my folks I had some time to produce a new level, I’ve updated the download to include it.

I’m hoping that it won’t take as long to build the next level, I got one pretty decent tip from watching some interviews of Brenda Romero. Basically the tip is starting at the end/goal and build outwards from there. I had been doing the opposite, which made the process harder, partly because you have to keep where you’re going in mind before having built the area.

The other stumbling block I have is coming up with ideas for levels. There’s not much I can do to stream line this, so it will probably continue to be a road block. I will probably simply make fewer levels for each “episode” so I don’t require as many ideas.

I’ve also released the level editor for any one interested. You can find it here.

Huffman Coding

Quite some time ago I did a short post about a compression technique called run-length encoding (or RLE), that was a commonly used compression method for graphic and level data. At the time I wrote and implemented it for the graphics and level data for my home-brew game Bobs Fury with quite the success, significantly reducing the disk space required for the base game.

I do however have some files left, which are largely just ASCII text, that don’t compress well or at all using that technique. I’d like to make them smaller, and of course harder to read as they contain story text, not that my game has a brilliant story, but you get the idea. Step in an encoding technique called Huffman coding.

Essentially the encoding algorithm encodes symbols as a variable length stream of bits. The most frequently used symbols are represented by shorter bit streams, whilst the least used have longer ones. Normally in a computer each symbol would be encoded as a fixed number of bits, such as say 8-bit or 16, so this results (hopefully) in shorter encodings for most symbols, and longer ones only for the rarely used ones.

The tricky part is creating the Huffman tree, which is basically a code-book representing how each symbol is encoded or decoded. Here is a quick tutorial on how they are created, which will also give you a feel for how the encoding works. It’s also commonly known as a dictionary, or code book.

A fixed tree can be used for everything, but would not do the best job for every set of data being compressed. So typically a tree is created and stored along with the encoded data to achieve the best compression possible. This of course does add some overhead, which could be a problem if the resulting encoding isn’t much shorter than the original.

Huffman coding typically works poorly when the symbols all appear in the text at roughly the same frequency. The worst case being everything with exactly the same frequency. Notably it won’t produce an encoding that is longer than the original data, although with the overhead of storing the tree, you could end up with a larger data file. In practise this rarely happens.

Other data such as English text stored in ASCII actually compresses quite well. As usually not all the 255 characters are used, most encodings will be shorter than 8 bits per symbol. Also because natural language uses some letters more than others the average encoding length for all the symbols will be shorter.

Huffman coding was actually invented quite some time ago (1951) by David Huffman, well before it came into common use. Check out the Wikipedia page for more information. It’s a part of many commonly used compression programs and formats such a Zip and Bzip. Older 8-bit machines typically weren’t powerful enough, so it wasn’t commonly used until more powerful machines with more memory became available.

It took me much longer than usual to write this post primarily because I began the process of writing an encoder and decoder, but because of the complexity, it’s taken up much more time than I expected. Currently I have just finished the encoder, but have yet to test it. I had hoped to get the code running first, but that will have to wait.

Improving Joystick support for Bob’s Fury

Some of the hardware support within Bob’s Fury has been far from ideal, the joystick/game pad being one such device. I had only added support for a simple 2 button joystick, as that’s all I had when I first wrote the code a long time ago. It proved to be inadequate as there just simply wasn’t enough buttons to support all the functions in game, and you couldn’t choose what the buttons do.

Old Joystick Configuration

So with the aid of a real machine and a Gravis game pad I worked out how the basic 4 button devices work. It turns out they aren’t much different. I had originally coded my interface to expect two joysticks, each with 2 axis and 2 buttons. It turns out that the buttons on the second joystick correspond to the 3rd and 4th buttons on the Gravis game pad, which means it was fairly simply to allow such a device to support 4 buttons with a minimal effort. I re-wrote the joystick hardware code to be a single joystick with 4 buttons and axis which should support most devices.

New Configuration Screen

Once I got the joystick code re-worked I didn’t want to give fixed functions to the buttons, so I had to recode the configuration interface to allow changing what the buttons do, which funnily enough took longer to get right than the hardware side of things. After some testing in Dosbox I’m pretty happy with the result. I still need to test on some real hardware to make sure everything works, and I need to test a two button joystick to ensure that still works as well. I’ll update the download once I’ve tested it on real hardware.

Download for Bob’s fury

This week, after much time thinking about it, I decided I’d finally offer my old school platform game, Bob’s Fury for download. I originally wrote it in Qbasic back when I was 14 with the help of my younger brother who did some of the graphics, levels and helped play test it. The idea for making my own platformer had grown out of playing two of my then favourite games, Xargon and Hocus Pocus.

VGA Screenshot

I originally had much larger plans for it, I had wanted to make water levels and puzzles like those in Xargon and run and gun sections like those in Hocus Pocus. At this stage I was still using gwbasic and I found that it was difficult to store enough graphics and tile information for one screen, it seemed like I wasn’t going to be able to build anything at all when I discovered Qbasic on the school computers.

Qbasic had many advantages, it supports a better graphics mode which allowed 256 colours at 320×200, then a common resolution for most PC games. The interpreter also had roughly twice the memory available to it which allowed me to use many sprites and get two screens per level. It took me roughly a year to build the engine and most of the levels. It was still quite limited in many aspects and didn’t live up to the original dream, but it was still a significant achievement.

Later in high school I had a computer studies teacher who did a bit of programming themselves. I know it seems odd, but not that many teachers of computer studies could actually program in those days. Anyway I was lucky enough that he gave me a copy of Borland Turbo Pascal 6.0, which was to be the first compiler I’d get to use. It was a bit of a learning curve, but I managed to learn pascal much quicker than either basic. I decided I wanted to port Bob’s fury as Pascal was a much faster language and wouldn’t be as limited as Qbasic.

EGA Screenshot

I had a few problems however when I learned the graphics library. Firstly I hadn’t encountered pointers before, and they were required for bit mapped graphics. So I experimented with some simple vector graphics at first. Also Pascal didn’t have any support built-in for the graphics modes I wanted to use. So I put off making a port until I could learn more about the language.

Shortly after I went to University and got internet access I was able to solve some of these problems. I practised and learned how to use pointers in general and I found files that provided support for the graphics modes I was after. By 1999 I had built much of the tools and libraries for graphics and a few ancillary libraries needed. I’ve been working on this port sporadically since then.

I’ve been reluctant to release it for a few reasons. The first one being it’s quite unfinished. I haven’t really made enough new levels, I’m only really half way through making the first episode. The bulk of the levels are actually from the original Qbasic version, which are obviously quite limited. I’ve built a system for playing Adlib music, but haven’t made any music yet, appart from tracks for testing the software anyway.

CGA in game.

So why am I releasing it? Well because despite the limitations it’s pretty cool, and I have fun playing it. (one of the reasons progress has been slow!) I want to motivate myself to get busy making more levels, now I realise there will probably be little interest in it, but stuff that I post about on my blog tends to get worked on. So having it here is a great motivation for doing more work and perhaps reporting progress as I get more done.

I’ve put a ZIP file on my download site here.

 

Adding CGA to Bob’s Fury

Bob’s Fury Title Screen

As a small project I decided to add CGA graphics capability to my DOS platform game, Bob’s Fury. I have already implemented EGA, VGA (mode 13h) and VESA (640×400) modes. I had hoped to be able to run the game on older machines including 286 class machines as a minimum specification. The trouble being that the EGA mode tends to be a bit slower because of the way its video memory is laid out (planar mode). VGA mode 13h works quite well, but machines of that vintage do not necessarily have a VGA card.

Bob’s Fury Gameplay

Early 286 machines were about 6-8Mhz, but had speed advantage over 8086/8088 machines because of being a more advanced processor. Later 286 machines got to about 16-20Mhz on average, but as high as 25Mhz about the time the 386 came out. This makes the 286 class an interesting beast as performance can vary quite a bit not only based on the processor, but also the speed of the RAM and chipset. It also spanned quite a change in graphics capability as it started when CGA was standard and lived until the early days of VGA.

Hence my desire to add CGA support.

EGA Screenshot

I haven’t written my own graphics drivers for the game, partly because that’s tones of work especially if you want to support multiple video cards. I’m using Borland’s Turbo Pascal 6.0 and I used the Graph unit built-in. It uses drivers stored in BGI files so you can write an application that works with a number of video cards and modes. This has made the programming relatively easy to add new graphics modes, which is part of the reason I started adding support for older cards. I have heard the disadvantage of the BGI/Graph system is that is can be slower performance wise compared with assembly code.

My main problem adding CGA support is the same as before, converting my existing VGA artwork to a 4 colour palette. I had solved this problem for 16 colours when I initially added EGA support with a horizontally doubled resolution, but because the only CGA modes with colour are 320×200 I wasn’t going to be able to do the exact same thing again.

CGA in-game.

I eventually worked out technique that I’m happy with. It’s a little bit more complex than the technique for EGA because of the very limited number of colours. I allocate CGA colours to the most commonly used VGA ones, then using the neighbouring pixels work out what the best CGA colour would be for the remaining VGA colours.

Whoa that’s a lot of green!

The end result is ok for CGA, but clearly not as good as the other modes. After testing I found it was quite a bit faster than EGA, but not as fast as VGA as expected. It means the game should run on a 286 of pretty much any type now. Whether they are slow or fast and have CGA,EGA, or VGA.

Thexder like EGA graphics conversion for Bobs Fury.

Recently I had decided to add EGA graphics to my DOS based platform game, Bobs Fury. The difficult part of course is converting the VGA 256 colour graphics to something in EGA that would look something like the original. I did not like the idea of manually converting or recreating the art work so I set upon creating a converter program that would do the work for the 150 different sprites in the game. The first kind of conversion I tried was basically mapping of colours in the sprites to the best match of a single colour in the standard EGA palette. I measured the difference in colour for each channel (red, green and blue) and added them together as a basic measurement of how different they were. This resulted in some odd colour choices by the converter. It picked brown in some cases where a green would have been more appropriate, and some other sprites where just way out of whack! At this point I also discovered that the graphics system would not allow me to use the 320x200x16 ega mode that I had planned on using. For Bobs Fury I’ve been using the Borland Graphics Interface (BGI) for drawing within the game as it allowed me to support a few different graphic modes without writing several low-level libraries for each graphics mode. It was also partly because when I started writing the game I didn’t have the experience necessary to create the low-level graphics libraries required. The best resolution that fit the game screen turned out to be 640x200x16 as the higher modes don’t have enough vertical resolution to deal with the higher resolution mode sprites I had created. It was at this point that I remembered the game Thexder and how it used the same mode to try to accomplish a very similar goal. You can see some details of this as recorded by Gemini (Kris Asick) on his web show Ancient Dos Games, click here for Thexder and here for Thexder the Second Contact. I decided I could probably modify my converter to double the horizontal resolution of the sprites, using two pixels instead of one for each in the low resolution sprites. Using a similar algorithm to before I did get some nice results, but still also some weird ones which didn’t even come close to the original at all. I was starting to think it wasn’t possible and that I’d have to convert the images manually when I was struck by an idea that actually comes from matrix math and 3D graphics. I decided to change how I measured the difference between two colours. What I did was to treat all the colours like vectors, and measure the angle between them and difference in length to decide which ones were closest in colour. Once I had picked the primary EGA colour that was the closest match, I went through a similar process to pick the second one. Adding it to the first and correcting the gamma so I could compare the final vector against the vector of the original. This seems to have given the best results that I could hope for, and has saved me a ton of work recreating the sprites in EGA. See the pictures bellow for a comparison of the VGA to the final EGA result.

VGA Screenshot

EGA Screenshot