Cycle Exact clarification

[Karlos]

Can someone clarify what the "A500/A1200 or cycle exact" mode means when using a 68EC020 or higher CPU emulation in UAE? I know what I think it means but I'm sure I'm not correct.

[alexh]

AFAIK it refers to chipset timing not CPU timing.

68EC020 CPU emulation (and it's caches etc) are I don't believe are cycle accurate but only Toni will know for sure.

[abu_the_monkey]

this is what Toni wrote a couple of years ago in another thread.

http://eab.abime.net/showpost.php?p=...2&postcount=10

things may be different now, I don't know.

[TCD]

Originally Posted by abu_the_monkey

things may be different now, I don't know.

Still true it seems: http://eab.abime.net/showthread.php?...39#post1606939

[Toni Wilen]

I don't think the question was about CE or not CE but CPU panel radio button option. It is basically "fastest possible" or not fastest possible selection.

Not fastest possible (approximate) then can be modified by enabling CE option(s).

Chipset itself is always cycle-accurate (minus blitter) in approximate modes.

[Karlos]

Originally Posted by Toni Wilen

I don't think the question was about CE or not CE but CPU panel radio button option. It is basically "fastest possible" or not fastest possible selection.

Not fastest possible (approximate) then can be modified by enabling CE option(s).

Chipset itself is always cycle-accurate (minus blitter) in approximate modes.

What I'm interested to know, at a macroscopic scale is what is the approximate CPU performance when choosing the latter option. There's a slider to adjust the CPU speed but what's it relative to when the selected CPU is 020 or higher?

[Snoopy1234]

Originally Posted by Karlos

What I'm interested to know, at a macroscopic scale is what is the approximate CPU performance when choosing the latter option. There's a slider to adjust the CPU speed but what's it relative to when the selected CPU is 020 or higher?

Run SYSInfo for comparable figures of Utopian Elegance.

[Waccoon]

I've found SysInfo to be pretty unreliable for benchmarking. Just for fun, I've been playing around with different '020 cache configurations and implemented a unified 512 byte I/D cache for the 68000. SysInfo shows much greater improvements than you'd notice in real-world applications. AIBB is generally better if you know how to read the results.

Overall, for gaming the '020 emulation is pretty close to real hardware, to within 10%. However, integer math is much faster than on real hardware. No matter how much you play with the performance sliders, some instructions will always be wildly faster or slower than others. The official '020 documentation isn't actually that helpful for estimating cycle times, so it's unlikely this will be improved anytime soon.

Also note that WinUAE does not emulate wait states for fast RAM, so if you have a configuration with fast RAM, it will always run faster than real hardware (by about 30%). Most games and demos that need cycle-exact behavior don't utilize fast RAM, so there's no point in worrying about it. 8)

[Karlos]

I understand why cycle exact is a problem for 020+ since you would end up needing a circuit simulator more than an emulator.

One thing that would be useful perhaps is a "cycle pessimism" mode, where every instruction takes the longest possible number of cycle and doesn't take into consideration execution overlap or pipelining. As to why I suggest this, it's so that you can write code always testing the hypothetical worst case, knowing it should almost always be better on actual hardware. The corollary would be a "cycle optimism" that uses the least number of cycles assuming a happy path always. Then you have lower ans upper bounds of predicted performance to work within.

[Zarnal]

Originally Posted by Waccoon

Also note that WinUAE does not emulate wait states for fast RAM, so if you have a configuration with fast RAM, it will always run faster than real hardware (by about 30%). Most games and demos that need cycle-exact behavior don't utilize fast RAM, so there's no point in worrying about it. 8)

Is there a particular reason for this? Too complicated ? Or would it require too many changes for little improvement ?

[Toni Wilen]

WinUAE does not emulate wait states for fast RAM

Assuming this means plain A1200 with fast RAM? I don't have any plain fast RAM expansions. Also I assume speed of board can depend on board design (how refresh is done etc)?

"cycle pessimism"

Can't do without separate CPU "core" which is not worth the trouble and complexity and side-increase.

[Waccoon]

Originally Posted by Zarnal

Is there a particular reason for this? Too complicated ? Or would it require too many changes for little improvement ?

Yeah, it requires a bunch of new memory calls which aren't really worth the complexity, and anyone who uses large memory configurations is probably only interested in JIT, anyway.

Memory timing is only really important for the custom chips, and all Amigas have pretty much the same memory timing at least as far as the CPU is concerned, so it's all standardized. When it comes to fast RAM, you're effectively talking about 3rd-party memory boards, and there's just too many variables to consider and you'll always just be "in the ballpark" rather than have exact performance.

I've been looking into cycle-exact burst mode support for the 68030 for a while, and concluded that there's really no point (it only works with fast RAM).