As well as what BDD mentioned, (ZP,X) is also used for smallish stacks in the zero page which can be very handy when writing interpreters (and is heavily used by several FORTH interpreters, IIRC).


Did you have in mind a branch instruction to remove from the %xxx10000 column of instructions? If not, this is going to add not insignificant complexity to the instruction decoding. At which point perhaps adding both BRA and BSR (the 6800 has both) is very little more expense.


I don't understand what that means, in particular the "reduced from" part. I don't see how Y is "reduced from X"; they seem the same thing to me. They inherently select different addressing modes, but that just saves a bit for that in the instruction that would allow both to be used for either mode. Nor do I understanding how either is "reduced from A"; A has a completely different purpose and a different set of things you can do with it. (Not more, just different; there are things you can do with X and Y that you can't do with A).


That's been done with the 6800 (the 6802 added 128 bytes of on-board RAM), but it doesn't make any real difference except to system designers that can live with 128 bytes of RAM and thus can save the cost of having any external RAM. In particular, it doesn't change the speed of the processor at all.

_________________
Curt J. Sampson - github.com/0cjs

No, I meant a simple BRA just like what the 65C02 has.

i did try that one. i wrote a 65C02 emulator in C, gave it an internal Zeropage and Stack (both can do 16-bit reads in a single cycle, the stack can also do 16-bit writes in a single cycle), and also gave it an adjustable instruction queue similar to the 8086/8088, and finally an adjustable data bus width.
viewtopic.php?f=8&t=7499

the CPU is internally using a harvard-like architecture where there are 2 data and addresses busses for instruction fetching (which goes to the queue) and instruction execution (which goes to the ALU/Registers). and since there are 3 discrete types of memory (zeropage, stack, and external (through the CPU's pins)) the CPU can both fetch instructions and do data memory accesses at the same time, as long as they don't try to access the same type of memory.

so for example, if you have a program or function that only uses the zeropage or stack, and all of the instructions are located in external memory, then the CPU can fetch new instructions into the queue pretty much every cycle.

and i think that having a small instruction queue, even without internal RAM, would already help a bit with performance. as suddendly all dead cycles can now be used to pre-fetch instructions. you could even add more "dead" cycles to some complicated instructions to add more chances to pre-fetch more instructions and overall reduce the amount of work that would otherwise be done in a single cycle, which could increase the maximum operating frequency.

I haven't. I spent about 2 years in the early 80s as a teenager writing games on the Atari 800XL. My games had their technical elements, making competent use of the hardware, but the programming itself was unsophisticated and mostly array-based.

Nowadays I dabble from time to time, but not even to the extent I did back then.

But the question was what I would change, and through my own limited lens, (ZP,X) gets the chop.

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

A quick 1+ for what Garth said.

You won't lament the loss of X; you'll be rewarded by its utility in a role that's similar in some ways to that of a frame pointer! Passing parameters back and forth between routines is far more easy and natural compared with doing so via the hardware stack in page 1.

I'm tempted to reiterate further, but Garth's post already states the case very nicely. Worth reading (not just skimming)!

-- Jeff

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

Yes, understood. As I mentioned in my post, I see in MSBASIC using it, and I did read your page 1 post, as well as this one, as well as many other Forth-related posts in the past that mention it. None of those have ever been directly relevant to the code I've written.

I don't doubt that it's useful, but I'm making a personal choice to prefer (ZP),X, as that is what I wanted back when I wrote a lot of code. I respect that it wouldn't be your choice. But it's mine.

I know you're trying to convince me that my choice is in error, but until the day I use it personally, and go, "Ahh... gotcha."... my choice stands.

Hope that's ok. You go ahead and continue to enjoy (ZP,X) and I'll continue to wish it were (ZP),X.

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

Garth, don't over-think it. The rules of the game were to suggest changes balanced by trade-offs. I didn't ask for the very useful PHY, PLY, STZ, and other useful additions from the 65C02 as the only thing I wanted to drop from the 1975 design was decimal mode. At no point did I say (ZP,X) isn't useful. Clearly it is. But it's something I would trade.

I'm a novice level programmer here, and those with vastly more 6502 experience agree with you that mine is a terrible idea. I'm comfortable with it.

I actually found a chip that does most of what I was thinking, it was released in 1988, so still 'in the era' I guess.

the 65CE02, from CSG, located here on the archives.
http://www.6502.org/documents/datasheets/mos/mos_65ce02_mpu.pdf
it had a Z register and a relocatable stack. Further, it had some improvements to its pre-fetch cycle, with the same nods towards Scalar pipelining I had mentioned elsewhere.

65CE02 seems to have a few things the 65816 had, 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.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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 see the MOS 6500 series CPUs as a design intended to be somewhat compatible with the 6800 series as a secondary objective (you'll note that the bus protocol is the same, and the 6801 even had the same ability to tri-state the bus) and being much cheaper to implement as a primary objective. Pretty much every change from the 6800 appears to be to make it cheaper or faster. (The switch from big-endian to little-endian is an example of giving it a speed advantage.)

The primary design criterion of the 65C02 and later CPUs was compatibility with the (documented) design of the 6502. 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.

_________________
Curt J. Sampson - github.com/0cjs

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

It was a trade-off to hit a budget.

When comparing CPU specs, I doubt an engineer of the time would say, "I'm looking for a processor that doesn't have a BRA instruction. That's a feature I'm interested in." No... they'd say, "I'm looking for a processor that will let me hit my dollar target", and dropping features is what let them hit that target.

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.

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


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

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

i would also change the way RTN # works. as described in the datasheet/other sites, RTN pulls # bytes off the stack (and discards them), and then reads the return address. with the idea being that you can easily get rid of a stack frame made during a function's execution.
but i would argue that having it the other way around is more useful. first pull the return address THEN pull # bytes off the stack (and discards them). with the idea being that you can remove function arguments that were pushed before the function was called using a single instruction.

i say it's more useful like that because while you can emulate either functionality manually using a macro, pulling bytes first and then returning is a lot easier to emulate than first getting the return address and then pulling bytes. so by having the instruction implement the more difficult/complex one, it means that if the other way is required it can be replicated much easier and with less code.


honestly if i had the choice between JSR and BSR, i would probably drop JSR and make BSR use a 16-bit relative offset. it's functionally the same (in most scenarios) as JSR but allows for position independent code. same with JMP and BRA or rather BRL (branch always long), i would keep BRL and remove JMP. but i'd keep the Indirect JMP's absolute, so you can still make use of function tables within a ROM regardless of where the code is located in RAM.

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