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: 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: > > 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: &lt;000d01d070cb$04a0bf60$0de23e20$(a)classiccmp.org&gt; 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> 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. 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: > > > 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 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: 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: 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: 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*) 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: 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*) 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: 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*) 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" 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. 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: > 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 :-) DEC does it by having the driver software remap sectors. 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. 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: Absolutely. 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: 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: 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 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. 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 ************************************