| |||
Views: 88,486,446 |
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search | 04-26-24 09:19 AM |
|
Guest: Register | Login |
0 users currently in ROM Hacking | 2 guests |
Main - ROM Hacking - How to change the way a rom READS BG & Sprites within ppu? | New thread | New reply |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 199/968 EXP: 2368040 Next: 93811 Since: 05-24-07 Last post: 958 days Last view: 814 days |
First let me just say that i've been tooling around with The Legend of Zelda since about October 2011. The changes I've made on my own from then, to now...
1. I've converted the rom from MMC1 to MMC3 2. Added a CHR-ROM engine for gfx swapping (BG/Sprites) 3. Expanded the rom to the fullest limits allowed within MMC3 (rom size, PRG, CHR) 4. Added an IRQ engine with working split screen dependant from the original sprite 0 split, for keeping the status bar stationary during x/y screen scrolls 5. MAJOR asm work on modification/creation of new weapons, tricks Now i've wanted to sooooo badly, to do as much as I could on my own with asm, but i'm having an issue with my IRQ split screen. Now i've tried doing as much research and messing around on my own, with trying to get this to work 'properly' so here's my problem. When I have a ton of sprites on the screen at a once, I can literaly position my split screen where ever I want. But, the less sprites that are on the current screen, the split begins to flicker badly, even disappear, and sometimes crash the rom. Originaly I didn't realize this till a few days ago, but I did this work back in November 2011. I originaly had my split appear below the status bar in the game, so I could freely move the screen below the status bar in any direction. But a few months later, I began to notice that if there was no sprites on the screen, the game would eventualy crash. It was yesterday that I was tooling around with a screen that had as many sprites possible, and I could position my irq at any length horizontaly. So i tried looking at Disch's doc on the IRQ usage in MMC3. What he said is that a rom that uses 8x16 sprites 'yup, zelda 1 does' HAS to be occupied with $1000-$1FFF and BG occupies $0000-$0FFF. Now, I can move my tiles within the ppu, where ever I want now due to my CHR-ROM engine. So I figured, ok, I'll just have the BG tiles appear in $0000-$0FFF, and sprites within $1000-$1FFF. I shifted the gfx, and to what I knew would happen, all the gfx in the game we're garbage. So, I then started messing around with the values within $8000 at the end of my hw bank. I have A906 & A907 stores into $8000. Now let me remind you, my BG is now in $0000-$0FFF, Sprites are in $1000-$1FFF. So, I change them to 86 & 87. When I did that, with my PPU Viewer open, the gfx shifted back to the way they we're before, so it was like I did absolutly nothing. Then I realized..... It's the way the rom is READING the PPU. So my realization was, "the rom is reading the sprites at $0000-$0FFF and is reading the BG at $1000-$1FFF. It doesnt matter about where you put the gfx in the rom, it's the roms way of saying, bg loads at $0000, sprites load at $1000" So, with no knowledge on how to change the way a rom reads the PPU, i began just noobishly changing individual bytes within the HW bank, to see if I could get any changes. I did one change that pretty much did it for the BG, but the sprites were still screwed up and not being loaded from $1000-$1FFF. With what I thought was a fix for the BG, I tried using my IRQ split again, and it still gave me the wrong results. :-( So i ask. Is there a universal way of detecting a rom's method of READING the PPU? Is there a way to tell the rom to read the BG in $0000-$0FFF and read the sprites at $1000-$1FFF? Because I've seen regular MMC3 games like that, ex SMB3, MM4. Thank you for taking the time to read this. At some point, i'll go into further detail on what i've been doing, and what my goals are with this. :-) |
snarfblam |
| ||
Tektite Level: 18 Posts: 1/54 EXP: 26412 Next: 3485 Since: 03-10-12 Last post: 3870 days Last view: 2820 days |
Check out http://wiki.nesdev.com/w/index.php/PPU_registers.
It sounds like all you need to do is set bits 2 and 3 accordingly on $2000 (PPU control). I'm guessing that the game caches the value of the register. You want to look for writes to $2000, see where it loads the value that gets written there, and that's the cached value. Find out where it initializes the cached value, and it will probably be as simple as flipping bits 2 and 3 on a constant in the init code. |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 200/968 EXP: 2368040 Next: 93811 Since: 05-24-07 Last post: 958 days Last view: 814 days |
Thank you for that info! :-) Ill start checking out $2000 sometime over the weekend, and ill post my findings/results. Again, thank you. :-) |
Thanatos-Zero |
| ||
Nipper Plant Level: 45 Posts: 251/423 EXP: 652840 Next: 7324 Since: 11-25-08 From: Germany - Rheinlandpfalz - Wittlich - Zur Phillippsburg 25 Last post: 1091 days Last view: 1053 days |
MMC3 eh? Why not going for the MMC5 mapper? ____________________ I was a prisoner enclosed in the void, were everything might end up just as myself. There I was called the death in the void, but after a long sleep my drill was ready to pierce the void. I came back... to guide those who are in doubt and to crush any corrupted mind. "Just who in the hell do you think I am?!". |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 201/968 EXP: 2368040 Next: 93811 Since: 05-24-07 Last post: 958 days Last view: 814 days |
Well theres 2 reasons as why i didnt. 1. I felt that would be overkill, when all im doing is practicing asm, and just tinkering with the rom. 2. I can code up to MMC5 about 95% myself. If i cant figure it out on my own, i dont attempt it. |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 202/968 EXP: 2368040 Next: 93811 Since: 05-24-07 Last post: 958 days Last view: 814 days |
Well, i was able to change the value in $2000 that tells the rom where to read the BG and Sprites, but my sprites dont appear correctly. The top tile of a sprite appears, but not the bottom tile. Idk. Smb3 has 8x16 and that occupies $1000. :-/ |
snarfblam |
| ||
Tektite Level: 18 Posts: 3/54 EXP: 26412 Next: 3485 Since: 03-10-12 Last post: 3870 days Last view: 2820 days |
I'm not sure what SMB3 has to do with it, and I don't have much to go on here, without seeing your code or the original code. Does Zelda use 8x16 sprites? This is also controlled by a flag in the $2000 register. Make sure you haven't accidentally cleared it. |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 203/968 EXP: 2368040 Next: 93811 Since: 05-24-07 Last post: 958 days Last view: 814 days |
Both games use 8x16 sprites. And you were right, i had the 8x16 enable bit off. So, i was able to swap where BG & Sprites are loaded from, but, if i want to keep this, id have to alter the tiles to EVERY sprite, for them to appear correctly. Blah, haha! |
RetroRain |
| ||
Fuzz Ball Level: 66 Posts: 575/994 EXP: 2438175 Next: 23676 Since: 09-30-07 Last post: 1935 days Last view: 957 days |
I can't wait to see some screenshots and/or video footage of what you're working on. Good luck with your endeavor! ____________________ My YouTube Channel |
infidelity |
| ||
Fuzz Ball Level: 66 Posts: 204/968 EXP: 2368040 Next: 93811 Since: 05-24-07 Last post: 958 days Last view: 814 days |
Ill try to get some videos up at some point. :-) I added a tiny piece of code with an ADC of 01, to all of the sprite tile registers within $200-$2FF after they're written to, and it fixed about 90% of all the sprites in the game. |
Main - ROM Hacking - How to change the way a rom READS BG & Sprites within ppu? | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
MySQL - queries: 82, rows: 111/112, time: 0.017 seconds. |