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|
|Tour de France||17,686|
|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:
- Memory. You should have at least 128K of memory (or at least 48K of program area after BASIC is loaded).
- Display size. You should have an 80-character by 24-line screen. Anything smaller will require changes in practically every PRINT statement.
- Enter the program one subroutine at a time. Test each one after it is entered and don't go on to the next until the current one is working. Above all, do not enter the entire program in one shot and expect it to work right away.
- Try to understand what each statement does and how it relates to other parts of the program. Refer to the list of variables and the comment statements. A thorough understanding of the program logic will make your job much easier when you reach the inevitable debugging stage.
- Depending upon the speed of your computer, timing loops may be too long or too short. Each program has a subroutine to make a short pause; these pauses should be one to two seconds long. You can experiment with different values in the FOR…NEXT loop to create an appropriate length pause.
- All the programs have a subroutine to print a centered line, specifically:
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.
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 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.
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# or Db||277||554|
|D# or Eb||311||622|
|F# or Gb||185||370||740|
|G# or Ab||207.5||415||830|
|A# or Bb||233||466||932|
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:
Describe the problem completely in writing.
- If you have a line printer, list the entire program, not just the statement you think is in error. Also, using the screen print feature, print one or more output screens that illustrate the problem.
- Send the above items with a self-addressed stamped envelope to: Basic Adventures Problem, David Ahl, 12 Indian Head Road, Morristown, NJ 07960.
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