It is currently Fri Sep 21, 2018 7:56 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Jul 01, 2018 1:06 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
I've got a parallax effect in one level of my new game. It works perfectly on emulators and on the original NES. But on AVS, after the second split the scroll kind of jitters up and down. I'm experimenting with ways to nudge the scroll update so that it aligns more correctly with hblank, but I can't seem to get it perfect on AVS. I either get scroll bounce, or a small glitch (similar to the status bar glitch in SMB3).


Last edited by GradualGames on Mon Jul 02, 2018 12:52 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sun Jul 01, 2018 7:15 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
When you say "on the original NES", do you mean using actual MMC3 chips or using FPGA flash carts? If the latter, you still can't be sure the code is 100% right. Once you can get it to work correctly across different revisions of the actual MMC3 chip, then this is really a problem for whoever is maintaining the flash cart and AVS implementations of the mapper.

I know things aren't as simple as this, as have creators we want to provide players with the best experience across all devices, so sorry if I can't give much technical advice on this.

What I can say is that MMC3 IRQs fire to late in the scanline for you to do any real hblank work in that same scanline, so you normally have to wait nearly a full scanline worth of CPU time in order to get a clean split. The other relevant thing I can say is that although changing the scroll takes a complex sequence of $2006/5/5/6 writes, only the last two wires have to happen during hblank for you to get a clean split, so that's just 5 cycles (the last cycle of the second $2005 write, plus e 4 cycles of the second $2006 write) you need to for in hblank, which leaves a lot of wiggle room for you to work with.


Top
 Profile  
 
PostPosted: Sun Jul 01, 2018 7:46 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
tokumaru wrote:
When you say "on the original NES", do you mean using actual MMC3 chips or using FPGA flash carts? If the latter, you still can't be sure the code is 100% right. Once you can get it to work correctly across different revisions of the actual MMC3 chip, then this is really a problem for whoever is maintaining the flash cart and AVS implementations of the mapper.

I know things aren't as simple as this, as have creators we want to provide players with the best experience across all devices, so sorry if I can't give much technical advice on this.

What I can say is that MMC3 IRQs fire to late in the scanline for you to do any real hblank work in that same scanline, so you normally have to wait nearly a full scanline worth of CPU time in order to get a clean split. The other relevant thing I can say is that although changing the scroll takes a complex sequence of $2006/5/5/6 writes, only the last two wires have to happen during hblank for you to get a clean split, so that's just 5 cycles (the last cycle of the second $2005 write, plus e 4 cycles of the second $2006 write) you need to for in hblank, which leaves a lot of wiggle room for you to work with.


I just learned how to use Mesen to confirm I'm in hblank. It shows me the ppu cycle if I set a breakpoint, so I set a breakpoint at the first of those last two writes to 2005 and 2006, and if it is between 256 and 341 I should be okay, right? it kept landing around 280 or so.

So here's the thing, works perfect on Mesen, Nestopia, Nintendulator, original NES, but on AVS, the second split bounces by 1 scanline.

It's a train, and looks kinda cool, so I might just have to live with it. But it made my OCD go off pretty bad. I don't know if I can make it work the same on all. Sure wish I could.

Wondering if I fine tune it further to more reliably land closer to 256 in that range if there'd be less chance of the writes bleeding outside of hblank.

It's weird that it bumps a whole scanline though it makes me think something odd is happening with respect to reloading the mmc3 scanline counter that's making it off by 1 sometimes and not others though. Yet it IS only AVS with this issue.


Top
 Profile  
 
