“Oh that would be VERY difficult! – Part 5“

(collision detection in Commodore BASIC V2!)

A video of an amazing program showing collision detection and one sprite bouncing off another on the C64!

This post is based round a comment I received eleven months ago from someone called Mark. It demonstrates using the VICE emulator on a Raspberry Pi computer, collision detection and moving a sprite after the collision in the awful Commodore BASIC V2. Nothing like this appeared in any official Commodore manuals for the C64.

I must apologise for taking so long to make another post, but I‘m now dealing with a lot of complicated programming techniques on the C64, to try and reveal how some people managed to program it!

I actually remember looking up all the memory locations used with the PEEK and POKE commands in this listing, then writing a very detailed summary trying to explain what was going on. Unfortunately, that text file is absolutely nowhere to be found now. I‘ve looked for it on several Linux partitions, a Windows partition on both my laptops, as well as in drafts folders for all my email addresses and I just can‘t find it, so I‘ve had to start again from scratch!

First of all, I think I should say thanks to all the people who have been visiting this blog recently even though it‘s several months since I made any new posts. For those of you who are new to this blog, to sum up, I bought my first computer during early 1984 (April?) in Britain. I grew up in London, so there was a good selection of computers in local shops, although some of the computers listed in the magazine “The A-Z of Computers“ didn‘t seem to be available from any shops I saw. They may have only been available via mail order. The computers which I remember seeing available in shops during early 1984 were Atari 8 bit computers (400, 800, 600XL, and 800XL), the Acorn Electron, BBC Micro (also by Acorn), Commodore VIC-20, Commodore 64, Dragon 32, Sinclair ZX81, Sinclair ZX Spectrum, and Sinclair QL. These computers were available at various shops, although Atari seemed to have quite limited distribution, but Atari computers were available through the dealer Silica Shop. I went through the magazine “The A-Z of Computers“ looking at the prices and specifications of all the computers. I was concentrating on the section “Under £500“ because there was no way my Dad would have paid £500 or more for a computer. I found out from reading this book that some computers had what were described as synthesizer chips, while others had less powerful tone generators, or even more basic chips which could only beep. I thought I could kill two birds with one stone, by getting a computer and a synthesizer combined in one. Using this information, I made up a shortlist of computers which included the Commodore 64, but also Atari computers, the BBC Micro, and possibly the Memotech MTX computers which weren‘t widely available. At this time, the BBC were running a computer literacy project based round their own branded BBC Micro computer. For that reason, as well as the fact that it had a built in 3 channel sound synthesizer chip, I said to my Dad “Get me a BBC Micro!“ (for £399), but unfortunately my Dad was quite miserly and thought he knew best, although he knew next to nothing about computers, except how many K they had and how much they cost. He bullied me into getting a Commodore 64, which I found out years later had decreased in price from £399 to £199. It turned out he didn‘t even know about RAM and neither did I. What I mean is that I later made the very depressing discovery that although the Commodore 64 had 64K of RAM chips inside it, there was no easy way of using all this RAM, and no way I could find out of how to use it. This information was actually on the startup screen which included the message “38911 BASIC BYTES FREE“. As 1K=1024 bytes, this means just under 38K! The ZX Sinclair Spectrum 48K has about 40K free to BASIC. Later on in 1984, some new computers came onto the market. These included the Amstrad CPC464, MSX computers, the Commodore 16, and the Commodore Plus 4. The Commodore Plus 4 was a better designed computer than the Commodore 64, because it came with a much better BASIC called Commodore BASIC 3.5, as well as 4 pieces of software built in on ROM, plus a Machine Code Monitor. It had 64K of RAM. The start screen said it had “60671 BYTES FREE“, which means just over 59K. For more detailed information about events leading to me getting a C64, please read from the beginning of this blog on https://commodore64crap.wordpress.com/2012/08/

Here‘s the program Mark sent me in a comment…

“Not my code, but simple collision detection in basic on the C64:“
(comment by Mark in “Oh that would be very difficult – Part 1“) https://commodore64crap.wordpress.com/2015/02/19/oh-that-would-be-very-difficult-part-1/

