Why? Because any SRAM chip over 2MB are only in BGA package and cost ridiculously much. I would've preferred to have 4MB, but 2MB seems to be all I can find at a reasonable price, and even then, it's a TSOP package.

As I said above:

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, I know. I'm not going to stream it; just pointing out that I'd like more RAM.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I see! I was not aware of these. Thank you for letting me know.

I did mention them a few posts back.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I think I read somewhere that you're allowed to have more than one RAM chip in a system. :-)

Maybe you could explain a bit more about to what use all this RAM and storage, in a single address space, is going to be put. I'm am pretty mystified here about why just loading new data over old data in RAM (as levels change, or whatever), as game consoles traditionally do (via bank switching, in the case of ROM-based systems), would be an issue.

Note that this loading time can be made to be pretty fast, if you're motivated to do so. If you build a controller that can DMA the data directly into memory, that will be able to read in 512 KB of data in less than half a second at 10 MHz.

Regardless, no matter how you load the data it's almost certain to be faster than trying to make single address space reads generate SD card reads, to make it look like random-access memory. You seem to be implying that speed isn't an issue, but I don't see how it cannot be an issue when you're talking about megabytes of data.

_________________
Curt J. Sampson - github.com/0cjs

Just to add a data-point here: I have an SD card talking to an ATmega which talks to my 6502/816 systems ... The ATmega runs the SD clock (I am using SPI mode which is all I think you can use from an ATmega) at 8Mhz. That gives me a theoretical maximum transfer speed of 1Mbyte/second. (there is a tiny bit of latency per 512 byte block, but that's insignificant here).

The bottleneck for me is then getting that data into the 6502/816 - partly because I made a hardware optimisation so the 8-bit bus I'm using from the ATmea to the SRAM is bit-flipped, so I have to pass each byte through a lookup table, and partly (possibly) because I'm doing it in C on the ATmega. I do get a transfer rate of about 33KBytes/sec into and out of 6502/816 RAM and that's good enough for me.

If you could 'mmap' (in Unix terms) an SD card into '816 address space, then that would be pretty neat, but I fear the hardware and software required to do it would far exceed the benefits gained, other than as an exercise, but i that's your aim, then go for it!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I think we might be seeing interactions here between the expected software design and the present hardware design. Skylie33, I'm not even sure we're using the same terminology when you say 'bulk storage' so that's a bit of an obstacle too.

I ask the following questions not to be pointed, or to criticise, but because I think the answers will illuminate what it is you're aiming to build.

It might be helpful to tell the story: what applications does the user run, how do they run them, where do they come from?

I'm still quite fuzzy on the idea of several banks of non-volatile storage, as to how they get used and what for. The questions in my mind are: When written? From where? When read? For what purpose?

Suppose for a minute you only had RAM in those high banks. Can you say what difference that would make?

Actually, I have changed my schematic to only have RAM in those high banks. Maybe I wasn't being clear. As I said before, the reason for having non-volatile memory in the higher banks was because I thought of putting the entire OS in there, and I had no clue how big it was going to end up being. Because of the wise people from here however, I realized that allocating 64K of the RAM for the OS would be more than it'd ever need.

The applications that the user might run could be games or utilities. I'm a fan of UNIX, so I'm going to have some commands with similar names and functionality. The idea is for the programs to be loaded from an SD card into RAM, and then get executed. If there *is* a faster way to do this, then I'd be happy to know about it. Games can be quite big -- Most games on the SNES were at least over a megabyte in size, and my hardware is about 3x as powerful.

Thanks - that helps!

I don't know much about the SNES, but I wonder how much of that data was tile & sprite graphics and sound samples/music?

My '816 system runs a simple command line OS that's very similar to Acorn MOS. Can load programs from SD card and so on, however right now I only expect to run programs in bank 0 - the rest of RAM (512K in total) is for data and interpreted code with the interpreter living in bank 0. It runs BBC Basic quite well, but only in 6502 emulation mode right now.

If you want to use SD efficiently from the 65xx side, then you might need some sort of hardware SPI driver for it. Bit-banging is not going to be fast enough although it might approximate old-school floppy drive speeds. There have been some CPLD designs in the past.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Probably quite a bit I'd imagine.



That makes sense. The first test I do with it will probably be bit-banging, but obviously it isn't going to be fast enough.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hmm. 30 isn't too bad for bit-banging, honestly. If the program were 2MB, it'd take.. 66 seconds? A little slow I suppose, but doable for now. That's also assuming everything is loaded into RAM at once; but I feel like that'd be the best option for speed.