11-02-2014, 01:47 PM
ZX BASIC has some weird bug involving OVER 1. Unfortunately I was unable to isolate this problem to produce a short example, so I will have to provide my full source code...
The ZEN source code is available here:
<!-- m --><a class="postlink" href="https://www.dropbox.com/sh/bgtoq6tdwropzzr/AAAknv_0PeJGhn36dLJZfGASa">https://www.dropbox.com/sh/bgtoq6tdwrop ... 6dLJZfGASa</a><!-- m -->
Right at the beginning, you will notice it sets ATTR_P to INK 0:
Afterwards it never sets a different INK, except for a single PRINT statement at the end of this sub-routine:
An obvious optimization would be setting a temporary INK inside this PRINT statement, instead of using a separate INK statement before, and another INK 0 immediately afterwards. Right? Unfortunately that won't work! Try it yourself. Replace these lines:
with this:
If you recompile ZEN with this change, parts of the board will be disappearing on screen. If you analyze the screen when it happens, you will notice the INK colors are correct on screen, but the pixels are missing. Therefore this PRINT statement is apparently using OVER 1 even in cases where OVER 1 wasn't set.
This bug is not relevant for me anymore since I have already released this game anyway, but it demonstrates ZX BASIC has some bug involving OVER 1 that may affect other developers in the future.
The ZEN source code is available here:
<!-- m --><a class="postlink" href="https://www.dropbox.com/sh/bgtoq6tdwropzzr/AAAknv_0PeJGhn36dLJZfGASa">https://www.dropbox.com/sh/bgtoq6tdwrop ... 6dLJZfGASa</a><!-- m -->
Right at the beginning, you will notice it sets ATTR_P to INK 0:
Code:
INK 0: PAPER 0: FLASH 0: BRIGHT 0: CLS
Afterwards it never sets a different INK, except for a single PRINT statement at the end of this sub-routine:
Code:
sub drawTile(row AS UBYTE, col AS UBYTE, color AS UBYTE)
DIM tile AS UBYTE
DIM ch AS UBYTE
LET tile = PEEK BOARD(row, col)
IF tile = 0 THEN
IF row=0 AND col=width THEN
OVER 1
ELSEIF color=2 THEN
LET tile = 16
END IF
END IF
LET ch = (tile<<2)+32
POKE UINTEGER 23606, @zenchr-256
INK color
PRINT AT row0+(row<<1), col0+(col<<1); CHR$(ch);CHR$(ch+1);AT row0+(row<<1)+1, col0+(col<<1);CHR$(ch+2);CHR$(ch+3);:
INK 0
OVER 0
end sub
An obvious optimization would be setting a temporary INK inside this PRINT statement, instead of using a separate INK statement before, and another INK 0 immediately afterwards. Right? Unfortunately that won't work! Try it yourself. Replace these lines:
Code:
INK color
PRINT AT row0+(row<<1), col0+(col<<1); CHR$(ch);CHR$(ch+1);AT row0+(row<<1)+1, col0+(col<<1);CHR$(ch+2);CHR$(ch+3);:
INK 0
OVER 0
with this:
Code:
PRINT INK color; AT row0+(row<<1), col0+(col<<1); CHR$(ch);CHR$(ch+1);AT row0+(row<<1)+1, col0+(col<<1);CHR$(ch+2);CHR$(ch+3);:
OVER 0
If you recompile ZEN with this change, parts of the board will be disappearing on screen. If you analyze the screen when it happens, you will notice the INK colors are correct on screen, but the pixels are missing. Therefore this PRINT statement is apparently using OVER 1 even in cases where OVER 1 wasn't set.
This bug is not relevant for me anymore since I have already released this game anyway, but it demonstrates ZX BASIC has some bug involving OVER 1 that may affect other developers in the future.