> > Most game I have seen so far are quite small...
> > (except Packman), now I am not talking about "animation"
> > neither minigame build into game for the dreamcast.
>
> > I expect the kernel to be very small too,
> > and because the kernel will handle some common task,
> > the hello_world template for MODULE will be smaller
> > (so will be those MODULE).
>
> Yes, but the big problem here is that the VM game must exist
> only in the first 128 blocks of the card, and so the only way
> you could swap in a new game is if you can *guarantee* that
> the whole area is empty, and doesn't contain game saves
> which might get overwritten. Therefore the kernel would
> either have to be a maximum fixed size, or we'd have to work
> out fat table modification code and make the program move any
> saves from the 0-128 area, and then adjust the size of itself
> to be big enough to hold the new module.

So this let us two option as for the KERNEL size:
1) Make a small KERNEL and a dummy swap space for MODULE
[and we limit ourself to a fixed size that could be the maximum]
2) We smartly play with the FAT and relocate SAVED GAME to
somewhere else (above) for having space for the MODULE (above the
KERNEL).

As for smartly playing with the FAT, we will have to read the FAT,
display a user interface to let one choose a MODULE based on...
ICONE, date and time (and some way we need to differenciate between
real SAVED GAME and MODULE using a "MAGIC NUMBER" technique) and
copy the MODULE into the swap area (above kernel).

Now as for the display of the directory (sort of but limited to
MODULE) I think the code is already build into the system...
It could be analyse, modified and/or reused.

About FAT anybody made a minigame that actualy write something
or play/modify the fat/flash? Like saving high score!

JOKE: Anybody want to make a "defrag" for VMU? ;-)

> > Exemple: We don't need the icone into the game anymore(?)
> I think we would, ...
Ok so same external structure as a SAVED GAME but with the inside
of a modified minigame.

> > Minigames are always copy to a fixed address into memory (zero)...
> > What about the data?
> > If properly initialise at runtime could the data memory
> > be shared by various module (at diferent moment in time)?
> I suppose you could make some code that pushes all your
> important variables to the stack when you leave your code,
> and pops them off again when you return. This way other code
> can do anything it likes in memory without damaging
> anything your code did.

Excuse me, where is the stack anyway?

I don't remember why I did ask the question, but
if variable space (where ever it is) could be access relatively
to a register (as apposed to absolutely) or could be restriced
to a well know range of addresses (or a define [inside the module]
range of addresses) then that peace of memory could be saved
(=swap out?) before the module is actually replaced by another one.

And that way we could swap-in/swap-out module with their memory
"segment" and when you re-swap-in the same module, you stay in the
same context (=PAUSE Tetris, start Blockout, PAUSE Tetris and
continue Tetris). I don't know if this is really worth the effort
(if at all technicaly possible).

NOW back to a previous question:
Is it possible (without loosing too much flexibility
in game writing) to have relocatable code for minigame?
The reason I am asking is that this would allow the kernel
to grow in size without having to recompile every module.

A few option otherwise...
1) Have a fixed start module (exemple block number 32) even if we
don't have the kernel that big yet.
2) Make it eassy to reassemble the MODULE for various starting
position (what if the source code is not available?)
3) Make the Module always load backward, starting from the top
(128 and down in direction of the kernel) but this will wast
a lot of space (in between) and might be difficult to explain
to the assembler (last byte should be that adress as opposed
to .org xxx ).

Whatever way the KERNEL idea goes, writing a MODULE will have
more limitations or rules to respect than writing MINI GAME.

David GLAUDE

PS: I seems to get more and more peaple interested ;-) it it good.

--
> _ Richard Munn RAMTronics Software
> // www : http://come.to/ramtronics
> \X/ email : richard.munn@b...