I spent several years in the 1980s programming games.

I have a memory of 26 year old me sat hunched over a computer late at night back in 1985. I was working a 60-70 hour week as a partner in a games company. My current game was an American Civil War tactical wargame called Johnny Reb II. I was struggling with some ‘artificial intelligence’ code for the attackers (Confederate troops) to cross a bridge over a river. On the other side the defenders (Union) were trying to defend the bridge.

Artificial Intelligence in games is a completely different thing from ML and Data Science nowadays. Back then it was just a control algorithm for troops reacting to the presence of enemy troops and working out the best routes, targets to attack, whether to retreat and so on.

What made it worse was that the whole thing was written in 6502 assembly language (and later converted to Z80). Back then you had two choices: Basic which was to be honest slow and clunky for writing games or assembly language. If I was doing it now, without a moments hesitation I’d program it in C. But C compilers for 6502 didn’t exist back then.

The Problem with assembly language

The problem with assembly language is (a) it’s slow to write. You can write 10 lines of C in the same time as ten lines of assembly code. Those ten lines of C will do far more than ten lines of assembly code. In 6502 all you are doing is moving values between registers or register <> memory. Maybe add a number or increment one of the three available registers A, X or Y. These were all 8-bit registers so you couldn’t even index easily through 64-bit memory. To do 16-bit indexing you stored the 16-bit address in two successive page-0 locations (addresses 0-255) and then used Y as an 8-bit index. You could do the same in page 0- memory with the X register.

(b). It takes a lot of code to do anything in assembly language. You want floating point arithmetic in 6502? Take a look.  I think Steve Wozniak wrote those for the Apple I/II. What we take for granted in languages like C# or Java or JavaScript is code for high level data structures like dictionaries. I’m sure it could be done but it takes a fair bit of programming. You don’t have those in assembly language; all you have to use is simple and not very long arrays.

In C# I wrote a program to read a 46 MB text file and produce a sorted count of all words in the file.  It used a Dictionary, took me 30 minutes to write and it ran in 5 seconds.  It would take weeks to do the same in assembler. 

6502 Page 0 locations were valuable because they made your code both shorter and faster.

I wrote a cross-assembler for 6502 in Z80 as a way to learn Z80. Assemblers use labels (L20, L30, L31 etc. in the screenshot) and I needed a way to hold them efficiently in memory. I ended up with a 26 x 26 index table of 2 byte pointers. If you had a label ‘ROUTE’ then there would be a pointer to a chain at the location for [‘R’][‘O’]. Each entry in the chain was like this

• 1 byte length of rest of label (i.e. 3 for ‘UTE’) – 0 marks the end of the chain.
• 3 bytes to hold ‘UTE’.
• 2 byte address value

No need to hold the whole word as you know the first two letters. It also makes comparing a label against one in the table was faster because it only needed to match against len(label)-2 characters.

So the next value in the chain would start after that or be a 0 for the end of the chain. Yes most of the index table might be empty (all 26x26x2= 1352 bytes) but every label in a chain used 2 bytes less than the full label text. So with more than 676 labels you saved memory. Searching for a label was just a matter of walking a chain. Labels were just addresses; so a location could hold a value like a count. You’d identify it with a label and use that label in 6502 instructions. No variables in assembler; it’s all addresses…

With 6502 you need to do two passes to generate code. If you have a label in the first page of memory (0-255) then instructions are only two bytes long and are faster to execute than the three byte instructions. So on the first pass you don’t know if a LDA label will be 2 or 3 bytes long. After the first pass through though you do know now, so on the 2nd pass it can output the correct size instructions.

Programming in assembler means you have to write a lot of code and in the early days before I had a development machine that meant I had to save the source code to tape and compile it using a cartridge assembler. The CBM-64 could take cartridges and one of them stored assembly language in RAM just like Basic. If the game did something wrong then the CBM-64 would reset and you’d lose your source and have to reload it from the slow tape. Let’s hope you didn’t forget to save changes before you ran it. I spent a few hours gnashing my teeth over a persistent crash. I was calling a CLR routine when it should have been CLS! d’oh…

