TIHOME Tidings - Volume 3, Number 1. March 21, 1983

Morden, Surrey

TIHOME is not affiliated with Texas Instruments in any way and is supported only by its subscribers. The opinions expressed in Tidings are not always those of TIHOME.

Prop: Paul M. Dicks MIDPM, 157 Bishopsford Road, Morden, Surrey.
Printer: The Secretary Birds, 19 Coombe Road, New Malden, Surrey.

Editorial I have pages of notes to be turned into an Editorial. It is difficult to know where to start. So, please forgive if it all sounds a bit disjointed this time. A number of you have suggested that the programs in the collection could be furnished with instructions. Also there are problems with some programs that can only be used with certain hardware configurations. TIHOME programs are the cheapest on the market and are supplied on an "as is" basis.

It would be nice to turn all programs into polished packages complete with instructions, etc., but I'm afraid time and cost do not allow it. For those of you who don't know, the offer of 4 programs of your choice, free, still stands if you inform me of a valid error in any TIHOME program. So, come on, you have purchased one of the most sophisticated machines our civilisation has to offer.

I suggest you get stuck in and learn to use it. If you use it for games only, and games that you expect someone else to supply, then you will soon get fed up with it and pass on to the next toy. If you really learn how to use the instrument you have bought, you will find it very rewarding and very useful. It has always amazed me that someone can find no other use for a TMS9900 but Space Invaders.

A Word About TIHOME TIHOME is now about 2 years old. It started with a group of enthusiasts and developed from there. It is run by myself in the evenings and the weekends, with help from my wife when she is not seeing to her five sons, two daughters-in-law and four grandchildren. We do the best we can, we are learning fast the details of how to run a business. We make quite a lot of mistakes.

Among the things we have learned is the fact that you cannot run a user group for a home computer on a home computer. Most of my time is spent recording tapes, printing listings, and doing accounts. Incidentally, it would help a lot if you sent in small tapes when you want a program. I have had orders for 12 programs, and the member has sent me 6 C90 tapes and requested one program on each side. Why, I'll never know. Can you imagine how long it takes to rewind 12 C90 tapes. Especially as the longest program you can put on tape is about 3 minutes.

Another of my problems is listings. Please order programs on tape rather than paper, if you possibly can. Someone once ordered 42 of listings in the days when listings were 50p each. It took me 4 weeks to fulfil the order, fitting it in as best I could. I only have the TI Thermal Printer and its speed is pathetic. It's fine for a user but useless for a business. So, no listings unless you really have to.

On the subject of phone calls, I suggest you remember the WW2 motto, "Is your call really necessary?" I love to talk to you, but not at 11 p. m. when I am in bed, and not at 7 a. m. on Sunday when I am also in bed. Please try to restrict your calls to the hours of 7 -10 p. m. on a weekday, 10 a. m. to 5 p. m. on Saturdays and Sundays. On the label of the envelope in which your copy of Tidings arrives there is a membership number. It would be useful if you could quote this in correspondence. It would give us a fighting chance when we get checks with no signature and letters with no name and address . . .

One last point and then I promise I'll stop moaning. There are 3 entities. There is Texas Instruments, there is TIHOME and there is 99'er Magazine. They are all totally separate and no connection with each other. While we all do our best, we are none of us responsible for the actions of the others. For instance, TI have published, in their software booklet, the names of all the programs held by all the User Groups in the world and labelled them "User Groups". This does not mean that software is available from every User Group. The only software available from TIHOME is that detailed in the Software Catalog.

Right, moan over, and now for the good and bad news. Arrangements have been made to give TIHOME members the ability to subscribe to 99'er Magazine on a yearly basis. A year's subscription will cost you GBP 31 . There is a form for you to fill in, in this issue of Tidings. If you decide to have the magazine, please return the form as soon as possible so that I can give the shipper his instructions. I think you will find the magazine really useful. Incidentally, it now comes out monthly.

A number of members seem to be under the impression that their membership runs from January to January. I have received a number of checks which were well ahead of their time. Membership runs from the date of your check to a year hence. Please do not worry about rejoining. I will write to you and tell you when.

I have recently been contacted by a new magazine, called Personal Computer News. They are ready to publish any programs or articles about any micro computers. Here's a chance! They do not want to end up with stuff for the BBC, the Sinclair and the rest of the popular micros. They want to scan a broad horizon. So, get with it, send them your articles and programs. Remember, magazines are user-driven, they publish what they get.

Do read TI News in this issue. I think you will find a lot of useful information there. We all know there are new computers coming out this year. So here's your chance to see what TI says about them.

Something for those of you that worry about such things. TIHOME does not claim copyright for anything published in Tidings, with the exception of three things. TIHOME claims copyright in the Editorial, the Close Routine and, by third party for Texas Instruments, for TI News. So you can send me anything you want. I will claim copyright in nothing you send. What I publish is purely for the information of TIHOME members.

God bless you Good computing Paul Dicks.

Go to top of page

100 PRINT AT (5,6):" LETTERS USED" 

One way to do it with TI Basic is to use the PRINT command as in the following example.
100 PRINT ::::::::::::::::::
::::: TAB( 5);" LETTERS USED"


We have got our words in the right place but what has happened to our display. It has disappeared off the top of the screen never to be seen again. We must therefore look for an alternative way to output our string. The only course open to us is to use CALL HCHAR. Try typing in the following program:

100 CALL CLEAR
110 FOR I= 1 TO 12
120 READ L
130 CALL HCHAR (5,6+ I, L)
140 NEXT I
150 DATA 76,69,84,84,69,82,8
3,32,85,83,69,68
160 GO TO 160

Now if we RUN it - Hey Presto! LETTERS USED appears just where we want it. What the program does is to go round a loop 12 times reading the value L in line 120 and printing the ASCII character corresponding to that value starting at position 5, 6. Each time we loop we increment the horizontal position by the loop counter so that the letters appear in a row. If we didn't do this all the letters would appear one at a time in the same place until we were finally left with a "D" on the screen. The data statement contains the ASCI I values for the letters we want to print. Note that 32 is the space character.

Well this method is OK but it does take time to look up the ASCI I values and type in the data. Is there a quicker way you might ask. Well I think there is. Try typing this in:

100 CALL CLEAR 
110 FOR I= 1 TO 12 
120 READ A$ 
130 CALL HCHAR(5,6+I,ASC(A$)) 
140 NEXT I 
150 DATA L,E,T,T,E,R,S," ",U,S,E,D 
160 GO TO 160 

Right if you're still with me let's take this one step further. Try:
100 CALL CLEAR
110 READ A$
120 FOR I= 1 TO LEN(A$)
130 CALL HCHAR(5,6+I,ASC(SEG
$(A$,I,1)))
140 NEXT I
150 DATA LETTERS USED
160 GO TO 160


Now the data looks just like a string that you would output with a PRINT statement. However this time we use the SEG$ a letter at a time. This routine also has the advantage that we do not need to know how many times we need to go round the loop to read all the data. This is automatically done for us in line 120 by use of the LEN command.

Well there you have three ways of doing the same thing. It's up to you to choose which one you want to use.

Now, how about going one stage further. Suppose what you want to output is continually changing. Maybe it's the score of your game or the height of your plane in the aircraft simulator program that you're writing. Whatever it is here is one approach.

100 CALL CLEAR
110 READ A$, B$
120 FOR I= 1 TO LEN (A$)
130 CALL HCHAR(5,6+I,ASC(SEG
$(A$,I,1)))
140 NEXT I
150 DATA SCORE, 0000


This prints the word SCORE near the top left of the screen 0000 is the starting value of the score. Now we want to simulate a score. We can do this by generating a random number which we shall call R.

160 R= INT( RND* 10) 

Now we must add this to the previous score and then convert it to a string so that our output routine can handle it.

170 B$= STR(VAL(B$)+ R) 

Just a word or two of warning. Make sure that what you want to output will fit into the space allowed. If it is too long the column counter will exceed the line length and the program will crash with a BAD VALUE error message. Also if the length of the output i. e. the score in this case, reduces in length then the last character remains on the screen. One way round this is to right justify the output, but I will leave that to you to sort out. Maybe I will give you the answer in a future "Helpful Hints".

Well that's all for now. Perhaps if you have any useful ideas or tips you could drop me a line so that I may incorporate them in future articles for Tidings. My address is under County Contacts.

Good luck with your programming. Alan Harrin.

By the end of December '82, his daily postbag equalled a full month's worth of mine, and his phone rang throughout the day during the holiday period (and during normal weeks can ring after 10 p. m.!), with requests for help and advice from erstwhile ordinary members of the public now afflicted with 4A-itis. (He managed to make time though to show me round some of the bigger brothers to the 99s which he plays with for a living - or maybe they play with him!)

