1
0
mirror of https://github.com/PDP-10/its.git synced 2026-01-13 15:27:28 +00:00
PDP-10.its/doc/build.info
2016-10-31 08:41:05 +01:00

85 lines
3.9 KiB
Plaintext

How to build a bootable NSALV tape for ITS on a KS10 with one RM80:
Write the following to a tape using dd and mt or whatever. All files have
2560-byte records (in TM03 format, the KS will see them as 512 words).
Rumors of PDP-10s using all 9 tracks as data tracks are utterly false, that
would be stupid. You can write the tapes on any machine that can write
unlabeled 1600bpi tapes with 8-bit data. I used an IBM ES/9000 running MTS,
about as far from the 10 as you can get!
ram.262 (ITS microcode)
<tape mark>
mtboot.bin (boot block)
@.ddt (standalone DDT)
salv.rm80 (NSALV built for RM80)
<2 tape marks> cosmetic, not used but this way the tape is easily copied
using any machine you have handy since 2 tape marks
traditionally mean "end of tape"
Building the DSKDMP tape is the same but substitute dskdmp.rm80 for salv.rm80.
This directory also contains the other versions of DSKDMP and [N]SALV from
the MINSYS; directory, converted to TM03 magtape format, but since all I
have that works is an RM80 I haven't tested the others so I don't know for
sure that the files aren't mangled and I don't know whether the patch given
below is required for those versions of MARK to work. If you know, tell me!
DSKDMP and NSALV tapes will help you build a blank disk but you'll still need
to make DUMP tapes of the MINSYS files if you want to load ITS, and you'll
need a lot more files to run and/or rebuild a real system. Writing DUMP tapes
from a non-ITS machine isn't too difficult, send me email and I'll give you
my code.
*** NOTE ***
As distributed there is a bug in the salvager, which needs to be patched before
you run MARK. Here's what to do (user input shown in lower case):
KS10>mt <cr>
KS10>USR MOD
ITS MTBOOT.176
qcnvt/' MOVSI B,-1 <lf>
QCNVT+1/ CAMN A,QTRAN(B) came a,qtran(b) <cr>
mark<esc>g
Format pack on unit #
... and so on, from here on out it's just like what BUILD DOC says.
Note that the distributed ITS 1644 binaries are built with the tape RH11 at a
non-standard address, and the system will crash if you try to run DUMP w/o
either moving the RH11 or reassembling a new system with the addr fixed.
So either edit SYSTEM; TM03S DEFS4 to change %TMBAS back to 772440 (instead
of 772400), or just delete the file since SYSTEM; TM03S DEFS3 has it right, and
reassemble the system.
IMPORTANT STUFF THAT APPARENTLY NOT EVERYONE KNOWS:
Before you go borrowing peripherals off of a VAX or PDP-11, you need to make
sure that your tape drive has the "universal data formatter" board (also known
as the "universal bit fiddler"), since otherwise it won't support 36-bit words
(packed into 5 tape frames each with 4 wasted bits) and you will lose. In
the TM03 formatter this board is M8915-YA, and it's quite rare since VAXen
don't need it.
You *can* use VAX Massbus disks with the KS since they all support 18-bit mode
and MARK handles the reformatting (rumors of needing an HDA swap are greatly
exaggerated), but with RM drives (including the RM80) you need to add a jumper
or else 18-bit operation will not work correctly. This jumper must connect
pins E06E1 and E06C2 on the RM Adapter backplane, which is the card cage that
goes under the drive in an RM02/03/80 or next to the drive in an RM05.
THIS IS NOT OPTIONAL!
The RH11s used in the KS10 are not quite vanilla either (naturally), the M7294
board used in the RH11-AB (used in some PDP-11s and VAXen) is replaced by an
M7294-YA in the RH11C (used in the KS). I'm fairly sure that all the other
parts interchange though so feel free to gut your VAX for spares.
DRIVES OTHER THAN THE RM80:
RM80s are all I have that works, so I have no way to test the other versions
of the "dskdmp.*" and "salv.*" files in this directory, so I don't know if
the bug in "MARK" is fixed in them. Give it a try... Anyway otherwise the
instructions for making the tapes are the same as for the RM80 versions, as
far as I know RP06 drives need no jumper changes but the RM drives do.
John Wilson <wilson@dbit.dbit.com> 31-Jan-1995