|
terminator
|
 |
« on: February 07, 2013, 02:30:08 PM »
|
|
|
I know the way to identify Prokanal bits is dissasembling, but I've just started to learn it. So maybe there is an easier way to identify it?
And if 2 different files have the same OS, will CDKAT, CDHSH etc have the same offsets too?
Thanx
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #1 on: February 09, 2013, 01:17:48 AM »
|
|
|
I know the way to identify Prokanal bits is dissasembling, but I've just started to learn it. So maybe there is an easier way to identify it?
And if 2 different files have the same OS, will CDKAT, CDHSH etc have the same offsets too?
Thanx
For most files Prokonal bits will be somewhere in 18xxx zone. You can try to compare your file to similar. |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #2 on: February 09, 2013, 01:35:57 PM »
|
|
|
I have seen where the order of the bits are different from version to version. it becomes a guessing game/ trial and error to find the CW you're looking for.
Is there anyway to identify them in disassembly? Or similar to the DTC table / error class lookup mentioned else on this forum?
|
|
|
|
|
Logged
|
|
|
|
|
masterj
|
|
« Reply #3 on: February 09, 2013, 01:41:25 PM »
|
|
|
I have seen where the order of the bits are different from version to version. it becomes a guessing game/ trial and error to find the CW you're looking for.
Is there anyway to identify them in disassembly? Or similar to the DTC table / error class lookup mentioned else on this forum?
I have created definition files for ASM map finder... Look for topic on this forum somewhere  |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #4 on: February 10, 2013, 11:22:48 AM »
|
|
|
These are 1x1 8bit Codewords that are not referenced directly in ASM code. So, I highly doubt the ASM map finder can reliably identify these.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #5 on: February 10, 2013, 12:12:02 PM »
|
|
|
These are 1x1 8bit Codewords that are not referenced directly in ASM code. So, I highly doubt the ASM map finder can reliably identify these.
Yes they are. The Prokon bits are referenced directly. Relevent bits are checked and then condition bits (i.e. B_cdlash) are set or cleared which are then referenced in the routines that they influence. |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #6 on: February 10, 2013, 02:53:06 PM »
|
|
|
Please show me an example of b_cdtes being set in an ASM code. (copy/paste)
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #7 on: February 10, 2013, 03:32:10 PM »
|
|
|
extp #206h, #1
movbz r4, CDTES
and r4, #1
jmpr cc_Z, loc_800472
mov r4, #2000h
or prokonal_w, r4
jmpr cc_UC, loc_80047A
mov r4, #0DFFFh
and prokonal_w, r4
B_cdtes is bit 13 in the word variable labeled prokonal_w above. |
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #8 on: February 10, 2013, 04:38:25 PM »
|
|
|
Looks like they changed how those are set in the NA AWP files. There's nothing like that in the 032HS/032LP files. At the beginning of DTEV I see this: mov [-r0], r9
mov [-r0], r8
mov [-r0], r7
mov [-r0], r6
sub r0, #14h
mov [r0], word_3839FE
mov r4, word_380BEA
and r4, #2000h
jmpr cc_NZ, loc_8A6F7A
looks familiar. Could word_380BEA hold b_cdtes? A Jump to xref to operand... does NOT show any writes to it though. |
|
|
|
« Last Edit: February 10, 2013, 05:04:19 PM by elRey »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #9 on: February 10, 2013, 05:17:14 PM »
|
|
|
Ands and ors right?
|
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #10 on: February 10, 2013, 05:24:55 PM »
|
|
|
word_380BEA is looking more like your prokonal_w. However, there's no and/or word_380BEA in the disassembly.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #11 on: February 10, 2013, 05:32:49 PM »
|
|
|
Screenshot of xref window?
|
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #12 on: February 10, 2013, 05:33:38 PM »
|
|
|
one minute
|
|
|
|
|
Logged
|
|
|
|
|
elRey
|
|
« Reply #13 on: February 10, 2013, 05:35:01 PM »
|
|
|
xref window for word_380BEA
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #14 on: February 10, 2013, 06:00:00 PM »
|
|
|
Jump to 0x800000 and check that the code is disassembled properly.
That should be the start of PROKONAL.
|
|
|
|
|
Logged
|
|
|
|
|
