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

There is a chat room at my site. I would be happy to let you all use it.
I set it up for General Games Development, but no-one uses it!! I would
be happy to donate my room to the guys here.
It asks for a username and password but enter any username you want
without a password and away you go!
I won't be the one to set up chat meetings and such, however I will
administer the room itself, when it breaks down, someone let me know an
I'll fix it.
Go to www.g43.co.uk, pick which screen size you want and then there is
an option for games dev chat on the left hand bar/pane.
At least I'd know where to come for help. :-)

David John Springate
Lead Programmer
Team G43
Graymalkin 43
www.g43.co.uk
djs@...

> ----------
> From:  Richard Munn[SMTP:richard.munn@...]
> Reply To:  vmu-dev@egroups.com
> Sent:  10 July 2000 10:22
> To:  vmu-dev@egroups.com
> Subject:  [vmu] Re: Chat rooms
>
> >    I think that it would be a nice idea for someone to set up a chat
> room
> > for people that need help to get it as quickly as possible.
>
> Well, egroups gave us a chat room automagically, if you visit the list
> archive site (in footer of every message if you're subscribing to read
> by
> email) and there's also a voice chat thing.  Also someone did set up a
> irc
> # somewhere on the sega server, but it wasn't around last time I
> looked
> (after the entire sega site was swapped with the new one)
>
> --
>    _  Richard Munn  RAMTronics Software
>   //  www   : http://come.to/ramtronics
> \X/   email : richard.munn@...
>
>
> ----------------------------------------------------------------------
> --
> Law.com is the preeminent online destination for legal professionals.
> Visit Law.com for exclusive content from American Lawyer Media, online
> CLE Seminars, Practice Centers and Career Listings.
> http://click.egroups.com/1/5803/0/_/417030/_/963221079/
> ----------------------------------------------------------------------
> --
>
>        post:  vmu-dev@eGroups.com
> unsubscribe:  vmu-dev-unsubscribe@eGroups.com
>     archive:  http://www.egroups.com/group/vmu-dev/
>         faq:  http://rvmu.port5.com/faq.html
>
>

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

May I suggest using #vmu-dev (IRC) for that. IRC is the most useful
chat utility found around the net. All the webchat system are a pain
to use.

Leo.

rednuht wrote:
>
> There is plenty of example code of copying an image to the lcd screen.
>
> What i want to know is can we write to an image in memory and use this
> as a buffer for screen updates.

It is possible, but it would take 192 bytes of memory. I think using the
work memory area would be fine for this, because the auto incrementation
of the pointer would save a few cycles when copying it in the vram.

>
> So the game loop would call a sub that clears the lcd screen, then the
> buffer image is copied to the lcd screen.

Clearing the screen wouldn't be neccessary, because it would be
overwritten by the new image. In fact, clearing the screen would
probably make a lot of flickering.

>
> meaning any events in the game that require a change in the display
> could just write to the buffer and wait for the main loop to call the
> clear screen and buffer to screen.
>
> and could a copy (buffer) image be stored in the data part of memory.
> ?

Yes, but it would take 192 bytes... The advantage is it would be linear
(unlike the vram), and thus simpler to access to. Also, when doing
intensive graphic operations, it would prevent flickering.

--
Antoine 'MORB' Chavasse / CdBS software

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

>    I think that it would be a nice idea for someone to set up a chat room
> for people that need help to get it as quickly as possible.

Well, egroups gave us a chat room automagically, if you visit the list
archive site (in footer of every message if you're subscribing to read by
email) and there's also a voice chat thing.  Also someone did set up a irc
# somewhere on the sega server, but it wasn't around last time I looked
(after the entire sega site was swapped with the new one)

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

There is plenty of example code of copying an image to the lcd screen.

What i want to know is can we write to an image in memory and use this
as a buffer for screen updates.

So the game loop would call a sub that clears the lcd screen, then the
buffer image is copied to the lcd screen.

meaning any events in the game that require a change in the display
could just write to the buffer and wait for the main loop to call the
clear screen and buffer to screen.

and could a copy (buffer) image be stored in the data part of memory.
?

=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

could be very usefull

try it, we might like it

:)


