Whoa, I was on another planet when I wrote my original message. I don't need 512MB, I need 512k of RAM, maybe sometimes more. I can't imagine I'd need more than 16MB. But I would like the design to be as expandible as possible. So I don't want to be limited to 512k, but a limit of 16MB-64MB would be fine.

Sorry about that. Big slip on my part and I'm not sure I can explain how that happened. I wasn't even tired at the time--but apparently distracted.



It needs to be fast, yes. Read/write XRAM.



No.



It needs to be such that any refresh is handled outside of the 8052. The 8052 may be executing code out of the large RAM bank and I can't imagine the 8052 handling the refresh if it is executing the code itself from that same RAM.



Undetermined at this point, but pin usage is going to be at a premium. My idea was to use a shift register or two to select the bank. I could do that with three I/O lines (data out, clock out, reset).



I was trying to avoid programmable logic but had come to the conclusion that there might be no way around it. If I use it I don't think it'd have any function other than an SDRAM controller.



I haven't gotten that far since I was still hoping to avoid programmable logic.



Not an issue.



Some, but not much. At this stage it might never go beyond prototype. But I don't want it to be unnecessarily expensive if I can avoid it--the more expensive it is the less likely it will go beyond prototype.



I would like the unit to be small but not microscopic. If board space becomes too large then I think I'd end up *stacking* boards rather than expanding the size of the board too much.



Preferably quickly, but it doesn't have to be instantaneous. The unit would boot from on-chip code memory and eventually load the large XRAM from an SD card. I could make the on-chip boot code wait until XRAM was ready if there is some reason it wouldn't be ready immediately.

Regards,
Craig Steiner