I haven't had enough time to really look at this, but just a caution on one
line of code...
Consider this routine...
; OUT: A, Y set to pat byte contents
GetPatByte
;
LDX PatIndex
NextByte
LDY PatFrame
BNE NextFrame
; if (PatFrame == 0) {
; get next pattern byte
INX
STX PatIndex ; inc pat index
; get patbyte
LDA EnemyPatTable,X
BEQ ResetPattern ; jump if sentinel end of pattern byte (0)
; get/set new PatFrame
AND #$C0
CLC
ROL
ROL
ROL
STA PatFrame
NextFrame
DEC PatFrame
LDA EnemyPatTable,X
BEQ ResetPattern
TAY
RTS
ResetPattern
TAX
DEX
STX PatIndex
STA PatFrame
BCS NextByte ; ALWAYS Taken
The last comment appears to be incorrect. I can see situations where the
carry will be clear at this point. For example, after...
AND #$C0
CLC
ROL
ROL
ROL
STA PatFrame
the carry would be clear (since you roll off the top two bits, and then one
you have guaranteed to be 0), so if you then get to ResetPattern as a result
of ...
NextFrame
DEC PatFrame
LDA EnemyPatTable,X
BEQ ResetPattern
which is highly possible, you will be going there with carry CLEAR.
So the BCS at the end *won't* be taken and you will instead execute the next
function StorePatVal inadvertently.
The moral: If you're going to use unconditional branches be really really
really sure of your "uncondition"!
The above probably isn't the problem, but it is A problem.
Cheers
A
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
