INSIGHT: Atari

Bill Wilkinson

This month I will discuss extended memory management on the Atari computers. Before I start, though, I would like just to chat for a bit. (If you are waiting for the last part of the series on self-relocatable code, be patient. It's just bigger than I expected it to be, so I've got to massage it a bit more.)

Some Small Talk About Computers

Today I read an interview with Alan Kay in Technology Illustrated. As many of you probably know, Alan Kay was perhaps the most instrumental person in the development of the Smalltalk language. (Or is it an operating system? Or is it more properly called simply an "environment"?)

The work he did on Smalltalk while at Xerox caused him to believe that computers were destined to become a household tool, as common as, say, the television set. (Which may seem a mundane belief today, but Kay was saying such things five to ten years ago.) Well, Atari apparently liked Kay's philosophy, vision, and capabilities, and hired him awhile back.

The article I read interested me in two ways. First, it labeled Kay "Atari's Chief of Games." Well, I had been led to believe that he had been brought to Atari to head research and development, presumably to lead Atari into the generation beyond Smalltalk (a logical presumption, since he'd stated that he felt Smalltalk had served its purpose, was obsolete, etc.).

Anyway, with my orientation toward languages and systems, I saw "Chief of Games" as a step downward. Yet the interview made it clear that Kay felt he was in perhaps one of the most challenging positions possible. Hmmm. What has changed? Are games truly the most useful purpose of a computer right now? The marketplace certainly seems to think so. It is food for thought.

The second thing in the article which really got my CPU stirred up was Kay's view of the computer. I had always been under the impression that he believed his real goal in life was to enable everyone not only to use the computer, but to actually command and manipulate it. (I hesitate to say "program it," but then Smalltalk is a language.) In the interview, though, Kay stated he was beginning to fear that perhaps the computer was not so much a household tool as it was a fine instrument, like a violin. He strengthened the analogy by noting that very few people can play the violin, just as very few people can properly use a computer.

Well, I for one believe that not only is the analogy inappropriate, but its projection of gloom and pessimism about the future of computers is not justified. Granted, the analogy may hold today. After all, only about 1 percent of the United States population can claim to be able to program at all (or play "Twinkle, Twinkle, Little Star" on the violin). Probably less than .1 percent produce acceptable application programs (or play in a community orchestra or equivalent). Dare we guess that .01 percent are commercial programmers (or make their living playing the violin)? Can it be that only .001 percent can actually write systems and languages (or are the guest soloists of the concert world)?

Actually, these proportions are just order-of-magnitude guesses, but they do seem to support Mr. Kay's analogy. But I say that his analogy has validity mainly because the computer is still such a relatively "rare" instrument. Personally, I prefer a different analogy.

When computers are as much a part of everyday life in this country as automobiles are now (and I firmly believe that they will be), then I think they will be treated much as automobiles are.

Let me sidetrack a little. Here in California, the State has decreed that all high school students shall take a course in "computer literacy." So what happens? Every high school is scrambling to buy one or two computers and begin teaching every kid how to program in BASIC. Great, right? Nonsense!

Two Different Classes

First of all, I can't conceive of learning how to use or program a computer at all if the student/computer ratio is above 3 to 1. More importantly, I think it is senseless to equate "computer literacy" with "learning to program in BASIC." After all, "automobile literacy" consists of learning traffic laws, safe driving techniques, and actually starting to drive a car (it's usually called "Driver Training").

"Automobile expertise," on the other hand, consists of learning what tools do what, the theory and practice of internal combustion engines, and how to maintain and repair an automobile (and this is usually called "Auto Shop"). Does every student take driver training? Yes, or nearly so. Does every student take auto shop? No. Not by a long shot.

So, I believe, it should be with computer literacy. Don't teach everyone how to program. (What would we do with a nation of programmers? The same thing we would do with a nation of auto mechanics?) Instead, teach everyone how to use a computer to do word processing, to balance their budget, to access data bases, and the list could be quite long.

And, yes, keep the computer programming classes. But keep them on the same basis that auto shop classes are offered — as electives, for those interested in learning more than how to "drive" their computers or cars.

Why this confusion of computer literacy and computer expertise among schools and teachers? Partly because the computer industry has promoted the view. (Perhaps fearing that current applications programs are inadequate to a classroom situation?) Partly because of a dismal lack of education and information on the part of the educators. (Pity the poor math or history teacher who is nearing retirement. Suddenly he/she is forced to learn enough about these nasty machines to be able to teach some kids how to use it. Do you wonder that the path of least resistance is most often chosen?) Mostly, I suppose, because BASIC comes built into each machine, while good text processors, spreadsheet programs, etc., cost extra, money which most schools don't have.

