Hi everyone,
If you were part of the 6502 design team, what would you have pushed for? Given the die was initially too large, any changes need to be part of a tradeoff.

Here is a suggestion to get the ball rolling:
1 bit Input/output ports like Signetics 2650, COSMAC 1802, INS8060, i8085

• Remove decimal mode to free up some space
• Change SO pin to an output FLAG pin and connect to bit 3 of Status Reg, previously Decimal Mode
• Rename the CLD/SED Clear/Set decimal flag instructions to Set/ClearFlagPin
• Connect IRQ pin to bit 5 of Status Reg - Replaces functionality of SO pin for 1 bit input
• However, Needs an instruction to either test (and set another SR bit) or branch

There is a related thread on what could we get rid of, but this thread is what would you change based on tradeoff.

Interesting list. I wonder about the feasibility of dropping BCD support, but I'm not very familiar with the mid-70's embedded market they were primarily targeting, so not sure if it would be deal breaker.

If I knew then what we know now about dropping memory prices, I'd use some of the NC pins as an indicator of type of memory access being performed, similar to VPA/VPD on the '816, in order to allow for potential separate address spaces. Maybe a vector pull pin?

Similarly, if I knew that compiled languages were the wave of the future, I'd try to find a way to squeeze in a larger stack pointer and stack relative addressing modes, if at all possible.

Who knows what the future would bring in 1975, but a cheap microprocessor that could handle decimal mode arithmetic? The business world would kill for that...

Or that was the thought... Did anyone actually use it?

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I don't know about business applications (though a spreadsheet might benefit from fewer round-off errors), but Atari BASIC used a six-byte BCD format for floating point operations

https://www.atarimax.com/freenet/freenet_material/5.8-BitComputersSupportArea/7.TechnicalResourceCenter/showarticle.php?14

I found this article about VisiCalc (c1979) where it says they use Decimal Numbers, which I understand to be Decimal floating point - did they use BCD mode internally? Don't know...

https://www.landley.net/history/mirror/ ... icalc.html

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Looks fairly likely that Visicalc used base-100 arithmetic, and didn't use BCD mode.
"VisiCalc used a variation of decimal arithmetic" (source)
and see this disassembly, with a few CLD, no SED, and a smattering of CMP #$64.

See also some related ideas but nothing definitive about VisiCalc in this Q&A:

• Did any micros use the 6502 BCD mode in their OS?.

I'm not sure it would have been wise to swap out BCD anyway: point of sale, trip computers, vending machines all like to show numbers to humans. It's something other micros had. And probably they expected their patent to help them too: no BCD, no patent.

Well, IMHO I would argue that bcd is a leftover from the IBM decimal mainframe from the 1960s, and that bcd is only useful in floating point, which I don’t expect the 6502 to be doing a lot of.

Once you have binary to decimal display conversion subroutines, special instructions are unnecessary.

If I recall early ARM does not provide BCD support, which shows RISC based philosophy felt the same way. I also dimly remember Motorola cold fire also dropped bcd support from the legacy 68k instruction set.

Add a stack for data. Make both the address stack and data stack relocatable (to page boundaries).

Does anybody know how relatively expensive different changes would have been? Looking at the 6502 as a reduction from the 6800, it seems that removing the B register and making the stack pointer only 8 bits wide were very deliberate decisions, so I presume register bits were very expensive.

Perhaps it would be more practical to enable more flexible use of the existing registers. In that sense, the CMOS updates add a lot of useful instructions that would have been good to add to the original launch - things like PHX for example.

In terms of new instructions, RSB would be nice, though it's mostly easy to work around. ADX, ADY, SBX, SBY also, i.e. adding or subtracting index registers to the accumulator. Indexed jumps and JSRs would be useful too. Hopefully most of these would be possible using pathways that already exist in the architecture, maybe just requiring changes to the instruction decoding.

I've often wondered it the (pre-indexed indirect, X) address mode would have been more useful, or at least more commonly used, if it was page one based instead of page zero. That would make it easier to use the hardware stack for passing addresses as function parameters. No need to move them page zero first to be used.

Or make the base page switchable between one and zero with a flag bit in the status register. Speaking of which, adding a break vector along with reset, NMI and IRQ would eliminate the need to check (or have at all) the break flag in the status register, which would have surely sped up anything that relies heavily on IRQs.

It certainly would - but note that the flag itself doesn't really exist in the silicon so unfortunately it wouldn't free up resources there.

I wonder about NMI, now that you mention it - the BBC Micro took advantage of it, but mostly as a workaround for not bothering with proper DMA. It was only used in conjunction with add-ons that were themselves rather expensive, and I feel that if it didn't exist they'd still have found another way to do what they needed to do. So it doesn't feel to me like a critical feature, and is one that I suspect many designs could happily do without. Maybe that would free up the resources needed to then have a dedicated BRK vector.

Yes, I'd have (S,n) instead of (X,n) addressing mode. In 40+ years I think I've only ever used (X,n) once, and that was in some extreme optimisation:
LDX #8 ; bit counter
LDA (zp-8,X) ; get byte

I'd also ensure JSR pushed the proper return address, not address-1. Always annoying having to code around that. I end up doing PHP:RTI instead.

_________________
--
JGH - http://mdfs.net

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