DI issues -- seems to just not work

In updated versions of HBC, that bug is fixed and "<no_ios_reload />" is completely interchangeable with "<ahb_access />"; both cause HBC to launch the app with the HW_AHBPROT access required.

<no_ios_reload /> was the only tag in older versions, in newer versions it was changed because IOS is always reloaded, to prevent the bug, but newer versions of HBC will still read <no_ios_reload /> as meaning the exact same as <ahb_access />. You can update it to the new tag if you like, but it shouldn't cause any problems leaving the tag as-is. Updating HBC to a newer version should fix that problem.



Edited 2 time(s). Last edit at 02/05/2013 04:33PM by SifJar.

Wait, if you're using the "regular" DVD functions why do you need AHB access?

I don't know about IOS and all, but I read that DVD access requires AHB access. I also experimented that DI_*** functions don't work at all if I don't have AHB access (DVD drive never spins and DI_GetError() always returns -6).

Anyway I changed the tag to ahb_access. This way people with older HBC installs aren't going to get the random crash and be confused. Instead they'll face a non-working app and (hopefully) find out they need to update.

Well I pretty much got my app working now, so guess this thread has served its purpose... thank you guys for all the help! :)

DVD access (done right) shouldn't require AHB access, if I'm understanding tueidj correctly. It's needed for reading commercial DVDs (e.g. movies etc. in apps such as WiiMC) because you need to poke a value onto a certain register to enable DVD video mode, which is easily done at runtime via AHB access.

But you shouldn't need DVD video mode to read files from a Wii optical disc. The drive supports reading these discs by default (obviously, seeing as the official software does it to load games etc.). So therefore AHB access shouldn't be necessary to read files from a disc.

Now I cannot give any guidance as to how "proper" access could be achieved, but if you want to improve your app further, I would advise pursuing this topic more and attempting to fix the FST library so that it does not require AHB access.

I don't know how you initiate the drive without AHB or anything like that, but there must be a way.

EDIT: Perhaps IOS_Open() with the path being "/dev/di"? This is what DI_Init(), but DI_Init will check for AHBPROT first and then fail if it's not available

Not sure what mode you'd need though. DI_Init() uses 2. (i.e. the command would be IOS_Open("/dev/di", 2);)

[I'm sure tueidj will be able to offer a more definitive answer]



Edited 3 time(s). Last edit at 02/05/2013 06:34PM by SifJar.

Well then guess I'll just snatch libdi's code and modify it to match my needs :P

I was also thinking about ways to potentially make the copying process faster. But I think I'm already reaching the maximum possible speed. SD and USB are yielding the same speed, which indicates that the drive is limiting the speed. But since I can't see any commands to set its speed, I assume it's always operating at its maximum speed, right?

To improve speed you can overlap your I/O i.e. perform reading at the same time as other processing. See Cleanrip for example (http://code.google.com/p/cleanrip/source/browse/trunk/source/main.c#66), it uses a seperate writer thread to perform reading and writing at the same time.

Okay, thanks. I'll look into that.

Thank you everyone for your help! :)