This would be *VERY* difficult on the C64 (beginning)


This would be *VERY* difficult on the C64 (end)

In this series of articles, I plan to look at simple building blocks of games programming, leading to programming a simple game.

The title of these articles is a quote from the Commodore 64 Group Leader of the local computer club I attended in 1984.

First, I must clear up a misunderstanding about the course “Let’s Make a Retro Game”, which has now reached its third episode on the YouTube channel “Electric Adventures”.

I was amazed to hear about this programming series, but I didn’t know exactly how the game was going to be written, or implemented on SEVEN different platforms, each with a different BASIC, and two different processors. These are MSX1, Spectravideo 318/328, the Colecovision games console, the Sinclair ZX Spectrum, Amstrad CPC (all Z80 based), as well as the Atari XEGS (6502 based console version of the Atari 8 bit computer system), and even the dreaded (6502 compatible) Commodore 64!

There was a mention of Z80 Assembler, the Z80 and TI99XX video chipset, other Z80 based computers with different video chips, and even 6502 Assembler for the Atari and C64. It also mentioned that the Colecovision games console is based on the Spectravideo 318/328 design. One difference is that the sound chip is by Texas Instruments and the same as in the BBC Micro.

I’ve now found out that, although this course will be using Z80 Assembler and 6502 Assembler, it’s not really a case of learning to program in those languages, but how to use an extensive game template linked with another two files, where most of the code has been prepared. It could be a bit like a game making package, such as “Shoot ‘Em Up Construction Kit”, although in this course you actually type in or modify a few lines which represent a small percentage of the total code and you don’t have to learn many Z80 or 6502 instructions. I can’t actually say how much people will learn about programming from this course, or if it’s possible to use this knowledge to create anything else except a shoot ’em up game.

There’s one main file containing the template program, which just prints the word TEMPLATE on a hires screen, while a ball is bouncing round the screen off the borders and there’s a bat at the bottom of the screen, which can be moved to the left and right, but the ball doesn’t bounce off the bat if it hits it. The template includes the message TEMPLATE, a font definition, a sound effect, and sprite data. One file is a list of labels followed by EQU (i.e. equate, meaning equals) instructions saying what numbers or memory locations these represent. The other file is a list of definitions of various subroutines which can be called up by the Template program itself. This includes various occurrences of CALL followed by addresses in the ROM. MSX1 has an extensive set of ROM routines, unlike the C64. MSX2 has even more of these routines. Obviously, there were no such templates around in 1984-1985 when I was being driven slowly round the bend by Commodore BASIC V2 on the C64. I think that MSX represents the best work Microsoft has ever done! After MSX, it seems to have been downhill all the way with the very derivative and buggy Windows OS copying the MacIntosh, the Amiga, and the Acorn Archimedes, as well as Visual BASIC, which is more like C than BASIC! Here’s the link to the Electric Adventures course…

I had been struggling to program the Commodore 64 with its totally f*cked up BASIC for several months, but obviously I didn’t get far, because Jack Tramiel had already sabotaged the C64’s BASIC before it was released. I presented the Commodore 64 Group Leader at my local computer club with a short program I called “TARDISes in flight”. This was based on the hot air balloon sprite program from the Commodore 64 user guide. The original program displayed a sprite that looked like a hot air balloon with a C logo moving across the screen. I managed to change this so it displayed a sprite that looked like the Doctor’s 1950s-1960s Police Box shaped TARDIS from the TV series “Doctor Who”, as well as a second sprite that looked identical, then made them cross each others’ paths. This was still on the text screen, because that was what was used in the original example and just turning on and clearing a C64 graphics screen is so difficult, although other computers do this with commands such as MODE <n> , SCREEN <n> , or GRAPHICS <n>.

