Garbage Collection in Basic programs

Requires: Extended Basic and Expansion Memory.

April 1988

First an item for Extended Basic users with 32k ram... one of the things Myarc intended to include in their XB was a forced garbage collection, but they seem to have run out of room. It is really quite easy, but what am I talking about?
Type in this program and run it:
100 CALL CLEAR
110 A$="1234567890"
120 FOR T=1 TO 12
130 CALL SPRITE (#T,42,2,30+
T*3,30+T*3,0,34+T)
140 NEXT T
150 CALL PEEK(-31890, I ,H)
160 CALL PEEK(-31974,H,L)
170 A$=A$&A$&A$&A$
180 DISPLAY AT(20,15) : "FREE:"
190 F=(H*256+L)-(I*256+M)
200 DISPLAY AT(21,15) :F
210 GOTO 140
220 END

The number you see counting down is the free stack space- it is being filled with redundant definitions of A$ (line 170). When the number reaches/passes zero, you will see that it starts again from a high value- but at the moment of changeover, all your sprites will halt briefly.

During this brief halt, the computer is checking the stack to see what information there is redundant ( no longer required) and getting rid of anything it doesn't need- garbage collection.

Garbage collection not only causes sprites to halt but can also interfere with music, causing the odd note to sound for longer. Instead of having garbage collection occur when the stack is full - which can be quite often if the program is long and stack space short- it can be useful to force a garbage collection at a time we choose, when the effect may not be too obvious. Also, if we do a garbage collection before the stack is full, the pause may be quite a bit shorter.

Here's how to do it... insert the following lines into the above program:
95 CALL INIT
205 CALL LOAD(-31885,144,"",
-31858,81,169,152,0)

Now run the program again. Notice that the stack space remains constant, as we are forcing a garbage collection after each definition of A$. How is sprite speed affected?

Try garbage collection at an intermediate stage
204 IF F>10000 THEN 210

Any difference? Have fun. Thanks to the Sydney User Group (TIsHUG) in Australia for this one, taken from their newsletters for March and July 1987.

TI Logo Limitations- Sample Program: Animal

TI LOGO...

at last a LOGO query, and a very interesting one too... the LOGO manual contains an ANIMAL program. If you key it in and build up the KNOWLEDGE a little, say by adding three or four extra choices, as the program runs, then save it to disk.. you will find that RECALLing the procedure will lock your console up.

On Page 7 the Logo manual, you can find the information that input lines are limited to 127 characters.

Here is the clue! Basic program lines are also limited to 127 . That is 127 bytes after tokenisation has occurred, which is why you can sometimes key in less than the 5 screen lines XB allows you and still get a LINE TOO LONG error message.

Back to Logo... as you play ANIMAL, the KNOWLEDGE LIST gets longer and longer and longer... and once it exceeds 127 bytes, it becomes incapable of loading back into the console. The file is just too long for the routine which reads the disk and places the definitions where they belong.

Once you have been playing ANIMAL for a while, if you wish to save it, you must first reduce the LIST attached to KNOWLEDGE to under 127 bytes. You could do this in immediate mode or write a routine to do it- perhaps call it 'RESET'

Demise of Turbo Pasc 99

TURBO PASC 99: in the last issue I mentioned Tex**** as a supplier of TurboPasc 99, a superb language for the TI99/4A, copyright June and August 1986 by an Austrian software house with rights now owned by a German company.

Tex****** advise that they no longer wish to offer this program.

Yes, a superb language, now 22 months old, and with NO distribution in the USA, Canada, the UK, Australia, France .... available only to a small (very small) fraction of TI users.

Historic Note: In view of the news given above, I will not here reproduce the four page Turbo Pasc 99 program that was printed in this issue of TI*MES. I had written a nifty version of Game of Life, which I based on a listing in a book by Scott Vincent.
The Internet records that one of the European companies involved with TurboPasc99 was involved with some form of legal action which it lost, although I have only just found this out, and the Internet is not always right.

Myarc RAM Card partition limitation

MYARC RAM CARD:

Why can you only use 400k of the Myarc ram card for disk emulation (as a ram disk)? Because the disk usage is BIT MAPPED into an area of the disk which can only map 400k.
There is no room to map more- if you want a bigger disk you must use a different mapping system- either increase the area in which the bit map is held, or allow a "floating" bit map on an 'as required' basis.
That would mean you would need a new disk controller- your ram card would not be strictly compatible with your old software!
Myarc were right to stick to 400k. The remainder is available for print spooling, and for your operating system to use as part of the normal computer memory map area.

fortran for the TI99/4a

FORTRAN from Tenex.

George Michel reports as follows:

I have the LGMA FORTRAN discs and I have succeeded in producing working object programs .... I concluded that the LGMA discs apply to a very powerful extract of the ANSI 77 FULL language, and is not to be confused with the ANSI 77 SUBSET.

The beauty and speed of the TI99/4A is brought out by the Fortran program. There are of course limitations such as:
having to write a lot of subroutines because the compiler cannot handle large programs;
requiring a deep pocket to stock up with printer paper;
having sufficient interest to find out how the IBM mathematicians brains work, etc.

It is perhaps worth mentioning that assembly language subroutines may be called on as well as Fortran subroutines, thus widening the applications field considerably.

Basic Tip- On Warning Next and Input, and Using On Error

EXTENDED BASIC PROGRAMMING TIP Courtesy John Seager

Using ACCEPT AT for a numeric variable, how do you idiot proof it so the program will not bomb? You can insert a default input value, and use a negative size, and also use VALIDATE.

However, the user CAN blank the default variable with CLEAR, and if the input variable is a numeric variable, trying to input a blank will cause an error condition.

I have frequently seen authors input all numbers into a string variable. Inputting a blank does not cause an error, and you can test for a nul input and go back if required.

You don't have to do it that way. John points out that using ON WARNING NEXT will test for the nul input and go back for you. Try it.

eg
100 ON WARNING NEXT
110 ACCEPT AT(4,5)ERASE ALL VALIDATE(DIGIT):A
120 GOTO 110

John also mentions that if you program:
100 ON ERROR 600
110 RUN "DSK1.NOFILE"
600 ON ERROR 600 :: RETURN

the RETURN will fail as the failed RUN seems to remove the internal pointers.

This is a deliberate ploy by TI to avoid the "accidental" removal of the List Protection flag- which happens with Version 100 of ExBas.

You need to use the format RETURN XXXX where XXXX is a line number to go to which will RUN your original program again- you could use RUN 100 or something if required. The second RUN will of course reset all required pointers.

Ian Martin

We regret the sad and sudden loss of Ian Martin, who died in February 1988, following a car accident. Ian was the proprietor of TIMELESS SOFTWARE and was responsible for the UK retail sale of DIABLO and other classic XB games. Ian was an avid adventurer and spent much time with the Infocom series.

Comments made about Rambles

A recent committee meeting of your Group felt that the presentation of Rambles left a little to be desired. Therefore THIS copy is being contributed unpasted with ALL print in a standard font - ELITE - and double struck for as much density as my printer will allow! If any pieces are MISSING, they have fallen out from the paste up stage, letters to the Editor please.

In this issue you will see news of the forthcoming AGM ( I hope!) - which offers a good chance for TI users to get together and have a chat, AND to express their wishes for the future of THEIR User Group.

Would you like a more professional magazine, either for higher subs, or with less content? Would you like any surplus funds used to make such improvement or for an extended subscription next time or held on to to prolong the group as numbers inevitably drop? WHERE do you wish us to go? Do come and express your views. If you really can't make it, why not drop our Hon Sec a line and tell him what YOU want from the Group!

As a result of comment by non-members, the section dealing with exchange newsletters has been dropped from Rambles. If you feel strongly that I should make a brief list of newsletters received from elsewhere and brief details of what they contain, please write to me. The section takes up a lot of room and unless it is really wanted, we have other (less contentious) material for our Group magazine.

RAMBLES is intended as a friendly letter to a member of the family - the TI family -- YOU. There are PERSONAL comments and feelings and news - and as with ALL articles in TI*MES, these do not claim to be the views of the Group as a whole. I welcome YOUR letters in return, with news, views, feelings, whatever.

Remember - this Group is YOURs dear member! If you think Rambles is too long, or should not appear at all, drop a line to our Hon Sec, Jim Ballinger. And to those of you who so kindly write in and advise of your appreciation for Rambles, please accept my sincere thanks. Such letters keep me going.

This issue marks the 6th Anniversary of Rambles, which first appeared in the April 1982 issue of TIDINGS, although my first contribution to TIDINGS actually appeared in issue 2: March 1981 (Pete Brooks got into Issue 1). When Rambles first hit the streets less than 20 people read it! A lot of words have been used in six years - some of them, on reflection, a trifle shall we say... wrong! but TI never did provide us with much information. The earliest documentation I hold here is dated August 1979!

