NIGHTMARE DETOUR

Saved by bank selection

You'll recall from the first three episodes of our "Nightmare Mission" series that we were recently contracted to produce a game for the Atari in roughly one month's time. This was our "nightmare mission." One month is far less than the usual six months allocated for a game's development, and to meet this tight deadline we had to resort to the use of a number of very sophisticated tools and techniques.

In the past three Systems Guide columns we've discussed the equipment and processes we used during the course of this proiect to get extraordinarily fast results. Our intent is to save the reader time and money by presenting the most efficient means possible to develop Atari programs.

In "Nightmare Mission" (ANTIC, October 1983), we covered the selection of an assembler for the project. We ended up using the MAC/65, which is the speediest and most powerful assembler we've been able to get our hands on. It saved us a great deal of time during assemblies.

In "Mission Accomplished" (ANTIC, November 1983), we discussed the unique debugger we used for the project, the Bit3 board with the ASM/ED cartridge. This provided us with a separate debugging screen in addition to the normal debug printout, and greatly increased the speed of the debugging process.

Finally, in "Mission Redux" (December 1983), we compared the disk drives that are currently available to the software developer and noted the ways in which a fast disk drive can increase your productivity.

This month, after a one-month hiatus, we'll explore the basics of "bank selection," the newest and "hottest" technique for programming Atari cartridges. Only very recently have bank-selected cartridges become available; in this column, we'll show why they're such powerful new tools for the general Atari user and the software developer alike.

CARTRTDGE DESIGN

Let's start with a quick overiew of the development of the Atari cartridge. The first cartridges had very little memory. Basketball and TicTacToe, for instance, each contain only one 4K memory chip. Star Raiders and the BASIC cartridge each include two 4K chips, for a grand total of only 8K of memory apiece. When these chips were first offered, prices were very high; remember, Star Raiders used to retail for $60!

Gradually, though, prices fell andl chips with more memory were introduced. It isn't uncommon nowadays to find two 8K memory chips (for a total of16K) contained in a single cartridge such as Donkey Kong.

However, you won't be able to find cartridges with more than 16K of memory. Why not? Well, when the Atar computer was designed, room for only 16K was allocated electrically for the cartridge slot. As a result, cartridge designers were stuck with "address lines" that make it impossible to hook up more than 16K in the machine. Keep in mind, though, that back in 1978 16K of memory was an expensive proposition. When Atari's designers allocated space for a 16K cartridge, they thought they were "over-designing" the computer.

WHAT IS BANK SELECTION?

How does all of this relate to our game project? After we'd finished developing the game and after every demand of our contract had been thoroughly covered, we realized that our game, which had to fit into a 16K cartridge, was 24K long!

At this point, we had several choices. We could trim the game, but this would mean that we wouldn't meet the terms of our contract. We could change it to a disk-based game, and again fail to live up to our contract's demands. Or we could develop a new kind of cartridge. We chose the latter option, of course, and came up with a cartridge that in- corporated bank selection.

Bank selection is based on a simple concept. Imagine, for example, that you have a circuit board which contains two 16K chips, and that both of them are at the same memory address. At any one time, the Atari only "talks" to one of these chips, and the other is inactive. Sometimes the computer selects ane "bank" of memory, sometimes the other. In other words, 32K of memory is present on the circuit board, but only 16K is connected to the Atari at any given time. This is an important point, because 16K is, of course, the maximum amount that the Atari will let you connect.

If, however, you design a program that can run in one 16K piece out of one chip, and can then "switch in" the other 16K chip and run on it, you'll have fooled the Atari into accepting your 32K cartridge.

HOW WE FOOLED THE ATARI

To trick the Atari into thinking that our cartridge was only 16K, we took two 27128 EPROM chips and bank selected one of them. Since the 27128 is a 16K chip, this gave us 32K of memory on our circuit board. Next, we "mapped" or connected our chips to the Atari in the following manner:

----Memory Address $8000

Chip 1: Bank Selected (4K memory space). Only one 4K bank is active at any one time. 4 banks of 4K are available.

----Memory Adress $9000

Chip 2: Not Bank Selected (12K memory space). 12K is always active; 4K is not used.

----Memory Adress $C000

In other words, our cartridge had 12K of memory in one chip and four 4K banks of memory in the other; this gave us a total of 16K on-line and active at all times.

How did we accomplish this at the circuit level? Actually, Atari provides almost everything you need. Use a 74LS175 chip, which is a "latch.'' Connect the "clock" input, which controls when the "latch" occurs, to the D5xx select that is made available to cartridges. Then connect two of the data inputs to DO and D1, the system data lines. Finally, connect Q0 and Q1, the outputs, to A12 and A13 of the 27128 to be bank selected. As a result, when you:

