Points of Required Attention™
Please chime in on a proposed restructuring of the ROM hacking sections.
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
Posted on 05-20-15 08:29 AM (rev. 2 of 05-20-15 09:15 AM) Link | Quote | ID: 160128


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:

$9C19:A5 F7     LDA $00F7 = #$00
$9C1B:29 10 AND #$10
$9C1D:F0 16 BEQ $9C35

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.

$9D56:AD 02 20  LDA $2002
$9D59:10 FB BPL $9D56
$9D5B:A9 22 LDA #$22
$9D5D:8D 06 20 STA $2006
$9D60:A9 06 LDA #$06
$9D62:8D 06 20 STA $2006
$9D65:A2 00 LDX #$00
$9D67:BD 5D 9C LDA $9C5D,X
$9D6A:8D 07 20 STA $2007 = #$00
$9D6D:E8 INX
$9D6E:E0 15 CPX #$15
$9D70:D0 F5 BNE $9D67
$9D72:4C 72 9D JMP $9D72 ; infinite loop so I can see my ppu tiles. temporary code

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
Posted on 05-20-15 01:10 PM Link | Quote | ID: 160129


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
Posted on 05-20-15 01:17 PM Link | Quote | ID: 160130


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
Posted on 05-20-15 02:22 PM Link | Quote | ID: 160131


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
Posted on 05-20-15 03:19 PM Link | Quote | ID: 160132


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
Posted on 05-20-15 04:49 PM Link | Quote | ID: 160133


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:

lda #$00
sta $2002 ; turn off rendering

;... this is where you do your update

lda #$1E ; this value might not be what your game uses
sta $2002
;... more stuff...

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
Posted on 05-20-15 05:30 PM (rev. 5 of 05-20-15 05:42 PM) Link | Quote | ID: 160134


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:

table:
00 01 02 03 04 05 06 07 08 09 0A 0B

; wait for vblank

wait_for_vblank:
LDA $2002
BPL wait_for_vblank

LDA #$__ ; Set $2006
STA $2006 ; to proper location
LDA #$__
STA $2006

LDX #$00
next_table_byte:
LDA table, X ; Read from table
STA $2007 ; Write to screen
INX ; Next value in table
CPX #$ ; Check max value
BNE next_table_byte ; If not finished read next byte

(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 infidelity
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.
But 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
Posted on 05-20-15 08:21 PM Link | Quote | ID: 160135


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
Posted on 05-20-15 08:59 PM Link | Quote | ID: 160136


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
Posted on 05-21-15 07:37 AM Link | Quote | ID: 160138


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
Posted on 05-21-15 12:25 PM Link | Quote | ID: 160141


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
Posted on 05-21-15 12:44 PM Link | Quote | ID: 160142


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
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.


But I really do appreciate the help you guys offered. Really, thank you so much. You guys are great!



=_= 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

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.024 seconds. (341KB of memory used)
MySQL - queries: 92, rows: 124/124, time: 0.017 seconds.