[Diy_efi] Re: if YOU were bored enough to disassemble...
Brian Dessent
brian at dessent.net
Thu Aug 29 02:51:15 GMT 2002
"Dave Gallant, 12 Point Racing" wrote:
> This was my guess as well, as the Ducati 748 and the Ducati 916 share the
> code, all except for the data segment. (The code segment shows variations as
> well, however slight and mostly offset changes). I have overlaid the maps of
> the 748 and the 916 (748 revs higher due to shorter stroke - has different
> fuel and timing requirements) to find the offsets of the maps are identical.
> I have been using this method in search of the holy grail - the rev limiter
> - looking for singular variations in the data segment that would raise or
> lower the end value. (I am told the highest possible value is 12k due to
> limitations in the code segment).
There's another thing that I forgot to mention in the last email, which
might be a way that various configurations are supported with one code
base. The last 48 bytes of the code segment, $d6a3-$d6d2 (the last data
before all the $ff's that pad things out to $f000) represents code for
an interrupt vector jump table. Each entry is 3 bytes, corresponding to
opcode $7e (jmp) plus the address. This is copied to RAM at $03d0
during startup. Anyway, if this block of bytes changes between BIN
files (I have not checked) it could dramatically alter the program's
operation.
Another note, in my DHC11 .cfg file, I have nuked the first 32k from the
ROM image since it's all $FF, and to get around this interrupt service
routine problem I just added the vectors directly and commented out the
standard ones in high memory ($ffd6-$fff4.) Just a note for the record
in case someone else is working on this too.
"Dave Gallant, 12 Point Racing" wrote:
> For more entertainment, here is a Ducati 916 BIN file:
>
> http://www.12pointracing.com/DucatiMaps/Ducati916.bin
Brent Prindle wrote:
> I am working on the same controller for the Guzzis and Laverdas. Mostly
> trying to interpret the code for the Aprilia right now, which is a
> completely different controller. Have it disassembled, need to figure out
> what is happening...
>
> If you want some more reference points, I happen to have a few other EPROM
> files for Ducati. Let me know if you want them, some may have different
> rev-limits since they are from race programmes.
>
> -oo
> BrentP at motobits.com
> Brent Prindle
Excellent. We should really put these on the diy-efi server so that
anyone that is looking for this info can find it. The /pub/incoming
directory is publicly writable, and I think that's the traditional
spot. If you do upload stuff there, try to use a descriptive name or
include a README.
> This segment seems to differ slightly between the 748 and the 916, of which
> I am not sure why. I am really not sure what this section does.
It's a nice even 512 bytes, and is squarely braketed on either side by
code. My current guess is that it's a watermark or ID sequence of some
sort. It could also be a part of a vendor's library code (for keeping
track of who's using the code or something) but this seems a bit far
fetched. And any embedded library that squanders 512 bytes of code
space for an ID pattern seems like it wouldn't fly with developers for
very long.
> Interesting enough, I started graphing these on different offsets and found
> that they were indeed starting on odd offsets. I (not knowing enough other
> than to be dangerous) did not think twice about this. F160 and F162 offer up
> terribly strange looking graphs, while the offset F161 is a smooth 3D graph.
> I have graphed the three maps and have links below.
After more thought, it's not *that* odd. If this were a 16 bit
processor it would be a lot weirder, but since the data bus is 8 bits
wide it doesn't really matter. Another thing you can do to look for
interesting stuff in the calibration area is search for the references
in the code. Here are the ones I found with a quick grep:
#$F000 #$F028 #$F038 #$F061 #$F081 #$F0A1 #$F0C1 #$F0E1 #$F101
#$F111 #$F121 #$F131 #$F151 #$F161 #$F262 #$F362 #$F372 #$F382
#$F392 #$F3A2 #$F3C6 #$F3E6 #$F3F8 #$F415 #$F425 #$F435 #$F44D
#$F45D #$F46D #$F480 #$F4A0 #$F5A0 #$F5B0 #$F5C0 #$F5E0 #$F5E2
#$F5F2 #$F602 #$F612 #$F614 #$F61D #$F62E #$F634 #$F63C #$F649
#$F654 #$F663 #$F677 #$F6F3 #$F713 #$F71C #$F750 #$F758 #$F858
#$F8DF #$F8FF #$FA00 #$FB01 #$FB11 #$FB21 #$FB31 #$FF00 #$FFA4
Obviously this isn't too useful by itself. But since $f161, $f4a0, and
$f8ff are all there, it's a good sign we're on the right track. Most of
the above are probably just single byte or word parameters, but I know
that some of them are lookup arrays and such. What you can do though,
is then search for these in the code and work backwards from there. For
example the code that seems to do some fuel map ($f161) calculations is
at $98cf (sub-72 in my listing.) Note also that there's another table
used at $f262, which could be a correction factor for the other injector
or something. The code also implies that vars L00D6, L00D8, and L00DC
probably have something to do with the final injector pulse width; and
also that L01E5 and L010F seem to have something to do with the
coordinates of the map lookup. So, I'd then go rename these to
something along those lines, and then examine all the other references
to them. That would be my method, at least.
> I am sorry, but I do not know what an n-alpha system is? 68HC11 is the
> processor - is this saying the same thing?
By "alpha-n" I meant as opposed to "speed density" or "MAF" -- i.e.
alpha-n systems calculate based only on throttle angle and RPM. That's
what we have here, right? (ignoring bar/CTS/etc for the momemnt...)
> Great work - I wish I had your tool when I first popped open this BIN file.
> I have been playing around in it looking at it in HEX. :/
(I used photoshop for that -- rename the file .RAW and then you can open
it with any pixel dimensions you want. The change the mode to "indexed"
and apply whatever color table you want, I used the "blackbody"
gradient.)
Another thing I wanted to mention is that we should probably investigate
the code that measures RPM, since its used everywhere else and you're
interested in killing the rev limit. So... you said that it uses a 50
tooth wheel crank sensor. If I were a betting person I'd wager that it
uses one of the TIC (timer input compare) pins for this input signal.
>From the datasheet: "The input capture function records the time an
external event occurs by latching the value of the free-running counter
when a selected edge is detected at the associated timer input pin."
The register that determines which timer pins cause an interrupt is
TMSK1, so a quick grep for this reveals:
8021 staA TMSK1
87AE bclr TMSK1, #%00100000
9421 bset TMSK1, #%00001000
9463 bset TMSK1, #%00100000
94A8 bclr TMSK1, #%00001000
9583 bclr TMSK1, #%00100000
9591 bclr TMSK1, #%00100000
A5BB bset TMSK1, #%01000010
A5FF bset TMSK1, #%00010010
A803 bset TMSK1, #%01000010
A836 bset TMSK1, #%00010010
A868 bclr TMSK1, #%01000000
A8B0 bclr TMSK1, #%00010000
AB52 bclr TMSK1, #%01000000
AB64 bclr TMSK1, #%00010000
AB7A bclr TMSK1, #%00000010
ABAA bclr TMSK1, #%00000010
ABDE bset TMSK1, #%10000000
C2E9 staA TMSK1
C3EC staA TMSK1
CD65 staA TMSK1
CF4C bset TMSK1, #%00010000
CF6F bset TMSK1, #%01000000
CF87 bset TMSK1, #%00000010
D3D0 bset TMSK1, #%00000010
D4E2 bset TMSK1, #%00000010
In all the "staA" cases except $cd65, A contains 0, so we'll ignore
those. The TIC bits are the lowest 4 bits, and TIC4 doubles as TOC5. So
from this, it appears that TIC2 is used a lit, and TIC4 might be used,
or it could be an output. Anyway, TIC2 corresponds to pin 41, so if you
could take a look at the board and see if it looks like the crank
position sensor is in any way related to pin 41 (perhaps through a
buffer/amplifier circuit) that would seal the deal. It could also be
TOC4, pin 39.
Additionally, I would also bet that the injectors are driven with the
TOC pins (timer output compare) as they are designed for this very
purpose: load a register with a value corresponding to a pulsewidth.
Based on the above, I'm guessing that TOC2 and TOC4 drive the injectors,
but it could be 3 or 5. It looks like TOC1 is used but it's only set in
one place so it seems like the others are more important. Anyway, it
would be worthwhile to trace these pins to the injector driver
transistors. The pins are 35-38 corresponding to TOC1 - TOC4.
Brian
_______________________________________________
Diy_efi mailing list
Diy_efi at diy-efi.org
http://www.diy-efi.org/mailman/listinfo/diy_efi
More information about the Diy_efi
mailing list