VMU Game Uploader

[Light-Dark]

Posted this over on DCEmu programming forum but I figured there may be some people here who are interested in this;

I've been working on writing a new game engine for the Dreamcast and so I've looked into putting vmu games onto the vmu through KOS. Couldn't find any good examples out there of how to do so I decided to make my own;

EDIT: (Better solution)

Before you can use this demo you have to do a bit of digging in KOS itself, specifically for the vmufs.c file, on line 750:

nd.hdroff = (flags & VMUFS_VMUGAME) ? 1 : 0;

Make sure the header offset value is set to 1 instead of 0 if the VMUFS_VMUGAME flag is set, otherwise your VMU will say "this game is damaged" when you try to play what you have uploaded. Once you have made sure of this, recompile KOS and you should be able to upload your VMS file to the VMU no problem. I've included Marcus Comstedt's Tiny Tetris within the demo. Hopefully this is helpful.

vmu_game.tar

(10 KiB) Downloaded 674 times

[Falco Girgis]

Jesus Christ, are you SURE you have to recompile all of KOS to do that!? That's absolutely horrible.

That offset is supposed to be 0 for DATA type files, where the header comes first then the data comes next. This is how standard save files work. Then GAME files require the header to be located at the first block, because block 0 is reserved for interrupt service routines and shit. So the layout in VMU flash is:

BLOCK 1: ISR Routines and Shit
BLOCK 2: VMS Header Data
BLOCK 3+: VMU Game Code

If KOS actually has to be recompiled like that, then how is it possible for DC homebrew like Pier Solar to save BOTH GAME and DATA files on a single VMU in a single executable?

[Light-Dark]

Jesus Christ, are you SURE you have to recompile all of KOS to do that!? That's absolutely horrible.

That offset is supposed to be 0 for DATA type files, where the header comes first then the data comes next. This is how standard save files work. Then GAME files require the header to be located at the first block, because block 0 is reserved for interrupt service routines and shit. So the layout in VMU flash is:

BLOCK 1: ISR Routines and Shit
BLOCK 2: VMS Header Data
BLOCK 3+: VMU Game Code

If KOS actually has to be recompiled like that, then how is it possible for DC homebrew like Pier Solar to save BOTH GAME and DATA files on a single VMU in a single executable?

Almost sure on this one. I used a VMU file explorer program ( the name of which is escaping me right now) and it has an option to "reformat" (or something like that) the VMU . Reformatting it fixed the "this game is damaged" error so I wondered what exactly it changed from my original standard KOS upload that made it work no problem. I then dumped an unmodified version and a reformatted version of the game I uploaded and wrote a program in C to isolate byte differences in the dumps and their locations in memory. I then went into the VMU drivers in KOS to check out whats going on with vmufs_write and found the header offset being set to 0 (regardless of whether or not you pass the flag determining whether you are writing a game or data).

Shit now that you mention that the offset should be 0 for Data (I didn't even think of that, thank you), I think this would probably be a more permanent solution:

nd.hdroff = (flags & VMUFS_VMUGAME) ? 1 : 0;

[short]

why not just?

Code: Select all

nd.hdroff = (bool)(flags & VMUFS_VMUGAME);

[Light-Dark]

why not just?

nd.hdroff = (bool)(flags & VMUFS_VMUGAME);

That works.