Re: TI83/TI-86/ please read!.. explanations.

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

Re: TI83/TI-86/ please read!.. explanations.

1 and 3 have already been answered, and as to 2:

no. It is not possible to run 82 asm on an 83,85,86, or 92.
no. It is not possible to run 83 asm on an 82,85,86, or 92.
no. It is not possible to run 85 asm on an 82,83,86, or 92.
no. It is not possible to run 86 asm on an 82,83,85, or 92.
no. It is not possible to run 92 asm on an 82,83,85, or 86.
no. the 80 and the 81 cannot 'do' asm.

I hopes the point is clear :-). Unless someone writes and builds a portable
compiler, which would *have* to be along the lines of C (many things turned
into small subs, of which the code is different depending on what you
compile it to.). No single inline asm that refers to any memory position
whatsoever. That means you will have unoptimized code and that means things
will be pretty slow.

Currently, moving asm code around on the various TI calcs is quite hard. If
there will be any easy porting, that will be between the 85 and the 86, and
between the 82 and 83. (Because they are so similar).

However, what should be understood before you go drool about it, is that
every single 'thing' on the calcs resides somewhere. for example, a rom
call is actually nothing more than calling a physical location in memory.
text_mem is the same. these physical locations are *NOT* equal. They are
different for every single calc. In fact, they change, sometimes only
minorly, sometimes only a few, sometimes all different, per ROM version.
Furthermore, although this generally doesn't happen between ROM versions,
it does between calcs, even ti85<->86 and ti82<->83, some rom calls and
things are simply not there at all on the other calc. Or they work
different. a simple example:

A getkey routine, that's part of the rom, which will wait for the user to
enter some characters and hit enter, along with displaying a cursor. I
don't even know if it exists, although it probably will, and I don't know
if it works like this, but jut an imaginary example.

This routine may look more or less the same on, say, the 85 or 86. However,
the code resides in a different place on the 85 than the 86. And, let's
say, the 85 routine expects the location to be in B and C, and expects the
length in, say, A, and wants the pointer to where to store the info in IX.

on the 86, it wants the location in DE, the pointer in HL, and keeps the
length in A as well.

simply changing the include file for assembling will not fix the different
register functions. someone is going to have to run through every line of
code and analyse it.

Furthermore, all the rom locations are currently *NOT* known for the 86 and
83. that will change, though.

The only serious solution is, as said before, a C kind of thing, where, for
example, the above function is actually turned into a sub that could be
called like this:

(This is just an imaginary language.. you should be able to follow it,
though.)
def X, byte
def Y, byte
def length, byte
def Pointer, word

CALL USRInput (X,Y,length,Pointer)

where you replace X, Y, length, and pointer with either actual numbers or
registers, or memory locations.

The trouble with that is, that routine will load all the appropriate
business in the appropriate registers, since someone wrote tables for what
to do when compiling code for the 85, or 86, depending on what the
developer set as what to compile code for. So, it'll work, assuming someone
has the skill to write it all (not on the calcs, on a personal computer
system.) However, let's say you know you won't need the length at all
returned for some reason. The sub will still get the info. That's wasting
time. And absolutely no way to stop it. Well, there would be, you could do
some inline asm code, but then it won't be compatible anymore. This is not
a huge problem on intels (it still exists.. Stuff called demos, which is
essentially a collection of very nice but proc and screen intensive
graphical effects are mostly coded in asm because anything else would cost
too much speed and won't win the competitions.) on the ti calcs, speed is
not available in great amounts. Truth is, the things are bloody slow and
you need to do a lot of code optimizing if you have anything mildly cpu
intensive.

Many complications, as you can see.

Final note on OSes for the calcs.

Many people think ZShell works like this:

ZShell runs in the background, reading the string, translating it to god
knows what, and powering the cpu that way.

With that logic, you logically and correctly come to the conclusion that
someone can write the same thing for an 86, that just translates it into 86
stuff rather than 85 stuff.

Now do this: search on the net for a super nintendo emulator, and run it on
your 486 dx/2 66 Mhz. Will it run? yes, it will, kinda, but too slow to be
of any use. Why? not because the snes has a faster proc. of course not. the
emulator has to read every command in a rom image and translate the snes
code (I don't know what processor the thing has. I think a customized
motorola 68k.. not sure) and make it intel code. that is very slow.

ZShell can't work like that, it would be waaay too slow. What ZShell does
when you run a string, is call it. That moves the current program pointer
of the small Z80 in the calculator to the string, and begins executing code
there. ZShell does nothing else. Nothing else at all. It does provide some
resident routines that control business, but they are not 'permanently'
looking at what's going on. They (The OSes) are, in fact, completely not
there. The Z80 is not a multithreading protected processor like i386 and
up, so you can't have an OS in the background much more in control like
Linux and NT (Win95 tries...). It's NOT there unless the currently running
prog calls it for something.

What is a big part of ZShell, Usgard, etc.. is the Include file for the
assembly on the PC. That file contains name constants for the actual rom
adresses. When the table assembler runs, it reads the TI-85.H (or usgard.h)
file, and see, for example, that VAR_NEW is equal to $5634.. the physical
location of the routine in TI-85 ROM memory. (the number is made up..). So,
when it sees CALL VAR_NEW, it will replace it with CALL $5634, and compile
it. Finding all those locations is tuff :-P. That's also why you can't
directly compile a different OS with the other- the names are different.
Also, newer versions incorporate newly found rom routines. Remember, not
all have been found yet.

I hope that clears some things up, and that people won't keep asking for
'can you run zshell stuff on the 86'. Because this answers your question:
Right now it can't, and if it ever will, only on code specifically compiled
with some portable language designed for ti processors, which doesn't
currently exist and may never will. Furthermore, code written for that
stuff will not be as optimized as straight assembly, and thus the really
cutting edge and 'coolest' games would not be available for it.

--
-R.Zwitserloot@BTInternet.com

cdavis@thepentAGON.COM wrote in article <868647390.5645@dejanews.com>...
> Although I currently haven't a ti, I am going to get one next week. I am
> tring to decide which one to get.
>
> 1) Is it possible to run 83, and 85 basic files on the 86?
>
> 2) Is it possible to run 83 asm / 85 zshell files of the 86?
>
> 3) The standard in my school is the 83. If a teacher was using an 83,
> would it be too difficult to follow on an 86?
>
>
> Thank you.
> --
> This message brought to you by Colin Davis, His ISP, and the letter 'C'
>
> -------------------==== Posted via Deja News ====-----------------------
>       http://www.dejanews.com/     Search, Read, Post to Usenet
>
References: