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

To: assembly-82@lists.ticalc.org
Subject: A82: Why Turbo Sucks. (also reply to dines)
From: Barubary <darkstar_usa@pipeline.com>
Date: Tue, 23 Dec 1997 03:57:47 -0500 (EST)
Reply-To: assembly-82@lists.ticalc.org

>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.

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.

>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.

How can you POSSIBLY have terminate and stay resident features with
something that can move around anywhere?  The Z80 has a 1 byte register that
makes up a 16 bit pointer, and each byte in the table works the same way.
How can an interrupt handler make such a table if it's not at a known
address like APD_BUF?

>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.

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.

>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.

>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.

Nope.  I don't know if hideaki will let me paste crash's random routine, so
I guess for now just disassemble crash or something.  We didn't use R simply
because it's not random enough.

>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.

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.

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.

-- Barubary