[cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again
On Thu, 2023-02-02 at 17:44 -0800, Sellam Abraham via cctalk wrote: > On Thu, Feb 2, 2023 at 3:45 PM Van Snyder via cctalk < > cctalk@classiccmp.org>wrote: > > On Thu, 2023-02-02 at 18:28 -0500, William Sudbrink via cctalk > > wrote: > > > After more than three years, U of Iowa's PDP-8 project active > > > again > > > > Years ago, I had a colleague named Prentiss Knowlton who built > > asolenoid bank to connect to his PDP-8. He put the solenoid bank on > > thekeyboard of the 90-rank Schlicker pipe organ in the All > > SaintsEpiscopal Church in Pasadena, CA. It played the music for his > > wedding. > > Later, he published an album of pipe-organ performances, on the > > sameorgan, entitled "Unplayed by Human Hands." > > https://en.wikipedia.org/wiki/Unplayed_by_Human_Hands > > > > I don't know whether he still has the computer. > > Ooh, very cool! I have his first album (he released two). > Looks like he's presently teaching computer science at UCLA ==> > https://www.uclaextension.edu/instructors/prentiss-knowlton > > I'm going to contact him and interview him about this. I'd like to > know ifthe computer could also select different ranks. Sellam: Prentiss's brother lives across the street from me, but Prentiss lives quite a distance away. You can use my name if you want to. Van > Thanks for the tip, Van. > Sellam > Sellam
[cctalk] Re: ZFS, was [... GreaseWeazle ..]
On Thu, 2 Feb 2023 at 11:54, emanuel stiebler via cctalk
wrote:
>
> On 2023-02-02 04:38, David Brownlee wrote:
>
> > That reminds me (looks at 43.5T of zfs pool that has not had a scrub
> > since 2021).
> >
> > It can be nice to have a filesystem which handles redundancy and also
> > the option to occasionally read all the data, check end to end
> > checksums (in the unlikely case a device returns a successful read
> > with bad data), and fixup everything. Does not eliminate the need for
> > remote copies, but gives a little extra confidence that the master
> > copy is still what it should be :)
>
> So, what else do you guys use, to make sure your data is safe for the
> years to come?
Code which can be public in github, code which cannot be public in
free gitlab account, (code which evokes Cthulhuian mindworms on
reading and should never be shared with others is kept with other
locally backed up files).
The sata on the main machine is held on 6 disks in ZFS raidz2 (takes 3
disks to fail to lose data). Synced to two remote machines (ZFS in
simple config to give integrity but without local redundancy).
Sync is via syncthing with staggered file versioning (keeps 365 days
of changes for any given file). Most data is pushed only from the main
machine, with remotes also able to sync between them, but some folders
are set to sync between all.
Biggest vulnerability would be an exploit in syncthing, or some common
OS level exploit, as all data is online. ("A backup is not a backup
when its online, it's just a copy")
David
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
> On Feb 3, 2023, at 1:12 AM, Chuck Guzis via cctalk > wrote: > > On 2/2/23 21:23, Tom Hunter via cctalk wrote: >> The actual ferrite core doughnuts do not break down with continued use, BUT >> moisture or mechanical impact or vibration will damage or degrade the >> ferrite cores. Otherwise the ferrite doughnut will live and maintain its >> properties "forever". > > Well, I don't know about that. The CDC 7600 had issues with core > overheating and included a "Duty Cycle Integrator" on core. See PDF > page 51, page 2-24: > > http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60367200D_Cyber70-76_Jul75.pdf > > --Chuvk That reminds me of a PDP-11 diagnostic -- not usually run -- called the "core heating test". The way I remember the description is that it would do rapid memory accesses in a set of addresses that are physically close in the core memory (obviously this is model-dependent). The idea was to find marginal memories. One reason for not running that test is that it was very slow. From the same era I recall that our IBM 1620 mod 2 had a heating system for the memory cabinet, and that after power up you had to wait 10 minutes or so for the memory to be warmed up to its normal operating temperature. I don't think I ever saw an explanation why this was done. It's puzzling that temperature would matter. Obviously, when you hit the Curie temperature the data goes away, but for typical magnetic materials that is in the hundreds of degrees. Does the hysteresis curve shift enough at moderate temperatures (a bit over room temperature) to matter? paul
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
> On 02/03/2023 8:25 AM CST Paul Koning via cctalk > wrote: > It's puzzling that temperature would matter. Obviously, when you hit the > Curie temperature the data goes away, but for typical magnetic materials that > is in the hundreds of degrees. Does the hysteresis curve shift enough at > moderate temperatures (a bit over room temperature) to matter? > > paul Yes. The thresholds shift with temperature. Some companines (DEC?) used temperature-compensated amplifiers to address the issue. IBM, on some models like the 1620, kept the cores at a constant (elevated) temperature. https://en.wikipedia.org/wiki/Magnetic-core_memory#Physical_characteristics Will I do not think you can name many great inventions that have been made by married men. Nikola Tesla
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
On Fri, Feb 3, 2023 at 2:41 PM Will Cooke via cctalk wrote: > Yes. The thresholds shift with temperature. Some companines (DEC?) used > temperature-compensated amplifiers to address the issue. IBM, on some models > like the 1620, kept the cores at a constant (elevated) temperature. Most of the core memories that I've worked on, including quite small ones like the HP9100B, have a thermistor physically next to the core array to control the threshold. I also seem to remember there were MAINDECs for various PDP8 and PDP!1 core units that did the worst case sequence for heating the cores and checked the memory was sill operational. -tony
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
On 2/3/23 08:25, Paul Koning via cctalk wrote: It's puzzling that temperature would matter. Obviously, when you hit the Curie temperature the data goes away, but for typical magnetic materials that is in the hundreds of degrees. Does the hysteresis curve shift enough at moderate temperatures (a bit over room temperature) to matter? Yes, it does. Maybe on earlier memories it was worse, but most later core systems had a thermistor in the core plane, and it adjusted the half-select current to put it right in the middle of the range of susceptance (is that the right term?) for that temperature. My recollection is the 1620 had the core planes in a tank of oil, and the 360/50 had a heater in the air stream flowing past the local store core stack. Jon
[cctalk] Nuking an MFM drive with a magnet, format/servo gone?
Question: I just used a strong magnet to wipe an old Maxtor MFM drive (magnet on outside of case). Now the drive will not even seek properly on start up, just endlessly moves the heads.. Is the drive now toast? Do MFM drives have embedded servo information on the platter formatted by the factory? CZ
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
low level format On Fri, Feb 3, 2023 at 11:40 AM Chris Zach via cctalk wrote: > Question: I just used a strong magnet to wipe an old Maxtor MFM drive > (magnet on outside of case). Now the drive will not even seek properly > on start up, just endlessly moves the heads.. > > Is the drive now toast? Do MFM drives have embedded servo information on > the platter formatted by the factory? > > CZ >
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
On Fri, Feb 3, 2023 at 4:40 PM Chris Zach via cctalk wrote: > > Question: I just used a strong magnet to wipe an old Maxtor MFM drive > (magnet on outside of case). Now the drive will not even seek properly > on start up, just endlessly moves the heads.. > > Is the drive now toast? Do MFM drives have embedded servo information on > the platter formatted by the factory? I assume by 'MFM' you mean a drive with an interface similar to the ST412. Embedded servo is rare (unheard-of) on ST412 interfaced drives simply because the manufacturer has no idea how it will be low-level formatted and thus where the sector headers will be. So no safe place for the servo bursts on the data surfaces But a dedicated servo surface is very common on larger such drives. That's why you often see an odd number of data heads. There is a head on each side of each disk, but one is used for the servo. Sounds like you've wiped that. No sensible way to recover I'm afraid -tony
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
On 2/2/23 23:07, Tom Hunter via cctalk wrote: > Chuck, the CDC 7600 duty cycle integrator is really a work-around against > overheating and has nothing to do with core reliability and/or endurance. > > Core and the data stored in it lives "forever" if the operating constraints > of the medium are adhered to (temperature being one of the constraints). > The 7600 was able to push core access past these constraints, hence needed > the duty cycle integrator. Different physical design and/or better cooling > could have been alternatives, but the duty cycle integrator was an easy fix > once the machine was out in the field and core memory started failing due > to overheating. Tom, I know all of that, having programmed a 7600. As a matter of fact, what's not mentioned in the manual is that a tight loop in a PPU (which did not have a duty cycle integrator) could throw parity errors. Just taking issue with your statement that "core memory is forever". Another problem with very old core is that its physical integrity is often an issue. Cores can crack, being essentially ceramics. I'm reminded of the CE fishing around in the oil bath of a 7090 with what amounted to a magnet on a broomstick to grab loose bits of core. --Chuck
[cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man
On Fri, Feb 3, 2023 at 4:45 PM Chuck Guzis via cctalk wrote: > > Another problem with very old core is that its physical integrity is > often an issue. Cores can crack, being essentially ceramics. I'm > reminded of the CE fishing around in the oil bath of a 7090 with what > amounted to a magnet on a broomstick to grab loose bits of core. > > True 'bit rot' !
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
Embedded servo is rare (unheard-of) on ST412 interfaced drives simply because the manufacturer has no idea how it will be low-level formatted and thus where the sector headers will be. So no safe place for the servo bursts on the data surfaces *nod* That's what I would think: MFM should allow you physical access to the heads to write the format as you see fit. So head positioning should be mechanical, not servo based. But a dedicated servo surface is very common on larger such drives. That's why you often see an odd number of data heads. There is a head on each side of each disk, but one is used for the servo. This is a Maxtor 2190. The RD54 base disk. I've been having major problems trying to format them on my RQDX3, I'll post that adventure in a bit. In a nutshell the drives only partially format then error out. On Dave G's MFM emulator all the tracks appear to be there. Sounds like you've wiped that. No sensible way to recover I'm afraid Yep, with 15 yeads it had a servo platter that is gone. Oh well, it's securely erased :-) I'll toss the drive, keep the electronics interface and keep it in mind for the future. C
[cctalk] Formatting and using RQDX3's and 2190's.
Decided to spend some time working on my 11/73 with MFM drives. Currently it has one of my RQDX3 boards (I have 3, 1 in attic), a 40mb ST412 drive (the half height Seagate whatever) which works fine. No issues there. I'm trying to format an RD54 compatible drive and am running into major issues. First, my two RWDX3's have different ROM dates, the old one is 1986 and the new one is 1990. This is important because I can't boot RX33 disk images with my GoTek using the old card but I can using the new one. Question: I'm guessing the old ROMs only supported RX50 disks? Or is it a secret jumper setting. Anyway I do have both RX33 and RX50 versions of XXDP so not a big issue. On to formatting. The old controller (which I used for the 40mb Seagate) had pins 2-3 jumpered on W23. With that the RD54 was able to autoformat but then would crash xxdp as soon as the initial format was done. Odd. So I used the new controller with 1-2 and 3-4 jumpered. Same problem. Then I tried having 1-2 jumpered and did a manual format (not autoformat, select RD54, etc) I noticed that on the old board it would ask me for the date when doing this kind of format, on the new board it would just ask me for the serial number. Odd. Question: Is the ZRQCH0.BIN file calling different routines in the RQDX3 ROM? Anyway after this the drive would format but then do endless seek errors on the "read" portion of the disk check. Two drives did this, so it's probably not the drives. Odd. Putting the drives on the Dave Gesswin MFM reader showed all cylinders could be read. Question: Can Dave G's board be used to low level format an RD54? Can it test physical disk for errors (wasn't sure) Now the drives only format for a minute or two before throwing errors. Looks like something is very confused on XXDP. Not going to try any other disks until I figure this out. Thoughts? Different sites say different things about the RQDX3 jumpers, some say to jumper 2-3 to allow more than 7 heads, some say to jumper pins 1-2 and some say jumper pins 1-2 on "early ROM" and 1-2 3-4 on "later ROM". This is a serious pain, but just what settings should be done to allow low level formatting, and did my previous attempts to low level wedge these disks from the RQDX3 point of view? Can I do a low level wipe with Dave Gesswin's board/software? Thanks! Chris
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
On Fri, Feb 3, 2023 at 4:57 PM Chris Zach via cctalk wrote: > Yep, with 15 yeads it had a servo platter that is gone. Oh well, it's > securely erased :-) I'll toss the drive, keep the electronics interface > and keep it in mind for the future. If you have the tools, it's worth carefully dismantling the dead HDA taking photos as you go and keeping parts like the heads and flexiprint. Other bits like the positioner magnet and spinde motor mght be worth keeping too. Some months ago I was working on a Toshiba hard drive in a Stride 440 and I wish I'd had some idea of what was on the flexiprint between the logic board connector and the heads. Of course without a clean room I didn't dare open the HDA, but had a defective or dismantled one been available I'd have paid reasonable money for it. -tony
[cctalk] Re: Formatting and using RQDX3's and 2190's.
On 2023-02-03 12:09, Chris Zach via cctalk wrote: Decided to spend some time working on my 11/73 with MFM drives. Currently it has one of my RQDX3 boards (I have 3, 1 in attic), a 40mb ST412 drive (the half height Seagate whatever) which works fine. No issues there. I'm trying to format an RD54 compatible drive and am running into major issues. First, my two RWDX3's have different ROM dates, the old one is 1986 and the new one is 1990. This is important because I can't boot RX33 disk images with my GoTek using the old card but I can using the new one. Question: I'm guessing the old ROMs only supported RX50 disks? Or is it a secret jumper setting. Anyway I do have both RX33 and RX50 versions of XXDP so not a big issue. On to formatting. The old controller (which I used for the 40mb Seagate) had pins 2-3 jumpered on W23. With that the RD54 was able to autoformat but then would crash xxdp as soon as the initial format was done. Odd. So I used the new controller with 1-2 and 3-4 jumpered. Same problem. Then I tried having 1-2 jumpered and did a manual format (not autoformat, select RD54, etc) I noticed that on the old board it would ask me for the date when doing this kind of format, on the new board it would just ask me for the serial number. Odd. Question: Is the ZRQCH0.BIN file calling different routines in the RQDX3 ROM? Anyway after this the drive would format but then do endless seek errors on the "read" portion of the disk check. Two drives did this, so it's probably not the drives. Odd. Putting the drives on the Dave Gesswin MFM reader showed all cylinders could be read. Question: Can Dave G's board be used to low level format an RD54? Can it test physical disk for errors (wasn't sure) Now the drives only format for a minute or two before throwing errors. Looks like something is very confused on XXDP. Not going to try any other disks until I figure this out. Thoughts? Different sites say different things about the RQDX3 jumpers, some say to jumper 2-3 to allow more than 7 heads, some say to jumper pins 1-2 and some say jumper pins 1-2 on "early ROM" and 1-2 3-4 on "later ROM". This is a serious pain, but just what settings should be done to allow low level formatting, and did my previous attempts to low level wedge these disks from the RQDX3 point of view? Can I do a low level wipe with Dave Gesswin's board/software? Thanks! Chris Have you tired manually telling ZRQC that it is an RD54? Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
I thoug the right one was st512...can you enlighten me on this subject Tony? Enviado do meu Tele-Movel > I assume by 'MFM' you mean a drive with an interface similar to the ST412. > -tony >
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
Or ST506 ? On Fri, Feb 3, 2023 at 5:21 PM Alexandre Souza via cctalk < cctalk@classiccmp.org> wrote: > I thoug the right one was st512...can you enlighten me on this subject > Tony? > > Enviado do meu Tele-Movel > > > > I assume by 'MFM' you mean a drive with an interface similar to the > ST412. > > -tony > > >
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
On Fri, Feb 3, 2023 at 5:21 PM Alexandre Souza wrote: > > I thoug the right one was st512...can you enlighten me on this subject Tony? I've never heard it called that. It's often called 'ST506' but that drive had a few differences from the later ones. it didn't support buffered seeks AFAIK. The ST412 did and was the most common of a family of 3 similar drives (ST406, ST412, ST419) so it tends to be used as the de-facto name of the interface. -tony
[cctalk] Re: Formatting and using RQDX3's and 2190's.
On Fri, Feb 03, 2023 at 12:09:27PM -0500, Chris Zach wrote: > > Question: Can Dave G's board be used to low level format an RD54? Can it > test physical disk for errors (wasn't sure) > The read test you did should have told you if there were sectors with errors. Using my tools to low level format is only sort of possible. DEC got overly creative with their disk format so some sectors are formmatted differently for controller use. I've haven't written code to be able to reproduce that. If you have an image of a good disk mfm_write can write that to another drive. Somewhat fiddly. Problem with that is it will not have the bad sectors on the new drive properly mapped out so you will get read errors. If there is a tool you can run to test the disk and mark new bad sectors that should fix that problem. I do have an RD54 image that can be used with mfm_write. Search in page for RD54 http://www.pdp8online.com/mfm/status.shtml
[cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again
On 2023-02-02 4:44 p.m., Van Snyder via cctalk wrote: On Thu, 2023-02-02 at 18:28 -0500, William Sudbrink via cctalk wrote: After more than three years, U of Iowa's PDP-8 project active again Years ago, I had a colleague named Prentiss Knowlton who built a solenoid bank to connect to his PDP-8. He put the solenoid bank on the keyboard of the 90-rank Schlicker pipe organ in the All Saints Episcopal Church in Pasadena, CA. It played the music for his wedding. Later, he published an album of pipe-organ performances, on the same organ, entitled "Unplayed by Human Hands." https://en.wikipedia.org/wiki/Unplayed_by_Human_Hands I don't know whether he still has the computer. Could be hiding in the Organ. :) They don't make I/O devices like that any more. Ben.
[cctalk] Re: Formatting and using RQDX3's and 2190's.
I do have an RD54 image that can be used with mfm_write. Search in page for RD54
http://www.pdp8online.com/mfm/status.shtml
Ok. Hm. So the command would be ./mfm_write --emulation RD54_A -d3?
This is possibly better than nothing: I could use this to put some sort
of format on the drive, then try letting xxdp reformat it. Right now I'm
getting this:
DR>START
CHANGE HW (L) ? Y
# UNITS (D) ? 1
UNIT 0
Enter controller IP Address (O) 172150 ?
What unit do you want to format [0-255] (D) 0 ?
Would you like to revector a single LBN only [Y/N] (L) N ?
Do you want to use the "AUTOFORMAT" Mode [Y/N] (L) Y ?
Enter unit serial number [1-32000] (D) 12345 ?
WARNING
ALL DATA ON SELECTED DRIVE WILL BE DESTROYED
Write protect all drives not being formatted.
Please verify that the selected drive is ON LINE
and NOT write protected.
If formatting RX33 media, insert media to be
formatted in the selected drive.
Do you wish to continue [Y/N] (L) Y ? Y
Autosizer found:
Unit Cylinders Drive Name
0 1225 RD54
1 RX33 Diskette (FORMATABLE)
MSCP Controller Model: 19
Microcode Version: 1
Formatting of Drive 0 Begun.
(Oddly enough the old controller doesn't display the progress. I really
think it's just talking to the RQDX3 and that is calling the shots as
the later ROMs do tell you how far it is and what it's doing which is nice)
ZRQC SYS FTL ERR 7 ON UNIT 00 TST 001 SUB 000 PC: 105742
Controller has reported a fatal error in the FORMAT program.
Status: RCT write error
Drive 0 was not formatted successfully.
ZRQC EOP1
1 TOTAL ERRS
[cctalk] Re: ST512 [WAS:RE: Re: Nuking an MFM drive with a magnet, format/servo gone?]
The ST512 was a thin-film head version of the ST506, per Seagate : "This increased capacity is accomplished by using the inner portion of the disc surface that was previously unused and by increasing the disc track density from 255 tracks per inch to 270 tracks per inch To reliably use the inner portion of the disc. The ST512 uses a new type of read/write head - a "thin film" head." It was dropped in 1981 due to the lack of a reliable supply of heads and replaced by the ST412. -Original Message- From: Tony Duell [mailto:ard.p850...@gmail.com] Sent: Friday, February 03, 2023 9:27 AM To: Alexandre Souza Cc: General Discussion: On-Topic and Off-Topic Posts Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? On Fri, Feb 3, 2023 at 5:21 PM Alexandre Souza wrote: > > I thoug the right one was st512...can you enlighten me on this subject Tony? I've never heard it called that. It's often called 'ST506' but that drive had a few differences from the later ones. it didn't support buffered seeks AFAIK. The ST412 did and was the most common of a family of 3 similar drives (ST406, ST412, ST419) so it tends to be used as the de-facto name of the interface. -tony
[cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again
On 2/3/23 10:22, ben via cctalk wrote: > Could be hiding in the Organ. :) > They don't make I/O devices like that any more. > Ben. Very old technology. Pre-electronic Welke Vorsetzer, electronics Marantz Pianocorder and the full-integrated into pianos Sony Disklavier. Remember the radio program "Keyboard Immortals Play Again" hosted by Joseph Tushinsky (President of Sony Superscope)? Or am I dating myself again --Chuck
[cctalk] Re: Formatting and using RQDX3's and 2190's.
Wow, this is interesting Dave. Took one of the "formatted badly" disks and did a write of your file. root@beaglebone:~/mfm# ./mfm_write --emulation RD54_A -d3 -c1224 -h15 -s 17 Board revision C detected Then a read of the disk: root@beaglebone:~/mfm# ./mfm_read --analyze -e rd.dsk Board revision C detected Found drive at select 3 Returning to track 0 Drive RPM 3596.5 Matches count 34 for controller DEC_RQDX3 Header CRC: Polynomial 0x1021 length 16 initial value 0x Sector length 512 Data CRC: Polynomial 0x1021 length 16 initial value 0x Interleave mismatch previous entry 0, 10 was 2 now 0 Number of heads 15 number of sectors 17 first sector 0 Unable to determine interleave. Interleave value is not required Drive supports buffered seeks (ST412) Found cylinder 200 expected 1224 Disk has recalibrated to track 0 Stopping end of disk search due to recalibration Number of cylinders 1224, 159.8 MB Command line to read disk: --format DEC_RQDX3 --sectors 17,0 --heads 15 --cylinders 1224 --header_crc 0x,0x1021,16,0 --data_crc 0x,0x1021,16,0 --sector_length 512 --retries 50,4 --drive 3 Retries failed cyl 0 head 0 Bad sectors on cylinder 0 head 0: 0 1 2 Retries failed cyl 0 head 3 Bad sectors on cylinder 0 head 3: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 4 Bad sectors on cylinder 0 head 4: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 5 Bad sectors on cylinder 0 head 5: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 6 Bad sectors on cylinder 0 head 6: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 7 Bad sectors on cylinder 0 head 7: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 8 Bad sectors on cylinder 0 head 8: 0 1 2 3 4 5 6 7 8 9 10 11 12H 13 14 15 16 Retries failed cyl 0 head 9 Bad sectors on cylinder 0 head 9: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 10 Bad sectors on cylinder 0 head 10: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 11 Bad sectors on cylinder 0 head 11: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 12 Bad sectors on cylinder 0 head 12: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 13 Bad sectors on cylinder 0 head 13: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 So looks like the disk is either not taking the format or something is very very wrong. Wonder what happened to all these disks C
[cctalk] Q-BUS Boards available
I have the following Q-BUS boards available. M7168 VCB02, QDSS Q 4-plane colour bitmap module M7169 VCB02, QDSS Q 4-plane video controller module M7608 MS630 RAM for KA630 M7608 MS630 RAM for KA630 M7606 KA630 Microvax II CPU M7620 KA650 Q MicroVAX III CPU M7165 Qbus SDI disk adapter I also have a Smoke Signal Broadcasting, dual 8" floppy set and a SS50 bus controller for the same. All are available for pick-up in Queen Creek, AZ, USA. If there's no interest, all will go to recycling.
[cctalk] Re: Q-BUS Boards available
On 2023-02-03 16:47, David Coolbear via cctalk wrote: I have the following Q-BUS boards available. M7168 VCB02, QDSS Q 4-plane colour bitmap module M7169 VCB02, QDSS Q 4-plane video controller module M7608 MS630 RAM for KA630 M7608 MS630 RAM for KA630 M7606 KA630 Microvax II CPU M7620 KA650 Q MicroVAX III CPU M7165 Qbus SDI disk adapter I also have a Smoke Signal Broadcasting, dual 8" floppy set and a SS50 bus controller for the same. All are available for pick-up in Queen Creek, AZ, USA. If there's no interest, all will go to recycling. I would love to take the 4 Microvax boards off your hands if nobody else is interested, I am in Toronto, ON, where are you and what would it cost to get them to me? cheers, Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591
[cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone?
Chris, what kind of magnet did you use? If it was an electromagnet I could imagine that you caused physical damage by something heating up sufficiently. If it was a permanent magnet then it might indeed be servo data which has been erased. Either way I expect you need a very strong magnetic field to erase a hard drive from the outside. Tom On Sat, 4 Feb 2023, 12:40 am Chris Zach via cctalk, wrote: > Question: I just used a strong magnet to wipe an old Maxtor MFM drive > (magnet on outside of case). Now the drive will not even seek properly > on start up, just endlessly moves the heads.. > > Is the drive now toast? Do MFM drives have embedded servo information on > the platter formatted by the factory? > > CZ >
[cctalk] Re: Formatting and using RQDX3's and 2190's.
Well, formatting an RD53 seems to be working. And the rev 4 ROMs are
much nicer than the rev 3 in terms of talking to you.
Unit Cylinders Drive Name
0 1024 RD53
1 RX33 Diskette (FORMATABLE)
MSCP Controller Model: 19
Microcode Version: 4
Formatting of Drive 0 Begun.
FORMAT PROGRESS REPORT -
1 minute into format Formatting tracks, LBN # 28816
2 minutes into format Formatting tracks, LBN # 57682
3 minutes into format Formatting tracks, LBN # 86514
4 minutes into format Formatting tracks, LBN # 115363
5 minutes into format Reading defect list
6 minutes into format Replacing defect # 3 on head # 0
7 minutes into format Replacing defect # 7 on head # 0
8 minutes into format Replacing defect # 1 on head # 1
9 minutes into format Reading defect list
10 minutes into format Replacing defect # 1 on head # 7
11 minutes into format Third check pass, writing LBN # 31399
12 minutes into format Third check pass, writing LBN # 62815
13 minutes into format Third check pass, writing LBN # 93959
14 minutes into format Third check pass, writing LBN # 125239
15 minutes into format Third check pass, reading LBN # 17935
16 minutes into format Third check pass, reading LBN # 49487
17 minutes into format Third check pass, reading LBN # 80495
18 minutes into format Third check pass, reading LBN # 104336
19 minutes into format Third check pass, reading LBN # 126055
Format Completed.
00012 Rev LBNs
0 Bad RBNs
0 Bad DBNs
0 Bad XBNs
1 retired
FCT used successfully.
Drive 0 has been formatted successfully.
ZRQC EOP1
0 TOTAL ERRS
On 2/3/2023 1:20 PM, David Gesswein via cctalk wrote:
On Fri, Feb 03, 2023 at 12:09:27PM -0500, Chris Zach wrote:
Question: Can Dave G's board be used to low level format an RD54? Can it
test physical disk for errors (wasn't sure)
The read test you did should have told you if there were sectors with errors.
Using my tools to low level format is only sort of possible. DEC got overly
creative with their disk format so some sectors are formmatted differently for
controller use. I've haven't written code to be able to reproduce that.
If you have an image of a good disk mfm_write can write that to another drive.
Somewhat fiddly. Problem with that is it will not have the bad sectors on
the new drive properly mapped out so you will get read errors. If there is
a tool you can run to test the disk and mark new bad sectors that should fix
that problem.
I do have an RD54 image that can be used with mfm_write. Search in page for RD54
http://www.pdp8online.com/mfm/status.shtml
[cctalk] RQDX3's: Lessons learned.
Some thoughts on this day of working on MFM drives: 1) MFM drives are just going bad. They were always kind of meh in terms of reliability, but I think even since 2019 (the last time I checked these drives) things have gotten worse. Drives which were readable and good then are now either shot or throwing errors and they have had an easy 3+ years in my upstairs room. 2) There are at least two RQDX3 ROM sets. The earlier one does not support the RX33 floppy and doesn't give any info during formatting. The later version (Version 4) does support the RX33 and is a lot nicer. 3) Seagate drives seem to be pretty good, especially the 20mb ones. They have no problems, work well, and are pretty right-sized for an RT11 system. 4) RD53 drives are weird. Their main failure is the drive head positioner just gets stuck and needs to be worked loose. Unfortunately that requires removing the lid. Fortunately there is a good filter in the drive along with an air handler that runs air from inside the drive body through the filter, then into the spindle where it is blown over the heads. Result is a pretty clean drive on the inside and so far opening the lid doesn't seem to be a recipe for instant destruction. Go figure. I may try an RD53 in one of my Pro/380's. It's about time I loaded up the final version of P/OS, as I can use the Gotek floppy to load everything instead of screwing with the RX50's. Or can I do that and switch disks on the fly with a single Gotek... Hm. 5) For anything bigger, it's time to retire the MFM drives. Unlike RL02's these things just were not that reliable when new and at this point are kind of falling apart. I have not had any trouble with the ESDI disks, but it might just be a matter of time. Perhaps I should look into duplexing my 330mb CDC drive in the 11/84 CZ
[cctalk] Re: [SPAM] RQDX3's: Lessons learned.
I’d just like to say that 25 years ago, RD53’s were *EVIL*. I do have one that I should try taking apart. I failed to back it up the first time I powered it on. It didn’t boot the second time. ESDI or SCSI is the way to go, at least that was true 20-25 years ago. Today I’d be inclined to say SCSI is the way to go. Zane > On Feb 3, 2023, at 7:48 PM, Chris Zach via cctalk > wrote: > > Some thoughts on this day of working on MFM drives: > > 1) MFM drives are just going bad. They were always kind of meh in terms of > reliability, but I think even since 2019 (the last time I checked these > drives) things have gotten worse. Drives which were readable and good then > are now either shot or throwing errors and they have had an easy 3+ years in > my upstairs room. > > 2) There are at least two RQDX3 ROM sets. The earlier one does not support > the RX33 floppy and doesn't give any info during formatting. The later > version (Version 4) does support the RX33 and is a lot nicer. > > 3) Seagate drives seem to be pretty good, especially the 20mb ones. They have > no problems, work well, and are pretty right-sized for an RT11 system. > > 4) RD53 drives are weird. Their main failure is the drive head positioner > just gets stuck and needs to be worked loose. Unfortunately that requires > removing the lid. Fortunately there is a good filter in the drive along with > an air handler that runs air from inside the drive body through the filter, > then into the spindle where it is blown over the heads. Result is a pretty > clean drive on the inside and so far opening the lid doesn't seem to be a > recipe for instant destruction. Go figure. > > I may try an RD53 in one of my Pro/380's. It's about time I loaded up the > final version of P/OS, as I can use the Gotek floppy to load everything > instead of screwing with the RX50's. Or can I do that and switch disks on the > fly with a single Gotek... Hm. > > 5) For anything bigger, it's time to retire the MFM drives. Unlike RL02's > these things just were not that reliable when new and at this point are kind > of falling apart. I have not had any trouble with the ESDI disks, but it > might just be a matter of time. Perhaps I should look into duplexing my 330mb > CDC drive in the 11/84 > > CZ
[cctalk] Re: [SPAM] RQDX3's: Lessons learned.
Yeah at this point pop it open, unlock the heads (the white cam down at the base there, trip it) and get the heads to move. They should smoothly move with a bit of effort. Then fire it up and see if anything works. I'm going to run this one for a bit in the backup pdp11 here, see if it runs if you fire it up every month or two. Once again what do I have to lose :-) I should probably install a TK50 for backups. C On 2/3/2023 11:34 PM, Zane Healy wrote: I’d just like to say that 25 years ago, RD53’s were *EVIL*. I do have one that I should try taking apart. I failed to back it up the first time I powered it on. It didn’t boot the second time. ESDI or SCSI is the way to go, at least that was true 20-25 years ago. Today I’d be inclined to say SCSI is the way to go. Zane On Feb 3, 2023, at 7:48 PM, Chris Zach via cctalk wrote: Some thoughts on this day of working on MFM drives: 1) MFM drives are just going bad. They were always kind of meh in terms of reliability, but I think even since 2019 (the last time I checked these drives) things have gotten worse. Drives which were readable and good then are now either shot or throwing errors and they have had an easy 3+ years in my upstairs room. 2) There are at least two RQDX3 ROM sets. The earlier one does not support the RX33 floppy and doesn't give any info during formatting. The later version (Version 4) does support the RX33 and is a lot nicer. 3) Seagate drives seem to be pretty good, especially the 20mb ones. They have no problems, work well, and are pretty right-sized for an RT11 system. 4) RD53 drives are weird. Their main failure is the drive head positioner just gets stuck and needs to be worked loose. Unfortunately that requires removing the lid. Fortunately there is a good filter in the drive along with an air handler that runs air from inside the drive body through the filter, then into the spindle where it is blown over the heads. Result is a pretty clean drive on the inside and so far opening the lid doesn't seem to be a recipe for instant destruction. Go figure. I may try an RD53 in one of my Pro/380's. It's about time I loaded up the final version of P/OS, as I can use the Gotek floppy to load everything instead of screwing with the RX50's. Or can I do that and switch disks on the fly with a single Gotek... Hm. 5) For anything bigger, it's time to retire the MFM drives. Unlike RL02's these things just were not that reliable when new and at this point are kind of falling apart. I have not had any trouble with the ESDI disks, but it might just be a matter of time. Perhaps I should look into duplexing my 330mb CDC drive in the 11/84 CZ
