PC still playing Amiga catchup

[Karlos]

To eliminate 16-bit mode is a MAJOR difference as there are millions of DOS programs and Windows 3.x programs out there.  As far as I know, you can disable caching on the later 680x0 processors to make them more compatible.  Strictly, you know the frequencies are incompatible but at least they can be called opcode compatible.

No they can't. Many opcodes are not supported on later 680x0 processors that were supported by earlier ones.

The 68020 changed the behaviour of some opcodes on the 68000 that will cause any software using them to crash. You cannot move bits from or to the status register outside of supervisor mode on 68020+. Since most operations on this register were actually condition code related, they added opcodes to read/write the CCR instead none of which can be used on the 68000. So, you can write code that uses the SR in userspace on the 68000 that won't work on the 68020+ or code that uses the CCR in userspace on the 68020 which won't work on the 68000. You either use separate code for each CPU or you install a trap handler of some sort for the privilege violation. It cannot be called opcode compatible any more.

Next, the 68040 threw away dozens of valid 68881 opcodes. You cannot use any of the transcendal operations or use the 68881/2 mathematical constants. You will get an illegal exception if you try to do so. Again, you must either write code that does not use these opcodes, or you install a handler for the unimplemented instruction exception and emulate them on trap.

Next, the 68060 threw away 64-bit integer arithmetic (multiply and divide) that were implemented in 68020, 68030 and 68040. You cannot use any of these opcodes without invoking an illegal instruction exception. Again, you must rewrite your code not to use them or install a handler for the unimplemented instruction exception and emulate them on trap.

The 680x0 series is not fully backwards compatible purely in hardware. It must use software assist. It says so in my copies of the user manuals and the examples above are all easily demonstrated.

[the_leander]

You are biased if you think the 68000 is incompatible with 680x0 processors.  

There are incompatabilities and they're so great that they need emulation to cover. They also change from model to model.

minor differences.

So minor that the Phase5 had to provide dummy 68040 libraries to even allow an 060 based accelerator card to boot.

You don't know what biased means although you are exemplifying it.

Disagreeing with your patent and demonstratable nonsense!=biased.

You are SG and I claim my £5.

[Karlos]

So minor that the Phase5 had to provide dummy 68040 libraries to even allow an 060 based accelerator card to boot. 5.

Mind you, CyberPatcher was a fantastic system though. Why trap unimplemented instructions when you can replace them with a direct branch to the handler code after the first trap?

-edit-

You are biased if you think the 68000 is incompatible with 680x0 processors.

What's biased about it? It's just the way it is. Motorola actually did a good job in making the SR privileged and dumping the least used instructions into software emulation for later CPUs. It allowed them to focus on making the silicon faster for the vast majority of object code.

You only have to look at the 68040 FPU performance compared to the 68882 or the 060 performance compared to the 040 to see they were right to do so. The only thing that surprised me was dropping the 64-bit arithmetic in the 060. I wouldn't have thought that was underutilized in the previous models.

[amigaksi]

There are incompatabilities and they're so great that they need emulation to cover. They also change from model to model.

...

"Great" for you.  They purposely tried to make them compatible-- what minor differences there are don't compare with eliminating the 16-bit mode completely.

>Disagreeing with your patent and demonstratable nonsense!=biased.

Nonsense that I think 68000 is compatible with 68020 and you don't.  If you can establish that 0x86 is less incompatible, perhaps I can take you seriously.

[the_leander]

Mind you, CyberPatcher was a fantastic system though. Why trap unimplemented instructions when you can replace them with a direct branch to the handler code after the first trap?

I ended up using Oxypatcher in the end for pretty much this reason. The speed boost was phenominal - what would take me 4 or more hours to render would take me a little over 2.

Further to my original point though. Try removing 68040.library on an Amiga that uses an 040 processor and see how far it gets you...

[the_leander]

"Great" for you.  They purposely tried to make them compatible-- what minor differences there are don't compare with eliminating the 16-bit mode completely.

See my previous post.

>Disagreeing with your patent and demonstratable nonsense!=biased.

Nonsense that I think 68000 is compatible with 68020 and you don't.

Citation please. I think you'll find no such post where I say these two models are "incompatable".

[ElPolloDiabl]

This thread reminds me of another famous argument. Check out 2:59 on this vid:
http://www.youtube.com/watch?v=9q2ABS7wSxU&feature=topvideos

:roflmao:

[Trev]

Nonsense that I think 68000 is compatible with 68020 and you don't.  If you can establish that 0x86 is less incompatible, perhaps I can take you seriously.

I'm confused by this whole argument. The differences between the various 680X0 revisions are well-known and well documented. The differences between the various 80X86 revisions are well-known and well documented as well. So, any code that relies on a feature of an earlier version of a CPU that doesn't exist or has changed in a future version of a CPU will be incompatible without some sort of workaround, e.g. 68040.library.

I don't see the lack of VM86 when an Intel or AMD processor is running in 64-bit mode as a limitation. One could suppose, however, that if Intel had designed the x64 model, it might have included it. Intel chose to focus on the Itanium, though, and the market adopted an arguably incomplete model produced by AMD.

As an architect/engineer/administrator/monkey of Windows systems, the last thing I want to support is software running in NTVDM, whether it's DOS or Windows based. If you're not gaming, NTVDM is wonderful; however, I've always disliked not being able to arbitrarily choose the target VM of a Windows application. It's either shared or isolated. It would have been nice to include support for multiple shared VMs that didn't require working around limitations in the GUI.

