Not rocket science – part 6

Debunking Oh that would be very difficult – part 6

Goodness dear reader, on the same day a newly-minted C64 programmer puts out his first intro as an official part of the C64CD team the author returns from the digital wilderness of his comments with a post about his C64 to C128 BASIC program conversion… but sadly, the news he brings isn’t good.

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!

And yet that “crappy C64 BASIC V2 listing” actually works as intended whilst none of the author’s various attempts to convert it into the “much improved” dialect of BASIC used on the C128 which have been going on since March do not work. Having nearly twice as many commands in BASIC certainly doesn’t seem to have helped the author with his endeavour, does it dear reader? Your correspondent converted the listing to assembly language for the C64 and later C128 without issue and in a tiny fraction of the time!

We also need to remember once more that the author previously made the rather bold claim that converting the same C64 BASIC listing to platforms without hardware sprites apparently “presents no problems” especially in the light of his fruitless flailing around on a machine that actually shares the C64’s sprite hardware.

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

How is the command meant to work without handing control to a specific part of the author’s program when a collision occurs, dear reader…?

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!

Along with sounding like a bad workman blaming his tools, this conclusion is both interesting and somewhat contradictory dear reader;  previously the author has stated that he didn’t think that “Commodore BASIC V7 require any POKE commands at all to use their sprites” and now he’s advocating the use of assembly language routines instead!

The author reached his conclusion by assuming that, simply because he personally couldn’t make something work, it wasn’t possible to do; this is just another example of his “I know best” attitude which was inherited from his father, who the author has recently declared was “certainly a prick”.[1]

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.

This is a childlike and quite frankly ridiculous attempt to lay the blame for what the author perceives to be shortcomings in the C128’s BASIC at the door of someone who was no longer at the company. Businesses change when the people running them leave, their influence goes with them and the people who remain have their own ideas about how things should be done.

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?

The solution is simple enough dear reader, put the C128 into C64 mode with a GO64 command and simply run the original BASIC listing since that actually works! Or failing that, why not use one of your correspondent’s assembly language ports for either mode because they will also work too! In fact the only thing that hasn’t worked was the author’s effort, saying quite a bit about his “abilities” as a programmer.

But now that failed attempt has been put aside, perhaps we can look forward to him spending half a year struggling and ultimately failing to convert the original C64 BASIC program to a platform without sprites since he feels that “presents no problems” – the Dragon 32/64 seem to be on his radar at the time of writing for example – or even targeting the Atari 8-bit since that does have hardware sprites but, just like the C64, lacks BASIC support for them?

[1] The entire response is worth reading for the comedy of the author desperately grasping the wrong end of the stick and trying to run with with it.

This entry was posted in Debunking and tagged , , , , , . Bookmark the permalink.

2 Responses to Not rocket science – part 6

  1. gerliczer says:

    “And yet that “crappy C64 BASIC V2 listing” actually works as intended whilst none of the author’s various attempts to convert it into the “much improved” dialect of BASIC used on the C128 which have been going on since March do not work.”
    That sentence somehow feels wrong to me.

    • TMR64 says:

      I believe it’s okay grammatically – I’m not well and haven’t been for over a week so mileage may vary – but it does labour the point more than necessary, at least in context.

Comments are closed.