It is currently Fri Dec 15, 2017 6:39 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Tue Feb 03, 2015 8:15 am 
Offline
User avatar

Joined: Sat Apr 18, 2009 4:36 am
Posts: 260
Location: Russia
Quote:
OAM reading on PAL NES - all test ROMs were taken from here, read first!
Test ROMs request by me

Hi, Nesdev. I need to clarify all unknown values here: http://wiki.nesdev.com/w/index.php/Clock_rate
Also i can confirm that red and green emphasis bits are swapped on Dendy same as PAL NES.

I've tested thefox's and blargg's ROMs on my custom-made Dendy based on Famicom AV PCB.
Here is the results:

OAM DECAY TEST ("original", take1, take2, take3, take4, take5). Seems it has correct NTSC-like behavior:
thefox wrote:
It uploads a bunch of sprites to OAM and enables rendering. When A is held down, rendering is kept disabled, which presumably should cause OAM to decay. However, on my PAL NES I wasn't able to make OAM decay no matter how long I kept the button pressed, the sprites always came back pristine. The ROM was tested on NTSC NES as well (thanks to Pasky), and there it functioned as expected (sprites started disappearing, which must mean that the bits tended towards ones).

Image Image Image
Image Image Image

OAM_Read_test and OAM_Read_VBL_wait_test: all passed.
Image Image

OAM_Stress: passed.
Image

all-in-one shots (19Mb)

I've read nintendulator history commits, and saw Quietust wrote about Dendy:
Quietust wrote:
the pre-render scanline difference is permissible, since nobody knows exactly how it works anyways

I can do tests on real hardware. I still want any test roms to clarify Dendy behavior.


Top
 Profile  
 
PostPosted: Tue Feb 03, 2015 6:06 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
My understanding of the OAM decay is that the sprite OAM inside the NES is DRAM instead of SRAM. DRAM has a faster response time, but its contents need to be periodically refreshed or else they'll decay. The PPU accesses memory much faster than the CPU does, so that could be why DRAM was used.

Later revisions of the NES may have been built during a time where SRAM response was improved, to where SRAM could be used in place of the DRAM. This is all just my speculation, but this is a possible reason for why the sprites don't decay on some units where they do on other units.


Top
 Profile  
 
PostPosted: Tue Feb 03, 2015 6:19 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
The PAL 2C07 is known to not decay because OAM evaluation can never be fully disabled. Hence why one can only DMA for the first 20 scanlines after NMI there.

It looks like in the Dendy, they either keep running OAM evaluation for the entire 51 POST-render scanlines so that its contents don't decay, or they are using DRAM with a substantially longer refresh time (4.6ms) than the 2C02's 1.3ms. I guess that's an obvious test: see if OAM can be usefully modified sometime around 260 scanlines after NMI.

edit:fixed typo


Last edited by lidnariq on Tue Feb 03, 2015 8:30 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Feb 03, 2015 8:01 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
The 51-line period on Dendy is post-render, after the picture and before the NMI. It corresponds to the 1-line post-render idle period after the picture on authentic consoles.


Top
 Profile  
 
PostPosted: Tue Feb 03, 2015 11:32 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2983
Location: Tampere, Finland
Drag wrote:
My understanding of the OAM decay is that the sprite OAM inside the NES is DRAM instead of SRAM. DRAM has a faster response time, but its contents need to be periodically refreshed or else they'll decay. The PPU accesses memory much faster than the CPU does, so that could be why DRAM was used.

I have always been taught that SRAM = fast, DRAM = slow. I'm not sure if the opposite has been true at some point in the past, but the main reason to use DRAM nowadays (and probably back then, too) is that it's cheaper. And the reason CPU caches use SRAM is that it's faster.

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


Top
 Profile  
 
PostPosted: Wed Feb 04, 2015 9:52 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
By the time of the GameCube, MoSys figured out how to make DRAM fast by striping data across a bunch of small independent DRAM banks, plus some SRAM cache in front to hide the refresh. It's called 1T-SRAM, and both the GameCube and the Wii have 24 MiB of the stuff.


Top
 Profile  
 
