SAD (disassembler) - Update

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: 409
Joined: Sat May 14, 2011 11:41 pm
Location: New Zealand

SAD (disassembler) - Update

Post by tvrfan » Sun Nov 22, 2015 8:35 pm

Guys - just to let you all know.

I haven't been idle, but when trying to solve some complex stuff, I keep running into 'catch 22' situations, and so far I've not been able to crack a way to fix some things.
It's very, very frustrating. 4 examples of quite a long list -

How to tell between a vector list (e.g. the background task list) and a structure like the A9L HSO table, which has a mix of subroutine addresses and other things.
The HHX0 bin which mpaton posted showed me yet another variation of parameter extraction which would not have worked automatically via SAD.
There are subroutines in some multibanks which have VARIABLE parameters, according to pars fed in.
How to tell if there is a data parameter in a subroutine list (A9L has these !)

I tried the idea of emulation of opcode instructions, mixed in with some static analysis, and that didn't work.
I tried doing loop analysis, that didn't work either.
I ended up chasing around a loop with "if I do this it will break that, and if I do that it will break this....", and this got horribly complicated.
I need to think of some cleverer ways than I've got now.

So - what I intend to do is to produce a MANUAL version, which will do some limited analysis to start (bank layout, interrupts) but will work via user commands.
This will allow me to sort all the bugs to do with printout, commands, etc, probably add some commands/capabilities, and then I can add the 'intelligent scanning' onto this base.
I am also thinking this base could provide for an 8061/8065 emulator .... which might be useful for some.

So I will be doing a manual version and trying to make it rock solid, fixing reported bugs, and playing separately with ideas for automatic analysis on the side.
I will make a Win32 and Linux version (DOS command line anyone ?), with the same 'core' and different interface modules to fit the OS.

Comments, bug reports on existing versions, feature requests etc. all welcome.

The suggestion to put source code etc. on Github is a good idea too, I'll look at that.

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

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

Re: SAD (disassembler) - Update

Post by jsa » Mon Nov 23, 2015 1:04 am

Well i can only pretend to understand the issues you mention.

Working through recent examples it occured to me that dissassembly looked like a database build and analysis problem. You probably do this already, right ?

How do you deal with the myriad branches and keep track of all the permutations ?

Do vector lists all work like the list in GHAJ0 at 0x2022. Where going to the first address, leads to the second address and so on ?
Cheers

John

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

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

Re: SAD (disassembler) - Update

Post by tvrfan » Mon Nov 23, 2015 2:29 pm

jsa wrote:Well i can only pretend to understand the issues you mention.

Working through recent examples it occured to me that dissassembly looked like a database build and analysis problem. You probably do this already, right ?

How do you deal with the myriad branches and keep track of all the permutations ?

Do vector lists all work like the list in GHAJ0 at 0x2022. Where going to the first address, leads to the second address and so on ?
At a high level......Emulation versus static.

Emulation runs the code in a fake environment. A static approach basically constructs a tree of all the branches (via the different kinds of jumps).
Both approaches have issues.

The problem with emulation is that it's effectively impossible to ensure every branch is executed.

The problem with a static approach is how to interpret 'inconsistent' areas and lists (i.e. whether a lump of data is data, or code, or a complex structure) and things like inline parameters require detail code checking.

Some disassemblers use both approaches together.
The 'real time' nature of EEC box doesn't help either.

SAD uses a static approach. It internally constructs a chained 'tree' via jumps, calls, returns etc. This requires extra checks for things like the background task list, and special checks for PUSHW, RET sequences (which are in effect the same as a CALL, and how lists get coded). It also has a kind of 'signature' match to recognise lumps of code for particular jobs (like table lookup). At the moment, SAD also does some partial emulation of each opcode, so that data addresses can be resolved. But it still has limits and holes.

Interrupt vectors are easy, because they are all the same, and you would know that they can't have inline params, or mess with the stack very much.

loop analysis is to look for backward jumps, and try to decide if this is the end of a loop (equivalent of "for i=0 to x" ) but more then one way to code this, and when you get if-then-else inside, gets horrid, or at least, I haven't cracked it yet.....

DATABASES

By comparison database analysis and design is really a detailed tour around some base questions, (Yes, I was a database designer !) mainly -
How is the data made up.
How do you want to search for the data you want.
Is there anything guaranteed to be unique in the data item(s).
How do data items link together or refer to each other.
< a few more around this theme >

And if you design it right, you should be able to index it so 95% or more of all the searches are FAST (via indexes).

Always happy to talk about database design, it's quite geeky, but getting it right is very rewarding. I regard success as when search stats tell me that at least 95% of searches come back in 2 secs or less. Managed this on some quite large databases ( > 10 million row tables) with careful design. Had some arguments with customers who insist on a particular layout, and you know that layout is simply garbage for performance.....can be fun to try to get them to understand...

Oh, yes, different DB engines also have different quirks......
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10699
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: SAD (disassembler) - Update

Post by cgrey8 » Mon Nov 23, 2015 6:59 pm

I get that in emulation, some jumps may never get called in emulation mode. However, can't you identify all jumps (or branches) you encounter, keep track of them, and then check later that all branch directions have been covered. And if they weren't follow back with them, and follow the alternate direction? Doing that may find more branches, so it'd have to be iterative until you have no more KNOWN branches to evaluate. At that point, then maybe do a static analysis to see if there were more that you missed. And if you missed them, determine why (i.e. orphaned code, bug in algorithm). If it's orphaned code, then it was benign to start with.

Or is this statement a facile view of the problem?
...Always Somethin'

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

Member V8-Ranger.com

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

Re: SAD (disassembler) - Update

Post by tvrfan » Tue Nov 24, 2015 5:29 pm

