Is Amiga Emulation better than the real thing?

[shoggoth]

amigaksi wrote:
As an example, try putting an instruction like $009C,$8010 into the copper list and write an interrupt routine (pointed to by location $68) that does something time critical like writing to joystick ports and there your emulator won't work.  The PC timer goes only as accurate as 1.19318Mhz whereas the copper is timing the color clocks at 3.57954525Mhz.

This is weird, because you don't need hi-res timers to do accurate emulation. Usually it's a matter of accurately interleaving CPU- and hardware emulation, not synchronizing emulation to the host hardware. In theory, nothing prevents perfect emulation of the Amiga hardware today, including copper timing.

[shoggoth]

amigaksi wrote:
Depends on what you are emulating.

No, as long as the individual systems in the device being emulated is cadenced by clock signals, you can emulate it through software.

In theory, nothing prevents perfect emulation of the Amiga hardware today, including copper timing.

Nice joke but you should have corrected yourself by now (if you had read all the posts).  It should read "In theory (software-wise), not even an Atari 800 can be perfect emulated what to speak of Amiga."

Nice insult. The Atari 800 can also be perfectly emulated, just like the Amiga. Just because current solutions doesn't offer what you want, that doesn't mean these things are impossible to emulate.

I just gave a simple example that's not doable although it may seem like it's doing it.  A fake diamond and a real diamond are different in molecular structure/density although they may look the same.  Your emulator cannot be doing timing at 3.579545Mhz if it's timer is only accurate to 1.19318Mhz where reading the tick count itself takes more time than the quantum of the timer.

Funny, because that's not even applicable. You generally don't use timers when emulating stuff this way. To put it simple, tou interleave the code for each subsystem. Granularity is then dictated by the number of cycles spend on each "interleave". No timer. In theory that means you can emulate just about any device cadenced by a clock.

The Atari 800 and the Amiga are cool machines, but there is nothing "magic" about the hardware which makes it impossible to emulate. The 2600 is notoriously difficult to emulate, even though it's a really simple design.

[shoggoth]

amigaksi wrote:
You replied to this after about 1 year.  

Yeah. I remembered having this discussion once before and I was right. And you're just as misinformed now as you were one year ago, aparently.

I never stated anyting "magical"-- just bare bone facts about hardware differences.  You do need timing to emulate things that rely on it.  Atari 800 has 8 POT counters that increment at exact cycle positions on the scanline; it has a fast pot scan that increments every 558 ns.  A Vcount that increments at exactly 2 scanlines (228 CPU cycles) on an exact cycle consistently.  Atari 800 has an IRQ that can cause an interrupt to occur at exact pixel points on the screen without flickering or diverging.  It has a DLI which can also be stabilized w/o requiring WSYNC register.

Nope. You interleave code for each subsystem, and that's what makes it cycle accurate. The internal state of each emulated part is correct in relation to eachother. That's what cycle-accurate means. You don't use timers for that. You're simply misinformed about this.

Perhaps, you want to wait another 5 years or so before you reply so that there's some chance that more people have HPET timers in their machine and OSes are allowing direct access to their hardware.  

Again - this is bull. You don't need high res timers to achieve high res emulation. You seem to think so, but that's not how you do it.

[shoggoth]

@amigaski

I think you confuse "timing" and "timer". Huge difference. You can maintain *timing* for subsystems in relation to eachother without using a *timer*.

Nowadays it's common to synchronize emulation to a "virtual" electron beam. The state of each subsystem is updated every other pixel (depends on the machine itself and how accurately you need to emulate it). For a given number of pixels, you execute the corresponding number of CPU cycles, followed by the corresponding number of cycles for each subsystem.

However: back in the days, we didn't have much CPU horse power, hence people used different tricks to achieve higher speed. AFAIK it was fairly common to use interrupts and dedicated hardware if possible. It wasn't very accurate, but it enabled people to emulate machines at reasonable speed.

A good comparison is the SMS+ emulator vs. older Sega Master System emulators for the Amiga. SMS is scanline accurate and very compatible, it is however much slower compared to e.g.AmiMasterGear which iirc uses the on-board sprite hardware etc for emulation. The latter does not achieve the same level of compatibility, but is definitely useful on lower-spec machines. The former one does not need any high resolution timers or anything of that nature, yet it's superior to the older approach when it comes to emulation accuracy (note however that AmiMasterGear is excellent given the circumstances).


EDIT: I spelled like a monkey. I corrected that somewhat.

[shoggoth]

