Propeller Concept Thinking: Sorta Advanced DOS Box

Wolfy

Okay,
while looking around on the forums I have seen multiple starts for an operating system for the propeller. Now before I get started, I will say that I have ZERO coding knowledge for the propeller, only knowledge of the basic stamp as far as coding goes.

Okay, speed up to today's computing environment and you'll see 1000MHz bus lines, gigabytes of storage, and so much more. 3D graphics running at multiples of frames per second, data traveling across the country in milliseconds, and even more. While we can't come close to doing that with the propeller, or propellers, we can bring back old systems and news features with the prop. Think DOS, UNIX, Linux, and the like. We already know how to create simple shells, return to those shells after execution of the progs, and as far as I can tell we can do loop and call based programming.

An advanced, yet small, and powerful operating system for the propeller shouldn't be to hard given the right coordination and drive to do so. We could be looking at a multi-propeller system. Since it doesn't look too complicated to code hardware into software stacks, it should be easy to bring the following into the OS: Ethernet, VGA Video, Keyboard, Audio, Bus Lines, SD Storage, and Serial Port. (please, keep in mind that I thinking with the concept point of view, we'll be using two props in this scenario!)

The OS and "Interrupts" would be mailbox driven, and I'll also outline Cog usuage:
Cog 0 / Prop 1: Boot Loader and BIOS (BIOS would provide keyboard API and clock settings to OS and applications)
Cog 1 / Prop 1: OS Networking and runtime routines (Take care of house keeping, timing sync, and SD Storage)
Cog 2 / Prop 1: Video Stack (Mailbox 1, provides video buffer and display API)
Cog 3 / Prop 1: Memory API (Mailbox 2, provides mem_read, mem_write, mem_free, mem_used, mem_protect(address), and mem_expose(address) to applications and OS)
Cog 4 / Prop 1: Ethernet Stack (no idea for runtime calls for this stack, but the OS should handle them for the virtual application machine)
Cog 5 / Prop 1: Round Robbin Device Manager (four pin expansion port: one data ready, one halt/ready, two data lines software directional)
Cog 6 / Prop 1: Mailbox 3 (shared between both propellers for OS calls, memory functions, and variable sharing)
Cog 7 / Prop 1: Mailbox 4 (shared between both propellers for OS calls, video functions, device calls)

Cog 0 / Prop 2: Application Virtual Machine PID 1000 (virtual machines at their simplest could help aid in primitive multitasking)
Cog 1 / Prop 2: Application Background Process PID 1001 (for handling memory calls and other various system calls)
Cog 2 / Prop 2: Application Mailbox Process PID 1002 (for interfacing with keyboard, video, and high level API calls)
Cog 3 / Prop 2: Application Virtual Machine PID 2000 (virtual machines at their simplest could help aid in primitive multitasking)
Cog 4 / Prop 2: Application Background Process PID 2001 (for handling memory calls and other various system calls)
Cog 5 / Prop 2: Application Mailbox Process PID 2002 (for interfacing with keyboard, video, and high level API calls)
Remaining Cogs are free for expansion, which could be used to implement future APIs or devices.

I understand the propeller was not built to be a full blown computer due to memory, speed, and a few math issues. But we could produce a DOS operating system utilizing two props in which the cogs would each have their own jobs to take care of. If everything is down round robbin sync, except for hardware devices which would be buffered, the system would have some marginal performance. Meaning we could build a dos box propeller powered computer. Sure, no gui, no internet, slow; but none the less it is a computer.

Please remember that this is only a concept, food for thought. I would like any input on this that I can get, as I may build the hardware and attempt to learn spin in order to "take a stab" at this sort of project. All thoughts are welcomed and any suggestions or even changes to the concept structure are welcome! Thanks to all those who read, and I hope this provided y'all with a good read.

Mike Green

I would suggest first deciding what you want to use this for and thinking about whether it's capable of doing what you want. Remember that each layer of abstraction you add to make this "OS" has a price in terms of efficiency, memory footprint, etc. A number of people have built multi-Prop setups where one Prop just does simple I/O for the other one, usually including a keyboard, display, mass storage, and the necessary interprocessor communications. The other Prop does the computational work. One example is a CP/M machine which has a performance very similar to the original Z80-based hardware. This has also been done with a single Prop.

Some of the supported hardware for the Catalina and GCC C systems include multi-Prop setups. There are performance issues due to the extra level of interpretation required, particularly with the XMM that uses external memory to hold the program. Caching does help a lot there, but both the run-time library and the memory management are heavily optimized as well to support good performance.

Feel free to experiment, but I think you'll find that you're moving too quickly into a design before understanding both the power and the limitations of the hardware.

There are plenty of existing DOSes including KyeDOS and some of the experimentation by Cluso99 and others on device independent I/O. See what others have done. There's a lot of good ideas out there and a lot of existing experience and discussion on the problems with some ideas.

pedward

The PropGCC project has developed a rudimentary kernel for doing a lot of what you are discussing. The kernel does multi-threading, both cooperative and multi-core. The kernel also provides device drivers for serial, console, and file access.

Duane Degn

The most common reason I've found for using two Props is for video. Many of the video drivers use a lot of RAM and there ends up not being much RAM left for programming additional tasks.

I think you'll be in a better position to make your Propeller PC plans after you have a more programming experience with the Prop.

Wolfy

Understandable on the waiting part, it is just food for though right now, but I do wish to see this come together. As far as memory issues go, swapping bits in and out from an EEPROM or RAM chip does sacrafice performance, but you can optimize enough to get the job done if you're not worried about speed. As far as the GCC kernel goes, I'd like to do everything in spin if possible, again speed is not an issue for me. I really don't want to learn C...but given that from what I understand, the prop already operates in round robbin, developing an OS that follows this would make things a bit easier..yes? Or just to an extent...

And the bottom line purpose is to build a homebrew DOS computer just to say it could be done, while cramming a power pack worth of function into it!

pik33

I, too, am thinking about 2-prop machine and system for it, but at now, I have to gain some experience.

My idea of this machine/os is evolving as I program and use simple things with Propeller (at now, video driver)

At now...

Propeller 1 - or 2 of them - is a good candidate for retrocomputing. Writing a c64/Atari 8bit and maybe Atari ST emulator. Then, a lot of software is available to use. Yes, they are available on PC - Atari, amiga emulators.. all with these delays and glitches...

Also, Propeller will be good as synthesizer, MIDI machine and game machine.

I need an OS to detach a propeller machine from PC. It should be standalone computer; it can communicate or be programmed with pc, but it should be programmable without pc. Then, a programming language is needed. Maybe a good 8-bit Basic port? Atari Basic has a compiler, too. And, of course, assembler... There is Forth, but it seems to be too exotic,

A Propeller 2 seems to be a good candidate for more advanced retrocomputing. With its 1600 MIPS it should have sufficient processing power to emulate Atari ST, Amiga and PC DOS machines. Its 96 or something i/o pins gives us availability to even make a 16-bit ISA slots to connect old, good PC expansion card. I have a Gravis Ultrasound and AWE64 Gold, they are still working and its sound quality is very good. and they are fully documented.

So we can have a real computer, with sufficient processing power and --- with full freedom of programming it. A millisecond MIDI delay, available only on good old ST is now available with a Propeller. And this is one difference: ST is not in production; Propeller still is.

Wolfy

We can write a DOS with APIs, it would be simple but effective. The reason for the BIOS in Cog 0 would be to make it possible to reassign the port pins, except for video pin which would be dedicated. BIOS would also control video resolution and system clock multiplier.

Possible Software Stack:
BIOS
Bootloader
Kernel (provides uniform calls from the CONFIGURED BIOS to user applications, which would make the OS board independent)
System Routines (CPU Sched, Memory operations, and mailboxes)
API Libraries
Shell
Application "VM" (A simple application VM or runtime would protect the system from application crashes and hangs)

This simple OS would be easy to expand, capable of running on multiple boards, and round robbin fashioned to manage both chips. Now, we could go to using only one prop, but we would be limited to much less API calls and the OS would have major short comings. I'm trying to set out a standard for the project, something that can be easily followed and agreed upon...

Mike Green

Successful standards are not proposed out of "whole cloth". They generally reflect a lot of experience with the system involved and previous successes. They tend to codify what already works, possibly combining and integrating existing tools / packages / etc. Learn what's been done already first. See what works well and what doesn't work well and figure out why.

jazzed

Wolfy wrote: »

Understandable on the waiting part, it is just food for though right now, but I do wish to see this come together. As far as memory issues go, swapping bits in and out from an EEPROM or RAM chip does sacrafice performance, but you can optimize enough to get the job done if you're not worried about speed. As far as the GCC kernel goes, I'd like to do everything in spin if possible, again speed is not an issue for me. ...

The problem with swapping bits in/out of EEPROM/RAM with Spin is the memory space and virtual address space is limited to 32KB (without a whole lot of tinkering around). Some day that barrier will be lifted. Meanwhile GCC and other solutions address ranges are practically unlimited.

Wolfy

Which isn't too big of an issue for small programs...I wouldn't think, I'm not trying to create a power house or super microcomputer. 32K + adt. 32K gives me 64K correct? I don't think this would be too much of an issue, seeing as an old friend had a dos box that ran on 28K plus an expansion card that gave it 48K total. All is done just to be proof-of-concept, no more and no less.

Another question, can a GPL license the code that I write and derive?

jazzed

Wolfy wrote: »

Which isn't too big of an issue for small programs...I wouldn't think, I'm not trying to create a power house or super microcomputer. 32K + adt. 32K gives me 64K correct?

That depends on how you want to use that memory. In Propeller 32KB of HUB RAM is available for general code and data storage; 16KB of COG RAM is available for PASM code that can run in the background. You can swap HUB from a backstore if you like, but Spin doesn't really make that easy.

You can load and run individual Spin programs that are 32KB or less as much as you like. There are several systems available that let you do that today. Small programs can be loaded from SDcard and run very easily.

I'm sure you'll hear even more from folks who have done this already.

Wolfy wrote: »

Another question, can a GPL license the code that I write and derive?

GCC 4.6.1 is the basis of the Parallax Propeller-GCC compiler. It is subject to the GPLv3.1 RUNTIME exception. It doesn't require you to GPL your non-GPL code. http://www.gnu.org/licenses/gcc-exception.html

Wolfy

jazzed wrote: »

That depends on how you want to use that memory. In Propeller 32KB of HUB RAM is available for general code and data storage; 16KB of COG RAM is available for PASM code that can run in the background. You can swap HUB from a backstore if you like, but Spin doesn't really make that easy.

You can load and run individual Spin programs that are 32KB or less as much as you like. There are several systems available that let you do that today. Small programs can be loaded from SDcard and run very easily.

I'm sure you'll hear even more from folks who have done this already.






GCC 4.6.1 is the basis of the Parallax Propeller-GCC compiler. It is subject to the GPLv3.1 RUNTIME exception. It doesn't require you to GPL your non-GPL code. http://www.gnu.org/licenses/gcc-exception.html

I meant that I want to GPL all of the code that I write, given that I do any time soon, would that be acceptable?

And you make a valid point there on the memory, but you could jus cache with files on sd even though thats another performance issue, jus cache the global variables and addresses into a txt file, should work for small scale stuff?

pedward

As far as licenses go, if you contribute to a project, the license you choose must be compatible with the project's license. If you are writing something from scratch, you can choose whatever license you want.

Parallax licenses their code under the MIT license, which is very permissive.

GCC is licensed under GPLv3, which is very restrictive for business use, but very open for personal use. Basically, you can't take GPLv3 code private, extend it, use it, then not release it. With GPLv2 you could take it private and do all you wanted, as long as you didn't release the product of the code, you didn't need to release the code. The GPLv3 was seen as closing this hole.

The "hole" is illustrated with a simple example: Company X takes the GPLv2 code of Product Y and extends it greatly, using it as the backbone of their company. As long as they don't distrubute their modifications in any way, they are not compelled to disclose the modifications or license them under GPL.

The GPLv3 basically says that any code anyone writes, is virally tainted by the license; you are compelled to license any internal modifications as GPLv3 and make them publicly available, even if you don't distribute the product.

I have been professionally restricted by this limitation, the company I work for has extensively modified a GPLv2 product for internal use and I must be careful not to use any GPLv3 publicly available code when extending it. This means rewriting certain things from scratch even if a valid extension is available.

jazzed

Wolfy wrote: »

I meant that I want to GPL all of the code that I write, given that I do any time soon, would that be acceptable?

People here tend to use MIT License for sharing. MIT License requires keeping the copyright of the original author for substantial copy and offers other protections. See http://obex.parallax.com/license/

Wolfy wrote: »

And you make a valid point there on the memory, but you could jus cache with files on sd even though thats another performance issue, jus cache the global variables and addresses into a txt file, should work for small scale stuff?

Sure. I look forward to seeing an example.

Welcome to the community.
--Steve

Cluso99

Wolfy: You have some great ideas. As has been mentioned, there are a number of us that believe a prop os is needed. We have built upon the code that has come before. We still do not have any real consensus to how it will work best. I guess this is just because it really is still in its infancy. Keep up the thoughts and take a look around at what has been done.
Dave Hein has produced a *nix style. Michael Park produced Sphinx. I have been working on an extension to KyeDos, trying to bring with it some of the work Sphinx did, and some of my own mixed in.

prof_braino

Wolfy wrote: »

An advanced, yet small, and powerful operating system for the propeller shouldn't be to hard given the right coordination and drive to do so. We could be looking at a multi-propeller system. Since it doesn't look too complicated to code hardware into software stacks, it should be easy to bring the following into the OS: Ethernet, VGA Video, Keyboard, Audio, Bus Lines, SD Storage, and Serial Port. (please, keep in mind that I thinking with the concept point of view, we'll be using two props in this scenario!)

Please remember that this is only a concept.

If you are willing to give propforth a try, pretty much all the stuff you are looking for is already in place. http://code.google.com/p/propforth/ All the material is free to study and use.

All the pieces have been presented and refined, next release we will start bringing the extensions and alternate kernel configurations (e.g. Jupiter ACE standalone development system) up to the current 5.x release level. We already have paged assembly, executions of scripts from SD (allowing gigbytes of memory), and synchronous serial for linking multiple props or any configuration of props to a PC or workstation, which has proven to be rock solid for the last month. Ethernet support using spinerette or WIznet5100 has already been demonstrated. The system already demonstrates excellent performance, given what it is and what its doing. We have not found a need for external memory besides the EEPROM and SD yet, of course adding it is certainly possible.

The method used is to keep everything as simple as possible, keep overhead to a minimum and we get the functionality so we can pretend the prop can act like a PC. Of course because of this the prop will never be a real M$ Windows PC or Apple OSX PC, but it can do most of the basic functions that a PC does.

This runs great on one prop 1; and we can easily and transparently add as many additional props as you have, and you can directly connect them up to your full blown workstation for additional processing and storage services as needed. Right now we're using 32 bidirectional channels which can be between any cogs or the workstation(s). At the moment they share a single physical serial connection at 230400 baud, so each channel does about 2000 character per second max, but in a bit the channels will be moved to Ethernet and the speed will go up accordingly.

I invite you to take a look at the project, we've already got 5 years of work in place and its almost finished. It might serve as starting point of examples and things to use or improve on your project.