real amiga vs winuae

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

[amigaksi]

@amigaski

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



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

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.

[amigaksi]

I run virtual machines all the time.  I have virtual servers working with non-virtual servers, neither i nor the users notice any difference.  All OSs are software, they behave the way they behave because of how they are written, the only difference hardware makes is in speed and video resolution.  Since the base machine of most computers running UAE is several orders of magnitude faster than the old Amiga equipment was the only issue is keeping the emulator from running too fast.

There is no difference between a UAE based Amiga and a hardware based Amiga.

You only need one example of software to disprove your claim and there's more than one example already available.

[amigaksi]

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.

It was based on a deductive fact like:

Fact: All men are mortal (based on logic or laws of the universe that everything goes through old age/decay and death).
Experience: All men I know are proving to be mortal.  

Fact: Motorola purposely maintained backward compatibility with 68000 according to their spec.
Experience: All 68000 software (I have tried) works fine under 68020.

People offer upgrade 68020 boards for Amiga so it's not based on some inductive knowledge.

The experience by itself doesn't allow you draw a general conclusion for everything just like running a few titles on emulator does not prove emulator is same as real amiga.

[amigaksi]

Ahem... 68040.libarary...

Never had any of those libraries in software I tested or even if it were present in some disks in some folder whether it was actively loaded and being used.  I put in a 68020 board in A2000 and didn't install any libraries-- ran the same software as before.  And some of this software is just a complete ANIM file and player software-- no 68020 or 68040.library.

[amigaksi]

As has been explained to you, this is simply not the case. That you've not used any software that is that calls on a 68000 specific function not available in later models does not change this.

...

It's the same for 0x86-- there's some minor differences.  But they are still considered backward compatible NOT incompatible.  Stop with the insults-- just exposes your biased fanatical nature.

[amigaksi]

Dear me, is there no end to your fail?

The example given was of memory, more specifically DRAM:
...

Context wasn't nor the first part.

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

Sorry, I don't edit my posts especially if they are true.

[amigaksi]

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)

It's like 6502 and 65816 processors.  65816 is backward compatible but you can find some instances where it doesn't do the samething as 6502 even in compatibility mode.

It would be unfair and biased to claim 6502 is NOT compatible with 65816.

[amigaksi]

Err, excuse me. Your whole point was about pure hardware compatability, this is clearly and demonstratably not so, not on x86 and not on 68k. With each significant step things were lost and added. The result is that compatability, whether you like it or not, is maintained only through software.

...

I already know there are minor differences.  But the essence works on hardware level-- no library needed.  I can boot up 68020 machine right now and run 68000 code w/o any drivers.

>Thats as may be, it doesn't change the fact that a certain amount of emulation software is required to maintain that compatability. Something that you have vehemently denied the necessity for.

No the compatibility is there w/o software but perhaps there's some rare piece of software that needs it.  
http://www.cpu-world.com/CPUs/68020/

>There's that word again. You seriously don't know what it means, do you?

You don't.  You are biased towards PCs as is evident throughout this thread and the other thread I particpate in.  So it's calling a spade a spade.

>As for insults, hah! I haven't even begun to insult you yet. Quite frankly the poor quality drivel you have been headsticking here isn't worthy of insult.

You haven't refuted any of my points nor even addressed most of them yet have already insulted.  Don't need much intelligence to insult people-- Perhaps I can get some kindergarten kids to reply to you.

[amigaksi]

Yeah amigaski seems to think that all devices on the system have their own timing... and that this timing is measure in cycles...

@amigaski cycles are not a unit of time, the cycle IS the synchronizing universal constant that keeps all the devices running together

I always have stuck to the same definition-- t=1/f; yeah, sure it may not matter to some applications if all cycles are maintained.

[amigaksi]

It's abit pointless to use 68040.library on 68020 based machine.

My point is valid for 680x0 processors not just 68020 which I used as an example because happen to have it in front of me to play around with.

[amigaksi]

Try doing the same with either an 040 or 060 without the requisite 040/060 library.
 

...

You stand corrected right?

>Go ahead and do the above and see how far your system gets. BTW, your brochure does not cut it as evidence.

It's not "mine".  There are many links that state the same.  

>I am niether for nor against the PC, it's not important enough for me to have a bias about.

I can PROVE you are biased towards PCs from what you have written in the two threads I am subscribed to.  

>Err, yes I have refuted your points, done so time and again, that you have chosen a path of wilful ignorance is not my or anyone elses problem.

Your ignorance was just proven-- you think a library is required and it's not.  You have yet to address many other points made and I won't waste my time linking to them as you are proven time and time again to blurt out blind statements like above.

>So go get a kid to reply, most young kids are less liable to lie or twist things to suite their purposes. I can teach a kid to provide verifiable evidense to back up their argument. Aparently this lesson is lost on you.

Kids can insult you better than you can insult me.

[amigaksi]

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.

Missing some instructions would be equivalent to missing some functionality like support for light pens or paddles on an emulator.  As I stated you have to looks at the essence.  OCS registers are same for ECS/AGA and the timing is same for Copper, Audio Interrupts, etc.  Processors do have some differences like frequency being a major one but the essence of the instructions is the same throughout all 680x0 amigas.

[amigaksi]

What kind of misinformed drivel is this? Of course the_leander is perfectly correct to say you need the library if you are using a 68040/68060. After several dozen recoverable alerts during booting I just about managed to get into workbench, just, before a fatal error took it down again.

Don't believe me? See attached. Now, if you don't mind, I'll re-enable my 68040.library so that I can actually get the thing booted.

What's the matter can't make up your mind?  In post #1191 in the other thread you stated you can boot up without the library and now after your sidekick corrected himself/herself you changed your mind.  You may be driving him/her crazy.

I don't get any alerts in booting up my applications.  Perhaps, you used something that actually uses FPU/MMU rather than 68000 application.

[amigaksi]

Oh here and there.

Am uploading them as and when I find an opening to use them

I taught a few kindergarten kids to upload silly pictures recently.