amigaksi wrote:
>>I never stated anyting "magical"-- just bare bone facts about hardware differences. You do need timing to emulate things that rely on it. Atari 800 has 8 POT counters that increment at exact cycle positions on the scanline; it has a fast pot scan that increments every 558 ns. A Vcount that increments at exactly 2 scanlines (228 CPU cycles) on an exact cycle consistently. Atari 800 has an IRQ that can cause an interrupt to occur at exact pixel points on the screen without flickering or diverging. It has a DLI which can also be stabilized w/o requiring WSYNC register.

To emulate this you synchronize emulation to the electron beam. For each pixel, you let the CPU and other subsystems run the corresponding number of cycles with respect to their own clocks. That enables emulation of advanced mid-scanline hardware effects. This is a well known technique and is used in most emulators.

>Nope. You interleave code for each subsystem, and that's what makes it cycle accurate. The internal state of each emulated part is correct in relation to eachother. That's what cycle-accurate means. You don't use timers for that. You're simply misinformed about this.

Sorry, I live in REALITY not your illusory concepts of cycle-accurate.  You are dealing with FAKE time not REAL time so the real/fake jewelry example applies.

No, that's what cycle accurate means. The state of each subsystem at any given time equals that of a real system given the same number of clock cycles. That's what it means.

Just having some counter for cycles is not same thing as measuring the cycle time. Eventually you have to map the cycles to real time cycles. We don't want to experience your fake cycles.

Ok, you're talking about emulation throttling. Generally you let the system run for one frame, then you use throttling to ensure that emulation speed stays constant.

Real time emulation as you describe it have no impact on the actual accuracy of the emulation with respect to the emulated application. You've got that part wrong.

>Again - this is bull. You don't need high res timers to achieve high res emulation. You seem to think so, but that's not how you do it.

Just read what you wrote-- where's the argument?  All you did was give your opinion.  If I simulate a 10-bit DAC on an OCS Amiga using Volume registers and AUDxDAT, you better get your fake time cycles to correspond to real time cycles else the output will be "bull" as you put it.  That's just one example just to see if you'll insult me or reply logically.

Again I've explained this numerous times. Look at the source code of any modern emulator and you'll see.

About your example. As I've stated earlier, you use code interleaving to achieve synchronisation between the subsystems (in this case the sound hardware and CPU). It's possible to emulate this part perfectly, except for the small delay induced by buffering (which is necessary since computer load varies, both because of the actual emulator and fluctuations caused by other processes).

[shoggoth]

amigaksi wrote:
I am clear on what I stated and am sticking to it.  I already explained that-- you are just calling it "timing", but it has nothing to do with actual cycle time.  But you can write applications (and many already exist) where this cycle time is measuring actual time.

Ok, so what you're claiming is that no matter how accurate an emulator is, you could write an application that can detect that it's not the real deal? :-)

[shoggoth]

amigaksi wrote:
Good so you agee you do need to synchronize emulation to the electron beam.  This translates to having something that can time things at 3.58Mhz or greater.  But you're wrong that it's used in most emulators as there's no way to run the corresponding number of cycles with respect to their own clocks without an accurate timer.  Remember that current processors based on caching, power management, dynamic frequency shifts, etc. can give different cycle counts running the same exact code.

"Cycles" in this case is the number of cycles the hardware in question would have completed given a particular number of pixels. It's not based on timers. And caches etc won't have any impact whatsoever on that value, since it's a relationship between the subsystems in the emulated context. You're confusing the "real" CPU with the emulated dito. The emulated CPU can run perfectly in sync with the emulated hardware regardles of performance fluctuations in the host environment.

It's like this. You know how many cycles a particular subsystem would complete during e.g. 16 pixels. In case of the CPU, let's say it's 4. Another hypothetical device completes 12 cycles during the same time span. You let the emulated CPU run 4 emulated cycles. Then you run the other hypothetical device for 12 cycles. Then you draw 16 pixels. Then you repeat this process. If needed, you can increase the resolution of this approach even further down to 1 cycle, but in many cases this is not necessary since the subsystems in question require a certain number of cycles for each task. If the granularity is right, the behavior and interaction between the subsystems in the emulator will equal that of their hardware counterparts. You've achieved cycle accuracy in the emulated context.

If on an Atari 800, I plot a pixel each time the CRT reaches point A, B, C, etc. on the screen, it resolves to a certain frequency.  That frequency will not be the same if you use FAKE time.

In the emulated context - and that's what we're discussing - it'll have the same frequency as the original. The application cannot detect the difference, nor does the user - given that the emulator runs fast enough.

I think we have different definitions of emulation.

Amigaski - I do get what you're after - but you've got the terms "emulation" and "cycle accuracy" wrong. I go by the common definition, and you clearly have your own one. Check wikipedia, for example. It'll confirm my definition of the word "emulator".

I claim that it's possible to emulate an Amiga or a A800 percectly accurate - and the definition of accurate in this case means A: the software can't tell the difference between an emulated machine and a real one, and B: the user perceives the framerate, response time etc. as a real machine.

I suspect that your definition is a comparison in real time - where the emulated machine won't be perfectly in sync with a "real" one at any given moment. Problem is, this is not even true for two "real" machines, given different hardware revisions, CPUs - it's not even true for two identical machines due to clock drifting.

>>Just read what you wrote-- where's the argument? All you did was give your opinion. If I simulate a 10-bit DAC on an OCS Amiga using Volume registers and AUDxDAT, you better get your fake time cycles to correspond to real time cycles else the output will be "bull" as you put it. That's just one example just to see if you'll insult me or reply logically.

I did answer that, at least I was under the impression that I did. The solution is pretty fundamental and you'll find the same kind of coding techniques in any modern music application. You use buffering - one buffer is calculated while another one is being replayed. This causes a slight sound latency, depending on buffer size. Given that the sound emulation catches register changes at a per sample basis, it'll sound like the original. On top of that you can apply filters etc. to mimic analog filters etc. present on the original sound hardware. Faster systems can have a smaller buffer, and hence less latency, naturally.

But your emulator won't buffer up writes to volume registers done via some IRQ/Copper unless it knows the timing of the IRQ/Copper and that it's audio; it would be bufferring up DAC data going to AUDxDat.

But the emulator will know the timing of the IRQ/Copper and the audio circuitry - in relation to eachother. It doesn't do that by keeping some hardware timer, it does so by keeping track of the cycle count of each subsystem. That cycle count is then synchronized to "real life" by means of throttling, at regular intervals.

[shoggoth]

amigaksi wrote:
One more thing; it's not my definition.  Emulate means to equal or excel in the dictionary.  And this thread is discussing whether emulation is better than the real thing so my definition makes sense.  Cycle accuracy can also mean 1/7.16Mhz (140 ns).

You obviously don't know how to read a dictionary either.

http://dictionary.reference.com/search?q=emulate
http://www.thefreedictionary.com/emulate
http://www.merriam-webster.com/dictionary/emulator
http://encarta.msn.com/dictionary_/emulator.html

In the context of computers, emulation does *not* mean "to equal or excel". You've chosen a definition intended for *behavioral* *science*, and while that might suit your twisted view of things, it's about as wrong as things get. Maybe - just maybe - you should use a definition which can be considered to be the *correct* one from a linguistic point of view.

I think wikipedia makes it quite clear. The following link is about computer emulation: http://en.wikipedia.org/wiki/Emulator

The following link is about behavior science, which is the definition you're using: http://en.wikipedia.org/wiki/Emulation_(observational_learning)

This is getting sillier than I could ever imagine. I don't know why I even bother. Judging by your previous posts, I guess you won't check those links - simply because "you already know better". Please grow up. I mean honestly. Please.

EDIT: Don't blame me for getting of topic. I'm merely trying to correct some *very* inaccurate posts about how emulators work. I find that highly relevant in this context.

[shoggoth]

amigaksi wrote:
His definition of emulation is the ATTEMPT to mimic the machine and for it to be accurate all its cycles (using fake time) of various subsystems are in chronological order in right ratios.  Then the "MAGICAL" WM_TIMER will come and put everything in real-time order and you won't notice the difference from the real machine.

I'm using the same definition as other emulator coders. It's just you who have a definition which happens to deviate from that of common dictionaries and wikipedia (well - and common sense too).

EDIT: I added the word "wikipedia", since I accidentally erased it prior to posting.

He was taking it out of context; I stated that it's impossible to emulate the Atari/Amiga given the standard PC hardware like 1.19Mhz timer, 2-channel audio card, zero sprites, etc.  Taking your example, traveling from A to B at 256X the speed of light IS impossible using today's rocket.  

You don't need sprites to emulate sprites accurately. You don't need for channel audio to emulate four channel audio. You don't need a timer to emulate something with an accuracy of one cycle.

You would know that if you actually checked how emulators are written today - something you've refused to do - probably because it would fundamentally contradict your earlier statements.

