Debunking Debunking “not rocket science – part 5”
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.
The author’s entire blog consists purely of his biased, illogical, factually inaccurate and often desperately pathetic, childlike rants, so claiming that anybody else is “talking crap” is quite frankly farcical. Your correspondent still isn’t a “maths whiz” by any stretch of the imagination, much as the author apparently needs that to be the case.
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.
And, as we’ve noted at length dear reader, other computers that the author has talked about previously also have their issues on that front; where is the BASIC support in the Atari 8-bit series or Texas TI-99/4a for the hardware sprites that both platforms have for example? Come to think of it, where are the Atari BASIC commands for handling those powerful display lists?
Oh that’s right dear reader, despite lacking BASIC support for those features these machines somehow magically don’t count because they’re not the C64.
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.
Pretty much anybody writing 8-bit software now in anything approaching a serious capacity uses cross development tools because they’re convenient; the source code can be posted online for others to learn from, build times are in seconds rather than minutes or in the case of the clunkier tools, hours backups can be automated and there’s no dealing with thirty plus year old magnetic media with the reliability issues that would bring to the table.
But your correspondent and others who have responded to the author have also paid their dues over the years or in some cases decades with native tools and, whilst the author doesn’t share that knowledge or experience, his “I know best” attitude leads him to believe that his uneducated and biased opinion is somehow more valid than everyone else.
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.
Anybody sensible would expect that a machine released after the C64 would in some way improve on it, even if that improvement is less than 4K extra for BASIC in the case of the Amstrad CPC which came out two years after the C64.
All the official Commodore Manuals kept mentioning using BASIC with five digit memory locations.
The C64 manual contains a small program which puts a sprite-based hot air balloon on screen and, despite the author’s claim above, at line 10 of said program is the command V=53248 followed by a comment reading “START OF DISPLAY CHIP” – he might have “forgotten” about that but the author has mentioned typing it in previously so can’t claim ignorance here.
Above is a screenshot of said program running with that line shown on screen (the RUN 10 command skips the PRINT command before it which would have cleared the screen).
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.
Being overly enthusiastic when assigning labels in this way can cause memory issues on larger programs since each reference to said labels will take space away from the actual assembly language – STA 53280 will be significantly more efficiently stored by an assembler with a good tokeniser than STA BORDER for example – so anybody “back in the day” optimising their code to claw back memory would first purge the comments before moving on to those labels.
Whilst we’re here, the author hasn’t described macros very well presumably because he’s never used them; they’re just fragments of frequently used code which might be used multiple times within a program so, whilst a macro may do something BASIC-like such as place text on the screen, how the data is actually passed to that code will be very different.
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!
This is actually documented in the C64 manual straight after the program example with the hot air balloon which the author has previously talked about typing in so it really shouldn’t have been new information to him unless his “I know best” attitude meant that he couldn’t be bothered to read the manual properly. There’s even a link to the relevant part of said tome included within one of the author’s posts linked above, but please click here to visit it directly and scroll down to the top of page 73 where line 11 of that program is explained with a handy diagram showing the bits and their values.
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 […] 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!
It doesn’t matter if he believed that there were “hundreds or even thousands” of registers because there weren’t and the mistake was nothing to do with the C64, it’s manual, Commodore or indeed anyone or anything else and purely down to the author himself. As was literally just pointed out at the start of the above paragraph, there’s no actual need to memorise five digit numbers either so the subsequent whining – along with all of the complaints on previous posts – is therefore debunked by his own words. Again.
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
The amusing term here is “not get much support” dear reader; the Atari 8-bit’s BASIC has exactly the same amount of direct support for the hardware sprites as can be found on the C64 because it’s all handled using POKEs, albeit significantly more POKEs on the Atari for vertical motion. The other difference is that, whilst Commodore’s “extremely crappy” BASIC includes bitwise operations which can be utilised for checking collision registers, the same isn’t true for the Atari so the program and indeed programmer will need to do far more work in order to achieve a similar effect.
And whilst there are examples for using hardware sprites in the C64’s manual, your correspondent recently found the book which shipped alongside his Atari 800XL in 1984 – the author would have received it as well had he made a different purchasing decision back then – and the same isn’t true there. It’s a mere 64 pages long, of which only ten are the English version of the text and there’s absolutely nothing in there to teach a new user BASIC apart from one page with three short sample programs which don’t come with an explanation of what they actually do.
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!
There are a couple of background elements that the moving sprite partially passes over – the collisions wouldn’t register otherwise – and the sprites themselves overlap as well so that will need to be dealt with via some form of masking; both sprites are also moving a pixel each refresh so the author’s software sprite routine is going to have to emulate that along with handling pixel accurate collision detection between those elements. Doing all of that from BASIC is going to be glacially slow.
Soon, I hope to post a conversion of the listing in question into Commodore BASIC V7 for the C128!
If his C128-specific BASIC version of the program actually materialises your correspondent has already ported his assembly language version for that platform whilst composing this post so, although there are no changes to the core program, we can spend a little time examining the small differences within the initialisation code and memory positioning between the two machines for assembly language programming.
Of course, if the author had any courage in his convictions the first platforms he’d be converting the program to are the Atari 8-bit or Texas TI-99/4A since aiming for a machine released after the C64 doesn’t prove much of anything…
 The Atari 8-bit’s BASIC actually has a command for reading the joystick ports but it returns a byte with the bits either set or unset depending on what the hardware is doing; not being able to AND specific bits off for testing from BASIC means that more code is required to handle all of the possible states.