more questions (AAAAA final clarification, addressing Qs, etc)

[Greg Alexander <galexand@xxxxxxx>]

side note: I just looked and I accidentally sent the last message to MISC,
I meant to send it only to Jeff.  Sorry about that, I hope he'll get it
anyways.  Onward ho:

I hate to ask about this as much as you all hate to hear about it.
If someone could point me to a searchable mailing list archive (or explain
how to search on the one at http://pisa.rockefeller.edu:8080/MISC/), I
would greatly appreciate it.

I just want to make sure I understand it perfectly because I want to make
a FAQ that is both correct and very clear so that even people who need to
be spoonfed will now understand this issue and talk no more of it.

Anyways, as I understand it the CPU would never actually XOR anything with
AAAAA (unless it encounters the -OR instruction).  So, for example, if you
have the two instruction cells:
	# NOP A! @+
	12345
(i.e., it pushes the literal 12345 on the stack, puts it in A, fetches
from that address)...in this case I meoan 12345 is physically what is
stored in the memory, in positive "normal" "Intel-style" logic.  In this
case I assume then that 12345 is what is output on the address bus.  If
you then did another @ instruction (the address was incremented by the @+)
I assume you would get 1235A (12345 AAAAA XOR 1+ AAAAA XOR in forth on a
PC is how I arrived at this number, I hope that makes sense) on the bus.
This is because the CPU is conceptually incrementing the number B89EF
(12345 AAAAA XOR), so it gets the answer of B89F0, which it represents as
1235A.

Of course, in a real P21 assembler, you would probably type:
	12345 # NOP A! @+
and the assembler would XOR for you so the address you end up outputting
by this code is B89EF.

Is the above correct?  If it is then I have only one more question about
AAAAA.  I have here two memory maps.  I didn't notice it before but they
differ by AAAAA:
P21 prog. man.	datasheet	RAM
000000-0FFFFF	000000-0FFFFF	DRAM
180000-1AFFFF	100000-13FFFF	slow SRAM
1CFFFF-1FFFFF	140000-17FFFF	fast SRAM
120000-1203FF	180000-1803FF	slow IO   *
160000-1603FF	1C0000-1C03FF	fast IO   *
140000		1E0000		conf reg  *
The problem comes both in that I don't know which is which and that it's
not a straight XOR.  In the lines with *s there are elements that are 0s
where one should be an A.  For example, if conf. reg is 1E0000 then it
should be 14AAAA; if slow IO is 180000-1803FF then xored it should be
18A000-18A3FF.  Now I would guess that this is rendered a moot point if
the MuP21 only uses the top 3 or 4 bits to address memory regions, and
any bits that don't get sent out to pins then get ignored.  So, for
example, the address 1C0000 would be functionally equivalent to the
address 1CA000.  And in fact everything from 1E0000-1EFFFF may be the
conf. register.  Is this the case?

If that's the case then I care only which is which.  Jeff said that
address 1AAAAA generates a 00000 on the bus in the SRAM region, so
presumably the one on the left is the programmer's viewpoint and the one
on the right is the hardware viewpoint.  Does this sound correct?


Now for a much more technical question.  In my copy of the MuP21
Programming Manual, page 118 (Appendix 5, MuP20 Application Notes), it has
the following diagram for how addresses are scrambled when sent to DRAM:
pin	A0 A1 A2 A3 A4 A5 A6 A7 A8 A9
CAS bit 0  1  2  3  4  5  6  7  8  9
RAS bit B  A  12 11 10 13 F  E  D  C
It also has the comment "The scrambling of the RAS bits has significance
only for memory tests."  Now that's true if you use 1Mword of RAM as
suggested, but if I go my minimalish route and have only 128kwords
of RAM then it matters rather a lot which address lines I ignore during
the RAS.  I want to ignore the ones connected with address bits 11, 12,
13, so that the same 128kword region is repeated 8 times through memory.
If I did it another way around, say I ignored A, B, C, then I would end up
with the same 1kword region repeated 8 times, then a different 1kword
region repeated 8 times, and so on.  This is mentioned in the manual in
the same place that the "timing register" to set DRAM and SRAM access
times shows up, so I want to make sure that it's accurate (since the
timing register apparently wasn't).  Does anyone more familiar with the
MuP21 know if this is accurate or not?  I could find out by trial and
error, but if I wind up wasting a whole day re-wire wrapping my address
decoding circuit a dozen times, I will be extremely unhappy.  I want to
have some reasonable confidence that my hardware is right so that I can
debug my bootcode without forever worrying "oh no, the bootcode may be
right, what if it's instead the RAS scrambling?"  Also, of significantly
less import, the manual says that all signals on the pins are actually
inverted (xored with FFFFF) on output.  I think this is a truly
transparent issue that not even I would care about, but since I'm writing
the FAQ I'd like to know if this is still the case or if this was only
something that happened in a prototype version so I can put something
definitive in the FAQ.



I guess it seems kind of stupid to post these descriptions and then ask
"is this correct?" but really I'm just making this stuff up and I want to
make sure I'm not misinterpretting any of my sources.  Besides, I know
I'll look a lot stupider if I assume I'm right about these things and it
later turns out I'm not. :)  (I want this FAQ to be perfect)

As usual, any help is appreciated.