Prepare to operate – part 1

Debunking The Commodore 64 and Operating Systems (Part 1)

Welcome to everyone who has recently been viewing this blog so much!

Your correspondent notes that the author apparently doesn’t understand that the WordPress statistics include spambots, search engine spiders or perhaps content scrapers in with the legitimate views. Your correspondent has also noted several busy periods but wouldn’t automatically assume that meant a significant spike in visitors.

Unfortunately, I‘ve had serious problems working out what to do next in the quest to find out how some people managed to program the Commodore 64…

And we have to start dear reader by asking ourselves what on Earth the diatribe which follows has to do with that stated topic; all of the rather blatantly uneducated discussion of Linux isn’t relevant in the slightest and, as we’ve noted previously, sitting down and putting the time and effort into learning is how people managed to program the C64, just like any other computer.

…as well as being very depressed by the destruction of my home city of London. The city is still there, but has been made virtually uninhabitable to me, as well as its nightlife being decimated. If any of you are thinking of visiting London, don‘t bother!

This has absolutely no relevance to the author’s stated topic either but, if we’re going to offer personal opinions of London, your correspondent worked there for a while in the late 1990s and found it an unfriendly and rather depressing place even then. It’s one of the reasons your correspondent now resides in Yorkshire in fact.

Operating Systems are what makes computers go. There‘s some dispute about whether or not the C64 actually had an Operating System, though. Some books and magazines say it had, while other books and magazines say that an Operating System is something you boot into which isn‘t a language waiting for you to type a program in. As the C64 boots into BASIC with the Ready prompt, on that basis it doesn‘t have an operrating system.

The majority of 8-bit systems go to a BASIC ready prompt in the same way as the C64 and some of these systems have to then boot a DOS from disk whilst others don’t even have an official solution for attaching a disk drive to the computer in the first place. The C64’s DOS might not be particularly user friendly but it does come with disk commands baked into the BASIC interpreter.

And if, as the author claims at the start of that quoted paragraph, “operating systems are what makes  computers go” how do any of these machines actually “go” if dropping to the BASIC ready prompt equates to not having an operating system?

Unlike MS-DOS, the Commodore KERNAL doesn‘t have lots of routines which can be called up. It has a total of 39 routines, as listed on http://sta.c64.org/cbm64krnfunc.html . I don‘t know what routines are contained in the very messy Commodore DOS.

So the author is once more complaining about something he hasn’t properly researched or understood… and let’s pause to note dear reader that any computer running CP/M or MS-DOS was actually loading a third party operating system from disk so comparing it to the C64 without allowing the latter to do the same with something like a DOS wedge is both a false argument and hypocritical. So, although they’re a later example of a DOS wedge, your correspondent found four slightly battered Action Replay 6 cartridges earlier…

…including one modified to extend the freeze and reset buttons for use with a C128D[1].These are also third party programs which boot from an external ROM rather than disk but work in a similar manner, adding commands such as $ to read the directory, @N to format a disk, @V to validate, @S to scratch a file, @C to copy files and @B to duplicate an entire disk either via RAM or from one drive to another. There aren’t drive letters of course because Commodore computers use numbers so commands like @8 or @9 select the relevant drive for the other commands.

For example this is how to format a blank disk for example, @N is the format command (short for “new” as in new disk) whilst C64CD is the disk label and 64 the ID.

Linux operating system is open source, which makes it highly customisable. It comes in lots of different varieties, called “distros” (distributions) meaning that the software included with each distro and how to install new software varies greatly.

This is off topic as noted earlier but okay… your correspondent would argue that Linux is actually too customisable, that the huge range of distros makes it difficult to get into as a beginner or even intermediate user and that said flexibility has more likely harmed rather than helped Linux as a desktop operating system over the years. Even for someone with a bit of computing experience it can be a painful ride, with desktop environments varying significantly and commands from one distro either not working or at least functioning differently on another.

I don‘t think it depends on any ROM, because it can run on PCs, Macs, and Raspberry Pi computers.

When a computer is turned on there’s some kind of ROM-based code in charge initially so yes, Linux does depend on it. In some cases like the Raspberry Pi it merely mounts the SD card’s file system and hands off control, but the average PC BIOS will go much further to the point of specifying which device the operating system is going to boot from and then handing over information about the system including RAM size and available drives.

At the end of the author’s latest missive  your correspondent finds himself wondering what the end game might be with this particular line of “thought”. Presumably he’s trying to build another worthless anti-C64 “argument” where not having an operating system (by some definitions at least) is somehow an issue but that’s easily debunked merely by looking at all of the users and indeed programmers who didn’t find that to be an issue either on the C64 or with other 8-bits which are similarly lacking in that department. There’s apparently more to come so we’ll have to wait and see where this goes next, and hopefully the author will actually be on topic next time… although that would be more than a little surprising if it were to happen.

