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.