real amiga vs winuae

[Speelgoedmannetje]

:lol:

Heh, now I'm saying "baby jesus" with that voice all day long. :lol:

[Roondar]

You violated the law of physics.

Sigh.

Emulators can run ten times slower than the real thing. Yet, in the emulator environment (or so to speak 'from the emulator's point of view') it's in fact the real world that is fast and the emulator is fine. After all, if a ten-times-slower-but-cycle-accurate emulator runs code that on the real thing takes exactly 503 cycles it will, on the emulator, also take exactly 503 cycles. Albeit ten times slower cycles.

Likewise, in the emulated Amiga world the copper can be used to read out the joystick port at the same resolution it can be on a real amiga.

However, (and this is where you probably got confused and felt I was telling something that was impossible), this is only true inside the emulated environment. Obviously, since an emulator can't beat the rules of physics, doing IO outside of the emulator environment can lead to timing mismatches. Such as a PC joystick not actually being read out at 1Khz. The emulated environment still does it at 1Khz internally, but it won't get input at that rate from the 'outside world'.

It's a good thing though, because this feature (i.e. the emulator not needing to run at 100% exactly the same speed as the real thing) is in fact one of the many reasons they work at all. If an emulator needed to be cycle-accurate and speed-accurate in 100% of the cases they'd never ever work properly.

For an alternate way to think about it, just look at WinVice - its actual execution speed of C64 code varies a few percent even with speed lock active. If the emulated environment would notice this slowdown and speedup stuff like timing critical raster splits, fastloaders and other hardware-timing dependent stuff would break. Yet, because the world inside the emulator works just like the real thing and it is only the presentation to the outside world that is not 100% accurate there is no problem: the code working (and displaying the proper effect) without crashing is proof enough that the emulator is cycle accurate.

So no, I did not break the laws of physics. I merely managed to look at this from both points of view: from the emulator and from the 'real world'.

[Roondar]

This I can agree with. I have several hardware amigas, one of which cannot currently be emulated by UAE due to having a PPC board.

However, for everyday work, UAE is great. It actually makes the m68k based amiga a viable platform.

Yup, UAE is a good thing.

If only to keep the Amiga* with us for the inevitable day when all the original hardware is dead.

*) Dependent on definition of Amiga. Your milage may vary

[Hammer]

My point was some processors did have that extra compatibility features like clock adjustments, but even without that they are still considered backward compatible.  If you want to state the "fuzziness" is 68000 instruction execution, then give example(s).

As an example, 68060 and 68040’s software instructions emulation. Then you have ColdFire.

In terms legacy investment while moving forward, nothing beats X86.

[Hammer]

I know some processors also had turbo/normal mode to even have compatibility with tasks that used the processor speed to time things.  However, as it stands the 680x0 series and x86 series are considered backward compatible even with different processor speeds and some differences in pipelined/cached instruction execution.

I was referring to self-modifying code and how the modern X86 CPU handles it i.e. X86 world added additional hardware. Motorola is !@#$%^&-all on legacy.

[scuzzb494]

Emulation is not the same as using real amiga.  I'll leave it at that for now...

Here here !!

scuzz
http://www.commodore-amiga-retro.com

[Trev]

You're dead wrong that software doesn't care how fast a cycle happens.  You are generalizing too much.

No, he's not. Time isn't an absolute, and your software's concept of time is relative to its frame of reference.

[Karlos]

No, he's not. Time isn't an absolute, and your software's concept of time is relative to its frame of reference.

True. Generally speaking, only hardware cares how long cycles take. If you don't refresh your DRAM at the right speed it can corrupt it's contents, for example. However, software isn't going to care if it takes 10ns to access memory or 100ns.

[Trev]

True. Generally speaking, only hardware cares how long cycles take. If you don't refresh your DRAM at the right speed it can corrupt it's contents, for example. However, software isn't going to care if it takes 10ns to access memory or 100ns.

Exactly, as long as some artribitrary unit, e.g. a cycle, is consistently applied, the actual value of a cycle isn't relevant. Then we get into the real world, of course, where systems are expected to interact with each other. ;-) We can rest assured, however, that an Amiga with zero 0 acceleration and an Amiga with an acceleration approaching the speed light are both Amigas, even though one appears to be running at a different speed from the perspective of the other.

EDIT: That, and any Turing-complete system can emulate an Amiga (or any other system).

[stefcep2]

Obviously, since an emulator can't beat the rules of physics, doing IO outside of the emulator environment can lead to timing mismatches. Such as a PC joystick not actually being read out at 1Khz. The emulated environment still does it at 1Khz internally, but it won't get input at that rate from the 'outside world'.

So no, I did not break the laws of physics. I merely managed to look at this from both points of view: from the emulator and from the 'real world'.

Very relativistic.  We could I suppose apply the Lorentz transformations so as to relate the time that passes per clock cycle in the real world to the time that passes per clock cycle in the emulator world.  Obviously some sort of time dilation would be happening, although space itself would not contract.

[ElPolloDiabl]

Very relativistic.  We could I suppose apply the Lorentz transformations so as to relate the time that passes per clock cycle in the real world to the time that passes per clock cycle in the emulator world.  Obviously some sort of time dilation would be happening, although space itself would not contract.

What if a wormhole opens between the UAE binary and the CPU, how would that affect it?

[stefcep2]

What if a wormhole opens between the UAE binary and the CPU, how would that affect it?

you could for example find that you've completed a render in Lightwave before you even started, but at the cost of system stability, as wormholes AFAIK are themselves highly unstable.  But then it only takes 5 seconds in our time frame to reboot -but infinite in the time frame of the emulator, as time itself cease to exist for the emulator at the point when the emulated workbench guru's

[Roondar]

What if a wormhole opens between the UAE binary and the CPU, how would that affect it?

If you open a stable wormhole using the UAE binary and the CPU, I suggest you call Ben Sisko, ASAP.

[Roondar]

EDIT: That, and any Turing-complete system can emulate an Amiga (or any other system).

While true we have to be fair, this is sometimes very hard to do at anything approaching a usuable speed. Amiga emulation took a long while to work properly because of the way the system is integrated.

Likewise, a PS2 emulator is very hard to write if it has to be cycle exact - because the bus between GFX ram and the 'GPU' is very much of the beaten path (i.e. it had insane bandwidth for its time and a reaaaaally big bus).

Now, if you don't mind about speed then yes, any system can emulate any other. Even though I will admit that writing a Quad-Core/Nvidia 'expensivo'/4GB/160GB emulator for my C64 would be needing quite a lot of 170KB floppies and be a 'tad' slow.

[amigaksi]

As an example, 68060 and 68040’s software instructions emulation. Then you have ColdFire.

In terms legacy investment while moving forward, nothing beats X86.

I was saying both x86 and 680x0 are considered backward compatible.  I have been able to run all 68000 software on AGA machines except those that rely on processor frequency being fixed at 7.16Mhz.  If the frequency/timing does not matter to application (application does not use it internally as a factor), then as long as 68060 can execute the instructions in equal or better time, it's fine however it executes those instructions.  Emulate = "equal or excel" here.

[amigaksi]

No, he's not. Time isn't an absolute, and your software's concept of time is relative to its frame of reference.

That bullcrap.  If your software uses the ticks to measure REAL-time, it matters how long a cycle takes.  For example, if I do, MOVE.W VHPOSR,D0 and use that to do short delays in the software for audio effects, the time matters.  Obviously, if I start doing time critical port I/O, it gets worse.