27
Jul
14

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

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.

22
Jul
14

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.

Continue reading ‘Run-Length Encoding’

14
Jul
14

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

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

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

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

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?

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.

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

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

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.

06
Jul
14

Caves of Thor

Demo Screen

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

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

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

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

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

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.

28
Jun
14

Another Modem and a Canon XT Clone

I’ve come back to my parents to visit them again and have found some more interesting hardware hiding away including two modems and an old PC clone belonging to my younger brother. Unfortunately for my Dad, internet providers aren’t very good at providing good service to rural areas, he is too far to get any kind of ADSL service. This had meant that for much longer than others he had to rely on dial-up until alternatives became available.

I forgot to bring my own camera, but was able to borrow my mothers, which whilst it has a higher pixel count it didn’t seem to do as well in the shots I took. I’ve had to adjust these images for brightness particularly.

DSC00073

This Dynalink modem is a pretty basic USB modem, I unfortunately couldn’t open it for any internal shots but it’s probably not very interesting as it’s small and almost certainly a software modem of some type. Dad used it for some time and had problems with drop-outs so we went about getting a better modem.

DSC00074

So we got this modem, a SmartSwan Turbo which much like my own modem is a proper self-contained serial modem you can use without drivers. This one was bought a little later (sometime around 2003 I don’t really remember) and did perform quite a bit better than the Dynalink modem. Unfortunately given the line quality and distance to the exchange there were still some issues, mostly speed and the very occasional drop-out.

DSC00075

I was able to take this modem apart quite easily, just four screws on the bottom. Here is an overview of the main board, you’ll notice that it is an Ambient chipset and is a voice modem (although we didn’t use that feature). Unlike my modem this one does have a line transformer and a DIP mask ROM chip for the firmware. It also has some similar features, like what appears to be a rectifier chip in the modem front end. Interestingly there is a 74 series logic chip (surface mount) towards the lower right of the board, something that has become unusual in modern equipment.

DSC00077

Here are the two primary chips up close, I believe the left one is the main DSP doing most of the grunt work for the modem, the one on the right looks like the serial interface. I found it difficult to find the data sheets for these chips as Ambient was formerly Cirrus Logic and now is a part of Intel. The chips were made late in 2002 so Dad probably bought this about the same time I got my modem.

DSC00078

The front end has fewer protection devices and simpler circuitry with fewer passive components. It may be using an older design with some updates. Not being an analog circuit (or any kind of circuit) guru I can’t really tell. Next up I took some photos of an old XT PC clone, a Canon A-200 20HD. My younger brother bought this machine for basically nothing, which is extremely lucky considering how hard they are to find in working condition. I found an article on google books here that reviewed the machine when it first came out, you will need to scroll up to read the whole article.

DSC00079

The machine in all its glory! It is lucky enough to still have the Canon branded monitor and keyboard with it, everything seems to have yellowed quite badly, although at least it’s uniform. The keyboard is still nice to type on and doesn’t seem to have any defects, although it does have the older XT style layout. The keyboard is compatible with the IBM XT class machines so it is possible to use it on another machine or replace this one if needed. The monitor is a pretty basic green phosphor monochrome monitor that seems to have been treated quite well. There doesn’t seem to be any burn-in and it is still quite bright and easy to read.

DSC00080

Here I’ve pulled the lid off to expose the internals, you can see a Canon 360k 5.25 inch floppy drive and a 20Mb NEC hard disk that has unfortunately stopped spinning. Fortunately I have some MS-DOS 4.01 floppies that allowed me to boot the machine, but it took ages to get to the normal prompt. In the expansion slots you can see a memory expansion card, the graphic card and hard disk controller. The floppy, serial and a parallel controller are integrated on the main board which means there are some slots free for further expansion. The main processor is an 8086 at 4.77Mhz which can be at times significantly faster than the 8088 found in IBM PCs at the time. This is because the 8086 has a 16 bit data bus (as opposed to 8) and could move data and instructions faster over the bus.

DSC00081

Here is the graphics adapter, interestingly it is not a Canon part but is made by Twinhead judging by the logo on the board. I can’t tell if it is Hercules compatible but it most certainly is compatible with MDA cards. I didn’t get any clues from the chips as many are 74 series, memory or other generic chips.

DSC00082

This is a memory expansion card, these cards frequently have a few different devices on them as well. In this case what appears to be a real-time clock and a 25 pin RS-232 port. This card has 6 x 64Kb banks of extra memory (384Kb made with 4164 DRAM chips) which would have required a special driver for the machine to gain access to it. The machine finds 320Kb of ram, but this is most likely the memory on the motherboard.

