65c816 address decoding help

[Skylie33]

cjs wrote:

..why not just add more RAM to your main system and write a small program that reads blocks from the SD card and copies them into that RAM?

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.

[BigDumbDinosaur]

As I said above:

Quote:

As for streaming from an SD card, I have a suspicion you wouldn't be impressed with the performance. As soon as I/O gets involved things will slow down. Better to load an entire module into core in one operation and only touch mass storage when absolutely necessary. That's how it is done in professionally-developed operating environments.

[Skylie33]

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

[GARTHWILSON]

Were you aware of the 4Mx8 10ns 5V hobbyist-friendly SRAM modules I offer?  See the front page of my site (linked below).  People have been surprised when they saw how small it was.  Here's a bare board in my hand:

WM-1PCBinHand.jpg (29.15 KiB) Viewed 1283 times

When fully loaded, there are four 512Kx8 SRAMs on each side, and there's a 46-pin header.  There are three header options.  I can supply sockets too, soldertail or wire-wrap.

I just offer these as a service to pormote our common interest.  I have a legitimate business to make sure I don't break any tax laws, but it's not a money-maker.

[Skylie33]

GARTHWILSON wrote:

Were you aware of the 4Mx8 10ns 5V hobbyist-friendly SRAM modules I offer? See the front page of my site (linked below). People have been surprised when they saw how small it was. Here's a bare board in my hand:

WM-1PCBinHand.jpg

When fully loaded, there are four 512Kx8 SRAMs on each side, and there's a 46-pin header. There are three header options. I can supply sockets too, soldertail or wire-wrap.

I just offer these as a service to pormote our common interest. I have a legitimate business to make sure I don't break any tax laws, but it's not a money-maker.

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

[BigDumbDinosaur]

Skylie33 wrote:

GARTHWILSON wrote:

Were you aware of the 4Mx8 10ns 5V hobbyist-friendly SRAM modules I offer?

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

I did mention them a few posts back.

[cjs]

Skylie33 wrote:

cjs wrote:

..why not just add more RAM to your main system and write a small program that reads blocks from the SD card and copies them into that RAM?

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.

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.

[drogon]

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

[BigEd]

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?

[Skylie33]

BigEd wrote:

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.

[BigEd]

Thanks - that helps!

[drogon]

Skylie33 wrote:

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.

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

[Skylie33]

drogon wrote:

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

Probably quite a bit I'd imagine.

drogon wrote:

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.

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.

[GARTHWILSON]

A rough cycle count from my own SPI bit-banging code looks to yield a little over 30 kilobytes (not bits) per second receiving at 10MHz.

[Skylie33]

GARTHWILSON wrote:

A rough cycle count from my own SPI bit-banging code looks to yield a little over 30 kilobytes (not bits) per second receiving at 10MHz.

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.