real amiga vs winuae

[amigaksi]

lol no the pegasos 1 & 2  is a next gen board as was the a1 and sam.
they ran morphos and linux, tho i think aos 4.1 is available for the pegasos 2

Question was whether the Pegasos uses the custom chip set (amiga h/w) or not.

[amigaksi]

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

One that works exactly like the real thing from all perspectives.

[amigaksi]

Bloated capacitors, leaky batteries, dirty drive heads, misbehaving CIAs, regional display formats, broken joystick switches, serial transfers.... *sigh* The joys of real Amigas.

EDIT: Ooh! I forgot rotten floppy disks. Those were the days.

Never had problems with leaky batteries.  A500/A1000 didn't have any batteries on them.  Capacitors, dirty drive heads, etc. isn't restricted to Amigas.  Amiga also has parallel transfers (which I find quite useful for playing with custom devices).  Sorry, my joystick has yet to break and all things eventually break.  Regional display format is also common in video industry; however, I have a PAL and NTSC amiga running in America.  I use floppy simulation so no rotten floppy disks.

[amigaksi]

That's a bit of a pointless criterion to pick.

The 060 doesn't support every instruction that the 000-030 used and has to rely on software emulation for the unimplemented instructions. We know your views on emulation, isn't real, it isn't timing precise, etc. So, does your amiga stop being real the moment you put an 060 card in it?

If there's a REAL Amiga 060 and emulated version is not like it, then it's not as good.  Someone may have exploited the 060 features in his real amiga for his own purposes and if these can't be done on emulated amiga, then it's different.  But in general use (most existing software uses), the core of the Amiga is it's custom chipset (OCS/AGA/ECS) and that involves more than just "looking the same".

[amigaksi]

What!?

His post was biased.  I have had battery leaks in a Thinkpad so that means I am better off with an Amiga 500 w/o a battery?  You have to maintain any PC-- even hard drives have their MTBF.  And you can add new peripherals to Amiga as well as to a PC.  Floppy simulator allows you to use disk images rather than real disks (although I must admit, some of my old disks still work just fine).

[amigaksi]

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

I never tried to impress upon anyone my knowledge of Amiga hardware.  Perhaps, that's what you are trying to do.  I was just asking someone about Pegasos which I never heard of before.  I don't have any 68060 system so I stated my comments with "if".

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

If you did not rely on the timing of the 68000 in your code and just relied on the instructions getting executed and used the CIA, Copper, and other timers for the timing, then it shouldn't matter if it's 68000, 68020, or other backward compatible processor.

>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 as it is capable of a memory access every cycle and is thus forced to wait. 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.

The 68020 is still called backward compatible with 68000 just like Pentium is backward compatible with 8088 although it has similar problems with caching.

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

No, you still write to the same hardware registers on 68020+ and get the same results.

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

I don't think you understood my argument-- if you use 68000 to time your code instead of other generic timers, then that means that emulator should be able to that same timing.  If you write general code that works across all 680x0 processors, then you can't be relying on the timing of the processor.

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

I don't see how that affects the timing.  If you do LOOP instruction in 80x86, it takes more cycles than doing DEC/Branch but earlier processors had it the other way.  

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

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

[amigaksi]

eh? you must have never put an a501 in then.

Actually, I have an ICD expansion in my A500 that has the same silver battery as PC desktops and has yet to leak.  The Thinkpad on the other hand had 3 NiMH batteries in some plastic and that leaked.

[amigaksi]

What amigaski means, is that emulation is bad unless he uses it.... :roll:

Floppy simulator is a peripheral-- people already buy peripherals from various manufacturers.  It performs it's tasks on a cycle by cycle basis where each cycle must finish within the 2 microsecond window.  It works 500kb/s and T=1/f so t = 2 microseconds for every cycle.

[amigaksi]

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.

You violated the law of physics.

[amigaksi]

Somebody needs to read up on Pentium Pro/Pentium II's handling of self-modify code and cache.