DSC00083

Finally here is the hard disk controller, a Western Digital device much like a later 16 bit one I have in my spare parts box. This one is only 8 bit and has more parts on the board, one with an old school Toshiba logo. Controllers such as this one were very common in all kinds of PCs of the time. Unfortunately the hard disk doesn’t seem to work any more, perhaps it’s time this machine got an emulated hard disk of some type.

22
Jun
14

Man Hunter San Fransisco for DOS

Sierra

Sierra

Man Hunter San Fransisco is a Sierra adventure game from 1989. The Man Hunter games are murder mystery inspired, but is set within a Orwellian world. The world has been successfully invaded by aliens called the Orbs. The Orbs have little ability to move among humans undetected and find keeping the human populance in check difficult. Hence the reason they recruit some humans known as Man Hunters to pursue criminals. The first game ended as you pursued one of the worst – Phil cook – to San Fransisco and had ended the orbs influence in New York. Your job here in San Fransisco is basically to try to catch Phil and hopefully defeat the Orbs here.

Golden Gate Bridge

Golden Gate Bridge

It is unusual compared to the other Sierra adventure games in that there is very little text in-game, most information in the game is conveyed visually. The only time text is used in-game is when you die and the three creators give you a short clue or scolding. This was quite different as the other Sierra adventure games used text extensively and had a text parser to interpret the players actions. It was also the only early Sierra adventure game to feature more graphic death and a Orwellian tone.

He broke our fall

He broke our fall

The AGI engine this game uses supports Hercules, CGA, EGA, and PCjr which was common to most of the earlier Sierra games such as Kings Quest, Space Quest and Leisure Suite Larry. I obviously played in EGA mode as it is the best looking, although I found it strange that only half the horizontal resolution seems to be used. It is something peculiar to the AGI engine as other games using it had the same feature, perhaps it is something to do with support for other graphic cards.

Being a detective, investigating murders leads to some very detailed and sometimes gory scenes of the victims and their surroundings. Always look carefully around for clues around these areas!

Your new home

Your new home

Like the other early AGI games sound is either from the PC speaker or PCjr sound if you happen to have a PCjr or Tandy machine. The sound is quite basic and there is some simple music at the start in a short cinematic sequence. Fortunately the sound whilst simple is of a decent quality and won’t get annoying, but you can turn it off if you don’t like it.

City sky line

City sky line

Playing the game is relatively straight forward, you interact with the world in a point and click like manner, except you control the cursor with the keyboard instead of a mouse. You don’t have to select actions to perform as any hot-spot on-screen will automatically change your cursor into the appropriate action, which you perform by pressing enter. I found using items less intuitive as you basically just select the item out of your inventory to use it. This would normally just have you look at the item, so it wasn’t clear you could use items that way.

Using the tracker

Using the tracker

You need to use your special MAD (Manhunter Assistant Device) to track suspects using the tracking discs that the orbs implanted in everyone. Unfortunately you can’t get identification information as the tracking system does not transmit that due to a technical error on the Orbs part. So you must use clues found at the locations suspects visit to try and identify them. After all the Orbs want the names of the suspects. Using the MAD is fairly easy. When tracking the events at a location you can tag another suspect so that the tracker follows their movements. This can lead to other locations and more clues. If you happen to find a name or work one out from clues you can enter it into the information finder to get more details and an address.

Information search

Information search

The puzzles in-game are quite tricky, you need to pick up on visual clues and piece together the identity of the suspects you are chasing. This involves visiting the locations they have visited and in some cases catching up with them. You can end up running into situations that result in your death, which fortunately isn’t too punishing. I’d recommend having a pen and paper to write down any details or clues you find in an area.

The Square

The Square

Some areas of the game lead to short arcade sequences, which usually involve avoiding some kind of hazard whilst trying to reach a particular goal. Sometimes it’s not clear where the goal is or what path you should take. Strangely the default difficulty is set to hard for every arcade sequence, so if you find one hard you should adjust the difficulty in the game menu.

The death screen

The death screen

We originally got Man Hunter back in the early 90′s, the same way we got Kings Quest 4, from one of my brothers friends. Like Kings Quest 4 we were never able to solve the game, and were in fact basically stuck on the first day. This was partly because I was quite young and hadn’t realised where some of the clues were and we didn’t even really know what we were looking for. For my recent play-through I decided to use a guide when I got stuck, which unfortunately became kind of necessary as the clues became more cryptic.

