[tvrfan]

My A9L HSO table is ....

sym 22a6 "InjTTab"
struct 22a6 2355 :R N: Y O +3 : Y D 2c5 N: Y O +2 : W : W | R N: Y O +3 : Y D 2c5 N: Y O +2 : W

Which means first entry is word pointer (check for sym name), followed by 3 bytes, followed by offset into 2c5 RAM table, followed by 2 words, then newline (the output half)
then pointer 3 bytes,offset, 2 bytes, one word. Where pointers are subr calls to do ON and OFF for injectors.....
this will auto repeat for the 8 (?) entries.
(I think that's correct, from an old listing)
this gives output like -

Code: Select all

  InjTTab:
22a6: 5a,32,00,16,0a,0f,01,fe,01,00,40,00  struct Sub54,0,16,a,Q1,1,fe,1,40,
22b2: 73,32,00,06,0c,0f,01,fe,01,00        struct Sub55,0,6,c,Q1,1,fe,1
22bc: 5a,32,00,17,0a,1b,02,fd,02,00,80,00  struct Sub54,0,17,a,Q2,2,fd,2,80,
22c8: 73,32,00,07,0c,1b,02,fd,02,00        struct Sub55,0,7,c,Q2,2,fd,2
22d2: 5a,32,00,10,0a,25,04,fb,03,00,01,00  struct Sub54,0,10,a,Q3,4,fb,3,1,
22de: 73,32,00,00,0c,25,04,fb,03,00        struct Sub55,0,0,c,Q3,4,fb,3
22e8: 5a,32,00,11,0a,2f,08,f7,04,00,02,00  struct Sub54,0,11,a,Q4,8,f7,4,2,
22f4: 73,32,00,01,0c,2f,08,f7,04,00        struct Sub55,0,1,c,Q4,8,f7,4
22fe: 5a,32,00,14,0a,39,10,ef,05,00,10,00  struct Sub54,0,14,a,Q5,10,ef,5,10,
230a: 73,32,00,04,0c,39,10,ef,05,00        struct Sub55,0,4,c,Q5,10,ef,5
2314: 5a,32,00,12,0a,43,20,df,06,00,04,00  struct Sub54,0,12,a,Q6,20,df,6,4,
2320: 73,32,00,02,0c,43,20,df,06,00        struct Sub55,0,2,c,Q6,20,df,6
232a: 5a,32,00,13,0a,4d,40,bf,07,00,08,00  struct Sub54,0,13,a,Q7,40,bf,7,8,
2336: 73,32,00,03,0c,4d,40,bf,07,00        struct Sub55,0,3,c,Q7,40,bf,7
2340: 5a,32,00,18,0a,57,80,7f,08,00,00,01  struct Sub54,0,18,a,Q8,80,7f,8,100,
234c: 73,32,00,08,0c,57,80,7f,08,00        struct Sub55,0,8,c,Q8,80,7f,8

Similarly (a9l again)
subr 3654 "Rolav3" : W N O +2: W E 1 e0 N

Which means 3 word params. First 2 word params with names (new AD and filtered value), last par is an offset from Re0 with name (which is the filter coefficient).
This means listing could have the real sym names (makes RPM filter calls REALLY obvious !!)

and gives output like this.....(note last param converted to true address as well)

Code: Select all

3e28: ef,29,f8          call  3654           Srolav3T(RPM_Filt1,Rpmx4,97f4);
3e2b: 08,01,ae,00,4c,d0 #args  

(could still cover varargs with old style CODE , DATA dirs)

Would that kind of thing help ??
I know we disagree on source code display, but perhaps there is a middle ground ??

[cgrey8]

I've been reading and following along, but I just haven't been chiming in since I didn't have anything to add. And I don't find the discussion boring either. So please keep it public.

But you, mpaton, are right on some things like people not knowing what rolavs are. I don't. Did I miss where those were defined earlier?

For others reading this discussion because they want to learn, it might be useful to at least give a quick blurb about what it is. Perhaps they know what it is, just not by that name. It doesn't appear to be a typical programming term, at least nothing that comes up in Google searches. So reading the comments and having the term bantered around without being defined just makes me feel stupid. I'm OK with that because I'm willing to ask the question. But I can see how some people would just give up trying because they didn't want to ask the question.

I also have to admit, I'm not interested in doing disassembly. I had curiosities about it specifically about what it is that makes disassembly so difficult to automate. And once I got a glimpse into that, my curiosity was satisfied. But that doesn't mean I don't still enjoy reading about what others, more informed than me, have to say in hopes that I can pick up something new.

As for the differences in philosophy, I see both sides. One wants disassembly to be easier and automated. The other thinks that a little pain in the disassembly is good for understanding the bin that ultimately will have to be digested, once disassembled, anyway. I can't say which is better. However I would probably personally prefer to automate as much as possible. I'm one of the guys that refused to learn Java writing in notepad. I learned on an IDE and I think I learned more than the others in the class because the IDE informed me of my options and hinted me to things I didn't know where even possible. Notepad could only sit there and wait for my input.

Granted we aren't talking about a high level language here. We are talking VERY low level stuff that requires you have a sufficient understanding of both the hardware the code was written for and the application requirements...many details of which you won't have all the info for and you rely on the code to infer you to...or asking questions of others that have already done that brain-damage. Doing this kind of work reminds me of being given a 1000 piece jigsaw puzzle with 1/2 of the pieces missing, many of the pieces are almost the exact same shape, no front cover to tell you what the picture should look like when done, and even make some of the missing pieces yourself. It takes a special kind of mind to want to venture into a project like that and stay engaged and motivated.

[mpaton]

Rolavs are defined in the available strategy docs.

The point about them for disassembly is that they take parameters (which might mean embedded data in code)

and more importantly, ford's coding style usually places them close by the function lookup and table lookup code.

So if you recognize their code, it helps you with other stuff.

Michael

[cgrey8]

Ahh, so I was right. I understood what they were, I just didn't know them by that name. They are the function and table lookup subroutines. And as you stated, they make use of stack manipulation to access embedded data where under normal circumstances there wouldn't be data...one of the many things that throws disassemblers for a loop.

[mpaton]

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 ?

That's more or less it. I was one of the ones who arrived on these forums with a bin that nobody had a def file for, and a strong desire to tune it. All the usual impractical (change to A9L) suggestions were made to me. You still see people like me arriving today, who may well be able to read 8086 code, and think maybe, with a little help, they make enough of a def file to do something useful.

When I started, there were 2 things that were of enormous help. The first was the patience of sailorbob, who gave me the right amount of help to understand the ford philosophy of table lookup and a few other things.

The second was the availability of the LHBH document. It was much more help than I realized at the time, because it matched my bin almost perfectly.

I got help when I started, and I believe in putting help back. But now I'm a grumpy old guy, and I have no interest in giving away fish. I'm happy to help people learn how to fish.

And I think that those people who want to start from nothing and make themselves a def file need to read all available documents, and make themselves a good disassembly, and UNDERSTAND it.

I believe there is and should be a hurdle to being able to do this stuff. It is, and should be to learn what the 8061 instructions do, and to read a strategy document, and disassemble a bin that matches it.

For those who say they want to make their own def file, I'm really not sure if SAD is helpful or not. And that is because it defers the need for understanding of the code, and makes its user think they're getting somewhere. But they still have work to do.

But it's still a great exercise for Andy, and I'm watching with interest to see how many directives it ends up with.

So I'm considering giving back my own disassembler. But it's not automatic. So I started this thread to see if there are enough people prepared to make directive files on the bin I posted, and if there are, I'll show what my disassembler can do, and along the way, decipha will get some input for his disassembly tutorial, at least.

If people do that, then I'll post my dir file for HHX0 for my disassembler, showing some of its features.
Then we can discuss these and then I'll post the resulting assembly, discuss more and compare to what SAD has, and then I'll show the rest of what it has. If that doesn't happen, so be it.

I put thought into the bin file selection. It's from an ECU I own, and just obscure enough that I doubt anybody is selling a def for it.
It's close enough to a strategy doc to be helpful.

So, first I made a general invitation for someone to do the grunt work on at least a partial disassembly with the BL disassembler.
No takers
Then a specific invite to Andy;
Maybe he's thinking about that, or maybe he's dodged it.
So how about cgreay, decipha, or others that have made contributions in EEC Geeks?

If that doesn't happen, I can stop being noisy here, and just take my discussions offliine, no problem.

Michael

[mpaton]

Ahh, so I was right. I understood what they were, I just didn't know them by that name. They are the function and table lookup subroutines.

Rolavs are not function and table lookup subroutines.

[cgrey8]

Ok now I'm confused again.

[mpaton]

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.

It;s not ever going to be easy, but aside from our own personal intellectual exercises, I think it is the more important goal.

And SAD moves the hurdle, leading to a probably false sense of progress towards that goal.

I wonder if it wouldn't be more useful to examine something like the LHBH doc and find all those things in the bin. That's more or less what I do, although not automatically. But I don't think it's hard for a human to find.

Michael

[mpaton]

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 did wonder the extent to which you would eventually accept the need for directives, at least as an interim measure along the way to the perfect automatic disassembly.

I believe this was the second thing I added to my disassembler.
I started gently, by identifying bit manipulation instructions.

If we get someone to do a partial HHX0 dir file, then I'll get to show you. How about you try that Andy? :-)

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 ??

i think you need that; glad to see you have it. As do I. If we ever get to see that BL disassembly, then maybe we'll get to compare our approaches.

(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 !!

I've seen I think 5.

Michael

[mpaton]

Ok now I'm confused again.

Then you should read about them in the strategy documents.

Michael

[tvrfan]

Mike,

OK, I just need to check - I have an original BL disassembler, but I'm not sure if yours is modded from there. If you have an updated one you want me to use, then let me know, otherwise I'll recompile my original saved one, and try it out. Not trying to be a pain, just to make sure what I'm doing is valid.
I thought you had done some work on it from our previous conversations

SAD Directives - actually I always knew I'd need a full list, the idea was to be able to get them automatically, but I was trying to support a semi-auto, semi-manual approach.

I think a good compromise might be a fully manual disassembler type with some more directives, perhaps a SUBR - from your comment about drudgery, I totally agree, it where errors creep in. I put those examples in as an idea, we don't have to copy it directly, but I think the idea is sound.

For what it's worth, my minimum dir list suggestion is -

DATA <start> <end> - perhaps extended format for structs (will cover tabs and funcs too)
CODE <start> <end>
VECT <start> <end> - list of subroutines - typically background task list and interrupt handlers
SUBR <start> - perhaps with extended format for params (don't need end)
SYM <start> <name> - and extension for bit naming
BANK <start> <end> <num> to define where banks are in bin file

there could be more of course, but I think that's a good baseline.....

Bank addresses - My idea for multibanks is that it might be useful to go 5 digit, as this neatly binds the bank - when I was looking at listings I made the mistake a few times of assuming the wrong bank. Then print becomes GOTO 842A3 , GOTO 17d42 , CALL 82437 or whatever. Just an idea...

I'm playing with Code::Blocks at the moment to replace Borland, as it supports Windoze, Linux, and others with (supposedly) the same code and interface libs (wxWidgets).

I could use a cut down SAD with no intelligent bits and challenge you to a friendly DUEL !!


5 types of timer lookups ? (or was that funcs ?) OK...I'm only 40% done then !

Rolavs For Dummies

My IT background includes 'real world' stuff (i.e. process control and measurement) and I knew quickly what code was doing for a rolav. I originally named it a 'filter' as that's what we used to call it where I worked ..... but rolling average is actually a more correct description for the EEC environment, and is absolutely necessary.

For those who are not sure why , think about how only a small 'jitter' or 'wobble' in the AD inputs could mess up your careful calcs, and realise that things like an rpm change HAS to be limited and checked to ensure it's reliable, and you'll get the reasons why rolav is there....and of course it cross checks where your AD inputs are....

[mpaton]

Mike,

OK, I just need to check - I have an original BL disassembler, but I'm not sure if yours is modded from there. If you have an updated one you want me to use, then let me know, otherwise I'll recompile my original saved one, and try it out. Not trying to be a pain, just to make sure what I'm doing is valid.
I thought you had done some work on it from our previous conversations

Original BL is fine Andy. Mine is indeed modded from there. It is at revision 154 from there. ;-) I suppose the point I'd like made is that if you know how to go about it, then you can do a lot with the BL one. Mine is still essentially the BL one in that nothing is automatic. However it does have some powerful directives that BL doesn't.

SAD Directives - actually I always knew I'd need a full list, the idea was to be able to get them automatically, but I was trying to support a semi-auto, semi-manual approach.

Then I've misunderstood your goals; I thought it was full automatic and not need the directives. That was a memory from a long time ago though.

I think a good compromise might be a fully manual disassembler type with some more directives, perhaps a SUBR - from your comment about drudgery, I totally agree, it where errors creep in. I put those examples in as an idea, we don't have to copy it directly, but I think the idea is sound.

For what it's worth, my minimum dir list suggestion is -

DATA <start> <end> - perhaps extended format for structs (will cover tabs and funcs too)
CODE <start> <end>
VECT <start> <end> - list of subroutines - typically background task list and interrupt handlers
SUBR <start> - perhaps with extended format for params (don't need end)
SYM <start> <name> - and extension for bit naming
BANK <start> <end> <num> to define where banks are in bin file

I agree with your current semantics for bank. I think you need that much, and I thought I remembered you telling me you didn't.

Bank addresses - My idea for multibanks is that it might be useful to go 5 digit, as this neatly binds the bank - when I was looking at listings I made the mistake a few times of assuming the wrong bank. Then print becomes GOTO 842A3 , GOTO 17d42 , CALL 82437 or whatever. Just an idea...

I agree. The bank number is part of the effective address. You could argue that is a segmented address, but at least there is a single canonical address, not like the hideous x86 scheme which has about 256 ways to represent the same address. Putting the bank nibble in front appeals to me, so that's what I've done.

I'm playing with Code::Blocks at the moment to replace Borland, as it supports Windoze, Linux, and others with (supposedly) the same code and interface libs (wxWidgets).

I'm happiest with gcc on Linux. Of course I neither care so much about Windows not its directions any more. Hence the likleyhood on only doing a Linux bin in future. VirtualBox can be run on almost anything these days. And that's where there are good differencing editors.

I could use a cut down SAD with no intelligent bits and challenge you to a friendly DUEL !!

I'm prepared to accept your challenge, but it seems only fair for you to wait to see what you're challenging.

5 types of timer lookups ? (or was that funcs ?) OK...I'm only 40% done then !

5 that I recall from memory. All use much the same code to derive approximations to mS, Seconds, and my label of oS for octiseconds. however the tables have 5 variations from memory, maybe more. I'm counting different register uses, EEC-IV and EEC-V, and timers in memory and registers, and random addressing and consecutive addressing.

Rolavs For Dummies

My IT background includes 'real world' stuff (i.e. process control and measurement) and I knew quickly what code was doing for a rolav. I originally named it a 'filter' as that's what we used to call it where I worked ..... but rolling average is actually a more correct description for the EEC environment, and is absolutely necessary.

For those who are not sure why , think about how only a small 'jitter' or 'wobble' in the AD inputs could mess up your careful calcs, and realise that things like an rpm change HAS to be limited and checked to ensure it's reliable, and you'll get the reasons why rolav is there....and of course it cross checks where your AD inputs are....

See there's out philosophical differences again. You just gave away some fish, so people didn't have to go and read the 1989 or 1991 documentation. And a wry grin to Andy alone!

Michael

Where's decipha? I heard he disassembled these days!

[cgrey8]

...Then you should read about them in the strategy documents...

Ok, so ROLAVs and UROLAVs are what yall were talking about above with Rolling Average routines.

Now I'm confused by there relevance to the discussion. I get that they are important to locate, but are they particularly difficult to locate or are there multiple versions of them that just make recognizing them a challenge if you've never seen all variants?

[mpaton]

...Then you should read about them in the strategy documents...

Ok, so ROLAVs and UROLAVs are what yall were talking about above with Rolling Average routines.

Now I'm confused by there relevance to the discussion. I get that they are important to locate, but are they particularly difficult to locate or are there multiple versions of them that just make recognizing them a challenge if you've never seen all variants?

They always take parameters
If the parameters are passed inline (in the code stream) then they NEED to be found.
They are always there somewhere
They are not especially difficult to find.
Ford coders often have them close by the function and table lookup code.

Want to go and look or them in HHX0?

Michael

[tvrfan]

Mike,

Snippets taken from above, so as to continue conversation....

Original BL is fine Andy. Mine is indeed modded from there. It is at revision 154 from there.

OK, I'll dig it out and have a go - will try SAD as well

SAD Directives - Yes, I am TRYING to make it fully auto, but realistically accepted It would probably always need SOME manual stuff, so kept a full command parser, aim is to produce a full list of directives automatically as much as poss.

I agree with your current semantics for bank. I think you need that much, and I thought I remembered you telling me you didn't.

On that one, you are correct, we had a difference about whether the loopstop jump for non bank 8 was a reliable enough test, again though I didn't remove the bank command in SAD, just in case.....

Glad you agree about the 5 digit address system - simple and self referencing. I did it originally in my code to stop having to drag address and bank around as two separate params, which seemed silly in a 32 bit (or higher) compiler.

gcc is great for command line, but I was trying to make mine run on Windoze and had the Borland in my archive. I'm Unix/linux too especially 'C', Perl, shell script, and I run my WinXp with Borland in VirtualBox already !! Code::blocks calls gcc underneath I think, but adds some nice easy graphical tools and debugging as well.

5 that I recall from memory.

I have the byte/word covered (very early 'AA' vs A9L and later.

Rolavs For Dummies

See there's out philosophical differences again. You just gave away some fish, so people didn't have to go and read the 1989 or 1991 documentation.

Guilty as charged yer honour.....my answer is "Softly softly catchee monkey......." Note though I didn't give away exactly HOW it's done.....(that's my pathetic defence....)

[Hey, shall we have a big debate about the best way to do averages and interpolations of tables and sensor data ? That could be FUN !!
Oh, on the other hand, I'll have to remember all that crap about statistical analysis, margin of error and standard deviation...... <Hurl> ]

NOW...where's that bloody BL disassembler directory... I know it's in here somewhere.......

[tvrfan]

found BL dis. and can't get it to read any files....Argghhh!!!!! (compiled with gcc in Linux)

OK, drop to SAD, even though it's a bit broken at the moment......
How to do this without giving stuff away.....

I see a set of base regs indicating data starts at c000. I see RAM base regs too, but I won't give them away right now.

I see it's quite like the A9L with HSO table preceeded with a short vect list. HMMMM. more like A9l for some bits of code I see here and there.
I see both func lookups use embedded params (ie. stack) with an encoded first address (assume func addr) and plain second , but tab lookup does not, and has a scaled option.
I see Tab interpolate routine.
I see base HSO output routine
I see table for AD lookups
I see background task list
I see more undecoded than I would like for a first pass.....
I see HSI processor
I see main timer is 24 (or 32) bit
But as of my first pass of 10 mins, I don't see the timer list......

Andy.

[mpaton]

That's good.

What I need for my staged demo/tease/reveal is a dir file for the BL disassembler for HHX0.

And ideally done by someone who wants to learn how to do this and is prepared to do the work.

And i see that we have a post by ironmanisanemic who says he wants to do just that.

If we can get his participation, then we can use some of his bins as examples. I've sent him a PM. We'll see.

Keep trying with the BL one. Once you find the functions with inline arguments and formulate the algorithm for making BL directives, maybe we can get ironmanisanemic to do a little drudge work and complete the dir file.

The focus here on A9L from a disassembly POV is unfortunate, because the strategy doc is very poor compared to the LHBL one.
So Andy, if you haven't read LHBH, I suggest you do, and relate it to this code/bin.

Michael

[mpaton]

Mike,

SAD Directives - Yes, I am TRYING to make it fully auto, but realistically accepted It would probably always need SOME manual stuff, so kept a full command parser, aim is to produce a full list of directives automatically as much as poss.

That reminds me that when I started, i didn't think much of the BL parser, or its lack or error recovery (although for a parser with nonea at all, the end result is not as bad as i would have thought).

So at first I wanted to do a rewrite, but then I thought it would be interesting to NOT act like the tech lead at work and make people do designs, but to just start hacking, like so many do. So I left it, and now the code is big as well as ugly. With non-orthogonal address specs.

[ironmanisanemic]

That's good.

What I need for my staged demo/tease/reveal is a dir file for the BL disassembler for HHX0.

And ideally done by someone who wants to learn how to do this and is prepared to do the work.

And i see that we have a post by ironmanisanemic who says he wants to do just that.

If we can get his participation, then we can use some of his bins as examples. I've sent him a PM. We'll see.

Keep trying with the BL one. Once you find the functions with inline arguments and formulate the algorithm for making BL directives, maybe we can get ironmanisanemic to do a little drudge work and complete the dir file.

The focus here on A9L from a disassembly POV is unfortunate, because the strategy doc is very poor compared to the LHBL one.
So Andy, if you haven't read LHBH, I suggest you do, and relate it to this code/bin.

Michael

I haven't gotten any PM s, but i am willing to learn. I'm willing to do whatever work is needed. Unfortunately I don't have much free time, so i will probably only get weekends to work on it.

I do want to learn with the end goal being definition development. I do have a few bins that aren't common around here that I would like to play with and maybe make def s for.

Let me know what i need to do and I will try and get the ball rolling

[mpaton]

I haven't gotten any PM s, but i am willing to learn. I'm willing to do whatever work is needed. Unfortunately I don't have much free time, so i will probably only get weekends to work on it.

I do want to learn with the end goal being definition development. I do have a few bins that aren't common around here that I would like to play with and maybe make def s for.

Let me know what i need to do and I will try and get the ball rolling

Thanks. Maybe you'll have the PM by now, but in any case, it asked you to post your 2 bins that you mentioned in your thread, if you have them extracted from your ECUs, or post the catch codes if not.

Also do you have the LHBH doc from this site downloaded? It's big, but set yourself a goal of reading it, a little at a time. Skip the transmission parts if you're not interested in them.

Do you have the Bill Lawrance disassembler downloaded and runnable? If not, do that.

i'll assume your computer runs Windows, but if it is linux or a Mac, let us know.

You will need to use a text editor, so find one you like and learn how to do simple stuff with it. It's not my intent to patronize here, but I mean for you to use a text editor and not a word processor. If you don't have a favourite yet, I'd suggest downloading and installing gvim from vim.org, but editors are a personal choice.

You will be using some form of command windows or shell, so let us know if you don't know how to find one.

Michael

Download the bin file

[sailorbob]

What I need for my staged demo/tease/reveal is a dir file for the BL disassembler for HHX0.

And ideally done by someone who wants to learn how to do this and is prepared to do the work.

I'm not volunteering, far to many inline parameters to tackle with the base BL disassembler. Not even the 'vect' directive to help. Been there, done that and got the T shirt far too many times in the past

[cgrey8]

...I'm not volunteering, far to many inline parameters to tackle with the base BL disassembler. Not even the 'vect' directive to help. Been there, done that and got the T shirt far too many times in the past

So when you need to do "new bin" disassembly, what tool do you use and how do you start? In other words, what's most efficient for you?

[mpaton]

What I need for my staged demo/tease/reveal is a dir file for the BL disassembler for HHX0.

And ideally done by someone who wants to learn how to do this and is prepared to do the work.

I'm not volunteering, far to many inline parameters to tackle with the base BL disassembler. Not even the 'vect' directive to help. Been there, done that and got the T shirt far too many times in the past

I was already quite happy for you to get a waiver on this. We're both glad we don't have to do that any more.

But I do want people to see that is possible to make things work this way. It's not just that I had to do it, and so you have to do it, newbies.

[mpaton]

...I'm not volunteering, far to many inline parameters to tackle with the base BL disassembler. Not even the 'vect' directive to help. Been there, done that and got the T shirt far too many times in the past

So when you need to do "new bin" disassembly, what tool do you use and how do you start? In other words, what's most efficient for you?

Things will be revealed in due course. It looks like SAD has some help to offer, and sailorbob has been a beta tester of mine for some earlier versions.

Can we get you to contribute some work to this effort Chris?

Michael

[decipha]

Where's decipha? I heard he disassembled these days!

I'm here, I don't frequent the forum as much as I used to but I try to drop by as much as I can

I don't have any complete disassembly's just partial's here and there usually just to find what I need to tune and or add features that I want like the nitrous code for gufb. Believe me when I say I don't enjoy doing it and the little bit I've done is nothing compared to what sailorbob has done or both you an Andy as well. The only strategy I've spent any amount of real time on is FBFG2. I've only got about 800 hrs in it and I've just scratched the surface, I still have quite a bit of it left to go through. In fact I approximated the other day just to get a round about figure and I estimated there's roughly 4,000 scalars 600 functions and 300 tables or so. I would have to say I got about 10% of it completed currently. As much as I've tried to avoid it I believe it's inevitable someone makes an open source 4 bank def file. Since no one has stepped up to the plate in the past 11 years the chances of it happening seemed minute so I figured why not. And I figured if I were to invest any time in it I might as well go to the newest strat. I'm making progress but its slow, taking on the hhx0 bin and spending any appreciable time on it just so we can talk about it doesn't sound very appealing to me at all.

[mpaton]

Where's decipha? I heard he disassembled these days!

I'm here, I don't frequent the forum as much as I used to but I try to drop by as much as I can

I don't have any complete disassembly's just partial's here and there usually just to find what I need to tune and or add features that I want like the nitrous code for gufb. Believe me when I say I don't enjoy doing it and the little bit I've done is nothing compared to what sailorbob has done or both you an Andy as well. The only strategy I've spent any amount of real time on is FBFG2. I've only got about 800 hrs in it and I've just scratched the surface, I still have quite a bit of it left to go through. In fact I approximated the other day just to get a round about figure and I estimated there's roughly 4,000 scalars 600 functions and 300 tables or so. I would have to say I got about 10% of it completed currently. As much as I've tried to avoid it I believe it's inevitable someone makes an open source 4 bank def file. Since no one has stepped up to the plate in the past 11 years the chances of it happening seemed minute so I figured why not. And I figured if I were to invest any time in it I might as well go to the newest strat. I'm making progress but its slow, taking on the hhx0 bin and spending any appreciable time on it just so we can talk about it doesn't sound very appealing to me at all.

I do understand where you're coming from. however, there's a potential leap forward in disassembling ability in it for you, and I'm asking for only about 2 hours of your time. Your call. I understand you don't see an upside for yourself.

[cgrey8]

I can try, although I don't know how much I can or have to contribute. You know the depths that I got into disassembly...just enough to muddle my way around, but no where near the level bin hacker.

What is it you need me to do? And what is it I'm looking for? Generally when I start in on a technical task, I have a specific goal I'm looking to attain that acts as a compass along the way, a plan of attack of how I'll begin, and I have a fairly good idea of what "done" is so I can gauge whether I succeeded or not.

When it comes to looking at disassembly and trying to get a clean disassembly, I'm not sure I know even how to start. I remember making those description files in the BL disassembler back when you were trying to teach me disassembly, and I didn't fully understand why certain things would happen the way they did. Most pertained to simply not knowing details about the processor and the instructions...and the 8096 technical instructions not detailing out exactly what I needed to know for one reason or another (including my lack knowing what to look for).

[mpaton]

I can try, although I don't know how much I can or have to contribute. You know the depths that I got into disassembly...just enough to muddle my way around, but no where near the level bin hacker.

What is it you need me to do? And what is it I'm looking for? Generally when I start in on a technical task, I have a specific goal I'm looking to attain that acts as a compass along the way, a plan of attack of how I'll begin, and I have a fairly good idea of what "done" is so I can gauge whether I succeeded or not.

When it comes to looking at disassembly and trying to get a clean disassembly, I'm not sure I know even how to start. I remember making those description files in the BL disassembler back when you were trying to teach me disassembly, and I didn't fully understand why certain things would happen the way they did. Most pertained to simply not knowing details about the processor and the instructions...and the 8096 technical instructions not detailing out exactly what I needed to know for one reason or another (including my lack knowing what to look for).

I would propose that we go through the task of mking a dir file for the BL disassembler which produces a clean disassembly.

Andy or I will start you off with the basic one that starts off with code 2000 then some word or byte directives that get you into the code.

Then we will look at how the function calls work. For example there are many calls to the 4 possible byte sized function lookup routines. Each of those starts with

call 0x4567 where 4567 is the address of the routine entry point. The next things in the code stream are 4 bytes of data, and then back to code, so once we know that 4567 is an entry point of that sort, we need to find all calls to those functions and write 2 lines of dir file for each call.

For example, 459E is a routine entry point like this, and there is a call to 459E at 0x3F3B

So we need to find the address of the instruction after the call (and the 3 byte call instruction might be a 2 byte scall instruction)

and write 2 lines of appropriately formatted dir file

word 456A
code 456E

for every occurrence of a call or scall to 459E and all the other routines that take inline arguments.
This stops the disassembler from treating the 4 bytes after the call as code. it doesn't yet deal with what kind of data they actually are. That comes later.

So I propose splitting up address ranges of the HHX0 bin between yourself and ironmanisanemic and decipha if he wants to play, and get a dir file. And decipha gets a methodology for the guide on his website.

So it isn't hard, but mistakes are easy. But you can try out your work on the bin and see if it works.

Michael

[sailorbob]

I generally use an earlier version of Michaels disassembler, the inline parameter handling is arguably its most useful feature. I also have a Perl script that Michael steered me into writing. It parses through a listing to help identify the addresses of unnamed scalars and functions referenced by the "tmp21" scratch register and also dumps part of the listing out for use as directives for pasting into the .dir file after I've hand editing listing.

Prior to this I was using a modified version of the BL disassembler with some of Michael's code and some of my own.

That HHX0 bin is bit odd with a large chunk of null data before the data blocks. Not some thing you see on a late eec-iv.

[mpaton]

found BL dis. and can't get it to read any files....Argghhh!!!!! (compiled with gcc in Linux)
Andy.

This error is so old, I'd forgotten about it.

Assuming this is version 115 or so of the BL disassembler look for the initialization of the variable inpbufl in main.c

it's initialized to 40000 and it needs to be 65536 - 0x2000 or it could equally well be 65536 these days.

You'll also need to check on the include of dis_806x.h because BL took liberties with the case insensitivity of the Windoze file system.

I could build you a linux verson, but i no longer have Windoze compiling ability, so i'll need to ask you to build our volunteers a Windoze executable.

This all assumes of course that you have an error message claiming end < start

If not, let me know what the symptoms are.

Michael