22 Jun
2005
22 Jun
'05
1:13 a.m.
Hi,
after several cleaning orgies, my SMD disk (AMPEX DFR-996, see other
posting) seems to start working.
Now I want to backup the data contained on the disks. These are RSX-11
volumes. I cannot read them under RT11. And I don't know if I can make a
diskette RSX-11 to inspect the data. Or is there a preogram which runs
on rt11 and is able to understand rsx11 filesystem? That would be great!
My first idea for the backup was "copy/device dm0: tt:" which works. But
there is no error correction and still only 19200 baud.
So tell me, what are the really cool methods to transfer data between a
PC and a real PDP11 at a reasonable speed? SCSI controller and SCSI
disk? Something else? Ethernet?
Or is a backup over serial line a normal thing...?
Regards,
Philipp :-)
22 Jun
22 Jun
11:50 a.m.
On Wed, 2005-06-22 at 07:13 +0200, Philipp Hachtmann wrote:
Hi,
after several cleaning orgies, my SMD disk (AMPEX DFR-996, see other
posting) seems to start working.
Now I want to backup the data contained on the disks. These are RSX-11
volumes. I cannot read them under RT11. And I don't know if I can make a
diskette RSX-11 to inspect the data. Or is there a preogram which runs
on rt11 and is able to understand rsx11 filesystem? That would be great!
My first idea for the backup was "copy/device dm0: tt:" which works. But
there is no error correction and still only 19200 baud.
So tell me, what are the really cool methods to transfer data between a
PC and a real PDP11 at a reasonable speed? SCSI controller and SCSI
disk? Something else? Ethernet?
Or is a backup over serial line a normal thing...?
I found that the best way to backup/restore is to use tape. I have a
TU80 on the PDP and a SCSI 9-track on the PC. Works great and is much
faster than the serial line.
--
TTFN - Guy
11:54 a.m.
>>>> "Guy" == Guy Sotomayor
<ggs at shiresoft.com> writes:
> So tell me, what are the really cool methods to
transfer data
> between a PC and a real PDP11 at a reasonable speed? SCSI
> controller and SCSI disk? Something else? Ethernet?
>
> Or is a backup over serial line a normal thing...?
Guy> I found that the best way to backup/restore is to use tape. I
Guy> have a TU80 on the PDP and a SCSI 9-track on the PC. Works
Guy> great and is much faster than the serial line.
Ethernet is another good way; DECnet is available on Linux.
paul
2:33 p.m.
So tell me, what are the really cool methods to
transfer data between a
PC and a real PDP11 at a reasonable speed? SCSI controller and SCSI
disk? Something else? Ethernet?
Or is a backup over serial line a normal thing...?
It helps that I have SCSI Controllers on my operational PDP-11's. I use
removable disk trays that allow me to move the HD's between PDP-11's, and
more importantly to hook them up to a Unix box, at which point I can use
'dd' to back them up. The resulting disk images can be accessed via SIMH,
E11, or burned to a CD-R and accessed on the real PDP-11 HW. I've managed
to boot and install RT-11, RSX-11M, and RSX-11M+ from CD-R. I've yet to
figure out how to do that with RSTS/E. I also typically have either a TZ30
(half-height SCSI TK50 drive), or a TLZ06 (4mm DAT) drive hooked up. I
prefer to use DAT, however, RSTS/E software doesn't really like trying to be
installed from DAT.
Ethernet using either TCP/IP or DECnet is another option that I use to
transfer data, but I try to only use that for small amounts of data. One of
these days I plan to go wireless with my PDP-11. I'd also like to see if I
can't get a SCSI DVD-ROM drive running, but considering the difficulty with
getting a CD-ROM drive to work, I have some doubts on getting that to work.
Zane
2:53 p.m.
>>>> "Zane" == Zane H Healy
<healyzh at aracnet.com> writes:
> So tell me, what are the really cool methods to
transfer data
> between a PC and a real PDP11 at a reasonable speed? SCSI
> controller and SCSI disk? Something else? Ethernet?
>
> Or is a backup over serial line a normal thing...?
Zane> It helps that I have SCSI Controllers on my operational
Zane> PDP-11's. I use removable disk trays that allow me to move the
Zane> HD's between PDP-11's, and more importantly to hook them up to
Zane> a Unix box, at which point I can use 'dd' to back them up. The
Zane> resulting disk images can be accessed via SIMH, E11, or burned
Zane> to a CD-R and accessed on the real PDP-11 HW. I've managed to
Zane> boot and install RT-11, RSX-11M, and RSX-11M+ from CD-R. I've
Zane> yet to figure out how to do that with RSTS/E.
If the CD-R is on a controller RSTS understands (MSCP is the only
option I can think of for this) and is formatted with the RSTS file
structure, and has a boot block in sector zero, it should all just
work.
I haven't personally done this but I'm pretty sure it was done by one
of my friends. I even have some weird "hybrid file system" hacks in
RSTSFLX to let you create a CD-R that's partly ISO and partly RTST,
and bootable. I believe that was used and shown to work, though I
never saw the results.
If you have the files, RSTSFLX can make a bootable disk image for you,
so you can try this yourself.
paul
3:07 p.m.
I haven't personally done this but I'm pretty
sure it
was done by one of my friends. I even have some weird
"hybrid file system" hacks in RSTSFLX to let you create
a CD-R that's partly ISO and partly RTST, and bootable.
That seems quite reasonable. The ISO9660 standard leaves
enough blocks early on undefined that you can build a
CD that is both a legal ISO9660 filesystem and a legal
OpenVMS (ODS-2) filesystem.
If you try hard enough, you can build a hybrid system where
the ODS-2 and ISO9660 sides have different trees but share
the same data (useful for stream-LF and binary files).
I presume RSTS is ODS-1, which IIRC is ODS-2 but without
a few of the bells and whistles so the structure is
quite close to ODS-2. I would expect that you could
interleave ODS-1 and ISO9660 fairly easily.
Antonio
3:17 p.m.
>>>> "Antonio" == Antonio Carlini
<a.carlini at ntlworld.com> writes:
> I haven't personally done this but I'm
pretty sure it was done by
> one of my friends. I even have some weird "hybrid file system"
> hacks in RSTSFLX to let you create a CD-R that's partly ISO and
> partly RTST, and bootable.
Antonio> If you try hard enough, you can build a hybrid system where
Antonio> the ODS-2 and ISO9660 sides have different trees but share
Antonio> the same data (useful for stream-LF and binary files).
Cool idea. I didn't do that -- didn't think of it, and also because I
didn't know enough 9660 then.
Antonio> I presume RSTS is ODS-1, which IIRC is ODS-2 but without a
Antonio> few of the bells and whistles so the structure is quite
Antonio> close to ODS-2. I would expect that you could interleave
Antonio> ODS-1 and ISO9660 fairly easily.
No, RSTS is RDS-1; it's a file structure all its own, totally
unrelated to any other PDP-11 OS. (It's a distant relative of the
TSS-8 file system, though.)
In particular, the naming aspects (directory) and file block to disk
block mapping aspects (file header in ODS, inode in Unix) are combined
in the RSTS directory structure, unfortunately. So there is no rename
across directories and neither softlinks nor hardlinks.
It's all nicely documented in the RSTS internals manuals, and you can
also read all about it in the RSTSFLX sources.
paul
3:55 p.m.
No, RSTS is RDS-1; it's a file structure all its
own, totally
unrelated to any other PDP-11 OS. (It's a distant relative of the
TSS-8 file system, though.)
The trick with interleaving ODS-2 and ISO9660 is to use the first
64 blocks or so that ISO9660 leaves undefined as the "in" for ODS-2.
Then you get N blocks of ISO9660 data and meta-data. The ISO9660
blocks get collected into BADBLK.SYS in ODS-2.
So the two filesystems side-step each other. If you want to share
data (which I did when I was building CDs with PDFs and index HTMLs)
then that is possible, but slightly harder.
As long as RDS-1 does not absolutely need block 64 and some way
onwards, then it may be possible to logically interleave it and
ISO9660.
I've often wondered whether it would be possible to build a
disk that could boot VAX, Alpha (OpenVMS) and PDP-11 (RSX-11).
It would be an interesting exercise to try sometime, and
probably a lot easier to test now that we have SIMH!
Antonio
4:03 p.m.
On Wed, 2005-06-22 20:55:32 +0100, Antonio Carlini <a.carlini at ntlworld.com>
wrote:
64 blocks or so that ISO9660 leaves undefined as the
"in" for ODS-2.
Then you get N blocks of ISO9660 data and meta-data. The ISO9660
blocks get collected into BADBLK.SYS in ODS-2.
As for ODS-2, the vax-linux kernel does have some limited ODS-2 support.
So if you've got some raw partition dumps, you may be able to to
loop-mount it (or crash your box, depends on computer's mood, moon
phase, jupiter's constellation towards earth and the answer to the final
question...)
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
4:13 p.m.
>>>> "Antonio" == Antonio Carlini
<a.carlini at ntlworld.com> writes:
> No, RSTS is RDS-1; it's a file structure all
its own, totally
> unrelated to any other PDP-11 OS. (It's a distant relative of the
> TSS-8 file system, though.)
Antonio> The trick with interleaving ODS-2 and ISO9660 is to use the
Antonio> first 64 blocks or so that ISO9660 leaves undefined as the
Antonio> "in" for ODS-2. Then you get N blocks of ISO9660 data and
Antonio> meta-data. The ISO9660 blocks get collected into BADBLK.SYS
Antonio> in ODS-2.
That's essentially what I did.
Antonio> As long as RDS-1 does not absolutely need block 64 and some
Antonio> way onwards, then it may be possible to logically interleave
Antonio> it and ISO9660.
Right. The only hardwired block is block 1 (the "pack label"). All
the rest starts from there and can be anywhere. Oh yes, and block 0
(the boot block) of course, for bootable disks.
paul
6:20 p.m.
Zane> It helps that I have SCSI Controllers on my
operational
Zane> PDP-11's. I use removable disk trays that allow me to move the
Zane> HD's between PDP-11's, and more importantly to hook them up to
Zane> a Unix box, at which point I can use 'dd' to back them up. The
Zane> resulting disk images can be accessed via SIMH, E11, or burned
Zane> to a CD-R and accessed on the real PDP-11 HW. I've managed to
Zane> boot and install RT-11, RSX-11M, and RSX-11M+ from CD-R. I've
Zane> yet to figure out how to do that with RSTS/E.
If the CD-R is on a controller RSTS understands (MSCP is the only
option I can think of for this) and is formatted with the RSTS file
structure, and has a boot block in sector zero, it should all just
work.
I haven't personally done this but I'm pretty sure it was done by one
of my friends. I even have some weird "hybrid file system" hacks in
RSTSFLX to let you create a CD-R that's partly ISO and partly RTST,
and bootable. I believe that was used and shown to work, though I
never saw the results.
If you have the files, RSTSFLX can make a bootable disk image for you,
so you can try this yourself.
paul
I didn't have any problem with getting RSTS/E to start to boot off of CD-R,
where I had problems was with it not liking the fact it was on a Read-Only
filesystem. If I had a better understanding of RSTS/E, I suspect this could
be overcome. I've not had the time to look further into the matter.
Zane
23 Jun
23 Jun
4:08 a.m.
Hi,
Zane H. Healy said:
I didn't have any problem with getting RSTS/E to
start to boot off of CD-R,
where I had problems was with it not liking the fact it was on a Read-Only
filesystem. If I had a better understanding of RSTS/E, I suspect this could
be overcome. I've not had the time to look further into the matter.
I think RSTS/E writes or re-writes something during the boot process to
check that it was properly shut down last time it was used. The quickest
way to check would probably be to look at the code in SHUTUP.BAS
--
Cheers,
Stan Barr stanb at dial.pipex.com
The future was never like this!
3:16 p.m.
>>>> "Stan" == Stan Barr
<stanb at dial.pipex.com> writes:
Stan> Hi, Zane H. Healy said:
> I didn't have any problem with getting RSTS/E
to start to boot off
> of CD-R, where I had problems was with it not liking the fact it
> was on a Read-Only filesystem. If I had a better understanding of
> RSTS/E, I suspect this could be overcome. I've not had the time
> to look further into the matter.
Stan> I think RSTS/E writes or re-writes something during the boot
Stan> process to check that it was properly shut down last time it
Stan> was used. The quickest way to check would probably be to look
Stan> at the code in SHUTUP.BAS
You're thinking about the "cleanly dismounted" flag in the pack
label. That's handled in the kernel, not in shutup.bas. In any case,
that flag is written at mount, and again at dismount, but ONLY if the
pack is a read-write pack and being mounted read-write. If you mount
the pack read-only (via the command line option, for example) or the
pack is marked as read-only in the pack label, then the "mounted" flag
is NOT touched at any time.
Read-only means what it says. If you mount a pack that way, RSTS will
NOT write it, ever.
That feature is used in a bunch of places; distribution media is one
example. Those would normally be loaded with the hardware write-lock
switch set, but whether ot not that is set, the software write-lock
flag in the pack label will tell RSTS never to write to it.
paul
9:18 a.m.
>>>> "Zane" == Zane H Healy
<healyzh at aracnet.com> writes:
Zane> I didn't have any problem with getting RSTS/E to start to boot
Zane> off of CD-R, where I had problems was with it not liking the
Zane> fact it was on a Read-Only filesystem. If I had a better
Zane> understanding of RSTS/E, I suspect this could be overcome.
Zane> I've not had the time to look further into the matter.
RSTS boots fine off a read-only file system. You probably want to set
the "read only pack" flag in the pack label. But it assumes that a
read-only file system is a kit, so it autostarts the installation
script. That may not be what you want. If not, control/C should get
you a CLI prompt.
paul
22 Jun
22 Jun
2:56 p.m.
>>>> "Zane" == Zane H Healy
<healyzh at aracnet.com> writes:
Zane> .... I also typically
Zane> have either a TZ30 (half-height SCSI TK50 drive), or a TLZ06
Zane> (4mm DAT) drive hooked up. I prefer to use DAT, however,
Zane> RSTS/E software doesn't really like trying to be installed from
Zane> DAT.
Why, what happens? If it's TMSCP it should work. Some of the I/O
won't be streaming I/O, since the RSTS install process doesn't switch
to the BACKUP tool (which supports streaming) until partway through.
So if your tape drive can't hack start/stop operating mode, then yes,
that could be a problem. In that case, I'd argue it simply isn't a
good drive at all.
paul
6:22 p.m.
Zane> .... I also typically
Zane> have either a TZ30 (half-height SCSI TK50 drive), or a TLZ06
Zane> (4mm DAT) drive hooked up. I prefer to use DAT, however,
Zane> RSTS/E software doesn't really like trying to be installed from
Zane> DAT.
Why, what happens? If it's TMSCP it should work. Some of the I/O
won't be streaming I/O, since the RSTS install process doesn't switch
to the BACKUP tool (which supports streaming) until partway through.
So if your tape drive can't hack start/stop operating mode, then yes,
that could be a problem. In that case, I'd argue it simply isn't a
good drive at all.
paul
As I understand it, the issue was with variable byte blocks. I had zero
issues installing RSTS/E, and I think a couple layered products off of 4mm
DAT. However, DECnet/E would not install off of DAT.
Zane
23 Jun
23 Jun
9:19 a.m.
>>>> "Zane" == Zane H Healy
<healyzh at aracnet.com> writes:
Zane> As I understand it, the issue was with variable byte blocks. I
Zane> had zero issues installing RSTS/E, and I think a couple layered
Zane> products off of 4mm DAT. However, DECnet/E would not install
Zane> off of DAT.
You mean variable length blocks? If it doesn't support that, it isn't
a proper tape. Proper tapes handle any block size, odd or even, from
14 up to at least 8k or so.
paul
10:51 a.m.
At 9:19 AM -0400 6/23/05, Paul Koning wrote:
Yes, that's what I mean. It is my understanding from when I got some
help figuring this out (I think by this list), that was the problem.
It wouldn't install from DAT, but had zero issues with TK50.
Zane
--
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
| | Classic Computer Collector |
+----------------------------------+----------------------------+
| Empire of the Petal Throne and Traveller Role Playing, |
| PDP-10 Emulation and Zane's Computer Museum. |
| http://www.aracnet.com/~healyzh/ |
>>>> "Zane" == Zane H Healy <healyzh at aracnet.com> writes:
Zane> As I understand it, the issue was with variable byte blocks. I
Zane> had zero issues installing RSTS/E, and I think a couple layered
Zane> products off of 4mm DAT. However, DECnet/E would not install
Zane> off of DAT.
You mean variable length blocks? If it doesn't support that, it isn't
a proper tape. Proper tapes handle any block size, odd or even, from
14 up to at least 8k or so.
11:02 a.m.
>>>> "Zane" == Zane H Healy
<healyzh at aracnet.com> writes:
Zane> At 9:19 AM -0400 6/23/05, Paul Koning wrote:
>> >>>>
"Zane" == Zane H Healy <healyzh at aracnet.com> writes:
>>
Zane> As I understand it, the issue was with variable byte blocks. I
Zane> had zero issues installing RSTS/E, and I think a couple layered
Zane> products off of 4mm DAT. However, DECnet/E would not install
Zane> off of DAT.
> You mean variable length blocks? If it
doesn't support that, it
> isn't a proper tape. Proper tapes handle any block size, odd or
> even, from 14 up to at least 8k or so.
Zane> Yes, that's what I mean. It is my understanding from when I
Zane> got some help figuring this out (I think by this list), that
Zane> was the problem. It wouldn't install from DAT, but had zero
Zane> issues with TK50.
Ok. RSTS does assume/require that tapes are designed by competent
designers. I'm surprised you didn't run into similar issues with
other operating systems.
paul
11:41 a.m.
Paul Koning wrote:
>>>>>"Zane" == Zane H Healy
<healyzh at aracnet.com> writes:
Zane> Yes, that's what I mean. It is my
understanding from when I
Zane> got some help figuring this out (I think by this list), that
Zane> was the problem. It wouldn't install from DAT, but had zero
Zane> issues with TK50.
Ok. RSTS does assume/require that tapes are designed by competent
designers. I'm surprised you didn't run into similar issues with
other operating systems.
Well, I'm not sure about Zane, but I've had that kind of issues with
RSTS/E, not just layered products, with two DDS drives that I assume
*was* designed by competent engineers. They were a TLZ06 and a TLZ07,
both clean and tested good.
And, as in Zane's experience, the same tape image installed from TK50
(TZ30 drive) on the same 11/83 without complaint.
Doc
26 Jun
26 Jun
4:57 p.m.
Zane H. Healy wrote:
So tell me,
what are the really cool methods to transfer data between a
PC and a real PDP11 at a reasonable speed? SCSI controller and SCSI
disk? Something else? Ethernet?
Or is a backup over serial line a normal thing...?
It helps that I have SCSI Controllers on my operational PDP-11's. I use
removable disk trays that allow me to move the HD's between PDP-11's, and
more importantly to hook them up to a Unix box, at which point I can use
'dd' to back them up. The resulting disk images can be accessed via SIMH,
E11, or burned to a CD-R and accessed on the real PDP-11 HW. I've managed
to boot and install RT-11, RSX-11M, and RSX-11M+ from CD-R. I've yet to
figure out how to do that with RSTS/E. I also typically have either a TZ30
(half-height SCSI TK50 drive), or a TLZ06 (4mm DAT) drive hooked up. I
prefer to use DAT, however, RSTS/E software doesn't really like trying to be
installed from DAT.
Ethernet using either TCP/IP or DECnet is another
option that I use to
transfer data, but I try to only use that for small amounts of data. One of
these days I plan to go wireless with my PDP-11. I'd also like to see if I
can't get a SCSI DVD-ROM drive running, but considering the difficulty with
getting a CD-ROM drive to work, I have some doubts on getting that to work.
One thing about a CDROM drive as opposed to a DVD drive
on a PC is that the normal (IDE) CDROM drive was not
able to read the first 64 blocks (16 CD sectors) of the
CD under E11 using RT-11. My DVD drive on the PC does
allow E11 under Windows 98 SE to read those first 64 blocks
of the CD and I can BOOT RT-11 on the PC under E11.
As a result, I do not have much of an incentive to acquire
a CDROM drive that will work with my SCSI Qbus host adapter
on the PDP-11. If ever anyone is discarding such a CDROM
drive, please let me know. It would be "nice" to be able
to boot from a CDROM drive on a real DEC PDP-11 system.
Sincerely yours,
Jerome Fine
--
If you attempted to send a reply and the original e-mail
address has been discontinued due a high volume of junk
e-mail, then the semi-permanent e-mail address can be
obtained by replacing the four characters preceding the
'at' with the four digits of the current year.
6931
days inactive
6935
days old
20 comments
9 participants
participants (9)
-
a.carlini＠ntlworld.com -
doc＠mdrconsult.com -
ggs＠shiresoft.com -
hachti＠hachti.de -
healyzh＠aracnet.com -
jbglaw＠lug-owl.de -
jhfinexgs2＠compsys.to -
pkoning＠equallogic.com -
stanb＠dial.pipex.com