SAD disassembler progress

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

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

SAD disassembler progress

Post by tvrfan » Sun Dec 02, 2018 5:26 pm

Just a quick update, and start a new topic...

I have A9L working with auto detect of subroutine variable arguments, but it has a 'kludge' in it which I don't really like.
At the moment it only shows a list of bytes as arguments, as that is how they are read off. Next step is to work out how they get read/processed, and where an 'answer' is returned (in a register normally) for better arguments display. But it works so far ....

Had to change the way SAD does the scans to make sure subroutines always get to the RET, which got in the way.
Haven't implemented if-then yet emulation either (for CARD etc), only djnz for testing (all of A9L uses djnz for its extract loops).

Slow progress, but getting there.....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Mon Dec 03, 2018 1:00 am

Thanks for the continued effort, great to hear you are making progress.
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Wed Dec 05, 2018 10:53 pm

DAMN !!! Well I *was* making progress, until I came across THIS... (from CARD)

Code: Select all

4459: f9                  stc                    CY = 1;
445a: cc,18               pop   R18              R18 = pop();
445c: b2,19,1a            ldb   R1a,[R18++]      R1a = [R18++];
445f: b2,19,1b            ldb   R1b,[R18++]      R1b = [R18++];
4462: b2,19,1c            ldb   R1c,[R18++]      R1c = [R18++];
4465: b2,19,1d            ldb   R1d,[R18++]      R1d = [R18++];
4468: d3,05               jnc   446f             if (CY = 0) goto 446f;                # 4 bytes
446a: c9,fa,40            push  40fa             push(@Sub87);                     # + 2 extra bytes 
446d: 20,02               sjmp  4471             goto 4471;

446f: c8,18               push  R18              push(R18);
4471: 91,02,2c            orb   R2c,2            R2c |= 2;
....(to a RET)

   Sub86:
40f8: cc,18               pop   R18              R18 = pop();
   Sub87:
40fa: ae,19,14            ldzbw R14,[R18++]      wR14 = [R18++];
40fd: b2,19,17            ldb   R17,[R18++]      R17 = [R18++];
4100: c8,18               push  R18              push(R18);
which means that the PUSH (from checking Carry flag) causes 2 more bytes (arguments) after processing returns.
This is the same as the A9L PUSHing a different return address for a subroutine too, and my 'kludge' gets over that one, but not THIS bit of code...

I was hoping not to have to maintain a fake stack (currently SAD links code blocks by CALLER in a chain, so a RET simply drops back to caller block.) but now it looks like I might have to....

hmmm.... I'll have to think about this....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Thu Dec 06, 2018 3:59 am

Yes, indeed.

I have not made note,in CMT, of the reason for having JNC on line 4468 when it is set at line 4459. May as well just jump as best as I can tell.
Cheers

John

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

sailorbob
BIN Hacker
Posts: 1672
Joined: Tue Jul 12, 2005 6:10 am

Re: SAD disassembler progress

Post by sailorbob » Thu Dec 06, 2018 10:18 am

Have a look a couple of lines above, at 0x4456, where a different entry point to the subroutine is used.

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

Re: SAD disassembler progress

Post by jsa » Thu Dec 06, 2018 12:14 pm

:shock: thanks, better get my eyes checked.
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Wed Dec 19, 2018 3:30 pm

Update -
I feel like I'm stuck in the "all alike maze" in the old text adventure game "...you are in a maze of twisty little passages, all alike..." in a kind of multifaceted catch 22.... To cover THIS bit I need logic to do THAT, but THIS bit in CARD needs it to work differently, and THIS bit in here needs another .....

I've got A9L working pretty well now, without the kludge, including the pop() shortcuts (7273 - 7292 approx) , but then as I go, I discover new things in CARD (as posted above) and multibank versions in 22CA which blow my logic assumptions about the way if-then-else and loops are structured, and it falls apart again.

From the Ford viewpoint, it seems that either the compiler/code got a lot more efficient at optimizing the end result, or the programming team did. Those neat little tricks make the code smaller, with more reuse of the same segments, but it makes it harder to unscramble. And there's many ways of writing code to do those same jobs...

So I'm stuck at the moment.....I need a new idea or several....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Wed Dec 19, 2018 10:01 pm

I think CARD is a conglomeration of different age strategies.

Some sections of code look like GUFB, others look like CDAN and a sprinkle of LHBH1.

Depending on the section of code, the loops are programmed differently. It looks like they plucked a block code from one strat, grabbed something else from others then patched it together.

Lurking is the depths is a 2 digit fault code while all others are 3.
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Thu Dec 20, 2018 10:08 pm

Yes, there is (rightly) a lot of reuse. For example, so far I've only seen 2 1D lookup (function) code versions (OK some with minor variations) and 2 versions of the 2D code (tables). Why reinvent something which works ?? Mathematically and codewise, the way the 2D data is interpolated is very neat and quite clever.

It makes perfect sense to grab different bits of working code and repackage, and perhaps only have to fix up some of the 'glue' which holds them together... We did that all the time - reuse and adapt !!

My problem stems from trying to merge a 'static' tree analysis with an emulation pass for arguments, and expecting the code to always 'flow' the same. I've got some things to try out already ....
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by motorhead1991 » Thu Dec 20, 2018 10:17 pm

tvrfan wrote:
Thu Dec 20, 2018 10:08 pm
Yes, there is (rightly) a lot of reuse. For example, so far I've only seen 2 1D lookup (function) code versions (OK some with minor variations) and 2 versions of the 2D code (tables). Why reinvent something which works ?? Mathematically and codewise, the way the 2D data is interpolated is very neat and quite clever.

It makes perfect sense to grab different bits of working code and repackage, and perhaps only have to fix up some of the 'glue' which holds them together... We did that all the time - reuse and adapt !!

My problem stems from trying to merge a 'static' tree analysis with an emulation pass for arguments, and expecting the code to always 'flow' the same. I've got some things to try out already ....
Sent you a PM, tvr.
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

teal95
Regular
Posts: 102
Joined: Fri Oct 18, 2002 2:46 pm
Location: Walkerton, IN

Re: SAD disassembler progress

Post by teal95 » Wed Dec 26, 2018 4:09 pm

Realize that important sections that get used frequently (like interpolations) probably got written directly in assembly by the programmers as any efficiency they could gain gets multiplied many times as this chunk of code gets used so often.

It doesn't surprise me that some of the stuff that was passed down from older programs weren't updated at all. I imagine even the compiling was done in chunks and when routines were used it grabbed the already compiled pieces instead of compiling everything every time.

steve
'95 GT - T4M0 x3
'93 notch - A9P
'87 TC - 8UA or LB2 or LA3 x2
'85.5 & '86 SVO - PE x2
'83 & '84 GT turbo - TA x2

caish
Gear Head
Posts: 9
Joined: Fri Mar 08, 2019 4:42 pm

Re: SAD disassembler progress

Post by caish » Mon Apr 01, 2019 8:38 pm

I was tinkering with different files, and d/led a bin, trying to learn..
Thought what if...
So grabbed a linux disassembpler, not sure I got the right cpu, as I think I read the Ford uses 8051, thre was one for it, but couldn't get it to cooperate.
But one for 8052 produced this assmbely from a Ford Bin...
for give me if I did something wrong posting...
P5X0.txt
P5X0.bin dissassembled
(458.01 KiB) Downloaded 22 times

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

Re: SAD disassembler progress

Post by motorhead1991 » Mon Apr 01, 2019 8:46 pm

caish wrote:
Mon Apr 01, 2019 8:38 pm
I was tinkering with different files, and d/led a bin, trying to learn..
Thought what if...
So grabbed a linux disassembpler, not sure I got the right cpu, as I think I read the Ford uses 8051, thre was one for it, but couldn't get it to cooperate.
But one for 8052 produced this assmbely from a Ford Bin...
for give me if I did something wrong posting...
P5X0.txt
Nothing wrong with posting different methods, however the one provided is useless :thumbup:

Ford used the 8061 and 8065 BTW.
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

caish
Gear Head
Posts: 9
Joined: Fri Mar 08, 2019 4:42 pm

Re: SAD disassembler progress

Post by caish » Mon Apr 01, 2019 9:41 pm

motorhead1991 wrote:
Mon Apr 01, 2019 8:46 pm


Nothing wrong with posting different methods, however the one provided is useless :thumbup:

Ford used the 8061 and 8065 BTW.
oops, thought I read 8051 or 8052.....
back to square one...
Thanks

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

Re: SAD disassembler progress

Post by tvrfan » Thu Apr 04, 2019 5:59 pm

Just seen this (on holiday at the moment).

to learn from scratch without SAD, the 8061 is based upon a 8096 core cpu, so that disassembler 'sort of' works.
8065 seems to be a unique extension as far as I can tell (i,e, no 8096 equivalent). You can still find some stuff
on 80C196 CPU (which is pretty much the same, more modern CMOS version)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

