Mesen Bugged Debugger??

Kasumi said:

I forget the specifics of why this is, but there's a quirk to how palettes are represented in the PPU memory. Mesen, thus, has another option in the pulldown to see the palette memory called palette RAM.

Edit: NovaTheSquirrel and Tepples set me straight on this six months ago, I found the message in discord. Apparently palettes are stored elsewhere even if they are mapped to $3F00. So you can read from the values that are ACTUALLY at PPU $3F00 (read: Not the palette), but not write there.

Here's a screenshot from those actually in the know:

I prefer FCEUX's approach development-wise, but I don't consider either approach right or wrong, really.

Click to expand...

Kasumi said:

The Palette RAM should not show up blank. What Mesen version/OS/Etc.?

That's 0.9.7 on Windows Vista. It was definitely also working during the date in those images, since those are responses to the same question. (Why doesn't Mesen show the palette at $3F00 in the PPU memory?)

If you directly place any number in $0A00 on the CPU side, you can read that same number back from $0200 and vice versa. Where is that value considered to be?

Provided my understanding of what they've said is correct, the palette isn't stored at $3F00 in PPU memory, it is simply accessed through that address. It's similar to how in UNROM or Mapper 30 different parts of the ROM can be accessed from the same address on the CPU side. $8000-$BFFF can be multiple 16KB segments of the ROM over the course of program execution. $8000-$BFFF is not necessarily "where it is", just where the NES sees it.

Similarly, $3F00 is not where the palette is, it's just where it's accessed from. The steps PinoBatch shares are how to read what's "actually" at $3F00, but you can only read. When you write, the writes get "redirected" to where the palette is, rather than the "actual" memory at $3F00 on the PPU side. And that probably sounds really weird, but lots of things on NES are like that. It's sort of like how writes to ROM get "redirected" to the mapper hardware for bank swapping.

Granted, it's weird that the palette is someplace else and the rest of the PPU memory seems not to be. This post offers an explanation on why: https://forums.nesdev.com/viewtopic.php?p=208786#p208786 (Note: Tepples = PinoBatch)

As for why the stack pointer changes the moment the NMI starts, consider that the NMI can happen while the code is doing anything.
How does the CPU know where to return to?
Suppose the carry is set. The NMI clears the carry, then returns. Couldn't that potentially break the code when the NMI does return?

So what happens is that whenever an interrupt (like the NMI, or the IRQ) interrupts, where the address the CPU is currently at (the Program Counter, or PC, two bytes) and the state of the processor status flags (one byte) are pushed onto the stack. (The stack is RAM at $0100-$01FF.)

So a byte at $01FF, a byte at $01FE, a byte at $01FD. The next byte is $01FC, where the stack pointer ends up. (The high byte, $01, is implied by any stack usage.)

When you return from the NMI with an RTI, it pulls those bytes off the stack (copying them back to the PC and Processor Status Byte) to safely return. BUT NOTE! A/X/Y are NOT put on the stack when the interrupt hits. If you don't save the current value of A, X and Y yourself at the start of the NMI, then restore them at the end of the NMI when the NMI returns there is absolutely potential for code to get broken. (Imagine a loop that can only end if X is a multiple of four, like dex dex dex dex bne. If the NMI changed X to something that was not a multiple of 4, the loop would never break)

The stack is also used on JSR and RTS. JSR pushes where to return to, RTS pulls those values to get back. That's why subroutines can be called from any location. This is also how subroutines can call other subroutines (and fundamentally why the concept of a stack exists as it does). (The below is slightly simplified for understanding, the exact details matter less for learning.)

Code:

main:
Jsr sub1;Address of main (really the address following the line of code that contains the jsr) is put onto the stack and we go to sub1
jmp main

sub1:
jsr sub2;Address of sub1 is put onto the stack "on top of" the address of main and we go to sub2
rts


sub2:
rts;The "top" two bytes are pulled off the stack. In this case, the address after the jsr sub2. The PC is set to this address, and the program resumes. Now the "top" two bytes of the stack are the address after jsr sub1.

;There's an RTS after jsr sub2. So the top two bytes are pulled off the stack again. The address after jsr sub1, which is jmp main.

You can have subroutines call subroutines up to 128 levels deep, in theory. New things are put on top. You can only pull the top things off, so to get the bottom all the top things have to be removed in order.

It's like if you had a real stack of plates. When you put a plate onto a stack, you put it on top. That's easier than putting it into the middle or the bottom. If you wanted to take one off, you'd take the top one because that's also easier.

