The svn repository is being restructured to accommodate the new projects that make up the SoftChip platform. I'm getting ready to commit elfstrip very shortly. Unfortunately, this will break any automated build scripts, but is very simple for the authors to fix.
On another note, what's all this about decrypted games again? I understand that there are a lot of you out there who have already burned decrypted versions of your backups, but we have advanced well beyond the need for them. Xorlac is making huge progress on the dip, and I've been reversing the hardware aes support. Why continue to support discs in a format that was never intended to be final? If there are enough users who would like to see them supported, then we'll add them as a priority. Support should be ready around the same time as original discs. On the other hand, I'm not convinced Waninkoko ever wanted this decrypted disc format to be available for public use.
Waninkoko, if your intentions were to make a release that supported the decrypted format, that will override any requests we get from the community, and I will most certainly support the format. However, without either a host of users requesting these decrypted discs be made usable, or without your confirmation of intent, this simply will not be a priority.
Basically, it's a simple change to make it happen, but why continue to support something that will only complicate matters of compatibility in the future?
Edit: I didn't mean to come off as rude, overbearing, or harsh. It's just that by supporting this format, we're getting into a legal gray area concerning fair use. Everyone already knows that we do not support piracy in any form, and while making decrypted copies of your backups may not be considered piracy, it may also not be considered fair use. In fact, it may very well be a DMCA violation. We respect the copyright holders, and do not wish to hurt their bottom line.
On another note, what's all this about decrypted games again? I understand that there are a lot of you out there who have already burned decrypted versions of your backups, but we have advanced well beyond the need for them. Xorlac is making huge progress on the dip, and I've been reversing the hardware aes support. Why continue to support discs in a format that was never intended to be final? If there are enough users who would like to see them supported, then we'll add them as a priority. Support should be ready around the same time as original discs. On the other hand, I'm not convinced Waninkoko ever wanted this decrypted disc format to be available for public use.
Waninkoko, if your intentions were to make a release that supported the decrypted format, that will override any requests we get from the community, and I will most certainly support the format. However, without either a host of users requesting these decrypted discs be made usable, or without your confirmation of intent, this simply will not be a priority.
Basically, it's a simple change to make it happen, but why continue to support something that will only complicate matters of compatibility in the future?
Edit: I didn't mean to come off as rude, overbearing, or harsh. It's just that by supporting this format, we're getting into a legal gray area concerning fair use. Everyone already knows that we do not support piracy in any form, and while making decrypted copies of your backups may not be considered piracy, it may also not be considered fair use. In fact, it may very well be a DMCA violation. We respect the copyright holders, and do not wish to hurt their bottom line.
I don't think decrypted backup support should ever be integrated, it has a very small audience and isn't necessary for anything.
However, I do think loading backups from SDHC should be a high priority. Especially because it's easy to implement and can use any IOS, which boosts compatibility up to 100%. Also, SD(HC) cards are mostly faster than 6x DVD reading speed, so it could actually reduce loading times compared to the real game disc.
I don't have much technical knowledge on this front, but I do believe it's just looking at ftpii (for instance) to see how proper SD access is done and then modifying the SoftChip loader to access the SD card for game data. Ofcourse, because of the 4GB limit of fat32 (or fat16) on SD cards, a PC program has to be coded to scrub the backup image of unnecessary data (remove it, not like Wii scrubber, which replaces the data) and then splits the files into 4GB parts (if necessary). That adds some complexity, but I think you could be running a small game like Wii Chess from an SD card in like 2 weeks of coding.
However, I do think loading backups from SDHC should be a high priority. Especially because it's easy to implement and can use any IOS, which boosts compatibility up to 100%. Also, SD(HC) cards are mostly faster than 6x DVD reading speed, so it could actually reduce loading times compared to the real game disc.
I don't have much technical knowledge on this front, but I do believe it's just looking at ftpii (for instance) to see how proper SD access is done and then modifying the SoftChip loader to access the SD card for game data. Ofcourse, because of the 4GB limit of fat32 (or fat16) on SD cards, a PC program has to be coded to scrub the backup image of unnecessary data (remove it, not like Wii scrubber, which replaces the data) and then splits the files into 4GB parts (if necessary). That adds some complexity, but I think you could be running a small game like Wii Chess from an SD card in like 2 weeks of coding.
Not quite. Loading the games from SD or USB is theoretically possible, but it's a lot more complex than just reading game data off the device. The game's code still tries to do its reads via ioctls to the dip module.
Nothing is ever as easy as it sounds.
WARNING: The following statements are purely hypothetical and do not reflect what is or is not possible, only theory.
That being said, we think we've found a way to have at least semi-reliable IPC between IOS modules, meaning with our from-scratch fully open source dip could theoretically communicate with another IOS module (possibly EHCI in the future) to attempt to both catch and redirect the IOCTLs from the dip via a new "IOS Proxy" mechanism.
Nothing is ever as easy as it sounds.
WARNING: The following statements are purely hypothetical and do not reflect what is or is not possible, only theory.
That being said, we think we've found a way to have at least semi-reliable IPC between IOS modules, meaning with our from-scratch fully open source dip could theoretically communicate with another IOS module (possibly EHCI in the future) to attempt to both catch and redirect the IOCTLs from the dip via a new "IOS Proxy" mechanism.
That would actually be kind of a nice solution to a problem concerning DVD backup loading, USB backup loading and SD backup loading. I'm looking forward to your first proof of concept (however far away).requiem4d said:
QUOTE said:
At current, xorlac is chugging away at the code, so we'll hope for a working dip replacement first. Elfstrip and IOS-Patcher will be requirements before it will be useful for anyone, but we'll publish sources as soon as they're available.
Woo! Now it works with my modchip, sadly it doesn't read the disks my modchip won't read, it won't open the partition, but it gets the game ID and stuff correct.requiem4d said:
6x. Read http://pastie.org/286184.txt for the complete story on why we're locked at 3x with backups.
-----------------------------------------------------------------------------------------
and chips are modifiing to always give back 0xFF ? why can´t we just flash it like xboxers do?
-----------------------------------------------------------------------------------------
and chips are modifiing to always give back 0xFF ? why can´t we just flash it like xboxers do?
robiul said:
requiem4d: Please tell them it can't get any easier then this!!!! lol
If you goto this post you can compile your own by just clicking an ICON!!!! We created it so you don't have to do nothing really!!!!!
Download the Installer, install. and that would be the hardest part of it! It download's the SVN for you, Then it will compile it for you, and it will make a WAD for you. Then it will open the folder for you where the dol & wad are!
rename the dol to boot or just copy the wad to the sd...
Alot of for you's huh....
Auto Devkitpro v3.0.1 - Download
This Does everything but copy it to the wii.... oh yeah we can do that to but we are not, lol
Enjoy the release...
By Jfitie & GodSpeed
goku21temp said:
Chips are plugged between D2C chip and drive itself, they will alter instruction sent by D2C chip to the drive. I think the "firmware" is kept in the D2C chip or uploaded to drive at runtime. D2C chip is undocumented and I think it's not even flashable. Even if it was it's not a conventional chip like xbox360, reversing it is not an easy task.
Similar threads
- No one is chatting at the moment.
-
-
@
K3Nv2:
If Jack didn't think about pussy he could've made some friends with a good few millionaires tbh+2 -
-
-
-
-
-
-
-
-
@
Xdqwerty:
@SylverReZ, ok sorry. Btw im worried, there is a spelling bee tommorrow and i barely practiced at all -
-
-
-
-
-
-
@
K3Nv2:
One of my friends wants to do a pc wall build I'm like but you constantly complain about roaches lol
-
-
-
-
-
-
-
