A86: Equations vs. Programs (Tokens and other)
[Prev][Next][Index][Thread]
A86: Equations vs. Programs (Tokens and other)
Actually, some of you are right, a normal equation or basic program begins
with the data if untokenized and a null byte followed by the data if
tokenized. If you read on I'll show you a cool way to prove this. Tokenizing
is something really neat that both the 85 and 86 do. Interestingly enough the
85 and 86 both have the same bug that allows you to play with tokenizing
stuff.
The bug:
I'm assuming Z is an undefined variable to do this
type this (I can't draw all characters, it should be obvious to most users)
Z=?
Eq>St(Z,Z)
sub(Z,2,1)->Z
Z should now contain the null character, if you play with the Eq>St and St>Eq
converting commands you can get the calc to do some weird stuff (crashing it
too). Ok, create a new program and recall Z into it as a string, remove the
quotes. If you put stuff after the black square (null byte) and exit the
program and re-enter, it will translate it into different stuff depending on
the stuff after it. (the number 3 will crash the calc! ) Try different stuff
like letters and symbols.
These translations are those that the 85 and 86 do when tokenizing and
untokenizing variables. When viewing a command line it will appear normal to
us, but upon tokenizing it will be usually be compressed into these
translations. The null character unlocks the translations. If you were to
change a tokenized program into a string and then recall it into a new program
deleting the parenthesis, it would take a null character at the beginning to
untokenize the program upon exit and re-entry. It also looks really weird.
It is possible to convert between the equation type and program type because
they behave very similar and begin identically, but a converted program to
equation would only evaluate the first line of code, returning syntax errors
as expected. This defeats the whole purpose of interchanging the two
elements. The modified program-equation would generate errors if you did
anything illegal in normal equation entry.
At runtime an equation becomes like an expression in parenthesis. The ROM
makes every appropriate call as if there were parenthesis around a separate
block of code, but it inserts the equation as it encounters it. Because of
this, an equation must function as any other expression or command that can be
encapsulated in parenthesis. The St>Eq converters allow you to customize
equations to anything desired, but they still must evaluate within a
parenthesis environment to function.
A bit of background information:
I got really bored a year or two ago (yes, it has been that long ago) and I
started writing a hexeditor for the TI-86, with it I've been able to hack many
things like high scores in games and VAT addresses. This is how I know what
equations and programs look like in memory. It should be available on
ticalc.org in a couple days now that I've decided to release it for the first
time. Much of what I know today is because of this somewhat old hacking
utility I made.
.
Tim Adkisson
<A HREF="mailto:honorIam2@aol.com">honorIam2@aol.com</A>
If you need help with any 85 86 hacking, don't hesitate to email me, I even
write hacking utilities on the fly (I usually keep them to myself, especially
the x86 ones for my PC).
David at acz.org keeps a very good tutorials section for beginners if anyone
is interested, at <a href="http://ti86.acz.org">http://ti86.acz.org</a>. It
can get quite annoying if everyone on this list keeps asking the same
questions over and over again, so I recommend any newbies reading this message
to check out this page or Matt Johnson's page. It helps a lot when trying to
get the basics of asm down.