A89: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
[Prev][Next][Index][Thread]
A89: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
Make what you like out of this, although I'm still waiting for something
more detailed. I did some simple benchmarks with some 89s in school today,
and it does appear that the new ones are about 20 to 30 percent faster,
which would coincide with the 20% difference between 10 MHz/12 MHz
processors. . .
-Scott
-----Original Message-----
From: p-fischer@ti.com <p-fischer@ti.com>
To: Scott Noveck <noveck@pluto.njcc.com>
Date: Monday, October 25, 1999 2:59 PM
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
>
>
>
>
>
>
Follow-Ups: