>Date: Mon, 25 Sep 2000 10:56:10 +0200
>From: MORB <MORB@...>
>Subject: Re: Multi-code Game - Bigger better games  :)
>Maybe people just don't have time for serious VMU coding...

My problem is that I don't have a DreamCast,
I am still suppose to build my cable (I have the parallel cable open up but
still need to mesure output).
And after the problem will be to build a connector, then...
Then it is the TIME to develope something. (with all of those other
project).

The level of understanding you need to reach before making anything usefull
seems high!

David GLAUDE

PS: I could try to start developping on the Emulator... Yes library
(sprite/sound) could help a bit, but not too much.

MORB wrote:
>
> rednuht wrote:
>
> >
> > Hi,
> >
> > There does not appear to be a huge increase of the number of
> > games/programs being released and wonder if it is because (especialy
>
> Maybe people just don't have time for serious VMU coding... I would have
> done some stuff, but I crashed my developement partition and lost many
> things (including some crazy stuff such a partially working vmu 3d
> engine, and a vmu demo that we were to present at a demo party)
>
> Until I recover my files on my crashed partition, however, I can't
> continue all this stuff :(
>
> But I'm afraid that much people have lost their interest in vmu coding
> in favor of dreamcast coding...


Well for now, I've gone back to coding OpenGL now that I've got full 3D
acceleration in Linux with XFree86 4.0.1.  I had a great VMU game idea
that I was working on but my sprite blitter had some problems.  I really
need a debugger if I'm going to continue VMU development.  I actually
wrote one in the style of GDB (GNU Debugger), but when it didn't work I
had no ambition to fix it.  I'd be happy to give the source to anyone
who wants it, it might be simple to fix, but I just don't care enough.
With a little work I had hoped to integrate it with DDD (Data Display
Debugger) for a nice GUI debugger for the VMU! =)

Anyway, I think if someone could write some reusable code that is
generic but efficient enough to incorporate into any game project, it
could really speed up development time. If someone would like to help
me, I can post my 8x8 sprite blitter that I thought was so ingenious and
someone could tell me why on this earth the damn thing doesn't work.

At any rate, the game I was working on was an Action/RPG style game.  I
have most of it designed on paper. It's practically a design document.
But until I have a working debugger, or some well written low-level code
to work with, I'm afraid I just don't have the motivation to get bogged
down with the ugly details of VMU coding.


-----------------------------------------------------------------------
  Brian Chapman                  (aka: antigrav - irc.openprojects.net)
-----------------------------------------------------------------------
   "Do you want to make people's heads explode? Sure -- we all do!..."
                                                  -Dr. Forrester, MST3K

rednuht wrote:

>
> Hi,
>
> There does not appear to be a huge increase of the number of
> games/programs being released and wonder if it is because (especialy

Maybe people just don't have time for serious VMU coding... I would have
done some stuff, but I crashed my developement partition and lost many
things (including some crazy stuff such a partially working vmu 3d
engine, and a vmu demo that we were to present at a demo party)

Until I recover my files on my crashed partition, however, I can't
continue all this stuff :(

But I'm afraid that much people have lost their interest in vmu coding
in favor of dreamcast coding...

--
Antoine 'MORB' Chavasse / CdBS Software

Hi,

There does not appear to be a huge increase of the number of
games/programs being released and wonder if it is because (especialy
people who have not yet written for the VMU) see it as a too big a task
to go from nothing to a cool game.

Sooo... Does anybody want to think about a game/progie that could be
split up into individual routines and we all write different ones,
meaning we get to a finished game much quicker?

This should create a bigger better game than any one of us may slave
over for weeks or months.

post game suggestions here!!



=====
Later ...

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


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

Drat! I am answering my own post again.

> has anyone documented any differences between the current batch of
> emulators and the VMU itself?

well?

> My big post a while back seems to be associated with my bad coding
> and
> the disrigard of unused bit states.

doh, it does appear to be my particular brand of bad coding.

On the VMU bit 4 of the VSEL is SET at reset and on the emulator it is
cleared.
(bit 4 of the VSEL sets the auto increment option for the work RAM
pointer)

Problem being that I spent all week ripping my code apart to find this.

Of cource you should manualy set the bit regardless, but just incase
you are having a simular strange problem with code working on the
emulator but not on the unit itself, check when you use the work RAM
and if you explictly set/cleared the bit.



=====
Later ...

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


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

--- tyro@... wrote:
> > www.jumpstation.co.uk
>
> Hm... the 'normal' Space Invaders .VMS file that can be downloaded
> from
> your page seems to be buggy (doesn't work), while the one included in
> the
> .ZIP file does.  Guess you should check it out. :)
>
> About the game... really not bad.  Not bad at all  But IMHO gameplay
> could
> be a lot more fun if the aliens would shoot back. ;)

erm, im not sure why i did not get this mail until today 21/09/2000 but
anyway.

I think the file problems were before i got the mirrors servers up, as
no one else has reported any problems.

Thanks, I think its quite cool and I have had lots of positive feedback
about it.

and yes i agree it would have been more fun if the aliens shoot back,
but a the end of it i had had enough, feel free to edit / re-release
it.


=====
Later ...

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


__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

On 05 Sep 00, rednuht@... (rednuht) wrote:

> At long last I have finally uploaded my files to a web page.
> the damm MIME types don't work (i am trying something) so can't
> download with a dreamcast.
>
> www.jumpstation.co.uk

Hm... the 'normal' Space Invaders .VMS file that can be downloaded from
your page seems to be buggy (doesn't work), while the one included in the
.ZIP file does.  Guess you should check it out. :)

About the game... really not bad.  Not bad at all  But IMHO gameplay could
be a lot more fun if the aliens would shoot back. ;)

Bye


Alessandro
---
You get what anyone gets. You get a lifetime.

On Mon, Sep 18, 2000 at 09:10:36PM +0200, Jeroen Domburg wrote:

> >Then there are 4 bits of
> >input to P7.
>
> Are these pins configurable as outputs to? If they are, that would do just
> the trick. And do you have any idea to which pins of the Potato they are
> connected?

They are available on the external connector, but I doubt that they can be
used as outputs, there is no P7DDR afaik.

Soeren

> Well, I do lots of stuff concerning microcontrollers and electronics, and I
> thought I might use the VMU for things like a tiny logic analyzer or scope.

I personally thing that someone should make a Lego Mindstorms style robot kit
using a VM as the central controller.  This would be very cool, and would be
sure to sell lots of dreamcasts to schools!

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

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/

>On Sun, Sep 10, 2000 at 12:52:51PM +0200, Jeroen Domburg wrote:
>
>> Does anyone know if the big 144-pin Potatoe-IC inside the VMU has some
>> general purpose I/O-pins left? IN the memory map I saw some vague
>> references to 'P0', 'P2' and 'P3'. Are these general IO pins and, if yes,
>> are they accessible as a pin on the chip?
>
>Why do you need them? Sounds like an interesting project...

Well, I do lots of stuff concerning microcontrollers and electronics, and I
thought I might use the VMU for things like a tiny logic analyzer or scope.

>6 bits of P1 are connected to the external connector, 3 configured as
>input, 3 configured as output, I don't know if there are extra drivers on
>them preventing you to change the directions.

>Then there are 4 bits of
>input to P7.

Are these pins configurable as outputs to? If they are, that would do just
the trick. And do you have any idea to which pins of the Potato they are
connected?

>Another idea is P3, it is connected internally to the buttons, so if you
>don't need them they are available as soon as your program is running.
>There is a P3DDR register, so you could use them as outputs.

Neah, I like the buttons...

But I read something about a P4 and P0 port too. Do you know anything about
these ones?

Anyway, thanxx for the reaction.

>Soeren

Jeroen Domburg
'------------------{ Signature follows: }------------------


(This signature has intentionally been left blank)

Jeroen Domburg
  Domburg@...
  Jeroen@...
  Sprite_JD@...

hi,

can someone please post a function that simply determins if the code is
running in the emulator or not, thanks.
(I know this will not garenty all timings working fine, but it would
help).


=====
Later ...

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


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

hi,

has anyone documented any differences between the current batch of
emulators and the VMU itself?

My big post a while back seems to be associated with my bad coding and
the disrigard of unused bit states.

But my new project is not crashing but seriously screwing up, I think
it has to do with the TRL/TRH registers but it might take me a while to
work it out (works fine in currently emulators).

Anyone got ANY info ??

thanks

=====
Later ...

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


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

On Sun, Sep 10, 2000 at 12:52:51PM +0200, Jeroen Domburg wrote:

> Does anyone know if the big 144-pin Potatoe-IC inside the VMU has some
> general purpose I/O-pins left? IN the memory map I saw some vague
> references to 'P0', 'P2' and 'P3'. Are these general IO pins and, if yes,
> are they accessible as a pin on the chip?

Why do you need them? Sounds like an interesting project...

6 bits of P1 are connected to the external connector, 3 configured as
input, 3 configured as output, I don't know if there are extra drivers on
them preventing you to change the directions. Then there are 4 bits of
input to P7.

Another idea is P3, it is connected internally to the buttons, so if you
don't need them they are available as soon as your program is running.
There is a P3DDR register, so you could use them as outputs.

Soeren

I've left the hardware questions for those who're more knowledable in
that area...

> And one last question: I heard Sega was going to release the VMU
devving
> stuff to the public. Anyone has any info on when exactly?

Well, the current problem is that the VM dev tools weren't made in
house by sega, and so they're having to negotiate with the authors
(which seems to be taking a while, and possibly may never get
resolved)

However, the freeware tools made by marcus, john et al, are very good
(and the new directx port of softvms contains a debugger, which will
be handy), so the main push is to get sega to release all the VMU
programming documentation (which would let us make the tools more
correct and compatible, and would also allow for much better games!)

I'm sorry I can't be more specific, but why not read it for yourself
through the vmu-dev list archive on the web (url in the email footer)

According to the UK Official DC mag, Sega's new 4x memory card will
not contain a screen, or use batteries.

Shame :(

Hello ppl,

Does anyone know if the big 144-pin Potatoe-IC inside the VMU has some
general purpose I/O-pins left? IN the memory map I saw some vague
references to 'P0', 'P2' and 'P3'. Are these general IO pins and, if yes,
are they accessible as a pin on the chip?

And one last question: I heard Sega was going to release the VMU devving
stuff to the public. Anyone has any info on when exactly?

Thanxx,

Jeroen Domburg.
'------------------{ Signature follows: }------------------


(This signature has intentionally been left blank)

Jeroen Domburg
  Domburg@...
  Jeroen@...
  Sprite_JD@...

you can now download SPACE INVADERS (VMU Style) direct to the dreamcast
from www.jumpstation.co.uk, I finaly got my file mirrors working.

=====
Later ...

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


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

>I found the following on booyaka, can anyone confirm if its true.
>
> > http://www.hkems.com
> >
> > download V2.1B and use 241.dcm on Nexus DC SAVE CARD to get 241
> >blocks per page ......
> >
> >the h/p updated again ... now is V2.11B ...
> >have direct format to 200/240/241 blocks per page for NEXUS DC SAVE
> >CARD ...

I tried the hacked memory save (dcm) and it works fine! I filled the card
with 240 blocks and tried if a game would still read it's save and it had
no problem!

> I found the following on booyaka, can anyone confirm if its true.
>
> > http://www.hkems.com
> >
> > download V2.1B and use 241.dcm on Nexus DC SAVE CARD to get 241
> >blocks per page ......
> >
> >the h/p updated again ... now is V2.11B ...
> >have direct format to 200/240/241 blocks per page for NEXUS DC SAVE
> >CARD ...

Well from what I can see on the hkems site, it is genuine (ems made the nexus
so they should know)

I guess what's being done is to provide a "blank card" image which has a hacked
file table, giving 241 free blocks instead of 200 (which was suggested as
possible a while ago on this list)

I can't test it at the moment, as I'm miles away from my DC, but I'm sure
somebody will (just remember to backup your saves first!!)

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

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

I found the following on booyaka, can anyone confirm if its true.

> http://www.hkems.com
>
> download V2.1B and use 241.dcm on Nexus DC SAVE CARD to get 241
>blocks per page ......
>
>the h/p updated again ... now is V2.11B ...
>have direct format to 200/240/241 blocks per page for NEXUS DC SAVE
>CARD ...





=====
Later ...

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


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

> >I'll sit down one evening and try and get that finished off (although my
> free
> >time has gone out of the window, having got myself a job at Codemasters)
>
> I know this is off topic, but weren't they the one's who made the Game
> Genie for Genesis?

Yup, that's right

> What do they do now?

They're the biggest games publisher in Britain, and do lots of in house
developent.  I don't know how many of their games have made it over to the US,
but they've got a huge string of hit releases for the playstation over here
(take a look at codemasters.com)


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

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

--- tyro@... wrote: > Hello.
> >     INC  xbnk           ; next 16 pixels please
> >     LD   xbnk
> >     BE   #$02,.quitin   ; we are updating the LCD icon memory today
> > .continue:
> >     INC  2
> >     BR   .blit          ; still more to go
>
> I once made that exact same mistake.  The problem with the VMU is
> that
> there are a some registers where only certain bits are used, meaning
> that
> the other bit locations simply aren't _there_ (instead of just being
>
> zero).  And the XBNK register is one of them.
>
> Now when you load such a register, you never know what bits will be
> returned for the not-present locations.  I suggest your VMU emulator
>
> simply returns 0's for those, which is the reason why your 'BE
> #$02,.quitin' works.  On a real VMU however, some of the non-present
> bits
> might be returned as 1's, and thus the compare never matches #$02.
>
> As a result, after INCreasing the XBNK value to point to bank 2
> (which is
> the bank that holds the VMU icons), instead of quitting your routine
>
> continues to copy data, causing the icons to go haywire, and
> eventually
> the VMU will 'hang'. ;)
>
> As a quick fix, you could for example the following:
>
>     LD   xbnk
>     AND  #%00000011     ; clear all bits from non-existant locations
>     BE   #$02,.quitin   ; compare should work now
>
> or just
>
>     INC  xbnk
>     BN xbnk,1,.quitin   ; branch as long as bit 1 isn't set in XBNK
>


