Revolution Destroyed?

Have I ensured that a world socialist revolution will never happen?

A book by Steve Wallis (www.socialiststeve.me.uk)

Chapter 6

Learning a trade

My parents bought a computer fairly soon after I started my computer studies O-level course, in the autumn of 1980 (when I was aged 14). They involved the whole family in the decision of which computer to buy.

The serious choice was between a Commodore Pet and a Sharp MZ-80K, which were roughly the same price (of the order of £500). Apple had brought out a far more expensive personal computer, which had colours and a pixel-based display, but that cost much more than my parents were willing to spend. At about the same time, Sinclair brought out its very cheap computers (the ZX-80 and ZX-81 which cost about £100) that had very little RAM (random access memory, that can be altered, unlike ROM which stands for read only memory) – 1K. [1K (one kilobyte) is 1024 bytes, where each byte consists of 8 bits (binary digits which are either 0 or 1) and can represent an integer (whole number) between 0 and 255.]

The Sharp MZ-80K had two big advantages over the Commodore Pet – it had sound and some good graphics characters. I played some games that had been written for the Pet at Cardiff University, while we were considering what computer to buy, and they had very bad graphics, including letter As moving around the screen! We therefore chose the MZ-80K.

Nowadays, I would take into account the fact that Sharp is a Japanese company whereas Commodore is an American one. I tend to avoid products (particularly electronic ones) made by US firms since that country is the main bastion of capitalism in the world. Also, Japanese workers are generally treated better than those in other countries. The motivation of most Japanese bosses may be to buy off the trade unions, but some of them are on the side of the working class in the big conspiracies in society, deliberately providing good quality products that working class people can use perhaps even to undermine their class (big business). Whatever the reason, their workers are generally more motivated to do a good job so their products are more reliable. The MZ-80K may have been manufactured in Japan itself, but most electronic products are now made in less developed countries, particularly China, due to the much cheaper labour costs (i.e. much greater exploitation of workers) in those countries. This obviously limits the advantage of buying from Japanese firms. I now tend to find products made in Taiwan to be more reliable than those made in China.

My parents economised at first by buying the minimum amount of RAM (20K), which only left 6K when the language BASIC was loaded, but they soon upgraded to the maximum (48K) when that proved insufficient.

The MZ-80K was a good computer to learn to program on. I largely taught myself BASIC at home, with the aid of the manual and computing magazines, but I also learnt it in the computer studies O-level course I was taking at school. Its character-mapped screen made it possible to write reasonably fast games entirely in BASIC, despite the fact that the language was interpreted (BASIC commands were processed on-the-fly rather than compiled into the machine code that the computer understood).

As well as BASIC, we were taught a very simple language called CESIL at school. This was a simplified assembly language (in which every command could be translated into a single machine code instruction) specially designed for teaching programming in schools. Learning CESIL helped me get reasonably good at the Z-80 assembly language used on Sharp machines. I never got good enough at the assembly language to write an entire game in it, however. Fortunately, we eventually discovered a BASIC compiler we could buy, which translated that language into machine code. I used Z-80 assembly language for simple routines that were used a lot and had to be fast, particularly graphics operations. I also used it for sound, since it was necessary to repeatedly interrupt what the processor was doing to access the sound chip, in order to avoid games pausing while sound effects were being produced.

Sean wrote computer games as well as me, learning at home at the same time, but he could only program in BASIC so I had to supply the assembly language routines he needed.

We made an early attempt at selling games by placing an advert in a computing magazine asking people to send a stamped addressed envelope for a list of the games and their prices with a short description of each, calling ourselves “Wallis Software”. I think this was before we got the compiler, so these games used the BASIC interpreter supplied with the computer (with some perhaps also having the odd machine code routine). We only sold a few copies in total, apart from someone who ordered a lot of games and twice sent us back the cassette tape with them on saying that her computer wouldn’t load them. Our more recent games were quite good but we had included some very old simple games on the list, some of which she had ordered, and we suspected that the real reason she was sending them back was disappointment at their quality. However, we finally returned the money she had paid with an apology.

Later on, after we had written some good games using the BASIC compiler, we got a company called Kuma Computers to sell them. They paid us royalties of 30% per copy, which was much higher than most other companies paid. This was a time when most games that were sold commercially were written by individual young people (usually boys who were still at school) on computers at home, rather than being developed by teams of programmers (and people with other expertise such as in graphics) working directly for the software companies and being paid a salary. They sold (at least some of) our games overseas as well as in the UK, but we insisted that they were not sold in South Africa since we didn’t want to break the Anti-Apartheid Movement’s boycott of that country.

