distributed colorforth?

[David J. Goehrig]

Hey all I have a simple scenario that some colorforth programmers may
have some insight towards.

I am currently trying to evaluate colorforth for a personal project
involving some embedded work.  While
the project will eventually run on something other than x86, I have been
-fighting- playing with
colorforth on the PC to replicate the software environment of the end
device.

The control panel in question is a dual screen touch input device
roughly the size of a typical paperback novel,
the hardware is readily available off the shelf dual PXA boards with
wifi (802.11b/g) with 2GB microSD cards
for storage.  The current design has one processor per screen, and the
communicate to each other over the network.

My vision for this thing is one part e-book, one part network console,
one part fun hobby project.  (although I've had some interest from
medical device people and education especially now that the new OLPC
design is public).

What I'm looking for is:

1.) A rough estimate of how much colorforth is currently x86 specific
and will require porting
2.) A rough estimate of how many screens in colorforth it would be to
write a basic 802.11b/g stack w/ support for UDP

My thinking is that if I can port colorforth, and get a basic wireless
stack setup to the point where I can fire off UDP
packets to a remote server then building the rest of the interface will
be trivial in comparison.  From a software
standpoint, what I'd like to do is have a simple client server program
written in colorforth that sends "forthlets" over
UDP between the processors for evaluation. (these same forthlets can be
fired off to any number of colorforth servers
on the net for processing that can't be handled locally)

The other language that I'm evaluating for this project is Erlang, which
has the basic client server messaging model built
into the language, but I don't care for the huge amount of overhead the
full OTP + Linux solution would place upon the device.

It seems to me in the world of multiple processors, and distributed
applications, Forth (and Object Oriented Forths) would be
the ideal fit.  Any ideas?

Dave

PS. Yes I would love to get my hands on a nice multiprocessor chip that
would work as a CPU/DSP combo.  I've got a Xilinx
Virtex4 eval board that I've been planning on prototyping such a beast
on, but I don't think I'll ever have enough time to
do it.


Email: dave@...

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Jeff Fox-2]

Dave,

Your project sounds good.  I would recommend that you look at
http://www.reda4.org

Pablo Reda's web site about his colorforth variants may be
of help to you.  I ran his reda4 ipaq code (PXA255 I think)
and it might have a lot of what you are looking for already
coded.

Pablo used the OS interface that was present however rather
than building a stand-alone system that included its own
OS services. Chuck prefers to build from the ground up but
it may make more sense for you to build on top of drivers
that you already have available for the hardware you are
using, touch screen, display, network services, files on
the SD card etc.   Or perhaps you have studied all the
low level details and want to jump it at the lowest
driver level. I don't know how much of Pablo's code
would be of use to you, if any, but I do recommend that
you check into it yourself.

If you google on Pablo Reda you can get pages translated
to English but there are other ways to get translations.
Maybe you wouldn't need translation. ;-) You might want
to email him with questions about his colorforth variant
if that makes sense.

He has a PC version and an ipaq version of reda4.  He has
pages about using it for educating children.  There are a
lot of screen shots etc.  If it has some of what you
need I would think you want to download a copy and run it
on an ipaq to help with the job of porting.

I did some colorforth like code for F21 way back when.
Chuck is interested in making a SEAforth version of
colorforth instead of developing SEAforth code in
colorforth on a Pentium PC.  He wILL also port the
okad colorforth code to processors of his own design.
He has been interested in what other people find when
they create a colorforth for a new environment.

I think it is also interesting that you have more than
one processor and can have both multitasking and
multiprocessing without going to an outside network
for more remote processors. I will be happy to comment
on your approach to the multiprocessing aspect of your app.

Best Wishes

