A.D.A. Amiga Demoscene Archive

Hi.

I know some of you have looked at the UAE sources, so maybe you could clear this up for me. I'm trying to figure out if it'd be realistic for someone with a lot of time on his hands (not me, probably) to add a speed limiter to the 68k emulation in UAE. The idea would be to get it reasonably close to 060/50 MHz speed by, say, counting cycles every time an instruction is emulated and then periodically pausing the emulation to slow it down accordingly.

What do you think?

I've spoken to the UAE coder about it long time ago but as he only seems to be interested in adding features that he finds useful, he wasn't interested. Well, he is not even interested to fix some obvious bugs, his answer was "fix it yourself". Well, no further comment needed. So, I'd like to have such option too, would make life a lof easier. =)

It would be extremely difficult to get anywhere near realistic 060 speed. Firtly, to get accurate cpu speed, you would have to keep track of pipeline effects, integer/fpu parallellism, caches, branch prediction and so on. That being difficult in itself, it will be near impossible to combine with JIT emulation. Hence, you will be emulating in interpreted mode, and I doubt even a modern PC is able to keep up with the speed of a 060 doing that.

Secondly, the major speed-limiting factor in modern demos is often not the cpu, but rather the chipram. You would have to emulate the chipram latency, write buffer and things like that to get realistic speeds here.

There are software that does this kind of cycle-exact emulation of systems of this complexity, but they take many man-years to develop and run nowhere near realtime.

So, dream on, and get used to having to test your things on a real Amiga to check the speed (or accept that it runs dead slow on the real thing... ;)

That said, it would be nice with some kind of speed-limiting option for the cpu. Just to stop those non-timed things from rotating so infuriatingly fast. :)

I wouldn't want cycle-exact emulation, just to get it somewhere in the area of 060 speed. Surely you could count the number of clock cycles emulated, and take simple pipelining into account when doing that. How could that make up more than an extra 10 or so instructions per translated 68k instruction? Even with chipmem writes and cache it should be possible to get "close" to a real number of cycles.

And then once every millisecond you just pause the emulation to let a timer catch up with the JIT translated code. Why is it not easy, I don't get it! Cycle-exact emulation isn't the point, I just want speed-limited emulation. The closer to real 68k timing the better of course, but even being able to limit the emulation to a fixed number of instructions per second would be a big improvement. At least then you could get some idea of how fast your code is.

Yeah, you could do that. You are probably right that it shouldn't be too difficult. I guess you could get reliable speed within a factor of about 4 using this method. So it would give you some idea of the order of magnitude of the speed of your code, but it would still be useless in testing optimizations.

Regarding implementation, the existing wait code used to implement the CPU Idle setting could probably be reused to do this waiting. I don't know for sure, though, I haven't looked at that part of the code.

I haven't looked at any part of the code, so I have no clue at all. ;)

But it'd be "somewhat" useful anyway, which is the general idea. UAE itself wasn't always useful at all, but you have to start somewhere. So please, somebody start somewhere. I'll reward serious efforts with serious booze at BP08. :)

BTW I do think UAE can match 060 speed without JIT these days. I base that assumption on my 1 GHz P3 laptop coming reasonably close to half speed.