Partial success mixing ROM & RAM in sprite

[+Gemintronic]

So, now that superchip variables are working again I tried hacking a RAM sprite demo to use both ROM and RAM. The original example used an 8x8 sprite. It moved around some pixels at the bottom of the sprite to demonstrate RAM usage. I changed the height to 16 and added the 16 pixel tall sprite data.

 

Well, partial success there. It does still move the bottom pixels around but the top 8 pixels are complete garbage. It almost looks like Stella is spoofing uninitialized RAM from first power on.

 

 include div_mul.asm
set romsize 8kSC
const p0_lo = <r000
const p0_hi = >r000

player0pointerlo = p0_lo
player0pointerhi = p0_hi
player0height = 16
player0x = 76
player0y = 44
w000 = p0[0]
w001 = p0[1]
w002 = p0[2]
w003 = p0[3]
w004 = p0[4]
w005 = p0[5]
w006 = p0[6]
w007 = p0[7]
w008 = p0[8]

loop
temp4 = r000 * 128
w000 = r000 / 2 + temp4
temp4 = r001 * 128
w001 = r001 / 2 + temp4
temp4 = r002 * 128
w002 = r002 / 2 + temp4
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
COLUP0 = $4C
drawscreen
goto loop
data p0
%11100000
%01100011
%01110011
%00111110
%00111100
%11011100
%10111101
%11111111
%01111110
%00100100
%10100101
%11011011
%10100101
%11011011
%01111110
%01100110
end

Edited September 30, 2010 by theloon

[SeaGtGruff]

Unfortunately, you can't mix ROM and RAM data in a player sprite in bB's kernel, because the entire player will be read from either ROM or RAM depending on which one the player's pointers are pointing to.

 

Actually, you *might* be able to do it if you position your player data carefully. You'd have to put the RAM portion at the very top of Superchip RAM, and put the ROM portion at the very bottom of the ROM area:

 

$F0F8 -- line 16 of the player (in RAM)

$F0F9 -- line 15 of the player (in RAM)

$F0FA -- line 14 of the player (in RAM)

$F0FB -- line 13 of the player (in RAM)

$F0FC -- line 12 of the player (in RAM)

$F0FD -- line 11 of the player (in RAM)

$F0FE -- line 10 of the player (in RAM)

$F0FF -- line 9 of the player (in RAM)

$F100 -- line 8 of the player (in ROM)

$F101 -- line 7 of the player (in ROM)

$F102 -- line 6 of the player (in ROM)

$F103 -- line 5 of the player (in ROM)

$F104 -- line 4 of the player (in ROM)

$F105 -- line 3 of the player (in ROM)

$F106 -- line 2 of the player (in ROM)

$F107 -- line 1 of the player (in ROM)

 

But then the player's data would cross a page boundary, which could be a problem.

 

The easiest solution is to copy *all* of the ROM data into RAM, and display the player from RAM so you can modify the portion that you want, but leave the "fixed" portion alone. Otherwise the kernel displays the player from RAM (where you've set the pointers to), but the portion of RAM that you haven't set yet will be garbage.

 

By the way, I had trouble compiling your code as-is, because of the include div_mul.asm line (not sure why), so I changed the code to eliminate the need for div_mul.asm by replacing 128 with 4*4*8.

 

Michael

 

 

 

[SeaGtGruff]

Here's the "fixed" version:

 

set romsize 8kSC 
const p0_lo = <r000 
const p0_hi = >r000 

player0pointerlo = p0_lo 
player0pointerhi = p0_hi 
player0height = 16 
player0x = 76 
player0y = 44 
w000 = p0[0] 
w001 = p0[1] 
w002 = p0[2] 
w003 = p0[3] 
w004 = p0[4] 
w005 = p0[5] 
w006 = p0[6] 
w007 = p0[7] 
w008 = p0[8] 
w009 = p0[9] 
w010 = p0[10] 
w011 = p0[11] 
w012 = p0[12] 
w013 = p0[13] 
w014 = p0[14] 
w015 = p0[15] 

loop 
temp4 = r000 * 4 * 4 * 8 
w000 = r000 / 2 + temp4 
temp4 = r001 * 4 * 4 * 8 
w001 = r001 / 2 + temp4 
temp4 = r002 * 4 * 4 * 8 
w002 = r002 / 2 + temp4 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
COLUP0 = $4C 
drawscreen 
goto loop 
data p0 
%11100000 
%01100011 
%01110011 
111110 
111100 
%11011100 
%10111101 
%11111111 
%01111110 
100100 
%10100101 
%11011011 
%10100101 
%11011011 
%01111110 
%01100110 
end

Michael

 

 

 

[+stephena]

So, now that superchip variables are working again I tried hacking a RAM sprite demo to use both ROM and RAM. The original example used an 8x8 sprite. It moved around some pixels at the bottom of the sprite to demonstrate RAM usage. I changed the height to 16 and added the 16 pixel tall sprite data.

 

Well, partial success there. It does still move the bottom pixels around but the top 8 pixels are complete garbage. It almost looks like Stella is spoofing uninitialized RAM from first power on.

Not sure what you mean by 'spoofing', but if you mean it's being randomized, then yes, you are correct. If you want to test with RAM being zeroed instead of being randomized, launch Stella from the commandline and include the '-ramrandom 0' argument (and set it back to '1' for randomization again).

[+Gemintronic]

Wow! Thanks for taking my little experiment seriously. ROM + RAM sprites would be awesome for player customization. SeaGtGruff did the hard part. I've got to figure out why.. oh. Ha! player0height should be 15. NEVERMIND.

 

Thanks and Hi! to stephena as well. I really appreciate Stella and how incredibly up-to-date it is. Along with Batari BASIC it's enabled me to really enjoy programming again. Didn't mean anything by the word spoofing. It's the best word I could come up with sick and sleepy. I realise randomizing RAM at startup is meant to be an accurate representation of Atari 2600 behavior.

Edited September 30, 2010 by theloon

[+Random Terrain]

It's the best word I could come up with sick and sleepy.

You're sick and sleepy and I seem to have male PMS.

 

I'd like to use this for creating multicolored enemies that can look different every time you play. You could have something like 10 or more pieces for each section. Wow, if you wanted to have an animated character, that would eat up some ROM.