>by shoggoth on 2009/1/23 9:37:31
>>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 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...
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.
I agree in the "emulated context" (fake time) you have (basically everything was done in order). The only problem you would have in the emulated context is if the cycles become fractional for a subsystem. However, this is not cycle accuracy if the time elapsed makes a difference like in the audio example I gave or even in the VHPOSR if timing adds up to a critical value.
>>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.
The application cannot detect the difference but user can if the elapsed time for the cycle makes a difference. You are synching up during refresh but humans can detect much higher frequencies than 60Hz especially for audio and even the 60Hz has latency and may be phase shifted and not exactly 60Hz (which it is not in NTSC).
>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.
This is where we differ; user may get close to the real framerate (depends on hardware support), but response time will always have the minimum of 1/60 latency. And other things will also have latency or be perceived to be different depending on hardware support.
>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.
Sorry, but if you do Copper-based, IRQ-based, Audio Intr-based, etc. operations on any Amiga (OCS, ECS, AGA), you are in-sync on a per cycle basis. Yes, the CPU varies in speed, but your emulation is not just a CPU speed enhancer. No clock drifting in Copper, IRQs, Audio Interrupts, and other things based on their hardware spec.
>...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.
Latency is always there unless you are doing cycle by cycle emulation in real-time AND your hardware supports similar audio registers to that on the Amiga. Another problems is that you don't know what the user may modify dynamically so you don't know which registers to buffer up.
>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.
If it does not buffer it up, it needs an accurate timer. If it can guess to buffer up, it has latency.