OK thats sound pretty reasonable, I wounder what the other bits are
used for?


> Also note that this part of your code is 'buggy' too:
>
> >     MOV  #$81,C       ; count down half the screen
> > .blit:
> >     LD   VTRBF        ; load 8 pixels of screen data
> >     ST   @R2          ; save it to the LCD memory
> >     DEC  C            ; counter
> >     LD   C            ; counter
> >     BNZ  .continue    ; if its zero then we need to change the bank
>
> Here you aren't copying #$80 bytes (which equals one half of the LCD
>
> screen), but instead _#$81_ bytes, meaning that one extra byte is
> written
> to Work Ram offset $00 in the other Work Ram area (because you used
> auto-
> increment).  Since you only use the Work Ram at offset $80 and above,
> this
> doesn't have any negative effect, though.
>
> To fix this, use
>
>     MOV #$80,C
>
> as counter value, not #$81.  To see what I mean, let's suggest you
> want to
> copy only ONE byte instead of #$80 bytes... based on your example,
> for
> that you would set the counter to #$02, correct?  Now look at your
> code
> again and check how many bytes would actually be copied. :)
>
> BTW, a counter and lots of branches back and forth IMHO aren't the
> best
> way to do a routine like this.  Ignoring the fact that it's not all
> that
> wise to copy data to those XBNK locations that should be skipped (4
> bytes
> after every 2 screen lines), I think the following version would work
>
> smoothest:
>
> works:
>     SET1 VSEL,4         ; autoincrement please
>     ;
>     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
>     MOV  #$00,VRMAD2    ; IMHO safer than messing with bits :)
>     MOV  #$80,2         ; the pointer to the LCD memory
>     MOV  #0,xbnk        ; start with the top 16 pixels
>     ;
> .blit:
>     LD   VTRBF          ; load 8 pixels of screen data
>     ST   @R2            ; save it to the LCD memory
>     INC  2              ; no auto increment on the LCD memory
>     ;
>     BP 2,7,.blit        ; since you have to count from $80 upward,
> the
>                         ; first screen half is completely copied when
>                         ; the pointer switches from #$ff back to #$00
>                         ; (meaning that bit 7 is cleared)
>     ;
>     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
>     MOV  #$01,VRMAD2    ; this time we select the other Work Ram area
>     MOV  #$80,2         ; set pointer to start of LCD memory again
>     INC  xbnk           ; next bank
>     ;
>     BN xbnk,1,.blit     ; branch as long as bit 1 isn't set in XBNK
>     ;
> .quitin:                ; the end :)
>
> Hope this helps. :)
>


