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

[rednekcowboy]

Glad to check and see new help. This is exciting and should show Marcan that some have interest. I cannot learn to code quickly enough but will test

Ya, what's being done is obviously over my head lol but I'd be a willing tester as well!!

 

[Andy A]

There needs to be some sort of project management going on here deciding on beta testers and where we are as a whole as we can't really just post stuff into the wild unless it has been tested because people will break things and complain, anyone want to try organise that?

 

[Foxi4]

If this can be done in Assembly, it can be done in C as well as long as someone takes the time to make libraries for vWii. The information should be posted on DevkitPro forums since that's the most popular coding environment for the Wii/Gamecube - I'm sure the masterminds behind libogc would love to fiddle around with this.

If there was a stable framework made for controlling all those jumps between cores, it could effectively be implemented into a "libvWii" the way I see it.

 

[rednekcowboy]

There needs to be some sort of project management going on here deciding on beta testers and where we are as a whole as we can't really just post stuff into the wild unless it has been tested because people will break things and complain, anyone want to try organise that?

I vote Ray for this he's great at bringing info together, not to mention that he doesn't seem to mind approaching seasoned devs should you guys need some help along the way. I'd do it, but I've got a few projects going on at work right now that will take up a lot of my time. When it comes time to test though, I'll make room in my schedule for it.

 

[the_randomizer]

Given the fact that code can be written to initialize the three cores in the CPU, would programs like Wii/Not 64 benefit from a potential speed boost so long as it was optimized to take advantage of said cores? Or would it not be effective to do so?

The only issue I could see is that adding the multi-core support would break something in the code, such as the speed hacks extrems made to the code for Not 64, I don't know, but one might be able to remove the virtual memory/NAND speed hack as it likely wouldn't be needed anymore. Just an idea.

 

[Maxternal]

If this can be done in Assembly, it can be done in C as well as long as someone takes the time to make libraries for vWii. The information should be posted on DevkitPro forums since that's the most popular coding environment for the Wii/Gamecube - I'm sure the masterminds behind libogc would love to fiddle around with this.

If there was a stable framework made for controlling all those jumps between cores, it could effectively be implemented into a "libvWii" the way I see it.

this is kinda the goal of this, make a 3 core library. The same framework could be needed for a linux port, too.

About the assembly, it's just that I chose to start with the part that was already most spelled out for me. Most of what that part was doing, though, was setting special purpose registers to change the configuration of parts of the processor. Even when writing in C the only way to do that is to add a line of assembly. The only real C in that part would have been if(), else and while() so it only made sense to do that part ALL in assembly. It will still link into and be launched from C code.

 

[the_randomizer]

3.)
Still a long way away from that. Good thought, BUT, we need to have the skilled ones finish the three core part, THEN worry about the linux port. I usually check f0f twitter, then Maran's personal twitter, and finally Comex's twitter. The blog comments and the RESPONSES (touch of espresso) are golden. You can click on "Reply" or "Replies" and it shows what f0f gives. One person made an argument just as I would.

The response; basically does not think it is worth it, does not give a crap if piracy comes from the pirate chip makers (wishes them well basically), believes HBC is too much work and was tough to get going (called it a mess basically). Believes with no "homebrew" sdk that development will not be there. LOT of work to get this going also. Ah, what else can I paraphrase? Liboc (correct name?) for Wii was one thing but the work to get that onto Vii U seems too tough of a task. STILL believes Android and other stuff makes homebrew meaningless for locked gaming systems. Said gave what he had to 31 people who have not done anything with it. Lol, like the dev kits really. Like EA, does not think it is worth it (Wii U). Believes if others unlock it or something that it would be like "hodge podge" and patched garbage (basically, paraphrasing, how I interpreted this response).

I go back to the 360 reference myself. With piracy here already, why not have HCB on unlocked Wii U mode? Why not get ahold of an SDK and make homebrew just as one would make official apps/programs? Marcan, in the blog post, says that getting vWii with 3 cores and a linux port will not be "Fruitless" I believe (again, how I read it). He said it would show interest. I THOUGHT that sort of meant he would reveal more as it would lay the groundwork for dev stuff on the Wii U. Linux, drivers included, etc. Sure, as a base, but here is my idea. The experienced will probably explain why this is not possible.

