Re: [colorforth] slighty off-topic: intellasys tools

["Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>]

Let me try to help:

port names are U D L R for Up Down Left Right, but
those are local names and depend on the orientation
of a core to map to global North South East West
directions.

Going east from node 0 is right to node 1.
Going west from node 1 is right to node 0.
node 0 is in an odd column, node 1 is in an even column.

When two people are facing each other they shake
hands right hand to right hand. If they face in
the same direction and touch hands they will touch
right hand to left hand.  Picture 24 people touching
heads to heads, feet to feet, right hand to right hand,
left foot to left foot.   Now picture that you could
describe a route as right left right left to pass
a message across a row of people.   Now picture that
this array is scalable with x by y on each cluster
and clusters connecting in arrays.

So east alternates from right to left depending
on odd or even columns.  North alternates from
up and down depending on odd or even rows.
There is a NSEW table in ROM used by routing words
and neighborhood access words.

So you can describe a route as N N E E and it is
probably what you expected from up up right right
local port names.

Routing uses two bits in a route descriptor to index
into the NSEW table on each node.  Neighborhood words
use it as extended addressing to get access to a NSEW
neighbor's memory or CPU.

> Hello Arno.
>
> Technically I suppose this fits the "machineForth"
> mailing list, but I it's not like either list has
> been "overflowing" with activity and I believe
> anyone interested in ColorForth is interested
> in what's happening at IntellaSys. :)
>
> I've downloaded the tools and I've gone through
> the "crawler" example enough times to have some
> idea of what's going on.  I am a bit confused
> as to how the routing is supposed to work in the
> "test.mf" program.
>
> ( $Id: test.mf,v 1.7.2.3.4.1 2006-09-27 03:00:14
> michael Exp $ ) \ test
> machine-forth
> [ hex 0 org ]
> : test          \  3
>   D		\  9
>   L		\ 10
>   R		\ 11
>   U		\ 17
>   R		\ 16
>   D		\ 22
>   L		\ 21
>   D		\ 15
>   R		\ 14
>   D		\ 20
>   L		\ 19
>   R		\ 18
>   D		\ 12
>   R		\ 13
>   U		\  7
>   L		\  8
>   D		\  2
>   R		\  3
>   dup dup xor $3f
>   dump
>   cold -;

Pretty confusing without context.  Those are direction
words for a crawler that follows that path.  Without
enough context it looks very odd.

> Here's an abreviated version of the node map that
> comes up when then simulator is run.
>
> 18 19 20 21 22 23
> 12 13 14 15 16 17
> 06 07 08 09 10 11
> 00 01 02 03 04 05
>
> Ok.  This simulation starts with node 3.

The reason the simulation starts with node 3 is that
that simulation uses a simulated off chip testbed to
feed a serial signal into one of the pins of node 3.
When node 3 sees a start bit it wakes up and executes
boot code. It loads a program which runs on 3.

The most complicated example yet provided I think is
the crawler that replicates itself and moves around
the chip delivering test or initialization code.  I
would not recommend starting with lots of other stuff
and getting a good grasp of it before going to
advanced topics like the the crawler or the use of
ROM BIOS services in applications.

> Then
> "D" takes you "down" to node 9?

Row 1 is down from row 0, so 3 north is down to 9.
Row 0 is down from row 1, so 9 south is down to 3.

> And "L" takes
> you "left" from node 9 to node 10?

Column 1 is right from column 0, so 1 is east of 0.
Column 0 is right from column 1, so 0 is west of 1.

> That would
> lead me to believe that everything is "reversed"

"everything" is not "reversed."

> except that "R" takes you "right" from node 10
> to node 11.

Certainly just as right takes you east from 0 to 1.

> The code is consistent in that
> horizontal moves "L" or "R" always move to
> nodes in the same row and horizontal moves
> "U" and "R" always move to nodes in the same
> row, but sometimes the move is in the opposite
> direction of what I would expect.

It is consistent, but it not a case of 'everything'
being 'reversed.'

And L and U might not have neighbors. They may connect
to pins instead of neighbors.

> I'm sure this will be cleared up when the rest
> of the documentation is released.  I feel
> pretty confident in my understanding of how
> the interprocess communication works.  And

One of the most important things is the way that
multiple ports can be selected at one time at certain
addresses.  Reading or writing of multiple ports at
the same time with a neighbor cooperating but not
doing exactly the same thing is one of the important
hardware features that the software and ROM BIOS uses.

> the simulator demonstrates pretty well how
> the internode communication works.  I look
> forward to working with the SEAForth family.

We have experimented with different user interfaces
to help visualize the global situation and watch the
interactions between different nodes in applications.

People enjoyed seeing a small crawler program copying
itself to other nodes and delivering test or initialization
code to all the nodes on the chip when we first demonstrated
it because it helps visualize the global picture.  We have
also tried other formats than the 2d format of x, y
orientation that matches the nodes on the first chips. We
also have a 'matrix' mode.   The idea is to separate the
front end visualization from the simulation and allow it
to work different ways to help debug different kinds of
programs.

Watching nodes send X0 messages to the RAM server and
watching it execute Forthlets and route programs and data
to other nodes helps understand what the ROM BIOS services
do just as watching a chip boot from a pin in serial or
SPI mode and load some code from the outside world helps
get a sense of how some of some of ROM BIOS features being
exercised. So far the website has only scatched the surface
unless you somehow spend enough time to reverse engineer
how all those ROM BIOS services are going to work together
by looking at the source code.

We also have colorforth tools and ways to move target code
between the environments.  I know this is the colorforth
mail list and there has been some interest in the colorforth
tools.

There is a plan to release a completely new version of
colorforth soon.  There are no plans to release the target
tools that we run under colorforth in the near future as
they are part of our in-house okad software package.
But I think the new colorforth will solve many of the
problems that people have had with the original release.

Best Wishes


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