Arlet wrote:


True, but it's better to build a good system first, and perfect it step by step. It's too easy to come up with many great ideas from the start until you're overwhelmed and quit.]

What you are describing is something I had in an early version, but no longer have.

Previously I had expected to have a T-flag that gets set by the heartbeat timer (either the ISR does this, or it is done by hardware). At NEXT for every primitive (not any particular frequently used primitive), the T-flag is tested and if set a task-switch is done.

I got rid of all that though.

There were problems with that design. Specifically, that accessing some shared resource could only be done inside of a single primitive, which necessarily implied that the code was written in assembly-language. What I have now is the EXA instruction that allows a task to obtain a semaphore. This means that accessing some shared resource can be done in Forth code (or C code or whatever language is being used) --- it doesn't have to be done inside of a single primitive --- the whole point of the 65VM02 is to support high-level languages, so I don't want to force people to use assembly-language for common programming tasks.

I think my design is way beyond the 65c02. I have support for byte-code VM execution which makes a high-level language realistic, I have support for local variables, I have support for semaphores, and I have support for a RAM-disk outside of the 64KB main-bank. The 65c02 lacked support for all of this --- that is why it became obsolete --- it was a very minor upgrade to the 6502; it just wasn't moving forward into the future.

The 65c816 is a much bigger processor than the 65VM02, with 16-bit registers. It doesn't support byte-code VM execution though, so high-level language compilers will typically generate machine-code which is typically quite bloaty. The 65c816 also only has the NMI and IRQ interrupts, the same as the 65c02, so it is pretty weak compared to the 65VM02 that has NMI IRQ MIRQ0 MIRQ1 MIRQ2 MIRQ3 interrupts --- the 65VM02 also allows NMI and IRQ interrupts to interrupt MIRQ ISRs, although the MIRQ interrupts can't interrupt each other's ISRs, so I have a distinction between high-priority and low-priority interrupts.

In the 65VM02 I have the D register that indicates where the direct-page and return-stack are. The D register is always even, so the direct-page will be on an even page and the return-stack will be on the next higher page. By changing D the entire context of a task can be swapped out with that of another task (most tasks use only the direct-page and return-stack for all of their data). This makes for very fast task-switches. The tasks communicate with each other using shared data-structures in the heap (there is 56KB of RAM available in the main-bank, so the heap is pretty big).

The 65VM02 is still an 8-bit processor with 8-bit registers. It is not an upgrade to 16-bit registers like the 65c816. It seems like upgrading from 8-bit to 16-bit registers is obvious. I am dubious that this is a good idea though. To me, the hallmark of the 65c02 was the A X Y and S registers, all 8-bit, and that is what I still have in the 65VM02 (with the addition of the D register that is also 8-bit). This is a small processor! I do have the IP register that is 16-bit, but this is provided to support byte-code VM execution, which is only necessary for high-level languages support.

Having a very few 8-bit registers allows the 65VM02 to have very fast interrupt response time (the IP registers doesn't have to be saved and restored if the ISRs are written in assembly-language, which is the typical case). All in all, I think the 65VM02 is a better design than the MSP430 or STM8 --- those are primarily what it would compete against.

One has to start somewhere. It's better to build a crappy system first which can then be improved to a good system. One may not know what a good system is until one's seen a few crappy ones.

OK, I have read that you were tinkering with your T-flag but I didn't notice that you dropped it. I thought the new M bit serves to distinguish between various IRQ levels AND somehow serves as a "time to switch task when it's convenient" flag. This is obviously not the case - so, how do you organize multi-tasking now? Or did you drop it?

Your new EXA instruction could well serve for more purposes than just semaphore handling. Of course some more address modes for EXA would be nice. BTW TSB/TRB lacking the (ptr),Y address mode but else could handle semaphores as well.

Well, exchanging stacked items without requiring auxiliary memory or registers would be easier using abs° or S,offs. (°: in the case of 65VM02 this probably won't work as your D reg moves the stack as well so absolute addressing the stack won't work and dp addressing stays in dp (?).) Perhaps (direct) - without Y

- but no matter, of course it is up to you what you add to your design.

now I'm interested in the subject again, although why I'm on this 65c02 kick in the year 2017 is hard to explain...

I want input from you guys.

I use direct,X for accessing the data-stack. Exchanging items on the stack needs Y available, but this is not a problem because Y is available:

enso seemed to explain it well, at viewtopic.php?f=12&t=2682&p=35151#p35151 .

The 65VM02 could be the next big thing --- actually, the next small thing, as it is a small 8-bit processor.

IMHO the problem of translating C (and many other tongues, even Forth!): to be universal they use a universal model and that is always ever stack oriented. And that is something, the 6502 does not support natively. The power of Forth lies in the mental strength of its programmer - (s)he has an overview about what will happen in the near future and plans the processing accordingly. This is an enormous advantage against a machine thats deals with characters and keywords. That is why Forth is/seems to be so powerful which in turn causes the people to like it

I would assume that every addressing mode concerning the return stack and/or every new instruction that helps processing sw-stacks would be helpful. Like INP direct, DEP direct (increment/decrement a direct pointer (16 or more bits) in a RMW fashion) might be helpful. Adding an S-relative address mode (ADC S,3 or DEC S,6 ...) should be a very powerful way to enhance the 6502's capabilities.

my 2 cents