mark944turbo

One more thing, the circuit I posted with the cmos amp etc was intended to listen to this filtered signal, not the raw signal. That would be so nice to have a little LED on the dash with a push button reset.

Zero10

The processor in the DME is an 8051?
Fascinating. There are revised versions of those all over, for about $0.50 each.
Pretty much any chip that supercedes the original 8051 will work in it's place.

hally

posted by pk951 once upon a time in the thread "what do you need to burn your own chips" Might have a bit more detail on suppliers and procedure not already covered. This is where i started from thanks pk951 and nice work on the website Mark

Lorenfb

"As far as location or actual values ?"

The locations are O.K. but the actual values have a constant (in most cases) offset. Not good!

mark944turbo

Thanks Loren, any idea on how to correct this? It is a little hard to look with a timing light under any conditions but idle.

Zero10

Hmm, $200 for an EEPROM writer isn't bad, most around here are $500-$600, but that's still kind of steep.
I'm getting a PIC programmer for about $40, building some microcontroller circuits, and it seems to me, this programmer should be about 10x more complicated than an EEPROM programmer.

Bri Bro

Here is the 28 pin code disassembled. The zip file contains the DIS8051 disassembler. In the Instruction document for DIS8051, it states that "Data Sync Engineering" has submitted the program to the public domain.

The 8051 instruction set is listed in section 3.

The programmer I use is built by Needham's electronics. Very depenable and flexable.

Lorenfb

"Thanks Loren, any idea on how to correct this? It is a little hard to look with a timing light under any conditions but idle." - mark944turbo -

Have to find a good updated version of "Motronic 911". The web site has just a demo
version which hasn't been updated since 2004. Some have a full version that's more
useable (no bugs maybe), but who??? Email to the web site results in an email return.

rage2

Disassembly and isolating data areas is the easy part. Commenting and understanding each section/subroutines is the tough and time consuming one! I'm almost done doing the stock Honda Integra VTEC ECU code... took like 2 years of spare time!

If anyone has found disassembled AND half decent (even partial) commented code floating around, it'd save a LOT of work. I could even start working on it, I used to do a lot of 8051/2 asm programming.

mark944turbo

Well, time is what I have right now.

I really have no idea about the magnitude of the process, as I have no experience with this sort of thing. I am relying on friends and rennlist contributions. Rage, anything you can help with is appretiated.

Brian, that looks awesome, I am going to sleep now but I will study it tomorrow.

Zero10

Hmm, I've done a lot of SPARC and Intel assembler programming, but this still seems somewhat foreign to me. From the looks of it, that is just the control code, not any of the maps, correct?

Bri Bro

Rage2, you are dead on, but you have to start somewhere. Unless we can get an employee who worked on this code for the Motronics and is willing to give us a copy, I doubt we ever see a commented source. At least one can look at the code to start the process of IDing the data file locations vs. the code locations. Is can be a real PITA!

rage2

The control code and all the maps are in there. Chances are the first run through the disassembler it's dissected maps as code (depending on how smart the disassembler is). Takes time to start labelling stuff and feeding that to the disassembler to get a clean run through, after which comes understanding and commenting by stepping through everything, guessing how each register and RAM memory location relate to inputs and outputs, then labelling the chunks of code with meaningful labels. Then we can start to see what each data section really does, and what kind of maps they are.

Since there's SOME info on rev limit locations, fuel map, and spark map, it should give us enough information to make really educated guesses as to what and how the memory locations and registers relate to I/O. That's the start if we want to truly understand the code, and allow us to write new code to do stuff. Example... I'm working on a predictive launch/traction control code based on wheelspeed alone on the Honda ECU for drag racing. Basically I can input maximum rate of acceleration in each gear, and use that to adjust boost/fuel cut accordingly to get consistent launches. From there you can get really complex... traction control based on multiple speed sensors (assuming the ECU has enough inputs), or device that can send individual wheel speed inputs through 1 i/o port... lots of cool stuff can be done. How about a motronic powered MAP conversion? The possibilities are endless.

I must stress that if this is to happen, that everyone that contributes makes it public, and not get pissed off if it gets borrowed/stolen for commercial purposes. I've seen way too many times where some people take the info from the public domain, and use help them start their disassembly, they go and make a commercial product once they're done, then everyone gets pissed and stops contributing and we're half done. It's happened SO many times. This is not a 1 man project. It's a collaboration with many people. I'm willing to start tackling it in my spare time.

If all we care about is to adjust fuel/spark/revlimit, there's no point in going that detailed... there's more than enough info already to make a decent editor.

Lorenfb

"I must stress that if this is to happen, that everyone that contributes makes it public, and not get pissed off if it gets borrowed/stolen for commercial purposes."
I've seen way too many times where some people take the info from the public domain, and use help them start their disassembly, they go and make a commercial product once they're done" - rage2 -

Remember, you're BEGINNING to enter the area of copyright infringement of the Porsche/Bosch code, i.e. it's NOT in the public domain!

mark944turbo

My website will always be public domain.

"If all we care about is to adjust fuel/spark/revlimit, there's no point in going that detailed... there's more than enough info already to make a decent editor."

I for one am not satisfied with what we have. Sure we have enrichment tables, but we dont know the relationship between the values in them and how much fuel is being injected. I want the base pulsewidth map. And the spark information we have now is no good, and I dont see any way of having confidence about changing those values until we know the full extent of the code including temperature and knock related algorithms.

On top of this I would also like to find the transfer function for the AFM and be able to change that for different maf's, and have bigger load vs rpm tables that are not influenced by a full throttle condition. The way everything is set up now makes tuneing annoying.

If we find that there are spare inputs/outputs on the processor I am sure we could come up with cool uses for them.

I emailed Bosch about getting any leads on the code, and they emailed back a phone number, which I will call soon. Hopefully that leads to something, they have been helpful in the past.