By the way, Loudroom, find yourself a copy of IDA pro (interactive dissasembler) ver 4.5. It works really well for the 8086 DASM. had the code fully torn down inside 20 mins. It also tries to guess what each instuction does, and where its calls are mad to and from.

 

I think an AFM to MAF conversion would be a great first step.

Okay. Perhaps we can "synchronize our watches" so to speak.

The first thing is:
What ROM # are you using as the basis for your work?
(I'm sorry if you've answered this before, but I don't recall it if you have.)

Second, it would be nice if we both had the same MAF. What unit would you suggest? I'd prefer not to spend too much money, and it would be nice to use a new, easily avaible part so others could easily duplicate our work.


I've got a 3" AFM adaptor sitting around, so perhaps I could just stick a 3" MAF and K&N filter off the AFM. I have access to a nice dual-channel 100MHz handheld oscilloscope which could be connected to both sensors to log the data. That should give us a conversion table pretty quickly.
I agree about hooking the MAF sensor up directly to the ECU. I'd rather do this than build a seperate box, even if it means modifying the ECU a bit.

Bummer about your hard disk. I'll dig around for IDA pro.

 

holy moley, its now 4:11 a.m. and i feel like im working in reverse. my brain is melting. first of all i'm second guessing myself. The processor is a Hitachi hd6303. Now, what language were the instructions written in? Was it 8086? If not, why was I thinking that it was? Im working on the 286 ROM. If it is 8086, I've gotten it DASM'ed and i'm working on recompiling it in order to emulate it, but my laptop is sooooooo slow, and there's something like 2700 lines of dasm'ed code, that it just locks up when i try to recompile and emulate. Maybe im just crazy, im certainly exhausted. I've been working on this pretty much straight through since yesterday evening. also it's gonna be hard to find IDA pro again, because so many people were downloading it and using fake serial numbers to unlock it, that they've made you start sending them email saying you work for a tech company before they will even send you the demo.

I digress. first and foremost, i think it important just to have the roms disassembled (code wise) and commented out. That would give us a crystal picture of what everything is doing when something is doing something else. Plus it will help us find the bit of code which contains the parameters for the afm. Man I'm so exhausted, im sure im going to read this tomorrow and wonder what the hell i was even talking about.

anyway thanks for keeping this thread alive. Ill keep trying guys, just please be patient. And if you guys see me getting discouraged, give me a nice kick in the ***!!!

goodnight

 

ok not goodnight, here's the DASM'ed 0286.rom file. it's not commented, but here it is anyway.



nevermind, I cant attach a file that's not a picture. Ill email it to you

 

Im retarded, heres the file

 

I don't think the processor uses an 8086 instruction set, but I'll check the 6303 datasheet.

Perhaps I'll even hook up a logic analyzer to the ECU and see what it does at boot. This would tell us once and for all what the processor is.

 

I think this is the disassemblyer we should be using.

http://www.softlookup.com/preview/dis6877.html

This is what the guy on the 16paws site used, and it appears pretty good. And it's free. That means anybody who wants to can download it and help out.

 

I think it makes sense to splice the two rom images together before disassembling them. Of course, we'll want this to be reversable.

Anyone know of a simple command line utility to merge and split binary files?

(I'm sure there's probably a one-line comannd that will handle it in Linux.)

Once that's done, it will be a matter of creating a couple .sym files so that the assembler can tell the difference between data and instructions.

 

Here are the symbol files.

These align the data at the correct addresses and give the disassembler all the possible program entry point (reset, interrupts, etc).

I've just started them, but this should be enough to get you going. You'll need a binary file named bothroms.bin in the same directory with consists of the IC605 rom image appended to the IC605 rom image.

 

That should be the 604 appended to the 605.

 

No, wait I got it backwards. 605 follows 604. Sheesh.

Anyways, it looks like the software flow could be.

Read ROMs => join ROMs => write symbol file => use dissambler program => clean up by hand and comment

Once we get to that point, what are we going to use to assemble our modified code? (An assembler obviously, but which one should we use?)

 

how much are these e-prom readers? I'd like to see what the code looks like on the chip I bought (hopefully its not a blank chip), and help you guys out. I'm attending college for a BS in Computer Science and am fimilar with java and c++ programing.

Could you guy go into more detial about what type of code is used and what the 8086 DSAM is and the 6063 or whatever is....

 

The EEPROM Reader/programmer I'm using was $100, shipped. (batronix.com) $30 of that was just the shipping from Germany. It came as a kit that takes about 1.5 hours to assemble, another 1/2 hour to test.

The code we're looking at is the actual assembly code used by the microprocessor. The 8086 disassembler jinx was using converted the binary instruction code into a more human-readable format. The only problem is that (if the 16paws site is correct) the instruction set used by the CPU is common with a Motorola 6800, not an Intel 8086. This is why I posted the link to a different program.

Have you taken any courses on microprocessors?

 

Loudroom, you are the man!!!! I was sooo exhausted last night, I just couldnt get my mind to function properly. The biggest problem I had, is for some reason I was convinced that It was 8086 assembly. Where I got that notion is beyond me. No wonder I couldnt recompile and emulate.

 

Loudroom, could you be a dear, and post a .zip file of what you've dasm'ed? I've used DASMx before, but for some reason on my shitty toshiba laptop nothing is working from the command line. If you post, let me know what Rom image you were working on. I'm still not sure if we ever got synched up about that

 

BTW if I'm back on track now, Isn't the HD6303 a 6801 variant with the instruction set being similar to the 6805?

 

something to ponder

 

I messed up those symbol files, the the disassembly isn't worth anything at this point. Maybe I can fix them today.

I'm working on the 287/277 ROM set. If the 285/275 ROMs have been spotted in an ECU with the same part number as the 287/277 set, then I'm going to assume that the 287/277 ROM is the "best" version and that both the 285/275 and 286/276 are previous versions.
If this assumptions is correct there is no reason to mess with the 285/275 or 286/276 versions.
Maybe once I get a good disassembly, we can verify this.

 

Agreed sir

 

Here's a more recent set of symbol files.

I would like to have the symbol files completely accurate WRT what is code and what is data.

I am putting non ROM specfic stuff in the mazda.sym file and the ROm specfic stuff in the other file. This will pay off when dealing with other ROMs.

 

I've also started checking up on MAf sensors:

http://web.camaross.com/forums/showt...hreadid=210777

 

Got my other computer back up. and Im using IDA pro again. I've DASM'ed the 287 rom as a 6303, but of course it has trouble finding an entry point. I can hand DASM it, but I'm not sure if it's accurate. I've also done it as a 6801, and 6805. I'll post if I get a clean DASM.

 

jinx,

I'm no EE, but I thought all microprocs had a series of default addresses they used to look for boot code. My data on the HD6303 says the reset causes the cpu to load the contents of $FFFE and $FFFF. that Help??

sunrotor

 

Thanks for the input Sunrotor. It helps

 

Those symbol files I'm posting give all those entry points to the debugger, which then performs a partial emulation of the processor when it hits branch instructions.

I haven't had a chance to really look over the resulting code though. There are certain jumps it can't handle automatically, and I think I have to figure these out and add them to the .sym files.