What should a Propeller OS have? (Sphinx/SphinxOS, PropDos, PropCmd, FATEngine,
Cluso99
Posts: 18,069
There are a great number of developments going on and that is great. However, everyone seems to be doing something different and I see a lot of time and energy wasted.
Sphinx / SphinxOS
I was inspired by Michael Park's (mpark) Sphinx. Why?
FATEngine
Kye has done a magnificent job. He has a particular audience at his University. It is extremely well documented.
IMHO it is the opposite of Sphinx, in that it is one big program and makes all user programs become standalone. So, I do not consider it is an OS as such.
Much of his code could however, be used in modules under SphinxOS.
My Vision
I would like to see something based on Sphinx which I have called SPhinxOS. We have an absolute minimal EEPROM boot code which boots the OS as has been·discussed here http://forums.parallax.com/showthread.php?p=911849·It is almost identical to what I have in RamBlade. The only hardware the EEPROM boot code knows about is the SD card pinout. The SD card contains the binary files to run. This way, we do not have to reprogram the EEPROM boot code ever (optimistically).
There are already drivers for TV, Keyboard, Serial, 1pin TV, 1pin Keyboard, and SD (needs replacing).
SD Driver(s): I had originally used the femto drivers, and later used the fsrw2.6 drivers. We now also have Kye's driver(s). IMHO, what we need is to standardise on one SD low level (fast) driver and place as much support as possible withing the cog. This could just be the buffer if there is enough space available. All the upper level FAT16/32 code can be an object called in your own programs.
The EEPROM boot code can run any program (named as a parameter in BOOTPROP.BAT), and otherwise runs BOOTPROP.BIN, else it stops. If SphinxOS (or whatever we all decide) is run, then we have an OS that is capable of DIR, TYPE, REN, compiling, launching xxxBasic, Catalina C, Forth, any emulation, file editing, etc, etc, etc. Each of these OS aware programs will be much easier and simpler. We as a community, will be able to build these addons much faster if we accept some form of a standard OS.
What are your Visions??? And how do we get there???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Sphinx / SphinxOS
I was inspired by Michael Park's (mpark) Sphinx. Why?
- The big advantage I saw was the I/O & SD drivers were stay-resident drivers within the cogs using a few upper hub ($7FFF...down) rendezvous locations to pass the I/O data. Much of our code could be written as I/O & SD independant which would allow for precompiled binary distribution.
- The·SD drivers use 3 cogs. I·believe this needs changing as 3 cogs is not acceptable.
- All the OS commands such as DIR, TYPE, etc are seperate binaries so extra commands·can be written simply by anyone without changing the basic OS.
- The OS itself was therefore a minimal footprint.
- The Spin/Pasm compiler could be recompiled to run under any propeller OS.·
- User programs can be written as Sphinx aware (uses the I/O & SD drivers) simply.
- User programs requiring the total Prop resources can also be written and run from Sphinx.
FATEngine
Kye has done a magnificent job. He has a particular audience at his University. It is extremely well documented.
IMHO it is the opposite of Sphinx, in that it is one big program and makes all user programs become standalone. So, I do not consider it is an OS as such.
Much of his code could however, be used in modules under SphinxOS.
My Vision
I would like to see something based on Sphinx which I have called SPhinxOS. We have an absolute minimal EEPROM boot code which boots the OS as has been·discussed here http://forums.parallax.com/showthread.php?p=911849·It is almost identical to what I have in RamBlade. The only hardware the EEPROM boot code knows about is the SD card pinout. The SD card contains the binary files to run. This way, we do not have to reprogram the EEPROM boot code ever (optimistically).
There are already drivers for TV, Keyboard, Serial, 1pin TV, 1pin Keyboard, and SD (needs replacing).
SD Driver(s): I had originally used the femto drivers, and later used the fsrw2.6 drivers. We now also have Kye's driver(s). IMHO, what we need is to standardise on one SD low level (fast) driver and place as much support as possible withing the cog. This could just be the buffer if there is enough space available. All the upper level FAT16/32 code can be an object called in your own programs.
The EEPROM boot code can run any program (named as a parameter in BOOTPROP.BAT), and otherwise runs BOOTPROP.BIN, else it stops. If SphinxOS (or whatever we all decide) is run, then we have an OS that is capable of DIR, TYPE, REN, compiling, launching xxxBasic, Catalina C, Forth, any emulation, file editing, etc, etc, etc. Each of these OS aware programs will be much easier and simpler. We as a community, will be able to build these addons much faster if we accept some form of a standard OS.
What are your Visions??? And how do we get there???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Comments
To simplify things down to the most basic level, I think all that is needed is the ability for any program to be able to do a 'warm boot' when it ends. Instead of just ending by going into a repetitive loop, it ends by shutting down cogs and reloading the KyeDOS code into ram and running it. The code to do that exists already. And I think on another thread pullmoll has added CTRL-ALT-DEL to some of the emulations. So it can be done either by a program or by a user. In practice, a warm boot is really the same as a cold boot (pushing the reset button), but maybe you might make them slightly different - eg if an autoexec file was running, a warm boot would get the next entry but a cold boot would start at the beginning.
Then you can mix and match Spin, Catalina, PropBasic programs. Each program is self contained with its own methods of handling cogs. Each program could do something very simple - a Catalina program that sends "Hello World" out the serial port then ends and goes back to the operating system.
If programs also can create and read small text files they can even communicate with each other or even chain one to the other.
Sphinx can become one of the programs in KyeDos. (Or the other way round if you like). You boot up into KyeDOS and type SPIN SPHINX and it runs sphinx and any of the programs in sphinx.
As for whether you boot into sphinx or kyedos or propdos - I don't think it matters. And it becomes very flexible if you can move from one to the other (ie if an OS can run a binary that happens to be another OS).
I don't think there are any 'rules' with the above system. Each operating system can keep growing and adding features. Of course, sphinx has its own internal systems and rules.
From a practical point of view, I guess one thing would be to get Fat32 support on as many programs as possible.
As for a tiny eeprom program to boot others, I can see a way to do that quite easily now. Would you like me to write some code?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 6/7/2010 5:57:00 AM GMT
Obviously that will not happen with MSDOS compatible file systems.
The ext2 Linux file system appears to be my only hope.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Should be a lot simpler/smaller than ext.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Ctl-Alt-Del makes a lot of sense. And yes, we need both warm and cold boot. I do not see any problems here.
I, like you and others, see FAT16 & FAT 32 as a requirement.
However, wouldn't it be better if we all pooled resources instead of each of us re-inventing complex solutions???? IMHO, an OS with drivers and lots of simple programs such as DIR, LIST, DEL, etc makes more sense than a large program with hardware specifics. This doesn't mean we cannot run them (such as the emulations) but wouldn't it be easier if the drivers were already in the cogs, so that precious hub code space could be available for the remainder of the emulation???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Max FS size 64MB, Max file size 64MB, Max filename 16/30 c, ....
Is there a utility available for windows users? There are tools for ext2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Access from Windows may be a problem but one can always run Minix under VMware or VirtualBox or whatever and share files that way.
minix1.woodhull.com/faq/filesize.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The way I go is similar to the Spinx approach. I put the PASM part of ALL the drivers in upper EEPROM. I modified keyboard/tv/sd/FullDuplexSerial and my own drivers for graphical LCD/text LCD. The 'application' then only has to load the driver by using a minimal CogOSCore, simply by giving name and version number of the driver and using the _NP (no PASM) SPIN code of the original driver. This also helps if the system that's going to be build is a standalone system. There an OS is overkill in my opinion as it only doubles startup-time. But storing the PASM part of the drivers in EEPROM gives more HUB-RAM for the application.
But I also want to have a table of loaded drivers in upper memory for applications that are meant to stay on the general purpose-platform. For such an application the OS will read a config-file and load all needed drivers before loading the application. This way the app does not even need code to load the drivers.
So, from my point of view it would be gread to introduce a driver code paradigm like: The application should be the master of the buffer for passing parameters to the PASM-driver, not the driver itself. Because that allows to manage the drivers and the parameter storage area. Maybe it would also be cool to have drivers that can suspend themselves to vMem and continue their work after resuming.
Other plans are to convert my vMem into PASM as it turns out to be very usefull for me. It allows to have a SWAP-space for data. (Currently it's only using SD card but in future I'd like to support EEPROM, RAM ...) What I did the last days was to put all the text messages / help texts ... into vMem, so these don't waste HUB-RAM and are easy to access.
As the keyboard reader of·the OS uses the same code that I posted in the Obex as ConfigReader, it will be easy to allow OS-Scripts later.
Cool thing would be to have a User IO system which can be easily switched from Keyboard/TV to FullDuplexSerial or any combination - during runtime or at least via config-file.
If there is some interest I can post the code - but plans are to wait until I have some kind of an installer. The CogOS itself needs the drivers to be in the EEPROM and of course a OSSWAP.SYS currently only containing the text.
PS:
By the way ... I have a nice run implementation which runs an EEPROM-file for a given time (of course it only works for applications that don't need all COGs).
Post Edited (MagIO2) : 6/7/2010 8:52:53 AM GMT
@heater, that's a good update. Thanks.
I would like to run a small Unix OS (OMU?) on Propeller if possible. Bill's VMCOG efforts and desire to support any hardware will make that and many things possible. Of course I prefer Linux as a developer and a user, but that's just not gonna happen any time soon and even if it does, it would boot like a snail.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
I am a potential user of such an OS, actually I use SPHINX for a project.
My wishes:
1. Stable (SPHINX has not shown problems here)
2. Needs only minimal hardware (like SPHINX). For me the Prop is a CONTROLLER, no PC, no Linux machine....
3. Has to be compatible with the demoboard (like SPHINX), most of my projects start there.
4. Has to use a file system, that can be read/written by Windows (like SPHINX)
5. Fast restart of the OS after program (like SPHINX)
6. Easy direct·built-in download feature put/get of SPHIX has proven to be very useful
More additional wishes and their·priority:
Interface of PropBasic to file system - very high
Subdirectories - medium (They are nice, but not soooo much needed in a small system)
Batch Programs - high
Optional Date/Time stamp for files would be helpful sometimes. medium-high
More free cogs (SD-driver in one cog, keyboard driver should be possible without own cog?) - high
Debug features - high
A local Propbasic compiler? - a dream
Documentation - very important
Christof
I think with SD we could create a very simplistic and yet sufficiently fast file system that looks just like a linked list of used and unused memory ranges on a heap.
It should be possible to write a file system driver for Windows to access SDs in this format. There have been way more complicated fs drivers available, e.g. for ext2.
For Linux and the *BSDs there is FUSE, for Mac there is macfuse, and all we would need was to write a simple plugin for that thing to cover all OSes.
The only thing we would need to define is a directory entry format. IMO we should go with 64 bit fields for everything, even if 32 bits seem sufficient now. Talk about 2049 and the 32TB limit of the file system Foobar.
How about
In case of fragmentation, i.e. when using a deleted file's space to create a new one and then detecting it won't fit, the next chunk could be defined the same as the first one, just with a different file type or flag bit in there, e.g. flag continuation.
ASCII maps to UTF-16 by just setting the MSB to $00. Latin-1 (ISO-8859-1) can also be handled without problems. On Windows you may have some fun with converting UTF-16 to your code page, but that isn't my (our) problem in the first place. Most *nices are Unicode capable now.
The very first block on the SD would be defined the root directory's first entry (/), the second block would be the free list anchor. These blocks would rarely be modifed, because changes would be done to the tails of the chains or somewhere in the middle of the chains in the case of the linked free list. Consequence: no excessive wear out of something like a FAT.
The file operations should be easy to do in Spin, while I would be willing to try to implement them in PASM, so they cold go into the same cog that handles the SPI block commands.
What do you think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
Post Edited (pullmoll) : 6/9/2010 12:34:09 PM GMT
However, with the system I am proposing, the FAT driver could be replaced without the other programs knowing or caring.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
We need support for VGA,TV, and SERIAL. It should be easy enough to support all of these at the same time.
We also need a standard for passing command line and "current' directory information.
As for music players, editors, etc, these can all be separate programs.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 6/9/2010 5:16:38 PM GMT
Maybe stored as an editable file on the SD card or even hard configured in the OS Code.
This could be passed to an area of HUB RAM that isn't replaced with the loaded program and say something things like "Video is NTSC starting on Pin 12", "Audio is Mono on Pin 4", "PS/2 Keyboards is at Pin 7", etc.
Would allow for people to compile .bin programs that can remap to the hardware! :]
Just an Idea.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Share the knowledge: propeller.wikispaces.com
Lets make some music: www.andrewarsenault.com/hss
About 80% down this page: http://forums.parallax.com/showthread.php?p=732725
Yes, that is a nice link and if someone wants to standardize on that, it's fine by me.
Of course that could also easily be added to the existing light-weight and reliable FSRW
versions which do not have directory support.
The challenge though seems to be mostly in re-indexing the files when changes happen. Where and
when do you re-index without further bloating the file system manager or making it a user PITA?
--
The purpose of a Propeller O/S seems to be to provide flexibility for those users who need that.
Flexibility comes at a cost of course, and not all solutions can handle the waste caused by such flexibility.
--
If an O/S had a decent shell scripting language and support for parameters/exit codes I might be a bigger
fan of the idea. Most people here probably don't understand what that means though so it's a moot point.
At minimum, having file access and running programs from the SD Card for those who need it is useful.
--
BTW: There was a great amount of effort put into pin-maps last year by many contributors. There are
many solutions including one from a very famous poster who no longer has much to say for some reason.
I doubt his solution will be seriously entertained though for various reasons.
The OP probably has developed enough good will to get pin-maps done one way or another this time around.
Be thankful for that if that's what you really need.
--
There is a lot being discussed in this tread that is not new. It is just more addressable now for some reason [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Who needs the pin information? The drivers! So, all we need is a *.SPIN file with standardized constants that have the right PIN number. Every driver should include this constants only 'object' and use the appropriate constants. This file is never packed into a source-package. In this way everybody who compiles an application get's the drivers setup with the right PINS. And if a interface is not available you get an compile error because the PINs are not defined. You'd have one of those PIN definition files per propeller system.
For applications the model of storing drivers in the upper EEPROM and/or on SD card is the best way in my opinion. You have the PASM code of up to 15 drivers in the upper part of a 64kB EEPROM. A descriptor table contains a list of drivers. The application program would simply use a library that can handle the driver-table. And it simply says: I need FSRW version 1.6, FullDuplexSerial version 1.0 ..... and the driver will be loaded.
As the hardware relevant part (the pin assignment) is contained in the PASM, the application itself will be interchangeable because every propeller board has it's own set of drivers compiled with the right settings.
A bonus of this is, that you have more room for the application code, as the drivers SPIN-files do no longer contain PASM. You only need a buffer big enough to load the drivers (2kB) and once the drivers are loaded this buffer can be used for other purposes.
When I'm back home I'll post a piece of code, because I already have this driver model running.
PS:
My idea is to have an "installer" for drivers in the end. You load the driver from ObEx and if you start the drivers-code, it will use the serial interface to ask you the right questions about the system it's going to be installed on. For example the pin numbers. With this information a init-routine is called and it changes the PASM variables, constants maybe even code according to the settings. Then this driver is stored in EEPROM or on the SDcard. From this time on each application can use that driver by simply including the xxx_NP.spin of this driver (NP = No PASM ;o)
Post Edited (MagIO2) : 6/10/2010 6:43:57 AM GMT
My expectation is that the pins for the standard drivers are passed by the OS when those drivers are loaded.
It may/will not work to have a standard set of pin defs for each prop. Why? Well, what do you do when you have a board that has both VGA and TV. In some circumstances you want TV and others you want VGA. We can control this by booting one and changing to another. Even re-loading the driver should be possible. This can come provided we do not create closed systems.
So, this means we could store drivers for various VGA formats, TV, 1pin B&W TV, Keyboard, 1pin Keyboard, Serial (as standard keyboard and display substitutes) and Serial (as a serial driver). They could all be precompiled standalone binaries (with a common interface) and stored as·xxxx.DRV files. The OS passes the pins and optional parameters when loading the driver.
I am personally against (at least for now anyway) writing to EEPROM. I also have an issue on RamBlade because the EEPROM is disabled from being written (although I don't think this is my reason). I just do not want the basic boot code to change per prop system with an SD card. The SD can contain any parameters required. Just my opinion and I could be swayed.
jazzed: Yes, a lot has been discussed previously. I think we are now much more advanced and this is now seen to be an issue that we need to solve quickly before we cause fragmentation. Better to pool our resources and get something we can all contribute to. If we can remove the standard I/O from the equation, we can all write extra OS functions as small standalone binaries. I suggest we call them xxxx.BIZ or something other than xxx.BIN as .BIN should be for complete standalone programs requiring the whole prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Personally, I am moving to a model where every cog driver/virtual machine/program/? I build is standardized on PAR holding a pointer to a four-long block for parameters, where the first long is the 'command', with three 'argument' longs.
The reason I use a long for the command is that I can pack a 9 bit command and 23 bit address into it easily with mov and movi, and it is just as easy to unpack.
This fits perfectly with using simple spinners to wait for commands.
This also makes it trivial to launch those cogs - just load the 2KB (or smaller) image, and cognew it passing the load address and mailbox address.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The other extensions, .bin, txt, etc... all work for their stated purpose. A SPIN bytecode file, if somebody chooses to do that, should be .spn
I like .bin for a standalone program that takes over the Prop.
@Jazzed, if the TRANS.TBL capability were written as wrappers for the current driver, anyone could make calls through those for long name support. That gets it done for the prop. One more wrapper for mounting a device would deal with indexing on the case of files created externally. I believe TRANS.TBL functionality is still in Linux, but is not in windows. Somebody will have to check Mac OS. Either way, it's not a big deal there either. Adding an extra file externally, could happen with a simple edit to the TRANS.TBL file, and a quickie Perl script, or binary could be used in a pinch for those needing to deal with lots of files. It's a low cost option, that's all, and one that doesn't break anything else.
Building it in standard, and or making a new file system, or incorporating it into the core driver all come with a cost that most people don't need to pay.
In any case, it was just an easy suggestion, for the case where long names are needed. They can be had for a pretty small code cost, without really impacting the other goings on, that's all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 6/10/2010 2:56:01 PM GMT
@potatohead,
Yes I'm painfully aware of the cost of adding features to Propeller that consume memory ... a leading contributor to "Propeller Neurosis."
@Cluso99,
OK, I'll play.
--
I'm attracted to some ideas such as being able to load/run a COG on demand and allow it to be recycled. You know this from the "post-boot PASM loader" thread where you shared some of your thoughts. I would like to see that mature.
--
Not everyone needs pin-maps, but I guess it makes since to create something that everyone can use ....
However, I am solidly against permanently using any big precious block of Propeller memory for that purpose though and believe that the drivers should be given the pin resources when they are started which is typical of most drivers today.
The devil is in the details of that though and I invite you to propose a reasonable solution that does not involve reserving a 256 byte block of memory.
Here are some thoughts in that direction: Since an O/S would use sd-card, etc... getting the pins from a file like has been described in some form more than once now seems very palatable. There is precedent for this in other O/S.
--
Seems to me there are extensions other than .bin (which take over the Propeller completely)
that make more sense than .biz (isn't that a web address extension?).
Here is a list of more .extentions to entertain:
- .prg for program
- .cmd like the old dos cmd files (could be confusing?)
- .exe pretty clear where that comes from (could be confusing?)
- .spn as potatohead mentions
- .utl for little utility programs
- .psh for Propeller shell programs
- .cog for cog programs which may be recycle-able
- .??? others' ideas of course welcome
--One other thing that is important to me is being able to pass parameters and collect exit status of programs.
Oh, did I mention that already? I'll mention it again and again and again.
Cheers,
--Steve
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Yes, Ariba has what I think is the best take on the issue here.
Can we move from 64k eeproms to something bigger?
I hate to give up the idea of being able to dual-boot when an SD isn't inserted.
(I've been hiding a copy of Femto in mine for when Propdos doesn't find what it needs)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
FUSE sounds like you create a single FAT file that (maybe) fills the SD card, but then within that file's data space, you build a completely independent embedded filesystem, is that right?
So with FUSE, you preserve the ability to transfer data to Windows, yet also get the ability to design the best filesystem for your particular project (entirely within that FAT file.)
I like it!
I've got a handheld portable propeller-powered GPS logger to SD card, and its weakest point is the corruption of its SD card FAT filesystem for various reasons, like powering down without closing a file, or running low on battery power.
My kludgey fix was to open a new file every 32K of logged data, to minimise data loss in case the final file was corrupted, but FUSE seems like a much better solution.
I'd be interested in a FUSE filesystem.
Just saying use $7FF8 for one little piece of data is a non-starter (except that you have to know where the starter pointer is). A very simple linked list that can be understood by any application would be fine so that the end of the "resources list" can found. I.E. some $7fee contains the top of list pointer and $7fec contains the end of list pointer. Then $7ff0 to $7fff can be a free-for-all area for any given application.
Cheers,
--Steve
EDIT: removed a different non-starter idea [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Post Edited (jazzed) : 6/10/2010 10:20:34 PM GMT
As I had no time to it -I not looked on this thread.
BUT now I see some discussions that I proposed long-ht time ago.
And see that my idea on Mail-Box controlled Drivers are Still alive. On my first idea that Drivers was supposed ti live in High part of EEProm to Systems that use them.
BUT if BOOTER are not BIG maybe Standard drivers can fit in first 32KBytes after Booter code And some table (FOR pin's and memory used) to other drivers that can be placed on SD.
I know that need some rewrite of drivers BUT can give much usability in all types of OS-type programing.
Regards
Christoffer J
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
- .bin for a program that takes over the whole propeller (what we do now)
- .cog is a great extension for cog drivers
- .spn is used by mpark's compiler for .spin source on SD (so it cannot be spin bytecode)
- .??? for spin bytecode (reserved)
- lets not use .cmd & .exe (confusing to other oses)
- .pgm for utilities and os aware programs that use the drivers (like .cmd & .exe).·.biz was typo for .biz. -·I really prefer .pgm to .prg
mpark: Yes, I move my SD card to other props. Not sure how to handle pin definitions between systems, let alone the one system. We can already change pin definitions within the one hardware system, and this will get more complex that a pc as I see some pluggable peripherals on various pins.As for the memory map of upper hub...
Lets discuss this bit so we can settle on something. The buffer allocations can be made by the os when loading the appropriate driver. I am NOT suggesting to do a linked list!!! Just update the "free" pointer at $7FFF.
re FUSE:
It is sort of like we are using in the emulations except we are making each CPM drive a single file instead of a single file for all drives. To me, a file for each drive made more sense as we could change drives and load more drives later from the pc direct to the SD card.
I have no problems with this except that they will not be accessible from the pc. However, if we have a single os aware program to copy them from the normal FAT16/32 to the FUSE directory structure this could work. It could be like a subdirectory. This could have benefits of placing the os files (.pgm) here to save filling the root directory. Comments???
BTW: I know various things have been proposed by various people before. That's great because if they surfice again it shows they have merit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Normally you start writing some spin code and keep going till the ram runs out. Then go back and optimise the code, add external ram etc.
Cluso is starting from the top of ram and working down. An intriguing way of looking at things. Fill up memory from the top with the essentials. Then try to squeeze some actual code in what is left.
Ok, a few common locations at the top of ram for postboxes. Then moving down, you are thinking video buffer, sd ram buffer.
I guess if there are .cog files, these need to be loaded off sd ram into hub and then into a cog? If so, could you share video ram and the common .cog loader space and save 2k?
Video buffer would be different sizes for different applications?
Pretty soon, you get stuck with the "hard" part - rewriting existing working drivers so they can be decoupled from any other program and turned into .cog files and only talk via the postbox addresses. Keyboard. Display. Serial drivers. fsrw/kyefat32.
Just for starters, how would the postbox code, and what is the largest number of addresses a .cog file might need?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller