I'm trying with allocmem tool from os4depot that fill ram from a shell command and when I use more than 1Gb of ram partially with allocmem and open some apps at same time system freeze. This means that use more than 1 Gb of ram in AmigaOS4 it's a fake? I can install 2 Gb but if use more than 1 Gb of ram system crash, it's the same result to have a system with only 1 Gb of ram.
Edited by kikems on 2024/8/12 0:30:11
Sam460LE AmigaOS 4.1FE with 2 Gb ram and Radeon RX550 LowProfile.
This is a (old) well known issue and its always reproducible also on Sam440 It doesn't matter how much swap memory you have, simply copying one or more files into RAM that are larger than your physical memory and this will trigger a system freeze...
Guys, you can also try to disable ExtMem with: SYS:Kickstart/ram-handler.kmod ExtMem=NO
Just to clarify, does this turn off ExtMem across the entire system, or are we only talking about turning it off for the RAM disk?
I am aware that some software does indeed make use of ExtMem (I forget the name of it but there's some audio software, by Trixie perhaps?, at the very least)
It's a ram-handler setting so it only change its own internal behavior. ExtMem remains enabled in the system for who wants to use it (SketchBlock is the only one if I'm not wrong).
ExtMem remains enabled in the system for who wants to use it (SketchBlock is the only one if I'm not wrong). The Rave audio editor can also use ExtMem, as I have described in my blog post.
Thanks for the insight into your blog and the explanation about ExtMem. So it is a feature of AmigaOs4.1 that is currently hardly used in programs or games. Similar to altivec support ?
I suspect that people are a bit insecure and think that every time they install 4GB RAM it is fully available under AmigaOs4.1.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne A1222plus AmigaOs4.1 FE
I suppose the real question is - how many applications or games could benefit from using it but don't? Maybe most software just manages OK without? I remember reading the blog post about Rave's use of ext mem - it was an interesting read and clearly a real good use case for the extra memory.
If we takes 3d games which use warp3dnova (so ogles2, gl4es ones, minigl ones) then there no needs to use extmem feature as 2d and 3d drivers put textures to "external" memory of video card (if we can says so, i.e. the one behind of our system visibly 256 mb barier). Some games i port even will not run with "just" 256mb of video memory , for example "worlds" game will take about 800 mb of video memory, which is quite unusual for amiga games, but : far behind 256 mb. Other 3d games also upload their textures to external video mem, just not as lot as "worlds". But main point: 3d games already benefit from external memory, just not via extmem feature (through, i do not know how Hans implement it, but developers of 3d games have no worry about, they just have no limits with memory to upload textures to)
There two types of bitmaps, displayable bitmaps and none displayable bitmaps, it won’t be wrong, to put none displayable bitmaps in upper memory. Freeing up lower mem for more useful stuff, for programs that can’t use upper memory, it can, also result in more programs using it without knowing.
Anything that has bla_lock()/bla_unlock() can potentially be in upper memory.
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
Almost everyone has more RAM now, not often we run out of memory anymore.
Not much benefit, really is more about managing memory better, Not every system has more then 2G installed in there system, but if you have 4GB or more, the upper memory can be used.
(So, there is potential for assuming you have something, you don’t, this can result in crashes, if you do not have a backup solution.)
It can be a little bit slower to use it, it is memory mapped memory. Not that virtual memory can’t also cause some slowdowns.
(So to access the memory, mmu has to be programed, when needed, the system will need to know what address space is available in lower space, for this mapping, it can give to the Ex mem object, So can take little bit of time for memory is available, the address space might not be availabol when you need it, as result you can fail to access it. Imaging going to the beach, and there some free parasols you can use, but they are all taken, but there no one is there. Everyone is out to lunch, but they have not returned the parasols.)
It can be useful in extreme events like animation / video editing, working with raw data. It can also quick way to store data for short times, like temp files. it can be really useful in drivers / filesystems for cache.
Edited by LiveForIt on 2024/8/14 9:00:11 Edited by LiveForIt on 2024/8/14 9:03:06 Edited by LiveForIt on 2024/8/14 9:05:50 Edited by LiveForIt on 2024/8/14 9:10:08 Edited by LiveForIt on 2024/8/14 9:14:12 Edited by LiveForIt on 2024/8/14 9:16:44 Edited by LiveForIt on 2024/8/14 9:21:48 Edited by LiveForIt on 2024/8/14 11:13:00
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
It can also quick way to store data for short times, like temp files. it can be really useful in drivers / filesystems for cache.
I planned to use ExtMem for the diskcache.library caches, but since not all kernels, for example the Pegasos2 one (maybe the A1222+ too?), support it I never implemented it.
The malloc allocator of newlib.library could in theory use ExtMem as well, if it would be supported by all platforms. Since it's MEMF_PRIVTATE anyway it can be paged out and isn't accessible by other tasks, but too much AmigaOS 4.x code is broken and wrongly assumes malloc()ed memory could be shared with other tasks or threads.
The malloc allocator of newlib.library could in theory use ExtMem as well
malloc has to be 32bit, and does not expect you to lock and unlock memory, so that won’t work.. will can work, but it won’t make sense, if always have lock, you have taken all the parasols, (used up all low memory address space.)
perhaps if scheduler gave back parasols when task was not active. (not sure what it does)
Quote:
The malloc allocator of newlib.library could in theory use ExtMem as well, if it would be supported by all platforms. Since it's MEMF_PRIVTATE anyway it can be paged out and isn't accessible by other tasks, but too much AmigaOS 4.x code is broken and wrongly assumes malloc()ed memory could be shared with other tasks or threads.
I don’t think malloc has a version that allows you to share anything, instead it steams to me its up to the child tread created by clone, what is shared or not. Different approach then we have on AmigaOS.
The big NO NO, will be to share pointers to variables on stack, sense stack pointer increased and decreased and can be over written, I consider this a logical fallacy. Stack most likely should be private and never be shared.
Edited by LiveForIt on 2024/8/14 16:34:19 Edited by LiveForIt on 2024/8/14 16:36:54 Edited by LiveForIt on 2024/8/14 16:38:19 Edited by LiveForIt on 2024/8/14 16:41:26 Edited by LiveForIt on 2024/8/14 16:49:08 Edited by LiveForIt on 2024/8/14 23:00:16 Edited by LiveForIt on 2024/8/14 23:01:00
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
[EDIT] Sorry, quoted the wrong thing. I meant to refer to this: Quote:
I planned to use ExtMem for the diskcache.library caches, but since not all kernels, for example the Pegasos2 one (maybe the A1222+ too?), support it I never implemented it.
Quote:
Not every system has more then 2G installed in there system, but if you have 4GB or more, the upper memory can be used.
(So, there is potential for assuming you have something, you don’t, this can result in crashes, if you do not have a backup solution.)
Isn't this another example of Amiga OS4 being held back by supporting the past? Doesn't there come a point where machines that are (however old stuff like Pegasos is) are left as legacy and NG moves on? Obviously if new machines see the light of day without features the rest of the line up has then that's a special kind of stupid and a different problem.
Eventually things have to move forward. And sometimes you can't keep looking in the rearview mirror. Although I guess we're all firmly fixed on that mirror to a certain extent or we wouldn't be here.
Isn't this another example of Amiga OS4 being held back by supporting the past?
Perhaps. (BPPC, CPPC, AONE-XE/SE/Micro, Peg2)
Slow computers are useful, when you write code, as if it runs well on a slow computer it will run well on fast computer, and perhaps wasting memory, was not the right approach, perhaps was better way to do it, then to use more memory.
Quote:
Eventually things have to move forward. And sometimes you can't keep looking in the rearview mirror.
But I don’t think workaround is that complicated, but sure, if have put stuff you normally put in high memory on disk, it’s of course more of a slowdown. Or if you can’t use high memory, resulting in higher low memory usage. I don’t necessarily see lack of ExtMem as showstopper. Sure, it’s a shame if it’s not used.
Edited by LiveForIt on 2024/8/15 21:25:14
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
The big NO NO, will be to share pointers to variables on stack, sense stack pointer increased and decreased and can be over written, I consider this a logical fallacy. Stack most likely should be private and never be shared.
Would that be for local variables? Any sane programmer would not try to share local variables with a child task. Static locals may work, but still. For globals it should be fine.
Of course, it's a bit dirty passing variable pointers to another process, child or otherwise. But, since AmigaOS has no proper process threads, it's one way to do it. At this point, given the shared memory model in AmigaOS, I still don't understand how they have not added threading capability. A process can write into memory space of another, but it cannot share a bsdsocket library base with a child processs. Nor share globals even though sharing the global register is easy enough.
malloc has to be 32bit, and does not expect you to lock and unlock memory, so that won’t work.
The whole point of the ExtMem feature is to use a small 32 bit virtual address space window to the larger 64 bit physical memory. However, there is no reason different tasks can't use the same 32 bit virtual address space for different 64 bit physical address spaces. All you have to do is to move the 32 bit virtual "window" on task switches to the different, per task based 64 bit physical address spaces.
@MartinW Quote:
Isn't this another example of Amiga OS4 being held back by supporting the past? Doesn't there come a point where machines that are (however old stuff like Pegasos is) are left as legacy and NG moves on?
The problem is that there is nothing like a "not supported on this platform" error code when trying to use ExtMem on unsupported platforms like the Pegasos2, it simply crashes instead.
@Hypex Quote:
A process can write into memory space of another, but it cannot share a bsdsocket library base with a child processs.
The RoadShow API includes extensions to the AmiTCP/IP one allowing to share socket fds and the ISocket interface between tasks, which is of course used by the newlib.library C socket code. Only if you are using junk like clib2 or clib4 instead you're out of luck and it will crash...
The problem is that there is nothing like a "not supported on this platform" error code when trying to use ExtMem on unsupported platforms like the Pegasos2, it simply crashes instead.
That sounds like poorly written and untested code.
Quote:
The RoadShow API includes extensions to the AmiTCP/IP one allowing to share socket fds and the ISocket interface between tasks, which is of course used by the newlib.library C socket code. Only if you are using junk like clib2 or clib4 instead you're out of luck and it will crash...
It was one example I thought of. But, I don't see a problem with it. Non-shared library bases are an Amiga standard. Somehow OpenLibrary() doesn't mention it. So you need to read the docs of the specific library, which people already should be, to find out these little idiosyncrasies about the library base.
This possibly came about since BSD is a multi-tasking, multi-threaded OS. So, a function base pointer can be shared across threads, in whatever form is in the ABI. On AmigaOS, that has no proper threads, this idea breaks. In any case, I consider code that opens a library in one process and accesses it from another to be dirty. It should keep it clean. Easy enough to isolate all library access to one process and use some IPC to share any data.
Slightly off topic, but with newlib, I wonder if it can easily share file handles? So in the case of a process spawning a child. And wanting to printf() in the child, but using the stdio handle set in the parent, so it outputs to the same file handle.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
