Jim Butterfleld, Associate Editor
Jim Butterfleld, Associate Editor
Large programs are often divided into several parts and started up by a separate program called a bootstrap. This article explains how the technique works and provides a simple demonstration. The demo programs run on the Commodore 64, VIC-20, 16, Plus/4, 128 (in 64 mode), and PET/CBM, and require a disk drive.
Many complex programs-especially commercial software packages-appear on disk or tape as a collection of files. The program is broken into several pieces, and each file is one of the pieces. It's the job of a bootstrap program (often called a boot) to put all these pieces together. This makes your job easier: Just load the boot program and enter RUN. The boot brings in the other programs and gets everything going for you.
When you see a cluster of programs with similar names on a disk, look for one with BOOT in the name. That's the one to load and run. For instance, you might see these filenames in a disk directory:
In this case, you run GAME.BOOT. The boot loads each of the remaining files in turn: +GAME.SCREEN, which contains a drawing of a high-resolution screen; +GAME.MUSIC, a tune that plays during the game; +GAME.SPRITES, which contains pictures of moving objects; +GAME.ML, a machine language routine used by the main program; and finally, +GAME.MAIN, which is the actual game program. When the bootstrap program has finished its job, often it erases itself from memory.
Notice in the above example how all the filenames other than the bootstrap start with a nonalphabetic character. The computer doesn't care what the filenames look like; the symbols are a signal to you, the human part of the system, that you shouldn't load these programs directly.
In other cases, you don't get any hints from the filenames. The word BOOT doesn't appear in any filename, and the names are not distinguished by any special symbols. With a commercial program, you could try LOAD "*",8,1 to see if this starts a bootstrap sequence. If all else fails, you may have to try desperate measures: Read the instructions.
A Little History
Early computers had no Read Only Memory. The marvelous ROM that computers now use to store "canned" instructions didn't exist. When the computer was turned on, it knew nothing-not even how to load a program. Thus, early computer users were faced with a chicken-and-egg paradox: In order to load a program, they needed a program in the computer that told it how to load. How did they get this first program in? Sometimes toggle switches were used to enter individual bytes. Sometimes the computer could read a punched card and transfer a tiny program from the card into its memory.
Whatever the method, one thing was certain: The first program would be very small, containing just enough instructions to do the simplest possible loading job. And the first program to be loaded would usually be a bigger and better loading program. You had to start with a tiny loading program whose job was to bring in a bigger loading program. It seemed as though the computer was coming into action by pulling itself up "by its own bootstraps." And the term bootstrap came to signify any program whose job is to bring in a larger program.
Once you open the door to program-loading programs, new possibilities arise. For example, a bootstrap program can bring in several disconnected modules, each of a different type (a screen, a main BASIC program, a machine language routine, and so on). Since the modules may load into different memory areas, it's usually far easier to create them as separate files rather than paste them into one big package that loads as a single file.
A bootstrap program can also reconfigure the computer. To make room for a high-resolution graphics screen or extra sprite definitions, you may need to change the locations where BASIC starts and ends. The boot program can reconfigure BASIC memory, then load the main BASIC program into the newly defined area.
The bootstrap can make changes to allow for a particular model of computer. If the boot program finds it is running in an 80-column machine, it might decide to load.an 80-column program module instead of the 40-column one. Or, the boot could let the user decide what modules to load, depending on what peripherals are in use. Thus, the program might ask if the user has a color or black-and-white monitor, or call for the identity of any printer that is connected.
Writing A Simple Boot
Let's write a small program that uses a bootstrap technique. We'll make the program do a simple task: read a sequential file from disk. If you don't happen to have a sequential file on disk, you can create a short one called XFILE by typing the following statements in direct mode (without a line number).
Now for the program itself. Here's the plan: We'll put a main program in BASIC's usual memory area. In another area (the cassette buffer), we'll put a machine language (ML) routine that reads the file quickly and displays it on the screen. Finally, we'll need a bootstrap program to install the other two modules. We'll be using several advanced techniques, including machine language programming, program overlays, and dynamic keyboard. If you haven't seen them before, don't worry. There's no space here to explain the techniques in detail, but you can still run the programs and enjoy the view.
First you need to put an ML routine on disk. The following program is not an ML routine itself, but a generator program that creates one for you. Type in and save the program, then run it. (Be sure to type the semicolon at the end of line 220.) This program puts a short machine language program named "+ML" on your disk. If the computer prints ** ERROR **, you've made a typing mistake in the DATA statements. After you correct the error in the generator program and resave it, scratch the incorrect ML file by typing OPEN 15,8,15,"S0:+ML": CLOSE 15. Then reload the generafor program and run it again.
If you have a Commodore 128, you can type in and save the programs in 128 mode, but before running the boot you must switch to 64 mode as explained below. The value of 144 in line 150 is correct for the VIC-20, Commodore 64 (and 128 in 64 mode), 16, and Plus/4. It needs fixing for the PET/CBM, but we'll let the boot program do that.
100 DATA 60,3
110 DATA 162,1
120 DATA 32,198,255
130 DATA 32,228,255
140 DATA 32,210,255
150 DATA 166,144
160 DATA 240,246
170 DATA 76,204,255
180 OPEN 4,8,4,"0:+ML,P,W"
190 FOR J=1 TO 20
200 READ X
230 NEXT J
240 CLOSE 4
250 IF T<>3054 THEN PRINT "**
Creating The Main Program
The BASIC program is quite straightforward. Type NEW and enter:
100 PRINT "NAME OF SEQUENTIAL
110 OPEN 1,8,2,N$
120 SYS 828
Now save this program by typing SAVE "0:+BASIC",8 so that the boot program can call it up when needed. Do not try to run this program yet. First we have to put the machine language routine it uses into memory.
Creating The Bootstrap
Type NEW again. Since the boot program varies slightly depending on the computer, we'll take care of the differences in the first line of the program. Enter line 100 as listed below for your computer.
For the 64 and VIC-20 (or 128 in 64 mode):
100 DATA 144,198,631
For the Commodore 16 or Plus/4:
100 DATA 144,239,1319
For the PET/CBM:
100 DATA 150,158,623
The three values in line 100 represent the memory locations of the computer's status variable (ST), keyboard buffer counter, and keyboard buffer, respectively. The first value adjusts the ML program to work on different machines. The other two are used to load the main BASIC program with the dynamic keyboard technique. After you enter line 100, type in the following lines as well:
110 IF X=1 GOTO 200
We're using a program overlay technique here. The computer never reaches line 140, since the boot program restarts at its first statement with all variable values intact after the LOAD in line 130. Since the variable X equals 1 on the second pass, the computer leaps ahead to the rest of the program at line 200. The technique is called program overlay because it was designed to allow a second BASIC program to be loaded over an existing program while maintaining variable values. Whenever a LOAD command is executed within a program, whatever BASIC program is in memory after the LOAD is finished will begin running at its first line. We're not actually using an overlay here, since the machine language program doesn't overwrite the BASIC boot program in memory, hence the need for using X to skip the LOAD on the second pass. Without it, the program would do nothing but LOAD again and again.
Now enter the following lines, which adjust the ML program to run on different machines.
200 READ A,B,C
210 POKE 840,A
Loading the ML required a special overlay technique. Loading the BASIC program is even trickier. Since BASIC programs normally load into the same space, the new program will destroy the bootstrap as it comes in. There are several ways we can cope with this. Perhaps the easiest is to use the dynamic keyboard technique. Here goes:
250 PRINT R$+N$+",8"+D$+D$
260 PRINT D$+D$+"RUN"+CHR$(19)
270 POKE B,2:POKE C,13:POKE C+
If you've never used the dynamic keyboard technique, the above lines may look confusing. Briefly, we are telling the computer to type two commands on the screen for us. You'll see the commands when the program runs:
The commands are carefully arranged on lines 3 and 8 of the screen. If you pressed RETURN twice-assuming the cursor was in the right place-the commands would execute, loading and running the program named +BASIC. But the boot program can press RETURN for us by putting RETURN characters, CHR$(13), into the keyboard buffer. This is a familiar trick for making Commodore computers do things that would otherwise be difficult.
Our bootstrap program is complete. Save it on disk with the name BOOT. Be sure to save a copy of the program before you run it, since it erases itself from memory after performing its work. (Users of the 128 must switch to 64 mode before running the program. Type GO64 and then enter Y at the prompt.) You should now have the following files on your disk:
BOOT (the boot program you just entered)
The sequential file you wish to read (XFILE, for example)
When you run the boot program, it loads in the ML and BASIC modules and starts things up. You'll be asked for a filename (enter XFILE if you created the sample file as shown above). After the program is finished, you can look at another file without using the boot again. Since everything's in place, just enter RUN.
This simple demonstration only hints at what a bootstrap program can do. The small but mighty bootstrap can call together many program elements to create an elegant and effective software package.