--- Isaac Rounds <isaac@...> wrote: >     I think that it
would be a nice idea for someone to set up a chat
> room
> for people that need help to get it as quickly as possible. I would
> be happy
> to do so, but don't really want to waste my time with something that
> no one
> wants. So, what are your thoughts?
>     The only reason I can see that this idea is poor is that I think
> these
> lists might suffer, which I would hate to see happen. Perhaps a
> chatroom is
> not that necessary?
>
> isaac rounds
>
>
>


=====
Later ...

rednuht@...
-+-..=|<[{(_"!"_)}]>|=..-+-


__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

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

I think that it would be a nice idea for someone to set up a chat room
for people that need help to get it as quickly as possible. I would be happy
to do so, but don't really want to waste my time with something that no one
wants. So, what are your thoughts?
     The only reason I can see that this idea is poor is that I think these
lists might suffer, which I would hate to see happen. Perhaps a chatroom is
not that necessary?

isaac rounds

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

I think everyone should remember at times like this that Alexander
Villagran, who has done a lot for this group and lets face it, doesn't
have to, has put a lot of time and effort to not only help us but help
equip us with the OFFICIAL tools and knowledge we need to make VMU
games.
Richard and Leo I'm backin' ya'll all the way.
This is a respectable group of good, talented developers.
This is the Internet, and the way it was made to be.
Let's try and keep it that way.
VMU is a great little machine, and there is enough Dreamcast coverage
out there so theres no need for it to be in here.
I'd like to take this oppourtunity though to thank all the regular
'posters' on this group for not only giving me, the general public,
great help daily but great tools as well. Thanks guys.

David John Springate
Lead Programmer
Team G43
Graymalkin 43
www.g43.co.uk
djs@...

> ----------
> From:  Richard Munn[SMTP:richard.munn@...]
> Reply To:  vmu-dev@egroups.com
> Sent:  08 July 2000 17:03
> To:  vmu-dev@egroups.com
> Subject:  [vmu] Re: burned games are now working
>
> > this group has successfully made working (illeagaly) copied games
> for
> > dreamcast.....
>
> Don't forget that this list is primarily for VM development, and not
> for the
> discussion of piracy (I think it would be a fairly sensible policy to
> ban
> anybody who posts requests for illegal material)  I know I sort of
> started
> it all off with the post about the action replay thing, and I'm not
> saying
> anybody that has posted here is guilty of anything at all, but I'm
> just
> worried that the list might degrade into a "where can I download xxx
> game.
> Can someone burn me a copy" list, which isn't too desirable (and might
> get
> sega upset and make them be less helpful about the VM in future) ;-)
>
> --
>    _  Richard Munn  RAMTronics Software
>   //  www   : http://come.to/ramtronics
> \X/   email : richard.munn@...
>
>
> __________________________________________________
> Do You Yahoo!?
> Talk to your friends online with Yahoo! Messenger.
> http://im.yahoo.com
>
> ----------------------------------------------------------------------
> --
> Remember four years of good friends, bad clothes, explosive chemistry
> experiments.
> http://click.egroups.com/1/5532/0/_/417030/_/963072206/
> ----------------------------------------------------------------------
> --
>
>        post:  vmu-dev@eGroups.com
> unsubscribe:  vmu-dev-unsubscribe@eGroups.com
>     archive:  http://www.egroups.com/group/vmu-dev/
>         faq:  http://rvmu.port5.com/faq.html
>
>

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

--- In vmu-dev@egroups.com, Soeren Gust <sgust@i...> wrote:
>>Technical question...
>> * Would you think it could be possible to have a master program
>> (the only program we can run) that will swap in and out loadable
>> module (know today as minigame) and start to run them.
>>  * This master program will swap in swap from flash those new
>> minigames.
>
> Such modules are then not compatible with normal minigames, but
> basically its not too difficult if you reserve a fixed memory
> location for swap-in and run. The easiest solution is to make the
> control program big enough to contain your biggest module so that
> you can write to it with the normal writeflash call.

> In my own defense, i was not attempting to insinuate that ANYONE
> should be making illegle copies of games...

Don't worry, as I said in my post I wasn't trying to say that anyone
currently on the list is guilty of anything and I have no plans to ban
anybody at this time .

leo & I made a clear decision that this list should be fully unmoderated and
unrestricted as we felt anything else would curb creativity <and having to
confirm every posting is a pain in the arse>)) and in part I am to blame
from starting the whole thread.