There. That was a Microsoft criticism. I have lots of them, but I still like Windows, and in general, Microsoft does a great job of making sure my business runs smoothly. Don't start with the virus stuff. Please. Humans work for Microsoft, and humans are fallible. That's never going to change. Somewhere underneath all the logos and litigation, there's a software engineer just like you and me, working under extreme amounts of pressure, just doing his best to feed his family and produce a product of which he can be proud, in so far as the project and the market will let him.

[paolone]

"Great" for you.  They purposely tried to make them compatible-- what minor differences there are don't compare with eliminating the 16-bit mode completely.

whatwhatwhatwhat!?

That's incredible, if you didn't exist, someone should have invented you: every night I come here to see if there are any news, and you always bring to me some delight.

Ok, so X64 architecture has dropped 16 bit compatibility. And now? How can we live with this? "there are millions of DOS/Win31 programs out there". One for every gameport? Once again, I have to inform you that we are in (late) 2009, 10 years after that 16-bit programming has been considered "deprecated" on the x86 architecture, and that today almost nobody still uses DOS. So anyone willing to use ancient code and ancient programs has the ability to run them on a virtual machine.

What are you? Some sort of technoecologist, desperately fighting for obsolete solutions preservation?

[persia]

Yeah, the reason for backward compatibility is to provide a bridge so that software manufacturers can catch up with the new system.  You provide it for a reasonable amount of time and then you move on.  The only reason anyone is interested in running 15+ year old software for the Amiga is because the company that produced the Amiga *DIED* 15 years ago.  If they had survived *nobody* would care if the current Amiga OS was compatible with with the old stuff.

I couldn't do 10% of what I do now on 15 year old software.  Life moves on.  That's the way in the computer world.  In the Mac world Carbon is finally being put to bed, it's junk but it had to be there initially, now it's just a waste of good electrons...  This is what happens in living systems.  You evolve and progress or you die.

whatwhatwhatwhat!?

That's incredible, if you didn't exist, someone should have invented you: every night I come here to see if there are any news, and you always bring to me some delight.

Ok, so X64 architecture has dropped 16 bit compatibility. And now? How can we live with this? "there are millions of DOS/Win31 programs out there". One for every gameport? Once again, I have to inform you that we are in (late) 2009, 10 years after that 16-bit programming has been considered "deprecated" on the x86 architecture, and that today almost nobody still uses DOS. So anyone willing to use ancient code and ancient programs has the ability to run them on a virtual machine.

What are you? Some sort of technoecologist, desperately fighting for obsolete solutions preservation?

[Hammer]

Symbolically however, the more scans that hit (1/On) the 'harder' the result.

I was referring to direction, deceleration and acceleration on the classic digital joystick.

[amigaksi]

See my previous post.

...

I did, it's your normal misunderstanding.

>Citation please. I think you'll find no such post where I say these two models are "incompatable".

So they are compatible like it states here:

http://www.cpu-world.com/CPUs/68020/

[amigaksi]

whatwhatwhatwhat!?

That's incredible, if you didn't exist, someone should have invented you: every night I come here to see if there are any news, and you always bring to me some delight.

Ok, so X64 architecture has dropped 16 bit compatibility. And now? How can we live with this? "there are millions of DOS/Win31 programs out there". One for every gameport? Once again, I have to inform you that we are in (late) 2009, 10 years after that 16-bit programming has been considered "deprecated" on the x86 architecture, and that today almost nobody still uses DOS. So anyone willing to use ancient code and ancient programs has the ability to run them on a virtual machine.

What are you? Some sort of technoecologist, desperately fighting for obsolete solutions preservation?

Some people still use DOS and Win98SE and other OSes that boot up in real-mode (16-bit).

The argument is whether it's considered compatible w/o 16-bit support not how many people still use it.  VGA still has CGA modes but hardly anyone uses them.

Insults can be said by anyone-- so stick to rational arguments.

[Hammer]

"Great" for you.  They purposely tried to make them compatible-- what minor differences there are don't compare with eliminating the 16-bit mode completely.

Both Real86 and Virtual86 modes are available in legacy mode.

[Hammer]

Some people still use DOS and Win98SE and other OSes that boot up in real-mode (16-bit).

Run it in legacy mode.

The argument is whether it's considered compatible w/o 16-bit support not how many people still use it

The legacy mode includes support for Real86 and Virtual86 modes.

[alexatkin]

To be fair, the PS3 also has a weaker GPU and a worse memory scheme than the Xbox 360. I see these to be more of a problem. Especially since Sony does have tools available to get you to use the SPU's relatively well even if you don't know how to (API's even ).

Actually there is a lot of argument that the memory is more efficient and that clever coding of the SPEs can make up for the limitations of the GPU and even surpass the 360s one.  

Personally, even if true I see that as a cop out.  Surely the point of a good games console is to make the developers job as easy as possible.  

It also cannot alter the fact that the Xbox 360 could use almost all its memory for textures if the software only needed a tiny amount for its use, and vice versa.  Plus there are a lot of the functions the PS3 has (voice chat in-game, custom soundtracks, etc) that were tagged on after launch and require a LOT more memory taken away from the games than the Xbox, as the Xbox had those functions built-in to the OS and optimised for its allocated memory space since day one. But we digress off topic now.