A82: Re: Why Turbo Sucks. (also reply to dines)

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

A82: Re: Why Turbo Sucks. (also reply to dines)


>We have thought out an algorithm using "classic" relocation to allow
>variables.  The relocation would be done in such a way that while things
are
>not in their original locations it will be algorithmically possible (just
a
>compare and a subtract probably - it will be handled by crash) to convert
>VAT addresses to the addresses of the variables' current (relocated)
locations.


The reason that i called the relocation method used r make such a table if
it's not at a known
>address like APD_BUF?

When you have Usgard like relocation it is possible to store the interrupt
rutines in a way which means that they will never move. And that is why
you can have TSR programs.

>A relocation algorithm that allows VAT reading/writing has already been
>thought of by us.  It's a matter of us beginning to write crash 2.

(Using the rom calls it is alot easier to do this)
>
>>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.
>
>They certainly aren't the biggest, are they?  Try recompiling something
like
>FFX4 for usgard.

As i said calculations has shown that this is no problem at all.

>>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 ?
>
>Have you benchmarked your CR_GRBCopy clone?  It's probably much slower.
>Yes, once you have set turbo mode you cannot unset it 100%.  Why else
would
>a TI-82 that has used ASH with turboing programs for a long time then
load
>the CrASH backup file and not work?  Turbo sets something that remains
until
>a forced reset occurs - pulling a battery when busy or in an assembly
>program (calc off programs excluded of course).  Turbo sets SOMETHING
that
>remains.

I have not seen a rutine which was faster than the one i wrote, except for
the one Sam Davies wrote, and that does not work on my calc (too short
delays). Your rutine might be faster, i do not know i have not seen it. I
designed my rutine for normal operation, an then tried it in turbo mode
afterwards, and it worked, with out using more delays. In the beginning my
delays where almost as short as the ones in Sam Davies rutine, but if you
used the rutine a lot it would give errors after a while. 

To test wether a display rutine has long enough delays try using it as
fast as possible. Do something like what is done in ShowPic, and let it
run for several minutes. If you do that alot of rutines which normally
would work, will give you errors. This means that if a game uses the
rutine too often it will mess up the display. Some of the errors will even
make some of the system rutines stop working. For exampel if you do the
test with ShowPic and then try CLEARLCD after the program has stopped, i
wont erase the whole display !

>The permanent effects seem to change the timing of the interrupts
slightly -
>slightly enough that CR_GRBCopy, confirmed to be the fastest possible
>buffer->display copy (we had to add 1 extra clock per loop execution to
get
>calculator version 17.0 working (there are hardware differences too I
>guess)), fails due to calculator mistiming.  Turbo therefore makes
programs
>slower (there's more than 1 reason) because the fastest routines don't
work
>even after being unset.

As far as i know it is not just a matter of difference between rom
versions, it is different from calc to calc (and it also depends on your
batteries !). To use the dispay controller you do not need to syncronize
with the interrupts in any way, have a look at all the display rutines
written, none of them makes any kind of syncronisation with the ints. If
you are right that the calc gets slower if you use Turbo mode, you display
rutine would get slower, which means longer delays between writes to the
display controller. Longer delays is no problem for the display
controller, so i do not see why this should make any difference.
>
>Nobody yet has given a reason to use turboing at all.  Fast key repeating
is
>much more easily done by manually setting the key repeat counter after a
>GET_KEY.  Also, if you don't turn off turbo before a KEY_HAND, turning
off
>the calc has the annoying effect of leaving TI-OS in "turbo" mode (see
FFX4
>for os-82).  Turbo mode SLOWS DOWN the calculator - the more time spent
in
>interrupts the less time spent in programs.

As far as i know someone (i dont know who, but i read it somewhere on the
net) messured the speed of BASIC programs/calculations with and without
turbomode on, and the results where that both things where faster with
turbo mode on. I do not know why this is so, but it does not fit your
explanation wvery well.

_______________________________________

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