[mpaton]

I'm interested in seeing who here is actually disassembling code, and what they're using it for.

I know who some of you are, and I understand the mindset that doesn't really want to share all that hard won knowledge. Disassembling is a huge amount of work, and I've always regretted that people think it's easy, and there's so little discussion of it.

But occasionally I see people come on here and ask interesting questions. And sometimes I wonder who is doing it to sell def files (besides sailorbob :-))

And I'm asking because as I see the interest in Andy's SAD disassembler, I'm wondering who's using Bill Lawrence's one. I used it and ended up enhancing it considerably. However although you can do a lot more with mine than with the version Bill made, it's still just as much work to use. It doesn't have the same automatic goals as Andy's.

I was considering making it more production quality, as a 32 bit Linux binary. Yes, I do think that's where serious disassemblers live, even if they are running on VirtualBox on Windows :-)

But I'm frankly not sure who's using the Lawrence one, and if one didn't find that at least usable, one wouldn't like mine.

Just pondering.............

[sailorbob]

I'm obviously one who's disassembled various codes Although most of my disassemblies have not been done to create definition files and I have far more partial disassemblies then complete(ish) ones that have been done to help answer questions that have been put to me by others.

Getting a 'clean' listing is the relative easy part. It's the adding of labels and decoding of addresses etc to make the listing understandable that's where a good disassembler makes itself a very, very useful tool.

[decipha]

I dabble in it a bit, I've done some extensive disassembly on the 04 stang FBFG2 strategy to make my own xdf and adx for tunerpro. It all works well but not to my standard. I don't intend on selling it though, when I'm to a point where I'm 'done' I'll publicly release it free of charge. It seems like I just can't devote enough time to finish it up though every time I try something always comes up.

mpaton, if you want to give my disassembly write up a good double over and see if anything is conflicting please do so, I've tried to trick others into doing disassembly as well lol.

http://info.efidynotuning.com/dis.htm

[jsa]

Got started because logging was not working for the GHAJ0 def.

Tinkering here for now, to better understand GHAJ0.

I am cheating a bit because I can compare with sailorbob's def. Could use gufb to look at, but I have a GHAJ0 car providing the motivation.

Continuing because I can see more parameters can be added to the logging and i imagine some custom code in future.

I agree it's a lot of work and I have nothing but respect for those who have nutted it out the hard way.

SAD produced a pretty good listing, so I haven't tried Bill's or others.

I am a pretender as I'm on Windows.

Of course we'd all be grateful for an enhanced version of Bill's disassembler or SAD or anything else that makes understanding the code less tedious.

The bar to getting started on disassembly is pretty high to anyone without programming knowledge. As someone who has strung a bit of LISP together, 8061 disassembly is a steep curve. Thanks to tvrfan and SAD, it is a lot easier to get a start. It would be unfair to forget all the work and information provided by yourself and many others, but SAD was the tipping point to understanding enough for me.

[ironmanisanemic]

I have zero programming experience, and decided i wanted to get into ford dissasembly. I've been reading all i can and dissasembling bins that have free defs so i can use the def as a reference as to what is what. For me the hard part is being able to look as a block of code and understand what its doing. Im still trying to figure out what all is going on in the MAF code that is in Deciphas writeup. I think for a complete beginner like myself getting a basic understanding how to interpret what the code is doing is half the battle. I think deciphas write up does a good job at outlining some of the basics, but having more examples of common code would be helpful, as well as breaking some of them down line by line to explain what is going on. To me most of the opcodes are very cryptic and even though i have a copy of the EEC pocket reference guide, the descriptions of most of the opcodes make things more confusing. Ultimately i would love to be able to develop my own defs to close the vast chasm in supported strategies. While i never be as good as decipha or sailorbob, at least having workable defs for more vehicles might cause more people to pick up the torch and expand upon them. I see in the GM side back with the OBD 1 stuff there is a huge amount of support, whatever vehicle you have there is probably a def for it, and if there isnt there is someone who can walk you through developing one. I believe something to that extend needs to happen with ford. While we have quite a bit of support for the common stuff, some of the not so common stuff has been left to the way side.

[tvrfan]

I started mine (SAD) because I wanted to see what code was in my EEC-IV box, and it grew from there. Little did I know how complex some of the coding is.

