I have a design for a processor (file attached) in case anybody is interested.

I don't know anything about Verilog --- I will have to learn it to implement this thing --- I'm just a programmer.

I will look into what you guys have going on over here. I am not familiar with this forum.

Welcome, Hugh! Take a look around, and you should recognize at least a few people from elsewhere ... I hope that you like it here! I felt at-home almost immediately.

Mike B.

Welcome Hugh!

Thanks Michael

How is your 65M32 design coming?
I was somewhat dubious of designing a 32-bit processor because the ARM Cortex dominates so much --- that is like challenging a silverback gorilla to a boxing match --- even processors such as the ColdFire, that are pretty cool by any estimate, have become obsolete (crushed by the gorilla!).

I'm aiming very low with my 65ISR design. There is no main-program, just ISRs. The chico version doesn't even support subroutines or 16-bit pointers. I may be aiming too low, and will shoot myself in the foot --- it is possible that everybody will say that even the 6805 is more powerful, and the 6805 is long obsolete...

You likely know more about 6502 assembly-language than I do. You have stayed in practice all of these years! Do you think that 6502 enthusiasts will feel at home with the 65ISR? Can meaningful programs be written for the 65ISR, or is it too limited?

BTW: What computer do you write 6502 assembly-language for? I am familiar with the Commodore-64 and Apple-IIc.
I liked the Commodore-64 --- the C64 had very good support for sound and graphics! --- I used SuperForth on the C64 and ISYS Forth on the Apple-IIc (actually a Laser-128 clone).

A design which is based around ISRs only sounds refreshingly original. Things will have to be done a bit differently. Sounds good to me!

I've been told elsewhere that this idea is not very original. It is called "event driven processing" and is well-known.

I find the idea to be intriguing! The advantages are:

1.) Fewer clock cycles are required because there is no save and restore of registers for each ISR.

2.) The processor is simple, because there is no return-stack. This helps put it within reach as my first-ever HDL effort. The chico version is super-simple, so I can start with that.

The disadvantages are:

1.) Interrupt latency is greater for the high-priority interrupts because they may have to wait for a low-priority ISR to finish, because they can't interrupt it.

2.) Programming is more difficult. The main-program has to be cut up into short code chunks for VIRQ that each end in RTI allowing an interrupt to occur. It is up to the programmer to manually save and restore context from one code chunk to the next. In the chico version, there are no subroutines or pointers.

Pretty intriguing idea!
It is an experiment in designing the simplest possible processor that is capable of supporting meaningful programs.

I have had to push it to the back-burner for the last several months. I have a 76-year-old house that is falling apart, and several cars that are falling apart too. I have also been spending a lot of effort trying to get a new job with better pay and less physical strain. My mother-in-law is starting to become more and more dependent on me as well. The 65m32 has been living in my imagination for nearly half of my 51 years, so I think that it can wait until I can give it a better time-slice of my attention, assuming that the competition quiets down a bit.

I'm not trying to compete with ARM or anything else ... I just want to show something I think is neat to people who might be interested and agree. If they agree then great; if they disagree or lose interest, then not-so-great. I'm not going to be offended ... I don't have a great deal of emotional investment in it, but I would be very pleased if it made it into an FPGA one of these days. The simulator is first, and it's still only about 80% complete.



Just follow your instincts. If you get discouraged, take a step back and see if anything can be saved for your next plan. The journey can be as rewarding as the destination, if you have the right frame of mind.



It looks very "learnable" to me.



If I want to try out some 6502 creations, I whip out AppleWin. It's convenient and familiar to me. My first home computer was an Apple ][+, and it was and always will be my first love. I also had a C=64, and I liked it, but it never had a chance to replace the ][+ in my heart.

Mike B.

Well, if you do make it into an FPGA eventually, maybe I will write a Forth for it. I skimmed over your description and it looks like it would be a reasonable target for Forth.

I think I mentioned this before, but I have a <SWITCH in ANS-Forth that generates a jump-table (unlike the CASE that generates nested IF statements). This would work well for a simulator. I would recommend writing both the simulator and the assemble in Forth rather than C --- Forth supports meta-compiling, and it is interactive! --- I wrote MFX in UR/Forth when I worked at Testra; realistically this would have been several times more difficult in C (difficult enough that it wouldn't have succeeded).

What are your thoughts on Michael Morris' M65C02A soft-core? If I do write a Forth for a 6502-derivative, that would be the most likely choice --- a 16-bit processor might get some use as a micro-controller, which seems unlikely for a 32-bit processor because (as I said) the ARM Cortex dominates so much.

I started another thread in the nostalgia section: viewtopic.php?f=22&t=423
The M65C02A would be a possible choice here.

P.S. I hope things work out for you in regard to finding a less physically-demanding job, taking care of your family, etc..

Yes, I wanted to say that it resembled event driven software.. but I was on a mobile device and couldn't write much. So, the concept is known of course, but mostly from software. I like the idea of a CPU that works that way, and only that way, in hardware.
[Edit: Typo : even -> event]

I think it is an intriguing idea! Doing it in hardware boosts the speed because there is no save and restore of registers. I wonder how much could be done on such a system...

I got the idea from the Parallax Propeller. There you have six coprocessors handling I/O concurrently. With my 65ISR you have multiple IRQs, so it is not concurrent, but they have to wait for the other ISRs to finish. Programming would be similar though.

I have been talking to Walter Banks of ByteCraft --- he told me about his RS08 processor.
The 65ISR-chico is more powerful because it has an indexed addressing mode, which is useful for circular buffers.
The RS08 has a link register for subroutines however, that the 65ISR-chico lacks, although the 65ISR uses the W register for this.
The 65ISR or 65ISR-chico would be similar to the RS08. A compiler, or at least a smart assembler, would be needed to prevent clashes between subroutines using the same zero-page variables as local variables --- this is because the 65ISR lacks a stack for local variables --- the RS08 is always programmed in C, and never in raw assembly-language, for the same reason.

I'm mostly a programmer with an interest in compilers. Hardware design isn't my thing. My interest is in writing a compiler for such a challenging target.

Eight, not six..
Yes, I almost mentioned the Propeller in my reply. The difference is of course that the Propeller 1 doesn't need interrupts at all. But it's a valid comparision - on the Propeller you write your code/program/driver to run in one cog, and then another for another cog. No need for a main program.

Eight then --- I was just going by memory, so I had it wrong --- I have not actually used the Propeller, but just read about it and found it to be an intriguing idea.

Have you used the Propeller? How well did that work out? What did you use it for?

I'm surprised that it has become so popular, because it is very non-traditional. It seems like it was designed for fast I/O but minimal processing.

I'm not really expecting my 65ISR to become popular among hobbyists, or even among professionals doing onesy-twosy projects. There are lots of chips, such as the PIC24 or the ARM Cortex, that are much more powerful. Cost is not very important on onesy-twosy projects. Such a tiny processor as the 65ISR might be used in high-volume projects in which counting pennies is important, but maybe not because FPGA chips are expensive --- an ASIC would be great --- that would require a huge upfront investment though.

When I worked at Testra I encouraged them to build an experimenter board based on their MiniForth processor. They didn't do this.
I was told that they didn't want to sell to hobbyists because: "hobbyists require too much support, and they don't have any money."

That was in 1994/1995. The MiniForth was built on the Lattice isp1048 PLD. In those days, it was possible to build a custom processor that was both less expensive than and faster than the competitor's system (using an MC68000 and programming in C). Nobody else has ever built a custom processor on the Lattice PLD --- it was only possible for Testra (they had written their own HDL in Forth, rather than use Lattice Design Language provided by Lattice).

The MiniForth is now called the RACE and is built on an FPGA, and is implemented in VHDL rather than any custom HDL (a custom HDL is not possible anymore). It is a different world now. Lots of people build custom processors on FPGA chips. None of these really compete well against the ARM Cortex in either price or performance. The custom processors are mostly used when custom I/O is needed that isn't available in an off-the-shelf chip and/or there is a speed bottleneck that can be relieved by adding some extra instructions to the ISA.

That is my understanding of when and why FPGA processors are used. I don't have any actual experience other than with the MiniForth, and that was over 20 years ago.

When I worked in applications engineering at M/A Com PHI which made VHF & UHF power transistors, I was told the same thing when I thought there might be a sizeable market among radio amateurs. However, I think one big thing that made for Microchip's growth in the mid-1990's was that they offered their free assembler and simulator and a very low-cost programmer, things that were no big deal to companies but huge to hobbyists who got going on PIC microcontrollers, and when they graduated in engineering and got jobs, they took it into the workplace. Of course today there are several well established microcontrollers, so it would be harder to elbow your way into the market.

Well, that was their policy. I didn't say that I agreed with it.
They had experience with this though. When the company was called Hartronix they advertised in "Forth Dimensions" to sell their bit-slice Forth processor. It is possible that this experience was bad --- too much of a hassle supporting hobbyists --- not enough money to make it worth the time and effort.

MicroChip is a big company that can afford to hire help-desk employees. At a small company, who exactly is going to man the help-desk? I wasn't volunteering for this, because I'm a programmer --- I can see how the help-desk could become very time-consuming and tedious (it has been said that there is no such thing as a dumb question, but that isn't really true!).

I agree that MicroChip is successful because they provide good development tools for free, and a lot of support. The early PIC chips were difficult to program, but people still used them, mostly because MicroChip provided a lot of support.

Over on the 6502 forum I was told that it would not just be hard for me to elbow into the market, but impossible. The only possibility is that my chip ends up on http://www.opencores.org as an open-source freebie. Maybe it will get picked up by somebody for use in a commercial product, but I wouldn't necessarily hear about this --- nobody is going to say: "thank you" --- by that time, I've already provided all of the tools (assembler, compiler, etc.) they need, and all of this is open-source, so they have no reason to communicate with me.

I suppose it's hard to predict what will make something successful. I have a friend who's in advertising, and he says the same thing, and that sometimes strategies you think will succeed don't, and vice-versa. We see examples of products like this in the markets, whether it's something really good that's misunderstood or perhaps doesn't hit the market window perfectly so it does poorly, or something that's lousy but is pressed by a strong sales team taking advantage of certain circumstances (or in some cases, probably not microprocessors, even creating fear). Some advertising tactics try to be self-fulfilling prophecy. "This is the next big standard that everyone will be going to; so don't be left behind." Industry magazines which are always trying to see further into the future to be ahead of their competitors, and after doing their research into new things in development, add their own hopefully self-fulfilling prophecies, when they really don't know.

I've had a few of these situations over the years: