New help finding some maps in two ROMS
Sep 21, 2009, 01:36 PM
#16
No, I mean #2 and #4 appear to reference the exact same tables as #1 and #3 (ie. same ROM addresses). It's kind of a messed up situation, and will probably force me to actually read the code for sub_CC6 and sub_C28 and figure out how the heck that table gets parsed.
I could be misreading this, though, which is why I'd love someone else to take a quick peek. l2r99gst, if you're reading this, are you still even remotely interested in 96940011?
Also, it looks like I might have been wrong about the Engine Speed axis for Decel Fuel Cut Retard; the address is actually 5a22, not 594e. (Not that it matters, unless you're planning on rescaling it, since the values are the same, but better to be accurate.) Again, I've re-edited my post to reflect the correct value.
I could be misreading this, though, which is why I'd love someone else to take a quick peek. l2r99gst, if you're reading this, are you still even remotely interested in 96940011?
Also, it looks like I might have been wrong about the Engine Speed axis for Decel Fuel Cut Retard; the address is actually 5a22, not 594e. (Not that it matters, unless you're planning on rescaling it, since the values are the same, but better to be accurate.) Again, I've re-edited my post to reflect the correct value.
On 96420008, the 4 table all have different addresses. I really need to see all four table in the 0011 ROM as I want to edit them.
Last edited by Evo_Jay; Sep 21, 2009 at 01:43 PM.
Sep 21, 2009, 01:46 PM
#17
(In the actual code, you don't directly reference the address 3972, to use 96940011's table #1 as an example. The code actually references, in this case, 396c, which provides a bit of header data, including the memory address to use as a lookup reference; then, the table data itself resides following that, at address 3972. In the case of tables #2 and #4, there's a table header, but no data; the space that would be occupied by the table data is occupied by the next table's header instead.)
96940011.
Sep 21, 2009, 01:53 PM
#18
Here's a snippet of what I'm talking about:
See how at byte_396C, the table actually starts off with the header, but at 3972, the actual table data starts. Not sure if that makes it any clearer, or just muddies the waters. 
Code:
396C byte_396C: .byte 2 ! DATA XREF: seg000:off_1AAF8vo 396C ! Decel Fuel Cut Delay #1 396D .byte 0 396E .long unk_FFFF8880 3972 .byte 7,0x28,0x41,0x55,0x55,0x55,0x55 3979 .byte 0xFF 397A byte_397A: .byte 2 ! DATA XREF: seg000:off_1AB00vo 397A ! Decel Fuel Cut Delay #2 397B .byte 0 397C .long unk_FFFF8880 3980 byte_3980: .byte 2 ! DATA XREF: seg000:off_1AAF4vo 3980 ! Decel Fuel Cut Delay #3 3981 .byte 0 3982 .long unk_FFFF8880 3986 .byte 0x24,0x41,0x5A,0x73,0x73,0x73,0x73 398D .byte 0xFF 398E byte_398E: .byte 2 ! DATA XREF: seg000:off_1AAFCvo 398E ! Decel Fuel Cut Delay #4 398F .byte 0 3990 .long unk_FFFF8880 3994 .byte 2 3995 .byte 0 3996 .long unk_FFFF8884 399A .byte 2 399B .byte 0 399C .long unk_FFFF8884 39A0 byte_39A0: .byte 2 ! DATA XREF: sub_1A3D8:off_1A418vo 39A0 ! Decel Fuel Cut Retard 39A1 .byte 0 39A2 .long unk_FFFF8880 39A6 .byte 0,0,0xA,0xA,0xA,0xA,0xA,0xA,0xA,0xA 39B0 .byte 2 39B1 .byte 0 39B2 .long unk_FFFF8884
Sep 21, 2009, 02:31 PM
#19
Unfortunately, they don't actually exist as separate tables. I'm not sure how to explain it better than that; there's actual table data for #1 and #3, but #2 and #4 are basically "stubs"; there's actually no data to edit.
(In the actual code, you don't directly reference the address 3972, to use 96940011's table #1 as an example. The code actually references, in this case, 396c, which provides a bit of header data, including the memory address to use as a lookup reference; then, the table data itself resides following that, at address 3972. In the case of tables #2 and #4, there's a table header, but no data; the space that would be occupied by the table data is occupied by the next table's header instead.)
96940011.
(In the actual code, you don't directly reference the address 3972, to use 96940011's table #1 as an example. The code actually references, in this case, 396c, which provides a bit of header data, including the memory address to use as a lookup reference; then, the table data itself resides following that, at address 3972. In the case of tables #2 and #4, there's a table header, but no data; the space that would be occupied by the table data is occupied by the next table's header instead.)
96940011.
Sep 21, 2009, 02:33 PM
#20
Here's a snippet of what I'm talking about:
See how at byte_396C, the table actually starts off with the header, but at 3972, the actual table data starts. Not sure if that makes it any clearer, or just muddies the waters.
Code:
396C byte_396C: .byte 2 ! DATA XREF: seg000:off_1AAF8vo 396C ! Decel Fuel Cut Delay #1 396D .byte 0 396E .long unk_FFFF8880 3972 .byte 7,0x28,0x41,0x55,0x55,0x55,0x55 3979 .byte 0xFF 397A byte_397A: .byte 2 ! DATA XREF: seg000:off_1AB00vo 397A ! Decel Fuel Cut Delay #2 397B .byte 0 397C .long unk_FFFF8880 3980 byte_3980: .byte 2 ! DATA XREF: seg000:off_1AAF4vo 3980 ! Decel Fuel Cut Delay #3 3981 .byte 0 3982 .long unk_FFFF8880 3986 .byte 0x24,0x41,0x5A,0x73,0x73,0x73,0x73 398D .byte 0xFF 398E byte_398E: .byte 2 ! DATA XREF: seg000:off_1AAFCvo 398E ! Decel Fuel Cut Delay #4 398F .byte 0 3990 .long unk_FFFF8880 3994 .byte 2 3995 .byte 0 3996 .long unk_FFFF8884 399A .byte 2 399B .byte 0 399C .long unk_FFFF8884 39A0 byte_39A0: .byte 2 ! DATA XREF: sub_1A3D8:off_1A418vo 39A0 ! Decel Fuel Cut Retard 39A1 .byte 0 39A2 .long unk_FFFF8880 39A6 .byte 0,0,0xA,0xA,0xA,0xA,0xA,0xA,0xA,0xA 39B0 .byte 2 39B1 .byte 0 39B2 .long unk_FFFF8884
But no, I can't read or do code, but I can see what your saying. It actually help me understand stuff like that more.
thx
Last edited by Evo_Jay; Sep 21, 2009 at 02:36 PM.
Thread
Thread Starter
Forum
Replies
Last Post
mrfred
ECU Flash
268
Feb 26, 2022 06:16 PM