C128 sprite collision 1

Several months ago, I posted here that I was trying to convert a crappy C64 BASIC V2 listing, which contained lots of PEEK and POKE commands, into the much improved C128 Commodore BASIC V7 language, which as you should know from previous posts, documentation in official Commodore manuals, as well as from books and magazines by third party publishers, includes commands for colour, graphics, and sound, which Commodore 64 owners had been deprived of. C64 BASIC contains only 71 commands, while C128 BASIC contains over 140 commands!

Unfortunately, although I seemed to be making progress, I got some unwanted, or even totally weird, effects in my code. I’ve posted some videos here, showing the development process so you can see what happened. I thought there may have been some more videos I made about this, but I can’t find them, so it seems not, because they should all have been automatically uploaded to my Google account, under Google Photos. In this post I may mention something that I attempted to do after making all these videos. This is because the whole process has totally confused me. I eventually gave up, but then people wanted to know what progress I’d made and a possible solution.

C128 sprite collision 2

After extensive research, I think I’ve found out what the problem is. Unfortunately, it’s a problem with Commodore BASIC V7 itself.

During the period after the C64 was released in 1982 with its 1977 style BASIC, other computer desgners (e.g. MSX, Amstrad) started to release versions of BASIC which included interrupt commands. This means commands that constantly monitor the situation, regardless of which other commands anywhere in your program are being executed at the time. Commodore BASIC V7 also includes interrupt commands. The command MOVSPR number, X, Y is a very powerful, interrupt driven command, which will start a sprite moving even in direct mode, without being contained in a program. The problem is that although Commodore BASIC V7 includes interrupt commands to get sprites moving, the way of dealing with collisions is to redirect control to subroutines with the command COLLISION type, line number. The problem seems to be that although this command is also interrupt driven, it needs to redirect control to a line number, can’t override or turn off the MOVSPR command and whatever commands you may include in your subroutine, even when you use another MOVSPR command, aren’t powerful enough to react against the first MOVSPR command, which just continues happily on its merry way! I have done extensive searches, including reading through books on how to program the C128, but haven’t been able to find a single program listing of how to use COLLiSION in a way that would enable this program to work in the same way as on the C64. One game listing I found just stopped and said something like “You’re dead!” when a collision occurred. I eventually came to the conclusion that this would require another routine written in Assembly Language/Machine Code to set up an interrupt, called with a SYS command, which would be constantly checking the situation, ready to redirect control to another Assembly Language/Machine Code routine in the same code that deals with it!

C128 sprite collision 3

I can’t help wondering what happened with Commodore BASIC V7 to cause this problem. I think it may have been yet another case of rushing to release a computer onto the market before development was finished, even though Jack Tramiel left the company before the earlier Commodore 16 and Commodore Plus/4 were released. Unfortunately, he taught the Commodore staff all they knew about business. The C128 development team might have finished work on the MOVSPR number, X, Y command, then been given a deadline by Commodore to have the BASIC completed in time for a show or in tiime to manufacture the first C128 computers.

C128 sprite collision 4

So that’s it, I’m afraid. I can’t find any solution to this problem! Why not try going over the examples I’ve listed on this site? Can anyone reading this provide a solution?

Posted November 30, 2019 by C64hater in Uncategorized

DEBUNKING “NOT ROCKET SCIENCE – Part 5“   10 comments


A collection of Memotech MTX games converted for the Colecovision console, both using the TMS9918/9928/9929 video chip

TMR of the rival blog “C64 Crap Debunk“ https://c64crapdebunk.wordpress.com/ (a maths whiz who can remember lots of five digit memory locations) has had the cheek to try and debunk my amazing post “Oh that would be VERY difficult – Part 5“, so here‘s my reply about how he‘s talking crap as usual.

This blog is mainly about how Commodore even dared to unleash a computer on unsuspecting consumers which contained a three channel/three note polyphonic synthesiser chip, as well as colour hires graphics, but didn‘t include a programming language which supported those features. I‘m trying to demonstrate what a struggle people faced trying to program it, while Commodore just sat back and waited for third parties such as 64er magazine, Compute!, Data Becker/Abacus, David Simons with Simons‘ BASIC, Loadstar, Oasis Software (with BASIC Lightning/White Lightning/Machine Lightning), Your 64 magaine, and lots of others to fix their mess! I‘m trying to avoid featuring any advanced tools running on x86 PC type computers which the vast majority of C64 owners couldn‘t afford back in those days.

Unfortunately, TMR wrote a very, very long post, which you can read on https://c64crapdebunk.wordpress.com/2019/01/29/not-rocket-science-part-5/ so I‘ll have to concentrate on the main points instead of quoting most of it here.

As for the amounts of RAM available on different computers, there was the Amstrad CPC family which managed to have more RAM free to BASIC than the C64 AND another 16K dedicated to hires graphics, while MSX computers had about 28K free to BASIC plus another 16K of video RAM. The Commodore Plus/4 declared 60671 bytes free to BASIC on its startup screen.


This book told C64 programmers to PEEK and POKE themselves to death!

I don‘t know how people in general managed to learn how to program the C64, but I doubt that many, if any, of them managed to memorise lots of five digit memory locations to use with PEEK and POKE in Commodore BASIC V2! All the official Commodore Manuals kept mentioning using BASIC with five digit memory locations. They could have avoided this by suggesting programming in Assembly Language with a prepared file of equates giving meaningful names to those locations, as well as predefined Macro routines, which are a bit like BASIC commands, translated into pre prepared routines of Assembly Language commands. Some people said that Commodore BASIC V2 has all the inconvenience of Assembler combined with the speed of BASIC!

