[A82] Re: TI82 ROM Version 19.006
[Prev][Next][Index][Thread]
[A82] Re: TI82 ROM Version 19.006
>From: "Henk Poley" <HPoley@DDS.nl>
>Reply-To: assembly-82@lists.ticalc.org
>To: <assembly-82@lists.ticalc.org>
>Subject: [A82] Re: TI82 ROM Version 19.006
>Date: Wed, 4 Jul 2001 11:30:05 +0200
>
>
> > Van: Dines Justesen <dines@aub.dk>
> >
> > > Are there big differences between the Ti82's and the Ti83's
>filesystem?
>If
> > > these aren't there, than it's more a way of finding the adress
>equivalents
> > > on the Ti82, and things will work (hopefully).
> >
> > The "filesystem" is pretty much the same, and the functions needed are
> > known. The problem is the way the assembly language programs are
>started.
> > One the Ti83 the TIOS is starting the asm program, and it performs some
> > clean up before it does that (AFAIK). On the TI82 the OS is interruped
>while
> > executing an ordinary assembly program, which means that the state of
>the
> > TI82 when the shell is started is not as well defined.
>
>Difficult... I know that Ti82 asm programs are started via some BASIC
>program, but I suspected that TIOS would be in much the same state when
>running such a BASIC-prog...
>
> > > Nice, that is the advantage of Venus, the shell is very small and
> > > everything get's a whole lot more transparent, always nice for the
> > > people-who-don't-know-what-a-shell-is...
> >
> > When it was tried on the TI82, most people seemed to prefer using the
>shell
> > and not start the programs from the menu. On the TI85, people prefered
> > Usgard over ZShell even though it was bigger. So it not al size, it is
>also
> > the features which the shell has. Including common functions in the
>shell
> > does make it bigger, but it makes the programs smaller, so it saves
>space
> > anyway.
>
>Venus can have a graphical shell extension (it has one already). And it has
>the libs, off coarse.
>
> > > And the pro for the programmer is the bigger crash-resistance (if
>things
> > > will work on the Ti82), plus you could use the same header for the
>Ti82
> > and
> >
> > Why would it be more crash resistant?
>
>I don't know if it is on the Ti82 like on the Ti83; when an error occures
>in a ROMcall (like in an FP functions etc.) the TIOS 'drops-back' to the
>prompt. At least on the Ti it will crash if the program was an Ion program
>(at least I haven't had one occurence where it didn't got into an APD-loop
>or something)
>because of the 'crappy' program relocation.
>
>If you update the the pointers then it won't crash on 'drop-back'...
>
> > > As I understand the Ti82 shells ASH and CrASH, have some built-in
> > > pointers/jumptable which will point the call to the right location for
>the
> > > different ROM versions. This is indeed not needed on the Ti83, but...
> > Venus
> > > has external libraries (in a better/other way then SOS), also just
>called
> > > 'externals'. You could could use these libs to straighten up some
>things,
> > > but okay, it won't be compatible to (Cr)ASH.
> >
> > The RAM adresses are different in the different ROM versions, so the
>shells
> > include a function which will add a constant offset to the address
>called.
> > This means that most of the ROM calls that are needed in ordinary
>programs
> > can be used without problems. In the new ROM version, a lot of stuff has
> > been moved, so now, one would need the adresses for all ROM versions,
>for
> > all the supported calls (or one would need two versions of the shell and
>the
> > programs).
>
>So on ROM 19.006 you would need a 'call-translator', instead of a little
>routine that will add the offset to your adress? That will be huge...
>
> > > BTW: We don't NEED to break with call compatiblity, it's just an
>option
> > > which uses less memory...
> >
> > If you want to support the new ROM version, the way ROM calls are made
>has
> > to be changed, and all programs would have to be changed.
>
>Okay, so programs made for previous Ti82s are not compatible with the
>new(est) version, so you really needed to re-assemble the progs, with new
>includes (need to be made), to make them work?
>
Wouldn't it be possible to write a program to replace the rom_calls with
nops then the proper call, and change any JP's or CALLS to rom addresses
with the correct new pointer address?
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
Follow-Ups: