@Dschultz , you're gonna wanna see this
So I got to thinking, $AC supports LIDs, CIDs, and Memory Addresses. $AC supports LIDs. But that doesn't make sense, as the only normal LID is the CUID, which is constant. So why would you ever need to create a LID of VARIABLES with a constant? Point being, you wouldn't. Sooooo, I got to thinking, $AC creates a LID. $AC can also creat e a LID with a LID. And so that made me think "You should be able to create a second LID using the contents of the first LID to double the size of the final LID." After verifying my assumptions within the code, I went out and tested it out. And here's what I found;
Findings;
- $AC LID can be extended by at LEAST FIVE extra LIDs!
- $AC LIDs have to be restarted from LID 81, no known way to adjust individual LIDs unfortunately.
- Anything larger than 61 addresses doesn't work yet, Nisprog throws some errors. But inside the code, it does a check with 0x3D (61 decimal), so I'm guessing that it means 61 addresses is the limit! Which hey, is slightlyyyy more than 12, am I right?
Code:
Formatting: $AC NewLID 01 OldLID
Example: $AC 82 01 81 would carry over LID 81's values into LID 82. Then $AC 83 01 82 to carry over those values into LID 83! Continue until LID 86 or 61 total addresses.
----
#LID 81 Full $AC Command: (Only here to ensure proper understanding)
0xAC 0x81 0x83 0xFF 0xFF 0x00 0x00 0x83 0xFF 0xFF 0x00 0x01 0x83 0xFF 0xFF 0x00 0x02 0x83 0xFF 0xFF 0x00 0x03 0x83 0xFF 0xFF 0x00 0x04 0x83 0xFF 0xFF 0x00 0x05 0x83 0xFF 0xFF 0x00 0x06 0x83 0xFF 0xFF 0x00 0x07 0x83 0xFF 0xFF 0x00 0x08 0x83 0xFF 0xFF 0x00 0x09 0x83 0xFF 0xFF 0x00 0x0A 0x83 0xFF 0xFF 0x00 0x0B
#LID 81 $21 Response
0x61 0x81 0x0A 0xB7 0xEC 0xED 0xB4 0x0D 0x39 0x03 0x2A 0xBF 0xCF 0x19
----
----
#LID 82 Full $AC Command:
0xAC 0x82 0x01 0x81 0x83 0xFF 0xFF 0x00 0x0C 0x83 0xFF 0xFF 0x00 0x0D 0x83 0xFF 0xFF 0x00 0x0E 0x83 0xFF 0xFF 0x00 0x0F 0x83 0xFF 0xFF 0x00 0x10 0x83 0xFF 0xFF 0x00 0x11 0x83 0xFF 0xFF 0x00 0x12 0x83 0xFF 0xFF 0x00 0x13 0x83 0xFF 0xFF 0x00 0x14 0x83 0xFF 0xFF 0x00 0x15 0x83 0xFF 0xFF 0x00 0x16
#LID 82 Full $21 Response:
0x61 0x82 0x0A 0xB7 0xEC 0xED 0xB4 0x0D 0x39 0x03 0x2A 0xBF 0xCF 0x19 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA
----
----
#LID 83 Full $AC Command:
0xAC 0x83 0x01 0x82 0x83 0xFF 0xFF 0x00 0x0C 0x83 0xFF 0xFF 0x00 0x0D 0x83 0xFF 0xFF 0x00 0x0E 0x83 0xFF 0xFF 0x00 0x0F 0x83 0xFF 0xFF 0x00 0x10 0x83 0xFF 0xFF 0x00 0x11 0x83 0xFF 0xFF 0x00 0x12 0x83 0xFF 0xFF 0x00 0x13 0x83 0xFF 0xFF 0x00 0x14 0x83 0xFF 0xFF 0x00 0x15 0x83 0xFF 0xFF 0x00 0x16
#LID 83 Full $21 Response:
0x61 0x83 0x0A 0xB7 0xEC 0xED 0xB4 0x0D 0x39 0x03 0x2A 0xBF 0xCF 0x19 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA
----
----
#LID 84 Full $AC Command:
0xAC 0x84 0x01 0x83 0x83 0xFF 0xFF 0x00 0x0C 0x83 0xFF 0xFF 0x00 0x0D 0x83 0xFF 0xFF 0x00 0x0E 0x83 0xFF 0xFF 0x00 0x0F 0x83 0xFF 0xFF 0x00 0x10 0x83 0xFF 0xFF 0x00 0x11 0x83 0xFF 0xFF 0x00 0x12 0x83 0xFF 0xFF 0x00 0x13 0x83 0xFF 0xFF 0x00 0x14 0x83 0xFF 0xFF 0x00 0x15 0x83 0xFF 0xFF 0x00 0x16
#LID 84 Full $21 Response:
0x61 0x84 0x0A 0xB7 0xEC 0xED 0xB4 0x0D 0x39 0x03 0x2A 0xBF 0xCF 0x19 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA
----
----
#LID 85 Full $AC Command:
0xAC 0x85 0x01 0x84 0x83 0xFF 0xFF 0x00 0x0C 0x83 0xFF 0xFF 0x00 0x0D 0x83 0xFF 0xFF 0x00 0x0E 0x83 0xFF 0xFF 0x00 0x0F 0x83 0xFF 0xFF 0x00 0x10 0x83 0xFF 0xFF 0x00 0x11 0x83 0xFF 0xFF 0x00 0x12 0x83 0xFF 0xFF 0x00 0x13 0x83 0xFF 0xFF 0x00 0x14 0x83 0xFF 0xFF 0x00 0x15 0x83 0xFF 0xFF 0x00 0x16
#LID 85 Full $21 Response:
0x61 0x85 0x0A 0xB7 0xEC 0xED 0xB4 0x0D 0x39 0x03 0x2A 0xBF 0xCF 0x19 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA
----
----
#LID 86 Full $AC Command: (notice the lone 0x83 on the end? Just forgot to delete it when adjusting the command file haha)
0xAC 0x86 0x01 0x85 0x83 0xFF 0xFF 0x00 0x0C 0x83 0xFF 0xFF 0x00 0x0D 0x83 0xFF 0xFF 0x00 0x0E 0x83 0xFF 0xFF 0x00 0x0F 0x83
#LID 86 Full $21 Response (Total = 61 Data Bytes)
0x61 0x86 0x0A 0xB7 0xEC 0xED 0xB4 0x0D 0x39 0x03 0x2A 0xBF 0xCF 0x19 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D 0xEF 0xEC 0xA3 0x3A 0x4B 0xBA 0x3A 0x19 0xE2 0xDA 0x7D
----
So as you can see, this is MASSIVE for K-line tuning! I put the formatting on the communication protocols page as well. But looks like there WAS a way to utilize the full limited packet size after all! Saves me from having to try implementing custom code that will be ROM specific! But now, everyone can benefit with completely stock ROMs!
I'm just really glad I ended up looking into KWP logic, because I cannot stand being limited with what I can log. But this effectively means that K-line logging is now a FULLY viable tuning tool! I mean, 12 data bytes vs 61 data bytes, that's not even CLOSE. Absolute insanity that we've been stuck with 12 when 61 has been possible the entire time. To be fair, $AC logic isn't exactly the most basic thing (at a first glance). So it's not surprising that no one figured it out before. And it's not even apparent until you connect the dots with "$AC supports LIDs. $AC creates DLIDs. That must mean $AC can add previously created DLIDs to the current DLID!", as the LID logic doesn't really show much without having external information.