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

DRAM refresh cycles on Genesis and NES
http://forums.nesdev.com/viewtopic.php?f=23&t=15261
Page 1 of 1

Author:  psycopathicteen [ Sun Dec 18, 2016 12:00 pm ]
Post subject:  DRAM refresh cycles on Genesis and NES

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.

Author:  lidnariq [ Sun Dec 18, 2016 12:01 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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.

Author:  tomaitheous [ Sun Dec 18, 2016 12:14 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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

Author:  lidnariq [ Sun Dec 18, 2016 12:23 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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

Author:  TmEE [ Mon Dec 19, 2016 3:08 am ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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

Author:  whicker [ Wed Dec 28, 2016 8:05 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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

Author:  tepples [ Wed Dec 28, 2016 9:01 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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.

Quote:
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.

Author:  l_oliveira [ Sat Feb 11, 2017 10:34 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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.

Author:  AWJ [ Sat Feb 11, 2017 10:58 pm ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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.

Author:  HardWareMan [ Thu Feb 16, 2017 5:46 am ]
Post subject:  Re: DRAM refresh cycles on Genesis and NES

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

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