EFIDynoTuning Forum

More - I downloaded your eqe3 bin to have a look, and SAD 4.0.7.16
if you look in <eqe3...> _msg.txt file, you should see a list of RBASE commands. these are detected automatically by SAD

rbase d8 10480
rbase da 10680
rbase dc 10880
rbase de 10980
rbase e0 10a80
rbase e2 11080
rbase e4 11180
rbase e6 11280
rbase e8 11380
rbase ea 11480
rbase ec 11580
rbase ee 11680
rbase f0 12060
rbase f2 12310
rbase f4 1258a
rbase f6 13678
rbase f8 13ee0
rbase fa 148ba
rbase fc 14dea
rbase fe 1627a

so these are all used as 'fixed' pointers to data in Bank 1.

there is a block of register data at 82060 and the setup is at 8de4d, and that looks just like A9L , and the others are set directly at 823ca

[Rec+c8] answer

Ford use certain registers as 'base' pointers. These point to a RAM or ROM address and then are used as [Register+offset]. SAD can detect these and automatically converts this to a fixed address (to look for a symbol name). There will be code somewhere that sets these up. SAD calls these RBASE registers, and there is an RBASE command to set these manually.

It seems that Ford did this to allow for new calibrations. Code-wise, it means Ford engineers can change the value of that register to point to a different data block without affecting anything else. Most bins have their data calibration setup this way. Single bank bins often use Rf0-Rfe, multibanks vary a lot more.

A9L version -
but sometimes it's just set directly.............A9L RAM pointers are here

Word tables by user command work (added for jsa request) , but auto detect isn't done yet.

Decipha,

You obviously have huge experience on actual tuning, from the work you do here. When you mention 'odd' tunes, I would like to get as much as possible working for all bins, (eventually..), so if you do get a weird one then I will be interested in it. SAD is an ongoing project, as we are still learning some of the finer details. Even the Ford manuals don't tell everything. Plus some of the special chips.. e.g. DUCE etc. are still a bit vague.
As an retired IT guy I can see why Ford did some of the code the way they did, but it doesn't make it any easier to disassemble.

examples - SAD not working for -
The RZASA series, because they had a second RAM area high up in Bank 1. (sorted now)
FM20M06 breaks Fords own hardware rules (no interrupt vectors in Bank 1). Not done yet.

I'm sure you will know of others...

If I'm understanding right, the later V4 versions do this already. Try the ones in 'development' subdirectory.
Yeah, looking back, it was a bad idea.

For everyone -

SAD V5 list is to try to -

Add proper math calcs instead of just divide. (allow stuff like = 4/(x*16) for example)
Allow for sub fields within bytes/words/longs (e.g. timer structures do this for bit flags)
Allow for word tables
Allow data items to be printed more than once (in some bins pointer/offsets are used more than once, into different queues/pointers)
Fix problem with FM20M06 etc. (where Ford break their own hardware rules....) requires a new bank detect trick.
Improve comment options.
Improve detection of data and code.
do argument sizes better (by checking more code)
[I'm sure I've forgotten some stuff...]

I've changed a lot of code already.

Hopefully I'll release a 5.0.1 alpha soon

Happy to take other suggestions.

BOOSTEDEVERYTHING wrote: ↑2023 Oct 24, 15:45 when I try and run my bin through the sad.exe windows version I get an error message. So I stopped using that version. Maybe I am doing something wrong? I just run the sad.exe and go to open and click on the bin I have been using

That's program crash, you are not doing anything wrong, that is some kind of bug... !DAMN! (or stronger). That should never happen. It should be robust to everything, even user errors. If there is a serious error it should just refuse to disassemble.

"write to address zero" hmmm....that's DEFINITELY a bug on my part.

Yes there are some versions with bugs in which cause crashes. SAD should say what version in the xx_msg.txt file (where xx is the bare name of the bin (ie. without the .bin)).. can you tell me which version ??

Generally the latest version on github is the best (but not always, new bugs can creep in...) Official stable is 4.06, but if you go into 'development' subdirectory it goes to 4.012 . If you are using that one, I am interested in how you managed it (so I can fix it).


Please confirm - 1) which bin. 2) send your dir file and cmt file if you have one.... and I'll see if I can find the bug.

General note - "what tables and functions are for ?"
They are your calibration/tune. They are the jets in your carb, and springs in your dizzy. But it's a hell of a lot more complex than that with all the sensors.
(Yes, you knew that. Just repeating.)

SAD disassembles the code. It can only try to pick out what it can. Data is still missed here and there. Some of the Ford coding is difficult to sort out. And that's before we get to what the data and code actually does for the engine. It's an ongoing project. Sorting out subroutine arguments/parameters is/was a real bastard to do. It doesn't work perfectly. Sorting out tables (2D lookups) correctly is tough as well.

Unfortunately the true answer is there is no way to know without a human brain looking through it. After studying for a while, you get to spot patterns more quickly, but even then some stuff may still be 'wtf?" without tracing what calls it and what it does. It's a slow process. IMHO, A9L is still really useful as a backup for the comments and labels it has. Many of its functions and tables are labelled to state what they do. Some good work done there. And it's still relevant.

JSA is studying CARD for example (Cosworth 2.0 Escort, manual trans) but CARD still has a lot of code which looks just like A9L, even though engine/trans is totally different to a V8 auto....

As JSA states above, start with A/D inputs, then can use interrupt handlers and that gives you a base of inputs, and try to work from there. See if the tables/funcs look similar to a one in a bin that's been identified already. In some ways it's also like a treasure hunt.

I hope that doesn't put you off, I'm just trying to be honest.

I can help with how the code works, and how functions/tables actually 'work' in terms of input/output, but I haven't done much for a particular engine/tune, others are much more experienced. I am doing SAD as a 'keep my brain active' project. I don't even own a Ford vehicle any more.

Tvrfan here (Andy), writer of SAD. JSA was doing a good job of explaining to you, but I thought I would finally register here and respond.

If you run SAD with no commands at all (i.e. .dir file) SAD will run automatically for everything. I freely accept it doesn't do some things properly (and probably there will always be some weird code or trick by Ford programmers...). If you specify commands, that command becomes 'master' and nothing will supercede it. But everything else will be unaffected and continue automatically.

So if you have a command which specifies say a Function (a 1D lookup) , SAD will not change that command EVEN IF YOUR COMMAND IS WRONG.
I have to do it this way, as user commands need to be able to fix/override any errors.

The example you gave is about what size the function argument is (word or byte). Frankly this is still a bit of a problem to do automatically, as it's not always obvious what the code does with the argument. Arguments are always read as bytes, and then may be used as words depending on the code.
You can override the sizes with ARG command.

BOOSTEDEVERYTHING - the 'Q' is used where you have a structure which has say an 0xff' at the end which is used solely as an 'end' marker. Timer structure is a good example, and also initial setup on some bins. I haven't seen a WORD terminator yet , but the 'Qn' allows for one. All terminators seen so far are a single byte (as you say, a 'Q1')

I am trying to finish an all new version 5 , which will have a big extension to the command sytax, (I am trying to sort out argument sizes), and lots of code has been rewritten to improve it from version 4 and have more user functionality (like proper math calculations). But it's taking much longer than I want.

general note for newbies - 'AA' is a good starter, not because it's mine, but because it's simple, and tiny. It has no subroutines with arguments, so is straightforward. And OLD (1985). The ubiquitous 'A9L' is a lot more complex, has arguments, some self tuning, synced injection, etc... but it's been worked on by many, so comments are mostly good to follow.