Why auto disassembly is tough

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: cgrey8, EDS50, Jon 94GT, 2Shaker

Post Reply
motorhead1991
Regular
Posts: 86
Joined: Tue Nov 21, 2017 2:32 am

Re: Why auto disassembly is tough

Post by motorhead1991 » Wed Jun 13, 2018 8:44 pm

tvrfan wrote:
Wed Jun 13, 2018 3:03 pm
You should be able to override any part you want with a command in a <name>_dir.txt file ( so "m0m2_dir.txt")
if it's a regular 2D table, then use a TABLE command, or if not use a STRUCT command and specify each element of the row. SAD knows how many rows by the start and end address (it calculates an entry/row size from the command).
Examples are in the SAD doc for the A9L injection structure, which I hope is enough to understand how to do it.

This kind of command does not affect the auto scanning of anything else, it just 'locks' that data as per your command.
SAD should not crash even if command is wrong, so you should be able to try a command and then fix it if necessary...

At the moment I haven't got code to analyse a mixed data structure type automatically.
That's just it. I have it laid out as a "table", and it keeps interpreting it as " code"
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

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Wed Jun 13, 2018 9:23 pm

motorhead1991 wrote:
Wed Jun 13, 2018 8:44 pm
tvrfan wrote:
Wed Jun 13, 2018 3:03 pm
You should be able to override any part you want with a command in a <name>_dir.txt file ( so "m0m2_dir.txt")
if it's a regular 2D table, then use a TABLE command, or if not use a STRUCT command and specify each element of the row. SAD knows how many rows by the start and end address (it calculates an entry/row size from the command).
Examples are in the SAD doc for the A9L injection structure, which I hope is enough to understand how to do it.

This kind of command does not affect the auto scanning of anything else, it just 'locks' that data as per your command.
SAD should not crash even if command is wrong, so you should be able to try a command and then fix it if necessary...

At the moment I haven't got code to analyse a mixed data structure type automatically.
That's just it. I have it laid out as a "table", and it keeps interpreting it as " code"
Doh! Blonde moment. ee00 extends outside the realm of SADs sizing boundary. If I set it for 64k, it should work fine.
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: 493
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: Why auto disassembly is tough

Post by jsa » Thu Jun 14, 2018 11:19 pm

tvrfan wrote:
Mon Jun 11, 2018 2:34 pm
Um.. I haven't tested that in a while, but SAD does have a D option,

Ok, my fault, the D 17C is good.

Code: Select all

ef,c4,12            call  1234             Sub1234(1b4,80);
38,80               #args       
Now, the second argument wants to be a bit field, have I missed an option to do something like this?

Code: Select all

ef,c4,12            call  1234             Sub1234(1b4,1000 0000);
38,80               #args       
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

3.07 released

Post by tvrfan » Fri Jun 15, 2018 2:33 pm

jsa -
No - I haven't got a bit field option in an arguments list. I'll add thet to my list - I assume it's so you can get a symbol name ??

I've just pushed 3.07 as my last thing before disappearing for a while.....

I've not fully tested it, but have got address ranges for symbols and rbases, and various other fixes for things reported.

I also added code for BWAK type binaries, which use the secondary stack (R22) for their background task list. This allowed SAD to go from decoding hardly anything in the BWAK3N2 to decoding most of it (but still more to do).

When I get back, I'm going to see if I can finally come up with a way to crack subroutine arguments correctly.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Fri Jun 15, 2018 3:04 pm

Thank you for 3.07.

I am am not sure whether symbol names are required or not. At the moment B7 is being tested but I need to look through the others to answer with certainty. I posted knowing 3.07 was imminent.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by motorhead1991 » Mon Jul 30, 2018 10:07 am

tvr is on vacation, no? It's too hot to be running my server currently, for the other project, but I still work on the disassembles from time to time. Github is a bit out of date, but has a couple new projects I think 🤔
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

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Jul 30, 2018 3:35 pm

I'm Back.....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Thu Aug 02, 2018 8:14 pm

Welcome back, another example of bit comparison and misleading output.

1110 0000 & 0000 0000 are not equal but Z_PSW is Set
1110 0000 & 0010 0000 are not equal but Z_PSW is Clear
0010 0000 & 0010 0000 are equal but Z_PSW is Clear

SAD 3.07

Code: Select all

b9d3: b1,20,3e            ldb   R3e,20           R3e = 20;                         # B5 Set 1

b9eb: 91,40,3e            orb   R3e,40           R3e |= 40;                        # B6 Set 1

ba06: 91,80,3e            orb   R3e,80           R3e |= 80; } }                    # B7 Set 1