Additionally one reader took extreme umbrage at the magazine (ever since TI*dings issue one) carrying a notice that the group was "Not affiliated with Texas Instruments." This notice had been insisted upon by Texas Instruments legal department. Recall that TI encouraged the formation of TI Home which published TI*dings. As TI*MES effectively carried on the torch from TIdings, the message was repeated, although the contemporary TI Lines did not carry it. Other UK magazines also carried no such message. So from Issue 20 the message was dropped from TI*MES also. It did not indicate any sponsorship by TI!

Items from Jim Swedlow, California

By Jim Swedlow
[This article is a summary of XB columns that originally appeared in the User Group of Orange County, California ROM]

IF... THEN
a. Instead of IF A<6 THEN A=6
try A=MAX(A,6)

b. Suppose that C$ can be only "Y" or "N" and that you want to write a routine to change C$ without knowing its current value. You might do this:
IF C$="Y" THEN C$="N" ELSE C$="Y"
You don't need to use IF THEN:
100 C$=CHR$(167-ASC(C$))
=======
TOO MANY GOTO's
The following code has been seen:
370 FOR B=1 TO 58 :: IF A(B)
=L THEN C=C+1 :: GOTO 372
371 NEXT B :: GOTO 374
372 IF C=1 THEN PRINT "You See"
373 PRINT A$(B) :: GOTO 371
374 ! Program Continues

Note that in line 370 the program leaves the loop to print the message and then returns. Then it skips over the print instructions to continue.
This is simpler
370 FOR B=1 T0 58 :: IF A(B)
=L THEN C=C+1 :: IF C=1 THEN
PRINT "You See:":A$(B) ELSE
PRINT A$(B)
371 NEXT B ! Program Continues


This saves 25 bytes of memory

DISK MENU PROGRAM:
This month's program will read your disk and display a menu on the screen. After you choose a program, it is loaded and ran. If you save this on your disk as LOAD, it will auto_boot when you opt for XB.

This program requires at least one disk drive and the memory expansion

When you enter this program, save it to disk BEFORE running it. If you make an error in line 220 or 230, the system could lock up and the program would be 1lost.

This program is based on one published in the Pomona Users Group newsletter

LINES 100-150 comprise the header.
LINES 160-190 read the programs on the disk and display them on the screen
LINES 200-210 wait for the user to select a program and then validates the user's selection.
LINES 220-240 change line 240 to have the selected program name rather than "1234567890" and then run that program.

Go to top of page

After you get this working, try entering BREAK 240 before running it. When the program stops, LIST 240 to see the change.

After you get this working, try entering BREAK 240 before running it. When the program stops, LIST 240 to see the change.

DID YOU KNOW? - BAD DISK SECTORS: When Disk Manager 2 formats a disk it verifies each sector (you knew that). What was new to me was that if it finds a bad sector, DM2 locks it off. This allows you to use the disk, with slightly less storage space. (source: a letter in MICROpendium - personally verified).

[DM1000 can do the same if you answer Y to the final question before it initialises a disk. ss.]
[DSKU can verify the sectors on a disk with files on it without wiping the files out, giving you the option to map out any bad 1 sectors. DM1000 and DSKU are available from the club disk library, as indeed is DM. ss]

BOOK REVIEW
The Orphan Chronicles by Ronald B. Albright, Jr. M.D., 172 pages, published by Millers Graphics
(This book is available as a pdf from 99er.net - you need to agree to download terms first) and also as a zip file from TI Books
Dr. Albright chronicles the TI Home Computer from the 99/4 (no A) thru TI's self-destructive marketing techniques to Black Friday (October 28, 1983 - the day TI announced that they were dropping the 99/4A) and beyond. Along the way he covers the International Users Group (a 'commercial' user group - an oxymoron unique to the 4A world) and publications including Home Computer Magazine (and tells us who Regina really is).

Fully half of the book is devoted to the current status of our orphan. There are chapters on telecommunications, freeware, the future and on current 4A supporters.

An interesting chapter is the survival guide. In ten steps, Dr. Albright suggests practical strategies that we can take to help ensure our computers continued existence.

This informative book is clearly written. The material is comprehensive and logically organized. It will help you understand the history that led to today and will give you food for thought about tomorrow.

All in all, this is a "must have" for the serious 4A owner. It will help put the joys and sorrows of having an orphan into perspective.

Basic Enhanced with PRK or Stats Modules

These notes refer to additional CALLs which are available to the Basic programmer when either the Personal Record Keeping Module or the Statistics Module are inserted. Yes your own Basic program can make use of additional utilities stored in modules. When the module allows you.

ENHANCED BASIC
The original console design concept was that there would be a peripheral device into which you could insert several modules. These would ALL appear on your opening menu screen for selection - that is, you could select modules by SOFTWARE instead of having to use a mechanical switch.

FURTHER, subroutines in each module would be available to you either in machine code OR BASIC.

The peripheral was never built, but you can still sometimes see its shadow with the error message "Review Module Library".

And two modules have routines which you CAN use in TI Basic.

If you insert either the Personal Record Keeping or Statistics modules into the port, and select -TI Basic, you have access to additional CALLS which we shall describe here and in forthcoming articles.

If you have a disk system, and run the PRK/Stats modules from DISK (using any suitable loading module or peripheral), after loading the module code, you will find yourself looking at a menu- offering say:
  1. TI BASIC 
  2. EXTENDED BASIC 
  3. PERSONAL RECORD KEEPING  
   If you select 1. TI BASIC, the extra calls ARE still available, just as though the actual module was inserted.

The details of the CALLs seem to have appeared in HOLLAND, via Paul Karis, who wrote an article on CALL A and CALL D for 99er Magazine. We have a printed booklet (800k pdf available to download from whtech.com) which seems to be a dump of the TI hard disk archive file "ARCHIVE.PRK.DOC.SUBRLST' and this has been used in putting together this (and preceding) articles.

The archive document indicates also an intention to allow CALL FILES(0), but that was also not implemented.

The extra calls are CALL A (Accept); CALL D (Display); CALL G (Getput); CALL H (Header); CALL L (Load); CALL P (Prep); and CALL S (Save).

These allow you to set aside an area of VDP ram for data storage, move data to and from this area, and to and from the screen, and save and load data stored in the area to an external device IN MEMORY IMAGE FORMAT . This is a very fast way of storing data, especially for cassette users.

We shall look first at the ACCEPT and DISPLAY subroutines as they relate to the SCREEN input and output. Next time round we shall get into the juicy bit of reserving VDP ram and doing something with it.

CALL A. . .ACCEPT SUBPROGRAM:
There are four formats. The fourth which we shall look at next time, verifies input based on a predefined header.
(i) and (ii)
CALL A(ROW, COLUMN, WIDTH, NUMRETVAR, NUMERIC, [LOW,HIGH]).
ROW AND COLUMN are screen positions- 1 to 24 for row, and 1 to 28 for column.
WIDTH is how many screen characters are to be entered. If this takes you past the screen edge, WIDTH is effectively reduced to the room available. You can of course actually enter a shorter input, as trailing spaces will be dropped.
NUMRETVAR must be a numeric variable. Its value is changed according to which key you use to trigger the input:
NUMRETVAR will be: 
     1 if you use ENTER and the input is valid and non-nul,
     2 if you use ENTER but the field is blank.
     3 if you press AID (Fctn 7)
     4 if you press REDO (Fctn 8)
     5 if you press PROC'D (Fctn 6)
     6 if you press BEGIN (Fctn 5)
     7 if you press BACK (Fctn 9).

think about how you can use this function!

NUMERIC is a numeric variable, into which your input is placed
LOW and HIGH are optional, and can be used to specify a range of acceptable inputs- perhaps you want the user to enter a number between 56 and 121? Not quite the same as the VALIDATE command we are used to in Exbas eh!

(iii). CALL A (ROW, COLUMN, WIDTH, NUMRETVAR, STRINGVAR)
is as above except that it is used to input a string variable. There is no range checking available.

Notes: Additional checking is possible using a fourth format which refers to a predefined Header, which we shall cover next time.

Row and Column numbers are MOD(24) and MOD(28) respectively- it won't crash if you use a number over 24 or 28. If you try to use a negative or zero number, the default of 1 is used.
Play around with this a while. Its not too difficult!

Go to top of page

Even easier is: CALL D- DISPLAY SUBPROGRAM
CALL D(ROW, COLUMN, WIDTH, VALUE,,,,,,,)
Where ROW and COLUMN are screen positions, MOD(24) and MOD(28) respectively, with zero or negative values read as 1.

WIDTH is interesting: If WIDTH is POSITIVE, then that number of characters will be replaced with spaces before the display is inserted. If the display is wider than the specified width. the display is truncated.
If WIDTH is NEGATIVE, the display will be inserted up to the specified length, but any excess length is not cleared.
WIDTH is reduced to the distance to the edge of the screen if you use too high a number. VALUE may be a number, string, or numeric or string variable
You may use CALL D to display as many items as you can fit into your BASIC program line, specifying the parameters for EACH display.

Try it
SAMPLE

Book reviews

Software: Diablo and High Gravity

An old XB game has been mentioned in print several times recently.

