EEPROM is FULL -- LAST WORD, PLEASE....
Archiver
Posts: 46,084
Let me clarify what I didn't. We choose NOT to rewrite the BASIC Stamp
interpreter core (we add new features to it from time-to-time, but the
architecture remains intact). Why? Because we have MILLIONS of units
in the field and to make a big change in our existing line would create
a service and support nightmare. Other companies promise future
features with "upgrades" then fail to deliver -- there's lots of public
evidence of this fact.
Since we will not change the interpreter architecture, any new feature
has to be added via the compiler and the current token set. About three
years ago our compiler engineer had an idea that he thought would create
a single 16K program block, all by using the compiler. I was on him
night and day about this, but in the end, he couldn't make it work.
Trust me, he spent hundreds of hours trying.
Garage shops and copy-cats don't have to hold themselves to the same
standards that we do. RadioShack has selected OUR product over all that
is available. Why do you think that is? I'll tell you: they've seen
our long track record of reliability and service, and that's the kind of
product that they want in their stores (they don't want to have to
support the product and know we can, do, and will).
To end the hair-spitting, nothing is impossible, but there are times
when responsible business managers have to make difficult choices.
Sometimes those choices aren't popular with customers, but usually that
dissatisfaction is short-term, because most understand that long-term
viability of a product and a company is what's really important. There
are lots of "like a Stamp, only better" products that have long since
died....
We're an innovative company, and true innovation doesn't come easily or
cheaply. Don't let our lack of new releases lull you into thinking
we're not doing anything. I wish I could tell you what's coming, but I
can't. Trust me, it's unbelievably cool, and just like the original
BASIC Stamp, it is entirely original. You've seen nothing like it.
Enough on this thread. Happy 4th everybody.
Jon Williams
Parallax
Original Message
From: TBooneFisher [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=8RCZktQ8UVK9hZi9hS23aesQq2zWsGKVBYtCmrNfbpXvvxDJ3ObAN4LwqpcUgJWelqGIKrmSJRs9RgfEt1XQlWwq]tboonefisher@s...[/url
Sent: Saturday, July 03, 2004 8:49 PM
To: basicstamps@yahoogroups.com
Subject: Re: [noparse][[/noparse]basicstamps] EEPROM is FULL
> don't download assembly language to it, we download program tokens
> (very much like Java bytecodes) that are handled by the PBASIC
> interpreter. For better worse, the current interpreter architecture
> limits us to 2K boundaries (this is BS2 legacy).
>
Jon, I'm completely aware of the program tokens that are
*intepreted* and that it is the machine language architecture of the
*interpeter* that would need to be modified/rewritten. I'm sure this
might be an expensive, time consuming BUT certainly not impossible task.
It's the use of the word 'impossible' that I take exception to. I'll
certainly agree that it is not possible with the current interpreter
machine code.
Anywho, we are obviously splitting hairs here and I appologize to all
who were offended. But please be careful about throwing around words
like impossible, never, etc etc. Tom Fisher Dallas,TX
interpreter core (we add new features to it from time-to-time, but the
architecture remains intact). Why? Because we have MILLIONS of units
in the field and to make a big change in our existing line would create
a service and support nightmare. Other companies promise future
features with "upgrades" then fail to deliver -- there's lots of public
evidence of this fact.
Since we will not change the interpreter architecture, any new feature
has to be added via the compiler and the current token set. About three
years ago our compiler engineer had an idea that he thought would create
a single 16K program block, all by using the compiler. I was on him
night and day about this, but in the end, he couldn't make it work.
Trust me, he spent hundreds of hours trying.
Garage shops and copy-cats don't have to hold themselves to the same
standards that we do. RadioShack has selected OUR product over all that
is available. Why do you think that is? I'll tell you: they've seen
our long track record of reliability and service, and that's the kind of
product that they want in their stores (they don't want to have to
support the product and know we can, do, and will).
To end the hair-spitting, nothing is impossible, but there are times
when responsible business managers have to make difficult choices.
Sometimes those choices aren't popular with customers, but usually that
dissatisfaction is short-term, because most understand that long-term
viability of a product and a company is what's really important. There
are lots of "like a Stamp, only better" products that have long since
died....
We're an innovative company, and true innovation doesn't come easily or
cheaply. Don't let our lack of new releases lull you into thinking
we're not doing anything. I wish I could tell you what's coming, but I
can't. Trust me, it's unbelievably cool, and just like the original
BASIC Stamp, it is entirely original. You've seen nothing like it.
Enough on this thread. Happy 4th everybody.
Jon Williams
Parallax
Original Message
From: TBooneFisher [noparse]/noparse]mailto:[url=http://forums.parallaxinc.com/group/basicstamps/post?postID=8RCZktQ8UVK9hZi9hS23aesQq2zWsGKVBYtCmrNfbpXvvxDJ3ObAN4LwqpcUgJWelqGIKrmSJRs9RgfEt1XQlWwq]tboonefisher@s...[/url
Sent: Saturday, July 03, 2004 8:49 PM
To: basicstamps@yahoogroups.com
Subject: Re: [noparse][[/noparse]basicstamps] EEPROM is FULL
> don't download assembly language to it, we download program tokens
> (very much like Java bytecodes) that are handled by the PBASIC
> interpreter. For better worse, the current interpreter architecture
> limits us to 2K boundaries (this is BS2 legacy).
>
Jon, I'm completely aware of the program tokens that are
*intepreted* and that it is the machine language architecture of the
*interpeter* that would need to be modified/rewritten. I'm sure this
might be an expensive, time consuming BUT certainly not impossible task.
It's the use of the word 'impossible' that I take exception to. I'll
certainly agree that it is not possible with the current interpreter
machine code.
Anywho, we are obviously splitting hairs here and I appologize to all
who were offended. But please be careful about throwing around words
like impossible, never, etc etc. Tom Fisher Dallas,TX
Comments
> interpreter core (we add new features to it from time-to-time, but the
> architecture remains intact). Why? Because we have MILLIONS of units
> in the field and to make a big change in our existing line would create
> a service and support nightmare. Other companies promise future
> features with "upgrades" then fail to deliver -- there's lots of public
> evidence of this fact.
>
As I said from the start of this discussion. Expensive, time consuming,
probable poor business move, etc, etc etc........BUT not impossible. Any
experienced assembly language programmer will verify this.
Again I have great respect for your company, it's products and it's service.
Please keep up the great work!
Tom Fisher
Dallas,TX
ps.....How many involved in this discussion have machine code
experience?
personally have programmed off and on in machine code since 1983 on the
6502 architecture. The interesting thing (and perhaps more relevant) is
that the larger, more complex, a system you're running, the more you have
to be concerned about things like code efficiency. If you're running a 2G
processor with a gig of memory optimizing small loops becomes less and
less important.
I've actually wondered why the architecture of the stamp is inherently
interpreted, rather than compiled. It seems like it would have added a
little speed to the chip and not taken a tremendous effort to compile to
native 16f84 architecture rather than to BSx bytecode. Was this just a
particular decision that was made at the beginning of the company?
On Sat, 3 Jul 2004, TBooneFisher wrote:
> ps.....How many involved in this discussion have machine code
> experience?
>
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and Body of the message will be ignored.
>
> Yahoo! Groups Links
>
>
>
>
>
>
Sean T. Lamont, Director Of Engineering
Innovative Communications Technologies, Inc. http://www.ict.net
email: lamont@a... / sean@i...
"Do not fear mistakes, There Are None" - Miles Davis
That 6502 wouldn't have been in an Ohio Scientific computer would it? If so,
I installed and worked on dozens of them on the east coast in the mid 80's.
And yes, I wrote a few things in machine code for it, mostly to add more I/O
gadgets. Small world, isn't it.
Mike Sokol
mike@f...
301-739-6842 (office)
301-964-5682 (mobile)
Original Message
From: "Sean T. Lamont .lost." <lamont@a...>
To: <basicstamps@yahoogroups.com>
Sent: Wednesday, July 07, 2004 2:51 PM
Subject: Re: [noparse][[/noparse]basicstamps] EEPROM is FULL -- LAST WORD, PLEASE....
>
> I expect you'll find a few PIC assembly programmers on this list. I
> personally have programmed off and on in machine code since 1983 on the
> 6502 architecture. The interesting thing (and perhaps more relevant) is
> that the larger, more complex, a system you're running, the more you have
> to be concerned about things like code efficiency. If you're running a 2G
> processor with a gig of memory optimizing small loops becomes less and
> less important.
>
> I've actually wondered why the architecture of the stamp is inherently
> interpreted, rather than compiled. It seems like it would have added a
> little speed to the chip and not taken a tremendous effort to compile to
> native 16f84 architecture rather than to BSx bytecode. Was this just a
> particular decision that was made at the beginning of the company?
>
> On Sat, 3 Jul 2004, TBooneFisher wrote:
>
> > ps.....How many involved in this discussion have machine code
> > experience?
> >
> >
> >
> >
> > To UNSUBSCRIBE, just send mail to:
> > basicstamps-unsubscribe@yahoogroups.com
> > from the same email address that you subscribed. Text in the Subject
and Body of the message will be ignored.
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
>
> Sean T. Lamont, Director Of Engineering
> Innovative Communications Technologies, Inc. http://www.ict.net
> email: lamont@a... / sean@i...
> "Do not fear mistakes, There Are None" - Miles Davis
>
>
>
> To UNSUBSCRIBE, just send mail to:
> basicstamps-unsubscribe@yahoogroups.com
> from the same email address that you subscribed. Text in the Subject and
Body of the message will be ignored.
>
> Yahoo! Groups Links
>
>
>
>
>
>
> I've actually wondered why the architecture of the stamp is inherently
> interpreted, rather than compiled. It seems like it would have added a
> little speed to the chip and not taken a tremendous effort to compile to
> native 16f84 architecture rather than to BSx bytecode. Was this just a
> particular decision that was made at the beginning of the company?
The 16F84 (originally 16C84) is a reasonable device for a BS1 "compiled
work-alike" and several products appeared about a decade ago using it in
that role.
When the BS2 was being developed, the 16C84 was the only PIC with
EEPROM/Flash program memory, and it doesn't have the memory or I/O pins to
match the BS2's program size or I/O pin count. With the components
available at the time, Parallax apparently decided that the tradeoff leaned
toward the interpreted approach, and the BS2 has certainly been successful.
Things have changed dramatically in the last 5 years or so with the large,
powerful flash memory micros now available, which has given rise to the
various compiler-based "Stamp alternatives." It will be interesting to see
the implementation (compiled vs. interpreted) of the new "killer" Stamp that
Jon has been hinting about.
-Randy
www.glitchbuster.com