MAC emulators? - Page 3

B14ck W01f · 15 November 2016, 02:32

Quote:

Originally Posted by JimDrew

LOL!

It is unlikely that I will ever just release any of my software as public domain, especially since I am now producing brand new CBM products and I will re-release updated versions of my old software as commercial products.

In other words, the only way to make Fusion public domain is if Jim was dead.

JimDrew · 15 November 2016, 03:06

Well, actually that would then require 75 years to pass by before it became public domain - per U.S. law.

Hewitson · 09 December 2016, 04:01

Quote:

Originally Posted by JimDrew

No copyrighted software should be appearing on any website without permission of the copyright holder. I have never released any of my software to the public domain.

At one stage you were hosting copyrighted D64 images on your own site. You are nothing but a lamer and a hypocrite.

trixster · 09 December 2016, 13:20

Bit unnecessary. Why the personal attack?

Locutus · 09 December 2016, 13:34

because of the lovely irony.

trixster · 09 December 2016, 14:17

You can make a point without being a dick about it.

JimDrew · 11 December 2016, 03:47

Quote:

Originally Posted by Hewitson

At one stage you were hosting copyrighted D64 images on your own site. You are nothing but a lamer and a hypocrite.

You are mistaken, I have never hosted any files (other than my own software) on my website.

Jacques · 28 October 2022, 12:10

Quote:

Originally Posted by JimDrew

It is unlikely that I will ever just release any of my software as public domain, especially since I am now producing brand new CBM products and I will re-release updated versions of my old software as commercial products.

Is the new commercial version of Fusion born&available, yet?

JimDrew · 03 November 2022, 02:56

Not yet. I am working on making some significant changes to the MacOS versions (6/7/8) because Mac works by moving memory around constantly, and that clears the cache. The issue is that EMU68 is constantly clearing the cache which could be megs in size. So, the speed was horribly slow - slower than the standard PiStorm 68K emulator in many cases. Things are much improved now though, but a lot of testing is still required. The good news is that these changes are compatible with real 680x0 hardware and offer a speed improvement with 060 systems.

Thomas Richter · 03 November 2022, 13:53

Yes, the MacOs memory manager and its handle system is prone to frequent heap compaction and thus causes issues with memory caches, I understand.

Jim, as matter of precaution, please stay away from MOVE16, which looks like a prime candidate to avoid caching when moving memory around. There are a couple of known-bad boards that have issues with it, most notably many GVP turbo boards when bursting into Zorro-RAM, and the P5 2060 board is also affected by this issue. Generally, Zorro-II and bursting does not seem to go well.

Caching is for that reason turned off on affected boards as caching implies bursting for the 68040 and above, but MOVE16 bursts, no matter whether the cache is on or off. There is thus no effective workaround.

Side effects are that MOVE16 may be slower(!) than a simple MOVE, or (on writing) even complete hangs of the system.

Despite, there are a couple of know errata in MOVE16 in both the 68040 and 68060.

JimDrew · 03 November 2022, 22:01

So, apparently I stopped using MOVE16 at some point after EMPLANT's Mac emulation was released (which would be early MacOS7). The MacOS uses MOVE16 in just about everything OS related when a 68040 is detected. Those instructions are patched out in real time with 68030 compatible code.

grelbfarlk · 04 November 2022, 02:07

Quote:

Originally Posted by JimDrew

Not yet. I am working on making some significant changes to the MacOS versions (6/7/8) because Mac works by moving memory around constantly, and that clears the cache. The issue is that EMU68 is constantly clearing the cache which could be megs in size. So, the speed was horribly slow - slower than the standard PiStorm 68K emulator in many cases. Things are much improved now though, but a lot of testing is still required. The good news is that these changes are compatible with real 680x0 hardware and offer a speed improvement with 060 systems.

Hey while you're knifing around rebuilding MacOS stuff, do me a favor and rebuild the PowerPC enabler to support the SonnetAmiga WarpUP powerpc.library so we can like run the fatter fat binaries on the PPC. Thanks in advance.

JimDrew · 04 November 2022, 08:53

Quote:

Originally Posted by grelbfarlk

Hey while you're knifing around rebuilding MacOS stuff, do me a favor and rebuild the PowerPC enabler to support the SonnetAmiga WarpUP powerpc.library so we can like run the fatter fat binaries on the PPC. Thanks in advance.

Yeah... that's never happening. I refuse to work on anything PowerPC related.

grelbfarlk · 06 November 2022, 05:07

NOOO!!

Don_Adan · 06 November 2022, 10:03

Quote:

Originally Posted by JimDrew

