> On Mar 21, 2021, at 2:28 PM, Paul Koning <[email protected]> wrote:
>
>
>
>> On Mar 21, 2021, at 9:35 AM, Rick Murphy via cctalk <[email protected]>
>> wrote:
>> ...
>> Trying again - my reply got chopped off for some reason.
>>
>> You have to read the bootstrap code in the TC0x driver to understand this.
>>
>> What happens is that the code watches the buffer pointer (7755) and when it
>> hits 7642, the remaining read is directed to field 1. The boot is looping on
>> 7616/DTSF and 7617/JMP .-1 when it's overwritten by the boot (the NOP below
>> overwrites the DTSF).
>
> The details are different, but it reminds me a bit of the magic used in the
> bootstrap on the CDC 6000 mainframes.
Another example and a more significant one of a self modifying boot loading
process is the "emulator IPL" on the IBM 360 model 44. The "emulator" is a
chunk of separate memory and control used to emulate the SS instructions not
implemented in the hardware. I used such a machine in college and looked at
the card deck for the emulator.
IPL ("initial program load") reads a record from the boot device -- the card
reader in this case -- which is a channel program that is then executed to read
the actual initial code. In the emulator case, the rest of the card deck is a
standard binary output file from the assembler -- think LDA format on a PDP-11.
The first card is a nice concoction of several channel commands that read
another card, drop the load address and byte count fields for that card into
another channel command word, then executes that CCW to send the data on the
card to the right memory location. It then loops back (CCW "command chaining")
to do the same with the next card. So the entire deck load is executed by the
channel, no CPU involvement at all, transfering the right number of bytes from
each card to the location it asked for.
I don't have any of this preserved, but it wouldn't be too hard to reconstruct
the details from that description. An exercise for the student... :-)
paul
