| |||
Views: 88,482,258 |
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search | 04-25-24 03:17 PM |
|
Guest: Register | Login |
0 users currently in ROM Hacking | 2 guests | 1 bot |
Main - ROM Hacking - I'm having a problem writing PPU tiles to SMB2's titlescreen | New thread | New reply |
RetroRain |
| ||
Fuzz Ball Level: 66 Posts: 879/994 EXP: 2438024 Next: 23827 Since: 09-30-07 Last post: 1934 days Last view: 956 days |
My project has been going very slowly. I never would have thought that SMB2 would be such a pain in the ass to work with, but it is.
Okay, here's the deal. When you press start on the titlescreen, instead of taking you to the character select screen, I want the code to instead write PPU tiles to the screen. This is my option box, which will display the game options. However, when I write tiles to the screen, I get tiles that are not even in my table showing up, and then don't write properly. It's like at times, they are being randomly screwed up. If you want to see for yourself: On the titlescreen, or the story part of the titlescreen, open up the debugger in FCUEX. Go to address $9C19. This is the code you will find:
Anything after $9C1D is what happens when you press the start button. Just put a JSR or JMP to some free space, and have some code that reads a table and writes it to $2007, and then does an infinite loop, and you will see what I mean. If I can't get passed this PPU problem, my project is in trouble. And I'm not one to give up. I've been wrestling with this problem for a few days now. I don't usually post a thread until I have tried figuring it out on my own. I have ruled out the X and Y registers for reading my table, and I have ruled out the $2007 auto-increment number. This is what I'm going for (with obvious-needed attribute table fixes) There is free space at $9D56 (even before that, all of the FFs). I modified my table to display the numbers 0 through 9, and some letters.
And this is the garbage I get. If anyone could help me figure this out, that would be great. Thanks for your help. ____________________ My YouTube Channel |
MiniCompute |
| ||
Bubble Level: 66 Posts: 690/981 EXP: 2421302 Next: 40549 Since: 04-25-07 Last post: 488 days Last view: 697 days |
Hmm does fecux have a tile viewer where you can see the gfx and other tiles while debugging ?
If it does, run your game again and look at the tile viewer and see where the game might be pulling the wrong tiles. Also you could ask infildelt, its a long shot but he might know something. |
za909 |
| ||
Cheep-cheep Level: 32 Posts: 184/196 EXP: 189057 Next: 17385 Since: 04-27-11 Last post: 3052 days Last view: 2762 days |
Is your code running during VBlank? If not, then your code will disturb the PPU as it's rendering (outputting the picture to the screen) and during that process it has to use the $2006 and $2005 registers (maybe even others) along with its internals to fetch pixel data from tiles and output them to the screen. If you want to write something to the PPU outside of VBlank you have to turn the rendering off in $2002, but if you do that for too long, parts of the screen might be missing.
Most games have a tile buffer in RAM to prepare which tiles have to be updated during VBlank, so the code during VBlank only has to copy-paste the data to $2007, as VBlank time is very short.(~2200-2300 cycles, DPCM samples playing can steal a maximum of around 150) |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 768/968 EXP: 2367897 Next: 93954 Since: 05-24-07 Last post: 958 days Last view: 813 days |
za909 beat me to it, lol.
If you know the register where smb2 performs its ppu rendering on/off, you could turn it off form one CPU cycle, then load your entire vram routine on one CPU cycle, then the next CPU cycle you would turn ppu rendering back on. You will, however, get a quick black flash due to turning off the ppu rendering. I did this for my legend of link registration screen, due to lots of vram I needed for the differnt screens. I swear, Mario games are so tightly crammed when code is executed. When I tried doing slight vram writes to smb2j it was tedious. Anyway good luck! |
MiniCompute |
| ||
Bubble Level: 66 Posts: 691/981 EXP: 2421302 Next: 40549 Since: 04-25-07 Last post: 488 days Last view: 697 days |
I swear you guys are like super gaming nerds, but good info even though I barely interpret half the stuff your saying.
reminds me I need to look at that asm for nes and snes guides I was given. |
za909 |
| ||
Cheep-cheep Level: 32 Posts: 185/196 EXP: 189057 Next: 17385 Since: 04-27-11 Last post: 3052 days Last view: 2762 days |
If it's just a simple update of a few tiles on the screen, and it only has to execute once, I guess you can put your code in between these:
This might even avoid the black screen for a frame. You could get a few scanlines of blackness though if your update takes more than 113-114 CPU cycles. (that's how many pass during the processing of every horizontal pixel line by the PPU) Here, you can see how many CPU cycles each instruction takes based on the addressing mode, and other conditions But ultimately, I don't think anyone's going to care about a single glitchy frame. |
RetroRain |
| ||
Fuzz Ball Level: 66 Posts: 880/994 EXP: 2438024 Next: 23827 Since: 09-30-07 Last post: 1934 days Last view: 956 days |
Yeah, I always wait for vblank before writing my tiles. But with most projects I have done, I was able to write at least $40 bytes (in hex) with no problem. In this game, I'm getting problems with very few bytes (less than $20).
My code to write tiles is like this, which is pretty much the only way to do it, as far as I know:
(I always like to have my tables above my code, so that way it is not in the way later as I add more code.) Posted by infidelityBut the NES' register for rendering is $2002. Are you saying that there is a special RAM address that the game specifically uses to read from and then writes to $2002? I'll try turning the rendering off, and see what happens. Thanks guys. ____________________ My YouTube Channel |
za909 |
| ||
Cheep-cheep Level: 32 Posts: 186/196 EXP: 189057 Next: 17385 Since: 04-27-11 Last post: 3052 days Last view: 2762 days |
Oh, if you are waiting for VBlank with a loop looking at the VBlank flag, you might have a problem because the NMI triggers, which then eats up all the VBlank time to do its thing, and by the time it returns to your code, you could be past VBlank again. But that's just some speculation on my part.
Waiting to see if it works |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 769/968 EXP: 2367897 Next: 93954 Since: 05-24-07 Last post: 958 days Last view: 813 days |
@RetroRain. I'll explain my comment.
Some games set aside a ram register, so that you can edit it without wasting prg-rom space with numerous writes to alter that specific nes register. What I would, is pause the emulator, add a write breakpoint to the ppu rendering register, now restart the rom while the emulator is still paused, then fire up the trace logger, now click run on the code data logger, and watch what gets stored into the nes register that deals with ppu rendering. See if its doing only hard coded writes, or if its using a ram register to check and alter itself, like A5FE 8D0020(I forget the nes register I'm question off the top of my head) The whole reason for this post, was to see if you can turn the ppu off manually, so you could perform some vram tests. I hope you get it figured out. :-) |
RetroRain |
| ||
Fuzz Ball Level: 66 Posts: 881/994 EXP: 2438024 Next: 23827 Since: 09-30-07 Last post: 1934 days Last view: 956 days |
Problem solved!
Believe it or not, there was nothing wrong with my code. In fact, I tried all of the methods you guys mentioned. NOTHING WORKED. What was the problem? Quite simply, I was writing too many bytes during Vblank. What I did, was instead of trying to write the tiles I really needed, I wrote the alphabet exactly where my option box begins and ends, on that line. I counted the bytes. There was $14 bytes (the letters A through T). I figured if $14 bytes wound up being too much, I could always divide it in half, and write $07 at a time. Fortunately, this wasn't necessary. I can write $14 bytes just fine, without a problem. Unlike in other games I have hacked, where I could get away with writing the minimum of $40 bytes at a time, in this game, you can't write as many at a time. Most likely what infidelity said, with the Mario games being tightly crammed. But I really do appreciate the help you guys offered. Really, thank you so much. You guys are great! ____________________ My YouTube Channel |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 770/968 EXP: 2367897 Next: 93954 Since: 05-24-07 Last post: 958 days Last view: 813 days |
Good to hear you got it figured out. |
MiniCompute |
| ||
Bubble Level: 66 Posts: 692/981 EXP: 2421302 Next: 40549 Since: 04-25-07 Last post: 488 days Last view: 697 days |
Posted by RetroRain =_= you what..... make this game a hard mode, I don't want the same old easy smb2 game. There is game genie codes you can convert to make it difficult, longer and more worth it. Now that SHOULD work. glad your problem is fixed. |
Main - ROM Hacking - I'm having a problem writing PPU tiles to SMB2's titlescreen | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
MySQL - queries: 92, rows: 124/124, time: 0.017 seconds. |