[1] The Action Replay 6 cartridges are accompanied in the picture by a far more recent Turbo Chameleon and 1541 Ultimate 2 which can both, among many other functions, pretend to be one as well.

Advertisements

Learning by the book – part 4

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[1] 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”.[2]

[1] 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.

[2] 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.

Guess who’s back, back again

Debunking Where have I been?

Theresa May kept me busy part of the time

That, dear reader, is something that should probably be kept between the author and Theresa May.

This blog isn’t actually about current events, although I do sometimes mention them to make my posts more interesting.

The author has presumably failed to process the sarcasm in your correspondent’s post; anything outside of the author’s stated topic is irrelevant because, as he notes, his “blog isn’t actually about current events”. It was very helpful of him to debunk his own post once more.

1. I’ve been going to meetings, demos, and a march to try and stop Brexit.

That certainly seemed to go well dear reader, doesn’t it? [1] Let us skip gently over the remaining political discussion and get back to what the author is meant to be discussing but here’s a picture of Spitting Image by Domark because it’s tangentally about politics and actually related to the C64!

Now back to the Commodore 64. Of course, not all dialects of BASIC apart from Commodore BASIC V2 supported hexadecimal numbers, but Locomotive BASIC on the Amstrad CPC range, as well as MSX BASIC did support them. Even Sinclair BASIC on the Sinclair ZX Spectrum supported binary numbers, but Commodore BASIC V2 and Atari BASIC only supported decimal.

So to recap dear reader, only the minority of BASIC dialects supported hexadecimal but the author only seems to perceive it as an “issue” worth noting with the C64; this is, obviously, hypocritical of him.

And this is hexadecimal we’re talking about as well,  the author has moaned at length about being “useless at maths” but rather magically that doesn’t extend to counting and carrying out calculations in base 16 it seems! Adding, subtracting or multiplying numbers (which is why the author whine that he “understand which one of these things it’s doing or why, because [he is] useless at maths” for what is essentially a simple equation if you pay enough attention to what it’s doing and actually try to understand) doesn’t get any easier just because the calculations take place in hex.

I remember reading lots of Commodore BASIC V2 listings which assigned variables to the locations of the VIC-II and SID chips, then used two digit offsets for the different registers. In spite of this, the impression I got was that there were a lot more memory locations I needed to learn than all the registers of these chips.

Which is a mistake on the author’s part because that isn’t the case. We’ve noted on countless occasions that he fails to do research and this is merely another example; he had no information whatsoever to back the assumptionthat there were more than merely a handful of locations to worry about but made the false assumption and gave up without looking further.

That assignment of variables with two digit offsets simplifies one of the author’s long-term bugbears, that he couldn’t remember five digit numbers – apparently he was aware of this in the 1980s but for some reason chose and continues to choose to ignore his own knowledge whilst complaining about it now, demonstrably trying to mislead his readers by doing so. And since the offsets are two digit numbers there can only be a hundred possible values, the author must have spectacularly failed to notice this when falsely getting the impression ” that there were a lot more memory locations [he] needed to learn”.

 There was also the weird command sequences working on these registers using the commands AND as well as OR, without any explanation from Commodore about why this was. It was explained in a magazine article I found a few years ago as “bitwise programming”, meaning setting certain bits in the VIC-II and SID chip registers.

It’s worth pausing to note dear readers that some BASIC dialects don’t have bitwise commands despite there being situations where they would have been incredibly useful such as reading the joystick on the Atari 8-bit for example, there’s a bespoke BASIC command but it returns a value where bits are set or clear depending on the state of the joystick so having the ability to AND by individual bits significantly reduces the number of condition tests required. And that’s before we remember that Atari BASIC uses POKE commands like the C64 to handle things such as the hardware sprites where bitwise commands would have been useful to deal with expansion registers, playfield priorities, collisions and so forth.

Of course this lack of functionality is overlooked by the author, either because he doesn’t want to poke holes in BASICs that he’s championing over the C64 or due to ignorance.

Assembly Language makes things much easier, with techniques such as meaningful labels in a pre prepared text file standing for memory locations, as well as those locations in hexadecimal being more memorable, such as $D000 which I posted some time ago could stand for display block, meaning where the VIC-II chip starts.

The author has yet to write any substantially sized program for a 6502-based computer so this is supposition rather than fact. Very few native assemblers have an equivalent of “pre prepared text file standing for memory locations” with some assembling directly to RAM rather than via disk. And the vast majority of assemblers both native and cross don’t require hexadecimal at all so C64 programmers who started with BASIC could carry the knowledge of decimal locations or indeed the concept of two digit offsets from a variable over to their assembler. Setting a label like v or perhaps vic to 53248 works in exactly the same manner as assigning it as $d000 for example.

