real amiga vs winuae

[Roondar]

I hate to say this but winuae IS the ultimate amiga.
It may not be a "real" Amiga, but what is a real Amiga anyway.
It's faster than any amiga out there, it has everything you need to connect anything you might imagine and of course it doesn't "Guru" so often. At least not that often as my old 060 1200.
The beauty of WinUAE is that you can have ANY configuration, in ANY hardware setup in just seconds. In my real 030 Amiga I use WHDLOAD. In UAE I use just... as many configs as I like for each game. I just click the game I want. It loads ultra fast in "turbo mode" floppies and I can also record in .avi all the action. As for Workbench use,  it is in fact easier to set up any workbench in UAE than in real amiga. I have many (so many) different Wb's set up in my UAE that I can always have a "clean" machine to work with. I have made different setup of 3.9 with scala and dpaint (for gfx), a different setup of 3.9 for games, another one for music etc. It is a matter of seconds to load the appropriate one, and it takes so little space on a 1TB HD :-D

All of this is true.

And yet I still love using my A600 (with compactflash-for-IDE) for retrogaming more.
I'll freely admit that this is due to me being a great retro-entoushiast though and that it has nothing to do with anything being 'better' about it (except the 50hz scrolling never working quite right on my PC with it's 60hz+ screenupdates and that only because I'm too lazy to set up the proper resolutions). There is just something about plugging in a real old-school joystick and using an old-school RGB monitor (ok, flat-screen scart-RGB crt TV) that just well, feels nicer to me.

Then again, I like using the ECS/OCS amiga's more than the AGA ones anyway. And I still have a C64c set up for similar purposes (whose retro-communities are, strangely enough, not at all worried that Vice can use Warp-Mode for uber speeds and would probably look at you quite strangely if you said Vice was better than the real thing because it was faster ).

Your milage may vary though

[Roondar]

You see, if you knew even half as much about the design of the original Amiga hardware as you try to impress upon us in threads like this, you'd know that the 68000 was as integral to the design of the system as any of the custom chips.

The entire DMA subsystem was designed around the fact that the 68000 could not access the chip memory more than once every 2 cycles, nor did it have any cache mechanism that would cause problems with dirty data. This allowed the designers to engineer  a system where the custom hardware and CPU could each access the memory in the most direct and efficient way possible. Priority was given to the custom chips when the amount of data access exceeded half the bandwidth but they did have the foresight to make sure that "Fast" memory could be added to allow the CPU to run at full speed when the custom chips start using more than half the available chip memory bandwidth.

So, to suggest that the 68000 was not an integral part of the overall hardware design, is frankly bollocks.

Faster CPU's only work in there thanks to the Fast RAM side of the design. The moment you put even a 68020 into the original design, without Fast RAM, it is crippled. It doesn't fit into the original one access every 2 cycles design. Even with Fast RAM, thanks to the instruction cache, it's also no longer compatible with just "any old" 68000 code. Anything self modifying is doomed to fail spectacularly since the instruction cache is never, ever written to by data writes.

So, by your argument any Amiga that has a 68020+ is not perfectly backwards compatible with the original OCS design and is therefore not a real amiga. The problem just gets worse with every faster 680x0. The 030 even has a data cache. That totally craps on the original DMA system unless you turn it off for the 24-bit DMA region. Which is exactly what they had to do.

With the 040 and especially 060, you even have to start emulating several instructions. Emulation? Surely that's no better than UAE :rolleyes:

In short, all this talk of "doing everything the exact sane way a real amiga does it" is total drivel because most actual physical amigas do things that are completely outside the original 68000/OCS design.

I'd go so far to say that this feature (the way these chips are integrated into the whole) sum up both the brilliance of the design and the root cause of it's eventual failure to keep up.

Commodore was really caught between a rock and a hard place here: either you upgrade the system and lots of old stuff breaks or you keep compatibility but your system performance suffers. Both not really great positions to be in.

[Roondar]

If you rely on those 680x0 specific timing features, then those timings should be exact as well.

If WinUAE is cycle exact for a specific 680x0 chip, then this is from the point of view of the emulated environment exactly what happens.

Now, obviously, if you access stuff outside of the emulated environment that is timing critical this may fail due to a variety of factors.

But, if you use timing critical software on an Amiga that is not the same spec as another Amiga this can (and often will) also fail. There are lots of different Amiga's out there, all subtly (or not so subtly) different. Some hardware for A1200's for instance doesn't work on all models, some expansions for other Amiga's actually require specific motherboard revisions to work reliably, etc.

[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

[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.

[Roondar]

That's your speculation.  You are dealing with the real world as well since audio goes out to the real world, imagery goes out to the real world, joystick/mouse gets inputted from real-world, etc.  Although processor speeds vary amongst amigas, there are also many elements that don't change.  You can't call it an amiga if everything is different from another amiga-- there has to be some substance.  Nor are you correct regarding "cycle is consistently applied."  A cycle unless timed to the cycle may vary the next time the same cycle occurs given processor inconsistencies.  Nor is the cycle taking the same time from cycle to cycle.  Nor can you say for sure you have exact VBI timing given NTSC/PAL rates are usually different from VGA frame rates.

If you don't understand how emulators work internally, why comment about them?

We've explained how it works already. What happens inside the emulator environment runs cycle-exact. If something takes 500 cycles on the Amiga, it will take 500 cycles in the emulator.

Like how I can run Winvice at 10% speed and see how the C64 games I have update the screen. But the software still works. It doesn't crash because the timing is now off by a factor of 10 because it doesn't matter - inside the emulator the 6502 is still executing it's cycles in the same lockstep with the VIC-II it always has, the raster interrupts still occur at the right lines, the serial IO still happens and doesn't lock up.

Even though slowing down a C64 by a factor of ten in real life would make almost any code fail miserably as interrupts would not longer happen at the proper moments.