A89: SV: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
[Prev][Next][Index][Thread]
A89: SV: Fw: TI-89 ROM 1.05 vs 2.00 version inquiries
How do you see the difference between the old and the new ones?
------------------
>
> 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:
References: