TI-Lines Issue 2

Editorial comments

I was chatting to a pharmaceutical rep the other day at the hospital where I work, and from him I learned the Gospel According To Mike (Horwood-Smith). "If you invite 4,000 people to a meeting, 400 will respond, 40 will say that they are interested, 4 will tell you that they are definitely coming, and one will turn up." Out of the 25 people to whom I originally sent the circular concerning the user group, 8 responded over nine weeks expressing a strong interest, and after the first issue, one sent me his stamps (and preferred to pay the total cost of the newsletter. However, while this is fine for those working, those at school and those unemployed might find it difficult to cover the cost - see later. The first copy cost 65p to produce, excluding materials and postage (i.e., photocopying cost was 65p), and I can see that future copies will become increasingly expensive. However, based on Mike's Gospel I don't expect that all 25 will take up the subsidized subscription, so I am quite happy to continue covering all but the postage cost for the foreseeable future. If the Elite Eight take out a subscription it will cost me the vast sum of about £6 a month - an amount which I (theoretically) earn from Home Computing Weekly for a week's software reviewing - and for the opportunity to shoot my mouth off in public once again, that is a small price to pay!

I've had one suggestion concerning the format of TI-Lines from fully-paid-up member Jan-Paul Nijman which agrees with my own idea, and that is to eventually produce the newsletter as reduction-Xeroxed A5 in a similar style to that used by Tidings (gone but not forgotten) and TI*MES. I've a feeling though that the cost could soar considerably unless I can put in an order for a sizable number of copies. That's something to look at in the near future.

Something else to look at will be the possibility of carrying advertising, which could eventually cover the cost of publication and thus place TI-Lines in the same league as the "free" newspaper. I have been compiling a list of software and hardware suppliers who might be approached once the group has achieved some stability, and I have decided to allow owners outside Oxfordshire to subscribe if they so wish. A number of the local American user groups mail their newsletters all over the world, and the material in them is largely concerned with local events, with little of the reference material which I hope to fill TI-Lines with during the coming months.

Some of you might have wondered where the title TI-Lines comes from. I came across it while reading a Texas manual on the 990 minicomputer series. It is an Input/Output facility on the 990/5 and 990/10 only, and the connection seemed too good not to make use of it. Any riveting alternatives will naturally be considered.

This second issue sees a continuation of the article on the CTRL and FCTN keys with a discussion of tokens among other things and the beginning of the Beginner's Basic which first appeared in Tidings. This series made reference to another which appeared in Tidings: the maths revision series which may, if necessary, be brought in to swell the ranks as it were. We will also be examining some of the data being produced by Richard Blanden, who appears to have delved deeper into the 4A than anyone before him. Later, if time permits, we will have an article concerning problems experienced with a continental TV by Graham Diacon.

Finally, there is a short questionnaire enclosed (with postage materials) which, if you are feeling helpful, you might fill in. All replies will be treated in the strictest confidence - in fact, once I have the necessary numerical data, I will be destroying the returned sheets. I look forward to hearing from you.

Beginner's Basic II

by Peter Brooks

Although TI manuals have a reputation for being comprehensive and well-written, it would appear that many owners have been experiencing some difficulty in following the explanations given. It may be that this difficulty arises because the manuals assume some basic understanding on the part of the reader, or, more likely in my view, that the majority of readers are not used to reading what amount to reference works. There is a degree of skill involved in sifting through and absorbing the small amount of information required from the mass presented. This problem was highlighted in a questionnaire sent out by TIHOME in 1982, in which many responses indicated that Beginner's Basic would need to be presented in a very elementary format, because many readers were putting the Babbling Brooks columns to one side against the day that they felt equipped to understand them. (Babbling Brooks was the title of a regular series which was comprised of several different items, all of them aimed at the novice user.)

In the light of that feedback I started the Beginner's Basic series, aimed at the novice user (yep, two novices). The Intention was not to replace the TI manuals, but to supplement them, as the same information, when presented several different ways, stands a better chance of being fully understood.

And if you think that my explanations don't improve matters, don't forget to write in and air your views. Back in the early days of computing, you really did need to be something of a brain-box in order to program a computer. The early machines were programmed in binary code, by setting banks of switches; a far cry from today's sophisticated machines, some of which allow you to program verbally, by accepting speech input.

Someone had a brainwave, and made life a little easier, by allowing programmers to enter their programs using either hexadecimal (base 16) or octal (base 8) code, through simple keyboards. Later, the so-called "high-level" languages were developed, and still are being developed. These allowed programmers to enter what amount to English words, and one of the early languages was Fortran (Formula Translation), a "scientific" language, from which Basic (Beginner's All-purpose Symbolic Instruction Code) was developed in about 1957 at Dartmouth College, USA.

Basic was apparently intended originally to help engineering and computer science undergraduates understand the principles of programming; a kind of "Janet and John" language which could be used to build up to the more complex languages used.

But, Basic proved to be so popular, precisely because it is so easy to learn and use, that it is still the predominant language around today, despite the fact that much more powerful languages have since been developed. In other words, it is as if most people are still using "goo-goo ga-ga" baby language as their main means of communication, which is a source of irritation to all academics and some of the "professionals". This is why you will see articles in the popular computing press which decry the amateur programmer and his Basic, and why you won't stand much chance of getting a job in the computer industry if you have only Basic under your belt.

To the average amateur, however, Basic doesn't seem much like a simple language, until they see programs written in Assembly Language or Pascal, or even Forth.

One hurdle that I found was that I couldn't grasp how the computer actually understood Basic. Most books will tell you that computers only "understand" machine code (which can mean binary code, octal, hexadecimal, or even something called microcode!). Even now, I have gained only a broad understanding of what goes on, and I have found that the key to understanding Basic is a little understanding of what goes on "behind the scenes" - in other words, how the computer "sees" things.

Go to top of page

To begin with, from the moment that we switch the computer on, programs are running. There is a program which prepares and produces the screen display, sending it to the TV together with instructions for synchronization. There is a program which checks the keyboard to see which keys are being pressed and what should be done if any are. There are others which actually execute the Basic programs which you write, and yet others which handle the flow of information between computer and peripherals. Unfortunately, even today, very few details are available about the internal workings of the 99s, so one can only speculate in some cases about what goes on inside.

You can get an inkling of the volume of work being done by the machine if, after selecting TI BASIC, you turn up the volume of the TV (hopefully properly tuned to the right channel) when you will be able to actually "hear" the cursor blinking on and off. If you then press a key like ENTER for example, you will hear the tone change as the computer responds. Type a valid instruction like CALL CLEAR and enter it (and make sure it is correct or you'll blow your socks off with a deafening error tone!) and you can hear the machine at work.

When you enter something, by pressing ENTER or using one of the other entry keys: FCTN X or FCTN E (replace FCTN with SHIFT on 99/4s), the computer runs part of a program which compares what you have typed with what amounts to a list or dictionary of instructions which it can "understand". If it finds that what you have entered doesn't appear in the list, it runs another part of a program which deals with errors. Otherwise it will execute whatever machine code routines (and there are many) it needs to use in order to carry out the commands which you have issued.

When you enter a Basic program, there is a lot which you the user do not realize is happening. You type a line number followed by a Basic statement, and then press ENTER. The computer runs a general check to see if what you have entered is allowed by the rules which have been laid down by the designer. Try entering:

100 RUN

and see if it is accepted. TI Basic won't allow RUN to be used as a statement in a program. Assuming that the line you have typed is not replacing one which exists already, the computer then replaces all the reserved words (like PRINT, IF, FOR, INPUT, etc.) with tokens, which are single characters and therefore take up far less room in memory. Certain other symbols (like =, +, &, etc.) are also replaced. This aspect of the operation of the machine is being covered in Issues 1 and 2 of TI-Lines.

There are at least two facets to any attempt to write a program. One the language used - in this case Basic, which will be looked at in greater detail. later. The other is probably the most difficult thing to understand or to explain, and that is what it actually means to "program". I am handicapped by the fact that it is now 7 years since I first "learned" to program, and I find it very difficult to remember exactly what it was like before then.

I have yet to find a simple way of getting the novice programmer to realize that he or she has been programming for years without ever being conscious of it. If you have ever written a shopping list you've written part of a program. Every waking hour is filled with little programs which you have learned over the years: ones which make you get dressed before going out, which make you open your mouth before shoveling food in, which make you open a door before trying to go through it. In theory, anyway. This doing things the right way round is an example of something called an algorithm, a rule or set of rules which are used to achieve an objective, and is an integral part of any program.

I have tried giving programming examples which make people think: my favorites are of the smoking and shopping variety. You can write down the sequence of actions involved in lighting up, or in sending the kids to the shops for a tin of beans. The trouble is that while these illustrate the principles of programming and of logical thinking, they have no relevance to Basic, unless you happen to have a robot tacked on to your 99. The above examples are concerned more with the control of things, whereas Basic is more concerned with processing data.

A better example might be if I was to ask you to do some arithmetic for me. If I asked you to add four numbers together, how would you set about it? You might ask for the first number, and then perhaps write it down. You would then ask for the second number, and write that down under the first, and so on. Once you had the four numbers, you'd add them up, writing the answer underneath. You might then tell me what it was.

There are three separate actions occurring here. The first is input, the second is processing data, and the third is output. Things are not always so cut and dried, as you will come to find out. Sometimes processing halts for further input, sometimes there is no output, sometimes no input as such. But generally programs can be divided up into those three sections. The sequence has to be right, too, before the program will work properly. You couldn't give me the answer before I'd given you the numbers, for example.

* The input section is fairly obvious: it consists of you prompting me for the numbers, and me giving them to you when you are ready for them.
* The processing is also fairly obvious - it consists of you doing the adding up.
* The output consists of you telling me what the answer is.

Not all processing involves arithmetic, however; at least, not in the sense implied above. Suppose that I had asked you to sort some words into alphabetical order instead. Again there would be an input section, where you prompted me for the words, perhaps writing them down on individual cards. The processing this time would involve shuffling the cards around according to a set of rules (an algorithm, remember?) until they were sorted. The output might consist of you reading the cards out to me, or storing them away somewhere without reading them out at all.

In theory what you are supposed to do is to sit down and specify the problem that you want to solve, or the game that you want to play. You then write down as many of the steps involved as you can, elaborating where necessary. You go over this many times, trying to iron out errors, making sure that you have covered everything (which of course you never have), until you are satisfied that you have done all that you need to. You can then begin to write the program in the language which you have chosen.

What usually happens though is that you sit down at the console with a rough idea of what you want to do, and you begin writing, testing each little bit as you add it, until you have a program which works. Until you present it with something which it can't handle, in which case you now have to go right back to the beginning in order to find out what went wrong, and by now you've forgotten exactly why you did certain things, and you still keep getting INCORRECT STATEMENT IN 460, although 460 looks OK to you. At this point you wish you'd kept notes on what you have been doing, and the three scribbled comments on the back of an old beer-mat don't mean a thing a fortnight later, and you might as well throw the whole thing over and take up fishing. Nice quiet hobby, fishing.

If you've been bitten by the programming bug though, you'll be back, having been struck by a bolt of wisdom on platform 7 at Reading General, breezing into the house, commandeering the telly in the middle of Coronation Street, and four hours later you're looking out the flies and the keep net …

In time, if you are lucky, you will come to develop a programming style which suits you, and if you are really lucky, one which permits you to program with the minimum of hair-tearing. Don't expect this stage to be reached for quite some time, though, unless you are undergoing tuition. Or reading this series.

In the first part of this article we looked mainly at ASCII rather than at using the CTRL and FCTN keys, primarily because before you can discuss the keyboard scans and "active" keys, you need some basic knowledge as background. So far we have glanced briefly at the function of CTRL and FCTN in their roles as control and editing keys, and at their use to obtain tokens. The User's Reference Guide (URG) gives a list of almost all the control characters, but you may have been confused by the references to "Pascal" and "Basic" modes, and the two different sets of key-codes listed on page 93. Quite why there should be a difference between the two modes is not clear.

A "mode", in case you were wondering, refers essentially to the way in which the computer has been programmed to respond according to what it happens to be doing. When you are running a program, the computer is in RUN Mode and will not respond in quite the same way as it would in Immediate Mode. Immediate Mode is the one you get when you select TI BASIC (or EXTENDED BASIC, for example) from the Master Selection List. It means that the computer will respond "immediately" to certain commands, rather than storing them away for later execution (i.e., what happens when you enter program lines). For example, in RUN Mode, pressing and holding down FCTN and then pressing 4 will BREAK the program. The computer will then re turn to Immediate Mode. However, if you perform the same key presses in Immediate Mode, the computer will "ignore" any instructions which you have just typed (but not ENTERed), and present you with a fresh line ready for another command.

Try this: Get into Immediate Mode, making sure that there is no program currently resident. If necessary type NEW and press ENTER. Then press and hold down the CTRL key and press these other keys one after another:

, (comma), the letters A to Z, . (full stop), ; (semicolon, = (equals) and the digits 8 and then 9. Release the CTRL key and press and hold down the FCTN key and then press 4 to perform the BREAK.

The display will scroll up, a fresh "prompt" will appear (>, the "greater than" symbol), and the cursor will indicate that the computer is ready to receive instructions. If you had pressed ENTER instead of FCTN 4 (BREAK), the response would have been an error tone and the message BAD NAME - i.e., the computer would not have ignored what you had typed.

Basic Mode therefore is what you are in when using TI Basic, and Pascal Mode is what you are in when using the UCSD p-System which is available for the TI.

Now, thoroughly confused, you probably wonder what on Earth all those control characters which you have just entered are supposed to do. Last issue I gave two short, very similar routines to print out a screen all of the user-definable graphics characters (UDGs), and I mentioned that it was possible to use the CTRL key to replace one of the routines, which is what we have now done.

You might choose to simplify things and just use CTRL with the alphabet keys (A - Z); the intention is simply to provide a visual indication that any incoming program is being loaded successfully. There is a set of tables later which gives, among other things, a list of the ASCII characters 127 to 255 and, where possible, the keys to be pressed to obtain those characters on the screen (in a program listing, for example). In some cases, more than one combination of keys can be pressed, for example, to get the character whose code is 133. In some instances you may find that your keyboard gives slightly different results. Richard Blanden tells me that on his 4A FCTN Q gives ASCII 185 instead of 197, which means that his keyboard is probably decoded differently.

The lists contain more information - for example, the tokens, which we will examine a little more closely later - but our interest at the moment centers on the UDGs. Having placed them on the screen with the CTRL key, get a program which you have already recorded on tape, and begin the OLDing sequence (see The CTRL and FCTN keys last issue), just to see the effect.

Once your program has OLDed successfully, type NEW and press ENTER. The UDGs won't now be on screen. Place them there as described earlier with the CTRL key. Note that the "shapes" are still defined. Most, if not all of them, will be blocks of apparently randomly-scattered dots and lines, but what you are actually looking at is part of your Basic program. To digress a little (again), when you typed NEW and entered it, the computer didn't remove your Basic program from memory.

What it did do was to alter a "system variable". System variables are values referred to, and in use by, the computer as it not only runs your programs but also when in Immediate Mode, etc. Somewhere in memory the computer stores details about any resident Basic program: where it is currently stored, for example. One system variable holds the address in memory where the listing begins, another where it ends. If those two system variables hold the same value (so that the "listing" begins and ends at the same place) then there is no Basic program on board as far as the computer is concerned. NEW alters the "end of listing" variable, and if we had been given access to machine code as standard (PEEK, POKE and USR or similar), we would have been able to "recover" a program if we had inadvertently NEWed it.

Now, because the UDGs' definition area in memory, and the TI Basic program listing area, begin at roughly the same point (see last issue), we can "see", to a limited extent, what a Basic program "looks like", by examining the UDGs without re-defining them. Again, had CALL CHARPAT() been included in TI Basic, we could have obtained the current definition strings for the "undefined" UDGs, and thus examined part of the Basic program without using machine code commands. You can try this with the Mini Memory, but I doubt if it is possible with either the Editor/Assembler or Extended Basic + 32K RAM Expansion, because they don't make use of VDP RAM in quite the same way.

For example, take the Basic instruction OPTION BASE - disregard the 0 or 1 for the moment. When stored in the computer's memory, OPTION and BASE are "tokenized" - that is, ASCII 158 is placed in memory instead of the full word OPTION, and ASCII 241 in place of BASE. In two consecutive memory locations therefore are the binary equivalents of 158 and 241 decimal: >9E, and >F1. So what ? you might say.

Well, try defining a graphics shape to be "9EF1". You can do it very simply with say CALL CHAR(159, "9EF1") in Immediate Mode, and then use CTRL 9 to place the character whose code is 159 on the screen. The shape you see is OPTION BASE as it appears in memory through our "window".

Try translating other tokens in the same way, and then go one step further: take a simple phrase like "HELLO MA", work out the ASCII codes for each of the letters and the space, translate them into hex (the text is 8 characters long, and the resulting hex string will be 16 digits long) and then use that with CALL CHAR() to re-define ASCII 159. You should have arrived at "48454C4C4F204041". {ut the character on the screen with CTRL 9 to see what "HELLO MA" will look like when stored internally.


100   CALL CLEAR

110   DIM T$(128)

120   FOR I=128 TO 159

130   PRINT CHR$(I);

140   NEXT I

150   FOR I=1 TO 128

160   T$(I)="HELLO MA"

170   NEXT I

180   GOTO 150

The sequence runs like this:

1. Clear all the UDGs of shapes; come back into TI Basic.
2. Clear the screen.
3. Reserve space for a string array which has 129 elements (0-128).
4. Print all the UDGs in a continuous string.
5. Put the text "HELLO MA" into every element of the array.
6. Go back and do step 5 again until FCTN 4 (BREAK) is pressed.

If you leave this running for some time, you will notice one or two peculiar things happening. See if you can explain what they are and why they occur (answers next time).

Above all else, you should be able to recognize your "HELLO MA" pattern appearing over and over again in the UDGs, although it probably won't sit squarely in each character - it may overlap from one character to the next. You'll have to press FCTN 4 (BREAK) to stop the program running. Try different groups of letters to see the shapes that different words or sentences produce.

OK, you say, now what? I still don't see how to use CTRL or FCTN in my own programs.

Well, if you examine the CALL KEY() command in the URG, you'll see that with some keyboard scans the FCTN and CTRL keys arm "active" - they will return a number if you press a combination of either CTRL or FCTN and certain other keys - and in others they are not. If you want to provide some special keys to be pressed, to provide some options for the user, you could use "PRESS 1 FOR this, 2 FOR that," etc, or you could use "PRESS CTRL AND 1 FOR this, CTRL AND 2 FOR that," etc.

Because the TI use of CTRL characters is non-standard, they will not have the same power as an other systems, but they can be used to extend your range of keys for use as menu options.

However, it must be said that it is probably simpler and easier not to use CTRL or FCTN in this way. In menus, you are unlikely to need to use more than the keys A - Z and 0 - 9 for any program that you could write for the 99s.

Where CTRL does have a use is in listings. Instead of using the laborious (and space-consuming) CHR$() function (with or without loops) to manipulate the UDGs, you could employ the characters directly. For example, instead of:

PRINT CHR$(128);CHR$(129);CH
R$(130) : CHR$(131);CHR$(132
);CHR$(133) : CHR$(134);CHR$
(135);CHR$(136) : : :

You could shorten it to:
FOR I=128 TO 134 STEP 3
PRINT CHR$(I);CHR$(I+1);CHR$(I+2)
NEXT I
PRINT : :
But better to use:

where, obviously, you don't type C-T-R-L in full, you press and hold down the CTRL key and then press the key for the letter or punctuation mark shown.

Don't forget to make a note somewhere of the keys that you have used and in what sequence for reference, although you can edit any such line and replace "PRINT" with "A$=", and then encompass the following PRINT statement with quotes. You can then run a loop of 1 to LEN(A$), and PRINT the ASCII codes - ASC(SEG$(A$, loop, 1)); which will show you which characters are "hidden" in the listing. Next issue we'll use this technique to uncover some interesting things.

Note that after the first RUNning of any program containing the UDGs directly in listings, they will 'appear' in their re-defined form in the listing. Remember this when producing hand copy on any printer capable of reproducing the listing exactly.

We now come to a more detailed examination of the tables of tokens. I have arranged them by ASCII code and by alphabetical keyword. It might be useful here to stop and point out the difference between keywords and reserved words. A keyword seems to be, universally, the Basic word which is replaced by a token when listings are entered ("tokenization").

A reserved word is one which has been reserved for the computer's use and the user cannot employ them as variable names. In this respect, LIST, RUN, CON(TINUE), etc, are reserved words but not tokens, while LET, IF, PRINT, etc, an both key words and reserved words. (Just as you cannot have 100 RUN in TI Basic, you also cannot have 150 CON - 3000 or 1000 FOR IF = THEN TO ELSE STEP GO … 1100 NEXT IF!). The URG lists the reserved words, and in the tables here the keywords are given. Notice that there are even tokens for: + - / & ( )

etc, and that some key-codes are "unused". Under certain circumstances, if placed in a listing these will produce gobbledegook in TI Basic. Some do have a use in Extended Basic (see Stephen Shaw's list in Tidings) and others have some function but at the moment we know the function and not the language! Some of them are UPRC$, DAT$, etc, (related to me by Richard Blanden) and I have seen these before in a TI-990 manual.

This tends to support the belief that the 99/4 and 99/4A are cut-down versions of full-blown mini-computers, complete with mini-computer operating systems. (For example, in the File Processing commands, the file description PERMANENT is given, suggesting that there is possibly also a TEMPORARY description. The URG says that PERMANENT may be omitted as all 99 files can be considered permanent - if that is the case, why have PERMANENT at all? Because the minicomputer operating system from which the 4 and 4A system is derived uses PERMANENT and TEMPORARY?)

The use of CTRL and FCTN to obtain these tokens is of little real practical help when programming, but it is a tool with which to dig a little deeper into the 99/4A (but not unfortunately the 99/4, which has no CTRL or FCTN keys), without needing to expand it.

Although we will have articles later for those possessing the Mini Memory and the like, this initial foray is for those who have just the console and who want to play detective (my favorite past-time bar none!). In the table of tokens by ASCII code, you'll see that after ASCII 198 there are tokens but no keystrokes. There is also a block between ASCII 160 and 175 which also cannot be accessed directly from the keyboard. (If you find anything different, please let us all know.)

In the next issue of TI-Lines we'll look at ways of accessing these "indirectly" - some initial details are given in the tables - and hopefully play around with the effects of editing lines, and discover the devastating effect of ASCII code 0.

(Note: no spaces) and then press and hold down the CTRL key, and press U and keep it pressed to bring the auto-repeat into play. When you reach the end of the 4th line, when the cursor will stop and the machine will make rude beeping noises, press CTRL A and then ENTER. CTRL A gives "ELSE" which will serve as our "end of listing" marker.

We now have a TI Basic statement which is 4 lines long - or do we? CTRL U is the token for RANDOMIZE, and we have around 107 of them, so LIST and watch the longest TI Basic line you'll ever see. (Well, almost: "SEQUENTIAL" is one letter longer, but we can't get the token for it directly from the keyboard).

This is where life gets complicated. Type EDIT 1 and press ENTER. Eventually the screen will stop scrolling and the last word on the screen will be ELSE, but where is the cursor? ($64,000 question). Answer: Sitting over the "R" in "REM". Where is that? ($128,000 question). Answer: I don't know, but try using FCTN D to move along the line (wherever it may be) and watch the screen scroll up one line for every character sideways that you move the cursor. Bring the auto-repeat into play and be prepared for an all-time-great crash (not audible).

The psychedelic flashing, flickering colors and shapes you see are caused by the computer being forced to clog-dance through its own work area, upsetting the colors, "patterns", even the sprite descriptors. To get back to normality, exit from your "editing" with FCTN 4 (BREAK) and then type RUN and ENTER. If all goes well, your normal screen color should return and the shapes on screen (if they have been visible!) should resolve into normal letters, etc. I suspect that there may be a use for this. (You may suspect that I have a screw loose. I suspect that you may be right …)

If you possess a spirit of adventure, play around with this some more and let us all know what you find! [See 84:06:10. The CTRL and FCTN keys - Part 3. - Cyc Ed.]

100 REM A$ = "insert single CTRL/FCTN character here"
110 FOR L=1 TO LEN(A$)
120 PRINT ASC(SEG$(A$,L,1));
130 NEXT L
EDIT 100
100 delete "REM" to give A$ = "sequence"
RUN

In some instances, "unused" control/function characters have a use in Extended Basic, and there may well be additional language modules which employ further "unused" codes.

130 CTRL B
32 86 108 147 32 6 40 44 109 163 6 40 60 201 32 42 86 113 6 40 62 86 32

186 FCTN /
54 191 163 226 245 63 6 55 127 210 74 118 247 92 179 94 183 160 206 191 118 177

Code sequences arising from the editing of indirectly obtained sequences to single characters (keyboard-indirect also)have not yet been investigated, but it seems very likely that all 256 characters can be brought into listings, thus avoiding the use of CHR$() and saving space.

Although the manual doesn't tell you so, the keys R, C, and E are "active" when you OLD and SAVE to cassette. You can, for example, type SAVE CS1 and press ENTER, and then press C, and the computer will act as if you have already been through the full SAVE sequence and now want to check the program which has just been SAVEd. This has the advantage that you can check a program which you already have on cassette and compare it with the program which you have onboard to see if they are the same (perhaps to try and avoid making duplicate copies of an amended program). On the other hand, you may have wanted to SAVE the program but been called away to deal with a major catastrophe (the dog's been sick in the washing machine, your eldest has just taken the ears off the guinea pig with the Flymo 6, and the cat from next door has just dug up the gerbil you carefully laid to rest last week. And the week before. And the week before that …) in which case you can press E and exit, just as if you had encountered an error and decided not to pursue matters further.

This is one of those tips which can be of immense use to some owners and of no use whatsoever to others. I've always found it very useful: I have this habit of not checking a program with C having SAVEd it, and this enables me to check it later when I suddenly feel uncertain about the reliability of my cassette recorder. In addition I occasionally use CS2 to SAVE programs (usually because I've either gone and typed the wrong instruction without checking what I was doing, or because I've had trouble with my CS1 RECORD lead), and to check it I then change the leads round (well organized, you see), type SAVE CS1, press ENTER, and then press C, which allows me to check the program.

Editor's note: There have been no entries for the bulletin board and no response to Gary Harding's request for assistance. If any member feels that they could be of some help, please don't hesitate to get in touch with me.

Don't worry if this leaves you with glazed eyes and gasping for air. It's a complex concept and I can't claim to be able to make the explanation easy. If you can't follow it at all, the solution is straightforward. Cough politely, and move on to the next article. Next month, try reading it again. And the month alter that. Until suddenly, you'll find bits dropping into place. You may even read a far more clearly explained account in the meantime. Either way, the exposure to it here will have paved the way.

Although you may not think so now, sooner or later you're going to take an interest in programming in machine code - if you haven't done so already. When you reach that point, it can help a little if you have already been exposed to some of the concepts involved. In fact, if you have Extended Basic, it can help to explain how NOT functions in statements like:

To begin with, we have to broach the thorny subject of the binary numbering system. We may be surrounded by binary systems (e.g., light switches: ON and 0FF - or, like mine, ON, fizz-bang! ouch! and OFF) but we are so decimal-oriented that counting in tens seems the only way to count. Until, that is, the day that number one son comes home, holds up ten fingers, and tells the family that he can count up to 1023 on them.

In the decimal or denary system, the digits 0 to 9 are used in combination to represent quantities. If you were brought up to think of numbers in this form:

The decimal number 123 is really one hundred plus two tens plus three units (a unit is maths jargon for one), or:

In the case of the headings above, each column is the base (10) times the value of the one to its right. Notice how it can be extended in both directions.

In the dreaded binary system, only the digits 0 and 1 are used in combination to represent quantities. The column headings are then:

Decimal 123 when expressed in binary terms is:
(1 × 64) + (1 × 32) +(1 × 16) + (1 × 8) + (0 × 4) + (1 × 2) + (1 × 1)

Generally, in computer terms eight binary digits (bits) are used at a time - a byte - and this gives column headings of:

The combinations of 0s and 1s will then range from 00000000 to 11111111, which, in decimal terms, runs from 0 to 255. (Work it out: 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1).

When it comes to treating these combinations in a byte as numbers and trying to perform a little maths with them (as you would when programming in machine code) a few difficulties arise. Firstly, for straightforward maths you won't be able to count higher than 255 decimal unless you begin to use short machine code routines to handle several bytes at once. (In the 99's case, there are special machine code commands which work on two bytes at a time, giving combinations of 0 to 65535.)

Secondly, you won't be able to handle fractions, nor will you be able to cope with negative numbers, so any subtractions like 4 - 6 will not be possible.

To get round this last problem, the use of a byte to represent a number is changed. Only 7 out of the 8 bits are used to represent a number and the 8th bit is used as a sign bit - to indicate whether the other 7 bits represent a positive or negative number.

We can now count from 0 to +127 (00000000 to 01111111), and with the 8th bit set, we can count from 0 to -127 (00000000 to 11111111).
However, life is never simple, and it is not as easy as that.
To show why this particular method of indicating the sign won't work correctly, try adding 3 and -3.
The result should be 0. Using the simplistic system just outlined, 3 will be 00000011, and -3 will be 10000011.

If you have any difficulty deciding how the result was arrived at, drop me a line and I'll give a shortie in a later issue on simple maths in binary.

So, how can we represent negative numbers accurately? The answer is confusing and complicated. There are two steps involved. The first is inversion, or One's Complement (otherwise also known as NOT). What you do is to produce the positive version of the number which you want to make negative. To get -3, then, you begin with +3, which is 00000011 in binary. You then make all the 1s into 0s, and 0s into 1s. This will turn 00000011 into 11111100. Are you with me so far?

Then you add 1 to the inverted bits. This turns 11111100 into 11111101, and to all intents and purposes 11111101 is -3. Note that the 8th bit is set to 1, signifying a negative number. This addition of 1 to One's Complement is called Two's Complement and is a very important procedure.

To test this rather odd-looking method of obtaining a negative number, let us again try adding 3 to -3. What we now have is:


       00000011

+     11111101

 ---------

    100000000

We have ended up with a 9 digit binary number. Har, har! I hear you say. So much for your maths. However, bytes only come in groups of 8 bits, and the 9th bit is actually "lost" - it is an "overflow" - leaving us with 00000000, which is zero in any numbering system.

Two's Complement takes advantage of this overflow and subsequent loss of the 9th bit. And no, I don't know why they call it Two's Complement when there is no 2.

Having got this far, let us examine some other combinations. What, for example, does 11111111 represent? The 8th bit indicates that it is a negative number, only which one ?

To discover this, we need to reverse the procedure involved in Two's Complement. We must first subtract 1, and then invert the result.

Thus 11111111 is actually -1! If you are not convinced, try producing -1 using Two's Complement.

Remember, get the positive form first: +1 is 00000001. Then invert (One's Complement): 11111110. Then add 1: 11111111.

What then is the largest negative number that you can produce? Earlier I said that using the first (and incorrect) method the largest value was -128. What does that look like in binary? Take +128: 10000000. Invert: 01111111. Add 1: 10000000. That may have caused a double-take, but it is correct.

So far we have examined just a few numbers. Is there an easier method? Well, in fact there is. If you look at the numbers again, see if you can spot the pattern:


Binary         Unsigned     Signed

number           decimal     decimal

00000011           3                 +3

11111101       253                 -3

11111111       255                 -1

10000000       128             -128

The "unsigned" values are those you get if you forget that the 8th bit is acting as the "sign". First, notice that if you forget the "+" and "-", the signed and unsigned values always add up to 256 - the rule of adding the signed and unsigned numbers to total 256 only works for negative numbers - you might have noticed that 3 + 3 has a hard time adding up to 256!

Second, notice that with the negative values, if you subtract 256 from the unsigned decimal value, you obtain the signed value. Or, to put it more logically, the negative value is 256 minus the positive value. Thus:

and so on. No need to go through all the Two's Complement process. To reverse the process, you simply subtract the unsigned value from 256. (I know it sounds confusing, but keep at it!).

Using Two's Complement, 103 in binary is 01100111; inversion gives 10011000, add 1 is 10011001 (which is 128 + 16 + 8 + 1, or 153), representing -103.

Having suffered all that, how does it help to explain how NOT works in Extended Basic? When used thus: A = NOT B

NOT operates as an inverter, giving One's Complement. If Two's Complement gives the negative value of a number, and One's Complement is 1 less than this, then NOT is equivalent to producing the negative number minus 1.

TI-Lines Issue 2 : May 1984

Editorial comments

Beginner's Basic II

Close File