Good work, alkis. :great 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.

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

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. :bowdown As usual, I've learned something. ;)

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

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

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.

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?

Oops, I meant Enqueue().

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

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

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

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

If you need, i can look for it.

Cheers

I will keep this in mind. A good hint.

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.

I would be interested in that tool.

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.