6502.org

100% agree on a WDC65CE02
it is like the last of the 8-bit, with a lot of the best improvements, while the 65816 is a 16-bit chip, the first of its generation of chips (in 65xx). I agree, cost was probably the factor that "made" the 6502. Any and all features would be hard pressed to unseat that commodity. totally! yeah it is certainly the end of the era, it is however really cool to see what is basically the final incarnation of the chip with its feature set turned up to 11, having many of the features I have been advocating for.
I am looking at the virtual cores built on this for future work and potential WDC developments, though unlikely, they do release new chips and revisions every few years. the support just shown here in this thread is a strong indication of marketability. If I enter the arena (aspirations!) I would be looking at a 65CE02 as a baseline, including for the 65-RISC-V project. I saw your thread on that. I am working in 6502, hardware and systems design atm, some low level electronics, in a few months, next year maybe I was going to look at the custom cpu design, verilog, CPLD/PLA/PAL/GAL, FPGA etc. There is also a github repository of 6502 cores : https://github.com/kdyke/65xx. totally agree that there should be a modern WDC 65CE02, things change, if there is demand I think supply will follow here. WDC releases updates and revisions from time to time. neat. I really think cost was such an influence, it was such a factor, it would preclude some of the most minimal of additional features.
I would at this point cast my vote for an on die cache, probably the stack, built into the chip itself, or at least some form of on chip RAM to facilitate stand-alone operation. I think if this could be achieved, to walk in and say "you can use our (~$30) chip. by itself, and it will work, and the 6800 is $250, plus that RAM, we will not only beat them at cost, we can completely eliminate the need for additional hardware with a performance boost." This is assuming you could fit 256 bytes of RAM onto the die for only a 50% price increase, $30 instead of the $20 price hawked at the time. Given that much later, many of the features I want ended up getting made, once it was affordable, I would now advocate for that on-chip Stack RAM (or cache) and the Stand-Alone-Operation it offers as something that might justify a price increase.

If MOS had had people as completely awful as you at marketing, the 6502 might well have failed, and this site might well be called "forum.6800.org."

Fortunately they didn't, and you can look back at what they did say to learn something about how marketing works. Their line was not, "lack of BRA is a feature"; their line was: "You can get a CPU with BRA for $175, or a faster one without BRA for $25. Which sounds better to you?"
Well, note that a "cache" would be rather useless; the design of the original chip is such that it will get no speed advantage at all from on-board memory.

For stand-alone operation, it's not really going to be useful without ROM and at least a bit of I/O as well, at which point you're either building a much more expensive microcontroller, à la the Motorola 6801, or you're putting ROM and I/O on a separate chip, in which case why not put the RAM there, too? Which is in fact exactly what they did: they created the MOS 6530 RRIOT (and a ROM-less version, the 6532 RIOT, for systems where the ROM needed to be external for development or other reasons).

I don't know if all these opcodes can fit in 256, nor would I have any idea of what price the 6502 would have cost if they implemented all these features but:

-Everything the 65c02 already added.
-ADD and SUB without carry
-Using X and Y registers themselves as an addressing mode
-ADX/ADY/SBX/SBY instructions
-being able to perform ASL/ROL/LSR/ROR on index registers
-register/register and register/memory swapping instructions
-memory to memory instructions

If they can't fit within 256 instructions, you can cut (dp,x), dp,x and dp,y addressing modes.

It was you who said it was a feature. Read your own post.

That said, I am awful at marketing. Not going to disagree with that.

Well, to be more precise, if you restore the second half of the sentence you deleted when you quoted me, I said, "...to keep the implementation as cheap as possible they determined that there would be only eight relative branch instructions, and BRA and BSR [are] ones that they chose to drop."

Which you seemed to understand and agree with anyway in the second and third paragraphs of your previous response.

Then you went on to say that your manipulation of what I said, leaving out half my sentence and essential context, was "what a marketeer would say." This is all a bad communications problem you've made up out of whole cloth.

cjs: Everything you said is correct. I yield.

Of course I am well aware of the extreme budget constraints the original designers were under, but that doesn't mean the shortcomings do not exist, nor that they were not addressed in subsequent improved designs.

Also, on a point of terminology and semantics, no, the lack of BRA is not a "feature". I don't think its possible for the lack of a desirable function to be considered a "feature". The "feature" is that the chip was cheap. The lack of BRA was, at best, a "trade-off" to achieve cheapness and, at worst, a "flaw" in the design (depending on your point of view).

The Commodore 64’s BASIC interpreter has the self-modifying CHRGET function on zero page. CHRGET reads BASIC program text a byte at a time and determines whether what was read is a BASIC token, PETSCII, or something else. Each time CHRGET is called, it first increments the text pointer, which is actually part of the code.


The Commodore 128’s BASIC 7.0 doesn’t have this form of CHRGET, instead using a zero-page pointer and (<zp>),Y addressing to read program text. Predictably, slower execution resulted.

Be that as it may, as far as I am concerned the 65816 is not the same beast. I've nothing against the 65816 of itself, but it just doesn't feel the same to work with when you're making use of the new stuff (and if you're not, what's the point?). The 6502 is just so beautifully straightforward in its ISA design, in a way that I don't see in the 65816; the latter feels kludgy. Conversely, the 65CE02, in my opinion, fills in the missing gaps from the 6502 without fundamentally changing that simplicity.

I also agree with wayfarer in that I view the 65816 as a 16-bit chip. Is the x86-64 architecture any less of a valid 64-bit chip for also supporting 32, 16 and 8-bit data? Of course not! Thus the same applies to the 65816 - it's largest native data size is 16-bit, therefore it is a 16-bit architecture. The fact it can also work on 8-bit data is besides the point.

It really is a nice feature set and culmination of features. any custom designs I build will use this as its core, sans ultralight types closer to the 6507 https://en.wikipedia.org/wiki/MOS_Technology_6507 or standard 6502 layout. 65CE02 is the way to go for future designs and iterations, as it is a drop in replacement that then has additional functions, nothing is lost by going to 65CE02? no existing design fails? So here I want to say Im not sure Id move Zero Page itself and as stated, a chip variant does exist with some one chip RAM and ROM...
however, I would still advocate for the Stack (and maybe a "scratchpad" of a few bytes of RAM) that is internal to the 6502 IC.
I would think of this Stack RAM as separate from the normal ram addressing, and accessed internally via the Stack register. because it is only 8 bit addressing, when using the stack, it can be accessed, and externally, it would need a few extra operations to interact with.
Internally, it is "negative 256 bytes" "below $0000". really it is in "Stack:0x00", and the high address byte can be used to specify the location in the stack for direct access to a given byte.
Externally, you could use the Set Overflow bit/pin to PUSH or PULL to or from the stack since its not used much; along with the relevant internal commands and addressing.
However you might expose the stack (if at all), internally it is not in the standard MMIO range, it is S:00-S:FF and if you did have any internal RAM, Id say even splitting the stack to 128 and 128 scratchpad registers (dumb ram) or even, 64 or 16 and 192 or 240 on the stack. I think you get the idea, just a very small internal area split between the Stack and a few simple local storage 'cache' ram, or scratchpad registers, would go a long way towards speed and overall simplicity.
So, even if its just 256 bytes (or less) internal RAM, split between the Stack and 'Scratchpad' or cache RAM.

I think if done right, a relevant address mode or use of SO pin would work for any external access you may need. though if this was for the original design, it would follow our designs now would use this. either way, I think the inclusion of this extra onboard RAM would justify a few bucks more and still beat out the competition

https://jcmit.net/memoryprice.htm

here we can see that 256 Byte Altair board in 1974 was ~$100 so it would put our chip at half the cost of the 6800 and have a significant advantage. at this price point, it is much easier to justify a quarter per byte on a $25 chip, to have say, 64 bytes of scratch-RAM used for stack/etc/user registers, and only cost $8-10 more.

somewhere in there are pseudo-instructions and addressing that uses some extra opcodes and makes things very fast...
further, just a few years later, RAM density and cost gets much, much cheaper, allowing for more and more internal scratchRAM, deeper stacks, more user GP-registers, etc. and the architecture is there to support it as it grows already.
I think this would have been a strong selling point, inexpensive and a significant advantage over competitors whose chips 'sat fallow in their sockets' without any extra RAM, board space and complexity being added to get them to do more than sit there.

Id realy look at even 16 bytes stack, 16 bytes scratch. for hex-addressing simplicity and cost.
so in demos, you have the 6800, that costs several hundred dollars in a socket, it 'does nothing but use electricity' while the 6502 'with scratchRAM' is $40 and is doing things all the while.

I was sent a couple of 65CE02 samples.  I put one in my workbench computer's 65c02 socket, and it did not work.  I did not try to troubleshoot why.  However, I do have a 65802 in there which works just fine.  The '802 is a 65816 made to drop into an '02 socket.  As such, it is confined to a single 64K bank operation, and doesn't have the VPA & VDA pins, but otherwise gives a ton of benefits over the '02.  Unfortunately the '802 was not made for very long either; but Daryl (forum name 8BIT) has a design for a hybrid using a 65816 and other ICs to plug into a 6502 socket like WDC's no-longer-available 65802.  The forum topic that goes with it is here.  Also, there's A2Heaven's 65816-to-6502 converter module, which seems to be the same thing as Daryl's 65802 module.

I think I'd agree that, in terms of programming model, the 65816 is more of a 16-bit chip than an 8-bit one. In particular, you couldn't really mix 8- and 16-bit work smoothly because you had to explicitly switch between 8- and 16-bit modes using another instruction. In some ways, supporting mixed 8- and 16-bit operations is even worse than a full 16-bit processor such as the 68000. For example, it's not possible (though correct me if I'm wrong here) to add (with correctly calculated carry) an 8-bit value to a full register width (16-bit on 65816) value; you have to convert the 8-bit value to a 16-bit value first. (The 68000 explicitly specifies byte, word or long addends and even has special short encodings for adding small constants in a single 16-bit instruction with no operand.)

But when I hear "the last of the 8-bit" I hear the potential for an implied "and best" there, too, and for me that would be the 6809. While the 6502 did improve over the 6800 in certain ways, the improvements were extremely limited due to the focus on lowering cost. The 6809, on the other hand, walks all over both in terms of programming model, compactness of code and (arguably) speed.

This came at the cost of (binary) incompatibility, of course, but that's just the nature of things. And that at this point rather leaves the 65xx line stuck; the reason people like it and use it now is because it's 6502, not because they're looking for a faster CPU, or an improved architecture or instruction set, all of which are available more cheaply now if you're willing to abandon the 6502 model.
It was a pretty common idea. Motorola also had the MC6846 (2K ROM, 8-bit PIA, timer). It didn't have RAM, but it didn't need it: it was released (in March 1977) along with the 6802, which had 128 bytes of on-board RAM.
The only thing that's going to give you is an extra 256 bytes of memory, and the cost would be enormous: incompatibility with a significant amount of 6502 software. Remember, accessing the stack via instructions other than PSH and PUL is not done only by programs that want to use a calling convention with arguments on the stack, but also for things like determining one's location in memory (JMP to a known RTS and read the return address from just below the stack pointer), saving and loading registers for various reasons, exception-handling type flow control, and so on.
No, it's going to put you at a disadvantage because you're now forcing all your CPU buyers to buy 256 bytes of expensive static RAM, even if their design already had, say, 2 KB of far less expensive DRAM. (Remember, DRAM quickly got to one transistor per bit, whereas static RAM to this day is, IIRC, 6 transistors per bit in small quantities, approaching 4 as you get to large quantities.)
The "who can do more with fewer chips?" battle is not one you want to get into with Motorola, because they will win.

Keep in mind, less than a year and a half after the introduction of the 6502, Motorola introduced the 6802, which had 128 bytes of onboard RAM. (It's also what's actually in several late-70s-onward "6800" microcomputers, too, because it had an on-board clock generator.) So that just stuffed your demo above. (Not to mention your pricing is wrong; the 6800/6802 rapidly dropped in price after the 6502 came out and by mid-1977 you could buy one from the back of Byte for $35. (The August 1977 Byte didn't have anybody even offering 6502 CPUs. Not sure what was up with that; availability issues?)

Second, unless you had external ROM, both CPUs were sitting there doing nothing. Sure, you could pull out a RRIOT, but Motorola had the MC6846, and with the RRIOT the internal RAM you've added to the 6502 isn't needed.

But then, Motorola's going to haul out a 6801 MCU (which was actually in use with GM well before it was released to the public in 1978), with ROM, RAM, PIO, a serial port and, hey why not, even a multiply instruction) and show you a complete working system in one chip, and what are you going to respond with?

Remember, the MC6801 and similar chips from Motorola far outsold the 650x processors. (And to this day we're still using 68HC11 MCUs.) MOS may have won in the microcomputer market, but Motorola had automobiles, and there were a lot more cars than microcomputers back then.

I have no experience with the 6809; but according to this post and this one, the 6809 had really no execution speed advantage over the 6502—and that's at a given clock rate; but the '02 went to much, much faster clock rates.
I had mentioned stack-relative addressing earlier, for stack frames, but this is also a good point which I was forgetting, regarding finding inlined data as well, and adjusting the return address to skip over the data, as in the macro line,

which assembles,

as chapter 7 of the 6502 stacks treatise goes into, at http://wilsonminesco.com/stacks/inlinedData.html .
The only single-chip 65xx solutions you'll find today are in ASICs, in automotive, industrial, toy, appliance, and even life-support equipment, and since they're custom ICs with everything onboard and the processor at their heart being licensed by WDC, they won't be marked with anything you'd recognize, like having any "65" in the name.  However, Mike Naberezny de-capped the controller IC in the control panel of his VW Jetta, in his project to make kind of an information center, and found that the processor in it was a 65c02.  https://wdc65xx.com/about-WDC/ says: "WDC and its licensees have shipped over eight billion CMOS processors; more than 1 per person on planet earth!  This number is growing by hundreds of millions of units each year."

The Mitsubishi 740 series chips support the original NMOS 6502 instruction set. They don't support the extensions of the CMOS 6502 variants but Mitsubishi added their own extensions with useful instructions.

I found a chip from this series, an M38869FFAHP, in a car radio. It's a single chip in 80-pin TQFP package with 60K flash, 2K RAM, and a lot of peripherals like timers, UART, I2C, and SPI. It's no longer in production but I bought a few of them from utsource.net and they worked.

Alan Baldwin's ASxxxx can be used for development. It can assemble both regular 6502 code and the 740 extensions. It works well. I disassembled the firmware of the car radio (about 56K) and ASxxxx reassembled it to an identical binary without any issues.