Archive for April, 2012


Block man for DOS

Block man was written by Soleau software back in 1993 for DOS. The king of the kingdom wants to marry off his daughter but wanted a worthy husband. The king loved to play with blocks as a child so he set a series of challenges using blocks to select the husband. You are the block man, a commoner who desires to marry the princess. You have to get through the levels to the exit using blocks to get there. You can move blocks by picking them up and placing them where you wish. You can climb up one block level at a time, so you can make stairs to reach higher areas or the exit. The game gets quite challenging and be quite difficult. I manage to get to level 8 but could not get any further. The shareware version only has 10 levels, and the registered version has 17. There was a level editor you could get to make your own levels and play levels from friends.

The graphics are in EGA and the sound is from the PC speaker. The graphics are acceptable but outdated for the computers of the time. The controls are good, simple and easy to use. The sound can be a bit annoying but fortunately you can turn it off. There are some small animations (they call them skits) between some levels that can be interesting, but ultimately they are a bit of a waste of time.

The game as a whole is pretty good and challenging, but lacks polished graphics and sound. This isn’t really a big problem as the game play more than makes up for the graphics.


Xmris on NetBSD

I had not heard of Xmris before I installed NetBSD on my sparc. I found the game when looking through package source for games that I could install and test out. It turns out that it will work on pretty much any Unix that has X windows installed. I played it and found that it was very similar to the DOS game Digger , and found upon looking into the manual page that they are actually both a clone of the arcade game called Mr Do! Xmris was written by Nathan Sidwell back in 1992 originally, but updated until 1999 at version 4.05. Luckily for us Nathan seems to have put the code up on sourceforge here for all of us to enjoy. You seem to be able to run it on any Unix system that has X windows installed and was very easy to compile. I ran it on NetBSD on my sparc, and found the performance quite good on old hardware and using X across the network. From what I have seen Xmris is a much more faithful clone/port of the arcade game. From the games man page…

You control a gnome, who can walk around a garden, along paths  already
marked,  or  create  new paths wherever you wish. You also have a ball,
which can be thrown in the direction you’re facing, towards the gnome’s
feet.  Points  are scored for collecting cherries (if you collect eight
cherries without stopping or  pushing  an  apple,  you  get  a  bonus),
killing monsters (by squashing them, or throwing the ball at them), and
collecting the prize left when all the monsters have come out of  their

Much like Digger the level ends when you collect all the cherries or kill all the monsters who do not seem to re-spawn. The game play is slower and a bit less frantic than Digger, and seems to be a bit easier in the early levels. In later levels you get more monsters and the game appears to speed up increasing the challenge significantly. It can be very difficult to get a high score as strategies that help you survive do not help you score points. If you are on a system with many other users on it you will notice that there is a shared high score table that everyone can compete to get to the top of. You also have a separate personal best list, so if you do not make the system wide table you can still see how well you are doing. I quite enjoyed trying to beat my own scores and trying out different strategies to survive longer or get more points.

The graphics in game are quite pleasing but also functional. If you are unfortunate enough to not have a colour X terminal it will also run in monochrome. Playing from a XDMCP session is quite good, and does not seem to over use the network bandwidth or resources on the X server. Unfortunately there is no sound to speak of, but given that most X terminals do not support sound this is not surprising. This game also has some nice features, like customisable controls and a level editor. I found it was a good idea to customise your controls as the default ones did not make much sense to me. The level editor is pretty easy to use and lets you add comments and names to each of your levels. You can play custom levels by using command line options to load them.

In conclusion Xmris is a good arcade action clone, and if you have a linux or unix system I would recommend you give it a try.


Bass Duel for DOS

I recently came across a small collection of games on a vintage PC that I got and found a strange game called bass duel. It was written by Richard Olsen around 1993. I wasn’t quite sure how one could make a computer game out of fishing, but somehow he has managed to do just that. Bass duel is a two player game at heart, each player does things like bait and select the rod that they want to use with either the keyboard or mouse. There is a wide variety of rods, lures and baits that you can use, I wasn’t sure what any of them did so I picked some at random. Once you’re ready you cast your line and hopefully catch a fish. I managed to catch a bunch of fish relatively quickly, but the target is of course to catch the one that is the largest, so I’m guessing that you need to know what you are doing to achieve this.

I don’t know anything about fishing so I can’t tell you how accurate the simulation is, but the excitement level seems to be about the same as real fishing. The graphics are in EGA and seem to be functional, but I found it difficult to work out what the various tiles actually meant as far as game play was concerned. I’m sure that VGA was available at the time but the author wrote the game in turbo pascal 6.0 so may not have had much choice in graphic modes. Sound comes from the PC speaker and just makes the odd bleep to indicate something is afoot, like having caught a fish.

