I wish I had thought of the 65VM02 in the early 1980s, but I was still in high-school at that time. The 65VM02 would have allowed computers such as the Commodore-64 to support a multi-tasking OS. How cool would that have been?
CP/M and MS-DOS would not have become popular --- who would want to use MS-DOS and its TSRs
when a real multi-tasking OS was available on the C64? --- the world would have been a better place!
By the late 1970s, preemptive multitasking was available in the form of UNIX. All of the targeted systems had the common features of memory protection and user/supervisor mode, which none of the Commodore eight bit machines had. A different microprocessor would not have mattered, as the eight Commodore designs from the VIC-20 onward were hobbled by the behavior of the video hardware, which was in constant contention with the MPU for bus time. A protected environment on such a machine would have been all but impossible to implement, since, in effect, two different processors were accessing the buses.
Anyone who is familiar with the hardware of systems capable of preemptive multitasking knows that the MPU is only part of the equation. What makes preemptive multitasking of the sort implemented with UNIX practical is hardware support for memory protection and different modes of operation. In modern systems, the MPU handles that ("rings of privilege," page tables, etc.). Back in the late 1970s and early 1980s, most systems had dedicated management hardware to enforce memory protection and the trapping of privileged instructions when executing in user mode. A few multitasking machines, most notably the Commodore Amiga, had no dedicated memory management hardware and relied upon careful operating system design to protect the kernel and critical system areas from the effects of dubious programming. However, the Amiga was a one-user system, unlike its contemporaries that ran UNIX, which were designed from scratch to support multiple users running multiple tasks. The Amiga kernel's only real threat was the user and if s/he were dumb enough to run a program that overwrote the kernel, stack, or other system area and crashed the machine (which people did do on occasion), oh well!
I don't need memory-management hardware, or a supervisor mode, or any of that other stuff that Unix machines have. I'm not expecting the 65VM02 to be a multi-user system. Even if it had been in the C64, it would have still been a single-user system --- but it would have allowed for doing tasks in the background --- it would have been better than MS-DOS with all of those TSRs that were obviously a kludge.
I'm not certain what your ultimate goal is with your 65VM02 design, but my curmudgeonly opinion is you will find that an intense focus on the microprocessor without considering how the rest of the targeted system will fit together is not going to produce a satisfactory result. A computer is much more than just an MPU. What about I/O? Oftentimes, the interfacing of I/O hardware to the system is much more complicated than interfacing the microprocessor. Although the 65xx peripheral devices may suffice in a uni-tasking environment, they will probably be inadequate in a multitasking situation, especially the 65C51 UART, which is a very "labor-intensive" device from the perspective of the microprocessor.
I don't see a problem with "labor-intensive" I/O devices. The IRQ and NMI can interrupt the low-priority ISRs. I/O that needs to serviced frequently will not have to wait on the multi-tasking OS. Also, the low-priority MIRQ interrupts don't have to wait for a task-switch, so they are pretty fast too. They can't interrupt each other though, so if you have more than one pending, some of them will have to wait. They are written in assembly-language though, so they should conclude quite quickly, so there isn't much of a wait. It is possible for them to be written in Forth, but I said that this is not recommended because of the speed issue.
The 65VM02 is designed for hard real-time micro-controllers. It supports a multi-tasking OS though, which is for tasks that don't have to be done on a strict schedule (soft real-time).
Also, the focus on Forth will likely narrow the attraction of your design to where it may not be of interest to those who would want to run an operating environment of which Forth would not be a part. The hardware design should not favor one operating environment over another, and should be sufficiently generalized to allow any kind of operating environment to be run, including one with a real-time kernel.
The 65VM02 is not Forth-centric.
There are processors, such as the MiniForth/RACE that I worked on previously, that were specifically designed to support Forth. The 65VM02 isn't one of them. There should be no difficulty in writing a C, Pascal, or whatever compiler for the 65VM02 --- the code quality should be comparable to Forth in regard to size and speed.
The 65VM02 supports byte-code with these instructions:
Code: Select all
JVM page jump through the pointer located at (page*$100+A)
OPA load A with (IP) in the alternate-bank, then increment IP
EXIP exchange IP with YA
OPA and JVM are used in NEXT. Also, OPA is used in any primitive that has an operand, such as LIT etc.. EXIP is used in CALL and EXECUTE. This should be the same for either C or Forth.
The 65VM02 supports local variables with these instructions:
Code: Select all
LLY load Y with the offset to the bottom value of the return-stack from the page boundary
AAS add A to S
LLY provides the local-frame address. AAS discards the local-frame from the return-stack. The local-frame is the same in both Forth and C --- this is something that Forth borrowed from C --- the difference is that my Forth supports quotations and HOFs, which C does not support (I don't know why C doesn't support this; that was a failure in the design of C, because this can easily be supported).
In following your topic, I'm getting the feeling you haven't fully defined what it is the 65VM02 is supposed to do that the 65C02 and 65C816 can't do. Am I misunderstanding?
AFAIK, nobody has downloaded my document and read it. Nobody is actually following the topic.
