nesdev.com

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.

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.

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

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

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

_________________
http://www.tmeeco.eu

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

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.


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.

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.

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.