mmc3/irq: sometime affect fade in/out

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

mmc3/irq: sometime affect fade in/out

Post by Banshaku »

For now I cannot show a piece of code since the same function works fine when not used with timed/irq code some I'm not suspecting the fade code as the issue but more something else affect the fade code while writing to the PPU.

It seems that in some situation, the fade in/out doesn't work well and after going to a few state (state = other screens, menu etc) and coming back to that place, it may stabilize and sometime shows properly. In other screen that doesn't ireq, that behavior doesn't occurs.

One thing that I found odd is in all screen, if I wait for the nmi to trigger the fade and use nmi to wait between frame it works fine except for the ones with IRQ. In those case, if I don't sync to the vblank, the fade often doesn't work at all. Quite an odd behavior. I'm not sure why the IRQ could cause thing to go out of whack, maybe it touches the PPU like for split the screen and happens at the same time as nmi? hmmm..

Now that I was able to improve my fade function by adding a frame with emphasis set, it looks a lot better except for those case when it start to fail.

Have anybody experienced similar behavior while using irq?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: mmc3/irq: sometime affect fade in/out

Post by tepples »

Might the MMC3 be seeing your palette writes as accessing the second pattern table (PA12 high), even if /RD or /WR isn't asserted during palette writes? Have you tried reloading the counter after you've finished writing the palettes?
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: mmc3/irq: sometime affect fade in/out

Post by Banshaku »

tepples wrote:Might the MMC3 be seeing your palette writes as accessing the second pattern table (PA12 high), even if /RD or /WR isn't asserted during palette writes? Have you tried reloading the counter after you've finished writing the palettes?
The counter is incremented after the palette is loaded. Like mentioned, what I found odd is if I was using the nmi counter for waiting for the next step in the palette fade , nothing was happening, which is odd. In that case, if I wait for the vblank, it was working but later I found that in some case, fade was unstable but not always.

I saw that it was less stable in some case when the code in the static bank changed, which could imply some page crossing issue but still, why only during IRQ but fine in other cases (other cases uses nmi wait). BUT, the failure of the fade occurred 100% when using nmi counter, which may be an important detail.

And example of what is done inside nmi for a screen with IRQ that have this issue and may be considered complex:

[inside nmi]
- save registers
- there is a callback function that check in C code for some text to be updated
- it starts the nmi minimum handler code
-- First update OAM
-- then palette, if necessary
-- Restore PPU_CTRL and reset latch (PPU_STATUS)
-- reset scroll
-- Restore PPU_MASK
-- update counter
- set IRQ counter
- set proper chr bank for top part
- update sound engine
- restore registers

[inside first hit of IRQ counter]
- save registers
- scroll position of screen
- Acknowledge IRQ
- set new IRQ handler
- prepare next IRQ
- restore registers

[inside last hit of IRQ counter]
- save registers
- scroll bottom to show part of from NT on right
- prepare register to change CHR banks for fonts
- Acknowledge IRQ
- restore middle screen IRQ handler for next frame
- nop for timing to change bank without glitch
- change bank
- restore registers

This screen is complicated, I do agree. But like mentioned, there is technically 2 issues:
- fade always fail if done with NMI while screen requires IRQ
- if done with vblank, maybe the location of code in static bank seems to affect display

What concerns me the most if case 1. I would love to just re-use code with NMI only since it's the most stable in all other screen but it doesn't work. I just need to understand where is the gotcha with IRQ that could affect fade when waiting for NMI instead of vblank while using IRQ.

Since it's quite a complicated issue I'm not expecting to have a clear answer on the subject but anything that I could test will be greatly appreciated. NMI fade bug is the one puzzling me the most. Using vblank instead seems to be a timing issue caused by code that ends up on a border, maybe it can be aligned in some way.

This is one puzzle that I will be relieved when the cause will be found :D
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: mmc3/irq: sometime affect fade in/out

Post by Banshaku »

I guess from the lack of response is that problem is not common and will be hard to find. hmmm...

After the OAM, palette is refreshed in nmi, the irq counter is reloaded for the proper split so it seems to be done like tepples said.

Like mentioned, what puzzled me the most is palette fade doesn't work if wait for nmi counter for waiting a frame, only waiting for the vblank seems to make it work. This one I cannot get my head around and puzzled about what could cause that.

edit:

I will see if I can make some sample that cause that error but outside of my current code base. this way, with an example, it will be easier to figure out what I'm doing wrong.
Post Reply