Palettes from BASIC

I’m trying to write some BASIC to make a 256-colour sprite and then add a full, 256-entry palette to it. Unfortunately, depending on what I pass in R3 to OS_SpriteOp 37, I seem to either get back 64 bytes or 256 bytes of palette data (according to the value returned in R3). The PRM says the sprite palettes contain 8 bytes per palette entry, which would mean I’m only getting back 8 or 32 palette entries instead of the 16, 64, or 256 I’m expecting!

This odd behaviour seems to be confirmed by the fact that even though my FOR loop is setting all the palette entries to white, when I plot the sprite the palette entries only apply a slight tint to the pixel colours, as is the normal for a 16 or 64-entry palette, not the 256-entry palette I want.

My BASIC is pretty rusty, so what am I doing wrong here?

REM Test Plots of Sprite with Full 256 Entry Palette
REM Andy S. August 2021

ONERROR REPORT:PRINT ERL:END
MODE 28
palsize% = 256 * 8
ttabsize% = 0
size% = 24000 + palsize%
DIM sarea% size%
sarea%!0 = size%
sarea%!8 = 16
SYS "OS_SpriteOp", 256 + 9, sarea%

REM create a new 256 colour sprite with no mask
SYS "OS_SpriteOp", 256 + 15, sarea%, "test", 0, 100, 100, 28: REM Mode 28

REM add a palette to the sprite
REM We want our palette mode value to be (%1 OR (%1 << 31))
DIM palmode% 4
!palmode% = 1
palmode%?3 = 1 << 7:REM Without this bit set it seems to give 64 byte palette, 1 << 7 gives 256 byte palette.
SYS "OS_SpriteOp", 256 + 37, sarea%, "test", !palmode%

REM get a pointer to the palette
SYS "OS_SpriteOp", 256 + 37, sarea%, "test", -1 TO ,,,palsize%,palette%

IF palette% = 0 THEN PRINT "Couldn't create palette.":GET:END
PRINT "Palette size in bytes: " palsize%
entries% = palsize% / 8

REM Fill the palette with colours
FOR i% = 0 TO entries% - 1
colour% = &FFFFFF00
!(palette% + (2 * i%)) = colour%
!(palette% + (2 * i%) + 1) = colour%
NEXT i%

widettab% = 1 << 4
ttabflags% = widettab%
SYS "ColourTrans_GenerateTable", 28, palette%, -1, 0, 0, ttabflags% TO ,,,,ttabsize%

DIM ttab% ttabsize%

SYS "ColourTrans_GenerateTable", 28, palette%, -1, 0, ttab%, ttabflags%

REM Not sure why this doesn't seem to alter the visible colours.
REM Write our palette to the screen's palette
REM SYS "ColourTrans_WritePalette", -1, -1, palette%, 0, 0

REM switch output to the sprite
SYS "OS_SpriteOp", 256 + 60, sarea%, "test", 0 TO r0%, r1%, r2%, r3%
REM clear sprite to green
bgcol% = &00FF00FF
SYS "ColourTrans_SetGCOL", bgcol%, , , &80, 0
CLG
REM switch output to the screen
SYS "OS_SpriteOp", r0%, r1%, r2%, r3%

IF ttab% = 0 THEN
flags% = %10000: REM Translation table can be ignored
ELSE flags% = 0
ENDIF
IF (ttabflags% AND widettab%) THEN flags% = %100000: REM Translation table is wide

FOR xy% = 0 TO 1200 STEP 150
REM plot sprite scaled
SYS "OS_SpriteOp", 256 + 52, sarea%, "test", xy%+80, xy%+80, flags%, 0, ttab%
NEXT xy%

It’s very odd. If I change the statement assigning the palette entries to colour% = &FF0000FF
then the sprite shows up in purple instead of green, which doesn’t make a lot of sense because the palette entries are supposed to be in &BBGGRR00 format.

If I change it to colour% = &FF000000 they suddenly come out black. Stranger still, because the lowest byte of the palette entry should be ignored.

Never mind. I’ve figured most of it out. My rusty BASIC knowledge had me thinking the ‘!’ indirection operator would step the specified number of words on from the memory address but of course all the offsets actually have to be in bytes! It’s not like an int * in C.

It’s still odd that I get the value 256 back from OS_SpriteOp 37 for the palette size, because when I peek inside the sprite header the palette I made is really the 2048 bytes that I expected!

but of course all the offsets actually have to be in bytes! It’s not like an int * in C.

Yeah, I fall into that one too, but usually the other way, of addressing something far beyond the array limits because, no, it’s words not bytes! ;-)

I thought the palette size returned by OS_SpriteOP 37 was the number of entries in the palette, not the bytesize?

Yes I’m pretty sure it is returning the number of palette entries when I run it. The PRM is probably wrong.

Yeah, I fall into that one too, but usually the other way, of addressing something far beyond the array limits because, no, it’s words not bytes! ;-)

Hey at least your mistake’s more likely to go bang quicker, giving a clear signal something’s very wrong. Mine only went bang when I tried to use my erroneous technique to read the offsets of values in the sprite header and then try to actually access memory at those offsets! 8-S