The controls for the game are confusing, I couldn’t even work out how to move my boat anywhere. There is a selection of menus for each player allowing them to select equipment, and enable or disable various bits and pieces. But there was little in the way of help, a tutorial mode would have been a godsend. Some of the controls also seemed a bit weird and like they had no purpose, for instance you can select whether you are wearing your life jacket or not. Does this mean that you can have an accident and capsize your boat and drown? If this is the case, why would you elect to not wear a life jacket? There are options for how you power your boat for movement, but seemingly no way to actually move your boat. I later discovered the controls for moving, and considering I chose mouse control, it was confusing to find the controls on the keyboard.

In conclusion this game is not really for anyone who isn’t into fishing, and even if you are, you’ll find it frustrating. It wouldn’t be so bad if the game had been polished some more, and had a tutorial mode added. Perhaps out there some where is a version 3 that improves upon this one.


OpenGL on Android tips

I’ve been working on an 2d rendering engine for OpenGL on the Android platform using the standard Java API. In my ramblings around the internet there seems to be a misunderstanding about how some portions of the API were intended to be used. In particular the use of vertex, texture and colour arrays and the draw arrays function seems to be commonly misused from what I have read on forum posts around the net. Here I will list a few short tips about making your OpenGL apps on the Android platform run a bit smoother.

The first mistake that seems to happen a lot is the constant creation and destruction of objects in the rendering thread. Android devices and other mobile or embedded systems are very limited in their nature, they do not have much RAM and the processor is not as powerful as your standard PC or mac. Because of this it is important to keep the number of objects pretty constant within your games, otherwise the garbage collector will slow things down constantly recycling objects that you create and destroy on a regular basis.

The second mistake I’ve seen has to do with how the buffers are mis-used. It seems many people are regularly changing the contents of the buffers to move or change the location, size or even rotation on-screen. My mind boggles as to why you would do this over using the standard GL model view matrix operations. It’s my belief that you should create the buffers that hold the actual vertex information once, then in your renderer use glTranslate, glRotate and glScale to achieve any transforms required. The reasons for this are two-fold, firstly if you modify your buffers all the time you will need to modify all the vertices to achieve simple things like translate. Some people have reported that functions on the buffer objects can be slow on some devices, so it is best to use them sparingly. Secondly using the GL functions and matrix operations should be optimised in native code for each device, and so they should be faster. This should also apply to using the OpenGL library on other platforms with Java, mostly because of its interpreted nature. This would be different in some cases if you were writing code for a native language, as I’m told state changes to the GL matrices can be slower than changing the vertices, but this is only true for a small number of vertices where the computation time to change them is trivial.

The final tip I have for you is to make use of multiple threads for your app. You have a very limited amount of processing power so taking advantage of the fact many of the more modern devices are dual core is imperative. The simplest way to do this is to create a separate thread for the main logic of your app, leaving the main rendering thread to perform the main task you want it to, updating the display. Writing multithreaded applications is more complicated in some instances, but java provides some nice mechanisms that you should take advantage of. Declaring objects or just some methods on an object synchronized is a good way to achieve this. Java only allows one thread to execute synchronized methods on objects at a time, but the lock is done at the object level and not the method level. This means you can effectively make an interface object between both threads that is what we call thread safe. This means you are less likely to run into race condition bugs, and hopefully you’ll also avoid deadlock. Please note you should try to keep synchronized methods short to minimise the amount of time another thread is held up. This will help improve the responsiveness of your app. For more information on Java synchronization click here.

I hope this information helps some of you out there trying to build your own apps for Android. Many of these tips are also pretty good advice for building Applications using Java and OpenGL on any platform. If you still run into performance problems you should run a debugging tool called a profiler to find out which code is causing the most slow down. It’s quite important to remember the limited nature of resources on mobile devices, and that disposing of objects can come at quite a price in processing power when the garbage collector kicks in.


Transfering data from old DOS machines

Today we will be talking about how you go about transferring data to and from old DOS machines. I generally use the data transfer initially to back up stuff on my vintage machines, and to install software from my archive to the vintage machine. If you have a vintage machine of any kind, I would strongly recommend you have a backup on a more modern machine. There are many different ways that you may wish to perform the transfer, here are some of my prefered simple ways of transferring data.

Floppy Disks