PostPosted: Thu Feb 05, 2015 3:31 am 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
thefox wrote:
Drag wrote:
My understanding of the OAM decay is that the sprite OAM inside the NES is DRAM instead of SRAM. DRAM has a faster response time, but its contents need to be periodically refreshed or else they'll decay. The PPU accesses memory much faster than the CPU does, so that could be why DRAM was used.

I have always been taught that SRAM = fast, DRAM = slow. I'm not sure if the opposite has been true at some point in the past, but the main reason to use DRAM nowadays (and probably back then, too) is that it's cheaper. And the reason CPU caches use SRAM is that it's faster.

I was just guessing. I only knew DRAM needed to be refreshed while SRAM didn't. I couldn't think of any possible reason to use DRAM over SRAM unless it was faster, I didn't consider the cost of materials or circuit complexity, aside from DRAM probably being less complex and thus probably faster (which, counter-intuitively, it isn't?) Anyway, it's all moot because my OAM decay hypothesis was wrong anyway. :P


Top
 Profile  
 
PostPosted: Thu Feb 05, 2015 5:37 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
I highly suspect that DRAM wasn't used because of speed, but because of size - 2112 bits of SRAM would've made the die significantly larger and thus more expensive to produce.

To see the difference, compare the bit density of palette RAM (156 bits) to that of OAM, and you'll see that it's a lot larger per bit.

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


Top
 Profile  
 
PostPosted: Thu Feb 05, 2015 12:10 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5898
Location: Canada
Out of curiosity, is DRAM slower just because of the interruptions usually required for the refresh process, or is all access slower?


Top
 Profile  
 
PostPosted: Thu Feb 05, 2015 1:55 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
It's only necessarily slower because of the background resources for refresh. Manufacturers sometimes stretch the DRAM quads much larger, putting more parasitic capacitance (without anything to directly drive it) on the row/column lines, so individual accesses can be slower too.


Top
 Profile  
 
PostPosted: Sun Feb 08, 2015 9:39 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
DRAM is slower because the address bus is multiplexed. You need more cycles to set up the address to read than on SRAM (whose address bus goes almost straight from the CPU to the RAM cell itself). On DRAM you need to set the row and column you will read or write to before the actual access can happen. On any "sane" DRAM design any access from CPU will take preference over refresh (unless the DRAM is used in something which cannot absolutely be stopped, like for example if the said DRAM is also used for video memory as in the C64 or Sinclair Spectrum. Because in that case you need to feed the raster rendering process with data you will instead stop the CPU from accessing the DRAM).

So you can think of DRAM as a computer bitmapped screen. Before you can toggle a pixel you need to set both the X and Y coordinates (in hardware level).

On SRAM the CPU see it as a straight line (DRAM refresh/RAS/CAS circuitry is supposed to make that for the DRAM too so the CPU see it like this).

Newer memory technologies like SDRAM have a much, much higher clock but their latency is high because they still use multiplexing to save traces requirement on the board design.

@the OP: very interesting post, thanks for posting.


Top
 Profile  
 
PostPosted: Sat Feb 14, 2015 8:08 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
l_oliveira wrote:
DRAM is slower because the address bus is multiplexed. You need more cycles to set up the address to read than on SRAM (whose address bus goes almost straight from the CPU to the RAM cell itself). On DRAM you need to set the row and column you will read or write to before the actual access can happen.


It should be noted that this does not apply to the PPU at all - the DRAM used for OAM has absolutely no address bus multiplexing whatsoever, and reading from it is done pretty much exactly the same as reading from palette SRAM (aside from the necessary bus precharge, of course).

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


Top
 Profile  
 
PostPosted: Sat Feb 14, 2015 8:17 am 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
Quietust wrote:
l_oliveira wrote:
DRAM is slower because the address bus is multiplexed. You need more cycles to set up the address to read than on SRAM (whose address bus goes almost straight from the CPU to the RAM cell itself). On DRAM you need to set the row and column you will read or write to before the actual access can happen.


It should be noted that this does not apply to the PPU at all - the DRAM used for OAM has absolutely no address bus multiplexing whatsoever, and reading from it is done pretty much exactly the same as reading from palette SRAM (aside from the necessary bus precharge, of course).


Indeed, when I wrote that I was thinking of external DRAM chips. I would expect what you say happen with all CPUs which use dynamic memory elements to hold register data. You can tell when CPUs use these if they crash when you remove the clock source.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 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