>
>> 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...
> 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 kernal 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.

> Exemple: We don't need the icone into the game anymore(?)

I think we would, since a file without an icon just shows up as a square
with a red cross through it on the dc file manager, and also the icon area
also holds the title and description that the filemanager shows. If this
header was missing you'd just get random looking text (since there's no way
of telling the filemanager that it's okay and the file shouldn't have an
icon or title)

If an end user sees a file like that they're likely to assume something is
broken and start sending paniked emails at everyone!


> 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.

> I know the flash file system contain a FAT like structure.
> Does this mean that all the block of a GAME SAVE could be
> not countiguous or in the reverse order?

Yup. A Game file is always contiguous from block zero onwards, since it
makes it easy for the VM to actually run the code that way. However, since
the saves are always handled by a DC, they can be fragmented all across the
memory

> This will make it imposible to actually run on place
> (and the need to copy the module block by block into the
> prealocate location close to the kernel)!

Yup. That's basically what I said above!

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