Climbing on the sign

Climbing on the sign

Obviously when we first played it such guides were not available, which would have made some sections quite difficult and solvable mostly by trial and error. I’d suggest you give it a try without a guide at first, but be sure to write down as much detail as you can, and save often! This may require pausing the game in some sequences. Some clues are only on-screen for a short time and can easily be missed.

I found it was quite a compelling game, but also frustrating when faced with some puzzles especially where it wasn’t clear what I should be doing. If you enjoy trying to solve a good mystery you’ll probably like the Man Hunter games.

16
Jun
14

Recursive versus Iterative Algorithm Results Follow-up

A few week ago I did some preliminary investigation into the performance difference between recursive and iterative procedures/algorithms. The problem I chose to solve was path finding in an imperfect maze as there are algorithms which have the same theoretical complexity. I also already had some code lying around for both generating mazes and finding paths. I created iterative and recursive versions of the depth first search algorithm to compare with each other and included breadth first search for comparison to a known “slower” algorithm.

The first results I got were interesting, both the dfs (short for depth first search) algorithms were fairly close in terms of rates until the size of the mazes got larger. The results however were inconsistent because of the small number of mazes used for testing and differences in the behavior of the two dfs algorithms. Clearly I needed to test across a larger set of mazes and fix the behavior difference before I’d get good results. It wasn’t a waste of time as it did illustrate that it is possible for both types of algorithm to out-perform the other given even minor differences in behavior.

So I carefully adjusted the code so that both implementations of the dfs algorithms behaved in the same manner. Again I ran some initial tests and this time the iterative version of dfs out-performed the others in general. Satisfied that the code is behaving correctly I up-scaled the tests to 1000 different mazes across many sizes so I could graph the results.

alg-rate

You can see the rate for all the algorithms drops of very quickly! It is quite difficult to see much detail in this graph so I did some number crunching to determine the average time per search for each algorithm and size of maze.

alg-msec-per-search

This graph makes the difference much more clear. Note the parabola shape, this is because the worst case for all the algorithms is to search the entire maze, which obviously is the square of the X axis in this graph. The interesting part is how they compare with each other. The iterative dfs graph is very shallow compared to the others, it is in fact quite difficult to see much of an increase. It is however increasing in a similar fashion just not anywhere near as dramatic as both recursive dfs and iterative bfs (breadth first search).

So why the huge difference between iterative dfs and the others? The big difference between the two dfs algorithms is the cost of recursion. The extra cost is per square visited in the maze, so a doubling in the processing overhead per square produces a times four increase in the total overhead.

To get a good idea of why the overhead is so comparably large in the recursive case we need to think about how it is implemented at the machine code level. Basically for every square visited in the maze there is a function call to the recursive function and a return at the end. A function call and return involves a number of relatively expensive operations. Firstly information from the calling code needs to be pushed onto the stack (usually important register information), then the processor can “call” the function code which basically pushes a return address onto the stack and jumps to the function code. The first thing the newly called function must do is allocate space on the stack for its local variables, then it can do whatever processing it requires. Once finished the function will place the return value in either the stack or a register, remove local variables from the stack and then return control to the code that called it. This involves restoring the stack to remove the local variable information and then using the return address stored there to return to the calling code. The calling code can then retrieve anything it pushed on the stack before the call and continue operation. Quite the involved process!

Lets contrast that with what an iterative algorithm needs to do differently. Firstly any iterative algorithm needs to set up storage space for the body of the algorithm. In this case a stack (in the data segment or heap) for storing the current search and some variables for tracking the current location. Then the body can begin, usually this will be a loop of some kind, either a for loop or a while loop. These loops involve checking a condition and jumping at either the beginning or end, but are only short-range jumps within the function. The body of the code simply does the search updating the stack as it goes.

So for every square of the maze visited the recursive version has to deal with function call overhead (stack operations and far calls) where the iterative version has to only check a condition and make a short jump. There is more to it with the effects of the L1 and L2 caches, but I’ll leave that out because it’s x86 specific.

So the cost of recursion is high, in this case almost as bad as iterative breadth first search and it doesn’t guarantee the shortest path. Also because of limited program stack space, the recursive function cannot search as large a maze lest there be a stack overflow. So in general I’d recommend people stick with writing iterative code except where the complexity of a recursive function is significantly better. Your code should be faster and put less strain on the limited stack space.




Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm - Vintage & Retro Computing Blog

Random mutterings on retro computing, old technology, some new, plus any other stuff that interests me

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...

Follow

Get every new post delivered to your Inbox.