I'm trying to think what this can do and what it can't do. Say you have a PUB function and it contains a few longs and maybe it reuses some commn hub memory for strings or whatever. That ought to work fine.
However, what about a self contained PUB function that calls other PUBs within its code? Is that a stack push/pop exercise and hence is it also possible to do this with relocatable code?
But how would you glue that all together with the naming of those sub-pubs? Dummy names? Or do you not have any sub-pubs and just use copy/paste a lot? (which is not as bad as it sounds when working with lots of external memory).
I think one thing is missing ... the link to already loaded drivers.
I have a system running called COG OS. It has some nice features:
1. The upper EEPROM contains all kind of drivers, for example FullDuplexSerial, LCD driver, Keyboard driver, SD card ....
2. There is a COGOSCORE which contains functions to load the drivers needed by name and version number.
3. The drivers loaded are registered in upper RAM.
4. Another set of core functions is there to attach to those drivers.
The link between 2,3 and 4 is that the parameter RAM that you use for communication between main code and the driver is not an array, but taken and reserved in upper RAM.
So, with the "loadspin" you'd first have some code which attaches to the already running drivers.
This way each piece of code loaded can have access to SD card and so on
So, what I have for example is a prime.BIN file on SD card which simply attaches to the full duplex serial driver and spits out a bunch of prime numbers. Another demo uses the LCD.
It's also possible to pass any number (up to 10) of parameters to the loades SPIN function.
Why didn't I post it yet ... well ... because it would need a good documentation for setup of such a system. Maybe I should post a ZIP for all who are interested.
It's easy to create the external functions ... first develop them on it's own including load of drivers and stuff, then move the code to a stub which no longer loads the drivers, but uses the core functions to attach to the existing drivers instead. Compile this and save it as BIN.
That sounds brilliant! The hard work is taking each of those obex objects and changing the code so that it works in a standard way. How many objects have you done?
This could link in nicely with the Big Spin work that Dave is doing. Big Spin could contain all the support code (which sometimes is a huge amount of spin and not much cog code).
It's easy to create the external functions
How quickly can you create one? I'm taking about 1 month! If you can do these quicker that would be great. The same driver could potentially be used by BigSpin, Catalina and Propbasic.
What is the most number of longs you have needed to reserve in upper ram? Is 10 enough per cog or would you need more for some drivers?
MagIO2 that code sounds great! I would be interested it in trying on the Chameleon. It would probably work with the C3 as well since both have an extra eeprom on the SPI bus.
Ok, I am going to prepare a long long post for you.
The drivers I have converted so far are:
TV
Keyboard
Full Duplex Serial
BenkyLCD
Spfd5408
The EEPROM is simply organized in slots of the same size (COG RAM size). The first slot is for the TOC. There is the name, the versionnumber and the number of longs needed in HUB.
The table of loaded drivers later on contains a hash value instead of the full name and the address of the Hub-buffer......
More has to come this evening.
Comments
I'm trying to think what this can do and what it can't do. Say you have a PUB function and it contains a few longs and maybe it reuses some commn hub memory for strings or whatever. That ought to work fine.
However, what about a self contained PUB function that calls other PUBs within its code? Is that a stack push/pop exercise and hence is it also possible to do this with relocatable code?
But how would you glue that all together with the naming of those sub-pubs? Dummy names? Or do you not have any sub-pubs and just use copy/paste a lot? (which is not as bad as it sounds when working with lots of external memory).
I have a system running called COG OS. It has some nice features:
1. The upper EEPROM contains all kind of drivers, for example FullDuplexSerial, LCD driver, Keyboard driver, SD card ....
2. There is a COGOSCORE which contains functions to load the drivers needed by name and version number.
3. The drivers loaded are registered in upper RAM.
4. Another set of core functions is there to attach to those drivers.
The link between 2,3 and 4 is that the parameter RAM that you use for communication between main code and the driver is not an array, but taken and reserved in upper RAM.
So, with the "loadspin" you'd first have some code which attaches to the already running drivers.
This way each piece of code loaded can have access to SD card and so on
So, what I have for example is a prime.BIN file on SD card which simply attaches to the full duplex serial driver and spits out a bunch of prime numbers. Another demo uses the LCD.
It's also possible to pass any number (up to 10) of parameters to the loades SPIN function.
Why didn't I post it yet ... well ... because it would need a good documentation for setup of such a system. Maybe I should post a ZIP for all who are interested.
It's easy to create the external functions ... first develop them on it's own including load of drivers and stuff, then move the code to a stub which no longer loads the drivers, but uses the core functions to attach to the existing drivers instead. Compile this and save it as BIN.
This could link in nicely with the Big Spin work that Dave is doing. Big Spin could contain all the support code (which sometimes is a huge amount of spin and not much cog code).
How quickly can you create one? I'm taking about 1 month! If you can do these quicker that would be great. The same driver could potentially be used by BigSpin, Catalina and Propbasic.
What is the most number of longs you have needed to reserve in upper ram? Is 10 enough per cog or would you need more for some drivers?
The drivers I have converted so far are:
TV
Keyboard
Full Duplex Serial
BenkyLCD
Spfd5408
The EEPROM is simply organized in slots of the same size (COG RAM size). The first slot is for the TOC. There is the name, the versionnumber and the number of longs needed in HUB.
The table of loaded drivers later on contains a hash value instead of the full name and the address of the Hub-buffer......
More has to come this evening.