TMR made the revelation “each of the eight hardware sprites is represented by one bit in the register’s byte so testing the state of that bit tells the program if the relevant sprite has been involved in a collision. The same is true of the sprite to background collisions and indeed several other sprite registers“ I don‘t think I ever knew that before!

Of course, I read back in in 1984 that variables such as V were often defined as 53248 ($D000), then offsets such as V+1, V+10, etc, were used for the various VIC-II chip registers. This technique was also used for the SID chip, which started at the address 54272/$D400, so S=54272, but it seemed to me there there were hundreds or even thousands of five digit memory locations to remember apart from the VIC-II and SID chip registers, so that wasn‘t much help!

TMR made a further revelation “The sprites don’t use the screen’s co-ordinates because they work independently of the screen itself – the same is true for other platforms including the Atari 8-bit – and, because sprites can move into the border areas to allow objects to enter or leave the screen smoothly, they therefore need different co-ordinates. The top left corner of the visible screen for a sprite on the C64 has the X value of 24 and Y is 50“!!

TMR wrote about the mysterious variable CD “This part of the program is dealing with collision detection between the moving sprite and the background, with CD being used as a timer; when a collision occurs CD is set to 20 and, until that timer decreases back to zero (line 35 handles that side of things, lowering the value by one with every pass of the loop) further collisions are ignored. This is done to avoid accidentally detecting the same collision twice, so your correspondent would hazard a guess that CD is perhaps short for Collision Delay?
 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 35 is an interesting one dear reader, there’s certainly a typo but your correspondent isn’t sure if it was meant to be IF CD>0 or just IF CD since both are valid. The program is actually doing the latter anyway since everything after the second character of the variable name is ignored – so that part at least is a happy accident – but your correspondent did a little digging and tested IF CD to find that it works in the same way on a number of other BASIC dialects“.

Of course, not all “home computers“ had hardware sprites. Some computers, such as the Acorn Electron, Amstrad CPC, Apple II, BBC Micro, and Sinclair ZX Spectrum had to make do without them. In those cases, User Defined Graphics (UDGs) or just default character graphics were used. The computers with sprites often had other problems. Most of them used the Texas Instruments TMS9918/9928/9929 video chip. If someone decided that their main requirement was that they must buy a computer which had sprites, here were their choices, at least in Britain. Buy a Commodore 64 and end up with an extremely crappy BASIC. Buy an Atari 400/800/XL/XE but not get much support and no real market for your programs unless you could somehow sell them in the USA. Buy a discontinued Texas Instruments TI99/4A with the 9918/9928/9929 video chip for a knock down price, but end up with no real support and a BASIC that didn‘t support the sprites. Buy a Memotech MTX with the same 9918/9928/9929 video chip, but not have much support as it didn‘t sell many units. Buy a Tatung Einstein, also with the 9918/9928/9929 video chip, but not have much support due to poor sales, as well as trying to get your software published by Tatung‘s own Einsoft label, because it seemed all the software was released by them. Buy a Spectravideo 318/328 also with the same 9918/9928/9929 video chip, which was “fairly new to the UK“ (Silica Shop ad), but not get much support, although you could join Silica Shop‘s Spectravideo Owners‘ Club, then later on find out that your computer had been discontinued, probably before you bought it. Buy an MSX computer also containing the 9918/9928/9929 video chip, but take the risk of it not becoming popular, then be left without much support, buying software often via mail order, but finding some cheap games in shops later on. In the USA, your choices would have been more limited, due to trade protectionism. Over there, if you were determined to buy a computer with sprites, then you‘d probably have had no choice except a C64, an Atari 400/800/XL/XE, or a Texas Instruments TI99/4A.

As for converting this program listing to a BASIC for spriteless computers, it presents no problems. This is because the main difference between sprites and UDGs is that sprites are independent of the background graphics, meaning they can move over any background graphics without disturbing them, while UDGs or character graphics are part of the background graphics, so they can‘t do that without careful programming. This usually involves the use of XOR or EOR. In this example there are no background graphics, though!

That‘s all for now! Soon, I hope to post a conversion of the listing in question into Commodore BASIC V7 for the C128!

Posted March 15, 2019 by C64hater in Uncategorized

Oh, that would be VERY difficult! – Part 5   8 comments

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“)

10 PRINT CHR$(147):V=53248
PRINT CHR$(13);CHR$(13);CHR$(13):PRINT SPC(2)CHR$(209)SPC(22)CHR$(209)
FOR T=12288 TO 12350:POKE T,255:NEXT:POKE 2040,192:POKE 2041,192
POKE V+39,1:POKE V+40,3:SC=V+31:SS=V+30
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
38 IF XY=3 THEN POKE V+3,PEEK(V+3)+1


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!


Posted January 26, 2019 by C64hater in Uncategorized

Hello again!   Leave a comment



The C64 GS console, the way the Commodore 64 should have been from the beginning! 

Hello again from me! I feel I must explain about what I‘ve been doing in recent months since my last blog entry on here.

During this time, I‘ve been continuing to think about the imminent destruction of Britain by Brexit turning it into an offshore tax haven, the “moat“ seperating Britain from the rest of Europe, as well as applying for Irish citizenship and an Irish passport.

