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[1], 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…
[1] 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.
The second change to the program is right at the start of the actual code at lines 34 to 36 in the source where we find it reading the value from location $01, clearing the lowest two bits and writing that revised value back. This was done because one feature the C128 has which isn’t present on the C64 is double buffering of the colour RAM and as a default the processor is looking at a different chunk of memory to the video system on start up; in order to colour the two balls that our moving sprite is going to collide with, we need to first make sure both chips are looking in the same direction.
Checking the registers
In response to his almost incomprehensible rambling during Oh that would be VERY difficult! – Part 5, the author was recently pointed towards Compute’s Mapping The Commodore 64, a book which exhaustively delves into the C64’s memory and how it’s used. He of course didn’t understand what the book was telling him presumably because he didn’t actually read it and just skimmed through before making some uneducated guesses that would fit with his current world view, so let’s take a quick look at his response to said comment.
This is an almost ridiculously vague question since it doesn’t specify which kind of programs; anybody writing a text adventure in BASIC has to know a grand total of zero memory locations, someone creating a single screen, sprite-based action game in assembly language needs access to some registers and those can be represented as offsets from a handful of base addresses meaning that knowledge of at most half a dozen numbers is required and not all of them are five digits either.
Even if someone were to insist on referring to the video registers directly there are only forty seven in total; the simple action game mentioned above hasn’t got to set sprite expansion or priority registers for example and certainly doesn’t need to be checking the current position of a light gun either so there’s no need to know what all of the registers do.
The author is confusing memory-mapped video, sound and I/O registers with memory as a whole dear reader; the spaces outside the 38,911 bytes allocated to BASIC programs don’t, as he falsely believed, all serve specific purposes that need to be learnt and the vast majority are merely memory that a programmer can assign at will. Yes there are rules and caveats to be learnt about specific ranges of memory – it’s not possible to store graphics data at $1000 to $1fff or $9000 to $9fff for example because the VIC-II sees a shadow of the ROM character set in those areas – but other 8-bits have similar rules and caveats so it’s not something unique to the C64.
The C64’s manual doesn’t exhaustively cover the memory map (the C64 Programmer’s Reference Guide does however, something that shouldn’t come as a surprise to anybody considering the title) but also doesn’t imply that a large swathe of memory locations need to be learnt either; that’s a mistake on the author’s part that a little further reading would have corrected.