Hi, yes, I was thinking of memory mapped storage. That's just what made sense to me if I want all of the RAM available and then use the rest of the address space for mass storage.

The reason I want large amounts of non-volatile storage is because I had originally thought of putting all the OS code there, and then making the rest of the address space available for SD card programs. I also wanted all of the RAM to be available for the programmer. One compromise I'm willing to make is to only have the 12K of ROM and that'll load the OS into RAM. However, I do not want user programs to be loaded into RAM, because since they can vary by size, that means you'd have to carefully split up how much your program takes up and how much RAM it uses. I would prefer to "stream it" from the SD card, so to speak.

Program size doesn't matter as long as the code will fit into one bank. In the 6502 universe, a 64KB program is a monstrosity and virtually unheard-of. The largest single 6502 assembly language program I ever wrote was about 27KB of machine code—it was part of a modularized business application that en toto was around a meg of programs, all in assembly language.

If your application is something with many aspects to it (games are an example of that sort of software), it should built as a set of loadable modules, with some sort of "executive" as a common return point when a new function has to be loaded. With a reasonable hardware design, you can have megabytes of RAM (Garth makes a 4MB plug-in SRAM module that would be a good choice) and therefore a lot of space in which to execute code and store run-time data. You could place your "executive" in one bank, along with a data table that keeps track of which banks are assigned to modules, and of course, the modules' names. Data can go anywhere programs are not executing, as unlike programs, data fields can span banks.

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.

As for cost, one CPLD can do the work of 10 GALs, and cost less in the process. If you are truly desiring to build this system you need to consider a CPLD or FPGA as glue logic. In any case, I think you need to learn a bit more about how this all works before you start making too many design choices.

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

Unlike most on 6502.org, I am a real fan of GALs. They offer a lot of advantages over logic IC's - a lot. Not the least of which is reduced cost (so a little uncertain about your original objection).

Looking at your table, and having only 2 memory chips o deal with, I think you can get by with a single 16V8 for most of the heavy lifting. Not sure what your planned I/O is, but you may need another to decode it. Of course, for just a dime or so more, you could upgrade to a 22V10 and do a lot more.

Another advantage is speed. Right now on felaBay there are16V8 in 5ns versions for sale for under $3 (if you like PLCC) or 7 and 10 ns ones for as little as $1 apiece, shipping in, if you prefer DIP.

_________________
Bill

_________________
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?

So, what you're saying is that any one program's code would fit into 64KB, even for games, and that they'd use other banks for the data? I see, I didn't really think about that. But, aren't things like graphics and other data considered part of the compiled binary? I'm a little confused on how that could be loaded into RAM..

Well, in that case, I suppose going with 12K of ROM in the first bank and then having 4MB of RAM is a good idea. And reserving some of it for the OS and program code, of course. You mention that I should consider a CPLD as glue logic. Would that be necessary for the memory map that I've suggested, or would it just make it a lot easier? Thanks for all the help, I've definitely learned some stuff.

Correct. And the chip in question is the CY62158E.

I was a little concerned about availability (and therefore unstable pricing) since not a lot are made anymore. I did however find some new ones being made. I'll take your suggestion about using GALs into account, thanks!

They don't have to be. You could put game data in a seperate file, and load it into another bank. From there, you could use long addressing to get at it, or you could set the Data Bank Register appropriately and use absolute addressing.

I should also mention that there will be 512K of dedicated VRAM for my FPGA video chip. I see what you mean about that, but I think having it in one file might be easier.

So you're going to make a commercial product out of this?

There seems to be an endless supply of Lattice GALs available as NOS, or failing that - pulls. I just picked up 20 NOS 7ns 16v8 chips for $15 shipped to add to my collection of almost 100. Certainly enough to last me the next few weeks *. However, I do realize they are are not being made anymore, so you'd likely not want them for a commercial product where you plan to offer support and such.

I believe Atmel (Microchip? Aren't there laws against building monopolies in the US?) are still making units with equivalent functionality. And as BDD suggests, CPLDs are still being made.

* - No joke. I'd rather use a GAL than resort to using two or more logic chips where possible. Makes life a ton easier!

_________________
Bill

I might, and that's why I want to make everything is readily available today.



Well, in that case, I'm sure I can end up using either of those without too much added cost. It's nice to know they're still (sort of) being made. Thanks! By the way, I want to run the CPU at around 8-10MHz. Would a 10ns GAL and 74-series ABT and AC (not for memory decoding) be fast enough?

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

Hey, thank you so much for all the advice! I feel as if I have a better understanding of all this.

I'll go with a GAL (or CPLD if I end up needing more logic). This seems like the best thing to do from what I can gather.

I really appreciate everyone here helping me out, it's been very useful! I'll be sure to make a post later down the line with an update on my project.

Do you realize that you're going to need extra (and rather non-trivial) hardware to memory-map your SD card? SD cards are serial devices; you send requests and get the data back one bit at a time. So unless you want access to indivdiual bytes to be incredibly, painfully slow your hardware interface talking to the SD card will probably also need RAM to cache entire blocks read from the SD card. By this point things are getting silly; 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?

Based on what I know about the 65816 (which is not a huge amount, just the very basics), here's a memory map I'd start with:

• $F000-$FFFF: 4K ROM for the vectors, bootstrap-level I/O code (including simple SD card reads) and a machine-language monitor. Anything more sophisticated than this should be loaded into RAM via the bootstrap code.
• $C000-$EFFF: 12K address space for I/O. The initial decoding for this can be very simple, "wasting" a lot of address space, but you can later extend the decoding as you wish to address more devices. Initially all you'll need console I/O and the SD card interface, as far as I can see. Note that, being in the 0 bank, you can set the direct page register to any page in the I/O space, which is useful for speeding up I/O when you're doing a lot of it (e.g., large transfers from or to the SD card).
• $0000-$DFFF: 48K RAM for direct page and stack. This is also sort of a "Fast RAM" area in that, as above, you can point the direct page anywhere in here for routines that can be sped up by having a lot of direct page space dedicated to them; just switch at the start of the routine(s) and switch back when done. Or maybe you give different programs different direct pages if you have multiple programs at once.
• $10000-: As much RAM as you care to pack in, to be loaded from SD card or wherever. And I guess the video frame buffers would probably go up in this area, too.

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

Yes, exactly. The SD card has huge capacity, but it is unusably slow when dealing with individual bytes. Instead you want a scheme where you're accessing a whole string of successive bytes.

Unfortunately, the bytes needed by the CPU won't necessarily be successive. That's why folks usually begin by reading the block of successive bytes and copying them to RAM. After that, the CPU simply takes what it needs from RAM, in any order.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html