My plans involve more studying of the book “The Machine Language Book of The Commodore 64“, as well as its follow up book “The Advanced Machine Language Book of the Commmodore 64“. Unfortunately, the text of these books is quite complicated, getting right to the heart of the C64, so that‘s why I haven‘t done any more posts about it. Apart from this, I wanted to demonstrate some examples running on an emulator, but this wasn‘t as straightforward as I thought it was, so that‘s why I haven‘t done it so far. I‘ve just had a look at two C64 emulators I installed under Windows 10, although I normally use Linux OS. I looked at C64 Forever, but found I had to pay just to get a full screen display, so I decided not to bother with that program, After some time, I managed to get WinVICE running. This was a bit dificult, because there was more than one version installed and it didn‘t even seem to appear on the Start menu. I ended up putting some shortcuts for the C64, as well as the C128, and the Plus/4 on the Desktop and it‘s now working OK.

Of course, I want to create a version of Microsoft Extended BASIC for the C64. This would probably be the 16K version, similar to the amazing Dragon 32/64 and Tandy Coco computers. I think that the most important commands, which C64 owners were crying out for, are COLOR N,N,N, to set the text and even graphics screen colours, SCREEN N, to set the display mode as text, multicoloured text (which I didn‘t even know existed when I owned a C64, thanks to Commodore‘s crappy manuals), multicolour graphics, and hires graphics, as well as LINE(x1,y1)-(x2,y2),c. It‘s a real shame that Microsoft never released a decent BASIC for the Commodore 64! Just think of how much money they could‘ve made. Unfortunately, I think Microsoft started to go downhill when they started producing Windows. I prefer their earlier work.

A very significant revelation in “The Advanced Machine Language Book of The Commodore 64“ is made on page 140, where it says “If we have added our own tokens for our new commands using the previously described vector §304/$305, a special character is no longer necessary“!! This means that new commands wouldn‘t have to be prefixed by characters such as “!“ or “@“.

Another amazing idea of mine is to convert some simple BASIC games listings from other computers into C64 BASIC. This will probably involve the use of two POKE commands to set the text cursor row as well as just the column, by using variables. This isn‘t possible using the Commodore 64 PRINT TAB(n) command, which only sets the column. Commodore‘s widely publicised way of dealing with this was to use strings of cursor up or cursor down control characters, in conjunction with the LEFT$, MID$, or even RIGHT$ command.

I think it could be an amazing experiment to get some Chimpanzees, babies, or toddlers to sit down with a Commodore 64 next to a computer running a version of Microsoft Extended BASIC, complete with instruction manuals, then see how they got on, but I don‘t think I could set this up. I think the end result would be quite predictable, though.

Thanks to everyone who‘s been visiting this blog in the meantime!

Posted June 7, 2018 by C64hater in Uncategorized

Debunking TMR‘s “Prepare To Operate – Part 2“   Leave a comment

Debunking TMR‘s “Prepare To Operate – Part 2“


Orac, one computer from “Blake’s Seven”, was a talking computer with just flashing lights and voice control

TMR of the blog “C64 Crap Debunk“ recently had the cheek in https://c64crapdebunk.wordpress.com/2017/12/23/prepare-to-operate-part-2/ to debunk my excellent post examining operating systems in general and what they have to do with the Commodore 64!

I haven‘t actually written an operating system yet, but I think I may be able write one at some stage in the future. To do this, I have to look at what other people have done, what operating systems have in common, and how they work. It‘s possible to create your own custom distro of Linux, using kits provided by groups such as Ubuntu, OpenSUSE, and Arch, but that‘s not the same as creating your own OS. These kits are limited to creating a branded personal version of the distro done by the group or company which provides the kit, you can rename it whatever you like, choose to include or exclude any software you like on DVD, although other software can still be installed later on, but the end result will be based on Ubuntu, OpenSUSE, Arch, or whatever distro it was based on. As for creating a distro of Linux of a new type or genus other than Debian, Red Hat, Slackware, or the much more recent Arch, you certainly can‘t do that with such a kit.


The computers in “Space: 1999” were made up of lighted panels and TV screens

I thought I expected computers to be absolutely amazing before getting one. This was based on what I‘d seen in sci fi series, such as Star Trek: The Original Series, Space 1999, Blake‘s Seven, and Doctor Who. Looking back at at episodes and clips from these series made before 1984, they show that none of the computers featured had a GUI, they were mainly voice controlled, could also speak, and either had lots of flashing lights, or panels with lighted switches, and could often display videos, but these videos were usually live and had no computer text or graphics overlaid. There was no frequently used standard computer in Doctor Who. I only remember the Chameleon Circuit system in “Logopolis“, where The Doctor typed in some Machine Code and it displayed a pyramid as the chosen new disguise for his TARDIS, as well as a fake TARDIS databank or instruction manual in the following story “Castrovalva“ which responded to commands such as IF for Index File, plus another database in the story “Arc of Infinity“ which gave details of that particular phenomenon. It seems that computers in sci fi with GUI systems may only have started appearing after they appeared in real life in the mass market. People were fascinated by the LCARS menu GUI in Star Trek: The Next Generation (created on colour Apple Mac computers in or before 1987) and have managed to produce something that looks like it running on top of other operating systems.

In Star Trek, keyboards and mice have been totally abandoned, although Scotty manages to type very fast on one in “Star Trek IV: The Voyage Home“ and Captain Katherine Janeway soon manages to pick up typing on a keyboard in the Star Trek: Voyager story “Future‘s End“, set in 1996. I think that the fictitious computers in these versions of Star Trek probably all contain a ROM or some equivalent RAM storage that can survive a reboot containing routines for graphics, so that creators of operating systems don‘t have to worry about doing this. Even the Atari 400/800 ROMs from 1979 and the Amstrad CPC ROMs from 1984 onwards contain graphics routines. Although these computers do display text, it‘s always on a graphic background and as we already know, modern computers and phones can input spoken text as well as be controlled by voice. I think that a future operating system could be entirely graphic, not bothering with any kind of typed commands at all. This goes against Linux and UNIX thinking, but the original Apple MacIntosh System Software had no shell or typed commands.

That‘s all for now! Look out for another amazing expose of the Commodore 64 soon.

Posted January 9, 2018 by C64hater in Uncategorized

The Commodore 64 and Operating Systems – Part 2     Leave a comment

The Commodore 64 and Operating Systems – Part 2


Games for GEOS on the Commodore 64

So, now we continue with this look at operating systems and how they‘re relevant to the Commodore 64.

Operating systems can be created either using Assembly Language/Machine Code for the CPU the hardware is based around, or by using a language which has a version running on that hardware, or on another system which can be used to produce code compatible for that hardware. How this is actually done can be quite complicated to understand.

The Commodore Kernal is a collection of routines which was used on all Commodore computers and updated for new models up to and including the Commodore 128, before Commodore abandoned it for the Amiga, as well as their own PC clones using third party PC BIOS ROMs and MS-DOS. You can read about this crap on http://sta.c64.org/cbm64krnfunc.html and https://www.c64-wiki.com/wiki/Kernal  The only really useful functions are to accept input, provide output, open files, load files, save files, and close files.

The way these calls are used has already been demonstrated in a previous post about the C128 built in MONITOR program. An example of this is below.

LDX #$00
LDA $1820,X
CPX #$0D
BNE $1802
JMP $1800

The program above uses $FFD2 CHROUT to output characters onto the text screen. These characters are held as data starting at address $1820 on the C128, but this should be $1020 on the C64, due to the different memory map. The program starts at $1800 on the C128, but this should be $1000 on the C64. You can read more about this in my post https://commodore64crap.wordpress.com/2013/10/29/the-commodore-128-the-fixed-and-upgraded-commodore-64-part-2/

CP/M only has 31 functions or calls, but the good excuse for this is that it came out in 1978, instead of 1982. The most useful calls are CONIN and CONOUT, to input and output characters from the keyboard. Apart from this there are functions for boot, both cold boot and warm boot. A cold boot starts from scratch, while a warm boot remembers what you were doing before your computer crashed and you reset the OS.

The “home computers“ such as the C64, Sinclair ZX Spectrum, Atari 8 bit, Acorn BBC Micro, Acorn Electron, Amstrad CPC and MSX, etc all booted into BASIC, but they also had a collection of ROM based routines. They were all coded in the Assembly Language/Machine Code for the CPU of each computer, meaning 6510/6502 for the C64, Atari, BBC Micro and Acorn Electron, but Z80 for the Sinclair ZX Spectrum, Amstrad CPC and MSX..

In 1969 onwards, years before the home computer boom, UNIX OS was created in some language on a PDP minicompurer which was probably Assembly Language/Machine Code, then rewritten in the C Programming Language. It was designed to be portable to different hardware. It has system calls or functions which have to be used in C. You can read about some or all of them on http://www.di.uevora.pt/~lmr/syscalls.html as well as http://www.tutorialspoint.com/unix_system_calls/ and http://www.csie.ntnu.edu.tw/~ghhwang/course_slices/OS/Unix_System_Calls.pdf

Years later, leading up to 1985, Amiga Workbench OS was also written in C, instead of in Assembly Language/Machine Code, but it was only designed for Amiga hardware, including a 68000, 68010, or 68020 CPU, as well as the custom chips Paula, Agnus, and Denise.

GEOS is an advanced GUI based OS for the C64, designed to look like the early Apple MacIntosh System Software or Digital Research GEM. It appears mainly as a monochrome system, but can use more than two colours at a time, unlike the early Mac. In spite of this, it never looks anything like as colourful as Atari ST GEM, or Amiga Workbench OS. It doesn‘t boot into BASIC, but into a desktop. It even fixes the C64 design faults by turning off the BASIC and Kernal ROMs, as well as loading a number of equates with meaningful names, similar to the Atari 8 bit computers. It contains functions including DrawPoint for plotting dots on the hires screen, HorizontalLine for drawing horizontal lines, VerticalLine for drawing vertical lines, DrawLine and i_Drawline for drawing diagonal lines! It was programmed in 6510/6502 Assembly Language. It allows users to run non GEOS C64 programs from the desktop, but also to write programs within GEOS. You can read more about it in “The Official GEOS Programmers Reference Guide“, as well as “GEOS Inside and Out“ (another Data Becker/Abacus book), both on http://www.bombjack.org/commodore/books.htm

I think that anyone out there wanting to create a brand new OS, not based on Linux, UNIX, or even on MS Windows, should get their hands on a Raspberry Pi computer, or a phone with an ARM CPU. This type of CPU is RISC (Reduced Instruction Set Chip), but I was surprised to read recently that it has lots of registers, a bit like the 68000 family, instead of the x86 family, or the 6502 family. While thinking up ideas for your new OS you could be watching lots of sci fi to see the way computers work there, then work out a way of actually doing it.

