Hacking Official Corbenik - Another CFW for advanced users (with bytecode patches!)

[chaoskagami]

Ok, thanks! I like the dots. OCD? Yes,

And this is why bytecode patches are a good thing (TM)

 

[Kirtai]

I'm pretty sure it's probably not worth the effort to import my code, honestly. I do a lot differently than pretty much everything and importing would imply importing ~80% of the code. The other thing that somewhat makes this infeasible is Corbenik is really NOT meant to be used in a self-contained manner in any way.

Yeah, I was more thinking of how much faster testing ideas would be with the bytecode patches as opposed to compiling and reinstalling the whole firmware.

 

[chaoskagami]

Yeah, I was more thinking of how much faster testing ideas would be with the bytecode patches as opposed to compiling and reinstalling the whole firmware.

It might be helpful, but one would need to rewrite the bytecode in C afterwards. Contrived example:

loc = memsearch(memory, pattern, size_mem, size_patn) - 2
memcpy(loc, repl, size_repl)

=

find <pattern>
back 02
set <repl>

All in all, if you're developing something using C, it's probably easier to just keep doing what you're doing.

 

[Orkna]

I still have small jumping around problems in the menu men not as bad as before.

Do you move on key down AND key up?

 

[chaoskagami]

I still have small jumping around problems in the menu men not as bad as before.

Do you move on key down AND key up?

No. The way the function works is as such:

- Wait until a key has been pressed
- Wait for the key read to NOT be depressed
- Return and process the key (and only ONE key)

This is why I'm so confused about your issue. There's no possible way this could happen unless your dpad is shorting. I literally just spin until a key is pressed, so that I don't have to limit the runspeed.

