Jump to:
This web page contains the text of articles for owners of the TI-99/4a from Issues 32 and 33 of TI*MES, Spring and Summer 1991. It is of use to users of the TI-99/4a emulators.
Program Design.
A good start on a non-trivial utility program for printing out TI BASIC or XB listings on an 80 column printer in two side by side columns which preserve the normal screen listing format.
If you just LIST "RS232.BA= .... " then the computer sends it out in DISPLAY/VARIABLE 80 format and it is up to you to tell the printer how to handle it.
Something approaching screen image format is only obtained (with extra paper consumption) with the printer margins set way in. 80-column printout beats none at all by miles but let's try to be fancier. If you don't have disk or printer then this lesson won't be of immediate use, but will still be a good example to work through as a programming exercise. We might as well do something useful.
First we figure out what needs to be done, and work out a set of procedures that can he CALLed as needed. The program will do only the minimum necessary to do the job properly. Bells and whistles can be added later. In one or two places we shall make provision for adding extras (bells and whistles have nothing on speech) by dummy subprograms which can be filled in later.
So let's start designing our program by deciding what do. We want the output nicely formatted on the page with margins, in 2 columns each in screen image (28 char/line) format. More columns (assuming the output device will handle them) are no problem -- once you can count to 2 then 3 is easy. Lines of Basic are not to be split from one column to the next or from one page to the next.
Some things commonly encountered in printed listings, such as indenting of FOR-NEXT loops don’t fit at all well with the multi-statement lines of XB (but might with TI Basic listings) so will not even be thought about here. On the other hand insertion of spaces before REM or SUB statements greatly improves the readability of XB listings, without doing violence to the idea of being screen list compatible. Page numbering is no big deal to add (a console only XB program can fill 6 pages).
At the other end of the business the LISTing to be printed is assumed taken from a disk file such as DSK1.LIST where it has been written by LIST "DSK1.LlST". A trivial difficulty easily taken care of is the blank first record written by LIST. The real problem is that LIST doesn't care about preserving XB lines as distinct entities. Each XB line starts out as a separate print record and if it is less than 80 characters long stays in one piece.
XB lines can easily extend into 2 print records and more (Basic lines much less frequently), but LIST places no markers to show which print records contain the start of XB lines. So if we are going to meet our specification that XB lines be treated exactly as in a screen list then something more subtle than a simple LINPUT is needed. There's one of our most important building blocks identified --- SUB BASICLINE(...).
Any utility program needs title and advice screens so there's SUB TITLES to keep all the details from cluttering the main program. The program will also need SUB CAPTIONS(...) to handle file and device name entry and print options which might be offered.
Now the real core of the program is the way in which it must assemble a whole page before printing anything because line feed moves ever on. So we need SUB PAGEBUFFER( .... l to take the output of BASICLINES, chop it into screen format hunks and decide where these are to be located on the page.
Then we need SUB PRINTPAGE(...) to massage the completed pages and ship them off to the printer. That about sums up the sub-programs that are called directly from the main program, and all that is necessary is to figure out the initialisation -- DIMs, default filenames etc etc, and to write the logic for program flow.
Before we start writing any code we should decide what utility sub-programs are to be used by those already defined. As the list is written into columns SUB WRITECOL(...) is a good candidate for repeated use, and SUB WRITEPAR(...) to take a line of BASIC and return it chopped up into 28 character lines to WRITECOL.
Since BASICLINE fetches the input records it is the appropriate place to detect End Of File. We might as well use PRINTPAGE to wipe the slate clean before writing a new page.
Let's dress up the input of filenames and Yes/No responses a little as SUB FILENAME(...) and SUB YN(...) , with SUB MORE(...) to end it all. Other useful utility sub-programs which will be included are SUB TXTCOL(..) to change display colors in one CALL, SUB KEYCON to carry the burden of "press any key to continue", and SUB DELAY(..) is always handy.
That about finishes the roster of procedures necessary to make up the listing program, and now the detailed coding can start after some thought on the necessary chains of parameter passing.
The principle that you should plan your programs from the top down and code them from the bottom up is just as valid in Extended Basic as it is in TI-LOGO or TI-FORTH where the form of the language makes it difficult to do otherwise. Sub-programs make it possible to go the same way in XB with ease. Less capable dialects of Basic make it a lot harder to keep your thoughts organised and your code on the rails.
The actual program will now be listed piece by piece and commented on in detail. The present program is actually a simplified version of the one originally written, but is powerful enough to do a useful job.
100 REM ** SIMPLIST **
The first part of the main program shown here sets default values and DIMensions the string array PRLN$ for two columns of 66 lines each. The top and bottom few lines will be left blank so that page format is obtained without sending printer control codes. A 66 line/page, 80 col. printer is assumed.
110 REM * PRINTER LIST *
120 REM ** FROM DISK **
130 REM FUNNELWEB FARM
140 OPTION BASE 1 :: DIM PRLN$(66,2)
150 REM * DEFAULT VALUES *
160 CALL TITLES :: SFIL$="DSK1.LIST" :: PDEV$="RS232.BA 4800"
170 CALL KEYCON
180 REM * NEW FILE ENTRY *
OPTIONS returns file and device names as entered there, and the remainder of line 190 resets the End of File flag, and throws away the first line of the list-file. At new page entry the page buffer is filled and then printed out repeatedly until it runs out of listing, and then it asks if you are finished. That's all there is to the main program folks. And now to the sub-programs that do all the work.
190 CALL OPTIONS(SFIL$,PDEV$):: ENDFILE=0 :: LINPUT #1:NEW$
200 REM * NEW PAGE ENTRY *
210 CALL PAGEBUFFER(PRLN$(,),ENDFILE)
220 CALL PRINTPAGE(PRLN$(,),PDEV$):: IF ENDFILE=0 THEN 210
230 REM * END OR NEXT *
240 CLOSE #1 :: CLOSE #2 :: CALL MORE(NM):: IF NM THEN CALL SPEAK("GOODBYE"):: GOTO 250 ELSE 190
250 STOP
260 SUB TITLES
TITLES here is little more than the barest stub, but you can fill that out to your own fancy. OPTIONS takes down the file names, does some checking, and opens the files.
270 CALL CLEAR :: CALL SCREEN(11):: DISPLAY AT(12,6)BEEP:PRINTER LISTING
280 SUBEND
290 SUB OPTIONS(S$,P$):: DISPLAY ERASE ALL :: CALL TXTCOL(16,5)
300 CALL FILENAME(1,2,"Edit as needed and ENTER","N?")
310 CALL FILENAME(4,4,"Source Fi1e for 1isting",S$)
320 CALL FILENAME(8,4,"Printer devicename",P$)
330 CALL YN(" Change mind ?","N",22,5,I):: IF NOT(I) THEN CALL HCHAR(22, 1,32,64):: GOTO 300
340 DISPLAY ERASE ALL :: IF S$="" OR P$="" THEN DISPLAY AT(1,2)BEEP:"NO INPUT/OUTPUT POSSIBLE" :: CALL DELAY(500) :: GOTO 300
350 OPEN #1:S$,DISPLAY ,INPUT ,VARIABLE 80 :: OPEN #2:P$, DISPLAY ,OUTPUT , VARIABLE 80
360 SUBEND
370 SUB PAGEBUFFER(PRLN$(,),EFL)
The new column entry in PAGEBUFFER resets the line counter PLN to top of page with a margin, increments the column count, and exits back to the main program if the page is full. If not it tells BASICLINE to fetch a new program line and WRITECOL to enter it in the page buffer. If BASICLINE says it has read the last line it exits and lets the main program worry about that, otherwise it gets another Basic line or starts a new column. A stub here, CALL SKIPLINE(NEW$,SK), could have uses.
380 REM * NEW COL ENTRY *
390 PLN=6 :: COL=COL+1 :: IF COL>2 THEN COL=0 :: SUBEXIT ELSE PRINT "":"** Reading column #";COL
400 REM * NEW PARA INPUT *
410 IF EFL THEN PRINT "":" ":"** END of FILE **":" *":"" :: SUBEXIT ELSE CALL BASICLINE(NEW$,EFL):: PRINT NEW$:""
420 CALL WRITECOL(PLN,COL,PRLN$(,),NEW$)
430 IF NEW$="END of COL" THEN 390 ELSE 410
440 SUBEND
If you have a disk system, and have a disk of XB programs which has a program called LOAD, your system will automatically load the LOAD program from DSK1 when you select Extended Basic.
It also kicks RANDOMIZE into touch, not only for the LOAD program but also for Any program that the LOAD program loads and runs.
If the computer manages to find a LOAD program, then your RND will always provide the same sequence every time you boot up, even if your program has a RANDOMIZE.
100 RANDOMIZE
110 FOR T=1 TO 6
120 PRINT INT (RND*100)
130 NEXT T
140 RUN "DSK1.LOAD"
and watch the six numbers repeat again and again, in defiance of the RANDOMIZE command.
Thus if you use a LOAD menu program to put in XB programs such as games or graphics or what have you, you may as well forget about RANDOMIZE... except...
70 CALL INIT
and now try it... see, different numbers.
80 CALL PEEK(-31880, [ , ])
90 CALL LOAD(-31808,[,])
( Yes Virginia you can use [ and ] as variable names!)
NOTE that you must omit the CALL INIT if it has already been used for example to load an assembly utility such as The Missing Link else you will destroy the utility! Call Init is also not required it you use the Triton version of XB titled Super Extended Basic on the module label and (c)1987 T PC.
Bruce tells us this fix can be attributed to Harry Wilhelm and dates back a couple of years.
UPDATE This bug has also been seen when LOADing from ramdisk, but appears to be dependant on specific TI99/4a consoles. The RANDOMIZE routine would appear to be making use of a memory address in the console which at some point was changed and using the disk LOAD may or may not interfere with it.
I somehow manage to find a pound (100 pence) and wish to purchase items which are priced at 14p, 17p, 22p, and 39p.
In what combinations may I purchase these items so that I exactly spend my pound?
We can quickly get our calculators out, work out the maximum number of each I can buy for a pound, and come up with code like this...
100 FOR A=0 TO 7
Can you follow the reasoning behind this code? This little program takes about 25.4 seconds to find the four possible answers.
110 FOR B=0 TO 5
120 FOR C=0 TO 4
130 FOR D=0 TO 2
140 IF 14*A+17*B+22*C+39*D=100 THEN PRINT A; B; C; D
150 NEXT D
160 NEXT C
170 NEXT B
130 NEXT A
We know our console is not the fastest in the world, so can we speed up this work? The first improvement is interesting- curious too. This simple amendment:
100 FOR D=0 TO 2
produces nearly a 10 per cent speed-up, and runs in about 23.2 seconds. Most odd.
110 FOR C=0 TO 4
120 FOR B=0 TO 5
130 FOR A=0 TO 7
140 IF 14*A+17*B+22*C+39*D=100 THEN PRINT A; B; C; D
150 NEXT A
160 NEXT B
170 NEXT C
180 NEXT D
We can however speed things up a great deal more by applying a little thought to the problem. If we buy a 39p item we have only 61p left which at most allows us to buy 3 items at 22p- in this case the C loop does not need to test for a value of 4. If we buy two 39p items we have only 22p left and can only buy one 22p item. The following code reduces the number of steps in the loop by taking account of this sort of limitation. The first line is slightly wasteful but will make the flow a little clearer:
100 FOR D=0 TO 100/39 ! think about it
This code would you believe gives us the same four answers in just 2.82 seconds or thereabouts.
110 FOR C=0 TO (100/39*D) /22
120 FOR B=0 TO (100-39*D-22*C)/17
130 A=INT((100-39*D-22*C-17*B)/14)
140 IF 14*A+17*B+22*C+39*D=100 THEN PRINT A;B;C;D
150 NEXT B
160 NEXT C
170 NEXT D
However we can still speed things up a little. Look at lines 130 and 140. Provided A does have an integer value our problem has a solution, and we can simplify this part like this:
130 A= (100-39*D-22*C-17*B) / 14
This improves the speed to around 2.24 seconds- about the time we saved with our first improvement. Just a little thought before coding a problem can save much un-needed work by the computer and speed things up to a degree which is greater than the difference between a 4Mhz computer and a 32MHz computer -all other things being equal, which they never are!
140 IF A=INT(A) THEN PRINT A;B;C;D
Thanks to Recreational and Educational Computing Newsletter Vol 1 #4 for the idea.
I became a founder member of the UK User Group, and by January 1982 had a program published in Computer and Video Games Magazine (still going in 1991 but no listings these days). I was also a founder subscriber to 99er Magazine, and was soon making my first purchase of modules from the USA, they were so much cheaper there than TI was selling them for here!
As the year progressed I wished to share the cassette software I was buying, and did the proper thing by establishing licensing arrangements and sold programs as Stainless Software, and so we went on... upgrading to a PEB and 99/4A in due course, continuing to write for anyone who wanted my material. modules from the USA, they were so much cheaper there than TI was selling them for here!
In due course, the collected writings were assembled into a book- I was asked to write it by a commercial publisher, who made the first payment before a word was written. WRITTEN ENTIRELY WITH TI WRITER, it brought in a little money, all of which was spent on new programs and books! modules from the USA, they were so much cheaper there than TI was selling them for here!
I love games, especially strategic games. I enjoy programming. And the TI has so many superb programs, so many languages to explore (still discovering new things about Basicl). I have a STACK o{ computer books full of programming ideas, and hundreds of programs to write, if I can ever find the time (anyone need programming ideas, mainly strategy or puzzle games?). modules from the USA, they were so much cheaper there than TI was selling them for here!
My TI has at this moment clocked up 11,044 hours, and has outlived the tv I bought to use with it! I am quite happy to go on using it for another ten years, even longer maybe, only an irrepairable breakdown is going to separate us! (By 2015 my TI ownership went back 34 years, and whilst my TI expansion memory was unhappy all else still worked fine.)
I have previously reviewed the earlier book, The Armchair Universe, and this one follows on from that, but this time the articles are heavier and do not have the simple algorithms to give us fast graphics output.
This is rather a set of articles loosely connected to computing, the reading and understanding of which just may help you to resolve computing problems faster or easier.
Something of a recreational math book. Some of the chapter headings include:
Error correcting codes; karnaugh maps; the fastest sorts of sorts, the chaitin-kolmogoroff theory... This book is intended as a semi-popular compendium of computer science rather like a touring bus visiting selected landmarks of computer science. You have been warned!
This 1990 book is a little easier to take, it has a few easy to translate algorithms to turn into programs, and in theory 16 out of 28 chapters could give rise to a program of some sort, although some could be hard to sort out! Once more lots of general reading to improve your approach to problems! Including even a mention of transactional analysis; other headings include:
balls in boxes; trains of thought (some classic recreational math puzzles); palmiters protozo; catching biomorphs.
THIS book is a collection of recreational material that was previously published in Scientific American under the heading "computer recreations".
Well that it the worst thing about this offering out of the way anyway, with a high score of zero out of ten for the name (unless you are German, or speak the language, when you will know the title is BRICKS). This program was written in an English speaking country (sort of) for sale in same. No excuse.
It is a Breakthrough type program- where you move a bat at screen bottom and a bouncing ball batters away at a wall of bricks, and if the ball hits the floor it is lost.
Not original. However the IMPLEMENTATION is absolutely superb, well up to modern arcade standards, with the ball and some bricks throwing shadows on a patterned background. Bricks take one two or three hits to knock out, and may drop one of six different bonus prizes, which make your bat bigger or affect the ball in some way. There are also some bricks which cannot be destroyed.
The game comes with an assortment of fifty screens (made up of different patterns of bricks) and there is an editor to make your own up.
Game play is with joystick one for one player. Editting can be with joystick one, or with more control (eg slower) with joystick 2 or even ESDX keys.
The graphics and implementation of this game are exceptional.
You may not be playing it none stop for the next year, but it is an excellent game to while away an hour or so every now and then, and contemplate just what our ancient machine is capable of... and was capable of in 1980. Why didn't TI release modules of this quality! Highly recommended.
This program originated with Great Lakes Software. It is quite old, and rather shows its age. Basically you key in your data, and have a few graphing options. Graphs can be printed out in a single format, and CANNOT BE SAVED TO DISK! in any format.
A little restricted perhaps, but there are not many graphing programs available, and this new price isn't bad.
A graphics utility program with several options, none of them very fast, but quite useful for all that.
Dating back to 1987, this program is by Rodger Merritt, who runs Comprodine. The program disk has several utilities...
BANNERS... to print instances up to 12 lines high and/or text in a specially supplied 8 inch high font, sideways, much enlarged. You get to choose which ASCII character represent a "pixel" so there is plenty of room to vary contrast. Banners seen at Romiley and Chester AGMs were prepared with this. Instances can be text prepared with any TI Artist font of course!
INSTANCES... can transfer a TI Artist instance into an XB program, either as redefined characters or as defined sprites. The output file is a merge format DV163 file.
TI WRITER... and you can save instances to disk in a format which prints out via the TI Writer FORMATTER (uses a lot of >TL's). If you need the program, you need it!
This is again a rather old program, which allows you to fill an A4 sheet of paper with a computer produced certificate, with a choice of borders, a choice of graphics, a choice of fonts, and a choice of signatures (perhaps Mrs Thatcher is no longer appropriate?). There are support disks available from both Comprodine AND Notung with extra fonts etc etc.
If you need to produce certificates, this is the most directly applicable TI program, and pretty inexpensive too!
About US$10 from Comprodine
JOYPAINT came out about the time TI Artisti did, but sold for a great deal more -more than twice the price.
You already know of my interest in graphics, and I quickly got a copy, only to find it was entirely unusable, not due to a bug in the program, but due to poor design- it was used by means of icons on the far LEFT of the tv screen, and on MY tv screen, those leftmost columns were invisible!
My old tv having died, I now have a super mono monitor from MCGS, which allows me to SEE those left columns, and coming back to the program I fiin it quite delightful.
Joypaint uses a larger image print size than fits on the screen, and this is handled by windowing- as you move off to the side the whole picture moves! The Joypaint disk uses its own unique (large) image disk format, but JoyPaint Pal allows you to load and save TI Artist and Graphx pictures as well as Joypaint pics.
The usual graphic features are there, and Joypaint Pal even allows you to define your own fill pattern, although automatic fill is not supported by Pal, you can still produce a tight pattern manually- instead of painting a solid black you paint the pattern. Joypaint has more patterns than TI Artist anyway.
Joypaint does not have much in the way of fonts or instances, using instead a "clip and paste" idea rather like Graphx, although there is an on-board font just as TI Artist Vn 2 had (dropped from Vn 3 alas)
Joypaint has an OOPS reversal function!
At present prices, provided your tv allows you to see the far 1eft hand side of the picture, Joypaint is an attractive addition for the graphics user.
Games disk(s). US$15 plus postage $4
Notung Software, 7647 McGroarty Street, Tujunga, Ca, USA, 91042
Apart from some new scenarios for the Tunnels of Doom module, this seems to be Ken's first games offering. Ken is a commercial artist and has many good graphics orientated programs for the TI user- naturally the graphics in this offering are superb!
As with all Notung software products, Ken will sell to you in your preferred disk format at no extra cost- if you have the minimum of SSSD then this product comes on two disks, else one DSSD disk. TI Casino requires joysticks, 32k ram and Extended Basic; a printer is optional.
Betting games are by no means unusual- some of the very first commercial offerings for the TI were betting games, whether we look at TI's ancient Blackjack and Poker module, or the very early cassette version of Blackjack from PRP Computergraphics.
What Ken has done here is to assemble eight betting games into one casino suite, so that you can move from game to game, taking your money with you, very largely under joystick control only.
The graphics are of a very high standard, card shuffles are rapid, and it is profoundly easy to lose money. If you have any winnings, you can draw your cash by means of a printed cheque! Graphics? Well, the cashier has a habit of winking at you...
The games are Blackjack (with doubling down, splits, and insurance); Roulette (with 0 and 00 on the whee1); Craps; Baccarat, Acey Deucey; Keno; Draw Poker; and a rather simplistic one armed bandit (no holds or nudges).
If you enjoy gambling games then you will enjoy this offering. If you enjoy well written programs, you will enjoy this!
Documentation? Outstanding. FORTY EIGHT PAGES. And you don't have to print it from disk- its ready printed for you. Not that you need the docs, but if you are not a casino habitue you may find the details helpful!
Numbers and punctuation are ignored.
It is written to be used with the Terminal Emulator 2 (TE2) moduleand of course requires the speech synthesiser peripheral.
Using TE2 we program in Basic, and cannot use the XB form of LINPUT A$ to read the text from disk. As some punctuation commonly found in text represents "end of record" when using Display Format files, we have added a comma to the INPUT line (130), which ensures that we miss no text. In XB LINPUT ignores the commas and so on.
Apart from the need for the comma after A$ there is nothing too strange about this little program.
As TE2 only "speaks" upper case we have to go through the string to alter it all to upper case, and for the purpose of the intended usage, certain characters are excluded.
Hope you find this of use!
Program to read a DV80 text file, which includes commas and uses upper and lower case characters.
Requires Terminal Emulator 2 module and speech synthesiser peripheral and will read a disk text file out loud.
Only regards A-Z and a-z, ignores numbers. Runs more smoothly if the text file is placed on a ram disk.
100 REM S SHAW FEB 91
110 OPEN #1 : "DSK3.FILENAME",INPUT
120 OPEN #2: "SPEECH",OUTPUT
130 INPUT #1 : A$,
140 IF LEN(A$)<1 THEN 130
150 PRINT A$
160 A$="__"&A$
170 FOR T=1 TO LEN(A$)
180 A=ASC(SEG$(A$,T, 1) )
190 IF A>57 THEN 220
200 IF A<>32 THEN 250
210 IF A<95 THEN 240
220 A=A-32
230 IF A=61 THEN 250
240 B$=B$&CHR$(A)
250 NEXT T
260 A$=B$
270 B$=""
280 PRINT #2:A$
290 IF EOF(1) THEN 310
300 GOTO 130
310 CLOSE #1
320 CLOSE #2
330 END
666 is also a PSmith, as it is Palindromic- the same backwards as forwards. It is not a Smith brother however as 665 and 667 are neither of them Smiths.
Remembering that prime numbers are excluded there are 81 Smiths between 0 and 2000.
Can you derive a program to list them?
Can you derive a 3x3 magic square containing only Smith numbers? That is with columns and rows and diagonals all add up to the same total.
The highest known Smith number has 3681893 digits... a bit beyond our machine perhaps... it has been proven that there is an infinite number of Smiths and PSmiths but the proof is awaited that there are an infinite number of Smith brothers ....
SPEEDING UP XB
Host of the material I have read suggests that removing REM/! lines and ! tails will improve execution time. It will, but not by very much.
A plain l TO 1000 loop took 10.6 seconds.
Adding either a REM or ! line INSIDE the loop increased execution time to 11.2 seconds. The same applied to a ! tail.
One of the things your TI does during pre-scan is to build a variable table. This is a table of all of the variables in the program and the memory location of each variables current value.
Each time your program uses a variable, it first searches the table for the variable and then goes to the memory location to find the value.
Our TI's list variables in reverse order. The first variable it finds in a program is at the end of the table and the last variable found is at the beginning.
I created a program with 26 variables and then used one of them inside the loop. Times were:
Variable used Run Time
Your TI finds your variables in either the order of use or whatever order you placed them in the pre-scan list.
First in program 19.0 seconds
Last in program 12.4 seconds
These results suggest that if you change the order so that infrequent1y used variables appear first and those that are used often appear last, your execution time should decrease.
To test this, I took a program that had the variables listed in alphabetical order. I rearranged them to reverse order of use. The results were impressive:
Variable Order Run Time
This step reduced run time 1.8 minutes or 12 percent. NOT BAD!
Alphabetical 14.3 minutes
Reverse use 12.5 minutes
Your TI also uses a line number table. This table is similarly in reverse order (first line last, last line first, etc). When you use a line number in your program (GOTO etc), your 99 must search the line number table to find the memory location of the line contents. Then it reads the line instructions, crunches them and executes.
I constructed a program that looks something like this
10 INPUT A$
20 FOR I=1 TO 1000
30 ! see notes below
40 NEXT I
50 RETURN
60 ! Lines 60 thru 2050 - 200 lines - are all REM lines , etc
2060 RETURN
2070 SUB A :: SUBEND
Run times depended on line 30:
Line 30 Run Time
GOSUB 50 took longer than GOSUB 2060 as the computer had to wade thru 202 lines to find line 50 in the line number table versus one line to find line 2060.
GOSUB 50 26.9 Seconds
GOSUB 2060 12.6 seconds
CALL A 15.6 seconds
Clearly, in long programs, put your frequently used subroutines and groups of code at the end of your program.
MINUTES OF ANNUAL GENERAL MEETING HELD 11th MAY 1991 Held in the MUSIC HALL SHREWSBURY AT 1.00pm.
Stephen Shaw in the Chair
Stephen Shaw welcomed members to the AGM, pointing out that all officers would be pleased to receive comments regarding the group activities, or to offer advice where required. He was pleased to be able to report that the membership levels had been maintained at a most remarkable level, when one considers that the manufacturer of the TI computer decided to cease production some seven years ago, and that some of the modules were copyrighted in 1978! Yet new programmes and equipment are still being designed for our computer, and anything available when TI retired from the home market is still obtainable through the group.
Much of this equipment is being demonstrated today, and if required could be purchased.
TI*MES is as strong as ever, and the reduction in the number of groups publishing magazines had meant that authors who had been sending text to them were now offering their work to us. As a result TI*MES can now be said to to be at least equal to the best TI mags in the world. He had examples of Micropendlum for examination, and would be pleased to arrange delivery for anyone wishing to subscribe.
Officer Reports:-
Stephen reported that use of the disc library had declined by about a third, which leaves us a little short of funds. If this continues, it will mean that he must either increase the charges or cease to purchase further programmes as they become available. Searching for and purchasing material is an expensive business, and the cost of a utility disc with programmes by several authors can cost from GBP 50 to GBP 60. The alternative is to exchange discs with other libraries, but this would not encourage the supply of new material into the TI world, and would therefore be counter productive.
Jim Ballinger recalled that during the early years since the Committee had been formed, the formulation and writing up of the constitution and the inevitable snags and amendments that became necessary, together with difficulties each officer met in sorting out their own field etc. made several meetings a year essential. In later years, such matters were sorted out, until last year only one meeting of the Committee was needed to decide on date and location of the AGM, together with the nomination of the officer living in the area involved, to organise this. Barring an unexpected problem, one meeting of the Committee should be all that is necessary this year.
Alan Rutherford reported a most satisfactory year, the total income was GBP 3402.31 including interest, while expenditure has been held to GBP 1375.45 thanks largely to the new terms secured by the editor for the printing of TI*MES, together with prudent expenditure by the rest of the Committee. As a result, the balance of group funds at the end of April 1990 - GBP 1812.07 has increased to GBP 3838.93 in April 1991. It must be pointed out however, that some of this increased balance is due to early re-subscription by many members, with the result that two years subs are shown in the 1990/1 figure in some cases. While it is accepted that increases in the costs can be expected, he felt that there was reason for satisfaction in the present position.
Peter Walker said that he regards the membership this year as most encouraging, when considered against the fall in membership experienced by many groups. During the year 42 members had moved to other machines, but the good news is that during the same period 38 new members joined the group. We are thus able to continue activities, produce our magazine and keep our heads above water, thanks to the efforts of Phillip and Stephen in publicising the group in the UK and USA respectively. We are going through the bulk of the renewal phase at the moment and 38 members who are due to renew at the end of June have not yet done so, and the present level of 166 members may drop then. Things do look fairly good however, and arrangements have been made for the USA members recruited by Stephen to pay their fees in dollar bills, as the cost of changing into Sterling in the USA almost doubles the cost for an American citizen! There are now 18 members of our group who are resident overseas. He reported that he still had a stock of past TI*MES Issues, although his recent offer of 5 issues at GBP 1 each had proved attractive. There had been litle activity in the Telecoms field, though he had done some work for publication, and would gladly give any help he could to anyone with a modem who would like to try exchanging programmes or data via telephone.
Nicky Goddard reported that at the January (Cuffley) meeting he had raised a total of GBP 75, including the raffle since when he has only taken one and a half per cent of that which he regarded as disappointing as things were going so well. He had brought plenty of cassettes to the AGM, and would be pleased to serve members present who were interested in a purchase.
Edward Shaw said that the Module Library had quite a good year, with total receipts of GBP 734.20, producing a profit of GBP 124.66. The stock of modules for sale now stands at 77, but the future replacements cannot be certain. The profit balance was transferred today (and so is not shown on the Treasurers account).
[ TI Book front page |
TI Resources Page
| PC99 Review
| PC99 Programs
]