BASIC CONVERSIONS

All of the programs in this book were written in standard Microsoft BASIC (also known as BASICA and GW BASIC) on an IBM PC-compatible computer with 512K of memory. All have been tested on a variety of PC-compatible computers.

The programs are set up for a display of 80 characters by 24 lines. All require only 72 columns of screen width, except Orient Express, which requires a full 80 columns. Thus, they cannot be easily used in a window environment unless you expand the window frame off the screen. I recommend that you run these programs directly from BASIC under MS-DOS without windows, desk accessories, or other operating-system overlays.

Some of the programs use the built-in speaker. If you have a computer with-out a speaker, don't despair; sound is not necessary to enjoy the journeys.

The memory requirements of the programs are as follows:

Program Name Program Size in Bytes
Marco Polo 18,761
Westward Ho! 16,508
Automobile Race 20,575
Orient Express 18,321
Amelia Earhart 20,826
Tour de France 17,686
Appalachian Trail 27,392
Subway Scavenger 37,562
Hong Kong Hustle 41,506
Voyage to Neptune 7,739

All of the programs run on any IBM PC, PCjr, or PC compatible with 128K or more of memory. Remember, Microsoft BASIC itself occupies about 64K of memory; the rest of the memory space is used for the interpreted program code and data.

If you wish to convert the programs to another type of computer or another version of BASIC, be warned that this is a major undertaking. Although the programs use no unusual commands, machine language subroutines, or devious techniques, converting code from one machine to another can be tricky. If you are determined to try, here are some tips that may make your job easier:

PRINT TAB((70 - LEN(X$)) / 2) X$ : RETURN

This prints whatever is in the string X$ centered on a 70-character line. If you are converting the program to one with a smaller screen, the constant 70 should be set equal to your screen width (or a bit less for better aesthetics), and the length of X$ cannot exceed the screen width.

Apple II Family

The main limitations in converting these programs to the Apple II family are memory size and screen size. You must have BASIC in ROM with 48K to 64K of free memory, and you must have an 80-column display.

As Applesoft BASIC does not have the IF…THEN…ELSE statement, all of the ELSE constructions must be changed. For example, in Marco Polo the following lines would have to be changed:

1140 IF JL > 20 THEN JL = JL - 10 ELSE JL = INT(JL / 2)
1150 GOTO 3510 : RETURN

Without the ELSE, these statements would become:

1140 IF JL > 20 THEN JL = JL - 10 : GOTO 1150
1145 JL = INT(JL / 2)
1150 GOTO 3510 : RETURN

Applesoft does not have INKEY$; instead GET X$ is used. Applesoft also does not have WHILE or WEND. All programs use INKEY$ in a WHILE…WEND loop to halt execution temporarily. The following is one such routine:

3730 PRINT "Hit any key to continue."
3740 WHILE LEN(INKEY$) = 0 : WEND : RETURN

Here is that same routine in Applesoft BASIC.

3730 PRINT "Hit any key to continue."
3740 GET X$ : IF LEN(X$) = 0 THEN 3740
3745 RETURN

Applesoft does not have the RANDOMIZE statement to vary the starting point of the random-number generator. For RANDOMIZE, you can substitute the following statements at the beginning of each program:

5 INPUT "Please enter a number between 1 and 2000";A
6 FOR I = 1 TO A : RN = RND(1) : NEXT I

You will find a few other minor problems in converting to Applesoft, but most of them will be in the area of aesthetics rather than function. Note that while Applesoft BASIC does not have direct equivalents for some commands like CLS, LOCATE, or PRINT USING, in many cases you can achieve the same effect by using an appropriate PEEK or POKE statement.

Commodore 64, 128; Atari 8-bit Series; Tandy Color Computer

Conversion to these systems is not recommended because of their 40-column screen widths. However, if you decide to go ahead anyway, you will find the versions of BASIC on these machines substantially similar to Applesoft BASIC, so most of the above comments pertaining to the Apple II apply.

Apple Macintosh

The following comments apply only to the Microsoft BASIC interpreter for the Macintosh and not to other versions of BASIC. All of the statements and commands in Macintosh Microsoft BASIC are virtually identical to those of IBM PC Microsoft BASIC. Line numbers are not necessary on the Macintosh except when they are referred to by other statements, but you would be well advised to leave them in. Obviously, the programs do not provide for mouse support, menus, or dialog boxes.

The Macintosh display is not a constant width because characters are proportionately spaced. You may have to reformat some of the PRINT statements in your program, since you have a choice of fonts on the Macintosh. Monaco 9 point is a suggested font that helps achieve results similar to the original.

Atari ST

Atari ST BASIC is very close to Microsoft BASIC in most regards. In ST BASIC, the argument for RANDOMIZE should be zero, not RN as it is in the programs. Instead of CLS to clear the screen, Atari ST BASIC uses CLEAR 2 (clear the output window). Instead of LOCATE Y, X, Atari ST BASIC uses GOTOXY X, Y (note that the arguments are in reverse order in the two statements). In place of INKEY$ to read a key press, the statement INP(4) should be used on the ST.

The SOUND statement of the ST is quite different from that of Microsoft BASIC. Your best bet is to leave out the sound. Or combine the information below with that in the ST BASIC Sourcebook, and work out the conversions for yourself.

MSX Computers

