It is currently Sat Nov 18, 2017 12:51 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Sun Dec 18, 2016 12:00 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2358
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.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 12:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
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.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 12:14 pm 
Offline

Joined: Thu Aug 28, 2008 1:17 am
Posts: 591
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


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 12:23 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
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


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 3:08 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 582
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
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


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 8:05 pm 
Offline
User avatar

Joined: Sun Dec 13, 2009 11:37 am
Posts: 208
Location: Wisconsin
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).


Top
 Profile  
 
PostPosted: Wed Dec 28, 2016 9:01 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19225
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat Feb 11, 2017 10:34 pm 
Offline
User avatar

Joined: Wed Jul 13, 2011 6:51 am
Posts: 395
Location: Brasilia, Brazil
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.


Top
 Profile  
 
PostPosted: Sat Feb 11, 2017 10:58 pm 
Offline

Joined: Mon Nov 10, 2008 3:09 pm
Posts: 431
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.


Top
 Profile  
 
PostPosted: Thu Feb 16, 2017 5:46 am 
Offline
User avatar

Joined: Mon Jan 01, 2007 11:12 am
Posts: 203
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


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

All times are UTC - 7 hours


Who is online

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