[teal95]

CGG2 1997 Escort 2.0 manual trans hardware MLT-212 strat GWAG5
J2W1 1993 Escort 1.9 manual trans

I don't seem to have a bin of the TA with me (and the cars are 600 miles away).

steve

[tvrfan]

Thanks Steve, I'm sure they will be useful, and give me a chance to do more bug finding !

[tvrfan]

OK guys, as promised, here is the disassembler, with instructions. Windows executeable, should be OK on any windows 32 bit (98 onwards). Can put .exe anywhere you like.

Cgrey - put this somewhere else if it makes sense...

NO it's NOT finished, some things still don't work right in automatic mode,
but it should be fine with a few directives for any binary.

I am using the binaries sent, and ones I had already, to try to improve the program, but it's still an ongoing process......

Things which don't work include (and there's probably more)

Tables and functions not picked up where their address is 'encoded' as an offset address.
Tables and functions not always picked up when address is set up as embedded parameter (i.e. on the stack). Works some of the time, not quite figured out why it fails as yet.

Doesn't always get the number of parameters right for subroutines, especially when a subroutine calls another
and both mess with the stack. Again, works for some cases (like A9L), but not for others - I do know why for this one, but it's tricky to fix up.

Enjoy !!

Bug reports are OK to send back - I'm sure I've missed some despite trying to test everything.

[cgrey8]

I'll be curious to learn why it's working for some stack-located offsets and not with others. I would've just assumed if it could do it for one, it could do it anytime this is done. I'm sure there is a difference and I'm sure when you figure it out, you'll be like...DUHH! But until then, it remains a mystery. Perhaps another set of eyes looking at it will see the pattern and get you into the duhh territory.

[decipha]

if only fraser still frequented this forum

[tvrfan]

I'll be curious to learn why it's working for some stack-located offsets and not with others. I would've just assumed if it could do it for one, it could do it anytime this is done. I'm sure there is a difference and I'm sure when you figure it out, you'll be like...DUHH! But until then, it remains a mystery. Perhaps another set of eyes looking at it will see the pattern and get you into the duhh territory.

I'm sure that will be the case... there probably IS a stupid mistake, but I know that it's only in some binaries, and that's the clue.... also I need to sort the encoded addresses used by quite a few binaries which don't work (automatically) either. Currently trying to sort out an issue where params pulled off the stack, and then another subroutine is called which ALSO pulls params of the stack.

Of course tool DOES work with a few well chosen directives.....and the rest in automatic mode.

[tvrfan]

If you get error - "Missing VCL35.bpl" (or similar) when trying to run the disassembler.


This was reported to me today, and I found out that what Borland tell you about how to release a package is actually not complete. Certain libraries are still not included by default, this build should correct that problem. Tested it on a computer which has never seen Borlandc, so here's hoping !!

Have corrected a few bugs too, but not a lot has changed, to be honest other stuff has got in the way....

new file attached....

[tvrfan]

Guys,

Here is an updated version of disassembler which will now recognise encoded function and table addresses, including ones embedded in subroutine call (i.e accessed via 'pop'), and will correctly recognise signed and unsigned functions and tables. Also added variable param subroutines (e.g. EARS binary). I've found 3 different types of address encoding so far....

Made quite a few improvements, several bug fixes, etc. and fixed a couple of crashes.
It also handles 'remote param' type subroutines much more reliably than before.

I've added an updated description of the commands.

Added 8065 interrupt structures, but it won't handle multibank 8065 (yet).
I did this for an Australian single bank 8065 binary, but had to trim file to 56K (ie. like an 8061 format).

I have to add, NO WARRANTY OR LIABILITY accepted, just to cover myself.

cheers,

Andy.



PS> What is a 'remote param' subroutine ?

Subroutines can use registers for parameters (as early code like my AA) or can embed them as data in the ROM code (A9L does this). Embedded pars can be detected by the fact the subroutine does a 'R30 = pop' or similar at the front, which effectively gets its own return address, then does several 'ldb R30++' or similar ops and then 'pushw R30' to push modified return address back, beyond its data.

