Can someone explain palettes more in-depth to me?

Hey, Rai here. Recently, I've been trying to code the asm to display a sprite on the screen.

I've mostly been going off the walker.asm example in the snes starter kit.

Now, I've gotten the sprite to display, but unless I put the palette at 100 bytes after the DMA address; the palette will be weird.

In this case, the palette is at 81A000 and that's the address I DMA to CGRAM. But unless I put the palette at 81A100, it won't send the correct palette.

This is weird because I did store 0 to the color register, so I thought that meant that the game should use the first palette?

You can download the asm file for the sprite routine here:
http://www.mediafire.com/download.php?sb9bmmpnozdl1jc

Hey, Rai,

great, welcome to the coding club! I'm still a newbie too. But I just took a look at your code nonetheless.


Beware of hex numbers -- $100 = 256 bytes!


Then there's this small, mysterious loop:

Remember that writing to $2122 auto-increments the address! So it's likely possible that by simply removing that Loopingtwo thingy (which is probably useless anyway), you'll solve your problem.

Hmm... well after doing some research, I think this may just be something to do with CGRAM.

I've looked at another game and it only uses the first 256 bytes of CGRAM for backgrounds. It uses the latter 256 bytes for sprites. But is this is true or just a coindence?

Infact yeah, I think that's it. It's because color 128 starts at $100 in cgram and sprites can only use the latter 128 colors.

I only found one document clarifying this though...

Well, nocash's in-depth fullsnes documentation gives you an overview of palette indices. Looks like your assumption is right (and I was wrong).

Thanks for that.

Unfortunately, I'm beginning to realize why there's not much SNES homebrew out there. There's a lack of asm examples on how to do things and the examples out there, make things too confusing.

Even with all the docs, you still mostly have to figure out everything yourself.

For instance, I've been trying to understand how simply move a sprite up and searching on google hasn't brung up anything good. I feel as though the only way I can figure it out is to figure out how a commercial snes game does it.

Yeah, but that's part of the fun.

Perhaps, but sometimes the only way to figure out clearly how to do a simple thing, is going into a commercial game and figuring it out.

Even doing something as simple reading joypad input is confusing with the current documents out there.

I might make my own SNES homebrew tutorial one day with ASM examples that are clear and have detailed comments.

Heck, I'm an experienced ASM hacker and still have trouble figuring out simple things even with all the docs out there. Imagine how hard it would be for a completely newbie.

Or maybe I'm just looking in the wrong places.

There's another approach: Make changes in an example like walker.asm, recompile it, and see what happens. This helped me a lot in the beginning anyway.


Yes, please do!


True. And still, I think if you really want to do it, and learn to make good use of the docs that are out there, and study a lot of existing sourcecode -- then I think that even against all odds, you can get really far.

Well do you know any good examples of using the joypad?

I've looked and looked and looked and none of the examples have worked.

Have you tried programming the NES first? Following an NES tutorial just might twist your brain into the right state to become able to generalize the knowledge to the Super NES.

Is that supposed to be your reset routine (routine that runs at bootup), or your nmi routine (routine that runs every frame)? This is how roughly your code should look like:




BTW, "org" is not really an ASM instruction. I don't know what assembler your using, but on xkas, the "org" command tells xkas what address to write code to.

It's nothing to do with the SNES, but more a lack of clear ASM samples on how to do anything.

I mean I've made several ASM hacks to SNES games, such as adding compression to text and even adding advance hacks like VWF's.

It's not that I don't understand ASM, it's not understanding one part of a particular code. Myself, I've done everything the examples have said, initialized all the joypad registers and the joypad register still loads zero.

But I certainly will write a homebrew document. If only so novice ASM guys can understand how to do simple things.

I have been trying to wrap my head around SNES programming lately, have you had a look at these pages?
http://wiki.superfamicom.org/snes/show/HomePage
http://en.wikibooks.org/wiki/Super_NES_Programming

Also, this example file is nice. http://filebin.ca/T4jRsOzndk0

Here is the code I use.

My VGM player for the SNES uses a lot of stuff that a typical game would include: joypad input, audio playback, hdma effects, sprites, etc. The full (assembly) source code is available here.

To find the subroutine responsible for updating the OAM (sprites), search for UpdateOAM in t700c.asm.

On the subject of more example codes, which is better?

A simple routine that writes a sprite to OAM, but requires additional processing.
A more complex routine that writes a sprite to OAM, but requires no additional processing.