Re: Greg's questions
- To: MISC
- Subject: Re: Greg's questions
- From: Greg Alexander <galexand@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 02 Jul 2000 21:43:37 -0500
- Sender: galexand@xxxxxxxxxxxxxxxxxxxxxxxx
>In order to do so I will also need to make a few corrections since
>some of the questions are based on invalid assumptions.
That is appreciated.
>> 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.
Example of you complaining:
As I have said. There is a crowd in c.l.f who are proud of not
knowing anything about it. They proudly announce that they will
ignore any examples or explanations posted because they don't
want to know about it.
(from private email, but I've seen you express this sentiment often enough
that I hope it's okay to post it to the list). Now it's definitely
possible that this was not really complaining and that you are perfectly
happy with these people not respecting your ideas, perhaps based off of an
incorrect assumption that they are universally stupid. I like such
assumptions, they are convenient, but damn are they limiting!
Example of Chuck complaining (page 103 first?? second?? third?? edition of
MuP21 programming manual)
The Establishment
I've got to pass on to you my latest encounter with the
establishment. It is disturbing and it is illuminating. I told
you before that I was writing a paper for HOPL 2, the Second
Conference on the History of Programming Languages. I got a
letter a month ago saying that they regretted that they could not
accept my paper. I wrote in my own style what had occured in
those early days. It was not in the academic style they expected.
<...>
Chuck clearly is not happy with his rejection by 'the
establishment', so I don't know how this could be portrayed as
anything but complaining. Note that I avoided the connotationally
loaded word "whining."
>> 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.
It seems stupid to complain and insult that people have not read
what you have published when you do not make these things readily
available to us. I've read what you've put on your website and I
am thankful for it. I've even payed for the P21 programming
manual, something I consider wasted money. I can't afford to pay
for 30 issues of More on Forth Engines or for a lot of Forth
Dimension back issues or whatever else you may suggest.
>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.
On May 14th I started complaining, and I was well done complaining
by June 12th, which is when I ordered my MuP21+manual. I only two
days ago resumed complaining, at least on the list, and only a
week before that began complaining to you. You did not tell me to
look at other things, though you suggested that some issues of
More on Forth engines would be useful. It is prohibitively
expensive to buy all of More on Forth Engines. Are you mad at me
because I'm too poor to buy what you want me to, or because you
think I wouldn't read them even if I could afford them?
>(For months Greg complained that there was NO documentation
For less than a month.
>available because he refused to go beyond the web and my site.
No, because I lacked the money. When I got the money I bought the
documentation that was suggested, the MuP21 programming manual.
Even if it had been suggested that I buy all of More on Forth
Engines, I certainly do not have the money for that for at least
another month, and that's only if I decide not to buy anything
else, like food.
>He constantly complained that UT did not provide free copies
>of Offete documentation. Many many people in this group
No, I said that because free copies of Offete documentation are
not available, UT looks bad. If ANYONE published free copies of
P21 documentation then UT and Offete would BOTH gain tremendously
in public opinion. I didn't say that UT was RESPONSIBLE, I said
that if UT didn't do it and nobody else did it, UT would certainly
lose out in the long run. Hobbyists are just hobbyists, but some
of them will someday (perhaps tomorrow or yesterday) go on to make
big purchasing decisions.
>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.
Okay, let's play fair. After so many years you have only NOW
bothered to produce the F21d. What took you so damn long? OH
WAIT MAYBE YOU'RE NOT MADE OF MONEY EITHER. It's a matter of
scale -- right now I have just barely enough money to buy P21
stuff one tiny item at a time. Right now you have just barely
enough money to prototype F21, one prototype run at a time, with
years between them. Someday I will probably have just barely
enough money to prototype chips too, but right now I have barely
enough money to buy them. You're complaining that nobody reads
your stuff, and you're also complaining that you are broke because
of supporting F21 development, and you make fun of us for
complaining that we do not have the money to buy Ting's horrible
documentation?
>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
I'm looking at the maximum of the documentation available to me.
The availability is limited, among other things, by:
* my financial situation
* Ting's disinterest in the english market
* your reluctance to give straight answers
>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.)
Ting has demonstrated that failing in the english-speaking market
is of no concern to him. You seem to care a little bit more about
the success of your company in english speaking areas. The P21 is
vitally important to the success of MISC, hence F21, hence UT.
>> 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."
No you haven't, I only started asking them on May 14th. I think
you think I'm somebody else. The questions I've gotten answered
from you until this message is just contact info for Ting.
>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.
If it's worthless then it's not help. If it's not what I want,
it's not help. These are valid complaints. At any rate, I
haven't even said that. Nobody that you have not flamed here or
on c.l.f has told me until after I had gotten the MuP21 programming
manual that this book is not a definitive P21 reference and that I
would neet to buy the entire MFE set to understand anything.
>> 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
Yes you do.
>to expose their own mental abilities. I often give people who
No you don't.
>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
No, I've never seen you do that. I'm not some idiot who just
jumped on the list. I've seen how you act, there's no point lying
and pretending that you use the MISC list for answering questions.
You use it for proselytizing. Proselytizing is what you do,
there's no doubt about that, and that word has STRONG religious
connotations, and that's why people see you as an attempted cult
leader. I've been forcefully excommunicated merely beacuse I'm
too stupid to understand shitty documentation. That's why we look
like a cult, because one minute we're defending you and then we
say the slightest negative thing and you're suddenly flaming us
like no tomorrow. I don't think you've got the ability or effort
or whatever to remember who the fuck I am or how I've acted, but
you assume I"ve been attacking you for years when the closest I
came began on May 14th of this year. Nevermind that on May 14th I
wasn't even complaining, I was just asking questions, trying to
find out what I needed to get...you started attacking me, after
I'd been a verbal supporter for several years. Why the hell do
you think I got mad?
>> 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.
I'm not too complicated to grasp a timing diagram. The timing
diagram is too shitty to be read. Don't try to blame the
shittiness of my understanding of the P21's timing on me.
I again point out that in this conversation you have spent
literally thousands of lines telling me how bad a P21 user I am,
and this message has a very small technical issue to offense
ratio. I included very little offense at the beginning of my
questions compared to questions, at least compared to you.
>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.)
Like you.
>> 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.
Oh, that sure does explain why there's a searchable mailing list
archive. OH WAIT THERE ISN'T.
>It is a fun party. You are invited. If it is more fun for
No I'm not, because I don't have enough money to join the "in
group" that has a bookshelf full of badly written incorrect and
contradicting Ting documents.
>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.
No, you don't understand at all. I am upset because I want to
find my fun in P21 chips, but you and Ting have erected
unnecessary barriers to its use. Ting did so because he doesn't
care about the American market. You have done so because you are
very hostile.
>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.)
I'm not asking for how to books, I'm asking for simple, accurate,
and complete 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
The P21 path has been well beaten but I have to pay hundreds
of dollars to get the record of the path, by your accounting.
>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.
Wide circulation? Bullshit!
>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.
That's your inevitable response to anyone who comes up with a
severe problem that is likely to impact UT, eh? "Go elsewhere,
use somebody else's chip." You'll note nobody with the big bucks
is using your chip and almost nobody without it is either. If you
had a million-count contract up your sleeve, why aren't you
developing new prototypes today?
>> 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.
Sorry, I was confused by the fact that the webpage said that it
was freely available, and the website also says that it is not
freely available. Now that I know it is not freely available, I
know that it is not freely available and I thank you very much for
providing me with an authoritative answer to this question.
>> 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.
By available I meant for free. I apologize for being unclear.
Thanks for taking every opportunity to be hostile.
>> 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.
Obviously I was a FUCKING RETARD for not knowing this. I should
obviously have figured that out from the PRIMARY REFERENCE on the
P21 WHICH says so QUITE CLEARLY on PAGE N/A. I OBVIOUSLY deserved
to be PUT IN MY PLACE for not knowing this information, since it
was made so WIDELY AVAILABLE and published CONSISTENTLY and in
many different places!
So as I see it that's address 100000, which is at the beginning of
what the P21 'datasheet' memory map says is 'slow sram (250ns)'
Does this imply that the entire P21 datasheet memory map is
correct? (it is not the same as the one in the book)
I have here:
000000-0FFFFF DRAM (80ns)
100000-13FFFF 250ns SRAM (8-bit)
140000-17FFFF 50ns SRAM (8-bit) ***
180000-1803FF 250ns IO (20-bit)
1C0000-1C03FF 50ns IO (20-bit) ***
***: is it really 50ns? some documentation says 15ns, and some
documentation says it's configurable.
If anyone can just say yea or nay on that memory map, I would
really appreciate it.
>> Where can I get a CORRECT and COMPREHENSIBLE timing diagram for the P21?
>
>CORRECT is in the documentation. COMPREHENSIBLE is in your mind. If
Don't bother lying to me. I know this documentation isn't
correct.
>> 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.
I know some things about basic functionality of DRAM. I don't
want to know how DRAM works and then make something that emulates
DRAM. Your postings from Chuck frown on this -- if X can talk
to things that conform to standard Y, the best way to use X is
not necessarily the best way to implement standard Y. I want to
know the P21 timing. This documentation assures me that the P21s
timings are compatable with 80ns DRAM but I want to actually know
how long P21 is going to assert these signals and hold them stable
and when it expects my signals to be held steady, etc. I want to
know what's really going on, not just one setup that could
potentially work.
Here, i'll reproduce the P21 manual statements so we can disect
them.
MuP21 output
RAS |--------------|
-| 76 |---------------------------------
CAS ----------------|------------| 33 |------| |-
68 |-----| |-----|
ADR || 15|---------------|||||||------||
||--------------|--| |||||||4 ||
WE ----------------|--------| 52 |--| |-
49 |---------|10|---------|
Refresh
CAS ------------| 20 |-
|---|------------------|
This looks kind of similar to what is specified as 'FPM early write
cycle' in the datasheet I found for 80ns FPM DRAMs (256kx4, on an
"obsolete product" page from Micron). The problem is taht the ADR
line doesn't make much sense here. Where the ADR line is shown as
being low, column address should be on those lines? And where it
is shows as high, row address is valid? Is ADR some internal
signal that selects whether row or address is output?
At any rate, it now looks like I'd need 20ns SRAMs from
the DRAM datasheet. It seems like the P21 could potentially work
with as much as 50ns SRAMs, but I'll never be able to tell from this
document. When I emailed Ting I asked him if this would work with a
latch triggered by CAS and a latch triggered by RAS and asked if the
propagation delay and he just said that it would work and that
SRAMs were much faster than DRAMs so timing would not matter.
Well there are many speed grades of SRAMs, and it turns out that
DRAM /CAS -> data valid time is fast, even for SRAMs! I certainly
could not latch both. In hindsight it would be stupid to bother
latching CAS, I could latch only RAS and have CAS be fed straight
to the chip, then I need only 20ns SRAMs and I don't need to worry
about the speed of the latch (its propagation delay must be less
than about 60ns, I guess, which is easy). Unfortunately, it
seems like 20ns SRAMs are prohibitively expensive in terms of
power usage, though it's very likely that I haven't been very
effective in my SRAM search.
An 80ns DRAM is equivalent to a 20ns SRAM for on-page
accesses, it seems. So Ting's advice was pretty useless.
So here I'm faced with the fact that I asked Ting a
question, and he answered it incorrectly. "timing will not be a
problem" my ass. Ting doesn't seem to care at all about his
American market, so he is giving the entire MISC consortium a
black eye. You have little concern for filling his gaps and have
demonstrated little interest in actually sharing Chuck's
implementations, rather just his ideas.
>> 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.
No, I know some of it, but not all of it. I know that this brand
of DRAM is guaranteed to have the data valid within 20ns of CAS,
but I STILL DON'T KNOW WHEN THE P21 EXPECTS DATA TO BE VALID!
The P21 has a memory interface on it. It's not /just/ a DRAM memory
interface. It happens to be designed so that it can talk to DRAM,
but it is a lot more generic than that.
>> 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.
It doesn't. Even experienced hardware hackers have stumbled over
these problems. Stop playing deaf. Nobody else had problems
because they wanted to use DRAM in the DRAM access area. Maybe
this seems intuitively obvious to you. I suspect Chuck would
disagree and say that ignoring its purpose and instead using
whatever is best for your project is better. Maybe I should ask
him. Anyone have contact information? I can be respectful to
Chuck: He has not sold me low quality products like Ting or been
very rude like Jeff.
>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 don't need to know that it must be stable, I know these things.
I need to know WHEN it must be stable!!!! That is why timing
diagrams are published!
>> 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.
It was talking about DRAM, and it wasn't really representing what
would be on the address lines at that time. It was showing high
and low when what it seemed to mean was column address and row
address.
>> 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.
I'm not stupid. I know what the /WE line does. I wanted to know
why it went high for 10ns in the middle of the part where it was
low. I now know why, it's because the illustration is for two
same-page accesses, rather than one, and the /WE line goes high while
the second column address is being loaded. In hindsight this is
kind of obvious, but the picture was presenting a specific type of
memory access as if it explained the entire memory system. I
guess it does give enough information IF YOU ARE USING DRAMs.
>> 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.
It turns out I was reading it correctly. Thanks for taking
another opportunity to be hostile. I just didn't know that it
represented two cycles.
>> 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.
I gave you context. Page 5, MuP21 programming manual. The DRAM
chip documentation helped some, thanks. It didn't give me the
information I was specifically looking for, which is how long
after CAS MUST the data be valid? The DRAM will give it in 20ns,
but I still have no idea what the P21 actually depends on. At
this point my hopes aren't high that it will be a long enough time
to make a significant price difference, but you never know until
you know!
>> 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.
PAGE 5 OF THE MUP21 PROGRAMMING MANUAL.
If there are different versions, this is the one sold as "second
edition" with "third edition" written on the outside front cover
and "first edition" written on the inside front cover.
>> 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.
That memory map you just gave me would put the boot code in the
middle of 20-bit memory, yet everything else I've read puts it in
8-bit memory.
>> 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.
Okay, time to GET valid results, but what about time to PRODUCE
valid results? Like if I have + in slot 0, adding 1 to 1FFFFF
(21-bit negative one), can I use C=0 in slot 1 and get the correct
result? What about if I have 2* in slot 1?
>> 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
No I'm not.
>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.)
Are you talking about clocks as in each instruction gets one
clock, or each word gets one clock? My original interpretation of
that explanation was that each instruction gets one clock, and in
that case it seems like having + at the beginning of a word would
be a bad idea. If instead each word gets one clock then that
changes things a bit, doesn't it? If you were CLEAR the first
time around, I wouldn't've needed to ask the second time around.
So I guess that 2* and 2/ don't actually do anything, they
just affect some counter that affects how far over the final
result for the end of that word gets shifted? Thanks! There was
something in the manual that mildly alluded to this, but I've been
trying to figure out how it actually works for a long time.
>> 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.
Okay, it's not listed in the documentation I've been able to
afford.
>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)
That's just charming. A processor, released with bugs, and no
decent explanation of the bugs. should I just include a NOP in
front of all A!s, then? Or you want I should UNDERSTAND when it
happens so I don't need to be so wasteful?
>> 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.)
I would say that the vast majority of programmers on the P21 at
this point are going to be hacking around at low level. :)
All I would have needed was a simple "Yes, the manual is correct
on that point." btw. Thanks, though.
>> 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)
I said it's simple! I'm not stupid! The problem is that it's not
documented when it's necessary, at least not in the 'primary
reference'!
>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.
I can deal with the basic concepts involved, but I can't produce
knowledge out of nothing. So after all your bitching about how
stupid me and the rest of the world is, what I've figured is that
I need to XOR everything generated on the cross-dev environment?
See, at first I didn't know I would need to XOR opcodes. That's
not specified anywhere. I knew the address and ALU logic wanted
the XOR from discussions here, but I figured that would just be
immediates and addresses.
>> 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.
No, it's nearly all users at this level. The P21 is not a PC
chip, and as such it's not the case that nobody ever touches the
hardware. It's an experimenter's chip, and potentially an
embedded chip in the 'real world', but right now it's mostly
people who will mess around with it at the low level.
>>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.
Maybe if you took a chill pill and wrote an authoritative
reference about what's happening here you wouldn't have to explain
it all the time? I see you waste al ot of verbage saying it's
simple and nobody should talk about it, but much less trying to
make it so simple to everyone that they actually understand it.
>> 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.
What is a PPort on the P21 anyways? I assume you mean if I want
to use like an 8255 or something? Remember, I bought a bare chip.
>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.
It doesn't confuse me. Nobody had told me about it clearly until
now.
>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
Ah, scrambling the memory image. That's an important detail I
knew nothing of until just now. Thanks.
>> 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.
The MuP20 appendix to the MuP21 programming manual, page 117.
>> 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.
Okay, that is all I needed to know. Thanks. (page 118 MuP21
programming manual says the MuP20 has these timing registers)
>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.
See this is you complaining. You could answer my question, but
instead you do your absolute best to try to associate me with
idiots. Nevermind that when I watched this discussion he wasn't
as idiotic as your followers seem to think. (I think I can say
that now, since I was a follower)
>> 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
It's in the MuP20 app.notes appendix, on the second page, showing
a diagram of timing registers that you say are not in the MuP21.
>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.
Exactly, I had no idea which clock Ting was referring to. That's
why I asked. I didn't ask what clock he was referring to because
I knew.
>> 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)
Yeah, it's a waste, but it's a lot more of a waste to try to
program in the 8-bit SRAM area. It's even more of a waste to try
to run DRAMs off of batteries, though if I need to use 20ns SRAM
I'll probably be better off with DRAM.
>> 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.
I don't think I need to do anything special, because I'm pretty
sure the P21 will send out a new RAS before doing any accesses
after a refresh.
>> 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.)
I meant to use SRAM in the DRAM range. Thanks for reading my question.
It looks like I'll need 20ns SRAM.
>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.
Thanks for the heads up. I think I'll buffer everything except
the high-speed stuff.
>> 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.
That's why I want to know the timing data rather than guess it.
Thanks for making my case for me.
>> 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
I thought you said it generated every result automatically at the
beginning of an instruction [word?] In this case it seems like it
would do the same work for a NOP as for anything else. I wasn't
asking how to not get useless work done, I was asking how to
reduce power consumption.
>> 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.
"if you disable the hardware refresh" are you referring to the
video coprocessor? So in order to use DRAM I must enable the
coprocessor or generate refreshes by hand?
>> 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.
Thanks. I figured that was the case, but just making sure.
>> 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!
Good to hear.
>> 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.
That's what I've been saying all along: none of this is said
anywhere that I have access to, so I'm forced to just guess.
>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.
Oh, I didn't mean it seemed like a bad idea, I just meant I didn't
understand how it worked.
>> "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. ;-)
Where? I have only found S21 and OK on ultratechnology.com for
download. I expected OK to have something like this, but it
doesn't seem to.
>> 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....
I was talking about 8-bit mode. It may not even be for real on
modern chips, but in the MuP21 programming manual I have, it has
source for an 8-bit boot loader and a comment there says that 44
is the only working constant.
>> 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 know all that, I was still talking about 8-bit code.
>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?
If it really only allows one constant in 8-bit mode then I think
the name of that constant would be a lot more meaningful than LIT,
because LIT gives the illusion that you can use any constant.
>Of the dozens of questions you have asked I have given thoughful
>and detailed answers to all of them that I could understand. I
hah.
>also had to correct a lot of wrong assumptions that you mixed
>in with your questions. I think this should show to anyone that
hah. hah.
>people have been tring to answer your questions even if they
>have been asked and answered many times before. Most people
hahahahahah
>do ask their questions more politely, without the profanity
>and insults.
fuck off.
Jeff, you're a liar and a flake.
For years I saw people say that. I saw people say that you had no
idea what you were doing. I saw people say that UT will fail
because you have no clue what you're doing trying to run a chip
business. I've seen people say that the P21 is badly documented
and a strong argument against the validity of MISC. I've seen
people say that Ting doesn't care about his customers. I've seen
people say that F21 will never really be out of prototyping. I've
seen people say that MISC chips usually get released with bugs in
them and that the bugs aren't documented well. I've seen people
say that you guys don't even understand the hardware behind it
very well. I've even seen a couple people say that MISC is the
wrong way to go and that simplicity never works.
I've seen you act is if every insult came from someone who was too
stupid to breath. I've seen you act as if you have followers who
agree with you on everything. I've seen you act as if everyone
who isn't a follower is a complete outsider, to be ridiculed and
disrespected, obviously not a worthwhile customer.
For a long time I was a follower.
Wow, I sure was blown away to find out I was wrong and c.l.f was
right! Jeff, you're a flake. Ting's a flake in america -- maybe
he's pursuing the taiwanese market. Like that does me any good.
I wasted $50 on the MuP21. I strongly advise nobody ever make the
same mistke.
I fucking love MISC. I think it's one of the greatest things
going on right now. I'm just really sad to see MISC represented
in America by a fucking idiot like Jeff and someone who doesn't
even care like Ting. It's just a real fucking shame to see
Chuck's great ideas wasted on the likes of them.
I'm beyond respect for you Jeff. For years I've seen you treat
people the way you've treated me, insulting them constantly,
pretending they're stupid because they're ignorant. I've seen you
be very rude to people because they haven't read your publications
or Ting's publications, while refusing to publish important
technological things. I've always assumed that these people had
done something really stupid to warrant your asshole side. Now I
find out all they did was discover a little weakness in your
fucking unrealistic dream. I supported you verbally for years.
On May 14th I posted about a major weakness to the P21. I did it
very politely, I honestly expected that people would point me to
the right documentation. I was pointed to the MuP21 programmer's
manual. I immediately received hostile messages from you because
I implied that there might be something you could be doing that
you aren't. I bought the programmer's manual anyways. I find
that it's useless. I said as much, and now all you can do is
complain and tell me how stupid I am.
fuck that. I've had enough. I wish you the best of luck and I
hope that someday a MISC product developed by Chuck will be good
enough for me, and then good enough to be something I would
actually recommend someone else use, but right now I just don't
see that happening unless someone other than you and Ting starts
working on actually producing the things.
The saddest thing is that I'm certain the P21 is a great chip.
I'm almost certain that it's possible to get it to do what I want
and to be a perfect step towards achieving my goals. But fighting
with you just to try to learn teh slightest thing about it, it's
just not worth it.
I've not entirely given up on someday making use of my P21...but
it's just not worth it. Through lack of caring, Ting's taken
something beautifully simple and made it horribly complicated,
just with bad documentation. You've further compounded this
problem by being simultaneously MISC's loudest advocate and also
the biggest asshole towards anyone who asks questions.
fuck off.
