It is currently Sun Jun 16, 2019 9:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Wed Dec 12, 2018 9:06 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2299
Location: Fukuoka, Japan
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?


Top
 Profile  
 
PostPosted: Wed Dec 12, 2018 10:11 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21439
Location: NE Indiana, USA (NTSC)
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?

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Wed Dec 12, 2018 7:51 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2299
Location: Fukuoka, Japan
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


Top
 Profile  
 
PostPosted: Sat Dec 15, 2018 7:17 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2299
Location: Fukuoka, Japan
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group