How much memory would be enough to have it always accesible by a 6502 CPU, so it could run code there no matter what happens to the rest of the memory (like being banked in and out).

I ask this because I've read several times that from the POV of a developer, 64K of memory is a huge space to be filled with code. But maybe too little as 4K would be too little.

From my experience it's usually data that ends up taking a lot of space, not code. 6502 code is quite compact and it'd take you a very long time (weeks?) to hand-write enough code to fill 8k or even 16k.

But if you store and process data - even just text - it can quickly add up. A day or two ago I rattled off some documentation about one of my projects, and wrote a 6k text file in probably about half an hour.

So it depends a lot on the use cases, and even something simple like a text editor will need a lot of data.

Interpreted higher-level language code tends to be less compact than 6502 machine code, even though it achieves more with each instruction. And of course source code is much less dense. e.g. looking at an example, for a recent project my 6502 assembly source is 16x larger than the machine code it produces.

If you're doing paging of some kind, you don't necessarily need to maintain this level of split, and maybe 8:1 (i.e. 8k fixed for non-paged code) would be a good ratio.

Well I suppose you'd want enough room for the code that switches banks. Even 4K is a fair amount of space. In fact the cartridge slot of the Atari VCS can only address 4K without bank switching, and aside from that only has 128 bytes of RAM.

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

It might be interesting to look at say Fuzix, and how it handles switching tasks in banked memory systems.

In that case it's a matter of making best use of whatever a system offers.

There must be a tradeoff between having enough for the kernel - at least the machinery which does the switching - and also having enough for the application, which is being paged in or out.

256 bytes is probably too little, 16k too much. Is 8k too much? I'm not sure. 8k feels to me like an attractive granularity. But also, it seems clear there won't be a hard limit in any case - it's all about relative effort and convenience.

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

Ok, all of this was because I was thinking in a system with a memory configuration like 32K+32K, where lower 32K would be fixed and the upper 32K would be a single bank that could be selected in slices of 32K from a 256K chip, giving the system a total memory size of 288K.

It would use the system that the Commodore 64 uses: the $0000-1 addresses to select the memory map, but in this case would be $0000 connected to a latch that would one the eight bits as the chip select that would match one of the slices of 32K. This latch should be somehow controlled in a way that only one bit could be set at a time, so the bank would be set properly.

The first 32K would be entirely video memory, BTW (640x200-4 colors or 320x200-16 colors).

I/O would be mapped in the lower 32K.

So that's why I thought about the minimal, decent memory size for coding, and then the rest as data, swap or even running code, provided that the program counter would always return to the lower 32K before swapping banks.

I suspect that's more chunky than would be ideal, but as I say, it's all about tradeoffs.

But then it's very much a theoretical discussion, until you start to build the applications which might make use of the system. (The story with Fuzix as I understand it is that there are the usual unix-like user-space applications, written in C, and I believe it's shown that it's better to have rather more than 32k for an application. In a world of smaller applications, or applications written with some idea of overlays, the answer might be different.)

Is it worth looking at some historical implementations?

The early SBCs had very little RAM and even in the early 80's I was building systems with just 128 bytes of RAM and 2KB of EPROM (Industrial controllers - "Arudino" of their day, as it were) Also Atari 2600 with 128 bytes too.

The Apple II initially shipped with just 4KB of RAM - 1KB was for the video too, leaving a minimal amount (by todays standards). However by 1978 most were being shipped with 48KB of RAM and that 16KB RAM card to take it to 64KB was a reality (And it introduced bank switching too as it overlayed the existing ROM space).

In 1981, The BBC Micro shipped with just 32KB of RAM which seemed bizarre at the time. Screen RAM was variable - the highest resolution mode needed 20KB however the intention was that that would always be the Base of IO processor with a 2nd processor plugged into it to do the actual "compute" tasks. That RAM limitation didn't stop elite being written though...

So to usefully run code you need some RAM in page 0 and some in page 1 - that 128 bytes I mentioned earlier came from the RIOT (RAM, IO, Timer) chip and the 128 bytes was mirrored all over the bottom 32KB range, so you set stack pointer to $FF and it grew down, and used RAM from $00 up for zero page and hoped the 2 never met in the middle...

