In this issue:
Editorial      Articles by Mike O'Regan,      Pete Brooks, Using VCHAR and HCHAR; and    

Paul W. Karis - enhanced basic (with Personal Record Keeping module)- CALL D and CALL A

Comments by Stephen Shaw- book reviews: "Computer Programming in Basic, Peter Bishop" and "Using Basic, Rich Didday and Rex Page"

    TI News and finally of course, PostScript

Editorial
As you are all no doubt aware, the PAL version of the 99/4 is at last on the market. The effect on the membership of TIHOME, has been electric. From a membership of 19 a couple of weeks ago, the number has risen to 56 and is still climbing. We are, of course, delighted to see the machine in which we invested our money finally taken up by the market place. If nothing else it totally vindicates our original assessment of the 99/4 and its potential. TI are getting it right and we should all be thankful for that.

The increase in membership has brought its own problems. We have run TIHOME since September, 1980, on a non-subscription basis and were content to do so because of the limited membership. However, the situation is now different. Until the membership rises to a level where it becomes economical to print the Newsletter, photocopying is the quickest and cheapest method. Postage rates continue to rise. Tapes and disks need to be bought to maintain the master copy of the software library.

In the light of the above comments, we think we should warn our members that the introduction of an annual membership subscription payable in advance is likely within the next couple of months.

Two interesting things about the new members joining TIHOME are that at last we have broken the sexual barrier and now have two lady members, and new members continue to join from places as far apart as Hong Kong, Malta, various states of America, Holland and Australia. We can understand why someone in Malta should join TIHOME, but we would have thought that the USA was well supplied by its existing 99/ 4 Users-Group. It will be interesting to see whether foreign members continue to join once an annual subscription comes into effect.

I have decided to take my own medicine and use my TEEPEEWOPRO (Thermal Printer WOrd PROcessor to the uninitiated) Program to produce this page, at least for a trial periods for a number of reasons.

I am writing this in a series of disjointed sessions, gradually accumulating bits on tape and using the tape as a jotting pad. The idea is then to sort this out once a month, on screen, trying to keep the "random" bit, and finally printing on the TP and pasting up the bits to form a readable page. Incidentally, is there anyone out there ACTUALLY READING THIS STUFF!! If so let Paul have your comments and snippets for inclusion in the next Tidings.

Anyway, here goes . . .
Which Test Home Computers
Have You read the Which report on Home Computers (Part 1). I was quite impressed at the lucidity of this article which attempts to introduce the home computer concept to the layman, in my opinion with remarkable success. I look forward to Part ii, although it's a pity that our 99/4 has been excluded from the tests, especially as it was the first to actually call itself a "Home Computer".

