LS1 Boost OS - Development

For discussion and distribution of custom code and hacks
Posts: 302
Joined: Wed Apr 11, 2018 8:50 am

Re: LS1 Boost OS - Development

Postby bubba2533 » Wed May 11, 2022 1:18 pm

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: If you have Questions about the current release post Here. If you have feature suggestions post in the Development Thread

User avatar
Posts: 2898
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: LS1 Boost OS - Development

Postby Tazzi » Wed May 11, 2022 1:49 pm

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Posts: 35
Joined: Thu Jan 19, 2017 11:09 pm

Re: LS1 Boost OS - Development

Postby Stokes1114 » Wed May 11, 2022 2:17 pm

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

Posts: 530
Joined: Sun Apr 10, 2016 9:20 pm

Re: LS1 Boost OS - Development

Postby kur4o » Wed May 11, 2022 8:53 pm

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 244 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 9 times

Posts: 302
Joined: Wed Apr 11, 2018 8:50 am

Re: LS1 Boost OS - Development

Postby bubba2533 » Thu May 12, 2022 12:47 am

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: If you have Questions about the current release post Here. If you have feature suggestions post in the Development Thread

Posts: 530
Joined: Sun Apr 10, 2016 9:20 pm

Re: LS1 Boost OS - Development

Postby kur4o » Thu May 12, 2022 3:29 am

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
Posts: 662
Joined: Fri Feb 02, 2018 3:13 pm

Re: LS1 Boost OS - Development

Postby NSFW » Thu May 12, 2022 2:18 pm

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
Posts: 2898
Joined: Thu May 17, 2012 8:53 pm
Location: WA

Re: LS1 Boost OS - Development

Postby Tazzi » Thu May 12, 2022 2:54 pm

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
Site:www.envyouscustoms.com
Mob:+61406 140 726
Image

Posts: 302
Joined: Wed Apr 11, 2018 8:50 am

Re: LS1 Boost OS - Development

Postby bubba2533 » Thu May 19, 2022 5:44 am

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: If you have Questions about the current release post Here. If you have feature suggestions post in the Development Thread

Previous

Return to Custom Code

Who is online

Users browsing this forum: Majestic-12 [Bot] and 1 guest