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   4 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