Fusion Mac Emulator

[Misclegend]

To use Fusion on a real Amiga ie A1200 or A4000 without gfx card you need a MMU otherwise you can not use the "amirefresh" video driver

Amirefresh is the only video driver who gives a real MAC experience in AGA

Having a gfx card on the Amiga the MMU is not really needed ( ie winuae or A4000+ Picasso IV)
you can use the "P96directXL" video driver and everything is fine

For shapeshifter is the same thing you need a MMU to use the refreshed Savage video driver

[JimDrew]

Originally Posted by AmigaHope

It's cool to hear about the paravirtualization of the Quickdraw and math libraries. The room for improvements on graphics handling via paravirtualization are obvious, but I have a question though, how are the math libraries any faster vs. just having the FPU handle them?

Because the math libraries call the FPU through a bunch of convoluted C code. I replace the math packages with hand-optimized assembly code which results in these functions being substantially faster - about 2.5 times faster on average.

Originally Posted by AmigaHope

Do the Apple math libraries just handle transcendentals badly on 040/060? Do they just rely on exception trapping? What about running on a system that also has Cyberpatcher/Oxypatcher that sticks a JIT cached version into the code after the first trap?

The Mac uses traps for everything. That's how system function calls work. Apple's memory manager moves code around all of the time as it needs to. This is why you don't get a physical memory address when you allocate memory on a Mac. Instead, you get a handle (which is a pointer to a pointer). That handle has to be used every time you go access even your own allocated memory, not to mention your own code in the case of self-modifying code (which is a no-no on the Mac). There are some exceptions where you can lock the physical memory allocated (system resources do this). In those cases you can replace the traps (as they occur in real time) with direct jumps (which typically requires copying the trap and the next instruction to be able to replace the trap with a jump address). I do this where ever possible.

I have no idea if Cyberpatcher/Oxypatcher works because these were written long after FUSION was released. I have not heard or seen anything about these being an issue though.

[JimDrew]

Originally Posted by Misclegend

To use Fusion on a real Amiga ie A1200 or A4000 without gfx card you need a MMU otherwise you can not use the "amirefresh" video driver

That is not true. You do not need a MMU ever. None of the video drivers for FUSION that actually *requires* a MMU. There is a definite speed difference though when you don't have a MMU! The MMU can be used to determine when the Mac video memory has been changed and trigger an update in the Amiga screen.

[Misclegend]

Originally Posted by JimDrew

That is not true. You do not need a MMU ever. None of the video drivers for FUSION that actually *requires* a MMU. There is a definite speed difference though when you don't have a MMU though! The MMU can be used to determine when the Mac video memory has been changed and trigger an update in the Amiga screen.

I know that none of the fusion video drivers requires MMU
what I meant is that the only fast and usable fusion video driver for AGA is amirefresh, but without MMU is very slow ( unusable)

[JimDrew]

I am not sure what you mean? The Amirefresh video driver is quite usable on a stock A1200.

[AmigaHope]

Originally Posted by JimDrew

Because the math libraries call the FPU through a bunch of convoluted C code. I replace the math packages with hand-optimized assembly code which results in these functions being substantially faster - about 2.5 times faster on average.

So theoretically you could use your math libs on a real Mac and still see the gains? If so jeez did Apple drop the ball. The default Commodore math libraries on the Amiga weren't the fastest, but if you don't count transcendental instructions on 040/060 they were nowhere near 2.5x slower than later hand-coded libraries.

The Mac uses traps for everything. That's how system function calls work. Apple's memory manager moves code around all of the time as it needs to. This is why you don't get a physical memory address when you allocate memory on a Mac. Instead, you get a handle (which is a pointer to a pointer). That handle has to be used every time you go access even your own allocated memory, not to mention your own code in the case of self-modifying code (which is a no-no on the Mac). There are some exceptions where you can lock the physical memory allocated (system resources do this).

Jeezus I had no idea. No wonder Macs were so fricking slow. What's the point of doing this in a single-tasking OS? Did it work this way pre-Multifinder? I guess if you were determined to have System 7 run on a non-MMU system it's one way to enhance stability, but I really have to wonder what was going through the engineers heads at Apple. It just makes way more sense by the time System 7 was a thing to have an MMU do the heavy lifting of address translation and let the code think it's directly accessing.

In those cases you can replace the traps (as they occur in real time) with direct jumps (which typically requires copying the trap and the next instruction to be able to replace the trap with a jump address). I do this where ever possible.

So did you replace the known traps ahead of time on load (old vmware style) or did you have an exception handler to patch the traps inline live, because that's exactly what Cyberpatcher/Oxypatcher do (for instructions unimplemented on 040/060).

[JimDrew]

Originally Posted by AmigaHope

So theoretically you could use your math libs on a real Mac and still see the gains? If so jeez did Apple drop the ball. The default Commodore math libraries on the Amiga weren't the fastest, but if you don't count transcendental instructions on 040/060 they were nowhere near 2.5x slower than later hand-coded libraries.

