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.
The author’s latest little missive is something of a stretch considering the author’s self-stated topic of “explaining why the Commodore 64’s BASIC V2 was crap and how some people managed to program the C64”; the post being examined here completely ignores the stated aim (although that hardly comes as a surprise) and steps well outside of the author’s self-imposed 1984 to 1985 window at the same time! And, considering how inaccurate his posts are generally, it’s hard to believe that anybody sensible would take notice of his political commentary without at the very least double checking the facts.[1]
Unfortunately, things didn’t go entirely according to plan. Lots of foreign computers were widely sold in the EEC and at one stage Commodore was the largest supplier. Of course, there were also lots of computer manufacturers native to the EEC, including Sinclair, Acorn, Tangerine with their Oric and Microtan computers, Thomson, and Olivetti.
And, because the C64 and other Commodore hardware for the EU was manufactured within the EU, we have to include Commodore on that list as well dear reader, unless we’re holding some kind of pathetic, childish grudge of course.
I remember Ian McNaught-Davis (RIP) on the BBC’s Micro Live TV series presenting some charts which showed how there was a lot of trade protectionism in the USA
It’s probably fun for the author to throw terms like “trade protectionism” around but actually demonstrating it is far more difficult since there are so many factors in play. For example, the American home computer market had a significant head start on the UK so taking a 48K system like the Sinclair Spectrum over as the Timex Sinclair 2068in 1983 when companies like Apple and Atari had been doing the same general kind of computer since the late 1970s and were already moving beyond even the expanded machine’s specifications was, even if we’re being charitable, a questionable idea at best.
Obviously, the EEC should have blocked Commodore from ever setting up a subsidiary inside the EEC, then set up some kind of quality control or non tariff barrier to stop Commodore computers from entering the EEC, but they failed to do either of those things.
No dear reader, obviously they were right not to block Commodore in that way because these rules aren’t made for a single company and the same “logic” would also have applied to the UK arm of American company Timex who manufactured the Spectrum for Sinclair or indeed other companies whose headquarters were outside the ECC like Atari or indeed the MSX consortium.
The EEC could have made up some rules such as that foreign computers sold in the EEC would have to have a minimum spec before getting a permit to be sold. Computers made by companies in the EEC all seemed to have quite advanced versions of BASIC, so Commodore and Sharp (whose MZ80K had NO language on ROM), could have been required to have the same. Unfortunately, they weren’t.
That net would also catch a lot of other hardware on sale which didn’t come with BASIC in ROM or didn’t match the author’s requirements; remember dear reader that, even if we ignore all of the non-consumer systems such as mainframes or minicomputers, a ruling such as this would also have outlawed sales of the Jupiter Ace, earlier models of the Atari 8-bit series (where BASIC was on cartridge), blocked the Atari ST and Commodore Amiga… some of which are machines the author has previously championed for one reason or another!
And companies are endlessly resourceful when it comes to finding work-arounds for these rules anyway, look at Amstrad’s Spanish distributor Indescomp who released the “72K” CPC472 simply to get around tariffs aplied to systems not meeting certain criteria which had 64K or less; that extra 8K of RAM was a single chip that wasn’t electrically connected to the computer and therefore useless!
In Sweden there was a quite well thought out computer called the ABC80 https://en.wikipedia.org/wiki/ABC_80 , which came out in 1978. This was based round the Z80 CPU and had its own type of BASIC, which was self compiling, so ran much faster than other dialects of BASIC, at a similar speed to Assembly Language/Machine Code.
Natively compiled BASIC (or, as the linked Wikipedia article describes it in the case of the ABC80, semi-compiling) will be faster than the original, fully interpreted BASIC program but simply can’t be expected to produce machine code execution speeds. It’s also worth remembering that compilation has memory overheads, reducing the available memory for programs as well.
Unfortunately, this computer wasn’t very successful outside Sweden, which was probably due to Sweden only being part of EFTA instead of the EEC.
There is no “probably” here and the author is merely guessing once more. But since we’re on the subject of the ABC80, here’s video of a recent demo called Hires Invasion created by members of Genesis Project which uses precise timing to create high resolution graphics on a machine not equipped for them:
(Genesis Project are primarily a C64 group dating back to the 1980s, hence the link above to their profile at the C64 Scene Database.)
After this, there might actually be a lot of manufacturing in Britain by cottage industries, making copies of foreign computers because most people wouldn’t be able to afford the real thing, the same as happened in the USSR, where there were lots of Sinclair Spectrum clones. Of course, no other countries would buy these goods.
This merely demonstrates a lack of understanding as regards what goes into a modern computer, dear reader; home computer development and manufacture wasn’t a small scale, cottage-style industry in the 1980s and now things are in a completely and utterly different league.
Of course, I advise everyone against subscribing to Sky TV, or to unsubscribe if they already do, because it’s owned by Rupert Murdoch, who brainwashed lots of people in the UK into voting Leave, because “When I go to Downing Street they do as I say. When I go to Brussels they usually take no notice”.
Your correspondent wouldn’t head anywhere near as far down the tinfoil-hat-wearing path as the author does by suggesting that the media broadcast by Murdoch-owned companies “may contain brainwashing and even subliminal messages”[2] (because everything is broadcast digitally and conclusive proof of such shenanigans couldn’t remain concealed for any extended period) but, generally speaking at least, your correspondent actually agrees that Murdoch’s influence on the United Kingdom isn’t a positive one.
Just imagine what a difference it would have made! If the Commodore 64 had been banned in the EEC.
We can easily imagine some of the effects dear reader; Commodore employed a huge number of people in those territories who would otherwise have not been in work and their computers were the starting point for an equally large percentage of the home grown game development and other IT-related industries throughout Europe. Taking them and other US influences (as we’ve previously noted, the author’s suggestion of an ECC “rule” to remove Commodore would also have impacted on Atari, Sinclair, the MSX consortium and others) out of the economy without anything else to fill those voids would have been a complete and utter disaster.
[1] Your correspondent may also be offering a personal commentary on socio-political matters, but doesn’t expect to be taken seriously or avoid being fact checked where appropriate, even in the current “post truth” environment.
[2] The author rather subversively suggests using illegal means to watch the Fox productions he feels may contain subliminal messages but, if that were actually true, obtaining said media outside of Fox’s control wouldn’t remove said subliminals so they’d still be a danger to the viewer!
Since there’s been some activity from the author and “Old C64 etc. Programmer” in the comments for a September 2015 post; this exchange has quite the word count, so for brevity we’ll start with the author’s first ejaculation where he says:
You point out that the SID sound chip has 29 registers and the VIC-II has 47 registers. That’s a total of 76 registers.
This was written in response to “Old C64 etc. Programmer” commenting that:
Of those 29 registers three blocks of 7 registers had same function but just for different voices of the SID chip so all one had to remember was 7 registers and continuous block they were in memory. Rest had volume, filter etc.
In other words the author was given a simple way to remember twenty one of those SID registers but ignored that part of the post completely when replying! Presumably the same thing happened when the author was reading the C64 documentation as well because, as “Old C64 etc. Programmer” would later point out, the same applies to a large chunk of those forty seven VIC-II registers with the first seventeen dealing with sprite X and Y positions, nine more for sprite colours and five controlling border/screen colours. And then there’s the way that sample programs in the C64 manual set a variable to the base address of the VIC-II and use easy to remember two digit offsets, something else the author has apparently been ignoring.
Since the Atari ST is mentioned in passing, the author goes off topic and outside his self-imposed 1984 to 1985 window whilst commenting that…
I recently saw a video by Dan Wood of Kooky Tech which revealed that there was actually a version or distro of UNIX specially written for the Atari ST, but then Jack Tramiel was so tight fisted that he refused to pay the price for it, so that was why it came with CP/M 68K rebranded as TOS with the GEM Desktop.
According to Landon Dyer – an Atari employee who was involved with the software side of the Atari ST’s creation – the Tramiels actually negotiated an exceptional per seat price for an AT&T flavour of UNIX and wanted the Atari ST to run it; the reason it wasn’t used is technical[1] rather than financial, so nothing to do with Jack Tramiel. It’s also worth reading Dyer’s twoposts from about the Atari ST’s development dear reader, because the author’s claim that the Atari ST shipped with “CP/M 68K rebranded as TOS with the GEM Desktop” is debunked by the second where the move from CP/M to GEMDOS is documented; since the latter was a work in progress, it can’t be described as “a recycled CP/M”.
This is because the PEEK and POKE commands aren’t limited to those 76 locations. There are even one or two books dedicated to PEEK and POKE on the C64. One of these is called “PEEKs & POKEs For The Commodore 64” by HJ Liesert published by Data Becker in 1984, but the English language edition by Abacus not until January 1985. […] This book is 197 pages up until the Index, so it’s no good pretending that a page or two listing some memory locations would be enough.
The book in question is indeed 197 pages to the index but isn’t merely a list of locations to PEEK or POKE as the author is falsely implying here; merely skim reading the index demonstrates this dear reader since there’s a whole chapter dedicated to machine code, hexadecimal and binary arithmetic, and we’ll have to conclude that the author failed to even look past the cover.
And whilst the claim that PEEK and POKE commands aren’t limited to the seventy six video and audio registers on the C64 is true, it’s also the case for other 8-bits and anybody who has tried to use the hardware sprites from BASIC on both the C64 and an Atari 8-bit should have noticed that the latter is more involved and requires more POKE commands overall; moving a twenty one pixel high, three colour sprite-based object vertically takes 84 POKEs compared to one on the C64.
Now we return to “Old C64 etc. Programmer”, whose most recent post at the time of writing poses an interesting question to the author:
Mind telling how you had to set things as Amstrads sounds for? I recall it had Sound command that took metric fuckton of parameters. Why you feel it was different to separate them just after SOUND command with comma, instead of just poking them?
Your correspondent hadn’t previously looked at the BASIC SOUND command on the Amstrad CPC, but after a little research over at the CPC Wiki, the parameters for the aforementioned are:
So that’s seven values with some of the numbers used being four or five digits long. The duration can be anything from 0 to 32,767 whilst the frequency is between 0 and 4095[2] and the channel value is selected via binary with bits one, two and four referring to the three channels. These parameters, their ranges and how they interact with each other are no easier to commit to memory than the C64 registers.
[1] The 68000 CPU used by the Atari ST doesn’t have memory management and any attempt to port UNIX would have ended up with a slow and particularly unstable operating system. The cost of adding an MMU to the design would have cranked the Atari ST’s price up to unrealistic levels since even the more affluent Apple Macintosh didn’t ship with one as standard at that time.
[2] The author has previously complained at great length about how he hatesmathematics but calculating the note frequencies will require, for the first time at least, some number crunching. Have a look again at the CPC Wiki page dear reader, in particular the part about calculating the Period.
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.
The comments return
Since there’s been some activity from the author and “Old C64 etc. Programmer” in the comments for a September 2015 post; this exchange has quite the word count, so for brevity we’ll start with the author’s first ejaculation where he says:
This was written in response to “Old C64 etc. Programmer” commenting that:
In other words the author was given a simple way to remember twenty one of those SID registers but ignored that part of the post completely when replying! Presumably the same thing happened when the author was reading the C64 documentation as well because, as “Old C64 etc. Programmer” would later point out, the same applies to a large chunk of those forty seven VIC-II registers with the first seventeen dealing with sprite X and Y positions, nine more for sprite colours and five controlling border/screen colours. And then there’s the way that sample programs in the C64 manual set a variable to the base address of the VIC-II and use easy to remember two digit offsets, something else the author has apparently been ignoring.
Since the Atari ST is mentioned in passing, the author goes off topic and outside his self-imposed 1984 to 1985 window whilst commenting that…
According to Landon Dyer – an Atari employee who was involved with the software side of the Atari ST’s creation – the Tramiels actually negotiated an exceptional per seat price for an AT&T flavour of UNIX and wanted the Atari ST to run it; the reason it wasn’t used is technical[1] rather than financial, so nothing to do with Jack Tramiel. It’s also worth reading Dyer’s two posts from about the Atari ST’s development dear reader, because the author’s claim that the Atari ST shipped with “CP/M 68K rebranded as TOS with the GEM Desktop” is debunked by the second where the move from CP/M to GEMDOS is documented; since the latter was a work in progress, it can’t be described as “a recycled CP/M”.
The book in question is indeed 197 pages to the index but isn’t merely a list of locations to PEEK or POKE as the author is falsely implying here; merely skim reading the index demonstrates this dear reader since there’s a whole chapter dedicated to machine code, hexadecimal and binary arithmetic, and we’ll have to conclude that the author failed to even look past the cover.
And whilst the claim that PEEK and POKE commands aren’t limited to the seventy six video and audio registers on the C64 is true, it’s also the case for other 8-bits and anybody who has tried to use the hardware sprites from BASIC on both the C64 and an Atari 8-bit should have noticed that the latter is more involved and requires more POKE commands overall; moving a twenty one pixel high, three colour sprite-based object vertically takes 84 POKEs compared to one on the C64.
Now we return to “Old C64 etc. Programmer”, whose most recent post at the time of writing poses an interesting question to the author:
Your correspondent hadn’t previously looked at the BASIC SOUND command on the Amstrad CPC, but after a little research over at the CPC Wiki, the parameters for the aforementioned are:
SOUND Channel, Period, Duration, Volume, Volume-Envelope, Tone-Envelope, Noise
So that’s seven values with some of the numbers used being four or five digits long. The duration can be anything from 0 to 32,767 whilst the frequency is between 0 and 4095[2] and the channel value is selected via binary with bits one, two and four referring to the three channels. These parameters, their ranges and how they interact with each other are no easier to commit to memory than the C64 registers.
[1] The 68000 CPU used by the Atari ST doesn’t have memory management and any attempt to port UNIX would have ended up with a slow and particularly unstable operating system. The cost of adding an MMU to the design would have cranked the Atari ST’s price up to unrealistic levels since even the more affluent Apple Macintosh didn’t ship with one as standard at that time.
[2] The author has previously complained at great length about how he hates mathematics but calculating the note frequencies will require, for the first time at least, some number crunching. Have a look again at the CPC Wiki page dear reader, in particular the part about calculating the Period.