Parallax Propeller

For some reason I found myself reading these newsgroups which I haven't 
really used for many years. It seems that although the Parallax Propeller 
web forums are extremely active there never seems to be much discussion 
elsewhere. Aren't you all curious as to what you are missing out on?

I have used just about every kind of micro and architecture over the 
decades and while I might still use some small "one buck" micros for 
certain tasks and some special ARM chips for higher end tasks I have 
almost exclusively been using Propeller chips for everything else. The 
reason is very simple, they are so simple to work with and there are no 
"peripheral modules" to worry about other than the counters and video 
hardware per cog. Every pin is general-purpose and any one of the eight 
32-bit cores can use them, you don't have to worry about trying to route 
a special pin or have the dilemma of using the special pin for one 
function but not the other etc. The 32-bit CPUs or cogs are a breeze to 
program and you can work with a variety of languages besides the easy to 
use Spin compiler that comes with it.

For you Forth enthusiasts there has been a big flurry of Forth related 
threads on the Propeller forums of late and there are several versions of 
Forth including my own Tachyon Forth. IMHO this is the best way to get 
into the Propeller and it's hardware. I just can't be bother trying to 
cram functions and debug interrupts on other chips when I can set a cog 
to work on a task and still have plenty of resources left over including 
video on-chip.

If you are intrigued or just plain curious it won't kill you unless you 
are a cat to have a look at my introduction page which has links to 
projects and the forum etc.
http://goo.gl/VX7pc

There is the sup'ed up version of the Propeller, the Propeller II coming 
out in the following months which has 96 I/O, 8 cogs, 128K RAM and 
160MIPS/core.

BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) that 
hang off the "I2C bus" from the Propeller and I can load new firmware 
into each chip using just one extra line to program them in-circuit. 

*peter*
 

On 13/01/2013 06:37, Peter Jakacki wrote:
>
> For some reason I found myself reading these newsgroups which I haven't
> really used for many years. It seems that although the Parallax Propeller
> web forums are extremely active there never seems to be much discussion
> elsewhere. Aren't you all curious as to what you are missing out on?
>
> I have used just about every kind of micro and architecture over the
> decades and while I might still use some small "one buck" micros for
> certain tasks and some special ARM chips for higher end tasks I have
> almost exclusively been using Propeller chips for everything else. The
> reason is very simple, they are so simple to work with and there are no
> "peripheral modules" to worry about other than the counters and video
> hardware per cog. Every pin is general-purpose and any one of the eight
> 32-bit cores can use them, you don't have to worry about trying to route
> a special pin or have the dilemma of using the special pin for one
> function but not the other etc. The 32-bit CPUs or cogs are a breeze to
> program and you can work with a variety of languages besides the easy to
> use Spin compiler that comes with it.
>
> For you Forth enthusiasts there has been a big flurry of Forth related
> threads on the Propeller forums of late and there are several versions of
> Forth including my own Tachyon Forth. IMHO this is the best way to get
> into the Propeller and it's hardware. I just can't be bother trying to
> cram functions and debug interrupts on other chips when I can set a cog
> to work on a task and still have plenty of resources left over including
> video on-chip.
>
> If you are intrigued or just plain curious it won't kill you unless you
> are a cat to have a look at my introduction page which has links to
> projects and the forum etc.
> http://goo.gl/VX7pc
>
> There is the sup'ed up version of the Propeller, the Propeller II coming
> out in the following months which has 96 I/O, 8 cogs, 128K RAM and
> 160MIPS/core.
>
> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc) that
> hang off the "I2C bus" from the Propeller and I can load new firmware
> into each chip using just one extra line to program them in-circuit.
>
> *peter*
>
>
Had a quick look (again) - it's not very fast and it's not very cheap 
(compared with a CortexM4 clocked at 150MHz or more). Then there is all 
the pain of programming and synching multiple cores which is (I think) 
worse than the pain of managing DMA on a typical M4 based micro-controller.
For some applications I'm sure it's a really good fit but I haven't hit 
one yet. It's similar in concept to XMOS and Greenchip offerings but 
like them suffers from a less than first rank supplier which would worry 
most of my customers.

MK

On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote:

