Emulator, Inc

["Bryan Parkoff" <nospam@nospam.com>]

    I have read Darek's website at http://www.emulators.com/.  Darek is an
emulated programmer and he told me that he claims that C/C++ language is the
WRONG languge for Emulator Project.  He says that he focuses at assembly
language for best optimization and performance.  It is almost impossible for
me to tell since he has been programming for over 17 years.  He always
disagrees with many programmers for general Emulation.
    The fact is that Assembler Language is obsolete that Microsoft and Intel
claim.  Both of them recommend to use C/C++ language.  The C/C++ compiler
will do its job to optimize C/C++ source code.
    I believe that you must be a good C/C++ programmer that can write
shorter routines that will make Emulator run much faster.  It is wasting a
lot of time to write in assembly language.
    I know that Pentium 4 has some problems, but I stay on Xeon Pentium III
until Pentium 4 will be fixed.  I don't like Intel's rules for avoiding some
x86 instructions, but I am told that Visual C++ 7.0 will be recommended
because C/C++ 7.0 has adjusted the optimization over Visual C++ 6.0's
Compiler 6.0, otherwise I would buy Intel C/C++ Compiler 7.0 that will plug
into Visual C++ 6.0 or 7.0.
    It is the way I can write shorter routines for my Emulator Project and
then I compile and go into debugging mode.  I can read x86 disassembler that
it makes sense to me (I don't use inline assembler function or MASM 6.11).
If it is in release mode, it will be difficult for me to understand by
reading x86 disassembler because it is already optimized that it is not the
same as debugging mode.
    I can tell that KEGS32 Project has a huge source code and have a very
long routines.  It is not good for writing emulated practices.
    If you want to avoid using classes, I recommend to write global
variables that are much easier to read that looks like classes.  Lets says,

class CPU
{
    DWORD m_Accumulator = 0x00;
    DWORD m_XIndex = 0x00;
    DWORD m_YIndex = 0x00;
    void CPU_Run();
    void CPU_Initialize();
    void CPU_Terminate();
}

    All 256 6502's OpCode routines stay in CPU_Run() by using goto statement
rather than calling functions.  Three local variables are inside classes so
it won't show global variables.

    If you choose not to use classes, there is an alternative.

DWORD CPU_Accumulator = 0x00;
DWORD CPU_XIndex = 0x00;
DWORD CPU_YIndex = 0x00;

void CPU_Run();
void CPU_Initialize();
void CPU_Terminate();

    It is global variable that begins with CPU_ instead of g_ for easy
reading.  All functions are global functions.  It will reduce minor bugs.
Use BYTE and WORD keywords are bad practices for Emulator because C/C++
compiler always adds "AND" instruction to clear 32-Bits, 24-Bits, and
16_Bits.  DWORD is chosen so "AND" instruction is removed.  It can reduce
x86's cycles and improve performance.
    Do you know what I mean by examining debugging mode so you can see
unneeded instructions?

    I would like to discuss with some Apple II Emulator programmers via
e-mails if it is possible.  It is not good to post Emulator Project
Programming Practices on newsgroups because nobody is interested in writing
Emulator Project until they are interested to play released Apple II
Emulator software.
    Please advise.


-- 
Bryan Parkoff