EFIDynoTuning Forum

Quick note to everyone -

4.14 has a lot of regression bugs, and will for a while, as I am moving in version 5 code so I can add some of that functionality (i.e. calculations). For now stick with 4.13 for best results (now in main branch in GitHub) , but do have a play with 4.14 if you wish. Bug reports are welcome.

Special thanks to jsa for his time spent doing testing and bug finding.

Thanks.

4.14.1

Can confirm that there's several likely 'symbol' bugs , because -

1. Code doesn't always keep track of read vs write operand properly.
2. Error status does not always get cleared properly (leads to all those phantom error messages)
3. When looking up a symbol, doesn't always identify the correct field or default name (also read/write? still trying to nail this down)

Note - the 'add' (i.e. when specified in commands) process works correctly as far as I can tell, so it's in the 'find' where it goes wrong.

Working on this now, after a delay, for various everyday garbage...

Andy.

That's a bug.

The warning should only come up if there is a duplicate USER command. It doesn't happen in my current 14.2 development code. I think it's an error flag which gets set and isn't cleared, and I fixed it when looking at something else. Not 100% sure. If so, this error probably reports for every SYM command, but possibly after there is a real error to set the flag first. So it's WRONG.

To confirm rules
User commands are always King/top and cannot be changed (*1), then a defined set of others come next (things like function lookup names, interrupt handlers etc) and then lowest precedent are 'default' names like "sub_1234".

(*1) but it's 'layered'. If you just set a name (e.g for a subroutine), SAD will still add extras (e.g. arguments) as user didn't specify. Whatever user command specifies effectively becomes absolute, no matter what, even if it breaks things.

No worries, I gave up on version 5 because my nice, neat, simple, elegant logic solution DOESN'T WORK...
so I am merging in various 'upgrades' from version 5 code so that these new or better features get rolled in to v4.
I still have more ideas to get SAD to do better as well.

So there's probably going to be some sneaky regression bugs that creep in.

That is only a warning - a user request came in, to log when sym names change, as SAD was silent before.
Sad will say "Error - " if something is rejected.
This warning also notifies if you have a duplicate in your DIR file, which also wasn't picked up before either.

It's strange that a lot of sub names give warning though... I wouldn't expect that, so maybe it is a bug.

Why ? I am merging in code from version 5 (now abandoned) to provide more functionality into version 4, and have merged in some version 5 code for symbol names, which is why this warning now appears.

Note - if SAD changes any of your .dir command names for 'default' ones (e.g. MYNAME replaced by 'sub1234') then that's definitely WRONG and is a bug.

SAD 4 (most versions) - BUG.
Shows inconsistent operand size for divide and multiply, maybe others.
NORM show operands the wrong way round?

Will fix these in next release (h/t sailorbob, jsa)

Just a thought here -

Note that the CPU ITSELF runs the extra code in the cal console, so the console doesn't need to see any banks directly, it can do what the EEC code does, and set ROMBANK and/or R11, saving and and restoring CPU state at the end before the RET. This is the same as an interrupt handler subroutine will do.

So only the code within the cal-console itself would have to change to enable and see banks, not any physical interface. I reckon there will be EEC-IV versions and EEC-V versions, because of updated code, but it's just a guess from me.

could be true - earlier bins tend to check a flag somewhere else, but checking for PUSHP at call address is just as good I reckon.

Have a look in the Ford handbook (via https://github.com/OpenEEC-Project/Usef ... C_handbook) Near the end, (section H) there are a set of memory maps. You can see there are several 'reserved' address and ranges of addresses defined for cal console and related stuff.

Unfortunately, the code listings don't always show the same addresses being called/checked for cal_console and special chips, so I haven't built them into SAD. The details differ a little too. The good news is that the overall address range of 0x1800 to 0x1ffff DOES seem to apply to all bins, and especially 0x1f00 to 0x1fff, how the banks map onto these isn't clear either (jsa above), some seem to call bank 8, some call bank 1 (?). So if you spot something around those addresses (ignoring the bank), it's probably a plug-in console.

What we can work out is that the cal console announces it's there in one address, and then ROM in the cal console itself is CALLed as if it was just another subroutine. This allows extra functions in the cal console to be run by the CPU, and gives cal console full access to everything the CPU can see. It also seems to be a standard technique in all bins.

You can see the special add-on chips (page H4) also have different address range options too. I think these turn up in bank 1, but not sure...

Hope that helps !!

More bug fixes to 4.13.8, but note that I have now put in a limited 'gap scanner' for missed code, which should reduce the need for extra SCAN commands. It's not finished yet, but it seems to work quite well, so released it as is.

Still more to do........