Jump to content


Recommended Posts

I just wanted to add a few updates.

I've been reading over the 68HC11 architecture, and assembly code in general. While I haven't thoroughly looked at the disassembled code yet, I think I may have some leads as to what to look for.

First off, the 68hc11 processor series has several I/O pins, most of which are digital, and even 8 built-in A/D channels :wacko:

Port B (as it's called) is 8 channels of strictly digital logic output. The rest of the ports are either bi-directional, or analog. So, my theory is that Port B is used to control the fuel injector transistors/ssrs, and possibly ignition spark control. This means that the fuel algorithm and possibly spark algorithm will involve writing data to this memory block. I think I can search the code for any writes into this block and work backwards to see how this output is determined.

Similarly, my best guess would be all analog sensor data is sent to the A/D converter; this includes VAF position, TPS, both 02 sensors, and all 2 (or 3) coolant temperature sensors. Additionally, I imagine the IAT sends its signal here. Let me know if I'm leaving a sensor out (knock sensor?). These addresses, if I can figure out physically which pin on the processor they refer to, can indicate which sensor(s) are associated with which memory address. I haven't looked over the other IC's on the ECU too closely, but I don't recall seeing any external A/D converters. I could be wrong about that one.

Finally, the ECU has 5 external clocks/timing circuits. These have the inherent ability to set interrupts if an input triggers a rising (and/or) falling edge of a digital logic signal. My best guess would be a cleaned up crank and cam position sensor signal is fed into here, and that the entire ECU program is interrupt driven. This means that for every trigger event (i.e. crank or cam sensor senses something) the timer starts, and the computer executes specific code. I believe when it receives the next timing signal, it checks the flags on the timer circuit that set the interrupt initially, and from this you can calculate the amount of time that has elapsed (i.e. this translates into a frequency...or a tach signal...ENGINE SPEED !). From this data, the VRIS, timing, and fuel maps are referenced! However, I'm not sure if between crank/cam signals the ECU tries to predict what the RPM's are (if it's an accel/decel) or if it just lags behind actual speed by one cycle (very tiny amount of time, not sure how much this would affect performance) when determining how much fuel to spray, and when to trigger an ignition spark.

Anyway, if anyone has any ideas, that would be great.

Link to post
Share on other sites
  • Replies 81
  • Created
  • Last Reply

Top Posters In This Topic

^^^ I love you marcin! :rolleyes:

I would say you're right about the clock cycle thing. I'm sure the ECU would lag at least 1 clock cycle, as it cannot predict the future :P and it always takes clock cycles to compute the data in anycase.

I will try and look more into it when I am finished exams. Anyways, back to studying. Good luck man. B)

Link to post
Share on other sites

Ok, some more notes from my digging around today (mostly hardware probing, and cross-referencing pins with memory addresses):

-Turns out I was wrong about a few things above. Mainly the 68HCK series (the only ones with an 84 pin PLCC) have bi-directional I/O on ALL ports.

-Pin 60 appears to control VRIS; the output is fed into some kind of logic gate/register shift gate (part number won't cross reference with anything :( ), which then controls two transistors/ssr's, which in turn send a signal to the VRIS solenoids.

-Pin 60 is also known as "PC5/DATA5" and is located on Port C. The data register address for this port is $0006, and the value of bit 5 determines the state. I'm thinking by searching through the EPROM code for writes to this address and bit, I will be able to find the VRIS code :biggrin:

-I'm thinking that PC5 supplies an 8-bit byte to the other IC (the shift gate, etc.), and the particular combination of this byte is what determines which VRIS is open, and which is closed. I'm thinking 2 bits determine the open/close status of the two VRIS solenoids, 4 are probably used to initiate communication/synchronization, and the other 2 may be insignificant. I'll have to probe through the code to find out.

I'll let you know more as I find out!

Oh, and I have obtained a complete instruction set (i.e. opcodes) for the K-series 68HC11 processor :P so I will be trying to build an assembler/disassembler at some point.

Link to post
Share on other sites
Oh, and I have obtained a complete instruction set (i.e. opcodes) for the K-series 68HC11 processor  so I will be trying to build an assembler/disassembler at some point.

I think Mike94pgt made one at some point, he is on mx6.com (or was), if you search around there and probetalk you may be able to get some info from him.

Link to post
Share on other sites
  • 1 month later...

I'm new to this thread and really interested in what you're trying to accomplish... A couple questions though...

Looking at the great photos provided, I don't see any 68HC11 CPU, as mentioned in one of the posts... Are you sure that this is the processor being used?

I've got a '93 626 ES with auto... Can I make use of this ECU patching? Especially the binaries found in a previous post?

Lastly, you should be able to clip pin 20 (Chip Enable*) off of the existing chip and piggyback a socket on top of it (not sure what kind of height clearance you need). Just be sure that you add a short piece of wire from pin 20 on your socket to the pad on the board.

If I get a spare ECU, I should be able to disect it, once I figure out what some of the other IC's are. (IC10 is RAM, IC1 is what I assume to be the CPU - but not marked 68HC11), etc...

Link to post
Share on other sites

^ Yes, it's a widely known fact that the CPU is a 68hc11 variant, I have the datasheet for the only public production IC that came in an 84 pin configuration. Fact is none of the IC's are marked with non-OEM numbers, making it very difficult to find any information on them. The two IC's the VRIS controllers pass through are a complete mystery to me and everyone else that has done anything with the ECU.

I don't believe simply cutting pin 20 is a good idea to piggy back another prom in its place for various reasons, but on top of that by removing the prom I can retrieve the code stored on it.

I have no experience dealing with the ATX ECU (although I have one in my new chassis-donor MX6), so I have no idea what else it needs to operate (if anything).

I don't see any benefit to tweaking the stock motor, there's little to be gained :huh: My main motivation is I have an imported engine and need to work around a few issues.

I forgot to mention, I "upgraded" my test platform and will now be using electonically erasable PROM's (can rewrite sections of code, i.e. maps, without UV erasing the chip).

Link to post
Share on other sites
I forgot to mention, I "upgraded" my test platform and will now be using electonically erasable PROM's (can rewrite sections of code, i.e. maps, without UV erasing the chip).

good idea. saves lots of time and trouble. you may still want to use the uv erasable for the final permanent chip though just to be safe.

Lastly, you should be able to clip pin 20 (Chip Enable*) off of the existing chip and piggyback a socket on top of it (not sure what kind of height clearance you need). Just be sure that you add a short piece of wire from pin 20 on your socket to the pad on the board.

chip enable and output enable 2 pins on this eprom, with the output enable disconnected you can run the second eprom with no problem, you could even run a switch and change programs. but i would be sure that on whichever chip i was not using i would tie the chip/output enable to the disabled state (logic high or low depending on the chip and circuit). Since the eprom has tristate buffers it should be fine. I think i would use a d-latch for the output enable pins with one hooked to the Q and the other to not-Q (do a search for d latch data sheets to see what im talking about), then a switch on the data input and the clk hooked to the ignition signal. with this hookup it would cycle to whichever chip was selected only when you start the car but if you flip the switch while driving it will have no effect until the car is turned off and on again.

You know i wish i had a full schematic of this computer then i could give a diagram on how to wire this in.

Link to post
Share on other sites

^ Like I said, I don't think it's worth the trouble :lol: But if you wanted to switch programs while running, all you would need to do is simultaneously trigger the soft reset pin on the ECU :huh:

Or instead of piggybacking, you can use a larger capacity PROM and switch between banks. But again, not worth the effort IMO. If I wanted to test different code on the fly, I'd buy an EPROM emulator.

Link to post
Share on other sites
  • 1 month later...

Just as an update, two additional binaries have been added to the site:


The KL01C and the KL85 files are new additions. The KL01C I retrieved from my '93 ECU (MTX), and the KL85 someone sent me, claiming it has JDM VRIS points, etc. I have as of yet to inspect it, but the KL-85 file does appear to have been tampered with. I don't know if it's working or not, but he claims it is, so use it at your own risk as well.

This project is kind of on the back burner right now, I've got too much other crap going on to really give it the time/attention it needs. For example, these binaries I retrieved over a month ago when I was modifying an ECU....and I just now got around to uploading them to the server.

Hopefully when I complete my MX-6 I'll have more time to fiddle with this stuff.

Link to post
Share on other sites
  • 2 weeks later...

Just as an update (it's 4:30 am right now), I finally sat down and wrote some java code to read in a binary EPROM dump byte by byte, and perform a checksum (like the ECU does). It then spits out the value you have to change the first two bytes to in order for the checksum to match the expected result. I tested it and it seems to work correctly, giving the expected result for various cases. I'll do some tweaking and refining later (as well as exception handling, right now I'm just throwing the exceptions), I'm just glad I finally made some progress!

So, next step is writing a disassembler <_< Now that I have file I/O working, all I need is to create a class file for each opcode (with the methods overloaded for opcodes that take on multiple forms), and then write an algorithm to put the opcode classes to work on the bytestream in Java ;)

I can't thank Mike94PGT from mx6.com enough for his guidance a few months back, I'm finally putting some of his "clues" to work ;)

Link to post
Share on other sites

As an update, all of the development source code (Java) and documentation that I'm developing can be found here:



Source (including the EPROM binaries):


NOTE: I am allowing people to use the sourcecode for PERSONAL USE ONLY. This will be a powerful package when I'm finished (allow you to change your VRIS, fuel, and ignition maps with the click of a mouse), and as such the source may be closed at some point. Since it's very primitive at this point, and only calculates the checksum (and has search capabilities to find various maps, but the implementation isn't finalized yet), it will be public.



Link to post
Share on other sites
  • 5 weeks later...

Hey there ... where to begin. This is going to be a long post, so bear with me.

I used to hack Mitsubishi stuff for fun, but not so much anymore. Kinda got out of Mitsubishis and back into Hondas where I hack quite a bit. Maybe I can shed some advice/light on tools I use(d) on a regular basis.

Long story short: I was helping a friend work on her 1994 MX-6 (pulling/cleaning interior) and I spy'd the ECU. I was like 'thats odd, it has 1G (90-94) DSM/Galant/Everything else ECU plugs. She informed me Mitsubishi is where Mazda sourced its ECU's from on these vehicles and that this thread exsisted. I guess this shouldn't have been a big suprise, as at one time, Mitsubishi was a large OEM electronics supplier in the automotive world.

Even longer story short, I've been getting interested in owning a KL powered vehicle as a daily driver. However I must be turbocharged... so advanced hacking will be needed on that.

I always like using OEM electronics when possible. I'm not a big fan of standalones and piggybacks.


Some interesting differences between Mitsubishis and this Mazda implementation I've seen thus far.

1.) Mitsubishi vehicles utilized a Karman Vortex style MAF/MAS, while (unless I'm totally incorrect) you guys utilize a hot-wire style. This is also true for most Hyundais (who also used Mitsubishi electronics and more).

2.) Unless I read wrong, your ECU's have a checksum. None of the Mitsubishis I've worked on utilized any checksumming.

3.) Distributors. The bulk of Mitsubishis (except for the crapbox 1.8L's etc) are inductive DIS ignition. Unless I'm mistaken (I keep using that ugh!) you guys didn't go DIS until 98 or 99? I've never seen one of the OBDII computers yet.

4.) Not too suprising, but Mitsubishis also use 68HCxx MCU's. However, they are proprietary and have some opcodes not normally found. IE: extra 16bit registers and a slew of other things.

I took a look at your dumps and quickly found the timing/fuel maps. On the fuel maps on a DSM, it is based on a calculated AFR. The "load" is based upon g/Rev and of course RPM. Here is an example of a typical turbo DSM fuel map:


The value = the AFR the ecu shoots for, but obviously since it has only a narrowband O2 Sensor ... its accuracy is limited (hence such the rich AFR's up top).


I could drone on all day, but let me get to some quick info/points which might make life easier for you.

1.) The disassembler we mostly used (and then plugged the holes/missing upcodes by hand) was TunerCat's. http://www.tunercat.com It has a free evaluation and you can make a pretty clean first pass at it.

2.) Lot of people tried writing ROM editors. Including me. We ended up kinda getting behind one called TunerPro. It can be found at: http://tunerpro.markmansur.com/ . I believe it can do checksumming etc too, but don't quote me on that. Honestly, I would consider finding the checksum routine and sniping it like we do on Honda's.... makes life a lot easier.

