This cart is basically the same as R4. There are a few differences and some other additions seen below:
- All SD read/write (0xB9/0xBB) has no sector shift.
- 0xBC does an XOR on the last byte:
- BC XX XX XX XX 00 00 YY
- XXXXXXXX = sector address
- YY = XOR of every byte in command reg, so
BC EOR XX EOR XX EOR XX EOR XX EOR 00 EOR 00
- 0xB4 works... on SD cards that aren't SDHC. because sector address must be <<9'd. Kernel uses normal SD RW for games.
- Save read/write commands on the R4 doesn't work on the Ace3DS+ if you do this for reasons not exactly known. Wood ports by some old devs used SD RW for saves and 0xB4 for ROM.
- 0xB6/0xBF seems to be supported... kinda. It's different from how the R4 does it. No idea at all how it works yet.
- When doing 0xB6/0xBF, it checks the header (
__NDSHeader->gameTitle). Seemingly freezes(?) if this check fails (not verified. Using wrong header in the boot file causes firmware to print an error.) Checks different based on clone.- Ace3DS+/Ace3DS X:
ACEP/ ARM codeb #0xc0(GBA Passthrough header) - R4 i.L.S / r4isdhc.com.cn / 2021-2022 r4isdhc.hk carts:
R4XX - Gateway Blue / r4infinity 2:
R4IT
- Ace3DS+/Ace3DS X:
- Either the firmware doesn't enable WRAM access upon chainloading boot file, or it hardcodes the ARM7 execute address to 0x02380000. Thus, the boot file must not load ARM7 directly to IWRAM, instead use the normal DS exec address and have your toolchain's crt0 move it wherever.
- 0xB0 command behaves differently. How differently is not observed, other than that it is needed in the firmware.
- According to ntrteam, 0xC0 sends raw SDIO commands. 0xC2 sets the SD host register, presumably for clock speed, as the cart likely uses SPI for SD control.