03-07-2010, 10:53 PM
In this case, it's a bug in your program: in fspInitialize you call fspData():
And later call fspDisable() with n = 0:
Look carefully at the above code and now look at fsbData definition:
When you call fspDisable(0) you're effectively *destroying* the RETURN sentence of fspData(), because you're doing
POKE @fspDataStart, 99 (which is @RETURN address). Rewriting fspData this way, fixes the bug:
Code:
SUB fspInitialize (n as uByte, a as uByte, b as uByte, c as uByte, d as uByte) 'Initialize Sprite: n (sprite number 0-3);a,b,c,d (UDG number 0-20,99 means the sprite won't be printed)
PRINT AT 0,0;"Initialize" : PAUSE 1: PAUSE 0
fspData() : REM call the data sub to make sure it isn't optimized out of the compile. That call just returns.
...
Code:
SUB fspDisable (n as UByte)
IF n>3 then return : END IF
POKE @fspDataStart+48*n,99
end SUB
Code:
SUB fspData()
fspDataStart:
RETURN : REM if called we should return immediately. This sub is for data and ASM only.
REM This routine contains Fourspriter data and code that is called by other routines. In effect, it's a dummy subroutine.
REM It is called by fspInitialize in order to ensure it is included in the build.
...
When you call fspDisable(0) you're effectively *destroying* the RETURN sentence of fspData(), because you're doing
POKE @fspDataStart, 99 (which is @RETURN address). Rewriting fspData this way, fixes the bug:
Code:
SUB fspData()
RETURN : REM if called we should return immediately. This sub is for data and ASM only.
fspDataStart: REM this label *AFTER* return to avoid being POKEd
REM This routine contains Fourspriter data and code that is called by other routines. In effect, it's a dummy subroutine.
REM It is called by fspInitialize in order to ensure it is included in the build.
...