A83: Flash Memory

[Prev][Next][Index][Thread]

A83: Flash Memory


The following is a log of my attempts to write to Flash with base code
v1.12.
19/08/2000

    As a preface I've decided to talk a little of my reasons to gain flash
write access. I'm not trying to prejudice TI's economical interests thought
I do not approve selling the rights to do freeware thus non commercial apps.
Furthermore, having recently ported Sqrxz to the 83+, I experienced the joy
of the hardware limit, code cannot run after C000h. What I want to achieve
is code patching like Archive Util on the 89/92+, such methods can largely
expand the possibilities of Asm programming.

That's all for the ethics, now here's the interesting stuff:

Nomenclature:
Invoke is an alias BCALL
TI s/d means TI simulator-debugger


After having spent 4h49m tracing with the TI s/d the following code will
happen to archive a program, with its name correctly written in OP1 :

Invoke(_ChkFindSym)
JR C, Not_exists

runs at 63B1h ROM page 07h
CALL 2C46h
DI
CALL 63DAh
CALL 2C4Ch
LD HL, (83F3h)
LD DE,(83F7h)
CALL 1891h
RET

You can include this piece of code in your program and run it, it will work.
I'll now start detailing this short snippet.
TI doesn't only use BCALL's to access routines on other ROM pages, the two
calls that start with 2C46h use similar code that RST 28h to change pages...
The DI before the call to 63DAh may seem suspicious, but this call doesn't
seem to write to flash, I haven't traced it so I cannot tell if it hides any
secrets. But I can say that the call to 2C4Ch does write. By tracing that
last call, we land at 6F7Eh ROM page 1Dh, which -if you care to look at the
TI-83+ SDK- you'll notice is a privileged area. I spent 3 hours tracing that
part of code, here's an extract of what I've copied:

PUSH AF
LD A,01h
NOP
DI
NOP
NOP
IM 1
DI
OUT (14h), A
CALL 01A9h
POP AF
[...]
CALL 7646h
JP C,4606h
BCALL(8021h)

As you see, more mysterious code is still to come, the call to 01A9h will to
check if we are at ROM page 1Dh, if not, TI will kindly reset the calc. Also
in our mysterious series, check out this snippet I came across:
LD HL, C000h
LD A,(HL)
LD B,A
CPL
LD (HL),A
LD A,(HL)
CPL
CP B
JR NZ,Reset
LD (HL),A
Strange things happen on ROM page 1Dh, the piece of code above is useless
since before a DI is executed, unless hardware comes to interfere. I'm
finished with all this spagetti code (IMHO), here comes the serious part.
BCall's 8021h & 8087h are known to write to flash, but one needs to unlock
it first. If you look at the code that runs on page 1Dh, you'll be able to
notice that a call to 7646h is made before writing, I've traced that code,
what it does is read the first few bytes of some "writable" flash pages and
do numerous checks on them. There is a variant to this code that runs at
7618h and that is called before writing several bytes to flash at once.

Dan Englender has convinced me that's more the area where the code is run
from than the code itself that's important, thus the change of tactics
observed below.

I stopped tracing Arc_UnArc as it's code was far too complicated, between
symbol table relocation... So I decided to find a simple function that would
only write a few bytes, GarbageCollect wouldn't do it nor ResetMem, but I
can remember reading in a FAQ that the first byte of each "writable" ROM
page is used to identify if the page is being used or not (question relative
to how the TI-83 maintains archived variables after a crash). Thus I put a
breakpoint on 810Ch and deleted an App, and only the first byte was changed
from 80h to 00h. After having backtraced a bit I found a nice little
routine, which I'd call DeleteApp:

LD A,page_of_app
CALL DeleteApp
[...]

DeleteApp:
PUSH AF
LD A,1Dh
OUT (06h), A
POP AF
JP 2C1Ch

This little routine successfully works on a real TI-83 Plus, If you don't
believe me try it, CalcSys indicates the ROM page it's on.
So it's just another routine like Arc_UnArc - you could say. Well my point
of view is that this routine only changes one single byte of flash ROM
without any complicated checks, thus by tracing further we should be able to
write anywhere on Flash.

That's all for now, I'll surely come up soon with another article with even
more
interesting info. Till then.

Solignac Julien
x1cygnus@xcalc.org
http://xcalc.org
Follow-Ups: