Part 25: Kangra - PotholesLet'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.
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.
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
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.
start address(decimal) ? 884 (hex=0374) 884 lda # 8 886 sta 58 888 lda # 0 890 sta 57 892 ldy # 0 894 clc 895 sta 1024 898 sta ( 57 ),y 900 cmp ( 57 ),y 902 beq 925 904 tya 905 pha 906 lda 58 908 pha 909 jsr 947 912 pla 913 sta 58 915 pla 916 tay 917 lda # 0 919 inc 57 921 bne 930 923 inc 58 925 clc 926 adc # 1 928 bne 895 930 iny
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.
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: