65c816 address decoding help

[Skylie33]

BigEd wrote:

Even as little as 2k ROM would be enough to load a bootstrap: 16k would be enough for quite a sophisticated loader.

So, indeed, banks 1 and up are all RAM.

I don't quite understand your 'devoted to mass storage' - you are perhaps thinking of memory mapped storage? I'm thinking of SD card block storage: your ROM routines read a block, place it in RAM.

If you have a large EEPROM mapped into high memory... well, you have non-volatile memory. That reduces boot time, I suppose. But it means there's a distinction between booting and upgrading.

Do you have a clear idea why you want large amounts of non-volatile storage? Is it perhaps because you hadn't originally got the SD card in mind?

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.

[BigDumbDinosaur]

Skylie33 wrote:

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.

[BillO]

Skylie33 wrote:

I would rather use a GAL if I need more address decoding logic.

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.

[GARTHWILSON]

What SRAM IC are you using? SRAM sizes normally go in x4 jumps: 2KB, 8KB, 32KB, 128KB, 512KB, 2M, skipping 1MB and the other in-between sizes.

I'm sure you'll want the bulk of the major portion of RAM to be contiguous so you can have large arrays, a capability you'll lose if each bank has a portion cut out for I/O or anything else.

[Skylie33]

BigDumbDinosaur wrote:

Skylie33 wrote:

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.

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.

[Skylie33]

GARTHWILSON wrote:

What SRAM IC are you using? SRAM sizes normally go in x4 jumps: 2KB, 8KB, 32KB, 128KB, 512KB, 2M, skipping 1MB and the other in-between sizes.

I'm sure you'll want the bulk of the major portion of RAM to be contiguous so you can have large arrays, a capability you'll lose if each bank has a portion cut out for I/O or anything else.

Correct. And the chip in question is the CY62158E.

[Skylie33]

BillO wrote:

Skylie33 wrote:

I would rather use a GAL if I need more address decoding logic.

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 to 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.

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!

[DerTrueForce]

Skylie33 wrote:

But, aren't things like graphics and other data considered part of the compiled binary?

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.

[Skylie33]

DerTrueForce wrote:

Skylie33 wrote:

But, aren't things like graphics and other data considered part of the compiled binary?

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.

[BillO]

Skylie33 wrote:

I was a little concerned about availability (and therefore unstable pricing) ...

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!

[Skylie33]

BillO wrote:

Skylie33 wrote:

I was a little concerned about availability (and therefore unstable pricing) ...

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

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

BillO wrote:

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.

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?

[BigDumbDinosaur]

Skylie33 wrote:

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.

That’s exactly what I am saying.  Load your program and the static data in one bank other than bank $00—the load address can be $bb0000, where bb is a non-zero bank.  Static data can be loaded above the executable machine code at any convenient address.

Quote:

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.

Just to be pedantic, one assembles, not compiles, an assembly language program.    In some cases, the resulting object file may not be an executable binary, which means it has to be processed by a linker before an executable binary results.  The linker usually tinkers with some addresses if a relocating load is to occur.

At the machine level, graphics are just a form of data, same as an array of pointers, or a series of user prompts.  I’ve not done any game programming, but have done a lot of business applications, in which a certain amount of static data is needed to make a program run.  In every case, the static data is logically separate from the executable code, although it may be assembled at the same time the program itself is being assembled, and hence may be physically part of the program.  If I were writing a program that has static graphics (e.g., a play field), I’d generate the binary data for the static graphics separately from the program itself and then define some pointers to where the graphics are loaded into memory.

Understand that while a 65C816 program cannot span banks, except via long jumps and/or long subroutine calls, the 816 can linearly address the entire memory space using various programming techniques.  As Garth said, you can have large arrays spanning over multiple banks and by using [<dp>] and [<dp>],Y addressing, access any of it with essentially the same ease as you would in a 16-bit address space.

Quote:

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.

In theory, it should be possible to build a maxxed-out 65C816 machine using only discrete logic.  However, the number of discrete gates required to do so would result in a large and slow system.  Even though fast logic families such as 74AC and 74AHC will achieve single-digit propagation times on 5 volts, the multiplicity of gates that would be needed to do what you wish to do would considerably cascade those prop times, resulting in a significant limit on how fast the machine can be clocked.  The bit-intensive code required of game programs demands a high level of compute-bound performance in order to produce a pleasant experience for the user.  You will have trouble achieving that if the glue logic throws too many twists and turns into your system.

Also, in order to accommodate the physical size of hobby-friendly discrete logic, a fairly large PCB may be required.  Aside from the cost of such a board, its size could result in long traces that give rise to transmission line effects and the problems that accompany them.  In other words, you may design a circuit that works on paper but will not be able to run at anything above a crawl when constructed.

Programmable logic devices (GALs, CPLDs, etc.) were developed because of the scaling problems I described.  Today’s programmable logic typically achieves 10ns pin-to-pin prop time, which is very close to the speed of a single 74AC gate.  At the same time, a PLD will accommodate a degree of logic complexity that is simply too difficult to create with discrete gates.  The PCB can be smaller and more densely packed, since one device (assuming the choice of PLD is correct) can replace a good-sized handful of discrete parts.

The decision on whether to use a GAL or a CPLD comes down to how complex the logic will be and how many I/O pins are required.  Also, consider that a small CPLD (e.g., a Microchip ATF1504AS) has at least ten times the logic capabilities of the largest standard GAL, plus more I/O pins, while at the same time occupying not much more space than the DIP package of the GAL,

Obviously it’s your call, but I will remind you of an adage I took to heart over some 55 years ago when I was starting out in this field: Learn how to fly a Piper Cub before climbing into the cockpit of a 747.

[Skylie33]

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.

[cjs]

Skylie33 wrote:

The plan is to add an SD card reader for easy loading of programs/ROMs onto the computer

Skylie33 wrote:

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.

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.

[Dr Jefyll]

Quote:

RAM to cache entire blocks read from the SD card

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