Re: How to design C++ OOP better?

In article <1872f022-3fc0-4ff6-bc94-
9237327b44ce@d1g2000hsg.googlegroups.com>, Immortal_Nephi@satx.rr.com
says...

The first part of good design (OO or otherwise) is applying knowledge of
the domain, first acquiring that knowledge if necessary.

In this case, it looks to me like you're trying to create a design that
just doesn't work much like a real 6502 microprocessor did. For example,
you mention making the address bus available to external code via get
and set methods. On the 6502, the address bus was output-only, so an
emulator that took inputs on the address bus wouldn't be very accurate
at all.

An accurate emulation of a microprocessor starts with its data sheet.
Generally speaking, you have inputs that correspond to its input pins,
and outputs that correspond to its output pins. Depending on how
detailed an emulation you want to provide, you may or may not want to
emulate (for one example) its address bus directly -- you may prefer to
simply have an array (or vector, etc.) available as its memory, and the
"address bus" will be implicit in the subscripts supplied to that array.

I'm not sure, but it sounds like your real question was about whether it
was a good idea to make the debugging class a friend of the
microprocessor class. While that's certainly a valid possibility, I
think I'd use inheritance:

class MPU_6502 {
    // Note: incomplete, untested, etc.
protected:
    char A, X, Y, F, SP;
    short PC;
    enum flags { carry=1,
            zero=2,
            IRQ_mask = 4,
            decimal = 8,
            BRK = 16,
            OV = 64,
            negative = 128
    };
public:
    reset() {
        A=F=X=Y=0;
        SP = 0xff; // ?
        PC=0xFFFC;
    }
    SO() { F |= OV; }

    // Add functions for IRQ, NMI, etc.
};

class ICE_6502 : public MPU_6502 {
    // extra debug access here
};

This corresponds fairly closely to reality: the real 6502 provides only
certain specific access to the internals, but there is also such a thing
as a ICE (In-circuit emulator) that can be substituted for the real
processor, which also provides more access to processor internals. This
does require making most of the internals protected instead of private,
but IMO this is a fairly minor problem -- you're not dealing with a
large class hierarchy here.

From there, you're left with questions about the emulation you want to
provide. This includes both whether you emulate the processor bugs or
not, and the level of detail you want to provide. An emulator to play
Apple/Atari/Commodore games will generally be quite different from one
that lets you see how whether (for example you can use a clock signal
with a given amount of noise or not.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.