Basically my message was that I don't want to see postings saying "Where can
I get xyz game" as I've seen perfectly respectable development channels
turn into warez pits before (Booyaka is already full of posts asking for
where the dc images can be found), and I don't want the hassle of geting
rude mails and phonecalls from Sega asking me to shut down the list (and
also we're at a point where sega are considering giving us official support
and dev stuff, so we don't want to piss them off now of all times!)

Right, let's try to stay on topic (although I suppose DC development is
loosely related) and call an end to this thread (oh yeah, and I've seen
some dreamcast development related lists here on egroups where the
discussion would be less OT ;-)

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


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Hi,

[no idea about RNG, sorry]

>I'm a little worried because I don't know how to figure out how big
>the code that my instructions are going to create is, and my project
>is going to use a *lot* of instructions; how do I make sure that the
>instructions don't run into the space I've got defined for my
>variables?  will the assembler move around them, or do I have to take
>that into account?

Variables are stored in the data segment which is the usable bank of
RAM (256-bytes). The rest is stored in code segment, either ROM or
in the very most cases, a bank of Flash ROM.

>Lastly, does anyone have any clue how to get two VMUs to talk to each
>other over the link?

It's done throught Port 1 and its associated registers but I never
used it myself so I don't know more about it.

So, okay.  I just noticed that I had no idea of how to get a random
number.  I took Marcus' Tetris out, but it looks like he's
implementing his own.  I only sorta know how RNGs work; not well
enough to write my own in a high-level language, and certainly not in
ASM, which I'm just now learning.  I can't follow Marcus' RNG without
comments, I think.

What's more, when I go and look for RNGs, I tend to get big complex
ones that are suitable for mathematicians, or for statisticians, or
for cryptographers - things that it would just be stupid to implement
on the VMU.  The basic ones that are built into most languages are
sufficient for things like this, and thus don't seem to get
duplicated
often enough for me to find them on the World Wide Mess.

I was wondering if anyone has a good, simple RNG?  I'd like to have
an
8-bit and a 16-bit one, but if the 8-bit one has a good distribution
(or however you'd say that), it seems like I ought to be able to
juststick two outputs together and call it a bigger variable, and
there I am.

If not, does anyone know where there's a reasonable overview on the
web somewhere of how RNGs work, so I can try to create my own?  If
they give examples, I'd really prefer something normal like C,
Pascal,
Lisp, or shell, or something;  ALGOL-90 isn't going to do me any good
(I say this only because I can't find an example in a normal
language,
so this may well be a useful differentiation to make).

On a seperate note, I'm beginning to wrestle with the notion of
having
to actually plan *where* my variables go.  Out of all of the examples
I have, the addresses pretty much don't coincide - this guy uses $30,
that guy uses $40, and so on.

I'm a little worried because I don't know how to figure out how big
the code that my instructions are going to create is, and my project
is going to use a *lot* of instructions; how do I make sure that the
instructions don't run into the space I've got defined for my
variables?  will the assembler move around them, or do I have to take
that into account?

One thing that occurred to me would be to begin defining variables at
the end of the possible program space, and move towards the
beginning.
That way, the only problem that would ever occur is if the two don't
fit together, and then I know what the nessecary solution is
immediately (no "maybe I can just move this here..."-ing).

I've seen people do some pad thing with nop to $200; is that them
putting no-ops in up to the address $200, implicating $200 as the
point to start defining backwards from?  Am I reading that wrong?

Lastly, does anyone have any clue how to get two VMUs to talk to each
other over the link?

Thanks.

- StoneCypher

In my own defense, i was not attempting to insinuate that ANYONE
should be making illegle copies of games, i was only stating that
someone had discovered how to boot from a cdr which could lead to
someone else making their own homebrewn games. The message was in
response to and intended for messages such as "Sony double-density CD-
ROM/R/RW" and "OT : DC Boot of CDR (?)". I would appreciate if i were
not banned from this list, as i have not done anything wrong, and i
was just trying to help the people here out. Please excuse my
ignorance in this issue, i did not intend to anger anyone.

Sincerest apologies,
-Petri

(ps. in case it is not clear, i do not support piracy, but a few
people here think that i do. Just wanted to clear that up)

Actually that they crack the security I can understand but i will not
understand the people who actively copy and distribute the games. The
URL below provides interesting news about the scene but that is all.

It looks like there have been two members of the Utopia crew been
arrested two days ago by german police. And it looks like they have
not been using their complete "own" code as they wanted the public
to know. I had a look at the binaries and they contain original sega
libraries as it appears.

Anyway I would like to see NO MORE of mails like this! We are not here
for distributing information on how to get illegal game copies!

Leo.

> this group has successfully made working (illeagaly) copied games for
> dreamcast. you can download the games supposedely if you mail the
> people they will give you access to their ftp servers. i know they
> have a lot of games working and they have a special bootCD which
> could give us an insight to making our own games
> the link is
> http://www.xtremehw.net/Dreamcast/

> this group has successfully made working (illeagaly) copied games for
> dreamcast.....

Don't forget that this list is primarily for VM development, and not for the
discussion of piracy (I think it would be a fairly sensible policy to ban
anybody who posts requests for illegal material)  I know I sort of started
it all off with the post about the action replay thing, and I'm not saying
anybody that has posted here is guilty of anything at all, but I'm just
worried that the list might degrade into a "where can I download xxx game.
Can someone burn me a copy" list, which isn't too desirable (and might get
sega upset and make them be less helpful about the VM in future) ;-)

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


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