So, apparently I stopped using MOVE16 at some point after EMPLANT's Mac emulation was released (which would be early MacOS7). The MacOS uses MOVE16 in just about everything OS related when a 68040 is detected. Those instructions are patched out in real time with 68030 compatible code.

For me these patches can be optionally only for 68040/68060. User can choose, if he want or dont want to use MOVE16 versions. Some bad designed Amiga turbo cards can not be main target for good program. Especially, if it costed program performance. F.e. fast ATA driver has many different copy routines with and without MOVE16.

Thomas Richter · 06 November 2022, 20:10

It's not only the cards that are bad. The instructions themselves have issues. Besides, how can a user know which issues a board has? This is asking a bit much for users - besides, how much difference does it make?

Don_Adan · 06 November 2022, 20:26

If something is OPTIONAL then user can disable or enable this option. If this instruction have issues then why MacOS Quadra users dont know about this?

JimDrew · 08 November 2022, 06:56

There has NEVER been an option, and there won't be one. I have always patched these instructions out because there were so many problems with the Amiga hardware. There is a potential bus contention issue and several boards (like the X-Calibur) had an issue with MOVE16.

The speed difference between MOVE16 instructions and correctly coded 68020/30 equiv. is typically NILL. Block moves are done on data that is not typically 16 byte aligned (a requirement of MOVE16), so you are moving some amount of data (bytes, words, longwords) before and/or after anyways.

MOVE16 has a known pipeline problem with the early 68040's used in Quadras, which is why it was a surprise to see OS8 come out still using the MOVE16 instructions for block moves. You can work around this problem by putting a NOP in front of the first MOVE16 instruction, but that adds extra time. The majority of the (wasted) time is figuring out the boundaries for splitting the moves from byte/word/long so that MOVE16 can even be used.

If you ever find yourself having to go backwards in memory, like copy from a higher memory location to a lower one, backwards, you can forget using the MOVE16 instruction all together because it doesn't play nice with the caches going that direction. Apple had routines that walked backwards. These got patched with smart routines moving forwards that allowed the cache to help out if data was already there. I have a ton of experience with how the caches works on the 68020/030/040/060 and the Intel 80486/586/Pentium. I tried all kinds of caching tricks with my PC emulation, even running it backwards in memory to try to eliminate the byte swapping requirements. The caches only work forwards on modern processors. In fact, I don't know of any CPU that actually caters to reverse direction of data.

JimDrew · 08 November 2022, 07:10

Quote:

Originally Posted by grelbfarlk

NOOO!!

LOL! Yeah, that's about right!

Don_Adan · 08 November 2022, 12:10

This is Your program and Your choice. X-Calibur is not Amiga turbo board, this is Mac turbo board which can works with A3640. Option is only option, dont must be recommended to use. I never tested copy speed for MOVE16 vs normal MOVE.L and MOVEM.L copy routines. But if fast ATA driver using MOVE16 for copy blocks then must be fastest for some Amiga boards. If I remember right RapidRoad driver or RoadShow used MOVE16 for fastest copy too.

03 November 2022, 22:01	#51
JimDrew Registered User Join Date: Dec 2013 Location: Lake Havasu City, AZ Posts: 741	So, apparently I stopped using MOVE16 at some point after EMPLANT's Mac emulation was released (which would be early MacOS7). The MacOS uses MOVE16 in just about everything OS related when a 68040 is detected. Those instructions are patched out in real time with 68030 compatible code. Last edited by JimDrew; 04 November 2022 at 08:52.