360 was hacked, with JTAG. Nand was read, then MODDED with applicable files. Checks were disabled as well. From there, programs were added, tools, stuf for saves, for file managers, etc. Could always recover with nand flash if needed. Could get keys, and had that backup. It would be easier if Wii U does not have efuse to prevent applying just any update. The Wii U has a LOT in common with the Wii U BUT missing a lot of the security (some of this provided in private). It all began with the basic start.

1.) Need keys (CPU and any other applicable keys).
2.) Need way to recover. Comex said he did not get keys and could not solder before playing with an IOS (see this thread).
3.) With memory having no firewall (per Marcan himself), some fundamental errors in system design, some with abilities SHOULD be able to trace what he did. MAYBE not the reverse engineering with pure understanding.

Unless lying, Marcan made it seem that once in, there was no security. I've read everything public. Some arm processors, a way the GPU in vWii mode will not run the gamepad (he may have found workaround, as he reversed the ENTIRE system). Unless there is something nasty in there, this may even be easier in comparison to the Wii. Wii needed tools to boot into in CASE nand had errors (recover bricks). This was later patched for newer Wii's and I want to say updates (not sure, I used tools, did not track hacking STUFF). He has provided plenty of details that I am POSITIVE the "initiated" could use to trace his work.

360 taught me that official dashboards could be modded to take out security functions. People then made or patched together .xex files (exe for 360) for things like reading/flashing nand from inside the OS, file managers, remove disc checks for games saved to hard drive, etc. 360 even had "Xell" that, using it's magic, booted and gave the CPU and DVD keys, lmfao. I did RGH stuff, nand stuff, and the dev stuff on 360 was awesome. Later, freestyle dash was made, then a program to even CHOOSE which order to boot in (well, what to boot into or what to HOLD a button or combination to boot into). Trainers came around for games, and I want to say 360 had some memory challenges.

Anyway, not to digress too much. people said they did not use the official sdk for 360 as it was "Illegal." Official dashboards have all information needed. This would also save time and with full control, it would be a LOT easier. This 3 core vWii idea and linux is great, I still WANT TO PURSUE THIS. If we can only access 3 cores, this does help, but no gamepage (not in Wii U mode and GPU was made to deactivate gamepad if not in Wii U mode). Imagine the homebrew and programming INFO available with full dash control? Pirate chip makers don't want this, and everyone knows that piracy is always a part of homebrew. MOST of us on this thread would likely agree with this, I bet. "Wii U mode is what we eventually want to able to dev in." Ports of GC stuff, Wii stuff, check out the threads asking about this. Using gamepad, different scaling (always a way, people find it). IF GPU can, then with software somebody will find a way.

IF this linux and 3 core project could lead to a dev BASE for Wii U mode stuff, hey, great. I won't lie though, just as I think this project is good, and I am GLAD people are helping, I also want full Wii U mode control. I am not convinced if we get this done that Marcan will say, "Okay, you showed interest, good base there, here is how to continue...." I secretly hope some, one of which has exchanged PM(s), can get the keys, and the nand, and maybe find an easier way to get those. Wii needed infectus or else you were flashing with system on (and reading). EVERYTHING began on 360 with these basics. Have nand, have control, way to recover, UPDATES were screened and security was checked (with tools like Marcan's scraper, it would be easy to see changed files, and I am SURE that some could find a way to check the differences for changed files from ones on there before the update. If you can get keys, then you could change the nand and re-sign. I think, as I read a LOT, people forget this; 360 began with this basic "Piece."

1.) 3rd party support? --Is what it is, and if units sell and sales pick up, just like other systems like 360/Wii, devs still show up as piracy and mod levels would not be dangerous (never have been in history). At this point, what is there to lose when dev kits are being returned?

2.) Prevent piracy? Pirate chips are going to make $ out of allowing theft of games; not getting full control benefits only those leeches who use knowledge to exploit. Older "freedom" based hackers are rolling over in their graves.

