real amiga vs winuae

[Karlos]

Even if there's some variance 1/100000000 across machines, it's still considered performing per spec.  They are related-- timing and frequency.

The variance is significantly more than that. The crystals used in the old miggies had tolerances in the tens of ppm.

[Karlos]

WinUAE is good, but not the same.  I keep a real amiga for the same reason I keep a real SNES and a real N64: because they "feel right".

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.

[Karlos]

Did you ever try Amithlon at all, if so, how did that compare to the real deal?

No, I can't say I've had the pleasure. From what I gather, it is very fast.

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

[Karlos]

I have been able to run all 68000 software on AGA machines except those that rely on processor frequency being fixed at 7.16Mhz.

That's bullcrap. I can write a piece of code for 68000 that will fail totally on 68020+, completely regardless of the processor frequency.

Writing to memory one before the last instruction executed, replacing the existing opcode with another legal one, then branching back to it is all it takes.

[Karlos]

I am speaking from my software base.  It all works fine.

So, because your software base works, all 680x0 are to be considered backwards compatible? :roflmao:

I'm starting to see the problem with your experiments here. Anything that you observe is considered the only possible outcome for any experiment.

[Karlos]

I was giving example.  And if you read Motorola specs, they are considered backward compatible.  I already mentioned there are some differences in this thread if you cared to read/recall.

No. I have every Motorola 680x0 manual right here. Motorola make it perfectly clear that the 68020 is not backwards compatible with the 68000 where the 68000 object code violates the 68020 cache or performs any operation considered privileged on the 68020 that was not considered privileged on the 68000.

Motorola make it absolutely clear that such code will not work without modification, either to the code itself or to the environment it is running in.

Backwards compatibility on the 680x0 is generally maintained in software, not in hardware. Motorola make this completely clear and provide reference implementations of the software required to maintain compatibility.

[Karlos]

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.

This is what should make people roll in laughter.  I am surprised you didn't edit it yet like many other posts.

I haven't edited it because it doesn't contain any typographical mistakes or require any additional clarification.

I can run 680x0 object code from chip ram or I can run it from fast ram. It works in both cases, despite the fact that the two memory buses run at different speeds and the two memory types have different latencies. In short, the memory timing is not an issue to the correct operation of the code. It only affects the speed it runs at.

Are you really trying to claim otherwise?

[Karlos]

Hell, I can even run the same code under emulation on my PC where memory access time is below 10ns and transfer rates over 18GiB/s (as measured by memtest86+). Amazingly, it still works. It just runs faster.

[Karlos]

As for backwards compatibility, it gets worse with every major release of the 680x0 architecture.

The 68040 FPU dropped support for pretty much all floating point operations that existed in the 68881/2, except for basic arithmetic and square root evaluation. Everything else has to be trapped and emulated in software.

The 68060 dropped things that worked fine even on the 68040, such as 32x32->64 multiplication. It also dropped movep which was used in some hardware drivers (eg surf squirrel IIRC). The trap and emulate overhead for these operations can be crippling.

Don't even get me started on the coldfire.

[Karlos]

One thing, how do you get the two quotes within each other?  That's one feature which does not show up by default when I reply and sometimes it's relevant to quote a few nested quotes in the reply.

I did that manually by editing the post and putting my post inside a quote tag within yours.

There are many reasons for editing your posts

[Karlos]

@amigaski

Given that my reference was made specifically (and unambiguously) to memory timing, to which you ridiculed:

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.

This is what should make people roll in laughter.  I am surprised you didn't edit it yet like many other posts.

Do I take it you now recognise and retract this embarrassing faux pas?

[Karlos]

No, it's still correct.  Someone can easily read it as if you are stressing first part and second part is an instance (instantiation) of the first.

Dear me, is there no end to your fail?

The example given was of memory, more specifically DRAM:

From a hardware perspective, timing truly matters for the stability of the system. If you do not refresh DRAM at the recommended rate and it will eventually fail to keep its data intact, resulting in software failure (contrast this to static memory, for example). Try running 90ns rated memory at 50ns and see how stable it is over time. Not very, I think you will find.

From a software only perspective, it doesn't matter for the stability whether the DRAM is 100ns or 10ns, only the maximum speed of instruction fetch and data read/write will be affected. Try running Ed from Chip or Fast (hint NoFastMem) and see if it fails on either one after any length of time as a consequence of memory speed.

Only software too large to fit into Chip RAM (or any that requires atomic read/write to an area of memory) will fail to run. Nothing else will be affected from a stability perspective. The only effects you will observe are that running from Chip RAM your regular expression search in a large document might take longer.

So, do you still think that the RAM example is worthy of your "everybody should roll around laughing at you for this, I'm surprised you didn't edit it" remark, or would you prefer to be a man, admit you made a mistake and withdraw it?

[Karlos]

Weren't their (2) instructions that were dropped, but they mostly weren't being used by anything of consequence. Further instructions were also added. But what is your point? (Don't make come back there, I will stop this bus)

Well, "anything of consequence" is subjective. Several years ago, I had a friend that had a surf squirrel PCMCIA interface that became very slow and CPU hungry after the installation of a 66MHz 68060 board.

After a spot of driver dissassembly he tracked it down to the use of MOVEP to transfer data to the slot. It was one of those rarely used instructions that motorola decided to throw onto the "either trap and emulate in software or crash with illegal instruction exception" pile.

He wrote his own patch in the end, replacing the block of code containing the instructions with a branch to his own code that used regular moves to emulate the operation. It made a huge difference.

[Karlos]

Just to pour some petrol on this.

Each major successive release of the 680x0 architecture has required additional software emulation for missing opcodes, but they are considered by friend here to be backwards compatible.

I don't actually have a problem with that, since if you take the processor plus it's software support as a single entity, then it is backwards compatible with older object code.

So, taking this trend to it's logical conclusion: By building faster silicon that's less directly compatible and supporting more and more old object code through emulation on that silicon then there isn't any reason why you don't arrive at UAE's JIT. Far faster silicon with zero hardware backwards compatibility with M68K object code, all of which is supported through software emulation.

[Karlos]

The 68000 was incomplete in some areas, particularly with regard to virtualization and the separation of privileged and unprivileged instructions, so Motorola made changes to the design.

The 68010 is really what the 68000 should have been.