Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Stack Bug in ZXB 1.2.5-r1489 ?
#2
In this case, it's a bug in your program: in fspInitialize you call fspData():
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.
    ...
And later call fspDisable() with n = 0:
Code:
SUB fspDisable (n as UByte)
    IF n>3 then return : END IF
    POKE @fspDataStart+48*n,99
    end SUB
Look carefully at the above code and now look at fsbData definition:
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.
    ...
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)