New SAD version soon

Post by tvrfan » Tue Oct 29, 2019 1:48 pm

Update after being far too long getting next version ready, here's my announcement

Where I am up to -

I have FINALLY got a method which seems to work for all my 'test binaries' collection, including variable argument decodes. The variable arg analysis proved HUGELY harder than I expected, and I again had to fundamentally change the way SAD decodes the binaries, as it kept going into infinite loops.
I may call this version 4.0.1 and ditch the 3.x set

So it now gets the arguments right, but there's more to do.

What's left, that does not always work right -
1) tables (2d lookups) and funcs (id lookups) sometimes get cut off early (where word or byte command/detect gets in the way)
2) Still some code left undecoded (not sure why, unless they are called inside data structs as pointers, or vects (pointer lists) being cut off early).
3) Sometimes get overlapping commands printed out.
4) need some way to investigate data structures to do auto layout
5) doesn't always get arguments the right size (reports as bytes instead of words)
6) probably be some 'old' or leftover bugs from 3.08 to fix

also I see quite a lot of "if (0=0)" printouts, but see that it IS after a CMPW 0,0, which looks very weird, but appears correct.
It may be a way to fixup the code manually afterwards. A9l had what looks like "goto xxxx" inserted in places, so perhaps CMP 0,0 is a neater way, but it still looks weird.....

So i want to fix 1) and 2) before I release it, and leave 3) onwards until after any bug reports come in...........

tvrfan
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Tue Oct 29, 2019 9:17 pm

How's the new one at automatically picking up variable argument quantities?
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Wed Oct 30, 2019 1:45 pm

the code now has 2 distinct 'phases'.

It scans the binary as a 'tree' (i.e. jumps and calls create a new 'branch' as a block to be scanned), but keeps a fake stack of 'callers' up to date.
and if it finds a POP or LDX [STACK+n] command, it flags that scan branch as an argument getter, and then flags the branch with the arguments as
requiring emulate. every block is scanned only ONCE.

When it hits a RET opcode, it checks to see if that scan block requires emulation. If so, it does an emulate of just that branch (and called branches)
to actually do the code, and get the arguments. It then adds an ARG command to log the arguments.

That's the simple overview anyway.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Wed Oct 30, 2019 3:07 pm

All sounds very promising and like a lot of time has gone into it.

Looking forward to giving it a run when you let it out.
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Wed Oct 30, 2019 4:54 pm

More -

Problem with loops was for tabs and funcs (2D and 1D lookups). SAD did originally rescan those blocks to get the parameters (address and size) out (from the call tree), but that caused loops when trying to link it with emulate (complicated by the fact that the function lookup code has JUMPS in it for the options, so it all got horridly complicated, because you need to keep track of which subroutine option was actually called. Similar for the original fingerprint detect of the param getters (ie. those which POP and get bytes), which also required rescans. I tried many different ways, and they all failed.

So now the code is able to go forwards or backwards (after each block has been scanned once, code keeps note of where each opcode starts) so it can do a 'reverse scan' to get address values for tables and funcs, and for conditional jumps (for "if (x = y)" style code) which is very different to version 3.x design.

It DOES get the correct bytes for each argument call, and it attempts to work out the size, but it don't always work (yet). Also it doesn't display the 'encoded' addresses used in a lot of places (the ones which use 0xf0-0xfe registers as pointers) as yet. So symbol names in args don't always work right either.

But no "invalid opcode" warnings is a big step forwards........especially on the multibanks, which were another layer of complication when the call tree swaps banks in the middle of it.

Hopefully in a couple of weeks, I'll release one for evaluation and bug reports (of course!)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Wed Oct 30, 2019 9:14 pm

Looking over this thread, how did you go with post 3 above?

Stepping back through the code sounds a winner.

It will be interesting to see what 4.x does to avoid inv opcodes resulting from variable args.
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Wed Oct 30, 2019 10:53 pm

Ah Yes, a good reminder.

I couldn't get that to work either !!

In the end I added a special extra emulate pass/block, flagged/created from the push, which executes before the 'final' return (this is where the args are)
so that gets more args if required.

and it seems to work !!
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Fri Nov 01, 2019 2:33 am

Entry at L4456 skips Sub40FA.
Entry at L4459 does Sub40FA which is the subject of the recent post about multiple addresses for 1 arg.
L4471 B2_R2C is for Fault Code clear or set.

So reverse scan is different to stepping back through the code?

It works....perfect!
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Tue Dec 10, 2019 3:18 pm

OK, sorry about further delay, I ran into a tricky bug...

Anyway, I've now got SAD v4 to work correctly for variable arguments, and it also is able to size and decode those arguments.
(decode is where the argument has a value like 0xd040 which equates to address [0xfa] + 40 ). I've found FOUR versions of this
encode system so far). Still testing, but it seems to work so far. I'm sure there's more bugs to find though.....

