Re: A89: Re: Survey for the next version of PlusShell
[Prev][Next][Index][Thread]
Re: A89: Re: Survey for the next version of PlusShell
>
>In a message dated 11/16/1998 10:52:41 PM Pacific Standard Time,
>assets@eden.rutgers.edu writes:
>
>> The problem is that big functions usually are very specialized; if there
is
>> a small difference in what the programmer needs and what is available,
he
>> must copy out the routine again ... most graphics routines are like
this.
>>
>> The most important calls in util are the clear screen, getkey,
>randomization
>> and find pixel calls ... all of which are most likely in the rom.
>> grayscale libraries represent the quintessence behind libraries, but if
>> someone wants his interrupt to do something more than grayscale, he
copies
>> out the routine again.
>> hexlib calls are probably in the rom; AAR they aren't common enough to
>> warrant place in a library.
>> Huffman, though the most common compression, is only best in a few cases
>...
>> it's most useful application would be to compress basic programs (text)
or
>> levels ... another scheme might be employed for graphics compression.
>> graphlib: forget about about it .. this library might be useful to
newbies
>> trying out simple test routines
>>
>> Though you might think the hassel is trivial, but as a programmer, I
>> personally don't like the idea of my program being dependent on external
>> code in order to run ... for a calculator that requires a shell,
libraries
>> are acceptable because the program is already dependant on the shell;
but
>> for calculators that aren't, this is not acceptable. A program written
for
>> the 89 should work on every 89 (on every rom version) and not _only_
until
>a
>> new standard is introduced. Libraries defeat the purpose and elegance
of
>> built-in assembly support
>>
>> Finally, I seriously doubt that the makers of the current 89 asm games
>> haven't received enormous amounts of email over their games & libraries
>> problem (I've recieved emails myself, just because I've posted to this
>> list). Libraries add an unneeded amount of complexity to assembly
>> programming, with little benifit to offer back
>>
>>
>> Aside, someone must have found the jump table used for ROM calls (if
not,
>> then we're stuck with ROM version specific programs when the next
version
>> comes out)
>> so please: share your information!
>
>
>In regard to the dislike of external code you mentioned, I don't think
Windows
>programmers would want to include the Windows code in their programs.
every
>programs would be about 50MB bigger! The size difference isn't that big on
>the TI-89, however.
Note: windows libraries .. they come with the os (like rom calls come w/
ti-os).
There's a difference between a program being dependent on the operating
system (you obviously can't get around that) and being dependent on some
code written by a third party that not only doesn't exist on every
calculator, but may or may not exist in the correct version.
>
>Some library functions do not defeat the purpose of built-in asm support,
but
>there are many of the functions in the TI ROM somewhere.
The very nature of libraries, even if the calls do the most useful things,
defeats the purpose of built-in asm.
Btw, I think the line functions have been discovered and the huffman and
sprite routines definitely do not exist in ROM
>
>When TI releases the specs for the ROM, with all the functions, I beleive
that
>we will find many of the library functions obsolete. Linelib, for example,
>will definitely become obsolete when we find the line function in TI's ROM.
>It will also probably run more effeciently (one advantage of using TI's
>functions instead of our own).Therefore, it is my opinion that until TI
>releases the specs (if they ever do!), we should not agree on standard
library
>functions.
>
>Daniel Imfeld