CSL '0401' Program Binary Disassembly Notes

[karter16]

Really light on details of the Jag sadly.

Here's what it looks like (not much has changed in the past four years except for stable mates): https://youtu.be/UGBo-wUDK4g

And a few details here, although I wasn't as great about updates. Not having the details was part of what motivated me to make this wagon build thread: https://www.jaguarforums.com/forum/x...roject-184994/

Absolutely gorgeous! Very cool


Sent from my iPhone using Tapatalk

[karter16]

karter16 I've probably missed but is "rf dynamics" explained anywhere?

Hey - it's a short doc but 8.02 in the funktionsrahmen explains it https://github.com/karter16/CSL_0401...mic%20Lead.pdf

Essentially RF can be adjusted for knock protection or cylinder pressure management. The integral component is suspended while this is in effect, so that it doesn't try to “adjust out” the dynamic adjustment.


Sent from my iPhone using Tapatalk

[ac427]

karter16 I've probably missed but is "rf dynamics" explained anywhere?

[Bry5on]

Do you happen to have a build thread somewhere for the Jag? I would love to read it if it exists.

Really light on details of the Jag sadly.

Here's what it looks like (not much has changed in the past four years except for stable mates): https://youtu.be/UGBo-wUDK4g

And a few details here, although I wasn't as great about updates. Not having the details was part of what motivated me to make this wagon build thread: https://www.jaguarforums.com/forum/x...roject-184994/

[karter16]

In my other car.

Do you happen to have a build thread somewhere for the Jag? I would love to read it if it exists.

[karter16]

This is brilliant. I'm still working on absorbing your written description and browsing through your project simultaneously to make sense of how you arrived at it, but writing it out like that is extremely helpful.

Another dumb question, when building a project like this did you have to populate the memory map in Ghidra or is that done automatically based on selecting the 68k architecture? I'm assuming you did, based on the nomenclature used for the memory segments.

Nice one - yeah it takes a while to get the hang of how the program works as a whole and then it all starts to make more sense.

Yeah we had to populate the memory map manually. There's lots of different ways to configure the 68k memory so it was built out based on the work others have done in the past, referring to the Motorola documentation, etc. It's fairly crucial to get it right as the disassembler takes the memory map into account when disassembling (e.g. if you leave program ROM marked as writable you are in for a bad time with pointer references lol because the disassembler has to assume anything could change at any time.)

[R3VM3UP]

This is brilliant. I'm still working on absorbing your written description and browsing through your project simultaneously to make sense of how you arrived at it, but writing it out like that is extremely helpful.

Another dumb question, when building a project like this did you have to populate the memory map in Ghidra or is that done automatically based on selecting the 68k architecture? I'm assuming you did, based on the nomenclature used for the memory segments.

[karter16]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

Thanks - great call out! Have amended :-)

[Bry5on]

Amazing, thank you! The only things I've noticed are just clerical: Definitions for TAN and P_UMG don't exist on the page in the Input Variables section. You added a quick (Definition) for other variables that were referenced but don't show up directly in these functions

[karter16]

I've also uploaded an archive ghidra project which contains all my latest work - it can be found here: https://github.com/karter16/CSL_0401...2025_03_09.gar It's a work in progress and I keep on wanting to tidy it up more before sharing but if I do that I'll never share it. You'll just need to put up with the fact that some of my comments will be out of date and the inconsistencies of work in progress. Let me know if you have any Q's.

Again my ask would be if you figure things out that you post them here as you go so that I can keep incorporating discoveries into the master disassembly project.

[karter16]

I've written up a wiki page here: https://github.com/karter16/CSL_0401...works#overview which describes in detail how the MAP sensor is used to calculate RF. It includes explanation, details of all variables and parameters along with a full code listing and code walkthrough of the functions that calculate RF and the integral controller component.

If anyone has the time I'd really appreciate it if you could have a read through and review - my intent is that this should be a complete explanation of how the MAP sensor is used. It would be great as well if you have questions about how specific values are obtained (e.g. "how do I know that xyz really does what you say it does?") then please point these out and I can do detailed listings of those things as well. It's a bit hard to figure out what the appropriate bounds of this are as you can go to the n'th degree with everything. Ideally I'd like the end result to be something that is so clear and comprehensive it leaves no remaining doubt that this is indeed the way the MAP sensor works.

Random screenshots of the wiki page to snazz up this post.


Screenshot from overview


Screenshot from function description of rf_calc()


Screenshot from code walkthrough of rf_calc()


Screenshot from code walkthrough of rf_p_kad_i_calc()

[R3VM3UP]

Ah okay, that's the part I was missing, I don't think I've ever seen those posted anywhere. I was only aware of the 52_V508.A2L file.

[karter16]

Is there a specific reason why you have higher confidence that the 1801 XDF is more accurate?

Yeah in the same way the original XDFs were built off an 0901 A2L there is also an 1801 A2L.

Not sure if an 1801 XDF actually exists btw, if it does it's probably one that was built off the original 0901 work.


Sent from my iPhone using Tapatalk

[R3VM3UP]

Is there a specific reason why you have higher confidence that the 1801 XDF is more accurate?

[karter16]

Sorry for the massive quote, and forgive my ignorance on some of this, but are you just doing this all manually or have you developed some sort of scripts to handle this? I get it that you've got a fairly complete XDF for the 1801 binary, are you just looking up how variables defined in the 1801 XDF are being used in the 1801 decompiled binary, and then checking to make sure that they are being used in the same way in the decompiled 0401 binary?

No worries - the translation from 1801 to 0401 was manual. Previous efforts were scripted and resulted in about a 1 in 5 error rate. Which comes down to the way BMW managed the codebase and the way the compiler reorders variable name to memory address assignments. Doing this manually, in this case, results in a much lower error rate and also captured where memory locations have been repurposed, etc.


Sent from my iPhone using Tapatalk