BigEd wrote:
Here's a thought. If we think, for example, of how to perform a version of lda (n),y on the 6502 where both the n and the y are 16-bit quantities, that would take quite a few instructions, bytes, cycles. All we need to do in the instruction encoding for an improved machine is to beat that density and speed comfortably - we don't have to fit it into three bytes. Even five bytes would be a win, I think.
I don't completely catch the idea. IMHO it is obvious that the better code density means the better speed because of the better cache performance. If we have 24/32-bit address space then n and y should be 24/32-bit too. But if we have zp-registers then what is it all for?
I also miss a bit the point in an idea that 6502+ has some disadvantage compared with x86. 6502+ shows that 6502 had very big potential for its further development and with proper support would be the best to the our time. Intel x86 is good, better than DEC PDP/VAX-11, Motorola 680x0, NS 320xx, ... but 6502 was better (IMHO). Intel won because it had much more resources and Motorola was too stupid to support the better CPU and its better future.
BTW I can share yet another idea which can make the position of 6502+ even more better. The second accumulator would have to have the double width.
It would be a thing similar to z80 HL-accumulator but with the full range of operations. It would be 16-bit at the 8-bit data mode, 32-bit at 16-bit mode, ..., 128-bit at 64-bit mode. All operations with zp-registers would be very fast and short. Every ALU upgrade would make them much faster.