That‘s all for now! Look out for another amazing post about the C64 in the near future!

Posted December 22, 2017 by C64hater in Uncategorized

Debunking TMR‘s “Prepare To Operate – Part 1“   Leave a comment

Debunking TMR‘s “Prepare To Operate – Part 1“

A video comparing UNIX and Linux

In his post “Prepare To Operate – Part 1“ TMR of the blog “C64 Crap Debunk” criticised statistics for my blog which he can‘t identify the source of, claimed to live in an abolished county, thought he could challenge my native knowledge of London, and criticised Linux OS!

I‘ve been pleased to see an increase in the hits on this website, but I don‘t know where they‘re all coming from, except from various countries. As he hasn‘t even seen my stats, I don‘t see how TMR would know either!

TMR said he worked in London for a while in the late 1990s. This has nothing to do with what‘s been happening to London since then. The destruction of London has taken place just in the last few years.

TMR claimed to live in Yorkshire. This is a county which was abolished in 1974! Its territory was redistributed amongst three new counties containing the name Yorkshire, as well as some old and new counties. These were called North Yorkshire, South Yorkshire, and West Yorkshire. Some other Yorkshire territory was transferred to a few new counties not containing that name, as well as to some existing counties. Later still, the counties of South Yorkshire, and West Yorkshire were abolished and split up into lots of Unitary Authorities. The new Doctor Who Jodie Whittaker was born in Skelmanthorpe, Kirklees Unitary Authority (which was in West Yorkshire at the time). To put this into some context, I could claim to live in Wessex. This a historic county and former Kingdom in southern England, which existed even before England was formed in about 970AD under King Æthelstan or Edgar (according to different sources), then continued as a county in England. The name Wessex is still used by some fanatics, but I‘m not one of them. I live in Greater London, but this county has faced territorial claims undermining its status maintained by the post Office, as well as the cricket teams of Surrey, and the abolished county of Middlesex both being based here. At least Essex Cricket Club had the decency to move out after their grounds in Leyton became part of Greater London. Yorkshire Cricket Club still has the cheek to continue to exist.

Linux is an operating system which has been adapted for lots of different hardware. The way it boots up may be different on different hardware, but once booted, I don‘t think Linux depends on making any calls to a PC BIOS ROM, a Mac ROM, or any other ROM. It‘s known as a monolithic Kernel, meaning that it contains drivers for almost any hardware the user may want to plug in, instead of having to install special drivers. In this way it seems similar to the classic Amiga Workbench OS, but this required the command bindrivers in the file “startup-sequence“, so I suppose you could say that means it‘s not the same kind of operating system at all. This method on Amiga OS is called Autoconfig, pre dating Plug and Play on Windows. All Linux distros are built round the Linux Kernel, but have a choice of desktops and different package managers for installing new software. Linux used to be quite difficult to get into, but has now become fairly user friendly, although some distrtos such as Arch insist on making users type lots of commands to get everything set up. In spite of this, some Arch based distros such as Manjaro, and Antergos have added graphical installers. Linux is much better than Windows OS, because it‘s more carefully thought out, doesn‘t depend on typing in a licence number and new distros are available free, so Linux users tend not to use versions as old as Windows 7. Updates are also carried out quite easily and Linux doesn‘t make you wait ages to turn off your computer. I wonder how many thousands or millions of buses, other trips, etc, etc have been missed or fires caused because of Microsoft screens telling Windows users that they mustn‘t turn off their computers because Windows is installing updates? Any Windows user who in frustration turned off their computer by pressing the power button while this is going on have to wait until returning home from their trip to find out whether or not they can boot up their computer again.

That‘s all for now. Look forward to another post soon. This will either be more about operating systems, or about doing graphics on the C64 using techniques from “The Machine Language Book of the Commodore 64“.

Posted December 15, 2017 by C64hater in Uncategorized

The Commodore 64 and Operating Systems (Part 1)   4 comments

The Commodore 64 and Operating Systems (Part 1)


The CP/M Operating Szstem in action

Welcome to everyone who has recently been viewing this blog so much! Unfortunately, I‘ve had serious problems working out what to do next in the quest to find out how some people managed to program the Commodore 64, as well as being very depressed by the destruction of my home city of London. The city is still there, but has been made virtually uninhabitable to me, as well as its nightlife being decimated. If any of you are thinking of visiting London, don‘t bother! Also, as I indicated in my last post, I‘m now exploring a slightly different angle with the C64 for the moment.

Operating Systems are what makes computers go. There‘s some dispute about whether or not the C64 actually had an Operating System, though. Some books and magazines say it had, while other books and magazines say that an Operating System is something you boot into which isn‘t a language waiting for you to type a program in. As the C64 boots into BASIC with the Ready prompt, on that basis it doesn‘t have an operrating system. By this definition, an operating system contemporary to when the Commodore 64 first came out is CP/M or MS-DOS. Each of those systems present the user with a prompt (usually “A>“, “B>“, or “C>“), indicating which disk drive they‘re logged onto. The user can then carry out lots of operations by calling up programs from disk in a way actually designed to be convenient, unlike the botched Commodore DOS on Commodore 1541 disk drives, not including a directory command, as well as using just the commands OPEN or CLOSE followed by various numbers for handling the contents of disks. An MS-DOS or CP/M user with a drive prompt could then type a command such as BASIC, BASICA, or MBASIC to get into a version of the BASIC programming language, or some other command to manipulate files, explore the contents of RAM, etc. This is often called a DOS for Disk Operating System, but actually CP/M and MS-DOS each contain lots of routines loaded into RAM. These routines do things such as detect key presses, print text on the screen, save to files, read from files, and print out files. So to sum up, an operating system is a program which contains lots of useful routines to do everyday things, so that programmers don‘t have to write their own routines to perform these mundane tasks.