> On 13/01/2013 06:37, Peter Jakacki wrote:
>>
>> For some reason I found myself reading these newsgroups which I haven't
>> really used for many years. It seems that although the Parallax
>> Propeller web forums are extremely active there never seems to be much
>> discussion elsewhere. Aren't you all curious as to what you are missing
>> out on?
>>
>> I have used just about every kind of micro and architecture over the
>> decades and while I might still use some small "one buck" micros for
>> certain tasks and some special ARM chips for higher end tasks I have
>> almost exclusively been using Propeller chips for everything else. The
>> reason is very simple, they are so simple to work with and there are no
>> "peripheral modules" to worry about other than the counters and video
>> hardware per cog. Every pin is general-purpose and any one of the eight
>> 32-bit cores can use them, you don't have to worry about trying to
>> route a special pin or have the dilemma of using the special pin for
>> one function but not the other etc. The 32-bit CPUs or cogs are a
>> breeze to program and you can work with a variety of languages besides
>> the easy to use Spin compiler that comes with it.
>>
>> For you Forth enthusiasts there has been a big flurry of Forth related
>> threads on the Propeller forums of late and there are several versions
>> of Forth including my own Tachyon Forth. IMHO this is the best way to
>> get into the Propeller and it's hardware. I just can't be bother trying
>> to cram functions and debug interrupts on other chips when I can set a
>> cog to work on a task and still have plenty of resources left over
>> including video on-chip.
>>
>> If you are intrigued or just plain curious it won't kill you unless you
>> are a cat to have a look at my introduction page which has links to
>> projects and the forum etc.
>> http://goo.gl/VX7pc
>>
>> There is the sup'ed up version of the Propeller, the Propeller II
>> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM
>> and 160MIPS/core.
>>
>> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc)
>> that hang off the "I2C bus" from the Propeller and I can load new
>> firmware into each chip using just one extra line to program them
>> in-circuit.
>>
>> *peter*
>>
>>
> Had a quick look (again) - it's not very fast and it's not very cheap
> (compared with a CortexM4 clocked at 150MHz or more). Then there is all
> the pain of programming and synching multiple cores which is (I think)
> worse than the pain of managing DMA on a typical M4 based
> micro-controller.
> For some applications I'm sure it's a really good fit but I haven't hit
> one yet. It's similar in concept to XMOS and Greenchip offerings but
> like them suffers from a less than first rank supplier which would worry
> most of my customers.
> 
> MK

Since I've had a lot of experience with the Propeller and ARMs and I'm 
familiar with M4s (still pushing out a design) then I can say that unless 
you actually sit down with it for an hour or two that you will probably 
continue to have this misconceptions. Is that the way that the Propeller 
comes across? I've always wondered about that.

No, your idea of the Propeller is so off the mark, I'm saying that not to 
offend, just setting the record straight although I appreciate the honest 
opinion as this gives me something to work on in explaining what it is 
and what it is not. 

First off, don't try to compare this with an XMOS or GreenArrays (I think 
you mean) as they are very different. No, the Propeller is more like 8 
identical 32-bit CPUs + counter and video hardware and 512 longs of RAM 
each sharing all 32 I/O in common and coupled to a multi-port 32kB RAM 
(hub). Sounds strange? Okay, but the eight cogs are not really utilised 
for "parallel processing" but think of each cog as either a CPU or a 
virtual peripheral or both. The way it's used is that you might setup one 
cog as an intelligent quad port UART, another as the VGA cog, another as 
keyboard and mouse etc while maybe only one cog is processing the 
application. When you see it in action it is very simple to program even 
for a beginner. 

Seeing that each cog only has 512 longs of RAM which it directly 
addresses both source and destination in each 32-bit instruction, it 
becomes necessary then to run a virtual machine for high level 
application code. This is what Spin does as it compiles bytecode in hub 
RAM while one or more cogs may have the Spin interpreter loaded. My 
Tachyon Forth does something similar but has a much faster runtime speed 
and of course the target hosts a Forth development and runtime system. So 
I use bytecode that directly addresses the code in the first 256 longs of 
the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode 
instructions/second and since there are no interrupts!! nor any need for 
them then each cog runs unencumbered. Realtime software development and 
testing has never been easier.

