Trailing-Edge
-
PDP-10 Archives
-
BB-L288A-RM
-
swskit-documentation/rp20-notes.mem
There are 4 other files named rp20-notes.mem in the archive. Click here to see a list.
TOPS-20 RP20 Software Functional Specification
I. OVERVIEW
This is a functional specification which describes the work
performed for TOPS-20 to add support for the RP20 disk subsystem.
II. CONFIGURATION DETAILS
Generally, each available RH20 channel can drive eight DX20s. Each
DX20 can drive one RP20 controller. Each RP20 controller can drive
spindles. In actual practice, these limits will not be attained because
of monitor table space and performance problems.
Each RP20 drive can be dual ported. Therefore, it is possible for
a disk to be accessed from two different RH20s, DX20s, or 8000s. It is
important to realize that this dual-porting is not active, however.
Unlike TOPS-10, TOPS-20 will not do commands to a drive using both
paths. All that will be done is that the monitor will notice the
existance of dual-porting, and not think that two separate drives exist.
This is for availability. If one of the paths to a disk becomes
unavailable because of some hardware problem, the disk can be accessed
from the other path when the monitor is restarted.
Dual porting is determined as follows. Each 8000 controller can be
assigned a number from 0 to 7. If the controller is 0, then all RP20
disks connected to that controller are single ported. If the controller
number is non-zero, then each disk is dual ported to another controller
with the same number. This convention is necessary because RP20s do not
have a serial number which can be used to determine if two access paths
lead to the same disk drive.
It is possible to dual port the RP20 disks such that one port is
available to each of two different TOPS-20 systems. However, only one
port can be enabled at any time. Since the two systems do not
communicate, access to the same disk at the same time would destroy the
data on the disk. To switch the disk from one system to another, it
must be dismounted from the first system, and then the port to that
system must be disabled. Then the port to the second system can be
enabled, and the disk mounted on the second system.
There are two spindles inside of each RP20 box. However, these two
spindles are totally independent. The monitor treats these as separate
units, and therefore they could appear as two separate structures. For
model B's there is a limit of 3 spindles per structure. For model A's,
a structure can only use one spindle.
Page 2
The capacity of a single RP20 spindle is 201420 pages. An RP06
holds 76000 pages, so an RP20 has 2.65 times the capacity of an RP06
when formatted for TOPS-20. Therefore one RP20 box containing two
spindles has over 5 times the capacity of a single RP06. Almost all of
this space will be available to the users, since the RP20 cannot be used
for booting, does not have a front-end area, and does not have swapping
space. This means that a system must include another type of disk for
these functions.
III. INTERNAL MONITOR CHANGES
There are many changes necessary to use the RP20 disk in TOPS-20.
The following is a simple outline of these changes.
RELEASE 4 CHANGES
The monitor must understand about the existence of
controllers. Many subroutines have to accept controller numbers
in addition to channel and unit numbers. The MSTR JSYS has to
be able to handle controller numbers in its unit status
functions (.MSRUS and .MSRNU). The 403 restart option of the
monitor must be able to input and output controller numbers.
The DSKOP JSYS must handle controller numbers. (See the next
section for details.)
The monitor must be able to handle sector sizes which are
one page. Places in the monitor which assumed a disk sector was
200(8) words in length also have to handle sectors which are
1000(8) words in length. Length errors reading sectors have to
be ignored when reading HOM or BAT blocks.
The DSKOP JSYS has been extended to allow multiple-page
reads. This is to allow the image-backup programs to run
quickly.
IV. CHANGES TO THE DSKOP JSYS
The DSKOP JSYS has been changed to allow the specification
of controller numbers. Also, the size of the unit number field
must be extended because RP20s can have unit numbers up to 377.
The new DSKOP format is the following:
Page 3
If the flag DOP%NF (bit 10) is not set in AC2, then DSKOP
works as in previous monitors. If DOP%NF is set, then the
arguments for the .DOPPU type of DSKOP (physical unit
information) are changed. The channel and unit fields in AC1
(DOP%CN and DOP%UN) are ignored. Instead, AC4 will contain the
following information:
Symbol Bits Description
DOP%C2 0-11 The channel number
DOP%K2 12-23 The controller number (or 7777 if none)
DOP%U2 24-35 The unit number
Also, the word count is no longer restricted to 1000 octal
words. The rule is: if a transfer stays within a single memory
page, DSKOP works as before, and error correlation and is
disabled. So if an error return occurs on a multi-page DSKOP,
the user program can then revert back to single page DSKOPS to
recover. There is a limit of 50 decimal pages for a transfer
(an attempt to read/write info more than 50 memory pages is
illegal).
V. NECESSARY CHANGES TO UTILITIES
The following programs have been changed in order to support the
RP20 disk. Most of these changes are necessary because of the existence
of a controller for these disks.
RELEASE 4 CHANGES
BOOT - Code has been added so that BOOT can load the microcode
for DX20s which control RP20s, in addition to those DX20s which
control the TU7x tapes. BOOT will not know how to access an
RP20. Thus it will not be possible to load the system from an
RP20, or to save a dump on an RP20. Another type of disk (such
as an RP06) is necessary for these functions.
CHECKD - The data for the RP20 disk has been added to the tables
it contains. The prompting for the disk unit has been changed
to include the controller number in the CREATE command. The
routine to type out the possible units includes the controller
number.
DDT - The version of DDT for examining files (FILDDT) has been
changed to allow the input of a controller number for the DRIVE
command. The code which does the DSKOP JSYS has been changed to
use the new format of the JSYS.
MOUNTR - The IPCF packet sent by ORION containing the controller
number has been handled. The output messages listing available
drives includes the controller number.
Page 4
DX20LD - The program has to be able to distinguish the DX20
which drives the RP20s from the DX20 which drives TU7xs. The
proper version of the microcode has to be loaded in each case.
The internal tables have been reorganized. DX20LD will
recognize the names DXMCA* as tape microcode, and DXMCE* as disk
microcode as defaults. There will also be the two new switches:
/T this is for tape DX20's
/R this is for RP20 DX20's
SYSERR - New code and tables have been added to handle errors
from the RP20s.
POSSIBLE FUTURE CHANGES
OPR/ORION - The command "SET DISK-DRIVE" must be extended to
include the controller number. The IPCF packet sent by ORION to
MOUNTR which contains the SET DISK-DRIVE data must contain the
controller number.
Page 5
NOTES ON RP20 OPERATION
THE DX20
--------
The DX20 is a device whose purpose is to allow the connection of IBM
compatible equipment with the RH20 channel of the KL processor. The
DX20 takes MASSBUSS commands from the KL, and translates them into IBM
style channel commands. The DX20 contains a minicomputer which is
programmed for this function. Notice that the TU70 style tape drives
are also controlled by a DX20. The only difference between these two
DX20s is a switch which is set to a particular value. Since the two
types of DX20 are set with different values, the monitor and microcode
loaders can distinguish between those DX20s which control disks and
those which control tapes.
The monitor tries to distinguish between the two kinds of DX20 in
reporting problems with them. The tape version of the DX20 is referred
to as a "DX20A" and the RP20 version is referred to as "DX20B". BUGCHKs
BUGINFs, and BUGHLTs related to the DX20s are generally of the two forms
DXAxxx and DXBxxx, so that tape problems can be distinguished from disk
problems. Finally, the BUGCHK and BUGINF output generally mention
either PHYX2 or PHYP2. PHYX2 is the module name of the TU70 driver, and
PHYP2 is the module name of the RP20 driver.
The DX20 has no external controls which the operator can use, nor does
it have any indicators to judge whether or not it is running. Only the
examination of the MASSBUSS registers for the DX20 can indicate if the
microcode is loaded and running. The monitor checks the microcode for
validity when it is first coming up, and checks to see if the microcode
is still running whenever any operation is started for a drive. Various
BUGCHKs will be output when the microcode is known to be bad, such as
DXBDMI (DX20 microcode is invalid), DXBDIE (DX20B microcode halted), and
DXBHLT (DX20B controller halted). On seeing one of these errors, the
affected RP20 disks will be off-line until the microcode is reloaded.
The BOOT program automatically loads microcode for all DX20s on the
system whenever a monitor is manually loaded by the operator. BOOT
loads both tape and disk DX20s, using the unit type to decide which type
of microcode to load. The microcode is contained within the BOOT
program itself, so that BOOT does not need any data file to load the
microcode. For each DX20 which BOOT loads, a message is output to the
CTY informing the operator which channel and DX20 number is being
loaded, and whether or not the load was successful. On a failure, BOOT
types the good and bad data, and field service should be called to
examine the problem. BOOT does not load any microcode on a reload or if
a dump is being taken.
Once the system is up and running, the DX20 should be running properly
since BOOT had loaded it. If the microcode becomes corrupted or halts
because of some problem, the operator will have to reload it manually.
The DX20LD program is used for this. The program has various commands
Page 6
to load microcode, verify microcode, and start and stop the DX20. The
program gets the microcode from a file which is is in a special format.
The standard names for the microcode files are as follows:
TU70: DXMCA.ADX
RP20: DXMCE.ADX
The normal action when running DX20LD is simply to type in the name of
the microcode file, and DX20LD will look around for the proper DX20 and
will load and verify the microcode into that DX20. The file names above
are known to DX20LD, and specify as a default which kind of DX20 to look
for. (Actually, any filename which starts with those first five letters
will work. So that DXMCE-OLD.ADX would be recognized as RP20 microcode,
for example, but OLD-DXMCE.ADX would not).
If there is confusion between types of DX20 being loaded, the switches
/T (for TU70) and /R (for RP20) can be used to force DX20LD to load only
that type of DX20. The switches will override the file names above, so
that a command like "DXMCE.ADX/T" will indeed load the disk microcode
into the wrong kind of DX20.
If there is not a unique DX20 to be loaded, you must specify the channel
and DX20 number of the DX20 you wish to load. The /D:mn switch does
this, where "m" is the channel number, and "n" is the DX20 number. For
most systems, where there is at most one DX20 for tapes and one DX20 for
disks, the switch isn't necessary. But if there were two DX20s for
disks for example, the /D switch has to be used to select which DX20 to
use.
DX20LD checks the microcode for validity after it loads it, and if there
are problems with the DX20 will complain about mismatches and will type
out good and bad data just like BOOT. If this occurs, field service
should be called in to fix the problem.
Each RH20 on the system can handle up to eight DX20s, of any kind.
However, DX20s should "stick together". That is, you should not put a
tape DX20 and disk DX20 on the same channel (even though it might work).
It is also a bad idea to put RP06s or TM02s on the same channel as a
DX20. However, it is just fine to put 8 disk DX20s on the same channel
(but expect this to be slow!!).
Page 7
The 8000 controller
-------------------
The 8000 controller is a IBM-compatible disk controller which handles up
to 16 RP20 disks in dual ported mode, and 8 disks in single ported mode.
It is talked to by the DX20. Only one 8000 controller can be controlled
by a DX20. The 8000 controller is also a mini-computer, and it has its
own microcode distinct from the DX20 microcode. It gets its microcode
from a floppy disk which should always be mounted in its floppy drive
inside the cabinet. The microcode is loaded automatically when the 8000
is powered on, when a power fail occurs, or when explicitly commanded by
using the maintenance switches inside the cabinet. The KL processor
cannot read or write the microcode of the 8000, or start or stop it.
Therefore the 8000 controller will in general require very little
attention by the operator since reloads, DX20LD, etc cannot affect it.
There is only one panel outside the cabinet which contains switches and
lights. These are the port enabling switches for the 8000, labeled
"CHANNEL ENABLED" (A, B, C, and D) and "TAGGED". In order for the 8000
to control any disks, the "TAGGED" switch must be on (it lights up when
it is on) and the proper "CHANNEL ENABLED" switches must be on (they
also light up when on). Which of the "CHANNEL ENABLED" switches needs
to be on is determined by how field service connects the disks to the
controller. These are push-button switches which lock into place, so
that once set they never have to be touched again, even across power
failures.
When it is necessary to examine the 8000 controller, the back door is
opened revealing a maintenance panel with many switches and lights.
Most of these are for field service's use, but a few notes should be
given here to enable operators to cope with problems.
There is a selector switch labeled "MODE" at the right side of the
maintenance panel. If it is in the rightmost "NORMAL" position, then
all other switches on the panel are disabled (as a safety feature). To
allow the other switches to work, the selector would be switched to the
"FE NORMAL" position. This affects the operation of the 8000 in no way,
except to allow other switches to work. (IE, it will not affect I/O
operations to the disk).
There is a selector switch in the left center of the panel labeled
"ENTER/DISPLAY". This switch selects which kind of information is
displayed in the LEDs immediately above, labeled "ADDRESS/CHECK/INLINE
DISPLAY". The normal position of this switch is in the "INLINE"
position, where it displays a checksum of the microcode. Other useful
positions of the switch are the "CHK1" and "CHK2" positions, which
display certain errors detected by the 8000. Changing this switch does
not affect the operation of the 8000 in any way, except for changing the
data displayed in the LEDs.
The LEDs themselves are a row of 18 bits, labeled "P", "0", "1", etc up
to "15", "P". The actual data bits are the numbered bits, and in what
follows the bits labeled "P" are ignored.
Page 8
When the microcode is loaded and running properly in the 8000
controller, and the "ENTER/DISPLAY" switch is in the "INLINE" position,
bits "0" and "1" should be lit, and bits "2" through "15" should be off.
If this is not true, then the microcode in the 8000 is invalid and
should be reloaded as described below. The microcode should also be
reloaded if the indicator labeled "CLOCK STOPPED" is on, or the "READY"
indicator is off (both in the top right of the maintenance panel).
To reload the microcode of the 8000 controller, you have to put the
"MODE" switch into the "FE NORMAL" position, and flip the "RESET" switch
which is at the bottom of the maintenance panel. This stops and resets
the 8000 controller. Then flip the "IMPL" switch in the top left of the
panel. This should start a sequence of events which will load the
microcode from the floppy drive, and start it. This process is
indicated by the LED labeled "MPL ON" being lit in the top left of the
panel. After a period of time about 30 seconds long (during which
nothing much seems to happen), the "MPL ON" light goes back off and the
controller should be ready.
If this procedure fails, you can try powering off and on the 8000
controller using the "POWER" switch on the top right of the maintenance
panel. When power is restored, the 8000 automatically tries to load
itself, a process which takes several minutes. During this time you
have no need to use the "RESET" and "IMPL" switches. The RP20 disks
will also be shut off by this procedure, but they should come back on
also. If everything fails, you should call field service.
When the "ENTER/DISPLAY" switch is positioned to either "CHK1" or
"CHK2", and the LED display has any of the bits "0" through "15" lit,
this indicates a malfunction in the controller, and field service should
be called to fix it.
The 8000 controller must be tailored to your disk configuration. Before
any change is made to the number of disks connected to the controller,
the microcode must be rewritten by field service to take into account
the changes. Otherwise, new disks will not be seen, and UDBs will still
be built for nonexistent disks. Therefore if there is ever a problem
where new disks are not seen by the system, suspect that the microcode
was not rebuilt to handle the new disks.
The 8000 controller has a unit number associated with it, which is
selected by microswitches inside the unit. Field service should set the
controller number to the proper value depending on whether or not the
disks the 8000 controls are to be dual ported or single ported. If the
disks are single ported, the controller number should be 0. If dual
ported, then the two 8000 controllers which connect to the same dual
ported disks should have the same number greater than 0. Every pair of
dual ported controllers has to have a different number. This is because
the monitor uses the drive unit numbers to determine how dual porting is
set up, and the controller number is the high order four bits of each
drive's unit number.
Page 9
The RP20 disks
--------------
Each RP20 disk comes in a box which contains two spindles. Even though
the two disk spindles are contained in one box, they are distinct. That
is, each spindle is a separate disk drive as far as the monitor is
concerned. The two spindles have different unit numbers, and can belong
to different structure if desired. (However, it is obviously a good
idea to not split two pack structures across two RP20 units. There is
more reliability in staying within one RP20 drive).
There are two kinds of RP20 drives. There are the "A" units, and the
"B" units. The "A" units contain power supplies and maintenance
controls which the "B" units do not contain. There must be at least one
"A" unit for each three "B" units, since the "B" units get their power
from the "A" unit. However, to the monitor there is no difference
between these two kind of units, they act identically as far as I/O is
concerned.
The "A" units contain a couple of power switches in the leftmost door of
the unit. These power switches control power to that unit and all "B"
units using that "A" unit as their power supply. Throwing the switch to
the "OFF" position will power down the drives. Throwing the switch to
the "ENABLE" position will allow the drives to be powered up, but does
not actually power them up. You have to hit the "POWER ON" switch to
actually power the drives on. The "POWER ON" switch becomes lit when
the power is on.
Each RP20 spindle has a set of switches which control that unit, and an
indicator saying whether or not the unit is ready. The switches are as
follows. The switch labeled "START" and "STOP" is used to spin the pack
up and down. When the switch the in the "STOP" position, the disk
becomes off-line and stops rotating. (However, the fans continue to
run). When the switch is in the "START" position, the disk spins back
up and comes on-line if possible.
The on-line state is indicated by the green "READY" indicator being lit.
This indicator will flash whenever a positioning operation is done for
the unit, and is therefore a sort of "busy" indicator saying that the
drive is being used currently. However, notice that the transfer itself
does not make the light flash, only the positioning operations. So I/O
can be occurring and you could not tell by examining the light. This
light is not a switch, so pushing on it does nothing.
The switch labeled "ATTN" is used to cause an asychronous interrupt for
that drive. This is used to inform the monitor that a drive is
available for use. If the drive was powered up while the monitor is
running, hitting this switch should not be necessary, since the drive
will give asychronous status by itself when it comes on-line. However,
under certain circumstances it will be necessary to hit the "ATTN"
switch before the monitor will acknowledge that the drive is on-line.
In particular, if the drives were already on-line, but the DX20
microcode was not running when the monitor was loaded, then this switch
would have to be hit for each drive before the monitor knew about their
Page 10
existance. This switch should NOT be used indiscriminately, since
hitting this switch while a transfer is in progress can cause problems.
Only use the switch when the unit is known to be idle.
The switch labeled "R/W" and "READ" is used to write-protect the drive.
The normal position is the "R/W" position, which allows data to be
written to the drive. When in the "READ" position, nothing can be
written to the drive. You should not write-protect drives which the
monitor is using, since it is necessary that the monitor be able to
write to disks. (You would use the "READ" position when diagnostics are
being run on the system, for example, not during timesharing.) If the
monitor complains about "XWBERR" BUGCHKs (Index block write errors), it
is possible that one of the disks was left write-protected.
The final switches for each drive are the "DUAL PORT" switches, one of
which is the "X INTERFACE" switch and one of which is the "Y INTERFACE"
switch. These control whether or not the unit can be accessed from the
two controllers it could be connected to. One switch controls the first
port, and the other switch controls the second one. The "ENABLE"
position allows access by the port, and the "DISABLE" disallows it.
NOTE
Currently these switches have no function.
I don't know if they will ever work. It
depends on what the hardware guys can do
to make them work.
Page 11
Configuration Rules
-------------------
1. No RP20 pack can be a PS: structure. No RP20 pack can be read
by the front end. Swapping is not possible on an RP20.
2. Therefore the must be an RP06 (or RP04) drive in addition to
RP20s so that PS: can be on it. This also allows the KLAD
packs to be used by field service.
3. BOOT is not able to load monitors, or write dumps to an RP20.
This is because BOOT has no code to use RP20 disks.
4. Tapes must exist for backup. Since the RP20 has a great amount
of data, it is recommended that a 6250 BPI tape drive exist to
make backups easier. A TU45 is not acceptable!
5. No other kind of device should be connected to a channel which
is controlling disk style DX20s. This is for performance
reasons, and also such a configuration has never been tried.
6. Each channel can control eight DX20s for controlling disks.
However, as the number of DX20s goes up, performance gets worse
since the channel cannot talk to all DX20s at once. It is
recommended that each DX20 have its own channel.
7. Each DX20 can control only one 8000 controller.
8. If the disks are to be single ported, then the 8000 controller
should have its unit number be set to zero. This is not a
fixed requirement, however, as long as there is no possibility
that the disks will ever be dual ported.
9. If the disks are to be dual ported, then the two involved 8000
controllers MUST have the same unit number, and that number
must be nonzero. (This is not the same unit number as the RH20
unit number, it is an internal number to the 8000 controller).
10. Each set of dual ported disks must have a different unit
number, so that the different combinations of dual ported disks
can be distinguished.
11. For dual porting, each of the access paths should be through
separate channels, otherwise all performance and reliability
improvements are wasted.
12. The monitor will not do dynamic dual porting with RP20 disks.
(That is, it will not be able to initiate I/O requests and
receive interrupts by way of two different paths for a single
disk). What the monitor will do is to spread the load at
initialization time, so that some disks will be accessed by one
path, and the remainder of the disks will be accessed by the
other path.
Page 12
13. If the access path to a disk fails, the monitor will not be
able to use the other access path to access a disk which is
dual ported. However, on a system reload the alternate path
will be used and the disk will be useable again.
14. For single porting, each 8000 controller can control up to four
RP20 boxes. That is, eight spindles. Of these, at least one
of the RP20s must be an "A" type unit.
15. For dual porting, two 8000 controllers can share between them
up to eight RP20 boxes. That is sixteen spindles. Of these,
at least two of the RP20s must be "A" type units, and each
controller must be connected to one of these.
16. The two ports of a disk must be set to be the same unit number,
so that to the monitor both paths to a disk unit appear to have
the same unit number.
17. Shared disks between systems is not possible at the same time.
If the two ports of a disk go to separate systems at the same
time, file damage WILL OCCUR. You have to dismount the disk
from system A, make the disk offline on that port, make the
disk online on the second port, then mount the disk on system
B.
18. A single RP20 spindle holds 201420 pages of storage. A
structure can only be built from three RP20 spindles, therefore
the largest structure can only have 604260 pages. This limit
occurs because of space limitations in CHECKD. However, it is
recommended that the largest structure only use two packs, so
that backups and restorations do not take too long.
19. There is no way that RP20s can be used for 2020s. They require
the RH20 controller.