- I have found·no flaws, everything works like a charm. I have added keyboard commands (like "run the CogCounter" object),·run applications from·the second·EEPROM page, used persistent COG's etc.·I am impressed by the seamless switching of VGA and keyboard through·pages. I am·now working on·a·dedicated space in high memory (ldr.allocate) to communicate data to/from·second page applications.
- About he editor in your OS, what is your goal? I would be interested to edit data tables on line (not in the IDE),·like digital patterns for driving pins etc.
- Off topic, I noted·NOP's in your assembly code·to accomodate·(future) pipeling problems. You have inside information, is it going to happen? A 1600 MIPS prop with more COG's, memory and pins is going to be a very capable processor.
Nico,
Thanks for really trying it out "hard".
- I did look at Atilla's board. It's nice. I have an order in for a usbWiz and was waiting for that to use for extended memory. The "OS_loaderInit" module is the only one that knows about where the data comes from. There are a couple of free bits in the command byte and it would be easy to add SPI routines. I think Atilla has already written them. They could be easily integrated. I2C has the advantage that it can just be added to the existing boot EEPROM SCL/SDA lines and uses the existing code that you need anyway to access the boot EEPROM, but SPI is faster.
- The editor is intended to allow editing of text files up to 32K although I'll probably write the editor for arbitrary length files. It would certainly be useful for editing data tables, but I can see implementing an assembler (someone mentioned working on that once - didn't hear further). Chip had expressed a desire to make the Propeller self supporting someday. This would be a start.
- Someone pointed out (I had forgotten) that the current Propeller already does instruction pipelining. The next location is already fetched for decoding when the previous location is doing its result store. Chip and Beau have been dropping hints from time to time. The "next Propeller" is supposed to have a HUB that takes only one clock per cycle rather than the two at present and there's plenty of chip real estate available for more memory, more cogs, etc. Chip has also expressed interest in an improved cog counter PLL.
I'd like to use this in one of my projects. What I need to do is load a program from a 24LC256 32kbyte EEPROM (SDA on A25 and SCL on A24). I have figured that I need to use the OS_loaderInit object included with the operating system. I also think that I need to use the ReadEEPROM routine and then the BootEEPROM routine to do this. However, I don't think I know how to do this. What does addr (stands for address, right?), buffer, and count mean? More specifically, what parameters do I pass to the routines? Thank you in advance!
Please read the comments in OS_Loader and OS_LoaderInit. They should explain. Basically, Addr is an EEPROM address. Bits 15 to 0 contain the 64K address within an EEPROM. If you have a 32K EEPROM, the valid addresses are in the first 32K of a 64K space. Bits 18 to 16 contain a device address. This is usually set by pins on the EEPROM (A2-A0). For some devices, these bits actually are used to address within the device (like the 24LC1024). Bits 22 to 19 specify a pin pair number (0 to 15) so pins 28 and 29 use a pin pair number of 14. The SCL pin is the even one and the SDA pin is the odd one. In your case, pins 24/25 are pin pair 12.
The buffer address is a HUB RAM address to get/put the data and the count is a byte count. If you just want to load a program, use BootEEPROM which reads the program and starts the SPIN interpreter. ReadEEPROM and WriteEEPROM read and write a block of data respectively.
Look at examples of the use of these routines in OS_initialization near the end and OS_fileSystem, also near the end.
Basically, you take the OS_initialization object, strip out everything but the initialize routine and the data it uses, and substitute your program for the processCommands call at the end of the initialize routine.
Note that the rest of OS_initialization may serve as examples of the use of the rest of the system. Particularly, the windowsEditor object was intended for users to built into their own programs.
I integrated my version of the VGA Terminal in with the rest of the Propeller OS commands.· Now "term" comes up in the help command list and when I type "term" at the command prompt it runs the VGA terminal.· I thought about stripping out the rest of the OS functionality but when I was looking it over it all seemed quite useful so I left it in there.· Also I found the "App Key" is the Win95 pick list key on the right side of my keyboard next to the right control key.
Now the N8VEM builders can use Propeller OS for other things and when they need the terminal they can invoke it.· Eventually when the N8VEM Terminal Replacement Board comes out I may convert it to just be a terminal only but for now the more general tool set seems quite useful.· The Propeller seems like a very complimentary device for a Z80 CP/M SBC as it abstracts a lot of otherwise difficult IO to an easy to access interface (UART).· The Propeller OS extends that functionality even more.
I have a zip file with the modified POS software if anyone wants it.· I don't want to hijack your thread so if anyone wants any more information just contact me offline.· Thanks and have nice day!
No. I don't plan to add any new I/O devices to the Propeller OS.
1) In many ways FemtoBasic has become the successor to the Propeller OS. The I/O routines, particularly for the special versions (like BoeBotBasic) were lifted directly from the Propeller OS.
2) There are so many varieties of LCD screens that it would be a nightmare to support them. The TV driver and the VGA driver were done and are nearly identical to each other in terms of how they look to the text driver.
Post Edited (Mike Green) : 12/18/2008 12:29:20 AM GMT
Comments
- I have found·no flaws, everything works like a charm. I have added keyboard commands (like "run the CogCounter" object),·run applications from·the second·EEPROM page, used persistent COG's etc.·I am impressed by the seamless switching of VGA and keyboard through·pages. I am·now working on·a·dedicated space in high memory (ldr.allocate) to communicate data to/from·second page applications.
-·Did you·look at Atilla's board·http://forums.parallax.com/showthread.php?p=596171· What would it take to run your OS on this? He uses an SPI Flash part as secondary storage.
- About he editor in your OS, what is your goal? I would be interested to edit data tables on line (not in the IDE),·like digital patterns for driving pins etc.
- Off topic, I noted·NOP's in your assembly code·to accomodate·(future) pipeling problems. You have inside information, is it going to happen? A 1600 MIPS prop with more COG's, memory and pins is going to be a very capable processor.
Nico Hattink
Thanks for really trying it out "hard".
- I did look at Atilla's board. It's nice. I have an order in for a usbWiz and was waiting for that to use for extended memory. The "OS_loaderInit" module is the only one that knows about where the data comes from. There are a couple of free bits in the command byte and it would be easy to add SPI routines. I think Atilla has already written them. They could be easily integrated. I2C has the advantage that it can just be added to the existing boot EEPROM SCL/SDA lines and uses the existing code that you need anyway to access the boot EEPROM, but SPI is faster.
- The editor is intended to allow editing of text files up to 32K although I'll probably write the editor for arbitrary length files. It would certainly be useful for editing data tables, but I can see implementing an assembler (someone mentioned working on that once - didn't hear further). Chip had expressed a desire to make the Propeller self supporting someday. This would be a start.
- Someone pointed out (I had forgotten) that the current Propeller already does instruction pipelining. The next location is already fetched for decoding when the previous location is doing its result store. Chip and Beau have been dropping hints from time to time. The "next Propeller" is supposed to have a HUB that takes only one clock per cycle rather than the two at present and there's plenty of chip real estate available for more memory, more cogs, etc. Chip has also expressed interest in an improved cog counter PLL.
I'd like to use this in one of my projects. What I need to do is load a program from a 24LC256 32kbyte EEPROM (SDA on A25 and SCL on A24). I have figured that I need to use the OS_loaderInit object included with the operating system. I also think that I need to use the ReadEEPROM routine and then the BootEEPROM routine to do this. However, I don't think I know how to do this. What does addr (stands for address, right?), buffer, and count mean? More specifically, what parameters do I pass to the routines? Thank you in advance!
Regards,
-iam7805
The buffer address is a HUB RAM address to get/put the data and the count is a byte count. If you just want to load a program, use BootEEPROM which reads the program and starts the SPIN interpreter. ReadEEPROM and WriteEEPROM read and write a block of data respectively.
Look at examples of the use of these routines in OS_initialization near the end and OS_fileSystem, also near the end.
I am·interested in writing an application which uses routines from·the Propeller Operating System.· However, I don't know how to get started.·
I have·modified/written a simple VGA terminal program I would like to modify to use the routines from the OS.
Is there a FAQ or simple example program available?· Thanks in advance!
Andrew Lynch
Note that the rest of OS_initialization may serve as examples of the use of the rest of the system. Particularly, the windowsEditor object was intended for users to built into their own programs.
Thanks and have a nice day!
Andrew Lynch
I integrated my version of the VGA Terminal in with the rest of the Propeller OS commands.· Now "term" comes up in the help command list and when I type "term" at the command prompt it runs the VGA terminal.· I thought about stripping out the rest of the OS functionality but when I was looking it over it all seemed quite useful so I left it in there.· Also I found the "App Key" is the Win95 pick list key on the right side of my keyboard next to the right control key.
Now the N8VEM builders can use Propeller OS for other things and when they need the terminal they can invoke it.· Eventually when the N8VEM Terminal Replacement Board comes out I may convert it to just be a terminal only but for now the more general tool set seems quite useful.· The Propeller seems like a very complimentary device for a Z80 CP/M SBC as it abstracts a lot of otherwise difficult IO to an easy to access interface (UART).· The Propeller OS extends that functionality even more.
I have a zip file with the modified POS software if anyone wants it.· I don't want to hijack your thread so if anyone wants any more information just contact me offline.· Thanks and have nice day!
Andrew Lynch
Thank you for the code
1) In many ways FemtoBasic has become the successor to the Propeller OS. The I/O routines, particularly for the special versions (like BoeBotBasic) were lifted directly from the Propeller OS.
2) There are so many varieties of LCD screens that it would be a nightmare to support them. The TV driver and the VGA driver were done and are nearly identical to each other in terms of how they look to the text driver.
Post Edited (Mike Green) : 12/18/2008 12:29:20 AM GMT