I’ve migrated this to the bug reports section of the forum.
I’ll also add an issue to the GitHub.
I’d look into it myself but I don’t know where the loader is kept.
I’ll have a dig later if I get time, but I’m currently busy working on something else Pokitto related.
If neither me or @jonne get time to have a look, maybe @FManga or @Hanski will have a free moment.
The loader isn’t on github yet.
Thanks to take care of it 
True. Coming soon
EDIT : the reason is I need to update the code to work with the latest codebase
Oh right, I forgot it’s stored in the LOA.DER file.
I’ve already made the issue so we can close it or leave it as it is.
If @jonne’s going to be adding the loader then it’s probably best to leave it until we know which is going to happen first - the bug getting fixed or the loader being added to the repo.
And a delayed grab of Jonne’s post.
Please add it to our fancy-pants open for everyone todo list
I’ve added it on behalf of @Haunebu123.
I also added a note about uploading the loader to GitHub,
and I’ve also forked the list into a ‘completed’ list so the todo list can actually shrink as stuff gets done.
I’ve started work on this. I have brought the loader to the new codebase but it is too big to fit in the memory area allocated. I’m trying to figure out what has increased the binary size
Got it to compile.
Phew.
Went from overflow (too big) of .text section (=program code) by 4092 bytes to 1300 bytes to spare 
Link-Time Optimization for the win!
An interesting information in that link. Do you remember if we have dead code & data removal in use in PokittoLib?
LTO, link time optimization, is something I have never used before. This time I was desperate.
What it does is that it re-analyzes unused code and data sections again when the compilation is finished and the linking is ongoing.
So no, we have not used this option before.
EDIT: in this case, LTO helped clear out float math operations that were actually not used. Compiler optimization -Os only looks at individual compilation units. LTO looks across all compilation units. The difference in this case was a whopping 1320 bytes.
To enable dead code removal, all the C/C++ source code files must be compiled using the command line option -ffunction-sections. Furthermore, the linker must be launched with the linker command line option --gc-sections.
To enable dead data removal, all the C/C++ source code files must be compiled using the command line option -fdata-sections. Furthermore, the linker must be launched with the linker command line option --gc-sections.
These could be very useful also in PokittoLib.
Unfortunately, this option (LTO) is experimental, and i am beginning to see why.
Won’t run.
EDIT: confirmed. It messes up the binary
EDIT: and here’s the bug
so its going to work and we get a new loader? 
No. (edit: silly me, I mean yes it will work) The Link Time Optimization messes the vector table. @FManga : could you try the LTO option in Build options / Linker / All settings and see what you make of it ?
But, @Haunebu123, I optimized the living daylights out of the code without the LTO and I managed to shave 3000 bytes. So it is running. But it is slow, and now I am trying to find out why
Can do. What does it do to the vector table?
It does not respect the vector table. It overwrites all sort of stuff over it. edit : including the initial sp and pc
wow, nice work @ “optimized the living daylights out of the Code” 
keep it up 
When do you think my 2 additional Pokittos going to be shipped? 
Tomorrow. Thanks for the order!
I’ll pick the most beautiful ones for you.
Thank you 
an than they are going on the big journey from finland to germany, whoo 