Waninkoko's coding skills are fine. It is my job to comment on exaggerations of his coding skills, and also on his ethics. Not all the time, only when I feel like it, and/or when it affects me directly.Saladman said:
how did this go from the backup loader reading 6x speed to a stupid flame war. all the time big threads end like this
there the people that are just dumb and dont understand how things work, and want everything for free and complain when some homebrew doesnt work. *sigh*, keep up the good work on your current/future projectsmarcan said:
marcan said:
The thread was initially started as I am fairly new to the scene, and wanted to know the ins and outs of the '3x' drive limit as it was the only thing i couldnt really find any info on. The thread produced alot of info, and thanks to a few people (you 'marcan' also), alot of that info was cleared up and explained.
Somewhere along the lines, someone suggested that you may have limited the disk read rate in the DVDX software, and i for one found it interesting and commented on it. Rather than acting all defesive, all you needed to do was say that it wasnt the case like you now have. At the time it was just factless speculation and nothing more, due to the fact we knew the negative effect that piracy would have on you and other coders, so it was thrown in as a possiblity.
The whole point in a forum is to discuss end of. All we are doing is duscussing, and it seems ive stumbled right in to the middle of some scene war.
I aint gonna take sides, as i use software/homebrew developed by both yourself, your group, and also coders such as Waninkoko and at the end of the day everyone has there own opinion. I have massive respect for all coders in various scenes for all the time, and work they put into there projects.
Like i said thanks for clearing things up, but if we could try and get back on topic now?
So right now we may aswell forget about bypassing the 3x limitation for the time being, and be hopeful that someone is working on another method of booting backups?
Cheers
I'm sure we can already do that using DVDx and some extra coding. No need for a backup loader. Just make a launcher that reads the data off the DVD from the homebrew channel.Haruhi said:
100% of people using the backup loader are either
1) Trying it out once or twice and then giving it up due to how slow it loads and how buggy it is
2) Using it to pirate.
No one is going to bother using such a buggy loader to play their "backups".
Ok, lecture time. Pay attention there in the back.
I'm going to show you that we're not trying to limit the drive to 3x, or whatever.You could easily
see this in the libdi code, and test it out for yourself, but for the sake of sharing some information,
I'll walk you through the boot process of the drive, and how we communicate with it.
The boot process of the drive is fairly complicated, so I'll just talk about the key points here.
If you want more information, come look me up on #hackmii or #wiidev on EFNet.
All of the following code is written in the non-reprogrammable mask ROM of the drive. We cannot change this
code in any way or shape, save with a modchip.
When you insert a DVD into your Wii, it will start it's internal DiscLogin statemachine. This is a huge
piece of code, which does everything that is required to get to the point where you can read the disc.
Everything up to about half of the statemachine is not all that interesting, that part mainly deals with
calibration and reflectivity detection and whatnot. The interesting part comes at state 0x7F. This is
the state that does the filtering between GC, Wii, and other discs.
Digging around a bit in state 0x7F yields this interesting bit of code:
ROM:0008AA43 movbu (0x40880C), D0
ROM:0008AA48 and 0xF0, D0 ! ''
ROM:0008AA4B cmp 0xF0, D0 ! ''
ROM:0008AA4F bne loc_8AAB5
ROM:0008AA51 movbu (0x40880C), D0
ROM:0008AA56 and 0xF, D0
ROM:0008AA59 cmp 0xF, D0
ROM:0008AA5B beq loc_8AA5F
ROM:0008AA5D bra loc_8AAB5
Now, if you've done a little digging around in the drive firmware, you know that at 0x408800 is the first sector of
the current disk. The very first sector of a disc contains stuff like size, and media code, stuff like that.
At offset 0xC of a disc resides the booktype. So what it's doing here is checking for booktype 0xFF (Which is a Wii disc).
If it's not 0xFF, that specific function will return non-zero.
Moving with the resulting codeflow, we see this occur:
ROM:0008F6D7 mov (8,SP), D0
ROM:0008F6D9 or 0x18, D0
ROM:0008F6DC mov D0, (8,SP)
And later:
ROM:0008F7BA mov (8,SP), D0
ROM:0008F7BC mov D0, (0x8576)
This (and only this) sets the lower byte of 0x8576, when we fail the 0xFF check. Keep this in the back of your mind please.
(More checks are done on 0x40880C, part of the reason why you cannot use DVD+R's without bitsetting, but that's for
another time).
The disclogin continues, and ends up in state 0xF2. So, the disc is now logged in. However, as some of you might have noticed
(maybe, possibly), we can only access the DVD at 3x speed. Far slower then the 6x speed I can access a normal Wii disc at.
But aha! Nintendo seems to have foreseen this little problem, and added a nifty function for us to use:
DVDLowSetMaximumRotation, a.k.a SetSpeed.
No luck though, issuing the command does nothing... So, why does it do nothing?
Sending a command to the drive results in the LL controller (the big chip) poking the mn102 with an interrupt. When we trace this
interrupt, and reverse some rather nasty jumptable algorithms, we find the code that gets run when 0xDD is sent to the drive. Digging
a little in the code, we find this:
ROM:0008259E mov (0x8576), D0
ROM:000825A1 btst 0x20, D0 ! ' '
ROM:000825A4 bne loc_825B6
But wait, thinking back a little, we saw that the lower byte of 0x8576 was set to 0x18. btst 0x20, 0x18 will fail, because bit 0x20 is not set in 0x18.
This results in the code skipping the actual speedsetting. And there's nothing we can do to bypass it.
Now, I'm not saying outright that you cannot kick the drive into high gear, but let us think about it for a second. This mode
was put there to allow playback of regular DVDVideo. Reading a normal DVDVideo disc means you're reading everything sequentially. There is
no need for high speed reading here. Why would you allow 6x speed reading, when you're not ever going to use it?
-- Erant, bushing boy.
I'm going to show you that we're not trying to limit the drive to 3x, or whatever.You could easily
see this in the libdi code, and test it out for yourself, but for the sake of sharing some information,
I'll walk you through the boot process of the drive, and how we communicate with it.
The boot process of the drive is fairly complicated, so I'll just talk about the key points here.
If you want more information, come look me up on #hackmii or #wiidev on EFNet.
All of the following code is written in the non-reprogrammable mask ROM of the drive. We cannot change this
code in any way or shape, save with a modchip.
When you insert a DVD into your Wii, it will start it's internal DiscLogin statemachine. This is a huge
piece of code, which does everything that is required to get to the point where you can read the disc.
Everything up to about half of the statemachine is not all that interesting, that part mainly deals with
calibration and reflectivity detection and whatnot. The interesting part comes at state 0x7F. This is
the state that does the filtering between GC, Wii, and other discs.
Digging around a bit in state 0x7F yields this interesting bit of code:
ROM:0008AA43 movbu (0x40880C), D0
ROM:0008AA48 and 0xF0, D0 ! ''
ROM:0008AA4B cmp 0xF0, D0 ! ''
ROM:0008AA4F bne loc_8AAB5
ROM:0008AA51 movbu (0x40880C), D0
ROM:0008AA56 and 0xF, D0
ROM:0008AA59 cmp 0xF, D0
ROM:0008AA5B beq loc_8AA5F
ROM:0008AA5D bra loc_8AAB5
Now, if you've done a little digging around in the drive firmware, you know that at 0x408800 is the first sector of
the current disk. The very first sector of a disc contains stuff like size, and media code, stuff like that.
At offset 0xC of a disc resides the booktype. So what it's doing here is checking for booktype 0xFF (Which is a Wii disc).
If it's not 0xFF, that specific function will return non-zero.
Moving with the resulting codeflow, we see this occur:
ROM:0008F6D7 mov (8,SP), D0
ROM:0008F6D9 or 0x18, D0
ROM:0008F6DC mov D0, (8,SP)
And later:
ROM:0008F7BA mov (8,SP), D0
ROM:0008F7BC mov D0, (0x8576)
This (and only this) sets the lower byte of 0x8576, when we fail the 0xFF check. Keep this in the back of your mind please.
(More checks are done on 0x40880C, part of the reason why you cannot use DVD+R's without bitsetting, but that's for
another time).
The disclogin continues, and ends up in state 0xF2. So, the disc is now logged in. However, as some of you might have noticed
(maybe, possibly), we can only access the DVD at 3x speed. Far slower then the 6x speed I can access a normal Wii disc at.
But aha! Nintendo seems to have foreseen this little problem, and added a nifty function for us to use:
DVDLowSetMaximumRotation, a.k.a SetSpeed.
No luck though, issuing the command does nothing... So, why does it do nothing?
Sending a command to the drive results in the LL controller (the big chip) poking the mn102 with an interrupt. When we trace this
interrupt, and reverse some rather nasty jumptable algorithms, we find the code that gets run when 0xDD is sent to the drive. Digging
a little in the code, we find this:
ROM:0008259E mov (0x8576), D0
ROM:000825A1 btst 0x20, D0 ! ' '
ROM:000825A4 bne loc_825B6
But wait, thinking back a little, we saw that the lower byte of 0x8576 was set to 0x18. btst 0x20, 0x18 will fail, because bit 0x20 is not set in 0x18.
This results in the code skipping the actual speedsetting. And there's nothing we can do to bypass it.
Now, I'm not saying outright that you cannot kick the drive into high gear, but let us think about it for a second. This mode
was put there to allow playback of regular DVDVideo. Reading a normal DVDVideo disc means you're reading everything sequentially. There is
no need for high speed reading here. Why would you allow 6x speed reading, when you're not ever going to use it?
-- Erant, bushing boy.
Hm, interesting posts guys. One simple question I have yet to see an answer for is why Nintendo (if this was on their part) would configure a firmware for the disc drive to have multiple modes, when clearly it should be expected to only play games. Did they eventually have plans for DVD playback? Did they know it could be utilized for ISOs?
The world may never know...
The world may never know...
Quite a few people presented it as fact, took it as such, or declared that it was almost certainly a fact. When those things happen, expect a defensive reaction. Also, consider the fact that I wrote DVDX.CMac1988 said:
Nice explanation there, Erant. For those that don't know, Erant is our resident drive guru, who also wrote almost all of libdi (minus the part that deals with DVDX).
So... Are we going to get a faster speed or not? Or will it take 3 years?
EDIT: Waninkoko is reading this thread! Let's see what he has to say!
38 User(s) are reading this topic (23 Guests and 1 Anonymous Users)
14 Members: Zeek03, Jeda, Baroque Obama, Erant, jebrown19, waninkoko, CMac1988, Modder225, marcan, Rcolon85, linkinworm, drmore, Shobux, sigh101
EDIT: Waninkoko is reading this thread! Let's see what he has to say!
38 User(s) are reading this topic (23 Guests and 1 Anonymous Users)
14 Members: Zeek03, Jeda, Baroque Obama, Erant, jebrown19, waninkoko, CMac1988, Modder225, marcan, Rcolon85, linkinworm, drmore, Shobux, sigh101
Ok marcan it makes sense now that really clears it all up I like those responses and your legitamate set in stone reasons
hey everybody this thread is useless i say close it.............
He is basically saying anyone could put all these things together to make this loader or hombrew app I say let the devs
do their thing and quit bickering about it.....
Cheers
hey everybody this thread is useless i say close it.............
He is basically saying anyone could put all these things together to make this loader or hombrew app I say let the devs
do their thing and quit bickering about it.....
Cheers
