cc65-sprite question

[alytle]

Hey, do you mind if we use issues to ask questions about the demos, or is there a better place to do so?

I'm trying to understand this line. Where does 0x010000 come from?

// Address bits 16:13 (starting at 0x010000) and 8 BPP mode
VERA.data0 = (1 << 7) | (0x010000 >> 13);

From:

x16-demo/cc65-sprite/demo.c

Line 90 in 02e1574

// Address bits 16:13 (starting at 0x010000) and 8 BPP mode

[greg-king5]

I'm trying to understand this line. Where does 0x010000 come from?

// Address bits 16:13 (starting at 0x010000) and 8 BPP mode
VERA.data0 = (1 << 7) | (0x010000 >> 13);

From:

x16-demo/cc65-sprite/demo.c

Line 90 in 02e1574

// Address bits 16:13 (starting at 0x010000) and 8 BPP mode

It comes from this:

x16-demo/cc65-sprite/demo.c

Lines 111 to 116 in e7403aa

	// Copy the balloon sprite data into the video RAM.
	// Set the address to increment with each access.
	vpoke(0x11, 0x0000, balloon[0]);
	for (i = 0; ++i < 64*64; )
	VERA.data0 = balloon[i];

I should fix vpoke() -- separating the address into two arguments is misleading -- it isn't banked. And, I should use a macro constant name for that address.

[alytle]

Ahh, ok I was confused about that banking. So it could be bank 0 address 0?

…

On Thu., Oct. 17, 2019, 5:45 p.m. greg-king5, ***@***.***> wrote: I'm trying to understand this line. Where does 0x010000 come from? // Address bits 16:13 (starting at 0x010000) and 8 BPP mode VERA.data0 = (1 << 7) | (0x010000 >> 13); From: https://github.com/commanderx16/x16-demo/blob/02e157496a6dbed9cbb049415f3728810e6ca236/cc65-sprite/demo.c#L90 It comes from this: https://github.com/commanderx16/x16-demo/blob/e7403aa109e9593afbe55b4e8baa87eceb880bc6/cc65-sprite/demo.c#L111-L116 I should fix vpoke() -- separating the address into two arguments is misleading -- it isn't banked. And, I should use a macro constant name for that address. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#66?email_source=notifications&email_token=ABCECEF23EIGIVNLIBP4LNLQPDMHXA5CNFSM4JB64DE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBRT3HA#issuecomment-543374748>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABCECEGWGW3DE55JDVRLHEDQPDMHXANCNFSM4JB64DEQ> .

[alytle]

I guess here's the crux of what I'm trying to understand. The (Unofficial) VRAM documentation shows:

Bank | Start | End | Purpose
-- | -- | -- | --
$00 | $0000 | $FFFF | Video RAM
$01 | $0000 | $FFFF | Video RAM
 -  |   -   |   -   | Everything from $020000 to $0EFFFF is unused.
$0F | $0000 | $001F | Display composer registers
$0F | $1000 | $11FF | Palette
$0F | $2000 | $200F | Layer 1 registers
$0F | $3000 | $300F | Layer 2 registers
$0F | $4000 | $400F | Sprite control registers
$0F | $5000 | $5FFF | Sprite graphics data
$0F | $7000 | $7FFF | SPI data

But what they describe as "Sprite graphics data" is actually more like "Sprite configuration data", which seems to include a memory address to the actual "bitmap" information. Where is this pixel data supposed to live? At any arbitrary point in banks 01 & 02, between 0000 and FFFF?

[mist64]

Correct. Clarification pull requests to the docs repo welcome. :-)

[alytle]

Happy to contribute, once I feel like I've got a better handle on what's actually missing versus what I just don't understand.

When I experiment loading bitmap data into 0x0000, it seems like I'm drawing directly to VRAM (though my sprite still works). Is there a "safe" area of VRAM I should be using which doesn't try to draw character data?

[greg-king5]

As much as I can tell:

• $20000 .. $EFFFF seems to have no hardware -- it's a "black hole"?
• In release 33:
  • $1E800 .. $1FFFF is used by the fonts.
• In the future release 34:
  • $0F800 .. $0FFFF is used by the PetSCII fonts.
  • $0F800 .. $0FBFF is used by the "ISO" font.
• $00000 .. $03B9F is used by the 80 x 60 screen.
• $00000 .. $01D4F is used by the 40 x 30 screen.