re> I'm not concerned about who cooked up what, but I do want to
re> understand what you're hoping to do and how you're going about
re> it.

    I thought if you were interested in what I was hoping to do,
    then it would be useful to distinguish that from what Jan did
    earlier.  Hence the little history review.

re> It strikes me, that the objects to be manipulated in consist
re> of four classes, namely code, idata, xdata, and SFR's.

    True, although I've been sort of lumping idata and the SFRs
    together because for the direct addressing mode, the SFRs and
    the lower 128 bytes of idata are handled identically.

re> There's got to be an address bus, separate from PC, as PC
re> isn't always used to address things,

    I've been thinking in terms of three address busses
    (multiplexers really, but that's another story), one for each
    of the three classes code, xdata, and idata/SFR.  These muxes
    are easily identified on the diagram as the ones that supply
    the addresses to the code memory, external memory, and
    internal memory, respectively.

re> and there's got to be a temporary register (I refer to
re> this/these as impending operand register(s), and generally use
re> only one).  These are not addressable by the MCU instructions,
re> but certainly have to be there.

    Got 'em.  I called them T1, T2, and T3.  I think you may be
    right that only one of these is really necessary.  Some of the
    notes at the bottom of my big chart are hints to myself that I
    need to revisit this.

re> Aside from PC, there really aren't any other core features
re> that aren't accessible through SFR space, are there?

    I don't think so.

re> PC is loaded by JMP, CALL, and RET/RETI instructions and
re> iterrupts, as well as RESET.  Aside from that, it's simply
re> incremented, and you have, as I understand it, chosen to do
re> that with a counter.

    No, the PC isn't a counter.  Since I needed an adder already
    to calculate relative jump addresses, I use that same adder to
    increment the PC.  That adder is called PCA (for "program
    counter adder") on the diagram.

re> Likewise, I've gathered you're implementing SP, DPL, and DPH
re> as loadable up/down counters, too.

    SP, yes, so that PUSH and POP and the calls and returns are
    all quick and easy.

    I haven't decided about DPTR yet.  The question there is
    whether or not it's worth the extra hardware to make INC DPTR
    a one-cycle instruction as opposed to the multi-cycle affair
    that would result from doing the 16-bit increment using the
    8-bit ALU.  But I guess in the spirit of squandering hardware
    to pay for performance, I'll probably make it a counter.  Note
    that it can be an up-only counter, since there is no DEC DPTR
    instruction.

re> Are you using counters for the registers, A and B?  What about
re> the rest of directly addressable SFR space?

    No, and no.  I don't see where that would buy me anything.

re> Some definitions of the symbolic names you've used in your
re> diagrams would be helpful.

    Noted, and thanks.  I will make some sort of an index the next
    time I do an update.

 -- Russ