I've had a whole career in IT, starting with coding of custom systems, and moving on from there to do things like database design. On the way I actually managed to debug a few problems in a proprietary operating system, and helped others with code techniques, amongst many other things, and moved through to UNIX and 'C' on various hardware. I've seen some terrible code, and some REALLY clever stuff too. Sometimes the clever stuff is worse to debug, as it can hide some subtle errors.

After a pause, I'm back trying to release the next version of my disassembler, with a big rewrite to make its own code easier to debug.

There are some quite advanced code tricks in some of the boxes, which makes an automatic disassembler HARD. Even in the A9L box for example, there is a subroutine which gets data parameters
from a grandcaller (i.e. two subroutines up the call chain) by fiddling with the stack. Sure, lots of code uses stack for calls and data, but getting stuff on behalf of another subroutine is definitely 'advanced' coding in my book. Detecting this with another program is a challenge....but it keeps your brain active, that's for sure.

Having only incomplete data on the 8061/5 didn't help either - that's not so bad now, a lot of info has been collected. There are still a few question marks here and there though.

I'm not protective in the classic sense "it's MY work !! Bugger off !!" but more of the "will someone misuse this and make a complete mess of it, or worse, mess up someone's vehicle ..." and the
"will someone claim it as theirs..." concerns.

I wouldn't immediately say no to someone wanting my code to see how I did it (with the added bonus of code which doesn't work here and there!) so if you want a copy of a previous version for 'proper' reasons , I might say yes....

It's all written in 'C', and you would need a good understanding of the language as I do use pointer structures quite a lot, but other than that, it's not anything wonderfully elegant or anything, and it still doesn't work as well as I would like. I am still using a really old Borland C compiler, because the graphics are really simple - has anyone here got a link to a good Xwin basic guide ? I could then make a Linux/Unix version.....

[tvrfan]

.... I was considering making it more production quality, as a 32 bit Linux binary......

I think a good, stable, manual version would be excellent idea, and if it can be done with simple command structure and comments, it should do well.

if you can have it handle the standardised def files, then even better !

Andy.

[decipha]

x2, I think an even better idea would be to have the disassembler recognize the more common routines and automatically make it label them with the correct PID names, that would be simple to do but time consuming to code out

or even if you could feed it your actual xdf file to use for comments and directive that would be even better

[tvrfan]

x2, I think an even better idea would be to have the disassembler recognize the more common routines and automatically make it label them with the correct PID names, that would be simple to do but time consuming to code out
or even if you could feed it your actual xdf file to use for comments and directive that would be even better

Been there, done that, FAILED !!

Problem is that there are subtle differences - for example, one BIN will use say bits 6 and 7 to flag whether a func lookup is signed or not (in and out), and another will use bits 1 and 2.
same for tables, and one bin I've seen uses the carry flag to indicate signed. Some bins also have a SCALED lookup as well. Later multibanks often have both an embedded address lookup and a register based one.

This means you have to come up with a sort of 'core' code recognition system, which has to have some flexibility in its matching and it gets very complicated quickly.
I can say I've got what I call a 'signature' recognition system, which is how SAD picks up the function and table lookup subroutines, and then extracts the address of the function or table via that subroutine's parameters, and several around the embedded parameters. THEN you need an alternate set for multibanks, as they have to do more to keep track of the bank, and use a totally different stack access trick. I think I can say SAD mostly works....it seems to get most of the funcs and tables.

This is why I've constantly had in the back of my mind whether an emulation technique might be better, but then that raises a whole other set of issues.....

I don't want to sound like i'm knocking the idea, more that it's actually quite tough to do.... Ideas welcome !!

[decipha]

well to be honest its really not needed would just make it faster for the more lazy

I'd try to get it cadillacin' and call it done

i tried the rbase 1 and it didn't work, didn't set any faults but still wouldn't resolve them

[tvrfan]

.... i tried the rbase 1 and it didn't work, didn't set any faults but still wouldn't resolve them

Which binary are you working on ? (sorry, you probably told me, but I forgot...) I'll have a look with the new version of SAD and see what happens.

[decipha]

fbfg2, its an 04 mustang strategy, I use it on all the 99-04 mustangs and f150s I tune, I have attached my current 87 octane tune that I have on my 2001 Harley F150

[ironmanisanemic]

I'm not protective in the classic sense "it's MY work !! Bugger off !!" but more of the "will someone misuse this and make a complete mess of it, or worse, mess up someone's vehicle ..." and the
"will someone claim it as theirs..." concerns.

I wouldn't immediately say no to someone wanting my code to see how I did it (with the added bonus of code which doesn't work here and there!) so if you want a copy of a previous version for 'proper' reasons , I might say yes....

It's all written in 'C', and you would need a good understanding of the language as I do use pointer structures quite a lot, but other than that, it's not anything wonderfully elegant or anything, and it still doesn't work as well as I would like. I am still using a really old Borland C compiler, because the graphics are really simple - has anyone here got a link to a good Xwin basic guide ? I could then make a Linux/Unix version.....

One thing i think that you could do is release the code under a GNU GPL License on sourceforge or GIT. That way people can help develop the code, and you can still maintain a tight leash on it. Also, having it on sourceforge/GIT will allow others to port the software over to U/Lnix so it would be a truely universal piece of software.

[decipha]

no need, the only fools doing 806x disassembly are us, the rest of the world moved on many moons ago. Im sure if someone were to try to mass market it their efforts would be wasted. There just isnt enough interest in these old boxes these days. Just think, the old bill lawrence disassembler has been open source since the 90s when these boxes were still relevant and no one has attempted to steal his work.

I think SAD is excellent and works great. IIs more than useable in its current state and Andy updating it is just a bonus IMO. Personally, I'm very comfortable working in C/C++ so it suits me perfectly.

But to get back on topic. I think the biggest hindrance for those that want to get into disassembly is the initial steps needed to get started. It seems as though no one ever shares their work which is understandable but makes it that much more difficult for those that want to dive in but cant due to information needed but not readily available.

[tvrfan]

Decipha - All good points there. I wanted someone with only slight knowledge to be able to use SAD and get enough back to get them hooked - and also get the data parts out as much as possible, because that's where the 'tune' is. Well, that was the idea anyway. I did already know that in real life, you still need to be able to interpret that data to make complete sense out of it.

Where I started, on my humble 'AA' box, it's easy to decode, it's open loop, no feedback sensors, no adaptive algorithms, so it's probably the nearest electronic equivalent of the old carb and dizzy with springs. I would still recommend it to a newbie for that reason - it's simple and 'easy' to understand. [relatively speaking]

But then even the old A9L has a lot of sneaky tricks which make it hard to deal with. Not only does it have the 'caller/grandcaller' parameter extraction tricks, but it also has DATA in a SUBROUTINE LIST ! For f*cks sake, who the HELL does THAT in a structured program ??? If it was source code reviewed in my day it would get rejected immediately !! (I sound like an old codger there - I guess I probably am !) It also has JMPs to subroutines as well as /instead of CALL, and one of those is a parameter extractor....... I call that BAD CODE ! This is what makes me wonder if it was patched afterwards to fix bugs.

It also has quite an advanced data structure setup for its injection, with embedded subroutine addresses to call, which it copies to RAM so it can be modded on the fly for timing adjustment. That bit I understand in my head, from a 'C' background, but I'm still struggling to work out how to detect it with another program.....

After what you said, I will seriously consider making SAD open source, I guess it's very specialist for the general tuner, but useful for geeks. I must clean up the code first though ....

[decipha]

no need in making it open source, I'd much rather tell you my problems and let you deal with them rather than me having to go figure it out on my own

don't do me like that

[jsa]

I wanted someone with only slight knowledge to be able to use SAD and get enough back to get them hooked

Seems to have worked at least once !

don't do me like that

You know you want it

[ender11]

I must clean up the code first though ....

that's engeneer! are you worrying about licensing stuff? having your program in a svn system available with a reference to "openbsd licence" in each source file is nothing better than just attach it in the forum thread.
as you said, only a few can use the sources. what just I said? only a few can use diassembler, consider a number of people who can compile it.

[ender11]

folks, I bought an eec-v box to have fun with it this summer.
and I could extract firmware from it via j3 port using a modified "son of eecsucka" device. how it is modified? it doesn's contains any integrated circuits anymore, just two connectors and a bunch of resistors.
anybody interested?

[jsa]

Always interested in neat ways of doing things, post it up please.

[tvrfan]