The Commodore 64 wasn‘t supplied with an operating system such as CP/M or MS-DOS, but it has what some people call an operating system on ROM. The lying buyers‘ guide “The A-Z of Personal Computers“ said it had “Cassette OS“. This is the Commodore KERNAL. Unlike MS-DOS, the Commodore KERNAL doesn‘t have lots of routines which can be called up. It has a total of 39 routines, as listed on http://sta.c64.org/cbm64krnfunc.html . I don‘t know what routines are contained in the very messy Commodore DOS. MS-DOS seems to have 86 routines it can call up, though. A summary of these can be viewed on http://www.eecs.wsu.edu/~ee314/handouts/dosref.pdf . Details of CP/M system calls can be viewed on http://www.seasip.info/Cpm/bios.html , but there are only 31 of them!

CP/M is made up of two parts, the BIOS (Basic Input Output System) and the BDOS (Basic Disk Operating System). This was an innovation it brought in, because previous operating systems had both these things combined. The CP/M BIOS managed the computer‘s hardware and each manufacturer usually had to write their own, which enabled the BDOS and all CP/M software to work on that system. With the original IBM PC, the BIOS which worked with IBM PC-DOS was put onto ROM. Microsoft had their own version called MS-DOS.

IBM‘s plan was to persuade lots of businesses to buy their IBM PC made from off the shelf parts, but with a custom Copyrighted BIOS on ROM. Microsoft‘s plan was to license MS-DOS to various manufacturers in a form with some kind of software BIOS like with CP/M. This meant that the hardware from different manufacturers could be quite different, but so long as software developers called MS-DOS functions instead of IBM PC BIOS ROM functions, then their MS-DOS software would run on any computer which could run MS-DOS. Some companies making MS-DOS computers which weren‘t IBM PC compatible were Apricot and Tandy. This concept didn‘t last for long, because other companies made ROMs which were compatible with the IBM PC BIOS, then IBM PC compatibles took over the business and home markets.

Of course, GEOS is a fully fledged third party operating system, which did its best to try and fix the Commodore 64 by making it behave like an early MacIntosh. It‘s much more sophisticated than the Commodore KERNAL, CP/M, or MS-DOS.

I think that nowadays a good way of exploring operating systems and what you can do with them is by using Linux OS. It‘s inspired by the older UNIX, but has been completely rewritten. Linux operating system is open source, which makes it highly customisable. It comes in lots of different varieties, called “distros“ (distributions) meaning that the software included with each distro and how to install new software varies greatly. I don‘t think it depends on any ROM, because it can run on PCs, Macs, and Raspberry Pi computers. When booting up or closing down Linux OS it displays hundreds or thousands of lines of text, unless the system is set to cover this with a graphics screen. In that case, you can choose to display them by hitting the ESC key. These lines are called the Linux Kernel.

Unfortunately, any OS shows signs of its origins. CP/M was originally for people building computers, as well as business users. MS-DOS was originally for business users and adding Windows to it didn‘t change this. The original MacIntosh with its System Software was originally for business users, then later versions of the Mac OS or Mac OSX continued in a similar vein. UNIX and Linux were originally for academics.

Well, that‘s all for now! I hope to make another post in the near future.

Posted November 30, 2017 by C64hater in Uncategorized




We’re still examining this book 


Now it‘s time to get on with actually doing something based on the knowledge in this book. There‘s also a follow up to this book, called “The Advanced Machine Language Book of The Commodore 64“, which continues in the same vein.


I‘m going to try and attempt to explain and demonstrate the very daunting tasks of drawing lines (the whole basis of graphics) and playing polyphonic music on the C64, which is child‘s play on other contempory computers, such as the Sinclair ZX Spectrum (drawing lines, but only playing monophonic music), Atari 8 bit, BBC Micro, Acorn Electron (one channel sound only), and MSX computers.


Readers are actually supposed to carry out these exercises for themselves instead of just sitting back, reading these articles, and looking at any accompanying pics and videos. To do this you‘ll need to either install an emulator such as VICE, or C64 Forever, or have a Commodore 128, or even a C64 at the ready.


How to install VICE

I think that VICE and C64 Forever are the worst (or best, depending on your opinion) C64 emulators out there, so here are the links.



It‘s important to remember that the C64 graphics screens are bitmapped into character cells. This seems to make things more difficult when plotting lines, because you have to keep track of when your line passes a character cell boundary, entering a new section of RAM. This is just one way Commodore/Jack Tramiel made things more difficult.

We‘ll need to decide which 6502 opcodes to use in our line drawing programs. It‘s fairly obvious that they‘ll include LDA #number, LDA address, and STA address, as well as loops including the use of LDX #number, and LDA address,X but not clear what else. You should refer back to the previous posts on programming horizontally scrolling text on https://commodore64crap.wordpress.com/2013/10/29/the-commodore-128-the-fixed-and-upgraded-commodore-64-part-2/


