Hacking Coding vWii 3-core support - everything you need to know.

[cory1492]

Maxternal, it is always a possibility that something goes ballistic due to a mistake or misconception resulting in unintended consequences. Don't ignore 1/2 unless you've got a boatload of cash (or wiius) and don't mind waste

Cory, did you see Marcan's post about caching and other things? Curious for your input. Seems you have some interesting experience.

Of course; to be honest my first goal would be to dump the loader's reset vector (unless there is an easier way to decrypt that loader title? I'm betting not, at this point... but maybe they leave it in mem instead of cleaning up after use) to see how it deals with a single core and the mmu/SoC interface... if that is even in PPC land. It would give a bit of a baseline as well, to compare with Fail's blog post, IBM documentation as well as other multi core PPC that I've worked with before (360/ps3.)

 

[the_randomizer]

Wow, even more experts are starting to show up....excellent....excellent indeed

 

[Maxternal]

Maxternal, it is always a possibility that something goes ballistic due to a mistake or misconception resulting in unintended consequences. Don't ignore 1/2 unless you've got a boatload of cash (or wiius) and don't mind waste

Of course; to be honest my first goal would be to dump the loader's reset vector (unless there is an easier way to decrypt that loader title? I'm betting not, at this point... but maybe they leave it in mem instead of cleaning up after use) to see how it deals with a single core and the mmu/SoC interface... if that is even in PPC land. It would give a bit of a baseline as well, to compare with Fail's blog post, IBM documentation as well as other multi core PPC that I've worked with before (360/ps3.)

You could probably dump the decrypted NANDloader (1-200) pretty simply. (if that's what you're talking about) you'd just put an infinite loop over that start instruction mentioned on the blog to trap PPC and then the mini (ARM code) has SDHC code built in so you could just have it dump all the RAM to see what's there. By that point, though, you should have some idea of where the start and end of the NANDbooter is in memory.

If you're talking about the ROM memory it boots from that does the decrypting ... might be a bit more tricky to know where the memory address is for that (assuming it's even accessible after boot) but the decryption algorithms in there could also be quite interesting.

... but alas, I'm just babbling/thinking out loud at this point so I'll stop.

 

[Ninja_Carver]

who needs debugging hardware? link me. I'll see what I can do to get it for you. Assuming its affordable. And unless you know what you're talking about and have proven that so far in this tread don't bother replying.

 

[the_randomizer]

Is there a way to back up the vWii NAND or will there be a way in the near-future?

 

[Quincy]

Oh and by the way, if it is't such a hassle, I am an application developer in progress, and very interested in learning ARM/PPC as wel, so I am keeping a close eye on this thread anyhow

 

[Quincy]

Why would it be a hassle? Lol, watch away, and if you have any ideas then please chime in. Lol, "Your house, robbing your stuff", lol, on second thought...go back outside the gate (joking). Your location is funny. Own personal guitarist, lol, little play off Depeche Mode song? Yeah, nobody minds if you hang around. If you have ideas for Linux, can code at all, and /or know somebody who knows PPC/ARM/coding then maybe mention this to them also.

Well I can code in VBasic, and a little bit C# but that's about it.

It may be far fetched, and it probably is mentioned before, but isn't it a good idea to start with core0 initialization and let that core handle the initialization of core1 and core2? I mean, if one core is up, the other 2 should follow too ^^.

 

[Quincy]

or even: Wiibrew contains code to init the starlet. Couldn't we just modify that to start with all cores instead of writing an all new initialization code snippet?

 

[Maxternal]

It may be far fetched, and it probably is mentioned before, but isn't it a good idea to start with core0 initialization and let that core handle the initialization of core1 and core2? I mean, if one core is up, the other 2 should follow too ^^.

That's kinda what I was hoping for with plan of attack #4 in OP (which is more of what I'm hoping for ATM, truthfully) and having core0 completely running before trying to start the other 2 MIGHT give us a better chance at some debug output without having to solder anything onto the console.

or even: Wiibrew contains code to init the starlet. Couldn't we just modify that to start with all cores instead of writing an all new initialization code snippet?

Since it's a different type of processor, (ARM vs PPC) the init code woul probably be significant;y different for Starlet.

Libogc DOES have the code it uses to init (which is usually what inits core0 when you're running normal Wii homebrew on vWii) and there are other examples that can be found on the Internet of a PPC initialization (OP has a link to a "standard embedded PowerPC init code") The real trick is all the multi-core and extra cache stuff that the espresso has that most PowerPC's don't (most of the terminology Marcan mentioned that has to do with how the 3 cores work together and don't step on eachother's toes, etc.) That will be a lot of trial and error even with following Marcan's lead on his blog post.

Before initializing them, though, it seems the extra cores have to be unlocked with the little trick of patching the 1-200 title Marcan mentioned on the blog. That requires us to be able to run code on Starlet. We're presently (slowly) trying the "easy" way to get that done. If that fails, there's other options but we're just taking this one thing at a time.

 

[Kdonix]

The main problem are going to come with the main execution.

Let me explain why many dev forget about the Wii U, it was not because of the CPU or the GPU at all, it was because they know that it would be easier
to work on PS4 or next XBOX (X86 archi adopted from both company) and the fact for Nintendo, no one is interesting to loose time anymore making games for 2 different archi, take a look, games on Windows (X86), games on PS4/Next XBOX (X86), games on Wii U (PPC), so in the end which dev would be interested to work on Wii U ? (taking more time to execute a simple code PPC vs X86, less code, less losing time)
Power7 is really interesting but no one seams interesting but most of this dev should take a look to the PowerVM and Lx86 library... it would be easy to port any PS4/next XBOX Games on Wii U.

That is the only reason why some big dev abandonned the Wii U Boat and not because of the BS behind the Power7 CPU (this is just a lazy way and baby cry)

Now about the vWii 3-core support, you should really consider the dolphin emulator (they have a plain of source code about it) and it can be useful for testing purpose, if you want you can ask the team if they can take a look to your code, you can also use Qemu or like i said PowerVM (even with lx86) to check how you can improve your code.

But the main problem is that you work 100% on ASM and that is not good at all, take too much of your times working on ASM, you will make many different error and restart again and again, it can take years of years as the main problem of ASM = one instruction take over line, anyway you should try to just improve the execution with it but not trying to make something else, because it would give a lot of fail.

Just to let you know, the CPU include ASM Menu and even ASMI point (but that, only Nintendo can tell you how to have a access on it, usually we use a HMC or try to access when the processus is on standby) as different Power7, the one of the Wii U include unused cores and turbomode core (probably used to improve the execution of the wii u menu but they should just improve the execution of the program/games without using this method but it is the problem of Nintendo not mine) try to exploit this part, also again it is not a 3-core but a 6-core locked, a 3-core by IBM P7 + eDRAM doesn't exist at all... it's just that Nintendo+IBM make 3 core unused just in case and to prevent any problem in the future. Like i said the main problem of the developing on Wii U it is not the CPU but more because that Sony/Microsoft offer a easy way for the dev, that all, remember that the CPU on the PS4/Next XBOX = APU (even the P7 is better) again is not comparable to a Desktop CPU for example but the APU give you a lot of easy way to make your program faster and flexible.

I'm sorry but in my position, i can't help, i don't really have time for it but hope that can help a little on your research of the processor execution.

 

[the_randomizer]

Yeah, porting Dolphin which uses x86 architecture and code if from that to PPC ASM would be no small task and would be an enormous undertaking by the programmers. As to how far one would get on the Wii U CPU or GPU with Dolphin, that's hard to say, even with three cores under full load. Other emulators, like N64, PSX on the other hand, could potentially benefit greatly from the cores.

 

[Kdonix]

Yeah, porting Dolphin which uses x86 architecture and code if from that to PPC ASM would be no small task and would be an enormous undertaking by the programmers. As to how far one would get on the Wii U CPU or GPU with Dolphin, that's hard to say, even with three cores under full load. Other emulators, like N64, PSX on the other hand, could potentially benefit greatly from the cores.

I didn't say to port Dolphin, i say to use as example, you should not that before that dolphin was able to run under X86, you need to know who to work on PPC ASM, that was the team dolphin did to make a emulator X86 capable to execute PPC Code. So they know exactly how to execute or improve the core execution.

 

[the_randomizer]

I didn't say to port Dolphin, i say to use as example, you should not that before that dolphin was able to run under X86, you need to know who to work on PPC ASM, that was the team dolphin did to make a emulator X86 capable to execute PPC Code. So they know exactly how to execute or improve the core execution.

My bad. I misread what you said. As a benchmark or to give a general idea on how custom code can run. Gotcha.

 

[Kdonix]

I was going to post this when I saw that person post all the information. http://forum.wiibrew.org/read.php?29,72883

--Newer, more updated, believe it is graphical interface. THE issue is going to be the coding and stuff Marcan mentioned. Getting that to work with CPU (at least 3 cores if this is correct about the 6 cores) and the rest Marcan went on about. After the debates on the Wii U, I've never seen anything on the 6 cores or the rest. IF true, and everyone missed it, damn. BUT, I wonder if this is BS. I want to see what Marcan says.

Oh you know, i just came subscribe to say my point and try to help by saying a solution, now you don't need to be rude, Marcan or others are not IBM, the fact is that the dev who work closer to Nintendo know exactly what's going on with the CPU but again is not the problem here and i was just hope to see that what i said can a little bit help, i can't help more as i can't tell all about it that will make a problem with my job and i don't have time for it, just to say that the ASM point is not the only solution and not the easier.

Have a nice day or night, see ya, as i'm a bs, sorry if you think that.

It's late in here, sorry if i miss some words, need to sleep

 

[JoostinOnline]

I wish people used better spelling and grammar, because it's hard to understand these arguments.

 

[the_randomizer]

I wish people used better spelling and grammar, because it's hard to understand these arguments.

His English isn't his native language, so we need to give him the benefit of the doubt.

 

[JoostinOnline]

His English isn't his native language, so we need to give him the benefit of the doubt.

If English isn't your first language, it's completely understandable that you would make mistakes. English is a difficult language. Regardless, I'm still having trouble following the debate. Besides, I was talking about everyone, not just Kdonix.

 

[the_randomizer]

Oh you know, i just came subscribe to say my point and try to help by saying a solution, now you don't need to be rude, Marcan or others are not IBM, the fact is that the dev who work closer to Nintendo know exactly what's going on with the CPU but again is not the problem here and i was just hope to see that what i said can a little bit help, i can't help more as i can't tell all about it that will make a problem with my job and i don't have time for it, just to say that the ASM point is not the only solution and not the easier.

Have a nice day or night, see ya, as i'm a bs, sorry if you think that.

It's late in here, sorry if i miss some words, need to sleep

No worries, it's fine, as we can use all the information that we can get. The more the merrier.

 

[izzydeank]

Joostin, thanks for coming by. The guy was saying the Wii U has 6 cores but is locked to 3 by Nintendo. Explained that there are other issues to consider with the processor also. Marcan said nothing about this. Unless I missed something, I have not seen this posted anywhere for public view. 6 cores but locked to 3.

I'm not sure if he was actually trying to say that its a 6 core processor or not. Thinking more of a failed google translate. Seems to be he's just complaining about the Wii U being underpowered and not the same as the PS4 or the next xbox. If he was trying to say that its a 6 core processor, then he's wrong. That would be a waste of money and dumb to have that just to run on 3 cores. The earlier Wii U processor rumors were that it would have 6 cores, so I'm only guessing that he was trying to say that Nintendo chose to go with a 3 core processor instead....big mistake...yada yada yada....translate fail.....

 

[Maxternal]

this sounds like the whole rumor that the last update overclocked everything. sounds bogus. the idea that ninty likes failure so they purposely reduce the power of their hardware is just silly