PowerPak + Tetramino = sprite flicker

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Re: PowerPak + Tetramino = sprite flicker

Post by blargg » Sun Jan 13, 2013 9:53 pm

Bananmos wrote:
You should also rememebr that the NTSC NES has 4 possible states possible at reset/power on while the PAL NES only have 1.
You've lost me there... didn't Blargg come to the opposite conclusion in this post, which explained how there are 8 different power-up states on PAL?
Well, farther down in that thread thread I do conclude 8 different PAL synchronizations at power. Due to the frame length, a given PPU dot in the frame (beginning of VBL, first pixel, etc.) always falls at one of the same two points, half a CPU cycle apart, on a CPU cycle, for a given power up/reset. Successive PPU cycles rotate through all possible positions within a CPU cycle, but those of particular dots in the frame (VBL begin, first pixel, etc.) are always on one of these two for a given power/reset. There are 8 possible pairs of these half-cycle-spaced points, so 8 synchronizations.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: PowerPak + Tetramino = sprite flicker

Post by thefox » Sun Jan 13, 2013 11:45 pm

Speaking of different synchronizations, when can we expect an emulator author to step up and support them?
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

User avatar
Bregalad
Posts: 7768
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: PowerPak + Tetramino = sprite flicker

Post by Bregalad » Mon Jan 14, 2013 4:20 am

The other cases really confuse me though, as I don't understand how the palette entries could get corrupted unless written to?
Remember the palette is DRAM. If you use forced blanking it's content will be lost after awhile. Same goes with OAM.
I realized my game's timing is a bit too unreliable to use Blarggs sync code at the moment, since some code takes more than a frame, which also means I can't always do DMA.
You could go Kirby's adventure route and double-buffer your OAMs. But I admit that if you don't use SRAM it's quite wasteful.

Bananmos
Posts: 468
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: PowerPak + Tetramino = sprite flicker

Post by Bananmos » Mon Jan 14, 2013 3:12 pm

Remember the palette is DRAM. If you use forced blanking it's content will be lost after awhile. Same goes with OAM.
Yep, I know the contents degrade - that's why I'm always rewriting the palette in vblank even though it's quite a bit of wasted cycles. Second reason is of course the planned water effect would require it anyhow, and it generally simplifies things.

Anyway, like I said in my post-edit the issue was something else entirely, and I now have a top chr-uploading blank bar and no sprite flicker as long as I don't use sprites 2 and 3 which is good enough for my purposes. Though I'm still confused as to how disabling rendering while VADDR points to the palette corrupts it. But I guess the work of reverse engineering the PPU from the die will give us the answers some sunny day... :)

Drag
Posts: 1286
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: PowerPak + Tetramino = sprite flicker

Post by Drag » Mon Jan 14, 2013 3:46 pm

I remember going over this ages ago, and remember that it was only the first four six sprites that actually triggers the OAM corruption, and it's only when those specific sprites are intersecting the scanline where the rendering is shut off.

If you keep sprites 0, 1, 2, and 3 0 through 5 away from where you turn the rendering off, you should avoid the OAM corruption all together, unless I've misinterpreted the information.

Edit: Here is my post on the matter, and it's the first six sprites, not the first four.

Bananmos
Posts: 468
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Re: PowerPak + Tetramino = sprite flicker

Post by Bananmos » Mon Jan 14, 2013 4:52 pm

I remember going over this ages ago, and remember that it was only the first four six sprites that actually triggers the OAM corruption, and it's only when those specific sprites are intersecting the scanline where the rendering is shut off.
I tried moving sprites 1-4 to the top so they intersect the black bar where I update CHR, and it doesn't seem to give me any OAM corruption (except, I assume, for sprites 1 and 2 which are hidden behind the bar. So I still say turning screen off around dot 330 is "safe enough". But of course, you should take an empirical test for what it is and always try your code on the real target system before making any conclusions of how well it really works :)

Post Reply