TAPE TOPICS

Help for Cassette Owners

The ATARI 400 or 800 with a cassette recorder is more useful.than most users are aware. Many ATARI disk users have ignored the cassette unit as a cumbersome device at best. If your programming technique does not exploit the strengths and circumvent the weaknesses inherent in a cassette-only system then it is very cumbersome. When used with operating techniques like those we will be discussing in this department the cassette unit is a cost effective storage medium.

A TAPE OPERATING SYSTEM APPROACH

In the 1960s, large companies effectively used tape-only systems for program and data storage and retrieval. A methodology called a Tape Operating System (TOS) was developed to simplify the programmer's interaction with these devices.

A TOS was there to provide users with the ability to easily load, save, merge, and read or write program files to tape. With a few simple techniques these functions can be combined into a simple ATARI TOS.

The basic procedure described for the program recorder in the Atari documentation is to use one side of a cassette tape per program. This uses lots of tape and is slow and clumsy. Putting multiple programs on one tape by skipping forward to specific numbers on the tape counter seems to introduce as many problems as it solves.

A MULTI-PROGRAM "TAPE LOAD"

The key to more efficient use of the cassette lies with ability to merge two programs into one "tape load." This is done by numbering the two programs into different ranges of BASIC statement numbers, then merging them using the ENTER "C" command. Now a CSAVE will save the two programs together, and the next CLOAD will load both programs. Merging in a third and fourth program is done using the same method. Even a 16K ATARI will easily hold a dozen or more small-to-medium sized BASIC programs.

A MENU TO FIND PROGRAMS

One problem with having a number of different programs in memory at the same time is how to find and run the one you want. A simple solution to this problem is to include a "menu" program in the "tape load". The menu program contains the name and starting line number of each program in data statements. It displays a numbered list of programs on the screen, saving the starting numbers in an array by program number. It then invites the user to key in the number of the selected program. This number (REPLY in the sample listing) is used in the GOTO to go to the desired starting line number from the array of numbers. Menu numbers not in use are directed back to the menu by the starting line number of zero.

The menu system becomes a closed loop if every program in the tape load ends with a GOTO to the menu. I like to do this by ending all of the programs in a tape load with GOTO 0, and adding a line 0 GOTO 15000, if 15000 is the starting line number of the menu. This has two properties. A simple RUN will always display the menu. A program can be developed with easy-to-type low line numbers without interfering with the menu set-up.

MAKING MULTI-PROGRAM TAPE LOADS

This whole approach assumes you have a way to renumber BASIC programs. You can keep a renumbering program as part of all your tape loads, if you've got plenty of memory. Or, keep one in LIST "C" format on tape so you can write a new program on a tape by itself with LIST "C", specifying the line numbers the program uses, then clear memory with NEW, reload the program with ENTER "C", then merge in the renumbering program with ENTER "C". Once the new program is renumbered, resave it with LIST, load (CLOAD) the tape load you want it in and merge it in with ENTER "C". Now just put the name and starting line number in the list of data statements and you're in business.

MULTI-PROGRAM TAPE LOADS, A FEW PROBLEMS

This technique will make life simpler but a few problems remain. Programs will be executed one after the other without an intervening END statement. This will lead to errors from multiple DIMENSION statements unless each program module begins with a CLR. Since BASIC considers all of the programs in the tape load as one continuous program the pointer to the current DATA statement is apt to get confused. This is remedied by including a RESTORE statement at the beginning of every program module. Another problem is that the same variable names may be reused in the separate program modules of a tape load. This will cause errors if the programs assume variables are set to zero or blank. This is corrected by initializing variables at the start of every module. Reusing variable names is useful to reduce program size. Remember there are only 128 available and it's often necessary to reuse names.

A more insidious problem occurs when a statement number is mistyped. This may omit the line from the program module you meant to change and clobber the line in another module. You can protect yourself against this by using separate working tapes for each program module and merging the working tapes to create a final tape load.

IN THE FUTURE

In future TAPE TOPICS we will discuss faster load techniques (600 baud too slow, how about 1200 or 2400 baud). We'll try to shorten the 20 second tape leader to just a couple of seconds. We will try to serve as a clearing house for tape problems and what to do about them. If you have questions, problems or suggestions send them to me c/o ANTIC.

See you tape users again in June!

Sample listing

[CODE]