nesdev.com

Most of the time, bad opcode means either A. you forgot the RTS at the end of a subroutine, B. you messed up a bankswitch, or C. you did RTS on a messed-up stack.

tepples, thanks! I guess it was kind of A. I put your code in the middle of a subroutine. So it had the first part of the first subroutine missing an RTS at the end.... like [/quote]

This is what I have so far. My brain doesn't work right now, but I want to make progress. My code always draws the sprite with just one tile; how do i increase the size? I used but that didnt help. And also, is that code possible... like for me, it is hard to understand why "sta sprite+aVariable" would work...? Found my assembly textbook from college and read the entire first chapter and going to finish the second chapter by today. It is really fun reading it!

Nope, that code isn't possible. You have to store a sprite next to/below in the next sprite address.

Thank you 3gengames!

I think I've found the problem... put tepples' code inside the code that runs before the .

Inside the NES 101 Tutorial the only code that runs after cli is the endless loop transfering control to the vblank interrupt, i think. Where do you think tepples' code should go? I'm asking beccause my skill with rearanging others' code is very poor; guess i could keep try ing though.

The code tepples posted is a subroutine. You can place it wherever you want (of course not in the middle of some other code). Was this what you meant, or do you mean where to place the actual calls (jsr) to the routine?

Yes, thank you; I agree.

Well, i think i ment both... My first problem was that I placed it in the middle of some other code. I've moved the


that part underneath the background and attribute data code at the end... that was obvious to me; after i did it. but, it's ok to make a mistake and then learn from that. : )

After many ideas and hours of reading I have decided to place the jsr in my vblank code because vblank is the period where you write to the sprite memory, right?

Thank you Jaffe for helping me!

This code has not worked for me, yet... now, it draws the first sprite in the correct spot on the screen; but only the first sprite. Back to my assembly book.
3
edit: forgot to post my code

I have a bit of a hard time getting an overview of your code. Could you post it in its entirety?

The subroutine should not be called during vblank time, at least not before all PPU updates are done. You'll want the subroutine to store sprite data in a page of RAM, and let the contents of this page be copied into OAM by a DMA transfer during vblank (from reading this thread it seems you did this before?) That way you can use all of the non-vblank time to do complex calculations etc. to compute what objects are to be shown in the next frame, where they should be placed, etc. Then when vblank comes, you'll have the sprite data ready to be copied into OAM.

I assume your game has some kind of a main loop that just runs over and over? This is usually where you'd like to place your call to the routine, but that requires that you have some way of controlling how often the loop runs. You could also place it at the end of your vblank code, after you're sure that all code accessing the PPU has run. If you just want to show one object now as a test, you can just as well call it once before your code enters the main infinite loop.

It's not really my code yet; it is really the code of Michael Martin in the NES 101 Tutorial and the code of tepples in his post on page 4, i think, of this thread.




Yes, I remember doing that from before in this thread. Right now, my file for vblank looks like:



So the first thing in vblank should be the copying of page 2 to OAM? And then is it right to do all the updating of page 2 after vblank ends? At vblank we are suspossed to make our changes known to OAM first and writes to page 2 are for between Vblank times. That's what im learning right now, thank you.

What is VRAM?

Ok, thanks! I changed it, but have the poblem again... it's only drawing the first of the 8 sprite object/meta-sprite. It's in the right place though and it's the right sprite.

Yes, you can update the CPU's copy of OAM outside of vblank. In fact, you're supposed to.

VRAM is any RAM mapped into PPU $0000-$2FFF. It includes CIRAM, the memory inside the NES used for nametables, and CHR RAM, the memory inside the cartridge used for pattern tables. Some cartridges have CHR ROM instead of CHR RAM; for these, the only VRAM is CIRAM.

Are you using the exact code you pasted here? You know it's incomplete, right? The sprite drawing routine is not copying all the bytes it's supposed to from the meta-sprite definitions, and it's not adding the coordinates to the object's coordinates either. That routine was provided as an example, not as something you can copy & paste.

I advise you start writing your own code, or at least read all the code you use very carefully so that you know exactly what it's doing. Making Frankenstein programs (copying blocks of code from different sources) is a terrible way to learn, because you have no idea of what is actually going on in the program and are only hoping that it will somehow work.

Thank you. Would testing the input be ok for during vblank? No, testing the input hasn't anything to do with VRAM... right?

Thanks!

Yes ok, you are right on all points. Thank you for your help. God really helped me with it and so it kind of works now! The code... it's able to print out the entire meta-sprite now using tepples' code and my code! Now i'm trying to figure out how to move it with the control pad... and I think maybe calling

after each input-check would work... but how should I try this?
Here's code that appplies to this question.


Would jsr draw_sprite be ok to include inside of the loop: jmp loop?
Is that the only place I can put it? (Because the rest of the file is subroutines and then data.) I'm missing knowlege about a way to organize my code with files. I remember reading some post by tokumaru that's about organizing code with different files... will search for that tomorrow. Good night.

It depends. There are 3 common ways to organize your frame logic in NES programs in order to make sure it will run 60 times per second (as it should):

1. Put the game logic after VRAM-related operations in your NMI. The NMI routine is automatically called at the start of VBlank, and once the VRAM updates are finished, you are free to do other kinds of operations. Since the NES runs at 60fps, there are 60 VBlanks in a second, so your game logic will also run at 60 Hz. Many commercial games do this, including SMB and Final Fantasy. There are some problems with this method though, which make lag frames (these happen when the frame logic takes longer than a frame to complete) difficult to manage. SMB suffers from this when there are too many enemies on screen (apparently the status bar "jumps" and the music slows down). Most tutorials appear to use this.



2. Use the NMI just for signaling the start of VBlank, and both the frame logic and the VRAM-updating in the main thread (the "loop: jmp loop" part). This is very similar to the above, only the order of the updates is different. Here we update the frame logic first and then we wait for VBlank (by checking a flag which is modified by the NMI when VBlank starts) before performing all VRAM updates. This technique suffers from the same lag frame problems. AFAIK, no commercial games did it like this.



3. Separate your main thread from your NMI thread and run them in parallel. This is my favorite, because it allows for safe handling of lag frames. When the NMI fires, it can detect if the frame logic is complete or not, so it's able to detect lag frames and make sura that status bars, the music and other things still work even though the frame logic isn't finished. AFAIK, most commercial games use this.



So, to answer your question more directly: If you just place the sprite-drawing call in the main loop without any other modifications, that routine will be called 100's of times in a frame, because there isn't any sort of timing control in there. In your case, the simplest fix would probably be to place that call right after the controller is checked and the player's coordinates are changed. Since it appears you are building this from a tutorial, it would be better to stick to the first solution I explained in this post. Just keep in mind that there are other options, and that you might want to take a look at them once your games become more complex and need more "robust" timing.


How you organize your files doesn't make any difference in the program... Separating files and using includes is something that's supposed to help you keep track of what's where and make your code more easily maintainable, but in the end the assemble still sees all the code as if it were in a single huge file. What matters for NES programs is the order in which things are processed, which doesn't necessarily match the order in which they are written.

Don't Squaresoft games such as Final Fantasy do it this way?

I'll have to see if Nintendulator and NESICIDE can measure /NMI-to-RTI time.