Atari BASIC String Manipulation Tricks

Atari BASIC String Manipulation Tricks

David E. Carew

While the merits of Atari's method of handling strings have been the subject of some debate, David Carew suggests how to make Atari strings work effectively. He provides some interesting techniques.

BASIC programming languages were influenced, naturally enough, by the minicomputer BASIC languages which preceded microBASIC's. The most popular of these minicomputer BASICs was probably Digital Equipment Corporation's (DEC's) PDP-11 family of BASICs : BASIC-11, BASIC-Plus and BASIC-Plus2. These BASICs possessed (and still possess) special substring manipulation functions such as MID$, LEFT$ and RIGHT$, and implemented "arrays of strings" which were referenced via subscripts exactly like a numeric array. Microsoft BASIC is a child of such ancestry. Other large vendors, including Data General Corporation, used the subscript syntax of A$(X,Y) to handle substrings, which eliminated special syntax (MID$, et al) for substring functions while precluding a "nice" implementation of string arrays. Atari's BASIC is one of this type. The DEC/Microsoft approach may be more popular than the DG/Atari approach – so much so that it is sometimes necessary to remind ourselves that simpler syntax does not necessarily mean inherently less power. Indeed, a simpler BASIC syntax may well mean that the BASIC interpreter uses fewer hardware resources, leaving more for our programs. Some different coding techniques are definitely called for, however.

I have a few tricks up my sleeve. I present some of these here in order to open up the possibilities to you.

The idea is to play to the strengths of the tool you have. One outstanding strength of Atari BASIC is its capability of addressing very long strings. What can you do with very long strings? Well, who says you can't build a viable word processor or editor in BASIC when you have the power to control and manipulate an edit buffer as a single huge string of characters? One can initialize a long string of an inconvenient large size, without inconvenient large string literal statements, and without a large number of iterations by concatenating the string to itself:

1000 E$ = " " : TRAP 1010 : FOR J1 = 1 TO 15 : E$(LEN(E$) + 1) = E$
1010 NEXT J1

For data base applications, a generalized "screen forms" handler might build and store desired screen input/display formats as a long "string image." One can precisely and flexibly embed particular string information into a surrounding string image with just one statement:

1200 REC$(J + 1 - LEN(EX$), J) = EX$

The above places the right edge of EX$ at position J in REC$, effectively right justifying variable-length information into REC$. To accomplish a similar left justification, place the left edge of EX$ at position J in REC$:

1300 REC$(J, J - 1 + LEN(EX$)) = EX$

If we begin using long strings as the handy data structures that they are, then it will be occasionally necessary to "pad" a piece of data with blanks so that it precisely fits a "longstring" subfield. Adding the correct number of blanks to short data can be accomplished in a single line like this:

1400 LN = LEN(EX$) : IF LN < 25 THEN EX$(LN + 1) = BLANK$(1, 25 - LN)

This code shows EX$ being padded with "trailing" blanks to a length of 25 characters. EX$ must, of course, be shorter than 25 characters in the first place, and BLANK$ must be initialized and left as a string of blanks. Change the literal 25 to a variable, set it as necessary, and the same single line in a subroutine will pad any string to any required length.

Stripping the blanks from data taken out of a long string is also a necessary housekeeping chore. The code to accomplish this is again very compact, but it does involve iteration (a "loop"):

1500 LN = LEN(EX$) : IF LN > 1 AND EX$(LN, LN) = " " THEN EX$ = EX$(1, LN - 1) : GOTO 1500

Line 1500 strips away "trailing" blanks on the right end of EX$. Any "leading" blanks at the left end of EX$ are just as vulnerable to an analogous technique:

1600 IF EX$(1, 1) = " " THEN EX$ = EX$(2, LEN(EX$)) : IF LEN(EX$) >= 2 THEN 1600

Substituting a variable equal to a blank for the literal blank in the above code will speed up execution; the literal, of course, improves readability. The choice in this tradeoff is yours to make.

Long strings have much inherent power, and the possibilities are endless and exciting. The old micro trick of storing graphics and machine language routines as BASIC strings and/or string literals is made all the more attractive by this power. And the tantalizing prospect of "programs that write programs" absolutely cries out for long strings that turn out to be program code. The substring manipulation techniques to be used are not as obvious without the special function calls of other BASICs. However, having seen a few such techniques in this article, you will not, I trust, now ignore Atari BASIC's "longstring" power, when this power could be of use to your application.

Return to Table of Contents | Previous Section | Next Section