Well holy shit, you went deeper than I've gone...TapamN wrote: ↑Tue Oct 22, 2024 10:25 pmHuh, that's not at all what I would expect. I would have thought that Get_Media_Info would return fixed values so the card could be properly reformatted in case it gets corrupted. If you wanted the information from the root block, you could just read it with a flash read request.Falco Girgis wrote: ↑Tue Oct 22, 2024 2:56 pm I'm pretty familiar with the VMU BIOS (we have a community-driven reverse engineered disassembly of it on GH), and the Maple stack logic in its FW responsible responding to a Get_Media_Info request should simply be sourcing its media information from the values stored in its root block directly, which should just be part of its flashrom image...
I decided to look at a disassembly of the American VMU BIOS (Dmitry's 1.005 dump) to see what GMI does.
I found the code responsible responding to a request, a switch table on the maple command code located at 0xE6F, which eventually jumps to the Get_Media_Info handler (0x9BB).
It looks like it checks if the first 16 bytes of the root block contain 0x55 (the loop that does this is at 0x9E3), and if they are, it returns the data in flash. The first eight bytes returned are hard coded, from 0xB59 (right after the license strings), then two bytes from flash 0x1FE46, then a hardcoded 0x00 and 0xFF, then sixteen bytes from flash address 0x1FE48.
If the first 16 bytes of the root block aren't 0x55, it jumps to 0xA38, which returns 28 bytes of fixed values from ROM (from 0xB59).
For your page with VMU variables, I figured out some more.
0x20 contains is the maple address of the VMU, and 0x21 is the maple address of the DC? Maybe I have them backwards?
0x22 also has to do with a maple address
0x23 related to p7, masked by 0xc
0x24 is current command.
0x27 is some kind of error bitmask?
0x29 stores what subdevice the current command is for (0x02 for VMU, 0x04 for LCD, 0x08 for clock)
Will update my VMU docs with this information. Thank you!!!!
