Pages: [1]
Author Topic: Analyze C16x Unkown Function  (Read 6180 times)
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« on: August 25, 2020, 12:17:03 AM »

Hi Guys,
I recently work on some c166 bin file.
And I am suspicious to the one of them.
Does anyone know what is this? What does this do?
This function repeated in all of my dump file. It seems this is a standard function.

Code:
sub_37C2:
mov     r5, r4
shr       r5, #14
shl       r5, #1
mov     r5, [r5+0FE00h]    ; ==> Or DPP0
bmov   r4.14, r5.0
bmov   r4.15, r5.1
shr      r5, #2
rets
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #1 on: August 25, 2020, 01:08:06 AM »

Quick glance, you pass a DPP encoded address to it (where the first two bits specify the page from the corresponding DPP register), you get a full segment plus offset 3 byte address on r5/r4.
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #2 on: August 25, 2020, 01:57:15 AM »

Near -> far address converter.
Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #3 on: August 25, 2020, 02:46:09 AM »

Quick glance, you pass a DPP encoded address to it (where the first two bits specify the page from the corresponding DPP register), you get a full segment plus offset 3 byte address on r5/r4.

Thanks
So, you say i must add 3 byte(that calculated from r4/r5) to DPP0?

This piece of code below shown how sub_37C2 invoked:
Code:
loc_1892: 
ROM:00001892                 mov     r9, #4
ROM:00001894                 add     r9, r0
ROM:00001896                 mov     r12, #0FFFFh
ROM:0000189A                 mov     r4, r9
ROM:0000189C                 add     r4, #2
ROM:0000189E                 calls   0, sub_37C2
ROM:000018A2                 mov     r13, r4

According to this code r4 must be r0+6.
And when i placement this value to sub_37C2 instead of r5, this line of code will be :
Code:
mov     r5, [r0+6+0FE00h]

So. how I can calculate this far address? It seems this is pointing to an address of Stack.
Logged
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #4 on: August 25, 2020, 10:38:21 PM »

No one ?
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #5 on: August 26, 2020, 12:10:34 AM »

After that call of yours you get in r4/r5 the far address of the function call stack (r0) shifted by 6 positions. There is no FE00 in this address. It is done in a slightly contrived way I see, and I am unsure myself what the purpose of this code is (getting a full far address of the call stack).

I also think that the suggested naming of near and far addresses is a bit unfortunate. I'd say near is an offset defined address within the same segment (as in for example jmpa), and far is any address within the address space, and this can be either page addressed (extp or through dpp), or segment addressed (exts).
Logged
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #6 on: August 26, 2020, 12:59:09 AM »

After that call of yours you get in r4/r5 the far address of the function call stack (r0) shifted by 6 positions. There is no FE00 in this address. It is done in a slightly contrived way I see, and I am unsure myself what the purpose of this code is (getting a full far address of the call stack).

I also think that the suggested naming of near and far addresses is a bit unfortunate. I'd say near is an offset defined address within the same segment (as in for example jmpa), and far is any address within the address space, and this can be either page addressed (extp or through dpp), or segment addressed (exts).

It is possible my question is imperfect. So I put here my complete question that I ask in reverse engineer. I will be thankful if you glance that.
https://reverseengineering.stackexchange.com/questions/25747/c166-c167-code-analyzing
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #7 on: August 26, 2020, 09:09:35 AM »

I really do not see an actual question there, no wonder noone answers. What do you mean you can't convert it to C code? You got it quite right with temp = *cBuffer++. Your problem is that the asm code accesses array data on the call stack, rather than in RAM, the code you quote simply tries to deal with accessing it there. So perhaps it's a clear case of call by value rather than call by reference for array parameters...?
Logged
nyet
Administrator
Hero Member
*****

Karma: +604/-166
Offline Offline

Posts: 12233


WWW
« Reply #8 on: August 26, 2020, 09:19:04 AM »

I also think that the suggested naming of near and far addresses is a bit unfortunate. I'd say near is an offset defined address within the same segment (as in for example jmpa), and far is any address within the address space, and this can be either page addressed (extp or through dpp), or segment addressed (exts).

Agreed, but in this case it seems to me the stack addressing is via a "near" pointer (address within same segment) and the return value is an absolute address (will avoid using the term "far"). That said, I may have completely misconstrued the ASM, I'm no expert.
« Last Edit: August 26, 2020, 09:20:50 AM by nyet » Logged

