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
>
>
>
>
>
>
>
>
>