More Adventures in hardware land

Last weekend I got into working on some of my collection of hardware. I modified my spectrum but also did a few other things you may find of interest.

Gravis Gamepad

Gravis Gamepad

I recently had gotten myself an old school gravis gamepad that was around in the 90’s. So in order to test it I had to dust off an old PC hook it up and try it out with a few games. I didn’t have one of these gamepads on any of our old computers so it was interesting to see how games worked with it. It is also interesting as it allows you to turn the gamepad upside down in case you happen to be left handed. Because of its shape it feels comfortable in either orientation. I found that the buttons were quite good, but the dpad wasn’t quite as good as it felt a bit mushy. I couldn’t tell sometimes when I was going diagonally or just left and right. The one I have may need a clean as well because it didn’t always respond as well as I would have liked it to.

Floppy disk backup

QuickBASIC Manual and disks

I have numerous bits of software on floppy disks of all different sorts, and I had decided it was time to finally backup some of them up. I have an old 5.25″ floppy disk drive in one of my old PCs that I normally use for tasks like this and I made a copy of some software I have. I hadn’t previously created disk images for them before and I wanted to do it now. The only trouble is rawwritewin (a program for imaging floppies) didn’t seem to work for disks other than the standard 3.5″ 1.44Mb disks. After much internet searching I found a program called ImageDisk that was created by Dave Dunfield, I haven’t tried it yet, but it comes highly recommended on many retro hardware forums and is free for personal use. I also noted it supports reading and writing disk formats for many machines other than just PC floppies.  Have a look on his personal site at http://classiccmp.org/dunfield/. I found the transfer utilities on a page he has with archives of old disks from ancient systems like the kaypro. You have to use it under DOS and with a compatible floppy disk controller (no usb floppies) so it is best to use it on an old machine.

Practising de-soldering

A practise board

After my work on the spectrum I realised I needed to practise de-soldering components – alot! Quite some time ago I got some boards out of some old printers exactly for that purpose and I started practising on it just this weekend. I’m hoping that by learning this I will be able to salvage old components from boards that no longer work, and be able to repair old parts that can no longer be replaced. I recently learned how to test a transistor from some kind people on youtube which will definitely help as well.

Hardware Weekend – Modding a Spectrum

This weekend rather than fiddling around with software of some sort I decided to get the old soldering iron out and have a go at a job I’ve been meaning to do for ages. I have a sinclair ZX Spectrum which of course under normal circumstances uses a RF signal with my TV. This works ok, but is often fuzzy and has interference. So I decided to perform a simple mod in order to bypass the RF modulator on board. I had previously replaced the keyboard membrane because the old one had failed.

ZX Spectrum mainboard

Fortunately there are many websites around the web that tell you exactly how to do this. So after dismantling my speccy, and reading up about what to do I began by desoldering the wires of the RF modulator. These seemed to be harder to get out than I had anticipated partly because they seemed to be soldered in from both sides of the board and my solder sucker didn’t seem to be very effective.

RF Modulator

I did however eventually get the wires disconnected and the board ready. I soldered in the new wire and prepared to test it out. The TV display was wonderful and clear, but unfortunately it seems my poor speccy has acquired a new problem since I last used it.

Mod Complete!

The display appears to be corrupted and I believe the CPU is hanging, after a bit of cleaning of the socketed chips I think I’ve narrowed down the problem to the display ram chips that are socketed. The ULA and other parts of the board all appear to work fine within the limitations of what I can test, and swaping the socketed ram chips seems to merely change where the corruption is on screen.

Image clearer – but corrupted

The main problem is sourcing the replacement chips! Video memory on the speccy is in the form of some 4116-n2 chips that are notorious for failure. Looking around online in Australia has turned up no obvious source of getting new chips. I may have to find a similar chip (say a 4164 or something similar) to replace it, but that also will be a difficult task of comparing data sheets. My best hope at the moment is to find another speccy for parts (or working) in order to repair this one.

Code Optimisation

Recently I started reading a book about code optimisation that focuses on the x86 architecture and assembly language. The book is called Graphics Programming Black book and is written by Michael Abrash who is well known for his work writing technical articles and coding on games such as Doom and Quake. Whilst the book has a graphics focus, the skills you can learn from the book can be applied to any high level language or assembly language you may happen to be using. I’ve dabbled with assembly code in the past and have found some parts of the book quite interesting. You can find the book on-line to read via html or PDF download. You can find it pretty easily if you just google Michael Abrash and the name of the book.

After my recent testing of data structure performance and beginning to read this book, I decided that I should look over all the Java code I had in order to try and optimise it. I have been for some time working on writing some android games, and in the process have built for myself a nice graphics library and the basics of some games. In testing and tuning my code I’ve found some good rules of thumb for making fast code in Java not just for the android platform but in general.

The first thing I’d recommend you do is to not use Iterator classes anywhere in your code, but use for loops instead. Iterators are objects and add overhead to your applications in multiple ways. Firstly the occupy heap space and need to be garbage collected when finished with. Now this may not seem all that bad, but if you have several nested loops, this could mean thousands of Iterator objects being created and destroyed on a regular basis in your code. Secondly it adds extra method call overhead every time you call hasNext() or next(), slowing down your loops. Again for small numbers of loops it seems insignificant, but when added up over a large number of loops the time taken to make the calls can become quite significant. For these reasons, even when using the API data structures such as ArrayList, I would avoid using Iterators.

In very time critical code, it is best to build your own data structures out of primitive arrays rather than to rely on the API code. The JIT compiler seems quite adept and optimising simple array based code to run a lot faster than pretty much any API or object based solution. It’s also best to try and minimise the number of method calls in your important loops to keep overhead down.

An interesting problem I recently had was to do with path finding within a maze in one of the games I am writing. Obviously I had a randomly generated maze that whilst being perfect to start with, has cycles (or loops) introduced to it to make the game more playable. When I first wrote the path finder I used a depth first approach that works quite well on perfect mazes as there is only one path from each point to each other point. The problem I had with it was two fold, the algorithm was slow in the larger mazes and with cycles being introduced it often chose longer paths than it had to. This perplexed me no end, so I went in search of what the problem might be, optimising some of the code to get better speed, and writing some extra code to try and get a better path. After having tried without any luck I decided to try using the breadth first search algorithm implemented iteratively. It turned out to be a whole bunch faster! I investigated into why this might happen given that depth first search should be faster to find a path (even if it’s not optimal). Upon comparing the code of the two algorithms I came to a simple conclusion. The depth first search code took a lot longer to execute a single iteration because it had many more method calls and comparisons than the simple breadth first search does. So whilst on paper the depth first search looked good, its performance is poor in comparison, because the simpler breadth first search could get through more iterations in the same amount of time. The breadth first search is so much better I was able to generate larger mazes and still find paths within a reasonable response time, even with worst case paths that searched most of the maze!

It’s interesting how sometimes the unexpected solution turns out to be the best. It shows you should always test your code, and spend a bit of time optimising your critical code. It will in the end make the experience of the end user all that much better, and enable you to do more with less.

Vette! for DOS

Title Screen

Vette! is an open world racing game released by Spectrum Holobyte back in 1989. It was one of 4 games we got in a simulation pack that included Silent Service II and F117a. Vette! was the first Racing game we had ever played, and would be the only one for quite some time. It was ahead of its time in many ways being one of the first to be open world, have multi-player support via serial or modem, and had some of the earlier successful 3d graphics. The city of San Francisco was used as the basis for the game world.

Choosing a Car

You are of course driving one of 4 different corvettes and have to race against one of 4 different opponent cars that were competitors to the corvette at the time. There are 4 different courses you can race, the 4th one being a combination of the first three into one long course. You have to navigate around the city to find the shortest route, races are simply from one point to another, fortunately there is a map in one of the many views to assist you. There are some free way segments you can use, they start at on ramps located around the city and play more like games such as outrun. The main ones link to and from the two major bridges in the city, the golden gate and the bay bridge. You can also use open spaces with out roads as short cuts, driving through the middle of a park.

Map and helicopter view

There is a realistic damage model on the harder difficulty modes which makes things more interesting. You can damage all the major parts of your car. If you damage your engine or transmission obviously you aren’t going to be going anywhere fast. Damaging your wheels or steering can make your car pull to the left or right and basically make your car uncontrollable. If you get damaged but can still drive you can get repaired at gas stations located around the map.

Passing a Bus

There are police in game which will chase you if they think you’re doing something wrong. They are more alert based on the difficulty level you select. You can get pulled over for any number of offences. Once caught you have the option of giving the officer an excuse, and sometimes they will let you off without a ticket. If you’ve done something really bad like run someone over or just gotten way to many offences you will be hauled off to jail and won’t get to complete the race. On the lowest difficulty setting the police hardly bother you at all.

Begining to cross the Golden Gate Bridge

Whilst the game is centred around racing there isn’t any reason you have to. You can drive anywhere around the city and basically go on a tour if you like. There isn’t a whole lot to do however apart from just going to see the various landmarks in the city.

The graphics were in EGA and were drawn using flat shaded polygons. EGA cards were slower than VGA ones in addition to being harder to program. So it’s quite impressive they managed to make such a large and detailed world! It is also one of the few games to take advantage of the higher resolution EGA modes (640×200).

At a Landmark

There is a surprising amount of detail in the world around you, traffic and pedestrians roam the city as obstacles. Many of the cities landmarks are in game and look quite reasonable given the capabilities of machines at the time. The game doesn’t look as nice on a LCD today as it does on an old school CRT so if you have an old machine with a CRT that will give you the best experience.

Sound is unfortunately only on PC speaker, and the engine sounds are quite annoying. Fortunately you can turn them off. Considering that by 1989 the Adlib sound card was quite common I hoped that there would be some support for it.

Losing to the Porsche

Me and my brothers had tons of fun with Vette! on our old 386. We often drove around the city as well as doing the races. Playing it recently I still had a lot of fun doing the same things, but it’s not a game I play on a regular basis as it can be repetitive. The graphics are a bit dated now, even though they are impressive for EGA, so this isn’t going to be a game for everyone.

This slideshow requires JavaScript.

Blots for DOS

The Title screen

Blots is a simple puzzle game written by David Bright released for PC in 1992. He originally developed the game for the Acorn Archimedes machines which are the ancestors of the now common ARM processors. Blots has some similarities to popular games from early 8 bit machine such as Boulder Dash. I have the shareware version we got of a magazine cover disc. The game is meant to be played by two people sharing a keyboard.

Intermission screen

It uses VGA graphics and PC speaker both of which are pretty good although the gradients on the title screen and intermission screen can make some text harder to read than it really should be. The only help and instructions you will get is some scrolling text at the bottom of the title screen. This was fairly common for small games such as this.

Simple Starter

The goal of the game is to get both players (called blots) out of the level. Each level consists of a number of brick walls that can be destroyed with bombs, concrete walls that can’t be destroyed, boulders, and areas of dirt that will block the movement of objects. Boulders and bombs will fall if un-impeded, and bombs will explode when either something lands on them or they fall on something else. You have to be careful as exploding bombs can kill either player. In this way it’s kinda similar to Boulder Dash with out the larger levels and diamond collecting.

Cascades

The puzzles are designed with two players in mind and some can’t be solved by one person alone. Depending on the situation you may need precise timing or need both blots moving towards a goal at the same time. A time limit prevents you from spending too much time, and in one level I played it was the main obstacle to completing it. Because of the two player requirement I found it a bit frustrating when I found a level I couldn’t complete alone. It would have been a lot more fun for me if there was a single player mode.

Run Forest Run!

Aside from requiring a second player on occasion, Blots is a decent puzzle game. The full game had lots more levels designed by many people. Perhaps there was a level editor was available in the full version. I wasn’t able to find out much more information about either the DOS or Archimedes versions unfortunately. This surprises me a little bit as it seems from the long list of level contributors that it was quite popular on the Acorn machine.

 

Spectre for DOS

First Level