At that time, membership of TIHOME stood at 700+and was rising in leaps and bounds. (Thanks to bad marketing strategy by TI, no machines have been available over the Christmas period, and the next shipment is not due until February '83 when the climb in membership numbers should continue!).

The commonest problem (judging by the phone calls) seems to be the Alpha Lock key and its effect on joysticks. If I heard Paul answer that one once, I heard him answer it a dozen times. Either lots of people haven't read the manual (which, I understand, is so full of bugs it would interest a microbiologist!) or the manual doesn't make the use of the key crystal clear.

Go to top of page

The cost of running TIHOME has turned out to be quite high, what with the cost of producing the newsletter (which would appear to compare very favourably indeed with all others) and back copies. While I was with Paul I learn that 99er, the specialist glossy from the States, has gone monthly, with an annual subscription of GBP 36, no less! Because of the format of these glossies (their high advert content, for example) they can usually afford to go out very much more cheaply than our Tidings, and I think that 99er's publishers ought really to reduce this price if they expect to make any sales on this side of the Atlantic. I can't see many TIHOMErs dipping into their money boxes at that price, especially since some have been unjustly treated in the recent past by companies purporting to supply 99er. I will be writing to Gary Kaplan in an attempt to clarify the situation, and I will report any correspondence as and if it arises.

I'm writing this Babble over two years - '82 to '83 - so although it won't actually appear until February, I'd like to propose a vote of thanks to Paul and Nicky for having steered TIHOME through another year, and for having taken Tidings up another rung in the ladder. Thanks are also due to the contributors in '82 who joined the Old Diehards (Mike, Stephen, and some scruff called Babbling) in staining sheets of wood pulp (writing, for those not familiar with my obscure style!), and '83 starts off with a handful of new contributors, of which more later. Here's to even more participation by you folks out there in '83.

Let me begin the Babble for '83 with a "notice board" of queries and requests passed to me from members. Nigel Clemons, of xx Seaxxxve Road, COVENTRY, West Midlands, CV1 xxx, is in the process of trying to convert an Apple II Algebra Checker (published in Personal Computer World in November '82? to run on the 4A. After much perseverance he has managed to get PCW to pass his request for assistance on to the author (one Mike Liardet), and has begun to produce a flow-chart for the program to help translate into TI BASIC. If anyone has any knowledge about the use of PEEK and POKE on the Apple II - i. e. how the memory map is laid out - would they like to contact Nigel and offer any help? (As I write, Nigel has had his second or third letter published by one of the popular micro mags - well done, sir).

Allen Burt, of Twyford, asked me if I could uncover the bug that exists in a 99er program (Vol. 1, No. 5) called SPRITER. The program keeps crashing and there is no apparent cause. I have narrowed it down through successive setting of BREAKPOINTS to something in line 980, probably caused by a CALL in another part of the program.

As I haven't asked Allen for permission to publish his address, would any member with a solution or comment like to write in to me (address given elsewhere) and I will pass anything on to him, and to TIHOMErs generally through these pages. All contributions acknowledged.

Through a friend I have learned that Debenhams in Swindon are keen to know if there is a TIHOME contact nearby to whom they could refer potential/ recent 4A owners. I have agreed to stand in for the time being, but I would be grateful if someone could come forward - I live some 40 miles away from Swindon, so I'm not exactly on the doorstep. If you don't feel confident enough to go it alone as a contact I am willing to give any candidate all the support I can. Any takers?

Ben Clewett, 11 year-old shortly-to-be-member from Oxford, has been helping me out in my favourite occupation, namely discovering things which TI don't know/ haven't released about the 99s. You may remember the last pages in December's Tidings giving some information about the use of the CTRL key with Extended BASIC to give some of the "tokens" used - some of them Reserved Words. Well, Ben and I have discovered that the same sort of thing is available with TI BASIC as well. You need to use a REM at the beginning of each line, followed by the usual space, and then you can type in the control characters to make up the statements as you wish. Which reminds me, a little while back Paul asked in the questionnaire if anyone wanted to see a Young 'Uns section in Tidings, written by young people for young people. Do we have any takers?

[Note: 2002: Ben tells me that he now programs professionally in c++under Unix. Another TI veteran in the trade.]

Still on the keywords, machine-code maestro Gary Harding has been also adding to the list using the FCTN key. I have yet to check them all out, but once I have they'll be added onto the postscript which 1 inevitably have to add to these ramblings. You will notice that Gary has also started a series on 9900 programming - this is intended for owners of the Mini Memory module, Editor/ Assembler, or Extended BASIC and 32K treasure chest, but if you're thinking of delving into machine code and haven't taken the financial plunge yet, then read Gary's articles to get the flavor, and maybe drop him a line to ask about specific points.

In fact, this issue sees contributions from a couple of people who have put pen to paper, one of whom is Gary, and another is Bill van Kerkoerle from Holland, who has offered me ready-translated copies of his articles for the Dutch magazine Tijdingen.

I have retyped his articles (there were 2, as he is trying to bring us up to date with his current writing) and edited them slightly, trying to retain the original flavor. If there is anything not clear, blame me, and write in to the address given elsewhere. Some of his points are being made in a different way in the Babble (and in previous articles, namely "FOR PETE'S SAKE"), and I think that it will be good to present alternative ideas on similar subjects so that we stand a better chance of reaching more members.

I will pass any comments/ queries on to Bill, who may later accept direct correspondence if I can persuade him. It is very generous of him to translate his articles into English for us, as I am not capable of doing the same for his group when I send a copy of my Babble over.

Another member to send in a contribution is Dave Hewitt of Hoddesdon, who relates a cautionary tale of micro-addiction. Incidentally, Dave is setting up an embryonic group in his area. Currently they number 3 consoles (who have remained nameless so far) and a few cartridges (modules, GROMS, cartridges . . . I wish TI would decide on one name!), and I have no doubt that they would welcome some more. They are currently advertising in the local rag for more to come forward, and although Dave hasn't given me direct authority to publish his details, I think he'd be pleased to hear from you at nn The Secccay, Hoddesdon, Herts.

Because of the extra contributions this issue (2 of which will be with us for a few more editions yet) I am holding back the final part of the 3D Noughts and Crosses and I am relegating "Sciencewatch" to be an occasional filler. The next item in the pipeline was to have been Video disks, but it can wait. If anyone actually was following the 3D OXO series, don't worry, it'll conclude next issue. The usual "Beginner's Basic" and "Re-introduction to Mathematics" are present, as is "Soapbox", with both the second part of the "Changing Times" article and a tirade on the subject of cables. This will no doubt be rounded off with a postscript as I add all those things which I forgot to put in this introduction!

Which reminds me, I am experimenting on odd occasions with placing characters which are restricted to use with CHR$() on the 99/ 4, directly in strings/ text on the 4A. I haven't managed to document all the characters available, but so far it looks as though 4A owners won't have to type CHR$(159) & CHR$(159) whenever they want to put those two characters on screen or in a string variable. I'm pressed for time these days, so it may be a little while before I have the full information (I still haven't found time to put the Hints and Tips booklet together yet, and at this rate I never will) but it will find its way onto these pages eventually. Before I go and forget it, I'd better give you my address (although it may also appear in the Contacts List):