Obviously, the next stage or stages was to detect when the sprites collided, then make them bounce off each other, meaning to stop and travel off in different directions. The C64 Group Leader obviously added some PEEK and POKE commands to my program, because PEEK and POKE is how you do MOST THINGS on the C64, apart from just printing text. After this, a number was displayed in the top left hand corner of the screen. He pointed out that the number displayed changed when the two sprites collided, so the program was detecting collisions. Obviously, this wasn’t what I had in mind. I asked him how to make the sprites bounce off each other as well. His now legendary reply was “Oh, that would be VERY difficult!” and that was the end of this programming session. This was the point where I gave up on the C64, and decided to look around for a replacement which could also play polyphonic music.

We’ve already got a big building block for a simple game, which is the program I recently posted in a de debunk. My opponent, the C64 fanatic TMR, has criticised my program as being “cack handed”, and even refused point blank to convert this listing into Commodore BASIC V2 for the C64. I’m not sure why this is, but it’s probably for some really nasty and devious reason, such as gaining a feeling of superiority by actively trying to prevent other people from learning to program. I saved my MSX BASIC V2.0 program as VDIFF6.BAS, then posted it on YouTube, included in my last post on here. Here it is again…

This program needs a bit more work on it, though. First of all, the sprites could be redesigned from the 8×8 resolution sprites expanded to 16×16 to proper 16×16 resolution sprites. MSX 16×16 sprites are defined in four 8×8 blocks in the order top left, bottom left, top right, and bottom right, They can be designed on graph paper, or in a special sprite designer, like one I’ve typed in from the Dutch magazine “MSX Computer Magazine”. This saves the finished design as BASIC lines of DATA statements, which can be read into a SPRITE$(N) definition.

MSX BASIC, even V1.0, has some very advanced commands, such as SPRITE$(N), PUT SPRITE N,(X,Y),C , SPRITE ON, SPRITE OFF and ON SPRITE GOSUB. We should also look at how to program the same demo and simple game without using these commands, as in Tandy Color BASIC, or Dragon BASIC. There were listings for the Tandy Colour Computer/Dragon in the amazing British magazine INPUT. This magazine exposed the C64’s BASIC V2 as crap in Issue No. 3, then started using Simon’s BASIC, which wasn’t designed with an option to create stand alone programs, in spite of a third party obscure compiler released some time later which I never heard of in 1984-1985. INPUT magazine was teaching how to do BASIC programming on several computer platforms, but this was before MSX came out. Luckily, I recently found out that there was later a Spanish version called “INPUT MSX”, which included the same listings converted into MSX BASIC, but with a lot of other articles such as games reviews, book reviews, computer news, and ads. You can find and download copies of “INPUT MSX” on http://www.maquinitas.org/revistas/input-msx/ , type in the listings for MSX, then refer back to the original English language articles in INPUT, if you can’t make out the Spanish articles at all.

There are a few things to consider when converting Dragon/Tandy listings to MSX. The commands which cause the main problems are PMODE N,N, PCLS, PRINT @ N, PEEK and POKE. To deal with these, you just delete all references to PMODE N,N, which selects one of a few limited palettes, as well as PCLS which clears a graphics screen, because SCREEN <n> in MSX automatically clears the graphics screen. PRINT @,N causes some problems. This is because the Dragon/Tandy text screens are 32 columns by 16 lines, but these positions are each represented by one number, instead of seperated into columns and rows. This means dividing the number by 32 to get the row, then the remainder is the column. You’d have to use the commands SCREEN 1:WIDTH 32 for the nearest equivalent screen. You may be able to do the same in MSX BASIC by using LOCATE N, instead of LOCATE X,Y , each followed by a PRINT command. Of course, PEEK and POKE commands can’t be used with the same memory locations, or in the same way on MSX as on Tandy/Dragon. Even some of the numbers to PEEK and POKE are different on the Dragon and Tandy, which was to avoid legal problems because the Dragon was based on the Tandy Colour Computer. There’s also a technique in Tandy/Dragon BASIC of making a character for a game, by defining a sequence of CHR$(N) commands. I think this may not be the same technique as MSX BASIC, where SPRITE$(N) is followed by 8 or 16 CHR$(N) commands, meaning that each one of them is a bit pattern. The Dragon/Tandy may be making up a string of graphics characters instead.

