It is currently Sun Dec 17, 2017 2:38 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: OAM and palette decay
PostPosted: Tue Dec 14, 2004 1:17 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19354
Location: NE Indiana, USA (NTSC)
In posts to the nesdev Yahoo! Group, it is suggested that OAM and the palette may be DRAM that decays rapidly.

In message 1751 Andrew Davie wrote:
So we sprayed it with freon and lo and behold, the sprites stopped
flickering. I figured it out shortly thereafter - the sprites are loaded
into DYNAMIC ram. The Three stooges was being miserly with what cpu cycles
it used, so it only did the update whenever it really HAD to. And it turns
out, when this particular variant of the NES got hot, the time the dynamic
ram held its contents got shorter and shorter. [snip]
I do believe we made modifications to the stooges, too, so that it wasn't
pushing the machine so much.


In message 3506 Kevin Horton wrote:
A word on the palette RAM. It is dynamic, and its value decays quite
quickly if PPU rendering is not on.


In a typical render cycle (wait for vblank, turn off PPU, write VRAM, do OAM DMA, turn on PPU), do OAM and the palette really decay to the point where they must be rewritten every vblank? I did a few tests on my frontloader using games with a Seal, jiggling the Game Pak at various points:
  • I tried Super Mario Bros./Duck Hunt in SMB mode and removed the Game Pak during gameplay. The sky stayed blue (blinking with black because of CIC resets) for a long time.
  • I tried Nintendo's Tetris for NES (NES-EI-USA). I held down on the cartridge and let it rise slowly, just enough to halt the CPU with a bad opcode on the PRG bus without affecting the CHR bus or the CIC chip. Once I got the program to stop in the middle of a note that continued playing, showing that at least some of the 2A03 was still being clocked, and the PPU kept on drawing the same image. Once I got the program to stop in what appeared to be the middle of a VRAM transfer, which I could discern because the background scrolled up and to the left a bit. Even without constant refreshing from the CPU, it appears the OAM and palette got refreshed by the PPU while the screen was turned on, even for several seconds.
I'm planning a clone of Zoop with a screen update that, in the worst case (the color bomb), pushes the machine to the point where it already has to cut off rendering a few scanlines early, triggered by sprite 0.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Dec 14, 2004 2:57 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3488
Location: Indianapolis
I think leaving the sprites displayed probably would keep the OAM refreshed, as long as the NES would be accessing every single byte of it every frame.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 4:05 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19354
Location: NE Indiana, USA (NTSC)
Thanks. I ought to make a demo for measuring how long the PPU's internal OAM and palette RAM maintain their contents during forced blank (lda #0 sta $2001). Are there any special considerations for preparing a ROM to run on Squeedo, other than that it uses CHR RAM and 4-screen mirroring?


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 5:16 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Yeah, I really had to wonder about this oam decay thing ever since the first time I heard about it.

Who found it out? From what it sounds like, it really does seem to decay its values, but I've never seen it happen, even on my carts that are really screwy and freeze the game due to bad connection.

Though, it'd make sense if that this would happen when the screen rendering is turned off.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 5:56 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3488
Location: Indianapolis
tepples wrote:
Are there any special considerations for preparing a ROM to run on Squeedo, other than that it uses CHR RAM and 4-screen mirroring?


The biggest thing I've noticed is using the reset button, currently the PIC is reset only at power-on. So if you hit reset, the NES will be stuck in the currently selected PRG bank. A work-around for that is to have a soft-reset routine in all your other banks to point to the main bank/reset routine. Or just use the power button instead.

Also, the first 4kB of CHR-RAM doubles as the nametable memory. So you can only use half of the first CHR page for tiles. The other 3 CHR pages are unaffected.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Dec 15, 2004 6:51 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
Memblers wrote:
The biggest thing I've noticed is using the reset button, currently the PIC is reset only at power-on. So if you hit reset, the NES will be stuck in the currently selected PRG bank.


The same will happen with nearly ALL other mappers, including the MMC1 and MMC3 (the MMC5 will detect soft resets because the M2 line suddenly goes silent).

Memblers wrote:
A work-around for that is to have a soft-reset routine in all your other banks to point to the main bank/reset routine. Or just use the power button instead.


All games which use 32KB PRG ROM switching do this, since the bank selected on POWERUP is indeterminate as well.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jul 19, 2005 7:55 pm 
Does anyone have a MMC5 cart handy (or any of a number of pirate multicarts that do the same thing), and would be willing to look at how their M2 or CLK watching circuit works?

Presumably M2 toggles keep a capacitor connected to the mapper /clear pin charged up, and a weak pull down drains it if M2 stops cycling, until it goes low enough to trigger a mapper reset, but I don't know what sort of values to use for R and C on my cart and I don't have access to my game collection right now.


Top
  
 
 Post subject:
PostPosted: Tue Jul 19, 2005 7:56 pm 
Err, and a diode from M2 to the cap, otherwise it'd drain instantly...


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: DRW and 9 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