Re: How to design C++ OOP better?
On Aug 30, 9:45 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1872f022-3fc0-4ff6-bc94-
9237327b4...@d1g2000hsg.googlegroups.com>, Immortal_Ne...@satx.rr.com
says...
Jerry,
I have an idea how to design an object in a better way.
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:
I want to thank you for a feedback how 6502 microprocessor
works. Fortunately, I have already written 6502 simulator as a real
6502 MPU chip. My test shows that Run() function processes address
bus, data bus, and internal registers once as one clock cycle. You
can execute Run() function many times as you wish so it processes each
clock cycle.
According to my 6502 research, my MPU_6502 object behaves as real
chip as 6502 simulator very accurately. Unlikely, other emulators
don't do process each clock cycle.
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
};
Nice class design. It is much similiar as my written MPU_6502
class. Unfortunately, it does not work. If you want to define
MPU_6502 object and ICE_6502 object in main() function, inheritance is
not an answer because MPU_6502 object and ICE_6502 object have their
own copy of member variables.
You can create two base classes of MPU_6502 and ICE_6502. You
don't need inheritance. You define MPU_6502 object first and then
ICE_6502 object second. You need to put friend class ICE_6502 into
MPU_6502 class. You set up a pointer inside ICE_6502 class so
ICE_6502 class' member function can access MPU_6502 class' member
variables through a pointer.
Another programmer in this post mentioned differently. He does
not recommend friend. He thinks that ICE_6502 class should be base
and then MPU_6502 class should be derived through private
inheritance. I can't sustain their opinions to think if C++ OOP has a
better design.
Nephi
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.