Well, I've given some more thought to the subject of an upgrade on the 65c02. I've come up with a design for an upgraded 65c02 that accesses 128KB of memory and is specifically designed to support running a VM and a multi-tasking OS. Of course, I'm thinking of running Forth on the VM, but it should also support other languages, such as C, Pascal, etc.. Only the primitives would be written in assembly-language, and maybe some user-written CODE words, but most of the code would be in written in a high-level language. The byte-code is pretty compact, so I'm expecting maybe 16KB of byte-code and 8KB of machine-code to support the Forth system, the OS, and the application code, and the rest would all be RAM for the application data. That seems like a lot of RAM to me!

I told one engineer about this, and he said this:
"For current processors a sobering thought is to look at bill of materials cost for [what] a Cortex M0/M1 based systems would cost and what it would offer in terms of functionality."

That is a good point!

It is unclear who would be interested in an 8-bit processor in the 21st century, given the low cost of 32-bit processors with megabytes of memory --- William D. Mensch said that the original purpose of the 65c816 was to be low-power enough that it could run inside a human body, but I never heard of it actually being used for that --- I have read that the MSP430 is used in pacemakers.

Anyway, if anybody wants to read my document, I attached it. Here is a snippet:
--------------------------------------------------------------------------------------------

The 65C02 is extensively used in implantable electronics. Can't vouch for the 65C816, though. Also, both of these devices find a lot of use in a variety of non-implantable electronic gadgets.

Something to keep in mind when dismissing the eight bit world as so last-century is that the power and complexity of 32 hardware is often not necessary or even desirable in many designs. Despite what one might think, eight bit microprocessors and microcontrollers are often more than adequate for most tasks. Embedded hardware running a microwave oven, landline telephone or washing machine seldom uses large data sets. Often, little memory is present, just enough in many cases to run the software. Things don't have to happen real fast, so high clock speeds are not a necessity. Just how would such embedded hardware benefit from a 32 bit microprocessor or microcontroller running at a ridiculous clock rate and addressing scads of memory? The short answer is it would not.

You wouldn't dispatch a battleship to sink a rowboat, would you? So why would you throw 32 bit hardware at an eight bit task?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's probably time to recheck that!



Agreed, it's interesting! I see several types of idea in the snippet:
- extra machinery for the alternate bank access (IP register)
- extra machinery for multi tasking (T bit, D register)
- some convenience functions (supporting YA operations, some of the exchange operations, MUL)

Certainly agree that hardware extensions are likely to work out best if developed in coordination with the software: for incremental changes like these, it should be straightforward to pick any open-source emulator and extend it.

For implementation in a small FPGA, again one could start with any open-source core. It almost doesn't matter what kind of modifications you are making from a capacity perspective, but it's worth checking that the design will fit and the speed will be not too much reduced. On the other hand, if building an extension using TTL or on a chip, the complexity will matter more.

In both cases - emulation and implementation - the complexity of the design will directly affect how difficult it is to test and debug. Simple is always best!

What you are describing is not very interesting. I've worked with the PIC16 that had, iirc, 128 bytes of RAM. I was decoding a keypad. The 8032 in single-chip mode has been used extensively for this kind of thing, as has the 6805. That is not where I'm going with the 65VM02 design though --- I support 128KB of memory --- I would expect the program to be written in a high-level language (Forth for me) and to use a multi-tasking OS.

You are right though, that high-speed is not as important as people suppose. Machines continue to have the same mechanical limitations on how fast they can work today, as they did 30 years ago --- inertia! --- not going away anytime soon...

BTW: That engineer who scoffed at my 65V02 design pointed out this link to me:
https://www.wemos.cc/product/d1-mini-pro.html
This board has a 32-bit processor, 16MB of FLASH, USB and TCP/IP with wifi.
He points out that it only costs $5.50, so I can't beat it on price with my 65VM02.
The major feature is internet connectivity. All that memory is mostly used for supporting a website.

Back in the 1980s a lot of people predicted that by the 21st century we would have a colony on the moon, and we would have something more high-tech than the gasoline-powered automobile for traveling around on Earth. None of that happened. The only difference between today and the 1980s is better communication. We have the internet now. woo hoo!

This is a good start to an interesting thread about your machine... but I suspect your later remarks will overshadow that.


Is it? It depends on what kind of discussion you hope to have. I'm interested in a discussion about your new machine, as a machine. Maybe you wanted a discussion about the market for your machine? That's a different discussion.


Indeed, but this forum is a good place to take it for granted as a set of interested people. Not necessarily interested as customers for a business, but interested in understanding and perhaps learning from your ideas.

Agree. The focus should be on learning something, having fun, and maybe dream a bit. Forget about competing with state of the art designs by big design teams.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Apparently the MSP430 has made some progress in those areas.

Mike B.

I completely disagree, as do many companies that produce embedded devices. If what you assert were true Bill Mensch and company would have folded a long time ago from lack of business. They aren't being sustained by hobbyist purchases of 65C02s and 65C816s.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I agree on that. And from my Physics background; less complexity also means less entropy, which is the definition on how to make something more stable. Over time that is.

So for someone going to Mars, they certainly would want to take many WDC 65C02 over a Unobtainum Xenon Pentium 10 running at 4000GHz. Its just going to survive for longer.

Then of course.. many machine manufacturers does not want their machine to last. They just want to sell more of the same garbage.

The good old light bulb: http://www.centennialbulb.org

(I also want to say that of all the MOS6502 IC´s I have in diverse equipment, 9 of 10 are still working)

It would be a bitter irony if one of us ever gets a pacemaker running a Z80. LOL

_________________
Cat; the other white meat.

GAK!! =8-O

I could tolerate an MSP430, perhaps. But 65C02 is closest to my heart (so to speak)!

[Just kidding. I admire what the Z80 designers accomplished given the need for 8080 compatibility.]

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hugh, can you elaborate about the T flag, please? According to your text document, "The T flag is set to indicate that a task-switch is needed," and you illustrate how the NEXT macro would include a BTC instruction to test T.

Would it be a timer-triggered Interrupt Service Routine that sets T, and/or might T be set by other means? Also, might T be tested at times other than when passing through NEXT?

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Well, I haven't written a multi-tasking OS, or had any experience in using one, so I'm speculating here.

Yes, the ISR for a heartbeat-timer can set T to indicate that it is time for a task switch.

There may be other cases in which T gets set. For example, an ISR that is inputting data into a circular buffer may set T if it is close to filling the buffer so the task that empties the buffer can get run --- presumably the OS is smart enough to figure out that this is the highest priority task to run.

One reason for doing a task-switch in NEXT, rather than in the middle of a primitive, is that less context needs to be saved. The A Y and P registers don't have to be saved because these are never used to pass data between primitives. This would be more important in a processor that had a lot of registers (the AVR has 16 registers and it has a T flag, which is where I got the idea). It is not very important on the 65VM02 because we have very few registers anyway --- there may be a lot of direct-page data associated with the task, but each task has its own direct-page so this doesn't need to get saved either. If the 65VM02 has any advantage over other processors (a somewhat dubious claim), then that advantage would be fast task-switches and low interrupt latency.

Another reason for doing a task-switch in NEXT, rather than in the middle of a primitive, is that this should be safer. Isys Forth would store data underneath the data-stack, and then cover up the data with DEX --- this was done to allow peephole optimization (functions that did INX did so at the start, and functions that did DEX did so at the end, so DEX and INX were juxtaposed and could be eliminated). This is not an issue on the 65VM02 however, because I can just make the rule that primitives are not to be written that store data underneath the data-stack (notice how all my primitives that do DEX have the DEX at the start).

I got the idea of the T flag from the AVR, but the 65VM02 is different because it has a lot fewer registers. It is possible that the T flag is not needed on the 65VM02 and I can just drop that feature. It is slowing down NEXT a lot. Maybe a preemptive task-switch in the middle of a primitive is okay.

BTW: There is a bug in CMOVE --- I'm surprised that none of you 6502 have pointed that out yet.

I've been thinking about the idea of a coprocessor that handles all I/O. It would have its own main-memory, so there is no bus contention. It would have access to the alternate-bank though, so any instructions in either processor that access the alternate-bank have to lock out the other processor from accessing the alternate-bank at the same time. I'm somewhat dubious of the idea of a coprocessor though. A better use of resources might be to just upgrade the 65c02's weak support for ISRs. When doing an interrupt, after saving the registers, D should be set to 0 and A should be set to an indicator of what caused the interrupt. This way the ISR doesn't have to poll the I/O ports to figure out what caused the interrupt and what needs to be done --- it could just do a JVM to get to the correct ISR --- so you would effectively have 128 different interrupts, rather than just one like on the 65c02 (I got this idea from the Z80).

Finally, let me say that I always thought the 6502 versus Z80 argument was foolish. There is a lot to be learned from the Z80. Similarly, there is a lot to be learned from the AVR and various other processors. It is not a good idea to become too focused on the 6502 as if it were a religion.