Questions about understanding tables in source code

Attachment 16112I am working on disassembling a $3E bin, and realized, even using the .XDF that 1project2many provided as a cheat sheet(THANK YOU!), I just don't quite understand tables. Constants and flags are not much of a problem... but tables...

I can "see" the tables, roughly speaking when looking at the bin in tuner pro 2D viewer, so I can see each bump in the main spark table, that starts at 0x003D. Counting the "bumps" its clear the table is 14 rows, and by carefully scrolling left to right, I can see it is 17 bytes/columns by counting a few of the valley to valley distances in bytes.

So, I have a 14x17 table which is consistent with the $3E.xdf... What I am having a hard time with is column and row labels, and the scale of each. From the xdf, its clear its that the Rows are RPM, and the columns is Load(MAP KpA), but how does one determine this, and furthermore what is the scale of the row and column values? Is there some value preceeding or following that indicates that? Or do I have travel elsewhere in the disassembly to find some code?

Thank you for the help!

Generally, although it's not a hard rule, calibration data such as tables, constants, and scalars are found at the beginning of the file before the code area. It's sometimes easy to visually identify tables due to patterns created by the data. Once a table is located I find that reading code is the best way to work out details for the table.

It's important to know that looking at addresses or locations in a data viewer or hex editor can be a little tricky. When these files are loaded in the computer the data can be offset from the address shown in the editor. The best analogy I can think of is to compare looking at the data in a hex viewer to finding information in a book that's on a shelf with other books. In order to pinpoint the location of the information you need to know which book and which page to reference. In this analogy the hex editor or data viewer only reports page numbers and leaves you to figure out which book (offset) to use.

This post from a thread about trying to use a four cylinder ecm with TBI may have a few bits and pieces of useful information. There's actually an uncommented disassembly of ADDT which might save some time. In many places sections of the code that look up tables or data have been matched to the calibration data and the result is a better organized file.

The process of trying to figure out what the table is for and how its indexed takes some time, especially in the beginning. Code will usually reference the location at beginning of the table, then it will pass that address plus the address of two or three important variables to a table subroutine. The table routine will use the additional variables to figure out what cell in the table to reference. The routine may also do some blending with surrounding cells. Then the routine passes the result back to the code so program flow will continue. In order to determine table function and axes you need to figure out what additional variables are being passed to the routine and what is done with the answer. In the beginning it can help to find disassemblies that are trusted then match of relevant sections of code to your project. It also helps to have files such as the .ds files.

There are some folks here that are good with code, then there are a few hacks like myself that toy around with it. Feel free to dig deeper if that's your interest.

Thank you for the reply! I realized the more I ask the more I don’t know....

I am using Ida Pro, so it gives a pretty good code or data reference and points to sub routines calling on the data.

One thing seems to escape me at the moment and I have not quite bridged the gap... Based on mode 1 data stream, I have the order in which data stream bytes relate to information stored in ram/rom. Where I don’t quite get the next step is linking those bytes of ALDL to program addresses? Do I look for places where MSB and LSB of prom ID are used? I imagine it’s only called for a very few routines? So I could “guess” what is the mode 1 byte order in the disassembly, some 63 bytes, by looking at what routines call the PROM ID bytes? $C000 and $C001 IIRC?

It can be very helpful to look for writes to or reads from the ALDL addresses. Although the ALDL display order does not necessarily reflect the order the variables are encountered in code. Also not that some of the variables are found in locations that actually refer to hardware, not RAM. It can also help to look at other ecm's. The ignition code is a great example. The code in a P4 usually references $3FC0 to get the time between reference pulses, essentially the RPM value. Finding this code then pattern matching with another disassembly can save some time.

Quote:

---

Originally Posted by cruiserbrett

Attachment 16112I am working on disassembling a $3E bin, and realized, even using the .XDF that 1project2many provided as a cheat sheet(THANK YOU!), I just don't quite understand tables. Constants and flags are not much of a problem... but tables...

I can "see" the tables, roughly speaking when looking at the bin in tuner pro 2D viewer, so I can see each bump in the main spark table, that starts at 0x003D. Counting the "bumps" its clear the table is 14 rows, and by carefully scrolling left to right, I can see it is 17 bytes/columns by counting a few of the valley to valley distances in bytes.

So, I have a 14x17 table which is consistent with the $3E.xdf... What I am having a hard time with is column and row labels, and the scale of each. From the xdf, its clear its that the Rows are RPM, and the columns is Load(MAP KpA), but how does one determine this, and furthermore what is the scale of the row and column values? Is there some value preceeding or following that indicates that? Or do I have travel elsewhere in the disassembly to find some code?

Thank you for the help!

---

Did you ever get a working $3E.xdf put together for this? I would be interested in getting a copy of that...

I did not completely sort out an .xdf, and definitely didn’t test anything on the ecm bench. I wouldn’t mind revisiting this in the future but not sure when that will be.

Tunercat does have a definition file IIRC. Might be an option if something is needed quickly.