The Micro-Professor MPF-1B

I’ve been meaning to get into building my own Z80 based micro computer for quite some time. This is because I did an interesting course as part of my degree where we learned to program 8085 micro processors and learned how to wire up extra memory to it. I did a project with a good friend of mine to build a simple voice recorder that behaved a little like an answering machine. I forget the full details of what we did but I remember it was a heck of a lot of fun.

MPF-1B with Manuals

Step in the Micro-professor, a Z80 based developement board targeted towards the education sector. I was lucky enough to see a few of them on ebay recently and doubly lucky to manage to get one for a reasonable price. The model that I have is the MPF-1B which has a very limited BASIC in ROM as well as all the extra on-board peripheral chips such as the Z80 PIO and CTC. It has a Zilog Z80A processor running at 1.79 Mhz and only 2kB of RAM which doesn’t sound like much, but seems much larger when programming in assembly.

The Micro-professor was designed and built by a company called Multitech in 1981. It has an unusual vacuum formed case and comes with a series of manuals including sample programs, schematics for the board, ROM listing and basic information for programming the Z80 CPU. Multitech later became Acer in 1987 and in 1993 sold the Micro-professor and associated materials to Flite electronics who still make and distribute the system.

Like many other developement boards of the time you interact with the machine via a very basic keyboard and 6 7 segment displays. This actually works well for inspecting memory and entering your hand assembled code. That’s right, the programs need to be entered in hexidecimal and thus assembled either by hand or by a cross assembler that produces convenient output.

Here we see the complete board in all its glory. It’s a very compact design mostly because the Z80 didn’t require as many support chips compared to many contemporary micros. This particular example is hard to date as the chips have a wide range of date codes on them. For instance the 8255 is dated 1981 where as the CTC chip is dated the 5th week 1987.

Here we can see the key overlay and display reference for the BASIC built into the ROM. I tried it out but found it was too limited for anything but the most mundane computations. Systems like this were really designed for learning machine language and hardware principles. The BASIC was limited because of the limited size ROM it had and the limited nature of the machine.

Here is  a close-up of the display and keyboard. The monitor has an impressive array of functions available at the keyboard including loading and saving memory to tape. I have tried using the tape system connected to my PC but I was unable to load any code into the MPF, although saving appeared to give audio data.

I remember the 8085 systems at uni didn’t have a keyboard or display at all, they instead did everything via serial line, which was quite good because the set-up allowed coding and assembly on a local unix machine then transfer directly to the micro for testing.

Close-ups of the chips showing their date codes.

Finally a picture from the manual showing part of the schematic for the machine. These manuals are very detailed and will certainly be very helpful.

The long-term plan is to learn about interfacing devices with this board in an effort to learn enough about the Z80 that I can build my own complete system. The first expansion I hope to build will be an external RAM module that will either add 32kB or more in a banked configuration. I then want to build an interface that allows an Arduino to read and write to all the memory in the system so I can simplify loading and saving programs. After that maybe I’ll add a multi-line LCD onto the outputs of the PIO chip to perhaps make the machine a bit more interactive. Considering I don’t have any parts yet, it could be a while before I accomplish any of this.

I have found one thing that will be handy, a nice Z80 assembler that will output in Hex or a number of other formats. This will save me hand assembling everything! You can find the cross assembler here.

Run-Length Encoding

I hadn’t quite gotten over the horrible cold this weekend, and have had to spend most of my time looking after children. So today’s post will be a short one. I’m looking at a very basic data compression technique frequently used in many older micro-computers of the 80’s to store level information and graphics for games.

The technique is called Run-length encoding (often called RLE), it takes advantage of repetition in data to reduce the storage requirement. It used to be a common compression technique for encoding graphics, but can be used effectively to encode level data or anything that has repeating data in it. The GIF image format is a well known example that uses the technique.

The encoding algorithm is very simple, you simply encode runs of data (repeated identical data) as the number of repetitions and a copy of the data. So if you had data that looked like this aaaaabbbbcaaa it could be encoded as a5b4c1a3. The trouble with this scheme is the worst case scenario (different data every byte) can actually increase the file size significantly, in some cases resulting in a larger file than uncompressed. You can avoid this scenario by encoding the start of a run as repeated characters with single characters representing themselves. This results in the previous data being encoded as aa5bb4caa3 which goes to show that even that technique has its downside.

I wrote up a quick implementation in pascal as an example and used it to compress some data files from my DOS platform game, Bob’s Fury.  The first two data files I tried were the graphics data files which you can see compressed quite well, this is because there are many long runs of the same colour pixels. The third data file takes it to the extreme, it is a level data file that is pretty much one big long run of empty spaces, it compresses to an impressively small size. The fourth data file is normal level data (albeit a much larger level), it is much like the graphics data in that there are many runs, but it has some data at the end which does not compress well resulting in a worse ratio. The last file in the table is actually an ASCII  map file detailing the contents of the executable for the game, it is useful in determining where errors are in the code, but this clearly shows that ASCII data is unsuitable for this compression technique, it resulted in a much larger file!

What follows is the pascal code I wrote for this quick test. It needs the buffer unit I wrote for buffered reading and writing files. You can also download the source file from here.

Heretic for DOS

Today I was going to write about some new hardware I acquired, but unfortunately me and my family are sick. So I’ve spent a good part of my weekend caring for my kids and partner. So I took some time to investigate a game based on the engine of one of my favourite DOS games, Doom.

Heretic

Heretic was made by Raven software in conjunction with iD software and released in late 1994. Having licensed out the Wolfenstein 3D engine it was only natural that iD would continue to do this for all the engines they have made since. Doom was still the best 3D engine around until the later Build engine and Quake became popular. I’ve never played Heretic before, today I managed to play most of the way through the shareware episode, I didn’t have time to complete any more.

Gargoyle

Being based on Doom, Heretic has very similar technical specifications and thus runs on similar hardware. Although some minor features were added to the graphics renderer such as particle effects for splashing in water. The main differences are in the artwork, level and sound design.

The artwork for the sprites and levels is pretty good for each individual item, but as a whole they don’t have the same cohesiveness and presence that the Doom artwork does. I also noticed that it either looks too dark or with the gamma increased a bit washed out. I guess it is just personal preference, but I just like the artwork of Doom more.

Intermission

The sound design suffered a similar fate, all the individual sounds are fine in and of themselves, but the way they are used and combined with the artwork it just doesn’t feel right. Again just a personal preference, but Doom has much better sound which successfully creates a feeling that is hard to describe. The best I can think of is a sense or urgency and being scary/evil at the same time.

Wand Fodder

I didn’t get to use all the guns in Heretic as I was playing the shareware version, but the ones I did use were clearly just modified versions of those found in Doom. Firstly you have a staff as a melee weapon which is basically just a sprite swap from the fists and some gauntlets which operate the same as the chainsaw electrifying any enemies that get in your way. The Elven Wand is the weakest ranged weapon and basically equivalent to the pistol. The only major difference is that ammo storage is much smaller (half in fact) making it easy to use all your ammo quickly.

Crossbow or Shotgun?

The Ethereal Crossbow is the equivalent of the Doom Shotgun, the main difference being that the crossbow shots projectiles rather than instantly hitting its target. It also has a narrower field of fire and fewer projectiles per shot which can make it even harder to hit a moving target.

Chain Claw I mean Dragon gun.

The Dragons Claw is the equivalent of the Doom Chaingun. It has a very similar fire rate and has its own separate ammunition supply unlike the chaingun. It doesn’t seem to have the ‘cha cha’ effect on enemies however, but is still quite good for knocking out a crowd of enemies. The Ethereal Crossbow is probably the easiest one to use on a regular basis, but the other weapons are just as good in a pinch under most circumstances.

A powerful read

Again as it was the shareware version I played I didn’t get to see all the enemies, although what I did see wasn’t as varied as those in Doom. The first bad guy you see is a small red demon creature (Gargoyle) that can only perform melee attacks. It is refreshingly different from most of the Doom monsters in that its small size and ability to fly mean it can access more of a level and may seem to come from no-where. The other main enemy is a Golem which basically looks like a man made of mud wrapped in bandages like a mummy. The Golem is fairly slow and again only has a melee attack, individually they aren’t dangerous but in groups can be a problem. Both these enemies also have a variant which can shoot a projectile attack with little change otherwise. There are only a few other creatures in game.

Power Wand

You might think from my description that Heretic is a bad game, but that’s far from the truth. It is just so similar to Doom that I can’t help but compare the the two, and because Doom sets such a high standard Heretic comes out looking a bit mediocre. Heretic has many great features in common with Doom and a few of its own, but it does too little to differentiate itself and become its own game.

Now back to resting and looking after little ones.

Caves of Thor

Demo Screen

Caves of Thor is an early Apogee game originally developed by Todd Replogle under the Scenario Software name in 1989. It is ASCII graphics action-adventure game in which you play the titular character Thor. You’re trapped in the Caves of Thor and need to find three magic items in order to escape.

Lava

The game doesn’t use any kind of graphics at all, instead it uses the 40 column text mode in combination with some very basic ASCII art. This technique proves to be quite effective in-game, all the objects have reasonable representations and scenery such as the lava and torches are animated very nicely. Because it uses ASCII art, Caves of Thor will run on almost any machine you throw at it.

A sole enemy

Sound is also very simple, coming from the PC speaker only. The first thing you hear is the music on the demo screen, which is a rendition of Flight of the Bumblebee. It’s not a very good rendition, but it couldn’t be given the hardware. The in-game music is better but will still annoy you after a while. Luckily you can turn it off in favour of the sound effects which are mercifully easier on the ears and not over used.

Water

The controls are nice and responsive, but you should play on a machine with a numeric keypad. You need it so you can move diagonally where required. I made the mistake of playing on my Macbook which doesn’t have the keypad, this made some sections harder than they should have been. Also I noticed if you hold any movement key down you can move faster than the screen will scroll, this means you should only hold the keys for short periods otherwise you could land in a pile of lava.

Dungeons

The weapon you have is not named, it is simply a dash that travels like an arrow in the direction you’re facing. You can only have one on-screen at a time. If you continually press the fire key it will simply replace the weapon on-screen. So it’s usually best to let it hit a target before firing a new shot. It also means being closer to your target allows you to fire faster, which is helpful when destroying the Thoar beasts.

Lava as a barrier

Given the goal of the game you’ll send a good portion of your time exploring and searching for keys. Be careful where you use your keys as they are in short supply. There are plenty of enemies to kill along the way, and in addition to your weapon there are potions you can use to kill enemies gathered around you. This is handy when surrounded by lots of enemies and their spawn points. There are often lots of enemies and spawn points around important areas that may have keys, Thoar beasts, or the magic items themselves.

Despite the simple presentation Caves of Thor has quite a bit of appeal. Exploring and fighting are fun and not too difficult. It isn’t too time intensive either, you could probably complete the first episode in an hour or two. However it does lack depth that later similar games have, but this lack of depth is an asset for someone short on time like myself.