Re: Most Difficult Emulator

["Bryan Parkoff" <BParkoff@satx.rr.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/
>
>
>