Classic Computer Magazine Archive CREATIVE COMPUTING VOL. 9, NO. 12 / DECEMBER 1983 / PAGE 261

Apple Basic programming using a word processor. Richard F. Thompson.

Apple Basic Programming Using A Word Processor

Writing Basic code on the Apple computer is usually done using Applesoft or Integer Basic interpreters which provide elementary editing features based on "free cursor' and overwrite. These few tools are certainly adequate for writing and maintaining Basic programs, but they are rooted in the operating system and are somewhat unpleasant for human operators to use for more than casual programming.

If your Apple system includes one disk drive and a word processing program, it may be possible to compose, alter, edit, save, and print out your Basic programs using the more advanced human-oriented capabilities provided by the word processor.

The immediate advantage is a dramatic increase both in programming comfort and in code listing legibility. It is also possible for a word processor to pick up and maintain Basic programs previously written the usual way.

A good word processor can transfer Basic program code from several files to a new program file and thus provide a modular alternative to chaining Basic files that is operationally similar than the &HOLD-&MERGE operations in the Tool Kit.

Magic Window is being cited in this article because I know from experience that this word processing program does all of the above in fine fashion, and it is splendidly compatible with human Basic programming.

For the method described here, the essential requirement is that the word processor to able to load, edit, and save standard DOS sequential TEXT files which must not contain any non-Basic control characters inserted by the word processor. This is possible when using Magic Window by executing the FILER option, UNFORMATTED LOAD/SAVE.

Some word processors do not process DOS TEXT files, and some insert formatting commands into TEXT files. An Apple user who already has a library of program code in Basic files will not be taking a step backward if new code is developed and retained in TEXT files, because it is very easy to transfer Basic program code back and forth between Basic files and TEXT files. The word processor is not needed to make these transfers since they are done using Applesoft or Integer Basic, as will be shown below.

One of the unpleasant things about using an Apple to write Basic programs is that when you type a program line and hit RETURN, the interpreter strips away all "unnecessary' blanks and then saves the line in memory in a collapsed form. When the line is listed later, the interpreter first inserts blanks according to its own arcane formula, and then displays a reinflated version of your program line.

The unpleasant result is that your extant program lines seldom resemble the ones you so carefully typed, and the sloppy spacing coupled with weird wraparound makes the code difficult to read and work with. This won't happen with Magic Window, since what you type is what you see, forever.

Another nice feature of composing Basic programs on a word processor is that 80-character lines can be maintained and printed on a printer. The word processor will also maintain neat margins, and permit the use of truly blank lines to create paragraph structure in the listing without the obtrusive, numbered REM statement. Having 40 extra columns to work in, and knowing that what you type is what you will see, gives you additional support and incentive to write Basic code and create eye pleasing listings at the same time.

Combining Material From Basic Files

The greatest problem associated with Apple Basic programming may well be that neither Applesoft nor Integer Basic contains a direct way of combining program material from two or more Basic files. Suppose, for example, that a programmer has three tested and true subroutines residing in three different Basic files and that a new programming problem can be solved by executing the three subroutines iteratively. Chaining the files at run time is a clumsy approach to the problem if only a part of each file is required and if control will be passed back and forth between the three sections of code many times in an unpredictable sequence. This sort of multiple subroutine interplay is common in municipal work.

The swiftest approach to this Basic problem may be to keep all tested and true subroutines in TEXT files and use a word processor to transfer this bits and pieces needed for the task at hand into one new TEXT file. This is easily done using the INSERT FILE command available in Magic Window.

After all the pretested tidbits are transferred from the several different TEXT files and brought together in the new problem solving TEXT file, they can easily be renumbered or rearranged as needed by using Magic Window CHARACTER-EDITING and LINE-EDITONG commands to insert/delete characters and to insert/delete/move/ duplicate lines. Then the subroutine pieces can be cemented together by code appropriate to the problem at hand using GOSUBs to invoke them in iterative fashion.

When using a word processor to edit Basic programs on the Apple, all alphabetic characters which are not part of a REM statement must be given in uppercase. As on a typewriter, one initial operation can shift-lock the Magic Window keyboard to type all succeeding alphabetic characters in uppercase; this is done either by hitting the ESC key twice in the EDITOR subsystem mode or by entering the CONFIGURATION SUBSYSTEM and setting UPPER CASE ONLY to YES. If lowercase text is desired in REM statements, use the ESC key method since uppercase can be locked or unlocked at any time in the EDITOR subsystem.

Another thing to keep in mind is that every line of Basic code must begin with a line number. In Applesoft, a line of Basic can have up to 239 characters, and it is terminated by hitting the RETURN key. When you use the interpreter, one long Basic line can wrap around onto several 40-character screen lines until the RETURN is reached.

But when you use the Magic Window, Basic line length is limited to 80 characters between successive RETURNs, and no wraparound is possible.

The thing to keep in mind is that every Basic line must be contained on one Magic Window screen line of 80 characters or less, and it must begin with the statement number. But Magic Window will maintain any completely blank lines that you may want to use to give your printed program a nice paragraph structure.

The simple Basic program in Figure 1 was written using Magic Window and saved on disk as a TEXT file named FILE1.MW. Note that the user gave the file name FILE1 to the FILER, but Magic Window SAVEd the program in a file named FILE1.MW.

Magic Window automatically appends MW to file names that are given to the FILER for LOAD/SAVE operations, so the disk catalog always shows which TEXT files are compatible with Magic Window.

