Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Documentation about the Vampire hardware

Mac Emulatorspage  1 2 3 4 5 6 

Jim Drew
Learn who I am!
Posts 67/ 1
06 Nov 2019 00:06


Gunnar asked that a new thread be started discussing Mac emulators.  So, here it is...

I am the creator of FUSION, the fastest and most compatible color Macintosh emulator ever made for the Amiga.  I also made FUSION-PC, which was a PC version that today runs circles around any real or FPGA based Amiga when using modern PC hardware.  FUSION came from the Mac emulation that was released for the EMPLANT hardware that I created.

When the last version of FUSION was released, there were only two programs that were known to not work with it.  Macsbug by Apple, and another program (I don't recall the name of it) that used the MMU to handle memory management.  It was not possible to make either of these work and still have the Amiga function in the background, so these two programs were not supported.  As far as I know everything else ever made for the Macintosh works.  Now, to be clear, there are some programs that only work on certain Mac models.  So, if you have a program that requires a 32 bit clean system, then it is likely not going to work on a Mac with 256K ROMs (Mac II, Mac IIx, etc.)  Likewise, a program that is making jumps directly into the Mac ROM is not going to work one some Mac models.  Make sure you look at the specs of the program you are trying to use - you could have the wrong system software and/or Mac ROMs for that program.  If the programs says that it requires a Quadra, then it really requires a Quadra based machine which have 1MB ROMs.

MacOS and GOLD Apollo core
--------------------------
The Mac OS uses the FPU extensively.  If Apple could have somehow made the mouse pointer position calculated with the FPU (instead of the ADB hardware), I am sure Apple would have done it!  When a FPU is present, Apple uses it (instead of integer math) to calculate everything from basic math functions to window coordinates.  The Mac OS *requires* 80 bit IEEE compliant functionality of the FPU (68881, 68882, or 68040).  The Apollo core does NOT have 80 bit math capability, so there will be many things under FUSION (or any other Mac emulator) that are going to crash and/or show issues.  A simple example is to install Mac OS8.1 and open a folder and try to use the window slider to move the contents of the window - the slider doesn't work and the slider size is not correct for the number of items contained in the folder.  That is an example of something that doesn't crash, but there are some things that can crash such as various extensions like the TCP control, A/ROSE, AppleTalk, etc.  Even with UAE (FS-UAE, WinUAE, etc.) it requires that "80-bit softfloat" be selected in order for any Mac emulator to work correctly.  There are also other cases where crashes can occur, like switching screen modes since the FPU is used to calculate the screen size.  I am hoping that at some point the FPU support in the Apollo core is improved to have the full 80 bit precision that is required for Mac emulations (and some Amiga programs) to function correctly.  There is no way to disable the FPU in the GOLD series cores.  Silver series cores do not have FPU support so no FPU related issues occur as the built-in integer FPU emulation is done by the MacOS when no real FPU is present.

FUSION, Shapeshifter, AMAX IV
-----------------------------
One common myth that people have is that Macintosh hardfiles and partitions can be shared between FUSION and Shapeshifter and AMAX IV.  That is simply incorrect.  You can't share system software between emulators.  You can't share system software between real Macs either!  If you installed Mac OS 7.5 on a Syquest cartridge (remember those?) on a Centris 650, you can't boot from that cartridge on anything other than another Centris 650.  If you try to boot that cartridge on a Quadra, Mac IIsi, etc. the machine *will* crash.

With a real Macintosh you must install the OS on the exact machine it is intended to run on.  If you change ANYTHING about the real Mac system, like the amount of phyical memory, the video card (or adding a 2nd video card), the hard drive size, or ROMs, you *must* re-install the Mac OS software.  There is no exceptions.  During the installation the MacOS determines the exact hardware being used and caters the installation to that exact hardware.  The *only* exception is MacOS 8.1.  Apple made a version of the MacOS 8.1 installer called the "Universal Installer CD".  This CD has system software for every MacII and later that was made.  You will need to force the MacOS to install the system software "FOR ALL MAC MODELS".  If you do that, then you can change the amount of memory, ROMs, and video drivers without having to re-install the system software.  However, you still can't share this system software with other emulators.  You have to do separate system software installations for FUSION, Shapeshifter, and AMAX IV and never share them.  The same partition or hardfile might appear to work between the emulators, but system resources are modified during the normal course of booting and running the OS, and that is something that Apple did not take care of correctly.  So, you will experience issues when trying to share the MacOS installation between emulators.  This was my biggest tech support headache back in the day.  Just make separate MacOS boot partitions for your emulators.  You can typically share partitions or hardfiles where applications have been installed.  Just note the requirements of the program itself.

NEW FUSION & PCx COMING!
------------------------
The last official release version of FUSION was v3.2.  There were NO later versions... period.  Every "cracked" version (often claiming to be some new release) is fake, and I have not seen a cracked version that removed all of the protection checks correctly.  So, any version being tested should be an original licensed version if you expect it to work.

I will be releasing new versions of FUSION and PCx (together as a package), both of which have new features such as improved video drivers, some internal fixes, and support for ISO disk images directly for CD's. You don't need a CD-ROM drive anymore for CD support (making installation a whole lot easier considering that the Mac OS7.5 and later came only on CD!).

People have asked for "Vampire optimized" versions of FUSION and PCx.  It's really not possible, other than I have an option in FUSION for making the Mac think there is no FPU so that FPU related issues are gone (along with FPU support).  I spent a few months tinkering with the using AMMX instructions with PCx, and there was no improvement that could be made by using any of the new instructions for doing things like swapping the endian order.  It turns out that the Apollo core's pipeline and caching mechanism works so well that the endian issues are absorbed.

If you have any questions about FUSION or PCx, or Mac emulation I can answer them here or on my forums (www.cbmstuff.com/forum)


Sean Sk

Posts 488
06 Nov 2019 01:12


Jim Drew wrote:

There is no way to disable the FPU in the GOLD series cores.

 
You can actually. Type "vcontrol fp 0" in shell and voila! no more FPU until power off.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
06 Nov 2019 06:34


Jim, my understanding is that your goal to post here is to "advertise" your products.
Jim, please stop don't this!
 
I see that again and again put both Shapeshifter and PC-Task down,
you also defame and repeatedly attacked the author of Shapeshifter.
 
This is NOT the place here for this.
Jim, again please stop don't this!
 
 
In your post I also see a number of technical interconnectedness.
 
a) Its not true that you can not turn the FPU off.
Both 68060 and 68080 behave exactly the same way
in turning off the FPU.
All you need it to poke the "DISABLE FPU BIT" in the Processor control register. You can do this in ASM with a MOVEC or with on CLI you can use for this the VCONTROL program.
 
b) Regarding AMMX tuning of PCx.
I recall very well that you tried out the Little-Endian MOVE in PCx and it did show a speedup.
The speedup in total was not that huge mainly because of PCx having no JIT.

This is easy to understand.
If your average cost to "emulate" 1 instruction is 3 Cycle - then saving 1 cycle will give you a major boost of 30%.
But if your emulation has always a lot of overhead and your average cost is 30 cycle then saving 1 cycle is not a major boost anymore.

PCx has here room for improvement.
Advertising your products will make a lot more sense again - if also some development was put in them.


Jim Drew
Learn who I am!
Posts 67/ 1
06 Nov 2019 07:08


I don't think I am advertising anything, and I can remove the part about releasing new versions if you like.
 
I wanted people to be aware of the issues when attempting to use the same system software between emulators, and FPU requirements for the Mac OS.
 
The Mac does a hardware level check for the FPU, so you can't fool it by simply flipping a bit in the CCR.  In order to disable the FPU on a Mac you actually have to patch the Mac OS's to eliminate the hardware check, which requires some exception handlers and patching numerous system resources.  It's quite a bit of work to accomplish this when you have an actual FPU available and don't want to use it.  If your core actually disables the FPU instructions, so they generate exceptions instead of actually performing FPU instructions, then that would work.  Otherwise, it won't.  Apple's hardware check is rather exhaustive because they used LC040's in many of their Mac models, and often times CPUs from Motorola labeled 'LC' actually had partially working FPUs and were labeled this way due to not passing QC for the FPU.  So, Apple's check makes absolutely sure that the processor has a working FPU by setting exception handlers and doing a range of FPU related functions (from Pack 4 and Pack 5) like Transcendentals, matrices, etc.
 