Hopefully I've put it in some kind of nutshell. What do you think?
Weird? Yes, but it works really well :)

*peter*


 

On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote:

> On 13/01/2013 06:37, Peter Jakacki wrote:
>>
>> For some reason I found myself reading these newsgroups which I haven't
>> really used for many years. It seems that although the Parallax
>> Propeller web forums are extremely active there never seems to be much
>> discussion elsewhere. Aren't you all curious as to what you are missing
>> out on?
>>
>> I have used just about every kind of micro and architecture over the
>> decades and while I might still use some small "one buck" micros for
>> certain tasks and some special ARM chips for higher end tasks I have
>> almost exclusively been using Propeller chips for everything else. The
>> reason is very simple, they are so simple to work with and there are no
>> "peripheral modules" to worry about other than the counters and video
>> hardware per cog. Every pin is general-purpose and any one of the eight
>> 32-bit cores can use them, you don't have to worry about trying to
>> route a special pin or have the dilemma of using the special pin for
>> one function but not the other etc. The 32-bit CPUs or cogs are a
>> breeze to program and you can work with a variety of languages besides
>> the easy to use Spin compiler that comes with it.
>>
>> For you Forth enthusiasts there has been a big flurry of Forth related
>> threads on the Propeller forums of late and there are several versions
>> of Forth including my own Tachyon Forth. IMHO this is the best way to
>> get into the Propeller and it's hardware. I just can't be bother trying
>> to cram functions and debug interrupts on other chips when I can set a
>> cog to work on a task and still have plenty of resources left over
>> including video on-chip.
>>
>> If you are intrigued or just plain curious it won't kill you unless you
>> are a cat to have a look at my introduction page which has links to
>> projects and the forum etc.
>> http://goo.gl/VX7pc
>>
>> There is the sup'ed up version of the Propeller, the Propeller II
>> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM
>> and 160MIPS/core.
>>
>> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc)
>> that hang off the "I2C bus" from the Propeller and I can load new
>> firmware into each chip using just one extra line to program them
>> in-circuit.
>>
>> *peter*
>>
>>
> Had a quick look (again) - it's not very fast and it's not very cheap
> (compared with a CortexM4 clocked at 150MHz or more). Then there is all
> the pain of programming and synching multiple cores which is (I think)
> worse than the pain of managing DMA on a typical M4 based
> micro-controller.
> For some applications I'm sure it's a really good fit but I haven't hit
> one yet. It's similar in concept to XMOS and Greenchip offerings but
> like them suffers from a less than first rank supplier which would worry
> most of my customers.
> 
> MK

Almost forgot, as for "first rank supplier" I can only say that all the 
big companies are the ones that let you down because they upgrade and 
suddenly the chip you are using is no longer current and may become hard 
to get and of course expensive. Parallax have supported the little guy 
just as well as the big and they have a track record of continuing to 
support their product (in many ways) over the years with assurances as 
well. How many companies these days are willing to make their chips 
available in DIP as well as SMD simply for "that" market? 

I have STM32F4 designs I'm working on mainly for Ethernet, as well as 
other vendor's ARMs and while the chips are impressive you can't really 
compare their raw speed with what the Propeller does and how it does it.

Price is relative too but 8 bucks for eight 32-bit fully utilisable cores 
is very good value but the price goes down to under $4.50 in volume.

*peter*

In comp.lang.forth Peter Jakacki <peterjakacki@gmail.com> wrote:

> I use bytecode that directly addresses the code in the first 256
> longs of the Tachyon VM. Each cog runs at a maximum of 2.5M Forth
> bytecode instructions/second and since there are no interrupts!! nor
> any need for them then each cog runs unencumbered. Realtime software
> development and testing has never been easier.
> 
> Hopefully I've put it in some kind of nutshell. What do you think?
> Weird? Yes, but it works really well :)

I think this looks really good.  Fast and simple multi-tasking with
even less overhead than the simplest Forth scheduler.  Extremely low
latency.  Cheap, simple.  I'm sorry I didn't hear about this years
ago.

Andrew.

On Sun, 13 Jan 2013 07:24:35 -0600, Andrew Haley wrote:

