Dreamcast-Talk.com

Sorry to bump this, just found this topic. So, could I essentially create a version of the 4x Memory Card to use say, in Flycast? And what tool would I need to use to create a 4x VMU image?

I had actually started adding the ability to export arbitrarily-sized, properly formatted VMU images from ElysianVMU 2.0, but I have since just gotten so busy with KOS and GTA--eerrrr I mean nothing, so I haven't been able to revisit in awhile... Definitely still planned for next release, though, if you don't find a tool before then!

Sounds like a plan I did stumble upon the ElysianVMU GitHub directory completely by accident and have been using the 1.6 release in CrossOver on my Mac in the meantime

eisnerguy1 wrote: ↑Sat Oct 12, 2024 3:32 am Sorry to bump this, just found this topic. So, could I essentially create a version of the 4x Memory Card to use say, in Flycast? And what tool would I need to use to create a 4x VMU image?

That's not really what this thread is about. The 4x Memory Card is broken up into banks, and is basically 4 regular 200 block VMUs that you toggle between with a button. This thread is about a experimenting with single VMU with more than 200 blocks, available all at once, without banks or manual switching.

TapamN wrote: ↑Sat Oct 12, 2024 5:32 pm

eisnerguy1 wrote: ↑Sat Oct 12, 2024 3:32 am Sorry to bump this, just found this topic. So, could I essentially create a version of the 4x Memory Card to use say, in Flycast? And what tool would I need to use to create a 4x VMU image?

That's not really what this thread is about. The 4x Memory Card is broken up into banks, and is basically 4 regular 200 block VMUs that you toggle between with a button. This thread is about a experimenting with single VMU with more than 200 blocks, available all at once, without banks or manual switching.

Ah, I stand corrected. So, how would one manually create a 400/800 emu bin image?

It's not a matter of just creating a larger VMU binary, I had to change flycast's code to get it to report a larger VMU.

With the spotty compatibility, you probably wouldn't want to do it. This was an experiment to see how games would work with a larger VMU.

TapamN wrote: ↑Fri Oct 18, 2024 4:58 pm It's not a matter of just creating a larger VMU binary, I had to change flycast's code to get it to report a larger VMU.

Tbh, I think that's not correct behavior on Flycast's part. 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... This is how the "unlock extra 40 blocks" ordeal works too. The save/hidden area location/size is just passed directly up to the DC from that root block.

I think Flycast was incorrectly emulating the behavior of the VMU's BIOS and was making hardcoded assumptions if this was the case... I do actually believe that a well-conforming VMU/DC emulator combo would be able to properly report arbitrarily sized partitions/extended volumes via standard Maple, based on nothing other than the VMU's flashrom, which is where this information ultimately gets pulled from when the VMU BIOS presents it to the DC.

...but yeah, like you said, doesn't do much good if the BIOS and most games don't even properly adhere to the Maple spec and operate generically.

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...

Huh, 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.

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)

TapamN wrote: ↑Tue Oct 22, 2024 10:25 pm 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).

cool, I did the same in the SMPK2DC project, I didn't even know that the original works on the same principle

Do we know for certainty what the heck those 40 extra block were intended for by Sega? I've always wondered about that.