Dissassembling BINS

lance lmwolrab at earthlink.net
Thu Aug 23 06:48:02 GMT 2001


I noticed that you refer to at least one of the big Japanese outfits using
Motorola processing.  Does anyone know about the ND processors that Toyota
uses?  I have tried to find information, or even a place to start looking
for information about the processors that Toyota uses in their later model
cars.  I am not able to find anything useful.  Does anyone have a good place
to start investigating something like this?

Lance Wolrab

-----Original Message-----
From: owner-diy_efi at diy-efi.org [mailto:owner-diy_efi at diy-efi.org]On
Behalf Of Christian Hack
Sent: Wednesday, August 22, 2001 22:40
To: 'DIY_EFI-Digest at lists.diy-efi.org'
Subject: RE: Dissassembling BINS


Excuse me if this gets sent twice - it appears the diy-efi DNS
entries are playing silly buggers.

On Wednesday, August 22, 2001 5:50 PM, DIY_EFI Digest
[SMTP:DIY_EFI-Digest-Owner at diy-efi.org] wrote:
> Date: Wed, 22 Aug 2001 14:54:59 +1000
> From: Peter Gargano <peter at techedge.com.au>
> Subject: Re: Dissassembling BINS
>
> Christian (who's in digest mode), let me answer this, please.
>
> Bruce wrote:
> >
> > Could we have a short explaination of what a Code Entry Point is?.
>
> The processor has to "start" somewhere when it is first fired up
> (ie. you switch on the IGN). Motorola uses the convention that
> the last 16 bit word (address $FFFE) holds a value that is fetched
> and plugged into the PC, and the CPU starts executing from that
> address. $FFFE is called the reset vector, and the reset vector
> can be thought of as an "entry point" to the actual BIN's code
> (that's the CPU's code, not the "code" that a lot of people talk
> about when they mean the CPU's data area, ie. the "calibration
> data" area).
>
> There are other vectors at the end of RAM (ie the $FFxx area), and
> these point to entry points within the code.
>
> I would venture that most vehicles use a Motorola, or Motorola
> clone processor, but there are some Intel (or should I say
> non-Motorola ;-) processors out there, and they probably don't use
> this same scheme of having a vector table at the end of RAM.
>

Let me elaborate a bit more on what Peter has said. Disassemblers
like DasmX have a feature called code-threading. I think DHC11 has
this and calls it code-seeking (I haven't had time to look at it yet Peter
:( )

What this means is that if you give the disassembler some of these entry
points it can follow the code from there. It doesn't execute it as such but
looks for things like jumps, branches, returns. By doing this it can
intelligently split up subroutines from each other which can make things
much easier to understand. It will also not disassemble code that it
thinks won't ever run, which can give a good indication as to where the
tables, constants etc are kept.

Every CPU has a reset vector at least. As Peter said Motorola typically
(definitely not always) used the last two locations in memory for initial
program counter. This way isn't as popular anymore since a lot of processors
have more than 64k address space. The typical trend these days is location
0 on chip select 0 for the start address and sometimes stack pointer.
You probably don't need to worry too much for map changes (unless your
trying
to actually disassemble the code).

Definitely GM, Nissan etc seem to stick to Motorola. However Ford seem to
like Intel 8051 based stuff. Holden vs Ford, Motorola vs Intel. You know
how it works...

Christian Hack
DESIGN ENGINEER
christianh at pdd.edmi.com.au
EDMI Product Development Division
Ph : +61 7 3881 6444
FAX : +61 7 3881 6420





----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org




More information about the Diy_efi mailing list