PCx would have to be completely re-written for a large memory model in order to have a real JIT type compiler built-in.  This is something that I will never be doing as it doesn't align with what PCx is for.  At this point PCx is good for running DOS programs that no longer work on modern PC hardware.



Gernt Gerloff

Posts 49
06 Nov 2019 07:41


That does not work, the computer will just crash and after reboot the FPU is on again.


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
06 Nov 2019 07:43


Jim Drew wrote:

  The Mac does a hardware level check for the FPU, so you can't fool it by simply flipping a bit in the CCR. 
 

 
OK I think I see now where your misunderstandings come from.

Let my explain how the FPU control of original MOTOROLA 68060 works.
 
The MOTOROLA 68060 has an internal register named "Processor Control Register".
This register has control bits in it, to enable/disable CPU features.

By setting here 1 Bit the FPU can be 100% turned off.
Then each FPU instruction will TRAP like there is no FPU.
 
This means with 1 MOVEC instruction you can turn off the FPU for the 68060. APOLLO 68080 behaves 100% the same as 68060 here.
 
There is one thing you need to take care of here.
We need to mind, that AMIGA OS will detect FPU first.
If AMIGA OS detected FPU and "marked in Attenflags" that FPU is there. Then AMIGA programs and AMIGA libraries will of course use FPU instructions. So if you then just turn the FPU "off", then FPU using libraries will of course create Traps.




Sean Sk

Posts 488
06 Nov 2019 07:44


Gernt Gerloff wrote:

That does not work, the computer will just crash and after reboot the FPU is on again.

What GOLD core version are you using? GOLD 2.11 works fine. Earlier versions did freeze when disabling the FPU but it was still disabled on restart (not power cycling).


Gernt Gerloff

Posts 49
06 Nov 2019 07:56


"With a real Macintosh you must install the OS on the exact machine it is intended to run on.  If you change ANYTHING about the real Mac system, like the amount of phyical memory, the video card (or adding a 2nd video card), the hard drive size, or ROMs, you *must* re-install the Mac OS software."

That is wrong, I have several 68k Mac at Hand and you can exchange quite a lot before you must reinstall, sometimes you have to poll some new extensions from the original disks, but it will still boot.
(I just installed a new NuBus GFX Card to my Performa 600 and it still works, now with 24 bit support!)
And I also used my original PowerBook HD in Shapeshifter (never used Fusion) without problems (PowerBook CD drive is broken) I had some issues with graphic card but basically it worked.


Andy Hearn

Posts 374
06 Nov 2019 09:27


Hey Jim, Gunnar
  Thanks for your input - i've learnt quite a bit today and i've only been on here 20 minutes!
 
  and regarding PCx, would windows98 be classed as a "dos program"? :D

[edit] removed question about JIT stuff, as it'll never happen


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
06 Nov 2019 10:17


Gernt Gerloff wrote:

That does not work, the computer will just crash and after reboot the FPU is on again.

You need to mind that AMIGA OS detect the FPU first.
If you then behind this back of the OS, secretly turn the FPU  - its clear what will happen. :-D

But there are solutions to this.
You can either tell the OS that FPU is gone.
Or you can turn FPU off, then reboot - and have the OS detect that FPU is gone.
Of in theory one could even turn of FPU for FUSION only...

So there are options possible.



Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
06 Nov 2019 12:48


