nesdev.org

Okay, so like this?: ; Inits everything. .proc reset ; Clears the flags. clc sei cld clv ; Sets the stack pointer. ldx #$FF txs ; Waits for the PPU to warm up. : lda $2002 bpl :- ; Inits the PPU. ldx #%10000000 stx PPU_CONTROL ldx #%00011000 stx PPU_MASK ; Sets the stack pointer again. ldx #$FF jmp ...

Okay, so I've meed those changes, and have this now: ; Inits everything. .proc reset ; Clears the flags. clc sei cld clv ; Sets the stack pointer. ldx #$FF txs ; Waits for the PPU to warm up. : lda $2002 bpl :- ; Inits the PPU. inx stx PPU_CONTROL stx PPU_MASK dex jmp main .endproc However, my code ...

I think you're confusing things, but it's normal. NMIs are very simmilar to IRQs, but on the NES it is specifically wired to the PPU and, when activated, fires when VBLank begins, basically. Code at the NMI vector is then executed, and then you can update the tiles, sprites and other stuff (or just...

You're supposed to use SEI on start up, not CLI. CLI allows interrupts to happen, and you don't want that during initialization. After initializing everything, you should only enable interrupts (CLI) if you actually use them. What do you mean "if you actually use them"? I thought I just r...

Disclaimer: I know nothing about music or music theory.

What does the music in NES RPGs sound like? Are they eastern, western, or have elements of both? How are composers like Nobou Uematsu and Koichi Sugiyama organized/treated?

What have you written to PPUCTRL ($2000)? You could try putting a breakpoint on the NMI handler to make sure it gets called. I'm not writing anything there. =/ Your NMI couting code is useless if you are not initializing $2000. Initializing the PPU by writing to $2000 and $2001 at least once is a m...

There are several. My build environment uses a lot of Python programs, so I wrote my own. It's in the Concentration Room source code archive. Okay, thanks. What have you written to PPUCTRL ($2000)? You could try putting a breakpoint on the NMI handler to make sure it gets called. I'm not writing an...

I'm pretty sure that passing parameters through the stack is not very common on the 6502, because having to work around the return address is not very efficient. But if you feel comfortable using the stack that way, there's no reason for you not to. I'm not using *the* stack (the one at $100 to $1F...

This .proc might confuse you. But it's just a way to hide the labels defined inside the .proc from view outside the .proc, so that multiple subroutines can share the same names for internal labels. For example, the symbol inside wait4vbl ends up called wait4vbl::loop, and other subroutines won't be...

After the reset code finishes and the background is copied into the nametables, you start the game loop. Okay. Also, a question: So, if I permanently disable interrupts by setting the flag, I won't be able to update the screen, right? How would you predict how many bytes to scroll up? 6502 bytecode...

Wherever a wait for VBlank is necessary. The typical structure of a game loop is: 1. update the game world using controller input and A.I.; 2. wait for VBlank; 3. update VRAM using data computed last frame; 4. update the audio; 5. go back to 1; How do I know when "wherever" is (for the vb...

The loop basically waits for the variable to change. This works well in most cases, it's only bad if you have raster effects near the top of the screen (like status bars) and you can't guarantee that frame calculations will never spill into the next frame. But where should this loop be located? in ...

Having IRQ pointing at an RTI will generally work. But in the NMI handler, you'll usually want to set a variable to notify the main program that a vertical blank has begun. So that I don't have to push and pull A, I just have it do inc nmis. What and where is "nmis"? Does it simply count ...

Where do $FFFA-$FFFB and $FFFE-$FFFF point? Are you pushing or pulling anything in your NMI and IRQ handlers? What values end up in $FFFA through $FFFF? There should be three addresses (in the typical reverse byte order of the 6502); do they point anywhere familiar? The vectors point to an RTI, ini...

I see your LOWER_PROG_ROM and UPPER_PROG_ROM sum to 32 KiB. Are you making sure to specify two 16k pages in the iNES header? Yes. And are you making sure to replicate the vectors and the beginning of the init code in all 16k banks (the Barbie stub) so that no matter how the MMC1's registers are set...