Basically you create a .ecu file (or .XDF now? I forget) and it has all sorts of built in formulas, graphing capabilities.. blablabla. Even has an ALDL interface which could be useful for you as well. I noticed the diag connector in the engine bay. I would bet it uses 1920bps ALDL like every other OBDI Mitsubishi ECU (request/reply).

Here is a basic DSM .ECU/.XDF file for you to play with if you want:

XDF: http://www.ecimulti.org/scratch/DSM_E931.xdf

BIN: http://www.ecimulti.org/scratch/E931-32k.bin

The bin is just a generic 1991 turbo DSM bin so you can see things.


Some item's I'd like to find/help find:

1.) Global fuel compensation. On every Mitsu ECU I've hacked on, they have a global injector compensation value. This would be useful for force inducted people needing to goto bigger injectors.

2.) MAF compensation values. This all depends on how much your stock air meters are effective to in g/Rev. Might have to consider switching to say a normal Ford or GM Hotwire (all depends on how the original MAF works) to accuratly meter air. Obviously to accomplish that the compensation tables need to be changed.

3.) Fun stuff like launch control, full throttle shift etc become possible when you know the RPM points (its way easy to code) and VSS memory location.


As I said, I could drone all day long ... but looks like another fun winter project to dive into a bit :smile:

You might wanna check out the DSM-ECU list. Lots of people working on various Mitusbishi ECU's (not just DSM's) on there. You might find some of their DASM's etc of use too.


Link to post
Share on other sites


Most of mine I got from simply removing the EPROM from the circuit boards of the various ECU's I've had in my posession at one point or another. Two or three of the binaries were sent to me from other sources <_<


If you found the fuel/timing maps, care to share the details? I have been busy working on the software (which thus far is coming along well) and haven't really spent enough time on the binaries. I've looked over several GM and Mitsu ECU tuning sites, and while some hardware similarities exist, I'm doubtful very much of the programming is the same or even close, due to the fact that our EPROM wasn't programmed by Mitsubishi (only the hardware was assembled by them), and that the engine runs on a very different set of parameters.

There is no hot-wire sensor on the OBD-I models. It uses a VAF.

We used distributors until '98, but a DIS coil-over-plug ignition is on the horizon :P

There is indeed a checksum, which if not correct, will produce unexpected results (including a check engine light with no code).

I'm not planning on using any one else's disassembler, and most of them don't work on Unix/Linux systems anyway.

Link to post
Share on other sites

Well I'm a unix admin for a living (I'm talking to you from my Ultra80) ... but when it comes to hacking Windows tools are generally more fruitful. I also try not to reinvent the wheel when it's possible.

Also you might be suprised, I see some thought simularities between Mitsubishi and Mazda in this rom. however, as you know theres only so many ways to make a MCU do what you want... so thats not always too shocking to find.


