This letter from Oxon TI User Tony Ralph not only gladdens the heart of a bald Editor in his old age, but
also gives the first Forth from a member.
Just a short note to comfort you with the fact that somebody is reading TI-Lines (not as thoroughly as I
might, but reading it nevertheless).
According to the information I have, you should not copy the TI Forth diskette with Disk Manager
for anything other than single-sided versions as apparently Screen 3 (the Boot screen) is transferred from
sectors 12 to 15 to sectors 367 to 370, which is on t'other side of the disk. [Stephen Shaw also warned me
about this. — PB] Screen 3 is left blank with unhappy results.
I have only just started on Forth, but with help from Neil Lawson down at Parco Electrics and by banging
my head rhythmically against the wall at appropriate moments, I now have a backup disk set up with a
binary image (?) version of the system —
minus -64SUPPORT, -ASSEMBLER, -FLOAT, and -CRU, but
plus a one-screen program to initialize program diskettes complete with the error message screens written
on to the disk.
To help a bit more, I have three Forth Words written on a very modified Screen 3. These are:
: FREE SP@ HERE - . ; (gives the free memory size available)
: PAGE CLS 0 0 GOTOXY ; (a 'clear and home cursor'...
which assumes -SYNONYMS has been loaded)
These I filched from information that Neil sent me. However, (sound of trumpets), this last one is my very
: COLOUR 7 VWTR ; (by putting a suitable decimal number on the stack in front of the word,
e.g.: 27 COLOUR you get a screen and writing color change... in this case black letters on a yellow screen.
Well, I like it anyway')
The number to enter into VDP register 7 ('cos that's what you are doing) is derived from the hex range of
colors — 0 transparent, 1 black, … E gray, F white. For example, white letters on a blue background is
>F5 (F = white, 5 = light blue) and > F5 = 245 decimal, so 245 COLOUR gives the said white letters on
a light blue background. You can of course change into hex numbering using BASE HEX and do it that
When the Personal Record Keeping module is inserted, when you select TI Basic, additional calls are available in Basic, this was given an unofficial name of "Enhanced Basic". This article is about CALL G.
TI*MES 20 and TI*MES 21, also TI Lines 7 and later issues. - and many other references on this website to Enhanced Basic which is available when the Personal Record Keeping module is inserted.
CALL G() - THE GETPUT SUBPROGRAM
And a bit more on CALL H and CALL A.
If you thought you'd seen the last of CALL H(), you'd be only half-right.
However, there is one aspect of CALL A(), the Accept subprogram, which has a bearing on the skeleton
structure of our database implemented through CALL H().
One form of CALL A() is:
CALL A (Y,X,W,C,V$,F)
The first five parameters we have already dealt with:
Y and X, the row and column co-ordinates;
W the width indicator;
C the return code which indicates which 'entry' key was used; and
V or V$ the numeric and string variables which will be the destination of any data which is entered.
We have not discussed F before. I decided that we would look at it in detail later in the series. Now seems
a suitable point at which to include it.
The F parameter is only valid when a completely-defined file header exists. That is, until you have used
CALL H() to define the structure and detailed specification of the "form", you can't make use of the F
parameter in CALL A().
F refers to the Field Number (FLD) which we encountered in the discussion on CALL H().
In our CLUB-85A file, FLD number 1 is TITL-INIT, FLD 2 is DEAR, FLD 3 is SURNAME, and so on.
What F does in CALL A() is to perform a comprehensive input validation on the
data being entered, by fetching the appropriate characteristics (type, width, number of decimal places, etc.)
of the FLD specified by F, and comparing them with the characteristics of the entry being attempted.
TITL-INIT's characteristics are:
CHAR, Width = 15, so any entry which is not within these limits is
rejected with a "honk". (Honk is the term used to describe the error tone. The "accepted" tone is called a
Check the Summary Table in TI-Lines Volume 11.
This facility saves you some of the work involved in writing your own routines to validate any input, but
of course it only applies to the use of CALL A().
And now …
Having created the skeleton structure (the Header) of our "form", we now need a means of filling the form
with data. Each completed form ("page" or record) will be a component in our club file (database).
CALL G(), the GETPUT subprogram, gives us the ability not only to write on any form but also to read
entries made on any existing form. GETPUT addresses itself to the fields in each record — in our case,
the TITL-INIT, DEAR, SURNAME, etc, fields.
It is important to make one thing clear here. A field has two parts — a "label", or "prompt" if you like, (e.g.
TITL-INIT, DEAR, SURNAME), and an entry (MR P.G.Q., BALDIE, BROOKS). You used CALL H() to
put the label into the Header (the description of the layout), and CALL G() will be used to make entries
— or examine them.
The item under Field Name is fixed or constant — it never changes from record to record. The items under
Field Entry usually change from record to record — unless there are more than one entry with the same
name, for example.
TITL-INIT......1.....MR P G Q
...............2....MR I P
...............3....MRS J R
We come now to the different forms which CALL G() can take, and although TI's own document is
published elsewhere in this issue (courtesy of TI), it is perhaps best to ignore it as it is very misleading.
The variants are:
1. CALL G(W, REC, FLD, V or V$)
2. CALL G(R, REC, FLD, MIS, V or V$)
R and W are Read and Write codes as before, although they are slightly different in this case. Note that
there are two distinctly different forms: one for Reading, and one for Writing. The codes are different too:
0 = write valid data to the file (i.e. W).
1 = read data from the file (i.e. R).
2 = indicate missing data in the file.
This last code concerning "missing data" might cause a little confusion. Essentially it means a field in
which no entry has been made that field on the form has not been filled in).
Note that the (1) form of CALL G() is used only when writing, and the (2) and (3) forms are used only
As an aside, I find it a little daft that zero should be used as the code for writing data to a file. If by chance
an error has been made in the listing of a program utilizing such subprograms, and the wrong variable is
used to indicate a Write when in fact a Read is required, an overwrite of at least one field could occur
which might not be noticed until it was too late. As zero is the default value of all unassigned numeric
variables, it would have been sensible to use a non-zero value to indicate a Write, and zero to indicate
When reading from a file with R set to 2 (indicate missing data) a value will be returned in MIS according
to what is found by CALL G().
If MIS = 0, data has been found, while if MIS = 1, this indicates that a "null entry" has been found; i.e.,
a field entry with nothing in it, neither numbers nor characters.
If missing data is found (which sounds like a contradiction in terms) one other effect occurs: the contents
of the "return variable" (V or V$) are left unchanged. This permits you to make use of "defaults", but it
might cause problems under certain circumstances.
To make an entry in our CLUB-85A file therefore, we need to refer to the structure which we set up using
CALL H() back in
Volume 11. The tables of that issue give details of the kind of entry
needed in each case.
(Bear in mind that the use of "lower case" — the small capitals — may lead to unusual effects if the file
is ever examined through the normal use of PRK or Stats, because they are not defined to be alphanumeric
characters by those modules).
Our first example entry is based upon my details. We can place it in memory using an approach similar
to that used with CALL H() previously.
We need to place the structure of the database in memory, — unless of course you did use CALL S() as instructed and have already stored the "header". If you did so, then load the file back in thus:
No. Item name.Example entry
1..TITL-INIT..MR P. G. Q
4..AD1........61 THE AVENUE
1. Switch the computer on and insert the PRK (or Stats) module.
2. Select TI BASIC and type:
3. Once again we will need to make use of a command which has not yet been discussed.
depending on whether you used cassette or disk storage, and on the file name you chose (where
Using PRINT A afterwards will indicate whether the transfer of data was successful, as for CALL S()
in Volume 11.
We will discuss CALLs L and S next time.
Having placed the structure in memory, we can begin to fill in the "form" with our example entries.
First, though, you might like to confirm that the structure is the one you want:
CALL H(1,1,0,V$) ENTER
This breaks down to be an instruction to:
CALL H(1 = READ,
INFO ITEM 1 - the file name folows in V$
FIELD NUMBER - unimportant therefore 0 (zero),
and put the file name in V$)
and you should see "CLUB-85A" — or whatever you stored there originally.
On to the first entry.
The general form of CALL G() which we will be using will be:
CALL G(0,REC,FLD,V or V$)
which translates as:
CALL G(WRITE, RECORD or PAGE number, FIELD number,NUMBER or NUMERIC VARIABLE or STRING or STRING VARIABLE)
We can either place each item individually using the Immediate mode, or write a short routine to do it for
us. In order that I may give brief explanations where necessary, I will only demonstrate CALL G() here
in Immediate Mode.
There are 14 fields to be entered. Each CALL will have the same initial part:
CALL G(WRITE, RECORD #1,
and knowing this should help to minimize typing errors.
To enter the TITL-INIT item (field 1):
CALL G(0,1,1,"MR P. G. Q.") ENTER
Then to check that it was accepted:
CALL G(2,1,1,MIS,V$) ENTER
PRINT MIS,V$ ENTER
which should result in:
0... MR P. G. Q.
If you see anything else, there is something seriously wrong. See me afterwards!
To continue:To continue:
CALL G(0,1,4,"61 THE AVENUE")
Note: These last two are null strings — two quotes together.
CALL G(0,1,9,"OX1 5PP")
CALL G(0,1,10,"0865 730044")
Note the last entry — it is the only one which is a "non-character" type.
Now to demonstrate the effects of a Read code of 2 (indicate missing data). Two fields (7 and 8) had no
entries, so we'll use one of them.
V$ = "BEFORE"
should produce a display of:
indicating that the data is "missing" (1) and that the contents of V$ ("BEFORE") are unchanged.
Use a field value of 9 (POST-CODE):
V$ = "BEFORE"
and you should see:
0 OX1 5PP
At a later stage I will print out a file as it appears when stored on disk, which, while of little real interest
to disk non-owners, should at least give them something more concrete to work on.