EFIDynoTuning Forum

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.

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)

not rly, cal console uses the on board eeprom and loads alternate calibration values by rerouted the pointers to do so

the qh is more of a debugger emulating the entire binary

Ok, that makes sense. Thanks for the clarification.

I think a nice enhancement could be made to the QH if it were can bus capable and used the console memory space for external can bus sensors. Lots of 3rd party can bus sensors, actuators and gauges available that could be quite useful. QH++ could read and write on a user can bus using console memory space and serve a little user code as well.

That would be awesome!!! Maybe some extra memory if needed to add fan controls to pcms that don't have it, nitrous control, boost control, etc. I don't think it would take much more hardware to do things like that, would it? That would add so much more functionality than it already has. QuarterHorseCAN !!!

QHCAN, I like it. CAN FD transceiver, more powerful processor, a bit of memory and a lot of firmware revison.

jsa wrote: ↑2025 Feb 17, 16:03 QHCAN, I like it. CAN FD transceiver, more powerful processor, a bit of memory and a lot of firmware revison.

Only about $30,000 in development costs and away we go!!!! LOL

So, SAD Version 4.0.14.1 does not like SUB commands. I got errors for possibly every one in my CRAI8 DIR file in the MSG file. Tells me << Warning - New Symname replaces "Sub_02000". My guess is that if SAD assigns it's name for the sub, Then my SUB command is a duplicate, I guess??? I triple checked to make sure some of the errors were not duplicated in my DIR file and I did not see any.

Quick update to my CRAI8 and READ0 DIR files. Most likely some errors and the one for READ0 is a complete mess, I will clean it up as I progress. Just started back on my old one. Have made a ton of corrections on it so far. Doing the CRAI8 one with the Docs has helped me a ton, I think.LOL

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.

I don't think it changed any of them. Just warnings for most of them. Just was thrown for a loop when I had pages of warnings to sift through, LOL. I know defining Subroutines in a DIR file is not common practice unless SAD misses something. So I guess the warnings are to be expected when attempting to define all of the Subroutines in a file. Thank you for the clarification.
Also, I hope we didn't discourage you from developing version 5 by asking about fixing some bugs in version 4 ? That was not the intention at all. Thank You again for all the work you put into this project!!!

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.