Isaac Rounds wrote:
>
> 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).

No. The only problem with this is to recognize which files are mini
games, and which others are not. BTW, those mini games will need to be
written specially for the kernel, so they can have some kind of
identifier at some arbitrarly fixed place to recognize them.

> 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

It's silply a matter of decoding the infos in the FAT and copy the blocs
in the right order.

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

I think it would be a little more complex than the kernel solution.

--
Antoine 'MORB' Chavasse / CdBS Software