6502.org

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?

In Microchip's Wayne Freeman's Dec 12, 2016 Electronic Design article "11 Myths About 8-Bit Microcontrollers," the #1 myth he addresses is that the 8-bit is going away. He says, "Gartner’s 2015 Microcontroller Report lists the dollar value of both 8- and 32-bit annual sales in the ~$6B range—roughly equivalent to each other. Given the differences in average transaction price, the math tells us that there were three 8-bit MCUs designed into embedded systems for every one 32-bit MCU in 2015. Going away? Not anytime soon."

In May of 2005, I wrote to Bill Mensch asking for good reasons to use the 65-family processors, for an article. One of the things he said was, "The 65xx architecture is sold in hundreds of millions of chips per year, and the volume is growing. We now find engineers porting applications that might have first been market-tested on PCs or ARM processors and finding the 65xx economy (both business and silicon) attractive and well worth the effort to change to the 65xx." Right from Bill Mensch himself is the first-hand info from his talking to his customers, that they considered the ARM first and then decided the 65xx architecture worth changing to—for some applications (obviously not all).


I can't imagine needing the power of an '816 for a pacemaker. My information may be outdated; but I had heard that the '02 is the only microprocessor approved for, and used in, pacemakers.

Jeff and Ed recently pointed out the HuC6280, a PC Engine using a special version of the 65c02 (with all the modern CMOS instructions except STP and WAI), with a memory management unit (MMU). Of special interest are the instructions directly involved with memory mapping and moving, and a T flag, which when set (using SET), causes accumulator instructions to operate on the ZP address pointed to by X instead, without affecting A! It makes it like having 256 extra accumulators, but it does it without breaking legacy code.


You have some interesting instructions there. It will be interesting to see how it works out in actual applications. I have wondered, more and more, what the best way to work on new instructions is, regarding the balancing of their hardware requirements against the instructions' practicality, discovered only through extensive programming, seeing whether modifications should be made before the hardware is done. Both will take time. Chicken and egg. Of course with programmable logic, you don't commit to silicon; but a complex design still takes time. As a minor point (affecting only the assembler), I do suggest using a different name for your INA, since the 65c02 and '816 use INA to mean INC A. Beyond these, I don't think I have any comments yet which we have not talked about in other recent topics.

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.

I don't know if it matters, but maybe I should have said "defibrillators," and possibly "implantable." Spending a lot of time reading web pages from a search for "65C02 defibrillator," the only thing I have found is lots and lots of websites with exactly the same wording: "The Western Design Center, Inc (WDC) introduced the CMOS 65C02 in 1982 and licensed the design to several firms. It was used as the CPU in the Apple IIe and IIc personal computers as well as in medical implantable grade pacemakers and defibrillators, automotive, industrial and consumer devices."

WDC's site does say the 65C02 is used in defibrillators, but so far I have not been able to verify that it's the only one used in them. However, one man who worked on them says, "On the ICD I did some work on they used a 65C02 processor, which they needed to get certified outside the normal supply chain (look at any datasheet for ICs and it usually says “not for life critical…”). Then they need to get ALL the software to pass FDA rules (lots of time and $$$). By the time everything is done, the development cost is HUGE." (This may explain why, after one was found to do the job just fine, the expensive approval process was not repeated for any other processors.)

The Jameco site has what I expect is probably a quote from their communication with WDC, "These chips are far from obsolete today. From hobbyists and DIYers to big corporations, the 65xx chips are relevant in almost every field. In the medical field, places like St. Jude's Children's Hospital and Medtronic make medical devices using the 65xx chips to create defibrillators and mammogram devices."

The defibrillator patent specifically mentions the 65C02, recommending it, but no others.

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.

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

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.]

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

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.