fachat wrote:
So I guess I DO have to comment on that
First of all, I think the 65816 is a nice chip, with lots of abilities that make it much greater than the 6502...it is only in retrospective now, with changing requirements (thinking of program sizes of more than 64k, supervisor mode) that I find the 65816 shows its age.
To some extent, that could be said about other contemporary MPUs. Consider at all the baggage dragged around by the x86 architecture, which is almost as old as the 65xx family.
Quote:
The time-shared data bus is an annoyance, but can easily be worked around. WDC could have thought of another hardware option with full external address bus though.
That feature (?) stems from the requirement by Apple that 65C02 compatibility be retained. There weren't enough pins available on the DIP40 package in which the first generation 65C816s were made. Now, if WDC had used a larger package, e.g., PLCC68, A16-A23 could have been separately brought out (as well as the output side of RDY). That, and if money grew on trees we'd all be wealthy.
Quote:
VDA/VPA give much more information than the 6502's SYNC output. Together with VP, E, M/X it allows to use the 65816 from simple systems to very complex systems with the 65816 as a core only and glue logic providing higher level functionality - speaking of supervisor mode for example etc.
Conversely, accounting for those signals means the use of basic glue logic become problematic. You could conceivably implement fine-grained functionality with a bunch of discrete gates—assuming performance isn't going to be important to you. Realistically, a high performance '816 system is going to required use of a CPLD to avoid cumulative propagation delays.
Quote:
- Structures in bank 0 - a major annoyance!
My principle beef with the '816 design. Unfortunately, a necessity to maintain 65C02 compatibility.
Quote:
- ABORT is required to be asserted on rising phi2? Outch. That's a tough timing requirement.
It's tight, I agree, but not impossible. Again, a GAL or CPLD would be necessary to achieve a quick response to an illegal memory condition. If you peruse the timing diagram, it is indicating that ABORT should be asserted shortly before the rise of Ø2, defined as tPCS. By then, the bank and address will be valid and aborting will prevent an register or memory changes. ABORT should be de-asserted immediately after the fall of Ø2.
Quote:
- multitasking, multiprocessing
- memory protection between processes
- 64k max memory per process
- user mode vs. supervisor mode
- hardware registers only available to supervisor mode
You'd have to decide what mapping scheme to use. The most easy "natural" one for the 65816 is one process per bank. Or at least one memory environment per bank (which may contain one or even more processes). You'd sacrifice the ability to run programs with more than 64k memory requirements.
You can't run a larger than 64K program without special gymnastics, because PBR doesn't increment when PC wraps. You're stuck in the same bank unless you execute something like JMP <NEWPBR><$0000> to get to the start of the next bank. So in that regard, you really haven't sacrificed anything.
Quote:
But with this decision you could do use a CLPD with a "user bank" register that monitors the 65816 and internally switches between user and supervisor mode.
In supervisor mode ("bank 0") the 65816 works as it is. In user mode the processor's bank address byte is ignored and instead replaced with the content of the "user bank" register. Thus the user mode cannot "escape" the user space memory. Even processor state on interrupt would be stored on the user space (bank) stack, not in supervisor memory.
This is one of the memory management schemes I've contemplated. Your next question highlights the fundamental problem with ignoring the bank when not in supervisor mode.
Quote:
How would such a system switch between user and supervisor mode?
- supervisor mode is entered on vector pull (VP), and possibly other signals
Risky. If ABORT is asserted during any stack operation it is likely the MPU will get put into a death spiral, since ABORT causes VP to be asserted as well. The rub is that ABORT, like all other interrupts, pushes the MPU state to the stack. If the illegal memory access involved a stack operation the MPU will choke on an endless cycle of ABORTs.
Quote:
- opcodes like BRK or COP could be used to call supervisor mode functions from user mode. Supervisor mode code can access user mode to transfer data.
BRK seems to be the better choice here, as the signature byte can be anything. Hence BRK can invoked up to 255 separate kernel functions, assuming signature byte $00 is used to set program breakpoints for debugging. Only 128 COP signatures are designated for user use.
As the MPU executes BRK (or other interrupts) it pushes its state onto the current stack, which would be in user space. If entering supervisor mode on a BRK instruction, how do you get the exit status of the called function back to the user process? After all, when the RTI is executed at the end, the user space has to be mapped back in so the MPU can pick up SR, PC and PBR. The problem is the value pulled back into the status register (SR) is that which was pushed when the BRK was executed. How would one fix that little contretemps?
Quote:
- opcodes like TXS need not be detected, as stack is mapped into the user bank (away from bank 0)
Also true of other stack operations, such as PHD, PHK, etc.
Quote:
- user mode could be entered by monitoring RTI opcode. The interrupt routine could increase a counter in the CPLD that is decreased on RTI, so that when the counter reaches zero/underflows user mode is entered (to accommodate stacked interrupts for example).
The VP line could be used to increment the counter, as VP is involved on any interrupt. However, the counter will become unbalanced if user-mode code "misuses" RTI for vectoring the MPU.
Quote:
Could be quite an interesting system thinking about it now...
Isn't that what this hobby is all about?