UK PDP11 wanted
Edward Austin
ed at ryer.ru
Wed Apr 8 07:19:03 CDT 2015
Hi there
I am based in the UK (Edinburgh) and have been seeking the last couple of
years a working/non-working MicroPDP 11/23, 73 or 93 in preferably a BA-23,
but anything definitely considered.
These rarely come up on eBay (although I am tempted to by a working
MicroPDP 11/73 in a BA-23 from eBay US for $1200, but shipping and taxes
would make this at least 50% more).
Any advice on sources of hardware in the UK/EU would be much appreciated.
I really don't want to wait many more years simply because the rarity may
mean I never get one.
Also looking for a VAXStation 3100/9x model. Again hard to find in the UK.
Many thanks
Ed
On Tue, Apr 7, 2015 at 6:00 PM, <cctalk-request at classiccmp.org> wrote:
> Send cctalk mailing list submissions to
> cctalk at classiccmp.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.classiccmp.org/mailman/listinfo/cctalk
> or, via email, send a message with subject or body 'help' to
> cctalk-request at classiccmp.org
>
> You can reach the person managing the list at
> cctalk-owner at classiccmp.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cctalk digest..."
>
>
> Today's Topics:
>
> 1. Re: BA23 Chassis available in Lexington KY - Taken
> (keith at saracom.com)
> 2. Re: BA23 Chassis available in Lexington KY - Taken (Paul Anderson)
> 3. Looking for.... (Jay West)
> 4. RL02-USB Controller Status/Problem (Christopher Parish)
> 5. Seeking H7861 Power Supply (PDP 11/23+) (Cory Heisterkamp)
> 6. Re: Seeking H7861 Power Supply (PDP 11/23+) (Noel Chiappa)
> 7. Re: Seeking H7861 Power Supply (PDP 11/23+) (Jacob Ritorto)
> 8. Re: RL02-USB Controller Status/Problem (Eric Smith)
> 9. Re: RL02-USB Controller Status/Problem (Eric Smith)
> 10. Re: RL02-USB Controller Status/Problem (Don North)
> 11. Re: RL02-USB Controller Status/Problem (Don North)
> 12. Re: RD54 Stopped Spinning (shadoooo)
> 13. Re: RL02-USB Controller Status/Problem (Johnny Billquist)
> 14. RE: RL02-USB Controller Status/Problem (Christopher Parish)
> 15. Re: RL02-USB Controller Status/Problem (Pete Turnbull)
> 16. Re: RL02-USB Controller Status/Problem (Pete Turnbull)
> 17. Re: RL02-USB Controller Status/Problem (Pete Turnbull)
> 18. Re: RL02-USB Controller Status/Problem (Pete Turnbull)
> 19. Re: RL02-USB Controller Status/Problem (Paul Koning)
> 20. Re: RL02-USB Controller Status/Problem (Johnny Billquist)
> 21. Re: RL02-USB Controller Status/Problem (Johnny Billquist)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 06 Apr 2015 13:20:22 -0400
> From: keith at saracom.com
> To: cctech at classiccmp.org
> Subject: Re: BA23 Chassis available in Lexington KY - Taken
> Message-ID: <74a272e1cd6f7dc12ff7f3a803b3c822 at saracom.com>
> Content-Type: text/plain
>
>
>
> OK, I think all of them have been claimed now. If not I will report. Now
> to see what else is in the shed.
>
> thanks
>
> ------------------------------ Message: 16 Date: Mon, 6 Apr 2015
> 11:06:31 -0400 From: Jacob Ritorto <jacob.ritorto at gmail.com> To:
> "General Discussion: On-Topic Posts" <cctech at classiccmp.org> Subject:
> Re: BA23 Chassis available in Lexington KY Message-ID:
> <CAHYQbfBp7WuiR5qSfeR39tDMBQKGHvg2Vk8vw5FGgewSOjBzug at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8 Hey Max, I'll take a couple.
> You're a six-hour's drive from me, so it'll take me a sec to figure out
> when. How's Friday for you? On Sun, Apr 5, 2015 at 6:47 PM,
> <keith at saracom.com> wrote:
>
> >> Hello, I am in the process of moving and need to pare down my spare
> parts collection. I have several BA23 chassis with power supplies. I do not
> know the condition as they have been stored in my shed for years. They do
> not include modules or outer shells. If you pickup in Lexington KY, they
> are free. Thanks Max
> > ************************************
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 6 Apr 2015 16:23:42 -0500
> From: Paul Anderson <useddec at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: BA23 Chassis available in Lexington KY - Taken
> Message-ID:
> <CACwhfuMTOfs_Q0bQgE5=
> o11LvsLG3hdkh858H0JNvmswy4ggQg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> If anyone needs any boards for them, feel free to contact me off list.
>
> Thanks, Paul
>
> On Mon, Apr 6, 2015 at 12:20 PM, <keith at saracom.com> wrote:
>
> >
> >
> > OK, I think all of them have been claimed now. If not I will report. Now
> > to see what else is in the shed.
> >
> > thanks
> >
> > ------------------------------ Message: 16 Date: Mon, 6 Apr 2015
> > 11:06:31 -0400 From: Jacob Ritorto <jacob.ritorto at gmail.com> To:
> > "General Discussion: On-Topic Posts" <cctech at classiccmp.org> Subject:
> > Re: BA23 Chassis available in Lexington KY Message-ID:
> > <CAHYQbfBp7WuiR5qSfeR39tDMBQKGHvg2Vk8vw5FGgewSOjBzug at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8 Hey Max, I'll take a couple.
> > You're a six-hour's drive from me, so it'll take me a sec to figure out
> > when. How's Friday for you? On Sun, Apr 5, 2015 at 6:47 PM,
> > <keith at saracom.com> wrote:
> >
> > >> Hello, I am in the process of moving and need to pare down my spare
> > parts collection. I have several BA23 chassis with power supplies. I do
> not
> > know the condition as they have been stored in my shed for years. They do
> > not include modules or outer shells. If you pickup in Lexington KY, they
> > are free. Thanks Max
> > > ************************************
> >
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 6 Apr 2015 19:37:24 -0500
> From: "Jay West" <jwest at classiccmp.org>
> To: <cctalk at classiccmp.org>
> Subject: Looking for....
> Message-ID: <000d01d070cb$04a0bf60$0de23e20$@classiccmp.org>
> Content-Type: text/plain; charset="us-ascii"
>
> I need another operational HP 7970E mag tape controller (13183 - 2 board
> set). It appears that the spare board sets I have are 13181 which I believe
> is only for the 7970A/B. All my drives are 7970E, so is there any chance
> someone has a 7970A/B but has a 13183 and would like to swap my 13181 for
> it? J Or if anyone has a spare 13183 they want to sell/trade...
>
>
>
> Best,
>
>
>
> J
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 6 Apr 2015 22:54:39 +0000
> From: Christopher Parish <christopher.parish at parishcomputers.com>
> To: General Discussion: On-Topic Posts ?[cctech at classiccmp.org]?
> <cctech at classiccmp.org>
> Subject: RL02-USB Controller Status/Problem
> Message-ID:
>
> <639FFF5F324E6D409F42CF2B2F3BB56AB0FF00DB at MBX022-E1-NJ-4.exch022.domain.local
> >
>
> Content-Type: text/plain; charset="windows-1256"
>
> Progress is good on the RL02-USB controller. I've gotten complete
> operation working as expected with the usual tools for disk access
> (badblocks, dd, etc.), and SIMH can access the real packs via the
> controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is
> only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those
> with identified bad blocks from the factory) are another story.
>
>
> The issue is most obvious when backing up and restoring disk images.
> Suppose I backup a pack with 1 bad sector. I have two choices of what to do
> with the bad sector (specifically if it's a bad header), I could skip the
> sector (reporting an IO error), or I could report all zeros for the sector.
>
>
> Skipping the sector is a bad idea because the logical address of all
> sectors after it will shift down by one. This will make the disk image not
> work correctly with SIMH, or anything else for that matter, because most
> filesystems address things by physical block (Please correct me if I'm
> wrong here). Remember, we're at the device level (/dev/sda) not the
> partition level (/dev/sda1).
>
>
> Returning all zeros for bad sectors will preserve the block numbers of
> following sectors and work correctly with SIMH, but trying to restore the
> resulting image to another physical pack will probably be impossible given
> the destination disk pack has bad sectors of its own in different spots.
>
>
> The usual trick of having the controller re-map the bad sectors will not
> work because the platters in the RL02 are removable. Writing some mapping
> index on the disk pack or holding back sectors in reserve will break
> compatibility with the original systems (PDP8s/11s/VAXes) and all their
> software (an unacceptable solution).
>
>
> I think I've come to the following conclusions given the restrictions
> above:
>
>
> - Creating and Restoring images with EF packs is unrestricted
>
> - SIMH operation with EF packs (online and images) will work perfectly
>
> - Creating images of DC packs will work with SIMH if I return zeros for
> the bad blocks
>
> - Online use of DC packs work with SIMH assuming no new bad blocks have
> formed since the bad block index was written
>
> - If new bad blocks have formed in a pack, SIMH will have to be modified
> so its RL(V)11 can receive error information from the drive, otherwise it
> will incorrectly handle the recovery
>
> - Restoring images on DC packs will require special software that can move
> data around the bad-blocks (or a linux RT-11 filesystem driver *wink*)
>
> - Using a modern filesystem on EF/DC packs is unrestricted (because they
> can identify and manage bad blocks on their own)
>
>
> First, does all of this seem reasonable?
>
>
> I vaguely remember reading about a program on RT-11 you would run
> (before?) backing up the filesystem. What was this program? How did it
> work? Did it make the data position independent?
>
>
> Christopher
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 6 Apr 2015 20:06:43 -0500
> From: Cory Heisterkamp <coryheisterkamp at gmail.com>
> To: "General Discussion: On-Topic Posts" <cctech at classiccmp.org>
> Subject: Seeking H7861 Power Supply (PDP 11/23+)
> Message-ID: <2747195F-0DE1-46FF-86A0-8342435A3C63 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
> I have a PDP 11/23+ I'm attempting to bring up and discovered why I wasn't
> getting anywhere- a metal screw had gotten into the supply shorting
> *something* on the supply PCB. I'm new to DEC equipment and I'm afraid this
> supply is beyond me. If someone has one for sale (this one marked H7861),
> please let me know. It looks serviceable and is likely repairable by an
> expert so that could be an option, too.
>
> Thanks,
> Cory
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 7 Apr 2015 00:21:32 -0400 (EDT)
> From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
> To: cctalk at classiccmp.org
> Cc: jnc at mercury.lcs.mit.edu
> Subject: Re: Seeking H7861 Power Supply (PDP 11/23+)
> Message-ID: <20150407042132.A7EF618C0FB at mercury.lcs.mit.edu>
>
> > From: Cory Heisterkamp
>
> > If someone has one for sale (this one marked H7861), please let me
> > know.
>
> Someone on eBay is selling one:
>
> http://www.ebay.com/itm/150947900783
>
> They are asking $125, which is not wholly ridiculous, and will probably
> take
> slightly less. I've bought several from this seller, and they are in good
> shape.
>
> Also, at a pinch, I'm pretty sure (as in, I have looked at both closely,
> and
> verified that they have the same interfaces and physical dimensions, etc,
> so I
> think this will work, but I have yet to actually try it) an H786 would also
> work in that system. The only difference I know of is that the H7861 puts
> out
> a few more amps of +5V. No reasonably priced H786's on eBay at the moment,
> though.
>
> > It looks serviceable and is likely repairable by an expert so that
> > could be an option, too.
>
> I'd interested in buying the dead one from you (which should help offset
> the
> cost if you go for the eBay one) - please contact me off line if
> interested.
>
> Noel
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 7 Apr 2015 00:32:20 -0400
> From: Jacob Ritorto <jacob.ritorto at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: Seeking H7861 Power Supply (PDP 11/23+)
> Message-ID:
> <
> CAHYQbfA336fXz8Ee_kThmGZKCz3r9wn8Je-rNg0-wP0TjfQtfQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> coupla questions as an aside on this subject:
>
> 1) Which PS is more available on commodity market?
>
> 2) Assuming H7681, do you know how to wire a chassis that expects H768 to
> work with H7681? Or vice versa?
>
> 3) How can we make what we have on hand work for a long time?
>
> Bonus 4) Is there a commodity setup available to replace this analog kit
> entirely with new stuff? (probably a new thread)
>
>
> On Tue, Apr 7, 2015 at 12:21 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
>
> > > From: Cory Heisterkamp
> >
> > > If someone has one for sale (this one marked H7861), please let me
> > > know.
> >
> > Someone on eBay is selling one:
> >
> > http://www.ebay.com/itm/150947900783
> >
> > They are asking $125, which is not wholly ridiculous, and will probably
> > take
> > slightly less. I've bought several from this seller, and they are in good
> > shape.
> >
> > Also, at a pinch, I'm pretty sure (as in, I have looked at both closely,
> > and
> > verified that they have the same interfaces and physical dimensions, etc,
> > so I
> > think this will work, but I have yet to actually try it) an H786 would
> also
> > work in that system. The only difference I know of is that the H7861 puts
> > out
> > a few more amps of +5V. No reasonably priced H786's on eBay at the
> moment,
> > though.
> >
> > > It looks serviceable and is likely repairable by an expert so that
> > > could be an option, too.
> >
> > I'd interested in buying the dead one from you (which should help offset
> > the
> > cost if you go for the eBay one) - please contact me off line if
> > interested.
> >
> > Noel
> >
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 6 Apr 2015 23:41:48 -0600
> From: Eric Smith <spacewar at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Cc: General Discussion: On-Topic Posts ?[cctech at classiccmp.org]?
> <cctech at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID:
> <CAFrGgTT+A25OBEuz3DzLaj3d=
> O5G2eYfgENNNWyhJwGH+D2c9g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Apr 6, 2015 at 4:54 PM, Christopher Parish
> <christopher.parish at parishcomputers.com> wrote:
> > - Using a modern filesystem on EF/DC packs is unrestricted (because they
> can identify and manage bad blocks on their own)
>
> I'm not sure which filesystems you have in mind as "modern", but
> filesystem-level support for bad blocks has largely faded away in
> recent decades, because for many years now all disk drives have
> implemented bad block replacement internally.
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 6 Apr 2015 23:41:48 -0600
> From: Eric Smith <spacewar at gmail.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Cc: General Discussion: On-Topic Posts ?[cctech at classiccmp.org]?
> <cctech at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID:
> <CAFrGgTT+A25OBEuz3DzLaj3d=
> O5G2eYfgENNNWyhJwGH+D2c9g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Apr 6, 2015 at 4:54 PM, Christopher Parish
> <christopher.parish at parishcomputers.com> wrote:
> > - Using a modern filesystem on EF/DC packs is unrestricted (because they
> can identify and manage bad blocks on their own)
>
> I'm not sure which filesystems you have in mind as "modern", but
> filesystem-level support for bad blocks has largely faded away in
> recent decades, because for many years now all disk drives have
> implemented bad block replacement internally.
>
>
> ------------------------------
>
> Message: 10
> Date: Mon, 06 Apr 2015 22:53:59 -0700
> From: Don North <north at alum.mit.edu>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>, "General Discussion: On-Topic Posts
> ?[cctech at classiccmp.org]?" <cctech at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <552370F7.5050500 at alum.mit.edu>
> Content-Type: text/plain; charset=windows-1256; format=flowed
>
> Shouldn't the controller be using the DEC STD 144 bad sector replacement
> table
> in the last sector to transparently remap bad sectors such that, to the
> user,
> the -DC packs appear error free? If this were done each RL02 image should
> appear
> error-free in logical block address space as the hidden remapping of bad
> sectors
> on -DC drives would not be seen by the user (or O/S).
>
> All the other proposed ways of handling -DC bad sectors have serious
> compatibility issues.
>
> Don
>
> On 4/6/2015 3:54 PM, Christopher Parish wrote:
> > Progress is good on the RL02-USB controller. I've gotten complete
> operation working as expected with the usual tools for disk access
> (badblocks, dd, etc.), and SIMH can access the real packs via the
> controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is
> only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those
> with identified bad blocks from the factory) are another story.
> >
> >
> > The issue is most obvious when backing up and restoring disk images.
> Suppose I backup a pack with 1 bad sector. I have two choices of what to do
> with the bad sector (specifically if it's a bad header), I could skip the
> sector (reporting an IO error), or I could report all zeros for the sector.
> >
> >
> > Skipping the sector is a bad idea because the logical address of all
> sectors after it will shift down by one. This will make the disk image not
> work correctly with SIMH, or anything else for that matter, because most
> filesystems address things by physical block (Please correct me if I'm
> wrong here). Remember, we're at the device level (/dev/sda) not the
> partition level (/dev/sda1).
> >
> >
> > Returning all zeros for bad sectors will preserve the block numbers of
> following sectors and work correctly with SIMH, but trying to restore the
> resulting image to another physical pack will probably be impossible given
> the destination disk pack has bad sectors of its own in different spots.
> >
> >
> > The usual trick of having the controller re-map the bad sectors will not
> work because the platters in the RL02 are removable. Writing some mapping
> index on the disk pack or holding back sectors in reserve will break
> compatibility with the original systems (PDP8s/11s/VAXes) and all their
> software (an unacceptable solution).
> >
> >
> > I think I've come to the following conclusions given the restrictions
> above:
> >
> >
> > - Creating and Restoring images with EF packs is unrestricted
> >
> > - SIMH operation with EF packs (online and images) will work perfectly
> >
> > - Creating images of DC packs will work with SIMH if I return zeros for
> the bad blocks
> >
> > - Online use of DC packs work with SIMH assuming no new bad blocks have
> formed since the bad block index was written
> >
> > - If new bad blocks have formed in a pack, SIMH will have to be modified
> so its RL(V)11 can receive error information from the drive, otherwise it
> will incorrectly handle the recovery
> >
> > - Restoring images on DC packs will require special software that can
> move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*)
> >
> > - Using a modern filesystem on EF/DC packs is unrestricted (because they
> can identify and manage bad blocks on their own)
> >
> >
> > First, does all of this seem reasonable?
> >
> >
> > I vaguely remember reading about a program on RT-11 you would run
> (before?) backing up the filesystem. What was this program? How did it
> work? Did it make the data position independent?
> >
> >
> > Christopher
> >
>
>
>
> ------------------------------
>
> Message: 11
> Date: Mon, 06 Apr 2015 22:53:59 -0700
> From: Don North <north at alum.mit.edu>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>, "General Discussion: On-Topic Posts
> ?[cctech at classiccmp.org]?" <cctech at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <552370F7.5050500 at alum.mit.edu>
> Content-Type: text/plain; charset=windows-1256; format=flowed
>
> Shouldn't the controller be using the DEC STD 144 bad sector replacement
> table
> in the last sector to transparently remap bad sectors such that, to the
> user,
> the -DC packs appear error free? If this were done each RL02 image should
> appear
> error-free in logical block address space as the hidden remapping of bad
> sectors
> on -DC drives would not be seen by the user (or O/S).
>
> All the other proposed ways of handling -DC bad sectors have serious
> compatibility issues.
>
> Don
>
> On 4/6/2015 3:54 PM, Christopher Parish wrote:
> > Progress is good on the RL02-USB controller. I've gotten complete
> operation working as expected with the usual tools for disk access
> (badblocks, dd, etc.), and SIMH can access the real packs via the
> controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is
> only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those
> with identified bad blocks from the factory) are another story.
> >
> >
> > The issue is most obvious when backing up and restoring disk images.
> Suppose I backup a pack with 1 bad sector. I have two choices of what to do
> with the bad sector (specifically if it's a bad header), I could skip the
> sector (reporting an IO error), or I could report all zeros for the sector.
> >
> >
> > Skipping the sector is a bad idea because the logical address of all
> sectors after it will shift down by one. This will make the disk image not
> work correctly with SIMH, or anything else for that matter, because most
> filesystems address things by physical block (Please correct me if I'm
> wrong here). Remember, we're at the device level (/dev/sda) not the
> partition level (/dev/sda1).
> >
> >
> > Returning all zeros for bad sectors will preserve the block numbers of
> following sectors and work correctly with SIMH, but trying to restore the
> resulting image to another physical pack will probably be impossible given
> the destination disk pack has bad sectors of its own in different spots.
> >
> >
> > The usual trick of having the controller re-map the bad sectors will not
> work because the platters in the RL02 are removable. Writing some mapping
> index on the disk pack or holding back sectors in reserve will break
> compatibility with the original systems (PDP8s/11s/VAXes) and all their
> software (an unacceptable solution).
> >
> >
> > I think I've come to the following conclusions given the restrictions
> above:
> >
> >
> > - Creating and Restoring images with EF packs is unrestricted
> >
> > - SIMH operation with EF packs (online and images) will work perfectly
> >
> > - Creating images of DC packs will work with SIMH if I return zeros for
> the bad blocks
> >
> > - Online use of DC packs work with SIMH assuming no new bad blocks have
> formed since the bad block index was written
> >
> > - If new bad blocks have formed in a pack, SIMH will have to be modified
> so its RL(V)11 can receive error information from the drive, otherwise it
> will incorrectly handle the recovery
> >
> > - Restoring images on DC packs will require special software that can
> move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*)
> >
> > - Using a modern filesystem on EF/DC packs is unrestricted (because they
> can identify and manage bad blocks on their own)
> >
> >
> > First, does all of this seem reasonable?
> >
> >
> > I vaguely remember reading about a program on RT-11 you would run
> (before?) backing up the filesystem. What was this program? How did it
> work? Did it make the data position independent?
> >
> >
> > Christopher
> >
>
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 7 Apr 2015 08:20:27 +0200
> From: shadoooo <shadoooo at gmail.com>
> To: cctech at classiccmp.org
> Subject: Re: RD54 Stopped Spinning
> Message-ID:
> <CAM4zSsX243N0PpBgD5-XUU=OhoXo3bDWRDTScKi=
> c79czUk71Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
> apart from the transistors, I would check for some bad capacitor.
> The analog part with the sensors needs quite clean supply to work good,
> while the motor itself is a big source of spikes and pulses.
> Possibly there could be some supply filter, with electrolytic capacitors
> not working as expected due to age... or with excessive current leakage.
>
> Andrea
>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 07 Apr 2015 12:21:31 +0200
> From: Johnny Billquist <bqt at update.uu.se>
> To: cctalk at classiccmp.org
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523AFAB.5080509 at update.uu.se>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> This might become a long answer.
>
> First of all, back when the RL drives were made, hardware handled bad
> block management wasn't yet popular in that neck of the woods. So bad
> blocks were/are visible to the software. In order to have some
> management of this, DEC had a standard - DEC STD144, which described how
> you kept track of, and managed, bad blocks.
> If you ever wondered where the Unix program bad144 got its name from,
> now you know (and the ultimate stupidness is NetBSD, where they decided
> that only the x86 platform would have bad144, leaving the VAX - the only
> hardware platform who actually had disks following the bad144 standard,
> not having the bad144 program).
>
> The STD144 reserves the last track of the device for pack information.
> In there you have the pack serial number, and also the manufacturer bad
> block list, and also the user bad block list. When/if new blocks are
> detected after the pack is manufactured, they would be placed in the
> user bad block list.
>
> So, a EF pack would simply be a pack with no bad blocks from the
> manufacturer. The manufacturer bad block list would contain no bad
> blocks. This does not mean that the pack could not develop bad blocks
> later.
>
> Now, a total imaging of one RL disk to another is not something you
> should do. That would replace the pack serial number, in addition to the
> issues with the bad block lists. Not to mention that different packs
> have bad blocks in different places.
>
> Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped
> away, or faked. The drive and controller can detect bad blocks, and when
> you try to read one, you'll get an error back. Drivers try a few times,
> and then give up, giving an error back to the user program.
> You should not try anything different.
>
> Now moving over to how software deals with this, essentially all DEC
> OSes have some way or other to mark the known bad sectors as bad when
> the filesystem in created, and then no software will try to use them.
> I have some rough idea on how this is done in RT-11 and RSTS/E, but to
> give details, I'll describe how RSX does it.
> RSX have a program that scans disks for bad blocks. It is called BAD.
> BAD will update the last track with any new bad blocks found.
> A different program is used to create a file system on a disks - INI.
> INI will read the last track of the device, to get the manufacturer and
> user bad block list. INI will then create the file system on the disk,
> and allocate all the bad blocks on the disk to a special file -
> BADBLK.SYS. That way, those blocks are already marked as used, and other
> files created cannot accidentally include those bad blocks.
>
> Copying RL disks with a block by block copy is not something you'd do.
> You'd mount the disk and copy the contents.
>
> So, all disk blocks are numbered just as you would expect. Bad blocks
> are not hidden, or mapped away, or returns zeroes. Doing anything like
> that will break existing software.
>
> Johnny
>
> On 2015-04-07 00:54, Christopher Parish wrote:
> > Progress is good on the RL02-USB controller. I've gotten complete
> operation working as expected with the usual tools for disk access
> (badblocks, dd, etc.), and SIMH can access the real packs via the
> controller's block device (i.e. attach rl0 /dev/sdX). Of course, this is
> only true for RL02K-EF (error-free) packs. The common RL02K-DC packs (those
> with identified bad blocks from the factory) are another story.
> >
> >
> > The issue is most obvious when backing up and restoring disk images.
> Suppose I backup a pack with 1 bad sector. I have two choices of what to do
> with the bad sector (specifically if it's a bad header), I could skip the
> sector (reporting an IO error), or I could report all zeros for the sector.
> >
> >
> > Skipping the sector is a bad idea because the logical address of all
> sectors after it will shift down by one. This will make the disk image not
> work correctly with SIMH, or anything else for that matter, because most
> filesystems address things by physical block (Please correct me if I'm
> wrong here). Remember, we're at the device level (/dev/sda) not the
> partition level (/dev/sda1).
> >
> >
> > Returning all zeros for bad sectors will preserve the block numbers of
> following sectors and work correctly with SIMH, but trying to restore the
> resulting image to another physical pack will probably be impossible given
> the destination disk pack has bad sectors of its own in different spots.
> >
> >
> > The usual trick of having the controller re-map the bad sectors will not
> work because the platters in the RL02 are removable. Writing some mapping
> index on the disk pack or holding back sectors in reserve will break
> compatibility with the original systems (PDP8s/11s/VAXes) and all their
> software (an unacceptable solution).
> >
> >
> > I think I've come to the following conclusions given the restrictions
> above:
> >
> >
> > - Creating and Restoring images with EF packs is unrestricted
> >
> > - SIMH operation with EF packs (online and images) will work perfectly
> >
> > - Creating images of DC packs will work with SIMH if I return zeros for
> the bad blocks
> >
> > - Online use of DC packs work with SIMH assuming no new bad blocks have
> formed since the bad block index was written
> >
> > - If new bad blocks have formed in a pack, SIMH will have to be modified
> so its RL(V)11 can receive error information from the drive, otherwise it
> will incorrectly handle the recovery
> >
> > - Restoring images on DC packs will require special software that can
> move data around the bad-blocks (or a linux RT-11 filesystem driver *wink*)
> >
> > - Using a modern filesystem on EF/DC packs is unrestricted (because they
> can identify and manage bad blocks on their own)
> >
> >
> > First, does all of this seem reasonable?
> >
> >
> > I vaguely remember reading about a program on RT-11 you would run
> (before?) backing up the filesystem. What was this program? How did it
> work? Did it make the data position independent?
> >
> >
> > Christopher
> >
>
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt at softjar.se || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
>
>
> ------------------------------
>
> Message: 14
> Date: Tue, 7 Apr 2015 12:13:47 +0000
> From: Christopher Parish <christopher.parish at parishcomputers.com>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: RE: RL02-USB Controller Status/Problem
> Message-ID:
>
> <639FFF5F324E6D409F42CF2B2F3BB56AB0FF0132 at MBX022-E1-NJ-4.exch022.domain.local
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> > [...]
> > Now, a total imaging of one RL disk to another is not something you
> > should do. That would replace the pack serial number, in addition to the
> > issues with the bad block lists. Not to mention that different packs
> > have bad blocks in different places.
>
> I agree. You're right that the best way to copy a pack is to load up the
> appropriate OS in the simulator and instruct it to do the work. Because it
> has knowledge of the filesystem, it will copy around bad blocks, identify
> new ones, etc. without stomping on the serial number and factory recorded
> bad block data.
>
> > Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped
> > away, or faked. The drive and controller can detect bad blocks, and when
> > you try to read one, you'll get an error back. Drivers try a few times,
> > and then give up, giving an error back to the user program.
> > You should not try anything different.
> > [...]
> > Johnny
>
> I will have to patch SIMH to support this paradigm because right now it
> expects the backing store for its virtual RL02s to be readable at all
> times. IO errors trying to access the underlying "file" halt the
> simulator. Additionally, there is no way to report what type of error
> occurred via USB mass storage, only that fewer blocks were returned than
> expected.
>
> I think I'll need to have two completely different modes of operation.
>
> A USB Mass storage mode would use the pack like a modern hard disk. The
> controller would hide and internally use the last track for bad block
> identification and not expose it to the PC. Also, the controller would
> hold some number of sectors in reserve, presenting a flat, error free
> ~9.8MB disk to the PC. This would work for modern filesystems but be
> completely useless for SIMH and physical computer compatibility.
>
> The other mode will need to be a non mass storage interface like bulk or
> CDC mode specifically for use with SIMH and any custom diagnostics. SIMH
> (after modification) would then be able to access all the raw data on the
> pack and have access to any errors that occur, handling them however it
> wants. Copying packs would need to be done just like it is now, except in
> the simulator. You either mount or image and mount the first disk, load
> your favorite OS in SIMH attached to the physical drive, and instruct it to
> copy disk 1 to disk 2, letting it copy around bad blocks in the manner it
> always has (preserving compatibility).
>
> Christopher
>
>
>
> ------------------------------
>
> Message: 15
> Date: Tue, 07 Apr 2015 13:41:08 +0100
> From: Pete Turnbull <pete at dunnington.plus.com>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523D064.3040305 at dunnington.plus.com>
> Content-Type: text/plain; charset=windows-1256; format=flowed
>
> On 06/04/2015 23:54, Christopher Parish wrote:
> > Progress is good on the RL02-USB controller. I've gotten complete
> > operation working as expected with the usual tools for disk access
> > (badblocks, dd, etc.), and SIMH can access the real packs via the
> > controller's block device (i.e. attach rl0 /dev/sdX).
>
> Very good! I want one :-)
>
> > The issue is most obvious when backing up and restoring disk images.
> > Suppose I backup a pack with 1 bad sector. I have two choices of what
> > to do with the bad sector (specifically if it's a bad header), I
> > could skip the sector (reporting an IO error), or I could report all
> > zeros for the sector.
>
> > The usual trick of having the controller re-map the bad sectors will
> > not work because the platters in the RL02 are removable.
>
> DEC does it by having the driver software remap sectors.
>
> > Writing some
> > mapping index on the disk pack or holding back sectors in reserve
> > will break compatibility with the original systems (PDP8s/11s/VAXes)
> > and all their software (an unacceptable solution).
>
> Eh? Use the existing bad block table which is on an RL01 or RL02, as on
> many other DEC disks.
>
> Return an error. Unless it's a block that's already in the bad block
> table at the end of the disk, in which case return the content of the
> remapped block, of course. If you don't do that, you'll break things in
> DEC OSs.
>
> > I vaguely remember reading about a program on RT-11 you would run
> > (before?) backing up the filesystem. What was this program? How did
> > it work? Did it make the data position independent?
>
> There are several ways to detect or handle bad blocks in RT-11. I
> suspect you're thinking of INIT/BAD or more likely DIR/BAD, or possibly
> BACKUP or FORMAT.
>
> INIT is is the monitor command to create an RT-11 filesystem on a disk;
> the /BAD option (full name BADBLOCKS, can be shortened to as little as
> /BA) tells it to scan the disk and report any bad blocks it finds. With
> no other options, it creates directory entries for files called FILE.BAD
> covering those blocks. INIT/BAD:RETAIN keeps any FILE.BAD it finds, and
> in most versions doesn't actually scan. This is really meant for
> devices that don't have a DEC standard bad block table (like floppies).
>
> Alternatively INIT/BAD/REPLACE doesn't write FILE.BAD but instead
> updates the bad block table at the end of the disk; /REPLACE overwrites
> the table, whereas REPLACE:RETAIN adds to it. Note that the DL(X)
> drivers in RT-11, as in other DEC OSs, know about the bad block table.
>
> But of course you wouldn't use INIT just before making a backup ;-)
> And it wouldn't work if your controller lies and returns zeros for bad
> blocks; that would be a very bad idea and will cause things to fail badly.
>
> The SQUEEZE command compresses a disk by shuffling up all the files
> (except FILE.BAD) to be contiguous (RT-11 always writes individual files
> as contiguous blocks on disk but gaps between files can arise as things
> are deleted or rewritten). It honours the bad block table (and/or
> FILE.BAD), as do other disk utilities, because the drivers do that. If
> your driver doesn't, it'll fail.
>
> If you just want to quickly scan a disk for errors, a common way is to
> do COPY/DEV/IGN DLx: NL: which does a block for block copy of the entire
> disk to the NULL device, reporting errors but not stopping on them
> (/COPY/DEVICE/IGNORE). It's common to do that just after formatting a
> disk, but before INIT, for example if you're working with a non-RT-11
> filesystem. BTW, for other COPY operations, it ignores FILE.BAD files,
> for obvious reasons, unless you specifically include them.
>
> You were probably thinking of the DIR command. /BAD is also an option
> to DIR; it can tell also you which files are affected by bad blocks. It
> scans the entire disk for bad blocks, and even works on non-RT-11 disks.
> If it finds any, it will report the block number in octal and decimal,
> and tell you if it's "Replaced" or "Replaceable" - ie if it's already in
> the bad block table - but it won't change the table for you. The full
> syntax is DIRECTORY/BADBLOCKS[/FILES][/START:n][/END:n]. /FILES will
> tell you what files are affected, assuming it's an RT-11 filesystem;
> /START and /END allow you specify a range rather than the whole disk.
> There's also a /WAIT option that pauses to let you change disks before
> scanning.
>
> BACKUP (or BUP) scans the target disk for bad blocks before copying a
> saveset to it (and stops if it finds any).
>
> You can't FORMAT an RL01 or RL02, but you can FORMAT/VERIFY:ONLY one.
> That writes patterns over the surface to test it, much more thoroughly
> than DIR/BAD, INIT/BAD, COPY/DEV or BACKUP.
>
> --
> Pete
>
> Pete Turnbull
>
>
> ------------------------------
>
> Message: 16
> Date: Tue, 07 Apr 2015 14:14:18 +0100
> From: Pete Turnbull <pete at dunnington.plus.com>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523D82A.7080804 at dunnington.plus.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 07/04/2015 11:21, Johnny Billquist wrote:
> > Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped
> > away, or faked. The drive and controller can detect bad blocks, and when
> > you try to read one, you'll get an error back. Drivers try a few times,
> > and then give up, giving an error back to the user program.
> > You should not try anything different.
>
> Absolutely.
>
> > Copying RL disks with a block by block copy is not something you'd do.
> > You'd mount the disk and copy the contents.
>
> Actually COPY/DEV under RT-11 is commonly used, especially for non-RT-11
> packs. I can't remember what RSX does, but RT-11 /does/ deal with the
> bad block table, by not copying the last track, and copying remapped
> blocks. But in general, under other OSs, yes, not a good idea. It
> would be like using dd in Unix to copy an entire device, including the
> disk label, rather than the partitions.
>
> --
> Pete
>
> Pete Turnbull
>
>
> ------------------------------
>
> Message: 17
> Date: Tue, 07 Apr 2015 14:24:30 +0100
> From: Pete Turnbull <pete at dunnington.plus.com>
> To: "Discussion at classiccmp.org:On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523DA8E.9030908 at dunnington.plus.com>
> Content-Type: text/plain; charset=windows-1256; format=flowed
>
> On 07/04/2015 13:41, Pete Turnbull wrote:
> > The SQUEEZE command [...] honours the bad block table (and/or
> > FILE.BAD), as do other disk utilities, because the drivers do that.
>
> Actually, thinking about it, SQUEEZE probably does it itself, and the
> drivers probably just do error reporting. I think.
>
> --
> Pete
>
> Pete Turnbull
>
>
> ------------------------------
>
> Message: 18
> Date: Tue, 07 Apr 2015 15:58:36 +0100
> From: Pete Turnbull <pete at dunnington.plus.com>
> To: General Discussion: On-Topic and Off-Topic Posts
> <cctalk at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523F09C.5000900 at dunnington.plus.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 07/04/2015 11:21, Johnny Billquist wrote:
>
> > The STD144 reserves the last track of the device for pack information.
> > In there you have the pack serial number, and also the manufacturer bad
> > block list, and also the user bad block list.
>
> While looking for something quite unrelated, I noticed that the RT-11
> Device Handlers Manual says slightly differently. The user list is
> stored, merged with the manufacturing list, in the home block (track 0
> sector 1) of RL01/02 and RK06/07 volumes, beginning at offset 6
> (HB.BAD). The actual replacement blocks are reserved space on the
> second last track (or tracks 0,1 of the last cylinder on RK06/7).
>
> The symbol names for the values in HB.BAD are defined in the .BBRDF
> macro in the distributed file SYSTEM.MLB.
> Offset Name Meaning
> 0 BBR.BD Bad block number.
> 2 BBR.GD Replacement block number.
> BBR.SZ Entry size.
>
> RSX-11 may not be the same?
>
> --
> Pete
>
> Pete Turnbull
>
>
> ------------------------------
>
> Message: 19
> Date: Tue, 7 Apr 2015 11:25:03 -0400
> From: Paul Koning <paulkoning at comcast.net>
> To: "General Discussion: On-Topic and Off-Topic Posts"
> <cctalk at classiccmp.org>
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <BC740651-507D-4C80-891E-38A3726B2641 at comcast.net>
> Content-Type: text/plain; charset=utf-8
>
>
> > On Apr 7, 2015, at 8:41 AM, Pete Turnbull <pete at dunnington.plus.com>
> wrote:
> >
> > On 06/04/2015 23:54, Christopher Parish wrote:
> >> Progress is good on the RL02-USB controller. I've gotten complete
> >> operation working as expected with the usual tools for disk access
> >> (badblocks, dd, etc.), and SIMH can access the real packs via the
> >> controller's block device (i.e. attach rl0 /dev/sdX).
> >
> > Very good! I want one :-)
> >
> >> The issue is most obvious when backing up and restoring disk images.
> >> Suppose I backup a pack with 1 bad sector. I have two choices of what
> >> to do with the bad sector (specifically if it's a bad header), I
> >> could skip the sector (reporting an IO error), or I could report all
> >> zeros for the sector.
> >
> > > The usual trick of having the controller re-map the bad sectors will
> > > not work because the platters in the RL02 are removable.
> >
> > DEC does it by having the driver software remap sectors.
>
> No, DEC does not do that. At least not in RSX, as Johnny described, nor
> in RSTS.
>
> In RSTS, creating a file system on a pack is done with the ?dskint?
> utility. One of its functions is to perform a drive scan, writing and
> verifying all sectors with several data patterns. If a sector is found to
> be bad, it is handled simply by allocating it to the reserved file
> [0,1]badb.sys. This scheme works for all drive types, including those that
> predate DEC Std 144. On packs that have a bad block table, the blocks
> listed in that table are includes in the bad block list that dskint
> determines (I don?t remember if they are checked anyway, or bypassed in the
> check).
>
> I also don?t remember if there was a way to handle blocks going bad
> later. In principle, yes; they could be allocated to badb.sys also. If
> so, a file system check (?onlcln?) would find a double allocated block and
> let you delete the file that was affected.
>
> The first drive type I know of that had anything resembling remapping is
> the RM80, with the ?skip sector? feature, where each track had an extra
> sector, and a flag in the sector header could be used to mark that sector
> as ?skip me and use the spare sector instead?. The first real remapping
> appeared in MSCP, which makes sense because that is the first time that DEC
> drives used logical addressing instead of hard cylinder/track/head
> addressing. At first (UDA50), remapping was done largely in the driver,
> requiring a quantity of code way larger than any other disk driver. In
> subsequent MSCP controllers, it moved entirely into the controller and the
> host simply saw an error free logical block space.
>
> Given all this, an image copy of a disk is not valid, unless the
> destination disk is error free. (Early packs usually were, which is why
> early PDP11 backup programs like ROLLIN did use image copy.) If the
> destination disk has errors, the copying has to be at the file system
> level, either by just copying all files one by one, or by doing an image
> copy that works around destination flaws. The RSTS standalone backup
> program SAVRES is an example of the latter.
>
> paul
>
>
>
> ------------------------------
>
> Message: 20
> Date: Tue, 07 Apr 2015 17:56:34 +0200
> From: Johnny Billquist <bqt at update.uu.se>
> To: cctalk at classiccmp.org
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523FE32.5010600 at update.uu.se>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 2015-04-07 15:14, Pete Turnbull wrote:
> > On 07/04/2015 11:21, Johnny Billquist wrote:
> >> Sp, to get to the meat of it. No, bad blocks are not replaced, or mapped
> >> away, or faked. The drive and controller can detect bad blocks, and when
> >> you try to read one, you'll get an error back. Drivers try a few times,
> >> and then give up, giving an error back to the user program.
> >> You should not try anything different.
> >
> > Absolutely.
> >
> >> Copying RL disks with a block by block copy is not something you'd do.
> >> You'd mount the disk and copy the contents.
> >
> > Actually COPY/DEV under RT-11 is commonly used, especially for non-RT-11
> > packs. I can't remember what RSX does, but RT-11 /does/ deal with the
> > bad block table, by not copying the last track, and copying remapped
> > blocks.
>
> But that don't make sense. You cannot just move one block somewhere else
> because it is bad on the target device. Or just ignore a block because
> it is bad on the source device.
>
> And "remapped" must be something very local to RT-11. RSX do not remap
> any blocks. A block that is bad, is bad. It is still there. No other
> block is substituted for the bad block. And where would those
> substitution blocks come from? There are no hidden extra blocks on an RL
> pack.
>
> RSX simply deals with bad blocks on an RL pack by making sure no file
> accidentally gets them, by putting all the bad blocks into a specific
> file on the file system, intended to hold bad blocks.
>
> > But in general, under other OSs, yes, not a good idea. It
> > would be like using dd in Unix to copy an entire device, including the
> > disk label, rather than the partitions.
>
> Yes.
>
> Johnny
>
>
>
> ------------------------------
>
> Message: 21
> Date: Tue, 07 Apr 2015 17:59:04 +0200
> From: Johnny Billquist <bqt at update.uu.se>
> To: cctalk at classiccmp.org
> Subject: Re: RL02-USB Controller Status/Problem
> Message-ID: <5523FEC8.2070308 at update.uu.se>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 2015-04-07 16:58, Pete Turnbull wrote:
> > On 07/04/2015 11:21, Johnny Billquist wrote:
> >
> >> The STD144 reserves the last track of the device for pack information.
> >> In there you have the pack serial number, and also the manufacturer bad
> >> block list, and also the user bad block list.
> >
> > While looking for something quite unrelated, I noticed that the RT-11
> > Device Handlers Manual says slightly differently. The user list is
> > stored, merged with the manufacturing list, in the home block (track 0
> > sector 1) of RL01/02 and RK06/07 volumes, beginning at offset 6
> > (HB.BAD). The actual replacement blocks are reserved space on the
> > second last track (or tracks 0,1 of the last cylinder on RK06/7).
> >
> > The symbol names for the values in HB.BAD are defined in the .BBRDF
> > macro in the distributed file SYSTEM.MLB.
> > Offset Name Meaning
> > 0 BBR.BD Bad block number.
> > 2 BBR.GD Replacement block number.
> > BBR.SZ Entry size.
> >
> > RSX-11 may not be the same?
>
> You are thinking of/referring to how the file system works. The bad
> block list on the last track is not directly used by the system, since
> this is different from one device to the next.
> RL drives have bad block information on the last track. It is not OS
> dependent.
>
> Johnny
>
>
>
> End of cctalk Digest, Vol 6, Issue 7
> ************************************
>
--
Edward Austin/Эд Остин
109147, Россия, Москва, ул. Марксистская, д. 3
gsm: +44 (0)7726 05 0000 (UK)
gsm: +7 925 871 94 11 (Moscow)
ed at ryer.ru
More information about the cctech
mailing list