ba09: b2,31,3c            ldb   R3c,[R30++]      R3c = [R30++];                    # B5 Set 1

ba2c: 50,3c,3e,00         an3b  R0,R3e,R3c       R0 = R3e & R3c;                   # 1110 0000 & 0010 0000
ba30: df,d7               je    ba09             if (R3e = R3c) goto ba09 ;        # Z_PSW Clear CONTINUE
in another loop it might be                                                        # Z_PSW Set goto ba09
Something like this would be better

Code: Select all

ba30: df,d7               je    ba09             if (Z_PSW = 1) goto ba09 ; 
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by jsa » Fri Aug 03, 2018 12:17 am

How to take this?

Code: Select all

ba76: 89,be,00,80,da
Apply this

Code: Select all

str  BA76 BA7A :Y :W N :Y :T +7
And get?

Code: Select all

ba76: 89,be,00,80,da      struct             89,My_Name,80,My_Flag
The 89 is a bit mask to control how My_Name is handled.
The 80 is the relevant Bit/s of DA.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by tvrfan » Fri Aug 03, 2018 5:12 am

jsa,

Damn, that example makes me realise that probably ALL the 3 op source substitutions "if (source) goto)" are WRONG....
OK - will look at that. Well spotted.

I take it example 2 is from the timer list ??

From your PM earlier.

symbol names - the problem is that sometimes, immediates ARE pointers to real items (e.g. a table). Similarly, indexed (i.e. [R30 +immediate]
may also be something like " testno + list_start". At the moment, if it's immediate and below 0xff (i.e. a register) then no symbol is allowed, otherwise
if it can find a symbol it gets used.... also can have structs in RAM ....

NB. this should NOT happen for register base pointers, which should always get converted to an immediate (absolute) address first, and THEN get checked for a symbol.

Yeah - it's not always right, but I don't know how to fix it.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Fri Aug 03, 2018 2:29 pm

Yes ex2 is a timer structure.

Really leaves the new range settings as the best way to handle incorrect naming. At the moment name ranges are inclusive, which is excellent for naming a scratch in a small piece of code, but very inefficient if wanting a name for nearly all code except a small piece. So could you add an excluding term for naming.

Something like...

Sym 234 my_name # the overall naming
Sym 234 ! 4567 456b # dont't name this code segment
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by jsa » Mon Aug 06, 2018 2:51 am

ok ok I can take a hint, :roll: ,I found your timer command example in your A9L Dir.

Eliminates the need for bit naming is this particular structure.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by tvrfan » Thu Aug 09, 2018 2:58 pm

TIMER - Actually I didn't mean it that way - I was just checking. Timer command is still experimental, and may fail.
SYMS - you could do sym xxx 1 2345 ... and sym xxx 2500 9ffff .... which would do the same !

Currently, I'm a bit distracted - to explain why.
I'm deep into trying to get subr arguments to work automatically - it requires changing the way the 'blocks' of code are scanned and linked, so that there is always a correct 'caller chain' for each subroutine, for every time it's called. This is actually a significant change from the current way SAD works. Currently SAD shortcuts the code scans, using 'signature' checking to see if subr has code which calls POPW (etc...). After subr scanned once, SAD just checks if signature is attached.

A 'block' of code is one which starts at a jump or call and goes to a jump or call, but skipping conditional jumps.

An example - Using A9L -

The subr at 3695 actually gets arguments for its grandcaller, via 3654 or 365e (which are the rolling average subrs). Currently in SAD 3695 is scanned only 3 times, because it's called at 3654, 3659, and 365e. The signature detector then assigns arguments to 3654 (and 365e) on their first call, and after that 3654, 3695, 365e code isn't scanned again. This works neatly (and quickly) for fixed number of arguments

To truly do variable arguments I can't think of any other way than to make the code get scanned/emulated for every call, and that requires
each CALL to have its correct call chain, so SAD can traverse back with the POPS, and then adjust the return addresses directly. So SAD requires changes right down to the base levels. And then, I need to add some emulation logic for cond jumps etc.

So it's complicated.....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Thu Aug 09, 2018 5:23 pm

Timer- no wories. Works well enough for the main timer control loop. Would be nice if you could enhance it so the control byte is used to generate auto comments for units, Inc/Dec, etc.

Picking up the variable arguments will be a big improvement. There is a variable argument subr in CARD also, that is at the core of a lot of mis-disassembled and missed code.
Last edited by jsa on Fri Aug 10, 2018 3:36 pm, edited 1 time in total.

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

Re: Why auto disassembly is tough

Post by tvrfan » Fri Aug 10, 2018 3:20 pm

Yes, I feel it's now pretty much essential to sort out arguments as next thing, before going on with anything else. (unless someone find a crash or something...)
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Thu Aug 16, 2018 7:25 pm

I have another request for a feature enhancement.

A DIR contains

Code: Select all

SYM 2B8 "Name2"
SYM 41C "Name1"
Some code looks like

Code: Select all

7d6b: a3,70,9c,3c         ldw   R3c,[R70+9c]

7d8a: a1,b8,02,88         ldw   R88,2b8
A CMT test might contain

Code: Select all

2345 #| $[R70+9c] does not output Name1 to LST

6789 #| $2B8 is output as Name2
Once the SYM 41C "Name1" is applied to [R70+9c]->[41C] the LST does not contain the value 41C anymore. I find it necessary to search for Name1 in the DIR to find the resolved address so I can put $41C in the CMT. [R70+9C] remains in the LST along with Name1.

To save time looking up the index address result could you extend name substitution so that SAD resolves indexed addresses in the comments?
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by tvrfan » Thu Aug 16, 2018 11:23 pm

How about an alternate method ?

Versions 3.04 on have prototype/test code for printing an OPERAND in the comment.
I haven't worked on it in a while so it might crash, but try it out with a \1 \2 or \3 in the text line.
It should work....and resolve names for indexed/indirect etc. as it calls the same routine as the main operand print with the opcode.
Note '\1' actually puts a true value of 1 in the test string, which is one of the old time 'control' characters

(to be honest I forgot about this completely, and saw it when checking the comment print code....!)

Progress -

Got a prototype auto argument getter partly working via basic code emulation....
but bloody A9L JUMPS TO A SUBROUTINE in several places..... AARGH!!!
I remember this caused me much pain with the signature handling last time.....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Fri Aug 17, 2018 8:04 pm

Consistency is better but an alternate is good too.

Tried a variety of syntax with \1 to \3 but output was just the various strings without conversion. Could not find examples in your a9l CMT or DIR.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by tvrfan » Fri Aug 17, 2018 8:38 pm

Oops, you are right. It don't work -- OK, I'll add that to the list of stuff....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Fri Aug 17, 2018 9:01 pm

no worries
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by jsa » Sat Aug 18, 2018 4:43 am

tvrfan wrote:
Fri Aug 03, 2018 5:12 am

Damn, that example makes me realise that probably ALL the 3 op source substitutions "if (source) goto)" are WRONG....
OK - will look at that. Well spotted.

Code: Select all

7beb: 47,f3,16,03,00,3e   ad3w  R3e,R0,[Rf2+316] R3e = Name; 
7bf1: df,36               je    7c29             if (R3e != 0)  {
This one really means;

Code: Select all

7bf1: df,36               je    7c29             if (Name != 0)  {
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by tvrfan » Sat Aug 18, 2018 3:30 pm

Hit a big problem with variable arguments which I'll have to rethink. It's looking more and more like if I can get A9L to work, ANYTHING else will probably work.....I reckon some of the 'nasty' code in there is patches applied afterwards by engineers.

So I shall go back to current prod version (3.07) and fix up what's reported here for a 3.08, and then go back to variable args version later....
and do other things on my list....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Sat Aug 18, 2018 5:54 pm

I hear you on the engineer edited code. CARD has code in different subroutines that is obviosly GUFB, LHBH1 or CDAN largely as per the respective strategy books. After working on it for a while there seems to be subtle differnces in programming style between them. Looking at CARD wastegate contol, the program flow is a different style again. Then you get opcodes used in different ways to check values or bits, that are foreign to the rest of the code.

With diverse methods in one binary, it is hard to imagine how an automated compiler would be configured to do that.

I PM'd you yesterday, looks like you missed it this morning as it shows as undelivered.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

Re: Why auto disassembly is tough

Post by tvrfan » Sat Aug 18, 2018 7:27 pm

Got PM now on this login....

Yeah, for you (jsa) and anyone else reading - there are a few argument getters which appear pretty much standard across the binaries.

There is a fixed size one, which basically is POP, one or more LDB (or STB) with autoincrement, and then a PUSH.

Code: Select all

3697: cc,3a               pop   R3A              R3A = pop();                      # Caller subroutine's return addr
3699: b2,3b,3c            ldb   R3C,[R3A++]      R3C = [R3A++];
369c: b2,3b,3d            ldb   R3D,[R3A++]      R3D = [R3A++];                    # 3C = Word param from caller
369f: c8,3a               push  R3A              push(R3A);                        # restore caller address (+2)
This gets 2 bytes from the return address of the subroutine.
but A9L ALREADY doesn't do this - it gets arguments from the GRANDCALLER (i.e. caller of the caller) - like this

Code: Select all

3695: cc,38               pop   R38              R38 = pop();                      # This subroutine's return addr
3697: cc,3a               pop   R3A              R3A = pop();                      # Caller subroutine's return addr
3699: b2,3b,3c            ldb   R3C,[R3A++]      R3C = [R3A++];
369c: b2,3b,3d            ldb   R3D,[R3A++]      R3D = [R3A++];                    # 3C = Word param from caller
369f: c8,3a               push  R3A              push(R3A);                        # restore grandcaller address (+2)
36a1: c8,38               push  R38              push(R38);                        # no change to local call
then the other common type is a little loop, which a local single parameter specifies how many params to get from the grandcaller

Code: Select all

77be: a1,1a,00,16         ldw   R16,1a           R16 = 1a;                         # default destination is R1a onwards
   Sub157:
77c2: cc,3c               pop   R3c              R3c = pop();                      # Caller's (normal) return address
77c4: b2,3d,3a            ldb   R3a,[R3c++]      R3a = [R3c++];                    # Get count of bytes, Inc return address
77c7: cc,42               pop   R42              R42 = pop();                      # Get GrandCaller's return address
77c9: b2,43,3b            ldb   R3b,[R42++]      R3b = [R42++];
77cc: c6,17,3b            stb   R3b,[R16++]      [R16++] = R3b;
77cf: e0,3a,f7            djnz  R3a,77c9         R3a--;
                                                 if (R3a != 0) goto 77c9;          # Get no of bytes into dest. addr
77d2: c8,42               push  R42              push(R42);
77d4: c8,3c               push  R3c              push(R3c);                        # and push modded returns back.
77d6: f0                  ret                    return;
using a djnz loop.....this code allows a default destination for the arguments (R1a) or you can specify your own externally and call 77c2.


But then A9L does some horrid things with jumps....

Code: Select all

7273: ef,79,08            call  7aef             Sub176();
7276: c9,7f,72            push  727f             push(Sub136);
7279: 28,12               scall 728d             Sub137(81,IO_Timer,STACK,46);     # SCCS Open Circuit Check, pars = E81,limit,bit mask(=SCCS),IO
727b: 81,06,10,46         #args  
   Sub136:
727f: 28,a4               scall 7325             Sub149();
7281: 91,10,46            orb   R46,10           R46 |= 10;                        # LSO output line 4 ON (Speed Control Vent)
7284: c9,97,72            push  7297             push(Sub140);                     # return from 7A76 to this address
7287: 28,06               scall 728f             Sub138(82,AD_Low,1,46);           # DOL Open Circuit Check, E82,limit,bit mask(=DOL),IO
7289: 82,04,01,46         #args  
   Sub137:
728d: 28,8a               scall 7319             Sub148();                         # SCCS controls off & stuff?
   Sub138:
728f: e7,e4,07            jump  7a76             goto Sub172;                      # Open Circuit Check function
it JUMPS to 7a76, a param getter, but does NOT call.

and then 7a76 does THIS

Code: Select all

7a76: 28,29               scall 7aa1             Sub173();                         # load params from stack & OCC base line test of circuit
7a78: ac,1d,20            ldzbw R20,R1d          WR20 = YR1d;                      # fourth param byte to word
# toggle output line for this device
7a7b: b2,20,1d            ldb   R1d,[R20]        R1d = [R20];     
and 7aa1 does THIS

Code: Select all

 
7aa1: 28,33               scall 7ad6             Sub175();                         # Repeatedly read AD channels 2.4mS
7aa3: cc,1e               pop   R1e              R1e = pop();                      # back up stack by one call
7aa5: 2d,17               scall 77be             Sub156(4);                        # Get 4 bytes from Grandcaller into R1A
7aa7: 04                  #args  
7aa8: c8,1e               push  R1e              push(R1e);       

which means that it effectively gets 4 arguments form the GREATGRANDCALLER of 7aa1!! (i.e. callers of 728d and 728f)
so this takes quite a bit of working out...

currently I'm calling the subroutines recursively, and creating a hierarchy chain, but it doesn't work for jumps - I added a fiddle for one jump level,
but the 7aa1 code messes up the chain....I could emulate the stack, but then that brings up a whole set of different issues , mainly that at the moment SAD does not necessarily scan the code in any defined order, etc etc etc....

This is partly why I've decided that this probably isn't from the compiler, as I don't think they are that clever (certainly not for 80's stuff...) and would
build single level arg getters. This looks like human code. I call it 'nasty' because it's hard to deal with, but it's perfectly good code...

And Yeah, I remember reusing quite a lot of code across projects - why reinvent your base ?? just adapt and reuse....so I'm not surprised that both strategies and actual code is reused....in part or in whole....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by tvrfan » Mon Aug 20, 2018 5:46 pm

Just a quick note - I've discovered that SAD does not work properly for single bank 8065 cpus if file size is not exactly 56 or 64K.
That is, if file does not 1) start immediately, or 2) has 'standard' 0x2000 filler at the front. This might apply for some multibanks too.
(the 4TAB I have is an 'odd' 90K in size)

