Part 25: Kangra - Potholes

Let's Play Potholes!
Compute's Gazette: September 1983



Feel the thrill of being a public works vigilante!

Potholes is a top-down chase game where you try to fill in all the potholes of the city streets while the corrupt street commissioner tries to stop you, apparently by crashing into you, because that's just how corrupt the commisioner is. Yeah, it's a pretty cruddy Pac-Man style game.

You may be wondering, why is there just a gif? Is there no sound? Why is only half the screen showing?

Well, that's really all you need to see. No other maps, nothing on the rest of the screen, and indeed no sound. To be fair, it's not quite as choppy as the gif framerate makes it seem.

This is, put simply, a really lazy port of a VIC-20 game. From the article it sounds as if they had to strain to get it working on the lesser cousin of the C64. When it came time to submit this version, they must have been tired out. For instance, take a look at this:



That's where the sound would be playing, if there were sound. They didn't bother to simplify those loops, they just dropped the POKE for sound from the VIC-20 version.
Also, there are variables named S1 and SL used right next to each other. Take that, Compute Gazette's typists!

This uses the standard programmable characters for graphics, although to their credit they specifically mention trying to use less common ones so that the program is still readable. They only needed a handful for the cars anyways. Although that did make me hunt around trying to find what petcat uses for the left arrow (it's '_', by the way). The VIC-20 has half the screen size of the C64, and there's no effort to change that either.

When I first typed this in, I left out a line of data statements that resulted in the potholes displaying as blanks. This actually improves the game a bit, because it's slightly harder to make the turn when you can't see the street. I call this version 'Snowplow'.

It's possible that there is still a bug in Potholes, because the article suggests that the enemy vehicle is supposed to replace the potholes as it goes, and I don't see that happening. Of course that would also make the grid nigh-impossible to clear, so maybe it's deliberate.

The Good
About the only positive thing about this is that the relative speed of the cars is balanced well; the enemy car is always moving towards you, but you can outrun and get ahead of it given enough open road.

The Bad
It's a bad port of not-too-exciting game.
It uses the odd key arrangement U-H-K-M, making it slightly harder to change direction on some corners.

At this point you're probably wondering, why do a write-up of a mediocre game like this? Well, seeing how this is a Let's Play, it seemed wrong to not bring a game for this issue. But what I really wanted to talk about is one of the other programs. (And no, it's not the similarly-mediocre Demon Star, which was already passed on once this thread.)



Given the brief forays into the guts of BASIC programs, and the discussion of machine language, assemblers, PEEKs and POKEs and other sorts of magic, I figured we should add this one into the mix.

What is disassembling? In brief, it means looking at machine language code in memory, and turning it into something slightly more readable.

You may have gotten the impression that 'machine language' and assembly as written by programmers are the same thing, and that's only sort-of true. The way machine language is stored in the computer's memory is as a series of numbers. Programmers don't like to work exclusively in numbers, though -- it's easier to use symbols. The main thing distinguishing 'assembly' language from any other programming language is that the symbols and statements correspond precisely with the values stored in computer memory.

Here's an example from the magazine (it's a fragment from one of their previous programs) :

800 FORADRES=884TO930:READ DATTA:POKEADRES,DATTA:NEXTADRES
882 DATA169,8,133,58
888 DATA169,0,133,57,160,0
894 DATA24,141,0,4,145,57
900 DATA209,57,240,21,152,72
906 DATA165,58,72,32,179,3
912 DATA104,133,58,104,168,169
918 DATA0,230,57,208,7,230
924 DATA58,24,105,1,208,221,200

That pokes the code into locations 884 to 930. The disassembler gives us this:

So you point your disassembler at a block of memory, and the output will be whatever assembly language instructions those values in memory correspond to. Now, since every program is sitting somewhere in memory, you can use a disassembler to examine any program. Even the 'operating system' (such as it is on the C64) or the BASIC interpreter. It's a very powerful hacking tool.

I'll be doing another post on the subject, in which I'll be dissecting some of the machine language code that's been in the thread so far.

The Weird
Some articles from the era are very obviously dated:


But others almost could have been written yesterday:


If you wonder why the tech world has always seemed a bit paranoid, maybe it's because there were ads that made talent searches look like a horror film: