OAM reading on Dendy (test pictures)

[Eugene.S]

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:

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).

OAM_Read_test and OAM_Read_VBL_wait_test: all passed.


OAM_Stress: passed.


all-in-one shots (19Mb)

I've read nintendulator history commits, and saw Quietust wrote about Dendy:

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.

[Drag]

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.

[lidnariq]

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

[tepples]

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.

[thefox]

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.

[tepples]

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.

[Drag]

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.

[Quietust]

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.

[rainwarrior]

Out of curiosity, is DRAM slower just because of the interruptions usually required for the refresh process, or is all access slower?

[lidnariq]

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.

[l_oliveira]

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.

[Quietust]

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).

[l_oliveira]

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.