EFIDynoTuning Forum

If newer pcms are like everything else, they will be full of tiny little 'blobs' with unreadable codes stamped on them, and the CPU may be a combined chip with other things like RAM already inside. (later EEC-V did this already! ) Time always moves on ....


I guess you just get to see part numbers ... ? (and prices...)

Pretty much just part numbers and prices, yes. The files we flash into vehicles are .vbf files when the ids scan tool downloads them. I’m sure it’s nothing more than an encrypted .bin file or sorts but I have no idea how to open them.

Quick web scan says that those .vbf files may be in something called MIPS assembly code, which (if true) isn't just for Ford stuff. It makes sense that if later EEC boxes are PowerPC or similar, then the CPU and architecture is no longer proprietary to Ford and so other tools and programs may already exist to read and decipher them. I see a couple of tools advertised which will read and write .vbf files to Ford boxes, so probably more things to find, if you want to get into that.

Just for an example, the '80s GM boxes (Yes, sorry..) used a widely available 68HC11 CPU and a standard EPROM chip that was even plugged into a socket and so easily removable, so those boxes got reprogrammed for a wide range of stuff. All you needed were standard off the shelf hardware and software tools to do it. It was like the 'flash' system today, but 40 years ago, and you physically swopped the EPROM chip.
This was standard practice for lots of small computer solutions in offices and businesses in those days.

Always an ongoing IT debate about proprietary or standard/open solutions....

I'll have to try searching a little more about that. I found a couple of programs that will do it but they are pretty expensive and require database files to decipher the bin files(i think that's correct). Have not been able to find any open source programs to do the new stuff. I am very curious how all the big companies come across the info needed to program these pcms so fast. Making a dir file and decompiling a small bin file takes a very long time, for me anyways, I can't imagine they are doing it the way we are.

they arent

most commercial companies are given the memory maps from ford
its a backdoor thing that beneficial for all parties

ford performance parts couldnt exist if vehicles couldnt be tuned to run them

That’s kind of what I was thinking too. But wasn’t absolutely sure because I had never been told that outright by anyone. lol.

tvrfan wrote: ↑2024 Feb 20, 22:22 Released version 5.0.8 with some more fixes.
-snip-
In the meantime v4 works OK, and you can use its output to feed into v5 to add calcs and new features, modify and/or make your own commands to fix the v5 issues.

Been giving 5.08 a workout. Progress but seeing enough issues to say it's not ready for prime time yet.
* Lookup signatures are not working well, lots missed.
* Some errors related to bits.
* Seeing these (0 > 0) where two PSW bits are required to determine branch action.
* Args not being printed, call then return line of code printed, no args in between.
* Code discovery in some bins has improved but its pretty much unusable on RZASA.
* Bank numbering issues in print.
* Issues with calc.

Edit; +100 offset on operand 2 of a byte operation, I'm likely wrong calling this out. See later post for explanation.
*You mentioned AI, should not have wished for that, SAD is hallucinating. 0472c: bd,ff,e3 ldsbw Re3,ff swR1e2 = ff; }

0472c: bd,ff,e3 ldsbw Re3,ff swR1e2 = ff

that looks correct

decipha wrote: ↑2024 Mar 20, 10:30 0472c: bd,ff,e3 ldsbw Re3,ff swR1e2 = ff

that looks correct

In previous versions it disassembles as below....

I miss the reference ??

What does your disassembly have to do with his disassembly ?