using DDR , SDRAM externally ?

[camp david]

is there a possibility of using ddr or sdram externally
let's say controlled by microcontroller ?

thanx in advance.

[Ttelmah]

Forget it.

You'd spend all the processor pins to generate the interface, and all the processor time handling triggering refresh (even using the auto refresh mode), and handling the interface.

On the PC there is hardware to do large parts of this. You could add this to the PIC, but it is getting more and more complex.

SRAM, no problem. Still uses a lot of pins, but dead easy to interface.

[camp david]

I need only one IC of it
and no more than (4 mbyte) 16 bit data output
I have pic18f2550 , cant it do it ?

[Ttelmah]

As I said, use SRAM.

Memories like DDR, and SDRAM, would all be 3.3v, so the interface would get even more difficult
I have to ask what you actually 'want' from the memory?.
For a large amount of storage, that it quick to interface, easy to drive, and fast to use, look at a FRAM.
I doubt if you'd have enough pins on a 2550, especially if you want to use 16bit interfacing.

[ELCouz]

[camp david]

SRAM was the first memory I thought with
but here in my country it's no more available.

let me explain what my project exactly
I need to make 'SEGA GENESIS CARTRIDGE'
'ultimate mortal kombat 3'
As you know it need a parallel memory of 4 mbyte 16 bit data bus
so I will use an sd card reader with MCU to write the data on the SDRAM
on the startup of the system.

[ELCouz]

[Ttelmah]

Look for CY62187EV30 or R1WV6416RBG.
4M*16 SRAM.
All readily available online.
You'll still have the problem of 3.3v. I can't think of any memory this sort of size that is 5v, and the number of pins needed. This is why an SPI memory will be much easier. Microchip do these. The SST26VF064B. Talk to the local Microchip dealer. With a relatively simple 5v to 3v level shifter, job done.

[camp david]

there is some types of MCU's have the ability to interfacing SDRAM
like AT91SAM9 , I'm not sure of it's availability though .

[Ttelmah]

Lot's of chips can drive SDRAM. Any of the embedded Intel Atom processors for instance. However these are all chips with unitary memory mapping (not Harvard architecture), and not PIC's.

[asmboy]

if you only need it for data storage and better yet for sequential access -check.

http://www.ccsinfo.com/forum/viewtopic.php?t=53503

it is obvious how to further extend to a greater address range using another 4040 counter. to add program code space? no way

[camp david]

Fine ..
MMC memory is really large capacity , small size , cheap , widely available
but it is serial , while genesis sega needs a parallel data output
what's the other options

* buying a cartridge online isn't included .

[Ttelmah]

It is the PIC that you were talking about connecting to the memory, not the Sega.
If you are trying to make a hardware module to plug into the Sega, then you need to be looking at hardware solutions to generate the interface (FPGA for example). If you have worked out how to make the PIC appear as the correct interface to the Sega, then the memory format being talked to by the PIC doesn't matter at all. You can read serial data from a memory and present this to a parallel interface.

There is nothing to stop you reading data serially, or in 8bit bytes, and present this to a 16bit interface. What matters is if you can generate the required interface with the PIC?. I'd doubt it. Problem is that the interface will need speed, probably many orders of magnitude faster than the PIC could simulate. I've used serial interface memories to emulate a parallel ROM. Some SPI memories can now happily be read in a few nSec, while old ROM's usually allow several hundred nSec to access. Something like an FPGA can shift data in from the faster serial memory, and latch it to a parallel connection, but it needs to be done fast. Far faster than a PIC can handle. If you are not going to get involved in hardware adaption like this, then you need to be using memories that the Sega can drive.

[camp david]

the problem isn't only with making a parallel 16 data pins
the sega will first give an address to get a specific byte
it's 4 mbytes addressing which equals to 32 pins
so the MCU should get this address and output the specefic byte .

[Ttelmah]

Exactly, which is why you need to be looking at a different solution.

You speak about 'control'. What do you want to do?.

If (for instance) it was to make a small part of a larger memory be mapped into the memory space of the Sega, then you could do this with a parallel memory (like the two I've already listed), and just directly connect this (with suitable voltage buffering), with the PIC controlling upper memory bit(s).

To directly 'control', you'd need something a huge amount faster than the PIC. The PIC s not a fast processor, and is not designed to handle large memory spaces.