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.

Bloxinies and Bloxinies II for DOS

One afternoon I had a bit of spare time, whilst looking around the doshaven website for something to play I ran into two simple puzzle games. Bloxinies and it’s sequel Bloxinies II. These were both made by Sebastiaan Jansen (also known as Thandor) in 2013 and 2016 respectively.

The first game is much like Paganitzu in many ways. Your character, Bloxinies has gone through a gate into a puzzle realm. It has to collect all the diamonds in each level before it can move onto the next, eventually to be able to return home. The levels contain hazards similar to those found in Paganitzu.

Technically the game uses CGA graphics and some basic PC speaker sound. The graphics are fairly well drawn for CGA, although there is basically no animation. Whilst it’s basic, the simplicity works with a puzzle game like this.

I found the levels a bit simpler than those in Paganitzu, but still quite challenging. The only thing that was annoying is running out of lives and being sent back to the start of the game. To make progress it’s important to conserve your lives as best you can, so when you return to a point of difficulty you have the best chance of success.

This slideshow requires JavaScript.

The second game is a much improved version of the first. Some new features have been added such as a few new enemies, gates and levers, the ability to use bombs, and extra lives. Notably there is multiplayer with a special set of levels. Each person has their own controls on the same keyboard.

There have been some technical improvements as well, mostly in the graphics which now supports VGA. Appropriately there is a significant improvement in the art, there’s more variety in the blocks that make up the walls in addition to the new features, making it more pleasing to look at. The sound system appears to have remained the same, retaining PC speaker sound.

The levels are more complex due to the new features, but at the same time have a shallower learning curve in the sequence. I feel like this is because the designer had more features to explore before increasing the difficulty. This gave me a bit more time playing before I hit any major road blocks, which were more punishing because of the lives system being carried over from the last game. Levels from the first game are included if you wish to play them with the improved graphics.

This slideshow requires JavaScript.

The only real complaint I have for both games is the lives system, which I feel doesn’t really belong in a puzzle game. Otherwise I quite enjoyed playing both of them. I didn’t get a chance to dive deeper into the multiplayer aspect of the second game, what with lacking a second player, but it does certainly look interesting. If you’re looking for a download you can find it here on the authors website. He’s included the source code for each game and a means for editing levels if you so desire. I was pleased to see it’s implemented in pascal, mostly because I use it myself for my own DOS projects.