OH THAT WOULD BE VERY DIFFICULT! – PART 6   6 comments

OH THAT WOULD BE VERY DIFFICULT! – PART 6


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

6 responses to “OH THAT WOULD BE VERY DIFFICULT! – PART 6

Subscribe to comments with RSS.

  1. You could set up a loop and use the ‘bump’ command to check sprite collision status:

    https://www.commodore.ca/manuals/128_system_guide/sect-18.htm#18.4

    When a collision occurs, you could then change the direction of the sprite(s) you wish to change.

  2. Hello, I read you at http://www.commodore64crap.wordpress.com/
    You wanted to improve the basic C64. I have the same ideas and I am moving towards that, I know it has been a long time since that comment and I need to get your full page, but I give you some progress.
    We know that there are many improvements for that basic, and buecanco I found this very good IDE C64Studio made by georg Rottensteiner, with which I am collaborating to remove some bugs. And I’m talking to him because I wanted to make my own IDE myself, although later I met the Visual Code editor that may help.
    The issue is that I have always wanted to improve the Mal basic speed of all the computers of the 80s. I am an expert in Color computer and also suffers from basic without integers.
    So I thought to make a new basic for them fully compatible with the legal and extensions of each equipment, plus many commands that really facilitate everything, more on PC but being able to execute the result on the original equipment, with a code compiled in essembler but also modifiable in assemble.

    In summary, a powerful Basic to program games, combertible (compilable) in Assembler expression by expression, high speed and with the possibility of improvements in assembler, if you like and understand something of what I told you, contact me and we will discuss. Luis Fernandez

  3. The C64 Studio is described on its own website at https://www.georg-rottensteiner.de/de/index.html This provides a full development system that runs on a completely different computer, meaning a Microsoft Windows based PC. It includes an Assembler and Disassembler, a character editor, a graphics screen editor and even more!! This is basically what I call cheating! People using this are creating programs and screens on a far more advanced computer with specifications unheard of while the C64 was in production. I think that that the Tandy CoCo computer is far superior to the Commodore 64 when it comes to programming. Its built in BASIC is Microsoft 16K BASIC from at least 1982, so that makes programming it far easier. Some recent thoughts of mine are that the GW BASIC (or Microsoft Extended BASIC) for the C64 which I mentioned on this blog https://commodore64crap.wordpress.com/2014/07/16/microsoft-extended-basic-for-c64-part-2/ is roughly what’s needed, but I think it needs to be extended. I’m not sure how to modify it. I also think the GW BASIC source code recently released by Microsoft, saying it was “translated” from another system propvides some insights.

  4. Quick question. Could you provide a listing that you’re basing this coding exercise on? I’d like to see if I can help.

  5. Haven’t heard much from you in a while … you doing okay?

    • I’m still alive, but that’s all I can say. My life and my plans have been ruined by the COVID-19 restrictions. I plan to make some posts soon about flowcharting.

Leave a comment