10 PRINT CHR$(147):V=53248
12 PRINT CHR$(13);CHR$(13);CHR$(13):PRINT SPC(2)CHR$(209)SPC(22)CHR$(209)
15 FOR T=12288 TO 12350:POKE T,255:NEXT:POKE 2040,192:POKE 2041,192
20 POKE V+39,1:POKE V+40,3:SC=V+31:SS=V+30
25 X=80:DX=1:POKE V,X:POKE V+2,125:POKE V+1,80:POKE V+3,80:C=0:POKE V+21,3
30 X=X+DX:POKE V,X
33 XX=PEEK(SC):XY=PEEK(SS)
34 IF CD=0 THEN IF XX=1 THEN DX=-DX:POKE V+3,PEEK(V+3)-23:CD=20
35 IF CD0 THEN CD=CD-1
38 IF XY=3 THEN POKE V+3,PEEK(V+3)+1
46 GOTO 30

 

Here‘s a breakdown of what the program does, then you‘ll find an explanation of memory locations used following the next paragraph.

 

In the program above, line 10 prints PETSCII character 147 to clear the screen, because we‘re only using the normal text screen, instead of a graphics screen. After this, V is definted as 53248, the base address of the VIC-II chip, meaning the first register. Line 12 positions and prints two solid circle graphics characters. This line really shows how inadequate Commodore BASIC V2 is when it comes to positioning characters to print! Line 15 POKEs the sprite data into memory locations 12288 to 12350. This sprite data is just the byte 255 into each location, producing solid square sprites. The sprites are then drawn on the screen when locations 2040 and 2041 are each POKEd with 192. This could be bitwise programming of registers, setting certain bits. Line 20 first of all sets the sprites‘ colours, when V+39 and V+40 are each POKEd with different numbers. Any numbers from 0-15 could be used here. SC is set to V+31, while SS is set to V+30, meaning the sprite to sprite collision and sprite to background graphics collision detect registers. Line 25 is setting up sprite coordinates, but I don‘t understand how these coordinates work! I‘ve tried changing the numbers, but with unusual results. This is the text screen we‘re using, but sprites aren‘t part of the background, so may be using some other kind of coordinates system. The most important thing happening in this line is the horizontal coordinate X is set to 80. DX stands for direction of X and is set to 1, meaning it moves right, instead of -1 or a value greater than 1 or less than -1 for increased speed. POKE V+2 affects the sprite 1 vertical coordinate, POKE V+1 affects the sprite 0 vertical Y coordinate, while POKE V+21 draws or redraws a sprite on the screen. In Line 30, the value of X then affects what V the vertical coordinate of sprite 0 is POKEd with, changing the X coordinate, causing movement. Line 33 is checking for collision detection using PEEK commands. Line 34 is using the previously undeclared variable CD, which I assume means Collision Detection, by checking if it equals 0. As it‘s never mentioned previously, then it MUST be equal to 0. Then if XX=1, meaning a collision has happened, DX=-DX, so that the vertical direction is reversed. After this POKE V+3 changes the sprite 1 vertical coordinate, then CD is set to 20, which at least means it‘s no longer 0, but it‘s not clear what this does! Line 35 looks like it may contain some kind of errror, as it reads “35 IF CD0 THEN CD=CD-1“. I think this is where the command ELSE may have come in useful. It may mean IF CD=0, meaning that the conditiion in the previous line has failed, or that for some strange reason the programmer wanted to cancel out the previous command “CD=20“, but why?! It looks like it may have something to do with the direction of a sprite, instead of with collision detection. Line 38 reads “38 IF XY=3 THEN POKE V+3,PEEK(V+3)+1“ This is checking XY, which means sprite to sprite collisions. If the value of this is 3, which I‘m not sure what it means, then it POKEs V+3, the sprite 1 vertical coordinate either with its own contents or with the contents of RAM at the same position as a ROM location as well as adding 1 to it. This business of POKEing a location with its own contents is one of the most confusing things about the Commodore 64! Line 46, after all this BASIC V2 confusion issues a GOTO 30, meaning go back to the start of the loop.

 

It‘s been very difficult writing this post, so I‘ve decided to split it into two parts. Luckily for you, this means the next part explaining the program in detail, along with a conversion into one or more other BASIC dialects, will follow fairly soon. That‘s all for now!