21MX proms (per request
Glen Slick
glen.slick at gmail.com
Sun Sep 13 22:26:59 CDT 2015
On Sun, Sep 13, 2015 at 7:44 PM, J. David Bryan <jdbryan at acm.org> wrote:
> On Sunday, September 13, 2015 at 8:42, Jay West wrote:
>
>> 3) Any I/O instructions in the loader are automatically patched during
>> the transfer (based on switch register bits 11 through 6) so that the
>> correct I/O address (device) is referenced.
>
> It's actually a bit more nuanced than this. What occurs is:
>
> 3a) Except for halt instructions, any I/O instruction referencing select
> code 10 (octal) or greater is patched by adding the select code
> value in the switch register minus 10.
>
> This means that (a) halt instructions, which are in the I/O group, are not
> altered, (b) DCPC I/O instructions, which reference select codes 2, 3, 6,
> or 7 are not altered, and (c) interfaces that use two select codes, e.g.,
> the 7900 disc interface, get both select codes updated properly. It also
> implies that all loaders are written to reference select code 10 (or 10 and
> 11, etc.).
>
> 3b) The two's-complement of the memory address of the first word of the
> loader is stored in the last word in memory.
>
> This is so that loaders can check that what they are loading does not
> overwrite the loader itself. For example, the paper tape loader does a HLT
> 55 if the absolute binary tape contains a record that would overlay the
> loader executable code.
>
> 3c) The contents of the penultimate memory location is patched by adding
> the select code value in the switch register minus 10.
>
> This is used to patch the select code into an optional DCPC control word,
> which is a constant and not an I/O instruction and so wouldn't be patched
> by (3a). Loaders that use DCPC, e.g., the disc loaders, place their DCPC
> control word at this location.
>
> There's actually quite a lot going on under the hood for that IBL button
> press.
>
> -- Dave
>
For the curious the source code for the Initial Binary Loader
microcode is listed on pages D-16 and D-17 of this manual:
http://www.bitsavers.org/pdf/hp/1000/1000_MEF_EngrRef/92851-90001_Mar81_1.1.pdf
It is reasonably well commented, but still not completely obvious
exactly what and why it is doing what it is doing without something
like Dave's explanation above.
More information about the cctalk
mailing list