A Simple Screen Editor For Atari Data Files

A Simple Screen Editor For Atari Data Files

Lawrence R. Stark

Use this "BASIC Memo Pad" program to enter a screenful of text. The computer will automatically place the screen into the pseudo string-array B$.

Screen editing is a very convenient means for entry of data and text in computer files. Yet one of the ironies surrounding several models of small computers is that, while they have this means to edit the source code of the BASIC language programs which they all feature, the user is often reduced to some form of serial prompting for the entry of data.

There are various solutions to this problem, but one of the nicer is presented in the 400/800 Atari and its 8K BASIC. The key is the ability to control the screen and to "dump" its contents quickly with the "dynamic keyboard" technique.

The following short program is a routine which demonstrates the principle. Extracted from a larger program which externally resembles the data file manager carried in the November, 1981, issue of COMPUTE!, the routine presented here does little other than demonstrate a method that has been mentioned at various places in the literature on the Atari computers. The demonstration is, in effect, a "BASIC Memo Pad."

The routine is very simple. The margins of the screen are set, making a sort of sub screen. In the example, the screen dimensions are 16 lines vertically and 35 horizontally. The row of numbers that appears on the left of the screen may be said to be outside the screen. The programmer can make this left margin broader and put prompting headers in it.

Once the screen is set, characters are taken from the keyboard and displayed in the subscreen. Troublesome characters like AT ASCII 125, clear screen, are bypassed. Then the routine checks to see if the border of the subscreen is crossed, PEEKing locations 84 and 85. Carriage return has no effect other than to print a carriage return that becomes, in essence, a cursor control. A "home" key is provided in Control T. Within these confines – the loop from 150 to 220 – the user can do almost anything.

Once the data is acceptable, the loop is exited. In the demo program, Control J is used as the signal. The program prompts for a confirmation at this stage, and if a "Y" is issued, passes to the dynamic keyboard routine.

In the dynamic keyboard routine, the cursor is POSITIONed, an INPUT from the editor is requested, and the dynamic keyboard is activated and de-activated as it passes each of the 16 lines. The necessary POKEs are illustrated in lines 260 and 270. The effect is to read from the screen memory into the variable named A$.

At this point, the needs of the application program come into play. In the larger programs in which I use this routine, A$ is written to a disk file, sometimes with a second line concatenated. In the demonstration program, I have merely put it into the pseudo-string array called B$.

The demo program STOPs upon the transfer of the screen display to B$ via A$. If CONT is issued at this stage the process will come full cycle, placing B$ into display. While this is largely useless as presented here, it is similar to the method of recalling data from a disk file and displaying it on the screen. The programmer may then, once again, invoke the editing routine for updating purposes, as in the demo program. Of course, in an actual program, the revision would have to result in something other than the endless loop in the demonstration program!

In actual use many other features can be added. For instance, I have included a "parser," perhaps better called an auto-return, which searches the end of a line when the cursor passes a designated position. A subroutine then positions all characters past the right-most space on the next line. This is done using the LOCATE command. Incidentally, the LOCATE command can also be used to dump this screen, but it is much slower than the dynamic keyboard approach.

It seems a little surprising that it is possible to devise a form of screen editor using the BASIC language, but here it is. Limited in some ways, it is generally more user-friendly than the serial prompt system which tells of BASIC's origins in the days of teletypewriter terminals.

PROGRAM. A Simple Screen Editor For Atari Data Files.

0 REM * * Screen editor & dump * * * * * * * * * * * * * * * * * * * * * *
100 DIM B$(600), A$(40)
110 ? CHR$(125)
120 GOSUB 500
130 OPEN #1, 4, 0, "K : "
140 REM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
150 POSITION 3, 0 : ? : GOSUB 1000
160 GET #1, T : IF T = 10 THEN 230 : REM 10 = CTRL "J"
170 IF T = 20 THEN 150 : REM 20 = CTRL "T"
180 IF PEEK(85) = 36 THEN GOSUB 1000
190 IF PEEK(85) > 38 THEN POKE 85, 38 : GOSUB 1000 : GOTO 160
200 IF PEEK(84) > 16 OR PEEK(84) < 1 THEN 150
210 IF T = 156 OR T = 157 OR T = 125 THEN 160
220 ? CHR$(T); : GOTO 160 : REM main working loop (160-220)
230 POSITION 3, 18 : ? "ARE YOU SURE?"; : GET #1, X : POSITION 3, 18 : ? "{14 SPACES}"
240 IF X< >ASC("Y") THEN 150
250 REM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
260 FOR I = 1 TO 16 : POSITION 3, I : POKE 842, 13 : INPUT A$
270 POKE 842, 12
280 B$(I * 35 - 34, I * 35) = A$
290 NEXT I
300 REM * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
310 STOP
315 ? CHR$(125)
320 FOR I = 1 TO 16
330 ? B$(I * 35 - 34, I * 35)
340 NEXT I
350 GOSUB 500 : GOTO 150
360 STOP
500 B$(1) = " " : B$(600) = " " : B$(2) = B$
600 POKE 82, 0 : POSITION 0, 0 : ? : FOR I = 1 TO 16 : ? I : NEXT I : POKE 82, 4
610 POSITION 3, 0 : ? "USE CTRL "J" TO ACCEPT" : RETURN
1000 FOR I = 1 TO 5 : SOUND 0, 50, 10, 10 : NEXT I : SOUND 0, 0, 0, 0 : RETURN

Return to Table of Contents | Previous Section | Next Section