Pete Brooks, nn Ffffurne Road, COWLEY, Oxford xxx xxx.
My work phone number is Oxford nnnnn, Ext. 335. If the Ansaphone is on, please feel free to leave any message. I'm not on the phone at home, so this is probably the quickest way to contact me should you need to.

Go to top of page

A couple of new micro mags have hit the streets this month, only one of which I have managed to pick up. It is called Micro Update and if you're looking for a very full list of just about all the micros on the already-packed market, this is the one to get. They have also published a full club list (as have others this month), but for some reason TIHOME has become a Surrey group instead of a national one!

Finally, if you want a list of educational micro-users, get a copy of Jan/ Feb. Computer Answers. Their list is far too long to reprint here, and I know that we have at least three teachers amongst our happie thronge!

A cautionary tale from Hoddesdon member Dave Hewitt. Mine is a sad tale, but true. I only tell it now as a salutary warning to others who may be tempted by the bright lights, fast-moving graphics, and slick product-pushing in the computer jungle.

I used to be your average Mr. Nice Guy - you know suburban semi, two kids, nice wife, a pleasant job wandering the streets of Hertfordshire plying my trade as an itinerant television repair man.

I well remember that fateful day last December when I first started down that slippery slope to micro madness. There I was, standing in W. H. Smith's minding my own business while my wife purchased the usual Yuletide wrapping paper, etc. Idly perusing, with one eye, the covers of ahem those magazines that are reserved for the top shelf, I happened to espy a portable TV with some display or other flickering and flashing on the screen. Seeking only to give the sales assistant some advice on how to cure this sort of fault on a portable TV, I ambled over to where he stood.

Too late I realised that this was not a malfunctioning telly, but one of Uncle Clive's magic boxes. In just a few minutes all was lost and I was hooked, a voice was saying: "American Express? That will do nicely, sir," and another poor soul was lost to the miseries of micromania. Still trying to put a brave face on it, I said to my wife: "Well, it will make a lovely Christmas present for the boys".

From that day forward nothing was ever the same; Christmas passed in a blur, the addiction and frustration intensified, Tell-tale signs began to appear: the glazed look that comes only after staring into a monitor screen hour after hour; hardened fingernails from assaulting a keyboard and worst of all the terrible mental anguish (understandable only by other addicts) when the program which you have just spent hours writing crashes.

Soon the ZX81 was not enough of a fix, and that is when sanity went clean out of sight and I started mainlining on a 99/ 4A. If you think that J. R. is the most sinister thing to come out of Dallas, then brother you haven't met Tex!

Now money seemed to be no object: "What do you mean, the kids need new shoes and the budgie hasn't had a square meal in weeks? I NEED the Extended BASIC module, and I've GOT to have it regardless of anything else. Yes, I know it was really a present for the kids, but I MUST finish that Alien Mother-in-Law Program, I've just GOT to."

Oh, yes, and then there is that sinking feeling in the pit of your stomach when your 10 year-old son looks at you sympathetically and says: "No, Daddy, that's not the way to write that statement, it won't run. Let me show you, it's easy."

So be warned. Before it is too late, go back to talking to the wife and playing with the kids. Stop talking to a flashing VDU or else people will shun you as an outcast. They do me, telling their children to turn their faces to the wall while the Micro Man goes by.

These may sound rather imposing, but once you understand what they mean in plain English (or as close as I come to it, anyway) you'll wonder why they seemed so formidable. The use of these functions is important in input validation, which we touched upon briefly last issue, and in particular the use of IF. . . is what gives the computer the ability to make what we would call a decision.

Take for example this instruction: "IF today is a weekday THEN go to work, OTHERWISE have a lie-in." No-one really wants to keep typing OTHERWISE in BASIC, so we use ELSE.

The restriction in TI BASIC (but not so much in Extended BASIC) is that you can only GOTO after THEN or ELSE, although you don't need to enter GOTO, just the line number (or DESTINATION as it is sometimes called).

The program is thus able to BRANCH by performing a "test" -i. e., is it a weekday? Yes or NO? Or, as the BASIC equivalent has it, TRUE or FALSE? If the response is 'TRUE, it IS a weekday", the branch will be made to the line number which follows THEN. If the response is "FALSE, it is NOT a weekday", the branch will be made to the line number following ELSE.

In fact, with this function, as with several others in TI BASIC, the use of ELSE can be "optional". That just means that if the line number which would follow ELSE is also the next line number in the program, then you don't need to use ELSE, because if the test has a FALSE result the computer will automatically follow on to the next line number if ELSE is not present.

We can use IF . . . THEN . . . ELSE in many circumstances. One use of it is in checking the response to an INPUT. if you remember, we can use INPUT in BASIC to stop the program so that the user can enter information (a number or a word or sentence). When ENTER is pressed, the computer will perform an initial check to see if the way in which any information entered is not correct - for example, entering 1. 2. 3 when a number is asked for, - but any further checking is left to the program (and thus the programmer).

Suppose we wanted to prevent our program from being used by anyone but ourselves. The kind of thing I have in mind is the use of a password. If the correct password is not given, the program will not proceed. Of course, this use of a password is more than a little tongue-in-cheek, as anyone with a little knowledge could break the program and find out what our password was, or even alter the program a little to avoid doing any such checking of the password: For example, try this small routine:

1 CALL CLEAR
2 INPUT "WHAT'S THE PASSWORD
?": P$
3 IF P$="TI ME KANGAROO DOWN
" THEN 4 ELSE 1
4 CALL CLEAR
5 PRINT "THE FOSTERS ARE IN
THE BILLABONG"
If you then RUN it, until you enter TI ME KANGAROO DOWN in exactly the way in which it appears within the quotes in line 3, the program will not reveal the location of the vital Australian tipple. It should be fairly straightforward to follow, but just in case, here is a blow-by-blow account:

Line 1: This is a special command which is available on the 99s to clear the screen, and which we first encountered in the last article.

Line 2: This is an INPUT (also covered last issue) with a "prompt" which is printed up on the screen, asking you for the password. If you press ENTER after you have decided on your response (perhaps it was DON'T GIVE ME THE OLD RAW PRAWN SHEILA), the text is then stored in a string variable called P$.

Line 3: Here comes the INPUT VALIDATION. This says: :If the contents of P$ is the same as "TI ME KANGAROO DOWN" then jump to line 4, otherwise go back to line 1 and continue the program from there".

Line 4: Simply clears the screen again ready to print the all-important information. Line 5: And this is where the golden brew is being kept. Suppose you wanted the user of your program to answer a question with either YES or NO and nothing else? (There is an easier and quicker way of doing this, as we shall see later in the series!) How might we go about it? Let's look at what we might need to do. First, we want an INPUT - an answer to the question (say, "Have you stopped beating your wife yet?") which we wish to pose. Then we want to store the response in a string variable. Then the validation can begin.

Go to top of page

We will need two tests: one to see if the response was "YES" and the other to see if it was "NO". If it was neither of these we will go back and ask the question again. (If we wanted to make it a little more complicated, we could, if the response was neither YES or NO, print out a short reminder, or reprimand the user for attempting to make an invalid entry!) Assuming that the program will proceed to two different sections depending upon the response, it might look a little like this:

1 CALL CLEAR
2 INPUT "HAVE YOU STOPPED BE
ATING YOUR WIFE YET ? ": A$
3 IF A$ = "YES" THEN 100
4 IF A$ = "NO" THEN 5 ELSE 1
5 CALL CLEAR
6 PRINT "WHY NOT, YOU SWINE!"
7 STOP
100 PRINT "AND ABOUT TIME TOO!"

See if you can follow the flow of the program, and RUN it, entering different responses, and see if you understand what it is doing. Note how stupid the computer is (or the programmer!) If you enter an answer like YES YES - it doesn't recognise that you have answered YES at all.

The '= ' in lines 3 and 4 is not used in the same sense that it is when you assign a value to a variable. In the case of "A$ = "WELL DONE, DUMMY!", or "A = A +4", you would get a better understanding of the meaning if you pronounced the "=" as "become". Thus: "Let the contents of A$ BECOME "WELL DONE, DUMMY!", or "Let the new contents of A become the current contents plus 4". The "=" does have its "equal to" meaning, but here its function is slightly different.

Here its role is as one of the RELATIONAL OPERATORS. There are a number of these, and they can be seen on some of the keys on the 99 keyboard.

There are just three operators, which can be combined to produce 6 tests. The '= ' is one, and the other two resemble letter Vs which have fallen over. The "<" is pronounced "less than", while the ">" is "greater than". In combination, they produce "<=" (less than or equal to - it doesn't matter which is put first), ">=" (greater than or equal to), and "<>" (not equal to). These operators can compare variables, or expressions (equations), and can not only be used with IF but can also be used in assigning values to variables, as we shall see. Let's recap on the full range of combinations, in case you haven't managed to disentangle them from the previous text:

A = B Equal to
A < B Less than
A > B Greater than
A <= B Less than or Equal to
A >= B Greater than or Equal to
A <> B Not equal to

If we wanted to restrict entry of a number, using INPUT, to being between 1 and 9 but not necessarily as an integer (so that 4. 15 would be a valid entry, for example), we could test to see if the entry was less than one or greater than 9, and continue or go back accordingly. The kind of test we will be performing is an "exclusive" one, which means that it tests for values which are excluded from the valid range. Our two tests will be "< 1" and "> 9", and the routine could look like this:

1 CALL CLEAR
2 INPUT "ENTER A NUMBER BETW
EEN 1 AND 9 " : N
3 IF N <1 THEN 1
4 IF N >9 THEN 1
5 PRINT "OK"
6 GOTO 2

Try running this program - if you enter an invalid number, the screen is cleared, and you are prompted again; if you enter a valid number, the computer responds with OK and leaves the screen to get slowly filled with questions and answers, and test it by using a range of numbers, both valid and invalid. Try altering the acceptable range of numbers to be say 5 and 50, or whatever you like.

We come now to the use of RELATIONAL OPERATORS, which involves the understanding of how the computer presents TRUE and FALSE.

PRINT 2= 2 

This should give -1 on the screen. This is the computer's equivalent of TRUE. It looks at the expression "2 = 2", and if the result is TRUE (and as 2 is equal to 2, it is TRUE!) the computer responds with a value of -1. If it is false, the value is 0.

To check this, try:

PRINT 2= 3 

You should get the answer 0, because of course 2 isn't equal to 3.

A= 5= 10 
B= A= 0 
PRINT A, B: 3*(A= B) 

The printout from this is 0, -1 , and 0. Can you see how it was produced? In the first line, the expression "5 = 10" is evaluated. It is false, so a value of 0 is produced. This is then assigned to variable A (NOT compared with it). In the second line, the expression "A = 0" is evaluated, which is TRUE, returning a value of -1 which is then assigned to variable B. During the printout, the values of A and B are printed, and there is also a small expression involving a comparison between the current values of A and B - they aren't equal, so a value of 0 is returned - and this is then multiplied by 3 and the result printed.

The expression "A = B" has to be placed within the brackets to ensure that the computer compares A with B, and not B with (3 * A). This is a common requirement, as the computer's mathematical rules are such that it could cause an incorrect comparison.

For example, if you wanted to evaluate A * (B +C) you couldn't simply enter A * B +C, as the rules for execution mean that the computer first performs multiplication and division before it performs addition and subtraction. This is a standard practice in mathematics. Highest priority of all, though, goes to expressions within brackets. They get done before any others. In a future edition of the Maths series we will look at mathematical hierarchy, and what it means.

Although it might not be resoundingly obvious, there are a number of uses for those relational operators and expressions, and I will leave you with one for next time. Your task is to try and figure out what this short routine does and how it does it!

What number will you NEVER see with an expression like this?
1 CALL CLEAR
2 A=A+1+10*(A>= 10)
3 PRINT A like this?
4 GOTO 2

Naturally, though, the sheer cost of putting together such a system will mean that most of us who want to write in Assembly Language on the 99s will utilise the Mini Memory's Line-By-Line Assembler. This is a pretty sophisticated tool in itself: it certainly beats Machine Code programming (working out the actual numbers which represent Assembly Language instructions and poking them into memory) as is much practised on other small computers. The one thing missing from the Mini-Memory package is a good 9900 Assembly Language manual, which is where this series - hopefully - comes in.

Go to top of page

Why?

I am not suggesting that Assembly Language is in any way the Logical Next Step for 99 owners to take. On the 99/ 4A, TI have provided a very powerful BASIC interpreter with excellent file-handling capabilities and easy access to colour graphics and sound, and for most tasks BASIC is the best language to use. However, there will be occasions (you may already have encountered some) when the speed of TI BASIC is just not up to the job, partly because of the way that programs and data are stored in VDP RAM (not easy for the 9900 to get at quickly) and partly because it is an interpreted language.

Imagine for a moment how long it would take you to get through a Russian newspaper if all you had was an English-Russian dictionary. Well, that's precisely the position in which your TMS9900 microprocessor finds itself when you run a BASIC program. In fact what you actually run is the BASIC interpreter, which reads your program as data.

It reads it a line at a time, looks it up in its internal "dictionary", and then executes the Assembly Language "translation" of your BASIC statement.

This process is slow - sometimes too slow. The only two ways round this speed problem are to get somebody to translate the whole Russian newspaper for you before you read it (this is what a COMPILER does when it translates a program from a high-level language into Machine Code) - or, more simply, buy an English newspaper (analogous to writing your program in Assembly Language directly).

There are problems with mixing BASIC and Assembly Language if you don't have the memory expansion (it seems to me that only 100% Assembly Language programs can make use of the new bit-mapped graphics mode on the 99/ 4A), but in general using Assembly Language to speed up time-critical operations is a good idea - and quite easy too.

What?

This is going to be the hardest part! What is an Assembly Language? Well, all microprocessors come with their own instruction sets with which they may be programmed - not quite the same as LET, GOTO, GOSUB, etc., but the principle is the same. However, as we are now operating at the lowest-possible level, the CPU (Central Processing Unit) will recognise only binary numbers as instructions, not the pseudo-English of TI BASIC. Unless we are to resort to Machine Code programming, what we need is another semi-English language that is easy to understand yet corresponds directly to the CPU's instruction set.

This - surprise, surprise - is what an Assembly Language is; the process by which an Assembly Language program is converted into the equivalent Machine Code (or OBJECT CODE) is called ASSEMBLY, which - wait for it - is what an Assembler does! It can't be that difficult, after all - even I can understand it!

Let's concentrate on our very own TMS9900 microprocessor. It has a fairly comprehensive instruction set consisting of 69 instructions, five of which are "external" instructions designed for use with TI's minicomputers and which have no effect on the 99s. The remaining 64 instructions fall into seven broad categories:

i) Data transfer - moving data around in memory
ii) Arithmetic - the basic four functions plus a few others
iii) Comparison - of data in memory with other data/ constants
iv) Logical - Boolean operations or setting/ clearing of bits
v) Shift - moving bit-patterns rightwards or leftwards
vi) Branch and Jump - including subroutine linkage
vii) CRU - forget about these for the time being!

I shall be running through the instruction set in future editions of Tidings, but there is a fair amount to get through before we get to that stage. The transition from BASIC to Assembly Language involves a lot more than merely learning a new set of instructions, as the way in which Assembly Language instructions are used differs considerably from TI BASIC.

Each instruction in an Assembly Language program corresponds directly with just one CPU operation, whereas the execution of a single instruction or statement in a TI BASIC program causes, via the interpreter, a sequence of many such 9900 instructions to be executed. This one-to-many relationship is what makes BASIC a high-level language.

The TI BASIC system also relieves the programmer of the responsibility for allocating storage space in memory for variables. It automatically reserves eight bytes for each numeric variable in a BASIC program, and allocates the requisite number of bytes (one per character plus one containing the string length) for each string variable, re-arranging memory as necessary dynamically, for example when two or more strings are concatenated during program execution.

When using Assembly Language, however, none of this convenient housekeeping is done automatically for the programmer (i. e., you); it's up to you to reserve space in memory within your program in order to maintain a set of variables. This is the main reason why Assembly Language programming takes more effort than writing in a high-level language - you need to have a far more detailed knowledge of what is going on inside the machine to be able to make full use of its facilities.

The basic unit of storage as far as the 9900 is concerned is the BYTE, although it is more usual to use a pair of consecutive bytes, termed a WORD. The CPU may address 64K bytes of memory directly, numbered 0 to 65535 with words starting at even byte addresses, i. e. 0, 2, 4, etc.

Many of the 9900 Assembly Language instructions come in two varieties to allow the same operation to be performed on both word and byte operands. What you store in a particular word of memory, and how you interpret it, is completely up to you as there are no pre-determined data types such as the numeric and string types in TI BASIC. Most of the commonly used 9900 instructions, however, assume that the contents of the words on which they operate are to be interpreted as 16-bit integer numbers.

