Greg's questions

[Jeff Fox <Fox@xxxxxxxxxxxxxxxxxxx>]

Dear MISC readers:

Greg asked me in email if I could answer his questions to the list:

In order to do so I will also need to make a few corrections since
some of the questions are based on invalid assumptions.

> Jeff and Chuck like to complain that nobody wants to read
> anything they write.  

I don't recall that.  Can you give me a reference where I said that?
It won't prove what I "like" but it would prove that you didn't
just make it up.

> I want to, but I find that the only document
> produced by any of the trio (Jeff,Chuck,Ting) that has any import to me
> (MuP21 programming manual) is a piece of shit.

I know you have read only 10% of what I have written and 1% of
what Chuck has written.  But that would never stop you from making
statements about the stuff you have never read.

I will repeat the advice that I have been giving you for months.
There are about 30 documents on P21.  None of them are without
some kind of problem.  No single document will answer all the
questions that anyone will have.

(For months Greg complained that there was NO documentation 
available because he refused to go beyond the web and my site.
He constantly complained that UT did not provide free copies
of Offete documentation.  Many many people in this group
have explained to him that UT is not responsible for documenting
the Offete products and that if he is interested that Offete
has 30 documents.  After months he has finally bothered to
look at _one_ of those documents.  

Given that he has still refused to even consider that he is
still only looking at a tiny fraction of the total documentation
he still has many questions.  I also find it strange that after
all the advice he has been given to contact Offete for
information and help with Offete products that he prefers to
once again bring his complaints to MISC rather than to go
to the source.)

I am NOT responsible for providing documentation on P21.  Nor
am I responsible for supporting their products.  I have heard
countless complaints that I don't do a good job at it.  But
I do try to answer people's questions (when they don't get
too insulting in the process).  I also have lost count of
how many other people have explained this to you.

Mainly I have said that I don't want to provide help to anyone
who wants to come into this group and make the most insulting
remarks that they can about religion etc.  My advice is that
if you really want your questions answered don't lead into
them with the most insulting things you can think of.  But that's
just my advice, not a complaint.

>         Jeff, please don't complain, you've spent so much more time
> complaining than teaching me how to use the MuP21.  I think it is your
> tendency to complain so much about those who don't believe in simplicity
> that makes us look like a religion with dogma.  

This is an example of what I am talking about. I have tried to answer
your questions many times.  You complain that "no one helps you."
You have rejected almost all the help you have been given.  We have
all heard "that's worthless" "that's not what I want" etc.

> They're really not the
> problem -- ignore them, they're a minority on this list.  The people
> complaining about bad documentation, unreliable chips, that sort of
> thing...listen to them, don't assume that they are as stupid as 
> those who believe that one man couldn't possibly build a 
> microprocessor.

I never assume people are stupid.  I give everyone the same change
to expose their own mental abilities.  I often give people who 
appear to be stupid the benefit of the doubt, but at some point
I sometimes have to just accept it and move on.  I can't try to
answer questions from a three year old.  No matter how much you
explain they can always follow it with "WHY?" No answer will
suffice in that case.  You can't explain everything.

(Maybe the UT site needs a test to determine how much someone
does understand before we attempt to answer their questions.
Your answer must depend on their level of understanding after all.)

>         I don't think Ting was listening when Chuck said "If we make
> things easy to get into, machine language programming can be taught in the
> grade school."  

Ting was listening.  The idea is that you have to get them before 
they have become so brainwashed with complexity that they are unable
to grasp simple concepts.  Once they have been ruined it is very
hard to get into their closed minds.  Few survive the mind numbing
sameness of most of what they see.

> This is very hard to get into, and that is why there is no
> community support like Jeff wanted -- the community has such a hard time

There has been community support.  I was just suprised that so few
people were able to contribute.  The MISC mail list is a good example
It is couple of hundred people who for the most part want to 
contribute and have questions about the project.  (There are a few
who's idea of support is insulting people.)

> getting past the fact that they are (and always will be, unless they
> luckily get their questions answered) completely unaware of how to use
> this chip.

We created the MISC mail list so that people 200 people could have
their questions answered without having to answer every question
200 times.  Most our readers are happy to read the responses
that have been given when someone else asked the question before
they got there.  Some still must feel that they are more important
than everyone else and deserve to have their questions answered
personally again and again.  They could read how the questions
were already answered but their time is too precious for that.

>         I don't want to wind up with a system that works but not always or
> that works but I don't know why (i.e., where I'm afraid to change it).