LDA # (0,1,2 or 3)
STA $D500

one of the banks (0,1,2, or 3) will suddenly appear in the memory region from $8000-$9000. The 74LS175 will then be triggered by the D%xx memory-access strob, and the data line's value will set the 4K selectors (A12 and A13) of the 27128.

After going through these steps, we had 16K available to us in 4K sections, but only one section was available at a time. We also had 12K that was always available. Thus, our new cartridge provided us with 28K of available space. Since our game program was only 24K long, we had 4K to spare.

When you use this procedure, some miscellaneous fiddling is required to disable one ROM chip when the other one is active, and to handle similar tasks, but this isn't too difficult. Bank selection is the important thing.

BREAKING UP THE PROGRAM

We chose to bank select 4K banks because of the nature of our program. It broke pretty easily into four sections of 4K each and these were placed under the control of the 12K "master" section.

Our game program included four display screens: The introduction, the "ship" page, the "flying" page, and the "landing" page. These corresponded nicely with our four banks. Whenever we needed to go to a new section, we simply flipped in a new 4K section of the16K ROM. Most of the data in our game was tied in with scrolling terrain maps, so we put the maps into the banks; after all, terrain maps are not used simultaneously. All of the subroutines and drivers, on the other hand, stayed in the 12K of non-switched memory. This is an excellent technique to keep in mind if your application runs over 16K, and there's a segment of your program that doesn't need to be available at all times.

You should note, though, that you can bank select just as easily on 8K banks if your application "breaks" better along those lines. For instance, 8K is the size of the display memory in ANTIC modes E and F (Graphics Mode 8); by using 8K banks, you can hide a complete display and flip it back in with one memoory write.

64K CARTRIDGES!

In addition, the 27256 (32K) EPROM chip is now available. This means that you can now easily make a 64K cartridge. Only 16K can be used at any one time, but because bank selection is such a fast process, anything you need to access in the cartridge is almost alwaye instantly available.

Imagine a 64K cartridge! This is a huge amount of memory for a computer game, even a game with a lot of text. For instance, imagine the "Zork" games, from Infocom, running from a cartridge with no disk access to slow things down: The computer would practically give you your answer before you asked the question! Chip prices are coming down, and a number of Atari users who don't own disk drives want software they can use, so in all probability the days of bank-selecred cartridges are here to stay.

BURNING THE 27128 EPROM

Incidentally, you "burn" the 27128 EPROM (28-pin) using a 2732A (24- pin) EPROM burner; you hand-select which 4K bank you burn.

Be careful of pin 20, which you used to apply programming voltage to; if you do this to a 27128 -- despite claims of "pin-to-pin compatibility" -- you'll fry the chip. They're $50 each, so this was a tough lesson for us to learn. It turns out that "compatibility" with the 2732 only applies to reading the chip.

PIRATE-PROOF BANK SELECTION

I recently picked up a democopy of OSS's new ACTION! language, which is cartridge based. It uses a "proprietary memory system" to "pack 24,000 bytes of code into only 8K of memory space."

Now you know how this was done: Bank selection. I opened the ACTION! cartridge to see exactly how they did it, and there was my old friend, the 74LS175. It was connected to two 2764 (8K) chips, and was busily bank selecting them. These two ROM chips occupy the same memory space and flip back and forth between themselves periodically, sharing 16K of code in one 8K space.

This arrangement has a unique advantage: It is extremely difficult to make a pirate copy of this cartridge for a disk-based format.

Nearly every other cartridge on the market has been copied to disk format and then distributed widely. The memory space that the cartridge used to occupy is loaded by the disk drive, and the system is fooled into thinking that a cartridge is present. Not so with ACTION! When the bank-selection technique has been used, you can't get to the whole cartridge at once; furthermore, two separate memory images occupy the same memory space. As a result, there is no practical way to simulate this configuration in RAM without relocating the code, which is extremely difficult task.

As a software developer, you should keep in mind that bank selection is very effective against pirating. Even if you don't need to bank select, because your application fits within 16K, you might want to use it because of the protection it offers. If you use bank selection, your program will not run unless your cartridge is "really" there. That's about the best insurance you're likely to find in this business.

David and Sandy Small are professional programmers who work extensively with Atari computers and Atari-compatable peripherals and software to produce commercial software for the Atari. In Systems Guide, they share discoveries, insights, experiences and secrets of professional programming that should be of interest to others who are at or near their level of practice.