PostPosted: Sun Jul 01, 2018 9:20 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
You didn't confirm if "real NES" means actual MMC3 chips or flash carts. I know it should work either way, but I think it's important to point out that if you used flash carts, you haven't used a single real MMC3 this whole time, only emulations/simulations of it, and maybe it'd be a good idea to give the real thing a try.


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 1:54 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 796
Some of Mega Cat titles had mmc3 issues on AVS, which only appeared on some firmware versions and not others (you can find the details at NA's AVS forum). They weren't what you saw, slight jitter, but an irq entirely missing on some frames. Still, it only happened on AVS, only on some firmware versions, on real (repro) mmc3 boards, so it's possible your issue too is something in the AVS firmware.

I agree with tokumaru that you need to post what you're testing on.


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 5:41 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
I'm using the PowerPAK with thefox's powermappers. (can't remember if that replaces mmc3 or not. probably not?).

I think next step I'm going to get a board and programmer from INL and try their mmc3 implementation, see if I get different results.

I keep wondering though if there's anything subtle in my implementation that could make the AVS happy. While experimenting there was at least one moment where FCEUX was off by one scanline versus the other emulators. Not bouncing like AVS, but off by one scanline.

My question is:

Does it matter when the mmc3 scanline counter is reset? If the timing is off and occurring very near where the ppu is going to start the next line could this conceivably cause an off-by-one scanline issue?

So in addition to trying the actual hardware my game will be released on instead of the PowerPAK, I think I'll try pushing out the scanline reset by a handful of cycles with some nops or something. I'm doing it RIGHT after the split x/y scroll writes.


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 6:52 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
I keep wondering if there are any potential problems here. I'm acknowledging the mmc3 irq and resetting the scanline counter RIGHT AFTER the split x/y writes. Since the scanline counter is affected near hblank, I am wondering if this could be causing my off-by-one scanline jitter that I've observed on AVS, and I think fceux at one point during experimentation.

Assume for this example I've timed the split x/y 2005/2006 writes properly into hblank. I'm wondering if the timing of the mmc3 counter reset is important as well and might cause an off by one scanline problem?

I'm wondering if I inserted enough nops between these operations if it might prevent jitter on touchier systems. Just speculation. Thoughts?

Code:
    ldy split_index
    lda split_nametable,y
    sta $2006
    lda split_scroll_y,y
    sta $2005
    lda split_scroll_x,y
    sta $2005
    lda split_nametable_lo,y
    sta $2006

    ;insert nops here?

    ;Acknowledge MMC3 irq.
    sta MMC3_IRQ_DISABLE

    ;Initialize next split if there is one.
    inc split_index
    ldy split_index
    cpy split_count
    beq :+
    lda split_scanlines,y
    sta MMC3_IRQ_LATCH
    sta MMC3_IRQ_RELOAD
    sta MMC3_IRQ_ENABLE
:



Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 8:16 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10814
Location: Rio de Janeiro - Brazil
GradualGames wrote:
While experimenting there was at least one moment where FCEUX was off by one scanline versus the other emulators. Not bouncing like AVS, but off by one scanline.

FCEUX rounds some things to the nearest scanline, it's probably one of the worst emulators to test raster effects.

Quote:
Does it matter when the mmc3 scanline counter is reset? If the timing is off and occurring very near where the ppu is going to start the next line could this conceivably cause an off-by-one scanline issue?

Since the scanline counter takes a relative number of scanlines (i.e. "fire an IRQ in N scanlines"), I assume that if you reload the counter near the end of the scanline, the split could indeed jitter by one scanline. Normally, the first IRQ will be setup during vblank, when the MMC3 isn't clocked, and subsequent IRQs are setup inside the IRQ handler, so it should be easy to avoid this problem.

Quote:
I'm doing it RIGHT after the split x/y scroll writes.

IIRC, the scanline counter is clocked when the sprite patterns are fetched, so by the time hblank is over, it should be safe to schedule the next IRQ.


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 8:59 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
tokumaru wrote:
IIRC, the scanline counter is clocked when the sprite patterns are fetched, so by the time hblank is over, it should be safe to schedule the next IRQ.

So that's the interesting part to me; when I look at mesen, and I set a breakpoint on the first of those last two writes to 2005 and 2006, I'm somewhere in the middle of hblank. So it is conceivable to me that I'm resetting the scanline counter still during hblank, since I do this right after those writes. And I'm not sure precisely where in hblank that fetch occurs. So perhaps a few nops could push the scanline counter reset far enough out that, if I have timed the 2005/2006 writes correctly, I can guarantee it won't be resetting at the wrong time? That's my hope right now. Going to try it later in the week :D As well as try different mmc3 hardware.


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 9:49 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
From the wiki:

https://wiki.nesdev.com/w/index.php/PPU_scrolling

"Hblank begins after dot 256, and ends at dot 320 when the first tile of the next line is fetched."

My 2005/2006 writes according to mesen are landing around 280 or so, and since I am doing the scanline counter reset right after, it seems conceivable it may conflict with fetching the first tile of the next line etc.


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 12:22 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3127
Location: Tampere, Finland
What version of PowerMappers are you using?

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 12:26 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
thefox wrote:
What version of PowerMappers are you using?

Code:
                         --------------
                          PowerMappers
                         --------------

                           v20 (BETA)

                       by thefox//aspekt
                        thefox@aspekt.fi
                     http://kkfos.aspekt.fi



Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 12:37 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
thefox wrote:
What version of PowerMappers are you using?

I see it is up to v23 now, think I should try it out?


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 12:40 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3127
Location: Tampere, Finland
GradualGames wrote:
thefox wrote:
What version of PowerMappers are you using?

Code:
                         --------------
                          PowerMappers
                         --------------

                           v20 (BETA)

                       by thefox//aspekt
                        thefox@aspekt.fi
                     http://kkfos.aspekt.fi


Try the latest version (v23, https://fo.aspekt.fi). And/or you can try loopy's MMC3 (http://3dscapture.com/NES/) if you don't need save states.

The MMC3 IRQ implementation in PowerMappers v20 was somewhat quirky, some people had problems with it on some systems. Even though it used the exact same logic as in loopy's MMC3 implementation, there are gated clocks in the design and that causes problems as the timings change depending on the amount of other logic in the mapper (the save state stuff uses up almost all the logic resources in the FPGA). It was just too annoying to find that in one build the IRQ would work and in the next one it wouldn't work, so in v23 I replaced it with an implementation that is completely synchronized to M2. The timings of this implementation are a little bit off from a real MMC3 (similar to Tengen's RAMBO-1 MMC3 clone, nothing extreme), but AFAICT it has been robust.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Mon Jul 02, 2018 12:58 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
thefox wrote:
GradualGames wrote:
thefox wrote:
What version of PowerMappers are you using?

Code:
                         --------------
                          PowerMappers
                         --------------

                           v20 (BETA)

                       by thefox//aspekt
                        thefox@aspekt.fi
                     http://kkfos.aspekt.fi


Try the latest version (v23, https://fo.aspekt.fi). And/or you can try loopy's MMC3 (http://3dscapture.com/NES/) if you don't need save states.

The MMC3 IRQ implementation in PowerMappers v20 was somewhat quirky, some people had problems with it on some systems. Even though it used the exact same logic as in loopy's MMC3 implementation, there are gated clocks in the design and that causes problems as the timings change depending on the amount of other logic in the mapper (the save state stuff uses up almost all the logic resources in the FPGA). It was just too annoying to find that in one build the IRQ would work and in the next one it wouldn't work, so in v23 I replaced it with an implementation that is completely synchronized to M2. The timings of this implementation are a little bit off from a real MMC3 (similar to Tengen's RAMBO-1 MMC3 clone, nothing extreme), but AFAICT it has been robust.


Cool I'll give it a try. Since you're familiar with how this mapper works, is my theory above at all conceivable? Like, do I need to ensure a fair distance between the split x/y 2005/2006 writes and the reset of the mmc3 scanline counter? I have these operations right next to each other; I'm wondering if it would be "safer" and admit a variance in mmc3 implementations to spread the two operations apart with a few nops or something, or if that's all speculation and not reflective of what may actually be happening with this 1 scanline jitter?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: lidnariq, Memblers, Punch and 3 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