I suspect we all know why it was left out!
Writing for the Computer Press
Ever thought about sending your latest masterpiece program to a magazine for publication? If you have, what happened! Did you stop short at just thinking about it? Well, so far I haven't seen a single 99/4 program published in any magazines and I read most of' them! In fact, I sent one to Personal Computer World some six months ago and only recently had it returned with a rejection slip. (I don't always get rejected, see PCW Vol. 3, No. 9). It seems a pity that a machine with a distinct lack of available software appears to be regarded as non-existent by the popular computer press!

Right, lads, let's flood 'em with program listings (with or without accompanying articles) just to show that there are one or two 99/ 4 owners out there.

Phantom Graphics
If you can stop reading this heady stuff for a few minutes then stagger over to the console and tap in the following short routine . . .

100 CALL CLEAR 
110 FOR K=24 TO 167 
120 PRINT K;CHR$(K);" ";
130 NEXT K 

I will not attempt to explain these weirdies (leaving that to experts like Peter Brooks). Notice that 24 to 29 "wiggle" and 160 to 167 are coloured blue - at least on my machine. Attempts at CALL COLOR for these phantoms are futile, as they do not fall into any CHAR set, and uses of these little chaps seem to be limited. However, try the following as a ready-made border to a title screen:

100 CALL CLEAR 
110 CALL HCHAR(1,1,30,32) 
120 CALL VCHAR(2,1,30,22) 
130 CALL VCHAR(2,32,30,22) 
140 CALL HCHAR(24,1,30,32)
150 GOTO 150 

Library Progs
I don't know if you have had any programs from our library. Having run quite a few (mainly of US origin) I must say that the quality, generally, leaves something to be desired. I know we got these free of charge (and for that grateful thanks to Charles LaFara). However, it appears that some authors haven't even RUN their programs before submitting to the library, otherwise such elementary blunders as running words off the end of a line would not occur! Some programs are first class - MATCH-UP, CARS AND CARCASES and VOCAB TEST are examples, but I object when for no apparent reason I am faced with "YOU ZAPPED THE ALIEN YOU JERK!"

. . . and More Program Thoughts
Have you ever tried converting a PET, TRS-80, Apple (or indeed any other alien) Program for your 99/4.
As a comparative newcomer to Basic, I have not had much success. Maybe one of you has a nice neat table of equivalent buzzwords in other dialects to some of the more peculiar TI Basic ones. If so, how about sharing it with all us lesser mortals by publishing in Tidings?

Your Friendly Neighbourhood Micro Club
I'm a member of Nottingham Micro-Computer club. Lately I have been wondering why! You see, in a club of 100 plus members, I am the only 99/4 owner. Now I am beginning to think that we (me and the club) have little to offer each other. After a couple of games nights at the club, with my 99/4 astounding all and sundry with speech, music and color graphics (not to mention the Five-A-Side Soccer module) next to Nascoms and ZX80s it seems that we are poles apart. It isn't even possible to swap programming hints or listings, so I will have to think hard before renewing my subscription next time around.

Go to top of page

Good Book
Programs in The A To Z Book of Computer Games work with a minimum of fuss and not a PEEK or POKE in sight!

Outputting text to the screen, without disturbing its contents, by using HCHAR or VCHAR, is also elementary, but I'm going to cover it anyway. That way I should stand a reasonable chance of pleasing some of you some of the time. I hope. I will also take this opportunity of providing a short explanation of a FLAG and its use, assuming that no-one else has done so.

But first, a silly cautionary tale about a programming genius not a million miles from this keyboard, and how the DEF statement caused his downfall.

Once upon a time, said genius writeth a program which useth said DEF statement to produce a marvellous function, and yea it wath . . . er . . . was a wondrous thing to behold (it says here). Said DEF statement appeareth in line 130, but not until line 210 useth he said marvelous function. And it cometh to pass that said genius RUNneth said program, and lo! it crasheth, and ye Great Operating System informeth him
"Ye hath made a boo-boo in line 210 with an INCORRECT STATEMENT, no less".

So, said genius searcheth and searcheth for getting on for an hour; checketh he the statement in line 210
- findeth he no INCORRECT STATEMENT; checketh he the DEF statement in line 130 - findeth he no SYNTAX ERROR, and similar.

Finally, in desperation, counteth he the number of brackets in said DEF statement in line 130, and lo!, there existeth one less left-hand bracket than should have done. So editeth he line 130, inserteth he said left-hand bracket, RUNneth he said debuggedeth program, and it worketh, and it is good.

So the moral of the story is - watch your punctuation in DEF statements, because the 99/4 won't.
Next, the FLAG. Apart from wrapping yourself in it, waving it at Royal Weddings, or having a pint at the Lamb And, a Flag serves many useful purposes in programming, and it is ridiculously simple to use. Like the ubiquitous Binary System, Flags are regularly encountered by members of the public and other mortals, without them realizing it. If Tom and Dick have rolled up outside Harry's too early on Sunday morning, the fact that the curtains are still closed acts as a Flag to tell them that Harry is still abed. In fact, anything that tells us whether something has, or has not happened, acts as a Flag. Flags can be either "Set" or "Unset". and they can be "tested" for either condition. In programming terms, you, the programmer, can call the Flag what you want, and you can Set or Unset it whichever way you like. For example, you could set your Flag (in this case a numeric variable, Z) thus:

Z=1 
And unset it thus: 
Z=0 

FLAG$=" SET" 
and unset it thus: 
FLAG$=" UNSET" 

Flags are usually used to indicate that a particular function has been performed, or a subroutine accessed, etc., etc. The classic use is in things like bubble sorts, where a Flag is used to indicate that a swap of adjacent elements has taken place; the idea is that you test to see if the Flag is set (i. e., IF Z=1 THEN) and if it is, you unset it and go back to the beginning (or go back to the beginning and unset it), and you keep doing this until the test shows that the Flag is unset, so no swaps have been made, and therefore the elements are in order.

If you are still in the dark, a future article on sorting may serve to enlighten you.
I have a program for three-dimensional Noughts and Crosses which uses HCHAR and string operators to output screen messages (e. g., Well Done, I Win, Go Boil Your Head, etc.), without disturbing the game board. I tend to prefer the modular approach to programming (or what passes for modular with my programming), so that my output routine is usually kept in the form of a subroutine requiring three variables to be assigned before calling. Those three variables are the text in question, the row number on screen, and the initial column number on screen. If we are highly original and call the row numeric variable R, and the column numeric variable C, and call the string variable M$, then, provided we observe some fairly obvious restrictions, things are pretty straightforward.
The subroutine is:

1000 FOR I=1 TO LEN( M$) 
1010 CALL HCHAR(R,C+I-1,ASC(SEG$(M$,1,1))) 
1020 NEXT I 
And the assignment would be of the form: 
200 R=16
210 C=2 
220 M$="DO YOU REALLY WANT TO DO THAT ?"
230 GOSUB 1000 

The restrictions are obvious, but I will state them all the same: this subroutine cannot cope with text that is greater than 32 characters in length (i. e., one screen line width), or with text that will not fit within one screen line given that the starting point (C) is a determining factor,, and don't forget to make sure that R lies on the interval (1, 24). To do the same sort of thing vertically, rather than horizontally, perform R+I-1 instead in line 1010, and if you need to, use VCHAR to remind yourself that the message goes down the screen, not across it.

When it comes to the graphics characters, it is a great pity that you cannot move a given character across the screen in 1/8th character width/ height intervals. The next best thing is to move the graphics SHAPE about: (i) within the "window" of a given character, and/ or (ii) by passing the definition strings, 1/8th at a time, across adjacent characters on screen.

The routines I have developed are not going to set the screen on fire with rapid Space Invader-type movement, but with care and a great deal of patience a reasonable degree of fine control over graphics can be obtained. When I can get around to it I will have a go at producing an Invaders clone program, but don't hold your breath. In the meantime I can try and explain the principles of operation, and perhaps give a few simple routines to demonstrate the effect.

In order to try and avoid confusion (wherever possible) in what follows, I should first explain what my terms mean. When I talk of "characters" I refer to the screen characters themselves (i. e., CHR$(32) to CHR$(159), although that is by no means the limit to the number of characters that can be put on screen).
A shape refers to whatever funny little creature appears on screen when a character is PRINTed or H/ VCHARed, etc., and a hex string or definition string is self-explanatory. A "transform" is the result of a manipulation of the definition string.

Go to top of page

Simple, straightforward motion (really apparent motion as only the shape moves, not the character) in one of two directions is obtainable by manipulating the hex string. Either you can just lop off pairs of hexcodes from either end of the hex string, and use CALL CHAR to redefine the character in between manipulations, in which case your shape will be very short-lived, or you can cycle the hexstring around - by which I mean take a hex pair off one end and tack it onto the opposite end - which means immortality for your shape. Let's put it on a more formal footing.

Given a 16-digit hex string, using SEG$ to obtain the substring that lies between the 3rd and 16th digits inclusive, and concatenating with that the substring which consists of the first and second digits, produces a transformed string, which, when used to redefine a character previously defined by the original string, causes the shape as it appears on screen to appear to scroll upward within the window afforded by the character, being followed immediately below by the part of the shape which has scrolled out of sight above.

10 points if you got that. On screen, it looks as though your shape is beginning to chase itself inside the character. Put your character over the entire screen with HCHAR, and some weird visual effects will be obtained. Use the aforementioned DEF statement to carry out the transform, and you could perform a transform after every statement line, so that the apparent motion becomes a little more even.
Here is a quickie demo program:

100 CALL CLEAR 
110 INPUT "YOUR HEX STRING ":H$ 
120 CALL CLEAR 
130 H$=SEG$(H$&"0000000000000000",1,16) 
140 CALL CHAR(96,H$) 
150 CALL HCHAR(1,1,96,768) 
160 H$=SEG$(H$,3,14)&SEG$(H$,1,2) 
170 CALL CHAR(96,H$) 
180 GOTO160 

You'll have to stop this program with the BREAK command; but you should now see that at least motion up and down under fine control is possible. No points for working out how to make the shape scroll down instead of up.
Now where do we go from here? One possibility is that because the transform takes a little while to perform, and it is faster to access elements of an array, it would be better to create all the possible transforms (8 in this case), store them sequentially in elements of a string array, and use the array instead of doing the transform during the program. Further, the CALL CHAR subprogram only uses the first 16 digits of a definition string when defining a character, so why not use a longer definition string, cycling the hex codes round in pairs, storing the resulting transforms in an array (first 16 digits only)? That way you could have a little army of shapes trundling around inside the character window, responding to commands entered using CALL KEY. Because the maximum string length is 255 characters, you could use 254 of them to control your shape movement.

So far we have covered movement up and down. Sideways movement is a little more complex, and really requires an article to itself , so I will leave that until next time. To round off this month's offering I will leave you with a few simple programming hints.

For example, were you aware that if you follow a PRINT statement with a semicolon print separator by an INPUT statement without any text in the INPUT statement, you get a question mark tacked onto the end of your PRINT statement? That means that you can incorporate much more text in your INPUT message, as well as, more importantly, string and numeric variables, and string and numeric operators.
And that provided the screen contents are not likely to be disturbed, you can use the screen as an extra array, storing information in it with HCHAR/ VCHAR and extracting it with GCHAR - use it as a two dimensional array with 24 by 32 elements - and I don't mean for storing complex information, just characters, or using their codes to provide information. I use the game boards on screen as the array which contains the moves made so far in my 3-D. Noughts and Crosses program.

Did you know that if you use the Relational Operators to compare characters directly with each other, you may run into difficulties? Comparing characters with codes less than 127 against characters with codes greater than 127 gives inverted results: i. e., testing CHR$ (A)< CHR$ (B) will give -1 if both A and B are less than 127, but if A is less than 127 and B is greater, it will give 0, which is wrong, so watch out. I often check out equations in the Immediate Mode before programming them in; the 99/ 4 doesn't possess the FRAC function (inverse of INT), but if you simply run a program which consists solely of DEF statements which produce your needed functions, e. g., DEF FRAC( X) = X-INT( X) and so on, when the program ends, your functions will still be intact, and you can call them up as required.

And finally, a little oddity: If in the Immediate Mode, with all variables cleared from memory, you type PRINT A, the 99/4 will print 0. If you then type PRINT A(1), you will get the error message NAME CONFLICT. The 99/4 has incorporated your numeric variable A into its variable list without requiring the usual assignment with LET. If you are daft, like me, you can create an overflow in the variable list just by using the PRINT statement, and end up with the MEMORY FULL message.

Good programming,
Pete Brooks

I think I must disagree with Mr. Brooks on naming variables - unless speed is important (it is not always) or memory space is limited (it is not always) the extra "readability" of variables having more than one character (!) is of use when debugging, amending, etc. If speed is of importance, there are a lot of tricks you can use before using small variable names. Memory use can also be reduced in many ways before reducing variable names.

An important way of saving memory space is to avoid if possible numerical arrays, or large numbers. For the former, much less space is reserved for string arrays, for the latter, it takes up less room (and can be quicker) to use a variable (e. g. AA=23456) if the number is used several times.

Price of the PAL version misquoted (I'm sure Mr Ashley has written?) - in a letter from Mike Lunch this was quoted as GBP 399. Have you written to the newer comp mags on the stands? I'm thinking of My Computer (yecch!) and Microcomputer Printout (no relation to a certain tame magazine).

99/4A - Sounds good but I'm persevering with my order for the 99/4 - I want one asap [as soon as possible], not in 12-18 months! I'm happy with the keyboard (apart from no number keypad) and don't like lower case in matrix format. Perhaps when my 99/4 wears out I'll be able to buy a super-duper 99/4A for about GBP 5.50?

But what Basic are Texas putting in the 99/4A? Will it be Extended Basic? or a third (slightly non-compatible) Basic?

Enclosed - copy Creative Computing ad for 99/4 progs - the more the merrier!
Has your Reference Manual fallen apart? Mine did, pages dropping out, limp cover, very limp . . . I've now rebound it in stiff covers, with the glued spine reinforced with linen thread. Should last for many years! [author's note- still hanging together over twenty years later].

If anyone wants their manual rebound, provided the pages aren't too badly damaged I could oblige - looks aren't much but the binding is strong. The reinforcement does mean the book wont open flat (which caused the pages to fall out in the first place . . .) The cost of materials is about a quid, (poster paper, cartridge paper, kraft paper, linen thread, PVA adhesive, card, muslin, texturised paper for the spine, hot foil tape for titling . . . plus postage of course. I have put the two most used appendix pages at the front of mine - reduces wear on the book.

I have also copied out the most looked up things onto a piece of A4 white card, and laminated it with that self-adhesive film you can buy. This will last for ages!

Go to top of page

Book Reviews
There are lots of books you can buy if you own a PET or TRS-80 or ZX80 . . . if you have a 99/4 you can read the manuals and then (after TIHOME . . .) . . .?

Two Basic textbooks, one British, one American, both based on ANSI minimal Basic, the American book looking at some extensions of ANSI Basic:

Computer Programming in Basic, Peter Bishop (Nelson, 140pp, �3.95, 1981) paperback. This is intended as a text book for CSE and O level [exams taken in 1981 by 16 year old-] students, and serves as a useful follow-on from TI's Beginning Basic manual. The book was written for use on a batch-processing ICL 1900 systems and its age shows - it is copyright 1978. The first chapter deals with the READ statement, as used in systems using DATA CARDS.
In the sample programs, the data cards are simulated with DATA statement lines. There are a number of exercises, but no solutions. Emphasis is placed on the use of flowcharts. All the minimum Basic commands are dealt with including single dimensioned arrays, in a simple but helpful manner.
The 99/4 is not limited by some of the ANSI Basic restrictions, but is fairly compatible - certainly at this level.

Using Basic, Rich Didday and Rex Page (West, 524pp, �9.20, 1981) paperback. Very strongly recommended. Worth buying for the chapter on sorting, this book (copyright 1981) is written in a user friendly manner, based on ANSI minimal Basic, but covering some of the commoner extensions. There are exercises and there are problems to solve. There are answers to many exercises.

Flow charts are dealt with, but this book introduces a new verbal flow chart which looks more useful.
There is a section on how to approach the problem of programming, and even a discussion of the moral problems arising from home computing. If you had no problems with Beginning Basic, this is the book for you - else read the Nelson book first - and do the problems!

Happy Computing

Stephen Shaw

1. Getting a printline
2. Getting an input anywhere on the screen

These are features of Extended Basic and they're respectively called PRINT USING and ACCEPT, but they are also available in TI Basic provided the Personal Record Keeping [ or Statistics ] module is inserted. This module, which is quite useful and versatile when used normally, permits you to use TI Basic statements CALL D and CALL A.

Of course you can also "PRINT" anywhere on the screen without CALL D by handling the PRINT character by character using the subroutine given in your manuals in the example program Character Definition. The drawbacks of that method are a) slow; the letters appear one by one; b) programming is more cumbersome and more memory space is used.

Have I whetted your appetites? I'll cut the chatter and get down to business.
PRINT USING - numerical data
CALL D(R,C,L,V)
R = row number of first character of print line
C = column number of first character of print line
L = maximum length of print line. Must be >= 1
V = variable the value of which is to be printed

R/ C The R(ow) and C(olumn) variables have a meaning with values between 1, and respectively 24 and 28 (the print field 24 � 28 is used). Values below the minimum of 1 (0 and negative numbers) are treated as the value 1. Above the maximum 24 or 28 are automatically subtracted as many times as is required to bring the result between 1 and 24/ 28 and this result is then used as R or C value.
This is a nice feature doing away with many program stops of "bad value" due to careless
programming.

Data at the end of a screen line is not printed at the beginning of the next screen row as is the case with the CALL HCHAR statement.
L The L position can be used with a fixed number (the maximum meaningful number is 28) or as a variable to which the function can be assigned in numerical data similar to SEG$ in strings.

V Instead of a numerical variable you can also put a number in this position that will then be printed on the screen in a position according to the rules above.

PRINT USING - string data
version 1: CALL D(R,C,L,S$)
version 2: CALL D(R,C,L,"PAUL W. KARIS")
version 3: CALL D(R,C,L,CHR$(N))

The variables R, C and L work as described previously. Here especially L can be put to good use as a built-in SEG$.

