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

[Ninja_Carver]

comex, I don't know you, but I know you've done a lot for the community and thus have earned my respect (for what its' worth). However, for a guy with your intellect and knowledge of this arch, I'd have expected a bit more from you than just popping in every few hours and shitting on our parade. After all, you know, the vast majority of us are novices, struggling to get by. So be a man, put some work in with us, get your hands dirty! We don't need to get demotivated this early on

And I mean this in the friendliest, most non-hostile manner possible.

 

[Ninja_Carver]

i am in no way downplaying any support given to us so far by the pros. Much appreciated. In fact, we got all excited over this binary compiling and that wouldn't have been possible without some pokes/jabs at us. I guess from the magnifying glass perspective, we are the ants, and sometimes we're fun to burn.

Can't blame. But can bitch.

 

[Maxternal]

I think [user]comex[/user] and marcan ([user]marcan_troll[/user] actually IS his GBATemp account) kinda want this to be something we all do on our own for the most part, offering only minor clarifications, to better gauge how much effort we're willing to put into this project.

 

[comex]

LOL, so you can COPY it but just don't convert/change it at all?

No, that's not what I meant. The point is that even though such code was manually converted from assembly to C, it was still essentially a direct copy of the logic. Certainly there are some APIs which are simple enough that there is only one reasonable way to implement them, but AFAIK the copying went far beyond that.

 

[comex]

Regarding "the wad part", if you install bootmii-ios into an unused slot it shouldn't cause a brick, and I vaguely think it would run correctly, but I'm not sure.

 

[Maxternal]

Maxternal is going to be an expert after this.

LOL, little by little.

I am having fun learning, though. ... slowly be it though it may.

 

[marcan_troll]

might have been motivating/challenging us or was serious (I don't know him well enough to be sure).

Both. I doubt the people currently on this thread will manage to get where I want this to go (unless comex handholds you all the way through). On the other hand, not trying is a sure-fire way to never get anywhere.

I started writing assembly in 1999, wrote my first ARM assembly and GBA homebrew (no libs, raw register access) in 2002, wrote a PS2 firmware mod similar to UNEEK in 2004 (memory card emulator using USB storage), ported Linux to a new board platform (not a new SoC) in 2005, reverse engineered the Wiimote in 2006, and didn't feel like I really contributed to console homebrew until 2008 when I started helping out with the Twilight Hack and HBC. I wasn't going for a speedrun, but it does take time nonetheless.

 

[rednekcowboy]

Both. I doubt the people currently on this thread will manage to get where I want this to go (unless comex handholds you all the way through). On the other hand, not trying is a sure-fire way to never get anywhere.

I started writing assembly in 1999, wrote my first ARM assembly and GBA homebrew (no libs, raw register access) in 2002, wrote a PS2 firmware mod similar to UNEEK in 2004 (memory card emulator using USB storage), ported Linux to a new board platform (not a new SoC) in 2005, reverse engineered the Wiimote in 2006, and didn't feel like I really contributed to console homebrew until 2008 when I started helping out with the Twilight Hack and HBC. I wasn't going for a speedrun, but it does take time nonetheless.

I don't think they are looking for hand-holding but some mentoring and a helping hand every once in a while, I'm sure would be greatly appreciated by everyone involved. Particularly if it's beneficial to everyone....

 

[Maxternal]

Well, I understand that the ULTIMATE goal would be a Linux port here. I, myself, just started this thread as a hope to help others in group collaboration ... but I had already started playing around with stuff so I thought I'd post that out there, too, and keep working on it.

A Linux port is probably beyond me but I do hope to make AT LEAST SOME way for basic Wii homebrew to take advantage of the other cores. (even if it doesn't lead to true Wii U homebrew ... but that would be nice, too) Even then, my attempt will be very limited at first (like no stack and global variables only for the other cores ... or creating a second thread, pausing it permanently and hijacking it's stack to allow local variables and function calls ) but hopefully something to build upon.
... and it's definitely more than we have had up until now but I DO hope someone else can build upon it, too.

 

[marcan_troll]

I don't think they are looking for hand-holding but some mentoring and a helping hand every once in a while, I'm sure would be greatly appreciated by everyone involved. Particularly if it's beneficial to everyone....

Sure, it's just that the amount of implied complexity, while not news to anyone who has worked on low-level PPC stuff before (or who has worked with any other modern architecture and can read the PPC documentation), is IMO significantly beyond the level displayed in this thread. What about caching? Coherency? Context-synchronizing instructions? Do you know what the BATs are and how to set them up? How do you write PPC exception-handler code that correctly switches between translated and real mode? Do you know how to set up the stack and TOC for PPC code? Do you grok the Wii's memory map, virtual and physical? Or even more practical: do you have any hardware debugging interface to test this? You can't exactly use printf to screen when working with low-level bringup (hint: I hooked up my sensor bar output to a USB serial converter to get a low-level debugging output, and later a USB Gecko to the POST debug testpoints).

These are all things that are easy for someone with experience to work out (even if they've never worked with the Wii U before), but if you've never heard of those topics, you don't need "mentoring and a helping hand". You need to learn about them, and learning takes time (and trial and error).

Keep in mind that the code that I posted is an outline, not a recipe. It's not "what you should do", it's "what Cafe OS does which you may find useful". Some of it won't apply to vWii mode (e.g. may crash or misbehave). You will have to determine what is needed and what is not. You may have to work out what some of the bits mean by trial and error. So far most of what I've seen on this thread has focused on translating my pseudocode into assembly (the first shot was very broken C). The thread title is already an indicator that this is wrong: the goal isn't to get someone to "code" 3-core support, because "coding" isn't nearly enough. You can't just translate pseudocode to assembly, because that's a) not going to work, and b) not a real indicator of useful interest. The goal is to get someone experienced interested enough that they take the idea, reverse engineer / work out the details, and do something useful with it, like start a Linux port. Half a dozen people struggling to write valid PPC asm are going to have a hard time.

My point: feel encouraged to keep hacking at it, but don't come crying if it doesn't "just work", and don't be surprised if I'm not convinced once you do get the extra cores executing some instructions. You may need to lure in someone with more experience.

 

[Maxternal]

Thanks for putting that in perspective. Don't worry, not discouraged. Even just starting this I've been enjoying learning as I go. No worries.


EDIT : but I DO hope we're not the only ones working on this. From the beginning I just hoped that there's someone more experienced sitting at home that hasn't connected to the Internet for days, trying to get this working the right way.

 

[comex]

Linux handles SMP and ppc, won't it puck that up and use the processor accordingly?

At the very least you need to figure out how to tell it about the new cores. It will not do anything automatically or magically, including most of the stuff you were talking about before. (In this case you would also have to understand Linux enough to know how to patch the kernel and pthreads to deal with the quirk mentioned in the blog post.)

Many have privately said the Wii U is a lot like the 360 but less security; you would known for sure. Nobody else knows when is talking.

The Wii U is, as a whole, less secure, but that's for a multitude of reasons and the systems are very different.

p.s. I don't remember when I started reading/writing assembly, but I did it in order to (epically fail at trying to) reverse engineer a checksum used in Brawl. Brawl was released in March 2008, and I knew enough to release Bannerbomb (which was not so amazing but at least a marker that I knew how to reverse engineer and modify assembly) in May 2009, so... don't be discouraged!

though i still can't do a lot of the stuff marcan can do anywhere near as well

 

[Deltaechoe]

Wow, ASM makes my eyes bleed, but it is something I want to learn for sure; I've yet to find useful info on getting started. Glad to see people rolling things into motion.

Assembly gets easy once you find the documentation for the architecture, go find the power pc documentation and have fun

 

[the_randomizer]

Assembly gets easy once you find the documentation for the architecture, go find the power pc documentation and have fun

Just like that? Aren't there certain prerequisites that I need to have, like, basic programming skills? C/C#? Because I don't know a lick of programming, like, at all. Okay, there's hex, binary, syntax, int, etc. but just diving into pure PPC ASM? Wouldn't that demotivate me in any way, to start with machine code?

 

[comex]

Yes, you should not be diving into assembly without knowing at least one programming language well. (C is preferred, but some people who know a higher level language might find the simplicity of assembly easier to learn than C...)

 

[Ray Lewis]

Respect to those working at it, thanks for the reply Comex. Always have respected you, thanks for everything.

 

[the_randomizer]

Yes, you should not be diving into assembly without knowing at least one programming language well. (C is preferred, but some people who know a higher level language might find the simplicity of assembly easier to learn than C...)

That's what I thought, that would be hell on earth. Besides, I don't know if programming is for me anyway---I might have to continue this tangent on other thread or a PM.

 

[Deltaechoe]

The prerequisites are that you know how bits, memory and the chipset work. Knowledge of programming languages may help but isn't necessarily required

 

[the_randomizer]

The prerequisites are that you know how bits, memory and the chipset work. Knowledge of programming languages may help but isn't necessarily required

Again, I don't know if programming is truly for me. I've had too many bad experiences in my programming class at my university this past semester. I simply cannot grasp certain concepts or so it seems. Unless there was a way, like an assessment or placement test of sorts, maybe, but until then, I have to figure something out, what I want to do.

Until then...I'll be keeping my eye on this thread as I've nothing to contribute.

Adieu.

 

[Ray Lewis]

The prerequisites are that you know how bits, memory and the chipset work. Knowledge of programming languages may help but isn't necessarily required

Thanks Delaechoe for stopping in. God knows we need all the help we can get. Well, to be honest, Maxternal.