I have had fun.  The other people who have experimented and provided
community support have said that they had fun too.  I like to see
people having fun and learning.

I feel sorry for people who don't get to have fun.  I think doing
stuff is fun and I am happy to see people doing it.  I feel sorry
for people who don't look like they are having fun, the ones
who just complain that they can't do anything, the ones who
may be frustrated that they can't have fun by providing community
support.   Maybe complaining that you can't do anything is more
fun for you than doing something but it sure doesn't sound
like it.  Your posts are full of cursing and complaints about
how terrible it is for you. People just feel sorry for you.

It is a fun party.  You are invited.  If it is more fun for
you to complain that the party is not for you then I hope
you find a party that you think is fun.  

No one says that you should prefer P21 to a TI chip.  The
people here who do don't need to argue with you about it.  If
you want to find your fun elsewhere then feel free.  We 
won't feel offended if you have more fun doing other
things.  

It really makes no differnce to me if you prefer TI chips
or Offete's chip for your projects.  But you seem upset that
Offete isn't TI and you wish it was.  Well that isn't going
to happen.  Insulting people won't make it happen.

If you prefer UTs chip, but because it isn't a big established
company where you can find many other companies writing code
for you, publishing documentation, how to books, for dummies
books etc. then it makes sense that you would prefer to
deal with TI.  (have you considered the basic stamp?  tons of
beginner level documentation.)

Even if you prefer the UT chip you might
prefer to deal with TI for the reasons that a big company
will provide you with a very well beaten path taken by
thousands or millions of others before you got there. You
will be less likely to get lost, and there will be
many fewer risks than if you head out into experimental
ground where there are few explorers and where you can
only get maps after they return from their exploration.
You will have to wait even longer if you can only get
your maps from web sites after someone has made free
copies of the information in wide circulation.

There is no need to make a value judgement here.  You are
free to prefer the beaten path, with lots of other people
providing you the documentation and tools you need to
get going.  Perhaps that is what you need for your projects,
your wants, your needs.  No shame in that.  Nor do we
feel shame for exploring where there is no path and
where we have to make our own maps.  Each to his own.

There are a few people who enjoy exploring uncharted
territory and making their own maps.  It isn't for everyone.
If you are expecting to see Offete look like TI then
you have unreasable expectations and are in for a big
disapointment.  If you want TI go to TI.  Nothing wrong
with that.

> On with the questions:
> 
> Is P21Forth source available?

Yes.  There is a long story involved which I have given before.
I will leave it out this time.  I have no problem providing
the source to interested parties.  But as I recall when I have
offered in the past you have always said that it would be
worthless to you.

Mostly because of the complexity of ANS Forth and the complexity
of metacompilation the metacompiler and source require more
documenation than P21Forth to be products.  They were free
at my site for years.  But these things generate many more
questions to the unexperienced than does P21Forth and I
didn't need to spend all my time giving people tutorials
on all those details.  So I made the source code a 
commercial product so that people wouldn't expect unlimited
free support.

> The Ultra Technology page says it is, but I found no link.

I know that if you can't find a link on the web you think that
something does not exist.  There is more than just the things
that have links on the WWW.  There is a world larger than the
WWW out there.
 
> Where does the MuP21 start execution?  Address 0 (external address
> AAAAA??)?

The CPU boots in the SLOW ROM address space.  The address is 
1AAAAA to the MISC chip.  The address will look like a physical
0 on the bus to a logic analyzer setup for an Intel machine.

> Where can I get a CORRECT and COMPREHENSIBLE timing diagram for the P21?

CORRECT is in the documentation.  COMPREHENSIBLE is in your mind.  If
one doesn't comprehend the information there then one can always ask
questions.  There are many people who could answer specific
questions but you have to ask.  Insulting people before you ask
them questions will usually not get you the answers to make things
more comprehensible to you.  Instead you may assume that no one
will help you after they give up.
  
