Apparently cardridges for video consoles could not keep up with the speed of CPUs and the 6502 in snes needed to be throttled down.

According to one line of reasoning (BigEd could provide the references for this) the 6502 was originally intended to have two accumulators. But they found this would've resulted in too large (and hence too expensive) a chip. So a brutally ruthless decision was made. The chip got very rudely downsized quite late in its development -- leaving some gaping holes in the opcode map.

I wonder if their 2-accumulator design had "A = A op B" style instructions.

If not, then yeah a XBA would cover plenty. (And you might as well go for XAC, XAD, XAH, XAL ... )

My strong suspicion is that originally the 6500 had *two* accumulators, and the instructions with low bits 11 were like those that now have 01, but for reg B instead of reg A.

DRAM refresh cycles are driven by the VIC-II in the C64. It's the basis for the arrangement. The CPU runs at half the speed of the memory in order to let memory access appear instantanous. This saves circuitry for arbitration. I still think it's a bad idea that the VIC can steal memory cycles from the CPU. For wide words a faster clock means better utilisation of the transistors doing the grunt work. But clock generation and distribution comes at some cost. Also some chips from MOS were prone to overheating. I am sure that a basically low clock rate allows lower supply voltage and higher resistance in the pull-up resistors keeping the current consumption low. If we would use the 6502 in an embedded application, it would be nice to add DRAM refresh. It may be that branches within a cached loop lead to pipeline stalls and a cycle where the 6502 does not access memory. This could be used for refresh. For this the refresh counter would be allowed to stay some ns behind schedule. Of course this means that there are is no cycle timed code. If one uses it for a woz-machine for example, the disk controller would have to generate the DRAM access.

If we could employ a large on-chip cache, bus width cost goes down (no more pins). Then use ARM. Apparently cardridges for video consoles could not keep up with the speed of CPUs and the 6502 in snes needed to be throttled down. They could have used an ARM with large on chip cache and try to eliminate some of their co-processors. It was 1991 after all. Amiga came out 1985.

And for RISC: I do not understand how you could read and write on the same bus in one cycle. We do not have enough die area for two busses. At most there could be two sets of registers each which their own bus. For example Akkumulator latches the output from ALU. Everything else is on bus. But then how could AX be used as source and target in every 8bit CPU? There need to be two and a bridge to toggle between them. Two busses do not seem that more complicated. This reduces code space.

Would the index registers be 16-bit?