Basil’s Compendium: Where to Put the Program

Where to Put the Program

This chapter will list some requirements for the place where we will put the machine code, and will show you how to find a memory location that meets those requirements. But first, our “play by ear” utility program.

The “rough draft” 1 REM line and the proofreading program are shown in Figures 3-1 and 3-2, respectively, and the readout for proofreading is in Figure 3-3. After you POKE the vacancies, according to Figure 3-4, the final proofreading should checkout with Figure 3-5.

I know that’s awfully fast, but it’s just a repeat of what you have done in the previous chapters. If you’re still having a problem with this procedure, then get in touch with me directly. I’ll be glad to be of service.

When you have the final 1 REM line in place, add the following two lines to your program:

1000 PRINT AT 10,3;"BASIL LOVES JOCELYN"
1010 RAND USR 16514

Then, GOTO 1000 and watch the fun.

And now the lesson.

What We Need

Where in ram are we going to store our machine code? We must satisfy two conditions.

1. The machine code routine must not interfere with the normal running of the computer itself.

2. The running of the computer must not interfere with the machine code.

Live and let live. For convenience, we’d like to impose a few more conditions, including:

3. The program should be easily entered, proofread and edited.

4. It should be possible to SAVE the program.

5. It should be expandable. We should be able to add more subroutines as they become necessary.

For the moment, let’s shelve number 5, and concentrate on the first four conditions. We’ll get back to number 5 later on.

Recall that the USR command must specify the starting address of the machine code routine. Much as GOTO and GOSUB have to be followed by a number (or an expression which the computer can evaluate as a number), so does the USR command require a number or expression equal to a number. This means that we’ll have to know (or compute) the address of the first byte of machine code every time we want to invoke it.

“What do you mean, every time?” I hear you cry. “Doesn’t my code stay put?” Well, that depends. Let’s try a little experiment.

Suppose your program consists of a line of 27’s. It never will, of course, but 27 is the code of a character that’s easy to spot (pardon the pun; try PRINT CHR$ 27). Let’s put a line of 27’s into the computer. Try this:

10......

OOPS! The computer won’t accept it. So, let’s give in to the computer on this point, and use up an extra byte. Try:

10 REM ......

If you’re really vindictive, POKE 16513,27. GOTCHA! There’s that line that the computer wouldn’t accept. Don’t ever try to EDIT that line. It’s much easier to include the REM. It takes up only one extra byte, doesn’t get in the way and makes things much easier all around (like salvaging the program if you ever inadvertently get the line down into the edit position).

So, now you have,

10 REM ......

Let’s see what the memory contents look like. Use the program of Figure 3-6. See those 27’s starting at 16514? Now add another line:

1 REM

Run the program again. The 27’s have moved up to memory locations starting at 16520! Change line 1 to:

1 REM ABC

Run the program again and notice that the 27’s have moved once again. Well, it’s going to be pretty hard to find a starting address that keeps moving around, but don’t give up.

Let’s try something else. Delete line 1 and Run the program again. Not surprisingly, the 27’s are back at 16514. Now, change the number of the REM from 10 to 1. Run it again. Notice that there is no change in the location of the 27’s. Now, add:

10 REM ABC

Run the program again and notice that there is still no change in position of the 27’s.

And here’s the conclusion that we draw from this maneuvering:

The address of the first byte in the first statement of the program does not depend on the line number of that statement, nor is it changed by the addition of any program lines numbered higher than the first line.

So, what are you to do? Put your machine code in a 1 REM, and the first byte after the REM will always have the same address, namely 16514, unless of course, you put a 0 REM in front of it. (We’re going to show you how and why to use line 0 one of these days.)

Ok, now let’s do something stupid, just to demonstrate a point. Don’t worry, it won’t do any harm, other than to crash (guaranteed) the program in memory. So, if you have any program material that you care about, SAVE it now, before continuing.

Ready? Enter the line

1 REM

and then POKE 16514,27. Now, LIST the program.

Don’t say that I didn’t warn you. It’s an interesting picture, but it’s not the sort of program you want to use every day. You can’t even get rid of it without turning off the computer.

What happened? Well, the computer was using 16514 for one of those “housekeeping” bytes (end of line marker), and was thrown off balance when you asked it to something else with that byte.

What we have to do is lay claim to some space for our machine code, and to do it before the computer starts using that space for its own purposes. The way we do this is to fill all the bytes we need after the REM with characters of our own choosing. There are various ways to accomplish this (see SWN 2/2, Memotext in ram or the article by Chuck Peterson on generating a big REM).

Enough preliminaries. Next time, we’ll actually write a real (though simple) program in machine code.

FIGURE 3-1. 1 REM for BLACKTOP -FIRST DRAFT-

HOW IT LOOKS

1 REM ▒CHR$ ▒E'RNDY.W7▒C.Y▒▒."4.TAN

HOW IT IS DONE

1 REM (GR 1) CHR$ (GR 2) E (SHIFT SPACE) RND Y . W 7 (INVERSE Y) C . Y (INVERSE SPACE) (GR Y) . " 4 . TAN

FIGURE 3-2. THE RUDIMENTARY LOADER

1000 REM PROOFREADING THE PROGRAM
1020 FOR F=16514 TO 16534
1030 PRINT F;TAB 6;PEEK F;TAB 10;CHR$ PEEK F
1040 NEXT F
1050 STOP
1500 REM POKING THE VACANCIES
1510 INPUT A
1520 PRINT A;TAB 6;
1525 LET A=A+16500
1530 INPUT B
1540 POKE A,B
1550 PRINT PEEK A
1560 GOTO 1510

FIGURE 3-3. PROOFREADING THE PROVISIONAL 1 REM

16514 1   ▒
16515 214 CHR$
16516 2   ▒
16517 42  E
16518 12  '
16519 64  RND
16520 62  Y
16521 27  .
16522 60  W
16523 35  7
16524 190 ▒
16525 40  C
16526 27  .
16527 62  Y
16528 128 ▒
16529 134 ▒
16530 27  .
16531 11  "
16532 32  4
16533 27  .
16534 201 TAN

FIGURE 3-4. POKING THE VACANCIES

21   117
26   252
30   119
33   242

FIGURE 3-5. PROOFREADING THE FINAL 1 REM

16514 1   ▒          LD BC,
16515 214 CHR$        726
16516 2   ▒
16517 42  E          LD HL,
16518 12  '           (16396)
16519 64  RND
16520 62  Y          LD A,
16521 117 ?           117
16522 60  W          INC A
16523 35  7          INC HL
16524 190 ▒          CP (HL)
16525 40  C          JR Z,
16526 252 UNPLOT      -4
16527 62  Y          LD A,
16528 128 ▒           128
16529 134 ▒          ADD A,(HL)
16530 119 ?          LD (HL), A
16531 11  "          DEC BC
16532 32  4          JR NZ,
16533 242 PAUSE       -14
16534 201 TAN        RET

FIGURE 3-6. WHERE ARE THE 27’S?

 10 REM ......
100 FOR M=16509 TO 16530
110 PRINT M;"  ";PEEK M
120 NEXT M