version 1: The string variable S$ is printed.
version 2: The string between quotes is printed.
version 3: Is a complicated way of saying CALL HCHAR(R,C,N) merely mentioned here as illustration of the possibilities.

ACCEPT statement - numerical data
The ACCEPT statement works similar to INPUT, but can be formatted anywhere on the screen. The input prompt can be printed in the appropriate place with the technique of ?. Further luxuries are the built-in value checks.

CALL A(R,C,L,F,A,MN,MX)

R, C and L have been explained previously.
F= function variable
A= accept variable
MN= minimum value
MX= maximum value

F The numerical variable in this position assumes a value 1-7 depending on certain function keys being depressed. The values connected to these functions in this way should not be confused with the ASCII values of these functions that can be useful in CALL KEY statements.

SHIFT C (CLEAR) will not only give F a value of 2, but it also clears the input printing field on the screen, and is to be used when typed input is not yet entered and ought to be changed.

WARNING: This means that if you write a program that continually loops to a CALL A statement, SHIFT C cannot be used to break the program. Only SHIFT Q or cutting the mains will work then, but erase your program in the process! The solution to this problem is to program your escape routine e. g. IF F= 3 THEN 10000 enabling you to use SHIFT A to bring the program to line 10000 which reads: 10000 END.

A The variable in the position of A assumes (accepts) the value you typed in much in the same way as the input variable does after you depress ENTER. The F variable of course then gets the value 1 since you have used the function key ENTER. In the case of pressing ENTER as the print/ input field contains no information (only "space") F gets the value of above table, if previously one of the function keys has been pushed.

