In search of standards: triblade,dracoblade,ram addons, etc.
Oldbitcollector (Jeff)
Posts: 8,091
I've been a big proponent of what we can do with a single propeller based board like that of the demoboard, or El Jugador
but I know that the way forward for the Propeller is multiple propellers with some sort of ram expansion.
Has some sort of consensus been reached as to a "standard" which would allow everyone to move forward
in the same general direction without feeling like we are moving in a counterproductive fashion?
Naturally, I'm addressing this to the designers of some of the interesting multiple-prop/memory/video boards.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Post Edited (Oldbitcollector) : 4/8/2010 12:57:06 AM GMT
but I know that the way forward for the Propeller is multiple propellers with some sort of ram expansion.
Has some sort of consensus been reached as to a "standard" which would allow everyone to move forward
in the same general direction without feeling like we are moving in a counterproductive fashion?
Naturally, I'm addressing this to the designers of some of the interesting multiple-prop/memory/video boards.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Post Edited (Oldbitcollector) : 4/8/2010 12:57:06 AM GMT
Comments
And how can there be?
Every RAM expansion solution has different hardware, different priorities different trade offs. For example Cluso goes for maximum speed and sacrifices most of the prop pins to get it on TriBlade and RamBlade. Meanwhile Dr_Acula is happy to give up some speed in order to have some pins back, hence a multiplexed bus. Not sure where the Hydra RAM expansion fits but it lives in a different world again. Then there is Morpheus, and Bill Henning is looking to serial RAMs.
From a software point of view, in order to have objects that can live with whatever RAM expansion is available and hence be portable, it would be necessary to have a hardware abstraction layer. An interface to RAM that is available on all those platforms and any new ones that come up. That layer is coming into existence with Bills Virtual Memory caching system VMCog. But then for many the speed hit of a HAL like that is not what the want. Or perhaps sacrificing a COG to virtual memory is not desirable.
For multi-prop solutions there are similar hurdles. Whatever the communication system employed between Props, serial, parallel, full duplex, half duplex, synchronous, asynchronous etc etc there would have to be a hardware abstraction layer to present a common interface to user objects.
For my humble efforts, I'm going to adopt Bills VM technology for external RAM. The Zog ZPU emulator will never contain a direct access to ext RAM, at least not from me. This way Zog can be dropped into a system with any RAM type even serial RAMS.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/7/2010 7:07:21 PM GMT
I delayed the RamBlade design while I examined all the various options for adding other I/O and ultimately I decided that everything else was a compromise that I was not willing to accept.
IMHO there is no point in sacrificing speed, particularly in emulations such as ZiCog. Why would you want an emulation that runs slower than the real McCoy? If you want a pile of interface chips then you may as well use a real Z80 and all the stuff that goes with it.
Another point that seems to be forgotten is that SRAM can only be accessed by one cog at a time. The moment you add contention control you add another layer of slowness. If you try to abstract the hardware you inflict another slowdown. We do not have the luxury of a data/address bus out of the prop chip. If you want that choose an Intel or similar chip, with all it's other interface chip requirements. The Prop I will never replace a modern PC.
FWIW it is much easier to abstract the I/O into a second prop and communicate over the serial, using Beau's high speed if 115200 or 1Mbps is not fast enough.
The TriBlade is a user assembled almost all through-hole design with 3 prop circuits...
* One Prop with keyboard, mouse VGA, TV, flash, and a latched 512KB SRAM (not all options simultaneously)
* One Prop with 2 x 512KB SRAM (no latches), microSD, flash (the latch is for decoding only)
* One Prop with uncommitted I/O
BTW TriBlade has Serial Flash 1-2MB on two props and Mike Green wrote a driver for them. However, I know of noone who has used it, nor the latched SRAM.
The RamBlade (surface mount pre-assembled module) is a simple design with dual roles...
* Standalone with serial or TV+KBD
* Plugin module to another board such as the ProtoBoard or DemoBoard
It is designed for overclocking and currently ships at 104MHz (with a 108MHz option not fully tested)
Unfortunately, I have had other things to do and not had all my hardware accessible recently, so a lot of my time has been spent readying my next project. Now that I have almost all of my hardware back in one place I can again progress the RamBlade, TriBlade and SphinxOS further.
OBC: I hope this helps to explain the different direction I am taking from some of the others.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects
From the software POV there is the need to have an ideally compatible library for external memory accesses. This is there for the TriBlade, RamBlade and DracBlade and will most probably be there for the upcoming PropCade, too. Further, for speed reasons, the low level read/write byte functions should be embeddable in things like a CPU or VM core. This is the case with the first 3 designs, and probably not with the PropCade - I don't know yet.
I have yet to see the difference in speed of the RamBlade vs. the DracBlade, but I somehow doubt it will suffice to make yaz80 run at 4MHz. Other, smaller CPU or VM cores may benefit more from the faster RAM access of the RamBlade.
What I was glad to see was hairymonster's efforts to join the SD SPI and the DracBlade memory access into one cog. This joint venture seems to me a must-have for all designs, because you will almost always need both things for your application and having them in just one cog is great. So the same should be doable for the RamBlade and perhaps also the TriBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Post Edited (pullmoll) : 4/7/2010 7:39:48 PM GMT
@Cluso99 is correct in that multiple propellers is the best solution for external memory access speed (greater than 32KB...).
Latching is fine for large bursts of data, but if you can't load a burst at the same time you're using it (a cache miss fetch), the advantage is clearly gone. I have yet to see a design that can fully do this, and my experiments in that area tell me that the latency of using multiple cogs is too high to be beneficial. Even VMCOG will not be capable of great performance on cache miss because it is a one cog solution. Perhaps Bill can prove me wrong.
Of course there is no perfect one size fits all solution. Byte wide access is perfect for 8 bit wide processor fetch, etc... emulation.
However, byte wide access is not the best fit for 32 bit wide fetch as is the dominant requirement for LMM instruction fetch from external memory. Unfortunately, there is no such thing as a 64 pin propeller today, so we have to play games to fetch a long quickly. The fastest means for reading a long is using multiple cogs to read bytes from P0-7 (data on P24-31 is inappropriate for this method) and assemble them for LMM to use.
One other use for multiple propellers that is never mentioned here is with the PropGFX design. PropGFX apparently provides a full 32K video buffer for output when connected from another propeller on P0-7 and P8. This is a very useful idea for video enthusiasts since a full 5MB/s can be transfered from the main controller to the PropGFX device.
As far as standards go ... the niche is too small to worry about it and endorsing a standard discourages other designs which are just as good I'm sure (or maybe not) for their purpose. The market should decide what it wants. Overt advertising or promotion of one given solution as best for all in the forms should be discouraged.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
OBC:
I don't believe a standard is possible, as it would be a poorly fitting straight jacket.
heater:
I totally agree with what you wrote, and I will expand on what you wrote later in this message.
Cluso99:
Agreed - your solutions are the current leader in random access, well done! I particularly like your RamBlade design, which is well adapted to its role as a memory/processing addition to other boards.
Nick McClick:
Short of applications which are sufficiently served with SPI memory, multiple props with more ram is the way to go forward, at least until such time as 64 pin propellers become available.
pullmoll:
I am trying to address the compatibility issue with VMCOG, while at the same time, using it to provide potentially very significant average access acceleration to serial solutions. For latched and parallel designs it would be easy to access the external memory directly, and present the results, without paging - which I fear would be too slow with a single bit serial solution, and probably too slow even with the four-bit FlexMem bus. I too intend to make the uSD card on PropCade available through VMCOG, with routines to read/write a sector at a time, which should easily be interfaced to the higher layers in file system code.
jazzed:
My calculations show that VMCOG (with FlexMem) will be able to handle a page miss in under 200us - which is certainly MUCH slower than a page hit, however as was observed on old VM systems, most code tends to run with 95%+ hit ratios if the working set of pages is large enough. I suspect it will be usefully fast, and I base this on older multi-user VM systems taking several ms to handle a page miss. VMCOG on PropCade will obviously be slower, I expect a page miss to take approximately 1ms there once the drivers are optimized.
I totally agree that standards would be counter productive - with the possible exception of something like VMCOG's mailbox, which would allow a low "common denominator" that could be targeted by all software, before optimizing it to the "native" XMM interface.
ALL:
There can not be a "memory" standard at this time. There are several competing needs, which lead to different solutions.
1) Low cost
For a small ammount of external memory, there is nothing that can beat four of the SPI ram's.
2) High (random-access) speed
Nothing beats the unlatched designs like Cluso's fine board. Nor can anything beat it, without more pins. This is probably the best overall for fast XLMM at this time, however it is not useful for higher resolution video as it consumes all the pins.
3) High (burst) speed
Morpheus took a balanced approach - my design goals required that I walk a fine line between random access speed, burst speed, and having enough pins left to do high resolution bitmap graphics - with more colors than the Propeller's normal native VGA supports. It is the best solution for my commercial needs at this time - but it is not the highest possible speed solution for random access. Unfortunately the extra capability comes at an extra cost, which a lot of people cannot afford at this time. This, and my other board designs are commercial as I have no "day job" to pay my bills.
4) Medium speed
Dr_Acula's approach does a great job at achieving medium speed access, while saving many pins. For his needs, Z80 emulation, it is a good trade off - we have to remember that the emulation of every instruction requires executing many native pasm (indeed, some LMM) instructions, thereby taking far longer than retreiving a byte even from a latched design, significantly mitigating the performance hit.
5) Low speed
SPI ram's shine again [noparse]:)[/noparse]
6) other solutions
Ale, and I am sure others that I've forgotten, have proposed CPLD based solutions, DRAM based solutions etc. - and I have also been exploring these options.
What we have to remember is TANSTAFL - "There Aint No Such Thing As Free Lunch"
There is a cost to every solution - be it lower speed, higher cost, additional chips, or unsuitability for some purposes.
There is no one right solution, and I posit that there won't be - at least until there is an "official" dedicated high speed address/data bus in perhaps Propeller 3.
As for myself... I will keep developing products, some commercial (my boards), some not (VMCOG) - hoping to make the Propeller more appealing to a wider audience, and scratching my itch to extend the state of the art.
As soon as I have the PropCade and FlexMem drivers up to speed, I will resume work on VMCOG, and I look forward to running ZOG and other future software on it [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 4/7/2010 10:18:06 PM GMT
Bill: Thanks. I agree with all your comments. Particularly, a high resolution video solution will require a block of fast access SRAM with the upper bits latched. Otherwise there are no pins available for the VGA output. This was one of·my ideas behind the TriBlade #1 - A0-A11 were direct and A12-A19 were latched, and it had a VGA port. Nothing has been done with this design. However, the high resolution would most likely benefit from some sort of PLD/FPGA to supply the address pins when generating the display. However, I am unsure of the impact of updating (writing) the video ram. This could be the case for an FPGA (co-processor style) solution for the video and SRAM.
So, in summary, I agree market forces (and of course that relates to the use) will preside. Meanwhile, we all benefit from various solutions for specific purposes. Sorry, no standards for now at least.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
@Nick:
Said like you disagree? From this direction the issues appear to be first, a lack of memory. 32k simply isn't
enough to do emulation or higher resolution graphics. While adding memory is possible, I/O is lost in the process.
Multiple propeller configurations seem to be the answer on both fronts.
@Cluso, jazzed, Dr_A, Bill & Friends:
Wish you guys would settle on a design, (or a combination of such) so this would move in a singular direction.
(Perhaps it's just too soon in the process.)
There are a bunch of us on the sidelines trying to keep score.. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Are you Propeller Powered? PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
I'd like to second Nick's question/response and add a few comments.
Although myself and I'm sure many others that scour these forums on
a regular basis are amazed at the extremes that folks such as yourself and
Sirs Cluso, Henning, Acula, Heater, and others have taken the Prop to,
I don't necessarily agree that multiple Props and gobs of memory is
*the* way forward. (read - the *only* way forward)
These extremes are fantastic in that they push the envelope letting the
rest of us see the possibilities and scrub every nook so that everyone
benefits from the knowledge gained. I also love the fact that these
projects such as the Z80 emulation let us revive some computing history
that could otherwise be difficult or nearly impossible due to long
unavailable hardware.
However, I don't think those doing these types of projects with the Prop
are a great majority of us using it. This group is a very vocal and
active part of the community that I for one admire the work of and follow
closely, but for academic reasons, not really because I plan to follow in
their footsteps. (even if I could [noparse];)[/noparse]
I could be wrong, and if so, I'm more than happy to admit it. I've had this
conversation with other folks using the Prop and those who frequent the forums
and find they also agree with this assumption. I personally view the Prop as
a fantastic core for my *embedded* projects. The core for the "widgets" I
like to build and tinker with. But considering that UAV systems have been built
with a single Prop, I don't think my two-bit widgets will soon outgrow it.
Essentially, I just wanted to note there is probably a large population of us
out here using the prop that have other applications for it.
Applications that don't involve pushing it to the limits in the way of video
or processing speed with the goal of creating a general purpose computing
or gaming platform.
Maybe that's what Nick had in mind with his post, as I had the same thought.
Respectfully,
beebs
It is absolutely true we are pushing the envelope for certain projects that require more memory. Things such as an operating system (SphinxOS) will benefit but do not require external memory. C most likely does. All the emulations do.
However, the prop is extremely versatile and external memory is not required for many projects. The UAV beebs cited is an example. You may have noticed I am in the process of doing just that with a quadcopter design. It uses just a singular prop and gyro, compass, accelerometer, GPS and pressure sensors.
This does not mean I am abandoning the multiple prop and SRAM solutions, just that other solutions do not require them - horses for courses!
There is a lot of interest in getting the prop to do things such as emulations (ZiCog etc) and there is certainly a lot of followings on these threads. You only have to look at the numbers of peole reading the threads (apart from ourselves).
Unfortunately, there are many legitimate solutions to adding external memory. We have all chosen to follow different methods to add this, and we have different objectives. There is no point in reciting them again. They are just that, different objectives. If we have a large family, some buy 4WD and others buy Taragos (cannot recall what you call the people movers in the US) - there is no standard here. And for now, there will be no standard on the external memory camp either. In the end, the end user will decide, and currently we do not have enough info to see what the end user requires.
For the users, there are now lots of hardware solutions, not only for external memory, but all sorts of boards. Not all of these adhere to any standards either. The benefit to the user is a plenthora of boards.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Yes it increase you carrying capacity. But at the cost of defeating the original purpose entirely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 4/10/2010 6:35:04 AM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
All analogies fail at some point. I was just alluding to the idea that using all the pins on a Prop for RAM basically defeats the point of the Prop, no pins left means probably limited possible uses for the COGs. At the end of the day it's a slow solution.
So, I have to ask, apart from us crazy emulator enthusiasts is there anyone out there using Propeller external RAM solutions for practical, useful or otherwise interesting applications?
In the back of my mind is the idea that all the work people have done on emulators with external RAM will one day be all consumed into the luxurious space of the Prop II. So none of it is wasted. Same applies to ICC, Catalina, dare I say it Zog and other such projects.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Wish you guys would settle on a design, (or a combination of such) so this would move in a singular direction.
(Perhaps it's just too soon in the process.)"
I've just returned from a one week vacation in sunny Queensland where I deliberately did not touch a computer for the entire time. So now, I'm bursting with ideas that are currently on paper in a notebook!
There are lots of designs. All work just fine, but this is the tough, harsh, highly competitive world of microcontrollers where today's cutting edge board is tomorrow's electronic junk. It is the Wild West. I have a feeling the current designs are not even close to what the Prop is capable of.
If it is confusing, instead of starting with a board, start with a problem that needs solving. For some, it is emulating a particular game they love. For others, emulating their favourite old computer. For some, flying across the country in an autonomous plane or helicopter. For me, I want a board capable of upgrading and rebooting its entire operating system wirelessly with no user intervention, plus a wireless mesh of boards for sensing and control. So easy to say, so hard to do!
What do you want to do?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Micha's USB host project has enormous potential and therefore has great value for many users. Same for BradC's spin compilers and Bean's Basic. The Java VM is applicable for far fewer users. The language list is good entertainment. Any kind of memory expansion is desirable for many users and has been essentially since Propeller introduction.
As I said anything can be positioned in any way. As long as it doesn't hurt people I guess it doesn't matter. Not that it's anything like the Y2K, internet, or Real Estate investment bubbles (unchecked speculative growth leading to disasters). It's Ok for things to go unchecked for those who know how to use them ....
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Are we trying to measure the value of a post, a project, a comment, a thread. By what criteria?. To whom?
Google thinks they have an answer with their page rank algorithms and what a pile of Smile that leads me to quite often.
Pretty much everything said here has some value to someone, sometime. May the conversation continue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
If you're working on it just to have fun, then 'keep on keeping on,' but I'm not sure how many other people want to go that way. My sense is there's more interest in making development easier and more accessible than getting more performance out of the Prop.
I could be wrong - I have been before
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Forums RSS Feed!
Gadget Gangster - Share your Electronic Projects