So how does this tirade relate to either Alan Kay or you, my patient reader? Well, first of all, I think the analogy of car and computer is a better one than violin and computer. And, perhaps, if computer companies started trying to design mass consumable "cars" instead of trying to ply the public with precision instruments, it is a future that will come true. To be fair, I think that companies such as Atari and Commodore and Apple and others are starting to do so already. But my cynicism leads me to believe that they are driven by the current market, not by the future one.

You're Ahead Of Your Time

Perhaps more importantly, though, I am trying to convey the message that those of you who read this column (and this magazine) are, in some sense, ahead of your time. You are, indeed, the violinists that Alan Kay perceives. Some of you are just learning to play your first notes. Others of you are already tackling the great concertos. But, when the computer revolution really arrives, you will all have the advantage of having already taken at least your first "auto shop" course. So, if you enjoy your computer (and particularly if you enjoy programming), don't give it up easily. And certainly don't give it up now. Someday, others will appreciate your art, however humble or glorious it may be.

Did that sound like a sermon? If so, I apologize. But it's my view of both the present and the future of computers and programming. One last sidelight before we move on: On hearing me espouse the views above, someone once asked me what my position in the hierarchy was, as a person who helped design (as opposed to program) operating systems and first languages for new machines. Actually, that's an easy question: I'm simply a composer. And so, I think, are such people as Alan Kay.

You Can Bank On It

All of the new Atari XL computers (including the 1200XL) will contain 64K bytes of RAM (the 600XL requires an external RAM pack to do so). And all contain 16K bytes of Operating System ROM space. And, further, all (except the 1200XL) include good old Atari 8K BASIC. Let's see here — 64K plus 16K plus 8K — that's over 90,000 bytes of space.

Wait a minute, though. If I plug in a 16K cartridge (such as AtariWriter or ACTION! or BASIC XL), then I could have 104K bytes of RAM and ROM. Wow. That's really nifty, right? Well…

Have you read this column often enough to know that "Well…" means "not really" or "there's more to come"? No? Well…

Not really. To begin with, all Atari computers are built around the same CPU (Central Processing Unit), the 6502. (Which, incidentally, is the same chip used in most Commodore computers and all Apple machines except the Lisa.) However, there is a fundamental restriction involved when using a 6502: There is simply no way to access more than 64K bytes (65,536 bytes) at one time. How, then, can the Atari use 104K bytes? Is someone fibbing to us?

The key here is the phrase "at one time." A juggler may be able to juggle only four things at a time. Does that mean he always juggles the same four objects? Should we presume that the 6502 must always work with the same 64K bytes? Of course not.

In point of fact, the new XL machines allow the 6502 a number of choices about which bytes it will "juggle." How the 6502 makes its choice is the subject of this section.

Actually, there is no magic formula or scheme which enables the various choices. In fact, various choices are made by differing means. Generally, the choice is "consciously" made by the program currently in control of the machine. And it makes the choice simply by (usually) storing something in a particular memory location. Confused? Let's digress a little.

Some CPUs (including microcomputers and minis and maxis) treat input/output as a separate domain from general memory. For example, the 8080/Z-80 group of processors allow up to 256 separate input and output ports, which are completely separated from the general RAM/ROM memory (they even have special instructions specifically for reading/writing these I/O ports). On the other hand, many machines (such as the 6800, 68000, and 6502 families, as well as such giants as the PDP-11 series) simply treat input/output ports as part of the general machine memory.

Efficient And Easily Learned

The advantages and disadvantages of each scheme are a subject of hot debate, but I will only present a single aspect of each here: Keeping the I/O ports out of general memory allows a true 64K bytes of RAM when using an 8- or 16-bit microprocessor. Allowing I/O to be treated as part of memory means that any instruction which can access RAM or ROM can also access a port, often resulting in efficient and easy-to-learn coding.

Anyway, note that the 6502 does, indeed, use what is called "memory mapped I/O," and Atari computers do, as a consequence, reserve 2K bytes of memory (addressed from $D000 to $D7FF) which is specifically designed for I/O port addresses. (If losing 2K of your space seems excessive, pity the Apple owner who loses 4K.)

In the case of the XL machines, then, one simply changes the value in an I/O port — which appears to one's program as a memory address — and presto, a different choice of "jugglable" memory is made. But what I/O port to use? Did you notice the fact that Atari 400 and 800 computers have four joystick ports while the XL machines have only two? Guess which ports are now used for memory juggling. Did you need more than one guess?

For the more hardware-oriented of you out there, I will note that all four Atari joystick ports are actually nibble-sized pieces of a 6820 (or 6520) PIA (Peripheral Interface Adapter). The PIA is a very flexible chip; it allows each of its 16 I/O pins to be separately configured to be either an Input line or an Output line. In the case of the 400 and 800, all 16 lines are configured as Input, since they are all used to read the four directional switches of an Atari joystick. In the case of the XL machines, some of them have been changed to Output lines, thus enabling them to act as electronic switches.

On the 1200XL, for example, two of them are used to control the LI and L2 status LEDs. And (you saw this coming, I presume) two of them choose certain configurations of the computer's memory. (On the other XL machines, still another line is used to control still another possible configuration.)

Since we are discussing memory configuration choices, I might as well confuse the issue a bit more by also mentioning how we at OSS implemented our new SuperCartridges. It is probably no accident that Atari provides the cartridge slot on all machines with a line labeled "CARCTL", an abbreviation for CARtridge ConTroL. Actually, this line is active whenever any memory location from $D500 to $D5FF is accessed. Since no Atari cartridges take advantage of this line, we thought it was time that we did so.

One At A Time

About now, it is past time for a diagram. The figure shows all the possible choices of memory configuration by placing them in memory address order. Note, though, that the 64K addressing restriction of the 6502 applies. Hence, when two or more choices are given for a particular address range in memory, remember that only one such choice may be active at any given time. For each address range where a choice is available, there are two or more banks of memory. And choosing one bank over another is called bank switching or bank selection.

For example, I might choose to use BANK1 of the SuperCartridge while at the same time choosing the RAM BANK of system memory. The important thing to note here is that each set of banks (that is, parallel memory segments), as shown in the figure, is independently bank selectable.

Also, some bank choices are not available at the software level. For example, when you plug in a Microsoft BASIC cartridge, you have 16K bytes of ROM from $8000 to $BFFF. You have no RAM in that address range. You have no choice in the matter. This is, then, hardware bank selection.

The advantage of hardware bank selection is that it is essentially foolproof. If the hardware removes a bank of RAM from your program's "vision," your program can't get into trouble trying to use that bank.

But the advantage of software-selectable banks is, quite simply, that they allow you to expand the capabilities of your machine. If you look at the figure, you can see that a SuperCartridge allows you 16K bytes of programming power while occupying only two 4K byte banks at any given time.

Memory Map Of Atari XL Computers (Showing Parallel Memory Banks At Same Addresses)

And the purpose of this discussion? To show that the XL machines really do have a lot of latent power. How do we make it un-latent? Well.…

As I write this article, the number of commercially available programs which allow you to take advantage of the extra 14K bytes of RAM on an XL machine is countable on the fingers of my left foot. Zero. By the time you read this, there will likely be products heading your way that will justify the purchase of an XL machine (or a 64K memory board, such as the one from Mosaic Electronics, for your 800).

Since I am obviously most familiar with DOS XL, let me explain a little of how it works.

When DOS XL boots into an XL computer, it first establishes a set of jump vectors for the various interrupt routines. Why? Because any IRQ, NMI, or SYSTEM RESET will attempt to jump through the vectors which must (by 6502 CPU law) be located at addresses $FFFA through $FFFF. If we deselect the OS ROM bank in order to enable the RAM bank at the same addresses, the contents of these critical addresses are unpredictable. We must supply some valid routine addresses or the system will crash.

DOS XL puts most of the DOS code in the RAM bank which is "under" the OS ROMs. It also leaves a piece of itself at the conventional DOS load address of $700 (an area of memory which is not bank selectable). Then, if there is a BASIC cartridge in the machine, it selects the OS ROM bank and jumps to BASIC.

So long as BASIC makes no calls on DOS, all is calm and expected. However, watch what happens when (for example) we try to open a file from BASIC.

1. BASIC sets up an IOCB with a pointer to the filename. Since the filename was specified by the user, the pointer will contain an address somewhere between about $A00 and $9C00. BASIC makes a call to $E456, the CIO entry point.
2. CIO determines that the device requested is actually the disk file manager and uses the "D:" device table to determine the address of the disk's open file routine. It passes control to that routine.
3. Note that the "D:" device table and at least the first part of the file open routine must be in nonselectable RAM (that is, at or near $700). The file open routine is a big one, so it selects the DOS XL RAM (disabling the OS ROM) and jumps to the main part of the code.
4. The main code is able to examine the filename since it is in nonselectable memory, so the file open is performed if possible. The main code exits back to the tail end of the OPEN code, near $700.
5. This tail end then simply reselects the ROM bank and returns to where it was called (somewhere in CIO).
6. When CIO is finished, it returns control to BASIC.

Wasn't that fun? For even more fun, try to trace what happens if interrupts occur during any or all of the above steps.

More Space

But why do we go through all this? Because, even though Atari saw fit to include all this good memory bank selection capability, they provided no software to use it. So why not just forget the bank select and pretend we are running on an Atari 800 or 400? Because the net gain to you, the BASIC or ACTION! or Assembler or whatever user, is about 5,000 bytes of user space. Your programs can be 5K bytes bigger. Your spreadsheets can contain many more cells. You can edit more text.

Of course, some programs (such as VisiCalc) which do not use a standard DOS or which use a heavily protected disk (such as the Microsoft BASIC extensions) will not be able to take advantage of the extra memory. But they, too, can use these techniques to extend their capabilities if the software companies producing them will decide that the XL machines are worth the little extra effort.