Just in case of confusion. FastIPrefs is optimized by H.-W.Schober in 1997.

Yes ok, but it's not capable to do the job of IPrefs under OS 3.5+. It cannot handle the new preferences format of OS 3.5 or 3.9, no matter if it's perfectly optimized or not.

Of course FastIPrefs is for OS3.1.

Hello PeterK, sorry for late reply.

file versions:
icon.library 46.4.228 - 26660 bytes (31.3.2012 07:40)
workbench.library 45.131
datatypes.library 44.48
picture.datatype 45.17
png.datatype 45.16 (WarpPNG)
PICASSO96:
Picasso96API.library 2.310
emulation.library 40.395
fastlayers.library 40.48
rtg.library 40.3992

Setpatch 44.38
IPrefs 45.13
exec.library 45.20
graphics.library 40.24 (in ROM)
dos.library 40.3 (in ROM)

With latest icon.library 46.4.240 icons display slowly and chipram is used. I use DOpus 4. It gives me this error message:

"Directory opus request:
unable to open screen/window"

and then it opens a screen in PAL low res mode with 2-colors or 4-colors (chipram is used up).

EDIT: attached Startup-sequence & User-startup. also tested with icon.library 46.4.233 and 46.4.235 and it also eats chipram.

Hello Bamiga2002,

your configuration looks quite reasonable. I can't find an obvious bug, but I will check that in detail on my WinUAE system.

Atm, I can only see two things, which you should change:
Please, remove icon and workbench from this line, because they don't belong to the DEVS:AmigaOS ROM UPDATE.
Second change: You are using two lines: Stack 4096, but no MinStack or StackAttack instruction. A stack of 4000 is the system default anyway, and two Stack instructions with the same argument won't make much sense.

But much more important, the Stack instruction has only an effect on the commands in your startup-sequence and will not prevent stack overflows after booting has finished. The default stack of 4000 is much too low for programs, tools and libraries. Please, insert a line with MinStack 10000 after SetPatch.

And please delete 46.4.233, it was buggy !

It would also be nice, if you could check the attributes of your memory chunks. Is the FastMem PUBLIC, which priority has it, and which priority has the ChipMem ? You can use SysInfo or similar tools like ShowConfig.

Maybe, this could help in case that the workbench.prefs are broken? Delete the workbench.prefs from ENVARC:sys and from ENV:sys and then use Sys:Prefs/Workbench, set the memory type to "other memory" and save it. Remove the WBCtrl IMT=IconFast from the startup-sequence and reboot (Hardware Reset).

Btw, what happens if you execute IconsToFastMem from a shell after booting ?
And, what happens with the original icon.library 45.1 ?
What are your PicassoVS settings ?

hiya Peter,

I just started using v46.4 with my 3.9 install and so far everything is working nicely, thanks for your efforts :)

Done.

OK I have changed this, removed the stack-lines and put "MinStack 10000" right after Setpatch.

Done! ;)

Checked with Scout, Sysinfo and Showconfig.
FastMem starts at $78000000 and hasn't got any in-name/node. Scout says <none> in Memory/in-name column and Sysinfo displays plain empty. ShowConfig does display "FAST" so it's recognised. FastMem has priority of 40.

ChipMem is flagged as "chip memory" by both Scout/SysInfo and has priority of -10.

Tried this, no help...

IconsToFastMem seems to do nothing for me, memory runs out even if it is ran.
Original 45.1 icon.library works like it should - fastram is used. Although it's slower than 46.4.228 ;)
I attached my P96-variable settings as file.

Hello Bamiga2002,

what are the "attributes" for your FastMem in Scout or ShowConfig or is there a the keyword PUBLIC in SysInfo ?

SysInfo:
"memory type: 32BitRAM PUBLIC KICK"

Scout mem attibute: $0405

IconsToAnyMem didn't seem to help here.

note: sometimes when I coldstart/reboot the miggy the icon.library works normally, sometimes not. strange. haven't been able to isolate what causes this.

Did you copy any PNG-icons into DEVS:monitors ?

are you runnung out of FastMem, too ?

No, there are only normal icons for monitor-files:
Additional info from Scout, memory attributes for FastMem:

MEMF_ANY=$0000
MEMF_PUBLIC=$0001
MEMF_FAST=$0004
MEMF_KICK=$0400

How much FastMem is free ?
For me, it looks as if your FastMem is not available or not properly recognized by the system.

You could try to insert a WAIT 2 above IPrefs

Added "Wait 2". Free fast ~ 119-119.5Mb right after WB has loaded up and ~1.6Mb free chip.
With this IconsForceFastMem some icons revert to WB-default ones, eg. DOPUS 4 yellow icon changes to gray hammer (default). Chip mem is eaten up anyway.

I deleted workbench.prefs, rebooted, library working fine -> rebooted, chipram eaten again. It seems to randomly work.

That means that the icon.library doesn' get any FastMem for the planar images. I've no idea why not.
What says Avail FLUSH ?

You could also try to load the iconlib and wblib by SetPatch instead of LoadModule. In this case remove the DISABLEROMMODULES ""

The SetPatch way didn't work either, same results.
Avail FLUSH gives otherwise normal results BUT "Largest" in fastmem is displayed "0". With icon.library 46.4.228 it is almost ~120Mb.

Ok, I'm gonna try to make a modification in the icon.library now. It may take a few minutes...

Removed.

Thanks that was fast! :)
Will test this version as soon as I get back home.

Don't know if this version could help, but I've no better idea atm.

I'll give it a go ofcourse then we'll see :)
I wonder if anyone else with a BPPC has this same problem...

Just tried v241 and the problem's the same. Tried with IconsForceFastMem and WBCtrl, no help. Is there something specific I need to check here?