It is apparent that people have several different goals in choosing or implementing a 6502-like core. This can lead to miscommunication when features are proposed and discussed. I think it would be good to point out which camp you belong to or target:

As I see it, here are the distinct categories
1) Hardware-compatible. Cycle and phase accurate target, perhaps a drop-in replacement to 6502 in existing hardware.
2) Cycle-accurate. Useful for implementing clones of old system; will play games etc.
3) Instruction-compatible. Not cycle accurate, but will execute the code generated by a 6502 assembler.
4) 6502-like. Not necessarily code-compatible, but inspired by 6502 features and hardware.

If you can think of catchier names or other categories, please contribute...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

You are right, also there is a difference if they should be synthesizeable or not I guess. It is often impossible to synthesize something that is triggered by a falling CLK edge on FPGA (but it would be synthesizable for ASIC, but honnestly, who have the funds for it ?).

Also I feel a growing interest in designing a super powerful instruction compatible processor with a deep pipleine that would be like a 6502, but doing almost everything nonbranching in 1 cycle. Also I think this would actually be a lot easier to do that doing something that is hardware accurate ^^

There are a lot of pitfalls, as the 6502 is hardly a RISC machine and there are a lot of paths to consider. Consider the '32 bit is new 8-bit' thread, and make sure to read the long-winded notes I posted on page 6 barely scratching the surface.

You'd be better off implementing a RISC core with minimal paths, specifically fine-tuned for 6502-like operations (alu and flags matching 6502), and using it as a microcode machine. You can break the 6502 instructions into 'micro-ops' and execute them as fast as possible then...

All in all, the 6502 is pretty good as is, especially if you don't care about cycle accuracy. Considering the amount of work in each operation (that would take 3 ops or more in a RISC processor). In that context, even 4-6 cycles is not so bad.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

It is no RISC machine, not even hardly.


Yes in fact this is what I had in mind. I've already made a RISC core, now I could adapt it to be 8 bit instead of 32 and change it so that it is best suited to execute 6502 instructions.

The idea I have would be to do a 32-bit instruction fetch (all 6502 instructions are either 8, 16 or 24 bit, so all of them can be fetched in a single cycle) followed by a decode stage which would asynchronously tell the fetch stage the length of the instruction it just fetched, so it can increment accordingly (it would manage to provide the next 32-bit with some kind of simple shift register/FIFO).

Then the decode stage would send microcode to the RISC machine (in other words CISC to RISC converter) and voilà. If the RISC machine is designed greatly, most instructions could be done in 1 cycle, but only if zero page is constantly cached. I'm not too sure how that part is supposed to be done so I'll have to think a bit more.

EDIT : OK this topic is already widely debated in the other thread, sorry for brining it here ^^ All the difficulty is how much importance you add to fetching instructions in Z-Page and access Z-Page with non Z-Page instructions. If you drop both, then 1 cycle per instruction is easy to get. However this is not a 6502 any more if it can't do that

Mis-aligned writes and to a lesser degree reads cause problems. And don't forget pipeline hazards such as reading immediately after writing (before the pipeline clears). And 16-bit reads/writes from stack... Well, I listed a whole slew of issues on the other thread...

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut