Learning by the book – part 3

Debunking The Machine Language Book Of The Commodore 64 – part 3

So the author’s last post was in February and your correspondent was beginning to wonder what had happened to him… article 50 has been triggered, we’ve had a general election and your correspondent has got married in that time and, whilst that third event won’t have made the author’s radar, the lack of coverage for the other two comes as a surprise. It’s presumably a strange coincidence that the author reappears just a few days after your correspondent posts something.

We’re now really getting down to understanding how the Commodore 64 works and how some people managed to program it, in spite of its totally crappy built in Commodore BASIC V2 language, which had no dedicated commands for colour, graphics, or sound, and didn’t support the Hexadecimal numbering system either

The author has forgotten once again that other BASIC dialects didn’t support hexadecimal numbers as well; this isn’t something specific to berate the C64 over since many other dialects including some the author has “championed” also omit this feature.

as well as Commodore’s crappy manuals totally leading people off track by telling them to PEEK and POKE to 5 digit decimal memory locations, instead of having the locations stored in files as hex labelled by EQU directives.

That’ll be the same C64 manual that actually assigns the variable V as 53248 and then POKEs to two digit offsets from that point[1] for its sample programs dear reader; the author is either ignorant of what the C64 manual actually says (which is fairly hard to believe since it’s been debunked previously in a post the author has replied to) or deliberately misleading his readers at this point.

And let’s just pause to reiterate dear reader, the same process of POKEing five digit numbers is required to handle hardware sprites on the Atari 8-bit but that machine’s manual doesn’t tell people to use hexadecimal (because that BASIC dialect doesn’t support it either) and in fact doesn’t actually cover the subject at all!

This year (2017) marks the 35th anniversary of the C64 being released. It also marks the 35th anniversary of me and my Mum running away from the home my Dad had turned into a slum with lots of unfinished DIY jobs and hoarding. Neither of these events is anything to celebrate, especially as my Mum and me ended up having to return to that slum after only about six months.

Only one of these events is really relevant to the stated topic of the author’s blog dear reader. Your correspondent also doesn’t want to comment on the author’s personal situation because the opportunities for cheap jokes are incredibly strong.

The book is about Assembly Language, but not on any specific computer. The Introduction/Preface mentions Commodore, Apple, and Atari computers as being 6502 based and that it applies to all those computers as well as to any other 6502 based computer, so it wouldn’t enable you to write any C64 demos.

Of course it won’t dear reader, a general purpose 6502 assembly language book won’t specifically teach a would-be programmer how to write demos, games or utilities on any of the platforms with a 6502, but saying that rather than targeting the C64 specifically a above would of course go against the author’s childish, bile-laden narrative! A book like the one described sets out to teach the base language before handing off to other works for the platform-specific information.

But it’s worth noting that, once a programmer understands the language, it isn’t particularly hard to pick up the first steps of demo programming such as moving sprites or scrolling messages and, since demos usually aren’t interactive and small ones don’t need to deal with things like I/O, demos are actually easier to program than games or utilities and just as useful as example code.

This book has a chapter called “Extending BASIC”, but actually there are no extended BASIC commands in the book. All it shows you is how to pass parameters to a SYS command.

Just because it lacks the extra programming required to add more commands to the BASIC interpreter that doesn’t mean it somehow stops being an extension dear reader; your correspondent is vaguely aware of quite a few similar examples for other 8-bits which work in a similar way whilst still being classified thus.

Finally, here’s some artwork I did in the C64 lores screen mode. No programming was required at all, I just used some software called Multipaint, which runs on Linux, Windows, and Mac OSX. I didn’t spend all that long working on it. It gives you a rough impression of the slum I grew up in, which was in stark contrast to the semi detached house next door.

The lack of detail and some rather jarring changes in perspective between the house itself and the vehicles parked around it all stand out with this particular piece; granted the author is remembering a childhood memory, but there wasn’t any requirement to draw the picture in the style of a key stage 1 student.

It is telling, however, that this picture is still the most involved graphical work that the author has produced since his blog went live nearly five years ago and significantly more substantial than anything he’s produced with any dialect of BASIC since that time as well?

I found I couldn’t convert the original graphics file from .bin or .ocp (Advanced Art Studio) to GIF, JPG, or even BMP, so in the end I had to take a pic of it with my Android phone.

It is apparently beyond the author’s wit to grab a screenshot with his PC, crop out the surrounding desktop and merely upload that to his blog…

[1] It doesn’t do the same for SID registers however; these are given as specific five digit values but, as has been noted by commenters on the Author’s posts, there aren’t that many values to actually remember.

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