I got interested in other programming languages, including Forth in which commands operate on a stack. For example, the addition command takes two numbers off the stack, adds them together, and puts the result back on the stack. I got hold of a version of Forth for one of our computers (I forget which) and later did my own implementation of the language for Sharp machines. I think that it was the first compiler I ever wrote, but that it converted Forth routines into an intermediate binary form that was then interpreted instead of generating machine code (being easier to write and more economical as far as memory is concerned, with the language still running reasonably fast). I wrote one game using my Forth compiler, called Chessman, which was also sold. [It was not a chess-playing program, as the name might suggest, but it used graphics characters that when used together looked like chess pieces.]

Kuma lent us other Sharp machines – the very similar MZ-80A and the colour MZ-700 – for us to convert the games to run on them. This was a straightforward task and resulted in significantly higher sales.

However, at one point we got disillusioned with Kuma because they didn’t seem to be marketing our games very well, and noting that we hadn’t given exclusive rights to them, we set up our own company to sell the MZ-700 versions of the games ourselves. We initially thought of calling it “Rainbow Software” but found that the name had already been used so we used the name “Lightning Software” instead (appropriate because the games were fast). We only found out later that a software distribution company called Lightning Software Distributors already existed!

We put quite a lot of effort into this company, with Sean (being good at art) producing the pictures to go on the inlay cards, us all setting computers going to make copies of the games one-by-one, and Max going round shops trying to get them to sell them. He even got Harrods to agree to take them (although I’m not sure whether they actually sold them in the end). We got registered for VAT (a tax on sales) in the expectation that we would sell big quantities. [Companies with low turnover were exempt unless they claimed that they would probably achieve a high turnover the following year, but profits were higher by registering because we had to pay VAT for the tapes and inlay cards, which we could claim back when registered, and shops had to charge customers VAT.] However, MZ-700 machines weren’t popular enough for us to sell many tapes so we probably lost money overall, but we did manage to reuse some of the tapes and backs of inlay cards for music!

That venture was useful however, because Kuma found out about it (thinking at first that Lightning Software Distributors were selling them) and their boss Tim Moore came to visit us at our house in Penarth. As a result of the meeting, Kuma started supplying us with better and more popular machines – an Amstrad CPC464 and a machine that used the MSX platform (the first attempt by different companies to construct compatible computers before the era of the IBM PC compatibles now known merely as “PCs”). Amstrad is a British company (whose boss is Alan Sugar of The Apprentice fame) whereas the MSX platform was initially a Japanese initiative but later involved countries from elsewhere in the world.

Kuma lent us an Amstrad computer before they were on sale on the UK, with a slightly different look-and-feel from those that were sold here. Because it was so new and (as with other personal computers at the time) only came with a BASIC interpreter, I needed to write a compiler myself. I wrote one for a subset of BASIC, which excluded operations on strings (sequences of characters) and floating point numbers (necessary for large numbers or ones with digits after a decimal point), written in that subset. Hence, I could use the BASIC interpreter at first to run the compiler but later run the compiler on itself, so that the resulting machine code could compile other programs (and later versions of the compiler itself) quickly.

The Amstrad and MSX platforms both had processors running the same machine code, Z-80, as the Sharp machines. The Z-80 processor had one major competitor at the time – 6502. Although both were called “8-bit” processors, the Z-80 allowed three pairs of two 8-bit registers (items of memory within the processors) to be used together to represent 16-bit numbers. In contrast, the 6502 had very few registers and complex operations (in which half the address was stored in RAM) were necessary to handle 16-bit addresses. The 6502 was built for speed and computers with that processor were generally faster (when running programs directly written in its assembly language) and more popular than those using the Z-80. However, the Z-80 machine code was much more suitable for compiling into – we bought a BBC Micro that had a 6502 processor and I wrote a BASIC compiler for it which was only a few times faster than the built-in interpreter (which was actually relatively fast for BASIC interpreters) and generated longer pieces of machine code than the Z-80. As a result, we concentrated on the Z-80 platforms for writing games. I did write one game for the BBC Micro that was reasonably good, and tried at a computer show to get a different company to sell it (since Kuma didn’t sell games for the BBC) without success.

