So would it make sense for WDC at this point to design a "streamlined" or "stripped down" version of the 65816? Get rid of emulation mode, get rid of decimal mode, fold the Program and Data Bank Registers into a real 24 bit address space, and replace some of those "weird" pins with real address outputs? After all, the quote on their website says "Simple elegance is a hallmark of the WDC CMOS 65xx brand technology", and I'm not sure if "simple elegance" is the first term on everybody's mind when they think of the 65816.

I don't think so. It's easy to make a decent small CPU, but the market wants microcontrollers and SoCs. And the problem with making microcontrollers is that every customer wants something different, so you need a huge portfolio of different options to capture the interest of all of them. Some people want extreme low power, others want floating point and ethernet, and some even want both.

Even making a really small core isn't very interesting any more. An ARM Cortex M0 is really tiny, not because it's so simple or streamlined, but because modern process technology is so good. Either the IC will be I/O-bound, or memories and peripherals will dwarf the CPU core.

That's true, and yet, more computers were built around the 68020 than the 65c816.

Even the 68008 had some success, despite having only a bytewide memory interface. My guess is that 68k succeeded because C compilers were a good fit, available, and we had the memory. It's a suitable CPU for a Unix-like system.
Also notable, Motorola would have more marketing presence and support capability than WDC. Around the same time, Zilog also had a go, with the Z8000 family, but it was not a great success. Motorola and Zilog didn't attempt backward compatibility, Intel and WDC did. In both cases the larger player succeeded- the player with more engineers, more customer feedback, more support capability, more marketing presence.

I think Intel engineers really did an amazing job at all the way from 8086 to current CPUs, using only backward compatible steps, and gain many orders of magnitude improvement. Along the way, they pretty much beat everybody else, even if they had "superior" designs.

Broccoli is very good for you, and you should eat it almost everyday if you can. The easiest way to add it to your diet is to obtain some frozen "Broccoli Florets", which turn out pretty well if you microwave for 3-4 minutes.

The microwaving process dehydrates them slightly while reducing sulphur compounds, which makes them sweeter and much more palatable. You can then add them to something like Fettucine Alfredo, or perhaps just melt some American Cheese on top. Whatever it takes to get it down.

There are no excuses, grow up and eat your damn broccoli.

(For some people it tastes rather bitter: http://www.livescience.com/39578-why-so ... ccoli.html)

For our members who don't live in the USA, "American cheese" is a processed form of cheddar and colby that also contains other dairy products. Hence it cannot be legally referred to solely as "cheese." Incidentally, I've heard my relatives in Canada refer to the exact same product as "Canadian cheese." Go figure!

All of this is way off topic!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Sorry After using the '816 more, I started to enjoy it a lot more than the '02.

I kinda wish there were separate add/adc (and sub/sbc) instructions. Also, signed indexing and 16-bit branches would have been nice. But it probably made more sense at the time to keep it as much like the '02 as possible, especially with the backward-compatibility in mind.

The '816 had to remain backward compatible to the 65C02 instruction set. That was one of the primary requirements set forth by Apple when they approached Bill Mensch about a 16 bit upgrade to the 'C02.

The Motorola 6800 had ADD and SUB in its instruction set, as well as ADC and SBC. When the 6501 was developed it was designed to be less expensive than the 6800 and elimination of ADD and SUB was one of many small changes that were made to achieve the cost reduction. Obviously, it worked out very well.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The 6800 only has one index register, reducing the number of op codes needed, leaving room for ADD and SUB instructions and for the nearly useless clear-accumulator instruction which saves no time compared to LDA#0. The '816 has the op code table completely full, though, with a lot of good extensions. The WDM op code is reserved for expansion (which we now know will never happen) to two-byte op codes. I think the occasional two-cycle CLC and SEC is less of a penalty to pay than frequently having to read another op code byte. However, it would always be interesting to see what they could have done with the '816 design if it didn't have to be able to run legacy '02 code.

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

The WDM placeholder should have been used as the preamble to a set of 16 bit immediate mode instructions. For example, instead of REP #%00100000 followed by LDA #$1234, a new mnemonic (perhaps LAW) could have been specified that would generate 16 bit immediate mode instructions, using existing immediate mode opcodes. For example, LAW #$1234 would assemble as $42 $A9 $34 $12, where $42 is WDM and $A9 is, of course, LDA #. The obvious advantage with this approach is that neither the assembler or programmer has to be constantly aware of the size of immediate mode operands, making for cleaner and easier to understand code. The equally obvious disadvantage is the effect on code size and speed.

Oh well!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Because of the compatibility requirement, it's probably unfair to compare the '816 to other processors. (I don't think copying the 6502 instruction set verbatim would have made sense for a completely new 16-bit design, though.)

I see now that considering all the addressing modes, adding ADD/SUB would have gobbled up a bunch of opcodes. WDC did squeeze a lot of power out of the existing instructions, by adding the movable direct-page, banking, 24-bit addressing, etc.

There is a 16-bit branch that I forgot about (BRL), but it takes 1 more cycle than JMP and it's unclear to me what this is for. Also, what are the stack relative addressing modes for?

What you are highlighting is the dichotomy of backward compatibility versus new features. Clearly, Bill Mensch had to carefully pick and choose what could be added without taking away the bulk of the existing 6502/65C02 instructions. Furthermore, he was working with an ISA in which all opcodes are one byte, thus setting a hard limit on the number of instructions that could be supported. This is where the reserved WDM instruction was supposed to help.


BRL is primarily of value in developing relocatable code. A JMP instruction is an absolute reference to a specific address that is generated at assembly time. The JMP instruction's target address is only valid if the program is loaded to the original assembly address. Relocating the program when it is loaded would cause JMPs (and JSRs) to direct the MPU to undefined locations, at best causing bizarre behavior and at worst, causing a crash.

On the other hand, BRL, like all relative branch instructions, references the current program counter at run-time, which means it will land the MPU in the right place without regard to where the program has been loaded. As BRL's operand is a 16 bit signed offset, it can branch forward $7FFF bytes or $8000 bytes backward. Incidentally, BRL in conjunction with PER can be used to synthesize the BSR (branch to subroutine) instruction of the Motorola 68000. It's one of those things best buried in a macro.


Stack pointer relative instructions allow the programmer to conveniently use the hardware stack as a scratch pad in function calls. Rather than predefine storage for a function call (aka subroutine), the programmer would reserve some space on the stack when the function is entered and then use stack pointer relative addressing to read and write on that space. Upon exit, the function would relinquish the extra space and the stack would be back in balance. The allocation and deallocation of the stack space is made convenient by the fact that the (16 bit) stack pointer can be copied to and from the accumulator and thus readily manipulated with 16 bit arithmetic.

Another use for stack pointer relative addressing involves passing parameters into functions via a stack frame that is generated by the caller. The function would then "cherry pick" parameters from the stack as needed. There is a good discussion of the use of stack pointer relative addressing in the Lichty and Eyes programming manual (jump to page 240 in the PDF copy). I use stack pointer relative addressing extensively in my POC unit's firmware and in a lot of programs.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

If you use the hardware stack for passing parameters to and from subroutines, you would be extremely limited if you could only access them with push and pull instructions. Although all additions to, or removals from, the stack happen only at the top, you will want to read or modify bytes that are further down the stack. That's where stack-relative addressing comes in. For example you may want to ADC a byte that's five bytes below the top of the stack, without pulling everything off the top to get to it. Stack-relative addressing can be done on the 6502, but not as efficiently as on the '816. There's a lot on it in my 6502 stacks treatise, starting about 40% of the page on stack addressing.

For an example of passing a table address as a parameter to a subroutine, here's a little from the page in my 6502 stacks treatise on synthesizing some of the 816's stack-related instructions on the '02:

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