RX02 Bootstrap

From: Andreas Freiherr <Andreas.Freiherr_at_Vishay.com>
Date: Wed Feb 27 15:48:23 2002

Pete,

> :-) I apologise for the slightly non-standard syntax used, notably for
> octal constants; it was rewritten for (and then assembled by) a home-grown
> cross-assembler.

No problem: since we are interested in the sequence of words in octal,
it doesn't matter too much how you format the right side of your
listing. It's well readable and self-explanatory anyway.

> I think there were actually three errors in my original copy. Anyway, the

Yes, the place I am referring to also has three: one is at 2066 (1066 in
your version), where the value is erroneously printed as "1100420" and
should be "100240" (the difference in the low-order bit has to do with
error #3).

The second error is at 2114, where it shows "6052" and should be "60502"
(this is one of the two ADD R5,R2 instructions to advance to the next
memory address).

And the third is that the branch offsets in all BMIs yield a destination
address of 2130, where instead of aborting the boot process it would
activate the routine that has not yet been read completely. Ouch!

Also, the last three locations are slightly different, but this
shouldn't present a problem:

2130 005000 CLR R0
2132 005007 CLR PC (my favourite PDP-11 instruction, really!)
2134 000000 HALT

All this is taken from "LSI-11 Systems Service Manual, Volume III", DEC
order no. EK-LSIFS-SV-005. These digits are "Fifth Edition, January
1985".

> The reason for the number of sectors is that you can use the same bootstrap
> with trivial alterations for a single-density boot, but then you need four.

Aaah! - Good reason.

> sectors, not two. The reason for missing the even-numbered sectors is
> because they are software interleaved to give time for the memory transfers
> between reads.

I thought this is done by spacing the sectors on the disk surface (like
1, 13, 2, 14, etc.) and having drive electronics deal with the sector
number from the preamble? Consequently, this would be a property of the
floppy that would be implemented when the media was formatted.

> Some versions actually have the HALT elsewhere. I once spent ages trying
> to work out the shortest variation on this bootstrap, IIRC I managed to
> save just one word.

I think more significant savings could perhaps be obtained by
initializing a stack at the beginning and then using a subroutine like

WAITRX: BIT R0, (R1)
        BEQ $-4
        BMI ABORT
        RTS PC
ABORT: HALT

to wait for any of the TR, ERR or DONE bits to come up, instead of
repeating these instructions every time. You might even free up R0 and
use the constant #100240 directly in the BIT instruction, because you
won't need it elsewhere any more.

> The reason for the <P> instead of <G> is to avoid a bus reset, which makes
> the RX02 and some processors "do things". And you're supposed to disable
> interrupts by setting a mask in RS first. It doesn't use the stack,
> though, and any decent second-stage boot should set R6, so I suspect that's
> redundant.

Since you never set the INTR ENB bit in the RX2CS register, you just
need to keep your fingers crossed so no other device will issue an
interrupt request... ;-)

For a ROM-based implementation, I'd certainly agree that it is wise to
make sure no interrupt will get in the way, and it's certainly safer to
initialize the stack pointer as soon as possible.

> I'm surprised your version starts at 2000. By convention, all normal
> bootstraps and similar start at 1000 -- the best-known exceptions being
> XXDP code (starts at 200, same as on a PDP-8) and the TS11 bootstrap which
> starts at 10000 (to allow space for larger tape blocks).

Yes. But this is neither a typo nor a printing error. If you read four
blocks of 200(8) _words_ each, starting at zero, you fill exactly
2000(8) _bytes_, and the next free location is 2000(8). As you state,
the printed version is prepared for conversion to single density (by
clearing the 400 bit in locations 2036 and 2072, right?) by reading in
four blocks... - So, the reason is somewhat similar to that for the
TS-11.

--
Andreas Freiherr
Vishay Semiconductor GmbH, Heilbronn, Germany
http://www.vishay.com
Received on Wed Feb 27 2002 - 15:48:23 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:34:49 BST