Mini-helmets for NFC West? (cxrom 32 team NES TSB)

[buck]

cxrom, where are the NFC West mini-helmets data stored in your 32 team rom?

[cxrom]

at 0x3F6C3

A4A5B4B586878C8DA69BB68382008E8330023B3C

[buck]

stumped again at these NFC west minis.  if I don't mess with them for a while I tend to forget how they work.  anyways, I simply need to slide the "special tile" for the ARZ down a couple of notches so that it lines up with the ARZ logo (I slid the ARZ logo down x08).

 

I do not understand where the variable is to position the ARZ special tile.  in my rom, said ARZ special tile is C6.

 

see attached png for reference.

[buck]

figured it out.  simple and stupid.  it is up there with the other regular mini stuff x23bc0 area.  just had to shift it down like I shifted all the non-nfc west team special tiles.  I don't know why those damn minis mess with my head so much.

[bruddog]

The highlighted 3C isn't actually the tile. Here is the FCEUX logic I went through. I'm working off a slightly different rom but the logic is the same. Knowing the tile ID for the sprite I did a quick search in sprite memory ($200-$2FF) 

 

The data is layed out as follows

Y coord, tile ID, attributes, x coord

 

Then I found the tile ID F9 at 0x2FD. Then I set a write breakpoint for that address. You'd want to set the breakpoint once you are at the main menu. Ideally if you know the tile you could add a further condition like A==#F9. A is the accumulator and is usually loaded with the data to be stored. 

 

Once it breaks you get this in the FCEUX window

 

 08:A7F6:B9 52 BC  LDA $BC52,Y @ $BCDA = #$F9
 08:A7F9:9D 01 02  STA $0201,X @ $02FD = #$F9

 

If you hover over the A7F6 with the cursor you'll see at the bottom of the debug window the offset in the rom its executing from which in this case is

0x22806. So where is it getting the data from? Well in that line we see @BCDA. B would add 0x1000 to the current offset+ the head offset of 0x10 so the tile data is

 

at 0x23CEA. The Y coordinate is the byte before that at 0x23CE9. 

 

[bruddog]

Well looks like you figured it out on your own. 

 

[buck]

2 minutes ago, bruddog said:

The highlighted 3C isn't actually the tile. Here is the FCEUX logic I went through. I'm working off a slightly different rom but the logic is the same. Knowing the tile ID for the sprite I did a quick search in sprite memory ($200-$2FF) 

 

The data is layed out as follows

Y coord, tile ID, attributes, x coord

 

Then I found the tile ID F9 at 0x2FD. Then I set a write breakpoint for that address. You'd want to set the breakpoint once you are at the main menu. Ideally if you know the tile you could add a further condition like A==#F9. A is the accumulator and is usually loaded with the data to be stored. 

 

Once it breaks you get this in the FCEUX window

 

 08:A7F6:B9 52 BC  LDA $BC52,Y @ $BCDA = #$F9
 08:A7F9:9D 01 02  STA $0201,X @ $02FD = #$F9

 

If you hover over the A7F6 with the cursor you'll see at the bottom of the debug window the offset in the rom its executing from which in this case is

0x22806. So where is it getting the data from? Well in that line we see @BCDA. B would add 0x1000 to the current offset+ the head offset of 0x10 so the tile data is

 

at 0x23CEA. The Y coordinate is the byte before that at 0x23CE9. 

 

 

thanks for the tips, I will have to try this method out sometime.  by "sprite memory" do you mean the PPU Memory?

[bruddog]

No I mean CPU memory. The CPU memory contains the sprite information that get copied one per frame.  

 

The link below also contains info about the sprite attribute byte. 

http://wiki.nesdev.com/w/index.php/PPU_OAM

 

"DMA

Most programs write to a copy of OAM somewhere in CPU addressable RAM (often $0200-$02FF) and then copy it to OAM each frame using the OAMDMA ($4014) register. Writing N to this register causes the DMA circuitry inside the 2A03/07 to fully initialize the OAM by writing OAMDATA 256 times using successive bytes from starting at address $100*N). The CPU is suspended while the transfer is taking place.

The address range to copy from could lie outside RAM, though this is only useful for static screens with no animation.

Not counting the OAMDMA write tick, the above procedure takes 513 CPU cycles (+1 on odd CPU cycles): first one (or two) idle cycles, and then 256 pairs of alternating read/write cycles. (For comparison, an unrolled LDA/STA loop would usually take four times as long.)"