All these changes keep 100% compatibility with the genuine 6502. The only small problem is the fix of zp,X warp but as the fix of 1977 it will not be a problem at all.

It is an interesting idea so as (X),Y or (Y,X) but there may be problem with not enough code space.

No, because it will consume code space but RWM instructions like ROR, DEC, ASL will take only 2 cycles instead of 5 and key for 6502 architecture ZP addressing will become 2/3 faster. This would make arithmetic at least 2 times faster. LDA 10 or STX 30 would take 2 cycles instead of 3, ...
EDIT. 6502+ architecture can be easily expanded to 64-bit keeping compatibility with 8-bit software.

_________________
my blog about processors

So, have you thought about the opcode map, and how it would all fit ?

The promoted changes will require a lot of opcodes for the second accumulator instructions only. 6502 has more than 80 unused opcodes. All accumulator instructions occupy about 70 opcodes - it will be enough. Other free opcodes would be used for work with the mode register (1 or 2 opcodes, to write and read or just to write as at 6309), for multiplication and division, etc.
EDIT. Of course, we need TAB, TBA, XBA. Instructions like eXchange A with Memory, e.g., XMA (zp),Y can occupy 2 byte opcodes. Two and later three byte opcodes can give all extra instructions like CPUID or for the work with additional accumulators and index registers.

_________________
my blog about processors

It's an interesting thought experiment, thanks litwr.

I'm sure that backward compatibility is greatly important, as Arlet notes. Indeed, I'd think that even then, you need some stability, so a new product every two years would be a better idea than every year.

It's an interesting idea to bring in just a little of ZP to allow faster pointer dereferences and RMW operations.

Thinking of these as fast ZP, not as registers, might be worth considering. That is, you don't necessarily have instructions to deal with them as registers, and you don't expect to save and load them on interrupts or function calls.

There's another approach, which is to make a small ZP cache. Say, the last 4 ZP locations referenced, or the last 8. It's more complex to design and test, but easier to use. There's a disadvantage: indeterminacy.

I'm sure at some point one would introduce a 16-bit wide memory interface - you do mention that in passing. And then, later, 32-bit wide memory interface. But there's a difficulty in doing that within a 40-pin package.

Some point between 16 and 32 bits, I think you need to introduce a privileged level.

Comparing this design with other CPU designs, I think the zeropage remains a weak point. Even if you can successfully pipeline the (zp), y addressing, you're still stuck with a very limited set of operations that you can do on zeropage.

Unfortunately, I don't see a way to replace zeropage with something more powerful without breaking backward compatibility.

For all its warts, the 8086 turned out to be an excellent future-proof design, allowing massive improvements while still supporting old code.

Once you add a code cache, you can get more work done on data, and you can tolerate longer instructions, perhaps using prefix bytes like the Z80 and x86 do.

Once you have prefix bytes, you could allow for zp-like indirections on two-byte addresses. I think I prefer that to the idea of a relocatable zero page, which uses a new register for the upper byte.

(When I say two-byte addresses, of course eventually that becomes three-byte or even four-byte addresses.)

I think, today, I prefer prefix bytes to mode bits. But I think they are quite expensive without a code cache, or at least a small prefetch buffer which allows tight loops to run at speed.

IMHO the hypothetical zp-registers claim to be the functional equivalent of z80 B, C, D, E, H, L-registers which may be combined into pairs BC, DE, HL. I think that instructions POP and PUSH for zp-registers would be very useful, z80 has advantage over 6502 using them.
The prefixes are the good supplement to the mode model. Intel x86(-64) is unthinkable without both. However I am not sure that they are good for 6502+ ISA because there is a fast mode change instruction, it may be used as a prefix.
BTW we need 2 bits only to describe mode: for data 8/16/32/64-bits and for addresses 16/24/32/64-bits. So 6 bits in the mode register will be enough to describe all modes. However I prefer to have 2 more bits describing X and Y index registers separately.
And indeed I want to use (zp,X),Y addressing with later 6502+.

_________________
my blog about processors

Have you experience using the '816? It has two width modes, one for data accesses and one for indexing, IIRC. It's not easy to get started with, and there are a whole load of subtleties to what happens.

It's kind of interesting within its constraints, but I find I prefer a machine with wide registers, where the operations apply to their appropriate data width. The difficulty with that, for a 6502+, is that we started with 8 bit registers, so we're forced to have a mode to adjust the width of the machine. But, for me, best to make that a uniform width change: 8/16/32/64 for all registers. And then use prefix bytes or modifier bytes to set the width of individual operations.