MN/ MX
The numbers or the values of the numerical variables in the positions MN and MX respectively determine the minimum and maximum values that A will accept. A gentle beep when pressing ENTER from your 99/4 reminds you if you try to step beyond these imposed limits. The screen of course will accept any numerical data, provided that the length does not exceed L. (E. g. if L= 2 and MX=10000 you still cannot get A to become more than 99 as the screen will not accept more than 2 digits)

String data are not accepted by the screen at all when using CALL A in this way except (for reasons beyond me) the letter E.

Belonging to numerical input also the signs + (plus) and - (minus) are accepted.
If MN=MX, A will only accept the MN and MX value.
If MN> MX, A shouldn't accept any value at all but illogically it does accept the MN value.
Go to top of page

ACCEPT statement - with string data
CALL A(R,C,L,A$)
R, C and L are explained previously
F is explained in previously
A$ = accept string variable

A$ The variable in the A$ position is filled with the typed string information when pressing ENTER.
Epilogue
Surprised that you had all these possibilities and didn't know about them?
Or is it too good to be true as you were on the verge of buying an Extended Basic module for just this purpose?

Ah! You don't believe me, eh?
Be like that if you must. But try it out.
If you find more uses for CALL D or CALL A or even a third statement, I'd love to hear from you.
Paul W. Karis
Blauuuuas 2
nnnn AA Veenendaal
The Netherlands

Tel (010)-3nnnn516000

[Many years later a module was found which extended the capability of TI Basic when inserted, with an associated BASIC program dated February 1981. This used for example CALL TEXT(ROW,COL,STRING$). There were lots of other extensions including a very handy CALL MENU which handled display and choice input for a list of options. Nominally called ADVERTISER, found many years after the event in an Austrian shop that used to sell TI99/4As. added 2018.]

The 99/4 which we were using was plugged through an RS232 Interface and a Terminal Emulator to an Acoustic Coupler. Using this setup I was able to talk to TI's mainframes in Dallas, Texas via satellite.
Average response, there and back, ran at about seven seconds - very impressive what you can do with this, so-called, home computer.

I saw the Music Maker, Soccer, and Attack modules and can see how an awful lot of time can be spent playing these games. The color and graphics are extremely good. Text and speech is now included in the Terminal Emulator II for those of you interested in constructing your own vocabularies.

TI gave us some programs to add to our library which I will include in the catalog. Some of these enable speech construction to be done via hex string.

I was informed that Rumbelows will be marketing the 99/4 which prompts me to speculate that other chains, e. g. Curry's and Boots may also be interested. Because the 99/4 PAL has at last been introduced at a new low price, you should expect to see some advertisements, surveys and articles appearing in the computer press during the last few months of this year.

Postscript
Well, there it is until next time. This newsletter is later than I would have liked but what with holidays and TI getting the PAL version off the ground, I thought it was better to wait. I hope you find something of interest and use in this newsletter and please continue to write in with opinions, tips and computing experience. There have been no quotes from letters in this newsletter so we shall have to catch up in the next issue.

Best of luck,
PMD