Fusion error with JIT enabled
 

Fusion 3.2 works only with JIT disabled.

I don´t know since when happens, but I remember it worked some years ago with JIT enabled.

When runs gives a continuous error like this:

Divide by zero sounds like program has some sort of CPU timing loop that runs far too fast when JIT is enabled. (Similar problem was quite common back in the day with some DOS programs)

When you say it only works with JIT disabled, what is it doing for you when it is enabled?

My Fusion 3.2 will GURU the moment I accept the license agreement on launch. Is that what was happening to you also? Judging by your screencap, you are running OS 4.x possibly and it has a different "reboot/suspend" screen.

My next step was to check the compatibility settings and, yes, JIT was one of the items I was going to try changing.

FUSION traps all 68K errors, so if you see an error like this it is not related to the Mac side itself. That would be an Amiga side problem.

FUSION use to work fine with JIT enabled the last time I tried it (last year).

I did not understand the problem, I launch Fusion 3.2 with JIT Enabled with the CPU 030, with the CPU 060 instead Amiga OS i get a Guru.

Turn off superscaler.

Yeah, turning JIT off got Fusion working for me. I've only experimented with the '040 CPU option, though. I do not have '060 libraries at the moment. The Mac OS 8 install I had on a old hard drive (real partition) is still snappy without JIT in 8 bit color mode. I imagine it would be even better with JIT working.

However, I encountered a problem with a HardFile I created. Just a measly 200MB file. After it was created and the Mac OS system booted, it naturally recognized a new volume and asked if I wanted to format it. Sure! There is even a little icon stating that it knows it is a "hard file". Problem is it is stuck on "Creating Directory...." for several hours. I am sure it is not supposed to take this long so I assume something went wrong.

Any tips on working with hard files in Fusion (within WinUAE)?

Thanks!

in winuae in older versions Fusion worked only with JIT enabled and crashed when JIT was disabled, idem for shape shifter

now is different, works on both but sometimes crash when JIT is enabled, depending winuae version or the config you are using

I still use winuae 2.80 version I consider it stable and near perfection,yet I don't like 3.x versions, they have timing problems , a few programs and emulators crash

DON'T use the 060 option in WinUAE when using FUSION. That will slow down the emulation dramatically because the Mac OS only works with Supercaler and branch cache disabled. Also, there is a HUGE amount of cache flushing that has to be done, and I patched the Mac OS everywhere to do that. Under real hardware, the 060 is slower than a 33MHz 040 (sometimes slower than 25MHz 040 in some cases). My Warp040/33MHz is faster than a Cyberstorm 50MHz 060 when running the emulation. In the case of WinUAE, you would be far better off using 040 mode.

JIT It crashes when using the CPU 060, with the 030 JIT WinUAE 3.3.0 It works fine with Shapeshifter and Fusion, HERE you can view one of my videos a few months ago.

This is so useless, only "something works" or "something does not work" information.. Not even sure what "something" is or if it even has anything to do with emulation (and which emulation!).

(If you are wondering why I haven't bothered to reply..)

Thanks for the tip.

Apparently enabling JIT with the 060 selected is causing this crash. 030/040 mode works fine. I hope that helps. :)

I don't specified the winuae 3.x issues very much because you don't want to fix timing issues if some program or game runs from workbench using a non standard config

I reported timming issues + gfx bugs in Aladdin and putty squad, both games running from WB a few months ago you still don't fixed them

It is not a bug.

I have said this millions of times: if you use fast modes, you get something that keeps changing all the time. Nothing is guaranteed if program expects some specific timing. (For example there was stupid code in fastest possible mode when program used blitter, it was fixed and some programs started running 50x faster in immediate blitter mode).

It would be pointless to artificially limit speed in fastest possible modes only because some games don't like it!

(What does this has to do with Fusion problem? It is not a game that does stupid things and/or assume some unaccelerated CPU timing, at least it should not.)

This issue has something to do with the 060 specifically since it doesn't occur with 020, 030, or 040 modes.

Perhaps but above reports are not very specific (JIT, CPU, and if 68060, 68060.library and unimplemented emulated or trapped)

Who knows.. the 060 was a horrible CPU, so I won't investigate this issue myself. I never wanted to support the 060, and of course Apple never did - and they were quite shocked that I got the Mac OS to work at all on an 060.

I agree the 060 was a horrible cpu , the 040/40 mhz is the best cpu for the AMiga
but the 060 can work fine in the AMiga if you know how to deal with it
I remember having a blizzard 1260/50 and lot of headaches to make some programs or games to work

in MAC OS the 060 works like this:

mac os7.x - works without mods

mac os8.0 - you must disable bran cache, yet some mac programs crash

mac os8.1 - you must disable bran cache and some extensions, which I don't remember now but I think quick time extension and some others


anyways in winuae you must select always a 020+FPU
selecting a 060 in winuae is idiotic because will load the 060 library which yet have lot of bugs and some programs don't like it will not work

What's wrong with the 060 ? You mean Apple knew you were working on a Mac emulator ?