> I've seen enough data sheets by people who don't give a fuck if I
> understand their documentation that were still more clear than the book's
> diagram (page 5).  I want to know timing for fast/slow sram&i/o accesses,
> and for DRAM accesses.  I don't mind ASCII art.  I mind the signals being
> undescribed.  The way this diagram is drawn it looks like there are 76
> nanoseconds wasted at the beginning of every DRAM memory cycle, 68
> 68 nanoseconds while RAS is low but CAS is not, then 33 nanoseconds while
> CAS and RAS are both low (is this supposed to be refresh??), then
> 30 nanoseconds of just RAS low while the 'ADR' is doing something,
> then 4ns??? of CAS and RAS low.

I guess you did have trouble reading it.  Do you know the basic
functionality of the DRAM?  Can you read the timing signals from
the DRAM specs?  Have you considered that it might be more
comprehensible to you than the short form that Ting used.  The
DRAM timing on P21 is the same as in the DRAM timing that the
DRAM use and that is in the DRAM timing diagrams.  Maybe
you would be able to read those more easily.

> Nowhere does it say when the MuP21 is expecting the RAM to have
> stabilized its data outputs for a read cycle.  

But you were able to infer it since it is an obvious
requirement.  The documentation on the memory interface to P21
is not meant to be a memory chip tutorial.  If you understand
how the memory chip interface needs to work, to match the
memory chips, then you can infer a redundancy in the documentation
since the same timing is required on the memory chips as P21.
If you need a tutorial on the timing of the DRAM chips then
you can look for it from the manufactures or you can complain
that the documentation you have doesn't include hardware tutorials
about the memory chips.  I know people didn't provide you the
online documentation that you need to get started.

> Nowhere does it say when
> the MuP21's data outputs are stable for a write.

I don't need to argue about these sorts of details.  I would
think that it would say this in at least one place. But as I 
say the Offete documentation is meant for people who have
some experience with hardware not for people who want a tutorial
about every detail.  

If you need a tutorial that explains that the data bus must
be stable and valid before you read it then I can see why you
can't make it through Offete docs. They are not meant as
tutorials for people with no hardware experience.

> I assume 'ADR' represents A0-A9, but

I would assume that ADR means address.  It could refer to different
sets of pins depending on the address space in question.  DRAM, ROM,
SRAM, and register address spaces have different meanings for the
specific bits doing the addressing.

> then that would seem to imply that all of them are high for some time?
> What about the 'WE' line?  What's it doing?  

WE stands for _write_enable.  It is on a chip to that it can tell
the memory chips that it wants to do a write rather than read.
That is what it is "doing."  It goes low to tell the
memory chips that a write is being performed.  This is not anything
special for P21, just very basic stuff about memory hardware.

> Why's it go high for 10ns in the middle of its low part?  

In the middle of the low part of what?  I don't understand your
question.  I suspect that you are missreading the timing diagram.
As I have said perhaps looking at the timing diagras for the
recommended DRAM and SRAM chips in the form you are familiar
with would make it clearer to you.

> I assume it stays high all the time if
> there's no write cycle going on? What do the ||||| portions really mean?

I don't understand the question without some context.  Try comparing
it to the timing diagram for the memory chips and see if that helps.
Or provide more context in your question so that it will be
answerable.

> What about the || at the beginning and end of the ADR line?  What is this
> 'FRAM' line?  Fast SRAM?

Without a reference to what timing diagram you are looking at I
have no context to understand your question.  If you want to 
give it context of an actual diagram I might be able to answer.
 
> What is an accurate memory map for the MuP21?

As I recall 0-FFFFF DRAM, 100000-1003FF SRAM, 140000-1403FF SRAM,
180000-1BFFFF ROM, 1C0000-1FFFFF ROM, 16..... registers.
Now because Ting used the SRAM space for I/O in some documentation
this is called I/O.  Likewise Ting calls the ROM space RAM space.
It is pretty straightforward.  If I got any addresses wrong
(from my own memory) someone can correct them.   This is pretty
much ancient history.  
 
> What are the restrictions from ripple carry on the + and +* instructions?

carry moves 5 to 8 bits per instruction time (10ns) on P21.  Thus
no NOP is required for additions where carry will never move
accross more than 8 bits.   If you are dealing with bytes or
if you know one or more of the numbers you may be able to use
no NOPs.  Chuck does this quite a bit in OKAD to make things
a little faster.  It is one of the design trade offs.

