Pharaoh’s Tomb for DOS

Title Screen

Pharaoh’s Tomb is one of the earliest titles in the Apogee library being released back in 1990. It was designed by one of the key members of Apogee, George Broussard, before he became part of the company. He originally released the game under the Micro F/X name. It uses the same FAST engine developed by Todd Replogle that was used in the games Monuments of Mars and Arctic Adventure which were both produced around the same time.

I had a quick look into other titles developed by George Broussard and found that Pharaoh’s Tomb was his first commercially released platform puzzle game. This may explain some of the design issues I’ll mention and why Arctic Adventure was vastly improved over this title.

Special Notice

Like the other games, Pharaoh’s Tomb uses both CGA for graphics and PC speaker for sound, which are about the same quality as the other games: about as good as you can do with the technology used. From what testing I have managed, I think it would have worked reasonably well on even the oldest PC’s except perhaps 8088 based machines.

The game has you playing as an archaeologist called Nevada Smith, an obvious reference to Indiana Jones. You job is basically to explore a pyramid gathering treasure as you go, and of course survive the various traps you’ll find along the way. Many of the hazards are similar to those found in the other FAST games, but there are a couple of additions.

The Pyramid

Something that struck me as soon as I started playing was how much harder Pharaoh’s Tomb is compared to the other games. One of the main issues is the collision detection, which seems to be much more of a problem. It feels like the designer has used the collision detection to make the game harder rather than design the levels to minimise the issue. Combined with having a limited number of lives this makes it very difficult to progress very far.

The Anteroom

The designer didn’t stop there however, some treasures and objects are either totally unreachable or trap you, leaving you alive but unable to complete the level. This forces you to memorise the levels and just plain feels a bit unfair. It can be quite frustrating.

Interestingly the game has a screen talking about the collision detection system that the others lack. It explains that all the objects use bounding boxes for collision detection basically as part of the FAST engine and that you should be careful when near objects. I think they must have known the collision detection was an issue, but perhaps didn’t have a good solution.

One Mis-step….

Because of these issues Pharaoh’s Tomb unfortunately doesn’t play as well as either Arctic Adventure or Monuments of Mars. It still has some of the same charm, but the frustrations with the collision detection and level design make it much less fun to play. Like the others it was made freeware in 2009, but I would suggest you play the other games. Arctic Adventure retains much of the difficulty, but makes it less frustrating with unlimited lives and many other additions. Monuments of Mars similarly has unlimited lives, but also works better with the collision detection resulting in what feels like less unfairness.

ESR Meter Repair and Investigating Jitters

This weekend I decided I’d tackle a repair that has been waiting quite some time. A bit more than a year ago I built an ESR meter from a kit. The version I have is the 2007 Bob Parker meter that was featured in Silicon Chip. I built the kit and was quite pleased with the result except during calibration of the battery voltage warning I manage to break the trimpot. Fortunately the unit still worked quite well, so I wasn’t all that concerned, the only downside being that it warned of a low battery all the time.

This weekend I happened by Jaycar to buy some unrelated stuff when I remembered the damaged trimpot and looked through the parts bin. I didn’t remember the value of it exactly, I thought it was around 200k Ohms. So I ended up getting a 250k part as it was the closest value, thinking that would be close enough. However I had remembered the value incorrectly as it is actually 10k Ohms.

Rather than going back and looking again for another part I looked at the circuit diagram. It seemed that the resistance value of the trimpot shouldn’t matter too much. Here’s a diagram of where it fits into the circuit.

It looked like the trimpot is basically providing a voltage for the IC to detect a low battery, it also has a resistor either side to limit the current flowing through it. I figured the higher value should only reduce the amount of current flowing through the trimpot and that I’d still be able to adjust it such that the IC would get the correct sense voltage. So I went ahead and replaced the broken one with the 250k new one.

After fitting the new part I tested the meter, it powered up and didn’t report a low battery, success! I needed to adjust the trimpot so that the low battery alarm would work correctly. I didn’t have a variable power supply so I created the low voltage by putting in some older cells that had about the right low voltage I needed. Adjusted the trimpot and checked that good batteries continued to not set of the low battery alarm.

As an extra measure I checked the meter against the calibration resistors to make sure the meter is still accurate.

This slideshow requires JavaScript.

Something else I heard about recently was people finding trigger jitter in particular models of Rigol Oscilloscopes. I first heard about it from watching a recent EEVBlog episode where Dave does some tests on his own equipment. I decided to test out my Rigol DS2072.

First let me explain trigger jitter a little. An oscilloscopes trigger mechanism is what starts the scope both capturing and displaying at a particular point in a waveform. Trigger Jitter is basically a situation where the scope will not start at the same part of a waveform each time, causing the waveform to literally jitter backwards and forwards on the display. This can be a problem if timing is sensitive in the signal and for performing some measurements.

Unfortunately I don’t have a signal generator (something I should rectify) so I had to use the 1Khz square-wave output on the scope normally used for compensating the probes. At first glance it wasn’t apparent that there was any jitter at all.

I also checked the AC coupled waveform and didn’t see a difference, then I realised I should probably zoom in on the waveforms to see if the jitter was just too small to see on the scale I was using.

I checked the DC coupling again like Dave did, checking intervals to see if there was any periodic jitter. I found none just like he did.

I then checked the AC coupled version and you can see here that there is indeed some jitter. I didn’t realise it when I did the test, but this is actually a different instance of jitter than what Dave on the EEVBlog found. He was testing AC coupling for the trigger input, here I’ve tested AC coupling on the input itself. I’ve run out of time this weekend so I’ll test the trigger coupling soon, but this illustrates that AC coupling on the input can also cause jitter in these scopes.

So what does this mean for me and using my scope going forward? Well as long as I use DC coupling I don’t have to worry about it, as that doesn’t seem to have the issue. I need to be aware of it when using AC coupling, and use appropriate means to reduce the problem. Although given what I’m interested in, I’m fairly unlikely to really need AC coupling most of the time as digital circuits that I’m interested in can be probed with DC coupling mostly. I’m still happy with my scope, although I haven’t had much call to use it for a while.

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.

 

Tubular Worlds for DOS

Tubular Worlds

Today’s game, Tubular Worlds, is a horizontally scrolling shoot ’em up seemingly inspired by the likes of R-type. It was created by Creative Game Design and published by Dongleware Verlags GmbH in 1994. I’ve never heard of any software from either company in the past, so when encountering this game on a shareware magazine cover disk I had no idea what to expect. The magazine simply called it a “surprise” and offered absolutely no clues about the game.

Preparing for Battle

I remember the introduction sequence seemed quite atmospheric and intriguing the first time I saw it. It involves some kind of “Cyber legion cadet” gearing up for battle, which looked kinda like what I’d expect a borg drone to do before battle. This was all the story we got as the cover disk had no room on it for any kind of documentation. As it turns out the story isn’t all that important, as was common for most shoot ’em up games of the time.

Weird Creatures

Graphically the game is quite impressive, with some very nice and colourful VGA sprites and backgrounds. The sprites animate very nicely, it’s obvious lots of work was put into making them as arcade like in quality as possible. I think that in general the art style is influenced by Japanese games and animation, all the objects are quite detailed. One of the only downsides of the graphics is that it can be hard to see some of the incoming projectiles sometimes.

More Preparation?

Back when I first played the game we didn’t have a sound card of any type, and Tubular Worlds doesn’t support PC speaker so we were left with playing in silence then. Having played it now with a sound blaster I can say that we were missing out. The background music is catchy and has a quick tempo, but isn’t overly distracting. It’s not the best I’ve ever heard, but it’s pretty good. The sound effects are appropriately arcadey, and fit quite well with the music.

Early in the first level

The control options are the keyboard, mouse or joystick. The keyboard controls are precise, but I feel with the speed of the ship you lack manoeuvrability that helps in both getting power-ups and dodging bullets. I feel the mouse controls work much better, you can more easily dodge and collect power-ups. I didn’t get to try the joystick option as I didn’t have a suitable joystick at the time, however I suspect that it would work much like keyboard does, especially if you have a game pad.

Second level

I was never really into shoot ’em ups when playing on our DOS machine, having only really played much of Starfire, Overkill and Stellar Defence. So Tubular worlds seemed like something quite different to me at the time. One thing the others lacked was simultaneous multi-player, which is implemented fairly nicely here, only it makes the game a fair bit easier, so turn up the difficulty if you plan on playing with a friend.

The main complaint I have is the game is extremely short. The game is divided into 4 worlds each with about 3 levels and a boss stage. It felt like each level only took a couple of minutes to complete and didn’t really fully explore the possibilities with arrangements of enemies. I did only play the shareware worlds, so the other worlds may be longer, but most shareware games of the day just offered more of the same once registered.

Pointy Things

It’s quite hard for me to look at the wider picture as I’ve not really played many shooters, but it is clear that Tubular Worlds doesn’t really stand out as unique. I didn’t think it was bad, but there isn’t much that would keep me coming back to play more. I quite enjoyed playing the levels in the shareware episode, but wasn’t really impressed by the boss, it seemed uninspired and didn’t reflect anything about the levels that came before it. In summary, I quite like this game, and you might enjoy it more than I did if you’re into shooters. However it’s not really anything special by any means, so don’t be surprised if you only play through it once.

This slideshow requires JavaScript.