In several binaries the designers got clever and have a subroutine which does 'R30 = pop' followed by 'R32 = pop' which gets the CALLING subroutine, and local subroutine then gets data from the caller routine.
In fact there could be more than 2 pops to get further back, but I've not seen this (yet).
There's also a type which gets a local param to tell it how many remote params to get (again A9L has one of these). This all requires some detailed tracking of 'what calls what' to get this to work correctly automatically, but it seem to work correctly so far !!

[decipha]

thanks tvr, i've been messing around with it just goofing off, pretty cool little gem

[cgrey8]

I tried disassembling the XDT2.bin file and it resulted in a text file too big to be opened by notepad. I'm not sure if it got bogged into some kind of circular condition or what.

[crakrz]

Can't wait for it handle multibank 8065, that will be awesome. Great work tvrfan.

[tvrfan]

Cgrey,

Yes possibly/probably some kind of wierd loop condition - I wouldn't be surprised.
Disassembler has to loop backwards sometimes for the structure, so I have probably caused a new bug to appear....

Please send or post the binary and I'll have a look at it, armed with the debug tools....


8065 and timer lists next ....

Thanks,

Andy.

[tvrfan]

Got a copy of XDT2 in an old thread (assuming its the right one.....).

This looks like a 2 bank 8065, using a binary editor to view it, with a start at 0xe000, so disassembler won't handle that yet, unless you trimmed the file down (and then would lose half of it).

Did you try trimming the file ?? I'm asking because if you did, I still need to check in case there's a bug for 8061 binaries....

Good bin to keep though, I now have 8061 of various vintages, a couple of single bank 8065 (Australian ones), a 2 bank and a 4 bank 8065.....

So this is my next big target - multibank 8065.

and thanks people for the good feedback !!

Andy.

[cgrey8]

Yes, XDT2 is a 2-bank 8065 tune. I wasn't aware the disassembler wasn't yet ready to handle them. Let me know when you get it working with this. If I do anything with 8065 stuff, it'll be with that tune just because that's what I have an EEC of.

[tvrfan]

APPEAL FOR 8065 INFO ... PLEASE...

Guys,

I have got a multibank disassambler working, but it gets its links messed up sometimes (ie. the subroutine 'tree') and I'm wondering what the BANK SELECT register does (I think this was in a previous thread), but also if the instuction pushf (push flags) also pushes the current bank...

Also it seems to have a different clock timing for IOTimer (8061 is 36 clock ticks, but 8065 appears to be more ?)

That XDT2 binary also uses a new way of fiddling with the stack, so some learning to do there...

All info welcome....

Thanks All.

Andy.

[tvrfan]

Nearly working....

Attached is my latest acheivement on XDT2 (from cgrey8). it's pretty good, but has some bits not analysed correctly. (2 bank 8065)

There appears to be a separate 'switch' for code (via BNK instructions) and data, because I had to force the data analysis bits to always run in bank1, despite where code was. This is why I need more info please... I think the BNK instructions only affect the next jump (or subr call) and leave data accesses unaffected. I think the BANK_SELECT register selects which bank for data reads ??
I also see procs which change banks always do a pushflags and popflags (start and end), so there's something 'bankwise' saved in there too I reckon.

Anyone...???

Andy.
(Cgrey... Enjoy !!)

[cgrey8]

Some areas of the code, you've been able to identify are tables and functions, so you begin labelling those areas as they are identified. However there are some large blocks that are not labelled as tables, but they are listed in blocks like tables are. What are these? And how have you determined how "wide" and "deep" they needed to be?

Also look at Table11 in the XDT2. This appears to actually be more than just 1 table. The pattern of data suggests to me that Table11 ends around 2544. And then a new pattern of numbers appears at 2545 which is possibly another table or at least abandoned data used by other strats, but not referenced in this one. I don't know any of this to be true. I'm just going by instinct. Have I been led astray? I'm just looking for info to help me look at the file and get a feel for what is and what isn't.