There‘s also Bresenham‘s algorithm to consider. This was mentioned but never explained in some crappy C64 programming books I read, probably by Sunshine publications. It turns out that this was developed as long ago as 1962, on an amazingly advanced for the time IBM computer called the IBM 1401, connected to a Calcomp plotter. I don‘t know if the computer could display graphics on a screen, but it could plot them on the Calcomp plotter. Unfortunately, Bresenham‘s algorithm is a complicated algebraical formula. This means I can‘t understand it because I‘m useless at maths, so I‘ll have to design my own alrorithm, based on calculations as simple as possible, as well as tailor made for the C64 screen mapping where the graphics screens are divided into 40 x 25 character cells.


I think the C64 graphics screen can be located at any one of FOUR locations in Assembly Language, so I think first of all I need to decide where to locate it. After this, I must choose a pixel where I want the line to start. This start point shouldn‘t be at the top left pixel of a character cell, otherwise a line could be simulated just by printing backslash characters to the screen. Perhaps I could find out whereabouts this point is on the screen, meaning in which character cell by dividing it, but I don‘t think there are any 6502 Assembly Language instructions which do division. This was mentioned once by TMR of the rival blog https://c64crapdebunk.wordpress.com . All there seems to be are the instructions LSR meaning Logical Shift Right, and ROR, meaning Rotate Right, which are both ways of dividing by 2 each time they‘re carried out. This means an easier way of doing it is for me to choose whereabouts in a character cell I start. This could be 4 pixels across the 8 pixel wide cell. This means that after plotting 5 pixels, the line would definitely enter another character cell. As each row of pixels is a bit pattern, this means transferring the sequence of bytes $10, $08, $04, $02, and $01 into the relevant bytes of screen RAM. Following this, the sequence $80, $40, $20, $10, $08, $04, $02, and $01 would be placed into the next character cell, wherever that was. It could be the cell to the right, or diagonally right and down.


Don‘t forget that Commodore‘s own manuals were crap! It took lots of third parties, often from Germany, like the author of this book, to unveil the secrets of the C64!


As for my other learning activities, I‘ve been studying Japanese, as well as programming in Python. I have completed 75% of the Michel Thomas Method Japanese Foundation Course, so this proves that learning to speak Japanese is far easier than learning to program the Commodore 64.


That‘s all for now! Look out for another post in this blog very soon, about a different subject. This series of articles about “The Machine Language Book of the Commodore 64“ will continue ASAP though.

Posted August 25, 2017 by C64hater in Uncategorized

WHERE HAVE I BEEN?   Leave a comment


Debunking “Learning by the book – part 3”


Theresa May kept me busy part of the time


I thought I should post this as some kind of reply to the latest “C64 Crap Debunk” post by TMR on “C64 Crap Debunk” which you can find by clicking on https://c64crapdebunk.wordpress.com/2017/06/18/learning-by-the-book-part-3/


TMR starts off by wondering where I’ve been since February, in the light of “important events” since then. These were the triggering on March 29, 2017 of Article 50 of The Lisbon Treaty to start the suicidal process of the UK leaving the EU by British Prime Minister Theresa May, AND the snap British General Election of June 8, 2017, a process also started by Theresa May, although the final decision on whether or not to hold it had to be taken by Parliament.


This blog isn’t actually about current events, although I do sometimes mention them to make my posts more interesting. What I’ve been doing in connection with these events is as follows…


1. I’ve been going to meetings, demos, and a march to try and stop Brexit.


2. I was campaigning for one of the smaller parties which wants to stop Brexit by electing candidates, delivering leaflets for the local candidate, attending meetings, and going to the local count representing my party to sample votes which were being counted from certain Constituency Wards, meaning very small local districts. This means counting as many of the votes as possible while they’re being counted by the official counters. The purpose of this is to build a picture of which wards our support is strongest in. Before I started counting, I saw a TV exit poll predicting a hung parliament (i.e. no party getting a majority), so I was relieved that this meant a total isolationist permanent one party dictatorship was less likely. After sampling some votes, I mainly watched the actual results coming in on TV, but took the trouble to watch the local results being declared in the venue, and booed as loudly as possible at a re elected Labour MP who had actively supported the Leave campaign.


Since the election, I’ve been watching and reading lots of news, and trying to predict the date of the next General Election. It seems this will now be in about December or January, meaning about six months after the last election. It will probably be caused by defeats for the Conservative minority government, brought on by rebellions by some of its own MPs, and possibly a vote of no confidence. The result will be about the same as in June 2017, unless a Proportional Representation electoral system is introduced before the election. Some people refer to this as “the popular vote”, where for example if one party gets 30% of the votes, they get about 30% of the seats. More parties need to put up lots of candidates for this to make a big difference now. These parties may include Left Unity (who refused to stand against Labour in June 2017), The Women’s Equality Party (WEP), and The Pirate Party. A real possibility is also the formation of a new party with the main policy of staying in the EU, although I think they’d need some other policies as well.


Now back to the Commodore 64. Of course, not all dialects of BASIC apart from Commodore BASIC V2 supported hexadecimal numbers, but Locomotive BASIC on the Amstrad CPC range, as well as MSX BASIC did support them. Even Sinclair BASIC on the Sinclair ZX Spectrum supported binary numbers, but Commodore BASIC V2 and Atari BASIC only supported decimal.


