[ironmanisanemic]

So i believe i have found all of the references given so far. mpaton, can you please check my work? i have attached my Dir file.

Thanks

That's a great effort. I think you've got almost all of them.

But have a look at addresses

58A0
58B0
62F7
6628
6905

and see what you think.

You haven't been careless here, it's something that can happen that we have to watch out for.

See if you can work out what it is and let us know.

Now I need to work out the next things I want to see in a dir file

jsa, you're off the hook for the word size 1D lookups, ironman's got them all.

So next, it should be understanding interpolation math and code, and then we can look at a 2D table example, with some Ford ROM and RAM addressing conventions,

Michael

I tried to be through, i guess i still missed a few.

I went through the ones you listed and added them to my DIR file. NOW it should complete up to this point. I forgot to re run the searches after i got the first round of them. i did that on most of them but i must have still missed a few. i forgot that as i cleaned up the data that some new values under address values i was searching for would appear. so completing a string of values and going back and rechecking my work more thoroughly would have been beneficial.

I attached my newest iteration of the dir file.

[jsa]

so people didn't have to go and read the 1989 or 1991 documentation.

Michael,

What are they, where are they, can you link them please or give ISBN or full names please ?

[ollopa]

Well sorry to necropost but I'm getting into EEC hacking and I find this thread very helpful and interesting. Did ironmanisanemic just give up after all that work? Granted this exercise was a really big ask for someone with no embedded systems experience, but some good progress was being made!

Hmm..... or another teaser perhaps..... what does THIS code actually do ?

Code: Select all

 cc,38             pop   R38            R38 = pop(); 
 b2,3b,3c          ldb   R3c,[R38++]    R3c = [R38++];
 b2,3b,3d          ldb   R3d,[R38++]    R3d = [R38++];
 c8,38             push  R38            push(R38);

Thank you for posting this. It's clear to me that this snippet of code is loading a word of what you all call an "inline parameter" into r3c:r3d and fixing up the return address on the call stack to skip over the inline data.

After the call the stack contains the return address which actually points to the first byte of inline data. That address is popped into r38 which is then used to indirectly load the next two bytes of program memory into the registers. R38 now points to the next instruction after the inline data and this address is pushed back onto the call stack so the ret at the end of the function will set the program counter to the correct value.

I see that the code and data directives in the dir file are being used like the "view as code" / "view as data (db/dw/etc)" in IDA. Once one has located a function with inline parameters and determined the number of parameters, you have to iterate over each occurrence in the BL listing, add directives, and disassemble again to find the next. This is quite tedious so I'm assuming mpaton added his own directives and enhanced the BL disassembler to automate this process once such functions have been located.

This is really great stuff! Any way to get this discussion rolling again?

[decipha]

correct

last I knew ida didn't handle 806x too well

but getting back to it, in most advanced disassemblers you can specify that a specific routine is grabbing inline parameters thus anytime that address is called, the following xxx bytes are omitted as code