3.) No dev work? WE are trying here and as I've said above, with Wii U control, keys, way to recover from even the WORSE bricks (hardware flash nand), other tools and information can be found. Hell, the internal processes that are not hardware based would all be mappable and discoverable. Probably to MOD a file, see format for coding, pick up a lot, and work from there (just like with .xex files). I am convinced by experience and participating (even with only monitoring and analyzing) 360 stuff from jtag to RGH (reset glitch hack). A guy on a forum suggested it as he believed processor was vulnerable to this type of hack and was not taken seriously at first. Others looked at it and said, "Wow, he has a point." LOL, dual boot nand or "eMMC" anyone? NOT sure if this is possible but I am imaginative.

Why not take the 360 approach? Another basic; remove automatic updates (lots of ways to do this, it is software based), or find way to cut something off it anything IS hardware based). 360 blocked access to update servers, and once in people really went deep. Prevent updates, analyze updates, have ways to apply updates without taking direct and official updates. Some still preferred mod child, and for 360 the firmware hacks. This is going to be done REGARDLESS.

I keep thinking about, "Too much?" ONLY argument I can think of for not going all out is to give Nintendo a chance to get games out, the HEAVY hitters. The Zelda, the Mario, the Smash Brothers, then see if it sells units. I love Nintendo, always have, and always will. I grew up on it. I would literally go into most homes and see a Wii there!!! Grandpa/grandma, games for the kids, people I visited for work (case manager, children with disabilities). MANY had a Wii. The exclusives MANY hardcore gamers had a PS3 or 360 also. Wii and 360 were the most hacked systems, PS3 was last, coincidence in sales? EVEN if somebody did this, I would not blame them for giving Nintendo that chance. If enough units sell, then I believe 3rd party devs will see earning potential. CAPCOM seems to be interested, Resident Evil game coming (no excuse to make one for 360/PS3 but not Wii U). Capcom seems to be on board. I need to look for more but that is a big one. Lol, interesting to use gamepad to have special moves on there, push one button for a dragon punch with Ryu or Ken, lmfao. EVEN if somebody sent a PM to me, I would say, "Lets be sure we can get the keys, hard flash nand, confirm there is no efuse, look into the software checks for updates and see if update servers are different from normal online functions and if they can be locked, lets see about snagging updates and not installing them (could be done from system itself with correct coding), then lets see what can be learned from the official dashboard by dissecting THAT. Rest can come with people who are creative. LETS get this done, then give Nintendo a chance to get some HARD HITTERS out. Sure we could test it, and we WILL, BUT we sit on it until after the big N gets that shot at 3rd party support and after this, we look at the release."

Forgive the novel, but this all came to mind after reading the responses from f0f. While good at reversing hardware, if Nintendo has no memory firewall for RAM (how Marcan described it), and I would believe signals and memory is not encrypted, then for those with the right approach, getting what I mentioned would not be nearly as hard as the 360. Others may see this, LIKELY considered it. If they do it, hey, great. To a few who I've talked with, PLEASE KEEP ME POSTED. If Marcan is going to give more, as he knows this will all come to pass in time anyway (piracy already happening, 3rd party support not there yet as earning potential is low with units sold thus far)...then I think this 3 core work will provicde fruit, and the linux port would still be COOL. Many devs may come to the fold due to this also and THEN be interested in more. IF this is Marcan's plan, BRILLIANT. I absolutely understand this and respect it. HOWEVER, all the other stuff, the "Android is easier" and "Other ways to do this" and "7 years ago this stuff was not easy"; bullshit. Android, laptops, early Android "pads", networking tools (hardware and MUCH software), open source (smart of him to buy unlocked phones only, nexus phones, smart move there); LAPTOPS. People could stream and remotely connect to networks (stream to/from any computer). Times change, people change, and I don't blame him for saying he has no interest in dev-ing like liboc for Wii. Likely a lot of that COULD apply to vWii, only thing changing is 3 cores, AND linux if it can be ported. Most of what is there for Wii is being ported to vWii (what I've read). Not sure devs will necessarily jump to vWii as not sure how much 3 cores will necessarily improve some things. It is not just a processor that would improve Wii stuff, but the FULL WII U GPU, lmfao.

Time for bed, I apologize for the novel. But I say what I feel and think. I TRY to consider Marcan's views, which we say f0f but it is no secret he is the ring leader, or at least the front man for PRESENTATION and communication. I read everything public, and while I concede anything waiting until AFTER Nintendo gets out exclusives out could have meaning, I also believe opened systems will not be life/death. If anything, it would lead to more sales, and exclusives will be what makes/breaks this. Lol, could be dead after exclusives. Seen any ads for Wii U? I have not seen any lately. Nintendo must strike now and I believe with exclusives and correcting marketing (NEW system) that Wii U will live/die. Shit, at stores, they COMPARE Wii U and Wii next to each other (like specs for computers). People only care about, "Latest and greatest." There are too many errors to list. Even for the neophytes, I do have a Psychology degree and a Sociology minor, and a WORLD of experience in reality. The common people want the latest/greatest, the stuff pushed by sales personnel, and whatever gives the best Mario/Zelda/Smash Brothers. 3ds owns the portable market, those exclusives are NOT on Android, lmfao. Mario Kart? I forget about that game. Anyway, I don't buy all that Marcan says, nor does he care. I will check in, but needed to get this out of my head. In reality, when it seems people hate your guts and all you stand for (even those who claim to love us in sickness and in health), at least one can feel like they matter, if even for a second (until flaming starts, lmfao).
To those here, I hope you say, this is cool work, will have benefit REGARDLESS. IF possible I would love to see a linux port for Wii U also Still a lot here for vWii but with good people, I think there will be a breakthrough to test. Okay, now off....

*Brain explodes* yeah, I'd best not post here anymore. I've nothing useful to contribute, so yeah. It's not that I don't understand the basics of programming, I just come reading this thread multiple times throughout the day, so I'll refrain from clogging this thread anymore than I've already done. I'll continue to follow the scene and see how it goes (very exciting to see some action on the Wii U), but I digress.

 

[izzydeank]

What the hell was all that stuff Ray Ray?

 

[Maxternal]

Given the fact that code can be written to initialize the three cores in the CPU, would programs like Wii/Not 64 benefit from a potential speed boost so long as it was optimized to take advantage of said cores? Or would it not be effective to do so?

The only issue I could see is that adding the multi-core support would break something in the code, such as the speed hacks extrems made to the code for Not 64, I don't know, but one might be able to remove the virtual memory/NAND speed hack as it likely wouldn't be needed anymore. Just an idea.

unlike other platforms where if the program was already split up into several threads, when you move that app from a single core machine to a multi core machine it automatically splits the threads among cores. (this IS what it would be like with a linux port, though, which is what marcan considers ideal.) with this, each app would have to decide which parts go onto which core and that would take a little reprogramming. If not reprogrammed, everything is just crammed onto core 0 as before, no changes, nothing broken.

The other, 3rd option that Marcan DOESN'T like is incorporating it into libogc. With that, all existing apps would have to do is recompile with the new libs and it's threads would automatically be sorted onto different cores. The reason Marcan doesn't like that idea is that he sees problems that libogc already has and that automatically sorting (or "scheduling") the threads onto the cores is a lot of work and he doubts that the writers of libogc would do it well/correctly. Linux already has that built into it as well as that it can deal with the rest of the hardware already so that's seen as ideal.

 

[pwsincd]

WTF .. FFS wheres the tl;dr ? OMG Ray .

 

[JoostinOnline]

I'm sure the masterminds behind libogc would love to fiddle around with this.

Meaning Nintendo. libogc is mostly just reverse engineered (another way of saying "stolen) code.

 

[Foxi4]

Meaning Nintendo. libogc is mostly just reverse engineered (another way of saying "stolen) code.

Meaning people who reverse-engineered it, as it didn't pop up out of nowhere.

 

[Bladexdsl]

What does ffs, tl;dr mean?

ffs: for fuck sake
tl;dr: too long didn't read

 

[JoostinOnline]

Meaning people who reverse-engineered it, as it didn't pop up out of nowhere.

Writing original code, and stealing someone else's code are two different skills.

 

[Foxi4]

Writing original code, and stealing someone else's code are two different skills.

Reverse-engineering code is quite a task Joostin, I wouldn't equate it to a simple copy-paste. Obviously the console's original ecosystem was made by Nintendo, so was any other console's - most homebrew SDK's are based off existing code that was reverse-engineered.

 

[Foxi4]

Lol, and I guarantee anyone knows more about this than I do Foxi4. I think it is still easier than coding from scratch though. Or designing from the ground up. This is pure intuition/gut here. Thanks for visiting Foxi4. If you have not, please PM Maxternal if you see something to give input on. I have not seen anything else like this out for public view.

To be perfectly fair, you can't simply "desing a console ecosystem from scratch" - the hardware registers are there, the functions are embedded and there's literally nothing you can do about it without writing completely new firmware and drivers for each and every chip in the system, effectively changing it from, say, a "Gamecube" into some kind of a monstrosity that merely works on the same hardware. Nobody does that because it's simply unnecessary.

If we're on about completely stolen code, the Dreamcast "Katana" devkit comes to mind - that was an actual instance of an official SDK leaking into the Internet and being used by homebrew developers. That required zero effort and for all intents and purposes could've been considered stealing code. Reverse-engineering registers in an existing system is as much stealing as reading hieroglyphs is stealing knowledge of Egyptian scholars - it's merely reading data that's already there, just putting it in a more readable format.

...unless I'm unaware of something and libogc is based off an existing SDK that was leaked into the Internet.

 

[the_randomizer]

Look, it doesn't matter how it's done, just let it be. Stop the bickering on the ecosystem is developed.

 

[Scuba156]

To be perfectly fair, you can't simply "desing a console ecosystem from scratch" - the hardware registers are there, the functions are embedded and there's literally nothing you can do about it without writing completely new firmware and drivers for each and every chip in the system, effectively changing it from, say, a "Gamecube" into some kind of a monstrosity that merely works on the same hardware. Nobody does that because it's simply unnecessary.

If we're on about completely stolen code, the Dreamcast "Katana" devkit comes to mind - that was an actual instance of an official SDK leaking into the Internet and being used by homebrew developers. That required zero effort and for all intents and purposes could've been considered stealing code. Reverse-engineering registers in an existing system is as much stealing as reading hieroglyphs is stealing knowledge of Egyptian scholars - it's merely reading data that's already there, just putting it in a more readable format.

...unless I'm unaware of something and libogc is based off an existing SDK that was leaked into the Internet.

The official Xbox 360 SDK was leaked and used too.

Look, it doesn't matter how it's done, just let it be. Stop the bickering on the ecosystem is developed.

Actually it does kind of matter how things are done. If any of the distributed executables/binaries contain copyrighted (Nintendo) code then its then illegal to distribute that piece of homebrew which is not the preferred path to take.

 

[the_randomizer]

The official Xbox 360 SDK was leaked and used too.


Actually it does kind of matter how things are done. If any of the distributed executables/binaries contain copyrighted (Nintendo) code then its then illegal to distribute that piece of homebrew which is not the preferred path to take.

Edit: No bickering is happening; all is well. Disregard.

 

[Foxi4]

Actually it does kind of matter how things are done. If any of the distributed executables/binaries contain copyrighted (Nintendo) code then its then illegal to distribute that piece of homebrew which is not the preferred path to take.

There's a big difference between including a copyrighted library from a stolen SDK and a library that's a direct result of reverse-engineering.

A library that was made by reverse-engineering (NOT dumping) and written for a given language from the ground up is not stolen code - it was made by the hacker in question even if it's virtually identical to the original SDK. A stolen SDK is just stolen.

In a similar fashion a stolen painting is just a stolen painting wheras a reproduction is a reproduction - one is illegal and one is not.

Contrary to popular belief reverse-engineering is not illegal all around the globe - in many countries (for example mine) by purchasing given hardware you also logically purchase whatever is in the hardware, meaning the firmware. You purchase an almost indispensible right to do whatever you feel like doing with your system, software, hardware and firmware-wise. This includes reverse-engineering and if the result of such activity is a library that does not contain stolen code, merely references to adresses that already exist on the system, it's entirely legal to distribute it.

The specific commands are already on the system in question - all an SDK does is dictating which commands should be used.