And again dear reader, we’re talking about base 16 here which most people don’t count in naturally so decimal numbers would be easier to deal with at least for beginners.  There is a reasoanble argument for understanding binary since it helps when manipulating video registers on pretty much every platform we’ve discussed rather than just the C64, but only old hands like your correspondent who learnt assembly language via hand assembling and working in a machine code monitor needed to learn hexadecimal.

As for books about Machine Code/Assembly Language which aren’t dedicated to a particular computer, before you can actually do anything with them on a specific computer, first off all you have to read up on your memory map to find the screen memory, a routine to print text on the screen, etc.

And that is where a reference book comes in… like the Commodore 64 Programmer’s Reference Guide for example! This is, after all, what your correspondent has been saying for quite a while.

I’m now getting close to understanding the process of how other people managed to program the C64. In the near future, I hope to use Assembly Language to program lots of lines being drawn across the screen, then erased and replaced by some other lines, to produce simple animation, as well as to program a three channel polyphonic tune, without being dependent on specific software

The author really isn’t “understanding the process of how other people managed to program the C64” dear reader, there isn’t an actual process because different people have different motivations – not everybody has a childlike fixation with drawing lines for no practical purpose like the author does! Your correspondent learnt by setting himself achievable tasks related to the kind of games or demos he wanted to create and working out how to complete them, all that requires in the long term is a little persistence.

Other ideas of mine include a printed book based on this blog, as well as a graphic novel including my Dad with his “I know best” attitude (IKBA), the offices of “The A-Z of Personal Computers” with staff enjoying presents sent by Commodore in exchange for not mentioning that their BASIC was crap, etc. I may be setting up a crowd funder for these projects. There could even be separate crowd funders. One could be for people who want to see the book or graphic novel published, while the other could be for people who don’t want to see them published, such as the Tramiel family. Revenge is sweet!

Whilst publishing his libellous opinions and blatant lies under a pseudonym on his blog offers some degree of protection, it will be very interesting indeed to see how a print-based endeavour fares on that front since they tend to require real names and often contact details. How any of this equates to “revenge” is highly questionable, the Tramiel family will have legal options open to them to consider well before they think about essentially paying anybody off, assuming the author’s belief that anybody really cares about his writings is more than mere narcissism of course.[2]

And whilst nobody really fact checks the content of low traffic WordPress bash blogs (apart from people like your correspondent who do have better things to do with their lives but are often lacking when it comes to the mental fortitude to prioritise such matters) there’s a lot more scrutiny for published works, especially if they’re crowdfunded. The author is potentially going to draw far more attention to his lack of research, false assumptions and downright lies so how something like, for example, a negative review on Amazon will be dealth with should prove interesting; trying to tell a commenter on your blog that they’re wrong because you say so usually doesn’t go down well on its own, but if the feedback is from a paying customer it’s bad public relations.

Another thing your correspondent feels should receive emphasis is the author complaining about his father; since the entire premise of his blog and presumably the graphic novel would be the author knows best, the idea of berating other people for having pretty much the exact same attitude is just another demonstration of hypocrisy.

Not only that, but some more good news from the German “MagPi” is that the Raspberry Pi computer looks set to outsell the C64 in the near future, so then I’ll no longer have to listen to C64 fanatics crowing that their crappy computer was the largest selling “home computer” or whatever the term is.

No dear reader, the C64’s record is for the “highest-selling single computer model of all time” (the important words highlighted for the author’s benefit since he didn’t bother checking for himself) which means that every unit sold was to the same specification. Even if they’d matched the C64’s worldwide sales figures, 8-bit systems like the Sinclair Spectrum or Atari 8-bit line couldn’t hold that record because there’s a raft of different models; the Spectrum came in 16K, 48K and 128K flavours and the Atari 8-bit had even more models available with the original 400 and 800, the XL series, the XE machines and, because it has an optional keyboard, the XEGS.

The Raspberry Pi is in the same way a range of computers with different specifications rather than just one so the sales as a whole therefore don’t count towards the C64’s record because they’re not for a “single computer model”. Again, the author fails to do any actual research before posting and subsequently tries to mislead his readers…

[1] For the author’s benefit, since he struggles to recognise it, this is sarcasm.

[2] Anybody who keeps a blog is a narcissist to some degree, your correspondent included of course, but it’s one thing to believe that anybody would be interested in reading your thoughts and another to labour under the misunderstanding that a lot of people would pay for the same, especially when you’ve had a large amount of your “arguments” thoroughly debunked.