Hacking Wii U Hacking & Homebrew Discussion

  • Thread starter Thread starter filfat
  • Start date Start date
  • Views Views 5,120,747
  • Replies Replies 21,104
  • Likes Likes 29
Alright! The function name already sounds like some kind of "error-report". :D
I asked it before, must have gone under the flood of msgs! :D
But I don't get the point though.
If it's supposed to draw error msgs but the error-text is longer than what the screen can show and you can't scroll though it, what's the reason they implemented this function into the coreinit lib? :P

It's possible to register exception handlers that catch things like accessing bad memory addresses and running invalid PPC code. You can't do that much in an exception handler, but it's useful to see why you hit the exception, so you'll often print out all the CPU registers before halting the system. That's one use of OSFatal() that I've actually seen games incorporate. We use OSFatal() for debug printing just because it's so simple and there for us. Relys' OSScreen work allows printing without halting the system, except the OSScreen stuff doesn't seem to work yet.
 
You asked what the bounderies are. Emulators. No backup loaders.
I meant it from a code writing perspective, like:
- Is the executed code being stored into the RAM and if so how much space is reserved?
- Can I use 1, 2 or 3 of the cores? And at 100% clockspeed or lower?

That sort of thing! ;)
I know that there won't be, say...
A 3DS emulator in the userland mode, since there doesn't seem to be direct access to the GPU.
 
love seeing this thread full of potencial homebrew devs xD, lets hope that the wiiu scene picks up and we get the best emulators and apps we can make and somehow make it better than the wii scene with extra processing and 3 cores xD.
 
I meant it from a code writing perspective, like:
- Is the executed code being stored into the RAM and if so how much space is reserved?
- Can I use 1, 2 or 3 of the cores? And at 100% clockspeed or lower?

That sort of thing! ;)
I know that there won't be, say...
A 3DS emulator in the userland mode, since there doesn't seem to be direct access to the GPU.

Currently, you get 0x8000 bytes for code. For perspective, our relatively-complex kernel exploit only takes up about half, as does the Pong game. Something larger like an emulator may not be possible, but that's why there's the kernel exploit. All three cores are available, and good thing they are, because our kernel exploit wouldn't have been possible otherwise.
 
Currently, you get 0x8000 bytes for code. For perspective, our relatively-complex kernel exploit only takes up about half, as does the Pong game. Something larger like an emulator may not be possible, but that's why there's the kernel exploit. All three cores are available, and good thing they are, because our kernel exploit wouldn't have been possible otherwise.
Thanks! :)
Well, what if the emulator is written in ASM? :D
(Until that's done the kernel-exploit might already be released, but... at least it would have some performance! ^^)
What about GPU access and clock-speed? :rolleyes:
 
How about dynamic code generation and execution (e.g. a JIT/dynarec)? Are we able to do that with the current environment, so that emulators will run better? Or does that require the kernel exploit (or IOSU if it's that sensitive)? In fact, does the Wii U have any sort of NX (not the NX mobile stuff, I mean Non-eXecute) bit/DEP?
 
  • Like
Reactions: VinsCool
wow! i hope some good dev take attention to this amazing work! 1year from previous osfatal release it's very long time! NWplayer123 marionumber1 nothing? no one userland program? example?
 
How about dynamic code generation and execution (e.g. a JIT/dynarec)? Are we able to do that with the current environment, so that emulators will run better? Or does that require the kernel exploit (or IOSU if it's that sensitive)? In fact, does the Wii U have any sort of NX (not the NX mobile stuff, I mean Non-eXecute) bit/DEP?

The browser exploit actually copies your project's code into the browser's JS JIT. You can switch this JIT between executable and writable, but it can only be one at a time, so you need a ROP chain to copy stuff into the JIT and get back to your original code. This is a pain, but certainly doable (we somewhat do this in findcode). Of course, having a PPC kernel exploit means that the memory protection rules suddenly don't apply anymore, and you can make any region of memory writable and executable.
 
Looks like things are starting to get exciting after the damp squib that was Nintendos E3. Respect to all involved.
 
The browser exploit actually copies your project's code into the browser's JS JIT. You can switch this JIT between executable and writable, but it can only be one at a time, so you need a ROP chain to copy stuff into the JIT and get back to your original code. This is a pain, but certainly doable (we somewhat do this in findcode). Of course, having a PPC kernel exploit means that the memory protection rules suddenly don't apply anymore, and you can make any region of memory writable and executable.

Thanks for the reply. I've never messed around with JIT-related stuff, but if I was going to, I think I'd hold off until the kernel exploit is out.
 
If I connect to the internet and quickly change my primary DNS to 192.168.0.0 and secondary to 172.0.0.1 like NWPlayer123 said any pages back, will my console install the partially downloaded update and brick itself?
 
Do it like this.
Make a new connection. Type in incorrect password for router and save it. Then go back and correct the dns and password and connect :)
 
Wow.
I just realised that the code has to be with the html file! :wacko:
What ways are there to link my Wii U to my PC via network to call the html file?
Or can you add code that loads code from the SD card @Adr990 ?
(Don't know whether it's possible in userland or not! :( )
 
Or can you add code that loads code from the SD card @Adr990 ?

If I recall correctly they said that SD access was a huge pain in the ass due to the browser not having permissions to use it at all, and would need to exploit a game like Smash 4 in order to gain the needed access. USB is far, far more realistic.
 
And is that really a bad thing? To some, I'm sure it is, somehow.
the thing is most devs dont want to work with nintendo sdk its much harder to make an emulator if you have to follow the sdk thats why the 3ds homebrew isnt too advanced still, having full acess makes codding much easier since you dont need to know and call every functions you can straight up code.
 
And is that really a bad thing? To some, I'm sure it is, somehow.

The Wii U doesn't have any games worth pirating, so for me at least, it'll be a nice upgrade from the original Wii in terms of homebrew capabilities.


Wii U / (v)Wii
  • 1024MB userspace RAM / 64MB userspace RAM (yeah there's another 24 or something in Wii/vWii Starlet land, but let's be realistic here, the Wii U has more or less 16 times the amount of RAM usable).
  • 3 cores running at ~1.24Ghz / 1 core running at ~729Mhz
  • Support for all Wii controllers out of the box for all applications / Supports only older Wii controllers (sort of an apples to oranges comparison here, since it's only logical that the original Wii never got a Pro Controller update) without 3rd party libraries that have to be linked into EVERY application
  • 4 USB ports / 2 USB ports
  • All system calls are built into the OS (i.e. the SDK libraries), reducing the burden on the programmer to keep their development kit up to date / Requires a homebrew library that needs to be linked into EVERY application
So to me it's a no-brainer, the Wii U will be a really pleasant platform to program for compared to the old Wii, once the 32K code limit and such are worked around or eliminated.
 
Last edited by daxtsu,

Site & Scene News

Popular threads in this forum