Using EXEC

Because Magic Window stores the program on disk in a TEXT file, Applesoft cannot access it with a LOAD OR RUN command, but the EXEC command can be used; EXEC FILE1.MW causes the numbered program lines to be loaded into memory right on top of any program lines that may already be in memory. So it is always a good idea to first type NEW before typing EXEC if you don't want program lines already in memory mixing with the lines coming in from your TEXT file.

After line 300 is loaded, EXEC reads the next line, and since this line has no line number, the RUN is treated as an immediate mode command. EXEC immediately executes each immediate mode command in FILE1.MW, so the Basic program is now executed and prints PROGRAM 1.

Being able to imbed immediate mode commands in a file containing a Basic program is another advantage of using TEXT files to store programs. After all the lines have been read from FILE1.MW, EXEC encounters the Magic Window End-of-File marker, CTRL-C, which causes the Basic interpreter to issue a SYNTAX ERROR which can be ignored.

Although it may be convenient to imbed immediate mode commands in the TEXT file, it is not necessary to do so. If the TEXT file contains only Basic program (numbered) lines, the EXEC command simply loads them all into memory and returns control to the keyboard. After EXEC loads the program lines into memory, they are identical to program lines that are typed in from the keyboard or read from a Basic file on a disk, so any or all of the usual commands--RUN, LIST, SAVE--can now be given from the keyboard.

It is useful to note what is accomplished when the command SAVE FILE1 is given. As always, the SAVE command simply saves the program back on disk in a standard Apple Basic file. Note that a program which was originally in a TEXT file named FILE1.MW and which was loaded into memory by the EXEC command, will be put back onto disk in a standard Basic file named FILE1 by the SAVE command. In this way, a program can be easily transferred from a TEXT file to a Basic file.

The suffix .MW should be omitted from the name given to the Basic file by the SAVE command, since the Basic file cannot be processed by Magic Window. For further illustration, line 200 in memory is changed to PRINT "PROGRAM 2', and the changed program is saved as FILE2 and immediately reloaded and listed.

Transferring From Basic To Text

It is also easy to transfer a program from an Apple Basic file to a TEXT file, a transfer which permits Magic Window to take over Basic programs that have been written in the usual way. If the program is on disk as an A or I file, it must first be loaded into memory. Once in memory, it can be saved on disk in a TEXT file which can be picked up by Magic Window for program editing. To save a Basic program in a TEXT file when Applesoft is running, simply preface the Basic program code in memory with the following Basic code having program line numbers 1, 2, 3:


2 LIST 4,32767


Change D$ to <CTRL-D> when running Integer Basic.

Then when a RUN command is given, only these first three lines are executed, and the remaining lines (the Basic program) will be put on the disk in a TEXT file named PGM.MW, or any name you choose. The LIST command in line 2 causes all program lines having numbers between 4 and 32767 to be transferred to the TEXT file; other limits can be given if only part of the program code is to be transferred to the TEXT file.

Figure 1 shows this method being used to transfer the Basic file, FILE2, to the TEXT file, FILE2.MW. Adding the suffix .MW to the file name in line 1 reminds you that the file is Magic Window compatible and forces Magic Window to recognize the file as one of its own.

Note that when asked to load the file name FILE2, Magic Window loads the file named FILE2.MW; the filer automatically appends .MW to all file names and will not recognize disk files whose catalog names do not end with .MW.

Because FILE2.MW was created by Applesoft, it does not contain the Magic Window End-Of-Text marker, so the first time Magic Window loads this file, a DOS end of data error, which can be ignored, will occur. The EOT will automatically be inserted later when Magic Window saves the file, after which the error message will not occur. Note that when Magic Window loads FILE2.MW and displays it in the EDITOR, the RUN statement is missing; it disappeared when the EXEC statement executed it in Applesoft instead of storing it in memory.


This article has described how a particular word processor, Magic Window, can be used as a Basic programming aid. As an editor, Magic Window is arguably superior to the Applesoft and Integer Basic interpreters. Other word processors that can process TEXT files may also be suitable for program editing.

A good editor not only eases the task of writing and maintaining program code; it also makes it easy for the programmer to observe simple precepts of composition, such as paragraph structure, that greatly aid the reader by visibly segmenting contiguous subprocesses.

It should be pointed out that the considerable advantages of using a good word processor to develop and maintain Basic programs are achieved at the expense of using TEXT files, because compared to Basic files, TEXT file processing is slower, and TEXT files are less efficient in their use of disk space. But as shown in Figure 1, it is extremely easy to transfer programs between Basic and TEXT files so that the relative inefficiency of TEXT files is a factor only during program editing, and should neither prolong processing nor enlarge archives.

I now use my Magic Window disk as an EDITOR disk. It would be useful to have several EDITOR disks containing the same word processor. Unfortunately Magic Window is copy protected, and on a one drive system, you must swap disks to edit Basic programs that are not on the Magic Window disk.

This is a significant impediment when several programs are under development, because you frequently need to transfer control between Magic Window and Basic to EDIT and RUN the code. If Magic Window is not on the disk that contains the program code, you must swap disks after each debug run. This inconvenience is either a good reason for not purchasing a $100, copy-protected word processor, or just one reason for purchasing a $400 second disk drive.

Photo: Figure 1. Magic Window can load, edit and save program code retained in TEXT files (Type T). Applesoft (or Integer Basic) can transfer program code back and forth between TEXT files and Basic files (Type A or I).