damm your good, that sounds reasonable as well.


> And finally, please keep in mind that some of ther earlier versions
> of
> Marcus' VMU emulator (especially the early DOS ports by Colm Cox)
> seem to
> support only one of the Work Ram areas.  Therefore I made it a rule
> for me
> that unless there really and truly isn't a way around it, I only use
> _one_
> of the Work Ram areas in my games.  Of course this is completely your
>
> choice, but if you want your game to work on _all_ of the available
> emulators around, I would invest the extra 10 minutes to store all
> the
> screen data in only one Work Ram area. ;)
>

I never knew that, for my next game I will be a bit more carefull.

> > The Space Invaders game is now 100% complete (as far as I am
> > concerned) and as soon as I have added a comment to every line
> > (you heard right, EVERY LINE (excluding blank ones)) and put
> > together a groovy web page for it I will let everyone have access.
>
> Cool!  Can you send me a 'preview' copy of the compiled game, please?
>  I'm
> currently messing around a bit with writing a 'Galaxian'-type game...
>

It is available at www.jumpstation.co.uk (no dreamcast downloads though)

=====
Later ...

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


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

At long last I have finally uploaded my files to a web page.
the damm MIME types don't work (i am trying something) so can't
download with a dreamcast.

www.jumpstation.co.uk

