3DS Virtual Console
There's two types of VC titles: regular VC titles, and dedicated GBA VC titles.
Regular VC
Regular VC titles: an emulator application + VC ROM in the NCCH RomFS(among other things in the RomFS). The emulator build includes support for all supported VC platfms, not specific to just the included ROM platform.
This emulator includes GBA support, however the GBA emulation for this this is somewhat slow. This was presumably implemented before AGB_FIRM was.
Unlike Wii VC, the 3DS VC ROMs for NES use the "TNES" header.
RomFS
- "rom:/rom/" This directory contains the ROM file(s). Filenames used under here don't matter: the filename is determined by the emulator app by doing a directory read.
- "rom:/shaders/" This directory contains GPU shaders used by the emulator app: .shbin, .csdr, and .obj.
- "rom:/VCM/" This directory contains graphics, audio, and text used by the emulator app.
- "rom:/agb.bin" GBA BIOS.
- "rom:/buildtime.txt" Emulator app build timestamp.
- "rom:/config.ini" Emulator configuration .ini, contains sections for all supported 3DS VC platforms.
- "rom:/<rom_name>.patch" rom_name = filename from the rom directory. This .ini contains patches for the ROM.
- "rom:/shader.shbin" GPU shader.
Savedata
The savedata can contain:
- "rsm1.dat": Same format as the below rsm2.dat. Probably used for the "restore-point".
- "rsm2.dat": Current emulator save-state, for storing/loading state at VC-title launch/exit.
- "sav.dat": The actual savedata used by the emulated ROM.
- "SecureValue": The random number used by Anti Savegame Restore. No known version of the emulator implements both savestates and secure value.
Overwriting sav.dat with 0xFF-bytes doesn't have any affect on the actual emulator. Doing that with most of the rsm*.dat data doesn't crash anything.
GBA VC
GBA VC is run by AGB_FIRM. RomFS isn't used for GBA VC titles, but can be found empty within GBA VC titles. The NCCH ExeFS contains the same files as a normal application. The ExeFS:/.code contains the GBA VC ROM followed by a 0x360 byte long footer.
All values in the GBA VC footer are little-endian.
| START | SIZE | DESCRIPTION |
|---|---|---|
| 0x004 | 0x4 | GBA ROM Filesize |
| 0x008 | 0x4 | Save type (see below) |
| 0x020 | 0x4 | LCD ghosting (01-FF, lower values equal more ghosting) |
| 0x024 | 0x300 | Video LUT (black to full, rgbrgbrgb...)?, three different types of this data have been observed. |
| 0x338 | 0x4 | GBA ROM Filesize |
| 0x344 | 0x4 | GBA ROM Filesize |
| 0x350 | 0x4 | Magic '.CAA' |
| 0x35A | 0x2 | High two bytes of GBA ROM file size |
Save types:
- EEPROM (various sizes, IDs specified in footer): 0x2
- SRAM/FRAM (128k): 0xE
- Flash (512k): 0x9
- Flash (512k) and RTC: 0x8
- Flash (1Mbit) : 0xB (not implemented in AGB_FIRM, save persists until reboot)
- Flash (1Mbit) and RTC : 0xA (not implemented in AGB_FIRM, save persists until reboot)
NAND Savegame
AGB_FIRM saves its active save memory to NAND on exit, this is then immediately picked up by NATIVE_FIRM on reboot by checking CFG_BOOTENV. From there, this is verified and copied out to SD. The savegame format is as follows:
| START | SIZE | DESCRIPTION |
|---|---|---|
| 0x0 | 0x4 | Magic ('.SAV') |
| 0x4 | 0xC | Always 0xFF |
| 0x10 | 0x10 | AES-CMAC of the SHA256 hash of 0x30..0x200 + the entire save itself, keyslot 0x24, keyY from process9 .rodata |
| 0x20 | 0x10 | Always 0xFF |
| 0x30 | 0x40 | Always 0x1 |
| 0x34 | 0x4 | Number of times saved (unused?) |
| 0x38 | 0x8 | AGB TitleID |
| 0x40 | 0x10 | SD card CID from the console the save was made on (verified on load) |
| 0x50 | 0x4 | Save start addr (always 0x200) |
| 0x54 | 0x4 | Save size |
| 0x58 | 0x8 | Always 0xFF (?) |
| 0x60 | 0x4 | See here |
| 0x64 | 0x4 | See here |
| 0x68 | 0x198 | Always 0xFF |