[shoggoth]

amigaksi wrote:
"to try to equal of surpass; imitate so as to excel: to emulate the success of great writers." - Page 258, Dictionary by Harcourt Brace Jovanovich, Inc.

"verb, -lat⋅ed, -lat⋅ing, adjective
–verb (used with object)
1.   to try to equal or excel; imitate with effort to equal or surpass: to emulate one's father as a concert violinist.
2.   to rival with some degree of success: Some smaller cities now emulate the major capitals in their cultural offerings.
3.   Computers.
a.   to imitate (a particular computer system) by using a software system, often including a microprogram or another computer that enables it to do the same work, run the same programs, etc., as the first.
b.   to replace (software) with hardware to perform the same task."

Hmm.... I wonder which definition that applies to this discussion.

Most up-to-date dictionares share this definition. This one is from http://dictionary.reference.com/search?q=emulate.

It doesn't say it's behavioral science in the dictionary.  Regardless, isn't the defintion I quoted what people assume when they hear "PC can emulate the Amiga in a cycle-exact manner."

You'd have to be a complete moron not to understand that it does, especcially when there is an additional definition for the word when used in the context of *computers*.

To clarify this I added the two definitions from wikipedia, something which you convieniently ignored completely:

http://en.wikipedia.org/wiki/Emulator

vs.

http://en.wikipedia.org/wiki/Emulation_(observational_learning)

I don't know which posts you are referring to.  All my posts are accurate given the definition above.  If I take your definition, then it gets silly-- Atari 800 can emulate a Pentium IV, Quad core given enough time.

That's taken out of context. In theory the statement is true, given enough time and memory - that was the point of it. In practice it's completely retarded. Just like some posters in this forum.

[shoggoth]

amigaksi wrote:
>You would know that if you actually checked how emulators are written today - something you've refused to do - probably because it would fundamentally contradict your earlier statements.

You are being vague.  I have stuck to my position for many years now although in the process HPET got introduced and Vista came out.
[/quote]

No. I entered this discussion because:
A: You make claims about how emulators work.
B: Those claims are completely wrong.

Given that, the statement is highly relevant. You've stuck to your position for many years because you refuse to take facts into the equation.

I've got a question for you, Amigaski:
A: You know how emulators work internally, and therefore your statements about emulators are true.
B: You don't know how emulators work internally, but you do know for a fact that your statements are true anyway.

Which one is it, Amigaski? A or B?

[shoggoth]

ChaosLord wrote:
I have, and so have some of my friends.  None of them use double-buffering.  AFAICT double-buffering is only really useful when displaying an FMV movie.  It is often a mistake to double-buffer a whole game on the Amiga.  The Amiga has real-time beam position knowledge with approximately 1/21000000th second resolution (if you want the exact number then consult your HRM).

ChaosLord - you're probably thinking of 2d games. Generally 3D games are double-buffered.

[shoggoth]

amigaksi wrote:
>by shoggoth on 2009/1/27 6:39:12

>>You are being vague. I have stuck to my position for many years now although in the process HPET got introduced and Vista came out.

>No. I entered this discussion because:
>A: You make claims about how emulators work.
>B: Those claims are completely wrong.

You haven't shown any of my claims to be wrong.  You just have a different definition of cycle-accuracy and emulation.  All of my statements are proven.

>I've got a question for you, Amigaski:
>A: You know how emulators work internally, and therefore your statements about emulators are true.
>B: You don't know how emulators work internally, but you do know for a fact that your statements are true anyway.

>Which one is it, Amigaski? A or B?

I already answered this.  It's C-- I know how the PC works and Amiga works so I know whether some Amiga function can be emulated on the PC.  It's called deductive logic-- not straw man argument or insult like you use.  Here's a simpler example, I know for a fact that Gameport joystick on PC takes 1 ms to read using port 201h (directly read port).  I know Amiga joystick read takes, a few microseconds.  Thus, you cannot emulate an Amiga joystick on PC using PC joystick.  It'll never EQUAL OR EXCEL it.

Same claims I made using timers with 1.19Mhz timer vs. 7.16Mhz cycle accuracy and other claims.

Sorry for the long quote.

Amigaski, you're twisting the truth. You invent your own definitions - none of which are in line with that of the rest of the world. You deliberately use definitions intended for completely different contexts. You simply do whatever to support your claims rather than accepting the fact that you're wrong. This is especially retarded considering that we're discussing an area of which you yourself admit that you have no real knowledge. You're simply amazing on your own very special way.