Re: MISC-d Digest V99 #16
- To: MISC
- Subject: Re: MISC-d Digest V99 #16
- From: "GARY B. LAWRENCE" <garyl@xxxxxxxxxxx>
- Date: Sun, 07 Mar 1999 04:36:59 -0700
- References: <199903061000.GAA14804@pisa.rockefeller.edu>
- Reply-To: garyl@xxxxxxxxxxx
>
> Dr. Ting wants to push someone into Forth enlightenment as soon
> as possible. ;-) That is his idea of minimalism and it makes
> him incredibly productive. Who else publishes one new book
> and a new Forth system every month in his spare time, works
> a job, and goes to college?
I want to thank Dr. Ting for putting up the money to do the first
version of
Chuck's forth chip. I have put together an MUP21 board and would like
to mention
a few things that I noticed.
1. I had ordered some of Ting's books
More on Forth Engines and much of the needed
documenation was in these books. This made it hard not only for me
to build the
board, but to organize the information. Other people who did not
order these
books were not given the information in the adds that they needed
these books.
2. When I received the construction kit I noticed that there was no
parts placement guide. This should not have been a problem
for me since this is a
simple board containing simm holes, rom holes, 74245, and 74574
holes.
I did manage to put a 82 ohm resistor in the wrong holes
because I did not carefully follow the schematic to place them
correctly. This
would have been easier with a parts placement diagram. When I
pulled these parts out I messed up the traces to them and had
to build point to point placement traces. This was not hard
for me since I have done wire wrap circuits
for 6502 projects, memory, floppy disk controlers, parallel port
connectors and so forth. I think a little more information is
needed for most kit projects
since one cannot assume that all people have done a lot of
wirewrap and machine
code construction.
3. I have a copy a letter I sent to Dr. Ting about design concerns.
Here is the list.
a. put bypass cap holes and silk screen labels near each chip,
the speed of
this board is helped by more bypass caps.
b. put in a line of holes near the J2 connector for a pullup
resistor array
I have a friend who puts holes for these kind of resistor
packs on even
smaller boards and having the option of using the pullup
resistor can make key scans and other buttons much easier
to do. I added pullups to the seven key keyboard that hooks
in to this board through this J2 connector and it would
have been easier to have this resistor array on the MUP21
board.
c. Renumber the J2 connector so that when a parallel ribbon
cable is put on
the color coded pin one of the cable is the same as pin one
on the connector. This was hard for me to follow because
all previous things that I had worked on followed the
standard.
d. a friend thought that the unused Simm data lines should be
pulled up with resistors so that they did not oscillate and
use extra power.
e. I also described the parts placement diagram that I have
already mentioned.
I will describe some of the problems I had bringing the board up.
a. broken traces caused by placing video 82 ohm resitor wrong -
my fault
b. problems with Simm socket - my fault bad solder job.
c. needed different support chips - 74HCT245 and 74HCT574 and
74HCT138
this information either came from Dr. Thing or from one of the More
on Forth Engines books. The parts list showed HC parts and HCT
parts worked
faster I think ?
d. I tried an 8meg dram board - heated up and caused bus
contention
- my fault.
e. I killed a 4meg dram - due to solder problems on simm socket -
my fault.
f. I put the video output through the J2 connector thru the
parallel cable
not a good 75 ohm coax cable -then 18 inches later on the
seven key keyboard I do use a rca connector about 30 inches
long to an rca video input on a VCR. There is no termination
on any of this other than the 82
ohm resistor on the MUP21 board. The VCR is set to rca input
mode and puts
the output to channel 3 since channel 4 is used in this area.
The reason I mention this is that when I got the tv tuned to
channel 3 and
put the demo 16 rom in the Forth board I got a very good
display and the
seven key keyboard also worked.
Jeff Fox said
> I love Fat Forths. I just hate FAT. These are not mutually
> exclusive things. I want everything (functionally not the ANShit)
> in my system. I want everything you have in a professional
> tools with all the optimized cool stuff we want. I just want
> mine 1000x smaller than yours. Don't worry that is the whole
> idea of our tiny machine and Machine Forth. We want all the
> same stuff we just want it 100 to 1000 times smaller and
> 10 to 10000 times faster than with ANSFAT.
I ordered the P21 ANS Forth software done by Jeff and got a rom
image on a 1.44 floppy and had a friend blast an eprom for me.
I do not understand why Dr. Ting did not send just a rom or both
a rom and the disk. The disk contained two versions of P21 Forth -
one with fast address decoding and one with slow address decoding
. I used the fast one.
When you go into the code to link up to the rs232 port the screen
jitters like crazy because much time is spent polling the i/0
addresses - this clears up once
the chip syncs up to 9600 baud input. I still have sceen jitter
using P21 - I think because the high level words have to cross many
memory page boundries and
also I am running my chip at 5 volts instead of using 5.7 volts as
Jeff mentioned. When I put in the demo rom I see no jitter - I am
assuming that the demo code was written within one memory page
when ever possible.
Now doing rs232 produced some problems. I have a note in documents
which states
that you should use an F-PC boot program called Ghost. I do not
remember getting
that program and I have a lot of F-PC tools downloaded over the
years. I instead
used a tool written for F-PC with a title like RS232. I looked at it
and it had
a simple serial terminal word. I added an escape sequence to this
code and started to play with the MUP21 using P21 Forth. I first
took the standard F-PC editor and added a word I call Fsend which
would redirect the load code out the
rs232 port. This is possible because it seems that every major I/O
address is made so that it is defered. That means everything can be
redirected. All I had to do was find the character output location
and redirect it. At the same time I wanted to make this work the
same way that fload works - that is you can have a
major load file that loads a file that also can do fload. What has
to happen
is that as soon as the second level fload word is hit the higher
lever fload
word has saveD the file handle, the line number, the input number
and a few other
things. I thought that this would be easy for me to find because of
the ability
for the code to be redirected. When I tried to change the code I
could go one level down
fload dog
( dog )
fsend foo
but when my code returned it would be out of place on the return
input pointer
and would try to execute dog and put up an error message.
I spent some time trying to understand the problem and while doing
so I came to a
better understanding of why both Chuck Moore and Jeff Fox talk so
much about doing smaller words and simpler code. I very much like
the fact that Tom Zimmer
and others have done F-PC and later Win32for for windows 95/98/NT,
but much of the code contains words that are not two or three lines,
but thirty to forty lines of code. This code is much better done and
better documented than my own code but large words are harder to
understand than small ones and when looking at a small
difference in calculation such as the problem I was having
the answer can be lost in the forest so to speak.
It turned out that the method of using my fsend word had other
problems so I
decided not to pursue the answer. I feel quite stupid when I
describe the problem. I was sending two or three thousand
characters at one time to the MUP21. This seemed logical to me
because I am not used to using a terminal based
Forth. What was happening was that some of the word definitions
would get to the
MUP21 and since the inner interpreter was directed to get chars from
the RS232
the chip would try to compile them as soon as they got there. Some
of you cross
compile guys might think this is funny, but since I never used a
Forth wasn't
connected directly to the keyboard, I didn't see the problem. When I
finally noticed that later words which took longer to compile
were not getting finished, I just tried to add delays after each
word - up to 600 ms and still some words
would mess up. I finaly realized that if I was going to send all the
code as a file I would first have to
a. set a load buffer on the MUP21
b. clear it
c. define a word on the MUP21 to store to the buffer and make sure
it didnot
overrun - open 64k buffer - easy to setup in 1meg word range
this word also had to look for a sequence that marked the end of
the buffer
load and returned to terminal input mode
d. define a word on the MUP21 to compile the code from the buffer
e. define the needed words on the MUP21 from terminal mode
I could have typed them but I chose to just send a file with a
few simple
words with big delays while each word was compiled
So the sequence I went through was
a. load RS232 F-PC code to standard F-PC
b. load my code to change terminal word
c. go into terminal mode
d. run sync word on MUP21 to set to 9600 baud
e. send buffer store words to MUP21 using fsend with delays
f. start buffer store word on MUP21 from terminal
g. run fsend to send file to MUP21
h. send the compile from buffer word to the MUP21 while in
terminal mode
i. test words in terminal mode
since I used a marker word with the first file send to the
buffer
I could reload by repeating the above steps d-i
Although this method is not really interactive, I can still load
files one after another and do some incremental testing.
I wish to express my regrets that while I was figuring out that I could
not load a total file from terminal mode, I sent email to Jeff Fox
about this and other problems. I should have expressed my problems here
where many more people could seen
it and I would not have caused Jeff to take time away from testing
F21 chips.
I do want to say that once I figured out the terminal file load
problem -
4-5 days - I wrote the code to correct it in maybe 2-6 hours.
To wrap up.
The board took a good amount of time to get working by someone who
had done some
previous wire wrap work.
Dr. Ting was helpful to me when I wrote and called and even sent me
the E21 forth
software for free.
MY chip boots and works well when using P21 forth.
I think you should use P21Forth because of all the words - good
high level
grapic words
I would like to put a simple video game on my MUP21 board
a. write in high level using my file send words and Jeff's
graphic
b. rewrite in machine code to page size to get rid of jitter
( I may not get this done as I am now taking some schooling for
job advancement and I will switch to the F21 as soon as
possible )
>
> There is only one semiprofessional P21 product. I did that as
> a favor to Dr. Ting and the whole MISC project as well as
> my own understanding. I still people who want to play to get
> my P21Forth on a tested board with good documentation and demos
> and examples and hundreds of works or CODE and lots of neat stuff
> unless your definition of fun is the same as Dr. Ting's.
>
> Jeff Fox
I think P21 is a must for any serious MUP21 work.
Gary Lawrence
---------------------------------------------------------------
>
> Subject: robotics on f21
> Date: Thu, 4 Mar 1999 15:20:28 -0400 (EST)
> From: jfox@UltraTechnology.com (Jeff Fox)
> To: MISC
>
> Dear MISC readers,
>
> I have been thinking about the Rochester Forth conference
> that I attended after my first year at iTV.
>
> I well remember the robotics meeting at the conference. I
> often think of the plug and play robotic hot insertion
> open robotforth standard suggested. I loved the idea.
> It should be the machine forth model of course not
> the openboot tokenized or for God's sake no ANSI.
>
> I love the idea that you just pull off the head or arm
> or put a new on while things are running at it all
> talks to the other things and pass what they can do
> to other stuff when you snap them in, it reconfigures
> itself and starts using the new arm.
>
> Robotis and AI were the original real targets. I have
> not really promoted the chip until today. I have
> really explained that yes we will replace your 8051
> but on your chip you do minimul reconfiguration and
> the interface between your clunky CPU and your clumbsy
> I/O subsystems are running at tens of kilohertz.
>
> On my chips folks there are four programmable I/O subsystems
> that are somewhat reconfigurable processors where you
> have the ability to program circuits running at 10 gigahertz.
> Yes that is the speed on the inside of the A/D D/A
> ramps and even of the echo timer. It is right there
> in the specs but Chuck advised me not to try to
> explain it to people until I got working silicon.
>
> programable analog I/O from the two different analog I/O subsystems
> one for low res video up to VGA with genlock and the other
> for everything else from 800x600x24 or HDTV. 14 parallel
> I/O lines for general purpose use or network interconnect
> with infinite architectural variations and a programmable
> network/active message passing DMA and remote interrupt
> gigahertz I/O coprocessor and of course our CPU, and
> of course lots of stuff that no one understands yet.
>
> And of couse smp with nodes that can be snapped together
> like lego blocks but with power and I/O interconnect
> and I/O connectors on every block. I want a more powerful
> lego robot than the one on the market.
>
> People don't seem to make the jump from things like
> the functions implemented in the simple video coprocessor
> really make it a Chuck Moore clever windows accelerator.
> I don't just want my GUI 1000x smaller than yours that
> already makes it 1000x faster, I want another 1000x
> from my clever programmable windows accelerator. People
> have no idea.
>
> The match between executeable decision trees and our
> stack machines is perfect. The mapping of complex expert
> systems expressed in Enlish, sets of rules of fuzzy logic,
> and trainable neural nets to those executable decision
> trees using Forth is almost trivial. We have removed so
> many layers of fat that a comparison to what other
> people are doing has more than ten zeros.
>
> I want to test several crackpot ideas in AI that I think
> can give me about six more zeros concerning Robot smarts.
> With this stuff I honestly believe that this thing is
> so much smart than people realize that it is truely
> frightening. And almost nothing scares me. I used to
> say nothing.
>
> Jeff Fox
>
> ---------------------------------------------------------------
In the october papers - an internal Micro Soft document - it is stated
that
one of the ways Micro Soft will try to get rid of small developers is
to make
standards more complex. The one that they mention is making HTTP
standard much more
complex. I think that they will miss part of a growing market - what I
would call
the appliance market. A good F21 design could use the a/d channel as
an input to a
30 megaherz digital scope with display, numerous software modes and
output to
a pc using tcp/ip to serial or ethernet connector. This design could
be portable
and also used in a shop with a pc. Another design could do a portable
function generator. What I think Micro Soft is missing is a pattern
that showed up at the
turn of the century. When steam power and early large electric motors
were first
put into factories there was one large shaft that supplied all
equipment through
numerous belts. Later when motors became cheap, each unit had it's own
motor and
maintenance, installation, and retooling all became easier. With the
F21 it will
be possible to have appliance computers cheap enough to do scopes, web
browsers,
time managers, house controllers, security systems, sound and video
controllers and
many others all connected by cable or infared or rf networks. Right
now Micro Soft
products use a unreliable plug and play and a very complex registry -
people who can configure MS networks and computers are having to
take MSCE courses and are making more money than a typical
installer because of the complexity just like the
early electric motor days.
May the future be simpler!
Gary Lawrence
