[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emulator Project Question
Bryan Parkoff wrote:
Read below with my comments.
I am curious why C++ is written to read 6502 opcode before C++
function
has to be built in order to translate 6502 opcode into 80x86 opcode. I
believe that function is not needed however we must match each opcode
code.
I'm confused. Are you referring to a generic C++ or some specific
program? A C++ compiler running under an emulator should still produce
6502 code. A cross compiler for C++ would produce native code for the
processor in use.
==> Very good that you guess because it is not easy to explain with
technical words. C++ compiler can only be done native through 80x86
microprocessor, but 6502 instructions can be written to form emulation that
is manipulated by 80x86 microprocessor. It is possible that C compiler and
other language compiler can be done by 6502 instructions through 80x86
microprocessor that can be very slow. It is not necessary to discuss this
paragraph above.
I'm still not completely clear. I want to understand it in my own mind
before I get into specifics. (It has been a really strange week for me.)
If I have the situation correct, you have an Apple// program you want to
port over to a PC? The language you are using to make the translation is
a C++ on the PC?
If, as the subject suggests, this is to be run under an emulator the
internal workings of the emulator should be understood. Does the
emulator completely emulate the 6502 or does it translate instructions?
I haven't seen the program you are talking about. In fact you never
mentioned its name. Therefore I will try to keep the answers general.
==> It is true that 6502 instructions are written through emulation in C++
can be very slow, but emulation can be running much faster unless each 6502
instruction is able to translate into 80x86 instruction.
Assuming you are the author of the translation program, the speed depends
on what you would consider to be acceptable. If you do a simple
translation you would end up with terrible, but working, code. From
there, if you wanted you could create another program to analyse the
80x86 code and optimise it. The translation from an 8 bit machine to at
least a 16 bit machine might result in tighter code if done manually.
Automatically it might need further optimisation.
<SNIP>
Well, yes and no. On the microprocessor level there have to be analogues
of certain types of instructions. These are the minimum instruction set
for things to work. You need to be able to bring things in and send
things out of the processor to the RAM. You need to be able to set
various status flags. Addition and subtraction are necessary. The
program needs to know where in the RAM the next instruction is (and to
jump to a new location if necessary). For the most part these seem to
work the same on most processors.
==> It is what I want to replace 6502 instructions to 80x86 instructions
that will make emulation run much faster. It is too easy to say --
impossible, but there are thousand ways to do. For example, text screen
from $400 through $7FF must be stored in emulated space somewhere as RAM.
It is not what I want. I can cause text screen to be stored in a different
memory location in 80x86.
Replacing one instruction with a number of others isn't impossible. ROM
routines and screen locations are going to be tough (as you suggested).
In fact, for graphics it might be possible to tighten the code because
you'd be dealing with bytes per pixel instead of bits per pixel. If your
program is to be a generic translation program (a program to translate
any Apple// program to a PC program), you'd have to take into account
the style of programming. Again with the HI-RES graphics, it isn't
enough to know where the graphics screen is. Direct manipulation of the
screen is only one way to plot a pixel. A lookup table could be used to
determine where and how to plot a point. There are also ROM routines to
be considered. A simple translator would simply translate and emulate
the style. If you were to try to optimise it, you might have to work out
a way to recognise what the programmer was trying to do, then do it better.
For example -- LDA #C1 + STA $500. It loads 'A' and store it in memory
location $500. All are located into emulated memory location that can be
slow.
I can cause 80x86 instruction to load 'A' and store it into 80x86 memory
location -- $007D:0100. Written C++ is programmed to read $007D-0100 then
calls some functions to load the screen resolution that will appear in the
screen. It will look like emulated 6502 memory location -- $500. Does it
make sense?
As I understand it, this is pretty much what other emulators do. The
program executes an instruction. Returns from the emulation. Looks at
the screen memory in use. Then it outputs the screen and returns to the
emulation.
On a specific processor the analogues may be direct such as the various
jump instructions. Others might need to have a few lines of code in
order to emulate the specific function. The Jump is easy. Change the
program counter.
==> It is my goal to translate 6502 instructions / opcodes into 80x86
instructions / opcodes without using functions nor emulation BEFORE written
C++ is programmed to point 80x86 memory location before emulation can be
executed. It is how speed and preformance can increase! Please state your
opinion what you think!
You've lost me again... If you want to emulate the instructions
(intrepret them and execute them immediately) then you will need to have
a function of some sort for some of them. If you are doing a translation
(taking the 6502 code without executing it and changing it into the
80x86 equivalent) you'd be better off storing the result as a separate
program to be executed later.
The horsepower of the newer machines will more than make up for any speed
problems resulting from emulation.
==> Please advise that I am not a very good English writer, but my computer
programming is very good for me.
Most people who speak English as a primary language aren't very good at
it either. Don't worry. If we don't understand something we'll ask
questions.
Bryan Parkoff
BParkoff@satx.rr.com
Later
Mike
--
+----------------------------------------------------------------------+
| Digital Civilization magazine: http://www.digitalcivilization.ca |
| http://members.shaw.ca/pfaiffer = Mike Pfaiffer (B.A., B.Sc.) |
| See my web page before you think about spamming me. I charge cash. |
+----------------------------------------------------------------------+
----- BEGIN GEEK CODE BLOCK -----
Version: 3.12
GCS/G/IT/PA/SS d s+:- a? C++ UL L++ W++ N++ o+ K- w(---) O+@ M++@ V PS+
PE !PGP t+ 5+ X R tv b+ DI+++ D++ G e++* h! r-- !y-- UF++
------ END GEEK CODE BLOCK ------