Dig the day/night mode :)

=====
Later ...

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


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

Hello.

Haven't checked the list since about a week, so I don't know if this
question has been answered yet.  Anyway, here goes...

On 26 Aug 00, rednuht@... (rednuht) wrote:

> << ALL LINES IN THIS POST ARE LESS THAN 70 CHARACTERS IN LENGTH >>

Thanks again. :)  It really improves readability of source code when using
a standard mailreader.

> Well below I have two routines the one called WORKS, supprising
> works perfectly (Emulator and VMU)

> The second routine is called EMULATORONLY and, yes you guessed
> it, only works on the emulator, but why?

> so my question is why, in its current form (as below), does the
> VMU crash (locks up and the game icon goes out while the clock and
> flash icons come on) but the emulator works 100% OK?

I guess this is what causes it:

>     INC  xbnk           ; next 16 pixels please
>     LD   xbnk
>     BE   #$02,.quitin   ; we are updating the LCD icon memory today
> .continue:
>     INC  2
>     BR   .blit          ; still more to go

I once made that exact same mistake.  The problem with the VMU is that
there are a some registers where only certain bits are used, meaning that
the other bit locations simply aren't _there_ (instead of just being
zero).  And the XBNK register is one of them.

Now when you load such a register, you never know what bits will be
returned for the not-present locations.  I suggest your VMU emulator
simply returns 0's for those, which is the reason why your 'BE
#$02,.quitin' works.  On a real VMU however, some of the non-present bits
might be returned as 1's, and thus the compare never matches #$02.

