15 November 2016, 02:32 | #41 |
m68k all the way
Join Date: Aug 2011
Location: Koalaland
Posts: 523
|
In other words, the only way to make Fusion public domain is if Jim was dead.
|
15 November 2016, 03:06 | #42 |
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, 04:01 | #43 |
Registered User
Join Date: Feb 2007
Location: Melbourne, Australia
Age: 41
Posts: 3,773
|
At one stage you were hosting copyrighted D64 images on your own site. You are nothing but a lamer and a hypocrite.
|
09 December 2016, 13:20 | #44 |
Guru Meditating
Join Date: Jun 2014
Location: England
Posts: 2,354
|
Bit unnecessary. Why the personal attack?
|
09 December 2016, 13:34 | #45 |
Registered User
Join Date: Jul 2014
Location: Finland
Posts: 1,186
|
because of the lovely irony.
|
09 December 2016, 14:17 | #46 |
Guru Meditating
Join Date: Jun 2014
Location: England
Posts: 2,354
|
You can make a point without being a dick about it.
|
11 December 2016, 03:47 | #47 |
Registered User
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 741
|
|
28 October 2022, 12:10 | #48 | |
Registered User
Join Date: Oct 2013
Location: Wrocław, Poland
Posts: 202
|
Quote:
Is the new commercial version of Fusion born&available, yet? |
|
03 November 2022, 02:56 | #49 |
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 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,304
|
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. |
03 November 2022, 22:01 | #51 |
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. |
04 November 2022, 02:07 | #52 | |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 2,958
|
Quote:
|
|
04 November 2022, 08:53 | #53 | |
Registered User
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 741
|
Quote:
Yeah... that's never happening. I refuse to work on anything PowerPC related. |
|
06 November 2022, 05:07 | #54 |
Registered User
Join Date: Dec 2015
Location: USA
Posts: 2,958
|
NOOO!!
|
06 November 2022, 10:03 | #55 | |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,030
|
Quote:
|
|
06 November 2022, 20:10 | #56 |
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,304
|
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 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,030
|
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, 06:56 | #58 |
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. |
08 November 2022, 07:10 | #59 |
Registered User
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 741
|
|
08 November 2022, 12:10 | #60 |
Registered User
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 56
Posts: 2,030
|
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) | |
Thread Tools | |
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 |
|
|