I'm compiling the fuel/timing maps into an excel spreadsheet. Which I'll share up soon.. no guarantees on them working with any free/staroffice stuff ... if thats all you have. Right now they're just raw values ... without formulas they're just good for looking at curves etc.

Main timing appears (using KL31.bin) to be 03C3h - 0478h

It looks like it works just like any other mitsu hardware ECU. Hex Value - some integer = final timing.

I two tables which appear to be fuel related. One resides at 0658h - 0729h and the other at 072Ch - 07FDh.

Beware, I could be mixed up... it might be the other way around (esp when you read my knock sensor question below). I don't think so though.. at least not yet. Then again I've looked at this ROM for about an hour thus far.

I assume you've found the revlimiter and VRIS RPM points, I looked and saw a few likely candidates after comparing a couple ROM's.


Explain this "VAF".

Every car manufactorer has its on schtick on air metering names and its hard for me to keep up.

Is it a karman vortex style just like a DSM then? If so that might mean I can find the compensation values and use a larger 2G DSM or Evo8 style "VAF/MAF/MAS" whatever you wanna call it. I guess I could just go look at the MX-6 tonight :rolleyes: and quit bugging you.

Also one other basic question (bear with me, I'm new to KL's) do you guys have knock sensors? If so I'd guess the second fuel map may be an 'octane' map like DSM's have. When the knock sensor gets angry, the cars revert to secondary maps. however DSM's revert to a secondary timing map.. not fuel. Those are turbocharged vehicles though and would be much more touchy under a knock circumstance... so that makes some sense.



