Hacking Fail0verflow updated with alot of new info

[JohnnyBlaze1986]

My guess is they watched the uh *ahem* little scene that unfolded earlier today.

What scene? I must've missed that.....

 

[the_randomizer]

What scene? I must've missed that.....

You're one of the lucky ones....or are you?

 

[Maxternal]

Might know about it but not interpreted it as a "scene"

 

[JohnnyBlaze1986]

I just got back home and don't follow message boards that often. I was just checking to see if I had any new responses and I saw this.

 

[the_randomizer]

Might know about it but not interpreted it as a "scene"

Disaster, calamity, hell breaking loose, overreactions, and you had to miss the fun.

 

[comex]

Oh Comex, lol. I am fairly certain if I pester you enough or ask nicely enough you may give TIPS. Or if somebody with more skills asked. If they are genuine and sincere, maybe a tip here/there. Thanks for being cool on twitter and not ripping me too much.

If necessary. However, the post is pretty explicit about what to do, so if you know what you're doing, you probably won't need much in the way of hints.

 

[driverdis]

as much as it is cool that they can access all 3 cores (at reduced clock of 729MHz), Marcan did mention that libogc would be near impossible to turn into an SMP-capable scheduler, and mentions that it has other problems too. it seems someone would need to code an alternative to libogc with proper smp support and fixes to the other problems libogc has, that Marcan did not go into specifics about. It seems that until that happens, the other 2 cores would be pretty much useless. without proper SMP support, emulators and other homebrew will not be able to utilize the other 2 cores in such a way that would significantly boost performance.

their blog post makes me wonder if maybe,they could find a method to get access to the extra features of the Radeon HD (that are disabled in vWii mode) to possibly render homebrew/emulators in HD resolutions.

There may be no need to run homebrew in Wii U mode( other then gamepad/pro controller support,faster clocks,and access to the 4/32GB of internal storage), if WiiMode can utilize the horsepower of the Radeon HD and have access to all 3 cores of the Espresso. (downclocked to 729MHz, for now)

the upside is that if someone does manage to pull that off, emulators, like Wii64 may be able to tap into the other 2 cores to finally achieve near to full speed emulation. It would be nice to have a N64 emulator that would play games as good as the custom per game emu that Nintendo uses for each N64 VC Title.
I would love to play Goldeneye, Banjo Kazooie, Banjo Tooie, and Donkey Kong 64 on the vWii since Nintendo cannot release them for VC as Microsoft , who owns Rare, denied them from doing so.

 

[Ray Lewis]

If necessary. However, the post is pretty explicit about what to do, so if you know what you're doing, you probably won't need much in the way of hints.

True. Comex, so are the 31 still "Mulling it over" and possibly made some progress. I did see the part about some being lazy. My skills are following directions and hardware (soldering, multimeter, trace repair, other component repairs). Reversing and coding are my weak spots or I would seriously go at this.

Edit: I don't know them but from Wiiuhax.com, goes to PS3 hacks, and some people on the thread there were talking about doing some work based on the blog Marcan posted. Again, I don't know them, 360 and Wii were what I paid attention to before.

 

[the_randomizer]

as much as it is cool that they can access all 3 cores (at reduced clock of 729MHz), Marcan did mention that libogc would be near impossible to turn into an SMP-capable scheduler, and mentions that it has other problems too. it seems someone would need to code an alternative to libogc with proper smp support and fixes to the other problems libogc has, that Marcan did not go into specifics about. It seems that until that happens, the other 2 cores would be pretty much useless. without proper SMP support, emulators and other homebrew will not be able to utilize the other 2 cores in such a way that would significantly boost performance.

their blog post makes me wonder if maybe,they could find a method to get access to the extra features of the Radeon HD (that are disabled in vWii mode) to possibly render homebrew/emulators in HD resolutions.

There may be no need to run homebrew in Wii U mode( other then gamepad/pro controller support,faster clocks,and access to the 4/32GB of internal storage), if WiiMode can utilize the horsepower of the Radeon HD and have access to all 3 cores of the Espresso. (downclocked to 729MHz, for now)

the upside is that if someone does manage to pull that off, emulators, like Wii64 may be able to tap into the other 2 cores to finally achieve near to full speed emulation. It would be nice to have a N64 emulator that would play games as good as the custom per game emu that Nintendo uses for each N64 VC Title.
I would love to play Goldeneye, Banjo Kazooie, Banjo Tooie, and Donkey Kong 64 on the vWii since Nintendo cannot release them for VC as Microsoft , who owns Rare, denied them from doing so.

Goldeneye's license is actually owned by Activision last I heard, but the other games Microsoft would never allow on the Wii U. Rare only published Donkey Kong 64, Donkey Kong was created by Shigeru Miyamoto and is a Nintendo IP.

 

[comex]