My Ruby 6502 project sort of mirrored the BBC Micro, although it has 64KB of RAM - OS usage, buffers, vectors, etc. is $0000 through $0DFF, "user" RAM (Program + Data) is from $0E00 through $7FFF. "Language/Application ROM" is 16KB from $8000 through $BFFF and Operating system "ROM" is 16KB minus a small window for IO from $C000 through $FFFF. (I put ROM in ""'s as it's really RAM, but pretending to be a ROM image area)

Will I ever write (BASIC) code to use all that 32KB area? Nope, but then I ran up the old Acornsoft BCPL system it sure did...

The BBC Micro "paged" ROM area from $8000 through $BFFF and as the OS was fixed in $C000 upwards, code in the OS could select any one of up to 16 ROM images to run code inside.

-Gordon

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

Many programs written in assembly language do fine in 8K or less memory.

A simple disk operating system requires something like 4K to 8K.

Something like a debugger with more capability than the usual monitor in ROM is going to need at least 8K for itself on top of the program being debugged.

An assembler needs more and a compiler way more.

So it depends on what you want to do with it.

32k is quite a lot and it will be interesting to see what you can make of this idea!

A few other points of reference... in this thread about the 6509 I make some mistaken links to banking in the C128 and then we're directed to an article about coding in the CBM-II world.

Also, note that Acorn expanded the Beeb by way of adding an application processor, which has just 2k for the OS ABI and the rest - 62k RAM - is all there for the application and its data. In fact they even expanded this system, in-house, with a scheme to access 256k. That's one of several large systems linked by Jeff here.

Also, perhaps of note, the modern remakes of this application processor (in FPGA and in Pi) now implement a memory banking scheme, 8 slots of 8k pages mapping into a 1MByte memory space. The idea was that the hardware is simple, and it's up to software as to how to use it. For example, one could use 3 slots to make a 24k sliding window, or 3 independent 8k windows, into upper memory, and leave the other 5 slots fixed, for a conventional fixed 40k. (Less, of course, whatever's needed for I/O and OS ABI.) We made a Conway's Life with a very large data structure this way - probably the only software so far which has tried to use this feature!

Speaking of code only, fixed memory is fast to access, since you don't have to go around twiddling banking registers just to call a function which happens to be in a different bank. So this all depends on how many oft-needed routines you need immediately accessible without significant slowdown, and without the code footprint overhead of calling "foreign" functions.

But I think the best approach is to use small windows (4kB?), and the user can compose those into larger areas, including your original two 32kB "fixed" and banked areas. The banking registers are also significantly affected in shape (and therefore affect the size of code needed to swap them) based on how many banks are available, so that needs to work into your design as well.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

The most general solution is to use an overlay linker.

The programmer has to specify which object modules go into the root or an overlay; the routines in the run-time library, if a compiler is used, goes in root.

The linker generates the thunks needed to swap overlays as needed; this management can be modified to handle banking if the hardware supports it.

In this configuration, you do not have any non-banked space for your program, which is troublesome. Also you can not have Banking the top of memory on 6502 would be problematic, as there are interrupt vectors. And they need to be initialized at CPU startup.

If your memory is 320x200x4 then it is 32000 bytes, leaving 768 bytes unused. That could be ZP, stack and 256 bytes for non-banked code.

Having large amounts of contiguous unbanked video memory seems appealing at first, as it simplifies things a bit, but it's a huge amount of memory and in practice as far as the code and speed are concerned, banked video memory is fairly easy to implement. The 6502 can only access large amounts of memory indirectly via two-byte pointers in zero page, which need setting up in any case, and setting a bank register as well is usually quite easy to add to the code, and fairly cheap to do.

My approach for this is to have a 6502 subroutine for preparing a zero page pointer to write to a specific line of the display. This routine calculates an address based on the input coordinate, and stores it in a fixed location in zero page, and also sets the bank register appropriately. After calling this routine, my code can then write to any location on that line (more or less) by writing relative to the address that was stored in the zero page location. For low stride modes this is just "STA (zp_ptr),Y", or if the width of the line is more than 256 bytes then you also need to adjust the pointer. Either way though it's pretty easy to do and most graphics routines can fairly easily be written to work line-by-line, meaning you call the line select routine once and then perform a large number of operations on that line before moving to another line.

The only exception to this is where you are copying from one area to another, which in a banked system may require a lot of reprogramming of the bank register. Supporting dual banks mapped to different parts of video memory is maybe a better solution for that, or just avoid the need to copy from one bit of video memory to another (e.g. copy from non-video memory instead).