Now I'm throughly pissed off -- READ THIS
-Scott
-----Original Message-----
From: p-fischer@ti.com <p-fischer@ti.com>
To: noveck@pluto.njcc.com <noveck@pluto.njcc.com>
Date: Tuesday, November 23, 1999 3:07 PM
Subject: TI-89 ROM 1.05 vs 2.00 version inquiries & Grayscale, etc.
>Scott Noveck,
> Scott, regarding your last additional inquiry; I will ask for
>your patience and a bit of understanding. This is not going to be a
>satisfactory solution to the the questions you are asking....
> I have been instructed to refer your questions to the customer
>service center; and that my job tasks and descriptions do not go outside
>the scope of the TI-83 Plus. May "I" recommend that you have a bit of
>patience; the '92+ SDK is in process & your questions would be appropriate
>for the staff of that SDK. You may also attempt of interface with
>additional peers in the TI-89/92/92+ programming community; they may be
>able to assist.
> I not attempting to ignore you or your questions; but much of
>what your asking is sensitive, both internally and externally, for several
>reasons, some of which I'm not probably not even aware of..... I do not
>know if this sensitivity is company-to-company competition; current or
>prior legal tests of propritary software trademarks/copyrights and
>changes in this status if released "external to the corporation"; ; "too
>many" questions on 92+ behaviors coupled with too few staff; or several
>other reasons. In any case, I cannot assist regarding questions outside
>the scope of the TI-83 Plus. My apologies,... I'm sorry.
>
>Sincerely,
>
>Paul Fischer
>---------------------------------------------------------------------------
------
>Texas Instruments Educational & Productivity Solutions
>TI-83 Plus Software Development Support
>E-mail: ti83beta@list.ti.com
>---------------------------------------------------------------------------
------
>
>
>
>
>"Fischer, Paul" <p-fischer@ti.com>@list.ti.com
>11/23/99 11:34 AM
>Sent by: owner-ti83beta@list.ti.com
>To: "ti83beta@list.ti.com - Support email for TI-83 Beta SDK"
><ti83beta@list.ti.com>
>cc:
>
>Subject: FW: TI-89 ROM 1.05 vs 2.00 version inquiries
>
>
>Forward of Mail -
>
>-----Original Message-----
>From: Scott Noveck [mailto:noveck@pluto.njcc.com]
>Sent: Sunday, November 21, 1999 1:34 PM
>To: Fischer, Paul
>Subject: Re: TI-89 ROM 1.05 vs 2.00 version inquiries
>
>Sorry for taking so long to reply -- I wanted to try and test this, and it
>hasn't quite worked =)
>
>I'm trying to get a greyscale routine to work based on the information
>you've provided, but something is still not working correctly. It seems
>that port ($600010) - which should hold the address of the desired display
>page divided by 8 - still doesn't want to display 0x5c00, 0x6c00, or
>0x7c00.
>Could you double check these addresses? The port still takes the address
>divided by 8, correct?
>
>I've included a simple grayscale library and source that I'm hoping your
>"expert" could take a quick look at; I've put detailed comments on every
>line. I'm using tios::heapalloc to create a buffer, storing 3840 bytes at
>0x7c00 in that buffer, then installing an interrupt that quickly switches
>between the two display pages. Every time the page is switched, it is
>copied to itself (similarly to the section of code you listed below, but
>much more optimized for speed). When the grayscale is done, the memory
>from
>the buffer is copied back to 0x7c00 and is freed.
>
>Unfortunately, the program still doesn't show grayscale on a real
>calculator, although it does on a specially modified version of the
>emulator
>that works based on the changes you listed. It seems that either there is
>an incorrect address or I and others have misinterpreted your message.
>
>I've attached a couple files: The gray4lib source, the header file
>listing
>usage, an assembled version of the library, and a copy of the game
>solitaire
>that uses the library for greyscale (and the other libraries that it
>needs).
>I'd appreciate it if you could pass this along and ask if there's anything
>else that I'm not aware of. Thanks!
>
> -Scott Noveck
> ACZ member
> http://scott.acz.org
>
>>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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>