The 6502 is an odd chip - everyone seems to love it. Clearly that has to be for good reasons.
(Sorry granny I know you know how to suck eggs....)

I was wondering what a modern chip built with the 6502 philosophy and "feeling"
would look like today.

Would it have 32bit data bus and registers, would it clock at 4Ghz, would it have a built
in FP processor or an external one. a flat memory space.
Would it make any sense at all?

What do you think?
if you had to design a 6502ish processor today what would you do?

That depends on what part you consider the "6502 philosophy"...

Whatever the reason is that this forum exists?
You don't generate this sort of enthusiasm without doing something right - but what is it?

viewtopic.php?f=1&t=4216

viewtopic.php?f=1&t=784

Mike B.

For me, it's mainly nostalgia, because the 6502 was my first CPU. But there's much better stuff now.

What's so odd about it?


Probably like a 65C816, but with smaller geometry so it can be run faster.


Doesn't sound like a 6502 to me.

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

The RISC-V architecture is a clean and new design, worth looking into if you like that sort of thing.

The crucial feature of the 6502 is that it was cheap, and one reason it was cheap was that it is fairly simple and fairly regular. The ease of learning to use it has helped it to stay popular. It was made by a small team in a small company. The spiritual descendent of that is the RISC approach, and the ARM, designed and made initially by Acorn, a very appropriate example. Although ARM isn't a purist's RISC, it was made to be simple and cheap. (The reason it is low power is that to be cheap it needed to be in a plastic package and therefore had to run cool.) As you may know, ARM was designed on 6502 systems by 6502 experts.

But today ARM has become rather complex, and RISC-V is a likely successor. Unlike ARM, it's free and open source.

In my opinion, the biggest design difference between the 6502 and modern cpus is that it has single-cycle access to all memory. Bulk memory doesn't really work like that anymore, and once you start dumping cache layers on the 6502, you lose a lot of its simplicity and coding style.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

The 6502 was a good architecture for it's time, but now times have changed.

Modern processors are designed for executing high-level language code, specifically C like languages. There's a lot of code out there now that you wouldn't want to throw away, so any worthwhile modern processor will most likely run compiled C like code. If that is the case then the character of the processor is not really important.

The 6502 was designed when memory was faster than processors, so many decisions were made because of this. Today it is the opposite and that is why we have caches and large register files. So a modern processor would need these too, further moving it away from the character of the 6502.

Direct page is hard to work with in a multitasking operating system, so it's benefits largely disappear.

It is interesting to look at the x86 architecture evolution as this gives us an example of a 70's design that has evolved. In the end though I'd think that very little of the character of the 8080 or 8088 still exists in the modern chips.

As a hobby CPU though we could look at it differently. What could be done to increase the performance of the 6502 to a level that it could be more useful, while still being a 6502. That is probably a more interesting question. The 65C816 takes one step in that direction, but it's interesting to see that it does not get all that much attention compared to the 65C02, many people prefer the nostalgia of using an original 6502 to the benefits of the 65C816. In my opinion I think that the 65C816 is a more interesting chip to use today than older 6502's. It definitely has some advantages for targeting high level languages. One interesting thing when implementing a compiler for the 65C816 is that there is almost no need for register allocation algorithms (because there's basically no registers ), and that makes a compiler easier to implement.

Not so with the 65C816 in native mode. Each function in the kernel can have an ephemeral direct page if needed, as can each task. So the benefits of using direct page are certainly attainable in a multitasking operating environment.

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

It is called "ARM".
They started on 6502 but wanted something faster.

https://www.theregister.co.uk/2012/05/0 ... ve_furber/

https://news.ycombinator.com/item?id=8549467


http://atariage.com/forums/topic/201370 ... from-6502/

_________________
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?

Yes, I guess so. I still get a bit hung up on the limitation of bank 0, in that you need to have both the stack and DP fit within 64k. So far this is theoretical as we don't currently have a multi-tasking operating system for the 65C816. I guess I'm also struggling to get used to the smaller resource requirements of these kinds of systems, but even with say a 4k stack you'll only have room for 16 processes. Given that we can now relatively cheaply fill up the address space of the 65C816 it seems that the main limit is on bank 0. This could be fixed with a MMU if someone were inclined to build one, but that may be overcomplicating the system.

_________________
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?

I would like to have a multitasking system with as few limits as possible. That is generally not possible without a full MMU as you don't have the flexibility of moving memory around as needed.

My end target is a 65C816 C compiler that runs on a 65C816 system. A C compiler (written in C) will require quite a bit of stack space. Since this is for the 65C816 I'm using the stack for local variables. If the stack was limited to being a call stack only then the stack could be quite small, but there are a lot of nice addressing modes on the 65C816 that make use of the stack.

In the end I don't think I know enough about the memory requirements to make any concrete decisions, the only way to find out is to build something and then see where the limitations are. It should be relatively easy to reverse any decisions that turn out to be impractical.