Note, from memory it was the Mikro cartridge assembler. See screenshot below.

Jump Tables

So a game back then might be 5,000 lines of code or longer. That’s quite a bit to hold in memory, given that you need space for the game machine code, sprites, graphics etc. as well. Plus it’s wasteful having to recompile the same code over and over again. My cross-assembler did 250 lines per second but divide that by two for the two passes.

So I split up long files into smaller ones and created a jump table at the start. There was no linker so the code was loaded into RAM at fixed addresses. If you had five subroutines in one file then there’d be five jumps at the start to the actual function. And the files that called those functions just had a block of five calls at the start.

That way you didn’t have to worry exactly where the function was located in RAM so long as that file was always loaded at the same address.

Switching to Development Machines

It got easier when we switched to development machines. The CBM-64 had a parallel port as did the development machine (Tatung Einstein-a CP/M computer) so a little bit of handler code in the CBM-64 set up the CIA chip to wait for data sent down the parallel cable and put the code directly in RAM. It took no time to load the handler from tape after a crash and then send down the whole file.

Modern CPUs do all sort of optimizing tricks and that’s even before you use vectorization. Compiler writers know how to generate code that uses these tricks but it would take quite a while to learn them so you could use them in hand-written assembly.

Conclusion

Writing in assembler in the 80s was easy to learn. Nowadays I wouldn’t know where to start- the Intel and AMD CPUs have a lot of different chips in their families so there are variations in what instructions are available. Oh and don’t forget there’s ARM CPUs as well.

Writing in C (or even C++) is a lot easier to get into and I very much doubt if you’d get any better performance in writing things in assembly. Also, it would take a lot longer.

A developer called Jakub “Jorengarenar” Łukasiewicz has posted a blog entry Best aspects of C language and I’m more than happy to link to it. It says much of what I think about C but expressed very nicely and its well worth the read.

In his post he refers to a document Rationale for International Standard Programming Languages C (PDF).  This is a 2003 document (C doesn’t change very often)  and not exactly a light read at a trifle over 200 pages long. It’s an insight and commentary into what C99 is about and also lists these five principles:

• Trust the programmer.
• Don’t prevent the programmer from doing what needs to be done.
• Keep the language small and simple.
• Provide only one way to do an operation.
• Make it fast, even if it is not guaranteed to be portable.

If you are learning C this will provide you with explanations of why some things in C99 are what thy are. Like myself you will discover things that you didn’t know. For instance I didn’t know about long double. Or that in K & R C(Kernighan and Ritchie) that all floating point arithmetic was done at double precision but that was relaxed in C89.

I’ve managed one blog entry per day for the last 134 days but a change in side project (I was writing a book to be published, not an Ebook)  but that has to be delayed by at least a year because of an issue at the publisher. In fact I may just publish what I’ve done as my 2nd Ebook.

I’m currently working on networking on a Raspberry Pi. Unfortunately it has to be in C# not C. Networking is a lot easier in C#- you have OOP, task parallel library (far easier than threads), thread pools,. concurrency with async/await and a lot more.  And I can use C# with .NET core or Mono on the Pi.

That said, I will still continue on with game development on the PI. I’ve got my Match Three game half done; I’m quite proud of it and want to get it finished. But I may switch to a slightly less frequent blog posting schedule…

It got very messy because I was trying to have all the moving objects (Player ship, asteroids, bullets, aliens ship) all based on a common ancestor class but then was trying to manipulate those instances of the ancestor class and downcast back from the ancestor instances and I don’t think you can in C++. Compiler errors galore!

It was the wrong approach and I wasn’t using virtual functions. So instead I’m doing it step by step, adding on new features. Much like the original C development in 13 different steps.

Here’s the slightly shorter asteroids.cpp:

// Asteroids C++ 2020 Chapter 27
#include "game.h"

int main(int argc,char * args[])
{
	Game g;
	g.InitSetup();
	g.GameLoop();
	g.FinishOff();
    return 0;
} 

There are other classes used from Game. I haven’t put everything in one “God” class!

Since I got asteroids running on a Raspberry Pi, I have decided I want to incorporate the temperature in the window caption when you switch it to debug mod by pressing Tab. Currently all that does is display position info on moving objects and bounding boxes.

But if I include that code in, I want to be sure that it only works when running on a Raspberry Pi. So I need some code to identify the system. A bit of digging and I discovered the Linux uname command. That link goes to an online man page for uname.

If I run uname -a on my Ubuntu 18.04LTS I get this.

Linux david-Virtual-Machine 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

And on my PI.

Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux

In fact the uname -n command gives david-Virtual-Machine on Ubuntu and raspberrypi on the PI. These are the names though names are often changeable and what if someone is running ubuntu on a PI? Yes it is a thing. But the uname -m identifies the CPU.  x86-64 on my Ubuntu and armv71 on the pi.

I did a bit of digging and found a C program on stackoverflow that will do the same as uname.

#include 
#include 
#include 
#include <sys/utsname.h>

int main(void) {

   struct utsname buffer;

   errno = 0;
   if (uname(&buffer) != 0) {
      perror("uname");
      exit(EXIT_FAILURE);
   }

   printf("system name = %s\n", buffer.sysname);
   printf("node name   = %s\n", buffer.nodename);
   printf("release     = %s\n", buffer.release);
   printf("version     = %s\n", buffer.version);
   printf("machine     = %s\n", buffer.machine);

   #ifdef _GNU_SOURCE
      printf("domain name = %s\n", buffer.domainname);
   #endif

   return EXIT_SUCCESS;
}

And this is what it outputs on a PI.

system name = Linux
node name   = raspberrypi
release     = 4.19.97-v7+
version     = #1294 SMP Thu Jan 30 13:15:58 GMT 2020
machine     = armv7l

So that bit is easy to do. Next is getting the temperature, but that’s for another blog entry…

I spent about five hours trying to get the timing code to compile before I got it compiling and working. Now I’m used to the concept of include guards in C. Those are the #ifndef that you see like this:

#ifndef _timeh
  #include <linux/time.h>
  #define _timeh 1
#endif

But in the hr_time.c file these include guards are on steroids. Not only did I need to include <time.h>, I also had to include <linux/time.h> but with a couple of extra #defines in there. It doesn’t seem right and wasn’t needed with the Windows version.  I’d welcome any comments on this.

#ifndef _timeh
  #include <linux/time.h>
  #define __timespec_defined 1 
  #define __itimerspec_defined 1
  #include <time.h>
  #define _timeh 1
#endif

Without these, I’d get compile errors like __timespec redefined errors.

I’ve uploaded the source files and Visual Studio Code JSON files for this in the file asteroids_ch25.zip in the new repository for the Learn C on Linux Ebook

So feel free to try it. The only difference between this and the version shown in an earlier post is the time (in the window caption) to draw all 100,000 rectangles,  You’ll need to install SDL2 if you want to compile and run the program.

The first 20 chapters introduce and teach C programming with many examples. This link is to an .mp4 of the asteroids game from the book. It’s about 90 seconds long and demonstrates all of the features of the game. High score table, rotating asteroids (four sizes), sound, explosions, ship hyper-jump and shields.

The remaining 30 chapters (20 in the Linux/Raspberry PI) builds up to full source code, about 2,000 lines, in 13 stages and I explain how each feature works and is implemented.  All of the book’s source code is on Github. (Windows) or (Linux). More about me. Buy the Windows one on Amazon(UK), Amazon(US) or the Linux/Raspberry PI. (UK). You can buy the book in other regions by changing the region in Amazon to your local one.