Spectre was released by Velocity inc. in 1992. It is a 3d tank battle game very much like battle zone and its descendants. It had numerous ports for systems such as the Macintosh and even a console version that was on the super Nintendo. I have only ever played the shareware version as I have never found a commercial copy of the game.

I played it originally on our old 20Mhz 386 when I was a kid, and the performance was actually pretty good considering the capabilities of the machine. Under dosbox I’ve found it works well if you have the cycles set high enough, but you can experience slow-down when you are close to some of the texture mapped objects if you haven’t set it high enough.

Flags

The game supports VGA, and has some simple 3d texture mapped graphics. If your machine doesn’t work very well you can turn off texture mapping to gain a little extra performance. The landscape is however very sparse and dark. There are a number of objects strewn around each landscape most of them geometric shapes such as cubes, pyramids and some flat surfaces in the form of billboards. The object that is the most complicated and animated are the windmills that you find in the levels. Strangely all the objects that are textured use the one texture, which changes each level.

Sound comes in the form of either PC speaker, Adlib or Sound Blaster, but oddly in the demo version of the game I could only ever get the PC speaker to work, which is reasonable, but nothing spectacular.

Level 3

Game play is relatively simple and very much like battle zone. You’re in an arena like space with obstacles, enemies, and some flags. To complete a level you have to collect all the flags and preferably kill as many of the enemies as you can. In the demo you only get the first three levels which are frankly a bit boring. The enemies aren’t all that clever and pretty much just come straight at you. From what I’ve read online there are many more levels that are much more difficult and have more interesting enemies.

Windmill in level 3

As a kid the demo was pretty impressive, but I had played games that had 3d graphics and better gameplay. I found the demo was a nice demonstration of the technology, but didn’t really have a lot of good game play in it. The technology in the game itself was kinda impressive, but was over shadowed very quickly by games that came out even that year, such as Wolfenstein 3d. Perhaps the commercial version is a bit more fun and interesting, but that unfortunately seems to be difficult to find.

Memory Allocation – Heap and Stack

A question I recently saw online was about how memory is allocated and used within the Java programming language. There was a little confusion about what the heap and stack are. Both the stack and heap are common to many languages such as pascal, C, and many more.

Stack space is a special construct in hardware used for storing temporary variables, return values and return addresses for functions. Most languages use the stack to store any local variables that will fall out of scope when a procedure (or method in OO language) finishes or returns. Java has the same style of stack construct for the virtual machine used for the same purpose. The Java language will however only store primitives (char, int, byte etc) and references to objects on the stack.

Heap space is a software construct and will be different depending on the language. It’s used for dynamically allocating memory usually for longer term storage of larger chunks of data. In languages like pascal and C, data on the heap is usually handled and referred to by a primitive called pointers. A pointer basically holds the memory location of whatever it is pointing to, they can be difficult to program.

Java doesn’t have a pointer primitive so it uses a different mechanism. Instead of having pointers, Java has references which are subtly different. A reference is different in that the memory location information is not available to the programmer where as it is with a pointer. This means you can’t do pointer arithmetic or try to access memory directly. The intent of this is to protect programmers from themselves and to make Java more secure. Java references are used for storing objects and arrays on the heap. The garbage collector keeps track of how many references are pointing to each item in the heap, and disposes of items that are no longer in use.

Older languages that target DOS and the older systems will allocate global variables to what is called the data segment. DOS and earlier processors used segmented memory addressing and in part comes from the 8086 machines assembly language. There are three types of segment, code, stack, and data. Code segments are for storing the machine code for the program and are pretty straight forward, there can be many of them but on DOS and 8086 machines the maximum size of each is 64Kb. The stack segment is singular and unique and is for the processor stack, there can be only one again with a maximum size of 64Kb. The data segment is as I said for statically defined data, and each segment is 64K in size. Borland Turbo Pascal only allowed one data segment and I suspect most other languages did the same. The heap would be outside the segments and would use the remaining memory, it was typically managed by a system library that was a part of the language used.

Java is fairly similar to native languages but does not use a segmented model, as many modern languages don’t. This is partly because hardware and software has changed in such a way as they are no longer needed.