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.
