Re: A82: Re: Dines + the future of Ash (Update on Ash 4.0)

[Prev][Next][Index][Thread]

Re: A82: Re: Dines + the future of Ash (Update on Ash 4.0)


>Perhaps you can tell the list this new method?  Usgard relocation will
NOT be acceptable.
> Some huge programs have too many jumps which would make them too big to
even exist
>on the 82.


On the TI85 some shells use the same method of relocation as Ash does not
and Usgard uses a different approach. And some time ago people where
discusof interrupts, it is not possible to support this unless another
method of relocation is used. Another thing is some functions which makes
it easy to make games which uses several variables, to implement this you
need another type of relocation than the one used in Ash.

No one has yet released a shell which solves all these problems without
using usgard like relocation, and i do not beleive that it is possible to
do so. Since a lot of people have been asking for these features i do plan
to use Usgard like relocation. This will among other things make programs
like GameWizard and MarioMan smaller and easier to make.

Interrupts:

As some of you have heard using interrupts under Usgard is very easy, and
you can have sevearl interrupt programs running at one time. Usgard like
relocation will make it easier to implement the interrupt driven programs.
and they will be smaller. One of the reasons for this is that you can have
relocated interrupt rutines.

Programs with more than one var:

Some big programs uses more than one variable, like mario man, and this
will get alot easier with the new type of relocation. The reason for this
is that you can have both programs relocated at the same time.

Not as many crashes:

The new method of relocation makes it less likely that a program will
crash, and it will solve the problem with KEY_HAND. 

For those of you who still thinks that Usgard like relocation takes up to
much place to make good programs, have a look at the programs written for
Usgard. The best asm programs i have seen for a ti-8x are made for usgard.

Now you all know why i prefer this method of relocation, but i would like
to hear what you guys want. Would you rather have the same old kind of
relocation, or do you agree that usgard like relocation is better ?

>>On the TI85 Andreas Ess and I located the build in random function, and
>>this one is included in some ti85 shells. The function is rather slow,
bu=
>>t
>>the results a very good. I could probably find the random functions on
th=
>>e
>>TI82 too, but the question is wether you want this are a runtine which
is
>>faster.
>
>CrASH has a small and fast one.

I guess that you use the r register to make random numbers. This is very
fast, and the rutine is small too, but the numbers are NOT very random.
Making good randoms numbers are very hard (the rutine Borland uses in its
compilers is actually not good enough for scientific purposes). So the
question is wether you want a small fast rutine, or one which makes good
random numbers.
(If you look at the ti85 programs which uses the r register to ger random
number you will see that there are several problems with this)

>This is the problem with turbo interrupts: THEY CANNOT BE UNDONE ONCE
SET.  Notice
>how ARK sets turbo and unsets it, yet CrASH's CR_GRBCopy still fails... 
Turbo mode
>has some permanent effects on the calculator that cannot be solved.  I
don't see
>why anyone would want turbo interrupts anyways, when you can make the
fast key repeat
>occur by setting the repeat countdown byte after a call to CR_KHAND or
GET_KEY.
>

I have made a function which works like CR_GRBCopy, and it functions in
turbo mode, and it is faster than most of the other rutines i have seen. I
know that some programs need Turbo mode, and they can not be made without
this. If you include the rutine in the shell Turbo mode will be
impossible, but if you do not i is possible to use it. I have tested Turbo
mode myself, with the display rutine that i wrote, and there are no
problems at all. After i had used turbo mode i tried some other asm
programs and there was no problems with them either, so i donot believe
that interrupts can not be undone. You say that turbo mode has some
permanent effects on the calc, does this mean that once you have tried
turbo mode you can never go back ?

I am very interested in hearing what you guys think about these things,
which kind of relocation should be included ?

Dines

_______________________________________

Dines Justesen
Email: dines@post1.com or
       c958362@student.dtu.dk
WWW  : http://www.gbar.dtu.dk/~c958362/
_______________________________________
Follow-Ups: