Hey, No Carrier, you should really listen to lynxsolaris. He got started in NES development not long ago and he is progressing rather nicely, so he might have some interesting tips to pass along to you. I've been helping him out a bit with the basics of setting up a game and he's doing pretty well.
About Nbasic, you're right, just drop it. When you know 6502 assembly you're in control of everything, you gotta have that or you'll won't get far.
Don't shoot me yet, but if you don't know 6502 ASM yet, you should
really play with it a bit, away from the NES for a while. You can't control a machine if don't speak it's language. It's like if you have a fully qualified maid at home but you don't know how to give her the simple command "dust the furniture". Grab a copy of
Michal Kowalski's 6502 simulator and analyse how the flags work, do some simple additions and subtractions, try a few conditional branches and stuff. You can run the code command by command and watch how they affect the flags, the memory and the stack, wich really helps in understanding what each command actually does, something you can't learn just from reading. You just can't.
I say that because that's how I started. I read thousands of 6502 docs and never got to understand the stack, flags and branches (things not present in higher level languages I was used to) until I played with the simulator. Then, before moving to the NES, I developed a series of small routines in 6502 ASM so that I could think just as the processor works, and then code would flow easily from my head, wich it does now. I made multiplication and division routines and things like that. I can't tell how valuable that was for me.
I really do not think it is healthy that you just get access to ready-made code that draws to the background and has a sprite move around so that you adapt it to your needs without actually knowing what's going on exactly, 'cause that only produces "nesticle code", wich is what you're already getting with Nbasic.
I could give you a list of things that would be involved in getting what you want working, explaining why each step is necessary. Then you can try to understand it, in order, and get back to me/us when you have doubts on a specific step.
1. The fisrt thing to do is turn rendering off (bit 3 and bit 4 of $2001 set to 0) so that you can work with the PPU freely whithout worring about writing to it at the correct time. When rendering is off, you can write to it at ANY time.
2. Then you need to wait 2 or so VBlanks to go by, because the PPU needs some time before it is ready to be used.
3. Now you can just draw all the tiles you want to the screen. You'll want to start with name table 0, wich is at PPU address $2000 (not the register, this is the PPU addressing space). You write the address you want to write to (in this case $2000) to register $2006 one byte at a time (first $20 and then $00). Then you write the codes of the tiles you want in the screen to register $2007, one tile at a time, until the whole screen is filled with tiles.
4. After the BG is ready, you have to set the initial position of your sprite. It is recommended that you don't use registers $2003/$2004 to handle sprites, but reserve a page (256 butes) in RAM to write your sprite definitions and move them to OAM by a DMA transfer at a later time. So, clear this whole page you choose to use with the value $FF (or any othe value that will keep the sprites you're not using off the screen), but set the first sprite (or any othe you fell like) with the information needed to display it in the middle of the screen, for example. Do the DMA transfer to put your sprite(s) in place (write the number of the page you used for sprite definitions to register $4014). You'll also probably want to write your palette now.
5. Now we're almost set to turn our screen on, but you'll won't want to do it without knowing it is the correct time to do so. If you just turn it on without any worries, you may end up doing so when the light cannon of the TV is in the middle of the screen, wich will result in a partially displayed screen, and, although it happens really really fast, it's still a glitch. So you wait for VBlank.
6. Now, we're inside VBlank, and you should do the last few arrangements so that your screen is displayed properly. Set $2000 and $2001 accordingly to what your intention are (indicate what side of the patterna table you're using for sprites and BG, set the name table to display to the name table you drew the BG to, that kind of thing). Rendering can be turned on already too, it's safe to do it inside the VBlank. You'll want to turn NMI's on here to, as you'll be rading the joypad every frame and updating the sprite's position. You'll also need to set the scroll values to 0 (write $00 to 2005 twice), to make sure the screen will be static at the correct position.
7. Since all the set up is over, and you enambled NMI's, all the rest will be responsability of the NMI routine. Your main code can just enter into an infinite loop now.
8. Now onto the NMI, wich will take care of all the rest. The NMI starts when each VBlank does. So all the writing to the PPu has to be handled first. All the writing you'll be doing is update the sprite's position, so you can just do a sprite DMA as the first thing in the NMI.
9. The next thing to do in the NMI (well, all the rest is NMI so I'll just stop saying it ok?) after all the PPU writing is finished is to set the scroll register back to place ($00 twice). This has to be done every frame to make sure your screen will never "jump", and will always stay pretty and still.
10. Onto the "game" logic now. You have to read the joypad now. And react to the 4 different directions that can be pressed. If the player pressed UP, decrement the Y coordinate of your sprite (wich is in that page you chose before, remember?). If the player pressed DOWN you'll increment Y. If he pressed LEFT you'll decrement the X position and if he pressed RIGHT you'll increment X. Of course the sprite will wrap from the edges of the screen to the opposite edge, but that's ok for a simple demo. Now you've done all the logic, just exit the NMI (RTI command).
That's about it. Since you changed the coordinates of the sprite it will be drawn at the new position in the next NMI. I may have left some details off (although that was a huge ass post!), I'm not perfect, but we'll check that along the way, ok?
Good luck.