Jump to:
Data file processing with cassettes ||
TI Writer Editor command key list
TI benchmarks in different programming languages ||
A detailed review of Myarc XB Vn 2.12
Already a number of you have asked about the recent changes in membership renewals. If you do not already know these start and end in May of each year. There is another reason and that is to enable a smooth handover to a brand new Group Committee which will be formed within the next few months.
(webnote: Clive produced one more issue - number 16- before the group met in Derby on 16th May 1987 to elect a committee to take over the helm.)
This means that TI99/4a Exchange will cease to exist. However SUBJECT TO YOUR CONTINUOUS SUPPORT The UK TI99/4a Users Group will remain. It will continue to be a non profit making group interested only in the survival of the TI99/4a and its expansion. TI*MES magazine will stay in circulation but again subject to an editor being appointed. There is no shortage of material which is produced daily from all over the World. I have no doubts that our orphan TI99/4a Home computer remains with us for many more years. But as regards a BRITISH TI USER GROUP it is now down to you to ensure that we continue to fly the flag overseas.
Now after four years and fifteen issues of TI*MES I am not sad but very excited about the prospects of a NATIONAL UK TI USER GROUP. With a strong team on a committee there is so much more than I ever hoped to achieve for the British 99er.
This leaves me to thank most sincerely Stephen, the many UK 99ers and contributors of TI*MES, including all WORLDWIDE TI99/4a Users Groups, who over the years continue to enrich the use of our machine. Audrey and myself wish all a very Enjoyable and Bright 1987.
Happy 99ing, Clive Scally
Cassette data file processing on the TI-99/4A is not one of its better features, so until I could afford a disk system I set about trying to make the best possible use of cassettes. How this can be done depends on your hardware configuration. It is easier with PRK or Minimem since both allow you to save data files in "program" format. Extended Basic for all its powerful features gives you no help in this respect.
Is there any difference between saving programs and saving data? and if so, why? There certainly is a difference but why it should be so is a mystery to me in my present state of knowledge of the technicalities. It appears that programs are saved in blocks of 256 bytes. Presumably there is some process to ensure that a program statement is not split between two blocks, so there may be a few blank spaces at the end of a block, but otherwise a block when passed to the tape is all solid information, and there is no wasted tape.
When saving data files however the system is different. It depends on the size of your data record in your OPEN statement. The User Reference Guide suggests you can make your records what size you like up to a maximum of 192. Well, yes you can, and presumably the computer in its own internal workings accepts whatever size you make it. It's a different matter however when it comes to transferring the records to tape. The recorder will only record in blocks of 64, 128 or 192 bytes choosing that one which is next above the record size in your OPEN statement. Any unused bytes on the tape block are filled with blanks. Thus if you make your size 30 than the recorder will record in blocks of 64 bytes, the first 30 being related to your data and the other 34 being filled with blanks. Half the tape is wasted and it takes twice as long to load or save as it should for the amount of data.
So what can we do about it? The short answer is use Minimem or PRK. The are special and individual problems in using program format with these modules and I propose to deal with those later, and for now set what can be done if you have only the basic console or Extended Basic. First of all however I will get the question of data compression out of the way. This simply means so codifying your data that it takes up less bytes. There are various means of doing this but they all mean extra program statements in codifying the data to record and then decoding again to use or display the data. You may not save all that much memory taking these extra statements into account, and it will probably slow down the execution of your program a little. Data compression may not be relevant to the question of economy of tape usage anyway. There's not much point reducing your records size from 30 to 20 if the records are still going to take up 64 bytes each on your tape..
My way of saving tape usage is to try and fill each block whatever size it is with useful data and not blanks. To do this I make use of the "pending print" and "pending input" facility (see the Users Reference Guide pages 127 and 133). First of all, let's look at the way a typical data file is recorded. You have an array containing your data which has been DIMensioned as A$(20,3) . Your routine to save this array to cassette will include the following statement:-
PRINT #1: A$(I,1),A$(I,2),A$(I,3)
where I is the index of a FOR-NEXT loop. This statement PRINTS a record on to the tape, but this record consists of 3 separate items, with a comma as separator. Why do these three apparently separate items all go onto one block of the tape? The secret is the comma which appears to be quite a powerful operator.
For our (human) purposes we call the separate items "fields" and the three fields together we call a record. The computer doesn't give a damn what we call them, they are simply separate items of data. Any items of data which are included in one Print statement and separated by a comma constitutes one record for the computer and are recorded in one block of 64, 128 or 192 bytes on the tape. The question arises;
can we include several of our (human) records in one tape record? The answer is yes, we can, as long as they are included in one PRINT statement and separated by a comma. Thus, we could modify the print statement mentioned above to read:-
PRINT #1:A$(I,1),A$(I,2),A$(I,3),A$(I+1,1),A$(I+1,2),A$(I+1,3)
The FOR-NEXT loop would have to have STEP 2 added to accommodate this PRINT statement. We now have 6 data items recorded in one block on the tape. For the computer it is one record; to us it is two. It could equally have been six records of one field each, but it would still be one record on the tape.
We could reach a position where, in trying to cram as much data into one tape record particularly if it is a tape record 192 bytes long, the entries exceed the allowable length of a program line. So what do we do in this case. The short answer is use two program lines. But a problem arises here. The two lines will constitute two separate PRINT statements and so will be recorded on to two separate tape records. This is where the pending print facility comes in. Simply add a comma after the last entry of the first line as well as the usual commas between the items, and the two lines are treated as one PRINT statement and recorded in one tape record. I said the comma was a powerful operator, didn't I.
All the above applies when you're saving a file. It applies equally when loading a file. The necessary statements will be identical in form, but with INPUT substituted for PRINT.
And now for a practical example. I have a data file of some 120 records of 3 fields dealing with the players in a chess league. For this particular purpose I need to record each players club and his grade which is a two or three digit number calculated on his performance in competitive games over the previous season. This particular file does not process the data arithmetically so the number is recorded as a string. The name of the club is recorded as a two or three letter abbreviation. So first of all an, array DIM F$(120,3) with Option Base 1. My first record, which will be record number 0 on the tape will be a Header Record (a useful device copied from the PRK module). So H1$="GRADING", H2$="NAME", H3$="CLUB", H4$="GRADE". Add two numerical fields to this Header Record, R the number of records in the file and PN the "page number" where a "page" consists of 10 records and is calculated from R by the formula PN=INT((R-1)/10).
Players' names are recorded surname first with initials after with no full stops, e.g. SMITH WT. Recorded like this the shortest name takes 5 bytes and the longest I have yet come across 16, the average being about 9. Recorded in INTERNAL format on the tape each field uses one more byte than the number of characters, so the name will take (on average) 10 bytes, the club (3 characters) 4 bytes and the grade (3 characters) also 4 bytes, a total of (on average) 18. Ten records will therefore use 180 bytes on the tape, and with a record length of 192 there are a few bytes spare to allow for the probability of a run of longer than average names in any particular group of ten records.
To PRINT 30 items in one PRINT list takes up two program lines, so the pending print facility described above is used to link the two program lines into the one tape record. An alternative, and quicker to program although possibly slower in execution is to use a FOR-NEXT loop for each group of ten records, as follows:-
310 FOR I=l TO 10 :: FOR J=l TO 3
320 PRINT #1: A$(I,J),
330 NEXT I :: NEXT J
There is a snag here however. In line 320 the comma at the end of the line is there to link up the records in one group of ten into one tape record. Unfortunately it doesn't finish there. When the next group of ten starts the pending print is still in operation and the data is included in the first group of 10 on the tape record. Of course, it soon goes over the 192 and the program crashes with File Error. To avoid this the FOR-NEXT loop should only go up to 9 and the 10th record is PRINTed following the loop and without the pending print comma.
My file program is as follows, with only the saving, loading and display routines given in detail.
100-120 SCREEN & DIM INITIALISATION
130-170 MENU DISPLAY & CHOICE ROUTINE
180-260 ADD RECORDS ROUTINE (Last line is 260 PN=INT((R-1)/10) )
270 CALL CLEAR :: REM - SAVE
FILE ROUTINE
280 OPEN #1:"CS1".INTERNAL;O
UTPUT,FIXED 192
290 PRINT #1:H1$,H2$,H3$,H4$
,R,PN
300 FOR P=0 TO PN
310 FOR I=1 TO 9 :: FOR J=1
TO 3
320 PRINT #1:A$(P*10+I,J)
330 NEXT I :: NEXT J
340 PRINT #1: A$(P*10+10,1),
A$(P*10+10,2),A$(P*10+10,3)
350 NEXT P
360 CLOSE #1
370 CALL CLEAR :: GOTO 140 :
: REM - RETURN TO MENU
380 CALL CLEAR :: REM LOAD F
ILE ROUTINE
390 OPEN #1:"CS1",INTERNAL,I
NPUT,FIXED 192
400 INPUT #1: H1$,H2$,H3$,H4
$,R,PN
410 FOR P=0 TO PN
420 FOR I=1 TO 9 :: FOR J=1
TO 3
430 INPUT #1: A$(P*10+I,J)
440 NEXT J :: NEXT I
450 INPUT #1: A$(P*10+10,1),
A$(P*10+10,2),A$(P*10+10,3)
460 NEXT P
470 CLOSE #1
480 CALL CLEAR :: GOTO 14O :
: REM - RETURN TO MENU
490 CALL CLEAR :: REM - DISP
LAY ROUTINE
500 DISPLAY AT(1,7):"FILE ST
RUCTURE": : :"FILE NAME";TAB
(16):H1$
510 DISPLAY AT(6,1):"No. OF
RECORDS"
520 DISPLAY AT(8,1):"FIELD
No. 1 ";TAB(13);H2$
530 DISPLAY AT (10,1):"FIELD
No. 2";TAB(13);H3$
540 DISPLAY AT (12,1):"FIELD
No. 3";TAB(13);H4$
550 DISPLAY AT(24,1):""PRESS
ANY KEY TO CONTINUE"
560 CALL KEY(0,K,S) :: IF S=
0 THEN 560
570 PRINT: "PRESS ANY KEY TO
SCROLL RECORDS"
580 FOR I=1 TO 200 :: NEXT I
:: REM DELAY LOOP
590 FOR I=1 TO R
600 PRINT:A$(I, 1);TAB(18);A
$(I,2);TAB(24);A$(I,3)
610 CALL KEY(0,K,S) :: IF S=
0 THEN 610
620 NEXT I
630 CALL CLEAR :: GOTO 140 :
: REM - RETURN TO MENU One last word regarding the general use of file handling programs whether on tape or on disc. I have used a number of commercial file handling programs (on cassette) and also the PRK module. On the whole they are quite useful but have their limitations. They all tend to impose restrictions on the number of records, fields or chars in a field which may not be acceptable in your particular application. Furthermore, in the nature of things these programs have to be fairly general in character to provide for all foreseeable requirements of your application. They thus necessarily include more programming and more complicated programming than may be necessary for your purpose. This uses up valuable memory which could be better put to use for data storage.
As an example of the effect of restrictions I tried using the PRK module to create a file of all my classical music records. This has a limit of 15 chars for any item. This is OK for the usual musical forms as one can use abbreviations, Sym for symphony, con for concerto etc. But what do you do about those pieces which don't fall into these categories? How do you fit Mozart's Eine Kleine Nachtmusik into an item of only 15 chars? Of conductors Beecham or Klemperer go in all right, but what about Schmidt-Isserstedt? Also if you want to scroll through the whole file this module is painfully slow, and even worse if you want to sort the file.
I have come to the conclusion that it is best to write an individual program for each application using the minimum of simple programming that will serve your purpose so saving memory for the maximum amount of data.
If you have a commercial program in TI Basic you could start with that, set up a pilot file to test it out, then amend it, simplify it and cut out any programming not required. The stripped down program could be tested again with your pilot file to debug it, and when debugged it could then be used for your full scale operation. If your program is in Extended Basic, hard luck, it will almost certainly be protected (web note- such protection as existed was very easy to remove and was therefore little used by reputable suppliers- sjs) so you can't do anything to improve it.
John Roe
The
following handy TI-WRITER commands are reprinted from the June issue of
the 99'er News published by the TI Users Group of Will County,
Romeoville, Ill. This puts the most used commands on one page for handy
access at your computer.
| Editor Command | FCTN |
CTRL |
|---|---|---|
| Back Tab | - | T |
| Start of Line | - | V |
| Exit Command | 9 | C |
| Delete Char | 1 | F |
| Delete End of Line | - | K |
| Delete Line | 3 | N |
| Line No Toggle | 0 | - |
| Down Arrow | X | A |
| Copy Line | - | 5 |
| Home Cursor | - | L |
| Editor Command | FCTN | CTRL |
|---|---|---|
| Ins Blank Line | 8 | 0 |
| Insert Char | 2 | G |
| Last Para | - | 6 or K |
| Left Arrow | S | S |
| L Margin Release | - | Y |
| New Page | - | 9 or P |
| New Para | - | 8 or K |
| Next Para | - | 4 or J |
| Next Window | 5 | - |
| Ooops | - | 1 or Z |
| Editor Command | FCTN | CTRL |
|---|---|---|
| Quit | " | - |
| Reformat | - | 2 or R |
| Right Arrow | D | D |
| Roll Down | 4 | A |
| Roll Up | 6 | B |
| Screen Colour | - | 3 |
| Tab | 7 | I |
| Up Arrow | E | E |
| Word Tab | - | 7 or W |
| Toggle Word wrap | - | 0 |
| Load Files: LF (enter) | does: |
|---|---|
| DSK1.FILENAME | Load entire FILENAME |
| 3 DSK1.FILENAME | Merge FILENAME onto text after line 3 |
| 3 2 10 DSK1.FILENAME | Merge lines 2 to 10 from FILENAME after line 3 |
| 3 12 DSK1.FILENAME | Load lines 3 to 12 from FILENAME |
| Save Files: SF (enter) | does: |
| DSK1.FILENAME | Save entire file to FILENAME |
| 3 12 DSK1.FILENAME | Save lines 3 to 12 to FILENAME |
| Print Files: PF (enter) | does: |
| PIO | Print to parallel INCL control codes |
| C PIO | Print to parallel EXCL control codes |
| L PIO | Print to parallel 74 chars wide plus line no's |
| F PIO | Print to parallel fixed 80 wide format |
| 3 14 PIO | Print lines 3 to 14 to parallel incl control chars |
| Setting Margins and Tabs - Maximum of 16 tabs: | |||
| L = Left Margin |
R= Right Margin |
I = Indent |
T=Tab |
| Use ENTER to execute or COMMAND/ESCAPE to terminate command | |||
(webnote: more than 30 years later I am still using CTRL C to escape console commands on my modern 4-core CPU computer with a current Operating System. Some things persist.)
I don't wish to criticise Amstrad but their machines ARE 'old tech', and the lack of anything really exciting left me feeling very happy with my present ancient set up - certainly I did not see any music or speech to compare to my present capabilities.
Did you go to PCW? I managed to find a stall with THREE TI99/4A modules on sale at low low prices - three different Atari modules.
Somehow I also managed to win a new watch for Cathy in one of the free draws - handy as she needed one!
The IUG had net assets of US$17,865.92. and after preferential creditors of US$12,441.35. that left just US$5,424.57 to meet the winding up costs and non- preferential creditors totalling US$79,390.55. The proprietor, Charles LaFara. has met with some lack of popularity recently, as he latterly sought to maintain the Groups income by claiming copyright on the public domain programs in the IUG library - and even took action against one unfortunate US User Group. A long way from the early days when the first UK User Group was established, and Charles sent over a few disks of programs to start the new Groups library off. I remember the good times.
Now it doesn't cause problems, but for reference, you may wish to note that the use of ON ERROR in that game is wrong.
This is wrong:
100 ON ERROR 200
This is how it SHOULD be done:
110 CALL SCREEN (-1000)
120 END
200 ON ERROR 200
210 PRINT ERROR
220 IF A=5 THEN 100
230 IF A=8 THEN 110
240 GOTO 120
250 END
100 ON ERROR 200
110 CALL SCREEN (-1000)
120 END
200 ON ERROR 200
210 PRINT ERROR
220 IF A=5 THEN RETURN 100
230 IF A=8 THEN RETURN 110
240 RETURN 120
250 END
I have omitted a piece on creating fonts to use with TI Artist as I don't understand what I then wrote!
Maths using numbers we are used to (that is, not restricted to whole numbers but allowing decimals).
A simple basic program that uses the four main math operators, plus, minus, multiply and divide.
100 X=0
Running this program as is took the following times: TI Basic 17.7 seconds; TI Extended Basic Vn 110 27.0 seconds; Myarc Extended Basic Vn 2.10 31.8 seconds.
110 Y=9.9
120 PRINT "START"
130 FOR C=1 TO 1000
140 X=X+Y-Y*Y/Y
150 NEXT C
160 PRINT "FINISH",C
By taking advantage of Extended Basics ability to put all of this onto one single program line the times are reduced by six per cent.
Myarc Extended Basic Vn 2.10 allows the use of integer numbers, and the counter C can be defined as follows: 90 DEFINT C to bring the Myarc timing down to 23 seconds. Myarc Vn 2.11 however dropped the speed to 18 seconds.
Then moving on to trigonometry functions, for which we use radians and base e (those are math terms!)- :
100 PRINT "START"
TI trig is quite slow, the console routines are written mostly in GPL rather than 9900 code.
110 X=0
120 Y=9.9
130 FOR C=1 TO 100
140 X=COS(SIN(ATN(LOG(Y))))
150 NEXT C
160 PRINT "FINISH",C
TI Basic: 62.4 seconds; TI Extended Basic Vn 110:36.2 seconds; Myarc Extended Basic V 2.10 (and 2.11): 36.5 seconds
Note that TI Basic is faster for simple math, but Extended Basic is faster for trig.
Now moving on to text displayed on a scrolling screen- the act of scrolling is quite time consuming-see the comment at the end.
100 PRINT "START"
TI Basic 26 seconds; TI Extended Basic 11.7 seconds; Myarc Extended Basic 7.3 seconds.
110 FOR C=1 TO 100
120 PRINT "1234567890Q WERTYUIOP";C
130 NEXT C
140 PRINT "FINISH"
We can take the scroll out -in extended basic only- by replacing line 120 with:
120 DISPLAY AT(3,1):"1234567890QWERTYUIOP";C
and the times change to: TI XB 110: 7.6 seconds; Myarc XB 2.0: 3.4 seconds; Myarc XB 2.1: 3.0 seconds
Now to more exotic languages- the routine with scrolling in TI Forth:
: TEST
Reasonably fast at 6.8 seconds. We can do it without scrolling by changing line 3 to read:
." START"
101 1 DO
." 1234567890QWERTYUIOP" I .
LOOP
." FINISH"
101 1 DO 4 5 GOTOXY
and this will now run in just 3.36 seconds for 100 loops.
Now for a really slow TI language, Pilot-99:
C: #I<-0
Disk of Pilot99 for emulator, loads with Ed/As option 3.
T: START
LP: 100
C: #I<I+1
TC: 4.5
T: 123456789 0QWERTYUIOP #I
EL:
T: FINISH
E:
100 loops in a not too speedy 98 seconds for that. Moving swiftly on to c-99:
/* console i/o first */
The time for 100 loops is 3.872 seconds. Not that fast? If we take out the scrolling by adding after the while() line: { locate(3.4); and remove the { from the string puts line- time for 100 loops now 0.682 seconds.
#define stdin -1
#define stdout -2
#define stderr -3
#define EOF -1
#define YES 1
#define NO 0
#define NULL 0
#define EOL 10
#define FF 12
#define BS 8
int I:
main()
{ putchar(FF);
puts("start ");
while(++I<5001)
{ puts(1234567890 qwertyuiop");
}
puts("finish");
}
How about graphics? Standard TI Basic and Extended Basic do not directly let you plot single pixels on screen, but Myarc Extended Basic does:
100 CALL GRAPHICS(3)
In version 2.0 this took 268 seconds. Running in Version 2.10 and adding 105 DEFINT X,Y reduced the time to 150 seconds,
110 CALL WRITE(1,22,2,"START")
120 FOR X=1 TO 100
130 FOR Y=1 TO 100
140 CALL POINT(1,X,Y)
150 NEXT Y
160 NEXT X
170 CALL WRITE(1,23,2,"FINISH")
180 GOTO 180
The same in TI FORTH:
: TEST PAGE GRAPHICS2
You will recall that TI Forth forces you to use the two variables I and J for its loops. This routine took 20.1 seconds.
101 1 DO 101 1 DO I J DOT LOOP LOOP
TEXT ;
Pilot-99 does allow pixel plotting (command is PP: #Y,#X), but it took 3936 seconds- over an hour!
And to be complete, some 9900 source code- assembly language- for brevity the routines SETUP, CLEAR and PLOT are omitted (sorry):
DEF BITMAP
This ran in 8.66 seconds.
REF VSBW,VSBR,VWTR
ROW DATA >0000
COLM DATA >0000
BITMAP BL @SETUP
LI R2,>F100
MOV @ROW,R8
MOV @COLM,R9
POINT MOV R8,R0
MOV R9,R1
BL @PLOT
INC R8
CI R8,100
JGT ROWINC
JMP POINT
ROWINC MOV @ROW,R8
INC R9
CI R9,101
JLT POINT
END LI R0,>F100
BL @CLEAR
JMP BITMAP
* SETUP, PLOT AND CLEAR ROUTINES HERE
Before moving on, let's look at some other computers available in 1983/4. For 1000 loops of the TEXT display with scrolling program- TI times were: TI Basic 260 seconds; TI Extended Basic 117 seconds; Myarc Extended Basic 73 seconds.
IBM PC and Turbo Pascal: 76.4 seconds; Spectrum Basic 84 seconds; IBM PC + BasicA 100 seconds; Commodore Amiga Basic 150 seconds; Amstrad CPC6128 Loco Basic 159.6 seconds; Apricot PC GW Basic 3.1 243.5 seconds.
Some of the longer timings for other computers can be explained by more screen characters to scroll.
MYARC EXTENDED BASIC Vn 2.11
This new version of Extended Basic is far more than a TI-compatible : it is largely compatible with TI ExBas but has a number of enhancements which make it a worthy successor, a definite must for anyone who programs in Basic - and it could even win converts from other languages.
One major drawback: none of it is in GPL. In other words, it is not possible to fit even the TI-compatible bits into a module. With the extensions... therefore you MUST have at least a 128k ram card to run it. At present it will run with the Myarc and Foundation cards only, and a new EPROM for the cards is required - included in the price for a Myarc card and at very low cost for a Foundation card (Foundation have now ceased trading by the way).
So here is what you need in order to use Myarc ExBas: at least 128k ram, preferably 512k, and at least one disk drive, with disk operating system.
TI BASIC
Myarc Extended Basic allows you to run 99% of programs written in TI BASIC. You may need to use CALL FILES(1) to load them from disk - but a clever bit of sidestepping allows the Myarc XB to load a longer TIB file than TI's XB can - and you don't have to worry about character sets 15 and 16 (which many TI Basic programs use- but are not supported by TI XB).
TI EXTENDED BASIC
One major problem was found with running commercial programs: a few commercial producers not only supply programs in PROTECTED format. but the program also checks the CPU RAM flag to see if protection has been removed, and if it has, it locks out the console (there are a range of CALL PEEKS that can do this).
Bad news: in an effort to increase the protection of PROTECTION. Myarc have moved the flag - so these programs take a look, fail to find the marker, and deliberately crash!
You will note the version number above! In the last issue I reported on Vn 2.0. and then received Vn 2.1. just as the last issue of Rambles went to press! I reported the problems with Vn 2.1 to MYARC and in due course - very quickly actually - received Vn 2.11. in which most of the problem areas had been fixed. Note by the way that Myarc have included these two upgrades as part of the original price, something Texas Instruments NEVER did in the U.K.
The prescan check of for-next loops does not function correctly- and this can make debugging very interesting! If a NEXT is missing, the error message:
FOR-NEXT NESTING IN NNNN is given.
Unfortunately the number NNNN has little resemblance to any line number in your program!. Remember to check that every FOR has its NEXT yourself if you have problems! For existing debugged TI XB programs this change to pre-scan makes no difference.
ACCEPT AT and DISPLAY AT also differ from TI XB, in an undocumented manner which could actually be helpful!
For instance:
ACCEPT AT(11.12)SIZE(32):A$
does what? In TI XB it blanks from column 11 to the end of line 12 and accepts A$ from column 11 to column 28.
In Myarc XB however, it blanks from column 11, line 12. to column 11 of line 13, and the ACCEPT cursor appears on LINE 13!!!
This can cause problems! Fortunately you are unlikely to come across this problem in many TI XB programs!
DISPLAY AT(11,12),SIZE(32):A$ makes the same deletion, spreading over two lines, but at least the display starts in the right place! Again you are unlikely to have problems with this.
Interesting... ACCEPT AT(24,12)SIZE(32):A$ will place the cursor on ROW 1 !!
OK... now to the useful bit. Lets be really odd and try:
ACCEPT AT(12,2)SIZE(255):A$
NOW... Beginning at row 12. column 2, count 255 screen characters... including the edge characters. THEN the cursor appears! BUT those 255 screen characters may not be blanks! They seem to be taken from the input buffer but I could be wrong. The result is not useful.
Now...ACCEPT AT(12,2)SIZE(-255):A$. Nothing is blanked. but the input field for A$ measures 255 chars from (12,2), including any positions outside current margins (eg edge characters). You can therefore type in quite a lot of text. and have it accepted with one key push into one string. This could be very useful. You can of course use HCHAR first to blank out that section of screen.
BLACK MARK: I may be the only person to OPEN files with the APPEND declaration. but Myarc XB fails to support it. It will open the file without an error message, but then refuses to write to it! Bye Bye APPEND. Unfortunately, there is no error message when you try to write to the file- so you may think everything is going well - it isn't. Do not use APPEND!
The manual I have bears the following claim 'VASTLY IMPROVED ERROR HANDLING SUPPORT' - so of course I have had a very close look at this area, and find the claim entirely false (sorry). In most cases, the same error messages are given as in TI XB, but in several instances, quite different messages appear (eg SYNTAX ERROR instead of BAD VALUE). In one case, an abbreviated error message is reported - eg only SYNTAX ERROR instead of SYNTAX ERROR : RECURSIVE SUBPROGRAM CALL.
In checking error messages out I came across an undocumented TI XB error message- Myarc have also not documented it but worse, have omitted the error trap entirely. Try this one:
100 DEF T(N)=T(N)-1
110 PRINT T(N)
Short program isn't it! In TI XB I received the message UDF REFS ITSELF (almost an X-cert message eh!)
BUT in Myarc XB. these two lines crash the system!!
And also an undocumented error message in Myarc XB where a standard error message should be:
INVALID ERROR NUMBER IN NNNN
That's a good one - this was produced eV VERSION 2.10 running the following code:
100 GOTO 120
However. version 2.11 produced:
110 SUB TRAP
120 PRINT "ERROR MESSAGE="
130 SUBEND
WARNING
Yes. FOUR warning messages - and yes, I know there is no line 515 in the code! After throwing these messages at you, your keyboard becomes unresponsive- only the QUIT key will function.
NUMERIC OVERFLOW IN 130
WARNING
NUMERIC OVERFLOW IN 130
WARNING
NUMERIC OVERFLOW IN 515
WARNING
NUMERIC OVERFLOW IN 515
You CAN stop the WARNING messages with an ON WARNING NEXT, but the console will still become unresponsive running the code above.
The problem area seems to be the console being busy looking for somewhere to go to when it hits the SUBEND!
And in checking out this area of errors, I found something very interesting - not just a difference between the two XB's, but an unreported feature of TI XB.
Read the manual on SUB PROGRAMS and it tells you that SUBEND can ONLY be followed by:
Another subprogram or REM or END.
Try this:
100 CALL HEH
Does it work?
110 SUB HEH
120 SUBEND
130 PRINT "PROGRAM END"
No it doesn't. you get an error message in TI XB whereas Myarc XB prints 'READY'
SO TRY THIS ONE in TI XB:
100 CALL HUH
and now TI XB works just like the Myarc XB. The word SUB appears to act in the same manner as STOP,. and forces the READY message.
110 SUB HUH
120 SUBEND
130 !@P-
140 PRINT "PROGRAM END"
Now try this one - in Myarc XB the !@P- is not required:
100 PRINT "START"
NOW... I am not advocating that you should place your SUB PROGRAMS in the MIDDLE of your programs - let's accept they are better at the end - BUT - they really do not HAVE to be at the end!!!
110 CALL NIDDLE
120 PRINT "RETURNED FROM CALL"
130 GOTO 180
140 SUB NIDDLE
150 PRINT "INSIDE CALL"
160 SUBEND
170 !@P-
180 PRINT "THIS IS AFTER SUBEND"
That covers normal TI XB, now onto the enhancements.
The Myarc Manual referred to is the one I have : it may be subject to revision!
The manual suggests that PROTECTED programs will auto-run and erase if CLEARed or at termination. WRONG. they act just like TI XB programs!
DEF can be used with more than one parameter - wrong, it works exactly like TI XB.
RUN and OLD will load a program LISTed in DV8O format- wrong.
DEFINT can be used in subprograms: wrong, it cannot- you CAN use the format suggested but the results are not those desired. Don't try it! Myarc responded to this with the comment '?' - but it really does NOT work!!
Original review of Vn 2.10: "DEFINT can be used for numeric arrays- wrong. Most unfortunate as this is the area that using INT can really save memory!" Myarc's reply on this one was to tell me how to do it! as the manual failed to do so and my guesses were not right! The way to DIM an array for INTEGER variables only is: 100 DEFINT DIM A(20)
The original manual suggests a command to force a garbage collection, which can be useful to prevent irritating problems with music and sprites when you least want them, but the command has not been implemented- Myarc tell we they ran out memory space!
Now we move onto the GOOD bits of the ExBas side of things... and some of these are a lot better than some the ads mention...
First you have commands strangely similar to UNIX commands... PWD and CHDIR ... used in COMMAND mode. these:
CHDIR: sets the name of a default i/o device. If you do not use the command, the default device is DSK1.
To use it you type in: CHDIR RD. or similar.
PWD: prints the current default device name
What use are they? Suppose you are working an a program called PROGNAME. which is on a disk in drive 1 and the default device is DSK1.
To save PROGRAM to DSK1 you only type: SAVE PROGNAME and to reload it you only type OLD PROGNAME
The default device name is inserted between OLD. RUN and SAVE and the file name! Neat.
RUN when used in a PROGRAM uses a QUOTED string. and you can now have in your program:
100 INPUT "PROGRAM NAME?":A$
110 RUN "DSK1."&A$
or similar- something TI wouldn't let us do
Also, in your program you can use a line like this one:
RUN "DSK2.PARTTWO",CONTINUE
Know what this does? It retains all the variable values from program one for use in program two - including string variables.
In COMMAND mode, RUN seems to use an unquoted string- quotation marks are not obligatory. They are also optional with OLD and SAVE.
thus RUN DSK1.LOAD and RUN "DSK1.LOAD" are equivalent
PRINT and DELETE still require quotation marks
You can also use RUN or OLD to load and run a machine code program which is on disk in memory image format (eg PROGRAM in the disk directory). This may not always work though - see the section on Machine code below!
GRAPHICS are a real delight, and screen displays are set up SO QUICKLY! You can use the 32 column screen. the 40 column screen. and bit map mode. all very easy to use with simple EX BAS CALL COMMANDS.
The 32 and 40 column screens use identical commands. except for colour: in 40 column mode. text colour is set by using two parameters with CALL SCREEN!
In BIT MAP mode you have the extra CALLS:
CIRCLE. RECTANGLE. DRAW. DRAWTO. FILL. POINT. WRITE DCOLOR
where WRITE is used to place text onto the bit map screen. using the 8x8 pixel character size.
CALL HCHAR and CALL VCHAR are also available in bit map mode.
Another undocumented feature you will like- remember TI's canard that you could not have sprite automotion in bit map mode? This is repeated in the Myarc XB manual I have - but in truth. you CAN switch Myarc XB to bit map mode. and then call sprites with auto-motion. Neat.
In the 32 and 40 column text modes. you have the ability to 'window' by setting margins for screen top, bottom, left and right. I recommend you do not LIST a program in a window two characters wide ....
The margins can be changed several times. and HCHAR and VCHAR let you place characters outside the margins anyway.
In default. the margins are set for two unused columns on either side of the screen. allowing 28 and 36 printable columns respectively. Unlike standard TI XB. PRINT does NOT scroll characters in the margins (eg outside the window.)
The reason you can run TI Basic programs without worrying about character sets 15 and 16 is that Myarc XB actually gives you 256 definable characters in 32 character sets - and 32 sprites for good measure. That is enough for most people! (In bit map mode Chars 216 to 255 are not available)
CALL CHARSET restores characters 32 to 95 only. maintaining compatability. but CALL GRAPHICS(N) restores all predefined characters. as well as restoring default colours and clearing the screen ....
VARIABLES can now use lowercase. so that you can use A,a.b.B=2 and have FOUR variables set. CALL color is accepted and remains unchanged when you LIST but has exactly the same effect as CALL COLOR.
If you use Myarc XB to write a program and use lower case variables. the program WILL run in TI XB - but if you edit a line with a lower case variable. TI XB will re-crunch the line and change the lower case to upper case!
Here is one that Myarc have kept quiet about.... MERGE format is a remarkably USEFUL thing that TI gave to us.
BUT it was so slow... a long program could easily take an hour or so to load! MYARC have performed a miracle. and MERGE now saves and loads almost in a twinkling (especially if you use a RAM disk). I was astonished at the speed up. Amazed even! Thanks Myarc!
INTEGERS... so often we hear that using integer math makes a considerable difference in speed. Maybe. but not what Myarc has done! You have the ability to define simple variables to be integers. If you do this. any decimal values are ROUNDED not decimal-stripped. The increase in speed? In a simple benchmark I clocked a 20% increase in speed. Handy but nothing to rave over in ads. when there are so many other improvements! The other change is that your integer variable eats up only two bytes instead of 8.
Nice new command: VALHEX. Ever wondered what >A000 was? Then use this command. as follows: PRINT VALHEX("A000") and there you are.
Unfortunately the reverse is not available!
You can now use a variety of keys to terminate an input, as well as ENTER and FCTN E and X. Whenever you do enter data. a predefined variable called TERMCHAR is set and can be referenced in your program at any time until the NEXT input! Then your program can branch depending on whether ENTER or AID or BEGIN!!!! ..... catch the drift? Unfortunately REDO has not been implemented. Pity.
The various ram card commands can be used in your ExBas programs now. such as CALL PART. EMDK. VOL. and RDDIR--- but for some reason these must each be on a program line of their own. Not serious. but undocumented.
Extra commands include PEEKV and POKEV
TECHNICAL STUFF
Myarc ExBas comes in the form of a module. a disk . an eprom and a manual. Not bad for the price. Good value!
The MODULE contains ram (>6000 to >8000) into which the memory management routines go. These are needed as there is a lot of paging going on!
The 128k is divided into FOUR pages (of 32k each if your calculator is off...).
Looking at the 24k area >A000 to >FFE8 first:
PAGE 1= EX BAS PROGRAM
PAGE 2= VARIABLES
PAGE 3= STRINGS
PAGE 4= Basic Interpreter
So altogether you have 72k for program and variables
In the 8k area >2000 to >4000. you have:
PAGE 1: For your machine code routines
PAGE 2: Basic interpreter again. and a small area of what Myarc call RAM DISK.
PAGE 3: routines for VDP and Speech. and i/o buffers
PAGE 4: MORE basic interpreter and the value stack.
As you can appreciate, a lot of code has to be loaded from the system disk, and life is a great deal simpler if the first thing you do is copy the disk to ramdisk- to do this however you must have the 512k card!
Otherwise. every time you QUIT you must reload the whole system from floppy.- now mostly remedied in Vn 2.11 - Myarc are quick to react to minor comments like this! - in VN 2.11. the file 128KOS is modified and instead of slavishly loading everything every time, checks memory to see what is there. In general, provided you have not switched the ram card off, the system will only need to reload two files from the system disk,. a great saving in time!
If you have copied the disk to ramdisk. the module will load direct from the ramdisk, whatever it is called.
The search appears to be:
Is the file in RAMDISK? If yes then load, if not then
What's on DISK 1 .... and so on.
Once the system is loaded from any drive. it takes a look at DSK1 for a file called LOAD. You can bypass this (undocumented) by holding down FCTN and 4 (CLEAR) until the READY message appears.
MACHINE CODE at last
Firstly, just as with TI XB. your m/c routines have a little less than 8k to fit into. You can enlarge the area slightly by typing in:
CALL INIT :: CALL LOAD(8194.32.130)
This is about the only time you MUST use call init! If you use CALL LOAD to load a machine code program, it checks to see if CALL INIT has been used and if not. does one for you.
Naturally if you wish to move the m/c boundary back a little. you must first use call load. or else when you load your file. the system will see no call init has been done. do one. and reset the boundary!
Now then
1. Programs in machine code written for TI XB loading and running (that is, not written for EdAs or MM loading) MAY not function. If you have any XB LOADing programs they will not operate correctly ( eg the hidden code LOAD program with FUNLWRITER- and similar programs created by SYSTEX or ACE)
2. in general. machine code programs written for editor/assembler will work with the exceptions found below. DF80 files may be too long to load in directly- Longer files can however be loaded using the UTILITY option of FUNLWRITER. (the error message MEMORY OVERFLOW tells you to try Funlwriter )
MEMORY IMAGE files (listed as PROGRAM in disk directories) can usually be loaded using OLD or RUN.
Given that several machine code files in DF8O format are likely not to load into Myarc XB, for a whole variety of reasons, you can use them to create a memory image file which will run directly from Myarc XB.
You will find that some machine code programs - in either format - make assumptions regarding the operating environment which do not apply.
For Version 2.1l. Myarc have provided an additional DF8O utility program called TIVDP which sets the VDP registers to correspond to TI XB. This apparently being the cause of the problem. It seems to cure almost all the faults I found. but I still found a black screen when loading MGR3 from the Funlwriter disk (cure: use CALL GRAPHICS(2) first- MGR file assumes a 40 column set up) , and FROG HAVEN by Fully Assembled Software had invisible logs for the frog to hop over - not easy!
The format is:
CALL INIT :: CALL LOAD("DSK1.TIVDP") :: CALL INIT :: CALL LOAD("DSK1.PROGNAME") and it is NOT a mistake to show CALL INIT twice above!!!
In the event of a LOAD error you will have a blank screen. and need to type NEW to recover the standard Myarc VDP register values.
If using TIVDP fails. then try switching to one of the other graphics modes (2 or 3) before loading the machine code program.
The DM1000 file MGR3 on the Funlwriter disk is an example: try to load it in GRAPHICS MODE(1) and you meet a blank screen - although it will function correctly. To see what you are doing you need to type in: CALL GRAPHICS(2) :: RUN "DSK1.MGR3" and off you go.
3. FORTH: Do not use the original TI loader for Ed/As. it will not function. Instead use the later modification for mini/memory (the Universal loader).
4. FUNLWRITER: The LOAD program with Funlwriter will not work. UTIL1 seems to use an interrupt routine and crashes if you try to run it directly. The easiest way into FUNLWRITER is with:
CALL LOAD("DSK1.LDFW") - the file LDFW is part of the Funlwriter package. Funlwriter remembers its source drive number. and resets various things to allow you access to otherwise difficult programs which may be anticipating an environment not matched by Myarc XB.
5. Any program with odd graphics or no graphics - try setting GRAPHICS mode to 2 (CALL GRAPHICS(2) or loading TIVDP as above. Or loading with FUNLWRITER loaders. Some programs make massive assumptions about the state of the console. when perhaps they shouldn't
6. INTERRUPT ROUTINES - as are used in graphics dumps such as DUMP for instance. or clock routines - do not seem to be available. There is only one vector available for interrupt routines and it looks as though Myarc XB is using it. It may be possible to adapt the environment so that interrupt routines can be used - my knowledge is insufficient to comment on this properly.
-Interrupt driven clocks: I have been able to load and run such things with Myarc XB. both from TI Forth and from XB itself. but in both cases with bad side effects.
In Forth. using MON caused a lock up instead of a graceful return to the title screen!
From XB. using GCHAR returned values 96 (>60) greater than the true value and NEW tried to load LOAD from DSK1...
My observation therefore is that any program using the interrupt vector >83C4 is more than likely to misbehave or totally crash the system. A few programs use this address as an alternative to TI's standard auto-start.
Cassette handling has not been included possibly as a result of differing VDP mapping- or the thought that few purchasers would want it - it was not worth the trouble of writing the code!
CONCLUSION
Although there will be some programs that you cannot run with Myarc XB. this is inevitable with any upgrade - in some cases you can get round the problem with just a small bit of a rewrite.
We are not looking at a Myarc failure here. but at programmers who have taken short cuts- in some cases taking advantages of bugs TI left in but Myarc have removed! In some cases a particular upgrade demands that a degree of incompatibility is introduced. Life is never easy! But by and large.I have had to use alternative modules to run very few programs.
I will retain my TI ExBas module to run the odd bits of code that I do not have source code for but which require the TI XB environment. Otherwise. I can strongly recommend a Myarc ExBas purchase. Only snag is you do need the RAM card... but that in itself is WELL worth having!
Rediscover Extended Basic. Treat yourself
(c)October 1986 Stephen Shaw
[ TI Book front page |
TI Resources Page
| TI Articles
| PC99 and MESS Programs
]