Debunking The Machine Language Book of the Commodore 64 – part 4
I‘m going to try and attempt to explain and demonstrate the very daunting tasks of drawing lines (the whole basis of graphics)…
Your correspondent has, in over thirty years of working with 8- and indeed 16-bit home computers, drawn game and demo graphics for all of the Commodore 8-bits including the VDC display of the C128, the Atari 8-bit, Amstrad CPC, Sinclair Spectrum, BBC Micro, Apple II and a raft of other computers and consoles without using either the BASIC commands or an assembly language equivalent for line drawing to bitmap and, despite knowing a lot of 8-bit programmers and artists, has never spoken to one who claimed that line drawing was “the whole basis of graphics” on their chosen platform.
Even programs such as graphical text adventures where the user can watch the display being built from a series of lines which are then filled in are created either with bespoke solutions by the programmer which allow artists to create the images or using pre-developed tools like the Graphic Adventure Creator or The Illustrator (which is the graphical extension of The Quill) where each image is stored as series of commands.
If drawing lines really was, as claimed by the author, “the whole basis of graphics” and the C64 lacks the BASIC commands to do that, how exactly does the author explain the truly vast quantities of C64 graphics? Your correspondent will leave the reader to mull that point over and we’ll move on to find out which other task the author feels is only “very daunting” on the C64 but not other platforms shall we?
…and playing polyphonic music on the C64, which is child‘s play on other contempory computers, such as the Sinclair ZX Spectrum (drawing lines, but only playing monophonic music)
In other words only one of the two tasks is “child’s play” in this case because polyphonic music on the Spectrum’s beeper requires assembly language and precise timing, which is significantly more daunting than doing the same task with the C64 from either BASIC or assembly language.
Acorn Electron (one channel sound only)
Again dear reader, only one of the two functions that are supposedly “childs play” can’t be done from BASIC and needs daunting, complex assembly language whilst the C64 in BASIC or assembly language would once more be easier. The same is true of the Apple II, some earlier models lack a BASIC command to draw lines and only have a beeper for sound unless an expansion card such as the Mockingboard; even when that’s installed there’s no BASIC support for it so writing to the card is done via POKE commands or through a music composition tool just like the C64.
Again as an aside, if creating music is so much easier on other platforms there wouldn’t be any demand for the huge number of music composition tools including the one that the author himself used when composing on the Yamaha CX5M.
We‘ll need to decide which 6502 opcodes to use in our line drawing programs. It‘s fairly obvious that they‘ll include LDA #number, LDA address, and STA address, as well as loops including the use of LDX #number, and LDA address,X but not clear what else.
Tying to tell other people how easy or otherwise a programming task is without actually understanding the programming language is utterly futile. And programmers don’t make the decision in advance about which instructions they use in the same way that writers don’t pick specific words from a dictionary before drafting a sentence, they instead have their entire vocabulary available.
It turns out that [the Bresenham line drawing algorithm] was developed as long ago as 1962, on an amazingly advanced for the time IBM computer called the IBM 1401, connected to a Calcomp plotter. I don‘t know if the computer could display graphics on a screen, but it could plot them on the Calcomp plotter.
So the author claims that the IBM 1401 was “amazingly advanced” but apparently hasn’t even done enough research to know what the machine potentially has in the way of hardware; this makes any comments the author makes untrustworthy.
Unfortunately, Bresenham‘s algorithm is a complicated algebraical formula. This means I can‘t understand it because I‘m useless at maths, so I‘ll have to design my own alrorithm, based on calculations as simple as possible, as well as tailor made for the C64 screen mapping where the graphics screens are divided into 40 x 25 character cells.
No dear reader, the sensible way to program this would be to develop an algorithm which works with X and Y co-ordinates and then translate the values it generates for the C64’s screen. This is how all the existing line drawing algorithms work on the various 8-bit systems so the author is trying to reinvent the wheel without even knowing if making it a square would be problematic.
I think the C64 graphics screen can be located at any one of FOUR locations in Assembly Language, so I think first of all I need to decide where to locate it.
It can be at six; those locations are $2000, $4000, $6000, $A000, $C000 and $E000 or if only the upper half of the screen needs to be bitmap (which is quite common for things like text adventures with graphics) it can be at $8000 as well. Using $E000 with the colour memory at $CC00 means the bitmap won’t take memory away from BASIC, but the ROMs will need to be disabled whilst writing to that memory which isn’t a problem since the routine is going to be in assembly language.
Perhaps I could find out whereabouts this point is on the screen, meaning in which character cell by dividing it, but I don‘t think there are any 6502 Assembly Language instructions which do division. […] All there seems to be are the instructions LSR meaning Logical Shift Right, and ROR, meaning Rotate Right, which are both ways of dividing by 2 each time they‘re carried out.
So after saying that he didn’t “think there are any 6502 Assembly Language instructions which do division” the author immediately goes on to recall your correspondent talking about LSR and ROR which are assembly language instructions which can divide by two. The author isn’t even trying it seems because he’s quite literally debunking his own claims before the end of the paragraph they’re in!
Don‘t forget that Commodore‘s own manuals were crap! It took lots of third parties, often from Germany, like the author of this book, to unveil the secrets of the C64!
Don’t forget that Commodore’s manuals weren’t trying to teach this very specific task that, as your correspondent has pointed out previously, isn’t actually essential to graphics creation despite the author’s claims.
As for my other learning activities, I‘ve been studying Japanese, as well as programming in Python.
These are of course irrelevant to the author’s stated topic of “explaining why the Commodore 64’s BASIC V2 was crap and how some people managed to program the C64” and your correspondent is actually getting tired of having to point that out almost endlessly but will continue to do so. This might actually be a form of masochism on your correspondent’s part, but after all these years it’s difficult to tell…
I have completed 75% of the Michel Thomas Method Japanese Foundation Course, so this proves that learning to speak Japanese is far easier than learning to program the Commodore 64.
The author still stupidly believes that his personal experience overrides that of everybody else; this is another example of the “I know best” attitude that annoyed the author when his father exhibited it, making the author a hypocrite for yet another time. If a single personal experience made any major difference to this discussion then your correspondent could simply point out that he failied GCSE French whilst successfully learning 6502 assembly language for the C64 because that would completely negate the author’s “argument”.
 This process is documented in the Steven Levy book Hackers which describes the process used by Ken and Roberta Williams whilst developing one of the first graphical adventures called Mystery House. Essentially, Ken rewrote the software that came with a graphics tablet so that it could store what Roberta was drawing as a series of commands.
 No dear reader, your correspondent doesn’t have anywhere near the self image required to believe his experience to be of such ground-shaking importance, he instead leaves such arrogant, egotistical and false beliefs to the author.