Enhanced Basic Part 2

Or what You Can Do when you have the Personal Record Keeping or Statistics modules inserted into your console, or, if you have loaded the modules from disk image files, if your console thinks they are inserted...

Last issue we dealt with the really easy bit, the equivalent calls to ACCEPT or DISPLAY data.

This issue we shall dive into the mysteries of CALL L (load), CALL P (partition), CALL H (header), and CALL G (getput).

The best way to introduce these perhaps is with a working program, then in the next issue we can get down to a little more detail!

Program first, then discussion. This program will use an already created PRK data file, and in the TI Basic environment will read that data and display it on the screen. It will demonstrate several of the calls in a fairly simple manner, so you can get used to the idea of using PRK data in a Basic program.

If you have a disk system, first free up memory by typing:

CALL FILES(1)  
NEW 

As this program occupies some VDP memory, you may find that a few PRK data files will be too long to load. Try deleting some records to make the data fit.

Remarks will be in lower case between the program lines

BEFORE LOADING THE PROGRAM you must allocate an area of VDP memory for the data, by using the partition command, in command mode, thus: CALL P(10900) NEW Now load the following program and run it:
   first 1oad the prk file from disk or cassette
100 CALL L("CS1",Y)
   or call L("dsk1.fi1ename",y) as you wish now to check to see if the file is loaded
110 IF Y=0 THEN 500
   no there was an error else carry on as follows how many fields in each record? lets find out
120 CALL H(1,5,0,F)
   where f will return number of fields
130 CALL CLEAR
140 CALL D(1,1,28,"# OF FIELDS:"&STR$(F))
   then we need to know how many records there are in the data file- think of a record as a page.
150 CALL H(1,6,0,R)
160 CALL D(2,1,28,"# OF RECORDS:"&STR$(R))
   now let's loop through each record and display it on the screen
170 FOR RCD=1 TO R
   taking each field in turn
180 FOR FLD=1 TO F
   but does the field contain a number or a string? let's find out:
190 CALL H(1,10,FLD,TYPE)
200 IF TYPE=1 then 240
   as type is 0, data is a number get the data from field FLD of record RCD:
210 CALL G(1,RCD,FLD,Z,RD)
   and print the result on screen:
220 CALL D(2+FLD,1,28,RD)
   and jump over string section
230 GOTO 260
   this is the string section:
240 CALL G(1,RCD,FLD,Z,RD$)
250 CALL D(2+FLD,1,28,RD$)
   that's one field dealt with, on to the next:
260 NEXT FLD
   and now all fields in the record are on screen let's give the record number and pause
270 CALL D(23,18,10,"RECORD:"&STR$(RCD))
280 CALL D(24,1,28,"PRESS ENTER FOR NEXT")
290 CALL A(24,28,1,RC,RV$)
   and on to the next record
300 NEXT RCD
310 PRINT "NO MORE"
320 GOTO 320
500 CALL CLEAR
510 PRINT "LOAD ERROR"
520 GOTO 520
530 END

CALL P sets aside an area of memory for the data to be stored in, and must of course be sufficient to hold the data, but for Basic use, we must also have enough room for our Basic program. After using CALL FILES(1), disk users have a maximum of 12768 bytes of VDP RAM free to split between Basic program and data area, while cassette users have 13820 bytes available (see how much memory a disk system eats up). By using 10900 for our data, we have left even disk users with at least 1868 bytes for our little program!

CALL L just loads the data file into the partitioned area, the return variable following the device/file name is a 0 (zero) if an error occurs, for instance, the file is not on the disk, the data is too large for the partition, or other I/O errors. The device/filename may be a string variable if you wish, e.g. CALL L(A$,A)

CALL H deals with the "header" information- the database specification you create when using PRK/Stats what sort of data is held in each field and what name have we given the field?

Looking more closely at the usages in the listing above - there are many other uses-
CALL H(1,5,0,F)
CALL H(1,6,0,R)
CALL H(1,10,FLD,TYPE)

The first digit (1) is a READ instruction. We would use a 0 to write.

The second digit (above we have used 5, 6 or 10) is the header item number obtained from the header data:
Where 5 is the number of fields per record,
Where 6 is the number of records
Where 10 is the type of field, indicated by a value placed in the final variable (TYPE here) and if it returns a 1 the field is a string, a 2 indicates an integer, 3 a decimal number, and 4 a number in scientific notation. The fourth digit is a variable placed in or obtained from the Header data.

There are another eleven header items to cover at some point, and also the writing of data.

CALL G deals with the actual data we have stored, and as used in the listing above, (there are other uses...):
CALL G(1,RCD,FLD,Z,RD)
CELL G(1,RCD,FLD,Z,RD$)
The first item (1) is a READ instruction, with 0 used to write.
The second and third items identify the record and field number that we are going to read/write, while the final item is the variable that the contents of that particular record/field will be placed in for us to use.
Note that we must use a string variable for characters.

That fourth item (Z) is a numeric variable, which can be used to indicate blank field. It takes a value of 0 if data is found, and 1 if data is missing (that is, not entered).

When using CALL G to WRITE, the fourth parameter as above is not used, you just go on to the value you are writing, for instance:
CALL G(0,RCD,FLD,"STRING INPUT")

That fully covers CALL G, apart from a sample of how to write.

CALL S will Save the data area to cassette/ disk, very easily indeed: CALL S(DEVICE$,VARIABLE) with the variable again indicating success or failure, as with CALL L.