nesdev.com
http://forums.nesdev.com/

Something on Nestopia board ($2007 write during rendering)
http://forums.nesdev.com/viewtopic.php?f=3&t=2182
Page 1 of 1

Author:  85cocoa [ Mon Oct 09, 2006 11:39 pm ]
Post subject:  Something on Nestopia board ($2007 write during rendering)

Just to make sure everyone is aware:

http://www.bannister.org/ubb/ultimatebb ... p=1#000005

There appears to be a request to get more information on what writes to $2007 do during rendering, specifically in the context of the game "Saint Seiya - Ougon Densetsu Kanketsu Hen."

Author:  Zepper [ Tue Oct 10, 2006 8:46 am ]
Post subject: 

Go hack the game, trace it... *bump*

Author:  85cocoa [ Wed Oct 11, 2006 1:07 am ]
Post subject: 

Sorry, I don't have the skills to do that, nor the equipment to HW test, so unless a dev has something to contribute, I will allow this thread to be locked.

Author:  kevtris [ Wed Oct 11, 2006 8:37 pm ]
Post subject:  Re: Something on Nestopia board ($2007 write during renderin

85cocoa wrote:
Just to make sure everyone is aware:

http://www.bannister.org/ubb/ultimatebb ... p=1#000005

There appears to be a request to get more information on what writes to $2007 do during rendering, specifically in the context of the game "Saint Seiya - Ougon Densetsu Kanketsu Hen."


I'm not sure about that game, but writing to 2007 during rendering is very bad news. There appears to be two "control units" so to speak on the PPU that can operate the memory interface.

The main "rendering" control interface, and the 2007 read/write control interface. The two are simply OR'd together on the control lines. It is possible to do both a read AND write cycle at the same time because of this. I used my "3 in 1 tester" to monitor the PPU's address, data, and control lines during rendering to see what happened when reads and writes were performed during rendering.

The result is very unpredictable as you can imagine, since the timing of the CPU read/write and the timing of the PPU data fetch both come into play. The net result of writing during rendering could be corruption of at least 2 memory locations and possible corruption of the address counter/pointer. Reading isn't so bad but it too could corrupt the address counter during rendering and if nothing else, cause glitchy video due to improper data being fetched for display.

Author:  dvdmth [ Thu Oct 12, 2006 7:12 am ]
Post subject: 

The game in question here is apparently trying to write to $3F00-3FFF during rendering. I suspect that side-effects would be minimized here since writes in this range don't go out into VRAM. On the other hand, palette memory may be adversely affected. Has any testing occurred to this regard?

Author:  85cocoa [ Fri Oct 13, 2006 12:38 am ]
Post subject: 

So Marty's diagnosis of the game is probably wrong?
(EDIT: Oops, I forgot about the way the PPU regs are mirrored. What I meant is that real game companies probably wouldn't try such a dangerous programming technique, so maybe the bug is really related to timing or something else.)

Author:  Marty [ Fri Oct 13, 2006 5:59 am ]
Post subject: 

Yeah, it could be related to timing as well (but that's still risky business), resulting in VRAM address trashing. I noticed that delaying the $2007 write by 4 PPU clocks (no less) also fixes the game. Incidentally, Micro Machines will cause screen-shaking in the finished course screen if $2001 writes (BG/SP enable) are delayed by 1 PPU clock. I guess PPU internals and different duty cycle timings plays a large role here. Makes me I wonder if there are more quirks for certain timed PPU register reads/writes, resulting in special behaviour similiar to the ones for the VBL flag and NMI supression.

Author:  Zepper [ Sat Oct 14, 2006 8:57 am ]
Post subject: 

kevtris, did you analyse the cartridge board? Just to be sure we're not speaking of an emulator "obscure" bug. -_-;; You know, if this latency occurs in the NES, so it's ok.

Author:  kevtris [ Sat Oct 14, 2006 7:49 pm ]
Post subject: 

dvdmth wrote:
The game in question here is apparently trying to write to $3F00-3FFF during rendering. I suspect that side-effects would be minimized here since writes in this range don't go out into VRAM. On the other hand, palette memory may be adversely affected. Has any testing occurred to this regard?


Oh, that's "legal" so to speak... if you time your writes juuuuust right, you can update the palette mid-frame. Micromachines does this as I think was already said. Micromachines uses the 2004 read to synch up, and it's insane critical. Any little timing screwup will cause you to bleed off into rendering which can cause graphic corruption.

Author:  Bananmos [ Sun Oct 15, 2006 1:02 am ]
Post subject: 

Quote:
Oh, that's "legal" so to speak... if you time your writes juuuuust right, you can update the palette mid-frame. Micromachines does this as I think was already said. Micromachines uses the 2004 read to synch up, and it's insane critical. Any little timing screwup will cause you to bleed off into rendering which can cause graphic corruption.


Yes it's legal, but ONLY if you turn off rendering thru $2001, in which case anything legal in vblank should be as legal mid-frame. Though you have to keep in mind that pointing $2006 to the palette registers will output the color pointed to rather than BG0. Micro Machines does turn off rendering before doing it's palette updates, and I am pretty sure there's no other way to do it.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/