We really need to work on a datalogger to verify findings, IMO. I think I'll investigate that further ASAP.

I've written various palm based logging apps for Mitsubishi, Honda and GM.

Link to post
Share on other sites

Oh ya, and heres a nice little tool I use for quickly locating map's in any ROM.


Its freeware, a buddy of mine wrote it. Open a rom, set precision to 1 and click small... scroll down and you'll see maps very clearly ;)

Also let me clarify that I'm not trying to steal anyones thunder etc. I'm well known in the freeware mitsu/honda worlds and have zero commercial interests in ROM editing. I'm allllll about free.

Link to post
Share on other sites

I'd think it would be better to locate maps via disassembler, no? i.e. 16x16 blocks of memory that aren't all 0x3F and not referenced directly by the code? Better yet, why not trace the fuel injector circuit to the ECU pin(s), and then trace all writes to the corresponding address to see how the code determines the state of each injector?

I also wanted to mention, I already wrote a pretty robust checksum utility, which also fixes the checksum after modifications. :biggrin:

Link to post
Share on other sites
I'd think it would be better to locate maps via disassembler, no?  i.e. 16x16 blocks of memory that aren't all 0x3F and not referenced directly by the code?  Better yet, why not trace the fuel injector circuit to the ECU pin(s), and then trace all writes to the corresponding address to see how the code determines the state of each injector?

I also wanted to mention, I already wrote a pretty robust checksum utility, which also fixes the checksum after modifications.  :biggrin:

