21 Mar
2021
21 Mar
'21
2:14 p.m.
On Mar 21, 2021, at 2:28 PM, Paul Koning
<paulkoning at comcast.net> wrote:
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
On Mar 21, 2021, at 9:35 AM, Rick Murphy via
cctalk <cctalk at classiccmp.org> 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.