--- In vmu-dev@egroups.com, "Isaac Rounds" <isaac@r...> wrote:
> I have been tinkering with that idea, myself,
>but have run across a few problems...
So it is a good idea if I am not the only one...
now maybe problems you encounter are not 'real'
and you should give up so fast.

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

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

> 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).
EXACTLY, the MODULE (= new minigame) need to look like GAME SAVE.
And the whole trick is to avoid the 1 minigame limitation.

> 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 =)
Well if we have a function (in ROM or Bios) to copy block of flash
from a high block (where game save reside) to low block (close to
zero where the minigame start... just after the kernel).

> 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.
Well, you want to staticaly link the games together
into a big minigame. It is not simple and require a lot of
work to remove duplicate symbole, and a program to deal with
the merge.
I prefere dynamic linking with MODULE and KERNEL.
It would allow to "exchange" MODULE(=new minigame)
the same way you "exchange" GAME SAVE.

> -Isaac Rounds
> ;;;;;;;;

TECHNICAL QUESTION TO GAME WRITER:
Minigames are always copy to a fixed address into memory (zero)...
Knowing that, and with the help of the assembler, it is eassy
to use absolute jump into the game.
Now in most assembling language, relative (to Program Counter)
jump are also available.
Would it be possible to write (with some self limitation) a
minigame that is relocatable (as for the code maybe not the data)?

What about the data?
If properly initialise at runtime could the data memory
be shared by various module (at diferent moment in time)?

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?

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)!

David GLAUDE