Update: the file "Ace3DS+ R4iLS Clones Wood Kernel 1.62.rar" now also contains a patched "_DS_MENU.DAT" for orginal Ace3DS+. THIS IS UNTESTED, as I don't have an original Ace3DS+, but it should work, the code is really the same.
Problem Fixed!!!
After thinking a lot on this, I took a look at the Wood 1.25 open source code, and this gave me an idea on where the problem could be. I decoded the kernel (_DSMENU.DAT) using r4denc.exe and disassembled it with ndsdis2.exe. After a lot of trial an error (a LOT LOT), I just found the instruction responsible of generating the wrong addresses. It's a simple "mov r6,#0x9" that needs to be changed to "mov r6,#0x0". This "#0x9" is used a bit later in the code to shift the sector address 9 bits to the left (same as multiplying by 512), which is totally unneeded and breaks game compatibility. After modifying the instruction, the shift is not executed, and Wario Ware D.I.Y and Jam with the Band work and save the game flawlessly, as they are suppossed to be.
I want to share the modified kernel for the two flashcarts I own, Blue Gateway and Ace3DS+ R4iLS Aliexpress Clone (as this card is referenced in https://github.com/DS-Homebrew/flashcard-archive):
If anyone has one of these two flashcarts (or another similar variant) and is interested in trying it, it would be nice to see if it works. If you have a similar flashcart that uses another Wood variation and these files don't work for you, please PM me with your kernel, and I can try to apply the same patch, providing the kernel is similar enough (very likely).
I hope this is useful for anyone.
Original post
As I have several Ace3DS+ clones and a Blue Gateway, I have been investigating the issue Wood 1.62 has with the two games that use NAND save type, Wario Ware D.I.Y and Jam with the Band. I know this two games work fine trough Twilight Menu and nds-bootstrap, but I think it would be great if they also work natively.
This is what I have found so far:
Wood 1.62 have specific code for dealing with NAND save type, and despite the fact that it is severely flawed, it kinda works. When you run one of these two games by first time, the kernel creates an empty 32MB sav file, and an 256KB sav.fix file, which is the interesting one.
This sav.fix file contains a list of 32 bits integers, that point to the address of every 512-byte block of the sav file on the SD card. The problem is that this pointers are byte pointers, but when they are used to access the actual save file, they are used as 512-bytes block pointers, thus the real accessed addresses are wrong.
If very specific conditions are met, these games can work and save just fine:
If both conditions are met the game will run and save fine, but with a very important consideration: the save will not be written to the 32MB sav file, but to disperse sectors along the SD card instead. Because of this, you cannot have more games in the card, as you take the risk that they become partially overwritten when Wario or Jam save the game.
Taking previous information into account, the games can be guaranteed to work on a 32GB or bigger SD card by following these directions:
At this point, is obvious that the solution would be to write sector addresses instead of byte addresses into the sav.fix file. I tried to modify the file, but it is regenerated every time the game is launched. I also tried to mark it as read only, but then the kernel throws an error about not enough free space and refuses to launch the game.
The only solution would be to modify the kernel itself, so correct values are written to the sav.fix file. Unfortunately, as far as I know, we don't have the source code of this specific Wood variant, and I don't have the necessary skills nor tools to debug the machine code.
So I leave here this information just in case is useful for anyone trying to run the games, or anyone with the necessary skills to investigate it deeper.
It is very sad we still don't have an updated open source version of Wood, with 100% ROM compatibility and capable to run on all known clones and variants.
Problem Fixed!!!
After thinking a lot on this, I took a look at the Wood 1.25 open source code, and this gave me an idea on where the problem could be. I decoded the kernel (_DSMENU.DAT) using r4denc.exe and disassembled it with ndsdis2.exe. After a lot of trial an error (a LOT LOT), I just found the instruction responsible of generating the wrong addresses. It's a simple "mov r6,#0x9" that needs to be changed to "mov r6,#0x0". This "#0x9" is used a bit later in the code to shift the sector address 9 bits to the left (same as multiplying by 512), which is totally unneeded and breaks game compatibility. After modifying the instruction, the shift is not executed, and Wario Ware D.I.Y and Jam with the Band work and save the game flawlessly, as they are suppossed to be.
I want to share the modified kernel for the two flashcarts I own, Blue Gateway and Ace3DS+ R4iLS Aliexpress Clone (as this card is referenced in https://github.com/DS-Homebrew/flashcard-archive):
If anyone has one of these two flashcarts (or another similar variant) and is interested in trying it, it would be nice to see if it works. If you have a similar flashcart that uses another Wood variation and these files don't work for you, please PM me with your kernel, and I can try to apply the same patch, providing the kernel is similar enough (very likely).
I hope this is useful for anyone.
Original post
As I have several Ace3DS+ clones and a Blue Gateway, I have been investigating the issue Wood 1.62 has with the two games that use NAND save type, Wario Ware D.I.Y and Jam with the Band. I know this two games work fine trough Twilight Menu and nds-bootstrap, but I think it would be great if they also work natively.
This is what I have found so far:
Wood 1.62 have specific code for dealing with NAND save type, and despite the fact that it is severely flawed, it kinda works. When you run one of these two games by first time, the kernel creates an empty 32MB sav file, and an 256KB sav.fix file, which is the interesting one.
This sav.fix file contains a list of 32 bits integers, that point to the address of every 512-byte block of the sav file on the SD card. The problem is that this pointers are byte pointers, but when they are used to access the actual save file, they are used as 512-bytes block pointers, thus the real accessed addresses are wrong.
If very specific conditions are met, these games can work and save just fine:
- The 32MB save file must be allocated at a very low sector count, so its starting position multiplied by 512 fits inside the SD card
- The SD card must be big enough so that the wrong sav file starting position, plus the effective save size (8MB for Jam, 16MB for Wario), multiplied by 512, still fits inside the card
If both conditions are met the game will run and save fine, but with a very important consideration: the save will not be written to the 32MB sav file, but to disperse sectors along the SD card instead. Because of this, you cannot have more games in the card, as you take the risk that they become partially overwritten when Wario or Jam save the game.
Taking previous information into account, the games can be guaranteed to work on a 32GB or bigger SD card by following these directions:
- Format the SD card in FAT32
- Create an empty 32MB file with the same name as the ROM, but with sav extension. It's mandatory to be the first file copied, so it is allocated at a very low sector
- Copy the kernel of the flashcart
- Copy the Wario or Jam ROM file, just one of them, with the same name as the previous save file
- Do not copy more games, as there is a big chance they get corrupted when Wario or Jam saves the game
At this point, is obvious that the solution would be to write sector addresses instead of byte addresses into the sav.fix file. I tried to modify the file, but it is regenerated every time the game is launched. I also tried to mark it as read only, but then the kernel throws an error about not enough free space and refuses to launch the game.
The only solution would be to modify the kernel itself, so correct values are written to the sav.fix file. Unfortunately, as far as I know, we don't have the source code of this specific Wood variant, and I don't have the necessary skills nor tools to debug the machine code.
So I leave here this information just in case is useful for anyone trying to run the games, or anyone with the necessary skills to investigate it deeper.
It is very sad we still don't have an updated open source version of Wood, with 100% ROM compatibility and capable to run on all known clones and variants.
Last edited by davidmorom,
