68060 speedup patches + more

[guest11527]

-Latest libs! (040_060Libs.lha) : I currently use mmu libs
-BlizKick : I can't use this, I have 1mb kickstart/rom and blizkick soesn't support them, only 512kb roms is supported. I use CPU Fast command. Better solution would be nice.
-FBlit : It is towerized system with RTG
-FText : - " " -
-BlazeWCP : I'm running this, it doesn't affect Picasso96
-CopyMem060 : I use MPC's
-UtilPatch060 : Need to check this
-CyberPatcher : Most of apps/games are for 040/060 anyway?

To be frank, most of this is not really helping much. "CPU Fast" is nonsense and does not work for a 060 at all since it does not support it. If you want to mirror the ROM into RAM and have the mmu libs, use "MuFastROM". Not any third party program.  Additionally, depending on the board, "MuFastZero" might also help to mirror execbase into fast memory.   "FBlit" is nonsense if you have an RTG system anyhow (in such a case, blits are executed by the CPU in first place, through the RGB system, and you don't need an additional source of instability in first place). The same goes for FText. All this is already run through the RTG System in first place, no patch needed - and not exactly helping either. I don't know what BlazeWCP is, but it falls probably into the same category.  CopyMem060 is most likely not helping, only damaging a perfectly fine copy. Besides, how much software are you aware of that copies huge amounts of memory around so that this would create a measurable difference?  Seriously, the 060 should - out of the box - reach approximately twice the speed of the 040. If it does not, none of the above programs will help either. Something is then seriously wrong, for example the CPU caches are off. (No, the *CPU* command does not help here. It is the processor library, i.e. the 68060.library that is then not loaded. The CPU command is a legacy program that has not been updated and that does not support the 68060.).

[giZmo350]

God... I love this guy!

To be frank, most of this is not really helping much. "CPU Fast" is nonsense and does not work for a 060 at all since it does not support it. If you want to mirror the ROM into RAM and have the mmu libs, use "MuFastROM". Not any third party program.  Additionally, depending on the board, "MuFastZero" might also help to mirror execbase into fast memory.   "FBlit" is nonsense if you have an RTG system anyhow (in such a case, blits are executed by the CPU in first place, through the RGB system, and you don't need an additional source of instability in first place). The same goes for FText. All this is already run through the RTG System in first place, no patch needed - and not exactly helping either. I don't know what BlazeWCP is, but it falls probably into the same category.  CopyMem060 is most likely not helping, only damaging a perfectly fine copy. Besides, how much software are you aware of that copies huge amounts of memory around so that this would create a measurable difference?  Seriously, the 060 should - out of the box - reach approximately twice the speed of the 040. If it does not, none of the above programs will help either. Something is then seriously wrong, for example the CPU caches are off. (No, the *CPU* command does not help here. It is the processor library, i.e. the 68060.library that is then not loaded. The CPU command is a legacy program that has not been updated and that does not support the 68060.).

[Oldsmobile_Mike]

LOL.  I was thinking the same thing when I saw that list. Although I will admit that I still run a couple of those utilities, it's probably more of a placebo effect - they're not really helping anything.

Thomas - I did have one thing that I've always kind of wondered about though. Even on an RTG system, wouldn't Fblit still help for non-RTG screenmodes? For example, system-friendly games and apps that aren't promoted to an RTG screenmode (but use NTSC 640x200, for example)?

Would love to hear your thoughts on this. Thanks!

[stefcep2]

LOL.  I was thinking the same thing when I saw that list. Although I will admit that I still run a couple of those utilities, it's probably more of a placebo effect - they're not really helping anything.

Thomas - I did have one thing that I've always kind of wondered about though. Even on an RTG system, wouldn't Fblit still help for non-RTG screenmodes? For example, system-friendly games and apps that aren't promoted to an RTG screenmode (but use NTSC 640x200, for example)?

Would love to hear your thoughts on this. Thanks!

I'm not Thomas but going off ancient memories my understanding is that the entire point of ftext and fblit-moving functions that happen in Amiga chip ram in to fast ram.  Which is why you should- I do- see more chip ram available with those patches. The screens data on an RTG system with RTG screens is held in the graphics ram.  Amiga screens are held in chip ram unless fblit shifts them into fast ram.  So the answer in my experience is" "yes".

[utri007]

To be frank, most of this is not really helping much. "CPU Fast" is nonsense and does not work for a 060 at all since it does not support it. If you want to mirror the ROM into RAM and have the mmu libs, use "MuFastROM". Not any third party program.  Additionally, depending on the board, "MuFastZero" might also help to mirror execbase into fast memory.   "FBlit" is nonsense if you have an RTG system anyhow (in such a case, blits are executed by the CPU in first place, through the RGB system, and you don't need an additional source of instability in first place). The same goes for FText. All this is already run through the RTG System in first place, no patch needed - and not exactly helping either. I don't know what BlazeWCP is, but it falls probably into the same category.  CopyMem060 is most likely not helping, only damaging a perfectly fine copy. Besides, how much software are you aware of that copies huge amounts of memory around so that this would create a measurable difference?  Seriously, the 060 should - out of the box - reach approximately twice the speed of the 040. If it does not, none of the above programs will help either. Something is then seriously wrong, for example the CPU caches are off. (No, the *CPU* command does not help here. It is the processor library, i.e. the 68060.library that is then not loaded. The CPU command is a legacy program that has not been updated and that does not support the 68060.).

This is very old thread, that time I didn't have a RTG.

BUT, problem was that Apollo's non standard fast chip ram access made very visible difference when using AGA and Hires Laced workbench compared to Blizzard.

I don't have FBLit and FText running.

I tried MuFastRom but I had some problems with it, can't remember what? Does it support 1mb physical kickstart? I have 1mb kickstart, with all the BB2 rom updates, filesystems and scsi.device.

PS. I just mentioned you name in another thread, maybe you could comment there also? http://www.amiga.org/forums/showthread.php?t=70260&page=6

Is CopyMem060 equalent to MCP's copy mem quick?

I ques that I have just been happy that system boots up very fast, without additional reboot.

[guest11527]

BUT, problem was that Apollo's non standard fast chip ram access made very visible difference when using AGA and Hires Laced workbench compared to Blizzard.

Access to chipram is limited by the bandwidth, not by the CPU power. Hence, for chipram it makes barely any difference whether this is a 68030 or a 68060 - or anything in between for that matter.  

I tried MuFastRom but I had some problems with it, can't remember what? Does it support 1mb physical kickstart?

Probably not. There are no 1MB Kickstart ROMs, CBM didn't made them, so that makes them unsupported. Unless we get an official 1MB kickstart, I see little reason to support them.  

Is CopyMem060 equalent to MCP's copy mem quick?

Equivalent in the sense that it makes barely any difference? Likely yes. Equivalent in the sense that the implementation is identical? I do not know. (-:

[guest11527]

The screens data on an RTG system with RTG screens is held in the graphics ram.

It's a bit more complicated than that. While I do not know how cybergraphics works, P96 tries to keep graphics data "on the board", but has no problem to off-load graphics data to fast RAM if on-board ram is getting tight. The native graphics system is not capable of doing that, i.e. any native bitplane will stay in chip RAM forever, no matter how tight it gets.

[guest11527]

Thomas - I did have one thing that I've always kind of wondered about though. Even on an RTG system, wouldn't Fblit still help for non-RTG screenmodes? For example, system-friendly games and apps that aren't promoted to an RTG screenmode (but use NTSC 640x200, for example)?

Likely, though it is not unlikely that it also conflicts with the RTG system (and some other stuff, too). Thus, for example, P96 "marks" its BitMap structure by a "magic word" to be able to tell "native" bitplanes from "RTG bitplanes" apart. This tagging may potentially conflict with FBlit and other hacks.

FBlit has also a couple of bugs, for example it writes into some custom chip locations that are not to be supposed to be written into, for example in its QSBlit patch. In specific, this causes screen corruption with third party hardware extensions like the Indivision. So all I can say is that would currently really not recommend such programs.

It would be much nicer to offer the same functionality through P96 which could, in principle, support the native chipset as a possible graphics output device as well. Unfortunately, this feature is currently not available.

[zipper]

Of course Fblit corrupts RTG - at least what I experienced ; freezes and corrupted windows. And Quake needs a patcher on 060 due to missing FPU instructions - without (MuRedox) the fps drops from about 15 to 5.

[utri007]

FBlit does make a huge dirrerence if hires interlaced modes are used, it increases screen scrolling etc a lot. It is nice to have pimped up workbench, without low chipram problems with whdload games.  

FBLit is now opensourced, so everyone capable can make fixes to it.
https://github.com/SamuraiCrow/fblit

Apollo accelerators read/write chip ram faster than other accelerators, that is done using some hacks. At least Jens S said something like that. Personally I don't know what but diffrence is noticeable.

[klx300r]

interesting thread as I can't get WHDload working at all on my 1200T, Apollo 060, Mediator setup and just wondering which, if any, of these patches mentioned might help or interfere with WHDLoad on my system?

-tried disabling the USB stack & various no cache, no mmu etc. but no go.

it's actually not a big deal for me as my 1200 desktop with 030 is amazing with WHDload, more curiosity then necessity for my 1200T

[Rotzloeffel]

interesting thread as I can't get WHDload working at all on my 1200T, Apollo 060, Mediator setup and just wondering which, if any, of these patches mentioned might help or interfere with WHDLoad on my system?

-tried disabling the USB stack & various no cache, no mmu etc. but no go.

it's actually not a big deal for me as my 1200 desktop with 030 is amazing with WHDload, more curiosity then necessity for my 1200T

If you REALY have the same WHDLoad setup on both machines then it sounds like trying to run PAL Games on an NTSC Machine... or vice-versa.. you could try the PAL tooltype to FORCE the screenmode ! the PAL Monitorfile must be in Devs:Monitors/

[klx300r]

If you REALY have the same WHDLoad setup on both machines then it sounds like trying to run PAL Games on an NTSC Machine... or vice-versa.. you could try the PAL tooltype to FORCE the screenmode ! the PAL Monitorfile must be in Devs:Monitors/

ah in fact you are correct in that my 1200T is NTSC and my desktop is PAL, I'll have a look at the PAL monitor tooltype in the 1200T?

[NorthWay]

Unless we get an official 1MB kickstart, I see little reason to support them.

So no joy if you manage to expand a CD32?

[Oldsmobile_Mike]

ah in fact you are correct in that my 1200T is NTSC and my desktop is PAL, I'll have a look at the PAL monitor tooltype in the 1200T?

Just put PAL in the tooltypes of the WHDLoad game. It helps some. I too, have problems with some games on my 2000 that work fine on my 500. Obviously much more expanded system, etc. Try disabling your TCP/IP stack and switching to a non-RTG screenmode before running the game. I've found those things can help, also.  

[utri007]

I used this guide, there is one mistake. http://www.mfilos.com/2010/12/guide-create-and-burn-custom-kickstart.html

DummyCDtrap is need with acceleratos wich has a MMU not just Cyberstorms. Other vice MMU blocks direct memory Access to extended 512kb part and make it slow.

There is some very nice points to have that kind of kickstart. Biggest advantage is with hard drives.