DEBUNKING “NOT ROCKET SCIENCE – Part 5“

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!