LS1 Boost OS - Development

For discussion and distribution of custom code and hacks
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: LS1 Boost OS - Development

Post by bubba2533 »

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.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: LS1 Boost OS - Development

Post by Tazzi »

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?
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
Stokes1114
Posts: 49
Joined: Thu Jan 19, 2017 11:09 pm
cars: 93 K1500, 5.7, 4L60E, 16168625 $E6

Re: LS1 Boost OS - Development

Post by Stokes1114 »

Sounds good man.. I'd love to dig into it.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: LS1 Boost OS - Development

Post by kur4o »

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.
patch.JPG
patch.JPG (108.7 KiB) Viewed 2486 times
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.
Attachments
P01-P59.xml
(7.37 KiB) Downloaded 104 times
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: LS1 Boost OS - Development

Post by bubba2533 »

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.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
kur4o
Posts: 948
Joined: Sun Apr 10, 2016 9:20 pm

Re: LS1 Boost OS - Development

Post by kur4o »

Code: Select all

link    a6,#$FFFE
movem.l d0-d2/a0-a1,-(sp)
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.

Code: Select all

move.b  (word_FFFFE800).w,unk_FFFFFFFE(a6)
move.b  unk_FFFFFFFE(a6),d3
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

Code: Select all

movem.l (sp)+,d0-d2/a0-a1
unlk    a6
rts
Use unlink and push back registers from stack.

Usually you can check where stack is configured. Somewhere at reset vector.

Code: Select all

movea.l #unk_FFA700,sp
for example.
And get a rough idea how many bytes you have.
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: LS1 Boost OS - Development

Post by NSFW »

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. :)
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: LS1 Boost OS - Development

Post by Tazzi »

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.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: LS1 Boost OS - Development

Post by bubba2533 »

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
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Phoenix
Posts: 112
Joined: Sat Aug 22, 2020 5:02 am
cars: 1983 Chevy C10
1993 Ford Mustang LX 5.0
2004 Pontiac GTO
2005 Pontiac GTO
Location: Anna, TX

Re: LS1 Boost OS - Development

Post by Phoenix »

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?
Attachments
Injector Flow Rate.JPG
Post Reply