Increasing COG RAM beyond 512 longs.

LoopyByteloose

I was just wondering if someone has come up with a way to extend beyond the 512 longs in a cog.· Seems to me that you could 'borrow' another Cog and have it sacrafice itself to just extending RAM to the first Cog.

This would mean that a particularly ambitious Cog program could always find a way to survive.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········

···················· Tropical regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Phil Pilgrim (PhiPi)

There's no reason you can't use overlays if you need more code space in a single cog. Just reserve a block of cog RAM for the purpose at a known location. Then make sure the code blocks that are to run in that location all get ORGed there. You'll need to keep track of what's loaded versus what's needed and make transfers from the hub when necessary. But it could work.

-Phil

Mike Green

I've been thinking about using a 128K byte EEPROM substituting for the 32K standard boot EEPROM and using the extra space for both SPIN and assembly overlays. For SPIN, I'm going to put together a small SPIN program that just takes the first 32K of the EEPROM and copies it to another 32K area. This small program would be run from RAM after loading the EEPROM with the Propellor Tool. Similarly, a simple object could write an assembly routine to a 2K page in the EEPROM. You'd write one or more assembly routines in a SPIN program, include this object, and your main method would just call this object with the start, length, and destination of each assembly routine you want to write. The last things you need are a small assembly routine (as an object) that loads and runs a complete SPIN overlay (into HUB RAM) and a small assembly routine that directly loads a new overlay into the same cog from the EEPROM. This would need a semaphore for the EEPROM since more than one cog could try to access the EEPROM at a time.