8-bit immediate questions (MuP21)

[Greg Alexander <galexand@xxxxxxx>]

Jeff said
> you will still read 20 bits.  I believe the upper 12 bits
> will be the same as the address and the lower 8 bits will
> be what was read from the address.  So # isn't exaclty like
> # in 20 bit memory. You will get garbage in the upper bits
> in 8 bit memory and you have to get rid of them.  The boot

I wrongly doubted him because I hadn't seen this documented anywhere else,
I thought he was remembering something about the F21 or maybe something
totally unrelated.  At any rate, in the ok16a.seq 8-bit assembler (from
ok101.zip from ultratechnology.com), it has the code fragment
    00 # -or
in the middle of the byte routine.  It would seem like what this code
fragment does is push the 21 bits:
    xaaaaaaaaaaaa00000000
onto the stack, then it xors that with what was in T, which would seem to
be an effective way of turning the xaaaaaaaaaaaa part into all zeroes.
So my question is what exactly is that value?  Is it from P (program
counter) or from A (address register)?  Also, is the 21st bit set (i.e.,
should the 'x' in the above diagrams just be another 'a')?

I'm wondering because it seems like it might be possible to use a single
immediate then a ;' in order to implement on-page jumps in 8-bit mode to
allow us to have a few more functions.

What about the really short branches?  i.e., if we have instruction coded
like this:
iiaiaiai
does the address that gets branched to get encoded as
AAAAAAAAAAAAA00a0a0a0
where the "A" comes from the P register and the "a" comes from the
instruction?  If that's the case then it seems like I could have multiple
branch targets (like for loops) so long as they're separated by 256 bytes.
Also, in the ok16a.seq it looks like the lower 8 bits there will be
inverted (i.e., XOR with FF)?  Am I interpretting this correctly?

I'm asking because I want to make somewhat more complex boot ROM that
will, rather than copy from SRAM, copy from the serial port (I'm a lazy
cheapskate who would rather use serial cables than PCMCIA cards or flash
ROMs or EEPROMs or whatever).


Also, I owe you all, especially Jeff, an apology.  Much of what I said was
right and much of it was wrong.  I still don't think Jeff is a very good
P21 resource (but as he likes to say, it is not his job), but he is
probably the best we have.  I should not have brought the flamewar onto
the list so loudly and rudely.  I still think Jeff's tendency to
exaggerate is a big problem for all of us, but there's nothing anyone can
do to change it (I don't think Jeff could change it any more than I could
change being impatient with poor documentation), so I'll just get over it.
I don't expect Jeff to forgive me, but I don't much care.  If nobody
answers my questions, I'll just have to guess and if it doesn't work I'll
have to guess again.

An MuP21 FAQ is forthcoming, so answering my questions will not be quite
as useless as sending answers that will get filed away in an
(unsearchable?) mail archive.  I will in the future try a lot harder to
ask "are you sure?  it seems like ..." rather than simply saying that Jeff
(or whoever answers) is wrong.

Thanks in advance for any help.