I met with John Scully and a team of engineers and execs at Apple's headquarters in early 1993. Apple wanted to talk about EMPLANT's Mac emulation (long before FUSION). I figured it was going to be the typical scare tactic about using ROMs and such (which were required, and I wanted to license). It turned out that Apple was more concerned about the perception of EMPLANT's Mac emulation possibly tainting the Apple brand image if it were to run Mac program slower or with various issues. After doing a complete demo (they had seen some demos themselves), they came to understand that not only did EMPLANT's Mac emulation not have any type of stability issue, they learned that it could actually run MORE software than any single model Mac because you could choose different ROMs and operating systems, something not possible with a real Mac. At that time, I showed them the benchmarks using Speedometer (the Mac version of the Amiga's AIBB). They were stunned at the performance difference. When I flipped screens to show them that the Amiga was also running at the same time, the engineers could not understand how it was possible and were rather skeptical thinking that this was some sort of parlor trick. They of course learned that the results were real.

Originally Posted by AmigaHope

Jeezus I had no idea. No wonder Macs were so fricking slow. What's the point of doing this in a single-tasking OS? Did it work this way pre-Multifinder? I guess if you were determined to have System 7 run on a non-MMU system it's one way to enhance stability, but I really have to wonder what was going through the engineers heads at Apple. It just makes way more sense by the time System 7 was a thing to have an MMU do the heavy lifting of address translation and let the code think it's directly accessing.

So did you replace the known traps ahead of time on load (old vmware style) or did you have an exception handler to patch the traps inline live, because that's exactly what Cyberpatcher/Oxypatcher do (for instructions unimplemented on 040/060).

The code is patched in the (heavily modified) system resource loader. Every resource, be it ROM based or disk loaded, is loaded with this. I replace some of the system resources completely with native Amiga-handled code (like .HD - the hard drive handler, and .sony - the disk handler). The Pack4/Pack5 resources are the math libraries and those are patched out completely with my own. There are literally hundreds of patches, and every version of the Mac OS (from OS6.0 through OS8.5) require different patches and all of those are supported with FUSION.

There is a LOT of code to pull this off... not as much as the 1.7 million lines of assembly code that make up PCx, but there was literally years worth of coding done on EMPLANT's Mac emulation and the various revisions to lead up to FUSION.

[AmigaHope]

I'm surprised Apple didn't just try to hire you to fix their clusterfuck then. Although this was the John Scully dark ages so I guess that makes sense.

Still this just adds to my amazement at how garbage the classic MacOS was. The fact that they had to include hardware kludges to let their 68000 high-byte address register hacks keep working up through the 68040 Quadra days led me to believe that the inmates were running the asylum.

[JimDrew]

It's interesting looking through the OS because you can easily tell what "group" (or person?) wrote each part of the OS based on the coding style. Much of it, especially later on, was written in C and is horribly bloated. Drivers and certain key parts of the OS were clearly written in optimized assembly. The multitasking code is about 64K worth of C coded junk. It's amazing how convoluted that code is. Of all of the things that should have been written in assembly, it was that code. I looked at replacing it, but it was so twisted that I couldn't figure out what everything was doing so it was left alone.

[torsti76]

I've got a problem running Fusion 3.2 on a CyberstormPPC. I can't seem to find a way to choose my CD ROM drive, which is connected to the CSPPC's UW-SCSI adapter.

I tried typing 'cybppc.device' and selecting unit 1 in the appropriate fields, but keep getting the error message 'Improper device driver for CD-ROM setup!'

Is there a way around this?

EDIT: Found the solution. Had to open the file requester, remove 'DEVS:' from the drawer name field and type cybppc.device.

[torsti76]

So, I now got it to boot from CD, both MacOS 8.0 and 7.6.1.

However, as soon as the Initialization of the hard disk image starts, the system freezes. I already tried all sorts of combinations of cache and MMU settings. They either lead to an immediate reset of the Amiga or to MacOS (and the Amiga) freezing during hardfile initialization.

Some words about my setup:

A4000T with CSPPC (060 / 72MHz - Bus running at 50MHz from its own crystal)

128 MB 60ns RAM on the CSPPC, 16 MB on the motherboard

Emplant card w/ SCSI and all 5 SRAM sockets and coin cell populated.

SSD and CD ROM drive connected to the CSPPC's UW SCSI. First partition (3500 MB) is reserved entirely for the Mac HD images. All partitions formatted with PFS3aio.

Fresh OS 3.1.4.1 install with Thor's MMUlib including the 68060.library. Registered HSMathLibs for the 060. Mediator w/ Voodoo3 2000 and latest P96 from Individual Computers. No rsrvwarm or the like in s:s-s

What I observed so far:

With disabled MMU in memory settings of Fusion, the Mac always starts, but is very slow. Before I can enable the MMU, I have to disable the data cache while running the emulator and shut it down properly once for the PRAM to get saved. Afterwards I can enable the MMU and the emulation runs much faster.

Enabling the superscalar setting in the CPU configuration leads to all sorts of funny non recoverable errors in MacOS. These mostly occur right at the beginning of the boot sequence.

But the real question is: Why can't I initialize any hardfile, regardless of its size? Could this be because of PFS3?

I'll try with FFS tomorrow. Somehow related, if I'd just leave out hard drive partitions and hardfiles from the Cyberstorm and instead use the SCSI port on the Emplant with a drive dedicated to the emulation, would this have the potential to work better?

Thank you very much in advance for any hints or pointers...

[torsti76]

Still no luck with hardfile on FFS, other ROMs, and MacOS 7.5.3. The system always freezes during initialization of the hardfile.

Doesn't anybody have any hints on this?

[JimDrew]

Originally Posted by torsti76

Enabling the superscalar setting in the CPU configuration leads to all sorts of funny non recoverable errors in MacOS. These mostly occur right at the beginning of the boot sequence.

Yep, I would expect this. You can try going through the EXTENSIONS and removing them one by one to figure out which one(s) are the issue. There were a lot of them that do not work with Superscalar enabled.

Originally Posted by torsti76

But the real question is: Why can't I initialize any hardfile, regardless of its size? Could this be because of PFS3?

Make sure that that hardfile is smaller than 1GB. Other than that, this could be a MacOS issue due to you NOT using the correct system software for the exact ROM you are using. You would be better off trying to find an original Mac OS8.1 Universal Installer CD and do an installation FOR ALL MAC MODELS. If you don't, you absolutely MUST have the same system software for the ROM you are using. You can't use a Centris ROM with the Mac OS for a Quadra. Each version of the Mac OS is specific to the ROM. Apple *finally* made the Universal System Installer available starting with OS7.6.1, but OS8.1 is a better OS. This could literally be why you can't format a hardfile.

[torsti76]

Thank you for the quick answer, @JimDrew.

I followed your advice and installed 8.1 universal. Works like a charm.

However as it turns out, the MMU problems I've had were mostly due to the aggressive memory timing of the Cyberstorm PPC. After setting the RAM timings to 70 ns (although I've giot 60 ns modules installed) fixed the crashes that occured on emulation startup.

