Hi everyone,
I am working on a translation project for Dragon Quest 25th Anniversary Collection on Wii (Yeah, that amazing video intro alone motivates the project). The idea is to preserve the original collection experience as much as possible, rather than simply running the games through an external emulator. The project is still experimental, but enough progress has been made that I think it is time to ask for help from people with more experience in Wii VC internals, SNES mapping, PowerPC/Ghidra work, and graphic editing.
The project can be divided into two main phases.
The SNES side is where the real problem begins. The collection uses Nintendo’s official Wii SNES emulator, shvc.dol, together with files such as: LZH8ZKDJ.rom, LZH8ZKDJ.pcm and ZKDJ.var
From what we have found, the .rom file is LZH8-compressed, the .pcm file appears to contain externalized audio/sample data, and the .var file is emulator-side metadata. The .var file is needed for emulation, not for reconstructing the ROM itself. I have seen posts here explaining that's the expected structure of Wii VC Snes roms, and how some of those VC Roms can be decompressed to create the rom+pcm, but I haven't found how to create a rom+pcm from the scratch using a estandard rom.
In the other hand, we can create a new LZH8-compressed .rom from the translated SFC ROM, but the issue is that the translated Dragon Quest III SNES ROM is larger than the original. The original game is effectively a 4 MB HiROM, while the translated version expands to around 6 MB. The official shvc.dol emulator does not seem to handle that expanded HiROM layout correctly, as stated in many threads in the forum trying to inject roms such as Tales of Phantasia or Star Ocean or DQ III.
Using Ghidra, we found that the loader portion of shvc.dol does pass the decompressed ROM pointer and ROM size dynamically into the emulator core. So the failure does not seem to be simply that the file cannot be loaded. We also found a Nintendo compatibility patch routine inside RomHeader.cpp logic, which validates certain bytes in the original DQIII ROM and applies runtime patches. We extracted those checks and compared them against the translated ROM; the validation points we checked still pass.
The more likely problem appears to be the HiROM memory map setup. In FUN_800fd104, the mapping routine appears to cover:
0x40 × 0x10 × 0x1000 = 0x400000
which matches a 4 MB ROM map. We tried a simple test by changing the 0x40 loop limit to 0x60, hoping to map 6 MB, but that caused a black screen even with the original ROM. The Wii sandbox still runs and the HOME menu can still be opened, so the DOL itself is not crashing completely; the SNES core simply fails to boot the game. That means the idea may still be correct, but the patch is too blunt and probably overwrites or changes mapping ranges the emulator expects to leave alone.
So right now there are two possible technical paths.
Help would be especially useful from anyone familiar with Wii DOL reverse engineering, PowerPC assembly, SNES HiROM and ExHiROM mapping, or Nintendo VC internals.
The clean version of this approach would be a custom applet that loads the translated SFC ROM directly and also saves in a way compatible with the Wii environment. Ideally, it would read the ROM from the collection files and write SRAM to NAND, or at least behave as closely as possible to the original applet. This route is probably easier than fully patching Nintendo’s emulator, but it may lose some of the original integration unless the save system is handled properly.
If anyone wants to help with the design side, graphic editing, menu cleanup, splash screens, or consistency work, that would also be very welcome.
At this stage, the most useful help would be from people who can look at the shvc.dol side and help determine whether the official Wii SNES emulator can be patched to support the expanded DQIII HiROM. Any knowledge of LZH8, Wii VC .rom/.pcm/.var files, Ghidra, PowerPC, or SNES memory mapping would be extremely helpful.
Thanks in advance to anyone interested in helping.
I am working on a translation project for Dragon Quest 25th Anniversary Collection on Wii (Yeah, that amazing video intro alone motivates the project). The idea is to preserve the original collection experience as much as possible, rather than simply running the games through an external emulator. The project is still experimental, but enough progress has been made that I think it is time to ask for help from people with more experience in Wii VC internals, SNES mapping, PowerPC/Ghidra work, and graphic editing.
The project can be divided into two main phases.
Phase 1: Emulation and ROM integration
The first goal is to make the translated games run inside the original collection structure. On the NES side, we have already made good progress. The collection uses Nintendo’s official hvc.dol emulator, and we were able to edit and replace the NES ROMs successfully while keeping the official emulator working. In practice, the NES side behaves much more like a Wii VC applet: the ROM can be replaced, the emulator still launches correctly, and the collection remains functional.The SNES side is where the real problem begins. The collection uses Nintendo’s official Wii SNES emulator, shvc.dol, together with files such as: LZH8ZKDJ.rom, LZH8ZKDJ.pcm and ZKDJ.var
From what we have found, the .rom file is LZH8-compressed, the .pcm file appears to contain externalized audio/sample data, and the .var file is emulator-side metadata. The .var file is needed for emulation, not for reconstructing the ROM itself. I have seen posts here explaining that's the expected structure of Wii VC Snes roms, and how some of those VC Roms can be decompressed to create the rom+pcm, but I haven't found how to create a rom+pcm from the scratch using a estandard rom.
In the other hand, we can create a new LZH8-compressed .rom from the translated SFC ROM, but the issue is that the translated Dragon Quest III SNES ROM is larger than the original. The original game is effectively a 4 MB HiROM, while the translated version expands to around 6 MB. The official shvc.dol emulator does not seem to handle that expanded HiROM layout correctly, as stated in many threads in the forum trying to inject roms such as Tales of Phantasia or Star Ocean or DQ III.
Using Ghidra, we found that the loader portion of shvc.dol does pass the decompressed ROM pointer and ROM size dynamically into the emulator core. So the failure does not seem to be simply that the file cannot be loaded. We also found a Nintendo compatibility patch routine inside RomHeader.cpp logic, which validates certain bytes in the original DQIII ROM and applies runtime patches. We extracted those checks and compared them against the translated ROM; the validation points we checked still pass.
The more likely problem appears to be the HiROM memory map setup. In FUN_800fd104, the mapping routine appears to cover:
0x40 × 0x10 × 0x1000 = 0x400000
which matches a 4 MB ROM map. We tried a simple test by changing the 0x40 loop limit to 0x60, hoping to map 6 MB, but that caused a black screen even with the original ROM. The Wii sandbox still runs and the HOME menu can still be opened, so the DOL itself is not crashing completely; the SNES core simply fails to boot the game. That means the idea may still be correct, but the patch is too blunt and probably overwrites or changes mapping ranges the emulator expects to leave alone.
So right now there are two possible technical paths.
Option 1: Edit shvc.dol
This is the preferred route if possible, because it would preserve the original Nintendo emulator, the collection structure, and the native feel of the release. What we need to understand is how shvc.dol builds the HiROM memory map and whether it can be modified to expose the extra 2 MB used by the translated ROM without breaking the original mapping tables.Help would be especially useful from anyone familiar with Wii DOL reverse engineering, PowerPC assembly, SNES HiROM and ExHiROM mapping, or Nintendo VC internals.
Option 2: Custom loader or forwarder
The other possible route is to replace the SNES applet with a custom loader or emulator-based solution. We already proved that the collection can launch a replacement DOL in place of shvc.dol. A SNES9x-based test build can launch from the collection, but there are still problems with paths and save handling.The clean version of this approach would be a custom applet that loads the translated SFC ROM directly and also saves in a way compatible with the Wii environment. Ideally, it would read the ROM from the collection files and write SRAM to NAND, or at least behave as closely as possible to the original applet. This route is probably easier than fully patching Nintendo’s emulator, but it may lose some of the original integration unless the save system is handled properly.
Phase 2: Editions, graphics, splash pages, and extras
Once the emulation side is solved, the second phase would be the presentation work. This includes editing the collection menus, letters, splash pages, graphic text, and any extra material needed to make the collection feel like a complete English release rather than only a ROM replacement.If anyone wants to help with the design side, graphic editing, menu cleanup, splash screens, or consistency work, that would also be very welcome.
What we are looking for
At this stage, the most useful help would be from people who can look at the shvc.dol side and help determine whether the official Wii SNES emulator can be patched to support the expanded DQIII HiROM. Any knowledge of LZH8, Wii VC .rom/.pcm/.var files, Ghidra, PowerPC, or SNES memory mapping would be extremely helpful.
Thanks in advance to anyone interested in helping.