> In comp.lang.forth Peter Jakacki <peterjakacki@gmail.com> wrote:
> 
>> I use bytecode that directly addresses the code in the first 256 longs
>> of the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode
>> instructions/second and since there are no interrupts!! nor any need
>> for them then each cog runs unencumbered. Realtime software development
>> and testing has never been easier.
>> 
>> Hopefully I've put it in some kind of nutshell. What do you think?
>> Weird? Yes, but it works really well :)
> 
> I think this looks really good.  Fast and simple multi-tasking with even
> less overhead than the simplest Forth scheduler.  Extremely low latency.
>  Cheap, simple.  I'm sorry I didn't hear about this years ago.
> 
> Andrew.

Yes, when you run a task in a cog then that is all it has to do. There is 
no need for task switching or interrupts etc. Some of my biggest 
headaches had to do with mysterious glitches which always end up being 
traced back to the wrong interrupts at the wrong time, but only 
sometimes, just to make it harder to find.

The P2 which is due to be released soon allows each cog to run up to 4 
tasks with zero switching overhead, you can even set the switching 
priority patterns in a 32-bit mask. But P2 runs 8 times faster than P1 
just in  terms of IPS alone without taking in account the many 
enhancements. Although the P2 has not yet been released there are many of 
us testing code for this on FPGA boards such as the DE2-115 or Nanos 
because Parallax made the FPGA binary for the P2 openly available. Can 
you beat that? Never ever heard of any chip company doing anything even 
close to that.  

*peter*

In article <LFxIs.2582$Ow3.159@viwinnwfe02.internal.bigpond.com>,
Peter Jakacki  <peterjakacki@gmail.com> wrote:
>On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote:
>
>> On 13/01/2013 06:37, Peter Jakacki wrote:
<SNIP>

>
>
>Seeing that each cog only has 512 longs of RAM which it directly
>addresses both source and destination in each 32-bit instruction, it
>becomes necessary then to run a virtual machine for high level
>application code. This is what Spin does as it compiles bytecode in hub
>RAM while one or more cogs may have the Spin interpreter loaded. My
>Tachyon Forth does something similar but has a much faster runtime speed
>and of course the target hosts a Forth development and runtime system. So
>I use bytecode that directly addresses the code in the first 256 longs of
>the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode
>instructions/second and since there are no interrupts!! nor any need for
>them then each cog runs unencumbered. Realtime software development and
>testing has never been easier.
>
>Hopefully I've put it in some kind of nutshell. What do you think?
>Weird? Yes, but it works really well :)

It sounds like GA144 done properly.

>
>*peter*
>
>
>
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 13/01/13 13:22, Peter Jakacki wrote:
> On Sun, 13 Jan 2013 10:26:31 +0000, MK wrote:
> 
>> On 13/01/2013 06:37, Peter Jakacki wrote:
>>>
>>> For some reason I found myself reading these newsgroups which I haven't
>>> really used for many years. It seems that although the Parallax
>>> Propeller web forums are extremely active there never seems to be much
>>> discussion elsewhere. Aren't you all curious as to what you are missing
>>> out on?
>>>
>>> I have used just about every kind of micro and architecture over the
>>> decades and while I might still use some small "one buck" micros for
>>> certain tasks and some special ARM chips for higher end tasks I have
>>> almost exclusively been using Propeller chips for everything else. The
>>> reason is very simple, they are so simple to work with and there are no
>>> "peripheral modules" to worry about other than the counters and video
>>> hardware per cog. Every pin is general-purpose and any one of the eight
>>> 32-bit cores can use them, you don't have to worry about trying to
>>> route a special pin or have the dilemma of using the special pin for
>>> one function but not the other etc. The 32-bit CPUs or cogs are a
>>> breeze to program and you can work with a variety of languages besides
>>> the easy to use Spin compiler that comes with it.
>>>
>>> For you Forth enthusiasts there has been a big flurry of Forth related
>>> threads on the Propeller forums of late and there are several versions
>>> of Forth including my own Tachyon Forth. IMHO this is the best way to
>>> get into the Propeller and it's hardware. I just can't be bother trying
>>> to cram functions and debug interrupts on other chips when I can set a
>>> cog to work on a task and still have plenty of resources left over
>>> including video on-chip.
>>>
>>> If you are intrigued or just plain curious it won't kill you unless you
>>> are a cat to have a look at my introduction page which has links to
>>> projects and the forum etc.
>>> http://goo.gl/VX7pc
>>>
>>> There is the sup'ed up version of the Propeller, the Propeller II
>>> coming out in the following months which has 96 I/O, 8 cogs, 128K RAM
>>> and 160MIPS/core.
>>>
>>> BTW, I use Silabs C8051F chips as specialised peripherals (ADC etc)
>>> that hang off the "I2C bus" from the Propeller and I can load new
>>> firmware into each chip using just one extra line to program them
>>> in-circuit.
>>>
>>> *peter*
>>>
>>>
>> Had a quick look (again) - it's not very fast and it's not very cheap
>> (compared with a CortexM4 clocked at 150MHz or more). Then there is all
>> the pain of programming and synching multiple cores which is (I think)
>> worse than the pain of managing DMA on a typical M4 based
>> micro-controller.
>> For some applications I'm sure it's a really good fit but I haven't hit
>> one yet. It's similar in concept to XMOS and Greenchip offerings but
>> like them suffers from a less than first rank supplier which would worry
>> most of my customers.
>>
>> MK
> 
> Since I've had a lot of experience with the Propeller and ARMs and I'm 
> familiar with M4s (still pushing out a design) then I can say that unless 
> you actually sit down with it for an hour or two that you will probably 
> continue to have this misconceptions. Is that the way that the Propeller 
> comes across? I've always wondered about that.
> 
> No, your idea of the Propeller is so off the mark, I'm saying that not to 
> offend, just setting the record straight although I appreciate the honest 
> opinion as this gives me something to work on in explaining what it is 
> and what it is not. 
> 
> First off, don't try to compare this with an XMOS or GreenArrays (I think 
> you mean) as they are very different. No, the Propeller is more like 8 
> identical 32-bit CPUs + counter and video hardware and 512 longs of RAM 
> each sharing all 32 I/O in common and coupled to a multi-port 32kB RAM 
> (hub). Sounds strange? Okay, but the eight cogs are not really utilised 
> for "parallel processing" but think of each cog as either a CPU or a 
> virtual peripheral or both. The way it's used is that you might setup one 
> cog as an intelligent quad port UART, another as the VGA cog, another as 
> keyboard and mouse etc while maybe only one cog is processing the 
> application. When you see it in action it is very simple to program even 
> for a beginner. 

I don't know about GreenArrays, but this sounds very much like XMOS
devices.  There are differences in the details, and the main languages
for the XMOS are C, C++ and XC (sort of C with a few bits removed, and
some parallel processing and XMOS features added) rather than Forth.
But it's the same idea - you have multiple CPUs so that you can make
your peripherals in software in a CPU rather than as dedicated hardware.

And I'd imagine it is similarly "easy" to work with - some things /will/
be easy, but other things will be a lot harder in practice.  In
particular, 8 cores/threads sounds great when you start, and you can
write very elegant UARTs, flashing lights, etc.  But in the real
application you need more than 8 cores, and you start having to combine
tasks within a single core/thread and the elegance, clarity, and ease of
development go out the window.  The other big problem is the small
memories - you start off thinking how cool these devices are that are so
fast you can make USB or Ethernet peripherals in software cores, using
ready-made "software components" from the company's website.  But then
you discover that to actually /use/ them for something more than a
flashing lights demo takes more ram than the chips have.


So it's a nice idea for some types of problem - but it is not unique,
and it is only really good for a small number of applications.

> 
> Seeing that each cog only has 512 longs of RAM which it directly 
> addresses both source and destination in each 32-bit instruction, it 
> becomes necessary then to run a virtual machine for high level 
> application code. This is what Spin does as it compiles bytecode in hub 
> RAM while one or more cogs may have the Spin interpreter loaded. My 
> Tachyon Forth does something similar but has a much faster runtime speed 
> and of course the target hosts a Forth development and runtime system. So 
> I use bytecode that directly addresses the code in the first 256 longs of 
> the Tachyon VM. Each cog runs at a maximum of 2.5M Forth bytecode 
> instructions/second and since there are no interrupts!! nor any need for 
> them then each cog runs unencumbered. Realtime software development and 
> testing has never been easier.
> 
> Hopefully I've put it in some kind of nutshell. What do you think?
> Weird? Yes, but it works really well :)
> 
> *peter*
> 

> you will probably
> continue to have this misconceptions. Is that the way that the Propeller
> comes across? I've always wondered about that.

Un unusal/non-mainstream architecture will always be
initally misjudged.

But some of the misconceptions are due to Parallax:
   if it has a smallish videogenerator then its probably
a retro arcade game machine chip ?
   While the spin language is usable, there
is nothing people like less then learning new weird
languages.
( 
http://www.parallax.com/portals/0/propellerqna/Content/QnaTopics/QnaSpin.htm
"Spin was inspired by portions of C, Delphi, and Python,
and a host of problem/solution scenarios ..." )
It could have easily been an extended BASIC or FORTH.

There are issues in implementation:
   The upper half of the 64k byte memorymap is a 32kbyte ROM
that contains the small 4k byte spin interpreter. That
ROM is rather underutilized with data tables.
This spin interpreter firmware is encrypted
http://propeller.wikispaces.com/Cracking+Open+the+Propeller+-+Original+Page
Which makes implementing other languages ontop
of it certainly much fun.
   Not much copy protection for the user
as the chip boots the application from an external
serial EEPROM to its internal SRAM.

There are issues in the basic concept:
   The round-robin access doesn´t scale very well.
If you go from 8 to 16 cores, the clock has to double
otherwise speed is down. So a 100 pin chip
can hardly have 64 cores.
   One can think of COG-RAM to HUB-RAM as an analogy
to the zero-page of an old 6502. But the speed penalty
is much worse: 4 clocks for COG versus 8...23 for HUB.
   Identical cores are one-size-fits-all. The propeller
may be flexible and fast concerning I/O, bit banging.
But an I/O core that interprets bytecode is probably no
match for even the smallest ARM in executing high level
language.

MfG  JRD

On Mon, 14 Jan 2013 10:51:39 +0100, David Brown wrote:


> I don't know about GreenArrays, but this sounds very much like XMOS
> devices.  There are differences in the details, and the main languages
> for the XMOS are C, C++ and XC (sort of C with a few bits removed, and
> some parallel processing and XMOS features added) rather than Forth. But
> it's the same idea - you have multiple CPUs so that you can make your
> peripherals in software in a CPU rather than as dedicated hardware.
> 
> And I'd imagine it is similarly "easy" to work with - some things /will/
> be easy, but other things will be a lot harder in practice.  In
> particular, 8 cores/threads sounds great when you start, and you can
> write very elegant UARTs, flashing lights, etc.  But in the real
> application you need more than 8 cores, and you start having to combine
> tasks within a single core/thread and the elegance, clarity, and ease of
> development go out the window.  The other big problem is the small
> memories - you start off thinking how cool these devices are that are so
> fast you can make USB or Ethernet peripherals in software cores, using
> ready-made "software components" from the company's website.  But then
> you discover that to actually /use/ them for something more than a
> flashing lights demo takes more ram than the chips have.
> 
> 
> So it's a nice idea for some types of problem - but it is not unique,
> and it is only really good for a small number of applications.
> 
> 

Well it seems that unless you try it you can't really judge it, that's 
for sure and in trying to judge it everyone is way off the mark. In terms 
of critique of your critique I would have to give you a very poor mark 
though. To mention flashing lights followed by "etc" is indicative of an 
early negative response and a attempt at minimalizing, as if you were 
Bill Gates talking about Linux. As for real applications I am always 
producing real commercial products with this chip so I think I know 
(actually, I do know) what goes into real apps having worked with a very 
wide variety of small to large micros through the decades (and still do).

Having read the rest of your comments I can't see where your fascination 
for flashing lights is coming from but I hope you are cured soon :)

BTW, the Propeller does very nice blinking lights along with simultaneous 
VGA and graphics rendering along with audio and SD, HID etc while still 
handling critical I/O in real deterministic time. The language and tools 
were the easiest to learn and use of any processor I've worked with.

Can't you see I'm not trying to sell them, I just didn't want to keep on 
being selfish keeping this good thing all to myself and the secret 
Propeller "Illuminati".


*peter*