Re: Most Difficult Emulator

["Steve Mentzer" <dropthistext.smentzer@pacbell.net>]

I understand what you are trying to achieve, but I will use simple math for
you...

lets say the total run time for an emulator is "100" (could be minutes,
seconds, etc)

The breakdown (when profiled) for a typical emulator looks like this.

Video/Audio Processing : 55%
Housekeeping: 5%
MemRead/Write: 25%
Aux Device Management: 5%
CPU Core: 10%

Let's put that in perspective. If the total run time is "100", this is the
amount of time spent in each part of the emulator.

Video Processing : 55
Housekeeping: 5
MemRead/Write: 25
Aux Device Management: 5
CPU Core: 10

If you were to improve CPU processing times by 500%, and re-distribute the
time elsewhere, the following will occur...

Video Processing : 59
Housekeeping: 6
MemRead/Write: 27
Aux Device Management: 6
CPU Core: 2

Yes, the effective speed of the CPU core is 500% faster! But the bottleneck
is not the core speed. It is the video processing, housekeeping,
memread/memwrite, and aux device mangement.

If you want to see the effects of this, disable video output from XGS/32 via
a recompile. The effective emulation speed will hover around 75% of the host
processor. For instance, the effective emulation speed on a 1Ghz athlon will
be about 750Mhz.

Re-enable video processing, and it will dramatically dimish to around 30Mhz.

My figures above don't take into account for the necessary overhead to
acheive jitting of the code. Keep in mind that for every memory write, you
will have to flag that "page" of code/data as "dirty", and the when the code
pointer reaches that "page", you will be forced to recompile that section of
code. Given that code/data is interspersed at random through Apple II
binaries, there is going to be a performance hit.

Like I said. I appeciate your efforts. But don't assume that you are going
to have a "blazing fast" emulator because you managed to minimize the
overhead associated with a non-bottleneck component of an emulator!















"Bryan Parkoff" <BParkoff@satx.rr.com> wrote in message
news:tObd9.394043$m91.15557421@bin5.nnrp.aus1.giganews.com...
>     It is true that you think the time is wasting.  My wasting time is not
> important to me, but I make this project much better as improvement than
the
> previous emulators.
>     It will make much difference than ever before.
>
> Bryan Parkoff
> BParkoff@satx.rr.com
>
> "Steve Mentzer" <dropthistext.smentzer@pacbell.net> wrote in message
> news:nr5d9.15$La5.58113@news.uswest.net...
> > Bryan,
> >
> > Congrats on your enthusiasm and effort on developing this new style of
> > emulator for the IIgs.
> >
> > However... you are wasting your time.
> >
> > The *vast* majority of processing time is spent OUTSIDE of the CPU
> > emulation.
> >
> > The big time-killers (and slowdown) occurs during video, audio, input,
> > memory reads/writes,  and "housekeeping". Keep in mind that CPU
emulators
> > are usually running in the L1 cache on the host processor, and as a
result
> > are VERY fast.
> >
> > However, a simple routine to convert the IIgs 320x200 color screen to a
> > DirectX compatible surface consumes almost 90% of the total execution
time
> > in an emulator.
> >
> > You need to keep in mind that the IIgs used a large number of custom
IC's
> to
> > augment the 65816. The IWM, DSP, DAC, etc in essence "offloaded" the
> burden
> > from the 65816, even if they didn't actually act as "processors".
> >
> > All emulators must provide equivalent functionality. The CPU core is the
> > most critical area in terms of compatibility. But speed is driven by all
> the
> > other stuff (mostly video and audio processing)...
> >
> >
> > "Michael J. Mahon" <mjmahon@aol.com> wrote in message
> > 20020901235159.25665.00001002@mb-md.aol.com">news:20020901235159.25665.00001002@mb-md.aol.com...
> > > Bryan Parkoff wrote:
> > >
> > > >    I realize that there are many emulators that can slow Intel CPU.
> It
> > > >takes couple seconds to read 6502 opcode table before it emulates
into
> > 80x86
> > > >opcode.  It can cost a lot of time.
> > > >    For example, MacSoft Emulator can be very slow on Intel PC while
> > > >emulating PowerPC.  What I have read article that the programmer said
> > that
> > > >it is the most difficult to write Emulator on type of processors that
> > > >emulates PowerPC into 80x86.
> > > >    I have decided to use a different method of way that it will NOT
> > EMULATE
> > > >6502 into 80x86.  First, my project reads ROM and/or disk images.
> > Second,
> > > >they convert 6502 routines into 80x86 routines (It is NOT to emulate
> each
> > > >6502 opcode into 80x86 opcode.  Routines are NOT 6502 machine
language
> > NOR
> > > >80x86 machine language.)  Routines are written according to my
design.
> > > >Third, ROM and/or disk images will be executing into NATIVE 80x86.
It
> is
> > > >MUCH faster than emulator/simulator.  Can't you imagine that it can
> > measure
> > > >up to 200MHz on Xeon 550MHz CPU!
> > > >    After rebooting Apple IIs, AppleSoft BASIC prompt appears in the
> > screen.
> > > >You type: "CALL -151", and then you will disassemble that will look
> real
> > > >80x86 instead of 6502 machine language.  Of course, it is difficult
to
> > > >DISPLAY BY TRANSLATING 6502 opcode into 80x86 opcode IN THE SCREEN
ONLY
> > (Not
> > > >CPU's).
> > > >    With disk images, you boot them into memory before they are
> converted
> > to
> > > >80x86 routines automatically for 15-30 seconds (I wish you are
WILLING
> to
> > be
> > > >patient for waiting 30 seconds) such as DOS 3.3 Master.  They will be
> in
> > > >NATIVE 80x86.  No more 6502 anymore!
> > > >    Please do not ask me where do you get the information from.  It
is
> > only
> > > >my project that will exist next couple months.
> > > >
> > > >    Opposite story of Steve Woz: If Steve is RICH that he can AFFORD
a
> > lot
> > > >of money, he can buy Intel 8008 CPU at least $300 instead of 6502 CPU
> at
> > > >$35(?).  Apple II computers will be very popular using 80x86
> instruction.
> > > >It will not be obsolete so all Apple II games will be COMPATIBLE to
> > 80386,
> > > >80486, and beyond Pentium II/III/IV.
> > > >
> > > >    Please provide me some ideas what do you think so I can continue
my
> > > >project.  Thanks a lot...Smile...I am a good C++ programmer, but it
> > always
> > > >progresses and improves project in order to get better.  I do not
> always
> > > >have a good programmer which is written in neither C, Pascal and
> others,
> > but
> > > >I depend on C++ using OOP.  I believe that OOP is better because of
> less
> > > >space and great performance.
> > >
> > > Bryan, while I must admire your enthusiasm, I wonder what you are
> > thinking.
> > >
> > > PC emulators for the various Apple II machines are pretty well
> developed.
> > > And the speed of x86 platforms is such that the problem with emulators
> is
> > > that they are too fast, if anything.  ;-)  There is no practical need
> for
> > a
> > > faster
> > > emulator on the PC platform.
> > >
> > > If you would like to write one to gain experience, I certainly
> understand
> > that.
> > > If you plan to use object code translation as an emulation mechanism,
> the
> > > project will be very challenging and educational.  You will learn that
> all
> > of
> > > the 6502 code must be kept around, since some of it is _data_ and some
> > > programs will simply not work if they cannot reference their 6502 code
> > > stream--and even _change it on the fly_.  These problems can be
detected
> > > and dealt with, but the net effect is that it is much more difficult
> than
> > you
> > > may think to create a fully compatible Apple II emulator based on
object
> > > code translation.  (And, as I mentioned, additional emulation speed is
> > > not actually a very high priority at the present time.)
> > >
> > > When you opened with the statement that "It takes couple seconds to
read
> > > 6502 opcode table before it emulates into 80x86 opcode.  It can cost a
> lot
> > > of time."--I don't know what you are referring to.  The emulators that
I
> > am
> > > aware of simply index into an opcode table or CASE statement table,
and
> > > that operation takes a negligible part of the emulated execution time.
> > >
> > > -michael
> > >
> > > Check out 8-bit Apple sound that will amaze you on my
> > > Home page:  http://members.aol.com/MJMahon/
> >
> >
> >
>
>