Will fix this in next release.

EDIT - 30 Aug - I've also found that the 4DBG bin I have has an empty bank first, which happens, BUT SAD gets confused by the fact this
empty bank has the text copyright messages in it.

This all used to work I think, but I've broken the code by trying to improve bank and copyright text detection for more and more bins
(e.g. found a bin with a missing byte at the front, and one with an extra NOP at the front, both of which I saw later....)

Or perhaps I picked up the 4DBG and didn't test it - can't remember for sure.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by tvrfan » Wed Sep 19, 2018 3:59 pm

Update .....

This is a bit like Whackamole....

I downloaded more bins to test, and discovered that whilst it's not too bad to write code which works for *many* bins,
getting it to work for *all* bins is a lot harder.....

I'm still testing, but discovered more bugs in the way that -
1) banks are detected
2) background task lists are identified

caused by the various different file layouts, and a surprisingly large number of different ways to CALL a list of addresses !!

So still working away when I have the time, and making progress.
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

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

Re: Why auto disassembly is tough

Post by jsa » Wed Sep 19, 2018 8:00 pm

Thanks for the update. Good to hear you are making progress.
Cheers

John

95 Escort RS Cosworth - GHAJ0 / ANTI on a COSY box code
Moates QH & BE
ForDiag

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

SAD 3.08 released

Post by tvrfan » Mon Sep 24, 2018 6:52 pm

Just released 3.08.

Mainly, this is for sorting out bank detection, for all bins, including those with a few missing or extra bytes at the front, and empty front banks.

I was doing further carry/conditional stuff (from jsa) but stumbled across the bank problem after a PM from ranga83 telling me he couldn't get Aussie bins to work (which are single bank 8065 in several cases), so some carry stuff included too.

See versions file, but mainly
1) have rewritten large parts of bank detection to use a score system for best match, and fixed several bugs in the process.
2) added more handling of conditional jumps (including 3 ops, R0 = , and cmp R0, ..) to get correct source. Sometimes it still shows (0=0) when it can't find the right psw setter... on future fix list.
3) rework the background task list detection yet again.... later bins do some extra stuff between the PUSH and the RET. Much better. Also handles
multibanks (where list is in bank 1 but addresses point to bank 8 )

Notes -
For bins with empty front bank with the copyright message in it, The Copyright won't be printed, bank is skipped entirely.

I have a couple of bins which seem to have two code banks (not allowed!!) but from names, may be a dump of original followed by modded version, so I have changed SAD to print first code bank found. Current SAD code can only handle one start point in bin.

so - where was I up to before this little bomb ?? Oh, variable arguments.....right......
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

mpaton
BIN Hacker
Posts: 370
Joined: Mon Jun 23, 2008 1:39 pm

Re: SAD 3.08 released

Post by mpaton » Tue Sep 25, 2018 5:13 pm

tvrfan wrote:
Mon Sep 24, 2018 6:52 pm
I have a couple of bins which seem to have two code banks (not allowed!!) but from names, may be a dump of original followed by modded version, so I have changed SAD to print first code bank found.
I don't understand the issue with 2 banks of code.

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

Re: SAD 3.08 released

Post by tvrfan » Tue Sep 25, 2018 7:25 pm

Er - I can see that what I wrote might be misleading....

Perhaps I should have said " 2 x bank 8"

Yes, *ALL* banks in a multibank can have both code and data, but only ONE contains a true 'start' jump at the beginning of the bank, which is bank 8.

A true start is the one which jumps over the interrupt vectors, i.e. is >= 0x2060.
The other banks have a loopstop jump in them - looks like a safety feature in the code.
I use this in SAD to find the correct bank 8

I have a bin file with a name of "4TAB_EL_SPARK.bin" which is 256K, comparing with a plain "4TAB.bin" which is 64K.
the 256K one has two banks which have a jump > 0x2060 at the front, and intr lists (0x2010..) appear identical, making me think it's two versions
of same code packaged together....

I know that the Aus. Falcon had an 'EL' model, so that fits....
TVR, Triumph (cars), kit cars, classics. Ex IT geek, development and databases.

https://github.com/tvrfan/EEC-IV-disassembler

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests