This is where the BIN Hackers and definition junkies discuss the inner workings of the EEC code and hardware. General tuning questions do not go here. Only technical/hardware-specific/code questions and discussions belong here.

Moderators: EDS50, cgrey8, 2Shaker, Jon 94GT

Post Reply
User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Thu Feb 15, 2018 7:07 pm

Thanks John,

Not sure if I know how to sort that, as it's a Win32 call to do the dialogs.....

But I'll have a web look and see if there's any info.
It's an XP dialog originally so may be because it's very old by now...(I built SADWIN on an XP virtual machine)

I've got a Win 8 VM somewhere..... I'll try it on that.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Thu Feb 15, 2018 7:33 pm

A further thought, are you intending to call the folder selection window when the path to sad.exe is broken, in the ini?

If so, could be the call is incorrect or has the wrong arguments.

I have an XP VM on my laptop. I shall fire it up later and see what happens....
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Thu Feb 15, 2018 9:49 pm

No - designed the last one as an 'OpenFile dialog' so that you can change the name of SAD.exe you wish (like for example have more than one version at the same time) and OpenFile gets the whole path, so went that way.

The official m$ docs actually say if you're using Vista or later to use an alternate dialog call, but of course the calls ain't there on an XP VM !

I was going to try out WxWidgets, which is supposed to be platform independent also, as far as Win and Linux go, but couldn't get compile to work
with Codeblocks. Very frustrating. Managed to sort that just this morning, solution was not very obvious, hidden away in Install docs.
One of those "in some cases......." gotcha statements near the end.

It's sometimes a real PITA, but good to learn the different techniques. Most of my background was in the server end with databases and custom written services, so did a lot of 'C', perl and various scripting, but no GUI stuff....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Thu Feb 15, 2018 10:43 pm

tvrfan wrote: ↑Thu Feb 15, 2018 9:49 pm No - designed the last one as an 'OpenFile dialog' so that you can change the name of SAD.exe you wish (like for example have more than one version at the same time) and OpenFile gets the whole path, so went that way.
Ok makes sense.
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Thu Feb 15, 2018 11:54 pm

John,

Tried out that setup on a Win 8.1 64 VM, and it doesn't seem to produce duplicates as your example (but the colours are truly awful !!).
Used the XP 32 bit builds. I see win 8.1 automatically shows the later style directory dialog picker (as I understand it).
Everything runs OK and it disassembles fine.

Did you say you were on Win 7 ? Hmm... haven't got one at the moment, I'll see if I can get one from the "Buccaneer Inlet"
if you know what I mean.......
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

motorhead1991
Regular
Posts: 238
Joined: Tue Nov 21, 2017 2:32 am

Re: 3.03 posted, Windows EXE posted

Post by motorhead1991 » Fri Feb 16, 2018 2:13 am

tvrfan wrote: ↑Wed Feb 14, 2018 4:08 am Linux is console only at the moment, but hey us UNIXphiles are well used to typing weird commands in a terminal window.......
Hey, I like a GUI sometimes... Taking a small break from this to run off a couple Android builds though :biggrin:
1990 Ford Ranger FLH2 conversion. Ford forged/dished pistons, Total Seal file-fit rings, Clevite rod and main bearings, Clevite cam bearings, IHI turbo, Siemens Deka 60lb/hr injectors, Ford slot MAF in custom 3" housing. Moates Quarterhorse with Binary Editor, using the PAAD6 database.

OpenEEC Telegram Chat:
Telegram

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Fri Feb 16, 2018 4:22 am

tvrfan wrote: ↑Thu Feb 15, 2018 11:54 pm John,

Tried out that setup on a Win 8.1 64 VM, and it doesn't seem to produce duplicates as your example (but the colours are truly awful !!).

Did you say you were on Win 7 ? Hmm... haven't got one at the moment, I'll see if I can get one from the "Buccaneer Inlet"
if you know what I mean.......
I look upon Win 8 as Vista 2 :surprised:

Yes, Win 7 x64 Ultimate SP1. I'll have a go with my laptop which is same OS plus VM XP.

Ay cap'n

The casts are muck'n up a bit. I ran your a9l cmt and dir through V3.03 and compared to your lst.
JC and JNC are getting pairs of (uns)

Code: Select all

2046: d3,f5               jnc   203d             if ((uns) (uns) R14 < 48a) goto 203d;
2077: db,0e               jc    2087             if ((uns) (uns) R14 < R16)  {
JE, JNE, JLT, JGT, DJNZ get nothing ?

Code: Select all

206c: df,20               je    208e             if (R14 = ffff) goto 208e;        # -1 = list processing done
2108: d7,03               jne   210d             if (0 = Kihp)  {
2237: de,22               jlt   225b             if (AD_Cmd < 0) goto 225b; 
24ad: d2,12               jgt   24c1             if (R8a <= 0)  {
270b: e0,50,05            djnz  R50,2713         R50--;
                                                 if (R50 != 0) goto 2713;  
                                               
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: 3.03 posted, Windows EXE posted

Post by tvrfan » Fri Feb 16, 2018 2:14 pm

motorhead1991 wrote: ↑Fri Feb 16, 2018 2:13 am Hey, I like a GUI sometimes... Taking a small break from this to run off a couple Android builds though :biggrin:
Now I've got the minimal WxWidgets example to compile and run, I'll learn this way instead and then there will be a GUI for both platforms.
I also finally managed to get git to talk to my remote repository on GitHub, so will try a push/pull/commit etc to testing branch to learn that too.

All good - keeps the brain working !
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Fri Feb 16, 2018 2:30 pm

jsa wrote: ↑Fri Feb 16, 2018 4:22 am
.. The casts are muck'n up a bit. I ran your a9l cmt and dir through V3.03 and compared to your lst.
JC and JNC are getting pairs of (uns)

Code: Select all

2046: d3,f5               jnc   203d             if ((uns) (uns) R14 < 48a) goto 203d;
2077: db,0e               jc    2087             if ((uns) (uns) R14 < R16)  {
Bugger - I left an extra (uns) in the code !! I have cheated and fixed that in 3.03 (src and bin) as it's only an extra print statement I should have commented out....

JE, JNE, JLT, JGT, DJNZ get nothing ?

These are all SIGNED operations, so didn't add anything. (hmm, must check DJNZ though )
I agree with adding long and uns, on the basis that a signed int (16 bit word) or signed byte is the default.
I'm open to suggestions as to how this might be improved without being too fussy.
I don't really want to make every comparison have (signed)(int) all over the place.

Idea - I did originally print every register as R14B, R14W, R14L but it looked messy/weird with absolute addresses and numbers.
Weird to me that is, but I'm embedded in this stuff.
If you guys reckon it's clearer I can put that format back in, or something like it.

Or could perhaps state in Doc that signed word/int is default ??
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Fri Feb 16, 2018 5:35 pm

tvrfan wrote: ↑Fri Feb 16, 2018 2:30 pm I have cheated and fixed that in 3.03 (src and bin) as it's only an extra print statement I should have commented out....
Haha I see the git source has been updated.

Would you like to cheat a little more...
Edit: I had already appended .1 for my build with version out to lst and msg

Code: Select all

shared.h
#define SADVERSION "3.03.2"

Core.cpp
 newl(1);
  pstr("#\n#  Disassembled by SAD V%s\n",SADVERSION);            //Add this to print SAD Version in *lst.txt
  pstr("#\n#  Disassembly listing of binary '%s' ",fldata.bare);

  wnprtn("\n\n --- Disassembled by SAD V%s",SADVERSION);        //Add this to print SAD Version in *msg.txt
  wnprtn("\n ------------- START Disassembly");
JE, JNE, JLT, JGT, DJNZ get nothing ?

These are all SIGNED operations, so didn't add anything. (hmm, must check DJNZ though )
I agree with adding long and uns, on the basis that a signed int (16 bit word) or signed byte is the default.
Having to check stuff in the reference material is a large part of my reasoning for having the casts explicit. Working on the disassembly's sporadically as time permits means that not all the finer points are ingrained in memory. After a break from disassembly, I find I spend a fair amount of unproductive time reviewing reference material to double check what I think I remember.
I had to go look up the ford reference before making a ? as to why you might leave them out.

Now I see in the ford reference, DJNZ notes, that there are differences for 8061 & 8065.....
I'm open to suggestions as to how this might be improved without being too fussy.
I don't really want to make every comparison have (signed)(int) all over the place.
I agree with keeping a balance between explicit information and untidy information making output difficult to read.

I really like the explicit hint for lookups. I think keep it down to just a single letter.
U Unsigned
S Signed

Code: Select all

2077: db,0e               jc    2087             if ((U) R14 < R16)  {
or
2077: db,0e               jc    2087             if (U R14 < R16)  {

206c: df,20               je    208e             if ((S) R14 = ffff) goto 208e; 
or
206c: df,20               je    208e             if (S R14 = ffff) goto 208e; 
The brackets add nothing for me, but to my detriment I'm not a formally trained programmer.
In your experience, what value is there in the ()?
Idea - I did originally print every register as R14B, R14W, R14L but it looked messy/weird with absolute addresses and numbers.
Weird to me that is, but I'm embedded in this stuff.
If you guys reckon it's clearer I can put that format back in, or something like it.
Was there a R14H as well at some point?

The B & W seem to be well covered by the opcode names which typically have a b or w suffix. So I don't think blanket B&W are going to add anything. Have you a listing you could share with blanket B,W & L?

If the B, W and L are tied to the Rxx, then B, W & L could be lost after Rxx is replaced by SYM with SomeName.
I agree some combinations of SomeNameL would just add confusion.

The detail that can be easily missed, is the change from B to W or W to L. I find it is the implicit changes that I want to be reminded of.

I say make it consistent so that they are shown as prefixes, but not directly appended to the Rxx.

Code: Select all

change
2971: 6c,be,50            ml2w  R50,Rbe          (long) R50 *= PIPH_PW;
to
2971: 6c,be,50            ml2w  R50,Rbe          L R50 *= PIPH_PW;
or                                               (L) R50
Or could perhaps state in Doc that signed word/int is default ??
My gut feel is that, by quantity most of the code is working on unsigned values. So signed by default seems counterintuitive to me.
Having to reference external material while following through code is a real train of thought breaker. Minimising that helps productivity, so I'm all for explicit hints.

How many of us are formally trained and know the implicit details straight up each time we return to disassembly?
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Fri Feb 16, 2018 6:18 pm

John,

some good points there....

Yes for version number, should add that to list and warn files. Good idea.

the (long) with brackets comes straight from 'C' code, where you can recast a value as something else...

If we go for a shorthand like (U) then perhaps I should print a key at the top ?
R14H meaning high ?, unfortunately it's R15. if it's a long, then it's R17 ...

Abandoned the R14B etc a long time ago, I decided (like you) the opcode was good enough most of the time, and so just the implicit/specific changes
to highlight.

Signed/unsigned - tricky territory (believe it or not).
Many Arithmetic ops are totally blind to sign because of a very clever trick - have you ever wondered why (16 bit) -1 is 0xffff and -32768 is 0x8000?
so that add is quite literally a+b in all 16 bits, in all cases. Neat. So really signed is only for compares and jumps (and a few odd opcodes where sign bit
screws stuff up, like shifts, mults). Yeah, OK, not quite always, but holding this idea in your head helps.
In C code for example you quite often have a mixed of signed and unsigned ints...

Also non-programmers will possibly miss tricks like this, which us IT geeks see straight away...
But I don't know how to show this reliably in SAD !!

Code: Select all


LDW, R14, R26;                   R14 = R26;
LDW  R30, R15;                   R30 = R26/256;

MULT R34, R32                   (L) R34 = R34 * R32;
LDX R30, R36                     R30 = (R34 * R32) / 65536




Anyway, I'll think seriously about your suggestions....
Last edited by tvrfan on Sat Feb 17, 2018 5:44 pm, edited 1 time in total.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

motorhead1991
Regular
Posts: 238
Joined: Tue Nov 21, 2017 2:32 am

Re: 3.03 posted, Windows EXE posted

Post by motorhead1991 » Fri Feb 16, 2018 6:33 pm

tvrfan wrote: ↑Fri Feb 16, 2018 2:14 pm
motorhead1991 wrote: ↑Fri Feb 16, 2018 2:13 am Hey, I like a GUI sometimes... Taking a small break from this to run off a couple Android builds though :biggrin:
Now I've got the minimal WxWidgets example to compile and run, I'll learn this way instead and then there will be a GUI for both platforms.
I also finally managed to get git to talk to my remote repository on GitHub, so will try a push/pull/commit etc to testing branch to learn that too.

All good - keeps the brain working !
That UI I showed you in PM is written with QT, which is cross-platform compatible. That means, if we can figure out how to integrate it, everyone's UI will look the same. I don't know enough C to do it just yet though.

For everyone else, who hasn't seen it, here;
https://youtu.be/OH_S6pRbX64
1990 Ford Ranger FLH2 conversion. Ford forged/dished pistons, Total Seal file-fit rings, Clevite rod and main bearings, Clevite cam bearings, IHI turbo, Siemens Deka 60lb/hr injectors, Ford slot MAF in custom 3" housing. Moates Quarterhorse with Binary Editor, using the PAAD6 database.

OpenEEC Telegram Chat:
Telegram

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Sat Feb 17, 2018 5:30 am

I just want to insert my 7 cents. last year I disassembled GM binary fom gm C3 ecu. It was as usual - see, what parts of code are the same with known parts in already disassembled binary, and write what it is. I used ida pro, since gm used supported motorola mcu (and much less tricks).
what can I say? I had nearly the same progress in 1 month with gm binary, as in 1 year with eec-iv binary.
apart from ida pro, there are opensource and free disassemblers, say 'radare2' (currently not supporting i8061). it's much better to use existing debugging interface than commandline tool, windows gui wrapper or anything else.

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Sat Feb 17, 2018 6:34 am

tvrfan wrote: ↑Thu Feb 15, 2018 11:54 pm Did you say you were on Win 7 ? Hmm... haven't got one at the moment, I'll see if I can get one from the "Buccaneer Inlet"
if you know what I mean.......
Well, I tried it on my Win7 x64 Ult laptop now, and what do you know, no additional instance of windows explorer.

Both machines have the same Windows updates and the settings are cloned with migration wizard. Workstation is a Gen 1 i7 and the laptop Gen 6 i7. Workstation has a lot more applications installed.

In summary something specific to my workstation, that is not worth chasing.
At a wild guess, maybe a runtime dll brought in by another application.

So, no point spending more of your time on it unless more have the same experience.
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Sat Feb 17, 2018 7:19 am

tvrfan wrote: ↑Fri Feb 16, 2018 6:18 pm
If we go for a shorthand like (U) then perhaps I should print a key at the top ?
I had added a glossary of sorts to my cmt file.
It contains a couple notes about PSW flags and detail for name abbreviations used in my Sym names.

How about, in the absence of a user cmt file, generate a default cmt with default glossary, and run the lst file generation after that?
R14H meaning high ?, unfortunately it's R15. if it's a long, then it's R17 ...
Yes, high was the context, but I don't recall where I saw it in use. May have been something on Decipha's site. May be as a result of a SYM name.
Yes, R15 and R17.
Signed/unsigned - tricky territory (believe it or not).
Many Arithmetic ops are totally blind to sign because of a very clever trick - have you ever wondered why (16 bit) -1 is 0xffff and -32768 is 0x8000?
oh yeah, have googled it more than once. The seemingly chaotic concepts that work for binary machines.


Also non-programmers will possibly miss tricks like this, which us IT geeks see straight away...

Code: Select all

LDW, R14, R26;                   R14 = R26;
LDW  R30, R15;                   R30 = R26/256;
[/quote]
Hmmmm, a perfect example of an implicit meaning a non-programmer overlooks!!!

Code: Select all

MULT R34, R32                   (L) R34 = R34 * R32;
LDX R30, R36                     R30 = (R34 * R32) / 32768
LOL, now that's just taking the mickey.
But I don't know how to show this reliably in SAD !!
Indeed, I have nothing right now.


motorhead1991 wrote: ↑Fri Feb 16, 2018 6:33 pm https://youtu.be/OH_S6pRbX64
Good stuff, looks alright.
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Sat Feb 17, 2018 1:47 pm

ender11 wrote: ↑Sat Feb 17, 2018 5:30 am I just want to insert my 7 cents. last year I disassembled GM binary fom gm C3 ecu. It was as usual - see, what parts of code are the same with known parts in already disassembled binary, and write what it is. I used ida pro, since gm used supported motorola mcu (and much less tricks).
what can I say? I had nearly the same progress in 1 month with gm binary, as in 1 year with eec-iv binary. apart from ida pro, there are opensource and free disassemblers, say 'radare2' (currently not supporting i8061). it's much better to use existing debugging interface than commandline tool, windows gui wrapper or anything else.
I did have a look at IDA, because you can (apparently) write plugins for any CPU. However I couldn't find decent docs on how to write one, and (in my head) what I could see got very complicated. I know it's very highly rated for x86 stuff though. Any links you might have are welcome, I'll have a read.

Funny that - I installed radare2 on my workstation to have a play with it....

GM Ecu - if it's the 68HC11 (definitely is on early 90's GMs) then that CPU has a much simpler opcode set. I did actually write a mini SAD for that for 'fun' (and to help a bit with understanding). But then GM released a whole load of good info, and it's a standard industry CPU chip.
But Ford didn't go that way.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Sat Feb 17, 2018 2:33 pm

jsa wrote: ↑Sat Feb 17, 2018 7:19 am
I had added a glossary of sorts to my cmt file.
It contains a couple notes about PSW flags and detail for name abbreviations used in my Sym names.
How about, in the absence of a user cmt file, generate a default cmt with default glossary, and run the lst file generation after that?
Great Idea - My answer - I'll have a 'default comment' file, with a glossary (etc) in it, and then have a command option whether to print it or not.
Then it fits in neatly with existing structure, and can be switched off.

A little lecture in case it helps...

The A9L listings have quite a lot of symxxL and symxxH which are for 32 (or 24) bit values. On later bins which have faster clock speeds A lot (all?) of them tend to have a 24 bit clock. When long adds appear you will see an ADDC (add with Carry) for the top (H) value after the lower (L) add. 32 bit adds (etc) have an ADCW (add word + carry) and 24 bit have ADCB (byte). This is the way to spot them.

I did consider doing this in SAD, but there are places where logic tricks mess this up....(they are all over the place !)

Arithmetics and sign. It makes sense once you get your head around it. Does it help if I say that ->

0x8000 -> 0xffff (= 0x0 -> 0x7ffff with sign bit set) is -32768 -> -1. Think of it as (0 -> 32767) minus 32768
0 -> 0x7fff (no sign bit) is 0 -> 32767

So there are two identical 'ranges' of 32768 values, which work in the same direction and are contiguous, so therefore plus and minus works seamlessly across those ranges with no extra work. By conventional maths, I guess it's true to say the sign bit is actually backwards (i.e. it should not be set for minus), but it gives a 'free' NEG flag for the PSW, and overflow from negative through to positive works correctly as it's only a binary bit.

If you go unsigned (no signed flag) 0 - 65536 works too. You can say that signed arithmetic simply shifts all values downwards by 32768.

As well as those implicit divides in my last post, quite a bit of the Ford code has shifts for divide and multiply.
I have replaced these in SAD where I think it makes sense.

so SHR 4 (shift right 4) = Value/16 and SHL 4 = Value *16;

As a lot of stuff is binary scaled (like for example say, stoich mixture is 0x4000) it then becomes simpler (and faster) to mess with.

Fount THIS in A9L for example...

Code: Select all

2b22: c3,74,1e,54         stw   R54,[R74+1e]     Sapw = R54;                       # Spark Angle Pulse Width, msec.
2b26: 6d,ab,6a,54         ml2w  R54,6aab         (long) R54 *= 6aab;
2b2a: 75,80,55            ad2b  R55,80           R55 += 80;
2b2d: a4,00,56            adcw  R56,R0           R56 += CY;
2b30: c3,74,ca,56         stw   R56,[R74+ca]     Spout_low_time = R56;
so this appears to be Spout_low_time = ((R54 * 27307) + rounding)/65536 + Carry, or Spout_low_time = R54 * 0.41667
And from memory that 0.416 appears quite a bit in A9L timed stuff, so will equate somewhere to (a scaled) ticks per millisec or millisecs per tick
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Sat Feb 17, 2018 8:48 pm

tvrfan wrote: ↑Sat Feb 17, 2018 2:33 pm My answer -
....
Then it fits in neatly with existing structure, and can be switched off.
Very good, I reckon run with that.
A little lecture in case it helps...
....
This is the way to spot them.
Thanks, good hint to be mindful of.

Arithmetics and sign.

I just keep in mind, that the absolute value increases from B0 to B6.
Signed Binary.png
I have replaced these in SAD where I think it makes sense.

so SHR 4 (shift right 4) = Value/16 and SHL 4 = Value *16;
Yes, the decimal equivalent equation is very helpful in the output list.
Long may it live....
You do not have the required permissions to view the files attached to this post.
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Sun Feb 18, 2018 5:18 am

tvrfan wrote: ↑Sat Feb 17, 2018 1:47 pm I did have a look at IDA, because you can (apparently) write plugins for any CPU. However I couldn't find decent docs on how to write one, and (in my head) what I could see got very complicated. I know it's very highly rated for x86 stuff though. Any links you might have are welcome, I'll have a read.
not much stuff - https://blog.quarkslab.com/ida-processor-module.html
also, you should have ida pro sdk unpacked. it contains intel 80196 processor module sources, which may be a start point. but, as I can see, that operations - redefining operands, code chunks etc are usually perfomed with python scripts in ida.
tvrfan wrote: ↑Sat Feb 17, 2018 1:47 pm But then GM released a whole load of good info
never heared about it, how can I take a look at that? cpu is ok in gm ecu, but there are other strange chips there.

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Sun Feb 18, 2018 2:41 pm

ender11 wrote: ↑Sun Feb 18, 2018 5:18 am not much stuff - https://blog.quarkslab.com/ida-processor-module.html
also, you should have ida pro sdk unpacked. it contains intel 80196 processor module sources, which may be a start point. but, as I can see, that operations - redefining operands, code chunks etc are usually perfomed with python scripts in ida.
Thanks for the link. I will have a read. I've not used Python before, so some learning there.

I admit I haven't personally seen any specific stuff for GM ECU, apart from how to read the codes, but several blogs I read said the info is freely available, but I didn't look. Could be confusion over use of a standard CPU, and the HC11 stuff WAS freely available. I thought the supporting chips were standard too ?

You can always try the chip numbers in google - it's pretty good at finding them.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

ender11
Gear Head
Posts: 58
Joined: Fri Jan 06, 2012 10:14 am
Location: Krasnoyarsk, Russia

Re: Why auto disassembly is tough

Post by ender11 » Sun Feb 18, 2018 10:47 pm

tvrfan wrote: ↑Sun Feb 18, 2018 2:41 pm I thought the supporting chips were standard too ?
no way - delco custom chips with no information available besides what's reverse engineered.

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Sun Feb 18, 2018 11:39 pm

OK, sorry about that. My error. So it's just as custom as the Ford ECU, except for the CPU.....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: dir & cmt changes

Post by jsa » Mon Feb 19, 2018 6:31 pm

tvrfan,

Between V0.5 and V3.03 I see some differences in the cmt output for the table and function lookups.
The old command option, : F 2 38 34, gives odd results if added to the option string in the V3.03 dir.

Could you give an overview of the new lookup option strings output to the cmt?

Table Look Up seems to work for this code segment using the default from V3.03 cmt

Code: Select all

V0.5 cmt output
sub  263c  "UTabLU"   : F 2 38 34 

V3.03 cmt output
sub 263c "Sub263C_TabLu1"   #S #spf :TBLU L1=0* L2=0 P=0 D=0 A=878b0

Function Look Up seems to need the old option strings without the :
I saw the : mentioned in an earlier post by ender11.
https://eectuning.org/forums/viewtopic. ... 20#p130001

Code: Select all

V0.5 cmt output
sub  7773  "UUByteLU"   :E 2 f0 N  :W N  : F 1 1 1 

V3.03 cmt output misses the arguments if pasted to dir
sub 7773 "Sub7773_BFuncLu4"   #sz1 4 #S: E 4 f0 N [Af0 D32] : Y O 2 [A0 D34]  #spf :testx L1=1* L2=0 P=4 D=32 A=87773 :FnLU L1=0* L2=0 P=0 D=0 A=87794

V3.03 this dir string without : captures the first word argument but the second is shown as 2bytes, not a word. 
sub 7773 "Sub7773_BFuncLu4"   E 2 f0 N  W N   F 1 1 1
Edit1: Word LU's are giving unexpected results as well. Looks like something's up with LU's that take two word size arguments.

Edit2:
Symbol defined in dir

Code: Select all

SYM DCEF "Address_DCEF"
CARD Code, output to lst on L264A & L2660 looks to be incorrect

Code: Select all

  Sub263C_TabLu1:
263c: f9                  stc                    CY = 1
263d: 00                  skip                   goto 263f;


263e: f8                        

263f: a3,72,b0,30         ldw   R30,[R72+b0]     R30 = [530];
2643: a3,72,b2,32         ldw   R32,[R72+b2]     R32 = [532];
2647: ad,0b,34            ldzbw R34,b            R34 = (uns)b;
264a: db,03               jc    264f             if ((uns) 0 >= Address_DCEF) goto 264f;
264c: e7,61,52            jump  78b0             goto Sub78b0_TabLu8;
264f: e7,5b,52            jump  78ad             goto Sub78ad_TabLu7;

  Sub2652_TabLu2:
2652: f9                  stc                    CY = 1
2653: 00                  skip                   goto 2655;

  Sub2654_TabLu3:
2654: f8                  clc                    CY = 0
2655: af,72,b4,30         ldzbw R30,[R72+b4]     R30 = (uns)[534];
2659: af,72,b5,32         ldzbw R32,[R72+b5]     R32 = (uns)[535];
265d: ad,06,34            ldzbw R34,6            R34 = (uns)6;
2660: db,03               jc    2665             if ((uns) 0 >= Address_DCEF) goto 2665;
Edit3
Some more CARD with V3.03
I have unsuccessfully tried a few ways to define 2 words and a byte as the arguments to Sub459F.
This is how it looks with 5 bytes, thoughts on getting 2W and 1B?

Code: Select all

2e99: ef,03,17          call  459f           Sub459F(2,0,80,46,0);
2e9c: 02,00,80,46,00    #args  
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Tue Feb 20, 2018 4:36 pm

Those extra comments are again for my debug (L1 = level1, L2 = level2 (how many subroutines back via POP) d = data register a = address and P = num args) SZ1 (and SZ2) are end result of num arguments. S means subr has signatures detected inside it (because a subr can call other subrs to do their argument work...).

:F It doesn't do anything anymore , so not surprised is prints wrong values - I should have dropped it from options allowed.
BUT now I see this means a manual command has no way of defining a function lookup subroutine.... Damn! I made a hole there....

And -

That code example is EXCELLENT !! AND INCREDIBLY ANNOYING !!!!!

Seriously - extra thanks and kudos to you for finding this.

- what's going wrong - LDW and LDZBW don't change PSW, so the JC is looking back to find the last opcode which changed the PSW. Complicated by the SKIP, which is treated as a GOTO, so it is marked as end of scan block and 263f starts a NEW block scan. This explains why 263e is skipped over, because it's a Clear Carry (CLC) which would be CALLed by someone - (signed/unsigned) but may not be used. So JC is finding something it should not for its compare..... what it should do is print a simple " If (Carry == 1) " as it should not find a PSW changer.... Um......

I'll have to study this one !! There's probably more occurrences then....

For a subroutine with different data types do them in order, you should be able to do a command -

sub 12345 "somesub" : W O 2 : Y
or
sub 12345 : W : W : Y

which is 2 words followed by 1 byte (and name is optional)
Last edited by tvrfan on Wed Feb 21, 2018 4:31 pm, edited 1 time in total.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Tue Feb 20, 2018 4:52 pm

To explain a bit more, I should probably add that when code scan blocks are closed and new ones added, they aren't necessarily done in order, as they go in an ordered queue, so what that JC picked up could possibly be a long way away....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Tue Feb 20, 2018 6:01 pm

tvrfan wrote: ↑Tue Feb 20, 2018 4:36 pm
For a subroutine with different data types do them in order, you should be able to do a command -

sub 12345 "somesub" : W O 2 : Y
or
sub 12345 : W : W : Y

which is 2 words followed by 1 byte (and name is optional)
Yeah, just not working in V3.03 in general, for many different subr's.

I might want

Sub "2345_My_Sub" : W N : Y N : W N

At the moment function LU sub's are splitting the last word in to bytes unless I do this;
sub 7770 "Sub7770_BFuncLu3" : W N O 2
But then the Sym defined name for the first word is not used.

The old style options allow the name to show for the first word, but not the second, particularly with it being split into 2 bytes.


Thanks for the explanations on other queries.

Looking forward to V3.04.

Edit 1
This
sub 7770 "Sub7770_BFuncLu3" : W N : W N
Gives
2457: ef,16,53 call 7770 Sub7770_BFuncLu3(8268,);
245a: 68,82 #args
Ignoring the name and second word argument.
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Tue Feb 20, 2018 7:59 pm

John - that trailing comma in args gives me a clue ",)" at the end - The code adds a comma if there's more data to go, but then doesn't get printed - probably the size calc (which is master check) is screwed up (i.e. set to 2 instead of 4) ... Hmmm.

in xx_msg.txt do you see something like

sub 1234 "somesub" #sz1 2 #S: W N : W N ? that would confirm my suspicion.... (sz1 should be 4)

OOps, must fix comments to come AFTER the data definition so it can be reused in dir file....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Tue Feb 20, 2018 9:34 pm

tvrfan wrote: ↑Tue Feb 20, 2018 7:59 pm
in xx_msg.txt do you see something like

sub 1234 "somesub" #sz1 2 #S: W N : W N ? that would confirm my suspicion.... (sz1 should be 4)

Note the args on the next line. The second word is not on the args line.

Another example

Code: Select all

sub 41fe "Sub41fe"   : W : Y : Y
or
sub 41fe "Sub41fe"   : W : Y O 2
or
sub 41fe "Sub41fe"   : W : W
With or without N options gives

Code: Select all

3f66: 2a,96               scall 41fe             Sub41fe(3,);
3f68: 03,00               #args  
3f6a: 20,dc               sjmp  4048             goto 4048;
20,dc being ignored as an arg

msg out

Code: Select all

sub 41fe "Sub41fe"   #sz1 2 #cmd #S: W [A0 D0] : Y [A0 D0] : Y [A0 D0]
 or
sub 41fe "Sub41fe"   #sz1 2 #cmd #S: W [A0 D0] : W [A0 D0]   
This decodes the right number of args, but not W and/or Y options.

Code: Select all

sub 41fe "Sub41fe"   : W N O 2
Gives

Code: Select all

3f66: 2a,96               scall 41fe             Sub41fe(LIO_Port,dc20);
3f68: 03,00,20,dc         #args  
msg out

Code: Select all

sub 41fe "Sub41fe"   #sz1 4 #cmd #S: W O 2 N [A0 D0] 
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

User avatar
tvrfan
Tuning Addict
Posts: 590
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: Why auto disassembly is tough

Post by tvrfan » Wed Feb 21, 2018 4:31 pm

JSA - Thanks for that.

Found - problem on subroutine args size is only from a directive command, not from an auto added one.

But the Carry one goes deeper, and in fact I'm still not happy that it reports correctly.

Carry may mean different limits (e.g for subtract it's a borrow, add it's an overflow, shift ....) so I'm not convinced that my
(uns) xxx > 0 style is correct, I may have to add code which looks at what the previous opcode actually is....

So, I want to fix it properly. May be a few days....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

jsa
Tuning Addict
Posts: 1289
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Wed Feb 21, 2018 6:31 pm

Ok, thanks.
Cheers

John

95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag

Post Reply

Who is online

Users browsing this forum: No registered users and 30 guests