Shortly before the demise of the late TIHOME, I spent a few hours ploughing through the handbook, testing the joystick routine given there, and working out a routine of my own (all done without the benefit of joysticks, which I still do not possess).

I produced a massive document (it was too big to be called simply an article!) complete with diagram showing how brilliant I had been, and shoved it out with my usual waffle to Paul Dicks, who produced Tidings, the bimonthly newsletter, at that time.

Fortunately for me, that article never saw the light of day. I say "fortunately", because only a few weeks later I saw a short routine in one of the popular monthly micro-mags (to my shame I have forgotten both the name of the mag, and, more importantly, the name of the author) which put my own efforts into perspective (that is, into the dustbin!).

The routine is simplicity itself. I have not included the original diagram which I drew, as it would only serve to confuse the issue. All you need to remember is that only three values are used: -4, 0, and +4. The only values your routine needs are -1, 0, and +1; ergo, divide the 'returned values', which the CALL JOYST() subprogram produces, by 4 and you are almost there. All you need to do after that is decide which variable to increment (add 1 to) and which to decrement, based an the values shown in the User's Reference Guide.

Here is the main body of the routine:

CALL JOYST(1,X,Y)
R=R-Y/4
C=C+X/4
where R and C are the variables holding the current Row and Column positions for whatever object is being moved around on the screen. In this example the key-unit is 1 — that is, it refers to joystick #1. If you set R and C to be initial values (so that they place any object at the center of the screen) then the above three lines will move the object in 8 directions (but not all at once!), and if you don't move the joystick, neither R nor C will change.

Simple when you know how, isn't it? I haven't included any example routines just to be awkward, and to allow anyone who wants some to ask for them

At the moment he is looking for a suitable venue, and he will let me know prices, etc, as soon as he can. There will apparently be hardware and software on show, with people coming over from the States. I will do my utmost to be there, and I'd like to take a group of Oxon TI Users with me. If anyone is interested in going will they please let me know as soon as possible so that I can give Clive some idea of numbers.

The Personal Computer World Show will be upon us shortly, and I will try to attend. I'm not sure which day I will have free (it will depend very mach on my commitments at work) but I will try to be near the TI stand if there is one. If TI are not represented I will float around between any companies which are marketing third-party products. I don't know who is going to have stand space there, but I will be around for as long as I can manage, so if you want to come and put the boot in … er … shake me warmly by the neck, I'll be waiting.

I have invited some of the software companies known to me to insert adverts for their wares in the August pages of TI-Lines. For the moment there will be no charge, as they will be lucky to see many sales from our small group. We're not yet big enough to warrant discounts, but the time will come.

Once again I find myself in the embarrassing position of issuing the newsletter late. My excuse this time is a mixture of ill-heaith and too much other work! I'm still wading through a bog of cassettes sent to me months ago by Home Computing Weekly, in between writing articles, doing the odd review of commercial software, providing listings for Personal Computing Today, and working for the National Health Service.

The only consolation that I can offer (should you need any) is that the delay would have been even greater without TI-Writer.

99 users' meeting

The much-mentioned users' meeting has now been confirmed by Clive Scally, and will take place on November 3 at The Ritz, Witworth Street West, Manchester Central, Manchester M1, from 11am to 5pm. The venue is roughly 7 minutes walk from Manchester Piccadilly or from the bus station. There are car parking facilities nearby, I am told.

Entry to the meeting is free to all members of TI-99/4A Exchange. Other folk have to pay a quid unless they are guests of an Exchange member (or are members of a bona fide user group). I'm an Exchange member, so I will be taking my membership card up with me as proof. I talked to Clive Scally, and he suggested that I put a coupon in TI-Lines for any Oxon TI Users member to show at the door and thus gain free entry, so somewhere in the pages of this issue is a card with the magic Oxon TI Users details on it.

You can either make use of it directly, or meet up with me somewhere along the way and come in on my Exchange card. I look forward to meeting anyone who goes. There should be refreshments available, and a bar for those needing fortification. I understand that there will be a number of vendors of third-party equipment, etc, as well as a TI Users' Corner, in which you will be able to meet fabulous mythical beasts like … er … me.

Telephone Clive for more info.

That PCW Show

It was ill-starred from the beginning. On the local radio I heard that water in a signal box somewhere near Slough had caused the cancellation of all Oxford to Paddington services. A swift call to the bus company and an hour trailing round trying to work out which was the express 190 to London, and I was off.

I managed to arrive 3 hours late for everything, and a planned link-up with Ian Martin of Timeless Software did not come about, despite my two-tone sunglasses which I steadfastly wore from 1pm to 5pm. I did manage to meet up with Gary Harding — he spotted the glasses — and we toddled round the show, gawping at some of the software, at some of the ladies distributing leaflets on some of the software, and at some of the looney characters wandering around in foam rubber Inedible Hulk costumes. Yes, inedible — well, I could never stomach him …