6502's stack grows "downwards" because $01FF is the "top" and $0100 is the "bottom". But that makes it easy to use contiguous "upwards" growing RAM starting at $0100. (But if you use too much the stack might crash into it.)

Try it! Look at $0100-$01FF when the first NMI hits in your program. See it change whenever you JSR. RTS and RTI don't change the RAM, just the index (the stack pointer). Because there is an index, old values don't have to get "erased" on return. (So note that you'll only see the NMI change in particular if the NMI's address wasn't the last thing pushed there already. That said, the flags that are also pushed are likely to be different.)

Click to expand...

Kasumi said:

I think Sour (Mesen dev) is on vacation right now, but definitely report that. It's weird that only those sections don't display rather than the entire memory viewer not displaying, I'm super curious why, heh. Edit: Oh, I saw your update. That makes sense, and even more information to make the report better!

Yes, that's a good summary of the palette stuff.

I want to write NES tutorials, but not enough to actually do it. There's so much weird NES stuff. Like writes to $2006 affect some of the same things that writes to the scroll position ($2005) do, so you have to write the scroll position after all $2006 writes. The 2 frame PPU warm up wait. Sprites being drawn one pixel lower than you set. (Really! It's impossible for sprites to occupy the top pixel of the screen. Position 0 will be drawn 1 pixel below the top and you always write the position you actually want minus one.) DPCM sample playback messing with the joypad... start of frame signals getting missed if you use $2002 (Not a huge effect, but can happen), reads from $2007 generally requiring an extra throwaway read (which is the behavior that allows reading from "actual" $3F00), palette colors getting rendered to the screen if rendering is off and the address written to $2006 is in the palette range...

But once you hit them, you learn!

Click to expand...

Kasumi said:

The wiki can be a little dense, but it's primarily raw documentation. If you have questions about something NES-hardware specific you can ask here and I'll probably answer. And maybe I can edit the wiki too if you list specific issues with it, but it's a fine line to walk for the perfect amount of information.

Click to expand...

Kasumi said:

Animated tiles are an easy question to answer outside the NES Maker context.

The benefit of not writing the engine: You don't have to the write the engine!
The con of not writing the engine: You have to be REALLY careful adding things to it, and do a lot of study to make sure the additions won't break it. You also have to research how things are set up to know where to make the additions.

So animated tiles. The NES has tiles in either ROM or RAM depending on the configuration of the cartridge. Mapper 30 is always RAM, a lot of others can be either or.

Assuming you have the tiles in RAM, you update them the same way as the palette. You write the address of the tile you want to update in two writes to $2006. Then you write the data itself to $2007. You can only update for 2270 cycles after the NMI triggers, or when rendering is turned off. Just like the palette!

$0000-$1FFF is the address range for tiles. Each tile is 16 bytes. The format for those 16 bytes is on this page: https://wiki.nesdev.com/w/index.php/PPU_pattern_tables

Suppose you're using $0000-$0FFF for your background tiles. This means $0000-$000F are all of the bytes of the first tile in your background set.

Code:

;Make sure the address increment bit for $2000 is go up by 1 rather than 32
lda #$00
sta $2006
sta $2006
ldy #$0F
tileloop:
sta $2007
dey
bpl tileloop

BAM, you've made the first tile entirely blank.

Mapper 30 has 32KB of RAM for tiles, but a whole set of 512 tiles is only 8KB. So it has four full sets. The NES can still only see one set, but you can change which set is in its vision at any time. The sets are commonly called banks. Mapper 30 also lets you swap in new banks to the CPU, which gives you access to more data that isn't tiles.

To do both, you write a byte to $8000. It's really that simple! And the format for that byte is on this page: https://wiki.nesdev.com/w/index.php/UNROM_512
But I'll quote it here:

Code:

  Range,Mask:   $8000-FFFF, $8000
  
    $8000:  [MCCP PPPP]
      M = One screen Mirroring select
      C = CHR RAM bank
      P = PRG ROM bank
  
  PRG Setup:
  ---------------------------
       $8000   $A000   $C000   $E000  
      +-------------------------------+
      |     $8000     |     { -1}     |
      +---------------+---------------+

So the lowest five bits are which PRG ROM bank you want (32 possible 16KB banks = 512KB total)
The two higher than that are which of the 4 sets of tiles Mapper 30 has the NES will use to display. Confused? No worries! Example time.

Code:

lda #%00000000;For now, let's assume we want PRG bank 0 and don't care about mirroring
sta $8000;Now CHR bank 0 and PRG bank 0 are what the NES is looking at.

;Make sure the address increment bit for $2000 is go up by 1 rather than 32
lda #$00
sta $2006
sta $2006
ldy #$0F
tileloop:
sta $2007
dey
bpl tileloop
;We have just made the first tile of the first (well, 0th) bank totally blank.

;Now we put in a new set, and we can make the first tile of that bank something else.

lda #%00100000;For now, let's assume we want PRG bank 0 and don't care about mirroring
sta $8000;Now CHR bank 1 and PRG bank 0 are what the NES is looking at.

lda #$00
sta $2006
sta $2006

lda #%11111111;This will be a tile that is filled with color 3, rather than color zero
ldy #$0F
tileloop2:
sta $2007
dey
bpl tileloop2

;Even though we have written to the exact same address, something different got changed because we put something new in NES' vision.

So in bank 0, tile 0 is entirely color 0.
In bank 1, tile 0 is entirely color 3.

To make it animate, in your NMI, you'd just do:

Code:

lda currentbank
eor #%00100000;We only have two frames with the above code, so we can just eor one bit to alternate frames
sta currentbank
sta $8000

And then every frame, anywhere tile 0 is used will alternate between being color 3 and color 0 every frame.

Short, review version:
Turn rendering off (write a zero to $2001) so you can do a lot of updates through $2006/2007. Write all sprite and background tiles to all 4 CHR RAM banks. Now you have four identical tileset "frames" set up.
Then, any tile index you want to be animated, you write the 16 bytes for the different versions of it to the appropriate banks.

Then you can turn rendering on, and all you have to do change frames is write a new CHR bank to $8000 in your NMI. You can ALSO write entirely new tiles there through $2006/$2007 but when rendering is on you have a VERY limited number of updates you can do in a frame before it starts to become unsafe. With $8000, you can change all 512 tiles multiple times per frame.

Edit: Just to be maximum clear, the write doesn't necessarily have to be to $8000. It can be anywhere from $8000-$FFFF. Occasionally for bank swapping the value stored at the location you write to has to be the same byte as what you write to ensure you get the right result (due to "Bus Conflicts"), but NES Maker's configuration I believe is one where this does not matter. (i.e. Mapper 30 is subject to Bus Conflicts for non self flashable boards of it, but NES Maker's carts are likely to be self flashable since saving is possible.)

Edit2: Troll Burner stores which CHR bank in $06D0 if you want to look at it with a debugger. The value is updated with either #%00000000, #%00100000, #%01000000, or #%01100000. Then the bank swap subroutine loads the PRG bank (a value with a range of #$00-#$1F) from $0045, and does ORA with $06D0 to get the right animation frame (CHR bank) in the proper bits. Then it stores the result to $C000. So if you freeze $06D0, the animation will stop.

Click to expand...

Kasumi said:

There aren't many cartridge types that allow animated tiles in exactly the way Mapper 30 does.

You can use RAM instead of ROM for tiles with NROM (mapper 0), but it doesn't have bank switching. (The writes to $8000 I mentioned. That's specifically how mapper 30's bank switching works.)
You can use CNROM to try bank switching, but it doesn't have CHR RAM. The way bank switching is done is also slightly different from Mapper 30. https://wiki.nesdev.com/w/index.php/CNROM

Yes, currentbank would be a byte in RAM. You would initialize all NES things, then before you turn rendering back on after initialization you would write the tiles you want. Then turn the screen on and enable NMIs.

You must absolutely use RTI at the end of the NMI code. For two reasons:
1. Remember when you noticed when the NMI hit, the stack pointer went to $FC? RTI makes it go back to $FF. If you jmp back, the next frame will move the stack pointer to $F9. It will keep going down. The NMI happening at all puts plates on the stack. RTI pulls them off. Putting something on the stack and not properly removing it tends to break things whenever the stack is next used.
2. The NMI is an interrupt. It can happen at anytime, after any instruction. If you jmp back to a fixed location, if the program didn't happen to be in that fixed location whatever the code was doing before the NMI interrupted will never get done.

Example file: Mapper30 Switch.zip
I did end up having to deal with Bus Conflicts after all, that's what the BYTETABLE,y stuff is for. Besides that, it's basically what I posted except with more initialization. (Have to write tile 0 to a nametable/write palettes so the change can actually be seen.)

Click to expand...