I remember reading lots of Commodore BASIC V2 listings which assigned variables to the locations of the VIC-II and SID chips, then used two digit offsets for the different registers. In spite of this, the impression I got was that there were a lot more memory locations I needed to learn than all the registers of these chips. There was also the weird command sequences working on these registers using the commands AND as well as OR, without any explanation from Commodore about why this was. It was explained in a magazine article I found a few years ago as “bitwise programming”, meaning setting certain bits in the VIC-II and SID chip registers. Not only that, but it seemed to me that there was NO END to the number of locations to PEEK and POKE. I thought the total number of locations to PEEK and POKE may be as many as 65,535 or perhaps it might be 65,535 minus the number of locations occupied by BASIC, which had 38,911 bytes free, meaning a total of 26,624 locations left. There was no indication anywhere in the Commodore manuals how many memory locations I’d have to use, so faced with the nightmare scenario of having to deal with 65,535 or even 26,624 memory locations, I gave up.


Assembly Language makes things much easier, with techniques such as meaningful labels in a pre prepared text file standing for memory locations, as well as those locations in hexadecimal being more memorable, such as $D000 which I posted some time ago could stand for display block, meaning where the VIC-II chip starts.


As for books about Machine Code/Assembly Language which aren’t dedicated to a particular computer, before you can actually do anything with them on a specific computer, first off all you have to read up on your memory map to find the screen memory, a routine to print text on the screen, etc. Without this information, all you can do is carry out calculations and store them somewhere in the RAM, then examine the contents of those locations to see the results, which isn’t very interesting at all.

The artwork of the slum I grew up in was quite rough. It’s still early days of me using Multipaint, so I hope to do some better graphics in that package soon. Another program I’ve heard about is Swanky Paint, which is supposed to be based on the Amiga’s excellent Deluxe Paint, so I plan to try that.


Multisound Synthesizer might have persuaded me to keep my C64, 


I’m now getting close to understanding the process of how other people managed to program the C64. In the near future, I hope to use Assembly Language to program lots of lines being drawn across the screen, then erased and replaced by some other lines, to produce simple animation, as well as to program a three channel polyphonic tune, without being dependent on specific software such as Synthy, or Multisound Synthesizer (my copy wouldn’t load and VicSoft failed to replace it, just sent a refund) and whatever restrictions they placed on how people could use the music they’d composed. That would be a proof of concept, then I may decide to stop writing this blog.


Other ideas of mine include a printed book based on this blog, as well as a graphic novel including my Dad with his “I know best” attitude (IKBA), the offices of “The A-Z of Personal Computers” with staff enjoying presents sent by Commodore in exchange for not mentioning that their BASIC was crap, etc. I may be setting up a crowd funder for these projects. There could even be separate crowd funders. One could be for people who want to see the book or graphic novel published, while the other could be for people who don’t want to see them published, such as the Tramiel family. Revenge is sweet!


“Linux Welt XXL” magazine, some previously forbidden knowledge from Germany


Some amazing news, is that I’ve recently gained access to some “forbidden knowledge” which the people who run newsagents in the UK don’t want me to know about. This lack of knowledge led a lot of people to vote to leave the EU. The forbidden knowledge is supplied by a service based in Sweden available on www.readly.com . I was very surprised to find about 305 Swedish magazines available, because I didn’t think Sweden with its population of just under ten million (plus another approximately 16.5 million people in other Scandinavian countries able to understand Swedish) could support that many magazines. What this means is that people in the UK now have access to the same current magazines and a few back issues as everyone else using this service anywhere else in the World. Countries covered include Germany, Sweden, and France, but not 100% of all magazines from anywhere seem to be available, based on the UK magazines on offer. It doesn’t include many magazines from France, but I found 586 magazines from Germany!! These include “Linux Welt” and “MagPi”. From “Linux Welt”, I’ve read that virus creators AND malware programmers are now targetting Linux, so it’s time to install some virus protection software and back up all my data. Apart from this, I read an article on the up and coming Linux distro Manjaro Linux which made me decide install it. A really important feature it has is that it’s not based on the Debian or Red Hat varieties of Linux, but on Arch Linux instead. This is important because Linux isn’t supposed to be controlled or dominated by any particular group. Unfortunately, in recent years Ubuntu and Mint, which are both Debian based, have been the most popular distros, as well as lots of other Debian or even Ubuntu based distros (e.g. Elementary OS, Zorin, Lite, Kali, KDE Neon, etc, etc) being released. What makes them Debian based is mainly that they use .deb package files and the apt or Aptitude package installer from the command line. The packages and the knowledge from using apt under one Debian based distro can be used with another. Arch Linux itself uses text based commands to install, which was the usual method at the turn of the Century, although distros such as the Red Hat based Mandrake soon started having graphic installers. Manjaro has a user friendly graphical installer. After that, you just have to learn a few different commands from the ones used in apt and be satisfied with a basic Synaptic like package installer called Octopi, without any equivalent to the Software Centre of Ubuntu or Software Manager of Mint. Not only that, but some more good news from the German “MagPi” is that the Raspberry Pi computer looks set to outsell the C64 in the near future, so then I’ll no longer have to listen to C64 fanatics crowing that their crappy computer was the largest selling “home computer” or whatever the term is. Meanwhile, in the latest (August 2017) issue of Linux Format (UK) there’s an article about how to make a custom distro based on Arch Linux. This may sound daunting, but after having read it, I can assure you it’s easier than trying to program the C64!


So that’s what I’ve been doing. In the near future I hope to get down to the depths of the C64 and explain to you how some people managed to program it! Look forward to that.

Posted July 25, 2017 by C64hater in Uncategorized