[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Most Difficult Emulator
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/