[tvrfan]

Default rules are that 'unknown' blocks are printed in sets of 8, except 'fill' (i.e. all 0xff) which are printed in sets of 16. No magic (unfortunately)

The disassembler did not recognise the table or function lookups on this binary (need to investigate the code changes) so I put the specs in manually by directive.

Disassembler attempts to decide where a table ends, but it's not reliable, especially when other bits are missed, so cannot guarantee it's right.

There are definitely some unexplored blocks, and I need to find out why - it looks like there is more to the bank swops for code and data than is commonly discussed. That's my conclusion based on the code that has been decoded, anyway (as per above post). Looking at those blocks, there is both code AND data not covered.

It could be there's a structure with embedded subroutine calls like A9L, which are very tough to sort out....

Need to do more investigation to confirm at this point.

[tvrfan]

MULTIBANK - MULTIBANK - MULTIBANK - MULTIBANK -

Well here it is -------- the multibank disassembler.

Tested on single, double and 4 bank binaries.

No guarantees it works for everything, but looks good.

Still doesn't recognise everything, not perfect, but does get most functions and tables
automatically. Just feed it the binary, then check warning file, then can reuse the commands and go around again as required.

Later binaries have even more complex algorthms to decipher, along with bank swopping
which makes some of this stuff *HARD* to decode in a program...but this does OK overall.

Anyway, have a play and tell me what you think....


Andy.

[tvrfan]

Just a quick note to say that I've found that some 4 bank binaries use a different table lookup mechanism to the single bank one - this means the disassembler will not spot those tables automatically.

Working on this now....

Andy.

[tvrfan]

Guys,

New version of disassembler, more bug fixes and now recognises more data structures automatically.
(just a new exe, other stuff is the same)

It can get quite slow with multibank binaries and lots of symbols, so this new version has quite a lot
of changes to speed up the processing. It's noticeably faster than before.

Andy.

[Howie]

Hi
Thanks for sharing.

I just used your disassembler on a Euro bin file from a 96 EEC5.

Looking at the output files am I right in saying it has picked out some things but has missed most of it.

Here is the bin.

[decipha]

tvrfan... shoot me an email and ill give you a thorough breakdown of a complete 4 bank disassembly byte by byte

i'll do my part to help u out as much as i can

decipha at efidynotuning dot com

[MartyMcSly]

4-bank 8065? That would be an EEC-V?

That's what I'm interested in. I'm looking for some guidance to get started. I can post up a bin but I'm also working to get up to speed to disassemble for myself. I've just ordered the IDA book with a view to checking out what would be involved in writing an 8065 module, but it looks like tvrfan is a lot further down the road already.

[ender11]

ida pro has 80196 module, close to 8061. there 2 opcodes which is different. 80196 module's sources are included in ida pro sdk, so it is easy to modify and recompile it.
well, ida will not recognise _all_ the code -- because it's not accessed by conditional or unconditional jumps, but by list with some stack manipulation.
the same is about data and it's format.
tvrfan said, that all necessary data can be borrowed from .wrn file to upload into ida, but it's kinda complicated when it comes to data tables.

[decipha]

at $2,000 US i can't even give ida another thought

[MartyMcSly]

USD2000??? Not quite. IDA Starter at USD589 includes support for the 8051 and 80196, with source code for the modules. With the AUD above parity I could stretch to that, but it sounds like I wouldn't get any further than tvrfan has, so IDA's on hold for the time being.

[decipha]

thats what it was when i priced a single user license for ida pro, i dont know about the base ida

[cgrey8]

Is there any updates to the Disassembler effort?
Is there an updated version available?
Are there any directive files that have been developed for it to help it disassemble some strategies?

[decipha]

say playa u gotta whip together your own directives