The code looks to be all correct. No invalid opcodes. Multibanks work too.

Issues to fix -

It still doesn't always pick up blocks of code which are referred to by a 'sneaky' PUSH, RET. A9l does an R34 = 79f9; in one place, and
elsewhere does a PUSH(R34); So 79f9 block is missed as a code block. CARD also does this for 4510.
Also not where a data structure has a subroutine reference (common in injection timing tables).

It doesn't always correctly extend tables and funcs to their true end, where rows have repeated data.
Need to double check multibanks, as I think the bank in the address reference is sometimes wrong as well. (= missed data)

I also had to change the command/data structures internally and I haven't reflected this back into the directive reads (yet.....).

But I will publish as V4.0.1 to Github so you can play with it, next week probably. (I need to do a WIndows build and check it)

Just don't run it with any of the fancier directives, as they probably will error, or not work.
Symbol names, scan, and so on should be OK, but not subroutine or advanced struct ones.
Last edited by tvrfan on Tue Dec 10, 2019 3:37 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: 428
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

Re: SAD disassembler progress

Post by tvrfan » Tue Dec 10, 2019 3:36 pm

jsa wrote:
Fri Nov 01, 2019 2:33 am
So reverse scan is different to stepping back through the code?
Yeah in my head anyway.
I originally kept a 'pile' of previous opcodes for conditional jumps, and stepped back through them, but now I've changed the code so that it can simply feed in ANY (valid) opcode start address and get it decoded. I did this so the code can do emulation of a subroutine for its arguments as a separate 'phase' within the scanning process. This came along with the idea of 'searchable' opcodes (e.g. look backwards or forwards for a 'jump', or an opcode which sets the PSW, etc.) Code keeps a simple bit array of where the opcodes start to provide this.

I then realised I also had better ways to sort out finding table (2D) and function (1D) lookups, which didn't require scanning those lookup functions over and over, which was the cause of a lot of loops and problems.

So hopefully, this will work.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by jsa » Wed Dec 11, 2019 12:55 am

No apology necessary. Sounds a nice chrissy present to try out.

Thanks for the explanation of changes.
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Sat Dec 14, 2019 3:26 pm

POSTED version 4.0.1 to github.

I did try out the full A9L directives file, but WITHOUT any SUB commands, as they won't work any more
(did args and lookups in totally different way). The struct commands still work..........but no guarantees.

Try version 4 out with NO .DIR file first, and see how it does....

Enjoy !! (I hope)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD disassembler progress

Post by motorhead1991 » Sat Dec 14, 2019 4:06 pm

tvrfan wrote:
Sat Dec 14, 2019 3:26 pm
POSTED version 4.0.1 to github.

I did try out the full A9L directives file, but WITHOUT any SUB commands, as they won't work any more
(did args and lookups in totally different way). The struct commands still work..........but no guarantees.

Try version 4 out with NO .DIR file first, and see how it does....

Enjoy !! (I hope)
There you go, changing the way we all know how to do this :lol: .

I'll give it a shot on m0m2 when I get home.
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: 615
Joined: Sat Nov 23, 2013 7:28 pm
Location: 'straya

Re: SAD disassembler progress

Post by jsa » Sat Dec 14, 2019 5:18 pm

Thanks for all the work on the new version.

[WARNING]
I have a sub entry for _every_ single subroutine in my CARD dir. It will be very interesting to see how SAD 4.0.1 goes from a cold start.
[/WARNING]
Cheers

John

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

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

Re: SAD disassembler progress

Post by tvrfan » Sat Dec 14, 2019 5:44 pm

jsa wrote:
Sat Dec 14, 2019 5:18 pm
Thanks for all the work on the new version.

[WARNING]
I have a sub entry for _every_ single subroutine in my CARD dir. It will be very interesting to see how SAD 4.0.1 goes from a cold start.
[/WARNING]
OK - change the SUB to a SYM to get your names back.
Just please drop off any additional stuff (like the arguments and special types).
Internally, SAD code did this anyway for the name part so it's not a big change.
TVR, kit cars, classic cars. 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 2 guests