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