23 Nov
2003
23 Nov
'03
5:46 a.m.
Last week I got the system unit and the tape drive mounted in the rack,
and yesterday, I managed to mount the Fujitsu Eagle. Now I'm trying to
figure out how to hook it all up...
I have been tinkering with it this morning, and finally, about a half
hour ago, I was able to see some activity. I found the information on
the serial board in a handbook, set the terminal for the proper baud
rate, etc, and connected it to channel 3 of the card. Powering it up
gives me the @ prompt. So far, the only things in the machine are the
CPU, the serial card, a 1mb memory board, and an Emulex tape
controller. Now that I have gotten it to do something, I'm totally
lost. I've never worked on a machine like this before. I don't even
know how to type in the boot program. I have a tape boot program here,
on a piece of paper, but I don't know how to type in the values. I've
tried all sorts of commands, all of which yield a ?. Typing P seems to
step the processor through something, as it prints 000002, and then
typing P again increments that value. G prints 177777, and the LED on
the tape controller lights briefly. Same thing if I toggle the boot
switch. I tried loading a tape into the drive and putting it online,
but I get no drive activity when I toggle the boot switch.
So, can anyone offer hints or suggestions as to what I should do next?
I'm lost...
Thanks!
Ian Primus
ian_primus(a)yahoo.com
23 Nov
23 Nov
6:45 a.m.
On 2003.11.23 17:46 Ian Primus wrote:
Powering it up gives me the @ prompt.
This is
the ODT Prompt. Unfortunately I have never found a good
documentation about ODT commands. Maybe someone else can help with this?
What CPU card do you have? There is a /73 CPU card, M8192 IIRC, that has
no ROM. If you have a M8190 (?) it has ROMs. You should be able to set
some jumper on that card so that the CPU jumps into the ROM on reset /
power up.
So far, the only things in the machine are the CPU,
the
serial card, a 1mb memory board, and an Emulex tape controller.
What disk
controller do you have for the Eagle?
I don't even know how to type in the boot program.
I have two minicom scripts that load a MSCP resp. TMSCP bootstrap into
memory. I used them to install / load 2.11BSD UNIX on my /73. Depending
on your disk and tape controller, the controller may have it's own boot
ROM.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
9:26 a.m.
Powering it up
gives me the @ prompt.
This is the ODT Prompt. Unfortunately I have never found a
good
documentation about ODT commands. Maybe someone else can help with
this? 
7:10 a.m.
Guaranteed there is someone on the list that is an active
11/73 user. I want to be one, but I'm not there yet.
Powering it up gives me the @ prompt.
Look for your KDJ11 manual**, chapter 3, for ODT. That's
the lanuage thats expected over your serial line (Working?
Congratulatations! BTW).
I have a tape boot program here, on a piece of paper,
but I don't know how to type in the values.
What does it look like? Numbers, Mnemonics? How many lines?
Also look around for any ROMS not on the SMD,Pertec controllers.
These could contain a bootstrap you can activate. Write down any
information that may be pasted on these ROMs. It's also possible
the controllers' ROMS can start a CPU bootstrap directly too.
In any case, Your supplier, Wayne was a turn-key systems VAR
(value added reseller). I would almost expect your system to be
a turn-key one right now.
Last weekend was a big breakthrough. In less that 24 hours you
amassed a total system that I have spent many weeks over a
period of many years collecting. Wow! Another BTW, these
systems used to be sold for $85,000 each!
John A.
** A copy here too, but you should already have the paper one.
http://bitsavers.org/pdf/dec/pdp11/KDJ11-A_UsersManual.pdf
7:56 a.m.
On Sunday, November 23, 2003, at 01:10 PM, John Allain wrote:
Here is the boot program I'm trying to use:
Memory Location Content Macro Instructions
--------------- ------- ------------------
2000 5000 Start: CLR R0
2002 5300 5$: DEC R0
2004 1376 BME 5$
2006 12706 MOV #1070,SP
2010 1070
2012 12701 MOV #172522,R1
2014 172522
2016 12702 MOV #100001,R2
2020 100001
2022 10211 MOV R2,(R1)
2024 10211 MOV R2,(R1)
2026 22711 10$: CMP #122204,(R1)
2030 122204
2032 01375 BNE 10$
2034 12704 MOV #MESS+20.R4
2036 2062
2040 05007 CLR PC
2042 46523 MESS: .WORD 46523
00001 .END
I am not even sure that this is meant for this particular computer, or
this tape controller. I also am confused by the last command, since it
doesn't have a memory location. Thanks to some help from Fred N. van
Kempen, I was able to type it in (I have to type <memory
location>/<contents> - before I was trying to type them in separated by
a space). After I typed in the program, I typed 2000G, and it just
hung, the RUN light on. Pressing Break on the terminal stopped it, and
it printed 2026 on the screen. While the program is running, the LED on
the tape controller is lit, but the tape drive doesn't spin or do
anything. (And yes, I do have a bootable tape loaded, and the tape
drive set to online). I don't know for sure that I have the tape drive
connected right though.
Guaranteed there is someone on the list that is an
active
11/73 user. I want to be one, but I'm not there yet.
Thanks. It was really cool to see that prompt... I had been trying to
plug the terminal into channel 0 on the card, figuring that the console
would need to be on the first port, but then I found the information in
the interfaces handbook, and found that it needed to be on channel 3,
and I also was able to read the wire jumpers, and figure out how the
board was configured.
Powering it up gives me the @ prompt.
Look for your KDJ11 manual**, chapter 3, for ODT. That's
the lanuage thats expected over your serial line (Working?
Congratulatations! BTW). I have a tape boot program here, on a piece of
paper,
but I don't know how to type in the values.
What does it look like? Numbers, Mnemonics? How many lines?
Also look around for any ROMS not on the SMD,Pertec
controllers.
These could contain a bootstrap you can activate. Write down any
information that may be pasted on these ROMs. It's also possible
the controllers' ROMS can start a CPU bootstrap directly too.
In any case, Your supplier, Wayne was a turn-key systems VAR
(value added reseller). I would almost expect your system to be
a turn-key one right now.
If I don't type the program in, and just turn on the system and flip
the Boot switch, the LED on the tape controller flashes briefly. I
don't see any ROMS, there is an empty socket on the CPU card where a
ROM might be able to go, and the ROMS on the tape controller are
factory made (not EPROMS that may have been added later) Maybe I should
install the hard disk controller? Right now it just has the CPU card,
serial card, RAM card and the tape controller in it. What other
configurations do I need to do to get it to recognize the drive
controller? From what I have been able to tell, in the PDP-11, the
order of the cards matters, and their addresses need to be set
manually, right? How to do this, I'm not sure.
Last weekend was a big breakthrough. In less that 24 hours you
amassed a total system that I have spent many weeks over a
period of many years collecting. Wow! Another BTW, these
systems used to be sold for $85,000 each!
Yeah, I really love this system, and I'm really glad I was able to get
it. I've got a lot to learn about it, but I'm really looking forward to
getting it booting and running something. I haven't decided what OS I
want to run on this thing though, I have the boot tape for RSX, but it
should also be able to run RT11 and UNIX. Any others? What other
software is available?
Thanks!
Ian Primus
ian_primus(a)yahoo.com
8:18 a.m.
From what I have been able to tell, in the PDP-11,
the
order of the cards matters, and their addresses need
to be set manually, right? How to do this, I'm not sure.
Wasn't this system preconfigured when you got it?
That would say to me that it was likely already 90-99%
ready.
At any rate it will be useful to record the card and slot
location info for your system for later.
I don't know for sure that I have the tape drive
connected
right though.
The cables are labelled P1 and P2. Locate the pin 1 point
on the source, cable and destination and line 'em all up,
once for each cable.
Here is the boot program I'm trying to use:
Might be useful but more likely with this system is that it
would boot by loading just one address first, just my hunch
for now.
John A.
8:40 a.m.
On Sunday, November 23, 2003, at 02:18 PM, John Allain wrote:
Well, yes and no. The machine had a CPU card, serial card and RAM in
it, but nothing else. And I didn't know how the serial card was
configured. Now I have figured out how the serial card works, but I am
trying to get the machine to boot off tape. I haven't even begun to
think about hooking up the hard drive yet.
I'm assuming that P1 and P2 would go to J1 and J2 respectively, right?
That's what I don't know. I've got pin 1's matched up, but I don't
know
for sure if the tape controller and tape drive have their connectors
numbered the same way. With my luck, they won't be...
Yeah, you're probably right. I'll have to look at the hardware some
more and post more information.
Ian Primus
ian_primus(a)yahoo.com
From what I
have been able to tell, in the PDP-11, the
order of the cards matters, and their addresses need
to be set manually, right? How to do this, I'm not sure.
Wasn't this system preconfigured when you got it?
That would say to me that it was likely already 90-99%
ready.
At any rate it will be useful to record the card and slot
location info for your system for later. I don't know for sure that I have the tape
drive connected
right though.
The cables are labelled P1 and P2. Locate the pin 1 point
on the source, cable and destination and line 'em all up,
once for each cable. Here is the
boot program I'm trying to use:
Might be useful but more likely with this system is that it
would boot by loading just one address first, just my hunch
for now.
8:33 a.m.
Here is the boot program I'm trying to use:
Memory Location Content Macro Instructions
--------------- ------- ------------------
2000 5000 Start: CLR R0
2002 5300 5$: DEC R0
2004 1376 BME 5$
2006 12706 MOV #1070,SP
2010 1070
2012 12701 MOV #172522,R1
2014 172522
2016 12702 MOV #100001,R2
2020 100001
2022 10211 MOV R2,(R1)
2024 10211 MOV R2,(R1)
2026 22711 10$: CMP #122204,(R1)
2030 122204
2032 01375 BNE 10$
2034 12704 MOV #MESS+20.R4
2036 2062
2040 05007 CLR PC
2042 46523 MESS: .WORD 46523
00001 .END
Well, except for s/BME/BNE/ on the third line (address 2004) and
s/.R4/,R4/ on the twelfth (address 2034), this looks not entirely
unreasonable. With those fixes, and changing the labels, the contents
given match what my assembler produces for that code (except for the
.end line; I don't know why your listing shows a value there). (I had
to change the labels because my assembler doesn't accept labels
beginning with a digit, and it was easier to change the labels than to
change the assembler.)
After I typed in the program, I typed 2000G, and it
just hung, the
RUN light on. Pressing Break on the terminal stopped it, and it
printed 2026 on the screen.
So it had sent the command to the tape but was sitting in the spin loop
at locations 2026 and 2032, waiting for the ack.
Given how small this is, and the control structure of the code, it
appears to be expecting the device at 172552 to DMA some boot code into
low memory; when this is done, as signaled by finding 122204 in what I
assume is the device's CSR, it jumps to it with the CLR PC.
I don't see any ROMS, there is an empty socket on
the CPU card where
a ROM might be able to go, and the ROMS on the tape controller are
factory made (not EPROMS that may have been added later)
It might be instructive to clear low memory first, then run the above
code, and see if low memory has changed.
For example,
001764 012700 b: mov #b,r0
001766 001764
001770 012701 mov #b/2,r1
001772 000772
001774 005040 x: clr -(r0)
001776 077102 sob r1,x
the rest of the code as above, and then use 1764G. When you break it,
examine low memory (type 0/ and just hit return a bunch of times). If
low memory isn't all 0, _something_ has changed it, and if you send me
the contents (a capture of the output when you hit return until you
find a bunch of all-0 memory locations) I can disassemble it for you.
Not that that will _necessarily_ help, but if the disassembly makes
sense, there is an excellent chance the hardware is connected
correctly.
From what I have been able to tell, in the PDP-11, the
order of the
cards matters, and their addresses need to be set manually, right?
How to do this, I'm not sure.
Order of cards matters in two ways: (1) the bus slots have chained
signals, and if you have any empty slots between the CPU and the last
card, you need to put jumper cards in them to pass along the chained
signals; and (2) card order determines priority for something - I
forget whether it's equal-priority interrupts or DMA bus grants or
what, but you want the cards for which timing is most important to be
closest to the CPU.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3:21 p.m.
Well, except for s/BME/BNE/ on the third line (address
2004) and
s/.R4/,R4/ on the twelfth (address 2034), this looks not entirely
unreasonable.
Hehe... oops... typo's. Sorry about that. I typed that in by hand, and
I must have made a couple futz keystrokes.
So it had sent the command to the tape but was sitting
in the spin loop
at locations 2026 and 2032, waiting for the ack.
Given how small this is, and the control structure of the code, it
appears to be expecting the device at 172552 to DMA some boot code into
low memory; when this is done, as signaled by finding 122204 in what I
assume is the device's CSR, it jumps to it with the CLR PC.
I checked my connections again, and lo and behold, I had the tape drive
cables reversed. The pin 1 markings on the back of the drive threw me
off, since the connectors are so close together, I got the labels mixed
up and was reading the pin 1 from the adjacent connector, thus both
connectors were rotated 180 degrees. I swapped them, and typed in the
program again. I the typed 2000g, and the tape drive started to whir!
It seeked back and forth in tiny and equal increments. Then, the drive
stopped and 012710 was displayed, then the @ prompt. I typed g, and got
: *** THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM ***. It
still didn't boot, but at least it's doing something! (Lesson for
today, never connect hardware while tired, and always use a flashlight
to see behind racks.)
It might be instructive to clear low memory first,
then run the above
code, and see if low memory has changed.
For example,
001764 012700 b: mov #b,r0
001766 001764
001770 012701 mov #b/2,r1
001772 000772
001774 005040 x: clr -(r0)
001776 077102 sob r1,x
the rest of the code as above, and then use 1764G. When you break it,
examine low memory (type 0/ and just hit return a bunch of times). If
low memory isn't all 0, _something_ has changed it, and if you send me
the contents (a capture of the output when you hit return until you
find a bunch of all-0 memory locations) I can disassemble it for you.
Not that that will _necessarily_ help, but if the disassembly makes
sense, there is an excellent chance the hardware is connected
correctly.
I might end up doing that, I can write down the output, and email it to
you. Right now though, it looks like the program _is_ running, it's
just not clear what it's looking for on the tape. I was told that the
tapes I have are bootable, so I must be doing something else wrong.
Either that, or all three tapes I tried have gone bad.
I have two blank tapes, as well as the SCSI nine track tape drive that
goes with my Prime. I should be able to connect the other tape drive to
a PC, and dd a tape image to a real tape. Is there a known working,
bootable tape image out there on the 'net that I could use to test?
I've been looking around, and so far I've found only a couple, and I'm
not sure that they would work on my machine. I found a couple different
places that had BSD 2.11, one of which had it as one tape image,
another had it as three. I only have two tapes, so installing from
three would be a pain (write first two, install one, install two while
rewriting one into three, install three, then scream when installer
asks for one again...)
Ian Primus
ian_primus(a)yahoo.com
10:46 p.m.
On Sun, 23 Nov 2003, Ian Primus wrote:
connectors were rotated 180 degrees. I swapped them,
and typed in the
program again. I the typed 2000g, and the tape drive started to whir!
It seeked back and forth in tiny and equal increments. Then, the drive
stopped and 012710 was displayed, then the @ prompt. I typed g, and got
: *** THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM ***. It
still didn't boot, but at least it's doing something! (Lesson for
today, never connect hardware while tired, and always use a flashlight
to see behind racks.)
OK, this means (a) the tape boot works, (b) the machine is
basically
OK, and (c) the tape connection is OK (now). Progress!
Since the "*** THIS VOLUME" ... comes from the boot loader (it is not
in the bootstrap program...) on tape, we *did* load something from it.
Dunno which tape you are using, but: the address the boot loader uses
is that of the TM11/TS11. The instruction (100001) it sends to the
controller doesn't match that of the TM11, so it must be the TS11 it
thinks it has- and this is quite often the case with Emulex and Dilog
controllers.
Even though we were able to load the secondary bootstrap off tape (which
is blocks 0 and/or 1 on tape), we **ALSO** need to have that code know
what we're loading from.
Suppose... we load the secondary boot. But: that thinks we're using a
TM11 controller. It then tries to load the rest off tape... but barfs,
because the TM11 doesnt respond (since it's really a TS11.) ... error..
> It might be instructive to clear low memory
first, then run the above
> code, and see if low memory has changed.
I bet you'll find the above
message in there, since that was loaded
to PC=0. Either the tape is a "ANSI standard" tape of some kind (with
valid boot blocks, but no bootable system) or it is a regular bootable
tape, but with a boot block for TM11 controllers...
I might end up doing that, I can write down the
output, and email it to
you.
Use a terminal program on a PC or other system, and just log the
sessions. Much easier :)
I have two blank tapes, as well as the SCSI nine track
tape drive that
goes with my Prime. I should be able to connect the other tape drive to
a PC, and dd a tape image to a real tape. Is there a known working,
bootable tape image out there on the 'net that I could use to test?
Sure,
whatcha want? I can send you the Ultrix-11 mini root, which is
very small, and which will tell you whether things work or not..
Fred
--
Fred N. van Kempen, DEC (Digital Equipment Corporation) Collector/Archivist
Visit the VAXlab Project at http://www.pdp11.nl/VAXlab/
Visit the Archives at http://www.pdp11.nl/
Email: waltje(a)pdp11.nl BUSSUM, THE NETHERLANDS / Sunnyvale, CA, USA
11:35 p.m.
[...], and the
tape drive started to whir! It seeked back and forth
in tiny and equal increments. Then, the drive stopped and 012710
was displayed, then the @ prompt. I typed g, and got:
*** THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM ***.
OK, this means
(a) the tape boot works, (b) the machine is basically
OK, and (c) the tape connection is OK (now). Progress! Since the "*** THIS VOLUME" ... comes from
the boot loader (it is not
in the bootstrap program...) on tape, we *did* load something from
it.
Not quite. It comes from the boot loader obtained somehow from the
tape interface. We do not know whether the controller got it from ROM
on the controller, from ROM on the drive, or from stuff read off the
tape. My guess would be it's part of the code DMAed into low memory
(from ROM somewhere), not part of something read from the tape, simply
because it makes sense for there to be a complaint in case someone
tries to boot from a totally garbage tape, and this message looks very
much like what I'd expect that complaint to be.
Even though we were able to load the secondary
bootstrap off tape
(which is blocks 0 and/or 1 on tape), we **ALSO** need to have that
code know what we're loading from.
Yes...except that we don't actually know we loaded anything off the
tape (see above).
Either the tape is a "ANSI standard" tape of
some kind (with valid
boot blocks, but no bootable system) or it is a regular bootable
tape, but with a boot block for TM11 controllers...
Or it's a nonbootable tape, and the message came from the ROMed boot
code DMAed into low core.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
24 Nov
24 Nov
4:11 a.m.
der Mouse wrote:
Yes! This is very encouraging.
Or the heads on the tape drive are dirty. Look at them, and try
cleaning them with a good quality alcohol.
[...], and the tape drive started to whir! It seeked
back and forth
in tiny and equal increments. Then, the drive stopped and 012710
was displayed, then the @ prompt. I typed g, and got:
*** THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM ***.
OK, this means (a) the tape boot works, (b) the machine is basically
OK, and (c) the tape connection is OK (now). Progress!
Since the "*** THIS VOLUME" ... comes
from the boot loader (it is not
in the bootstrap program...) on tape, we *did* load something from
it.
Not quite. It comes from the boot loader obtained somehow from the
tape interface. We do not know whether the controller got it from ROM
on the controller, from ROM on the drive, or from stuff read off the
tape. My guess would be it's part of the code DMAed into low memory
(from ROM somewhere), not part of something read from the tape, simply
because it makes sense for there to be a complaint in case someone
tries to boot from a totally garbage tape, and this message looks very
much like what I'd expect that complaint to be.
Even though we were able to load the secondary
bootstrap off tape
(which is blocks 0 and/or 1 on tape), we **ALSO** need to have that
code know what we're loading from.
Yes...except that we don't actually know we loaded anything off the
tape (see above).
Either the tape is a "ANSI standard"
tape of some kind (with valid
boot blocks, but no bootable system) or it is a regular bootable
tape, but with a boot block for TM11 controllers...
Or it's a nonbootable tape, and the message came from the ROMed boot
code DMAed into low core.
6:26 a.m.
Ian,
The message is - to my knowledge - contained in boot blocks of RSX
volumes that are not meant to be bootable. There is a simple routine
instead of the secondary bootstrap that only outputs the string and then
halts. It's kind of a grounding wire to make sure you won't boot off a
tape that contains just user data in place of system files, and hence
might produce unpredictable results. Nevertheless, this is proof that
you managed to read the tape.
You may want to look for a tape that is labelled "Standalone BRU" or
"BRU64K": it should contain a variant of the "Backup / Restore
Utility"
that works independently of the operating system and is bootable on its
own (actually, a specialized RSX system with pre-loaded BRU task). You
boot this tape, unload, then mount the actual data tape (one of those
you tried), and do the actual restore. This is how you would start a
SYSGEN (SYStem GENeration) after receiving a tape kit from Digital.
If you have a lot of time to wait, I might provide a Standalone BRU tape
(1600bpi only, I use a TS05!), but I'm afraid I'll have no time for my
PDP-11 before Christmas. Certainly, other list members can also do so.
But then, where will you copy the contents of the tape if your disk is
not yet connected? - Maybe trying to boot off disk is a better next step?
Regards,
Andreas
der Mouse wrote:
Yes! This is very encouraging.
--
Andreas Freiherr
Vishay Semiconductor GmbH, Heilbronn, Germany
http://www.vishay.com
[...], and the tape drive started to whir! It seeked
back and forth
in tiny and equal increments. Then, the drive stopped and 012710
was displayed, then the @ prompt. I typed g, and got:
*** THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM ***.
OK, this means (a) the tape boot works, (b) the machine is basically
OK, and (c) the tape connection is OK (now). Progress! Since the "*** THIS VOLUME" ... comes
from the boot loader (it is not
in the bootstrap program...) on tape, we *did* load something from
it.
Not quite. It comes from the boot loader obtained somehow from the
tape interface. We do not know whether the controller got it from ROM
on the controller, from ROM on the drive, or from stuff read off the
tape. My guess would be it's part of the code DMAed into low memory
(from ROM somewhere), not part of something read from the tape, simply
because it makes sense for there to be a complaint in case someone
tries to boot from a totally garbage tape, and this message looks very
much like what I'd expect that complaint to be.
Even though we were able to load the secondary
bootstrap off tape
(which is blocks 0 and/or 1 on tape), we **ALSO** need to have that
code know what we're loading from.
Yes...except that we don't actually know we loaded anything off the
tape (see above).
Either the tape is a "ANSI standard"
tape of some kind (with valid
boot blocks, but no bootable system) or it is a regular bootable
tape, but with a boot block for TM11 controllers...
Or it's a nonbootable tape, and the message came from the ROMed boot
code DMAed into low core.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
1:18 a.m.
On Monday, November 24, 2003, at 04:46 AM, Fred N. van Kempen wrote:
Good point... Right now I'm using a Lear Siegler
ADM3A :)
Yeah, that would
be great. Is there anything special I have to do when
I write the tape to make sure the PDP-11 can read it? Since the tape
drives are different (the PDP-11 one is Pertec, the Prime one is SCSI),
will the tapes be compatible? It sounds like tapes written with two
slightly different Pertec controllers on the PDP-11 aren't compatible.
Ian Primus
ian_primus(a)yahoo.com
Since the "*** THIS VOLUME" ... comes from the boot loader (it is not
in the bootstrap program...) on tape, we *did* load something from it.
OK, that's good, I was worried that the tape drive might be damaged, or
have dirty heads or something.
Dunno which tape you are using, but: the address the
boot loader uses
is that of the TM11/TS11. The instruction (100001) it sends to the
controller doesn't match that of the TM11, so it must be the TS11 it
thinks it has- and this is quite often the case with Emulex and Dilog
controllers.
I tried three different tapes, two of which are the same thing. One
tape is a homemade system tape, on an ten inch reel. The label is
handwritten in pencil and hard to read. It says "RSX-11-M-Plus V4.0
Operating system for Eagle (DB2, omitting software directories) VMR'd
for extra pool space <something I can't read>, needs DTR files
[1,2],<something else I can't read>" The other tape is an official
Digital tape on a 12 inch reel. The label says "BB-JO81J-BC
RSX-11M-LUS V4.4 BRU MT:1/1 ID:RSX11MPBL78 DIST 1600BPI COPYRIGHT
1993 DIGITAL EQUIPMENT CORPORATION MB0804". I don't know what
controller these were written for, or how my Emulex card is set up.
I'll have to read through the Emulex manual some more.
Even though we were able to load the secondary
bootstrap off tape
(which
is blocks 0 and/or 1 on tape), we **ALSO** need to have that code know
what we're loading from.
Are these leading blocks written in the same format or
a different
format as the rest of the tape? What about density? I'll have to look
up in the manual, but I _think_ the default on my drive is 1600bpi, but
I'm not positive.
Suppose... we load the secondary boot. But: that
thinks we're using a
TM11 controller. It then tries to load the rest off tape... but barfs,
because the TM11 doesnt respond (since it's really a TS11.) ... error..
What's the difference between the two controllers? Is their tape format
different, or just the headers?
I might end up
doing that, I can write down the output, and email it
to
you.
Use a terminal program on a PC or other system, and just log the
sessions. Much easier :) I have two
blank tapes, as well as the SCSI nine track tape drive that
goes with my Prime. I should be able to connect the other tape drive
to
a PC, and dd a tape image to a real tape. Is there a known working,
bootable tape image out there on the 'net that I could use to test?
Sure,
whatcha want? I can send you the Ultrix-11 mini root, which is
very small, and which will tell you whether things work or not..
5:44 a.m.
On Mon, 24 Nov 2003, Ian Primus wrote:
OK, that's good, I was worried that the tape drive
might be damaged, or
have dirty heads or something.
Well, as was suggested earlier, this COULD come from
the hardware,
but I doubt it. Your hardware (the 11/73) doesnt know this beast,
and you use a manually typed-in boot loader, which only can do one
thing, and that is loading the secondary boot. And that magically
seems to load something, then halts.
Halting usually means "duh, bad karma, can't continue" when at this
level of the system.
Continuing yoields you the bad-volume message, which imho has to be
on the tape. I just checked the image of my RSX11-M-PLUS V4.2
tape, and sure enough, that message is in there, so we *did* load
it off the tape. Our tape unit works :)
I tried three different tapes, two of which are the
same thing. One
tape is a homemade system tape, on an ten inch reel. The label is
handwritten in pencil and hard to read. It says "RSX-11-M-Plus V4.0
Operating system for Eagle (DB2, omitting software directories) VMR'd
for extra pool space <something I can't read>, needs DTR files
[1,2],<something else I can't read>" The other tape is an official
Digital tape on a 12 inch reel. The label says "BB-JO81J-BC
RSX-11M-LUS V4.4 BRU MT:1/1 ID:RSX11MPBL78 DIST 1600BPI COPYRIGHT
1993 DIGITAL EQUIPMENT CORPORATION MB0804". I don't know what
controller these were written for, or how my Emulex card is set up.
I'll have to read through the Emulex manual some more.
Yeah, this might be the
real issue. The DEC tape is for 16MT9, aka
1600bpi 9-track, using TM11 format controllers. It *may* not know
what to do with a TS11, if that is what the Emulex currently "talks".
As said earlier, *we* load the secondary in memory, which seems to
work. Next, we pass control to that code, and that code will then
try to load more stuff off the tape. Since it expects a TM11
controller at that address, it will program for that. And then
the load fails, since the TS11 doesnt respond to the commands
sent to it.... "not bootable" we get shown...
Are these leading blocks written in the same format or
a different
format as the rest of the tape? What about density? I'll have to look
up in the manual, but I _think_ the default on my drive is 1600bpi, but
I'm not positive.
That depends, but yeah, always the same density. Most of the
system
load files are in 512-byte blocks. Here is a list of my V4.2 tape:
TDF version : 1 (OLD)
Flags :
CRC-32 : 0x32b466df
Media code : 9-track 1600bpi
Part # : BB-J083H-BC
Serial Number : ME109856
Tape Label : RSX-11M-PLUS V4.2 MT:1600
Description : BRUSYS STANDALONE COPY SYSTEM
Copyright : 1989
Owner : DIGITAL EQUIPMENT CORPORATION
File 0 : blocksize 512 (439 blocks)
File 1 : blocksize 80 (2 blocks)
File 2 : blocksize 80 (1 blocks)
2 : blocksize 512 (2 blocks)
2 : blocksize 80 (1 blocks)
2 : blocksize 512 (1 blocks)
2 : blocksize 80 (2 blocks)
2 : blocksize 2560 (1 blocks)
2 : blocksize 80 (1 blocks)
2 : blocksize 4144 (28 blocks)
2 : blocksize 560 (1 blocks)
File 3 : blocksize 80 (2 blocks)
File 4 : blocksize 80 (2 blocks)
File 5 : blocksize 80 (1 blocks)
5 : blocksize 512 (2 blocks)
5 : blocksize 80 (1 blocks)
5 : blocksize 512 (1 blocks)
5 : blocksize 80 (2 blocks)
5 : blocksize 4096 (1 blocks)
5 : blocksize 512 (1 blocks)
5 : blocksize 80 (1 blocks)
5 : blocksize 4144 (208 blocks)
5 : blocksize 2608 (1 blocks)
File 6 : blocksize 80 (2 blocks)
File 7 : blocksize 80 (2 blocks)
File 8 : blocksize 80 (1 blocks)
8 : blocksize 512 (2 blocks)
8 : blocksize 80 (1 blocks)
8 : blocksize 512 (1 blocks)
8 : blocksize 80 (2 blocks)
8 : blocksize 4096 (1 blocks)
8 : blocksize 512 (1 blocks)
8 : blocksize 80 (1 blocks)
8 : blocksize 4144 (26 blocks)
8 : blocksize 560 (1 blocks)
File 9 : blocksize 80 (2 blocks)
File 10 : blocksize 80 (2 blocks)
File 11 : blocksize 80 (1 blocks)
11 : blocksize 512 (2 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 512 (1 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 512 (2 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 512 (3 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 512 (1 blocks)
11 : blocksize 80 (2 blocks)
11 : blocksize 1536 (1 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 4096 (4 blocks)
11 : blocksize 3584 (1 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 4096 (8 blocks)
11 : blocksize 1024 (1 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 4096 (3 blocks)
11 : blocksize 2048 (1 blocks)
11 : blocksize 80 (1 blocks)
11 : blocksize 4144 (542 blocks)
11 : blocksize 3632 (1 blocks)
File 12 : blocksize 80 (2 blocks)
File 13 : blocksize 80 (2 blocks)
File 14 : blocksize 80 (1 blocks)
14 : blocksize 512 (2 blocks)
14 : blocksize 80 (1 blocks)
14 : blocksize 512 (2 blocks)
14 : blocksize 80 (2 blocks)
14 : blocksize 4096 (7 blocks)
14 : blocksize 2048 (1 blocks)
14 : blocksize 80 (1 blocks)
14 : blocksize 4144 (107 blocks)
14 : blocksize 3120 (1 blocks)
File 15 : blocksize 80 (2 blocks)
File 16 : blocksize 80 (2 blocks)
File 17 : blocksize 80 (1 blocks)
17 : blocksize 512 (2 blocks)
17 : blocksize 80 (1 blocks)
17 : blocksize 512 (2 blocks)
17 : blocksize 80 (2 blocks)
17 : blocksize 4096 (4 blocks)
17 : blocksize 512 (1 blocks)
17 : blocksize 80 (1 blocks)
17 : blocksize 4144 (129 blocks)
17 : blocksize 1584 (1 blocks)
File 18 : blocksize 80 (2 blocks)
File 19 : blocksize 80 (2 blocks)
File 20 : blocksize 80 (1 blocks)
20 : blocksize 512 (2 blocks)
20 : blocksize 80 (1 blocks)
20 : blocksize 512 (1 blocks)
20 : blocksize 80 (2 blocks)
20 : blocksize 4096 (3 blocks)
20 : blocksize 80 (1 blocks)
20 : blocksize 4144 (49 blocks)
20 : blocksize 2608 (1 blocks)
File 21 : blocksize 80 (2 blocks)
File 22 : blocksize 80 (2 blocks)
File 23 : blocksize 80 (1 blocks)
23 : blocksize 512 (2 blocks)
23 : blocksize 80 (1 blocks)
23 : blocksize 512 (1 blocks)
23 : blocksize 80 (2 blocks)
23 : blocksize 4096 (1 blocks)
23 : blocksize 512 (1 blocks)
23 : blocksize 80 (1 blocks)
23 : blocksize 4144 (26 blocks)
23 : blocksize 3120 (1 blocks)
File 24 : blocksize 80 (2 blocks)
File 25 : blocksize 80 (2 blocks)
File 26 : blocksize 80 (1 blocks)
26 : blocksize 512 (2 blocks)
26 : blocksize 80 (1 blocks)
26 : blocksize 512 (1 blocks)
26 : blocksize 80 (2 blocks)
26 : blocksize 4096 (1 blocks)
26 : blocksize 1536 (1 blocks)
26 : blocksize 80 (1 blocks)
26 : blocksize 4144 (24 blocks)
26 : blocksize 3120 (1 blocks)
File 27 : blocksize 80 (2 blocks)
File 28 : blocksize 80 (2 blocks)
File 29 : blocksize 80 (1 blocks)
29 : blocksize 512 (2 blocks)
29 : blocksize 80 (1 blocks)
29 : blocksize 512 (1 blocks)
29 : blocksize 80 (2 blocks)
29 : blocksize 4096 (1 blocks)
29 : blocksize 1024 (1 blocks)
29 : blocksize 80 (1 blocks)
29 : blocksize 4144 (18 blocks)
29 : blocksize 3120 (1 blocks)
File 30 : blocksize 80 (2 blocks)
File 31 : blocksize 80 (2 blocks)
File 32 : blocksize 80 (1 blocks)
32 : blocksize 512 (2 blocks)
32 : blocksize 80 (1 blocks)
32 : blocksize 512 (1 blocks)
32 : blocksize 80 (2 blocks)
32 : blocksize 4096 (1 blocks)
32 : blocksize 2048 (1 blocks)
32 : blocksize 80 (1 blocks)
32 : blocksize 4144 (80 blocks)
File 33 : blocksize 80 (2 blocks)
File 34 : blocksize 80 (2 blocks)
File 35 : blocksize 80 (1 blocks)
35 : blocksize 512 (2 blocks)
35 : blocksize 80 (1 blocks)
35 : blocksize 512 (1 blocks)
35 : blocksize 80 (1 blocks)
35 : blocksize 512 (1 blocks)
35 : blocksize 80 (2 blocks)
35 : blocksize 1024 (1 blocks)
35 : blocksize 80 (1 blocks)
35 : blocksize 2560 (1 blocks)
35 : blocksize 80 (1 blocks)
35 : blocksize 4144 (67 blocks)
35 : blocksize 3120 (1 blocks)
File 36 : blocksize 80 (2 blocks)
File 37 : blocksize 80 (2 blocks)
File 38 : blocksize 80 (1 blocks)
38 : blocksize 512 (2 blocks)
38 : blocksize 80 (1 blocks)
38 : blocksize 512 (1 blocks)
38 : blocksize 80 (2 blocks)
38 : blocksize 4096 (1 blocks)
38 : blocksize 2560 (1 blocks)
38 : blocksize 80 (1 blocks)
38 : blocksize 4144 (8 blocks)
38 : blocksize 2096 (1 blocks)
File 39 : blocksize 80 (2 blocks)
File 40 : blocksize 80 (2 blocks)
File 41 : blocksize 80 (1 blocks)
41 : blocksize 512 (2 blocks)
41 : blocksize 80 (1 blocks)
41 : blocksize 512 (1 blocks)
41 : blocksize 80 (2 blocks)
41 : blocksize 3584 (1 blocks)
41 : blocksize 80 (1 blocks)
41 : blocksize 4144 (126 blocks)
41 : blocksize 2608 (1 blocks)
File 42 : blocksize 80 (2 blocks)
File 43 : blocksize 80 (2 blocks)
File 44 : blocksize 80 (1 blocks)
44 : blocksize 512 (2 blocks)
44 : blocksize 80 (1 blocks)
44 : blocksize 512 (1 blocks)
44 : blocksize 80 (1 blocks)
44 : blocksize 512 (1 blocks)
44 : blocksize 80 (2 blocks)
44 : blocksize 1024 (1 blocks)
44 : blocksize 80 (1 blocks)
44 : blocksize 1024 (1 blocks)
44 : blocksize 80 (1 blocks)
44 : blocksize 4144 (31 blocks)
44 : blocksize 560 (1 blocks)
File 45 : blocksize 80 (2 blocks)
File 46 : blocksize 80 (2 blocks)
File 47 : blocksize 80 (1 blocks)
47 : blocksize 512 (2 blocks)
47 : blocksize 80 (1 blocks)
47 : blocksize 512 (1 blocks)
47 : blocksize 80 (2 blocks)
47 : blocksize 1536 (1 blocks)
47 : blocksize 80 (1 blocks)
47 : blocksize 4144 (4 blocks)
47 : blocksize 560 (1 blocks)
File 48 : blocksize 80 (2 blocks)
It just occurred to me: you need the BRUSYS tape to boot, not
the distribution kit...
What's the difference between the two controllers?
Is their tape format
different, or just the headers?
Neither, the controller is programmed differently.
Also, I believe
the TM11 could only do low density tapes originally, and the TS11
could do more. For programming, they're not identical, though,
which is why you should be wary of the "mode" of the Emulex.
Good point... Right now I'm using a Lear Siegler
ADM3A :)
*slap* use the Hinote!
Yeah, that would be great. Is there anything special I
have to do when
I write the tape to make sure the PDP-11 can read it? Since the tape
drives are different (the PDP-11 one is Pertec, the Prime one is SCSI),
will the tapes be compatible? It sounds like tapes written with two
slightly different Pertec controllers on the PDP-11 aren't compatible.
Nah,
1600 of 800 bpi, and all look alike at the tape level.
I'll send you the file in private email.
--f
--
Fred N. van Kempen, DEC (Digital Equipment Corporation) Collector/Archivist
Visit the VAXlab Project at http://www.pdp11.nl/VAXlab/
Visit the Archives at http://www.pdp11.nl/
Email: waltje(a)pdp11.nl BUSSUM, THE NETHERLANDS / Sunnyvale, CA, USA
25 Nov
25 Nov
3:42 a.m.
--- "Fred N. van Kempen" <waltje(a)pdp11.nl> wrote:
On Mon, 24 Nov 2003, Ian Primus wrote:
Well, the three tapes I tried must not have been
bootable (or at least not directly bootable) I do have
one more tape, that does seem to be a BRU tape. I
booted it, and it did more. It loaded for longer, then
crashed. Woohoo! It's working well enough to crash! (I
think this is an improvement). When it crashed, it
gave me this:
SYSTEM CRASH AT LOCATION 011336
REGISTERS
R0=000304 R1=172522 R2=063107 R3=172520
R4=000010 R5=000000 SP=117756 PS=000010
SYSTEM STACK DUMP
LOCATION CONTENTS
117756 000004
004412
@
So, it definitely seems to be loading _something_. I
don't know what though. I tried booting this tape
without the hard drive connected, but I don't think it
should matter. I hooked up the hard drive, and tried
to boot off it by toggleing the boot switch or typing
g, but it doesn't seem to work. I must not have a boot
ROM in there that it can read. I haven't tried booting
this tape with the hard drive connected, but I don't
think it should make any difference.
OK, that's good, I was worried that the tape
drive
might be damaged, or
have dirty heads or something.
Well, as
was suggested earlier, this COULD come from
the hardware,
but I doubt it. Your hardware (the 11/73) doesnt
know this beast,
and you use a manually typed-in boot loader, which
only can do one
thing, and that is loading the secondary boot. And
that magically
seems to load something, then halts.
Continuing yoields you the bad-volume message, which
imho has to be
on the tape. I just checked the image of my
RSX11-M-PLUS V4.2
tape, and sure enough, that message is in there, so
we *did* load
it off the tape. Our tape unit works :)
As said earlier, *we* load the secondary in memory,
which seems to
work. Next, we pass control to that code, and that
code will then
try to load more stuff off the tape. Since it
expects a TM11
controller at that address, it will program for
that. And then
the load fails, since the TS11 doesnt respond to the
commands
sent to it.... "not bootable" we get shown...
I don't know off the top of my what model tape
controller I'm using. I'll have to check when I get
back home tonight. I know it's an Emulex, but that
really doesn't help. <grin>
That depends, but yeah, always the same density.
Most of the system
load files are in 512-byte blocks. Here is a list
of my V4.2 tape:
File 0 : blocksize 512 (439 blocks)
OK, so I guess that File 0 is what I'm
currently
reading, correct? Is this the part of the tape that
has that error message in it?
Well, it looks like I'll be trying to write a tape
tonight. I'll have to connect the Prime's SCSI tape
drive to a PC, I should just be able to dd a tape
image to the tape device without any problems, right?
Or will I have to write it in segments, specifying the
block size as I go? I haven't done a lot with tape
formats before. Also, once I figure out which tape
controller I am using, how do I write a compatible
tape from *nix?
Ian Primus
ian_primus(a)yahoo.com
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/
3:53 a.m.
On Tue, 25 Nov 2003, Mr Ian Primus wrote:
Yup. The ROM (or your boot routine) read the first
(sometimes
second) block of that, which in turn goes to read the rest.
Well, the three tapes I tried must not have been
bootable (or at least not directly bootable) I do have
one more tape, that does seem to be a BRU tape. I
booted it, and it did more. It loaded for longer, then
crashed. Woohoo! It's working well enough to crash! (I
think this is an improvement). When it crashed, it
gave me this:
SYSTEM CRASH AT LOCATION 011336
REGISTERS
R0=000304 R1=172522 R2=063107 R3=172520
R4=000010 R5=000000 SP=117756 PS=000010
SYSTEM STACK DUMP
LOCATION CONTENTS
117756 000004
004412
@
OK. R3 is pointint at 172520, which is the MSCP DISK
controller address (KDA50,UDA50,RQDX, etc.) It probably
decided to bail out after finding no usable disk controllers.
I don't know off the top of my what model tape
controller I'm using. I'll have to check when I get
back home tonight. I know it's an Emulex, but that
really doesn't help. <grin>
It doesnt :) When doing remote debugging, I
usually wanna
know what I am dealing with, for both disk and tape controllers.
File 0 :
blocksize 512 (439 blocks)
OK, so I guess that File 0 is what I'm currently
reading, correct? Is this the part of the tape that
has that error message in it? Well, it looks like I'll be trying to write a
tape
tonight. I'll have to connect the Prime's SCSI tape
drive to a PC, I should just be able to dd a tape
image to the tape device without any problems, right?
Yup. Well, hmm. PDP-11 boot
tape usually have a number
of "files" on them, and each "file" can use more than one
block size- see my example. You can't just dd it to a
file, and then from a file back to tape.
Or will I have to write it in segments, specifying
the
block size as I go? I haven't done a lot with tape
Yep.
formats before. Also, once I figure out which tape
controller I am using, how do I write a compatible
tape from *nix?
No worries, the tape stuf seems to be fine now, we probably
have to concentrate on the disk part now.
--f
--
Fred N. van Kempen, DEC (Digital Equipment Corporation) Collector/Archivist
Visit the VAXlab Project at http://www.pdp11.nl/VAXlab/
Visit the Archives at http://www.pdp11.nl/
Email: waltje(a)pdp11.nl BUSSUM, THE NETHERLANDS / Sunnyvale, CA, USA
24 Nov
24 Nov
5:53 a.m.
On Nov 24, 2003, at 6:18 AM, Ian Primus wrote:
On Monday, November 24, 2003, at 04:46 AM, Fred N. van Kempen wrote:
Good point... Right now I'm using a Lear Siegler
ADM3A :)
Better yet, use vtserver from a PC to boot the 11/73, and write a
scratch tape from a known good boot image. If the new boot tape
actually boots, your controller and tape drive are validated, leaving a
couple of points-of-failure not to worry about. Plus, you get to play
with the system. :)
I forget the memory specs of your system, but vtserver requires 192KB
on the client (PDP11) to run. vtserver was invaluable in getting our
new 11/84 up and running last month. The previous owners had
bulk-erased every piece of media except the RA-60P disk packs, and had
zeroed those. :(
Doc
Since the "*** THIS VOLUME" ... comes from the boot loader (it is not
in the bootstrap program...) on tape, we *did* load something from it.
I tried three different tapes, two of which are the same thing. One
tape is a homemade system tape, on an ten inch reel. The label is
handwritten in pencil and hard to read. It says "RSX-11-M-Plus V4.0
Operating system for Eagle (DB2, omitting software directories) VMR'd
for extra pool space <something I can't read>, needs DTR files
[1,2],<something else I can't read>" The other tape is an official
Digital tape on a 12 inch reel. The label says "BB-JO81J-BC
RSX-11M-LUS V4.4 BRU MT:1/1 ID:RSX11MPBL78 DIST 1600BPI COPYRIGHT
1993 DIGITAL EQUIPMENT CORPORATION MB0804". I don't know what
controller these were written for, or how my Emulex card is set up.
I'll have to read through the Emulex manual some more.
Even though we were able to load the secondary
bootstrap off tape
(which
is blocks 0 and/or 1 on tape), we **ALSO** need to have that code know
what we're loading from.
Are these leading blocks written in the same format
or a different
format as the rest of the tape? What about density? I'll have to look
up in the manual, but I _think_ the default on my drive is 1600bpi,
but I'm not positive.
Suppose... we load the secondary boot. But: that
thinks we're using a
TM11 controller. It then tries to load the rest off tape... but
barfs,
because the TM11 doesnt respond (since it's really a TS11.) ...
error..
What's the difference between the two controllers? Is their tape
format different, or just the headers?
I might
end up doing that, I can write down the output, and email it
to
you.
Use a terminal program on a PC or other system, and just log the
sessions. Much easier :)
5:55 a.m.
> Dunno which tape you are using, but: the
address...
Ian I think he means your drive and controller.
Have you told the list what controllers you're using?
http://world.std.com/~mbg/pdp11-field-guide.txt :
"TC02 Q Emulex Pertec-interface tape drive controller.
Emulates TS11."
Since the tape drives are different
(the PDP-11 one is Pertec, the Prime one is SCSI),
Nine track tapes tend to be pretty interchangeable
across a given density (800bpi,1600bpi,etc.)
I never sweated the Formatted/Streaming issue before
now though. Could a list member comment if Those
tapes are interchangeable?
Here's another quick suggestion.
There's a fair chance that your hard drive has a working O/S on it too.
I'll have to look up in the manual, but I _think_
the default
on my drive is 1600bpi,
Keep all the relevant manuals handy.
They're _very_valuable to your task.
John A.
7542
days inactive
7544
days old
18 comments
8 participants
participants (8)
-
allain＠panix.com -
Andreas.Freiherr＠Vishay.com -
doc＠mdrconsult.com -
ian_primus＠yahoo.com -
jkunz＠unixag-kl.fh-kl.de -
kth＠srv.net -
mouse＠Rodents.Montreal.QC.CA -
waltje＠pdp11.nl