> Hey all I have a simple scenario that some colorforth
> programmers may have some insight towards.
>
> I am currently trying to evaluate colorforth for a personal project
> involving some embedded work.  While
> the project will eventually run on something other than x86, I have been
> -fighting- playing with
> colorforth on the PC to replicate the software environment of the end
> device.
>
> The control panel in question is a dual screen touch input device
> roughly the size of a typical paperback novel,
> the hardware is readily available off the shelf dual PXA boards with
> wifi (802.11b/g) with 2GB microSD cards
> for storage.  The current design has one processor per screen, and the
> communicate to each other over the network.
>
> My vision for this thing is one part e-book, one part network console,
> one part fun hobby project.  (although I've had some interest from
> medical device people and education especially now that the new OLPC
> design is public).
>
> What I'm looking for is:
>
> 1.) A rough estimate of how much colorforth is currently x86 specific
> and will require porting
> 2.) A rough estimate of how many screens in colorforth it would be to
> write a basic 802.11b/g stack w/ support for UDP
>
> My thinking is that if I can port colorforth, and get a basic wireless
> stack setup to the point where I can fire off UDP
> packets to a remote server then building the rest of the interface will
> be trivial in comparison.  From a software
> standpoint, what I'd like to do is have a simple client server program
> written in colorforth that sends "forthlets" over
> UDP between the processors for evaluation. (these same forthlets can be
> fired off to any number of colorforth servers
> on the net for processing that can't be handled locally)
>
> The other language that I'm evaluating for this project is Erlang, which
> has the basic client server messaging model built
> into the language, but I don't care for the huge amount of overhead the
> full OTP + Linux solution would place upon the device.
>
> It seems to me in the world of multiple processors, and distributed
> applications, Forth (and Object Oriented Forths) would be
> the ideal fit.  Any ideas?
>
> Dave
>
> PS. Yes I would love to get my hands on a nice multiprocessor chip that
> would work as a CPU/DSP combo.  I've got a Xilinx
> Virtex4 eval board that I've been planning on prototyping such a beast
> on, but I don't think I'll ever have enough time to
> do it.
>
>
> Email: dave@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@...
> For additional commands, e-mail: colorforth-help@...
> Main web page - http://www.colorforth.com
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[David J. Goehrig]

Jeff Fox wrote:
> Dave,
>
> Your project sounds good.  I would recommend that you look at
> http://www.reda4.org
>  
Thanks Jeff, very interesting indeed.
> Pablo used the OS interface that was present however rather
> than building a stand-alone system that included its own
> OS services.
Do you know it was running R4 linux or R4 wince on the ipaq?  I doubt either
of my ipaqs even have the original roms :)

I see that he's using SDL, so it doesn't really matter which I guess :)
> Or perhaps you have studied all the
> low level details and want to jump it at the lowest
> driver level.
Well for sake of simplicity the hardware I'm using comes with a linux ROM
installed, and I'm tempted to just use that for wifi, framebuffer, SD
access,
and the touchpad ttys.

But since the hardware is so limited anyways, it might make as much sense to
reimplement the specific drivers.  Depends on how small a build the
kernel becomes.
> If you google on Pablo Reda you can get pages translated
> to English but there are other ways to get translations.
> Maybe you wouldn't need translation. ;-)
I probably should do that, though my Spanish composition is terrible
these days  :)

At least I can read his site!
> Chuck is interested in making a SEAforth version of
> colorforth instead of developing SEAforth code in
> colorforth on a Pentium PC.  He wILL also port the
> okad colorforth code to processors of his own design.
>  
My impression is that the hardest part is going to be factoring code
into 64 words
messaging between chips efficiently.  Assuming you could however, using
something
like SEAforth chip for modeling protein folding would be an incredible.
> I think it is also interesting that you have more than
> one processor and can have both multitasking and
> multiprocessing without going to an outside network
> for more remote processors.
I've been doing a lot of cellphone programming these days, and I think
the hardware
is far more capable than people realize.  If you look at the
power/performance cost
of the 400-600mhz PXA chips, the boards I'm looking at draw ~250mA  @
3.6V- 5V,
and the screens I'm looking at take 25mA @ 3.3V for 18bit TFT-LCD w/
backlight.

That's a small amount of power for the equivalent of a Pentium III w/
display.  And
that's more than enough processing power to drive a postscript based
display.  Which
is part of the reason I'm considering colorforth, as I can write a
postscript interpreter
(or PDF interpreter) fairly easily in it.
>  I will be happy to comment
> on your approach to the multiprocessing aspect of your app
Thanks Jeff


--

David J. Goehrig


Email: dave@...


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com

[Pablo H. Reda]

Thanks Jeff for the reference !!

Hi Dave,
I start in the Ipaq plataform, in C ,I'm not using this now.
if you like I can send the source code, is for eVC (2005).

If you machine run a linux, perhaps change the source of the gcc version (lin & win) can work.

writeme if you need something.

Pablo

[Albert van der Horst]

On Thu, Jun 05, 2008 at 10:43:19AM -0400, David J. Goehrig wrote:
> Hey all I have a simple scenario that some colorforth programmers may
> have some insight towards.
>
> I am currently trying to evaluate colorforth for a personal project
> involving some embedded work.  While
> the project will eventually run on something other than x86, I have been
> -fighting- playing with
> colorforth on the PC to replicate the software environment of the end
> device.

You will find colorforth one of the hardest systems to port.
Either you like colorforth very much, then you are best off
reimplementing it from specifications. (Those you have to
write mostly yourself).
Or, if you want some Forth and want to be able to change it, you
can start with something that has been written with
reimplementation/portability in mind, like my ciforth.
(Currently 80x86 (8 flavors), 6809, M16C, Dec Alpha)

Compiler is GPL, your programs are your own.

<SNIP>
>
> Dave
>
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@...
For additional commands, e-mail: colorforth-help@...
Main web page - http://www.colorforth.com