Amstrad CPC-464 and MSX emulators have now been written for modern platforms, including PCs and Macs, and I found our games for these machines (as sold by Kuma) on internet archives. Emulators and games can be downloaded free of charge; I have put details and advice for using two of the emulators on the Computer Games page of my socialist website (www.socialiststeve.me.uk).

The best selling of our games was the first I wrote on the Amstrad – Fruity Frank. As with many of our other games, I based it on one I’d already seen on a different machine, making improvements to the idea. In this case, I based it on one running on arcade machines called Dig Doug; there is also a similar game for the BBC Micro called Mr Do but I think that was written after Fruity Frank. In my game, you can push apples onto monsters or move under apples to let them drop onto the monsters. There is also a ball that you can throw at monsters, but it takes a while to come back preventing you from using it all the time. To get big scores, you need to kill the bonus monsters or push an apple onto a few different monsters on top of each other. There are other fruit (mainly cherries) that you can eat in order to progress to the next level. Beware of the vicious strawberry monster, which appears if you take too long to finish a level!

I originally intended to call that game Fruity Franco, but Max fortunately told me about the Spanish fascist dictator with that name!

The Amstrad screen was, like modern computers, based on pixels (little dots of colour), rather than characters like the Sharp machines. Therefore many more operations were required to display graphics on the screen, which slowed Fruity Frank down on high levels due to the large number of monsters moving about, despite the fact that I had written the graphics-drawing routines in Z-80 assembly language rather than BASIC. One visitor to our house utilised this flaw to get very high scores simply by eating the fruit on each level, ignoring the monsters. Modern machines are much faster, so the game shouldn’t have this flaw when emulated.

The MSX screen was a cross between a pixel-mapped and character-mapped display. It was possible to define (possibly multicoloured) characters and move them around the screen, or adjust the pixels on the screen by modifying some of the characters. I wrote some graphics tools, which we used to design the characters and build larger objects out of those characters; these objects could then be displayed very quickly using assembly language routines. The version of the MSX platform we wrote for had a big limitation – in any row of eight pixels, there could only be two different colours (apart from a small number of additional “sprites” being able to be on the screen at once). This meant that the characters in most MSX games were only one colour. Indeed, the first game I wrote on that platform, Hyperviper, in which you go round a scrolling maze eating snakes (perhaps dividing them in two), had mainly monochrome characters.

Sean was very good at art and he used this skill to define the graphics for many of our computer games, including Fruity Frank. The monsters and fruit in that game were less colourful and realistic in the MSX version of the game than on the Amstrad due to the limitation mentioned above, but he was nevertheless skilful enough to make it look very good on that platform.

There was a further feature of Fruity Frank that contributed to its addictiveness – the background music, which changed from level to level. I chose seven catchy folk tunes for that game. Folk was the genre of music that I was most into at the time, not being particularly interested in pop music until I went to university. By using tunes of traditional folk songs in our games, we avoided the potential copyright problems of more modern music.

Many years later, I got an email from somebody paying me a huge complement by saying that Fruity Frank was the best game ever written. He wanted me to send him the game’s code so that he could write a version in the language Java, but I didn’t have the code any more and, as far as I know, he didn’t get round to writing a version of the game. Fruity Frank was not even my best game; Buster Block is far better in my opinion. In terms of sheer complexity or graphics quality, modern video games are far more impressive than the games I wrote. It was just about possible to do fast 3D graphics at the time, such as in car-racing games and the excellent space adventure Elite which I often played on the BBC, but I didn’t know the techniques that were used. However, as far as playability is concerned, modern games tend to be inferior to those written in those days.

Early computer games tended to be played on keyboards. Those keyboards usually didn’t have cursor keys, so games programmers chose keys that made the games easiest to play instead of that obvious solution. I tended to find it easiest to use my left hand, and hence keys on the left-hand side of the keyboard (typically Z and X), to move a character left or right, and my right hand to move up or down. The main exception to this general rule is for space games in which the background (often including a planet’s surface) is being scrolled leftwards across the screen, such as Sean’s games Star Avenger and Galaxia, in which it is easier to use the hands the other way round. Not only were games harder to control using the joysticks available at the time, but modern game controllers (such as one I’ve connected to my laptop to use with the Amstrad and MSX emulators) are massively inferior to keyboards! Games consoles such as PlayStations and X-Boxes, on which most modern games are played nowadays, rely entirely on such controllers and I don’t think anybody’s fingers can manipulate them as quickly as is possible on keyboards! The new controllers for the Wii look interesting and possibly make controlling same games easier and more fun, but they are probably only suitable for certain kinds of games.

