TI Writer Editor

Stephen Shaw (Stainless Software, and contributor to TI Exchange's newsletter TI*MES) wrote to pass on a piece of information.

A response to Allen Burt's intention to find a way of using transliterate in the TI-Writer Editor:- The equivalent of transliterate is ReplaceString — as Stephen says, you can replace every occurrence of say ">i " (i.e., greater than, lower case "i", space) by say Esc 4 (switch italics on, Epson MX80 series).

TI Forth

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.

Dear Peter,
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).

Forth.
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 own invention:
: 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 way.

CALL G

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.

See also 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)
or
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 beep.)
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 …
CALL G()

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.

Example
Field:......Record...Field Entry
TITL-INIT......1.....MR P G Q
...............2....MR I P
...............3....MRS J R

DEAR...........1....BALDIE
...............2....IAN
...............3....SPAM

SURNAME........1....BROOKS
...............2....KNIGHTLY
...............3....EWING

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.

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 when reading.

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 Read.

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.

Summary Table
No. Item name.Example entry
1..TITL-INIT..MR P. G. Q
2..DEAR.......BALDIE
3..SURNAME....BROOKS
4..AD1........61 THE AVENUE
5..AD2........KENNINGTON
6..AD3........OXFORD
7..AD4.................(MISSING)
8..AD5.................(MISSING)
9..POST-CODE..OX1 5PP
10.PHONE......0865 730044
11.SEX........M
12.MEM-TYPE...L
13.RENEWAL....31DEC99
14.SUM-PAID...0
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:
1. Switch the computer on and insert the PRK (or Stats) module.
2. Select TI BASIC and type:
....CALL P(10000)ENTER
....NEW ENTER
3. Once again we will need to make use of a command which has not yet been discussed.
Type either:
CALL L("CS1",A)
or
CALL L("DSK1.CLUB-85A",A)
depending on whether you used cassette or disk storage, and on the file name you chose (where applicable).
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:
Type:
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$)

PRINT 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(0,1,
that is:
CALL G(WRITE, RECORD #1,
and knowing this should help to minimize typing errors.

Let's begin.
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,2,"BALDIE")
CALL G(0,1,3,"BROOKS")
CALL G(0,1,4,"61 THE AVENUE")
CALL G(0,1,5,"KENNINGTON")
CALL G(0,1,6,"OXFORD")
CALL G(0,1,7,"")
CALL G(0,1,8,"")
Note: These last two are null strings — two quotes together.

CALL G(0,1,9,"OX1 5PP")
CALL G(0,1,10,"0865 730044")
CALL G(0,1,11,"M")
CALL G(0,1,12,"L")
CALL G(0,1,13,"31DEC99")
CALL G(0,1,14,0)

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.

Theoretically,
V$ = "BEFORE"
CALL G(2,1,7,MIS,VS)
PRINT MIS,V$
should produce a display of:
1 BEFORE

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"
CALL G(2,1,9,MIS,V$)
PRINT MIS,V$
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.

TI Writer

Getting the most out of TI-Writer
by Allen Burt
This time I would like to start with page 98 of the TI-Writer manual —"Special Character Mode" . There are two potentially misleading statements on this page.
1. The third paragraph implies that you have to use the Transliterate command if you wish to use a combination of two or more special codes. This we now know to be untrue. In the last article I demonstrated how to input three character combinations.
2. The second error is the page reference at the end of paragraph three (… see example on page 121 … should read 107).

Reminder. Special Codes are accessed by means of CTRL U — the cursor then appears as CHR$(95), the underscore character. You can then enter the special code by pressing either SHIFT or FCTN together with the key as shown on page 146 of the manual.(This is only necessary to obtain ASCII codes 0-31).

More tips for the Editor
1. Space can be saved in TI-Writer files by removing all the blank lines within the layout. Once you have decided how many blank lines are needed for each part of the document you can place a number of line feeds at the end of the line preceding the blank line area with the aid of CTRL U and SHIFT J, i.e. CHR$(10). (This document is produced without any blank lines on the screen display). This means that one record in the file can be used for one line of characters together with a number of blank lines.

Each line of writing on the screen display requires one record in the file. Files are DISPLAY/VARIABLE 80, which means that each record can contain up to 80 characters, and each blank line occupies one record.

2. Sometimes when finishing a line there is not enough space to enter the Carriage Return (CR) without word-wrap carrying the last word and the CR over to the next line. This can be avoided by using CTRL U and SHIFT M (CHR$(13)), but you will have to ensure that you are not on the line above … "*End of file Version") … because this method of inputting a CR will not put you on the next line. You have to "Insert" a line first and then use the arrow keys to move between lines. This method cf using the CR is particularly useful when editing data tables. It does not produce an extra line that has to be deleted afterwards.

3. Most printers can be prevented from stopping when the paper out signal is activated. The Gemini 10 requires CHR$(27):"B" codes. This is useful when printing on single sheets because it allows you to print to the bottom of the page. Make sure that you do not have too many lines, otherwise you will print on the platen. This is especially important if you are using Tip 1 — the line numbers at the side of the screen will not correspond with the actual number the printer will print.