I had that 65VM02 design previously. I no longer think that it is very good --- unlikely to be viable for real-world projects --- only interesting to 6502 enthusiasts.

I have another design now that is much different. This one is derived from the 6502 but is not compatible with the 6502, so arguably is off-topic for this discussion group. I think it has the same feel as the 6502 though --- anybody with 6502 experience should feel more comfortable with it, than with the STM8 or MSP430 --- definitely better than the eZ80.

Honestly, I doubt a 6502-derived FPGA core will be of interest to anyone outside the 6502 enthusiast community. Don't let my opinion deter you - the fun is having a project and seeing it through from concept to completion. That's the challenge and the reward. If some like minded folk can find interest in the project and provide good feedback along the way then even better.

Good luck with it.

Looks like an interesting machine! From your text file:

Thanks for your encouragement.

I would think something like this could be used in the real world. The STM8 gets some use. Apparently these are projects in which low-cost is an issue, but high-performance is not needed (otherwise the ARM Cortex would be used). Being an FPGA it can be customized for I/O --- and also to get new instructions as needed to speed up the slow parts --- so that would be an advantage over an off-the-shelf processor such as the MSP430.

You may be right though, that it won't get noticed much outside of the 6502 enthusiast community. I'm not expecting to take the micro-controller world by storm. There are going to be a lot of people who say the PIC24 is faster, or the MSP430 is less expensive, or almost anything is easier to program, etc. --- I don't want to get into arguments with them --- this is my design, and I like it!

I have reworked this design multiple times. I have to stop refining it and get down to business in learning Verilog and implementing it. My design right now is very simple, with only a few registers, so it should be feasible as a first-effort.

I don't really know anything about hardware. I just program. The assembler and compiler are what I'm interested in. It will be interesting for me to write the system so that zero-page memory can be reused by multiple ISRs and subroutines, but there won't be any clash with one subroutine corrupting another subroutine's local data. Making a Forth compiler work without an actual stack will also be quite challenging.

BTW: I had a bug in my document. This is fixed code:

I also had some typos throughout --- none of this is important enough to upload a new file --- if there are any major changes, I'll upload a new file then.

For a new instruction set, like this, I would recommend you start with the tools: assembler, disassembler and simulator. These are software projects you can take on without help (besides Google), as you're a programmer... If you've never written an assembler before, then start with a simple two-pass assembler (no fancy macros, expression handling or conditional compilation) - just enough to write instructions, with branch and label support, and get a binary out that you can verify with a simple disassembler and then simulate. If you Google "assemblers and loaders" there's a great PDF book which you can download to give you insights. With these tools you can write code examples and test programs (which you'll later use on your Verilog implementation) and refine your instruction set until you're happy with it.

Tools are very important to anyone wanting to pick up your work. You're not going to sell this. Don't be under any illusions here. There's no real scenario where that will happen. Professional engineers who go out and buy 3rd party intellectual property go to established companies with a track record and look for RTL, test benches, often proven tape-out, parameters, power estimates in various technologies, professional support, software tools and lots and lots of legal paperwork. They likely want to find software engineers with existing knowledge of the architecture, so something bespoke is hard to sell, and they want a toolchain that's stable and easy to use. For a processor core it's common to have a JTAG-based debug port, too. They don't want to add new instructions and modify the tools. They're not building a processor chip, they're building a chip that happens to contain a processor (for reasons). I'm generalizing, of course.

So... what's left? opencores.org. You give your processor and tools to the world and say, "Here it is, I hope you like it". Both hobbyists and professionals go to opencores.org looking for ways to build or prototype their ideas. The bar is much lower, and the chance of acceptance much higher. A wishbone interface is the processor to system interface is appreciated, but for a 6502-style design it might kill the bus performance so something more native might be a better choice. Documentation for both the processor RTL and the tools is important, as is cleanly written code.

While you're working on your software tools, I would recommend you start playing with Verilog to implement small things: small registers, counters, state machines, an ALU... Learn with small little tasks and learn both the FPGA tools and flow, and how Verilog works. Get used to looking and waveforms and seeing how what you wrote translates into real behavior. Learn how to see the bugs in the waveform. Get an FPGA board and blink LED, use the buttons to effect behavior, etc. Do these little tasks on the side, between software work. By the time you've finalized your design and have the software tools complete, you'll be ready to tackle the Verilog and it won't be as daunting.

You seem to have a lot of energy, so I'm sure you'll make great progress. Good luck!

Thanks for the advice.

I agree that I need a simulator and assembler first, so I can write some code and see how well it works. Day-dreaming about the "perfect" ISA design is fine, but I expect a lot will change in the crucible of testing.

I have written an assembler before. When I worked at Testra I wrote MFX the development system for their MiniForth processor (now called RACE). There could be up to 5 instructions packed into a single opcode, all of which executed concurrently in a single clock cycle. My assembler would rearrange the order of the instructions in order to pack as many as possible into each opcode (minimize how many NOP instructions had to be inserted), while still guaranteeing that the program did the same thing as it would have if the instructions had been assembled one per opcode in the same order that they appeared in the source-code.

My 65ISR is pretty easy in comparison to the MiniForth. The 65ISR is just a traditional processor without any significant features beyond the 6502 etc. that have been around since the 1970s.

My assembler for the MiniForth was written in UR/Forth though. I used UR/Forth as the macro language; there was no real distinction between writing the assembler and writing macros in the assembler. I have never written a traditional "macro assembler" however. I will have to write that as a wrapper around the Forth assembler because otherwise nobody will use it --- this will be new to me --- should be fun!

(you might be interested to check the forums over on anycpu.org - there are a number of novel CPU designs ongoing there, some with assemblers and emulators, and we can all learn from each other's projects!)

I posted a mention of my 65ISR there, along with a slightly updated version of the document:
http://anycpu.org/forum/viewtopic.php?f=13&t=421

The 65ISR is off-topic for the 6502 forum because it is not 6502 compatible. Any discussion of it should go over there to that thread --- anycpu is okay with any cpu.