I would not say 'facile', I think that's a bit too harsh ... Perhaps I might say 'simplistic'.
cgrey8 wrote:I get that in emulation, some jumps may never get called in emulation mode. However, can't you identify all jumps (or branches) you encounter, keep track of them, and then check later that all branch directions have been covered.
This sounds fine in principle, but you get into many layers quickly. For example - You have a 'hole' where nothing else refers to. Is it code ? or is it data ? Is it a list of vector (subroutine) addresses? It is a hole because something somewhere else has gone screwy ? If you decide it's code, it might work for a while and refer to other addresses (which may also be dodgy) - what do you then do if you get an Invalid opcode ? Ditch all of it, or just up to the invalid opcode ? This means it may have spawned a whole new set of errors. You might decide it's a vector list. It works happily for say 4 addresses, and then you get a invalid address (say a zero). Is that a list end, or just a data word, or dodgy list ? [In fact A9L has that very problem - I can see correct solution in my brain, but can't work out how to do reliable code to handle it]

Even some seemingly simple things - e.g. many bins (A9L included) have timing numbers for PIP via number of cylinders, and address quoted needs to have 4,6, or 8 added to it, so the 'base' address actually points to code. Sure, in your head this is simple to spot, but for an automatic disassembler, not so easy..... Should therefore allow every index address to have 4,6,8 as a possible offset ? And so on into madness.....

[ Did you know technically the A9L could handle 6 cylinder engines ? ]
cgrey8 wrote: And if they weren't follow back with them, and follow the alternate direction? Doing that may find more branches, so it'd have to be iterative until you have no more KNOWN branches to evaluate. At that point, then maybe do a static analysis to see if there were more that you missed. And if you missed them, determine why (i.e. orphaned code, bug in algorithm). If it's orphaned code, then it was benign to start with.
Again, the analysis program is dumb, so if you get a series of errors, it becomes impossible to decide what's valid and what's not.....

So on the top level it seems easy, but then when you start going down the rabbit hole, you end up with a set of overlapping "what ifs" and it gets horribly complicated.
Either that, or I'm not clever or sneaky enough to crack it !
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

User avatar
cgrey8
Administrator
Posts: 10699
Joined: Fri Jun 24, 2005 5:54 am
Location: Acworth, Ga (Metro Atlanta)
Contact:

Re: SAD (disassembler) - Update

Post by cgrey8 » Wed Nov 25, 2015 7:58 am

No, that's just a tough nut to crack without a human at the wheel to make these decisions.

But what might be useful to the human is for the code to do as much as it can and make a dump of everything it is highly confident of. Then list the things it tried to figure out, didn't find a problem with, but is still suspect of, and finally areas that it was just lost on. I'm sure if you've seen 100 different strategies, you already know these areas, where they'll be, and what the contingencies in those areas likely are, and thus don't need the disassembler to point them out. So perhaps that's a lot of work for little-to-no ultimate value.

One of the things I'm amazed at is that vector lists aren't well known. I've always associated vectors as being event handlers that get associated to specific events. Different processors do events (i.e. Interrupts) differently, but I thought these processors had it such that a specific memory address was dedicated to specific hardware and software events. No? If no, how are hardware events setup and associated to their event handler (aka Interrupt Service Routine)?

As for facile, well after hearing your explanation...yeah, facile...with all of it's undertones.
...Always Somethin'

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

Member V8-Ranger.com

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

Re: SAD (disassembler) - Update

Post by tvrfan » Wed Nov 25, 2015 2:02 pm

Just a quick correction there - the INTERRUPT vectors ARE of course well known, and not a problem. They are in a fixed place. In the later bins with extra fancy hardware, there are some fixed addresses linked to hardware functions. For the CPU itself though, there's only those first few registers and interrupt vectors. Everything else is software.

The main 'background task list' and the 'self test' vector/subroutine lists can be anywhere in the code. Sometimes there are more lists as well. These are purely program lists, and have no direct 'handler' links to hardware. These only show up from sequences like PUSHW [R92+xxxx]; RET; and R30 = R92+xxxx; PUSHW [R30]; RET; and similar.

In some of the older ones, I've also seen a shift setup, where each bit represents a sensor, and code does a set of bit twiddles to get the offset for the subroutine/vector list.
So you have to try to get the base address of each list from the original indexed instructions, and it's not always obvious where the end of the list is.

My original intent was "to do as much as correctly possible", even if it did leave holes, but this gets a bit hazy too !!
I'll keep trying out ideas though, it's good for brain exercises !!
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: SAD (disassembler) - Update

Post by ender11 » Thu Nov 26, 2015 2:39 pm

why don't do some text-format signatures file? or even perl or lua script, which is for finding signatures, so it can be updated outside the SAD? a bunch of perl script files.
there must be finite number of tricks. at least, they will not add more, I think.

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

Re: SAD (disassembler) - Update

Post by jsa » Thu Nov 26, 2015 9:19 pm

That is part of what i had in mind for a DB.

Have an entry for each address as well.
Fields for solved, unsolved, referenced, referenced by, PSW interaction, stack interaction, PC interaction, what recognised sub-routine, branch dependancy and so on.
Cheers

John

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

svt4cobra6
Gear Head
Posts: 32
Joined: Mon Sep 21, 2015 11:31 pm

Re: SAD (disassembler) - Update

Post by svt4cobra6 » Sat Feb 13, 2016 12:11 am

I have found while tuning the write ups on this site are great but I really have to guess exactly what the code is doing. So one option is to use an in circuit debugger which would allow you to run the code on the chip with all the hardware inputs and outputs stop at any line of code and look at variables and so on (this would be assembly or C language so you can see what is regulating the air fuel (what equations) for example). Talking with Clint he mentioned there is not a way to do this as the ECM is not in debug mode. A second option which might be what this thread is related to is to use a software simulator. In both cases you would need the actual code that is running on the chip, possibly assembly language or C? With the software simulator you run the hole thing on a computer pc or laptop, and can stop at any line of code and look at parameter values. The difficulty with this is you also need to simulate hardware inputs and outputs that the ECM interfaces with. For the example the ECM may wait for a signal before continuing execution, like a temperature (which is probably a digital voltage level, value 00000001 may be min value and 11111111 may be max value depending on the word size used by the ECM). Anyhow at least for me there is a lot of trail and error in tuning since I do not know exactly what the ECM is doing, but would be totally lost without the write ups here.

decipha

Re: SAD (disassembler) - Update

Post by decipha » Wed Jan 04, 2017 1:57 pm

Hey Andy any updates?

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

Re: SAD (disassembler) - Update

Post by tvrfan » Sat Jan 21, 2017 4:13 pm

I took on a real database job for a fixed term, and away from home, so have been really busy.
Good money, but otherwise .....only saw this today.

Have done a little work now and then, still trying out ideas on bast way to handle data structures, subroutine parameters, etc. automatically.
Got a couple of 'data analysis' tricks working quite well.
Have also been reviewing bugs etc and how to fix them.

Have a far neater way of mapping multi banks, which should stop any bugs around jumps etc.

But need some more time before releasing a test version for you to play with !
Also, doing this work on Linux as a command line program, so need to rebuild it for Windows users.
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD (disassembler) - Update

Post by tvrfan » Sat Jan 21, 2017 4:29 pm

By the way, referring above to Cgrey's posting, here is an example A9L vector list from SAD analysis with no commands

Code: Select all

717e: e0,7b                 vect  7be0,           Sub78
7180: 65,6f                 vect  6f65,           Sub40                             # clr STO, Hard Fault, ACT, ECT, TP, TPS ?
7182: 84,7c                 vect  7c84,           Sub79                             # high RPM test (If Engine Running)
7184: a3,7c                 vect  7ca3,           Sub80
7186: c9,7c                 vect  7cc9,           Sub81
7188: e5,7c                 vect  7ce5,           Sub82
718a: 11,7d                 vect  7d11,           Sub83
718c: 4a,7d                 vect  7d4a,           Sub84
718e: 68,7d                 vect  7d68,           Sub85
7190: 91,7d                 vect  7d91,           Sub86
7192: aa,7d                 vect  7daa,           Sub87
7194: 85,80                 vect  8085,           Sub102
7196: 5a,90                 word  905a,           Dnppm                             # PARAM  - for proc 8085
7198: 4c,7e                 vect  7e4c,           Sub90
719a: 8f,7e                 vect  7e8f,           Sub91
719c: 15,7f                 vect  7f15,           Sub92
719e: 24,7f                 vect  7f24,           Sub93
71a0: 37,7f                 vect  7f37,           Sub94
71a2: 55,7f                 vect  7f55,           Sub95
71a4: 62,7f                 vect  7f62,           Sub96
71a6: 7f,7f                 vect  7f7f,           Sub97
71a8: b1,7f                 vect  7fb1,           Sub98
71aa: c8,7f                 vect  7fc8,           Sub99
71ac: 83,6f                 vect  6f83,           Sub44                             # dump out all 342 stack error codes to ?
71ae: a6,80                 vect  80a6,           Sub104
71b0: c4,80                 vect  80c4,           Sub105
71b2: f2,80                 vect  80f2,           Sub106
71b4: fe,80                 vect  80fe,           Sub107
71b6: 21,81                 vect  8121,           Sub108
71b8: 2d,81                 vect  812d,           Sub109
71ba: 77,81                 vect  8177,           Sub110
71bc: 8a,81                 vect  818a,           Sub111
71be: ba,81                 vect  81ba,           Sub112
71c0: 34,84                 vect  8434,           Sub120                            # in all three Tables at end
71c2: 79,80                 vect  8079,           Sub100                            # clr 1CA timer, incr R38 self test index, set bit flag and return
71c4: 83,6f                 vect  6f83,           Sub44                             # dump out all 342 stack error codes to ?
71c6: 34,84                 vect  8434,           Sub120                            # in all three Tables at end
# Diagnostic proc Table C
71c8: 92,72                 vect  7292,           Sub58                             # STO off and output to low, zero VIP timer, incr R38 test index
71ca: f4,71                 vect  71f4,           Sub53                             # tweak flags
71cc: ff,71                 vect  71ff,           Sub55                             # SCCS something
71ce: 73,72                 vect  7273,           Sub56
71d0: 79,80                 vect  8079,           Sub100                            # clr 1CA timer, incr R38 self test index, set bit flag and return
71d2: 83,6f                 vect  6f83,           Sub44                             # dump out all 342 stack error codes to ?
71d4: 34,84                 vect  8434,           Sub120                            # in all three Tables at end
# Diagnostic proc Table D
71d6: 92,72                 vect  7292,           Sub58                             # STO off and output to low, zero VIP timer, incr R38 test index
71d8: fa,71                 vect  71fa,           Sub54
71da: 7e,80                 vect  807e,           Sub101
71dc: 69,91                 word  9169,                                             # PARAM - for proc 807e
71de: a6,72                 vect  72a6,           Sub60
71e0: cc,72                 vect  72cc,           Sub61
71e2: 7e,80                 vect  807e,           Sub101
71e4: 6a,91                 word  916a,                                             # PARAM - for proc 807e
71e6: d6,72                 vect  72d6,           Sub62
71e8: dc,72                 vect  72dc,           Sub63
71ea: 00,73                 vect  7300,           Sub64
71ec: 04,73                 vect  7304,           Sub65                             # HEGO - A/F ratio test?
71ee: 79,80                 vect  8079,           Sub100                            # clr 1CA timer, incr R38 self test index, set bit flag and return
71f0: 83,6f                 vect  6f83,           Sub44                             # dump out all 342 stack error codes to ?
71f2: 34,84                 vect  8434,           Sub120           

Note that subroutine 807e called at 71da and 71e2 actually uses the next entry in the vector list as a frigging DATA POINTER !!
The code in 807e confirms this trickery, so is doable by human brain, but very hard to spot with a dumb program. SAD only works right in the above because it keeps track
of where the main data areas are, so it can decide that's not a code (subroutine) pointer.
In many A9L listings around, these have a comment "Huh?" or "Dodgy Address?" next to them, showing that many others were not able to sort this out either.
(worse, that pointer, eg 9169 is actually one of the "encoded' type address pointers, as used by subroutine at 3695, making the whole thing even more difficult to crack...)
This is a real life example of a nasty 'gotcha' .

I've given up trying to do this with 'hard' logic and gone for a 'fuzzy' type technique by 'scoring' things - which actually seems to work better overall.

I've seen enough now to know a lot more about how the multibank swops and address references actually work, so that code makes sense to me now.....including the equivalent
and more complex subroutine parameter extraction across banks...
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

decipha

Re: SAD (disassembler) - Update

Post by decipha » Sat Jan 21, 2017 10:23 pm

the biggest problem i have with sad right now is that is mistakenly names values where it shouldn

for example, if i do

sym 1 8c8d "FRP_DeltaP_Target"

anywhere in the code 8c8d is referenced it uses that even in the middle of an ad3w opcode where its just to a value and not that parameter

when i get to my laptop i can post a screen shot

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

Re: SAD (disassembler) - Update

Post by tvrfan » Sun Jan 22, 2017 10:05 pm

Yes, not very surprised. The problem is how to tell when it's an address, and when it's not. That can be hard.

You could start by saying that immediate values are never symbols, but many binaries use an immediate to a register for RAM addresses/structures.

Code: Select all

a1,9b,76,38           ldw   R38,769b        R38 = Table2; 
and may pass this to a subroutine.

AD3W is a bit of a problem. some binaries use this as a start+reqd field in a structure -
an indexed LDW is pretty much the same as an AD3W (e.g. R30 = STRUCT3+56; can be done either way)

Code: Select all

340a: 47,01,08,24,3a,3e     ad3w  R3e,R3a,[R0+2408] R3e = R3a + VAF_Trim;  
so that is correct, but for something like this

Code: Select all

    ad3w  Re,R6,3123         HSO_TIME = IO_TIMER + 3123;    
SAD will attempt to find symbol names for all 3 addresses (e,6,3123)

If it's for a 'base' register (typically rf0-rfe) it works correctly to calc address (eg. from A9L) if it is set by command, or detected.

Code: Select all

  ad3w  R5a,Rf4,1e3     R5a = 91b9;  
  ad3w  R32,Rf0,186     R32 = Eftrffl;         
I had wondered if I should add an extra like 'C' code and add a '&' , which means "the address of", so above example would change to R38 = &Table2; and R32 = &Eftrffl; where it was an immediate value, but I'm still not sure it works any better overall for understanding. (although it's probably more correct)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

decipha

Re: SAD (disassembler) - Update

Post by decipha » Wed Jan 25, 2017 11:54 pm

From now on I'll pay more attention when it occurs and see if I can come up with something more concrete as to automatically determining when it is or isnt a reference

one thing thats really is an issue is 3 digit ram addresses, those get mistakened all the time

one thing off the top of my head, no two SYMs can ever occur within a single opcode, an rbase yes but two SYMs no, that would resolve most of the issues I have

another request, instead of naming tables functions and routines in a numbered order can you name them their actual address? for example, instead of func12, func8_feda for bank 8 routine at addy FEDA would be a significant help

also when SYMs are resolved the actual address is substitued for the sym name, that creates a bunch of manual calculation when that SYM is incorrectly referenced and you need to determine the address being calculated

another issue ive found is that filler cannot be assigned to anything other than FF, which some stock bins have 0F as filler and it muddies up the listing

xcode and code does not seem to work for large blocks of data either

another thing that would make it easier, if you had SAD automatically run all subr commands as code commands, in my dir file i always have to put subr xxxx then i have to put code xxxx cause SAD doesnt run it unless told to

i have yet one last request, if you can have SAD kick out the routines funcs bytes words tables etc.. in chronological order in the msg file for copying to the dir file it would be a benefit to all, i always keep the addresses in order in my dir file so i cant accidentally fat finger something or assign the same address more than once, it prevents errors on my part at last for me it does

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

Re: SAD (disassembler) - Update

Post by sailorbob » Thu Jan 26, 2017 10:11 am

Are you sure you are seeing 0x0F as filler? 0x0F is the normalise instruction so I doubt it is being used as filler. Could it be that the 0x0F is the product of trying to read an address that physically does not exist in the eec? Trying to that will get you odd values.

decipha

Re: SAD (disassembler) - Update

Post by decipha » Thu Jan 26, 2017 11:03 am

Im pretty sure its the null filler henry tossed in there, iirc ive seen it at the tail end of bank 8 and 9, i always ignore ram on bank1 so although it could have been there i doubt it

even in the single bank bins like d3d? and a9l etc... youll see other than FF filler at the end

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

Re: SAD (disassembler) - Update

Post by sailorbob » Thu Jan 26, 2017 11:26 am

The GUF* rom is only 32k in size so any attempt to read beyond that gives garbage.

decipha

Re: SAD (disassembler) - Update

Post by decipha » Thu Jan 26, 2017 11:45 am

rly? so 0000-9FFF is the only accessible memory?

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

Re: SAD (disassembler) - Update

Post by sailorbob » Thu Jan 26, 2017 12:10 pm

There's less than 40k of valid addresses in the GUFx eec-iv as the first 8k is not all used by ram and kam.

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

Re: SAD (disassembler) - Update

Post by tvrfan » Thu Jan 26, 2017 3:06 pm

I've not seen a binary which has 0xF as filler, they all seem to have 0xff (NOP), which makes sense to me. Some binaries have 0xff at front as well....
I'm not saying it won't happen though. I've only really worked with the binary files, not any readers, so I don't know what would happen when reading invalid addresses.

NAMES - Good point there, I didn't spot what I had done in the code.
There is at the moment no way to switch off table or function naming, and it should be there as an option ....

You can switch off all the psuedo source code, and 'goto' labels, and some of the subroutine naming but I completely missed the symbol naming.

OK - I'll include options to stop the autonaming of various symbols - - - hat tip to Decipha on this one.


Also you should be able to specify start and end with the bank command, even for a single bank binary, but I admit I don't think I tested this very much......

I did try to auto compute the eec checksum to calculate the end of bank, but Ford seemed to change the algorithm they use so I don't get consistent results (or it could be a bug I haven't spotted)
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

decipha

Re: SAD (disassembler) - Update

Post by decipha » Thu Jan 26, 2017 9:04 pm

i know of two different stops for the checksum on 4 banks, what i call the old and the new stop address

heres the actual checksum routine all commented out from fbfg2 http://forum.efidynotuning.com/viewtopi ... =30&t=1375

and more details on checksums in my disassembly write up
http://efidynotuning.com/dis.htm#checksum

decipha

Re: SAD (disassembler) - Update

Post by decipha » Thu Jan 26, 2017 9:10 pm

also if u want SAD to automatically determine the bank order on eec-v i have a set of rules that applies to all eecV at the top of the disassembly write up

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

Re: SAD (disassembler) - Update

Post by tvrfan » Thu Jan 26, 2017 11:40 pm

Decipha,

Sorry, just spotted above -

All SAD versions should print out an ordered commands listing at the end of the <name_wrn.txt> file, so you can cut and paste (and edit) into a <name.dir> file. (e.g. A9L_wrn.txt for A9L)
This should be directly readable back in....

Banks and checksums links - interesting...
I've done banks by -
1) finding the first jump (0x2000) and checking if it's a loopback or a real jump. The real jump is bank 8. Then it's a bit of guesswork, as I have seen binaries ordered 0,1,8,9 0,1,9,8 and 8,9,0,1
around. I intend to also check the interrupt vectors as well, to see if I can get a better automated fit. Latest version being worked on will ALWAYS print in order 0,1,8,9 so that the comments file can be straight address ordered (in 5 hex digits). Also in multibanks I have decided to always print addresses in 5 digits (i.e. bank+address), as it's simply easier to read that way.
Internally single banks are treated as a single bank 8, so the same code is used.

I have also changed the BANK instruction to look like a prefix as that's the way the Ford handbook shows it.

I run backwards from file end /bank end whilst bytes are 0xff and assume that's fill - not sorted out the Ford Copyright text message yet....

It occurs to me if the banks are wrong then seeing a BANK 0 when you are in Bank 0 is a trigger that it must be WRONG.... but it don't help much...
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler

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

Re: SAD (disassembler) - Update

Post by jsa » Fri Jan 27, 2017 6:07 am

sailorbob wrote:The GUF* rom is only 32k in size so any attempt to read beyond that gives garbage.

8763 ROM chip?

2000-9fff ?
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) - Update

Post by sailorbob » Fri Jan 27, 2017 10:50 am

@jsa, probably.

decipha

Re: SAD (disassembler) - Update

Post by decipha » Mon Jun 26, 2017 5:25 am

hey andy any update on SAD? I'm currently using the June-10-2013 version of SAD as I could never get any of the newer version to work

if you have something more up to date that would be excellent

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

Re: SAD (disassembler) - Update

Post by jsa » Wed Dec 13, 2017 2:56 am

Hello Andy,

You still working on SAD?

Issue with Rbase addresses by AD3W

This

Code: Select all

b1cb: 45,41,00,f6,30    ad3w  R30,Rf6,41     R30 = cf75

Should look like

Code: Select all

b1cb: 45,41,00,f6,30    ad3w  R30,Rf6,41     R30 = [cf75]

and resolve to a defined symbol
SYM cf75 "SomeSym"

Code: Select all

b1cb: 45,41,00,f6,30    ad3w  R30,Rf6,41     R30 = SomeSym
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) - Update

Post by sailorbob » Wed Dec 13, 2017 3:32 am

jsa wrote:
Wed Dec 13, 2017 2:56 am
This

Code: Select all

b1cb: 45,41,00,f6,30    ad3w  R30,Rf6,41     R30 = cf75
This is correct, register 0x30 will hold the result of the sum of the value held in register 0xF6 and the value 0x0041.

Post Reply

Who is online

Users browsing this forum: No registered users and 0 guests