Standards for hardware, file types and OS features, please chime in
vampyre
Posts: 146
I think it would be in the best interest of all of us to create some kind of optional clearly documented standards system that covers OS/application protocols.
I thought it'd be a good to get an idea of how many people are using props as microcomputers and what their configurations were. since this forum doesn't have working polls i've made one here, please take the time to take the poll (its only one question)
snappoll.com/poll/277010.php
Also see new pole at end of this post
Basic problem:
There are some number of people who use the prop as the core of a small computer. Most of us are using an SD card, many of us are using an operating system such as PropDOS or PorthOS.
And of course, any spin program usually requires certain external hardware which can and usually is hooked up in many different ways.
Another problem is that there are now a number of applications for playing multimedia on the Propeller, each requiring its own unique and sometimes hard to acquire media file format.
Reasons standards would be useful:
* Helping people with a standard setup would be easier because we would all have almost identical hardware
* Applications wouldn't need to be custom modified by each user before running them.
* Apps written to take advantage of any of the many operating systems would run on any other OS that is standard compliant.
* Application authors would be more likely to write software that supports OS features if those features were standardized
* Media (video,audio,images) could be created and used by multiple applications without conflict
Reasons standards might be damaging:
* They might make future development of now un-thought of hardware or software very difficult if:
- the standards are too set-in-stone.
- the standards are not well thought out
- the people who set the standards are exclusive, and then move on to other projects
- any part of the standard is not easily understandable, or well documented
To avoid these pitfalls i suggest we use the wiki to post our final standards (so anyone can edit them or pick up the project)
I also think that we have some kind of agreed upon revision system, and a cute name for the standards. Something to unify the users in a way that makes app development easier, but also doesn't restrict anyone.
(the rest of this post has been cut, due to the fact that it is already outdated, and was pretty long winded.)
So, lets open this up, tell me what you guys think of all this
Post Edited (vampyre) : 6/29/2008 8:20:21 AM GMT
I thought it'd be a good to get an idea of how many people are using props as microcomputers and what their configurations were. since this forum doesn't have working polls i've made one here, please take the time to take the poll (its only one question)
snappoll.com/poll/277010.php
Also see new pole at end of this post
Basic problem:
There are some number of people who use the prop as the core of a small computer. Most of us are using an SD card, many of us are using an operating system such as PropDOS or PorthOS.
And of course, any spin program usually requires certain external hardware which can and usually is hooked up in many different ways.
Another problem is that there are now a number of applications for playing multimedia on the Propeller, each requiring its own unique and sometimes hard to acquire media file format.
Reasons standards would be useful:
* Helping people with a standard setup would be easier because we would all have almost identical hardware
* Applications wouldn't need to be custom modified by each user before running them.
* Apps written to take advantage of any of the many operating systems would run on any other OS that is standard compliant.
* Application authors would be more likely to write software that supports OS features if those features were standardized
* Media (video,audio,images) could be created and used by multiple applications without conflict
Reasons standards might be damaging:
* They might make future development of now un-thought of hardware or software very difficult if:
- the standards are too set-in-stone.
- the standards are not well thought out
- the people who set the standards are exclusive, and then move on to other projects
- any part of the standard is not easily understandable, or well documented
To avoid these pitfalls i suggest we use the wiki to post our final standards (so anyone can edit them or pick up the project)
I also think that we have some kind of agreed upon revision system, and a cute name for the standards. Something to unify the users in a way that makes app development easier, but also doesn't restrict anyone.
(the rest of this post has been cut, due to the fact that it is already outdated, and was pretty long winded.)
So, lets open this up, tell me what you guys think of all this
Post Edited (vampyre) : 6/29/2008 8:20:21 AM GMT
Comments
SD cards
If you have a demo board than the sd card has to be on pins 1-8.
File headers
How about a standard file header for storing some meta-data such as version number of the file format, etc...
Maybe a couple of bytes that says where the data starts and then a few standard fields with room for more stuff to be added?
Add-on cards
Do we want to include some of these in the specs. For example the NIC cards?
It remains my belief that the best solution to diverse hardware configuration is within the PropTool itself. Some means for each user to specify how the I/O is allocated on their particular hardware which can override whatever the program calls for. In particular what _XINFREQ and _CLKMODE is required. Users can select the definition file to match whatever hardware board they have connected.
If a name appears in the user's PropTool definition then any CON definition with the same name in the Spin program is overridden by what the user wants. Standardisation then falls to defining naming and usage conventions.
If I had free run of how to, I'd add a PIN section to Spin which works like CON. If a name is in there it is replaced by the user's PropTool definition, if a name is specified compilation fails if the user hasn't got a definition for that name. Compilation fails if a name a user specifies appears anywhere other than in a PIN section.
I would also say that it is essential to be able to indicate "I don't have this" ( SD = -1 for no SD Card say ) so code can still be compiled although it may not run properly unless the original developer has taken care to make sure a "don't have" pin is handled in a non-catastrophic way.
This would be useful for adding serial debugging say; TX_DEBUG sets the pin a debug terminal is attached to, users will either have that or not, the program will use it or not depending on the user's setting. Ideally PropTool would support conditional compilation so there would be no overhead for unused code.
Unfortunately doing any of this is largely out of our hands except for third party IDE's which can pre-process Spin files and call Propellent. This has been mentioned before but I don't see any enthusiasm from Parallax to add support for it to PropTool. It's a shame because I think it would make everyone's life so much easier; aren't we all sick to death of having to change _XINFREQ and every other pin allocation every time we load up someone's program which doesn't match what we are actually using ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
realized it would be important to be compatible with other boards to "share the fun."
A few hardware comments: (In no particular order.)
Regarding the HYDRA:
The HYDRA is an important consideration because there are more than a handful of
existing games for it, as well as new hardware developments. (Pinouts comparing
the HYDRA to the typical Protoboard/Demoboard setup can be found on the last
page of the original Propeller Cookboard PDF.) Recently, an SD card interface
was introduced (SDmax) which sits on 16-19.
Personally, I think 16-19 is a good idea for SD, but it does omit the demoboard users
who don't have access to these pins. (Unless someone can successfully find a way
to plug-in an SD interface card into it's VGA header, a trick that I couldn't replicate.)
The HYDRA suffers from having an early keyboard/mouse interface design, but other
than I/O location, most of this has been solved with Mike Green's keyboard driver.
My own setup:
My own version of a "Propeller Microcomputer" uses removable "Spin Controller" cards
s configured in the following manner...
0-7 This is used a "Spin Studio" userport. My experiments are run from here,
NES, Controller, Ethernet, etc.
8-15 This usually has my 10,11 sound and 12-14 video. 8,9 are currently not used.
16-19 This usually has my SD card attached. 20-23 are currently not used.
24-31 Keyboard/Mouse, EEPROM, and programming interface.
Potential Additions:
I'd like to see the addition of a standard clock/data setup. Perhaps using
one of the open pins (8 or 9)
Also, it should be noted that the upcoming PropGFX card will require
eight "databus" connections, as well as two additional lines for serial communication.
Gentlemen, what we have is a standards mess already.....
If we come up with a conditional compile, (better than selecting all the pins every time)
perhaps this could be solved on a software level. But before we dig ourselves deeper
into this hole, it would help if we could all agree on some basics..
It might be like asking 20 people what they want for lunch...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
.HID hidden files. No specific format required,
simply not displayed by PropDOS.
.64C Commodore font.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
We don't need a standard which says what hardware has to be connected on what Pins. But we need a standardized File on SD card, that describes what Pins are used for TV, Keyboard, Mouse, and so on. The Application can read this file and then start the TV_Text, Keyboard (...) drivers with the correct Pins.
I suggest not to use a Textfile for this configuration, but a simple binary file with the Pin numbers on defined locations. So you don't have to parse the textfile, but only read the config file in an Array and use the right indexes to get the desired Pin numbers. If this Indexes are constants, it is also good readable.
I prefere to pass the configuration and the commandline at the End of the MainRAM in defined addresses, so also Applications without an SDcard driver can read it. But why not doing both, then one can read it from SD card, the other from MainRAM.
For a minimal standard we need:
- Filename for a Pin configuration file
- Filename for the Commandline
- On what index in the config array is what Hardware Pin defined.
- MainRAM locations for a copy of the Config and Commandline file in RAM.
Then we need a Combo-Mousedriver similar to Mikes ComboKeyboard to support Hydra and Demoboard type Mouse Interface.
All the rest, like File extensions and File standards will dynamically grow.
Andy
I'm wondering if, in the absence of conditional compile in PropTool, we cant hold our set-up's config in a standard file, then make use of the FILE command in a DAT?
e.g.
On the PC we'd have a file called (say) config.pin. This would have some standard content that defines what pins our set-up uses for each of: keyboard, mouse, SD, NIC, etc.
Not sure if this file could also include our XTAL & FREQ settings? (That'd be nice!)
We'd then have all our Spin app's call this file with something like:
That's where I get stumped - what needs to happen next?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.co.uk
You'll always have as many take-offs as landings, the trick is to be sure you can take-off again ;-)
BTW: I type as I'm thinking, so please don't take any offense at my writing style
I'm beginning to re-think the idea of "standard" pin connections all-together. Maybe a better idea is to just have a standard configuration file on the SD card, and or standard eeprom address for information about pin connections within the operating system. That way , we could add any new hardware without having to modify the Summer Standards spec. All we'd have to do is claim a new text tag for their hardware, like PROPNIC and post that tag on the wiki
OBC:
file types added.. thanks for the heads up. i'll re-read the pdf and add the information about the hydra to the standards
Baggers:
I hadn't thought of using EEPROM in the operating system as a way to identify hardware / settings... thats not a bad idea. anyone have any suggestions on the right way to do this? What should be included in the eeprom about configuration? How should it get there? I think if the OS has a configuration file on the SD card it could scan that file on each bootup, check the rom addresses , and if its different, re-write the info to rom. how does that sound?
Hippy:
I can certainly see your point. However without conditional compilation it becomes more difficult. The ultimate goal is to prevent us from having to change settings before compile. In fact its my dream that people will be able to confidently distribute pre-compiled binaries, and those binaries will run on any Summer Standard compliant machine. The basic idea is that we should provide a standard way of having non-standard connections. the best way to do that though, is still up in the air
stevenmess2004:
file headers are a good idea, im currently planning to implement them in PGF and PVF. trying to implement a file header for every type of file might be difficult, especially formats we dont have control over like .wav files. but a standard for 'prop native' files might be doable.
Post Edited (vampyre) : 6/21/2008 10:41:43 PM GMT
It would be useful to have pin assignments by function (SD card, TV, keyboard, mouse, VGA, etc.). There might also be a table of pin assignments by pin number with the byte containing the offset of the function involved (like pin 12 containing the offset of the first SD card table entry). We should provide for 64 I/O pins and provide a group of function slots that are unallocated. This binary table doesn't have to be included in a program. For example, it could be copied to an SD card file or to an area of EEPROM above 32K and accessed only during initialization.
I'm starting to believe that the best way to pass hardware information is to store it in the eeprom, and the commandline in the ram? What do you guys think about those ideas?
simonl:
pins and the crystal are not the only consideration. We also have to figure out what hardware is hooked up before we know if the app will run.
it would be rather easy to write a program that pre-processes a spin file to modify it automatically, but it would just be really nice if we didn't have to do any of that, and could run the binaries without compiling them at all.
then if the needed hardware wasn't present, you'd get a nice error message expliaing what you need
Mike, I like this... A solid software solution! (Why would I expect less.. [noparse]:)[/noparse]
Curious.. Why a binary? Maybe I don't completely understand this solution, but
couldn't we simply include a .spin file that used expected variables and settings for
those variables? Give the .spin an official name and then just compile with
all code?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
You could certainly do this with a DAT section that is part of the program itself. The main problem is that there is no include facility in Spin other than FILE and FILE simply copies the entire content of the specified file into the compiled program as a DAT section. That makes it a binary table. My understanding is that we want a configuration file that reflects our own individual hardware configuration. Maybe we'd have a configuration program that lets us specify what we want using a GUI and it would write out an appropriate file that could be used with any program that we have that follows these rules. Maybe we'd have a template in Spin that we'd edit for our configuration and would be compiled into a binary file for use later.
Then write a utility app that can search an eeprom image for the magic numbers and edits the values directly in the image rather than a dat file. The utility should be configurable from a file with the offsets and display strings so new offsets can be easy added. You then can modify a binary image for your system without needing to rebuilding the project.
the other problem i see with it is newbies. when they download a spin program and look at it, they will not instinctively be able to tell what the binary is or where to get it. if the configuration is stored as binary info in the eeprom, then the application can automatically configure itself, and you wont even have to have an SD card to make it work
Using rom above 32k would be great but i dont think everyone has that?
The simplest implementation of this Standard for an operating system would be to stuff the needed info into the eeprom.
thoughts? suggestions?
My vote on the binary with some good written documentation on how
a beginner can set it up. The solution needs to be both easy to understand
and implement as well as not consume memory with a million zero'd variables.
We will need to agree on variable identification, and it should be written in long
form if at all possible to leave plenty of room for new hardware and new I/O.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
All the drivers like Mouse, Keyboard, TV have parameters for the Pin numbers. Now we pass just constant values to the Start methodes. But if an Application reads first the Configuration from SDcard, EEPROM or RAM, and pass the values from this configuration to the Start methode as Pin numbers, then the Application adapts itself to your Hardware. If all use a standardized Config then you only have to Edit one time the Config File, and many Applications run without recompiling.
I think it is not possible to switch, for example, between a VGA and TV output according the Config File, or between a PS2 Keyboard and a Terminal Input. I've tried to realize that, but it is very inefficient, you have a lot of dead code in the binary. So in this cases, a recompiling is necessary, and then it is useful to have also a configuration file on IDE level that is included with a File command in the Spin source, as Mike suggested.
Andy
Catch22.. To read a configuration file from SD, or EEPROM it will need a
either a standard for FSRW or the EEPROM (likely)
Thrown Monkeywrench...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
I've updated the first post by removing the hardware requirements.
I like your previous comment OBC about how its like asking 20 people what they want for lunch.
Ariba, you bring up some good points as well
Perhaps we should re-evaluate our goals?
Do we simply want easier compilation are do we want no compilation at all, and for what reason should we, if any, require modified compiles ?
I think the core of this project is to unify the many operating systems, to give them the ability to provide applications with info on how the hardware is connected..
But Your right Andy, if the hardware is sufficiently different it would require different binaries or a modified compile.
So, perhaps we should split this into two segments, one for pin assignments/crystal information... and one for things that really require compilation modification? ideas anyone?
Post Edited (vampyre) : 6/21/2008 10:15:46 PM GMT
I fear the temptation of "closed source" with no compilation required..
One of the strengths the Prop is being able to read others code to learn and adapt.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Any objects that need this info can include it, thus:
The only things that need standardizing are the names of the pins and the name of the file their definitions are to be found in. The latter could be problematic where more than one configuration is used by the developer. But this might be remedied once the IDE supports PATH directives.
Doing anything post-compilation would involve some sort of linker, in order to make sure everything got plugged in where it needed to be, which, IMO, is way too messy.
-Phil
This might make a great addition to the standard application format
I'm not sure it would meet all the goals though since one of the goals is to have a binary work (or exit gracefully) on any platform running a Summer Compliant OS without being re-compiled
Note: moved the poll to the first thread
Post Edited (vampyre) : 6/21/2008 10:42:30 PM GMT
About Catch22..
My solution for this is to have a BIOS in the EEPROM that searches for the SD card on different Pins. If it find a SD card it writes the Pin numbers in the Config file. If not it ask the user for all the configuration pins and reboot then.
Then it starts the Desktop or Console and pass the configuration to it (in RAM).
vampyre
>Easier compilation or no compilation?
Why not both with the same file:
CON #0, TVpin, KBpin, MOUSEpin .... PUB main if fsrw.popen("config.sys","r") 'example for SD card fsrw.pread(@config,16) 'read the config from SD 'else use compiled defaults ... tv.start(config[noparse][[/noparse]TVpin]) ... DAT config file "config.sys" 'include the defaults from a copy 'of config.sys on the PCAndy
Also Ariba's idea for looking for the sd card on bootup is good. Maybe it just searches on the two sets of pins normally used (1-4 and 16-20?). Only problem is would it muckup other hardware attached to those pins?
Didn't Coley figure out a way recently to tell what board someone was using based on the different keyboard ports?
Intelligent objects like the one that Andy described would solve most of
the issues. At least for those that provide input.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
From a "friendly to the beginner" standpoint, I think Phil's suggestion is the easiest
to implement, maintain, and can be upgraded quickly as needed.
The only catch with using a "PinDefs.spin" is that it will require that we all
agree to the names used by the byte settings in the configuration file.
We could use the Propeller Wiki as a place to keep things up to date.
But everyone will need to agree for this to work. It doesn't matter which
direction we go, if everyone doesn't agree then we are back to same problem.
Anyone?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
This works too..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
What have I missed?
CON '' PinDefs.spin configuration file, adjust or overwrite as needed. _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 'NTSC/PAL Switch ' Primary Keyboard Single KEYBOARD1 = 26 ' Primary Mouse Connection Single MOUSE1 = 24 ' Primary TV Connection Single TV_DAC1 = 12 ' Primary Audio Connection Single AUDIO1 = 10 ' Secondary Audio Connection AUDIO2 = 11 ' Primary SD media Connections FSRW1_DO = 16 FSRW1_Clk = 17 FSRW1_DI = 18 FSRW1_CS = 19 'DS1302 Clock Settings DS1302_INCLK = 0 DS1302_INIO = 0 DS1302_CS = 0 ' Serial I/O SERIAL1_TX = 0 SERIAL1_RX = 0 ' XBee Configuration XBEE1_TX = 0 XBEE1_RX = 0 ' HYDRA NET Configuration HYDRANET_TX = 0 HYDRANET_RX = 0 ' NES bit encodings general for state bits NES_RIGHT = %00000001 NES_LEFT = %00000010 NES_DOWN = %00000100 NES_UP = %00001000 NES_START = %00010000 NES_SELECT = %00100000 NES_B = %01000000 NES_A = %10000000 ' NES bit encodings for NES gamepad 0 NES0_RIGHT = %00000000_00000001 NES0_LEFT = %00000000_00000010 NES0_DOWN = %00000000_00000100 NES0_UP = %00000000_00001000 NES0_START = %00000000_00010000 NES0_SELECT = %00000000_00100000 NES0_B = %00000000_01000000 NES0_A = %00000000_10000000 ' NES bit encodings for NES gamepad 1 NES1_RIGHT = %00000001_00000000 NES1_LEFT = %00000010_00000000 NES1_DOWN = %00000100_00000000 NES1_UP = %00001000_00000000 NES1_START = %00010000_00000000 NES1_SELECT = %00100000_00000000 NES1_B = %01000000_00000000 NES1_A = %10000000_00000000 ' Nes Controller I/O Configuration JOY_CLK = 3 JOY_SHLDn = 4 JOY_DATAOUT0 = 5 JOY_DATAOUT1 = 6 ' PropGFX Lite I/O Configuration PG_RXSPEED = 256_000 PG_RXPIN = 24 PG_TXPIN = 25 MYCLKVAL = %00000010_00000000_00000000_00000000 MYDIRAVAL = %00000010_00000000_00000000_11111111 MYPINOKVAL = %00000001_00000000_00000000_00000000 MYDATASHIFT = 0 'Debug LED Configuration 'LED1 = 0 'LED2 = 1 'LED3 = 3 ' ENC28J60 Ethernet settings - Remarked to save memory if not required. { ENC1_CS = 3 ENC1_SCK = 4 ENC1_SI = 5 ENC1_SO = 6 ENC1_INT = 7 DAT mac_addr byte $10, $00, $00, $00, $00, $01 ip_addr byte 192, 168, 1, 200 ' device's ip address ip_subnet byte 255, 255, 255, 0 ' network subnet ip_gateway byte 192, 168, 1, 1 ' network gateway (router) ip_dns byte 192, 168, 1, 1 ' network dns } PUB StartOBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange
Did you mean to put something under the PAL/NTSC switch? Also, should we add some things for newline clear screen etc? I know these are not really related to hardware but if they are in this they would get standardised. For the ENC28J60 (or anything else that puts stuff in the DAT sections) we would need some way to get to the data. Something like this
Also, with this method if people want to they could put the file on the sd card and then write programs to read the file from the sd card if they really wanted to.
What about vga? Maybe also a switch to switch between vga and tv (probably not since you can't switch between the two without conditional compilation)?
Perhaps adding network DAT data is taking it a little too far.
Not sure how to handle the PAL/NTSC switch, open for suggestions.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook 1.4
Updates to the Cookbook are now posted to: Propeller.warrantyvoid.us
Got an SD card? - PropDOS
Need a part? Got spare electronics? - The Electronics Exchange