LMM but in reverse?
TJHJ
Posts: 243
So I was thinking about this from working with VGA outs, but I am not really how to accomplish it or even if it is feasible.
Can the main ram that held the programs become the video buffer ram? But be using the space that was previously occupied by the programs that were cog loaded.
To explain better, Lets say we have 8 "cog programs" that are 1k each for a total of 8k. The Video buffer for the VGA is 24k (roughly). So full at 32k ish. And limited using the spin compiler as the space is pre allocated preventing anything from being placed there.
Now The 24k is to large to fit into a cog, so it must be accessed though cog access windows, so Im assuming that access time is not a problem.
So our initial ram map looks like |Program 8k| Var 24K|. Now if I understand it correctly on start up the full 32k is copied then the 8k of programs are copied into their respective cogs. This main ram space they are copied from is not accessed again unless a cognew command is called to start a new cog.
If the program were to call all of its initial cog starts and then not reload a new cog, this 8k of space is really dead space. Could the Video buffer be re allocated to occupy this space, allowing more programs/ larger size to be loaded. I dont know how to reallocated variable area post compilation? This effectually would allow for a true 16k of program space, and 32k of ram (Limited by access window)? If I am thinking about this correctly.
The big issue is the coginit routine, I have wiped out what was stored there, what if there was a "reserved 2k" for cog loading, Such that when a new cog is called, go to eprom load to 2k ram, load to cog? I know this would be slower, but I dont think many of us are depending on the speed of the coginit call, maybe but it isnot something I would bet on for a speed dependent app.
Effectively we could gain an additional 14k -16k which changes a whole lot in the system.
Is this even possible?
Maybe this has been done, If so sorry. and Thanks who ever did.
TJ
Can the main ram that held the programs become the video buffer ram? But be using the space that was previously occupied by the programs that were cog loaded.
To explain better, Lets say we have 8 "cog programs" that are 1k each for a total of 8k. The Video buffer for the VGA is 24k (roughly). So full at 32k ish. And limited using the spin compiler as the space is pre allocated preventing anything from being placed there.
Now The 24k is to large to fit into a cog, so it must be accessed though cog access windows, so Im assuming that access time is not a problem.
So our initial ram map looks like |Program 8k| Var 24K|. Now if I understand it correctly on start up the full 32k is copied then the 8k of programs are copied into their respective cogs. This main ram space they are copied from is not accessed again unless a cognew command is called to start a new cog.
If the program were to call all of its initial cog starts and then not reload a new cog, this 8k of space is really dead space. Could the Video buffer be re allocated to occupy this space, allowing more programs/ larger size to be loaded. I dont know how to reallocated variable area post compilation? This effectually would allow for a true 16k of program space, and 32k of ram (Limited by access window)? If I am thinking about this correctly.
The big issue is the coginit routine, I have wiped out what was stored there, what if there was a "reserved 2k" for cog loading, Such that when a new cog is called, go to eprom load to 2k ram, load to cog? I know this would be slower, but I dont think many of us are depending on the speed of the coginit call, maybe but it isnot something I would bet on for a speed dependent app.
Effectively we could gain an additional 14k -16k which changes a whole lot in the system.
Is this even possible?
Maybe this has been done, If so sorry. and Thanks who ever did.
TJ
Comments
For example: the vga 512X384 Bitmap object uses 24kbytes of RAM. I use the rest of the ram for buffers and so on (have a look at the thread about a math article in the propeller wiki where I posted the code example for a simple Oszi with FFT).