I still do stuff, just stopped doing much on Gens4All, and haven't released anything recently. Mostly slowly working on my game/game engine with most time going to getting the model converter and collision detection. I've also spent time on the beginnings of a AICA library, a video signal setting library, and a VMU display library (it does graphics, text, and menus; I wanted to hook the DC up to an oscilloscope to verify the video signal library and be able to use the VMU to adjust the settings). I did do a small experiment on Gens4All to speed up the sound emulation at the cost of some accuracy (might be worth it for a higher sample rate or better rasters), but it was crashing randomly for some reason that I haven't completely figured out.Falco Girgis wrote:Oh, apparently TampamN is still active? I had heard somewhere he was no longer active within the scene...
The settings I used where calculated like this:Falco Girgis wrote:I was wondering which fields exactly you were setting to which values to get as far as you got?
There's a single root block which is always at the top of the VMU.
The FAT is right below the root block, and is 2 bytes per unformatted block, or 1 block per 128 KB of unformatted space.
The directory is below the FAT, and should be at least 32 bytes per user accessible block (i.e. divide the user accessible VMU space in blocks by 16 to get the dir size in blocks). If it doesn't divide evenly into the block size, round up. (So on a 200 block VMU, it's 200/16=12.5 -> roundup -> 13 blocks for dir)
The wear level area is between the regular storage area and the directory, and its size is whatever space is left.
I wanted to see if there was anyway to find out the official sizes of the different parts of the VMU file system. After tracing some code in the US version of Sonic Adventure 2, I think I found something. In SA2's 1ST_READ.BIN, at 0xf0338, there appears to be a small array of four longs containing the expected size of the FAT for 128KB, 256KB, 512KB, and 1024KB VMUs and afterwards four more longs containing the expected size of the directory. I don't think there's anything about the size of the wear level area.
The FAT sizes are all the expected values (1, 2, 4, and 8), and the directory size of the 128KB VMU is the known value (13 blocks), but the size for 256KB, 512KB, and 1024KB VMUs are larger than expected, being 30, 60, and 113 blocks large, which suggest there are 480, 960, or 1808 (probably 1800 rounded up) blocks available to the user.
For the 256/512 KB VMUs, I think someone at Sega just miscalculated the directory sizes, and there was never any intention for 480 or 960 block VMUs. If you actually tried to get 480 user accessible blocks on a 256KB flash, you'd run out of space even if you assumed no wear leveling. You have 480 user blocks + 30 dir blocks + 2 FAT blocks + 1 root block = 513 blocks, or 256.5 KB. I think actual space available is be something less, like 400 and 800. The directory is probably just larger than it needs to be and some blocks that could be used for wear leveling get wasted.
It's a bit more plausible that Sega might have intended to create a 1800 block VMU instead of 1600 block, since there's still room for 126 blocks of wear level space after adding everything together.
I really don't think VMU's larger than 128KB are worth it considering how poor they're supported. They can be fun to play around with, but not something to seriously use.
I would guess that the corruption problems with large VMUs could be cause by a buffer overflow. There might be some preallocated buffer to cache the directory area and FAT, and using larger VMUs could overflow this. It seems like there's an attempt to prevent this, since many games reject large VMUs, but maybe some games use the VMU library incorrectly?