If carry needs to move through 21 bits then NOPs or a slow
memory operation is needed before you read the results of
the addition to have valid results.  The simplest thing
to do is to always put the add in slot 0.  This means that
it follows the instruction load and has time to get valid
results regardless of data.

> Jeff's P21Forth manual says that if the + is the first inst in a word then
> we don't need a NOP, but that doesn't make sense, 

Oh, but it does.  You are obviously thinking of some other 
architecture and making assumptions that this chip works the same
way.  I have explained this before, but once again, the way
the chip works is that all possible instructions execute on
each clock cycle and that the instruction decode selects the
results of the operations rather than preparing the setup
to start the execution of the proper instruction as with
other architectures that require extra cycles and pipelines
to compensate for this.  The zero operand architecture 
accounts for part of this, but also Chuck has made an
unusual design trade off using parallelism at the instruction
level to get instructions to execute while they are being
docoded. (it only saves a 1/10 of ns but every little bit helps.)

> it would seem to be
> more like if the + were the last inst in a word then we wouldn't need the
> NOP?

This is the way it would work on other architectures where things
are happening in a different order.  On P21 and F21 you need the NOPs
before the addition if you need them.  They are of no use after
the addition had completed.  This is not a documentation error.

> What is this mysterious A! problem I've heard about with regards to
> plastic MuP21?  It's mentioned, but nowhere documented.

I know I am not suppose to complain, but I do not like constantly
reading "there is NO documentation" "its not documented anywhere"
etc.  I believe it is documented in several places.  I wish
people who have only looked at a tiny fraction of the documentation
would not make these sorts of missinformed attacks.

The first 8 MuP21 chips were prototyed in ceramic packages.
The production P21 was done in plastic.  The plastic package
intoduced a problem that was not present on the ceramic
packages possibly due to increased inductance on the lead
wires.  The bottom line was that A! became marginal.

Not all instructions take the same amount of current.  Some
required more power than others.  A! is one of those.  With
the introduction of the plastic package some code that had
worked on ceramic packages broke.  It turned out that the
cause was A! failing.  It worked better in some slots than
in others.  The conservative fix was to preceed A! with a
NOP. It might or might not be needed in each case but it
provided a simple work around for the package introduced
problem.  I understand that the problem is not present
on the plcc package. (shorter lead wires)
 
> What is the instruction encoding?  There is an outdated (MuP20) appendix
> in the manual that says:
> 01010101012233232323

That is it.  That is how the 00000 11111 22222 33333 slots look.
In the P21 simulator it just uses 0000011111122222233333 and
I call this "conceptual" mode.  The actual hardware on P21 uses
01010101012233232323 in hardware.  The interleaving of opcode
bits into the word was done for hardware reasons.  The result
however of 01010101012323232323 would be that only four bits
of opcode 3 would be visible in the bottom 8 bits (ROM space).
That wouldn't work.  So two bits were swapped to get 2233 so
that all 5 bits of the opcode in slot 3 would be visible in
the 8 bit address space and so things would boot.

