[ Go to Stephen's Entry Page ]
[ TI99/4a Articles index |   TI Book front page |    TI Resources Page |   PC99 Programs       |   TI-Lines 2 ]
contact - please use subject="TI page" to avoid spam trap!

TI-Lines Issue 1

TI-Lines is the monthly newsletter of the Oxon TI User Group - TI-Lines is produced and published by: Peter G.Q. Brooks. This issue was dated April 1984.

A short book review and a long article on the CTRL and FCTN keys.

Editorial comments After sounding a few people out, I sent a circular to all those owners who are known to me in the Oxfordshire area. Of the 25 to whom I originally wrote, only 7 actually put pen to paper or picked up the phone and made a positive effort, for which I thank them. As I have decided to give the first two issues free to all 25 owners, this should give all of you a chance to sample the quality and decide whether you wish to continue receiving this newsletter. It is being produced on a shoestring budget (i.e., my salary).

I spent several days producing stencils and three hours one afternoon trying to make decent copies from them, but failed miserably. The idea was to make the newsletter available for just the cost of a second-class stamp each month. I have therefore decided to photocopy it, but for the moment in A4 format. Possible production in A5 booklet format, with perhaps even reduction-copying, as was the case with TIHOME's sorely-missed Tidings, and as is the case with TI-99/4A Exchange's TI*MES, is a very strong possibility.

If you wish to be put on the mailing list, you must let me know and provide 12 second-class stamps to cover postage. With the special discount scheme currently operated by the GPO this could cost you less than GBP 1.50. I have no real objection if you wish to copy the newsletter for distribution among fellow owners (you'll actually be saving me money!). Please note that I will also be providing a facility for the blind or partially-sighted, in that the newsletter will be read on to an audio cassette. Those owners wishing to obtain copies of the newsletter in this manner should provide at least one cassette (C60) and at least 12 "Articles tor the Blind" labels. If there is sufficient demand for such a service from outside the Oxon group, I will seriously consider trying to provide it on a larger scale. Any assistance from interested members will be welcomed, especially tape-to-tape copying.

Make any contributions that you wish to: Items for sale/exchange/wanted; large or small articles; programs etc; comments; letters for publication; any queries which you may have (don't be backward about coming forward!), and if you wish you may remain anonymous your wishes will be respected; and anything else which you think might interest anybody. But please: Don't send large lists of your highest scores at Parsec or Invaders. It probably is very important to you, and if anyone wants to set up and run a regular section on Games Programming then by all means submit your efforts, but I hope that the newsletter will eventually gain some reputation as a good source of information both on the TI-99 and on computing generally. Within the limits of the copyright laws I will attempt to pass on any information which comes my way - undocumented functions on modules, system data, etc.

Of things to come Articles planned for the next few months include:
Ian Swales' Improved Plotter and timings for functions in TI Basic and Extended Basic.
Dave Hewitt's suggestion for using your video recorder or TV modulator with your TI-99.
Tokens in TI Basic, in Extended Basic, and a few others from Richard Blanden.
The Speech Synthesizer - How She Is Spoke.
Obtaining non-keyboard characters in listings.
Additional CALLs which give you Enhanced Basic.
Using your joysticks.
Assembly Language - the first steps.
etc. I look forward to hearing from you most of all.

Book review Learning to Use the TI-99/4A by Kevin Townsend.
110 pages. GBP 4.95. Gower Publishing.
Available at archive.org
This book by Kevin Townsend is one of a series of eleven or more, all apparently written to a standard format and this approach turns out to be a mistake, as you will see later. The book itself is about A5 or so with about 110 pages. The cover itself is misleading, as it shows a VDU with what looks like a 64 × 30 display, which of course the 99/4A cannot achieve.

The foreword by the author sounds promising and the opening chapter is quite good, although I found it amusing that an illustration showing a floppy disk was in fact VisiCalc for the Apple II. It did seem to suggest that the 4A could be regarded as a serious business machine, which of course it cannot, whatever the adverts might say. To make such a system out of the 4A you would need to expend far more time and money than on buying a dedicated system.

There then follows a historical section of questionable necessity, detailing the trials and tribulations of one Geophysical Services Inc, the forerunner of TI.

On page 9 is a photo showing a rear view of the computer with the legend: "a number of the various peripheral connection sockets, including the cassette recorder port". So the power supply has now become a peripheral, and the TV socket must therefore be "various".

In one illustration on page 10 it looks as though the printer is connected via the cassette port, and although this possibility has been raised in Tidings, I don't think that it is a standard option. The Peripheral Expansion Box gets a passing mention, which probably means that the author doesn't know too much about that either.

There then follows a sort of Basic introduction. The beginning is good (using PRINT and LET for openers as I had done in Tidings). This is followed by a chapter on strings and their manipulation, which has good exercises and has given me some ideas for my own books. The next section states that you can put your statement lines into the 4A in any order because the machine uses the line numbers to put them in the correct order. This is only half right: You can put the lines in in any order, but the computer stores them in the order in which they are entered, and then keeps a table to refer to their correct execution sequence (this information is courtesy of Stephen Shaw in Tidings).

A program listing gives PRINT "(CLS)", which might prove confusing to the newcomer. It does have another version which uses CALL CLEAR, but the first example shouldn't exist anyway.

It says that you cannot add trailing spaces to an INPUT - you can if you use leading and trailing quotes ("). Maybe they thought that was too complex for beginners when proofing the book. At one point it even seems that there is an intention to make TI Basic perform a statement of the type:

which of course it cannot.

There are many other things in this book which will trip the unwary, but what is worse is the fact, that half of the facilities are ignored, and more importantly, bad programming is encouraged. One example, if left running long enough, would eventually crash with a MEMORY FULL error.

"note that on a number of screens, only columns 2 to 28 can be accessed." Firstly, it's 3 to 30, and secondly they can all be "accessed", it's just that on some badly-adjusted TVs you won't actually see the edge columns. The author also fails to distinguish between the screen 'area accessed by PRINT and INPUT (3-30), and that accessed by H/V/GCHAR().(1-32)

Then there are appendices. The first mentions the UK TI HOME Computer Users Club of Morden (we knew it as TIHOME which is now extinct, but replaced by a commercial group called TIHCUC from Maidenhead. - I wonder how the author knew (?) and gives a run-down of two or three magazines.
[Note by Stephen Shaw 2015: The first UK user group was founded by Paul Dicks. It was called TIHOME and produced a magazine called Tidings. The membership list was passed TIHCUC, operated by a PR company, this was mostly ignored. Clive Scally set up TI*MES which continued for many years.]

There is a glossary running to some 8 pages, and one odd thing was the explanation of the jargon phrase "Word Processor". I had not recalled seeing that mentioned in the main text, so I checked the index, and sure enough, there was a reference to it, so I checked the page. It referred to the glossary …
There is a listing for a game - Tower Of Hanoi - which some might find useful.

All in all I didn't find the book to be good value for money, nor do I think it a good buy for someone who doesn't already have quite a good grasp of the 99/4A anyway, in which case they wouldn't need to buy this book.

The CTRL and FCTN keys (Part 1)
by Peter Brooks
(first published in TI*MES, newsletter of TI-99/4A Exchange)
The User's Reference Guide (URG) gives a passing and incomplete coverage of the CTRL key, and a more detailed yet still incomplete explanation of the uses of the FCTN key. This article cannot do full justice to both keys, but it may begin to lift the mists which appear to surround the CTRL key especially. To begin with, an understanding of the exact nature of ASCII is necessary.
The American Standard Code for Information Interchange (the mnemonic is pronounced "askey") is a system of characters and symbols in common use on computers. Each character or symbol has a code, just as in Morse code. Telegraphic Morse uses combinations of dots and dashes in varying numbers to represent letters of the alphabet, digits, and a few special combinations which represent standard words or phrases. Whereas one dot stands for "E", three are used for "S", so the groups of dots and dashes vary in size. To distinguish between groups, there is a slight pause after each group is transmitted.

ASCII uses groups of ones and zeroes, where the group size is fixed: 8 in all, a byte. The total number of possible combinations of ones and zeroes is 00000000 to 11111111, i.e., 256. If you treat the combinations as binary numbers, then they range from 0 to 255 decimal:
  128 64 32 16 8  4  2  1
   0  0  0  0  0  0  0  0   = decimal 0
   1  1  1  1  1  1  1  1   = decimal 255

The full range of ASCII codes is only 0 to 127, not 0 to 255 as you might have concluded. Of the 8 bits (binary digits) in a byte, only 7 are used to represent all he letters of the alphabet (both upper and lower case, i.e., capitals and small letters), punctuation marks, the digits 0 to 9, the arithmetic and relational operators (+, /, =, etc.), and some special characters which are used to transmit instructions to certain items of equipment. The 8th bit is used as a check when transmitting character codes, called Parity Error Checking. There are two methods of achieving a degree of validation of transmitted bytes. One is termed Even Parity, the other Odd Parity.

The 7 bits representing an ASCII character about to be transmitted are examined and the number of ones is counted. If the number of ones (1s) is odd, and the error checking method. is Even Parity, the 8th bit is set to "1" thus making the total number of 1s even. If the number is already even, then the 8th bit is left set to zero. The opposite procedure is followed for Odd Parity.

For example, take the upper case letter "A". Its ASCII code is decimal 65, or binary 01000001. There are two 1s, and using Even Parity, the 8th or leftmost bit would still be 0. If, however, the method in use was Odd Parity, the 8th bit would be set to 1, to make the total number of 1s odd, thus changing the combination to 11000001, which is equivalent to decimal 193 (128 + 64 + 1). This is where the codes 128 to 255 come in, for they are the codes 0 to 127 with the 8th bit set to 1. This is equivalent to adding 128 to the ASCII code.

Thus when receiving a transmitted byte of data, simple checks can be made to see if bits have been lost or changed (corrupted). If the checking method is Even Parity but a received byte has an odd number of 1s, then something has happened during transmission and the receiving equipment can either warn the transmitter that corruption has occurred, or ask for that particular byte to be re-transmitted until it is received in an acceptable form.

Note that if the corruption was such that the total number of 1s was still even, then the method would fail to pick up the interference. Because the parity checks are not foolproof, other checks are performed. One of these involves sending the data according to a protocol, where the receiving equipment is instructed to expect the data in a certain sequence. Any alteration in the sequence indicates corruption.

For example, the start of a set of data might be indicated by one particular code or sequence of codes, followed by an indication of the number of bytes to follow - perhaps 64 every time - together with something called a Hash Code. The ASCII codes of the 64 bytes to be sent are added together; each time the total exceeds 255, 256 is subtracted so that the final "total" is always a number between 0 and 255.

As each of the 64 data bytes is received by the equipment, it first scans the combination of 1s and 0s to make sure that there are an even (odd) number of 1s. If the byte passes this parity check, its value is added to a running total for that particular block - building up the hash code in exactly the same fashion as mentioned, subtracting 256 every time the total exceeds 255 - and the process continues until the 64th byte has been sent and has passed the parity check and been added to the growing hash total.

The original hash code (which may have been transmitted either before or after the block to which it refers) is then compared with the hash code which has been calculated during transmission, and if they are both the same then it lessens the likelihood that any corruption has occurred. Thus the transmission of the English word "DEAF" will involve sending the codes 68, 69, 65, and 70. The binary equivalents of 69 and 70 contain odd numbers of 1s, so if we use Even Parity we will have to set the 8th bits in those two bytes.

This alters the codes to be sent: 68, 197, 65, and 198. The hash code for those four is 16. If, by chance, during transmission the last code was to become corrupted - perhaps due to a sudden surge in the mains supply (mains spike) - and two 0s became 1s, making the "F" become a "P" say, the parity check would still pass the last byte. However, the ASCII code for "P" is 80, and the calculated hash code would now be 154 and not 16. The hash codes disagree, therefore an error has occurred, and the computer can react accordingly.

On some computers, the ASCII codes 128 to 255 are used to make available so-called graphics characters. For complex reasons, TI's system only allows 96 to 159 on the 99/4 and 128 to 159 on the 99/4A (although 127 is "blank" and could technically be regarded as the first of the graphics set), but at least the shapes of those characters are not predefined and fixed as they are on almost all other machines.

These graphics characters have their shape descriptions (definitions) stored in a particular area of memory in the computer. Until CALL CHAR() is used to re-define those characters, that area of memory is used by the computer for its own purposes. One of these is the storage of an incoming program being loaded in TI Basic using OLD CS1.

This fact is used by a routine that I wrote a few years ago to monitor the initial process of OLDing, thus giving an early indication of a failure to begin loading. The routine simply prints all the user-definable characters (i.e., the graphics characters discussed earlier) on the screen, and as the cassette OLDing begins, provided you have the volume level set correctly, you'll see the program arriving on board:
100 FOR N= 96 TO 159
110 PRINT CHR$(N);
120 NEXT N

100 FOR N=128 TO 159
110 PRINT CHR$(N);
120 NEXT N

Simply enter the relevant program and RUN it. When it has finished, type in the OLD CS1 instruction and follow the computer's prompts. When a program begins to load successfully, you will see an army of insects marching across the screen.

So far we have not even mentioned the CTRL or FCTN keys. As you will see next time, you could use the CTRL key to replace one of the programs above, placing the necessary characters directly on the screen from the keyboard.

The FCTN key's effect is largely the same as the SHIFT key on the 99/4 - giving editing functions - except that there are certain aspects not covered in the URG. For example, pressing and holding down the FCTN key and then pressing V will cause a character to be placed on the screen. Its ASCII code is 127 and it could be said to be the first of the graphics characters - the last character listed on page 102 of the URG - and its name is DEL; short for Delete.

Despite the fact that it is obtained via the FCTN key, it is one of the control characters. The rest of these characters are obtained through the (wait for it) CTRL key. Control characters are used, as their name implies, to control things. On page 93 of the URG you will see the table of control key codes. Missing from this list is CTRL , (comma), which has an ASCII code of 128 in Basic mode, and 0 in Pascal mode. Its mnemonic is NUL. On some computers (e.g. most professional machines and the BBC, among others) these keys are "active" - that is, if you press them, the computer will do something.

To confuse matters, the ASCII codes for these control characters are 0 to 31 and 127, but if you use the control key with the stated characters you will obtain on the screen characters with codes ranging from 128 (not forgetting NUL) to 159, which are the user-definable graphics characters. If, however, you were transmitting these codes down the -telephone line, they would mean something to the receiving equipment. CTRL B would inform the receiver that you were about to send a section of text, and CTRL C would signal the end of that text. If the receiving equipment was a printer, the control characters would instruct the machine to perform a carriage return, for example, or to scroll the paper up by one line (line feed, LF), or even to select a different typeface.

The control functions were devised at a time when the Teletype was the main method of communication with the computer (under certain circumstances, the VDU or TV screen has been called a "glass Teletype"), hence functions like BEL, which causes a small bell to sound once, usually signifying the arrival of a transmission. On different machines the mnemonics may be slightly different, or have slightly different meanings (e.g. EOT can mean End of Transmission, or End Of Tape - a reference to paper tape passing through a paper tape reader) but the principle remains the same.

Finally, to heap confusion upon the reader, there is an unintentional effect which can be produced using the FCTN and CTRL keys, which affords us a glimpse of the operation of the computer "behind the scenes", as it were. Enter the following line but do not yet press ENTER:

Now press and hold down the CTRL key, and then press A so that both keys are being pressed - but don't hold them down for too long, or the auto-repeat function will come into play. Now press ENTER, and then instruct the computer to LIST the line. What is that following "REM"? According to the URG, CTRL A gives a character whose code is 129 - a graphics character; so where did "ELSE" come from ? Well, when you type a normal line of Basic commands (with a line number), the computer does quite a lot of work behind the scenes. It scans your Basic commands, checking each separate word against a list or dictionary which is already stored permanently in ROM (Read Only Memory).

For each of the reserved words (e.g. LET, PRINT, INPUT, CALL, IF, etc.), the computer replaces that, word with a token. This is a single character which, when the computer LISTs your program, will be translated back into the reserved word which it is replacing. This means that although the computer will faithfully reproduce your listing when commanded to do so, internally it has used far less memory to store its version. This explains the phenomenon whereby you can enter a normal 4-line Basic statement, call it up for editing, and go on to extend it up to 6 lines before encountering the LINE TOO LONG error. The token for ELSE is ASCII 129; for PRINT is 156, and so on.

Stephen Shaw published a list of the tokens operative in Extended Basic in an edition of Tidings, back copies of which can still be obtained from Paul Dicks, 1n7 Ytreopsford Road, Morden, Surrey; tel: 01.nn0.75nn (after 8:00pm). The issue in question, if you do not have it already, is Volume 2 No. 3 (1982).

The list of those operative is too long to fit into the remaining pages of this article, and in fact the next issue will deal in some detail with the tokens, the further use of CTRL, FCTN, and editing to obtain characters on the screen as part of a listing (characters - which cannot normally be obtained directly from the keyboard. but through POKEing - using Mini Memory, Editor/Assembler, or Extended Basic + 32K) and their use to uncover additional CALLs which are present in the Personal Record Keeping, and Statistics modules, CALLs which are not already known. I am indebted to Richard Blanden for initial information on these.

When you pressed CTRL A and entered the line, you placed the token directly into the program line, so that subsequent listing caused the reserved word to be reproduced on screen. However, in order to do so, the computer had to go through quite a lot of additional processing, as you will discover if you experiment further with this. Instead of just CTRL A, if you had used CTRL B, C, D, … etc., and then ENTER and then listed the line, you would have had to wait quite some time for certain tokens to be translated, and for those tokens which exist, but which have no representation in TI Basic, the wait can amount to several seconds or more.

If you edit the line by calling it up but not changing it in any way and then press ENTER, it goes back into memory in exactly the same form. If, however, you edit the line by pressing a key but do not change the line … that is, if the cursor lies over the "R" in 'REM' and you press R, thus editing without changing - the computer will assume that you have made a change, and will scan the line(s), taking the words as they appear on screen rather than their tokens, making subsequent listing much quicker. There is far more to this than at first meets the eye!

These are all examples of the multitude of ways in which the value represented by the code of a character called up by FCTN, CTRL, or other keys, can be interpreted, depending upon the circumstance in which it is used.

The ASCII character whose code is 159 can be regarded as a graphics character (CTRL 9), or character 31 with the most significant bit set to 1 (c.f. parity), or the token for the reserved word OPEN, or a small number (represented one of two ways: "unsigned", where the value lies in the range 0 to 255 - i.e., 159; or "signed", where the value lies in the range -128 to +127 and the most significant bit (leftmost or 8th bit) indicates whether the value is positive or negative - i.e., -97. I will try to fit the discussion of One's and Two's Complement into a later issue 3), or the shape definition of a line of eight dots horizontally in a graphics character (in binary: 10011111; in hexadecimal: 9F), or even as part of a TMS9900 machine code instruction or datum.

"Teach your grandmother to suck eggs" Department
A former member of TIHOME, one David Brown of Abingdon, borrowed my Speech Editor module manual 4 and discovered that the speech separator characters detailed in that manual are also active in Extended Basic, and Robert Batts of TI (who will be reading this newsletter) tells me that details of the use of the hash symbol on either side of a "phrase" were also omitted from the Extended Basic manual. I don't know who else in the group has a Speech Synthesizer and doesn't know about these items, but anyone who is interested can obtain further details from me (see elsewhere). As an example, the "+" symbol reduces the pause between the enunciation of two words or phrases to almost nothing, so that:
will be faster than just:
CALL SAY("A","","B")

Following this surprise (I've had my Speech Editor for more than 3 years and my Extended Basic for more than two and I hadn't noticed anything amiss), a member of TI-99/4A Exchange wrote to me through its organizer, Clive Scally, and discussed the CALL KEY() bug, which reared its ugly head some time ago when I wrote an article in Tidings on High Resolution Plotting (all 14,000 words of it in one issue alone!). One of the routines provided cursor control of the plotting, using CALL KEY() with key units 1 and 2. I soon found out from those trying it on their 99/4As (I'd prepared everything on my trusty old NTSC 99/4) that using the X key with key unit 1 didn't work as it should.

If you write a short routine to scan the left-hand half of the keyboard using CALL KEY(1, K, S) and then print out the value of K whenever a key is pressed, you will find that pressing X results in what looks like a 0. If you include a relational expression (PRINT K=0) and press X, you will get the value corresponding to false - in other words, although the screen says it's 0, the computer says it's not. If you print EXP(LOG(K)) when pressing X, this time the computer tells you that the value is really 400! [The same thing happens on the scan of the right-hand half of the keyboard using key unit 2.

Stephen Shaw suggested using a test for (K+1)=1 in the plotting routines, which did work, and I couldn't think of anything better, so that is what we advised people to use. Recently Simon Pryce wrote via Clive and suggested using a simpler relational expression: K<1, which works fine, and occupies less memory and is faster in execution. If anyone in the Oxon area has not experienced any difficulty with a CALL KEY() bug as detailed here, perhaps they would like to get in touch with me, and let us see if we can discover exactly what the difference(s) might be between their machine and mine. Perhaps we could shed a little light on the mystery.

Close File Well, that is the first issue of the newsletter. I apologize for the scrappy layout, (and possibly appearance - I haven't photocopied it yet!), but with your help, criticisms, etc, I hope that it will go on to grow and improve and become a useful source of reference material for the TI programmer and user. Don't forget to make the effort and respond with any comments (naturally, praise will not be refused), and please don't forget: the first two issues are free. Thereafter, you will only get a copy if you have responded either by phone or post and sent in 12 second-class postage stamps to help out with my postage costs.

Oh, and before I forget: There are no April Fool items in this issue. Maybe next year, when we're running at 2000 copies a month …

If sufficient members live close enough to be able to hold regular meetings (or any meetings at all) among themselves, would they like to broadcast their efforts through these pages? You will be more than welcome - we may end up with several subgroups - and any support which you think I may be able to give, please do not hesitate to ask.

I would like to put members with similar interests in touch with each other, and in the next issue there will (hopefully) be a simple questionnaire which you may fill in if you have no objection, and return to me in complete confidence.

I would also like to run a page or six for the younger members of the group, to be written, and edited by them. Do we have any takers ? Let me know as soon as you can.
Good programming,
Peter Brooks

Go to top of page

[ TI Book front page   |    TI Resources Page    |   TI Articles    |   PC99 and MESS Programs ]