Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: XDelusion on July 10, 2012, 04:27:13 AM
-
I got my 80Mhz 060 back from Poland. It is quick as can be, but...
When ever I am in double scan mode or have another program like Ocamed ss open, the screen dragging process becomes slow and cumbersom.
Anyone know what causes this?
-
No one?
-
Need more info such as what Kickstart rev, what Amiga (A1200 I'm Guessing)
What Workbench? (3.1/3.5/9) if Classic Workbench did you turn off some of the installed patches like CyberBugFix (Which seems to cause havok on my machines)
Lastly, are you using correct 060 Libs (Apollo/Blizzard)
-
Sorry yes, first off I meant Window resize and not screen.
Secondly I am on a 1200, basic 3.1 install with the proper Apollo libs.
MCP and FBlit are the only additional Items I have loaded atm.
-
It's probably a setting in MPC, you can try disabling some options but I'm not familiar with MPC.
Also the Apollo's can be funny cards with some software/apps, I'm thinking there may be more to setting up the Apollo 1260 then just adding the 060 libs, some kind of CPU command needed in the SS IIRC.
I don't have an Apollo 1260 yet though, I have these fun & games to look forward to!
Hope you figure it out.
Steve.
-
Sorry yes, first off I meant Window resize and not screen.
Secondly I am on a 1200, basic 3.1 install with the proper Apollo libs.
MCP and FBlit are the only additional Items I have loaded atm.
Although a beefy 060 will make mincemeat out of anything living in FastRAM, ChipRAM is still as slow and awful as ever and double scan modes really hammer the available bandwidth for graphical operations.
-
Although a beefy 060 will make mincemeat out of anything living in FastRAM, ChipRAM is still as slow and awful as ever and double scan modes really hammer the available bandwidth for graphical operations.
Ya, but with a basic 3.1 install it should not be acting like this.
I'm going to tinker with MCP when I get home.
-
Double PAL/NTSC will use double chip bandwidth, so deeper screens (>16 colors) may become really slow, regardless of CPU speed.
Displaying a Double PAL (or Superhires) screen with 256 colors will use up ALL available bandwidth in the scanline. Any screen manipulation by CPU or blitter can only happen during the rather brief horizontal and vertical blanking periods.
-
Totally and utterly resolved!!! And now I'm in Hi-res Laced NTSC as well!!!! :)
The primary solution was to install BlazeWCP, but here's a full list of my system related software set up for those who may venture into ultra 060 land them selves some day. ;)
Hardware:
Amiga 1200
Modified Apollo 68060 (done by Stachu)
MIPS: 70.51
MFLOPS: 39.66
Software:
Workbench 3.1
BlazeWCP
MagellanII
CMQ060
FBlit
MagicMenu
MCP
FullPalette
HSMathLibs 060
Anything else anyone can suggest? So far, Quake aside, everything is running fast as hell!
-
Can you do a correct speed test for us using SysSpeed?
70.51 MIPS looks like a sysinfo result which is way off the mark for an 060 @ 80MHz :)
http://aminet.net/package/util/moni/sspeed26
P.S. I get 87.5 MIPS approx on my Apollo 060/66.
(Just double checked)
-
Not good!!!
I did use SysSpeed.
-
Here is a video that Stachu shot before he mailed the board back to me:
http://youtu.be/zsHqXdH3r9Y
The MIPS are higher in it, I just now noticed.
Def not good. :/
-
I would also recommend Exec 44.1 and FText. The former will require REMApollo (or perhaps loadmodule) or a custom kickstart.
Another idea, ditch the Apollo CPU library and use the one from the MuLib package on Aminet. It works fantastic with the Apollo cards, plus there are lots of other included tools that can speed things up a bit.
-edit- And definitely use SysSpeed, SysInfo if a steaming pile of , even on '030.
-
OK, so MCP and SYSPeed don't play well together.
With MCP I get the lower read out, without it I get:
MIPS: 104.27
MFLOPS: 42.05
Though without it BOOM runs like crap.
I presume MCP is working as it should and is only causing SYSPeed to produce an incorrect reading?
Here is the order in which our lord and savior Franko suggested for my startup-sequence:
Startup-Sequence order after setpatch:
C:Cmq060
C: blazeWCP
C:fblit
C:ftext
C:mcp
And I'm going to install patch control next.
BTW, my copy of Fblit must have been way out of date.
The archive I had was missing the GUI and Lib. Strange.
-
I got my 80Mhz 060 back from Poland. It is quick as can be, but...
When ever I am in double scan mode or have another program like Ocamed ss open, the screen dragging process becomes slow and cumbersom.
Anyone know what causes this?
If you had a Indivision MK2 or some other sort of flickerfixer. You could run in interlace mode which will be more than twice as fast. It is with Shapeshifter anyway... Interlace mode runs 1X mac quadra 950 speed where as multiscan mode runs about half that and seems to really drag...
-
Double PAL/NTSC will use double chip bandwidth, so deeper screens (>16 colors) may become really slow, regardless of CPU speed.
Displaying a Double PAL (or Superhires) screen with 256 colors will use up ALL available bandwidth in the scanline. Any screen manipulation by CPU or blitter can only happen during the rather brief horizontal and vertical blanking periods.
oops, already said... totally agree...
-
Just took a look at the 3.9 install for my Apollo, which I spent quite a bit of time fine-tuning a few years back.
One annoying thing with this card is that exec.library always ends up in chipram, which isn't optimal and slows things down a bit. You can get around this by using MuMove4k and MuFastZero from the MMULib (http://aminet.net/package/util/libs/MMULib) archive, and/or using Piru's exec44 loaded via RemApollo (http://aminet.net/package/util/boot/RemAPollo). The nice thing about RemApollo is that it's compatible with some of the excellent BlizKick (http://aminet.net/package/util/boot/BlizKick) modules. SpeedyIDE is useful if you're not using Doobrey's scsi.device or IDEFix. With my 80MHz Apollo, I was getting about 5 MB/s raw read with an IDE-Fix express, better than most '030 cards which are usually fastest due to better chipset access.
You can also use RemApollo to load some updated OS components (like Doobrey's patched scsi.device), or use ROMSplit and Remus to compile your own custom ROM with everything already added, then re-kick the ROM image with RemApollo, or burn it. And don't forget about TLSFmem.
Ultimately, if you're like me you can spend most of your time on the Amiga tweaking and benchmarking the OS, without actually using it to run programs or do anything useful. :-o
-edit- Though not strictly related to the Apollo, Peter Keunecke's icon library (http://aminet.net/package/util/libs/IconLib_46.4) is an absolute must-have IMHO. Speeds up icon loading tremendously, not to mention a ton of other great features.
-
OK, so MCP and SYSPeed don't play well together.
With MCP I get the lower read out, without it I get:
MIPS: 104.27
MFLOPS: 42.05
Though without it BOOM runs like crap.
I presume MCP is working as it should and is only causing SYSPeed to produce an incorrect reading?
Here is the order in which our lord and savior Franko suggested for my startup-sequence:
Startup-Sequence order after setpatch:
C:Cmq060
C:blazeWCP
C:fblit
C:ftext
C:mcp
MCP may patch over CMQ060's exec.library/CopyMem() and exec.library/CopyMemQuick() patches with much inferior code. There are some test results with how poor the CMQ CopyMem patches are for the 68060 here:
http://aminet.net/util/boot/CopyMem.readme
CopyMem060 is a little faster than Piru's new CMQ060 for the 68060:
http://aminet.net/util/boot/CopyMem.lha
MCP may interfere with or patch over other improved patches as exec.library/SetPatch() has no way of preventing or arbitrating new patches from patching over the same functions. The newer MCP versions are for UAE and the older ones are outdated. It's nice to have all the patches in one that can be selectively enabled and disabled but MCP isn't worth the trouble anymore in my opinion.
-
RemApollo says I have the wrong version of the 060 Lib. Where do I get the right one?
-
RemApollo says I have the wrong version of the 060 Lib. Where do I get the right one?
You need 68060.library v60.10 by Z. Urwani. First you need the Apollo060.dms (http://www.l8r.net/install/accel/apollo060.DMS) archive which contains v60.02 of the library. Then you need the 68060 patch from the RemApollo (http://aminet.net/util/boot/RemAPollo.lha) archive to update to the final v60.10 version.
-
RemApollo says I have the wrong version of the 060 Lib. Where do I get the right one?
You need 68060.library v60.10 by Z. Urwani. First you need the Apollo060.dms (http://www.l8r.net/install/accel/apollo060.DMS) archive which contains v60.02 of the library. Then you need the 68060 patch from the RemApollo (http://aminet.net/util/boot/RemAPollo.lha) archive to update to the final v60.10 version.
@ XDelusion
No thanks, huh?! People are so ungrateful these days. Don't ask for help next time, dude!
:madashell:
-
@ XDelusion
No thanks, huh?! People are so ungrateful these days. Don't ask for help next time, dude!
:madashell:
Sorry?
Been busy man, have not had a chance to get back to this till now. Will post my results.
Thankx! ;)
-
You need 68060.library v60.10 by Z. Urwani. First you need the Apollo060.dms (http://www.l8r.net/install/accel/apollo060.DMS) archive which contains v60.02 of the library. Then you need the 68060 patch from the RemApollo (http://aminet.net/util/boot/RemAPollo.lha) archive to update to the final v60.10 version.
Anyone know Z. Urwani ?
I found a big bug into ex_afterUser_060 : it's not jsr but jmp
If anyone know this guys, please, send him this message. Thanks !
-
Anyone know Z. Urwani ?
I found a big bug into ex_afterUser_060 : it's not jsr but jmp
If anyone know this guys, please, send him this message. Thanks !
Is this bug causing big poblems? Because i don't have any issues with this library.
My A1260/80Mhz system is running stable for a couple of years now.
-
For me, it's a big bug : the routine previously pointed by a5 will run one time again, and in no-supervisor mode...
-
68060.library fixed : http://leblogdecosmos.blogspot.fr/2012/08/68060library-apollo.html
-
Alright, I am moved into my new home and back at this again.
I received my MKII in the mail yesterday so I decided to celebrate by giving OS 3.9 another go.
Well I installed 3.9 on 4 PFS formatted partitions. I installed both Boing Bags and just now tried to install FBlit again.
I put "C:FBlit"
In the line directly above BIND Drivers
But as fate would have it, start up tells me that FBlit is not an executable. Also when I double click it in within WB, nothing happens. No config menu, nothing.
Likewise, I installed Sysspeed, but it will not load either.
-
But as fate would have it, start up tells me that FBlit is not an executable.
That's an easy one to fix, just find FBlit in your C folder and change it's attributes to executable.
Are you using RemApollo yet, that made the biggest difference to my system.
-
This is an interesting thread, I've got the same setup and of course I'm always chasing more speed.
Things I want to try out:
Piru's exec44 (using RemApollo)
Cosmos 8060.library
Also what is the best 060 library to use for example I also wanted to give MuLib package on Aminet and try but I thought you had to use the patched v60.10 library with RemApollo?
-
That's an easy one to fix, just find FBlit in your C folder and change it's attributes to executable.
Are you using RemApollo yet, that made the biggest difference to my system.
Nova: Just saw your post here:
http://eab.abime.net/showthread.php?p=493925
If I set it to executable, it will shut it up during boot time, but I still can not double click it and launch it (just like SysSpeed), and if I try to execute it via CLI it will tell me it is not an executable there as well.
-
Nova: Just saw your post here:
http://eab.abime.net/showthread.php?p=493925
If I set it to executable, it will shut it up during boot time, but I still can not double click it and launch it (just like SysSpeed), and if I try to execute it via CLI it will tell me it is not an executable there as well.
Hiya,
Yep like I said it's not setup correctly when you install it (don't know why), you have to find the program in you C folder (using WB) then click on it and open up the information and tick the executable attribute.
Don't try and execute FBlit by double clicking on it, just stick it the startup like I have my version I sent to you and you should be all good.
BTW, I don't think you should install MCP or BlazeWCP.
-
I have done this, but from what I understood you are supposed to launch FBlit at least once via Icon so that you can open up the config menu and save your config file to ENV.
Anyhow, now that FBlit is set as Executable, I tried to load it via CLI and it tells me that FBlitGUI is not an executable. If I set it to Executable and try to run FBlit via command line, I get a Reboot or Suspend option.
ALso I don't think FBLit is working (even though setting it to Executable made it stop complaining at boot time) because my memory is not freeing up yet.
Hiya,
Yep like I said it's not setup correctly when you install it (don't know why), you have to find the program in you C folder (using WB) then click on it and open up the information and tick the executable attribute.
Don't try and execute FBlit by double clicking on it, just stick it the startup like I have my version I sent to you and you should be all good.
BTW, I don't think you should install MCP or BlazeWCP.
-
Hmmm, it must be working cause FText seems to be working.
Strange, I seem to recall having more memory left after a basic install. Nothing else has been included at startup yet.
And I forgot that SysSpeed requires MUI, that's why it isn't working.
Back to Fblit though, isn't it supposed to have an extra file that goes into prefs?
-
MCP, BlazeWCP, fblit, ftext modify major system functions and can conflict with one another. Back in the day I spent ages with them, I've forgotten more than I remember but there is a lot of guess work in order to get a stable system when patching things like this. Thats the trade off for a faster system.
In the end I actually wanted my A1200 to work without feeling I'm playing Russian roulette, and I just used the latest 060 library and the HSmathslibs, with reduce colors and resolutions.
-
MCP, BlazeWCP, fblit, ftext modify major system functions and can conflict with one another. Back in the day I spent ages with them, I've forgotten more than I remember but there is a lot of guess work in order to get a stable system when patching things like this. Thats the trade off for a faster system.
In the end I actually wanted my A1200 to work without feeling I'm playing Russian roulette, and I just used the latest 060 library and the HSmathslibs, with reduce colors and resolutions.
I have ditched most of those, now I'm trying to use a Drap, RemApollo, HSMathLibs 060, CPU60, CMQ060, FBlit, FText, Visual Prefs, FPPrefs, combo. Having much trouble thus far.
-
I have the Apollo 68060 card as well. It can take a long time working out what works and what doesn't. IMO too long.
My advice to anyone starting on a fresh system would be to get one of the classicWB packs which has many of these patches already installed and playing well with each other, in addition to a bunch of other utilities you didn't think you needed but you find indispensibe later.
OFF topic: why when I login I do log in for an instant but then get I the vBulletin login page saying I'm not loggged in. I can't quote posts, but can reply like I am now.
-
I have ditched most of those, now I'm trying to use a Drap, RemApollo, HSMathLibs 060, CPU60, CMQ060, FBlit, FText, Visual Prefs, FPPrefs, combo. Having much trouble thus far.
Hiya probably best to setup your system in this order (obviously check that everything is working for each stage):
1) Install PFS3 (060)
2) Install 3.9 + BB1 & BB2 (do not install BB3/BB4)
3) Install basic RemApollo + Drap
4) Start adding modules to RemApollo (eg updated System libraries, Blizkick modules, HSMATH LIBS)
5) Install any other patches you need (as few as possible), (eg FBlit, FText etc).
-
Hiya probably best to setup your system in this order (obviously check that everything is working for each stage):
1) Install PFS3 (060)
2) Install 3.9 + BB1 & BB2 (do not install BB3/BB4)
3) Install basic RemApollo + Drap
4) Start adding modules to RemApollo (eg updated System libraries, Blizkick modules, HSMATH LIBS)
5) Install any other patches you need (as few as possible), (eg FBlit, FText etc).
Getting there slowly but surely. I'm already seeing speed increases and I'm getting more and more memory back, sadly BOOM no longer works for me. Hasn't since I first installed OS 3.9. :/
-
Nova: How did you go about installing your HSMathLibs 060? I noticed in the example you sent that you used it as a Module...
That aside, I am now able to use your Starup-Sequence. ;)
Now to get BOOM working again...
...the whole point of doing this in the first place.
-
This is an interesting thread, I've got the same setup and of course I'm always chasing more speed.
Things I want to try out:
Piru's exec44 (using RemApollo)
Cosmos 8060.library
Also what is the best 060 library to use for example I also wanted to give MuLib package on Aminet and try but I thought you had to use the patched v60.10 library with RemApollo?
No, the MULib package replaces the Apollo 68060.library (or Blizzard for that matter), so it's not needed at all. I've used MuLib package for years and I can highly recommend it.
I haven't tried the exec44. Can I use that with Workbench3.1? Or is it OS3.9 only? What kind of a speed gain could I expect with Piru's exec anyone?
-
Hiya,
Had a play with all of this last night.
Tried the MMU libs 060 (+mmu.library), seem to be stable but they also seemed to run Quake slower than than standard (patched) Apollo libs, also not sure how compatible it is with RemapApollo. I might still try to use them to create a 3.1 boot floppy to run some demos that don't seem to get on with my standard 3.9 setup.
I also built the exec v44.1 but it only comes as a 3.1 complete rom image (which you can't seem to split for some reason), this is no good for me because I'm running RemapApollo with 3.9 and patching the built in 3.1 rom image with the Boing bag updates (loaded as modules). I'm not even sure if it's such a great idea to run v44.1 exec.library if you are running 3.9.
I updated my CopyMem 060 patches to the faster version listed in this thread. This didn't effect the frame-rate in Quake though, even running without any memory copy patches doesn't seem to have any real-world effect?
Also tried Cosmos's updated Apollo 060 library, so far no problems with it and it's maybe a little bit quicker too.
Didn't try the updated memory allocation routines from Chris Hodges (also mentioned in this thread) because it seems that they are less useful if you are running 3.9 + bb2 (which has updated memory allocation code).
-
Tried the MMU libs 060 (+mmu.library), seem to be stable but they also seemed to run Quake slower than than standard (patched) Apollo libs, also not sure how compatible it is with RemapApollo. I might still try to use them to create a 3.1 boot floppy to run some demos that don't seem to get on with my standard 3.9 setup.
With the Mu 68060.library I use this line in my S:Startup-Sequence
MuFastZero MOVESSP ON
This makes the Mu 68060.library a little faster (instead of a little slower) than most other 68060 libraries. It is less compatible with a few very old programs.
I also built the exec v44.1 but it only comes as a 3.1 complete rom image (which you can't seem to split for some reason), this is no good for me because I'm running RemapApollo with 3.9 and patching the built in 3.1 rom image with the Boing bag updates (loaded as modules). I'm not even sure if it's such a great idea to run v44.1 exec.library if you are running 3.9.
Piru's exec.library is missing some functions that are necessary for AmigaOS 3.9.
I updated my CopyMem 060 patches to the faster version listed in this thread. This didn't effect the frame-rate in Quake though, even running without any memory copy patches doesn't seem to have any real-world effect?
CopyMem060 isn't much faster than CMQ060. The only time the speed difference might be noticeable would be a lot of small copies in a short amount of time. You do save a little memory over CMQ060. The patch is worth running on a 68060 over the AmigaOS 3.9 copy functions. If you want to "see" the difference, scroll around in a newer version of AWeb with and without CopyMem060 installed ;).
If you have a Warp3D compatible gfx card, let me know. I have some patches that will speed up GLQuake by a few frames. You might try MuRedox/OxyPatcher with other Quakes and see if it's any faster.
-
Cool, thanks for the info :)
Nope no GFX card for me, I've only got AGA and I'm running my own port of Quake.
-
Cool, thanks for the info :)
Nope no GFX card for me, I've only got AGA and I'm running my own port of Quake.
Nova: Do you recall what steps you took installing HSMathLibs? RemApollo isn't mentioned during the install process. Do I choose the Blizzard option then just patch the Modules? I can't seem to run RemApollo with the ones you supplied me so I'm trying to install them my self. Currently I have HSMathLibs installed using the default method.
-
Nova: Do you recall what steps you took installing HSMathLibs? RemApollo isn't mentioned during the install process. Do I choose the Blizzard option then just patch the Modules? I can't seem to run RemApollo with the ones you supplied me so I'm trying to install them my self. Currently I have HSMathLibs installed using the default method.
It took me a few goes to get it right, I remember that much ;)
I think I went for the 'other' option then copied them manually. I'll have a look when I get a second to see how I did it if you like.
-
It took me a few goes to get it right, I remember that much ;)
I think I went for the 'other' option then copied them manually. I'll have a look when I get a second to see how I did it if you like.
I'd be curious to know before I start tinkering around. ;)
If you got the time, otherwise I can always back up my system and start experimenting.
THankx!
-
I'd be curious to know before I start tinkering around. ;)
If you got the time, otherwise I can always back up my system and start experimenting.
THankx!
Ok in system/libs
mathieeedoubbas.library
mathieeedoubletrans.library
mathieeesingtrans.library
mathtrans.library
Then in my devs/modules folder (ie the ones that are loaded by RemapApollo)
mathftp.library
mathieeesingbas.library
To check everything is ok, run Sysinfo and check that all of the following are in CHIPRAM (and have the correct version numbers)
mathieeesingbas.library
mathftp.library
mathieeedoubbas.library
mathieeedoubletrans.library
-
Hiya,
Had a play with all of this last night.
Tried the MMU libs 060 (+mmu.library), seem to be stable but they also seemed to run Quake slower than than standard (patched) Apollo libs, also not sure how compatible it is with RemapApollo. I might still try to use them to create a 3.1 boot floppy to run some demos that don't seem to get on with my standard 3.9 setup.
I use this in my startup-sequence regarding the MuLib package:
MuMove4K PREPAREEMUL A1200
SetPatch QUIET
PatchRAM PORTPATCH
PoolMem INSTALL >NIL:
MuFastZero ON FASTEXEC MOVESSP=FASTSSP
MuFastRom
MuRedox
ConsoleFix
ConFix
The MuRedox part is equivalent to oxypatcher or cyberpatcher. I'm 3.1 though so I wouldn't know what 3.9 would need regarding the other stuff.
I'm sure I had better speed with MuLibs, or I wouldn't have used them. I may take another look at the Apollo library though being as though it's been updated recently.