as much as it is cool that they can access all 3 cores (at reduced clock of 729MHz), Marcan did mention that libogc would be near impossible to turn into an SMP-capable scheduler, and mentions that it has other problems too. it seems someone would need to code an alternative to libogc with proper smp support and fixes to the other problems libogc has, that Marcan did not go into specifics about. It seems that until that happens, the other 2 cores would be pretty much useless. without proper SMP support, emulators and other homebrew will not be able to utilize the other 2 cores in such a way that would significantly boost performance.

As much as libogc is apparently lacking, for applications like emulators where very specific repetitive tasks take up most of the CPU, it would probably be relatively easy to dedicate each of the two auxiliary cores to a specific purpose rather than bothering with actual threading. Just speculation though.

 

[Ray Lewis]

As much as libogc is apparently lacking, for applications like emulators where very specific repetitive tasks take up most of the CPU, it would probably be relatively easy to dedicate each of the two auxiliary cores to a specific purpose rather than bothering with actual threading. Just speculation though.

You also said dynamic linking is supported;-) I do pay attention. A joke about 1964 technology. Maybe you get some PMs but mostly just opinions by the neophytes like myself.

Edit: comments on here, not about PMs, obviously I cannot see those.

 

[comex]

You also said dynamic linking is supported;-) I do pay attention. A joke about 1964 technology.

Hmm, how is that relevant? It's the Wii U mode Cafe OS that supports dynamic linking.

 

[the_randomizer]

As much as libogc is apparently lacking, for applications like emulators where very specific repetitive tasks take up most of the CPU, it would probably be relatively easy to dedicate each of the two auxiliary cores to a specific purpose rather than bothering with actual threading. Just speculation though.

That would be quite beneficial to emulators such as Wii 64 and WiiSX, both of which could use optimizations to the code and gain a speed boost while maintaining stability.

 

[driverdis]

As much as libogc is apparently lacking, for applications like emulators where very specific repetitive tasks take up most of the CPU, it would probably be relatively easy to dedicate each of the two auxiliary cores to a specific purpose rather than bothering with actual threading. Just speculation though.

according to this sentence that I quoted from Marcan's post on the Fail0verflow blog, that may be possible.

It might also be possible to use the two extra cores in libogc apps purely for number crunching, with carefully designed locking (outside of libogc) and without calling any libogc functions from the other two cores (or any non-reentrant libc functions).

 

[the_randomizer]

according to this sentence that I quoted from Marcan's post on the Fail0verflow blog, that may be possible.

That would be quite advantageous for homebrew methinks.

 

[Bladexdsl]

Rare only published Donkey Kong 64, Donkey Kong was created by Shigeru Miyamoto and is a Nintendo IP.

and yet they still won't release it on the VC

and what scene i was here earlier and i didn't see no scene?

 

[the_randomizer]

and yet they still won't release it on the VC

and what scene i was here earlier and i didn't see no scene?

Check PM.


Bugger! I can't PM you. I can't explain it here.

Let't just say it's this thread, post #79
http://gbatemp.net/threads/marcan-clarifies.347450/page-4

 

[shakirmoledina]

is the 3ds too easy to hack?

 

[driverdis]

and yet they still won't release it on the VC

and what scene i was here earlier and i didn't see no scene?

I always thought Rare would not allow DK64 to be on BC because of it having their "jetpac" game being one of the minigames to get the rareware coin.
it seems i was wrong as i found this tweet from 2010 from rare claiming DK64 already belongs to Nintendo. they commented on it as people emailed them over that weekend contantly asking them to let Nintendo put DK64 on virtual console.
https://twitter.com/RareLtd/status/25013528136

My guess is that Nintendo could not get it running correctly as a VC game and decided to scrap it. DK64 is one of those problem games that no N64 emulator so far can emulate properly with no rendering errors also.
like this kind of rendering error,
http://i.imgur.com/x5tvv.png
this is not a screenshot i took, i found it on ngemu but this has happened to me.

DK64 also uses its own custom RSP graphics microcode that even emulators like Project 64, have problems emulating. Rare loved to use custom opcodes,hacks,etc to make their games run better on n64. doing so was fine on the hardware
but the side-effect is that its difficult to emulate that properly. my guess is that Nintendo could not get Donkey Kong 64 running correct enough (no graphical errors,and other bugs) to be good enough to put on VC.
all of the released N64 VC games look and play nearm if not identical to the way they are on a real n64.

I do not want to hear all the "But Nintendo made the N64 so they should be able to make it run...", this does not apply as Rare used custom opcodes,hacks, etc to make the game run better on the actual hardware. these are why the game does not emulate right and the reason its not on VC. If rare made the game the same way Super Mario 64 was made(which probably is not even possible), one simple opcode, no hacks,and other tweaks, It would have been perfectly emulated and on VC.

 

[Bladexdsl]

Check PM.


Bugger! I can't PM you. I can't explain it here.

Let't just say it's this thread, post #79
http://gbatemp.net/threads/marcan-clarifies.347450/page-4

sorry bout that i had to temp disable pm's because of AN ASSHOLE.

rydian getting pissed off you call that a scene?