DirectoryBlob: fix data alignment for GC/Triforce and skip Triforce DIMM memory range

[naari3]

DirectoryBlob uses 0x8000 alignment for file data offsets when rebuilding the FST. This is needed for Wii disc group encryption, but for GC/Triforce it just inflates the disc image.

On Triforce games with many files (MKGP2 has ~8600), the inflated offsets can land in the DIMM memory range (0x1F000000-0x1F800000). AMMediaboard Read returns SRAM data instead of disc data for those offsets, which causes the game to hang.

This changes GC/Triforce alignment to 0x20 (matching original disc layout) and, for Triforce specifically, skips the DIMM memory range when assigning data offsets as a safety net for very large mods.

Tested with MKGP2 (GNLJ) + Riivolution:

• A no-op patch (just triggering FST rebuild, no file changes) that hangs without this fix
• ~60 MB of additional create="true" files pushing past the DIMM range, confirming the skip works

Riivolution patches used for testing

No-op patch (reproduces the hang without this fix):

<wiidisc version="1">
  <id game="GNLJ"/>
  <options>
    <section name="Test">
      <option name="Empty patch" default="1">
        <choice name="Enabled">
          <patch id="noop"/>
        </choice>
      </option>
    </section>
  </options>
  <patch id="noop"/>
</wiidisc>

DIMM range skip test (60 x 1MB files to push past 0x1F000000):

<wiidisc version="1">
  <id game="GNLJ"/>
  <options>
    <section name="Test">
      <option name="Add files" default="1">
        <choice name="Enabled">
          <patch id="add_files"/>
        </choice>
      </option>
    </section>
  </options>
  <patch id="add_files">
    <file disc="/dummy_01.bin" external="/testmod/dummy_01.bin" create="true"/>
    <file disc="/dummy_02.bin" external="/testmod/dummy_02.bin" create="true"/>
    <!-- ... 60 x 1MB random files total -->
    <file disc="/dummy_60.bin" external="/testmod/dummy_60.bin" create="true"/>
  </patch>
</wiidisc>

[naari3]

I'm not familiar with how the actual Triforce hardware works, but perhaps disk reads should be performed before DIMM memory access. Since I couldn't determine the impact of that operation in this pull request, I've opted for the current approach.

[jordan-woyak]

I'm not familiar with how the actual Triforce hardware works, but perhaps disk reads should be performed before DIMM memory access. Since I couldn't determine the impact of that operation in this pull request, I've opted for the current approach.

It does seem odd that the Disc would need to actively avoid the 0x1F000000-0x1F800000 region.

[JosJuice]

0x20000000 is the max size of a Triforce game anyway, right? I feel like that's close enough to not be a coincidence.

[naari3]

@JosJuice thanks a lot for the thorough review! I hadn't done enough homework here tbh.

On the overall direction: I'm not sure whether Riivolution added files should actually be constrained by Triforce's hardware layout. If they should, then even with 0x20 alignment the usable capacity is still pretty limited.

If they shouldn't be, we'd need some kind of special handling (for example, the skip in this PR, or moving the disc read check ahead of the DIMM dispatch in AMMediaboard, or running a special code path only when Riivolution is active). These are clear trade-offs though, so I'd understand if this ends up not being accepted.

[JosJuice]

The skip in this PR sounds reasonable.

[JosJuice]

LGTM after squashing the commits into one.

[naari3]

@JosJuice Squashed into one, thanks!