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