[TUHS] v6 RK05 bootloader question

[TUHS] v6 RK05 bootloader question

[Norman Wilson]

Something of a tangent:

In my early days with UNIX, one of the systems I helped look
after was an 11/45.  Normally we booted it from an SMD disk
with a third-party RP-compatible contorller, for which we
had a boot ROM.  Occasionally, however, we wanted to boot it
from RK05, usually to run diagnostics, occasionally for some
emergency reason (like the root file system being utterly
scrambled, or the time we ran that system, with UNIX, on a
single RK05 pack, for several days so our secretaries could
keep doing their troff work while the people who had broken
our air-conditioning system got it fixed--all other systems
in our small machine room had to stay shut down).

There was no boot ROM for the RK05, but it didn't matter:
one just did the following from the front-panel switches:

1.  Halt/Enable to Halt
2.  System reset (also sends a reset to the UNIBUS)
3.  Load address 777404
4.  Deposit 5.
(watch lights blink for a second or so)
5.  Load address 0
6.  Halt/Enable to Enable
7.  Continue

777404 is the RK11's command register.  5 is a read command.
Resetting the system reset the RK11, which cleared all the
registers; in particular the word count, bus address, and
disk address registers.  So when the 5 was deposited (including
the bit 01, the GO bit), the RK11 would read from address 0 on
the disk to address 0 in physical memory, then increment the
word-count register, and keep doing so until the word count
was zero after the increment.  Or, in higher-level terms, read
the first 65536 words of the disk into the first 65536 words
of memory.

Then starting at address 0 would start executing whatever code
was at the beginning of memory (read from the beginning of the
disk).

Only the first 256 words (512 bytes) of the disk was really
needed, of course, but it was harmless, faster, and easier to
remember if one just left the word-count at its initial zero,
so that is what we did.

The boot ROM for the SMD disk had a certain charm as well.
It was a quad-high UNIBUS card with a 16x16 array of diodes,
representing 16 words of memory.  I forget whether one inserted
or removed a diode to make a bit one rather than zero.

It's too bad people don't get to do this sort of low-level stuff
these days; it gives one rather a good feel for what a bootstrap
does when one issues the command(s) oneself, or physically
programs the boot ROM.

Norman Wilson
Toronto ON

[TUHS] v6 RK05 bootloader question

[Will Senn]

All,

I am preparing to open a SimH ticket around hand entered boot loaders along the lines of the one described by Norman below. Currently, the simulator doesn't allow the console operator to perform this type of boot. Although, it should be theoretically possible to follow the steps as given with the expected result, the simulator just doesn't work exactly like the console. I have this example and can theorize others, but if y'all know of some you actually used to boot your PDP-11 machine from tape/disk/etc,  I will happily include them in my request. It is possible/likely that the SimH pdp-11 simulator can be modified to support this process.

Thanks,

Will

Sent from my iPhone

> On Dec 27, 2015, at 2:32 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> Something of a tangent:
> 
> In my early days with UNIX, one of the systems I helped look
> after was an 11/45.  Normally we booted it from an SMD disk
> with a third-party RP-compatible contorller, for which we
> had a boot ROM.  Occasionally, however, we wanted to boot it
> from RK05, usually to run diagnostics, occasionally for some
> emergency reason (like the root file system being utterly
> scrambled, or the time we ran that system, with UNIX, on a
> single RK05 pack, for several days so our secretaries could
> keep doing their troff work while the people who had broken
> our air-conditioning system got it fixed--all other systems
> in our small machine room had to stay shut down).
> 
> There was no boot ROM for the RK05, but it didn't matter:
> one just did the following from the front-panel switches:
> 
> 1.  Halt/Enable to Halt
> 2.  System reset (also sends a reset to the UNIBUS)
> 3.  Load address 777404
> 4.  Deposit 5.
> (watch lights blink for a second or so)
> 5.  Load address 0
> 6.  Halt/Enable to Enable
> 7.  Continue
> 
> 777404 is the RK11's command register.  5 is a read command.
> Resetting the system reset the RK11, which cleared all the
> registers; in particular the word count, bus address, and
> disk address registers.  So when the 5 was deposited (including
> the bit 01, the GO bit), the RK11 would read from address 0 on
> the disk to address 0 in physical memory, then increment the
> word-count register, and keep doing so until the word count
> was zero after the increment.  Or, in higher-level terms, read
> the first 65536 words of the disk into the first 65536 words
> of memory.
> 
> Then starting at address 0 would start executing whatever code
> was at the beginning of memory (read from the beginning of the
> disk).
> 
> Only the first 256 words (512 bytes) of the disk was really
> needed, of course, but it was harmless, faster, and easier to
> remember if one just left the word-count at its initial zero,
> so that is what we did.
> 
> The boot ROM for the SMD disk had a certain charm as well.
> It was a quad-high UNIBUS card with a 16x16 array of diodes,
> representing 16 words of memory.  I forget whether one inserted
> or removed a diode to make a bit one rather than zero.
> 
> It's too bad people don't get to do this sort of low-level stuff
> these days; it gives one rather a good feel for what a bootstrap
> does when one issues the command(s) oneself, or physically
> programs the boot ROM.
> 
> Norman Wilson
> Toronto ON

[TUHS] v6 RK05 bootloader question

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

Yep, I suspect the simulator “console” doesn’t let you deposit directly into the simulated unibus csrs.


I bet there’s some more stuff they get wrong.   Not everything on the PDP-11’s is actually documented.   I bet I can’t lock up the system by loading up the address space in user mode with SPL instructions either :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151229/555322ba/attachment.bin>

[TUHS] v6 RK05 bootloader question

[Wolfgang Helbig]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

What went wrong with simh? It worked fine with examples that I entered. Find working “simh”-Programs at
	http://wwwlehre.dhbw-stuttgart.de/~helbig/os/pdp11/progs/

They might help to narrow in the problem.

Greetings,
Wolfgang

[TUHS] v6 RK05 bootloader question

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2899 bytes --]



On 12/30/15 1:14 AM, Wolfgang Helbig wrote:
> What went wrong with simh? It worked fine with examples that I entered. Find working “simh”-Programs at
> 	http://wwwlehre.dhbw-stuttgart.de/~helbig/os/pdp11/progs/
>
> They might help to narrow in the problem.
>
> Greetings,
> Wolfgang
Wolfgang,

Nothing is wrong with SimH's handling of the machine code programs that 
I know of. It is when you try to modify the device registers directly 
using deposit to effect the boot loading that the simulator doesn't 
operate as would a real PDP-11. For example, Norman Wilson's example:

1.  Halt/Enable to Halt
2.  System reset (also sends a reset to the UNIBUS)
3.  Load address 777404
4.  Deposit 5.
(watch lights blink for a second or so)
5.  Load address 0
6.  Halt/Enable to Enable
7.  Continue

This doesn't work in SimH. I asked Mark Pizzolato about why, and he suggested the following:

The reason is that on real hardware, when an I/O activity
is initiated via some register probing, the device will then perform the commanded
activity in parallel to the simulator's execution of instructions.  A device driver will
either wait for an interrupt to know when to proceed or it will read some device
status register periodically or in a tight loop to determine completion.  With hand
entered boot code, the goal is to minimize typing of boot code and since
operations will complete (from a human perspective) as soon as the user is done
typing, instructions which wait for I/O completion are not provided as  part of the
hand typed boot code.

Simh devices don't actually operate in parallel with the CPU.  The concept of
parallel operation is simulated by the devices performing their activities in
between the execution of simulated instructions.  The simh framework has
the ability to allow a device simulation to schedule its activation in between
some future number of instructions executed.  This allows programs in the
simulated system to see that some time has elapsed from when a device
operation is initiated to when it completes.  A hand entered bootstrap program
without any loops to wait for completion status generally won't execute
enough instructions to allow the desired operation to actually complete

Which makes sense, but doesn't sound like a brick wall. Yes, the console 
method leverages side effects, granted, but the console method worked on 
a real PDP, just not on the simulator. It will with some 
modifications... To be honest, I really liked the idea of making 
Norman's method work in SimH because it's fun and feels historic, and if 
I can provide other similar examples along with some supporting text, 
the modification can probably be made. Then I can write another blog 
entry for posterity that's a little more fun and a little less 
technical, well that depends on the reader's perspective, but certainly 
light on technical details :).

Thanks,

Will

[TUHS] v6 RK05 bootloader question

[Erik E. Fair]

Related minicomputer booting story:

I cut my computing teeth on the PDP-11's competitor, the Data General NOVA minicomputer. Edson de Castro supposedly proposed the architecture to Ken Olson, and when Ken said "no", Edson left DEC and founded DG - much as we've seen companies in Silicon Valley beget each other when some smart engineers get annoyed with their bosses. Fairchild begat Intel and AMD, Cisco begat Juniper, et alia.

Rather than memory-mapped I/O, the NOVA had I/O instructions, and six bits of device codes. Every interrupt handler I saw for the NOVA ended in the same self-modifying code sequence: if your OS doesn't handle the device that has interrupted, put the device code into an interrupt dismiss instruction in the next location, fall into it to shut the device up, and return from interrupt.

Booting the NOVA (provided you knew the device code of the device you wanted to boot from) was simplicity itself:

Power everything up.

Mount the media (disk, tape) including any positioning as required

Put I/O device online (frequently an explicit act involving a switch)

Set the CPU front panel switches to the 6-bit device code

Hit in order the momentary contact switches: STOP, RESET, START

The CPU would read the device code from the front panel switches, read the first record (of arbitrary size) from the device into RAM starting at location 0, and set the program counter (PC) to zero and begin execution of whatever was read in from the I/O device.

Disks had a primary booter in the first 512 bytes (so, 256 16-bit instructions & data) which would read in the rest of whatever OS you were booting. Necessarily, that booter needed to know where to load the OS from on disk.

Since "page zero" of the NOVA (the first 256 words of RAM) was a critical resource (direct reference from anywhere else in RAM rather than using space-expensive indirect addressing, plus, there were some autoincrement and autodecrement locations - reading them caused the stored value to change - handy for counters and pointers), the booter usually got overwritten.

Booting an OS from tape was easier because of the arbitrary record size: you could fit a whole tape OS into a single record and start running immediately - no intermediate boot code required. OTOH, tape OSes were really slow when all their files were on very slow tape drives (if you were lucky, you had vacuum column tape drives - faster for positioning).

Life got lots easier when PROMs got big & cheap enough for on-board firmware like IEEE 1275 (OpenBoot/Open Firmware, a formalization of Sun's forth-based firmware).

So far as I know, Unix (DG/UX) didn't come to DG until the Eclipse MV ("Eagle") 32-bit computer of literary fame.

	ancient history,

	Erik <fair at netbsd.org>

[TUHS] v6 RK05 bootloader question

[John Cowan]

Erik E. Fair scripsit:

> Rather than memory-mapped I/O, the NOVA had I/O instructions, and
> six bits of device codes. 

Same as the PDP-8, in fact.  But all my PDP-8 work was with OS/8,
which runs with interrupts off: you can turn them on in userland if your
program wants to use them, but you have to shut them off before invoking
any system services.  So I know little of these sixties sitcoms of
which you speak.

> Since "page zero" of the NOVA (the first 256 words of RAM) was a
> critical resource (direct reference from anywhere else in RAM rather
> than using space-expensive indirect addressing, plus, there were some
> autoincrement and autodecrement locations - reading them caused the
> stored value to change - handy for counters and pointers), 

All exactly like the PDP-8.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
You are a child of the universe no less than the trees and all other acyclic
graphs; you have a right to be here.  --DeXiderata by Sean McGrath

[TUHS] v6 RK05 bootloader question

[Wolfgang Helbig]

Hallo Will,

Ah, I understand:
The HALT instruction of the real PDP11 only stops the CPU whereas simulator also stops simulating the devices.

By the way, I modified simh 2.6:
The simulated clock ticks at real 60 Hz.
The simulater waits a little bit in each cycle. This saves the real CPU from overheating and slows down
the execution to a more realistic level.
I can attach terminals, this gives you a more realistc multi user experience.

Greetings,
Wolfgang

[TUHS] v6 RK05 bootloader question

[Noel Chiappa]

    > From: Wolfgang Helbig

    > The HALT instruction of the real PDP11 only stops the CPU 

I have this bit set that on at least some models of the real machine, when
the CPU is halted, it does not do DMA grants? If so, on such machines, the
trick of depositing in the device registers directly would not work; the
device could not do the bus cycles to do the transfer to memory. Anyone know
for sure which models do service DMA requests while halted?

	Noel

[TUHS] v6 RK05 bootloader question

[Will Senn]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]



On 12/26/15 1:26 PM, Ronald Natalie wrote:
> Note that all this “boot loading” stuff was only necessary if you didn’t already have a boot rom board (the common one for the early PDPs had a bunch of diodes you clipped).   Ours was set to boot RK Drive 0 so even after we got a larger drive (80MB seemed like an infinite amount of storage after dealing with 2.4M) we left a disk with the bootstrap in RK0.
>
> I can’t remember the boot address on that machine, but the boot for the 11/70 I used for years at BRL is still ingrained in my memory:  7765000 (while it isn’t exactly right, I used the Glenn Miller PENNSYLVANIA-6-5000 as a memory aid).   Long after we gave up using PDP-11’s for UNIX machines, I recycled them all into internet routers using my own (“Little Operating System” LOS).   We had started with Noel’s MIT gateway but he was exiled at the time to the Bahamas or something and we decided it was easier starting over with the magnitude of changes we needed to make.
>
Thanks for the reply. SimH has built in boot ROM code for the RK 
controller and other devices as well. So, the boot loader code isn't 
really necessary, but I like to understand the things I am reading and 
the boot loader code is presented in the set up instructions, so I 
wanted to understand them before I moved on to other areas.

I appreciate the historical perspective. Glenn Miller, that's fun.

Regards,

Will

[TUHS] v6 RK05 bootloader question

[Ronald Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

Note that all this “boot loading” stuff was only necessary if you didn’t already have a boot rom board (the common one for the early PDPs had a bunch of diodes you clipped).   Ours was set to boot RK Drive 0 so even after we got a larger drive (80MB seemed like an infinite amount of storage after dealing with 2.4M) we left a disk with the bootstrap in RK0.

I can’t remember the boot address on that machine, but the boot for the 11/70 I used for years at BRL is still ingrained in my memory:  7765000 (while it isn’t exactly right, I used the Glenn Miller PENNSYLVANIA-6-5000 as a memory aid).   Long after we gave up using PDP-11’s for UNIX machines, I recycled them all into internet routers using my own (“Little Operating System” LOS).   We had started with Noel’s MIT gateway but he was exiled at the time to the Bahamas or something and we decided it was easier starting over with the magnitude of changes we needed to make.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/1576e5ae/attachment.bin>

[TUHS] v6 RK05 bootloader question

[Ronald Natalie]

Yeah, some of the code is a bit non-obvious because the author of this snippet was trying to get the minimum number of instructions that
have to be keyed in with the front panel switches to make things go.

Yep, as far as the UNIBUS is concerned the bus addresses could be memory or control registers for some peripheral.

Your analysis is correct.  Note this one jumps to zero when ready as opposed to the tape boot you posted before which just loops forever
expecting you to notice the tape has finished moving and wants you to load 0 and start.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151226/1a1cb534/attachment.bin>

[TUHS] v6 RK05 bootloader question

[Will Senn]

All,

I'm trying to understand the RK bootloader code that is found in 
"Setting up Unix - Sixth Edition". My question is related to RKBA, RK's 
bus address buffer. Is the bus address the same as memory address? If 
so, the code makes sense, if not, I appreciate y'alls help.

Here's what I have so far:

RK05

01 012700       MOV 177414,R0  ; Move RKDB into R0
02 177414                      ; RKDB Address
03 005040       CLR -(R0)      ; Decrement R0 and clear the contents of RKDA
04 005040       CLR -(R0)      ; Decrement R0 and clear the contents of RKBA
05 010040       MOV R0,-(R0)   ; Move the contents of R0(RKBA) into 
decremented R0(RKWC)
06 012740       MOV 5,-(R0)    ; Decrement R0 and move 5 into RKCS
07 000005                      ; Read and go
08 105710 WAIT: TSTB (R0)      ; Test the lower byte of RKCS
09 002376       BGE WAIT       ; When bit 7 becomes 1, the read is done
10 005007       CLR PC         ; Set PC 000000, the start of the bytes read

RKDB - RK data buffer register
This register is a general data register and it only used by the code 
above to initialize R0 so that subsequent RK addresses can be found by 
simply decrementing R0.

RKDA - RK disk address register
This register determines the starting disk address of the read operation 
and is cleared by the code.

RKBA - RK current bus address register
This register contains the bus address to or from which data will be 
transferred. Is this the same as memory address?

RKWC - RK word count register
Two's complement of the number of words to be transferred.

RKCS - RK control status register
This is the register that controls the device and provides the device 
status to the program

Lines 1-2
The execution of the boot loader code moves the address of RKDB into R0 
to initialize the register so that it can be used to obtain the other RK 
buffer addresses as they are needed.

Line 3
The RKDA buffer is cleared, setting the disk address to 0.

Line 4
The RKBA buffer is cleared, setting the bus address to 0.

Line 5
The value in R0 is transferred into the RKWC buffer. RKBA or 177410, the 
value in R0, is a convenient number to use for the read operation 
because it is big enough to cause the program to read in a block of 
data. The number is in two's complement and represents -370. This tells 
the disk controller that 370 words (540 bytes) will be transferred.

Lines 6-7
The value 5 is placed into RKCS, this value represents a read operation 
and go.

Lines 8-9
The lower byte of RKCS is tested and when it is greater than or equal to 
zero (not negative), it loops, waiting until the value is negative, that 
is until bit 7 becomes 1, which indicates Control Ready (RDY) and done.

Line 10
  PC is set to 00000 and execution of the bytes read from the disk 
begins at location 00000.