The ISAC will handle a lot of this, and may be able to shadow or mirror different address ranges during runtime.
so no matter what bank you are in, you can 'shadow back' to bank 0 and use the stack there.
Something you and several other people have commented on is this particular topic. This is the system address space and the cpu isnt the only device on the system bus. with bank f being all rom, it makes sense to copy routines from it. ...
If on power-up, the ISAC "knows" to make the to however many byte of the F ROM page available at the top of the 6502 logical address space, and know to make however many bytes of the 0 RAM page available to the 6502 logical address space ...
... then in what sense is the physical address space split up into 16 64KB banks?
I am giving the reaction of several other people because what was said was 16, 64KB banks.
If the physical address space is not appearing in the logical 64KB address space as a single 64KB bank (which, logically, occupies the entire address space) ... isn't it a bit confusing to say that it is?
The video ram may not be accessible by the cpu without going through its registers. Devices will use DMA to talk to each other, so they might never involve the 6502 at any given point, other than to be issued commands, like Run and Stop, or Next Track. Consider an ISA slot in a desktop version of this. It might get an entire bank dedicated to it, such as Ram Expander, or only a few bytes are used, in the case of an MP3 player add on card, with a 128gb of storage. The 6502 cant see 128gb, it can tell your device to advance to the next song, and that MP3 player can still talk to DMA, the gpu for visualizers and the audio mixer to send the data onward to the speakers.
So in what sense is that 1MB physical space organized into 16 distinct 64K Banks -- where as we know, in the context of 16bit address space from the 1980s, "Bank" means the contiguous segment of physical memory that appears to the CPU at some span of logical addresses.
Are you perhaps inventing a new meaning for "Bank" from the one that has been used in the 8bit CPU context for 4 decades or more, and so confusing people as to what you are saying?
If what you mean is that the manager of the physical memory manages it as 64KB segments and then flexible sub-segments within that, wouldn't it make more sense to call them 64KB Segments, which doesn't carry the implication that they appear in the 64KB address space all at once?
So System Address Space is 'theoretically accessible' by the cpu anywhere, that doesnt mean people can be careless programmers.
That is a dramatically different description of what is going on than saying that the 1MB of physical address space is broken on 64KB boundaries and the CPU can only see one 64KB portion at a time.
Careful development of a DMA controller and system software should help here.
Im not shuffling 'windows of 16k around'. Numerous people have lamented the thought.
16KB windows were just a system that was nearly as simple as a single Bank of 64KB making up the entire 6502 address space, yet would also be functional, unlike the suggestion that each 64KB segment of physical memory actually be treated as a single 64KB Bank.
If people don't want to be locked into 16KB windows, simple to work with but more flexible banking systems can be readily specified ... the venerable Z180 Common 0, Banked RAM, Common 1 system over a 1MB physical space mapped into the 64KB address space on 4KB boundaries could be expanded into four zones: Common 0 at $00000 to the start of Bank1, Bank1 from the start of Bank1 to the start of Bank2, Bank2 from the start of Bank2 to the start of Common1, and Common1 at the physical address space from $F0000+Common1_begin to $FFFFF. That is a byte and a half to specify logical windows on 4KB boundaries, three bytes to specify logical windows on binary page boundaries.
Then with a 1MB physical address space you can specific the physical base of each bank with a one byte index on a 4KB boundary, or with a separate segment nybble and sub-segment byte, on a 256byte page boundary. So you can easily specify symmetric sized RAM and ROM banks to copy from ROM to RAM, but you can also specify a 256 byte I/O register space that can placed as high or low in the address as is convenient.
The system space is 1MiB, and the programmer might want to use that space carefully, to avoid problems like you have pointed out, however, with careful use of the system and commands, they should be able to utilize much of it.
I was just pointing out that in the terms that were used to describe the project, the design was unworkable, but as you describe how it is intended to operate, it seems rather that you mean that the 1MB physical address space is organized into 64KB segments, rather than it being organized into 64KB Banks. 64KB Banks are clearly unworkable. Given that an 8bit processor is talking to the registers of the memory map manager, a system of 16 segments, which implies a 4bit segment index, and up to 256 subsegments within each segment, on binary page boundaries -- which implies an 8bit sub-segment index -- could be quite convenient.
it's important that the core registers of the memory map manager are somewhere in the Common0 area that includes the zero page and stack page, which is why it is not unusual for them to be located starting at $0000 in the logical address space, and to be concise enough that not too much zero page space is given over to them. Extended functions could be brought into the logical space as additional I/O registers in a banked window (of whatever size), but the core registers to bring that into view need to always be visible.
So one approach which would fit the design of the 6502 would be to dedicate the first page of the I/O segment to $0200-$02FF, and if that includes the registers of the memory bank manager, that would then include the capability of bringing in whatever additional I/O register space by banking them in from the I/O segment.
