nesdev.org

Alrighty... I'd like to get started in the world of NES programming. I've done x86 assembly (yeah, I know it's different), and want to give this a go to see if I can at least do something that would run on Nintendulator.

I'd like to make a basic program that would have a few simple sprites, one that could recognize controller input and do some changes, and possibly display text. Sound and such I'd look into later.

One person recommended CA65. I don't know if any assembler is really considered superior.

So, what should I do and where to start?

I like Loopy's ASM6 as an assembler. To properly use CA65 you have to set it up, which is something I'd always rather not do.

I assume you're familiar with simple programming concepts, so that's not a problem. What you want to do is get a graphics editor (I personally like YY-Chr), and you do want an assembler that's commonly used (ASM6, CA65, or WLA-DX) so people can help you more easily when you have a problem. I use WLA-DX, but I hate trying to set up new things. I usually just use the same setup for every new project.

You'll want to read some of the technical documents, such as Yoshi's NEStech document, and you'll want to learn the 6502. There are plenty of places to learn 6502. It's fairly simple, there aren't that many instructions.

A default NES game without any mappers or anything added on to it is 40k: 8k of graphical data, and 32k of program data. The default setting is known as NROM. So if you're just making simple sprite data, you'll want to set up everything to make an NROM demo.

So yeah, if you read NEStech, and MAYBE GBAGuy's tutorials, you'll be at a good start.

I might sound like a scratched up record here, but learn 6502 ASM & just completely skip learning anything about it's Binary-Coded Decimal mode. Other than the fact that it's been stripped from the NES/Famicom's CPU, to my knowledge very few people use it aside for scorekeeping.

& remember, when you start developing, if you're not using the IRQ interrupt for anything, remember to set it to a RTI instruction. I don't know HOW long that mistake crippled me!

Well, from my reading thus far, I've figured out that # means the value of the number and not a memory location. $ in front means a hex number, % means binary, and no prefix means decimal. I also apparently set up banks for graphics and code I guess... It's a start for now.

I found a bunch of the commands and made up a Notepad++ styler for them, so I got colorful 6502! I'm sure I don't have all though.

The guides I've been looking at state nesasm as the assembler, although looking at the forums, it seems to be unacceptable to use that.

Some of the commands look specific to nesasm, and not to other assemblers... like:
.inesprg 1
.inesmap 0
.... etc.

Anyway, I'll keep looking things up. It'll be great when I can compile something with no errors.

You can start off with nesasm if you want, while you wait for somebody to set up you the CA65 config files.

I got something to compile with nesasm. A simple sprite that moves around. It's a start!

You can learn a lot from a simple program like that. You seem to catch on quickly. At least much more than I did. But I didn't have any programming experience when I started.

Well, I've been fiddling some more.

I've gotten the controller mappings into a subroutine now and it can return values for the various buttons.

One thing that's really weird is that the sprite moves down and right faster than it moves up and left, even though I'm just changing each value by 1 pixel at a time... I also like how going off screen to the right brings it back in on the left!

I'm trying to write some code to have it so that you need to release a button before it can function again.

I'd also like to get into background graphics, though that's a little fuzzy.

Your sprite shouldn't be going up/down at a different rate. There may be something wrong with the way you are checking things...

Doing what you said about the controller is quite simple. You just need to keep track of the button status somewhere in RAM.

I'm thinking it has something to do with the Vblank checking. I have read that I should (need to???) check for 2 Vblanks and I wasn't sure if the demo code was any good.

I'm not sure if that could be it or what. Also, I tried adding some values to the palette to change colors and when I add 1, it adds 2 instead...

Because carry is set?

the vblank checked twice thing should only be used in your init code, before anything else. This gives time for caps to fill, etc if I remember correctly.

Remember to use CLC before ADC and SEC before SBC if you want them to behave like ADD/SUB.

Ok. I've done well so far. I've gotten sprites to move, palettes to be modified, though I've hit a jam.

I want to load in the BG data. Now, I can get some of it, but I need an index that'll allow me to go to $ffff, but that's obviously not possible.
That's what I'm doing. Someone said to use indirect addressing??? I am bad with pointers.

I do have another question: If I ever want to modify the BG in-game, do I need to do another full write to $2007?