Simplest subset of 6502

[Alarm Siren]

So, this topic on the Furby's cut-down 6502-like CPU got me thinking... What's the simplest subset of the 6502 architecture that could still be reasonably useful?

Obviously that line is a bit fuzzy, because I'm not talking about going down to the levels of Turing Machines or An unfortunately named esoteric programming language, so I'm thinking this will be a somewhat subjective discussion. Rephrased another way to allow for said subjectivity:

What's the simplest subset of the 6502 architecture that you feel would still be reasonably useful in a real-world use-case?

To be clear I am talking about strict subsets of one of the 65C816 or 65C02. You're not allowed to alter or add anything, only take things away; what you end up with must still be binary compatible with an existing 65C02 or 65C816 program which doesn't use the removed capabilities. I would expect most solutions to be based on 65C02 since its already simpler, but I'm including 65C816 as an acceptable starting point because you might feel that one of the 65C816's new features can replace several features of the 65C02's, thuse giving a smaller subset overall.

---

My own initial thoughts are:

1. Start with 65C02 as the basis.
2. Trim down to 8-bit addresses and we can dispense with absolute addressing modes entirely and only use ZP-related modes.
3. We don't need both X and Y, though I'm not sure which I'd prefer to keep as both are useful in different ways.
4. Don't need interrupts, both hardware and software. Saves some instructions and removes the I flag.
5. If we don't have interrupts, we don't strictly need a stack either, so the S register can go.
6. As there's no stack, can't have hardware-assisted subroutines, so those instructions can go too.
7. V and N flags are not really necessary, so they and their associated Set/Clear and Branch instructions can go.

Technically the Z flag could go (you can use a subtraction and look at the C flag), but that's one feature I would probably draw the line at losing as it comes up a lot in loops. I also feel that in the context of such an 8-bit address system, the bit-fiddling instructions (TSB/TRB/RMB/SMB/BBR/BBS) would actually be more useful than they usually are and thus worth retaining.

Now, certainly the above isn't going to hold a candle to a full 6502, but I'm thinking it could be useful as a little co-processor or I/O controller of some kind. Wozmon fitted in 250 bytes of ROM, so I'm sure you could do something useful with (say) 224 bytes of ROM, and 16 bytes each of RAM and I/O space. Heck if you really needed more RAM you could always hook some up indirectly with a PIA or VIA through the I/O space.

---

Very interested to hear all of your thoughts!

[BigEd]

It would feel extreme, but dropping ADC and EOR should be workable: SBC is enough.

Surely we don't need both of SEC and CLC.

Maybe even keep the decrement but lose the increment instructions. That'll show 'em!

One or other of the shifts and rotates to stay, and one to go - how about that?

The absolute indexed can probably go - but I see you've already dispensed it.