In a fit of generosity and madness, here is a zip of the source code of SAD as released March 2013 from my backup archive. That may seem old, but it's not really, as I spent some time out after that.

This is all the files you need to compile in Borland C++ version 3. Yes, it's VERY old, but it was a free give-away version from a long time ago, and it still happily works on Win XP
I currently compile in a VM under Linux with Virtualbox.

Notes -

It is split deliberately, with an eye on UNIX/Linux compiles - the main modules are core.cpp and sign.cpp which do the main work (core does the decoding, and sign does the 'signature' recognition).
Distest and distest1 are the graphics and 'shell' module for Windows to call the dialogs.

Core and sign contain no win or graphics stuff, and are actually all 'C' (but Borland libs insist it's all C++ for naming). They make calls out to distest to do all display and file selection, so they should compile and work in Linux, as long as you put an outside interface module with them - I had a Linux version running for a while, but can't find the interface module (it's pretty simple to write though), and it can be basic command line - all Core needs are the filenames to work.

Enjoy, and please if you do re-use the code, at least acknowledge where you got it.....Thanks.
Don't spend too long on the code, it's bad for your eyes.....

[ender11]

I compiled it with builider 6 (two staples required), but it works somehow wrong: acts like SAD.exe file posted here. maybe, it looks for old name directives file? I will take a look.
or maybe some hex/dec issue? have no time...

[tvrfan]

Er...possible ideas. I have had this kind of thing happen before when moving between platforms/OSes/compilers with 'C' and 'C++'

A a type size difference - I haven't built that code under a 64 bit Unix platform for example....
Bit or byte ordering or structure item ordering - I did try to make the binfile getword type functions independent of local order so it's always right for 8061, it happens to be same as Pentium, but I may well have messed that up somewhere.
I do 'cheat' here and there with pointer structures. (ie overlay one on top of another when first few items are the same, it's a bit dangerous).

If, it's in filenames, could be the double byte international char set thing - I don't think std 'C' can handle that without extra string definition and lib types (AnsiString ?? something like that anyway),
so my subroutines probably won't work if you feed them a modern double byte string - there should be a conversion to 'C' (char *) in your compiler/library ?

Built with BorlandC++ Builder 3, which is 32 bit Windows and API. Its type sizes are (bytes) - char =1, short=2, int=4, long=4, float=4, double=8 (float), size_t=4 (size_t is the generic size typedef).

[ender11]

well, that was not about compiler. facts, there exists "borland bla-bla 3.0 builder" and "borland c++ 3.1 bla-bla". "builder" suits, another is not.
builder 3.0 and builder 6.0 compiled distest1.exe produces identical listings.
the problem was the line in the _dir file:

Code: Select all

sub 7e56 "Check_Console"

with _dir file containing only this single line, tables are not working. I mean, the program finds UTabLU() routine, I can see UTabLU() is called in code, but no TableXX references are made.
second problem is following directives are not working:

Code: Select all

sub 63c2 "someTabLU"   : F 2 38 -10
sub 63e0 "someTabLU"   : F 2 38 -10

what I see in _msg file:

Code: Select all

sub  63c2  "someTabLU"   : F 2 38 fffffff6 
sub  63e0  "someTabLU"   : F 2 38 fffffff6 

and no TableXX references. instead, I see "Word" in listing at address, where table begins.

[ender11]

I couldn't set "Z" option from _dir file, so I added it to default options...

then, tables are broken:

Code: Select all

52c0: a0,38,32          ldw   R32,R38        R32 = R38;
52c3: 45,66,03,f8,38    ad3w  R38,Rf8,366    R38 = Table19;
52c8: ad,0a,34          ldzbw R34,a          R34 = (uns)a;
52cb: ef,24,e3          call  35f2           UTabLU();

clearly 10 column table

Code: Select all

   Table19:
9876: 30,30,30,20,20,20,00,00,00,00,20  table  48, 48, 48, 32, 32, 32,  0,  0,  0,  0, 32
9881: 20,20,20,20,20,00,00,00,00,20,20  table  32, 32, 32, 32, 32,  0,  0,  0,  0, 32, 32
988c: 20,20,20,20,00,00,00,00,20,20,20  table  32, 32, 32, 32,  0,  0,  0,  0, 32, 32, 32
9897: 20,20,20,00,00,00,00,20,20,20,20  table  32, 32, 32,  0,  0,  0,  0, 32, 32, 32, 32
98a2: 20,20,00,00,00,00,20,20,20,20,20  table  32, 32,  0,  0,  0,  0, 32, 32, 32, 32, 32
98ad: 20,00,00,00,00,20,20,20,20,20,20  table  32,  0,  0,  0,  0, 32, 32, 32, 32, 32, 32
98b8: 00,00,00,00,20,20,20,20,20,20,00  table   0,  0,  0,  0, 32, 32, 32, 32, 32, 32,  0

becomes 11 column table

Code: Select all

UPD REG (L0) 32 = 38
UPD REG (L0) 38 = 9876
UPD REG (L0) 34 = a
add  (backw) Subr Call depth 0 from 8|52cb to 8|35f2
SUBR type 2 (8|35f2) levs  0 from 8|52cb
TABLE invalid col size. default (11) set
WPARS TABLE add=8|9876, size=b

somehow.

older SAD.exe produces the same result, while newer TSAD.exe doesn't. so, looks like it's already fixed bug?

[mpaton]

So here's some input for discussion. I've attached a binary, which I've called HHX0a.bin

It's an EEC-IV bin from a 1996 F350 with a 351 and a C6. It has many of the things in it that the later EEC-IVs with 3 digit error codes have. It is a later development of the code described in the speed density doc on this site.

If anyone wants to play, please disassemble this using SAD and please somebody also do at least a little bit with the Lawrance disassembler. The Lawrance will be a lot harder work, so that's why I'm only asking for a useful bit, or part of it.

If we get some worthwhile responses using those 2 tools, we can discuss some useful things like:

1 Differences between Andy's disassembler philosophy and mine

2 How to go about disassembly with the Lawrance tool

As a starter for 2 above, in this bin, my own opinion is that the priorities are

first to find out what is code and what is data, by looking for

(i) the subroutine calls with inline arguments.
To get started on these you want to be able to recognize the function lookup code for words and bytes, and the rolav code

(ii) The background dispatch table. Found by finding the code that calls it

(iii) The raminit table. Found the same way

(iv) The ROM data sections, where they start and end

(v) The analog input table

(vi) The HSO table

(vii) The interrupt handlers

(viii) The timer table

(ix) The error code table

(x) The self test vector tables

(xi) The data table for data scanner variables. Yes, OBD1 ECUs with 3 digit codes have these even if A9L doesn't, and they are a great help.

decipha, you can take that list and put it in your advice for disassemblers. Even if SAD or something or someone else finds these things for you, i think one needs to be able to recognize these things. Most of these things, in one form or another are in commonly used binaries. Even if A9L doesn't have item (xi).

If we get some response, then around the endof the week, I'll post some results from my own disassembler, and we can discuss what it does.

Before then, we can discuss my list of advice above if anyone wants to. it's pretty much a given that understanding 90% of 8061 assembly instructions is a requirement. Even though I still have to read the book if I really need to know which way conditional branches go.

One thing I don't have the slightest interest in discussing is anybody's views on how the code ought to have been written, or how they would have written it. It is what it is.

Michael

[tvrfan]

Micheal,

Obviously I'm going to be more in the 'automatic' point of view, but here are some thoughts....
all of which should be argued for or against, this is my input for discussion, and a couple of questions, if you don't mind !

From your list, There are some things which can be included very easily and could potentially help immediately (see notes on how I do it - open for discussion).
These are all either in fixed places, or are easy to detect.

7) Interrupt handlers
6) finding which bank is bank 8 (where code really starts)
5) ROM section sizes
?) finding the BASE registers for much of the ROM data.
3) RAM sizes, from init routine(s).

Then it gets harder, and probably falls out of the scope of a more 'manual' disassembler, but I guess some things could get printed as a warning ? [to be investigated]
I used a 'signature' approach to find following things, this is a kind of 'regular expression' approach, with a pattern match. Some of them don't work as well as I would like, but it's ongoing.

Table lookup
Function lookup
Base register code (links up with above)
Subroutines which mess with the stack (= have parameters)
Subroutines which not only mess with stack, but get parameters on behalf of others (A9L does this quite a bit, and later ones too)
Vector lists (background task, test lists etc)
[ haven't done rolav(s), don't see the need from a code analysis point of view, but agree would be useful for reader - I could add this ]

Note - If you've not heard the term, the 'regular expression' is a very powerful pattern match technique, shared across many UNIX utilities. They look like gibberish much of the time, but once you get the hang of them, they can be amazingly concise and yet flexible and have optional and/or multiple subpatterns within a single main one.

Things I still haven't properly sorted out [automatically]

May be possible to do -

Timer table - the earlier bins seem to have almost the same code, so may be possible to detect
Subroutines with variable parameters (yes, there are some)

Haven't a clue at the moment -

Data Structures, especially with embedded subroutine calls (e.g. HSO table).
Vector lists with data in them (A9L again - has this trick, effectively a vector call to a subr with data param(s) )
Error tables
ODBII data structs and code (Question - are these also pretty regular in layout and code ? if so could be detectable.

See next post for more....

[mpaton]

So i hope others join in, or else a discussion between 2 disassembler writers may get a bit boring.

For the benefit of the others, Andy and I have discussed some of these points in private email between 1 and 2 years ago.

Then we agreed we had different goals; he wanted the intellectual challenge of automatic disassembly. I on the other hand maintained that if you were going to change the code and data to tune something, then you just needed to understand the code, and that having a perfect automatically produced disassembly wouldn't be very useful to some one who still couldn't read 8061 assembly code.

What I wanted to do was to take the repetitive stuff out of it.

So now, I'll comment on the first few points of Andy's post, and then probably a separate reply for later ones.

Michael,

Obviously I'm going to be more in the 'automatic' point of view, but here are some thoughts....
all of which should be argued for or against, this is my input for discussion, and a couple of questions, if you don't mind !

From your list, There are some things which can be included very easily and could potentially help immediately (see notes on how I do it - open for discussion).
These are all either in fixed places, or are easy to detect.

7) Interrupt handlers
6) finding which bank is bank 8 (where code really starts)
5) ROM section sizes
?) finding the BASE registers for much of the ROM data.
3) RAM sizes, from init routine(s).

