[ironmanisanemic]

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.

Yep, i still dont have a PM, oh well. I do have the bins extracted, ill zip them up and attach them. EC2 is from a 87 Lincoln Town Car with the 5.0 and AOD. It from what i can tell is sequential fire and SD similar to LUX0, but has cruise control built into the ECU (its the one im most interested in). 8PZ is my old 89 Bronco 5.0 computer. It was a batch fire SD non electronic trans computer. I also have a third bin i wouldn't mind getting into, but its EEC-V and is a 4 bank bin, so a bit more trouble than its worth for this exercise.

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.

I do have the LHBH doc. I didnt start reading it because its size intimidated me. But i will start whittling away at it

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

I believe i have it, i downloaded a ton of stuff from the yahoo page and put it on my google drive. was it a command line interface? If so i believe i found it.

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

I mainly run windows, but do run linux in a dual boot on our desktop.

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.

I have notepad++ set as my default text editor. I never could get behind vim in linux, wasnt my favorite. Will i also need a HEX editor? i have one of those already as well.

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

I can pull them up easy enough, in windows what is preferred, CMD or PowerShell?

Michael

Download the bin file

[jsa]

Well I am time limited, and must put something else on hold to play with this. I've been following the thread and have picked the eyes out of it here. I may not be able to keep up with the pace that you might wish to progress Mike, but lets see.

If anyone wants to play, please disassemble this using SAD and please somebody also do at least a little bit with the Lawrance disassembler.

Ok done, using BL's V115

BL gives this info;

Code: Select all

2000                      org   $2000
0000                Zero                              equ   $0000
0002                Low_Speed_Output                  equ   $0002
0003                BiDirect_Port                     equ   $0003
0004                AD_Lo                             equ   $0004
0004                Watchdog_Timer                    equ   $0004
0005                AD_Hi                             equ   $0005
0005                AD_Command                        equ   $0005
0006                Master_IO_Timer_Lo                equ   $0006
0007                Master_IO_Timer_Hi                equ   $0007
0008                Interrupt_Mask                    equ   $0008
0009                Interrupt_Pending                 equ   $0009
000A                IO_Status                         equ   $000A
000B                HSI_Sample                        equ   $000B
000C                HSI_Data_Mask                     equ   $000C
000D                HSI_Data_Hold                     equ   $000D
000E                HSI_Time_Hold                     equ   $000E
0010                Stack_Ptr                         equ   $0010
2000                      end

SAD equivalent;

Code: Select all

2010: 03,2d             vect  2d03,          IPT_HSO_2
2012: e5,2c             vect  2ce5,          IPT_Timer_OVF
2014: 02,2d             vect  2d02,          IPT_Ignore
2016: 02,2d             vect  2d02,          IPT_Ignore
2018: ae,23             vect  23ae,          IPT_External
201a: fe,2a             vect  2afe,          IPT_HSO_1
201c: 02,2d             vect  2d02,          IPT_Ignore
201e: 8f,2a             vect  2a8f,          IPT_HSI_0

Now right away SAD has told me addresses I have access too, to follow.

BL told me there is a Stack_Ptr at x0010, but I don't have that address in the bin you provided. So armed with BL alone I'm scratching my 8061 numpty head. I need a sardine to get me interested before going fishing for tuna, Mike.

Having read the Reference Handbook, looking at the full 64K of GHAJ0 and looking at the SAD listing, I can deduce the word at x0010 & x0011 is 03,2D or x2D03.

Now how do I make that deduction with BL alone ?

I'm thinking maybe searching for something that references x0010. So knowing from SAD that x2D03 is the pointed to address , I look there but I'm not immediately picking up a reference to x0010. What I do see is code that matches with GHAJ0's equivalent.

