Dreamcast-Talk.com

All VMUs to date have been limited to 128KB of storage with 200 blocks usable, with a few memory cards that basically combine multiple 128KB cards into one unit, switchable via a button on the side. From the perspective of the DC, though, they're all 128KB. It's also possible to rewrite the file system to report 241 blocks available by treating seeming unused space as usable. (This unused space is probably really used for wear leveling.) This works fine for most games, but a few (like DreamPassport) won't recognize the VMU. AFAIK, no one has ever made a unpaged VMU with more than 128KB storage.

However, the file system used on VMUs seems to support even larger memory cards, theoretically up to 16 or 32 MB. What would happen if you tried to have a VMU report that it's larger than 128KB?

I tried modifying emulators to do this before, but always had trouble getting them to compile. After seeing the work on VM2, I wanted to try again. I finally managed to get Flycast Dojo to compile. I had it report having a 256KB VMU with 400 blocks, and experimented to see what would work.
The BIOS worked just fine, and was able to format the VMU and see the entire space. There are even some games that work fine with VMUs larger than 128KB, however many games don't recognize larger VMUs, and some even corrupt the VMU's file allocation table.

I noticed that a block went missing on the BIOS somehow... there are 371 used and 28 free, so 399 blocks total. When I was testing games, I deleted some files at some point since I ran out of space. I guess that while the BIOS can format and read the space fine, the deletion code has issues sometimes? It does work correctly too, it just didn't at some point for this screenshot. Or maybe a game caused the block to disappear. I noticed something like this happened when I was using the 241 block trick on real hardware at one point, where I deleted a file but didn't get all of the space back. It might be because the values used to describe how the VMU is laid out are not what the BIOS expects.

I tried a random assortment of games.

The following games seem to work:
Sonic Adventure
Sonic Adventure 2
Soul Calibur
Test Drive Le Mans
Trickstyle
Surf Rocket Racers
Seventh Cross Evolution
Record of Lodoss War
Alien Front Online
Radirgy
Under Defeat
Trigger Heart Exelica
Space Channel 5 Part 2
Rez
Advanced Daisenryaku 2001
Bangai-Oh
Quake III Arena
Unreal Tournament

The following games either falsely report no VMU inserted or not enough space, or just don't allow you to select the VMU:
Crazy Taxi
Shenmue
Shenmue II
Phantasy Star Online v2
Daytona USA 2001
Jet Grind Radio
Skies of Arcadia
Fur Fighters
Virtua Fighter 3tb
NFL 2K1
Super Runabout
Half-Life Beta
Ecco the Dolphin
MDK2
Cosmic Smash
Ikaruga

Dead or Alive 2 will boot and show the start up logos, then hangs when accessing the VMU.

What's worse than a game not working? The following games seem to end up corrupting part of the file allocation table, causing random other saves to become unreadable:
Metropolis Street Racer
Propeller Arena (Says file damaged after saving)
Dynamite Cop (Says no card, allows selecting card anyways)
18 Wheeler (Says not enough space, saves anyways)

From what I remember, MSR doesn't recognize standard VMUs with 241 blocks enabled, so the fact that it saves on larger ones is odd.

I haven't looked closely into what kind of corruption is happening. When I try to look at the VMU in the BIOS, the BIOS tries to read block 65532 (or FFFC in hex). That value is used in the FAT to mark areas that are unallocated, so it looks like the block chain linked list was incorrectly updated when the saves where written.

It's possible that the corruption is happening because I have wrong values for how the VMU is laided out, but I doubt it in this case.

I can't be sure that the games that seemed to work will always work. It's possible that some might only work when the card is mostly empty, or only work when the file gets written to an address in the first 128KB, or something like that. Loading or updating saves might run into problems, too. For most games, I only tried getting the game to create the save, then checked the BIOS to see if it was written ok.

So while large, single-page VMUs are interesting and kind of work, I'm not sure they're supported well enough to try actually making any. Accidentally playing the wrong game and loosing your saves would be awful. I guess you could create a VMU that did copy-on-write, so you could rollback any changes, but that would be a lot of work.
Seems like 1MB is the limit.

great
imo this should be bookmarked on the top of the Emulation forum
thanks

The Wingman SD built-in VMU can be changed from 200 to 240 blocks, not 241. What's the deal with one unused block?

I mentioned how using an incorrect VMU layout might be the cause of some of the problems. I went back and redid the layout, and got come compatibility improvements. All the games that caused corruption before now work correctly, making large VMUs more viable. However, when I retested other games that wouldn't accept the large VMU, like PSOv2 and DOA2, they still wouldn't work.

Some games will use their own scheme to read the setup vmu, unless you change the main program of all those games

TapamN wrote:I mentioned how using an incorrect VMU layout might be the cause of some of the problems. I went back and redid the layout, and got come compatibility improvements. All the games that caused corruption before now work correctly, making large VMUs more viable. However, when I retested other games that wouldn't accept the large VMU, like PSOv2 and DOA2, they still wouldn't work.

manyblocks.jpg

Would it be possible to modify Flycast Dojo so controller slot 1 will work as a standard 200 block VMU and slot 2 would work as a custom 1MB VMU?

