FORTH use in Toys
Guy Macon
Note: I have crossposted this to misc.business.product-dev, which
is a newsgroup I moderate and which I am trying to get jump-started.
Please don't trim the newsgroup line. I will add everyone who
replies to this thread will be added to the good-posters whitelist
so your posts will be autoapproved for posting there. Thanks!
Elizabeth D Rather wrote:
>
>John Passaniti wrote:
>
>> If you're suggesting that someone might find a way to use Forth
>> in the high-volume domains that Guy Macon is talking about,
>> highly doubt it. In his domain, he's dealing with processors
>> that have *very* small amounts of program memory and RAM.
>>One processor I used (in the Zilog Z8 family) had 512 bytes
>> of program space and 32 bytes of RAM-- the processors Guy uses
>> are likely even smaller. You clearly can't host a traditional
>> Forth on such a platform, and with that kind of program space,
>> you're going to hand-code your program in assembly. Waiting
>> 30 years isn't going to change that.
>
>I believe Guy's point was that he *is* using Forth in his
>applications.
Yes. Not all, but some. But the result is far from "hosting a
traditional Forth on the target." For one thing, the target
might have a total I/O of one input switch and two output LEDs
or two switches and an audio output. What we were doing at Mattel
(I don't know what they are doing now, having moved on to do
consulting for multiple companies) was to hand-craft a language
to run on a PC that was a lot like Forth. The developer designed
it after reading Starting Forth and Thinking Forth, and (being
an engineer) mixed in a few of his favorite techniques used in
programming toys in assembly. He then shared it with others and
it was growing in popularity when I left.
> Even though you can't "host a traditional Forth" on those tiny
>platforms, Forth cross-compilers can be extremely helpful, even in
>debugging an all-assembler program (assuming it's a Forth assembler).
>The footprint required for a SwiftX cross-target link is extremely
>small, and it can be removed transparently, so you can use a slightly
>bigger (but pin-compatible) chip during development and then remove the
>XTL at the end to go with the tiny chip.
The forth-like language we used did a couple of things. First,
it would compile down to a really tiny executable for the small
ROM, Small RAM chips described above that looked a lot like
assembly with a tendency to thread and use stack more often than
usual. Second it would compile to a far more capable system for
large ROM, small RAM systems.
Consider, for example, the WinBond W566B025 and W566B120 processors.
They have 256 bytes of RAM, but have 94K and 382K of ROM to hold
both speech and program. See
http://www.winbond-usa.com/products/winbond_products/pdfs/Speech/w566bxxx.pdf
for details. On such a chip, a tiny reduction in audio length
gives the designer a large increase in code space, so ROM is
essentially limitless.
(There is also a good article at
http://www.audiodesignline.com/165702682?printableArticle=true
that explains some of the tricks we use to get audio out of a toy.)
>> And it's not just about small resources. Take one of my favorite little
>> microcontrollers-- the HCS08-family QG4's. These come in a 8-pin
>> package and in many applications one would use one of these little guys,
>> you're going to be using *all* the pins to interact with the system it's
>> in. In one recent project, I ended up using all six remaining pins and
>> I couldn't hack any of them for serial input/output to a console (or
>> even going half-duplex and using a single pin). In these kinds of small
>> systems, the biggest traditional value Forth has (interactivity) simply
>> can't work. And again, waiting 30 years isn't going to change that.
Waiting 30 years *will* change one aspect. Let me explain:
One would think that no matter how cheap transistors on a die get,
toymakers will always strive for the minimum that will do the job.
It turns out that many of today's very small microcontrollers are
pad limited -- the pads for the wire bonding are as small and as
close together as possible, and thus fewer/smaller transistors do
not reduce die size. As IC geometry shrinks, that little square
in the middle can hold more and more at zero added cost.
One would also think that the makers of the small microcontrollers
wouldn't bother changing to finer geometry, but it turns out that
they often buy all the equipment (or sometimes the entire factory)
when a big chip maker moves to a mew fab that handles smaller
features and larger wafers. Thus whatever the big boys had a while
back is what the makers of toy uCs have today.
All of this means that waiting 30 years is likely to result in the
cheapest microcontrollers having more RAM, more ROM and moving to
16 or 32 bit processors, all while remaining pin-count limited.
Consider the following products:
1940s - ENIAC. Memory: 0.02K. Clock: 0.06 MHz.
Cost: $5,000,000. Weight: 60,000 Lbs. Power: 140,000 Watts
1960s - IBM System 360. Memory: 64K. Clock: 1.3 MHz.
Cost: $1,000,000. Weight: 2,000 Lbs. Power: 2,000 Watts.
1980s - Commodore 128. Memory: 128K. Clock: 2 MHz.
Cost: $300. Weight: 10 Lbs. Power: 70 Watts.
2000s - Diva Starz doll CPU. Memory: 256K. Clock: 3.3 MHz.
Cost: Less than $1. Weight: < 0.1 ounce. Power < 0.1 Watt.
...So where will we be in the 2020s?
--
misc.business.product-dev: a Usenet newsgroup
about the Business of Product Development.
-- Guy Macon <http://www.guymacon.com/>
Guy Macon
John Passaniti wrote:
>I must have missed that. I read where he was talking about high-volume
>applications written in assembler "with Forth making some inroads" on
>these very tiny microcontrollers. The phrase "making some inroads"
>doesn't suggest Forth is in any way mainstream in that domain.
That is correct. My experience is with one group of developers
at one toy company (Mattel, the largest), includes boy's and
girl's toys (Barbie, Hot Wheels, etc.) but excluding infant toys
(Playskool toys are designed at a different facility) and a
limited time frame (after 2001 I was no longer a captive
employee and thus had no knowledge of what was going on inside
the engineering department). At the time I left, I would estimate
that 30% of the developers had either switched to Forth or were
looking into doing so, based on the large productivity gains we
were seeing.
So if the question is "Does Forth work well in a toymaking
environment" the answer is a definite yes. If the question
is "is Forth is in any way mainstream in toymaking?" The
answer is no. I would love to be able to say that my efforts
to introduce Forth revolutionized the entire industry, but I
did not accomplish so lofty a goal.
>I can easily see how using a cross-target link can be small. I would
>imagine a minimal SwiftX cross-target link only needs to implement a
>put, fetch, and call primitive to be useful, and that can't take more
>than a a couple or three dozen bytes for most platforms.
>
>But to say that one is "using Forth" in such a context seems like a
>stretch when you're writing code in assembler. It reminds me of a
>system I once saw where someone created an assembler using C macros and
>claimed you were "using C" to program the system. Nope. That's using
>the language as a mere side effect.
We weren't just using Forth as an assembler. For example, we had
an ongoing annoyance; having to make a new toy that is just like
an old one but with new audio files (remember, these are Masked-ROM
parts, so changing the audio means buying a minimum quantity of
50,000 of the new parts) and thus seemingly a good chance to re-use
existing code -- but another micro with a completely different
architecture just became a fraction of a cent cheaper, so we had
to write new code. With the forth-like language, we would rewrite
the language for the mew micro, and all of the programs would now
be usable unchanged simply by recompiling them.
It should also be noted that some of the low end processors
aren't really programmable computers. One was a 256-state
state machine with no data storage at all. That one won't
be programmed with a forthlike language anytime soon...
Guy Macon
John Passaniti wrote:
Guy Macon
Marcel Hendrix wrote:
>
>Guy Macon <http://www.guymacon.com/ writes Re: FORTH use in Toys
>[..]
>> Consider the following products:
>
>> 1940s - ENIAC. Memory: 0.02K. Clock: 0.06 MHz.
>> Cost: $5,000,000. Weight: 60,000 Lbs. Power: 140,000 Watts
>
>> 1960s - IBM System 360. Memory: 64K. Clock: 1.3 MHz.
>> Cost: $1,000,000. Weight: 2,000 Lbs. Power: 2,000 Watts.
>
>> 1980s - Commodore 128. Memory: 128K. Clock: 2 MHz.
>> Cost: $300. Weight: 10 Lbs. Power: 70 Watts.
>
>> 2000s - Diva Starz doll CPU. Memory: 256K. Clock: 3.3 MHz.
>> Cost: Less than $1. Weight: < 0.1 ounce. Power < 0.1 Watt.
>
>> ...So where will we be in the 2020s?
>
>This is a completely invalid chain of events.
Why would you think that? It clearly shows increasing
computing power moving into lower and loer cost products.
Note: I have crossposted this to misc.business.product-dev, which
is a newsgroup I moderate and which I am trying to get jump-started.
Please don't trim the newsgroup line. I will add everyone who
replies to this thread will be added to the good-posters whitelist
so your posts will be autoapproved for posting there. Thanks!