[justin3009]

I've had similar issues before, more-so with just a couple issues writing to VRAM with background data.. but I'm having a HUGE issue with this in my SMB2 hack.

The original routine stored both PC graphics and the POW/Flask/Orb crystals as one giant section of code instead of separating it.  So both graphics were stored essentially at the same time in the same routine with the storage of 07 to 420B.

I broke the original routine off and have it storing the PC graphics top and bottom separately (Which it also did in the original) as it's own routine, then the POW/Flask/Orb graphics as a separate routine.. but for some reason this new routine is causing HUGE screen flickering issues.

Code: [Select]

Top Storage of PC Sprites
$13/8B57 AE EF 02    LDX $02EF  [$11:02EF]   A:1801 X:0000 Y:0080 P:envmXdIZC ;Load bank of PC graphic
$13/8B5A 86 04       STX $04    [$00:4304]   A:1801 X:002F Y:0080 P:envmXdIzC
$13/8B5C AD F0 02    LDA $02F0  [$11:02F0]   A:1801 X:002F Y:0080 P:envmXdIzC ;Load how many bytes to send to VRAM
$13/8B5F 85 05       STA $05    [$00:4305]   A:0080 X:002F Y:0080 P:envmXdIzC
$13/8B61 A9 00 60    LDA #$6000              A:0080 X:002F Y:0080 P:envmXdIzC ;Load where to store sprites into VRAM
$13/8B64 8D 16 21    STA $2116  [$11:2116]   A:6000 X:002F Y:0080 P:envmXdIzC
$13/8B67 AD ED 02    LDA $02ED  [$11:02ED]   A:6000 X:002F Y:0080 P:envmXdIzC ;Load pointer to PC sprites
$13/8B6A 85 02       STA $02    [$00:4302]   A:A800 X:002F Y:0080 P:eNvmXdIzC
$13/8B6C A0 01       LDY #$01                A:A800 X:002F Y:0080 P:eNvmXdIzC ;Set bit for storage into VRAM
$13/8B6E 8C 0B 42    STY $420B  [$11:420B]   A:A800 X:002F Y:0001 P:envmXdIzC ;Store to VRAM

Code: [Select]

Bottom Storage of PC Sprites
$13/8B71 AD F0 02    LDA $02F0  [$11:02F0]   A:A800 X:002F Y:0001 P:envmXdIzC ;Load how many bytes to send to VRAM
$13/8B74 85 05       STA $05    [$00:4305]   A:0080 X:002F Y:0001 P:envmXdIzC
$13/8B76 A9 00 61    LDA #$6100              A:0080 X:002F Y:0001 P:envmXdIzC ;Load where to store sprites into VRAM
$13/8B79 8D 16 21    STA $2116  [$11:2116]   A:6100 X:002F Y:0001 P:envmXdIzC
$13/8B7C AD ED 02    LDA $02ED  [$11:02ED]   A:6100 X:002F Y:0001 P:envmXdIzC ;Load pointer to PC sprites
$13/8B7F 18          CLC                     A:A800 X:002F Y:0001 P:eNvmXdIzC
$13/8B80 69 00 02    ADC #$0200              A:A800 X:002F Y:0001 P:eNvmXdIzc ;Add $200 to get bottom piece of sprites
$13/8B83 85 02       STA $02    [$00:4302]   A:AA00 X:002F Y:0001 P:eNvmXdIzc
$13/8B85 8C 0B 42    STY $420B  [$11:420B]   A:AA00 X:002F Y:0001 P:eNvmXdIzc ;Store to VRAM
Is there anything wrong with this routine?  I'm really confused on why it's causing screen flickering.  It seems to only happen when it STORES to VRAM.  So if I remove the 8C 0B 42 on both, obviously nothing gets stored but it ends up not screen flashing anymore which singles it out to be this area.  Even if I just use ONE of them to store to VRAM, it causes screen flicker.. I don't understand why.

[Disch]

Obvious questions:

1)  Is your DMA taking too long and spilling outside of VBlank?

