> From: Pete Turnbull
> Does anyone have a description of the switch settings for a QBus
> MSV11-M (aka MSV1M) memory card (M7506)?
> .. I can't find the manual ... or any useful notes anywhere.
How odd. I've looked through every plausible DEC QBUS document I've got, and
none mention the MSV11-M! They all jump straight from the MSV11-L to the
MSV11-P. E.g. the "Microcomputer Products Handbook" from 1985 has the
MSV11-L, then the MSV11-P, then the MSV11-Q. (Although it doesn't have the
MSV11-J either, though - although my MSV11-J manual says the first version
was '85.)
I wonder why? Was the MSV11-M a later card? (Well, it must have been...)
There's a Micro-Note (#28) from June '85 which mentions the MSV11-M, so it's
not _that_ late. However, e.g. the "Supermicrosystems Handbook", from 1986,
mentions the MSV11-J, then the MSV11-Q, then the MSV11-P!
I wonder why they left it out? It provides up to 1MB on a dual card, whereas
the MSV11-P only does 512KB on a quad card? So it's not as if it were already
obsolete by 1986 - it's clearly better than something they _did_ include!
Very odd.
Noel
Hi
I'm trying to save a MicroVAX 8350. Seen to the left here:
http://brain.brokenbrain.se/skrot_dh1/20150407_100417.jpg
It's in a DEC half-rack which I sadly don't have room for. So I will ask
to have the CPU module only and any specific rackheaders (for ethernet
and other things, if any).
Is there anything else about that rack specific to the 8350 ?
I have RA72 disks already. And other DEC racks to mount it in.
/P
I have finally managed to get my hands on a TRS-80 Model 1. Trouble is, it
came without a monitor. I have been doing some searching to see if I can
find out what kind of monitor it is and I am left unsure. All I have found
so far is a statement which says it is a TV without a tuner. I am not sure
what that means. I still have a CRT TV, can that be made to work, or have I
bought something that I can't use?
Thanks
Rob
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
I recently received a new BDV11 and booted it up on my 11/23 with whatever ROM it has on board.
It displays the following menu, and I was curious if anyone recognizes it. Just for fun, I'd just like to find out what sort of system this board lived in previously.
Thanks!
<[2J[6;1H PRIMITIVE MENU (V-01)
1. MCR MODE
2. UIS MODE
3. LSI DIAGS
ENTER MENU NUMBER: _
--
Ben Sinclair
ben at bensinclair.com
I am working on the H7104 power supplies for the VAX-11/750 now. The 5V had
a short circuit main switch transistor and a output rectifier diode that
also was a short circuit. Now it works fine into a 0.5 ohm dummy load.
Then when checking the 2.5V supply it had two out of three output
rectifiers short circuited.
So what is it with these rectifiers? They are Unitrode USD5096F but
unfortunately I cannot find any data sheet for them. I asked in another
forum and someone even checked the Unitrode data book for 84-85 but didn't
find the part!
However looking in the print set the diode is listed as 1114197-00 with the
remark "60 AMP POWER SCHOTTKY DIODE"
Is the Unitrode USD5096F a 60 Amp diode? This link tells me it is a 35A
diode:
http://www.electronicsurplus.com/unitrode-usd5096f-diode-35amp-35v-piv
and so does this link:
http://www.ebay.com/itm/35-Amp-35-Volt-Stud-Mounted-Diode-with-Wire-and-Lug…
Is there anyone that can enlighten me here? Is USD509F a 35 Amp part and
then why have DEC used parts that is not as specified in the print set?
/Mattis
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$(a)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
> From: Edward Austin
> 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
See if you can buy the chassis in the UK/EU, that's the heavy part (i.e.
costs the most to ship). You could then buy cards in the US, and have them
sent to you trans-Atlantic; being light, they won't cost much to send. (I
will help, if a seller won't ship internationally - I can also test the cards
to make sure they are working before dispatching them.)
11/73 CPU cards come up regularly for not too much (I just bought one for
$46), and memory, etc can also be had for not too much. What do you want to
do about mass storage? That's going to be the hard part, IMO.
Noel~h
A situation came up where CHM wanted to film a Compaq Deskpro 386, but we didn't have one,
so I've been trying to put a first generation system together (circa 1987), but I'm having trouble locating
a Deskpro 386 keyboard, and Compaq EGA card and monitor. Does anyone have this kicking around?
