From mhuffstutter@outlook.com Tue Nov 1 00:04:18 2022 From: Mark Huffstutter To: cctalk@classiccmp.org Subject: [cctalk] Re: LC:M+L (Living Computer Museum) Date: Tue, 01 Nov 2022 00:04:02 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6067128831187479424==" --===============6067128831187479424== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Chuck, They did close to the public for a while, in around June of 2020, But they re-opened a while back now, and are back on their standard Sunday open to public day sched. Mark -----Original Message----- From: Chuck Guzis via cctalk Sent: Monday, October 31, 2022 4:47 PM To: Rich Alderson via cctalk Cc: Chuck Guzis Subject: [cctalk] Re: LC:M+L (Living Computer Museum) On 10/31/22 16:31, Rich Alderson via cctalk wrote: > > That's as much as I know. I'm a bit curious if the Connection Museum managed to stay open during the Plague. Does anyone know? -- --Chuck --===============6067128831187479424==-- From ccth6600@gmail.com Tue Nov 1 06:46:15 2022 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: LC:M+L (Living Computer Museum) Date: Tue, 01 Nov 2022 14:45:39 +0800 Message-ID: In-Reply-To: <4N1Ttr2P4mzfYm@panix5.panix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1859004941006840805==" --===============1859004941006840805== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you Rich for shedding light on this. Most of it makes sense to me, but the secrecy part where you weren't allowed to talk to those still at the museum is weird. I can't see any possible commercial reason for preventing former engineering staff to talk with their former colleagues or replacements. If anything you would think that any new staff would be encouraged to talk to the engineers who left to benefit from their experience. As I said this appears to be rather strange. On Tue, 1 Nov 2022, 7:31 am Rich Alderson via cctalk, wrote: > First, let me thank Sellam and Tom for inviting me to comment on this > topic. > > LCM+L closed its doors to the public in March 2020, at the height of the > initial pandemic (in the sense that it had become clear that the Covid-19 > virus > was not a passing thing), because our entire mission was to make possible > actual physical contact between visitors to the museum and vintage > computing > engines of various stripe. There was no way to allow visitors to continue > to > touch all the hardware which would protect both visitors and the equipment. > > Tour guides and front desk personnel were immediately let go, because it > was > clear that it would be several months, up to a year, before we could open > again. Professional museum staff (curator, educational coordinator, etc.) > were > retained for a short while, to wind things down. The engineers were put to > work winding things down: Creating power-down-bring-up documentation, > backing > up software on those systems for which that was necessary, and generally > making > it possible to close up shop with an eye to opening again in a year (the > target > period). > > This project was the response to the original order simply to turn > everything > off. We pointed out vociferously how much damage that would do to the > dinosaurs, reminding the nontechnical powers-that-be of just how long it > had > taken to make most of the vintage hardware work again, and that they could > plan > on a month of restoration per month of down time, before the museum could > be > reopened after the decision was made to do so. > > All of the engineers, which the exception of the manager of the department, > were laid off as of 1 July 2020. None of us was allowed to return to the > museum at any future time, and no one associated with the mothballed > museum was > allowed to talk to any of us. > > All of that is by way of saying that I have no information on the internal > state of the collection, or of the museum which we built on it. > > As for the status of the collection: While we built the museum, there was > a > private foundation set up which acquired items for the collection, > generally by > purchase. After 5 years of successful operations, with year over year > increases in visitor counts, ongoing relationships with several school > districts for instructional field trips, and worldwide acclaim, the > decision > was to taken to move to a 501(c)(3) public charity. This transition was > under > way when Paul died suddenly; that placed things into limbo because the > transition was incomplete, and the estate could not do things that he could > have done in person. > > That's as much as I know. > > Rich > Alderson > > P. S. After the layoff, I looked for work for a few months, with nary a > nibble. I've officially been retired for tax purposes since > September 2021. > --===============1859004941006840805==-- From pontus@dfupdate.se Tue Nov 1 13:43:22 2022 From: pontus To: cctalk@classiccmp.org Subject: [cctalk] Re: LC:M+L (Living Computer Museum) Date: Tue, 01 Nov 2022 14:43:03 +0100 Message-ID: In-Reply-To: <4N1Ttr2P4mzfYm@panix5.panix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1882161088471816150==" --===============1882161088471816150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thank you for sheding some light on what transpired. Regards, Pontus On 2022-11-01 00:31, Rich Alderson via cctalk wrote: > First, let me thank Sellam and Tom for inviting me to comment on this > topic. > > LCM+L closed its doors to the public in March 2020, at the height of > the > initial pandemic (in the sense that it had become clear that the > Covid-19 virus > was not a passing thing), because our entire mission was to make > possible > actual physical contact between visitors to the museum and vintage > computing > engines of various stripe. There was no way to allow visitors to > continue to > touch all the hardware which would protect both visitors and the > equipment. > > Tour guides and front desk personnel were immediately let go, because > it was > clear that it would be several months, up to a year, before we could > open > again. Professional museum staff (curator, educational coordinator, > etc.) were > retained for a short while, to wind things down. The engineers were > put to > work winding things down: Creating power-down-bring-up documentation, > backing > up software on those systems for which that was necessary, and > generally making > it possible to close up shop with an eye to opening again in a year > (the target > period). > > This project was the response to the original order simply to turn > everything > off. We pointed out vociferously how much damage that would do to the > dinosaurs, reminding the nontechnical powers-that-be of just how long > it had > taken to make most of the vintage hardware work again, and that they > could plan > on a month of restoration per month of down time, before the museum > could be > reopened after the decision was made to do so. > > All of the engineers, which the exception of the manager of the > department, > were laid off as of 1 July 2020. None of us was allowed to return to > the > museum at any future time, and no one associated with the mothballed > museum was > allowed to talk to any of us. > > All of that is by way of saying that I have no information on the > internal > state of the collection, or of the museum which we built on it. > > As for the status of the collection: While we built the museum, there > was a > private foundation set up which acquired items for the collection, > generally by > purchase. After 5 years of successful operations, with year over year > increases in visitor counts, ongoing relationships with several school > districts for instructional field trips, and worldwide acclaim, the > decision > was to taken to move to a 501(c)(3) public charity. This transition > was under > way when Paul died suddenly; that placed things into limbo because the > transition was incomplete, and the estate could not do things that he > could > have done in person. > > That's as much as I know. > > Rich > Alderson > > P. S. After the layoff, I looked for work for a few months, with nary > a > nibble. I've officially been retired for tax purposes since > September 2021. --===============1882161088471816150==-- From gavin@learn.bio Tue Nov 1 14:37:18 2022 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] 50 Years of the HP 3000 Date: Tue, 01 Nov 2022 09:36:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3310935931350063098==" --===============3310935931350063098== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Well, here we are. If you boot up a classic HP 3000 system and simply hit return when it asks you for the date and time, it will default to: HP32002E.01.00 WHICH OPTION ? COO ANY CHANGES? N DATE (M/D/Y)? WED, NOV 1, 1972, 12:00 AM LOG FILE NUMBER 64 ON *WELCOME* :HELLO OPERATOR.SYS;HIPRI 0:00/13/SP#6/SPOOLED OUT 0:00/#S1/14/LOGON FOR: OPERATOR.SYS,OPERATOR ON LDEV #20 HP3000 / MPE V E.01.00 (BASE E.01.00). WED, NOV 1, 1972, 12:00 AM which is exactly 50 years ago today. November 1972 was the month that the very first HP 3000 systems were shipped to customers. Shortly after this, those initial deliveries were all hastily recalled when it quickly became clear that they were not yet capable of living up to their specifications. The 3000 however would go on to recover from this event and eventually became one of HP's most successful and profitable product lines, and one of the most beloved computer systems of all time, regularly beating out IBM, DEC, DG, and others in customer satisfaction surveys. For some stories about the earliest days of the platform, I refer you to the words of Bob Green http://www.robelle.com/smugbook/classic.html and Bill Foster http://www.teamfoster.com/hewlett-packard who were there. The original "Classic" CISC HP 3000 systems live on today through Dave Bryan's most excellent SIMH simulation http://simh.trailing-edge.com/hp/ and I have a turn-key setup which will let you have your own 1980-vintage HP 3000 system up and running in a couple minutes which is downloadable from my Google Drive at https://drive.google.com/file/d/16vaNUrmfs2aQpjdQijG4PZmJaNu3hfcz (Save the zip file using the download link in the upper right then extract it anywhere convenient and see the README file for further instructions) This only includes a SIMH binary for Windows, but you can also build a SIMH executable from Dave Bryan's source above for your platform of choice and use the rest of my infrastructure. MPE Forever. G. --===============3310935931350063098==-- From ethan.dicks@gmail.com Tue Nov 1 15:49:41 2022 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 11:49:13 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181E137C2A1178418B61FE1E4349=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6417260458381092045==" --===============6417260458381092045== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 30, 2022 at 2:49 PM Wayne S via cctalk wrote: > The difference between dz and dh interfaces is that the dh used dma instead= of interrupts to get characters to the cpu. It would be transparent to any s= oftware. > I did a write up on them 40 years ago justifying the replacement of a dz wi= th dh saying that decreasing interrupts would increase performance on my VAX = 780. It did, but just a bit. To make a big difference, you=E2=80=99d have to = have a LOT of people banging away on serial terminals and rs-232 connected p= rinters. When I ran Unibus VAXen in the 80s every day at work, our small machines had 5-9 serial ports for 1-4 users and our largest machine had 57 serial ports (multiple Emulex CS/21 and at least one DEC DMF32 plus the console) and several dozen users. We never moved to terminal servers or other external connection management. It was all individual serial connections routed to offices and workrooms. I think our peak usage was 50-60 active users but at that point, the 8MB of physical memory started to be a constraint. I don't think the 11/750 could have handled that many users on DZ-11s. -ethan --===============6417260458381092045==-- From paulkoning@comcast.net Tue Nov 1 16:01:10 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 12:00:48 -0400 Message-ID: <644ED193-F48A-4242-AA3B-2F22B3252B56@comcast.net> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181E137C2A1178418B61FE1E4349=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4577131415518753736==" --===============4577131415518753736== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk w= rote: >=20 > The difference between dz and dh interfaces is that the dh used dma instead= of interrupts to get characters to the cpu. It would be transparent to any s= oftware. No, it doesn't. I was confused about this but was recently corrected. The DH11 does DMA output, but not DMA input. I don't know any DEC serial por= t devices that have DMA input; it would make very little sense to do that sin= ce input generally is one character at a time. Block mode terminals do exist= in DEC's world but they are rare, and even those are hard to operate with si= mple DMA. DZ is programmed I/O in both directions, which makes the difference. In typi= cal usage, the bulk of the terminal traffic is output, so doing that with DMA= is a big win. paul --===============4577131415518753736==-- From wayne.sudol@hotmail.com Tue Nov 1 17:02:17 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 17:01:57 +0000 Message-ID: In-Reply-To: <644ED193-F48A-4242-AA3B-2F22B3252B56@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1667532534895391613==" --===============1667532534895391613== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Paul. Who =E2=80=9Ccorrected=E2=80=9D you about DMA input? I=E2=80=99d lik= e to read about that as nothing i read about the DZ mentioned that. Got any C= ites? Sent from my iPhone > On Nov 1, 2022, at 09:01, Paul Koning via cctalk = wrote: >=20 > =EF=BB=BF >=20 >> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk = wrote: >>=20 >> The difference between dz and dh interfaces is that the dh used dma instea= d of interrupts to get characters to the cpu. It would be transparent to any = software. >=20 > No, it doesn't. I was confused about this but was recently corrected. >=20 > The DH11 does DMA output, but not DMA input. I don't know any DEC serial p= ort devices that have DMA input; it would make very little sense to do that s= ince input generally is one character at a time. Block mode terminals do exi= st in DEC's world but they are rare, and even those are hard to operate with = simple DMA. >=20 > DZ is programmed I/O in both directions, which makes the difference. In ty= pical usage, the bulk of the terminal traffic is output, so doing that with D= MA is a big win. >=20 > paul >=20 >=20 --===============1667532534895391613==-- From wayne.sudol@hotmail.com Tue Nov 1 17:06:12 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 17:05:54 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181A1DE7326034C5AC13B2AE4369=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2718722393743620853==" --===============2718722393743620853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Nov 1, 2022, at 10:01, Wayne S wrote: >=20 > =EF=BB=BFHi Paul. Who =E2=80=9Ccorrected=E2=80=9D you about DMA input? I=E2= =80=99d like to read about that as nothing i read about the DZ mentioned that= . Got any Cites? >=20 > Sent from my iPhone >=20 >> On Nov 1, 2022, at 09:01, Paul Koning via cctalk = wrote: >>=20 >> =EF=BB=BF >>=20 >>>> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk wrote: >>>=20 >>> The difference between dz and dh interfaces is that the dh used dma inste= ad of interrupts to get characters to the cpu. It would be transparent to any= software. >>=20 >> No, it doesn't. I was confused about this but was recently corrected. >>=20 >> The DH11 does DMA output, but not DMA input. I don't know any DEC serial = port devices that have DMA input; it would make very little sense to do that = since input generally is one character at a time. Block mode terminals do ex= ist in DEC's world but they are rare, and even those are hard to operate with= simple DMA. >>=20 >> DZ is programmed I/O in both directions, which makes the difference. In t= ypical usage, the bulk of the terminal traffic is output, so doing that with = DMA is a big win. >>=20 >> paul >>=20 Also, can you define what the phrase =E2=80=9Cprogrammed io=E2=80=9D refers? AFAIK, pretty much everything does that, so a clarification would help. >>=20 --===============2718722393743620853==-- From paulkoning@comcast.net Tue Nov 1 17:21:16 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 13:20:55 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21819B84103F19286737604FE4369=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8231755977031657557==" --===============8231755977031657557== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 1, 2022, at 1:05 PM, Wayne S wrote: >> ... >>> On Nov 1, 2022, at 09:01, Paul Koning via cctalk wrote: >>>=20 >>> =EF=BB=BF >>>=20 >>>>> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk wrote: >>>>=20 >>>> The difference between dz and dh interfaces is that the dh used dma inst= ead of interrupts to get characters to the cpu. It would be transparent to an= y software. >>>=20 >>> No, it doesn't. I was confused about this but was recently corrected. >>>=20 >>> The DH11 does DMA output, but not DMA input. I don't know any DEC serial= port devices that have DMA input; it would make very little sense to do that= since input generally is one character at a time. Block mode terminals do e= xist in DEC's world but they are rare, and even those are hard to operate wit= h simple DMA. >>>=20 >>> DZ is programmed I/O in both directions, which makes the difference. In = typical usage, the bulk of the terminal traffic is output, so doing that with= DMA is a big win. >>>=20 >>> paul >>>=20 > Also, can you define what the phrase =E2=80=9Cprogrammed io=E2=80=9D refers? > AFAIK, pretty much everything does that, so a clarification would help. Yes, in the sense that all I/O happens under control of some program. The te= rm "programmed I/O" normally means I/O where the entire job is done in softwa= re, as opposed to DMA or similar schemes where the software initiates the pro= cess but the I/O device then does a lot of the detail work autonomously, with= out bothering the CPU. Take terminal interfaces. With interactive terminals (standard usage in DEC = systems) it's unavoidable that the software has to do work for each character= , so programmed I/O is normal. It typically has a FIFO to deal with interrup= t latency, and as a result also tends to do interrupt coalescing (under hight= load each interrupt results in several characters being taken from the FIFO = and acted on). Terminal output often comes in bursts, for example an application may write a= line of text or even a larger chunk of data. If so, the OS can do block tra= nsfers for those bursts. Even if it has to copy from user to kernel buffers,= it can fill such a buffer and the start a DMA transfer of the entire buffer = contents. The result is that the OS only has to deal with the device every 3= 0 characters or so (RSTS case) or even less often if the buffer size is large= r. Consider disk for another example. With very rare exceptions, disks do DMA: = the OS points to the place where the data lives, supplies a transfer length a= nd starting disk position, and says "go do it and tell me when it's finished"= . Newer devices like the MSCP controllers support a queue of requests, but e= ven simple devices like the RK05 will do a full transfer without CPU involvem= ent. The one notorious exception is the Pro, where the disk controllers use progra= mmed I/O: the OS has to move every word one at a time to or from a controller= CSR. So the CPU overhead of disk I/O in that system is much higher than on = every other DEC machine, and partly for that reason the Pro is utterly incapa= ble of transferring consecutive sectors. Instead, it is forced to use interl= eaving, where logically-adjacent sectors are actually 5 sectors apart ("4:1 i= nterleave"). That too contributes to pathetic performance. paul --===============8231755977031657557==-- From bfranchuk@jetnet.ab.ca Tue Nov 1 18:40:24 2022 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 12:32:04 -0600 Message-ID: <1ab1fc3c-3b3e-7fc2-7472-f76099ebaf37@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1167552220581421502==" --===============1167552220581421502== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: tents. The result is that the OS only has to deal with the device every=20 30 characters or so (RSTS case) or even less often if the buffer size is=20 larger. >=20 > Consider disk for another example. With very rare exceptions, disks do DMA= : the OS points to the place where the data lives, supplies a transfer length= and starting disk position, and says "go do it and tell me when it's finishe= d". Newer devices like the MSCP controllers support a queue of requests, but= even simple devices like the RK05 will do a full transfer without CPU involv= ement. >=20 How mqny old systems required partial transfer for disk io, for swapping=20 overlays in and out? > paul >=20 Ben. --===============1167552220581421502==-- From mark@markesystems.com Tue Nov 1 18:55:20 2022 From: mark@markesystems.com To: cctalk@classiccmp.org Subject: [cctalk] Re: 50 Years of the HP 3000 Date: Tue, 01 Nov 2022 11:48:40 -0700 Message-ID: In-Reply-To: <166731342436.2127582.13268172123793962044@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0013784209966961793==" --===============0013784209966961793== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Gavin Scott Subject: [cctalk] 50 Years of the HP 3000 > Well, here we are. If you boot up a classic HP 3000 system and simply > hit return when it asks you for the date and time, it will default to: As it turns out, I have a complete, working HP 3000 917/LX system, with printers, a line printer with stand, 14-port terminal concentrator, four HP 700-series terminals (one new in box, one likely dead), SCSI disk storage module with a couple of 2GB drives, DAT drive, and all of the necessary cables. It all seems to work perfectly (with the exception of the one worn-out terminal), and I booted it up a couple of months ago with no problems. The passwords have been removed from the MANAGER.SYS account, so the system is now wide open. There's also some software: ASK/ManMan, FORTRAN, and of course TurboIMAGE and Query; also a copy of Reflection (Windows emulator for HP terminals). There's also in excess of 100 pounds of documentation, and some boxes of paper, including green-bar (remember that?). The thing is, despite aspirations from my youth, I really don't need a complete timesharing computer system in my house, so I'm looking to sell the whole thing as a package. It seems possible that someone on this list might be interested, and I'm also open to suggestions about other places I could list it. I took it to the west coast Vintage Computer Faire this year, and there were several nibbles, but obviously I still have it. It's currently located in the San Francisco Bay area, but I commute semi-regularly between there and Portland OR, and could be fairly easily persuaded to deliver it anywhere in either of those areas, or in between. (The system will fit in a mini-van - barely - or comfortably in a full-sized pick-up truck with room to spare.) I'd like to see $2000, but will cheerfully entertain offers (cheerfully if they're reasonable, or met with hysterical laughter if not). Feel free to contact me off-list if you'd like more details and/or pictures. Thanks! ~~ Mark Moulding --===============0013784209966961793==-- From paulkoning@comcast.net Tue Nov 1 18:57:08 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 14:56:48 -0400 Message-ID: <2DF8B39C-26BB-49BC-8652-1325EB45AB54@comcast.net> In-Reply-To: <1ab1fc3c-3b3e-7fc2-7472-f76099ebaf37@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6951706266381617993==" --===============6951706266381617993== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 1, 2022, at 2:32 PM, ben via cctalk wrote: >=20 > On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: > tents. The result is that the OS only has to deal with the device every 30= characters or so (RSTS case) or even less often if the buffer size is larger. >> Consider disk for another example. With very rare exceptions, disks do DM= A: the OS points to the place where the data lives, supplies a transfer lengt= h and starting disk position, and says "go do it and tell me when it's finish= ed". Newer devices like the MSCP controllers support a queue of requests, bu= t even simple devices like the RK05 will do a full transfer without CPU invol= vement. > How mqny old systems required partial transfer for disk io, for swapping ov= erlays in and out? Arbitrary size reads are common; as you said overlay loads require that. Par= tial block writes are not so common. In RSTS, the base OS write operation do= es not allow that. But I found out early that RT11 does, and depends on it. = In RT11, if you do a partial block write, the rule is that the rest of the b= lock is zero-filled. In some disks the controller takes care of that. In th= e RF11, the driver does because the device does any word count, so the driver= sets up a separate transfer for the rest of the block using a word containin= g zero as the source buffer, and "inhibit bus address increment" set so all t= he DMA cycles use that same word. In the RC11, the sector size is 64 bytes, = so the device zero-fills to the end of the sector but the driver has to do th= e same sort of stuff as the RF11 driver if there are any additional 64-byte s= ectors left before the 512-byte block boundary. It turns out RT11 Fortran depends on this, though I don't remember the detail= s. paul --===============6951706266381617993==-- From wayne.sudol@hotmail.com Tue Nov 1 19:03:30 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 19:03:13 +0000 Message-ID: In-Reply-To: <2DF8B39C-26BB-49BC-8652-1325EB45AB54@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6007739371305451082==" --===============6007739371305451082== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul said =E2=80=9CBut the DZ doesn't do DMA.=E2=80=9D=20 I apologize. I used DZ in responses when i meant DH.=20 =20 Sent from my iPhone > On Nov 1, 2022, at 11:56, Paul Koning via cctalk = wrote: >=20 > =EF=BB=BF >=20 >> On Nov 1, 2022, at 2:32 PM, ben via cctalk wrote: >>=20 >> On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: >> tents. The result is that the OS only has to deal with the device every 3= 0 characters or so (RSTS case) or even less often if the buffer size is large= r. >>> Consider disk for another example. With very rare exceptions, disks do D= MA: the OS points to the place where the data lives, supplies a transfer leng= th and starting disk position, and says "go do it and tell me when it's finis= hed". Newer devices like the MSCP controllers support a queue of requests, b= ut even simple devices like the RK05 will do a full transfer without CPU invo= lvement. >> How mqny old systems required partial transfer for disk io, for swapping o= verlays in and out? >=20 > Arbitrary size reads are common; as you said overlay loads require that. P= artial block writes are not so common. In RSTS, the base OS write operation = does not allow that. But I found out early that RT11 does, and depends on it= . In RT11, if you do a partial block write, the rule is that the rest of the= block is zero-filled. In some disks the controller takes care of that. In = the RF11, the driver does because the device does any word count, so the driv= er sets up a separate transfer for the rest of the block using a word contain= ing zero as the source buffer, and "inhibit bus address increment" set so all= the DMA cycles use that same word. In the RC11, the sector size is 64 bytes= , so the device zero-fills to the end of the sector but the driver has to do = the same sort of stuff as the RF11 driver if there are any additional 64-byte= sectors left before the 512-byte block boundary. >=20 > It turns out RT11 Fortran depends on this, though I don't remember the deta= ils. >=20 > paul >=20 --===============6007739371305451082==-- From wayne.sudol@hotmail.com Tue Nov 1 19:07:24 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 19:07:05 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21817B8B6B8DE90C1DDD9597E4369=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6998076241328814293==" --===============6998076241328814293== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just to clarify, my surmising was in response to =E2=80=9C The DH11 does DMA = output, but not DMA input. =E2=80=9D in one of the earlier messages. Sent from my iPhone > On Nov 1, 2022, at 12:03, Wayne S wrote: >=20 > =EF=BB=BFPaul said =E2=80=9CBut the DZ doesn't do DMA.=E2=80=9D=20 > I apologize. I used DZ in responses when i meant DH.=20 >=20 >=20 > Sent from my iPhone >=20 >> On Nov 1, 2022, at 11:56, Paul Koning via cctalk = wrote: >>=20 >> =EF=BB=BF >>=20 >>>> On Nov 1, 2022, at 2:32 PM, ben via cctalk wro= te: >>>=20 >>>> On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: >>> tents. The result is that the OS only has to deal with the device every = 30 characters or so (RSTS case) or even less often if the buffer size is larg= er. >>>> Consider disk for another example. With very rare exceptions, disks do = DMA: the OS points to the place where the data lives, supplies a transfer len= gth and starting disk position, and says "go do it and tell me when it's fini= shed". Newer devices like the MSCP controllers support a queue of requests, = but even simple devices like the RK05 will do a full transfer without CPU inv= olvement. >>> How mqny old systems required partial transfer for disk io, for swapping = overlays in and out? >>=20 >> Arbitrary size reads are common; as you said overlay loads require that. = Partial block writes are not so common. In RSTS, the base OS write operation= does not allow that. But I found out early that RT11 does, and depends on i= t. In RT11, if you do a partial block write, the rule is that the rest of th= e block is zero-filled. In some disks the controller takes care of that. In= the RF11, the driver does because the device does any word count, so the dri= ver sets up a separate transfer for the rest of the block using a word contai= ning zero as the source buffer, and "inhibit bus address increment" set so al= l the DMA cycles use that same word. In the RC11, the sector size is 64 byte= s, so the device zero-fills to the end of the sector but the driver has to do= the same sort of stuff as the RF11 driver if there are any additional 64-byt= e sectors left before the 512-byte block boundary. >>=20 >> It turns out RT11 Fortran depends on this, though I don't remember the det= ails. >>=20 >> paul >>=20 --===============6998076241328814293==-- From ethan.dicks@gmail.com Tue Nov 1 19:39:22 2022 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 15:38:55 -0400 Message-ID: In-Reply-To: <644ED193-F48A-4242-AA3B-2F22B3252B56@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3442592324362898910==" --===============3442592324362898910== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 1, 2022 at 12:01 PM Paul Koning via cctalk wrote: > > On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk = wrote: > > > > The difference between dz and dh interfaces is that the dh used dma inste= ad of interrupts to get characters to the cpu... > > No, it doesn't. I was confused about this but was recently corrected. > > The DH11 does DMA output, but not DMA input. I don't know any DEC serial p= ort devices that have DMA input; it would make very little sense to do that s= ince input generally is one character at a time. Yes. I was going to mention this in my previous reply but got sidetracked. The big benefit for DH11 and DMF32 and 3rd-party DH11 work-alikes (Emulex CS-21...) is that since under normal workflow, many times more chars go out than come in so DMA-out saves a lot of overhead when blasting screens of stuff (like refreshing your page in EDT...) and people don't type all that fast by comparison. Where we used to have problems is having multiple Kermit sessions on our serial ports. Those hammer both ways. Fortunately, I wasn't trying to support PDP-11s with split baud rates like 1200/150 that were used to _really_ reduce input interrupt frequency. Our machines kept up at 9600/9600. -ethan --===============3442592324362898910==-- From paulkoning@comcast.net Tue Nov 1 20:36:58 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 16:36:40 -0400 Message-ID: <18ACD678-9321-4E49-8E2E-9BC3BF916EEE@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3555623775740062199==" --===============3555623775740062199== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 1, 2022, at 3:38 PM, Ethan Dicks via cctalk wrote: >=20 > On Tue, Nov 1, 2022 at 12:01 PM Paul Koning via cctalk > wrote: >>> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk = wrote: >>>=20 >>> The difference between dz and dh interfaces is that the dh used dma inste= ad of interrupts to get characters to the cpu... >>=20 >> No, it doesn't. I was confused about this but was recently corrected. >>=20 >> The DH11 does DMA output, but not DMA input. I don't know any DEC serial = port devices that have DMA input; it would make very little sense to do that = since input generally is one character at a time. >=20 > Yes. I was going to mention this in my previous reply but got sidetracked. >=20 > The big benefit for DH11 and DMF32 and 3rd-party DH11 work-alikes > (Emulex CS-21...) is that since under normal workflow, many times more > chars go out than come in so DMA-out saves a lot of overhead when > blasting screens of stuff (like refreshing your page in EDT...) and > people don't type all that fast by comparison. >=20 > Where we used to have problems is having multiple Kermit sessions on > our serial ports. Those hammer both ways. >=20 > Fortunately, I wasn't trying to support PDP-11s with split baud rates > like 1200/150 that were used to _really_ reduce input interrupt > frequency. Our machines kept up at 9600/9600. A DEC product that shows this sort of scenario is Typeset-11 (TMS-11) which h= as VT71 block transfer terminals at 9600 bps. I'm 98% sure those were on DH1= 1s. So with those, when the user hit the key to send the completed file back= to the host, a bulk transfer of whatever the file size was (a complete newsp= aper article, in the typical case) would occur. I'm not sure if DDCMP was us= ed for that, probably yes. It certainly adds up to a pretty significant work= load. I suppose there was an occasional FIFO overflow under peak load (repor= ters frantically finishing articles as the deadline approaches...) paul --===============3555623775740062199==-- From a.carlini@ntlworld.com Tue Nov 1 20:57:27 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Tue, 01 Nov 2022 20:57:11 +0000 Message-ID: <033f4aff-85e7-0a47-4e56-8ff1184fed56@ntlworld.com> In-Reply-To: <16cd53c5-1298-2807-49fd-bcfc54787f37@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5647072317098301481==" --===============5647072317098301481== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24/10/2022 21:07, Antonio Carlini via cctalk wrote: > the bitsbox one may be a teensy bit to large but the ebay one should > fit nicely. Neither is too expensive even with postage so I'll buy a > few, given that I do have a fair few PSUs knocking around. Turns out both sets of X2 caps I bought were identical and they fit perfectly. As I was putting the PSU back together I thought I could hear something loose rattling inside. So I decided to dismantle it completely. I managed to get the bottom board out, with some fiddling, but it would be much easier if I could get the fans off. However, they seem to be held on with some fasteners that I've not seen before. On the inside they are some sort of trilobe fastener that seems to yield under any sort of pressure (so I stopped) and on the outside they have a small hole with three thin slots, but my tri-wing bits only seem to turn them in the "tighten" direction, almost as though the whole thing is supposed to be "fit and forget". I suppose if I had to get the fans out of the way I could destroy those fittings and replace with some suitable M bolts. I'm just wondering now whether I'm missing a trick for removing the fans? As I write this I realise that a photo or two wouldn't go amiss, so I'll try to take a few close ups tomorrow in daylight. Antonio -- Antonio Carlini antonio(a)acarlini.com --===============5647072317098301481==-- From cctalk@beyondthepale.ie Tue Nov 1 23:26:07 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Tue, 01 Nov 2022 23:10:33 +0000 Message-ID: <01SJUCC2IT708WYOLI@beyondthepale.ie> In-Reply-To: <033f4aff-85e7-0a47-4e56-8ff1184fed56@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4076784359685117198==" --===============4076784359685117198== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24/10/2022 21:07, Antonio Carlini via cctalk wrote: >> the bitsbox one may be a teensy bit to large but the ebay one should >> fit nicely. Neither is too expensive even with postage so I'll buy a >> few, given that I do have a fair few PSUs knocking around. > > Turns out both sets of X2 caps I bought were identical and they fit > perfectly. > > > As I was putting the PSU back together I thought I could hear something > loose rattling inside. So I decided to dismantle it completely. > > I managed to get the bottom board out, with some fiddling, but it would > be much easier if I could get the fans off. However, they seem to be > held on with some fasteners that I've not seen before. On the inside > they are some sort of trilobe fastener that seems to yield under any > sort of pressure (so I stopped) and on the outside they have a small > hole with three thin slots, but my tri-wing bits only seem to turn them > in the "tighten" direction, almost as though the whole thing is supposed > to be "fit and forget". I suppose if I had to get the fans out of the > way I could destroy those fittings and replace with some suitable M > bolts. I'm just wondering now whether I'm missing a trick for removing > the fans? > I thought those things that hold the fans on were a variation on pop rivets but now that you mention it, I can see the "three sided slot" on the outside. Perhaps there is something preventing them from unscrewing, so that vibration from the fans will not end up loostening them or something like that? I've taken the boards out of a whole bunch of H7821 and H7822 PSUs to replace the electrolytics without removing the fans. It was difficult at first but the more I did, the easier it got. I did come across one seized fan along the way but I haven't a replacement yet so I haven't got around to removing the bad one. I should look into it. Regards, Peter Coghlan. > > As I write this I realise that a photo or two wouldn't go amiss, so I'll > try to take a few close ups tomorrow in daylight. > > Antonio > > > -- > Antonio Carlini > antonio(a)acarlini.com > --===============4076784359685117198==-- From cz@alembic.crystel.com Wed Nov 2 00:00:14 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 19:59:50 -0400 Message-ID: <4ab53f63-82d5-1f01-9d03-3c73d7c3538b@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7498093784396288608==" --===============7498093784396288608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/1/2022 11:49 AM, Ethan Dicks via cctalk wrote: > I don't think the 11/750 could have handled that many users on DZ-11s. I think this is why COMM-IO-P systems were sold. They basically acted like front end processors for a stack of DZ11's to interface to a Unibus system. Problem was those communications processor boards only had enough microcode to handle either block lines or async lines but not both. When the fruitcakes at HKJC demanded that they support the betting systems (polled block oriented devices) and async terminals (for betting odds and displays and such) for the mighty Sha Tin Totalizer (multiple 11/74 type systems and a boat-ton of 11/04 front ends connected by those weird IPC connections) all hell broke loose. Literally. CZ > > -ethan --===============7498093784396288608==-- From paulkoning@comcast.net Wed Nov 2 00:08:42 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 20:08:23 -0400 Message-ID: <369BD59F-AFDB-4AD4-B835-E9E9A0364B4D@comcast.net> In-Reply-To: <4ab53f63-82d5-1f01-9d03-3c73d7c3538b@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3598307612726799287==" --===============3598307612726799287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 1, 2022, at 7:59 PM, Chris Zach via cctalk = wrote: >=20 > On 11/1/2022 11:49 AM, Ethan Dicks via cctalk wrote: >> I don't think the 11/750 could have handled that many users on DZ-11s. >=20 > I think this is why COMM-IO-P systems were sold. They basically acted like = front end processors for a stack of DZ11's to interface to a Unibus system. >=20 > Problem was those communications processor boards only had enough microcode= to handle either block lines or async lines but not both. When the fruitcake= s at HKJC demanded that they support the betting systems (polled block orient= ed devices) and async terminals (for betting odds and displays and such) for = the mighty Sha Tin Totalizer (multiple 11/74 type systems and a boat-ton of 1= 1/04 front ends connected by those weird IPC connections) all hell broke loos= e. >=20 > Literally. You'd think the obvious answer would be to use two KMC11s rather than just on= e... The big win from those coprocessors is that they could offload not just simpl= e DMA, but also protocol processing like DDCMP or even BISYNC. HKJC, now there's a designation I haven't seen in many years.=20 paul --===============3598307612726799287==-- From cz@alembic.crystel.com Wed Nov 2 00:20:28 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Tue, 01 Nov 2022 20:20:08 -0400 Message-ID: <50ccdb54-aa65-36fa-85f2-8dcc779921e6@alembic.crystel.com> In-Reply-To: <369BD59F-AFDB-4AD4-B835-E9E9A0364B4D@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4660272820823678558==" --===============4660272820823678558== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > HKJC, now there's a designation I haven't seen in many years. Were you on that project? I oddly enough have a report that was a root cause analysis as to the failure of the whole thing. Fascinating reading, it's like a 1970's DEC CSS hardware orgy gone mad. C --===============4660272820823678558==-- From cc@informatik.uni-stuttgart.de Wed Nov 2 08:33:50 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Wed, 02 Nov 2022 09:33:21 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4507101974597190771==" --===============4507101974597190771== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 1 Nov 2022, Ethan Dicks wrote: > The big benefit for DH11 and DMF32 and 3rd-party DH11 work-alikes > (Emulex CS-21...) is that since under normal workflow, many times more > chars go out than come in so DMA-out saves a lot of overhead when > blasting screens of stuff (like refreshing your page in EDT...) and > people don't type all that fast by comparison. One question arises: how does that work with XON/XOFF flow control? Does the DH11 handle that on-board? I mean, a VT100 for example is a very slow device. It doesn't reliably work without flow control. You can't send a page full of text, even worse with some escape control characters, without it dropping large chunks of data. Christian --===============4507101974597190771==-- From bmr@ringman.ch Wed Nov 2 13:22:59 2022 From: Magnus Ringman To: cctalk@classiccmp.org Subject: [cctalk] Re: 14 DZ11's for sale/whatever Date: Wed, 02 Nov 2022 14:22:33 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6394434362589628598==" --===============6394434362589628598== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit (wildly off topic but) On Tue, Nov 1, 2022 at 4:49 PM Ethan Dicks via cctalk wrote: > > I don't think the 11/750 could have handled that many users on DZ-11s. With DZ-11s no. But it is impressive what could be done with the "good" hardware. In the mid 80s I was an occasional user on a 11/750 that at its peak had 80 (eighty!) terminals connected across a university campus. Mostly terminals that could be switched between different host lines (sometimes with a mechanical switch box) so the 750 was never 100% utilized, but even with ~40 people logged in, responsiveness was bearable. The interfaces as I recall were DHU-11s and DMZ-32s. The DMZ-32s were weird beasts; the Unibus module connected to a distribution panel via a 4-wire T1 line and could be kilometers away. The distribution panel (which needed its own power supply) had 24 lines. I suspect the thing was aggressively optimized for low CPU overhead. Magnus --===============6394434362589628598==-- From a.carlini@ntlworld.com Wed Nov 2 16:27:17 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Wed, 02 Nov 2022 16:26:55 +0000 Message-ID: <09ddbb23-7e70-a57b-269c-920aeb7f6601@ntlworld.com> In-Reply-To: <01SJUCC2IT708WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6447006816202736792==" --===============6447006816202736792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 01/11/2022 23:10, Peter Coghlan via cctalk wrote: > I've taken the boards out of a whole bunch of H7821 and H7822 PSUs to > replace the electrolytics without removing the fans.  It was difficult at > first but the more I did, the easier it got.  I did come across one > seized > fan along the way but I haven't a replacement yet so I haven't got around > to removing the bad one.  I should look into it. I think I have a second  H7822 and a pair of H7821 supplies to look  at, so I may well end up getting some practice in! Did you have to replace the power LED at all? I've just bench-tested the PSU I've swapped the X2 cap in (luckily it powers up without a load, so all I did was hook up a DVM and check out the voltages), and I noticed that the LED didn't light. I'm pretty sure I connected it back (and it is keyed!) so I think I may be looking for a replacement. Something in the back of my mind says that there is something that makes the replacement slightly non-trivial (funny LED, odd housing it fits in, some trick to getting it out ... I can't remember unfortunately). BTW was it just the 1800uF 25V 105degC caps (mine are brown) that you had to replace? Mine look fine but there are some other large electrolytics in there (two large brown 470uF voltage unclear, and one large black cap by the mains input on which I cannot see any of the markings). Thanks Antonio -- Antonio Carlini antonio(a)acarlini.com --===============6447006816202736792==-- From cctalk@beyondthepale.ie Wed Nov 2 17:41:39 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Wed, 02 Nov 2022 17:15:56 +0000 Message-ID: <01SJVEJ9132W8WYOLI@beyondthepale.ie> In-Reply-To: <09ddbb23-7e70-a57b-269c-920aeb7f6601@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6766630854306067884==" --===============6766630854306067884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Antonio Carlini via cctalk wrote: > On 01/11/2022 23:10, Peter Coghlan via cctalk wrote: >> I've taken the boards out of a whole bunch of H7821 and H7822 PSUs to >> replace the electrolytics without removing the fans.  It was difficult at >> first but the more I did, the easier it got.  I did come across one >> seized >> fan along the way but I haven't a replacement yet so I haven't got around >> to removing the bad one.  I should look into it. > > I think I have a second  H7822 and a pair of H7821 supplies to look  at, > so I may well end up getting some practice in! > > Did you have to replace the power LED at all? I've just bench-tested the > PSU I've swapped the X2 cap in (luckily it powers up without a load, so > all I did was hook up a DVM and check out the voltages), and I noticed > that the LED didn't light. I'm pretty sure I connected it back (and it > is keyed!) so I think I may be looking for a replacement. Something in > the back of my mind says that there is something that makes the > replacement slightly non-trivial (funny LED, odd housing it fits in, > some trick to getting it out ... I can't remember unfortunately). > The LED is more than just a power on indicator. When it fails to light, it can indicate that something is not right in the PSU. It may tie in with the "power good" output from the PSU. It could be that it is failing to light because the regulation is not working properly because there is no load. I'd try it with a load before anything else. The H7822 may need a load on both boards. To eliminate the LED from enquiries, you could try powering it from a 5V supply via a 1KOhm resistor or something like that to see if it lights. If it does, then further investigation in the PSU may be required. If the LED does turn out to be bad, I forget whether it comes out by pulling the LED out of the bezel first or taking the ring off the rear of the bezel first, whichever works. > > BTW was it just the 1800uF 25V 105degC caps (mine are brown) that you > had to replace? Mine look fine but there are some other large > electrolytics in there (two large brown 470uF voltage unclear, and one > large black cap by the mains input on which I cannot see any of the > markings). > It was only the 1800uF 25V capacitors were bad (mine are all brown too). In an earlier posting I said there were six of them in a H7821 and ten of them in a H7822. I should have said five in a H7821 and nine in a H7822. The 470uF 400V capacitors in my units were all fine. The leaking electrolyte had damaged some other components in some cases, especially an odd value resistor which seems to have different values in different units, something around 464 Ohms. It is in series with an thermistor which seems to control the speed of the fans. I've also had a zener diode fail which caused problems with the fans. (If the fans aren't operating properly, the LED might not light!) Regards, Peter Coghlan. > > Thanks > > > Antonio > > > -- > Antonio Carlini > antonio(a)acarlini.com > --===============6766630854306067884==-- From cz@alembic.crystel.com Wed Nov 2 20:28:33 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for DQ696 and RQDX3 Date: Wed, 02 Nov 2022 16:28:17 -0400 Message-ID: <90f43b42-f12b-8607-c0c7-b1fdd84cce07@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8982091642671604791==" --===============8982091642671604791== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hey good news for you! I was in the attic and found the box with my third RQDX3. Which means I have a spare and can send you over one for shipping, a beer and a donation to a local food bank of your choice. Drop me your address. C On 10/10/2022 6:05 PM, Nigel Johnson Ham via cctalk wrote: > Hi folk, > > I am still looking for a DQ696 to allow me to get ESDI drives going on > both my microVAX and 11/73 since the Webster RQD11 controller failed I > only have the one.  I'd also like to get old of an RQDX3 since I built a > Gesswein emulator and have nothing to test it with :-) > > Any help appreciated, > > Nigel > > --===============8982091642671604791==-- From cmhanson@eschatologist.net Thu Nov 3 07:47:21 2022 From: Chris Hanson To: cctalk@classiccmp.org Subject: [cctalk] Re: 50 Years of the HP 3000 Date: Thu, 03 Nov 2022 00:30:16 -0700 Message-ID: <9C0961EA-73AC-4264-8758-B7BEA116D9DF@eschatologist.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3795919468944913581==" --===============3795919468944913581== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Nov 1, 2022, at 11:55 AM, Mark Moulding via cctalk wrote: >=20 > =EF=BB=BFI'd like to see $2000, but will cheerfully entertain offers (cheer= fully if they're reasonable, or met with hysterical laughter if not). You may need to adjust your expectations on that front. Even with pandemic-re= lated inflation, that=E2=80=99s quite high for something not a lot of people = will know they should be interested in. =E2=80=94 Chris =E2=80=94 who has a 917LX and A400, and wishes he could find a 37 or Micro Sent from my iPad --===============3795919468944913581==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 21:08:20 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Disk imaging n00b Date: Thu, 03 Nov 2022 15:07:00 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9083081623525821327==" --===============9083081623525821327== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, n00b alert Does anyone have a 101 level boot strap guide for someone wanting to get into creating better-than-dd disk images? I'm finding myself back in a position where I want to image / preserve multiple 5¼ & 3½ inch disks. I think all of them are PC compatible disks. Probably standard FAT-12 and a handful of super capacity disk formats from the likes of IBM / Microsoft where they tried to squeeze 1.6 (?) MB on a 3½ inch disk. I have an internal 5¼ inch floppy drive that is in unknown condition (I've never used / tested it since I got it). I also have (at least one) 5¼ disk that I acquired as a scratch monkey disk to test on before working on disks that I care more about. I was thinking about acquiring a Kryoflux in the next few months and starting to collect better quality images of disks. I recently saw someone on Twitter suggest that Kryoflux wasn't the best route to go and suggested a SuperCard Pro instead. I had been using the dd command under Linux against a USB connected 3½ inch floppy drive for most things. But I've come to learn that's not as good as some people would like to see preserved. So, does anyone have a 101 level boot strap guide for someone wanting to get into creating better-than-dd disk images? -- Grant. . . . unix || die --===============9083081623525821327==-- From cisin@xenosoft.com Thu Nov 3 21:26:36 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 14:26:20 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6717049458437709807==" --===============6717049458437709807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: > Does anyone have a 101 level boot strap guide for someone wanting to get in= to=20 > creating better-than-dd disk images? > I'm finding myself back in a position where I want to image / preserve=20 > multiple 5=C2=BC & 3=C2=BD inch disks. I think all of them are PC compatib= le disks.=20 > Probably standard FAT-12 and a handful of super capacity disk formats from = > the likes of IBM / Microsoft where they tried to squeeze 1.6 (?) MB on a 3= =C2=BD=20 > inch disk. > I have an internal 5=C2=BC inch floppy drive that is in unknown condition (= I've=20 > never used / tested it since I got it). > I also have (at least one) 5=C2=BC disk that I acquired as a scratch monkey= disk=20 > to test on before working on disks that I care more about. > I was thinking about acquiring a Kryoflux in the next few months and starti= ng=20 > to collect better quality images of disks. I recently saw someone on Twitt= er=20 > suggest that Kryoflux wasn't the best route to go and suggested a SuperCard= =20 > Pro instead. > I had been using the dd command under Linux against a USB connected 3=C2=BD= inch=20 > floppy drive for most things. But I've come to learn that's not as good as= =20 > some people would like to see preserved. > So, does anyone have a 101 level boot strap guide for someone wanting to ge= t=20 > into creating better-than-dd disk images? If these were formats OTHER THAN PC-DOS, then imaging can be essential. And, a flux-transition device, such as Kryoflux might be necessary for=20 some. And, if they are copy-protected, then flux-transition imaging is=20 necessary, and still might not be adequate. But, why do IMAGING on PC-DOS disks? Why not just copy the files, and "ZIP" them? Other than bootable or copy-protected, then re-creation is format a disk=20 and copy the files onto it. In what way would "better than DD" be needed? -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============6717049458437709807==-- From rtomek@ceti.pl Thu Nov 3 21:27:03 2022 From: Tomasz Rola To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 22:26:43 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8037459784518833928==" --===============8037459784518833928== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Nov 03, 2022 at 03:07:00PM -0600, Grant Taylor via cctalk wrote: > Hi, > > n00b alert > > Does anyone have a 101 level boot strap guide for someone wanting to get > into creating better-than-dd disk images? [...] > So, does anyone have a 101 level boot strap guide for someone wanting to get > into creating better-than-dd disk images? I am (slowly) on my way to use ddrescue for similar thing(s). caveat 1: I have not used ddrescue yet, just read a bit and was convinced I may like it. pro: ddrescue is said to be able to read image many times, trying only what have failed before, merging results from various trials etc. So, in theory, try same media in two drives, merge two images. In theory, this might work with any block device under Linux (Unix?). pro: While reading about ddrescue, I have learned that dd might abort on error, this resulting in defective/uncompleted image. Whereas ddrescue retries. caveat n+1: see caveat n-1 -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com ** --===============8037459784518833928==-- From drb@msu.edu Thu Nov 3 21:27:47 2022 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 17:27:33 -0400 Message-ID: <20221103212733.3E0644E77F@yagi.h-net.msu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6066669939221049485==" --===============6066669939221049485== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I was thinking about acquiring a Kryoflux in the next few months and > starting to collect better quality images of disks. I recently saw > someone on Twitter suggest that Kryoflux wasn't the best route to go > and suggested a SuperCard Pro instead. Some people are bothered by Kryoflux's behavior around openness of their formats and the like. I _think_ they've addressed that, but if you care about this, you will have to verify. _My_ Kryoflux went deaf -- quit hearing any flux on the read line from the drive -- but that doesn't seem to be common. The SuperCard Pro doesn't seem to support 8" disks. That may or may not be an issue for you. The frustrating part of the whole flux imaging arena is that the hardware is actually the _easy_ part. Software to decode flux images for all the myriad on-disk formats, copy protection schemes, etc is both the hard part _and_ the part everyone seems to skip over. If you just need to process Apple / Atari / Commodore / PC diskettes, you're probably covered. For anything else you're probably on your own. Note that some disk types are CLV, not CAV (e.g. some Mac disks), and reading them without additional hardware support may be problematic. De --===============6066669939221049485==-- From elson@pico-systems.com Thu Nov 3 21:46:56 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:46:41 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5796737293327300424==" --===============5796737293327300424== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/3/22 16:07, Grant Taylor via cctalk wrote: > Hi, > > n00b alert > > Does anyone have a 101 level boot strap guide for someone > wanting to get into creating better-than-dd disk images? Is there a reason to do a real IMAGE backup, rather than a file backup?  I have used Linux to backup a lot of old PC stuff, including backing up a Win95 system and making it available to a Win95 virtual machine under VirtualBox.  This enabled me to run a bunch of old CAD programs and recover/access old schematics and board layouts. Linux can directly identify and read almost all of the old FATxx file systems. Jon --===============5796737293327300424==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 21:50:44 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:49:27 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4869579376062481278==" --===============4869579376062481278== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/3/22 3:26 PM, Fred Cisin via cctalk wrote: > But, why do IMAGING on PC-DOS disks? My /personal/ and primary use case is for use in virtual machines where disk images (a la dd) is best (in my experience). > Why not just copy the files, and "ZIP" them? Ziped (et al.) files are nice for some things. But the aren't readily usable with virtual machines without access to where the zip files are. Conversely I can attach a disk image to a virtual machine and start using it immediately. As for Zip specific, I'm not aware if /integrated/ Zip file support prior to Windows XP. So the MS-DOS, Windows 3.x, and Windows NT / 2k that I want to mess with can't work with Zip files directly. I also like how I can mount a loop back of the disk image and make the files therein accessible on Linux, my chosen host OS. > Other than bootable or copy-protected, then re-creation is format a disk > and copy the files onto it. I largely agree. However being a person that plays with different operating systems in virtual machines, I need to boot and / or readily attach images to the VM. > In what way would "better than DD" be needed? I'm too ignorant to be able to answer that. dd has served /my/ needs. However I think there is some consensus, I don't know how general it is, that dd or simple file copy tends to not be sufficient for some things. I believe it's technically possible to re-create an MS-DOS boot disk by formatting and then copying IO.SYS, MSDOS.SYS, and then COMMAND.COM to the floppy disk in that order. I think the same methodology can be used with PC-DOS. But that's /just/ /DOS/ and doesn't cover boot disks for other operating systems that I play with. -- Grant. . . . unix || die --===============4869579376062481278==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 21:51:34 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:50:16 -0600 Message-ID: <9e902b4c-0e1e-68ca-8da4-9d783ea240e2@spamtrap.tnetconsulting.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7555626362998227408==" --===============7555626362998227408== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/3/22 3:26 PM, Tomasz Rola via cctalk wrote: > I am (slowly) on my way to use ddrescue for similar thing(s). I've used ddrescue for a /few/ of my disk images. Thankfully /most/ of the 3½ disks that I've imaged have not needed ddrescue / SpinRite / et al. -- Grant. . . . unix || die --===============7555626362998227408==-- From glen.slick@gmail.com Thu Nov 3 21:57:57 2022 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 14:57:29 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7708157786292935446==" --===============7708157786292935446== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Nov 3, 2022 at 2:08 PM Grant Taylor via cctalk wrote: > > Hi, > > n00b alert > > Does anyone have a 101 level boot strap guide for someone wanting to get > into creating better-than-dd disk images? > > I'm finding myself back in a position where I want to image / preserve > multiple 5¼ & 3½ inch disks. I think all of them are PC compatible > disks. Probably standard FAT-12 and a handful of super capacity disk > formats from the likes of IBM / Microsoft where they tried to squeeze > 1.6 (?) MB on a 3½ inch disk. If they are 5¼ & 3½ inch disks which are not copy protected and are readable with standard PC compatible floppy controllers, but not necessarily limited to standard DOS formats, and you had a older PC with a floppy controller which you could set up to boot into real mode DOS, I would start with Dave Dunfield's ImageDisk program. See a link for ImageDisk 1.19 here: http://dunfield.classiccmp.org/img/ Even if a disk is in a standard DOS format, it can be helpful to have an image of the disk rather than just a ZIP of all of the files copied off of the disk. In one example I was trying to run a setup program from a set of files extracted from a ZIP and copied back to disks and the setup program blocked when it was necessary to change installation disks because the next disk didn't have the expected disk label. Of course the disk labels weren't saved in the ZIP, while they would have been saved in images of the disks. --===============7708157786292935446==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 21:59:30 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:58:12 -0600 Message-ID: <0681c26e-ba9a-c13b-29ef-b714d15194db@spamtrap.tnetconsulting.net> In-Reply-To: <20221103212733.3E0644E77F@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2210764364644962585==" --===============2210764364644962585== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/3/22 3:27 PM, Dennis Boone via cctalk wrote: > Some people are bothered by Kryoflux's behavior around openness of > their formats and the like. I _think_ they've addressed that, but > if you care about this, you will have to verify. Ya. I'm starting to see that. I don't /personally/ care about deeper images than a dd image which I can attach to a hypervisor or use to re-create physical disks when needed. If I'm going to re-image my disks, I'm willing to put in a little bit more time and effort (per disk) and some additional time and cost in hardware /if/ it's not onerous /and/ the community will benefit from my efforts. > _My_ Kryoflux went deaf -- quit hearing any flux on the read line > from the drive -- but that doesn't seem to be common. :-( > The SuperCard Pro doesn't seem to support 8" disks. That may or may > not be an issue for you. I do own some 8" disks, but they are only as a museum piece of ancient media along with some hard drive platters. I have no aspiration of ever having an 8" disk drive, much less in a usable state. > The frustrating part of the whole flux imaging arena is that the > hardware is actually the _easy_ part. Software to decode flux images > for all the myriad on-disk formats, copy protection schemes, etc is > both the hard part _and_ the part everyone seems to skip over. If you > just need to process Apple / Atari / Commodore / PC diskettes, you're > probably covered. For anything else you're probably on your own. As indicated, effectively, if not literally, everything I have is PC compatible disks. > Note that some disk types are CLV, not CAV (e.g. some Mac disks), and > reading them without additional hardware support may be problematic. Is Constant Linear vs Angular Velocity (?) anything I need to worry about when sticking within the IBM PC compatible line from say '90 forward? The only other thing that I might add to this would be Zip or Syquest disks if I ever acquire media / drives. I figure that CD-ROMs / DVD-ROMs are largely a solved problem. Simply use dd for single track disks and something that does cue / bin files for multi-track disks. -- I think -- Grant. . . . unix || die --===============2210764364644962585==-- From cisin@xenosoft.com Thu Nov 3 22:09:22 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:09:04 -0700 Message-ID: In-Reply-To: <0681c26e-ba9a-c13b-29ef-b714d15194db@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6475006735407028142==" --===============6475006735407028142== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> Note that some disk types are CLV, not CAV (e.g. some Mac disks), and >> reading them without additional hardware support may be problematic. On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: > Is Constant Linear vs Angular Velocity (?) anything I need to worry about > when sticking within the IBM PC compatible line from say '90 forward? NO. PC [compatible] was fixed rotational speed of 300 or 360 RPM. Well, Weltec? made a 180 RPM drive, to be able to use 1.2M on 5150/5160, and there are many other bizarre oddities. CLV, or "zone" recording, with vaarying motor speed CAN be worked around with a constant motor speed, by varying the data transfer rate, . . . but NO PC [compatible] machines used variable speed floppies, other than 300RPM and 360RPM. --===============6475006735407028142==-- From sellam.ismail@gmail.com Thu Nov 3 22:17:42 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:17:16 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2688009370596111563==" --===============2688009370596111563== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Fred, The Victor/Sirius 9000 was sort of PC compatible and featured a varial speed floppy format, no? Sellam On Thu, Nov 3, 2022 at 3:09 PM Fred Cisin via cctalk wrote: > >> Note that some disk types are CLV, not CAV (e.g. some Mac disks), and > >> reading them without additional hardware support may be problematic. > > On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: > > Is Constant Linear vs Angular Velocity (?) anything I need to worry > about > > when sticking within the IBM PC compatible line from say '90 forward? > > NO. > PC [compatible] was fixed rotational speed of 300 or 360 RPM. > Well, Weltec? made a 180 RPM drive, to be able to use 1.2M on 5150/5160, > and there are many other bizarre oddities. > > CLV, or "zone" recording, with vaarying motor speed CAN be worked around > with a constant motor speed, by varying the data transfer rate, . . . > but NO PC [compatible] machines used variable speed floppies, other than > 300RPM and 360RPM. > --===============2688009370596111563==-- From cisin@xenosoft.com Thu Nov 3 22:29:44 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:29:27 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5765582266931100775==" --===============5765582266931100775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> But, why do IMAGING on PC-DOS disks? On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: > My /personal/ and primary use case is for use in virtual machines where dis= k=20 > images (a la dd) is best (in my experience). THAT is a totally valid reason for disk images, rather than file copies. Another, less common problem, is that SOME installation programs also look=20 at the disk label, in addition to the files. Windoze, at least in 3.xx did not. It worked fine to copy everything to a=20 single directory and install from there. >> Other than bootable or copy-protected, then re-creation is format a disk=20 >> and copy the files onto it. > I largely agree. However being a person that plays with different operatin= g=20 > systems in virtual machines, I need to boot and / or readily attach images = to=20 > the VM. Ah, if you are using OS's other than MS-DOS and PC-DOS, then a disk image=20 is likely to be essential. Even the 5150 also had CP/M-86 and UCSD P-System FROM IBM. And the 5170 had Xenix (Santa Cruz Operation Unix, peddled through=20 Microsoft) >> In what way would "better than DD" be needed? > I'm too ignorant to be able to answer that. dd has served /my/ needs.=20 > However I think there is some consensus, I don't know how general it is, th= at=20 > dd or simple file copy tends to not be sufficient for some things. The USUAL reasoning is to reproduce variance other than content of sectors=20 and files. Such as copy-protection. Unless you are dealing with copy-protection, or seriously alien formats,=20 you are generally better off using the FDC to make your images, rather=20 than flux-transition. There are numerous FDC based imaging programs, but,=20 there are also multiple formats of the image, such as metadata headers,=20 etc. OTOH, flux-transition lets you look at content below the sector level, to=20 view and sometimes even repair damaged tracks. > I believe it's technically possible to re-create an MS-DOS boot disk by=20 > formatting and then copying IO.SYS, MSDOS.SYS, and then COMMAND.COM to the = > floppy disk in that order. I think the same methodology can be used with=20 > PC-DOS. But that's /just/ /DOS/ and doesn't cover boot disks for other=20 > operating systems that I play with. Even with MS-DOS/PC-DOS, there CAN [very rarely] be issues of boot sector. OS other than MS-DOS/PC-DOS likely need an image. SOME OS use system=20 tracks and/or content that is NOT stored as files in the DIRectory. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5765582266931100775==-- From cisin@xenosoft.com Thu Nov 3 22:35:53 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:35:38 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6165668806161996403==" --===============6165668806161996403== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022, Sellam Abraham via cctalk wrote: > Fred, > The Victor/Sirius 9000 was sort of PC compatible and featured a varial > speed floppy format, no? Although MS-DOS capable, the Victor/Sirius 9000 was FAR from PC compatible! An amazing machine, but NOT PC compatible. It is an ideal example of how far away from PC compatible MS-DOS was capable of being. Also GCR, not MFM. NOT readable with a PC FDC. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============6165668806161996403==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 22:44:24 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:43:02 -0600 Message-ID: <56edfa0b-4888-8e7a-55b1-fa8a24157852@spamtrap.tnetconsulting.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8469851913035159902==" --===============8469851913035159902== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/3/22 3:57 PM, Glen Slick via cctalk wrote: > If they are 5¼ & 3½ inch disks which are not copy protected and > are readable with standard PC compatible floppy controllers, but not > necessarily limited to standard DOS formats, and you had a older PC > with a floppy controller which you could set up to boot into real > mode DOS, I would start with Dave Dunfield's ImageDisk program. > > See a link for ImageDisk 1.19 here: http://dunfield.classiccmp.org/img/ Thank you Glen. That's where I was sort of hoping to end up. I may actually see if I can get my IBM PS/2 back in service as a starter for this. }:-) Doing so serves as: - A solution to my desired goal of this thread - A reason to stand Token Ring up for quasi production. -- Don't talk to me about Ethernet for PS/2s. - A Reason to stand up a Novell NetWare server for quasi production. > Even if a disk is in a standard DOS format, it can be helpful to > have an image of the disk rather than just a ZIP of all of the files > copied off of the disk. In one example I was trying to run a setup > program from a set of files extracted from a ZIP and copied back to > disks and the setup program blocked when it was necessary to change > installation disks because the next disk didn't have the expected > disk label. Of course the disk labels weren't saved in the ZIP, > while they would have been saved in images of the disks. This is a very good example of why a disk image is better than /just/ a collection of files. -- Grant. . . . unix || die --===============8469851913035159902==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 22:47:47 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:46:24 -0600 Message-ID: <0f796c69-1875-6cbb-18ec-3a8a44f71bcb@spamtrap.tnetconsulting.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7008554500246358111==" --===============7008554500246358111== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/3/22 4:35 PM, Fred Cisin via cctalk wrote: > Also GCR, not MFM.  NOT readable with a PC FDC. Please expand "GCR". -- Grant. . . . unix || die --===============7008554500246358111==-- From drb@msu.edu Thu Nov 3 22:49:10 2022 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 18:48:53 -0400 Message-ID: <20221103224853.6928E4EC4F@yagi.h-net.msu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0474369318524770260==" --===============0474369318524770260== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Is there a reason to do a real IMAGE backup, rather than a file > backup? People have occasionally found interesting things in the unallocated sectors of disks. For garden variety PC format disks, it's not necessary to do flux imaging to preserve that sort of thing, though. A regime using a dd-like tool is adequate. De --===============0474369318524770260==-- From cisin@xenosoft.com Thu Nov 3 22:52:25 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 15:52:08 -0700 Message-ID: In-Reply-To: <20221103224853.6928E4EC4F@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5660259744289771590==" --===============5660259744289771590== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > Is there a reason to do a real IMAGE backup, rather than a file > > backup? On Thu, 3 Nov 2022, Dennis Boone via cctalk wrote: > People have occasionally found interesting things in the unallocated > sectors of disks. For garden variety PC format disks, it's not > necessary to do flux imaging to preserve that sort of thing, though. A > regime using a dd-like tool is adequate. Such as the classic Montezuma Micro CP/M for TRS80 Model 3, with "JOHN, EAT SHIT AND DIE" in some sectors? Also, an "ERASED" file is not truly erased until the sector is re-used. By repairing the DIRectory entry, it can be "UNerased". --===============5660259744289771590==-- From drb@msu.edu Thu Nov 3 23:08:07 2022 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 19:07:48 -0400 Message-ID: <20221103230748.CE49E4ED55@yagi.h-net.msu.edu> In-Reply-To: <0681c26e-ba9a-c13b-29ef-b714d15194db@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2242774366807140710==" --===============2242774366807140710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Is Constant Linear vs Angular Velocity (?) anything I need to worry > about when sticking within the IBM PC compatible line from say '90 > forward? There aren't that many platforms that used CLV drives. I don't recall seeing one in the PC world. If anyone did, they would have been specialty stuff. > The only other thing that I might add to this would be Zip or Syquest > disks if I ever acquire media / drives. I haven't seen a flux imaging system for Zip/Jaz drives. MO stuff might be easier optically. But those don't tend to have the sorts of issues where you'd need to flux image anyway -- just a bunch of blocks, and a dd-type tool ought to work fine. De --===============2242774366807140710==-- From cisin@xenosoft.com Thu Nov 3 23:23:35 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:23:20 -0700 Message-ID: In-Reply-To: <0f796c69-1875-6cbb-18ec-3a8a44f71bcb@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7176817712432263058==" --===============7176817712432263058== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit >> Also GCR, not MFM.  NOT readable with a PC FDC. On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: > Please expand "GCR". Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux transition) FM is "frequency modulated". Well, it is actually a regular clock pulse, with data bit pulse, or no pulse, between each of the clock pulses. There is, of course, a limit to how densely packed that can be on a track. A signal with all zero bits of the data, and a signal with all one bits of the data therefore are two different frequencies. MFM is "Modified Frequency Modulated". Clock pulses really aren't necessary when they fall between two consecutive data pulses. If we leave those out, we end up with a much less dense pattern of pulses. (Over-simplified: MFM is FM without any clock pulses deemed "unnecessary") We can get away with a higher data transmission rate, even TWICE, and still not be much too overcrowded on the track. Therefore, twice as much data per track. The marketing people called that "DOUBLE DENSITY", and immediately started calling FM, "SINGLE DENSITY", although some engineers would argue that FM was "half density" and MFM would be "about single density". If you do historical research, you will find the term "double density" was used in the literature BEFORE the term "single density" was (Just like the phrase "WORLD WAR TWO" was used in newspapers before "WORLD WAR I" was ever applied to the "great war") But, going back to FM, . . . if you look at all of the patterns of pulses, you'll see that not ALL of them are dense. In fact, of the 256 possible patterns for an 8 bit byte, you can find 32, or even 64, that are low enough density that they could be compressed. We can use 5 or 6 bits to represent those patterns. But, having only 5 or 6 bits usable to only use the specific patterns that were low enough density means that we can't use 8 bit bytes directly. but, we COULD recombine, to store 5 8 bit bytes as 8 5 bit patterns, or 3 bytes as 4 6 bit patterns. THAT produced low enough "density" of the signal that by upping the data transfer rate, about one and a half times as much data scould be stored on a track, admittedly with some additional processing overhead. Thus, the Apple2 got about 140K on a disk, when the TRS80 got about under 100K (89,600). (Both were originally 35 track, using Shugart SA400 and SA390 drives) "Beneath Apple DOS" has a decent description) The FDC of PC can only directly handle WD/IBM sector and track structure, so reading GCR, such as Apple (prior to 1.4M) Victor/Sirius, Commodore, etc. calls for different hardware. http://www.xenosoft.com/fmts.html has a list of a few of the different machines that use formats that CAN be done using the PC FDC. They do still have different file systems, with various sector sizes, and directory structures. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============7176817712432263058==-- From cisin@xenosoft.com Thu Nov 3 23:26:36 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:26:21 -0700 Message-ID: In-Reply-To: <20221103230748.CE49E4ED55@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3771452746929079440==" --===============3771452746929079440== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > Is Constant Linear vs Angular Velocity (?) anything I need to worry > > about when sticking within the IBM PC compatible line from say '90 > > forward? On Thu, 3 Nov 2022, Dennis Boone via cctalk wrote: > There aren't that many platforms that used CLV drives. I don't recall > seeing one in the PC world. If anyone did, they would have been > specialty stuff. The Macintosh 400K/800K formats were not a continuously variable motor speed, but they used several speeds for different groups or "zones" of tracks. --===============3771452746929079440==-- From cisin@xenosoft.com Thu Nov 3 23:27:14 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:26:56 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1863741326972306820==" --===============1863741326972306820== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable GCR stands for "group Coded Record" On Thu, 3 Nov 2022, Fred Cisin via cctalk wrote: >>> Also GCR, not MFM.=C2=A0 NOT readable with a PC FDC. > > On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: >> Please expand "GCR". > > Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux=20 > transition) > FM is "frequency modulated". Well, it is actually a regular clock pulse,=20 > with data bit pulse, or no pulse, between each of the clock pulses. > There is, of course, a limit to how densely packed that can be on a track. > A signal with all zero bits of the data, and a signal with all one bits of = > the data therefore are two different frequencies. > > > MFM is "Modified Frequency Modulated". Clock pulses really aren't necessar= y=20 > when they fall between two consecutive data pulses. If we leave those out,= =20 > we end up with a much less dense pattern of pulses. (Over-simplified: MFM i= s=20 > FM without any clock pulses deemed "unnecessary") We can get away with a=20 > higher data transmission rate, even TWICE, and still not be much too=20 > overcrowded on the track. Therefore, twice as much data per track. The=20 > marketing people called that "DOUBLE DENSITY", and immediately started=20 > calling FM, "SINGLE DENSITY", although some engineers would argue that FM w= as=20 > "half density" and MFM would be "about single density". If you do historica= l=20 > research, you will find the term "double density" was used in the literatur= e=20 > BEFORE the term "single density" was (Just like the phrase "WORLD WAR TWO" = > was used in newspapers before "WORLD WAR I" was ever applied to the "great = > war") > > > But, going back to FM, . . . if you look at all of the patterns of pulses, = > you'll see that not ALL of them are dense. In fact, of the 256 possible=20 > patterns for an 8 bit byte, you can find 32, or even 64, that are low enoug= h=20 > density that they could be compressed. We can use 5 or 6 bits to represent= =20 > those patterns. But, having only 5 or 6 bits usable to only use the specif= ic=20 > patterns that were low enough density means that we can't use 8 bit bytes=20 > directly. but, we COULD recombine, to store 5 8 bit bytes as 8 5 bit=20 > patterns, or 3 bytes as 4 6 bit patterns. THAT produced low enough "densit= y"=20 > of the signal that by upping the data transfer rate, about one and a half=20 > times as much data scould be stored on a track, admittedly with some=20 > additional processing overhead. Thus, the Apple2 got about 140K on a disk,= =20 > when the TRS80 got about under 100K (89,600). (Both were originally 35=20 > track, using Shugart SA400 and SA390 drives) > "Beneath Apple DOS" has a decent description) > > > The FDC of PC can only directly handle WD/IBM sector and track structure, s= o=20 > reading GCR, such as Apple (prior to 1.4M) Victor/Sirius, Commodore, etc.=20 > calls for different hardware. > http://www.xenosoft.com/fmts.html has a list of a few of the different=20 > machines that use formats that CAN be done using the PC FDC. They do still= =20 > have different file systems, with various sector sizes, and directory=20 > structures. > > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com --===============1863741326972306820==-- From paulkoning@comcast.net Thu Nov 3 23:27:36 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 19:27:16 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6210848490269335874==" --===============6210848490269335874== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 3, 2022, at 5:57 PM, Glen Slick via cctalk = wrote: >=20 > On Thu, Nov 3, 2022 at 2:08 PM Grant Taylor via cctalk > wrote: >>=20 >> Hi, >>=20 >> n00b alert >>=20 >> Does anyone have a 101 level boot strap guide for someone wanting to get >> into creating better-than-dd disk images? >>=20 >> I'm finding myself back in a position where I want to image / preserve >> multiple 5=C2=BC & 3=C2=BD inch disks. I think all of them are PC compati= ble >> disks. Probably standard FAT-12 and a handful of super capacity disk >> formats from the likes of IBM / Microsoft where they tried to squeeze >> 1.6 (?) MB on a 3=C2=BD inch disk. >=20 > If they are 5=C2=BC & 3=C2=BD inch disks which are not copy protected and a= re > readable with standard PC compatible floppy controllers, but not > necessarily limited to standard DOS formats, and you had a older PC > with a floppy controller which you could set up to boot into real mode > DOS, I would start with Dave Dunfield's ImageDisk program. An example of a non-PC format 5.25 inch disk that normal drives can read woul= d be the DEC RX50 floppy, which has 10 sectors per track rather than the PC s= tandard 9 sectors. But a standard drive will read and write those just fine,= if it's told to use that format. I did that ages ago in DOS, but in the pas= t 15 years or so I've only used Linux for that job. It's a simple matter, yo= u just need to know what the format is. paul --===============6210848490269335874==-- From cctalk@gtaylor.tnetconsulting.net Thu Nov 3 23:29:24 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 17:28:01 -0600 Message-ID: In-Reply-To: <20221103230748.CE49E4ED55@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2506471346229568531==" --===============2506471346229568531== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/3/22 5:07 PM, Dennis Boone via cctalk wrote: > There aren't that many platforms that used CLV drives. I don't > recall seeing one in the PC world. If anyone did, they would have > been specialty stuff. ACK > I haven't seen a flux imaging system for Zip/Jaz drives. MO stuff > might be easier optically. But those don't tend to have the sorts > of issues where you'd need to flux image anyway -- just a bunch of > blocks, and a dd-type tool ought to work fine. I would naively think that a dd (type) process would work for Zip / Jazz / Syquest drives, especially for my use case. I think the biggest thing with dd for CD-ROMs / DVD-ROMs is when there are multiple tracks. I know /of/ CUE & BIN file pairs. But I can't describe their differences other than my understanding is that they deal with multi-track 'ROMs. -- Grant. . . . unix || die --===============2506471346229568531==-- From cisin@xenosoft.com Thu Nov 3 23:39:00 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:38:29 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5760345567105596193==" --===============5760345567105596193== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022, Paul Koning via cctalk wrote: > An example of a non-PC format 5.25 inch disk that normal drives can read > would be the DEC RX50 floppy, which has 10 sectors per track rather than > the PC standard 9 sectors. But a standard drive will read and write > those just fine, if it's told to use that format. I did that ages ago > in DOS, but in the past 15 years or so I've only used Linux for that > job. It's a simple matter, you just need to know what the format is. 'course MS-DOS/PC-DOS/WINDOWS can't understand anything other than its own very limited selection of formats. Does Windoze 11 still understand the original 160K format of PC-DOS 1.00? It helps to be using a program that can talk to the BIOS, or directly to the FDC, to be able to use the other sector sizes, and file systems. But, with a little programming, such as dropping down to BIOS level, and calling INT13h, you can read most others that use IBM/Western Digital sector and track structures (generally becaause they used a WD or NEC FDC) http://www.xenosoft.com/fmts.html is a list of some of the ones that I implemented in XenoCopy-PC -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5760345567105596193==-- From paulkoning@comcast.net Thu Nov 3 23:56:34 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 19:55:54 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6344507986726325701==" --===============6344507986726325701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 3, 2022, at 7:38 PM, Fred Cisin via cctalk = wrote: >=20 > On Thu, 3 Nov 2022, Paul Koning via cctalk wrote: >> An example of a non-PC format 5.25 inch disk that normal drives can read w= ould be the DEC RX50 floppy, which has 10 sectors per track rather than the P= C standard 9 sectors. But a standard drive will read and write those just fi= ne, if it's told to use that format. I did that ages ago in DOS, but in the = past 15 years or so I've only used Linux for that job. It's a simple matter,= you just need to know what the format is. >=20 > 'course MS-DOS/PC-DOS/WINDOWS can't understand anything other than its own = very limited selection of formats. Does Windoze 11 still understand the orig= inal 160K format of PC-DOS 1.00? > ... > But, with a little programming, such as dropping down to BIOS level, and ca= lling INT13h, you can read most others that use IBM/Western Digital sector an= d track structures (generally becaause they used a WD or NEC FDC) > http://www.xenosoft.com/fmts.html is a list of some of the ones that I impl= emented in XenoCopy-PC Exactly, and that's what I did way back when, in my original implementation o= f "flx" -- a utility for accessing RSTS file systems on a PC. Later I added = a Linux way to do that, which is very much simpler -- just a matter of settin= g the right mode, either with the fdprm utility or just by issuing an ioctl. = My current "flx" is written in Python, it does that automatically when it se= es a floppy being accessed. =20 That version includes a small script to use just the floppy access routines, = to make an image copy of an RX50 either in physical sector order or RX50 logi= cal order. Look on svn://akdesign.dyndns.org/flx/trunk for the code. "rx50.= py" is that tool; you can also find in "fdprm" the configuration file for the= fdprm utility to tell it about "rx50" format. paul --===============6344507986726325701==-- From sellam.ismail@gmail.com Thu Nov 3 23:58:23 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:57:55 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6824281385811120079==" --===============6824281385811120079== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Fred, There was a project someone did years ago where you can read GCR disks in an unmodified PC drive by first inserting a PC formatted disk to get synced and then swapping in a GCR encoded disk, then it can actually read the raw pulses and they get decoded in software. I forget the website where the project can be found but a web search will hopefully turn it up. Sellam On Thu, Nov 3, 2022 at 4:23 PM Fred Cisin via cctalk wrote: > >> Also GCR, not MFM. NOT readable with a PC FDC. > > On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: > > Please expand "GCR". > > Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux > transition) > FM is "frequency modulated". Well, it is actually a regular clock pulse, > with data bit pulse, or no pulse, between each of the clock pulses. > There is, of course, a limit to how densely packed that can be on a track. > A signal with all zero bits of the data, and a signal with all one bits of > the data therefore are two different frequencies. > > > MFM is "Modified Frequency Modulated". Clock pulses really aren't > necessary when they fall between two consecutive data pulses. If we leave > those out, we end up with a much less dense pattern of pulses. > (Over-simplified: MFM is FM without any clock pulses deemed "unnecessary") > We can get away with a higher data transmission rate, even TWICE, and > still not be much too overcrowded on the track. Therefore, twice as much > data per track. The marketing people called that "DOUBLE DENSITY", and > immediately started calling FM, "SINGLE DENSITY", although some engineers > would argue that FM was "half density" and MFM would be "about single > density". If you do historical research, you will find the term "double > density" was used in the literature BEFORE the term "single density" was > (Just like the phrase "WORLD WAR TWO" was used in newspapers before "WORLD > WAR I" was ever applied to the "great war") > > > But, going back to FM, . . . > if you look at all of the patterns of pulses, you'll see that not ALL of > them are dense. In fact, of the 256 possible patterns for an 8 bit byte, > you can find 32, or even 64, that are low enough density that they could > be compressed. We can use 5 or 6 bits to represent those patterns. But, > having only 5 or 6 bits usable to only use the > specific patterns that were low enough density means that we can't use 8 > bit bytes directly. but, we COULD recombine, to store 5 8 bit bytes as 8 > 5 bit patterns, or 3 bytes as 4 6 bit patterns. THAT produced low enough > "density" of the signal that by upping the data transfer rate, about one > and a half times as much data scould be stored on a track, admittedly with > some additional processing overhead. Thus, the Apple2 got about 140K on a > disk, when the TRS80 got about under 100K (89,600). (Both were originally > 35 track, using Shugart SA400 and SA390 drives) > "Beneath Apple DOS" has a decent description) > > > The FDC of PC can only directly handle WD/IBM sector and track structure, > so reading GCR, such as Apple (prior to 1.4M) Victor/Sirius, Commodore, > etc. calls for different hardware. > http://www.xenosoft.com/fmts.html has a list of a few of the different > machines that use formats that CAN be done using the PC FDC. They do > still have different file systems, with various sector sizes, and > directory structures. > > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com --===============6824281385811120079==-- From cisin@xenosoft.com Fri Nov 4 00:16:04 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 17:15:40 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3836605049610318760==" --===============3836605049610318760== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022, Sellam Abraham via cctalk wrote: > There was a project someone did years ago where you can read GCR disks in > an unmodified PC drive by first inserting a PC formatted disk to get synced > and then swapping in a GCR encoded disk, then it can actually read the raw > pulses and they get decoded in software. I forget the website where the > project can be found but a web search will hopefully turn it up. There are some strange tricks that you can do to fool the system and get it to read some stuff that is NOT IBM/WD sector/track structures. For example, Amiga is MFM data stream, but without IBM/WD sector/track structures. You can fool the NEC FDC into seeing it, in several ways, one of which is to switch drives in mid read, and/or to read a "long" sector. I never succeeded with any of the tricks for Apple2 GCR. About 35 years ago, I did the file system code to use with an extra board ("Apple Turnover") to go between the FDC and the drive, for Apple2 disks (Apple-DOS 3.2 (13 sector), 3.3 (16 sector), Softcard CP/M, P System, and ProDos) It never worked well, and the publisher got in too far over their heads, and I had to have a lawyer shut them down. --===============3836605049610318760==-- From sellam.ismail@gmail.com Fri Nov 4 00:44:57 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 17:44:24 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3305536390058685911==" --===============3305536390058685911== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here's something right out of the Apple II FAQ: 07.007 Can I read Apple II diskettes on my PC? Yes. There is a way for some PCs to read Apple II DOS 3.3 and ProDOS 5.25" floppies which are not copy-protected. By "some PCs" I mean that the PC must have two floppy drives (only one h= as to be a 5.25" drive) and it must be running MS-DOS or Windows 95, 98, or ME. (It won't work with NT, 2000, and XP). You also need a program called "DISK2FDI". (For a link to the program, s= ee Csa21MAIN4.txt.) DISK2FDI reads the Apple floppy and creates a disk image (.do) on the PC. These images will work on most emulators. https://stason.org/TULARC/pc/apple2/faq/07-007-Can-I-read-Apple-II-diskettes-= on-my-PC.html Oh yeah, I remember now: http://www.oldskool.org/disk2fdi/ It requires two drives, where one drive has a PC-DOS formatted disk in it, and then switches to the other that contains the subject GCR disk. Cool hack. Sellam On Thu, Nov 3, 2022 at 5:16 PM Fred Cisin via cctalk wrote: > On Thu, 3 Nov 2022, Sellam Abraham via cctalk wrote: > > There was a project someone did years ago where you can read GCR disks in > > an unmodified PC drive by first inserting a PC formatted disk to get > synced > > and then swapping in a GCR encoded disk, then it can actually read the > raw > > pulses and they get decoded in software. I forget the website where the > > project can be found but a web search will hopefully turn it up. > > There are some strange tricks that you can do to fool the system and get > it to read some stuff that is NOT IBM/WD sector/track structures. > > For example, Amiga is MFM data stream, but without IBM/WD sector/track > structures. You can fool the NEC FDC into seeing it, in several ways, one > of which is to switch drives in mid read, and/or to read a "long" sector. > > I never succeeded with any of the tricks for Apple2 GCR. > > > About 35 years ago, I did the file system code to use with an extra board > ("Apple Turnover") to go between the FDC and the drive, for Apple2 disks > (Apple-DOS 3.2 (13 sector), 3.3 (16 sector), Softcard CP/M, P System, and > ProDos) It never worked well, and the publisher got in too far over their > heads, and I had to have a lawyer shut them down. > --===============3305536390058685911==-- From bitwiz@12bitsbest.com Fri Nov 4 02:25:23 2022 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 18:21:43 -0500 Message-ID: <7dc215b4-92d1-6557-d4f6-c01707860117@12bitsbest.com> In-Reply-To: <0f796c69-1875-6cbb-18ec-3a8a44f71bcb@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7444812307649279603==" --===============7444812307649279603== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit GCR is Group Code Recording, used on the Apple II, Commodore 1541 drive and Amiga (and others) use a different encoding scheme than the normal FM (Frequency Modulation) or MFM (Modified Frequency Modulation) encoding formats used by a majority of floppy disk controllers. There is a very good description of floppy encoding formats here: https://extrapages.de/archives/20190102-Floppy-notes.html On 11/3/2022 5:46 PM, Grant Taylor via cctalk wrote: > On 11/3/22 4:35 PM, Fred Cisin via cctalk wrote: >> Also GCR, not MFM.  NOT readable with a PC FDC. > > Please expand "GCR". > > > --===============7444812307649279603==-- From cisin@xenosoft.com Fri Nov 4 02:32:55 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 19:32:39 -0700 Message-ID: In-Reply-To: <7dc215b4-92d1-6557-d4f6-c01707860117@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6524906540895515155==" --===============6524906540895515155== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022, Mike Katz via cctalk wrote: > GCR is Group Code Recording, used on the Apple II, Commodore 1541 drive and > Amiga (and others) use a different encoding scheme than the normal FM > (Frequency Modulation) or MFM (Modified Frequency Modulation) encoding > formats used by a majority of floppy disk controllers. > > There is a very good description of floppy encoding formats here: > > https://extrapages.de/archives/20190102-Floppy-notes.html Amiga is not GCR; it is MFM, but without the IBM/WD sector/track structure. WD 179x controllers can read tracks. It is too bad that NEC chose to implement traack read as multiple sector read, rather than raw track. But, you are right about the others. Apple still used GCR on the 400K/800K Mac format. PROBABLY also on the Lisa Twiggy disks. Victor/Sirius 9000 and many others, . . . --===============6524906540895515155==-- From sieler@allegrosupport.com Fri Nov 4 06:34:08 2022 From: Stan Sieler To: cctalk@classiccmp.org Subject: [cctalk] list problem with digestmode Date: Thu, 03 Nov 2022 20:44:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4073205043341384353==" --===============4073205043341384353== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, Is anyone else getting 4 to 10 digest emails a day, each with 4 to 8 messages? (cctalk) (Instead of one a day) I have received four digest emails since noon: 2:57PM (8 msgs), 3:47 PM (7 msgs), 5:44 PM (7 msgs), and 8:24 PM (6 msgs). (Yes, all embedded messages are different.) I tried emailing the list owner, but the only response I got was from a moderator (Lawrence W, who specifically said he wasn't the owner), who wasn't able to help me. (He did suggest checking my mode...see below.) I tried going to the website to "login" and check my status...it said my email address wasn't known (which, of course, was patently false...since I'm receiving emails :) So, I tried: subscribe with sieler(a)allegro.com, ensure I have 'digest' mode on. And.....still get multiple messages per day ... *not* what a digest is! This started happening on the order of 3 to 6 months ago. I used to get a single digest a day, with 20 to 50 messages in it. The multiple messages (even though they're smaller) are really annoying. As a possible clue...somewhere around March we (my business partner and I) sold our domain, allegro.com, in the process of retiring. The new owner is providing two years of email forwarding of sieler(a)allegro.com to sieler(a)allegrosupport.com (the latter is a gmail corporate managed account, as allegro.com had been prior to March). (Oh, I tried "logging" in via both domains with no luck.) If the forwarding is a factor, I could try to get allegro/allegrosupport unsubscribed and use a third account :) thanks! Stan Sieler sieler(a)allegro.com sieler(a)allegrosupport.com sieler(a)gmail.com --===============4073205043341384353==-- From bitwiz@12bitsbest.com Fri Nov 4 08:56:21 2022 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Thu, 03 Nov 2022 16:20:50 -0500 Message-ID: <56121fb1-0124-ab4c-abb4-0123fb1a5160@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0739677793214821432==" --===============0739677793214821432== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I would recommend a Greaseweazle.  This is a flux change recorder/copier that can handle many many different formats because it reads and writes by flux transitions on the disk, regardless of the encoding scheme (GCR, MFM, FM, etc.) or format. This is how I format and copy DEC RX01 and RX02 8" disks. On 11/3/2022 4:07 PM, Grant Taylor via cctalk wrote: > Hi, > > n00b alert > > Does anyone have a 101 level boot strap guide for someone wanting to > get into creating better-than-dd disk images? > > I'm finding myself back in a position where I want to image / preserve > multiple 5¼ & 3½ inch disks.  I think all of them are PC compatible > disks.  Probably standard FAT-12 and a handful of super capacity disk > formats from the likes of IBM / Microsoft where they tried to squeeze > 1.6 (?) MB on a 3½ inch disk. > > I have an internal 5¼ inch floppy drive that is in unknown condition > (I've never used / tested it since I got it). > > I also have (at least one) 5¼ disk that I acquired as a scratch monkey > disk to test on before working on disks that I care more about. > > I was thinking about acquiring a Kryoflux in the next few months and > starting to collect better quality images of disks.  I recently saw > someone on Twitter suggest that Kryoflux wasn't the best route to go > and suggested a SuperCard Pro instead. > > I had been using the dd command under Linux against a USB connected 3½ > inch floppy drive for most things.  But I've come to learn that's not > as good as some people would like to see preserved. > > So, does anyone have a 101 level boot strap guide for someone wanting > to get into creating better-than-dd disk images? > > > --===============0739677793214821432==-- From cc@informatik.uni-stuttgart.de Fri Nov 4 08:56:34 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Fri, 04 Nov 2022 09:56:04 +0100 Message-ID: <953aa211-63e5-d2a7-0b2-9cc6d88824c@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0109765475620545024==" --===============0109765475620545024== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 3 Nov 2022, Grant Taylor wrote: > Does anyone have a 101 level boot strap guide for someone wanting to get in= to=20 > creating better-than-dd disk images? > > I'm finding myself back in a position where I want to image / preserve=20 > multiple 5=C2=BC & 3=C2=BD inch disks. I think all of them are PC compatib= le disks.=20 > Probably standard FAT-12 and a handful of super capacity disk formats from = > the likes of IBM / Microsoft where they tried to squeeze 1.6 (?) MB on a 3= =C2=BD=20 > inch disk. Short answer: ImageDisk For FAT/DOS disks, I have a small script that creates both an .imd file=20 and a .zip file of the disk contents, essentially this: DRV=3D/dev/fd0 DOSDRV=3D"a:" # Create both .imd and .dd image imd -i1 -R -a -d $DRV -r "$NAME.imd" # Compress pigz -9 "$NAME.imd" # Create directory listing mdir -i "$NAME.imd.dd" -a/ > "$NAME.dir" # Extract contents from .dd mkdir "$NAME" mcopy -i "$NAME.imd.dd" -smpv :: "$NAME/" # ZIP contents cd "$NAME" zip -r "../$NAME.zip" . # Remove temporary files cd .. rm -rf "$NAME" rm -f "$NAME.imd.dd" Christian --===============0109765475620545024==-- From cc@informatik.uni-stuttgart.de Fri Nov 4 09:03:06 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Fri, 04 Nov 2022 10:02:43 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5511804731301761244==" --===============5511804731301761244== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 3 Nov 2022, Fred Cisin wrote: > On Thu, 3 Nov 2022, Grant Taylor via cctalk wrote: >> Please expand "GCR". > > Sure, . . . (GROSSLY OVER-SIMPLIFIED, such as "pulse" instead of flux=20 > transition) > FM is "frequency modulated". Well, it is actually a regular clock pulse,=20 [...] > MFM is "Modified Frequency Modulated". Clock pulses really aren't necessar= y=20 [...] And to shorten the discussion: *all* of them boil down to a form of RLL=20 (run-lenth-limited) encoding. Christian --===============5511804731301761244==-- From cc@informatik.uni-stuttgart.de Fri Nov 4 09:04:35 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Fri, 04 Nov 2022 10:04:16 +0100 Message-ID: <5e3c6f16-9b69-75fa-1671-209bf6476c1d@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3896120180392140001==" --===============3896120180392140001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022, Fred Cisin wrote: > GCR stands for "group Coded Record" group coded "recording" ;-) Christian --===============3896120180392140001==-- From cc@informatik.uni-stuttgart.de Fri Nov 4 09:08:32 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Fri, 04 Nov 2022 10:08:13 +0100 Message-ID: <1233804e-a396-e9c-ce3-227d3bd734b@informatik.uni-stuttgart.de> In-Reply-To: <7dc215b4-92d1-6557-d4f6-c01707860117@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2794023235117487348==" --===============2794023235117487348== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022, Grant Taylor wrote: > GCR is Group Code Recording, used on the Apple II, Commodore 1541 drive and > Amiga (and others) use a different encoding scheme than the normal FM No, the Amiga can handle GCR, but never used it. It's plain standard MFM with different sector layout and IDs. After all, it's a software thing. Christian --===============2794023235117487348==-- From drb@msu.edu Fri Nov 4 13:46:34 2022 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: list problem with digestmode Date: Fri, 04 Nov 2022 09:46:13 -0400 Message-ID: <20221104134613.D56222B8E86@yagi.h-net.msu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2114941668564335762==" --===============2114941668564335762== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I have received four digest emails since noon: 2:57PM (8 msgs), 3:47 > PM (7 msgs), 5:44 PM (7 msgs), and 8:24 PM (6 msgs). (Yes, all > embedded messages are different.) I dug into the list digest settings a little. It looks like the way the migration tool set them doesn't match the old behavior. It's been flushing the digest out based on a (very small) size threshold. I've adjusted the settings to try to force it to flush on a once-daily basis. I may have to fiddle with this a little. Let me know if you still get multiple issues per day. > I tried going to the website to "login" and check my status...it said > my email address wasn't known (which, of course, was patently > false...since I'm receiving emails :) As previously discussed on-list, the current version of mailman treats the concepts of subscription and web login separately. You can be subscribed without having a user account. If you _create_ an account with a matching email address as a subscription, mailman will associate the two pieces. De --===============2114941668564335762==-- From r_a_feldman@hotmail.com Fri Nov 4 13:53:45 2022 From: Robert Feldman To: cctalk@classiccmp.org Subject: [cctalk] Re: list problem with digestmode Date: Fri, 04 Nov 2022 13:53:29 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1708142470932936701==" --===============1708142470932936701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >Date: Thu, 3 Nov 2022 20:44:34 -0700 >From: Stan Sieler >Subject: [cctalk] list problem with digestmode > >Hi, > >Is anyone else getting 4 to 10 digest emails a day, each with 4 to 8 >messages? >(cctalk) (Instead of one a day) >Stan Sieler Same here. I have not changed my email service, so that is not the cause. The= change began when the new list server went online. Bob --===============1708142470932936701==-- From cclist@sydex.com Fri Nov 4 14:44:39 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: list problem with digestmode Date: Fri, 04 Nov 2022 07:44:18 -0700 Message-ID: <78c9f170-430e-4410-1509-2156ec2e087e@sydex.com> In-Reply-To: =?utf-8?q?=3CCH0PR18MB419566E9B66CA1198F321844B53B9=40CH0PR18MB?= =?utf-8?q?4195=2Enamprd18=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7667327740349483671==" --===============7667327740349483671== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/4/22 06:53, Robert Feldman via cctalk wrote: >> Date: Thu, 3 Nov 2022 20:44:34 -0700 >> From: Stan Sieler >> Subject: [cctalk] list problem with digestmode >> >> Hi, >> >> Is anyone else getting 4 to 10 digest emails a day, each with 4 to 8 >> messages? >> (cctalk) (Instead of one a day) >=20 > >=20 >> Stan Sieler >=20 > Same here. I have not changed my email service, so that is not the cause. T= he change began when the new list server went online. Same here--using Thunderbird client. Messages with the same header and body have become so numerous, I don't bother to read any of them now. --Chuck --===============7667327740349483671==-- From cctalk@gtaylor.tnetconsulting.net Fri Nov 4 15:47:42 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Fri, 04 Nov 2022 09:46:23 -0600 Message-ID: <5f695191-fd9a-4653-41b1-b60fcc53f626@spamtrap.tnetconsulting.net> In-Reply-To: <953aa211-63e5-d2a7-0b2-9cc6d88824c@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7099007841535015263==" --===============7099007841535015263== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/4/22 2:56 AM, Christian Corti via cctalk wrote: > Short answer: ImageDisk ACK > For FAT/DOS disks, I have a small script that creates both an .imd file > and a .zip file of the disk contents, Nice! I think that's in the same ball park as I would have assumed I'd do if someone had asked me this time last week. > essentially this: > > DRV=/dev/fd0 > DOSDRV="a:" > # Create both .imd and .dd image Why the two types of image? I assume that .imd is ImageDisk's native format. I understand the raw sector by sector (byte by byte?) .dd image. Aside: Does that mean that ImageDisk's /image/ is not the same sbs / bbb image that a dd image is? I assume that ImageDisk's format contains the same type of data, possibly organized differently and / or compressed thus making the .imd not directly usable by VM hypervisors or loopback mounts the same way that a .dd image is. > imd -i1 -R -a -d $DRV -r "$NAME.imd" > # Compress > pigz -9 "$NAME.imd" > # Create directory listing > mdir -i "$NAME.imd.dd" -a/ > "$NAME.dir" > # Extract contents from .dd > mkdir "$NAME" > mcopy -i "$NAME.imd.dd" -smpv :: "$NAME/" > # ZIP contents > cd "$NAME" > zip -r "../$NAME.zip" . > # Remove temporary files > cd .. > rm -rf "$NAME" > rm -f "$NAME.imd.dd" Interesting. I'm going to have to look at the man pages to completely grok the commands that you're using. The thing that stands out to me as the biggest unknown is where the $NAME.imd.dd file is coming from. It seems as if img (the main ImageDisk command?) is creating $NAME.imd file. Does it also create $NAME.imd.dd file at the same time? I like using mcopy (from mtools?) to extract the files to create a zip. Nice technique. -- Grant. . . . unix || die --===============7099007841535015263==-- From jon@jonworld.com Fri Nov 4 17:47:51 2022 From: Jonathan Katz To: cctalk@classiccmp.org Subject: [cctalk] Whitechapel Computer Works Date: Fri, 04 Nov 2022 17:47:23 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5891482972255844635==" --===============5891482972255844635== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi everyone! I'm curious; other than Wikipedia what do we know about Whitechapel workstations? Do any of us have some working in our collections, with software, disk dumps, etc? Cheers! --===============5891482972255844635==-- From ard.p850ug1@gmail.com Fri Nov 4 17:53:38 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Whitechapel Computer Works Date: Fri, 04 Nov 2022 17:53:10 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1996376465610544141==" --===============1996376465610544141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2022 at 5:47 PM Jonathan Katz via cctalk wrote: > > Hi everyone! > > I'm curious; other than Wikipedia what do we know about Whitechapel > workstations? Do any of us have some working in our collections, with > software, disk dumps, etc? I know somebody who pointed out that back in Victorian times, Whitechapel (an area of London) was known for opium dens. And that this must have influenced the design of said computers... More seriously I have a working (last time I turned it on) MG1 with monitor, keyboard, and mouse. Also have the technical notes manual and an installation disk kit. Another chap I know (I think he's here but I'll let him speak up) scanned the manual and coppied the disks last year, so there is a backup.This is a 32016-based machine of course. It has a bit-serial graphics processor (akin to the excellent parallel rasterop machine in the PERQ) that is slower than doing a bitmap update in software... I also have most of a Hitech 10 (MIPS R2000 box) that I know nothing about ye= t. All sorts of spare boards, including things like never-populated bare RAM boards for the Hitech,. -tony --===============1996376465610544141==-- From abs@absd.org Fri Nov 4 17:54:10 2022 From: David Brownlee To: cctalk@classiccmp.org Subject: [cctalk] Re: Whitechapel Computer Works Date: Fri, 04 Nov 2022 17:53:37 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4874208019552355789==" --===============4874208019552355789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 4 Nov 2022 at 17:47, Jonathan Katz via cctalk wrote: > > Hi everyone! > > I'm curious; other than Wikipedia what do we know about Whitechapel > workstations? Do any of us have some working in our collections, with > software, disk dumps, etc? I had quite a few back in the 90s when City University was transitioning to Suns. Complete with 42nix and GENIX disks. My last ones made it to Iain A F Fleming back at the end of the last century, but I've no idea what happened after :/ David --===============4874208019552355789==-- From cmhanson@eschatologist.net Fri Nov 4 23:54:07 2022 From: Chris Hanson To: cctalk@classiccmp.org Subject: [cctalk] Re: LC:M+L (Living Computer Museum) Date: Fri, 04 Nov 2022 16:53:37 -0700 Message-ID: <04EBF9EB-B836-4AB2-AC7B-F2CCC6958F7E@eschatologist.net> In-Reply-To: <4N1Ttr2P4mzfYm@panix5.panix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3388438300643313349==" --===============3388438300643313349== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Oct 31, 2022, at 4:31 PM, Rich Alderson via cctalk wrote: >=20 > Tour guides and front desk personnel were immediately let go, because it was > clear that it would be several months, up to a year, before we could open > again. Microsoft, Google, Apple, Facebook etc. were willing to pay all of the ancill= ary on-site staff (like the people work at their coffee bars) their regular w= ages through the pandemic even when nobody was allowed in the offices. LCM+L, being owned by a billionaire's foundation, could have chosen to do tha= t too. > Professional museum staff (curator, educational coordinator, etc.) were > retained for a short while, to wind things down. They and the entire engineering staff should have been kept on until the muse= um could reopen, doing whatever work they could remotely, and should still be= working there now. That they weren't shows how little the foundation cares for the things Paul A= llen cared about. While I prefer the way LCM+L made working systems available to the public ove= r the CHM's mostly-static "behind a velvet rope" approach, CHM has turned out= to be the better institution since they at least kept people on. > All of the engineers, which the exception of the manager of the department, > were laid off as of 1 July 2020. None of us was allowed to return to the > museum at any future time, and no one associated with the mothballed museum= was > allowed to talk to any of us. Disgusting. Good luck to LCM+L hiring anyone with real skills for passion rat= es if they ever actually do try to reopen. -- Chris --===============3388438300643313349==-- From cmhanson@eschatologist.net Fri Nov 4 23:57:40 2022 From: Chris Hanson To: cctalk@classiccmp.org Subject: [cctalk] Re: LC:M+L (Living Computer Museum) Date: Fri, 04 Nov 2022 16:57:13 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3129229846595856162==" --===============3129229846595856162== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Oct 31, 2022, at 11:45 PM, Tom Hunter via cctalk = wrote: >=20 > Thank you Rich for shedding light on this. Most of it makes sense to me, > but the secrecy part where you weren't allowed to talk to those still at > the museum is weird. I can't see any possible commercial reason for > preventing former engineering staff to talk with their former colleagues or > replacements. If anything you would think that any new staff would be > encouraged to talk to the engineers who left to benefit from their > experience. As I said this appears to be rather strange. I think you have it backwards: The way I read Rich's message, former LCM+L st= aff can talk to each other -- they can't really prevent that! -- but anyone s= till on at LCM+L can't talk to them about LCM+L (or presumably the public). That's fairly standard for a company; if I were to leave my employer, my form= er colleagues wouldn't be able to talk to me about current internal goings-on= there because I'm a civilian. (We could certainly talk about anything else.)= It's a bit weird for an educational/cultural institution though. -- Chris --===============3129229846595856162==-- From lproven@gmail.com Sat Nov 5 09:44:42 2022 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Sat, 05 Nov 2022 10:44:12 +0100 Message-ID: In-Reply-To: <0f796c69-1875-6cbb-18ec-3a8a44f71bcb@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1936992599344924631==" --===============1936992599344924631== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022 at 23:47, Grant Taylor via cctalk wrote: > > Please expand "GCR". Group-coded recording. https://en.wikipedia.org/wiki/Group_coded_recording Specifically: https://en.wikipedia.org/wiki/Group_coded_recording#Apple As opposed to Modified Frequency Modulation: https://en.wikipedia.org/wiki/Modified_frequency_modulation In ST-506 hard disks, MFM was supplemented by RLL, Run-length Limited: https://en.wikipedia.org/wiki/Run-length_limited -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============1936992599344924631==-- From lproven@gmail.com Sat Nov 5 09:45:28 2022 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Sat, 05 Nov 2022 10:44:57 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3755503674309915949==" --===============3755503674309915949== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 3 Nov 2022 at 23:52, Fred Cisin via cctalk wrote: > > Such as the classic Montezuma Micro CP/M for TRS80 Model 3, with "JOHN, > EAT SHIT AND DIE" in some sectors? ?! Do tell... -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============3755503674309915949==-- From harten@injectstar.de Sat Nov 5 16:17:49 2022 From: Harten To: cctalk@classiccmp.org Subject: [cctalk] Beehive Topper help needed Date: Sat, 05 Nov 2022 18:11:57 +0200 Message-ID: <5cd4a7425a.harten@injectstar.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4563279000795329099==" --===============4563279000795329099== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi folks! Is there anyone out there, who can help me with my Beehive Topper CP/M machine? The machine starts up with his self-test going o.k. Then it requests for the boot disk or pressing RETURN to start the Monitor V2.0 program. The Monitor program seems to work o.k. Booting a disk (written from the images out of the Maslin archive) puts some cryptic characters of the screen and hangs the machine. The images are for a Topper II, mine is a model Topper. Is this the problem? I have found very very little about the Topper machines, no manuals, no software, no schematics. R. Harten -- --===============4563279000795329099==-- From stepleton@gmail.com Sat Nov 5 19:02:25 2022 From: Tom Stepleton To: cctalk@classiccmp.org Subject: [cctalk] Re: Whitechapel Computer Works Date: Sat, 05 Nov 2022 19:01:56 +0000 Message-ID: In-Reply-To: <166766760741.2127582.5956391622996358580@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5932754622788662418==" --===============5932754622788662418== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 4 Nov 2022 17:53:10 PM Tony Duell wrote: > More seriously I have a working (last time I turned it on) MG1 with > monitor, keyboard, and mouse. Also have the technical notes manual and > an installation disk kit. Another chap I know (I think he's here but > I'll let him speak up) scanned the manual and coppied the disks last > year, so there is a backup.This is a 32016-based machine of course. It > Yes hello, this is me. In fact, if you would like to see the Whitechapel MG-1 in my possession in operation, come up tomorrow (Sunday) to the Centre for Computing History in Cambridge, where the system is on public display alongside an AT with a busy bunch of Transputers in it. It's all part of the Retro Computing Festival that's underway this weekend: http://www.computinghistory.org.uk/det/69485/Retro-Computer-Festival-2022-Sat= urday-5th-November/ If you can't make it to Cambridge, then when the machine is running (which it isn't at the moment --- wait for between 10 AM and 5 PM GMT Sunday), you can visit the machine over HTTP at http://mg-1.uk . (Note no https.) Working MG-1s and related machines (like the colour CG-1) are rare owing to leaky batteries (what else). I'm very grateful to Tony for his generous sharing of MG-1 materials --- it helps make it possible to show off the MG-1 in this way! I've got everything on Google Drive, with links available on the website just mentioned. Since it's liable to be down when you're reading this, here's an archive.org link: https://web.archive.org/web/20210625124716/http://mg-1.uk/ Note also this page with links to 42nix 2.6 OS media, also owing to Tony: https://web.archive.org/web/20210625124758/http://mg-1.uk/42nix/42nix.html You will probably have to edit archive.org's links out to Google Drive in order for them to work, but I think it should be pretty easy to do this. I have been meaning to make disk images of my best-effort reconstruction of a clean 42nix 2.5 installation (a predecessor to the version linked above), which I derived from a disk image taken from one of Jim Austin's MG-1s. There is not a vast difference for the user at the console between 2.5 and 2.6, although they did fix a bug in the TCP/IP implementation that allows a forking HTTP server running on 2.5 to cause a kernel panic. I suspect revisions to TCP/IP were required to get NFS working, which, I remember concluding, had been a new feature for 2.6. I've never been able to get my hands on GENIX. All sorts of spare boards, including things like never-populated bare > RAM boards for the Hitech,. > It took me a lot longer than I like to admit to realise that HITECH was derived from wHITECHapel... Speaking of discoveries, I found out today that the Centre for Computing History is in possession of a couple Hitech MIPS machines (sans cases). Apparently they might have some media on QIC tapes as well. Tony, I'll try to get you in touch with the person I was speaking with about this. Meanwhile TNMOC at Bletchley are in possession of three MG-1s. --Tom --===============5932754622788662418==-- From stepleton@gmail.com Sat Nov 5 19:08:28 2022 From: Tom Stepleton To: cctalk@classiccmp.org Subject: [cctalk] Re: Whitechapel Computer Works Date: Sat, 05 Nov 2022 19:08:01 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3134931035181700512==" --===============3134931035181700512== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I forgot to add that some gradual but real progress on adding the MG-1 to MAME is taking place as well. --Tom On Sat, Nov 5, 2022 at 7:01 PM Tom Stepleton wrote: > On Fri, 4 Nov 2022 17:53:10 PM Tony Duell wrote: > >> More seriously I have a working (last time I turned it on) MG1 with >> monitor, keyboard, and mouse. Also have the technical notes manual and >> an installation disk kit. Another chap I know (I think he's here but >> I'll let him speak up) scanned the manual and coppied the disks last >> year, so there is a backup.This is a 32016-based machine of course. It >> > > Yes hello, this is me. In fact, if you would like to see the Whitechapel > MG-1 in my possession in operation, come up tomorrow (Sunday) to the Centre > for Computing History in Cambridge, where the system is on public display > alongside an AT with a busy bunch of Transputers in it. It's all part of > the Retro Computing Festival that's underway this weekend: > > http://www.computinghistory.org.uk/det/69485/Retro-Computer-Festival-2022-S= aturday-5th-November/ > > If you can't make it to Cambridge, then when the machine is running (which > it isn't at the moment --- wait for between 10 AM and 5 PM GMT Sunday), you > can visit the machine over HTTP at http://mg-1.uk . (Note no https.) > > Working MG-1s and related machines (like the colour CG-1) are rare owing > to leaky batteries (what else). > > I'm very grateful to Tony for his generous sharing of MG-1 materials --- > it helps make it possible to show off the MG-1 in this way! I've got > everything on Google Drive, with links available on the website just > mentioned. Since it's liable to be down when you're reading this, here's an > archive.org link: > > https://web.archive.org/web/20210625124716/http://mg-1.uk/ > > Note also this page with links to 42nix 2.6 OS media, also owing to Tony: > > https://web.archive.org/web/20210625124758/http://mg-1.uk/42nix/42nix.html > > You will probably have to edit archive.org's links out to Google Drive in > order for them to work, but I think it should be pretty easy to do this. > > I have been meaning to make disk images of my best-effort reconstruction > of a clean 42nix 2.5 installation (a predecessor to the version linked > above), which I derived from a disk image taken from one of Jim Austin's > MG-1s. There is not a vast difference for the user at the console between > 2.5 and 2.6, although they did fix a bug in the TCP/IP implementation that > allows a forking HTTP server running on 2.5 to cause a kernel panic. I > suspect revisions to TCP/IP were required to get NFS working, which, I > remember concluding, had been a new feature for 2.6. > > I've never been able to get my hands on GENIX. > > All sorts of spare boards, including things like never-populated bare >> RAM boards for the Hitech,. >> > > It took me a lot longer than I like to admit to realise that HITECH was > derived from wHITECHapel... > > Speaking of discoveries, I found out today that the Centre for Computing > History is in possession of a couple Hitech MIPS machines (sans cases). > Apparently they might have some media on QIC tapes as well. Tony, I'll try > to get you in touch with the person I was speaking with about this. > > Meanwhile TNMOC at Bletchley are in possession of three MG-1s. > > --Tom > --===============3134931035181700512==-- From dkelvey@hotmail.com Sat Nov 5 19:09:44 2022 From: dwight To: cctalk@classiccmp.org Subject: [cctalk] Re: Disk imaging n00b Date: Sat, 05 Nov 2022 19:09:28 +0000 Message-ID: In-Reply-To: <1233804e-a396-e9c-ce3-227d3bd734b@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8365778421255233416==" --===============8365778421255233416== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Disk compression gone wrong. I had a number of files from a hard drive to save to floppies. Even compresse= d it took 3 floppies. Al was fine until one night, I was carrying the box of these and other floppi= es. As I got out of the car, I dropped several disc and before I could stop, my f= oot came down on the first disk, of the three ( in the dark). I was never able to recover any useful information from any of the three disc= . I didn't create those disc and the person that did had lost the source. I am willing to waste space to keep the original format, of each file, as muc= h as possible. Any problem reading the first information of compressed files may mean the lo= ss of all. I only use compressed if it is to be re-expanded at it final destination. Dwight ________________________________ --===============8365778421255233416==-- From pete@dunnington.plus.com Sat Nov 5 20:22:51 2022 From: Pete Turnbull To: cctalk@classiccmp.org Subject: [cctalk] Re: Whitechapel Computer Works Date: Sat, 05 Nov 2022 20:10:38 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5061350033650020957==" --===============5061350033650020957== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 04/11/2022 17:47, Jonathan Katz via cctalk wrote: > Hi everyone! > > I'm curious; other than Wikipedia what do we know about Whitechapel > workstations? Do any of us have some working in our collections, with > software, disk dumps, etc? Jim Austin has 4 or 5 MG1s and a CG1 in his collection. https://www.computermuseum.org.uk/ -- Pete Pete Turnbull --===============5061350033650020957==-- From tony@tonyjones.com Sat Nov 5 20:53:38 2022 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Whitechapel Computer Works Date: Sat, 05 Nov 2022 13:53:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8547689364507333356==" --===============8547689364507333356== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I attended Queen Mary College from 86-89. They had just received several dozen MG1s. I believe the WCW founders came from QMC. By the final year a good 1/4 we're non-functional as the keyboards has failed and by then WCW has gone bankrupt a second time (for good). I remember one the programmers trying to encourage the more enterprising 3rd year students to take on building a IBM keyboard adapter as their final year project :-) I'd love one for nostalgias sake but I live in the US now though shipping to my mum's may be possible though no clue if they can handle 120v. Lots of good memories. Eliot Miranda worked at QMC and had ported his BrouHaHa smalltalk to the MG1. I remember using Occam (emulator), Lisp, ML, Modula2 and C plus of course Smalltalk 80 all on the MG1. Tony --===============8547689364507333356==-- From toby@telegraphics.com.au Sat Nov 5 21:46:39 2022 From: Toby Thain To: cctalk@classiccmp.org Subject: [cctalk] To cctalk owner: There's a problem subscribing Date: Sat, 05 Nov 2022 17:46:22 -0400 Message-ID: <0e93fa0a-06d5-86d3-32d4-94e3a28b333c@telegraphics.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6936747981990029883==" --===============6936747981990029883== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Clicking Subscribe goes to a Not Found page. I found this out because I'm trying to subscribe with a new email address. --Toby --===============6936747981990029883==-- From dave.g4ugm@gmail.com Sat Nov 5 22:38:32 2022 From: dave.g4ugm@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing Date: Sat, 05 Nov 2022 22:38:17 +0000 Message-ID: <0ef701d8f167$4cd54380$e67fca80$@gmail.com> In-Reply-To: <0e93fa0a-06d5-86d3-32d4-94e3a28b333c@telegraphics.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3590406460044836313==" --===============3590406460044836313== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Toby, I think you can subscribe here:- https://www.classiccmp.org/mailman3/postorius/lists/cctalk.classiccmp.org/ Dave > -----Original Message----- > From: Toby Thain via cctalk > Sent: 05 November 2022 21:46 > To: General Discussion: On-Topic and Off-Topic Posts > Cc: Toby Thain > Subject: [cctalk] To cctalk owner: There's a problem subscribing >=20 > Clicking Subscribe goes to a Not Found page. >=20 > I found this out because I'm trying to subscribe with a new email address. >=20 >=20 > --Toby --===============3590406460044836313==-- From lproven@gmail.com Sat Nov 5 22:45:44 2022 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Topper help needed Date: Sat, 05 Nov 2022 23:45:16 +0100 Message-ID: In-Reply-To: <5cd4a7425a.harten@injectstar.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5509142244367478562==" --===============5509142244367478562== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 5 Nov 2022 at 17:17, Harten via cctalk wrot= e: > > Hi folks! > > Is there anyone out there, who can help me with my Beehive Topper > CP/M machine? One of these? https://www.reddit.com/r/retrocomputing/comments/vud92z/weve_found_a_beehive_= international_bee_1_or_b1_in/ --=20 Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============5509142244367478562==-- From cclist@sydex.com Sat Nov 5 23:05:20 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Topper help needed Date: Sat, 05 Nov 2022 15:55:33 -0700 Message-ID: <0096c287-ef8c-45a3-252b-cd0ec5cedcd2@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0157769544453985041==" --===============0157769544453985041== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/5/22 15:45, Liam Proven via cctalk wrote: > On Sat, 5 Nov 2022 at 17:17, Harten via cctalk wr= ote: >> >> Hi folks! >> >> Is there anyone out there, who can help me with my Beehive Topper >> CP/M machine? >=20 >=20 > One of these? >=20 > https://www.reddit.com/r/retrocomputing/comments/vud92z/weve_found_a_beehiv= e_international_bee_1_or_b1_in/ Isn't that just a B1 terminal? http://bitsavers.org/pdf/beehive/ads/Beehive_Micro_B1.jpg --Chuck --===============0157769544453985041==-- From sellam.ismail@gmail.com Sun Nov 6 02:01:26 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Topper help needed Date: Sat, 05 Nov 2022 19:00:58 -0700 Message-ID: In-Reply-To: <0096c287-ef8c-45a3-252b-cd0ec5cedcd2@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4839913362070074515==" --===============4839913362070074515== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've never heard of Beehive making anything but terminals but then everyone and their mother corporation were making CP/M computers at one point so it's certainly both plausible and possible. Sellam On Sat, Nov 5, 2022 at 4:05 PM Chuck Guzis via cctalk wrote: > On 11/5/22 15:45, Liam Proven via cctalk wrote: > > On Sat, 5 Nov 2022 at 17:17, Harten via cctalk > wrote: > >> > >> Hi folks! > >> > >> Is there anyone out there, who can help me with my Beehive Topper > >> CP/M machine? > > > > > > One of these? > > > > > https://www.reddit.com/r/retrocomputing/comments/vud92z/weve_found_a_beehiv= e_international_bee_1_or_b1_in/ > > Isn't that just a B1 terminal? > > http://bitsavers.org/pdf/beehive/ads/Beehive_Micro_B1.jpg > > --Chuck > --===============4839913362070074515==-- From couryhouse@aol.com Sun Nov 6 02:13:29 2022 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Topper help needed Date: Sun, 06 Nov 2022 02:13:09 +0000 Message-ID: <1130788462.182620.1667700789523@mail.yahoo.com> In-Reply-To: <0096c287-ef8c-45a3-252b-cd0ec5cedcd2@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2406217009005885440==" --===============2406217009005885440== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Iam looking for the beehive has detached keyboard upper case oly tanish caseI= was king of uppercase only on the hp2000 with that.=C2=A0 Needs to be clean = an if working that is a bonus!=C2=A0 Upper case forsever ubies.=C2=A0 Hah!!!!! Drop me a line=C2=A0 with photo, condition and price!Ed# Sent from the all new AOL app for Android=20 =20 On Sat, Nov 5, 2022 at 4:05 PM, Chuck Guzis via cctalk wrote: On 11/5/22 15:45, Liam Proven via cctalk wrote: > On Sat, 5 Nov 2022 at 17:17, Harten via cctalk wr= ote: >> >> Hi folks! >> >> Is there anyone out there, who can help me with my Beehive Topper >> CP/M machine? >=20 >=20 > One of these? >=20 > https://www.reddit.com/r/retrocomputing/comments/vud92z/weve_found_a_beehiv= e_international_bee_1_or_b1_in/ Isn't that just a B1 terminal? http://bitsavers.org/pdf/beehive/ads/Beehive_Micro_B1.jpg --Chuck =20 --===============2406217009005885440==-- From pbirkel@gmail.com Sun Nov 6 07:50:16 2022 From: pbirkel@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] Seeking DEC BN25B-nn Optical Fiber Cable Date: Sun, 06 Nov 2022 02:49:49 -0500 Message-ID: <024a01d8f1b4$593989e0$0bac9da0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4509640120593667710==" --===============4509640120593667710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is a twin/duplex cable of varying length with 100/140 um "multimode" cores and SMA-906 connectors. SMA-906 connectors have the stepped center-pin, compared to the SMA-905 which is a simpler straight pin. It's used, for example, by the LAN Bridge 100. For additional information see pages 169 through 335 (of 452) in http://www.bitsavers.org/pdf/dec/comm/EK-CMIV7-RM-005_Communications_Options _Minireference_Manual_Vol7_Aug88.pdf Probably it has an orange sheath so it would be somewhat distinctive in your tangled pile of cables :-}. Thank you for looking, paul --===============4509640120593667710==-- From toby@telegraphics.net Sun Nov 6 10:58:37 2022 From: Toby Thain To: cctalk@classiccmp.org Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing Date: Sat, 05 Nov 2022 20:50:10 -0400 Message-ID: <9ca64844-3a4e-bc12-89b9-8e597324a7c6@telegraphics.net> In-Reply-To: <0ef701d8f167$4cd54380$e67fca80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1088658986001375808==" --===============1088658986001375808== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2022-11-05 6:38 p.m., Dave Wade G4UGM via cctalk wrote: > Toby, > I think you can subscribe here:- >=20 > https://www.classiccmp.org/mailman3/postorius/lists/cctalk.classiccmp.org/ >=20 I'll try that, but Google led me to this page where I had the problem: https://classiccmp.org/cctalk.html --Toby > Dave >=20 >> -----Original Message----- >> From: Toby Thain via cctalk >> Sent: 05 November 2022 21:46 >> To: General Discussion: On-Topic and Off-Topic Posts >> Cc: Toby Thain >> Subject: [cctalk] To cctalk owner: There's a problem subscribing >> >> Clicking Subscribe goes to a Not Found page. >> >> I found this out because I'm trying to subscribe with a new email address. >> >> >> --Toby >=20 --===============1088658986001375808==-- From dave.g4ugm@gmail.com Sun Nov 6 11:24:39 2022 From: dave.g4ugm@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing Date: Sun, 06 Nov 2022 11:24:22 +0000 Message-ID: <10ea01d8f1d2$51d8d2a0$f58a77e0$@gmail.com> In-Reply-To: <9ca64844-3a4e-bc12-89b9-8e597324a7c6@telegraphics.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2575762296868390688==" --===============2575762296868390688== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Toby Thain via cctalk > Sent: 06 November 2022 00:50 > To: cctalk(a)classiccmp.org > Cc: Toby Thain > Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing >=20 > On 2022-11-05 6:38 p.m., Dave Wade G4UGM via cctalk wrote: > > Toby, > > I think you can subscribe here:- > > > > https://www.classiccmp.org/mailman3/postorius/lists/cctalk.classiccmp.org/ > > >=20 >=20 > I'll try that, but Google led me to this page where I had the problem: >=20 > https://classiccmp.org/cctalk.html >=20 Yes the links there haven't been updated to point to the new mail server. Dave >=20 >=20 > --Toby >=20 >=20 > > Dave > > > >> -----Original Message----- > >> From: Toby Thain via cctalk > >> Sent: 05 November 2022 21:46 > >> To: General Discussion: On-Topic and Off-Topic Posts > > >> Cc: Toby Thain > >> Subject: [cctalk] To cctalk owner: There's a problem subscribing > >> > >> Clicking Subscribe goes to a Not Found page. > >> > >> I found this out because I'm trying to subscribe with a new email addres= s. > >> > >> > >> --Toby > > --===============2575762296868390688==-- From harten@injectstar.de Sun Nov 6 14:22:52 2022 From: Harten To: cctalk@classiccmp.org Subject: [cctalk] Beehive Topper help needed Date: Sun, 06 Nov 2022 15:23:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4367441277702140020==" --===============4367441277702140020== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Liam, i'm sorry, but Chuck is right. Your link directs to a photo showing a terminal. The Topper was put into market as a intelligent terminal for stand alone use as a CP/M machine and for remote issues as a IBM compatible terminal. In fact the Topper has a 8085 CPU for the terminal part and a Z80 for the CP/M part. On booting the system disk you should be asked which functionalilty you want. There is a marketing brochure i have found in the www, where the Topper is mentioned beside some other Beehive terminals. Rolf --===============4367441277702140020==-- From lproven@gmail.com Sun Nov 6 14:42:42 2022 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Topper help needed Date: Sun, 06 Nov 2022 15:42:14 +0100 Message-ID: In-Reply-To: <0096c287-ef8c-45a3-252b-cd0ec5cedcd2@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2971726751389526787==" --===============2971726751389526787== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 6 Nov 2022 at 00:05, Chuck Guzis via cctalk wrote: > > > > One of these? > > > > https://www.reddit.com/r/retrocomputing/comments/vud92z/weve_found_a_beeh= ive_international_bee_1_or_b1_in/ > > Isn't that just a B1 terminal? > > http://bitsavers.org/pdf/beehive/ads/Beehive_Micro_B1.jpg Could well be. I had to go out and didn't have time to write a longer message. As indeed I don't know. I found that quickly and merely wanted to demonstrate that, yes, there is quite a lot of reference to the Beehive Topper on the WWW, but yes, as OP said, most relates to the Topper II. I just searched for beehive topper "cp/m" and found dozens to hundreds of pages with links and downloads, but most referred to the Topper II. All I am saying is that it is out there but some Google Fu may be required. --=20 Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============2971726751389526787==-- From sellam.ismail@gmail.com Sun Nov 6 15:32:47 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Topper help needed Date: Sun, 06 Nov 2022 07:32:20 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1201580751764445793==" --===============1201580751764445793== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here are some stubs of information I found via Google Books search: Ad in Computer World (October 25, 1982) https://books.google.com/books?id=3D75XGp5bJW1UC&pg=3DRA1-PA16-IA13&dq=3Dbeeh= ive+topper+%22cp/m%22&hl=3Den&sa=3DX&ved=3D2ahUKEwiMivD07Zn7AhXOF1kFHdlhD6QQ6= AF6BAgLEAI#v=3Donepage&q=3Dbeehive%20topper%20%22cp%2Fm%22&f=3Dfalse Describes the Topper as a 3270 compatible terminal online and a CP/M personal computer offline. Infosystems (Volume 30, 1983) https://www.google.com/books/edition/Infosystems/zldUAAAAMAAJ?hl=3Den&gbpv=3D= 1&bsq=3Dbeehive+topper+%22cp/m%22&dq=3Dbeehive+topper+%22cp/m%22&printsec=3Df= rontcover Google restricts the view to just a few lines. For what it was worth, Sellam On Sun, Nov 6, 2022 at 6:42 AM Liam Proven via cctalk wrote: > On Sun, 6 Nov 2022 at 00:05, Chuck Guzis via cctalk > wrote: > > > > > > One of these? > > > > > > > https://www.reddit.com/r/retrocomputing/comments/vud92z/weve_found_a_beehiv= e_international_bee_1_or_b1_in/ > > > > Isn't that just a B1 terminal? > > > > http://bitsavers.org/pdf/beehive/ads/Beehive_Micro_B1.jpg > > Could well be. > > I had to go out and didn't have time to write a longer message. As > indeed I don't know. > > I found that quickly and merely wanted to demonstrate that, yes, there > is quite a lot of reference to the Beehive Topper on the WWW, but yes, > as OP said, most relates to the Topper II. > > I just searched for > > beehive topper "cp/m" > > and found dozens to hundreds of pages with links and downloads, but > most referred to the Topper II. > > All I am saying is that it is out there but some Google Fu may be required. > > > > -- > Liam Proven ~ Profile: https://about.me/liamproven > Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com > Twitter/LinkedIn: lproven ~ Skype: liamproven > UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) > 702-829-053 > --===============1201580751764445793==-- From pbirkel@gmail.com Sun Nov 6 18:00:47 2022 From: pbirkel@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking DEC BN25B-nn Optical Fiber Cable Date: Sun, 06 Nov 2022 13:00:28 -0500 Message-ID: <02c801d8f209$a7685650$f63902f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5738110092956775102==" --===============5738110092956775102== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > From: pbirkel(a)gmail.com > Sent: Sunday, November 6, 2022 2:50 AM > To: General Discussion: On-Topic and Off-Topic Posts > Subject: Seeking DEC BN25B-nn Optical Fiber Cable > > This is a twin/duplex cable of varying length with 100/140 um "multimode" cores and > SMA-906 connectors. SMA-906 connectors have the stepped center-pin, compared to > the SMA-905 which is a simpler straight pin. It's used, for example, by the LAN Bridge 100. > > For additional information see pages 169 through 335 (of 452) in > http://www.bitsavers.org/pdf/dec/comm/EK-CMIV7-RM-005_Communications_Options _Minireference_Manual_Vol7_Aug88.pdf I'm reliably informed that the cable actually has a light beige jacket (not orange), so not so easy to spot in your tangled pile of cables :-{. paul --===============5738110092956775102==-- From spectre@floodgap.com Sun Nov 6 21:45:19 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] IBM 4863 monitor sync problem (PCjr display) Date: Sun, 06 Nov 2022 13:44:57 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5076030232708424434==" --===============5076030232708424434== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Got the Peanuts out today for a shakedown. They work well, or at least they d= id until about 5 minutes into playing Kings Quest when the h-sync on the monitor suddenly went out. Colours show and match what should be on screen but the horizontal display is scrambled. It does it on both Peanuts, so I think something in the display blew. Anyone recognize this issue? Seems like it should be a straightforward fix; I can't imagine this monitor is particularly complex internally. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Put down your guns, it's Weasel Stomping Day! ----------------------------= -- --===============5076030232708424434==-- From cz@alembic.crystel.com Mon Nov 7 02:24:06 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 4863 monitor sync problem (PCjr display) Date: Sun, 06 Nov 2022 21:23:45 -0500 Message-ID: <4d75c6f5-b158-d8f2-374c-6d0144308fa1@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1624027620418722398==" --===============1624027620418722398== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I had a problem like this on a VT52, and the problem turned out to be=20 one the power supplies (the -12v one) had died. Wired in a 7812 (or=20 whatever it is for - voltage) and the monitor came back. May want to look inside and see if a supply rail is dead. C On 11/6/2022 4:44 PM, Cameron Kaiser via cctalk wrote: > Got the Peanuts out today for a shakedown. They work well, or at least they= did > until about 5 minutes into playing Kings Quest when the h-sync on the monit= or > suddenly went out. Colours show and match what should be on screen but the > horizontal display is scrambled. It does it on both Peanuts, so I think > something in the display blew. >=20 > Anyone recognize this issue? Seems like it should be a straightforward fix;= I > can't imagine this monitor is particularly complex internally. >=20 --===============1624027620418722398==-- From johnhreinhardt@thereinhardts.org Mon Nov 7 04:46:18 2022 From: "John H. Reinhardt" To: cctalk@classiccmp.org Subject: [cctalk] Shipping help in Brunswick, GA Date: Sun, 06 Nov 2022 22:37:55 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2004361381819259129==" --===============2004361381819259129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable So, I screwed up and in my excitement to find a DEC BA123 chassis (and MVII p= arts) I bid on an Ebay auction where there is no shipping and it's "Local Pic= kup Only".=C2=A0 The problem is that I'm near Fort Worth TX and the MVII/BA12= 3 is in Brunswick, GA and I don't really have the time to make the 2000+ mile= round trip drive to pick it up. Does anyone here know of a reliable shipping service in Brunswick, GA?=C2=A0 = Or suggestions for outfits to check out?=C2=A0 Google hasn't shown me much ot= her that UPS and FedEx stores. Failing that, is there anyone near enough willing to pick it up in Brunswick = that might want it for themselves? Ebay listing=C2=A0 https://www.ebay.com/itm/334615827742? --=20 John H. Reinhardt --===============2004361381819259129==-- From sellam.ismail@gmail.com Mon Nov 7 05:05:28 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Shipping help in Brunswick, GA Date: Sun, 06 Nov 2022 21:04:58 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3918709795986017155==" --===============3918709795986017155== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Back in the day, Forward Air was a good option with good rates ==> https://www.forwardair.com/ I haven't used them in years though. And someone will still have to prepare it for freight shipment (i.e. palletize it). Or, maybe visit your nearest truck stop and talk to some truckers and ask how you could find someone who might want to bring the machine back to Texas on a return trip for some agreed upon amount. Or, you might try contacting the VCF Southeast folks for assistance. Sellam On Sun, Nov 6, 2022 at 8:46 PM John H. Reinhardt via cctalk < cctalk(a)classiccmp.org> wrote: > So, I screwed up and in my excitement to find a DEC BA123 chassis (and > MVII parts) I bid on an Ebay auction where there is no shipping and it's > "Local Pickup Only". The problem is that I'm near Fort Worth TX and the > MVII/BA123 is in Brunswick, GA and I don't really have the time to make the > 2000+ mile round trip drive to pick it up. > > Does anyone here know of a reliable shipping service in Brunswick, GA? Or > suggestions for outfits to check out? Google hasn't shown me much other > that UPS and FedEx stores. > > Failing that, is there anyone near enough willing to pick it up in > Brunswick that might want it for themselves? > > Ebay listing https://www.ebay.com/itm/334615827742? > > -- > > John H. Reinhardt > > > --===============3918709795986017155==-- From jrr@flippers.com Mon Nov 7 06:10:37 2022 From: John Robertson To: cctalk@classiccmp.org Subject: [cctalk] Re: Shipping help in Brunswick, GA Date: Sun, 06 Nov 2022 22:04:45 -0800 Message-ID: <96ccc0c1-cc49-938f-ef74-16b7c9bcad4e@flippers.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2002634257437939948==" --===============2002634257437939948== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2022/11/06 8:37 p.m., John H. Reinhardt via cctalk wrote: > So, I screwed up and in my excitement to find a DEC BA123 chassis (and > MVII parts) I bid on an Ebay auction where there is no shipping and > it's "Local Pickup Only".  The problem is that I'm near Fort Worth TX > and the MVII/BA123 is in Brunswick, GA and I don't really have the > time to make the 2000+ mile round trip drive to pick it up. > > Does anyone here know of a reliable shipping service in Brunswick, > GA?  Or suggestions for outfits to check out?  Google hasn't shown me > much other that UPS and FedEx stores. > > Failing that, is there anyone near enough willing to pick it up in > Brunswick that might want it for themselves? > > Ebay listing  https://www.ebay.com/itm/334615827742? > If they can put it on a pallet then you can find a Freight Forwarder in the area that can arrange a pickup... Or contact North American Van Lines (NAVL-Beltman) Michele Bianchi (630-344-3093) there arranges pickups of equipment (like arcade games for home owners) in similar situations. This service isn't as cheap as trucking would be from a Freight Forwarder. Good luck! John :-#)# -- John's Jukes Ltd. 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 Call (604)872-5757 (Pinballs, Jukes, Video Games) flippers.com "Old pinballers never die, they just flip out" --===============2002634257437939948==-- From spectre@floodgap.com Mon Nov 7 17:46:57 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 4863 monitor sync problem (PCjr display) Date: Mon, 07 Nov 2022 09:46:34 -0800 Message-ID: <3906c6ba-2ad2-0c08-aba1-fee99eeb5542@floodgap.com> In-Reply-To: <4d75c6f5-b158-d8f2-374c-6d0144308fa1@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3826978228788728446==" --===============3826978228788728446== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I had a problem like this on a VT52, and the problem turned out to be one t= he > power supplies (the -12v one) had died. Wired in a 7812 (or whatever it is = for > - voltage) and the monitor came back. >=20 > May want to look inside and see if a supply rail is dead. A good suggestion. This morning it powers up fine, so maybe there's a cold or bad solder joint somewhere in that area, or a failing cap. I'll check the rai= ls next time it goes bad. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- They told me I was gullible ... and I believed them. ---------------------= -- --===============3826978228788728446==-- From bob@jfcl.com Mon Nov 7 23:52:16 2022 From: Robert Armstrong To: cctalk@classiccmp.org Subject: [cctalk] Replacement tachometer sensor for DEC RA80/1/2 drives ... Date: Mon, 07 Nov 2022 15:51:55 -0800 Message-ID: <003901d8f303$eb29b460$c17d1d20$@com> In-Reply-To: <166784400629.2127582.17531488387843155250@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3300471582945486614==" --===============3300471582945486614== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have three DEC RA8x drives that have failed (all of them fault with "spin error") because of bad photo-interrupter tachometer sensors. After talking to a few friends, it sounds like this is a pretty common fault. Photo sensors like this are fairly common, even today, but the specific parts DEC used are weird and unobtainable. I designed a little PC board that uses an ITR9606 photo interrupter, a 2N3904 and a resistor as a replacement. Works great - gives a beautiful 5V P-P clean waveform and with the PCB it's a mechanical drop in replacement. Just screws right onto the original mounting holes and plugs into the original connector. I put the PCB design up on OSH Park https://oshpark.com/shared_projects/z8DSkQsP If anybody needs one you're welcome to order some PCBs and build your own. The ITR9606 is as common as dirt, and you can buy bags of ten on Amazon for a few bucks. I've also put a few pictures on the Facebook DEC Computer Users group. I'd post the pictures here, but I don't think cctalk accepts attachments. It's not really worth making a web page for it. Bob --===============3300471582945486614==-- From billdegnan@gmail.com Tue Nov 8 00:34:27 2022 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Beehive Terminal Manual Date: Mon, 07 Nov 2022 19:33:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6271264424329229863==" --===============6271264424329229863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Useful? https://www.vintagecomputer.net/cromemco/3102/1979%20Beehive%20MicroB%20DM10%= 20DM1A%20Terminals%20197911.pdf Bill --===============6271264424329229863==-- From bitwiz@12bitsbest.com Tue Nov 8 00:36:24 2022 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ... Date: Mon, 07 Nov 2022 18:01:37 -0600 Message-ID: <9c7eea17-fd66-073a-2003-e5512f98b148@12bitsbest.com> In-Reply-To: <003901d8f303$eb29b460$c17d1d20$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3265338509275692400==" --===============3265338509275692400== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable May I suggest that you post this to the DEC forum on the VCFED.org website? On 11/7/2022 5:51 PM, Robert Armstrong via cctalk wrote: > I have three DEC RA8x drives that have failed (all of them fault with > "spin error") because of bad photo-interrupter tachometer sensors. After > talking to a few friends, it sounds like this is a pretty common fault. > Photo sensors like this are fairly common, even today, but the specific > parts DEC used are weird and unobtainable. > > I designed a little PC board that uses an ITR9606 photo interrupter, a > 2N3904 and a resistor as a replacement. Works great - gives a beautiful 5V > P-P clean waveform and with the PCB it's a mechanical drop in replacement. > Just screws right onto the original mounting holes and plugs into the > original connector. > > I put the PCB design up on OSH Park > > https://oshpark.com/shared_projects/z8DSkQsP > > If anybody needs one you're welcome to order some PCBs and build your own. > The ITR9606 is as common as dirt, and you can buy bags of ten on Amazon for > a few bucks. > > I've also put a few pictures on the Facebook DEC Computer Users group. I= 'd > post the pictures here, but I don't think cctalk accepts attachments. It's > not really worth making a web page for it. > > Bob > > --===============3265338509275692400==-- From paulkoning@comcast.net Tue Nov 8 00:57:15 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ... Date: Mon, 07 Nov 2022 19:56:54 -0500 Message-ID: In-Reply-To: <003901d8f303$eb29b460$c17d1d20$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5871085575123807571==" --===============5871085575123807571== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 7, 2022, at 6:51 PM, Robert Armstrong via cctalk wrote: >=20 > I have three DEC RA8x drives that have failed (all of them fault with > "spin error") because of bad photo-interrupter tachometer sensors. After > talking to a few friends, it sounds like this is a pretty common fault. > Photo sensors like this are fairly common, even today, but the specific > parts DEC used are weird and unobtainable. Does the tachometer have to be accurate, or does it just have to indicate "sp= inning fast enough" to satisfy the spin-up logic? In other words, does the a= ctual laying out of bits on the media depend on the tachometer? If not, you could just use a 555 to generate a pulse train at the nominal fre= quency, perhaps with a second 555 to delay that signal after power up to corr= espond to the typical time it takes the drive to get up to speed. paul --===============5871085575123807571==-- From cclist@sydex.com Tue Nov 8 01:04:57 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Terminal Manual Date: Mon, 07 Nov 2022 17:04:34 -0800 Message-ID: <07974889-701d-e159-8873-87c3f64bc316@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9078511699646108474==" --===============9078511699646108474== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I'm getting a little confused. Are we talking about the Topper, or a specific Beehive terminal? If it's the former, there's this: http://www.retroarchive.org/maslin/disks/beehive/index.html --Chuck --===============9078511699646108474==-- From bob@jfcl.com Tue Nov 8 01:28:12 2022 From: Robert Armstrong To: cctalk@classiccmp.org Subject: [cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ... Date: Mon, 07 Nov 2022 17:27:52 -0800 Message-ID: <000301d8f311$52854950$f78fdbf0$@com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1689678001585224245==" --===============1689678001585224245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >Paul Koning wrote: >Does the tachometer have to be accurate, or does it just have to indicate > "spinning fast enough" to satisfy the spin-up logic? It's not just spin up - the firmware monitors the disk speed all the time it's running. But AFAIK the tachometer has nothing to do with how the bits are recorded on the media. It's just there to be sure the disk is actually rotating. >If not, you could just use a 555 to generate a pulse train ... Maybe, probably, but I'm not sure why you'd want to. That's way more complicated than just fixing the tachometer sensor, and having the firmware shut down the motor in the event the belt breaks or jams, or if the motor brake (yes, it has a brake!) freezes, etc is an advantage. It's a fairly big motor and a fairly (by PC standards at least) heavy disk - there's a lot of mechanical energy there. Bob --===============1689678001585224245==-- From paulkoning@comcast.net Tue Nov 8 01:34:50 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ... Date: Mon, 07 Nov 2022 20:34:28 -0500 Message-ID: In-Reply-To: <000301d8f311$52854950$f78fdbf0$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0978612822545025955==" --===============0978612822545025955== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 7, 2022, at 8:27 PM, Robert Armstrong wrote: >=20 >> Paul Koning wrote: >> Does the tachometer have to be accurate, or does it just have to indicate >> "spinning fast enough" to satisfy the spin-up logic? >=20 > It's not just spin up - the firmware monitors the disk speed all the time > it's running. >=20 > But AFAIK the tachometer has nothing to do with how the bits are recorded > on the media. It's just there to be sure the disk is actually=20 > rotating. >=20 >> If not, you could just use a 555 to generate a pulse train ... >=20 > Maybe, probably, but I'm not sure why you'd want to. That's way more > complicated than just fixing the tachometer sensor, and having the firmware > shut down the motor in the event the belt breaks or jams, or if the motor > brake (yes, it has a brake!) freezes, etc is an advantage. It's a fairly > big motor and a fairly (by PC standards at least) heavy disk - there's a lot > of mechanical energy there. Indeed, but I was reacting to the statement that the DEC part is strange and = hard to find. So if that turns out to be barrier, faking the tach signal wou= ld be a way to make the drive operational again. Another approach would be a bit of mechanical work to fit a stock optical sen= sor. That would depend on having access to the needed machining skills. paul --===============0978612822545025955==-- From dave.g4ugm@gmail.com Tue Nov 8 06:59:18 2022 From: dave.g4ugm@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ... Date: Tue, 08 Nov 2022 06:58:59 +0000 Message-ID: <1cc501d8f33f$93e75450$bbb5fcf0$@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2237756361660961317==" --===============2237756361660961317== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Paul Koning via cctalk > Sent: 08 November 2022 01:34 > To: Bob Armstrong > Cc: cctalk(a)classiccmp.org; Paul Koning > Subject: [cctalk] Re: Replacement tachometer sensor for DEC RA80/1/2 drives ... > > > > > On Nov 7, 2022, at 8:27 PM, Robert Armstrong wrote: > > > >> Paul Koning wrote: > >> Does the tachometer have to be accurate, or does it just have to > >> indicate "spinning fast enough" to satisfy the spin-up logic? > > > > It's not just spin up - the firmware monitors the disk speed all the > > time it's running. > > > > But AFAIK the tachometer has nothing to do with how the bits are > > recorded on the media. It's just there to be sure the disk is > > actually rotating. > > > >> If not, you could just use a 555 to generate a pulse train ... > > > > Maybe, probably, but I'm not sure why you'd want to. That's way more > > complicated than just fixing the tachometer sensor, and having the > > firmware shut down the motor in the event the belt breaks or jams, or > > if the motor brake (yes, it has a brake!) freezes, etc is an > > advantage. It's a fairly big motor and a fairly (by PC standards at > > least) heavy disk - there's a lot of mechanical energy there. > > Indeed, but I was reacting to the statement that the DEC part is strange and hard > to find. So if that turns out to be barrier, faking the tach signal would be a way > to make the drive operational again. The replacement board does not use the DEC part. > > Another approach would be a bit of mechanical work to fit a stock optical > sensor. That would depend on having access to the needed machining skills. That is what this mod does > > paul dave --===============2237756361660961317==-- From harten@injectstar.de Tue Nov 8 08:14:12 2022 From: Harten To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Terminal Manual Date: Tue, 08 Nov 2022 10:13:20 +0200 Message-ID: <878407445a.harten@injectstar.de> In-Reply-To: <07974889-701d-e159-8873-87c3f64bc316@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0855943690073869584==" --===============0855943690073869584== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit In message <07974889-701d-e159-8873-87c3f64bc316(a)sydex.com> Chuck Guzis via cctalk wrote: > I'm getting a little confused. Are we talking about the Topper, or a > specific Beehive terminal? If it's the former, there's this: > http://www.retroarchive.org/maslin/disks/beehive/index.html > --Chuck For me, i'm talking about the Topper I. From the various terminal manuals i could figure out some special keyboard functions, that work on the Topper too. For example: Ctrl-Shift-V performs a reset of the whole system (cold-start). The Topper has no Reset button. I found only one document where both the Topper I and Topper II are mentioned. It says: Topper I 64k CP/M 2.2 machine and IBM 3270 compatible terminal Topper TT 64k CP/M 2.2 machine and Burroughs compatible terminal The system disks from the Maslin archive are both for the model Topper II. They do not work on my Topper I. The machine reads something from this disks with no boot- or disk-error, prints some cryptic characters on the screen and seems to hang. It should ask me if want either - Command mode - CP/M mode - Terminal mode Rolf -- --===============0855943690073869584==-- From cclist@sydex.com Tue Nov 8 16:55:55 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Terminal Manual Date: Tue, 08 Nov 2022 08:55:31 -0800 Message-ID: <2c86cb9e-1aba-5f6f-3d4d-3cbca3313e98@sydex.com> In-Reply-To: <878407445a.harten@injectstar.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8741461019965813403==" --===============8741461019965813403== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/8/22 00:13, Harten via cctalk wrote: > For me, i'm talking about the Topper I. > >>From the various terminal manuals i could figure out some special > keyboard functions, that work on the Topper too. I haven't checked my own archives yet. If I find something, I'll forward it on. --Chuck --===============8741461019965813403==-- From sellam.ismail@gmail.com Tue Nov 8 20:03:29 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Beehive Terminal Manual Date: Tue, 08 Nov 2022 12:02:57 -0800 Message-ID: In-Reply-To: <878407445a.harten@injectstar.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1201919179388733555==" --===============1201919179388733555== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Nov 8, 2022 at 12:13 AM Harten via cctalk wrote: > In message <07974889-701d-e159-8873-87c3f64bc316(a)sydex.com> > Chuck Guzis via cctalk wrote: > > > I'm getting a little confused. Are we talking about the Topper, or a > > specific Beehive terminal? If it's the former, there's this: > > > http://www.retroarchive.org/maslin/disks/beehive/index.html > > > --Chuck > > For me, i'm talking about the Topper I. > > From the various terminal manuals i could figure out some special > keyboard functions, that work on the Topper too. > > For example: > Ctrl-Shift-V performs a reset of the whole system (cold-start). > The Topper has no Reset button. > ... > Rolf > > Fun fact: Mike Wise (creator of the Sphere I) claims to have invented the three-finger keyboard sequence hard reset (which was a fesature of the Sphere I), and I think his claim is valid. Sellam --===============1201919179388733555==-- From tony@tonyjones.com Tue Nov 8 21:16:14 2022 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Alacron i860 boards Date: Tue, 08 Nov 2022 13:15:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5967209555999607555==" --===============5967209555999607555== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I recently bought an Alacron FT200-AT dual i860 card. Basically the earlier ISA version of this: http://www.alacron.org/clientuploads/FT-200-PCI.PDF It included two manuals but no software. Alacron seems still in business but they didn't reply to email. I've called twice and noone answers their phone, it just goes to an anonymous voicemail. Does anyone have any software? I couldn't find anything via Google or on bitsavers. Thanks Tony --===============5967209555999607555==-- From davidkcollins2@gmail.com Tue Nov 8 21:27:28 2022 From: davidkcollins2@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] HP Computer Museum update Date: Wed, 09 Nov 2022 08:27:06 +1100 Message-ID: <029401d8f3b8$db5a9b70$920fd250$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0725828429775234201==" --===============0725828429775234201== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Those who have an interest in vintage HP computing will most likely know of the HP Computer Museum (www.hpmuseum.net). The HP Computer Museum is the result of over 30 years of work by Jon Johnston who collected HP equipment and documentation and systematically catalogued, photographed and commented on almost all of the over 7,000 items in the collection. After Jon's death in 2016, I kept the museum website going and worked on restoring many of the more notable items in the collection to working order, but the museum has largely been static for the last six years. Jon's wish was that the collection would eventually find its way either to HP or to one of the major computer museums, and I'm pleased to advise that the Hewlett Packard Company Archives (HPCA) has agreed to take over the entire collection and website. With only a few exceptions, the museum's entire collection of HP hardware, software and manuals has now been shipped from Melbourne, Australia, to HPCA's archival company - Heritage Werks Inc, in Atlanta, Georgia, USA. The equipment will be catalogued and preserved as a record of HP's early years in computing, with the ability for HP offices to borrow equipment for display purposes. The HP Computer Museum website (www.hpmuseum.net ), which has long been a popular reference resource for enthusiasts and industry on HP's computing history, will continue and be maintained by the HPCA, through Heritage Werks, with the intent of ensuring ongoing access to the wealth of information collected by Jon and many other HP enthusiasts over the last 30 years. Over the coming weeks and months, the website will be relocated to new hosting platforms and the curatorship will transfer to Heritage Werks. This will bring to a close my role in maintaining Jon's legacy in HP computing. It's been a privilege to be responsible for the collection and the website and to see the value they bring to the vintage computing community. David Collins --===============0725828429775234201==-- From doc@vaxen.net Tue Nov 8 21:32:22 2022 From: Doc Shipley To: cctalk@classiccmp.org Subject: [cctalk] Re: HP Computer Museum update Date: Tue, 08 Nov 2022 15:31:59 -0600 Message-ID: <7b0d5154-1c5a-b0ce-6f65-cfc083cfa50f@vaxen.net> In-Reply-To: <029401d8f3b8$db5a9b70$920fd250$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5054342502133034716==" --===============5054342502133034716== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/8/22 15:27, David Collins via cctalk wrote: > > With only a few exceptions, the museum's entire collection of HP hardware, > software and manuals has now been shipped from Melbourne, Australia, to > HPCA's archival company - Heritage Werks Inc, in Atlanta, Georgia, USA. The > equipment will be catalogued and preserved as a record of HP's early years > in computing, with the ability for HP offices to borrow equipment for > display purposes. > > This will bring to a close my role in maintaining Jon's legacy in HP > computing. It's been a privilege to be responsible for the collection and > the website and to see the value they bring to the vintage computing > community. This is a huge thing. I cannot imagine how much time and eergy you've invested making this happen. Congratulations on a successful transition, and thank you so very much for your efforts! Doc --===============5054342502133034716==-- From rdawson16@hotmail.com Tue Nov 8 22:06:46 2022 From: Randy Dawson To: cctalk@classiccmp.org Subject: [cctalk] Re: Alacron i860 boards Date: Tue, 08 Nov 2022 22:06:20 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3866505794382743347==" --===============3866505794382743347== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Wow Tony, thats a really cool board. I hope you get the support software, co= mpilers and all that. I had an i860 fromAT&T Truevision, for their TOPAS 3D modeling SW, but they = dropped it. The i860 was also in a desktop, Kubota bought the Ardent graphics supercomput= er and moving the software to this. What a flame that was, for a time there, we all thought we were going to get = graphics supercomputers. I have not coded any CUDA on the Nvidia boards yet, but I am sure it beats th= eir socks off. Randy ________________________________ From: Tony Jones via cctalk Sent: Tuesday, November 8, 2022 1:15 PM To: cctalk(a)classiccmp.org Cc: Tony Jones Subject: [cctalk] Alacron i860 boards I recently bought an Alacron FT200-AT dual i860 card. Basically the earlier ISA version of this: http://www.alacron.org/clientuploads/FT-200-PCI.PDF It included two manuals but no software. Alacron seems still in business but they didn't reply to email. I've called twice and noone answers their phone, it just goes to an anonymous voicemail. Does anyone have any software? I couldn't find anything via Google or on bitsavers. Thanks Tony --===============3866505794382743347==-- From rickb@bensene.com Wed Nov 9 06:18:23 2022 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: HP Computer Museum update Date: Tue, 08 Nov 2022 22:17:55 -0800 Message-ID: <923A614D09D64B4D94D588FCAFD04C17012D4B86@mail.bensene.com> In-Reply-To: <7b0d5154-1c5a-b0ce-6f65-cfc083cfa50f@vaxen.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7456489674807194057==" --===============7456489674807194057== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable David Collins wrote: >>=20 >> This will bring to a close my role in maintaining Jon's legacy in HP >> computing. It's been a privilege to be responsible for the collection and >> the website and to see the value they bring to the vintage computing >> community. To which Doc Shipley replied: > This is a huge thing. I cannot imagine how much time and energy you've=20 > invested making this happen. > Congratulations on a successful transition, and thank you so very much=20 > for your efforts! Doc's words are most heartily seconded by me. =20 Preserving this collection is so important. Knowing that it is becoming a pa= rt of HP's corporate archive hopefully assures that it will all be well cared= -for, as well as documented and shared in the decades to come. Thank you, David, for all of your efforts to make this happen. It had to be= a monumental task to make all of the arrangements, not to mention simply mai= ntaining it all for the years after Jon's passing. Most sincerely, -Rick -- Rick Bensene The Old Calculator Museum https://www.oldcalculatormuseum.com Beavercreek, Oregon USA --===============7456489674807194057==-- From lewissa78@gmail.com Wed Nov 9 08:18:18 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] CoreNET PC-51 info (IBM 5110) Date: Wed, 09 Nov 2022 02:17:44 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2275474139200794447==" --===============2275474139200794447== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Is anyone familiar with PC-51 and/or CoreNET? These are IBM 5110/5120 related tools developed by an individual in the early 1980s. My understanding is PC-51 was an emulator that ran BASIC programs from the IBM 5110. One keyword new in the IBM 5110 was the "FORMS" keyboard, and you could define input fields (including type-formatting constraints, like sequence of letters and numbers) -- and once defined, you could relatively-easily store all the contents of the fields to a file (on tape or disk). I'm not entirely sure what format PC-51 supported (e.g. could read in ASCII text files containing the BASIC programs?). But I always imagined those customer data entry forms in old Radio Shack or Sears stores -- large department stores -- being developed in something like this. And CoreNET, I think was some kind of "null modem cable" that let the IBM 5110 communicate with an IBM PC 5150. The IBM 5110 has 3x DB25 connectors at the backside (and 1x DB15 cable like what became the "standard" joystick port on some systems in mid-late 1980s). The external tape and disk system would use these connectors -- with software driven from the ROS. I've always imagined it would be possible to "bit bang" across these external IO pins with some PALM-assembly -- the machine should be fast enough to encode 7-bit ASCII at 300 baud across those pins, maybe 1200. I'm not sure if CoreNET used or required any async card or the parallel communication card (that did IEEE-488), i.e. not sure if it was more than just a cable. But what's more interesting - apparently Sony is now the owner of both these assets, PC51 and CoreNET. Maybe Hal Prewitt sold it to them? Why would Sony be interested in it? Anyone happen to know anyone who works at Sony, or ideas on where to start on even "asking them" about it? Might be a lost cause these days. Anyone happen to have a copy of the old manuals of either of these? -Steve --===============2275474139200794447==-- From cc@informatik.uni-stuttgart.de Wed Nov 9 10:22:21 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: CoreNET PC-51 info (IBM 5110) Date: Wed, 09 Nov 2022 11:21:53 +0100 Message-ID: <73fa9422-f5e6-ed17-dcc3-749e6d1a3f9d@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4334526882268600200==" --===============4334526882268600200== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 9 Nov 2022, Steve Lewis wrote: > always imagined it would be possible to "bit bang" across these external IO > pins with some PALM-assembly -- the machine should be fast enough to encode > 7-bit ASCII at 300 baud across those pins, maybe 1200. I'm not sure if The PALM and thus the 51[012]0 is much much faster than that (I guess about 0.7 MIPS). I do bit-banging on the Asynchronous Serial I/O card with twice the baud rate (to sample the center of a bit) and am able to do *full-duplex* communications *with* terminal emulation *and* character set conversion at 4800 baud. Using the byte mode of the I/O adapter I can go up to 38400 baud (used for file transfers). Remember: this card is absolutely dumb, it essentially only has shift registers and a clock generator. The benefits come from the zero-overhead interrupt context switches and the great number of fast processor registers. But back to your questions: I personally have never heard of these products. I only know that there was a third-party hard disk option. Christian --===============4334526882268600200==-- From lewissa78@gmail.com Wed Nov 9 14:33:10 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: CoreNET PC-51 info (IBM 5110) Date: Wed, 09 Nov 2022 08:32:36 -0600 Message-ID: In-Reply-To: <73fa9422-f5e6-ed17-dcc3-749e6d1a3f9d@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7296356438711926895==" --===============7296356438711926895== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Remember: this card is absolutely dumb, it essentially only has shift > registers and a clock generator Ah, the clock might be important. I was thinking of a terminal that could be written without the async card, and using maybe 3 pins on those set of external DB25 connectors. This is possible using the 4-pin connector "serial IO" connector on the 1980 Color Computer (but it struggles to do 1200 baud). And yes part of the work would be receiving ASCII and translating those results to "display character codes." I don't think the 5110 has a clock on its own, so you'd have to carefully time things? (like doing audio on an original Apple 2 with no RTC module). > But back to your questions: I personally have never heard of these > products. I only know that there was a third-party hard disk option. I got a response from Hal Prewitt a couple months ago (apparently the creator of these products), who stated he did still have a copy of PC-51, but said "none of the hardware" was still available for CoreNET. I asked if PC-51 could be made available basically into the public domain, but hadn't heard a response (then later I learned of the Sony connection, which maybe is the reason). -Steve On Wed, Nov 9, 2022 at 4:22 AM Christian Corti via cctalk < cctalk(a)classiccmp.org> wrote: > On Wed, 9 Nov 2022, Steve Lewis wrote: > > always imagined it would be possible to "bit bang" across these external > IO > > pins with some PALM-assembly -- the machine should be fast enough to > encode > > 7-bit ASCII at 300 baud across those pins, maybe 1200. I'm not sure if > > The PALM and thus the 51[012]0 is much much faster than that (I guess > about 0.7 MIPS). > I do bit-banging on the Asynchronous Serial I/O card with twice the baud > rate (to sample the center of a bit) and am able to do *full-duplex* > communications *with* terminal emulation *and* character set conversion at > 4800 baud. > Using the byte mode of the I/O adapter I can go up to 38400 baud (used for > file transfers). > Remember: this card is absolutely dumb, it essentially only has shift > registers and a clock generator. The benefits come from the zero-overhead > interrupt context switches and the great number of fast processor > registers. > > > But back to your questions: I personally have never heard of these > products. I only know that there was a third-party hard disk option. > > Christian > --===============7296356438711926895==-- From spectre@floodgap.com Wed Nov 9 19:23:57 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: HP Computer Museum update Date: Wed, 09 Nov 2022 11:23:34 -0800 Message-ID: <2056e347-af37-af23-6c72-47eb0c5fa107@floodgap.com> In-Reply-To: <029401d8f3b8$db5a9b70$920fd250$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2378294975094864818==" --===============2378294975094864818== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable David, > With only a few exceptions, the museum's entire collection of HP hardware, > software and manuals has now been shipped from Melbourne, Australia, to > HPCA's archival company - Heritage Werks Inc, in Atlanta, Georgia, USA. The > equipment will be catalogued and preserved as a record of HP's early years > in computing, with the ability for HP offices to borrow equipment for > display purposes. =20 Thanks for all your hard work on this and preserving a major historical treasure. Will software downloads remain available, particularly historical OS releases? --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Traditionally, most of Australia's imports come from overseas. -K. Enderbe= ry --===============2378294975094864818==-- From imp@bsdimp.com Thu Nov 10 02:52:48 2022 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Exabyte recovery Date: Wed, 09 Nov 2022 19:52:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0109563368861284147==" --===============0109563368861284147== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have a few old exabyte tapes of possible historic value. Who can I pay to get them recovered that has the best chance of success? Warner --===============0109563368861284147==-- From lewissa78@gmail.com Thu Nov 10 07:24:34 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: CoreNET PC-51 info (IBM 5110) Date: Thu, 10 Nov 2022 01:24:01 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6037972279000668987==" --===============6037972279000668987== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Just yesterday, I received the following notes from Hal Prewitt of CORE (see below). Some highlights: - confirmation that use of async, comm, parallel card was not necessary - from the PC51 manual, their hard drives were accessed as "device 08" (D08 instead of D80 for the IBM disk drive) - gives me hope that doing a similar thing with a modern SD card might be possible ! - Hal's notes (not shown below) indicate that "5,000 to 30,000 users of 5110s and 5120s," - does anyone have insight into NASA's usage of PALM in the 1960s? Notes from Hal Prewitt (HP): "CoreNET was our storage & network for the 5110/5120 systems. We wrote PALM assembler, linker and IO drivers. We engineered an interface card that connected to the 5110/20 cabling design. Build cables and assorted storage systems. Did not use Async, Comm or parallel card features. The HDD interface inside our drive boxes used SASI (predecessor to SCSI). On the 5110/20 we loaded a driver from the floppy which provided access to the CoreNet and our HD drives. The 5110/20 could directly access its storage devices (tape & floppies) and our HD systems just by using new references for our storage devices. We also had a card for the PC bus and box that connected to the 5110/20 cables which provided the PC with access to the CoreNet and IBM machines. Had a box with 8" flopies for the PC and when running PC-51 turned the PC into a 5110/20 replacement running Basic. The term "PALM" refers to the processor. I was not involved but think it was created for NASA for use in the 1960-1970s Apollo missions. IBM was the computer equipment contractor. And yes, the ROS emulated S/360 code." On Wed, Nov 9, 2022 at 2:17 AM Steve Lewis wrote: > > Is anyone familiar with PC-51 and/or CoreNET? > > These are IBM 5110/5120 related tools developed by an individual in the > early 1980s. > > My understanding is PC-51 was an emulator that ran BASIC programs from the > IBM 5110. One keyword new in the IBM 5110 was the "FORMS" keyboard, and > you could define input fields (including type-formatting constraints, like > sequence of letters and numbers) -- and once defined, you could > relatively-easily store all the contents of the fields to a file (on tape > or disk). I'm not entirely sure what format PC-51 supported (e.g. could > read in ASCII text files containing the BASIC programs?). But I always > imagined those customer data entry forms in old Radio Shack or Sears stores > -- large department stores -- being developed in something like this. > > > > And CoreNET, I think was some kind of "null modem cable" that let the IBM > 5110 communicate with an IBM PC 5150. The IBM 5110 has 3x DB25 connectors > at the backside (and 1x DB15 cable like what became the "standard" joystick > port on some systems in mid-late 1980s). The external tape and disk system > would use these connectors -- with software driven from the ROS. I've > always imagined it would be possible to "bit bang" across these external IO > pins with some PALM-assembly -- the machine should be fast enough to encode > 7-bit ASCII at 300 baud across those pins, maybe 1200. I'm not sure if > CoreNET used or required any async card or the parallel communication card > (that did IEEE-488), i.e. not sure if it was more than just a cable. > > > > > But what's more interesting - apparently Sony is now the owner of both > these assets, PC51 and CoreNET. Maybe Hal Prewitt sold it to them? Why > would Sony be interested in it? Anyone happen to know anyone who works at > Sony, or ideas on where to start on even "asking them" about it? Might be > a lost cause these days. > > > Anyone happen to have a copy of the old manuals of either of these? > > > -Steve > > --===============6037972279000668987==-- From cc@informatik.uni-stuttgart.de Thu Nov 10 12:09:00 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: CoreNET PC-51 info (IBM 5110) Date: Thu, 10 Nov 2022 13:08:35 +0100 Message-ID: <645d7990-fe4c-d060-51b8-ec6ce3f857c@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1919043588443715001==" --===============1919043588443715001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 9 Nov 2022, Steve Lewis wrote: > translating those results to "display character codes." I don't think the > 5110 has a clock on its own, so you'd have to carefully time things? (like > doing audio on an original Apple 2 with no RTC module). Sure it has. The ASync card does not have an oscillator. It divides the system clock that is brought out on one of the I/O bus pins (I think +OSC/4 on A3 pin 2). Anyways, it uses the 3.01824 MHz clock from this bus. Christian --===============1919043588443715001==-- From elson@pico-systems.com Thu Nov 10 15:45:33 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 09:45:12 -0600 Message-ID: <0537fabd-a27f-9dc6-65ed-728119499f2d@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4390207179164903675==" --===============4390207179164903675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/9/22 20:52, Warner Losh via cctalk wrote: > I have a few old exabyte tapes of possible historic value. Who can I pay to > get them recovered that has the best chance of success? > Very difficult.  We were a big user of Exabyte drives for processing of physics experimental data.  Our experience is Exabyte drives had a lifetime of 1-2 years, no matter if they were powered on, in heavy use or just parked on a shelf.  Back in the day, we found outfits that would refurbish and test the drives for a modest cost, but I assume they are not doing that now. I do have an 8200 drive here, but I have great doubts that it would work. Jon --===============4390207179164903675==-- From cctalk@beyondthepale.ie Thu Nov 10 16:28:37 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 16:18:26 +0000 Message-ID: <01SK6IDBLMYI8WYOLI@beyondthepale.ie> In-Reply-To: <0537fabd-a27f-9dc6-65ed-728119499f2d@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7730752825006490197==" --===============7730752825006490197== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Jon Elson via cctalk wrote: > On 11/9/22 20:52, Warner Losh via cctalk wrote: >> I have a few old exabyte tapes of possible historic value. Who can I pay to >> get them recovered that has the best chance of success? >> > Very difficult.  We were a big user of Exabyte drives for > processing of physics experimental data.  Our experience is > Exabyte drives had a lifetime of 1-2 years, no matter if > they were powered on, in heavy use or just parked on a > shelf.  Back in the day, we found outfits that would > refurbish and test the drives for a modest cost, but I > assume they are not doing that now. > > I do have an 8200 drive here, but I have great doubts that > it would work. > I have an Exabyte drive too, actually two drives in the one case. One of the drives has not worked at all while it has been in my care (the door was pulled off by someone attempting to extract the tape from it when it failed in service before I got it). A few years back I dug it out and found the other drive didn't work either. However, it was a fairly simple power supply fault and I was able to revive it enough to read some old tapes successfully. I'm not sure I'd trust it to try to read anything that might be of historic value though. Regards, Peter Coghlan. > > Jon > --===============7730752825006490197==-- From spectre@floodgap.com Thu Nov 10 16:45:18 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] GLACIER-01 in the DataRover 840 Date: Thu, 10 Nov 2022 08:44:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4576833932432882913==" --===============4576833932432882913== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cracked open my General Magic DataRover 840 to find out what specific MIPS R3000 variant is in it. However, the only chips that are large enough to be CPUs are *two* with Bowser logos marked (C)GMI JAPAN GLACIER-01 F840276. The other chips of notable size are easily identified as RAM, a sound/modem codec and the inverter for the LCD backlight. I've seen systems with two CPUs that handle two halves of an LCD (the Tandy PC-1 and Laser 50 come to mind), but none with a CPU this large. Any General Magic alums on the list who can explain more about these? --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- "Endian Little Hate We" -- credits from Connectix Virtual PC 6 for Mac ---= -- --===============4576833932432882913==-- From cclist@sydex.com Thu Nov 10 16:56:06 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 08:55:38 -0800 Message-ID: In-Reply-To: <01SK6IDBLMYI8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6845504135964158067==" --===============6845504135964158067== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I don't know where Jon is, but I'm located on the US Pacific Northwest. I have a couple of Exabyte drives and used my EXB-8700 about two months ago to recover some customer data, so I know it works--and is clean. If no one comes forth, I'd be willing to help out. --Chuck --===============6845504135964158067==-- From cz@alembic.crystel.com Thu Nov 10 18:19:10 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 13:18:46 -0500 Message-ID: In-Reply-To: <0537fabd-a27f-9dc6-65ed-728119499f2d@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7489973584098486292==" --===============7489973584098486292== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Indeed. I have a Cybernetics 8505 in the shed, I was just looking at it and wondering if it still worked. What tends to go on these things? Rubber in there, capstains, etc? C On 11/10/2022 10:45 AM, Jon Elson via cctalk wrote: > On 11/9/22 20:52, Warner Losh via cctalk wrote: >> I have a few old exabyte tapes of possible historic value. Who can I >> pay to >> get them recovered that has the best chance of success? >> > Very difficult.  We were a big user of Exabyte drives for processing of > physics experimental data.  Our experience is Exabyte drives had a > lifetime of 1-2 years, no matter if they were powered on, in heavy use > or just parked on a shelf.  Back in the day, we found outfits that would > refurbish and test the drives for a modest cost, but I assume they are > not doing that now. > > I do have an 8200 drive here, but I have great doubts that it would work. > > Jon > --===============7489973584098486292==-- From elson@pico-systems.com Thu Nov 10 19:09:36 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 13:09:19 -0600 Message-ID: <45d97088-d10d-7b56-6da3-6061f5236407@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1577093734731340632==" --===============1577093734731340632== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/10/22 12:18, Chris Zach via cctalk wrote: > Indeed. I have a Cybernetics 8505 in the shed, I was just > looking at it and wondering if it still worked. > > What tends to go on these things? Rubber in there, > capstains, etc? > > Clearly, rubber rollers go bad, but there seems to be > something else going on, because when ours went bad, they > would start blinking LEDs without any movement of stuff > inside.  So, some of the chips failed internal self-test.  > Or, that's how I remember it. Jon --===============1577093734731340632==-- From healyzh@avanthar.com Thu Nov 10 19:50:50 2022 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 11:50:29 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1821741085936791251==" --===============1821741085936791251== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As a reminder, since I=E2=80=99ve seen at least 3 different drives mentioned = in this thread. Not all drives can read all tapes. Given the age, I=E2=80=99d recommend someone that does this professionally (a= nd I believe that includes Chuck). I=E2=80=99ve worked with computer tapes f= or something like 40 years, and I try to avoid 8mm tapes, though I prefer the= m to 4mm tapes. Zane > On Nov 10, 2022, at 10:18 AM, Chris Zach via cctalk wrote: >=20 > Indeed. I have a Cybernetics 8505 in the shed, I was just looking at it and= wondering if it still worked. >=20 > What tends to go on these things? Rubber in there, capstains, etc? >=20 > C >=20 > On 11/10/2022 10:45 AM, Jon Elson via cctalk wrote: >> On 11/9/22 20:52, Warner Losh via cctalk wrote: >>> I have a few old exabyte tapes of possible historic value. Who can I pay = to >>> get them recovered that has the best chance of success? >>>=20 >> Very difficult. We were a big user of Exabyte drives for processing of ph= ysics experimental data. Our experience is Exabyte drives had a lifetime of = 1-2 years, no matter if they were powered on, in heavy use or just parked on = a shelf. Back in the day, we found outfits that would refurbish and test the= drives for a modest cost, but I assume they are not doing that now. >> I do have an 8200 drive here, but I have great doubts that it would work. >> Jon --===============1821741085936791251==-- From wayne.sudol@hotmail.com Thu Nov 10 20:16:08 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 20:15:44 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6388225765583367914==" --===============6388225765583367914== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Zane, what is the problem you=E2=80=99ve experienced with 8MM tapes? I have a= lot of home video 8MM that I=E2=80=99ve not converted to Dvd yet and was won= dering if the issue was related to tape deterioration or more to the drive me= chanism. Sent from my iPhone > On Nov 10, 2022, at 11:50, Zane Healy via cctalk = wrote: >=20 > =EF=BB=BFAs a reminder, since I=E2=80=99ve seen at least 3 different drives= mentioned in this thread. Not all drives can read all tapes. >=20 > Given the age, I=E2=80=99d recommend someone that does this professionally = (and I believe that includes Chuck). I=E2=80=99ve worked with computer tapes= for something like 40 years, and I try to avoid 8mm tapes, though I prefer t= hem to 4mm tapes. >=20 > Zane >=20 >=20 >=20 >=20 >> On Nov 10, 2022, at 10:18 AM, Chris Zach via cctalk wrote: >>=20 >> Indeed. I have a Cybernetics 8505 in the shed, I was just looking at it an= d wondering if it still worked. >>=20 >> What tends to go on these things? Rubber in there, capstains, etc? >>=20 >> C >>=20 >>> On 11/10/2022 10:45 AM, Jon Elson via cctalk wrote: >>> On 11/9/22 20:52, Warner Losh via cctalk wrote: >>>> I have a few old exabyte tapes of possible historic value. Who can I pay= to >>>> get them recovered that has the best chance of success? >>>>=20 >>> Very difficult. We were a big user of Exabyte drives for processing of p= hysics experimental data. Our experience is Exabyte drives had a lifetime of= 1-2 years, no matter if they were powered on, in heavy use or just parked on= a shelf. Back in the day, we found outfits that would refurbish and test th= e drives for a modest cost, but I assume they are not doing that now. >>> I do have an 8200 drive here, but I have great doubts that it would work. >>> Jon >=20 --===============6388225765583367914==-- From sellam.ismail@gmail.com Thu Nov 10 20:23:01 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 12:22:31 -0800 Message-ID: In-Reply-To: <45d97088-d10d-7b56-6da3-6061f5236407@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2807984922576039582==" --===============2807984922576039582== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've got this Exabyte 8900 drive currently listed for sale: https://www.ebay.com/itm/403940369941 Unfortunately I could not find a tape to do at least rudimentary testing. If you're interested, I'll give you a much better price in a direct sale. Contact me privately and I can provide more information about the drive and try to test it. Sellam On Thu, Nov 10, 2022 at 11:09 AM Jon Elson via cctalk wrote: > On 11/10/22 12:18, Chris Zach via cctalk wrote: > > Indeed. I have a Cybernetics 8505 in the shed, I was just > > looking at it and wondering if it still worked. > > > > What tends to go on these things? Rubber in there, > > capstains, etc? > > > > Clearly, rubber rollers go bad, but there seems to be > > something else going on, because when ours went bad, they > > would start blinking LEDs without any movement of stuff > > inside. So, some of the chips failed internal self-test. > > Or, that's how I remember it. > Jon > > > --===============2807984922576039582==-- From cclist@sydex.com Thu Nov 10 21:34:39 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 13:34:09 -0800 Message-ID: <8441bb69-7698-adbb-da6f-6a34ac70223b@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4530811519463047657==" --===============4530811519463047657== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit A quick look at that auction site shows that the Exabyte Mammoth tapes are now stupid cheap--some being offered in lots. There are also several 8900 drives for sale (even OBO). I think that LTO pretty much sounded the death knell for 8mm tape. No comparison in capacity or speed. --Chuck --===============4530811519463047657==-- From cclist@sydex.com Thu Nov 10 21:36:04 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 13:26:42 -0800 Message-ID: <65825150-7f1f-a863-2444-5086f76d9b02@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3804769335978920568==" --===============3804769335978920568== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/10/22 12:22, Sellam Abraham via cctalk wrote: > I've got this Exabyte 8900 drive currently listed for sale: > > https://www.ebay.com/itm/403940369941 > > Unfortunately I could not find a tape to do at least rudimentary testing. > If you're interested, I'll give you a much better price in a direct sale. > Contact me privately and I can provide more information about the drive and > try to test it. > The 8900 uses the Mammoth AME tapes, but can read earlier tapes. I like the 8700 (and 8505XL) for the regular oxide tapes. I don't think I've ever received so much as an inquiry regarding the Mammoth metal tapes. That was near the end of the 8mm media (1999) when other formats, such as DLT and DDS were gobbling up the market. IIRC that the AME tapes were stupid-pricey. --Chuck --===============3804769335978920568==-- From cz@alembic.crystel.com Thu Nov 10 22:36:50 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 17:36:30 -0500 Message-ID: <48c75c7e-cf15-6e09-f4ed-f371ecb1aaf3@alembic.crystel.com> In-Reply-To: <65825150-7f1f-a863-2444-5086f76d9b02@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1878650657078732729==" --===============1878650657078732729== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/10/2022 4:26 PM, Chuck Guzis via cctalk wrote: > The 8900 uses the Mammoth AME tapes, but can read earlier tapes. I like > the 8700 (and 8505XL) for the regular oxide tapes. I don't think I've > ever received so much as an inquiry regarding the Mammoth metal tapes. > That was near the end of the 8mm media (1999) when other formats, such > as DLT and DDS were gobbling up the market. IIRC that the AME tapes > were stupid-pricey. Yeah, we had Exabyte Mammoth tape drives for a while in changers at AAAS. They had a serious reliability problem which was not good for backup tapes, so we went to IBM LTO and the IBM tape changers. Those worked well. The Contemporary Cybernetics 8505's were pretty much bulletproof, I should get it inside and fire it up to see if anything works. Had hardware accelerated compression and was pretty quick for the mid 1990's technology. > > --Chuck > > --===============1878650657078732729==-- From imp@bsdimp.com Thu Nov 10 22:56:30 2022 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Exabyte recovery Date: Thu, 10 Nov 2022 15:55:58 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7647307683308343158==" --===============7647307683308343158== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, Nov 9, 2022 at 7:52 PM Warner Losh wrote: > I have a few old exabyte tapes of possible historic value. Who can I pay > to get them recovered that has the best chance of success? > These are 4GB tapes, I believe. Made in 1992 or 1994 give or take. They are in Sun dump format. i need the bits at least, but decoding from dump format wouldn't be bad. they are level 0 backups. And I'm really hoping to find a good service to do due to the age... I'd rather not do it on my own, even though it's easy enough to connect the equipment... Warner --===============7647307683308343158==-- From leec2124@gmail.com Thu Nov 10 23:32:37 2022 From: Lee Courtney To: cctalk@classiccmp.org Subject: [cctalk] Re: HP Computer Museum update Date: Thu, 10 Nov 2022 15:31:40 -0800 Message-ID: In-Reply-To: <029401d8f3b8$db5a9b70$920fd250$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0149097682810318795==" --===============0149097682810318795== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thank you David, for all the hard work, dedication, and keeping Jon's dream alive! I started my career at HP, working on the HP 1000 and know many many former and current HP employees appreciate this. Lee Courtney On Tue, Nov 8, 2022 at 1:27 PM David Collins via cctalk < cctalk(a)classiccmp.org> wrote: > Those who have an interest in vintage HP computing will most likely know of > the HP Computer Museum (www.hpmuseum.net). The HP Computer Museum is the > result of over 30 years of work by Jon Johnston who collected HP equipment > and documentation and systematically catalogued, photographed and commented > on almost all of the over 7,000 items in the collection. > > After Jon's death in 2016, I kept the museum website going and worked on > restoring many of the more notable items in the collection to working > order, > but the museum has largely been static for the last six years. > > Jon's wish was that the collection would eventually find its way either to > HP or to one of the major computer museums, and I'm pleased to advise that > the Hewlett Packard Company Archives (HPCA) has agreed to take over the > entire collection and website. > > With only a few exceptions, the museum's entire collection of HP hardware, > software and manuals has now been shipped from Melbourne, Australia, to > HPCA's archival company - Heritage Werks Inc, in Atlanta, Georgia, USA. > The > equipment will be catalogued and preserved as a record of HP's early years > in computing, with the ability for HP offices to borrow equipment for > display purposes. > > The HP Computer Museum website (www.hpmuseum.net > ), which has long been a popular reference resource for enthusiasts and > industry on HP's computing history, will continue and be maintained by the > HPCA, through Heritage Werks, with the intent of ensuring ongoing access to > the wealth of information collected by Jon and many other HP enthusiasts > over the last 30 years. > Over the coming weeks and months, the website will be relocated to new > hosting platforms and the curatorship will transfer to Heritage Werks. > > This will bring to a close my role in maintaining Jon's legacy in HP > computing. It's been a privilege to be responsible for the collection and > the website and to see the value they bring to the vintage computing > community. > > David Collins > > > -- Lee Courtney +1-650-704-3934 cell --===============0149097682810318795==-- From bkr@WildHareComputers.com Fri Nov 11 01:42:26 2022 From: Bruce Ray To: cctalk@classiccmp.org Subject: [cctalk] Nova and Eclipse Emulator beta release Date: Thu, 10 Nov 2022 18:47:11 -0700 Message-ID: <7ac9d291-233f-4b67-97af-c66715aea991@WildHareComputers.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8605729767505776241==" --===============8605729767505776241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wild Hare Computer Systems is pleased to announce the public beta release of its Data General Nova and Eclipse emulator. This emulator allows the full range of DG 16-bit Nova and Eclipse computer software to run on Microsoft Windows and Linux platforms, and will become a major part of Wild Hare's increased efforts to preserve Data General's significant contributions to computer history. The emulator combines portions of Wild Hare's commercial products with the SimH project structure to create a single emulator for the 16-bit Nova and Eclipse computers. The program supports a wide range of features, including: Processors: unmapped Nova, SuperNova, Nova 1200, Nova 800, Nova 2, Nova 3, Nova 4 mapped Nova 840 mapped Nova 3/D mapped Nova 4/X Eclipse S/130 Eclipse S/140 Eclipse S/150 Eclipse S/120 Eclipse Desktop Generation Model 20 and Model 30 Peripherals: TTI/TTO primary console (TeleType) input/output RTC real-time clock TTI1/TTO1 secondary console (TeleType) input/output PTR paper tape reader PTP paper tape punch PLT plotter LPT line printer MTA mag tape unit DSK fixed-head disks DKP moving head disks DEP Desktop Generation disks DZP popular "Zebra" moving head disks QTY 4060 "Quad" asynchronous multiplexers ALM 4255 Asynchronous Line Multiplexers Software: Operating Systems DOS Novas (first DOS written for Nova) URDOS RDOS for Novas and Eclipses (in unmapped mode) MRDOS RDOS for Mapped Nova 840 NRDOS RDOS for Mapped Nova 3/D and Nova 4/X ZRDOS RDOS for Mapped Eclipses MP/OS Nova 4 DG/RDOS Eclipses AOS Eclipses MP/AOS Eclipses Languages ASM (Assembler) MAC (Macro Assembler) ALGOL DG/L FORTRAN 4 FORTRAN 5 FORTRAN 77 Extended BASIC Business BASIC MP Pascal SP Pascal COBOL Interactive COBOL (ICOBOL) PL/1 RPG II IDEA INFOS II CEO Prior Data General knowledge is beneficial to using the emulator and corresponding DG software. For convenience, Wild Hare has created container files of pre-configured operating system environments and their corresponding languages to minimize the time needed to enjoy the full DG "experience". This "beta-level" software release is intended to gather user feedback to help guide future product development. Bug reports, comments, suggestions, ridicule and giggles can be sent to beta(a)WildHareComputers.com. Further information is contained in the emulator beta release web page: www.NovasAreForever.org/dgbeta Bruce Ray Wild Hare Computer Systems, Inc. Denver, Colorado USA bkr(a)WildHareComputers.com ...preserving the Data General legacy: www.NovasAreForever.org --===============8605729767505776241==-- From jay@toaster.com Fri Nov 11 15:58:22 2022 From: Jay Logue To: cctalk@classiccmp.org Subject: [cctalk] Re: Nova and Eclipse Emulator beta release Date: Fri, 11 Nov 2022 07:52:47 -0800 Message-ID: In-Reply-To: <7ac9d291-233f-4b67-97af-c66715aea991@WildHareComputers.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1810151990207432333==" --===============1810151990207432333== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thanks for doing this!  I do have a few questions regarding emulator software: - You mention that the emulator combines "the SimH project structure" with Wild Hare's commercial code.  I take this to mean that the emulator is an extension of simh to support the listed DG processors and devices.  Can you clarify which version (and ideally commit id) of simh is this based on? - I noticed that the license document available on the dgbeta page only covers the legacy software produced by DG.  Given the inclusion of commercial code in the simh executables, can you clarify what license the emulator binaries are released under? (Ideally this would be published along side the legacy license text). - Do you envision at some point publishing the simh emulator changes as a pull request to the simh project (presumably under the simh license)? Again, thank you for your efforts here.  It's great to see this software opened up to hobbyist use. --Jay On 11/10/2022 5:47 PM, Bruce Ray via cctalk wrote: > > Wild Hare Computer Systems is pleased to announce the public beta > release of its Data General Nova and Eclipse emulator. > > This emulator allows the full range of DG 16-bit Nova and Eclipse > computer software to run on Microsoft Windows and Linux platforms, and > will become a major part of Wild Hare's increased efforts to preserve > Data General's significant contributions to computer history. > > The emulator combines portions of Wild Hare's commercial products with > the SimH project structure to create a single emulator for the 16-bit > Nova and Eclipse computers.  The program supports a wide range of > features, including: > > Processors: > >     unmapped Nova, SuperNova, Nova 1200, Nova 800, Nova 2, Nova 3, Nova 4 >     mapped Nova 840 >     mapped Nova 3/D >     mapped Nova 4/X >     Eclipse S/130 >     Eclipse S/140 >     Eclipse S/150 >     Eclipse S/120 >     Eclipse Desktop Generation Model 20 and Model 30 > > > Peripherals: > >     TTI/TTO        primary console (TeleType) input/output >     RTC        real-time clock >     TTI1/TTO1    secondary console (TeleType) input/output >     PTR        paper tape reader >     PTP        paper tape punch >     PLT        plotter >     LPT        line printer >     MTA        mag tape unit >     DSK        fixed-head disks >     DKP        moving head disks >     DEP        Desktop Generation disks >     DZP        popular "Zebra" moving head disks >     QTY        4060 "Quad" asynchronous multiplexers >     ALM        4255 Asynchronous Line Multiplexers > > > Software: > >     Operating Systems > >     DOS        Novas (first DOS written for Nova) >     URDOS        RDOS for Novas and Eclipses (in unmapped mode) >     MRDOS        RDOS for Mapped Nova 840 >     NRDOS        RDOS for Mapped Nova 3/D and Nova 4/X >     ZRDOS        RDOS for Mapped Eclipses >     MP/OS        Nova 4 >     DG/RDOS        Eclipses >     AOS        Eclipses >     MP/AOS        Eclipses > >     Languages > >     ASM (Assembler) >     MAC (Macro Assembler) >     ALGOL >     DG/L >     FORTRAN 4 >     FORTRAN 5 >     FORTRAN 77 >     Extended BASIC >     Business BASIC >     MP Pascal >     SP Pascal >     COBOL >     Interactive COBOL (ICOBOL) >     PL/1 >     RPG II >     IDEA >     INFOS II >     CEO > > Prior Data General knowledge is beneficial to using the emulator and > corresponding DG software.  For convenience, Wild Hare has created > container files of pre-configured operating system environments and > their corresponding languages to minimize the time needed to enjoy the > full DG "experience". > > This "beta-level" software release is intended to gather user feedback > to help guide future product development.  Bug reports, comments, > suggestions, ridicule and giggles can be sent to > beta(a)WildHareComputers.com. > > Further information is contained in the emulator beta release web page: > > www.NovasAreForever.org/dgbeta > > > > Bruce Ray > Wild Hare Computer Systems, Inc. > Denver, Colorado USA > bkr(a)WildHareComputers.com > > ...preserving the Data General legacy: www.NovasAreForever.org --===============1810151990207432333==-- From hi@senzilla.io Fri Nov 11 20:20:31 2022 From: "D. Olsson" To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking a Sun monitor with 13W3 interface Date: Fri, 11 Nov 2022 21:19:59 +0100 Message-ID: <4561A685-4E82-4140-AADB-E69D29A066F2@senzilla.io> In-Reply-To: <01SK3HUJ9NXG8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8425581666704149206==" --===============8425581666704149206== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, I really appreciate the reply! What an amazing community and mailing list her= e for keeping retro computing alive! > I have a GDM1604B40 monitor (Sony Trinitron design) with a 13W3 connector. > I don't know if it works or not. I'm glad to hear there still are some out there! :)=20 > It is missing the on/off switch which I > borrowed to repair my DEC VR297. Not ideal that it's missing the on/off switch. But it does sounds like it was= worth it for saving a DEC VR297 :) Good one! > It is located on the east coast of Ireland on the EU side of the border. > It weighs about 28kg. I'm located in France. So Ireland isn't the ideal location from here :) But I= 've made a note and will reach out again unless I find a whole/complete monit= or within driving distance from France :) Thanks again! Best regards, DO. --===============8425581666704149206==-- From w2hx@w2hx.com Fri Nov 11 21:16:52 2022 From: W2HX To: cctalk@classiccmp.org Subject: [cctalk] Inline Serial Device? Date: Fri, 11 Nov 2022 21:16:26 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2497549582605565647==" --===============2497549582605565647== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello all, I am looking for a device that sits transparently in an RS-232 serial line an= d upon seeing a particular code go over the serial line ((or sequence of code= s) will actual a relay (or a transistor). Something with two DB25s or DE9s an= d is configurable to what code will trigger the output? Some kind of box? Does anyone know of such a thing? I guess it could be cobbled up with a micro= controller, but hoping to just get something "off the shelf." Thank you 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx --===============2497549582605565647==-- From billdegnan@gmail.com Fri Nov 11 21:24:32 2022 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 16:24:02 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB5269A431002E2BF0F8A694F2B5009=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7255995159150499378==" --===============7255995159150499378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit not that it's easy but a raspberry pi could be set up to watch the serial line. On Fri, Nov 11, 2022 at 4:16 PM W2HX via cctalk wrote: > Hello all, > > I am looking for a device that sits transparently in an RS-232 serial line > and upon seeing a particular code go over the serial line ((or sequence of > codes) will actual a relay (or a transistor). Something with two DB25s or > DE9s and is configurable to what code will trigger the output? Some kind of > box? > > Does anyone know of such a thing? I guess it could be cobbled up with a > microcontroller, but hoping to just get something "off the shelf." > Thank you > > 73 Eugene W2HX > Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx > > > > > --===============7255995159150499378==-- From g4ajq1@gmail.com Fri Nov 11 21:29:33 2022 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 16:29:13 -0500 Message-ID: <9d1098be-ee80-762d-132b-890cf2540425@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2728498761816370042==" --===============2728498761816370042== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Or even cheaper, and Arduino uno cheers, Nigel Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 On 2022-11-11 16:24, Bill Degnan via cctalk wrote: > not that it's easy but a raspberry pi could be set up to watch the serial > line. > > On Fri, Nov 11, 2022 at 4:16 PM W2HX via cctalk > wrote: > >> Hello all, >> >> I am looking for a device that sits transparently in an RS-232 serial line >> and upon seeing a particular code go over the serial line ((or sequence of >> codes) will actual a relay (or a transistor). Something with two DB25s or >> DE9s and is configurable to what code will trigger the output? Some kind of >> box? >> >> Does anyone know of such a thing? I guess it could be cobbled up with a >> microcontroller, but hoping to just get something "off the shelf." >> Thank you >> >> 73 Eugene W2HX >> Subscribe to my Youtube Channel:https://www.youtube.com/@w2hx >> >> >> >> >> --===============2728498761816370042==-- From cisin@xenosoft.com Fri Nov 11 21:38:32 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 13:38:14 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB5269A431002E2BF0F8A694F2B5009=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9047182735582544001==" --===============9047182735582544001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Something quite similar, . . . (probably a hassle to switch over) I had a=20 KVM switch, that permitted two computers to share one keyboard mouse,=20 monitor, and speakers. DE15, two USB ports and a headphone jack (IOGear=20 GCS632U?) It apparently watched for a hotkey from the keyboard to=20 activate switching. I replaced it with one that had a physical pushbutton for switching (would=20 have preferred a DT switch, with visible positions, so that you know which=20 one is selected, not bouncing back and forth until it's what you want) On Fri, 11 Nov 2022, W2HX via cctalk wrote: > Hello all, > > I am looking for a device that sits transparently in an RS-232 serial line = and upon seeing a particular code go over the serial line ((or sequence of co= des) will actual a relay (or a transistor). Something with two DB25s or DE9s = and is configurable to what code will trigger the output? Some kind of box? > > Does anyone know of such a thing? I guess it could be cobbled up with a mic= rocontroller, but hoping to just get something "off the shelf." > Thank you > > 73 Eugene W2HX > Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx --===============9047182735582544001==-- From paulkoning@comcast.net Fri Nov 11 21:40:14 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 16:39:25 -0500 Message-ID: In-Reply-To: <9d1098be-ee80-762d-132b-890cf2540425@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1182716913833365954==" --===============1182716913833365954== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Perhaps cheaper still, a Raspberry Pico. Those go for $4, which even for the= smaller Arduinos is hard to beat. paul > On Nov 11, 2022, at 4:29 PM, Nigel Johnson Ham via cctalk wrote: >=20 > Or even cheaper, and Arduino uno >=20 > cheers, >=20 > Nigel >=20 >=20 > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU > Amateur Radio, the origin of the open-source concept! > Skype: TILBURY2591 >=20 >=20 > On 2022-11-11 16:24, Bill Degnan via cctalk wrote: >> not that it's easy but a raspberry pi could be set up to watch the serial >> line. >>=20 >> On Fri, Nov 11, 2022 at 4:16 PM W2HX via cctalk >> wrote: >>=20 >>> Hello all, >>>=20 >>> I am looking for a device that sits transparently in an RS-232 serial line >>> and upon seeing a particular code go over the serial line ((or sequence of >>> codes) will actual a relay (or a transistor). Something with two DB25s or >>> DE9s and is configurable to what code will trigger the output? Some kind = of >>> box? >>>=20 >>> Does anyone know of such a thing? I guess it could be cobbled up with a >>> microcontroller, but hoping to just get something "off the shelf." >>> Thank you >>>=20 >>> 73 Eugene W2HX >>> Subscribe to my Youtube Channel:https://www.youtube.com/@w2hx >>>=20 >>>=20 >>>=20 >>>=20 --===============1182716913833365954==-- From cisin@xenosoft.com Fri Nov 11 21:40:29 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 13:39:55 -0800 Message-ID: In-Reply-To: <9d1098be-ee80-762d-132b-890cf2540425@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3919362346007807553==" --===============3919362346007807553== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Or even cheaper, a dumpstered/e-waste PC On Fri, 11 Nov 2022, Nigel Johnson Ham via cctalk wrote: > Or even cheaper, and Arduino uno > > cheers, > > Nigel > > > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU > Amateur Radio, the origin of the open-source concept! > Skype: TILBURY2591 > > > On 2022-11-11 16:24, Bill Degnan via cctalk wrote: >> not that it's easy but a raspberry pi could be set up to watch the serial >> line. >> >> On Fri, Nov 11, 2022 at 4:16 PM W2HX via cctalk >> wrote: >> >>> Hello all, >>> >>> I am looking for a device that sits transparently in an RS-232 serial line >>> and upon seeing a particular code go over the serial line ((or sequence of >>> codes) will actual a relay (or a transistor). Something with two DB25s or >>> DE9s and is configurable to what code will trigger the output? Some kind >>> of >>> box? >>> >>> Does anyone know of such a thing? I guess it could be cobbled up with a >>> microcontroller, but hoping to just get something "off the shelf." >>> Thank you >>> >>> 73 Eugene W2HX >>> Subscribe to my Youtube Channel:https://www.youtube.com/@w2hx --===============3919362346007807553==-- From cclist@sydex.com Fri Nov 11 21:52:42 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 13:52:13 -0800 Message-ID: In-Reply-To: <9d1098be-ee80-762d-132b-890cf2540425@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0721364721647147275==" --===============0721364721647147275== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I suspect that a cheap minimal MCU could not only do the job, but do it by scavenging power from the RS232 signal lines (like old serial mice did). It's really surprising how miserly these things can be with power requirements nowadays. I keep a big jar around that's full of blue- and black pill MCU boards, as well as a few of the more capable STM32F4 and F7 boards. Nowadays, everything seems to look like a job for an MCU. I recall that a couple of years ago, either ED or EDN had an open question about whether it was preferable to replace NE555s with small MCUs--the parts price between the two being negligible. --Chuck --===============0721364721647147275==-- From wayne.sudol@hotmail.com Fri Nov 11 21:53:13 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 21:52:50 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9109147926069467147==" --===============9109147926069467147== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Black box may have something. They had something similar where you could call= in via phone and activate a switch to reboot a computer. Sent from my iPhone > On Nov 11, 2022, at 13:40, Fred Cisin via cctalk = wrote: >=20 > =EF=BB=BFOr even cheaper, a dumpstered/e-waste PC >=20 >> On Fri, 11 Nov 2022, Nigel Johnson Ham via cctalk wrote: >>=20 >> Or even cheaper, and Arduino uno >>=20 >> cheers, >>=20 >> Nigel >>=20 >>=20 >> Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU >> Amateur Radio, the origin of the open-source concept! >> Skype: TILBURY2591 >>=20 >>=20 >>> On 2022-11-11 16:24, Bill Degnan via cctalk wrote: >>> not that it's easy but a raspberry pi could be set up to watch the serial >>> line. >>> On Fri, Nov 11, 2022 at 4:16 PM W2HX via cctalk >>> wrote: >>>> Hello all, >>>> I am looking for a device that sits transparently in an RS-232 serial li= ne >>>> and upon seeing a particular code go over the serial line ((or sequence = of >>>> codes) will actual a relay (or a transistor). Something with two DB25s or >>>> DE9s and is configurable to what code will trigger the output? Some kind= of >>>> box? >>>> Does anyone know of such a thing? I guess it could be cobbled up with a >>>> microcontroller, but hoping to just get something "off the shelf." >>>> Thank you >>>> 73 Eugene W2HX >>>> Subscribe to my Youtube Channel:https://www.youtube.com/@w2hx --===============9109147926069467147==-- From cisin@xenosoft.com Fri Nov 11 22:00:42 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 14:00:20 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8007288149409210780==" --===============8007288149409210780== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 11 Nov 2022, Chuck Guzis via cctalk wrote: > I keep a big jar around that's full of blue- and black pill MCU boards, > as well as a few of the more capable STM32F4 and F7 boards. Nowadays, > everything seems to look like a job for an MCU. The MCU has replaced the hammer! . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs), everything looks like a NAIL|(job for an MCU)" --===============8007288149409210780==-- From wayne.sudol@hotmail.com Fri Nov 11 22:08:11 2022 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 22:07:47 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6989109956543919989==" --===============6989109956543919989== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Something like this=E2=80=A6 https://www.ebay.com/itm/Black-Box-Corporation-Modified-SWED98174-Cos-II-Code= -Operated-Serial-Switcher-/165759564735?mkcid=3D16&mkevt=3D1&_trksid=3Dp23496= 24.m46890.l49286&mkrid=3D711-127632-2357-0 Sent from my iPhone On Nov 11, 2022, at 14:00, Fred Cisin via cctalk wr= ote: =EF=BB=BFOn Fri, 11 Nov 2022, Chuck Guzis via cctalk wrote: I keep a big jar around that's full of blue- and black pill MCU boards, as well as a few of the more capable STM32F4 and F7 boards. Nowadays, everything seems to look like a job for an MCU. The MCU has replaced the hammer! . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs), everythi= ng looks like a NAIL|(job for an MCU)" --===============6989109956543919989==-- From cclist@sydex.com Fri Nov 11 22:10:33 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 14:10:04 -0800 Message-ID: <329f5e60-1b2a-8e5b-a3c0-d55e4edd6bed@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8075432559427226187==" --===============8075432559427226187== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/11/22 14:00, Fred Cisin via cctalk wrote: > On Fri, 11 Nov 2022, Chuck Guzis via cctalk wrote: >> I keep a big jar around that's full of blue- and black pill MCU boards, >> as well as a few of the more capable STM32F4 and F7 boards.    Nowadays, >> everything seems to look like a job for an MCU. > > > The MCU has replaced the hammer! > . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs), > everything looks like a NAIL|(job for an MCU)" Probably true--there are commodity light bulbs and flashlights with MCUs in them. The price of the Chinese OTP ones has dropped to a few cents--less than a package of chewing gum. "Silicon is cheap" is the motto of our times. --Chuck --===============8075432559427226187==-- From w2hx@w2hx.com Fri Nov 11 22:14:27 2022 From: W2HX To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 22:14:04 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21816D566343F9C960B86BA9E4009=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6740533931357348441==" --===============6740533931357348441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks to everyone who responded. And thanks to Wayne for the black box sugge= stion. I have actually been thinking about that very product. What it does is= switch a master port to one of several other ports. Not far from what I'm se= eking. I was thinking of buying one of these and hacking it to trigger a rela= y instead of a change of port. But before I went down that path, I thought I'= d ask if anyone knew something more fit for purpose. Seems not and either thi= s black box unit with a hack or a mcu might be my options. Thanks all! 73 Eugene W2HX Subscribe to my Youtube Channel:=C2=A0https://www.youtube.com/@w2hx -----Original Message----- From: Wayne S via cctalk =20 Sent: Friday, November 11, 2022 5:08 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Wayne S Subject: [cctalk] Re: Inline Serial Device? Something like this=E2=80=A6 https://www.ebay.com/itm/Black-Box-Corporation-Modified-SWED98174-Cos-II-Code= -Operated-Serial-Switcher-/165759564735?mkcid=3D16&mkevt=3D1&_trksid=3Dp23496= 24.m46890.l49286&mkrid=3D711-127632-2357-0 Sent from my iPhone On Nov 11, 2022, at 14:00, Fred Cisin via cctalk wr= ote: =EF=BB=BFOn Fri, 11 Nov 2022, Chuck Guzis via cctalk wrote: I keep a big jar around that's full of blue- and black pill MCU boards, as well as a few of the more capable STM32F4 and F7 boards. Nowadays, everything seems to look like a job for an MCU. The MCU has replaced the hammer! . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs), everythi= ng looks like a NAIL|(job for an MCU)" --===============6740533931357348441==-- From bill.gunshannon@hotmail.com Fri Nov 11 22:37:16 2022 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 17:36:48 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5383088169014551259==" --===============5383088169014551259== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/11/22 16:24, Bill Degnan via cctalk wrote: > not that it's easy but a raspberry pi could be set up to watch the serial > line. Probably overkill. I think it could be done with an arduino. bill --===============5383088169014551259==-- From bill.gunshannon@hotmail.com Fri Nov 11 22:47:20 2022 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 17:46:47 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181B8928FDA0201F794F1F3E4009=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1344876907602361922==" --===============1344876907602361922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/11/22 16:52, Wayne S via cctalk wrote: > Black box may have something. They had something similar where you could ca= ll in via phone and activate a switch to reboot a computer. >=20 If they do it probably costs about $500. Blackbox is not the company they used to be. (From someone who still has a lot of things floating around here from them like short haul modems!!) bill --===============1344876907602361922==-- From bill.gunshannon@hotmail.com Fri Nov 11 22:52:09 2022 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 17:51:46 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21816D566343F9C960B86BA9E4009=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3816033561570379586==" --===============3816033561570379586== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/11/22 17:07, Wayne S via cctalk wrote: > Something like this=E2=80=A6 >=20 > https://www.ebay.com/itm/Black-Box-Corporation-Modified-SWED98174-Cos-II-Co= de-Operated-Serial-Switcher-/165759564735?mkcid=3D16&mkevt=3D1&_trksid=3Dp234= 9624.m46890.l49286&mkrid=3D711-127632-2357-0 >=20 Looks like some kind of serial port switcher. Not really what W2HX was looking for. bill --===============3816033561570379586==-- From spectre@floodgap.com Sat Nov 12 02:06:57 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Fri, 11 Nov 2022 18:06:35 -0800 Message-ID: <1be1cb47-5304-6556-7bc0-5eccdd765e3c@floodgap.com> In-Reply-To: <9d1098be-ee80-762d-132b-890cf2540425@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3060401625361530375==" --===============3060401625361530375== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>> I am looking for a device that sits transparently in an RS-232 serial line >>> and upon seeing a particular code go over the serial line ((or sequence of >>> codes) will actual a relay (or a transistor). Something with two DB25s or >>> DE9s and is configurable to what code will trigger the output? Some kind = of >>> box? >> >> not that it's easy but a raspberry pi could be set up to watch the serial >> line. > > Or even cheaper, and Arduino uno I second the Arduino recommendation. I have a Power Mac G4 with a serial dong= le that drives an Arduino Nano-based IR blaster. It sends serial commands to it and the blaster transmits a signal to the room air conditioner. Should be easy to adapt the GPIO pins to a relay. Arduino programming and interfacing is pretty straightforward. https://oldvcr.blogspot.com/2022/10/ir-controlling-new-air-conditioner-in.html --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- The more corrupt the state, the more numerous the laws. -- Tacitus -------= -- --===============3060401625361530375==-- From ard.p850ug1@gmail.com Sat Nov 12 10:24:44 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 10:24:13 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1459317004263905626==" --===============1459317004263905626== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Nov 11, 2022 at 9:24 PM Bill Degnan via cctalk wrote: > > not that it's easy but a raspberry pi could be set up to watch the serial > line. So you're suggesting that it takes more components to detect what character my computer has sent than there are in the rest of the computer? -tony --===============1459317004263905626==-- From ard.p850ug1@gmail.com Sat Nov 12 10:28:39 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 10:28:09 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7910968205735362393==" --===============7910968205735362393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Nov 11, 2022 at 10:00 PM Fred Cisin via cctalk wrote: > The MCU has replaced the hammer! > . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs), > everything looks like a NAIL|(job for an MCU)" I thought it was well-known that nothing can be designed without at least one microcontroller. The other day I saw a product with a flashing LED, the flash rate was set with a knob. Yes, a microcontroller with a pot connected to an analogue input and LED hung off an output port. This is the sort of thing I'd do with a couple of transistors or an NE555 depending on which turned up in the junk box first. $deity I hate modern electronics. -tony --===============7910968205735362393==-- From a.carlini@ntlworld.com Sat Nov 12 11:59:23 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 11:58:59 +0000 Message-ID: <72693d4a-3217-7e93-8e68-9d86cc197d56@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9041465178709101894==" --===============9041465178709101894== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/11/2022 10:28, Tony Duell via cctalk wrote: > I thought it was well-known that nothing can be designed without at > least one microcontroller. > > The other day I saw a product with a flashing LED, the flash rate was > set with a knob. Yes, a microcontroller with a pot connected to an > analogue input and LED hung off an output port. This is the sort of > thing I'd do with a couple of transistors or an NE555 depending on > which turned up in the junk box first. > > $deity I hate modern electronics. Surely a microcontroller is just a 555 with a few extra transistors? Another tool in the box, just that it happens to be very cheap. You should check out Usagi Electric on youtube: https://www.youtube.com/c/Nakazoto/videos, he's putting together a valve-based recreation  of 1-bit processor (the MC14500B). He makes his own PCBs too :-) Antonio -- Antonio Carlini antonio(a)acarlini.com --===============9041465178709101894==-- From ard.p850ug1@gmail.com Sat Nov 12 16:08:58 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 16:08:25 +0000 Message-ID: In-Reply-To: <72693d4a-3217-7e93-8e68-9d86cc197d56@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6582314408441094287==" --===============6582314408441094287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 12, 2022 at 11:59 AM Antonio Carlini via cctalk wrote: > > Surely a microcontroller is just a 555 with a few extra transistors? For suitable (large) values of 'few'? Actually I can think of many differences... Firstly, the full equivalent circuit of the 555 is in the datasheet. So I can predict how it should behave under all conditions (there are many things you can do with a 555 besides astables and monostables). I have never seen an equivalent circuit, or a gate level description of a microcontroller. All 555s are the same. If it fails I can replace it. Microcontrollers cease to be the same once they are prgrammed. If a microcontroller fails then I'm stuck. I won't be able to get the firmware I would argue that 555s are a lot more reliable than microcontrollers. And have a much longer life than the time to bitrot of most microcontroller flash memories It's a lot easier to test a 555 than it is to test a microcontroller. 555s do not have illegal internal states they can get into. Microcontrollers almost always do. Hence the need for watchdog timers which IMHO are a kludge, > Another tool in the box, just that it happens to be very cheap. Cheap != good They have their uses. But like many tools they can be misused and often are. -tony --===============6582314408441094287==-- From emu@e-bbes.com Sat Nov 12 17:16:30 2022 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 11:53:11 -0500 Message-ID: <6629c4c1-de9a-02bf-c1ef-366fd31770cd@e-bbes.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5466861006155493419==" --===============5466861006155493419== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2022-11-12 11:08, Tony Duell via cctalk wrote: > On Sat, Nov 12, 2022 at 11:59 AM Antonio Carlini via cctalk > wrote: >> >> Surely a microcontroller is just a 555 with a few extra transistors? > > For suitable (large) values of 'few'? > > Actually I can think of many differences... > > Firstly, the full equivalent circuit of the 555 is in the datasheet. > So I can predict how it should behave under all conditions (there are > many things you can do with a 555 besides astables and monostables). I > have never seen an equivalent circuit, or a gate level description of > a microcontroller. And if you like to "tune" your ne555, you can do it on your own: https://www.adafruit.com/product/1526 :) --===============5466861006155493419==-- From cclist@sydex.com Sat Nov 12 17:18:20 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 09:17:51 -0800 Message-ID: <1fca3130-4c27-d89b-e39f-11c88ae70835@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4950214691162808718==" --===============4950214691162808718== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/12/22 02:28, Tony Duell via cctalk wrote: > The other day I saw a product with a flashing LED, the flash rate was > set with a knob. Yes, a microcontroller with a pot connected to an > analogue input and LED hung off an output port. This is the sort of > thing I'd do with a couple of transistors or an NE555 depending on > which turned up in the junk box first. It's inevitable evolution--why fight it? Without that, we'd all be nematodes or bacteria. MCUs make a lot of very complex stuff simple. A tape controller that would have required a couple of large PCBs now can be put on a filing-card size pcb--and most of that is connectors. Almost anything electronic sold today has an MCU in it--even a lithium cell. One thing that a small MCU has over a 555 is that it can be programmed once and you can be assured of its frequency stability. No fooling with pots and caps to get the thing to work the way you'd like. Signal processing is fairly easy when a commodity MCU has a fast-enough ADC and lots of memory? You can write your own realtime FFT software for it with no problem. Why write a CRC calculation routine when there's dedicated hardware to do that? If anything, a modern medium-scale MCU can be so packed with peripherals and features that the reference manual outlining them can run to a couple thousand pages. Productions yields have drastically improved since Hans Kamenzind spun the 555. I'm sure that he would approve of MCUs, were he still alive. I'm certain you'd be tickled to see your beloved HP 9800 series box re-imagined in TO5 germanium point-contact transistors and relays. --Chuck --===============4950214691162808718==-- From abuse@cabal.org.uk Sat Nov 12 17:27:19 2022 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 18:26:56 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1969160731474184769==" --===============1969160731474184769== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Nov 12, 2022 at 10:28:09AM +0000, Tony Duell via cctalk wrote: [...] > The other day I saw a product with a flashing LED, the flash rate was set > with a knob. Yes, a microcontroller with a pot connected to an analogue > input and LED hung off an output port. This is the sort of thing I'd do > with a couple of transistors or an NE555 depending on which turned up in > the junk box first. Farnell Nederland is quoting me €1.06 (+21% VAT) for the cheapest brand of 555 in stock. Their search won't let me find the cheapest microcontroller without drilling down further, but an 8 pin AVR is €0.88. That's single item quantities in DIP packaging, as is typical for small home projects. The 555 will also need a capacitor for its RC timer circuit which is another few tens of cents. And that's why people use microcontrollers to blink LEDs. The MCU in the Pi Pico is also well under a euro if you buy a reel of 3,400 of them. That's probably a few too many for an average hobbyist :) --===============1969160731474184769==-- From ard.p850ug1@gmail.com Sat Nov 12 17:34:47 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 17:34:13 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4512324082328153018==" --===============4512324082328153018== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > Farnell Nederland is quoting me €1.06 (+21% VAT) for the cheapest brand of > 555 in stock. Their search won't let me find the cheapest microcontroller > without drilling down further, but an 8 pin AVR is €0.88. Just checked RS components which is the supplier I normally use. Assuming I want a through-hole DIP device (not surface mount), I can get a TI NE555 for 28.4p if I buy 50 at a time. That is not a large quantity even for a hobbyist. -tony --===============4512324082328153018==-- From anders.k.nelson@gmail.com Sat Nov 12 17:35:50 2022 From: Anders Nelson To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 12:35:17 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1659560675831100108==" --===============1659560675831100108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I can probably build firmware to this for you and assemble a list of OTS parts you can connect together in a day or two - what string do you want to trigger on? Parameters, 8N1? RTS/CTS? Voltage at RS-232 or TTL level? OTS parts cost maybe $30? Source: am firmware engineer at Peloton (and still employed, wheee). -- Anders Nelson On Sat, Nov 12, 2022 at 12:27 PM Peter Corlett via cctalk < cctalk(a)classiccmp.org> wrote: > On Sat, Nov 12, 2022 at 10:28:09AM +0000, Tony Duell via cctalk wrote: > [...] > > The other day I saw a product with a flashing LED, the flash rate was set > > with a knob. Yes, a microcontroller with a pot connected to an analogue > > input and LED hung off an output port. This is the sort of thing I'd do > > with a couple of transistors or an NE555 depending on which turned up in > > the junk box first. > > Farnell Nederland is quoting me €1.06 (+21% VAT) for the cheapest brand of > 555 in stock. Their search won't let me find the cheapest microcontroller > without drilling down further, but an 8 pin AVR is €0.88. That's single > item > quantities in DIP packaging, as is typical for small home projects. The 555 > will also need a capacitor for its RC timer circuit which is another few > tens of cents. And that's why people use microcontrollers to blink LEDs. > > The MCU in the Pi Pico is also well under a euro if you buy a reel of 3,400 > of them. That's probably a few too many for an average hobbyist :) > > --===============1659560675831100108==-- From ard.p850ug1@gmail.com Sat Nov 12 17:41:17 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 17:40:45 +0000 Message-ID: In-Reply-To: <1fca3130-4c27-d89b-e39f-11c88ae70835@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2099132487002178474==" --===============2099132487002178474== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 12, 2022 at 5:18 PM Chuck Guzis via cctalk wrote: > MCUs make a lot of very complex stuff simple. A tape controller that > would have required a couple of large PCBs now can be put on a > filing-card size pcb--and most of that is connectors. You've hit a raw nerve there. I've recently being doing battle with an old-ish tape controller board that has a microcontroller with internal ROM and 3 ASICs amongst other things on it. I'd much prefer a cardcage of boards containing simple components. I do not understand this desire to miniaturise everything. > Almost anything > electronic sold today has an MCU in it--even a lithium cell. And that is why I hate modern electronics and buy very little of it. > > One thing that a small MCU has over a 555 is that it can be programmed > once and you can be assured of its frequency stability. No fooling with > pots and caps to get the thing to work the way you'd like. Now wait a second. I've not come across a simple microcontroller with a crystal in the same package. If you're going to use an external crystal, then I can do that too, with a couple of divider ICs. If you use the internal clock option of the microcontroller, it can drift. If I use R's and C's on a 555 I can choose ones with the stability, temperature coefficient, etc that I need. > > I'm certain you'd be tickled to see your beloved HP 9800 series box > re-imagined in TO5 germanium point-contact transistors and relays. Isn't that called an HP9100.Much the same functionality as an HP9810, but discrete transistors. Some of them are germanium (albeit junction ones). And yes I do love it. -tony > --===============2099132487002178474==-- From ethan.dicks@gmail.com Sat Nov 12 17:42:08 2022 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 12:41:34 -0500 Message-ID: In-Reply-To: <1fca3130-4c27-d89b-e39f-11c88ae70835@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2436287429442518696==" --===============2436287429442518696== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 12, 2022 at 12:18 PM Chuck Guzis via cctalk wrote: > On 11/12/22 02:28, Tony Duell via cctalk wrote: > > ... This is the sort of > > thing I'd do with a couple of transistors or an NE555 depending on > > which turned up in the junk box first. > > One thing that a small MCU has over a 555 is that it can be programmed > once and you can be assured of its frequency stability. No fooling with > pots and caps to get the thing to work the way you'd like. Yes, that, plus since many products have a hardware team and a firmware/software team, the hardware can be designed to general requirements and sent out for manufacture while the software team has time to write the firmware (and make changes long after the hardware is set). One of the first times I encountered this was stripping some old emergency exit lights for parts c. 2008. The switching supply had an 8-pin PIC for the oscillator instead of a 555. Yes, a 555 could have done it, but the PIC didn't need any external components to set the frequency, components that can drift with age, and components that take up board space. Even if the 555 and MCU were identical in cost for the IC, the MCU was cheaper because of the smaller footprint. Additionally, the designers had some flexibility. To change the frequency with a 555 after manufacture is an expensive proposition. With an MCU, if it's flashable in-circuit (clip or possibly programming pads near/at the MCU), then one can change the behavior without melting any metal or purchasing components. While one may never need to change the frequency of a SMPSU oscillator after initial design, there are plenty of products where it's handy that the hardware guys can say "here's an output that can go from 1/10Hz to 20Khz - what do you want it to be?" and not worry about design limitations, just set the frequency in the firmware and it does that. You can build some generic hardware (X inputs, Y outputs with Z mA current drive) and fine tune things later, or have variations on what the inputs mean and not have to change the PCB. Yeah, the 555 is extremely simple and is well known and is fairly cheap, simple MCUs are simple (and cheap) even if they aren't 100% deterministic like a chip with 20-30 transistors. There's economic advantage in flexibility. -ethan --===============2436287429442518696==-- From cclist@sydex.com Sat Nov 12 18:05:46 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 10:05:22 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0974426120033127027==" --===============0974426120033127027== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/12/22 09:41, Ethan Dicks via cctalk wrote: > > Yeah, the 555 is extremely simple and is well known and is fairly > cheap, simple MCUs are simple (and cheap) even if they aren't 100% > deterministic like a chip with 20-30 transistors. There's economic > advantage in flexibility. There's also efficiency in mass-produced numbers. There are several Chinese MCUs that go for less than USD$0.10 in low quantities. I think the bottom end a couple of years ago was about USD$0.03. At that price point, you have to wonder if some of that isn't the packaging (tape reel) cost. There are far more MCUs made today than 555s, if that's any indication. And some of the newest ones feature neural net hardware (e.g. MAX78000). Do that with your 555s! I, for one, welcome our robot overlords. --Chuck --===============0974426120033127027==-- From anders.k.nelson@gmail.com Sat Nov 12 18:08:49 2022 From: Anders Nelson To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 13:08:19 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3834049868189052343==" --===============3834049868189052343== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I bet NN/AI would be helpful with data recovery - if we can model certain common failure modes with those old drive heads we could infer what the data should have been... -- Anders Nelson On Sat, Nov 12, 2022 at 1:05 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 11/12/22 09:41, Ethan Dicks via cctalk wrote: > > > > > Yeah, the 555 is extremely simple and is well known and is fairly > > cheap, simple MCUs are simple (and cheap) even if they aren't 100% > > deterministic like a chip with 20-30 transistors. There's economic > > advantage in flexibility. > > There's also efficiency in mass-produced numbers. There are several > Chinese MCUs that go for less than USD$0.10 in low quantities. I think > the bottom end a couple of years ago was about USD$0.03. At that price > point, you have to wonder if some of that isn't the packaging (tape > reel) cost. > > There are far more MCUs made today than 555s, if that's any indication. > > And some of the newest ones feature neural net hardware (e.g. MAX78000). > Do that with your 555s! > > I, for one, welcome our robot overlords. > > --Chuck > > > --===============3834049868189052343==-- From bfranchuk@jetnet.ab.ca Sat Nov 12 18:47:33 2022 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 11:47:11 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2389551792508699728==" --===============2389551792508699728== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2022-11-12 9:08 a.m., Tony Duell via cctalk wrote: > On Sat, Nov 12, 2022 at 11:59 AM Antonio Carlini via cctalk > wrote: >> >> Surely a microcontroller is just a 555 with a few extra transistors? > > For suitable (large) values of 'few'? > > Actually I can think of many differences... > > Firstly, the full equivalent circuit of the 555 is in the datasheet. > So I can predict how it should behave under all conditions (there are > many things you can do with a 555 besides astables and monostables). I > have never seen an equivalent circuit, or a gate level description of > a microcontroller. > > All 555s are the same. If it fails I can replace it. Microcontrollers > cease to be the same once they are prgrammed. If a microcontroller > fails then I'm stuck. I won't be able to get the firmware > > I would argue that 555s are a lot more reliable than microcontrollers. > And have a much longer life than the time to bitrot of most > microcontroller flash memories > > It's a lot easier to test a 555 than it is to test a microcontroller. > > 555s do not have illegal internal states they can get into. > Microcontrollers almost always do. Hence the need for watchdog timers > which IMHO are a kludge, > >> Another tool in the box, just that it happens to be very cheap. > > Cheap != good > > They have their uses. But like many tools they can be misused and often are. > > -tony They often now have huge development software now days, that may tie you to a specific computer platform. Pal's I am using for example, 16v8's require win-cupl and can't be adapted for original FORTRAN V software. Ben. --===============2389551792508699728==-- From bfranchuk@jetnet.ab.ca Sat Nov 12 19:00:04 2022 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 11:59:42 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1832737326405389512==" --===============1832737326405389512== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2022-11-12 11:05 a.m., Chuck Guzis via cctalk wrote: > On 11/12/22 09:41, Ethan Dicks via cctalk wrote: > >> >> Yeah, the 555 is extremely simple and is well known and is fairly >> cheap, simple MCUs are simple (and cheap) even if they aren't 100% >> deterministic like a chip with 20-30 transistors. There's economic >> advantage in flexibility. > > There's also efficiency in mass-produced numbers. There are several > Chinese MCUs that go for less than USD$0.10 in low quantities. I think > the bottom end a couple of years ago was about USD$0.03. At that price > point, you have to wonder if some of that isn't the packaging (tape > reel) cost. > > There are far more MCUs made today than 555s, if that's any indication. > > And some of the newest ones feature neural net hardware (e.g. MAX78000). > Do that with your 555s! > > I, for one, welcome our robot overlords. > > --Chuck > I do too, but don't welcome the market droids that make you upgrade all the time. I am putting a projection TV in the living room, and needed to use all this HDMI or wire less crap. What ever happened to 75 video and 150? ohm terminated audio. Ben. PS At least my new computer still has a COM port. --===============1832737326405389512==-- From cclist@sydex.com Sat Nov 12 19:34:09 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 11:33:44 -0800 Message-ID: <575b2cb3-2204-df1d-7850-141d66e9393a@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5135550175730553618==" --===============5135550175730553618== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/12/22 10:59, ben via cctalk wrote: > I do too, but don't welcome the market droids that make you upgrade all > the time. > I am putting a projection TV in the living room, and needed to use all > this HDMI or wire less crap. What ever happened to 75 video and 150? ohm > terminated audio. What's all this 75 ohm stuff? 300 ohm twinlead. And the separate UHF down-converter to feed your VHF teevee. I'm still trying to figure out how my TV broadcast preview never displays any of the commercial advertisements, but I have to watch them when they're fullscreen. It's a conspiracy, I tell you... Now, if you'll pardon me, I have to go to the telegraph office to send a TWX. --Chuck --===============5135550175730553618==-- From mhs.stein@gmail.com Sat Nov 12 19:53:47 2022 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 14:53:15 -0500 Message-ID: In-Reply-To: <1be1cb47-5304-6556-7bc0-5eccdd765e3c@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8669758860500699929==" --===============8669758860500699929== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A surprisingly complex project ;-) For another alternative, the ever prolific Geoff Graham and co. have developed an amazingly versatile BASIC interpreter for the Pi Pico: https://geoffg.net/picomite.html m On Fri, Nov 11, 2022 at 9:06 PM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org> wrote: > >>> I am looking for a device that sits transparently in an RS-232 serial > line > >>> and upon seeing a particular code go over the serial line ((or > sequence of > >>> codes) will actual a relay (or a transistor). Something with two DB25s > or > >>> DE9s and is configurable to what code will trigger the output? Some > kind of > >>> box? > >> > >> not that it's easy but a raspberry pi could be set up to watch the > serial > >> line. > > > > Or even cheaper, and Arduino uno > > I second the Arduino recommendation. I have a Power Mac G4 with a serial > dongle > that drives an Arduino Nano-based IR blaster. It sends serial commands to > it > and the blaster transmits a signal to the room air conditioner. Should be > easy > to adapt the GPIO pins to a relay. Arduino programming and interfacing is > pretty straightforward. > > > https://oldvcr.blogspot.com/2022/10/ir-controlling-new-air-conditioner-in.h= tml > > -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckaiser(a)floodgap.com > -- The more corrupt the state, the more numerous the laws. -- Tacitus > --------- > > --===============8669758860500699929==-- From bfranchuk@jetnet.ab.ca Sat Nov 12 19:56:54 2022 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 12:56:33 -0700 Message-ID: In-Reply-To: <575b2cb3-2204-df1d-7850-141d66e9393a@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0648257931784936392==" --===============0648257931784936392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2022-11-12 12:33 p.m., Chuck Guzis via cctalk wrote: > On 11/12/22 10:59, ben via cctalk wrote: > >> I do too, but don't welcome the market droids that make you upgrade all >> the time. >> I am putting a projection TV in the living room, and needed to use all >> this HDMI or wire less crap. What ever happened to 75 video and 150? ohm >> terminated audio. > > What's all this 75 ohm stuff? 300 ohm twinlead. And the separate UHF > down-converter to feed your VHF teevee. > > I'm still trying to figure out how my TV broadcast preview never > displays any of the commercial advertisements, but I have to watch them > when they're fullscreen. > > It's a conspiracy, I tell you... Now, if you'll pardon me, I have to go > to the telegraph office to send a TWX. > > --Chuck > Watch out for Indians. :) Ben. --===============0648257931784936392==-- From mhs.stein@gmail.com Sat Nov 12 20:10:00 2022 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 15:09:26 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB5269BF880663E84BD7B5E785B5009=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7532983983592644300==" --===============7532983983592644300== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Can the magic control codes pass through to the remote device or does the "black box" have to eat them? Makes quite a difference... m On Fri, Nov 11, 2022 at 5:14 PM W2HX via cctalk wrote: > Thanks to everyone who responded. And thanks to Wayne for the black box > suggestion. I have actually been thinking about that very product. What it > does is switch a master port to one of several other ports. Not far from > what I'm seeking. I was thinking of buying one of these and hacking it to > trigger a relay instead of a change of port. But before I went down that > path, I thought I'd ask if anyone knew something more fit for purpose. > Seems not and either this black box unit with a hack or a mcu might be my > options. > > Thanks all! > > > 73 Eugene W2HX > Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx > > -----Original Message----- > From: Wayne S via cctalk > Sent: Friday, November 11, 2022 5:08 PM > To: General Discussion: On-Topic and Off-Topic Posts < > cctalk(a)classiccmp.org> > Cc: Wayne S > Subject: [cctalk] Re: Inline Serial Device? > > Something like this=E2=80=A6 > > > https://www.ebay.com/itm/Black-Box-Corporation-Modified-SWED98174-Cos-II-Co= de-Operated-Serial-Switcher-/165759564735?mkcid=3D16&mkevt=3D1&_trksid=3Dp234= 9624.m46890.l49286&mkrid=3D711-127632-2357-0 > > > Sent from my iPhone > > On Nov 11, 2022, at 14:00, Fred Cisin via cctalk > wrote: > > =EF=BB=BFOn Fri, 11 Nov 2022, Chuck Guzis via cctalk wrote: > I keep a big jar around that's full of blue- and black pill MCU boards, > as well as a few of the more capable STM32F4 and F7 boards. Nowadays, > everything seems to look like a job for an MCU. > > > The MCU has replaced the hammer! > . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs), > everything looks like a NAIL|(job for an MCU)" > > > > --===============7532983983592644300==-- From w2hx@w2hx.com Sat Nov 12 20:27:11 2022 From: W2HX To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 20:26:41 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5571237836468890939==" --===============5571237836468890939== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Can the magic control codes pass through to the remote device or does the "= black box" have to eat them? According to a manual I found on the internet, it has three modes. One mode w= here the "arming" character and the subsequent port selection character are n= ot passed through, one where it does pass through and one where there must be= a (settable) delay between the arming and port selection characters. =20 I looked at a picture of the main board of one of these black box COS units (= code operated switch) and it appears there are two UARTS back to back. Betwe= en the UARTs where the data is parallel, there is an 8-bit comparator (74HCT6= 88E) that checks the data flowing to an 8 position dip switch that lets you = set the arming character. All sounds simple. But I must admit, if I were to b= uild something similar, I wouldn=E2=80=99t bother with two back to back uarts= , an MCU would certainly be the way to go. 73 Eugene W2HX Subscribe to my Youtube Channel:=C2=A0https://www.youtube.com/@w2hx -----Original Message----- From: Mike Stein via cctalk =20 Sent: Saturday, November 12, 2022 3:09 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Mike Stein Subject: [cctalk] Re: Inline Serial Device? Can the magic control codes pass through to the remote device or does the "bl= ack box" have to eat them? Makes quite a difference... m On Fri, Nov 11, 2022 at 5:14 PM W2HX via cctalk wrote: > Thanks to everyone who responded. And thanks to Wayne for the black=20 > box suggestion. I have actually been thinking about that very product.=20 > What it does is switch a master port to one of several other ports.=20 > Not far from what I'm seeking. I was thinking of buying one of these=20 > and hacking it to trigger a relay instead of a change of port. But=20 > before I went down that path, I thought I'd ask if anyone knew something mo= re fit for purpose. > Seems not and either this black box unit with a hack or a mcu might be=20 > my options. > > Thanks all! > > > 73 Eugene W2HX > Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx > > -----Original Message----- > From: Wayne S via cctalk > Sent: Friday, November 11, 2022 5:08 PM > To: General Discussion: On-Topic and Off-Topic Posts <=20 > cctalk(a)classiccmp.org> > Cc: Wayne S > Subject: [cctalk] Re: Inline Serial Device? > > Something like this=E2=80=A6 > > > https://www.ebay.com/itm/Black-Box-Corporation-Modified-SWED98174-Cos- > II-Code-Operated-Serial-Switcher-/165759564735?mkcid=3D16&mkevt=3D1&_trksi > d=3Dp2349624.m46890.l49286&mkrid=3D711-127632-2357-0 > > > Sent from my iPhone > > On Nov 11, 2022, at 14:00, Fred Cisin via cctalk=20 > > wrote: > > =EF=BB=BFOn Fri, 11 Nov 2022, Chuck Guzis via cctalk wrote: > I keep a big jar around that's full of blue- and black pill MCU boards, > as well as a few of the more capable STM32F4 and F7 boards. Nowadays, > everything seems to look like a job for an MCU. > > > The MCU has replaced the hammer! > . . . "To a man with a HAMMER|(big jar of blue and black pill MCUs),=20 > everything looks like a NAIL|(job for an MCU)" > > > > --===============5571237836468890939==-- From cclist@sydex.com Sat Nov 12 20:36:20 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 12:35:56 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6721913743673585851==" --===============6721913743673585851== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/12/22 11:56, ben via cctalk wrote: > On 2022-11-12 12:33 p.m., Chuck Guzis via cctalk wrote: > Watch out for Indians. :) > Ben. Nonsense--they have some very fine restaurants here. --Chuck --===============6721913743673585851==-- From mhs.stein@gmail.com Sat Nov 12 23:31:41 2022 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 18:31:09 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0317775894747041608==" --===============0317775894747041608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nice one! LOL! m On Sat, Nov 12, 2022 at 3:36 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 11/12/22 11:56, ben via cctalk wrote: > > On 2022-11-12 12:33 p.m., Chuck Guzis via cctalk wrote: > > > Watch out for Indians. :) > > Ben. > > Nonsense--they have some very fine restaurants here. > > --Chuck > > > --===============0317775894747041608==-- From glen.slick@gmail.com Sat Nov 12 23:41:50 2022 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 15:41:17 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5444630154789280481==" --===============5444630154789280481== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 12, 2022 at 12:36 PM Chuck Guzis via cctalk wrote: > > On 11/12/22 11:56, ben via cctalk wrote: > > On 2022-11-12 12:33 p.m., Chuck Guzis via cctalk wrote: > > > Watch out for Indians. :) > > Ben. > > Nonsense--they have some very fine restaurants here. > > --Chuck I went to an Endian restaurant once. I was disappointed. I wanted something little, but everything on the menu was big. --===============5444630154789280481==-- From gavin@learn.bio Sat Nov 12 23:55:10 2022 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 17:54:37 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CDM6PR06MB5580962E8CBB6118E3F8C0B2ED009=40DM6PR06MB?= =?utf-8?q?5580=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2017075879998196667==" --===============2017075879998196667== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Nov 11, 2022 at 4:46 PM Bill Gunshannon via cctalk wrote: > If they do it probably costs about $500. Blackbox is not the company > they used to be. That sounds like exactly the kind of company they used to be :P I just wanted to mention that back when we did POS systems, we had cash drawers that were operated off of an RS232 port not by looking at the data stream but simply by triggering off the DTR line. The drawer contained basically a capacitor and a solenoid. So if you have control over the serial port on the "commanding" end, that sort of thing can be an option for triggering physical devices. G. --===============2017075879998196667==-- From imp@bsdimp.com Sun Nov 13 00:41:51 2022 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 17:41:19 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2927467032033135956==" --===============2927467032033135956== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 12, 2022, 4:41 PM Glen Slick via cctalk wrote: > On Sat, Nov 12, 2022 at 12:36 PM Chuck Guzis via cctalk > wrote: > > > > On 11/12/22 11:56, ben via cctalk wrote: > > > On 2022-11-12 12:33 p.m., Chuck Guzis via cctalk wrote: > > > > > Watch out for Indians. :) > > > Ben. > > > > Nonsense--they have some very fine restaurants here. > > > > --Chuck > > I went to an Endian restaurant once. I was disappointed. I wanted > something little, but everything on the menu was big. > I'm never quite sure which way to read the menu there, but the food is good. Warner > --===============2927467032033135956==-- From sellam.ismail@gmail.com Sun Nov 13 01:23:49 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 17:23:12 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3613489273643474152==" --===============3613489273643474152== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I recommend the DEADBEEF dish. Sellam On Sat, Nov 12, 2022 at 4:41 PM Warner Losh via cctalk < cctalk(a)classiccmp.org> wrote: > On Sat, Nov 12, 2022, 4:41 PM Glen Slick via cctalk > > wrote: > > > On Sat, Nov 12, 2022 at 12:36 PM Chuck Guzis via cctalk > > wrote: > > > > > > On 11/12/22 11:56, ben via cctalk wrote: > > > > On 2022-11-12 12:33 p.m., Chuck Guzis via cctalk wrote: > > > > > > > Watch out for Indians. :) > > > > Ben. > > > > > > Nonsense--they have some very fine restaurants here. > > > > > > --Chuck > > > > I went to an Endian restaurant once. I was disappointed. I wanted > > something little, but everything on the menu was big. > > > > I'm never quite sure which way to read the menu there, but the food is > good. > > Warner > > > > --===============3613489273643474152==-- From cclist@sydex.com Sun Nov 13 02:46:35 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 18:46:12 -0800 Message-ID: <50d00699-5ff4-60f6-f7b7-383af246f49f@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1430179707818160691==" --===============1430179707818160691== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/12/22 15:41, Glen Slick via cctalk wrote: > I went to an Endian restaurant once. I was disappointed. I wanted > something little, but everything on the menu was big. In one, dessert comes first and finishes with salad. --===============1430179707818160691==-- From ethan.dicks@gmail.com Sun Nov 13 02:53:05 2022 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 21:52:29 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0514890528228935717==" --===============0514890528228935717== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 12, 2022 at 8:23 PM Sellam Abraham via cctalk wrote: > I recommend the DEADBEEF dish. FEED FACE DEAD BEEF -ethan --===============0514890528228935717==-- From cclist@sydex.com Sun Nov 13 04:02:49 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sat, 12 Nov 2022 20:02:22 -0800 Message-ID: <0b4cd80d-07d9-b579-0d07-dae7f5f627d8@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8436614650709161942==" --===============8436614650709161942== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/12/22 17:23, Sellam Abraham via cctalk wrote: > I recommend the DEADBEEF dish. Are you certain that you don't mean EFBEADDE? On the STAR, DEADBEEF was the dead code for a call to page and un-pageable (i.e. kernel resident) page. There were other DEAD codes, such as DEADCACA, etc. All of which caused the system to throw up its hands and die. Looks cool in a dump with 64 bit words. --Chuck] --===============8436614650709161942==-- From lewissa78@gmail.com Sun Nov 13 06:14:18 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 00:13:45 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5982828572646605807==" --===============5982828572646605807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I've been looking for a video or image that shows what font the original Datapoint 2200 used. It's not shown in the manual. There is one vintage image with the office lady and the DP2200 on the desk- but the font isn't very clear in that. In any modern video about the DP2200, none of them seem to power it on -- which is certainly understandable. From what I've read, the power supply of that system is prone to failure. Also, the system is hard-coded to load from Tape 1 -- which means both the tape drive, and tape media, still needs to be in good working order (which would be pretty rare after this time). In "the" DP2200 book, it only briefly mentions that the original tape software was developed "on an HP system" (without any elaboration that I could tell on which HP system that was). Nothing in the manual suggests the original DP2200 could "program itself" (i.e. no built in machine code monitor -- those TTL chips had one strict boot up sequence: load from tape 1). If there was a read error or no tape available, I'm curious if any message showed on the CRT. So, I was just wondering if there was any known pre-1973 Datapoint 2200's that are still working? (and/or if any HD video of them powered on and legible font can be seen) Or any other more current system that we know for sure used the same font? Thanks! -Steve --===============5982828572646605807==-- From jos.dreesen@greenmail.ch Sun Nov 13 09:45:24 2022 From: jos To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 10:44:57 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6590740157750291154==" --===============6590740157750291154== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 13.11.22 07:13, Steve Lewis via cctalk wrote: > I've been looking for a video or image that shows what font the original > Datapoint 2200 used. > > It's not shown in the manual. There is one vintage image with the office > lady and the DP2200 on the desk- but the font isn't very clear in that. > > In any modern video about the DP2200, none of them seem to power it on -- > which is certainly understandable. From what I've read, the power supply > of that system is prone to failure. Also, the system is hard-coded to load > from Tape 1 -- which means both the tape drive, and tape media, still needs > to be in good working order (which would be pretty rare after this time). > > In "the" DP2200 book, it only briefly mentions that the original tape > software was developed "on an HP system" (without any elaboration that I > could tell on which HP system that was). > > Nothing in the manual suggests the original DP2200 could "program itself" > (i.e. no built in machine code monitor -- those TTL chips had one strict > boot up sequence: load from tape 1). If there was a read error or no tape > available, I'm curious if any message showed on the CRT. > > So, I was just wondering if there was any known pre-1973 Datapoint 2200's > that are still working? (and/or if any HD video of them powered on and > legible font can be seen) Or any other more current system that we know > for sure used the same font? > > Thanks! > -Steve Not only=C2=A0 is the powersupply prone to failure, it is also the most dange= rous I have ever seen, and I am hesitant on working it. Primary and secondary= sides not separated,=C2=A0 isolation between the two almost nonexistant, man= y primary nodes exposed. Would never pass modern safety checks. But here is a picture of my DP1100, a DP2200 derivative, while it was running= a memory selftest, for a short time in 2021, before the powersupply blew aga= in : https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.12= 22197/#post-1222197 While the DP2200 is hardcoded to start from tape, the DP1100, otherwise ident= ical, boots from a ROM. This ROM also contains a minimal machinecode monitor.= I recovered & disasembled the ROM and Gordon Peterson, from Datapoint, comme= nted it out : http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisasse= mblyGEP2.txt Note that there are multiple videoboard options : the later DP2200, my DP1100= , and the DP5500 share the same videoboard. This relies on a programmable cha= racterset. In the disassembly mentioned above above, starting at line 3660 yo= u will see a load of gobldecook, these are actually fondsets to be loaded int= o the machine. The fontset has a very particular "look" to it. How much is due to fontdefini= tion, and how much is due to the diddlescan, that I dont know. Diddlescan is = where they scan each character in full, before proceding to the next. Note that a=C2=A0 ROM based bootboard for a DP2200 would be a trivial underta= king,=C2=A0 and only involve changing the cassette reader board for the ROM b= oard. Jos --===============6590740157750291154==-- From cc@informatik.uni-stuttgart.de Sun Nov 13 09:49:56 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 10:49:32 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6564801486772975796==" --===============6564801486772975796== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 12 Nov 2022, Peter Corlett wrote: > Farnell Nederland is quoting me ?1.06 (+21% VAT) for the cheapest brand of A quick search reveals that a single NE555 costs 0.25 Euros at Reichelt, *including* VAT. I'm sure they can be had much much cheaper in quantities. Christian --===============6564801486772975796==-- From rdowns@radix.co.uk Sun Nov 13 09:54:34 2022 From: Robin Downs To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 09:54:12 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB5269A431002E2BF0F8A694F2B5009=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8284654495134098755==" --===============8284654495134098755== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi,=20 Actually, I built exactly this many years ago (1990s) to operate a cash draw = for dumb terminals on Unix systems, used on counters as point of sale devices= ... The existing solution used a processor, ram, rom, double sided board etc and = was too expensive, so I designed a replacement with a real UART and a finite = state machine consisting of a EPROM and 8 bit latch that simply monitored the= RS232 data passively and when the appropriate character sequence was matched= , it triggered the solenoid to open the cash draw. It decoded a long 14 character code sequence easily and reliably and used 5 c= hips in total on a smaller single sided board. Nowadays, a small microcontroller is the obvious way to go for cost and ease = of development. An easy way to implements is to use a small box to contain the two DB25 conne= ctors and simply tap into the receive data line and run a short cable to the = monitor circuit, probably built in and powered off what you want to operate... Regards, Robin Downs -----Original Message----- From: W2HX via cctalk =20 Sent: 11 November 2022 21:16 To: General Discussion: On-Topic and Off-Topic Posts Cc: W2HX Subject: [cctalk] Inline Serial Device?=20 Hello all, I am looking for a device that sits transparently in an RS-232 serial line an= d upon seeing a particular code go over the serial line ((or sequence of code= s) will actual a relay (or a transistor). Something with two DB25s or DE9s an= d is configurable to what code will trigger the output? Some kind of box? Does anyone know of such a thing? I guess it could be cobbled up with a micro= controller, but hoping to just get something "off the shelf." Thank you 73 Eugene W2HX Subscribe to my Youtube Channel: https://www.youtube.com/@w2hx --===============8284654495134098755==-- From ard.p850ug1@gmail.com Sun Nov 13 10:51:16 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 10:50:42 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CPR3PR01MB6860B9C8203DB47C3B356DA99D029=40PR3PR01MB?= =?utf-8?q?6860=2Eeurprd01=2Eprod=2Eexchangelabs=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5201817369295433830==" --===============5201817369295433830== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 13, 2022 at 9:54 AM Robin Downs via cctalk wrote: > > Hi, > Actually, I built exactly this many years ago (1990s) to operate a cash dra= w for dumb terminals on Unix systems, used on counters as point of sale devic= es... > > The existing solution used a processor, ram, rom, double sided board etc an= d was too expensive, so I designed a replacement with a real UART and a finit= e state machine consisting of a EPROM and 8 bit latch that simply monitored t= he RS232 data passively and when the appropriate character sequence was match= ed, it triggered the solenoid to open the cash draw. I am now thinking of totally crazy ways to detect a serial character. OK, a Model 33 Teletype with the right option in the stunt box is trivial. One odd idea is to detect the start bit and then generate the chracter bit-serially at the right baud rate. XOR that with the bitstream. Start with a flag ff set, at the middle of each bit-time, clear the flag if the bitstream and generated bit differ. At the end of the character time if the flag is still set, it's a match, Has the advantage of only needing a single-bit comparison not 7 or 8. > > It decoded a long 14 character code sequence easily and reliably and used 5= chips in total on a smaller single sided board. > > Nowadays, a small microcontroller is the obvious way to go for cost and eas= e of development. Cost, probably. Ease of development, it depends on who you are. I reckon I could solder up a suitable circuit using TTL only (i.e. not using a dumb UART which would simplify things a lot) in less time that it would take me to write the firmware. I am not a programmer. I tried the Arduino boards once and got fed up with a lack of proper printable documentation, no formal language specification, etc. -tony --===============5201817369295433830==-- From rich.bramante@gmail.com Sun Nov 13 14:12:16 2022 From: Rich Bramante To: cctalk@classiccmp.org Subject: [cctalk] NEC APC I / III available USA Massachusetts Date: Sat, 12 Nov 2022 16:11:13 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2547739543086519938==" --===============2547739543086519938== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I am downsizing. These have been in storage for quite some time. I am about 25 miles N of Boston, MA and S of Nashua NH. These are both extremely heavy so no interest in shipping. Unfortunately I do not have any software for either system. The I is fairly clean and the kb is effectively new-old-stock with the box. Possibly unused. Powers on, green mono, single drive. The III powers on but I can't get a cursor on video (there is a flash at power cycle). It has seen more use than the I (yellowing, case screws missing). Photos here: https://photos.app.goo.gl/6vbMnVZsZEkrpFGc8 e-mail if interested rich.bramante+cctech(a)gmail.com. Thank you. --===============2547739543086519938==-- From billdegnan@gmail.com Sun Nov 13 14:13:48 2022 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 09:13:15 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5574937575906890445==" --===============5574937575906890445== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I assume the Datapoint 3300 terminal's electronics beam characters to the crt differently. If they're the same, or close enough from the font perspective, I have a 3300 that works that could be used. Same goes for power supply, I have a spare of one of the 3300"s power supplies should it be used to modified to be used in a 2200. I.assume it's a long shot.. I did not look it up to see for sure. Anyone have a 3300 that needs a power supply? The 3300 has multiple power supplies, I have a working spare of the supply that attaches to the back behind the.crt. Bill On Sun, Nov 13, 2022, 4:45 AM jos via cctalk wrote: > On 13.11.22 07:13, Steve Lewis via cctalk wrote: > > I've been looking for a video or image that shows what font the original > > Datapoint 2200 used. > > > > It's not shown in the manual. There is one vintage image with the > office > > lady and the DP2200 on the desk- but the font isn't very clear in that. > > > > In any modern video about the DP2200, none of them seem to power it on -- > > which is certainly understandable. From what I've read, the power > supply > > of that system is prone to failure. Also, the system is hard-coded to > load > > from Tape 1 -- which means both the tape drive, and tape media, still > needs > > to be in good working order (which would be pretty rare after this time). > > > > In "the" DP2200 book, it only briefly mentions that the original tape > > software was developed "on an HP system" (without any elaboration that I > > could tell on which HP system that was). > > > > Nothing in the manual suggests the original DP2200 could "program itself" > > (i.e. no built in machine code monitor -- those TTL chips had one strict > > boot up sequence: load from tape 1). If there was a read error or no > tape > > available, I'm curious if any message showed on the CRT. > > > > So, I was just wondering if there was any known pre-1973 Datapoint 2200's > > that are still working? (and/or if any HD video of them powered on and > > legible font can be seen) Or any other more current system that we know > > for sure used the same font? > > > > Thanks! > > -Steve > > > Not only is the powersupply prone to failure, it is also the most > dangerous I have ever seen, and I am hesitant on working it. Primary and > secondary sides not separated, isolation between the two almost > nonexistant, many primary nodes exposed. Would never pass modern safety > checks. > > But here is a picture of my DP1100, a DP2200 derivative, while it was > running a memory selftest, for a short time in 2021, before the powersupply > blew again : > > > https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.= 1222197/#post-1222197 > > While the DP2200 is hardcoded to start from tape, the DP1100, otherwise > identical, boots from a ROM. This ROM also contains a minimal machinecode > monitor. I recovered & disasembled the ROM and Gordon Peterson, from > Datapoint, commented it out : > http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisassemblyGEP2.txt > > Note that there are multiple videoboard options : the later DP2200, my > DP1100, and the DP5500 share the same videoboard. This relies on a > programmable characterset. In the disassembly mentioned above above, > starting at line 3660 you will see a load of gobldecook, these are actually > fondsets to be loaded into the machine. > > The fontset has a very particular "look" to it. How much is due to > fontdefinition, and how much is due to the diddlescan, that I dont know. > Diddlescan is where they scan each character in full, before proceding to > the next. > > Note that a ROM based bootboard for a DP2200 would be a trivial > undertaking, and only involve changing the cassette reader board for the > ROM board. > > > Jos > > > --===============5574937575906890445==-- From paulkoning@comcast.net Sun Nov 13 15:10:17 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 10:09:52 -0500 Message-ID: <2AE6A513-0409-4934-8AC6-15DFF879AD1F@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4414901674459493207==" --===============4414901674459493207== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 12, 2022, at 1:08 PM, Anders Nelson via cctalk wrote: >=20 > I bet NN/AI would be helpful with data recovery - if we can model certain > common failure modes with those old drive heads we could infer what the > data should have been... NN maybe, I need to understand those better. I see they are now a building b= lock for OCR. AI, not so clear. In my view, AI is a catch-all term for "software whose pro= perties are unknown and probably unknowable". A computer, including one that= executes AI softwware, is a math processing engine, so in principle its beha= vior is fully defined by its design and by the software in it. But when you = do AI in which "learning" is part of the scheme, the resulting behavior is in= fact unknown and undefined. =20 For some applications that may be ok. OCR doesn't suffer materially from occ= asional random errors, since it has errors anyway from the nature of its inpu= t. But, for example, I shudder at the notion of AI in safety-critical applic= ations (like autopilots for aircraft, or worse yet for cars). A safety criti= cal application implemented in a manner that precludes the existence of a spe= cification is a fundanmentally insane notion. paul --===============4414901674459493207==-- From mjd.bishop@emeritus-solutions.com Sun Nov 13 15:59:31 2022 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 15:54:06 +0000 Message-ID: <124771ce9850456fad9380ba9829b235@WINHEXBEEU125.win.mail> In-Reply-To: <2AE6A513-0409-4934-8AC6-15DFF879AD1F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4684039105308591128==" --===============4684039105308591128== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable IMHO, AI is bull Martin -----Original Message----- From: Paul Koning via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 13 November 2022 15:10 To: cctalk(a)classiccmp.org Cc: Paul Koning Subject: [cctalk] Re: Inline Serial Device? > On Nov 12, 2022, at 1:08 PM, Anders Nelson via cctalk wrote: >=20 > I bet NN/AI would be helpful with data recovery - if we can model=20 > certain common failure modes with those old drive heads we could infer=20 > what the data should have been... NN maybe, I need to understand those better. I see they are now a building b= lock for OCR. AI, not so clear. In my view, AI is a catch-all term for "software whose pro= perties are unknown and probably unknowable". A computer, including one that= executes AI softwware, is a math processing engine, so in principle its beha= vior is fully defined by its design and by the software in it. But when you = do AI in which "learning" is part of the scheme, the resulting behavior is in= fact unknown and undefined. =20 For some applications that may be ok. OCR doesn't suffer materially from occ= asional random errors, since it has errors anyway from the nature of its inpu= t. But, for example, I shudder at the notion of AI in safety-critical applic= ations (like autopilots for aircraft, or worse yet for cars). A safety criti= cal application implemented in a manner that precludes the existence of a spe= cification is a fundanmentally insane notion. paul --===============4684039105308591128==-- From robert.jarratt@ntlworld.com Sun Nov 13 18:47:21 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Modern Replacement for H7140 in PDP 11/24 Date: Sun, 13 Nov 2022 18:36:24 +0000 Message-ID: <012901d8f78e$d5b73500$81259f00$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6448622218090480244==" --===============6448622218090480244== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Given all the troubles I have had with the H7140 in my PDP 11/24 I am considering whether to replace it with modern equivalents, installed inside the H7140 enclosure. I am a bit puzzled by the specs listed in the PDP 11/24 Maintenance Card, it suggests the PSU outputs +12V and -12V from the memory inverter/memory regulator, but the specs for the cards don't mention 12V so I don't know if I need 12V from the PSU. My memory board is an M8722-BC (MS11-MB). I can't find a manual or printset for this memory, so I am not sure what voltages it will need, although I suspect it only needs +5V, +15V and -15V. Is that right? I know I will also have to replace the fans, because the ones in the machine are AC and need 35V. Thanks Rob --===============6448622218090480244==-- From spectre@floodgap.com Sun Nov 13 19:31:33 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 11:31:10 -0800 Message-ID: <8b16b307-6065-8344-3fdb-57e71432b641@floodgap.com> In-Reply-To: <2AE6A513-0409-4934-8AC6-15DFF879AD1F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7563054391549582505==" --===============7563054391549582505== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > AI, not so clear. In my view, AI is a catch-all term for "software whose p= roperties are unknown and probably unknowable". Someone recently on Hacker News talked about the possibility of neural net models to translate code for other architectures. The best response to this idea described it as a "turbo SIGILL generator." The mental image of a CPU ramming into a silicon brick wall, reversing and doing it again, over and over, possibly infinitely (the halting problem) comes irresistibly to mind. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- The earth is like a tiny grain of sand, only a lot heavier and bigger. ---= -- --===============7563054391549582505==-- From paulkoning@comcast.net Sun Nov 13 19:36:33 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 14:36:08 -0500 Message-ID: In-Reply-To: <8b16b307-6065-8344-3fdb-57e71432b641@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3882167758761364533==" --===============3882167758761364533== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 13, 2022, at 2:31 PM, Cameron Kaiser via cctalk wrote: >=20 >> AI, not so clear. In my view, AI is a catch-all term for "software whose = properties are unknown and probably unknowable". >=20 > Someone recently on Hacker News talked about the possibility of neural net > models to translate code for other architectures. The best response to this > idea described it as a "turbo SIGILL generator." That's a good description. > The mental image of a CPU ramming into a silicon brick wall, reversing and > doing it again, over and over, possibly infinitely (the halting problem) co= mes > irresistibly to mind. I see all too many "inventions" that can be summarized as "use prior art solu= tion X to well known problem Y by executing X in an AI (or "machine learning"= ) system." Sigh. paul --===============3882167758761364533==-- From mark.tapley@swri.org Sun Nov 13 19:46:03 2022 From: "Tapley, Mark B." To: cctalk@classiccmp.org Subject: [cctalk] Re: Inline Serial Device? Date: Sun, 13 Nov 2022 19:45:38 +0000 Message-ID: <7255A86E-D332-45E4-A1AB-0183AC21DF07@swri.org> In-Reply-To: <2AE6A513-0409-4934-8AC6-15DFF879AD1F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1245305633920990112==" --===============1245305633920990112== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 13, 2022, at 9:09 AM, Paul Koning via cctalk wrote: >=20 > [EXTERNAL EMAIL] >=20 >=20 >=20 >> On Nov 12, 2022, at 1:08 PM, Anders Nelson via cctalk wrote: >>=20 >> I bet NN/AI would be helpful with data recovery - if we can model certain >> common failure modes with those old drive heads we could infer what the >> data should have been... >=20 > NN maybe, I need to understand those better. I see they are now a building= block for OCR. >=20 > AI, not so clear. In my view, AI is a catch-all term for "software whose p= roperties are unknown and probably unknowable". A computer, including one th= at executes AI softwware, is a math processing engine, so in principle its be= havior is fully defined by its design and by the software in it. But when yo= u do AI in which "learning" is part of the scheme, the resulting behavior is = in fact unknown and undefined. =20 >=20 > For some applications that may be ok. OCR doesn't suffer materially from o= ccasional random errors, since it has errors anyway from the nature of its in= put. But, for example, I shudder at the notion of AI in safety-critical appl= ications (like autopilots for aircraft, or worse yet for cars). A safety cri= tical application implemented in a manner that precludes the existence of a s= pecification is a fundanmentally insane notion. >=20 > paul >=20 Paul, not a fan of AI myself. But, I feel constrained to point out that the altera= tive to "AI in safety-critical applications=E2=80=9D often is =E2=80=9Ca mini= mum-wage employee in a safety-critical application=E2=80=9D which may or may = not be an improvement. Agreed that AI is fundamentally not absolutely predict= able - but neither are people. For problems complex enough to require either = in a safety-critical decision-making loop, it may resolve down to a question = of either 1) trusting the statistics (AI driving is maybe already *statistica= lly* safer than human driving), 2) desiging the whole system in such a manner= as to be tolerant of decision-making faults, or 3) Not doing the dangerous a= ctivity because it=E2=80=99s not monitorable. I would say our current road and automobile system doesn=E2=80=99t satisfy a= ny of those criteria, FWIW. For problems simple enough to write closed-form, formally-verifiable softwar= e to handle, I *definitely* agree that is the way to go.=20 - Mark --===============1245305633920990112==-- From lewissa78@gmail.com Sun Nov 13 20:15:20 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 14:14:48 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3646191878428394760==" --===============3646191878428394760== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Jos, I hadn't realized how similar the DP1100 is. This brochure has a great image of the font right on the front page (80x12 text): http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf And it's probably a safe bet that it's the same font as in the 1972 models. Would be neat to see the entire character set. In the photo, the screen looks fairly inset -- like maybe an inch? That's good for keeping glare off the screen. I see there was a Cassette 1100 and Disk 1100 (by '75): http://www.bitsavers.org/pdf/datapoint/1100/60259_1100_Brochure_1975.pdf Then I came across a DP2200 emulator, except -- it was apparently made in 1973 and ran on a DP2200! (ACM link, but click the PDF, it's freely available) https://dl.acm.org/doi/10.1145/800192.805722 What a neat system. In an old IBM 5110, I replaced its power supply with modern components. From the DP2200 manual, it looks like it needs -5 -12 +5 +12 and +24V? There is a "trick" in the modern buck-boost voltage converters to get negative voltage (the IBM PSU needs -5 -12 +5 +12 and +8.5V). I put notes about it here: https://voidstar.blog/ibm-5100-power-supply/ Maybe something similar can be done for the old DP's? I understand for authentic/historical perspective all original components is prefered, but using a substitute PSU is reasonable for checking out the rest of the system. Were there any contemporary complaints about the DP PSU in the mid-1970s? Like was it noisy, ran hot, cause any fires? I recall a talk from one of the early 1980s Commodore engineer, where he was amazed ANY C64 was still running since the components were truly not designed to last more than a few years. What an amazing system those Datapoints were, for their time. The chicken-farm story in the DP2200 book is really fun - these farmers being savvy enough to code up what they needed, and the systems compact enough to fit in the farms and using modems even to sync up data (pre-1975). The IBM 5100: 64x16 screen (instead of 80x12 used in DP), and a slightly larger "box"(case) that had a "horn" inside for better airflow over all the components (not an audible horn, but a thing that channel air from the PSU fan to distribute over all the electronic cards and display circuits). Plus the 5100 supported the external BNC video (I'm not sure if any of the DP systems had an external video connector? I didn't see it mentioned in the DP2200 manual) - I've put 3x extra CRT's chained up to the IBM 5100, in the manual I think it says it can go up to 16 (not sure what the limiting factor of that signal is). I'm not sure if quality-wise the IBM PSU was "better" (it takes about 3/4th of the back half of the case, the other 1/4th for the fan) - other than to say quite a few 5100's are still running in the world. Maybe all that altogether makes it (the 5100) a more "portable" system (construction sites, forward edge battlespace, etc -- i.e. being more robust to handle outside heat). Also it had a minimum of 8K. The APL stuff made the 5100 expensive, but the base BASIC model was ~$9K (I think even with the single QIC tape for 207KB storage; but that price didn't include async/comm cards). Weren't base DPs $5K-$7K (all throughout 72-75) ? But, in extracting the data on those TTLs, it seems like a modern replica of a DP2200 would be possible. Can't say the same for the 5100 because apparently nobody left on the planet understands those MOSFET silver cans (and how to extract the 6KB of content from them). Sorry for the tangent:) I really was just curious about the DP2200 font, and possibly seeing where it came from (just based on its style). The DP has a better "0" (zero) font than the 5100 :) (IMO) -Steve On Sun, Nov 13, 2022 at 3:45 AM jos via cctalk wrote: > On 13.11.22 07:13, Steve Lewis via cctalk wrote: > > I've been looking for a video or image that shows what font the original > > Datapoint 2200 used. > > > > It's not shown in the manual. There is one vintage image with the > office > > lady and the DP2200 on the desk- but the font isn't very clear in that. > > > > In any modern video about the DP2200, none of them seem to power it on -- > > which is certainly understandable. From what I've read, the power > supply > > of that system is prone to failure. Also, the system is hard-coded to > load > > from Tape 1 -- which means both the tape drive, and tape media, still > needs > > to be in good working order (which would be pretty rare after this time). > > > > In "the" DP2200 book, it only briefly mentions that the original tape > > software was developed "on an HP system" (without any elaboration that I > > could tell on which HP system that was). > > > > Nothing in the manual suggests the original DP2200 could "program itself" > > (i.e. no built in machine code monitor -- those TTL chips had one strict > > boot up sequence: load from tape 1). If there was a read error or no > tape > > available, I'm curious if any message showed on the CRT. > > > > So, I was just wondering if there was any known pre-1973 Datapoint 2200's > > that are still working? (and/or if any HD video of them powered on and > > legible font can be seen) Or any other more current system that we know > > for sure used the same font? > > > > Thanks! > > -Steve > > > Not only is the powersupply prone to failure, it is also the most > dangerous I have ever seen, and I am hesitant on working it. Primary and > secondary sides not separated, isolation between the two almost > nonexistant, many primary nodes exposed. Would never pass modern safety > checks. > > But here is a picture of my DP1100, a DP2200 derivative, while it was > running a memory selftest, for a short time in 2021, before the powersupply > blew again : > > > https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.= 1222197/#post-1222197 > > While the DP2200 is hardcoded to start from tape, the DP1100, otherwise > identical, boots from a ROM. This ROM also contains a minimal machinecode > monitor. I recovered & disasembled the ROM and Gordon Peterson, from > Datapoint, commented it out : > http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisassemblyGEP2.txt > > Note that there are multiple videoboard options : the later DP2200, my > DP1100, and the DP5500 share the same videoboard. This relies on a > programmable characterset. In the disassembly mentioned above above, > starting at line 3660 you will see a load of gobldecook, these are actually > fondsets to be loaded into the machine. > > The fontset has a very particular "look" to it. How much is due to > fontdefinition, and how much is due to the diddlescan, that I dont know. > Diddlescan is where they scan each character in full, before proceding to > the next. > > Note that a ROM based bootboard for a DP2200 would be a trivial > undertaking, and only involve changing the cassette reader board for the > ROM board. > > > Jos > > > --===============3646191878428394760==-- From paul@frixxon.co.uk Sun Nov 13 20:23:53 2022 From: Paul Flo Williams To: cctalk@classiccmp.org Subject: [cctalk] Re: Modern Replacement for H7140 in PDP 11/24 Date: Sun, 13 Nov 2022 19:55:43 +0000 Message-ID: <20221113195543.662f47ff@chopoc.localdomain> In-Reply-To: <012901d8f78e$d5b73500$81259f00$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2425265083330411301==" --===============2425265083330411301== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 13 Nov 2022 18:36:24 -0000 Rob Jarratt via cctalk wrote: > Given all the troubles I have had with the H7140 in my PDP 11/24 I am > considering whether to replace it with modern equivalents, installed > inside the H7140 enclosure. I am a bit puzzled by the specs listed in > the PDP 11/24 Maintenance Card, it suggests the PSU outputs +12V and > -12V from the memory inverter/memory regulator, but the specs for the > cards don't mention 12V so I don't know if I need 12V from the PSU. > My memory board is an M8722-BC (MS11-MB). I can't find a manual or > printset for this memory, so I am not sure what voltages it will > need, although I suspect it only needs +5V, +15V and -15V. Is that > right? The MS11-MB printset is here: http://wwcm.synology.me/pdf/MP00742%20MS11-M%20Field%20Maintenance%20Print%20= Set.pdf --===============2425265083330411301==-- From sellam.ismail@gmail.com Sun Nov 13 21:01:08 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 13:00:30 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4599619071959087990==" --===============4599619071959087990== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Steve said: > I recall a talk from one of the early 1980s Commodore engineer, where he was amazed ANY C64 was still > running since the components were truly not designed to last more than a few years. Me too, to be honest. But then, they seem to just randomly die at any moment, so maybe the C64 components are only good for so many hours of use, like a light bulb. The fact that so many of them were made (upwards of 25 million) is probably why some can still be found working. Those are still somewhere on the vertical of the bathtub curve on the backend, where their useful life is fast coming to an end. We will all probably witness the last working Commodore 64's in our lifetimes :D > But, in extracting the data on those TTLs, it seems like a modern replica of a DP2200 would be possible. > Can't say the same for the 5100 because apparently nobody left on the planet understands those MOSFET > silver cans (and how to extract the 6KB of content from them). I am completely ignorant to the operation of the 5100 but can't you just dump that memory when the system is on? Or is there some Jon Titor type reason behind it? Sellam On Sun, Nov 13, 2022 at 12:15 PM Steve Lewis via cctalk < cctalk(a)classiccmp.org> wrote: > Thanks Jos, I hadn't realized how similar the DP1100 is. > > This brochure has a great image of the font right on the front page (80x12 > text): > http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf > > And it's probably a safe bet that it's the same font as in the 1972 > models. Would be neat to see the entire character set. In the photo, the > screen looks fairly inset -- like maybe an inch? That's good for keeping > glare off the screen. > > I see there was a Cassette 1100 and Disk 1100 (by '75): > http://www.bitsavers.org/pdf/datapoint/1100/60259_1100_Brochure_1975.pdf > > Then I came across a DP2200 emulator, except -- it was apparently made in > 1973 and ran on a DP2200! (ACM link, but click the PDF, it's freely > available) > https://dl.acm.org/doi/10.1145/800192.805722 > > > What a neat system. In an old IBM 5110, I replaced its power supply with > modern components. From the DP2200 manual, it looks like it needs -5 > -12 +5 +12 and +24V? There is a "trick" in the modern buck-boost voltage > converters to get negative voltage (the IBM PSU needs -5 -12 +5 +12 > and +8.5V). I put notes about it here: > https://voidstar.blog/ibm-5100-power-supply/ > > Maybe something similar can be done for the old DP's? I understand for > authentic/historical perspective all original components is prefered, but > using a substitute PSU is reasonable for checking out the rest of the > system. > > Were there any contemporary complaints about the DP PSU in the mid-1970s? > Like was it noisy, ran hot, cause any fires? I recall a talk from one of > the early 1980s Commodore engineer, where he was amazed ANY C64 was still > running since the components were truly not designed to last more than a > few years. > > > What an amazing system those Datapoints were, for their time. The > chicken-farm story in the DP2200 book is really fun - these farmers being > savvy enough to code up what they needed, and the systems compact enough to > fit in the farms and using modems even to sync up data (pre-1975). > > The IBM 5100: 64x16 screen (instead of 80x12 used in DP), and a > slightlyBut, in extracting the data on those TTLs, it seems like a modern > replica > of a DP2200 would be possible. Can't say the same for the 5100 because > apparently nobody left on the planet understands those MOSFET silver cans > (and how to extract the 6KB of content from them). > larger "box"(case) that had a "horn" inside for better airflow over all the > components (not an audible horn, but a thing that channel air from the PSU > fan to distribute over all the electronic cards and display circuits). > Plus the 5100 supported the external BNC video (I'm not sure if any of the > DP systems had an external video connector? I didn't see it mentioned in > the DP2200 manual) - I've put 3x extra CRT's chained up to the IBM 5100, in > the manual I think it says it can go up to 16 (not sure what the limiting > factor of that signal is). I'm not sure if quality-wise the IBM PSU was > "better" (it takes about 3/4th of the back half of the case, the other > 1/4th for the fan) - other than to say quite a few 5100's are still running > in the world. Maybe all that altogether makes it (the 5100) a more > "portable" system (construction sites, forward edge battlespace, etc -- > i.e. being more robust to handle outside heat). Also it had a minimum of > 8K. The APL stuff made the 5100 expensive, but the base BASIC model was > ~$9K (I think even with the single QIC tape for 207KB storage; but that > price didn't include async/comm cards). Weren't base DPs $5K-$7K (all > throughout 72-75) ? > > > But, in extracting the data on those TTLs, it seems like a modern replica > of a DP2200 would be possible. Can't say the same for the 5100 because > apparently nobody left on the planet understands those MOSFET silver cans > (and how to extract the 6KB of content from them). > > > Sorry for the tangent:) I really was just curious about the DP2200 font, > and possibly seeing where it came from (just based on its style). The DP > has a better "0" (zero) font than the 5100 :) (IMO) > > > -Steve > > > > On Sun, Nov 13, 2022 at 3:45 AM jos via cctalk > wrote: > > > On 13.11.22 07:13, Steve Lewis via cctalk wrote: > > > I've been looking for a video or image that shows what font the > original > > > Datapoint 2200 used. > > > > > > It's not shown in the manual. There is one vintage image with the > > office > > > lady and the DP2200 on the desk- but the font isn't very clear in that. > > > > > > In any modern video about the DP2200, none of them seem to power it on > -- > > > which is certainly understandable. From what I've read, the power > > supply > > > of that system is prone to failure. Also, the system is hard-coded to > > load > > > from Tape 1 -- which means both the tape drive, and tape media, still > > needs > > > to be in good working order (which would be pretty rare after this > time). > > > > > > In "the" DP2200 book, it only briefly mentions that the original tape > > > software was developed "on an HP system" (without any elaboration that > I > > > could tell on which HP system that was). > > > > > > Nothing in the manual suggests the original DP2200 could "program > itself" > > > (i.e. no built in machine code monitor -- those TTL chips had one > strict > > > boot up sequence: load from tape 1). If there was a read error or no > > tape > > > available, I'm curious if any message showed on the CRT. > > > > > > So, I was just wondering if there was any known pre-1973 Datapoint > 2200's > > > that are still working? (and/or if any HD video of them powered on and > > > legible font can be seen) Or any other more current system that we > know > > > for sure used the same font? > > > > > > Thanks! > > > -Steve > > > > > > Not only is the powersupply prone to failure, it is also the mostBut, > in extracting the data on those TTLs, it seems like a modern replica > of a DP2200 would be possible. Can't say the same for the 5100 because > apparently nobody left on the planet understands those MOSFET silver cans > (and how to extract the 6KB of content from them). > > dangerous I have ever seen, and I am hesitant on working it. Primary and > > secondary sides not separated, isolation between the two almost > > nonexistant, many primary nodes exposed. Would never pass modern safety > > checks. > > > > But here is a picture of my DP1100, a DP2200 derivative, while it was > > running a memory selftest, for a short time in 2021, before the > powersupply > > blew again : > > > > > > > https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.= 1222197/#post-1222197 > > > > While the DP2200 is hardcoded to start from tape, the DP1100, otherwise > > identical, boots from a ROM. This ROM also contains a minimal machinecode > > monitor. I recovered & disasembled the ROM and Gordon Peterson, from > > Datapoint, commented it out : > > > http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisassemblyGEP2.txt > > > > Note that there are multiple videoboard options : the later DP2200, my > > DP1100, and the DP5500 share the same videoboard. This relies on a > > programmable characterset. In the disassembly mentioned above above, > > starting at line 3660 you will see a load of gobldecook, these are > actually > > fondsets to be loaded into the machine. > > > > The fontset has a very particular "look" to it. How much is due to > > fontdefinition, and how much is due to the diddlescan, that I dont know. > > Diddlescan is where they scan each character in full, before proceding to > > the next. > > > > Note that a ROM based bootboard for a DP2200 would be a trivial > > undertaking, and only involve changing the cassette reader board for the > > ROM board. > > > > > > Jos > > > > > > > --===============4599619071959087990==-- From lewissa78@gmail.com Sun Nov 13 21:45:52 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 15:45:20 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1453149055884645920==" --===============1453149055884645920== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable True, I'd have to assume actual usage degrades the longevity of some electronics (and number of hot/cold cycles). But there is still some natural shelf-life decay (maybe moisture in the air can find its way, even in what should be sealed components). > I am completely ignorant to the operation of the 5100 but can't you just > dump that memory when the system is on? Or is there some Jon Titor type > reason behind it? Some of it, yes. Enough that a viable 5110 emulator was made (5100 emulator still in work). But there is some code in the PALM processor itself (about a dozen "tin cans" on there, related to how it actually executed instructions), the Base IO card, display card, comm. cards. Like for the display card, and how its character set is generated (there should be similar code like was shown for the DP). So there are some limits to the emulator, such as MARKing a tape/disk and doing both a read/write of tape/disk images (there is some limited read capability). So, true, baring some of the I/O features and some precise timing of the processor, a reasonable replica could be made (a good replica of the font is in Corti's X11 parts of the emulator - one of the sets at least). But that's an emulation, not a replica :D On Sun, Nov 13, 2022 at 3:00 PM Sellam Abraham via cctalk < cctalk(a)classiccmp.org> wrote: > Steve said: > > > I recall a talk from one of the early 1980s Commodore engineer, where he > was amazed ANY C64 was still > > running since the components were truly not designed to last more than a > few years. > > Me too, to be honest. But then, they seem to just randomly die at any > moment, so maybe the C64 components are only good for so many hours of use, > like a light bulb. The fact that so many of them were made (upwards of 25 > million) is probably why some can still be found working. Those are still > somewhere on the vertical of the bathtub curve on the backend, where their > useful life is fast coming to an end. We will all probably witness the > last working Commodore 64's in our lifetimes :D > > > But, in extracting the data on those TTLs, it seems like a modern replica > of a DP2200 would be possible. > > Can't say the same for the 5100 because apparently nobody left on the > planet understands those MOSFET > > silver cans (and how to extract the 6KB of content from them). > > I am completely ignorant to the operation of the 5100 but can't you just > dump that memory when the system is on? Or is there some Jon Titor type > reason behind it? > > Sellam > > > On Sun, Nov 13, 2022 at 12:15 PM Steve Lewis via cctalk < > cctalk(a)classiccmp.org> wrote: > > > Thanks Jos, I hadn't realized how similar the DP1100 is. > > > > This brochure has a great image of the font right on the front page > (80x12 > > text): > > > http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf > > > > And it's probably a safe bet that it's the same font as in the 1972 > > models. Would be neat to see the entire character set. In the photo, > the > > screen looks fairly inset -- like maybe an inch? That's good for keeping > > glare off the screen. > > > > I see there was a Cassette 1100 and Disk 1100 (by '75): > > http://www.bitsavers.org/pdf/datapoint/1100/60259_1100_Brochure_1975.pdf > > > > Then I came across a DP2200 emulator, except -- it was apparently made in > > 1973 and ran on a DP2200! (ACM link, but click the PDF, it's freely > > available) > > https://dl.acm.org/doi/10.1145/800192.805722 > > > > > > What a neat system. In an old IBM 5110, I replaced its power supply > with > > modern components. From the DP2200 manual, it looks like it needs -5 > > -12 +5 +12 and +24V? There is a "trick" in the modern buck-boost voltage > > converters to get negative voltage (the IBM PSU needs -5 -12 +5 +12 > > and +8.5V). I put notes about it here: > > https://voidstar.blog/ibm-5100-power-supply/ > > > > Maybe something similar can be done for the old DP's? I understand for > > authentic/historical perspective all original components is prefered, but > > using a substitute PSU is reasonable for checking out the rest of the > > system. > > > > Were there any contemporary complaints about the DP PSU in the mid-1970s? > > Like was it noisy, ran hot, cause any fires? I recall a talk from one > of > > the early 1980s Commodore engineer, where he was amazed ANY C64 was still > > running since the components were truly not designed to last more than a > > few years. > > > > > > What an amazing system those Datapoints were, for their time. The > > chicken-farm story in the DP2200 book is really fun - these farmers being > > savvy enough to code up what they needed, and the systems compact enough > to > > fit in the farms and using modems even to sync up data (pre-1975). > > > > The IBM 5100: 64x16 screen (instead of 80x12 used in DP), and a > > slightlyBut, in extracting the data on those TTLs, it seems like a modern > > replica > > of a DP2200 would be possible. Can't say the same for the 5100 because > > apparently nobody left on the planet understands those MOSFET silver cans > > (and how to extract the 6KB of content from them). > > larger "box"(case) that had a "horn" inside for better airflow over all > the > > components (not an audible horn, but a thing that channel air from the > PSU > > fan to distribute over all the electronic cards and display circuits). > > Plus the 5100 supported the external BNC video (I'm not sure if any of > the > > DP systems had an external video connector? I didn't see it mentioned in > > the DP2200 manual) - I've put 3x extra CRT's chained up to the IBM 5100, > in > > the manual I think it says it can go up to 16 (not sure what the limiting > > factor of that signal is). I'm not sure if quality-wise the IBM PSU was > > "better" (it takes about 3/4th of the back half of the case, the other > > 1/4th for the fan) - other than to say quite a few 5100's are still > running > > in the world. Maybe all that altogether makes it (the 5100) a more > > "portable" system (construction sites, forward edge battlespace, etc -- > > i.e. being more robust to handle outside heat). Also it had a minimum of > > 8K. The APL stuff made the 5100 expensive, but the base BASIC model was > > ~$9K (I think even with the single QIC tape for 207KB storage; but that > > price didn't include async/comm cards). Weren't base DPs $5K-$7K (all > > throughout 72-75) ? > > > > > > But, in extracting the data on those TTLs, it seems like a modern replica > > of a DP2200 would be possible. Can't say the same for the 5100 because > > apparently nobody left on the planet understands those MOSFET silver cans > > (and how to extract the 6KB of content from them). > > > > > > Sorry for the tangent:) I really was just curious about the DP2200 font, > > and possibly seeing where it came from (just based on its style). The DP > > has a better "0" (zero) font than the 5100 :) (IMO) > > > > > > -Steve > > > > > > > > On Sun, Nov 13, 2022 at 3:45 AM jos via cctalk > > wrote: > > > > > On 13.11.22 07:13, Steve Lewis via cctalk wrote: > > > > I've been looking for a video or image that shows what font the > > original > > > > Datapoint 2200 used. > > > > > > > > It's not shown in the manual. There is one vintage image with the > > > office > > > > lady and the DP2200 on the desk- but the font isn't very clear in > that. > > > > > > > > In any modern video about the DP2200, none of them seem to power it > on > > -- > > > > which is certainly understandable. From what I've read, the power > > > supply > > > > of that system is prone to failure. Also, the system is hard-coded > to > > > load > > > > from Tape 1 -- which means both the tape drive, and tape media, still > > > needs > > > > to be in good working order (which would be pretty rare after this > > time). > > > > > > > > In "the" DP2200 book, it only briefly mentions that the original tape > > > > software was developed "on an HP system" (without any elaboration > that > > I > > > > could tell on which HP system that was). > > > > > > > > Nothing in the manual suggests the original DP2200 could "program > > itself" > > > > (i.e. no built in machine code monitor -- those TTL chips had one > > strict > > > > boot up sequence: load from tape 1). If there was a read error or > no > > > tape > > > > available, I'm curious if any message showed on the CRT. > > > > > > > > So, I was just wondering if there was any known pre-1973 Datapoint > > 2200's > > > > that are still working? (and/or if any HD video of them powered on > and > > > > legible font can be seen) Or any other more current system that we > > know > > > > for sure used the same font? > > > > > > > > Thanks! > > > > -Steve > > > > > > > > > Not only is the powersupply prone to failure, it is also the mostBut, > > in extracting the data on those TTLs, it seems like a modern replica > > of a DP2200 would be possible. Can't say the same for the 5100 because > > apparently nobody left on the planet understands those MOSFET silver cans > > (and how to extract the 6KB of content from them). > > > dangerous I have ever seen, and I am hesitant on working it. Primary > and > > > secondary sides not separated, isolation between the two almost > > > nonexistant, many primary nodes exposed. Would never pass modern safety > > > checks. > > > > > > But here is a picture of my DP1100, a DP2200 derivative, while it was > > > running a memory selftest, for a short time in 2021, before the > > powersupply > > > blew again : > > > > > > > > > > > > https://forum.vcfed.org/index.php?threads/its-alive-my-datapoint-2200-1100.= 1222197/#post-1222197 > > > > > > While the DP2200 is hardcoded to start from tape, the DP1100, otherwise > > > identical, boots from a ROM. This ROM also contains a minimal > machinecode > > > monitor. I recovered & disasembled the ROM and Gordon Peterson, from > > > Datapoint, commented it out : > > > > > > http://www.bitsavers.org/pdf/datapoint/1100/DisketteBootDisassemblyGEP2.txt > > > > > > Note that there are multiple videoboard options : the later DP2200, my > > > DP1100, and the DP5500 share the same videoboard. This relies on a > > > programmable characterset. In the disassembly mentioned above above, > > > starting at line 3660 you will see a load of gobldecook, these are > > actually > > > fondsets to be loaded into the machine. > > > > > > The fontset has a very particular "look" to it. How much is due to > > > fontdefinition, and how much is due to the diddlescan, that I dont > know. > > > Diddlescan is where they scan each character in full, before proceding > to > > > the next. > > > > > > Note that a ROM based bootboard for a DP2200 would be a trivial > > > undertaking, and only involve changing the cassette reader board for > the > > > ROM board. > > > > > > > > > Jos > > > > > > > > > > > > --===============1453149055884645920==-- From elson@pico-systems.com Sun Nov 13 23:18:30 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Sun, 13 Nov 2022 17:18:10 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2715025467156676852==" --===============2715025467156676852== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/13/22 15:45, Steve Lewis via cctalk wrote: > True, I'd have to assume actual usage degrades the longevity of some > electronics (and number of hot/cold cycles). But there is still some > natural shelf-life decay (maybe moisture in the air can find its way, even > in what should be sealed components). > Yup, I have a ~ year 2000 pick and place machine.  It was last used in about 2006 and then abandoned in Austin, TX.  I bought it at auction in 2020, so it had been sitting for about 14 years, likely in unconditioned air space.  It fired right up the first time I tried, and I cloned the hard drive.  Then, 2 days later it would not come out of E-stop.  Lots of boards went bad over time, and are still going out.  Nothing I have replaced has failed, and all repair parts must be about the same vintage.  So, yes, sitting in warm, humid conditions for a long time apparently is NOT good for electronics.  Funny, the man-machine interface computer is a consumer-grade PC, I think it is original, and is still chugging along.  VME boards and industrial servo drives have gone out. Jon --===============2715025467156676852==-- From jos.dreesen@greenmail.ch Mon Nov 14 08:01:06 2022 From: jos To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Mon, 14 Nov 2022 09:00:22 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0492047767777042015==" --===============0492047767777042015== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 13.11.22 21:14, Steve Lewis via cctalk wrote: > Thanks Jos, I hadn't realized how similar the DP1100 is. > > This brochure has a great image of the font right on the front page (80x12 > text): > http://www.bitsavers.org/pdf/datapoint/1100/Dataform_1100_Brochure_1974.pdf > > > Maybe something similar can be done for the old DP's? I understand for > authentic/historical perspective all original components is prefered, but > using a substitute PSU is reasonable for checking out the rest of the > system. The DP2200 needs secondaries of 450V, 120V,40V, 25V, -25V, 12V, -12V 5V and -= 5V. Yep, can be done, but..... > What an amazing system those Datapoints were, for their time. The > chicken-farm story in the DP2200 book is really fun - these farmers being > savvy enough to code up what they needed, and the systems compact enough to > fit in the farms and using modems even to sync up data (pre-1975). They were, and are, indeed nice little systems...really need to get mine up a= gain, also because I have a Diablo disk system for it. Must be extremely rare= .. > But, in extracting the data on those TTLs, it seems like a modern replica > of a DP2200 would be possible. Sure, I even have the complete DP2200 MB in Kicad, see http://www.bitsavers.o= rg/pdf/datapoint/2200/jdreesen_shematics/DP2200_mb.pdf if anyone wants to go ahead I will gladly share my Kicad project ! Mind you, = the diddlescan is a problem as that requires a CRT yoke with 3 windings.... Jos --===============0492047767777042015==-- From cc@informatik.uni-stuttgart.de Mon Nov 14 09:11:54 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Any working Datapoint 2200 systems? Date: Mon, 14 Nov 2022 10:11:30 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3880266964966829369==" --===============3880266964966829369== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 14 Nov 2022, jos wrote: > if anyone wants to go ahead I will gladly share my Kicad project ! Mind you= ,=20 > the diddlescan is a problem as that requires a CRT yoke with 3 windings.... Reminds me of the Cogar C4/ICL 1500 system that has a rotated deflection=20 also with diddlescan ;-) But I think it uses only two windings and=20 overlays the character deflection with the vertical deflection (it's=20 desribed in the service manuals). Christian --===============3880266964966829369==-- From tshoppa@wmata.com Mon Nov 14 12:26:15 2022 From: "Shoppa, Tim" To: cctalk@classiccmp.org Subject: [cctalk] 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 12:25:44 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6898779050202813749==" --===============6898779050202813749== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've been reporting on 9-track tape seal failures over at least the past 2 de= cades here. I first noticed the problem in the very early 2000's, and thought it was just= random onesy-twosy failures, possibly contributed to by ozone in LA region, = but over the past 20 years the failures have progressed. Sometime in the past couple weeks the last of my "soft" 9-track tape seals fa= iled, because there is nothing but broken tape seals left hanging in the Wrig= ht-Line rack that had all my "new" aka 3M Blackwatch 703 tapes. Very very few of the older (I think of them as IBM or 70's/80's style) "hard = plastic" tape seals failed. Tim N3QE --===============6898779050202813749==-- From elson@pico-systems.com Mon Nov 14 15:20:09 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 09:19:45 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CDM6PR06MB480952F89B0044AD8C1BE871BA059=40DM6PR06MB?= =?utf-8?q?4809=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7785243467481109984==" --===============7785243467481109984== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/14/22 06:25, Shoppa, Tim via cctalk wrote: > I've been reporting on 9-track tape seal failures over at least the past 2 = decades here. > > I first noticed the problem in the very early 2000's, and thought it was ju= st random onesy-twosy failures, possibly contributed to by ozone in LA region= , but over the past 20 years the failures have progressed. > > Sometime in the past couple weeks the last of my "soft" 9-track tape seals = failed, because there is nothing but broken tape seals left hanging in the Wr= ight-Line rack that had all my "new" aka 3M Blackwatch 703 tapes. > > Very very few of the older (I think of them as IBM or 70's/80's style) "har= d plastic" tape seals failed. > Yup, these seals were under tension.=C2=A0 I think the failure=20 mechanism is the square holes in the seal band develop=20 cracks at the outer corners, and the tension continues to=20 expand the crack. Jon --===============7785243467481109984==-- From elson@pico-systems.com Mon Nov 14 16:12:33 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 10:12:14 -0600 Message-ID: <4306f503-442e-fd32-71d3-0cfe74440bf7@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3532828727971740404==" --===============3532828727971740404== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/14/22 09:19, Jon Elson via cctalk wrote: > On 11/14/22 06:25, Shoppa, Tim via cctalk wrote: >> I've been reporting on 9-track tape seal failures over at >> least the past 2 decades here. >> >> >> Very very few of the older (I think of them as IBM or >> 70's/80's style) "hard plastic" tape seals failed. >> > Yup, these seals were under tension.  I think the failure > mechanism is the square holes in the seal band develop > cracks at the outer corners, and the tension continues to > expand the crack. The soft seals were Polyethelene, I think, the "hard" seals for use on drives with auto-loaders were Cyclolac, AKA ABS, and were not in much tension when closed. Jon --===============3532828727971740404==-- From cclist@sydex.com Mon Nov 14 16:37:03 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 08:36:37 -0800 Message-ID: <5a033675-16c4-3dfe-d210-3cf4e83d9102@sydex.com> In-Reply-To: =?utf-8?q?=3CDM6PR06MB480952F89B0044AD8C1BE871BA059=40DM6PR06MB?= =?utf-8?q?4809=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7514169165003206344==" --===============7514169165003206344== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/14/22 04:25, Shoppa, Tim via cctalk wrote: > I've been reporting on 9-track tape seal failures over at least the past 2 = decades here. >=20 > I first noticed the problem in the very early 2000's, and thought it was ju= st random onesy-twosy failures, possibly contributed to by ozone in LA region= , but over the past 20 years the failures have progressed. >=20 > Sometime in the past couple weeks the last of my "soft" 9-track tape seals = failed, because there is nothing but broken tape seals left hanging in the Wr= ight-Line rack that had all my "new" aka 3M Blackwatch 703 tapes. >=20 > Very very few of the older (I think of them as IBM or 70's/80's style) "har= d plastic" tape seals failed. >=20 I wrote about this problem here at least 2 or 3 years ago, Although there must have been millions of these soft seals manufactured (that's not an exaggeration; the US government, for example, used hundreds of thousands of them). And yes, the IBM autoloader tape seal(for 3400 series drives) is very durable--I haven't seen many of these fail. But what I call the "Wright Line" PVC tape seal will age out and eventually crack and break. Usually this occurs where the "hook" is attached, due to the attachment being a hole punched in the PVC belt. On a couple of occasions, I've had the seals split longitudinally. This is almost epidemic on 1960s and 70s 7 track tapes, due to their age. Locating replacements has proven to be an exercise in futility, particularly when one realizes that even relatively new ones are doomed to fail. What I've done for customers is return their 10.5" reels in 16mm plastic tape "cans" in the 800' size. The fit is perfect and I've received no complaints. Film "cans" for smaller reels are also available. My source for these is Urbanski Film, although there are other vendors--and the "cans" are still being manufactured. --Chuck --===============7514169165003206344==-- From sellam.ismail@gmail.com Mon Nov 14 18:58:50 2022 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 10:56:45 -0800 Message-ID: In-Reply-To: <5a033675-16c4-3dfe-d210-3cf4e83d9102@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3961492057029185344==" --===============3961492057029185344== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Point of order for the dummies: what is a tape seal? Sellam On Mon, Nov 14, 2022 at 8:36 AM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 11/14/22 04:25, Shoppa, Tim via cctalk wrote: > > I've been reporting on 9-track tape seal failures over at least the past > 2 decades here. > > > > I first noticed the problem in the very early 2000's, and thought it was > just random onesy-twosy failures, possibly contributed to by ozone in LA > region, but over the past 20 years the failures have progressed. > > > > Sometime in the past couple weeks the last of my "soft" 9-track tape > seals failed, because there is nothing but broken tape seals left hanging > in the Wright-Line rack that had all my "new" aka 3M Blackwatch 703 tapes. > > > > Very very few of the older (I think of them as IBM or 70's/80's style) > "hard plastic" tape seals failed. > > > > I wrote about this problem here at least 2 or 3 years ago, Although > there must have been millions of these soft seals manufactured (that's > not an exaggeration; the US government, for example, used hundreds of > thousands of them). And yes, the IBM autoloader tape seal(for 3400 > series drives) is very durable--I haven't seen many of these fail. > > But what I call the "Wright Line" PVC tape seal will age out and > eventually crack and break. Usually this occurs where the "hook" is > attached, due to the attachment being a hole punched in the PVC belt. > On a couple of occasions, I've had the seals split longitudinally. This > is almost epidemic on 1960s and 70s 7 track tapes, due to their age. > > Locating replacements has proven to be an exercise in futility, > particularly when one realizes that even relatively new ones are doomed > to fail. > > What I've done for customers is return their 10.5" reels in 16mm > plastic tape "cans" in the 800' size. The fit is perfect and I've > received no complaints. Film "cans" for smaller reels are also > available. My source for these is Urbanski Film, although there are > other vendors--and the "cans" are still being manufactured. > > --Chuck > > > > > --===============3961492057029185344==-- From paulkoning@comcast.net Mon Nov 14 19:08:23 2022 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 14:07:42 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6854213524781403725==" --===============6854213524781403725== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 14, 2022, at 1:56 PM, Sellam Abraham via cctalk wrote: >=20 > Point of order for the dummies: what is a tape seal? A wrapper around the rim of a 1/2 inch tape reel, to protect it and allow for= storage. It's more compact than the alternative, a canister to hold the tap= e, though both were used. Tape seals come in two flavors. One is just a seal -- it protects the tape and has a hook to hang it in a sto= rage rack. To use the tape, you remove the seal and load the tape reel. htt= ps://en.wikipedia.org/wiki/File:Tapeprotection.jpg -- the white rim around th= e reel, with the black hook at the top of the photo. The other is a seal but also can be opened by the drive mechanism to allow th= e tape end to escape through a slot in the seal. These were used for auto-lo= ading tape drives. You'd mount the reel, seal and all, hit "load" and the dr= ive would make the tape end come out of the seal slot, thread it through the = tape drive path and onto the take up reel, and get it ready for use. https:/= /en.wikipedia.org/wiki/File:Magnetic-tape_hg.jpg The ones that fail are the first type, made of soft plastic that's either def= icient in strenght or in longevity, or perhaps both. paul --===============6854213524781403725==-- From cclist@sydex.com Mon Nov 14 19:21:49 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 11:14:50 -0800 Message-ID: <35901d56-361d-f208-dd1f-21a02c29f5d3@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2007704250427406892==" --===============2007704250427406892== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/14/22 10:56, Sellam Abraham via cctalk wrote: > Point of order for the dummies: what is a tape seal? > > Sellam The type under discussion is this: https://forum.vcfed.org/index.php?attachments/1667864510113-png.1248420/ The "band" that goes around a reel of 1/2" tape and allows it to be hung in a rack. Wright-Line was big in this type. https://www.govdeals.com/photos/767/767_18381_19.jpg IBM used a different seal with their autoloading drives and storage racks for those worked a bit differently. --Chuck --===============2007704250427406892==-- From cisin@xenosoft.com Mon Nov 14 19:23:57 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 11:23:32 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3282254394504261885==" --===============3282254394504261885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit 1) A piece of tamper-proof tape, labeled "breaking this seal voids warranty". If you do major modifications to something, such as a TRS80 model 1, always put a fresh tamper-evident seal on it afterwards, to re-enable the warranty. 2) Also called a "tape hanger", a piece of plastic that wraps around the circumference of a reel of tape to keep it from unrolling all over the floor, and has a hook for hanging the tape in a rack. Now known to have a limited lifespan. 3) "tape, seal" 3M Temflex type 21557, used to attach a VHF transmitter to pinnipeds, such as northern elephant seals, for tracking On Mon, 14 Nov 2022, Sellam Abraham via cctalk wrote: > Point of order for the dummies: what is a tape seal? > > Sellam >> On 11/14/22 04:25, Shoppa, Tim via cctalk wrote: >>> I've been reporting on 9-track tape seal failures over at least the past >> 2 decades here. --===============3282254394504261885==-- From cclist@sydex.com Mon Nov 14 19:25:36 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 11:17:05 -0800 Message-ID: <57071741-4fbb-d958-7db7-7de661df13c3@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9001106880936945716==" --===============9001106880936945716== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here's a photo of a "combo" Wright Line rack. Note how the upper row of tapes are hung from a rail. https://photovault.com/data/resize/800x550/TEC/TECV01P01_19.jpg?a21a7d6f2c851= 40ab281fe847fc313ac --Chuck --===============9001106880936945716==-- From geneb@deltasoft.com Mon Nov 14 21:23:39 2022 From: geneb To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 13:23:14 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4162986489434340006==" --===============4162986489434340006== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 14 Nov 2022, Fred Cisin via cctalk wrote: > 1) A piece of tamper-proof tape, labeled "breaking this seal voids warranty= ".=20 > If you do major modifications to something, such as a TRS80 model 1, always= =20 > put a fresh tamper-evident seal on it afterwards, to re-enable the warranty. It's a lot less effort to tell them the sticker was illegal to begin with.=20 ;) g. --=20 Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! --===============4162986489434340006==-- From cisin@xenosoft.com Mon Nov 14 21:47:34 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 13:47:16 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0182555828449027928==" --===============0182555828449027928== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> 1) A piece of tamper-proof tape, labeled "breaking this seal voids=20 >> warranty". If you do major modifications to something, such as a TRS80=20 >> model 1, always put a fresh tamper-evident seal on it afterwards, to=20 >> re-enable the warranty. On Mon, 14 Nov 2022, geneb wrote: > It's a lot less effort to tell them the sticker was illegal to begin with. = ;) . . . and have him have to escalate it to somebody authorized to make=20 exceptions, or argue with tandy lawyers? Nah, it's more FUN to excuse the piggy-backed chips and extra circuitry=20 added in with, "well, it's like building a boat in a bottle, and if the=20 seal isn't broken, then the warraanty is still valid, even with=20 modifications" Although, for a while, we had a tech at the local Radio Shack "Computer=20 Center", who would gladly ignore any modifications for which we gave him=20 circuit diagrams. (lower case, extra keys, memory remapping, RCA=20 jack for composite video out, reverse video, etc.) --===============0182555828449027928==-- From geneb@deltasoft.com Mon Nov 14 22:32:13 2022 From: geneb To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 14:31:47 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4752281244802911789==" --===============4752281244802911789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 14 Nov 2022, Fred Cisin via cctalk wrote: >>> 1) A piece of tamper-proof tape, labeled "breaking this seal voids >>> warranty". If you do major modifications to something, such as a TRS80 >>> model 1, always put a fresh tamper-evident seal on it afterwards, to >>> re-enable the warranty. > > On Mon, 14 Nov 2022, geneb wrote: >> It's a lot less effort to tell them the sticker was illegal to begin with. >> ;) > > . . . and have him have to escalate it to somebody authorized to make > exceptions, or argue with tandy lawyers? > Nope. You point out that the state attorney(sp) general would love to watch Tandy flail against the Magnusson-Moss Warranty Act. ;) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! --===============4752281244802911789==-- From cisin@xenosoft.com Mon Nov 14 23:09:34 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 15:09:14 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5065362434676049030==" --===============5065362434676049030== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>> It's a lot less effort to tell them the sticker was illegal to begin with= .=20 >>> ;) >> . . . and have him have to escalate it to somebody authorized to make=20 >> exceptions, or argue with tandy lawyers? On Mon, 14 Nov 2022, geneb via cctalk wrote: > Nope. You point out that the state attorney(sp) general would love to watc= h=20 > Tandy flail against the Magnusson-Moss Warranty Act. ;) I encountered a lot of entities who would not willingly comply with=20 Manuson-Moss. (I was doing auto repair in the 1970s) Although it was=20 enacted in 1975, it took a long time for word to get around. And many=20 companies openly failed to comply, not just coming up with bizarre=20 scenarios to claim that the modification in some extremely roundabout way=20 caused the problem. For example, they could legally get away with claiming that adding a=20 trailer hitch to your car meant that you were towing, and stressing the=20 engine more than intended. Even if you CLAIMED that the hitch was for a=20 bike rack, or a flag for the local sports team. In theory, burden of=20 proof that a modification caused the problem would be on the dealer; but=20 in actuality, . . . And, of course, they would extrapolate that to=20 anything of the running gear of the car. But, when they deny warranty=20 coverage of the windshield wiper motor, then they were flagrantly=20 violating the act. In the EARLY years of the TRS80, Tandy actually believed that they could=20 void the warranty if you opened the case. Eventually, their lawyers=20 explained to them about Magnuson-Moss. Sometimes, it is GREAT to have=20 your adversary lawyer-up, since they will listen to their lawyer, even if=20 they won't believe you. YES, you would be legally correct, but trying to get that through to the=20 droids in the store could be difficult. And, the state attorney general=20 didn't always consider such to be a high priority. So, it was easier just to reseal the case. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5065362434676049030==-- From geneb@deltasoft.com Mon Nov 14 23:25:57 2022 From: geneb To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 15:25:34 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6445437707787507361==" --===============6445437707787507361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 14 Nov 2022, Fred Cisin via cctalk wrote: > In the EARLY years of the TRS80, Tandy actually believed that they could vo= id=20 > the warranty if you opened the case. Eventually, their lawyers explained t= o=20 > them about Magnuson-Moss. Sometimes, it is GREAT to have your adversary=20 > lawyer-up, since they will listen to their lawyer, even if they won't belie= ve=20 > you. > > YES, you would be legally correct, but trying to get that through to the=20 > droids in the store could be difficult. And, the state attorney general=20 > didn't always consider such to be a high priority. > So, it was easier just to reseal the case. > Yep. At least nowdays you can publically embarass companies that pull=20 crap like that - assuming they care of course. :) g. --=20 Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! --===============6445437707787507361==-- From cisin@xenosoft.com Mon Nov 14 23:41:58 2022 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 15:41:38 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4708804324991343376==" --===============4708804324991343376== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 14 Nov 2022, geneb via cctalk wrote: > Yep. At least nowdays you can publically embarass companies that pull crap > like that - assuming they care of course. :) I don't know the details; didn't Apple push through an "update" that would "brick" phones with third party replacement screens? Did somebody kick their ass? --===============4708804324991343376==-- From geneb@deltasoft.com Tue Nov 15 03:15:34 2022 From: geneb To: cctalk@classiccmp.org Subject: [cctalk] Re: 100% Tape Seal (soft kind) failure Date: Mon, 14 Nov 2022 19:15:11 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2630974646273335974==" --===============2630974646273335974== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 14 Nov 2022, Fred Cisin via cctalk wrote: > On Mon, 14 Nov 2022, geneb via cctalk wrote: >> Yep. At least nowdays you can publically embarass companies that pull cra= p=20 >> like that - assuming they care of course. :) > > I don't know the details; didn't Apple push through an "update" that would = > "brick" phones with third party replacement screens? > Did somebody kick their ass? > I think that was related to the fingerprint sensor. I didn't pay close=20 attention as I avoid that ecosystem whenever possible. ;) g. --=20 Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! --===============2630974646273335974==-- From a.carlini@ntlworld.com Tue Nov 15 10:06:56 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Tue, 15 Nov 2022 10:06:35 +0000 Message-ID: <112ae2b6-1b26-dddd-6e00-7f386809e11e@ntlworld.com> In-Reply-To: <16cd53c5-1298-2807-49fd-bcfc54787f37@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0280478717088013404==" --===============0280478717088013404== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 24/10/2022 21:07, Antonio Carlini via cctalk wrote: > the bitsbox one may be a teensy bit to large but the ebay one should > fit nicely. Neither is too expensive even with postage so I'll buy a > few, given that I do have a fair few PSUs knocking around. Just a quick follow-up in case it helps someone else down the line. I've put the system back together and the H7822 PSU seems to work: with the mainboard connected the green LED lights (and the fans spin). So that's good. The mainboard stays in the reset state (all diagnostic LEDs lit) so that might still be an issue with the PSU DC OK signal or the mainboard itself. However, at this stage the PSU is behaving as expected. Antonio -- Antonio Carlini antonio(a)acarlini.com --===============0280478717088013404==-- From cctalk@beyondthepale.ie Tue Nov 15 23:35:42 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Tue, 15 Nov 2022 23:22:12 +0000 Message-ID: <01SKDWMZ6P9U8WYOLI@beyondthepale.ie> In-Reply-To: <112ae2b6-1b26-dddd-6e00-7f386809e11e@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6566858686814779135==" --===============6566858686814779135== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 15/11/2022 10:06, Antonio Carlini via cctalk wrote: > On 24/10/2022 21:07, Antonio Carlini via cctalk wrote: >> the bitsbox one may be a teensy bit to large but the ebay one should >> fit nicely. Neither is too expensive even with postage so I'll buy a >> few, given that I do have a fair few PSUs knocking around. > > > Just a quick follow-up in case it helps someone else down the line. I've > put the system back together and the H7822 PSU seems to work: with the > mainboard connected the green LED lights (and the fans spin). So that's > good. > > The mainboard stays in the reset state (all diagnostic LEDs lit) so that > might still be an issue with the PSU DC OK signal or the mainboard > itself. However, at this stage the PSU is behaving as expected. > My experience with a H7822 is that when all the diagnostic LEDs stay lit, DC OK is probably not getting asserted so the power supply might still not be working 100% correctly. In the H7822, DC OK seems to be the purple lead and high (something around 4V-5V) means asserted. Regards, Peter Coghlan. > > > Antonio > > > -- > Antonio Carlini > antonio(a)acarlini.com > --===============6566858686814779135==-- From cctalk@ibm51xx.net Wed Nov 16 07:15:54 2022 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] ESD Bags Date: Tue, 15 Nov 2022 23:15:28 -0800 Message-ID: <004b01d8f98b$358fda60$a0af8f20$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2795567103215189286==" --===============2795567103215189286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, Does anyone have a REASONABLY priced source for 6" x 14" anti-static bags with zip lock tops? I've looked on eBay and Amazon with no luck. I have also looked online and have only found heat sealable bags. I am not sure if it is the sizing which the issue or what as other size bags seems to be easy to find. TIA! -Ali --===============2795567103215189286==-- From peterandersen@mespilus.dk Wed Nov 16 09:02:43 2022 From: Peter Andersen To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 08:52:57 +0100 Message-ID: <177392b5-13a5-44c0-b977-e9a27210d5d3@mespilus.dk> In-Reply-To: <004b01d8f98b$358fda60$a0af8f20$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1516879243934962446==" --===============1516879243934962446== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, buy from aliexpress.=C2=A0 Lots of them in different sizes and cheap. Peter Den 16. nov. 2022 08.16, fra 08.16, Ali via cctalk = skrev: >Hello, > >Does anyone have a REASONABLY priced source for 6" x 14" anti-static >bags >with zip lock tops? I've looked on eBay and Amazon with no luck. I have >also >looked online and have only found heat sealable bags. I am not sure if >it is >the sizing which the issue or what as other size bags seems to be easy >to >find. TIA! > >-Ali --===============1516879243934962446==-- From organlists1@sonic.net Wed Nov 16 09:53:08 2022 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 01:52:44 -0800 Message-ID: <81F0023D-F082-4890-9F02-0B07F5D20DE9@sonic.net> In-Reply-To: <177392b5-13a5-44c0-b977-e9a27210d5d3@mespilus.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2567557779695057411==" --===============2567557779695057411== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Amazon may be another option, especially if you have Prime. eBay might be an= other. Do the math though to be sure. Don Resor Sent from someone's iPhone > On Nov 16, 2022, at 1:02 AM, Peter Andersen via cctalk wrote: >=20 > =EF=BB=BFYes, buy from aliexpress. Lots of them in different sizes and che= ap. >=20 > Peter >=20 >=20 > Den 16. nov. 2022 08.16, fra 08.16, Ali via cctalk skrev: >> Hello, >>=20 >> Does anyone have a REASONABLY priced source for 6" x 14" anti-static >> bags >> with zip lock tops? I've looked on eBay and Amazon with no luck. I have >> also >> looked online and have only found heat sealable bags. I am not sure if >> it is >> the sizing which the issue or what as other size bags seems to be easy >> to >> find. TIA! >>=20 >> -Ali >=20 --===============2567557779695057411==-- From cctalk@gtaylor.tnetconsulting.net Wed Nov 16 12:45:28 2022 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 05:43:59 -0700 Message-ID: <6ecdceaa-1765-233e-095c-fe5c7094a3d9@spamtrap.tnetconsulting.net> In-Reply-To: <004b01d8f98b$358fda60$a0af8f20$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6697346532912835405==" --===============6697346532912835405== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/16/22 12:15 AM, Ali via cctalk wrote: > Hello, Hi, > Does anyone have a REASONABLY priced source for 6" x 14" anti-static > bags with zip lock tops? I've looked on eBay and Amazon with no > luck. I have also looked online and have only found heat sealable > bags. I am not sure if it is the sizing which the issue or what as > other size bags seems to be easy to find. TIA! I don't recall 6 x 14 bags, especially with zip lock tops, when I was recently looking for a recent need. Are you wanting to put full sized PC expansion cards in bags? I ended up buying bigger, (near) 12 x 14 non-zip-lock bags for my full sized cards. I simply wasted part of the bag, or put two cards in with a fold down the middle to separate them. ProTip: Put the component sides away from each other so that the boards lay together best. -- If you want to, put a piece of card board outside the bag between (like jelly) the two cards (bread) as a buffer. -- Grant. . . . unix || die --===============6697346532912835405==-- From elson@pico-systems.com Wed Nov 16 16:42:50 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 10:42:30 -0600 Message-ID: <7d1e9b28-cff8-d3a5-74f4-549b9fd6f696@pico-systems.com> In-Reply-To: <004b01d8f98b$358fda60$a0af8f20$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2459813381586540382==" --===============2459813381586540382== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/16/22 01:15, Ali via cctalk wrote: > Hello, > > Does anyone have a REASONABLY priced source for 6" x 14" anti-static bags > with zip lock tops? I've looked on eBay and Amazon with no luck. I have also > looked online and have only found heat sealable bags. I am not sure if it is > the sizing which the issue or what as other size bags seems to be easy to > find. TIA! > I buy shield bags from Digi-Key, but not the zip-lock style. I think Uline h= as them. Jon --===============2459813381586540382==-- From jdbryan@acm.org Wed Nov 16 20:50:13 2022 From: "J. David Bryan" To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 15:44:50 -0500 Message-ID: <20221116204951.D602081681@classiccmp.org> In-Reply-To: <004b01d8f98b$358fda60$a0af8f20$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5913176224742551453==" --===============5913176224742551453== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tuesday, November 15, 2022 at 23:15, Ali via cctalk wrote: > Does anyone have a REASONABLY priced source for 6" x 14" anti-static > bags with zip lock tops? I bought a few dozen in several sizes, with zip-lock and plain tops, a couple of years ago from McMaster-Carr. Search their site for "antistatic bags." -- Dave --===============5913176224742551453==-- From a.carlini@ntlworld.com Thu Nov 17 00:33:43 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Thu, 17 Nov 2022 00:33:21 +0000 Message-ID: <12f4312f-9cbb-60a1-61d5-92bbf02da726@ntlworld.com> In-Reply-To: <01SKDWMZ6P9U8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9136323448204558656==" --===============9136323448204558656== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 15/11/2022 23:22, Peter Coghlan via cctalk wrote: > My experience with a H7822 is that when all the diagnostic LEDs stay lit, > DC OK is probably not getting asserted so the power supply might still > not be working 100% correctly.  In the H7822, DC OK seems to be the > purple lead and high (something around 4V-5V) means asserted. Thanks, but sadly in this case it's not such a simple diagnosis. I had a spare 15 mins tonight so I powered it up and checked (DC OK is indeed the purple lead). DC OK is sitting at 5.13V so the problem lies elsewhere. I do have another H7822 in a MicroVAX 3100-80 (iirc, could be -40) and that one doesn't start either. I've done nothing with that one at all since it has a Dallas chip and so didn't need any remedial work. At some point I'll get back to these and spend some time trying to get them going. But I need to do some work on a Rainbow and some uV3600 PSUs first before I get back to working through uVAX/VS 3100 PSUs (I also have 5 H7821 PSUs there, so I expect that I'll be back ...). Antonio -- Antonio Carlini antonio(a)acarlini.com --===============9136323448204558656==-- From cctalk@ibm51xx.net Thu Nov 17 02:21:18 2022 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 18:20:54 -0800 Message-ID: <000301d8fa2b$390f4770$ab2dd650$@net> In-Reply-To: <6ecdceaa-1765-233e-095c-fe5c7094a3d9@spamtrap.tnetconsulting.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5599349295682040657==" --===============5599349295682040657== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 > I don't recall 6 x 14 bags, especially with zip lock tops, when I was > recently looking for a recent need. >=20 > Are you wanting to put full sized PC expansion cards in bags? Hi Grant, Yes. Looking for a catch all bag for cards from half to full size ISA/EISA/MC= A cards. I did find 6x14 heat seal bags but that doesn't work for me. I also = found some places that do manufacture them but they were all out of stock. >=20 > I ended up buying bigger, (near) 12 x 14 non-zip-lock bags for my full > sized cards. I simply wasted part of the bag, or put two cards in with > a fold down the middle to separate them. I am currently using 9 x 13 zippered ones. They work fine but cards are not s= nug. However, at $100 for $23 shipped I am not complaining too much. =20 > ProTip: Put the component sides away from each other so that the > boards > lay together best. -- If you want to, put a piece of card board > outside the bag between (like jelly) the two cards (bread) as a buffer. Thanks! -Ali --===============5599349295682040657==-- From cctalk@ibm51xx.net Thu Nov 17 02:23:13 2022 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: ESD Bags Date: Wed, 16 Nov 2022 18:22:51 -0800 Message-ID: <000501d8fa2b$7f1240b0$7d36c210$@net> In-Reply-To: <7d1e9b28-cff8-d3a5-74f4-549b9fd6f696@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3864174904151375377==" --===============3864174904151375377== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I buy shield bags from Digi-Key, but not the zip-lock style. I think > Uline has them. Not in this size. Most PCIe cards tend to be smaller in length and can be sig= nificantly thicker (think video cards) so the bags that would have fit ISA fu= ll length cards are no longer needed/manufactured. -Ali --===============3864174904151375377==-- From macro@orcam.me.uk Thu Nov 17 13:02:48 2022 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Thu, 17 Nov 2022 12:56:27 +0000 Message-ID: In-Reply-To: <01SJVEJ9132W8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0339833727214881382==" --===============0339833727214881382== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 2 Nov 2022, Peter Coghlan via cctalk wrote: > > Did you have to replace the power LED at all? I've just bench-tested the = PSU > > I've swapped the X2 cap in (luckily it powers up without a load, so all I > > did was hook up a DVM and check out the voltages), and I noticed that the > > LED didn't light. I'm pretty sure I connected it back (and it is keyed!) = so > > I think I may be looking for a replacement. Something in the back of my m= ind > > says that there is something that makes the replacement slightly non-triv= ial > > (funny LED, odd housing it fits in, some trick to getting it out ... I ca= n't > > remember unfortunately). > >=20 >=20 > The LED is more than just a power on indicator. When it fails to light, > it can indicate that something is not right in the PSU. It may tie in > with the "power good" output from the PSU. It does. I have an H7821 PSU where the LED lights briefly upon power-on=20 and then goes dark. The PSU cannot be used to power a mainboard as it=20 does not come up, however it works just fine with storage in an expansion=20 box. It is one of those that I recapped after leaks have appeared; in=20 fact it is the one that made me aware of the problem in the first place. =20 I'll have to get back to it sometime to get this sorted. > It could be that it is failing to light because the regulation is not > working properly because there is no load. I'd try it with a load > before anything else. The H7822 may need a load on both boards. There's a 2=CE=A9 dummy load on the 5V line in storage expansion boxes power= ed=20 by the H7821, so these do require minimum current to work correctly. > > BTW was it just the 1800uF 25V 105degC caps (mine are brown) that you had= to > > replace? Mine look fine but there are some other large electrolytics in > > there (two large brown 470uF voltage unclear, and one large black cap by = the > > mains input on which I cannot see any of the markings). > >=20 >=20 > It was only the 1800uF 25V capacitors were bad (mine are all brown too). > In an earlier posting I said there were six of them in a H7821 and ten of > them in a H7822. I should have said five in a H7821 and nine in a H7822. > The 470uF 400V capacitors in my units were all fine. Same here, five 1800uF 25V caps to replace in the H7821 according to my=20 notes. Overall if you spot a cap that says SXF on it, then replace it=20 right away whether already leaking or not. These were made by Chemi-con. =20 Other Chemi-con lines reported problematic are SXE and LXF, though from=20 own experience they seem less prone. Also Nichicon PL and PF parts may have to be replaced, I have seen the=20 former ones actually leaking in other DEC PSUs, such as the H7826, which=20 is also infested by SXF parts in various capacitances. Both kinds leaked=20 in a generic industrial Bel Power PSU used with a Cisco device. Sadly the problem with component shortage has hit capacitors as well and=20 some that used to be readily available are not anymore and prices have=20 risen too. NB I wasn't aware about the problem with RIFA capacitors, it seems like I=20 might have to replace them in several PSUs I have already recapped, sigh. =20 I haven't seen any of them fail though, not at least in an obvious way. HTH, Maciej --===============0339833727214881382==-- From spectre@floodgap.com Fri Nov 18 00:26:08 2022 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Apple AWACS register documentation Date: Thu, 17 Nov 2022 16:25:39 -0800 Message-ID: <3712fb78-0c55-45a8-d215-7efc89f64186@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7086956922721265855==" --===============7086956922721265855== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Any Apple alumni (Al?) with documentation on AWACS registers? I'm trying to figure out why the BeOS AWACS sound driver works on some Power Mac 6500s and TAMs but not others (but works fine on 6400s and everything previously). Yes, I'm aware that Be considered the 6500 "Unsupported but Compatible" and it boots fine on my 6500/275 but is totally mute. An instrumented driver in debug mode yielded little insight. The driver thinks it's initialized everything correctly and reports no errors. I wonder if there's something about the SRS sound enhancement that's different on later 6500s/TAMs. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- God made the integers; all else is the work of Man. -- Kronecker ---------= -- --===============7086956922721265855==-- From lewissa78@gmail.com Fri Nov 18 04:52:11 2022 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Looking for NORTRONICS Read/Write head for IBM 5100/5110/5106 tape unit Date: Thu, 17 Nov 2022 22:51:31 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1269158266484690551==" --===============1269158266484690551== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have a 5100 and 5106 both with a working tape unit. But the tape unit in my 5110 is not working, and I believe it is the read/write head. The REWIND command works, but the MARK command does not (ERR 3). I took the Tape Card from the 5110 and swapped it into the 5106, and the 5106 continued to work (and 5110 then had same result, ERR 3). This tells me the issue isn't any electronics in the Tape Card electronics (such as bad IC's). Swapping the electronics card is easy. But I haven't yet tried taking the read/write head from the 5106 and putting it into 5110's tape unit (they both use all the same components) -- it's not that difficult, but I don't really want to put a working 5106 at more risk of becoming non-working. Hence, that's why I'm asking around first if anyone might happen to have one of these NORTRONICS or a suitable substitute to try. For example, it may be the same kind of read/write head used in some reel-to-reel systems of that era (early/mid 1970s). The various numbers on the read/write head are as follows: NORTRONICS PN 1608752 C584980 269 24256 I have measurements and photos of what I'm looking for at the bottom of this link: https://voidstar.blog/ibm-5100-internal-tape-and-5106/ The head is about a 15mm x 20mm, with a 26mm ground extension on one side for mounting. A few months ago I contacted Nortronics. They had some stock that was close, but not this exact pin out (4-pins on one side, 6-pins on the other; not sure which is read vs write). I think all the ones they had were 4-pin/4-pin. I've also tried different brand tapes, DC6150 vs DC600A (which all of them do work in the 5100, but not the 5110). -Steve --===============1269158266484690551==-- From bkr@WildHareComputers.com Fri Nov 18 05:18:30 2022 From: Bruce Ray To: cctalk@classiccmp.org Subject: [cctalk] Re: Nova and Eclipse Emulator beta release Date: Thu, 17 Nov 2022 22:23:24 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8705111497352208551==" --===============8705111497352208551== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable G'day Jay - > - You mention that the emulator combines "the SimH project structure"=20 > with Wild Hare's commercial code.=C2=A0 I take this to mean that the emulat= or=20 > is an extension of simh to support the listed DG processors and=20 > devices.=C2=A0 Can you clarify which version (and ideally commit id) of sim= h=20 > is this based on? OpenSimH rev 4, simh git commit id: 009d748a > - I noticed that the license document available on the dgbeta=20 > page only covers the legacy=20 > software produced by DG.=C2=A0 Given the inclusion of commercial code in th= e=20 > simh executables, can you clarify what license the emulator binaries are=20 > released under? (Ideally this would be published along side the legacy=20 > license text). The standard SimH structure is used and its license is honored. >=20 > - Do you envision at some point publishing the simh emulator changes as=20 > a pull request to the simh project (presumably under the simh license)? The new Nova and Eclipse emulator, along with the commercial components,=20 will become part of the standard OpenSimH project and its license. > Again, thank you for your efforts here.=C2=A0 It's great to see this softwa= re=20 > opened up to hobbyist use. > --Jay >=20 >=20 > On 11/10/2022 5:47 PM, Bruce Ray via cctalk wrote: >> >> Wild Hare Computer Systems is pleased to announce the public beta=20 >> release of its Data General Nova and Eclipse emulator. >> >> This emulator allows the full range of DG 16-bit Nova and Eclipse=20 >> computer software to run on Microsoft Windows and Linux platforms, and=20 >> will become a major part of Wild Hare's increased efforts to preserve=20 >> Data General's significant contributions to computer history. >> >> The emulator combines portions of Wild Hare's commercial products with=20 >> the SimH project structure to create a single emulator for the 16-bit=20 >> Nova and Eclipse computers.=C2=A0 The program supports a wide range of=20 >> features, including: >> >> Processors: >> >> =C2=A0=C2=A0=C2=A0 unmapped Nova, SuperNova, Nova 1200, Nova 800, Nova 2, = Nova 3, Nova 4 >> =C2=A0=C2=A0=C2=A0 mapped Nova 840 >> =C2=A0=C2=A0=C2=A0 mapped Nova 3/D >> =C2=A0=C2=A0=C2=A0 mapped Nova 4/X >> =C2=A0=C2=A0=C2=A0 Eclipse S/130 >> =C2=A0=C2=A0=C2=A0 Eclipse S/140 >> =C2=A0=C2=A0=C2=A0 Eclipse S/150 >> =C2=A0=C2=A0=C2=A0 Eclipse S/120 >> =C2=A0=C2=A0=C2=A0 Eclipse Desktop Generation Model 20 and Model 30 >> >> >> Peripherals: >> >> =C2=A0=C2=A0=C2=A0 TTI/TTO=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prima= ry console (TeleType) input/output >> =C2=A0=C2=A0=C2=A0 RTC=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 real-time= clock >> =C2=A0=C2=A0=C2=A0 TTI1/TTO1=C2=A0=C2=A0=C2=A0 secondary console (TeleType= ) input/output >> =C2=A0=C2=A0=C2=A0 PTR=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 paper tap= e reader >> =C2=A0=C2=A0=C2=A0 PTP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 paper tap= e punch >> =C2=A0=C2=A0=C2=A0 PLT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 plotter >> =C2=A0=C2=A0=C2=A0 LPT=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 line prin= ter >> =C2=A0=C2=A0=C2=A0 MTA=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mag tape = unit >> =C2=A0=C2=A0=C2=A0 DSK=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fixed-hea= d disks >> =C2=A0=C2=A0=C2=A0 DKP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 moving he= ad disks >> =C2=A0=C2=A0=C2=A0 DEP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Desktop G= eneration disks >> =C2=A0=C2=A0=C2=A0 DZP=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 popular "= Zebra" moving head disks >> =C2=A0=C2=A0=C2=A0 QTY=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4060 "Qua= d" asynchronous multiplexers >> =C2=A0=C2=A0=C2=A0 ALM=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 4255 Asyn= chronous Line Multiplexers >> >> >> Software: >> >> =C2=A0=C2=A0=C2=A0 Operating Systems >> >> =C2=A0=C2=A0=C2=A0 DOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Novas (fi= rst DOS written for Nova) >> =C2=A0=C2=A0=C2=A0 URDOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RDOS fo= r Novas and Eclipses (in unmapped mode) >> =C2=A0=C2=A0=C2=A0 MRDOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RDOS fo= r Mapped Nova 840 >> =C2=A0=C2=A0=C2=A0 NRDOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RDOS fo= r Mapped Nova 3/D and Nova 4/X >> =C2=A0=C2=A0=C2=A0 ZRDOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RDOS fo= r Mapped Eclipses >> =C2=A0=C2=A0=C2=A0 MP/OS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nova 4 >> =C2=A0=C2=A0=C2=A0 DG/RDOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Eclip= ses >> =C2=A0=C2=A0=C2=A0 AOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Eclipses >> =C2=A0=C2=A0=C2=A0 MP/AOS=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Eclips= es >> >> =C2=A0=C2=A0=C2=A0 Languages >> >> =C2=A0=C2=A0=C2=A0 ASM (Assembler) >> =C2=A0=C2=A0=C2=A0 MAC (Macro Assembler) >> =C2=A0=C2=A0=C2=A0 ALGOL >> =C2=A0=C2=A0=C2=A0 DG/L >> =C2=A0=C2=A0=C2=A0 FORTRAN 4 >> =C2=A0=C2=A0=C2=A0 FORTRAN 5 >> =C2=A0=C2=A0=C2=A0 FORTRAN 77 >> =C2=A0=C2=A0=C2=A0 Extended BASIC >> =C2=A0=C2=A0=C2=A0 Business BASIC >> =C2=A0=C2=A0=C2=A0 MP Pascal >> =C2=A0=C2=A0=C2=A0 SP Pascal >> =C2=A0=C2=A0=C2=A0 COBOL >> =C2=A0=C2=A0=C2=A0 Interactive COBOL (ICOBOL) >> =C2=A0=C2=A0=C2=A0 PL/1 >> =C2=A0=C2=A0=C2=A0 RPG II >> =C2=A0=C2=A0=C2=A0 IDEA >> =C2=A0=C2=A0=C2=A0 INFOS II >> =C2=A0=C2=A0=C2=A0 CEO >> >> Prior Data General knowledge is beneficial to using the emulator and=20 >> corresponding DG software.=C2=A0 For convenience, Wild Hare has created=20 >> container files of pre-configured operating system environments and=20 >> their corresponding languages to minimize the time needed to enjoy the=20 >> full DG "experience". >> >> This "beta-level" software release is intended to gather user feedback=20 >> to help guide future product development.=C2=A0 Bug reports, comments,=20 >> suggestions, ridicule and giggles can be sent to=20 >> beta(a)WildHareComputers.com. >> >> Further information is contained in the emulator beta release web page: >> >> www.NovasAreForever.org/dgbeta >> >> >> >> Bruce Ray >> Wild Hare Computer Systems, Inc. >> Denver, Colorado USA >> bkr(a)WildHareComputers.com >> >> ...preserving the Data General legacy: www.NovasAreForever.org --===============8705111497352208551==-- From bkr@WildHareComputers.com Fri Nov 18 06:07:59 2022 From: Bruce Ray To: cctalk@classiccmp.org Subject: [cctalk] Re: Data General Nova and Eclipse Hobbyist License... Date: Thu, 17 Nov 2022 23:12:54 -0700 Message-ID: <37c4683c-2816-fcf8-5196-210cec2a8890@WildHareComputers.com> In-Reply-To: <2CEB2252-C151-4F60-9BFC-AE009ECFC4F1@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3477509516798189910==" --===============3477509516798189910== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It is not a sublicense, Wild Hare Computer Systems, Inc., now has=20 copyright and title to the legacy DG/EMC software. On 10/24/2022 5:35 PM, Paul Koning via cctalk wrote: > Very nice! So I take it that's a sublicense of Dell/EMC IP? It doesn't sa= y that. >=20 > paul >=20 >=20 >> On Oct 24, 2022, at 6:26 PM, Bruce Ray via cctalk wrote: >> >> >> Wild Hare Computer Systems, Inc., is pleased to announce that a >> "Hobbyist License" is now available for legacy Data General >> Nova and Eclipse software. This license allows educational, hobbyist, >> non-commercial use of the vast amount of DG software - software >> that changed the world in many ways. >> >> The initial archives are currently available at: >> >> www.NovasAreForever.org/dgsw >> >> and includes documentation for the corresponding software. >> >> >> This October announcement also honors the 54th anniversary of the original >> Data General Nova. An international celebration of the Nova's 50th anniver= sary was >> hosted by Wild Computer Systems in Colorado, USA. Some of the festivities >> can be seen at: >> >> www.Nova-At-50.org >> >> and >> >> www.Nova-At-50.org/album/index.html >> >> >> To complement this Hobbyist License, a Nova and Eclipse emulator that can = run all of the >> software will be introduced later this week. >> >> >> Wild Hare Computer Systems is dedicated to preserving Data General's >> significant contributions to computer history. We seek DG hardware, softw= are, documentation, >> sales literature - basically "anything DG" - that can be added to the >> archives for posterity. >> >> >> >> Bruce Ray >> Wild Hare Computer Systems, Inc. >> Denver, Colorado USA >> bkr(a)WildHareComputers.com >> >> ...preserving the Data General legacy: www.NovasAreForever.org >> >> www.WildHareComputers.com >> >> www.NovasAreForever.org >=20 --===============3477509516798189910==-- From cctalk@beyondthepale.ie Fri Nov 18 11:55:02 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Is this a RIFA (uV3100-10 PSU)? Date: Fri, 18 Nov 2022 10:51:47 +0000 Message-ID: <01SKHF6TWVVM8WYOLI@beyondthepale.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7730251269457479463==" --===============7730251269457479463== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Maciej W. Rozycki via cctalk wrote: > > Same here, five 1800uF 25V caps to replace in the H7821 according to my > notes. Overall if you spot a cap that says SXF on it, then replace it > right away whether already leaking or not. These were made by Chemi-con. > Other Chemi-con lines reported problematic are SXE and LXF, though from > own experience they seem less prone. > > Also Nichicon PL and PF parts may have to be replaced, I have seen the > former ones actually leaking in other DEC PSUs, such as the H7826, which > is also infested by SXF parts in various capacitances. Both kinds leaked > in a generic industrial Bel Power PSU used with a Cisco device. > I agree that all the 1800uF capacitors should be replaced whether leaking or not. When I first checked all my H7821 power supplies, I found some that looked absolutely fine. However, after I started using them for a while, problems began to show up and when I checked them again, they were leaking badly. > > Sadly the problem with component shortage has hit capacitors as well and > some that used to be readily available are not anymore and prices have > risen too. > Even if replacements are not available, I would suggest immediately removing any capacitors that are showing any signs of leakage and cleaning the affected area in order to limit damage from the leakage. > > NB I wasn't aware about the problem with RIFA capacitors, it seems like I > might have to replace them in several PSUs I have already recapped, sigh. > I haven't seen any of them fail though, not at least in an obvious way. > I wouldn't worry too much about the RIFAs. Their failure mode is to produce lots of smoke a short while after switch on. Apart from a bit of soot, they don't do any damage to anything else while the faulty electrolytics can do a considerable amount of damage without any visible external sign that anything is wrong. I haven't seen any failures of any of the RIFAs in my H7821 or H7822 power supplies and even if they are going to fail eventually, I am happy enough to wait for this to happen before doing anything about it because it will be obvious to me when they do fail and the consequences of their failure are not severe anyway. Regards, Peter Coghlan > > HTH, > > Maciej --===============7730251269457479463==-- From ccth6600@gmail.com Fri Nov 18 14:34:13 2022 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: Nova and Eclipse Emulator beta release Date: Fri, 18 Nov 2022 22:33:30 +0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5623976293020266201==" --===============5623976293020266201== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit G'day Bruce, Fantastic news about your hobbyist licensed software and manuals and now the Nova and Eclipse emulators becoming part of OpenSimh. The Windows & Linux binary only releases were difficult for some of us. I think now with an open-source emulator "Novas Are Forever" becomes a reality. :-) Best regards Tom On Fri, Nov 18, 2022 at 1:18 PM Bruce Ray via cctalk wrote: > G'day Jay - > > > - You mention that the emulator combines "the SimH project structure" > > with Wild Hare's commercial code. I take this to mean that the emulator > > is an extension of simh to support the listed DG processors and > > devices. Can you clarify which version (and ideally commit id) of simh > > is this based on? > > OpenSimH rev 4, simh git commit id: 009d748a > > > - I noticed that the license document available on the dgbeta > > page only covers the legacy > > software produced by DG. Given the inclusion of commercial code in the > > simh executables, can you clarify what license the emulator binaries are > > released under? (Ideally this would be published along side the legacy > > license text). > > The standard SimH structure is used and its license is honored. > > > > > - Do you envision at some point publishing the simh emulator changes as > > a pull request to the simh project (presumably under the simh license)? > > The new Nova and Eclipse emulator, along with the commercial components, > will become part of the standard OpenSimH project and its license. > > > > Again, thank you for your efforts here. It's great to see this software > > opened up to hobbyist use. > > --Jay > > > > > > On 11/10/2022 5:47 PM, Bruce Ray via cctalk wrote: > >> > >> Wild Hare Computer Systems is pleased to announce the public beta > >> release of its Data General Nova and Eclipse emulator. > >> > >> This emulator allows the full range of DG 16-bit Nova and Eclipse > >> computer software to run on Microsoft Windows and Linux platforms, and > >> will become a major part of Wild Hare's increased efforts to preserve > >> Data General's significant contributions to computer history. > >> > >> The emulator combines portions of Wild Hare's commercial products with > >> the SimH project structure to create a single emulator for the 16-bit > >> Nova and Eclipse computers. The program supports a wide range of > >> features, including: > >> > >> Processors: > >> > >> unmapped Nova, SuperNova, Nova 1200, Nova 800, Nova 2, Nova 3, Nova > 4 > >> mapped Nova 840 > >> mapped Nova 3/D > >> mapped Nova 4/X > >> Eclipse S/130 > >> Eclipse S/140 > >> Eclipse S/150 > >> Eclipse S/120 > >> Eclipse Desktop Generation Model 20 and Model 30 > >> > >> > >> Peripherals: > >> > >> TTI/TTO primary console (TeleType) input/output > >> RTC real-time clock > >> TTI1/TTO1 secondary console (TeleType) input/output > >> PTR paper tape reader > >> PTP paper tape punch > >> PLT plotter > >> LPT line printer > >> MTA mag tape unit > >> DSK fixed-head disks > >> DKP moving head disks > >> DEP Desktop Generation disks > >> DZP popular "Zebra" moving head disks > >> QTY 4060 "Quad" asynchronous multiplexers > >> ALM 4255 Asynchronous Line Multiplexers > >> > >> > >> Software: > >> > >> Operating Systems > >> > >> DOS Novas (first DOS written for Nova) > >> URDOS RDOS for Novas and Eclipses (in unmapped mode) > >> MRDOS RDOS for Mapped Nova 840 > >> NRDOS RDOS for Mapped Nova 3/D and Nova 4/X > >> ZRDOS RDOS for Mapped Eclipses > >> MP/OS Nova 4 > >> DG/RDOS Eclipses > >> AOS Eclipses > >> MP/AOS Eclipses > >> > >> Languages > >> > >> ASM (Assembler) > >> MAC (Macro Assembler) > >> ALGOL > >> DG/L > >> FORTRAN 4 > >> FORTRAN 5 > >> FORTRAN 77 > >> Extended BASIC > >> Business BASIC > >> MP Pascal > >> SP Pascal > >> COBOL > >> Interactive COBOL (ICOBOL) > >> PL/1 > >> RPG II > >> IDEA > >> INFOS II > >> CEO > >> > >> Prior Data General knowledge is beneficial to using the emulator and > >> corresponding DG software. For convenience, Wild Hare has created > >> container files of pre-configured operating system environments and > >> their corresponding languages to minimize the time needed to enjoy the > >> full DG "experience". > >> > >> This "beta-level" software release is intended to gather user feedback > >> to help guide future product development. Bug reports, comments, > >> suggestions, ridicule and giggles can be sent to > >> beta(a)WildHareComputers.com. > >> > >> Further information is contained in the emulator beta release web page: > >> > >> www.NovasAreForever.org/dgbeta > >> > >> > >> > >> Bruce Ray > >> Wild Hare Computer Systems, Inc. > >> Denver, Colorado USA > >> bkr(a)WildHareComputers.com > >> > >> ...preserving the Data General legacy: www.NovasAreForever.org > --===============5623976293020266201==-- From mloewen@cpumagic.scol.pa.us Fri Nov 18 16:39:58 2022 From: Mike Loewen To: cctalk@classiccmp.org Subject: [cctalk] Holmes Engineering CP/M Date: Fri, 18 Nov 2022 11:31:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7020146201598210727==" --===============7020146201598210727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I'm still looking for a copy of CP/M for the Holmes Engineering VID-80 board for the TRS-80 Model III. A manual would be helpful, as well. Mike Loewen mloewen(a)cpumagic.scol.pa.us Old Technology http://q7.neurotica.com/Oldtech/ --===============7020146201598210727==-- From rtomek@ceti.pl Sat Nov 19 02:34:30 2022 From: Tomasz Rola To: cctalk@classiccmp.org Subject: [cctalk] RIP Fred Brooks (1931-2022) Date: Sat, 19 Nov 2022 03:34:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4798714699998335294==" --===============4798714699998335294== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit As the subject (and wikipedia) say: https://en.wikipedia.org/wiki/Fred_Brooks -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com ** --===============4798714699998335294==-- From elson@pico-systems.com Sat Nov 19 03:13:39 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: RIP Fred Brooks (1931-2022) Date: Fri, 18 Nov 2022 21:13:19 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0985056540597563930==" --===============0985056540597563930== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/18/22 20:34, Tomasz Rola via cctalk wrote: > As the subject (and wikipedia) say: > > https://en.wikipedia.org/wiki/Fred_Brooks Oh my! I didn't realize he was still around, the Mythical Man Month was a fa= scinating read. The general concept was pretty obvious to anyone who develop= ed software in a group, but it pulled together a lot of interesting observati= ons and anecdotes. RIP indeed! Jon --===============0985056540597563930==-- From cclist@sydex.com Sat Nov 19 06:55:51 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RIP Fred Brooks (1931-2022) Date: Fri, 18 Nov 2022 22:46:25 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1732881891252421766==" --===============1732881891252421766== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/18/22 18:34, Tomasz Rola via cctalk wrote: > As the subject (and wikipedia) say: > > https://en.wikipedia.org/wiki/Fred_Brooks When I took a project management class at CDC, "The Mythical Man-month" was required course material. I had a manager who admonished me "A milestone is something tangible that I can hold in my hands and know that I'm not just handling empty promises or a mark on a Gantt chart". Sort of a Pope Julius in "The Agony and the Ecstasy". "When will you make an end?" --Chuck --===============1732881891252421766==-- From rdowns@radix.co.uk Sat Nov 19 10:26:17 2022 From: Robin Downs To: cctalk@classiccmp.org Subject: [cctalk] Help! Mentec and GRC DEC compatible manuals not in usual places... Date: Sat, 19 Nov 2022 10:25:48 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3554847984069037003==" --===============3554847984069037003== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi and thanks for reading... I am on the way to getting a small Q-Bus PDP11 up and running (I used to work= on and repair then in the 1980s) and have some boards and a chassis now, but= I cannot find any documentation for a couple of less common boards I have go= t - any help would be greatly appreciated - but I have looked in the usual pl= aces... The main issues are: Mentec M70 CPU - There are jumpers for serial port config and speed.. I have = got a glossy leaflet for it but no jumper info.. GRC MLV11 - two serial lines and 128KB memory, but configured with switches -= lots of switches... Also is anyone has any old Q-Bus parts in the UK (particularly any Baydel par= ts) that are looking for a good home, I would love to hear from you! Thanks for reading - any help or info much appreciated! Regards, Robin Downs Email: rdowns(a)radix.co.uk --===============3554847984069037003==-- From bill.gunshannon@hotmail.com Sat Nov 19 14:21:01 2022 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: RIP Fred Brooks (1931-2022) Date: Sat, 19 Nov 2022 09:20:34 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1191385443902085254==" --===============1191385443902085254== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/19/22 01:46, Chuck Guzis via cctalk wrote: > On 11/18/22 18:34, Tomasz Rola via cctalk wrote: >> As the subject (and wikipedia) say: >> >> https://en.wikipedia.org/wiki/Fred_Brooks > > When I took a project management class at CDC, "The Mythical Man-month" > was required course material. I had a manager who admonished me "A > milestone is something tangible that I can hold in my hands and know > that I'm not just handling empty promises or a mark on a Gantt chart". > And then, along came Agile.... bill --===============1191385443902085254==-- From couryhouse@aol.com Sun Nov 20 08:25:18 2022 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: RIP Fred Brooks (1931-2022) Date: Sun, 20 Nov 2022 08:24:48 +0000 Message-ID: <251232163.933947.1668932688958@mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7738927260573101481==" --===============7738927260573101481== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alas another one gone. Sent from the all new AOL app for Android=20 =20 On Fri, Nov 18, 2022 at 7:34 PM, Tomasz Rola via cctalk wrote: As the subject (and wikipedia) say: https://en.wikipedia.org/wiki/Fred_Brooks --=20 Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature.=C2=A0 =C2=A0 = =C2=A0 ** ** As the answer, master did "rm -rif" on the programmer's home=C2=A0 =C2=A0 = ** ** directory. And then the C programmer became enlightened...=C2=A0 =C2=A0 = =C2=A0 ** **=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ** ** Tomasz Rola=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mailto:tomasz_rola(a)bigfoot= .com=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ** =20 --===============7738927260573101481==-- From robert.jarratt@ntlworld.com Sun Nov 20 17:41:21 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 20 Nov 2022 17:40:55 +0000 Message-ID: <006901d8fd07$3e1e2130$ba5a6390$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5071518066867371897==" --===============5071518066867371897== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The H7842 PSU in my Rainbow failed yesterday. At first the machine just powered down and there was a slight burning smell, I wasn't next to the machine when this happened, so I didn't see or hear anything to tell me where the problem might be. Not being sure if there was a short in the machine or a problem in the PSU, I disconnected the fans, FDD and HDD and, probably foolishly, I applied power again to see if the machine would work. At this point there was a bang and a flash in the PSU. On opening up the H7842 power supply I found that one of the transistors had completely disintegrated. It looks to be the main switching transistor, here is a picture of it: https://rjarratt.files.wordpress.com/2022/11/img_20221120_165850.jpg. I have identified a source for this transistor, but if anyone can suggest a modern replacement that would be useful too. However, that is not my main problem. Given that before the transistor blew up there had clearly been another failure somewhere else, I tried to find the original failure. There were no obviously damaged parts, so I just probed around near the transistor for any parts that were open circuit or short circuit. I found a diode connected to the base of the transistor that appeared to be short circuit. So, I decided to lift one end to check it. As I de-soldered one of the leads, the diode broke in two. So clearly the diode was either damaged by the failure of the transistor, or it was the cause of the failure. This is the diode: https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. I can't quite make out the markings on the diode to know what to replace it with. I think it says "D610". Would that be the right designation? If so, can anyone suggest a suitable replacement please? The diode seems to connect an inductor to the base of the switching transistor and the collector of the transistor is connected to a transformer. Should I be looking for other failed parts? Not sure if the diode failed first and then caused the transistor to fail? Or if something else has failed which caused these parts to fail? I do know that there are no shorts in the Rainbow itself, because I have a spare PSU that still works fine in the same machine. I blogged this here (it repeats most of that I have said above): https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai lure/ Thanks Rob --===============5071518066867371897==-- From cctalk@beyondthepale.ie Sun Nov 20 18:52:42 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 20 Nov 2022 18:49:31 +0000 Message-ID: <01SKKMC7X5CG8WYOLI@beyondthepale.ie> In-Reply-To: <006901d8fd07$3e1e2130$ba5a6390$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1649366573324556363==" --===============1649366573324556363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Rob, I'm only guessing here. I think the sequence may have been that the main switching transistor failed first as it would be under more stress than a diode in the base circuit. If the transistor shorted E-B-C then the HT would become connected to the circuitry at it's base which would be compelely unable to cope with voltages and currents involved. This probably resulted in the failure of the diode. I think it may be worth looking at the components further back the drive chain from the diode. The inductor could be ok unless it is a very frail little thing but small signal semiconductor components and/or resistors further back may not have fared as well as it. It might also be worthwhile checking for shorted rectifiers on the output side in case this was the cause of the stress on the switching transistor. However, the power supply might have an overcurrent trip to reduce the possibility of this sort of damage. If there is an overcurrent trip or thermal trip, this may have been reset after the power supply was powered off for a while and when it was powered on again, the already damaged transistor could have been teed up to fail more spectacularly? Like I said, just guessing here. Were there no fuses failed or cutouts cut out? Does it look like there should have been? I would think a shorted switching transistor should have caused some safety device to operate. Or is it the case of the old adage that the faster acting transistor managed to sacrifice itself in time to protect the quick-blow fuse from blowing? Regards, Peter Coghlan. > > The H7842 PSU in my Rainbow failed yesterday. At first the machine just > powered down and there was a slight burning smell, I wasn't next to the > machine when this happened, so I didn't see or hear anything to tell me > where the problem might be. Not being sure if there was a short in the > machine or a problem in the PSU, I disconnected the fans, FDD and HDD and, > probably foolishly, I applied power again to see if the machine would work. > At this point there was a bang and a flash in the PSU. > > > > On opening up the H7842 power supply I found that one of the transistors had > completely disintegrated. It looks to be the main switching transistor, here > is a picture of it: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165850.jpg. I > have identified a source for this transistor, but if anyone can suggest a > modern replacement that would be useful too. However, that is not my main > problem. > > > > Given that before the transistor blew up there had clearly been another > failure somewhere else, I tried to find the original failure. There were no > obviously damaged parts, so I just probed around near the transistor for any > parts that were open circuit or short circuit. I found a diode connected to > the base of the transistor that appeared to be short circuit. So, I decided > to lift one end to check it. As I de-soldered one of the leads, the diode > broke in two. So clearly the diode was either damaged by the failure of the > transistor, or it was the cause of the failure. This is the diode: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. > > > > I can't quite make out the markings on the diode to know what to replace it > with. I think it says "D610". Would that be the right designation? If so, > can anyone suggest a suitable replacement please? > > > > The diode seems to connect an inductor to the base of the switching > transistor and the collector of the transistor is connected to a > transformer. Should I be looking for other failed parts? Not sure if the > diode failed first and then caused the transistor to fail? Or if something > else has failed which caused these parts to fail? > > > > I do know that there are no shorts in the Rainbow itself, because I have a > spare PSU that still works fine in the same machine. > > > > I blogged this here (it repeats most of that I have said above): > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai > lure/ > > > > Thanks > > > > Rob > --===============1649366573324556363==-- From robert.jarratt@ntlworld.com Sun Nov 20 20:37:30 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 20 Nov 2022 20:37:06 +0000 Message-ID: <007401d8fd1f$db226eb0$91674c10$@ntlworld.com> In-Reply-To: <01SKKMC7X5CG8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6674492495981972257==" --===============6674492495981972257== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Peter, Thanks for the analysis. There doesn't seem to be anything further back from the diode, unless you mean further back behind the inductor? I will check on the output side as you suggest. The circuit breaker did pop out when it failed. The onboard fuse is intact. The house RCD triggered and cut the power to the whole house when the transistor exploded! Do you, or anyone else, have an idea what the diode could be so that I can find a replacement. Like I said, it seems to be marked D610, and there are some other ones that look to be the same elsewhere in the PSU. Thanks Rob > -----Original Message----- > From: Peter Coghlan via cctalk > Sent: 20 November 2022 18:50 > To: General Discussion: On-Topic and Off-Topic Posts > > Cc: Peter Coghlan > Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power > Supply > > Hi Rob, > > I'm only guessing here. I think the sequence may have been that the main > switching transistor failed first as it would be under more stress than a diode > in the base circuit. If the transistor shorted E-B-C then the HT would become > connected to the circuitry at it's base which would be compelely unable to > cope with voltages and currents involved. This probably resulted in the > failure of the diode. I think it may be worth looking at the components > further back the drive chain from the diode. > The inductor could be ok unless it is a very frail little thing but small signal > semiconductor components and/or resistors further back may not have > fared as well as it. > > It might also be worthwhile checking for shorted rectifiers on the output side > in case this was the cause of the stress on the switching transistor. > However, the power supply might have an overcurrent trip to reduce the > possibility of this sort of damage. If there is an overcurrent trip or thermal > trip, this may have been reset after the power supply was powered off for a > while and when it was powered on again, the already damaged transistor > could have been teed up to fail more spectacularly? Like I said, just guessing > here. > > Were there no fuses failed or cutouts cut out? Does it look like there should > have been? I would think a shorted switching transistor should have caused > some safety device to operate. Or is it the case of the old adage that the > faster acting transistor managed to sacrifice itself in time to protect the quick- > blow fuse from blowing? > > Regards, > Peter Coghlan. > > > > > The H7842 PSU in my Rainbow failed yesterday. At first the machine > > just powered down and there was a slight burning smell, I wasn't next > > to the machine when this happened, so I didn't see or hear anything to > > tell me where the problem might be. Not being sure if there was a > > short in the machine or a problem in the PSU, I disconnected the fans, > > FDD and HDD and, probably foolishly, I applied power again to see if the > machine would work. > > At this point there was a bang and a flash in the PSU. > > > > > > > > On opening up the H7842 power supply I found that one of the > > transistors had completely disintegrated. It looks to be the main > > switching transistor, here is a picture of it: > > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165850.jpg. > > I have identified a source for this transistor, but if anyone can > > suggest a modern replacement that would be useful too. However, that > > is not my main problem. > > > > > > > > Given that before the transistor blew up there had clearly been > > another failure somewhere else, I tried to find the original failure. > > There were no obviously damaged parts, so I just probed around near > > the transistor for any parts that were open circuit or short circuit. > > I found a diode connected to the base of the transistor that appeared > > to be short circuit. So, I decided to lift one end to check it. As I > > de-soldered one of the leads, the diode broke in two. So clearly the > > diode was either damaged by the failure of the transistor, or it was the > cause of the failure. This is the diode: > > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. > > > > > > > > I can't quite make out the markings on the diode to know what to > > replace it with. I think it says "D610". Would that be the right > > designation? If so, can anyone suggest a suitable replacement please? > > > > > > > > The diode seems to connect an inductor to the base of the switching > > transistor and the collector of the transistor is connected to a > > transformer. Should I be looking for other failed parts? Not sure if > > the diode failed first and then caused the transistor to fail? Or if > > something else has failed which caused these parts to fail? > > > > > > > > I do know that there are no shorts in the Rainbow itself, because I > > have a spare PSU that still works fine in the same machine. > > > > > > > > I blogged this here (it repeats most of that I have said above): > > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power- > supp > > ly-fai > > lure/ > > > > > > > > Thanks > > > > > > > > Rob > > --===============6674492495981972257==-- From a.carlini@ntlworld.com Sun Nov 20 20:38:44 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 20 Nov 2022 20:38:24 +0000 Message-ID: In-Reply-To: <006901d8fd07$3e1e2130$ba5a6390$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6694428556520421656==" --===============6694428556520421656== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 20/11/2022 17:40, Rob Jarratt via cctalk wrote: > The H7842 PSU in my Rainbow failed yesterday. At first the machine just > powered down and there was a slight burning smell, I wasn't next to the > machine when this happened, so I didn't see or hear anything to tell me > where the problem might be. Not being sure if there was a short in the > machine or a problem in the PSU, I disconnected the fans, FDD and HDD and, > probably foolishly, I applied power again to see if the machine would work. > At this point there was a bang and a flash in the PSU. > > > > I blogged this here (it repeats most of that I have said above): > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai > lure/ > I have Rainbow PSUs H7842A, H78420 (which I suspect I may have misread! ...) and H7842D available. I can look tomorrow; if you can supply an overview picture and maybe circle the location of the offending parts that might help me identify them more quickly (always assuming that they are marked at all, of course). Antonio -- Antonio Carlini antonio(a)acarlini.com --===============6694428556520421656==-- From robert.jarratt@ntlworld.com Sun Nov 20 21:03:34 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 20 Nov 2022 21:03:15 +0000 Message-ID: <007501d8fd23$828449a0$878cdce0$@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1119548769321632770==" --===============1119548769321632770== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Antonio, The location of the diode is arrowed on this picture: https://rjarratt.files.= wordpress.com/2022/11/img_20221120_205802-arrowed.jpg You can also see the heatsink where the transistor used to be. Regards Rob > -----Original Message----- > From: Antonio Carlini via cctalk > Sent: 20 November 2022 20:38 > To: Rob Jarratt via cctalk > Cc: Antonio Carlini > Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power > Supply >=20 > On 20/11/2022 17:40, Rob Jarratt via cctalk wrote: > > The H7842 PSU in my Rainbow failed yesterday. At first the machine > > just powered down and there was a slight burning smell, I wasn't next > > to the machine when this happened, so I didn't see or hear anything to > > tell me where the problem might be. Not being sure if there was a > > short in the machine or a problem in the PSU, I disconnected the fans, > > FDD and HDD and, probably foolishly, I applied power again to see if the > machine would work. > > At this point there was a bang and a flash in the PSU. > > > > >=20 > > > > I blogged this here (it repeats most of that I have said above): > > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power- > supp > > ly-fai > > lure/ > > >=20 > I have Rainbow PSUs H7842A, H78420 (which I suspect I may have misread! > ...) and H7842D available. I can look tomorrow; if you can supply an overvi= ew > picture and maybe circle the location of the offending parts that might help > me identify them more quickly (always assuming that they are marked at all, > of course). >=20 >=20 > Antonio >=20 >=20 > -- > Antonio Carlini > antonio(a)acarlini.com --===============1119548769321632770==-- From wscharer@gmail.com Sun Nov 20 21:45:59 2022 From: Whitney Scharer To: cctalk@classiccmp.org Subject: [cctalk] digital group's Richard Bemis Date: Fri, 18 Nov 2022 14:58:23 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8808448893964846863==" --===============8808448893964846863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Brad, I just came across your post from last year about my father, Richard C. Bemis. He passed away in June. I wish I knew more about the digital group and would love to see the video or article you are working on. I can also fill you in on what my dad did after dg. Thanks, Whitney ___ Whitney Scharer *The Age of Light* Order today from Bookshop.org or Amazon whitneyscharer.com | @wscharer | instagram.com/wscharer --===============8808448893964846863==-- From cctalk@beyondthepale.ie Mon Nov 21 01:28:22 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Mon, 21 Nov 2022 00:10:26 +0000 Message-ID: <01SKKZPNW02G8WYOLI@beyondthepale.ie> In-Reply-To: <007401d8fd1f$db226eb0$91674c10$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8004868242457353697==" --===============8004868242457353697== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Rob, > > Thanks for the analysis. There doesn't seem to be anything further back from > the diode, unless you mean further back behind the inductor? > I probably do. I guess the base drive for the main switching transistor comes from another smaller transistor via the inductor and the diode which failed? Or maybe the diode is in parallel across the drive voltage? Anyway, it is this smaller transistor providing the drive that I'm suggesting checking next as it may have got a belt of anything up to three hundred and something volts DC when the main switching transistor shorted out an instant before it exploded. If that one has failed too, check further back to whatever is driving it. > > I will check on the output side as you suggest. > The rectifiers on the output side may be tedious to figure out and test due in part to the very low resistances of the transformer windings feeding them unfortunately, especially if there are double rectifiers (maybe in packages which look suspiciously like transistors) connected to either side of centre tapped transformer windings. > > The circuit breaker did pop out when it failed. The onboard fuse is intact. > If you mean the house breaker as opposed to a breaker in the power supply, I would guess it was probably rated at 25A or more and given the destruction of the transistor, I would think the instantaneous current was way higher than that. Perhaps the fuse is a time delay one. It seems likely things could have been worse if the breaker wasn't able to cut the power as soon as it did and you had to wait for the fuse to blow :-( > > The house RCD triggered and cut the power to the whole house when the > transistor exploded! > I guess that the transistor exploding produced a momentary cloud of ionised gas which allowed arcing/tracking from the live transistor terminals to something earthed (power supply case maybe?) which triggered the RCD. Or maybe the heatsink the switching transistor is mounted on is earthed and the insulating washer between the heatsink and the transistor failed causing it's destruction and the heatsink then became the path to earth that triggered the RCD? > > Do you, or anyone else, have an idea what the diode could be so that I can > find a replacement. Like I said, it seems to be marked D610, and there are > some other ones that look to be the same elsewhere in the PSU. > Sorry, I have no idea what the diode is. Hopefully Antonio will be able to help with that. Or if your spare power supply is the same design as the failed one, can you look at the diode in that one? It has dawned on me that another mechanism for the switching transistor to have failed so spectacularly is for it to have been switched on hard and held on for more than an instant by something driving it resulting in it effectively shorting out the rectified mains supply through the primary of the chopper transformer. When you next try powering it up, it might be good to use the old (filament) light bulb in series with the mains supply trick in case whatever caused the initial problem is still lurking in there. This can be useful for locating shorted output rectifiers too. You might see a slight voltage rise from the outputs with working rectifiers when power is applied through the light bulb and a lesser or no voltage rise on an output which has a shorted rectifier or other issue that needs closer inspection. It also means there is no need to hide behind the sofa when you switch it on :-) Regards, Peter. > > Thanks > > Rob > > > -----Original Message----- > > From: Peter Coghlan via cctalk > > Sent: 20 November 2022 18:50 > > To: General Discussion: On-Topic and Off-Topic Posts > > > > Cc: Peter Coghlan > > Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power > > Supply > > > > Hi Rob, > > > > I'm only guessing here. I think the sequence may have been that the main > > switching transistor failed first as it would be under more stress than a > diode > > in the base circuit. If the transistor shorted E-B-C then the HT would > become > > connected to the circuitry at it's base which would be compelely unable to > > cope with voltages and currents involved. This probably resulted in the > > failure of the diode. I think it may be worth looking at the components > > further back the drive chain from the diode. > > The inductor could be ok unless it is a very frail little thing but small > signal > > semiconductor components and/or resistors further back may not have > > fared as well as it. > > > > It might also be worthwhile checking for shorted rectifiers on the output > side > > in case this was the cause of the stress on the switching transistor. > > However, the power supply might have an overcurrent trip to reduce the > > possibility of this sort of damage. If there is an overcurrent trip or > thermal > > trip, this may have been reset after the power supply was powered off for > a > > while and when it was powered on again, the already damaged transistor > > could have been teed up to fail more spectacularly? Like I said, just > guessing > > here. > > > > Were there no fuses failed or cutouts cut out? Does it look like there > should > > have been? I would think a shorted switching transistor should have caused > > some safety device to operate. Or is it the case of the old adage that > the > > faster acting transistor managed to sacrifice itself in time to protect > the quick- > > blow fuse from blowing? > > > > Regards, > > Peter Coghlan. > > > > > > > > The H7842 PSU in my Rainbow failed yesterday. At first the machine > > > just powered down and there was a slight burning smell, I wasn't next > > > to the machine when this happened, so I didn't see or hear anything to > > > tell me where the problem might be. Not being sure if there was a > > > short in the machine or a problem in the PSU, I disconnected the fans, > > > FDD and HDD and, probably foolishly, I applied power again to see if the > > machine would work. > > > At this point there was a bang and a flash in the PSU. > > > > > > > > > > > > On opening up the H7842 power supply I found that one of the > > > transistors had completely disintegrated. It looks to be the main > > > switching transistor, here is a picture of it: > > > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165850.jpg. > > > I have identified a source for this transistor, but if anyone can > > > suggest a modern replacement that would be useful too. However, that > > > is not my main problem. > > > > > > > > > > > > Given that before the transistor blew up there had clearly been > > > another failure somewhere else, I tried to find the original failure. > > > There were no obviously damaged parts, so I just probed around near > > > the transistor for any parts that were open circuit or short circuit. > > > I found a diode connected to the base of the transistor that appeared > > > to be short circuit. So, I decided to lift one end to check it. As I > > > de-soldered one of the leads, the diode broke in two. So clearly the > > > diode was either damaged by the failure of the transistor, or it was the > > cause of the failure. This is the diode: > > > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. > > > > > > > > > > > > I can't quite make out the markings on the diode to know what to > > > replace it with. I think it says "D610". Would that be the right > > > designation? If so, can anyone suggest a suitable replacement please? > > > > > > > > > > > > The diode seems to connect an inductor to the base of the switching > > > transistor and the collector of the transistor is connected to a > > > transformer. Should I be looking for other failed parts? Not sure if > > > the diode failed first and then caused the transistor to fail? Or if > > > something else has failed which caused these parts to fail? > > > > > > > > > > > > I do know that there are no shorts in the Rainbow itself, because I > > > have a spare PSU that still works fine in the same machine. > > > > > > > > > > > > I blogged this here (it repeats most of that I have said above): > > > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power- > > supp > > > ly-fai > > > lure/ > > > > > > > > > > > > Thanks > > > > > > > > > > > > Rob > > > --===============8004868242457353697==-- From toby@telegraphics.net Mon Nov 21 02:25:51 2022 From: Toby Thain To: cctalk@classiccmp.org Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing Date: Sun, 20 Nov 2022 21:25:30 -0500 Message-ID: <72b565c3-c514-2495-2aec-3b0521fd073b@telegraphics.net> In-Reply-To: <9ca64844-3a4e-bc12-89b9-8e597324a7c6@telegraphics.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7209661724878214513==" --===============7209661724878214513== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2022-11-05 8:50 p.m., Toby Thain via cctalk wrote: > On 2022-11-05 6:38 p.m., Dave Wade G4UGM via cctalk wrote: >> Toby, >> I think you can subscribe here:- >> >> https://www.classiccmp.org/mailman3/postorius/lists/cctalk.classiccmp.org/ >> >> > > > I'll try that, but Google led me to this page where I had the problem: > > https://classiccmp.org/cctalk.html > > @ list owner, Please consider this a bug report -- the old non functioning page is causing confusion because google, for one thing, takes people there. Can it be removed? --Toby > > --Toby > > >> Dave >> >>> -----Original Message----- >>> From: Toby Thain via cctalk >>> Sent: 05 November 2022 21:46 >>> To: General Discussion: On-Topic and Off-Topic Posts >>> >>> Cc: Toby Thain >>> Subject: [cctalk] To cctalk owner: There's a problem subscribing >>> >>> Clicking Subscribe goes to a Not Found page. >>> >>> I found this out because I'm trying to subscribe with a new email >>> address. >>> >>> >>> --Toby >> > --===============7209661724878214513==-- From drb@msu.edu Mon Nov 21 03:13:58 2022 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing Date: Sun, 20 Nov 2022 22:13:39 -0500 Message-ID: <20221121031339.3CECA2C4866@yagi.h-net.msu.edu> In-Reply-To: <72b565c3-c514-2495-2aec-3b0521fd073b@telegraphics.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0965061590327533142==" --===============0965061590327533142== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Please consider this a bug report -- the old non functioning page is > causing confusion because google, for one thing, takes people > there. Can it be removed? Fixed. De --===============0965061590327533142==-- From toby@telegraphics.net Mon Nov 21 15:14:28 2022 From: Toby Thain To: cctalk@classiccmp.org Subject: [cctalk] Re: To cctalk owner: There's a problem subscribing Date: Mon, 21 Nov 2022 10:14:05 -0500 Message-ID: <49637f5d-0fc7-c74d-3303-704601fddb33@telegraphics.net> In-Reply-To: <20221121031339.3CECA2C4866@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2539787320145191245==" --===============2539787320145191245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2022-11-20 10:13 p.m., Dennis Boone via cctalk wrote: > > Please consider this a bug report -- the old non functioning page is > > causing confusion because google, for one thing, takes people > > there. Can it be removed? > > Fixed. > > De Thanks! --Toby --===============2539787320145191245==-- From a.carlini@ntlworld.com Mon Nov 21 21:45:56 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Mon, 21 Nov 2022 21:45:30 +0000 Message-ID: <66f562f9-75c2-a1f0-4840-a5d14db5afe7@ntlworld.com> In-Reply-To: <007501d8fd23$828449a0$878cdce0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4831513866759062003==" --===============4831513866759062003== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20/11/2022 21:03, Rob Jarratt wrote: > Thanks Antonio, > > The location of the diode is arrowed on this picture: https://rjarratt.file= s.wordpress.com/2022/11/img_20221120_205802-arrowed.jpg > > You can also see the heatsink where the transistor used to be. This is mine:=20 https://drive.google.com/file/d/1igM9AqrICX93t-KHH3N4gRCr1Z8H6tAY/view?usp=3D= share_link,=20 so as you can see, the pick-and-place machine decided to rotate the=20 diode for almost maximum inconvenience! I have two more I can open up and look at, but I cannot get to them=20 tonight and I'm probably out tomorrow too. But I think I can get to=20 those other two supplies on Wednesday. Hopefully at least one of them=20 will be readable! Otherwise I can desolder the diode from one of the=20 other two and hopefully find a useful marking. Antonio --=20 Antonio Carlini antonio(a)acarlini.com --===============4831513866759062003==-- From mattislind@gmail.com Tue Nov 22 07:54:53 2022 From: Mattis Lind To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Tue, 22 Nov 2022 08:54:19 +0100 Message-ID: In-Reply-To: <006901d8fd07$3e1e2130$ba5a6390$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3613292840060913428==" --===============3613292840060913428== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Rob! > > Given that before the transistor blew up there had clearly been another > failure somewhere else, I tried to find the original failure. There were no > obviously damaged parts, so I just probed around near the transistor for > any > parts that were open circuit or short circuit. I found a diode connected to > the base of the transistor that appeared to be short circuit. So, I decided > to lift one end to check it. As I de-soldered one of the leads, the diode > broke in two. So clearly the diode was either damaged by the failure of the > transistor, or it was the cause of the failure. This is the diode: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. > > > DEC used a lot of A114x diodes in their PSUs. They looked exactly like that one. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet-pdf/view/7563180/2074/A114F.html I would replace it with a UF4007 or something similar. https://www.mouser.se/datasheet/2/849/uf4001-2578577.pdf > > I can't quite make out the markings on the diode to know what to replace it > with. I think it says "D610". Would that be the right designation? If so, > can anyone suggest a suitable replacement please? > > > > The diode seems to connect an inductor to the base of the switching > transistor and the collector of the transistor is connected to a > transformer. Should I be looking for other failed parts? Not sure if the > diode failed first and then caused the transistor to fail? Or if something > else has failed which caused these parts to fail? > Also check all other semiconductors. Also on the outputs. If there is a 1 ohm fusible resistor in the base drive circuit check that one as well. In the VT100 PSUs it happens that it blows. > > > > I do know that there are no shorts in the Rainbow itself, because I have a > spare PSU that still works fine in the same machine. > > > > I blogged this here (it repeats most of that I have said above): > > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai > lure/ > > > > /Mattis > > Thanks > > > > Rob > > --===============3613292840060913428==-- From matt@9track.net Wed Nov 23 02:56:18 2022 From: Matt Burke To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Wed, 23 Nov 2022 00:31:35 +0000 Message-ID: <794216db-b59a-02e0-8114-6fd6fe21bc9f@9track.net> In-Reply-To: <007501d8fd23$828449a0$878cdce0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1495008455207020302==" --===============1495008455207020302== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20/11/2022 21:03, Rob Jarratt via cctalk wrote: > The location of the diode is arrowed on this picture: https://rjarratt.file= s.wordpress.com/2022/11/img_20221120_205802-arrowed.jpg > > You can also see the heatsink where the transistor used to be. The component you refer to as an inductor is actually a transformer, providing isolation between the control PCB (riser card) and the switching transistor. As such the control circuitry should not have been harmed by the failure of the transistor. You can test the control circuitry by applying about 15V from a bench supply to the purple capacitor shown in the picture. This is the 2200uF capacitor shown on "PSU sheet 1" of Tony Duell's schematics (available on Bitsavers). You will then be able to see the switching drive signal on the left hand pin of the control PCB. On "PSU sheet 2" I'm assuming that the diode in question is the one in parallel with the 2.7R resistor. My guess is that it is there to provide fast turn-off of the switching transistor. If it were to fail then that would lead to slower turn-off and probably overheating of the transistor. That may explain the failure. Other components to check are the ones in the snubber circuit. This is the two 500R resistors and associated diode and capacitor connected to the collector. Matt --===============1495008455207020302==-- From a.carlini@ntlworld.com Wed Nov 23 20:04:27 2022 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Wed, 23 Nov 2022 20:04:05 +0000 Message-ID: <605634e2-f43b-7dfe-ed84-a230c82ffff5@ntlworld.com> In-Reply-To: <66f562f9-75c2-a1f0-4840-a5d14db5afe7@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8796656056079898865==" --===============8796656056079898865== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 21/11/2022 21:45, Antonio Carlini wrote: > > I have two more I can open up and look at, but I cannot get to them=20 > tonight and I'm probably out tomorrow too. But I think I can get to=20 > those other two supplies on Wednesday. Hopefully at least one of them=20 > will be readable! Otherwise I can desolder the diode from one of the=20 > other two and hopefully find a useful marking. Turns out I have three more PSUs ... and the diode markings are=20 unfortunately invisible on all but one. That one is this one: https://drive.google.com/file/d/1TeGTcBBv7KecMJ2CmNcR0O-tb3jZigy6/view?usp=3D= share_link It's not really visible there either but with the PSU out and one end=20 desoldered I can see that it is marked H9501. I can also see that it=20 doesn't conduct either way, which might mean that this PSU is the=20 non-working one I know I have. Obviously the capacitor (820uF 250V=20 electrolytic) is going to need replacing (might as well do both). But=20 first I need to remove them and see what (if anything has happened)=20 underneath. This now goes back into my queue (behind the MicroVAXes and the H7868B=20 PSU modules) so if you fix yours before I get to mine, please let me=20 know what you did :-) Antonio --=20 Antonio Carlini antonio(a)acarlini.com --===============8796656056079898865==-- From organlists1@sonic.net Wed Nov 23 21:00:51 2022 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Wed, 23 Nov 2022 13:00:27 -0800 Message-ID: <3B2114C0-0A8D-4C38-8CEF-518A24931A50@sonic.net> In-Reply-To: <605634e2-f43b-7dfe-ed84-a230c82ffff5@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5615291938705045011==" --===============5615291938705045011== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable NTE seems to turn up these possibilities for a H9501. https://www.nteinc.com/search/search/search.php?ss360Query=3DH5901 Don Resor Sent from someone's iPhone > On Nov 23, 2022, at 12:04 PM, Antonio Carlini via cctalk wrote: >=20 > =EF=BB=BFOn 21/11/2022 21:45, Antonio Carlini wrote: >>=20 >> I have two more I can open up and look at, but I cannot get to them tonigh= t and I'm probably out tomorrow too. But I think I can get to those other two= supplies on Wednesday. Hopefully at least one of them will be readable! Othe= rwise I can desolder the diode from one of the other two and hopefully find a= useful marking. >=20 >=20 > Turns out I have three more PSUs ... and the diode markings are unfortunate= ly invisible on all but one. That one is this one: >=20 > https://drive.google.com/file/d/1TeGTcBBv7KecMJ2CmNcR0O-tb3jZigy6/view?usp= =3Dshare_link >=20 >=20 > It's not really visible there either but with the PSU out and one end desol= dered I can see that it is marked H9501. I can also see that it doesn't condu= ct either way, which might mean that this PSU is the non-working one I know I= have. Obviously the capacitor (820uF 250V electrolytic) is going to need rep= lacing (might as well do both). But first I need to remove them and see what = (if anything has happened) underneath. >=20 >=20 > This now goes back into my queue (behind the MicroVAXes and the H7868B PSU = modules) so if you fix yours before I get to mine, please let me know what yo= u did :-) >=20 >=20 > Antonio >=20 >=20 > --=20 > Antonio Carlini > antonio(a)acarlini.com >=20 --===============5615291938705045011==-- From organlists1@sonic.net Wed Nov 23 21:08:30 2022 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Wed, 23 Nov 2022 13:08:04 -0800 Message-ID: <9E35B26D-FF30-4DE2-A5A9-F6C5606C6A3C@sonic.net> In-Reply-To: <3B2114C0-0A8D-4C38-8CEF-518A24931A50@sonic.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3606631614889979234==" --===============3606631614889979234== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This data sheet may prove to be more useful. https://www.nteinc.com/specs/5800to5899/pdf/nte5892_99.pdf Don Resor Sent from someone's iPhone > On Nov 23, 2022, at 1:00 PM, Don R wrote: >=20 > =EF=BB=BFNTE seems to turn up these possibilities for a H9501. >=20 > https://www.nteinc.com/search/search/search.php?ss360Query=3DH5901 >=20 > Don Resor >=20 > Sent from someone's iPhone >=20 >>> On Nov 23, 2022, at 12:04 PM, Antonio Carlini via cctalk wrote: >>>=20 >> =EF=BB=BFOn 21/11/2022 21:45, Antonio Carlini wrote: >>>=20 >>> I have two more I can open up and look at, but I cannot get to them tonig= ht and I'm probably out tomorrow too. But I think I can get to those other tw= o supplies on Wednesday. Hopefully at least one of them will be readable! Oth= erwise I can desolder the diode from one of the other two and hopefully find = a useful marking. >>=20 >>=20 >> Turns out I have three more PSUs ... and the diode markings are unfortunat= ely invisible on all but one. That one is this one: >>=20 >> https://drive.google.com/file/d/1TeGTcBBv7KecMJ2CmNcR0O-tb3jZigy6/view?usp= =3Dshare_link >>=20 >>=20 >> It's not really visible there either but with the PSU out and one end deso= ldered I can see that it is marked H9501. I can also see that it doesn't cond= uct either way, which might mean that this PSU is the non-working one I know = I have. Obviously the capacitor (820uF 250V electrolytic) is going to need re= placing (might as well do both). But first I need to remove them and see what= (if anything has happened) underneath. >>=20 >>=20 >> This now goes back into my queue (behind the MicroVAXes and the H7868B PSU= modules) so if you fix yours before I get to mine, please let me know what y= ou did :-) >>=20 >>=20 >> Antonio >>=20 >>=20 >> --=20 >> Antonio Carlini >> antonio(a)acarlini.com >>=20 --===============3606631614889979234==-- From cctalk@beyondthepale.ie Thu Nov 24 00:32:14 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Thu, 24 Nov 2022 00:26:47 +0000 Message-ID: <01SKP533MBNM8WYOLI@beyondthepale.ie> In-Reply-To: <3B2114C0-0A8D-4C38-8CEF-518A24931A50@sonic.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7370396709905976002==" --===============7370396709905976002== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Don, Does the url suggest you may have searched for a H5901 rather than a H9501? Regards, Peter Coghlan. > > NTE seems to turn up these possibilities for a H9501. >=20 > https://www.nteinc.com/search/search/search.php?ss360Query=3DH5901 >=20 > Don Resor >=20 > Sent from someone's iPhone >=20 >> On Nov 23, 2022, at 12:04 PM, Antonio Carlini via cctalk wrote: >>=20 >> =EF=BB=BFOn 21/11/2022 21:45, Antonio Carlini wrote: >>>=20 >>> I have two more I can open up and look at, but I cannot get to them tonig= ht and I'm probably out tomorrow too. But I think I can get to those other tw= o supplies on Wednesday. Hopefully at least one of them will be readable! Oth= erwise I can desolder the diode from one of the other two and hopefully find = a useful marking. >>=20 >>=20 >> Turns out I have three more PSUs ... and the diode markings are unfortunat= ely invisible on all but one. That one is this one: >>=20 >> https://drive.google.com/file/d/1TeGTcBBv7KecMJ2CmNcR0O-tb3jZigy6/view?usp= =3Dshare_link >>=20 >>=20 >> It's not really visible there either but with the PSU out and one end deso= ldered I can see that it is marked H9501. I can also see that it doesn't cond= uct either way, which might mean that this PSU is the non-working one I know = I have. Obviously the capacitor (820uF 250V electrolytic) is going to need re= placing (might as well do both). But first I need to remove them and see what= (if anything has happened) underneath. >>=20 >>=20 >> This now goes back into my queue (behind the MicroVAXes and the H7868B PSU= modules) so if you fix yours before I get to mine, please let me know what y= ou did :-) >>=20 >>=20 >> Antonio >>=20 >>=20 >> --=20 >> Antonio Carlini >> antonio(a)acarlini.com >>=20 --===============7370396709905976002==-- From organlists1@sonic.net Thu Nov 24 06:50:14 2022 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Wed, 23 Nov 2022 22:49:45 -0800 Message-ID: In-Reply-To: <01SKP533MBNM8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0861059754048337585==" --===============0861059754048337585== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The data sheet lists H5892 through H5899 and H5900 through H5911. Don Resor Sent from someone's iPhone > On Nov 23, 2022, at 4:32 PM, Peter Coghlan via cctalk wrote: >=20 > =EF=BB=BFDon, >=20 > Does the url suggest you may have searched for a H5901 rather than a H9501? >=20 > Regards, > Peter Coghlan. >=20 >>=20 >> NTE seems to turn up these possibilities for a H9501. >>=20 >> https://www.nteinc.com/search/search/search.php?ss360Query=3DH5901 >>=20 >> Don Resor >>=20 >> Sent from someone's iPhone >>=20 >>>> On Nov 23, 2022, at 12:04 PM, Antonio Carlini via cctalk wrote: >>>=20 >>> =EF=BB=BFOn 21/11/2022 21:45, Antonio Carlini wrote: >>>>=20 >>>> I have two more I can open up and look at, but I cannot get to them toni= ght and I'm probably out tomorrow too. But I think I can get to those other t= wo supplies on Wednesday. Hopefully at least one of them will be readable! Ot= herwise I can desolder the diode from one of the other two and hopefully find= a useful marking. >>>=20 >>>=20 >>> Turns out I have three more PSUs ... and the diode markings are unfortuna= tely invisible on all but one. That one is this one: >>>=20 >>> https://drive.google.com/file/d/1TeGTcBBv7KecMJ2CmNcR0O-tb3jZigy6/view?us= p=3Dshare_link >>>=20 >>>=20 >>> It's not really visible there either but with the PSU out and one end des= oldered I can see that it is marked H9501. I can also see that it doesn't con= duct either way, which might mean that this PSU is the non-working one I know= I have. Obviously the capacitor (820uF 250V electrolytic) is going to need r= eplacing (might as well do both). But first I need to remove them and see wha= t (if anything has happened) underneath. >>>=20 >>>=20 >>> This now goes back into my queue (behind the MicroVAXes and the H7868B PS= U modules) so if you fix yours before I get to mine, please let me know what = you did :-) >>>=20 >>>=20 >>> Antonio >>>=20 >>>=20 >>> --=20 >>> Antonio Carlini >>> antonio(a)acarlini.com >>>=20 >=20 >=20 --===============0861059754048337585==-- From robert.jarratt@ntlworld.com Thu Nov 24 21:45:27 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Thu, 24 Nov 2022 21:45:05 +0000 Message-ID: <01d301d9004e$04340f30$0c9c2d90$@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1897470735587668896==" --===============1897470735587668896== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a sugg= estion that the PIV should be 200V. Not sure what rating I should be going fo= r here? =20 Regards =20 Rob =20 From: Mattis Lind =20 Sent: 22 November 2022 07:54 To: rob(a)jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power Sup= ply =20 =20 Hello Rob! =20 Given that before the transistor blew up there had clearly been another failure somewhere else, I tried to find the original failure. There were no obviously damaged parts, so I just probed around near the transistor for any parts that were open circuit or short circuit. I found a diode connected to the base of the transistor that appeared to be short circuit. So, I decided to lift one end to check it. As I de-soldered one of the leads, the diode broke in two. So clearly the diode was either damaged by the failure of the transistor, or it was the cause of the failure. This is the diode: https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. =20 =20 DEC used a lot of A114x diodes in their PSUs. They looked exactly like that o= ne. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet-p= df/view/7563180/2074/A114F.html =20 I would replace it with a UF4007 or something similar. https://www.mouser.se/= datasheet/2/849/uf4001-2578577.pdf =20 =20 =20 I can't quite make out the markings on the diode to know what to replace it with. I think it says "D610". Would that be the right designation? If so, can anyone suggest a suitable replacement please? The diode seems to connect an inductor to the base of the switching transistor and the collector of the transistor is connected to a transformer. Should I be looking for other failed parts? Not sure if the diode failed first and then caused the transistor to fail? Or if something else has failed which caused these parts to fail? =20 =20 Also check all other semiconductors. Also on the outputs. If there is a 1 ohm= fusible resistor in the base drive circuit check that one as well. In the VT= 100 PSUs it happens that it blows. =20 =20 I do know that there are no shorts in the Rainbow itself, because I have a spare PSU that still works fine in the same machine. I blogged this here (it repeats most of that I have said above): https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai = =20 lure/ =20 /Mattis=20 Thanks Rob --===============1897470735587668896==-- From organlists1@sonic.net Thu Nov 24 21:49:31 2022 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Thu, 24 Nov 2022 13:49:12 -0800 Message-ID: <59FC6ECB-FB71-4BB5-A08A-DEE3FE6A03EA@sonic.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5815794737608681533==" --===============5815794737608681533== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You=E2=80=99re right, I superimposed the number. That certainly doesn=E2=80=99t help at all. Don Resor Sent from someone's iPhone > On Nov 23, 2022, at 10:50 PM, Don R via cctalk wr= ote: >=20 > =EF=BB=BFThe data sheet lists H5892 through H5899 and H5900 through H5911. >=20 > Don Resor >=20 > Sent from someone's iPhone >=20 >> On Nov 23, 2022, at 4:32 PM, Peter Coghlan via cctalk wrote: >>=20 >> =EF=BB=BFDon, >>=20 >> Does the url suggest you may have searched for a H5901 rather than a H9501? >>=20 >> Regards, >> Peter Coghlan. >>=20 >>>=20 >>> NTE seems to turn up these possibilities for a H9501. >>>=20 >>> https://www.nteinc.com/search/search/search.php?ss360Query=3DH5901 >>>=20 >>> Don Resor >>>=20 >>> Sent from someone's iPhone >>>=20 >>>>> On Nov 23, 2022, at 12:04 PM, Antonio Carlini via cctalk wrote: >>>>=20 >>>> =EF=BB=BFOn 21/11/2022 21:45, Antonio Carlini wrote: >>>>>=20 >>>>> I have two more I can open up and look at, but I cannot get to them ton= ight and I'm probably out tomorrow too. But I think I can get to those other = two supplies on Wednesday. Hopefully at least one of them will be readable! O= therwise I can desolder the diode from one of the other two and hopefully fin= d a useful marking. >>>>=20 >>>>=20 >>>> Turns out I have three more PSUs ... and the diode markings are unfortun= ately invisible on all but one. That one is this one: >>>>=20 >>>> https://drive.google.com/file/d/1TeGTcBBv7KecMJ2CmNcR0O-tb3jZigy6/view?u= sp=3Dshare_link >>>>=20 >>>>=20 >>>> It's not really visible there either but with the PSU out and one end de= soldered I can see that it is marked H9501. I can also see that it doesn't co= nduct either way, which might mean that this PSU is the non-working one I kno= w I have. Obviously the capacitor (820uF 250V electrolytic) is going to need = replacing (might as well do both). But first I need to remove them and see wh= at (if anything has happened) underneath. >>>>=20 >>>>=20 >>>> This now goes back into my queue (behind the MicroVAXes and the H7868B P= SU modules) so if you fix yours before I get to mine, please let me know what= you did :-) >>>>=20 >>>>=20 >>>> Antonio >>>>=20 >>>>=20 >>>> --=20 >>>> Antonio Carlini >>>> antonio(a)acarlini.com >>>>=20 >>=20 >>=20 --===============5815794737608681533==-- From mattislind@gmail.com Fri Nov 25 07:12:53 2022 From: Mattis Lind To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Fri, 25 Nov 2022 08:12:27 +0100 Message-ID: <75DE3CD2-B9F8-4396-AC44-4D653561380E@gmail.com> In-Reply-To: <01d301d9004e$04340f30$0c9c2d90$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6470991187922020363==" --===============6470991187922020363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 24 Nov 2022, at 22:45, Rob Jarratt wrote: >=20 > =EF=BB=BF > Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a su= ggestion that the PIV should be 200V. Not sure what rating I should be going = for here? Given that I didn=E2=80=99t have a schematic and this is on the primary side = I went for the recommendation of 1000V. 200V may a bit low on the primary sid= e depending on the application of the diode. On the primary there can be sust= ained voltages up to 400V and peaks that go even higher. Using a diode with h= igher PIV almost never affects the operation as long as other parameters stay= the same. In this case the most important parameter is the trr. It has to be= a fast recovery diode. In this case the UF4007 is slightly slower than the U= F4004. But I doubt it has a big significance. Actually the A114 is much slowe= r. 200 ns.=20 :Mattis > =20 > Regards > =20 > Rob > =20 > From: Mattis Lind =20 > Sent: 22 November 2022 07:54 > To: rob(a)jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts <= cctalk(a)classiccmp.org> > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply > =20 > =20 > Hello Rob! > =20 >=20 > Given that before the transistor blew up there had clearly been another > failure somewhere else, I tried to find the original failure. There were no > obviously damaged parts, so I just probed around near the transistor for any > parts that were open circuit or short circuit. I found a diode connected to > the base of the transistor that appeared to be short circuit. So, I decided > to lift one end to check it. As I de-soldered one of the leads, the diode > broke in two. So clearly the diode was either damaged by the failure of the > transistor, or it was the cause of the failure. This is the diode: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. >=20 >=20 > =20 > =20 > DEC used a lot of A114x diodes in their PSUs. They looked exactly like that= one. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet= -pdf/view/7563180/2074/A114F.html > =20 > I would replace it with a UF4007 or something similar. https://www.mouser.s= e/datasheet/2/849/uf4001-2578577.pdf > =20 > =20 > =20 >=20 > I can't quite make out the markings on the diode to know what to replace it > with. I think it says "D610". Would that be the right designation? If so, > can anyone suggest a suitable replacement please? >=20 >=20 >=20 > The diode seems to connect an inductor to the base of the switching > transistor and the collector of the transistor is connected to a > transformer. Should I be looking for other failed parts? Not sure if the > diode failed first and then caused the transistor to fail? Or if something > else has failed which caused these parts to fail? > =20 > =20 > Also check all other semiconductors. Also on the outputs. If there is a 1 o= hm fusible resistor in the base drive circuit check that one as well. In the = VT100 PSUs it happens that it blows. > =20 > =20 >=20 >=20 >=20 > I do know that there are no shorts in the Rainbow itself, because I have a > spare PSU that still works fine in the same machine. >=20 >=20 >=20 > I blogged this here (it repeats most of that I have said above): > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai > lure/ >=20 >=20 > =20 > /Mattis=20 >=20 > Thanks >=20 >=20 >=20 > Rob --===============6470991187922020363==-- From robert.jarratt@ntlworld.com Fri Nov 25 08:04:44 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Fri, 25 Nov 2022 08:04:22 +0000 Message-ID: <020e01d900a4$876ca0a0$9645e1e0$@ntlworld.com> In-Reply-To: <75DE3CD2-B9F8-4396-AC44-4D653561380E@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0713062646687244361==" --===============0713062646687244361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tony Duell has reverse engineered the following schematic. =20 http://www.bitsavers.org/pdf/dec/rainbow/duell_schematics/psu.pdf =20 I will go with the 1000V as you suggest anyway. =20 Thanks =20 Rob =20 From: Mattis Lind =20 Sent: 25 November 2022 07:12 To: rob(a)jarratt.me.uk Cc: General Discussion: On-Topic and Off-Topic Posts Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power Sup= ply =20 =20 On 24 Nov 2022, at 22:45, Rob Jarratt > wrote: =EF=BB=BF Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a sugg= estion that the PIV should be 200V. Not sure what rating I should be going fo= r here? =20 Given that I didn=E2=80=99t have a schematic and this is on the primary side = I went for the recommendation of 1000V. 200V may a bit low on the primary sid= e depending on the application of the diode. On the primary there can be sust= ained voltages up to 400V and peaks that go even higher. Using a diode with h= igher PIV almost never affects the operation as long as other parameters stay= the same. In this case the most important parameter is the trr. It has to be= a fast recovery diode. In this case the UF4007 is slightly slower than the U= F4004. But I doubt it has a big significance. Actually the A114 is much slowe= r. 200 ns.=20 =20 :Mattis =20 Regards =20 Rob =20 From: Mattis Lind >=20 Sent: 22 November 2022 07:54 To: rob(a)jarratt.me.uk ; General Discussion: On= -Topic and Off-Topic Posts > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power Sup= ply =20 =20 Hello Rob! =20 Given that before the transistor blew up there had clearly been another failure somewhere else, I tried to find the original failure. There were no obviously damaged parts, so I just probed around near the transistor for any parts that were open circuit or short circuit. I found a diode connected to the base of the transistor that appeared to be short circuit. So, I decided to lift one end to check it. As I de-soldered one of the leads, the diode broke in two. So clearly the diode was either damaged by the failure of the transistor, or it was the cause of the failure. This is the diode: https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. =20 =20 DEC used a lot of A114x diodes in their PSUs. They looked exactly like that o= ne. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet-p= df/view/7563180/2074/A114F.html =20 I would replace it with a UF4007 or something similar. https://www.mouser.se/= datasheet/2/849/uf4001-2578577.pdf =20 =20 =20 I can't quite make out the markings on the diode to know what to replace it with. I think it says "D610". Would that be the right designation? If so, can anyone suggest a suitable replacement please? The diode seems to connect an inductor to the base of the switching transistor and the collector of the transistor is connected to a transformer. Should I be looking for other failed parts? Not sure if the diode failed first and then caused the transistor to fail? Or if something else has failed which caused these parts to fail? =20 =20 Also check all other semiconductors. Also on the outputs. If there is a 1 ohm= fusible resistor in the base drive circuit check that one as well. In the VT= 100 PSUs it happens that it blows. =20 =20 I do know that there are no shorts in the Rainbow itself, because I have a spare PSU that still works fine in the same machine. I blogged this here (it repeats most of that I have said above): https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai = =20 lure/ =20 /Mattis=20 Thanks Rob --===============0713062646687244361==-- From cctalk@beyondthepale.ie Fri Nov 25 10:12:42 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Fri, 25 Nov 2022 09:44:04 +0000 Message-ID: <01SKR3J59SSA8WYOLI@beyondthepale.ie> In-Reply-To: <020e01d900a4$876ca0a0$9645e1e0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8125140743319600075==" --===============8125140743319600075== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It is often possible to infer the component ratings needed from the other components around them. A component in the base circuit of a transistor is likely to experience lower currents and voltages than one in the collector circuit. In this case, we can see from Tony's diagram that there is a 2.7 Ohm resistor in parallel with the diode. Suppose it is a 1W resistor. This means that the from P =3D I squared R, the average current the resistor is likely to pass is less than 1A. From Ohm's law, V/I =3D R, this means the average voltage across the resistor is likely to be no more than 2.7 Volts. It is possible that the peak current / voltage involved could be higher than the average for short periods of time but we have plenty of margin for error here so we don't need to think about that too much. A diode with a PIV of 200V should be fine here. Regards, Peter Coghlan > > Tony Duell has reverse engineered the following schematic. >=20 > =20 >=20 > http://www.bitsavers.org/pdf/dec/rainbow/duell_schematics/psu.pdf >=20 > =20 >=20 > I will go with the 1000V as you suggest anyway. >=20 >=20 > > Thanks > >=20 > > Rob > >=20 > > From: Mattis Lind =20 > Sent: 25 November 2022 07:12 > To: rob(a)jarratt.me.uk > Cc: General Discussion: On-Topic and Off-Topic Posts > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply >=20 > =20 >=20 > =20 > >=20 >=20 > >=20 > On 24 Nov 2022, at 22:45, Rob Jarratt > wrote: >=20 > =EF=BB=BF >=20 > Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a > suggestion that the PIV should be 200V. Not sure what rating I should be > going for here? >=20 > =20 > > Given that I didn=E2=80=99t have a schematic and this is on the primary sid= e I went > for the recommendation of 1000V. 200V may a bit low on the primary side > depending on the application of the diode. On the primary there can be > sustained voltages up to 400V and peaks that go even higher. Using a diode > with higher PIV almost never affects the operation as long as other > parameters stay the same. In this case the most important parameter is the > trr. It has to be a fast recovery diode. In this case the UF4007 is slightly > slower than the UF4004. But I doubt it has a big significance. Actually the > A114 is much slower. 200 ns.=20 >=20 > =20 >=20 > :Mattis >=20 >=20 >=20 > =20 >=20 > Regards >=20 > =20 >=20 > Rob >=20 > =20 >=20 > From: Mattis Lind >= =20 > Sent: 22 November 2022 07:54 > To: rob(a)jarratt.me.uk ; > General Discussion: On-Topic and Off-Topic Posts > > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply >=20 > =20 >=20 > =20 >=20 > Hello Rob! >=20 > =20 >=20 >=20 > Given that before the transistor blew up there had clearly been another > failure somewhere else, I tried to find the original failure. There were no > obviously damaged parts, so I just probed around near the transistor for any > parts that were open circuit or short circuit. I found a diode connected to > the base of the transistor that appeared to be short circuit. So, I decided > to lift one end to check it. As I de-soldered one of the leads, the diode > broke in two. So clearly the diode was either damaged by the failure of the > transistor, or it was the cause of the failure. This is the diode: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. >=20 >=20 >=20 >=20 > =20 >=20 > =20 >=20 > DEC used a lot of A114x diodes in their PSUs. They looked exactly like that > one. Those are fast recovery diodes. > https://pdf2.alldatasheet.com/datasheet-pdf/view/7563180/2074/A114F.html >=20 > =20 >=20 > I would replace it with a UF4007 or something similar. > https://www.mouser.se/datasheet/2/849/uf4001-2578577.pdf >=20 > =20 >=20 > =20 >=20 > =20 >=20 >=20 > I can't quite make out the markings on the diode to know what to replace it > with. I think it says "D610". Would that be the right designation? If so, > can anyone suggest a suitable replacement please? >=20 >=20 >=20 > The diode seems to connect an inductor to the base of the switching > transistor and the collector of the transistor is connected to a > transformer. Should I be looking for other failed parts? Not sure if the > diode failed first and then caused the transistor to fail? Or if something > else has failed which caused these parts to fail? >=20 > =20 >=20 > =20 >=20 > Also check all other semiconductors. Also on the outputs. If there is a 1 o= hm > fusible resistor in the base drive circuit check that one as well. In the > VT100 PSUs it happens that it blows. >=20 > =20 >=20 > =20 >=20 >=20 >=20 >=20 > I do know that there are no shorts in the Rainbow itself, because I have a > spare PSU that still works fine in the same machine. >=20 >=20 >=20 > I blogged this here (it repeats most of that I have said above): > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fa= ilure/ > >=20 >=20 >=20 >=20 > =20 >=20 > /Mattis=20 >=20 >=20 > Thanks >=20 >=20 >=20 > Rob >=20 --===============8125140743319600075==-- From robert.jarratt@ntlworld.com Sat Nov 26 18:47:39 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sat, 26 Nov 2022 18:47:17 +0000 Message-ID: <000001d901c7$822d3220$86879660$@ntlworld.com> In-Reply-To: <01SKR3J59SSA8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3868201383414084762==" --===============3868201383414084762== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just trying to decide what to replace the failed diode with, and looking at t= he UF400x series, as suggested by Mattis. It seems to me that as long as the = PIV is 200V or higher it should be fine from that point of view, the switchin= g speed is never higher than 70ns, while the original A114x (assuming it *is*= an A114x) has a switching speed of 200ns (possibly even 200us from the datas= heet). However, I am wondering about the forward voltage drop. The datasheets sugges= t that the A114x parts have a 1.3V forward voltage drop. I have a spare H7842= that was working (until I messed it up today, another story), so I tested th= e diode in that, its forward voltage appears to be 0.5V, using a little teste= r I have. The UF400x have ratings of either 1.0V or 1.7V. How sensitive is the circuit going to be to the forward voltage on the diode?= Given that the forward voltage of the suggested replacement is higher, would= it slow down the speed with which the transistor is switched off too much an= d cause it to be overloaded and fail? Thanks Rob > -----Original Message----- > From: Peter Coghlan via cctalk > Sent: 25 November 2022 09:44 > To: General Discussion: On-Topic and Off-Topic Posts > > Cc: Peter Coghlan > Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power > Supply >=20 > It is often possible to infer the component ratings needed from the other > components around them. A component in the base circuit of a transistor is > likely to experience lower currents and voltages than one in the collector > circuit. >=20 > In this case, we can see from Tony's diagram that there is a 2.7 Ohm resist= or > in parallel with the diode. Suppose it is a 1W resistor. This means that = the > from P =3D I squared R, the average current the resistor is likely to pass = is less > than 1A. From Ohm's law, V/I =3D R, this means the average voltage across = the > resistor is likely to be no more than 2.7 Volts. >=20 > It is possible that the peak current / voltage involved could be higher than > the average for short periods of time but we have plenty of margin for error > here so we don't need to think about that too much. A diode with a PIV of > 200V should be fine here. >=20 > Regards, > Peter Coghlan >=20 > > > > Tony Duell has reverse engineered the following schematic. > > > > > > > > http://www.bitsavers.org/pdf/dec/rainbow/duell_schematics/psu.pdf > > > > > > > > I will go with the 1000V as you suggest anyway. > > > > > > > > Thanks > > > > > > > > Rob > > > > > > > > From: Mattis Lind > > Sent: 25 November 2022 07:12 > > To: rob(a)jarratt.me.uk > > Cc: General Discussion: On-Topic and Off-Topic Posts > > > > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 > > Power Supply > > > > > > > > > > > > > > > > > > > > On 24 Nov 2022, at 22:45, Rob Jarratt > wrote: > > > >=20 > > > > Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had > > a suggestion that the PIV should be 200V. Not sure what rating I > > should be going for here? > > > > > > > > Given that I didn=E2=80=99t have a schematic and this is on the primary s= ide I > > went for the recommendation of 1000V. 200V may a bit low on the > > primary side depending on the application of the diode. On the primary > > there can be sustained voltages up to 400V and peaks that go even > > higher. Using a diode with higher PIV almost never affects the > > operation as long as other parameters stay the same. In this case the > > most important parameter is the trr. It has to be a fast recovery > > diode. In this case the UF4007 is slightly slower than the UF4004. But > > I doubt it has a big significance. Actually the > > A114 is much slower. 200 ns. > > > > > > > > :Mattis > > > > > > > > > > > > Regards > > > > > > > > Rob > > > > > > > > From: Mattis Lind > > > > > Sent: 22 November 2022 07:54 > > To: rob(a)jarratt.me.uk ; > > General Discussion: On-Topic and Off-Topic Posts > > > > > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 > > Power Supply > > > > > > > > > > > > Hello Rob! > > > > > > > > > > Given that before the transistor blew up there had clearly been > > another failure somewhere else, I tried to find the original failure. > > There were no obviously damaged parts, so I just probed around near > > the transistor for any parts that were open circuit or short circuit. > > I found a diode connected to the base of the transistor that appeared > > to be short circuit. So, I decided to lift one end to check it. As I > > de-soldered one of the leads, the diode broke in two. So clearly the > > diode was either damaged by the failure of the transistor, or it was the > cause of the failure. This is the diode: > > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. > > > > > > > > > > > > > > > > > > DEC used a lot of A114x diodes in their PSUs. They looked exactly like > > that one. Those are fast recovery diodes. > > https://pdf2.alldatasheet.com/datasheet- > pdf/view/7563180/2074/A114F.ht > > ml > > > > > > > > I would replace it with a UF4007 or something similar. > > https://www.mouser.se/datasheet/2/849/uf4001-2578577.pdf > > > > > > > > > > > > > > > > > > I can't quite make out the markings on the diode to know what to > > replace it with. I think it says "D610". Would that be the right > > designation? If so, can anyone suggest a suitable replacement please? > > > > > > > > The diode seems to connect an inductor to the base of the switching > > transistor and the collector of the transistor is connected to a > > transformer. Should I be looking for other failed parts? Not sure if > > the diode failed first and then caused the transistor to fail? Or if > > something else has failed which caused these parts to fail? > > > > > > > > > > > > Also check all other semiconductors. Also on the outputs. If there is > > a 1 ohm fusible resistor in the base drive circuit check that one as > > well. In the > > VT100 PSUs it happens that it blows. > > > > > > > > > > > > > > > > > > I do know that there are no shorts in the Rainbow itself, because I > > have a spare PSU that still works fine in the same machine. > > > > > > > > I blogged this here (it repeats most of that I have said above): > > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power- > supp > > ly-failure/ > > sup > > ply-failure/> > > > > > > > > > > > > > > /Mattis > > > > > > Thanks > > > > > > > > Rob > > --===============3868201383414084762==-- From wrcooke@wrcooke.net Sat Nov 26 19:16:53 2022 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sat, 26 Nov 2022 13:11:34 -0600 Message-ID: <741966159.374916.1669489894678@email.ionos.com> In-Reply-To: <000001d901c7$822d3220$86879660$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6117107164254853956==" --===============6117107164254853956== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 11/26/2022 12:47 PM CST Rob Jarratt via cctalk = wrote: >=20 >=20 > Just trying to decide what to replace the failed diode with, and looking at= the UF400x series, as suggested by Mattis. It seems to me that as long as th= e PIV is 200V or higher it should be fine from that point of view, the switch= ing speed is never higher than 70ns, while the original A114x (assuming it *i= s* an A114x) has a switching speed of 200ns (possibly even 200us from the dat= asheet). >=20 > However, I am wondering about the forward voltage drop. The datasheets sugg= est that the A114x parts have a 1.3V forward voltage drop. I have a spare H78= 42 that was working (until I messed it up today, another story), so I tested = the diode in that, its forward voltage appears to be 0.5V, using a little tes= ter I have. The UF400x have ratings of either 1.0V or 1.7V. >=20 > How sensitive is the circuit going to be to the forward voltage on the diod= e? Given that the forward voltage of the suggested replacement is higher, wou= ld it slow down the speed with which the transistor is switched off too much = and cause it to be overloaded and fail? >=20 > Thanks >=20 > Rob >=20 >=20 I'm not at all familiar with either this circuit or any of the mentioned diod= es. However, I would point out that a diode's forward voltage drop varies wi= th current through it. Usually, the datasheet will list the "max" forward dr= op, at the rated current and typically at the lowest rated temp (the drop dec= reases as temp rises.) So it is entirely possible that your tester is puttin= g a very small current through a high-current diode and getting that 0.5V. = It might be useful to feed it something close to its rated current and measur= e the drop for a more accurate estimate. Will --===============6117107164254853956==-- From robert.jarratt@ntlworld.com Sat Nov 26 20:31:02 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sat, 26 Nov 2022 20:30:40 +0000 Message-ID: <000f01d901d5$f3bcd180$db367480$@ntlworld.com> In-Reply-To: <741966159.374916.1669489894678@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6607054315854477414==" --===============6607054315854477414== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Will Cooke via cctalk > Sent: 26 November 2022 19:12 > To: Rob Jarratt via cctalk > Cc: wrcooke(a)wrcooke.net > Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power > Supply >=20 >=20 > I'm not at all familiar with either this circuit or any of the mentioned di= odes. > However, I would point out that a diode's forward voltage drop varies with > current through it. Usually, the datasheet will list the "max" forward dro= p, at > the rated current and typically at the lowest rated temp (the drop decreases > as temp rises.) So it is entirely possible that your tester is putting a v= ery small > current through a high-current diode and getting that 0.5V. It might be > useful to feed it something close to its rated current and measure the drop > for a more accurate estimate. Thanks, I didn't know this, there is still so much I have to learn! I had not= iced that the datasheets say "max" forward voltage but wasn't sure of the sig= nificance. >=20 > Will --===============6607054315854477414==-- From robert.jarratt@ntlworld.com Sun Nov 27 09:21:49 2022 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 27 Nov 2022 09:21:26 +0000 Message-ID: <002801d90241$a028ab90$e07a02b0$@ntlworld.com> In-Reply-To: <01d301d9004e$04340f30$0c9c2d90$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0786829798585798914==" --===============0786829798585798914== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have done a little more probing around. I have found that the 7812 regulato= r that drives Vstart on sheet 1 of Tony Duell=E2=80=99s schematic is shorted,= so I will have to replace this too. I have not found anything else that look= s obviously suspicious. I can=E2=80=99t test the output rectifiers for shorts= without desoldering them, which I would rather avoid. I guess the next step = is to replace the broken parts and use the light bulb current-limiter method = to power on the PSU. =20 Regards =20 Rob =20 From: Rob Jarratt =20 Sent: 24 November 2022 21:45 To: 'Mattis Lind' ; rob(a)jarratt.me.uk; 'General Dis= cussion: On-Topic and Off-Topic Posts' Subject: RE: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power Sup= ply =20 Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a sugg= estion that the PIV should be 200V. Not sure what rating I should be going fo= r here? =20 Regards =20 Rob =20 From: Mattis Lind >=20 Sent: 22 November 2022 07:54 To: rob(a)jarratt.me.uk ; General Discussion: On= -Topic and Off-Topic Posts > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power Sup= ply =20 =20 Hello Rob! =20 Given that before the transistor blew up there had clearly been another failure somewhere else, I tried to find the original failure. There were no obviously damaged parts, so I just probed around near the transistor for any parts that were open circuit or short circuit. I found a diode connected to the base of the transistor that appeared to be short circuit. So, I decided to lift one end to check it. As I de-soldered one of the leads, the diode broke in two. So clearly the diode was either damaged by the failure of the transistor, or it was the cause of the failure. This is the diode: https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. =20 =20 DEC used a lot of A114x diodes in their PSUs. They looked exactly like that o= ne. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet-p= df/view/7563180/2074/A114F.html =20 I would replace it with a UF4007 or something similar. https://www.mouser.se/= datasheet/2/849/uf4001-2578577.pdf =20 =20 =20 I can't quite make out the markings on the diode to know what to replace it with. I think it says "D610". Would that be the right designation? If so, can anyone suggest a suitable replacement please? The diode seems to connect an inductor to the base of the switching transistor and the collector of the transistor is connected to a transformer. Should I be looking for other failed parts? Not sure if the diode failed first and then caused the transistor to fail? Or if something else has failed which caused these parts to fail? =20 =20 Also check all other semiconductors. Also on the outputs. If there is a 1 ohm= fusible resistor in the base drive circuit check that one as well. In the VT= 100 PSUs it happens that it blows. =20 =20 I do know that there are no shorts in the Rainbow itself, because I have a spare PSU that still works fine in the same machine. I blogged this here (it repeats most of that I have said above): https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai = =20 lure/ =20 /Mattis=20 Thanks Rob --===============0786829798585798914==-- From mattislind@gmail.com Sun Nov 27 12:06:45 2022 From: Mattis Lind To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 27 Nov 2022 13:06:21 +0100 Message-ID: <15B6266A-63FF-401F-B36F-475E68E55094@gmail.com> In-Reply-To: <002801d90241$a028ab90$e07a02b0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3075216416858352728==" --===============3075216416858352728== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 27 Nov 2022, at 10:21, Rob Jarratt wrote: >=20 > =EF=BB=BF > I have done a little more probing around. I have found that the 7812 regula= tor that drives Vstart on sheet 1 of Tony Duell=E2=80=99s schematic is shorte= d, so I will have to replace this too. I have not found anything else that lo= oks obviously suspicious. I can=E2=80=99t test the output rectifiers for shor= ts without desoldering them, which I would rather avoid. I guess the next ste= p is to replace the broken parts and use the light bulb current-limiter metho= d to power on the PSU. I think that a good thing is to ramp up the input voltage slowly. Use a bench= PSU to supply the Vstart voltage and then use a variac with insulation trans= former to feed the rest if the supply. Use some small loads on the 5V and 12V= outputs. Now you can safely probe the PSU and monitor base and collector vol= tages of the main switch transistor and see that everything looks fine. Chec= k output voltages. Stay below 50VAC input and very little harm can be done. C= ould be good idea to have an amp-meter inline with input AC from the variac t= o find out if there is short somewhere.=20 If this works then try with full input. Remove any scope probes=E2=80=A6 /Mattis > =20 > Regards > =20 > Rob > =20 > From: Rob Jarratt =20 > Sent: 24 November 2022 21:45 > To: 'Mattis Lind' ; rob(a)jarratt.me.uk; 'General D= iscussion: On-Topic and Off-Topic Posts' > Subject: RE: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply > =20 > Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a su= ggestion that the PIV should be 200V. Not sure what rating I should be going = for here? > =20 > Regards > =20 > Rob > =20 > From: Mattis Lind =20 > Sent: 22 November 2022 07:54 > To: rob(a)jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts <= cctalk(a)classiccmp.org> > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply > =20 > =20 > Hello Rob! > =20 >=20 > Given that before the transistor blew up there had clearly been another > failure somewhere else, I tried to find the original failure. There were no > obviously damaged parts, so I just probed around near the transistor for any > parts that were open circuit or short circuit. I found a diode connected to > the base of the transistor that appeared to be short circuit. So, I decided > to lift one end to check it. As I de-soldered one of the leads, the diode > broke in two. So clearly the diode was either damaged by the failure of the > transistor, or it was the cause of the failure. This is the diode: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. >=20 > =20 > =20 > DEC used a lot of A114x diodes in their PSUs. They looked exactly like that= one. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet= -pdf/view/7563180/2074/A114F.html > =20 > I would replace it with a UF4007 or something similar. https://www.mouser.s= e/datasheet/2/849/uf4001-2578577.pdf > =20 > =20 > =20 >=20 > I can't quite make out the markings on the diode to know what to replace it > with. I think it says "D610". Would that be the right designation? If so, > can anyone suggest a suitable replacement please? >=20 >=20 >=20 > The diode seems to connect an inductor to the base of the switching > transistor and the collector of the transistor is connected to a > transformer. Should I be looking for other failed parts? Not sure if the > diode failed first and then caused the transistor to fail? Or if something > else has failed which caused these parts to fail? > =20 > =20 > Also check all other semiconductors. Also on the outputs. If there is a 1 o= hm fusible resistor in the base drive circuit check that one as well. In the = VT100 PSUs it happens that it blows. > =20 > =20 >=20 >=20 >=20 > I do know that there are no shorts in the Rainbow itself, because I have a > spare PSU that still works fine in the same machine. >=20 >=20 >=20 > I blogged this here (it repeats most of that I have said above): > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fai > lure/ >=20 > =20 > /Mattis=20 >=20 > Thanks >=20 >=20 >=20 > Rob --===============3075216416858352728==-- From lyokoboy0@gmail.com Sun Nov 27 17:48:44 2022 From: Devin D To: cctalk@classiccmp.org Subject: [cctalk] Guidance on repairing Dec PDP 11 System Date: Sun, 27 Nov 2022 12:48:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2074490603447002209==" --===============2074490603447002209== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Greetings, Been a while since i have posted here. I have several PDP11 systems and peripherals. I picked the original lot of a system 34 and related tech in Miami FL a couple years back, and have since found several more pdp 11/34 machines, and a pdp 11/05, 11/85, and others. It has been a goal to get the original PDP 11/34 system up and running, however my job schedule kept getting in the way of my repair efforts, making it easy to loose track of where i was at with the repair progress. Thankfully i no longer work in a datacenter in a 10 hour overnight shift, so it should be much easier to devote my time to this repair. I am looking for advice to get the 11/34 system up and running. I have started to put together a site to document my progress, to stay on track with the repair effort. The system has 2 rl02 drives, and an attached 9 track tape drive. I had worked to repair a power supply issue at first, there was a problem with the main transformer, as well as one of the smaller voltage "bricks". Thankfully i have many systems and i was just able to swap in the needed working parts. So this is about as far as I got, I had a minimal config of the 11/34 machine running, with not much more than the cpu, and a serial card to talk to attached terminal. Power supply works, and i was able to toggle in programs from the front panel to output characters to the attached terminal. I believe the next logical step was to try and attach the rl02 controllers, and see if the disk packs still have working installs of RSX installed. I am not sure how to proceed with this though. I have mainly been following the advice of Paul Anderson, who has been a godsend in regard to advice and guidance with getting these old systems fixed up. I hope that if i keep a log of the repair effort on my site, it will allow me to pick up where i leave off with the repair much more easily. So that is the present condition of the machine. Good power supply, can toggle in simple programs to print to the attached terminal. Any advice on how to proceed is much appreciated.  I Need to get an itemized list of what hardware and cards i have on hand, and post that here so its understood what i have. Thanks, Devin D. --===============2074490603447002209==-- From jrr@flippers.com Sun Nov 27 18:23:40 2022 From: John Robertson To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 27 Nov 2022 10:23:17 -0800 Message-ID: <407af523-c65e-20fe-a9b7-6ac46758cebc@flippers.com> In-Reply-To: <002801d90241$a028ab90$e07a02b0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2996653642915845113==" --===============2996653642915845113== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2022/11/27 1:21 a.m., Rob Jarratt via cctalk wrote: > I have done a little more probing around. I have found that the 7812 regula= tor that drives Vstart on sheet 1 of Tony Duell=E2=80=99s schematic is shorte= d, so I will have to replace this too. I have not found anything else that lo= oks obviously suspicious. I can=E2=80=99t test the output rectifiers for shor= ts without desoldering them, which I would rather avoid. I guess the next ste= p is to replace the broken parts and use the light bulb current-limiter metho= d to power on the PSU. > > Regards > Rob My experience with blown 7812s is that there was a surge on the=20 unregulated side that went over the maximum input rating for the device.=20 You may want to add a Transient Suppression Diode on the input if this=20 is a future possibility or a suitable line protection MOV on the input=20 just after the line fuse. John :-#)# > =20 > > From: Rob Jarratt > Sent: 24 November 2022 21:45 > To: 'Mattis Lind' ; rob(a)jarratt.me.uk; 'General D= iscussion: On-Topic and Off-Topic Posts' > Subject: RE: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply > > =20 > > Thanks for the suggestion Mattis. The UF4007 has a PIV of 1000V, I had a su= ggestion that the PIV should be 200V. Not sure what rating I should be going = for here? > > =20 > > Regards > > =20 > > Rob > > =20 > > From: Mattis Lind > > Sent: 22 November 2022 07:54 > To: rob(a)jarratt.me.uk ; General Discussion: = On-Topic and Off-Topic Posts > > Subject: Re: [cctalk] Identifying a Failed Diode in a Rainbow H7842 Power S= upply > > =20 > > =20 > > Hello Rob! > > =20 > > > Given that before the transistor blew up there had clearly been another > failure somewhere else, I tried to find the original failure. There were no > obviously damaged parts, so I just probed around near the transistor for any > parts that were open circuit or short circuit. I found a diode connected to > the base of the transistor that appeared to be short circuit. So, I decided > to lift one end to check it. As I de-soldered one of the leads, the diode > broke in two. So clearly the diode was either damaged by the failure of the > transistor, or it was the cause of the failure. This is the diode: > https://rjarratt.files.wordpress.com/2022/11/img_20221120_165913.jpg. > > =20 > > =20 > > DEC used a lot of A114x diodes in their PSUs. They looked exactly like that= one. Those are fast recovery diodes. https://pdf2.alldatasheet.com/datasheet= -pdf/view/7563180/2074/A114F.html > > =20 > > I would replace it with a UF4007 or something similar. https://www.mouser.s= e/datasheet/2/849/uf4001-2578577.pdf > > =20 > > =20 > > =20 > > > I can't quite make out the markings on the diode to know what to replace it > with. I think it says "D610". Would that be the right designation? If so, > can anyone suggest a suitable replacement please? > > > > The diode seems to connect an inductor to the base of the switching > transistor and the collector of the transistor is connected to a > transformer. Should I be looking for other failed parts? Not sure if the > diode failed first and then caused the transistor to fail? Or if something > else has failed which caused these parts to fail? > > =20 > > =20 > > Also check all other semiconductors. Also on the outputs. If there is a 1 o= hm fusible resistor in the base drive circuit check that one as well. In the = VT100 PSUs it happens that it blows. > > =20 > > =20 > > > > > I do know that there are no shorts in the Rainbow itself, because I have a > spare PSU that still works fine in the same machine. > > > > I blogged this here (it repeats most of that I have said above): > https://robs-old-computers.com/2022/11/20/dec-rainbow-h7842-power-supply-fa= i > lure/ > > =20 > > /Mattis > > > Thanks > > > > Rob > --=20 John's Jukes Ltd. 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 Call (604)872-5757 (Pinballs, Jukes, Video Games) flippers.com "Old pinballers never die, they just flip out" --===============2996653642915845113==-- From billdegnan@gmail.com Sun Nov 27 19:56:30 2022 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Guidance on repairing Dec PDP 11 System Date: Sun, 27 Nov 2022 14:55:59 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4003728971106953312==" --===============4003728971106953312== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit There are some pretty good.videos on youtube about the 11/34.and RL02. Ray Fantini, who lives(d) neat Salisbury, MD. Bill On Sun, Nov 27, 2022, 12:48 PM Devin D via cctalk wrote: > Greetings, > > Been a while since i have posted here. I have several PDP11 systems and > peripherals. I picked the original lot of a system 34 and related tech > in Miami FL a couple years back, and have since found several more pdp > 11/34 machines, and a pdp 11/05, 11/85, and others. > > It has been a goal to get the original PDP 11/34 system up and running, > however my job schedule kept getting in the way of my repair efforts, > making it easy to loose track of where i was at with the repair > progress. Thankfully i no longer work in a datacenter in a 10 hour > overnight shift, so it should be much easier to devote my time to this > repair. > > I am looking for advice to get the 11/34 system up and running. I have > started to put together a site to document my progress, to stay on track > with the repair effort. The system has 2 rl02 drives, and an attached 9 > track tape drive. I had worked to repair a power supply issue at first, > there was a problem with the main transformer, as well as one of the > smaller voltage "bricks". Thankfully i have many systems and i was just > able to swap in the needed working parts. > > So this is about as far as I got, I had a minimal config of the 11/34 > machine running, with not much more than the cpu, and a serial card to > talk to attached terminal. Power supply works, and i was able to toggle > in programs from the front panel to output characters to the attached > terminal. > > I believe the next logical step was to try and attach the rl02 > controllers, and see if the disk packs still have working installs of > RSX installed. I am not sure how to proceed with this though. > > I have mainly been following the advice of Paul Anderson, who has been a > godsend in regard to advice and guidance with getting these old systems > fixed up. I hope that if i keep a log of the repair effort on my site, > it will allow me to pick up where i leave off with the repair much more > easily. > > So that is the present condition of the machine. Good power supply, can > toggle in simple programs to print to the attached terminal. Any advice > on how to proceed is much appreciated. I Need to get an itemized list > of what hardware and cards i have on hand, and post that here so its > understood what i have. > > Thanks, > > Devin D. > > > --===============4003728971106953312==-- From cz@alembic.crystel.com Sun Nov 27 20:12:40 2022 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Guidance on repairing Dec PDP 11 System Date: Sun, 27 Nov 2022 15:12:20 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0644481431587468605==" --===============0644481431587468605== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi! Probably the best way to get an 11 going is to take it by big steps first, then when that fails switch to one small step at a time and change as few things as possible between steps. That said you might want to start by making sure the RL02's come up first. Open them up, make sure they are clean, the filters pass air and are not destroyed by mice, unpark the heads by dropping the head lock, things like that. Disconnect the power supply from the board, turn them on, make sure the supplies are putting out the right voltage and the fans come up. Plug things back in and see if the fault and ready lights come on when you power it up. Small simple steps. Check the pack to make sure it's not dinged or damaged, check the heads with a mirror to see if they have streaks of oxide on them or are bent, stuff like that. Cable them up (remember the terminator), plug in the card, make sure the ribbon cable is inserted the right way so pin 1 on the card goes to pin 1 in the drive, then turn on the computer then the drive. The fault light should be out which means the drives are talking to the controller. Stuff like that. Where are you located? On 11/27/2022 12:48 PM, Devin D via cctalk wrote: > Greetings, > > Been a while since i have posted here. I have several PDP11 systems and > peripherals. I picked the original lot of a system 34 and related tech > in Miami FL a couple years back, and have since found several more pdp > 11/34 machines, and a pdp 11/05, 11/85, and others. > > It has been a goal to get the original PDP 11/34 system up and running, > however my job schedule kept getting in the way of my repair efforts, > making it easy to loose track of where i was at with the repair > progress. Thankfully i no longer work in a datacenter in a 10 hour > overnight shift, so it should be much easier to devote my time to this > repair. > > I am looking for advice to get the 11/34 system up and running. I have > started to put together a site to document my progress, to stay on track > with the repair effort. The system has 2 rl02 drives, and an attached 9 > track tape drive. I had worked to repair a power supply issue at first, > there was a problem with the main transformer, as well as one of the > smaller voltage "bricks". Thankfully i have many systems and i was just > able to swap in the needed working parts. > > So this is about as far as I got, I had a minimal config of the 11/34 > machine running, with not much more than the cpu, and a serial card to > talk to attached terminal. Power supply works, and i was able to toggle > in programs from the front panel to output characters to the attached > terminal. > > I believe the next logical step was to try and attach the rl02 > controllers, and see if the disk packs still have working installs of > RSX installed. I am not sure how to proceed with this though. > > I have mainly been following the advice of Paul Anderson, who has been a > godsend in regard to advice and guidance with getting these old systems > fixed up. I hope that if i keep a log of the repair effort on my site, > it will allow me to pick up where i leave off with the repair much more > easily. > > So that is the present condition of the machine. Good power supply, can > toggle in simple programs to print to the attached terminal. Any advice > on how to proceed is much appreciated.  I Need to get an itemized list > of what hardware and cards i have on hand, and post that here so its > understood what i have. > > Thanks, > > Devin D. > > --===============0644481431587468605==-- From mjd.bishop@emeritus-solutions.com Sun Nov 27 20:32:56 2022 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Guidance on repairing Dec PDP 11 System Date: Sun, 27 Nov 2022 20:32:36 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4383448783388869383==" --===============4383448783388869383== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Have you run any (paper tape) diagnostics ? I genuflect to paper tape as XXD= P and TU58 diagnostics are broadly a continuum from the paper tape days. The= seminal 11/40 diagnostics are broadly applicable to all machines (noting tha= t some addressing modes were implementation dependent ...) and that the archi= tecture / diagnostics evolved with I/D MMUs U/S/K etc. Additionally, the earl= y diagnostics have the merit of being instruction (group) / memory (test) spe= cific. The 11/34 diagnostics are agregated into a few files / tapes e.g. CFK= AAC0, CFKABD0 & CFKTHB0. Finally, an XXDP diagnostic pack is certain to cont= ain RL02 controller and drive diagnostics; snag is finding the pack is XFU - = the contents of available disk images is very variable. The following links may be useful: http://web.frainresearch.org:8080/projects/mypdp/tu58.php https://github.com/AK6DN https://www.pcjs.org/software/dec/pdp11/tapes/diag/ http://retrocmp.com/tools/pdp-11-diagnostic-database/200-pdp-11-diagnostics-i= ntroduction http://retrocmp.com/projects/unibone/285-unibone-pdp-11-and-unibus The baseline concept is: TU58 emulator / console --> DL11W --> 11/34 memory; integrating the TU58 emul= ator and 11/34 may be a programming task i.e. use the console emulator L and D commands to load the diagnostics This could be evolved, if you have the hardware, boot roms, etc. Good Luck and Best Regards Martin -----Original Message----- From: Devin D via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 27 November 2022 17:48 To: cctalk(a)classiccmp.org Cc: Devin D Subject: [cctalk] Guidance on repairing Dec PDP 11 System Greetings, Been a while since i have posted here. I have several PDP11 systems and perip= herals. I picked the original lot of a system 34 and related tech in Miami FL= a couple years back, and have since found several more pdp 11/34 machines, and a pdp 11/05, 11/85, and others. It has been a goal to get the original PDP 11/34 system up and running, howev= er my job schedule kept getting in the way of my repair efforts, making it ea= sy to loose track of where i was at with the repair progress. Thankfully i no= longer work in a datacenter in a 10 hour overnight shift, so it should be mu= ch easier to devote my time to this repair. I am looking for advice to get the 11/34 system up and running. I have starte= d to put together a site to document my progress, to stay on track with the r= epair effort. The system has 2 rl02 drives, and an attached 9 track tape driv= e. I had worked to repair a power supply issue at first, there was a problem = with the main transformer, as well as one of the smaller voltage "bricks". Th= ankfully i have many systems and i was just able to swap in the needed workin= g parts. So this is about as far as I got, I had a minimal config of the 11/34 machine= running, with not much more than the cpu, and a serial card to talk to attac= hed terminal. Power supply works, and i was able to toggle in programs from t= he front panel to output characters to the attached terminal. I believe the next logical step was to try and attach the rl02 controllers, a= nd see if the disk packs still have working installs of RSX installed. I am n= ot sure how to proceed with this though. I have mainly been following the advice of Paul Anderson, who has been a gods= end in regard to advice and guidance with getting these old systems fixed up.= I hope that if i keep a log of the repair effort on my site, it will allow m= e to pick up where i leave off with the repair much more easily. So that is the present condition of the machine. Good power supply, can toggl= e in simple programs to print to the attached terminal. Any advice on how to = proceed is much appreciated.=C2=A0 I Need to get an itemized list of what har= dware and cards i have on hand, and post that here so its understood what i h= ave. Thanks, Devin D. --===============4383448783388869383==-- From elson@pico-systems.com Sun Nov 27 20:54:45 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] anybody need 1/2" tape drives? Date: Sun, 27 Nov 2022 14:54:25 -0600 Message-ID: <7e7b6b3a-e0ea-c02d-6a9e-35a5ff4ce86e@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2790522021063078062==" --===============2790522021063078062== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Anybody need some 1/2" 9-track tape drives? I have a Pertec T9640 tape drive (vacuum column, 75 IPS 800/1600 Pertec unformatted interface). DEC sold this drive as the TU45. I also have an MDB MLSI-TM11 Q-bus tape controller that will run this drive on either LSI-11 or uVAX II systems. DEC does not supply a driver for this setup on the uVAX, but I have source of the driver I used on VMS 4.7. I also have 2 CDC Keystone 92185 drives with formatted Pertec interface. These drives handle 1600/6250 BPI, and can start/stop at 25 IPS or stream at 25 or 75 IPS. The tape path is all air-bearing. I am located in the St. Louis, MO area. Jon --===============2790522021063078062==-- From van.snyder@sbcglobal.net Sun Nov 27 21:02:21 2022 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Box of SCSI stuff Date: Sun, 27 Nov 2022 13:01:57 -0800 Message-ID: <1a3968a65a5abaa932668a52f6e83c19ea6ac4a3.camel@sbcglobal.net> In-Reply-To: <1a3968a65a5abaa932668a52f6e83c19ea6ac4a3.camel.ref@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0940241142254082951==" --===============0940241142254082951== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have a box of SCSI stuff that I'm no longer using. PCI adapters (Adaptec, Symbios) Cables -- 68-pin, 50-pin Centos, 50-pin Mac-Centos, 50-pin ribbon cable, .... Terminators Yours in exchange for a PDF of a USPS flat-rate box shipping label. Everthing might fit in a medium flat-rate box, but just to be sure send a PDF for a large flat-rate box. Van Snyder --===============0940241142254082951==-- From cctalk@beyondthepale.ie Sun Nov 27 21:18:32 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Identifying a Failed Diode in a Rainbow H7842 Power Supply Date: Sun, 27 Nov 2022 20:38:59 +0000 Message-ID: <01SKUJAMLLWW8WYOLI@beyondthepale.ie> In-Reply-To: <15B6266A-63FF-401F-B36F-475E68E55094@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3180748003154872360==" --===============3180748003154872360== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > I think that a good thing is to ramp up the input voltage slowly. Use a > bench PSU to supply the Vstart voltage and then use a variac with > insulation transformer to feed the rest if the supply. Use some small > loads on the 5V and 12V outputs. Now you can safely probe the PSU and > monitor base and collector voltages of the main switch transistor and > see that everything looks fine. Check output voltages. Stay below 50VAC > input and very little harm can be done. Could be good idea to have an > amp-meter inline with input AC from the variac to find out if there is > short somewhere. > I'm sure I recall we had a discussion about this a some time ago and I think we came to the conclusion that a variac is not a good tool for this sort of work, mainly because it doesn't limit current. A series light bulb bulb on the other hand will not allow the power supply to draw more current than the maximum current drawn by the light bulb, even if the power supply is a complete short circuit. This avoids the need to monitor an ammeter and react quickly to switch off if a high current is noticed. It also avoids having to aquire an AC ammeter which can accurately measure the odd current waveforms likely to be drawn by a switch mode power supply. An isolation transformer can be added if it turns out to be necessary to probe the primary side of the chopper transformer. Usually this won't be necessary as the light bulb will give a good indication of what is happening there. If the bulb lights at normal brilliance and the power supply does nothing, there is likely to be a serious short on the input side. If the bulb barely glows and the power supply produces reasonable output voltages into small loads, then all is probably well. If the bulb glows somewhat and one or more outputs are missing, then check the associated output rectifiers and smoothing networks for shorts. If the bulb pulses, the power supply could be tripping in response to an overload somewhere. If the bulb doesn't light and the power supply does nothing, either something is open circuit or the chopper control circuit is not working. I should probably add that the bulb needs to be a mains bulb. A 100W bulb will limit the current to less than half an Amp (in this part of world anyway). Remember to check that the reservoir capacitors for the rectified mains have discharged before handling that part of the power supply. Regards, Peter Coghlan. --===============3180748003154872360==-- From cctalk@beyondthepale.ie Sun Nov 27 21:51:32 2022 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Guidance on repairing Dec PDP 11 System Date: Sun, 27 Nov 2022 21:26:45 +0000 Message-ID: <01SKUKLH2P6U8WYOLI@beyondthepale.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1229763703746986675==" --===============1229763703746986675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > I am looking for advice to get the 11/34 system up and running. I have > started to put together a site to document my progress, to stay on track > with the repair effort. The system has 2 rl02 drives, and an attached 9 > track tape drive. I had worked to repair a power supply issue at first, > there was a problem with the main transformer, as well as one of the > smaller voltage "bricks". Thankfully i have many systems and i was just > able to swap in the needed working parts. > I'd suggest repairing the swapped out parts that were found to be faulty and putting them back in the systems they came from before going any further. I know this seems like boring work as this doesn't seem to contribute to any visible progress but it may be that minor differences in ECO level, customisations, hacks etc could lead to surprises down the road when parts from different systems are mixed and matched. Doing this work first also means there is less danger of running out of working parts if more failures should occur further along. Finally, it is going to be easier to faulty repair parts when you have working examples of them to make comparisons with than if you have no remaining working parts to guide you. Regards, Peter Coghlan. --===============1229763703746986675==-- From lyokoboy0@gmail.com Mon Nov 28 05:45:29 2022 From: devin davison To: cctalk@classiccmp.org Subject: [cctalk] Re: Guidance on repairing Dec PDP 11 System Date: Mon, 28 Nov 2022 00:44:57 -0500 Message-ID: In-Reply-To: <01SKUKLH2P6U8WYOLI@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5348617261997606050==" --===============5348617261997606050== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, thank you for the advice on repairing the failed power supply parts. I do intend to repair them, my intent was to get one system working, and then move along to the others. I will admit i am anxious to get a running rsx system running. I have been working to repair cateract and power supply issues on adm 3 terminals, i have 16 terminals now working, 10 of them being adm3, others being vt100 compatible televideo terminals. On Sun, Nov 27, 2022, 4:51 PM Peter Coghlan via cctalk < cctalk(a)classiccmp.org> wrote: > > > > I am looking for advice to get the 11/34 system up and running. I have > > started to put together a site to document my progress, to stay on track > > with the repair effort. The system has 2 rl02 drives, and an attached 9 > > track tape drive. I had worked to repair a power supply issue at first, > > there was a problem with the main transformer, as well as one of the > > smaller voltage "bricks". Thankfully i have many systems and i was just > > able to swap in the needed working parts. > > > > I'd suggest repairing the swapped out parts that were found to be faulty > and putting them back in the systems they came from before going any > further. I know this seems like boring work as this doesn't seem to > contribute to any visible progress but it may be that minor differences > in ECO level, customisations, hacks etc could lead to surprises down the > road when parts from different systems are mixed and matched. Doing this > work first also means there is less danger of running out of working parts > if more failures should occur further along. Finally, it is going to be > easier to faulty repair parts when you have working examples of them to > make > comparisons with than if you have no remaining working parts to guide you. > > Regards, > Peter Coghlan. > --===============5348617261997606050==-- From cclist@sydex.com Mon Nov 28 06:18:22 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Pertec controller; was: anybody need 1/2" tape drives? Date: Sun, 27 Nov 2022 22:17:53 -0800 Message-ID: <9b84a5e8-e2fc-7e26-8e9d-10788767b0bf@sydex.com> In-Reply-To: <7e7b6b3a-e0ea-c02d-6a9e-35a5ff4ce86e@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5814589935531782292==" --===============5814589935531782292== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/27/22 12:54, Jon Elson via cctalk wrote: > Anybody need some 1/2" 9-track tape drives? > I have a Pertec T9640 tape drive (vacuum column, 75 IPS 800/1600 Pertec > unformatted interface).  DEC sold this drive as the TU45.  I also have > an MDB MLSI-TM11 Q-bus tape controller that will run this drive on > either LSI-11 or uVAX II systems.  DEC does not supply a driver for this > setup on the uVAX, but I have source of the driver I used on VMS 4.7. > > I also have 2 CDC Keystone 92185 drives with formatted Pertec > interface.  These drives handle 1600/6250 BPI, and can start/stop at 25 > IPS or stream at 25 or 75 IPS.  The tape path is all air-bearing. > > I am located in the St. Louis, MO area. If anyone cares, I've been working on a Pertec tape controller design. The initial version worked remarkably well with only a few bodge wires. I'm assembling the respin of the design and do not anticipate any issues. It's basically a 4x6 inch PCB with a bunch of through-hole TTL hooked to a piggyback MCU. I've selected the STM32F407 Chinese boards as they're inexpensive and easily available from Aliexpress, unlike a lot of the other MCU boards which seem to have been hit by the chip shortage. My current controller is getting a bit cranky and I don't want to have to rely on it. In essence, any MCU with 3 or 4 8 bit 5v tolerant GPIO ports, with one of them being bidirectional can probably work. The MCU board that I'm using has a battery-backed RTC as well as integrated SDIO. Interface to the host is pretty much dumb terminal CLI-type with data transfer to the host using good old YMODEM, using either (depending on firmware assembly) async serial or USB 2.0 FS. Transfer uses a microSD card and has been verified to work with cards of up to 64GB capacity. The file system is exFAT, so this should work with Linux, Windows, etc. I've got a bit more assembly to do and then I'll be tweaking the firmware (the STM32F407 runs at 168 MHz and has 512K of program memory, as well as 192K of SRAM onboard). To date, I've tested it on the fastest drive that I have, a Fujitsu M2444AC streamer. The 1MB/sec transfer rate doesn't appear to be a problem even at 6250 GCR. Rather than using open-collector outputs to drive the formatter interface, I'm using tristate bus buffers with drive capability of 60ma. Until the interface is initialized, the outputs float, so, in theory, multiple controllers can share the bus. Power is supplied by a 5V 2A "wall wart" supply. The reverse direction is standard TTL level, terminated with 220/300 networks. That's about all I can think of tonight. If anyone is interested, I'll put you on my email status list. Eventually, I'd like to host the whole thing on Github. A special "thank you" is due Mattis Lind, who has done a super job of PCB layout (something that gives me a raging headache). I could not have done what you did in the time that you did it! All the best, Chuck --===============5814589935531782292==-- From elson@pico-systems.com Mon Nov 28 17:27:59 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Mon, 28 Nov 2022 11:27:40 -0600 Message-ID: In-Reply-To: <9b84a5e8-e2fc-7e26-8e9d-10788767b0bf@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6056187179089841076==" --===============6056187179089841076== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/28/22 00:17, Chuck Guzis via cctalk wrote: > > If anyone cares, I've been working on a Pertec tape controller design. > The initial version worked remarkably well with only a few bodge wires. > I'm assembling the respin of the design and do not anticipate any issues. I'm guessing this is a formatted Pertec interface. My CDC Keystone drives have that, and I hacked up one of my CNC control cards to make a read-only interface that communicates at modest speed over the PC parallel port. (These choices were not optimal, but reused infrastructure I already knew well.) MANY years ago, I got a surplus 800 BPI 9-track key to tape system and hacked into it to put 9-track tape on my Z-80 CP/M system. That was a fascinating project. Jon --===============6056187179089841076==-- From bfranchuk@jetnet.ab.ca Mon Nov 28 18:17:37 2022 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Mon, 28 Nov 2022 11:08:58 -0700 Message-ID: <3982a092-7c36-e475-e348-ca5dae71afc7@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7932733053957977979==" --===============7932733053957977979== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2022-11-28 10:27 a.m., Jon Elson via cctalk wrote: > MANY years ago, I got a surplus 800 BPI 9-track key to tape system and > hacked into it to put 9-track tape on my Z-80 CP/M system.  That was a > fascinating project. > Jon > What was the character encoding on that system? Ben. --===============7932733053957977979==-- From cclist@sydex.com Mon Nov 28 18:30:18 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Mon, 28 Nov 2022 10:29:48 -0800 Message-ID: <0fff847f-f44d-db84-2217-e0bcc5422eae@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9222984716740617712==" --===============9222984716740617712== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/28/22 09:27, Jon Elson via cctalk wrote: > I'm guessing this is a formatted Pertec interface.  My CDC Keystone > drives have that, and I hacked up one of my CNC control cards to make a > read-only interface that communicates at modest speed over the PC > parallel port. (These choices were not optimal, but reused > infrastructure I already knew well.) Yes, the interface to the formatter. Although, I suspect that with the current crop of MCUs, interface to the "naked" drive isn't beyond the pale--it's just that there was a considerable amount of variation in that by various vendors. My board has ICs mostly for interface. The real work is done by the MCU. I figure that a 64GB microSD should be good for at least 1,000 reels of 9 track tape. > MANY years ago, I got a surplus 800 BPI 9-track key to tape system and > hacked into it to put 9-track tape on my Z-80 CP/M system.  That was a > fascinating project. I still do that with an HP7970 equipped with the double-stack (7 and 9 track) RO heads. The naked interface goes directly to an MCU. Works well enough. I prefer naked or Pertec interface drives to SCSI because of the better control and information afforded by a more direct interface. --Chuck --===============9222984716740617712==-- From elson@pico-systems.com Mon Nov 28 18:58:30 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Mon, 28 Nov 2022 12:58:12 -0600 Message-ID: <27a2aa2b-6154-14d2-b650-0fded0745cb6@pico-systems.com> In-Reply-To: <3982a092-7c36-e475-e348-ca5dae71afc7@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1662017765032174991==" --===============1662017765032174991== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/28/22 12:08, ben via cctalk wrote: > On 2022-11-28 10:27 a.m., Jon Elson via cctalk wrote: > > >> MANY years ago, I got a surplus 800 BPI 9-track key to >> tape system and hacked into it to put 9-track tape on my >> Z-80 CP/M system.  That was a fascinating project. >> Jon >> > What was the character encoding on that system? I think it was originally EBCDIC, but I just tied in to points that were essentially similar to an unformatted Pertec interface. The drive only had a single data gap, so you had to write, backspace and read to verify that the write was good. I used the existing CRC generator. The character timing for writing was all in software loops, but reading waited for a character strobe from the drive electronics. I then took tapes in to work and read them on the VAX to verify the format was good. Jon --===============1662017765032174991==-- From cmhanson@eschatologist.net Tue Nov 29 19:27:46 2022 From: Chris Hanson To: cctalk@classiccmp.org Subject: [cctalk] Re: Data General Nova and Eclipse Hobbyist License... Date: Tue, 29 Nov 2022 11:17:42 -0800 Message-ID: In-Reply-To: <37c4683c-2816-fcf8-5196-210cec2a8890@WildHareComputers.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3555543537067544584==" --===============3555543537067544584== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Nov 17, 2022, at 10:12 PM, Bruce Ray via cctalk = wrote: > It is not a sublicense, Wild Hare Computer Systems, Inc., now has copyright= and title to the legacy DG/EMC software. That's awesome news, congratulations! -- Chris --===============3555543537067544584==-- From cube1@charter.net Tue Nov 29 21:32:14 2022 From: Jay Jaeger To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Tue, 29 Nov 2022 15:31:49 -0600 Message-ID: <145d145b-da76-2e48-7937-9f4e558412a0@charter.net> In-Reply-To: <9b84a5e8-e2fc-7e26-8e9d-10788767b0bf@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8164150549697590990==" --===============8164150549697590990== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/28/2022 12:17 AM, Chuck Guzis via cctalk wrote: > > If anyone cares, I've been working on a Pertec tape controller design. > The initial version worked remarkably well with only a few bodge wires. > I'm assembling the respin of the design and do not anticipate any issues. > > It's basically a 4x6 inch PCB with a bunch of through-hole TTL hooked to > a piggyback MCU. I've selected the STM32F407 Chinese boards as they're > inexpensive and easily available from Aliexpress, unlike a lot of the > other MCU boards which seem to have been hit by the chip shortage. > I very much care; indeed I had thoughts of maybe doing something similar, using a BeagleBone, but this sounds a lot easier. Would like to know exactly what board you chose, so I can acquire one. I have a cipher drive and an HP 88780A that would be good candidates to use with this / use this to test. I also have a DG drive that might well have a Pertec interface (haven't looked in a while). JRJ --===============8164150549697590990==-- From cclist@sydex.com Tue Nov 29 23:27:31 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Tue, 29 Nov 2022 15:21:18 -0800 Message-ID: <8341b71f-726e-f250-f85c-46c768ad29a9@sydex.com> In-Reply-To: <145d145b-da76-2e48-7937-9f4e558412a0@charter.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2664968999935175753==" --===============2664968999935175753== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/29/22 13:31, Jay Jaeger via cctalk wrote: > I very much care; indeed I had thoughts of maybe doing something > similar, using a BeagleBone, but this sounds a lot easier. > > Would like to know exactly what board you chose, so I can acquire one. I > have a cipher drive and an HP 88780A that would be good candidates to > use with this / use this to test.  I also have a DG drive that might > well have a Pertec interface (haven't looked in a while). Hi Jay, The board I'm using is the STM32F4VE, described here: https://stm32-base.org/boards/STM32F407VET6-STM32-F4VE-V2.0 Cheap and available; generally about $14-15 from Aliexpress. I've toyed with the STM32H750 board (very similar, but runs at 400Mhz; the added cost didn't contribute anything toward functionality. Your DG might well be Pertec-interface, but you can check that out with Bruce Ray. Oh, a word of caution is in order... With the chip shortage, a lot of Chinese vendors are re-labeling GDS32F407 and CKS32F407 chips with the ST logo and markings. I've run into a few, but generally, they perform as well as--and in some cases, better than, the real thing. I'll put you on my mailing list... All the best, Chuck --===============2664968999935175753==-- From bdweb@mindspring.com Wed Nov 30 00:00:45 2022 From: Bjoren Davis To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Tue, 29 Nov 2022 18:55:13 -0500 Message-ID: In-Reply-To: <8341b71f-726e-f250-f85c-46c768ad29a9@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1035525810434835224==" --===============1035525810434835224== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hello Chuck and Jay, I took this off list because I'm not sure people would be interested. I made a simple board with level shifters to allow me to use a PJRC Teensy 4.1 (https://www.pjrc.com/store/teensy41.html) with a Pertec interface.  I called it a "Pertexus". The Teensy is really nice because it's actually available, relatively cheap, and has Ethernet. The firmware I wrote creates a simple USB "serial" command line interface which allows me to read tapes to files on the SD card, write tape images from the SD card, and do a bunch of hairy diagnostic things.  I've only tested it with my Qualstar 1052 drive. In theory the setup could be used to emulate a drive, but I haven't actually tried that. Is this interesting to you? Thanks. --Bjoren On 11/29/2022 6:21 PM, Chuck Guzis via cctalk wrote: > On 11/29/22 13:31, Jay Jaeger via cctalk wrote: > >> I very much care; indeed I had thoughts of maybe doing something >> similar, using a BeagleBone, but this sounds a lot easier. >> >> Would like to know exactly what board you chose, so I can acquire one. I >> have a cipher drive and an HP 88780A that would be good candidates to >> use with this / use this to test.  I also have a DG drive that might >> well have a Pertec interface (haven't looked in a while). > Hi Jay, > > The board I'm using is the STM32F4VE, described here: > > https://stm32-base.org/boards/STM32F407VET6-STM32-F4VE-V2.0 > > Cheap and available; generally about $14-15 from Aliexpress. > > I've toyed with the STM32H750 board (very similar, but runs at 400Mhz; > the added cost didn't contribute anything toward functionality. > > Your DG might well be Pertec-interface, but you can check that out with > Bruce Ray. > > Oh, a word of caution is in order... With the chip shortage, a lot of > Chinese vendors are re-labeling GDS32F407 and CKS32F407 chips with the > ST logo and markings. I've run into a few, but generally, they perform > as well as--and in some cases, better than, the real thing. > > I'll put you on my mailing list... > > All the best, > Chuck > > > --===============1035525810434835224==-- From cc@informatik.uni-stuttgart.de Wed Nov 30 09:31:20 2022 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Wed, 30 Nov 2022 10:30:56 +0100 Message-ID: In-Reply-To: <9b84a5e8-e2fc-7e26-8e9d-10788767b0bf@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1527964637529242211==" --===============1527964637529242211== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 27 Nov 2022, Chuck Guzis wrote: > If anyone cares, I've been working on a Pertec tape controller design. > The initial version worked remarkably well with only a few bodge wires. > I'm assembling the respin of the design and do not anticipate any issues. I could really use some "Unformatted to Pertec" tape controllers. I have a bunch of ½" drives but no separate formatter. So ATM they are quite useless. Christian --===============1527964637529242211==-- From cclist@sydex.com Wed Nov 30 16:41:49 2022 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Wed, 30 Nov 2022 08:41:21 -0800 Message-ID: <4e202ce0-8d8e-0f5c-cc77-c5aeadea01ba@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6243730069512325216==" --===============6243730069512325216== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/30/22 01:30, Christian Corti via cctalk wrote: > On Sun, 27 Nov 2022, Chuck Guzis wrote: >> If anyone cares, I've been working on a Pertec tape controller design. >> The initial version worked remarkably well with only a few bodge wires. >> I'm assembling the respin of the design and do not anticipate any issues. > > I could really use some "Unformatted to Pertec" tape controllers. I have > a bunch of ½" drives but no separate formatter. So ATM they are quite > useless. It's not impossible, but was there a universal standard for the unformatted side of the affair? There are small differences between the formatted side between vendors as-is. I use an MCU as a formatter.controller on my HP7970 drive. But that's just an NRZI model, so it's pretty easy. --Chuck --===============6243730069512325216==-- From ard.p850ug1@gmail.com Wed Nov 30 16:47:19 2022 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Wed, 30 Nov 2022 16:46:43 +0000 Message-ID: In-Reply-To: <4e202ce0-8d8e-0f5c-cc77-c5aeadea01ba@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8851197055789380969==" --===============8851197055789380969== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Nov 30, 2022 at 4:41 PM Chuck Guzis via cctalk wrote: > > On 11/30/22 01:30, Christian Corti via cctalk wrote: > > On Sun, 27 Nov 2022, Chuck Guzis wrote: > >> If anyone cares, I've been working on a Pertec tape controller design. > >> The initial version worked remarkably well with only a few bodge wires. > >> I'm assembling the respin of the design and do not anticipate any issues. > > > > I could really use some "Unformatted to Pertec" tape controllers. I have > > a bunch of ½" drives but no separate formatter. So ATM they are quite > > useless. > > It's not impossible, but was there a universal standard for the > unformatted side of the affair? There are small differences between > the formatted side between vendors as-is. There is an unformatted Pertec interface, I've got at least one tape drive that uses it and have seen others. No idea if there are odd 'gotchas' between different drives though. It's 3 edge connectors, I think 0.156" pitch, all the same size (but without digging out the manuals I can't remember how many pins). Essentially, one is the write data signals, the second is the read data signals, and the third is the control signals. -tony --===============8851197055789380969==-- From elson@pico-systems.com Wed Nov 30 18:46:44 2022 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Wed, 30 Nov 2022 12:46:22 -0600 Message-ID: <523577f0-9491-58ca-8e3f-d494af06508a@pico-systems.com> In-Reply-To: <4e202ce0-8d8e-0f5c-cc77-c5aeadea01ba@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0425596431343194884==" --===============0425596431343194884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/30/22 10:41, Chuck Guzis via cctalk wrote: > On 11/30/22 01:30, Christian Corti via cctalk wrote: >> On Sun, 27 Nov 2022, Chuck Guzis wrote: >>> If anyone cares, I've been working on a Pertec tape controller design. >>> The initial version worked remarkably well with only a few bodge wires. >>> I'm assembling the respin of the design and do not anticipate any issues. >> >> I could really use some "Unformatted to Pertec" tape controllers. I have >> a bunch of ½" drives but no separate formatter. So ATM they are quite >> useless. > > It's not impossible, but was there a universal standard for the > unformatted side of the affair? There are small differences between > the formatted side between vendors as-is. > > I use an MCU as a formatter.controller on my HP7970 drive. But that's > just an NRZI model, so it's pretty easy. > > --Chuck > > NRZI is fairly simple, there is logic in the drive that produces a strobe approximately at the center of the character. For writing, there is a write gate that enables the erase head, and a data strobe. For PE, you just get the transitions from the read amps. Some drives have squelch that turns off the read signal until the amplitude exceeds a threshold. So, unformatted Pertec is as close to the signals on the tape as you can get in a digital format. Jon --===============0425596431343194884==-- From mooreericnyc@gmail.com Wed Nov 30 22:45:54 2022 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Re: Pertec controller; was: anybody need 1/2" tape drives? Date: Wed, 30 Nov 2022 14:45:17 -0800 Message-ID: In-Reply-To: <523577f0-9491-58ca-8e3f-d494af06508a@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8607179923773077118==" --===============8607179923773077118== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I have a kennedy 9100 with an unformatted pertec interface that I would love to use for imaging tapes from my AS/400 It seems like strapping a logic analyzer to the read connector, and an arduino on the command connector, may be fairly easily done? Has anyone done that? -Eric On Wed, Nov 30, 2022, 10:46 AM Jon Elson via cctalk wrote: > On 11/30/22 10:41, Chuck Guzis via cctalk wrote: > > On 11/30/22 01:30, Christian Corti via cctalk wrote: > >> On Sun, 27 Nov 2022, Chuck Guzis wrote: > >>> If anyone cares, I've been working on a Pertec tape controller design. > >>> The initial version worked remarkably well with only a few bodge wires. > >>> I'm assembling the respin of the design and do not anticipate any > issues. > >> > >> I could really use some "Unformatted to Pertec" tape controllers. I have > >> a bunch of ½" drives but no separate formatter. So ATM they are quite > >> useless. > > > > It's not impossible, but was there a universal standard for the > > unformatted side of the affair? There are small differences between > > the formatted side between vendors as-is. > > > > I use an MCU as a formatter.controller on my HP7970 drive. But that's > > just an NRZI model, so it's pretty easy. > > > > --Chuck > > > > > NRZI is fairly simple, there is logic in the drive that > produces a strobe approximately at the center of the > character. For writing, there is a write gate that enables > the erase head, and a data strobe. > > For PE, you just get the transitions from the read amps. > Some drives have squelch that turns off the read signal > until the amplitude exceeds a threshold. > > So, unformatted Pertec is as close to the signals on the > tape as you can get in a digital format. > Jon > --===============8607179923773077118==-- From hi@senzilla.io Mon Feb 13 08:46:25 2023 From: hi@senzilla.io To: cctalk@classiccmp.org Subject: [cctalk] Seeking a Sun monitor with 13W3 interface Date: Sun, 06 Nov 2022 15:11:02 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3473915101599727727==" --===============3473915101599727727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I'm seeking to buy a Sun Microsystems monitor with a 13W3 interface. Ideally somewhere around central Europe for pickup in person. But I'm happy t= o consider shipping options as well. Background: I'm looking to complete a Sun Ultra 1 build that I've been collec= ting parts for =F0=9F=99=82 Best regards, D.O. --===============3473915101599727727==-- From cctalk@beyondthepale.ie Mon Feb 13 08:46:25 2023 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking a Sun monitor with 13W3 interface Date: Tue, 08 Nov 2022 12:28:16 +0000 Message-ID: <01SK3HUJ9NXG8WYOLI@beyondthepale.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3818499300473587172==" --===============3818499300473587172== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > > I'm seeking to buy a Sun Microsystems monitor with a 13W3 interface. > > Ideally somewhere around central Europe for pickup in person. But I'm happy > to consider shipping options as well. > I have a GDM1604B40 monitor (Sony Trinitron design) with a 13W3 connector. I don't know if it works or not. It is missing the on/off switch which I borrowed to repair my DEC VR297. It is located on the east coast of Ireland on the EU side of the border. It weighs about 28kg. Regards, Peter Coghlan. > > Background: I'm looking to complete a Sun Ultra 1 build that I've been > collecting parts for 🙂 > > > > Best regards, > > D.O. --===============3818499300473587172==--