Re: slighty off-topic: intellasys tools

>   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

I like that diagram.  For one version it would
be expanded as follows

   U                        U
   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
 L 00 R 01 L 02 R 03 L 04 R 05
   U

Where L U at the bottom are the external
address and data busses and U at the top
are A/D D/A pins.  And some pins are have
input to the handshake line from the
missing L or U ports. If a node goes to
sleep accessing an address that selects
the missing L or U port pin activity can
wake it up.  This is how asynchronous
serial boot in ROM gets started.  A start
bit on a pin wakes ups the node and it
goes to code that figures out if it was
awakened to do serial boot or to act as
a normal worker given an executable
message from somewhere else.

Other pins are controlled through the IO
register on processors.  Software in ROM
defines SPI boot on 5, serial boot on 3,
12, 17, and 21 and optional external memory
boot from 0.  After you boot and load RAM
what you do with pins and cores is not
limited to what is in ROM.

> 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.

No. That's fine. You start with whatever was put
there to start with.

> Neat.  So in reality the serial signal would load
> node 3 with the crawler program?

You load whatever application code you like.
If you want to launch crawlers to test or initialize
nodes you can do that.  If you want to launch an
appliction forthlet that doesn't include that that's
fine too.

One should really just start by compiling programs
directly into the RAM of the simulated chip and then
exploring and debugging code.  Once you mastered all
that you are really ready to appreciate the cleverness
in the ROM BIOS and how to use that.  Then move to
forthlet wrappers and crawlers and concepts that build
on the other concepts.  Of course if you have been
thinking in machineForth code for years or who were
writing multiprocessor programs that did in software
the sorts of things that is being done here by some
hardware and some software then things like forthlet
wrappers and crawlers may be semi-obvious and you
may be ready for more advanced stuff.

> 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

Yes. I am suppose to create one of those pages too.
It may start with some of the stuff similar to
what I have posted in this list.

> 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.

And that's just part 1 right? ;-)

> 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 does make for an engaging demo that exercises
some distintive features of the architecture.  It
isn't big, but it makes a nice container object
that can deliver code to multiple locations and
run in parallel with other crawlers and other code.

> Hmmmm...that just brought up a possibility.
> If the pin were connected to another SEAForth
> chip....

  yes, 12 connects to 17, 3 connects to 21 on other chips
  on that model.   Serial bridges on those connections
  create a scalable array of cluster chips which are
  scalable in design themselves from a few cores to a
  lot of cores.

>  $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.

Right.  Those are ones that were used in the ROM BIOS.
There are 15 combinations of the four bits that select
those ports that select one or more of the com ports.

> 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.)

I can't answer it because I don't understand it.

The reason not every combination of ports were given names
in the dictionary in this application?  Software style?
If you want to use an address like -rl- in your code you
could probably figure out how to define it by looking
at the example you have shown from the ROM BIOS code.
It is documented in a lot of places, but I don't know
exactly which documents are on the web at this moment.

> "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.)

Sure.  One can dump any amount of information or make an
interface where if you click on this you zoom into ...
on top of the services used in text in the examples,
but then you will lose portability.  Front end stuff.

With minimal amount of info on each node and with small
fonts very large x, y arrays of processors have been
shown in simulation using all that screen real estate
that you speak of.  But some people do have bigger
screens than others.  But again we are just talking
about a front end that uses some style of visualization.

> 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.

Chuck likes that idea.  And we are releasing
cf stuff but it does take effort to draw a line
between what is going into the public domain and
what is considered proprietary cad tools.  And
that sort of effort cuts into some other effort
and we do have to focus on what we consider important.

> 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. :)

I can't even see the pins and some components any more
without a magnifying glass and on some packages I say,
'Those are the pins?'

We joke about how small our processors are. When you put
a bunch of them together it is big enough to see if you
are looking for it.  A single processor could be lost in
the dust pretty easily in a lot of places.  Even when
you put a bunch of them together it is a small chip.

Inserting a dongle into a USB slot is something I can do
most of the time. I look forward to it getting that easy
to play too.

Optional USB boot should be a nice feature on the new
colorforth too.  I suppose it might be possible to include
a bootable colorforth on the thumb drive evaluation board.
Something to think about anyway.