Temporary turning FAST memory off
 

Hi,

is there a way to turn off FAST memory so the system can't allocate it any more apart from this very common technique?

If I do it this way, it's a one-way street. The FAST memory is irreversible lost. I want a solution like NoFastMem of the WB 1.2/1.3 does. Switching FAST memory off and on again.

Does anyone know a smarter way in assembler?

Start with an empty list
If list empty get all memory and store memory pointers to list
if list not empty, walk list & free all list memory pointers

Even easier: store all address/size pairs in first (largest) allocated block.

Thanks alkis&Toni. :) I will try this. I hope that the first largest memory block is large enough to save all address/size pairs.

Why not patching AllocMem() and AvailMem() and let them simply return zero to all FastMem requests?

OS internal memory allocations may bypass LVO calls and call internal functions directly and AllocMem() is not the only memory allocation function.

IMHO LVO patching should be only used if there is no other cleaner solution.

Ok, it depends on what you want to keep off from getting FastMem. And yes, of course, there are also Allocate(), AllocPooled(), AllocAbs() and AllocVec(). The latter calls AllocMem(). Don't know what the other functions are doing, whether they are based on AllocMem() too or not.

But I just had a short look into the disassembler listing of NoFastMem, which could be easily integrated into other programs. NoFastMem patches AvailMem() and AllocMem(), maybe in a little bit different way, but it's going into the same direction.

On the other side, when you are trying to allocate all available FastMem blocks you are never finished with that task, because at any time other programs may set their used blocks of FastMem free again, and then you will get into a race condition with those which want to allocate these new FastMem blocks.

Why not using NoFastMem itself ?
From within a program it should be easy to call Execute() or a similar function.
If it doesn't work on pre 2.0 then it can probably be adapted.

Hi PeterK, the code below works fine. The loop allocates all FAST memory:

But you are right, there's one disadvantage regarding the multitasking environment. If a program was opened before my routine allocated all FAST-memory and is quit before I release my allocated FAST-memory, there will be available FAST memory again. Turing off the multitasking via Forbid() and Permit() maybe useful only in very special cases.

My idea is to patch the memory-list at the pointer Exec-Base->MemList. Just removing the node of FAST memory out of the memory list with Remove() and inserting it again with Insert(). But this could be dangerous, because it's a private structure and could mess everything up.

Right, I forgot that problem.. There does not seem to be any nice and simple solutions.

It should work until someone tries to free memory that was allocated from removed node.

Hi meynaf, I've tested it on a WinUAE-68060 config. NoFastMem also works with KS 3.1.

Yes, using it via Execute() could be a solution, but then my program would require the pre OS2.0 NoFastMem in a OS 2.0+ environment.

Yes, I really had the same idea, so this can't be the solution. It's too complex and dangerous messing up this list.

I think that some bootblocks can do that. Turn off memory and floppy drives. And some could switch PAL/NTSC.

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 :D).


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.

Right, dependent what he want to do. If he want to load exe files to chip ram, he can modify hunks to load into chip ram. If he want to disable Alloc fast mem, he can alloc full Fast at begining and nothing will be loaded/allocated to fast mem.

This.

It patches AvailMem to never report the fast mem (which stays unallocated), and patches AllocMem to clear the bit of FAST_MEMORY and always return CHIP_MEMORY.

Yes, I know such bootblocks. Often you have a menu there to select PAL/NTSC mode or turn off FAST memory. I didn't check such a bootcode yet, but I guess FAST memory is turned off like the first code I posted. As this routine is called before any CLI window is opened and the bootroutine is a main routine, there can't be much other routines releasing their allocated FAST memory after FAST memory was turned off.

I fail to see any good use for that in a bootblock. :confused

If you're running your own code, it's a magnitude simpler to just pass the correct flags to allocmem calls in order to get chipmem.
And if it's not your own code that runs after, patching it shouldn't be that hard either.

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.


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. :D

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.

Yes, modifying the hunks could be a solution, but fails, if the exe file itself allocates memory not correctly and doesn't request CHIP memory in particular. To be honest, modifying hunks is not something I've done yet. :confused

Yes, you got it. That's exactly what I will do.