The book in question


Now for another instalment about this amazing book, which wasn’t published or promoted by Commodore at all, but I think copies should have been given away with every Commodore 64 sold. At the very least, I think Commodore should have included a business reply card in each C64 box saying something like “Are you serious about programming your C64? If so, then you need this book! Please register your C64 with Commodore within 28 days of purchase to get a copy of this book at the discounted price of… Meanwhile we hope you enjoy using the built in Commodore BASIC V2, which is designed to produce text based applications only”. This card could also have mentioned some other amazing books by Data Becker/Abacus and by Compute! , where the exclamation mark is actually part of the name.

As I pointed out in the last post of this series, I couldn’t get the LEA Assembler I typed in to work, and couldn’t find a working copy of it for download either, so this means that I’d need to alter the Assembler Directives and syntax slightly to get any of the code in this book to Assemble and run on another Assembler.

The Merlin 64 Assembler seems to be a popular Assembler for the C64. I managed to download a PDF of this, which says that it was published in 1984, so that means I could have bought a copy while I owned my Commodore 64. The Table of Contents lists the Pseudo Opcodes or Directives as EQU (=), ORG, PUT, VAR, SAV, DSK, END, DUM, and DEND. It follows these up with lists of commands for what it calls formatting, strings, data and allocation. Some of these may be necessary, such as TXT, ASC, and .DFB, so I’ll look at the Directives and those other three commands first, then may come back to the several other commands listed in the manual later. The Directives are used as follows. Label EQU expression , or label = expression. Another one is ORG expression , which the manual explains is $8000 by default. This is much lower than the commonly used $C000 which LEA seems to use by default. PUT filename allows the user to place a filename in RAM for assembly at the location of this opcode. DSK filenme will assemble directly to disk. END denotes the end of your source file. TXT “ABC” will Assemble ABC as Commodore PETSCII, but ASC “ABC” will Assemble ABC into standard ASCII. It seems that DFB can be followed by any one byte long numbers or text, or even a list of these separated by commas.

The Machine Language Book of The Commodore 64 doesn’t list any Directives in its Table of Contents, so I’ll have to go through it to find out what they are. I’ve already mentioned in the previous post in this series that = is EQU and .EN is END , though. On page 94 it starts by telling us to define a label as some optional text in the first column. The example given is called simply LOOP , which isn’t followed by anything in that column. After this, we can use BNE LOOP to get back there. Labels can have a maximum length of five characters, which is much better than Commodore BASIC V2 limit of two significant characters for variable names. As I mentioned earlier .EN means that your source code ended with the previous line. The Directive ORG , meaning put the code at the following address, doesn’t seem to be needed, because there’s no mention of this or an equivalent in the first few example programs. On page 99, we learn that labels can also be used to stand for addresses in the memory map. In that case they have to be inputted using all three columns in the BASIC V2 editor. An example of this is VIDEO = $400 , which defines the screen memory as beginning at $400 or 1024 decimal. After this, we’re introduced to the use of *= instead of ORG. The Directive *= is placed in the second column, followed by the address $C000 in the third column. The address $C000 or 49152 decimal seems to be the most commonly used location for storing Machine Language programs on the C64, at least while the BASIC V2 interpreter is still turned on. The book explains that 4K of space is available at that location. It seems there’s a lot you can do with 4K on an 8 bit computer. On pages 100-101, we’re introduced to the Directive .BY , where it’s explained that this is used to store data or text which follows it. I think this would be .DFB in Merlin 64, DB, DEFB, or BYTE or some other Assemblers I’ve read about some time ago, but I can’t remember which ones. I think this knowledge may now be enough to convert some listings from this book for other Assemblers! Examples of .BY given are .BY 100 , .BY $7F , and .BY CR , which I think stands for carriage return, but there’s no mention of if or where this is defined. It may be that .BY is more complicated than similar directives in other Assemblers, because it can also divide a 16 bit value into two 8 bit values using the operators < and > , but I think we’ll leave that til later. Immediate addressing is carried out by prefixing operands with the # character, while zero page addressing is achieved by prefixing operands with the * character. After this, we’re told we now know enough to start using the LEA Assembler.

I’ve recently found a quite obscure book about 6502 Assembly Language and there’s also Jim Butterfield’s book, but I’ve decided to deal with them in a later post.

Unfortunately, it looks like I can’t afford to buy another C128 or even a C64 at the moment, especially as I still need to buy a frying pan, a saucepan, a sharp knife, a plunger, and go for some more badly needed nights out.

That’s all for now! The next stage is for you to absorb what you’ve read and I plan to try and convert some of the source code listings from this book for the Merlin 64 Assembler. Perhaps you’d like to have a go at this yourself.

Posted May 22, 2016 by C64hater in Uncategorized


Subscribe to comments with RSS.

  1. In the ancient days, when I was learning programming on the C64, getting access to books was really difficult… my first PC was a Pentium 100-S based box, by that time, dial-up Internet was available, and Windows 95 had just come out. However, obviously, the C64 was officially dead by then… and whatever I had learned, I had to basically forget and try to start over.

    Only, I tried to bring some sanity to PC development… being more pragmatic. It would be years later that I would find out that two main processes are at work in the development of complex things: those what want to help you get work done, and those that want to look busy whilst preventing work from being done. The latter form seems to think it is the former, and dominate everything… over time.

    The only respite, potentially, is mobile, console, and other embedded development… which might actually be closer to what we really want, anyhow: to deliver a working product to as many people as possible, in a way that also benefits, rather than hindering.

    I got way off my topic though… it’s cool that you found those books, I’m not familiar with that one, but I did find the magazine articles in Compute! Gazette and the Commodore 64 Programmer’s reference guide helpful. Also C, and C++ became popular partly because of well-written books, as opposed to their intrinsic merits.

    Going forwards, Python 2/3 seems to be a stable, if partial, platform. Well, dual platforms. They solve the problem of how to express an algorithm, but not the full problem of how to develop a full system; embedding Python into a mobile App is possible, in theory, but not easy, few people even seem to try it. I hope to try it later this year.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: