Hacking Wii U Hacking & Homebrew Discussion

[Marionumber1]

Adding to my previous post, I should note that trying to allocate a new DRC framebuffer with MEMAllocFromDefaultHeapEx() returns NULL. My guess is that the cancelled thread allocated the original framebuffer, and cancelling it will free the memory back to the heap so we can reallocate it ourselves.

 

[celcodioc]

Moving to something else... I've been trying to read files, but this function, which is put inside fs.py (you'll also have to add 'FSOpenFile', 'FSReadFile', 'FSCloseFile' to symnames there) gets stuck on "Opening..."

Any ideas?

 

[WulfyStylez]

Your method of getting the proper pointer of MEMAllocFromDefaultHeapEx worked, but now I'm curious about canceling that thread. I imagine the thread pointer they used isn't going to be the same now, right? And wouldn't terminating that thread kill the browser (and rpc) anyways?

 

[NWPlayer123]

Moving to something else... I've been trying to read files, but this function, which is put inside fs.py (you'll also have to add 'FSOpenFile', 'FSReadFile', 'FSCloseFile' to symnames there) gets stuck on "Opening..."

Any ideas?

That's the point, it was a failed test You're not supposed to be able to read files

 

[Marionumber1]

Your method of getting the proper pointer of MEMAllocFromDefaultHeapEx worked, but now I'm curious about canceling that thread. I imagine the thread pointer they used isn't going to be the same now, right? And wouldn't terminating that thread kill the browser (and rpc) anyways?

I tried terminating that thread, and it seemed to work (OSIsThreadTerminated() on it returned true after cancelling it). However, it didn't allow me to allocate the framebuffer. Also, I attempted to display one of the images in the 0xE0000000 area (by setting both the TV and DRC buffers to it), but the screen contrast just changed a tiny bit. Mind sharing your code?

 

[WulfyStylez]

I tried terminating that thread, and it seemed to work (OSIsThreadTerminated() on it returned true after cancelling it). However, it didn't allow me to allocate the framebuffer. Also, I tried displaying one of the images in the 0xE0000000 area (by setting both the TV and DRC buffers to it), but the screen contrast just changed a tiny bit.

Weird, my console just locks up when I try to terminate it (on 5.0.0.) And yeah, I had that same result upon trying that yesterday. I think it might be because there's already a framebuffer set up for it?

 

[celcodioc]

That's the point, it was a failed test You're not supposed to be able to read files

A failed test? I just wrote the thing These are the browser files, too... shouldn't you be able to do that considering you're running code in the browser space?

I tried terminating that thread, and it seemed to work (OSIsThreadTerminated() on it returned true after cancelling it).

Hmm, for me OSIsThreadTerminated returned true before calling it too. Did you make sure before? I'm on 5.1.0.

However, it didn't allow me to allocate the framebuffer.

I found this, might be useful:

MEMGetAllocatableSizeForExpHeapEx(MEMGetBaseHeapHandle(1), 4)

Also, I attempted to display one of the images in the 0xE0000000 area (by setting both the TV and DRC buffers to it), but the screen contrast just changed a tiny bit.

From the SetDRCBuffer/SetTVBuffer documentation:

"Calling this requires fade-out/disable/change/enable/fade-in sequence. (if called from start, video should already be black & disabled."

That could be why.

Mind sharing your code?

https://dl.dropboxusercontent.com/u/72562253/gx2.py

Based on WulfyStylez code, not yet updated to reflect your suggestions for the memory allocation function.

 

[Marionumber1]

Hmm, for me OSIsThreadTerminated returned true before calling it too. Did you make sure before? I'm on 5.1.0.

I just tried, on 5.0.0, and it turns out that you're right. It was true before and after calling, indicating that the thread structure's address did change.

I found this, might be useful:

MEMGetAllocatableSizeForExpHeapEx(MEMGetBaseHeapHandle(1), 4)

That returned 0xc9eac, which I assume is the maximum allocation size you can use.

From the SetDRCBuffer/SetTVBuffer documentation:

"Calling this requires fade-out/disable/change/enable/fade-in sequence. (if called from start, video should already be black & disabled."

That could be why.

I did do this, using GX2SetTVEnable()/GX2SetDRCEnable(), but it had the same effect.

https://dl.dropboxusercontent.com/u/72562253/gx2.py

Based on WulfyStylez code, not yet updated to reflect your suggestions for the memory allocation function.

Thanks, I'll take a look. Does it manage to display anything, even part of an image?

 

[WulfyStylez]

From the SetDRCBuffer/SetTVBuffer documentation:

"Calling this requires fade-out/disable/change/enable/fade-in sequence. (if called from start, video should already be black & disabled."

That could be why.

I'm 99% sure that's a user-experience thing. Flickery screens are no good, even if it's just for a tenth of a second.

https://dl.dropboxusercontent.com/u/72562253/gx2.py

Based on WulfyStylez code, not yet updated to reflect your suggestions for the memory allocation function.

Ha, I noticed that that was really similar to mine.

Here's what I threw together to handle that memory alloc function: http://pastebin.com/z2AciYer . Goes in rpc.c.

 

[Marionumber1]

Here's what I threw together to handle that memory alloc function: http://pastebin.com/WJdcFbLz . Goes in rpc.c.

Thanks for that, however, there's are two small problems with that code related to how you compare the strings. First, of all, you wrote =, not ==. But even changed to ==, the comparison would still fail regardless. Comparing strings actually compares pointers, and since the passed string is not at the same address as the one in the program, it will fail. I'll need to add a strcmp() function for that purpose. Another way would be adding a parameter to the call buffer specifying whether the intended symbol is a function or a function pointer. That would make things more extensible, especially since I think other default heap functions are like MEMAllocFromDefaultHeapEx().

And third, your bracing style is all wrong.

 

[WulfyStylez]

Thanks for that, however, there's are two small problems with that code related to how you compare the strings. First, of all, you wrote =, not ==. But even changed to ==, the comparison would still fail regardless. Comparing strings actually compares pointers, and since the passed string is not at the same address as the one in the program, it will fail. I'll need to add a strcmp() function for that purpose. Another way would be adding a parameter to the call buffer specifying whether the intended symbol is a function or a function pointer. That would make things more extensible, especially since I think other default heap functions are like MEMAllocFromDefaultHeapEx().

And third, your bracing style is all wrong.

Weird, because I was getting two distinct results with different capitalization of the function name when I requested its address. And the one spelled the same as I threw in there worked. But yes, you can tell I've never done anything in C in my life, I'm a Java person usually.

Also that parameter would be really really helpful, I was debating doing that myself (in awful C, of course.)

 

[celcodioc]

Thanks, I'll take a look. Does it manage to display anything, even part of an image?

Nope. No effect as far as I tried.

 

[Bug_Checker_]

Nope. No effect as far as I tried.

Have you guys tried
GX2Invalidate before GX2SetDRCBuffer?

 

[WulfyStylez]

Have you guys tried
GX2Invalidate before GX2SetDRCBuffer?

I think we need to know where the existing framebuffer is first to do that.

 

[Marionumber1]

I think we need to know where the existing framebuffer is first to do that.

GX2Invalidate() would perform a cache flush on a buffer we pass it. I think he was saying we should flush the buffer that we pass to GX2SetDRCBuffer().

 

[celcodioc]

Hmm, there's a GX2ResetGPU(unsigned int reserved) function, I wonder if it would help...

I think we need to know where the existing framebuffer is first to do that.

For the record, I'm pretty sure the framebuffers are in the VRAM, known as MEM1 (0xF4000000 - 0xF6000000). Not sure if it's possible to access that from usermode.

 

[WulfyStylez]

Hmm, there's a GX2ResetGPU(unsigned int reserved) function, I wonder if it would help...



For the record, I'm pretty sure the framebuffers are in the VRAM, known as MEM1 (0xF4000000 - 0xF6000000). Not sure if it's possible to access that from usermode.

It's readable with some trickery, but writing is probably a no.

 

[Marionumber1]

It's readable with some trickery, but writing is probably a no.

Have you tried directly accessing them from userspace and found that it didn't work? By "some trickery", I assume you mean OSConsoleWrite().

 

[WulfyStylez]

Have you tried directly accessing them from userspace and found that it didn't work? By "some trickery", I assume you mean OSConsoleWrite().

From a few random write tests to that range, it seems that it is not writable from userspace.

 

[Huntereb]

Is all this work to make a fancier "Hello World"?