I’ve just done a redesigned version of the TARDIS sprite, using the very handy sprite editor created by http://www.electricadventures.net. Unfortunately, this sprite editor only runs under Windows and requires the .net framework, but no one’s perfect! The data for this sprite is as follows, output in Assembler hex format using the Assembler DB (Define Byte) directive, which translates easily into an MSX BASIC definition. However, with such a large sprite, made up of 32 bytes instead of 8 bytes, we have to first define a string of 32 bytes, let’s call it S$ before using SPRITE$(N)=S$. This is because even the amazing MSX BASIC V2.0 can’t fit all of that onto one program line, although it’s much better than Commodore BASIC V2, which can only manage 80 characters!

db 01h,02h,02h,0Fh,1Fh,11h,11h,11h
db 11h,1Fh,1Fh,1Fh,1Fh,1Fh,1Fh,3Fh
db 80h,40h,40h,F0h,F8h,88h,88h,88h
db 88h,F8h,F8h,F8h,F8h,F8h,F8h,FCh


My new improved program (part 1)


My new improved program (part 2)


My new improved program (part 3)

Following this, I decided to improve on my demo program, by doing a sound effect, changing the sprites’ colours, and improving the routine to make them bounce off each other. Here’s the video of the new improved version…

Unfortunately, the hires MSX2 SCREEN 7 mode (512×212) used here has resulted in the stars ending up more or less invisible in this video.

That’s all for now! Just try and take in the techniques I’ve revealed to you here, before the next installment in this exciting series.


Posted February 19, 2015 by C64hater in Uncategorized

3 responses to “OH, THAT WOULD BE *VERY* DIFFICULT! – PART 1

Subscribe to comments with RSS.

  1. The more I read this blog, the more tickled I get. The Commodore 64 was introduced in 1982 – 33 years ago at the time of this posting. The last Commodore 64 rolled off of the assembly line in 1992 – 23 years ago at the time of this posting.

    Why are you so hung up on a computer that’s been off the market for over 20 years … your energies could be much more fruitfully directed toward learning modern programming on modern machines.

  2. I’m glad to hear that you’re “tickled” by my blog. This obviously means you enjoy it, although different countries and areas use the same words to mean slightly different things. The reason why I’m writing a blog attacking the Commodore 64, which ceased production 23 years ago (well done Commodore buyers Escom for not making any more), is because I was provoked into starting it by the celebrations of the Commodore 64’s 30th anniversary in 2012. It is totally sick to celebrate the anniversary of a computer which was so poorly designed that it came with a version of BASIC which didn’t support its hardware, meaning that there were no commands even to draw a line across the screen, or just to play a little tune. The BASIC could have been upgraded in 1983 before much damage was done. I was heartbroken to find out that my wonderful new colour computer and synthesiser was just a pile of unprogrammable shit, which I had to sell 10-11 months later for about half price of the computer, some books and software. The several extended BASICs weren’t designed to produce stand alone programs and not many magazine articles or books were ever written about them. As you’ve probably heard, when a butterfly flaps its wings in Slovenia (or anywhere else), this can influence events all over the World, so please keep reading my blog to find out more things such as how Jack Tramiel and his sons delayed me from becoming a one man band, how they influenced when and where my first flat was, how they made me leave the computer club and not join another one, etc, etc. I’m currently studying programming on the Raspberry Pi computer, as well as on MSX2.

  3. So, how much of this ‘super duper, fantastic, mega, unbelievably complicated’ code and associated knowledge did you actually write? As opposed to copying somebody else’s code from a book/magazine and altering to suit your needs and claiming it as your own?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: