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


     This  is  a  functional  specification  which  describes  the  work
performed for TOPS-20 to add support for the RP20 disk subsystem.


     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.


     There are many changes necessary to use the RP20 disk  in  TOPS-20.
The following is a simple outline of these 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


             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


     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.


        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

        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.


        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 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:



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

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

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

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.


               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

    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.