First of all, I should say hello and welcome to all the recent new visitors to this blog who have caused what WordPress call a spike in my ratings which they felt the need to send me an email about! I saw that I was getting a lot of visits from Poland, although I didn’t seem to get much attention from there before.
Only someone who has previously allowed spam-flavoured comments onto his blog would blindly believe that any jump in traffic is from real visits rather than spambots or “hackers” (for want of a better word) looking to leverage a recently-announced WordPress vulnerability. A lot of the spam posted this way will be automatically dealt with but the connections made to the blog still crop up in the logs.
Following on from my first article in this series, after a lot of distractions, as well as my MSX2 computer power switch breaking down, then me getting it repaired, my camera phone wearing out or just getting corrupted, here’s the continuation. I took the pics and the video on my new Huawei Ascend Y330 Android 4.3 Jellybean based phone, because I’m on a tight budget, but if I had more money I wouldn’t buy an iPhone.
This really isn’t relevant information dear reader; the author has claimed this series to be about programming but drones on about broken cameras or his personal preference in smartphones instead. We’ll also skip over the pointless waffling about BASIC versions because it is similarly unimportnat to the program the author has spent a ridiculous amount of time not writing or even discussing – it’s nearly nine months between posts.
I should point out to you that due to me not making a flowchart before starting work on the original program, it has now grown into slightly hard to follow “spaghetti code”, which I’ve found is difficult to add anything to.
The flowchart for such a program is simple to the point of being superfluous; the main loop will move the objects, check for a collision, react as needed and then return to the start. If the author can’t follow his own code now he’s really going to struggle later on when working with programs running to thousands of lines.
A better designed, flowcharted program should have a number of separate subroutines, each clearly labelled with a REM statement, then a main game loop would be made up mostly of GOSUB commands, as well as, thanks to the advanced MSX BASIC, interrupt commands such as ON SPRITE, ON STICK, and ON STRIG.
This would be a quite poor way to do things; the main loop would literally be a large block of GOSUBs pointing to line numbers with no real idea of what they’re doing so anybody unfamiliar with the code would either have to remember or fish around the subroutines themselves. A REM on the same line as each GOSUB makes that code more legible, but spraying comments around takes memory away from the BASIC program itself and the parser still has to deal with them at runtime.
The author can’t comment either way about if a flowchart would be helpful of course because he hasn’t made one but, since it would only the program in the most general of principles, a reasonably well documented main loop will be several leagues more useful.
Interrupts are a limited form of multitasking for 8 bit computers, which were never properly explained by Commodore in their official manuals, instead waffling on about totally incomprehensible crap to do with “IRQs” and “raster interrupts”.
This particular “argument” is moronic even by the author’s “standards”, especially since pretty much every other system’s documentation deals with these things in a similar way; when Atari eventually released the documentation for the 8-bit series they wrote about display list and vertical blank interrupts for example (DLIs are similar to raster interrupts, except the trigger is an event in the display list rather than reaching a specific scanline) so the unadulterated hypocrisy of singling out and damning the C64’s documentation for what the author very incorrectly describes as “waffling” is obviously just a desperate scrabbling around in the dark for something to attack the machine over which bore no fruit at all.
I think the best way I can present this program to you at the moment is to show you the several screenshots of program listing, as well as the video taken on my new smartphone and a short explanation of what I was thinking when I wrote it, then leave you to try and work out how this has been achieved, before I give you a detailed explanation in the next part of this series.
Leaving the reader to guess how something works is a poor way of “teaching” them. And, since it’s been several months between instalments the next part of the series might take a while to arrive – that incredibly long wait makes your correspondent feel a lot better about being a few days behind on his self-imposed “schedule”.
This program could be converted into Commodore BASIC V7 on the Commodore 128 without too much difficulty, but I have no idea how to convert it into Commodore BASIC V2 as on the C64.
And this, dear reader, has always been the problem with the author – he doesn’t know how to convert this program to the C64 and is clearly just guessing about how easy a C128 version would be as well but then expects people to take his opinions seriously when discussing the relative pros and cons of various BASIC dialects! It’s like discussing the merits of spoken languages without being sure you even have the pronunciation correct.
Your correspondent would be interested to see how things would pan out if the author were to attempt a conversion of his program over to another platform like the Atari 8-bit or TI-99/4A or even something without hardware sprites such as the Apple II or Spectrum since those BASICs have previously been declared by him as “superior” to the C64 without any experience to back those claims up.
 Going back to a piece of code after nine months is always a struggle, but a small program like the author’s shouldn’t cause the issues he’s apparently having.
 One is IRQ-based, the other is NMI and neither have dedicated commands from the BASIC shipped with the machine that manipulate them.