Quote:
Originally Posted by meynaf
Less dangerous than removing the entry, would be to set priority so that chipmem is allocated first. Then, no fast mem unless the system runs out of chip.
(But don't ask me how to do that, i've tried to change priority of the mem nodes and it didn't work  ). |
Yes, I already had the same idea, changing the priority of the node. This could be done this way by the old tool SlowMemLast of WB 1.2. Or they also patched the AllocMem() function.
Quote:
Originally Posted by meynaf
Normally in a 2.0+ environment, NoFastMem should be available somewhere, like sys:system/NoFastMem.
Then again, it all depends why you want to remove fastmem from the system.
What does your program do ? What is the final goal ?
Perhaps better solutions exist than just removing the fastmem.
|
I've checked it. On the WB 3.0 disc NoFastMem is still in the system drawer. Funnily I didn't expect this and though didn't check it.
Sorry, that I didn't mention it. What I intended to do is loading executable files with LoadSeg(). These files should not be loaded into FAST memory, because it is most likely, they were coded on a machine without extra memory and the coder didn't expect there will be such like in old intros/demos. So FAST memory must be turned off before. After some system modifications, the code of the file is executed. But if any error occurs during my modifications or the file can't be loaded, I have to free the allocated FAST memory and exit my program.
To my mind, I already have a solution that is not too complicated with the second code I have posted.