Yes I know, it seems obvious but with modern machines you may need to go out of your way to install a floppy drive in your system. Many old machines only have a 5.25 inch floppy drive. which could pose a problem for you. Surprisingly most systems even modern ones will support a 5.25 floppy drive if you have the right cables, but if that is not a option you may be able to install a more compatible 3.5 inch floppy drive in your vintage system. The disadvantage of this method is that you cannot move large amounts of data

Serial Cable

Another option you have is to use a serial cable and some special software to do the data transfer. This requires some important things, firstly the hardware to be able to do it. Pretty much all vintage computers have serial ports so they typically aren’t a problem. You also need a serial null modem cable, which is pretty simple if like me you’ve been using these cables for a long time. I’ve had them for the purposes of playing games via serial for quite a while. The last thing that you need is a serial port in you modern machine. This can be difficult as many modern machines do not have any serial ports on board, others require a header connected to the mainboard to access the feature. If you don’t have a port I’d recommend getting a serial card as this is the method most likely to work. You may try a USB adapter first if you like but they are often problematic and don’t work. Now for the software you can use a variety of programs, but I’d recommend you get a copy of laplink 3 for DOS. It works quite well and seems to be robust. You will need to set up dosbox on your modern machine if you are running a newer OS. Be sure to set up the link from a virtual dosbox serial port to the real serial port. You can of course also use other software such as terminal software that uses the zmodem protocol.  If the old machine has windows 3.x on it, you can use the terminal program in it in conjunction with the terminal program in your modern windows. The advantages of serial are obvious, you can transfer alot of data instead of just a few megabytes. The down side is usually the speed. It’s faster than floppies if you account for the time swapping and managing the copy, but it’s still pretty slow. You can speed things up by compressing what you want to send using pkzip or lha, but this does take time to create and extract, which can be significant on old systems. Parallel ports are pretty much the same deal as serial except they require a different set of cables and software, but generally have the same good and bad points with a higher speed. This is my prefered way of transferring data.

Via Hard Disk

This is probably the hardest way of moving data, but by far the fastest once it is working. The main problems with hard disks are the in ability of modern machine to read many old drives and vice versa. You really need to do your homework before connecting an old drive into a new machine or a newer hard disk into an old machine. ATA (also known as IDE) adapters used different standards over time and many of them are incompatible. I remember at one point frying a newer hard disk trying to connect to a older computer because of the differing signalling voltages between the two eras of hard disk. I think the best way is to find a adapter or card that will fit either the modern machine or vintage one, it must be known to work with the particular hard disk you have. SCSI cards and hard disks are a good option as the drives are fast, and you’ll find plenty of adapters to suit modern and vintage machines. To minimise the risk to you modern machine you may try to use a USB to IDE adapter, but may find it doesn’t work depending on the age of the vintage hardware. I don’t like to use this method as it puts hardware at risk of damage, and vintage components are hard to come by. Also I don’t like messing to much with my working vintage systems configuration. The only reason I’d do this is if the drive is already failing and I needed the data back fast. You can use tools like ddrescue on linux to make a image of a hard disk containing as much data as is recoverable and retreive your data from there.


The last method you can use is networking. A network is a good option if you use your vintage machine on a regular basis and need to transfer data regularly. There is alot you need to do but it is usually fairly simple as long as you can get the appropriate equipment. You’ll need a preferably ne2000 compatible card for your vintage machine that has dos support, and the microsoft networking software (often comes with windows for workgroups). Once you set up the network share, you simple just need to be connected to your network and you can either map a network drive or use windows explorer to do what you need to be done. This is  a good solution in that it is typically faster than serial, less likely to damage hardware than directly connecting devices, and cane be set up as a permanent solution. The down side is that the set up itself can be difficult if you are not familiar with networking.


I prefer using the serial cable method myself as it is one of the simplest and quickest to set up. You’ll also find it’s the most compatible across the most vintage machines. Incidently it’s also the one requiring the least hardware and software knowledge, so it’s also what I’d recommend inexperienced people try, unless they only need to transfer a small amount in which case a floppy is a good choice. The other methods require you to be able to install specialised hardware and/or software. Connection of hard drives in particular is the most perilous for the inexperienced, as destruction of hardware is a very real possibility. Network connectivity is usually overkill for me as I don’t set up any of my vintage machines in a permanent place, and I generally don’t have to worry to much about how long the transfer will take so serial is fine. If you happen to have a parallel cable you can get some better speed than serial with much of the same convenience, but many old parallel ports are not bi-directional so you will need a backup in case it fails.

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

Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.


retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way