You may also consider zp-registers as dedicated address registers of 680x0 which has limited set of operations for them. Zp-registers give us a lot of fast pointers. Of course, GPR are better but a-lot of zp-register may outperform small number of GPR.
Later models of 6502+ with wide data bus and proper pipelining would have any operations for zp-registers implemented by multi-byte opcodes.

All these subtleties are the same as with Intel x86 ISA. IMHO 6502+ shows cheaper and faster design. Is it perfect? No.
Who uses assembler to program of modern CPU? Just several geeks, compiler and OS coders. All mentioned problems are solved by compilers.

_________________
my blog about processors

Compilers... that's a good point. But do you think they work well with lots of modes? I'd think they would set-and-forget, making some single simple choice.

True, but at least they had adda, suba, cmpa, lea, and movem. Also, the addressing modes allowed both index register and immediate offset, as well as auto inc/dec.


I think the x86 is much easier to keep track of. For 8 vs 16, it had the 'w' bit encoded in the instruction, making it easy to switch back and forth. And the '386 has a default mode (which you should set once), plus a prefix per instruction.

Nice, but this usage would cost +1 cycle - using abs+x (available) yield the same speed at the expence of one more program byte.
Adding an offs,S address mode would be more versatile IMHO.

Oh yes, sadly lots of programs needs to be "adjusted" due to incorrect timing loops. And I'm sure, allthough it looks simple, it takes a huge amount of silicon to achieve this.

Hmm, this is something I don't understand. Perhaps you can explain this dramatic speedup. But I assume adding 9 accumulators instaed of only one wouldn't yield +900% ??

Again I require additional explaination - you mean accessing $80 will use the internal "register", and accessing $0080 will use external RAM? So they could have different contents? If so, that means you are using zeropage addressing as a flag to distinguish between external and internal memory. OK, then LDA ($80),Y will fetch two bytes (opcode and zpAddr) but then use reg80,reg81 add Y and finally fetch the data. Ideally this would take only 3 cycles instead of 5. In- or decrementing these "registers" would then again require 2 byte program data and ideally 2 cycles (more likely 3 cycles, since you have to fetch, change, and restore the register) saving 3 or 2 cycles.
Hee hee - if register <> memory you could fill a program into $0080++ and run it, using regs$80++ having a different contents. Nicely odd
Yes, nice.

Well, IMHO that's beyond the scope of 65xx.

The advantage of having lots of "pointers" placed in zeropage is only that you can/should avoid saving and restoring them - that is exactly what you need to do when dealing with a Z80. There you easily ran out of registers especially as they are not freely interchangeable.
6 mode bits! Meaning 2^6 = 64 possible situations regarding register lengths. Do you played in your mind with situations like context switches or simply interrupts? I just playing with the 816 and realize that I have to save A and X and a second time P (flags) and perhaps DPR. Then I could switch the register size to what I need within the IRQ service. There I have to take care of DPR or using long addressing. Finally I have do undo everything => PLD, PLP, PLX, PLA, RTI

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

Thanks for the mention, Garth.

Prefix bytes are a potent solution because each consumes just a single place in the opcode table but it makes possible 256 new encodings. Unfortunately, the prefix occupies an extra byte of memory. Also, fetching that byte entails a certain delay.

So, there's a tradeoff. A single-byte opcode is fastest, but a prefix-plus-opcode combination is more versatile because more encodings are possible.

KK implements both. The prefix method is the most flexible way to specify a "Far" data access — that is, one whose data has a bank address that's independent of the bank where the currently-executing code resides (per K0). The desired prefix (either K1 prefix, K2 prefix or K3 prefix) is followed by and acts upon any typical 65C02 data-access instruction such as BIT Abs, INC Abs, CMP (Ind) and so on. During that following instruction the 'C02 creates a 16-bit address in more or less the usual fashion, and KK makes the alternative bank active only during the instruction's data access — ie, typically for one cycle only (three cycles for Read-Modify-Write).

The other method involves only LDA and STA. These are used more frequently than other data-access instructions, and to improve performance KK sometimes allows them to omit the prefix. In order to conserve encodings this capability is limited to a few carefully selected cases.

• opcodes $D3, $F3 and $E3 apply K2 to LDA Abs, LDA (Ind,X) and LDA (Ind),Y respectively
• opcodes $93, $B3 and $A3 apply K1 to STA Abs, STA (Ind,X) and STA (Ind),Y respectively

In other words $D3 (for example) acts as "2 in1"— ie, both the prefix and the opcode itself. The mnemonic is LDA_K2. Altogether (including the two operand bytes for Abs mode) the instruction occupies 3 bytes, and it executes in four cycles, with register K2 supplying the bank address only for the last cycle.

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