Looking forward to improved emulators in q4 and will gladly pay 20$.
      Improved feature list says more then attacking competition. "No vamp optimizations" would, for me, mean a slightly updated old software avail on sale again, which is much less stimulating and surely less of deserved to pay in development time and new market adjustment.
   
    Note that I can understand something is not done and on a roadmap, which I find deserving of support. Saying something wont be done (or impossible without really trying) is ... something else.
 
  JIT is essential to boost, as OS4 JIT UAE proved. With JIT it was possible to jump from fast A600 ECS emulation to smooth 020 AGA to slow 030 AGA performance on single core PA Semi 1.8GHz with no hardware changed. Some form of JIT or dynamic vs static interpretation could be taken from other x86 emulators on longer run.
     
      V2 has cut down fpu, v4 has full one of higher precision.
     
      So you could do a v4 fork.
     
      As soon as gcc gets 080-ammx support, you could try to do optimized port and we LL see benefits.

      Meanwhile, emulator could take use of faster rtg, cpu, ide and 128-512mb ram.
     

----- Mac ---

If Fusion is easier to improve, take my $20 on Vampirized Fusion. Whatever can get more native, less emulated or JIT emulated.

Mac 68k files
EXTERNAL LINK 
Mac emulation Wiki

It can run things DOS and Win 3.11 are too slow etc.
I find this nice addons to Vamp Amiga and FreeMINT s/w library, even rather old.

iCab -2.9.9 iCab 2.9.9 CSS (Consider disabling)
This is the most feature-rich browser. It includes a pop-up blocker, and tabbed browsing. The 68k version is identical to the PowerPC version, and is the only browser where both PowerPC and 68k versions maintain the same version. Runs kind of slow and crashes a lot.

WannaBe 68k 1.0b14

Netscape Navigator 4.08 - improved Ibrowse
Internet Explorer 4.0.1 - Noooo
Aldus FreeHand 3.0
Aldus PageMaker 3.0
Macromedia Director 1.0
ClarisWorks 2.1
Microsoft Works 4.0
MS Word 1.0
Adobe Illustrator 3.0
Adobe Photoshop 4.0
Adobe Pagemaker 6.0
POV Ray 3.1
Adobe Acrobat Reader 2.1
Adobe PageMill 2

Something to port back ppc to m68k
EXTERNAL LINK   



Nixus Minimax

Posts 416
06 Nov 2019 14:47


Jim Drew wrote:
Apple's hardware check is rather exhaustive because they used LC040's in many of their Mac models, and often times CPUs from Motorola labeled 'LC' actually had partially working FPUs and were labeled this way due to not passing QC for the FPU.  So, Apple's check makes absolutely sure that the processor has a working FPU by setting exception handlers and doing a range of FPU related functions (from Pack 4 and Pack 5) like Transcendentals, matrices, etc.

Tell me, if Apple does so many checks on the FPU to absolutely be sure it is a good one, why does the supposedly too imprecise 080-FPU pass the test only to then cause problems in trivial calculations like window coordinates and slider sizes which should require no more than perhaps twelve bits of precision while the 080-FPU offers more than 50 bits of precision?



Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
06 Nov 2019 15:05


v2 FPU is really boring story.
 
  How to prepare code for v2 FPU and what it can do is covered
  https://www.apollo-accelerators.com/wiki/doku.php/apollo_core:fpu
 
  V2: 64bits or little less, emulating some instructions, bit buggy, experience based on FEMU.
 
  V4: Real fully HW no cuts no emu 080 80 bit FPU is on V4 and no software uses it.


Mr Niding

Posts 459
06 Nov 2019 19:09


@Gunnar

I dont see a problem with Jim advertising his software, if it leads to development and better compability/utilization of the Apollo core features.
Better performance can only be a good thing.

And youre assuming people will blindly throw cash at a product without examining said performance, and if the improvements warrants a new version.

Sidecomment: dont we want developers to support the platform?


Steve Ferrell

Posts 424
06 Nov 2019 21:23


Mr Niding wrote:

@Gunnar
 
  I dont see a problem with Jim advertising his software, if it leads to development and better compability/utilization of the Apollo core features.
  Better performance can only be a good thing.
 
  And youre assuming people will blindly throw cash at a product without examining said performance, and if the improvements warrants a new version.
 
  Sidecomment: dont we want developers to support the platform?

I agree.  Commercial development can only help the Vampire.  Lack of commercial development will only lead to another dead platform or at least a very long period of hibernation for any platform. I'm glad that Jim Drew sees an incentive to update/upgrade/develop 68K products and like it or not, revenue is what drives hardware (including the Vampire) and software development.  Love will only get you so far.



Sebastian Blanco

Posts 148
07 Nov 2019 02:06


i could love to test fusion but Jim complained about it being included into coffinos so i don't have it anymore to test the speed.

Jim how can one get a license to use your emulator now ?
?????


Gunnar von Boehn
(Apollo Team Member)
Posts 6197
07 Nov 2019 02:08


Mr Niding wrote:

  @Gunnar
     
  I dont see a problem with Jim advertising his software, if it leads to development and better compability/utilization of the Apollo core features.
  Better performance can only be a good thing.
     
  And youre assuming people will blindly throw cash at a product without examining said performance, and if the improvements warrants a new version.
     
  Sidecomment: dont we want developers to support the platform?
 

     
Short answer:
Yes, real developers are always welcome and will get support.
But no one needs conmans.
 
 
I'm sorry to have to say it so clear, but after all what happened
we have unfortunately very serious doubts that Jim Drew is trustworthy.


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
07 Nov 2019 03:09


Sebastian Blanco wrote:

  i could love to test fusion but Jim complained about it being included into coffinos so i don't have it anymore to test the speed.
 

 
  As soon as he puts older one to Aminet (if ever) and newer one to sale. Now you cant.
 
 
Gunnar von Boehn wrote:

  we have unfortunately very serious doubts that Jim Drew is trustworthy.
 

 
  Promises are cheap here and cost nothing.
 
  One he puts new Fusion and PC.X he will be more of trustworthy


Steve Ferrell

Posts 424
07 Nov 2019 03:19


Gunnar von Boehn wrote:

Mr Niding wrote:

  @Gunnar
       
  I dont see a problem with Jim advertising his software, if it leads to development and better compability/utilization of the Apollo core features.
  Better performance can only be a good thing.
       
  And youre assuming people will blindly throw cash at a product without examining said performance, and if the improvements warrants a new version.
       
  Sidecomment: dont we want developers to support the platform?
 

     
  Short answer:
  Yes, real developers are always welcome and will get support.
  But no one needs conmans.
   
 
  I'm sorry to have to say it so clear, but after all what happened
  we have unfortunately very serious doubts that Jim Drew is trustworthy.

Wow, that's a pretty bold and harsh statement, but then I know very little of what happened.  Do you think the Jim Drew account here on the Apollo forums is fake or are you saying that you really have serious trust issues with Jim?


Vojin Vidanovic
(Needs Verification)
Posts 1916/ 1
07 Nov 2019 03:44


Beside whatever happened in removing Fusion from Coffin,
    Jim has history of "too strong words".
   
    As developer he should have a chance to prove othewise.
   
    As an example, same promise of "slightly updated" emulators can be found on EAB and is 2 years old.
 
  Back on track, how can Fusion be improved?
 
  - Utilization of native resolutions in Vamp h/w for MacOS display, similar to non emulated CPU
  - Better usage of v2 and v4 fpu
  - Better usage of more and faster RTG, RAM and IDE in kind of direct access, as much as emulator can do (Amithlon approach?)
 
  Speed is already acceptable, any gains are most welcome. Its easy when max enemy is 040, on x86 side we need every "mm of enemy territory"-

posts 105page  1 2 3 4 5 6