yzb wrote:Some games will use their own scheme to read the setup vmu, unless you change the main program of all those games

I think most (maybe even all) commercial games would use a library created by Sega to access the VMU. Any differences in how the VMU is accessed from game to game are probably down to either the version of the library, or maybe some kind of configuration option.

Actually, if someone located the VMU save handling library code, it would be possible to hack it to save to a serial port SD card. Redirect all file read and writes to files on the SD card and have it always report that there's 200 blocks free in the VMU for an "infinite" VMU. (You might have to limit it to 200 files, since that's the limit on real 200 block VMUs) Since the VMU save code is likely to be mostly the same between games, once one game has been patched, it should be relatively easy to patch other games.

But I'm more interested in seeing what could be done without hacking the games; what could be done on a stock system and software by just plugging in the right hardware.

MoeFoh wrote:Would it be possible to modify Flycast Dojo so controller slot 1 will work as a standard 200 block VMU and slot 2 would work as a custom 1MB VMU?

It doesn't seem like that would be hard, but I think a better option would just to allow selecting the size per VMU.

I ran into some problems testing the 1MB VMU. It's not saving more than 16 saves to the VMU, and there's some problems with the file allocation table. I'm not sure if it's a problem with the layout I'm using, or problem with the games.

There's basically five parts to the VMU layout. The data area, the unused (wear level?) area, the file head area (directory, the file position area (called the FAT in the link), and the root block.

The data area is where the save data is stored, and the unused area is probably used to handle any blocks that go bad. The file head area stores the file name, file creation time, file size, etc. For every potential file, there are 32 bytes reserved here. The file position area is used to track where parts of a file are located on the VMU. For every block of the VMU, two bytes are reserved for this area. The root block stores where all the other areas are and the VMU color and icon.

It seems like this was designed to avoid wear on the flash. The root block is only written to when the VMU is formatted, and the file head area and file position areas are generally only written to when a file is created or deleted. (If a block goes bad, then it probably gets moved and the file position would need to be updated, but this would be rare.) Only user data would risk having the flash wear out, and that can be moved around with the file position area.

The VMU has a "Get Memory Information" command that returns the size of the VMU and hard coded locations for where the areas are supposed to go, which is used by the BIOS when formatting the card. This is what I've been changing in Flycast to get a larger VMUs to be recognized.

During the 1MB VMU testing, I found the first block of the file head area written to three places. One was the correct place, one was at block 0 (which would corrupt any save data that's happens to be written there), and one was in the file position area. I didn't notice any write to block 0 like this happening with my 400 block attempts, but it did write over the file position area. I don't know if a specific game did this, if it has to do with my layout, or if it's a problem with 1MB VMUs in particular.

The 16 save limit stands out because that's how many entries fit into one block of the file head area.

It's going to take much more thorough testing that what I've done so far to figure out what the limits of VMU size and layout are.

Where's to download the 1MB VMU with 1853 block ?

I'm going to add this to my list of things to investigate now that I'm back and am trying to be active within the scene again. I have a bunch of stuff on my plate already between trying to get a new ElysianVMU release out, trying to work on a few KOS PRs, and trying to pick back up Elysian Shadows, but hopefully I'll get some time to look into this before too long. I've been very interested in trying to see whether a larger capacity VMU could actually be possible or not. I don't really fully buy into the notion that the 4x memory cards literally *have* to be banked yet. I think there's still a lot to explore here.

I know TampanN isn't really around anymore, but If anyone else is VMU-savvy and is reading this, a few things I'd note. I'm almost positive that at least based on the VMU Root block layout, the FAT entry table and directory sizes should be configurable, so the 16 entry limit might not actually be a real issue. Whether the DC BIOS actually honors variable sizes here or not remains to be seen. Also what Tampan said about the "unused" blocks being for relocating bad sectors as a wear area is true. I believe the fat table itself has an entry value for denoting a block is bad. This area is basically what you're expanding the user/data segment into when you do the "unlock extra 41 blocks" ordeal that we know works with most games.

If we get this figured out, I'll add the ability to configure custom VMU image sizes to the ElysianVMU file manager.

edit: actually the EVMU flash hex editor makes it extremely easy to modify the root block and export a new flash image you could use to test with emulators...

Oh, apparently TampamN is still active? I had heard somewhere he was no longer active within the scene... Well anyway, hell yeah, he's a damn legend.

Yo TampamN, looks like I made some dumb assumptions in EVMU in terms of flash root block configuration, so it'll take some code changes before I can produce test images over here.

I was wondering which fields exactly you were setting to which values to get as far as you got?

I also wanted to share this with you. Over the years working on EVMU and researching, I've collected docs and reverse engineered a bunch of these values. This is the VMU root block layout, as far as I'm aware: Notice the entries or FATSIZE and DIRSIZE. You should be able to configure the fat region to span multiple blocks and the directory region to span more than just the default 13. Sounds like you have a better setup than I do for testing this stuff.
Once I get EVMU to stop being pissed off (detects all blocks, but they're all magically not empty? wtf?), I can make a dialog widget for easily configuring these values and exporting corresponding images for testing.