this group has successfully made working (illeagaly) copied games for
dreamcast. you can download the games supposedely if you mail the
people they will give you access to their ftp servers. i know they
have a lot of games working and they have a special bootCD which
could give us an insight to making our own games
the link is
http://www.xtremehw.net/Dreamcast/

-Petri

> Technical question...
>  * Would you think it could be possible to have a master program (the
> only program we can run) that will swap in and out loadable module
> (know today as minigame) and start to run them.
>  * This master program will swap in swap from flash those new
> minigames.

Such modules are then not compatible with normal minigames, but basically
its not too difficult if you reserve a fixed memory location for swap-in
and run. The easiest solution is to make the control program big enough
to contain your biggest module so that you can write to it with the normal
writeflash call.

Hello,

I found out about DreamCast while in UK the weak they launch the
beast.
Month later I found out and VMU few month ago when by mistake I
downloaded something by mistake on Gnutella network.

So I browsed arround and found about independent developper (I know
you are on this list) and I raised the question (on another mailing
list): "Is it possible to develope without a Dreamcast?". I was told
about building a cable and communication with a PC.

This week I had a few pound to spend before leaving UK and guess
what... I brought a VMU.

I will of course have to worry about a cable (and I will go for
printer port because it use less electronics) and as time goes I will
go on and try to develop.

As a newcomer, I have a wish list of application. ;-)
I think a NotePad+Contact+Agenda+Calculator+Alarm(?)+...
a few games (snake+memory+...) would be the best application.
We could beat Palm Pilote, Nokia 61xx feature and other organiser in
size and uselessness feature.

I understand we can access the flash from mini-game (and save files
for notepad or contact list or agenda). Of course I would like to
exchange files with my girl friend to synchronise our contact list
and compare our agenda.

I also understand that we can only have one minigame at a time!!!
This mean it will have to be one application only.

QUESTIONS:
  Is anybody working on similar project?
  What do you think of this idea (sound crazy)?

Technical question...
  * Would you think it could be possible to have a master program (the
only program we can run) that will swap in and out loadable module
(know today as minigame) and start to run them.
  * This master program will swap in swap from flash those new
minigames.

David GLAUDE

(repost-- I think the first one was rejected because I had the wrong return
address)

> Sony has announced a double density CD-ROM/R/RW format. See the story
> at:
> http://www.zdnet.com/zdnn/stories/news/0,4586,2598043,00.html?chkpt=zdhpnews01
>
> I'm not sure how compatible this will be with the Sega's GD, especially
> since the GD uses a conventional CD zone and a high density zone. I
> doubt that the recordable media will be capable of shifting zones like
> this -- they usually have pre-existing tracks that the recorders follow
> to lay down new data. I guess the big question is that, if the whole
> disc is recorded at double density, will the Dreamcast notice that the
> first section isn't normal density?
>
> One interesting comment on the talkback section was that Sony is a
> competitor to Sega and that making dreamcast game possible (who knows if
> this is true-- i'd be more interested in authoring) it would be
> promoting the playstation.
>
> john

--- In vmu-dev@egroups.com, Omar Cornut <cornut@c...> wrote: > Hello everybody
(on both list :) >  > I'm posting from home - actually never posted from work -
because I don't > have Internet connection at work. >  > I'm new to VM and today
while reading the main PDF (the version from > the SDK10) I stumbled accross
something I couldn't understand: all  > exemples using relative jump seemed
buggy to me.  >  > I don't them handy so I can't quote the exact examples, but
the problems > were usually on the line using the "LA" label in those examples,
like >  >  BR  LA >  > What is unclear to me is which what value the assembler
replace LA. > Judging by these exemples it should be the relative value. >  >
But then why a JMP LA would work, JMP taking an absolute address?! > Someone to
clear up my mind and tell me where I am wrong?   The assembler accepts absolute
addresses for all branch instructions, and then converts them to relative if
needed.  This is because it would be a pain in the behind to have to write    
BR  LA-(.-1)  and similar everywhere.  All assemblers I know do this.     //
Marcus

Hello everybody (on both list :)

I'm posting from home - actually never posted from work - because I don't
have Internet connection at work.

I'm new to VM and today while reading the main PDF (the version from
the SDK10) I stumbled accross something I couldn't understand: all
exemples using relative jump seemed buggy to me.

I don't them handy so I can't quote the exact examples, but the problems
were usually on the line using the "LA" label in those examples, like

	 BR  LA

What is unclear to me is which what value the assembler replace LA.
Judging by these exemples it should be the relative value.

But then why a JMP LA would work, JMP taking an absolute address?!
Someone to clear up my mind and tell me where I am wrong?

Now I'm checking Marcus Comstedt's site and it says the same as in the
official docs for those opcodes. (Marcus's infos might have been copy &
pasted, thought).

Thanks,
Omar Cornut / Zoop

"Richard Munn (aka benjymous)" wrote:
>
> Take a look at this transcript of an interview that Bill McEwen(Amiga's
current head honcho) gave with CNN.Apparently they've demoed the OS on a
dreamcast (@ 20:18:00)I'd really like to get one of those discs!! (Assuming they
ever getthe OS out of vaporware status, that is...)

Yes, I've already heard of that. I think it would be very cool if Sega
adopts Amie as OS for the DC (or whatever future console they make),
both for Sega and Amiga. I'd rather see a boing ball in front of my
dreamcast than the winCE logo :)

--
Antoine 'MORB' Chavasse / CdBS Software

> See, this is the problem.  I can't see it, and I'm wondering if this
> is true for others.  I'm assuming that this is some privacy function
> of e-groups, but I haven't used it before, so I can't say for sure.
>
> Is it correct to assume that that says
>
>   subscribe-vmu-coders (at) sega (dot) com

Looks like egroups' anti-spam email masking thing.  it's not (at) sega (dot)
com but (at) soadtslist (dot) sega (dot) com


List address:
vmu-coders@...
[ vmu-coders (at) soadtslist (dot) sega (dot) com ]

Subscribe address:
subscribe-vmu-coders@...
[ subscribe-vmu-coders (at) soadtslist (dot) sega (dot) com ]

Unsubscribe address:
unsubscribe-vmu-coders@...
[ unsubscribe-vmu-coders (at) soadtslist (dot) sega (dot) com ]*
*
Administrator address:
admin-vmu-coders@...
[ admin-vmu-coders (at) soadtslist (dot) sega (dot) com ]


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

<de-lurk>

> subscribe-vmu-coders@s...

See, this is the problem.  I can't see it, and I'm wondering if this
is true for others.  I'm assuming that this is some privacy function
of e-groups, but I haven't used it before, so I can't say for sure.

Is it correct to assume that that says

    subscribe-vmu-coders (at) sega (dot) com

?

I'm going to try it, of course, but here's to public documentation.
No, it's not whining, it's documentation.  How?  Don't worry about
how.  Just know that I said so.  Okay?  Now go eat your dinner.

(sigh)

I think I need kids.

- StoneCypher

Take a look at this transcript of an interview that Bill McEwen(Amiga's current
head honcho) gave with CNN.Apparently they've demoed the OS on a dreamcast (@
20:18:00)I'd really like to get one of those discs!! (Assuming they ever getthe
OS out of vaporware status, that
is...)http://cnnfntech.yellowbrix.com/pages/cnnfntech/Story.nsp?story_id=1168091\
1&ID=cnnfntech&scategory=Computers