Linux port for the Propeller
Jorge P
Posts: 385
Hi all, I have been wanting to see a linux port for the propeller for a while now, however the task of porting an entire OS is to big deal for a single person. There are several of us who want to have a working OS and maybee do. But the Idea of having a linux port would mean that any native linux app could be recompiled to support the Propeller.
I hope to get several people involved in this on the forums here because it will require alot of work, and may need the help from the admins and developers at linux.org, kernel.org, etc...
I think a project like this can only be head up by Parallax, and first we need the hardware setup and a standard to have linux on our props. So anyone can build a system from a specific hardware setup.
The flash memory would act as the BIOS to get things started, and the system hardware should include keyboard, mouse, NTSC/PAL video, and SD media. I left out VGA since it consumes several pins that can be better used for further customization of hardware.
As long as we have a reliable project admin, someone from parallax, and community support, we will get support from the Linux community. I posted this thread on linuxquestions.org to start things off http://www.linuxquestions.org/questions/programming-9/porting-question-818546 .
Please keep this thread alive and we can have linux with some rewarding hard work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
I hope to get several people involved in this on the forums here because it will require alot of work, and may need the help from the admins and developers at linux.org, kernel.org, etc...
I think a project like this can only be head up by Parallax, and first we need the hardware setup and a standard to have linux on our props. So anyone can build a system from a specific hardware setup.
The flash memory would act as the BIOS to get things started, and the system hardware should include keyboard, mouse, NTSC/PAL video, and SD media. I left out VGA since it consumes several pins that can be better used for further customization of hardware.
As long as we have a reliable project admin, someone from parallax, and community support, we will get support from the Linux community. I posted this thread on linuxquestions.org to start things off http://www.linuxquestions.org/questions/programming-9/porting-question-818546 .
Please keep this thread alive and we can have linux with some rewarding hard work.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
Comments
-Phil
Wanting something doesn't mean that it's feasible. The Propeller simply doesn't have enough memory available to provide for an operating system like Linux. There have been several emulators written for the Propeller including several Z80 emulators and a ZOG emulator. I'm not sure of the status of the 6809 or 6502 emulator, but these are not native Propeller implementations. They use external SRAM for memory and are much much slower than the native Propeller since they're emulators. It should be possible to make a medium speed LMM interpreter using external SRAM that's quite large, but it's still not a native Propeller system. There's at least an order of magnitude speed hit in doing the LMM interpretation using external SRAM.
I hope to get some support for this regardless of weather it has been discussed in the past, It will do nothing but open new doors for the propellar once it is started. I am not trying to make X-windows work right off the bat, I am just trying to get some support for a basic linux kernel that has key featurs for the hardware I stated in the first post.
Currently the OS's made to run on the propellar are not realy OS's, they dont have a console that returns when a program is finished as far as I have seen, nor do they support a real file structure that has directories, system files etc...
Thats not to say that their work is in vein, but rather they are projects that are being taken on by a single person and are taking a while to complete, and I support their work too, it is not an easy task to design an OS.
I hope others, who questioned/supported it in the past, could offer continued support and insight to help get things started, even if it is just for fun.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
I still see this as possibe, and memory can always be added depending on how you think about it. The oldschool TRS-80 (Color Computers)/Z80/Comidore/etc... were all systems that started out with only support for plugin cartridges, and developers and hobbiests added support for floppy drives, disk drives, and a wealth of other hardware.
As for memory being slow, I think you mean in terms of flash, if you were to add a single MT48LC8M8A2 IC to the prop, memory would not be that big of an issue. Look at how slow the old 286's and 386's were, they had very little memory but it was enough to get a working OS and windowing system. Then there is always swapspace, which with an SD-Card would be fairly slow which brings ATA/IDE features into play. In order to communicate with an hard disk, you would need to impliment a USB host chip and write functions to support the ATA-3 standard at a minimum, which has been done on 8-bit systems with great success in the past(z80/6809E/etc). It is all possible.
Its just a matter of getting a team together to get atleast the hardware requirements started.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
http://www.rowebots.com/products/unison_rtos
It's not linux, but from description seems that it's having some posix and linux compatibility.
I imagine linux compatibility·being partial and consisting in·API compatibility layer, but I haven't seen the source so I'm not sure on the exact meaning of that.
From what I recall, it should be downloadable in the open source form for a $1 fee.
Sorry to throw cold water on your idea, but some things are just not practical. It would be a bit like towing a semi trailer with a subcompact car. You could probably get it moving, but it is not very practical.
-Phil
Forgive me, but you don't seem to understand the magnitude of the problem - actually multiple problems. I suspect that you have not written compilers nor operating systems yet.
What you are asking for is not impossible, but it is not worth doing.
I came up with LMM in 2006 to enable "conventional" compilers to run on the Prop. There are now many compilers using it, including C compilers such as Catalina which supports XMM (external memory) on Propeller boards that support it - including my Morpheus product.
Why is this relevant?
Because Morpheus theoretically can have enough memory to run a cut-down uCLinux, but it is not worth doing.
Why?
Too much effort is required to end up with a system that would run too slowly to be truly usable.
XLMM (LMM running on external memory) code would run at <1MIPS on the Prop.
Frankly, using a lot of tricks and 2 cogs, I might be able to get it up to 2MIPS - maybe - but it would be a huge effort.
Now we come to a huge problem.
The Linux kernel needs gcc extensions, so it won't compile under Catalina.
Re-targetting GCC for XLMM is a huge task in itself
On the future Propeller 2, it may in fact be feasible to run an XLMM, with a decent MIPS rating (guesstimate: 20MIPS)
FYI, I have been running, and developing under, Linux since kernel version 0.10 [noparse]:)[/noparse] ... and I am doing most of my development work under Linux.
Off-and-on I've been working on a "Linux-like" OS called "Largos" (see link in my signature) which is something like:
Unix v7 meets Plan 9 meets Hurd --> reduced to something that fits
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
So what do we need to do this:
1) Compile Linux for the Prop.
Well straight away we have a problem or two. What does it mean "compile for the prop". For sure you don't want it to compile to the native machine code as you would on a normal CPU. On the Prop one can only fit 496 instructions into a COG at a time so that's out.
Next up is compiling to the built in byte code interpreter. Any kind of interpreter would be horrible slow but to make it worse Spin byte codes don't suite the C language very well at all. Hence the proposal by Parallax to create a "not C" C like language that sits on Spin byte codes.
Well better than byte codes, for speed at least, is to compile C to large memory model PASM. This is already done by the Catalina compiler from RossH on this forum and by the ImageCraft C compiler. So at least we know it works well.
However I don't think either of these can compile a Linux kernel. Linux depends on some extra features of GCC which I believe only a couple of other C compilers have implemented. So first we have to define an LMM interpreter and then we have to target GCC or other compatible compiler to that.
2) Having compiled our kernel, were are we going to put it?
For sure Linux is not going to fit in 32K of HUB RAM. We will need some external memory. That's OK. People like Cluso, Dr_Acula and Bill Henning have external RAM solutions for the Prop going up to megabytes. This of course will slow execution down even more and means that we have to design our LMM solution for 1) above to work with external RAM. It's going to be slow but could be done.
3) Memory management/Virtual memory. A key point of Linux is memory management. If I understand correctly it was because Linus was exploring the virtual memory and memory management features of the Intel 386 that Linux became an idea at all.
The Prop has no paging or segmentation or any kind of MMU. It has now way to isolate processes from each other. It has no way of implementing supervisor/user division of memory.
No matter, Bill Henning as come up with VMCog that currently manages external memory and swaps pages in and out of HUB RAM automatically. With a bit more effort VMCOG could be extended to implement the protections required and take care of swap files etc.
4) Device drivers. Given that the Prop almost has no devices we will need to provide UARTS etc in software. No worries we already have FullDuplexSerial etc to handle that stuff. We just have to integrate them as Linux device drivers.
5) Block devices, basically disks. No problem, we have SD card drivers galore. Same as 4) above.
6) Boot loader. You did mention a BIOS above. Forget it, Linux does not need a BIOS. It understands hardware quite well enough by itself, given the device drivers we have made in 4) and 5) above. All it needs is something to get it off of a media and into RAM and run it. Easy.
7) There is no 7) because I'm starting to think this is not a good idea.
In the Prop we have a 20 MIPS CPU (per COG), we are going to make it into a 5 or less MIPs virtual machine with LMM. We are then going make it into a 1 or less MIPS machine my having to use external memory. The we add a virtual memory/memory management scheme and bring it down to 0.1 MIPS. No, it can be done of course, with a huge amount of effort. But really what is the point?
Instead, I'm going to get Zog to run One Man Unix (OMU). Zog is a bytecode interpreter that can run C code on the Prop that is compiled with GCC. That will have to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
in short.. IMPRACTICAL, FOLLEY, "WASTE-OF-TIME-,-TALLENT-&-RESOURCES"
is it possible, well we have an early model·EV General·Motors·vehicle on the moon, so yes... it is posible to an extent, but not worth the 15-30 man-years to do it. MCU's will develope their own OS's on their own evolutionary branch. No need to take Dino DNA and mate it with a frog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.
You could develop an OS that looks and feels like linux to the user, but isn't really linux.· All you need is an OS that can access an SD card and load applications.· Then all you have to do is develop the main apps that reside in the linux /bin directory, such as vi, cat, grep, cd, pwd, etc.
Although I agree with pretty much everything the other posters here have said, I would also encourage you not to pay too much attention to us forum "oldies", and instead follow your own path. Fantastic things have been done by people who ignored "conventional" wisdom that something couldn't be done and simply went ahead and did them. Chip Gracey himself is a perfect example.
Having said that, I'm afraid that I have to agree that Linux is completely impractical on the Prop I - it simply doesn't have the necessary resources. However, it might be realistic on the Prop II. Also, as Heater has pointed out, while Linux itself may not be feasible (no virtual memory), there are many embedded Unix-like systems that could be ported instead. Also, even if such an operating system is not entirely practical on the Prop I, you can get your initial experience developing for the Prop I and then easily port your results to the Prop II when it arrives.
And if nothing else, by the time you have got even partway through the project (even if you decide it's not practical to continue) you will have learned an awful lot about both the Propeller and about compilers and operating systems, and probably developed some very useful programs and techniques into the bargain!.
So - if you choose to ignore the conventional wisdom, you basically have three options:
1. Go for Linux. This requires you to first port gcc. Given my experience with Catalina, this alone will proabably take about a man-year (unless you already have quite a lot of experience with compilers in general and gcc in particular). While this would be a useful thing in itself, it is just the beginning. I think it would probably take you another man-year after that to get a working kernel - mostly figuring out what you can eliminate and what you have to leave. Of course, the two tasks can be done in parallel if you have multiple people working on it.
2. Go for another Unix-like system. There are lots of interesting ones out there, and some of them are much more suitable for the Prop architecture than Linux. Most of these are written in C, so given that there is already a C compiler available, I think you could have a minimalist working port of one of the smaller Unix-like systems in three to six months.
3. Develop something new from scratch. If you look through the forums you wil see many people are in the process of doing exactly this, and you may end up choosing to join one of these projects. Or, having looked at the current "state of the art" as represented by the various Propeller O/S projects, you may then decide to start one of your own. Depending on what you choose to do, you could probably have something worthwhile (but again "minimalist") in one to three months.
One last point - I don't think you're going to have much success gathering a "team" together to do this - the very nature of the Propeller means that the people who tend to spend the most time playing around with it are those who are attracted to things that are a little quirky or unorthodox - which probably means we are all terrible team players!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (RossH) : 7/8/2010 2:00:52 AM GMT
That said, the task is not trivial, and the results maybe slow, but as you said that is not important - you are correct, unix flavours were running on 286 PCs with small memories.
I built the RamBlade for emulations and operating systems for a 2-prop solution. It is a single prop using all pins to interface to 512KB 55ns SRAM (no latches so it is as fast as you can get), microSD and 2 pins left for interfacing (serial preferred to another prop, but it can drive a keyboard and mono TV text 80x25). Drac built the DracBlade using latches to his SRAM so it is much slower, but he has TV, Keyboard, Serial, etc on his 1 prop solution.
This forum is great for help. I am certain Parallax will not sponsor this. However, you can certainly run the project from here, and you will receive enormous help. We already have drivers for the SD using FAT16/32 and other peripherals including PS2 Keyboard, TV, VGA, Serial, VT100 equivalents, etc. Even if you do not completely succeed, it will be a good start for the Prop II when it becomes available.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
@heater's post should be studied carefully.
About 2 MIPS (32 bit instructions) is probably about the best you can hope
to get from a Propeller executing in cache, etc... with external storage.
The Micron SDRAM takes a ton of pins and lots of signalling.
There is a PSRAM that would be a better fit with burst read/write.
The problem with PSRAM is that it's a tiny BGA package.
SRAM will never be big enough or cheap enough on any board for Linux.
I believe Parallax offered to match the Linux on Propeller bounty dollar for dollar.
I agree whole heartedly with RossH on most points. To restate with an analogy:
Pushing the Linux string through the Propeller pin hole will teach you many things.
Of course like anything, it is much easier to pull the string once it's threaded.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
However, any form of *nix will not be fast. But hey, do we really care? Bill has all sorts of caching code, and hardware too.
If we get another OS running on the prop it can only help. And anything learnt will be put to good use on Prop II later.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
http://en.wikipedia.org/wiki/Von_Neumann_architecture#von_Neumann_bottleneck
The Propeller's cogs are very fast running·programs from internal·RAM·but once you use the external memory everything slows W A Y down.· I am sure the creative and talented people can come up with all sorts of creative schemes but if the CPU relies on external memory there is no way around the "bottleneck".
That being said, I am continually amazed by what is done with the Propeller but there are fundamental limits at work here.· Regardless, I wish you the best of luck in your pursuits.
Have a nice day!
Andrew Lynch
Perhaps we should adopt the same idea. Here we have a multi-core 32 bit micro-controller with obvious power and advantages over other micro-controllers, a fairly unique architecture which hampers some tasks as it helps with others. We should be exploring what is possible with what we have rather than trying to shoehorn it into something it is not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 7/8/2010 12:48:24 PM GMT
" V7 (1979): For many, this is the "last true Unix", an
"improvement over all preceding and following Unices"
[noparse][[/noparse]Bourne]. It included full K&R C, uucp, Bourne shell. V7 was
ported to the VAX as 32V. The V7 kernel was a mere 40
Kbytes!"
How far would you have to cut back on the size, and function of linux before everybody says that it is no longer linux? I would say go ahead with the project, even if you do not succeed, you will have learned a hell of a lot about operating systems, and programming.
Ray
It may be possible to run the V7 on th prop with external memory... but who has the sources !?
You know, once you have linux, the kernel, running... what then ? you startx and load firefox ? [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
pPropellerSim - A propeller simulator for ASM development sourceforge.net/projects/ppropellersim
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
The problem is getting a full blown Linux on the prop.
I believe it would be feasible to reach source-level *AND* user command level compatibility with v7 on the prop with XMM, particularly after I finish adding support for read-only pages to VMCOG. Once I make the "large" version of VMCOG, it would not be too difficult to support multiple virtual address spaces, starting at address 0 - so then it would have all the MMU and VM functionality needed for v7.
A new, minimal, kernel would still need to be written. A good starting point might be an earlier version of Minix.
Note that this will result in a "Unix", but not a full Linux.
As I said earlier, a full Linux port is not quite impossible, but the ammount of effort required, for the slow speed that would result, IMHO is not worth the effort.
With Largos, I am going even simpler than v7 in some ways - and more advanced in others. It is fully messaging based, and would even run smaller programs on a bare prop. But it is not Linux.
Prop2 will be a totally different ball of wax, and I can see running a full Linux on it (with a VMCOG2 providing full MMU/VM functionality) and an LMM2 developed specifically to be a reasonable GCC target. We can get ~20MIPS per free core - much more worth the effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
http://www.damnsmalllinux.org/
Somebody else will know more than me, but to my understanding: Open Bios and open firmware are more or less FORTH kernels that provide a common, interactive, and efficient hardware abstraction layer to the target hardware. The the topmost forth words are the bottom-most system level function calls that unix /linux is built on.
Once we get a forth running on a piece of hardware, it is a reasonable next step to implement open firmware. Then it is a reasonable next step to implement a version of unix. Whether or not the resulting version of linux can support Xwindows or emulate you mac book is a separate issue. But you can probably get a reasonable root command prompt, and at lest you have a familiar starting point.
If one looks at the forth prompt on an Imac v3 or on an OLPC-XO (One Laptop Per Child), one finds that the initial function list as provided by the WORDS command, is pretty recognizable as a standard forth dictionary, with a bunch of hardware specific extension and operating system support words added. The first part, the standard forth kernel, already exists for the prop. The forth kernel is already implemented on the prop. The unix system calls are not, yet. I haven't done an extensive testing of measurements yet, but the forth prompt on the prop is no slower than the OLPC-XO, and is noticeably FASTER than on the IMAC v3.
Of the many possibilities for porting unix to the prop, I would like to present for consideration the option of the open firmware / open bios route, since most of the hard part (the forth kernel) is in place. The rest seems to be a standard exercise for some familiar with unix implementation; google Mitch Bradley at OLPC.
Even though experts have dismissed unix on the prop as unrealistic, this does not necessarily prevent us non-experts from making it real.
Work is in progress, participants are invited.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 10 types of people in the world,
Those who understand binary, and those who don't
As an experiment, go run it on an old 386DX 16Mhz computer.
Then imagine it running at least 20x slower.
That's about the best a current prop could do, running a "real" linux.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
DamnSmallLinux is still Linux and requires lots of megabytes of memory to run. Read the minimum memory and processor requirements in the DSL documentation. It's modest by Linux standards, but still huge in terms of resources available on the Prop.
@prof_braino,
Open Bios and Open Firmware really have little to do with Linux. Open Firmware is a Forth-like system that enables the hardware to get initialized and for the bootstrap portion of the operating system to be loaded. It's really not used after that point. Open Bios provides a standard low-level interface to the hardware, but this isn't used by Linux which provides its own low level drivers.
Again, remember that the Prop has only 496 longs (plus the 16 special locations) of memory. Anything more than that and you're writing a simulator for a different non-Propeller computer and you get a big speed hit anytime you add a layer of simulation / emulation. It then becomes a "toy" project in terms of its usefulness, good for a demonstration or academic exercise, but useless as a practical tool because it's just too slow to do anything useful with it.
Now I would like to make note that I should not have used solely a linux port, I am interested in an os kernel that is small enough/chopped down to run on the propeller, not just considering linux as there are several others. In the early to mid 80's mcu's, like MC6809 were being used in consoles like the TRS-80 Color Computer, and had operating systems written for them including OS9-Level 1 and 2, OS-9 came into the market in the late 70's and is similar to *NUX in that it was a multi tasking/multi user system. In the 90's Nitros9 came into being and is released as a replacement for OS-9 L1 and L2, and is still being developed and open source.
I know the architectures are different for the 6809/any other mcu compared to the Propeller, but bringing a functional OS that can be compiled under Cygwin using binutils and toolshed would make ALL of us be able to convert almost any c program to the propellar, however the opcodes/templates, etc would have to be written for the Propeller for use within binutils and toolshed. Toolshed was designed for use with the 6809/6309 mcu's but using that as a template, we can create a toolshed for the Propeller, wich will allow Windows, Linux, and Mac users the ability to cross compile using cygwin.
I believe that would be the main goal before even thinking about writing or porting a kernel, making a cross development platform for the Propeller through cygwin, that way one package of code can be written and compiled for use under windows, mac, linux, as well as the propeller. All this is what I meant by a community of effort to complete and that alone would be benificial to all of us.
links:
Cygwin http://cygwin.com
toolshed http://sourceforge.net/projects/toolshed/
Nitros9 http://sourceforge.net/projects/nitros9/
Toolshed and Nitros9 sources are where I would get a kernel and cross compiler from by using them as a template for the propeller.
Then I could even consider others as a template as well, it is just a matter of finding the right one in regard to a kernel, once a cross compiler is made, every one would be able to fork off and choose their on projects for a kernel if that is what they are interested in, its the cross compiler that it important right now, without that, everything would basicaly need to be written from scratch.
Forgive me if I seam to be going all over the place with my thoughts, that is why I posted, to get a better understanding of what could be done and to get insight into what others were interested in. I am just doing homework in a sense and gathering oppinions so I can compress and direct my thoughts for these Propellers more wisely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
http://WhatsAvailable.org Software and Gadgets for Windows 7.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
There's nothing wrong with trying to come up with some kind of operating system that runs on the Propeller. It's just that anything you'd do would have to involve an emulator/simulator, whether it's for a Z80 and CP/M or MP/M or for a 6809 and Nitros9 or for the ZOG or even Bill's LMM and Largos. As Bill mentioned, the performance of such a system is likely to be comparable to a 1MHz 6809 or a similar Z80. As a demonstration project or an educational project, that's fine, but as a working tool, it's very limiting in today's world of GHz+ processors. Dr_Acula uses the Z80 emulator and MP/M for a useful home-based project and others have packaged up a Prop with a keyboard and a display to run CP/M that can be used for hobby development "on-the-road", but pretty much any "netbook" can do the same, much faster and much more conveniently for not much more money once you add the display.
There are no native C compilers for the limited memory (512 words) of the native Propeller, but the Catalina and ImageCraft cross compilers exist for Bill's LMM emulator. Catalina already supports execution (XMM) from external SRAM which is the only way to do anything close to what you want. As mentioned before, executing XMM code is quite slow, about the same order of magnitude as any of the other "legacy" emulators.