[Diy_efi] Re: if YOU were bored enough to disassemble...

[Brian Dessent]

"Dave Gallant, 12 Point Racing" wrote:

> And with this map, I can't even wager an educated guess. Possibly this is a
> correction map of some sort...Overall, I am missing the location of the
> secondary fuel map, however my first guess would be this is a timing
> adjustment map for the coolant temperature sensor. (I am told timing is
> pulled out as the bike's coolant gets hotter and hotter, and it is not
> linear. I would LOVE to kill this calibration factor at some point). Of
> course, this is just a guess, and it quite possibly could be some strange
> correction map for the secondary fuel map. This is where having a CLUE as to
> what the code was doing would be worth its weight in gold. :/
> 
> Keep the thoughts coming - it has only taken you guys 1 day to get as far as
> I have gotten in 1 month. :)

Well, I've been tinkering with this, I guess because I'm bored or
something... :-)

Anyway, I've been using Peter Gargano's DHC11 disassembler
(http://www.techedge.com.au/utils/dhc11.htm) because I think the output
is prettier.  Beware that it renames a few opcodes from the "standard." 
Anyway, my setup is currently a huge kludge of Perl scripts, but I've
been making progress.  You can see my current disassembly here:

http://www.dessent.net/tmp/748.DIS

As you can see I've assigned names to the subroutines that are a little
easier for a human to understand.  I've also poked around in a few of
them and given them a meaningful name.  Same with some of the variables,
although most of them are still Lxxxx.

The biggest problem with getting a meaningful disassembly is the use of
jump tables.  This makes things pretty frustrating because the
disassembler has to know about all the entry points, otherwise the
listing is either a bunch of un-disassembled bytes (dw, db, etc) or
gibberish because it's trying to disassemble stuff that isn't opcodes. 
I think I've gotten all the entry vectors covered now, but there are
probably a few subroutines left.  It's an iterative process, every time
you uncover some code you have to go and check any new dreaded "call 0,
X" statements -- or even worse: "ldx <var>; call 0, x"  This is the
worst because it's jumping to an arbitrary pointer.  So then you have to
track down any possible values for <var> and make sure the disassembler
knows about them.  But even worse then that are these stupid
3-byte-per-entry vector tables where the code searches for a lookup
index value (the first byte) and then calls the corresponding address
(the other 2 bytes.)  I resorted to just adding a 1-entry vector (to the
.cfg file) for each entry in these type tables.  This is an example of
what I'm talking about:

C903    vec9_00-0
C903            ldX     #$C83E
C906            call    sub-41
C909    vec9_00-1
C909            ldaA    #$09
C90B            staA    L00A2
C90D            bset    L0081, #%10000000
C910            jmp     0, Y

"sub-41" searches through the table pointed to by X for a value that
matches A, and returns the corresponding jump pointer in Y.  A big mess
if you ask me.

Other stuff:

I tried give meaningful names where possible.  I've also added the
mneumonics for the HC11's registers, which helps to interpret the code. 
Note that the ECU maps the HC11 registers to the first 4k page, so they
show up as $0000 - $005f, instead of the usual $1000 - $105f.  I'm
assuming we're dealing with a "F1" family (ie mc68hc511f1) since I
noticed from your pics that the MCU is a 68 pin plcc, and the only
family with this package is the F1, accoring to motorola's site.  (BTW
if you haven't gone there yet and grabbed all the tech manuals, do that
now, there's a buttload of stuff.)  Oh and if you want to start poking
around with tracing pins, start with the A/D inputs, pins 59-66 (see
datasheet for a picture of how to identify the pins.)  Surely these are
connected to something interesting...

Anyway, (one of...) my config file for dhc is here:

http://www.dessent.net/tmp/748.cfg

That doesn't include all the renaming that I do (it's a multi-step thing
I do with some scripts) but it's enough to get the basic disassembly. 
There's also some notes where I was analyzing some of the
interpolation/math assembly stuff (and other random junk):

http://www.dessent.net/tmp/notes.txt

Also, I hacked together some perl to use the GraphViz library to make a
neat digraph of all the function calls.  Check it out: (you'll want to
zoom in with your PDF viewer to make sense of it all.)

http://www.dessent.net/tmp/748-asm-graph.pdf

The interrupt routines are differentiated from normal subroutines by the
polygons vs. ellipses.  Edges correspond to "CALL" instructions.  The
routines named "vec_..." were derived from the vector jump tables, the
"sub-...." routines are ordinary subroutines.  And if you must know, I
numbered the sub-'s in order of call frequency, so the low numbered ones
are called most (in the static disassembly at least.)

Brian

_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi