This is a collection of features that I think would be desirable for a 16-bit 65-series processor. I'm calling it the 65016, because it doesn't really have an 8-bit mode, the way I see it. I do not have the skills(or equipment) to implement this idea at this time, so I don't plan to do so. I'm putting this out here because Garth said he'd like to see it in a PM, and so that people can see it and comment. And probably laugh at me for it(which I'm fine with. It's probably not that good).
This is only an idea that I cooked up, and I suspect that it's half-baked, but what the heck.

The starting point for this design is the WDC 65C02.

From there:
A, X, and Y registers are 16-bit full-time.
24-bit address space, address pins are not multiplexed.
8-bit data path(To simplify the wiring and the width-switching)
Two new opcodes for bigger operations: WIDE, which makes 8-bit instructions into 16-bit ones, and LONG, which extends addressing.
Math and bitwise logic operations are always done on all 16 bits, but the N, V, C, and Z flags are set to correspond to the width of the instruction being executed.
No decimal mode or emulation mode.
Relocatable Stack and Direct Page(a la '816).
Register swap and STP instructions from the '816.
No shared interrupt vectors(BRK seperate from IRQ).
No clock outputs or /SO, as these are generally not used these days(as far as I know).

Possible features:
COP software interrupt and output pin.
built-in reset circuit with pushbutton(essentially an integrated DS1813).

Discarded features:
Ports and IN/OUT instructions.
These would be active-low chip selects replacing /SO, the NC pin, and the clock output pins. When the IN and OUT instructions are used, the lower 8 address lines work, but the rest are low. IN and OUT have four opcodes each(one for each port). Syntax:
This was discarded as being too un-6502-ish, and painful to implement, as well as for the rather profligate use of opcode space.

Problems:
Exactly how LONG works with the indirect addressing modes.
Where to put the vectors?
Exactly how this works.

This sort of discussion regularly comes up and has almost as many permutations as there are active members on the forum.


Why?


They already are in the 65C816. All that happens when you set the m and/or x bits is make them look like eight bits to the outside world.


That would be a very useful feature. The MUXing of A16-A23 onto the data bus in the '816 was something that was done to make the '816 appeal to Apple. It certainly was not an elegant thing to do. The irony is the '816 could have A16-A23 separately brought out if it was in a PLCC52 package.


Already part of the '816. Two memory cycles are used to load/store words.


WIDE might be useful, but I fail to see any use for LONG. In the '816, long addressing is implicit with the $Fx set of opcodes and the [<dp>] and [<dp>],Y addressing modes. Having to set up 24 bit addressing mode with another instruction sounds like a performance killer to me.

Incidentally, one of the best features of the 65xx family is the use of three character instruction mnemonics. That size makes for a very efficient method of looking up mnemonics. If mnemonics vary in size, as you are suggesting, the look-up function now has to account for that, and a simple index and compare algorithm becomes one of using a pointer table to the mnemonic list in the assembler.


Already the case with the '816. Again, the m and/or x bits determine that in the '816.


Eliminating emulation mode would make the MPU's design easier, plus remove the XCE instruction, freeing up its opcode for something else. Eliminating decimal mode would be a significant loss of functionality in my opinion, as decimal mode is quite useful for converting between the ASCII representation of numbers and their binary equivalents.


Good.


Already the case with the '816 in native mode.


They don't exist on the '816 and their use on the 65C02 has been deprecated.


COP already exists in the '816 and causes VPB to go low during cycles 7 and 8, which can tell logic that an interrupt is being processed.


Not necessary. To quote the '816 data sheet:

2.25 Reset (RESB)

The Reset active low input is used to initialize the microprocessor and start program execution. The Reset input buffer has hysteresis such that a simple R-C timing circuit may be used with the internal pull-up device.

The DS1813's main value is that it senses the level of Vcc and will wait until Vcc exceeds a certain threshold before starting its reset cycle. The need for that feature depends on what else is attached to reset.


Since this hypothetical MPU doesn't have to be compatible with any other member of the 65xx family, I would suggest putting the reset vectors as high in RAM as you can get them to create the maximum amount of contiguous address space.

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

To be frank, I did expect this idea to be as crappy as you seem to make it look.
It's not surprising that this comes up that much. We are all somewhat different in the way we think.

I used the 'C02 for the starting point because it's essentially the current state of 65xx, if you discount the '816. There's no reason that I can think of to base it off of the NMOS part. Probably basing the design off of the '816 would have made more sense, that being a 16-bit thing already.

Not having used the '816, I don't know anything about it besides what I've read in the programming manual and the forums. I had assumed that the accumulator operations operated only on one half of the whole register. This thing has no concept of register sizes, only widths of operations. This(to my mind) makes it clearer what the hardware is actually doing.

The WIDE and LONG mnemonics could be shortened to WID and LNG. Your point about LONG is probably a good one. I was thinking just use the 'C02 instruction set with the addition of functionality not already present and avoid using more opcodes as much as possible. It had occurred to me that if you were doing a lot of 16-bit operations that WIDE might cause problems. All I was really trying to do was kill the need for a hidden flag(which seemed strange to me), and make it so that the programmer would always know what mode the processor was in by making the whole concept of mode go away. I suppose that the unused flag (in the 'C02) could be used for a visible mode bit, if the register widths were all locked together...

The idea with COP was that there would be a seperate output just for it to indicate that the co-processor was to do its thing. Sort of like an interrupt coming out of the main processor, requesting that the co-pro take over. That was just an idea brainstormed up on the spur of the moment, not anything motivated by a real situation.

The reset idea was more to avoid the requirement for anything external, but not destroy the possibility of doing clever things with it.

If it makes it any better, I thought it was dodgy. I might have made a mistake mentioning it in that post(in What to do with more than 64K) in the first place, but it can't be undone now. If what you say is the whole of it, BDD, the '816 is only very slightly different to what I had in mind.

For what it's worth, the length of the mnemonics is a trivial issue, and it shouldn't be a distraction. The difference in time will be completely imperceptible, especially when you use a modern PC to run the assembler on.

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

That vector register idea is a really good one. I'm not sure how one would get code into RAM at 00:0000 while the CPU was still resetting, though. It would seem to make more sense to have the reset vector point to somewhere likely to be ROM, such as FF:0000, or FF:8000.

What I'm saying is that since direct page no longer has to be page 0 and it could default to someplace else, and the stack does not need to use page 1, you can have ROM starting at address 00:0000.

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

That makes sense as I think about it. The ROM being at the start of the address space does make some sense.

Just kind of a funny anecdote related to this.

In college, I took a PDP-11 assembly language course. My friend showed me how macros worked, and I went a bit overboard.

Essentially I wrote a large set of macros as inspired by Forth. I had most of the major constructs, notably control structures, stack, and math. I didn't have BUILD DOES>.

But what I did have was BASE and NUMBER, which is what Garth is referring to.

One of the projects was something like inputing decimal numbers, performing some masking operations, and output hex and binary numbers. (Thinking back, pretty sure I was the only one to output binary numbers.)

As you can imagine, this was utterly trivial. It was, like, 2 dozen lines of code using my macro library. In fact, all of the assembly exercise were trivial with this library.

I turned in a stack of one page answers to the exercises, but also added the 50-60 page listing for the library to explain my macros.

Guess I impressed the teacher, gave me an A.

Mr. Hartung, you'll enjoy some of the articles at http://www.ultratechnology.com/forth0.htm, regarding Forth philosophy. I've read a few tonight. Samuel Falvo told me about the site.

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

I was thinking. If you want to fix almost everything wrong with the 65816, it might be best to use the WDM instruction for a prefix byte. There's more instructions I would like to add, then remove. One feature I would like to add is a speed-flag. Setting this flag will speed up certain instructions such as ASL, TAX, INC, CLC.

Nice idea about using WDM as a prefix. Its effect would be to alter what the following instruction does. Would you go for an FPGA implementation, or add external hardware to an actual '816? Either way there's a lot of potential -- but also some problems that can't be ignored.

For example, you need to defend against the risk that an interrupt could occur after the prefix but before the following instruction. You don't want the prefix to inadvertently affect the first instruction of the Interrupt Service Routine. But you DO want the prefix to eventually affect its intended target (after the ISR completes, dozens or hundreds of cycles later). Simply inhibiting interrupts using SEI is one solution, though not a desirable one. Otherwise solutions exist, both for the FPGA approach and for the external hardware approach.

-- Jeff

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

Then it must get done with the prefixed instruction before it jumps to the interrupt.

That's exactly what WDM is there for—adding two-byte op codes for future expansion (which we now know will never happen).

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

Interestingly, WDM didn't debut on the '816 (although the mnemonic is new). Op-code $42 produces the same behavior on the 'C02 as it does on the '816; ie; two bytes and two cycles, with no spurious data access. So when the 'C02 got modded into the '816 it seems they didn't have to add anything new in regard to WDM. It was already there.

(But they did remove other WDM's that were there. On 'C02, opcodes $02, $22, $42, $62, $82, $C2 and $E2 all behave like WDM, but the '816 gave new meanings to all the WDM's except $42.)

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