Cluso99, I'm glad to hear you like Sphinx. I consider Sphinx more of a proof-of-concept than an actual usable application; I've kind of been hoping that people, if interested, would use it as a starting point and modify it to their own needs. Sounds like that's what you're doing, so that's great. I'm sure you'll have no problem modifying the drivers to handle $00 inputs.
Just keep in mind that any resemblance between Sphinx and an OS is strictly coincidental. My goal was to write a compiler. The OS-like bits were added as needed to get the compiler to work, but there was no real OS design, it was all ad hoc. I believe Mike Green tackled the same issues a lot earlier and more systematically with his Propeller OS.
mpark, I don't suppose you have the time to add a FILE command to include binary files? if not, no worries, I'll get round to it eventually, as I'm having trouble finding the time to do hero at the moment. lol
Baggers, way back on page 1 of this thread you mentioned adding File, but I didn't understand what you meant until just now! (Yes, I'm a little slow sometimes.)
If/when I get back to Sphinx, the first order of business will be to fix the file system bug. Then we'll see about FILE etc. But if you get around to it first, I won't complain.
Lol mpark, no worries, and thanks, and I'm glad you see what I mean now also lol [noparse]:)[/noparse] it will allow for more stuff to compile without changing anything! [noparse]:D[/noparse]
As a substitute for a FILE command, you can just reserve the space in a DAT section, and then load the file data at runtime from SD card.
Because Sphinx anyway needs an SD card, and most applications anyway need the SD-driver running, this is no big drawback.
(This changes if you want run your code on another platform, with no SD card).
How integrated is the video driver you are currently using in Sphinx?
I'd like to switch it out for Doug's new 8x8 driver, but the more I attempt to unravel your code,
the more hair I start painfully extracting... [noparse]:)[/noparse]
@OBC - The video driver is pretty integral to Sphinx because it keeps the video buffer in the COG so it has a footprint in hub ram of only one long. The Spin compiler needs all of the hub memory it can get. The way Sphinx is set up, all the I/O drivers are in cogs and only a sector buffer and a small work area have to be kept in hub ram plus another sector buffer and work area for each open file.
Very true Ariba, thanks for the tip, [noparse]:D[/noparse] although some of my games fit in one load, but don't have SD drivers as that would push it over the 32KB limit.
OBC, is there a specific reason you want to add Doug's driver to Sphinx? or is it just for more the retro visual feel for it?
I'm having a problem getting Sphinx to work on a PRICO board. The TV lines are starting on line 20 for this board. I changed the TV pin in the sphinx file to 20, and also set the crystal speed like this...
This is a great tool mpark! I think you've moved a great distance towards what Chip's been talking about for the last couple years with the on chip development environment. I just compiled several small programs. It's so nice to be untethered and I really like your idea for the "interface" objects. Very well done. It's great to be able focus on the application, not the environment all the time.
BTW, I just figured out you can pass the verbose flag to cl as well, Very Cool! Now I feel like I'm in a full blown IDE again [noparse]:)[/noparse]
This is really cool. The innards of a compiler are there to see, eg tokenizr.spn and codegen.spn. I'm studying them closely now and thinking of all sorts of cool possibilities.
In June last year Cluso said "As soon as time permits, I am definately going to have to dust off my version of Chip's spin interpreter and modify it to use external sram yeah"
Since then heater and cluso have shown it is possible to build both the hardware and the software to emulate another micro. The tools to access large amounts of ram (512k and up) now exist.
So - here is a goal that I think might be getting closer - build a propeller based computer that can compile its own programs, including its own operating system and have a working memory that to the user is more than 32k.
In simple terms, for people like me, you can start writing spin code and just keep writing and writing and never worry about running out of code space.
Is this crazy? I don't think so. For instance, it is quite possible to have an operating system (CP/M) running on a propeller, to run a text editing program (on the propeller), edit that operating system, recompile it (on the propeller) and save it so it reboots with the new system. And CP/M exists in a working space of 64k - twice that of the propeller, and the 64k space usage is entirely transparent to the user. Dim Myarray(50000) etc. On a 32k propeller.
This works already, but lets say the emulation is not CP/M. Lets say it is Spin.
Now, the first problem you run up against is memory. Sphinx gets around this by having only TV drivers, but by the time you add all the other peripheral code (serial port drivers, vga driver, a useful terminal driver, the engine to access the larger memory) you use up more and more of the free space in hub that is the key to the flexibility of sphinx. So - I think you reach some sort of stalemate where you can't add more features easily (eg vga drivers) without compromising other parts of the system that need all the hub ram.
So, lets say we sacrifice a little speed in return for more code space.
First, let's be generous and fill up more hub ram with useful code. I think that is ok because...
Lets take the concept of a zicog emulator and turn it into a spin emulator! That ought to only take one cog, and probably considerably less than one cog.
So - here is the idea. You have a pure Spin program, and it might contain bits of code to load cogs and run them, and it also contains a 'main' part of the code, plus all the peripheral bits of spin, that when compiled turns it into a 200k program.
How so?
Well, a start might simply be to tweak the variables in the compiler that tell it how big the code space is, eg
Next step is to turn that into a huge binary, using the existing compiler.
Now, consider the first few instructions in that binary file. The first one might be a long that sets the pins. We can grab that long and emulate it in something like the zicog program. The emulation would actually be quite simple because for most instructions it just runs the instruction, then goes back to the emulation on the next instruction. I think this is the LMM concept?
The main difference is to trap certain instructions before they run, eg instructions that get data from memory location nnnn in hub now get their data from memory location nnnn in external ram. And the other main instruction to trap is any Jump type instruction. Eg a normal spin instruction might say to jump to hub location $2000, but a valid instruction might say to jump to instruction $16000, which lies outside of standard hub space. Instead, it sets a program counter (PC in the zicog) and gets the new long from external ram at $16000 and keeps going.
Thus a 'call' to a PUB that is at the end of the large original spin program ends up compiled into something that still jumps to the right location.
Sphinx could stay as it is - in that most of the drivers such as vga drivers would be loaded into hub ram, would run, would relocate themselves to cog memory then would just get on with their jobs and the hub ram becomes free again.
You could also have two models - the original Sphinx that loads smaller programs into hub ram, and LMM Sphinx that loads programs off sd card into external ram and then starts emulating those programs.
I guess what I'm considering here is a fusion of the LMM, Sphinx, PropDos, the Zicog, the Ramblade and the Dracblade to create a standalone microcontroller that can break out of the 32k memory space of the propeller. Sitting in front of me is a board which I think has all the hardware one needs, and has at least 90% of the software as well.
Maybe this has already been done? Or maybe it has been considered in the past and felt to be too hard?
1) A Spin interpreter that will execute its byte codes from external RAM and also use ext RAM for its data space. Perhaps with some part of its memory map still accessing HUB RAM allowing interaction with other, normal, Spin progs in HUB or with COGS running PASM.
Looks like Cluso's interpreter could be modified to do that.
2) A Spin compiler on the PC that will allow generation of code that will sit in external RAM.
Perhaps BST or HomeSpun could be adapted to do that if Brad or maprk were into the idea.
3) A modified Sphinx that will all generation of code that will sit in ext RAM. A self-hosted Spin dev system.
This all sounds very attractive but there are some down sides:
1) Spin as interpreted is slow. Running from external RAM is even slower.
2) One of the main point of Spin is its support for firing off parallel execution of other Spin code. I imagine that there would only ever be one Spin thread running from and using ext RAM. So he parallelism gets a bit flawed at this point.
So it might be better just to stick with using C, Catalina or ImageCraft, when wanting to use ext RAM like this.
Unless the aim is really to have the compiler running on the Prop, a self hosted dev environment. Not sure if Catalina can compile itself on the Prop yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Just composed a·huge reply and poof! update failed · Here is the second bit first·because it was fresher in my aging mind
@mpark (Michael): May we call it SphinxOS as it is really an OS with a spin/compiler added in ?
If so, could someone add a wiki entry for "SphinxOS - A Parallax Propeller Operating System". Then we can all edit a list of things to do and who is doing·them to avoid duplication of resources. Here·are some ideas (and dare I suggest possible volunteers)...
Sphinx OS
Extensions - mpark ?
Extensions - Mike Green, OBC, localroger ?
Use "-1" instead of "0" for status to allow all 256 character code transfers - cluso
Spin Interpreter to use SRAM - cluso (later)
Drivers
SD to use latest fsrw - ?
1-pin video - cluso
1-pin keyboard - cluso
vga - ?
FDX (to substitue for keyboard & video) - cluso
LCD (2x40, 128x64) - Rayman, Peter, Drac?
Ethernet - ?
USB - ?
Others - ?
Utilities
File transfers (PC to/from FAT16/32) - already done by mpark
Xmodem or Y or Z - OBC, Mike Cook, JamesL, Dracula ?
Ed - already done by mpark
Preditor - CassLan ?
Others - ?
Languages
Compiler spin/pasm - already done by mpark
PropBasic - Bean ?
Catalina - Ross ?
FemtoBasic - Mike Green, OBC ?
Forth ?
Others ?
Miscellaneous
ZiCog & CPM - heater, cluso & dracula
Sound - Ariba, etc ?
Games - baggers, etc ?
What have I missed?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I do not think using SRAM will be much, if any slower than hub. Remember, my interpreter is already 20-25% faster anyway.
As for parallel processing, most of the other cogs are used for doing BIOS and hardware emulations. However, in every application I have seen, there is still one main app that requires a lot of memory, and this is the one that would also use SRAM. Sphinx shifts a lot of code out of the hub.
The normal commands like DIR, DEL, etc are in fact seperate binaries compiled on the prop by sphinx. Extensions to the OS are now so much easier. Anyone can write a command program, just like CPM does.
Sphinx can load a complete prop binary, such as ZiCog (I have done it ). ZiCog could relaunch Sphinx. ZiCog can now be done as a sub-app (like the DIR program) to use the Sphinx drivers·
Drac, I share the same future thoughts. Sphinx just made a lot of that doable much quicker as Michael has done the difficult work in creating the "hub rendezvous" to seperate the drivers into a sort of BIOS. The sub-apps (programs that run under Sphinx) load into the free hub area (or TPA in CPM terms). The other key was the compiler and he has done this too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
...
@mpark (Michael): May we call it SphinxOS as it is really an OS with a spin/compiler added in ?
...
Well, I guess even though I don't consider it an OS now, it will be by the time you're done with it, so sure, call it SphinxOS. I admit defeat. [noparse]:)[/noparse]
Please keep in mind that crucial to Sphinx's ability to compile programs is the very small hub memory footprint of the I/O drivers. You need a persistent video driver, a persistent keyboard driver, and a persistent file system driver. The 512 byte metadata buffer for the file system plus 512 bytes per file is a necessary but huge amount of overhead. All the other overhead is much much smaller. While it's nice to think about all kinds of other devices that could be supported, any additional drivers would need to have a very small hub memory presence and we do have only 8 cogs. Sphinx already needs 6 of them (3 for file system, 1 for video, 1 for keyboard, and 1 for everything else).
@Mike,
I would think that if you were using a USB, it would be in the place of the FullDuplexSerial, so it would be the I/O. Same with Ethernet. I was thinking more in terms of how an OS like Contiki (http://www.sics.se/contiki/about-contiki.html) is accessed.
However, you are right, there is precious little hub memory (and cogs) for the Prop to access other devices.
mpark: Thankyou. It's not an admission of defeat - you have achieved something in addition to your goal.
Ale: Thankyou for the wiki addition
trodoss: We have to be extremely careful of the footprint in hub, as well as the cog usage (as Mike mentioned). However, with external sram, I see ways to overcome this. I would suggest that the ad-ons will be self-contained so for instance the ethernet will use the enc28j60? part.
SphinxOS gives us a great starting point. I do not expect we will be able to do all these add-ons concurrently yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso,
Using FDX accomplishes the same thing, and would be less 'tied' to a specific hardware configuration = better in the long run. Just thought I would mention the previous if it would ever be a consideration.
trodoss said...
@Mike,
I would think that if you were using a USB, it would be in the place of the FullDuplexSerial, so it would be the I/O. Same with Ethernet. I was thinking more in terms of how an OS like Contiki (http://www.sics.se/contiki/about-contiki.html) is accessed.
However, you are right, there is precious little hub memory (and cogs) for the Prop to access other devices.
The USB stack does require 2 cogs, and some hub ram.
I did a HID version that did slow CRC checking in COG, and used 16 bytes of HUB ram to talk between the two cogs, but you need an application on the PC end to talk to it and I never managed to get it to fly on the Mac.
You would need more space for a CDC-ACM version as you need 3 endpoints (You generally need 4 longs per endpoint), plus the serial IO buffers. You might still get away with slow CRC though. Packing the descriptors into the COG can be a little challenging and certainly untidy, but it can be done (I did it for the HID bootloader).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Cluso99 said...
@trdoss: Absolutely batch support, but later. That is a reason to use the standard autoexec.bat and config.sys naming conventions.
It would make the task of compiling itself (or any user apps) significantly easier Sounds like you have a plan though, so it is all good.
I could see a config.sys if, at some point, the kernel used dynamically loadable device drivers. Otherwise, it sounds like one builds it to a specific hardware configuration. I think the DOL project (Dynamic Object Loader?) had been working along those lines.
Once PrEditor is done (not much longer now) I'm going to make a really trim version of it, no menu's etc, that should fit very well into an email program [noparse]:)[/noparse]
@CassLan: Rick, not sure how this would fit with your code, but have you thought about holding your text for menu's on the SD. I presume you are using the fsrw 1.6. If so, I pickup the file first sector address for ZiCog and use this directly plus offsets to read the sectors. You could use this and an index to pick up strings. There is plenty of room on the disk, so use a fixed length and truncate with '0'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
CassLan said...
Once PrEditor is done (not much longer now) I'm going to make a really trim version of it, no menu's etc, that should fit very well into an email program [noparse]:)[/noparse]
Rick
Truly the highest price ever paid for the Propeller chip.. [noparse]:)[/noparse]
CassLan said...
Once PrEditor is done (not much longer now) I'm going to make a really trim version of it, no menu's etc, that should fit very well into an email program [noparse]:)[/noparse]
Rick
Truly the highest price ever paid for the Propeller chip.. [noparse]:)[/noparse]
OBC
I guess I'm being slow again. What the heck are you two on about?
Comments
Just keep in mind that any resemblance between Sphinx and an OS is strictly coincidental. My goal was to write a compiler. The OS-like bits were added as needed to get the compiler to work, but there was no real OS design, it was all ad hoc. I believe Mike Green tackled the same issues a lot earlier and more systematically with his Propeller OS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
If/when I get back to Sphinx, the first order of business will be to fix the file system bug. Then we'll see about FILE etc. But if you get around to it first, I won't complain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
As a substitute for a FILE command, you can just reserve the space in a DAT section, and then load the file data at runtime from SD card.
Because Sphinx anyway needs an SD card, and most applications anyway need the SD-driver running, this is no big drawback.
(This changes if you want run your code on another platform, with no SD card).
Andy
How integrated is the video driver you are currently using in Sphinx?
I'd like to switch it out for Doug's new 8x8 driver, but the more I attempt to unravel your code,
the more hair I start painfully extracting... [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
OBC, is there a specific reason you want to add Doug's driver to Sphinx? or is it just for more the retro visual feel for it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
_clkfreq = 5_000_000 ' Hydra
_clkmode = xtal1 + pll16x
tvPins = 20
kbPins = 26
sdPins = 0
What I get, looks like static on the TV screen. Both of Chip's original TV Terminal and TV Text demo's work fine when set to the same pin.
Does anyone know what else I could check?
Thanks
Or you could define _xinfreq = 5_000_000 instead of _clkfreq.
BTW, I just figured out you can pass the verbose flag to cl as well, Very Cool! Now I feel like I'm in a full blown IDE again [noparse]:)[/noparse]
cl filename /v 2
This is really cool. The innards of a compiler are there to see, eg tokenizr.spn and codegen.spn. I'm studying them closely now and thinking of all sorts of cool possibilities.
In June last year Cluso said "As soon as time permits, I am definately going to have to dust off my version of Chip's spin interpreter and modify it to use external sram yeah"
Since then heater and cluso have shown it is possible to build both the hardware and the software to emulate another micro. The tools to access large amounts of ram (512k and up) now exist.
So - here is a goal that I think might be getting closer - build a propeller based computer that can compile its own programs, including its own operating system and have a working memory that to the user is more than 32k.
In simple terms, for people like me, you can start writing spin code and just keep writing and writing and never worry about running out of code space.
Is this crazy? I don't think so. For instance, it is quite possible to have an operating system (CP/M) running on a propeller, to run a text editing program (on the propeller), edit that operating system, recompile it (on the propeller) and save it so it reboots with the new system. And CP/M exists in a working space of 64k - twice that of the propeller, and the 64k space usage is entirely transparent to the user. Dim Myarray(50000) etc. On a 32k propeller.
This works already, but lets say the emulation is not CP/M. Lets say it is Spin.
Now, the first problem you run up against is memory. Sphinx gets around this by having only TV drivers, but by the time you add all the other peripheral code (serial port drivers, vga driver, a useful terminal driver, the engine to access the larger memory) you use up more and more of the free space in hub that is the key to the flexibility of sphinx. So - I think you reach some sort of stalemate where you can't add more features easily (eg vga drivers) without compromising other parts of the system that need all the hub ram.
So, lets say we sacrifice a little speed in return for more code space.
First, let's be generous and fill up more hub ram with useful code. I think that is ok because...
Lets take the concept of a zicog emulator and turn it into a spin emulator! That ought to only take one cog, and probably considerably less than one cog.
So - here is the idea. You have a pure Spin program, and it might contain bits of code to load cogs and run them, and it also contains a 'main' part of the code, plus all the peripheral bits of spin, that when compiled turns it into a 200k program.
How so?
Well, a start might simply be to tweak the variables in the compiler that tell it how big the code space is, eg
from the codegen.spn program.
Replace $8000 with something bigger.
Next step is to turn that into a huge binary, using the existing compiler.
Now, consider the first few instructions in that binary file. The first one might be a long that sets the pins. We can grab that long and emulate it in something like the zicog program. The emulation would actually be quite simple because for most instructions it just runs the instruction, then goes back to the emulation on the next instruction. I think this is the LMM concept?
The main difference is to trap certain instructions before they run, eg instructions that get data from memory location nnnn in hub now get their data from memory location nnnn in external ram. And the other main instruction to trap is any Jump type instruction. Eg a normal spin instruction might say to jump to hub location $2000, but a valid instruction might say to jump to instruction $16000, which lies outside of standard hub space. Instead, it sets a program counter (PC in the zicog) and gets the new long from external ram at $16000 and keeps going.
Thus a 'call' to a PUB that is at the end of the large original spin program ends up compiled into something that still jumps to the right location.
Sphinx could stay as it is - in that most of the drivers such as vga drivers would be loaded into hub ram, would run, would relocate themselves to cog memory then would just get on with their jobs and the hub ram becomes free again.
You could also have two models - the original Sphinx that loads smaller programs into hub ram, and LMM Sphinx that loads programs off sd card into external ram and then starts emulating those programs.
I guess what I'm considering here is a fusion of the LMM, Sphinx, PropDos, the Zicog, the Ramblade and the Dracblade to create a standalone microcontroller that can break out of the 32k memory space of the propeller. Sitting in front of me is a board which I think has all the hardware one needs, and has at least 90% of the software as well.
Maybe this has already been done? Or maybe it has been considered in the past and felt to be too hard?
Thoughts would be most appreciated!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
1) A Spin interpreter that will execute its byte codes from external RAM and also use ext RAM for its data space. Perhaps with some part of its memory map still accessing HUB RAM allowing interaction with other, normal, Spin progs in HUB or with COGS running PASM.
Looks like Cluso's interpreter could be modified to do that.
2) A Spin compiler on the PC that will allow generation of code that will sit in external RAM.
Perhaps BST or HomeSpun could be adapted to do that if Brad or maprk were into the idea.
3) A modified Sphinx that will all generation of code that will sit in ext RAM. A self-hosted Spin dev system.
This all sounds very attractive but there are some down sides:
1) Spin as interpreted is slow. Running from external RAM is even slower.
2) One of the main point of Spin is its support for firing off parallel execution of other Spin code. I imagine that there would only ever be one Spin thread running from and using ext RAM. So he parallelism gets a bit flawed at this point.
So it might be better just to stick with using C, Catalina or ImageCraft, when wanting to use ext RAM like this.
Unless the aim is really to have the compiler running on the Prop, a self hosted dev environment. Not sure if Catalina can compile itself on the Prop yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 1/4/2010 10:48:27 AM GMT
@mpark (Michael): May we call it SphinxOS as it is really an OS with a spin/compiler added in ?
If so, could someone add a wiki entry for "SphinxOS - A Parallax Propeller Operating System". Then we can all edit a list of things to do and who is doing·them to avoid duplication of resources. Here·are some ideas (and dare I suggest possible volunteers)...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
As for parallel processing, most of the other cogs are used for doing BIOS and hardware emulations. However, in every application I have seen, there is still one main app that requires a lot of memory, and this is the one that would also use SRAM. Sphinx shifts a lot of code out of the hub.
The normal commands like DIR, DEL, etc are in fact seperate binaries compiled on the prop by sphinx. Extensions to the OS are now so much easier. Anyone can write a command program, just like CPM does.
Sphinx can load a complete prop binary, such as ZiCog (I have done it
Drac, I share the same future thoughts. Sphinx just made a lot of that doable much quicker as Michael has done the difficult work in creating the "hub rendezvous" to seperate the drivers into a sort of BIOS. The sub-apps (programs that run under Sphinx) load into the free hub area (or TPA in CPM terms). The other key was the compiler and he has done this too.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Well, I guess even though I don't consider it an OS now, it will be by the time you're done with it, so sure, call it SphinxOS. I admit defeat. [noparse]:)[/noparse]
Edit: I did a quick-and-drafty draft, I hope it works well
propeller.wikispaces.com/Sphinx
Have fun!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Post Edited (Ale) : 1/5/2010 12:49:51 PM GMT
http://forums.parallax.com/showthread.php?p=675656
I would think that if you were using a USB, it would be in the place of the FullDuplexSerial, so it would be the I/O. Same with Ethernet. I was thinking more in terms of how an OS like Contiki (http://www.sics.se/contiki/about-contiki.html) is accessed.
However, you are right, there is precious little hub memory (and cogs) for the Prop to access other devices.
Ale: Thankyou for the wiki addition
trodoss: We have to be extremely careful of the footprint in hub, as well as the cog usage (as Mike mentioned). However, with external sram, I see ways to overcome this. I would suggest that the ad-ons will be self-contained so for instance the ethernet will use the enc28j60? part.
SphinxOS gives us a great starting point. I do not expect we will be able to do all these add-ons concurrently yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Using FDX accomplishes the same thing, and would be less 'tied' to a specific hardware configuration = better in the long run. Just thought I would mention the previous if it would ever be a consideration.
Have you thought about batch file support?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
The USB stack does require 2 cogs, and some hub ram.
I did a HID version that did slow CRC checking in COG, and used 16 bytes of HUB ram to talk between the two cogs, but you need an application on the PC end to talk to it and I never managed to get it to fly on the Mac.
You would need more space for a CDC-ACM version as you need 3 endpoints (You generally need 4 longs per endpoint), plus the serial IO buffers. You might still get away with slow CRC though. Packing the descriptors into the COG can be a little challenging and certainly untidy, but it can be done (I did it for the HID bootloader).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
It would make the task of compiling itself (or any user apps) significantly easier
I could see a config.sys if, at some point, the kernel used dynamically loadable device drivers. Otherwise, it sounds like one builds it to a specific hardware configuration. I think the DOL project (Dynamic Object Loader?) had been working along those lines.
[noparse][[/noparse]Edit:] Found the thread for DOL:
http://forums.parallax.com/showthread.php?p=701497
Post Edited (trodoss) : 1/6/2010 3:26:13 AM GMT
Rick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
NYC Area Prop Club
Prop Forum Search (Via Google)
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Truly the highest price ever paid for the Propeller chip.. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I guess I'm being slow again. What the heck are you two on about?