Me producing this list, is really me responding to decipha's request for an answer to "how do you go about disassembly?".

So all these things are easy to detect, depending on how much code you've actually seen, read and understood. And all of them are gong to be there 99% of the time, in some form or another.

Your item 6 btw, does not come from me, because I've chosen to focus on 8061 code for the moment. It's important, it's interesting, but it's not very hard if you understand the code.

When you, Andy say they help, do you mean help separate code from data, or help understand the code?

Because I think if you make the effort to understand the code, you will understand how it all works, and where the
interesting parts to tune are.

I have no problem with SAD as your intellectual exercise. I have several of these myself. But I'm not at all sure if even perfect disassembly from something like SAD actually helps people to read code and understand how it all works, and build def files.

I think they need to understand more about what's going on in the code, and that may as well be learned in the process of making a dir file.

Then it gets harder, and probably falls out of the scope of a more 'manual' disassembler, but I guess some things could get printed as a warning ? [to be investigated]

Either I don't understand what gets harder, or I don't think it does get harder. I most certainly DON'T think anything falls out of the scope of the manual disassembler, because that's what I use.

Michae

[mpaton]

Michael,
I used a 'signature' approach to find following things, this is a kind of 'regular expression' approach, with a pattern match. Some of them don't work as well as I would like, but it's ongoing.

Table lookup
Function lookup
Base register code (links up with above)
Subroutines which mess with the stack (= have parameters)
Subroutines which not only mess with stack, but get parameters on behalf of others (A9L does this quite a bit, and later ones too)
Vector lists (background task, test lists etc)

All of these are easy for a human to find, but then I've probably disassembled about 200 bins. I suspect sailorbob's done more.
So if it's hard to do automaticaly, is it actually useful to try to do it automatically. Just give the human a way to have the code or data presented in a way that is easier to comprehend. This is a philosophy difference between the 2 of us.

