-------------------------------------------------------------------------
written by Johan Borg, johbo050@student.liu.se.

This text assumes some basic knowledge in how
microprocessorsystems in general work,
and will probably make very little sense to anyone else.
(this text is about the HW1.0 calc, some is probbably correct for other
versions too, but not alot) 
-------------------------------------------------------------------------

Some time ago, I got the idea of writing a nice little program
for patching the flashrom in my ti89, and some days ago I started 
to try to find out how to write to the flashrom chip, a LH28F160S3T 
made by sharp(www.sharpmeg.com), the pdf appears to have
disappeared from their site though can however be found at:

ftp://d188.ryd.student.liu.se/calculator/ti89/tech/f160s3.pdf

Anyway, it is a 2MByte chip, can be configured for 16x2^20 or 8x2^21, 
and have nice protection features, implemented in the ti89 in a
way that makes it impossible to ever write to the first 64k of the
flashrom chip, without disconnecting the WP-pin on the flashrom from
ground and connecting it to Vcc. it's quite simple to write to normally, 
but NOT in the TI89. This is why:

anyone who has opened their calc should have noticed U8, a so16
mounted directly below the flashrom chip, perhaps looked for some 
info on it, and discovered that orbit, who made it, makes just
about nothing ASICs and probably given up all attempts to find out what
its for.

after having spent some days trying to write to the flash the
normal way (move d0,(0) sending it the command for "erase block"
and then for "write..") without any progress whatsoever, I looked at
how the OS does it: it writes to 0x1Cxxxx, after disabling
autointerupts and LCD update (clears bit 1 in 0x600015).
so, I did the same thing, still without any progress. 
so, I hooked my calc to my oscilloscope, attached a cable to WE
on the rom, another to CE (actually there are 2 CEs on the ROM
but only one of them is used), result: 
my write never reached the flashromchip. the writes from the
rom-routine ocured just fine however. why?

I kept trying with some different software aproaches, even
copying the flashroutines to ram, moving the vector (to trap #$B,
all archiverom functions (2) are called through it) acordingly.
even this failed.

why would a routine work just fine when executed from the rom,
but not at all when executed from ram? because the chip U8
protects the flashrom from being written to, and the protection 
can _only_ (in software that is) be turned of by writing to anywhere
in 0x1c0000-0x1f0000, from somewhere in 0x200000-0x20FFFF,
0x212000-0x217fff and 0x21a000-0x21ffff with 3 reads from 
those areas imidately prior to the write to anywhere in 
0x1c0000-0x1f0000. The 0x210000-0x211fff and 0x218000-0x219fff
areas are READ protected when the write protection is enabled 
(anyone who have done 2 romdumpes directly after each
other might have noticed these areas to differ, or, for some
strange reason, the 2nd seams to be steady at 0xffff, but
anyway...) hopefully, the certificatecode is stored in one of
these areas (hopefully because they are easily(?) programed)
the area 0x200000-0x20ffff can never be written to with U8 in
place. 

the protection can be turned back on by doing the same thing as
when disabling it, but READING from those areas instead.

if an attempt have been made to disable the protection from the
area 0x2c0000-0x2f0000, (which will fail) the chip wont accept 
any valid disable requests until its been powered down
and up again it seems..

how I figured this things out? I traced all the pins (but one 
sadly but unimportant) to pins with known functions, as follows: 
1->A20 ... 5->A16  6->R/~W  7->CE-ram  8->gnd  9->CE-rom (from
uP) 
10 -> CE for ROM  11 -> OE for ROM  12->? (high when the calc is 
on, low otherwise, reset perhaps)  13->A13 .. 15-> A15  16->Vcc,
and desoldered U8 from the calc, and connected it directly to my
printerport, (using some cable and a Dsub25 of course) hoping it 
would withstand and function on 5v which it did (it normally runs 
on ~3v in the calc), and wrote a small program for reading 
and writing to the adresses of my choice. The rest was simple.

a very useful file was
http://www.geocities.com/SiliconValley/Peaks/6869/cpu.html 
(contains pinout of the uP chip with many pins identified) the
other pages around there are 
nice too, but not much applies to the ti89 though.
and of course Lowlevel.txt from the fargo documentation is very
useful.

so, how do you write to the flashrom anywhere you like? (well,
writing in the first 64k requires the WP-pin on the flashrom to 
be moved from GND to Vcc but you probably wouldnt want to write 
there anyway, because bootloader (the one activated by holding 
down APPS when the batteries are inserted) amongst other things 
are placed there, or at least, I _hope_ the bootloader entirely 
contained in that part of the memory).

perhaps, one could download the ROM (using "send product code")
patching the part that contains trap #$B so that it is no longer 
limited to operating on the archive part of the flash, and 
recalculate the checksum  and sending it back to the calc. 
This will probably work, as the part of the rom that contains trap 
#$B is at least transmitted by "send product code" and is
therefor probably also written during "receive product code".

OR, add a small switch, connecting the ROM-CE either to U8 pin 10
or to U8 pin 9 directly. It doesnt work to have a permanent 
connection between the later, the calc refuses to boot
correctly, this is probably because the OS probably uses the
"holes" created by the readprotection before it has remapped 
the rom from 0x000000 to its normal position. 
this does work just fine, except it involves opening the calc,
desoldering a single pin in a so16 and some soldering. 
Unfortunatly, I think many people think this is a lot of 
work, and dangerous to the calc, and does anyway not have a
soldering iron or know how to use it correctly. 
(I've done this in order to find out whether the writeprotection 
inside flashrom chip is used, and in what extent (used for first
64k))


btw, i happened to notice that Autoint 3  is triggered shortly
after 0x600015:2 is set, if anyone would care to find out what 
its for and what the other bits in ..15 does, the 2 lowest 
enable row and column clock to the LCD drivers it seams and 
7 affects the calc to in some way... 

I've also tried to increase the speed of my calc a bit, 
15MHz works just fine, the current used increases linearely
in "busy" mode, and not at all in standby (when the calc is on
but not doing anything)
20MHz does not work well
the C10 and R12 are the external components used by the
main oscillator. (Directly to the right of the uP chip)

-------------------------------------------------------------------------
written by Johan Borg, johbo050@student.liu.se.
-------------------------------------------------------------------------