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.