Your heart is in the right place, but the reality of most situations in a full reverse engineering scenario (which is what we're in) it's taken 3-4 hard years to get to where we are in the Honda world and that is with literally a forum of about 2000 people (with maybe 30-50 regular contributors). That being said I would estimate the full working knowledge of OBDI Honda ECU's to be about ... 50-60% (thats prolly being optimisic). This is you and maybe me (right now) looking at it. I've looked around on Probetalk and any 'real' knowledge is pretty limited it seems.. and the couple people who do know are mum.

ECU stuff always becomes some huge idealogical and politcal battle and its lame. That's why I work on stuff myself usually.

It's like anything in life, taking steps and looking for paterns/maps is a valuable tool in understanding the disassembly.

Theres a lot that goes into calculating injector pulse width.....

g/Rev, battery voltage (due to dwell), dwell of the pintle (usually a dead time variable), global compensation, long & short term fuel trims and I could go on and on.

You have to choose your battles.

Is your checksumming utility on your site? I didn't look very close. It will make doing some timing table tests easy with my Ostrich.

Link to post
Share on other sites

Okay, I neglected my job most of the day :biggrin:

Heres my first spreadsheet, honestly those graphs look pretty realistic (for what I'd expect). Obviously the timing (in degrees) is incorrect, I just left that there for now. Need to get some datalogging action going...

The large flat area is weird... wonder if there is an idle timing map like some GM cars have.

Disassembly and time will prove/disprove that.

FYI If you're a MS Excel user, you will need the Tookpack and VBA Toolpack addins (install them under tools-> addins).


For those who don't wish to install excel .. here is a big fat JPEG.


Next I wanna do some comparison overlays agains the USDM/non-ZE stuff.. to note the differences in their fuel/timing.

Link to post
Share on other sites

Sorry to post whore, but here is a JPEG of the "KL55" which is listed as 94 Probe on your site. It's the same map wise at the KL01. No wonder the ZE's feel like crapola with the USDM ECU's (besides the VRIS strategy differences).


I wish I had a car sitting around I could monkey around with a bit :smile: I can test datalogging on the MX-6 of my friends, but I don't wanna play with someone elses timing or fuel.

Link to post
Share on other sites

I appreciate your input thus far, it's always good to approach things from multiple angles.

I never really liked the idea of just "hunting around" to find maps, mainly because it may bite you in the ass later. What I mean is, you don't really know exactly what they do, even if you find some sort of empirical relation, unless you understand the code that references it. But you make a good point, it's a good place to start, AND it can potentially be used to implement maps from other KL-series motors (i.e. putting ZE timing maps on an stock KL-03 ECU).

Unfortunately I don't have a running MX-6 at the moment (in the midst of a complete tear-down and rebuild), and it will be a while before it is running again.

I'm not sure that data logging would be of much more benefit than simply poking around with an o-scope, or better yet, using an EPROM emulator and changing parameters "on the fly."

The checksum utility is part of the program I've written thus far (which implements many many more methods than just the checksum, but they are not put to use yet...for example, I already have a search algorithm in place to seek out specific bits of code, such as VRIS maps, regardless of which memory address they reside in, since they are in different locations depending on the software revision). I don't have a GUI for it yet, as I'm still working on the core of the program (although it does compile and work). Additionally, I may do some restructuring to take better advantage of the OO functionality in Java.

If you are bored, you can compile the source code and run the main file (it's the only one that implements the main method), and type "help" when you get to the command prompt for a list of available commands. Currently the GUI is disabled by default (since it is not yet implemented!).

The javadocs should also be useful if you feel like playing around with the code.

Link to post
Share on other sites

I know this is a lil off topic/tangent, but I got bored and looked at a 98+ 626's ECU. To my suprise a Ford EEC-V was sitting there -_-

Looks like Ford wanted to unify its assembly line or something.

Could be interesting, lots of EEC-IV and V adapters out there, which make sucking the calibration -> replacing the calibration a snap.


Link to post
Share on other sites

I'm not particularly interested in the '98+ ECU (or the '96+ for that matter), but that may be worth looking into if you've got one yourself. I'm personally trying to stay focused on my personal project for the time being ;)

Ya know, I had this crazy idea. Why not set up a test bench where engine operation could be simulated?

i.e. hook up the ECU to a complete engine wiring harness (I have these sitting in a box, several of them actually), and use function generators to simulate the N1/N2 signals (cam/crank), use pots to simulate various temperatures (the temp sensors can be mapped out with a thermometer, a stove, and an ohmmeter), and either map the VAF, or physically just move the cone in and out to simulate higher and lower airflows. Same goes for the TPS and 02 sensors, etc.

This seems like a rediculously good idea, no?

I'm thinking the soundcard on a computer can easily be set up as a multi-channel function generator (use several old pc's to generate any type of signal necessary), since it's basically a relatively high frequency D/A converter with built-in amplifier.

I've already got a 2-channel o-scope, EPROM reader/writer (homebuilt variety :P ), and the ECU's and wiring harness to support such a fiasco :biggrin:

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...