[quote=""tvrfan"][ haven't done rolav(s), don't see the need from a code analysis point of view, but agree would be useful for reader - I could add this ][/quote]

I would submit again that while you're correct that it might not matter to identify rolavs from a SAD point of view, it is very useful if you are trying to match your bin to one of the strategy docs out there. And if you do that, you will develop an understanding of many if not most of the bins out there. And I think that's what is going to benefit people with a bin, and no def file, and the need for one, who think they have the skills to read 8061 code because perhaps they can read 8086 code, or 68020 code.

I don't especially wantto help people who don't want to write a def file, and who give up when they find they need to do that.
I'm happy to help people who want to know HOW to make a def file, but people want simpler solutions that involve less work.

And SAD gives them that, but I don't think it's a net help, because now they have a great assembly file, but probably don't know what a rolav function is. So they can't find the code that makes VS into VSBAR, and then can't find the code that is somewhere close to that, which might be very enlightening.

So I think, as I put in my list, that people should look for these functions like the function and table lookups, the rolavs, the fault filter code, the timer code, the ram init code. All of this is easy to find, and it will ALWAYS be there, perhaps using different registers to pass arguments, but the interpolation code is always going to be there.

What IS a drag is to find these functions that pass parameters inline, and having to concoct a dir file full of

word 2C02
code 2C06
.
.
.
byte 782F
code 7832

all done manually.

So we need a better way to eliminate that drudgery, not so much because it's drudgery, but because humans make errors doing drudgery.

Timer table - the earlier bins seem to have almost the same code, so may be possible to detect

In the friendliest way possible Andy, if you can make this statement, then you haven't been reading enough 8061 code.

I find it simple to detect. it's not even worth automatic detection.
it IS worth formatting the table usefully.
But then this is our philosophical difference, and our different goals.

Subroutines with variable parameters (yes, there are some)

A fine intellectual exercise for the disassembler writer.

But also simple to deal with using the manual disassembler.

Haven't a clue at the moment -

Data Structures, especially with embedded subroutine calls (e.g. HSO table).
Vector lists with data in them (A9L again - has this trick, effectively a vector call to a subr with data param(s) )
Error tables
ODBII data structs and code (Question - are these also pretty regular in layout and code ? if so could be detectable.

You haven't seen enough of these, and/or you haven't wanted to understand what the use of finding them was. :-) :-)
There are several variants, but yes, pretty easy to find, pretty much always there in one of a few forms, and IMO useful to find.

What's needed is not automatic finding, but useful presentation of the embedded data.


May I suggest Andy, that you yourself take on the task of using the Lawrance disassembler on at least part of HHX0*
See if you can find anything interesting about the function tables in it. Something that made me have to get with Clint and have a small change made to BE a few years ago.

Use SAD if you like to get yourself started. But I still want to see some participation from other disassembler users.

Otherwise it will just be a discussion of philosophy, and you and I can do that just as well offline.

Michael

[tvrfan]

Yep, we've discussed this before, from different angles...
Mike, sorry if I wasn't clear......
What I thought I was responding with was what would be good to perhaps include in a 'base' disassembler (I.e. mostly manual directive driven, like the BL one), and when I said 'harder' I meant from the automatic decoding perspective.
From your reply, I now know I've got that wrong -
I now understand you are coming more from "how does a human understand the [base] listing" and "how does a human start with basic listing and then gradually add directives to improve it" along with "how do we eliminate some of the pain ?" Is that right ?

Even with SAD, turning the end listing into something that makes sense to TUNE is still a big jump, especially so for those with limited IT/programming experience.
So actually, we're NOT of different viewpoints at all, and I agree with everything you said. (and no offence ever taken !!)

An idea occurs whilst I was reading you comments about cutting down the drudgery .... but it is about adding functionality (sorry !)

For subroutines, SAD has a directive/command "SUBR" - this would allow all calls to that subr to be covered in one single cmd, along with its params.
(doesn't work for variable pars yet). But it is used for getting table/func addresses as well.....

I also have quite an advanced "DATA" equivalent, which can allow the definition of structures/tables like HSO, as mixes of words, bytes and pointers.
You define one 'entry' and then it will automatically repeat between start and end. At the moment, SAD doesn't have bit fields, but could be done.
This same mechanism can be added to a subroutine to define its params...which is supported in SAD already.
(pointers will optionally be replaced by symbol names etc. in those structs)

Is that the kind of thing ??

(A small dig - Timer struct - well I only have TWO signatures for func lookup (8061, 8065 multibank) does both word and byte, and TWO for table....... I haven't found a binary which doesn't work yet, but I freely admit I only have a collection of about 50 so far.....) Happy for you to send me a weird one !!