SetPatch is hungry!

[saimo]

Hi all,

can anybody explain me why SetPatch (the correct one in the OS3.9 CD) steals ~700 kb of CHIP RAM?
My settings aim to store as much stuff as possible to FAST RAM.
My machine is an A1200+Bz1230+16Mb RAM+AOS3.9 etc...

Thanks in advance,
Saimo

[blobrana]

Certain commands are on the ROMS (read only) but any tweaks or improvments have to be witten to memory, almost like a kickrom program...

I suppose that they could have made it to look for fast mem first...But if you see any tasks that use buffmem type=3,
you could change it to
Buffmemtype=5,  - to use fast mem. :-D

[420Dude]

sETPATCHs got the "munchies"! :-P  :-D  ;-)

[Duncan]

Your fast memory is probably not tagged as MEMF_KICK, and
is not used by setpatch. try the AVOIDMEMFKICKFORPATCHES
option.

Duncan

[saimo]

First of all, thanks to everybody who has answered.
I must correct myself, as I've posted vague and false information.
These are the correct ones:

When I switch the Amiga the mounted memory is:
 - CHIP RAM:  2096128 bytes (~2 Mb)
 - FAST RAM: 16252928 bytes (15.5 Mb - this is correct as I have the FASTROM
             jumper set on the Bz1230)

So the memory is detected correctly.

At this point, "Avail FLUSH" returns that 77152 bytes of CHIP RAM and
675320 bytes of FAST RAM are "In-Use" (how come that so much FAST is used?!?
*What* uses it?!? - please note that I've just turned the machine on and
that I have booted *without* startup-sequence).

Then, these first lines of my startup-sequence are executed:

 C:SquirrelSCSI
 ;C:LoadModule L:Shell-Seg L:RAM-Handler NOREBOOT
 ;C:SetPatch SKIPROMUPDATES=shell,ram-handler QUIET
 C:LoadModule L:RAM-Handler NOREBOOT
 C:SetPatch SKIPROMUPDATES=ram-handler QUIET

Execution goes as follows (variations of "In-Use" memory indicated in
brackets) :

 1. C:SquirrelSCSI is executed
     - used CHIP: 77152

     - used FAST: 703632 [+28312]
     (at this stage, nothing to say)

 2. C:LoadModule L:RAM-Handler NOREBOOT is executed
     - used CHIP: 117176 [+40024]
     - used FAST: 703632

     (why does LoadModule use CHIP RAM?)

 3. C:SetPatch SKIPROMUPDATES=ram-handler QUIET is executed
    and the system re-boots
     - used CHIP: 236608 [+119432]
     - used FAST: 676168 [-27464]
     (values have been taken immediately after re-booting without
     startup-sequence; why does SetPatch use CHIP RAM?)

 4. C:SquirrelSCSI is executed again
     - used CHIP: 236608

     - used FAST: 704480 [+28312]
     (at this stage, nothing to say)

 5. C:LoadModule L:RAM-Handler NOREBOOT is executed again
     - used CHIP: 236608

     - used FAST: 704480

     (at this stage, nothing to say)

 6. C:SetPatch SKIPROMUPDATES=ram-handler QUIET is executed again
     - used CHIP: 236608

     - used FAST: 739176 [+34696]
     (at this stage, nothing to say)

As last note, here are the versions of the programs involved:

 - SquirrelSCSI 39.44 (04/26/1996)
 - LoadModule 40.9 (08/11/2002)
   © THOR
 - setpatch 44.38 (03/08/2002)
 - BoingBag #2 installed



Please enlighten me!

Thanks & bye!
Saimo

[Thomas]

Reset proof modules need reset proof memory. Some A1200 accelerators do not provide reset proof memory and so chip ram has to be used for reset proof modules.

As stated before SetPatch can be forced to use fast ram by the AVOIDMEMFKICKFORPATCHES option. Don't know if similar options exist for other programs.

You should avoid to use reset proof modules: remove the LoadModule entry and delete the Devs:AmigaOS ROM Update file.

The other solution would be a patch which flags all fast mem as memf_kick (if it is reset proof but not flagged correctly). Don't know if such patch exists and don't know either if your fast mem is reset proof.

Bye,
Thomas

[saimo]

Thanks for the info.
I will try the AVOIDMEMF... flag, but I'm not gonna delete del ROM updates... I guess the cure would be worse than the problem.

I'd bet my memory is reset-proof, as it always retains information after a reset (f.ex., when I need to force the system to re-install the memory updates, I need to explicitly tell SetPatch to do it with KILLUPDATES).

Yet, it's still a mistery the fact that as soon as I turn the Miggy on 0.5+ Mb of FAST RAM are already in use (I'm talking about switching the power on even after *hours* of rest).

Regards,
Saimo

[Duncan]

Don't forget you can also force LoadModule to use
your Fast memory. Just use the NOMEMFKICK option.

Duncan

[saimo]

OK, I'll try.
Many thanks to you, too.
I'll let you know tomorrow.

[Thomas]

I'd bet my memory is reset-proof, as it always retains information after a reset (f.ex., when I need to force the system to re-install the memory updates, I need to explicitly tell SetPatch to do it with KILLUPDATES).

You observed that your reset-proof modules go into chip memory and now you argue that your fast mem is proof because your modules (in chip mem) survive a reset ? Funny.

Bye,
Thomas

[saimo]

You are perfectly right, I said a stupid thing.
Yet, as for the rest-proof memory, I'm quite sure as this is what the behaviour (in general) of my system suggests.
Anyway, yesterday, back at home, I've checked my FAST RAM flags and yes, you guys were right: it is not marked as "KICK". Nevertheless I tried using the flags you suggested and everything seems to work fine and finally I have spared some CHIP RAM.
Lastly, as for the massive use of FAST RAM right at the boot, I think it is due to the buffers reserved by the SmartFilesystem.