real amiga vs winuae

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

[amigaksi]

It can be used, but be aware of performance penalties. Most X86 desktops includes a working cache coherency hardware.



AMD K8 (which includes Northbridge) keeps the instruction and data caches coherent in hardware, which means that a store into an instruction closely following the store instruction will change that following instruction. Other processors, like those in the Alpha and MIPS family, have relied on software to keep the instruction cache coherent. Stores are not guaranteed to show up in the instruction stream until a program calls an operating system facility to ensure coherency. The idea is to save hardware complexity on the assumption that self-modifying code is rare.

The reason why AMD K8 includes additonal hardware complexity is to support for self-modifying X86 code.

For Intel Core 2, Errata AW46 i.e.
"Self/Cross Modifying Code May Not be Detected or May Cause a Machine Check Exception"
Workaround: It is possible for the BIOS to contain a workaround for this erratum.

I assume you know about Intel micro-code patches.

This issue was fixed in E0 and R0 stepping.
AW = "Intel® Core™ 2 Duo processor E8000 series".

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.

[amigaksi]

...
You first sunbeam.
...

Your stuff is proven bullcrap.  And you misquoting me is your 2nd problem.  Saying "you first" as if it applies to the other party is your third problem.

>Yes, you really have. NTSC/PAL/SECAM etc are specifications, and like all specifications there is a tollerance, a little wiggle room. It's this leeway that allows you to do spiffy things like move the screen up down left and right. These things are done by minute adjustments to the frequency of the graphics output. A little goes a long way.

More bullcrap.  It's per spec every cycle.

[amigaksi]

...
Your problem is that you have a fundie mindset (as evidenced by your demands that I prove you wrong, which btw is a logical falacy).
...

Thanks for modifying my posts again in your quotes, just proves my point.  No logical fallacy-- you are misquoting me, I'm not misquoting you so you can't say "You first."

>Damn, you got me, I totally couldn't move the screen around via a control panel that made minute adjustments to the frequency output, not in AmigaOS nor in BeOS! I must have just imagined the capability this whole time, thankyou for teaching me the error of my ways! /sarcasm.

The fact that you have to adjust your frequency should prove to you that TVs are being broadcast at a fixed frequency.  And you don't have to keep adjusting your frequency for the different channels and Amiga/Atari/C64 lock into this same frequency given the consistency of running cycle-exact code that does video-based manipulations and works on all TVs.  And the color burst is exact and for NTSC it's frequency is (13*7*7*5*5*5*5*3*3)/(13*11*7) = 3579545Hz.

[amigaksi]

My post has nothing to do with clock speed changes.


Except 680x0 is a bit fuzzy when comes to legacy support.

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

[amigaksi]

My pleasure, no, really. And yes, you cannot prove a negative, that is what you've asked me to do (repeatedly) and that is a logical falacy.

I didn't say "you first" to you for misquotation (though some of your selective quotation of some of my posts borders on that).
...

In post #207, you misquoted me (PURPOSELY) and then in #214 you told me I should I stop misquoting.  In post #229, you misquoted me again.  And then you repeatedly told me I am confusing timing with cycles while I have clearly stated I am sticking to T=1/f.  Then I tell you to stop this bullcrap, you say "You first".  I have quoted you EXACTLY to the points I replied to.  Only put "..." where it's irrelevant to the point.

>Not had to, could (although to be fair, some televisions I ran my Amiga through really did need it), what it proves is that the Amiga isn't all that accurate (now there's a shock!). It also proves beyond a shadow of a doubt that there is a certain amount of tollerance within the specification - if there wasn't, any minute alteration in frequency would result in no picture.

I already said even with the ppm rating, it's considered to be working per spec.  Your vague blurb, Amiga isn't all that accurate is misleading.  I get at least 558ns accuracy on every Amiga.

[amigaksi]

...
Actually, you haven't. Some (not all) of your replies have bordered on quote mining.
...

You have a big problem of just blaming people of things falsely.  You butchered my quotes -- something called tampering.

>Ok, perhaps I wasn't clear here, I'm not arguing the spec, what I'm saying is that the spec (or at least the equipment built to the spec) has a certain tollerance, this is true of any piece of equipment. If there was zero tolerance, the ability to adjust the screen in the way currently available would not be possible (or necessary for that matter).

Adjusting screen can be done even while maintaining same color-burst frequency.

Your blurting that "amiga  is not accurate" shows your bias and ignorance.  Whatever tolerances you apply, apply more so to PCs since NTSC frequencies are more precisely defined and crystals more accurately manufactured due to TV standards.

[amigaksi]

Pot, meet kettle. I broke up your quotes point by point to address those individual posts, in the end I must admit, when you're going over the same thing over and over after having had it explained to you multiple times by multiple people why you're wrong I did have some fun with them. You on the other hand have sliced and diced my, as well as others posts to the degree that the many of the points have been removed.

...

I know you feel you have to say something just make you feel better that you responded.  But you are dead wrong.  You misquoted me and you don't understand the point I made regarding cycle-exactness using NTSC-based systems.

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

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

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

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