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:

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 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”.

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:

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.

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