IAC doesn't read pressure and I'm pretty sure I had the IAC ram addresses labeled. There is an IAC bump up for when the fan is on, probably to offset the alt working harder. Pretty sure the IAC is effectively a stepper motor, so it bumps it up or down x steps.
This is some pretty deep stuff really, I'm not sure if anyone else has the cpu model worked out and the data sheet for a reference. I'm not the one that put in the 6+ months of research to find the cpu, but it was my introduction to this stuff for another computer, basically find the cpu that has all the center pins as powers and I had a couple hints along the way, took me like a week to find it if I remember right and I kind of stumbled upon it with out knowing 100% because it's a cpu Motorola doesn't have full specs for, if I remember right there's not really a real pinout diagram for it.
The stuff I said in my last post I'm not even 100% on, it's just some quick things I noted while looking at those addresses and function.
The way I normally program, I'd set a break point at the spot I'd want to check, then look at the vars to see what value they hold. Then I'd know 100% if certain codes would run or how it would step through the code, however this is ran on hardware and it's not a small project so knowing the values is a bit more of a challenge. It would be really neat to be able to emulate the hardware, but of my understanding only the cpu is known, the other chips would have to be worked out and someone would have to reverse engineer the board for how everything is hooked up and such. Kind of like emulating a game console, but there was never a dev kit handed out, so more or less no one really knows the inner workings besides the mfg and the ones that helped design it. We can speculate from the outside and get pretty close though.
If I showed you my understanding how just how the coolatant temp sensor is read and passed around till that part of the code, you'd be going wtf if you understood the programming. It's read from the registrar, stored in one spot, then it's referenced in another section of code and stored in another var, then I think it's done one more time before it it's inside the big mess of if statements and such for a super simple task, if certain things are true, turn the fan on. Of course the coolant temp is referenced in other locations as well and should be part of the table lookup for some of the tune tables but I didn't get deep enough to try to understand where the assembly code is that does that or how the table structure is coded. I've done very little with assembly, but the decompiled code I can follow along well enough which I think is C language. I did take programming classes back in college for C, C++, and C#, but we didn't get too deep in things, more history, standards of coding styles and labeling things, and some programs we had to make that were pretty simple. I was already a hobby programmer before then, just I was working on the basic side of things. Started in GW Basic as a kid, 1980's era stuff, didn't really like Q Basic but looked the same, then eventually did VB6. I've hit so many languages now I probably can't remember them all, it's all the same stuff more or less, just different formats and limitations. Assembly on the other hand, is what all of that compiles into, and it's a different world when you're looking at things directly at the hardware level lol.
I'm starting to ramble again lol.
Anyway, to answer your question about windows, I don't run windows, I'm on Linux. Think of it as if I was using an apple device with Mac OS, but with out their spyware and it's free and opensource (like pcmhammer if I remember right). Sadly a lot of things are dev'ed for windows only which doesn't get ported to other OS's. Universal patcher I suspect isn't used by many people, so probably doesn't make sense to try to manage 3 versions of it for each OS. I could try to setup WINE (the windows emulator in Linux), but I never had much success with it.
I'm not really expecting you to fully understand the coding or anything, unless you've worked around the C or Java style languages.
Anyway, in ghidra it doesn't say any code points to $7447c, but it could be code that it hasn't found yet. 0x01FF doesn't really look right though to me for the temp setting.
Here's the coolant temp on for fan 1 setting from my bin. The xref is the address where it's referenced in code. You can see the other settings around it as well. The ect_on value is 0x0A9A while the off value is 0x0A4A. To get outside of the hex, that's 2714 for on and 2634 for off. There's likely some sort of conversion or calibration table to convert those numbers to something we'd understand, like degrees C for example, but F could be converted too. I do know Universal patcher has that info exposed as well for how it converts the values, so if you didn't like working in C, you could change it so it's in F, you'd just have to rework the formula for that.
As you can probably see, I'm doing stuff very raw in the file. I think I spotted a pattern that matches both bins, so your coolant temp on for fan one address should be $74484 and the raw value is 0x0955 which converts to 2389 so that is lower than what my car's bin had in it, so seems like you've updated the value right. I just need to get the right code flagged so the references will be seen. It's been so long, but I think it was one of the interrupts defined in the first 255 bytes of the flash chip where it ultimately hits that code.
Ok, I went through all the interrupts and decompiled the jump to addresses and let it do it's thing and now there's a reference =).
I'll give it the same name as my other bin file so it's easier to spot in the code. Here's a copy paste to see the reference, of course we only have 1 thing labeled, and it's from universal patcher, so not like we actually discovered anything new.
/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */
undefined4 FUN_0001d49c(void)
{
undefined4 in_D0;
char cVar1;
if (DAT_000743b8 == '\0') {
_DAT_ffffa618 = 0;
}
else {
_DAT_ffffa618 = _DAT_ffffa0f6;
}
if ((DAT_ffffa5cc == '\x02') || (DAT_ffffa5cc == '\x01')) {
if (DAT_000743b8 == '\0') {
if ((((DAT_0006efb5 == '\0') || (DAT_0006efb5 == '\x01')) || (DAT_0006efb5 == '\b')) ||
(DAT_0006efb5 == '\t')) {
_DAT_ffffa62a = FUN_00017b60();
if ((DAT_00ff83a0 & 0x20) == 0) {
DAT_ffff8122 = DAT_ffff8122 & 0xf7;
}
else {
DAT_ffff8122 = DAT_ffff8122 | 8;
}
if (Fan1_ECT_On <= _DAT_ffffa5dc) {
DAT_ffff8122 = DAT_ffff8122 | 0x40;
}
if ((DAT_00ff83a0 & 0x10) == 0) {
DAT_ffff8122 = DAT_ffff8122 & 0xfb;
}
else {
DAT_ffff8122 = DAT_ffff8122 | 4;
}
if (DAT_0007447a <= _DAT_ffffa5dc) {
DAT_ffff8122 = DAT_ffff8122 | 0x20;
}
}
}
else {
if (DAT_000743be < _DAT_ffffa618) {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 & 0xf7;
DAT_ffff8122 = DAT_ffff8122 | 0x40;
}
_DAT_ffffa632 = _DAT_ffff9116;
}
else {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 | 0x48;
}
_DAT_ffffa62e = _DAT_ffff9116;
}
if (_DAT_ffffa618 < DAT_000743bc) {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 & 0xfb;
DAT_ffff8122 = DAT_ffff8122 | 0x20;
}
_DAT_ffffa630 = _DAT_ffff9116;
}
else {
cVar1 = FUN_00017fe6();
if (cVar1 != '\0') {
DAT_ffff8122 = DAT_ffff8122 | 0x24;
}
_DAT_ffffa62c = _DAT_ffff9116;
}
_DAT_ffffa626 = FUN_00017b60();
_DAT_ffffa628 = FUN_00017b60();
}
}
return in_D0;
}
Of course the next question is, what is _DAT_ffffa5dc, it's a global since it starts with _ so most likely it is the ram address for the actual current coolant temp, but the current code that's decompiled that writes it doesn't seem to make much sense to me, this bin/os is very different from mine at this point. I jumped in the other bin and $8000 is part of the setup code, but the GT bin defined it as a data var, that's why things didn't work out quite right lol. Still not finding the reference back to the source, it's just defined as 0 and in another spot in code another var is added to it, so doesn't seem to be the actual temp. Maybe that address isn't the correct one since I just looked for patterns with my bin, similar area but structure could be wildly different.
Anyway, I better get back to work on harnesses, but was neat to poke at the bins again. It does seem like the Grand Am code is a fair bit different from the Malibu even though they effectively run on the same hardware.
I suspect this tiny peek into what it takes to reverse engineer a bin file (with some known values!) can explain why it takes months or years to get very little progress as a whole. For a future project when I have more time, I'd like to trace out the pins on the chips for each of the common sensors for the engine to see exactly which chip it's hooked to, and try to work out some of the hardware pinouts and maybe work out the part number of the chips used more or at least try to understand the communication between some of the chips and the CPU by looking at the code and recording the interaction on the traces with my oscilloscope. I'm a very hands on learner, so I can read all the books in the world, but until I physically do something, I don't really understand it fully. I have some basic concepts, but they don't go too deep yet. Deep for the average person, but someone that works with hardware, I'd look like a newb I'm sure lol.
I think it would be neat to target a P04 that's a super common part number and work on a single bin as a community to reverse engineer how it works, work out the physical pins, communication between chips, maybe identify the chips, etc. If one gets worked out, in theory the other's should be pretty easy to translate to since the hardware shouldn't change too much, the big changes should be in software (firmware). The concept of a super common part number is so more than one person can have the same physical computer to reference. Of course that kind of makes it a requirement to have a vehicle with a 3100/3400, but for simple things like validating fan kick on shouldn't be too hard to probe for as long as it doesn't require the engine running for the events to happen. It's quite a complex spiderweb of functions so labeling everything and making sense of it all it no small task. I think that's part of why P01/P59 are worked out so well, there's only a few OS's to be bothered with so everyone's looking at the same code effectively.
This gives me an interesting idea since clearly there must be code reuse, the different functions should be able to be masked (so addresses don't matter for their locations) and detect x function in bins even if the bin has never been looked at before. Clearly if the function's job is known, the data vars it uses should be known as well. This might be part of the key to actually working out the P04's as a whole, instead of individual bin files, and in theory in other cars the same code might be used on different platforms with similar CPU's. I was doing something somewhat similar to that before but I didn't get too far before I jumped to another project lol. I have to keep the business running, so can't dedicate time like I could if I was a teen again. Really, wish I learned this stuff as a teen so I could have spent months in computers like this and get a good understand of hardware at a younger age. I was basically just lacking direction at that age, willingness to learn was there and the curiosity, once I learned firmware was just software running on hardware, that blew my mind and sadly it wasn't really *that* long ago I learned that, maybe 5 years ago.
Anyway... back to work that pays the bills lol.
