DRAM refresh cycles on Genesis and NES

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

DRAM refresh cycles on Genesis and NES

Post by psycopathicteen »

I know that on the SNES, DRAM refresh halts the CPU for 40 master cycles every line. Do the Genesis and NES CPUs have to be halted during DRAM refresh, or do they use some other kind of DRAM that doesn't need halting the CPU.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: DRAM refresh cycles on Genesis and NES

Post by lidnariq »

NES CPU doesn't use DRAM.

The sprite memory in the PPU is DRAM, but its refresh is the same as evaluation.

The FDS uses DRAM, but it seems to be using some kind of hidden refresh.
tomaitheous
Posts: 592
Joined: Thu Aug 28, 2008 1:17 am
Contact:

Re: DRAM refresh cycles on Genesis and NES

Post by tomaitheous »

The Genesis system ram uses special DRAM that interfaces like SRAM (I forget the name of it; PSRAM? I dunno). There is some cycle delay for the internal refresh, but I don't remember the details. I just remember the effect being being almost non-existent.

I thought I remember the SMS using DRAM, but that could be just be me remembering that the z80 has a built-in dram controller - and associating it as such.

PCE is SRAM (main memory, video memory). Even though the PCE 65x variant processor runs at 7.16mhz - it can run roms and ram just fine at 120ns. The PCE's Arcade Card uses DRAM for the extended 2048kbytes of ram, but the refresh is hidden (because there's no way to stall/delay the CPU from the cart port; that can only be done via the back plane interface. /RDY isn't available on the front port for whatever reason).
__________________________
http://pcedev.wordpress.com
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: DRAM refresh cycles on Genesis and NES

Post by lidnariq »

SMS seems to use three µPD4168C ICs, which the datasheet describes as "XRAM" ... which appears to be PSRAM, or maybe prior art for 1T-SRAM
User avatar
TmEE
Posts: 960
Joined: Wed Feb 13, 2008 9:10 am
Location: Norway (50 and 60Hz compatible :P)
Contact:

Re: DRAM refresh cycles on Genesis and NES

Post by TmEE »

SMS and MD both use PSRAM chips for main memory. SMS has no performance impact as it is built into CPU and the refresh strobe of the memory is pulsed every M1 cycle of the CPU.
How it works on MD : http://gendev.spritesmind.net/forum/vie ... 829#p28829
User avatar
whicker
Posts: 228
Joined: Sun Dec 13, 2009 11:37 am
Location: Wisconsin

Re: DRAM refresh cycles on Genesis and NES

Post by whicker »

Just to add/summarize:

The Genesis/Megadrive has a 68000 CPU.
It's fairly rare on other CPUs, but the 68K series has an input pin called DTACK (active low).
DTACK = data acknowledge.

If memory or a peripheral isn't ready for a read or write, it simply doesn't assert DTACK and the CPU will just wait.

This was really great for things like slow memory or 1 Mhz max accesses to PIO chips and such, because you have the flexibility to just delay however many clocks variably and then say the data is ready, instead of assuming the data is going to be there after a certain number of clocks.

Now this also brings complications, because when accessing an undefined memory range that won't assert DTACK, you need a watchdog timer to eventually trigger the BERR (Bus Error) pin to cause an interrupt.

I miss the 68K. It made so much sense. (Except for bombing out on unaligned address accesses).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: DRAM refresh cycles on Genesis and NES

Post by tepples »

whicker wrote:It's fairly rare on other CPUs, but the 68K series has an input pin called DTACK (active low).
DTACK = data acknowledge.

If memory or a peripheral isn't ready for a read or write, it simply doesn't assert DTACK and the CPU will just wait.
The 6502 has that as well for reads, where pulling RDY (ready) low during a read halts the CPU until it returns high. This is what the DMA controllers on the 2A03 (NES CPU) and 5A22 (S-CPU) do to stop execution.
I miss the 68K. It made so much sense. (Except for bombing out on unaligned address accesses).
One could write an exception handler that emulates unaligned access, just as one writes a handler for the "Fxxx instruction" that emulates some model of FPU. But then an unaligned access more likely indicates a corrupt pointer, much as a bus error does.
User avatar
l_oliveira
Posts: 409
Joined: Wed Jul 13, 2011 6:51 am
Location: Brasilia, Brazil

Re: DRAM refresh cycles on Genesis and NES

Post by l_oliveira »

whicker wrote:I miss the 68K. It made so much sense. (Except for bombing out on unaligned address accesses).
Even that makes sense(hardware wise). MC68000 has no A0 address line. Instead it use a pair of strobes (UDS, LDS) to access 8 bit stuff. Specific instructions for 8bit accesses cause those to operate. 8bit operations can access odd addresses without problems.

When using normal word access it can't access odd addresses due to the bus construction (no A0) and will throw an address error exception.

Apparently, later they found a way of allowing odd address accesses and the full 32bit processors in the family can actually do it...

I don't know how that works.
AWJ
Posts: 433
Joined: Mon Nov 10, 2008 3:09 pm

Re: DRAM refresh cycles on Genesis and NES

Post by AWJ »

l_oliveira wrote:
whicker wrote:I miss the 68K. It made so much sense. (Except for bombing out on unaligned address accesses).
Even that makes sense(hardware wise). MC68000 has no A0 address line. Instead it use a pair of strobes (UDS, LDS) to access 8 bit stuff. Specific instructions for 8bit accesses cause those to operate. 8bit operations can access odd addresses without problems.

When using normal word access it can't access odd addresses due to the bus construction (no A0) and will throw an address error exception.

Apparently, later they found a way of allowing odd address accesses and the full 32bit processors in the family can actually do it...

I don't know how that works.
The later 68K processors split word-straddling bus accesses into two operations, just like x86 chips do.
User avatar
HardWareMan
Posts: 209
Joined: Mon Jan 01, 2007 11:12 am

Re: DRAM refresh cycles on Genesis and NES

Post by HardWareMan »

And true: 32 bit access must be word aligned as 16 bit access, because M68000 has only 16 bit data bus and split 32 bit access into 2 of 16 bit access. For M68000 only 8 bit access can be not aligned by word.
Image
Post Reply