ME7.1 tuning guide (READ FIRST)
ECUx Plot
ME7Sum checksum checker/corrrector for ME7.x

Please do not ask me for tunes. I'm here to help people make their own.

Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your experience.
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #9 on: August 27, 2020, 12:32:51 AM »

I really do not see an actual question there, no wonder noone answers. What do you mean you can't convert it to C code? You got it quite right with temp = *cBuffer++. Your problem is that the asm code accesses array data on the call stack, rather than in RAM, the code you quote simply tries to deal with accessing it there. So perhaps it's a clear case of call by value rather than call by reference for array parameters...?

Yes, you right.
Actually I try to find the first address of this array. But I can't calculate this address.  How I can calculate actual address till I can get the right value.
Please pay attention to the picture shown below:




According to the picture I deeply feel I am wrong Smiley
totally i wanna to calculate actual address of an array especially in this case.

Best regards. 
Logged
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #10 on: August 30, 2020, 10:17:17 PM »

Yes, you right.
Actually I try to find the first address of this array. But I can't calculate this address.  How I can calculate actual address till I can get the right value.
Please pay attention to the picture shown below:




According to the picture I deeply feel I am wrong Smiley
totally i wanna to calculate actual address of an array especially in this case.

Best regards. 

Here I think I have some wrong in base concepts,
I check once again.
In the code shown below as you have seen, `r4` is input argument for `sub_37C2` where `r4` is `r0 + 6`. And probably this function return `r4` and `r5`.
So, we have a 32-bit address after `sub_37C2`.
Code:
loc_1892:
mov     r9, #4
add     r9, r0
mov     r12, #0FFFFh
mov     r4, r9
add     r4, #2
calls   0, sub_37C2
mov     r13, r4
mov     r14, r5
mov     r15, #6
calls   0, CRC_16_Calculate
mov     word_E7F8, r4
mov     r12, #0FFFFh
mov     r4, #4
add     r4, r0
calls   0, sub_37C2
mov     r13, r4
mov     r14, r5
mov     r15, #6
calls   0, CRC_16_Calculate
mov     word_E7FA, r4

OK. In `sub_37C2`we have:

Code:
sub_37C2:
mov     r5, r4
shr     r5, #14
shl     r5, #1
mov     r5, [r5+0FE00h] ; DPP0
bmov    r4.14, r5.0
bmov    r4.15, r5.1
shr     r5, #2
rets

Suppose we know what this function does.(Convert near address to far)
But, There are some basically question.
Why `r5` shifted  14 times to right after that 1 times to left? Does this have a specific purpose?

In line `mov     r5, [r5+0FE00h] ; DPP0`, what is the `r5` after execute? DPP0 is 1D.

After that, we have `CRC_16_Calculate` function that used `r4,r5`(as `r13` and `r14`) for input argument and use in sub function that shown below:

Code:
loc_29A4:
mov     r4, r13
mov     r5, r14
add     r13, #1
addc    r14, #0
exts    r5, #1
movb    rl3, [r4]
movbz   r7, rl3
movb    rl6, #0


Too000 weird.
Why `r13` increment but `r4` is used as the address?
Can anyone help me until I find my answer?

Thanks people.
Logged
woj
Hero Member
*****

Karma: +41/-3
Offline Offline

Posts: 500


« Reply #11 on: September 01, 2020, 01:32:37 AM »

You should really get back to the CPU documentation and understand the different addressing modes, DPPs, and indirect addressing. I think you car hunting down something that you should not be hunting Wink
Logged
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #12 on: September 01, 2020, 04:14:00 AM »

You should really get back to the CPU documentation and understand the different addressing modes, DPPs, and indirect addressing. I think you car hunting down something that you should not be hunting Wink
Yes. I think you're right. Undecided
Can you describe it for me(and other noobs) in nutshell? Huh (like some people in stackoverflow  Tongue )
excuse for eating you time Smiley
Logged
unicornux
Full Member
***

Karma: +2/-6
Offline Offline

Posts: 83


« Reply #13 on: September 14, 2020, 11:01:24 PM »


https://reverseengineering.stackexchange.com/questions/25824/the-c166-family-code-meaning
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Page created in 0.022 seconds with 16 queries. (Pretty URLs adds 0s, 0q)