Part1

Part2

Your first link states that this book cannot be used.  The point is caching did affect self-modifying code on later than 8088 processors (not just Pentium I/II) but they are still considered backward compatible.

[amigaksi]

Again with confusing cycles and timing (seriously, are you doing this deliberately?).

As has been stated, repeatedly, by multiple folks on here: Timing, especially on the Amiga is an inexact thing. It is different between any two Amigas since the timing comes not from the processor, but by the crystal oscillator. Those Crystal oscillators are far from exact. It gets even worse when you consider that PAL and NTSC Amigas have different timings altogether.

None of which invalidates anything that Karlos has said.

Learn to quote properly.  I made a valid point and it's there in post #202.  I am being consistent with the timing/frequency: T=1/f.

[amigaksi]

If WinUAE has it any shortcomings the fact that its free (at no cost to you) might have something to do with that. Also the fact that they are not allowed to copy Amiga patents and copyrighted code (not sure if they got permission for at least some of it) could be a contributing factor.

     Any argument against WinUAE is pretty petty. Something better to argue about would be: Why was Shapeshifter on Amiga faster than a real Mac? (I think hardware and the price of said hardware was the reason).

It's not petty.  It's not a real amiga just like a fake diamond is different from a real diamond.  Now subjectively, whether it makes some difference to you or not is another matter.  You cannot establish it's a real amiga by trying out a few applications (inductively).

[amigaksi]

You first sunshine.



No, you're mixing cycle precision with timing precision. Timing on an Amiga is not exact due to a whole range of differences within the various Amiga models and revisions, as well as the relative imprecision of the type of crystals used to supply the timings. Ergo, any argument against emulation on the basis of timing is eroneous at best.

They are related.  I can prove it if I write application that actually uses it for timing things.

[amigaksi]

Tell that to the owners of those accellerator cards with those motherboards that didnt work together.

I already answered this idea of timing many times in the other thread and you never replied to it.  The NTSC crystal timing is precisely defined.  As per spec, it's doing what it's supposed to do.

[amigaksi]

The only way to test it would be to have two different amigas run any timing dependant code (such as a basic drum beat, for instance) side by side and check for differences in speed over time. This is demonstrable and even I understand this.

The fact is that the NTSC and PAL specs have a reasonable amount of leaway due to the fact that at the time of their inception, the equipment and componants used were (by todays standards) imprecise. This imprecision can be seen too in the crystals used by the Amiga to produce the clock frequency.

You are deliberately trying to confuse cycle and timing precision, both of which have very specific meanings that have been spelled out to you. Stop it.

Huh.  If I send out a bit through some I/O port using the Copper to time it, it's going to be the same across all amigas because the frequency of operation is the same.  Even if there's some variance 1/100000000 across machines, it's still considered performing per spec.  They are related-- timing and frequency.

[amigaksi]

Cycles are a list of things that happen in a given order. Timing is completely unrelated beyond how fast the cycle happens. Software doesn't give a crap at how fast a cycle happens, so long as it does so without interruption.

Go on, test the hardware timing dependant drumbeat.
...

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

>And btw "per spec" there are tolerances, those tolerances today are considered very imprecise, so much so that building an accelerator card for a given model of A1200 might not work as well on a different revision, or in some cases,...

I already addresses the accelerated processors.  You are not addressing the points I just raised regarding Copper timing being the same.  NTSC crystals are much more accurate than your processor crystals since they are basis for color burst on TVs and other audio-visual broadcast standards.  Here I'll factor it out for you: (13*7*7*5*5*5*5*3*3)/(13*11*7).

>And again, stop trying to confuse timing and cycle precision!

Stop the bullcrap.  I haven't confused anything; you are confused as to what consistent timing exists amongst Amiga models and that timing is based on a fixed frequency as defined here: http://en.wikipedia.org/wiki/Colorburst or you are better off reading it in some standard text books.