pcmhacking.net

It's so bad, I'm honestly starting over. I'm planning to put together a video to show how to get started and I'll post that file as a jumping off point for people.

bubba2533 wrote:It's so bad, I'm honestly starting over. I'm planning to put together a video to show how to get started and I'll post that file as a jumping off point for people.

Well, 'C' based coding will save variables in RAM, thats kinda how that works generally.
I believe C should be fine to use, but you will need to make sure you indicate 'where' its saving these variables so that it doesnt get overriden by some other routine.

Otherwise if you feel pretty confident writing in 68k, then just write your routines in assembly. It really depends how complex you want to make your functions?

Sounds good man.. I'd love to dig into it.

There was an issue with current config and checksum dll, using hardcoded end of OS. Now the dll is configured to read the end address from bin file. And there is updated xml checksum config for Universal Patcher[attached]. It needs to go to xml folder overwriting older version.

Creating patch is just as easy as comparing 2 files. Open original file[base] and modified file[patched]
->check force if same size if OS numbers differ, and mark only OS.
->click compare
->go to patch editor tab and click save

If saved in patch folder the patch will get loaded and be ready to apply when a bin matching the OS is loaded.

You can also create manually patch, add rules, searchable rules and so on.

When we have a good definition done for the boost OS[an xdf with boost tables only will be enough], a table patch can be made with preconfigured tables data.
For example
level1 base maps with 2bar map
level2 base maps with 3 bar map
and so on
tons of different preset configurations can be made with a click of a button.

You can save them as a table patch and it can be applied separately.

On the variables that can be used. Saving to ram only global ones[used in more than one subroutine] and some for debug and logging is needed.
When you jump to subroutine you can stack all registers with simple 2 line code, use whatever registers you need in the subroutine and before exiting load back from stack variables.

kur4o wrote:There was an issue with current config and checksum dll, using hardcoded end of OS. Now the dll is configured to read the end address from bin file. And there is updated xml checksum config for Universal Patcher[attached]. It needs to go to xml folder overwriting older version.

Ok, I'll have to update my file. Thanks!

kur4o wrote: Creating patch is just as easy as comparing 2 files.

patch.JPG

Open original file[base] and modified file[patched]
->check force if same size if OS numbers differ, and mark only OS.
->click compare
->go to patch editor tab and click save

If saved in patch folder the patch will get loaded and be ready to apply when a bin matching the OS is loaded.

You can also create manually patch, add rules, searchable rules and so on.

After thinking about it I really don't want to program a patching tool, so I'll have to play with this more.

kur4o wrote: When we have a good definition done for the boost OS[an xdf with boost tables only will be enough], a table patch can be made with preconfigured tables data.
For example
level1 base maps with 2bar map
level2 base maps with 3 bar map
and so on
tons of different preset configurations can be made with a click of a button.

You can save them as a table patch and it can be applied separately.

I won't be making any changes to the calibration with my patch. It'll be on the tuner to make these modifications based on the parts the vehicle has.

kur4o wrote: On the variables that can be used. Saving to ram only global ones[used in more than one subroutine] and some for debug and logging is needed.
When you jump to subroutine you can stack all registers with simple 2 line code, use whatever registers you need in the subroutine and before exiting load back from stack variables.

Yeah, that's exactly what I'm doing.

But I save some CPU cycles because the d3 & d4 registers don't need to be saved. I'm not sure if it was the compiler that made that decision, or if it was explicitly done by GM (or whoever did the OS programming). Either way it would have been nice to know, but it really doesn't matter unless I start overflowing the stack. I have no way of knowing if I overflow the stack, the CPU could do a reset, or it might just override other RAM addresses and go totally unnoticed.

With this you can link 10-15 variables to fffe, within subroutine.
And push only the registers that will be used only in the subroutine.

To read data from linked a6 special stack for variables. And so on. the linked a6 is written backwards. It can start from fffe but it can also start from 0 on some occasions.

Stack is really hard for debugging, so if you need to test some code, better write to ram first. Than when it is nailed use stack.

On exiting the subroutine Use unlink and push back registers from stack.

Usually you can check where stack is configured. Somewhere at reset vector. for example.
And get a rough idea how many bytes you have.

The nice thing about storing values in RAM is that you can watch them with a data logger.
Sometimes that's helpful for debugging, sometimes it's helpful for tuning.
If you don't see it being useful in either case, then the stack is probably better.

NSFW wrote:The nice thing about storing values in RAM is that you can watch them with a data logger.
Sometimes that's helpful for debugging, sometimes it's helpful for tuning.
If you don't see it being useful in either case, then the stack is probably better.

I think thats a good point. I build a function strictly for dumping the RAM area so I could see exact values for debugging.

So....I changed things again...

I've changed how I am doing desired air/fuel ratio. I replaced power enrichment with 2 new "Desired Air/Fuel Ratio" 3D tables based on MAP and RPM. I added 2 of them to allow for different Air/Fuel ratios between E0 and E80 (Flex Fuel Enabled).

I've stopped working on V3 and I'm going to start doing testing in my truck. I would like to get this out there for other people to play with as I think it's a huge upgrade from V2. There are significant changes so there will be no easy way to upgrade from V2 -> V3. But I'm hopeful that all the changes I've made will allow for relatively easy upgrades in the future.

Also......I've started work on V4 that will allow for some big changes for the MAF guys....lots more work to do, but it's looking pretty easy to increase the MAF frequency and g/sec capacity. If you are interested or have an opinion on the table size/limit for an update MAF calibration let me know what you think it should look like.

Edit:
P59 MAF curve is 1500-12,000 Hz with 125 Hz resolution and a maximum airflow value of 511.99 grams/second
E37 & E92 MAF curve is 0-15,000 Hz with 150 Hz resolution and a maximum airflow value of 4,000 grams/second

Please forgive me if this has been discussed before, but would it be possible to extend the Injector Flow Rate table to boost areas? I know that up to know people have been compensating by either adding more fuel or using a boost referenced regulator, but I think it would be pretty neat to give the PCM accurate injector data while in boost. I don;t think one would need to increase the table size, just change the values that are referenced. Please take a look at the attached injector data, I took this from the ID725 spreadsheet. The top table is what the P59 currently has and the bottom table is what I'm talking about changing it into. I'm not sure what OS or ECM uses the lower table.

0 kPa is atmospheric pressure, positive kPa is vacuum and negative kPa is boost. The lower table would max out around 12 psi in boost. Maybe the two halves can be scaled differently so the boost side could include more columns than the vacuum side?