The PCW Show was something of a let-down compared with previous years. My last trip to one (at which I met Richard Blanden, Stephen and Cathy Shaw, and Robin Frowd's back) was filled with lots of hardware goodies, albeit with little room in which to see them. This time there was lots of room, but not much in the way of hardware in evidence. There was some excellent software, making use of the hidden resources of just about every micro under the sun, but nothing from TI, nothing from the third-party software or hardware vendors, and just one or two books.

However, after much detailed investigation Gary and I managed to unearth just one 99/4A. Yes it was switched on. Yes there was a games module plugged in. Yes it had TI Wired Remote Controllers attached.

Yes it was connected to a TV. No the TV was not switched on, nor could we find an on/off switch. Boring!

The offending unit was part of a demo stand of Atarisoft cartridges, but as it had taken until 4.45pm to locate this last bastion of TI-ness, we decided to call it a day. (Friday, as it happens.)

The only thing I came away with was two packs of cheap disks (see ACC). Gary went one better — he got a free frisbee as well. Some people have all the luck.

Naughty, naughty

You may remember an insert in TI-Lines a couple of issues ago from a firm called Serato. Afterwards, a couple of Oxon TI Users called me to let me know that the insert was a direct copy of one produced by a firm called Parco Electrics of Honiton. After that, it was discoverd that Serato were also guilty of copying Stainless Software's price lists. Now, it might seem petty, but even a price list is covered by the Copyright Act, and I wrote to Parco to warn they that TI-Lines had been an unwitting partner in a contravention of that Act. I had written prior to having published the Serato insert to that company, telling them of my intention to publish, and I also replied to their offer to sell TI-Lines over the counter to their USAF customers. I even sent them a sample of TI-Lines so that they could see what it was like. I have since been told that Serato deny knowing that Oxon TI Users was to publish their ripped-off price list. Why they couldn't have spent half an hour typing up their own is beyond me.

by Peter Brooks, October 1984

If you own either the Personal Record Keeping or Statistics modules, then you also own a fairly powerful addition to TI Basic's facilities.

Information on what is now known as Enhanced Basic was first passed to TIHOME, former UK user group, by Paul Karis, president of the Dutch User Group. He was responsible for bringing the facilities to light, before even Manton Lane had any information on the subject.

When either of the two modules mentioned above is present in the "GROM port", and TI Basic is selected, you have at least 7 additional CALLs or subprograms at your fingertips, two of which will be discussed here.

[2021 update: This article was written in 1984, and the information was presented as a new discovery. Back in 1980 TI released a diskette called "Inventory Management" (PHD5024) which required either the Statistics or Personal Record Keeping modules. It had programs in Enhanced Basic. Just listing these would have given a great deal away about the extra CALLS. Four years before this article. The disk program was that good a seller no-one seems to have noticed it....]

The 7 (magnificent 7 ?) are:
Table 1: Subprograms
CALL A ACCEPT AT
CALL D DISPLAY AT
CALL G GETPUT
CALL H HEADER
CALL L LOAD
CALL P PREP
CALL S SAVE

We will begin by examining CALL A and CALL D, as they are simple, straightforward, and of most immediate use.

CALL A
There are four basic formats for this subprogram:
1. CALL A(Y, X, W, C, V)
2. CALL A(Y, X, W, C, V$)
3. CALL A(Y, X, W, C, V, L, H)
4. CALL A(Y, X, W, C, V, F)
where:
Y is the screen row (1 - 24).
X is the screen column (1 - 28).
W is the 'width' of the "field" (1 - 28).
C is the "return code" (1 - 7 : see table)
V is a "return variable" for entry of numbers.
V$ is a "return variable" for entry of strings.
L is a "low value" limit for automatic input validation.
H is a "high value" limit for automatic input validation.
F is a "field number". This is a complex subject, and can only really be discussed properly when CALLs G, H, and P are fully understood.

Although this might look fairly daunting, it becomes easier as you go along.

Let's begin with an example (all those without PRK or Statistics modules may now burst into tears).

Switch on your computer, insert whichever module you possess into the GROM port, and select TI BASIC. In Immediate Mode, type the following instruction:
CALL A(10,1,2,C,V) ENTER

The result should be a cursor flashing at row 10, column 3 (which is column 1 on the PRINT screen — a PRINT line starts at screen column 3, remember ?). The "2" specifies the width of the input line
— here it is set to 2, so that you can enter anything between -9 to 99 or so.
If you enter a number — say 31 — and press ENTER, the cursor will appear at the bottom of the screen. If you then type PRINT C : V and press ENTER, two values will be printed. The first, held in C, is the key-code of ENTER, which for Enhanced Basic is 1. The second number is 31, held in V.
However, if you go through the same procedure above, but instead of pressing ENTER, press FCTN 7 (AID), then the subsequent PRINT will give you 3 instead of 1, and 0. Table II below gives most of the valid keys which you may press, together with their 'names' and their codes. (NB: Note: Only ENTER will assign your entry to a variable.)

Return codes for CALL A for the TI99/4a console:
ENTER....1
FCTN 4...2
FCTN 7...3
FCTN 8...4
FCTN 6...5
FCTN 5...6
FCTN 9...7

The other valid keys can be used to access different parts of a program through ON C GOTO … or GOSUB …; you will be familiar with this effect on both modules (and on others — for example, the Disk Manager).

The "valid characters" which this form of CALL A will accept are the digits 0 to 9 inclusive, the decimal point (.), the "signs" (+, -), and the "exponent" (E). Anything else is regarded as invalid, and the program will not permit their entry. In fact, when attempting to enter a "blank field" with this form of CALL A you will need to use CLEAR (FCTN 4 or SHIFT C) in order to achieve it.

One thing to note about a blank field: if the variable V which has been used was first set to a value, and you then used CALL A and entered a blank field, the value held in V would have remained unchanged. That is most important.

So far we have looked at Format 1, entry of a number. You can also enter strings by replacing the V with V$ (or a string variable of your choice, naturally). This is Format 2. You will find that if you enter any "leading spaces" that they will be removed, but unlike INPUT you can enter commas (because they are not regarded as "separators").

Format 3 is a very useful variation on Format 1. Instead of having to check an entry to see if it lies within certain limits (let's say for the sake of argument that you wanted an entry to be between 1 and 99) by using IF (V(1)+V(99)) THEN …, you can get CALL A to do it for you. All you do is specify the lower and upper limits after the numeric variable V (or whatever name you choose to use) thus:
CALL A(10, 1, 2, C, V, 1, 99)

There are certain limitations to this validation — for example, it can't distinguish between integers, floating point, and real numbers — but as far as it goes it is very powerful.

Format 4, as has been said already, needs some knowledge of the other CALLs before it can be understood fully. However, a short introduction will help things along.

When you use PRK or Statistics to set up a file, you are asked to specify the attributes of each field that you use — whether it is to contain a string (and if so, how many characters — up to 15), or a number (and if so, what type: Integer, Decimal, Floating Point/Scientific Notation, and so on). What Format 4 does is permit you to compare an entry made with CALL A with a particular attribute already stored, and to validate the entry according to that. This is rather jumping the gun, though.

The "editing keys" can be used during execution of a CALL A — that is, INSERT, DELETE, Cursor Right and Left, but the function of ERASE is taken by CLEAR (FCTN 4 or SHIFT C), and FCTN E and FCTN X do not act as entry keys as they do with INPUT.

One important thing which hasn't so far been mentioned: You can BREAK out of an INPUT with FCTN 4 (SHIFT C), but you cannot with CALL A. What you have to do instead is to make an entry (anything valid), and then press ENTER followed swiftly by FCTN 4 (SHIFT C) and try and catch the program before it tries executing another CALL A.

That is, in broad outline, CALL A.
Now for CALL D.

CALL D
The DISPLAY subprogram allows you to display a line of data (text or numerals) anywhere on the PRINT screen.
1. CALL D(Y, X, W, V)
2. CALL D(Y, X, W, V$)
3. CALL D(Y1, X1, W1, V1, Y2, X2, W2, V2$, Y3, X3, W3, V3, ...)

This time, to display data you need only specify a screen row, column, the width of the field (up to 28 columns), and the appropriate number, string, numeric variable, string variable, numeric expression, or string expression.

Note Format 3. It is similar to the multiple data facility allowed in Extended Basic for some commands (e.g., CALL CHAR). In this way you can display a screenful of text very quickly indeed, or set up the layout of a form, ready to use CALL A to accept entries.
There are two further important points to note about CALL D. Firstly, if you attempt to use a null string with CALL D, it will crash with an error report. This information is not given by the TI document.
Secondly, the field width value has a dual function. As well as operating a little like SEG$() in that it can be uses to display only part of an item, if the width value is a positive number, the field over which the item is to be displayed will be cleared before the data is displayed.

If however the width value is negative, the field will not be cleared.
CALL D thus replaces the cumbersome subroutines involving HCHAR and ASC and SEG$, and is much more powerful as well as much, much faster.

You could, for example, use a CALL D to place an option on the screen — say "CS1" — and then use a CALL A over the same field so that the word CS1 is not removed. That way a user could either simply press ENTER and make use of CS1 (a "default") or type their own choice — perhaps DSK1.ZZ, or whatever. You have probably seen this in use on some modules and in some of the more intelligent Extended Basic programs.

At this point I would normally have provided some example routines, but in this instance I will refrain from doing so. Your task is to write some example routines yourself, to see if you have understood my bad explanations, and I will publish any that are sent to me. Try and keep them simple if you can.

Note that I have not covered CALL A and CALL D in fine detail, as too much information will only serve to confuse the reader.
If you have any questions about A or D, please do not hesitate to ask.