I don't like to take inspiration from x86 - and particularly so when Microsoft is involved in hardware standards. Regardless, I believe that something similar to
LIM EMS expanded memory may be beneficial. In particular, a large common pool of memory may be accessed via banking on 65C02 or directly on 65816. Bank switching circuitry and one or two multiplexer chips would allow bank switched 65C02 software to run unmodified on 65816.
There are different types of RAM and one or two may be present on any given 6502/65816 system:-
The
first type of RAM always remains present in the bottom 64KB of the address-space although portions of it may be temporarily or permanently obscured by ROM or I/O. In the majority of systems, this is the only type of RAM.
The
second type of RAM is bank switched in the bottom 64KB of the address-space. One or more windows of one or more sizes allow substitution of memory ranges. In the most extreme case, 63KB or more memory will be switched. Bank switching is typically implemented with one or more latches. These provide upper address bits within a larger address-space. This arrangement often has the problem that only 12-15 address bits are directly mapped and therefore contiguous use of large ranges requires slow bit shuffling operations of the address bits. Schemes with 8 bit alignment may also be slow and cumbersome due to excessive writes to two or more latch registers. On x86, the second type of RAM would be called expanded memory.
The first and second type of RAM may be offered in the same system. Commander X16 is an example design.
The
third type of RAM is directly accessible outside of the bottom 64KB. This is not available to 65C02 and only available to 65816. On x86, this would be called extended memory.
The first and third type of RAM may be offered in the same system. All of BigDumbDinosaur's designs are prominent examples. I believe Foenix C256 may be another example.
It should be obvious that it is possible to make a 65C02 system which only offers the second type. It should also be obvious that it is possible to make a 65816 system which only offers the second and third type - and do so in a manner which is compatible with the 65C02 system. At the most, this requires two sets of latches and address multiplexers. This may be designed in the following manner:-
- Design a 65C02 system with bank switching. (Outline example.) This may be the last step.
- If a 65816 system is required, substitute 65C02 with 65816 and 8 bit address latch to obtain 24 bit addressing.
- Additional 65802 style circuitry may be required for compatibility with video, DMA or dual core.
- Feed address lines A16-A23 into 74x4078 8 input OR/NOR to modulate legacy or extended address range.
- In particular, feed 74x4078 output into one or more 74x157 multiplexers. This allows RAM addressing via 65C02 bank latches or 65816 latch.
The latency of the scheme should not be too onerous given that A16-A23 is stable ahead of A0-A15. However, given that bank switch windows are often scaled down by one or more bits, it is likely that the bank switching will have a different address range compared to a 65816's native 24 bit range. For example, Commander X16 offers one 13 bit (8KB) window. An 8 bit latch expands this to 21 bit (2MB) address-space. My preferred embodiment offers 22 bit or, optionally, 30 bit addressing. It is rare, if ever, for banked and directly accessed schemes to align exactly.
Regardless, such schemes allow a large range of 65C02 software to run unmodified on 65C816. A given scheme may also be suitable to supervise zero or more
virtual 6502 instances - without allocating 64KB RAM per process and without restricting each instance to a maximum of 64KB. Furthermore, this may be achieved without a privilege system or pre-emptive multi-tasking.
Indeed, such arrangement has the advantage of fast, linear addressing for demanding tasks and non-contiguous allocation without fragmentation for less demanding tasks. Furthermore, a useful subset of this functionality may be upward and downward compatible with existing hardware and software.