In Buster Block, you try to push blocks onto monsters before they come and get you or even push blocks at you. Your energy decreases when you collide with a monster or moving block, and gradually all the time so you have to be quick. I based Buster Block on two games for the BBC Micro, Pingu and Rubble Trouble. In those games, all blocks and monsters looked and behave the same and were arranged randomly, whereas I provided 16 different kinds of block (including both kinds from those two games plus others which go round corners) and six kinds of monster, and designed a maze of 400 rooms.

I arranged those rooms in 25 different levels, plus a starting level without any blocks or monsters merely used to select one of eight doorways to a new level, for four different routes through the levels each of which can be traversed in either direction.

I implemented Buster Block on the MSX platform first. That platform’s limited graphics were less of a problem with this game since blocks are easier to make multi-coloured than other objects. I did virtually the entire graphics for it, unlike with our other games; accommodating to the limitations of MSX graphics required a different kind of skill to simply being very good at art.

I was quite surprised that I managed to implement Buster Block on the Amstrad at all, due to its smaller memory capacity. To do so, I had to shrink the screen size and use some of the memory that should have been used for it to store data.

The Amstrad version of Buster Block in particular suffered from slow-downs when there were a large number of monsters and blocks moving around (since it did not have a character-mapped screen like with the MSX). As with Fruity Frank, this is not such a problem when emulating the game on a modern PC. This makes the game harder to play and I haven’t been able to do as well when playing the game on a PC as on the Amstrad, but I have completed all the routes through the maze.

Buster Block did have a serious flaw in that some blocks were not pushable or destructible, making it possible for them to block the way to an exit. Sometimes there is another way to complete the level, but at other times this is impossible. I therefore provided a teleportation device in one room of every level, which you can use to return to the start level, and made you appear in this room whenever you lost a life (unless you’ve run out of lives of course). I made kicking a wall expensive in terms of energy, so that you don’t have to wait ages for the energy to run out if you get stuck. In practice, this problem does not occur very often, and even if it does, reappearing in the teleportation room after losing a life often allows you to progress.

I tended to prefer less violent games, and squashing monsters with blocks or apples, or eating snakes, were arguably more ethical than those where you shoot at alien spaceships, like many of Sean’s games including Star Avenger and Galaxia. However, I undermined this argument slightly by making one of the “monsters” in Buster Block look like a mini-spaceship (perhaps Sean’s idea), and by writing (and putting my name on) the MSX version of Galaxia.

I will talk about the left-wing meaning of the name “Galaxia” in Isaac Asimov’s Foundation series, which I reused for my socialist band, in chapter YYY. I strongly suspect that Sean used this name to undermine that left-wing meaning, because he was (and still is) partly an agent of big business.

I carried on writing computer games for about two more years after starting at the University of Manchester, but mainly when back in Penarth during university holidays (despite buying an Amstrad computer in Manchester).

Sean and I divided the royalties from all our games equally, irrespective of who did the most work in any particular game – this socialist approach was more beneficial for Sean since Fruity Frank and Buster Block were our best-selling computer games. For a short period of time we were getting royalties of thousands of pounds a month. These royalties helped support our parents when they had financial difficulties and helped finance me through my time at university – despite the fact that student fees had not yet been introduced, the full grant I received as an undergraduate due to my parents’ low income was not sufficient during the holidays. By the time I bought a house in Moss Side in 1988, four years after starting university, I just about had enough money for a £10,000 deposit on that house.

Towards the end of our time with Kuma, they were concentrating on business and educational software and therefore did not market our games particularly well. I found out recently, when investigating emulators for the Amstrad CPC-464 and MSX platforms, that new improved computers that were compatible or very similar to these platforms were being produced by many different companies. In newer MSX machines, the restriction on two colours per row of eight pixels was removed, so later MSX games were more colourful. If we had known this at the time, we could have made much larger amounts of money by adapting the games for these machines and finding a different software company to sell them. However, being rich would have undermined my later political activities!

They stopped selling them altogether at about the time that new computers, compatible with the I started writing a game called Bubble Trouble, which involved a scrolling alien landscape with bubbles of varying sizes above it. However, I lost interest in writing computer games before finishing it – I felt that Buster Block was so good that any later game would be an anti-climax, and I became more interested in serious computer programs, particularly those involving artificial intelligence (AI). In the next chapter, I will write about my continued learning of computer programming at university.

Click here to read the next chapter of the book

Click here to return to the Revolution Destroyed? contents page