Running an OS on the Propeller?
rcxking
Posts: 3
Hi everyone!
I'm new with the propeller, and I noticed that there's a lot of SBC's that run CP/M off a SD Card. Since it's possible to run an OS through the Propeller, is it possible to run something like Ubuntu off of a SBC with multiple Propeller chips? I saw the Dracblade Propeller Computer, and if a single Propeller can run and display video, I'm wondering if the Propeller will have enough power to display the graphics a modern OS like Ubuntu requires.
Thanks for your replies!
I'm new with the propeller, and I noticed that there's a lot of SBC's that run CP/M off a SD Card. Since it's possible to run an OS through the Propeller, is it possible to run something like Ubuntu off of a SBC with multiple Propeller chips? I saw the Dracblade Propeller Computer, and if a single Propeller can run and display video, I'm wondering if the Propeller will have enough power to display the graphics a modern OS like Ubuntu requires.
Thanks for your replies!
Comments
Emulating more recent micros would be needed to run more recent operating systems. I guess that would be a 286 for windows 1.0. The 286 may or may not be possible - I think a subset of 286 instructions includes 8080 instructions.
Another approach is to start from scratch for an operating system. KyeDos is a text based OS that can run programs much like CP/M, but is written in native Spin. There are other "blocky text" based OS's that are possible using some of the graphics drivers in the obex. This takes things to about the mid 1980s.
I do believe that a windows type GUI is possible, and I have written some of the elements in C but the program does tend to grow rather fast. I think it is going to need to be written from scratch rather than taking an 'off the shelf' OS like Ubuntu.
http://hive-project.de/ runs a linux - like command line, but not so much GUI.
Its in German, but Google translate woks fine. I have one of the R13 units built, and some R14 boards.
Look at such projects as KyeDos, PropDos, PropCmd, ZiCog (CPM), Sphinx, etc. Some links are in my signature.
CP/M is/was a single user OS with a command line interface.
But, there are LInuxes that do run in command line mode only and in single user mode. It is possible.
And its not possilbe. Excellent!
So how would one divide the functions of Ubuntu so an individual function or group of functions can be handled by a single cog?
How many cog-sized function groups would be in the list that includes all Ubuntu functions?
My thought is first figure out how many cogs are needed and worry about stitching them back together later.
Once the functions are defined, the interfaces should be straightforward.
I'm currently sitting at a Mac with a 22" display set at 1680x1050 with a bazillion colors..... this is typical for desktop GUI's and certainly out of scope for a Prop (or multiple Props) to handle. So for this and other reasons mentioned about Linux (in the context the OP asked), the "absolutely not" is warranted.
Can a GUI be presented? Certainly. My iPhone has a wonderful GUI but I really don't like to use it as a window manager for program development for a number of reasons. In a pinch, you can use Telnet on it to do some command line things.....Jump Desktop is even usable (barely) to connect to a desktop.
The Prop can present a GUI (with touch screen support) but not with the resolution, speed and functionality of a modern desktop GUI. It's also very taxing on system resources at any level.
Can Linux be deconstructed and something that looks like Linux at the command line be presented to a user? Certainly.
At some point, you deconstruct Linux to the point where it isn't really Linux....the user would need to decide what functionality they wanted and then decide if it's look and feel issues (command syntax, file system organization, programming languages) or if it's architectural and not (reasonably) possible on a Prop. Multithreaded, multi-user, protected, page-able memory, etc. - it would be really cool to have the prop able to handle user memory space virtualization at the hardware level, memory protection would be nifty, an executive mode, DMA transfers......but then it wouldn't be a Prop.
I don't think that multi-user or GUI are the defining properties of what can and cannot be run on the prop. We could certainly imagine a simplified multi-user GUI OS running on a prop. There might already be such things as I've seen several GUI OSes shown off in these forums.
I think the defining property is more a question of scale. I can't efficiently pull a huge 5th wheel trailer with a motorcycle. But, I could pull a little fiberglass luggage trailer. In theory both trailers implement the same service, but the scale differs. Where do you draw the line at what is and is not appropriate? We can look at the extremes and realize that Ubuntu on a Prop isn't feasible, but somewhere out there in the middle of the continuum there is room for someone to push the envelope on how much OS we can fit on a prop.
http://www.busybox.net/
I suppose multiuser is not much of an issue if you don't use it like Linux does. At present, Linux takes advantage of the feature to run groups with specific rights that are not really users at all. It seems to be a back door that allows applications to do things that would be less secure in other ways.
GUI is detachable in Linux. You can downsize your system to run only at command line and many servers have NO Gui for the boost in speed. Other the other hand, Windows is an inseparable GUI which both slows it down and may make it harder to code.
At some point, one has to get down to basics, BIOS, RAM, Kernel, and File System. Unix/Linux are rather rigorous about what these are. Frankly, the need for a GUI better served in Ubuntu Linux on a desktop as video cards are now often as huge as a computer, and maybe faster.
Back to utilities: Most of them are written in C, and what they mostly need is the C runtime API which is covering quite large parts of what an application typically needs. That's why I could, years back, port many Unix tools to an extremely different minicomputer environment with basically nothing in common with Unix - as soon as C was available there was also a C runtime API that hid the differences. One tool I ported back then was microemacs.
Another useful API is POSIX, add that to the good old Libc API and you can write almost anything you could wish for. Some of the POSIX sub-APIs will make some demands on what's underneath (i.e. the kernel and the syscalls), but it's still vastly simpler to implement a POSIX API than trying to port a Linux kernel to the Propeller.
-Tor
There is ELKS the Embedded Linux Kernel Subset. That is old now and does not seem to be maintained.
Event that will need external RAM to run on the Prop and hence be as slow as molasses.
Yeah I'm quite aware that any port would need oodles of RAM and performance would be horrible. But some people just want it and confuse the Prop with a real microprocessor for which Linux was designed. The fact you can make a dog dance doesn't make it fit to be your ballroom dance partner.
As far as I'm concerned, if you want to host Linux or say QNX on a SBC get a Beagle and save yourself the headache.
Those who do know what they want (i.e. they need to run Linux on an embedded device due to some Linux kernel feature like e.g. RT priorities, device driver support, whatever) will probably also know enough to do just as rod1963 suggests: Get a Beagleboard or something similar ARM-based.
-Tor
But it would still be cool to see this particular dog doing this particular dance.
Why? It would run horribly slow and be useless. It would only show that the Prop architecture isn't suited for it. It's much easier to take ARM board with 128MB of DRAM and gigs of flash and do a port. You also have serious mind share to help with port which a great plus and you'd have something useful like a development host for the Prop at the end.
What the Propeller does offer is a great microcontroller for sophisticated tasks which can easily exploit some limited video and mouse abilities for i/o. Getting too demanding of the audio/video aspect begins to bog everything down.
Nonetheless, it is a fun and rewarding environment to learn how boundaries evolve in architectures.