What I'm still experiencing is that the Amiga crashes right after shutting down the emulation - either through the Fusion Control Panel or through the "Special -> Shutdown" menu on the Mac side. These crashes only occur if the MMU is activated in the Fusion settings (regardless of the chosen mode)

Any hints? Thank you!

[Estrayk]

Jim:

I think we have asked this question to ourselves many times, but we would love to hear your opinion:

According to your sincere opinion, - does the Shapeshifter have any advantage over Fusion?

thx

[torsti76]

@Estrayk if you followed Jim's posts in the various forums you will know that he will always recommend using Fusion instead of Shapeshifter. And honestly, why would he advertise a software that competes with his own developments.
The only advantage that Shapeshifter has over Fusion is that it's available legally right now.

For me, Fusion is much more relevant than Shapeshifter because it fully supports the EMPLANT board, which I paid a lot of money for. I once owned a Performa LC475 which was barely able to cope with MacOS 8.0. I'm very glad, my Amiga does so much better with EMPLANT, Fusion, and MacOS 8.1.

That said, @JimDrew, is it possible that the problems I'm experiencing upon emulation shutdown are related to the Mediator and its memory/MMU handling?

[Estrayk]

It is obvious that he recommended his own program, the question may not have been asked correctly, what I would like to know if there is any aspect in the shapeshifter that is superior to FUSION. As a whole, I also think that FUSION is vastly superior. It is not a question with evil, it is a serious question.

[JimDrew]

There is absolutely nothing superior to FUSION in Shapeshifter. The person who cobbled Shapeshifter together using code stolen from Amax IV and EMPLANT's Mac emulation has enough to make it "work", but lacks the compatibility and speed that FUSION has.

Typically problems with starting up and shutting down are due an extension that is not compatible with the ROM. Try booting with extensions off and then see if it shuts down correctly. If so, you will need to disable each extension one by one to figure out which is the problem.

[McTrinsic]

As mentioned two posts ago.
+1 for Shapeshifter being available legally.

It’s nice to know that Fusion is better. If I can’t buy it or obtain it at all it’s useless for anyone who didn’t buy it back then.

[JimDrew]

"Legally" is certainly questionable. It's made of stolen code. It's the only reason it exists.

I sold thousands of copies of FUSION, as did Blittersoft. I see original disks pop up quite often on eBay. However, there will be a new version released. I am waiting on Mikej to get a virtual MMU implemented at the moment and then I can release the all new Mac emulation based on FUSION.