While MSX BASIC is virtually identical to Microsoft BASIC, these machines pose the dual problems of narrow screen width and, frequently, inadequate memory. If you have a fully expanded machine (48K or 64K) and are willing to divide most of the PRINT statements into two statements, you should have relatively few problems with BASIC itself.

Sound Routines for Microsoft BASIC

Several programs in this book utilize the speaker built into the computer to play a short melody or fanfare. The SOUND command is easy to use, but it is one of the most poorly documented commands in BASIC. The command takes the form:

SOUND frequency, duration

in which frequency is the desired frequency in hertz (cycles per second or cps), and duration is the time the tone is to be sounded in arbitrary units of 55 milliseconds in length. In other words, the command SOUND 100, 10 would play a 100 Hz tone for .55 seconds.

The value for frequency can range from 37 to 32767, although the upper limit of human hearing for most people is between 14,000 and 20,000 Hz. A greater limitation is the speaker built into the computer which, depending upon the computer, generally has a range of about 100 Hz to 15, 000 Hz.

Duration can range from a minimum of zero to an upper limit of 32767 (30 minutes). In general, the most useful range of duration values is from 1 to 12.

If you wish to utilize the SOUND command to play a melody, it is important to know the frequency of various notes. You will have additional versatility if you know the relationship between various notes as well.

Middle A, the note most used for tuning instruments, is 440 Hz. One octave above, A is 880 Hz and one octave down, A is 220 Hz.

All notes follow this pattern, i.e., the frequency is doubled each octave.

Another important relationship is between the notes in an octave. There are 12 equally spaced notes in an octave, which are related to each other by the following formula:

Freq(N + 1) = Freq(N) * (2^(1 / 12))

More useful for computing is an extension of that formula for all the notes in the scale:

Freq(N) = BaseFreq * (2^(N / 12))

Thus the program to assign the correct frequency values to the two octaves above middle C (frequency 261.63 Hz) is as follows:

10 FOR I = 0 TO 24 : Freq(I) = 261.63 * (2^(I / 12)) : NEXT I

The following table shows the frequencies for the middle two and one-half octaves on the piano. These are the notes that are most useful for programming.

Note Octave 1 Octave 2 Octave 3
C 262 524
C# or Db 277 554
D 294 588
D# or Eb 311 622
E 165 330 660
F 174.5 349 698
F# or Gb 185 370 740
G 196 392 784
G# or Ab 207.5 415 830
A 220 440 880
A# or Bb 233 466 932
B 247 494 988
C 262 524 1048

TABLE 1. Note frequencies (Hertz)

Note durations are more easily related to one another than note frequencies. For example, if we assign a duration of 8 to a whole note, a half note has a value of 4, quarter note 2, eighth note 1, sixteenth note .5, and so on. A more versatile approach is to assign a whole note a duration value of DUR, a half note DUR/2, and so on. This way, you can set DUR at the beginning of the program for any tempo you want.

You can use a similar method with frequencies and assign the base frequency in Line 20 above to FRQ; then by varying FRQ, you can transpose the melody to any key you wish.

Putting all these ideas together, you will be able to add sound easily to any program. For example, here is a short program that plays the first two bars of "Give My Regards to Broadway."

10 DIM FREQ(25)
20 FRQ = 262 : DUR = 12
30 FOR I = 0 TO 24 : '2 OCTAVES
40 FREQ(I) = FRQ * (2^(I / 12)) : 'FILL NOTES WITH CORRECT FREQUENCIES
50 NEXT I
60 FOR I = 1 TO 15
70 READ NOTE, LN : 'READ NOTES AND LENGTHS FROM DATA
80 SOUND FREQ(NOTE), DUR/LN : 'PLAY NOTES
90 NEXT I
100 DATA 0, 3, 2, 2, 4, 3, 5, 2, 7, 2, 5, 1, 4, 1
110 DATA 4, 4, 2, 4, 2, 4, 2, 4, 2, 4, 4, 2, 4, 2, 0, 1

If It Doesn't Work

When a program blows up, your first reaction may be to kick your computer and yell, "There ought to be a law against people who sell books full of programs that don't work!" However, after many years of experience, we have found that almost all the problems people have with published programs result from simple typing mistakes or lack of familiarity with the peculiarities of their machines. So if a program doesn't work, we strongly suggest that you have someone else check your program character-by-character or line-by-line against the one in this book. The reason for having someone else do it is that if you have typed something wrong because you read it incorrectly, you will tend to continue to see it incorrectly.

If you are having a problem with one of the programs, reason it through. For example, in Westward Ho!, if you always run out of food on the first trip segment, that would suggest that the starting quantity is too small. When the supplies-buying routine is executed, perhaps instead of multiplying the quantity per dollar by the dollars spent, the quantities have been added by mistake. Or maybe there is a typo in the variable name. Every program has a list of variables, and practically every statement in the listing is commented; thus, you should be able to pinpoint an error once you think it through.

If, after following these procedures, you identify what you are convinced is a genuine bug, please do the following:

Please note that I am absolutely unable to handle telephone inquires. Please understand that there are well over one million copies of my books in circulation and if just one-tenth of one percent of the readers called me for a half-hour debugging session…well, you get my point. I will, however, respond to all written inquires that adhere to the guidelines given above.

Bugs aside, I'm sure you will devise many ways to extend and improve the programs in this book. I would be pleased to hear from readers—in writing—with comments about this book and, most especially, with suggestions for programs you would like to see in my next book.

Until then, have fun trekking through this volume.

Return to Table of Contents | Previous Section | Next Section