Temporary turning FAST memory off

[dissident]

Originally Posted by alkis

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.

Good work, alkis. So the patching could have done with SetFunction(). Just a short own header-routine to change the memory request passed over in D1 and then run the original AllocMem() function. This patch could be removed easily by resetting the LVO to the original routine.

[meynaf]

Originally Posted by dissident

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.

If the exe file itself allocates memory not correctly, then it's a matter of patching it - something you already do for other reasons. Find calls to exec allocation functions and add the flag.

For altering the executable's header with a chipmem flag, it's not as complicated as it looks.
Get number of hunks at +8. Each one has a size longword, they start at +$14. Replace first byte (which is $00) with $40 and you're done.

Usually old intros will be single hunk and don't perform allocmems so that's a single byte to change. Don't use a tank to go shopping .

[dissident]

So, I guess, I've got a solution for my case. I tend to use the second code I posted. If it isn't enough, I will patch AllocMem(). Modifying hunks is too complex for me at the moment, but I will keep this in mind.

Thanks everyone for your good ideas and hints. As usual, I've learned something.

[dissident]

Originally Posted by meynaf

If the exe file itself allocates memory not correctly, then it's a matter of patching it - something you already do for other reasons. Find calls to exec allocation functions and add the flag.

For altering the executable's header with a chipmem flag, it's not as complicated as it looks.
Get number of hunks at +8. Each one has a size longword, they start at +$14. Replace first byte (which is $00) with $40 and you're done.

Usually old intros will be single hunk and don't perform allocmems so that's a single byte to change. Don't use a tank to go shopping .

Hmm, modifying the hunks seems not so complex as I thought. It will try this. Thanks for the hints, meynaf.

[Toni Wilen]

If you use LoadSeg() and want to make this more complex and more interesting: use InternalLoadSeg(), it uses caller defined alloc/free functions..

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

You need to re-insert the entry (node) in correct position. Forbid() + Remove() + Enqueue() + Permit().

Memory allocator scans nodes one by one until it finds entry that succeeds in memory allocation. It does not care about priority field.

[Hedeon]

Originally Posted by Toni Wilen

Memory allocator scans nodes one by one until it finds entry that succeeds in memory allocation. It does not care about priority field.

That is why normally you would Enqueue() the memory node so it gets inserted based on priority. The list indeed gets searched from top to bottom.

So why not just Remove() memory with FASTRAM attributes from the MemList?

[Toni Wilen]

Originally Posted by Hedeon

That is why normally you would Enqueue() the memory node so it gets inserted based on priority. The list indeed gets searched from top to bottom.

Oops, I meant Enqueue().

So why not just Remove() memory with FASTRAM attributes from the MemList?

It was already mentioned: if something (some other process, or OS internal allocation) decides to free memory that was originally allocated from fast ram: crash..

[StingRay]

Originally Posted by meynaf

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

Such bootblocks were often used for game/demo compilations and allowed to run stuff which didn't work with fast memory.

[Hedeon]

Originally Posted by Toni Wilen

It was already mentioned: if something (some other process, or OS internal allocation) decides to free memory that was originally allocated from fast ram: crash..

Meh, me and my lame quick thread scan skills. And you're right of course about the crash. Mem header not found.

[sigma63]

Originally Posted by meynaf

For altering the executable's header with a chipmem flag, it's not as complicated as it looks.
Get number of hunks at +8. Each one has a size longword, they start at +$14. Replace first byte (which is $00) with $40 and you're done.

There was already a CLI-Command for that purpose called ATOM.
It was part of assemblers/compilers in these good old days .

If you need, i can look for it.

Cheers

[dissident]

Originally Posted by Toni Wilen

If you use LoadSeg() and want to make this more complex and more interesting: use InternalLoadSeg(), it uses caller defined alloc/free functions..

I will keep this in mind. A good hint.

Originally Posted by Toni Wilen

You need to re-insert the entry (node) in correct position. Forbid() + Remove() + Enqueue() + Permit().

Memory allocator scans nodes one by one until it finds entry that succeeds in memory allocation. It does not care about priority field.

This is really interesting and confirms the system's list handling. Every node points to its predecessor and successor. So to insert a node at the head of the list, AddHead() could be used. Or AddTail() to append a note to the tail of the list I guess.

[dissident]

Originally Posted by sigma63

There was already a CLI-Command for that purpose called ATOM.
It was part of assemblers/compilers in these good old days .

If you need, i can look for it.

Cheers

I would be interested in that tool.

[Don_Adan]

Originally Posted by dissident

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.



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

For LoadSeg this is very easy job to do. I used hunks modification for one player, i dont remember exactly if i forced this exe player to load to chip ram ($00 to $40) or to load to fast/any ram ($40 to $00) for save some chip ram memory.

Ok. perhaps it was Amplifier version for EaglePlayer 2. For save chip ram. If FastLoading in EP2 was enabled.