(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

Right there I'm not certain what is meant. Without a formal programming education, industry jargon loses me. Can I have a sardine please Mike ?

So I think a subroutine call is the opcode CALL followed by an address to a piece of code that does something, then returns to the line after the CALL opcode.

What do you mean by inline arguments ? Is that the arguments that go with opcode CALL ?

ROLAV, you have me beat, thankfully Andy threw a sardine later on. Rolling average, like Chris and Andy I understand its purpose from a process control standpoint. I don't recognise ROLAV code.

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

I don't know what they are, their purpose, or where to find out. Some one chuck me a sardine please.

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

This I think I pick up on from x2020, because I previously had a light bulb moment looking at a SAD listing of GHAJ0. Again for a beginner BL gave me nothing.

Code: Select all

08 01

08 tells me there are 8 addresses.
01 has significance, but I need to refresh my ORAM.

x2022 onwards for

Code: Select all

00 C0 28 C4 36 C4 A0 C9 4A CB 70 CC D4 D1 D6 D1

8 address for Data starts;
C000
C428
C436
C9A0
CB4A
CC70
D1D4
D1D6

Is it safe to say 08 01 00 C0 is a pattern that holds for all bins ?

I don't know how to recognise the end of each data block.

(v) The analog input table

A table with the present values from the analog inputs ?
Must be some code somewhere that reads that from x0004 & x0005, then stores it in said table.
I'm uncertain where to start looking for this.
I have been testing input pins and logging lots of addresses, eventually I might close in on its whereabouts in GHAJ0 but that is not an efficient approach, and may only be valid for GHAJ0 alone.

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

Again, I'm uncertain where to start looking for this.

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

Not boring at all. It helps with understanding the process of and tools for disassembly. Please keep it out in the open.

I have no interest in giving away fish. I'm happy to help people learn how to fish.

Fair enough, but that will limit the number prepared to even try. A sardine here or there will help us numpties get a toe hold to build on. I applaud Andy for giving a great starting point with SAD, and the snippets of help.

Mike, thank you for the time your putting in to this, please don't disregard those of us starting off a very low base.

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.

I can say SAD is helpful, yes it defers some learning but it provides a starting point. Yes, I think I'm getting somewhere, I now understand some things I never understood before using SAD on GHAJ0. Yes, there is a lot more to understand.

I have no strategy doc for GHAJ0, I have read 3 strategy docs including LHBH some time ago. I don't need to make a def for GHAJ0 as sailorbob has done the hard work. I'd like to understand how it functions and that is a case of following the code. I expect the process of following the code would result in enough understanding to make a def file.

go and read the 1989 or 1991 documentation

What are they ?

parameters are passed inline

Can you give an example or an expanded explanation of what that means, please ?

My apologies for many questions and not much in return.

[tvrfan]

Here is a quick example of what we are calling inline parameters. (apologies to mpaton already, for me giving out free data again...)

The high level equivalent would be where a subroutine is defined with params as in 'C' (Tech - Yes, I know, this isn't technically accurate, but it will do for explanation purposes)

int do_something (int a, int b, int c)
{
...
}

in the EEC code, this becomes byte(s) of DATA in the code, which are completely invisible to something like the base disassembler, which tries to interpret this as code, and makes a mess of it....

Here's an A9L snippet (Yeah, yeah, I know, it's just that I have lots of versions of this.....)
firstly, where it's wrong

Code: Select all

  Sub63:
7273: ef,79,08           call  7aef           Sub79();
7276: c9,7f,72           push  727f           push(727f);
7279: 28,12              scall 728d           Sub101(); 
727b: 81,06,10,46        orw   R46,1006
727f: 28,a4              scall 7325           Sub81();
7281: 91,10,46           orb   R46,10
7284: c9,97,72           push  7297           push(7297);
7287: 28,06              scall 728f           OCC_chk2();
7289: 82,04,01           orw   R1,[R4]        R1 |= AD_LO;
728c: 46,28,8a,e7        ad3w  Re7,R8a,[R28]  Re7 = R8a + R28; 
7290: e4                 !INV! 
7291: 07,01              incw  R1             R1++;
7293: 30,ef,1d           jnb   B0,Ref,72b3    if (!Power_up) goto 72b3;
7296: 05,c7              decw  Rc7            Rc7--; 
7298: 72,4a,00           an2b  R0,[R4a]       0 &= [R4a];
729b: 17,38              incb  R38            R38++;
729d: f0                 ret                  return;

When you look at this, what do you see ?? Assigning AD_LO register (pointer) to R1 ?? incrementing R1 ???? is that even legal ????
Adding content of a pointer to R0 ??
No no no, something went screwy here......
I'll leave this here for a short while, and post the answer later....

Hmm..... or another teaser perhaps..... what does THIS code actually do ?

Code: Select all

 cc,38             pop   R38            R38 = pop(); 
 b2,3b,3c          ldb   R3c,[R38++]    R3c = [R38++];
 b2,3b,3d          ldb   R3d,[R38++]    R3d = [R38++];
 c8,38             push  R38            push(R38);

when you can understand THIS you are a good way to understanding what subroutine calls do, and how inline parameters work ......

[ironmanisanemic]

Here is a quick example of what we are calling inline parameters. (apologies to mpaton already, for me giving out free data again...)

The high level equivalent would be where a subroutine is defined with params as in 'C' (Tech - Yes, I know, this isn't technically accurate, but it will do for explanation purposes)

int do_something (int a, int b, int c)
{
...
}

in the EEC code, this becomes byte(s) of DATA in the code, which are completely invisible to something like the base disassembler, which tries to interpret this as code, and makes a mess of it....

Here's an A9L snippet (Yeah, yeah, I know, it's just that I have lots of versions of this.....)
firstly, where it's wrong

Code: Select all

  Sub63:
7273: ef,79,08           call  7aef           Sub79();
7276: c9,7f,72           push  727f           push(727f);
7279: 28,12              scall 728d           Sub101(); 
727b: 81,06,10,46        orw   R46,1006
727f: 28,a4              scall 7325           Sub81();
7281: 91,10,46           orb   R46,10
7284: c9,97,72           push  7297           push(7297);
7287: 28,06              scall 728f           OCC_chk2();
7289: 82,04,01           orw   R1,[R4]        R1 |= AD_LO;
728c: 46,28,8a,e7        ad3w  Re7,R8a,[R28]  Re7 = R8a + R28; 
7290: e4                 !INV! 
7291: 07,01              incw  R1             R1++;
7293: 30,ef,1d           jnb   B0,Ref,72b3    if (!Power_up) goto 72b3;
7296: 05,c7              decw  Rc7            Rc7--; 
7298: 72,4a,00           an2b  R0,[R4a]       0 &= [R4a];
729b: 17,38              incb  R38            R38++;
729d: f0                 ret                  return;

When you look at this, what do you see ?? Assigning AD_LO register (pointer) to R1 ?? incrementing R1 ???? is that even legal ????
Adding content of a pointer to R0 ??
No no no, something went screwy here......
I'll leave this here for a short while, and post the answer later....

If i had to make a guess, from 7287 through 7292 are inline parameters. You gave me a clue when you said AD_LO and R1. I assumed there was a problem when at 7290 its invalid data for an opcode, and the end of the data would be when you gave another hint at incrementing R1

Hmm..... or another teaser perhaps..... what does THIS code actually do ?

Code: Select all

 cc,38             pop   R38            R38 = pop(); 
 b2,3b,3c          ldb   R3c,[R38++]    R3c = [R38++];
 b2,3b,3d          ldb   R3d,[R38++]    R3d = [R38++];
 c8,38             push  R38            push(R38);

So i dont immediately see an issue (i only assume there is one because you are using it as an example), but one thing that doesnt seem quite right is it is setting R38 to 2 different other registers after it popeed to the top of the stack. (im assuming thats what that means). So i take it as there is an issue in that all or some is an inline parameter. There is an even number of bytes to make it words or double words.

when you can understand THIS you are a good way to understanding what subroutine calls do, and how inline parameters work ......

I hope i at least got something right in my answers.

[jsa]

Here is a quick example of what we are calling inline parameters. (apologies to mpaton already, for me giving out free data again...)

The high level equivalent would be where a subroutine is defined with params as in 'C' (Tech - Yes, I know, this isn't technically accurate, but it will do for explanation purposes)

int do_something (int a, int b, int c)
{
...
}

in the EEC code, this becomes byte(s) of DATA in the code, which are completely invisible to something like the base disassembler, which tries to interpret this as code, and makes a mess of it....

Here's an A9L snippet (Yeah, yeah, I know, it's just that I have lots of versions of this.....)
firstly, where it's wrong

I think I see what you mean E4,07,01 are inline parameters ?

As I've worked through it I have added comments and questions to your example code.

Code: Select all

  Sub63:
7273: ef,79,08           call  7aef           Sub79();                  The processor runs the code at 7aef and returns
7276: c9,7f,72           push  727f           push(727f);            Upon returning the processor takes the (word ???) value from 727f
                                                                                        and puts it on the stack.
                                                                                        What stack, how many stacks are there, and where are they ???
7279: 28,12              scall 728d           Sub101();                Is it putting the value of x0028/x0029 on a/the stack ???
                                                                                        x7279+x0012=x728B, so the key must be +x0002 to account for
                                                                                        2 bytes of the opcode and offset distance value
727b: 81,06,10,46        orw   R46,1006                               Upon return the word from either x0046/x0047 or x1006/x1007
                                                                                        is held at R46 which is x0046/x0047. Have I got that in the right
                                                                                        order ??? I'm missing how the choice between the two is made ???
727f: 28,a4              scall 7325           Sub81();                  Similar to line 7279, x727f+x00a4+x0002=x7325
7281: 91,10,46           orb   R46,10                                    Similar to line 727b but for a byte instead of a word.
7284: c9,97,72           push  7297           push(7297);         Similar to line 727f
7287: 28,06              scall 728f           OCC_chk2();            Similar to line 7279, x7287+x0006+x0002=x728D. Value of x00E7
7289: 82,04,01           orw   R1,[R4]        R1 |= AD_LO;      Ok so I need to understand the nuances of opcode 81 VS 82.
728c: 46,28,8a,e7        ad3w  Re7,R8a,[R28]  Re7 = R8a + R28; Add x008A/x008B to x0028/x0029 and store at x00E7/x00E8
7290: e4                 !INV!                                                 E4 should this be data, haven't found reference to opcode E4
7291: 07,01              incw  R1             R1++;                    x0000/x0001 are supposed to be Zero. Can't be right trying to 
                                                                                       increment the high byte, or trying to increment x0001/x0002.
                                                                                       So are E4,07,01 supposed to be data ???
7293: 30,ef,1d           jnb   B0,Ref,72b3    if (!Power_up) goto 72b3;
7296: 05,c7              decw  Rc7            Rc7--; 
7298: 72,4a,00           an2b  R0,[R4a]       0 &= [R4a];
729b: 17,38              incb  R38            R38++;
729d: f0                 ret                  return;

or another teaser perhaps..... what does THIS code actually do ?

Code: Select all

 cc,38             pop   R38            R38 = pop();                 Getting a word from a/the stack and storing it to x0038/x0039
 b2,3b,3c          ldb   R3c,[R38++]    R3c = [R38++];      If opcode CC is supposed to be a word, why are we taking a byte
 b2,3b,3d          ldb   R3d,[R38++]    R3d = [R38++];     from x0038/x0039 and storing in x003c & x003d
 c8,38             push  R38            push(R38);

when you can understand THIS you are a good way to understanding what subroutine calls do, and how inline parameters work

I have yet to understand your second example. It doesn't make sense to me, why not load a word ? Is it even placing the lo and hi bytes at R3C & R3D respectively ?

Times up for now so I'll have to come back to this last example.

Edit: I see ironman has posted while I'm working through this.

[mpaton]

Thanks for coming in to play John.

Well I am time limited, and must put something else on hold to play with this. I've been following the thread and have picked the eyes out of it here. I may not be able to keep up with the pace that you might wish to progress Mike, but lets see.

If anyone wants to play, please disassemble this using SAD and please somebody also do at least a little bit with the Lawrance disassembler.

Ok done, using BL's V115

BL gives this info;

Code: Select all

2000                      org   $2000
0000                Zero                              equ   $0000
0002                Low_Speed_Output                  equ   $0002
0003                BiDirect_Port                     equ   $0003
0004                AD_Lo                             equ   $0004
0004                Watchdog_Timer                    equ   $0004
0005                AD_Hi                             equ   $0005
0005                AD_Command                        equ   $0005
0006                Master_IO_Timer_Lo                equ   $0006
0007                Master_IO_Timer_Hi                equ   $0007
0008                Interrupt_Mask                    equ   $0008
0009                Interrupt_Pending                 equ   $0009
000A                IO_Status                         equ   $000A
000B                HSI_Sample                        equ   $000B
000C                HSI_Data_Mask                     equ   $000C
000D                HSI_Data_Hold                     equ   $000D
000E                HSI_Time_Hold                     equ   $000E
0010                Stack_Ptr                         equ   $0010
2000                      end

This is what you get out of BL if you put nothing in. BL is a disassembler that needs directives in a file of the same name as the bin file, but with the suffix of .dir instead of .bin

That dir file also has fairly strict formatting requirements, in that the directive must start in column 1 and the address which follows must start in column 13. I had thought this was covered in the meagre documentation that comes with BL, but maybe that's been separated out over the years. So what you've got, is just the symbol table of predefined registers, no disassembly at all.

Can you try again with a dir file that contains at least the line

code 2000

where the address of 2000 starts in column 13. (counting from code in column 1)

You've made some very perceptive comments later on, so I'm sure you'll get much further.

SAD equivalent;

Code: Select all

2010: 03,2d             vect  2d03,          IPT_HSO_2
2012: e5,2c             vect  2ce5,          IPT_Timer_OVF
2014: 02,2d             vect  2d02,          IPT_Ignore
2016: 02,2d             vect  2d02,          IPT_Ignore
2018: ae,23             vect  23ae,          IPT_External
201a: fe,2a             vect  2afe,          IPT_HSO_1
201c: 02,2d             vect  2d02,          IPT_Ignore
201e: 8f,2a             vect  2a8f,          IPT_HSI_0

and btw, these are not equivalents. The SAD extract is a disassembly of some bytes starting at the ECU address 0x2010
while the BL extract is just a symbol table extract.

Now right away SAD has told me addresses I have access too, to follow.

BL told me there is a Stack_Ptr at x0010, but I don't have that address in the bin you provided. So armed with BL alone I'm scratching my 8061 numpty head. I need a sardine to get me interested before going fishing for tuna, Mike.

And that single line provided is your sardine. Stick that in a dir file, and please try BL again. You should get quite a lot.
I'll reply to the rest of your post separately.

Michael

[ironmanisanemic]

BL gives this info;

Code: Select all

2000                      org   $2000
0000                Zero                              equ   $0000
0002                Low_Speed_Output                  equ   $0002
0003                BiDirect_Port                     equ   $0003
0004                AD_Lo                             equ   $0004
0004                Watchdog_Timer                    equ   $0004
0005                AD_Hi                             equ   $0005
0005                AD_Command                        equ   $0005
0006                Master_IO_Timer_Lo                equ   $0006
0007                Master_IO_Timer_Hi                equ   $0007
0008                Interrupt_Mask                    equ   $0008
0009                Interrupt_Pending                 equ   $0009
000A                IO_Status                         equ   $000A
000B                HSI_Sample                        equ   $000B
000C                HSI_Data_Mask                     equ   $000C
000D                HSI_Data_Hold                     equ   $000D
000E                HSI_Time_Hold                     equ   $000E
0010                Stack_Ptr                         equ   $0010
2000                      end

I dont get whats above when i feed a bin through BL, i get this (this is using your HHX0a.bin)

Code: Select all

2000                      org   $2000
2000                      end

This is what you get out of BL if you put nothing in. BL is a disassembler that needs directives in a file of the same name as the bin file, but with the suffix of .dir instead of .bin

That dir file also has fairly strict formatting requirements, in that the directive must start in column 1 and the address which follows must start in column 13. I had thought this was covered in the meagre documentation that comes with BL, but maybe that's been separated out over the years. So what you've got, is just the symbol table of predefined registers, no disassembly at all.

Can you try again with a dir file that contains at least the line

code 2000

where the address of 2000 starts in column 13. (counting from code in column 1)

I tried that and i kept getting an error that i had an illegal ASCII char on line 1 of the directive. I tried all sorts of things, and it finally wouldnt error out but the program would stop responding and windows would force close it.

[mpaton]

Attached is the instructions that come with the BL disassembler, such as they are in a file called

dirfile.txt

The BL disassembler reads the bin file and then needs to be told what to do. It needs to be told to start disassembling bytes as if they were code and then if bytes become other than code, it needs to be told that also.

That is the purpose of the dir file
The dirfile.txt file that comes with it gives you the very particular syntax you need to use in the dir file

The Lawrance disassembler version 1.15 to 1.17 has a bug which will prevent it from disassembling the HHX0 bin (or indeed any longer more modern bin.

Lest anyone wonder if I'm going to do any work here, I can tell you that I've just spent a painful 3 hours finding a Windoze compilation environment on an old laptop, fixing the bug, recompiling the disassembler, finding another bug, tracking that down without a debugger, finding it's in the area of comment directives, disabling them and recompiling.

So please use this version of BL, zipped below.

[ironmanisanemic]

Attached is the instructions that come with the BL disassembler, such as they are in a file called

dirfile.txt

The BL disassembler reads the bin file and then needs to be told what to do. It needs to be told to start disassembling bytes as if they were code and then if bytes become other than code, it needs to be told that also.

That is the purpose of the dir file
The dirfile.txt file that comes with it gives you the very particular syntax you need to use in the dir file

The Lawrance disassembler version 1.15 to 1.17 has a bug which will prevent it from disassembling the HHX0 bin (or indeed any longer more modern bin.

Lest anyone wonder if I'm going to do any work here, I can tell you that I've just spent a painful 3 hours finding a Windoze compilation environment on an old laptop, fixing the bug, recompiling the disassembler, finding another bug, tracking that down without a debugger, finding it's in the area of comment directives, disabling them and recompiling.

So please use this version of BL, zipped below.

That did it. I was able to do SOMETHING with BL now. Adding code 2000 is effectively the same as doing code 2000-ffff in sad it interprets EVERYTHING as code. I can see why this would be difficult, because now you have to be able to distinguish whats actually code and whats tables, scalars, functions being interpreted as code.

[mpaton]

And here is a starter dir file for HHX0a

I didn't know we were limited to 2 attachments here.

How interesting. Apparently we aren't but something doesn't like dir files.


And finally, while it's very important to understand what inline parameters are, and what they do,
we are currently just one step behind that.

Where we are now is that we tell the BL disassembler to treat all bytes of the bin as code.

Inline parameters at this point are nothing more than bytes which are NOT code. this confuses the BL disassembler, and leads it astray.

So my own preference would be to start another thread for "what are inline parameters" and for the moment anyway, this one can focus on working around the things that aren't code, so that BL can produce a good disassembly.

I don't want to withhold any information, I just want to make the process as clear and easy to understand as it could be.
I also understand that one can't identify these things/monsters that are NOT CODE without recognizing them, so there's lots of potential for a circular argument here.


Michael

[ironmanisanemic]

Why dont we start a new thread with this being the topic? i feel we have gotten a little off topic from the original subject. We can do Disassembly 101 or Machine Code for Dummies, and as you suggested yet another for what are inline parameters.

[mpaton]

Why dont we start a new thread with this being the topic? i feel we have gotten a little off topic from the original subject. We can do Disassembly 101 or Machine Code for Dummies, and as you suggested yet another for what are inline parameters.

How about we start the new thread when you're able to post some more dir file? Assuming you can run with the 0x459E and 0x45A9 calls.

That will give Andy and I time to decide how to proceed about identifying other calls that need "treatment"

Does that work for you?

Michael

[ironmanisanemic]

Why dont we start a new thread with this being the topic? i feel we have gotten a little off topic from the original subject. We can do Disassembly 101 or Machine Code for Dummies, and as you suggested yet another for what are inline parameters.

How about we start the new thread when you're able to post some more dir file? Assuming you can run with the 0x459E and 0x45A9 calls.

That will give Andy and I time to decide how to proceed about identifying other calls that need "treatment"

Does that work for you?

Michael

I would LOVE to be able to get more of the dir file, but to be completely honest I have no idea what im doing. You mention 0x459E and 0x45A9, but looking at what BL put out i dont know where you found those to start with. To be fair, i am probably way in over my head with this undertaking. I still want to try to dredge through this, but im going to need some rather direct instructions until i get a rough understanding what im looking for and at. Remember i have ZERO programming background, so this is all new to me.

[mpaton]

Assuming you can run with the 0x459E and 0x45A9 calls.

I would LOVE to be able to get more of the dir file, but to be completely honest I have no idea what im doing. You mention 0x459E and 0x45A9, but looking at what BL put out i dont know where you found those to start with.

I think you don't know HOW I found those. That will be explained a bit later, and in another thread I started. For now, don't worry about it; one thing at a time. It is important,but not just yet. You got a big listing out of BL.exe, probably nearly 300 lines of it.

Search for a call or scall instruction to address 459E

To be fair, i am probably way in over my head with this undertaking. I still want to try to dredge through this, but im going to need some rather direct instructions until i get a rough understanding what im looking for and at. Remember i have ZERO programming background, so this is all new to me.

From a post in this thread on Friday:

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 then having put those 2 lines in our dir file, we then look for the next call or scall to 459E. Then find the address of the following instruction (left hand column) and use that address for another word(or byte) directive in your dir file. Then another code directive with the address 4 bytes after the word(or byte) one.

Michael

[tvrfan]

More, without giving it away, as I want you guys to learn.

That A9L snippet isn't just wrong at 7289..... the other error is more subtle and harder to spot, but it's still right there.....however spotting the more obvious one still helps.
jsa you are on the right path......well done so far......

Code: Select all

  Sub63:
7273: ef,79,08           call  7aef           Sub79();
7276: c9,7f,72           push  727f           push(727f);
7279: 28,12              scall 728d           Sub101(); 
727b: 81,06,10,46        orw   R46,1006
727f: 28,a4              scall 7325           Sub81();
7281: 91,10,46           orb   R46,10
7284: c9,97,72           push  7297           push(7297);
7287: 28,06              scall 728f           OCC_chk2();
7289: 82,04,01           orw   R1,[R4]        R1 |= AD_LO;
728c: 46,28,8a,e7        ad3w  Re7,R8a,[R28]  Re7 = R8a + R28; 
7290: e4                 !INV! 
7291: 07,01              incw  R1             R1++;
7293: 30,ef,1d           jnb   B0,Ref,72b3    if (!Power_up) goto 72b3;
7296: 05,c7              decw  Rc7            Rc7--; 
7298: 72,4a,00           an2b  R0,[R4a]       0 &= [R4a];
729b: 17,38              incb  R38            R38++;
729d: f0                 ret                  return;

as for the second - john had a go, but it's not so much WHAT it does, but WHY as well

here's another clue - when a CPU does a CALL to a subroutine, it jumps off and does it right ??
Has anyone considered how the CPU knows where to go back ? what actually happens when RET is executed...
Have a read up on this kind of stuff - all general purpose CPUs have the same (more or less) setup, and I'm not going to tell you.....so that mpaton won't tell me off (joke),
but believe me, it's worth the research, and I really hope you have the 'lightbulb' moment ..... and answer is in the 8096 docs, and almost every other CPU.....

so something CALLS here ....

Code: Select all

 cc,38             pop   R38            R38 = pop(); 
 b2,3b,3c          ldb   R3c,[R38++]    R3c = [R38++];
 b2,3b,3d          ldb   R3d,[R38++]    R3d = [R38++];
 c8,38             push  R38            push(R38);

[tvrfan]

Michael,

I can't get the BL disassembler to do anything but seg violate !! Which is VERY annoying.....
Anyway, this thread has given me a good kick up the rear end to get SAD improved and released again - and it DOES have a purely manual setting.
(I know we discussed the issue9s0 of just how automatic, but I've been around IT long enough to know that a good design has the belt, braces, AND string in the back pocket !)

I'll try the posted dir file and see what happens.....

NB. I posted stuff here as an old fashioned zip file, which seems to get around the .exe and filetype checks....

I hope the teaser approach to the parameters is OK.....

[mpaton]

Michael,

I can't get the BL disassembler to do anything but seg violate !! Which is VERY annoying.....

Me too, but I fixed it. I sent you 2 emails about it; have you changed emails since the last gmail one I had for you?
And I believe I sent you a PM, but evidently I'm not too competent at PMs.

I'll try the posted dir file and see what happens.....
I hope the teaser approach to the parameters is OK.....

Posted dir file from me won't get you far, as its just a starter with 2 lines.

You've not kept up, please use the BL zip file I posted for a Windoze BL disassembler that works.
If you need a linux, I'll send you the modded source file.

Teasers are OK, but I've got a new thread for that, so we can keep this one just about the process of getting a clean disassemble with BL. The discussion about inline parameters is moved.

Michael

[ironmanisanemic]

Search for a call or scall instruction to address 459E

I did and i got a result like this

Code: Select all

Line 2842: 3F3B  EF6006              lcall L459E
	Line 3227: 4381  EF1A02        L4381 lcall L459E
	Line 3230: 438B  EF1002              lcall L459E
	Line 3408: 459E  91209D        L459E orb   REG_9D,#$20
	Line 3408: 459E  91209D        L459E orb   REG_9D,#$20
	Line 3752: 493B  EF60FC              lcall L459E
	Line 3946: 4B68  EF33FA              lcall L459E
	Line 4605: 52E0  EFBBF2              lcall L459E
	Line 5385: 5B62  EF39EA              lcall L459E
	Line 6063: 62DF  EFBCE2              lcall L459E
	Line 6287: 655B  EF40E0              lcall L459E

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

I see this, im following.

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

Do you mean to say

Code: Select all

word 459A
code 459E

Otherwise im lost how you got address 456A and 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 then having put those 2 lines in our dir file, we then look for the next call or scall to 459E. Then find the address of the following instruction (left hand column) and use that address for another word(or byte) directive in your dir file. Then another code directive with the address 4 bytes after the word(or byte) one.

Michael

If i understood where you got those addresses from, i might understand what to do with the next line in the search field.

[mpaton]

Search for a call or scall instruction to address 459E

I did and i got a result like this

Code: Select all

Line 2842: 3F3B  EF6006              lcall L459E
	Line 3227: 4381  EF1A02        L4381 lcall L459E
	Line 3230: 438B  EF1002              lcall L459E
	Line 3408: 459E  91209D        L459E orb   REG_9D,#$20
	Line 3408: 459E  91209D        L459E orb   REG_9D,#$20
	Line 3752: 493B  EF60FC              lcall L459E
	Line 3946: 4B68  EF33FA              lcall L459E
	Line 4605: 52E0  EFBBF2              lcall L459E
	Line 5385: 5B62  EF39EA              lcall L459E
	Line 6063: 62DF  EFBCE2              lcall L459E
	Line 6287: 655B  EF40E0              lcall L459E

That's good. However, we want to see not only the results of the search, but also the lines round about the results of the search.

So rather than a dedicated search program, I'd suggest searching using your editor. I think you said you would use notepad for this, and it might do, but not especially suitable. (You asked also about a hex editor, and no, you don't need one of those)

But taking only the first "catch' of your search, my copy of gvim shows

3F39 D10C jnh L3F47
3F3B EF6006 lcall L459E
3F3E 8E00B6 divu REG_B6,[Zero]
3F41 0098 skip REG_98
3F43 3816D3 jbs REG_16,BIT_00,L3F19

We've said that there are 4 bytes following the call tat are not code, and we must tell BL this with a directive. The first address after the call here is address 3F3E and so

I find out that I misled you earlier, sorry,

we need directives

word 3F3E
code 3F42

or it could be

byte 3F3E
code 3F42

For our current purposes each is equally good, and we will find out what's better later, in the other thread.

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 then having put those 2 lines in our dir file, we then look for the next call or scall to 459E. Then find the address of the following instruction (left hand column) and use that address for another word(or byte) directive in your dir file. Then another code directive with the address 4 bytes after the word(or byte) one.

Michael

If i understood where you got those addresses from, i might understand what to do with the next line in the search field.

I believe you. Sorry, my fault.

Michael

[ironmanisanemic]

That's good. However, we want to see not only the results of the search, but also the lines round about the results of the search.

So rather than a dedicated search program, I'd suggest searching using your editor. I think you said you would use notepad for this, and it might do, but not especially suitable. (You asked also about a hex editor, and no, you don't need one of those)

Im not using a dedicated search program. Im using Notepad++. Its an open source improvement upon notepad, but its geared twards the programmer. It has a pretty awesome search function where it highlights everywhere the parameters are found, and it can also list them out like i had it do.

https://notepad-plus-plus.org/

But taking only the first "catch' of your search, my copy of gvim shows

3F39 D10C jnh L3F47
3F3B EF6006 lcall L459E
3F3E 8E00B6 divu REG_B6,[Zero]
3F41 0098 skip REG_98
3F43 3816D3 jbs REG_16,BIT_00,L3F19

We've said that there are 4 bytes following the call tat are not code, and we must tell BL this with a directive. The first address after the call here is address 3F3E and so

I find out that I misled you earlier, sorry.

no problem, it happens we are all human. But im following along much easier now, and it actually makes sense to a point. How do i know its not code right after the call, or is it always not code?

we need directives

word 3F3E
code 3F42

or it could be

byte 3F3E
code 3F42

For our current purposes each is equally good, and we will find out what's better later, in the other thread.

So i now understand finding the "not code", but how do you determine how many bytes it is? i would assume if its larger than 1 byte, it would be in multiples of 2 correct? So i would be looking for either 1 byte 2 bytes 4 bytes... etc...

[tvrfan]

I sent you 2 emails about it; have you changed emails since the last gmail one I had for you?
And I believe I sent you a PM, but evidently I'm not too competent at PMs.
...<snip> ...
You've not kept up, please use the BL zip file I posted for a Windoze BL disassembler that works.

OK. haven't changed email, will check. I admit I haven't looked recently....(oops).
Good idea to split discussions to keep things clearer - sorry I didn't spot that
Will download the stuff you posted - I think we crossed posts ...
Cgrey - if you have admin privileges, could you move the inline params posts (mainly mine and Jsa I think) - that would be great if you could - thanks.

[mpaton]

no problem, it happens we are all human. But im following along much easier now, and it actually makes sense to a point. How do i know its not code right after the call, or is it always not code?

So i now understand finding the "not code", but how do you determine how many bytes it is? i would assume if its larger than 1 byte, it would be in multiples of 2 correct? So i would be looking for either 1 byte 2 bytes 4 bytes... etc...

After the call to this routine, it's always 4 bytes on not code.

But some functions it could be a different number, and some might be a number that is defined somewhere else.

So yes, it IS important to know how many bytes, and later on t will also be important to know how the bytes are formatted, and what they mean.

But for now, I'm following your suggestion, and I have another thread or 2 for that.

So, good job, you can post your dir file as you go if you like. At some point, we'll merge it with the other volunteers, and we'll have a clean listing file.

Don't post the whole list file, because we can all generate it from the bin and the dir file. But fragments are OK.

Good job!

Michael

[jsa]

This is what you get out of BL if you put nothing in. BL is a disassembler that needs directives in a file of the same name as the bin file, but with the suffix of .dir instead of .bin

That dir file also has fairly strict formatting requirements, in that the directive must start in column 1 and the address which follows must start in column 13. I had thought this was covered in the meagre documentation that comes with BL, but maybe that's been separated out over the years. So what you've got, is just the symbol table of predefined registers, no disassembly at all.

Can you try again with a dir file that contains at least the line

code 2000

Yes there is a meagre help file, but slightly different to the one you posted.

BL crashed out providing no content in the listing, when a dir file was provided.

and btw, these are not equivalents.

Sorry, I'll try to be clearer. I'm trying to convey that x0010/x0011 contains the address 2D03, and SAD told me that address is IPT_HSO_2

And that single line provided is your sardine. Stick that in a dir file, and please try BL again. You should get quite a lot.
I'll reply to the rest of your post separately.
Michael

Ok a directive entry for 2D03.

Lest anyone wonder if I'm going to do any work here, I can tell you that I've just spent a painful 3 hours

Thank you for the time creating a working BL disassembly tool. I don't think anyone will complain if you sit back and let us do the work, after all your putting in the effort to enlighten us, and have put in the effort to learn it already.

So now I do get quite a bit of info with
code 2000

And here is a starter dir file for HHX0a

Ok thanks, so now everything from xC000 is thought of as a word, but could be bytes of data or opcodes.

we need directives

word 3F3E
code 3F42

Ok done

So searching for 459E, a couple of things seemed out of place. A rombnk opcode and an invalid opcode. Are these the sort of things that tip you off to LCALL 459E ?

Add other addresses and rerun. dir attached below.

Now the list has many references to R38 following LCALL 459E.

Following x459E is reference to REG 32 through 34, is this the key to deciding 4 bytes of data follow every LCALL 459E ?
REG_32 & 33 being bytes, and REG_34 being a word ?

I really hope you have the 'lightbulb' moment ..... and answer is in the 8096 docs

Thank you, I'm sure I'll cotton on eventually.

It is a big doc so may take a while to read. I'll leave the rest until transfer to the new thread.

[jsa]

The HHX0a.jc output file from BL is worth a look.

Code: Select all

**** References to: L459E
    3F3B-CA     4381-CA     438B-CA     493B-CA     4945-CA     4B68-CA 
    52E0-CA     52EA-CA     5B62-CA     5B6C-CA     62DF-CA     655B-CA 

[mpaton]

So searching for 459E, a couple of things seemed out of place. A rombnk opcode and an invalid opcode. Are these the sort of things that tip you off to LCALL 459E ?

Those are, I'd say clues, to something not being right. And those clues do need to be fullowed up.

In the case of 459E however, I got there because I know that there will always be 1D and 2D lookup code, so very early on, I go looking for it.

I find it by the code signature for the interpolation match, see other thread as it develops.

Then I look to see if its parameters are inline, or passed in registers. Inline involved stack manipulation to get the parameters.

If the parameters are inline, then I know that I will have to tell BL that there are 4 byes of data after the call, and then I'll have tell it that there is code after the 4 bytes. So for each call, I need to add 2 lines to the dir file.

Ironmanisanemic is making progress with the byte sized 1D lookups.

John, would you like to make a dir file that deals with the word sized 1D lookups.

These are any places that call or scall to

0x4614
0x4619
0x461C
0x461F

For each call, add 2 lines to your dirfile, and then post it here when done.

Thanks,

Michael

[ironmanisanemic]

So i believe i have found all of the references given so far. mpaton, can you please check my work? i have attached my Dir file.

Thanks

[jsa]

John, would you like to make a dir file that deals with the word sized 1D lookups.

Michael

Will do.

[mpaton]

So i believe i have found all of the references given so far. mpaton, can you please check my work? i have attached my Dir file.

Thanks

That's a great effort. I think you've got almost all of them.

But have a look at addresses

58A0
58B0
62F7
6628
6905

and see what you think.

You haven't been careless here, it's something that can happen that we have to watch out for.

See if you can work out what it is and let us know.

Now I need to work out the next things I want to see in a dir file

jsa, you're off the hook for the word size 1D lookups, ironman's got them all.

So next, it should be understanding interpolation math and code, and then we can look at a 2D table example, with some Ford ROM and RAM addressing conventions,

Michael

[jsa]

But have a look at addresses

58A0
58B0
62F7
6628
6905

So its a knock on from words and bytes being interpreted as code until caught by additions in the directive.

jsa, you're off the hook for the word size 1D lookups, ironman's got them all.

Ok cool. Have had a look and see R32 to R34 & R38 feature heavily after the referenced address in each case.

[decipha]

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

I said that ?