My $.02. bank 0 should be all RAM (with shadowed access for ROM and IO) for a ‘816 system since that is the only bank that direct pages and the stack can be located in.
In my system I use Garth’s 4MB RAM module for banks 0 to 63, banks 64 to 191 reserved for RAM, then have IO and ROM in upper banks. ROM can be shadowed into bank 0 when needed via an ff switch. I have 74'259 ff allowing ROM reads in bank zero. IO is at bank $FD.

_________________
http://www.finitron.ca

Interesting way to keep RAM contiguous. I'm following almost the same philosophy for Bank 0, reserving the last page of that bank for ROM. To keep areas contiguous to the extent possible, I continue with ROM in bank 1, followed immediately with I/O in the first page of bank 2. The remainder of memory is RAM.


I'm interested in seeing the comments. I didn't get much (any?) positive feedback for my '816 memory map.

To add another data point...

My Ruby'816 system has 512KB of RAM and no ROM.

There is a 256 byte 'window' at $00FE00 for IO (just one VIA) and the RAM at $00FF00 through $00FFFF is shared in a mutually exclusive way with the board IO/Control MCU. The hardware and OS call vectors are from $00FF90 upwards and $00FF00 through $00FF8F is used to pass commands and data to/from the IO/Control MCU.

The OS lives at $00C000 upwards, the application is typically loaded into $008000 through $00BFFF (16KB) the rest is free to application use...

That allows me to load and run 65C02 code in 8-bit native or emulation mode (e.g. the 65C02 version of BBC Basic) or my own native '816 applications (which for now is just my multi-tasking BCPL VM.

Cheers,

-Gordon

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

Because I'm new to the '816 scene, and honestly haven't much clue how the software side goes, can you all tell me why so much RAM in Bank 0 is so important?

Yes, that is the only place for direct page and stack. I get that. But I'm so used to zero page and stack being 256 bytes each, and I have never ever run into a problem of not having enough of those in 6502 land. I think Proxy once said that he intends on running C code on his '816 and wanted a very large stack. I think BDD mentioned having I/O in Bank 0 because of 'convenience', though I think that is mainly because interrupts are only handled in Bank 0. Other than that, (and perhaps just speed/bootloader concerns), why is so much RAM needed in Bank 0?

I currently have 32KB of RAM planned in Bank 0. Is that enough?

Thank you everyone!

Chad

I wouldn't say it's so important, but more like you said, simply


I'm not saying don't use it for something else. I use a page for ROM for my ISR and vectors. I'll use it for other stuff if I get a greater benefit from it in Bank 0 than elsewhere. It's not a religion, but just what I want to do for my current project.


Yep, same for me. And I'll admit to using zero page for stuff that didn't even need to be there.


There is lots of good advice on this site. But some of it might not be consistent with your goals. It's been recommended that I do away with interrupts, because polling is enough for my needs. It's also been said that I can fit everything into Bank 0, so why bother with more ROM outside that bank. Right now, this is all true and will still likely be for a long time to come. But I'm aspiring for more or maybe just something a little bit different. My post here is just a data point for consideration.

My first '816 experiments simply got the processor running on my 65C02 builds. My current build expands one of those to multi-bank memory and I'm well on my way to porting my 6502 Forth to it. So far, I've only used about 10k ROM and several kB of RAM. I haven't coded far address access yet and don't really have much vision for it yet other than multiple instances of my Forth OS. I really don't need all of the ROM/RAM or even the '816. I could easily keep working just within Bank 0, but I'm looking to push my horizons a bit. Where are yours? Only you can say.

Garth has a good article "enough stack space". You probably don't need as much as you think.

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

To be honest, I think there's a certain amount of habit and intuition in play, when people designing '816 memory maps decide what to put where and which tradeoffs to make. I include myself in this.

It's not a science and there's no single correct answer.

Very rarely does someone have deep experience in the '816 at that time, because usually it's their first effort. They want to be careful and to do the right thing, but they don't know how it's going to work out because they haven't yet tried it. There's no OS, no libraries, no applications yet written.

It's highly likely that 32k is enough RAM for bank zero. It's also likely that 48k or 60k is better, especially if it doesn't cost anything to do that.

I think the reality may be that there's so much memory space these optimisations don't mean much, although we're all inclined to make them.

(The case of fitting an 816 into an existing '02 machine is slightly different, because there are compatibility considerations.)

I think the same will be true of I/O - one can save a cycle or two by putting it in bank 00, but it's rare indeed that those saved cycles will be crucial, especially at higher clock speeds.

Good points.

Recursion is quite powerful and can consume a lot of memory. My first introduction to Python was in solving a complex puzzle with just a tiny bit of recursive code. I didn't realize how much memory it was using until I translated it to C and had to handle memory allocation. Python hides all that internally.

RECURSE is a standard word in Forth and interestingly only took 16 extra bytes to implement on my 6502 Forth. It takes 21 bytes on my '816 Forth, but the extra bytes are because it's subroutine threaded and needs to handle the bank byte. I never used the word much though, except in testing.

_________________
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'm even doing without a ROM at all and have bank0 all RAM except for an IO window. A CPLD loads the boot code into the top page from an SPI Flash and the CPU then takes it from there.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/