Re: [colorforth] slighty off-topic: intellasys tools
- Subject: Re: [colorforth] slighty off-topic: intellasys tools
- From: John Drake <jmdrake_98@xxxxxxxxx>
- Date: Thu, 12 Oct 2006 15:44:17 -0700 (PDT)
--- Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx> wrote:
> Let me try to help:
Thanks!
> 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.
I noticed north, south, east and west in the
rombios.mf file. I wasn't exactly sure how
that fit in. Thanks for the clarification.
> 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.
Ok. I think I understand now.
18 R 19 L 20 R 21 L 22 R 23
D D D D D D
12 R 13 L 14 R 15 L 16 R 17
U U U U U U
06 R 07 L 08 R 09 L 10 R 11
D D D D D D
00 R 01 L 02 R 03 L 04 R 05
> > ( $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.
Sorry. I'm sure it might look odd to people on the
list who haven't yet downloaded the SEAForth tools.
Yes, you do have to look at the crawler.mf and
crawl.mf code to understand what's going on. I was
just trying to get to the meat of what I didn't
understand.
> > 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.
Neat. So in reality the serial signal would load
node 3 with the crawler program?
> 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.
So far the only annotated code samples I've seen
are crawler and the random number generator on
"Michael's code corner" page. Michael's page
is very good and I look forward to future
installments.
http://www.intellasys.net/tools/michael.php
Nice to see him go from C psuedo code to
"ANSIsh" VentureForth code to optimized
"machine" VentureForth code and cut the
program size almost in half.
I agree the crawler was a bit much to bite
off and chew, but I definitely learned a lot
going threw it. And it goes a long way to
illustrating the power of the chip.
> It is consistent, but it not a case of 'everything'
> being 'reversed.'
Yeah. It's a case of me just being "lost" and
not figuring out the pattern on my own. Again
thanks for clearing this up.
> And L and U might not have neighbors. They may
> connect
> to pins instead of neighbors.
Hmmmm...that just brought up a possibility.
If the pin were connected to another SEAForth
chip....
> > 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.
Yes. I noticed that reading through the ROM BIOS
code.
$1d5 equ 'r---
$115 equ '-d--
$175 equ '--l-
$145 equ '---u
$1a5 equ 'rdlu
$1b5 equ 'rdl-
$185 equ 'rd-u
$195 equ 'rd--
$1c5 equ 'r--u
I noticed that some possible port combinations
are missing. Is that something that's changeable
in the bios or is it something that's fixed by
the chip fab? (And if this is a question that
can't be answered now I understand.)
> > 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.
"Matrix" mode sounds cool! One possible enhancement
that I thought of would be to allow the user to
"focus" on one node and show some of it's memory
contents while stepping through. SwiftForth has
enough "screen real estate" to be able to do that.
(GForth under Windows doesn't, but perhaps the
Mac and Linux versions are better.)
> 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
Well I look forward to the new release of
colorforth. I would love to see the CF version
of the SEAForth tools, but I understand the need
to keep some things under wraps. I see they'll
be a "thumb" drive SEAForth evaluation chip.
That's good because it will be accessible to
"solder illiterate" people like me. :)
Regards,
John M. Drake
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com
