Welcome, Guest. Please login or register.

Author Topic: Change processor  (Read 2515 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline darkcoder

  • Full Member
  • ***
  • Join Date: Sep 2002
  • Posts: 164
    • Show only replies by darkcoder
Re: Change processor
« Reply #14 from previous page: March 25, 2005, 10:28:05 AM »
@Karlos:

 I remember that the old MacOS used "fat binaries" (executables with both the 68k and PPC code) to solve the issue of the two cpu families. From which version do they have 68k software emulation, and from which OS version?
The Dark Coder / Trinity
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show only replies by Karlos
Re: Change processor
« Reply #15 on: March 25, 2005, 01:08:16 PM »
@darkcoder

Fat binaries were a way of distributing executables in a single release that could run on both PPC and 68K systems during the time that Mac were introducing PPC.

StormC for WarpOS supports a similar notion (as well as PPC only, and mixed binaries - of which fat binaries are a special case).

As far as I recall, the last OS to run on 680x0 was OS8.x. Since there were PowerMacs running this already, I can only assume they had 680x0 emulation at that point.

MacOS 9 was PPC only (IIRC) - anything 68K was emulated at this point.

The early 68K emulation didn't set the world on fire. Early  powermacs ran 680x0 applications slower than the 040 macs they were replacing. That said, they were more intent on porting 68K code to PPC rather than finding out how to maximise 68K emulation.

Luckily for us, we have 680x0 emulation for our PPC systems (A1, pegasos, classic) several years later, in which time the methods used to emulate the 680x0 have advanced considerably. Thanks to JIT, even the slowest PPCs used in amigas can run 68K software respectibly. On the rather more powerful G3 and G4 based systems, 68K apps fly. I've seen A1s and Pegs run rings around WinUAE on much faster x86 systems - of course this is partially due to the fact that the OS is running native, whereas the x86 is having to emulate the lot.
int p; // A
 

Offline MskoDestny

  • Sr. Member
  • ****
  • Join Date: Oct 2004
  • Posts: 363
    • Show only replies by MskoDestny
    • http://www.retrodev.com
Re: Change processor
« Reply #16 on: March 25, 2005, 06:46:22 PM »
Quote

Karlos wrote:
I've seen A1s and Pegs run rings around WinUAE on much faster x86 systems - of course this is partially due to the fact that the OS is running native, whereas the x86 is having to emulate the lot.

It also helps that OS4 and MOS make no attempts at emulating the rest of the hardware (which is probably particularly slow in UAE since it's designed to be able to handle software that requires fairly accurate cycle timings).
 

Offline Karlos

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show only replies by Karlos
Re: Change processor
« Reply #17 on: March 25, 2005, 10:36:04 PM »
Quote

MskoDestny wrote:
Quote

Karlos wrote:
I've seen A1s and Pegs run rings around WinUAE on much faster x86 systems - of course this is partially due to the fact that the OS is running native, whereas the x86 is having to emulate the lot.

It also helps that OS4 and MOS make no attempts at emulating the rest of the hardware (which is probably particularly slow in UAE since it's designed to be able to handle software that requires fairly accurate cycle timings).


Also true, but to be honest I was talking about OS/RTG friendly apps that by and large don't use the original amiga hardware. As you know, WinUAE is extremely fast in this area but OS4 and MOS still have the advantage that the OS (and also many often used third party libraries etc) itself is native.

Regarding compatibility, a lot of custom hardware utilising stuff still works fine in OS4, provided you run it on an classic PPC machine.
int p; // A