devkitPro

There's a problem with the wii speak - it doesn't have any stored firmware. Every wii speak game has a "blob" of firmware data embedded within it which it uploads to the wii speak to make it work. Any homebrew apps would need to do the same, which would be illegal since the firmware blob i...

Sounds more like bg_rockfieldMap is a u8 array when the code expects it to be a u16 array, resulting in incorrect pointer math.

Any situation where you need to kill a thread is a result of bad coding/design elsewhere.

The RTC does not provide sub-second accuracy so using the CPU timebase is the only logical choice. The fact that they're not aligned is irrelevant; even if they were, they are being accessed separately at different points in time instead of using a single atomic tick value to calculate both tv_sec a...

If this is ever going to be fixed I propose adding wii u pro controller support at the same time: Index: gc/wiiuse/wiiuse.h =================================================================== --- gc/wiiuse/wiiuse.h (revision 4915) +++ gc/wiiuse/wiiuse.h (working copy) @@ -245,7 +245,7 @@ CMD_DONE } ...

Snarky comments aren't really that helpful tbh. I had this discussion several times during commercial dev work as well and we never managed to find a situation where a custom allocator actually had a significant benefit. I used a custom allocator once to avoid the overhead of newlib in a GBA based ...

You need to change quite a few other registers, mainly the ones that control vertical timings for both fields.

Do you also reset mem2_start to NULL?

You're right. DevkitPPC uses dlmalloc for its malloc implementation, from memory it has a "trim" function that releases memory back to sbrk when a certain amount is unallocated (in this case it must be at the "top"). Unfortunately it's configured to treat all sbrk'd memory as con...

It's not quite that simple. sbrk allocates RAM from the heap to the memory manager in newlib. When you release memory using free it becomes available through malloc regardless of where the heap pointer might be. The only memory that gets "lost" is the gap at the end of MEM1 when moving to...