This is slightly OT, as it's not my own idea. But in the realm of enhancements which *did* get implemented, I think the T Flag (a new bit in the Processor status register, included in the Hudson Soft HuC6280 and certain other CPU's) is worth remarking. From this post in the thread 65x02 variants:

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

I thought the 65CE02 completed the opcode set in a very elegant way, by adding a Z index register, a movable base page, a 16-bit wide SP, and other niceties such as relative and indirect JSR, an ASR operation and the new stack addressing mode. Not sure if it was maybe a little complex to have been possible in the early 80s though. It's certainly a shame it never took off.

As for how I wouldn't extend it, it eludes me to this day why TSB and TRB were considered worth adding. I assume the designers had some very specific use-case in mind, but I've only ever found use for TSB (as a marginally quicker way of doing LDA/ORA/STA) and even then its lack of addressing modes make it relatively useless.

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

Oh yeah, the 'ce02 was very cool IMO! I'm disappointed that I forgot about it. When I think of TSB and TRB, I automatically think of semaphores.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I do like the 10-bit or 12-bit word suggestion. It would have been a bold departure from the norm and would have raised some eyebrows for sure. 10 bits with a 20-bit address bus would have required 6 more pins - blowing out of the 40-pin package. I wonder if it would have been possible, at the time, to have a 10-bit +RAS+CAS bus instead... I guess that's only good for DRAMs and not for I/O devices... But maybe some games would have been possible there.

A nice bit of out-of-box (byte?) thinking!

In addition to thread- and/or interrupt-safe semaphores, you could also use TSB/TRB to check interrupt (and similar) flags in an I/O register at the same time as clearing them.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

As Garth already posted this sort of question and the following "discussion" had happened frequently - everytime with much emotion as we're all in love with this little beast and its limitations and we all dream of Sweet16 or more

Acting a little bit as an Advocatus Diaboli I take your introduction a bit more literally:
Well I could remember that time but I took a look into some old Byte magazines to recall the RAM situation and the prices of the CPU and I/O circuitry. In 1980 a 6502 costs about 6..10$, a 6502A twice as much, Z80A in between, MC6809 <40$. Static RAM was 1Kx4 (5$) and 16Kx1 dynamic RAMs becomes payable (8 pcs. 50$). Beside the MC6809 the MC68000, the Z8000, and the i8086/88 appears in the advertising (seldom as chips, usually on cards or as a system) - any of them really expensive.

Now, if you emphase the backwards-compatibility then this could only mean the upgrade requires to be transparent under all circumstances - even for the usage of unimplemented opcodes. Then things becomes very difficult, as any improvement within the CPU architecture could change the behaviour of these "illegal" opcodes. Is it acceptable to repair the JMP [indirect] bug? That repair could cause incompatibilities!

Staying compatible means leaving all bugs untouched. Then only the twelve so-called "KIL" instructions are free as they most likely never used intentionally. Further there are a few more NOPs ($1A, $3A, $5A, $7A, $DA, $FA) that may be usable as well. This would allow to implement 18 new opcodes. Some welcomed extensions like PHX, PLX, PHY, PLY, SWP (nibble swap), INC A, and DEC A were possible. A further addressing mode like (ZP) without index would eat up 8 opcodes (ADC/AND/CMP/EOR/LDA/ORA/SBC/STA) leaving no room for goodies like BRA/LBRA, BSR/LBSR Kicking SWP (sorry, Daryl) would allow the latter four but nothing else.

Of course, dropping INC/DEC A would allow to implement two different prebytes to extend the opcode map ad infinitum

But implementing these additions without affecting the original behaviour appears to me as a very costly adventure. It would probably require much more silicon to implement that around (outside) the core than to enhance the core with the risk of altering the behaviour of some "illegal" opcodes. Beside the NRE costs - assuming it would increase the chip size somewhere between 50..100% this would double the market price - for gaining what benfit in terms of speed?

A different approach could be just to use one "KIL" opc to implement a "BOOST" function: turning on the 65org16. Then 8 bits becomes 16 bits everywhere. (=> a "page" is then 65K x 16bit, an absolute address covers 2^32 16bit "bytes", ...). Perhaps it would be possible to rearrange the core in a way that all these upper 8 bits are ignored/untouched unless boosted, this may roughly double the required transistors. Again the chip could perhaps require not more than twice the area.

The 16 additional address lines plus 8 additional data lines would just fit into a 64 pin package -
or you may use 1 of the 3 "NC" pins to multiplex the address bus and another "NC" pin to select high or low byte access as a secondary multiplexing for the data. (This would cost an additional cycle - ).

Would anyone in 1980 buy such a CPU paying twice or more money for just staying compatible and then having to double all RAM/ROM (and perhaps I/O) to use the booster - meaning new hardware, not something to plug in? In the dawn of the new 16bit CPUs mentioned above I have my doubts.


my 2 cents

I'd have to take a different line on the opcodes - the point of a spec is to say what happens. Things outside the spec are not normally part of a backward compatibility claim. So, all those unspecified opcodes are certainly up for grabs. This is why no-one who used them should have any expectation of portability or future support.

The only good reason to soften this line is when some economically important use is made of undocumented behaviour - it may be time to make it part of the spec. Suppose for example VisiCalc used one or two of the undocumented opcodes - that would be important.

It's worth noting though that there are different levels of claim for backward compatibility. There's pin-compatible, binary-compatible, and source-code compatible, at least. And even with pin-compatible, it could be totally compatible or mostly compatible.

So we do have some wiggle room.

Whilst I totally see your point GaBuZoMeu, and it is an interesting discussion, I have to agree with BigEd that behaviour outside of the official specification, or unintentional bugs that cause deviation from that specification, are outside what I would call necessary for "backward-compatibility". Yes, sometimes a widely used but officially undefined behaviour is backported into a specification (I'm looking at you, C/C++) but I consider that an exception rather than the norm.

---

There's certainly been many interesting suggestions in this thread. I like the 10-bit bytes idea, though I'm not sure that it would have been practical in terms of memory ICs, even in 1980. I do like some features of both the 65CE02 and the 6809, but I also dislike each of them for one reason or another.

---

I was thinking about this myself a few months ago (april) and this is what I came up with:


Green is all the original 6502 instructions (the backwards compatibility part), Yellow are 65C02, blue 65C816 and Orange are instructions of my own design.

There are two new registers: B, a secondary accumulator, and W, the Working Page pointer (equivalent to the Direct Page register in 65816). All zero-page instructions are replaced with equivalent instructions indexed by W. Instructions for B are added, including XBA, all the RMW instructions and some LD/ST instructions. No, B is not as flexible as A, but its not really meant to be - it is secondary afterall. JMP and JSR using (#, S) address mode added to support passing function pointers on the stack.
The P register has two new flags at bits 4 and 5: U and E respectively. If bit E is clear (which is the default on reset) then incompatible extensions are switched off - BRK shares its vector with IRQ, and the U bit behaves as the B bit does in 6502, and the SO pin messes with V. If bit E is set then BRK has its own vector, and the U flag mirrors value input on the SO pin. There are two new branch instructions, BUC and BUS, for the U flag.
Unfortunately I cannot remember what PLG, PHG and PEC where supposed to do.
The chip would be pin-compatible with the 65C02.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

There's a challenge then!

I would guess that PLG and PHG need to push and pull some state: how about General state: they could push and pull A, B, X, Y, W, maybe P. For some kind of task switch, perhaps.

Whereas PEC looks like it should be a bit like PEA, PEI, PER which Bruce describes thus:


So, PEC needs to push something 16-bit flavoured. How about the concatenation of A and B?

I'm sure other guesses can be made, and I'd be interested to see them...

6 more pins is perfectly doable, the 6510 added a 6 pin port to the 6502 and still shipped in a 40 pin package, just depends on what you can live without.

30 pins for address and data, plus PWR, GRD, Clk still leaves 7 pins for RDY, NMI, etc.

WDC's W65C02S

• still leaves pins 35 as "NC" (is it used for testing?)
• still has SO\ which nobody but Dr Jefyll is using (but he uses it very effectively!)
• Φ1 and Φ2 out, which WDC no longer tests or recommends using
• takes away the pin-1 ground for a VP\ (vector-pull not) output
• uses pin 36 for a BE (bus-enable) input
• uses pin 5 for a ML\ (memory-lock not) output

It would be nice to have the 816's VDA and VPA in place of the 6502's SYNC output which is on pin 7. This add another pin (VDA & VPA, as opposed to only SYNC).

If we make these adjustments, we have:

• Φ2 in
• R/W
• VDA
• VPA
• IRQ\
• NMI\
• RST\
• ML\
• BE
• VP\
• SO\ (??)
• GND (There ought to be two of these, one in the middle of each row of pins.)
• VDD (There ought to be two of these, one next to each ground pin above.)

If there are 30 address and data lines, the above makes for 45 pins. We could forgo one of the VDD's and fit it all in a 44-pin DIP.

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

As good a guess as any, but I honestly have no idea! Certainly a useful instruction to decrease interrupt latency even further.


I think it might have been an 8-bit version of PEA, a Push Constant if you will.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I'd be tempted not to have all of VPA, VDA, VP. I might for example have a SYNC pin which outputs two bits of state, one in each phase. That might allow for signalling vector pull, fetch, normal access, dummy access, for example.

You could appropriate the following 6 pins from the original 6502 for D8-D9/A16-A19:

• 3 no-connects
• PHI1_OUT and PHI2_OUT
• The 2nd VSS

You lose the 65C02 pins: VBP (previously VSS), /ML (previously PHI1_OUT), and BE (previously N.C), but these didn't exist in 1980, so they would not have been missed.