Release Notes – WannaClone (Atari 8-bit)

Goodness dear reader, it’s been a very long time since the last C64CD demo release… hang on, haven’t we done this one before?! Well yes and no, because the Atari Age forum thread which inspired WannaClone for the C64 is the gift that keeps on giving, so now there’s an Atari 8-bit port as well! The music is brand new and supplied by Miker, conversion of the C64 version’s graphics was handled by José Pereira and your correspondent and a joke about the malware turning the user’s POKEY into a SID chip if they didn’t pay up was “borrowed” from Zapac in the forum thread.

It’s worth noting that the Atari 8-bit’s processor is doing quite a lot of work during the picture, relying on a couple of cycle-accurate loops that change several colour registers per scanline, one of which is written to twice during each pass. This is more advanced programming would usually employ for a C64CD release, but your correspondent feels that the overall effect is worth it. The part of the code handling the decoding of text is identical to the C64 although the “magic number” used in the process has been changed from %6A to $A8 since the latter seemed appropriate.

Sadly 2600problems – the forum poster who inspired both the C64 version and this one by asking people to elaborate on encryption within the previously mentioned discussion thread – hasn’t acknowledged the existence of the C64 demo and probably won’t pay any attention to this Atari 8-bit conversion either.

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.

Release Notes – WannaClone

Goodness dear reader, it’s been a very long time since the last C64CD demo release so here’s a new one for the C64 called WannaClone. There are a couple of inspirations for this release, with the primary one being a thread at the Atari Age forums called “screwing with pirates” where the initial post from user 2600problems features a BASIC-driven password protection for the C64 which… well, let’s charitably say it wouldn’t work, in part because the password can be found or overridden simply by looking through the program.

But the subject of encryption came up in said discussion and, since your correspondent has experimented with this a little in the past, that seemed like a good enough excuse to write a little practical example. The text for the scrolling message in WannaClone has actually been encrypted in a reasonably loose sense of the term; each character is exclusive ORed with a byte from the first 256 in the music routine before a “seed” value is added to it, neatly turning plain text into guacamole when looked at in memory. The result from each pass is then used as the seed value for the next one, so changing the encrypted text itself, the initial seed value or that block of the music being used will completely garble things. The text is stored as raw data in the binary directory for those wanting to examine it further, there might even be something extra in there…

This exercise shouldn’t be taken anywhere near seriously of course because it wouldn’t require ridiculous amounts of work to circumvent the encryption (especially since the source code containing the “magic number” $6A which is used to set things rolling is readily available[1]) but the principle could at least be expanded to perhaps using the characters of a password as initial seed values instead.

We haven’t even approached the question of why such a “protection” would actually be required on 8- or 16-bit software and, although your correspondent asked within the thread, he didn’t receive an answer so will instead leave it to the reader to ponder. This demo does at least serve as a questionable excuse to do the WannaCrypt joke again and a couple of small but potentially useful Windows-based tools for processing data were written so that’s… something?

[1] The number $6A wasn’t chosen at random, it’s 106 in decimal and your correspondent is a fan of Jeff Minter’s 8-bit games; shooting a camel in some of those titles would award the player with 106 points, a reference to an American radio station.