(F21 uses 00000 _1_1_1_1_1 22222 33333 as I recall. That is
in order but slot 1 inverted.  This sort of detail is only
important to compiler writers and is simple to them.  Most
programmers don't need to deal with this level of detail.)

> It seems correct if the P21Forth assembler documentation source is to
> be considered definitive...except that it seems that every instruction is
> inverted: i.e., @A+ is supposed to be 09, but the code seems to really be
> for the instruction 16.  ???  The 20-bit assembler in the MuP21 manual
> uses even different numbers.

Oh boy.  Back to the simple AAAAA concept that is visible in cross
system development.  It really is so simple.  Anyone who has spent
more than a few minutes thinking about it is wasting their time.
Anyone who has brought it up for discussion again is wasting a
lot of people's time.  (enough complaints)

What is the bottom line of this AAAAA thing?  It is the same as
with any other chip.  I once ported an embedded app from a Moto
chip to an Intel chip.  In the process I had to replace all
the opcodes that defined the program for the Moto chip with
opcodes that defined the program for the Intel chip.  

I also had to exclusive OR all the data in the program with FF.
I had to this because one bus used positive logic (+5V = true)
and the other bus used negative logic (0V = true).  It is 
a very simple idea conceptually.  Now picture a third bus
that has half the bits postive logic and half the bits 
negative logic.  to port the data to that chip one would
have to exclusive or all data with 55 or AA.

Now if I look at those two ROMs I see that data representing
an 8 will appear as a 8 exclusive ored with FF in one of
the ROMs.  But in fact 8 is represented in both cases.

So now picture a P21 assembler running on P21 and a P21
cross assembler running on an Intel chip.  What is the difference?
They both must generate the same opcodes.  But they must
represent the opcodes differently.  About the only difference
between the original version done by Chuck Moore in FPC for
P21 and the same thing in P21Forth is that all the opcodes 
must be exclusive ored with AAAAA when making the jump from
one bus to the other.  It is as simple as that.  

As I say this sort of thing only effects people who write
cross development enviroments and I assume that anyone who
is qualified to do such things will be able to deal with
basic concepts involved.

> This whole AAAAA thing....what is it about?  

Hardware.  It only effects people who want to deal at the
low level hardware and cross development issues.  This is 
about 1 in 100 users and those users understand simple
hardware related issues.  It has confused the heck out
of people who heard hardware and software issues discussed
in the same paragraph ten years ago.  I understood it 
quite well at the time and Chuck even made me feel 
confused when he first talked about it.  I told him not
to talk about it after that.

>Where does it show up?  

Writing an I/O driver for the PPort, or writing cross development
tools.  It also constantly shows up in discussions, much more
often than it deserves to show up.

> Just
> things that go into teh ALU?  Do I need to XOR everything, just
> addresses, what?  

On p21 you don't need to XOR anything except data passing
through the PPort.  The pport is inverted also so you must
xor data with 55555 there.

If you are doing cross development then it depends on what
you do.  If you start with opcodes as seen from Intel and
you want to use them in P21 you must xor them.  If you start
with P21 opcodes on P21 you don't need to xor them.  If you
xor them twice you are back where you started.  That confuses
people.  

If you are writing on an Intel you will need to xor the
addresses you generate with AAAAA and scramble a memory
image so that it will appear sequential when ported to a
P21.  You will also need to xor all data with AAAAA.
Data and Addresses need to adjusted, just like on any
other cross development project, when working with
two machines that don't use the same representation on
the bus.

> Can I accept the documentation for the MuP20 about this
> as accurate?

I don't know which documentation you are refering to.  I
would say accept the above as accurate.
 
> There's some mention in the MuP20 part about DRAM and SRAM clocks being
> configurable -- is this the case?  

Was it talking about hardware design?  Programming?  What page?  What
does it say?  F21 got registers that the user could set to change
memory timing.  This was not the case on P21.  

We did have one user who kept asking about the circuit that 
automatically changed the timing on the memory circuits on the
fly.  He kept saying that this circuit was bad because if he
"blew" on his chip it would "jump."  He insisted that the
technology was doomed because this circuit was bad.

People kept telling him that this circuit didn't exist and asking
him what he was talking about.  No one could ever figure it out.

Perhaps you found the same documenation that confused him.  What
where is this mentioned in the documentation that you have and
what does it say?  I am currious.

> How can they be configured?  What do
> the configuration diagrams on page 118 mean?  

There are a number of versions of the P21 programming manual.
the page numbers are not all the same.  Without context I 
don't know what diagram you refer to.  There are two bits
in a configuration register that control the upper two bits 
sent out to ROM (select one of 4 pages in the ROM address window)
This might be what you are refering to.  I don't know.

> They seem to be counting
> clocks -- what's a clock on the MuP21?  

The CPU clocks instructions at 10ns each.  The video clocks
instructions from an external clock.   There are also hardware
timers (clocks) running inside of the chip that provide 
things like memory timing. I have no idea which clocks you
are refering to.  Generally we call these unclocked chips
because the CPU is asynchronous, not synchronized to an
external clock.

> In particular, if I can get the
> access times slow enough then I can get very cheap very very low power
> 70ns (or slower) SRAMs, but if I need to use 15ns SRAMs then I have to
> buy cache modules intended for PCs that take up to 160mA just idling.

The SLOW SRAM and ROM spaces provide 250 ns access. The fast
SRAM and ROM spaces provide 35-40ns access.  The P21 has a long
setup time so 15 or 20ns SRAM will get about 40ns timing
from P21.  F21 reduced the setup time from 25ns to 6 or 7ns to
reduce total SRAM timing to 18ns on 12ns SRAMS.  Also F21
can vary the timing to DRAM and SRAM with the use of five
bits in a control register.

> I already asked Ting this, but I just got a "yeah, it should work" without
> addressing any of my other questions: If I use SRAM instead of DRAM and
> have the address bits of the SRAM fed by two latches, one which has a
> latch enable on RAS and one which has a latch enable on CAS, will this
> work?  

It will work in that you can get SRAM chips to function in the
DRAM address space.  The real issue is however you will still
get DRAM timing.  The SRAM will work at those timing but it
seems like a waste to add 100ns timing for off page access
to chips that don't need the same timing as DRAM.  "yeah, it
should work" (sort of)

> Will I need to do something clever to make sure that refresh
> signals don't latch new addresses in the latch (such as AND the latch
> enables with the output of a XOR from CAS and RAS)?  

I don't know.  I don't think so, but I don't know what your
design would look like.   I know you "can" hang SRAM on the
DRAM bus if you really want to.

> What speed SRAM do I
> need?  

the speed of the memory of the memory interface you are using
to access them.  You can access a fast chip though the 250ns
space or the 40ns access space.  I you access a slow chip
(250ns say) via the fast memory space you are reading it
in 40ns and you would not get a valid result from a chip
slower than about 15ns.)

> Will the propagation delay (up to 23ns?) of the 74hc574 latch get
> in the way?  I could figure this out on my own if the timing diagrams were
> worth anything.

It might.  Ting's first board used a parallel port chip.  The
thing was a mess.  I repaced it with 3 CMOS chips to decode
input and output ports.  Ting's second board used a similar
but different 3 CMOS chips to latch I/O.  If you used ACT
versions of the chips you could access it in the high
speed address space, otherwise the chips would be too slow.

> If my RAM interface ends up being too slow (presumably because of too much
> slow glue logic), what happens? 

Nothing would work. You would get invalid results when trying to
read memory.

Another issue that is of equal importance in loading.  P21 was
designed to provide power to drive a set of memory chips and
some chips to decode I/O on the bus.  If you load the bus with
too many chips then you may have problems providing sufficient
drive.  The signals will become weak or slow.  It is a hardware
issue, not the sort of thing programmers deal with.  Hardware
types will be as concerned about bus loading as timing when
they design systems.

> It seems to me like the whole system
> would stop working, right?

Yeah.  Or if it is marginal it might be intermediate.  Intermediate
errors can be terrible to isoluate and debug. 
 
> I see 20mA running, 1mA idle published a lot for the MuP21 -- are these
> accurate?  

These things are very hard to measure.  Power will move in and
out of chips on data and address pins if you try to isolate the
power of each chip on board.  It makes it very hard to measure
exactly how much power is being consumed by each chip.

If you remove the memory chips to get just the P21 power it 
doesn't run.  The most power is drawn by the video output
coprocessor.  Generating a white screen takes more power
than generating a black screen.  The biggest transitors
on the chip are in video generator.  I know with F21 that
turning on video basically doubles power consumption,
however most of that is memories not the CPU.

The CPU power consumption is so low as to be almost
negligable and very difficult to measure.  I know that
most of the power is going to the memory chips so when
the whole board is drawing 5ma with 7 chips it is a good
guess that CPU isn't using much.  Voltage and what the
CPU is doing are the biggest factors for power use.
Generating off page signals makes the DRAMS draw much
more power than if they are mostly running on page.


> How does the MuP21 idle?  
 
NOPs

> It doesn't seem to have a HALT instruction or interrupts.

No.  No HALT.  No interrupts. This is one of the major
diffences between F21 and P21. F21 has three interupts
and P21 has none.
 
> If I run the thing completely without any sort of clock input at all, will
> that work so long as I don't use the video coprocessor?  

Yes, expept that the video coprocessor also includes a refresh
instruction in its instruction set.  If you are using DRAM that
require refresh you would have to do it in software if you
disable the hardware refresh.  For SRAM and ROM however there
is no problem in running without refresh.  There are also
self refreshing DRAM.

> (I'm looking at a
> simple LCD for my output, no use for NTSC)  This is implied, but never
> actually said.

I know Dr. Ting has shown examples of P21 running without refresh,
without Video, without DRAM, etc.  The minimal system is a P21
and a ROM (rather short on I/O however)
 
> The data stack is 6 words deep and does work all the way on the production
> plastic MuP21s, right?  I can ignore the notes saying that the bottom 2
> words are broken?

Sounds like a description of one or more of the 8 prototype chips
not the production chips.
 
> I'm sure there are other things I'll need to know to build this thing, but
> those are the things that have been frustrating me today.
> 
> Keep in mind that if I were rich, I would buy a logic analyzer, and I
> would figure this all out that way.  But I'm not -- even the cost of a
> single fried MuP21 would put a significant dent in my monthly budget.

I never fried a P21.  I was sure I had several times.  I remember
hooking up a 6V nicad directly to a P21 board and getting the polarity
wrong. With the low internal resistance of nicad bad things can
happen.  They can make things explode rather violently.  Instead
the chips on the board just heated up to about 300 degrees f.
Everything survived!  Rather resilant stuff I must say!

> The 8-bit MuP21 assembler with 8-bit boot code makes almost no sense.

I think it makes a lot of sense.  If it makes "no sense" to you then
I think you missed something.

1. without an 8 bit boot space you would need 20 bits with of
ROM to boot.  You would need two or three times as many ROM
chips, that means more power, more expense, more bus loading
etc.  With an 8 bit boot space you can use a single 8 bit
ROM, RAM, or FLASH.  It makes things simple and cheap, that
was the idea and the reason it makes sense.

2. with an 8 bit boot space you need an 8 bit assembler.  It just
makes sense.

> "A
> different boot code will be provided when the production MuP21 is
> available."  Where?  

There are a half dozen different versions of the boot code that
has been released since P21.  See Offete and UT products.  You can
even find one online. ;-)

> Since apparently the only functioning constant is 44,

??? the only functioning constant is 44?  What are you talking
about?  Maybe you are talking about a literal opcode rather than
a constant.  All constants function on P21....

> why have a # word instead of just some "_44" word or similar?

Ting called it Load_immediate in his Intel like list of names for
the instructions.

It is known in classic Forth as LIT.  Chuck also used the opcode
n for this one for a long time.

I really don't think _44 is a better name than LIT, #, or N.  How
does _44 convey more meaning about the instruction to the programmer?
Are you suggesting that we should not use symbolic names, Forth,
or even assembler and just work in a binary hex dump?

> I suspect the rest of my questions would be answered if a new version were
> come up with because they mostly have to deal with unnecessary
> duplication.  Also, why does !0 bother to generate a 1 and bang it?  that
> seems pretty useless.

If you want an explanation of why Ting wrote his code the way
he wrote it I think you will have to ask him.  He has been focused
on serial I/O to support the embedded eForth model.  I think that
is why one of the first things he did was serial I/O via bit
bang on his projects. It might be useless to you.  I found it
pretty useless.  Dr. Ting insisted on a serial I/O routine
in P21Forth even though everything worked so much better
with the parallel I/O routines.

Of the dozens of questions you have asked I have given thoughful
and detailed answers to all of them that I could understand.  I
also had to correct a lot of wrong assumptions that you mixed
in with your questions.  I think this should show to anyone that
people have been tring to answer your questions even if they
have been asked and answered many times before.  Most people
do ask their questions more politely, without the profanity
and insults.

> I have one request: burn all bad MuP21 documentation.  

But you said that all P21 documentation is bad.  Burn it all I guess.
Why stop there?  If you are into book burning I can think of
lots of other books that you might want to burn.  Any book that
makes people wonder about whether anything is right or wrong
needs to be burned I guess.  

> I don't care if
> this means we have none left, at least we won't be wondering what is right
> and what is wrong.

Burn the books! Problem solved! We won't ever have to think
about it again and wonder if we are right or wrong.  Your in
good company with your book burning idea.  Back to the dark
ages! ;-)

> If I had bought a motorola or TI microcontroller, I would already be
> coding.

What a shame.  I am sure that if you had been able to code then
your code could have transformed Offete and UT into copies of
Motorola and TI.  If those two companies would just focus
entirely on your needs then they would no doubt take over the
Motorala and TI markets tomorrow. ;-)

Jeff Fox