Future directions for Propeller OS?
Mike Green
Posts: 23,101
The FemtoBasic EEPROM/SD-Card low level I/O routines are those developed for the Propeller OS. In trying to retrofit these back into the OS, I've run into problems, mostly memory limitations. Rather than trying to patch and mend, it may be time to redo a lot of it. The basic idea is that I would like to have a core of I/O routines that get loaded into cogs during initialization and stay there, running, while applications that use them may be overlaid over the "command interpreter". The core I/O routines should include a combined keyboard and mouse driver (with mouse optional), an EEPROM/SD-Card read/write/load package, and either a VGA driver or a compatible TV driver with cursor support. These should support the Hydra / Demo board / Proto board conventions with one set of source files. VGA and SD-card use will normally be mutually exclusive on the Hydra due to the way the VGA display and expansion port use the same I/O pins. Clearly, someone could modify the Hydra board to connect an SD card to other I/O pins and the source could be modified for this, but I don't plan to support it.
The EEPROM/SD-Card routines now work. The keyboard driver works, but doesn't include mouse support. The VGA driver works. The TV driver works, but doesn't include cursor support. The display API is independent of the type of display used, but doesn't have support for the cursor or tiled graphics which both display drivers now support.
The "command interpreter" has become unwieldy. Adding new functionality is not practical, particularly SD card support.
With SD card support now possible with minimal hardware and only 4 I/O pins needed, basing further expansion on external memory (EEPROM and/or SD-card) makes sense.
Any thoughts? Discussion? I'm not so much interested in a "wish list" at the moment as much as a discussion of pros and cons and tradeoffs. Currently, FemtoBasic uses the OS's keyboard and EEPROM/SD-Card drivers. I would like to use the OS's display drivers as well for that.
The EEPROM/SD-Card routines now work. The keyboard driver works, but doesn't include mouse support. The VGA driver works. The TV driver works, but doesn't include cursor support. The display API is independent of the type of display used, but doesn't have support for the cursor or tiled graphics which both display drivers now support.
The "command interpreter" has become unwieldy. Adding new functionality is not practical, particularly SD card support.
With SD card support now possible with minimal hardware and only 4 I/O pins needed, basing further expansion on external memory (EEPROM and/or SD-card) makes sense.
Any thoughts? Discussion? I'm not so much interested in a "wish list" at the moment as much as a discussion of pros and cons and tradeoffs. Currently, FemtoBasic uses the OS's keyboard and EEPROM/SD-Card drivers. I would like to use the OS's display drivers as well for that.
Comments
I think a major issue is the allocation of cogs; what functionality goes into what cogs? Especially as not everyone may want
all functionality. At the same time we want to be able to "fill a cog"---put as much functionality per reserved cog as we can.
Right now the SD routines do not (nearly) fill a cog. I could rewrite the FAT16 support as much as possible in assembly, to
minimize the amount of Spin code you'd need to load to use them. But to do this, I'd need to know if I get a cog, or just
part of a cog, or what.
I also think we should review the interfaces between the assembly and spin routines in the interests of simplifying them.
The code overhead of doing masking and shifting of parameters, I think, costs more than just allocating a bit more memory
for the separate parameters.
Ideally someone could come up with a good way to be able to declare a Spin/assembly object so that the assembly part
is only used for initialization/cog loading, and there's an "automatic" way to derive the base client Spin that would be used
by the program that is actually using the code. I'm thinking of as much as possible having a single source code base that
could be used in "normal" programs, but also "separably" as "initialization" followed by "client side". This could be as simple
as some convention we all agree on in the "main" program, and a trivial Perl or other script that would then strip out the
initialization part to yield the "client" side object. Does this make any sense? But the idea is to get away from a big set of
predefined "entry points" or whatnot with all the constants, and just come up with a generic mechanism for doing this
sort of preloading so that it can be used by the OS.
Best Regards,
Robert
Mike, you work is stunning.
David
Currently there is one cog that contains the EEPROM and the low-level SD card I/O. The reason for combining them is for purposes of loading. When loading Spin programs, the whole loader has to be cog resident so the loader can load the entire Hub RAM and some of the code is common. The display driver occupies one cog for TV (and there's room for cursor support in the same cog). The VGA version uses 2 cogs for the video output and an additional cog for cursor support (if enabled ... it's Chip's tiled VGA driver). The keyboard driver uses one cog and there should be room to include a mouse driver. My assumption is that the minimum basic I/O would include some mass storage, keyboard, and display.
Alas, the current Propeller Tool does not allow conditional compilation or even source file includes so it's difficult at best to do any kind of automatic source code processing.
Robert,
Rokicki's SD card routines are in the Propeller Object Exchange. You only need the SD card socket and 6 - 22K pull-ups. There are comments in the SD card routines on how it's all connected.
I really, really like FemtoBasic, which seems to be more useful than the PropellerOS, maybe just because I haven't learned to do much in it.
I would agree with Dennis. Since I am a Unix geek, and ls, mkdir, cd, pwd, cat, grep, /etc roll off my fingertips, sometimes while thinking of what to do next, I would really like the capability and modularity that comes with the unix system. For some commands, arguments will have to be passed, like cog numbers & pins. Come to think of it. The prop could be like an Origin2000 8 processor deskside.....although a bit scaled down ;^)
Doug
You are the expert when it comes to the prop OS, but I see interesting possibilies with what you have done so far.
The prop with mouse/keyboard in one cog, VGA in 2 or TV in 1 cog and EEPROM/SD in another, leaves 4/5 cogs to play with.
I am thinking the EEPROM can be like a bootloader, loading from SD card the drivers for VGA or TV then the OS or programs for the cogs etc.
Pulling functions from the SD would be interesting.
I have not yet had a chance to play with the latest Femto.
Will Femto become the new OS?
Some way to do everything without needing a PC would be cool
Gavin
As I read on how things are progressing and updated / improved versions of femtobasic are released - I can't help but wonder - will a name change follow ? as 'Femto' certainly does not cover the the amount of time and skill involved in bringing it thus far !
Regards,
Quattro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
It is possible, but would markedly complicate the interpreter and slow it down. When programs are stored in memory, the keywords are stripped out and replaced with single byte codes which saves a lot on space and speeds up the interpreter. You can still write huge FemtoBasic programs by using overlays. I had indicated that you could use something like 'load "SDfile" : run' or 'load "SDfile" : goto 100' to do overlays. It turns out this won't work currently, but I'll fix it this weekend. If you use the 'goto' version, the program's variables are not cleared and you can go to a specific line in the overlay.
Quattro,
FemtoBasic was Tomas Rokicki's name for the interpreter (he wrote the original). Now you can think of it as a "tongue in cheek" name.
Are you intending of combine femto and the os in one product? I hope not. I had intended to use the os as the core of a multiprocessor system with a Client/Server structure. The design would have serial i/o, i2c, VGA and keyboard for a user interface on a single propeller with the Client systems using serial i/o, i2c and sd storage. I was hoping to use the os for what it is. My interest in femto basic is limited.
David
These are two related projects. As I've mentioned before, I see the OS really as an integrated set of basic I/O for Propeller applications. The "command interpreter" has been included with the I/O drivers and APIs, but that's primarily for convenience and has worked fairly well until now. I've been using FemtoBasic as a platform for development and testing of the I/O drivers and I've had versions of it that work as an OS application. Now that I have the SD card loader working, I plan to revise the OS to include the SD card support as well as add the additional features to the I/O drivers (mouse support and TV cursor support). The problem I've run into is that the "command interpreter" has become unwieldy. In fact, I can't get it to fit into memory any more with the VGA driver I want to use (Chip's tiled VGA driver). I may make use of pieces of FemtoBasic to simplify and shrink the command interpreter.
To more directly answer your question ... The existing package of I/O routines will be expanded to support a mouse and to be compatible with graphics and a cursor. The use of the mouse, cursor, and graphics will be optional. There will be some integration of SD card and EEPROM file system code now that the SD card I/O is working. It may be that I'll switch to using a FAT file system for EEPROM which would allow several small named files to reside in a 64K EEPROM. It'll take some experimenting to see if that's practical and useful. I suspect that the 1st 32k of any boot EEPROM will always be treated as a single file because of the way the Propeller Tool works. For the Hydra, the 1st 32k of the on-board EEPROM would also be a special case (as it is now) when a memory expansion card is installed.
I was hoping that the real title was not "future directions for propeller os" if any....
David
Nope. I've got a couple of proto-boards with the keyboard/mouse/VGA display connectors. They come standard with 64K x 8 EEPROM and an SD card breakout board from SparkFun mounts vertically very nicely between the VGA resistors and the power switch. What a great platform for development! As with any project like the OS that has grown over time with new features added, it's time to throw out pieces of it and redesign and reimplement those pieces in a more integrated fashion. The OS's command interpreter is the part that badly needs this and some other parts (like the EEPROM file system) will get cleaned up too.
Mike
Would you post a jpg of your setup. I am very new at soldering on things like the proto-board.
For me, an example is worth a thousand words.
First , congratulations. Regardless of the never ending nature of creative design. What you've done so far is pretty impressive.
I personally think this kind effort is worth it, even if you run into a stone wall at the end. If I were capable of this kind of work... I would do it just to enhance my own understanding of the Propeller-Spin-Assembler triad.
I've been doodling various systems mostly for diagnostic equipment... and then look to see if there is anything about the Propeller system that is missing... and I haven't found anything. There are some limitations, which would keep me from trying to use the chip right now... except for rough cut design planning. But I mostly know those limitations because the Parallax folks have discussed them here... and obviously will make them better in the next version.
The one serious question I have is... what functionality isn't already present in the overall product that you need. Or is just getting rid of the computer interface components the goal?
I personal would love a small stand-alone self contained system, but I don't see how you could ever put as much into it as you can with the computer attached. Everyone has different preferences... some like command line control, bare bones and others like the work that goes into a nice user experience on the computer. So, there is definitely a place for both approaches.
I think the most interesting possibility that is being actively discussed is the multi-prop option. I love 3D... and I would love to give my son a propeller hat with oled's in the visor and a robot with a stereo camera/transmitter to drive around.
You guys are going to make that possible...
Thanks
Rich
I think what's driving this effort is that the Propeller as it stands, set up on a Proto-board with the accessory kit and an SD card socket is already much more computer than I was using for stand-alone commercial development of what were major pieces of software 30 years ago. There is simply no reason why the Propeller can't be used for its own software development at least some of the time.
Mike
Thanks.
I certainly agree with you.
Rich
AND... 30 years ago, it was a simple matter to reach down through the interface and actually talk to the processor. I have routines, written in modern languanges... that work just about as well as they did in assembler...30 years ago. But now, when I want to talk to the processor I am expected to change the kernal... as if I can do that without just blowing up the box!!!!!
So long as you avoid that little problem... anything you can do would be more than worthwhile.
Rich
I don't want you to stop what you are doing... but when you get tired... and you want to do add something that is at least of marginal importance... I was doing some work on number theory... and I needed the bignumber function....from God knows what interpreted language... which was incredibly slow. And I wanted to convert that function into a color-object. So... if you could put a bignumber function into your language... I would use it.
bignumber is a way to precisely work with integers of any scale... limited only by the amount of memory used to hold the integer.
A rough cut at it would be more than sufficient.
Rich
The other thing... which you didn't say, but which is no doubt true. There have been so many languages and so many new devices to come along... that most guys in our generation... would take one look at Spin and think to themselves... "Boy that is slick. When these guys make some form of Basic available... then I'll get back to this and try to do something with it."
Rich