Migrate GameCube port to libogc2

[Extrems]

This may prove controversial, but here goes.

Some key benefits:

• Support for the GC Loader.
• More robust support for passive SD card adapters.
• Default progressive mode state follows system settings.

I've made some changes to reflect the current state of libogc and/or libogc2 on the GameCube.

Here are some comments:

• The starting position given to console_init used to do nothing. This now does something in libogc, so zeroes are given to maintain the original behavior.
• Memory card unlocking hangs the system due to using ASND. This is currently only supported with AESND in libogc2.
  Memory card support is otherwise tested as working.

libogc2 can be found here. You may install using any method you feel comfortable with (make, makepkg or pacman).

[ekeeke]

Hi, thanks for the effort.I have some questions though:

1/ Has this been throughfully tested (browsing menus, playing some ROM and CD image files, loading files from sdcard and dvd, etc) to be sure there is no introduced regression ? I don't have a working hacked Gamecube anymore (cannot read homebrew bootable dvds anymore) so I will no be able to check it myself.

2/ Does the Wii port still compile fine (without warnings or errors) ? Some of the changes indeed have impact on shared code and, although it seems minor changes (use of library defined constants instead of fixed values), they need to be compatible with libogc as well since it will still be used to build the Wii port.

3/ Why only the modified dvd read sector handler is removed from DVD libogc interface patch ? Couldn't this patch be entirely suppressed as I think other handlers were copy pf libogc ones and only the read handler was modified ?

[Extrems]

1. Everything is working fine as far as I can tell, except for a few things to note:

   a) There is an interesting interaction between the GC Loader and the DVD load device, where the FAT contents are presented instead of the mounted disc image. This is because libfat mounts the GC Loader at dvd:/.
   This is potentially desirable if you want to use the GC Loader as load device and SD2SP2 as save device.

   b) Since devkitPPC release 42.2, readdir can return NULL with EOVERFLOW when a file name exceeds 255 UTF-8 bytes.
   This is possible with FAT LFNs as they use UCS-2 characters. You're meant to skip over the file instead of stopping here.

2. The Wii port has no new warnings, except for the existing issue with libogc 2.5.0 where CARD_WORKAREA was renamed to CARD_WORKAREA_SIZE. I haven't decided whether to follow suit yet.

3. The underlying alignment issue with libiso9660 has been fixed twice over, but the other issues are still on the backburner.

[ekeeke]

Thanks for the detailled answer.

Regarding this point

2. The Wii port has no new warnings, except for the existing issue with libogc 2.5.0 where CARD_WORKAREA was renamed to CARD_WORKAREA_SIZE. I haven't decided whether to follow suit yet.

Does the changes made to slot_io.c (simplification of card init/mount/read/write code + correction of time attribute value) require an updated libogc when compiled for Wii or was it already unnecessary / incorrect code with older libogc ?
I checked my install and I currently have libogc 2.2.1 installed (I don't really keep track of the GC/Wii scene developments anymore) so if a libogc update is needed, I guess I will also need to update devkitPPC to latest version ? I am still on r38 and I am always a bit hesitant updating devkitPPC unless it is really necessary because it seems it always comes with some regression (not just from devkitpro organization but also looking at gcc/newlib bugs tagged as 'regression' after each new release is kinda frightening) and I could swear it seems the generated DOL file are getting bigger after each releases :-/

One last question about the change in VI callback: is there something wrong with the current code ? Because it seemed to me more efficient to directly read hardware register rather than calling a function doing the same thing with an additional shift then reversing that shift. The only difference is that the function also masks bit 15 but I assumed it was always set to 0, maybe I was wrong ?

[Extrems]

Does the changes made to slot_io.c (simplification of card init/mount/read/write code + correction of time attribute value) require an updated libogc when compiled for Wii or was it already unnecessary / incorrect code with older libogc ?

I had to check and CARD_Read was fixed since libogc 1.8.24. CARD_Write is still broken as of libogc 2.5.0.

I checked my install and I currently have libogc 2.2.1 installed (I don't really keep track of the GC/Wii scene developments anymore) so if a libogc update is needed, I guess I will also need to update devkitPPC to latest version ? I am still on r38 and I am always a bit hesitant updating devkitPPC unless it is really necessary because it seems it always comes with some regression (not just from devkitpro organization but also looking at gcc/newlib bugs tagged as 'regression' after each new release is kinda frightening) and I could swear it seems the generated DOL file are getting bigger after each releases :-/

I understand your hesitation. Unfortunately libogc2 currently require devkitPPC release 42 at minimum. :(

One last question about the change in VI callback: is there something wrong with the current code ? Because it seemed to me more efficient to directly read hardware register rather than calling a function doing the same thing with an additional shift then reversing that shift. The only difference is that the function also masks bit 15 but I assumed it was always set to 0, maybe I was wrong ?

There's nothing really wrong with it, but an existing library function exists for this very purpose, so...

[Extrems]

Bumping this as quite a few things changed.

• The upcoming ETH2GC Sidecar+ needs software to be recompiled to support its SD slot.
• The SD2SP2 hardware has been revised to enable greater read performance. This change is backwards compatible, but requires software to be recompiled to benefit.
• 32 MHz operation is now attempted by default, improving I/O performance in any case.
• FAT cache optimizations also brought other I/O performance improvements.
• The FlippyDrive is on the horizon.

I need to know if I need to focus on restoring support for devkitPPC release 38 to move forward on this.

[ekeeke]

I need to know if I need to focus on restoring support for devkitPPC release 38 to move forward on this

No, I will probably update devkitPPC to latest version some day so don't bother with it, it's just I don't have much time to focus on this these days. Thanks for the continued submissions, I/O optimization is certainly much appreciated, for Mega-CD support especially...

[Extrems]

exFAT support is now available via the libogc2-libdvm package. libogc2-libfat is now deprecated, but will remain available and maintained for the foreseeable future.