new $EE tuning thing!

[fbody_Brian]

We need to find some free ram also.
Can you make continuos scan of memory region 0245 to 2ff and 188a til 18ff via mode2 on runnnig engine.

Just curious, how would one go about doing this?

[steveo]

Cylinder trims will be easy to do, but it will need eside mode4 control for sure.
That will be good choice for the first version to try.
Do you want it to trim all at once or single mode only.

we only need to be able to set one at a time, but they need to stick

so we need 8 bytes of ram, but only two bytes for mode4; one for cylinder select, and one for the value to use for that cylinder, perhaps sending cylinder '0' or something will switch back to the ordinary table.

We need to find some free ram also.
Can you make continuos scan of memory region 0245 to 2ff and 188a til 18ff via mode2 on runnnig engine. I suspect this region as not used, but it needs to be confirmed on running engine.

i'll try and get that done soon. we need to remember that y-bodies have some extra code, so we need to check a y-body too otherwise we might screw up a vette?

[steveo]

Just curious, how would one go about doing this?

use custom commands in the advanced tab in eehack

command like 0xE4 [length] 0x02 0x02 0x45 [checksum] will dump the memory at 0x0245 at a length of 64 bytes

you need kur4o's e-side comms patch for it to work on e-side memory, as modes 0x02 and 0x03 are disabled by default on the e-side

[steveo]

Disabled fast comms and did not get the error. I'll turn it back on next time and see if it returns.

brian i've patched 4.1 like this just to be safe, so linux specific builds get a bit longer post delay. i've increased mode 6's general post-delay too.

// we use a longer post delay for linux guys due to a few write errors cropping up
#ifdef W_OS_LINUX
#define WRITE_POST_DELAY_SHORT 30
#else
#define WRITE_POST_DELAY_SHORT 22
#endif

[kur4o]

I`ve explored and compared alot of bins, but never found a difference in the code part, even between 94 and 95 there are 2 bytes difference in the code part and it`s mode 4 tcc dc valve related.
Did you find some vette specific code part to look at?

I can try different approach with small tables loading via command mode. The max will be 17 bytes long, even though it can be expanded.
I will use some of the aldl modes that are not used. On eside mode 07, 08, 09, 0a, 0b, 0c are not used and can be forced to do intersting stuff as code execution, loading tables, switching bits and so on. For example you send empty mode 7 request It execute some code and switch sd to maf untill memory is cleared or battery disconnected. I guess the limit will be free ram memory.
Do you think multi mode support will be possible?

[fbody_Brian]

brian i've patched 4.1 like this just to be safe, so linux specific builds get a bit longer post delay. i've increased mode 6's general post-delay too.

// we use a longer post delay for linux guys due to a few write errors cropping up
#ifdef W_OS_LINUX
#define WRITE_POST_DELAY_SHORT 30
#else
#define WRITE_POST_DELAY_SHORT 22
#endif

Nice!
best to grab from github or fbodytech?

also, does 4.1 happen to have a fix for the file extension issue under nix?
Just curious

[steveo]

Nice!
best to grab from github or fbodytech?

how about right here......

---------

EEHack’s 4.1 release is now out!

For those of you running 4.0, hopefully the automatic version notification worked, and this notice won’t even be necessary…

Highlights include improvements to the graphing module, the knock analyzer module, and some minor tune-ups to flash write timing to decrease the chance that errors will occur.

This release is also important as I’ve changed the way font sizes are displayed. Some users with modern high dpi displays with enlarged fonts found the program unusable. This should help a lot.

See release announcement for download link: http://fbodytech.com/eehack-4-1-released/

-------

does 4.1 happen to have a fix for the file extension issue under nix?

no, i forgot about that one. you should beat up my github's issue tracker a bit so i actually remember these back-burner issues.

[steveo]

Do you think multi mode support will be possible?

it's easy to just grab data; my concern is logging the data, playing it back, graphing it, etc.

it has to be a fixed set of data that doesn't change all the time, since every time it changes i pretty much have to change my log format.

For example you send empty mode 7 request It execute some code and switch sd to maf untill memory is cleared or battery disconnected. I guess the limit will be free ram memory.

that'd be awesome.

Did you find some vette specific code part to look at?

not really, i thought '95 y-body ecms had a bunch of weirdo error checking that earlier ones didn't.

speaking of which, do you know anything about the 'vette rear o2 sensor? (there is one...) does it have an AD channel? there's no error for it...

[fbody_Brian]

no, i forgot about that one. you should beat up my github's issue tracker a bit so i actually remember these back-burner issues.

This is what I've been using, probably not the best way, and no idea what effect it would have on windows, but it's working for me under linux:

#ifdef V6
        config.get_savepath(),tr("EEData File (*.ee6data)"));
#else
        config.get_savepath(),tr("EEData File (*.eedata)"));

  if (!filename.endsWith(".eedata"))
      filename += ".eedata";
#endif

and I did get a new version notification, fyi

[steveo]

that might do the trick, i'll try it out! i never think to use qstring's advanced features, im still so used to doing my own string handling.

[fbody_Brian]

I just tested it on 4.1, which is great btw.
seems to work.

Very useful software.
Being in open loop, the AFR display is very helpful. It's definitely worth a patched bin

[steveo]

i found a few problems with your file extension approach. the worst is you have a file already named log.eehack, then you type 'log' as your save filename. it overwrites log.eehack with no prompt, violating all sorts of user interface conventions. so at least need to check if the file already exists and manually bring up a replace/cancel dialog.

[steveo]

i just caught your bug report on github too,

If you click save, then click cancel on the file save dialog, it pops up the dialog that says log file saved, then you get the discard/cancel dialog.

the first one is your patch's fault.

when you click cancel a blank string is passed to the filename object, which you then check for an eehack suffix (which doesn't exist since its blank), now there's a legit filename, ".eehack" so the file open and write succeeds, whereas i intended a blank filename to inherently fail and bail out at the same point as an invalid filename. you likely have saved a log called .eehack (which would be invisible, and overwritten without notice)

anyway i now bail silently on an invalid filename, and integrated your file extension patch defined for linux builds only:

https://github.com/resfilter/eehack/...dda1768ecc7dda

[fbody_Brian]

ah!
didn't realize about the empty string. Yeah, well I guess with that code adding ".eehack" there's never an empty string.

Funny enough, there's no hidden file, .eehack, but yes I just tested the overwrite without notice and that's the case.

[fbody_Brian]

There's got to be a better way to get this file extension to work in linux. right now overwriting without warning is possible and that's a pretty bad thing. It's the same with the csv, no extension unless you manually type it.
Maybe it should just be up to the user to always put it in, pretty crappy, but at least you are warned before you overwrite something.