View Full Version : Code Explosion... part 2, the Prediction

04-02-2009, 05:51 AM
I have to admit... when Mike first started talking about an operating system for the Prop, I thought he was brilliant but just a little bit nuts. The kinds of things that I could envision for the Prop certainly didn't need an operating system and with the RAM limits, etc. etc.... it just didn't seem to make sense.

That is what I thought, and I couldn't have been more wrong.

At PropExpo last year, Oldbit demonstrated what you actually could do if you added a modicum of code and brought all of the right pieces together. That 20 minutes or so was worth the six hour drive. Oldbit was not claiming to be a code messiah... he was just showing what you could cook up with what was already available. How could I have been so wrong?

Then I got myself all invested in a project that actually needs an operating system... and I felt like the luckiest kid on the block.

Now localRoger has weighed in and boy-o-boy...

In this one area of development, we now have three great efforts, which have substantially lowered the bar for everyone and can serve as useful templates for our larger efforts... all supported by some really fine common objects.

My first thought was...this is great, there are features all over the place. All I have to do is mix and match and add a few features, and I'll have exactly what I need for my project... which is absolutely true, not a chance of being wrong, you can take it to the bank, and just about anyone can do exactly the same thing. This is real progress and it is hugely significant.

But then I remembered the last time I was really wrong. And I started thinking about Cogs and RAM again...and then I found out that localRoger's OS doesn't include the aigeneric driver... which is spectacular and which I would plan to use or need to hack.

In this new and improved working environment, I'm going to be tearing apart code at multiple levels. And it isn't just me, almost every convert is going to have a period of mixing, matching and tearing apart code at multiple levels ... It doesn't hurt anything. It is very educational, and it is fun... but it is also not very efficient.

There must be a better way to do it.

Whenever I come to a conclusion like this... there is almost always a guy way out ahead of me who has already solved the problem.

So, I would like to make a prediction: Before long we are going to see our Spin programs talking to each other... slowly at first. And about the time the PropII arrives they will be talking so fast, you will think it is a real time conversation. In this area, some of our Spin programs will be much smaller and get even smaller as the modes of conversation improve.... We will end up with something that looks a lot like Unix... but better.

This won't be how you have to do it... simply a way that you can do it if you want to... an addition to everything else we now have. A faster track to development and learning.

Adding that last piece will dramatically change the landscape... again.


04-02-2009, 06:50 AM
rjo -- PropCMD does indeed run the aigeneric driver, I just left it out because of licensing. The source has detailed instructions for patching it back in if you have the aigeneric files, and now that aigeneric is MIT I may post that version to the obex instead. (The tv_text version has the advantage of significant memory savings, so both are valuable.)

I saw the value of what you are talking about within about two hours of learning that the Propeller existed. An OS for the Prop doesn't have to be Linux or Windows, it can be like CP/M, which ran in like 8K of RAM. When I was (re)coding PropCMD I left doors open in the code to do things like I/O redirection which would mainly be curiosities, since PropCMD goes away when it SPINs another .SPIN. But there might be a way to establish a standard for spinning apps that leave the OS running in a cog or two to manage things like SD access and I/O redirection. This is the basis of all true OS, a core which remains resident at all times and provides services. That could also help with things like driver hell, having to patch in the pins and schema for the video, keyboard, etc. That's the sort of thing an OS is FOR ... you patch that stuff in for your one system, and then all compatible programs can find your input and output streams, figure out the video screen dimensions, and so on. The Prop doesn't seem to have anything like that yet but I think the way is clear to build it.

Oldbitcollector (Jeff)
04-02-2009, 08:15 AM
Patience my friend, we're all making good progress. :)
Go back to read the threads from early 2007. (think Propeller stone-age) <smirk>
Amazing things have happened when people came together and started working
collaborative projects and code! I'm excited that 2009 is already off with a BANG!

I'm thrilled to death that you have added your "spin" on PropDOS. If you don't mind
I'd like to attach a slightly altered version to your thread with the original AiGeneric
in place for those who would like to take a simple side-step into it from the PropDOS

Anyone remember the story of stone soup (http://en.wikipedia.org/wiki/Stone_soup)? :)


New to the Propeller?

Visit the: The Propeller Pages (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

04-02-2009, 08:24 AM
Be my guest. I had planned on people using it as a framework. I am thinking maybe when I polish it for obex I should put BOTH versions in a zip, just to save people the trouble. There's plenty of hub ram left for whole groups of new commands, and it's easier to add them with the if/return structure which paradoxically runs just as fast as a properly constructed lookup table and case statement (darn them cogs is fast, it screws with a lot of your usual optimization assumptions).

Mike Green
04-02-2009, 09:26 AM
Do have a look at the Propeller O/S that I wrote (http://forums.parallax.com/showthread.php?p=598350).

In terms of I/O, this does what you're suggesting in that it loads a display driver, a keyboard driver, and an I2C driver/loader and leaves them running for subsequent programs to use via known workareas in high hub memory. Since the last version I posted (1.031), I made the TV and VGA drivers more compatible and was working on reducing the memory needed. There was no SD-card driver at the time, but it would be a "slam-dunk" to substitute the combined I2C and low-level SPI driver used in BoeBotBasic along with a FAT I/O layer since that's essentially what I did with BoeBotBasic.