the strategy is not important at this point. i am working on a project to come up with the tools to take a binary and dis-assemble it and then re-assemble it to re-create the original binary.

any help would be most appreciated.

thanks

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

instead of reverse engineering Henry's, why not just create your own engine control software and just use the ford ecu as the I/O device?

First, I need to learn the 8061 machine language and know what ports to peek and poke in order to communicate with the external devices. That is where a good dis-assembly would come in handy. Given the lack of solid information I have come across thus far, that is currently the hardest part of this whole process.

Once I know that stuff, it will be easy enough to implement a FORTH machine for that hardware. Then an engine management system might be in reach.

And by Henry .... I assume you are referring to Henry Ford?

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

To understand how the HSI and HSO coprocessors work, read over the 8096 documentation. It uses an almost identical high speed coprocessor setup. The Tom Cloud document touches on this, but it doesn't really go into a great detail about how to use those coprocessors. The 8096 documentation does. The Low Speed I/O are not nearly as complicated. I think they are memory mapped to specific registers (e.g. the ACT and ECT input registers).

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

I downloaded a CBAZA definitions file. I will write a little program to parse it and generate a disassembler directives file.

That should also work for the A9L and any other similarly formatted def.

Hopefully someone will notice this thread before long and point me to a disassembly that people have filled in.

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

Keep in mind when you write this that you'll need to maintain the value of all registers and everything on the stack, which means you'll also have to execute most all the other commands like the EEC would (math, jumps, conditional jumps, etc).

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

if one is completely re-programming the chip, then the stack and registers are all fair game and he or she can do whatever they want.

if one is trying to tweak a small section of the code that is there, then naturally he or she needs to be extremely careful about leaving the environment in a state that is compatible with the rest of the system.

that is the beauty and the beast of programming at the machine level ... total control over everything, but the price is that you better freaking know what you are doing because one small misstep and all hell can break loose.

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

If you are completely rewriting the code from the ground up, then yeah do whatever you want. But I thought the purpose of the program was to parse through a BIN file and get a clean disassembly.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

yes, getting a clean and accurate dis-assembly is the goal, at least for now

maintaing the values of the registers and stack pointer and things like that (as you mentioned in your previous post) are issues that need to be thought through when developing the program that will actually run on the EEC-IV processor.

but they don't come into play when trying to turn the machine code for the processor into a human readable form (aka assembler code). so long as the assembler code that came out of the disassembler is an accurate representation of the machine code, and can be turned back into the exact same machine code.

maybe i'm not following what you mean ... ?

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

Now you are thinking like I was before I actually read the code...ummm strike that, before mpaton took the time to explain the code to me and I realized why the disassemblers barfed. Once I understood why the disassemblers were breaking and what it'd take to make them not break, it became clear that YES to effectively dissassemble FORD's code, the disassembler does need to keep up with register values as well as stack data since the execution order of the code is directly manipulated by the code screwing with the stack.

For example, when the hardware throws a program counter onto the stack before a CALL is called, most disassemblers (and human programmers) assume that the return value will be the byte immediately after the CALL and the call's jump-to address operand. That's not a safe assumption in Ford code. The code that is being called could POP off the stack the return-address value that the hardware put on the stack. Manipulate it in a register. Then return that manipulated value back to the stack. Then when the code hits a RETURN, the hardware POPs off the stack a value that code tampered with. If the disassembler doesn't actually execute the code the way the EEC would, it will wrongfully assume the next byte after the CALL is an instruction when it may be more data. So traditional disassembly doesn't work hence our need for an emulator, not a disassembler, to give us a clean disassembly of the code without directives.

With what we have today, a human has to:

1. Do an initial disassembly attempt.
2. Read the resulting code.
3. Recognize where the disassembler went off in the weeds
4. Understand why and what it must do to NOT screw up
5. Create/Update a directive file to tell the disassembler what to do instead to stay on track
6. Rerun the disassembler with that update to the directive file
7. Repeat to Step 2 until the assembly comes out clean.

THAT is one of the tedious and most time consuming parts of disassembly that I think software can do FAR better than a human...or at least faster if there was someone so inclined to write an emulator that will just execute the code the way the EEC does. After all, the EEC doesn't need a directive file, so if you have an emulator walking the code the way the EEC does, the emulator shouldn't either. But such an emulator program would have to actually execute the code as the EEC would and keep up with register values and RAM (in specific, the stack) to see what it is that the code is doing to the execution order and not get tripped up.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

i see where you are going now ... i think ...

start with an emulator that can simulate running the program. such a simulator would have built in instrumentation to be able to detect the locations that were actually executed. given that info, those memory locations that were not executed must either be data or unused. then an accurate directives file could be generated so that the disassembly can actually know where the code is and where the non-code is.

then again, since the simulator has to be able execute the code, it will need to be able to parse the machine code, which is what a disassembler does also, so the simulator could also produce the assembly source file. then the human could focus on naming the subroutines and the data locations. BE and TunerPro and the like have great starting points for that.

you are absolutely correct, with such an approach, the process of discovering the non-code areas (especially those places where the called routine modified with the return address) would likely be much more complete and accurate.

that is a very interesting idea ... hmmmm ...

in order for a simulator to be able to be complete, it will need a stream of data that simulates the changing sensor values like TPS, MAF, PIP frequency, ECT, ACT, O2 sensors, ...

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

Mpaton, Adam M, or Sailorbob could chime in here better than I, but I don't think code execution is dictated by sensor values OTHER than via conditional code paths, but a traditional disassembler can handle that. In the case of a simulator, you simply "remember" what conditional paths you've gone down and circle back to identifying the code paths that weren't taken before. That may be easier said than done, but that's the theory in my head anyway.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

project started. this is an interesting project. i am going with the instrumented simulator approach to try to track all locations that are executed.

more updates as i have them.

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

my simulator can now run through the entire initialization routine of the A9L code!

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

wow awesome work. I wish I remembered more from my assembler class so I could assist... lol

_________________
1978 Mustang II King Cobra
89 5.0HO, Stock Short Block, Edelbrock 4bbl aluminum intake, Holley 650 double pumper, MSD 6AL, Ford F303 cam, 1.7:1 Crane Roller Rockers, Pocket Ported stock heads, Hedman Long Tube Headers
5 spd Manual
Full roll cage, 9" full floater w/Currie trac lock/373 gears, RCI Fuel Cell
Project Page: http://www.brandttuning.com/projects.htm

Post up what you believe to be an entire disassembly and see what some of the experiened bin hackers think. It may be completing, but not getting everything.

_________________
...Always Somethin'

89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, 1.6RRs, FMS Explorer (GT40p) headers, Slot Style MAF, aftermarket T5 'Z-Spec', 8.8" rear w/3.27s, Powertrax Locker, Innovate LC-1, GUFB, Moates QuarterHorse tuned using BE&EA

Member V8-Ranger.com

i don't have any support for user defined labels yet, but i do have instrumentation.

for instrumentation, i am tracking 4 pieces of information currently: executed opcodes, operands, and the addresses that are loaded and set (aside from the opcodes and their operands).

it does not yet generate an assembly listing file, but that will come before long.

when i have something, where should i post it? as an attachment to this thread?

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

GROUND BREAKING UPDATE FOLKS

after 4 years, 2 months, 6 days, 12 hours and many sleepless nights, I have successfully engineered a program in source-code on my scientific calculator, I can now calculate what the length of the hypotenuse is on a right triangle!

lol, it only took me 2 years to do that.

after a couple rounds of refactoring the code, it can now spit out a disassembly of the instructions it ran. still no support for user defined labels yet though.

i'll post a screen shot of the UI and a dump of what it currently spits out tonight.

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

here is a current disassembly ... not much there yet i know, but it has actually executed all the code here, including the jumps and autoincrements and all that

_________________
95 GT Vert, TwEECer R/T v1.30A9
1970 block, 410ci, 10.27:1 CR, 42#, LMAF, CBAZA/T4M0, AOD, 2500 Stall, Custom Cam

1967 Fairlane Vert, 390FE, C6, 100% stock

Hey guys, want to check this file out ?

It's the results of a few years of my labour, on a very simple EEC iV binary...
only 8k, but does the job.

Ford Granada 1985 Uk.

It has TWIN VAFS as standard (yes really !)

_________________
TVR Tasmin 280, TVR Tuscan 2.8 Efi (EEC IV), various kit cars, IT code geek....
Crusty old Classic car freak.