buck Posted February 29, 2008 Share Posted February 29, 2008 cxrom, where are the NFC West mini-helmets data stored in your 32 team rom? Quote Link to comment Share on other sites More sharing options...
cxrom Posted March 1, 2008 Share Posted March 1, 2008 at 0x3F6C3A4A5B4B586878C8DA69BB68382008E8330023B3C Quote Link to comment Share on other sites More sharing options...
buck Posted May 29, 2016 Author Share Posted May 29, 2016 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. Quote Link to comment Share on other sites More sharing options...
buck Posted May 30, 2016 Author Share Posted May 30, 2016 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 1 Quote Link to comment Share on other sites More sharing options...
bruddog Posted May 30, 2016 Share Posted May 30, 2016 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. buck 1 Quote Link to comment Share on other sites More sharing options...
bruddog Posted May 30, 2016 Share Posted May 30, 2016 Well looks like you figured it out on your own. Quote Link to comment Share on other sites More sharing options...
buck Posted May 30, 2016 Author Share Posted May 30, 2016 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? Quote Link to comment Share on other sites More sharing options...
bruddog Posted May 30, 2016 Share Posted May 30, 2016 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.)" buck 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.