(The thing is, we know we can trim almost everything and still have the theoretical power of the original, but at what cost? So it's a bit hard to know where to stop - it's a tradeoff that we can't quite see.)

[GARTHWILSON]

You could start by looking at what others have done, to evaluate various ideas and perhaps cut the process shorter.  One that comes to mind is the BMOW Tiny CPU in a CPLD, which is intentionally very 6502-like.  Another is the PIC16C5x microcontrollers (link is to a .pdf), although the architecture is radically different from that of the 6502.  I haven't used the 5x, only 6x.  They have about the same number of instructions, 35 and 33, including addressing modes, for example that its ANDWF (similar to 65's AND  ZP) and ANDLW (like 65's AND#) are counted as two separate instructions in the 33 or 35.  Certain things are very problematic (or even impossible) to try to do on the low-end PICs; but if you want something super minimal, you can take a look.  I've brought a dozen products to market with PIC16F's, so from experience, I could be someone to bounce ideas off of regarding them.

Edit, to address a few things on Alarm Siren's list:  The low-end PICs' instruction set does include CALL (like 6502's JSR) and RETURN (like 6502's RTS), but the stack is very shallow, in the processor itself (not in user RAM) and is not accessible to the programmer.  The equivalent of the I flag is the GIE (global interrupt enable) flag in the INTCON (interrupt control) register which is in the RAM map.  The processor flags include Z and C, but not N.  There are no indexed or indirect addressing modes, but there's an FSR (File Select Register) which you can read, write, clear, increment, decrement, etc. and an INDF (INDirect File access) address (not a physical register, but used to access others through it, and you can write to the program counter.

[gfoot]

Alarm Siren wrote:

[*]We don't need both X and Y, though I'm not sure which I'd prefer to keep as both are useful in different ways.

You could get rid of both of them and still have a usable instruction set.

Quote:

[*]If we don't have interrupts, we don't strictly need a stack either, so the S register can go.
[*]As there's no stack, can't have hardware-assisted subroutines, so those instructions can go too.

I think losing the ability to do subroutines is a huge sacrifice and possibly makes it no longer "reasonably useful".

BigEd wrote:

Maybe even keep the decrement but lose the increment instructions. That'll show 'em!

You can always write 255 decrements in a row!

Quote:

One or other of the shifts and rotates to stay, and one to go - how about that?

.. or eight rotate-rights instead of one rotate-left.

[AndrewP]

In the real world if simplifying the 6502 means that I could buy them cheaply then they could absolutely be useful.

Looking at all the simple devices I've implemented in 74 series ICs then a cut down 6502 would also cut those designs down to just a couple of chips.

Keyboard controllers, UARTs, audio mixing even something as simple as a radio channel selector. If I could buy a 6502 for, like, a dollar it would be a no brainer. Kinda something like the Intel 80C51.

Of course the question now becomes: must I connect RAM? Does it have internal ROM? Who provides the clock? Will it have GPIO'ish pins like the 6510's ports?

[Alarm Siren]

gfoot wrote:

I think losing the ability to do subroutines is a huge sacrifice and possibly makes it no longer "reasonably useful".

Yes I agree its a big loss, but I considered that in the context of a memory space only 256 bytes large, you probably don't want to be worrying about the stack accidentally overwriting your tiny amount of RAM. Plus, any program simple enough to fit in such a space probably doesn't have much need of subroutines anyway. I wouldn't remove subroutines (or the Stack for that matter) if the memory space were larger.

AndrewP wrote:

In the real world if simplifying the 6502 means that I could buy them cheaply then they could absolutely be useful.

Looking at all the simple devices I've implemented in 74 series ICs then a cut down 6502 would also cut those designs down to just a couple of chips.

Keyboard controllers, UARTs, audio mixing even something as simple as a radio channel selector. If I could buy a 6502 for, like, a dollar it would be a no brainer. Kinda something like the Intel 80C51.

Of course the question now becomes: must I connect RAM? Does it have internal ROM? Who provides the clock? Will it have GPIO'ish pins like the 6510's ports?

Yes, I vaguely had the thought of a very simple and cheap 6502-like microcontroller in mind. By being a strict subset, you can use your existing knowledge and toolchain.

[BigEd]

There's a very nice pair of posts by Ken Shirriff about the firmware in Sinclair's Scientific Calculator and the TI processor within. That processor lacks a call/return, but it's possible to reuse a routine by setting a flag before jumping there, and then testing the flag when jumping back: it's just a question of knowing the call sites, and not having too many of them.

[barnacle]

What? And no-one's mentioned chopping the decimal mode out?

There's an interesting 16-bit risc teaching design that gets away with just SBC and NAND in the ALU, but I suppose NAND counts as something new... but you can of course do any logical operation with just NAND.

I did a homebrew many years ago that was deliberately 6502ish but got it down to (I think) seventeen instructions and three flags; a simple design just to play with a simulator has fewer but the ALU just ADDs with a carry output, but no carry input. Subtraction *is* possible but it's a slow pain to complement one of the operands.

Neil

Edit: https://user.eng.umd.edu/~blj/RiSC/

[Alarm Siren]

... is it wrong that I totally forgot that the decimal mode exists?

[GARTHWILSON]

barnacle wrote:

There's an interesting 16-bit risc teaching design that gets away with just SBC and NAND in the ALU, but I suppose NAND counts as something new... but you can of course do any logical operation with just NAND.

I did a homebrew many years ago that was deliberately 6502ish but got it down to (I think) seventeen instructions and three flags; a simple design just to play with a simulator has fewer but the ALU just ADDs with a carry output, but no carry input. Subtraction *is* possible but it's a slow pain to complement one of the operands.

In the Forth world, there have been various discussions over the years about how few primitives you could get away with.  (Primitives are the functions defined in assembly language, or in the case of stack processors whose assembly language basically is Forth, they would be the machine-language instructions.)  The idea was partly for easiest portability, such that if you encounter a new processor that doesn't have a Forth kernel written for it yet, you'd have a minimum of primitives to write, and those are used to build everything else, the latter being common to all processors.  The consensus seemed to be that the reasonable minimum was about 30 primitives; but going to a ridiculous extreme, I think someone figured out you could do it with something like 13.  (Performance would be terrible though.)

[Martin_H]

Over the summer I started a thread called "Turing Tarpit Programming Challenge" where I wrote several programs and with each further restricted the instructions I allowed. I concluded that the following 65c02 instructions and addressing modes allowed for a reasonably useful system.

Code: Select all

Accumulator operations: and, ora, eor, adc, clc, inc, ror, and rol
Memory operations: lda #, lda absolute, lda (), sta absolute, and sta ()
Flow control instructions: bcc, bcs, beq, bne, jmp absolute, jmp (), jsr absolute, rts, and nop

That's 16 instructions, which is a notable reduction from the 6502's 56, and matches the PDP-8. I allowed absolute addressing because the 6502 is a byte machine and one or two byte operands are intrinsic to such a design. I also allowed the zero control bit because the PDP-8 had skip on zero.

Notable missing instructions are CMP, DEC, PHA, PLA, and SBC. Subtraction is done by adding the two's complement, and precomputed negative quantities. CMP is a nondestructive subtract, so you have to subtract and test for zero. DEC is achieved by adding negative one. This was actually common on early machines with a discrete logic ALU. The PDP-8 didn't have a stack, so I didn't allow its use for anything other than subroutine calls.

I was able to write a slow but usable Game of Life with those restrictions.

[BigEd]

That's a very good result! It's a nice semi-arbitrary stopping point, some power of two, because it motivates a possible implementation. And writing a proper program with the chosen subset is a very good idea!

[Dr Jefyll]

Martin_H wrote:

Code: Select all

nop

I don't dispute the value of having an instruction that does nothing. But is it necessary to devote one of your precious sixteen opcode encodings?

Back in the 20th Century I designed and deployed a discrete-TTL machine that had no NOP per se. But in order to fill that need, certain operand encodings (not opcode encodings) were reserved. A similar idea might be helpful for the "Simplest subset of 6502" machine. For example, sta absolute is a NOP if the operand specifies a ROM address. Better candidates can probably be contrived.

OT: for the curious, see One-bit Computing at 60 Hertz. The machine is a bituva mutant, because there actually aren't any opcode encodings. There're no need for an opcode because the machine only has one (somewhat VLIW-ish) instruction!

-- Jeff

[Alarm Siren]

Dr Jefyll wrote:

Martin_H wrote:

Code: Select all

nop

I don't dispute the value of having an instruction that does nothing. But is it necessary to devote one of your precious sixteen opcode encodings?

Back in the 20th Century I designed and deployed a discrete-TTL machine that had no NOP per se. But in order to fill that need, certain operand encodings (not opcode encodings) were reserved. A similar idea might be helpful for the "Simplest subset of 6502" machine. For example, sta absolute is a NOP if the operand specifies a ROM address. Better candidates can probably be contrived.

OT: for the curious, see One-bit Computing at 60 Hertz. The machine is a bituva mutant, because there actually aren't any opcode encodings. There're no need for an opcode because the machine only has one (somewhat VLIW-ish) instruction!

-- Jeff

Believe me, I have scoured your website (and its hidden depths) in great detail and with fascination in the past, this included. I have always found the Diablo CPU pages particularly interesting.

[Dr Jefyll]

I'm honored and delighted by your remark... even though I have somewhat of a love/hate relationship with my web site.

As for hidden depths, I'm afraid others may discover that the Wescode and Diablo material is a little hard to find. But this page explains what a Wescode is. (Special highlight! Scroll down to "The kludge that no-one questioned"! )

And this page describes the Diablo 1345 workhorse daisywheels used by the Wescode systems in this demanding production environment. Special highlights: "the Diablo proprietary processor" and "Cracking the system and customizing the code."

-- Jeff