I'm done being pissed off...it's time to ask questions.

[Greg Alexander <galexand@xxxxxxx>]

Typically I'd just read the book.  The book sucks.  So I'm not even going
to hesitate to ask questions.  I'm asking here first because I don't want
to ask the guy who made the book.  If I don't get satisfactory answers
here, I will try to ask Ting.  I'm going to ask a lot of questions that
are answered in the documentation because I do not trust the
documentation.  If, AND ONLY IF, you have used the plastic MuP21 and found
the documentation to be 100% accurate, I would like to know what part of
the documentation answers my question correctly.  I'm completely ignoring
all of the source code dumps at the end of the MuP21 programming manual
because I have no choice but to assume that they are outdated!  The MuP20
appendix (page 117), in particular, looks very useful, but I can't trust
anything in it!  Jeff and Chuck like to complain that nobody wants to read
anything they write.  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.
	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.  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 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."  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
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.
	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).

On with the questions:

Is P21Forth source available?
The Ultra Technology page says it is, but I found no link.

Where does the MuP21 start execution?  Address 0 (external address
AAAAA??)?

Where can I get a CORRECT and COMPREHENSIBLE timing diagram for the P21?
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
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.
Nowhere does it say when the MuP21 is expecting the RAM to have
stabilized its data outputs for a read cycle.  Nowhere does it say when
the MuP21's data outputs are stable for a write.
I assume 'ADR' represents A0-A9, but
then that would seem to imply that all of them are high for some time?
What about the 'WE' line?  What's it doing?  Why's it go high for 10ns in
the middle of its low part?  I assume it stays high all the time if
there's no write cycle going on? What do the ||||| portions really mean?
What about the || at the beginning and end of the ADR line?  What is this
'FRAM' line?  Fast SRAM?

What is an accurate memory map for the MuP21?

What are the restrictions from ripple carry on the + and +* instructions?
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, it would seem to be
more like if the + were the last inst in a word then we wouldn't need the
NOP?

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

What is the instruction encoding?  There is an outdated (MuP20) appendix
in the manual that says:
01010101012233232323
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.

This whole AAAAA thing....what is it about?  Where does it show up?  Just
things that go into teh ALU?  Do I need to XOR everything, just
addresses, what?  Can I accept the documentation for the MuP20 about this
as accurate?

There's some mention in the MuP20 part about DRAM and SRAM clocks being
configurable -- is this the case?  How can they be configured?  What do
the configuration diagrams on page 118 mean?  They seem to be counting
clocks -- what's a clock on the MuP21?  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.

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?  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)?  What speed SRAM do I
need?  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.

If my RAM interface ends up being too slow (presumably because of too much
slow glue logic), what happens?  It seems to me like the whole system
would stop working, right?

I see 20mA running, 1mA idle published a lot for the MuP21 -- are these
accurate?  How does the MuP21 idle?  It doesn't seem to have a HALT
instruction or interrupts.

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?  (I'm looking at a
simple LCD for my output, no use for NTSC)  This is implied, but never
actually said.

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?

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.

The 8-bit MuP21 assembler with 8-bit boot code makes almost no sense.  "A
different boot code will be provided when the production MuP21 is
available."  Where?  Since apparently the only functioning constant is 44,
why have a # word instead of just some "_44" word or similar?
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.


I have one request: burn all bad MuP21 documentation.  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.


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