RE: A92: Suggestions for the 92+ upgrade.
[Prev][Next][Index][Thread]
RE: A92: Suggestions for the 92+ upgrade.
A TI-BASIC compiler would be either impossible, or very difficult to make.
TI-BASIC programs can generate code on-the-fly, and the compiler would have
to be on the lookout for that code so the interpreter could take care of
it. Even if it were done, speed would only be increased marginally.
A good way to make the text editor better would be to change the F2 VIEW
item. This should be replaced by two different menus, one labeled Folder
and the other labeled Var Type. Each of these menus would just have the
items that were previously in the View dialog box, which would save many
keystrokes. Also, the current view settings, Folder and Var Type, should
not be cleared when the Var Link menu is exited.
Another change I would make is in the MODE dialog box, swap the locations
of GRAPH and CURRENT FOLDER.
________________
Jeff Tyrrill
http://tyrrill-ticalc.home.ml.org/
http://ti-philes.home.ml.org/
-----Original Message-----
From: Francois Bradet [SMTP:hernick@videotron.ca]
Sent: Saturday, November 08, 1997 2:59 PM
To: assembly-92@lists.ticalc.org
Subject: A92: Suggestions for the 92+ upgrade.
<< File: ATT00000.htm >> IMHO, one problem that plagues the 92 is the
awful speed of TI-BASIC programs. As I understand it, the programs are
interpreted and are stored as text. I suggest that, in the 92+, the
interpreter be wiped out of the ROM and that the now-free space be replaced
by a compiler. A compiler, producing lightning fast ASM code from a
TI-BASIC program, would bring the possibilities of TI-BASIC to a new level.
Some will say, it will be possible to program the same thing in ASM, and it
will run much quicker, but most people won't learn ASM. Most people would
prefer a fast TI-BASIC allowing you to make a situation specific program in
minutes.
There is a problem with what I suggested: both the uncompiled TI-BASIC and
compiled ASM program would have to be kept in memory, which is bad. I also
have solutions to bring, that could solve this. Three of them, actually,
that could be used together or separately, only one, two or even all of
them.
1-Tokenizing: Tokenizing a program consists in assigning each instruction a
specific value. For example, solve could be tokenized to ASCII 135.
solve(x=2,x) would stored in memory as <token code><ascii 135>(x=2,x)<end
of line>. Then, when the user would want to access back the program, it
would be detokenized on the spot.
2-Compressing: LZW and/or Huffman compression can be used on both the
uncompiled and compiled programs, or only one of them, and can save a lot
of space as well.
3-JIT Compiling: Just In Time compiling consists keeping only the
uncompiled version of the program in memory, and compiling it only when
needed. While it delays the start of the program, it allows to completly
eliminate the compiled version from the memory.
Even though 500k of memory seems a lot, I am certain that it will sooner or
later become a limit. Having compression/decompression algorithms built in
ROM would allow us to maximise efficiency of that memory. Be it implemented
in a DoubleSpace kind of way (seamless automatic compression/decompression
of everything) or zip kind of way (you must compress/decompress files
manually), it would be very interesting to have.
It would be quite convenient if the TI-92 ASM support would be compatible
with Fargo, as there already is a large amount of fargo programs and
programmers.
A major upgrade to VAR-LINK. It just plain sucks. Get an User Interface
specialist on the job and come up with something better. Please.
Redefinable keys in the text editor. I'm tired of pressing [2nd] e e to get
a é or [2nd] a e to get a è. Half the functions key are sitting there doing
nothing. I'd like to be able to press F9 to have the é or something like
that.
Please comment/provide contructive critics. And bear my awful english. I'm
a french canadian and english is only my secondary language.
Francois Bradet