Luma actually loops through the menu code at a limited framerate (like a game's main loop,) so this probably doesn't occur there due to precise waits.

 

[Orkna]

No. The way the function works is as such:

- Wait until a key has been pressed
- Wait for the key read to NOT be depressed
- Return and process the key (and only ONE key)

This is why I'm so confused about your issue. There's no possible way this could happen unless your dpad is shorting. I literally just spin until a key is pressed, so that I don't have to limit the runspeed.

Luma actually loops through the menu code at a limited framerate (like a game's main loop,) so this probably doesn't occur there due to precise waits.

It seems that it jump one on key down and once again key up the few times I get double jumps..

 

[Kirtai]

It seems that it jump one on key down and once again key up the few times I get double jumps..

Could you have a glitchy d-pad that sometimes sends multiple clicks per press?

 

[chaoskagami]

It seems that it jump one on key down and once again key up the few times I get double jumps..

I don't know what to tell you. I suspect it's hardware, since you're the only one who seems to have this issue. I can't reproduce it, and nobody else here has mentioned it either.

I'm not going to rewrite the code to hard limit the speed any further, because it interferes with going down, a, down, a, down, a very fast in options past this point.

 

[Orkna]

Nope. Doesn't haopen anywhere else.

I push down the button, the selection jumps one selection but then it will jump one more selection when I lift my finger again.

 

[chaoskagami]

Nope. Doesn't haopen anywhere else.

Like it is not, I push down thw button, the selection jumps but then it will jump one more selecting when I stop pushing down

And again, this isn't my fault. I'm really sorry, but there's nothing more I can do here. I can't cater to glitchy hardware.

Luma doesn't do it because it rate limits its' main loop. I spin on polling input rather than acting on it within the loop and rate-limiting runspeed.

 

[Orkna]

And again, this isn't my fault. I'm really sorry, but there's nothing more I can do here. I can't cater to glitchy hardware.

. It's better compared to older versions so I have to live with this thanks for caring!

 

[chaoskagami]

. It's better compared to older versions so I have to live with this thanks for caring!

Maybe someday I'll switch to doing a frame-limited main loop, but the main thing blocking that is an accurate timer. Maybe someday. I do care. ;P

EDIT: You can slow it down further by adjusting the #defined value ARM9_APPROX_DELAY_MAX in the function wait_key in `source/menu.c`. I can't do this in release builds, evidently because it negatively affects functional dpads. Considering you're compiling from source, this is a simple change you might want to make (for now)

 

[Arcanuskun]

how to boot to setup again after enabling autoboot?

 

[chaoskagami]

how to boot to setup again after enabling autoboot?

Hold R. I should probably put this in the readme and the OP.

 

[Deleted member 117573]

Little help with my compiling error please.

Not sure how to proceed.

 

[chaoskagami]

Little help with my compiling error please.

Not sure how to proceed.

View attachment 53099

I've never said I supported compiling on Windows with good reason. It was pure luck it worked until now. Did you check out the submodules properly? You also need a host gcc/g++, e.g. mingw/cygwin now.

 

[Deleted member 117573]

I've never said I supported compiling on Windows with good reason. It was pure luck it worked until now. Did you check out the submodules properly? You also need a host gcc/g++, e.g. mingw/cygwin now.

From here on out, I think I will just wait for official releases. CFW working perfectly so I really have no reason to update to latest commit. Thanks @chaoskagami.

 

[chaoskagami]

From here on out, I think I will just wait for official releases. CFW working perfectly so I really have no reason to update to latest commit. Thanks @chaoskagami.

Here's how I generally roll with releases anyways, for reference:

* Make some new experimental change
* Break git
* Fix git
* Do another 1~2 times
* Release

So as you can see, there's no negative to running the stable unless you like crashes that I personally am working on. I don't plan to sit on stable code for extended periods, nor do I intend to leave bugs unfixed in git for extended periods. Release early, release often. This is also why I'm using semantic versioning on stable releases.

 

[DjoeN]

Little help with my compiling error please.

Not sure how to proceed.

View attachment 53099

Here's my build error :/ gcc/g++ (cygwin/mingw) are both installed
Not complaining, like @chaoskagami said, he never supported compiling on Windows.

Spoiler: Build error

make[1]: Entering directory `/d/ABuildCFWs/corbenik/host/bdfe'

rm -f bdfe
rm -f *.o
make[1]: Leaving directory `/d/ABuildCFWs/corbenik/host/bdfe'
rm -rf out build
make -C host/bdfe
make[1]: Entering directory `/d/ABuildCFWs/corbenik/host/bdfe'
g++ -c -Wall -Werror -g -DOSSD_TARGET=OSSD_IF_LINUX main.c -o main.o
main.c: In function 'int main(int, char**)':
main.c:89:25: error: 'basename' was not declared in this scope
   usage(basename(argv[0]));
                         ^
main.c:95:26: error: 'basename' was not declared in this scope
    usage(basename(argv[0]));
                          ^
main.c:211:22: error: 'basename' was not declared in this scope
  file = basename(file);
                      ^
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/d/ABuildCFWs/corbenik/host/bdfe'
make: *** [hosttools] Error 2

Think we need a windows equivalent for this line in the makefile:
(Then again, i know nothing about code and makefiles, so i could be wrong)

%.o: %.c $(HFILES)
    $(CXX) -c $(CFLAGS) -DOSSD_TARGET=OSSD_IF_LINUX $< -o $@

 

[Suiginou]

Here's my build error :/ gcc/g++ (cygwin/mingw) are both installed
Not complaining, like @chaoskagami said, he never supported compiling on Windows.

Spoiler: Build error

make[1]: Entering directory `/d/ABuildCFWs/corbenik/host/bdfe'

rm -f bdfe
rm -f *.o
make[1]: Leaving directory `/d/ABuildCFWs/corbenik/host/bdfe'
rm -rf out build
make -C host/bdfe
make[1]: Entering directory `/d/ABuildCFWs/corbenik/host/bdfe'
g++ -c -Wall -Werror -g -DOSSD_TARGET=OSSD_IF_LINUX main.c -o main.o
main.c: In function 'int main(int, char**)':
main.c:89:25: error: 'basename' was not declared in this scope
   usage(basename(argv[0]));
                         ^
main.c:95:26: error: 'basename' was not declared in this scope
    usage(basename(argv[0]));
                          ^
main.c:211:22: error: 'basename' was not declared in this scope
  file = basename(file);
                      ^
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/d/ABuildCFWs/corbenik/host/bdfe'
make: *** [hosttools] Error 2

Think we need a windows equivalent for this line in the makefile:
(Then again, i know nothing about code and makefiles, so i could be wrong)

%.o: %.c $(HFILES)
    $(CXX) -c $(CFLAGS) -DOSSD_TARGET=OSSD_IF_LINUX $< -o $@

Looks like the basename(char *) function isn't a thing in Windows and would need working around in upstream.

Don't worry, upstream has already been informed! Maybe they'll even give a fuck!