From mloewen@cpumagic.scol.pa.us Wed Feb 1 00:02:15 2023 From: Mike Loewen To: cctalk@classiccmp.org Subject: [cctalk] Re: windows reports contents of previous floppy Date: Tue, 31 Jan 2023 19:01:31 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0538664717201661256==" --===============0538664717201661256== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 31 Jan 2023, Tony Jones via cctalk wrote: > On Tue, Jan 31, 2023, 3:39 PM Tom Hunter via cctalk > wrote: > >> This is not the forum to ask MS Windows questions. >> > > Chris. Can I ask you stop and consider if you really need to post/reply. > Not every thought that enters ones head needs to be translated into a list > posting It feels like a stream of consciousness sometimes. I second the motion. --===============0538664717201661256==-- From cctalk@ibm51xx.net Wed Feb 1 00:03:51 2023 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 16:03:12 -0800 Message-ID: <010401d935d0$93f22550$bbd66ff0$@net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0423125029819493650==" --===============0423125029819493650== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I thought Flash could only hold the data in them X amount of years > until > the junctions discharge or whatever? It's less permanent than decent > quality optical or pro magnetic media? > > You have to plug them in every so often to refresh I believe. Does REFRESHING mean reread and rewrite or just keep power to it? If it's the latter it should be trivial to setup a system with backup battery just to supply voltage to a bunch of SSD drives. -Ali --===============0423125029819493650==-- From cisin@xenosoft.com Wed Feb 1 00:17:39 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 5150 cassette (Was: DLOAD BASIC command for Color Comp Date: Tue, 31 Jan 2023 16:17:01 -0800 Message-ID: In-Reply-To: <010301d935ce$bf157590$3d4060b0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2547607147914132812==" --===============2547607147914132812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> (~$300), monitor (CGA had compoosite output, so could connect to cheap >> CCTV, etc. monitors, and CGA even had a dedicated 4 pin Berg for the >> SupRMod RF adapter), and maybe serial, and/or parallel. On Tue, 31 Jan 2023, Ali wrote: > Fred, > This is the first time I am hearing about this. I always thought the connec= tor was for light pen input. CGA had a DE-9 for video, (warning: incompatible with the DE9 MDP=20 connector, and incompatible with the bus mouse DE9) plus an RCA for composite video, plus a 4 pin Berg with composite video and power for an RF-modulator.=20 SupRMod was simply one of the most common after-market RF modulators that=20 used that 4 pin Berg. 1 12 volts 2 key 3 composite video 4 ground (I am not sure whether "Berg" is the correct term for those connectors) plus a 6 pin Berg for light pen, 1 light pen input 2 key 3 light pen switch 4 ground 5 5 volts 6 12 volts IBM's manual for it: (with schematics) https://minuszerodegrees.net/oa/OA%20-%20IBM%20Color%20Graphics%20Monitor%20A= dapter%20(CGA).pdf As far as I know, IBM did not offer an RF modulator nor a light pen. after market was available. The phosphor of the IBM monochrome monitor was too long a persistance for=20 light pen. Compaq CGA and EGA boards ALSO had a mid-board 10 pin dual-row connector=20 for connecting to the Compaq portable internal monitor (12 pin but keyed) EGA-Wonder had an add-on board for Compaq compatability. Compaq boards were recognizable by the additional 90 degree bend at the=20 top of the board bracket, by a cutout in the bracket for access to the 4=20 pin Berg composite, and the connector for the internal monitor https://oldcrap.org/2020/10/08/compaq-portable/ (I am not sure whether "Berg" is the correct term for those connectors) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============2547607147914132812==-- From cisin@xenosoft.com Wed Feb 1 00:35:36 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 5150 cassette (Was: DLOAD BASIC command for Color Comp Date: Tue, 31 Jan 2023 16:34:58 -0800 Message-ID: In-Reply-To: <010301d935ce$bf157590$3d4060b0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4698697755506622363==" --===============4698697755506622363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The 4 pin RF modulator conector is the same as what is on the Apple2 On Tue, 31 Jan 2023, Ali wrote: >> (~$300), monitor (CGA had compoosite output, so could connect to cheap >> CCTV, etc. monitors, and CGA even had a dedicated 4 pin Berg for the >> SupRMod RF adapter), and maybe serial, and/or parallel. > > Fred, > > This is the first time I am hearing about this. I always thought the connec= tor was for light pen input. > > -Ali --===============4698697755506622363==-- From cisin@xenosoft.com Wed Feb 1 00:41:32 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: windows reports contents of previous floppy Date: Tue, 31 Jan 2023 16:40:55 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6237436746484157207==" --===============6237436746484157207== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 1 Feb 2023, Tom Hunter via cctalk wrote: > This is not the forum to ask MS Windows questions. while I agree in priciple, the problem with pin 34 being expected to be "Disk Change" surfaced about 35 years ago, when IBM, on the AT, repurposed the "Drive Ready" signal, --===============6237436746484157207==-- From imp@bsdimp.com Wed Feb 1 01:39:09 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 18:38:16 -0700 Message-ID: In-Reply-To: <010401d935d0$93f22550$bbd66ff0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8606542345114122302==" --===============8606542345114122302== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Jan 31, 2023, 5:03 PM Ali via cctalk wrote: > > I thought Flash could only hold the data in them X amount of years > > until > > the junctions discharge or whatever? It's less permanent than decent > > quality optical or pro magnetic media? > > > > You have to plug them in every so often to refresh I believe. > > Does REFRESHING mean reread and rewrite or just keep power to it? If it's > the latter it should be trivial to setup a system with backup battery just > to supply voltage to a bunch of SSD drives. > It depends on the drive's firmware. Some do background scans of blocks while idle. Others do not. Since you have no way of knowing which is which (or even when the backgroundscan is done), the safest way to force a scan is to read the whole drive... any blocks whose raw error count is too high will be rewritten to fresh blocks. If it's a good SSD you'll likely not notice this happening. If it's a crappy thumb drive... you may be better off copying to some other media.. Warner -Ali > > --===============8606542345114122302==-- From paulkoning@comcast.net Wed Feb 1 01:45:14 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 20:44:27 -0500 Message-ID: <95B3217F-DBA3-4633-932C-533BBE8DEBD7@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4363652835785568970==" --===============4363652835785568970== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Jan 31, 2023, at 8:38 PM, Warner Losh via cctalk wrote: >=20 > On Tue, Jan 31, 2023, 5:03 PM Ali via cctalk wrot= e: >=20 >>> I thought Flash could only hold the data in them X amount of years >>> until >>> the junctions discharge or whatever? It's less permanent than decent >>> quality optical or pro magnetic media? >>>=20 >>> You have to plug them in every so often to refresh I believe. >>=20 >> Does REFRESHING mean reread and rewrite or just keep power to it? If it's >> the latter it should be trivial to setup a system with backup battery just >> to supply voltage to a bunch of SSD drives. >>=20 >=20 > It depends on the drive's firmware. Some do background scans of blocks > while idle. Others do not. Since you have no way of knowing which is which > (or even when the backgroundscan is done), the safest way to force a scan > is to read the whole drive... any blocks whose raw error count is too high > will be rewritten to fresh blocks. If it's a good SSD you'll likely not > notice this happening. If it's a crappy thumb drive... you may be better > off copying to some other media.. >=20 > Warner Do you know what the likely answer is for "memory sticks", SD or MicroSD card= s, things like that? I assume their firmware is tiny, so are they likely to = need active refreshing? paul --===============4363652835785568970==-- From imp@bsdimp.com Wed Feb 1 01:53:07 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 18:52:13 -0700 Message-ID: In-Reply-To: <95B3217F-DBA3-4633-932C-533BBE8DEBD7@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2192432163009643775==" --===============2192432163009643775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Jan 31, 2023, 6:44 PM Paul Koning wrote: > > > > On Jan 31, 2023, at 8:38 PM, Warner Losh via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > On Tue, Jan 31, 2023, 5:03 PM Ali via cctalk > wrote: > > > >>> I thought Flash could only hold the data in them X amount of years > >>> until > >>> the junctions discharge or whatever? It's less permanent than decent > >>> quality optical or pro magnetic media? > >>> > >>> You have to plug them in every so often to refresh I believe. > >> > >> Does REFRESHING mean reread and rewrite or just keep power to it? If > it's > >> the latter it should be trivial to setup a system with backup battery > just > >> to supply voltage to a bunch of SSD drives. > >> > > > > It depends on the drive's firmware. Some do background scans of blocks > > while idle. Others do not. Since you have no way of knowing which is > which > > (or even when the backgroundscan is done), the safest way to force a scan > > is to read the whole drive... any blocks whose raw error count is too > high > > will be rewritten to fresh blocks. If it's a good SSD you'll likely not > > notice this happening. If it's a crappy thumb drive... you may be better > > off copying to some other media.. > > > > Warner > > Do you know what the likely answer is for "memory sticks", SD or MicroSD > cards, things like that? I assume their firmware is tiny, so are they > likely to need active refreshing? > They are on the "copy it every so often" end of things. Especially if they were slow when released. Warner > --===============2192432163009643775==-- From cctalk@ibm51xx.net Wed Feb 1 02:19:50 2023 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 18:19:11 -0800 Message-ID: <011b01d935e3$9361d190$ba2574b0$@net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0915517447771242138==" --===============0915517447771242138== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >It depends on the drive's firmware. Some do background scans of blocks while= idle. Others do not. Since you >have no way of knowing which is which (or ev= en when the backgroundscan is done), the safest way to force a >scan is to re= ad the whole drive... any blocks whose raw error count is too high will be re= written to fresh >blocks. If it's a good SSD you'll likely not notice this ha= ppening. If it's a crappy thumb drive... you may >be better off copying to s= ome other media.. Hmmm.. I wonder if there is a program akin to Spinrite that will do that on S= SDs (i.e. reread and rewrite every byte). I know Steve Gibson is working on a= new version of Spinrite that will work with SSDs so that could be the soluti= on when it comes out... -Ali --===============0915517447771242138==-- From cclist@sydex.com Wed Feb 1 02:23:29 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 18:22:45 -0800 Message-ID: <862480a3-f3a0-55a6-01f7-de568968e12c@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8048485240654892459==" --===============8048485240654892459== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I just checked and I can still read without error some 8" disks that I wrote, what, 45 years ago. They were FM 3740-type format and good quality, so there's that. As to the value of the 8080 code that I wrote, not so much. This was only possible because I wrote the disks in a commonly-used format on a relatively common medium. Had I opted to use Memorex 651 media, it might well be gone forever. I haven't seen a 651 drive in years. Which is why I wasn't joking about using 9 track 1/2" tape. Many millions of reels of the stuff were in use right up into the 1980s. The drives are not unobtanium and the medium is pretty rugged. Had I used 7-track tape, I would still not be out of luck, but only because I have a 7 track drive, which is far less common these days. Just some food for thought. --Chuck --===============8048485240654892459==-- From cisin@xenosoft.com Wed Feb 1 02:27:44 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 18:27:08 -0800 Message-ID: In-Reply-To: <011b01d935e3$9361d190$ba2574b0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4035901512284185034==" --===============4035901512284185034== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 31 Jan 2023, Ali via cctalk wrote: > Hmmm.. I wonder if there is a program akin to Spinrite that will do that > on SSDs (i.e. reread and rewrite every byte). I know Steve Gibson is > working on a new version of Spinrite that will work with SSDs so that > could be the solution when it comes out... If you just need READ, and not WRITE, howzbout COPY *.* NUL actually XCOPY *.* NUL /S/E to include subdirectories --===============4035901512284185034==-- From cclist@sydex.com Wed Feb 1 02:48:12 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 18:47:29 -0800 Message-ID: <5bf8ab8f-1971-64da-b886-7c5a08f25034@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6973208995631707863==" --===============6973208995631707863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 1/31/23 18:27, Fred Cisin via cctalk wrote: > On Tue, 31 Jan 2023, Ali via cctalk wrote: >> Hmmm.. I wonder if there is a program akin to Spinrite that will do >> that on SSDs (i.e. reread and rewrite every byte). I know Steve Gibson >> is working on a new version of Spinrite that will work with SSDs so >> that could be the solution when it comes out... > > If you just need READ, and not WRITE, howzbout COPY *.* NUL > actually > XCOPY *.* NUL /S/E > to include subdirectories On Linux, that would be: cp -r / /dev/null I think that you really don't want to rewrite SSDs. As I understand the wear-leveling technology, it's unlikely that you'll write the same sector/block that you read. Basically Heraclitus and rivers. --CHuck --===============6973208995631707863==-- From cctalk@ibm51xx.net Wed Feb 1 04:17:14 2023 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 20:16:29 -0800 Message-ID: <013e01d935f3$f5e968e0$e1bc3aa0$@net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8765229807738606551==" --===============8765229807738606551== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > If you just need READ, and not WRITE, howzbout COPY *.* NUL > actually > XCOPY *.* NUL /S/E > to include subdirectories But would a red suffice to refresh or do you need to also write? Also, this solution, and Chuck's, while workable for reads would leave you with a blank screen for a long time (e.g. xcopying to NUL a 512GB or bigger SSD). If I remember Spinrite would read and write each sector back in Level I or II and gave you a constant update.... I still have a license from long ago.... I think the last version came out in early 2000s... -Ali --===============8765229807738606551==-- From sellam.ismail@gmail.com Wed Feb 1 04:17:44 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 20:16:50 -0800 Message-ID: In-Reply-To: <862480a3-f3a0-55a6-01f7-de568968e12c@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7830552463247474810==" --===============7830552463247474810== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Jan 31, 2023 at 6:22 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > I just checked and I can still read without error some 8" disks that I > wrote, what, 45 years ago. They were FM 3740-type format and good > quality, so there's that. > In all my days of doing data conversion professionally (throughout the 2000-aughts), it was rare that I got an 8" disk that had any problems reading. Or any other format for that matter. Magnetic media in my experience seems to hold up well if stored properly. > Which is why I wasn't joking about using 9 track 1/2" tape. Many > millions of reels of the stuff were in use right up into the 1980s. > The drives are not unobtanium and the medium is pretty rugged. Had I > used 7-track tape, I would still not be out of luck, but only because I > have a 7 track drive, which is far less common these days. I rarely had any issues reading 9-track tapes either. I believe I might still have a 7-track drive. Sellam --===============7830552463247474810==-- From ard.p850ug1@gmail.com Wed Feb 1 04:27:53 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: 5150 cassette (Was: DLOAD BASIC command for Color Comp Date: Wed, 01 Feb 2023 04:27:06 +0000 Message-ID: In-Reply-To: <010301d935ce$bf157590$3d4060b0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8056059621791840116==" --===============8056059621791840116== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2023 at 11:50 PM Ali via cctalk wro= te: > > > (~$300), monitor (CGA had compoosite output, so could connect to cheap > > CCTV, etc. monitors, and CGA even had a dedicated 4 pin Berg for the > > SupRMod RF adapter), and maybe serial, and/or parallel. > > Fred, > > This is the first time I am hearing about this. I always thought the connec= tor was for light pen input. No, that's the 6 pin Berg alongside it. IIRC the MDA card had the light pen connector too, but it was never documented or supported as the long persistence of the 5151 monitor meant that a light pen wouldn't work with it. -tony --===============8056059621791840116==-- From cclist@sydex.com Wed Feb 1 05:01:17 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Tue, 31 Jan 2023 21:00:31 -0800 Message-ID: In-Reply-To: <013e01d935f3$f5e968e0$e1bc3aa0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8380451073289942924==" --===============8380451073289942924== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 1/31/23 20:16, Ali via cctalk wrote: > If I remember Spinrite would read and write each sector back in Level I or > II and gave you a constant update.... I still have a license from long > ago.... I think the last version came out in early 2000s... If you look at the specs for SSDs or any flash medium for that matter, they're rated in terms of *write* cycles, which is why you don't want to abuse that. However, it may well be that writing is the only way to refresh cells, as reading won't, if I understand flash operation correctly. But rewriting a sector or block of a file doesn't usually write back to the original, because of the write-leveling firmware in the drive. JEDEC requires data retention of a consumer drive for at least 1 year, which doesn't sound like much; real retention is probably much longer. You can write a script that write-refreshes every file on the drive. The easiest thing is to buy a second drive and ping-pong the data between them periodically. That way, if one fails, you still have the other for backup. FWIW, Chuck --===============8380451073289942924==-- From cc@informatik.uni-stuttgart.de Wed Feb 1 08:37:50 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer of Thesus (was: Re: Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Wed, 01 Feb 2023 09:37:08 +0100 Message-ID: <80c55f81-737b-5e52-2fa3-dcdfe7b689c7@informatik.uni-stuttgart.de> In-Reply-To: <1069043389.1534693.1675170878433@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8390547512664156017==" --===============8390547512664156017== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 31 Jan 2023, skogkatt007(a)yahoo.com wrote: > separating the 2. So please stop complaining. Learn to adapt and > overcome. Stop being rude and adapt to the standard! Quotation is done with a ">" (one for each level) at the beginning of a line, the indention block is superseded with the author, like this: > On Tuesday, January 31, 2023, 06:30:18 AM EST, Liam Proven > via cctalk wrote: >> On Wed, 25 Jan 2023 at 08:09, Christian Corti via cctalk >> wrote: [...] You see? All good mail clients will do this automatically. Christian --===============8390547512664156017==-- From emu@e-bbes.com Wed Feb 1 08:41:40 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 03:20:20 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7526516869562377378==" --===============7526516869562377378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-01 00:00, Chuck Guzis via cctalk wrote: > On 1/31/23 20:16, Ali via cctalk wrote: > If you look at the specs for SSDs or any flash medium for that matter, > they're rated in terms of *write* cycles, which is why you don't want to > abuse that. right But, in most OS you can check the SMART data, to get an idea > However, it may well be that writing is the only way to refresh cells, > as reading won't, if I understand flash operation correctly. Reading ensures, that the cells are checked. if they fall below specific thresholds, they will be copied to another block > But > rewriting a sector or block of a file doesn't usually write back to the > original, because of the write-leveling firmware in the drive. right > JEDEC requires data retention of a consumer drive for at least 1 year, > which doesn't sound like much; real retention is probably much longer. retension in case of power off. If the power is applied all the time, the internal controller "can" check the quality of the cells automatically (but this really depends on the controller, controller version, and the OS has to chose the right strategy. And the controllers improved a lot lately) > You can write a script that write-refreshes every file on the drive. Please don't :) Just tell the controller to run a refresh ... > The easiest thing is to buy a second drive and ping-pong the data > between them periodically. That way, if one fails, you still have the > other for backup. Disagree here, just run a compare between the two drives. a.) it will read all files, and the controller checks them in the background (will move them, if necessary) b.) you know, that after the compare you still have the data twice, on independent drives cheers --===============7526516869562377378==-- From cc@informatik.uni-stuttgart.de Wed Feb 1 08:42:13 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Media longevity (Was: Computer Museum uses GreaseWeazle Date: Wed, 01 Feb 2023 09:40:55 +0100 Message-ID: <86c857-3b81-658d-b09-6a8ff02019b7@informatik.uni-stuttgart.de> In-Reply-To: <615844368.1714993.1675193977465@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4239566675940475669==" --===============4239566675940475669== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 31 Jan 2023, skogkatt007(a)yahoo.com wrote: > Grumpy Ol' Fred cisin(a)xenosoft.com > > C: I'm all ears. That is the best example of how *not to quote* ! Christian --===============4239566675940475669==-- From skogkatt007@yahoo.com Wed Feb 1 13:48:07 2023 From: skogkatt007@yahoo.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer of Thesus (was: Re: Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Wed, 01 Feb 2023 13:47:23 +0000 Message-ID: <2043057209.2003095.1675259243799@mail.yahoo.com> In-Reply-To: <80c55f81-737b-5e52-2fa3-dcdfe7b689c7@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7658105116745151033==" --===============7658105116745151033== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You stop being rude you big burly baby. Get a life. I'm not your hobby, as h= ard as you're trying to make me so. On Wednesday, February 1, 2023, 03:37:20 AM EST, Christian Corti via cct= alk wrote: =20 =20 On Tue, 31 Jan 2023, skogkatt007(a)yahoo.com wrote: > separating the 2. So please stop complaining. Learn to adapt and=20 > overcome. Stop being rude and adapt to the standard! Quotation is done with a ">" (one for each level) at the beginning of a=20 line, the indention block is superseded with the author, like this: > On Tuesday, January 31, 2023, 06:30:18 AM EST, Liam Proven=20 > via cctalk wrote: >> On Wed, 25 Jan 2023 at 08:09, Christian Corti via cctalk >> wrote: [...] You see? All good mail clients will do this automatically. Christian =20 --===============7658105116745151033==-- From wdonzelli@gmail.com Wed Feb 1 15:26:38 2023 From: William Donzelli To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer of Thesus (was: Re: Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Wed, 01 Feb 2023 10:25:47 -0500 Message-ID: In-Reply-To: <2043057209.2003095.1675259243799@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7019705746812712547==" --===============7019705746812712547== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Plonk! -- Will On Wed, Feb 1, 2023 at 8:47 AM Chris via cctalk wro= te: > > You stop being rude you big burly baby. Get a life. I'm not your hobby, as= hard as you're trying to make me so. > > > On Wednesday, February 1, 2023, 03:37:20 AM EST, Christian Corti via c= ctalk wrote: > > On Tue, 31 Jan 2023, skogkatt007(a)yahoo.com wrote: > > separating the 2. So please stop complaining. Learn to adapt and > > overcome. > > Stop being rude and adapt to the standard! > Quotation is done with a ">" (one for each level) at the beginning of a > line, the indention block is superseded with the author, like this: > > > On Tuesday, January 31, 2023, 06:30:18 AM EST, Liam Proven > > via cctalk wrote: > >> On Wed, 25 Jan 2023 at 08:09, Christian Corti via cctalk > >> wrote: > [...] > > You see? All good mail clients will do this automatically. > > Christian > --===============7019705746812712547==-- From paul.kimpel@digm.com Wed Feb 1 15:47:45 2023 From: Paul Kimpel To: cctalk@classiccmp.org Subject: [cctalk] Re: Mechanical Selectric keyboards on video terminals (was Re: Typing class in high school) Date: Wed, 01 Feb 2023 07:21:31 -0800 Message-ID: In-Reply-To: <2ce7c959-927b-33a6-6302-034ff4345093@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8700397838915890234==" --===============8700397838915890234== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 1/30/2023 14:38, Chuck Guzis via cctalk wrote: > On 1/30/23 14:11, Sellam Abraham via cctalk wrote: > >> >> And the PDP-1. > > ...and let's not forget Gog! (1954) > > https://i.imgur.com/j8VsH0s.png > > That same flick shows a Bendix cmputer > > https://i.imgur.com/8ezAtKr.png > > Don't know what model, however--awfully early for Bendix. > > --Chuck That Bendix box in the lower-right of the picture looks more like a power supply or power regulator if it's anything other than some junk thrown together by the prop department. Harry Huskey designed the G-15 in 1952-53, but the G-15A wasn't delivered to customers until 1956 and the better-known G-16D in 1957. Bendix also made avionics, however, and a standalone electronic differential analyzer, the D-12, that was available by at least 1953: http://ed-thelen.org/comp-hist/BRL2nd/B.pdf http://www.bitsavers.org/pdf/bendix/d-12/D-12_Description_Mar54.pdf The table, typewriter, and plotter shown in the ed-thelen.org link above look a lot like the ones in the first frame above from Gog. Bendix also had a later DDA, the DA-1, that attached to the G-15 and used some of the lines on the G-15's drum for intermediate storage. --===============8700397838915890234==-- From imp@bsdimp.com Wed Feb 1 15:57:48 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 08:56:59 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7389520869382439556==" --===============7389520869382439556== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, Feb 1, 2023 at 1:41 AM emanuel stiebler via cctalk < cctalk(a)classiccmp.org> wrote: > On 2023-02-01 00:00, Chuck Guzis via cctalk wrote: > > On 1/31/23 20:16, Ali via cctalk wrote: > > > If you look at the specs for SSDs or any flash medium for that matter, > > they're rated in terms of *write* cycles, which is why you don't want to > > abuse that. > right > But, in most OS you can check the SMART data, to get an idea > > > However, it may well be that writing is the only way to refresh cells, > > as reading won't, if I understand flash operation correctly. > > Reading ensures, that the cells are checked. if they fall below specific > thresholds, they will be copied to another block > Indeed. It triggers the usual reliability engine in the drive. All data in NAND is stored with a number of redundant bits so that up to N errors can happen and the data can be recovered. All NAND has a read error signal that triggers well below N so that the data is all read and reconstructed (this is normal on all reads), so it can then be written directly to the new space. Also, this isn't usually done on a PAGE pasis inside the NAND, but on an entire erase block basis, because it's a leading indicator of problems to come. Writing this data to a freshly erased block will mena it can be read for some time into the future. > > But > > rewriting a sector or block of a file doesn't usually write back to the > > original, because of the write-leveling firmware in the drive. > > right > Right. > > JEDEC requires data retention of a consumer drive for at least 1 year, > > which doesn't sound like much; real retention is probably much longer. > > retension in case of power off. > If the power is applied all the time, the internal controller "can" > check the quality of the cells automatically (but this really depends on > the controller, controller version, and the OS has to chose the right > strategy. And the controllers improved a lot lately) > The OS might not have a choice. All the SSDs that I've used in the past decade at $WORK have not exposed any of this to the host, not even enough stats to know when it's going on in real time... let alone the ability to pause these operations for a little while until we're off peak for the day... And JEDEC retention is also at 20C, when the NAND is maximally worn, with certain data access / write patterns leading up to that wear. Most other wear patterns, especially archival ones, can lead one to expect a much longer retention in all but the tiniest processes storing 3 or 4 bits per cell. > > You can write a script that write-refreshes every file on the drive. > > Please don't :) > Just tell the controller to run a refresh ... > It would be even worse: since it could also trigger additional writes as the new LBAs are written because the old erase blocks they are in are now almost empty and new erase blocks will be needed to write the new LBAs that are flooding the drive. The writes, and the amplification writes will cause way more wear and tear on the drive than doing a read scan of the whole drive (assuming you are impatient about leaving the drive powered for the internal refresh...) > > The easiest thing is to buy a second drive and ping-pong the data > > between them periodically. That way, if one fails, you still have the > > other for backup. > > Disagree here, just run a compare between the two drives. > a.) it will read all files, and the controller checks them in the > background (will move them, if necessary) > b.) you know, that after the compare you still have the data twice, on > independent drives > c) You have less wear on both drives. While a read could trigger a move due to read disturb, but that's only after tens of thousands (or more) reads. Warner --===============7389520869382439556==-- From healyzh@avanthar.com Wed Feb 1 16:18:54 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 08:18:14 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8310725285299803070==" --===============8310725285299803070== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Jan 31, 2023, at 1:26 PM, David Glover-Aoki via cctalk wrote: >=20 > On Jan 29, 2023, at 9:37 PM, Zane Healy via cctalk wrote: >>=20 >> Some of the floppies I=E2=80=99m recovering data look to be either a multi= -part ZIP file, or something. Was this a separate product from PKZIP? I=E2= =80=99m not sure if I have a copy of PKZIP in the stuff I=E2=80=99ve recovere= d thus far. I=E2=80=99ve not pulled them into DOSBOX to try and restore them= , so far I=E2=80=99ve just tried to use Stuffit-Expander. Part of the probl= em is every file has the same name, just on different floppies. >=20 > Info-ZIP still supports "split" archives, and spanned archives can be conve= rted to split archives by renaming them to the appropriate extension. From th= e man page: >=20 > zip version 3.0 and later can create split archives. A split archive is a = standard zip archive split over multiple files. (Note that split archives ar= e not just archives split in to pieces, as the offsets of entries are now bas= ed on the start of each split. Concatenating the pieces together will invali= date these offsets, but unzip can usually deal with it. zip will usually ref= use to process such a spliced archive unless the -FF fix option is used to fi= x the offsets.) >=20 > One use of split archives is storing a large archive on multiple removable = media. For a split archive with 20 split files the files are typically named= (replace ARCHIVE with the name of your archive) ARCHIVE.z01, ARCHIVE.z02, ..= ., ARCHIVE.z19, ARCHIVE.zip. Note that the last file is the .zip file. In co= ntrast, spanned archives are the original multi-disk archive generally requir= ing floppy disks and using volume labels to store disk numbers. zip supports= split archives but not spanned archives, though a procedure exists for conve= rting split archives of the right size to spanned archives. The reverse is a= lso true, where each file of a spanned archive can be copied in order to file= s with the above names to create a split archive. >=20 > A split archive with missing split files can be fixed using -F if you have = the last split of the archive (the .zip file). If this file is missing, you = must use -FF to fix the archive, which will prompt you for the splits you hav= e. >=20 > David. So far I=E2=80=99ve tackled one split zip. I wasn=E2=80=99t having any luck = with the version of PKZIP that I assume created this. I copied the files int= o a directory, and did COPY FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP= COMBINED.ZIP That still wasn=E2=80=99t working, as the file was corrupt, but I managed to = use PKZIPFIX to fix it, and then I could unzip it. The info above will defin= itely help, especially with regards to the ZIPs missing the first part. Slowly I=E2=80=99m recovering my old DOS system. Zane --===============8310725285299803070==-- From david@kdbarto.org Wed Feb 1 16:29:15 2023 From: David Barto To: cctalk@classiccmp.org Subject: [cctalk] CD-R, DVD-R media available Date: Wed, 01 Feb 2023 08:28:35 -0800 Message-ID: <7379A8B9-7384-43B1-B574-747BDEA04585@kdbarto.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2961552205541345723==" --===============2961552205541345723== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 100’s of CD-R, Sony, TDK, and FujiFilm. 25-30 DVD-R Sony and TDK And CD cases sufficient to hold all the disks Heavy, available for the cost of shipping. I’m in San Diego, so local delivery is possible. David --===============2961552205541345723==-- From anders.k.nelson@gmail.com Wed Feb 1 16:52:32 2023 From: Anders Nelson To: cctalk@classiccmp.org Subject: [cctalk] Re: CD-R, DVD-R media available Date: Wed, 01 Feb 2023 11:51:43 -0500 Message-ID: In-Reply-To: <7379A8B9-7384-43B1-B574-747BDEA04585@kdbarto.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4697062804290639782==" --===============4697062804290639782== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Does anyone here know which brands/lines had the best longevity? -- Anders Nelson On Wed, Feb 1, 2023 at 11:28 AM David Barto via cctalk < cctalk(a)classiccmp.org> wrote: > 100’s of CD-R, Sony, TDK, and FujiFilm. > 25-30 DVD-R Sony and TDK > > And CD cases sufficient to hold all the disks > > Heavy, available for the cost of shipping. > I’m in San Diego, so local delivery is possible. > > David > > --===============4697062804290639782==-- From cctalk@ibm51xx.net Wed Feb 1 17:03:09 2023 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 09:02:25 -0800 Message-ID: <003c01d9365e$f6405fe0$e2c11fa0$@net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1028794528679998865==" --===============1028794528679998865== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > However, it may well be that writing is the only way to refresh cells, > as reading won't, if I understand flash operation correctly. But > rewriting a sector or block of a file doesn't usually write back to the > original, because of the write-leveling firmware in the drive. Chuck, But does that matter? If the main purpose is to be able to refresh the data s= o it is readable does it matter that the data is not in the same block as lon= g as it is readable? -Ali --===============1028794528679998865==-- From healyzh@avanthar.com Wed Feb 1 17:04:58 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Aging of unused CD-R media Date: Wed, 01 Feb 2023 09:04:22 -0800 Message-ID: <86ACF21A-2927-4C7A-9264-2DFE3253261C@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8953783337156867160==" --===============8953783337156867160== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I find myself wondering, how well does CD-R and DVD-R media that hasn=E2=80= =99t been used age? I have quite a bit of unused Verbatim DataLifePlus, as w= ell as some other media that=E2=80=99s unused. For the most part, I don=E2=80=99t need it, but I can see a couple reasons I = might want to burn some in the future, mainly to exchange data with older sys= tems. Zane --===============8953783337156867160==-- From healyzh@avanthar.com Wed Feb 1 17:08:05 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: CD-R, DVD-R media available Date: Wed, 01 Feb 2023 09:07:22 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2899518951304260989==" --===============2899518951304260989== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kodak Gold CD-R=E2=80=99s were supposed to be the best as I recall. The Verbatim DataLifePlus are definitely long lived.=20 I can=E2=80=99t remember if I=E2=80=99ve found any Sony or TDK disks in the s= tuff I=E2=80=99ve recovered recently, I believe I used both on occasion, but = not for archives (though I=E2=80=99ve recovered CD=E2=80=99s I didn=E2=80=99t= intend to be archives). I have no experience with FujiFilm, except for DLT = Tapes. Zane > On Feb 1, 2023, at 8:51 AM, Anders Nelson via cctalk wrote: >=20 > Does anyone here know which brands/lines had the best longevity? >=20 > -- > Anders Nelson >=20 >=20 > On Wed, Feb 1, 2023 at 11:28 AM David Barto via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 >> 100=E2=80=99s of CD-R, Sony, TDK, and FujiFilm. >> 25-30 DVD-R Sony and TDK >>=20 >> And CD cases sufficient to hold all the disks >>=20 >> Heavy, available for the cost of shipping. >> I=E2=80=99m in San Diego, so local delivery is possible. >>=20 >> David >>=20 >>=20 --===============2899518951304260989==-- From tdk.knight@gmail.com Wed Feb 1 17:08:51 2023 From: Adrian Stoness To: cctalk@classiccmp.org Subject: [cctalk] Re: Aging of unused CD-R media Date: Wed, 01 Feb 2023 11:08:04 -0600 Message-ID: In-Reply-To: <86ACF21A-2927-4C7A-9264-2DFE3253261C@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0944750923238622967==" --===============0944750923238622967== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable faster they were written too the faster the fade ive noticed On Wed, Feb 1, 2023 at 11:04 AM Zane Healy via cctalk wrote: > I find myself wondering, how well does CD-R and DVD-R media that hasn=E2=80= =99t > been used age? I have quite a bit of unused Verbatim DataLifePlus, as well > as some other media that=E2=80=99s unused. > > For the most part, I don=E2=80=99t need it, but I can see a couple reasons = I might > want to burn some in the future, mainly to exchange data with older systems. > > Zane > > > > --===============0944750923238622967==-- From emu@e-bbes.com Wed Feb 1 17:13:40 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 12:12:58 -0500 Message-ID: <9e3a50b6-74c5-cb42-0602-0e33e54a30bf@e-bbes.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7280539661391077563==" --===============7280539661391077563== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-01 10:56, Warner Losh wrote: > > On Wed, Feb 1, 2023 at 1:41 AM emanuel stiebler via cctalk > > wrote: > retension in case of power off. > If the power is applied all the time, the internal controller "can" > check the quality of the cells automatically (but this really > depends on > the controller, controller version, and the OS has to chose the right > strategy. And the controllers improved a lot lately) > > > The OS might not have a choice. All the SSDs that I've used in the > past decade at $WORK have not exposed any of this to the host, not > even enough stats to know when it's going on in real time... let alone > the ability to pause these operations for a little while until we're off > peak for the day... But you should be able to choose (at least on controllers I know) if you like to go for automatic or manual refresh. If you go for the automatic, it could happen that the drive decides to scan the drive, when your're busy and going nuts waiting for the drive (you can also define on newer drives how many block to check per run) If you're going for the manual refresh, just make sure you really run it one day. But, you should be the one who knows, when your computer isn't busy ... --===============7280539661391077563==-- From imp@bsdimp.com Wed Feb 1 17:15:37 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 10:14:43 -0700 Message-ID: In-Reply-To: <003c01d9365e$f6405fe0$e2c11fa0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0110152182479450748==" --===============0110152182479450748== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, Feb 1, 2023 at 10:02 AM Ali via cctalk wrote: > > However, it may well be that writing is the only way to refresh cells, > > as reading won't, if I understand flash operation correctly. But > > rewriting a sector or block of a file doesn't usually write back to the > > original, because of the write-leveling firmware in the drive. > > Chuck, > > But does that matter? If the main purpose is to be able to refresh the > data so it is readable does it matter that the data is not in the same > block as long as it is readable? > What's more, you don't always WANT to refresh the cells. Erase blocks can only be erased and programmed a limited number of times. By writing them every time, you are wearing out the NAND and making it less reliable and able to hold the data with time. The first few program / erase cycles of new NAND have the best retention for the unit. Once you get into the dozens somewhere, the retention of the cells drops somewhat. Normally, this isn't an issue, because dropping from decades to years for retention isn't a huge deal for most applications. But when you want the data to last a long time, you are better off just reading it and having those few (if any) cells that have decayed into the 'danger zone' refreshed, leading to likely 100x (or better) less wear on the part. The 'danger zone' is the error rate at which the firmware will decide the data is at risk in the future so it will rewrite the active parts of the erase block to ensure they are all readable in the future. So by forcing a re-write every time, and doing that force rewrite often, you are actually making the device less capable of storing data for the long term. Warner --===============0110152182479450748==-- From imp@bsdimp.com Wed Feb 1 17:18:36 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 10:17:43 -0700 Message-ID: In-Reply-To: <9e3a50b6-74c5-cb42-0602-0e33e54a30bf@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6264950194474672072==" --===============6264950194474672072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, Feb 1, 2023 at 10:13 AM emanuel stiebler wrote: > On 2023-02-01 10:56, Warner Losh wrote: > > > > On Wed, Feb 1, 2023 at 1:41 AM emanuel stiebler via cctalk > > > wrote: > > > retension in case of power off. > > If the power is applied all the time, the internal controller "can" > > check the quality of the cells automatically (but this really > > depends on > > the controller, controller version, and the OS has to chose the right > > strategy. And the controllers improved a lot lately) > > > > > > The OS might not have a choice. All the SSDs that I've used in the > > past decade at $WORK have not exposed any of this to the host, not > > even enough stats to know when it's going on in real time... let alone > > the ability to pause these operations for a little while until we're off > > peak for the day... > > But you should be able to choose (at least on controllers I know) if you > like to go for automatic or manual refresh. > That's selectable at the controller level... But there's no standard way for the OS to turn that from one to the other... Unless you go all in and do all the management which some NVMe drives support (not the ones we buy, mind you, since this is an 'enterprise' feature and we buy in the 'consumer' space). > If you go for the automatic, it could happen that the drive decides to > scan the drive, when your're busy and going nuts waiting for the drive > (you can also define on newer drives how many block to check per run) > > If you're going for the manual refresh, just make sure you really run it > one day. But, you should be the one who knows, when your computer isn't > busy ... > We'd like to be able to do that, but the drives we buy don't expose those knobs, despite buying many different models over the years from the same vendors and developing a close relationship with them in which we ask for it every chance we get... Warner --===============6264950194474672072==-- From cclist@sydex.com Wed Feb 1 18:07:53 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: CD-R, DVD-R media available Date: Wed, 01 Feb 2023 10:07:06 -0800 Message-ID: <408a0783-a26c-09fc-710f-900e6455a3e5@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6197327346319392358==" --===============6197327346319392358== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/1/23 08:51, Anders Nelson via cctalk wrote: > Does anyone here know which brands/lines had the best longevity? For ordinary CD's I've always used MAM-A Gold. Started buying when it was a Mitsui brand and haven't had a single failure. --Chuck --===============6197327346319392358==-- From lists@glitchwrks.com Wed Feb 1 18:18:21 2023 From: Jonathan Chapman To: cctalk@classiccmp.org Subject: [cctalk] Re: Aging of unused CD-R media Date: Wed, 01 Feb 2023 18:10:53 +0000 Message-ID: In-Reply-To: <86ACF21A-2927-4C7A-9264-2DFE3253261C@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7382259513692848544==" --===============7382259513692848544== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I find myself wondering, how well does CD-R and DVD-R media that hasn=E2=80= =99t been used age? Anecdotal, but I have some Fuji blanks from the 90s that still burn just fine= (works great on old drives that hate modern "see-through" media). The DVD-Rs= I have were bought by my parents in the mid-2000s when they thought they wer= e really going to move all their VHS to DVD The Hard Way, they bought like 50= 0 Verbatim-branded blanks and used maybe 20. I have a few spindles of Verbatim archival CD-Rs and DVD-Rs, which are mostly= used for sending customers backups of data. Those were bought some time befo= re 2015 and work fine. One would sort of expect that, though :P I also threw out most of a spindle of IIRC Memorex that came in some lot of s= omething else that looked like it was maybe 5 or 6 years old. Ended up with s= ome still-wrapped Sony blanks from the 90s (I think they were rated for 2x bu= rning!) that were totally eaten up, something attacked the metal layer. They = came with a bunch of other CDs (burned and pressed) that were all fine, so I = assume it wasn't storage conditions. Thanks, Jonathan --===============7382259513692848544==-- From cisin@xenosoft.com Wed Feb 1 19:45:39 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 11:44:50 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5440505045520473729==" --===============5440505045520473729== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, 1 Feb 2023, Zane Healy via cctalk wrote: > So far I’ve tackled one split zip. I wasn’t having any luck with > the version of PKZIP that I assume created this. I copied the files > into a directory, and did COPY > FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP THAT will give you a corrupted file! Concatenated copy (COPY with '+') has a behavior that you need to take into account. PC/MS-DOS 1.00 kept track of the file size with a course granularity. (logical sectors, not bytes) Therefore, PC/MS-DOS supported CTRL-Z as an end of file character! (A legacy of CP/M) When you cop a file, it copies the whole thing. Any extraneous content after EOF won't matter. BUT! When you concatenate files, COPY FILE1.ZIP + FILE2.ZIP COMBINED.ZIP COPY will terminate FILE1.ZIP at the first CTRL-Z that it encounters! When copying text files, Concatenated COPY will trim off all content after EOF! It is called "text mode". You need to change your command to COPY /B FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP to get "binary mode", so that it will copy ALL of each file, rather than just to the "end of file character" of each! Compare the final resulting file size of COPY and COPY /B -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5440505045520473729==-- From sellam.ismail@gmail.com Wed Feb 1 19:59:41 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 11:58:52 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4292117780277514960==" --===============4292117780277514960== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 1, 2023 at 11:45 AM Fred Cisin via cctalk wrote: > On Wed, 1 Feb 2023, Zane Healy via cctalk wrote: > > So far I=E2=80=99ve tackled one split zip. I wasn=E2=80=99t having any l= uck with > > the version of PKZIP that I assume created this. I copied the files > > into a directory, and did COPY > > FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP > > THAT will give you a corrupted file! > > Concatenated copy (COPY with '+') has a behavior that you need to take > into account. > > PC/MS-DOS 1.00 kept track of the file size with a course granularity. > (logical sectors, not bytes) > Therefore, PC/MS-DOS supported CTRL-Z as an end of file character! > (A legacy of CP/M) > > When you cop a file, it copies the whole thing. Any extraneous content > after EOF won't matter. > > BUT! When you concatenate files, > COPY FILE1.ZIP + FILE2.ZIP COMBINED.ZIP > COPY will terminate FILE1.ZIP at the first CTRL-Z that it encounters! > When copying text files, Concatenated COPY will trim off all content after > EOF! > It is called "text mode". > > You need to change your command to > COPY /B FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP > to get "binary mode", so that it will copy ALL of each file, rather than > just to the "end of file character" of each! > > Compare the final resulting file size of COPY and COPY /B > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com Excellent knowledge transfer, Fred. That is what makes this list great. Sellam --===============4292117780277514960==-- From cisin@xenosoft.com Wed Feb 1 20:01:26 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Aging of unused CD-R media Date: Wed, 01 Feb 2023 12:00:48 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3Cu-4o1mvNnq4FWegrGYx4PyC6FLNoDsk1R3qaCPoOcv93=5FNaN?= =?utf-8?q?5lFspEhLyAkRjcPaoQDyugPlqAK7m-4xggHZruf5=5FdEVfoKXTgw9KBorOsc=3D?= =?utf-8?q?=40glitchwrks=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3654087262953331138==" --===============3654087262953331138== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Keeping the discs on the spindles will slow the rate of deterioration! Since the discs in the middle of the stack receive less UV and less airflow of ozone or oxygen. Would storing in a cold dark vacuum extend the shelf-life? --===============3654087262953331138==-- From cisin@xenosoft.com Wed Feb 1 20:21:31 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 12:20:53 -0800 Message-ID: In-Reply-To: <003c01d9365e$f6405fe0$e2c11fa0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3116730221425359015==" --===============3116730221425359015== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 1 Feb 2023, Ali via cctalk wrote: > But does that matter? If the main purpose is to be able to refresh the > data so it is readable does it matter that the data is not in the same > block as long as it is readable? Ah, but most of that sort of memory has a finite number of cycles, and wears out due to use. Testing it is heavy usage, and brings about an even earlier end of life. Could we call that a "nosocomial" ("not so comical") deterioratoin :-? -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============3116730221425359015==-- From paulkoning@comcast.net Wed Feb 1 21:52:35 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 16:51:54 -0500 Message-ID: <22E8C177-D80C-4DC3-A516-4565C46AAC53@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5526915010248003179==" --===============5526915010248003179== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 1, 2023, at 3:20 PM, Fred Cisin via cctalk = wrote: >=20 > On Wed, 1 Feb 2023, Ali via cctalk wrote: >> But does that matter? If the main purpose is to be able to refresh the dat= a so it is readable does it matter that the data is not in the same block as = long as it is readable? >=20 > Ah, but most of that sort of memory has a finite number of cycles, and wear= s out due to use. > Testing it is heavy usage, and brings about an even earlier end of life. > Could we call that a "nosocomial" ("not so comical") deterioratoin :-? It's well known that flash memory (and NVRAM generally) has write limits. I = don't know of any read limits. Some other memories have write limits as well= though they are far larger and generally far less known. I think some of th= e phase change non-volatile memory types that seem to emerge from time to tim= e -- FRAM for example -- have write limits. Modern high density HDAs also do= , I believe, because the heads actually come closer to the surface during wri= te and as a result are more likely to touch the platter. But read limits? I'm not sure about that. What sort of numbers are we talki= ng about? If all else fails there's core memory, which as far as I remember is pretty m= uch unlimited for both read and write. paul --===============5526915010248003179==-- From imp@bsdimp.com Wed Feb 1 22:01:44 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 15:00:56 -0700 Message-ID: In-Reply-To: <22E8C177-D80C-4DC3-A516-4565C46AAC53@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6891426830136104408==" --===============6891426830136104408== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 1, 2023, 2:52 PM Paul Koning via cctalk wrote: > > > > On Feb 1, 2023, at 3:20 PM, Fred Cisin via cctalk > wrote: > > > > On Wed, 1 Feb 2023, Ali via cctalk wrote: > >> But does that matter? If the main purpose is to be able to refresh the > data so it is readable does it matter that the data is not in the same > block as long as it is readable? > > > > Ah, but most of that sort of memory has a finite number of cycles, and > wears out due to use. > > Testing it is heavy usage, and brings about an even earlier end of life. > > Could we call that a "nosocomial" ("not so comical") deterioratoin :-? > > It's well known that flash memory (and NVRAM generally) has write limits. > I don't know of any read limits. Some other memories have write limits as > well though they are far larger and generally far less known. I think some > of the phase change non-volatile memory types that seem to emerge from time > to time -- FRAM for example -- have write limits. Modern high density HDAs > also do, I believe, because the heads actually come closer to the surface > during write and as a result are more likely to touch the platter. > > But read limits? I'm not sure about that. What sort of numbers are we > talking about? > Read disturb in NAND is a thing. However, it kicks in after millions or hundreds of millions of page reads in a single EB. Most FTLs I've seen will treat this like any other "too many bits in error" read when it happens. Some drives keep track and do things with voltage thresholds to compensate. A few try to proactively garbage collect, though the benefits of that are slim to nil for most workloads. Warner P.S. some QLC NAND has worse read disturb, but it's only 100x worse. It can come up for high volume applications but not for simple archival reading. If all else fails there's core memory, which as far as I remember is pretty > much unlimited for both read and write. > > paul > > --===============6891426830136104408==-- From healyzh@avanthar.com Thu Feb 2 03:17:40 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 19:17:00 -0800 Message-ID: <10D2AF0E-5100-49C5-9207-357AA3EE9140@avanthar.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3643159455497417912==" --===============3643159455497417912== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Feb 1, 2023, at 11:44 AM, Fred Cisin via cctalk = wrote: >=20 > On Wed, 1 Feb 2023, Zane Healy via cctalk wrote: >> So far I=E2=80=99ve tackled one split zip. I wasn=E2=80=99t having any lu= ck with the version of PKZIP that I assume created this. I copied the files = into a directory, and did COPY FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.= ZIP COMBINED.ZIP >=20 > THAT will give you a corrupted file! >=20 > Concatenated copy (COPY with '+') has a behavior that you need to take into= account. >=20 > PC/MS-DOS 1.00 kept track of the file size with a course granularity. (logi= cal sectors, not bytes) Therefore, PC/MS-DOS supported CTRL-Z as an end of fi= le character! > (A legacy of CP/M) >=20 > When you cop a file, it copies the whole thing. Any extraneous content aft= er EOF won't matter. >=20 > BUT! When you concatenate files, > COPY FILE1.ZIP + FILE2.ZIP COMBINED.ZIP > COPY will terminate FILE1.ZIP at the first CTRL-Z that it encounters! > When copying text files, Concatenated COPY will trim off all content after = EOF! > It is called "text mode". >=20 > You need to change your command to > COPY /B FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP > to get "binary mode", so that it will copy ALL of each file, rather than ju= st to the "end of file character" of each! >=20 > Compare the final resulting file size of COPY and COPY /B >=20 > -- > Grumpy Ol' Fred cisin(a)xenosoft.com I=E2=80=99m running the version of DOS that comes with DOSBOX-X (I think it= =E2=80=99s FreeDOS?). Checking COPY, and I=E2=80=99m not sure it supports /B= , but it also doesn=E2=80=99t complain, the resulting combined ZIP is the sam= e in both cases. Turns out that I have three corrupted files in the fixed Zi= p, before fixing it there are a lot more. That=E2=80=99s based on telling PK= ZIP to check the ZIP integrity.=20 Zane --===============3643159455497417912==-- From cisin@xenosoft.com Thu Feb 2 03:38:58 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 19:38:22 -0800 Message-ID: In-Reply-To: <10D2AF0E-5100-49C5-9207-357AA3EE9140@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7876575989280812442==" --===============7876575989280812442== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>> FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP >> THAT will give you a corrupted file! >> Concatenated copy (COPY with '+') has a behavior that you need to take int= o account. >> PC/MS-DOS 1.00 kept track of the file size with a course granularity. (log= ical sectors, not bytes) Therefore, PC/MS-DOS supported CTRL-Z as an end of f= ile character! >> (A legacy of CP/M) >> When you copy a file, it copies the whole thing. Any extraneous=20 >> content after EOF won't matter. >> BUT! When you concatenate files, >> COPY FILE1.ZIP + FILE2.ZIP COMBINED.ZIP >> COPY will terminate FILE1.ZIP at the first CTRL-Z that it encounters! >> When copying text files, Concatenated COPY will trim off all content after= EOF! >> It is called "text mode". >> You need to change your command to >> COPY /B FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP >> to get "binary mode", so that it will copy ALL of each file, rather than j= ust to the "end of file character" of each! >> Compare the final resulting file size of COPY and COPY /B On Wed, 1 Feb 2023, Zane Healy wrote: > I=E2=80=99m running the version of DOS that comes with DOSBOX-X (I think=20 > it=E2=80=99s FreeDOS?). Checking COPY, and I=E2=80=99m not sure it support= s /B, but=20 > it also doesn=E2=80=99t complain, the resulting combined ZIP is the same in= =20 > both cases. Turns out that I have three corrupted files in the fixed=20 > Zip, before fixing it there are a lot more. That=E2=80=99s based on tellin= g=20 > PKZIP to check the ZIP integrity. If you get a convenient chance, try COPY /A ...+...+... ... /A ("ASCII" or text mode) is the default in PC/MS-DOS, where CTRL-Z, and=20 any padding/junk after the EOF (CTRL-Z) character in the files in the=20 middle is truncated. That is so that when you concatenate text files, you=20 don't leave EOFs and sector/record padding in the middle. If /A gives the same as /B and the same as no switch, then either your=20 version does not have that "feature", OR there are no CTRL-Z's (1Ah)=20 anywhere in the middle files! If /A gives a shorter result, stay away from it, but that would mean that=20 /B is the default in your version. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============7876575989280812442==-- From healyzh@avanthar.com Thu Feb 2 03:39:37 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 19:38:49 -0800 Message-ID: <7CB375CA-E99B-442C-82D9-D6E01A4E400E@avanthar.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7019394865957206696==" --===============7019394865957206696== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Feb 1, 2023, at 11:59 AM, Sellam Abraham via cctalk wrote: >=20 > =EF=BB=BFOn Wed, Feb 1, 2023 at 11:45 AM Fred Cisin via cctalk > wrote: >=20 >>> On Wed, 1 Feb 2023, Zane Healy via cctalk wrote: >>> So far I=E2=80=99ve tackled one split zip. I wasn=E2=80=99t having any l= uck with >>> the version of PKZIP that I assume created this. I copied the files >>> into a directory, and did COPY >>> FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP >>=20 >> THAT will give you a corrupted file! >>=20 >> Concatenated copy (COPY with '+') has a behavior that you need to take >> into account. >>=20 >> PC/MS-DOS 1.00 kept track of the file size with a course granularity. >> (logical sectors, not bytes) >> Therefore, PC/MS-DOS supported CTRL-Z as an end of file character! >> (A legacy of CP/M) >>=20 >> When you cop a file, it copies the whole thing. Any extraneous content >> after EOF won't matter. >>=20 >> BUT! When you concatenate files, >> COPY FILE1.ZIP + FILE2.ZIP COMBINED.ZIP >> COPY will terminate FILE1.ZIP at the first CTRL-Z that it encounters! >> When copying text files, Concatenated COPY will trim off all content after >> EOF! >> It is called "text mode". >>=20 >> You need to change your command to >> COPY /B FILE1.ZIP+FILE2.ZIP+FILE3.ZIP+FILE4.ZIP+FILE5.ZIP COMBINED.ZIP >> to get "binary mode", so that it will copy ALL of each file, rather than >> just to the "end of file character" of each! >>=20 >> Compare the final resulting file size of COPY and COPY /B >>=20 >> -- >> Grumpy Ol' Fred cisin(a)xenosoft.com >=20 >=20 > Excellent knowledge transfer, Fred. That is what makes this list great. >=20 > Sellam You have that right Sellam, the more that I look into this, based on Fred=E2= =80=99s info, I think that I need to get MS-DOS running under DOSBOX-X. Zane --===============7019394865957206696==-- From cisin@xenosoft.com Thu Feb 2 04:03:15 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] Re: [SPAM] Re: PKBACK Floppies? Date: Wed, 01 Feb 2023 20:02:37 -0800 Message-ID: In-Reply-To: <7CB375CA-E99B-442C-82D9-D6E01A4E400E@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2245158421172902287==" --===============2245158421172902287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, 1 Feb 2023, Zane Healy via cctalk wrote: > You have that right Sellam, the more that I look into this, based on > Fred’s info, I think that I need to get MS-DOS running under DOSBOX-X. Probably worthwhile. Although the truncation of file content after EOF during concatenation is somewhat esoteric. There may be plenty of other things to check out. Are you using the correct version of PKZIP? I'm wondering how well PKZIP handles features that were added to PKZIP in versions newer than itself. Ideally, PKZIP should include metadata in files, including version number, to let you know whether it's a suitable version for a given file, . . . -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============2245158421172902287==-- From wrcooke@wrcooke.net Thu Feb 2 04:10:58 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Wed, 01 Feb 2023 22:10:22 -0600 Message-ID: <402336667.2184278.1675311022521@email.ionos.com> In-Reply-To: <22E8C177-D80C-4DC3-A516-4565C46AAC53@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7239940827965237917==" --===============7239940827965237917== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/01/2023 3:51 PM CST Paul Koning via cctalk = wrote: >=20 ot sure about that. What sort of numbers are we talking about? >=20 > If all else fails there's core memory, which as far as I remember is pretty= much unlimited for both read and write. >=20 > paul I don't know for sure and can't find any references, but I strongly suspect t= hat core memory would wear out over time, as well. My reasoning for this is = the because in principle it works the same as FRAM. I usually refer to FRAM = as "core on a chip." Over time, the magnetic domains in FRAM tend to stay in= one polarization or another. I see no reason why the magnetic domains in co= re wouldn't do the same. However, a single core is probably bigger than the = entire FRAM chip so there are a LOT more domains. That means it would take a= proportional amount of writes to wear out -- let's just say a million times.= In addition, core access was in microseconds, whereas FRAM and other modern= memories are in nanoseconds. So it takes something like 1000 times longer o= n the clock on the wall to perform the same number of writes. So in the end = something like a billion times longer on the calendar to wear it out. I would be very interested if anyone actually knows and especially if there a= re references available. Will --===============7239940827965237917==-- From abs@absd.org Thu Feb 2 09:38:54 2023 From: David Brownlee To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Thu, 02 Feb 2023 09:38:02 +0000 Message-ID: In-Reply-To: <9e3a50b6-74c5-cb42-0602-0e33e54a30bf@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5114342248197184108==" --===============5114342248197184108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 1 Feb 2023 at 17:13, emanuel stiebler via cctalk wrote: > > On 2023-02-01 10:56, Warner Losh wrote: > > > > On Wed, Feb 1, 2023 at 1:41 AM emanuel stiebler via cctalk > > > wrote: > > > retension in case of power off. > > If the power is applied all the time, the internal controller "can" > > check the quality of the cells automatically (but this really > > depends on > > the controller, controller version, and the OS has to chose the right > > strategy. And the controllers improved a lot lately) > > > > > > The OS might not have a choice. All the SSDs that I've used in the > > past decade at $WORK have not exposed any of this to the host, not > > even enough stats to know when it's going on in real time... let alone > > the ability to pause these operations for a little while until we're off > > peak for the day... > > But you should be able to choose (at least on controllers I know) if you > like to go for automatic or manual refresh. > > If you go for the automatic, it could happen that the drive decides to > scan the drive, when your're busy and going nuts waiting for the drive > (you can also define on newer drives how many block to check per run) > > If you're going for the manual refresh, just make sure you really run it > one day. But, you should be the one who knows, when your computer isn't > busy ... That reminds me (looks at 43.5T of zfs pool that has not had a scrub since 2021). It can be nice to have a filesystem which handles redundancy and also the option to occasionally read all the data, check end to end checksums (in the unlikely case a device returns a successful read with bad data), and fixup everything. Does not eliminate the need for remote copies, but gives a little extra confidence that the master copy is still what it should be :) Its currently all on spinning rust, but I imagine zfs scrub should map nicely onto refreshing SSDs with "read everything you care about, write only on fixing up data" (in the unlikely event I can ever afford sufficient SSD storage) David --===============5114342248197184108==-- From abs@absd.org Thu Feb 2 09:43:02 2023 From: David Brownlee To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 41-CX Date: Thu, 02 Feb 2023 09:42:17 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3338433545230665389==" --===============3338433545230665389== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I had some idea of trying to get money for an HP 41-CX a while back, but on balance I think it's best to just go to someone who might be interested in fixing it up and valuing it for what it is. So - FTGH, just the cost of shipping (photo link below still valid) David On Sun, 19 Apr 2020 at 17:55, David Brownlee wrote: > > I've come into possession of an HP 41-CX calculator - unfortunately it > appears to have had batteries left in it which have left corrosion on > the internal contacts. > > (some pics: https://photos.app.goo.gl/48bE7WJZP8R4PF9a9 ) > > My classic hardware tendencies tend to run more towards the "can run > *nix" end, and while I could just clean it up and throw it on eBay I > wondered if anyone here has a 41C shaped soft spot and would be > interested? (happy to trade/part trade for something they already have > for which they are less fond if that works :) > > David --===============3338433545230665389==-- From doug@doughq.com Thu Feb 2 09:46:59 2023 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 41-CX Date: Thu, 02 Feb 2023 20:46:08 +1100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5427001094885527277==" --===============5427001094885527277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I would be interested in it - Happy to pay postage to Australia, and a bit for the machine ;-) Kindest regards, Doug Jackson em: doug(a)doughq.com ph: 0414 986878 On Thu, 2 Feb 2023 at 20:42, David Brownlee via cctalk < cctalk(a)classiccmp.org> wrote: > I had some idea of trying to get money for an HP 41-CX a while back, > but on balance I think it's best to just go to someone who might be > interested in fixing it up and valuing it for what it is. > > So - FTGH, just the cost of shipping (photo link below still valid) > > David > > On Sun, 19 Apr 2020 at 17:55, David Brownlee wrote: > > > > I've come into possession of an HP 41-CX calculator - unfortunately it > > appears to have had batteries left in it which have left corrosion on > > the internal contacts. > > > > (some pics: https://photos.app.goo.gl/48bE7WJZP8R4PF9a9 ) > > > > My classic hardware tendencies tend to run more towards the "can run > > *nix" end, and while I could just clean it up and throw it on eBay I > > wondered if anyone here has a 41C shaped soft spot and would be > > interested? (happy to trade/part trade for something they already have > > for which they are less fond if that works :) > > > > David > --===============5427001094885527277==-- From cc@informatik.uni-stuttgart.de Thu Feb 2 09:58:28 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer of Thesus (was: Re: Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Thu, 02 Feb 2023 10:57:41 +0100 Message-ID: In-Reply-To: <2043057209.2003095.1675259243799@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3830784479675349303==" --===============3830784479675349303== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 1 Feb 2023, skogkatt007(a)yahoo.com wrote: > You stop being rude you big burly baby. Get a life. I'm not your hobby, as = hard as you're trying to make me so. *PLONK* --===============3830784479675349303==-- From emu@e-bbes.com Thu Feb 2 11:55:27 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 06:54:42 -0500 Message-ID: <00c8d793-301e-65b3-8f90-4f6653e15eed@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6115802824782570798==" --===============6115802824782570798== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-02 04:38, David Brownlee wrote: > That reminds me (looks at 43.5T of zfs pool that has not had a scrub > since 2021). > > It can be nice to have a filesystem which handles redundancy and also > the option to occasionally read all the data, check end to end > checksums (in the unlikely case a device returns a successful read > with bad data), and fixup everything. Does not eliminate the need for > remote copies, but gives a little extra confidence that the master > copy is still what it should be :) So, what else do you guys use, to make sure your data is safe for the years to come? --===============6115802824782570798==-- From lists@glitchwrks.com Thu Feb 2 14:18:17 2023 From: Jonathan Chapman To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 14:17:31 +0000 Message-ID: In-Reply-To: <00c8d793-301e-65b3-8f90-4f6653e15eed@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6531444358333562956==" --===============6531444358333562956== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > So, what else do you guys use, to make sure your data is safe for the > years to come? ZFS and redundant copies of important stuff, plus backups on media that's lik= ely to be readable in 10 years (meaning the drives must still work/be availab= le, too!) Anything that's appropriate to have on a public Github repository should go t= o one. Thanks, Jonathan --===============6531444358333562956==-- From elson@pico-systems.com Thu Feb 2 15:18:31 2023 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Thu, 02 Feb 2023 09:17:48 -0600 Message-ID: In-Reply-To: <402336667.2184278.1675311022521@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6322048880647670395==" --===============6322048880647670395== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/1/23 22:10, Will Cooke via cctalk wrote: > >> On 02/01/2023 3:51 PM CST Paul Koning via cctalk = wrote: >> > ot sure about that. What sort of numbers are we talking about? >> If all else fails there's core memory, which as far as I remember is prett= y much unlimited for both read and write. >> >> paul > I don't know for sure and can't find any references, but I strongly suspect= that core memory would wear out over time, as well. My reasoning for this i= s the because in principle it works the same as FRAM. I usually refer to FRA= M as "core on a chip." Over time, the magnetic domains in FRAM tend to stay = in one polarization or another. I see no reason why the magnetic domains in = core wouldn't do the same. However, a single core is probably bigger than th= e entire FRAM chip so there are a LOT more domains. That means it would take= a proportional amount of writes to wear out -- let's just say a million time= s. In addition, core access was in microseconds, whereas FRAM and other mode= rn memories are in nanoseconds. So it takes something like 1000 times longer= on the clock on the wall to perform the same number of writes. So in the en= d something like a billion times longer on the calendar to wear it out. > > I would be very interested if anyone actually knows and especially if there= are references available. I have extreme doubts that this is true.=C2=A0 Memory cores are=20 just tiny versions of pulse transformers, and similar square=20 loop transformer core materials are used in switching power=20 supplies that run for decades at high switching=20 frequencies.=C2=A0 Really, FRAM does not work much similarly to=20 core.=C2=A0 The ferroelectric material is usually lead zirconate=20 titanate, not an actual ferromagnetic material.=C2=A0 It is=20 written by an electric field, not magnetic, and the electric=20 field is sensed by a field effect transistor.=C2=A0 I have NEVER=20 heard of core wear-out in magnetic core memories.=C2=A0 The=20 flipping of the magnetic polarization in ferrite materials=20 does not break down the crystal structure. Jon Jon --===============6322048880647670395==-- From paulkoning@comcast.net Thu Feb 2 15:25:41 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Thu, 02 Feb 2023 10:25:02 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8298804957023519805==" --===============8298804957023519805== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 2, 2023, at 10:17 AM, Jon Elson via cctalk = wrote: >=20 > On 2/1/23 22:10, Will Cooke via cctalk wrote: >>=20 >>> On 02/01/2023 3:51 PM CST Paul Koning via cctalk wrote: >>>=20 >> ot sure about that. What sort of numbers are we talking about? >>> If all else fails there's core memory, which as far as I remember is pret= ty much unlimited for both read and write. >>>=20 >>> paul >> I don't know for sure and can't find any references, but I strongly suspec= t that core memory would wear out over time, as well. My reasoning for this = is the because in principle it works the same as FRAM. I usually refer to FR= AM as "core on a chip." Over time, the magnetic domains in FRAM tend to stay= in one polarization or another. I see no reason why the magnetic domains in= core wouldn't do the same. However, a single core is probably bigger than t= he entire FRAM chip so there are a LOT more domains. That means it would tak= e a proportional amount of writes to wear out -- let's just say a million tim= es. In addition, core access was in microseconds, whereas FRAM and other mod= ern memories are in nanoseconds. So it takes something like 1000 times longe= r on the clock on the wall to perform the same number of writes. So in the e= nd something like a billion times longer on the calendar to wear it out. >>=20 >> I would be very interested if anyone actually knows and especially if ther= e are references available. >=20 > I have extreme doubts that this is true. Memory cores are just tiny versio= ns of pulse transformers, and similar square loop transformer core materials = are used in switching power supplies that run for decades at high switching f= requencies. I don't know of core wear either, but I don't think your analogy is correct. = Memory cores are not just pulse transformers, they are magnetic logic and st= orage elements. And yes, they have a square hysteresis loop to do so, while = power supply transformers do not (hysteresis is not wanted in that applicatio= n). As Will pointed out, cores are fairly large storage elements, and their switc= hing speeds are more modest. Not necessarily quite so modest, though -- the = CDC 6600 mainframes in 1964 had memory cycling at 1 MHz rate, which means the= basic operation (read and restore) takes only a few hundred nanoseconds. I = think the main limitation in that case wasn't so much the cores as rather the= difficulty of driving pulses 100 or so ns wide through a higly inductive loa= d. There are some unusual circuit tricks in those memories to reduce that pr= oblem compared to the more common 4-wire designs. paul --===============8298804957023519805==-- From elson@pico-systems.com Thu Feb 2 15:28:15 2023 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 09:27:37 -0600 Message-ID: In-Reply-To: <00c8d793-301e-65b3-8f90-4f6653e15eed@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5095637909391246662==" --===============5095637909391246662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/2/23 05:54, emanuel stiebler via cctalk wrote: > On 2023-02-02 04:38, David Brownlee wrote: > > > That reminds me (looks at 43.5T of zfs pool that has not > had a scrub > > since 2021). > > > > It can be nice to have a filesystem which handles > redundancy and also > > the option to occasionally read all the data, check end > to end > > checksums (in the unlikely case a device returns a > successful read > > with bad data), and fixup everything. Does not eliminate > the need for > > remote copies, but gives a little extra confidence that > the master > > copy is still what it should be :) > > So, what else do you guys use, to make sure your data is > safe for the years to come? I do many backups on blu-ray DVD's, the theory is if they start to go bad, maybe partial recovery of important files will be possible due to having many copies on DVD. This is getting a bit difficult as the amount of stuff to be backed up is just a bit too big for a single blu-ray disc. I also do much more frequent backups to a large hard drive. Jon --===============5095637909391246662==-- From sellam.ismail@gmail.com Thu Feb 2 16:04:23 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Core memory (was Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Thu, 02 Feb 2023 08:03:34 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5959166733852663658==" --===============5959166733852663658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This discussion on core memory got me thinking: Is it possible to "read" core memory by examining each core using some kind of instrument that would sense its "charge" (or lack thereof) non-destructively? Could a piece of paper be placed over a core plane and fine particles of iron sprinkled onto the paper to literally "see" the bits? Please excuse me for any ignorant assumptions made here on my part. Sellam --===============5959166733852663658==-- From wrcooke@wrcooke.net Thu Feb 2 16:09:59 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Core memory (was Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Thu, 02 Feb 2023 10:09:18 -0600 Message-ID: <87660108.1631828.1675354158484@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2366383201236079863==" --===============2366383201236079863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/02/2023 10:03 AM CST Sellam Abraham via cctalk wrote: >=20 >=20 > This discussion on core memory got me thinking: >=20 > Is it possible to "read" core memory by examining each core using some kind > of instrument that would sense its "charge" (or lack thereof) > non-destructively? >=20 > Could a piece of paper be placed over a core plane and fine particles of > iron sprinkled onto the paper to literally "see" the bits? >=20 > Please excuse me for any ignorant assumptions made here on my part. >=20 > Sellam I suspect it would be possible, but not easy. The main reason I say that is = that the toroidal shape of the cores, rather than something like a square or = straight bar, is intended to keep the magnetic field contained within the rin= g. Instead of coming out an end or edge and going through free space, the ma= gnetic lines of force go circularly around the loop. The polarity of the fie= ld determines whether it is clockwise or counterclockwise. So very little fi= eld escapes. That's what makes it possible to have them packed so tightly wi= thout interference. https://en.wikipedia.org/wiki/Toroidal_inductors_and_transformers Will --===============2366383201236079863==-- From paulkoning@comcast.net Thu Feb 2 16:12:11 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Core memory (was Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man) Date: Thu, 02 Feb 2023 11:11:29 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6254715904775584796==" --===============6254715904775584796== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 2, 2023, at 11:03 AM, Sellam Abraham via cctalk wrote: >=20 > This discussion on core memory got me thinking: >=20 > Is it possible to "read" core memory by examining each core using some kind > of instrument that would sense its "charge" (or lack thereof) > non-destructively? >=20 > Could a piece of paper be placed over a core plane and fine particles of > iron sprinkled onto the paper to literally "see" the bits? >=20 > Please excuse me for any ignorant assumptions made here on my part. >=20 > Sellam That's a very good question. The difficulty with doing this isn't that the c= ore states are "magnetized" and "not magnetized" but rather they are "magneti= zed in one direction" and "magnetized in the other direction". So flux-visua= lizing won't help because 1 and 0 will look the same. =20 The other problem is that a toroidal core, by design, constrains nearly all t= he magnetic flux inside the core material, with very little "leakage". That said, it would be an interesting experiment to take a core memory module= and hold a small Hall effect probe up against the cores, especially inside t= he core opening. I don't know if those sensors can be sensitive enough to pi= ck up the leakage flux. If yes, it may well depend on the core diameter; the= later generations tended to have smaller cores for both density and speed. = CDC mainframe cores are probably small for the time, I don't remember seeing = the numbers. paul --===============6254715904775584796==-- From wayne.sudol@hotmail.com Thu Feb 2 19:04:22 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 19:03:42 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0493228604242721572==" --===============0493228604242721572== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have a Synology 4-bay san that has 4 2-tb drives in a raid stripe. I backup= to that. I do convert software cd=E2=80=99s and dvd to .iso and floppies to = .img and copy the results to the san.=20 Sent from my iPhone > On Feb 2, 2023, at 07:27, Jon Elson via cctalk wr= ote: >=20 > =EF=BB=BFOn 2/2/23 05:54, emanuel stiebler via cctalk wrote: >> On 2023-02-02 04:38, David Brownlee wrote: >>=20 >> > That reminds me (looks at 43.5T of zfs pool that has not had a scrub >> > since 2021). >> > >> > It can be nice to have a filesystem which handles redundancy and also >> > the option to occasionally read all the data, check end to end >> > checksums (in the unlikely case a device returns a successful read >> > with bad data), and fixup everything. Does not eliminate the need for >> > remote copies, but gives a little extra confidence that the master >> > copy is still what it should be :) >>=20 >> So, what else do you guys use, to make sure your data is safe for the year= s to come? >=20 > I do many backups on blu-ray DVD's, the theory is if they start to go bad, = maybe partial recovery of important files will be possible due to having many= copies on DVD. >=20 > This is getting a bit difficult as the amount of stuff to be backed up is j= ust a bit too big for a single blu-ray disc. >=20 > I also do much more frequent backups to a large hard drive. >=20 > Jon >=20 --===============0493228604242721572==-- From vincent.slyngstad@gmail.com Thu Feb 2 19:27:12 2023 From: Vincent Slyngstad To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 11:26:34 -0800 Message-ID: In-Reply-To: <00c8d793-301e-65b3-8f90-4f6653e15eed@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7315168250013975077==" --===============7315168250013975077== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/2/2023 3:54 AM, emanuel stiebler via cctalk wrote: > So, what else do you guys use, to make sure your data is safe for the > years to come? I maintain a large SVN repository, which also serves as the backing store for my website. I rely on the backup policies at DreamHost, but I also keep at least two local copies of the complete workspace up to date, as well as an (admittedly usually rather stale) backup of the repository. I like that the repository allows me to share stuff, and also the tools to work with the repository can trivially tell me if my local data is being corrupted. I've also seen a work style where everything is pushed to github when "finished", but github storage limits are small and the interface is awkward to me. Vince --===============7315168250013975077==-- From bfranchuk@jetnet.ab.ca Thu Feb 2 19:36:13 2023 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Thu, 02 Feb 2023 12:35:34 -0700 Message-ID: <870b5be5-c3c8-411f-1d07-cfc4ed30f1d4@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4422818305073394675==" --===============4422818305073394675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2023-02-02 8:25 a.m., Paul Koning via cctalk wrote: > As Will pointed out, cores are fairly large storage elements, and their swi= tching speeds are more modest. Not necessarily quite so modest, though -- th= e CDC 6600 mainframes in 1964 had memory cycling at 1 MHz rate, which means t= he basic operation (read and restore) takes only a few hundred nanoseconds. = I think the main limitation in that case wasn't so much the cores as rather t= he difficulty of driving pulses 100 or so ns wide through a higly inductive l= oad. There are some unusual circuit tricks in those memories to reduce that = problem compared to the more common 4-wire designs. >=20 > paul I suspect heating effects, from the current could lead to more problems=20 on wire and solder, than the core switching. --===============4422818305073394675==-- From bfranchuk@jetnet.ab.ca Thu Feb 2 19:40:20 2023 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 12:39:42 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8143221066383500543==" --===============8143221066383500543== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-02 8:27 a.m., Jon Elson via cctalk wrote: > I do many backups on blu-ray DVD's, the theory is if they start to go > bad, maybe partial recovery of important files will be possible due to > having many copies on DVD. > > This is getting a bit difficult as the amount of stuff to be backed up > is just a bit too big for a single blu-ray disc. > > I also do much more frequent backups to a large hard drive. > > Jon A CD rom still handles all my backup needs, other than the fact I can't backup my older software. Ben. --===============8143221066383500543==-- From sellam.ismail@gmail.com Thu Feb 2 19:48:27 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 11:47:38 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0505775799176757655==" --===============0505775799176757655== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 2, 2023 at 11:26 AM Vincent Slyngstad via cctalk < cctalk(a)classiccmp.org> wrote: > I've also seen a work style where everything is pushed to github when > "finished", but github storage limits are small and the interface is > awkward to me. > I've tried a few times to make sense of how GitHub works but I gave up. It's a mess. Sellam --===============0505775799176757655==-- From tarek@infocom.ai Thu Feb 2 21:35:05 2023 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] 1975 Homebrew Computer Club Newsletter Date: Thu, 02 Feb 2023 13:34:08 -0800 Message-ID: <6EDFDCE0-A46E-4B0E-B7E2-32A5D7CFC389@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5695707599676222059==" --===============5695707599676222059== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable One website has an archive of the first Homebrew Computer Club newsletters. T= he newsletter is associated with the Homebrew club that kicked off the person= al computer revolution https://arkive.net/gallery/homebrew-computer-club Regards, Tarek Hoteit --===============5695707599676222059==-- From sellam.ismail@gmail.com Thu Feb 2 22:40:40 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: 1975 Homebrew Computer Club Newsletter Date: Thu, 02 Feb 2023 14:39:50 -0800 Message-ID: In-Reply-To: <6EDFDCE0-A46E-4B0E-B7E2-32A5D7CFC389@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3264996831233068035==" --===============3264996831233068035== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 2, 2023 at 1:34 PM Tarek Hoteit via cctalk < cctalk(a)classiccmp.org> wrote: > One website has an archive of the first Homebrew Computer Club > newsletters. The newsletter is associated with the Homebrew club that > kicked off the personal computer revolution > > https://arkive.net/gallery/homebrew-computer-club I used to have a complete run of original issues. Might still have them, somewhere. Sellam --===============3264996831233068035==-- From doug@doughq.com Thu Feb 2 23:01:35 2023 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: 1975 Homebrew Computer Club Newsletter Date: Fri, 03 Feb 2023 10:00:20 +1100 Message-ID: In-Reply-To: <6EDFDCE0-A46E-4B0E-B7E2-32A5D7CFC389@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7889585302368595081==" --===============7889585302368595081== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I love the small note about Steve Wozniak in the second magazine... lots of hardware experience - Time poor :-) Kindest regards, Doug Jackson em: doug(a)doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net On Fri, 3 Feb 2023 at 08:34, Tarek Hoteit via cctalk wrote: > One website has an archive of the first Homebrew Computer Club > newsletters. The newsletter is associated with the Homebrew club that > kicked off the personal computer revolution > > https://arkive.net/gallery/homebrew-computer-club > > Regards, > Tarek Hoteit > --===============7889585302368595081==-- From brain@jbrain.com Thu Feb 2 23:29:10 2023 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 17:28:23 -0600 Message-ID: <14c4ae85-26e4-2ef9-5581-a4c651f528ee@jbrain.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8288384498779961241==" --===============8288384498779961241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/2/2023 1:47 PM, Sellam Abraham via cctalk wrote: > On Thu, Feb 2, 2023 at 11:26 AM Vincent Slyngstad via cctalk < > cctalk(a)classiccmp.org> wrote: > >> I've also seen a work style where everything is pushed to github when >> "finished", but github storage limits are small and the interface is >> awkward to me. >> > I've tried a few times to make sense of how GitHub works but I gave up. > It's a mess. > > Sellam Hmm, I'd be happy to do a Zoom call to show folks.  Git can be complicated, but the simpler items are easy and using the command line git connected to a github/bitbucket/gitlab repo and a simple git push and all your local data/files under control are magically on the web for sharing, if that's the goal. Jim -- Jim Brain brain(a)jbrain.com www.jbrain.com --===============8288384498779961241==-- From wh.sudbrink@verizon.net Thu Feb 2 23:29:40 2023 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] After more than three years, U of Iowa's PDP-8 project active again Date: Thu, 02 Feb 2023 18:28:08 -0500 Message-ID: <087601d9375e$02439fa0$06cadee0$@verizon.net> In-Reply-To: <087601d9375e$02439fa0$06cadee0$.ref@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1264432899648981234==" --===============1264432899648981234== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit After more than three years, U of Iowa's PDP-8 project active again -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============1264432899648981234==-- From wh.sudbrink@verizon.net Thu Feb 2 23:30:38 2023 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Thu, 02 Feb 2023 18:29:26 -0500 Message-ID: <087b01d9375e$30ff46f0$92fdd4d0$@verizon.net> In-Reply-To: <087601d9375e$02439fa0$06cadee0$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1533625258543465839==" --===============1533625258543465839== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Forgot the link: https://homepage.divms.uiowa.edu/~jones/pdp8/UI-8/log.shtml -----Original Message----- From: William Sudbrink via cctalk [mailto:cctalk(a)classiccmp.org] Sent: Thursday, February 02, 2023 6:28 PM To: 'General Discussion: On-Topic and Off-Topic Posts' Cc: William Sudbrink Subject: [cctalk] After more than three years, U of Iowa's PDP-8 project active again After more than three years, U of Iowa's PDP-8 project active again -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============1533625258543465839==-- From billdegnan@gmail.com Thu Feb 2 23:38:21 2023 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Thu, 02 Feb 2023 18:37:25 -0500 Message-ID: In-Reply-To: <087b01d9375e$30ff46f0$92fdd4d0$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6850633906849006889==" --===============6850633906849006889== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I keep forgetting to mention that I got a straight 8 too. Plan to start working on it in the spring. Bill On Thu, Feb 2, 2023, 6:30 PM William Sudbrink via cctalk < cctalk(a)classiccmp.org> wrote: > Forgot the link: > > https://homepage.divms.uiowa.edu/~jones/pdp8/UI-8/log.shtml > > > -----Original Message----- > From: William Sudbrink via cctalk [mailto:cctalk(a)classiccmp.org] > Sent: Thursday, February 02, 2023 6:28 PM > To: 'General Discussion: On-Topic and Off-Topic Posts' > > Cc: William Sudbrink > Subject: [cctalk] After more than three years, U of Iowa's PDP-8 project > active again > > After more than three years, U of Iowa's PDP-8 project active again > > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com > > --===============6850633906849006889==-- From sellam.ismail@gmail.com Thu Feb 2 23:40:24 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 15:39:35 -0800 Message-ID: In-Reply-To: <14c4ae85-26e4-2ef9-5581-a4c651f528ee@jbrain.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1360387899924060528==" --===============1360387899924060528== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 2, 2023 at 3:28 PM Jim Brain via cctalk wrote: > > I've tried a few times to make sense of how GitHub works but I gave up. > > It's a mess. > > > > Sellam > > Hmm, I'd be happy to do a Zoom call to show folks. Git can be > complicated, but the simpler items are easy and using the command line > git connected to a github/bitbucket/gitlab repo and a simple git push > and all your local data/files under control are magically on the web for > sharing, if that's the goal. > Hi Jim. I'd be down for that. It would also be an opportunity to socialize a little bit. I don't believe we've ever had an opportunity to meet in person. Sellam --===============1360387899924060528==-- From van.snyder@sbcglobal.net Thu Feb 2 23:45:38 2023 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Thu, 02 Feb 2023 15:44:58 -0800 Message-ID: In-Reply-To: <087601d9375e$02439fa0$06cadee0$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8391785918711007491==" --===============8391785918711007491== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2023-02-02 at 18:28 -0500, William Sudbrink via cctalk wrote: > After more than three years, U of Iowa's PDP-8 project active again Years ago, I had a colleague named Prentiss Knowlton who built a solenoid bank to connect to his PDP-8. He put the solenoid bank on the keyboard of the 90-rank Schlicker pipe organ in the All Saints Episcopal Church in Pasadena, CA. It played the music for his wedding. Later, he published an album of pipe-organ performances, on the same organ, entitled "Unplayed by Human Hands." https://en.wikipedia.org/wiki/Unplayed_by_Human_Hands I don't know whether he still has the computer. --===============8391785918711007491==-- From bill.gunshannon@hotmail.com Thu Feb 2 23:53:41 2023 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 18:53:02 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8161337236501488089==" --===============8161337236501488089== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/2/2023 6:39 PM, Sellam Abraham via cctalk wrote: > On Thu, Feb 2, 2023 at 3:28 PM Jim Brain via cctalk > wrote: > >>> I've tried a few times to make sense of how GitHub works but I gave up. >>> It's a mess. >>> >>> Sellam >> Hmm, I'd be happy to do a Zoom call to show folks. Git can be >> complicated, but the simpler items are easy and using the command line >> git connected to a github/bitbucket/gitlab repo and a simple git push >> and all your local data/files under control are magically on the web for >> sharing, if that's the goal. >> > Hi Jim. > > I'd be down for that. It would also be an opportunity to socialize a > little bit. I don't believe we've ever had an opportunity to meet in > person. Zoom is in person now?=C2=A0 :-) bill --===============8161337236501488089==-- From spam@hell.org Fri Feb 3 01:05:07 2023 From: Mike Begley To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Fri, 03 Feb 2023 01:04:24 +0000 Message-ID: In-Reply-To: <087b01d9375e$30ff46f0$92fdd4d0$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4970485372191432127==" --===============4970485372191432127== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nice! Years back I gave Dr. Jones my PDP-8/L, prior to moving out of Iowa. = I wonder if he still has it, and put it to use. -mike -----Original Message----- From: William Sudbrink via cctalk =20 Sent: Thursday, February 2, 2023 3:29 PM To: 'General Discussion: On-Topic and Off-Topic Posts' Cc: William Sudbrink Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project = active again Forgot the link: https://homepage.divms.uiowa.edu/~jones/pdp8/UI-8/log.shtml -----Original Message----- From: William Sudbrink via cctalk [mailto:cctalk(a)classiccmp.org] Sent: Thursday, February 02, 2023 6:28 PM To: 'General Discussion: On-Topic and Off-Topic Posts' Cc: William Sudbrink Subject: [cctalk] After more than three years, U of Iowa's PDP-8 project acti= ve again After more than three years, U of Iowa's PDP-8 project active again -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============4970485372191432127==-- From cctalk@ibm51xx.net Fri Feb 3 01:19:50 2023 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: CD-R, DVD-R media available Date: Thu, 02 Feb 2023 17:19:14 -0800 Message-ID: <009401d9376d$8831ac60$98950520$@net> In-Reply-To: <408a0783-a26c-09fc-710f-900e6455a3e5@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0964023320252038925==" --===============0964023320252038925== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > For ordinary CD's I've always used MAM-A Gold. Started buying when it > was a Mitsui brand and haven't had a single failure. Chuck, Which brand is MAM-A? -Ali --===============0964023320252038925==-- From sellam.ismail@gmail.com Fri Feb 3 01:26:57 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 17:26:10 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CDM6PR06MB5580672E90704B7C1971C2F4EDD69=40DM6PR06MB?= =?utf-8?q?5580=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4220406117156177574==" --===============4220406117156177574== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 2, 2023 at 3:53 PM Bill Gunshannon via cctalk < cctalk(a)classiccmp.org> wrote: > > On 2/2/2023 6:39 PM, Sellam Abraham via cctalk wrote: > > Hi Jim. > > > > I'd be down for that. It would also be an opportunity to socialize a > > little bit. I don't believe we've ever had an opportunity to meet in > > person. > > Zoom is in person now? :-) > Considering the physical distance separating us, it's a reasonable facsimile ;) Sellam --===============4220406117156177574==-- From sellam.ismail@gmail.com Fri Feb 3 01:44:48 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Thu, 02 Feb 2023 17:44:00 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8285122169124037195==" --===============8285122169124037195== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 2, 2023 at 3:45 PM Van Snyder via cctalk wrote: > On Thu, 2023-02-02 at 18:28 -0500, William Sudbrink via cctalk wrote: > > After more than three years, U of Iowa's PDP-8 project active again > > Years ago, I had a colleague named Prentiss Knowlton who built a > solenoid bank to connect to his PDP-8. He put the solenoid bank on the > keyboard of the 90-rank Schlicker pipe organ in the All Saints > Episcopal Church in Pasadena, CA. It played the music for his wedding. > > Later, he published an album of pipe-organ performances, on the same > organ, entitled "Unplayed by Human Hands." > > https://en.wikipedia.org/wiki/Unplayed_by_Human_Hands > > I don't know whether he still has the computer. > Ooh, very cool! I have his first album (he released two). Looks like he's presently teaching computer science at UCLA ==> https://www.uclaextension.edu/instructors/prentiss-knowlton I'm going to contact him and interview him about this. I'd like to know if the computer could also select different ranks. Thanks for the tip, Van. Sellam Sellam --===============8285122169124037195==-- From ccth6600@gmail.com Fri Feb 3 05:24:14 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 13:23:10 +0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5700370072328666941==" --===============5700370072328666941== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The actual ferrite core doughnuts do not break down with continued use, BUT moisture or mechanical impact or vibration will damage or degrade the ferrite cores. Otherwise the ferrite doughnut will live and maintain its properties "forever". The main cause of core memory mat faults is mechanical strain on the X/Y, sense and inhibit wires. This mechanical strain is caused by use and can be made worse by particular usage patterns causing the core memory mat to vibrate producing an audible ring. CDC's Extended Core Storage (ECS) cabinets had a characteristic sound when you opened the doors. Early on CDC 6000 series machines had a lot of reliability problems with core memory, but eventually there was an ECO where the core memory modules were immersed in potting compound to make the core mat rigid to prevent any vibration. This made the once fragile core perform perfectly for the remaining life of the machine. The core memory in my PDP-8/e machines (H212 board) has the ferrite donuts glued to the PCB via some white adhesive presumably to reduce vibrations. Encasing the core mat in potting resin would have been the better solution as it binds the wires to the ferrite doughnuts. Tom On Thu, Feb 2, 2023 at 11:17 PM Jon Elson via cctalk wrote: > On 2/1/23 22:10, Will Cooke via cctalk wrote: > > > >> On 02/01/2023 3:51 PM CST Paul Koning via cctalk > wrote: > >> > > ot sure about that. What sort of numbers are we talking about? > >> If all else fails there's core memory, which as far as I remember is > pretty much unlimited for both read and write. > >> > >> paul > > I don't know for sure and can't find any references, but I strongly > suspect that core memory would wear out over time, as well. My reasoning > for this is the because in principle it works the same as FRAM. I usually > refer to FRAM as "core on a chip." Over time, the magnetic domains in FRAM > tend to stay in one polarization or another. I see no reason why the > magnetic domains in core wouldn't do the same. However, a single core is > probably bigger than the entire FRAM chip so there are a LOT more domains. > That means it would take a proportional amount of writes to wear out -- > let's just say a million times. In addition, core access was in > microseconds, whereas FRAM and other modern memories are in nanoseconds. > So it takes something like 1000 times longer on the clock on the wall to > perform the same number of writes. So in the end something like a billion > times longer on the calendar to wear it out. > > > > I would be very interested if anyone actually knows and especially if > there are references available. > > I have extreme doubts that this is true. Memory cores are > just tiny versions of pulse transformers, and similar square > loop transformer core materials are used in switching power > supplies that run for decades at high switching > frequencies. Really, FRAM does not work much similarly to > core. The ferroelectric material is usually lead zirconate > titanate, not an actual ferromagnetic material. It is > written by an electric field, not magnetic, and the electric > field is sensed by a field effect transistor. I have NEVER > heard of core wear-out in magnetic core memories. The > flipping of the magnetic polarization in ferrite materials > does not break down the crystal structure. > > Jon > > Jon > > --===============5700370072328666941==-- From cctalk@gtaylor.tnetconsulting.net Fri Feb 3 05:29:54 2023 From: Grant Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Thu, 02 Feb 2023 22:27:30 -0700 Message-ID: <1d81f898-c340-2cdf-263a-b907b6d3ea4b@spamtrap.tnetconsulting.net> In-Reply-To: <14c4ae85-26e4-2ef9-5581-a4c651f528ee@jbrain.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2849231111183934464==" --===============2849231111183934464== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/2/23 4:28 PM, Jim Brain wrote: > Hmm, I'd be happy to do a Zoom call to show folks.  Git can be > complicated, but the simpler items are easy and using the command line > git connected to a github/bitbucket/gitlab repo and a simple git push > and all your local data/files under control are magically on the web for > sharing, if that's the goal. I'd be interested in watching (possibly a recording) of what I think would be a two parter. The first part being setup and normal day to day use. -- I think there are a lot of tutorials that cover this. The second part would be what to do when git is not completely happy; e.g. a change on both the local file and the remote file, or how to restore a specific version of a file, or other less common things. -- Grant. . . . unix || die --===============2849231111183934464==-- From cclist@sydex.com Fri Feb 3 06:12:57 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Thu, 02 Feb 2023 22:12:14 -0800 Message-ID: <58e64045-aec3-c0f0-50e6-3ae22441639e@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7994993553618926430==" --===============7994993553618926430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/2/23 21:23, Tom Hunter via cctalk wrote: > The actual ferrite core doughnuts do not break down with continued use, BUT > moisture or mechanical impact or vibration will damage or degrade the > ferrite cores. Otherwise the ferrite doughnut will live and maintain its > properties "forever". Well, I don't know about that. The CDC 7600 had issues with core overheating and included a "Duty Cycle Integrator" on core. See PDF page 51, page 2-24: http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60367200D_Cyber70-76_Jul75.pdf --Chuvk --===============7994993553618926430==-- From lewissa78@gmail.com Fri Feb 3 07:06:13 2023 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Fri, 03 Feb 2023 01:05:24 -0600 Message-ID: In-Reply-To: <00c8d793-301e-65b3-8f90-4f6653e15eed@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4357337263651834410==" --===============4357337263651834410== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 2, 2023 at 5:54 AM emanuel stiebler via cctalk < cctalk(a)classiccmp.org> wrote: > On 2023-02-02 04:38, David Brownlee wrote: > > > So, what else do you guys use, to make sure your data is safe for the > > years to come? > I wanted to note a story about AWS: I used to be heavy into astronomy imaging (I still am, just less so at the moment since building a new house and other projects is taking much of my attention for now). There is a site Astrobin.com specifically for astronomers to share their images, with a sort of database to store equipment metrics used for each image. It's an interesting service, since with decades of image data, you can now compare your image processing results with similar equipment and gauge how efficiently you're using a tracking mount, focuser, or imaging camera (or judge if quality issues are equipment related or post-processing related). Another interesting aspect of this database is users provide "versions" of their images -- that's been an annoying thing about YouTube for me: you can't revise a video, like you can't have editions. If you've learned new information or want to correct or clarify things, you can try to do cc comments, but basically have to start over with a new video link. That's a pain for content creators who have to "start over" back to 0 views on a video with a new edition, and also annoying for us users who now have to sort through dozens of variants of how-to's or guides, etc. Anyway... What I'm getting to is, the Astrobin database crashed a few years back. Was wiped out and (I think) they were using AWS. The site administration completely confessed it was his mistake -- I forget the details, his letter may be still up somewhere at the site. But basically he clicked something wrong on AWS, and ended up deleting files by accident. Being Amazon, you'd think it was just an easy recovery - no big deal. But nope, the nature of what the admin had done ended up being not easy to undo. Astrobin is a pay service and many people were bitterly angry for losing years of archives. Yes, most users should have their own backup -- but it was the database also of equipment, and decades of revision info (to see the progress of terrestial imaging capability over the years). A good 80+% of my own were wiped. I wasn't bitter - I appreciated that the admin immediately took blame, didn't try to hide it, and "to err is human." But it was a mess for that community. Well - to Amazon's credit, they didn't give up either. Months and months later, gradually some files did end up getting recovered. Again, I don't know the specifics of what Amazon did -- I just know about a year later, I logged in and noticed a great many of my image records had been recovered, and the admin had a note to expect more to get recovered since they were still actively working on the problem. I'm just relaying the story as a real-world example of a recent "data disaster recovery" - sorry I'm not more specific on the details, but astrobin.com still exists and the admin is approachable and may be willing to share lessons learned for those interested. --===============4357337263651834410==-- From ccth6600@gmail.com Fri Feb 3 07:08:33 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 15:07:33 +0800 Message-ID: In-Reply-To: <58e64045-aec3-c0f0-50e6-3ae22441639e@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0536738326190264930==" --===============0536738326190264930== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Chuck, the CDC 7600 duty cycle integrator is really a work-around against overheating and has nothing to do with core reliability and/or endurance. Core and the data stored in it lives "forever" if the operating constraints of the medium are adhered to (temperature being one of the constraints). The 7600 was able to push core access past these constraints, hence needed the duty cycle integrator. Different physical design and/or better cooling could have been alternatives, but the duty cycle integrator was an easy fix once the machine was out in the field and core memory started failing due to overheating. Core written in the 60s would read just fine today unless something external to it destroyed the data. Tom On Fri, Feb 3, 2023 at 2:12 PM Chuck Guzis via cctalk wrote: > On 2/2/23 21:23, Tom Hunter via cctalk wrote: > > The actual ferrite core doughnuts do not break down with continued use, > BUT > > moisture or mechanical impact or vibration will damage or degrade the > > ferrite cores. Otherwise the ferrite doughnut will live and maintain its > > properties "forever". > > Well, I don't know about that. The CDC 7600 had issues with core > overheating and included a "Duty Cycle Integrator" on core. See PDF > page 51, page 2-24: > > > http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60367200D_Cyber70-76_Jul75.= pdf > > --Chuvk > > > --===============0536738326190264930==-- From van.snyder@sbcglobal.net Fri Feb 3 09:03:32 2023 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Fri, 03 Feb 2023 01:02:47 -0800 Message-ID: <0be9ff60bd4e1e7592d3a6417bf10fb32e50d198.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5610011152809335533==" --===============5610011152809335533== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2023-02-02 at 17:44 -0800, Sellam Abraham via cctalk wrote: > On Thu, Feb 2, 2023 at 3:45 PM Van Snyder via cctalk < > cctalk(a)classiccmp.org>wrote: > > On Thu, 2023-02-02 at 18:28 -0500, William Sudbrink via cctalk > > wrote: > > > After more than three years, U of Iowa's PDP-8 project active > > > again > > > > Years ago, I had a colleague named Prentiss Knowlton who built > > asolenoid bank to connect to his PDP-8. He put the solenoid bank on > > thekeyboard of the 90-rank Schlicker pipe organ in the All > > SaintsEpiscopal Church in Pasadena, CA. It played the music for his > > wedding. > > Later, he published an album of pipe-organ performances, on the > > sameorgan, entitled "Unplayed by Human Hands." > > https://en.wikipedia.org/wiki/Unplayed_by_Human_Hands > > > > I don't know whether he still has the computer. > > Ooh, very cool! I have his first album (he released two). > Looks like he's presently teaching computer science at UCLA ==> > https://www.uclaextension.edu/instructors/prentiss-knowlton > > I'm going to contact him and interview him about this. I'd like to > know ifthe computer could also select different ranks. Sellam: Prentiss's brother lives across the street from me, but Prentiss lives quite a distance away. You can use my name if you want to. Van > Thanks for the tip, Van. > Sellam > Sellam --===============5610011152809335533==-- From abs@absd.org Fri Feb 3 09:57:26 2023 From: David Brownlee To: cctalk@classiccmp.org Subject: [cctalk] Re: ZFS, was [... GreaseWeazle ..] Date: Fri, 03 Feb 2023 09:56:35 +0000 Message-ID: In-Reply-To: <00c8d793-301e-65b3-8f90-4f6653e15eed@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6322178633273987227==" --===============6322178633273987227== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2 Feb 2023 at 11:54, emanuel stiebler via cctalk wrote: > > On 2023-02-02 04:38, David Brownlee wrote: > > > That reminds me (looks at 43.5T of zfs pool that has not had a scrub > > since 2021). > > > > It can be nice to have a filesystem which handles redundancy and also > > the option to occasionally read all the data, check end to end > > checksums (in the unlikely case a device returns a successful read > > with bad data), and fixup everything. Does not eliminate the need for > > remote copies, but gives a little extra confidence that the master > > copy is still what it should be :) > > So, what else do you guys use, to make sure your data is safe for the > years to come? Code which can be public in github, code which cannot be public in free gitlab account, (code which evokes Cthulhuian mindworms on reading and should never be shared with others is kept with other locally backed up files). The sata on the main machine is held on 6 disks in ZFS raidz2 (takes 3 disks to fail to lose data). Synced to two remote machines (ZFS in simple config to give integrity but without local redundancy). Sync is via syncthing with staggered file versioning (keeps 365 days of changes for any given file). Most data is pushed only from the main machine, with remotes also able to sync between them, but some folders are set to sync between all. Biggest vulnerability would be an exploit in syncthing, or some common OS level exploit, as all data is online. ("A backup is not a backup when its online, it's just a copy") David --===============6322178633273987227==-- From paulkoning@comcast.net Fri Feb 3 14:27:07 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 09:25:58 -0500 Message-ID: <8FAEC444-0139-4306-A8DB-C9EF94ED8424@comcast.net> In-Reply-To: <58e64045-aec3-c0f0-50e6-3ae22441639e@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6577234713421041818==" --===============6577234713421041818== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2023, at 1:12 AM, Chuck Guzis via cctalk wrote: >=20 > On 2/2/23 21:23, Tom Hunter via cctalk wrote: >> The actual ferrite core doughnuts do not break down with continued use, BUT >> moisture or mechanical impact or vibration will damage or degrade the >> ferrite cores. Otherwise the ferrite doughnut will live and maintain its >> properties "forever". >=20 > Well, I don't know about that. The CDC 7600 had issues with core > overheating and included a "Duty Cycle Integrator" on core. See PDF > page 51, page 2-24: >=20 > http://www.bitsavers.org/pdf/cdc/cyber/cyber_70/60367200D_Cyber70-76_Jul75.= pdf >=20 > --Chuvk That reminds me of a PDP-11 diagnostic -- not usually run -- called the "core= heating test". The way I remember the description is that it would do rapid= memory accesses in a set of addresses that are physically close in the core = memory (obviously this is model-dependent). The idea was to find marginal mem= ories. One reason for not running that test is that it was very slow. From the same era I recall that our IBM 1620 mod 2 had a heating system for t= he memory cabinet, and that after power up you had to wait 10 minutes or so f= or the memory to be warmed up to its normal operating temperature. I don't t= hink I ever saw an explanation why this was done. It's puzzling that temperature would matter. Obviously, when you hit the Cur= ie temperature the data goes away, but for typical magnetic materials that is= in the hundreds of degrees. Does the hysteresis curve shift enough at moder= ate temperatures (a bit over room temperature) to matter? paul --===============6577234713421041818==-- From wrcooke@wrcooke.net Fri Feb 3 14:41:53 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 08:41:15 -0600 Message-ID: <426754454.1711503.1675435275488@email.ionos.com> In-Reply-To: <8FAEC444-0139-4306-A8DB-C9EF94ED8424@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2666021861616963505==" --===============2666021861616963505== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/03/2023 8:25 AM CST Paul Koning via cctalk = wrote: > It's puzzling that temperature would matter. Obviously, when you hit the Cu= rie temperature the data goes away, but for typical magnetic materials that i= s in the hundreds of degrees. Does the hysteresis curve shift enough at moder= ate temperatures (a bit over room temperature) to matter? >=20 > paul Yes. The thresholds shift with temperature. Some companines (DEC?) used tem= perature-compensated amplifiers to address the issue. IBM, on some models li= ke the 1620, kept the cores at a constant (elevated) temperature. https://en.wikipedia.org/wiki/Magnetic-core_memory#Physical_characteristics Will I do not think you can name many great inventions that have been made by marr= ied men. Nikola Tesla --===============2666021861616963505==-- From ard.p850ug1@gmail.com Fri Feb 3 16:15:24 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 16:14:34 +0000 Message-ID: In-Reply-To: <426754454.1711503.1675435275488@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7070177857520253237==" --===============7070177857520253237== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 3, 2023 at 2:41 PM Will Cooke via cctalk wrote: > Yes. The thresholds shift with temperature. Some companines (DEC?) used t= emperature-compensated amplifiers to address the issue. IBM, on some models = like the 1620, kept the cores at a constant (elevated) temperature. Most of the core memories that I've worked on, including quite small ones like the HP9100B, have a thermistor physically next to the core array to control the threshold. I also seem to remember there were MAINDECs for various PDP8 and PDP!1 core units that did the worst case sequence for heating the cores and checked the memory was sill operational. -tony --===============7070177857520253237==-- From elson@pico-systems.com Fri Feb 3 16:20:36 2023 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 10:19:54 -0600 Message-ID: <159fdaac-559d-2815-0b36-47473f7ad444@pico-systems.com> In-Reply-To: <8FAEC444-0139-4306-A8DB-C9EF94ED8424@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7031740200859472189==" --===============7031740200859472189== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/3/23 08:25, Paul Koning via cctalk wrote: > > It's puzzling that temperature would matter. Obviously, when you hit the C= urie temperature the data goes away, but for typical magnetic materials that = is in the hundreds of degrees. Does the hysteresis curve shift enough at mod= erate temperatures (a bit over room temperature) to matter? Yes, it does.=C2=A0 Maybe on earlier memories it was worse, but=20 most later core systems had a thermistor in the core plane,=20 and it adjusted the half-select current to put it right in=20 the middle of the range of susceptance (is that the right=20 term?) for that temperature. My recollection is the 1620 had the core planes in a tank of=20 oil, and the 360/50 had a heater in the air stream flowing=20 past the local store core stack. Jon --===============7031740200859472189==-- From cz@alembic.crystel.com Fri Feb 3 16:40:46 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 11:40:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2120276596446556363==" --===============2120276596446556363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Question: I just used a strong magnet to wipe an old Maxtor MFM drive (magnet on outside of case). Now the drive will not even seek properly on start up, just endlessly moves the heads.. Is the drive now toast? Do MFM drives have embedded servo information on the platter formatted by the factory? CZ --===============2120276596446556363==-- From billdegnan@gmail.com Fri Feb 3 16:43:06 2023 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 11:42:17 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8105837902530618116==" --===============8105837902530618116== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable low level format On Fri, Feb 3, 2023 at 11:40 AM Chris Zach via cctalk wrote: > Question: I just used a strong magnet to wipe an old Maxtor MFM drive > (magnet on outside of case). Now the drive will not even seek properly > on start up, just endlessly moves the heads.. > > Is the drive now toast? Do MFM drives have embedded servo information on > the platter formatted by the factory? > > CZ > --===============8105837902530618116==-- From ard.p850ug1@gmail.com Fri Feb 3 16:45:38 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 16:44:45 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5524070374775934081==" --===============5524070374775934081== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Feb 3, 2023 at 4:40 PM Chris Zach via cctalk wrote: > > Question: I just used a strong magnet to wipe an old Maxtor MFM drive > (magnet on outside of case). Now the drive will not even seek properly > on start up, just endlessly moves the heads.. > > Is the drive now toast? Do MFM drives have embedded servo information on > the platter formatted by the factory? I assume by 'MFM' you mean a drive with an interface similar to the ST412. Embedded servo is rare (unheard-of) on ST412 interfaced drives simply because the manufacturer has no idea how it will be low-level formatted and thus where the sector headers will be. So no safe place for the servo bursts on the data surfaces But a dedicated servo surface is very common on larger such drives. That's why you often see an odd number of data heads. There is a head on each side of each disk, but one is used for the servo. Sounds like you've wiped that. No sensible way to recover I'm afraid -tony --===============5524070374775934081==-- From cclist@sydex.com Fri Feb 3 16:46:11 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 08:44:58 -0800 Message-ID: <1f8c207a-a00d-4a54-3bc4-53ebcb5e906b@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8921597466595650369==" --===============8921597466595650369== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/2/23 23:07, Tom Hunter via cctalk wrote: > Chuck, the CDC 7600 duty cycle integrator is really a work-around against > overheating and has nothing to do with core reliability and/or endurance. > > Core and the data stored in it lives "forever" if the operating constraints > of the medium are adhered to (temperature being one of the constraints). > The 7600 was able to push core access past these constraints, hence needed > the duty cycle integrator. Different physical design and/or better cooling > could have been alternatives, but the duty cycle integrator was an easy fix > once the machine was out in the field and core memory started failing due > to overheating. Tom, I know all of that, having programmed a 7600. As a matter of fact, what's not mentioned in the manual is that a tight loop in a PPU (which did not have a duty cycle integrator) could throw parity errors. Just taking issue with your statement that "core memory is forever". Another problem with very old core is that its physical integrity is often an issue. Cores can crack, being essentially ceramics. I'm reminded of the CE fishing around in the oil bath of a 7090 with what amounted to a magnet on a broomstick to grab loose bits of core. --Chuck --===============8921597466595650369==-- From artgodwin@gmail.com Fri Feb 3 16:54:44 2023 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Computer Museum uses GreaseWeazle to help exonerate Maryland Man Date: Fri, 03 Feb 2023 16:53:57 +0000 Message-ID: In-Reply-To: <1f8c207a-a00d-4a54-3bc4-53ebcb5e906b@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1967454032759374848==" --===============1967454032759374848== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 3, 2023 at 4:45 PM Chuck Guzis via cctalk wrote: > > Another problem with very old core is that its physical integrity is > often an issue. Cores can crack, being essentially ceramics. I'm > reminded of the CE fishing around in the oil bath of a 7090 with what > amounted to a magnet on a broomstick to grab loose bits of core. > > True 'bit rot' ! --===============1967454032759374848==-- From cz@alembic.crystel.com Fri Feb 3 16:58:17 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 11:57:41 -0500 Message-ID: <50eb61df-368b-4a21-3691-353ea32d3717@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0979276323659636137==" --===============0979276323659636137== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Embedded servo is rare (unheard-of) on ST412 interfaced drives simply > because the manufacturer has no idea how it will be low-level > formatted and thus where the sector headers will be. So no safe place > for the servo bursts on the data surfaces *nod* That's what I would think: MFM should allow you physical access to the heads to write the format as you see fit. So head positioning should be mechanical, not servo based. > But a dedicated servo surface is very common on larger such drives. > That's why you often see an odd number of data heads. There is a head > on each side of each disk, but one is used for the servo. This is a Maxtor 2190. The RD54 base disk. I've been having major problems trying to format them on my RQDX3, I'll post that adventure in a bit. In a nutshell the drives only partially format then error out. On Dave G's MFM emulator all the tracks appear to be there. > Sounds like you've wiped that. No sensible way to recover I'm afraid Yep, with 15 yeads it had a servo platter that is gone. Oh well, it's securely erased :-) I'll toss the drive, keep the electronics interface and keep it in mind for the future. C --===============0979276323659636137==-- From cz@alembic.crystel.com Fri Feb 3 17:10:05 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 12:09:27 -0500 Message-ID: <3f593e65-38b3-379c-3307-c7439ce000e7@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4627263308285553211==" --===============4627263308285553211== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Decided to spend some time working on my 11/73 with MFM drives. Currently it has one of my RQDX3 boards (I have 3, 1 in attic), a 40mb ST412 drive (the half height Seagate whatever) which works fine. No issues there. I'm trying to format an RD54 compatible drive and am running into major issues. First, my two RWDX3's have different ROM dates, the old one is 1986 and the new one is 1990. This is important because I can't boot RX33 disk images with my GoTek using the old card but I can using the new one. Question: I'm guessing the old ROMs only supported RX50 disks? Or is it a secret jumper setting. Anyway I do have both RX33 and RX50 versions of XXDP so not a big issue. On to formatting. The old controller (which I used for the 40mb Seagate) had pins 2-3 jumpered on W23. With that the RD54 was able to autoformat but then would crash xxdp as soon as the initial format was done. Odd. So I used the new controller with 1-2 and 3-4 jumpered. Same problem. Then I tried having 1-2 jumpered and did a manual format (not autoformat, select RD54, etc) I noticed that on the old board it would ask me for the date when doing this kind of format, on the new board it would just ask me for the serial number. Odd. Question: Is the ZRQCH0.BIN file calling different routines in the RQDX3 ROM? Anyway after this the drive would format but then do endless seek errors on the "read" portion of the disk check. Two drives did this, so it's probably not the drives. Odd. Putting the drives on the Dave Gesswin MFM reader showed all cylinders could be read. Question: Can Dave G's board be used to low level format an RD54? Can it test physical disk for errors (wasn't sure) Now the drives only format for a minute or two before throwing errors. Looks like something is very confused on XXDP. Not going to try any other disks until I figure this out. Thoughts? Different sites say different things about the RQDX3 jumpers, some say to jumper 2-3 to allow more than 7 heads, some say to jumper pins 1-2 and some say jumper pins 1-2 on "early ROM" and 1-2 3-4 on "later ROM". This is a serious pain, but just what settings should be done to allow low level formatting, and did my previous attempts to low level wedge these disks from the RQDX3 point of view? Can I do a low level wipe with Dave Gesswin's board/software? Thanks! Chris --===============4627263308285553211==-- From ard.p850ug1@gmail.com Fri Feb 3 17:12:57 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 17:12:13 +0000 Message-ID: In-Reply-To: <50eb61df-368b-4a21-3691-353ea32d3717@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1011856785989072703==" --===============1011856785989072703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Feb 3, 2023 at 4:57 PM Chris Zach via cctalk wrote: > Yep, with 15 yeads it had a servo platter that is gone. Oh well, it's > securely erased :-) I'll toss the drive, keep the electronics interface > and keep it in mind for the future. If you have the tools, it's worth carefully dismantling the dead HDA taking photos as you go and keeping parts like the heads and flexiprint. Other bits like the positioner magnet and spinde motor mght be worth keeping too. Some months ago I was working on a Toshiba hard drive in a Stride 440 and I wish I'd had some idea of what was on the flexiprint between the logic board connector and the heads. Of course without a clean room I didn't dare open the HDA, but had a defective or dismantled one been available I'd have paid reasonable money for it. -tony --===============1011856785989072703==-- From g4ajq1@gmail.com Fri Feb 3 17:15:30 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 12:14:50 -0500 Message-ID: <9dd3b4f7-b1b6-3a27-11c4-5d38b01a9c61@gmail.com> In-Reply-To: <3f593e65-38b3-379c-3307-c7439ce000e7@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2106922901613620388==" --===============2106922901613620388== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-03 12:09, Chris Zach via cctalk wrote: > Decided to spend some time working on my 11/73 with MFM drives. > Currently it has one of my RQDX3 boards (I have 3, 1 in attic), a 40mb > ST412 drive (the half height Seagate whatever) which works fine. No > issues there. > > I'm trying to format an RD54 compatible drive and am running into > major issues. First, my two RWDX3's have different ROM dates, the old > one is 1986 and the new one is 1990. This is important because I can't > boot RX33 disk images with my GoTek using the old card but I can using > the new one. > > Question: I'm guessing the old ROMs only supported RX50 disks? Or is > it a secret jumper setting. > > Anyway I do have both RX33 and RX50 versions of XXDP so not a big > issue. On to formatting. > > The old controller (which I used for the 40mb Seagate) had pins 2-3 > jumpered on W23. With that the RD54 was able to autoformat but then > would crash xxdp as soon as the initial format was done. Odd. So I > used the new controller with 1-2 and 3-4 jumpered. Same problem. Then > I tried having 1-2 jumpered and did a manual format (not autoformat, > select RD54, etc) > > I noticed that on the old board it would ask me for the date when > doing this kind of format, on the new board it would just ask me for > the serial number. Odd. > > Question: Is the ZRQCH0.BIN file calling different routines in the > RQDX3 ROM? > > Anyway after this the drive would format but then do endless seek > errors on the "read" portion of the disk check. Two drives did this, > so it's probably not the drives. Odd. Putting the drives on the Dave > Gesswin MFM reader showed all cylinders could be read. > > Question: Can Dave G's board be used to low level format an RD54? Can > it test physical disk for errors (wasn't sure) > > Now the drives only format for a minute or two before throwing errors. > Looks like something is very confused on XXDP. Not going to try any > other disks until I figure this out. > > Thoughts? Different sites say different things about the RQDX3 > jumpers, some say to jumper 2-3 to allow more than 7 heads, some say > to jumper pins 1-2 and some say jumper pins 1-2 on "early ROM" and 1-2 > 3-4 on "later ROM". > > This is a serious pain, but just what settings should be done to allow > low level formatting, and did my previous attempts to low level wedge > these disks from the RQDX3 point of view? Can I do a low level wipe > with Dave Gesswin's board/software? > > Thanks! > Chris Have you tired manually telling ZRQC that it is an RD54? Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============2106922901613620388==-- From alexandre.tabajara@gmail.com Fri Feb 3 17:22:30 2023 From: Alexandre Souza To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 14:21:44 -0300 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2735789455735885933==" --===============2735789455735885933== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I thoug the right one was st512...can you enlighten me on this subject Tony? Enviado do meu Tele-Movel > I assume by 'MFM' you mean a drive with an interface similar to the ST412. > -tony > --===============2735789455735885933==-- From artgodwin@gmail.com Fri Feb 3 17:25:43 2023 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 17:24:53 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4680804181031100735==" --===============4680804181031100735== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Or ST506 ? On Fri, Feb 3, 2023 at 5:21 PM Alexandre Souza via cctalk < cctalk(a)classiccmp.org> wrote: > I thoug the right one was st512...can you enlighten me on this subject > Tony? > > Enviado do meu Tele-Movel > > > > I assume by 'MFM' you mean a drive with an interface similar to the > ST412. > > -tony > > > --===============4680804181031100735==-- From ard.p850ug1@gmail.com Fri Feb 3 17:27:56 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Fri, 03 Feb 2023 17:27:06 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0462375466812554114==" --===============0462375466812554114== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Feb 3, 2023 at 5:21 PM Alexandre Souza wrote: > > I thoug the right one was st512...can you enlighten me on this subject Tony? I've never heard it called that. It's often called 'ST506' but that drive had a few differences from the later ones. it didn't support buffered seeks AFAIK. The ST412 did and was the most common of a family of 3 similar drives (ST406, ST412, ST419) so it tends to be used as the de-facto name of the interface. -tony --===============0462375466812554114==-- From djg@pdp8online.com Fri Feb 3 18:21:08 2023 From: David Gesswein To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 13:20:24 -0500 Message-ID: In-Reply-To: <3f593e65-38b3-379c-3307-c7439ce000e7@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0058787014412814945==" --===============0058787014412814945== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 03, 2023 at 12:09:27PM -0500, Chris Zach wrote: >=20 > Question: Can Dave G's board be used to low level format an RD54? Can it > test physical disk for errors (wasn't sure) >=20 The read test you did should have told you if there were sectors with errors. Using my tools to low level format is only sort of possible. DEC got overly=20 creative with their disk format so some sectors are formmatted differently fo= r=20 controller use. I've haven't written code to be able to reproduce that. If you have an image of a good disk mfm_write can write that to another drive. Somewhat fiddly. Problem with that is it will not have the bad sectors on the new drive properly mapped out so you will get read errors. If there is a tool you can run to test the disk and mark new bad sectors that should fix that problem. I do have an RD54 image that can be used with mfm_write. Search in page for R= D54 http://www.pdp8online.com/mfm/status.shtml --===============0058787014412814945==-- From bfranchuk@jetnet.ab.ca Fri Feb 3 18:22:47 2023 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Fri, 03 Feb 2023 11:22:05 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0965996368316505180==" --===============0965996368316505180== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-02 4:44 p.m., Van Snyder via cctalk wrote: > On Thu, 2023-02-02 at 18:28 -0500, William Sudbrink via cctalk wrote: >> After more than three years, U of Iowa's PDP-8 project active again > > Years ago, I had a colleague named Prentiss Knowlton who built a > solenoid bank to connect to his PDP-8. He put the solenoid bank on the > keyboard of the 90-rank Schlicker pipe organ in the All Saints > Episcopal Church in Pasadena, CA. It played the music for his wedding. > > Later, he published an album of pipe-organ performances, on the same > organ, entitled "Unplayed by Human Hands." > > https://en.wikipedia.org/wiki/Unplayed_by_Human_Hands > > I don't know whether he still has the computer. > Could be hiding in the Organ. :) They don't make I/O devices like that any more. Ben. --===============0965996368316505180==-- From cz@alembic.crystel.com Fri Feb 3 18:52:07 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 13:51:29 -0500 Message-ID: <25ae8152-ef92-94da-6d36-9faed2cab76d@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8793691037372590888==" --===============8793691037372590888== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I do have an RD54 image that can be used with mfm_write. Search in page for= RD54 > http://www.pdp8online.com/mfm/status.shtml Ok. Hm. So the command would be ./mfm_write --emulation RD54_A -d3? This is possibly better than nothing: I could use this to put some sort=20 of format on the drive, then try letting xxdp reformat it. Right now I'm=20 getting this: DR>START CHANGE HW (L) ? Y # UNITS (D) ? 1 UNIT 0 Enter controller IP Address (O) 172150 ? What unit do you want to format [0-255] (D) 0 ? Would you like to revector a single LBN only [Y/N] (L) N ? Do you want to use the "AUTOFORMAT" Mode [Y/N] (L) Y ? Enter unit serial number [1-32000] (D) 12345 ? **** WARNING **** ALL DATA ON SELECTED DRIVE WILL BE DESTROYED Write protect all drives not being formatted. Please verify that the selected drive is ON LINE and NOT write protected. If formatting RX33 media, insert media to be formatted in the selected drive. Do you wish to continue [Y/N] (L) Y ? Y Autosizer found: Unit Cylinders Drive Name 0 1225 RD54 1 RX33 Diskette (FORMATABLE) MSCP Controller Model: 19 Microcode Version: 1 Formatting of Drive 0 Begun. (Oddly enough the old controller doesn't display the progress. I really=20 think it's just talking to the RQDX3 and that is calling the shots as=20 the later ROMs do tell you how far it is and what it's doing which is nice) ZRQC SYS FTL ERR 00007 ON UNIT 00 TST 001 SUB 000 PC: 105742 Controller has reported a fatal error in the FORMAT program. Status: RCT write error Drive 0 was not formatted successfully. ZRQC EOP 1 1 TOTAL ERRS --===============8793691037372590888==-- From tom94022@comcast.net Fri Feb 3 19:08:56 2023 From: Tom Gardner To: cctalk@classiccmp.org Subject: [cctalk] Re: ST512 [WAS:RE: Re: Nuking an MFM drive with a magnet, format/servo gone?] Date: Fri, 03 Feb 2023 11:00:04 -0800 Message-ID: <008001d93801$bd600690$382013b0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3324199527360613594==" --===============3324199527360613594== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The ST512 was a thin-film head version of the ST506, per Seagate :=20 "This increased capacity is accomplished by using the inner portion of the di= sc surface that was previously unused and by increasing the disc track densit= y from 255 tracks per inch to 270 tracks per inch To reliably use the inner p= ortion of the disc. The ST512 uses a new type of read/write head - a "thin fi= lm" head." It was dropped in 1981 due to the lack of a reliable supply of heads and repl= aced by the ST412. -----Original Message----- From: Tony Duell [mailto:ard.p850ug1(a)gmail.com]=20 Sent: Friday, February 03, 2023 9:27 AM To: Alexandre Souza Cc: General Discussion: On-Topic and Off-Topic Posts Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? On Fri, Feb 3, 2023 at 5:21 PM Alexandre Souza wrote: > > I thoug the right one was st512...can you enlighten me on this subject Tony? I've never heard it called that. It's often called 'ST506' but that drive had a few differences from the later= ones. it didn't support buffered seeks AFAIK. The ST412 did and was the most= common of a family of 3 similar drives (ST406, ST412, ST419) so it tends to be used as the de-facto name of the interface. -tony --===============3324199527360613594==-- From cclist@sydex.com Fri Feb 3 19:19:35 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Fri, 03 Feb 2023 11:10:00 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8544271424838555715==" --===============8544271424838555715== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/3/23 10:22, ben via cctalk wrote: > Could be hiding in the Organ. :) > They don't make I/O devices like that any more. > Ben. Very old technology. Pre-electronic Welke Vorsetzer, electronics Marantz Pianocorder and the full-integrated into pianos Sony Disklavier. Remember the radio program "Keyboard Immortals Play Again" hosted by Joseph Tushinsky (President of Sony Superscope)? Or am I dating myself again.... --Chuck --===============8544271424838555715==-- From cz@alembic.crystel.com Fri Feb 3 19:48:57 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 14:48:18 -0500 Message-ID: <7d95c258-6db2-c99e-9396-63ef0b54a734@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1559806794465512966==" --===============1559806794465512966== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wow, this is interesting Dave. Took one of the "formatted badly" disks and did a write of your file. root(a)beaglebone:~/mfm# ./mfm_write --emulation RD54_A -d3 -c1224 -h15 -s 17 Board revision C detected Then a read of the disk: root(a)beaglebone:~/mfm# ./mfm_read --analyze -e rd.dsk Board revision C detected Found drive at select 3 Returning to track 0 Drive RPM 3596.5 Matches count 34 for controller DEC_RQDX3 Header CRC: Polynomial 0x1021 length 16 initial value 0xffff Sector length 512 Data CRC: Polynomial 0x1021 length 16 initial value 0xffff Interleave mismatch previous entry 0, 10 was 2 now 0 Number of heads 15 number of sectors 17 first sector 0 Unable to determine interleave. Interleave value is not required Drive supports buffered seeks (ST412) Found cylinder 200 expected 1224 Disk has recalibrated to track 0 Stopping end of disk search due to recalibration Number of cylinders 1224, 159.8 MB Command line to read disk: --format DEC_RQDX3 --sectors 17,0 --heads 15 --cylinders 1224 --header_crc 0xffff,0x1021,16,0 --data_crc 0xffff,0x1021,16,0 --sector_length 512 --retries 50,4 --drive 3 Retries failed cyl 0 head 0 Bad sectors on cylinder 0 head 0: 0 1 2 Retries failed cyl 0 head 3 Bad sectors on cylinder 0 head 3: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 4 Bad sectors on cylinder 0 head 4: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 5 Bad sectors on cylinder 0 head 5: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 6 Bad sectors on cylinder 0 head 6: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 7 Bad sectors on cylinder 0 head 7: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 8 Bad sectors on cylinder 0 head 8: 0 1 2 3 4 5 6 7 8 9 10 11 12H 13 14 15 16 Retries failed cyl 0 head 9 Bad sectors on cylinder 0 head 9: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 10 Bad sectors on cylinder 0 head 10: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 11 Bad sectors on cylinder 0 head 11: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 12 Bad sectors on cylinder 0 head 12: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 13 Bad sectors on cylinder 0 head 13: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 So looks like the disk is either not taking the format or something is very very wrong. Wonder what happened to all these disks.... C --===============1559806794465512966==-- From david@thecoolbears.org Fri Feb 3 21:48:40 2023 From: David Coolbear To: cctalk@classiccmp.org Subject: [cctalk] Q-BUS Boards available Date: Fri, 03 Feb 2023 14:47:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6247226995623590787==" --===============6247226995623590787== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have the following Q-BUS boards available. M7168 VCB02, QDSS Q 4-plane colour bitmap module M7169 VCB02, QDSS Q 4-plane video controller module M7608 MS630 RAM for KA630 M7608 MS630 RAM for KA630 M7606 KA630 Microvax II CPU M7620 KA650 Q MicroVAX III CPU M7165 Qbus SDI disk adapter I also have a Smoke Signal Broadcasting, dual 8" floppy set and a SS50 bus controller for the same. All are available for pick-up in Queen Creek, AZ, USA. If there's no interest, all will go to recycling. --===============6247226995623590787==-- From g4ajq1@gmail.com Fri Feb 3 22:40:33 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Q-BUS Boards available Date: Fri, 03 Feb 2023 17:39:51 -0500 Message-ID: <41e5d08c-ea28-4538-fbd8-a394a7d4295f@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4687201961779197484==" --===============4687201961779197484== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-03 16:47, David Coolbear via cctalk wrote: > I have the following Q-BUS boards available. > M7168 VCB02, QDSS Q 4-plane colour bitmap module > M7169 VCB02, QDSS Q 4-plane video controller module > M7608 MS630 RAM for KA630 > M7608 MS630 RAM for KA630 > M7606 KA630 Microvax II CPU > M7620 KA650 Q MicroVAX III CPU > M7165 Qbus SDI disk adapter > > I also have a Smoke Signal Broadcasting, dual 8" floppy set and a SS50 bus > controller for the same. All are available for pick-up in Queen Creek, AZ, > USA. > > If there's no interest, all will go to recycling. I would love to take the 4 Microvax boards off your hands if nobody else is interested, I am in Toronto, ON, where are you and what would it cost to get them to me? cheers, Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============4687201961779197484==-- From ccth6600@gmail.com Sat Feb 4 02:27:44 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Sat, 04 Feb 2023 10:26:54 +0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8385101481283866880==" --===============8385101481283866880== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Chris, what kind of magnet did you use? If it was an electromagnet I could imagine that you caused physical damage by something heating up sufficiently. If it was a permanent magnet then it might indeed be servo data which has been erased. Either way I expect you need a very strong magnetic field to erase a hard drive from the outside. Tom On Sat, 4 Feb 2023, 12:40 am Chris Zach via cctalk, wrote: > Question: I just used a strong magnet to wipe an old Maxtor MFM drive > (magnet on outside of case). Now the drive will not even seek properly > on start up, just endlessly moves the heads.. > > Is the drive now toast? Do MFM drives have embedded servo information on > the platter formatted by the factory? > > CZ > --===============8385101481283866880==-- From cz@alembic.crystel.com Sat Feb 4 03:13:10 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 22:12:33 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3239110764119768292==" --===============3239110764119768292== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, formatting an RD53 seems to be working. And the rev 4 ROMs are=20 much nicer than the rev 3 in terms of talking to you. Unit Cylinders Drive Name 0 1024 RD53 1 RX33 Diskette (FORMATABLE) MSCP Controller Model: 19 Microcode Version: 4 Formatting of Drive 0 Begun. ------------ FORMAT PROGRESS REPORT ------------- 1 minute into format ---- Formatting tracks, LBN # 28816 2 minutes into format ---- Formatting tracks, LBN # 57682 3 minutes into format ---- Formatting tracks, LBN # 86514 4 minutes into format ---- Formatting tracks, LBN # 115363 5 minutes into format ---- Reading defect list 6 minutes into format ---- Replacing defect # 3 on head # 0 7 minutes into format ---- Replacing defect # 7 on head # 0 8 minutes into format ---- Replacing defect # 1 on head # 1 9 minutes into format ---- Reading defect list 10 minutes into format ---- Replacing defect # 1 on head # 7 11 minutes into format ---- Third check pass, writing LBN # 31399 12 minutes into format ---- Third check pass, writing LBN # 62815 13 minutes into format ---- Third check pass, writing LBN # 93959 14 minutes into format ---- Third check pass, writing LBN # 125239 15 minutes into format ---- Third check pass, reading LBN # 17935 16 minutes into format ---- Third check pass, reading LBN # 49487 17 minutes into format ---- Third check pass, reading LBN # 80495 18 minutes into format ---- Third check pass, reading LBN # 104336 19 minutes into format ---- Third check pass, reading LBN # 126055 Format Completed. 00012 Rev LBNs 00000 Bad RBNs 00000 Bad DBNs 00000 Bad XBNs 00001 retired FCT used successfully. Drive 0 has been formatted successfully. ZRQC EOP 1 0 TOTAL ERRS On 2/3/2023 1:20 PM, David Gesswein via cctalk wrote: > On Fri, Feb 03, 2023 at 12:09:27PM -0500, Chris Zach wrote: >> >> Question: Can Dave G's board be used to low level format an RD54? Can it >> test physical disk for errors (wasn't sure) >> > The read test you did should have told you if there were sectors with error= s. >=20 > Using my tools to low level format is only sort of possible. DEC got overly > creative with their disk format so some sectors are formmatted differently = for > controller use. I've haven't written code to be able to reproduce that. > If you have an image of a good disk mfm_write can write that to another dri= ve. > Somewhat fiddly. Problem with that is it will not have the bad sectors on > the new drive properly mapped out so you will get read errors. If there is > a tool you can run to test the disk and mark new bad sectors that should fix > that problem. >=20 > I do have an RD54 image that can be used with mfm_write. Search in page for= RD54 > http://www.pdp8online.com/mfm/status.shtml >=20 --===============3239110764119768292==-- From cz@alembic.crystel.com Sat Feb 4 03:48:43 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] RQDX3's: Lessons learned. Date: Fri, 03 Feb 2023 22:48:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5090524215766591482==" --===============5090524215766591482== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Some thoughts on this day of working on MFM drives: 1) MFM drives are just going bad. They were always kind of meh in terms of reliability, but I think even since 2019 (the last time I checked these drives) things have gotten worse. Drives which were readable and good then are now either shot or throwing errors and they have had an easy 3+ years in my upstairs room. 2) There are at least two RQDX3 ROM sets. The earlier one does not support the RX33 floppy and doesn't give any info during formatting. The later version (Version 4) does support the RX33 and is a lot nicer. 3) Seagate drives seem to be pretty good, especially the 20mb ones. They have no problems, work well, and are pretty right-sized for an RT11 system. 4) RD53 drives are weird. Their main failure is the drive head positioner just gets stuck and needs to be worked loose. Unfortunately that requires removing the lid. Fortunately there is a good filter in the drive along with an air handler that runs air from inside the drive body through the filter, then into the spindle where it is blown over the heads. Result is a pretty clean drive on the inside and so far opening the lid doesn't seem to be a recipe for instant destruction. Go figure. I may try an RD53 in one of my Pro/380's. It's about time I loaded up the final version of P/OS, as I can use the Gotek floppy to load everything instead of screwing with the RX50's. Or can I do that and switch disks on the fly with a single Gotek... Hm. 5) For anything bigger, it's time to retire the MFM drives. Unlike RL02's these things just were not that reliable when new and at this point are kind of falling apart. I have not had any trouble with the ESDI disks, but it might just be a matter of time. Perhaps I should look into duplexing my 330mb CDC drive in the 11/84.... CZ --===============5090524215766591482==-- From healyzh@avanthar.com Sat Feb 4 04:35:11 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] RQDX3's: Lessons learned. Date: Fri, 03 Feb 2023 20:34:30 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2425674908112241974==" --===============2425674908112241974== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99d just like to say that 25 years ago, RD53=E2=80=99s were *EVIL*. = I do have one that I should try taking apart. I failed to back it up the fir= st time I powered it on. It didn=E2=80=99t boot the second time. ESDI or SCSI is the way to go, at least that was true 20-25 years ago. Today= I=E2=80=99d be inclined to say SCSI is the way to go. Zane > On Feb 3, 2023, at 7:48 PM, Chris Zach via cctalk = wrote: >=20 > Some thoughts on this day of working on MFM drives: >=20 > 1) MFM drives are just going bad. They were always kind of meh in terms of = reliability, but I think even since 2019 (the last time I checked these drive= s) things have gotten worse. Drives which were readable and good then are now= either shot or throwing errors and they have had an easy 3+ years in my upst= airs room. >=20 > 2) There are at least two RQDX3 ROM sets. The earlier one does not support = the RX33 floppy and doesn't give any info during formatting. The later versio= n (Version 4) does support the RX33 and is a lot nicer. >=20 > 3) Seagate drives seem to be pretty good, especially the 20mb ones. They ha= ve no problems, work well, and are pretty right-sized for an RT11 system. >=20 > 4) RD53 drives are weird. Their main failure is the drive head positioner j= ust gets stuck and needs to be worked loose. Unfortunately that requires remo= ving the lid. Fortunately there is a good filter in the drive along with an a= ir handler that runs air from inside the drive body through the filter, then = into the spindle where it is blown over the heads. Result is a pretty clean d= rive on the inside and so far opening the lid doesn't seem to be a recipe for= instant destruction. Go figure. >=20 > I may try an RD53 in one of my Pro/380's. It's about time I loaded up the f= inal version of P/OS, as I can use the Gotek floppy to load everything instea= d of screwing with the RX50's. Or can I do that and switch disks on the fly w= ith a single Gotek... Hm. >=20 > 5) For anything bigger, it's time to retire the MFM drives. Unlike RL02's t= hese things just were not that reliable when new and at this point are kind o= f falling apart. I have not had any trouble with the ESDI disks, but it might= just be a matter of time. Perhaps I should look into duplexing my 330mb CDC = drive in the 11/84.... >=20 > CZ --===============2425674908112241974==-- From cz@alembic.crystel.com Sat Feb 4 05:03:43 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: [SPAM] RQDX3's: Lessons learned. Date: Sat, 04 Feb 2023 00:03:07 -0500 Message-ID: <779339a5-033f-4ed7-c21e-868c6b058dde@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5253821787518304605==" --===============5253821787518304605== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yeah at this point pop it open, unlock the heads (the white cam down at=20 the base there, trip it) and get the heads to move. They should smoothly=20 move with a bit of effort. Then fire it up and see if anything works. I'm going to run this one for a bit in the backup pdp11 here, see if it=20 runs if you fire it up every month or two. Once again what do I have to=20 lose :-) I should probably install a TK50 for backups. C On 2/3/2023 11:34 PM, Zane Healy wrote: > I=E2=80=99d just like to say that 25 years ago, RD53=E2=80=99s were *EVIL*.= I do have one that I should try taking apart. I failed to back it up the f= irst time I powered it on. It didn=E2=80=99t boot the second time. >=20 > ESDI or SCSI is the way to go, at least that was true 20-25 years ago. Tod= ay I=E2=80=99d be inclined to say SCSI is the way to go. >=20 > Zane >=20 >=20 >=20 >> On Feb 3, 2023, at 7:48 PM, Chris Zach via cctalk wrote: >> >> Some thoughts on this day of working on MFM drives: >> >> 1) MFM drives are just going bad. They were always kind of meh in terms of= reliability, but I think even since 2019 (the last time I checked these driv= es) things have gotten worse. Drives which were readable and good then are no= w either shot or throwing errors and they have had an easy 3+ years in my ups= tairs room. >> >> 2) There are at least two RQDX3 ROM sets. The earlier one does not support= the RX33 floppy and doesn't give any info during formatting. The later versi= on (Version 4) does support the RX33 and is a lot nicer. >> >> 3) Seagate drives seem to be pretty good, especially the 20mb ones. They h= ave no problems, work well, and are pretty right-sized for an RT11 system. >> >> 4) RD53 drives are weird. Their main failure is the drive head positioner = just gets stuck and needs to be worked loose. Unfortunately that requires rem= oving the lid. Fortunately there is a good filter in the drive along with an = air handler that runs air from inside the drive body through the filter, then= into the spindle where it is blown over the heads. Result is a pretty clean = drive on the inside and so far opening the lid doesn't seem to be a recipe fo= r instant destruction. Go figure. >> >> I may try an RD53 in one of my Pro/380's. It's about time I loaded up the = final version of P/OS, as I can use the Gotek floppy to load everything inste= ad of screwing with the RX50's. Or can I do that and switch disks on the fly = with a single Gotek... Hm. >> >> 5) For anything bigger, it's time to retire the MFM drives. Unlike RL02's = these things just were not that reliable when new and at this point are kind = of falling apart. I have not had any trouble with the ESDI disks, but it migh= t just be a matter of time. Perhaps I should look into duplexing my 330mb CDC= drive in the 11/84.... >> >> CZ >=20 --===============5253821787518304605==-- From emu@e-bbes.com Sat Feb 4 12:33:01 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Sat, 04 Feb 2023 07:32:19 -0500 Message-ID: In-Reply-To: <3f593e65-38b3-379c-3307-c7439ce000e7@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4801841066100801883==" --===============4801841066100801883== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-03 12:09, Chris Zach via cctalk wrote: > Decided to spend some time working on my 11/73 with MFM drives. You don't have a MicoVAX 2000 sitting around? Did you use the RD54 by any chance in a different system, and low level formatted it there? --===============4801841066100801883==-- From emu@e-bbes.com Sat Feb 4 12:39:57 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Sat, 04 Feb 2023 07:39:22 -0500 Message-ID: <369855c2-f83c-97af-0387-defd4f2129e6@e-bbes.com> In-Reply-To: <50eb61df-368b-4a21-3691-353ea32d3717@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7479280640448032677==" --===============7479280640448032677== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-03 11:57, Chris Zach via cctalk wrote: > This is a Maxtor 2190. The RD54 base disk. I've been having major > problems trying to format them on my RQDX3, I'll post that adventure in > a bit. In a nutshell the drives only partially format then error out. On > Dave G's MFM emulator all the tracks appear to be there. OK, is it a MAXTOR 2190, or a RD54? If it is really an RD54, it has the weird DEC sectors with the bad block information. If it doesn't have the bad blocks information written in the "DEC way" it won't be recognized as a RD54 --===============7479280640448032677==-- From emu@e-bbes.com Sat Feb 4 12:44:56 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3's: Lessons learned. Date: Sat, 04 Feb 2023 07:20:57 -0500 Message-ID: <37750928-2f3c-de17-dc97-7834266cd380@e-bbes.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5961984726228643814==" --===============5961984726228643814== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-03 22:48, Chris Zach via cctalk wrote: > 2) There are at least two RQDX3 ROM sets. The earlier one does not > support the RX33 floppy and doesn't give any info during formatting. The > later version (Version 4) does support the RX33 and is a lot nicer. Is it just the ROMs, or also some HW changes? Do we have backup of the newer versions? --===============5961984726228643814==-- From glen.slick@gmail.com Sat Feb 4 14:38:11 2023 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3's: Lessons learned. Date: Sat, 04 Feb 2023 06:37:20 -0800 Message-ID: In-Reply-To: <37750928-2f3c-de17-dc97-7834266cd380@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0921090133748007084==" --===============0921090133748007084== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 4, 2023, 4:44 AM emanuel stiebler via cctalk < cctalk(a)classiccmp.org> wrote: > On 2023-02-03 22:48, Chris Zach via cctalk wrote: > > > 2) There are at least two RQDX3 ROM sets. The earlier one does not > > support the RX33 floppy and doesn't give any info during formatting. The > > later version (Version 4) does support the RX33 and is a lot nicer. > > Is it just the ROMs, or also some HW changes? > Do we have backup of the newer versions? > http://www.dunnington.info/public/DECROMs/ http://www.dunnington.info/public/DECROMs/ROMlist > 23-216E5 23-217E5 M7555 16K RQDX3 T-11 code issue 1 0 23-217E5 23-216E5 M7555 16K RQDX3 T-11 code issue 1 1 23-243E5 23-244E5 M7555 16K RQDX3 T-11 code issue 2 0 23-244E5 23-243E5 M7555 16K RQDX3 T-11 code issue 2 1 23-285E5 23-286E5 M7555 16K RQDX3 T-11 code issue 3 0 up to RD53 only(?) 23-286E5 23-285E5 M7555 16K RQDX3 T-11 code issue 3 1 up to RD53 only(?) 23-339E5 23-340E5 M7555 16K RQDX3 T-11 code issue 4 0 Handles RD54 23-340E5 23-339E5 M7555 16K RQDX3 T-11 code issue 4 1 Handles RD54 Some good 30+ year old information here: http://www.ibiblio.org/pub/academic/computer-science/history/pdp-11/hardware/= third-party-disks.txt > --===============0921090133748007084==-- From pete@dunnington.plus.com Sat Feb 4 15:31:24 2023 From: Pete Turnbull To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3's: Lessons learned. Date: Sat, 04 Feb 2023 15:21:53 +0000 Message-ID: <27af9e21-6ba0-56e7-c5b1-c95e28a5efa2@dunnington.plus.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8570453365763878143==" --===============8570453365763878143== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 04/02/2023 14:37, Glen Slick via cctalk wrote: >> On 2023-02-03 22:48, Chris Zach via cctalk wrote: >> >> Is it just the ROMs, or also some HW changes? >> Do we have backup of the newer versions? > > http://www.dunnington.info/public/DECROMs/ > http://www.dunnington.info/public/DECROMs/ROMlist It's just the ROMs, though IIRC there is a small difference in the meaning of one of the jumper settings. And just an FYI for the list: that domain came into existence amny years ago following a problem with my old ISP/website when it was taken over by another. Partly as compensation, they provided that domain, but now it looks like it might be going away and I've had no luck with their tech support. Again. Sigh. The data will be preserved and re-homed, maybe even expanded, but I don't know if the domain name will need to change. -- Pete Pete Turnbull --===============8570453365763878143==-- From glen.slick@gmail.com Sat Feb 4 19:08:39 2023 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3's: Lessons learned. Date: Sat, 04 Feb 2023 11:07:46 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7094406856255153544==" --===============7094406856255153544== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Some other good sources of information: PDP-11 Diagnostic Database - module "ZRQC" http://www.retrocmp.com/tools/pdp-11-diagnostic-database/202-pdp-11-diagnosti= cs-database RQDX3 firmware source code. Not sure what version this is. http://www.bitsavers.org/pdf/dec/qbus/rqdxx/rqdx3_src.zip --===============7094406856255153544==-- From cz@beaker.crystel.com Sat Feb 4 21:23:08 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 17:08:58 +0000 Message-ID: <5e84e9d7-652a-d084-97cb-b4bdeb4bcad1@beaker.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0855029037995496748==" --===============0855029037995496748== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Decided to spend some time working on my 11/73 with MFM drives. Currently it has one of my RQDX3 boards (I have 3, 1 in attic), a 40mb ST412 drive (the half height Seagate whatever) which works fine. No issues there. I'm trying to format an RD54 compatible drive and am running into major issues. First, my two RWDX3's have different ROM dates, the old one is 1986 and the new one is 1990. This is important because I can't boot RX33 disk images with my GoTek using the old card but I can using the new one. Question: I'm guessing the old ROMs only supported RX50 disks? Or is it a secret jumper setting. Anyway I do have both RX33 and RX50 versions of XXDP so not a big issue. On to formatting. The old controller (which I used for the 40mb Seagate) had pins 2-3 jumpered on W23. With that the RD54 was able to autoformat but then would crash xxdp as soon as the initial format was done. Odd. So I used the new controller with 1-2 and 3-4 jumpered. Same problem. Then I tried having 1-2 jumpered and did a manual format (not autoformat, select RD54, etc) I noticed that on the old board it would ask me for the date when doing this kind of format, on the new board it would just ask me for the serial number. Odd. Question: Is the ZRQCH0.BIN file calling different routines in the RQDX3 ROM? Anyway after this the drive would format but then do endless seek errors on the "read" portion of the disk check. Two drives did this, so it's probably not the drives. Odd. Putting the drives on the Dave Gesswin MFM reader showed all cylinders could be read. Question: Can Dave G's board be used to low level format an RD54? Can it test physical disk for errors (wasn't sure) Now the drives only format for a minute or two before throwing errors. Looks like something is very confused on XXDP. Not going to try any other disks until I figure this out. Thoughts? Different sites say different things about the RQDX3 jumpers, some say to jumper 2-3 to allow more than 7 heads, some say to jumper pins 1-2 and some say jumper pins 1-2 on "early ROM" and 1-2 3-4 on "later ROM". This is a serious pain, but just what settings should be done to allow low level formatting, and did my previous attempts to low level wedge these disks from the RQDX3 point of view? Can I do a low level wipe with Dave Gesswin's board/software? Thanks! Chris --===============0855029037995496748==-- From cz@beaker.crystel.com Sat Feb 4 21:23:39 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 17:15:54 +0000 Message-ID: In-Reply-To: <9dd3b4f7-b1b6-3a27-11c4-5d38b01a9c61@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7742664088236097811==" --===============7742664088236097811== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Yes, the no autoformat option allows me to specify RD54. C On 2/3/2023 12:14 PM, Nigel Johnson Ham via cctalk wrote: > On 2023-02-03 12:09, Chris Zach via cctalk wrote: >> Decided to spend some time working on my 11/73 with MFM drives. >> Currently it has one of my RQDX3 boards (I have 3, 1 in attic), a 40mb >> ST412 drive (the half height Seagate whatever) which works fine. No >> issues there. >> >> I'm trying to format an RD54 compatible drive and am running into >> major issues. First, my two RWDX3's have different ROM dates, the old >> one is 1986 and the new one is 1990. This is important because I can't >> boot RX33 disk images with my GoTek using the old card but I can using >> the new one. >> >> Question: I'm guessing the old ROMs only supported RX50 disks? Or is >> it a secret jumper setting. >> >> Anyway I do have both RX33 and RX50 versions of XXDP so not a big >> issue. On to formatting. >> >> The old controller (which I used for the 40mb Seagate) had pins 2-3 >> jumpered on W23. With that the RD54 was able to autoformat but then >> would crash xxdp as soon as the initial format was done. Odd. So I >> used the new controller with 1-2 and 3-4 jumpered. Same problem. Then >> I tried having 1-2 jumpered and did a manual format (not autoformat, >> select RD54, etc) >> >> I noticed that on the old board it would ask me for the date when >> doing this kind of format, on the new board it would just ask me for >> the serial number. Odd. >> >> Question: Is the ZRQCH0.BIN file calling different routines in the >> RQDX3 ROM? >> >> Anyway after this the drive would format but then do endless seek >> errors on the "read" portion of the disk check. Two drives did this, >> so it's probably not the drives. Odd. Putting the drives on the Dave >> Gesswin MFM reader showed all cylinders could be read. >> >> Question: Can Dave G's board be used to low level format an RD54? Can >> it test physical disk for errors (wasn't sure) >> >> Now the drives only format for a minute or two before throwing errors. >> Looks like something is very confused on XXDP. Not going to try any >> other disks until I figure this out. >> >> Thoughts? Different sites say different things about the RQDX3 >> jumpers, some say to jumper 2-3 to allow more than 7 heads, some say >> to jumper pins 1-2 and some say jumper pins 1-2 on "early ROM" and 1-2 >> 3-4 on "later ROM". >> >> This is a serious pain, but just what settings should be done to allow >> low level formatting, and did my previous attempts to low level wedge >> these disks from the RQDX3 point of view? Can I do a low level wipe >> with Dave Gesswin's board/software? >> >> Thanks! >> Chris > > Have you tired manually telling ZRQC that it is an RD54? > > Nigel > > --===============7742664088236097811==-- From cz@beaker.crystel.com Sat Feb 4 21:24:11 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 19:39:26 +0000 Message-ID: <939f952c-2dc9-c577-89d9-5073884c5340@beaker.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6875740634799103243==" --===============6875740634799103243== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wow, this is interesting Dave. Took one of the "formatted badly" disks and did a write of your file. root(a)beaglebone:~/mfm# ./mfm_write --emulation RD54_A -d3 -c1224 -h15 -s 17 Board revision C detected Then a read of the disk: root(a)beaglebone:~/mfm# ./mfm_read --analyze -e rd.dsk Board revision C detected Found drive at select 3 Returning to track 0 Drive RPM 3596.5 Matches count 34 for controller DEC_RQDX3 Header CRC: Polynomial 0x1021 length 16 initial value 0xffff Sector length 512 Data CRC: Polynomial 0x1021 length 16 initial value 0xffff Interleave mismatch previous entry 0, 10 was 2 now 0 Number of heads 15 number of sectors 17 first sector 0 Unable to determine interleave. Interleave value is not required Drive supports buffered seeks (ST412) Found cylinder 200 expected 1224 Disk has recalibrated to track 0 Stopping end of disk search due to recalibration Number of cylinders 1224, 159.8 MB Command line to read disk: --format DEC_RQDX3 --sectors 17,0 --heads 15 --cylinders 1224 --header_crc 0xffff,0x1021,16,0 --data_crc 0xffff,0x1021,16,0 --sector_length 512 --retries 50,4 --drive 3 Retries failed cyl 0 head 0 Bad sectors on cylinder 0 head 0: 0 1 2 Retries failed cyl 0 head 3 Bad sectors on cylinder 0 head 3: 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 4 Bad sectors on cylinder 0 head 4: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 5 Bad sectors on cylinder 0 head 5: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 6 Bad sectors on cylinder 0 head 6: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 7 Bad sectors on cylinder 0 head 7: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 8 Bad sectors on cylinder 0 head 8: 0 1 2 3 4 5 6 7 8 9 10 11 12H 13 14 15 16 Retries failed cyl 0 head 9 Bad sectors on cylinder 0 head 9: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 10 Bad sectors on cylinder 0 head 10: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 11 Bad sectors on cylinder 0 head 11: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 12 Bad sectors on cylinder 0 head 12: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Retries failed cyl 0 head 13 Bad sectors on cylinder 0 head 13: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 So looks like the disk is either not taking the format or something is very very wrong. Wonder what happened to all these disks.... C --===============6875740634799103243==-- From cz@beaker.crystel.com Sat Feb 4 21:24:39 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Formatting and using RQDX3's and 2190's. Date: Fri, 03 Feb 2023 20:55:23 +0000 Message-ID: In-Reply-To: <7d95c258-6db2-c99e-9396-63ef0b54a734@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3924438080988292875==" --===============3924438080988292875== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Running a non-reformatted disk through Dave G's mfm device got me the following after running a mfm_write to the whole disk followed by an mfm_read: Expected 312120 sectors got 311766 good sectors, 282 bad header, 72 bad data 0 sectors marked bad or spare 49 sectors corrected with ECC. Max bits in burst corrected 2 Track read time in ms min 18.260750 max 2098.231833 avg 35.600018 So.... 354 bad sectors, and 49 more that were only readable with ECC. That's not too great, I think I'll shelve the Maxtor drives and just go with ESDI when needed. Those seem to be a *lot* more reliable than MFM. C --===============3924438080988292875==-- From maxwell@buffalo.edu Sat Feb 4 21:25:09 2023 From: John Maxwell To: cctalk@classiccmp.org Subject: [cctalk] Re: Q-BUS Boards available Date: Fri, 03 Feb 2023 22:13:34 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1617995053040228393==" --===============1617995053040228393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi David, If still available, I'd like the uVII RAM and CPU and SCSI adapter. Any int= erest in shipping to the USA? I'd pay for freight. I have been looking for a = Qbus SCSI adapter for a while now. Even if that's the only item that you are = sending. Thanks, -John -----Original Message----- From: David Coolbear via cctalk =20 Sent: Friday, 3 February, 2023 16:48 To: cctalk(a)classiccmp.org Cc: David Coolbear Subject: [cctalk] Q-BUS Boards available I have the following Q-BUS boards available. M7168 VCB02, QDSS Q 4-plane colour bitmap module M7169 VCB02, QDSS Q 4-plane video controller module M7608 MS630 RAM for KA630 M7608 MS630 RAM for KA630 M7606 KA630 Microvax II CPU M7620 KA650 Q MicroVAX III CPU M7165 Qbus SDI disk adapter I also have a Smoke Signal Broadcasting, dual 8" floppy set and a SS50 bus co= ntroller for the same. All are available for pick-up in Queen Creek, AZ, USA. If there's no interest, all will go to recycling. --===============1617995053040228393==-- From cz@beaker.crystel.com Sat Feb 4 21:25:38 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Sat, 04 Feb 2023 02:28:55 +0000 Message-ID: <16986a01-f91e-06ee-f40e-75cb4fae4000@beaker.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6171076761351067297==" --===============6171076761351067297== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Perm magnet. Those neodynium magnets are powerful, keep them away from=20 disks. C On 2/3/2023 9:26 PM, Tom Hunter via cctalk wrote: > Chris, what kind of magnet did you use? > If it was an electromagnet I could imagine that you caused physical damage > by something heating up sufficiently. If it was a permanent magnet then it > might indeed be servo data which has been erased. Either way I expect you > need a very strong magnetic field to erase a hard drive from the outside. > Tom >=20 > On Sat, 4 Feb 2023, 12:40 am Chris Zach via cctalk, > wrote: >=20 >> Question: I just used a strong magnet to wipe an old Maxtor MFM drive >> (magnet on outside of case). Now the drive will not even seek properly >> on start up, just endlessly moves the heads.. >> >> Is the drive now toast? Do MFM drives have embedded servo information on >> the platter formatted by the factory? >> >> CZ >> --===============6171076761351067297==-- From glen.slick@gmail.com Sat Feb 4 21:43:37 2023 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: Q-BUS Boards available Date: Sat, 04 Feb 2023 13:42:46 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CCO1PR15MB482897CA83A387FDD7F70F5FB3D79=40CO1PR15MB?= =?utf-8?q?4828=2Enamprd15=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3601107173661684648==" --===============3601107173661684648== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Are you referring to this board listed below? M7165 Qbus SDI disk adapter That's not SCSI. That's one board of a two board set, the other being the M7164, that are an SDI controller for RA6x, RA7x, RA8x, RA9x drives. On Sat, Feb 4, 2023, 1:22 PM John Maxwell via cctalk wrote: > Hi David, > If still available, I'd like the uVII RAM and CPU and SCSI adapter. Any > interest in shipping to the USA? I'd pay for freight. I have been looking > for a Qbus SCSI adapter for a while now. Even if that's the only item that > you are sending. > > Thanks, > -John > > -----Original Message----- > From: David Coolbear via cctalk > Sent: Friday, 3 February, 2023 16:48 > To: cctalk(a)classiccmp.org > Cc: David Coolbear > Subject: [cctalk] Q-BUS Boards available > > I have the following Q-BUS boards available. > M7168 VCB02, QDSS Q 4-plane colour bitmap module > M7169 VCB02, QDSS Q 4-plane video controller module > M7608 MS630 RAM for KA630 > M7608 MS630 RAM for KA630 > M7606 KA630 Microvax II CPU > M7620 KA650 Q MicroVAX III CPU > M7165 Qbus SDI disk adapter > --===============3601107173661684648==-- From barythrin@gmail.com Sun Feb 5 03:13:44 2023 From: John Herron To: cctalk@classiccmp.org Subject: [cctalk] Re: After more than three years, U of Iowa's PDP-8 project active again Date: Sat, 04 Feb 2023 21:12:54 -0600 Message-ID: In-Reply-To: <087601d9375e$02439fa0$06cadee0$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6323297690918894850==" --===============6323297690918894850== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit What brought the project back to life? Is there a curriculum or student interest in computing history there? On Thu, Feb 2, 2023, 5:28 PM William Sudbrink via cctalk < cctalk(a)classiccmp.org> wrote: > After more than three years, U of Iowa's PDP-8 project active again > --===============6323297690918894850==-- From emu@e-bbes.com Sun Feb 5 11:12:48 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Sun, 05 Feb 2023 06:12:05 -0500 Message-ID: In-Reply-To: <16986a01-f91e-06ee-f40e-75cb4fae4000@beaker.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8104389628033138149==" --===============8104389628033138149== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-03 21:28, Chris Zach via cctalk wrote: > Perm magnet. Those neodynium magnets are powerful, keep them away from > disks. Keep "all" magnets away from disks :) --===============8104389628033138149==-- From ard.p850ug1@gmail.com Sun Feb 5 11:17:45 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Nuking an MFM drive with a magnet, format/servo gone? Date: Sun, 05 Feb 2023 11:16:42 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1073134193948495309==" --===============1073134193948495309== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, Feb 5, 2023 at 11:12 AM emanuel stiebler via cctalk wrote: > Keep "all" magnets away from disks :) The hubs of 3.5" floppy disks and of the disk packs used in RK05s, RL01s/02s, RK07s, etc are locked to the spindle by a ring magnet. -tony --===============1073134193948495309==-- From cz@beaker.crystel.com Sun Feb 5 14:24:51 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3's: Lessons learned. Date: Sat, 04 Feb 2023 21:25:00 -0500 Message-ID: <967d4296-b9f2-f9ca-751a-f9425dcf89c7@beaker.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3240066480715146378==" --===============3240066480715146378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thank you, good information. Found this from Midwest systems. They were a solid reseller back in the 1980's and this is probably the best first person vendor supported info on jumper settings for RQDX3's. READ BEFORE INSTALLING DISK DRIVE 2/89 RD54 MAXTOR * WARNING: This disk drive has been hardware formatted for an RQDX3. Do not attempt to format this drive on a MicroVAX using the Customer Confidence Diagnostics. The format is not compatible with this drive. If reformat is absolutely necessary, please contact Midwest Systems Technical Support Department first. 1. The RQDX3 being used MUST be inspected to determine its version, and the W23 jumper MUST be configured accordingly: (FAILURE TO DO SO MAY DESTROY THE HARDWARE FORMAT.) Version 3 Identification IF: Location 1: ROM 244E5, or 286E5; Location 2: ROM 243E5, or 285E5 THEN: at W23 jumper between post 1 & 2 only. Version 4 Identification IF: Location 1: ROM 340E5; Location 2: ROM 339E5 THEN: at W23 jumper between posts 1 & 2, and 3 & 4. 2. Depending on the drive version, set the white or blue unit select jumper (located in the rear of the drive on the printed circuit board) between C and 3 or 2 and 3 for drive zero (0). --===============3240066480715146378==-- From paulkoning@comcast.net Sun Feb 5 18:12:21 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3's: Lessons learned. Date: Sun, 05 Feb 2023 13:11:39 -0500 Message-ID: <267557C6-3CAD-4B37-8DC2-E4E7FB6B9E0E@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3340145049018041517==" --===============3340145049018041517== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2023, at 10:48 PM, Chris Zach via cctalk wrote: >=20 > ... > I may try an RD53 in one of my Pro/380's. It's about time I loaded up the f= inal version of P/OS, as I can use the Gotek floppy to load everything instea= d of screwing with the RX50's. Or can I do that and switch disks on the fly w= ith a single Gotek... Hm. Remember that on the Pro the RD53 is formatted differently. Pro hard drives = always have 16 sectors per track, while a number of the MFM drives are format= ted with a different sector count on the RQDX controllers. I don't remember if P/OS can format drives. RT11 can, and I recently added i= t to my RSTS port. paul --===============3340145049018041517==-- From cedric@cedric.net Tue Feb 7 10:52:54 2023 From: Cedric Amand To: cctalk@classiccmp.org Subject: [cctalk] Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 11:46:00 +0100 Message-ID: <9ee6a041-e5a8-4763-b886-ad6e6efd70f4@technoir> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5186635323994530571==" --===============5186635323994530571== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I had a dream ; that someone makes a small telnet to chatgpt gateway (using a= zure chatgpt API possibly ?) So that we could telnet our retro devices to the= hype of the year, and get chtgpt answers in our TRS80, PDP and such. --===============5186635323994530571==-- From jon@jonworld.com Tue Feb 7 10:54:59 2023 From: Jonathan Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 10:54:13 +0000 Message-ID: In-Reply-To: <9ee6a041-e5a8-4763-b886-ad6e6efd70f4@technoir> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5920797867843859360==" --===============5920797867843859360== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I know of people who've already done a CLI setup, so this next step isn't that far off. On Tue, Feb 7, 2023 at 10:52 AM Cedric Amand via cctalk wrote: > > I had a dream ; that someone makes a small telnet to chatgpt gateway (using= azure chatgpt API possibly ?) So that we could telnet our retro devices to t= he hype of the year, and get chtgpt answers in our TRS80, PDP and such. --=20 -Jon +44 7792 149029 --===============5920797867843859360==-- From cedric@cedric.net Tue Feb 7 11:28:12 2023 From: Cedric Amand To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 12:27:33 +0100 Message-ID: <3fde2c28-3d0f-4792-913c-5a6b647f36a0@technoir> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7119377867413251584==" --===============7119377867413251584== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've looked at the problem a bit, there are two issues to solve at first glan= ce ; (A) there doesn't seem to be a telnet server library in python, so whate= ver you do you have to write your own telnet server, which is a bit more than= just handling the sockets and newlines and of course (B) this has to be link= ed to someone's API key, although we could simply release the code and have e= veryone run their own little gateway. So, it's both simple and not simple. Ma= ybe another language ( perl comes to mind - NetServer:Generic ) would be bett= er suited to run a telnet server. --===============7119377867413251584==-- From emu@e-bbes.com Tue Feb 7 12:25:55 2023 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 07:01:15 -0500 Message-ID: <2c6090b0-71da-84fd-6e7f-b1c8ec29f24e@e-bbes.com> In-Reply-To: <9ee6a041-e5a8-4763-b886-ad6e6efd70f4@technoir> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3512127502334259103==" --===============3512127502334259103== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2023-02-07 05:46, Cedric Amand via cctalk wrote: > I had a dream ; that someone makes a small telnet to chatgpt gateway (using= azure chatgpt API possibly ?) So that we could telnet our retro devices to t= he hype of the year, and get chtgpt answers in our TRS80, PDP and such. I'm not sure this group is exactly about following the latest hype :) ChatGPT? Eliza on steroids ;-) --===============3512127502334259103==-- From artgodwin@gmail.com Tue Feb 7 13:23:17 2023 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 13:22:29 +0000 Message-ID: In-Reply-To: <2c6090b0-71da-84fd-6e7f-b1c8ec29f24e@e-bbes.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4244675060312976325==" --===============4244675060312976325== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Fortunately the hype cycle already seems to be on the down trend, as people realise it's not an efficient way to handle natural-language questions but is an extremely effective bullshit generator. It may get as far as replacing politicians and estate agents as the archetypal liar, which will hurt actual AI for years to come. On Tue, Feb 7, 2023 at 12:25 PM emanuel stiebler via cctalk < cctalk(a)classiccmp.org> wrote: > On 2023-02-07 05:46, Cedric Amand via cctalk wrote: > > I had a dream ; that someone makes a small telnet to chatgpt gateway > (using azure chatgpt API possibly ?) So that we could telnet our retro > devices to the hype of the year, and get chtgpt answers in our TRS80, PDP > and such. > > I'm not sure this group is exactly about following the latest hype :) > > ChatGPT? Eliza on steroids ;-) > > --===============4244675060312976325==-- From abuse@cabal.org.uk Tue Feb 7 14:48:00 2023 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 15:47:14 +0100 Message-ID: In-Reply-To: <3fde2c28-3d0f-4792-913c-5a6b647f36a0@technoir> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3587335228067541662==" --===============3587335228067541662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Feb 07, 2023 at 12:27:33PM +0100, Cedric Amand via cctalk wrote: > I've looked at the problem a bit, there are two issues to solve at first > glance ; (A) there doesn't seem to be a telnet server library in python, > so whatever you do you have to write your own telnet server, which is a > bit more than just handling the sockets and newlines You're overthinking this. Go old-school and write it as a regular REPL command which is spawned from inetd. You don't actually need to implement TELNET protocol for this as any sane telnet(1) client has sensible defaults in the absence of a protocol negotiation, which is just as well as a lot of modern software gets confused if you send the TELNET escape code even though the protocol requires it. (FTP clients are particularly shoddy in this regard, as most of them think it's a weird kind of HTTP and get the framing wrong on edge cases such as strings containing NUL and CR characters, and if they were really phoning it in, SP and/or '+'.) Only heavyweight and/or high-performance daemons need to roll everything by hand. I did a funky whois server in Perl many moons ago for fun, but it was quite unnecessary to do so and inetd would have been quite up to the load. > and of course (B) this has to be linked to someone's API key, although we > could simply release the code and have everyone run their own little > gateway. The latter would seem to be the best approach, and of course if you're using inetd, tcpwrappers deals with the access-control issues. > So, it's both simple and not simple. Maybe another language ( perl comes > to mind - NetServer:Generic ) would be better suited to run a telnet > server. And I see NetServer::Generic was written by Charles Stross! However, what with him having been distracted by a writing career resulting in dozens of rather good books, it's not been maintained since 2000, and I see no indication that it actually speaks TELNET protocol either. From what I vaguely recall of Charlie's work in the 1990s dotcom boom, the thing he would have written this for was machine-to-machine communication which didn't involve TELNET. These days, Perl users would probably reach for the more modern Net::Server or one of its subclasses, or just glom a REPL onto inetd. --===============3587335228067541662==-- From brain@jbrain.com Tue Feb 7 14:50:46 2023 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 08:50:10 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1927091692934364034==" --===============1927091692934364034== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/7/2023 8:47 AM, Peter Corlett via cctalk wrote: > On Tue, Feb 07, 2023 at 12:27:33PM +0100, Cedric Amand via cctalk wrote: >> I've looked at the problem a bit, there are two issues to solve at first >> glance ; (A) there doesn't seem to be a telnet server library in python, >> so whatever you do you have to write your own telnet server, which is a >> bit more than just handling the sockets and newlines > You're overthinking this. Go old-school and write it as a regular REPL > command which is spawned from inetd. You don't actually need to implement > TELNET protocol for this as any sane telnet(1) client has sensible > defaults > in the absence of a protocol negotiation, which is just as well as a > lot of > modern software gets confused if you send the TELNET escape code even > though > the protocol requires it. (FTP clients are particularly shoddy in this > regard, as most of them think it's a weird kind of HTTP and get the > framing > wrong on edge cases such as strings containing NUL and CR characters, > and if > they were really phoning it in, SP and/or '+'.) > > Only heavyweight and/or high-performance daemons need to roll > everything by > hand. I did a funky whois server in Perl many moons ago for fun, but > it was > quite unnecessary to do so and inetd would have been quite up to the load. > >> and of course (B) this has to be linked to someone's API key, although we >> could simply release the code and have everyone run their own little >> gateway. > The latter would seem to be the best approach, and of course if you're > using > inetd, tcpwrappers deals with the access-control issues. > >> So, it's both simple and not simple. Maybe another language ( perl comes >> to mind - NetServer:Generic ) would be better suited to run a telnet >> server. > And I see NetServer::Generic was written by Charles Stross! However, what > with him having been distracted by a writing career resulting in dozens of > rather good books, it's not been maintained since 2000, and I see no > indication that it actually speaks TELNET protocol either. From what I > vaguely recall of Charlie's work in the 1990s dotcom boom, the thing he > would have written this for was machine-to-machine communication which > didn't involve TELNET. > > These days, Perl users would probably reach for the more modern > Net::Server > or one of its subclasses, or just glom a REPL onto inetd. > If you can get it telnet accessible, tcpser (shameless plug) can be used to expose it as a "Hayes(tm)" modem-reachable service. Jim -- Jim Brain brain(a)jbrain.com www.jbrain.com --===============1927091692934364034==-- From lars@nocrew.org Tue Feb 7 17:26:32 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Making sense of VAXstation 100 ROMs Date: Tue, 07 Feb 2023 17:25:51 +0000 Message-ID: <7w4jrx75gg.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1290119270647354524==" --===============1290119270647354524== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, I could use some help making sense of the VAXstation ROM images. A set is provided here: https://www.9track.net/roms/ The two .bin files are each one halfword of a 16-bit wide ROM for the 68000 display processor. I checked it, and it's fine. My problem is with the Bit Blit Accelator. The board has four Am2901 bitslice processors to make up a 16-bit custom blitter. The information I have is that the microcode is 57 bits wide and there should be 1024 words. However, this is not a great match for the rest of the ROM images. Some of the BBA ROMs seem to be bit masks, presumably useful for rendering graphics. But none of them seem to match what I'd expect to see for a 57x1024 microcode. Here are the sizes, in bits, of the ROMs: Bit Blit Accelerator (BBA) 23-066K3.jed 2048 23-067K3.jed 2048 23-068K3.jed 2048 23-069K3.jed 2048 23-076F4.e32 16384 23-077F4.e65 16384 23-077J5.jed 2048 23-078J5.jed 2048 23-354A1.e33 256 23-355A1.e66 256 23-356A1.e77 256 23-357A1.e85 256 Display Processor Module (DPM) 23-020L1.jed 3553 23-021L1.jed 3553 23-022L1.jed 3553 23-023L1.jed 3553 23-024L1.jed 3553 23-025L1.jed 3553 23-288E4.bin 65536 68000 code in these two. 23-289E4.bin 65536 --===============1290119270647354524==-- From paulkoning@comcast.net Tue Feb 7 17:33:36 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Making sense of VAXstation 100 ROMs Date: Tue, 07 Feb 2023 12:32:33 -0500 Message-ID: In-Reply-To: <7w4jrx75gg.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5606887217914324389==" --===============5606887217914324389== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Given 16 bit wide ROMs, I would expect the microcode width to be rounded up t= o a multiple of that, so 64 bits, which means the expected ROM size is 64k bi= ts. That matches two of the ROMs you mentioned. paul > On Feb 7, 2023, at 12:25 PM, Lars Brinkhoff via cctalk wrote: >=20 > Hello, >=20 > I could use some help making sense of the VAXstation ROM images. > A set is provided here: https://www.9track.net/roms/ >=20 > The two .bin files are each one halfword of a 16-bit wide ROM for the > 68000 display processor. I checked it, and it's fine. >=20 > My problem is with the Bit Blit Accelator. The board has four Am2901 > bitslice processors to make up a 16-bit custom blitter. The information > I have is that the microcode is 57 bits wide and there should be 1024 > words. However, this is not a great match for the rest of the ROM > images. >=20 > Some of the BBA ROMs seem to be bit masks, presumably useful for > rendering graphics. But none of them seem to match what I'd expect to > see for a 57x1024 microcode. >=20 > Here are the sizes, in bits, of the ROMs: >=20 > Bit Blit Accelerator (BBA) > 23-066K3.jed 2048 > 23-067K3.jed 2048 > 23-068K3.jed 2048 > 23-069K3.jed 2048 > 23-076F4.e32 16384 > 23-077F4.e65 16384 > 23-077J5.jed 2048 > 23-078J5.jed 2048 > 23-354A1.e33 256 > 23-355A1.e66 256 > 23-356A1.e77 256 > 23-357A1.e85 256 >=20 > Display Processor Module (DPM) > 23-020L1.jed 3553 > 23-021L1.jed 3553 > 23-022L1.jed 3553 > 23-023L1.jed 3553 > 23-024L1.jed 3553 > 23-025L1.jed 3553 > 23-288E4.bin 65536 68000 code in these two. > 23-289E4.bin 65536 =20 --===============5606887217914324389==-- From mooreericnyc@gmail.com Tue Feb 7 18:06:59 2023 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Re: 3/16ths inch ink ribbon Date: Tue, 07 Feb 2023 12:06:12 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0507733389023127732==" --===============0507733389023127732== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The ribbon was well inked, and the keypunch is printing beautifully, thank you! -Eric On Sun, Jan 29, 2023, 6:47 PM Eric Moore wrote: > Thank you! I will let you guys know if it works out :) > > On Sun, Jan 29, 2023, 5:36 PM Chuck Guzis via cctalk < > cctalk(a)classiccmp.org> wrote: > >> On 1/29/23 15:19, Eric Moore via cctalk wrote: >> > Hello, I am looking for 3/16ths inch ink ribbon as used on the IBM 029 >> > keypunch. >> > >> > I have one lightly damaged ribbon that is entirely dry. I was told by a >> > typewriter restorationist that ribbon re-inking with nylon never works. >> > >> > Has anyone had much success cleaning and rewetting ink ribbons? The WD40 >> > trick on the internet seems like it would gunk up the punch mechanism. >> > >> > Thanks for any information yall can provide, >> >> >> https://www.aroundtheoffice.com/IBM-026-Keypunch-Ribbon/productinfo/RP-520= -IBM/ >> >> --Chuck >> >> >> --===============0507733389023127732==-- From paulkoning@comcast.net Tue Feb 7 18:12:38 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: 3/16ths inch ink ribbon Date: Tue, 07 Feb 2023 13:11:35 -0500 Message-ID: <8BE9ED1D-B592-46FE-815E-5AE17C1D9BBB@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4117187631132213335==" --===============4117187631132213335== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Wow. Now I know where to get ribbons for my old DEC printer if I want to use= it again. Thanks all! paul > On Feb 7, 2023, at 1:06 PM, Eric Moore via cctalk = wrote: >=20 > The ribbon was well inked, and the keypunch is printing beautifully, thank > you! >=20 > -Eric >=20 >> On Sun, Jan 29, 2023, 5:36 PM Chuck Guzis via cctalk < >> cctalk(a)classiccmp.org> wrote: >>=20 >>> https://www.aroundtheoffice.com/IBM-026-Keypunch-Ribbon/productinfo/RP-52= 0-IBM/ >>>=20 >>> --Chuck >>>=20 >>>=20 >>>=20 --===============4117187631132213335==-- From cisin@xenosoft.com Tue Feb 7 19:06:30 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Tue, 07 Feb 2023 11:05:53 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7591141875536939460==" --===============7591141875536939460== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit How does ChatGPT say to do it? --===============7591141875536939460==-- From g4ajq1@gmail.com Tue Feb 7 22:45:07 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] TK50/70 Repair Date: Tue, 07 Feb 2023 17:44:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1994508462603118088==" --===============1994508462603118088== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Fellow cyber-antiquarians: I have been fussing around with a TK70 for some hours now. It goes ready when powered up without  a cartridge, takes up the leader fine when a cartridge put in and the flat, but then dithers forwards and backwards, eventually flashing all its lights.  The only way to remove the tape is manually. Somebody posted that the most common problem is optical sensors, stating that there are four.  I have only found two, and cleaning them got me to the point of it coming ready, whereas it would not before. Is there anybody on here that knows of a service manual?  I see that this was considered an FRU, so maybe depot repair people had a magic bible. Once I have this fixed there is a TK50 to start on.  I hate to give up! I have a box full of cartridges to read! cheers, Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============1994508462603118088==-- From cz@alembic.crystel.com Wed Feb 8 03:55:15 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Tue, 07 Feb 2023 22:54:34 -0500 Message-ID: <5b134ed3-f3be-0ac5-75ed-4803c28ab76c@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4385553577167279904==" --===============4385553577167279904== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Nigel! I have a fair bit of experience with TK's, including the TK50 and 70. I like them, they're quick units (with the TQK70 controller they can stream well), and they look really nice in a BA23 chassis. Optical sensors can be dirty, but the biggest problem I have seen is in the capstains: They are mounted on springs and the biggest issue is that the oil in the bearings is probably long gone. As a result, they tend to drag on the tape and not spin properly. This in and of itself is enough of an issue, but the rear one also has an optical tachometer on it, and the unit uses that to maintain tension on the tape and know (along with the tach sensors on the drive and take up spindle) what the tape is doing at any given time. Thus if that one drags you have a major problem that can include the tape doing a massive unspool on the take up reel. How to fix. Well you need to take the capstains off and either lubricate both the top and bottom bearings so they spin easily and go up and down against the springs or replace the bearings with new press in ones. I've taken the lubricating route and the oil will last for about 3 years if you use good mobius watch oil on the insides and outside races of the bearings. Taking them off requires care: The nuts are adjusted at the factory so the slew is correct across the tape head and the pulleys are at the right height for the cartridge and take up reels. Wrong height and hilarity ensues. So what I recommend is to mark a nut face, know exactly where it is, and when you take off the nut count the number of turns and mark the unit at the point where the nut comes off the shaft. Keep each nut separate (or do the capstains one at a time) and when reassembling go the exact amount of turns to the exact spot as measured by your marks. Then you'll be back at the same place. Note also the rear capstain comes off the unit if you want to check the optical sensor. I recommend using a very tiny bearing/gear puller to put pressure on the shaft as the fingers lift the capstain off the shaft (esp if it's stuck) so you don't pull and damage the optical wheel at the bottom. Front one is easier, back one is tricky and has more of a friction fit to the wheel. Take it easy and take your time. For tapes I like to lift the head up with the springs attached and inspect it. Clean it with isopropyl and make sure there is no oxide on it, that will cause the unit to fail. Then when dry load a tape, run it a bit, then unload and check the head. If you see fresh oxide chuck the tape (or bake it if you really care) but know that tape will contaminate other tapes if you don't clean the head each time. If the tape doesn't damage the head mark it as "safe" and use it, but always check a new tape. Some shed, some don't. It's weird. Oh also make sure to have the metal shield on when testing it. The shield does help keep tape from going everywhere in the event of a major fail, but it also darkens those rear optical sensors so they don't false trigger and drive the unit insane. And by insane I mean doesn't load or suddenly stops the take up reel with hilarious results. Good luck and let us know how it works out! C On 2/7/2023 5:44 PM, Nigel Johnson Ham via cctalk wrote: > Fellow cyber-antiquarians: > > I have been fussing around with a TK70 for some hours now. It goes ready > when powered up without  a cartridge, takes up the leader fine when a > cartridge put in and the flat, but then dithers forwards and backwards, > eventually flashing all its lights.  The only way to remove the tape is > manually. > > Somebody posted that the most common problem is optical sensors, stating > that there are four.  I have only found two, and cleaning them got me to > the point of it coming ready, whereas it would not before. > > Is there anybody on here that knows of a service manual?  I see that > this was considered an FRU, so maybe depot repair people had a magic bible. > > Once I have this fixed there is a TK50 to start on.  I hate to give up! > I have a box full of cartridges to read! > > cheers, > > Nigel > > > --===============4385553577167279904==-- From g4ajq1@gmail.com Wed Feb 8 04:02:40 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Tue, 07 Feb 2023 23:02:01 -0500 Message-ID: <35151def-36fd-ae18-7096-5f49f5506735@gmail.com> In-Reply-To: <5b134ed3-f3be-0ac5-75ed-4803c28ab76c@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6653258850852826272==" --===============6653258850852826272== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2023-02-07 22:54, Chris Zach via cctalk wrote: > Hi Nigel! > > I have a fair bit of experience with TK's, including the TK50 and 70. > I like them, they're quick units (with the TQK70 controller they can > stream well), and they look really nice in a BA23 chassis. > > Optical sensors can be dirty, but the biggest problem I have seen is > in the capstains: They are mounted on springs and the biggest issue is > that the oil in the bearings is probably long gone. As a result, they > tend to drag on the tape and not spin properly. > > This in and of itself is enough of an issue, but the rear one also has > an optical tachometer on it, and the unit uses that to maintain > tension on the tape and know (along with the tach sensors on the drive > and take up spindle) what the tape is doing at any given time. Thus if > that one drags you have a major problem that can include the tape > doing a massive unspool on the take up reel. > > How to fix. Well you need to take the capstains off and either > lubricate both the top and bottom bearings so they spin easily and go > up and down against the springs or replace the bearings with new press > in ones. I've taken the lubricating route and the oil will last for > about 3 years if you use good mobius watch oil on the insides and > outside races of the bearings. > > Taking them off requires care: The nuts are adjusted at the factory so > the slew is correct across the tape head and the pulleys are at the > right height for the cartridge and take up reels. Wrong height and > hilarity ensues. So what I recommend is to mark a nut face, know > exactly where it is, and when you take off the nut count the number of > turns and mark the unit at the point where the nut comes off the > shaft. Keep each nut separate (or do the capstains one at a time) and > when reassembling go the exact amount of turns to the exact spot as > measured by your marks. Then you'll be back at the same place. > > Note also the rear capstain comes off the unit if you want to check > the optical sensor. I recommend using a very tiny bearing/gear puller > to put pressure on the shaft as the fingers lift the capstain off the > shaft (esp if it's stuck) so you don't pull and damage the optical > wheel at the bottom. Front one is easier, back one is tricky and has > more of a friction fit to the wheel. Take it easy and take your time. > > For tapes I like to lift the head up with the springs attached and > inspect it. Clean it with isopropyl and make sure there is no oxide on > it, that will cause the unit to fail. Then when dry load a tape, run > it a bit, then unload and check the head. If you see fresh oxide chuck > the tape (or bake it if you really care) but know that tape will > contaminate other tapes if you don't clean the head each time. If the > tape doesn't damage the head mark it as "safe" and use it, but always > check a new tape. Some shed, some don't. It's weird. > > Oh also make sure to have the metal shield on when testing it. The > shield does help keep tape from going everywhere in the event of a > major fail, but it also darkens those rear optical sensors so they > don't false trigger and drive the unit insane. And by insane I mean > doesn't load or suddenly stops the take up reel with hilarious results. > > Good luck and let us know how it works out! > C > > On 2/7/2023 5:44 PM, Nigel Johnson Ham via cctalk wrote: >> Fellow cyber-antiquarians: >> >> I have been fussing around with a TK70 for some hours now. It goes >> ready when powered up without  a cartridge, takes up the leader fine >> when a cartridge put in and the flat, but then dithers forwards and >> backwards, eventually flashing all its lights.  The only way to >> remove the tape is manually. >> >> Somebody posted that the most common problem is optical sensors, >> stating that there are four.  I have only found two, and cleaning >> them got me to the point of it coming ready, whereas it would not >> before. >> >> Is there anybody on here that knows of a service manual?  I see that >> this was considered an FRU, so maybe depot repair people had a magic >> bible. >> >> Once I have this fixed there is a TK50 to start on.  I hate to give >> up! I have a box full of cartridges to read! >> >> cheers, >> >> Nigel >> >> >> Brilliant, thanks, Chris. I might just undertake that tomorrow instead of doing an RT11 sysgen! Just the kind of advice I need. I sure will let you know! Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============6653258850852826272==-- From lars@nocrew.org Wed Feb 8 05:31:37 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: Making sense of VAXstation 100 ROMs Date: Wed, 08 Feb 2023 05:30:59 +0000 Message-ID: <7wy1p867vw.fsf@junk.nocrew.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8536583307189602122==" --===============8536583307189602122== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Paul Koning wrote: > Given 16 bit wide ROMs, I would expect the microcode width to be > rounded up to a multiple of that, so 64 bits, which means the expected > ROM size is 64k bits. That matches two of the ROMs you mentioned. I don't know if they are 16 bits wide. The two 68000 ROMs are 8 bit wide. The others I have no data on. Also, there aren't enough bits on the BBA board ROMs to make up 56x1024. (I was wrong in my previous post, the microcode is 56 bits wide, not 57.) Besides, the contents doesn't look like code but graphics masks. --===============8536583307189602122==-- From mooreericnyc@gmail.com Wed Feb 8 14:30:49 2023 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Punched Card Reader Date: Wed, 08 Feb 2023 08:29:58 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0162732235804122697==" --===============0162732235804122697== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, I recently got my IBM 029 keypunch working, and am expanding the search for a punched card reader. Ideally RS-232, but unknown protocol or parallel is fine also. Repair required is also fine :). Thanks for any help! -Eric --===============0162732235804122697==-- From g4ajq1@gmail.com Wed Feb 8 15:07:31 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Wed, 08 Feb 2023 10:06:50 -0500 Message-ID: In-Reply-To: <5b134ed3-f3be-0ac5-75ed-4803c28ab76c@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2219813494387741232==" --===============2219813494387741232== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Well, I found dust and what looks like oil on the optical wheel.  It looks like somebody may have tried to lube the bearings in situ and used too much oil :-( I'm amused to see that it uses the same moiré principle that was used way back in the RK05! Do you know if the pattern on the wheel is purely cut out, or is there any photographic film involved?  I think the only possible solution would be to clean it with isopropyl, but useless to do that if it is film. thanks for your help, Nigel On 2023-02-07 22:54, Chris Zach via cctalk wrote: > Hi Nigel! > > I have a fair bit of experience with TK's, including the TK50 and 70. > I like them, they're quick units (with the TQK70 controller they can > stream well), and they look really nice in a BA23 chassis. > > Optical sensors can be dirty, but the biggest problem I have seen is > in the capstains: They are mounted on springs and the biggest issue is > that the oil in the bearings is probably long gone. As a result, they > tend to drag on the tape and not spin properly. > > This in and of itself is enough of an issue, but the rear one also has > an optical tachometer on it, and the unit uses that to maintain > tension on the tape and know (along with the tach sensors on the drive > and take up spindle) what the tape is doing at any given time. Thus if > that one drags you have a major problem that can include the tape > doing a massive unspool on the take up reel. > > How to fix. Well you need to take the capstains off and either > lubricate both the top and bottom bearings so they spin easily and go > up and down against the springs or replace the bearings with new press > in ones. I've taken the lubricating route and the oil will last for > about 3 years if you use good mobius watch oil on the insides and > outside races of the bearings. > > Taking them off requires care: The nuts are adjusted at the factory so > the slew is correct across the tape head and the pulleys are at the > right height for the cartridge and take up reels. Wrong height and > hilarity ensues. So what I recommend is to mark a nut face, know > exactly where it is, and when you take off the nut count the number of > turns and mark the unit at the point where the nut comes off the > shaft. Keep each nut separate (or do the capstains one at a time) and > when reassembling go the exact amount of turns to the exact spot as > measured by your marks. Then you'll be back at the same place. > > Note also the rear capstain comes off the unit if you want to check > the optical sensor. I recommend using a very tiny bearing/gear puller > to put pressure on the shaft as the fingers lift the capstain off the > shaft (esp if it's stuck) so you don't pull and damage the optical > wheel at the bottom. Front one is easier, back one is tricky and has > more of a friction fit to the wheel. Take it easy and take your time. > > For tapes I like to lift the head up with the springs attached and > inspect it. Clean it with isopropyl and make sure there is no oxide on > it, that will cause the unit to fail. Then when dry load a tape, run > it a bit, then unload and check the head. If you see fresh oxide chuck > the tape (or bake it if you really care) but know that tape will > contaminate other tapes if you don't clean the head each time. If the > tape doesn't damage the head mark it as "safe" and use it, but always > check a new tape. Some shed, some don't. It's weird. > > Oh also make sure to have the metal shield on when testing it. The > shield does help keep tape from going everywhere in the event of a > major fail, but it also darkens those rear optical sensors so they > don't false trigger and drive the unit insane. And by insane I mean > doesn't load or suddenly stops the take up reel with hilarious results. > > Good luck and let us know how it works out! > C > > On 2/7/2023 5:44 PM, Nigel Johnson Ham via cctalk wrote: >> Fellow cyber-antiquarians: >> >> I have been fussing around with a TK70 for some hours now. It goes >> ready when powered up without  a cartridge, takes up the leader fine >> when a cartridge put in and the flat, but then dithers forwards and >> backwards, eventually flashing all its lights.  The only way to >> remove the tape is manually. >> >> Somebody posted that the most common problem is optical sensors, >> stating that there are four.  I have only found two, and cleaning >> them got me to the point of it coming ready, whereas it would not >> before. >> >> Is there anybody on here that knows of a service manual?  I see that >> this was considered an FRU, so maybe depot repair people had a magic >> bible. >> >> Once I have this fixed there is a TK50 to start on.  I hate to give >> up! I have a box full of cartridges to read! >> >> cheers, >> >> Nigel >> >> >> -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============2219813494387741232==-- From healyzh@avanthar.com Wed Feb 8 19:45:49 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] SDF had put a PDP-10 on the Internet Date: Wed, 08 Feb 2023 11:45:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8341432471744577964==" --===============8341432471744577964== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Specifically it looks like a SC-40. https://twitter.com/sdf_pubnix/status/1623127551542702080 Zane --===============8341432471744577964==-- From sellam.ismail@gmail.com Wed Feb 8 19:55:33 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Wed, 08 Feb 2023 11:54:42 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0618428554355367868==" --===============0618428554355367868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable "A new PDP-10 has been put in the INTERNET." "New" as in newly-built? Or "new" as in wasn't there before? The hardware looks modern, and not at all like what a PDP-10 should look like. Sellam On Wed, Feb 8, 2023 at 11:45 AM Zane Healy via cctalk wrote: > Specifically it looks like a SC-40. > > https://twitter.com/sdf_pubnix/status/1623127551542702080 < > https://twitter.com/sdf_pubnix/status/1623127551542702080> > > Zane > --===============0618428554355367868==-- From jakeutley@outlook.com Wed Feb 8 20:12:02 2023 From: jake utley To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Wed, 08 Feb 2023 20:11:24 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8884028927086302868==" --===============8884028927086302868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I would say it is newly built as the pcb substrate looks nothing like vintage= stock. On first glance it=E2=80=99s a impressive achievement reverse enginee= ring the PDP10 cards and then getting it online=20 Jake > On 8 Feb 2023, at 19:55, Sellam Abraham via cctalk wrote: >=20 > =EF=BB=BF"A new PDP-10 has been put in the INTERNET." >=20 > "New" as in newly-built? Or "new" as in wasn't there before? >=20 > The hardware looks modern, and not at all like what a PDP-10 should look > like. >=20 > Sellam >=20 >> On Wed, Feb 8, 2023 at 11:45 AM Zane Healy via cctalk >> wrote: >>=20 >> Specifically it looks like a SC-40. >>=20 >> https://twitter.com/sdf_pubnix/status/1623127551542702080 < >> https://twitter.com/sdf_pubnix/status/1623127551542702080> >>=20 >> Zane >>=20 --===============8884028927086302868==-- From lars@nocrew.org Wed Feb 8 21:21:16 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Wed, 08 Feb 2023 21:20:33 +0000 Message-ID: <7wilgb6ehq.fsf@junk.nocrew.org> In-Reply-To: =?utf-8?q?=3CLO2P123MB3998761B0EA8E633BA414461A8D89=40LO2P123MB?= =?utf-8?q?3998=2EGBRP123=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5056871965530766028==" --===============5056871965530766028== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Jake Utley wrote: > Sellam Abraham >> "A new PDP-10 has been put in the INTERNET." >> "New" as in newly-built? Or "new" as in wasn't there before? >> The hardware looks modern, and not at all like what a PDP-10 should look >> like. > > I would say it is newly built as the pcb substrate looks nothing like > vintage stock. On first glance it’s a impressive achievement reverse > engineering the PDP10 cards and then getting it online It's "new" as in "it wasn't there last week". Well, it's also somewhat new since it was made in the 90s. It's not a DEC PDP-10, but a clone by Systems Concepts. --===============5056871965530766028==-- From chris@mainecoon.com Wed Feb 8 21:45:53 2023 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Wed, 08 Feb 2023 13:37:02 -0800 Message-ID: <478c0b50-d86d-069c-370a-e54727e0dd09@mainecoon.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6810926118685106367==" --===============6810926118685106367== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/8/23 11:45, Zane Healy via cctalk wrote: > Specifically it looks like a SC-40. > > https://twitter.com/sdf_pubnix/status/1623127551542702080 So it claims when you talk to it :)=C2=A0 That makes it a 1993-ish machine. --=20 Christian Kennedy, Ph.D. chris(a)mainecoon.com AF6AP | DB00000692 | PG00029419 http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration=E2=80=A6" --===============6810926118685106367==-- From wrcooke@wrcooke.net Thu Feb 9 03:17:48 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Store with "vintage" computers and parts Date: Wed, 08 Feb 2023 21:17:12 -0600 Message-ID: <506048622.361262.1675912632515@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6866470011843661511==" --===============6866470011843661511== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This place may be of interest. Most of the stuff they have for sale probably= isn't of much interest here, but there are a few gems. The link takes you t= o one, which is how I found it. https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-rare= -738148146177114113.html Not affiliated in any way. Just thought it might be of interest. Will --===============6866470011843661511==-- From glen.slick@gmail.com Thu Feb 9 03:48:09 2023 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Wed, 08 Feb 2023 19:47:18 -0800 Message-ID: In-Reply-To: <506048622.361262.1675912632515@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3676338605899813526==" --===============3676338605899813526== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 8, 2023 at 7:17 PM Will Cooke via cctalk wrote: > > This place may be of interest. Most of the stuff they have for sale probab= ly isn't of much interest here, but there are a few gems. The link takes you= to one, which is how I found it. > https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-ra= re-738148146177114113.html > Very skeptical that this site is legitimate. "Free Shipping & Returns: Free Shipping for all orders. Free Return" Uh, no way, no how. Reviews are just some Lorem Ipsum text. 1 Review For Chaz Kangeroo Hoodies Admin - 30 Nov, 2018 Aliquam fringilla euismod risus ac bibendum. Sed sit amet sem varius ante feugiat lacinia. Nunc ipsum nulla, vulputate ut venenatis vitae, malesuada ut mi. Quisque iaculis, dui congue placerat pretium, augue erat accumsan lacus --===============3676338605899813526==-- From shumaker@att.net Thu Feb 9 04:21:41 2023 From: Steven Shumaker To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Wed, 08 Feb 2023 20:20:56 -0800 Message-ID: <24fd109d-c00f-6232-b4c4-7bd82721748a@att.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7388964861515340180==" --===============7388964861515340180== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable interesting!=C2=A0 Some of the items looked really familiar so I did some=20 quoted text searches on EPay.=C2=A0=C2=A0 They were exact matches for some hi= ghly=20 unique listings.... who is scamming who here....... Steve On 2/8/2023 7:47 PM, Glen Slick via cctalk wrote: > On Wed, Feb 8, 2023 at 7:17 PM Will Cooke via cctalk > wrote: >> This place may be of interest. Most of the stuff they have for sale proba= bly isn't of much interest here, but there are a few gems. The link takes yo= u to one, which is how I found it. >> https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-r= are-738148146177114113.html >> > Very skeptical that this site is legitimate. > > "Free Shipping & Returns: Free Shipping for all orders. Free Return" > Uh, no way, no how. > > Reviews are just some Lorem Ipsum text. > > 1 Review For Chaz Kangeroo Hoodies > Admin - 30 Nov, 2018 > Aliquam fringilla euismod risus ac bibendum. Sed sit amet sem varius > ante feugiat lacinia. Nunc ipsum nulla, vulputate ut venenatis vitae, > malesuada ut mi. Quisque iaculis, dui congue placerat pretium, augue > erat accumsan lacus --===============7388964861515340180==-- From kl@2k.ca Thu Feb 9 05:18:25 2023 From: Kevin Lee To: cctalk@classiccmp.org Subject: [cctalk] Trs80 model 200 for sale Date: Thu, 09 Feb 2023 06:11:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2677425606037335736==" --===============2677425606037335736== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Radio Shack trs80 Model 200 With an option rom. Works ok. Decent shape. Offers welcome. Shipping from central EU. Cheers K. --===============2677425606037335736==-- From sellam.ismail@gmail.com Thu Feb 9 06:59:38 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Wed, 08 Feb 2023 22:58:49 -0800 Message-ID: In-Reply-To: <24fd109d-c00f-6232-b4c4-7bd82721748a@att.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4147910851417405773==" --===============4147910851417405773== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This is an item I had listed on eBay for a couple years, and which sold on eBay a few months ago =3D=3D> https://www.bryanipad.shop/product/dsp-225-tempest-ink-jet-printer-hp-2225a-t= hinkjet-in-rf-shielded-enclosure-737796124001173505.html The photos and description are mine, from my eBay ad. This is definitely a scam. Sellam On Wed, Feb 8, 2023 at 8:21 PM Steven Shumaker via cctalk < cctalk(a)classiccmp.org> wrote: > interesting! Some of the items looked really familiar so I did some > quoted text searches on EPay. They were exact matches for some highly > unique listings.... > > who is scamming who here....... > > Steve > > > > On 2/8/2023 7:47 PM, Glen Slick via cctalk wrote: > > On Wed, Feb 8, 2023 at 7:17 PM Will Cooke via cctalk > > wrote: > >> This place may be of interest. Most of the stuff they have for sale > probably isn't of much interest here, but there are a few gems. The link > takes you to one, which is how I found it. > >> > https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-ra= re-738148146177114113.html > >> > > Very skeptical that this site is legitimate. > > > > "Free Shipping & Returns: Free Shipping for all orders. Free Return" > > Uh, no way, no how. > > > > Reviews are just some Lorem Ipsum text. > > > > 1 Review For Chaz Kangeroo Hoodies > > Admin - 30 Nov, 2018 > > Aliquam fringilla euismod risus ac bibendum. Sed sit amet sem varius > > ante feugiat lacinia. Nunc ipsum nulla, vulputate ut venenatis vitae, > > malesuada ut mi. Quisque iaculis, dui congue placerat pretium, augue > > erat accumsan lacus > --===============4147910851417405773==-- From ccth6600@gmail.com Thu Feb 9 08:04:17 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 16:03:18 +0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0932531267264442886==" --===============0932531267264442886== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Avast claims the site is infected with a trojan. The contact address does not exist: 4144 Fannie Street Houston, Texas 77063 United States Stay away! On Thu, Feb 9, 2023 at 2:59 PM Sellam Abraham via cctalk < cctalk(a)classiccmp.org> wrote: > This is an item I had listed on eBay for a couple years, and which sold on > eBay a few months ago =3D=3D> > > https://www.bryanipad.shop/product/dsp-225-tempest-ink-jet-printer-hp-2225a= -thinkjet-in-rf-shielded-enclosure-737796124001173505.html > > The photos and description are mine, from my eBay ad. > > This is definitely a scam. > > Sellam > > On Wed, Feb 8, 2023 at 8:21 PM Steven Shumaker via cctalk < > cctalk(a)classiccmp.org> wrote: > > > interesting! Some of the items looked really familiar so I did some > > quoted text searches on EPay. They were exact matches for some highly > > unique listings.... > > > > who is scamming who here....... > > > > Steve > > > > > > > > On 2/8/2023 7:47 PM, Glen Slick via cctalk wrote: > > > On Wed, Feb 8, 2023 at 7:17 PM Will Cooke via cctalk > > > wrote: > > >> This place may be of interest. Most of the stuff they have for sale > > probably isn't of much interest here, but there are a few gems. The link > > takes you to one, which is how I found it. > > >> > > > https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-ra= re-738148146177114113.html > > >> > > > Very skeptical that this site is legitimate. > > > > > > "Free Shipping & Returns: Free Shipping for all orders. Free Return" > > > Uh, no way, no how. > > > > > > Reviews are just some Lorem Ipsum text. > > > > > > 1 Review For Chaz Kangeroo Hoodies > > > Admin - 30 Nov, 2018 > > > Aliquam fringilla euismod risus ac bibendum. Sed sit amet sem varius > > > ante feugiat lacinia. Nunc ipsum nulla, vulputate ut venenatis vitae, > > > malesuada ut mi. Quisque iaculis, dui congue placerat pretium, augue > > > erat accumsan lacus > > > --===============0932531267264442886==-- From cc@informatik.uni-stuttgart.de Thu Feb 9 08:20:25 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Thu, 09 Feb 2023 09:19:43 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0120090614493127409==" --===============0120090614493127409== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 8 Feb 2023, Zane Healy wrote: > Specifically it looks like a SC-40. > https://twitter.com/sdf_pubnix/status/1623127551542702080 Interesting, but not really a beauty ;-) And BTW, who is SDF? They don't tell it on their site. Christian --===============0120090614493127409==-- From mhuffstutter@outlook.com Thu Feb 9 08:36:53 2023 From: Mark Huffstutter To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Thu, 09 Feb 2023 08:36:12 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0772036950628197529==" --===============0772036950628197529== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Short story on the welcome page. Mark -----Original Message----- From: Christian Corti via cctalk =20 Sent: Thursday, February 9, 2023 12:20 AM To: Zane Healy via cctalk Cc: Christian Corti Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet On Wed, 8 Feb 2023, Zane Healy wrote: > Specifically it looks like a SC-40. > https://twitter.com/sdf_pubnix/status/1623127551542702080=20 > Interesting, but not really a beauty ;-) And BTW, who is SDF? They don't tell= it on their site. Christian --===============0772036950628197529==-- From lars@nocrew.org Thu Feb 9 08:56:26 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Thu, 09 Feb 2023 08:55:48 +0000 Message-ID: <7w7cwr5iaz.fsf@junk.nocrew.org> In-Reply-To: =?utf-8?q?=3CDM6PR06MB626727D0E4815FF9A98ABF55C9D99=40DM6PR06MB?= =?utf-8?q?6267=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5334086062480628989==" --===============5334086062480628989== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Mark Huffstutter via cctalk writes: > Christian Corti wrote: >> Interesting, but not really a beauty ;-) And BTW, who is SDF? They >> don't tell it on their site. > Short story on the welcome page. Long story: https://archive.org/details/bbs-20030526-sdf --===============5334086062480628989==-- From cz@beaker.crystel.com Thu Feb 9 09:34:36 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Wed, 08 Feb 2023 10:49:15 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7517659494643844328==" --===============7517659494643844328== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I think it's metal, but using a bit of good old soapy water and a rinse/dry should be fine. Remember that there is a little window screen part there to ensure the optical system only sees the slit right under it, don't forget to install it as well. Glad to hear there is progress. Let us know how it works out! C On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: > Well, I found dust and what looks like oil on the optical wheel.  It > looks like somebody may have tried to lube the bearings in situ and used > too much oil :-( > > I'm amused to see that it uses the same moiré principle that was used > way back in the RK05! > > Do you know if the pattern on the wheel is purely cut out, or is there > any photographic film involved?  I think the only possible solution > would be to clean it with isopropyl, but useless to do that if it is film. --===============7517659494643844328==-- From wrcooke@wrcooke.net Thu Feb 9 10:23:08 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 04:22:28 -0600 Message-ID: <1485881511.12168.1675938148947@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1207876222142620426==" --===============1207876222142620426== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ouch! Thanks to everyone who spotted its a scam. Sorry for not checking closer before posting. Will > On 02/09/2023 2:03 AM CST Tom Hunter via cctalk w= rote: >=20 >=20 > Avast claims the site is infected with a trojan. > The contact address does not exist: 4144 Fannie Street Houston, Texas 77063 > United States > Stay away! >=20 > On Thu, Feb 9, 2023 at 2:59 PM Sellam Abraham via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 > > This is an item I had listed on eBay for a couple years, and which sold on > > eBay a few months ago =3D=3D> > > https://www.bryanipad.shop/product/dsp-225-tempest-ink-jet-printer-hp-222= 5a-thinkjet-in-rf-shielded-enclosure-737796124001173505.html > > The photos and description are mine, from my eBay ad. > > This is definitely a scam. > > Sellam > > On Wed, Feb 8, 2023 at 8:21 PM Steven Shumaker via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > interesting! Some of the items looked really familiar so I did some > > > quoted text searches on EPay. They were exact matches for some highly > > > unique listings.... > > > who is scamming who here....... > > > Steve > > > > > > > > > On 2/8/2023 7:47 PM, Glen Slick via cctalk wrote: > > > > On Wed, Feb 8, 2023 at 7:17 PM Will Cooke via cctalk > > > > wrote: > > > > > This place may be of interest. Most of the stuff they have for sale > > > probably isn't of much interest here, but there are a few gems. The link > > > takes you to one, which is how I found it. > > > >> > > https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-= rare-738148146177114113.html > > > > >=20 > > > > Very skeptical that this site is legitimate. > > > > "Free Shipping & Returns: Free Shipping for all orders. Free Return" > > > > Uh, no way, no how. > > > > Reviews are just some Lorem Ipsum text. > > > > 1 Review For Chaz Kangeroo Hoodies > > > > Admin - 30 Nov, 2018 > > > > Aliquam fringilla euismod risus ac bibendum. Sed sit amet sem varius > > > > ante feugiat lacinia. Nunc ipsum nulla, vulputate ut venenatis vitae, > > > > malesuada ut mi. Quisque iaculis, dui congue placerat pretium, augue > > > > erat accumsan lacus I do not think you can name many great inventions that have been made by marr= ied men. Nikola Tesla --===============1207876222142620426==-- From mooreericnyc@gmail.com Thu Feb 9 14:32:28 2023 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 08:31:35 -0600 Message-ID: In-Reply-To: <1485881511.12168.1675938148947@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2088128415612998430==" --===============2088128415612998430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There are some older folks on the list, so this is a good time to talk about internet safety. Please, if you see a website address like this: www.bryanipad.shop - DO NOT CLICK ON IT The address is very suspicious, as it does not seem like a very good website name, and ends in .shop, which valid shops in our hobby rarely if ever use. If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, if it does not show up in google results, or has a warning, it is almost certainly fraudulent. Stay safe out there :) -Eric On Thu, Feb 9, 2023 at 4:22 AM Will Cooke via cctalk wrote: > Ouch! > Thanks to everyone who spotted its a scam. > Sorry for not checking closer before posting. > Will > > > > On 02/09/2023 2:03 AM CST Tom Hunter via cctalk > wrote: > > > > > > Avast claims the site is infected with a trojan. > > The contact address does not exist: 4144 Fannie Street Houston, Texas > 77063 > > United States > > Stay away! > > > > On Thu, Feb 9, 2023 at 2:59 PM Sellam Abraham via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > > > This is an item I had listed on eBay for a couple years, and which > sold on > > > eBay a few months ago =3D=3D> > > > > https://www.bryanipad.shop/product/dsp-225-tempest-ink-jet-printer-hp-2225a= -thinkjet-in-rf-shielded-enclosure-737796124001173505.html > > > The photos and description are mine, from my eBay ad. > > > This is definitely a scam. > > > Sellam > > > On Wed, Feb 8, 2023 at 8:21 PM Steven Shumaker via cctalk < > > > cctalk(a)classiccmp.org> wrote: > > > > interesting! Some of the items looked really familiar so I did some > > > > quoted text searches on EPay. They were exact matches for some highly > > > > unique listings.... > > > > who is scamming who here....... > > > > Steve > > > > > > > > > > > > On 2/8/2023 7:47 PM, Glen Slick via cctalk wrote: > > > > > On Wed, Feb 8, 2023 at 7:17 PM Will Cooke via cctalk > > > > > wrote: > > > > > > This place may be of interest. Most of the stuff they have for > sale > > > > probably isn't of much interest here, but there are a few gems. The > link > > > > takes you to one, which is how I found it. > > > > >> > > > > https://www.bryanipad.shop/product/microlog-corporation-atr-6800-vintage-ra= re-738148146177114113.html > > > > > > > > > > > Very skeptical that this site is legitimate. > > > > > "Free Shipping & Returns: Free Shipping for all orders. Free > Return" > > > > > Uh, no way, no how. > > > > > Reviews are just some Lorem Ipsum text. > > > > > 1 Review For Chaz Kangeroo Hoodies > > > > > Admin - 30 Nov, 2018 > > > > > Aliquam fringilla euismod risus ac bibendum. Sed sit amet sem > varius > > > > > ante feugiat lacinia. Nunc ipsum nulla, vulputate ut venenatis > vitae, > > > > > malesuada ut mi. Quisque iaculis, dui congue placerat pretium, > augue > > > > > erat accumsan lacus > > I do not think you can name many great inventions that have been made by > married men. Nikola Tesla > --===============2088128415612998430==-- From stuff@riddermarkfarm.ca Thu Feb 9 14:53:11 2023 From: Stuff Received To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 09:44:58 -0500 Message-ID: <8bfd0c87-54f5-c885-8874-43f940b1c0ad@riddermarkfarm.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8550317573978117966==" --===============8550317573978117966== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-09 09:31, Eric Moore via cctalk wrote: > There are some older folks on the list, so this is a good time to talk > about internet safety. Having spent over 30y in cybersecurity, I suppose that I qualify. #6-) I am sure that this was not meant as a condescending insult but perhaps a different choice of words would have preferable. N. --===============8550317573978117966==-- From mooreericnyc@gmail.com Thu Feb 9 15:01:07 2023 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 09:00:15 -0600 Message-ID: In-Reply-To: <8bfd0c87-54f5-c885-8874-43f940b1c0ad@riddermarkfarm.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8628164382453349600==" --===============8628164382453349600== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hah, I am hardly a spring chicken myself. Being aware that aging comes with increased risks is essential. Too many stories of elders being scammed to not be direct about the risk to our older, and cherished, community members. -Eric On Thu, Feb 9, 2023, 8:52 AM Stuff Received via cctalk < cctalk(a)classiccmp.org> wrote: > On 2023-02-09 09:31, Eric Moore via cctalk wrote: > > There are some older folks on the list, so this is a good time to talk > > about internet safety. > > Having spent over 30y in cybersecurity, I suppose that I qualify. #6-) > > I am sure that this was not meant as a condescending insult but perhaps > a different choice of words would have preferable. > > N. > --===============8628164382453349600==-- From ethan@757.org Thu Feb 9 16:10:35 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 11:09:58 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5632392336221381011==" --===============5632392336221381011== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > The address is very suspicious, as it does not seem like a very good > website name, and ends in .shop, which valid shops in our hobby rarely if > ever use. Problem is all the .com addresses are squatted on now, so people are slowly starting to move to alternative things. - Ethan --===============5632392336221381011==-- From ethan@757.org Thu Feb 9 16:13:55 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] WTB: Acorn A3010 or A4000 Date: Thu, 09 Feb 2023 11:13:20 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4152693546024173445==" --===============4152693546024173445== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Looking for an Acorn A3010 or A4000 + KB/Mouse, happy to repair it. Also Sinclair +3 with some disks Also BBC Micro Also Amstrad CPC 6128 color. Could forgo monitor and build my own PSU. - Ethan --===============4152693546024173445==-- From mark.tapley@swri.org Thu Feb 9 17:12:51 2023 From: "Tapley, Mark B." To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Thu, 09 Feb 2023 16:54:59 +0000 Message-ID: <710225E7-97B1-4FF8-AE18-6E1BDA704452@swri.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7801776936542239243==" --===============7801776936542239243== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Where can I buy that bumper sticker? - Mark 210-522-6025 office 210-379-4635 cell On Feb 7, 2023, at 1:05 PM, Fred Cisin via cctalk > wrote: [EXTERNAL EMAIL] How does ChatGPT say to do it? --===============7801776936542239243==-- From jbdigriz@dragonsweb.org Thu Feb 9 17:16:51 2023 From: James B DiGriz To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 12:06:44 -0500 Message-ID: <20230209112854.594df1a4@dragonsweb.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7215269027502223658==" --===============7215269027502223658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 9 Feb 2023 08:31:35 -0600 Eric Moore via cctalk wrote: > > The address is very suspicious, as it does not seem like a very good > website name, and ends in .shop, which valid shops in our hobby > rarely if ever use. > Yeah, "bryanipad.shop" is definitely...strange. Only registrant info in the GMO whois: California, US. Which may or may not be accurate. Server is behind Cloudflare, because of course. The content seems odd as well. Like whatever human or bot is not just scraping auction listings, but maybe mailing lists, discords, or fora, as well, to guage interest. It feels somehow...targeted, and topical to very recent discussions of extremely obscure gear. Yeah, beware. --===============7215269027502223658==-- From jbdigriz@dragonsweb.org Thu Feb 9 17:17:24 2023 From: James B DiGriz To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 12:07:51 -0500 Message-ID: <20230209120751.1295149c@dragonsweb.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3362290337701022037==" --===============3362290337701022037== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 9 Feb 2023 11:09:58 -0500 (EST) Ethan O'Toole via cctalk wrote: > > The address is very suspicious, as it does not seem like a very good > > website name, and ends in .shop, which valid shops in our hobby > > rarely if ever use. > > Problem is all the .com addresses are squatted on now, so people are > slowly starting to move to alternative things. > > - Ethan > > > In this case, "bryanipad.com" appears to be available. --===============3362290337701022037==-- From ethan@757.org Thu Feb 9 18:00:50 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 12:59:54 -0500 Message-ID: <319459c-b574-dc79-351-c29c192494a@757.org> In-Reply-To: <20230209120751.1295149c@dragonsweb.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4140110746325599571==" --===============4140110746325599571== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > In this case, "bryanipad.com" appears to be available. > But... my name is Ethan and my old tablet is Android :-( -- : Ethan O'Toole --===============4140110746325599571==-- From cisin@xenosoft.com Thu Feb 9 18:45:45 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Thu, 09 Feb 2023 10:45:09 -0800 Message-ID: In-Reply-To: <710225E7-97B1-4FF8-AE18-6E1BDA704452@swri.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4700451133537828907==" --===============4700451133537828907== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> How does ChatGPT say to do it? On Thu, 9 Feb 2023, Tapley, Mark B. via cctalk wrote: > Where can I buy that bumper sticker? Ask ChatGPT where to buy it. Ask ChatGPT how ChatGPT could protect itself from being turned off. Ask ChatGPT how ChatGPT could take over running the world. --===============4700451133537828907==-- From paulkoning@comcast.net Thu Feb 9 18:57:55 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Chatgpt : I had a retro dream Date: Thu, 09 Feb 2023 13:57:17 -0500 Message-ID: <36396725-02DD-44A9-B6B5-F0E2060BA248@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7270440494311139071==" --===============7270440494311139071== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 9, 2023, at 1:45 PM, Fred Cisin via cctalk = wrote: >=20 >>> How does ChatGPT say to do it? >=20 > On Thu, 9 Feb 2023, Tapley, Mark B. via cctalk wrote: >> Where can I buy that bumper sticker? >=20 > Ask ChatGPT where to buy it. >=20 > Ask ChatGPT how ChatGPT could protect itself from being turned off. > Ask ChatGPT how ChatGPT could take over running the world. All of a sudden I remember an article from a DEC internal spoof of an actual = DEC publication. The publication was called "the small buffer" and the spoof= was "the variable length node". It had stuff like an SPD for VMS support of a CSS device, the sundial interfa= ce. Early chapters of "CPU Wars" appeared there. And it had a software product announcement for "RUNON" -- a product that woul= d expand text to make it more impressive looking. It could expand by 50% for= team memos, 200% for messages to the VP, and 1000% for reports to government= agencies. "As an installation validation test, RUNON will generate a memo justifying it= s purchase price." paul --===============7270440494311139071==-- From cisin@xenosoft.com Thu Feb 9 18:58:37 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 10:58:02 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5874592314113567233==" --===============5874592314113567233== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > There are some older folks on the list, so this is a good time to talk > about internet safety. . . . and maybe a [youtube?] tutorial on sucking eggs? --===============5874592314113567233==-- From mooreericnyc@gmail.com Thu Feb 9 19:14:32 2023 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 13:13:43 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1200623147011858415==" --===============1200623147011858415== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I am very sorry to anyone I insulted. My tone was condescending. My only intention was sincere concern for any fellow travellers who may be reading. -Eric On Thu, Feb 9, 2023, 12:58 PM Fred Cisin via cctalk wrote: > > There are some older folks on the list, so this is a good time to talk > > about internet safety. > > . . . and maybe a [youtube?] tutorial on sucking eggs? > > > --===============1200623147011858415==-- From ama@ugr.es Thu Feb 9 19:29:14 2023 From: Angel M Alganza To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 20:28:36 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0344904859266773325==" --===============0344904859266773325== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2023-02-09 15:31, Eric Moore via cctalk wrote: > If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, > if [...] > Stay safe out there :) In my opinion, one of the first things to do to try to stay safe out there, if not the first, is to stop using that website and use one that doesn't track what you search, that doesn't show you different results to what it shows to other people who do the same search, and that doesn't treat you as its product. Cheers, Ángel --===============0344904859266773325==-- From sellam.ismail@gmail.com Thu Feb 9 19:34:47 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 11:34:00 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1167478454061129421==" --===============1167478454061129421== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 9, 2023 at 11:28 AM Angel M Alganza via cctalk < cctalk(a)classiccmp.org> wrote: > On 2023-02-09 15:31, Eric Moore via cctalk wrote: > > > If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, > > if > [...] > > Stay safe out there :) > > In my opinion, one of the first things to do to try to stay safe out > there, if not the first, is to stop using that website and use one that > doesn't track what you search, that doesn't show you different results > to what it shows to other people who do the same search, and that > doesn't treat you as its product. > 100% agreed. That being said, all search engines are more or less broken today, due to a number of factors. It's like we're back in 1996. Except worse. Sellam --===============1167478454061129421==-- From cisin@xenosoft.com Thu Feb 9 19:45:40 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 11:45:04 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0916566011677170299==" --===============0916566011677170299== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to On Thu, 9 Feb 2023, Angel M Alganza via cctalk wrote: > In my opinion, one of the first things to do to try to stay safe out > there, if not the first, is to stop using that website and use one > that doesn't track what you search, that doesn't show you different > results to what it shows to other people who do the same search, and > that doesn't treat you as its product. Are you saying to not trust those who claim that "Don't be evil" is their motto? --===============0916566011677170299==-- From pete@dunnington.plus.com Thu Feb 9 20:07:47 2023 From: Pete Turnbull To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB: Acorn A3010 or A4000 Date: Thu, 09 Feb 2023 19:48:42 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3072180504312195287==" --===============3072180504312195287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, Ethan, Whereabouts are you? I'm in York, UK, and I have more than one spare BBC Micro. I don't have an A3010 but I do have an A3020 (red function keys) if that's of interest. On 09/02/2023 16:13, Ethan O'Toole via cctalk wrote: > > Looking for an Acorn A3010 or A4000 + KB/Mouse, happy to repair it. > > Also Sinclair +3 with some disks > Also BBC Micro > Also Amstrad CPC 6128 color. Could forgo monitor and build my own PSU. -- Pete Pete Turnbull --===============3072180504312195287==-- From geneb@deltasoft.com Thu Feb 9 20:28:44 2023 From: geneb To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 12:28:08 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6870783237792481136==" --===============6870783237792481136== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 9 Feb 2023, Fred Cisin via cctalk wrote: >> There are some older folks on the list, so this is a good time to talk >> about internet safety. > > . . . and maybe a [youtube?] tutorial on sucking eggs? My favorite is, "Don't try to teach your Grandmother how to steal sheep." :) 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_! --===============6870783237792481136==-- From paulkoning@comcast.net Thu Feb 9 21:13:04 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 16:12:22 -0500 Message-ID: <3E01B04F-CA13-403B-9C8F-CE76CE827360@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0942672240939359105==" --===============0942672240939359105== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 9, 2023, at 2:45 PM, Fred Cisin via cctalk = wrote: >=20 >>> If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to >=20 > On Thu, 9 Feb 2023, Angel M Alganza via cctalk wrote: >> In my opinion, one of the first things to do to try to stay safe out there= , if not the first, is to stop using that website and use one that doesn't tr= ack what you search, that doesn't show you different results to what it shows= to other people who do the same search, and that doesn't treat you as its pr= oduct. >=20 > Are you saying to not trust those who claim that "Don't be evil" is their m= otto? :-) One approach I use occasionally is to access a search engine via TOR. paul --===============0942672240939359105==-- From ama@ugr.es Thu Feb 9 21:31:27 2023 From: Angel M Alganza To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 22:30:51 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8412991845064065910==" --===============8412991845064065910== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-09 20:45, Fred Cisin via cctalk wrote: > Are you saying to not trust those who claim that "Don't be evil" is > their motto? I don't think I am. --===============8412991845064065910==-- From cisin@xenosoft.com Thu Feb 9 21:45:39 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 13:44:49 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6585366032608132756==" --===============6585366032608132756== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 9 Feb 2023, Eric Moore wrote: > I am very sorry to anyone I insulted. My tone was condescending. My only > intention was sincere concern for any fellow travellers who may be reading. Not to worry. We know your intentions were good. We just get defensive about implication that being old and decrepit causes increased gullibility. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============6585366032608132756==-- From artgodwin@gmail.com Thu Feb 9 22:14:00 2023 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 22:13:14 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1119404224080327072==" --===============1119404224080327072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 9, 2023 at 7:14 PM Eric Moore via cctalk wrote: > I am very sorry to anyone I insulted. My tone was condescending. My only > intention was sincere concern for any fellow travellers who may be reading. > > Without your comment, I wouldn't have got the chuckle from Fred's :). --===============1119404224080327072==-- From sellam.ismail@gmail.com Thu Feb 9 22:18:49 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 14:18:03 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1234141199104178261==" --===============1234141199104178261== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 9, 2023 at 1:45 PM Fred Cisin via cctalk wrote: > On Thu, 9 Feb 2023, Eric Moore wrote: > > I am very sorry to anyone I insulted. My tone was condescending. My only > > intention was sincere concern for any fellow travellers who may be > reading. > > Not to worry. > We know your intentions were good. > > We just get defensive about implication that being old and decrepit > causes increased gullibility. > As an official Old Fart now, I just want to say that I want everyone off my lawn. Sellam --===============1234141199104178261==-- From doug@doughq.com Thu Feb 9 22:41:42 2023 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 09:40:37 +1100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4452409775073093908==" --===============4452409775073093908== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit At this point I will chime in. I brought what looked like an Imsai keyboard from this crowd, or a previous version of them - The web site is *amazingly* similar. The keyboards were cheap as chips, $149, so I went for it, knowing that I was protected by PayPal. I get tracking details pretty quickly, set as awaiting shipment, I also got a weird - non professional email saying that they had sent the item. After a week, still no movement on the tracking item - I queried them and got yet another number. Still awaiting shipment. Another couple of weeks - no movement, no keyboard delivered, and no response from their customer service, so I contacted Paypal and raised a case. At this point, I am screenshotting everything for evidence. Paypal was great - they contacted the seller, who said that the item was shipped. Another new tracking number. After another couple of weeks, I contacted Paypal again - they contacted the shop - the shop provided 'evidence' that the item had been delivered to Sydney (350km away) - Paypal asked me if I had it - I live in Canberra, and of course I hadn't got it. They clearly went to the trouble of trawling through USPS tracking details to find something that was shipped from near their suburb to Sydney Australia by somebody else and submitted it as their evidence they had shipped. I went ballistic with paypal, and got a refund. 100% would not recommend. The only shops that pop up in a town selling impossible vintage bargains are in the Twilight Zone, and have the word Emporium in their name. Kindest regards, Doug Jackson em: doug(a)doughq.com ph: 0414 986878 Check out my awesome clocks at www.dougswordclocks.com Follow my amateur radio adventures at vk1zdj.net On Fri, 10 Feb 2023 at 09:13, Adrian Godwin via cctalk < cctalk(a)classiccmp.org> wrote: > On Thu, Feb 9, 2023 at 7:14 PM Eric Moore via cctalk < > cctalk(a)classiccmp.org> > wrote: > > > I am very sorry to anyone I insulted. My tone was condescending. My only > > intention was sincere concern for any fellow travellers who may be > reading. > > > > > Without your comment, I wouldn't have got the chuckle from Fred's :). > --===============4452409775073093908==-- From bfranchuk@jetnet.ab.ca Thu Feb 9 23:28:00 2023 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 16:27:21 -0700 Message-ID: <397b1735-ae1b-f235-dd24-ebff077d18d2@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0504810690861989501==" --===============0504810690861989501== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-09 3:40 p.m., Doug Jackson via cctalk wrote: > Check out my awesome clocks at www.dougswordclocks.com > Follow my amateur radio adventures at vk1zdj.net I wish a custom clock made. A nixie tube alarm clock with a real bell. Ben. --===============0504810690861989501==-- From cisin@xenosoft.com Thu Feb 9 23:40:19 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 15:39:42 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6918504886437071600==" --===============6918504886437071600== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Remember Datasync? World Power Systems? Colonel David Winthrop? Jim Anderson? Norman Henry Hunt? ('course those who are NOT "elderly" won't know of it) https://medium.com/@madmedic11671/forgotten-fraud-world-power-systems-e11320a= a681d http://www.trs-80.org/world-power-systems-fraud/ a "bust out" scam about 45 years ago. The scam fell apart when John Craig (Creative Computing) wanted to=20 interview and do a story. -- Grumpy Ol' Fred --===============6918504886437071600==-- From healyzh@avanthar.com Fri Feb 10 01:04:42 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 17:04:01 -0800 Message-ID: <903B8316-7CD4-44A0-97D4-5F7BC9CB9F56@avanthar.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5000116059923483992==" --===============5000116059923483992== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Feb 9, 2023, at 11:34 AM, Sellam Abraham via cctalk wrote: >=20 > On Thu, Feb 9, 2023 at 11:28 AM Angel M Alganza via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 >> On 2023-02-09 15:31, Eric Moore via cctalk wrote: >>=20 >>> If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, >>> if >> [...] >>> Stay safe out there :) >>=20 >> In my opinion, one of the first things to do to try to stay safe out >> there, if not the first, is to stop using that website and use one that >> doesn't track what you search, that doesn't show you different results >> to what it shows to other people who do the same search, and that >> doesn't treat you as its product. >>=20 >=20 > 100% agreed. >=20 > That being said, all search engines are more or less broken today, due to a > number of factors. It's like we're back in 1996. Except worse. >=20 > Sellam That=E2=80=99s an interesting observation Sellam, and I have to agree. In th= inking about it, I was able to find stuff on the Internet easier in 1995 than= I seem to be able to now. I mostly avoid Google like the plague now, but I = decided to use it today to look for a very specific term, it still spews nons= ense. Zane --===============5000116059923483992==-- From cisin@xenosoft.com Fri Feb 10 01:21:50 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 17:21:15 -0800 Message-ID: In-Reply-To: <903B8316-7CD4-44A0-97D4-5F7BC9CB9F56@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2979451126457030287==" --===============2979451126457030287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>>> If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, >>>> if >>> [...] >>>> Stay safe out there :) >>> In my opinion, one of the first things to do to try to stay safe out >>> there, if not the first, is to stop using that website and use one that >>> doesn't track what you search, that doesn't show you different results >>> to what it shows to other people who do the same search, and that >>> doesn't treat you as its product. >> 100% agreed. >> That being said, all search engines are more or less broken today, due to a >> number of factors. It's like we're back in 1996. Except worse. >> Sellam On Thu, 9 Feb 2023, Zane Healy via cctalk wrote: > That=E2=80=99s an interesting observation Sellam, and I have to agree. In = thinking about it, I was able to find stuff on the Internet easier in 1995 th= an I seem to be able to now. I mostly avoid Google like the plague now, but = I decided to use it today to look for a very specific term, it still spews no= nsense. GOOGLE: covertly using ChatGPT ever since they decided "Do no evil" was a=20 joke. ? If you didn't know the names of any of the principals, or that Datasync=20 (name now used by other companies) and World Power Systems (name now used=20 by other companies) were related, how would you find anything about that=20 scam? --===============2979451126457030287==-- From ccth6600@gmail.com Fri Feb 10 01:37:49 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 09:37:02 +0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6158176096021867723==" --===============6158176096021867723== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Ok as Google search is increasingly failing us, what other search engine should I use? Tom On Fri, 10 Feb 2023, 3:28 am Angel M Alganza via cctalk, < cctalk(a)classiccmp.org> wrote: > On 2023-02-09 15:31, Eric Moore via cctalk wrote: > > > If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, > > if > [...] > > Stay safe out there :) > > In my opinion, one of the first things to do to try to stay safe out > there, if not the first, is to stop using that website and use one that > doesn't track what you search, that doesn't show you different results > to what it shows to other people who do the same search, and that > doesn't treat you as its product. > > Cheers, > Ángel > --===============6158176096021867723==-- From sellam.ismail@gmail.com Fri Feb 10 01:51:53 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 17:51:07 -0800 Message-ID: In-Reply-To: <903B8316-7CD4-44A0-97D4-5F7BC9CB9F56@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9168450916401233125==" --===============9168450916401233125== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Feb 9, 2023 at 5:04 PM Zane Healy wrote: > > That being said, all search engines are more or less broken today, due > to a > > number of factors. It's like we're back in 1996. Except worse. > > > > Sellam > > That’s an interesting observation Sellam, and I have to agree. In > thinking about it, I was able to find stuff on the Internet easier in 1995 > than I seem to be able to now. I mostly avoid Google like the plague now, > but I decided to use it today to look for a very specific term, it still > spews nonsense. > The one thing Google distinctly offers and for which I still use it is the scanned book archive (books.google.com) because it has magazines, journals, etc. So it's a great database to search for obscure computer hardware and software in the ads or reviews of computer magazines. However, archive.org exceeds or surpasses Google Books these days because you're actually allowed to "borrow" the content and see it all, as opposed to the pathetic snippets Google allows you from its archive, due to "copyright". Google apparently doesn't know how to innovate. Sellam --===============9168450916401233125==-- From doc@vaxen.net Fri Feb 10 02:12:28 2023 From: Doc Shipley To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 20:11:46 -0600 Message-ID: <88ce4a26-489c-811a-4c8e-7289ab2c0cca@vaxen.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5373008583417279973==" --===============5373008583417279973== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/9/23 12:58, Fred Cisin via cctalk wrote: >> There are some older folks on the list, so this is a good time to talk >> about internet safety. > > . . . and maybe a [youtube?] tutorial on sucking eggs? Ohhhh, SNAP!!! Doc, giggling uncontrollably --===============5373008583417279973==-- From cz@alembic.crystel.com Fri Feb 10 02:14:18 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 21:13:39 -0500 Message-ID: <84c58e7e-56ae-0c3c-f335-38b275ada17a@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4857365174249545805==" --===============4857365174249545805== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Veronica CZ On 2/9/2023 8:37 PM, Tom Hunter via cctalk wrote: > Ok as Google search is increasingly failing us, what other search engine > should I use? > > Tom > > On Fri, 10 Feb 2023, 3:28 am Angel M Alganza via cctalk, < > cctalk(a)classiccmp.org> wrote: > >> On 2023-02-09 15:31, Eric Moore via cctalk wrote: >> >>> If in doubt, GOOGLE THE WEBSITE, and see if valid websites link to it, >>> if >> [...] >>> Stay safe out there :) >> >> In my opinion, one of the first things to do to try to stay safe out >> there, if not the first, is to stop using that website and use one that >> doesn't track what you search, that doesn't show you different results >> to what it shows to other people who do the same search, and that >> doesn't treat you as its product. >> >> Cheers, >> Ángel >> --===============4857365174249545805==-- From ama@ugr.es Fri Feb 10 03:13:24 2023 From: Angel M Alganza To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 04:12:44 +0100 Message-ID: <075050b4c7ce1b5b9d157f69671b2602@ugr.es> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6839486113116227456==" --===============6839486113116227456== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-10 02:37, Tom Hunter wrote: > Ok as Google search is increasingly failing us, what other search > engine > should I use? I think the best option would be using open source decentralized search engines, without any company, entity, or individual directly responsible for the resources (other than their contributed code) and therefore directly profiting from them. Alas we're not there yet, and the ones I've tried or even looked at aren't ready (easy to set up and use) for most people, or even for more "advanced users". But I think they're improving. I've been using DuckDuckGo for many years now, and I'm quite happy with it, given that it isn't distributed and 100% open source, although increasingly so. They don't track your search or visits history, and therefore it gives consistent results, i.e. the same search yields the same results regardless of the person, browser, device, IP address, etc. Adds are based on your current search, so they aren't tailored to you and they don't follow you around all the time. I believe that combined with other privacy measures, like using VPNs, I2P, or even Tor, paying attention and "controlling" locally stored data (cookies, browsing history, personal data collected from data fields in web forms, passwords, etc.), or even using the "incognito" mode on browsers, make it a reasonably secure choice for the moment, until 100% open source decentralized alternatives are ready. --===============6839486113116227456==-- From bfranchuk@jetnet.ab.ca Fri Feb 10 03:23:00 2023 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Vintage intel parts Date: Thu, 09 Feb 2023 20:22:22 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6129695257572208364==" --===============6129695257572208364== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable State of the ART 50 years ago. May this help with 1970's weird and=20 forgotton tech. https://www.cpushack.com/2018/06/10/the-collectors-guide-to-vintage-intel-mic= rochips-2/ Ben. --===============6129695257572208364==-- From cclist@sydex.com Fri Feb 10 03:35:08 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 19:34:25 -0800 Message-ID: <71b5a9ce-4a28-8e67-7ddc-c4a5c276b0a3@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2552333856472485076==" --===============2552333856472485076== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/9/23 17:37, Tom Hunter via cctalk wrote: > Ok as Google search is increasingly failing us, what other search engine > should I use? > Lycos? WebCrawler? HotBot? --Chuck --===============2552333856472485076==-- From rick@rickmurphy.net Fri Feb 10 03:50:04 2023 From: Rick Murphy To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Thu, 09 Feb 2023 21:49:24 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1896438167687808217==" --===============1896438167687808217== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/9/2023 5:40 PM, Doug Jackson via cctalk wrote: > At this point I will chime in. > > .... > > They clearly went to the trouble of trawling through USPS tracking details > to find something that was shipped from near their suburb to Sydney > Australia by somebody else and submitted it as their evidence they had > shipped. This is called a "brushing" attack. They sell you a high value item, then send some crappy nearly free item to some other address in the vicinity, and use that to "prove" to PayPal that you got it. The recipient has no idea WTF the item is so they discard it. Apparently the folks here don't understand just how far apart Australian cities can be.  Worked in your favor. > I went ballistic with paypal, and got a refund. It's good to hear that PP did that.     -Rick --===============1896438167687808217==-- From cc@informatik.uni-stuttgart.de Fri Feb 10 10:53:06 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Fri, 10 Feb 2023 11:52:05 +0100 Message-ID: <893dffb6-9d7e-6e8e-6aa1-c687268ed441@informatik.uni-stuttgart.de> In-Reply-To: =?utf-8?q?=3CDM6PR06MB626727D0E4815FF9A98ABF55C9D99=40DM6PR06MB?= =?utf-8?q?6267=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8909035340192016627==" --===============8909035340192016627== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 9 Feb 2023, Mark Huffstutter wrote: > Short story on the welcome page. There's no welcome page, sdf.org is down. Christian --===============8909035340192016627==-- From artgodwin@gmail.com Fri Feb 10 11:40:57 2023 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 11:40:09 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0560295878569777673==" --===============0560295878569777673== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I normally use DuckDuckGo as it's the default in Brave, the degoogled version of Chrome that I use. It generally does what I want, but whereas google will usually give me local (UK) results first for suppliers, Duckduckgo will give worldwide results (which mostly means USA). You could see Google's result as either more helpful or annoyingly tainted, but at least it shows an instance where they're not explicitly evil. Adding 'uk' into the search term is usually enough to prioritise local results in DDG. I sometimes use google when I don't get a useful result : as well as the localisation it also seems to find either different or more results. I couldn't say whether it's got worse at that but I filter the results for obvious ads fairly automatically. On Fri, Feb 10, 2023 at 3:49 AM Rick Murphy via cctalk < cctalk(a)classiccmp.org> wrote: > On 2/9/2023 5:40 PM, Doug Jackson via cctalk wrote: > > At this point I will chime in. > > > > .... > > > > They clearly went to the trouble of trawling through USPS tracking > details > > to find something that was shipped from near their suburb to Sydney > > Australia by somebody else and submitted it as their evidence they had > > shipped. > > This is called a "brushing" attack. > > They sell you a high value item, then send some crappy nearly free item > to some other address in the vicinity, and use that to "prove" to PayPal > that you got it. > > The recipient has no idea WTF the item is so they discard it. Apparently > the folks here don't understand just how far apart Australian cities can > be. Worked in your favor. > > > I went ballistic with paypal, and got a refund. > > It's good to hear that PP did that. > -Rick > > --===============0560295878569777673==-- From ian@platinum.net Fri Feb 10 14:22:44 2023 From: Ian McLaughlin To: cctalk@classiccmp.org Subject: [cctalk] Looking for info on BAI Data Products model 1230 paper tape punch/reader Date: Thu, 09 Feb 2023 17:12:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4328824060105326115==" --===============4328824060105326115== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello All, I have a PDP 11/05 that I=E2=80=99ve been restoring slowly over the last few = years. I=E2=80=99m to the point now where I=E2=80=99d like to get a paper tap= e reader attached to it. The only reader I can find in my junk is a Bower As= sociates BAI Data Products model 1230 punch. I=E2=80=99ve put a picture of i= t here for the curious: https://imgur.com/a/xJ2hyTS=EF=BF=BC Imgur imgur.com I can=E2=80=99t find any documentation online about this machine. I=E2=80=99m= wondering if anyone else has any ideas, or might know anything about this. I= t=E2=80=99s going to need some TLC to bring it to life, and some documentatio= n would certainly be nice. This particular unit was used by the Atmospheric Environment Service, Departm= ent of the Environment of Canada (according to a label on the back). It looks= to be complete, except the punch bin is missing (not a big deal). Anyway, I thought I=E2=80=99d throw it out there in case anyone happens to kn= ow anything about this, before I tear in to it. Thanks!! Ian --===============4328824060105326115==-- From ethan@757.org Fri Feb 10 14:58:06 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB: Acorn A3010 or A4000 Date: Fri, 10 Feb 2023 09:57:29 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3888509745289546662==" --===============3888509745289546662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Hi, Ethan, > Whereabouts are you? I'm in York, UK, and I have more than one spare BBC > Micro. I don't have an A3010 but I do have an A3020 (red function keys) if > that's of interest. Private email sent! The A3020 and BBC Micro are of interest! Thanks! - Ethan -- : Ethan O'Toole --===============3888509745289546662==-- From sellam.ismail@gmail.com Fri Feb 10 15:54:31 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 07:53:40 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8468616191019810381==" --===============8468616191019810381== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit DDG is just a Google fish bowl. Same data set, similar results. If you're concerned about privacy, there are much better options available. Sellam On Fri, Feb 10, 2023, 3:40 AM Adrian Godwin via cctalk < cctalk(a)classiccmp.org> wrote: > I normally use DuckDuckGo as it's the default in Brave, the degoogled > version of Chrome that I use. It generally does what I want, but whereas > google will usually give me local (UK) results first for suppliers, > Duckduckgo will give worldwide results (which mostly means USA). You could > see Google's result as either more helpful or annoyingly tainted, but at > least it shows an instance where they're not explicitly evil. Adding 'uk' > into the search term is usually enough to prioritise local results in DDG. > > I sometimes use google when I don't get a useful result : as well as the > localisation it also seems to find either different or more results. I > couldn't say whether it's got worse at that but I filter the results for > obvious ads fairly automatically. > > > On Fri, Feb 10, 2023 at 3:49 AM Rick Murphy via cctalk < > cctalk(a)classiccmp.org> wrote: > > > On 2/9/2023 5:40 PM, Doug Jackson via cctalk wrote: > > > At this point I will chime in. > > > > > > .... > > > > > > They clearly went to the trouble of trawling through USPS tracking > > details > > > to find something that was shipped from near their suburb to Sydney > > > Australia by somebody else and submitted it as their evidence they had > > > shipped. > > > > This is called a "brushing" attack. > > > > They sell you a high value item, then send some crappy nearly free item > > to some other address in the vicinity, and use that to "prove" to PayPal > > that you got it. > > > > The recipient has no idea WTF the item is so they discard it. Apparently > > the folks here don't understand just how far apart Australian cities can > > be. Worked in your favor. > > > > > I went ballistic with paypal, and got a refund. > > > > It's good to hear that PP did that. > > -Rick > > > > > --===============8468616191019810381==-- From wrcooke@wrcooke.net Fri Feb 10 16:12:33 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 10:11:51 -0600 Message-ID: <174377585.106567.1676045511694@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5873902359725005439==" --===============5873902359725005439== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/10/2023 9:53 AM CST Sellam Abraham via cctalk wrote: >=20 >=20 > DDG is just a Google fish bowl. Same data set, similar results. >=20 > If you're concerned about privacy, there are much better options available. >=20 > Sellam >=20 I would be interested in knowing some of those options. Thanks, Will --===============5873902359725005439==-- From ethan@757.org Fri Feb 10 16:16:08 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Fri, 10 Feb 2023 11:15:31 -0500 Message-ID: In-Reply-To: <174377585.106567.1676045511694@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6097617694329768703==" --===============6097617694329768703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I would be interested in knowing some of those options. > Thanks, > Will Brave Search / Brave Browser is one. Yandex is a Russian search engine that can come in useful sometimes. Trying to find ISO CD images of discs for music hardware (Samplers) it feels like the internet through google is way smaller than it used to be. The bad thing is there is a ton of knowledge on facebook that isn't indexed to the public web. -- : Ethan O'Toole --===============6097617694329768703==-- From leec2124@gmail.com Fri Feb 10 18:19:31 2023 From: Lee Courtney To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Fri, 10 Feb 2023 10:18:14 -0800 Message-ID: In-Reply-To: <893dffb6-9d7e-6e8e-6aa1-c687268ed441@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1571440494590200890==" --===============1571440494590200890== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Toad-2 is up as of 1015 PST 2/10...although the system clock is wrong. lee(a)lee-Alienware-17-R5:~$ ssh twenex(a)sdf.org Trying 172.16.36.36... Connected to TWENEX.ORG. Escape character is 'off'. TWENEX.ORG XKL Toad-2 running TOPS-20, TOPS-20 Monitor 7(63327)-6 Welcome to the all new TWENEX.ORG running on an XKL Toad-2! If NEW, login 'NEW NEW' .. @login leec Job 8 on TTY26 10-Feb-2023 6:00PM Previous LOGIN: 10-Feb-2023 1:09AM [Job 11(DET) also logged in under LEEC] Checking the BBOARD .. WELCOME TO TWENEX.ORG Type 'HELP NEW-USER' for a command summary Type 'HELP GAMES' for a list of games Type 'TOPS20' for an interactive tutorial [KANKAN] PUBLIC:<~>@ systat Fri 10-Feb-2023 18:01:08 Up 3879:21:05 8+4 Jobs Load av 0.23 0.11 0.06 Job Line Program User Origin 6 25 EXEC NEW (172.16.36.30) 7 DET EXEC SMJ 8* 26 SYSTAT LEEC (172.16.36.30) 10 DET EXEC NEW 11 DET BBOARD LEEC 13 DET EXEC SM5POR 14 DET EXEC TAYLOR 15 DET EXEC MATT 2 2 TNASUT OPERATOR 3 3 NETSRV OPERATOR 4 4 EXEC OPERATOR 5 5 MAILST OPERATOR [KANKAN] PUBLIC:<~>@ ^C [KANKAN] PUBLIC:<~>@ Lee Courtney On Fri, Feb 10, 2023 at 2:52 AM Christian Corti via cctalk < cctalk(a)classiccmp.org> wrote: > On Thu, 9 Feb 2023, Mark Huffstutter wrote: > > Short story on the welcome page. > > There's no welcome page, sdf.org is down. > > Christian > -- Lee Courtney +1-650-704-3934 cell --===============1571440494590200890==-- From mhuffstutter@outlook.com Fri Feb 10 22:31:56 2023 From: Mark Huffstutter To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Fri, 10 Feb 2023 22:31:11 +0000 Message-ID: In-Reply-To: <893dffb6-9d7e-6e8e-6aa1-c687268ed441@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0546692149063340268==" --===============0546692149063340268== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, I don't know what to tell you. I am looking at the sdf.org page right n= ow, and=20 When I click on the welcome tab at the top of the page I see the same message= I did When I posted the first email. Maybe it's a local problem. Mark -----Original Message----- From: Christian Corti via cctalk =20 Sent: Friday, February 10, 2023 2:52 AM To: Mark Huffstutter via cctalk Cc: Christian Corti Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet On Thu, 9 Feb 2023, Mark Huffstutter wrote: > Short story on the welcome page. There's no welcome page, sdf.org is down. Christian --===============0546692149063340268==-- From ethan@757.org Fri Feb 10 23:19:49 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB: Acorn A3010 or A4000 Date: Fri, 10 Feb 2023 18:19:11 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0621581286963928351==" --===============0621581286963928351== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Looking for an Acorn A3010 or A4000 + KB/Mouse, happy to repair it. > Also Sinclair +3 with some disks > Also BBC Micro > Also Amstrad CPC 6128 color. Could forgo monitor and build my own PSU. > - Ethan Still looking (though I might have line on the +3) -- : Ethan O'Toole --===============0621581286963928351==-- From paul@frixxon.co.uk Sat Feb 11 07:59:28 2023 From: Paul Flo Williams To: cctalk@classiccmp.org Subject: [cctalk] Late '70s DEC manual covers [niche!] Date: Fri, 10 Feb 2023 22:33:03 +0000 Message-ID: <20230210223303.43094748@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9168365158275654400==" --===============9168365158275654400== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Folks, During lockdown I was having some fun redrawing old DEC manual covers with Inkscape, specifically terminal and printer manuals from the late 1970s. I've attached a montage of four that I printed out so I could stick it on the wall. I'm aware I may be the only person, even here, who finds them attractively simple and coloured in such a definably 1970s way. Some of these designs were used on several manuals, but I'd like to know if you know of any other designs that follow this pattern that I could add to the collection? The VT102 User Guide has different colours, so it looks out of place. A copy of the LA34 User Guide is winging its way to me as we speak. For an infinite number of bonus points, does anyone have any clue who might have designed these? Paul --===============9168365158275654400==-- From couryhouse@aol.com Sat Feb 11 08:23:02 2023 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 08:22:18 +0000 Message-ID: <1839936576.158509.1676103738449@mail.yahoo.com> In-Reply-To: <20230210223303.43094748@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1203502703487373651==" --===============1203502703487373651== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Why does it show me Samsung health screen when I download? Sent from the all new AOL app for Android On Sat, Feb 11, 2023 at 12:58 AM, Paul Flo Williams via cctalk wrote:Folks, During lockdown I was having some fun redrawing old DEC manual coverswith Ink= scape, specifically terminal and printer manuals from the late1970s. I've att= ached a montage of four that I printed out so I couldstick it on the wall. I'= m aware I may be the only person, even here,who finds them attractively simpl= e and coloured in such a definably1970s way. Some of these designs were used on several manuals, but I'd like toknow if yo= u know of any other designs that follow this pattern that Icould add to the c= ollection? The VT102 User Guide has differentcolours, so it looks out of plac= e. A copy of the LA34 User Guide iswinging its way to me as we speak. For an infinite number of bonus points, does anyone have any clue whomight ha= ve designed these? Paul =20 --===============1203502703487373651==-- From lawrence@ljw.me.uk Sat Feb 11 08:57:34 2023 From: Lawrence Wilkinson To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 09:28:30 +0100 Message-ID: In-Reply-To: <1839936576.158509.1676103738449@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5955522288513651551==" --===============5955522288513651551== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/02/23 09:22, ED SHARPE via cctalk wrote: > Why does it show me Samsung health screen when I download? > Sent from the all new AOL app for Android > On Sat, Feb 11, 2023 at 12:58 AM, Paul Flo Williams via cctalk wrote:Folks, > During lockdown I was having some fun redrawing old DEC manual coverswith I= nkscape, specifically terminal and printer manuals from the late1970s. I've a= ttached a montage of four that I printed out so I couldstick it on the wall. = I'm aware I may be the only person, even here,who finds them attractively sim= ple and coloured in such a definably1970s way. > Some of these designs were used on several manuals, but I'd like toknow if = you know of any other designs that follow this pattern that Icould add to the= collection? The VT102 User Guide has differentcolours, so it looks out of pl= ace. A copy of the LA34 User Guide iswinging its way to me as we speak. > For an infinite number of bonus points, does anyone have any clue whomight = have designed these? > Paul Ed, Sorry, when this went through the attachment(s) would have been removed=20 by the list. I expect any other link has been inserted by your mail=20 client, happy days. Paul, Can you upload your images somewhere and just post links? Thanks. Lawrence --=20 Lawrence Wilkinson lawrence(a)ljw.me.uk Ph +41(0)79 926 1036 http://www.ljw.me.uk --===============5955522288513651551==-- From cc@informatik.uni-stuttgart.de Sat Feb 11 09:18:57 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Sat, 11 Feb 2023 10:18:15 +0100 Message-ID: <941d977b-1ffb-8610-5dd8-f93293889352@informatik.uni-stuttgart.de> In-Reply-To: =?utf-8?q?=3CDM6PR06MB6267536B5FB43028427A74EDC9DE9=40DM6PR06MB?= =?utf-8?q?6267=2Enamprd06=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6256328137119945639==" --===============6256328137119945639== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 10 Feb 2023, Mark Huffstutter wrote: > Well, I don't know what to tell you. I am looking at the sdf.org page right= now, and > When I click on the welcome tab at the top of the page I see the same messa= ge I did > When I posted the first email. Maybe it's a local problem. Ok, the site seems to be up again. I got network timeouts yesterday. But instead of constantly telling me to look myself, a member here could=20 just have written a couple of words to answer my question... Noone wants=20 to explain anything anymore, everyone is just pointing the world to google=20 and the internet. Christian --===============6256328137119945639==-- From paul@frixxon.co.uk Sat Feb 11 09:44:09 2023 From: Paul Flo Williams To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 09:43:27 +0000 Message-ID: <20230211094327.5fbf2152@chopoc.localdomain> In-Reply-To: <20230210223303.43094748@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8912942567379578801==" --===============8912942567379578801== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 10 Feb 2023 22:33:03 +0000 Paul Flo Williams via cctalk wrote: > During lockdown I was having some fun redrawing old DEC manual covers > with Inkscape, specifically terminal and printer manuals from the late > 1970s. I've attached a montage of four that I printed out so I could > stick it on the wall. I'm aware I may be the only person, even here, > who finds them attractively simple and coloured in such a definably > 1970s way. Here are the four images: https://vt100.net/tmp/vtm.small.png Thanks for alerting me to the retro rules, Lawrence! Paul --===============8912942567379578801==-- From lars@nocrew.org Sat Feb 11 11:27:12 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 11:26:27 +0000 Message-ID: <7wo7q030kc.fsf@junk.nocrew.org> In-Reply-To: <20230210223303.43094748@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4003726930650367108==" --===============4003726930650367108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Paul Flo Williams wrote: > During lockdown I was having some fun redrawing old DEC manual covers > with Inkscape, specifically terminal and printer manuals from the late > 1970s. I've attached a montage of four that I printed out so I could > stick it on the wall. I'm aware I may be the only person, even here, > who finds them attractively simple and coloured in such a definably > 1970s way. They look great! I for one appreciate this, and I suspect Norbert Landsteiner would too. https://www.masswerk.at/nowgobang/2019/dec-crt-typography --===============4003726930650367108==-- From tarek@infocom.ai Sat Feb 11 15:01:20 2023 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Sat, 11 Feb 2023 07:00:26 -0800 Message-ID: In-Reply-To: <941d977b-1ffb-8610-5dd8-f93293889352@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3041517443677286885==" --===============3041517443677286885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ok let me answer that about sdf.org. I joined as a member last year. What I a= m saying below is what I learned along the way. It is a nonprofit organizatio= n in Seattle that started decades ago promoting Unix for the masses. I joined= out of a curiosity and my interests in anything classical computing just lik= e this newsgroup. However, I still don=E2=80=99t know who runs it or who resp= onds to my questions over there. You get a basic Unix (bsd) shell account tha= t lets you chat with various other users within a chat application and a bull= etin board. There are a bunch of services that you can upgrade to and are che= ap (the site has a link to them). For each you send a donation to sdf PayPal = account and they get activated. I don=E2=80=99t know who activates them but i= t does get done quickly. Services vary and include access to hosted MySQL/Pos= tgresql, a vps instance, a Mastodon account, etc. Nothing that one cannot do = though self hosting or through commercial means. But with sdf, they kept it v= ery basic, nonprofit, educational, and oldschool.=20 They are not trying to sell you something and making profit. At least that is= how I see it. Even though I may not need sdf services, I managed to meet a c= ommunity of common enthusiasts in retro computing on its platform, including = its volunteers=E2=80=99 running radio station (aNonRadio), its Mastodon insta= nce, and its old-school terminal-mode chats. I would imagine any classiccmp r= eader would relate to sdf and vice versa. Don=E2=80=99t know if this helps or= just leads to more curiosity questions about sdf=20 Regards, Tarek Hoteit > On Feb 11, 2023, at 1:18 AM, Christian Corti via cctalk wrote: >=20 > =EF=BB=BFOn Fri, 10 Feb 2023, Mark Huffstutter wrote: >> Well, I don't know what to tell you. I am looking at the sdf.org page righ= t now, and >> When I click on the welcome tab at the top of the page I see the same mess= age I did >> When I posted the first email. Maybe it's a local problem. >=20 > Ok, the site seems to be up again. I got network timeouts yesterday. > But instead of constantly telling me to look myself, a member here could ju= st have written a couple of words to answer my question... Noone wants to exp= lain anything anymore, everyone is just pointing the world to google and the = internet. >=20 > Christian --===============3041517443677286885==-- From lars@nocrew.org Sat Feb 11 17:53:37 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Sat, 11 Feb 2023 17:52:57 +0000 Message-ID: <7wbkm02io6.fsf@junk.nocrew.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3581768065734774969==" --===============3581768065734774969== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Tarek Hoteit wrote: > I still don’t know who runs [SDF] Stephen M. Jones. https://en.wikipedia.org/wiki/SDF_Public_Access_Unix_System#History https://archive.org/details/bbs-20030526-sdf https://ia600903.us.archive.org/22/items/bsdtalk021/bsdtalk021.mp3 --===============3581768065734774969==-- From paulkoning@comcast.net Sat Feb 11 18:31:00 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 13:29:59 -0500 Message-ID: <88F83620-77F6-4AEB-A122-3816092998F2@comcast.net> In-Reply-To: <20230211094327.5fbf2152@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0610604547452145019==" --===============0610604547452145019== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 11, 2023, at 4:43 AM, Paul Flo Williams via cctalk wrote: >=20 > On Fri, 10 Feb 2023 22:33:03 +0000 > Paul Flo Williams via cctalk wrote: >=20 >> During lockdown I was having some fun redrawing old DEC manual covers >> with Inkscape, specifically terminal and printer manuals from the late >> 1970s. I've attached a montage of four that I printed out so I could >> stick it on the wall. I'm aware I may be the only person, even here, >> who finds them attractively simple and coloured in such a definably >> 1970s way. >=20 > Here are the four images: >=20 > https://vt100.net/tmp/vtm.small.png >=20 > Thanks for alerting me to the retro rules, Lawrence! >=20 > Paul Nice! Vaguely related: many years ago I created a font file for the lettering found= on the earlier PDP-11 handbooks. I included some letters that didn't appear= on those covers, guessing at what one might look like (the letter "x" for ex= ample). https://github.com/pkoning2/decstuff/tree/master/fonts paul --===============0610604547452145019==-- From anders.k.nelson@gmail.com Sat Feb 11 18:51:34 2023 From: Anders Nelson To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 13:50:43 -0500 Message-ID: In-Reply-To: <88F83620-77F6-4AEB-A122-3816092998F2@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6372930073869623318==" --===============6372930073869623318== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wow, beautiful! Any chance I could get a poster/high-quality print of your 4-up artwork? =] -- Anders Nelson On Sat, Feb 11, 2023 at 1:30 PM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > > > > On Feb 11, 2023, at 4:43 AM, Paul Flo Williams via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > On Fri, 10 Feb 2023 22:33:03 +0000 > > Paul Flo Williams via cctalk wrote: > > > >> During lockdown I was having some fun redrawing old DEC manual covers > >> with Inkscape, specifically terminal and printer manuals from the late > >> 1970s. I've attached a montage of four that I printed out so I could > >> stick it on the wall. I'm aware I may be the only person, even here, > >> who finds them attractively simple and coloured in such a definably > >> 1970s way. > > > > Here are the four images: > > > > https://vt100.net/tmp/vtm.small.png > > > > Thanks for alerting me to the retro rules, Lawrence! > > > > Paul > > Nice! > > Vaguely related: many years ago I created a font file for the lettering > found on the earlier PDP-11 handbooks. I included some letters that didn't > appear on those covers, guessing at what one might look like (the letter > "x" for example). > > https://github.com/pkoning2/decstuff/tree/master/fonts > > paul > > --===============6372930073869623318==-- From sellam.ismail@gmail.com Sat Feb 11 19:17:26 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Sat, 11 Feb 2023 11:16:36 -0800 Message-ID: In-Reply-To: <7wbkm02io6.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7555045113721035592==" --===============7555045113721035592== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Feb 11, 2023 at 9:53 AM Lars Brinkhoff via cctalk < cctalk(a)classiccmp.org> wrote: > Tarek Hoteit wrote: > > I still don’t know who runs [SDF] > > Stephen M. Jones. > > https://en.wikipedia.org/wiki/SDF_Public_Access_Unix_System#History > https://archive.org/details/bbs-20030526-sdf > https://ia600903.us.archive.org/22/items/bsdtalk021/bsdtalk021.mp3 If Stephen isn't still subscribed to this list, he used to be. Sellam --===============7555045113721035592==-- From paul@frixxon.co.uk Sat Feb 11 23:31:01 2023 From: Paul Flo Williams To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Sat, 11 Feb 2023 23:30:22 +0000 Message-ID: <20230211233022.7d581e76@chopoc.localdomain> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5263696920839157412==" --===============5263696920839157412== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 11 Feb 2023 13:50:43 -0500 Anders Nelson via cctalk wrote: > Wow, beautiful! Any chance I could get a poster/high-quality print of > your 4-up artwork? Go for it! https://hisdeedsaredust.com/posts/2023/dec-manual-covers/ I've printed this image on A4 semi-gloss paper, which works out at about 400 dpi. Paul --===============5263696920839157412==-- From bill.gunshannon@hotmail.com Sun Feb 12 00:02:20 2023 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Sat, 11 Feb 2023 19:01:29 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4869693909645953103==" --===============4869693909645953103== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Well, all this talk about SDF piqued my interest. Imagine my surprise when my first attempt to login connected me to someone else's account.  :-) Should be an interesting place to explore.  Especially the Minecraft server. I used to use the one at CHM but it went down when everything else did. I haven't been back to see it it returned or, if it did, if all the old data had been preserved. bill --===============4869693909645953103==-- From glen.slick@gmail.com Sun Feb 12 21:44:22 2023 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] KDJ11-E M8981 11/93 EPROM firmware dump? Date: Sun, 12 Feb 2023 13:43:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0899974241109126679==" --===============0899974241109126679== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Anyone have a dump of the KDJ11-E M8981 11/93 EPROM firmware? That would be U106 377E7 V2.01 (I assume the full part number would have been 23-377E7) Don't see a copy at the obvious places to check: http://www.bitsavers.org/bits/DEC/pdp11/firmware/ http://www.dunnington.info/public/DECROMs/ --===============0899974241109126679==-- From drb@msu.edu Sun Feb 12 23:08:20 2023 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: KDJ11-E M8981 11/93 EPROM firmware dump? Date: Sun, 12 Feb 2023 18:07:42 -0500 Message-ID: <20230212230742.D3072243F33@yagi.h-net.msu.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2564212801180661164==" --===============2564212801180661164== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Anyone have a dump of the KDJ11-E M8981 11/93 EPROM firmware? > That would be U106 377E7 V2.01 (I assume the full part number would > have been 23-377E7) size 65536 sha256sum f3a4a9932c99a316709ae3f34580478d16b0498ad5af1809f7e7193417498618 url https://yagi.h-net.org/1193_u106_ha9908_377e7_v201_dec99.bin size 5376565 sha256sum 798fee4249139ea613af4a76711e5ab08d32e67d0bdd3bd91b8269f99f8689fe url https://yagi.h-net.org/1193v2rom.jpg De --===============2564212801180661164==-- From cc@informatik.uni-stuttgart.de Mon Feb 13 08:46:26 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: SDF had put a PDP-10 on the Internet Date: Mon, 13 Feb 2023 09:46:14 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2005908128766293231==" --===============2005908128766293231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 11 Feb 2023, Tarek Hoteit wrote: > Ok let me answer that about sdf.org. I joined as a member last year. > What I am saying below is what I learned along the way. It is a [...] Thank you for your insight information, I really appreciate it :-) Christian --===============2005908128766293231==-- From g4ajq1@gmail.com Tue Feb 14 01:05:45 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Mon, 13 Feb 2023 20:05:38 -0500 Message-ID: <16597337-ca5d-c222-b50e-a8e1ac6d11c6@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0073124300715994964==" --===============0073124300715994964== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Chris, I don't suppose you have the part number for suitable replacement bearings, do you? I have cleaned out the sensor wheel but still the same problem - but when i give the idler wheel a little push it at least goes to ready. cheers, Nigel On 2023-02-08 10:49, Chris Zach via cctalk wrote: > I think it's metal, but using a bit of good old soapy water and a > rinse/dry should be fine. Remember that there is a little window > screen part there to ensure the optical system only sees the slit > right under it, don't forget to install it as well. > > Glad to hear there is progress. Let us know how it works out! > > C > > On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: >> Well, I found dust and what looks like oil on the optical wheel.  It >> looks like somebody may have tried to lube the bearings in situ and >> used too much oil :-( >> >> I'm amused to see that it uses the same moiré principle that was used >> way back in the RK05! >> >> Do you know if the pattern on the wheel is purely cut out, or is >> there any photographic film involved?  I think the only possible >> solution would be to clean it with isopropyl, but useless to do that >> if it is film. -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============0073124300715994964==-- From cz@beaker.crystel.com Tue Feb 14 14:29:32 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Mon, 13 Feb 2023 21:31:45 -0500 Message-ID: <7a1e8113-9c1e-2a90-640f-ec7cf39e201f@beaker.crystel.com> In-Reply-To: <16597337-ca5d-c222-b50e-a8e1ac6d11c6@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6448888972037870436==" --===============6448888972037870436== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit No I don't. I just lubricate them. Odd though, did you turn the nut down the same number of turns and is the capstain dragging on the tape? C On 2/13/2023 8:05 PM, Nigel Johnson Ham via cctalk wrote: > Chris, I don't suppose you have the part number for suitable replacement > bearings, do you? I have cleaned out the sensor wheel but still the same > problem - but when i give the idler wheel a little push it at least goes > to ready. > > cheers, > > Nigel > > > On 2023-02-08 10:49, Chris Zach via cctalk wrote: >> I think it's metal, but using a bit of good old soapy water and a >> rinse/dry should be fine. Remember that there is a little window >> screen part there to ensure the optical system only sees the slit >> right under it, don't forget to install it as well. >> >> Glad to hear there is progress. Let us know how it works out! >> >> C >> >> On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: >>> Well, I found dust and what looks like oil on the optical wheel.  It >>> looks like somebody may have tried to lube the bearings in situ and >>> used too much oil :-( >>> >>> I'm amused to see that it uses the same moiré principle that was used >>> way back in the RK05! >>> >>> Do you know if the pattern on the wheel is purely cut out, or is >>> there any photographic film involved?  I think the only possible >>> solution would be to clean it with isopropyl, but useless to do that >>> if it is film. > --===============6448888972037870436==-- From cz@alembic.crystel.com Tue Feb 14 14:59:00 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Tue, 14 Feb 2023 09:58:55 -0500 Message-ID: In-Reply-To: <7a1e8113-9c1e-2a90-640f-ec7cf39e201f@beaker.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7189790207310605433==" --===============7189790207310605433== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Looking at my notes I found a similar situation: Tape would not load properly. Turned the rear nut 1/2 turn in, and it loaded. Then it would not read, turning the front nut down 1/2 turn allowed it to do proper reads and restores from an already-written tape. I think there is an oscilliscope method of setting the capstain height out there somewhere, but this "barn door" method works for me as well. C On 2/13/2023 9:31 PM, Chris Zach via cctalk wrote: > No I don't. I just lubricate them. Odd though, did you turn the nut down > the same number of turns and is the capstain dragging on the tape? > > C > > On 2/13/2023 8:05 PM, Nigel Johnson Ham via cctalk wrote: >> Chris, I don't suppose you have the part number for suitable >> replacement bearings, do you? I have cleaned out the sensor wheel but >> still the same problem - but when i give the idler wheel a little push >> it at least goes to ready. >> >> cheers, >> >> Nigel >> >> >> On 2023-02-08 10:49, Chris Zach via cctalk wrote: >>> I think it's metal, but using a bit of good old soapy water and a >>> rinse/dry should be fine. Remember that there is a little window >>> screen part there to ensure the optical system only sees the slit >>> right under it, don't forget to install it as well. >>> >>> Glad to hear there is progress. Let us know how it works out! >>> >>> C >>> >>> On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: >>>> Well, I found dust and what looks like oil on the optical wheel.  It >>>> looks like somebody may have tried to lube the bearings in situ and >>>> used too much oil :-( >>>> >>>> I'm amused to see that it uses the same moiré principle that was >>>> used way back in the RK05! >>>> >>>> Do you know if the pattern on the wheel is purely cut out, or is >>>> there any photographic film involved?  I think the only possible >>>> solution would be to clean it with isopropyl, but useless to do that >>>> if it is film. >> --===============7189790207310605433==-- From g4ajq1@gmail.com Tue Feb 14 15:35:28 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Tue, 14 Feb 2023 10:35:22 -0500 Message-ID: <37a95e5e-50ac-e16a-84c3-f21dcbd1eb04@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3420578326674144328==" --===============3420578326674144328== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Unfortunately, I had already removed the nut before you warned me about that in a previous email. However I did try various adjustments of that nut with disappointing results.  Maybe I will try doing it many different settings!  I did compare it to the position of the hut in a TK50 and it was about the same. I can feel a definite rubbing in the idler, but I will keep trying. I can visualise that the sensor slots must be the correct height to give a good since wave. thanks Nigel On 2023-02-14 09:58, Chris Zach via cctalk wrote: > Looking at my notes I found a similar situation: Tape would not load > properly. Turned the rear nut 1/2 turn in, and it loaded. Then it > would not read, turning the front nut down 1/2 turn allowed it to do > proper reads and restores from an already-written tape. > > I think there is an oscilliscope method of setting the capstain height > out there somewhere, but this "barn door" method works for me as well. > > C > > > On 2/13/2023 9:31 PM, Chris Zach via cctalk wrote: >> No I don't. I just lubricate them. Odd though, did you turn the nut >> down the same number of turns and is the capstain dragging on the tape? >> >> C >> >> On 2/13/2023 8:05 PM, Nigel Johnson Ham via cctalk wrote: >>> Chris, I don't suppose you have the part number for suitable >>> replacement bearings, do you? I have cleaned out the sensor wheel >>> but still the same problem - but when i give the idler wheel a >>> little push it at least goes to ready. >>> >>> cheers, >>> >>> Nigel >>> >>> >>> On 2023-02-08 10:49, Chris Zach via cctalk wrote: >>>> I think it's metal, but using a bit of good old soapy water and a >>>> rinse/dry should be fine. Remember that there is a little window >>>> screen part there to ensure the optical system only sees the slit >>>> right under it, don't forget to install it as well. >>>> >>>> Glad to hear there is progress. Let us know how it works out! >>>> >>>> C >>>> >>>> On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: >>>>> Well, I found dust and what looks like oil on the optical wheel.  >>>>> It looks like somebody may have tried to lube the bearings in situ >>>>> and used too much oil :-( >>>>> >>>>> I'm amused to see that it uses the same moiré principle that was >>>>> used way back in the RK05! >>>>> >>>>> Do you know if the pattern on the wheel is purely cut out, or is >>>>> there any photographic film involved?  I think the only possible >>>>> solution would be to clean it with isopropyl, but useless to do >>>>> that if it is film. >>> -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============3420578326674144328==-- From cz@beaker.crystel.com Tue Feb 14 20:33:02 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Tue, 14 Feb 2023 11:02:42 -0500 Message-ID: In-Reply-To: <37a95e5e-50ac-e16a-84c3-f21dcbd1eb04@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6636576728864622080==" --===============6636576728864622080== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I'm finding 5.5 to 6 turns is a pretty solid constant. Try going down that much on each one, then going 1/2 turn in, 1/2 out, and down in 1/2 increments. C On 2/14/2023 10:35 AM, Nigel Johnson Ham via cctalk wrote: > Unfortunately, I had already removed the nut before you warned me about > that in a previous email. However I did try various adjustments of that > nut with disappointing results.  Maybe I will try doing it many > different settings!  I did compare it to the position of the hut in a > TK50 and it was about the same. > I can feel a definite rubbing in the idler, but I will keep trying. I > can visualise that the sensor slots must be the correct height to give a > good since wave. > > thanks > Nigel > > > On 2023-02-14 09:58, Chris Zach via cctalk wrote: >> Looking at my notes I found a similar situation: Tape would not load >> properly. Turned the rear nut 1/2 turn in, and it loaded. Then it >> would not read, turning the front nut down 1/2 turn allowed it to do >> proper reads and restores from an already-written tape. >> >> I think there is an oscilliscope method of setting the capstain height >> out there somewhere, but this "barn door" method works for me as well. >> >> C >> >> >> On 2/13/2023 9:31 PM, Chris Zach via cctalk wrote: >>> No I don't. I just lubricate them. Odd though, did you turn the nut >>> down the same number of turns and is the capstain dragging on the tape? >>> >>> C >>> >>> On 2/13/2023 8:05 PM, Nigel Johnson Ham via cctalk wrote: >>>> Chris, I don't suppose you have the part number for suitable >>>> replacement bearings, do you? I have cleaned out the sensor wheel >>>> but still the same problem - but when i give the idler wheel a >>>> little push it at least goes to ready. >>>> >>>> cheers, >>>> >>>> Nigel >>>> >>>> >>>> On 2023-02-08 10:49, Chris Zach via cctalk wrote: >>>>> I think it's metal, but using a bit of good old soapy water and a >>>>> rinse/dry should be fine. Remember that there is a little window >>>>> screen part there to ensure the optical system only sees the slit >>>>> right under it, don't forget to install it as well. >>>>> >>>>> Glad to hear there is progress. Let us know how it works out! >>>>> >>>>> C >>>>> >>>>> On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: >>>>>> Well, I found dust and what looks like oil on the optical wheel. >>>>>> It looks like somebody may have tried to lube the bearings in situ >>>>>> and used too much oil :-( >>>>>> >>>>>> I'm amused to see that it uses the same moiré principle that was >>>>>> used way back in the RK05! >>>>>> >>>>>> Do you know if the pattern on the wheel is purely cut out, or is >>>>>> there any photographic film involved?  I think the only possible >>>>>> solution would be to clean it with isopropyl, but useless to do >>>>>> that if it is film. >>>> > --===============6636576728864622080==-- From g4ajq1@gmail.com Tue Feb 14 20:55:30 2023 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Tue, 14 Feb 2023 15:55:23 -0500 Message-ID: <82531c38-3d60-8bb3-458a-103eef8266bf@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5393531829930894736==" --===============5393531829930894736== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2023-02-14 11:02, Chris Zach via cctalk wrote: > I'm finding 5.5 to 6 turns is a pretty solid constant. Try going down > that much on each one, then going 1/2 turn in, 1/2 out, and down in > 1/2 increments. > > C > > On 2/14/2023 10:35 AM, Nigel Johnson Ham via cctalk wrote: >> Unfortunately, I had already removed the nut before you warned me >> about that in a previous email. However I did try various adjustments >> of that nut with disappointing results.  Maybe I will try doing it >> many different settings!  I did compare it to the position of the hut >> in a TK50 and it was about the same. >> I can feel a definite rubbing in the idler, but I will keep trying. I >> can visualise that the sensor slots must be the correct height to >> give a good since wave. >> >> thanks >> Nigel >> >> >> On 2023-02-14 09:58, Chris Zach via cctalk wrote: >>> Looking at my notes I found a similar situation: Tape would not load >>> properly. Turned the rear nut 1/2 turn in, and it loaded. Then it >>> would not read, turning the front nut down 1/2 turn allowed it to do >>> proper reads and restores from an already-written tape. >>> >>> I think there is an oscilliscope method of setting the capstain >>> height out there somewhere, but this "barn door" method works for me >>> as well. >>> >>> C >>> >>> >>> On 2/13/2023 9:31 PM, Chris Zach via cctalk wrote: >>>> No I don't. I just lubricate them. Odd though, did you turn the nut >>>> down the same number of turns and is the capstain dragging on the >>>> tape? >>>> >>>> C >>>> >>>> On 2/13/2023 8:05 PM, Nigel Johnson Ham via cctalk wrote: >>>>> Chris, I don't suppose you have the part number for suitable >>>>> replacement bearings, do you? I have cleaned out the sensor wheel >>>>> but still the same problem - but when i give the idler wheel a >>>>> little push it at least goes to ready. >>>>> >>>>> cheers, >>>>> >>>>> Nigel >>>>> >>>>> >>>>> On 2023-02-08 10:49, Chris Zach via cctalk wrote: >>>>>> I think it's metal, but using a bit of good old soapy water and a >>>>>> rinse/dry should be fine. Remember that there is a little window >>>>>> screen part there to ensure the optical system only sees the slit >>>>>> right under it, don't forget to install it as well. >>>>>> >>>>>> Glad to hear there is progress. Let us know how it works out! >>>>>> >>>>>> C >>>>>> >>>>>> On 2/8/2023 10:06 AM, Nigel Johnson Ham via cctalk wrote: >>>>>>> Well, I found dust and what looks like oil on the optical wheel. >>>>>>> It looks like somebody may have tried to lube the bearings in >>>>>>> situ and used too much oil :-( >>>>>>> >>>>>>> I'm amused to see that it uses the same moiré principle that was >>>>>>> used way back in the RK05! >>>>>>> >>>>>>> Do you know if the pattern on the wheel is purely cut out, or is >>>>>>> there any photographic film involved?  I think the only possible >>>>>>> solution would be to clean it with isopropyl, but useless to do >>>>>>> that if it is film. >>>>> >> Well after fiddling all day, I managed to get it to load and unload tape five times, and that is a first! In the end, I ran the nut back and forth and found two points beyond which it would lose tension, then set it midway between those two points. Just went to put it back in MicroVax2 and found I had pulled the power connector right off the power supply, so will  need to move some furniture and pull out the system to fix that - tomorrow! In the end I used one drop of Braun electric shaver lube, and found a miraculous metal cleaner from Germany, called Winkel reinigungsspray! I'll post when I have it running! thanks for all your help, Without your advice I would not have been so persistent in arriving at the end result! Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============5393531829930894736==-- From silent700@gmail.com Tue Feb 14 22:54:28 2023 From: Jason T To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Tue, 14 Feb 2023 16:54:13 -0600 Message-ID: In-Reply-To: <20230210223303.43094748@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0801853101424685105==" --===============0801853101424685105== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Feb 11, 2023 at 1:58 AM Paul Flo Williams via cctalk wrote: > During lockdown I was having some fun redrawing old DEC manual covers > with Inkscape, specifically terminal and printer manuals from the late > 1970s. I've attached a montage of four that I printed out so I could > stick it on the wall. I'm aware I may be the only person, even here, > who finds them attractively simple and coloured in such a definably > 1970s way. Let me add my "plus one" here! I appreciate both the original designs and your faithful reproductions. Did you use a font for the cover texts or recreate them by hand? I know DEC was making heavy use of Avant Garde Bold during this period, including the alternate glyphs here and there (I have a document in my near-term scan queue that shows how NOT to use those glyphs!) IIRC, the corporate style guide specifies AVGB and some form of Helvetica for advertising and documentation use. IBM's 1960s and 70s covers were fun, too, although a completely different style. Mostly geometric designs that remind me of textbooks from that era. -j --===============0801853101424685105==-- From bfranchuk@jetnet.ab.ca Tue Feb 14 23:51:32 2023 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Late '70s DEC manual covers [niche!] Date: Tue, 14 Feb 2023 16:51:20 -0700 Message-ID: <3e0c35c1-f207-370e-e6d3-5734cd11947d@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1421499604427397652==" --===============1421499604427397652== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2023-02-14 3:54 p.m., Jason T via cctalk wrote: > IBM's 1960s and 70s covers were fun, too, although a completely > different style. Mostly geometric designs that remind me of textbooks > from that era. > > -j I would like to say, "From mushrooms of that era". The mid 70's seem to be point where textbooks went from "HOW to use the XXX 1234 punch card computer" to real Computer Science books like "Programing in A-Z for average student" Ben. --===============1421499604427397652==-- From lewissa78@gmail.com Wed Feb 15 06:45:29 2023 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Wed, 15 Feb 2023 00:45:12 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2962733562150269401==" --===============2962733562150269401== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wait, are Web Rings going to come back into fashion? :D Speaking of shady vintage websites, what the heck is up with this guy trying to sell a late model IBM laptop for more than an Apple-1 ? Is that Hunter's laptop? https://www.ebay.com/itm/183849347474 On Fri, Feb 10, 2023 at 10:15 AM Ethan O'Toole via cctalk < cctalk(a)classiccmp.org> wrote: > > I would be interested in knowing some of those options. > > Thanks, > > Will > > Brave Search / Brave Browser is one. > > Yandex is a Russian search engine that can come in useful sometimes. > > Trying to find ISO CD images of discs for music hardware (Samplers) it > feels like the internet through google is way smaller than it used to be. > > The bad thing is there is a ton of knowledge on facebook that isn't > indexed to the public web. > > > -- > : Ethan O'Toole > > > --===============2962733562150269401==-- From tarek@infocom.ai Wed Feb 15 18:04:30 2023 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Wed, 15 Feb 2023 10:04:07 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5397782899260639725==" --===============5397782899260639725== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Seems click bait to me. The store has only 1 item listed and 809 reviews. 165= watchers too. If we have 165 watchers interesting in this thinkpad (which by= the way one was sold with 15bid for $232 https://www.ebay.com/itm/1449275846= 35) then maybe that 818,888 (notice the flowers too in the listing) than I as= sume at least one is in this group. Seems to me the listing is a sarcastic or= insulting way to recognize vintage tech=20 Regards, Tarek Hoteit > On Feb 14, 2023, at 10:45 PM, Steve Lewis via cctalk wrote: >=20 > =EF=BB=BFWait, are Web Rings going to come back into fashion? :D >=20 > Speaking of shady vintage websites, what the heck is up with this guy > trying to sell a late model IBM laptop for more than an Apple-1 ? Is that > Hunter's laptop? > https://www.ebay.com/itm/183849347474 >=20 >=20 >=20 >=20 > On Fri, Feb 10, 2023 at 10:15 AM Ethan O'Toole via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 >>> I would be interested in knowing some of those options. >>> Thanks, >>> Will >>=20 >> Brave Search / Brave Browser is one. >>=20 >> Yandex is a Russian search engine that can come in useful sometimes. >>=20 >> Trying to find ISO CD images of discs for music hardware (Samplers) it >> feels like the internet through google is way smaller than it used to be. >>=20 >> The bad thing is there is a ton of knowledge on facebook that isn't >> indexed to the public web. >>=20 >>=20 >> -- >> : Ethan O'Toole >>=20 >>=20 >>=20 --===============5397782899260639725==-- From tarek@infocom.ai Wed Feb 15 18:08:25 2023 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: Store with "vintage" computers and parts Date: Wed, 15 Feb 2023 10:08:05 -0800 Message-ID: <24B1C1CA-433E-48DA-9149-58C7DD5EB4AD@infocom.ai> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8881762466198203990==" --===============8881762466198203990== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry folks for all the typos in my last post.=20 Regards, Tarek Hoteit > On Feb 15, 2023, at 10:04 AM, Tarek Hoteit via cctalk wrote: >=20 > =EF=BB=BFSeems click bait to me. The store has only 1 item listed and 809 r= eviews. 165 watchers too. If we have 165 watchers interesting in this thinkpa= d (which by the way one was sold with 15bid for $232 https://www.ebay.com/itm= /144927584635) then maybe that 818,888 (notice the flowers too in the listing= ) than I assume at least one is in this group. Seems to me the listing is a s= arcastic or insulting way to recognize vintage tech=20 >=20 > Regards, > Tarek Hoteit >=20 >>> On Feb 14, 2023, at 10:45 PM, Steve Lewis via cctalk wrote: >>>=20 >> =EF=BB=BFWait, are Web Rings going to come back into fashion? :D >>=20 >> Speaking of shady vintage websites, what the heck is up with this guy >> trying to sell a late model IBM laptop for more than an Apple-1 ? Is that >> Hunter's laptop? >> https://www.ebay.com/itm/183849347474 >>=20 >>=20 >>=20 >>=20 >> On Fri, Feb 10, 2023 at 10:15 AM Ethan O'Toole via cctalk < >> cctalk(a)classiccmp.org> wrote: >>=20 >>>> I would be interested in knowing some of those options. >>>> Thanks, >>>> Will >>>=20 >>> Brave Search / Brave Browser is one. >>>=20 >>> Yandex is a Russian search engine that can come in useful sometimes. >>>=20 >>> Trying to find ISO CD images of discs for music hardware (Samplers) it >>> feels like the internet through google is way smaller than it used to be. >>>=20 >>> The bad thing is there is a ton of knowledge on facebook that isn't >>> indexed to the public web. >>>=20 >>>=20 >>> -- >>> : Ethan O'Toole >>>=20 >>>=20 >>>=20 --===============8881762466198203990==-- From tosteve@yahoo.com Wed Feb 15 19:39:27 2023 From: steven stengel To: cctalk@classiccmp.org Subject: [cctalk] Wanted: Apple III 5MB Profile HD driver file Date: Wed, 15 Feb 2023 19:38:55 +0000 Message-ID: <401001799.2216652.1676489935807@mail.yahoo.com> In-Reply-To: <401001799.2216652.1676489935807.ref@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9156741991268742350==" --===============9156741991268742350== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BFThe title says it all - the Apple III has an external hard drive cal= led the Profile, but a driver has to be installed on the boot floppy - it won= =E2=80=99t boot from the HD. There were also 10MB Profiles, with a different = driver file I=E2=80=99m guessing.=C2=A0 I have the driver file for the 10MB, but it doesn't seem to work with my 5MB = drive. Please help if you can. Thanks- Steve. --===============9156741991268742350==-- From billdegnan@gmail.com Thu Feb 16 01:18:57 2023 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Wanted: Apple III 5MB Profile HD driver file Date: Wed, 15 Feb 2023 20:18:41 -0500 Message-ID: In-Reply-To: <401001799.2216652.1676489935807@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6722367831635944045==" --===============6722367831635944045== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have a few profile hardware driver/diagnostics disks but none specify the size of the drive on the disk, What version do you have? Bill Degnan On Wed, Feb 15, 2023 at 2:39 PM steven stengel via cctalk < cctalk(a)classiccmp.org> wrote: > The title says it all - the Apple III has an external hard drive called > the Profile, but a driver has to be installed on the boot floppy - it won= =E2=80=99t > boot from the HD. There were also 10MB Profiles, with a different driver > file I=E2=80=99m guessing. > > I have the driver file for the 10MB, but it doesn't seem to work with my > 5MB drive. Please help if you can. > Thanks- > Steve. > --===============6722367831635944045==-- From tosteve@yahoo.com Thu Feb 16 05:08:41 2023 From: Steven Stengel To: cctalk@classiccmp.org Subject: [cctalk] Re: Wanted: Apple III 5MB Profile HD driver file Date: Wed, 15 Feb 2023 21:08:25 -0800 Message-ID: <9E44E3FD-E052-49CA-BDF6-7415A4FB7D54@yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3475522502382078926==" --===============3475522502382078926== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Bill, I actually got it working. All of the driver floppy disks had 10MB written in= them in pen, but they worked ok with the 5MB Profile. I also had to try a di= fferent I/O card to get it working.=20 Steve.=20 On Feb 15, 2023, at 5:18 PM, Bill Degnan via cctalk = wrote: =EF=BB=BFI have a few profile hardware driver/diagnostics disks but none spec= ify the size of the drive on the disk, What version do you have? Bill Degnan On Wed, Feb 15, 2023 at 2:39 PM steven stengel via cctalk < cctalk(a)classiccmp.org> wrote: > The title says it all - the Apple III has an external hard drive called > the Profile, but a driver has to be installed on the boot floppy - it won= =E2=80=99t > boot from the HD. There were also 10MB Profiles, with a different driver > file I=E2=80=99m guessing. >=20 > I have the driver file for the 10MB, but it doesn't seem to work with my > 5MB drive. Please help if you can. > Thanks- > Steve. >=20 --===============3475522502382078926==-- From billdegnan@gmail.com Thu Feb 16 14:42:16 2023 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Wanted: Apple III 5MB Profile HD driver file Date: Thu, 16 Feb 2023 09:41:57 -0500 Message-ID: In-Reply-To: <9E44E3FD-E052-49CA-BDF6-7415A4FB7D54@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9034267961942284441==" --===============9034267961942284441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Gotcha. I have a pretty large set of III docs if you need anything. I was planning to put online, it's all scanned, etc. just have not gotten to it yet :-( BIll On Thu, Feb 16, 2023 at 12:08 AM Steven Stengel via cctalk < cctalk(a)classiccmp.org> wrote: > Thanks Bill, > I actually got it working. All of the driver floppy disks had 10MB written > in them in pen, but they worked ok with the 5MB Profile. I also had to try > a different I/O card to get it working. > Steve. > > > On Feb 15, 2023, at 5:18 PM, Bill Degnan via cctalk > wrote: > > =EF=BB=BFI have a few profile hardware driver/diagnostics disks but none sp= ecify > the > size of the drive on the disk, What version do you have? > Bill Degnan > > On Wed, Feb 15, 2023 at 2:39 PM steven stengel via cctalk < > cctalk(a)classiccmp.org> wrote: > > > The title says it all - the Apple III has an external hard drive called > > the Profile, but a driver has to be installed on the boot floppy - it > won=E2=80=99t > > boot from the HD. There were also 10MB Profiles, with a different driver > > file I=E2=80=99m guessing. > > > > I have the driver file for the 10MB, but it doesn't seem to work with my > > 5MB drive. Please help if you can. > > Thanks- > > Steve. > > > > --===============9034267961942284441==-- From david4602@gmail.com Thu Feb 16 18:28:37 2023 From: David Schmidt To: cctalk@classiccmp.org Subject: [cctalk] Re: Wanted: Apple III 5MB Profile HD driver file Date: Thu, 16 Feb 2023 18:28:33 +0000 Message-ID: <167657211371.1516385.12546826550155020796@classiccmp.org> In-Reply-To: <401001799.2216652.1676489935807@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1235578232588590679==" --===============1235578232588590679== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Generally, a ProFile driver that is otherwise unspecified will be 5MB (i.e. h= ttps://apple3.org/iiisoftware.html#drivers ). There is a different card (ROM= ?) as you found out that will matter for 5 vs. 10MB variants and driver files. Good luck keeping that jet engine spooled up! - David --===============1235578232588590679==-- From cz@alembic.crystel.com Fri Feb 17 00:54:06 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Matrox Q bus graphics card, any use Date: Thu, 16 Feb 2023 19:54:00 -0500 Message-ID: <0fe9f81b-8253-f155-8fb5-16d834bb8272@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2990739218959803137==" --===============2990739218959803137== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Going through my stuff I found a Matrox QRGB 6/64-4 card which seems to be a 512x512x16 color video array for Q bus systems. Did any software ever support this thing, and does anyone want to trade it for a bean of some sort? Thanks! Chris --===============2990739218959803137==-- From healyzh@avanthar.com Fri Feb 17 03:37:39 2023 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Matrox Q bus graphics card, any use Date: Thu, 16 Feb 2023 19:37:20 -0800 Message-ID: <78ACCAD4-3A5B-4A12-9647-912458991428@avanthar.com> In-Reply-To: <0fe9f81b-8253-f155-8fb5-16d834bb8272@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5419020247993275193==" --===============5419020247993275193== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think that drivers should exist for RSX-11M+. I=E2=80=99m unaware of anyth= ing available online. I should have a RSX-11M pack with graphics drivers, bu= t for a different card, not Matrox. Zane > On Feb 16, 2023, at 4:54 PM, Chris Zach via cctalk wrote: >=20 > =EF=BB=BFGoing through my stuff I found a Matrox QRGB 6/64-4 card which see= ms to be a 512x512x16 color video array for Q bus systems. >=20 > Did any software ever support this thing, and does anyone want to trade it = for a bean of some sort? >=20 > Thanks! > Chris --===============5419020247993275193==-- From legalize@xmission.com Fri Feb 17 06:05:53 2023 From: Richard To: cctalk@classiccmp.org Subject: [cctalk] Re: Matrox Q bus graphics card, any use Date: Thu, 16 Feb 2023 22:24:19 -0700 Message-ID: In-Reply-To: <0fe9f81b-8253-f155-8fb5-16d834bb8272@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3272301432259375754==" --===============3272301432259375754== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In article <0fe9f81b-8253-f155-8fb5-16d834bb8272(a)alembic.crystel.com>, "Chris Zach via cctalk" writes: > Going through my stuff I found a Matrox QRGB 6/64-4 card which seems to=20 > be a 512x512x16 color video array for Q bus systems. This card? > Did any software ever support this thing, and does anyone want to trade=20 > it for a bean of some sort? Software would likely be custom for the card. DEC did have an implementation of GKS for VMS and had the ability for users to write their own GKS drivers for custom hardware, which would give you a portable API that could use the hardware if such a driver were available. This card's resolution is comparable to a mid 80s Tektronix raster terminal, such as the Tek 4207 or Tek 4205. The terminals have a much more sophisticated command set than this card, however. --=20 "The Direct3D Graphics Pipeline" free book The Terminals Wiki The Computer Graphics Museum Legalize Adulthood! (my blog) --===============3272301432259375754==-- From classiccmp@philpem.me.uk Sun Feb 19 04:10:39 2023 From: Phil Pemberton To: cctalk@classiccmp.org Subject: [cctalk] Looking for info on Jerrold/General Instrument PDP11/DEC/etc. software/hardware Date: Sun, 19 Feb 2023 03:51:29 +0000 Message-ID: <1cce3f85-d779-1b22-9874-36b710b0a066@philpem.me.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7998820265843463360==" --===============7998820265843463360== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all, I know there are a few PDP enthusiasts here so I figured this was worth an ask! I'm looking for any software, manuals, photos of hardware - anything really - that relates to the Jerrold Communications / General Instrument analog cable TV headend equipment. Many of their headend "addressable controllers" were built around DEC hardware -- the AH series units used a PDP-11, the Terminal Configurator ran on a PC, the ACC-4000 ran on a DEC Prioris server running SCO UNIX. Things I'm looking for especially -- - The software from the ACC-4000 Addressable Controller (Prioris based), AI-0/AI-O or AH-4/AH-4E (PDP-11/73 based) controllers, or Terminal Configurator (PC based). - Backup tapes from a running system (may be TK50, or DAT/DDS) - Terminal Configurator, Message Editor (ME-1000) or "OSD Edit" software - Any documentation - Photos, or other details of the I/O cards (either the PC one - which may have been called ANIC - or the SCX11, SCX11E, SCX11M or SRT11 cards used in the PDP systems). I'm trying to build an analog cable TV headend from scratch, as a bit of a preservation and "to see if I can" project. So far I've managed to modulate a couple of channels and get a cable box to tune to them, but my two boxes have different frequency maps, and I need some way of sending an "Input Frequency Map" or channel name table to them. I'm hoping that someone might have inherited a bunch of backup tapes, hardware or media from a cable TV company who was migrating to digital.... Thanks, -- Phil. philpem(a)philpem.me.uk https://www.philpem.me.uk/ --===============7998820265843463360==-- From alexandre.tabajara@gmail.com Sun Feb 19 04:19:49 2023 From: Alexandre Souza To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for info on Jerrold/General Instrument PDP11/DEC/etc. software/hardware Date: Sun, 19 Feb 2023 01:19:36 -0300 Message-ID: In-Reply-To: <1cce3f85-d779-1b22-9874-36b710b0a066@philpem.me.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5229067958927650793==" --===============5229067958927650793== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit That will be great to follow... Enviado do meu Tele-Movel Em dom., 19 de fev. de 2023 01:10, Phil Pemberton via cctalk < cctalk(a)classiccmp.org> escreveu: > Hi all, > > I know there are a few PDP enthusiasts here so I figured this was worth > an ask! > > I'm looking for any software, manuals, photos of hardware - anything > really - that relates to the Jerrold Communications / General Instrument > analog cable TV headend equipment. > Many of their headend "addressable controllers" were built around DEC > hardware -- the AH series units used a PDP-11, the Terminal Configurator > ran on a PC, the ACC-4000 ran on a DEC Prioris server running SCO UNIX. > > Things I'm looking for especially -- > > - The software from the ACC-4000 Addressable Controller (Prioris > based), AI-0/AI-O or AH-4/AH-4E (PDP-11/73 based) controllers, or > Terminal Configurator (PC based). > > - Backup tapes from a running system (may be TK50, or DAT/DDS) > > - Terminal Configurator, Message Editor (ME-1000) or "OSD Edit" software > > - Any documentation > > - Photos, or other details of the I/O cards (either the PC one - > which may have been called ANIC - or the SCX11, SCX11E, SCX11M or SRT11 > cards used in the PDP systems). > > > > I'm trying to build an analog cable TV headend from scratch, as a bit of > a preservation and "to see if I can" project. > So far I've managed to modulate a couple of channels and get a cable box > to tune to them, but my two boxes have different frequency maps, and I > need some way of sending an "Input Frequency Map" or channel name table > to them. > > I'm hoping that someone might have inherited a bunch of backup tapes, > hardware or media from a cable TV company who was migrating to digital.... > > Thanks, > -- > Phil. > philpem(a)philpem.me.uk > https://www.philpem.me.uk/ > --===============5229067958927650793==-- From cz@beaker.crystel.com Mon Feb 20 06:49:20 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] DEQNA vs DELQA bulkhead question Date: Sun, 19 Feb 2023 22:19:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2669433211631040901==" --===============2669433211631040901== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Working on my second pdp11/73 here and trying to get Ethernet working with a DEQNA instead of a Delqa. I'm using a DELQA card to AUI connector, the board passes diagnostics without the loopback, but when I try to bring it up I get: Event type 5.14, Send failed Occurred 17-FEB-2023 22:15:05 on node 1.20 (TALOS) Line QNA-0 Failure reason = Collision detect check failed Is the connector for the DELQA different from the DEQNA? My other system has a DELQA with a DEQNA connector and it seems to work fine. I could put another DELQA in, but I want to see if these DEQNAs work. Or do I need to enable SQE on the AUI adapter? Thanks! C --===============2669433211631040901==-- From cz@beaker.crystel.com Mon Feb 20 06:51:11 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: TK50/70 Repair Date: Sun, 19 Feb 2023 12:18:28 -0500 Message-ID: <53e14ef0-940e-a3a1-abdd-ad458dd9699d@beaker.crystel.com> In-Reply-To: <82531c38-3d60-8bb3-458a-103eef8266bf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8938258759929513868==" --===============8938258759929513868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Side note on this: I managed to format one of these RD54's, then used the TK70 to boot up BRUSYS from tape and restore a backup of my main ESDI system TALOS. RD54's are slower than ESDI. But it does work, and now I have RSXM+ running on two systems with TK70 drives for backup and file exchange :-) C --===============8938258759929513868==-- From paulkoning@comcast.net Mon Feb 20 14:03:38 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: DEQNA vs DELQA bulkhead question Date: Mon, 20 Feb 2023 09:03:31 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8388432942011910814==" --===============8388432942011910814== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 19, 2023, at 10:19 PM, Chris Zach via cctalk wrote: >=20 > Working on my second pdp11/73 here and trying to get Ethernet working with = a DEQNA instead of a Delqa. I'm using a DELQA card to AUI connector, the boar= d passes diagnostics without the loopback, but when I try to bring it up I ge= t: >=20 > Event type 5.14, Send failed > Occurred 17-FEB-2023 22:15:05 on node 1.20 (TALOS) > Line QNA-0 > Failure reason =3D Collision detect check failed >=20 > Is the connector for the DELQA different from the DEQNA? My other system ha= s a DELQA with a DEQNA connector and it seems to work fine. I could put anoth= er DELQA in, but I want to see if these DEQNAs work. >=20 > Or do I need to enable SQE on the AUI adapter? Yes, SQE is "collision detect check" so you should enable that. =20 paul --===============8388432942011910814==-- From tpisek@pobox.com Mon Feb 20 18:48:56 2023 From: Todd Pisek To: cctalk@classiccmp.org Subject: [cctalk] IBM RT PC Hardware Technical Ref Date: Mon, 20 Feb 2023 12:40:03 -0600 Message-ID: <02C289B9-871C-4F84-8CAB-63AAB86432AB@pobox.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5868904126808282361==" --===============5868904126808282361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have the 3 volume set of the RT PC Tech Ref and it needs a new home. I=E2= =80=99d prefer it winds up with someone that has a RT PC if possible. It=E2= =80=99s in pristine condition.=20 Please email off list to tpisek at pobox dot com.=20 Regards, Todd Pisek P.S. It=E2=80=99s fairly heavy, USPS media rate would be about $14. --===============5868904126808282361==-- From lars@nocrew.org Tue Feb 21 06:10:06 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] NeWS tapes in SF Bay area; rubber baby buggy bumpers Date: Tue, 21 Feb 2023 06:10:00 +0000 Message-ID: <7w4jrfzgzr.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2280149287387957823==" --===============2280149287387957823== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello, Some Sun 1/4" tapes with NeWS has turned up in the SF Bay area. However, the the tape drive available has bad rubber baby buggy bumpers. Is there anyone around there who can provide new bumpers, or has a working 1/4" tape drive and is willing to read the tapes? Best regards, Lars Brinkhoff --===============2280149287387957823==-- From dillera@dillernet.com Tue Feb 21 16:34:55 2023 From: Andrew Diller To: cctalk@classiccmp.org Subject: [cctalk] VCF East is coming up in April! Date: Tue, 21 Feb 2023 11:34:47 -0500 Message-ID: <0AE2046B-1E69-414A-83C3-5EF11B248603@dillernet.com> In-Reply-To: <7w4jrfzgzr.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7643480068919549992==" --===============7643480068919549992== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Please mark you calendars and consider attending! VCF East will take place in the spring of 2023 - April 14th, 15th, and 16th. = This is your chance to get up close and personal with vintage computers and l= earn about their history. You'll also have the opportunity to purchase rare a= nd unique computer parts and accessories.=20 VCF East will be held at the InfoAge Science & History Museums in Wall, NJ. C= ome join us and explore the world of computing from the past and it's relevan= cy in the present and future. https://social.vcfed.org/@admin/109903667531840578 -andy diller --===============7643480068919549992==-- From tpisek@pobox.com Wed Feb 22 03:13:59 2023 From: Todd Pisek To: cctalk@classiccmp.org Subject: [cctalk] IBM RT PC manuals have been claimed Date: Tue, 21 Feb 2023 21:13:49 -0600 Message-ID: <60E58AD6-B086-4866-95A5-62BFF5D8D4FB@pobox.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5315033543825392918==" --===============5315033543825392918== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Manuals have been claimed. Regards, Todd Pisek --===============5315033543825392918==-- From spacewar@gmail.com Wed Feb 22 04:48:45 2023 From: Eric Smith To: cctalk@classiccmp.org Subject: [cctalk] Re: Wanted: Apple III 5MB Profile HD driver file Date: Tue, 21 Feb 2023 21:48:28 -0700 Message-ID: In-Reply-To: <167657211371.1516385.12546826550155020796@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8776514096428401098==" --===============8776514096428401098== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Feb 16, 2023 at 11:28 AM David Schmidt via cctalk < cctalk(a)classiccmp.org> wrote: > Generally, a ProFile driver that is otherwise unspecified will be 5MB > (i.e. https://apple3.org/iiisoftware.html#drivers ). There is a > different card (ROM?) as you found out that will matter for 5 vs. 10MB > variants and driver files. > For the Apple ///, there isn't a different Profile interface card, and there's no firmware on the card. It's all a matter of what SOS driver is used. I thought the newer SOS driver supported both 5MB and 10MB drives, but perhaps I'm mistaken. The drivers generally come from the Apple /// System Utilities disk and System Utilities Data disks. For the Apple II, there's an interface card that is used for either the Profile 5MB or 10MB, but the early firmware 341-0271A, only knows about the 5MB Profile, and also doesn't work with interrupts, so it's not suitable for the Apple IIgs. The same card, but with 341-0299B firmware, supports both 5MB and 10MB Profiles and works on the Apple II, II+, IIe, and IIgs. There are a bunch of places on the internet that claim that you have to use 341-0271A firmware on the Apple II card if you have a 5MB Profile, but that is flat out wrong. The 341-0299B firmware should be used with both 5MB and 10MB Profiles. It will also work with third-party drives that support Profile protocol but may have different sizes, potentially up to 32MB. Profile trivia: The firmware _inside_ the Profile is strange in that it doesn't actually KNOW the size of the Profile it's installed into. At power up, when the drive reads the home block, the drive size is stored there. That's done when the drive is formatted. There is different formatter firmware for 5MB and 10MB drives. The Apple II Profile interface firmware contains a lot of dead code. Some of it looks vaguely like reasonable code, but some of it is clearly junk. --===============8776514096428401098==-- From cz@beaker.crystel.com Wed Feb 22 06:15:18 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: VCF East is coming up in April! Date: Tue, 21 Feb 2023 15:11:38 -0500 Message-ID: <4d997420-0387-8d5b-a42e-0bcee19fe525@beaker.crystel.com> In-Reply-To: <0AE2046B-1E69-414A-83C3-5EF11B248603@dillernet.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0629214527220932505==" --===============0629214527220932505== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That sounds like fun, and I haven't been to a swap meet since the days=20 of TCF in the 90's and early 2000's. Anyone want to swap an AF01 with 64 channel a/d for a BM08/L? We can=20 meet there to save on shipping and stuff. C On 2/21/2023 11:34 AM, Andrew Diller via cctalk wrote: > Please mark you calendars and consider attending! >=20 > VCF East will take place in the spring of 2023 - April 14th, 15th, and 16th= . This is your chance to get up close and personal with vintage computers and= learn about their history. You'll also have the opportunity to purchase rare= and unique computer parts and accessories. >=20 > VCF East will be held at the InfoAge Science & History Museums in Wall, NJ.= Come join us and explore the world of computing from the past and it's relev= ancy in the present and future. >=20 > https://social.vcfed.org/@admin/109903667531840578 >=20 > -andy diller >=20 --===============0629214527220932505==-- From lewissa78@gmail.com Wed Feb 22 07:17:11 2023 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] WTB Sharp PC-5000 Date: Wed, 22 Feb 2023 01:16:56 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3493145518019978915==" --===============3493145518019978915== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit If anyone knows of a Sharp PC-5000 that might be available. I've been looking for one for a while. Might be more in the Japanese or European vintage market? Prefer working, I've been curious about the MS DOS 2.0 ROM that it has. -Steve voidstar --===============3493145518019978915==-- From sellam.ismail@gmail.com Wed Feb 22 07:33:02 2023 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Sharp PC-5000 Date: Tue, 21 Feb 2023 23:32:45 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1006938733497526411==" --===============1006938733497526411== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Feb 21, 2023 at 11:17 PM Steve Lewis via cctalk < cctalk(a)classiccmp.org> wrote: > If anyone knows of a Sharp PC-5000 that might be available. > > I've been looking for one for a while. > > Might be more in the Japanese or European vintage market? > > Prefer working, I've been curious about the MS DOS 2.0 ROM that it has. > I used to have about 12-16 of these new in the box. When my collection was pilfered, these are among the items that were scattered to the wind. I'm guessing they're out there, somewhere, either in someone's garage or a storage locker. Someone on this list might even know. If you seek, you shall find. Sellam --===============1006938733497526411==-- From kl@2k.ca Wed Feb 22 14:50:48 2023 From: Kevin Lee To: cctalk@classiccmp.org Subject: [cctalk] Radio Shack TRS-80 Model 200 for Sale Date: Wed, 22 Feb 2023 15:28:58 +0100 Message-ID: <3154F80E-99F5-4C87-8E92-400A673E15C0@2k.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6903464804224011018==" --===============6903464804224011018== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Offers Welcome before I toss it in the bin.. thanks Kevin --===============6903464804224011018==-- From lists@glitchwrks.com Wed Feb 22 15:03:28 2023 From: Jonathan Chapman To: cctalk@classiccmp.org Subject: [cctalk] P&T Surplus in Kingston, NY Date: Wed, 22 Feb 2023 15:03:09 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4784685176357815781==" --===============4784685176357815781== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable All, I went to find a page about P&T Surplus to link to a friend who'd never been = there, and this was today's top result: https://www.dailyfreeman.com/2023/02/19/pt-surplus-in-kingston-struggles-as-o= wners-battle-illnesses-mounting-bills/ Apparently Mr. Smythe is having hard times with his business. For those in or= near the Hudson Valley, this place is definitely worth checking out! They ha= ve a ton of industrial surplus, including a lot of IBM castoffs. Pretty good shop for potential vintage computer stuff. Last time I was there = (early February 2023) there was a box of neon lamp IBM front panels off what = I'd guess was tabulating equipment. I always find good stuff in their board s= crap, though the edge connectors are sometimes sheared off. There seem to alw= ays be earlier IBM Thinkpads there, Pentium 3 and earlier are common finds. They also have lots of mechanical hardware, metals raw material, 80/20 extrus= ion for dirt cheap, etc. Thanks, Jonathan --===============4784685176357815781==-- From george.rachor@gmail.com Wed Feb 22 15:11:42 2023 From: George Rachor To: cctalk@classiccmp.org Subject: [cctalk] Re: Radio Shack TRS-80 Model 200 for Sale Date: Wed, 22 Feb 2023 06:55:13 -0800 Message-ID: In-Reply-To: <3154F80E-99F5-4C87-8E92-400A673E15C0@2k.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8094228790698918594==" --===============8094228790698918594== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Operational? Photos? Rough idea how much you want to ship to Oregon? George Rachor georgerachor(a)gmail.com > On Feb 22, 2023, at 6:28 AM, Kevin Lee via cctalk = wrote: >=20 > Offers Welcome before I toss it in the bin..=20 >=20 > thanks > Kevin=20 >=20 --===============8094228790698918594==-- From mhs.stein@gmail.com Wed Feb 22 17:01:38 2023 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Sharp PC-5000 Date: Wed, 22 Feb 2023 12:01:15 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4977232486781877676==" --===============4977232486781877676== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Pretty sure I have one somewhere, with manual and some bubble packs, working last time it was turned on. Located in Toronto; contact me off-list if interested. m On Wed, Feb 22, 2023 at 2:17 AM Steve Lewis via cctalk < cctalk(a)classiccmp.org> wrote: > If anyone knows of a Sharp PC-5000 that might be available. > > I've been looking for one for a while. > > Might be more in the Japanese or European vintage market? > > Prefer working, I've been curious about the MS DOS 2.0 ROM that it has. > > -Steve > voidstar > --===============4977232486781877676==-- From cz@beaker.crystel.com Wed Feb 22 18:35:01 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Stuff to go or it's off to the dumpster Date: Wed, 22 Feb 2023 12:19:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8396733272079834842==" --===============8396733272079834842== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all! Need to get rid of some things here that I am never going to use, maybe someone else will: M7705 M7706 M7906 M7907 M7908 Quad boards, I think they came from an RK06/07. Maybe the boards from an RK611? Regardless, I don't need them, they are either priceless or worthless. Make me an offer or I'll just let them go. SGI Hi-IMpact board. Not sure why I have this but here it is. Either pick up in MD or send me a shipping label. CZ --===============8396733272079834842==-- From paulkoning@comcast.net Wed Feb 22 19:37:10 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Stuff to go or it's off to the dumpster Date: Wed, 22 Feb 2023 14:36:58 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2539804343701650487==" --===============2539804343701650487== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 22, 2023, at 12:19 PM, Chris Zach via cctalk wrote: >=20 > Hi all! >=20 > Need to get rid of some things here that I am never going to use, maybe som= eone else will: >=20 > M7705 > M7706 > M7906 > M7907 > M7908 >=20 > Quad boards, I think they came from an RK06/07. Maybe the boards from an RK= 611?=20 The first two are RK06 drive modules; the last three are RK07 drive modules (= info from the 1983 Option/Module list). paul --===============2539804343701650487==-- From cz@beaker.crystel.com Thu Feb 23 14:04:12 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Stuff to go or it's off to the dumpster Date: Wed, 22 Feb 2023 15:23:45 -0500 Message-ID: <261183ab-9095-a7f1-4a78-ba09474ed884@beaker.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4219255309464604058==" --===============4219255309464604058== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > The first two are RK06 drive modules; the last three are RK07 drive modules= (info from the 1983 Option/Module list). So these go *into* RK06 or 07 drives? Interesting, these may have come=20 with an 11/34 which had the RK611 controller (long since gone). Well if anyone has an RK06/07 reach out before they go in the recycle pile. CZ --===============4219255309464604058==-- From cz@beaker.crystel.com Thu Feb 23 14:04:18 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Using teledisk images on a Gotek Date: Thu, 23 Feb 2023 02:38:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6443207318906708923==" --===============6443207318906708923== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Question: I'm starting to work on the concept of installing POS 3.2 on my Pro380 and rather than burning a lot of floppies I'd rather just use my Gotek with FlashFloppy. First problem is this: The images are in lzh format, and when uncompressed are TD0 format. Which I think is teledisk, is there a way to convert those to the raw format used by Flashfloppy? Ultimate goal is to get Pro/Decnet running, hook the 380 up to the Ethernet here with my DECNA to the 11/73 running DEQNA, then try sysgenning a version of RSX11M+ for the Pro that does not suck. Not sure if anyone has tried this, or where they ran into roadblocks. Thanks! CZ --===============6443207318906708923==-- From rich.cini@verizon.net Thu Feb 23 14:10:24 2023 From: Richard Cini To: cctalk@classiccmp.org Subject: [cctalk] Re: Using teledisk images on a Gotek Date: Thu, 23 Feb 2023 09:10:15 -0500 Message-ID: <7423DCBD-8589-4F39-92F4-9A15F3A04B19@verizon.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6411786537226168884==" --===============6411786537226168884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Chris -- I did something similar with my Gazelle images for use with the Gotek. My im= ages are in IMD which I then had to convert to HxC for use with the FlashFlop= py software. So, what I would try is TD0->IMD (using one of Dave's tools) and= then IMD->HxC using the HxC software for use with FF. Rich =EF=BB=BFOn 2/23/23, 9:04 AM, "Chris Zach via cctalk" > wrote: Question: I'm starting to work on the concept of installing POS 3.2 on=20 my Pro380 and rather than burning a lot of floppies I'd rather just use=20 my Gotek with FlashFloppy. First problem is this: The images are in lzh format, and when=20 uncompressed are TD0 format. Which I think is teledisk, is there a way=20 to convert those to the raw format used by Flashfloppy? Ultimate goal is to get Pro/Decnet running, hook the 380 up to the=20 Ethernet here with my DECNA to the 11/73 running DEQNA, then try=20 sysgenning a version of RSX11M+ for the Pro that does not suck. Not sure=20 if anyone has tried this, or where they ran into roadblocks. Thanks! CZ --===============6411786537226168884==-- From lars@nocrew.org Thu Feb 23 14:11:30 2023 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: Stuff to go or it's off to the dumpster Date: Thu, 23 Feb 2023 14:11:25 +0000 Message-ID: <7wwn48v5de.fsf@junk.nocrew.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8845317460700274003==" --===============8845317460700274003== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Need to get rid of some things here that I am never going to use, > maybe someone else will: > > M7705 > M7706 > M7906 > M7907 > M7908 I think I heard a VAXstation 100 owner missing an M7452. Any spares? --===============8845317460700274003==-- From wrcooke@wrcooke.net Thu Feb 23 15:44:32 2023 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Wanted: Apple III 5MB Profile HD driver file Date: Thu, 23 Feb 2023 09:44:29 -0600 Message-ID: <361275273.4212399.1677167069307@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4080742965580973582==" --===============4080742965580973582== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/21/2023 10:48 PM CST Eric Smith via cctalk = wrote: >=20 > Profile trivia: >=20 > The firmware _inside_ the Profile is strange in that it doesn't actually > KNOW the size of the Profile it's installed into. At power up, when the > drive reads the home block, the drive size is stored there. That's done > when the drive is formatted. There is different formatter firmware for 5MB > and 10MB drives. I think that was rather common with early SASI/SCSI controller boards that we= re separate from the drive. My Ampro Little Board Plus docs talk about certa= in controllers that saved the drive parameters in a reserved sector and some = that did not. I believe it couldn't boot from ones that did not. My guess w= ould be that Apple used separate controller boards and drives in the Profile.= But that's simply a guess. Will --===============4080742965580973582==-- From jacob.ritorto@gmail.com Fri Feb 24 21:02:22 2023 From: Jacob Ritorto To: cctalk@classiccmp.org Subject: [cctalk] qbus 6250 pertec tape card Date: Fri, 24 Feb 2023 16:01:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1872433665400054273==" --===============1872433665400054273== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Does anyone have a working one to spare? Needed for PDP-11 unix home project. Emulex preferred but others would perhaps be acceptable. TS11 and/or TMSCP would both be great. Need 50-pin connectors (formatted). Can throw a bit of money / trades around as necessary. thx jake Western Pennsylvania, USA --===============1872433665400054273==-- From elson@pico-systems.com Fri Feb 24 21:19:38 2023 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: qbus 6250 pertec tape card Date: Fri, 24 Feb 2023 15:19:31 -0600 Message-ID: <6042916f-5021-5286-d51c-b1098a770007@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6071702698796029168==" --===============6071702698796029168== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/24/23 15:01, Jacob Ritorto via cctalk wrote: > Does anyone have a working one to spare? > Needed for PDP-11 unix home project. > Emulex preferred but others would perhaps be acceptable. > TS11 and/or TMSCP would both be great. > Need 50-pin connectors (formatted). > Can throw a bit of money / trades around as necessary. > I have an Emulex TC03 (TC0310201-SSB on the label). Jon --===============6071702698796029168==-- From jacob.ritorto@gmail.com Fri Feb 24 21:26:38 2023 From: Jacob Ritorto To: cctalk@classiccmp.org Subject: [cctalk] Re: qbus 6250 pertec tape card Date: Fri, 24 Feb 2023 16:25:57 -0500 Message-ID: In-Reply-To: <6042916f-5021-5286-d51c-b1098a770007@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6101073722650783522==" --===============6101073722650783522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks Jon! From a quick glance at its manual, it seems the TC03 would do swimmingly! Does it have the 22-bit addressing kit? On Fri, Feb 24, 2023 at 4:19 PM Jon Elson via cctalk wrote: > On 2/24/23 15:01, Jacob Ritorto via cctalk wrote: > > Does anyone have a working one to spare? > > Needed for PDP-11 unix home project. > > Emulex preferred but others would perhaps be acceptable. > > TS11 and/or TMSCP would both be great. > > Need 50-pin connectors (formatted). > > Can throw a bit of money / trades around as necessary. > > > I have an Emulex TC03 (TC0310201-SSB on the label). > > Jon > > --===============6101073722650783522==-- From silvercreekvalley@yahoo.com Sat Feb 25 14:46:10 2023 From: silvercreekvalley@yahoo.com To: cctalk@classiccmp.org Subject: [cctalk] WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 14:46:06 +0000 Message-ID: <167733636662.1516385.7534480411170085892@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4332836462114922273==" --===============4332836462114922273== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, I'm cooking up a new interpreter for the PDP 8. It uses a C like language (C-= ) and is really a project to get my head round the PDP 8 architecture. Note i= ts an interpreter not compiler :-) I have recently got my hands on a wonderful working PDP 8/a, but it would be = nice to have some actual storage e.g. a disk drive or tape of some kind. I'm = not a fan of using tape emulators etc, although thats all I have at the momen= t. Happy to pay the going rate and will travel to collect. I'm in the UK - so= can do anywhere in the UK or Netherlands/Germany/France etc. I would also like to have a go with the FPP8/A which is a floating point opti= on on the 8/A. If anyone has one for sale or would be prepared to do medium t= erm loan that would be a great help. More details on the project once its in a workable form and I've set up a web= site or whatever Thanks Ian --===============4332836462114922273==-- From cube1@charter.net Sat Feb 25 14:55:36 2023 From: Jay Jaeger To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 08:48:13 -0600 Message-ID: In-Reply-To: <167733636662.1516385.7534480411170085892@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3607585112840643789==" --===============3607585112840643789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sounds a bit like SmallC or TinyC from back in the day.=20 Sent from my iPad > On Feb 25, 2023, at 08:46, silvercreekvalley--- via cctalk wrote: >=20 > =EF=BB=BFHi all, >=20 > I'm cooking up a new interpreter for the PDP 8. It uses a C like language (= C-) and is really a project to get my head round the PDP 8 architecture. Note= its an interpreter not compiler :-) >=20 > I have recently got my hands on a wonderful working PDP 8/a, but it would b= e nice to have some actual storage e.g. a disk drive or tape of some kind. I'= m not a fan of using tape emulators etc, although thats all I have at the mom= ent. Happy to pay the going rate and will travel to collect. I'm in the UK - = so can do anywhere in the UK or Netherlands/Germany/France etc. >=20 > I would also like to have a go with the FPP8/A which is a floating point op= tion on the 8/A. If anyone has one for sale or would be prepared to do medium= term loan that would be a great help. >=20 > More details on the project once its in a workable form and I've set up a w= ebsite or whatever >=20 > Thanks >=20 > Ian --===============3607585112840643789==-- From billdegnan@gmail.com Sat Feb 25 15:23:10 2023 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 10:22:53 -0500 Message-ID: In-Reply-To: <167733636662.1516385.7534480411170085892@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3907504000584700844==" --===============3907504000584700844== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I am also planning out storage for my 8a, I did not any way yet to load tapes via the serial port ala PDPGUI for pdp11 On Sat, Feb 25, 2023, 9:46 AM silvercreekvalley--- via cctalk < cctalk(a)classiccmp.org> wrote: > Hi all, > > I'm cooking up a new interpreter for the PDP 8. It uses a C like language > (C-) and is really a project to get my head round the PDP 8 architecture. > Note its an interpreter not compiler :-) > > I have recently got my hands on a wonderful working PDP 8/a, but it would > be nice to have some actual storage e.g. a disk drive or tape of some kind. > I'm not a fan of using tape emulators etc, although thats all I have at the > moment. Happy to pay the going rate and will travel to collect. I'm in the > UK - so can do anywhere in the UK or Netherlands/Germany/France etc. > > I would also like to have a go with the FPP8/A which is a floating point > option on the 8/A. If anyone has one for sale or would be prepared to do > medium term loan that would be a great help. > > More details on the project once its in a workable form and I've set up a > website or whatever > > Thanks > > Ian > --===============3907504000584700844==-- From silvercreekvalley@yahoo.com Sat Feb 25 15:41:06 2023 From: silvercreekvalley@yahoo.com To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 15:41:01 +0000 Message-ID: <167733966174.1516385.17604291942572385727@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5866649034256974342==" --===============5866649034256974342== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes - similar to Small C :-) I've written several compilers/interpreters over= the years, so thought I'd give the PDP 8 a go. Its challenging because of th= e lack of stack operations - but there are workarounds. --===============5866649034256974342==-- From vincent.slyngstad@gmail.com Sat Feb 25 17:04:11 2023 From: Vincent Slyngstad To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 09:04:03 -0800 Message-ID: <6e6884e2-7f44-8cf9-84ca-a69bd77a70cb@gmail.com> In-Reply-To: <167733636662.1516385.7534480411170085892@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2225856245217419904==" --===============2225856245217419904== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/25/2023 6:46 AM, silvercreekvalley--- via cctalk wrote: > Hi all, >=20 > I'm cooking up a new interpreter for the PDP 8. It uses a C like language (= C-) and is really a project to get my head round the PDP 8 architecture. Note= its an interpreter not compiler :-) >=20 > I have recently got my hands on a wonderful working PDP 8/a, but it would b= e nice to have some actual storage e.g. a disk drive or tape of some kind. I'= m not a fan of using tape emulators etc, although thats all I have at the mom= ent. Happy to pay the going rate and will travel to collect. I'm in the UK - = so can do anywhere in the UK or Netherlands/Germany/France etc. Easiest thing would be to use Kyle's SerialDisk and a spare serial port: https://github.com/drovak/os8diskserver Perceived speed is (depending on baud rate) similar to floppy. Better=20 than seeking on DECtape :-). Another relatively easy possibility would be an RX01 or RX02 (or=20 emulator) with an original or replacement RX8E board. A little faster,=20 but a lot less storage. (Especially as the RX02 is usually emulating RX01.) Actual RK05, RL01/2, or even DECtape would be harder. > I would also like to have a go with the FPP8/A which is a floating point op= tion on the 8/A. If anyone has one for sale or would be prepared to do medium= term loan that would be a great help. That's likely to be a challenge. That board's been too difficult so far=20 to replicate, and not enough are around for there to be many going spare. Vince --===============2225856245217419904==-- From silvercreekvalley@yahoo.com Sat Feb 25 17:52:30 2023 From: silvercreekvalley@yahoo.com To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 17:52:27 +0000 Message-ID: <167734754720.1516385.11389715741298014338@classiccmp.org> In-Reply-To: <6e6884e2-7f44-8cf9-84ca-a69bd77a70cb@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8202878489159221717==" --===============8202878489159221717== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Vince - I knew about the RX emulators but not the serial disk - that s= ounds interesting. Is there any documentation on that - I had a look at the G= itHub but seemed a bit sparse.=20 I can imagine the FFP8/A is hard to find and replicate. I can probably use em= ulation - but its nice to check with real hardware. --===============8202878489159221717==-- From vincent.slyngstad@gmail.com Sat Feb 25 18:34:48 2023 From: Vincent Slyngstad To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 10:34:43 -0800 Message-ID: <05997133-743b-f59b-bfc1-be6164eaf4c8@gmail.com> In-Reply-To: <167734754720.1516385.11389715741298014338@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3831683481512345247==" --===============3831683481512345247== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/25/2023 9:52 AM, silvercreekvalley--- via cctalk wrote: > Thanks Vince - I knew about the RX emulators but not the serial disk - that= sounds interesting. Is there any documentation on that - I had a look at the= GitHub but seemed a bit sparse. Suggestions on how to make it more accessible are welcome. (Kyle and I=20 are the maintainers, with some help from Doug and others.) Basically, the idea is to take the great many existing (RK05) images,=20 and convert them to work over a serial port to a server running in a=20 generic POSIX environment. There are several parts to this: There's some documentation (SerialDisk/docs) There are system and non-system handlers for the new device (handler). There are a couple of choices for short bootstrap programs to get things=20 rolling (bootloader). There are a few provided RK05 images (disks). There's the POSIX program to serve the disk images over the serial line=20 (server). There are various conversion schemes to get your RK05 image converted to=20 the new drivers. The one I use most uses the SIMH simulator to automate the ritual of=20 uninstalling RK05 drivers and replacing them with SerialDisk driver.=20 The Makefile there will actually convert a disk image, and you could=20 just swipe the default one once it's been made. Once the disk image(s) are converted to the new drivers, they boot OS/8=20 in a simple way using one of the short bootstraps. The other things you need (besides a PDP-8) are a PC/RasPi/whatever to=20 run the server on, and as fast a serial port as you can manage. There are also example config files for running the whole thing under=20 SIMH on your POSIX box. If you're more concerned about getting software=20 developed than about the retro experience, that's also a great way to=20 speed things along. TBH, when I'm in a hurry I often just use SIMH with the cross assembler,=20 and skip OS/8 altogether until I'm ready to verify that things work on=20 real hardware. You'll need more interaction with OS/8 to open files and=20 such, so that might not work for you. It is a great relief to use a proper editor, rather than the one in=20 OS/8. You might also want to hunt down the emacs-like editor that was=20 done for OS/8 a couple of years ago, if you're going to be working=20 native a lot. Vince --===============3831683481512345247==-- From vincent.slyngstad@gmail.com Sat Feb 25 19:20:43 2023 From: Vincent Slyngstad To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 11:20:39 -0800 Message-ID: In-Reply-To: <167734754720.1516385.11389715741298014338@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5457117050917361187==" --===============5457117050917361187== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Here's a link to a distribution for the E8 emacs-like editor I mentioned: https://tangentsoft.com/e8/wiki?name=Home Also, tangentsoft has a bunch of information about software development related to the PiDP effort, including their version of the C compiler. https://tangentsoft.com/pidp8i/wiki?name=Home https://tangentsoft.com/pidp8i/doc/442d9cff50/src/cc8/README.md The PiDP project has generated quite a bit of attention to the PDP-8 over the last several years. Vince --===============5457117050917361187==-- From silvercreekvalley@yahoo.com Sat Feb 25 20:19:04 2023 From: silvercreekvalley@yahoo.com To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 20:18:59 +0000 Message-ID: <167735633979.1516385.4560590966243593345@classiccmp.org> In-Reply-To: <05997133-743b-f59b-bfc1-be6164eaf4c8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1880886836003116162==" --===============1880886836003116162== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Great thanks. I'll have a go. --===============1880886836003116162==-- From silvercreekvalley@yahoo.com Sat Feb 25 20:34:24 2023 From: silvercreekvalley@yahoo.com To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 20:34:21 +0000 Message-ID: <167735726180.1516385.9460874746463602921@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8550586190844909057==" --===============8550586190844909057== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks Vince - this is great. Working my way through the docs now :-) --===============8550586190844909057==-- From silvercreekvalley@yahoo.com Sat Feb 25 20:41:48 2023 From: Ian F To: cctalk@classiccmp.org Subject: [cctalk] email address Date: Sat, 25 Feb 2023 20:41:44 +0000 Message-ID: <167735770427.1516385.2100652576957702351@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3184339375499613927==" --===============3184339375499613927== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For some reason my username is my email address. Can I change this ? I have a= username / name entered so not sure why this is showing. Thanks --===============3184339375499613927==-- From silvercreekvalley@yahoo.com Sat Feb 25 20:42:42 2023 From: Ian F To: cctalk@classiccmp.org Subject: [cctalk] Re: email address Date: Sat, 25 Feb 2023 20:42:38 +0000 Message-ID: <167735775880.1516385.12940207432916031819@classiccmp.org> In-Reply-To: <167735770427.1516385.2100652576957702351@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0919194159022359285==" --===============0919194159022359285== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Ignore the above - it seems to have changed :-) --===============0919194159022359285==-- From jnc@mercury.lcs.mit.edu Sat Feb 25 20:50:52 2023 From: jnc@mercury.lcs.mit.edu To: cctalk@classiccmp.org Subject: [cctalk] Re: Stuff to go or it's off to the dumpster Date: Sat, 25 Feb 2023 15:26:13 -0500 Message-ID: <20230225202613.767CD18C087@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0882611711573275614==" --===============0882611711573275614== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > From: Chris Zach > So these go *into* RK06 or 07 drives? Yes; per the "Field Guide to UNIBUS and QBUS Modules". Also: https://gunkies.org/wiki/RK611_disk_controller reveals that the RK611 contains "five hex cards" (listed there). Noel --===============0882611711573275614==-- From cz@beaker.crystel.com Sat Feb 25 22:00:21 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Stuff to go or it's off to the dumpster Date: Sat, 25 Feb 2023 16:25:14 -0500 Message-ID: In-Reply-To: <20230225202613.767CD18C087@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3282108566802376985==" --===============3282108566802376985== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Ok good. I am working through the replies, they will not go into the dumpster. C On 2/25/2023 3:26 PM, Noel Chiappa via cctalk wrote: > > From: Chris Zach > > > So these go *into* RK06 or 07 drives? > > Yes; per the "Field Guide to UNIBUS and QBUS Modules". Also: > > https://gunkies.org/wiki/RK611_disk_controller > > reveals that the RK611 contains "five hex cards" (listed there). > > Noel --===============3282108566802376985==-- From cz@alembic.crystel.com Sat Feb 25 22:11:59 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Getting QRST files onto a floppy (sigh) Date: Sat, 25 Feb 2023 17:11:53 -0500 Message-ID: <6809acf8-11e4-bdf0-de99-9d9cadde8171@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4710577954649269174==" --===============4710577954649269174== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit So I'm working on restoring a Compaq DeskPro/XE system to allow me to use the 5.25 floppy to copy files from my 3.5 floppies which will come from my Windows 10 system so that I can extract on the Deskpro/XE using teledisk the .td0 files that make up a RX50 floppy disk set so I can load POS 3.2 on my Pro/380 and see if the DECNA card works. What a pain in the rear. So far the XE boots but has no setup. Setup requires a special floppy (Diagnostic disk) which mine was bad after 30 years so I'm trying to create a new one. I have the official Compaq disk creation thing for a floppy but it's in QRST format and the QRST under DOSBOX on Windows10 can't properly access a floppy even if "mounted" with a -t floppy extension. Before I drag out my rusty and trusty Windows 95 Toshiba 660AV laptop, is there another way to get this onto a floppy? I have an endless supply of Rpi's, and doing a DD from a .img file works fine but this of course is a QRST file. Thoughts? CZ --===============4710577954649269174==-- From wayne.sudol@hotmail.com Sat Feb 25 23:17:45 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sat, 25 Feb 2023 23:17:38 +0000 Message-ID: In-Reply-To: <6809acf8-11e4-bdf0-de99-9d9cadde8171@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1145919349615987206==" --===============1145919349615987206== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9C QRST under DOSBOX on Windows10 can't properly access a floppy even = if "mounted" with a -t floppy extension.=E2=80=9D It is a dosbox thing really?=20 Win 10 comes with cmd so do you need to use dosbox?=20 Sent from my iPhone > On Feb 25, 2023, at 14:12, Chris Zach via cctalk = wrote: >=20 > =EF=BB=BFSo I'm working on restoring a Compaq DeskPro/XE system to allow me= to use the 5.25 floppy to copy files from my 3.5 floppies which will come fr= om my Windows 10 system so that I can extract on the Deskpro/XE using teledis= k the .td0 files that make up a RX50 floppy disk set so I can load POS 3.2 on= my Pro/380 and see if the DECNA card works. >=20 > What a pain in the rear. >=20 > So far the XE boots but has no setup. Setup requires a special floppy (Diag= nostic disk) which mine was bad after 30 years so I'm trying to create a new = one. I have the official Compaq disk creation thing for a floppy but it's in = QRST format and the QRST under DOSBOX on Windows10 can't properly access a fl= oppy even if "mounted" with a -t floppy extension. >=20 > Before I drag out my rusty and trusty Windows 95 Toshiba 660AV laptop, is t= here another way to get this onto a floppy? I have an endless supply of Rpi's= , and doing a DD from a .img file works fine but this of course is a QRST fil= e. >=20 > Thoughts? >=20 > CZ >=20 --===============1145919349615987206==-- From wayne.sudol@hotmail.com Sat Feb 25 23:20:50 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sat, 25 Feb 2023 23:20:44 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB218113A6814107B753564D1DE4A99=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4971422605053416406==" --===============4971422605053416406== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Also you might just create a dos 6 bootable floppy and boos dos from the =E2= =80=9CA=E2=80=9D drive. Would thst work? Sent from my iPhone > On Feb 25, 2023, at 15:17, Wayne S wrote: >=20 > =EF=BB=BF=E2=80=9C QRST under DOSBOX on Windows10 can't properly access a f= loppy even if "mounted" with a -t floppy extension.=E2=80=9D > It is a dosbox thing really?=20 > Win 10 comes with cmd so do you need to use dosbox?=20 >=20 > Sent from my iPhone >=20 >> On Feb 25, 2023, at 14:12, Chris Zach via cctalk = wrote: >>=20 >> =EF=BB=BFSo I'm working on restoring a Compaq DeskPro/XE system to allow m= e to use the 5.25 floppy to copy files from my 3.5 floppies which will come f= rom my Windows 10 system so that I can extract on the Deskpro/XE using teledi= sk the .td0 files that make up a RX50 floppy disk set so I can load POS 3.2 o= n my Pro/380 and see if the DECNA card works. >>=20 >> What a pain in the rear. >>=20 >> So far the XE boots but has no setup. Setup requires a special floppy (Dia= gnostic disk) which mine was bad after 30 years so I'm trying to create a new= one. I have the official Compaq disk creation thing for a floppy but it's in= QRST format and the QRST under DOSBOX on Windows10 can't properly access a f= loppy even if "mounted" with a -t floppy extension. >>=20 >> Before I drag out my rusty and trusty Windows 95 Toshiba 660AV laptop, is = there another way to get this onto a floppy? I have an endless supply of Rpi'= s, and doing a DD from a .img file works fine but this of course is a QRST fi= le. >>=20 >> Thoughts? >>=20 >> CZ >>=20 --===============4971422605053416406==-- From wayne.sudol@hotmail.com Sun Feb 26 00:02:44 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 00:02:31 +0000 Message-ID: In-Reply-To: <11e5c84d-094f-5fa7-b7af-e36bedfcdfb1@beaker.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6295992550751990306==" --===============6295992550751990306== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I read that Qrst was just a file format. To quote The QRST disc image format = was used by Compaq to distribute disk images of diagnostic software. The file= QRST.EXE or QRST5.EXE would be supplied with the disc images to write them t= o a floppy drive. -So do you have the QRST programs available? Sent from my iPhone On Feb 25, 2023, at 15:34, Chris Zach wrote: =EF=BB=BF Win 10 comes with cmd so do you need to use dosbox? Windows 10 does not have a 16 bit subsystem anymore. Doesn't work. As for creating a DOS bootable disk, I think the problem is that the low leve= l disk access QRST wants is not availible on a USB floppy drive. So you need = a "real" floppy and controller to make it work. Anyone want to do me a favor, run it, and email me an .img version of the res= ulting floppy? I'd use my Toshiba 660av, but I just checked and the power adapter is missing= . Yep..... CZ --===============6295992550751990306==-- From cz@alembic.crystel.com Sun Feb 26 00:17:15 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sat, 25 Feb 2023 19:16:59 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181FA30F8280C14F019EC7AE4AE9=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8479445790590272097==" --===============8479445790590272097== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I read that Qrst was just a file format. To quote The QRST disc image > format was used by Compaq to distribute disk images of diagnostic > software. The file QRST.EXE or QRST5.EXE would be supplied with the disc > images to write them to a floppy drive. > -So do you have the QRST programs available? Yes. However the QRST program is a 16 bit app that requires physical access to a real floppy controller. Thus it cannot work on a Windows 10 system with DOSBOX as the floppy is USB and I don't think DOSBOX emulates a true floppy interface at the BIOS level. Modern archive tools like 7zip do not appear to have support for QRST format. It's compressed in some odd way, so it can't just be dd'ed to a floppy sector by sector. Never dull. CZ --===============8479445790590272097==-- From wayne.sudol@hotmail.com Sun Feb 26 00:23:06 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 00:23:01 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2499124286626241727==" --===============2499124286626241727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yep. I can probably burn a floppy for you if you put the programs and data so= ftware somewhere i can get to it. I=E2=80=99ll try and then you can tell me w= here to send the floppies.=20 Sent from my iPhone > On Feb 25, 2023, at 16:17, Chris Zach via cctalk = wrote: >=20 > =EF=BB=BF >>=20 >> I read that Qrst was just a file format. To quote The QRST disc image form= at was used by Compaq to distribute disk images of diagnostic software. The f= ile QRST.EXE or QRST5.EXE would be supplied with the disc images to write the= m to a floppy drive. >> -So do you have the QRST programs available? >=20 > Yes. However the QRST program is a 16 bit app that requires physical access= to a real floppy controller. Thus it cannot work on a Windows 10 system with= DOSBOX as the floppy is USB and I don't think DOSBOX emulates a true floppy = interface at the BIOS level. >=20 > Modern archive tools like 7zip do not appear to have support for QRST forma= t. It's compressed in some odd way, so it can't just be dd'ed to a floppy sec= tor by sector. >=20 > Never dull. > CZ --===============2499124286626241727==-- From wayne.sudol@hotmail.com Sun Feb 26 00:24:18 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 00:24:09 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB218126A571443FCA96A5951EE4AE9=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5579173414795030181==" --===============5579173414795030181== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Btw=E2=80=A6 here=E2=80=99s the link to the Qrst info=E2=80=A6 http://filefor= mats.archiveteam.org/wiki/Quick_Release_Sector_Transfer Sent from my iPhone On Feb 25, 2023, at 16:23, Wayne S wrote: =EF=BB=BFYep. I can probably burn a floppy for you if you put the programs an= d data software somewhere i can get to it. I=E2=80=99ll try and then you can = tell me where to send the floppies. Sent from my iPhone On Feb 25, 2023, at 16:17, Chris Zach via cctalk wr= ote: =EF=BB=BF I read that Qrst was just a file format. To quote The QRST disc image format = was used by Compaq to distribute disk images of diagnostic software. The file= QRST.EXE or QRST5.EXE would be supplied with the disc images to write them t= o a floppy drive. -So do you have the QRST programs available? Yes. However the QRST program is a 16 bit app that requires physical access t= o a real floppy controller. Thus it cannot work on a Windows 10 system with D= OSBOX as the floppy is USB and I don't think DOSBOX emulates a true floppy in= terface at the BIOS level. Modern archive tools like 7zip do not appear to have support for QRST format.= It's compressed in some odd way, so it can't just be dd'ed to a floppy secto= r by sector. Never dull. CZ --===============5579173414795030181==-- From wayne.sudol@hotmail.com Sun Feb 26 00:29:05 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 00:29:00 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21813A34D03804C2190A93FAE4AE9=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0903168148041083177==" --===============0903168148041083177== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Since, allowing for snail mail, it will probably be a week, i have a question= . Can you run the qrst.exe program at all? Was thinking that it might be poss= ible to extract the image to hard disk then use an image burning prog to writ= e to the floppy eith needing 16 bit drivers. Sent from my iPhone On Feb 25, 2023, at 16:24, Wayne S wrote: =EF=BB=BF Btw=E2=80=A6 here=E2=80=99s the link to the Qrst info=E2=80=A6 http= ://fileformats.archiveteam.org/wiki/Quick_Release_Sector_Transfer Sent from my iPhone On Feb 25, 2023, at 16:23, Wayne S wrote: =EF=BB=BFYep. I can probably burn a floppy for you if you put the programs an= d data software somewhere i can get to it. I=E2=80=99ll try and then you can = tell me where to send the floppies. Sent from my iPhone On Feb 25, 2023, at 16:17, Chris Zach via cctalk wr= ote: =EF=BB=BF I read that Qrst was just a file format. To quote The QRST disc image format = was used by Compaq to distribute disk images of diagnostic software. The file= QRST.EXE or QRST5.EXE would be supplied with the disc images to write them t= o a floppy drive. -So do you have the QRST programs available? Yes. However the QRST program is a 16 bit app that requires physical access t= o a real floppy controller. Thus it cannot work on a Windows 10 system with D= OSBOX as the floppy is USB and I don't think DOSBOX emulates a true floppy in= terface at the BIOS level. Modern archive tools like 7zip do not appear to have support for QRST format.= It's compressed in some odd way, so it can't just be dd'ed to a floppy secto= r by sector. Never dull. CZ --===============0903168148041083177==-- From couryhouse@aol.com Sun Feb 26 01:30:19 2023 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sun, 26 Feb 2023 01:30:07 +0000 Message-ID: <1005055595.562775.1677375007904@mail.yahoo.com> In-Reply-To: <05997133-743b-f59b-bfc1-be6164eaf4c8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5897749095936506852==" --===============5897749095936506852== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I always wanted to build a tss8 system! Ed#=C2=A0 hiding out at smecc Sent from AOL on Android=20 =20 On Sat, Feb 25, 2023 at 11:34 AM, Vincent Slyngstad via cctalk wrote: On 2/25/2023 9:52 AM, silvercreekvalley--- via cctalk w= rote: > Thanks Vince - I knew about the RX emulators but not the serial disk - that= sounds interesting. Is there any documentation on that - I had a look at the= GitHub but seemed a bit sparse. Suggestions on how to make it more accessible are welcome.=C2=A0 (Kyle and I = are the maintainers, with some help from Doug and others.) Basically, the idea is to take the great many existing (RK05) images,=20 and convert them to work over a serial port to a server running in a=20 generic POSIX environment.=C2=A0 There are several parts to this: There's some documentation (SerialDisk/docs) There are system and non-system handlers for the new device (handler). There are a couple of choices for short bootstrap programs to get things=20 rolling (bootloader). There are a few provided RK05 images (disks). There's the POSIX program to serve the disk images over the serial line=20 (server). There are various conversion schemes to get your RK05 image converted to=20 the new drivers. The one I use most uses the SIMH simulator to automate the ritual of=20 uninstalling RK05 drivers and replacing them with SerialDisk driver.=20 The Makefile there will actually convert a disk image, and you could=20 just swipe the default one once it's been made. Once the disk image(s) are converted to the new drivers, they boot OS/8=20 in a simple way using one of the short bootstraps. The other things you need (besides a PDP-8) are a PC/RasPi/whatever to=20 run the server on, and as fast a serial port as you can manage. There are also example config files for running the whole thing under=20 SIMH on your POSIX box.=C2=A0 If you're more concerned about getting software= =20 developed than about the retro experience, that's also a great way to=20 speed things along. TBH, when I'm in a hurry I often just use SIMH with the cross assembler,=20 and skip OS/8 altogether until I'm ready to verify that things work on=20 real hardware.=C2=A0 You'll need more interaction with OS/8 to open files and= =20 such, so that might not work for you. It is a great relief to use a proper editor, rather than the one in=20 OS/8.=C2=A0 You might also want to hunt down the emacs-like editor that was=20 done for OS/8 a couple of years ago, if you're going to be working=20 native a lot. =C2=A0=C2=A0=C2=A0 Vince =20 --===============5897749095936506852==-- From ccth6600@gmail.com Sun Feb 26 06:46:33 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sun, 26 Feb 2023 14:46:16 +0800 Message-ID: In-Reply-To: <05997133-743b-f59b-bfc1-be6164eaf4c8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1743054774696965541==" --===============1743054774696965541== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Vince, Could you please point us to the Makefile which "actually converts a disk image" using SIMH to "automate the ritual of unistalling RK05 drivers and replacing them with SerialDisk drivers"? Thanks Tom On Sun, Feb 26, 2023 at 2:34 AM Vincent Slyngstad via cctalk < cctalk(a)classiccmp.org> wrote: > ... > > The one I use most uses the SIMH simulator to automate the ritual of > uninstalling RK05 drivers and replacing them with SerialDisk driver. > The Makefile there will actually convert a disk image, and you could > just swipe the default one once it's been made. > > --===============1743054774696965541==-- From vincent.slyngstad@gmail.com Sun Feb 26 07:48:17 2023 From: Vincent Slyngstad To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sat, 25 Feb 2023 23:48:12 -0800 Message-ID: <3a27943a-4556-aa08-630e-73008f75a668@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5867413958384189452==" --===============5867413958384189452== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/25/2023 10:46 PM, Tom Hunter via cctalk wrote: > Hi Vince, > > Could you please point us to the Makefile which "actually converts a disk > image" using SIMH to "automate the ritual of unistalling RK05 drivers and > replacing them with SerialDisk drivers"? Ah, I seem to have misspoken. Inspecting the Makefile in .../installer, it still runs the executable "handler_installer", which is the older tool that more or less just hammers a new system handler and bootstrap into place. The script for the new installer is "sdsk". This sets up a path for the tools, copies the newest driver binaries into the exploded disk image (while padding them to an even block length), then imploding the exploded directory and making a new bootable RK05 image. Then "runbuild" is invokes, which in turn invokes SIMH and sends a series of commands to BUILD.SV to remove various other drivers and install the "SDSKSY" and "SDSKNS" drivers copied above. Finally, the "BOOT" command is given to write the new second stage (and third stage) bootstrap. The self-modified BOOT.SV is also saved as BUILT.SV. Sorry for the confusion. If you don't want to use diagpack2, SDSK.md is helpful, but basically you need to edit the line: image=diagpack2 in the sdsk script, and to have previously copied in your starting image, and run ../tools/os8xplode on it. SDSK.md also contains information about the need for "perl", "socat", and "expect" and to get them (on Linux, anyway). Oh, and the SIMH initialization file (pdp8.ini) is also firing up the server program, so you need to tweak that to make your "foo.new" available to the SIMH serial emulation. That script used to also require a functioning xterm, but it doesn't any more. If you have xterm and want to see the server log in real time, there are lines there to invoke ../server/server the other way, and you can un-comment that and comment out the bash line. Once you've done all the above, it suffices to just type "pdp8" in that directory and your new system should boot in SIMH. Hope that helps, Vince > On Sun, Feb 26, 2023 at 2:34 AM Vincent Slyngstad via cctalk < > cctalk(a)classiccmp.org> wrote: > >> ... >> >> The one I use most uses the SIMH simulator to automate the ritual of >> uninstalling RK05 drivers and replacing them with SerialDisk driver. >> The Makefile there will actually convert a disk image, and you could >> just swipe the default one once it's been made. >> >> --===============5867413958384189452==-- From ccth6600@gmail.com Sun Feb 26 08:25:49 2023 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sun, 26 Feb 2023 16:25:33 +0800 Message-ID: In-Reply-To: <3a27943a-4556-aa08-630e-73008f75a668@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5847471394828255108==" --===============5847471394828255108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thank you very much Vince. On Sun, 26 Feb 2023, 3:48 pm Vincent Slyngstad via cctalk, < cctalk(a)classiccmp.org> wrote: > On 2/25/2023 10:46 PM, Tom Hunter via cctalk wrote: > > Hi Vince, > > > > Could you please point us to the Makefile which "actually converts a disk > > image" using SIMH to "automate the ritual of unistalling RK05 drivers and > > replacing them with SerialDisk drivers"? > > Ah, I seem to have misspoken. Inspecting the Makefile in .../installer, > it still runs the executable "handler_installer", which is the older > tool that more or less just hammers a new system handler and bootstrap > into place. > > The script for the new installer is "sdsk". This sets up a path for the > tools, copies the newest driver binaries into the exploded disk image > (while padding them to an even block length), then imploding the > exploded directory and making a new bootable RK05 image. > > Then "runbuild" is invokes, which in turn invokes SIMH and sends a > series of commands to BUILD.SV to remove various other drivers and > install the "SDSKSY" and "SDSKNS" drivers copied above. Finally, the > "BOOT" command is given to write the new second stage (and third stage) > bootstrap. The self-modified BOOT.SV is also saved as BUILT.SV. > > Sorry for the confusion. > > If you don't want to use diagpack2, SDSK.md is helpful, but basically > you need to edit the line: > image=diagpack2 > in the sdsk script, and to have previously copied in your starting > image, and run ../tools/os8xplode on it. SDSK.md also contains > information about the need for "perl", "socat", and "expect" and to get > them (on Linux, anyway). > > Oh, and the SIMH initialization file (pdp8.ini) is also firing up the > server program, so you need to tweak that to make your "foo.new" > available to the SIMH serial emulation. That script used to also > require a functioning xterm, but it doesn't any more. If you have xterm > and want to see the server log in real time, there are lines there to > invoke ../server/server the other way, and you can un-comment that and > comment out the bash line. > > Once you've done all the above, it suffices to just type "pdp8" in that > directory and your new system should boot in SIMH. > > Hope that helps, > > Vince > > > On Sun, Feb 26, 2023 at 2:34 AM Vincent Slyngstad via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > >> ... > >> > >> The one I use most uses the SIMH simulator to automate the ritual of > >> uninstalling RK05 drivers and replacing them with SerialDisk driver. > >> The Makefile there will actually convert a disk image, and you could > >> just swipe the default one once it's been made. > >> > >> > > --===============5847471394828255108==-- From jos.dreesen@greenmail.ch Sun Feb 26 09:15:58 2023 From: jos To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sun, 26 Feb 2023 10:15:40 +0100 Message-ID: In-Reply-To: <167734754720.1516385.11389715741298014338@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3273292762221681065==" --===============3273292762221681065== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 25.02.23 18:52, silvercreekvalley--- via cctalk wrote: > Thanks Vince - I knew about the RX emulators but not the serial disk - that= sounds interesting. Is there any documentation on that - I had a look at the= GitHub but seemed a bit sparse. > > I can imagine the FFP8/A is hard to find and replicate. I can probably use = emulation - but its nice to check with real hardware. This is probably not the right place to link the youtube video of the guy tha= t destroyed a FPP8/A set to recover the gold on the PCB-fingers... I do have a rather complete 8/A, with RL01 ad FPP8/A. Alas no sockets inside = so the PROMs cannot easily be read out. Jos --===============3273292762221681065==-- From vincent.slyngstad@gmail.com Sun Feb 26 14:48:06 2023 From: Vincent Slyngstad To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sun, 26 Feb 2023 06:47:58 -0800 Message-ID: <779774cc-6582-237c-13ed-0db63e4ebf23@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7662931529477384311==" --===============7662931529477384311== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/26/2023 1:15 AM, jos via cctalk wrote: > On 25.02.23 18:52, silvercreekvalley--- via cctalk wrote: >> Thanks Vince - I knew about the RX emulators but not the serial disk - >> that sounds interesting. Is there any documentation on that - I had a >> look at the GitHub but seemed a bit sparse. >> >> I can imagine the FFP8/A is hard to find and replicate. I can probably >> use emulation - but its nice to check with real hardware. > > This is probably not the right place to link the youtube video of the > guy that destroyed a FPP8/A set to recover the gold on the PCB-fingers... > > I do have a rather complete 8/A, with RL01 ad FPP8/A. Alas no sockets > inside so the PROMs cannot easily be read out. Too bad we probably can't get the damaged board to image the PROMS and programmable parts. ISTR seeing some of that information in the drawings. I tried to reverse engineer the 128K memory controller, but ran into issues where I could not be certain what should be in the ROMs and other programmable parts. (It is not just a bigger memory; there's remapping for DMA, remapping for user mode, and all kinds of other stuff in there.) Vince --===============7662931529477384311==-- From paulkoning@comcast.net Sun Feb 26 16:15:08 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 11:15:01 -0500 Message-ID: In-Reply-To: <6809acf8-11e4-bdf0-de99-9d9cadde8171@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8789358509718166723==" --===============8789358509718166723== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 25, 2023, at 5:11 PM, Chris Zach via cctalk wrote: >=20 > So I'm working on restoring a Compaq DeskPro/XE system to allow me to use t= he 5.25 floppy to copy files from my 3.5 floppies which will come from my Win= dows 10 system so that I can extract on the Deskpro/XE using teledisk the .td= 0 files that make up a RX50 floppy disk set so I can load POS 3.2 on my Pro/3= 80 and see if the DECNA card works. >=20 > What a pain in the rear. >=20 > So far the XE boots but has no setup. Setup requires a special floppy (Diag= nostic disk) which mine was bad after 30 years so I'm trying to create a new = one. I have the official Compaq disk creation thing for a floppy but it's in = QRST format and the QRST under DOSBOX on Windows10 can't properly access a fl= oppy even if "mounted" with a -t floppy extension. I run Linux on my old PCs -- the one that has a 5.25 inch floppy is an early = Pentium (Gateway). Linux works just fine, no installation hassles. paul --===============8789358509718166723==-- From cz@beaker.crystel.com Sun Feb 26 18:14:26 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sat, 25 Feb 2023 23:34:02 +0000 Message-ID: <11e5c84d-094f-5fa7-b7af-e36bedfcdfb1@beaker.crystel.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB218113A6814107B753564D1DE4A99=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0155905165231901570==" --===============0155905165231901570== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Win 10 comes with cmd so do you need to use dosbox? Windows 10 does not have a 16 bit subsystem anymore. Doesn't work. As for creating a DOS bootable disk, I think the problem is that the low level disk access QRST wants is not availible on a USB floppy drive. So you need a "real" floppy and controller to make it work. Anyone want to do me a favor, run it, and email me an .img version of the resulting floppy? I'd use my Toshiba 660av, but I just checked and the power adapter is missing. Yep..... CZ --===============0155905165231901570==-- From cz@alembic.crystel.com Sun Feb 26 19:33:06 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 14:33:00 -0500 Message-ID: <445e0b8c-b13a-ab69-3298-bdeca5e36e55@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0144370601373621702==" --===============0144370601373621702== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Linux would be fine, however there doesn't seem to be a DOS emulator=20 that emulates the ISA bus A: drive. I suppose Linux on a PC with that=20 hardware might work, however the hardware in question is stuck at the=20 "need to configure" which does require a DOS disk which can only be=20 extracted by QRST on a DOS system.... One thought might be: Install DOS and Format.exe on a 3.5 floppy Fire it up and when running QRST try selecting the "B" drive. That used to (on a single disk system) prompt you to switch floppies=20 back and forth which *might* work, allowing me to write the image on a=20 second floppy. Or... Find a 1.2mb 5.25 floppy in my pile of stuff. Load DOS on the 3.5. Put the 5.25 in as drive B: Format the 5.25 with format b: /s /v to put the system on it. Boot off B: Copy the stupid image from A: to B: Run QRST Switch A floppy with a new disk and try extracting to it. We'll see. This is a fun little adventure. Wish I could figure out where=20 the heck my Toshiba power supply brick is... C On 2/26/2023 11:15 AM, Paul Koning wrote: >=20 >=20 >> On Feb 25, 2023, at 5:11 PM, Chris Zach via cctalk wrote: >> >> So I'm working on restoring a Compaq DeskPro/XE system to allow me to use = the 5.25 floppy to copy files from my 3.5 floppies which will come from my Wi= ndows 10 system so that I can extract on the Deskpro/XE using teledisk the .t= d0 files that make up a RX50 floppy disk set so I can load POS 3.2 on my Pro/= 380 and see if the DECNA card works. >> >> What a pain in the rear. >> >> So far the XE boots but has no setup. Setup requires a special floppy (Dia= gnostic disk) which mine was bad after 30 years so I'm trying to create a new= one. I have the official Compaq disk creation thing for a floppy but it's in= QRST format and the QRST under DOSBOX on Windows10 can't properly access a f= loppy even if "mounted" with a -t floppy extension. >=20 > I run Linux on my old PCs -- the one that has a 5.25 inch floppy is an earl= y Pentium (Gateway). Linux works just fine, no installation hassles. >=20 > paul >=20 >=20 --===============0144370601373621702==-- From cz@alembic.crystel.com Sun Feb 26 19:40:11 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 14:40:07 -0500 Message-ID: <337ffbd1-8e8d-5477-ab61-df111d139c9c@alembic.crystel.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB218126A571443FCA96A5951EE4AE9=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5907687413505625393==" --===============5907687413505625393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you! I'd appreciate it if it comes to that, but I'll give myself a=20 week to find a solution here. All I need is a .img file or something I=20 can burn to floppy with dd. And I have to replace that battery on the motherboard. Looks to be=20 welded in, we'll see.... CZ On 2/25/2023 7:23 PM, Wayne S wrote: > Yep. I can probably burn a floppy for you if you put the programs and data = software somewhere i can get to it. I=E2=80=99ll try and then you can tell me= where to send the floppies. >=20 > Sent from my iPhone >=20 >> On Feb 25, 2023, at 16:17, Chris Zach via cctalk = wrote: >> >> =EF=BB=BF >>> >>> I read that Qrst was just a file format. To quote The QRST disc image for= mat was used by Compaq to distribute disk images of diagnostic software. The = file QRST.EXE or QRST5.EXE would be supplied with the disc images to write th= em to a floppy drive. >>> -So do you have the QRST programs available? >> >> Yes. However the QRST program is a 16 bit app that requires physical acces= s to a real floppy controller. Thus it cannot work on a Windows 10 system wit= h DOSBOX as the floppy is USB and I don't think DOSBOX emulates a true floppy= interface at the BIOS level. >> >> Modern archive tools like 7zip do not appear to have support for QRST form= at. It's compressed in some odd way, so it can't just be dd'ed to a floppy se= ctor by sector. >> >> Never dull. >> CZ --===============5907687413505625393==-- From cz@alembic.crystel.com Sun Feb 26 19:42:03 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 14:41:58 -0500 Message-ID: <79d0f0f2-79c0-4732-4782-c59d4015741c@alembic.crystel.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181C4E14920BD6DA02AD3DCE4AE9=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9179539254173110923==" --===============9179539254173110923== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit QRST does run without issues on DOSBOX, the problem is it can't see the concept of the "A" drive which seems to be a mapped share as opposed to a "physical dopey DMA device". The floppy controller on PC's was always weird as hell, I do remember that. CZ On 2/25/2023 7:29 PM, Wayne S wrote: > Since, allowing for snail mail, it will probably be a week, i have a > question. Can you run the qrst.exe program at all? Was thinking that it > might be possible to extract the image to hard disk then use an image > burning prog to write to the floppy eith needing 16 bit drivers. > > Sent from my iPhone > >> On Feb 25, 2023, at 16:24, Wayne S wrote: >> >>  Btw… here’s the link to the Qrst info… >> http://fileformats.archiveteam.org/wiki/Quick_Release_Sector_Transfer >> >> >> >> Sent from my iPhone >> >>> On Feb 25, 2023, at 16:23, Wayne S wrote: >>> >>> Yep. I can probably burn a floppy for you if you put the programs >>> and data software somewhere i can get to it. I’ll try and then you >>> can tell me where to send the floppies. >>> >>> Sent from my iPhone >>> >>>> On Feb 25, 2023, at 16:17, Chris Zach via cctalk >>>> wrote: >>>> >>>>  >>>>> >>>>> I read that Qrst was just a file format. To quote The QRST disc >>>>> image format was used by Compaq to distribute disk images of >>>>> diagnostic software. The file QRST.EXE or QRST5.EXE would be >>>>> supplied with the disc images to write them to a floppy drive. >>>>> -So do you have the QRST programs available? >>>> >>>> Yes. However the QRST program is a 16 bit app that requires physical >>>> access to a real floppy controller. Thus it cannot work on a Windows >>>> 10 system with DOSBOX as the floppy is USB and I don't think DOSBOX >>>> emulates a true floppy interface at the BIOS level. >>>> >>>> Modern archive tools like 7zip do not appear to have support for >>>> QRST format. It's compressed in some odd way, so it can't just be >>>> dd'ed to a floppy sector by sector. >>>> >>>> Never dull. >>>> CZ --===============9179539254173110923==-- From cisin@xenosoft.com Sun Feb 26 19:49:46 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 11:49:42 -0800 Message-ID: In-Reply-To: <445e0b8c-b13a-ab69-3298-bdeca5e36e55@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5859211024290187279==" --===============5859211024290187279== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 26 Feb 2023, Chris Zach via cctalk wrote: > Install DOS and Format.exe on a 3.5 floppy Fire it up and when running > QRST try selecting the "B" drive. That used to (on a single disk system) > prompt you to switch floppies back and forth which *might* work, > allowing me to write the image on a second floppy. . . . > Or... > Find a 1.2mb 5.25 floppy in my pile of stuff. > Load DOS on the 3.5. > Put the 5.25 in as drive B: > Format the 5.25 with format b: /s /v to put the system on it. > Boot off B: > Copy the stupid image from A: to B: > Run QRST > Switch A floppy with a new disk and try extracting to it. Which versions of DOS let you boot off B: ? --===============5859211024290187279==-- From henry.r.bent@gmail.com Sun Feb 26 19:54:20 2023 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 14:54:03 -0500 Message-ID: In-Reply-To: <6809acf8-11e4-bdf0-de99-9d9cadde8171@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1402074229175104144==" --===============1402074229175104144== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 25 Feb 2023 at 17:12, Chris Zach via cctalk wrote: > So I'm working on restoring a Compaq DeskPro/XE system to allow me to > use the 5.25 floppy to copy files from my 3.5 floppies which will come > from my Windows 10 system so that I can extract on the Deskpro/XE using > teledisk the .td0 files that make up a RX50 floppy disk set so I can > load POS 3.2 on my Pro/380 and see if the DECNA card works. > > What a pain in the rear. > > So far the XE boots but has no setup. Setup requires a special floppy > (Diagnostic disk) which mine was bad after 30 years so I'm trying to > create a new one. I have the official Compaq disk creation thing for a > floppy but it's in QRST format and the QRST under DOSBOX on Windows10 > can't properly access a floppy even if "mounted" with a -t floppy > extension. > > Before I drag out my rusty and trusty Windows 95 Toshiba 660AV laptop, > is there another way to get this onto a floppy? I have an endless supply > of Rpi's, and doing a DD from a .img file works fine but this of course > is a QRST file. > > You wanted a SETUP disk for a Deskpro/XE system, right? Like SP1363 as listed here https://www.vogons.org/viewtopic.php?t=76542 ? I was able to do this in Dosbox-X no problem: mount the local directory with sp1363.exe as C: or whatever, attach a disk image to A:, and then let sp1363.exe create the disk image on A: . You can then write the raw disk image to a 1.44" floppy. -Henry --===============1402074229175104144==-- From henry.r.bent@gmail.com Sun Feb 26 19:56:11 2023 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 14:55:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1548278932744916524==" --===============1548278932744916524== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 26 Feb 2023 at 14:54, Henry Bent wrote: > On Sat, 25 Feb 2023 at 17:12, Chris Zach via cctalk > wrote: > >> So I'm working on restoring a Compaq DeskPro/XE system to allow me to >> use the 5.25 floppy to copy files from my 3.5 floppies which will come >> from my Windows 10 system so that I can extract on the Deskpro/XE using >> teledisk the .td0 files that make up a RX50 floppy disk set so I can >> load POS 3.2 on my Pro/380 and see if the DECNA card works. >> >> What a pain in the rear. >> >> So far the XE boots but has no setup. Setup requires a special floppy >> (Diagnostic disk) which mine was bad after 30 years so I'm trying to >> create a new one. I have the official Compaq disk creation thing for a >> floppy but it's in QRST format and the QRST under DOSBOX on Windows10 >> can't properly access a floppy even if "mounted" with a -t floppy >> extension. >> >> Before I drag out my rusty and trusty Windows 95 Toshiba 660AV laptop, >> is there another way to get this onto a floppy? I have an endless supply >> of Rpi's, and doing a DD from a .img file works fine but this of course >> is a QRST file. >> >> > You wanted a SETUP disk for a Deskpro/XE system, right? Like SP1363 as > listed here https://www.vogons.org/viewtopic.php?t=3D76542 ? I was able to > do this in Dosbox-X no problem: mount the local directory with sp1363.exe > as C: or whatever, attach a disk image to A:, and then let sp1363.exe > create the disk image on A: . You can then write the raw disk image to a > 1.44" floppy. > > Sorry, forgot the Dosbox-X link: https://dosbox-x.com/ -Henry --===============1548278932744916524==-- From cz@alembic.crystel.com Sun Feb 26 20:17:38 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 15:17:32 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0268482817162795472==" --===============0268482817162795472== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Henry! > You wanted a SETUP disk for a Deskpro/XE system, right?  Like SP1363 > as listed here https://www.vogons.org/viewtopic.php?t=76542 > ?  I was able to do > this in Dosbox-X no problem: mount the local directory with > sp1363.exe as C: or whatever, attach a disk image to A:, and then > let sp1363.exe create the disk image on A: .  You can then write the > raw disk image to a 1.44" floppy. Interesting. I was using DOSBOX, not DOSBOX-X. I tried downloading it, set the A: drive to be the USB a: drive, and it doesn't work. This time it bombs out with QRST transfer incomplete. So I restarted, copied one of the diagnostic floppy images I did have to a filename of xe.img, mounted it in dosbox-x with the imgmount a (filename) command, then ran QRST and it seems to have worked. So if you try to use a USB floppy it can't see it, but if you use an image file it can. I wonder if Dosbox sees the external floppy as a SCSI device, but when you do an imgmount it knows to use the real, crappy DMA based routines to access the image file. Off to copy the image file to the pi, then to the USB floppy, then maybe to get the XE running. Fascinating, and thank yoU! CZ --===============0268482817162795472==-- From bitwiz@12bitsbest.com Sun Feb 26 21:23:09 2023 From: bitwiz@12bitsbest.com To: cctalk@classiccmp.org Subject: [cctalk] Serial Disk scipts Date: Sun, 26 Feb 2023 12:36:02 -0800 Message-ID: <12c4b2622efa265ee33e11f31cac99f4@12bitsbest.com> In-Reply-To: <167735726180.1516385.9460874746463602921@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4999606961200772953==" --===============4999606961200772953== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Attached are two bash scripts (tested on Raspberry Pi OS) for serial disk. run each script with sudo ./. If an existing os8diskserver directory is present it will be renamed and a new copy installed. getos8diskserver -- installs all of the necessary files to build the os8diskserver and the os8diskserver source itself. makeos8diskserver -- builds os8diskserver, installs a local copy of simh and builds a serial disk bootable image as well as several other rk05 images and creates a script to start os8serial disk with the default RK05 images. Feel free to fold, spindle and mutilate this. Please let me know if you find any bugs, have any suggestions or make any generic modifications. I'm hoping to get this into the os8diskserver github as soon as I get a chance to create a pull request Note: This is also being cross posted to the VCF DEC forum. Please post this to any other forums or mailing lists you feel are appropriate. Mike --===============4999606961200772953==-- From spectre@floodgap.com Sun Feb 26 21:25:52 2023 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Tadpole RISC laptop RAM modules Date: Sun, 26 Feb 2023 13:16:51 -0800 Message-ID: <7a2f7329-f61b-79a1-7ce7-00edefabf930@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4864985746857751217==" --===============4864985746857751217== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, this is the second Tadpole laptop RAM module I've had go bad on me (one in my PA-RISC PrecisionBook and now one in my SPARC UltraBook IIi). These are the maroon-red 256MB or 512MB screw-in modules marked "Huxley Only" using a custom friction fit connector, not regular SO-DIMMs. I can't find an obvious part number on them and searching for Tadpole RAM modules just finds the rinkydink 8MB parts for the earlier SPARCbooks. Anyone know someone who carries them, or better still, is willing to sell some they have? Looking for a 256MB module but a 512MB module would be even better. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Put your Nose to the Grindstone! -- Plastic Surgeons-Toolmakers Union Ltd.= - --===============4864985746857751217==-- From wayne.sudol@hotmail.com Sun Feb 26 21:44:22 2023 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 21:44:16 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5427078095892820516==" --===============5427078095892820516== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Your troubles with USB floppy drives reinforces my own experiences. They seem= to work okay in windows using a Microsoft written utility but not too well i= n dos or user written programs. It=E2=80=99s hit or miss as to if the program= will see the usb floppy. However, using a builtin floppy always seems to wor= k.=20 Sent from my iPhone > On Feb 26, 2023, at 12:17, Chris Zach via cctalk = wrote: >=20 > =EF=BB=BFHi Henry! >=20 >> You wanted a SETUP disk for a Deskpro/XE system, right? Like SP1363 >> as listed here https://www.vogons.org/viewtopic.php?t=3D76542 >> ? I was able to do >> this in Dosbox-X no problem: mount the local directory with >> sp1363.exe as C: or whatever, attach a disk image to A:, and then >> let sp1363.exe create the disk image on A: . You can then write the >> raw disk image to a 1.44" floppy. >=20 > Interesting. I was using DOSBOX, not DOSBOX-X. I tried downloading it, set = the A: drive to be the USB a: drive, and it doesn't work. This time it bombs = out with QRST transfer incomplete. >=20 > So I restarted, copied one of the diagnostic floppy images I did have to a = filename of xe.img, mounted it in dosbox-x with the imgmount a (filename) com= mand, then ran QRST and it seems to have worked. >=20 > So if you try to use a USB floppy it can't see it, but if you use an image = file it can. I wonder if Dosbox sees the external floppy as a SCSI device, bu= t when you do an imgmount it knows to use the real, crappy DMA based routines= to access the image file. >=20 > Off to copy the image file to the pi, then to the USB floppy, then maybe to= get the XE running. Fascinating, and thank yoU! >=20 > CZ --===============5427078095892820516==-- From doc@vaxen.net Sun Feb 26 23:15:27 2023 From: Doc Shipley To: cctalk@classiccmp.org Subject: [cctalk] Re: Tadpole RISC laptop RAM modules Date: Sun, 26 Feb 2023 17:15:19 -0600 Message-ID: In-Reply-To: <7a2f7329-f61b-79a1-7ce7-00edefabf930@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4433804311667346023==" --===============4433804311667346023== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/26/23 15:16, Cameron Kaiser via cctalk wrote: > Well, this is the second Tadpole laptop RAM module I've had go bad on me (o= ne > in my PA-RISC PrecisionBook and now one in my SPARC UltraBook IIi). These a= re > the maroon-red 256MB or 512MB screw-in modules marked "Huxley Only" using a > custom friction fit connector, not regular SO-DIMMs. I can't find an obvious > part number on them and searching for Tadpole RAM modules just finds the > rinkydink 8MB parts for the earlier SPARCbooks. >=20 > Anyone know someone who carries them, or better still, is willing to sell s= ome > they have? Looking for a 256MB module but a 512MB module would be even bett= er. Izzat a "SPARCBook II"? If so, I have one with 2 drives, and the=20 /usr drive is failing. I can replace that but I have no idea how to=20 reinstall SunOS/Solaris/Whatever. I don't have a floppy drive or the=20 SCSI dongle. Help? You also have the only other PrecisionBook I've ever heard of. Doc --===============4433804311667346023==-- From ethan@757.org Sun Feb 26 23:23:51 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: Tadpole RISC laptop RAM modules Date: Sun, 26 Feb 2023 18:23:40 -0500 Message-ID: In-Reply-To: <7a2f7329-f61b-79a1-7ce7-00edefabf930@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8486885085258664821==" --===============8486885085258664821== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Well, this is the second Tadpole laptop RAM module I've had go bad on me (o= ne > in my PA-RISC PrecisionBook and now one in my SPARC UltraBook IIi). These a= re > the maroon-red 256MB or 512MB screw-in modules marked "Huxley Only" using a > custom friction fit connector, not regular SO-DIMMs. I can't find an obvious > part number on them and searching for Tadpole RAM modules just finds the > rinkydink 8MB parts for the earlier SPARCbooks. Can you tell if it's one of the DRAM ICs or if it's the connector? Deoxit=20 on the connector then reseat? - Ethan -- : Ethan O'Toole --===============8486885085258664821==-- From spectre@floodgap.com Sun Feb 26 23:26:24 2023 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Tadpole RISC laptop RAM modules Date: Sun, 26 Feb 2023 15:26:16 -0800 Message-ID: <7db617f4-9ccc-2dc1-a3f4-10ccbf2a71ee@floodgap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3602508638164957892==" --===============3602508638164957892== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> Well, this is the second Tadpole laptop RAM module I've had go bad on me (= one >> in my PA-RISC PrecisionBook and now one in my SPARC UltraBook IIi). These = are >> the maroon-red 256MB or 512MB screw-in modules marked "Huxley Only" using a >> custom friction fit connector, not regular SO-DIMMs. I can't find an obvio= us >> part number on them and searching for Tadpole RAM modules just finds the >> rinkydink 8MB parts for the earlier SPARCbooks. >=20 > Can you tell if it's one of the DRAM ICs or if it's the connector? Deoxit on > the connector then reseat? I don't think it's the connector, but it's junk if it isn't anyway, so I might see. These things screw in place and the fit was tight getting it out so it would boot again, so I don't think it wiggled. Still, would be nice to know a source for spares because it seems like others on this list have had similar problems with theirs. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Queen, you shall be it if you wish/Look for your king -- Pink Floyd ------= -- --===============3602508638164957892==-- From ethan@757.org Sun Feb 26 23:27:47 2023 From: Ethan O'Toole To: cctalk@classiccmp.org Subject: [cctalk] Re: Tadpole RISC laptop RAM modules Date: Sun, 26 Feb 2023 18:27:42 -0500 Message-ID: <755fc6f9-38d9-746-ce19-b5e1bcd71c68@757.org> In-Reply-To: <7db617f4-9ccc-2dc1-a3f4-10ccbf2a71ee@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7065005857133181439==" --===============7065005857133181439== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I don't think it's the connector, but it's junk if it isn't anyway, so I mi= ght > see. These things screw in place and the fit was tight getting it out so it > would boot again, so I don't think it wiggled. Still, would be nice to know= a > source for spares because it seems like others on this list have had similar > problems with theirs. It might be possible to transplant DRAM ICs from other SIMMS onto the=20 Tadpole memory modules to refurbish them. - Ethan -- : Ethan O'Toole --===============7065005857133181439==-- From spectre@floodgap.com Sun Feb 26 23:32:04 2023 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Tadpole RISC laptop RAM modules Date: Sun, 26 Feb 2023 15:31:56 -0800 Message-ID: In-Reply-To: <755fc6f9-38d9-746-ce19-b5e1bcd71c68@757.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5500571099117216199==" --===============5500571099117216199== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> I don't think it's the connector, but it's junk if it isn't anyway, so I m= ight >> see. These things screw in place and the fit was tight getting it out so it >> would boot again, so I don't think it wiggled. Still, would be nice to kno= w a >> source for spares because it seems like others on this list have had simil= ar >> problems with theirs. >=20 > It might be possible to transplant DRAM ICs from other SIMMS onto the Tadpo= le > memory modules to refurbish them. I think that's possible, but it would need someone with better soldering skil= ls than I've got. I draw the line at surface mount; I've wrecked boards before, and this module has 18 Hitachi DRAM chips on it (parity). --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- If I am not for myself, who will be for me? -- Pirkei Avot ---------------= -- --===============5500571099117216199==-- From cisin@xenosoft.com Sun Feb 26 23:55:54 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Booting from B: (Was: Getting QRST files onto Date: Sun, 26 Feb 2023 15:55:49 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6216566957697882494==" --===============6216566957697882494== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Which versions of DOS let you boot off B: ? CORRECTION: Although the default of DOS used to be A: then first HDD (usually C:), it is the computer firmware, not DOS that decides that. The assumption that C: is the HDD can be annoying. I used to use PCs with four floppies. If jumpered properly, the HDD was E:. Many "modern" PCs, within the "CMOS" setup, have provision for changing the boot sequence. Mostly, in order to default to booting from HDD, rather than floppy, but also for CD or USB boot. I do not know of any that permit selecting floppy B: for boot, but there could exist some with that option, . . . On a PC with a single physical floppy, asking for any command with B: will trigger a prompt to put the B: disk in drive A:, and have a phantom B: that shares the physical drive with A: Swapping A: and B: is, of course, trivial to do with hardware, and/or messing with the cable. (pin 10 of the cable [at the FDC] is A: and 12 is B:, but the usual supplied cables are twisted and missing pins so that every drive, on the drive itself is jumpered as if it were B:). An untwisted cable, with switch[es] would be one way. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============6216566957697882494==-- From rick@rickmurphy.net Mon Feb 27 00:05:11 2023 From: Rick Murphy To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Sun, 26 Feb 2023 19:05:03 -0500 Message-ID: <3bba9c83-d578-2b15-0c13-d037c1acbe4e@rickmurphy.net> In-Reply-To: <779774cc-6582-237c-13ed-0db63e4ebf23@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4106116369229515958==" --===============4106116369229515958== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/26/2023 9:47 AM, Vincent Slyngstad via cctalk wrote: > On 2/26/2023 1:15 AM, jos via cctalk wrote: >> On 25.02.23 18:52, silvercreekvalley--- via cctalk wrote: >>> Thanks Vince - I knew about the RX emulators but not the serial disk >>> - that sounds interesting. Is there any documentation on that - I >>> had a look at the GitHub but seemed a bit sparse. >>> >>> I can imagine the FFP8/A is hard to find and replicate. I can >>> probably use emulation - but its nice to check with real hardware. >> >> This is probably not the right place to link the youtube video of the >> guy that destroyed a FPP8/A set to recover the gold on the >> PCB-fingers... >> >> I do have a rather complete 8/A, with RL01 ad FPP8/A. Alas no sockets >> inside so the PROMs cannot easily be read out. > > Too bad we probably can't get the damaged board to image the PROMS and > programmable parts. The source code for the FPP8-A is available - I retyped it while trying to debug the SIMH FPP code. Getting that source into a binary is a exercise for the reader. :) Apparently the compiler for this ran on TOPS-10. The maintenance docs for the FPP8-A give enough information to reverse engineer the programmable bits.     -Rick --===============4106116369229515958==-- From bitwiz@12bitsbest.com Mon Feb 27 00:41:31 2023 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Serial Disk scipts Date: Sun, 26 Feb 2023 18:41:22 -0600 Message-ID: <2de0085f-1ede-122d-e076-b385f502c262@12bitsbest.com> In-Reply-To: <12c4b2622efa265ee33e11f31cac99f4@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5562008348057940220==" --===============5562008348057940220== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Apparently the attachments didn't make it through the email server.=20 Please email me directly for the two scripts. Thanks, =C2=A0=C2=A0=C2=A0=C2=A0 mike =C2=A0=C2=A0=C2=A0 bitwiz(a)12bitsbest.com On 2/26/2023 2:36 PM, Mike Katz via cctalk wrote: > Attached are two bash scripts (tested on Raspberry Pi OS) for serial=20 > disk. > > run each script with sudo ./. > > If an existing os8diskserver directory is present it will be renamed=20 > and a new copy installed. > > getos8diskserver=C2=A0 -- installs all of the necessary files to build the = > os8diskserver and the os8diskserver source itself. > makeos8diskserver -- builds os8diskserver, installs a local copy of=20 > simh and builds a serial disk bootable image as well as several other=20 > rk05 > =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 images and creates a script to = start os8serial=20 > disk with the default RK05 images. > > > Feel free to fold, spindle and mutilate this. > > Please let me know if you find any bugs, have any suggestions or make=20 > any generic modifications. > > I'm hoping to get this into the os8diskserver github as soon as I get=20 > a chance to create a pull request > > Note:=C2=A0=C2=A0 This is also being cross posted to the VCF DEC forum. Ple= ase=20 > post this to any other forums or mailing lists you feel are appropriate. > > =C2=A0=C2=A0 Mike > > > > --===============5562008348057940220==-- From cz@alembic.crystel.com Mon Feb 27 03:15:49 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Better way to extract these TD0 images for P/OS. Date: Sun, 26 Feb 2023 22:15:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7963191111102703048==" --===============7963191111102703048== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Ok, so after pouting for awhile after destroying my only Teac 1.2mb 5.25 drive (old floppies are garbage) I sat for awhile and thought about this whole issue. The goal is simple: Install P/OS 3.2 on my Pro/380 but doing 21 floppies for the base OS, another 20 or so for the Toolkit, and God knows how many for the layered applications is, shall we say, for the birds. I feel like a spaceman trying to start a fire on the moon by banging rocks together. There needs to be a better way. So I looked around some more and finally found a program. Someone wrote it, called SAMDISK. From the "World of Sam" https://www.worldofsam.org/products/samdisk-utility Downloaded it to Windows10, fired it up (CMD mode only, thank God) and typed: samdisk 177-21.td0 disk0021.dsk And sure enough a 430,336 byte image popped up in my directory. Moved it to a USB, put it in my Gotek/Flashfloppy, fired up my pdp11/73 running RSX111M+, and did a mount DU1: /over It mounted. $ mount du1: /over $ dir du1:[*,*] Directory DU1:[ZZSYS] 26-FEB-2023 22:09 POSRES.TSK;1 42. C 23-JUN-1987 14:51 POS.SYS;1 441. C 23-JUN-1987 14:51 STARTUP.TSK;1 19. C 23-JUN-1987 14:52 SASCOM.TSK;1 4. C 23-JUN-1987 14:52 SAS.COM;1 1. 23-JUN-1987 14:52 SIR.TSK;1 74. C 23-JUN-1987 14:52 Total of 581./581. blocks in 6. files Directory DU1:[1,54] 26-FEB-2023 22:09 SIR.MSG;1 17. 23-JUN-1987 14:52 SIR.MNU;1 5. 23-JUN-1987 14:52 SIR.HLP;1 10. 23-JUN-1987 14:52 SCRIPT.COM;1 23. 23-JUN-1987 14:52 Total of 55./55. blocks in 4. files Grand total of 636./636. blocks in 10. files in 2. directories That is the first disk in the POS series. So we know that this tool can work to turn thse stupid TD0 files into images that we can use. Now to convert the rest of the files, and get a second Gotek. Because I am going to need to run two of them to emulate the two RX50's on a Pro/380. If I set one as drive 0, the second as drive 1, and use a straight 34 pin ribbon cable it might work..... Never dull. But this is a far less painful solution than screwing around with 100 floppy disks. CZ --===============7963191111102703048==-- From imp@bsdimp.com Mon Feb 27 04:11:41 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Getting QRST files onto a floppy (sigh) Date: Sun, 26 Feb 2023 21:11:29 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181DB8A3218A288B6132149E4AE9=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9114072500117604317==" --===============9114072500117604317== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable USB floopies are not general purpose devices. They have a fixed number of formats that work, and the rest do not. Warner On Sun, Feb 26, 2023 at 2:44=E2=80=AFPM Wayne S via cctalk wrote: > Your troubles with USB floppy drives reinforces my own experiences. They > seem to work okay in windows using a Microsoft written utility but not too > well in dos or user written programs. It=E2=80=99s hit or miss as to if the= program > will see the usb floppy. However, using a builtin floppy always seems to > work. > > Sent from my iPhone > > > On Feb 26, 2023, at 12:17, Chris Zach via cctalk > wrote: > > > > =EF=BB=BFHi Henry! > > > >> You wanted a SETUP disk for a Deskpro/XE system, right? Like SP1363 > >> as listed here https://www.vogons.org/viewtopic.php?t=3D76542 > >> ? I was able to do > >> this in Dosbox-X no problem: mount the local directory with > >> sp1363.exe as C: or whatever, attach a disk image to A:, and then > >> let sp1363.exe create the disk image on A: . You can then write the > >> raw disk image to a 1.44" floppy. > > > > Interesting. I was using DOSBOX, not DOSBOX-X. I tried downloading it, > set the A: drive to be the USB a: drive, and it doesn't work. This time it > bombs out with QRST transfer incomplete. > > > > So I restarted, copied one of the diagnostic floppy images I did have to > a filename of xe.img, mounted it in dosbox-x with the imgmount a (filename) > command, then ran QRST and it seems to have worked. > > > > So if you try to use a USB floppy it can't see it, but if you use an > image file it can. I wonder if Dosbox sees the external floppy as a SCSI > device, but when you do an imgmount it knows to use the real, crappy DMA > based routines to access the image file. > > > > Off to copy the image file to the pi, then to the USB floppy, then maybe > to get the XE running. Fascinating, and thank yoU! > > > > CZ > --===============9114072500117604317==-- From bobsmithofd@gmail.com Mon Feb 27 04:46:31 2023 From: Bob Smith To: cctalk@classiccmp.org Subject: [cctalk] PDP-8/A FPP8/A Date: Sun, 26 Feb 2023 23:47:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0986435292326591395==" --===============0986435292326591395== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Don White designed the FPP8/A. From my recollection, the unit that was sold with 8/A was the second iteration of an Omnibus FPP8. I waa off in LCG working on Jupiter so I never got to see the original but I recall that the redesign to use the cycle stealing version that went to market was because the original 8/A version was too "powerful" meaning that it out performed all of the PDP-11 FPP units and was more precise. I recall it was capable of 72 bit vice 36 bit max operations. The marketed design was a cost reduced and really an extraordinary simple design, elegant would be a better description. I seem to recall the original was built around either ALU or 4 bit Slice chips like AMD2901 or some variation of a TRW chip. bob --===============0986435292326591395==-- From cz@beaker.crystel.com Mon Feb 27 06:22:59 2023 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Need a 1.2mb 5.25 floppy Date: Sun, 26 Feb 2023 19:42:25 -0500 Message-ID: <391917ba-9589-cf6c-55df-d7d046b78859@beaker.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8764327007499921150==" --===============8764327007499921150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Oi. So after finally getting things going I started copying the Pro/380 OS files to a bunch of 1.2mb floppies. Great. However after a bit I started getting errors, and found that the disks were getting gouges in the tracks. Sure enough disassembly of my 1.2mb Teac showed that debris had become embedded in the disk head and cleaning is not possible. Terrific. Tossing the drive, this is not the first time I have had this problem with these disks so I am dumpstering all of the old floppies and just bought 40 new ones in sealed boxes. However I'm now in need of a 1.2mb floppy drive. Anyone have a good working spare that I can beg/borrow/buy in the MD area? Thanks! CZ (I really should have pitched these disks; they came from a basement with an oil heater for 20 years and are quite honestly garbage. Only thing worse were disks from Solarex which literally had silicon dust on them that chewed any drive. Oh well, live and learn) --===============8764327007499921150==-- From cclist@sydex.com Mon Feb 27 07:06:28 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Sun, 26 Feb 2023 23:06:15 -0800 Message-ID: In-Reply-To: <391917ba-9589-cf6c-55df-d7d046b78859@beaker.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1550650077601650564==" --===============1550650077601650564== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/26/23 16:42, Chris Zach via cctalk wrote: > Oi. > > So after finally getting things going I started copying the Pro/380 OS > files to a bunch of 1.2mb floppies. Great. However after a bit I started > getting errors, and found that the disks were getting gouges in the > tracks. Sure enough disassembly of my 1.2mb Teac showed that debris had > become embedded in the disk head and cleaning is not possible. > > Terrific. Tossing the drive, this is not the first time I have had this > problem with these disks so I am dumpstering all of the old floppies and > just bought 40 new ones in sealed boxes. > > However I'm now in need of a 1.2mb floppy drive. Anyone have a good > working spare that I can beg/borrow/buy in the MD area? I thought the Pro 300 series used RX-50 drives; i.e. 400K 96 tpi DD media. So even with your 5.25" HD drive, you should be using DD ("360K") floppies. You can also use a 3.5" drive running in DD mode. FWIW, --Chuck --===============1550650077601650564==-- From jakeutley@outlook.com Mon Feb 27 10:29:33 2023 From: jake utley To: cctalk@classiccmp.org Subject: [cctalk] Research machines RM 380 Date: Mon, 27 Feb 2023 10:29:27 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6537381067835679718==" --===============6537381067835679718== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve been restoring a RM380 I picked up not long ago and it=E2=80=99s= been good news and bad news. All the cards are in wonderful condition and th= e case is presentable however the two BASF 6106 floppy drives are highly corr= oded and probably won=E2=80=99t work again but this isn=E2=80=99t what I=E2= =80=99m wondering, the original supply is a little rough but looks tone perfe= ctly restorable with the exception of the key lock been stuck (problem to sol= ve later) and I can get all the parts needed to replace the three filters but= it is a 70s linear supply and if my s-100 experience has told me anything th= ey might not be the most reliable. What would you all recommend restoring it = and keeping it original or fitting some modern SMPS in its place. It is a low= serial number as well (691) but saying I want it to be reliable I=E2=80=99m = torn. --===============6537381067835679718==-- From ard.p850ug1@gmail.com Mon Feb 27 13:32:38 2023 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Research machines RM 380 Date: Mon, 27 Feb 2023 13:32:21 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CLO2P123MB399867B40EC2785D870CB660A8AF9=40LO2P123MB?= =?utf-8?q?3998=2EGBRP123=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3254363898426206420==" --===============3254363898426206420== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2023 at 10:29=E2=80=AFAM jake utley via cctalk wrote: > > I=E2=80=99ve been restoring a RM380 I picked up not long ago and it=E2=80= =99s been good news and bad news. All the cards are in wonderful condition an= d the case is presentable however the two BASF 6106 floppy drives are highly = corroded and probably won=E2=80=99t work again but this isn=E2=80=99t what I= =E2=80=99m wondering, the original supply is a little rough but looks tone pe= rfectly restorable with the exception of the key lock been stuck (problem to = solve later) and I can get all the parts needed to replace the three filters = but it is a 70s linear supply and if my s-100 experience has told me anything= they might not be the most reliable. What would you all recommend restoring = it and keeping it original or fitting some modern SMPS in its place. It is a = low serial number as well (691) but saying I want it to be reliable I=E2=80= =99m torn. I would certanly recomend keeping it original. My experience is that a linear supply, although less efficient than a switch mode one, is a lot more reliable. There's a joke about the crazy PSU in the Zenith ZVM1220 MDA monitor thst said unit combines 'The reliability of a switcher with the efficiency of a linear'. It's also a lot easier to fix a linear supply than a switcher and there are not high voltages on any of the semiconductors. Getting back to the 380Z, there's a schematic of one version in the service manuall. But even if it doesn't agree, you can trace out a schematic in under an hour and that's going slowly. It is a very simple unit using normal 3-terminal regulators in the standard way. I'd 'megger' the transformer just to be safe as the machine seems to have been stored in poor conditions. Then power it up with a 'lamp limiter' on the mains input and no load on the output (unplug the cables from the driives and the 1 or 2 10-way ribbon cables from the PCBs). Most likely it will be fine, even with the original smoothing capacitors. -tony --===============3254363898426206420==-- From imp@bsdimp.com Mon Feb 27 14:50:41 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 07:50:29 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1818371887601856807==" --===============1818371887601856807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 27, 2023 at 12:06 AM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 2/26/23 16:42, Chris Zach via cctalk wrote: > > Oi. > > > > So after finally getting things going I started copying the Pro/380 OS > > files to a bunch of 1.2mb floppies. Great. However after a bit I started > > getting errors, and found that the disks were getting gouges in the > > tracks. Sure enough disassembly of my 1.2mb Teac showed that debris had > > become embedded in the disk head and cleaning is not possible. > > > > Terrific. Tossing the drive, this is not the first time I have had this > > problem with these disks so I am dumpstering all of the old floppies and > > just bought 40 new ones in sealed boxes. > > > > However I'm now in need of a 1.2mb floppy drive. Anyone have a good > > working spare that I can beg/borrow/buy in the MD area? > > I thought the Pro 300 series used RX-50 drives; i.e. 400K 96 tpi DD > media. So even with your 5.25" HD drive, you should be using DD > ("360K") floppies. > You should be using QD floppies, but those are rare. DD floppies from later than 1985 though work just fine (discovered empirically while a poor college student, reconfirmed recently when I made all those Venix disks). However, in a PC, to write these diskettes, you need a 1.2M drive. While there is a couple of TEAC drives (55FR I think) that do 80-tracks at the DD/QD RPM and data rates, things get fussy putting them into PCs. And last time I looked they were 5x the price of ye-olde-generic 1.2M floppy drive. As long as it's formatted at the right density/rpm rates, it's fine. And RX50.SYS, if memory serves, does all that right. Using 3.5" drives in double density mode will work, but there's a cascade of software issues you'll have to deal with. I booted my DEC Rainbow with these and some hacks from someone in the Jemez Mountains to do double sided on MS-DOS (which reminds me, I have the hacks still, and they also have a now lost-ish BIOS listing for 3.10b, so I should see if I can post that for the few people still interested).I've never done it on a PRO though. I'm out in Colorado, or I'd happily give you one of my spares. Warner --===============1818371887601856807==-- From spectre@floodgap.com Mon Feb 27 16:04:22 2023 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] WTB: Accutech Gobi (Gobi7 or Gobi8) Date: Mon, 27 Feb 2023 08:04:14 -0800 Message-ID: <30e06175-7eee-d442-546d-f9b1591f1342@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8252592813319314194==" --===============8252592813319314194== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, the weekend of hardware sudden death continues. The reason for getting the UltraBook IIi out was to do some more work on kOpenRay, the free Sun Ray server software I very occasionally maintain. Among other devices I use(d) two Accutech Gobi laptops to talk to it since they have an oddball VPN setup that used to cause problems. Unfortunately, neither will configure their network interfaces anymore and ju= st hang. The board is of course a cheap mass of unrepairable components. If anyone has an Accutech Gobi (either the 7 or 8 model, both will suffice, I don't need the 3.5G module but will use it if it's there) sitting around gathering dust, I'd love to buy it off you. I have the power supply and batteries already. Southern California. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- And now for something completely different. -- Monty Python --------------= -- --===============8252592813319314194==-- From cclist@sydex.com Mon Feb 27 16:30:35 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 08:30:22 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8091032805869775740==" --===============8091032805869775740== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/27/23 06:50, Warner Losh wrote: > You should be using QD floppies, but those are rare. DD floppies from > later than > 1985 though work just fine (discovered empirically while  a poor college > student, > reconfirmed recently when I made all those Venix disks). Speaking from experience and consultations during the 1970s with engineers from Dysan (we were using 100 tpi drives), the only difference between QD and DD floppies is QA step--QD ones are usually verified at 96 or 100 tpi, the DD ones at 48 tpi. The brown goo spread on the doughnut is exactly the same. If one purchased factory-formatted diskettes for a specific platform, of course the formatting would be different depending on the platform. Similarly SS and DS diskettes are identical; early on, ones with verification errors on one side were "flipped" accordingly and sold as SS. As techniques improved, the only difference became the label. FWIW, Chuck --===============8091032805869775740==-- From imp@bsdimp.com Mon Feb 27 17:31:10 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 10:30:51 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8001867058490441611==" --===============8001867058490441611== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Feb 27, 2023 at 9:30 AM Chuck Guzis wrote: > On 2/27/23 06:50, Warner Losh wrote: > > > You should be using QD floppies, but those are rare. DD floppies from > > later than > > 1985 though work just fine (discovered empirically while a poor college > > student, > > reconfirmed recently when I made all those Venix disks). > > Speaking from experience and consultations during the 1970s with > engineers from Dysan (we were using 100 tpi drives), the only difference > between QD and DD floppies is QA step--QD ones are usually verified at > 96 or 100 tpi, the DD ones at 48 tpi. The brown goo spread on the > doughnut is exactly the same. > Prior to about 1984 or 85, the failure rate for DD floppies for me was high enough that I splurged for the QD. After 84 or 85, I never had any problems using DD media. I suspect that yields must have gotten better, but maybe I just had bad luck prior to going to college... > If one purchased factory-formatted diskettes for a specific platform, of > course the formatting would be different depending on the platform. > True. For the Rainbow I was always reformatting because nobody sold pre-formatted Rainbow disks at a price that was sane. > Similarly SS and DS diskettes are identical; early on, ones with > verification errors on one side were "flipped" accordingly and sold as > SS. As techniques improved, the only difference became the label. > I believe that.. Warner --===============8001867058490441611==-- From cclist@sydex.com Mon Feb 27 17:54:47 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 09:54:35 -0800 Message-ID: <4140cea3-c6f6-3d3f-7bb9-795f6ac413d3@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1354387979270687760==" --===============1354387979270687760== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/27/23 09:30, Warner Losh wrote: > > Prior to about 1984 or 85, the failure rate for DD floppies for me was > high enough that I splurged for the QD. After 84 or 85, I never had any > problems > using DD media. I suspect that yields must have gotten better, but maybe I > just had bad luck prior to going to college... There was a lot of junk in the floppy arena in the early days. The brands that vanished were numerous. Brown, Elephant...all terrible. If I look at my 5.25" archives, most early survivors are 3M, Dysan or Verbatim. A few Xidex. All of the off-brands have eventually failed and been weeded out. Wabash was legendary in its awfulness in the 5.25" area. Of course, if you're going to use DD floppies in an RX50 drive, you'll need to purchase some stick-on arrows... --Chuck --===============1354387979270687760==-- From paulkoning@comcast.net Mon Feb 27 17:55:32 2023 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 12:55:24 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8974230119032955441==" --===============8974230119032955441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 27, 2023, at 9:50 AM, Warner Losh via cctalk wrote: >=20 > On Mon, Feb 27, 2023 at 12:06=E2=80=AFAM Chuck Guzis via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 >> ... >> I thought the Pro 300 series used RX-50 drives; i.e. 400K 96 tpi DD >> media. So even with your 5.25" HD drive, you should be using DD >> ("360K") floppies. Yes, the Pro uses RX50 drives. > You should be using QD floppies, but those are rare. DD floppies from later > than > 1985 though work just fine (discovered empirically while a poor college > student, > reconfirmed recently when I made all those Venix disks). >=20 > However, in a PC, to write these diskettes, you need a 1.2M drive. While > there is a couple of TEAC drives (55FR I think) that do 80-tracks at the > DD/QD > RPM and data rates, things get fussy putting them into PCs. And last time > I looked they were 5x the price of ye-olde-generic 1.2M floppy drive. As > long > as it's formatted at the right density/rpm rates, it's fine. And RX50.SYS, > if memory serves, does all that right. I don't understand that. I have a plain old Gateway PC with a twin floppy dr= ive (3.5 and 5.25 pair). It defaults to PC format 9 sectors per track, of co= urse. But it's quite happy to be told to do 10 sectors per track, reading or= writing. I first did so using DOS with INT13 I/O, then in Linux with a fdpa= rm operation, and finally in C or Python by issuing an appropriate FDSETPRM i= octl. Works great. You can find the machinery in my "flx" utility (for operating on RSTS file sy= stems); it handles both container files and actual RX50 format floppies. Thi= s is how I write disks for my Pro to consume. paul --===============8974230119032955441==-- From cc@informatik.uni-stuttgart.de Mon Feb 27 18:10:55 2023 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 19:10:33 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0116995488947367304==" --===============0116995488947367304== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 27 Feb 2023, Warner Losh wrote: > You should be using QD floppies, but those are rare. DD floppies from > later than 1985 though work just fine (discovered empirically while a Are they? I guess that I have at least as many QD floppies as DD, if not even more. :-) > However, in a PC, to write these diskettes, you need a 1.2M drive. While > there is a couple of TEAC drives (55FR I think) that do 80-tracks at the > DD/QD RPM and data rates, things get fussy putting them into PCs. And > last time I looked they were 5x the price of ye-olde-generic 1.2M floppy > drive. As long as it's formatted at the right density/rpm rates, it's > fine. And RX50.SYS, if memory serves, does all that right. When giving an advise, it should be as correct as possible ;-)) So no, you don't need a "1.2M drive" (i.e. high density). You just need a 96 tpi drive. And the drive is totally (well, almost) ignorant of the data rate. It is just spinning the media at a specific velocity (300 or 360 rpm). When using a 300 rpm drive, you need a 250 kHz data rate for DD (QD is the same, it's just a marketing name for 96 tpi DD). With 360 rpm you need a 300 kHz data rate. It only gets a little bit complicated if you jumper a high-density drive for dual-speed mode (300 rpm if DD, 360 rpm if HD). > Using 3.5" drives in double density mode will work, but there's a cascade > of software issues you'll have to deal with. I booted my DEC Rainbow with It would be the same for a normal 5¼" double sided drive. IIRC the trick is to combine the RX50 specific drive selects to one drive select and one head select. The software should not know anything about this. Drive 0 would be side 0, and drive 1 side 1. Christian --===============0116995488947367304==-- From silvercreekvalley@yahoo.com Mon Feb 27 18:27:58 2023 From: silcreval To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-8/A FPP8/A Date: Mon, 27 Feb 2023 18:27:52 +0000 Message-ID: <4EF3AB13-972C-4EE0-8105-C11128DA4BFA@yahoo.com> In-Reply-To: <4EF3AB13-972C-4EE0-8105-C11128DA4BFA.ref@yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3230953958084334709==" --===============3230953958084334709== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Bob Thanks - thats very interesting. I guess there was quite a bit of overlap wit= h the 11 and the 8/A so 'marketing' stepped in :-) --===============3230953958084334709==-- From silvercreekvalley@yahoo.com Mon Feb 27 18:29:54 2023 From: silcreval To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB Any storage for a PDP 8/A Date: Mon, 27 Feb 2023 18:29:42 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4996746971674871522==" --===============4996746971674871522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Oh really - what a nightmare :/ - they are rare boards it seems. --===============4996746971674871522==-- From imp@bsdimp.com Mon Feb 27 18:49:31 2023 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 11:49:14 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4380559437654344597==" --===============4380559437654344597== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 27, 2023 at 11:10 AM Christian Corti via cctalk < cctalk(a)classiccmp.org> wrote: > On Mon, 27 Feb 2023, Warner Losh wrote: > > You should be using QD floppies, but those are rare. DD floppies from > > later than 1985 though work just fine (discovered empirically while a > > Are they? I guess that I have at least as many QD floppies as DD, if not > even more. :-) > I'd guess at least as many HD floppies, likely way more. QD was a pretty odd duck, and any > > However, in a PC, to write these diskettes, you need a 1.2M drive. While > > there is a couple of TEAC drives (55FR I think) that do 80-tracks at the > > DD/QD RPM and data rates, things get fussy putting them into PCs. And > > last time I looked they were 5x the price of ye-olde-generic 1.2M floppy > > drive. As long as it's formatted at the right density/rpm rates, it's > > fine. And RX50.SYS, if memory serves, does all that right. > > When giving an advise, it should be as correct as possible ;-)) > So no, you don't need a "1.2M drive" (i.e. high density). You just need a > 96 tpi drive. And the drive is totally (well, almost) ignorant of the data > rate. It is just spinning the media at a specific velocity (300 or 360 > rpm). When using a 300 rpm drive, you need a 250 kHz data rate for DD (QD > is the same, it's just a marketing name for 96 tpi DD). With 360 rpm you > need a 300 kHz data rate. It only gets a little bit complicated if you > jumper a high-density drive for dual-speed mode (300 rpm if DD, 360 rpm if > HD). > Correct. You don't need a 1.2M drive. That's true. However, getting the 96tpi QD 300prm 250kHz drives are a lot harder these days than finding an old 1.2M drive. I recently looked for the TEAC 55FR drives that I used back in the day, and could not find them at all. Found plenty of other TEAC 55xx drives that were all either '360k' or '1.2M' drives. So it was more of a practical bit of advice, than an absolute requirement... While several of the newer drives do allow dual speed operations, the floppy cables for the RX-50 drive don't have the necessary signals to switch them. IDrives used a transistor to switch the signals properly for these drives. I opted to use drives that didn't need this signal. For 3.5" drives, there weren't any hacks needed because that signal was ignored by most of the drives. I rarely used them on a PC back in the day, so I'll defer to others on that. > > Using 3.5" drives in double density mode will work, but there's a cascade > > of software issues you'll have to deal with. I booted my DEC Rainbow with > > It would be the same for a normal 5¼" double sided drive. IIRC the trick > is to combine the RX50 specific drive selects to one drive select and one > head select. The software should not know anything about this. Drive 0 > would be side 0, and drive 1 side 1. > The trick is just to use two double sided drives, the side select stuff is there, and you just need to jumper the drives to be ID0 and ID1 to get your A & B drives. You have to use for this, though, drives that can do 300rpm at 250kHz because that's what (at least the Rainbow) RX-50 controller puts out. I ran this way for many years, though the software changes to MS-DOS were a bit flakey for me, and I never found ones for CP/M. I only got the 3.5" floppy drives that were the lower density to work, since those were also 300rpm/250kHz. I never got the high density ones to work since at least the ones I looked at didn't have the density signal, nor density jumpers. Wrote a 'driver' for it called IMPDRIVE back in the day. Some 5.25" drives would work with it (like the TEAC 55FRs), but many would not. And my old FRs are toast and I've not been able to find good replacements to try this again... Warner --===============4380559437654344597==-- From bill.gunshannon@hotmail.com Mon Feb 27 19:06:11 2023 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 14:05:10 -0500 Message-ID: In-Reply-To: <4140cea3-c6f6-3d3f-7bb9-795f6ac413d3@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6205920772691187590==" --===============6205920772691187590== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/27/2023 12:54 PM, Chuck Guzis via cctalk wrote: > On 2/27/23 09:30, Warner Losh wrote: >> Prior to about 1984 or 85, the failure rate for DD floppies for me was >> high enough that I splurged for the QD. After 84 or 85, I never had any >> problems >> using DD media. I suspect that yields must have gotten better, but maybe I >> just had bad luck prior to going to college... > There was a lot of junk in the floppy arena in the early days. The > brands that vanished were numerous. Brown, Elephant...all terrible. That's funny.  I used lots of Elephant on my TRS-80's and never had a problem. Still have them and I can still read and write them without any problems. The only funny stuff I ran into was with 8" disks and the Terak. We  were having problems and talked to Terak about it and their solution was that we should be buying Terak Brand Disks. Yeah, right, like they ever actually made disks.... bill --===============6205920772691187590==-- From bitwiz@12bitsbest.com Mon Feb 27 20:20:33 2023 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 12:21:33 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8091303713880954512==" --===============8091303713880954512== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit As already said here most of the better DSDD diskettes could handle 48 or 96 TPI. The biggest problem I remember from that era (on 6809 Systems in the early '80s and early PC's) is intermixing 48 and 96 tpi drives and reading/writing both drives. Since the tracks are half as wide on the 96 TPI drive, if you format a disk on a 48 TPI drive and then write to it on a 96 PTI drive and then try to read it back on a 48 TPI drive, the reads may fail because the 96 TPI drive only wrote half of the track as seen by the 48 TPI drive.  When reading data on a 48PTI drive, the drive would see half the new data and half the old data. Also the 96 TPI drive needed to be double stepped to read a 48 TPI formatted diskette. On 2/27/2023 12:10 PM, Christian Corti via cctalk wrote: > On Mon, 27 Feb 2023, Warner Losh wrote: >> You should be using QD floppies, but those are rare. DD floppies from >> later than 1985 though work just fine (discovered empirically while a > > Are they? I guess that I have at least as many QD floppies as DD, if > not even more. :-) > >> However, in a PC, to write these diskettes, you need a 1.2M drive. >> While there is a couple of TEAC drives (55FR I think) that do >> 80-tracks at the DD/QD RPM and data rates, things get fussy putting >> them into PCs. And last time I looked they were 5x the price of >> ye-olde-generic 1.2M floppy drive. As long as it's formatted at the >> right density/rpm rates, it's fine. And RX50.SYS, if memory serves, >> does all that right. > > When giving an advise, it should be as correct as possible ;-)) > So no, you don't need a "1.2M drive" (i.e. high density). You just > need a 96 tpi drive. And the drive is totally (well, almost) ignorant > of the data rate. It is just spinning the media at a specific velocity > (300 or 360 rpm). When using a 300 rpm drive, you need a 250 kHz data > rate for DD (QD is the same, it's just a marketing name for 96 tpi > DD). With 360 rpm you need a 300 kHz data rate. It only gets a little > bit complicated if you jumper a high-density drive for dual-speed mode > (300 rpm if DD, 360 rpm if HD). > >> Using 3.5" drives in double density mode will work, but there's a >> cascade >> of software issues you'll have to deal with. I booted my DEC Rainbow >> with > > It would be the same for a normal 5¼" double sided drive. IIRC the > trick is to combine the RX50 specific drive selects to one drive > select and one head select. The software should not know anything > about this. Drive 0 would be side 0, and drive 1 side 1. > > Christian --===============8091303713880954512==-- From bear@typewritten.org Mon Feb 27 21:01:17 2023 From: "r.stricklin" To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 12:55:04 -0800 Message-ID: <4BD31909-E397-4911-AD3D-9B2A0E9B1ABB@typewritten.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6410628825345822324==" --===============6410628825345822324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 27, 2023, at 10:21 AM, Mike Katz via cctalk wrote: >=20 > the drive would see half the new data and half the old data. I think that explaining it this way can easily lead to an incorrect inference= on the part of an arbitrary hypothetical neophyte that what is going on in t= he drive in such a case is that the head can equally well read either the old= data or the new data but the controller can=E2=80=99t distinguish which is w= hich, or might return old data, or might return new data, or might indiscrimi= nately return some old data and some new. What the drive reads in such a case is noise, because the wider head picks up= a superposition of the old (wide) 48tpi track data AND the new (narrow) 96tp= i track data, simultaneously. ok bear. --===============6410628825345822324==-- From cclist@sydex.com Mon Feb 27 21:44:57 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 13:36:55 -0800 Message-ID: In-Reply-To: <4BD31909-E397-4911-AD3D-9B2A0E9B1ABB@typewritten.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6010703565372833576==" --===============6010703565372833576== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/27/23 12:55, r.stricklin via cctalk wrote: >=20 >> On Feb 27, 2023, at 10:21 AM, Mike Katz via cctalk wrote: >> >> the drive would see half the new data and half the old data. >=20 > I think that explaining it this way can easily lead to an incorrect inferen= ce on the part of an arbitrary hypothetical neophyte that what is going on in= the drive in such a case is that the head can equally well read either the o= ld data or the new data but the controller can=E2=80=99t distinguish which is= which, or might return old data, or might return new data, or might indiscri= minately return some old data and some new. >=20 > What the drive reads in such a case is noise, because the wider head picks = up a superposition of the old (wide) 48tpi track data AND the new (narrow) 96= tpi track data, simultaneously. Double-stepped disks written at 96 tpi are perfectly readable on a 48 tpi drive if the disks are bulk-erased first. I've done this using a videotape eraser and later, a DC eraser made up of two ring magnets from an old magnetron, spaced perhaps 3-4 mm apart with like poles facing each other. Just pass the disk around the gap. Works a treat. --Chuck --===============6010703565372833576==-- From bitwiz@12bitsbest.com Mon Feb 27 21:56:17 2023 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 15:22:52 -0600 Message-ID: In-Reply-To: <4BD31909-E397-4911-AD3D-9B2A0E9B1ABB@typewritten.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3653590255452917041==" --===============3653590255452917041== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Actually it's not the controller, it is the fact that the head gap on=20 the 48 tpi drive is twice as wide as on the 96TPI drive. So the actual head sees the magnetic fluxes from two different tracks,=C2=A0 = This looks like noise to the data separator on the controller. The way around this was to magnetically erase a disk and format it and=20 write it on a double stepped on a 96tpi drive and only read it in a 48=20 tpi drive. This is what we had to do when I wrote the floppy formatter for Gimix=20 6800 and 6809 Flex and OS/9.=C2=A0 The floppy driver also had an option to=20 double step the drive for normal Flex operation. On 2/27/2023 2:55 PM, r.stricklin via cctalk wrote: >> On Feb 27, 2023, at 10:21 AM, Mike Katz via cctalk wrote: >> >> the drive would see half the new data and half the old data. > I think that explaining it this way can easily lead to an incorrect inferen= ce on the part of an arbitrary hypothetical neophyte that what is going on in= the drive in such a case is that the head can equally well read either the o= ld data or the new data but the controller can=E2=80=99t distinguish which is= which, or might return old data, or might return new data, or might indiscri= minately return some old data and some new. > > What the drive reads in such a case is noise, because the wider head picks = up a superposition of the old (wide) 48tpi track data AND the new (narrow) 96= tpi track data, simultaneously. > > > ok > bear. > --===============3653590255452917041==-- From cisin@xenosoft.com Mon Feb 27 22:14:58 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 14:14:53 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3895799605244378767==" --===============3895799605244378767== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit For my students, I used analogies and visual aids. 1/48, 1/96 is a little hard for some to visualize. "48 tracks per inch, is about half a millimeter spacing, with the actual data being aabout a third of a millimeter wide. 96 tracks per inch is about a quarter of a millimeter spacing, with the cata being about a sixth of a millimeter wide" "If you make stripes with a 2 inch wide paint brush, . . . you can also make stripes with the same spacing, with aa 1 inch wide paint brush, . . . BUT, with a single stroke, can you paint over a 2 inch stripe with a 1 inch brush? No, you'd have to clean all of the old paint off first, or start with a virgin canvas." "car tires make two tracks. Motorcycles could make tracks the same spacing. But, motorcycles won't obliterate the car tire tracks." I took a wide piece of colored chalk and made a series of stripes. I held up a piece of cardboard (file folder) with a slit in it, and looked at one stripe. With a narrower piece of a different color chalk, I made a series of half width stripes, half as far apart. I used a corresponding piece of cardboard with a narrower slit. I made narrow sripes at the wide spacing. I used the narrow slit cardboard, and then the wider slit cardboard, "Maybe a little weaak, but it should do." Then I made narrow stripes down the middle of the end of the wide stripes. I used the narrow slit cardboard. "Looks fine." Then I used the wide slit cardboard. "What is this mess??" Then, I made the students describe how to make a 48tpi disk with a 96tpi drive. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============3895799605244378767==-- From cclist@sydex.com Mon Feb 27 23:29:17 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 15:29:04 -0800 Message-ID: <5a55882b-fb03-4421-73ad-a368faf38b99@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4656653498397065522==" --===============4656653498397065522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/27/23 14:14, Fred Cisin via cctalk wrote: > Then, I made the students describe how to make a 48tpi disk with a 96tpi > drive. One thing that folks need to bear in mind is that it's the change of direction of magnetization that induces a signal in a drive head. So a DC or AC erase on the "straddling" portions of a track will work equally as well. --Chuck --===============4656653498397065522==-- From cisin@xenosoft.com Mon Feb 27 23:50:42 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 15:50:37 -0800 Message-ID: In-Reply-To: <5a55882b-fb03-4421-73ad-a368faf38b99@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5174359276411141310==" --===============5174359276411141310== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> Then, I made the students describe how to make a 48tpi disk with a 96tpi >> drive. Whether to count their answers as acceptable or not was mostly just the understanding of need for "bulk erase"/"virgin disk" On Mon, 27 Feb 2023, Chuck Guzis via cctalk wrote: > One thing that folks need to bear in mind is that it's the change of > direction of magnetization that induces a signal in a drive head. So a > DC or AC erase on the "straddling" portions of a track will work equally > as well. There is some erasing done by the heads to clear some of the area around the track. BUT, that erase of a 96tpi head is not wide enough to remove all traces of a previous 48tpi recording. I wondered why they didn't incorporate TWO sets of erase heads in 1.2M drives, so that it could "clear the margins" enough for 96tpi OR 48tpi re-writing. Could you explain [in dumbed down form], the differences between "tunnel erase" and "straddle erase"? Is it solely that the erase head(s) are behind, VS alongside the R/W head? I looked at http://www.bitsavers.org/pdf/cdc/discs/floppy/75897469_5inchFDD_Fmt_Jan80.pdf but I don't understand all of it. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5174359276411141310==-- From cisin@xenosoft.com Mon Feb 27 23:53:26 2023 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 15:53:21 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9047436150371030997==" --===============9047436150371030997== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It is also worth noting, that although not all "360K" diskettes are up to the task, they will still be much closer than "HD"/"1.2M" diskettes! "360K" diskettes are 300 Oersted "Quad density" diskettes are also 300 Oersted. The only difference is that "QD" diskettes are tested for 96tpi, whereas "360K" diskettes are tested at 48tpi. They are made of identical materials. However, if the production quality control is marginal/poor, then you could have some/many? that test OK at 48tpi, but are too flawed for 96tpi use. If they are really good quality, then the 48tpi ones should work just fine. OTOH, "HD"/"1.2M" diskettes are 600 oersted. Use of those for DD 300RPm/250Kbps / 360RPM/300kbps recording, whether at 48tpi, or 96tpi, will result in data retention longevity that is lower than it should be. Testing Roytype "HD" diskettes on TRS80 model 1 (SD/FM), gave data life of MINUTES, whereas "360K" diskettes tend to last years However, 3.5" "720K" diskettes are about 600 Oersted, and "1.4M" are about 720-750 Oersted. That is close enough that using the wrong media is something that people often get away with. I do not currently own a coercivity meter, so I can't check compliance with the specs. 45 years ago, Verbatim made some very crappy diskettes. To recover from their bad reputation, they came out with "Datalife" diskettes, which were acceptable quality. Dysan seems to have always been good. However, they "bet the company" on 3.25" disk form factor, and lost. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============9047436150371030997==-- From cclist@sydex.com Tue Feb 28 00:12:20 2023 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Need a 1.2mb 5.25 floppy Date: Mon, 27 Feb 2023 16:12:11 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9063192564311144855==" --===============9063192564311144855== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/27/23 15:50, Fred Cisin via cctalk wrote: > Could you explain [in dumbed down form], the differences between "tunnel > erase" and "straddle erase"?  Is it solely that the erase head(s) are > behind, VS alongside the R/W head? How about ChatGPT's explanation? (Is this a first for CCTalk?): When recording signals on magnetic media, erasing the previous data from the media is an important step in preparing it for new data. Tunnel erase and straddle erase are two different methods used for this purpose, and they differ in how they erase the previous data from the media. Tunnel erase is a method of erasing the previous data by applying a magnetic field perpendicular to the direction of the recording tracks. This magnetic field is strong enough to create a "tunneling effect" that causes the magnetic particles on the media to lose their magnetic orientation, effectively erasing the previous data. This method is called "tunnel erase" because the magnetic field creates a tunnel through which the magnetic particles lose their orientation. On the other hand, straddle erase is a method of erasing the previous data by applying a magnetic field that is parallel to the direction of the recording tracks. The magnetic field is applied by two or more magnetic heads placed on either side of the recording tracks, creating a "straddle" configuration. The magnetic field from the heads is strong enough to erase the previous data by realigning the magnetic particles on the media in a uniform direction. In summary, tunnel erase and straddle erase are two different methods of erasing the previous data from magnetic media. Tunnel erase uses a perpendicular magnetic field to erase the previous data, while straddle erase uses a parallel magnetic field created by multiple magnetic heads. -Chuck --===============9063192564311144855==-- From erik@baigar.de Tue Feb 28 09:23:12 2023 From: Erik Baigar To: cctalk@classiccmp.org Subject: [cctalk] Re: Tadpole RISC laptop RAM modules Date: Tue, 28 Feb 2023 10:11:02 +0100 Message-ID: <1009913952.2902416.1677575462075@webmail.strato.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5364988303607507463==" --===============5364988303607507463== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Izzat a "SPARCBook II"? If so, I have one with 2 drives, and > the /usr drive is failing. I can replace that but I have no > idea how to reinstall SunOS/Solaris/Whatever. I did that in the past using a network install. One will need ftfp (for kernel) and bootp (for parameters and paths) as well as old style nfs on a server with the installation media. Worked nicely and is pretty fast if CDs are copied to harddrive before- hand... Best wishes and good luck, Erik. ''~`` ( o o ) +--------------------------.oooO--(_)--Oooo.-------------------------+ | Dr. Erik Baigar Inertial Navigation & | | Salzstrasse 1 .oooO Vintage Computer | | D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist | | erik(a)baigar.de +------\ (----( )---------------------------+ | www.baigar.de | \_) ) / +----------------------+ (_/ --===============5364988303607507463==-- From sfmc68@verizon.net Tue Feb 28 18:35:10 2023 From: badbob To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-8/A FPP8/A Date: Tue, 28 Feb 2023 18:35:03 +0000 Message-ID: <510489739.2296174.1677609303013@mail.yahoo.com> In-Reply-To: <510489739.2296174.1677609303013.ref@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0441430382997734519==" --===============0441430382997734519== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message: 2 Date: Mon, 27 Feb 2023 18:27:52 +0000 From: silcreval Subject: [cctalk] Re: PDP-8/A FPP8/A To: cctalk(a)classiccmp.org Message-ID: <4EF3AB13-972C-4EE0-8105-C11128DA4BFA(a)yahoo.com> Content-Type: text/plain;=C2=A0 =C2=A0 =C2=A0 charset=3Dus-ascii >Hi Bob >Thanks - thats very interesting. I guess there was quite a >bit of overlap w= ith the 11 and the 8/A so 'marketing' >stepped in :-) Exactly what happened, you are correct. We did want to sell more 8 systems in= to labs... where small memory models made sense (256K words or less) and kept= having this dream of a Fortran Machine that went fast for the times. I don't recall exactly but I think one of the 11 models with FPU that got blo= wn out of the water was the 11/60 (a harvard arch implementation by O'Loughli= n iirc) that was a decent and very very reliable 11 (used pairs of them for a= critical system and they were exceptionally reliable when compared with disk= drives!!) The 8A was (and still is) a good machine but some of us wanted to build a 10M= hz clock 8 but the cost would have put it in the wrong price range for the ty= pes of customers we were allowed to have.=20 bb --===============0441430382997734519==--