5 DIMMS ... 5.2 Size Is it theoretically possible to populate each memory controller with 8GB for a total of 16GB, however the practical memory size limit will depend on software. ...
With the new extmem feature) it is (will be) possible to go beyond the 2GB memory barrier (at least hidden in the background used by programs, without showing the whole memory in Workbench).
Is that correct?
What if one *would* populate the memory controllers with the max of 16GB? Would that be usable with extmem or is the system limited to 4GB max due to it's (32bit?) architecture?
ExtMem gives the programmer the possibility to access memory above the 2 GB "barrier", but no further than 4 GB for the reason you stated (32-bit addressing).
In fact, it's slightly less than 4 GB because of permanent allocations for some hardware register addresses.
I was under the impression that you could use more than 4GB by mapping/unmapping different areas into 32-bit address space. However, I haven't looked at the extmem feature in any detail.
You might be right - I haven't reread it for a while either. But remapping doesn't sound like a game to be played in user-land.
The remapping is not handled by the 'user' but via the API (though there are some very advanced option that mortal devs should likely never touch in this regard) .
Currently the ExtMem allows mapping all 2Gb of memory into the available memory space. This mean you can access that mysterios last 500Mb of memory that was never accessable which is again in that regard. When running SketchBlock without ExtMem I crash out due to lack of memory at an apperently reportedlow of 500 / 600 Mb (as reported in WB titlebar) with ExtMen I can get down to 0.
A futre iteration of ExecSG should allow all instaled memeory to be accessed.
...i Lost track of the development. Is ExtMem already usable or will it be added with a future ExecSG?
Where should one look to find code examples or examples on how to add ExtMem to their programs?
I really hope its a matter of adding a few lines of code to the program and not the need of replacing every single memory read/write I/O...that would make ported programs no target for ExtMem.
...i Lost track of the development. Is ExtMem already usable or will it be added with a future ExecSG?
It's available in the FE Update 1 release. One caveate with the usage on the X1K is that under certain circums5tances the cfeide.device and ExtMem will both map memeory to the same space.
So if you don't use the cfe card reader then comment it out of the kickstart, if you do then perhaps create an alternate kicklayout for use with ExtMem enabled software.
Current SketchBlock pro is the only thord party app I'm aware of.
ram-handler (ie ram disk:) is the main system component using it. (may need enabling with command line options to kickstart/ram-handler.kmod)
Quote:
Where should one look to find code examples or examples on how to add ExtMem to their programs?
Your question is clearly rhetorical as you will have read the autodocs (ASOT_EXTMEM) and wiki in particular, but I'll commit the faux pas of answering it anyway....
I really hope its a matter of adding a few lines of code to the program and not the need of replacing every single memory read/write I/O...that would make ported programs no target for ExtMem.
It's an amiga specific API, you will need to write code to manage paging in and out the sections of memory you are currently working with.
Every program that wants to use extended memory needs to add specific support for it.
This is why it was obvious that almost no apps would be written supporting this feature (reserved for motivated and skilled developers) and also because almost all apps don't need large amounts of memory. I am glad to see that helped with SketchBlock but this feature should be entirely managed by the OS. Maybe one day ...
@Raziel
I recently looked for memory sticks for my X1000 but I didn't find 4 GB ones. So I thought that we could have 2 GB in each of the 4 slots, that is to say 8 GB max. Anyway, that's not necessary to buy 16 GB betting they will be addressed by OS4 soon.
This is why it was obvious that almost no apps would be written supporting this feature
Don't forget, after all, that the RAM Disk (ram-handler) does support it, so at least everybody can benefit from it by being able to shove more temporary files in there.
...this feature should be entirely managed by the OS. Maybe one day ...
Exactly what i meant. There shouldn't be the need to recompile every program to make use of bank switching. It should be handled by ExecSG, or any other program, in the background, on the fly.
If I haven't misunderstood Andy, this is a future plan Quote:
A futre iteration of ExecSG should allow all instaled memeory to be accessed.
So let's hope for the best...
Quote:
I recently looked for memory sticks for my X1000 but I didn't find 4 GB ones. So I thought that we could have 2 GB in each of the 4 slots, that is to say 8 GB max.
If you are still interested, I ordered some new sticks (2Gb for now) which fit the needs described in X1000's manual and will check if they work. If they do, I'll check higher capacity ones too...
Is the updated gfx driver (the one that broke the 256mb barrier) displaying all of the usable graphics memory (in workbench) or is the display in workbench still limited to 256 Mb and the usage of full video memory is done in the background?
...this feature should be entirely managed by the OS. Maybe one day ...
Exactly what i meant. There shouldn't be the need to recompile every program to make use of bank switching. It should be handled by ExecSG, or any other program, in the background, on the fly.
No! There no way it could work efficiently like this, if it even could work inefficiently! You have to write specific code, that means if your are applying to aport, you need to actually do a port rather than a recompile. It will best suit applications that have some kind of paging system (gfx app, video apps perhaps, maybe even VIMs temp files could be put in ExtMem instead (though I'm not sure there would be benefit from this).
Quote:
If I haven't misunderstood Andy, this is a future plan
You have misunderstood, all I said was at some future point all the memory willbe available to ExtMem (hopefully).
T answer your question to Hans. No The memorty shown in workbench tite bar would still reflect the memory visible to the standard system (p96 / gfx lib etc).
But ... there is an x-dockapp to display gfx memory usage, and that shows but the main gfx memory usage and the extended video memory usage.
There shouldn't be the need to recompile every program to make use of bank switching. It should be handled by ExecSG, or any other program, in the background, on the fly.
Do you mean that all of the existing OS4 software should dynamically be mapped above the 2GB barrier by the OS?
I'm not very technical, but doesn't this mean that those OS4 programs out of the currently used banks would suddenly freeze or not able to multitask alongside other programs without warning?
If so then I personally would not like to be implemented this way, seems inconvenient to me.
Unless Exec would also constantly switch banks to allow for multitasking but I think that would have quite a performance penalty.
I rather have the normal programs reside in the 2GB barrier and have ExtMem support hardwired in certain programs e.g. web browsers having tabs in different banks or video editors.
Of course I wouldn't mind if this dynamic way of storing programs in different banks is optional for the user.
What i meant was, to have the ability in ExecSG (or whatever patch or kernel program would take care off) checking for any RAM beyond the 2 GB border (on bootup or even in CFE/UBoot) and only if that case is met (since probably most of the X1000 userrs will use their originally 2 GB) chime in and dynamically use bank switching on all programs (that need it due to their high ram consumption) to use all of the available memory. (Or if the 2 GB Ram gets filled otherwise, e.g. filling up RamDisk)
I would also sacrifice the same amount of memory (that goes beyond the 2 GB border) on a HDD/USB Stick for hash tables or whatever would be needed to keep track of programs writing beyond that border. (write address, size of RAM adressed, task number, etc.)
But, this discussion is moot, as Andy already explained that this is not possible.
...and i have absolutely no idea what i'm talking about, i'm just throwing out brain farts...
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
