Re: Logic Gate on Emulator

[mjmahon@aol.com (Michael J. Mahon)]

Bryan Parkoff asked:

>    Can you provide your theory for two different Emulator project?  First
>project is to translate 6502 opcode instructions into 80x86 opcode
>instruction that will be written in assembler language.  Second project is
>to interpret 6502 opcode instructions into C/C++ language before it can be
>complied/linked into 80x86 opcode instruction.
>    I suspect that second project can be very slow than first project.

Both approached are problematic, since many Apple II programs
modify their code during execution, and any store into the instruction
space will require run-time emulation, not compile-time translation.

>    Third project will be doing with Logic Gate.  Logic Gate can be written
>in C/C++ by using if then else statement by using Boolean's Truth Table
>ONLY.  I can tell that it will be over thousand if then else statement.  It
>will be the EXACT same as Apple II's schematic diagram.  80x86 CPU will
>spend too much time by executing Boolean's Truth Table continously.  It will
>IMPROVE Emulator project that it can be running much perfect that it looks
>very real on Apple II.  It can be REALLY STABLEe.  The problem is that 80x86
>CPU will steal too much time that will decrease the performance on Pentium
>III 550MHz, but it will improve performance on newer Pentium IV 2.0GHz and
>higher
>    It looks like that Logic Gate with If Then Else statement can use too
>many 80x86 opcode instructions for testing AND, OR, XOR, and NOT.  It will
>always show accurate number of cycles each second.  I tried to use Kegs32
>Emulator, but it almost has accurate cyclces.  It is not always perfect.
>    What do you think to compare first, second and third projects?  Extra
>opcode instructions can be wasting and they are not necessary if they use
>Logic Gate.

It is axiomatic that the lower the level of a simulation/emulation, the more
faithful it is to the actual behavior of the simulated machine, and the slower
it is.  (Actually, it need not be slower, but the number of simulated, as
opposed to directly executed, operations, will be greater.)

A gate-level simulation of an Apple II is perhaps best done in an FPGA,
a readily available type of programmable hardware.  A gate-level simulation
in software is probably not worth the trouble, since the added fidelity comes
at a huge price in simulation overhead.

The standard tradeoff for simulating the Apple II is a behavioral, instruction-
level simulator, with instruction decoding and execution interleaved at run
time.  Much of the cost of simulation is a result of simulating the hardware
switches and ports and maintaining the appearance of video memory.

It is possible to keep exact cycle counts with such a software simulator,
but, as with many things, 10% of the work will get 90% of the accuracy,
and getting to 99.9% accuracy will cost ten times as much in timing
overhead.  (Every special case must be tested for so that the accumulated
cycle count can be accurately updated.)  Since the special cases occur
rarely, but must be tested for continuously, the speed-accuracy tradeoff
argues for "reasonable" accuracy at minimal cost.  Of course, a "diagnostic"
simulator could be written which would keep precise time information, but
would run, perhaps, half as fast.  If few people need this accuracy, that
would, in general, be a poor design tradeoff.

-michael

Check out amazing quality 8-bit Apple sound on my
Home page:  http://members.aol.com/MJMahon/