2)  Is your DMA configured properly? (looks like you're using DMA channel 0 for both .. are both DMAs doing the exact same copy?)


EDIT:

Looks like you are loading the number of bytes to copy and storing it to $05, but you never seem to be storing it to the actual DMA reg ($4305-$4306)  Note that you must do this before every DMA, since that reg will be zero'd after the DMA is complete.


EDIT 2:

You'll have to set $4302-4304 to specify the source address, as well.  And again you'll have to do that before each DMA since the DMA process will mangle that value.


Basically you need to actually configure the DMA before you perform it.  It does not look like you're doing that at all.

[justin3009]

I'm actually doing all of that, most notably in the first chunk of code which does ALL of that.  I've copied and pasted code into the second chunks as well and altered what values need to be done and it still causes some odd flashing.

I'm fairly certain it's not taking too long as it's in the 'exact' same spot the original routine was and is actually storing the same amount of data.  The only time I've noticed it flashes bad is when I perform a Super Jump and start moving across the screen, it'll flash all rainbowy for split second about 2-3 times.

I think the only thing that I MAY not be doing is the DMA channel.. which might be the issue.  I removed the bottom storage of code and the flickering stopped.. so I believe it's the DMA channel.

(Tested)
Yep, it seems THAT fixed the flickering issue with the PC sprites anyway.. but now when it's storing the Flask and stuff it's flickering again.  I assume I'd just store it to another DMA channel?

[Disch]

Whoops!   I didn't realize you had direct page set to $4200.  My mistake.   

It shouldn't matter which DMA channel you're using as long as you're not clobbering something another part of the game is using (like HDMA).

[justin3009]

Interesting..  Yeah this game uses quite a bit of HDMA so that might be a problem.

The original game used 3 DMA channels and my routine was only using 1.. which caused that problem lol.

I'm actually kind of baffled at the moment though.  I'm messing with the Flask/POW/Crystal storage now and if I remove the bottom storage but keep the TOP portion storing in Channel 0 like the first PC sprites.. it causes no flickering at all.  I add back the bottom storage and it causes flickering.  If I change the storage of the BOTTOM half to Channel 1, it'll cause flickering again.

Is there any reason why removing half the routine would cause no flickering but adding the 2nd half back with a different channel does cause it?  I'm assuming maybe that it's spilling outside of VBlank at this point.

[Disch]

An easy way to check to see if you're spilling out of VBlank:

- set the "force blank" bit before DMA
- clear it after DMA

If your DMA is spilling over, this will remove the flicker, but will screw up the scroll and/or result in a few blank scanlines at the top of the screen.

[justin3009]

I feel a bit dumb asking all these questions, but better to learn it now I suppose.  How exactly do you set a 'force blank' and clear it after?  I don't quite understand what to do for that.

I'm starting to think it may not be an issue with spilling though.. not entirely certain though.  The 'DMA' is spewing this out.

DMA[0]: CPU->PPU Mode:1 0x16E840->0x2118 Bytes:C0 (inc) V:231 VRAM: 67A0 (1,0) word

There's still a decent amount of scanlines left so I don't think it'd be a problem.

Edit: Then again.. this is the highest one I saw.
DMA[1]: CPU->PPU Mode:1 0x7F0846->0x2118 Bytes:3C (inc) V:259 VRAM: 4809 (32,0) word

Edit 2: This whole game seems like it's ran on DMA issues.  Even in the original the screen would flicker quite consistently depending on the circumstances.

[Disch]

I feel a bit dumb asking all these questions, but better to learn it now I suppose.  How exactly do you set a 'force blank' and clear it after?  I don't quite understand what to do for that.

It's a bit setting in one of the very first PPU regs.  Ctrl+F the doc for "force blank" and you'll find it soon enough.  I'm not on my home machine right now and I don't have the doc handy so I can't check myself.

DMA[0]: CPU->PPU Mode:1 0x16E840->0x2118 Bytes:C0 (inc) V:231 VRAM: 67A0 (1,0) word

There's still a decent amount of scanlines left so I don't think it'd be a problem.

Edit: Then again.. this is the highest one I saw.
DMA[1]: CPU->PPU Mode:1 0x7F0846->0x2118 Bytes:3C (inc) V:259 VRAM: 4809 (32,0) word

It's been a while since I looked at SNES timing so don't know for sure.  IIRC it's the same as the NES, so there should be 262 lines total, right?  In which case V=259 is pretty much right at the end of VBlank so that is almost certainly spilling over.

[justin3009]

Yep, I'm fairly certain that's what the problem is.  It's spilling over and causing the flickering.  The issue is how exactly do I 'fix' that?

In other games, I'd actually find another section that'd store into VRAM later down the road and use that there but this game seems to be completely different on how it handles VRAM storage.

[Disch]

First thing is make sure you're doing all your time-critical stuff FIRST before doing other stuff.  That is, do all your drawing immediately after NMI, and only after your drawing is complete do you move on to other things that can be done any time (like logic or whatever).

After that you'll have to cut down on how much time it takes to do the drawing.  Like do any prepwork and stuff before NMI so when VBlank starts you can get drawing done as fast as possible.

After than you just have to cut down on how much drawing you're doing.



There's no easy answer to that.... it really depends on what the game is doing and how much actually needs to get done vs. how much you can postpone.

[justin3009]

That's what I figured... From what I'm seeing, it looks like all of the DMAing that's going on is quite literally all the sprite storage for the PC and that darn POW/Flask/Crystal graphics.  I could honestly probably remove the Crystal graphics though and have them load only during a boss fight.  Seems like a waste to have all that extra space wasted by it when it's never honestly used usually on screen the same time as the others.

(Just checked something)

On this.. interesting note.  From what I saw, there was code right after the NMI to force VBlank I believe.  I ended up removing it as a test to see if it'd harm anything.  Instead, it actually fixed the flashing issue.  Everything is still working perfectly fine as well in all aspects so I'm honestly confused on why it caused no side effects.  I have it noted down and bolded in my change log just in case but it seems to have fixed a vast majority of the flashing issues.