...
Before allocating memory, the user application has to know in which bank the requested memory area is located. OS_Fma provides that job with plenty of options. An even bank number can be requested since segment 0 can only be allocated with such banks. Remember that if an odd RAM bank is bound to segment 0, the upper half of the previous even bank will be bound to $2000-$3FFF (an even bank number is bound to $2000-$3FFF with lower half of that bank). A fixed memory (not subject to swapping) can be requested, this is useful if your application is not a popdown and does not release this memory when suspended. An explicit slot can be specified or any of them letting routine scan all slots for requested memory. If successful, the bank number is returned in B.
...
Several allocations (with both calls) can be done under the same memory handle, thus user the application should keep a track of explicit address and length for future release of the memory. To get more memory (contiguous to previous or not), OS_Fma can be called again many times after previous allocation (with different options). In conclusion, it is possible to allocate under the same memory handle several large area in different banks.
...
Memory release is really flexible. It is provided by OS_Fxm with bank, page offset and length specified. A partial release is possible, pages are relinked together during de-allocation. Notice that a call of OS_Fxm with wrong values does not crash OZ like OS_Mfr did in previous OZ (OS_Mfr has been fixed too). This flexibility is really handy if user the application wants to decrease memory pool but not release all memory at once. At least, a brutal release of all allocated memory is always possible by calling OS_Mcl directly without calling OS_Fxm before. This sandbox feature protects system against incomplete release of memory pool.
These new calls completely follow the OZ rules. They use the existing memory routines which have been improved or fixed. The different memory tables are unchanged and updated dynamically during allocation/release, especially the out-of-memory tables which speed up allocation. OZ memory allocation is strong and sandbox feature can recover lost pages. However, corruption of MAT is unrecoverable. User is Applications are strongly advised to not use MAT and OOM table directly.
...