Now, you're probably all familiar with the fact that the eight bits of a byte may be arranged in 256 different ways and hence a byte may represent any integer (whole number) from 0 to 255. Well, a 16-bit word can similarly hold 65536 (2 to the 16th power) different bit patterns and may thus represent integers from 0 to 65535.

These are known as UNSIGNED INTEGERS as they are all positive (oh, all right then, all non-negative! As you'll have no doubt noticed, these limits are the same as the 9900's addressing limits, which means that the numeric address of any byte in the 9900's 64K address space can be held in a single word. This turns out to be rather handy, as we'll discover later. Anyway, back to the unsigned integers.

In many circumstances it's useful to be able to hold negative numbers as well as positive - which is where SIGNED integers come in. If you've used the PEEK and POKE facilities in either Extended BASIC or the Mini-Memory, you'll have noticed that the range of valid addresses does not run from 0 to 65535 but from -32768 to +32767.

Go to top of page

This is because addresses are interpreted (unfortunately, in my view) as signed integers in what is called "TWO'S COMPLEMENT" form. Without going into too much detail, two's complement is a method by which those 16-bit patterns representing integers from 32768 to 65535 (i. e. those with the left-most bit set to 1) may also be interpreted as negative (signed) integers from -32768 to -1.

What it boils down to is that you can only hold 65536 different patterns/ numbers in one 16-bit word, but depending upon your interpretation of those patterns they can be either unsigned (0 to 65535) or signed (-32768 to 32767). And in fact this concept carries through to bytes as well: an unsigned byte contains an integer in the range 0 to 255, while a signed byte contains values from -128 to 127.

These integers, as you may by now have realised, are the only numbers the 9900 can manipulate directly with its instruction set. This may seem a little restrictive after the real (floating point) numbers available in TI BASIC, but for many programs you will find that integers are all that is required. And if you should want to use real numbers, then with both the Mini-Memory (in ROM) and the Editor/ Assembler (on diskette) TI provide a suite of Utility Routines which handle all the more complicated aspects of handling floating point numbers (e. g., arithmetic, and conversion to and from integers).

Okay - now I'm afraid we have to look a little bit deeper into how the 9900 holds its act together and actually executes these instructions that we've been hearing so much about. Just like any other kind of program, an Assembly Language program resides in memory, in RAM like the Line-By-Line Assembler which comes on cassette with the Mini-Memory, or in ROM like the TI BASIC interpreter in the 99/ 4A console.

Single instructions take up 1, 2, or 3 words of memory each and are executed in the sequence in which they appear in memory, unless of course a branch or jump instruction is encountered. At all times the status of the program being executed can be determined by examining the contents of the three 16-bit words called PROCESSOR REGISTERS. These actually live on the chip itself and are not part of the 64K address space of the 9900. All three are vitally important to the operation of the CPU, and need to be explained in some detail.

a) The PROGRAM COUNTER (PC for short) enables the 9900 to keep track of its whereabouts, figuratively speaking, in memory as it travels through, furiously executing instructions as it goes. The PC always contains the address of the next instruction to be executed by the 9900 and is automatically updated continually by the CPU, normally just by adding the address of the current instruction to its length (2, 4, or 6 bytes). If the instruction is a branch or jump instruction, however, then the PC is modified as specified by the instruction instead. In short, the PC is used to control program flow by acting as a pointer to the next instruction in the program.

b) The STATUS REGISTER (ST for short) contains, among other things, a set of flags which hold information about the result of the last instruction executed. Together with the 13 different jump instructions, the ST register makes it possible to program conditional branches in Assembly Language, similar to IF-THEN-ELSE in TI BASIC.

c) The third processor register is the WORKSPACE POINTER (WP for short), and this, as it introduces the fundamental concept of the workspace, needs so much space that I've decided to leave it until the next issue of Tidings. So don't go 'way!

Well, here endeth the first lesson. I hope I've managed to lay some kind of foundation for the rest of this short series of articles. If you think I'm making a pig's ear of it by making it too easy or too hard to follow, then drop me a line and tell me. Any feedback at all would be much appreciated, even if it's just to tell me to give up and go back to being a dustman!

My address is: Gary Harding, Flat n, nn fffmont, Lansdown Road, BATH BA1 fff.

My subject this time is a result of observing that often the length of a program is inversely proportional to its output. For those like myself not used to typing, shorter programs are a blessing and besides work faster and claim less memory space. Who hasn't come across "MEMORY FULL" through too large arrays, too little space for ASCI I characters, etc.?

Examine the market for RAM Expansion, and you'll come away disgusted with the price, but while more memory may offer greater possibilities, it may not be necessary if you optimise a program's use of memory. For short programs this is overkill I agree, but generally a good short program will eventually be added to, to make it multi-functional for example, and that is where efficient programming comes in.

On to part 2