Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!yale.edu!cmcl2!rutgers!cbmvax!mks From: mks@cbmvax.commodore.com (Michael Sinz) Newsgroups: comp.sys.amiga.hardware Subject: Re: Fusion-40, the 68040 Card for A2000 avail... Message-ID: <22700@cbmvax.commodore.com> Date: 26 Jun 91 14:20:21 GMT References: <1991Jun20.114837.22962@unibi.uni-bielefeld.de> <1991Jun21.183207.27427@CAM.ORG> <22645@cbmvax.commodore.com> <1991Jun25.212433.24418@CAM.ORG> Reply-To: mks@cbmvax.commodore.com (Michael Sinz) Organization: Commodore, West Chester, PA Lines: 56 In article <1991Jun25.212433.24418@CAM.ORG> menzies@CAM.ORG (Stephen Menzies) writes: >mks@cbmvax.commodore.com (Michael Sinz) writes: > >>[stuff deleted] >> However, some applications >>may not be ready for 68040 and CopyBack. CopyBack tends to make programs >>that write code to RAM not work too well since even if the instruction cache >>is flushed, the new code may not have been copied to physical RAM from >>the cache.[more stuff deleted] > >And Again, RCS's reply: > >[Quote]Copyback will work very well with programs that are copied to ram, >however instead of flushing the instruction cache, flush the data cache >before you addtask(). this must work,period. If you cannot see this working >I strongly suggest that you read the 68040 users manual.[unquote] I have read the manual (a few times) You must push back the DCache *AND* flush the ICache to work correctly. (Too bad you can not just push the DCache; the push also flushes the DCache which is a loss... :-() Note that AddTask() is not so much the problem (even though it does solve the loading problem.) Many programs do other things that have nothing to do with AddTask(). If RCS would like to see my list (which includes things such as AddLibrary(), AddIntServer(), SetIntVector(), and many more such as IND_ADDHANDLER command to input.device!) Anyway, there are many parts of the system that are even worse off (try running a program with overlays) AmigaDOS 2.0 solves many of the problems but there is still a need for applications to either know what they are doing or for a set of patches that tries to patch the system in enough places. Note that this still can not catch all of the situations. (Any self modifying code that does not call a special system function to run it would be impossible to "patch" without changing the application itself.) >--------end of RCS replies------------- > >And I repeat, I am NOT an employee of RCS though I have been independently >testing the Fusion_40 for a couple of weeks now, in particular, with 3D >Animation software. I am willing though to relay questions of a technical >nature direcly to them. I would be interested in knowing what they did about the caching issues. I am in charge of the 68040 project here and have found out many interesting things about applications and the assumptions some of them make. In addition, it would be good to coordinate the method of installing the FPSP code such that the various 68040 vendors can just supply the one file they need and have the standard system do the rest. /----------------------------------------------------------------------\ | /// Michael Sinz - Amiga Software Engineer | | /// Operating System Development Group | | /// BIX: msinz UUNET: rutgers!cbmvax!mks | |\\\/// | | \XX/ Quantum Physics: The Dreams that Stuff is made of. | \----------------------------------------------------------------------/