By Larry Isaacs — originally published in Volume 1 – Issue 1 – June, 1983
“64 Explorer” will be a regular column dealing with topics of interest to Commodore 64 users. Since this is the premiere column, perhaps a little bit about my background is in order (mixed with a few items of historical interest) before we begin our first explorations of the 64’s BASIC language.
Eight Years Ago
I have had an interest in microcomputers since they first became available. At that time (around 1975), I was still in college, so naturally I couldn’t afford one of my own. Instead, I had to be content reading all the literature and magazines I could lay my hands on. In those days, you had to know a lot about how your microcomputer worked in order to use it. Plus, you would typically have to do a lot of your own programming. Back then a microcomputer with as much memory as the 64 would have been quite expensive. And it would have weighed a ton, because at that state of technology it would have required a very large power supply.
It was during this time that I picked up most of my hardware design experience. This experience included designing a bit-slice (i.e., custom) minicomputer and working on some peripheral controllers for DEC minicomputers. Unfortunately, I wasn’t able to pick up much experience on microcomputers.
Then came the Apple and Commodore PET computers. They were the first mass-market microcomputers for beginners as well as for more experienced people. Actually, the PET (short for Personal Electronic Transactor) could be considered the great-grandfather of the Commodore 64. When the PET was first introduced, there weren’t many books or publications to help beginners learn about computing, and fewer still ready-to-run programs, so it was quite a challenge for a beginner to use a PET. Fortunately, things began to immediately improve with the formation of user clubs and the publication of a number of small but informative newsletters.
It was a short time later (the spring of 1979) that I joined Small System Services, which a few months later began publishing COMPUTE! (the parent magazine of COMPUTE!’s Gazette). It was at Small System Services that I got my first hands-on experience with microcomputers. Most of that experience was with the Commodore PET and CBM computers, though the Atari was not far behind.
I had been with Small System Services about a year when, in an effort to further my programming skills, I left to work for Micro Technology Unlimited. For the past three years, I have been writing or adapting programs almost exclusively, though my work still exposes me to a good deal of hardware. Most of my programming involves machine language, but I have also done a fair amount of programming in BASIC. And I have at least a little experience with some of the less widespread languages, such as Forth, Pascal, and C.
Virtually all my programming experience has involved the 6502 microprocessor. The 6510, which is the microprocessor chip at the heart of the Commodore 64, is identical to the 6502 except for a few minor changes. For programming purposes they can be considered virtually identical.
Tips, Translations, Small Applications
In this column, I plan to cover topics for all levels of users, but primarily for the beginner- to intermediate-level user. I will try to provide programming tips as well as useful information about the computer. Where feasible, I will discuss how to convert programs from other home computers, especially the VIC, for use on the 64, and I’ll try to keep you up-to-date on new hardware and software products for the 64. From time to time, I will try to present small applications of my own which I hope will prove useful and instructive to you. Since this column is for your benefit, I invite you to send in your suggestions for subjects you would like to see covered.
Now let’s move on to something you can put to use. As you may know, the 64 represents the state-of-the-art in inexpensive home computers. Yet it still shares a lot of similarities with Commodore machines that have preceded it. An advantage you have over owners of the early Commodore machines is the availability of helpful books and publications. This should make it easier to learn how to get more out of your computer. Your 64 came with a small book called the Commodore 64 User’s Guide. It is written in tutorial style and provides a very brief introduction to the BASIC language. In most cases, it doesn’t go into enough detail to prepare you to do actual programming.
If you do plan to do some of your own programming, a book you should buy is the Commodore 64 Programmer’s Reference Guide. It provides information on a wide variety of subjects, and in much greater detail. In my next column, I will briefly review this book, and in the future I will try to mention sections of this book where you can find additional information related to subjects covered in the column.
Microsoft BASIC
If the 64 is your first computer, and you’re planning on doing some of your own programming, then chances are that BASIC will be your first computer language. Several different versions of BASIC have been developed by various companies. Each has its own style or flavor.
The BASIC which is built into the 64 comes originally from Microsoft, Inc. It is an early version of Microsoft BASIC, which means that it is missing some features sometimes found in newer or “extended” BASICs. But, for most applications, this simpler version will prove sufficient, and it has the advantage of taking up less memory. Enhancements to BASIC have already begun to hit the market, so those who would like some of these extra features will not have to do without. I will try to keep you posted on the enhancements as they become available.
Some Terms
Before discussing some things concerning the 64’s BASIC, I had better define a couple of terms first. Some of the time I may refer to BASIC commands, and other times I may refer to BASIC statements. Some of you might wonder what the difference is. Generally speaking, there isn’t any difference. Strictly speaking, a BASIC statement is any “sentence” which is executable by BASIC, and is thus the more general term. BASIC commands are typically those BASIC statements which are executed as direct commands (that is, instructions typed in without line numbers for immediate execution). This implies that the other statements, not called commands, are typically used within programs.
The Commodore 64 User’s Guide categorizes CONT, LIST, LOAD, NEW, RUN, SAVE, and VERIFY as commands, and the rest as statements. I will try to follow this terminology, but in some cases it isn’t obvious whether a statement is being used as a command or not. In such cases, my choice will depend mostly on my mood. For example, it may seem more natural to say “OPEN command” rather than “OPEN statement” if it is being executed as a direct command.
Another important term I will be using in this column is the word “enter.” I use “enter” to refer to a line or lines that should be typed into the computer with each line being terminated by pressing RETURN. So, if I indicate that you should enter “NEW,” you should type “NEW” followed by a RETURN.
If you’ve never written any programs before, you will soon learn that some of the things you’re used to doing may not be acceptable to BASIC. A prime example is the use of commas in numbers. When writing numbers for other humans, we are taught to place commas in the number for the millions and thousands (i.e., 1,000,000). But, in BASIC, the comma is used to separate various items from one another; you write 3100, not 3,100. BASIC would interpret 3,100 as three followed by 100.
CHRGET Routine
One of the things that gives the 64’s BASIC its flavor is a routine called the CHRGET routine. This is not a BASIC routine, but a machine language routine which is part of the BASIC interpreter program. For those new to programming, the BASIC interpreter program is the program the 64 is executing while you are using BASIC. The computer chip in the 64 isn’t made to execute BASIC statements directly, so a program is needed which can interpret the BASIC statements and perform the specified action.
The CHRGET routine is used by the BASIC interpreter to fetch the next character from your BASIC program or direct command. It isn’t the only way the BASIC interpreter fetches the next character, but it is the one used in most situations. Thus, the characteristics of this routine have a major effect on the way certain things operate in this BASIC.
For example, the CHRGET routine will skip spaces. If the character fetched is a space character, the CHRGET routine will throw it away and fetch the character following the space. It will repeat this process until a non-space character is found. The result is that the BASIC interpreter won’t see any difference between “FOR I = 1 TO 10” and “FORI = 1TO10”. There are other times where the results can be somewhat unexpected. For example, BASIC also uses the CHRGET routine to fetch the digits found in numbers. Consequently, BASIC doesn’t see any difference between “9999” and “99 99”. Enter the following to see this for yourself:
PRINT VAL(“9999”),VAL(“99 99”)
It must be noted, though, that the spaces are thrown away only when the statements are being executed, and not when they are entered.
Statement Terminator
Another characteristic of the CHRGET routine is that it will signal when the end of a statement has been reached. It decides that it has reached the end of a statement when it finds a colon (:) or a zero-byte character (i.e., a character whose ASCII value is zero, not to be confused with a “0” character which has an ASCII value of 49). You need not concern yourself with the zero-byte character since it is automatically put at the end of each line by the BASIC interpreter. This is not the case with the colon, whose special status as a statement terminator can also cause unexpected results. For example, try entering and running the following one-line program:
10 INPUT T$:PRINT T$
The INPUT statement will make the computer display a question mark and pause while it awaits some response from you. Then enter:
ABCD:EFG
as your response to the INPUT statement. The 64 will display:
?EXTRA IGNORED
ABCD
As you can see, the colon in your response had the effect of terminating input into the T$ variable. The “EXTRA IGNORED” message is to let you know that there was more on the line which was not used. You might expect that changing the program to:
10 INPUT T1$,T2$:PRINT T1$,T2$
and entering the same response would get rid of the “EXTRA IGNORED” message, but this is not the case. If you enter the same input, BASIC will display “??” indicating that the INPUT statement wants more data. This happens because the colon doesn’t just separate, but terminates the input for that line as well. It is as if you entered a RETURN after the “D” instead of the colon.
As previously stated, the comma is the character used to separate items from one another. If you enter “ABCD,EFG” in the two examples above, you would find that the first example works the same, but the second works as expected. “ABCD” and “DEF” are read into T1$ and T2$, respectively. The comma does not have the terminating characteristic that the colon does.
Special-Purpose Characters
With this special treatment given to the comma and colon, it would appear that using them as normal characters would be difficult. However, this is where another character which receives special treatment comes in handy. This character is the quote mark (“). Any sequence of characters found between quotes will be interpreted as a literal string, which means that BASIC won’t use the CHRGET routine to fetch the characters. As a result, the comma and colon won’t receive the usual special treatment. The only difficulty that remains is embedding quotes within a string. This is accomplished by specifying the quote as CHR$(34) (the character code number for “) and combining it into the string at the desired places. For example, the statements:
PRINT CHR$(34);”PRINT THIS WITHIN QUOTES”;CHR$(34)
T$ = CHR$(34) + “PRINT THIS WITHIN QUOTES” + CHR$(34):PRINT T$
will both print a sequence of characters between quotes. The first statement prints it directly; the second places the string into a variable first, then prints the variable.
The moral of this story is that BASIC may not always do what you might expect. The Microsoft BASIC in the 64 uses some characters for special purposes, which in other situations can give unexpected results. As you become better acquainted with BASIC, these surprises will occur less often. I will try to cover more of these operational details in future columns.
One Final Tip
As one final tip for this month, I would like to point out that FN is a reserved keyword — it may not be used as a variable name. Remembering this could save a lot of time, and a lot of hair-pulling. On more than one occasion I have tried to use FN$ as a string variable to hold a file name. The result is a SYNTAX ERROR which can be very difficult to see if you forget that FN is reserved. I have stared at the offending statements for longer than I would care to admit before remembering this simple fact. I hope you won’t make the same mistake, at least not more than once.