History first... DIABLO, by Manual Constantinidis, was released in TI Extended Basic by the US firm of EXTENDED SOFTWARE in 1983, when it was advertised for US$19.95, and stated to be "1st place winner of the TISHUG Australia Contest". Yes, the author was a member of the Sydney user group. (diablo.dsk 90k disk image file to run in an emulator with Extended Basic. With the Linux ti99sim, use the command line eg [/ti99sim-0.0.10/ti99sim-sdl --dsk1=diablo.dsk sxba.ctg] )

DIABLO involved the movement of tiles containing various shapes of track, in order to keep a moving ball continuously supplied with track. As it moved over a tile, the track it moved over disappeared, so you were left with less and less track! The object was to clear the screen, so that the ball had moved over every piece. Diabolic! It was sold in the UK by Timeless Software for just GBP 9.95.

DIABLO is NOW on sale again..."Diamond Games, a German software company, marketed in the UK under the Robtek banner. By Manuel Constantinidis, updated to live within the half-a-megabyte machines, with a Commodore version to follow". DIABLO for the Amiga or ST is advertised at GBP 19.95 and GBP 14.95 respectively. The C64 version will be GBP 7.95 on tape or GBP 9.95 on disk. These new versions appear to be exactly like the TI original, apart from a slightly different tile layout, and the ability to pause/save/load.

When a program written FOR the TI99/4A by a user group member make it onto the Amiga, it is a timefor celebration- and pause to consider just how good our old programs really are!

HIGH GRAVITY:
Way way back... December 1982... I enjoyed a game on a Hewlett Packard computer in which you aim a rocket in a chosen direction, with the intention of it reaching a certain point. Its course is affected by the presence of various planets, which pull it off course by gravity..

Well, I can now play this game on my TI!
HIGH GRAVITY is a good disk full from Asgard Software ( recommend you buy from Tenex or some other reliable source.). You may select how many planets you want on screen, and then solve the "random" screens thrown at you. OR you can set up your own screens- and save them for future solution! The program cones with many such screen tiles You may experiment with gravity- and as the rocket leaves a trail behind it, perhaps even use gravity to produce an interesting art work.

After waiting so long I can only recommend the program to you. It is more of a program to experiment with than a game, and you may not play it often after the first week, but it really is an excellent program.

Tony McGovern writes about Funlweb 4

FUNLWEB
The following text from Tony goes into a little more detail on FUNLWEB

ENTOMOLOGY CORNER #14
Tony McGovern -- Funnelweb Farm

Here we are back writing again after a break of several months of hard programming labor. It has been the Southern Hemisphere winter for the period, not that many readers outside Australia would consider a Newcastle, NSW Winter to be a real winter. I have lived through Oregon and Colorado winters so I do know the difference. Still it leaves a lot more time for programming than summer, the funnelwebs are quiescent, and mail from the rest of the world has been very slow. I hope this is just a sign of summertime elsewhere and not of the death throes of the 99/4a.

Can't be that as it is still too good a machine to give up on easily. No sign of the Network Nasties and their backers. Hopefully they are now doing something constructive for a change, though I can't say I've been left with a very high opinion of either them or those who went along with them, and sad to see some people intimidated by the virulence of their nonsense.

The main news is that FUNNELWEB Vn 4.0 is now out to old friends as a pre-release test version, and will be generally available by the time you read this. What I propose to do in this chapter is to give some further explanation and background discussion over and above the FWDOC's which are of necessity refined to eliminate any excess verbiage. So until I run out of space I'll just keep talking about the how and why of FWB 4.0, and continue next time if it overflows a reasonable length.

A real change is that UPATCH and ULINSTL have disappeared, and LOAD now contains a warning that it is NOT to be edited. All of the setup procedure is now handled by the single CONFIG program.

Myarc XBII:- We have XBII up and running. The point addressable graphics is what TI should have provided all along and the lack was always the worst failing of XB. Mostly, but not always it is faster, but curiously enough is not fast enough to keep up with the sprite routines in the TXB game program, which work even in console XB only.

The real nuisance factor with the Myarc 128K-OS is that it always writes its boot header and code into cartridge RAM on power-up, even if the 128K-OS is NOT enabled. This destroys anything else you want to keep in your Cache Card, DEBUG for instance or FWB even.

NOTE BY STEPHEN: To return to MYARC XB from FUNLWEB 4, do not use the RETURN TO XB option as that only works with TI XB. Instead go to DM1000 and choose the CART RAM option- this will cause MYARC XB to be reloaded from disk (do keep the Myarc disk in place for this!) as the Myarc module retains the loading routine all the time as noted by Tony.

So what has all that to do with CONFIG ? The relevance is that once the XB entry code had been adjusted to sense the presence of XBII (same simple trick as used by LDFW - get a character from the screen area in VDP and see whether it has a >60 XBasic screen oftset) then it was found that reSAVEing LOAD to disk under Myarc XBII would destroy its integrity.

First inclination was to leave it as it was with a warning that it should be edited and reSAVEd only with TI XB. This wasn't really thought good enough by the funnelwebs, or even by the possums that live in the root, so the last major task in developing Vn 4.0 was to eliminate the need for XB editing of LOAD.

This was handled by upgrading CONFIG so that it also configures the LOAD program as well. There are three aspects to customizing. The first of these is common to both LOAD and UTIL1 and comprises all the boot specs, color choices, file/device names and numbers. The second is the UL (Option #7) User List function, either to be saved separately or incorporated in UTIL1. The third, relevant to LOAD only is the User List function from the XB level.

In previous versions this was handled by the XB editor with program statements. CONFIG writes to the LOAD file but treats it as a generic program file for purposes of fetching it from and saving it back to disk.

All items that can be entered directly are no longer defined in XB statements, but since ANY user option could lead to XB RUN of a program it was necessary to keep all these loading paths as XB statement. So CONFIG actually rewrites the XB statements directly into the tokenized program.

There is no way CONFIG is going to duplicate the complete function of the XB line editor, and it is only just smart enough to do the job, provided the XB program has not been mucked around. Hence the warning about not editing and reSAVEing directly with XB. With XBII it is fatal anyway. The real limitation on direct editing is that all XB lines from #160 up must be left strictly alone and none added after #160.

The sequence of the configuration process establishes the common items first before the LOAD program itself is even loaded. If you skip directly to the UL screen the settings that you are using in LOAD or UTILl as used to load CONFIG will be imprinted on LOAD when it is saved back to disk, so if you use several different loading paths it may be a good idea to go through the full procedure each time.

LOAD may be saved back to any drive, as may UTIL1 and UL. I have more ideas on restructuring LOAD/CONFIG but sheer exhaustion has won the day now. Perhaps in some future version! Will used this idea of treating a FWB type of XB LOAD with embedded assembly code as a generic program file in his DISK-HACKER program.

Also you will find that the exit from DM-1000 now looks for LOAD if it can't find RELOAD/UTIL1 on the system drives. This doesn't restore XB conditions but merely loads LOAD as a generic program file and extracts the FWB code.

So what difference does all this make? The prime one when you are setting up is that all configuration steps are now prompted or menu driven, even for XB. You don't even have to have XB or XBII in the machine to configure LOAD. No more figuring XB color groups or which XB statement goes with which. When LOAD is RUN initial operation is now much faster, mostly because it is shorter, and it may be re-enterd by RUN after return to the XB command level, either by explicit option or because a RUN "DSKx.yy" has failed. This allows recovery from such errors without complete reload of LOAD.

It possible to add to LOAD so that a keypress bypasses boot tracking and installs a fixed drive number, for a deviant device such as the Myarc RAMdisk which might be reset to emulate different drive numbers. Why, I'm not quite sure but here's how to handle it on the fly. This is all despite the warning message against direct editing.
Add line #110 to LOAD:
110 CALL INIT :: CALL KEY(5
K,ST) :: IF ST=1 THEN CALL L
OAD(-232,K,K,0,0)

and remove the CALL INIT from 1130. With this addition a key held down as the program starts to execute will be installed as the fixed drive number. See FWDOC/REPT for background information.

Go to top of page

In everyday use of FWB the most popular feature will very likely be the newly updated SD in the Editor. The beginnings of this were apparent in late editions of Vn 3.4.

It is now easy while in the Editor to Mark a file in SD for Viewing on the screen while leaving the document in memory unaffected. Very handy for quick checking of the contents of another file without going through the whole save/load/reload rigmarole.

The existing workfile name can be restored by (O)ldFi1e before exit without explicit reselection. The Print Directory and Program Check functions are unchanged.

Deleting of markable files is also supported, with a cautionary pause, so that memory work is not required as with DF. Files which cannot be marked for loading by the Editor can't be deleted directly this way from SD, but then SD really has no business deleting files that the Editor can't read. The Editor enhancements from late in the Vn 3.4 development cycle are retained, notably right margin beep, crisper screen scrolling, and reduced tendency to lose keystrokes on end of line wordwrap.

It is maybe worthy of note that this extra functionality of the Editor and SD does not require any extra hardware over and above a minimum 99/4a system. The same is true of FWB as a whole.

One thing I have found from the pre-release is that there is a pent-up demand out there for a ruler line. I had altered the End of File message to a more elegant (to my eye anyway) form with a discreet EoF and a column number marking across the screen. This immediately set offcomplaints that it wasn't a full 80 column ruler.

As I'm not under the delusion that my program as handed down is perfect and immutable, I had another look at it and figured how to turn the EoF message line into a 80 column ruler that shifts with horizontal window and line # on/off. While at it I decided to have a go at providing a facility that I have long wanted - upper/lower case conversion without explicit retyping. The major upheavals for EoF on the new ruler line had left a contiguous block of 17 words for the necessary code.

The best I could do for a both way conversion was 19 words of code, but Will saved the day with an improved version that fitted in exactly.

Two of the four unused control keys are used, (ctrl ;) for converting to upper case, and (ctrl . ) just below it for conversion to lower case. If the letter under the cursor is not converted, these just act like a plain right arrow key.

Each of the Central Menu screens has been extended to seven entries. CONFIG allows you to set your own preferred name on the sixth and a two character associated filename. Each of these is set up as an Option 3 program file load for maximum flexibility. The Option 3 loader itself has been modified so that it will handle a wider range of files.

It still hands over in the E/A USRWSP but now sets this up before loading any files. Previously it used registers and loaded R11 before final handover. So now it is more tolerant of files that load into low memory. It just goes to show how even the most worked over code still can be improved with a fresh look. Not only was the loader improved but some bytes were saved in the process.

Many people do not seem to have appreciated the relative significance of the Option 2 and 3 program file loaders. There is some difficulty with terminology here, but the practical differences are real and significant. Option 2 imitates the RUN PROBRAM FILE function of the E/A module. Why then call it 'GPL' ? It's a programmer's view really. The reason is that the E/A function is handled purely by GPL code In the E/A Grom, and the E/A assembly utilities are totally ignored.

Also similar conditions are appropriate for other file loads from Grom and for cartridge simulations. Option 3 is very much closer to being a program (memory image) mirror of LOAD and RUN in a way that the E/A module just does not even provide. The E/A utilities are loaded, the E/A USRWSP is set, and FWB makes sure that differences in departure points from GPL (XMLs in LOAD as against LINK) don't matter.

The latest modifications just smooth over some of the difficulties that an Option 3 load might cause for program files that really should be Option 2 loads.

If the overhead of loading EA is bothersome and unnecessary in your particular application then the jump table may be altered to give the preferred type of program load. As a practical matter if you are using the E/A module or running with your FWB system files in RAMdisk, then loading of the utilities is so fast that you won't notice it anyway.

The easiest place to find the byte jump table is in UTIL1 where the relevant bytes are presently located at >FFE3 and >FFEA. These are near the end of the second last sector and UTIL1 starts at >E006 so you don't have to fuss about 6 byte offsets when counting sectors and bytes. As issued these are both "I" in ASCII form.

Option 2 loads are "F" in ASCII form and Option 1 are "B". You will have to do it to LOAD also, but you will find the practice on UTILl to have been worthwhile. We usually run from a HORIZON RAMdisk and it all zips out so fast that I have to go back to running from physical disk every so often just to see where the program is really getting files from. As always please leave your master disk in its original state for passing on.

Go to top of page

Talking of Horizon RAMdisks brings up the first page items in CONFIG. If boot disk tracking is not enabled then you are asked to specify the system drive. Vn 4.0 allows the FWB system files to be spread over two drives. A full complement of system and user list utility files usually overwhelms the capacity of a DSSD disk.

One drive may be specified for system utilities on the TI-Writer side of the Central Menu screen, and a different drive for the system files on the E/A side. The system file loaders look on the specified drive for that side first, but if the file is not found there they check the other drive too before issuing an error.

The only system files not so treated are the CHR1/2 character sets. The Editor files ED/EE are cosmmon to both sides. If both primary and secondary disks are RAMdisks then the difference in speed of loading when only one copy of ED/EE is present is hardly noticeable. This feature may also be useful to users of TI original type SS disk systems or TI controllers with DS drives.

A little discovery in assembly coding was that the well known trick for incrementing a register by 4 in a one word instruction, C *R1+,*R1+ can get you into trouble - if R1 happens to point to a memory mapped address as it ended up doing in one path through a first attempt at some tricky code to make the right margin beep.

The next obvious addition in Vn 4.0 is the Low-Loader function. This fills a gap in the facilities that TI made available for the 99/4a. The major utility programs that TI provided, the E/A Editor and Assembler and the TI-Writer Editor (but not the Formatter) have most or all of their functional code in the low-mem 8K block, and use hi-mem as a large one piece data buffer. It was easy enough for TI's programmers to prepare these on their minicomputer based development systems, but the nearest the 99/4a came to it was the Minimem module, which provided LOAD and RUN functions only. Helping MM along with more functions in the cartridge RAM was probably an early educational step for many serious 99/4a programmers.

The decision was made early to duplicate the function of the E/A loader, including the loading speed. This meant that an E/A DSRLNK had to be provided and by the time that was done there wasn't much more space needed to provide the complete E/A utility set even though most programs will not use them. Low-Load still uses the FWB object loader, but has to alter and restore a bunch of memory values.

Other programs have been adapted to work with Low-Loader as well. Script-Load now recognizes a global LWLD directive which causes it to use the LL utilities rather than the E/A utilities. That wasn't easy. Also the FMSAVE utility automatically recognizes Low-Load and SAVEs starting with low memory first in that case. I regularly use this to patch and reSAVE the Editor files. While on loaders, there is now only one off-screen loader entry (#8), and this one cancels autostarting of object files. FWSAVE is there mainly to provide the LSAVE function as used to prepare CONFIG, and SAVE to CSl. There just wasn't enough room to fit these in FMSAVE.

The modified DM1000 files are clearly different from before even if this is not obvious until the exit screens. An invisible change is that the entry code has been altered so that if it is not loaded from FWB it works more or less normally, so that separate versions aren't required. I gather that the new UTIL1 doesn't fit as well in GRAM simulating devices. I don't see quite what the problem is as UTIL1 is still under 8K long, but that's what I'm told. I've never even seen one of these devices, and don't know the details involved, and it just may be the system software for the particular device in question.

This is enough to be going on with so I'l1 sign off for now and see if I can find some time for playing with high level languages.

Note: Tony McGovern wrote for the Hunter Valley TI Group in Australia, and is well known for his series of articles "Extended Basic Tutorial", and especially for what started as an improvement on TI Writer, Funlwriter, and grew to become a powerful integrated loading system Funlweb. Some of the magazines of the Hunter Valley group are available online in sometimes hard to read PDF format at whtech.com.

Corrections to Editor Assembler Manual

ADDENDUM to Editor/Assembler Owner's Manual

The Manual is available for download as an 84 Megabyte pdf document (!) Only click this link to 84Mb pdf file at whtech.com if you can handle such a large download.

p42. 3.1.3.1 In the last sentence of the first paragraph, change 'least' to 'most'

p92. 6.10 In the second line of the example explanation, change "value of ADDR" to "value in ADDR".

p104. 6.14.2 In the example, change "MOV *11,1" to "MOV *11+ ,1"

p127. 7.20.1 In the next-to-last line, change ">2220" to ">C220"

p168. 10.5 In the example, change ">2A41" to "@ >2A41" and "Register 3" to "Register 2"

p262. 16.2.4. (Add the following.) NOTE: Some devices modify the GROM read address. RS232 and TP are known offenders. If your program accesses these devices, save the current GROM address (see section l6.5.2) before the I/O operation, and restore it (see section 16.5.1) after your program has accessed the device. Otherwise, the program will not be able to return to the Editor/Assembler or BASIC or to perform a BLWP @GPLLNK properly.

p289. 17.2.6 Change line 130 in the BASIC program to CALL LOAD("DSK1.BSCSUP","DSK2.STRINGO") This assumes that you have entered the source file on the next page by means of the Editor, saved the file as DSK2.STRING, and run the Assembler, using DSK2.STRING for a source file and producing DSK2.STRINGO as an object file.

p328. 21.1 The default for VDP Register 7 is >07 in TI BASIC and Extended BASIC

p335. 21.5.2 In the last paragraph, change ">00 or >04" to ">03 or >07"

p335. 21.5.3 In the last paragraph, change ">00 or >04" to ">7F or >FF"

p415. 24.4.8 Change the second instance of GRMRD to "GRMRA EQU >9802"

p416. 24.4.8 Change the second line to "NUMREF EQU >200C"

p420. 24.5 (Add the following.) NOTE: A program to be saved using the SAVE utility should not have an entry point defined on the END statement. If you want to save the Tombstone City game in memory image format, you must first change the last line from "END START" to "END" and then reassemble the program. Otherwise, the game starts to run as soon as it is loaded, and you will not have a chance to execute the SAVE utility.

p465 Index VDP Write-Only Registers: add page 267 to references