Have a couple of Diagnostic Data Stream questions (ANHT & AUJP). Looking at the hacks, addresses of data output in the stream have 3 different methods of their being specified in the code (zzz = remainder of address):
.word 0x3128 ; 39. SA + BASE (Relative to TDC, MSB)
.word 0x3129 ; 40. SA + BASE (Relative to TDC, LSB)
So the questions:
1. Why the different address specifications for 1-byte versus 2-byte Memory Mapped Data (0x0zzz versus 0x3zzz)
2. What is the starting address of Memory Mapped data items in the BIN when viewed with a hex editor. My confusion here is that the AUJP code starts at 0x3000, but the address of Spark-TDC in the example above at 0x3128 is NOT 128 bytes into the code. It's somewhere else, but where?
These are not three different methods but show data from three different address ranges.
1) The size of the data is not dictating the addresses, it just happens to be that in the examples you cited they are from different address ranges.
2) A bin file typically only is comprised of the data in the rom of the ecu (i.e. from 0x8000 onwards in the example you have). Sometimes a bin file will contain null data that is 'padding out' the bin file so that the bin file addresses will match the rom addresses.
You will not find the spark value in either type of bin file as this data is stored in the volatile memory of a custom chip.
i'll explain your third example, since it can be confusing:
the 3128 and 3129 address doesn't actually exist. in older GM code, having a location that transmits over ALDL start as 3xxx is actually a flag for the algorithm to send the value as a double-byte. this is done due to the time between one byte sending and the other following it having the potential to give false information.
if you have a 16-bit counter and the LSB is close to rolling over when the MSB gets sent, MSB could show 5, with LSB of 253, but when the LSB transmits, it rolled over to 9, so now an incorrect value of 05 and 09 get sent. the code basically buffers to grab the MSB and LSB at the same time, so that even while the value is technically one transmit period out of date, it will still be very accurate.
05FD <-slightly out of date but very close to correct
0609 <-actual value
0509 <- what could result from lack of buffering.
so, there is that little bugget of information. you'll notice the PROM ID doesn't use this method of MSB+LSB buffering, it doesn't need it since PROM ID shouldn't change at any time.
to get the actual address of a buffered value, just remove the leading 3 from the address. actual locations of 128 and 129 in this instance.
due to the way the older code works, some of the registers in the 3Fxx range aren't able to be read directly(or at least, i don't think they would) over ALDL, would have to be buffered into a RAM byte first. later code got away from using 3xxx as a flag and instead used FFFF for an indicator that a byte needed buffered, followed by the actual address of the MSB. those, you can directly read registers in and a lot of calibrations do this already. reference period seems to be a common one.
since i'm looking at it: AUJP actually starts at 8000(all 32KB BINs do), below that is all RAM, registers and otherwise non-PROM locations.
robertisaar wrote:i'll explain your third example, since it can be confusing:
the 3128 and 3129 address doesn't actually exist. in older GM code, having a location that transmits over ALDL start as 3xxx is actually a flag for the algorithm to send the value as a double-byte. this is done due to the time between one byte sending and the other following it having the potential to give false information.
In the AUJP Transmit interrupt handler there is code to 'Check for double byte' and there a '2nd byte transmit waiting' flag. Is this possibly related to the 0x3000 addresses?
i'm not as familiar with $8D as some other masks, but very likely.
Decided to do some deeper code review. In AUJP $8D, seems a request by the ALDL device for ALDL Diagnostic Data (Msg Header = 0xF4) to an address in the range 0x3000-0x6FFF in a ROM or RAM Table ALWAYS results in a 2-byte xmit. Bingo! Not so if the xmit is to an address in a RAM Buffer. There, a 1-byte xmit alawys occurs, as it does when outside the above address range. Bingo again! That explains why 2-byte and 1-byte values are treated differntly.
For a 2-byte xmit, byte 2 of 2 is saved, a flag is set to notify the xmit handler there is a byte waiting, and byte 1 is transmitted. Upon reentry to the xmit handler the byte-waiting flag is checked, and if set, byte 2 is retrieved, the byte-waiting flag is cleared and byte 2 is transmitted.
Guess that explains why all Mode 1 values, which are in a ROM Table (Memory Flag = 0x80), are declared in the Table as ".word" even if the value is a single byte. Now makes sense & thanks.