As a result, after INCreasing the XBNK value to point to bank 2 (which is
the bank that holds the VMU icons), instead of quitting your routine
continues to copy data, causing the icons to go haywire, and eventually
the VMU will 'hang'. ;)

As a quick fix, you could for example the following:

     LD   xbnk
     AND  #%00000011     ; clear all bits from non-existant locations
     BE   #$02,.quitin   ; compare should work now

or just

     INC  xbnk
     BN xbnk,1,.quitin   ; branch as long as bit 1 isn't set in XBNK

Also note that this part of your code is 'buggy' too:

>     MOV  #$81,C       ; count down half the screen
> .blit:
>     LD   VTRBF        ; load 8 pixels of screen data
>     ST   @R2          ; save it to the LCD memory
>     DEC  C            ; counter
>     LD   C            ; counter
>     BNZ  .continue    ; if its zero then we need to change the bank

Here you aren't copying #$80 bytes (which equals one half of the LCD
screen), but instead _#$81_ bytes, meaning that one extra byte is written
to Work Ram offset $00 in the other Work Ram area (because you used auto-
increment).  Since you only use the Work Ram at offset $80 and above, this
doesn't have any negative effect, though.

To fix this, use

     MOV #$80,C

as counter value, not #$81.  To see what I mean, let's suggest you want to
copy only ONE byte instead of #$80 bytes... based on your example, for
that you would set the counter to #$02, correct?  Now look at your code
again and check how many bytes would actually be copied. :)

BTW, a counter and lots of branches back and forth IMHO aren't the best
way to do a routine like this.  Ignoring the fact that it's not all that
wise to copy data to those XBNK locations that should be skipped (4 bytes
after every 2 screen lines), I think the following version would work
smoothest:

works:
     SET1 VSEL,4         ; autoincrement please
     ;
     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
     MOV  #$00,VRMAD2    ; IMHO safer than messing with bits :)
     MOV  #$80,2         ; the pointer to the LCD memory
     MOV  #0,xbnk        ; start with the top 16 pixels
     ;
.blit:
     LD   VTRBF          ; load 8 pixels of screen data
     ST   @R2            ; save it to the LCD memory
     INC  2              ; no auto increment on the LCD memory
     ;
     BP 2,7,.blit        ; since you have to count from $80 upward, the
                         ; first screen half is completely copied when
                         ; the pointer switches from #$ff back to #$00
                         ; (meaning that bit 7 is cleared)
     ;
     MOV  #$80,VRMAD1    ; the pointer to our off screen buffer
     MOV  #$01,VRMAD2    ; this time we select the other Work Ram area
     MOV  #$80,2         ; set pointer to start of LCD memory again
     INC  xbnk           ; next bank
     ;
     BN xbnk,1,.blit     ; branch as long as bit 1 isn't set in XBNK
     ;
.quitin:                ; the end :)

Hope this helps. :)

And finally, please keep in mind that some of ther earlier versions of
Marcus' VMU emulator (especially the early DOS ports by Colm Cox) seem to
support only one of the Work Ram areas.  Therefore I made it a rule for me
that unless there really and truly isn't a way around it, I only use _one_
of the Work Ram areas in my games.  Of course this is completely your
choice, but if you want your game to work on _all_ of the available
emulators around, I would invest the extra 10 minutes to store all the
screen data in only one Work Ram area. ;)

> The Space Invaders game is now 100% complete (as far as I am
> concerned) and as soon as I have added a comment to every line
> (you heard right, EVERY LINE (excluding blank ones)) and put
> together a groovy web page for it I will let everyone have access.

Cool!  Can you send me a 'preview' copy of the compiled game, please?  I'm
currently messing around a bit with writing a 'Galaxian'-type game...

Bye


Alessandro
---
You get what anyone gets. You get a lifetime.

>I'll sit down one evening and try and get that finished off (although my free
>time has gone out of the window, having got myself a job at Codemasters)

I know this is off topic, but weren't they the one's who made the Game
Genie for Genesis?

What do they do now?

> http://dreamcast.ign.com/news/24480.html

> bet it will not allow page switching so still one game per vmu :(

but that could be a good thing, since it would allow a single game to
be four times bigger than the current limit!

http://dreamcast.ign.com/news/24480.html

bet it will not allow page switching so still one game per vmu :(

=====
Later ...

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


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

For those using windows that want some tools,
you can get the newest version online now at:
http://rpging.simplenet.com/directvms.html

I updated the debug window to be actually useful
and have more planned. Also has step and
pausing features to make for easier debugging
of VMS games. Also has a breakpoint sort of deal
where (I think was previously done here) when an
unused register ($10A) is written to, the emulator
stops and jumps to the debug window (or just
updates the values in the window without pausing).
Check the site and the readme link for info.

> your were probably on holiday during the last month so
> I did not write to remind you but now it is time to get
> the next online tutorialdone. Who'd like to be the next?

Well, I've got a "Setting up a development environment" tutorial about 60%
written (in 3 flavours for dos/windows, 'nix and amiga)

I'll sit down one evening and try and get that finished off (although my free
time has gone out of the window, having got myself a job at Codemasters)



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

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

Hi,

your were probably on holiday during the last month so
I did not write to remind you but now it is time to get
the next online tutorialdone. Who'd like to be the next?

Go ahead!

Leo.