6502.org

> They cannot simply run a program for the end user like emulators can.

That I agree with, if only from a gut feeling. So yes, to me visual6502 seems to be a simulator, although it arguably may be more accurate and complete in its execution of 6502 instructions than just about any 6502 emulator out there.

> Emulators need to be able to run at the speed and provide the same interface as the replaced machine. Everything else is a simulator. It is not an emulator just because it can run binaries!

But that I don't fully agree with - accurate speed should not define if something is an emulator, unless the goal of the particular emulator is to emulate something running at a particular speed. In my opinion it's perfectly fine to define the goal of an emulator as e.g. 'emulate an xxx type of computer executing at about 9MHz'. Even if there never was an actual xxx running a that specific speed. It's still an emulator (IMO), and that's why there are different sub-variants of emulators. People call some of them 'cycle-exact emulators', for example, implying that there are (acceptable) emulators that are not.

-Tor

No, I disagree.

To 'emulate' is to reproduce the function of something but the reproduction does not have to be 100%. You only have to emulate enough of the function for the result to suit your requirements. As my requirements may not be the same as yours the distinction is subjective.

O.K., the "able to run at the speed of the replaced machine" argument is weak, because you could specify an emulator to replace a 6502 with any clock speed and cycle accuracy. What I meant was, that this may not be a criteria for a simulator as it does not have to be real time if you are not interested in real time behavior. On an emulator you are definitely interested in real time behavior.

An emulator does not have to be 100% accurate? True. Unfortunately that does not mean a 100% accurate emulator is automatically a simulator. However, if I simulate a program in my IDE I expect it to be 100% accurate even if you call it an emulator.

As it was brought up as an example: A flight simulator is a simulator because you don't actually fly. Put the instrumentation of an Airbus into a Boeing cockpit so an Airbus trained pilot can fly it, it is an Airbus emulator. The instrumentation is the same for both the simulator and the emulator. The usage makes the difference. And the emulator should better be 100% accurate...

see also: http://stackoverflow.com/questions/1584 ... difference

"My machine can behave like a completely different machine!" == the act of emulation.

This is generally accomplished by software simulating what goes on in the other machine to whatever detail necessary to correctly perform the desired emulation.

Simulation vs emulation is a false dichotomy.

That's ignoring the problem.  There has to be a way to specify that it can connect to modules or other hardware that may be specific to the particular machine, with certain connectors, voltages, set-up times, hold times, etc..  This is well beyond the scope of software.  Taking away the word "emulator" to use for software-only products takes away the only word we had left to specify this kind of thing.  "In-circuit emulator" is only one type of hardware emulator (the kind that plugs into a socket in your board), and does not cover all types of hardware emulators.

New lingo isn't automatically correct lingo. Also, anything coming from Wikipedia is automatically suspect.

I'm not taking away the word "emulator". Plus, I was responding to the thread as a whole, not the most recent posts.

I'm saying that "emulation" is the behavioral act of one machine acting like another. It has nothing to do with the precision or simulation technique involved. Whatever's required to get that behavior to happen is typically called an "emulator". If replication of the experience requires the ability to interface with external hardware, then that's part of the included "emulated" situation.

"Simulation" has a few meanings. One is that instead of just acting like a different machine (emulation), it simulates an human-modeled or human-experienced environment that would typically happen without a machine, like a flight simulator. Another is non-interactive emulation; it behaves like something else, not for the purposes of presenting its outermost behavior to reality, but for discovering & researching internal or system properties and states, often ignoring wall-clock time but tracking modeled time.

But again, a simulator can have varying degrees of accuracy and detail depending on the needs. I don't believe it's sensible to say "emulation is less accurate than simulation" or the converse. It doesn't make sense, especially since emulation software performs simulation. Emulation and simulation are talking about purposes for replicating behavior, not how detailed/accurately the behavior is replicated.

When what's discussed is mocking up a machine interface to another system, I think both terms are equally applicable.

I haven't read all the arguments here but when I first encountered ICE it was referred to as "Hardware Emulation". Nowadays, of course, people rarely use these devices as they have (software) emulation.

You mention ICE to a youngster today and they'll think you mean In Car Entertainment!

I don't think there's an end to this - those with strong opinions are not likely to change them. My point in starting the thread was to draw away all the sidetracks on this subject which appear in other threads from time to time. We can do without those if we have a central place to talk.

FWIW, the first couple of answers at
http://stackoverflow.com/questions/1584 ... difference
seem quite good to me. (Also at
http://stackoverflow.com/questions/2174 ... simulation
)

Not sure if this was covered in the preceding arguments (did not read them all).

It has always been my understanding that in general terms, as simulation has varying degrees of the look and feel of what is being simulated. Some are more accurate and more complete than others. While emulation must actually do what the thing being emulated does. Take an example outside of computers/CPUs. Flight.

A flight simulation of a Spitfire must only respond like a Spitfire and need not even take input as a real Spitfire or actually have a real physical response. Like a software flight simulator as an example. The software flight simulator does not actually fly, or bank when you actuate the simulated ailerons, but it can show you a picture of the simulated horizon banking and tell you the calculated bank angle and roll rate.

However, a Spitfire emulator must actually fly like a Spitfire. You must be able to get in it, start it up, taxi it down the runway, etc...

The difference gets a little fuzzier when it comes to emulating or simulating a CPU, but if you ask me, something like Kowalski's 6502 emulator is actually a simulator. But it's really just semantics. As long as it does what you need it to do you can call it whatever you like.

This discussion has removed all doubt from my mind. In future, the term I will use is "semulator" !!

Works for me.

Possibly interesting historical note: when IBM decided to build the 360 series circa 1964 it was important to protect customers' investment in software for previous machines. - p.149 of A History of Modern Computing, Paul Ceruzzi, 1998

The idea was to be able to run existing binaries, and it seems the emulation could be at microcode level (needs a reboot) or by software in the modern way. Programs written for the 1401 were apparently still running thirty or forty years later. The 360 series was intended to be a long-lived architecture with binary compatibility covering a 25:1 performance range - which held true up to 200:1 in 1970 and for several decades beyond. Part of the trick was to make microcoded CPUs, such that the microarchitecture need not map too closely to the instruction set architecture.

Right. Because nobody on this forum is living in the past! :-P