A89: Re: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
[Prev][Next][Index][Thread]
A89: Re: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
That makes me angry.. I have an original TI-89. I want a new one! :)
Bryan
----- Original Message -----
From: "Scott Noveck" <noveck@pluto.njcc.com>
To: <xvassor@mail.dotcom.fr>; <assembly-89@lists.ticalc.org>
Sent: Monday, November 15, 1999 4:43 PM
Subject: A89: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
> I haven't read through all of this yet, but I'm in a hurry so I'll forward
> it now. . .
>
> -Scott
>
> -----Original Message-----
> From: p-fischer@ti.com <p-fischer@ti.com>
> To: noveck@pluto.njcc.com <noveck@pluto.njcc.com>
> Date: Monday, November 15, 1999 2:53 PM
> Subject: Re: TI-89 ROM 1.05 vs 2.00 version inquiries
>
>
> >Scott Noveck -
> >
> > Okay, here's what I have for answers to your inquiries regarding
> >the TI-89: Please bear with my, I'm not a TI-89 expert. Most of this was
> >from another developer. Hope it answers most if not all your
> >questions....
> >
> >1. The TI-89 Hardware Version "2.00" and lower down report ROM version
1.05
> vs
> >the older TI-89s with a upgraded to ROM v1.05 and
> > are NOT labeled "Hardwate Version 2.00". There are two different
> >versions of hardware for the TI-89, as you noticed in the hardware
> > version descriptions. This H/W & firmware change was implemented
to
> >move the functionality of the security chip into a gate array,
> > to alleviate a potential lockup/ROM corruption problem which you
> >mentioned.
> >
> >2. Along with this hardware change (to alleviate the security chip's
> >prior shortcomings), there was some changes to the underlying
> > hardware's means of how display pages are selected and displayed.
> >(The) LCD can only start at 0x4c00, 0x5c00, 0x6c00, or
> > 0x7c00.) Writes to the LCD memory are copied to a buffer internal
> >(in one of the gate arrays). Consequently, selecting an alternate
> > display page is not enough to load up the gate array's display
> >buffer. You need a little loop like:
> >
> > lea lcdpage,a0
> > move.w #PAGESIZE/4-1,d0
> > .1:
> > move.l (a0),d1
> > move.l d1,(a0)+
> > dbra d0,.1
> >
> >to copy the memory to the internal display buffer. According to our 89/92
> >software developer/"expert", the above "looks" like it's copying to
> >itself, but that's how it works (his words). The reason, (as I
understand
> >it) for this display buffer is to remove DMA contention for the LCD
> >display memory accesses, thereby speeding up other calculator (memory)
> >operations.
> >
> >Basecode version 1.05 mostly consists of changes to interface with the
new
> >hardware configuration. Version 1.05 runs on older hardware, but,
> >software versions prior to 1.05 will not run on the new hardware. There
> >are some ports in the new gate array which are not initialized properly
by
> >the old(er) software.
> >
> >Several important memory locations, such as the Heap address, are also
not
> >in the 1.0x jump table. They will be added in future base code releases
> >and documented in the TICALCOS (68K) SDK. In the meantime, assembly
> >language programs which depend on the migrant memory locations will have
> >to track the different base code versions.
> >
> >So, I'm sorry to say that one cannot downgrade to the prior / initial
> >hardware version (ROM 1.05 , <hardware version 1.0>) if the calculator in
> >question is a hardware version 2.00. Several addresses (eg, you refer to
> >the: ....tios::kb_vars and tios::MaxHandles ROM addresses...).are
> >different.
> >
> >>4. There are various ASM program failures with the ROM 2.00.
> >>
> >>Yes. I'm sure TI is aware that there are shells that install their own
> >>kernels on the 89. The kernels allow the programs to have support for
> >>features including ASM library support and BSS blocks as well as the
> >ability
> >>to make ROM calls without the ROM_CALL macro, among other things. Some
> >>versions of the kernel that install on a "old" 89 will freeze on
> >> installation on a "new" 89.
> >
> > This could also be due to "several <I/O> ports" not being
properly
> >initialized as well as differences in addresses of variables or other
> >parameters.
> >
> >>In addition, several greyscale programs. . . well, the greyscale doesn't
> >>work =) I'm sure that you're aware of the method used to obtain
> >greyscale
> >>on the calculators by rapidly switching the screen between two "planes"
> >via
> >>an interrupt. Several 89 programs that work perfectly on the v1.05 ROM
> >>without Hardware Version 2.00 fail to display properly on an 89 WITH the
> >new
> >>Hardware version. It appears that the planes are unable to toggle fast
> >>enough to cause the greyscale appearance, I'm not sure if this is due
> >tthe
> >>hardware change or a possible slowdown somewhere in the ROM's auto-int 1
> >or
> >>the ROM's getkey-like keyreading routine.
> >
> >This is probably due directly to the internal buffering scheme in the
gate
> >array of the newer hardware configuration.
> >
> >> .... I'd also like to know, if possible, what the hardware
> >>change is in the new versions in order to see about getting my assembly
> >>programs to work properly. I'd primarily like to know what the
> >>nature/purpose of the change was and how it affects the programs.
> >
> >I'm sorry, Scott, but the folks aren't stating beyond what information I
> >was able to gleen. However, I'm certain that with the 68K SDK; you
should
> >be able to get the databases/ include files of pertinent addresses,
> >equates, etc. If the pertinent datums are not there; please contact me
> >again; I'll do what I can to get better information and answers at that
> >time.
> >
> >
> >Sincerely,
> >
> >
> >Paul Fischer
>
>---------------------------------------------------------------------------
> ------
> >Texas Instruments Educational & Productivity Solutions
> >TI-83 Plus Software Development Support
> >E-mail: ti83beta@list.ti.com
>
>---------------------------------------------------------------------------
> ------
> >
> >
> >Please respond to ti83plus@list.ti.com
> >To: "Scott Noveck" <noveck@pluto.njcc.com>
> >cc:
> >
> >Subject: TI-89 ROM 1.05 vs 2.00 version inquiries
> >
> >Hi Scott;
> >
> > Just keeping you apprised of status; no answers (yet). The
> >TI-89/92/92+ folks have been busy on another task this last week to ten
> >days. I'll be back with the S/W designers for the 89/92 tomorrow;
they
> >needed a day of "grace and respite" as they have been working shall we
say
> >'under duress' lately. I'll be back in touch within 5-6 busines days;
> >sooner if I get a satisfactory resolution to your inquiries . And
> >"Thank You" for the patience - I understand waiting is hard to do. .
> >
> >
> >
> >Sincerely,
> >
> >
> >Paul Fischer
>
>---------------------------------------------------------------------------
> ------
> >Texas Instruments Educational & Productivity Solutions
> >TI-83 Plus Software Development Support
> >E-mail: ti83beta@list.ti.com
>
>---------------------------------------------------------------------------
> ------
> >
> >
> >
> >Please respond to ti83beta@list.ti.com
> >To: "Scott Noveck" <noveck@pluto.njcc.com>
> >cc:
> >
> >Subject: Re: TI-89 ROM 1.05 vs 2.00 version inquiry and possible
> reasons
> >forreloading to a prior ROM load don't work
> >
> >Thank you for the clarifications. They help!
> >
> >
> >Sincerely,
> >
> >
> >Paul Fischer
>
>---------------------------------------------------------------------------
> ------
> >Texas Instruments Educational & Productivity Solutions
> >TI-83 Plus Software Development Support
> >E-mail: ti83beta@list.ti.com
>
>---------------------------------------------------------------------------
> ------
> >
> >
> >
> >
> >"Scott Noveck" <noveck@pluto.njcc.com>@list.ti.com
> >10/13/99 09:57 PM
> >Sent by: owner-ti83beta@list.ti.com
> >To: <ti83beta@list.ti.com>
> >cc:
> >
> >Subject: Re: TI-89 ROM 1.05 vs 2.00 version inquiry and possible
> reasons
> >forreloading to a prior ROM load don't work
> >
> >
> >>1. You have a TI-89 with a "Hardware Version 2.00" on the about screen.
> >> (There exists a small question/ambiguity regarding whether the ROM
> >>associated with this about screen is version 2.00 or Rom 1.05 with a
2.00
> >> screen message - we are not certain of the interpretation of
"come
> >with ROM v1.05 natively").
> >
> >Sorry about being ambiguous - I should know better than to be unclear in
> >bug
> >reports =) The TI-89s' (I've seen 4 of the Hardware Version 2.00 ones
> >now)
> >about screens label them as "TI-89 Hardware Version 2.00" and lower down
> >report ROM version 1.05. Any attempt to send the product code from a
> >calculator with ROM v1.00 or send version 1.00 from a computer fails
> >(invalid checksum error). This is NOT the case with "older" 89s that
have
> >been upgraded to ROM v1.05 and are NOT labeled Hardwate Version 2.00.
> >
> >>2. The TI-89's previously came with ROM version 1.05
> >
> >Yes.
> >
> >>3. You cannot reload version 1.05 ROM (which I assume has a ROM 1.05
> >>about screen) via the graphlink cable.
> >
> >No, you cannot "downgrade" to the version 1.00 ROM via graphlink or
> >calc-to-calc product code transfer. Many people prefer the older version
> >of
> >the ROM, as ROM version 1.05 changes the addresses of the tios::kb_vars
> >and
> >tios::MaxHandles ROM addresses.
> >
> >>4. There are various ASM program failures with the ROM 2.00.
> >
> >Yes. I'm sure TI is aware that there are shells that install their own
> >kernels on the 89. The kernels allow the programs to have support for
> >features including ASM library support and BSS blocks as well as the
> >ability
> >to make ROM calls without the ROM_CALL macro, among other things. Some
> >versions of the kernel that install on a "old" 89 will freeze on
> >installation on a "new" 89.
> >
> >In addition, several greyscale programs. . . well, the greyscale doesn't
> >work =) I'm sure that you're aware of the method used to obtain
greyscale
> >on the calculators by rapidly switching the screen between two "planes"
> >via
> >an interrupt. Several 89 programs that work perfectly on the v1.05 ROM
> >without Hardware Version 2.00 fail to display properly on an 89 WITH the
> >new
> >Hardware version. It appears that the planes are unable to toggle fast
> >enough to cause the greyscale appearance, I'm not sure if this is due
tthe
> >hardware change or a possible slowdown somewhere in the ROM's auto-int 1
> >or
> >the ROM's getkey-like keyreading routine.
> >
> >>Your question is......"Can/is the failure to downgrade back to a prior
> >>version of the 89 basecode (TI-89 ROM version1.05 (with a v1.05
> >screen))
> >
> >That's part of it. . . I'd also like to know, if possible, what the
> >hardware
> >change is in the new versions in order to see about getting my assembly
> >programs to work properly. I'd primarily like to know what the
> >nature/purpose of the change was and how it affects the programs.
> >
> >>- is this failure related to a prior (or current) logic or physical
> >design
> >>fault at U9 <which can (?) corrupt both the -89's ROM and its
> >>checkbyte>, which then
> >>a. Corrupts the current ROM load, as well as
> >>b. Prohibits downloads of any other ROM <via the graphlink , or for
that
> >>matter , any other media>.
> >
> >Not exactly. . . please see
> >http://d188.ryd.student.liu.se/ftp/calculator/ti89/tech/89hw.txt for more
> >information. The following quote from that page explains the bug (I
> >apoligize for the type, the bug is in u8, not u9):
> >
> >------------------------------------
> >The flashrom is protected by a special chip U8, which only let you
> >write commands to the chip when it is in a mode only possible
> >to get it in to by writeing to $1c0000-$1fffff after 3 or more
> >readacceses in a row from $200000-$20ffff, 0x212000-0x217fff
> >or 0x21a000-0x21ffff. In its normal mode this chip also
> >protects the area 0x210000-0x211fff from being read, in
> >this area is a small number of bytes which probably are the
> >calculator specific certificate code. It is possible to disable U8,
> >eighter
> >by
> >adding a small switch making CS go directly to the rom instead through
U8.
> >Simply connecting the CS-line direcly does not work, the bootloader
> >contained
> >in $200000-$20FFFF (an area writeprotected by a feature on the flashrom
> >_and_
> >by U8) checks wether the U8 works before it branches to the writeable
> >part of the ROM. (the switch should connect the pad below pin 10 on U8
> >to eigther pin 10 or pin 9).
> >The other way is to do branch to somewhere in $200000-$20ffff,
> >0x212000-0x217fff
> >or 0x21a000-0x21ffff, to normal executable code wont do, because every
> >write
> >that uses a register to determin adress is preceded by a read from a
> >"wrong"
> >area, BUT by branching into code that is not intended to be executable,
> >but
> >happens to be it anyway, a lookup table or text-string for example,
> >which happens to generate 3 reads from "right" areas before a write to
> >a selectable adress, and then getting trapped for an illeagal instruction
> >or
> >similar, then U8 can be disabled. It does work.
> >It seams to me it is possible to make the calc unuseable by clearing the
> >area
> >that is read-protected, the bootloader in the first 64k that is
completely
> >write
> >protected and checks a byte in this area, if incorrect value, it stops
> >with
> >the
> >message "Corrupt certificate memory" or something similar, without ever
> >giving
> >the user a chans to install new software (or certificate memory). (the
> >software
> >that recieves and writes new software is completely in the first 64k i
> >think).
> >BUT this is nothing im sure of, and would be happy if someone could
check.
> >-------------------------------------
> >
> >Following this logic, not only can the ROM be modified bug it can also be
> >destroyed to the point where it cannot be fixed by flashing the ROM back
> >in.
> >
> >A good example of the use of this bug can be seen in Archive Utility
2.00,
> >an assembly language program available at
> >http://www.ticalc.org/archives/files/fileinfo/91/9182.html which modifies
> >the ROM to prevent clearing of the archive on a crash. The source is NOT
> >included with this program.
> >
> >It is also theoretically possible for an assembly program to change a
> >calculator's serial number, allowing it to receive digital certificates
> >necessary to run the "applications" that should be supported in v2.00 of
> >the
> >ROM (right?). Seeing as how there are commercial applications for the
83+
> >depending upon this, it seems like a large problem to me.
> >
> >>Just making sure I..we.. have the problem understood here. My
apologies,
> >>Scott, I'm not a "TI-89 cognitive" person by any means; just making
> >>certain I'm also not caught as a 3rd-party individual due to
> >>misunderstanding of the technical information.
> >>As stated , your inquiry has been forwarded to TI-89 staff. I will
keep
> >>you advised of the status of this inquiry, even if "no progress/status
> >>still pending".
> >
> >I undestand, and I thank you for your support for those of us who program
> >these calculators. For the most part, I'd just like to know what is
> >causing
> >these problems with programs not running properly.
> >
> > -Scott Noveck
> > ACZ member
> > http://www.acz.org
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
References: