What would you change in 1974 with Mensch & Peddle

[wayfarer]

Alarm Siren wrote:

wayfarer wrote:

I actually found a chip that ...
the 65CE02, from CSG, located here on the archives. http://www.6502.org/documents/datasheet ... 02_mpu.pdf
it had a Z register and a relocatable stack. ... in an 8-bit package. Super cool. A couple of people have or are working on 'cores' for the 65CE02, I will be studying them for any custom chip/core developments!!

Indeed, I have a great fondness for the 65CE02. I think it addresses a lot of the 6502 and 65C02's shortcomings whilst fundamentally remaining true to the original, unlike the more drastic measures of the 65816 (which are mainly in service of the larger address space). And before Garth and BDD jump on me, yes I am fully aware you don't have to use the 65816's additional features if you don't want to: The point is I view the 65CE02 as being fundamentally a 6502 with the flaws fixed, whereas the 65816 is a different beast altogether. I do think its a pity that the 65CE02 saw so little real-world usage, and that the chips are no longer available. a WDC version of the 65CE02 would be great.

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).

cjs wrote:

Alarm Siren wrote:

Indeed, I have a great fondness ....

I'm not so sure. Consider, for example, the lack of a BRA instruction in the original 6502. That wasn't a flaw, that was a feature: to keep the implementation as cheap as possible they determined that there would be only eight relative branch instructions, and BRA and BSR one ones that they chose to drop.

I agree, cost was probably the factor that "made" the 6502. Any and all features would be hard pressed to unseat that commodity.

Quote:

I see the MOS 6500 series CPUs as a design intended to be somewhat compatible with the 6800 series as a secondary objective ... But if the original 6502 designers had had the transistor and space budget that the 65C02 designers had, would they have designed the same CPU? I think probably not.

totally!

sark02 wrote:

wayfarer wrote:

I actually found a chip ....

Oh that's a really nice find. The Z register hits exactly what I was looking for with my (terrible) (ZP),X idea, and BRA. And it has some really nice features that wayfarer mentions.

Coming in 1988, 13 years after the 6502, and in the era of the 68000-based machines, it doesn't look like it had much of a life.
From Wikipedia: The 65CE02 was used in the Commodore A2232 serial port card for the Amiga computer. That was it? What a waste.

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.

Proxy wrote:

wayfarer wrote:

A couple of people have or are working on 'cores' for the 65CE02, I will be studying them for any custom chip/core developments!!

nice find! i made one of those 65CE02/816 hybrid cores. though i haven't worked on it for a while.

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.

Quote:

Alarm Siren wrote:

Indeed, I have a great fondness for the 65CE02. ... a WDC version of the 65CE02 would be great.

yeah, sometimes i feel like the modern day WDC65C02S should've been the WDC65CE02S instead. BSR/BRL, relocatable stack and zeropage, stack indirect addressing modes, and other useful features... it would've been amazing!
especially for Operating Systems like FUZIX or GeckOS where fully relocatable code and data structures are pretty useful.
but sadly that is not the timeline we live in...

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.

Quote:

though there are a few things i would change about the 65CE02:
for example i would remove INW, DEW, ASW, and ROW (Word Increment/Decrement/Shift Left/Rotate Left) and replace them with ICC and DCC (Increment/Decrement with Carry) with both Basepage and Absolute addressing modes. ICC and DCC are functionally identical to "LDA ADC #0 STA" and "LDA SBC #0 STA" but don't modify the accumulator. so you can chain them to increment/decrement multi-byte words in memory (also works with BCD).

neat.

Quote:

...

cjs wrote:

to keep the implementation as cheap as possible they determined that there would be only eight relative branch instructions, and BRA and BSR one ones that they chose to drop.

...
but of course i know that with the goal of staying as low cost as possible, having JMPs and JSRs always do a 16-bit addition with the relative offset and the PC would add quite a bit of complexity and cost. but a man can dream

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.

[cjs]

sark02 wrote:

cjs wrote:

Consider, for example, the lack of a BRA instruction in the original 6502. That wasn't a flaw, that was a feature

I LOLd. No, just no. That's what a marketeer would say.

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

wayfarer wrote:

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.

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).

[Aaendi]

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.

[sark02]

cjs wrote:

sark02 wrote:

cjs wrote:

Consider, for example, the lack of a BRA instruction in the original 6502. That wasn't a flaw, that was a feature

I LOLd. No, just no. That's what a marketeer would say.

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."

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.

[cjs]

sark02 wrote:

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

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.

[sark02]

cjs: Everything you said is correct. I yield.

[Alarm Siren]

cjs wrote:

Alarm Siren wrote:

Indeed, I have a great fondness for the 65CE02. I think it addresses a lot of the 6502 and 65C02's shortcomings whilst fundamentally remaining true to the original, unlike the more drastic measures of the 65816 (which are mainly in service of the larger address space).

I'm not so sure. Consider, for example, the lack of a BRA instruction in the original 6502. That wasn't a flaw, that was a feature: to keep the implementation as cheap as possible they determined that there would be only eight relative branch instructions, and BRA and BSR one ones that they chose to drop.

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).

[GARTHWILSON]

I lament, with so many other enthusiasts, that so few 65CE02's were made and that it was discontinued so quickly.  I remember well the excitement when it came out.

wayfarer wrote:

Alarm Siren wrote:

wayfarer wrote:

I actually found a chip that ...
the 65CE02, from CSG, located here on the archives. http://www.6502.org/documents/datasheet ... 02_mpu.pdf
it had a Z register and a relocatable stack. ... in an 8-bit package. Super cool. A couple of people have or are working on 'cores' for the 65CE02, I will be studying them for any custom chip/core developments!!

Indeed, I have a great fondness for the 65CE02. I think it addresses a lot of the 6502 and 65C02's shortcomings whilst fundamentally remaining true to the original, unlike the more drastic measures of the 65816 (which are mainly in service of the larger address space). And before Garth and BDD jump on me, yes I am fully aware you don't have to use the 65816's additional features if you don't want to: The point is I view the 65CE02 as being fundamentally a 6502 with the flaws fixed, whereas the 65816 is a different beast altogether. I do think its a pity that the 65CE02 saw so little real-world usage, and that the chips are no longer available. a WDC version of the 65CE02 would be great.

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).

A couple of notes:

• The '816 offers a lot of software benefits even in '02-emulation mode.  There is so much there that's not particularly related to the larger address space or wider registers.
• When you put the '816 in native mode, the registers are still 8-bit until you change them to 16-bit.

cjs wrote:

wayfarer wrote:

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.

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.

A few things like stack pushes and pulls could be sped up if this internal memory were on a separate internal bus; but this page-0 and page-1 on-chip memory would then need to be dual-ported, accessible on the normal bus as well, to avoid losing a lot of capability.  Two examples that come to mind are:

• I've put actual executable code in ZP in order to do some self-modifying code that takes advantage of ZP addressing modes, to reduce the number of clock cycles taken.
• Stack-relative addressing requires being able to use standard instructions in the stack area, not just the PH_ and PL_ instructions.

Quote:

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).

That 6530 IC was really nice at the time.  There was another company later that did that kind of thing, more powerful, and not 65xx-specific.  I think it was called "Crystal," although I don't know if that's the entire company name.  I threw out my data book not too long ago.

Aaendi, some of what you're suggesting, plus a lot more, can be done on the existing '02 with self-modifying code.

[BigDumbDinosaur]

GARTHWILSON wrote:

I've put actual executable code in ZP in order to do some self-modifying code that takes advantage of ZP addressing modes, to reduce the number of clock cycles taken.

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.

Code: Select all

115 $73   CHRGET  INC TXTPTR   ; increment low byte of TXTPTR
117 $75           BNE CHRGOT   ; if low byte isn't 0, skip next
119 $77           INC TXTPTR+1 ; increment high byte of TXTPTR
121 $79   CHRGOT  LDA          ; load byte from where TXTPTR points
                               ; entry here does not update TXTPTR,
                               ; allowing you to readl the old byte again
122 $7A   TXTPTR  $0207        ; pointer is really the LDA operand
                               ; TXTPTR+1 points to 512-580 ($200-$250)
                               ; when reading from the input buffer
                               ; in direct mode
124 $7C   POINTB  CMP #$3A     ; carry flag set if > ASCII numeral 9
126 $7E           BCS EXIT     ; character is not a numeral--exit
128 $80           CMP #$20     ; if it is an ASCI space...
130 $82           BEQ CHRGET   ; ignore it and get next character
132 $84           SEC          ; prepare to subtract
133 $85           SBC #$30     ; ASCII 0-9 are between 48-57 ($30-$39)
135 $87           SEC          ; prepare to subtract again
136 $88           SBC #$D0     ; if < ASCII 0 (57, $39) then carry is set
138 $8A   EXIT    RTS          ; carry is clear only for numeral on return

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.

[Alarm Siren]

GARTHWILSON wrote:

A couple of notes:

• The '816 offers a lot of software benefits even in '02-emulation mode.  There is so much there that's not particularly related to the larger address space or wider registers.
• When you put the '816 in native mode, the registers are still 8-bit until you change them to 16-bit.

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.

[wayfarer]

GARTHWILSON wrote:

I lament, with so many other enthusiasts, that so few 65CE02's were made and that it was discontinued so quickly.  I remember well the excitement when it came out.

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?

Quote:

wayfarer wrote:

Alarm Siren wrote:

wayfarer wrote:

I actually found a chip that ...
!!

Indeed, I have a great fondness for the 65CE02. ....

100% agree on a WDC65CE02 ...

A couple of notes:

• The '816 offers a lot of software benefits even in '02-emulation mode.  There is so much there that's not particularly related to the larger address space or wider registers.
• When you put the '816 in native mode, the registers are still 8-bit until you change them to 16-bit.

cjs wrote:

wayfarer wrote:

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.

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.

A few things like stack pushes and pulls could be sped up if this internal memory were on a separate internal bus; but this page-0 and page-1 on-chip memory would then need to be dual-ported, accessible on the normal bus as well, to avoid losing a lot of capability.  Two examples that come to mind are:

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.

[GARTHWILSON]

wayfarer wrote:

GARTHWILSON wrote:

I lament, with so many other enthusiasts, that so few 65CE02's were made and that it was discontinued so quickly.  I remember well the excitement when it came out.

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?

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.

[cjs]

wayfarer wrote:

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 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.

GARTHWILSON wrote:

That 6530 IC was really nice at the time.  There was another company later that did that kind of thing, more powerful, and not 65xx-specific.  I think it was called "Crystal," although I don't know if that's the entire company name.  I threw out my data book not too long ago.

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.

wayfarer wrote:

...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....

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.

Quote:

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.

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.)

Quote:

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.

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.

[GARTHWILSON]

cjs wrote:

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.

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.

Quote:

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),[...]

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,

Code: Select all

        PRINT  "This will be printed!"

which assembles,

Code: Select all

        JSR   PRIMM
        BYTE  "This will be printed!", $00

as chapter 7 of the 6502 stacks treatise goes into, at http://wilsonminesco.com/stacks/inlinedData.html .

Quote:

The "who can do more with fewer chips?" battle is not one you want to get into with Motorola, because they will win.

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."

[Mike Naberezny]

GARTHWILSON wrote:

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

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.