real amiga vs winuae

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

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

[amigaksi]

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

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.

[amigaksi]

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.

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

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

[amigaksi]

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

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.

[amigaksi]

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.

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

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

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

[amigaksi]

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?

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 am claiming that software does need to know the cycle time.  Perhaps, it's not the processor frequency if it's not targetting a particular processor but at least the cycle times for audio rates, VBIs, serial baud rates, CIA timers, etc.

[amigaksi]

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

I do understand them that's why I never replied to you.

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

You have a different concept than some others do.  My argument is whether it's a real amiga functionally not whether it has good bookkeeping and took into account all the cycles each cycle possibly having a different time span.

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

Not crashing does not translate to working.  Doing a mock-up of raster interrupts (via buffering) and bufferring audio is NOT same as a real machine doing it.  

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

Okay, we agree here.  But speed up can have same problems as well.

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