For me, there's no fear, but I grew up with the 6502, not the 65816. After the 6502, I got an 68000 and right now I'm mostly working with ARM. The '816 would be a big step back.

Most of my modern embedded applications have a few kB stack per task, mostly for local buffers, for formatting/parsing data, file/network buffers, and just general local variables. The advantage of putting most of the variables on the stack is that they are automatically freed when you no longer need them, so you can reuse the memory for something else later. That's more efficient than using static data.

Even if we believe that number, it doesn't really make sense to do that. You'd get a lot more performance out of a bigger CPU running at lower speed.

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

If you don't need more than 8 bits, you probably also don't need 10 GHz

The savings on silicon real estate aren't very useful, because the only way you can make a 10 GHz CPU is by putting the memory and peripherals all on the same chip, which, combined with the I/O pads and PLL, will take much more room than the actual core. At that point, it costs very little extra room to use a small ARM, which you can then let run at lower frequency for the same performance.

It's a crying shame that the 65816 didn't get used in more devices. Both the SNES and the Apple IIgs were sorely underclocked, in terms of showcasing the processor. The SNES wasn't user-programmable, and the IIgs just didn't have the reach to cement it as a familiar CPU you grew up with. Yeah, 68k was around, but the '816 would have been perfectly at home in more lower-cost computers and speed-competitive to the early 68k, making for a great value. Of course, this would have had to come from a company that didn't have a 68k platform that would be undermined...

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

I didn't even know there was such a thing as the 65816 until a few years ago, when I joined this forum. I think it arrived to the market too late, a few years after the 68000.

Some interesting comments and food for thought.
Thanks

If anyone has more it's welcome.

It's not ideal but that's the way it works. However, programmable logic could be used to sandbox direct pages and stacks so they appear to be in bank $00 but are not.


It is highly unlikely you will need a stack larger than 512 bytes, let alone 4KB. I make extensive use of stack frames in 65C816 software I write and the deepest I've had the stack so far is 150-or-so bytes. Even after accounting for the stack frame created during interrupt processing (nested interrupts, at that) there's still plenty of headroom left with a 256 byte stack.


There is extensive discussion around here on bank remapping and other aspects of 65C816 hardware management. I wouldn't see it as overcomplication, just the next step in putting the '816 to work in a hobby system.

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

I happened to notice a related item mentioned on Hacker News today. It's a blog post regarding memory bandwidth, and it makes some comparisons between modern processors and older devices... such as the 6502!

The blog post itself is here. The related Hacker News discussion is here.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Not only have processors gone up in speed faster than memory bandwidth, the increased memory bandwidth comes at a cost of much higher latency (measured in clock cycles, not nanoseconds).

edit: Hmm.. now I see you already posted that.

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

Not necessarily, but today's technology can't do 10GHz over I/O pads, so that kind of speed is only useful if you do a bunch of internal calculations. And most real world calculations benefit from using 32 bit and some more registers.


The ARM is just the core, just like a bare 6502, although they are typically made with peripherals and memory in the same die. The point is that the core is only a small part of the silicon, so keeping every else the same, substituting the 6502 for an ARM doesn't increase silicon cost all that much. On a small design, on a modern process, silicon area is mostly determined by number of I/O pads, because these require huge transistors, and ESD protection and space for the bond wires.


Depends. In many cases, even solving 8 bit problems, you'll be using 16 bit pointers. A simple, common, sequence like this:

takes 10 cycles on the 6502 (and uses 2 out of 3 registers), but would only take 1 cycle on an ARM. Other things, like copying memory, benefit from 32 bit loads and stores, even if you're not doing calculations. The ARM has more registers, so less need to push/pop, or use slower memory. So, it's not so far fetched that a 500 MIPS ARM could match a 3GIPS 6502 for speed, even doing mostly 8 bit stuff. And 32 bit isn't just for talking cars. A simple application that benefits from 32 bit could be a sensorless brushless DC motor controller for a home appliance.

I learned ARM assembly on ARM7TDMI, which has about 50 instructions and 5 addressing modes, all quite regular. Took me maybe 2 days until I could do 95% of the work without looking at the manual. The complexity is somewhere between 6502 and 65816. In many cases, having 32 bits and 16 registers makes things a lot easier, because most results (be it addresses or calculations) fit in a single register.

Somewhat related: elsewhere Arlet asked what kind of 8-bit CPU could we design to fit in the same resources as a 6502, in 8 bit CPU challenge, with four or five machines as responses.