I have been tinkering with that idea, myself, but have run across a few
problems...
First of all, the space issue. It's hard enough to get much to fit in
the 200 blocks, so a kernel of sorts would make it even harder...
Secondly, if I remember correctly, the browser gives an error and
refuses to download more than one gamefile. So, unless there was a way to
bypass that, you would need to change the type of file from GAME to SAVE,
which could hinder the process further (or so it would seem).
Also, I don't know how difficult it would be to get the 'kernel' to copy
the program to be run (integrate it... you know what I mean?), but I would
think it quite hard... It would take quite the skilled programmer, but
there's plenty of those around =)
I would think that it would be better to just have a repository of
mini-games and the like that allowed you to choose multiple ones (up to 200
blocks worth) which would then modify the code to allow no conflicts with
the other games, and splice them all together complete with a nifty GUI,
and, finally, assemble the complete file. So, you could select, say, Tetris
and Pac-Man (assuming they are a maximum of 200 blocks combined) and change
the variable addresses and function names as to eliminate any conflictions,
and the program would splice the two together and customize the GUI to
display the filenames, then assemble that whole thing to a temporary spot
and allow you to download it. This would be difficult, but do-able, correct?
Anyways, just my two-cents. I agree that something of the sort should be
done, though. It would get annoying having to constantly switch (quick fix:
buy a lot of VMU's ^-^)

-Isaac Rounds
;;;;;;;;

>Hello everybody,
>
>I want to make sure everybody (capable of developping minigames or
>other for the VMU) fully understand the potential of the technical
>answer we just receaved.
>
>I think the folowing is possible:
> 1) Create a KERNEL minigame that will offer a way to select any file
>in the memory and write it into running space... then the kernel will
>jump into that running space (the swap space) and start to execute
>whatever was in this file!
> 2) Every minigame could be rewrited to work launched by this kernel
>(thus from a well known memory location).
> 3) Somehow the minigame should offer a way to jump back to the
>kernel to let one load another minigame.
>
>The effect of this way of working is that you could have with you in
>your VMU a single dummy minigame: THE KERNEL and choose to load and
>play any of the real minigame you have saved in the memory (without
>having to reconnect back to your DreamCast).
>
>Now what should be discuss?: (and maybe this list is the best place)
> * What do we need in the kernel (minimal user interface to swap in
>and out + ...)
> * How a module "call-back" the kernel to allow selection of another
>minigame module?
> * Could we implement a set a common usefull function that could be
>used by many minigame in order to save space on all of them?
> * What should be the size available for those module (maximum
>minigame size!?)? Could we have a small, medium and big kernel that
>support different size of module?
>
>QUESTIONS:
>So does it still sound technicaly possible to do?
>Isn't this a good idea that is worth the try?
>If you are a minigame developer and a kernel exist, would you spend
>the time to adapt your minigame (very important if you don't provide
>the source code of your minigame).
>If you are a very good minigame developper, could you test the idea
>and build a kernel and adapt one of your game and (let say) tetris
>for this kernel?
>
>Thanks for listening and I hope to make this look so much an
>interesting idea that it will build-up one day.
>
>David GLAUDE
>
>PS: I promise that as soon as I have my PC cable working, made my few
>first minigame and have some more time, I will personnaly work on the
>project. ;-) Unfortunately I don't have the equipement and expertise
>yet to help (but I am ready to discuss and share idea as much as you
>want).
>