08 November 2022, 06:56	#58
JimDrew Registered User Join Date: Dec 2013 Location: Lake Havasu City, AZ Posts: 741	There has NEVER been an option, and there won't be one. I have always patched these instructions out because there were so many problems with the Amiga hardware. There is a potential bus contention issue and several boards (like the X-Calibur) had an issue with MOVE16. The speed difference between MOVE16 instructions and correctly coded 68020/30 equiv. is typically NILL. Block moves are done on data that is not typically 16 byte aligned (a requirement of MOVE16), so you are moving some amount of data (bytes, words, longwords) before and/or after anyways. MOVE16 has a known pipeline problem with the early 68040's used in Quadras, which is why it was a surprise to see OS8 come out still using the MOVE16 instructions for block moves. You can work around this problem by putting a NOP in front of the first MOVE16 instruction, but that adds extra time. The majority of the (wasted) time is figuring out the boundaries for splitting the moves from byte/word/long so that MOVE16 can even be used. If you ever find yourself having to go backwards in memory, like copy from a higher memory location to a lower one, backwards, you can forget using the MOVE16 instruction all together because it doesn't play nice with the caches going that direction. Apple had routines that walked backwards. These got patched with smart routines moving forwards that allowed the cache to help out if data was already there. I have a ton of experience with how the caches works on the 68020/030/040/060 and the Intel 80486/586/Pentium. I tried all kinds of caching tricks with my PC emulation, even running it backwards in memory to try to eliminate the byte swapping requirements. The caches only work forwards on modern processors. In fact, I don't know of any CPU that actually caters to reverse direction of data. Last edited by JimDrew; 08 November 2022 at 07:10.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Love Emulators? - Dgen & Hatari emulators	Paul	News	18	14 January 2023 20:56
Best Emulators ?	Washac	support.Other	2	15 September 2015 20:13
New to Amiga Emulators, help please	Brduk	New to Emulation or Amiga scene	10	04 August 2011 08:29
Favourite Emulators	aldo	Retrogaming General Discussion	92	10 February 2007 01:16
Running Emulators In Mac Emu	CU_AMiGA	Amiga scene	3	31 January 2005 11:42

15 November 2016, 03:06	#42
JimDrew Registered User Join Date: Dec 2013 Location: Lake Havasu City, AZ Posts: 741	Well, actually that would then require 75 years to pass by before it became public domain - per U.S. law.

09 December 2016, 13:20	#44
trixster Guru Meditating Join Date: Jun 2014 Location: England Posts: 2,339	Bit unnecessary. Why the personal attack?

09 December 2016, 13:34	#45
Locutus Registered User Join Date: Jul 2014 Location: Finland Posts: 1,179	because of the lovely irony.

09 December 2016, 14:17	#46
trixster Guru Meditating Join Date: Jun 2014 Location: England Posts: 2,339	You can make a point without being a dick about it.

03 November 2022, 02:56	#49
JimDrew Registered User Join Date: Dec 2013 Location: Lake Havasu City, AZ Posts: 741	Not yet. I am working on making some significant changes to the MacOS versions (6/7/8) because Mac works by moving memory around constantly, and that clears the cache. The issue is that EMU68 is constantly clearing the cache which could be megs in size. So, the speed was horribly slow - slower than the standard PiStorm 68K emulator in many cases. Things are much improved now though, but a lot of testing is still required. The good news is that these changes are compatible with real 680x0 hardware and offer a speed improvement with 060 systems.

03 November 2022, 13:53	#50
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,238	Yes, the MacOs memory manager and its handle system is prone to frequent heap compaction and thus causes issues with memory caches, I understand. Jim, as matter of precaution, please stay away from MOVE16, which looks like a prime candidate to avoid caching when moving memory around. There are a couple of known-bad boards that have issues with it, most notably many GVP turbo boards when bursting into Zorro-RAM, and the P5 2060 board is also affected by this issue. Generally, Zorro-II and bursting does not seem to go well. Caching is for that reason turned off on affected boards as caching implies bursting for the 68040 and above, but MOVE16 bursts, no matter whether the cache is on or off. There is thus no effective workaround. Side effects are that MOVE16 may be slower(!) than a simple MOVE, or (on writing) even complete hangs of the system. Despite, there are a couple of know errata in MOVE16 in both the 68040 and 68060.

06 November 2022, 05:07	#54
grelbfarlk Registered User Join Date: Dec 2015 Location: USA Posts: 2,918	NOOO!!

06 November 2022, 20:10	#56
Thomas Richter Registered User Join Date: Jan 2019 Location: Germany Posts: 3,238	It's not only the cards that are bad. The instructions themselves have issues. Besides, how can a user know which issues a board has? This is asking a bit much for users - besides, how much difference does it make?

06 November 2022, 20:26	#57
Don_Adan Registered User Join Date: Jan 2008 Location: Warsaw/Poland Age: 55 Posts: 1,979	If something is OPTIONAL then user can disable or enable this option. If this instruction have issues then why MacOS Quadra users dont know about this?

08 November 2022, 12:10	#60
Don_Adan Registered User Join Date: Jan 2008 Location: Warsaw/Poland Age: 55 Posts: 1,979	This is Your program and Your choice. X-Calibur is not Amiga turbo board, this is Mac turbo board which can works with A3640. Option is only option, dont must be recommended to use. I never tested copy speed for MOVE16 vs normal MOVE.L and MOVEM.L copy routines. But if fast ATA driver using MOVE16 for copy blocks then must be fastest for some Amiga boards. If I remember right RapidRoad driver or RoadShow used MOVE16 for fastest copy too.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)