From a.carlini@ntlworld.com Mon Apr 1 11:00:11 2024 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: WAS: Amoeba OS, Now: VAX/VMS Licensing? Date: Mon, 01 Apr 2024 12:00:04 +0100 Message-ID: <295dacd7-868f-40d5-9207-bb1f5066555b@ntlworld.com> In-Reply-To: =?utf-8?q?=3CBL1PR12MB5269BB9E460300363F7A6974B5382=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0661621240568827510==" --===============0661621240568827510== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 01/04/2024 00:45, W2HX wrote: > Hi all, I am completely ignorant when it comes to VMS licensing and how it = works (or worked). > I purchased a MicroVAX that is running VMS V5.3. Do I need to worry about i= t ceasing to work at some point? > I don=E2=80=99t have any paperwork for the license, just a running machine. > > What should I know about this? You should know how to take a standalone backup and make sure you have=20 done that. I'd suggest restoring it on a SIMH instance to check that it=20 is bootable and works as expected. You could use the LMF commands to dump the PAKs with checksums but that=20 (iirc) disables them so you have to re-enable them afterwards. That=20 would allow you to rebuild your system, assuming you have install media=20 for VMS and all the layered products. A standalone backup would be=20 better=C2=A0 though. Your VMS installation will certainly keep running for as long as you are=20 likely to want to run it, but the hardware may fail at any time. Antonio --=20 Antonio Carlini antonio(a)acarlini.com --===============0661621240568827510==-- From c.murray.mccullough@gmail.com Mon Apr 1 13:29:12 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] The 8008 Date: Mon, 01 Apr 2024 09:28:56 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5426928076062854309==" --===============5426928076062854309== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I’ve read with great interest, over the past short while, a few interesting articles on the history of the Intel 8008(officially released in April 1972) as it was the forerunner of what was to become the personal computer industry. And done with less than 4000 transistors. I saw one at a computer shop/store in Toronto in the latter 1970s’ but had no idea the seminal role it was to play in microcomputer history. Happy computing! Murray 🙂 --===============5426928076062854309==-- From billdegnan@gmail.com Mon Apr 1 13:43:21 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8008 Date: Mon, 01 Apr 2024 09:43:06 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8694815214633509209==" --===============8694815214633509209== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable are these articles available/online? maybe others might like them too. Thanks in advance Bill On Mon, Apr 1, 2024 at 9:29=E2=80=AFAM Murray McCullough via cctalk < cctalk(a)classiccmp.org> wrote: > I=E2=80=99ve read with great interest, over the past short while, a few int= eresting > articles on the history of the Intel 8008(officially released in April > 1972) as it was the forerunner of what was to become the personal computer > industry. And done with less than 4000 transistors. I saw one at a computer > shop/store in Toronto in the latter 1970s=E2=80=99 but had no idea the semi= nal role > it was to play in microcomputer history. > > Happy computing! > > > > Murray =F0=9F=99=82 > --===============8694815214633509209==-- From kantexplain@protonmail.com Mon Apr 1 22:33:50 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] oscilloscopes Date: Mon, 01 Apr 2024 22:33:38 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2213130660961585922==" --===============2213130660961585922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have more then I need. All the working ones are HP w/color crts, and as far= as older, verifiably vintage tools (right down to the 680x0 processor in eit= her) I have to admit I favor them as a brand. Call we an oddball, weird egg, = badges I wear with pride. But who could resist the allure of the newer ultra portable, even handheld un= its (some with bandwidth or sampling rates to 50mhz). I'm a big cheapo. But t= here's no real reason to agonize over a 65 - 200$ or thereabouts acquisition.= It's a bit tiring to wade through the piles of availability. I favor a deskt= op unit, larger screen (but not always, careful). But most of those need wall= current I think? The convenience of a handheld battery powered unit obviousl= y has it's benefits. I will always love and dote upon my color crt based HPs. But the damned thing= s are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit the paved = floor, shook the house. And still works! Built to withstand an atomic bombard= ment. --===============2213130660961585922==-- From cisin@xenosoft.com Mon Apr 1 22:56:13 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 15:56:05 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CxVKPUUPAeHv0=5FGdsaq0al3Lji6a5VLAX2wRSUo5YhZwiADr5?= =?utf-8?q?zn171nRBMNxX-XE1ru7jPj1GFbu0aE3uBwUsVKxlU=5FXAYKX9B0x42zJZADc=3D?= =?utf-8?q?=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6294870585963587976==" --===============6294870585963587976== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 1 Apr 2024, Just Kant via cctalk wrote: > I have more then I need. All the working ones are HP w/color crts, and as f= ar as older, verifiably vintage tools (right down to the 680x0 processor in e= ither) I have to admit I favor them as a brand. Call we an oddball, weird egg= , badges I wear with pride. > But who could resist the allure of the newer ultra portable, even=20 > handheld units (some with bandwidth or sampling rates to 50mhz). I'm a=20 > big cheapo. But there's no real reason to agonize over a 65 - 200$ or=20 > thereabouts acquisition. It's a bit tiring to wade through the piles of=20 > availability. I favor a desktop unit, larger screen (but not always,=20 > careful). But most of those need wall current I think? The convenience=20 > of a handheld battery powered unit obviously has it's benefits. > I will always love and dote upon my color crt based HPs. But the damned=20 > things are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit=20 > the paved floor, shook the house. And still works! Built to withstand an=20 > atomic bombardment. I had a Tektronix 512, and an NLS215 (battery powered portable) from a company that switched=20 over to making Kaypros. I gave it away at one of the first VCFs. I guess that the vintage ones are no longer adequate. -- Grumpy Ol' Fred --===============6294870585963587976==-- From rickb@bensene.com Mon Apr 1 23:21:27 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 23:12:08 +0000 Message-ID: <4a3b62096f7b43dd85e38af74e4a7e37@bensene.com> In-Reply-To: =?utf-8?q?=3CxVKPUUPAeHv0=5FGdsaq0al3Lji6a5VLAX2wRSUo5YhZwiADr5?= =?utf-8?q?zn171nRBMNxX-XE1ru7jPj1GFbu0aE3uBwUsVKxlU=5FXAYKX9B0x42zJZADc=3D?= =?utf-8?q?=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8919569306906111401==" --===============8919569306906111401== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> And still works! Built to withstand an atomic bombardment. Except for the EMP. It'll theoretically render such devices nice looking, w= ell-built scrap. The old completely vacuum-tube-based, discrete component oscilloscope from ba= ck in the day may actually survive such an event if it's outside the blast r= adius but still reasonably sheltered; and you are also outside lethal fallout= zones, or can shelter and survive in radioactivity-safe places for a long ti= me. Stock up on quality-made (e.g., Tektronix, Hewlett Packard) tube and cold-cat= hode-based test equipment (VTVM, oscilloscope, etc.) as well as quality radio= s and transceivers. Hopefully they will continue to serve as interesting ar= tifacts of a time gone by, but if something were to go sideways in our world,= they could potentially come in very handy. =20 --===============8919569306906111401==-- From wayne.sudol@hotmail.com Mon Apr 1 23:31:47 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 23:31:38 +0000 Message-ID: In-Reply-To: <4a3b62096f7b43dd85e38af74e4a7e37@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8232842783387776396==" --===============8232842783387776396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have 2 of the Non-Linear Systems (NLS) oscilloscopes that you speak of. Sti= ll working=20 Sent from my iPhone > On Apr 1, 2024, at 16:21, Rick Bensene via cctalk = wrote: >=20 > =EF=BB=BF >>=20 >>> And still works! Built to withstand an atomic bombardment. >=20 > Except for the EMP. It'll theoretically render such devices nice looking,= well-built scrap. >=20 > The old completely vacuum-tube-based, discrete component oscilloscope from = back in the day may actually survive such an event if it's outside the blast= radius but still reasonably sheltered; and you are also outside lethal fallo= ut zones, or can shelter and survive in radioactivity-safe places for a long = time. >=20 > Stock up on quality-made (e.g., Tektronix, Hewlett Packard) tube and cold-c= athode-based test equipment (VTVM, oscilloscope, etc.) as well as quality rad= ios and transceivers. Hopefully they will continue to serve as interesting = artifacts of a time gone by, but if something were to go sideways in our worl= d, they could potentially come in very handy. =20 >=20 >=20 --===============8232842783387776396==-- From bill.gunshannon@hotmail.com Tue Apr 2 00:06:18 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 20:05:38 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5391459801135199706==" --===============5391459801135199706== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/1/2024 6:56 PM, Fred Cisin via cctalk wrote: > On Mon, 1 Apr 2024, Just Kant via cctalk wrote: >> I have more then I need. All the working ones are HP w/color crts, and >> as far as older, verifiably vintage tools (right down to the 680x0 >> processor in either) I have to admit I favor them as a brand. Call we >> an oddball, weird egg, badges I wear with pride. >> But who could resist the allure of the newer ultra portable, even >> handheld units (some with bandwidth or sampling rates to 50mhz). I'm a >> big cheapo. But there's no real reason to agonize over a 65 - 200$ or >> thereabouts acquisition. It's a bit tiring to wade through the piles >> of availability. I favor a desktop unit, larger screen (but not >> always, careful). But most of those need wall current I think? The >> convenience of a handheld battery powered unit obviously has it's >> benefits. >> I will always love and dote upon my color crt based HPs. But the >> damned things are so heavy, so unwieldy. Judy-Jude knocked my 54111d >> over, hit the paved floor, shook the house. And still works! Built to >> withstand an atomic bombardment. > > I had a Tektronix 512, > and an NLS215 (battery powered portable) from a company that switched > over to making Kaypros.  I gave it away at one of the first VCFs. > I guess that the vintage ones are no longer adequate. My first one was a Heathkit I built. I now carry mine in my shirt pocket. bill --===============5391459801135199706==-- From bill.gunshannon@hotmail.com Tue Apr 2 00:09:52 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 20:09:01 -0400 Message-ID: In-Reply-To: <4a3b62096f7b43dd85e38af74e4a7e37@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1243170926089864900==" --===============1243170926089864900== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/1/2024 7:12 PM, Rick Bensene via cctalk wrote: >>> And still works! Built to withstand an atomic bombardment. >=20 > Except for the EMP. It'll theoretically render such devices nice looking,= well-built scrap. >=20 > The old completely vacuum-tube-based, discrete component oscilloscope from = back in the day may actually survive such an event if it's outside the blast= radius but still reasonably sheltered; and you are also outside lethal fallo= ut zones, or can shelter and survive in radioactivity-safe places for a long = time. >=20 > Stock up on quality-made (e.g., Tektronix, Hewlett Packard) tube and cold-c= athode-based test equipment (VTVM, oscilloscope, etc.) as well as quality rad= ios and transceivers. Hopefully they will continue to serve as interesting = artifacts of a time gone by, but if something were to go sideways in our worl= d, they could potentially come in very handy. >=20 >=20 You do realize that in the event of such an occurrence there would be nothing left to use them on. :-) bill --===============1243170926089864900==-- From paulkoning@comcast.net Tue Apr 2 00:20:33 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 20:20:24 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737A8E8D5D14019B6EB69F5ED3E2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0425574781848316441==" --===============0425574781848316441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 1, 2024, at 8:09 PM, Bill Gunshannon via cctalk wrote: >=20 >=20 > On 4/1/2024 7:12 PM, Rick Bensene via cctalk wrote: >>>> And still works! Built to withstand an atomic bombardment. >> Except for the EMP. It'll theoretically render such devices nice looking= , well-built scrap. >> The old completely vacuum-tube-based, discrete component oscilloscope from= back in the day may actually survive such an event if it's outside the blas= t radius but still reasonably sheltered; and you are also outside lethal fall= out zones, or can shelter and survive in radioactivity-safe places for a long= time. >> Stock up on quality-made (e.g., Tektronix, Hewlett Packard) tube and cold-= cathode-based test equipment (VTVM, oscilloscope, etc.) as well as quality ra= dios and transceivers. Hopefully they will continue to serve as interesting= artifacts of a time gone by, but if something were to go sideways in our wor= ld, they could potentially come in very handy. >=20 > You do realize that in the event of such an occurrence there > would be nothing left to use them on. :-) Not many computers, but my 51J-3 would be just fine. paul --===============0425574781848316441==-- From bhilpert@shaw.ca Tue Apr 2 00:22:03 2024 From: Brent Hilpert To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 17:14:48 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CxVKPUUPAeHv0=5FGdsaq0al3Lji6a5VLAX2wRSUo5YhZwiADr5?= =?utf-8?q?zn171nRBMNxX-XE1ru7jPj1GFbu0aE3uBwUsVKxlU=5FXAYKX9B0x42zJZADc=3D?= =?utf-8?q?=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7833749112873723604==" --===============7833749112873723604== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024Apr 1,, at 3:33 PM, Just Kant via cctalk wro= te: >=20 > I have more then I need. All the working ones are HP w/color crts, and as f= ar as older, verifiably vintage tools (right down to the 680x0 processor in e= ither) I have to admit I favor them as a brand. Call we an oddball, weird egg= , badges I wear with pride. >=20 > But who could resist the allure of the newer ultra portable, even handheld = units (some with bandwidth or sampling rates to 50mhz). I'm a big cheapo. But= there's no real reason to agonize over a 65 - 200$ or thereabouts acquisitio= n. It's a bit tiring to wade through the piles of availability. I favor a des= ktop unit, larger screen (but not always, careful). But most of those need wa= ll current I think? The convenience of a handheld battery powered unit obviou= sly has it's benefits. >=20 > I will always love and dote upon my color crt based HPs. But the damned thi= ngs are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit the pave= d floor, shook the house. And still works! Built to withstand an atomic bomba= rdment. Pardon the plug for my own web page, but given the topic of scopes and DSOs, = for any interested in some minor reading on the origins of the DSO and geekin= g out on sophisticated and little-known HP equipment from their heyday: http://madrona.ca/e/HP5480A/index.html Or TLDR: digital capture of analog signals to the low KHz in the late 1960s u= sing core memory & TTL, or, =E2=80=9Ca DSO before the DSO=E2=80=9D. As for portability, it=E2=80=99s possible for one person to manhandle it arou= nd but it comfortably needs 2 people to carry. --===============7833749112873723604==-- From paulkoning@comcast.net Tue Apr 2 00:36:33 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 20:36:03 -0400 Message-ID: <2F83C3CD-8112-4617-BC5E-2A12FE08B1B4@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2082497129638494588==" --===============2082497129638494588== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 1, 2024, at 8:14 PM, Brent Hilpert via cctalk wrote: >=20 > On 2024Apr 1,, at 3:33 PM, Just Kant via cctalk w= rote: >>=20 >> I have more then I need. All the working ones are HP w/color crts, and as = far as older, verifiably vintage tools (right down to the 680x0 processor in = either) I have to admit I favor them as a brand. Call we an oddball, weird eg= g, badges I wear with pride. >>=20 >> But who could resist the allure of the newer ultra portable, even handheld= units (some with bandwidth or sampling rates to 50mhz). I'm a big cheapo. Bu= t there's no real reason to agonize over a 65 - 200$ or thereabouts acquisiti= on. It's a bit tiring to wade through the piles of availability. I favor a de= sktop unit, larger screen (but not always, careful). But most of those need w= all current I think? The convenience of a handheld battery powered unit obvio= usly has it's benefits. >>=20 >> I will always love and dote upon my color crt based HPs. But the damned th= ings are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit the pav= ed floor, shook the house. And still works! Built to withstand an atomic bomb= ardment. >=20 >=20 >=20 > Pardon the plug for my own web page, but given the topic of scopes and DSOs= , for any interested in some minor reading on the origins of the DSO and geek= ing out on sophisticated and little-known HP equipment from their heyday: >=20 > http://madrona.ca/e/HP5480A/index.html >=20 > Or TLDR: digital capture of analog signals to the low KHz in the late 1960s= using core memory & TTL, or, =E2=80=9Ca DSO before the DSO=E2=80=9D. > As for portability, it=E2=80=99s possible for one person to manhandle it ar= ound but it comfortably needs 2 people to carry. The same could be said for the Tektronics scope I have, a DSA602. It just fi= ts in an H960 rack, and weighs perhaps 50 pounds. I can lift it -- if I'm ca= reful. That is my main oscilloscope, but once in a while I grab the Tek 7603 (thanks= , Fair Radio!). Analog, two channel, 100 MHz bandwidth on a good day. But i= f I think I'm looking at aliased signals, the 7603 will tell me because it do= esn't have any. I once had a 535. Repairing the HV supply was interesting; not all that easy= to find the rectifier tubes. Speaking of A/D specs, that old HP device reminds me of a digital voltmeter i= n my father's university lab, I think also by HP: it had a successive approxi= mation A/D constructed out of relays. It would typically sample every other = second or so, and make a "krrrrrrrt" sound while all those relays were flippi= ng. The display was some number of columns of 10 light bulbs showing digits = 0-9. paul --===============2082497129638494588==-- From sqrfolkdnc@comcast.net Tue Apr 2 00:43:15 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Mon, 01 Apr 2024 19:42:47 -0500 Message-ID: <1341801570.1317821.1712018567229@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1732917656802392618==" --===============1732917656802392618== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Will things like PDAs and tablets, powered off and stored inside steel ammo b= oxes survive? wrapped in layers of aluminum foil inside a small ammo box inside a larger am= mo box? In an ammo box buried in copper pennies? Back when they were taking copper o= ut of pennies, I stocked up on the all (mostly) copper ones... Maybe the sma= ll ammo box would fit inside the larger one with room for pennies all around = it. if essentially all computers not in military hardened sites were kaput, even = a cheap (to me obsolete) tablet would be very valuable, right? And I am not = assuming a nuclear war. The sun has emitted bursts resulting in EMP on earth= , the last one was before we had much technology, but IIRC, it toasted telegr= aph wires. https://www.history.com/news/a-perfect-solar-superstorm-the-1859-carrington-e= vent =20 
--Carey
--===============1732917656802392618==-- From wrcooke@wrcooke.net Tue Apr 2 00:50:56 2024 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 19:50:52 -0500 Message-ID: <2038149949.6502021.1712019052571@email.ionos.com> In-Reply-To: <2F83C3CD-8112-4617-BC5E-2A12FE08B1B4@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4362631985927630691==" --===============4362631985927630691== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I used to have a Tek 453(?) that was really nice. I sold it when I got a Tek= 7201(?) 1Ghz model. I recently sold it. I hated getting rid of it but it w= as big enough to be used as a small desk and weighed more than my back could = handle any more. I still have a 561A that I've been meaning to repair for 40= years. Any nuke preppers want it? It needs a new home. Bring a truck. Will Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince --===============4362631985927630691==-- From c.murray.mccullough@gmail.com Tue Apr 2 01:17:48 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8008 Date: Mon, 01 Apr 2024 21:17:31 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8082223194847395745==" --===============8082223194847395745== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Bill, I have not read the history of Intel lately but here are articles I have read starting with: https://www.techspot.com/article/1397-intel-8008-microprocessor/ Over the course of the last month or so this is what I=E2=80=99ve read: https://www.ithistory.org/db/hardware/intel-corporation/intel-8008 http://archive.computerhistory.org/resources/text/Oral_History/Intel_8008/Int= el_8008_1.oral_history.2006.102657982.pdf https://gunkies.org/wiki/Intel_8008 https://www.google.com/url?sa=3Dt&source=3Dweb&rct=3Dj&opi=3D89978449&url=3Dh= ttps://twitter.com/TechSpot/status/1773220599361417566&ved=3D2ahUKEwjr0uHO-qG= FAxWJFFkFHf5TCocQFnoECBsQAQ&usg=3DAOvVaw2xDE3zESspH5a49L34MetO https://www.eejournal.com/article/happy-50th-birthday-to-the-8-bit-intel-8008= -microprocessor/ These are articles on the Deep Net/Web that I=E2=80=99ve also read and may be= hard to reach(Private PDFs): https://archive.computerhistory.org/resources/access/text/2012/07/102657982-0= 5-01-acc.pdf https://www.righto.com/2017/02/reverse-engineering-surprisingly.html https://hackaday.com/2022/09/28/the-first-microcomputer-the-q1/ https://stevemorse.org/8086history/8086history.pdf https://www.sjsu.edu/people/robert.chun/courses/CS247/s4/M.pdf I hope these are of interest. Murray =F0=9F=98=8A On Mon, Apr 1, 2024 at 9:43=E2=80=AFAM Bill Degnan via cctalk wrote: > are these articles available/online? maybe others might like them too. > Thanks in advance > Bill > > On Mon, Apr 1, 2024 at 9:29=E2=80=AFAM Murray McCullough via cctalk < > cctalk(a)classiccmp.org> wrote: > > > I=E2=80=99ve read with great interest, over the past short while, a few > interesting > > articles on the history of the Intel 8008(officially released in April > > 1972) as it was the forerunner of what was to become the personal > computer > > industry. And done with less than 4000 transistors. I saw one at a > computer > > shop/store in Toronto in the latter 1970s=E2=80=99 but had no idea the se= minal > role > > it was to play in microcomputer history. > > > > Happy computing! > > > > > > > > Murray =F0=9F=99=82 > > > --===============8082223194847395745==-- From billdegnan@gmail.com Tue Apr 2 01:35:42 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8008 Date: Mon, 01 Apr 2024 21:35:24 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1944439573273321283==" --===============1944439573273321283== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable thanks. I thought there was maybe one specific item, but it's nice to have a bibliography to choose from! Appreciated Bill On Mon, Apr 1, 2024 at 9:17=E2=80=AFPM Murray McCullough via cctalk < cctalk(a)classiccmp.org> wrote: > Hi Bill, > > I have not read the history of Intel lately but here are articles I have > read starting with: > > https://www.techspot.com/article/1397-intel-8008-microprocessor/ > > Over the course of the last month or so this is what I=E2=80=99ve read: > > https://www.ithistory.org/db/hardware/intel-corporation/intel-8008 > > > http://archive.computerhistory.org/resources/text/Oral_History/Intel_8008/I= ntel_8008_1.oral_history.2006.102657982.pdf > > https://gunkies.org/wiki/Intel_8008 > > > https://www.google.com/url?sa=3Dt&source=3Dweb&rct=3Dj&opi=3D89978449&url= =3Dhttps://twitter.com/TechSpot/status/1773220599361417566&ved=3D2ahUKEwjr0uH= O-qGFAxWJFFkFHf5TCocQFnoECBsQAQ&usg=3DAOvVaw2xDE3zESspH5a49L34MetO > > > > > https://www.eejournal.com/article/happy-50th-birthday-to-the-8-bit-intel-80= 08-microprocessor/ > > These are articles on the Deep Net/Web that I=E2=80=99ve also read and may = be hard > to reach(Private PDFs): > > > https://archive.computerhistory.org/resources/access/text/2012/07/102657982= -05-01-acc.pdf > > https://www.righto.com/2017/02/reverse-engineering-surprisingly.html > > https://hackaday.com/2022/09/28/the-first-microcomputer-the-q1/ > > https://stevemorse.org/8086history/8086history.pdf > > https://www.sjsu.edu/people/robert.chun/courses/CS247/s4/M.pdf > > I hope these are of interest. > > Murray =F0=9F=98=8A > > On Mon, Apr 1, 2024 at 9:43=E2=80=AFAM Bill Degnan via cctalk < > cctalk(a)classiccmp.org> > wrote: > > > are these articles available/online? maybe others might like them too. > > Thanks in advance > > Bill > > > > On Mon, Apr 1, 2024 at 9:29=E2=80=AFAM Murray McCullough via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > > > I=E2=80=99ve read with great interest, over the past short while, a few > > interesting > > > articles on the history of the Intel 8008(officially released in April > > > 1972) as it was the forerunner of what was to become the personal > > computer > > > industry. And done with less than 4000 transistors. I saw one at a > > computer > > > shop/store in Toronto in the latter 1970s=E2=80=99 but had no idea the = seminal > > role > > > it was to play in microcomputer history. > > > > > > Happy computing! > > > > > > > > > > > > Murray =F0=9F=99=82 > > > > > > --===============1944439573273321283==-- From chris@mainecoon.com Tue Apr 2 01:46:11 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Mon, 01 Apr 2024 18:46:00 -0700 Message-ID: In-Reply-To: <1341801570.1317821.1712018567229@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6583612985339868577==" --===============6583612985339868577== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/1/24 17:42, CAREY SCHUG via cctalk wrote: > Will things like PDAs and tablets, powered off and stored inside steel ammo= boxes survive? Yes, as will most contemporary electronics, even without elaborate=20 protection. The amount of current induced in a device by EMP is a function of the=20 number and length of conductors; most modern electronics are unlikely to=20 have an issue given relatively short conductor lengths.=C2=A0 Automotive=20 ECUs, in particular, are unlikely to be affected, as they're equipped=20 with seriously clamped lines and generally have been tested in lightning=20 simulators (EMP looks like lightning, but EMP has a much faster rise=20 time, much higher voltages, and vastly higher currents); likewise the=20 commercial electrical grid is likely to be largely unaffected due to=20 existing lightning protection.=C2=A0 If your device can withstand a nearby=20 lightning strike, it's probably going to survive a high altitude EMP event. The biggest problem for semiconductor devices is from neutron flux when=20 under power, hence weird solutions for military systems where a PN diode=20 will be used to trigger a crowbar on the power supply (ionizing=20 radiation arrives well in advance of the neutrons).=C2=A0 The upshot is that = warfighting systems will recover, although the same probably can't be=20 said for the warfighters. Yes, I spent entirely too much time in this space in my misspent youth. Note that none of this is to suggest that all electronics will survive,=20 but the doom and gloom people associate with high altitude EMP, and=20 Carrington events in particular, are generally overblown. --=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" --===============6583612985339868577==-- From cclist@sydex.com Tue Apr 2 02:58:12 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Mon, 01 Apr 2024 19:58:01 -0700 Message-ID: <4dd33b27-7c24-4c95-8008-747aeaae306c@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1128241573554454561==" --===============1128241573554454561== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Well, if you're after an EMP-tolerant oscilloscope, there's always the mirror-galvanometer + rotating mirror variety. Precedes the development of the CRT by quite a bit. Runs fine with clockwork. It's amazing what can be done with simple electrics and mechanics. Anyone remember using the wall-galvanometer + telescope setup in physics classes? Or am I dating myself again? I recall working on L&N clamp-galvanometer chart recorders with clockwork drive and a single dry cell to provide power to a wheatstone bridge. L&N "Micromax". The idea is to sense the position of the galvo needle (periodically clamped) and adjust the setting of the slidewire to bring things into balance, which drives the recording pen. They were still in use in steel mills when I was in my salad days. The electronic versions with chopper amplifiers and regular servo drives were known as "Speedomax" Probably not EMP-safe. --Chuck --===============1128241573554454561==-- From kantexplain@protonmail.com Tue Apr 2 05:03:55 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 05:03:44 +0000 Message-ID: <03vUWxIth71E58g0C5-S_eQtmRRbhJ0jvhxrat4C-oeNaz_wa5K2WFq79rk02HVxnH5YYb9rqTAtiYcQkcsW3aXVLP6ZyvGlcW-SNf6gISI=@protonmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8292025903203362675==" --===============8292025903203362675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Accordimg to certain individuals on this list, going back a few years, electr= onics/computers can be damaged due to an electrical storm, presumably very in= tense activity, even while off. Go look through the archives. I knew people back in the 80s that said they could "torque" certain frequenc= ies with a cb radio in the vicinity of a car wash and turn the whole joint on= ! Vending machines are/were said to be similaely vulnerable. Such is the basi= s behind emc testing. I should know. A specific component is wrapped with wir= e say, or is placed in front of various antennas, and currents are pumped thr= ough or frequencies are directed at the item to see if it fails. Or fries (ve= ry uncommon). Specifications are provided as to what tests need to be conduct= ed, literally, or radiated. If the item fails, additional work is required to= keep the item in spec so that it doesm't fail in the field. Which frequencies are present in an EMP I couldn't tell you. But I have to b= elieve they delivered with considerable power. I did work like that back in t= he 80s. In general I don't think too much equipment was radiation hardened ba= ck then. It was believed then the threat would be from a neutron bomb. A high= altotude emp strike probably wouldn't affect much. But I'd certainly be conc= erned about one in the vicinity of a server farm or a military complex may fr= ig up quite a bit. You don't havento knock out everyone's electronics in orde= r to frig up a society or crucial portions of it. I'm binging Pikard at the m= oment. Their comms have limited effectiveness because relays (repeaters?) don= 't exist in 2024. =20 Sent with Proton Mail secure email. On Monday, April 1st, 2024 at 9:46 PM, Christian Kennedy via cctalk wrote: > On 4/1/24 17:42, CAREY SCHUG via cctalk wrote: >=20 > > Will things like PDAs and tablets, powered off and stored inside steel am= mo boxes survive? >=20 >=20 > Yes, as will most contemporary electronics, even without elaborate > protection. >=20 > The amount of current induced in a device by EMP is a function of the > number and length of conductors; most modern electronics are unlikely to > have an issue given relatively short conductor lengths. Automotive > ECUs, in particular, are unlikely to be affected, as they're equipped > with seriously clamped lines and generally have been tested in lightning > simulators (EMP looks like lightning, but EMP has a much faster rise > time, much higher voltages, and vastly higher currents); likewise the > commercial electrical grid is likely to be largely unaffected due to > existing lightning protection. If your device can withstand a nearby > lightning strike, it's probably going to survive a high altitude EMP event. >=20 > The biggest problem for semiconductor devices is from neutron flux when > under power, hence weird solutions for military systems where a PN diode > will be used to trigger a crowbar on the power supply (ionizing > radiation arrives well in advance of the neutrons). The upshot is that > warfighting systems will recover, although the same probably can't be > said for the warfighters. >=20 > Yes, I spent entirely too much time in this space in my misspent youth. >=20 > Note that none of this is to suggest that all electronics will survive, > but the doom and gloom people associate with high altitude EMP, and > Carrington events in particular, are generally overblown. >=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" --===============8292025903203362675==-- From bitwiz@12bitsbest.com Tue Apr 2 05:57:15 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Mon, 01 Apr 2024 19:23:56 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0267825827580934039==" --===============0267825827580934039== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I still have a TEK 475A (with the DMM4 on top) and a TEK 11043A mainframe scope. The 475A is rock solid and is one of the best analog triggering scopes ever made.  The 11403A goes all the way up to 3GHz but, tbh, is was a difficult to use touch screen scope.  I still use both of them occasionally. I had a Sony Tektronix Battery Operated 10 or 20 MHz scope ( I can't remember which) that was lent out never to be seen again.  The nicest thing about it was that the two channels were completely electrically isolated from each other. My go to scopes now are a couple of PicoScope USB scopes with logic analyzers and arbitrary function generators. Here are the two TEK scopes.  The 475A is showing both a sine and a square wave at 1 MHz (chopped).  The 11403A is showing a 1GHz sine wave and 7 other unconnected traces just to show that is can display 8 traces at once.  The three plugins on the 11403A are, 4 trace 3000MHz/trace, 2 trace 1GHz/trace and 2 trace 50MHz Current Probe Amplifier. On 4/1/2024 5:56 PM, Fred Cisin via cctalk wrote: > On Mon, 1 Apr 2024, Just Kant via cctalk wrote: >> I have more then I need. All the working ones are HP w/color crts, >> and as far as older, verifiably vintage tools (right down to the >> 680x0 processor in either) I have to admit I favor them as a brand. >> Call we an oddball, weird egg, badges I wear with pride. >> But who could resist the allure of the newer ultra portable, even >> handheld units (some with bandwidth or sampling rates to 50mhz). I'm >> a big cheapo. But there's no real reason to agonize over a 65 - 200$ >> or thereabouts acquisition. It's a bit tiring to wade through the >> piles of availability. I favor a desktop unit, larger screen (but not >> always, careful). But most of those need wall current I think? The >> convenience of a handheld battery powered unit obviously has it's >> benefits. >> I will always love and dote upon my color crt based HPs. But the >> damned things are so heavy, so unwieldy. Judy-Jude knocked my 54111d >> over, hit the paved floor, shook the house. And still works! Built to >> withstand an atomic bombardment. > > I had a Tektronix 512, > and an NLS215 (battery powered portable) from a company that switched > over to making Kaypros.  I gave it away at one of the first VCFs. > I guess that the vintage ones are no longer adequate. > > -- > Grumpy Ol' Fred --===============0267825827580934039==-- From doug@doughq.com Tue Apr 2 06:26:47 2024 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 17:26:28 +1100 Message-ID: In-Reply-To: =?utf-8?q?=3C03vUWxIth71E58g0C5-S=5FeQtmRRbhJ0jvhxrat4C-oeNaz?= =?utf-8?q?=5Fwa5K2WFq79rk02HVxnH5YYb9rqTAtiYcQkcsW3aXVLP6ZyvGlcW-SNf6gISI?= =?utf-8?q?=3D=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0030987934868578625==" --===============0030987934868578625== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit ASCII Graphic of an EMP: Much EMF _____ | | | | --------------- --------- zero EMF t=0 t= very short time What frequencies would you like.... Fourier would suggest that many of them are there :-) :-) Kindest regards, Doug Jackson em: doug(a)doughq.com ph: 0414 986878 Follow my amateur radio adventures at vk1zdj.net On Tue, 2 Apr 2024 at 16:04, Just Kant via cctalk wrote: > Accordimg to certain individuals on this list, going back a few years, > electronics/computers can be damaged due to an electrical storm, presumably > very intense activity, even while off. Go look through the archives. > > I knew people back in the 80s that said they could "torque" certain > frequencies with a cb radio in the vicinity of a car wash and turn the > whole joint on! Vending machines are/were said to be similaely vulnerable. > Such is the basis behind emc testing. I should know. A specific component > is wrapped with wire say, or is placed in front of various antennas, and > currents are pumped through or frequencies are directed at the item to see > if it fails. Or fries (very uncommon). Specifications are provided as to > what tests need to be conducted, literally, or radiated. If the item fails, > additional work is required to keep the item in spec so that it doesm't > fail in the field. > > Which frequencies are present in an EMP I couldn't tell you. But I have > to believe they delivered with considerable power. I did work like that > back in the 80s. In general I don't think too much equipment was radiation > hardened back then. It was believed then the threat would be from a neutron > bomb. A high altotude emp strike probably wouldn't affect much. But I'd > certainly be concerned about one in the vicinity of a server farm or a > military complex may frig up quite a bit. You don't havento knock out > everyone's electronics in order to frig up a society or crucial portions of > it. I'm binging Pikard at the moment. Their comms have limited > effectiveness because relays (repeaters?) don't exist in 2024. > > > > Sent with Proton Mail secure email. > > On Monday, April 1st, 2024 at 9:46 PM, Christian Kennedy via cctalk < > cctalk(a)classiccmp.org> wrote: > > > On 4/1/24 17:42, CAREY SCHUG via cctalk wrote: > > > > > Will things like PDAs and tablets, powered off and stored inside steel > ammo boxes survive? > > > > > > Yes, as will most contemporary electronics, even without elaborate > > protection. > > > > The amount of current induced in a device by EMP is a function of the > > number and length of conductors; most modern electronics are unlikely to > > have an issue given relatively short conductor lengths. Automotive > > ECUs, in particular, are unlikely to be affected, as they're equipped > > with seriously clamped lines and generally have been tested in lightning > > simulators (EMP looks like lightning, but EMP has a much faster rise > > time, much higher voltages, and vastly higher currents); likewise the > > commercial electrical grid is likely to be largely unaffected due to > > existing lightning protection. If your device can withstand a nearby > > lightning strike, it's probably going to survive a high altitude EMP > event. > > > > The biggest problem for semiconductor devices is from neutron flux when > > under power, hence weird solutions for military systems where a PN diode > > will be used to trigger a crowbar on the power supply (ionizing > > radiation arrives well in advance of the neutrons). The upshot is that > > warfighting systems will recover, although the same probably can't be > > said for the warfighters. > > > > Yes, I spent entirely too much time in this space in my misspent youth. > > > > Note that none of this is to suggest that all electronics will survive, > > but the doom and gloom people associate with high altitude EMP, and > > Carrington events in particular, are generally overblown. > > > > -- > > 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…" > --===============0030987934868578625==-- From elson@pico-systems.com Tue Apr 2 14:56:05 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 09:55:56 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8112700423335341608==" --===============8112700423335341608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/1/24 20:46, Christian Kennedy via cctalk wrote: > > On 4/1/24 17:42, CAREY SCHUG via cctalk wrote: >> Will things like PDAs and tablets, powered off and stored >> inside steel ammo boxes survive? > > Yes, as will most contemporary electronics, even without > elaborate protection. Right, I think there is a lot of hype about this.  A cell phone should be fine (no wires) but anything connected to the outside world (like phone modems, cable modems, power outlets) etc. could be harmed.  A computer that is plugged into the wall socket and a modem could really get walloped, as the two connections form a big loop to accept magnetic coupling. Jon --===============8112700423335341608==-- From elson@pico-systems.com Tue Apr 2 15:01:20 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 10:01:11 -0500 Message-ID: <29fcd90e-29cb-74a8-a4e1-84b71e2117cf@pico-systems.com> In-Reply-To: =?utf-8?q?=3C03vUWxIth71E58g0C5-S=5FeQtmRRbhJ0jvhxrat4C-oeNaz?= =?utf-8?q?=5Fwa5K2WFq79rk02HVxnH5YYb9rqTAtiYcQkcsW3aXVLP6ZyvGlcW-SNf6gISI?= =?utf-8?q?=3D=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6637275979272825283==" --===============6637275979272825283== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/2/24 00:03, Just Kant via cctalk wrote: > Accordimg to certain individuals on this list, going back a few years, elec= tronics/computers can be damaged due to an electrical storm, presumably very = intense activity, even while off. Go look through the archives. > I have had two incidents where nearby lightning strikes blew=20 out components on gear I had.=C2=A0 Many years ago, I had two=20 computers connected by a parallel port cable, and chips on=20 both ends were popped by a strike that might have hit power=20 lines about two blocks away. About a decade ago, we had a lightning strike that hit trees=20 half a block away.=C2=A0 It took out an ethernet port on one=20 computer, and blew out a bunch of stuff on a burglar alarm I=20 had built.=C2=A0 Both involved long wire runs. Jon --===============6637275979272825283==-- From paulkoning@comcast.net Tue Apr 2 15:13:18 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 11:13:08 -0400 Message-ID: <81400415-BB0A-4350-8997-E40326909B2E@comcast.net> In-Reply-To: <29fcd90e-29cb-74a8-a4e1-84b71e2117cf@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1132208251949734980==" --===============1132208251949734980== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 2, 2024, at 11:01 AM, Jon Elson via cctalk = wrote: >=20 > On 4/2/24 00:03, Just Kant via cctalk wrote: >> Accordimg to certain individuals on this list, going back a few years, ele= ctronics/computers can be damaged due to an electrical storm, presumably very= intense activity, even while off. Go look through the archives. >>=20 > I have had two incidents where nearby lightning strikes blew out components= on gear I had. Many years ago, I had two computers connected by a parallel = port cable, and chips on both ends were popped by a strike that might have hi= t power lines about two blocks away. >=20 > About a decade ago, we had a lightning strike that hit trees half a block a= way. It took out an ethernet port on one computer, and blew out a bunch of s= tuff on a burglar alarm I had built. Both involved long wire runs. Some years ago we had a lightning strike on the driveway next to the house. = It took out every single device directly or indirectly connected to the cable= TV (also Internet) connection. The reason was something I knew about but wh= ich I did not sufficiently understand: the cable TV connection came into the = house at the opposite end from power and telephone, and was grounded there. = A lightning strike will set up a voltage gradient in the soil near the strike= , so the "ground" seen by power and phone was at a very different voltage tha= n the "ground" seen by the ground rod "protecting" the cable TV entry. The r= esulting current actually evaporated the cable TV surge protector innards, an= d took out TV, printer, cable modem, Ethernet switch, PC, and a bunch of othe= r things. Lesson learned: I rerouted the cable TV to go first to the power entry point,= and attached its protector to the same copper ground sheet that the other tw= o protectors sit on. A great reference for all this is the handbook "The grounds for lightning pro= tection" by Polyphase Co., a maker of professional lightning protection devic= es. I haven't done everything they call for -- for example, our house doesn'= t have a perimeter ground. But it does now have single point grounding, and = as a result we've had no trouble even though there have been plenty of lightn= ing strikes in the neighborhood. paul --===============1132208251949734980==-- From shumaker@att.net Tue Apr 2 15:54:26 2024 From: steve shumaker To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 08:54:14 -0700 Message-ID: In-Reply-To: <81400415-BB0A-4350-8997-E40326909B2E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3896945377050883469==" --===============3896945377050883469== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Company (Polyphaser) web page doesn't seem to list that handbook as an=20 available lit product.=C2=A0 Can you suggest a source? Steve On 4/2/24 8:13 AM, Paul Koning via cctalk wrote: > >> On Apr 2, 2024, at 11:01 AM, Jon Elson via cctalk= wrote: >> >> On 4/2/24 00:03, Just Kant via cctalk wrote: >>> Accordimg to certain individuals on this list, going back a few years, el= ectronics/computers can be damaged due to an electrical storm, presumably ver= y intense activity, even while off. Go look through the archives. >>> >> I have had two incidents where nearby lightning strikes blew out component= s on gear I had. Many years ago, I had two computers connected by a parallel= port cable, and chips on both ends were popped by a strike that might have h= it power lines about two blocks away. >> >> About a decade ago, we had a lightning strike that hit trees half a block = away. It took out an ethernet port on one computer, and blew out a bunch of = stuff on a burglar alarm I had built. Both involved long wire runs. > Some years ago we had a lightning strike on the driveway next to the house.= It took out every single device directly or indirectly connected to the cab= le TV (also Internet) connection. The reason was something I knew about but = which I did not sufficiently understand: the cable TV connection came into th= e house at the opposite end from power and telephone, and was grounded there. > > A lightning strike will set up a voltage gradient in the soil near the stri= ke, so the "ground" seen by power and phone was at a very different voltage t= han the "ground" seen by the ground rod "protecting" the cable TV entry. The= resulting current actually evaporated the cable TV surge protector innards, = and took out TV, printer, cable modem, Ethernet switch, PC, and a bunch of ot= her things. > > Lesson learned: I rerouted the cable TV to go first to the power entry poin= t, and attached its protector to the same copper ground sheet that the other = two protectors sit on. > > A great reference for all this is the handbook "The grounds for lightning p= rotection" by Polyphase Co., a maker of professional lightning protection dev= ices. I haven't done everything they call for -- for example, our house does= n't have a perimeter ground. But it does now have single point grounding, an= d as a result we've had no trouble even though there have been plenty of ligh= tning strikes in the neighborhood. > > paul > --===============3896945377050883469==-- From paulkoning@comcast.net Tue Apr 2 16:37:54 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 12:37:25 -0400 Message-ID: <00E093ED-E0CE-4A89-A2E9-392B738AB8D6@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1053268969838688772==" --===============1053268969838688772== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 2, 2024, at 11:54 AM, steve shumaker via cctalk wrote: >=20 > Company (Polyphaser) web page doesn't seem to list that handbook as an avai= lable lit product. Can you suggest a source? >=20 > Steve >=20 >=20 > On 4/2/24 8:13 AM, Paul Koning via cctalk wrote: >>=20 >> ... >> A great reference for all this is the handbook "The grounds for lightning = protection" by Polyphase Co., a maker of professional lightning protection de= vices. I haven't done everything they call for -- for example, our house doe= sn't have a perimeter ground. But it does now have single point grounding, a= nd as a result we've had no trouble even though there have been plenty of lig= htning strikes in the neighborhood. >>=20 >> paul I found a somewhat different book from Polyphaser: https://w5nor.org/presenta= tions/PolyphaserGuide.pdf which cites the other one in the references section= in the back. The material looks rather similar to the older book; I recogni= zed a number of illustrations. It has more content, it seems, and more recen= t material. The exact title is "The Grounds for Lightning and EMP Protection" by Roger Bl= ock, and searching for that title yields some sources, including a used copy = on eBay and an online copy on Scribd. paul --===============1053268969838688772==-- From cube1@charter.net Tue Apr 2 17:37:56 2024 From: Jay Jaeger To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 12:30:41 -0500 Message-ID: <57018e41-81c0-1e0e-39a7-780734e5badf@charter.net> In-Reply-To: <81400415-BB0A-4350-8997-E40326909B2E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1298621578922276135==" --===============1298621578922276135== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul, would you mind if I shared this on the Facebook EndFed Halfwave=20 Antenna group?=C2=A0 Time and time again I see folks talk about putting in=20 ground rods in for antennas and NOT bonding them to the electrical=20 service ground rod.=C2=A0=C2=A0=C2=A0 In most (if not all) locations in the U= S, this=20 kind of bonding is now a required part of the electrical code, and newly=20 constructed houses (or ones that have their panels replaced) will=20 typically have a "service ground' bus bar installed near the electrical=20 panel. (The ARRL book is a pretty good resource on this topic, too, but real=20 life experience may convince some to think twice about what they are doing.) https://www.arrl.org/grounding-and-bonding-for-the-amateur JRJ On 4/2/2024 10:13 AM, Paul Koning via cctalk wrote: > >> On Apr 2, 2024, at 11:01 AM, Jon Elson via cctalk wrote: >> >> On 4/2/24 00:03, Just Kant via cctalk wrote: >>> Accordimg to certain individuals on this list, going back a few years, el= ectronics/computers can be damaged due to an electrical storm, presumably ver= y intense activity, even while off. Go look through the archives. >>> >> I have had two incidents where nearby lightning strikes blew out component= s on gear I had. Many years ago, I had two computers connected by a parallel= port cable, and chips on both ends were popped by a strike that might have h= it power lines about two blocks away. >> >> About a decade ago, we had a lightning strike that hit trees half a block = away. It took out an ethernet port on one computer, and blew out a bunch of = stuff on a burglar alarm I had built. Both involved long wire runs. > Some years ago we had a lightning strike on the driveway next to the house.= It took out every single device directly or indirectly connected to the cab= le TV (also Internet) connection. The reason was something I knew about but = which I did not sufficiently understand: the cable TV connection came into th= e house at the opposite end from power and telephone, and was grounded there. > > A lightning strike will set up a voltage gradient in the soil near the stri= ke, so the "ground" seen by power and phone was at a very different voltage t= han the "ground" seen by the ground rod "protecting" the cable TV entry. The= resulting current actually evaporated the cable TV surge protector innards, = and took out TV, printer, cable modem, Ethernet switch, PC, and a bunch of ot= her things. > > Lesson learned: I rerouted the cable TV to go first to the power entry poin= t, and attached its protector to the same copper ground sheet that the other = two protectors sit on. > > A great reference for all this is the handbook "The grounds for lightning p= rotection" by Polyphase Co., a maker of professional lightning protection dev= ices. I haven't done everything they call for -- for example, our house does= n't have a perimeter ground. But it does now have single point grounding, an= d as a result we've had no trouble even though there have been plenty of ligh= tning strikes in the neighborhood. > > paul > --===============1298621578922276135==-- From paulkoning@comcast.net Tue Apr 2 17:48:28 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 13:47:58 -0400 Message-ID: <827363A5-B7B3-40F7-A48C-1E36E3F1EF06@comcast.net> In-Reply-To: <57018e41-81c0-1e0e-39a7-780734e5badf@charter.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3998788211166111467==" --===============3998788211166111467== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Absolutely, by all means go right ahead. As you pointed out, the NEC absolutely requires bonding all ground rods. And= Roger Block spells out in quite some detail why this is important in his boo= ks. Come to think of it, apart from bonding electrical system grounds, I think th= ere's also a requirement for bonding other metal objects that are anywhere ne= arby, like other utilities. I'm not sure about the details; they should be i= n the NEC or in building codes. paul > On Apr 2, 2024, at 1:30 PM, Jay Jaeger via cctalk = wrote: >=20 > Paul, would you mind if I shared this on the Facebook EndFed Halfwave Anten= na group? Time and time again I see folks talk about putting in ground rods = in for antennas and NOT bonding them to the electrical service ground rod. = In most (if not all) locations in the US, this kind of bonding is now a requ= ired part of the electrical code, and newly constructed houses (or ones that = have their panels replaced) will typically have a "service ground' bus bar in= stalled near the electrical panel. >=20 > (The ARRL book is a pretty good resource on this topic, too, but real life = experience may convince some to think twice about what they are doing.) >=20 > https://www.arrl.org/grounding-and-bonding-for-the-amateur >=20 > JRJ >=20 > On 4/2/2024 10:13 AM, Paul Koning via cctalk wrote: >>=20 >>> On Apr 2, 2024, at 11:01 AM, Jon Elson via cctalk wrote: >>>=20 >>> On 4/2/24 00:03, Just Kant via cctalk wrote: >>>> Accordimg to certain individuals on this list, going back a few years, e= lectronics/computers can be damaged due to an electrical storm, presumably ve= ry intense activity, even while off. Go look through the archives. >>>>=20 >>> I have had two incidents where nearby lightning strikes blew out componen= ts on gear I had. Many years ago, I had two computers connected by a paralle= l port cable, and chips on both ends were popped by a strike that might have = hit power lines about two blocks away. >>>=20 >>> About a decade ago, we had a lightning strike that hit trees half a block= away. It took out an ethernet port on one computer, and blew out a bunch of= stuff on a burglar alarm I had built. Both involved long wire runs. >> Some years ago we had a lightning strike on the driveway next to the house= . It took out every single device directly or indirectly connected to the ca= ble TV (also Internet) connection. The reason was something I knew about but= which I did not sufficiently understand: the cable TV connection came into t= he house at the opposite end from power and telephone, and was grounded there. >>=20 >> A lightning strike will set up a voltage gradient in the soil near the str= ike, so the "ground" seen by power and phone was at a very different voltage = than the "ground" seen by the ground rod "protecting" the cable TV entry. Th= e resulting current actually evaporated the cable TV surge protector innards,= and took out TV, printer, cable modem, Ethernet switch, PC, and a bunch of o= ther things. >>=20 >> Lesson learned: I rerouted the cable TV to go first to the power entry poi= nt, and attached its protector to the same copper ground sheet that the other= two protectors sit on. >>=20 >> A great reference for all this is the handbook "The grounds for lightning = protection" by Polyphase Co., a maker of professional lightning protection de= vices. I haven't done everything they call for -- for example, our house doe= sn't have a perimeter ground. But it does now have single point grounding, a= nd as a result we've had no trouble even though there have been plenty of lig= htning strikes in the neighborhood. >>=20 >> paul >>=20 --===============3998788211166111467==-- From bill.gunshannon@hotmail.com Tue Apr 2 19:17:59 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 15:17:36 -0400 Message-ID: In-Reply-To: <29fcd90e-29cb-74a8-a4e1-84b71e2117cf@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5973799968075918335==" --===============5973799968075918335== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/2/2024 11:01 AM, Jon Elson via cctalk wrote: > On 4/2/24 00:03, Just Kant via cctalk wrote: >> Accordimg to certain individuals on this list, going back a few years, >> electronics/computers can be damaged due to an electrical storm, >> presumably very intense activity, even while off. Go look through the >> archives. >> > I have had two incidents where nearby lightning strikes blew out > components on gear I had.  Many years ago, I had two computers connected > by a parallel port cable, and chips on both ends were popped by a strike > that might have hit power lines about two blocks away. > > About a decade ago, we had a lightning strike that hit trees half a > block away.  It took out an ethernet port on one computer, and blew out > a bunch of stuff on a burglar alarm I had built.  Both involved long > wire runs. I have had lots of stuff taken out by lightening. Even when it wasn't particularly close but hit a power line as much as a mile away. On a much more interesting note, I used to live in a cute little farmhouse in New Windsor, NY. Our power came in a a line that hung across the vacant lot next to me. About 500 yards. We took a direct hit on that line one night. Dog got shocked by pulse came thru the stone floor of the mud room. A TRS-80 was toast. A modem was toast. TV and a few other household items. There was a Terak 8510 not only plugged in but running at the time. It didn't even reboot. Just kept on plugging along. Nobody made them like DEC did. bill --===============5973799968075918335==-- From g4ajq1@gmail.com Tue Apr 2 19:18:32 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 15:18:24 -0400 Message-ID: In-Reply-To: <29fcd90e-29cb-74a8-a4e1-84b71e2117cf@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6214192857300904095==" --===============6214192857300904095== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-02 11:01, Jon Elson via cctalk wrote: > On 4/2/24 00:03, Just Kant via cctalk wrote: >> Accordimg to certain individuals on this list, going back a few >> years, electronics/computers can be damaged due to an electrical >> storm, presumably very intense activity, even while off. Go look >> through the archives. >> > I have had two incidents where nearby lightning strikes blew out > components on gear I had.  Many years ago, I had two computers > connected by a parallel port cable, and chips on both ends were popped > by a strike that might have hit power lines about two blocks away. > > About a decade ago, we had a lightning strike that hit trees half a > block away.  It took out an ethernet port on one computer, and blew > out a bunch of stuff on a burglar alarm I had built.  Both involved > long wire runs. > > Jon > I maintained a ham repeater that had 6 x 800 Ah lead acid station cells for power backup. One time, it was down days after a storm, so my chief engineer at work (also a ham) and I went up to investigate.  The repeater was still running on batteries, but as we approached we saw the entire glass enclosure of the meter was covered internally with melted copper!  We attributed its survival to extremely good grounding, including a mesh underneath the shack, and the fact that all the power to the radios went through that extremely low impedance battery source to ground! 73 de Nigel ve3id -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============6214192857300904095==-- From g4ajq1@gmail.com Tue Apr 2 19:18:37 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 15:18:24 -0400 Message-ID: <07ed3533-9ac2-4d1d-b1fb-af6ee8eed65e@gmail.com> In-Reply-To: <29fcd90e-29cb-74a8-a4e1-84b71e2117cf@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4872382210217573502==" --===============4872382210217573502== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-02 11:01, Jon Elson via cctalk wrote: > On 4/2/24 00:03, Just Kant via cctalk wrote: >> Accordimg to certain individuals on this list, going back a few >> years, electronics/computers can be damaged due to an electrical >> storm, presumably very intense activity, even while off. Go look >> through the archives. >> > I have had two incidents where nearby lightning strikes blew out > components on gear I had.  Many years ago, I had two computers > connected by a parallel port cable, and chips on both ends were popped > by a strike that might have hit power lines about two blocks away. > > About a decade ago, we had a lightning strike that hit trees half a > block away.  It took out an ethernet port on one computer, and blew > out a bunch of stuff on a burglar alarm I had built.  Both involved > long wire runs. > > Jon > I maintained a ham repeater that had 6 x 800 Ah lead acid station cells for power backup. One time, it was down days after a storm, so my chief engineer at work (also a ham) and I went up to investigate.  The repeater was still running on batteries, but as we approached we saw the entire glass enclosure of the meter was covered internally with melted copper!  We attributed its survival to extremely good grounding, including a mesh underneath the shack, and the fact that all the power to the radios went through that extremely low impedance battery source to ground! 73 de Nigel ve3id -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============4872382210217573502==-- From bill.gunshannon@hotmail.com Tue Apr 2 19:21:14 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 15:20:57 -0400 Message-ID: In-Reply-To: <827363A5-B7B3-40F7-A48C-1E36E3F1EF06@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6084786764892791951==" --===============6084786764892791951== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/2/2024 1:47 PM, Paul Koning via cctalk wrote: > Absolutely, by all means go right ahead. >=20 > As you pointed out, the NEC absolutely requires bonding all ground rods. A= nd Roger Block spells out in quite some detail why this is important in his b= ooks. >=20 > Come to think of it, apart from bonding electrical system grounds, I think = there's also a requirement for bonding other metal objects that are anywhere = nearby, like other utilities. I'm not sure about the details; they should be= in the NEC or in building codes. >=20 Propane tanks and their associated gas lines. bill --===============6084786764892791951==-- From paulkoning@comcast.net Tue Apr 2 19:24:28 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 15:24:21 -0400 Message-ID: <15DA3242-1F01-4C45-88C2-C47D25907E01@comcast.net> In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737F76D01F090D51696DF6FED3E2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4161760407901123181==" --===============4161760407901123181== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 2, 2024, at 3:17 PM, Bill Gunshannon via cctalk wrote: >=20 >=20 >=20 > On 4/2/2024 11:01 AM, Jon Elson via cctalk wrote: >> On 4/2/24 00:03, Just Kant via cctalk wrote: >>> Accordimg to certain individuals on this list, going back a few years, el= ectronics/computers can be damaged due to an electrical storm, presumably ver= y intense activity, even while off. Go look through the archives. >>>=20 >> I have had two incidents where nearby lightning strikes blew out component= s on gear I had. Many years ago, I had two computers connected by a parallel= port cable, and chips on both ends were popped by a strike that might have h= it power lines about two blocks away. >> About a decade ago, we had a lightning strike that hit trees half a block = away. It took out an ethernet port on one computer, and blew out a bunch of = stuff on a burglar alarm I had built. Both involved long wire runs. >=20 > I have had lots of stuff taken out by lightening. Even when it > wasn't particularly close but hit a power line as much as a mile > away. I used to have problems until I put substantial panel-mounted surge protector= s both at the main power entry and at the panels of the barns. Since then, a= ll good. Phone and cable are also protected, and all those protectors are mo= unted on a sheet of copper connected directly to the main panel shell and the= main ground. paul --===============4161760407901123181==-- From shumaker@att.net Tue Apr 2 20:54:31 2024 From: steve shumaker To: cctalk@classiccmp.org Subject: [cctalk] Re: EMP was: oscilloscopes Date: Tue, 02 Apr 2024 13:54:19 -0700 Message-ID: In-Reply-To: <00E093ED-E0CE-4A89-A2E9-392B738AB8D6@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2504655491639637290==" --===============2504655491639637290== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks! Steve On 4/2/24 9:37 AM, Paul Koning wrote: > >> On Apr 2, 2024, at 11:54 AM, steve shumaker via cctalk wrote: >> >> Company (Polyphaser) web page doesn't seem to list that handbook as an ava= ilable lit product. Can you suggest a source? >> >> Steve >> >> >> On 4/2/24 8:13 AM, Paul Koning via cctalk wrote: >>> ... >>> A great reference for all this is the handbook "The grounds for lightning= protection" by Polyphase Co., a maker of professional lightning protection d= evices. I haven't done everything they call for -- for example, our house do= esn't have a perimeter ground. But it does now have single point grounding, = and as a result we've had no trouble even though there have been plenty of li= ghtning strikes in the neighborhood. >>> >>> paul > I found a somewhat different book from Polyphaser:https://w5nor.org/present= ations/PolyphaserGuide.pdf which cites the other one in the references secti= on in the back. The material looks rather similar to the older book; I recog= nized a number of illustrations. It has more content, it seems, and more rec= ent material. > > The exact title is "The Grounds for Lightning and EMP Protection" by Roger = Block, and searching for that title yields some sources, including a used cop= y on eBay and an online copy on Scribd. > > paul > --===============2504655491639637290==-- From fedorkow@mit.edu Wed Apr 3 15:07:33 2024 From: Guy Fedorkow To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:01:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2193708203526974712==" --===============2193708203526974712== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Vintage computer enthusiasts might want to keep track of where to find=20 CRT-based analog oscilloscopes, for use as output devices. The early MIT and Lincoln Labs computers used D/A converters to steer=20 and activate the beam on analog scopes to draw vector images. Working on Whirlwind simulation, we've been able to get this technique=20 to work with "real" oscilloscopes, e.g., Tek 475, but we have not yet=20 found a single DSO that has X/Y _and_ Z inputs (let alone the required=20 phosphor fade). =C2=A0 Myself, I have a couple scopes with backups, so I'm not in the market= =20 for another one.=C2=A0 But others might consider the option... =C2=A0 /guy fedorkow Date: Mon, 01 Apr 2024 22:33:38 +0000 From: Just Kant Subject: [cctalk] oscilloscopes To: "General Discussion: On-Topic and Off-Topic Posts" Message-ID: Content-Type: text/plain; charset=3Dutf-8 I have more then I need. All the working ones are HP w/color crts, and as far= as older, verifiably vintage tools (right down to the 680x0 processor in eit= her) I have to admit I favor them as a brand. Call we an oddball, weird egg, = badges I wear with pride. But who could resist the allure of the newer ultra portable, even handheld un= its (some with bandwidth or sampling rates to 50mhz). I'm a big cheapo. But t= here's no real reason to agonize over a 65 - 200$ or thereabouts acquisition.= It's a bit tiring to wade through the piles of availability. I favor a deskt= op unit, larger screen (but not always, careful). But most of those need wall= current I think? The convenience of a handheld battery powered unit obviousl= y has it's benefits. I will always love and dote upon my color crt based HPs. But the damned thing= s are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit the paved = floor, shook the house. And still works! Built to withstand an atomic bombard= ment. --===============2193708203526974712==-- From paulkoning@comcast.net Wed Apr 3 15:16:14 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:16:07 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1777387201897998363==" --===============1777387201897998363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 11:01 AM, Guy Fedorkow via cctalk wrote: >=20 > Vintage computer enthusiasts might want to keep track of where to find CRT-= based analog oscilloscopes, for use as output devices. > The early MIT and Lincoln Labs computers used D/A converters to steer and a= ctivate the beam on analog scopes to draw vector images. > Working on Whirlwind simulation, we've been able to get this technique to w= ork with "real" oscilloscopes, e.g., Tek 475, but we have not yet found a sin= gle DSO that has X/Y _and_ Z inputs (let alone the required phosphor fade). So did a whole range of DEC computers, of course. And the famous CDC mainfra= me console (DD60) though it did vectors only for text (graphics was dot-mode = only since it wasn't a major use case for that device). I once built a graphics display setup for an 11/20 lab machine (in college) u= sing DEC D/A modules (AA-01?) with an RC-11 disk serving as the refresh memor= y, DMA direct to the D/A data register. paul --===============1777387201897998363==-- From michael.99.thompson@gmail.com Wed Apr 3 15:18:13 2024 From: Michael Thompson To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:17:53 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3268239838655546489==" --===============3268239838655546489== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit DEC used Tektronix R503 scopes for a display on many of their early machines. On Wed, Apr 3, 2024 at 11:16 AM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > > > > On Apr 3, 2024, at 11:01 AM, Guy Fedorkow via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > Vintage computer enthusiasts might want to keep track of where to find > CRT-based analog oscilloscopes, for use as output devices. > > The early MIT and Lincoln Labs computers used D/A converters to steer > and activate the beam on analog scopes to draw vector images. > > Working on Whirlwind simulation, we've been able to get this technique > to work with "real" oscilloscopes, e.g., Tek 475, but we have not yet found > a single DSO that has X/Y _and_ Z inputs (let alone the required phosphor > fade). > > So did a whole range of DEC computers, of course. And the famous CDC > mainframe console (DD60) though it did vectors only for text (graphics was > dot-mode only since it wasn't a major use case for that device). > > I once built a graphics display setup for an 11/20 lab machine (in > college) using DEC D/A modules (AA-01?) with an RC-11 disk serving as the > refresh memory, DMA direct to the D/A data register. > > paul > > > -- Michael Thompson --===============3268239838655546489==-- From bitwiz@12bitsbest.com Wed Apr 3 15:21:21 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 10:21:10 -0500 Message-ID: <2e0be5fc-9146-494b-84f9-3cf4313dd875@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0549659861924173870==" --===============0549659861924173870== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I'm surprised some digital scope manufacturer hasn't implemented X-Y-Z control as an option.   Driving X-Y was fairly common for certain types of signals.  And many also used the Z input. Back in the day there were many companies that made X-Y or X-Y-Z displays. On 4/3/2024 10:01 AM, Guy Fedorkow via cctalk wrote: > Vintage computer enthusiasts might want to keep track of where to find > CRT-based analog oscilloscopes, for use as output devices. > The early MIT and Lincoln Labs computers used D/A converters to steer > and activate the beam on analog scopes to draw vector images. > Working on Whirlwind simulation, we've been able to get this technique > to work with "real" oscilloscopes, e.g., Tek 475, but we have not yet > found a single DSO that has X/Y _and_ Z inputs (let alone the required > phosphor fade). > >   Myself, I have a couple scopes with backups, so I'm not in the > market for another one.  But others might consider the option... > >   /guy fedorkow > > > Date: Mon, 01 Apr 2024 22:33:38 +0000 > From: Just Kant > Subject: [cctalk] oscilloscopes > To: "General Discussion: On-Topic and Off-Topic Posts" >      > Message-ID:     NxX-XE1ru7jPj1GFbu0aE3uBwUsVKxlU_XAYKX9B0x42zJZADc=@protonmail.com> > Content-Type: text/plain; charset=utf-8 > > I have more then I need. All the working ones are HP w/color crts, and > as far as older, verifiably vintage tools (right down to the 680x0 > processor in either) I have to admit I favor them as a brand. Call we > an oddball, weird egg, badges I wear with pride. > > But who could resist the allure of the newer ultra portable, even > handheld units (some with bandwidth or sampling rates to 50mhz). I'm a > big cheapo. But there's no real reason to agonize over a 65 - 200$ or > thereabouts acquisition. It's a bit tiring to wade through the piles > of availability. I favor a desktop unit, larger screen (but not > always, careful). But most of those need wall current I think? The > convenience of a handheld battery powered unit obviously has it's > benefits. > > I will always love and dote upon my color crt based HPs. But the > damned things are so heavy, so unwieldy. Judy-Jude knocked my 54111d > over, hit the paved floor, shook the house. And still works! Built to > withstand an atomic bombardment. > > > --===============0549659861924173870==-- From paulkoning@comcast.net Wed Apr 3 15:27:06 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:26:53 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4047243043146916055==" --===============4047243043146916055== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 11:16 AM, Paul Koning via cctalk wrote: >=20 >=20 >=20 >> On Apr 3, 2024, at 11:01 AM, Guy Fedorkow via cctalk wrote: >>=20 >> Vintage computer enthusiasts might want to keep track of where to find CRT= -based analog oscilloscopes, for use as output devices. >> The early MIT and Lincoln Labs computers used D/A converters to steer and = activate the beam on analog scopes to draw vector images. >> Working on Whirlwind simulation, we've been able to get this technique to = work with "real" oscilloscopes, e.g., Tek 475, but we have not yet found a si= ngle DSO that has X/Y _and_ Z inputs (let alone the required phosphor fade). >=20 > So did a whole range of DEC computers, of course. And the famous CDC mainf= rame console (DD60) though it did vectors only for text (graphics was dot-mod= e only since it wasn't a major use case for that device). The DD60 and its associated controller in the mainframe (6612 or 6602) was an= interesting beast. The interface between controller and display is a hybrid= , with the positioning information delivered as 9 bits each of X and Y, but t= he character vectors are generated in the controller and sent to the display = as analog waveforms, X and Y on differential pairs. Another oddity is the character waveform generation: that uses two pairs of A= /D converters, and the converters are essentially base one -- 6 equally weig= hted inputs to produce output values 0..6. And since ROMs were hard to come= by in 1964, at least ones with 100 ns cycle time, the digital inputs for the= waveform generators are an amazingly large pile of gates. paul --===============4047243043146916055==-- From paulkoning@comcast.net Wed Apr 3 15:27:58 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:27:51 -0400 Message-ID: In-Reply-To: <2e0be5fc-9146-494b-84f9-3cf4313dd875@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1816210147963359183==" --===============1816210147963359183== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 11:21 AM, Mike Katz via cctalk = wrote: >=20 > I'm surprised some digital scope manufacturer hasn't implemented X-Y-Z cont= rol as an option. Driving X-Y was fairly common for certain types of signal= s. And many also used the Z input. Oh, they offer X/Y display, but sampled just as the normal operation is. Som= e of the applications we're talking about here don't appreciate the digitizat= ion artefacts. paul --===============1816210147963359183==-- From uban@ubanproductions.com Wed Apr 3 15:53:15 2024 From: Tom Uban To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 10:47:32 -0500 Message-ID: <23c372c8-f511-46b4-80af-eb2b016decc4@ubanproductions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7511054466716796733==" --===============7511054466716796733== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have a pair of CDC6600 console CRTs (~12" diameter electrostatic deflection= vector), I've been=20 working on "restoring" a console which I salvaged from Purdue surplus many ye= ars ago, but have kind=20 of stalled on at present and it takes up a significant amount of space. If so= meone would like to=20 take over the project, let's talk... For those who are not familiar, it looks like this: https://en.wikipedia.org/wiki/CDC_6600#/media/File:Control_Data_6600_mainfram= e.jpg I have the remains of most of the drive electronics, but the design runs on 4= 00Hz power, so I am=20 planning on using a solid state power converter to run it. The ultimate plan = of course is to run a=20 Pi (or FPGA) CDC6600 simulation to drive the console. --tom On 4/3/24 10:01, Guy Fedorkow via cctalk wrote: > Vintage computer enthusiasts might want to keep track of where to find CRT-= based analog=20 > oscilloscopes, for use as output devices. > The early MIT and Lincoln Labs computers used D/A converters to steer and a= ctivate the beam on=20 > analog scopes to draw vector images. > Working on Whirlwind simulation, we've been able to get this technique to w= ork with "real"=20 > oscilloscopes, e.g., Tek 475, but we have not yet found a single DSO that h= as X/Y _and_ Z inputs=20 > (let alone the required phosphor fade). > > =C2=A0 Myself, I have a couple scopes with backups, so I'm not in the marke= t for another one.=C2=A0 But=20 > others might consider the option... > > =C2=A0 /guy fedorkow > > > Date: Mon, 01 Apr 2024 22:33:38 +0000 > From: Just Kant > Subject: [cctalk] oscilloscopes > To: "General Discussion: On-Topic and Off-Topic Posts" > =C2=A0=C2=A0=C2=A0=C2=A0 > Message-ID: =C2=A0=C2=A0=C2=A0=C2=A0NxX-XE1ru7jPj1GFbu0aE3uBwUsVKxlU_XAYKX9B0x42zJZADc= =3D@protonmail.com> > Content-Type: text/plain; charset=3Dutf-8 > > I have more then I need. All the working ones are HP w/color crts, and as f= ar as older, verifiably=20 > vintage tools (right down to the 680x0 processor in either) I have to admit= I favor them as a=20 > brand. Call we an oddball, weird egg, badges I wear with pride. > > But who could resist the allure of the newer ultra portable, even handheld = units (some with=20 > bandwidth or sampling rates to 50mhz). I'm a big cheapo. But there's no rea= l reason to agonize=20 > over a 65 - 200$ or thereabouts acquisition. It's a bit tiring to wade thro= ugh the piles of=20 > availability. I favor a desktop unit, larger screen (but not always, carefu= l). But most of those=20 > need wall current I think? The convenience of a handheld battery powered un= it obviously has it's=20 > benefits. > > I will always love and dote upon my color crt based HPs. But the damned thi= ngs are so heavy, so=20 > unwieldy. Judy-Jude knocked my 54111d over, hit the paved floor, shook the = house. And still works!=20 > Built to withstand an atomic bombardment. > > > --===============7511054466716796733==-- From mjd.bishop@emeritus-solutions.com Wed Apr 3 16:14:10 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 16:13:19 +0000 Message-ID: <335c00973bb14cc08d6797ae8a28766f@emeritus-solutions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4473796476943801799==" --===============4473796476943801799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable rfgh -----Original Message----- From: Guy Fedorkow via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 03 April 2024 16:02 To: cctalk(a)classiccmp.org Cc: Guy Fedorkow Subject: [cctalk] Re: oscilloscopes Vintage computer enthusiasts might want to keep track of where to find CRT-ba= sed analog oscilloscopes, for use as output devices. The early MIT and Lincoln Labs computers used D/A converters to steer and act= ivate the beam on analog scopes to draw vector images. Working on Whirlwind simulation, we've been able to get this technique to wor= k with "real" oscilloscopes, e.g., Tek 475, but we have not yet found a singl= e DSO that has X/Y _and_ Z inputs (let alone the required phosphor fade). =C2=A0 Myself, I have a couple scopes with backups, so I'm not in the market= for another one.=C2=A0 But others might consider the option... =C2=A0 /guy fedorkow Date: Mon, 01 Apr 2024 22:33:38 +0000 From: Just Kant Subject: [cctalk] oscilloscopes To: "General Discussion: On-Topic and Off-Topic Posts" Message-ID: Content-Type: text/plain; charset=3Dutf-8 I have more then I need. All the working ones are HP w/color crts, and as far= as older, verifiably vintage tools (right down to the 680x0 processor in eit= her) I have to admit I favor them as a brand. Call we an oddball, weird egg, = badges I wear with pride. But who could resist the allure of the newer ultra portable, even handheld un= its (some with bandwidth or sampling rates to 50mhz). I'm a big cheapo. But t= here's no real reason to agonize over a 65 - 200$ or thereabouts acquisition.= It's a bit tiring to wade through the piles of availability. I favor a deskt= op unit, larger screen (but not always, careful). But most of those need wall= current I think? The convenience of a handheld battery powered unit obviousl= y has it's benefits. I will always love and dote upon my color crt based HPs. But the damned thing= s are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit the paved = floor, shook the house. And still works! Built to withstand an atomic bombard= ment. --===============4473796476943801799==-- From mjd.bishop@emeritus-solutions.com Wed Apr 3 16:29:16 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 16:28:26 +0000 Message-ID: <5b31aea2061a4b7f85c0f77060c52324@emeritus-solutions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0794059604220236932==" --===============0794059604220236932== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ignore my last - incontinence or is it incompetence A fairly ordinary GPU, in a PC, could almost certainly provide an XY display = with Z fade (long persistance phosphor). I use them for waterfall displays a= nd they keep up - the data does of course arrive by E'net. Equally, FPGAs / SOCs can implement frame buffers; eg to output waterfall dis= plays. The fading memory would have to be in DRAM, FPGA memory is fast but s= mall 3 ns access time but only 240 ki by .. 2.18 Mi by (Zynq 10 .. 45, the '4= 5 is a corporate purchase). A ping pong buffer arrangement could implement f= ading - computed in either processor (vector instructions) or logic (raw mus= cle). The DAC input lines could supply the data. Martin -----Original Message----- From: Guy Fedorkow via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 03 April 2024 16:02 To: cctalk(a)classiccmp.org Cc: Guy Fedorkow Subject: [cctalk] Re: oscilloscopes Vintage computer enthusiasts might want to keep track of where to find CRT-ba= sed analog oscilloscopes, for use as output devices. The early MIT and Lincoln Labs computers used D/A converters to steer and act= ivate the beam on analog scopes to draw vector images. Working on Whirlwind simulation, we've been able to get this technique to wor= k with "real" oscilloscopes, e.g., Tek 475, but we have not yet found a singl= e DSO that has X/Y _and_ Z inputs (let alone the required phosphor fade). =C2=A0 Myself, I have a couple scopes with backups, so I'm not in the market= for another one.=C2=A0 But others might consider the option... =C2=A0 /guy fedorkow Date: Mon, 01 Apr 2024 22:33:38 +0000 From: Just Kant Subject: [cctalk] oscilloscopes To: "General Discussion: On-Topic and Off-Topic Posts" Message-ID: Content-Type: text/plain; charset=3Dutf-8 I have more then I need. All the working ones are HP w/color crts, and as far= as older, verifiably vintage tools (right down to the 680x0 processor in eit= her) I have to admit I favor them as a brand. Call we an oddball, weird egg, = badges I wear with pride. But who could resist the allure of the newer ultra portable, even handheld un= its (some with bandwidth or sampling rates to 50mhz). I'm a big cheapo. But t= here's no real reason to agonize over a 65 - 200$ or thereabouts acquisition.= It's a bit tiring to wade through the piles of availability. I favor a deskt= op unit, larger screen (but not always, careful). But most of those need wall= current I think? The convenience of a handheld battery powered unit obviousl= y has it's benefits. I will always love and dote upon my color crt based HPs. But the damned thing= s are so heavy, so unwieldy. Judy-Jude knocked my 54111d over, hit the paved = floor, shook the house. And still works! Built to withstand an atomic bombard= ment. --===============0794059604220236932==-- From bitwiz@12bitsbest.com Wed Apr 3 16:43:31 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:01:40 -0500 Message-ID: <91cfbb02-8570-4d46-8f3f-bf99a257b3ee@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4833608433123834058==" --===============4833608433123834058== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I still have a TEK 475A (with the DMM4 on top) and a TEK 11043A mainframe scope. The 475A is rock solid and is one of the best analog triggering scopes ever made.  The 11403A goes all the way up to 3GHz but, tbh, is was a difficult to use touch screen scope.  I still use both of them occasionally. I had a Sony Tektronix Battery Operated 10 or 20 MHz scope ( I can't remember which) that was lent out never to be seen again.  The nicest thing about it was that the two channels were completely electrically isolated from each other. My go to scopes now are a couple of PicoScope USB scopes with logic analyzers and arbitrary function generators. Here are the two TEK scopes.  The 475A is showing both a sine and a square wave at 1 MHz (chopped).  The 11403A is showing a 1GHz sine wave and 7 other unconnected traces just to show that is can display 8 traces at once.  The three plugins on the 11403A are, 4 trace 3000MHz/trace, 2 trace 1GHz/trace and 2 trace 50MHz Current Probe Amplifier. On 4/1/2024 5:56 PM, Fred Cisin via cctalk wrote: > On Mon, 1 Apr 2024, Just Kant via cctalk wrote: >> I have more then I need. All the working ones are HP w/color crts, >> and as far as older, verifiably vintage tools (right down to the >> 680x0 processor in either) I have to admit I favor them as a brand. >> Call we an oddball, weird egg, badges I wear with pride. >> But who could resist the allure of the newer ultra portable, even >> handheld units (some with bandwidth or sampling rates to 50mhz). I'm >> a big cheapo. But there's no real reason to agonize over a 65 - 200$ >> or thereabouts acquisition. It's a bit tiring to wade through the >> piles of availability. I favor a desktop unit, larger screen (but not >> always, careful). But most of those need wall current I think? The >> convenience of a handheld battery powered unit obviously has it's >> benefits. >> I will always love and dote upon my color crt based HPs. But the >> damned things are so heavy, so unwieldy. Judy-Jude knocked my 54111d >> over, hit the paved floor, shook the house. And still works! Built to >> withstand an atomic bombardment. > > I had a Tektronix 512, > and an NLS215 (battery powered portable) from a company that switched > over to making Kaypros.  I gave it away at one of the first VCFs. > I guess that the vintage ones are no longer adequate. > > -- > Grumpy Ol' Fred --===============4833608433123834058==-- From paulkoning@comcast.net Wed Apr 3 17:38:33 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 13:38:25 -0400 Message-ID: <77DD9D60-2331-4FCC-9B45-9FDEBF2560DC@comcast.net> In-Reply-To: <5b31aea2061a4b7f85c0f77060c52324@emeritus-solutions.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1482354863933995633==" --===============1482354863933995633== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 12:28 PM, Martin Bishop via cctalk wrote: >=20 > Ignore my last - incontinence or is it incompetence >=20 > A fairly ordinary GPU, in a PC, could almost certainly provide an XY displa= y with Z fade (long persistance phosphor). I use them for waterfall displays= and they keep up - the data does of course arrive by E'net. Yes, and some emulations have done this, such as Phil Budne's famous work in = SIMH. I adopted some of those ideas for DtCyber (CDC 6000 emulation) and it = works well, though the timing is marginal given the graphics subsystem I use.= That is WxWidgets -- changes are SDL would do better and some day I will tr= y that. > Equally, FPGAs / SOCs can implement frame buffers; eg to output waterfall d= isplays. The fading memory would have to be in DRAM, FPGA memory is fast but= small 3 ns access time but only 240 ki by .. 2.18 Mi by (Zynq 10 .. 45, the = '45 is a corporate purchase). A ping pong buffer arrangement could implement= fading - computed in either processor (vector instructions) or logic (raw m= uscle). The DAC input lines could supply the data. Agreed, and that would be an elegant way to emulate a CDC DD60. Or a GT40. = You'd presumably want to use at least an HD level display signal (1920 by 108= 0), if not double that, to make it look right; less than that would give pixe= l artefacts that make it not look as vector-like as you would want. paul --===============1482354863933995633==-- From bitwiz@12bitsbest.com Wed Apr 3 17:43:00 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:41:27 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3220381579836158423==" --===============3220381579836158423== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I still have a TEK 475A (with the DMM4 on top) and a TEK 11043A=20 mainframe scope. The 475A is rock solid and is one of the best analog triggering scopes=20 ever made.=C2=A0 The 11403A goes all the way up to 3GHz but, tbh, is was a=20 difficult to use touch screen scope.=C2=A0 I still use both of them occasiona= lly. I had a Sony Tektronix Battery Operated 10 or 20 MHz scope ( I can't=20 remember which) that was lent out never to be seen again.=C2=A0 The nicest=20 thing about it was that the two channels were completely electrically=20 isolated from each other. My go to scopes now are a couple of PicoScope USB scopes with logic=20 analyzers and arbitrary function generators. Here are the two TEK scopes.=C2=A0 The 475A is showing both a sine and a=20 square wave at 1 MHz (chopped).=C2=A0 The 11403A is showing a 1GHz sine wave = and 7 other unconnected traces just to show that is can display 8 traces=20 at once.=C2=A0 The three plugins on the 11403A are, 4 trace 300MHz/trace, 2=20 trace 1GHz/trace and 2 trace 50MHz Current Probe Amplifier. https://drive.google.com/file/d/10lFayScEaebLSAKRyEhUmIC_MoONMkcu/view?usp=3D= sharing On 4/1/2024 5:56 PM, Fred Cisin via cctalk wrote: > On Mon, 1 Apr 2024, Just Kant via cctalk wrote: >> I have more then I need. All the working ones are HP w/color crts,=20 >> and as far as older, verifiably vintage tools (right down to the=20 >> 680x0 processor in either) I have to admit I favor them as a brand.=20 >> Call we an oddball, weird egg, badges I wear with pride. >> But who could resist the allure of the newer ultra portable, even=20 >> handheld units (some with bandwidth or sampling rates to 50mhz). I'm=20 >> a big cheapo. But there's no real reason to agonize over a 65 - 200$=20 >> or thereabouts acquisition. It's a bit tiring to wade through the=20 >> piles of availability. I favor a desktop unit, larger screen (but not=20 >> always, careful). But most of those need wall current I think? The=20 >> convenience of a handheld battery powered unit obviously has it's=20 >> benefits. >> I will always love and dote upon my color crt based HPs. But the=20 >> damned things are so heavy, so unwieldy. Judy-Jude knocked my 54111d=20 >> over, hit the paved floor, shook the house. And still works! Built to=20 >> withstand an atomic bombardment. > > I had a Tektronix 512, > and an NLS215 (battery powered portable) from a company that switched=20 > over to making Kaypros.=C2=A0 I gave it away at one of the first VCFs. > I guess that the vintage ones are no longer adequate. > > --=20 > Grumpy Ol' Fred --===============3220381579836158423==-- From rickb@bensene.com Wed Apr 3 17:50:06 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 17:49:58 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8172969974255999976==" --===============8172969974255999976== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul wrote: > The DD60 and its associated controller in the mainframe (6612 or 6602) was = an > interesting beast. The interface between controller and display is a hy= brid, > with the positioning information delivered as 9 bits each of X and Y,= but the > character vectors are generated in the controller and sent to the = display as=20 > analog waveforms, X and Y on differential pairs. > Another oddity is the character waveform generation: that uses two pairs of= =20 > A/D converters, and the converters are essentially base one -- 6 equally=20 > weighted inputs to produce output values 0..6. And since ROMs were hard to= =20 > come by in 1964, at least ones with 100 ns cycle time, the digital inputs f= or > the waveform generators are an amazingly large pile of gates. I was a systems operator (as it was called back in the day) on a Control Data= Cyber 73 at Tektronix for a number of years. The round console displays on= the machine were simply beautiful. The characters were very clear and easy = to read, even though they packed a lot of them on the screen. One thing tha= t I thought was particularly cool about it is that you could pull up a page o= f any section of memory and watch the live data flicker around as the machine= was running. Pretty amazing. On a similar display topic, I have a very unusual old electronic calculator m= ade by a US company called Wyle Laboratories. The machine was designed in th= e 1962-1063 timeframe. It is all Germanium-Transistor and Resistor logic(RTL= ). The Model WS-01/WS-02 (two versions, both using the same display subsyste= m, but varied in terms of the main register storage) calculators used a CRT d= isplay for showing the content of the registers to the user. The display consists of six lines of 24 digits each. The six lines represent the conten= t of three memory registers, the accumulator, a multiplier-quotient register,= and the numeric entry register. =20 Even with only having to render the digits zero through nine and a decimal po= int (the calculator didn't support negative numbers; they were represented us= ing tens complement form), the display generator also used a batch of diode-t= ransistor gates to generate the digits. The interesting thing about it is = that instead of generating strokes to create the digits, the machine uses sin= e/cosine waveforms that are gated by the character generation logic to draw t= he digits on the screen. The position of the digits, like the CDC scopes, i= s derived by precision resistor DACs, and then a mixer takes over as the char= acter is drawn using gated segments of the sine and cosine waveforms mixed to= gether with the position voltage. The result is really beautifully rendered= digits that look almost like they are drawn by a draftsperson who is extreme= ly consistent in the drawing of each digit. The CRT has yellow-orange phosph= or with a moderate persistence, so when the digits change, they look like the= y quickly morph from one digit to the next. =20 =20 The digits are among the nicest looking digits that I've ever seen on a CRT d= isplay, including those on the CDC scopes as well as IBM console displays. They are far more aesthetically (to my taste, anyway) pleasing than the segme= nted digits drawn on other CRT-display calculators such as the HP 9100A/B, Fr= iden EC-130/132 and 116x, Victor 3900 and 14-321/14-322, SCM Cogito 240/240S= R, Busicom 202/207/2017, and some calculators (usually clones of US or Japane= se-designed machines) made in the former Soviet Union. -Rick --===============8172969974255999976==-- From cclist@sydex.com Wed Apr 3 18:03:13 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 10:47:57 -0700 Message-ID: In-Reply-To: <91cfbb02-8570-4d46-8f3f-bf99a257b3ee@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5597163398394331273==" --===============5597163398394331273== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/3/24 09:01, Mike Katz via cctalk wrote: > I still have a TEK 475A (with the DMM4 on top) and a TEK 11043A > mainframe scope. I still occasionally haul out my 465A. If I got rid of it, I'd have to figure out what to do with the scope cart... --Chuck --===============5597163398394331273==-- From bitwiz@12bitsbest.com Wed Apr 3 18:07:03 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 11:54:53 -0500 Message-ID: In-Reply-To: <91cfbb02-8570-4d46-8f3f-bf99a257b3ee@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8946304230340029589==" --===============8946304230340029589== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit For some reason the mailing list deleted the link to the photo, I'm sorry. On 4/3/2024 11:01 AM, Mike Katz via cctalk wrote: > I still have a TEK 475A (with the DMM4 on top) and a TEK 11043A > mainframe scope. > > The 475A is rock solid and is one of the best analog triggering scopes > ever made.  The 11403A goes all the way up to 3GHz but, tbh, is was a > difficult to use touch screen scope.  I still use both of them > occasionally. > > I had a Sony Tektronix Battery Operated 10 or 20 MHz scope ( I can't > remember which) that was lent out never to be seen again. The nicest > thing about it was that the two channels were completely electrically > isolated from each other. > > My go to scopes now are a couple of PicoScope USB scopes with logic > analyzers and arbitrary function generators. > > Here are the two TEK scopes.  The 475A is showing both a sine and a > square wave at 1 MHz (chopped).  The 11403A is showing a 1GHz sine > wave and 7 other unconnected traces just to show that is can display 8 > traces at once.  The three plugins on the 11403A are, 4 trace > 3000MHz/trace, 2 trace 1GHz/trace and 2 trace 50MHz Current Probe > Amplifier. > > > > On 4/1/2024 5:56 PM, Fred Cisin via cctalk wrote: >> On Mon, 1 Apr 2024, Just Kant via cctalk wrote: >>> I have more then I need. All the working ones are HP w/color crts, >>> and as far as older, verifiably vintage tools (right down to the >>> 680x0 processor in either) I have to admit I favor them as a brand. >>> Call we an oddball, weird egg, badges I wear with pride. >>> But who could resist the allure of the newer ultra portable, even >>> handheld units (some with bandwidth or sampling rates to 50mhz). I'm >>> a big cheapo. But there's no real reason to agonize over a 65 - 200$ >>> or thereabouts acquisition. It's a bit tiring to wade through the >>> piles of availability. I favor a desktop unit, larger screen (but >>> not always, careful). But most of those need wall current I think? >>> The convenience of a handheld battery powered unit obviously has >>> it's benefits. >>> I will always love and dote upon my color crt based HPs. But the >>> damned things are so heavy, so unwieldy. Judy-Jude knocked my 54111d >>> over, hit the paved floor, shook the house. And still works! Built >>> to withstand an atomic bombardment. >> >> I had a Tektronix 512, >> and an NLS215 (battery powered portable) from a company that switched >> over to making Kaypros.  I gave it away at one of the first VCFs. >> I guess that the vintage ones are no longer adequate. >> >> -- >> Grumpy Ol' Fred --===============8946304230340029589==-- From paulkoning@comcast.net Wed Apr 3 18:21:16 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 14:20:47 -0400 Message-ID: <28C5699E-D860-435B-B2A6-BCDA30ADDACE@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6445625719166186649==" --===============6445625719166186649== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 1:49 PM, Rick Bensene via cctalk wrote: >=20 > ... > Even with only having to render the digits zero through nine and a decimal = point (the calculator didn't support negative numbers; they were represented = using tens complement form), the display generator also used a batch of diode= -transistor gates to generate the digits. The interesting thing about it i= s that instead of generating strokes to create the digits, the machine uses s= ine/cosine waveforms that are gated by the character generation logic to draw= the digits on the screen. The position of the digits, like the CDC scopes,= is derived by precision resistor DACs, and then a mixer takes over as the ch= aracter is drawn using gated segments of the sine and cosine waveforms mixed = together with the position voltage. The result is really beautifully render= ed digits that look almost like they are drawn by a draftsperson who is extre= mely consistent in the drawing of each digit. The CRT has yellow-orange phos= phor with a moderate persistence, so when the digits change, they look like t= hey quickly morph from one digit to the next. =20 >=20 > The digits are among the nicest looking digits that I've ever seen on a CRT= display, including those on the CDC scopes as well as IBM console displays. I have, somewhere, a copy of a paper that describes analog circuits for gener= ating waveforms for digits along the lines you describe. Might have been fro= m MIT, in the 1950s, but right now I can't find it. The CDC console waveforms start out as step function waveforms, with delta x = and/or y of +/- 1 or 2 units, at 100 ns intervals. Given the bandwidths of t= he circuits involved they get rounded off in the generation, and a whole lot = more in the DD60 deflection amplifier signal chain. I've tried to create a S= PICE model of that signal path to try to reproduce what we know actually show= ed up on the display screen, but haven't had much luck. Too much of the circ= uit involves parts with unknown properties, starting with the transistors, on= to the wirewound resistors that apparently show up in various places, and en= ding with the deflection plates of the CRTs themselves. Still, a crude IIR f= ilter mimicking some of the more obvious contributions do produce acceptable = character shapes in my DD60 emulation software. Speaking of nice looking numeric displays: probably the best ever are the pro= jection displays made by IEE, in the 1960s I think. https://www.antiqueradio= s.com/forums//viewtopic.php?f=3D12&t=3D341355 shows a sample. A few computer= s from that era used them for the console, the CDC 1604 seems to be an exampl= e. paul --===============6445625719166186649==-- From paulkoning@comcast.net Wed Apr 3 18:44:45 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 14:44:17 -0400 Message-ID: In-Reply-To: <28C5699E-D860-435B-B2A6-BCDA30ADDACE@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3451538253530800169==" --===============3451538253530800169== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 2:20 PM, Paul Koning via cctalk wrote: >=20 >=20 >=20 >> On Apr 3, 2024, at 1:49 PM, Rick Bensene via cctalk wrote: >>=20 >> ... >> Even with only having to render the digits zero through nine and a decimal= point (the calculator didn't support negative numbers; they were represented= using tens complement form), the display generator also used a batch of diod= e-transistor gates to generate the digits. The interesting thing about it = is that instead of generating strokes to create the digits, the machine uses = sine/cosine waveforms that are gated by the character generation logic to dra= w the digits on the screen. The position of the digits, like the CDC scopes= , is derived by precision resistor DACs, and then a mixer takes over as the c= haracter is drawn using gated segments of the sine and cosine waveforms mixed= together with the position voltage. The result is really beautifully rende= red digits that look almost like they are drawn by a draftsperson who is extr= emely consistent in the drawing of each digit. The CRT has yellow-orange pho= sphor with a moderate persistence, so when the digits change, they look like = they quickly morph from one digit to the next. =20 >>=20 >> The digits are among the nicest looking digits that I've ever seen on a CR= T display, including those on the CDC scopes as well as IBM console displays. >=20 > I have, somewhere, a copy of a paper that describes analog circuits for gen= erating waveforms for digits along the lines you describe. Might have been f= rom MIT, in the 1950s, but right now I can't find it. Found it (on paper): "Generating characters" by Kenneth Perry and Everett Aho= , Electronics, Jan 3, 1958, pp. 72-75. Bitsavers has it in the MIT/LincolnLaboratory section: https://bitsavers.org/= pdf/mit/lincolnLaboratory/Perry_and_Aho_-_Generating_Characters_-_Electronics= _19580103.pdf paul --===============3451538253530800169==-- From rickb@bensene.com Wed Apr 3 22:32:43 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Wed, 03 Apr 2024 22:32:29 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5164852973296826912==" --===============5164852973296826912== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I wrote: >> The digits are among the nicest looking digits that I've ever seen=20 >> on a CRT display, including those on the CDC scopes as well as IBM >> cons= ole displays. =20 To which Paul responded: > I have, somewhere, a copy of a paper that describes analog circuits > for g= enerating waveforms for digits along the lines you describe. =20 > Might have been from MIT, in the 1950s, but right now I can't find > it. > Found it (on paper): "Generating characters" by Kenneth Perry and=20 > Everett Aho, > Electronics, Jan 3, 1958, pp. 72-75. > Bitsavers has it in the MIT/LincolnLaboratory section: https://bitsavers.= org/pdf/mit/lincolnLaboratory/Perry_and_Aho__Generating_Characters_-_Electron= ics_19580103.pdf Very interesting. Here's a link to the patent for the display system on the= Wyle Labs calculator: https://patentimages.storage.googleapis.com/17/51/58/89c19cee6c60e2/US3305843= .pdf The concepts are very similar to the paper written up in ELECTRONICS magazine= in early 1958 that you found. Your memory is incredible to have been able t= o have this pop into your mind when you read my description of the way the ca= lculator generates its display. Thank you for looking up this article! It'll provide some nice background f= or the concepts of generating characters this way when I finally get to docum= enting the Wyle WS-01/WS-02 calculators in an Old Calculator Museum exhibit. I wonder if the inventor of the display system for the calculator (in fact, t= he inventor of the entire Wyle Labs calculator architecture) had read this ar= ticle at some point prior? =20 I scanned through the patent for the calculator display system looking for an= y reference to the article or any document from MIT relating, and I couldn't = find anything. =20 The inventor is still alive, and I have talked to him on the telephone a coup= le of times. For his advanced age, he is still quite sharp, and remembers a= lot of the challenges involved with trying to make a solid-state electronic = calculator that would fit on a (large) desktop using early 1960's technology.= =20 Here's a link to a little information about the calculator: https://oldcalculatormuseum.com/w-wyle.html=20 It's hard to tell from the photo (from advertising material of the day) how l= arge the machine is, but the dimensions and weight (50 pounds!) are included= in the specifications at the end of the page. It's quite a monster. The two models of the machine differed in that the WS-01 utilized a home-brew= ed(e.g., made entirely within Wyle Labs) rotating magnetic memory as the stor= age for the working registers (as well as for timing tracks that provided clo= cking signals). It proved to be very temperamental with many failures in th= e hands of customers that gave the machine somewhat of a tarnished reputation= in the market. A magnetostrictive delay line that was much more reliable re= placed the rotating magnetic memory in the re-worked WS-02 model of the calcu= lator. -Rick --===============5164852973296826912==-- From sellam.ismail@gmail.com Thu Apr 4 00:48:37 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Seeking out Joe Rigdon / John Lawson Date: Wed, 03 Apr 2024 17:48:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1698991857442546601==" --===============1698991857442546601== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Has anyone communicated with or know a way to communicate with Joe Rigdon out of Florida? Most here should know him as an old-school ClassicCmp veteran. If anyone has any information at all on the whereabouts of Joe Rigdon, and for that matter John Lawson, please either reply here or to me privately as appropriate. Thank you. Sellam --===============1698991857442546601==-- From chris@mainecoon.com Thu Apr 4 04:49:11 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Wed, 03 Apr 2024 21:49:04 -0700 Message-ID: <96bcda2f-9cbf-4215-9155-b8ccd0ecccdc@mainecoon.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7628231484319460475==" --===============7628231484319460475== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/3/24 17:48, Sellam Abraham via cctalk wrote: [snip] > If anyone has any information at all on the whereabouts of Joe Rigdon, and > for that matter John Lawson, please either reply here or to me privately as > appropriate. Last contact info I have for John is: 738 Monico Dr. Dayton, NV 89403 775 230 8242 775 241 0546 john(a)nnevllc.com Note that the domain appears to be semi-parked, so I don't know if the address is still good. Cheers, Chris -- 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…" --===============7628231484319460475==-- From paulkoning@comcast.net Thu Apr 4 13:59:52 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Thu, 04 Apr 2024 09:12:38 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1036336691857977034==" --===============1036336691857977034== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 3, 2024, at 6:32 PM, Rick Bensene wrote: >=20 > I wrote: >=20 >>> The digits are among the nicest looking digits that I've ever seen=20 >>> on a CRT display, including those on the CDC scopes as well as IBM >> con= sole displays. >=20 > To which Paul responded: >=20 >> I have, somewhere, a copy of a paper that describes analog circuits > for = generating waveforms for digits along the lines you describe. =20 >> Might have been from MIT, in the 1950s, but right now I can't find > it. >=20 >> Found it (on paper): "Generating characters" by Kenneth Perry and=20 >> Everett Aho, > Electronics, Jan 3, 1958, pp. 72-75. >=20 >> Bitsavers has it in the MIT/LincolnLaboratory section: https://bitsavers= .org/pdf/mit/lincolnLaboratory/Perry_and_Aho__Generating_Characters_-_Electro= nics_19580103.pdf >=20 > Very interesting. Here's a link to the patent for the display system on t= he Wyle Labs calculator: >=20 > https://patentimages.storage.googleapis.com/17/51/58/89c19cee6c60e2/US33058= 43.pdf >=20 > The concepts are very similar to the paper written up in ELECTRONICS magazi= ne in early 1958 that you found. Your memory is incredible to have been able= to have this pop into your mind when you read my description of the way the = calculator generates its display. >=20 > Thank you for looking up this article! It'll provide some nice background= for the concepts of generating characters this way when I finally get to doc= umenting the Wyle WS-01/WS-02 calculators in an Old Calculator Museum exhibit. >=20 > I wonder if the inventor of the display system for the calculator (in fact,= the inventor of the entire Wyle Labs calculator architecture) had read this = article at some point prior? =20 >=20 > I scanned through the patent for the calculator display system looking for = any reference to the article or any document from MIT relating, and I couldn'= t find anything. =20 I didn't see any either, and the patent examiners didn't cite any. Then agai= n, it's amazing how often patent examiners miss relevant prior art. One exam= ple I like to mention is Edwin Armstrong's patent for FM radio, which doesn't= cite an actual earlier US patent, 1,648,402 from 1927, actually filed 12 yea= rs before Armstrong's. Or the prior art centuries preceding US 6469... On the other hand, while the concept is similar the details are rather differ= ent, and the Wyle design is clearly a whole lot simpler. > The inventor is still alive, and I have talked to him on the telephone a co= uple of times. For his advanced age, he is still quite sharp, and remembers= a lot of the challenges involved with trying to make a solid-state electroni= c calculator that would fit on a (large) desktop using early 1960's technolog= y. =20 It would be neat to ask him about that MIT article. paul --===============1036336691857977034==-- From artgodwin@gmail.com Thu Apr 4 14:22:37 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Thu, 04 Apr 2024 15:22:20 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2877563813044926873==" --===============2877563813044926873== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This 'scope clock also uses circle generators rather than vectors to produce well-formed characters. It mentions a Teensy controller so I don't think it's the original made in this way - the first I heard of was too long ago for that. But I don't know if it's an update or a separate design. https://scopeclock.com/ On Thu, Apr 4, 2024 at 2:59=E2=80=AFPM Paul Koning via cctalk wrote: > > > > On Apr 3, 2024, at 6:32 PM, Rick Bensene wrote: > > > > I wrote: > > > >>> The digits are among the nicest looking digits that I've ever seen > >>> on a CRT display, including those on the CDC scopes as well as IBM >> > console displays. > > > > To which Paul responded: > > > >> I have, somewhere, a copy of a paper that describes analog circuits > > for generating waveforms for digits along the lines you describe. > >> Might have been from MIT, in the 1950s, but right now I can't find > it. > > > >> Found it (on paper): "Generating characters" by Kenneth Perry and > >> Everett Aho, > Electronics, Jan 3, 1958, pp. 72-75. > > > >> Bitsavers has it in the MIT/LincolnLaboratory section: > https://bitsavers.org/pdf/mit/lincolnLaboratory/Perry_and_Aho__Generating_C= haracters_-_Electronics_19580103.pdf > > > > Very interesting. Here's a link to the patent for the display system > on the Wyle Labs calculator: > > > > > https://patentimages.storage.googleapis.com/17/51/58/89c19cee6c60e2/US33058= 43.pdf > > > > The concepts are very similar to the paper written up in ELECTRONICS > magazine in early 1958 that you found. Your memory is incredible to have > been able to have this pop into your mind when you read my description of > the way the calculator generates its display. > > > > Thank you for looking up this article! It'll provide some nice > background for the concepts of generating characters this way when I > finally get to documenting the Wyle WS-01/WS-02 calculators in an Old > Calculator Museum exhibit. > > > > I wonder if the inventor of the display system for the calculator (in > fact, the inventor of the entire Wyle Labs calculator architecture) had > read this article at some point prior? > > > > I scanned through the patent for the calculator display system looking > for any reference to the article or any document from MIT relating, and I > couldn't find anything. > > I didn't see any either, and the patent examiners didn't cite any. Then > again, it's amazing how often patent examiners miss relevant prior art. > One example I like to mention is Edwin Armstrong's patent for FM radio, > which doesn't cite an actual earlier US patent, 1,648,402 from 1927, > actually filed 12 years before Armstrong's. Or the prior art centuries > preceding US 6469... > > On the other hand, while the concept is similar the details are rather > different, and the Wyle design is clearly a whole lot simpler. > > > The inventor is still alive, and I have talked to him on the telephone a > couple of times. For his advanced age, he is still quite sharp, and > remembers a lot of the challenges involved with trying to make a > solid-state electronic calculator that would fit on a (large) desktop using > early 1960's technology. > > It would be neat to ask him about that MIT article. > > paul > > --===============2877563813044926873==-- From bill.gunshannon@hotmail.com Thu Apr 4 15:06:42 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 11:05:37 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB573777EB21501CC04FE25F12ED322=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6246850984960173011==" --===============6246850984960173011== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit One more list before I give up. Anybody interested in Iomega drive? I have: 2 - 90 Pro 2 - 150 Multidisk and somewhere here I have a 230M but I haven't come across it yet. To go along with them I have: 4 - 90M Carts 3 - 150M Carts (one labeled Windows NT) 7 - 230M Carts (one labeled RSTS V10) I also have shoe boxes if SIMMS and DIMMS some going back to the Sparc Pizza boxes. I also have piles of IDE drives that range from the days when you had "disk types" for the PC Bios up to GB sizes. Also, CD drives including a bunch of various laptop models. I have piles of other stuff, too, but I am not going to bother listing as I thought the most valuable were the brand new DEC disks and the SB shelves but they apparently aren't worth a thing. bill --===============6246850984960173011==-- From cclist@sydex.com Thu Apr 4 15:36:58 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 08:36:45 -0700 Message-ID: <5ee33b06-8510-4d22-a475-3c6e3a118eb5@sydex.com> In-Reply-To: =?utf-8?q?=3CSA1PR17MB57373857EF2A006091755A16ED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8129930544318071105==" --===============8129930544318071105== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/4/24 08:05, Bill Gunshannon via cctalk wrote: > One more list before I give up. > > Anybody interested in Iomega drive? > > I have: >         2 - 90 Pro >         2 - 150 Multidisk > and somewhere here I have a 230M but I haven't come across it yet. > > To go along with them I have: >         4 - 90M Carts >         3 - 150M Carts  (one labeled Windows NT) >         7 - 230M Carts  (one labeled RSTS V10) > > I also have shoe boxes if SIMMS and DIMMS some going back to > the Sparc Pizza boxes. > Just to be clear, Bill, these are the 5.25" Bernoulli drives, right? --Chuck --===============8129930544318071105==-- From bill.gunshannon@hotmail.com Thu Apr 4 16:28:27 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 12:27:13 -0400 Message-ID: In-Reply-To: <5ee33b06-8510-4d22-a475-3c6e3a118eb5@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8492408277785947851==" --===============8492408277785947851== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/4/2024 11:36 AM, Chuck Guzis via cctalk wrote: > On 4/4/24 08:05, Bill Gunshannon via cctalk wrote: > >> One more list before I give up. >> >> Anybody interested in Iomega drive? >> >> I have: >>         2 - 90 Pro >>         2 - 150 Multidisk >> and somewhere here I have a 230M but I haven't come across it yet. >> >> To go along with them I have: >>         4 - 90M Carts >>         3 - 150M Carts  (one labeled Windows NT) >>         7 - 230M Carts  (one labeled RSTS V10) >> >> I also have shoe boxes if SIMMS and DIMMS some going back to >> the Sparc Pizza boxes. >> > Just to be clear, Bill, these are the 5.25" Bernoulli drives, right? > Was there any other kind? Oh yeah, I also have one marketed for use on the Mac. It says 88M on the front. bill --===============8492408277785947851==-- From cclist@sydex.com Thu Apr 4 16:48:12 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 09:47:53 -0700 Message-ID: <7773be00-994f-4963-ac0e-d49089ac59a2@sydex.com> In-Reply-To: =?utf-8?q?=3CSA1PR17MB57373D51B8ACD1B0AE61B50BED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2547627071785551138==" --===============2547627071785551138== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/4/24 09:27, Bill Gunshannon via cctalk wrote: > > Was there any other kind? > > Oh yeah, I also have one marketed for use on the Mac.  It says 88M > on the front. Zip, Jaz....all Iomega. The Zips were 100MB, 250MB and 750MB. The Jaz was 1 GB and 2 GB, if memory serves. The 88M sounds like a SyQuest drive--very popular in the 90s with the Mac crowd. Pretty much unknown in the PC world. 44M 88M and 200M, after which SyQuest went toes-up. Chuck --===============2547627071785551138==-- From sqrfolkdnc@comcast.net Thu Apr 4 16:55:01 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 11:54:54 -0500 Message-ID: <1823879511.1358028.1712249694757@connect.xfinity.com> In-Reply-To: <7773be00-994f-4963-ac0e-d49089ac59a2@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4898822701182272019==" --===============4898822701182272019== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable my syquests say 135 mb, though IIRC that must be raw, because useable was a m= ore even number, like 125mb, which the formatting program agreed with. I mad= e it my c: drive on my I386 pc so I could switch operating systems before vi= rtualization. I was pissed that though os/2 said it would install on 125 MB,= it actually meant OVER 125 MB and would not install. 
--Carey
> On 04/04/2024 11:47 AM CDT Chuck Guzis via cctalk = wrote: >=20 > =20 > On 4/4/24 09:27, Bill Gunshannon via cctalk wrote: > >=20 >=20 > > Was there any other kind? > >=20 > > Oh yeah, I also have one marketed for use on the Mac.=C2=A0 It says 88M > > on the front. >=20 > Zip, Jaz....all Iomega. The Zips were 100MB, 250MB and 750MB. The Jaz > was 1 GB and 2 GB, if memory serves. >=20 > The 88M sounds like a SyQuest drive--very popular in the 90s with the > Mac crowd. Pretty much unknown in the PC world. 44M 88M and 200M, > after which SyQuest went toes-up. >=20 > Chuck --===============4898822701182272019==-- From bill.gunshannon@hotmail.com Thu Apr 4 16:55:45 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 12:55:26 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB57373857EF2A006091755A16ED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8021706816267708535==" --===============8021706816267708535== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/4/2024 11:05 AM, Bill Gunshannon via cctalk wrote: > > > > One more list before I give up. > > Anybody interested in Iomega drive? > > I have: >         2 - 90 Pro >         2 - 150 Multidisk > and somewhere here I have a 230M but I haven't come across it yet. > > To go along with them I have: >         4 - 90M Carts >         3 - 150M Carts  (one labeled Windows NT) >         7 - 230M Carts  (one labeled RSTS V10) > > I also have shoe boxes if SIMMS and DIMMS some going back to > the Sparc Pizza boxes. > > > I also have piles of IDE drives that range from the days when you > had "disk types" for the PC Bios up to GB sizes.  Also, CD drives > including a bunch of various laptop models. > > I have piles of other stuff, too, but I am not going to bother > listing as I thought the most valuable were the brand new DEC > disks and the SB shelves but they apparently aren't worth a thing. > Found the 230 drive. Actually two of them. And both in external boxes. bill --===============8021706816267708535==-- From bill.gunshannon@hotmail.com Thu Apr 4 17:20:28 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 13:20:09 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737A617E20114C1E9F1E845ED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7475251924304319494==" --===============7475251924304319494== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Not really sure I want to get rid of them yet, but what do Apple II's go for nowadays? I have an Apple II with 2 Disk II's and a language card. I also have an Apple IIe with three external disk cards and 2 3.5" drives and 3 5.25" drives. It also has a Microsoft Soft Card for running CP/M. And I have the docs and disks. bill --===============7475251924304319494==-- From cclist@sydex.com Thu Apr 4 17:25:19 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 10:25:09 -0700 Message-ID: In-Reply-To: <1823879511.1358028.1712249694757@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4023732499957377405==" --===============4023732499957377405== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/4/24 09:54, CAREY SCHUG wrote: > my syquests say 135 mb, though IIRC that must be raw, because useable was a= more even number, like 125mb, which the formatting program agreed with. I m= ade it my c: drive on my I386 pc so I could switch operating systems before = virtualization. I was pissed that though os/2 said it would install on 125 M= B, it actually meant OVER 125 MB and would not install. > The EZ 135 was yet a different format, succeeded by the EZ Flyer 230 MB. Lower-priced versions of the cartridge drives I mentioned--and utterly incompatible. Then there was the ill-fated 1GB SyQest SparQ drive, available, AFAIK, only in parallel printer port version (a big mistake). I still have one in original bubble-pack. I don't know if I ever bothered to see if it works. It was pretty clear at that time that SyQuest was in a losing position. --Chuck --===============4023732499957377405==-- From billdegnan@gmail.com Thu Apr 4 17:53:13 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 13:52:55 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737C20CFF8584A9046412DDED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8453208056197261143==" --===============8453208056197261143== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Apple II's go for a lot. The iie a lot less. Compare the original cbm Pet with later Pets Bill On Thu, Apr 4, 2024, 1:20 PM Bill Gunshannon via cctalk < cctalk(a)classiccmp.org> wrote: > > > > Not really sure I want to get rid of them yet, but what do Apple II's > go for nowadays? I have an Apple II with 2 Disk II's and a language > card. I also have an Apple IIe with three external disk cards and > 2 3.5" drives and 3 5.25" drives. It also has a Microsoft Soft Card > for running CP/M. And I have the docs and disks. > > bill > --===============8453208056197261143==-- From wayne.sudol@hotmail.com Thu Apr 4 18:36:08 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 18:36:02 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0187569752481606326==" --===============0187569752481606326== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What were the brand new DEC disks? Sent from my iPhone > On Apr 4, 2024, at 10:53, Bill Degnan via cctalk = wrote: >=20 > =EF=BB=BFApple II's go for a lot. The iie a lot less. Compare the origina= l cbm Pet > with later Pets > Bill >=20 >> On Thu, Apr 4, 2024, 1:20 PM Bill Gunshannon via cctalk < >> cctalk(a)classiccmp.org> wrote: >>=20 >>=20 >>=20 >>=20 >> Not really sure I want to get rid of them yet, but what do Apple II's >> go for nowadays? I have an Apple II with 2 Disk II's and a language >> card. I also have an Apple IIe with three external disk cards and >> 2 3.5" drives and 3 5.25" drives. It also has a Microsoft Soft Card >> for running CP/M. And I have the docs and disks. >>=20 >> bill >>=20 --===============0187569752481606326==-- From healyzh@avanthar.com Thu Apr 4 18:40:14 2024 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 11:39:57 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB57373857EF2A006091755A16ED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4122990892067131701==" --===============4122990892067131701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 4, 2024, at 8:05 AM, Bill Gunshannon via cctalk wrote: >=20 > 7 - 230M Carts (one labeled RSTS V10) Is the RSTS/E disk something that needs to be preserved? Zane --===============4122990892067131701==-- From bhilpert@shaw.ca Thu Apr 4 19:12:25 2024 From: Brent Hilpert To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Thu, 04 Apr 2024 12:12:18 -0700 Message-ID: <2106BE82-C4A4-49BB-B923-7FAA52906933@shaw.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5164079258406357657==" --===============5164079258406357657== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 2024Apr 4,, at 7:22 AM, Adrian Godwin via cctalk wrote: >=20 > This 'scope clock also uses circle generators rather than vectors to > produce well-formed characters. It mentions a Teensy controller so I don't > think it's the original made in this way - the first I heard of was too > long ago for that. But I don't know if it's an update or a separate design. > https://scopeclock.com/ Technically, the scopeClock is generating neither curves nor vectors, it's ge= nerating pixels in an XY display - it's just that they=E2=80=99re of fine eno= ugh resolution and fast enough that they=E2=80=99re seen as a smooth-enough c= urve on the CRT. The MIT/Electronics-magazine and Wyle techniques are using analog electronics= to generate portions of sine waves for selected phase periods and phase rela= tion such that when applied to the XY cartesian display you get continuous po= rtions (chords) of circles. Some digital logic gates the analog sine generato= rs appropriately to produce the chords and line segments, with offsets, in a = sequence to form characters. The scopeClock, in contrast, is using DACs in the microcontroller to generate= (discrete approximations of) sine wave segments - which is to say it=E2=80= =99s relying on the abilities of inexpensive current-day high-speed digital e= lectronics. Thanks Paul, for pulling up the article, I recalled it as well when Rick ment= ioned the technique of the Wyle. I think I ran across it many years ago when= sorting through stacks of Electronics magazines at our radio museum. --===============5164079258406357657==-- From bill.gunshannon@hotmail.com Thu Apr 4 19:13:54 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 15:13:36 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4723886795876131776==" --===============4723886795876131776== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/4/2024 2:39 PM, Zane Healy wrote: > > >> On Apr 4, 2024, at 8:05 AM, Bill Gunshannon via cctalk >> wrote: >> >>  7 - 230M Carts  (one labeled RSTS V10) > > Is the RSTS/E disk something that needs to be preserved? > Not by me. And I created it. Not sure if it was from an 11/44, 11/73 or 11/23 but it dates back to when Mentec gave me a license to run PDP-11 OSes at the University. As a matter of fact, I see where I still have the TK50 and 9-track install tapes. bill --===============4723886795876131776==-- From wayne.sudol@hotmail.com Thu Apr 4 19:18:16 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 19:18:09 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB57377CEF20A0CA05B16E49E7ED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0104407958730383607==" --===============0104407958730383607== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Bill. I would be interested in the rz28 drives. They would work on my Alph= a. I live in the Los Angeles area though so i would need shipping.=20 Sent from my iPhone > On Apr 4, 2024, at 12:14, Bill Gunshannon via cctalk wrote: >=20 > =EF=BB=BF >=20 > On 4/4/2024 2:39 PM, Zane Healy wrote: >>>> On Apr 4, 2024, at 8:05 AM, Bill Gunshannon via cctalk wrote: >>>=20 >>> 7 - 230M Carts (one labeled RSTS V10) >> Is the RSTS/E disk something that needs to be preserved? >=20 > Not by me. And I created it. Not sure if it was from an 11/44, > 11/73 or 11/23 but it dates back to when Mentec gave me a license > to run PDP-11 OSes at the University. As a matter of fact, I see > where I still have the TK50 and 9-track install tapes. >=20 > bill >=20 >=20 >=20 --===============0104407958730383607==-- From sellam.ismail@gmail.com Thu Apr 4 19:19:06 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Thu, 04 Apr 2024 12:18:48 -0700 Message-ID: In-Reply-To: <96bcda2f-9cbf-4215-9155-b8ccd0ecccdc@mainecoon.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6080452499802207952==" --===============6080452499802207952== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Chris. It's been quite a while. Those are the numbers I have for John last as well. He stopped responding to me over 10 years ago but I'm not sure if that was because he was tired of me or just tired (I was going through a phase myself and pissed off some friends inadvertently). But around that time for a couple years I would periodically reach out via text and maybe a phone call but he never responded. So I'm not sure if he passed or not because he wasn't in the greatest health but he lost a bunch of weight the last time I saw him and was looking pretty good. But that was 10 years ago and he wasn't that young then. However, I find no obituaries, but then there's no guarantee he didn't move somewhere else in the meantime. Anyway, I hope you've been well. Sellam On Wed, Apr 3, 2024 at 9:49 PM Christian Kennedy via cctalk < cctalk(a)classiccmp.org> wrote: > > On 4/3/24 17:48, Sellam Abraham via cctalk wrote: > > [snip] > > If anyone has any information at all on the whereabouts of Joe Rigdon, > and > > for that matter John Lawson, please either reply here or to me privately > as > > appropriate. > > Last contact info I have for John is: > > 738 Monico Dr. > Dayton, NV 89403 > 775 230 8242 > 775 241 0546 > john(a)nnevllc.com > > Note that the domain appears to be semi-parked, so I don't know if the > address is still good. > > Cheers, > > Chris > > -- > 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…" > > --===============6080452499802207952==-- From paulkoning@comcast.net Thu Apr 4 19:35:59 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Thu, 04 Apr 2024 15:35:30 -0400 Message-ID: In-Reply-To: <2106BE82-C4A4-49BB-B923-7FAA52906933@shaw.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1520699404857789640==" --===============1520699404857789640== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 4, 2024, at 3:12 PM, Brent Hilpert via cctalk wrote: >=20 >> On 2024Apr 4,, at 7:22 AM, Adrian Godwin via cctalk wrote: >>=20 >> This 'scope clock also uses circle generators rather than vectors to >> produce well-formed characters. It mentions a Teensy controller so I don't >> think it's the original made in this way - the first I heard of was too >> long ago for that. But I don't know if it's an update or a separate design. >=20 >> https://scopeclock.com/ > Technically, the scopeClock is generating neither curves nor vectors, it's = generating pixels in an XY display - it's just that they=E2=80=99re of fine e= nough resolution and fast enough that they=E2=80=99re seen as a smooth-enough= curve on the CRT. >=20 > The MIT/Electronics-magazine and Wyle techniques are using analog electroni= cs to generate portions of sine waves for selected phase periods and phase re= lation such that when applied to the XY cartesian display you get continuous = portions (chords) of circles. Some digital logic gates the analog sine genera= tors appropriately to produce the chords and line segments, with offsets, in = a sequence to form characters. >=20 > The scopeClock, in contrast, is using DACs in the microcontroller to genera= te (discrete approximations of) sine wave segments - which is to say it=E2=80= =99s relying on the abilities of inexpensive current-day high-speed digital e= lectronics. That is similar to what the CDC 6612 controller for the DD60 console display = does. So given that you're sending the resulting step waveform through a def= lection circuit with finite bandwidth, you do in fact end up with a continuou= s vector with rounded features. How nicely rounded depends on the bandwidth = and the number and size of the steps. For example, the DD60 display doesn't = look all that elegant, but it is definitely well rounded, simply because the = step clock is 10 MHz and the deflection chain bandwidth isn't a whole lot mor= e than that. So the fact that you're dealing with what originally was a step= waveform with just 7 positions for X and Y isn't at all obvious in the final= image. paul --===============1520699404857789640==-- From healyzh@avanthar.com Thu Apr 4 19:39:51 2024 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Thu, 04 Apr 2024 12:39:34 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0823023084403673707==" --===============0823023084403673707== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Apr 3, 2024, at 5:48 PM, Sellam Abraham via cctalk wrote: >=20 > Has anyone communicated with or know a way to communicate with Joe Rigdon > out of Florida? Most here should know him as an old-school ClassicCmp > veteran. >=20 > If anyone has any information at all on the whereabouts of Joe Rigdon, and > for that matter John Lawson, please either reply here or to me privately as > appropriate. >=20 > Thank you. >=20 > Sellam According to the archives I have on my computer, John Lawson announced here o= n June 15th, 2005 that he was leaving the hobby. It looks like Joe was last on the list in November 2006, at that time he was = still using the rr.com email address. Sadly I don=E2=80=99t know how to reach either of them. Eric Smith apparentl= y had Joe=E2=80=99s phone number in 2011, I don=E2=80=99t know if he spoke to= him at that time. Zane --===============0823023084403673707==-- From sellam.ismail@gmail.com Thu Apr 4 19:46:37 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Thu, 04 Apr 2024 12:46:21 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7473337156678497684==" --===============7473337156678497684== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 4, 2024 at 12:39=E2=80=AFPM Zane Healy w= rote: > On Apr 3, 2024, at 5:48 PM, Sellam Abraham via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > Has anyone communicated with or know a way to communicate with Joe Rigdon > > out of Florida? Most here should know him as an old-school ClassicCmp > > veteran. > > > > If anyone has any information at all on the whereabouts of Joe Rigdon, > and > > for that matter John Lawson, please either reply here or to me privately > as > > appropriate. > > > > Thank you. > > > > Sellam > > > According to the archives I have on my computer, John Lawson announced > here on June 15th, 2005 that he was leaving the hobby. > > It looks like Joe was last on the list in November 2006, at that time he > was still using the rr.com email address. > > Sadly I don=E2=80=99t know how to reach either of them. Eric Smith apparen= tly had > Joe=E2=80=99s phone number in 2011, I don=E2=80=99t know if he spoke to him= at that time. > > Zane > The mystery deepens. I was in touch with John Lawson up until around 2013-2014 when he stopped responding to my calls/texts/emails (which could have been for several reasons). I only thought of Joe recently out of the blue and thought I'd see if he was still around. Jay West (in the ClassicCmp Discord server) said he was friends with Joe and hosted his website and used to communicate with him regularly but then stopped hearing from him at some point, and as of 5 years ago he and others made a concerted effort to locate him to no avail. So this is a last ditch effort on my own part to find them before I figure it's time for eulogies. Sellam --===============7473337156678497684==-- From sellam.ismail@gmail.com Thu Apr 4 19:50:10 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 12:49:53 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737C20CFF8584A9046412DDED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5930102230782224165==" --===============5930102230782224165== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Apr 4, 2024 at 10:20 AM Bill Gunshannon via cctalk < cctalk(a)classiccmp.org> wrote: > > Not really sure I want to get rid of them yet, but what do Apple II's > go for nowadays? I have an Apple II with 2 Disk II's and a language > card. I also have an Apple IIe with three external disk cards and > 2 3.5" drives and 3 5.25" drives. It also has a Microsoft Soft Card > for running CP/M. And I have the docs and disks. > > bill > It depends on the model. Typically an Apple ][ of any model sells for $100-$250, depending on accessories and configuration. Unless you have a straight Apple ][ (and not Plus, as I'm assuming), what you describe sounds like a $250-$300 ][+ system, and $400-$450 for the //e. Give or take eBay markup. Sellam --===============5930102230782224165==-- From chris@mainecoon.com Thu Apr 4 19:52:34 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Thu, 04 Apr 2024 12:52:27 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5070261670671026544==" --===============5070261670671026544== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Sellam, On 4/4/24 12:18, Sellam Abraham via cctalk wrote: > It's been quite a while. Too long.  Life happened. > So I'm not sure if he passed or not because he wasn't in the > greatest health but he lost a bunch of weight the last time I saw him and > was looking pretty good. But that was 10 years ago and he wasn't that > young then. However, I find no obituaries, but then there's no guarantee > he didn't move somewhere else in the meantime. I visited him in Dayton sometime in the first half of 2017, and he seemed quite alive and kicking then.  He seemed to be moving back into radio as his time-and-resource sink at the time. I have a couple of other leads to chase up.  I'll let the list know if I learn anything. Cheers, Chris -- 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…" --===============5070261670671026544==-- From healyzh@avanthar.com Thu Apr 4 19:58:56 2024 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Thu, 04 Apr 2024 12:58:41 -0700 Message-ID: <91E796BE-F1A5-468B-9A0C-E34FAEF11CB3@avanthar.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3602022863246144727==" --===============3602022863246144727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 4, 2024, at 12:46 PM, Sellam Abraham wro= te: >=20 > The mystery deepens. >=20 > I was in touch with John Lawson up until around 2013-2014 when he stopped r= esponding to my calls/texts/emails (which could have been for several reasons= ). >=20 > I only thought of Joe recently out of the blue and thought I'd see if he wa= s still around. Jay West (in the ClassicCmp Discord server) said he was frie= nds with Joe and hosted his website and used to communicate with him regularl= y but then stopped hearing from him at some point, and as of 5 years ago he a= nd others made a concerted effort to locate him to no avail. >=20 > So this is a last ditch effort on my own part to find them before I figure = it's time for eulogies. >=20 > Sellam=20 Have you checked with Eric Smith or Dave McGuire? I want to say that Dave wa= s in the same general area as Joe when he lived in Florida. Other people I=E2=80=99d love to know how their doing would be James Willing,= Allison Parent, and Megan Gentry. Zane --===============3602022863246144727==-- From artgodwin@gmail.com Thu Apr 4 20:21:30 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Thu, 04 Apr 2024 21:21:14 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0488761534075074392==" --===============0488761534075074392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 4, 2024 at 8:36=E2=80=AFPM Paul Koning via cctalk wrote: > > > >> https://scopeclock.com/ > > Technically, the scopeClock is generating neither curves nor vectors, > it's generating pixels in an XY display - it's just that they=E2=80=99re of= fine > enough resolution and fast enough that they=E2=80=99re seen as a smooth-eno= ugh > curve on the CRT. > > > > That's disappointing. There was such a clock, and I thought I'd found it since it described using circle generators - but was surprised to find it used a teensy. Does anyone know which clock used analog circuits to form the characters ? --===============0488761534075074392==-- From uban@ubanproductions.com Thu Apr 4 20:33:16 2024 From: Tom Uban To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Thu, 04 Apr 2024 15:33:11 -0500 Message-ID: <86f62d44-1765-4ed5-810a-328d97b93644@ubanproductions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2756886209520898083==" --===============2756886209520898083== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This one: https://scopeclock.com/ You can see the connected arcs in the pic on the main page. I built an older model years ago and it is still running... --tom On 4/4/24 15:21, Adrian Godwin via cctalk wrote: > On Thu, Apr 4, 2024 at 8:36=E2=80=AFPM Paul Koning via cctalk > wrote: > >>>> https://scopeclock.com/ >>> Technically, the scopeClock is generating neither curves nor vectors, >> it's generating pixels in an XY display - it's just that they=E2=80=99re o= f fine >> enough resolution and fast enough that they=E2=80=99re seen as a smooth-en= ough >> curve on the CRT. >> > That's disappointing. There was such a clock, and I thought I'd found it > since it described using circle generators - but was surprised to find it > used a teensy. > Does anyone know which clock used analog circuits to form the characters ? --===============2756886209520898083==-- From bill.gunshannon@hotmail.com Thu Apr 4 21:25:26 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 17:25:05 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5167424503415350712==" --===============5167424503415350712== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/4/2024 3:49 PM, Sellam Abraham via cctalk wrote: > On Thu, Apr 4, 2024 at 10:20 AM Bill Gunshannon via cctalk < > cctalk(a)classiccmp.org> wrote: > >> >> Not really sure I want to get rid of them yet, but what do Apple II's >> go for nowadays? I have an Apple II with 2 Disk II's and a language >> card. I also have an Apple IIe with three external disk cards and >> 2 3.5" drives and 3 5.25" drives. It also has a Microsoft Soft Card >> for running CP/M. And I have the docs and disks. >> >> bill >> > > It depends on the model. Typically an Apple ][ of any model sells for > $100-$250, depending on accessories and configuration. Unless you have a > straight Apple ][ (and not Plus, as I'm assuming), what you describe sounds > like a $250-$300 ][+ system, and $400-$450 for the //e. Give or take eBay > markup. > Well, The SoftCard and the Language Card (why did they call it that?) both go for $100 a piece. The one is a IIe, not a \\e. There are some on eBay now for more than $2000. I wouldn't expect that but I do find it interesting that all the stuff I have is worthless unless someone else is selling it. :-) bill --===============5167424503415350712==-- From sellam.ismail@gmail.com Thu Apr 4 21:47:59 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 14:47:43 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB57375FE1AB1AD63CD4013D3EED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0472994849460162833==" --===============0472994849460162833== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Apr 4, 2024 at 2:25 PM Bill Gunshannon via cctalk < cctalk(a)classiccmp.org> wrote: > > > It depends on the model. Typically an Apple ][ of any model sells for > > $100-$250, depending on accessories and configuration. Unless you have a > > straight Apple ][ (and not Plus, as I'm assuming), what you describe > sounds > > like a $250-$300 ][+ system, and $400-$450 for the //e. Give or take > eBay > > markup. > > > > Well, The SoftCard and the Language Card (why did they call it that?) > both go for $100 a piece. The one is a IIe, not a \\e. There are > some on eBay now for more than $2000. I wouldn't expect that but I > do find it interesting that all the stuff I have is worthless unless > someone else is selling it. :-) > That's not how it works but it sounds like you got it figured out. Sellam --===============0472994849460162833==-- From cisin@xenosoft.com Thu Apr 4 21:54:51 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 04 Apr 2024 14:54:46 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB57375FE1AB1AD63CD4013D3EED3C2=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2082468662596495998==" --===============2082468662596495998== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 4 Apr 2024, Bill Gunshannon via cctalk wrote: > Well, The SoftCard and the Language Card (why did they call it that?) > both go for $100 a piece. The one is a IIe, not a \\e. Was that "IIe", "][e", or "//e"? > There are > some on eBay now for more than $2000. I wouldn't expect that but I > do find it interesting that all the stuff I have is worthless unless > someone else is selling it. :-) Speculation: The "Language Card" could be populated with a fancy BASIC (what Kurtz and Kemeny called "street BASIC"), OR COULD BE, at least in theory, populated with other languages, hence the name "Language Card". I am not aware of any successful examples of it ever being populated with anything other than BASIC. The "Soft Card" was Microsoft's first significant venture into hardware. It was incredibly successful, and Microsoft's largest revenue source in 1980. At one point, somebody at Apple said that 20% of AppleII owners had one. "The SoftCard was Paul Allen's idea.[5] Its original purpose was to simplify porting Microsoft's computer-language products to the Apple II.[6] The SoftCard was developed by Tim Paterson of Seattle Computer Products (SCP). SCP built prototypes,[7] Don Burtis of Burtronix redesigned the card, and California Computer Systems manufactured it for Microsoft.[8] Unsure whether the card would sell, Microsoft first demonstrated it publicly at the West Coast Computer Faire in March 1980.[2][" - Wikipedia It had a Z80, and a copy of CP/M. I suspect that the name "Soft Card" might be due to its intent to open the Apple to CP/M SOFTware, particularly software that Micorsoft had originally written in 8080/Z80. There were rumors that an IBM person had one in a personal Apple, and that that caused IBM, when they went to Microsoft for BASIC, to assume that they could get CP/M (CP/M-86) through Microsoft. When Microsoft sent them to DRI for CP/M, IBM and DRI had a "culture clash" and IBM went back to Microsoft (long story, with some disagreements about details) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============2082468662596495998==-- From kevin.bowling@kev009.com Fri Apr 5 02:17:59 2024 From: Kevin Bowling To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Thu, 04 Apr 2024 19:17:41 -0700 Message-ID: In-Reply-To: <28F73077-4F60-472B-9440-9D87DDA401D4@eschatologist.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5367578800645412897==" --===============5367578800645412897== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable eBay prices have gotten silly. Sellers seem a lot more willing to sit on items for years hoping they get 4-5x what something should sell for rather than moving volume these days. It's odd psychology when you know a lot of it just gets scrapped eventually when it never sells. There is an ebay seller 'biff-howard-tanen' that has some C200s up right now. All their items have "Make an Offer'' and they tend to be fairly reasonable as long as you account for the free shipping they offer. I've had mostly good luck with buying from them, and they made right the couple oops. Regards, Kevin On Sun, Mar 24, 2024 at 5:17=E2=80=AFPM Chris Hanson via cctalk wrote: > > I just looked at the prices on eBay=E2=80=94yikes! All of my HP hardware fr= om that era was pretty inexpensive a few years back. > > What are people using the B180L for that=E2=80=99s driven the prices so hig= h? I assume it=E2=80=99s another =E2=80=9Cthere=E2=80=99s a piece of equipmen= t that was built around this specific platform 20+ years ago, and we=E2=80=99= re still running it so we need spares=E2=80=9D situation, just like the equip= ment that was built around the VAXstation 4000 Model 90 which keeps the price= on that insane. > > Is there a specific need you=E2=80=99re trying to fill? I wound up with an = additional B- or C-series workstation as part of a deal, I can check what mod= el it is (it=E2=80=99s in storage right now) and we can talk off-list about m= aybe getting it to a good home. (I=E2=80=99m in the SF Bay Area if that helps= , no idea where you are.) > > -- Chris > > PS - There=E2=80=99s a Vintage HP Computers group at https://groups.io/g/Vi= ntHPcom/ where you=E2=80=99ll also find lots of folks talking about the entir= e range of HP computer hardware. > --===============5367578800645412897==-- From cmhanson@eschatologist.net Fri Apr 5 03:26:05 2024 From: Chris Hanson To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Thu, 04 Apr 2024 20:06:47 -0700 Message-ID: <3632DEB9-7DA5-41EF-8DC9-A3AB1839FA5F@eschatologist.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8046149309804692011==" --===============8046149309804692011== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Apr 4, 2024, at 7:17=E2=80=AFPM, Kevin Bowling wrote: >=20 > There is an ebay seller 'biff-howard-tanen' that has some C200s up > right now. All their items have "Make an Offer'' and they tend to be > fairly reasonable as long as you account for the free shipping they > offer. I've had mostly good luck with buying from them, and they made > right the couple oops. I can vouch for them as a seller in the same way, I've also gotten reasonable= prices from them when making offers that account for shipping, and the selle= r actually knows how to pack stuff. Same with eBay seller jonnyadler, though = their list price for a C180 is, let's say, "optimistic.") -- Chris --===============8046149309804692011==-- From mattislind@gmail.com Fri Apr 5 07:23:22 2024 From: Mattis Lind To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Fri, 05 Apr 2024 09:23:04 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6847408091735896868==" --===============6847408091735896868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > > > > >> Found it (on paper): "Generating characters" by Kenneth Perry and > >> Everett Aho, > Electronics, Jan 3, 1958, pp. 72-75. > > > >> Bitsavers has it in the MIT/LincolnLaboratory section: > https://bitsavers.org/pdf/mit/lincolnLaboratory/Perry_and_Aho__Generating_C= haracters_-_Electronics_19580103.pdf > > > > Very interesting. Here's a link to the patent for the display system > on the Wyle Labs calculator: > > > > > https://patentimages.storage.googleapis.com/17/51/58/89c19cee6c60e2/US33058= 43.pdf > > > > The concepts are very similar to the paper written up in ELECTRONICS > magazine in early 1958 that you found. Your memory is incredible to have > been able to have this pop into your mind when you read my description of > the way the calculator generates its display. > > > > DEC made the KV8/I option ( http://www.bitsavers.org/pdf/dec/pdp8/pdp8i/DEC-8I-H6MA-D_KV_Graphic_Display_= System_Maint_Apr70.pdf) for the PDP-8/I and PDP-8/L. It had a analog function generator which could draw vectors and circles. The board is A312 and is a Dual module. My board look like this: https://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/Axxx/A312/A312Efro= nt.jpg THE KV8 was made for connecting to storage displays like the Tek 611 / VT01 and not displays that need continuous updates. --===============6847408091735896868==-- From ard.p850ug1@gmail.com Fri Apr 5 12:34:00 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Fri, 05 Apr 2024 13:33:44 +0100 Message-ID: In-Reply-To: <91E796BE-F1A5-468B-9A0C-E34FAEF11CB3@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2727719488557110659==" --===============2727719488557110659== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 4, 2024 at 8:58=E2=80=AFPM Zane Healy via cctalk wrote: > Have you checked with Eric Smith or Dave McGuire? I want to say that Dave = was in the same general area as Joe when he lived in Florida. I've asked Wlodek Mier-J of the British HPCC calculator club if he has any contact details. -tony --===============2727719488557110659==-- From ard.p850ug1@gmail.com Fri Apr 5 14:58:39 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Fri, 05 Apr 2024 15:58:23 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4114758420326513889==" --===============4114758420326513889== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2024 at 1:33=E2=80=AFPM Tony Duell w= rote: > > On Thu, Apr 4, 2024 at 8:58=E2=80=AFPM Zane Healy via cctalk > wrote: > > > Have you checked with Eric Smith or Dave McGuire? I want to say that Dav= e was in the same general area as Joe when he lived in Florida. > > I've asked Wlodek Mier-J of the British HPCC calculator club if he has > any contact details. Unfortunately Wlodek has been unable to contact Joe Rigdon as well. -tony --===============4114758420326513889==-- From keith@techtravels.org Fri Apr 5 15:34:00 2024 From: Keith Monahan To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Fri, 05 Apr 2024 11:33:52 -0400 Message-ID: <23d16ca4-a105-440e-bdc2-9c9cc129ea6d@techtravels.org> In-Reply-To: <3632DEB9-7DA5-41EF-8DC9-A3AB1839FA5F@eschatologist.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5590048873292265275==" --===============5590048873292265275== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks guys for pointing out what's available and the references....=20 which will be useful the next time something good comes around! The C200 runs the newer 64-bit processor, the PA8200, which is RISC 2.0,=20 and (I'd imagine is) quite a bit different than the PA7300. I don't understand the silly pricing either. Who's buying them? Who is=20 forking over $1000, $1500, etc for these old machines? I don't really=20 even buy the "some business relies on this and have never updated"=20 because you'd have to have some smart folks on standby who could=20 reinstall software, reconfigure machines with licenses, etc. Assuming=20 you still had the necessary CDs etc. Keith On 4/4/2024 11:06 PM, Chris Hanson via cctalk wrote: > On Apr 4, 2024, at 7:17=E2=80=AFPM, Kevin Bowling wrote: >> >> There is an ebay seller 'biff-howard-tanen' that has some C200s up >> right now. All their items have "Make an Offer'' and they tend to be >> fairly reasonable as long as you account for the free shipping they >> offer. I've had mostly good luck with buying from them, and they made >> right the couple oops. >=20 > I can vouch for them as a seller in the same way, I've also gotten reasonab= le prices from them when making offers that account for shipping, and the sel= ler actually knows how to pack stuff. Same with eBay seller jonnyadler, thoug= h their list price for a C180 is, let's say, "optimistic.") >=20 > -- Chris --===============5590048873292265275==-- From kevin.bowling@kev009.com Fri Apr 5 17:10:34 2024 From: Kevin Bowling To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Fri, 05 Apr 2024 10:10:15 -0700 Message-ID: In-Reply-To: <23d16ca4-a105-440e-bdc2-9c9cc129ea6d@techtravels.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1964968658595906454==" --===============1964968658595906454== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2024 at 8:33=E2=80=AFAM Keith Monahan wrote: > > Thanks guys for pointing out what's available and the references.... > which will be useful the next time something good comes around! > > The C200 runs the newer 64-bit processor, the PA8200, which is RISC 2.0, > and (I'd imagine is) quite a bit different than the PA7300. You can still run a 32b OS or 32b applications depending on your preference on the C200. PA-RISC is a well designed superset of its prior ISA versions. I re-read your post and it seems you want chipset compatibility though, in which case yes you'd want to find a LASI system like the C160L/C180L if going to C-class. Here is a good candidate: https://www.ebay.com/itm/195201664655 > I don't understand the silly pricing either. Who's buying them? Who is > forking over $1000, $1500, etc for these old machines? I don't really > even buy the "some business relies on this and have never updated" > because you'd have to have some smart folks on standby who could > reinstall software, reconfigure machines with licenses, etc. Assuming > you still had the necessary CDs etc. I think there is a small subset of PA-RISC machines that are used as controllers for ABB PLCs, maybe other types of industrial and lab equipment. It might not be a big deal to spend $1200 to maintain something like that and not have to understand how to make it run on other types of systems. The sellers then extrapolate that to everything is worth its weight in gold. > > Keith > > > On 4/4/2024 11:06 PM, Chris Hanson via cctalk wrote: > > On Apr 4, 2024, at 7:17=E2=80=AFPM, Kevin Bowling wrote: > >> > >> There is an ebay seller 'biff-howard-tanen' that has some C200s up > >> right now. All their items have "Make an Offer'' and they tend to be > >> fairly reasonable as long as you account for the free shipping they > >> offer. I've had mostly good luck with buying from them, and they made > >> right the couple oops. > > > > I can vouch for them as a seller in the same way, I've also gotten reason= able prices from them when making offers that account for shipping, and the s= eller actually knows how to pack stuff. Same with eBay seller jonnyadler, tho= ugh their list price for a C180 is, let's say, "optimistic.") > > > > -- Chris --===============1964968658595906454==-- From keith@techtravels.org Fri Apr 5 19:29:22 2024 From: Keith Monahan To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Fri, 05 Apr 2024 15:29:16 -0400 Message-ID: <6e8dffeb-64f0-4c25-b0b8-e6866620c831@techtravels.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4134905766231981316==" --===============4134905766231981316== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kevin, Thanks..... but isn't there a big risk with that item that it doesn't=20 work at all, given the "for parts" designation? I suppose I can email=20 and ask if it POSTS... Thanks On 4/5/2024 1:10 PM, Kevin Bowling via cctalk wrote: > On Fri, Apr 5, 2024 at 8:33=E2=80=AFAM Keith Monahan wrote: >> >> Thanks guys for pointing out what's available and the references.... >> which will be useful the next time something good comes around! >> >> The C200 runs the newer 64-bit processor, the PA8200, which is RISC 2.0, >> and (I'd imagine is) quite a bit different than the PA7300. >=20 > You can still run a 32b OS or 32b applications depending on your > preference on the C200. PA-RISC is a well designed superset of its > prior ISA versions. I re-read your post and it seems you want chipset > compatibility though, in which case yes you'd want to find a LASI > system like the C160L/C180L if going to C-class. Here is a good > candidate: https://www.ebay.com/itm/195201664655 >=20 >> I don't understand the silly pricing either. Who's buying them? Who is >> forking over $1000, $1500, etc for these old machines? I don't really >> even buy the "some business relies on this and have never updated" >> because you'd have to have some smart folks on standby who could >> reinstall software, reconfigure machines with licenses, etc. Assuming >> you still had the necessary CDs etc. >=20 > I think there is a small subset of PA-RISC machines that are used as > controllers for ABB PLCs, maybe other types of industrial and lab > equipment. It might not be a big deal to spend $1200 to maintain > something like that and not have to understand how to make it run on > other types of systems. The sellers then extrapolate that to > everything is worth its weight in gold. >=20 >> >> Keith >> >> >> On 4/4/2024 11:06 PM, Chris Hanson via cctalk wrote: >>> On Apr 4, 2024, at 7:17=E2=80=AFPM, Kevin Bowling wrote: >>>> >>>> There is an ebay seller 'biff-howard-tanen' that has some C200s up >>>> right now. All their items have "Make an Offer'' and they tend to be >>>> fairly reasonable as long as you account for the free shipping they >>>> offer. I've had mostly good luck with buying from them, and they made >>>> right the couple oops. >>> >>> I can vouch for them as a seller in the same way, I've also gotten reason= able prices from them when making offers that account for shipping, and the s= eller actually knows how to pack stuff. Same with eBay seller jonnyadler, tho= ugh their list price for a C180 is, let's say, "optimistic.") >>> >>> -- Chris --===============4134905766231981316==-- From van.snyder@sbcglobal.net Fri Apr 5 20:45:33 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 13:45:26 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7074156082411714247==" --===============7074156082411714247== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have a Dell Vostro. When I boot, the screen briefly flashes and then remains dark. I have another one on which the screen would stay lit for a minute or two, then go black. If I closed the lid and opened it, it would stay lit for a few more minutes, then go black again. I corrected that by replacing the backlight power supply. In this one, is the problem more likely a defective power supply for the backlight, or a defective backlight, or something else? Thanks, Van Snyder --===============7074156082411714247==-- From sellam.ismail@gmail.com Fri Apr 5 21:40:57 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Fri, 05 Apr 2024 14:40:41 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6571515810078335655==" --===============6571515810078335655== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Apr 4, 2024 at 7:18 PM Kevin Bowling via cctalk < cctalk(a)classiccmp.org> wrote: > > There is an ebay seller 'biff-howard-tanen' that has some C200s up > right now. All their items have "Make an Offer'' and they tend to be > fairly reasonable as long as you account for the free shipping they > offer. I've had mostly good luck with buying from them, and they made > right the couple oops. > > Regards, > Kevin > I can also vouch for "Biff". I've transacted with him before (traded an IMSAI 8080 for an Alpha Syntauri system he had listed on eBay...I proposed the trade and he was kind enough to go with it, so I know he will work with you). FWIW we are also "Facebook Friends" and he's known in the computer collecting circles there. A very great guy. He runs an e-waste processing facility in the midwest. Sellam --===============6571515810078335655==-- From sellam.ismail@gmail.com Fri Apr 5 21:41:29 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 14:41:13 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8933759538706958696==" --===============8933759538706958696== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Um... On Fri, Apr 5, 2024 at 1:45=E2=80=AFPM Van Snyder via cctalk wrote: > I have a Dell Vostro. > > When I boot, the screen briefly flashes and then remains dark. > > I have another one on which the screen would stay lit for a minute or > two, then go black. If I closed the lid and opened it, it would stay > lit for a few more minutes, then go black again. I corrected that by > replacing the backlight power supply. > > In this one, is the problem more likely a defective power supply for > the backlight, or a defective backlight, or something else? > > > Thanks, > Van Snyder > > --===============8933759538706958696==-- From rickb@bensene.com Fri Apr 5 22:25:42 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 22:25:31 +0000 Message-ID: <9e6c3d7e1be04e3a849dd7daa74f29de@bensene.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4322473450954879470==" --===============4322473450954879470== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Apr 5, 2024 at 1:45 PM Van Snyder via cctalk wrote: > I have a Dell Vostro. Sellam responded: >Um... ...Yeah. --===============4322473450954879470==-- From billdegnan@gmail.com Fri Apr 5 23:01:06 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 19:00:45 -0400 Message-ID: In-Reply-To: <9e6c3d7e1be04e3a849dd7daa74f29de@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5945794164473554939==" --===============5945794164473554939== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit That's not quite on topic here but I used to own one. Just close the lid and walk away slowly. On Fri, Apr 5, 2024, 6:25 PM Rick Bensene via cctalk wrote: > > > > On Fri, Apr 5, 2024 at 1:45 PM Van Snyder via cctalk > wrote: > > > I have a Dell Vostro. > > Sellam responded: > > >Um... > > ...Yeah. > --===============5945794164473554939==-- From van.snyder@sbcglobal.net Fri Apr 5 23:47:25 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 16:47:17 -0700 Message-ID: In-Reply-To: <9e6c3d7e1be04e3a849dd7daa74f29de@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7129577104139283336==" --===============7129577104139283336== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 2024-04-05 at 22:25 +0000, Rick Bensene via cctalk wrote: > > > On Fri, Apr 5, 2024 at 1:45 PM Van Snyder via cctalk > wrote: > > > I have a Dell Vostro. > > Sellam responded: > > > Um... > > ...Yeah. Both extremely helpful. Thanks. --===============7129577104139283336==-- From billdegnan@gmail.com Sat Apr 6 00:42:14 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 20:41:57 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7594153747910809553==" --===============7594153747910809553== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I find them to be painfully slow Actually I think it got a lot better once I installed debian in it. Sorry you're having issues. B On Fri, Apr 5, 2024, 7:47 PM Van Snyder via cctalk wrote: > On Fri, 2024-04-05 at 22:25 +0000, Rick Bensene via cctalk wrote: > > > > > > On Fri, Apr 5, 2024 at 1:45 PM Van Snyder via cctalk > > wrote: > > > > > I have a Dell Vostro. > > > > Sellam responded: > > > > > Um... > > > > ...Yeah. > > Both extremely helpful. Thanks. > --===============7594153747910809553==-- From jwsmail@jwsss.com Sat Apr 6 01:22:32 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Fri, 05 Apr 2024 20:22:20 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0192246829012143063==" --===============0192246829012143063== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I did run a hackintosh on one very long ago.  IIRC it was a core I 2 not very bright bulb. That's not on topic either, but worth knowing. thanks Jim On 4/5/24 19:41, Bill Degnan via cctalk wrote: > I find them to be painfully slow > Actually I think it got a lot better once I installed debian in it. > Sorry you're having issues. > B > > On Fri, Apr 5, 2024, 7:47 PM Van Snyder via cctalk > wrote: > >> On Fri, 2024-04-05 at 22:25 +0000, Rick Bensene via cctalk wrote: >>> >>> On Fri, Apr 5, 2024 at 1:45 PM Van Snyder via cctalk >>> wrote: >>> >>>> I have a Dell Vostro. >>> Sellam responded: >>> >>>> Um... >>> ...Yeah. >> Both extremely helpful. Thanks. >> --===============0192246829012143063==-- From kevin.bowling@kev009.com Sat Apr 6 06:08:31 2024 From: Kevin Bowling To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for an HP 9000/778 workstation B160/180 Date: Fri, 05 Apr 2024 23:08:15 -0700 Message-ID: In-Reply-To: <6e8dffeb-64f0-4c25-b0b8-e6866620c831@techtravels.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0574784496324145416==" --===============0574784496324145416== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2024 at 12:29=E2=80=AFPM Keith Monahan wrote: > > Kevin, > > Thanks..... but isn't there a big risk with that item that it doesn't > work at all, given the "for parts" designation? I suppose I can email > and ask if it POSTS... Depends what your risk tolerance is and how much you enjoy fixing things. I'd go for it if I were in the market because these things are pretty chonky and the parts are not too rare. The C class has three modules that promote easy swapping.. the PSU, drive bay, and motherboard all come out very easy. I wouldn't expect much from random ebay sellers, but a few pictures of the LED light bar after a few minutes of power on the front may be within their scope and could let you know if you have a functional PSU. > Thanks > > > On 4/5/2024 1:10 PM, Kevin Bowling via cctalk wrote: > > On Fri, Apr 5, 2024 at 8:33=E2=80=AFAM Keith Monahan wrote: > >> > >> Thanks guys for pointing out what's available and the references.... > >> which will be useful the next time something good comes around! > >> > >> The C200 runs the newer 64-bit processor, the PA8200, which is RISC 2.0, > >> and (I'd imagine is) quite a bit different than the PA7300. > > > > You can still run a 32b OS or 32b applications depending on your > > preference on the C200. PA-RISC is a well designed superset of its > > prior ISA versions. I re-read your post and it seems you want chipset > > compatibility though, in which case yes you'd want to find a LASI > > system like the C160L/C180L if going to C-class. Here is a good > > candidate: https://www.ebay.com/itm/195201664655 > > > >> I don't understand the silly pricing either. Who's buying them? Who is > >> forking over $1000, $1500, etc for these old machines? I don't really > >> even buy the "some business relies on this and have never updated" > >> because you'd have to have some smart folks on standby who could > >> reinstall software, reconfigure machines with licenses, etc. Assuming > >> you still had the necessary CDs etc. > > > > I think there is a small subset of PA-RISC machines that are used as > > controllers for ABB PLCs, maybe other types of industrial and lab > > equipment. It might not be a big deal to spend $1200 to maintain > > something like that and not have to understand how to make it run on > > other types of systems. The sellers then extrapolate that to > > everything is worth its weight in gold. > > > >> > >> Keith > >> > >> > >> On 4/4/2024 11:06 PM, Chris Hanson via cctalk wrote: > >>> On Apr 4, 2024, at 7:17=E2=80=AFPM, Kevin Bowling wrote: > >>>> > >>>> There is an ebay seller 'biff-howard-tanen' that has some C200s up > >>>> right now. All their items have "Make an Offer'' and they tend to be > >>>> fairly reasonable as long as you account for the free shipping they > >>>> offer. I've had mostly good luck with buying from them, and they made > >>>> right the couple oops. > >>> > >>> I can vouch for them as a seller in the same way, I've also gotten reas= onable prices from them when making offers that account for shipping, and the= seller actually knows how to pack stuff. Same with eBay seller jonnyadler, t= hough their list price for a C180 is, let's say, "optimistic.") > >>> > >>> -- Chris --===============0574784496324145416==-- From mike_t_norris@hotmail.com Sat Apr 6 10:11:15 2024 From: Mike Norris To: cctalk@classiccmp.org Subject: [cctalk] Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 06 Apr 2024 10:11:08 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1550581419032265608==" --===============1550581419032265608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Before I consign the following books to be recycled I thought I would ask if = they are any use to anyone. I do not want anything for them except postage, but they are heavy so might b= e expensive to post from the UK. (These are the manuals only no software) Manuals Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, Debu= gger, DOS Ref, Library Ref Borland C++V2 Object Windows - Reference Guide, Programmers Guide Turbo C++ V3 Object Windows - User Guide, Reference Guide Turbo C++ V3 User Guide Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide Resource Workshop Turbo Assembler V2 (5 books in set) Turbo Basic Books The Waite Group Turbo C Bible Developing C++ Software Additional I would like =C2=A35 beer money for this one please! Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubowicz Regards Mike Norris --===============1550581419032265608==-- From dj.taylor4@comcast.net Sat Apr 6 14:54:05 2024 From: Douglas Taylor To: cctalk@classiccmp.org Subject: [cctalk] DEC VT340/330 ROM Cartridge Date: Sat, 06 Apr 2024 10:53:51 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3949901417943991839==" --===============3949901417943991839== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The DEC VT340 has a slot in the back of the terminal to insert a ROM cartridge.  I can't find any description of what this DEC labeled ROM cartridge would do for you.  I've seen them with V1.1 and V2.1 markings, does anyone remember what additional capabilities these ROM cartridge provide? Doug --===============3949901417943991839==-- From healyzh@avanthar.com Sat Apr 6 15:13:16 2024 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 06 Apr 2024 08:13:00 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CPAWPR02MB980665D237EFC218A5AB8A64AA022=40PAWPR02MB?= =?utf-8?q?9806=2Eeurprd02=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3119644702501284642==" --===============3119644702501284642== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I suspect that at least the Turbo BASIC and TASM manuals should be saved. Th= e only Turbo BASIC that I ever saw in the 80=E2=80=99s is the copy that I bou= ght. I=E2=80=99m not sure how useful the OpenVMS book is, but it is also somewhat = uncommon. I recently got a copy with some other books that I bought. Zane=20 Sent from my iPhone > On Apr 6, 2024, at 3:11=E2=80=AFAM, Mike Norris via cctalk wrote: >=20 > =EF=BB=BFHello, >=20 > Before I consign the following books to be recycled I thought I would ask i= f they are any use to anyone. > I do not want anything for them except postage, but they are heavy so might= be expensive to post from the UK. > (These are the manuals only no software) >=20 > Manuals > Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, De= bugger, DOS Ref, Library Ref > Borland C++V2 Object Windows - Reference Guide, Programmers Guide > Turbo C++ V3 Object Windows - User Guide, Reference Guide > Turbo C++ V3 User Guide > Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide > Resource Workshop > Turbo Assembler V2 (5 books in set) > Turbo Basic >=20 > Books > The Waite Group Turbo C Bible > Developing C++ Software >=20 > Additional > I would like =C2=A35 beer money for this one please! > Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubow= icz >=20 >=20 > Regards Mike Norris --===============3119644702501284642==-- From ard.p850ug1@gmail.com Sat Apr 6 15:14:54 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: DEC VT340/330 ROM Cartridge Date: Sat, 06 Apr 2024 16:14:37 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3757252999209463986==" --===============3757252999209463986== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Apr 6, 2024 at 3:54 PM Douglas Taylor via cctalk wrote: > > The DEC VT340 has a slot in the back of the terminal to insert a ROM > cartridge. I can't find any description of what this DEC labeled ROM > cartridge would do for you. I've seen them with V1.1 and V2.1 markings, > does anyone remember what additional capabilities these ROM cartridge > provide? Will the terminal work at all without that cartridge fitted?. I've had a quick look at the VT330 and VT340 printsets and I can't obviously spot any firmware ROMs on the main board schematics. So my first guess is that said cartridge is the terminal firmware. -tony --===============3757252999209463986==-- From dj.taylor4@comcast.net Sat Apr 6 15:26:38 2024 From: Douglas Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: DEC VT340/330 ROM Cartridge Date: Sat, 06 Apr 2024 11:26:25 -0400 Message-ID: <60105b98-8292-4a6b-99c9-594ddec6d47f@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3915404614719589021==" --===============3915404614719589021== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/6/2024 11:14 AM, Tony Duell via cctalk wrote: > On Sat, Apr 6, 2024 at 3:54 PM Douglas Taylor via cctalk > wrote: >> The DEC VT340 has a slot in the back of the terminal to insert a ROM >> cartridge. I can't find any description of what this DEC labeled ROM >> cartridge would do for you. I've seen them with V1.1 and V2.1 markings, >> does anyone remember what additional capabilities these ROM cartridge >> provide? > Will the terminal work at all without that cartridge fitted?. I've had > a quick look at the VT330 and VT340 printsets and I can't obviously > spot any firmware ROMs on the main board schematics. So my first guess > is that said cartridge is the terminal firmware. > > -tony Hmm, I have a VT340 that seems to pass POST but no video.  It does have a cartridge inserted into the slot, you may be exactly correct. Doug --===============3915404614719589021==-- From tarek@infocom.ai Sat Apr 6 15:30:50 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 06 Apr 2024 08:24:58 -0700 Message-ID: <1552009F-D242-4C08-92B8-C2B5F6332677@infocom.ai> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5611274770905137050==" --===============5611274770905137050== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I double that. Turbo Basic and TASM manuals should be saved, especially the T= urbo BASIC one.=20 If Zane doesn=E2=80=99t want it, I would pay for shipping Turbo BASIC to 9867= 1 zip code in the US.=20 Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675 https://tarek.computer INFOCOM AI LLC - https://infocom.ai > On Apr 6, 2024, at 08:13, Zane Healy via cctalk w= rote: >=20 > =EF=BB=BFI suspect that at least the Turbo BASIC and TASM manuals should be= saved. The only Turbo BASIC that I ever saw in the 80=E2=80=99s is the copy= that I bought. >=20 > I=E2=80=99m not sure how useful the OpenVMS book is, but it is also somewha= t uncommon. I recently got a copy with some other books that I bought. >=20 > Zane >=20 >=20 > Sent from my iPhone >=20 >> On Apr 6, 2024, at 3:11=E2=80=AFAM, Mike Norris via cctalk wrote: >>=20 >> =EF=BB=BFHello, >>=20 >> Before I consign the following books to be recycled I thought I would ask = if they are any use to anyone. >> I do not want anything for them except postage, but they are heavy so migh= t be expensive to post from the UK. >> (These are the manuals only no software) >>=20 >> Manuals >> Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, D= ebugger, DOS Ref, Library Ref >> Borland C++V2 Object Windows - Reference Guide, Programmers Guide >> Turbo C++ V3 Object Windows - User Guide, Reference Guide >> Turbo C++ V3 User Guide >> Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide >> Resource Workshop >> Turbo Assembler V2 (5 books in set) >> Turbo Basic >>=20 >> Books >> The Waite Group Turbo C Bible >> Developing C++ Software >>=20 >> Additional >> I would like =C2=A35 beer money for this one please! >> Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubo= wicz >>=20 >>=20 >> Regards Mike Norris >=20 --===============5611274770905137050==-- From tarek@infocom.ai Sat Apr 6 15:30:58 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 06 Apr 2024 08:30:20 -0700 Message-ID: <4C717189-8D0F-46DB-8AF9-1DA29F635C38@infocom.ai> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5755266333455260821==" --===============5755266333455260821== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I double that. Turbo Basic and TASM manuals should be saved, especially the T= urbo BASIC one.=20 If Zane doesn=E2=80=99t want it, I would pay for shipping Turbo BASIC to 9867= 1 zip code in the US. Regards, Tarek Hoteit > On Apr 6, 2024, at 08:13, Zane Healy via cctalk w= rote: >=20 > =EF=BB=BFI suspect that at least the Turbo BASIC and TASM manuals should be= saved. The only Turbo BASIC that I ever saw in the 80=E2=80=99s is the copy= that I bought. >=20 > I=E2=80=99m not sure how useful the OpenVMS book is, but it is also somewha= t uncommon. I recently got a copy with some other books that I bought. >=20 > Zane >=20 >=20 > Sent from my iPhone >=20 >> On Apr 6, 2024, at 3:11=E2=80=AFAM, Mike Norris via cctalk wrote: >>=20 >> =EF=BB=BFHello, >>=20 >> Before I consign the following books to be recycled I thought I would ask = if they are any use to anyone. >> I do not want anything for them except postage, but they are heavy so migh= t be expensive to post from the UK. >> (These are the manuals only no software) >>=20 >> Manuals >> Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, D= ebugger, DOS Ref, Library Ref >> Borland C++V2 Object Windows - Reference Guide, Programmers Guide >> Turbo C++ V3 Object Windows - User Guide, Reference Guide >> Turbo C++ V3 User Guide >> Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide >> Resource Workshop >> Turbo Assembler V2 (5 books in set) >> Turbo Basic >>=20 >> Books >> The Waite Group Turbo C Bible >> Developing C++ Software >>=20 >> Additional >> I would like =C2=A35 beer money for this one please! >> Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubo= wicz >>=20 >>=20 >> Regards Mike Norris >=20 --===============5755266333455260821==-- From mike_t_norris@hotmail.com Sat Apr 6 15:37:49 2024 From: Mike Norris To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 06 Apr 2024 15:37:43 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CPAWPR02MB980665D237EFC218A5AB8A64AA022=40PAWPR02MB?= =?utf-8?q?9806=2Eeurprd02=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1794673610758424472==" --===============1794673610758424472== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Guys, Julian managed to get in save the Turbo Assembler and Turbo Basic books, he i= s not far away so is calling to collect tomorrow. The following are still available:- Manuals Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, Debu= gger, DOS Ref, Library Ref Borland C++V2 Object Windows - Reference Guide, Programmers Guide Turbo C++ V3 Object Windows - User Guide, Reference Guide Turbo C++ V3 User Guide Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide Resource Workshop Books The Waite Group Turbo C Bible Developing C++ Software Additional I would like =C2=A35 beer money for this one please! Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubowicz Regards Mike Norris ________________________________ From: Mike Norris via cctalk Sent: 06 April 2024 11:11 To: cctalk(a)classiccmp.org Cc: Mike Norris Subject: [cctalk] Borland Turbo C++ and Turbo Basic - Books and Manuals Hello, Before I consign the following books to be recycled I thought I would ask if = they are any use to anyone. I do not want anything for them except postage, but they are heavy so might b= e expensive to post from the UK. (These are the manuals only no software) Manuals Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, Debu= gger, DOS Ref, Library Ref Borland C++V2 Object Windows - Reference Guide, Programmers Guide Turbo C++ V3 Object Windows - User Guide, Reference Guide Turbo C++ V3 User Guide Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide Resource Workshop Turbo Assembler V2 (5 books in set) Turbo Basic Books The Waite Group Turbo C Bible Developing C++ Software Additional I would like =C2=A35 beer money for this one please! Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubowicz Regards Mike Norris --===============1794673610758424472==-- From cube1@charter.net Sat Apr 6 15:52:35 2024 From: Jay Jaeger To: cctalk@classiccmp.org Subject: [cctalk] Re: WTB: PSU for DEC PDP8F Date: Sat, 06 Apr 2024 10:52:31 -0500 Message-ID: <099fbfbf-55ae-4f37-88a7-83af77e79a1f@charter.net> In-Reply-To: <0edaf55f95c8b3352f63fe69dffdbb10@tuberadio.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3389506083122630071==" --===============3389506083122630071== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 1/12/2024 12:02 AM, Raymond Robinson via cctalk wrote: > Hi there, > > I need a power supply for my PDP8F computer. > It is missing. > > The PDP8F 19" chassis box came in 3 different depths, > 600 mm (PSU front to back) > 370 mm (PSU across the back) > 300 mm (PSU front to back) > > I need the shallow one, the 300 mm PSU front to back. > Do you have one available, or know where I can get one please. > Even if it is dead! > > regards > ray Did you ever find one?  If not, let me know - I *may* have one. (Madison, WI, US) JRJ --===============3389506083122630071==-- From geneb@deltasoft.com Sun Apr 7 00:27:34 2024 From: geneb To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 06 Apr 2024 17:21:05 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CPAWPR02MB980665D237EFC218A5AB8A64AA022=40PAWPR02MB?= =?utf-8?q?9806=2Eeurprd02=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9120705556871379577==" --===============9120705556871379577== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 6 Apr 2024, Mike Norris via cctalk wrote: > Hello, > > Before I consign the following books to be recycled I thought I would ask i= f they are any use to anyone. > I do not want anything for them except postage, but they are heavy so might= be expensive to post from the UK. > (These are the manuals only no software) > > Manuals > Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, De= bugger, DOS Ref, Library Ref > Borland C++V2 Object Windows - Reference Guide, Programmers Guide > Turbo C++ V3 Object Windows - User Guide, Reference Guide > Turbo C++ V3 User Guide > Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide > Resource Workshop > Turbo Assembler V2 (5 books in set) > Turbo Basic > > Books > The Waite Group Turbo C Bible > Developing C++ Software > If you were only in the US. :( I'd buy you *two* beers. ;) g. --=20 Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_! --===============9120705556871379577==-- From doug@doughq.com Sun Apr 7 01:09:10 2024 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sun, 07 Apr 2024 10:59:30 +1000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3691459570157419837==" --===============3691459570157419837== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Having paid personally for a Borland C++ compiler in the Windows 95 days, I can confirm that the set of books can comfortably elevate a monitor by about 14" when used as a monitor stand. On Sun, 7 Apr 2024, 10:27 am geneb via cctalk, wrote: > On Sat, 6 Apr 2024, Mike Norris via cctalk wrote: > > > Hello, > > > > Before I consign the following books to be recycled I thought I would > ask if they are any use to anyone. > > I do not want anything for them except postage, but they are heavy so > might be expensive to post from the UK. > > (These are the manuals only no software) > > > > Manuals > > Borland C++ V4 for Windows - Programmers Guide, User Guide, Library Ref, > Debugger, DOS Ref, Library Ref > > Borland C++V2 Object Windows - Reference Guide, Programmers Guide > > Turbo C++ V3 Object Windows - User Guide, Reference Guide > > Turbo C++ V3 User Guide > > Turbo C++ - Library Ref, Getting Started, Programmers Guide, User Guide > > Resource Workshop > > Turbo Assembler V2 (5 books in set) > > Turbo Basic > > > > Books > > The Waite Group Turbo C Bible > > Developing C++ Software > > > > If you were only in the US. :( I'd buy you *two* beers. ;) > > 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_! > --===============3691459570157419837==-- From kantexplain@protonmail.com Sun Apr 7 04:29:18 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] cheap boards for 16/32 bit apps Date: Sun, 07 Apr 2024 04:29:03 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5434568695685931241==" --===============5434568695685931241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ifo you absolutely must run something old, yet don't want to deal with the co= mplexities of modern emulation: https://www.ebay.com/itm/191322319264 - drivers, whatever is needed, likely to be included on floppy. Ask seller. N= ot sure what tbe form factor it is. Who cares, nail it to a board or the wall. https://www.ebay.com/itm/283869740055 - obviously a lot faster. 2nd cpu isn't necessary or necessarily beneficial, = but it is mandatory (says me, don't be a plebe). Unlike the Intel S5000 serie= s serverboards, this bad boy has a FLOPPY connector. Should boot dos. But I h= aven't owned 1 yet. Can't remember if I even tried to boot my s5000vsadimmr4 = or whatever I had from a dos loaded boot cd. Just can't. But my board did boo= t Windows 2000. Not too shabby. No drivers or i/o plate with this though. Dri= vers for Win2k are on tne net. I even foumd a manual I think. Check with me i= f you have need. The Intel boards have support for Win2008. NOT this board af= aik. If that matters to you. Serverboards of this gen/chipset have steemy hot ram. You can nail this to the wall also. But have a desk fan to keep it all cool. --===============5434568695685931241==-- From phil@ultimate.com Sun Apr 7 07:21:34 2024 From: Phil Budne To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Sat, 06 Apr 2024 11:40:35 -0400 Message-ID: <202404061540.436FeZRI072159@ultimate.com> In-Reply-To: <77DD9D60-2331-4FCC-9B45-9FDEBF2560DC@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5525428738391012139==" --===============5525428738391012139== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul Koning wrote: > Yes, and some emulations have done this, such as Phil Budne's famous work i= n SIMH. Famous?? I'm famous???!!! To be fair, I started with Douglas W. Jones' PDP8 Emulator. Which reminds me of: If I have seen farther than others, it is because I was standing on the s= houlders of giants. -- Isaac Newton In the sciences, we are now uniquely privileged to sit side by side with = the giants on whose shoulders we stand. -- Gerald Holton If I have not seen as far as others, it is because giants were standing o= n my shoulders. -- Hal Abelson In computer science, we stand on each other's feet. -- Brian K. Reid It was certainly an awakening to the inherent parallelism of "analog" natural processes... I wrote and tuned the code twenty years ago, but haven't looked at whether better results might be possible by wasting the capabilities of current systems (SIMD libaries and/or multiple cores). I felt like I only was able to give a slim impression, and not an immersive experience. I've also wondered what could be done with 4K HDR displays: making points round(!) and simulating the "bloom" and intensity of repeatedly or highly intensified spots. phil --===============5525428738391012139==-- From lars@nocrew.org Sun Apr 7 08:33:38 2024 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Sun, 07 Apr 2024 08:18:14 +0000 Message-ID: <7w34rxegc9.fsf@junk.nocrew.org> In-Reply-To: <202404061540.436FeZRI072159@ultimate.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7633845222757065610==" --===============7633845222757065610== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Phil Budne wrote: > I wrote and tuned the code twenty years ago, but haven't looked at > whether better results might be possible by wasting the capabilities > of current systems (SIMD libaries and/or multiple cores). I felt like > I only was able to give a slim impression, and I've also wondered what > could be done with 4K HDR displays: making points round(!) and > simulating the "bloom" and intensity of repeatedly or highly > intensified spots. I have done some experiments in this direction. There are two sample pictures here which are supposed to look similar to a P7 CRT. https://github.com/larsbrinkhoff/crt-simulation --===============7633845222757065610==-- From ccth6600@gmail.com Sun Apr 7 08:48:03 2024 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Sun, 07 Apr 2024 16:47:46 +0800 Message-ID: In-Reply-To: <7w34rxegc9.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3310223665493777120==" --===============3310223665493777120== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I too have experimented with OpenGL to simulate phosphor-decay. I never got to a satisfactory solution. The learning curve for OpenGL is steep. On Sun, Apr 7, 2024 at 4:43 PM Lars Brinkhoff via cctalk < cctalk(a)classiccmp.org> wrote: > Phil Budne wrote: > > I wrote and tuned the code twenty years ago, but haven't looked at > > whether better results might be possible by wasting the capabilities > > of current systems (SIMD libaries and/or multiple cores). I felt like > > I only was able to give a slim impression, and I've also wondered what > > could be done with 4K HDR displays: making points round(!) and > > simulating the "bloom" and intensity of repeatedly or highly > > intensified spots. > > I have done some experiments in this direction. There are two sample > pictures here which are supposed to look similar to a P7 CRT. > > https://github.com/larsbrinkhoff/crt-simulation > --===============3310223665493777120==-- From mjd.bishop@emeritus-solutions.com Sun Apr 7 09:58:58 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Sun, 07 Apr 2024 09:58:09 +0000 Message-ID: In-Reply-To: <77DD9D60-2331-4FCC-9B45-9FDEBF2560DC@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4906040940300165246==" --===============4906040940300165246== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A little digging later ... I implemented the waterfall display eight years a= go, outputing to a 1280 x 1024 monitor. 1920 x 1080 was supported, but I was= outputing 1 Ki pt FFTs. The hardware platform was a Xilinx Zynq. An indication of 4k video capabilities is https://xilinx-wiki.atlassian.net/w= iki/spaces/A/pages/2611216385/Zynq+UltraScale+MPSoC+VCU+TRD+2023.1 Note the = higher octane hardware used. Martin -----Original Message----- From: Paul Koning [mailto:paulkoning(a)comcast.net]=20 Sent: 03 April 2024 18:38 << snip >> > Equally, FPGAs / SOCs can implement frame buffers; eg to output waterfall d= isplays. The fading memory would have to be in DRAM, FPGA memory is fast but= small 3 ns access time but only 240 ki by .. 2.18 Mi by (Zynq 10 .. 45, the = '45 is a corporate purchase). A ping pong buffer arrangement could implement= fading - computed in either processor (vector instructions) or logic (raw m= uscle). The DAC input lines could supply the data. Agreed, and that would be an elegant way to emulate a CDC DD60. Or a GT40. = You'd presumably want to use at least an HD level display signal (1920 by 108= 0), if not double that, to make it look right; less than that would give pixe= l artefacts that make it not look as vector-like as you would want. paul --===============4906040940300165246==-- From chris@groessler.org Sun Apr 7 12:23:27 2024 From: Christian Groessler To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sun, 07 Apr 2024 13:57:19 +0200 Message-ID: In-Reply-To: =?utf-8?q?=3CPAWPR02MB980684FD59A6F10D6948F3C3AA022=40PAWPR02MB?= =?utf-8?q?9806=2Eeurprd02=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8204463128277393828==" --===============8204463128277393828== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/6/24 5:37 PM, Mike Norris via cctalk wrote: > Additional > I would like =C2=A35 beer money for this one please! > Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubow= icz I'd take it. I can send you beer money, or could send you 2 or 3 bottles of local=20 beer. I'm living near Munich, Germany. Sending beer will likely be quite more expensive than 5 pounds, but has=20 a fun factor bonus :-) regards, chris --===============8204463128277393828==-- From lproven@gmail.com Sun Apr 7 12:57:56 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Sun, 07 Apr 2024 13:57:39 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3338441849890945438==" --===============3338441849890945438== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 6 Apr 2024 at 00:47, Van Snyder via cctalk wrote: > > Both extremely helpful. Thanks. This is mainly a list for pre-PC era kit. Windows PCs and 64-bit x86 kit are offtopic here, and most members, I suspect, regard them as disposable office equipment with no more personality than a stapler. The Vostro 1700 looks to be a 2007 era 17" C2D laptop. Not much info to go on in your message. You say it boots; how do you know? What OS? Latest firmware? Can you SSH to it when the OS comes up? Can it successfully drive an external screen? Have you opened it up and checked its CPU and GPU fans are clean, unobstructed, spin and it's not overheating? -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============3338441849890945438==-- From paulkoning@comcast.net Sun Apr 7 17:51:36 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Sun, 07 Apr 2024 13:51:28 -0400 Message-ID: In-Reply-To: <202404061540.436FeZRI072159@ultimate.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1728907737280912140==" --===============1728907737280912140== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 6, 2024, at 11:40 AM, Phil Budne via cctalk wrote: >=20 > Paul Koning wrote: >=20 >> Yes, and some emulations have done this, such as Phil Budne's famous work = in SIMH. >=20 > Famous?? I'm famous???!!! >=20 > To be fair, I started with Douglas W. Jones' PDP8 Emulator. >=20 > Which reminds me of: >=20 > If I have seen farther than others, it is because I was standing on the = shoulders of giants. -- Isaac Newton >=20 > In the sciences, we are now uniquely privileged to sit side by side with= the giants on whose shoulders we stand. -- Gerald Holton >=20 > If I have not seen as far as others, it is because giants were standing = on my shoulders. -- Hal Abelson >=20 > In computer science, we stand on each other's feet. -- Brian K. Reid Well said, indeed! > It was certainly an awakening to the inherent parallelism of "analog" > natural processes... I wrote and tuned the code twenty years ago, but > haven't looked at whether better results might be possible by wasting > the capabilities of current systems (SIMD libaries and/or multiple > cores). I felt like I only was able to give a slim impression, and > not an immersive experience. I've also wondered what could be done > with 4K HDR displays: making points round(!) and simulating the > "bloom" and intensity of repeatedly or highly intensified spots. I did these things, in an emulation of the CDC 6600 console (DD60). It paint= s the "dot" on the screen using a 2D Gaussian distribution around the nominal= center, with its parameters adjusted by the "focus" and "intensity" controls= just like on the original. And each visit of the spot is summed into the cu= rrent screen data using saturated arithmetic. So you get intensification at = no extra charge, and if a spot is drawn many times it also gets a bit blurrie= r due to the skirts of the Gaussian distribution becoming more visible. At o= ne point I had the spot as an RGB value with a touch of blue in it, so the "b= loom" would be bluer than normal lines. I took that out because I don't reme= mber what the real screen actually does. But clearly a color shift like that= could be simulated. paul --===============1728907737280912140==-- From bfranchuk@jetnet.ab.ca Sun Apr 7 18:01:27 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: oscilloscopes Date: Sun, 07 Apr 2024 12:01:15 -0600 Message-ID: <61099efa-4b0e-4980-97fa-12cd64acf208@jetnet.ab.ca> In-Reply-To: <202404061540.436FeZRI072159@ultimate.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1671819633805347569==" --===============1671819633805347569== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-06 9:40 a.m., Phil Budne via cctalk wrote: > Paul Koning wrote: >=20 >> Yes, and some emulations have done this, such as Phil Budne's famous work = in SIMH. >=20 > Famous?? I'm famous???!!! >=20 > To be fair, I started with Douglas W. Jones' PDP8 Emulator. >=20 > Which reminds me of: >=20 > If I have seen farther than others, it is because I was standing on th= e shoulders of giants. -- Isaac Newton >=20 > In the sciences, we are now uniquely privileged to sit side by side wi= th the giants on whose shoulders we stand. -- Gerald Holton >=20 > If I have not seen as far as others, it is because giants were standin= g on my shoulders. -- Hal Abelson >=20 > In computer science, we stand on each other's feet. -- Brian K. Reid >=20 > It was certainly an awakening to the inherent parallelism of "analog" > natural processes... I wrote and tuned the code twenty years ago, but > haven't looked at whether better results might be possible by wasting > the capabilities of current systems (SIMD libaries and/or multiple > cores). I felt like I only was able to give a slim impression, and > not an immersive experience. I've also wondered what could be done > with 4K HDR displays: making points round(!) and simulating the > "bloom" and intensity of repeatedly or highly intensified spots. >=20 > phil I need to write a emulator for a new cpu design I have. The 1086 cpu,=20 nice 20 bit cpu design from about 1968 using more modern parts. The=20 problem is the modern parts are just too fast and I have timing issues. I can read/ write from memory using the front panel but not run code for some reason. Jumps seem to work but HALT does not. This requires a whole new bunch of PCB's with test points and other bug fixes, and I=20 have few weeks waiting for more parts. I figure 90% of the code will be planning simple IO for this beast and=20 10% the emulator itself. I like real hardware that you can put a scope too. All I can say modern programming is a about using a GUI and very little about console IO. This is a bit change from using a PDP-8 with=20 TTY, and 4K focal. --===============1671819633805347569==-- From bfranchuk@jetnet.ab.ca Sun Apr 7 18:05:44 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sun, 07 Apr 2024 12:05:32 -0600 Message-ID: <550d8f4e-319b-4e9b-b00b-09a20e824581@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3948749867737180616==" --===============3948749867737180616== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-07 5:57 a.m., Christian Groessler via cctalk wrote: > On 4/6/24 5:37 PM, Mike Norris via cctalk wrote: >> Additional >> I would like £5 beer money for this one please! >> Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard >> Szubowicz > > > I'd take it. > > I can send you beer money, or could send you 2 or 3 bottles of local > beer. I'm living near Munich, Germany. > > Sending beer will likely be quite more expensive than 5 pounds, but has > a fun factor bonus :-) > > regards, > chris > I don't think bottles would be ship able. Now a keg of beer might be. Or a least the old oak kegs you read in stories. Ben. --===============3948749867737180616==-- From van.snyder@sbcglobal.net Sun Apr 7 19:43:21 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Sun, 07 Apr 2024 12:43:09 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6565506830620046309==" --===============6565506830620046309== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 2024-04-07 at 13:57 +0100, Liam Proven via cctalk wrote: > On Sat, 6 Apr 2024 at 00:47, Van Snyder via cctalk< > cctalk(a)classiccmp.org> wrote: > > Both extremely helpful. Thanks. > > This is mainly a list for pre-PC era kit. Windows PCs and 64-bit > x86kit are offtopic here, and most members, I suspect, regard them > asdisposable office equipment with no more personality than a > stapler. I know the main focus of the list. The Vostro 1700 is almost old enough to be a semi-antique. I don't know another list where people might know why the display flashes once and then goes black. > The Vostro 1700 looks to be a 2007 era 17" C2D laptop. > Not much info to go on in your message. You say it boots; how do > youknow? If you shine a very bright light at the display, you can dimly see what it's trying to show. So the display works, but the backlight doesn't. I saw a note that if the display flashes, however briefly, the problem is almost certainly the inverter, not the backlight. So I've ordered a new one -- $10.99, including tax and shipping. > What OS? Latest firmware? Can you SSH to it when the OS comesup? Can > it successfully drive an external screen? Have you opened itup and > checked its CPU and GPU fans are clean, unobstructed, spin andit's > not overheating? Windoze 10 with all the updates. I installed a Ubuntu-something drive and I can ssh to it. It's not overheating. It's my brother's only computer. He's destitute and lives in a room slightly bigger than a postage stamp. He can't afford a new laptop, and he is picky about where the USB connectors are. (His hobby is complaining that most stuff other people would say is good enough isn't perfect.) --===============6565506830620046309==-- From sellam.ismail@gmail.com Sun Apr 7 19:57:14 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Sun, 07 Apr 2024 12:56:58 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2239378263724092190==" --===============2239378263724092190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The point being that there are nigh endless forums for PC tech support but there's only one ClassicCmp mailing list. On Sun, Apr 7, 2024 at 12:43=E2=80=AFPM Van Snyder via cctalk wrote: > > --===============2239378263724092190==-- From dillera@dillernet.com Sun Apr 7 20:07:16 2024 From: Andrew Diller To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Sun, 07 Apr 2024 16:07:09 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2589746240731033353==" --===============2589746240731033353== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Replace all the caps. Then it will work! -andy > On Apr 7, 2024, at 3:43 PM, Van Snyder via cctalk = wrote: >=20 > I know the main focus of the list. The Vostro 1700 is almost old enough > to be a semi-antique. I don't know another list where people might know > why the display flashes once and then goes black. >=20 --===============2589746240731033353==-- From lists@skogtun.org Sun Apr 7 20:27:20 2024 From: Harald Arnesen To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sun, 07 Apr 2024 22:14:16 +0200 Message-ID: In-Reply-To: <550d8f4e-319b-4e9b-b00b-09a20e824581@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6947521329657797788==" --===============6947521329657797788== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit ben via cctalk [07/04/2024 20.05]: > I don't think bottles would be ship able. Now a keg of beer might be. > Or a least the old oak kegs you read in stories. No problem to ship beer bottles, just pack them in diapers. We do this all the time in the Norwegian homebrew competitions. Now, diapers are the only thing really cheap in Norway. -- Hilsen Harald. --===============6947521329657797788==-- From kantexplain@protonmail.com Sun Apr 7 21:33:40 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sun, 07 Apr 2024 21:33:31 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2859463159518659794==" --===============2859463159518659794== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What about cans? They don't shatter. What? Too American? I mean I won't drink out of anything but glass. But dad u= sed to drink those tall boy Rheingold and Schaeffer. He was so nasty in the m= ornings. Sent with Proton Mail secure email. On Sunday, April 7th, 2024 at 4:14 PM, Harald Arnesen via cctalk wrote: > ben via cctalk [07/04/2024 20.05]: >=20 > > I don't think bottles would be ship able. Now a keg of beer might be. > > Or a least the old oak kegs you read in stories. >=20 >=20 > No problem to ship beer bottles, just pack them in diapers. We do this > all the time in the Norwegian homebrew competitions. Now, diapers are > the only thing really cheap in Norway. > -- > Hilsen Harald. --===============2859463159518659794==-- From bfranchuk@jetnet.ab.ca Sun Apr 7 22:39:10 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sun, 07 Apr 2024 16:38:58 -0600 Message-ID: <58e8bb9e-32b0-4413-9c22-e132f0f64a8c@jetnet.ab.ca> In-Reply-To: =?utf-8?q?=3CE4nWZaZ5c9KITEMs0i=5FX6J5Zq8SV9i02h=5FcomZPSohVFqY?= =?utf-8?q?5f4f8ar=5FAKD6D4Hps629ny43WWkqNg8kG8O5yRA91M0D7uEDxq2DvwahHKr0M?= =?utf-8?q?=3D=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5163771099789592414==" --===============5163771099789592414== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-07 3:33 p.m., Just Kant via cctalk wrote: > What about cans? They don't shatter. >=20 > What? Too American? I mean I won't drink out of anything but glass. But dad= used to drink those tall boy Rheingold and Schaeffer. He was so nasty in the= mornings. >=20 >=20 >=20 >=20 > Sent with Proton Mail secure email. >=20 > On Sunday, April 7th, 2024 at 4:14 PM, Harald Arnesen via cctalk wrote: >=20 >> ben via cctalk [07/04/2024 20.05]: >> >>> I don't think bottles would be ship able. Now a keg of beer might be. >>> Or a least the old oak kegs you read in stories. >> >> >> No problem to ship beer bottles, just pack them in diapers. We do this >> all the time in the Norwegian homebrew competitions. Now, diapers are >> the only thing really cheap in Norway. >> -- >> Hilsen Harald. But kegs are more fun. --===============5163771099789592414==-- From ard.p850ug1@gmail.com Mon Apr 8 03:42:15 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Mon, 08 Apr 2024 04:41:59 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1057343392848905752==" --===============1057343392848905752== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Apr 4, 2024 at 1:48 AM Sellam Abraham via cctalk wrote: [Sent privately] > > Has anyone communicated with or know a way to communicate with Joe Rigdon > out of Florida? Most here should know him as an old-school ClassicCmp > veteran. I have just heard that he attended the HP Handhelds conference last year so is alive and well and still, presumably, interested in such machines. But no way to contact him -tony --===============1057343392848905752==-- From sellam.ismail@gmail.com Mon Apr 8 03:54:43 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Sun, 07 Apr 2024 20:54:26 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4154764372018008314==" --===============4154764372018008314== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tony. Thank you for the note. Is there any way to confirm this? Many people have been seeking out Joe and when I tell them I'm told he was spotted alive last year there are going to be many questions, and many people wanting to attempt to reach him. More than a few people are very concerned about him as they enjoyed varying relationships with him but none have heard from him for 5+ years. Thank you. Sellam On Sun, Apr 7, 2024 at 8:42=E2=80=AFPM Tony Duell via cctalk wrote: > On Thu, Apr 4, 2024 at 1:48=E2=80=AFAM Sellam Abraham via cctalk > wrote: > > [Sent privately] > > > > > Has anyone communicated with or know a way to communicate with Joe Rigdon > > out of Florida? Most here should know him as an old-school ClassicCmp > > veteran. > > I have just heard that he attended the HP Handhelds conference last > year so is alive and well and still, presumably, interested in such > machines. But no way to contact him > > -tony > --===============4154764372018008314==-- From glen.slick@gmail.com Mon Apr 8 06:07:23 2024 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: DEC VT340/330 ROM Cartridge Date: Sun, 07 Apr 2024 23:07:06 -0700 Message-ID: In-Reply-To: <60105b98-8292-4a6b-99c9-594ddec6d47f@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0485330901460597586==" --===============0485330901460597586== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Apr 6, 2024 at 8:26 AM Douglas Taylor via cctalk wrote: > > On 4/6/2024 11:14 AM, Tony Duell via cctalk wrote: > > On Sat, Apr 6, 2024 at 3:54 PM Douglas Taylor via cctalk > > wrote: > >> The DEC VT340 has a slot in the back of the terminal to insert a ROM > >> cartridge. I can't find any description of what this DEC labeled ROM > >> cartridge would do for you. I've seen them with V1.1 and V2.1 markings, > >> does anyone remember what additional capabilities these ROM cartridge > >> provide? > > Will the terminal work at all without that cartridge fitted?. I've had > > a quick look at the VT330 and VT340 printsets and I can't obviously > > spot any firmware ROMs on the main board schematics. So my first guess > > is that said cartridge is the terminal firmware. > > > > -tony > > Hmm, I have a VT340 that seems to pass POST but no video. It does have > a cartridge inserted into the slot, you may be exactly correct. > > Doug The VT340 I have does not have an opening on the back where the ROM slot would be. Maybe the ROM card is still there in that location, but the back cover molding was changed to remove the user accessible slot. I'd have to pull the cover off to see if the ROM board is still in that location. The VT330 I have does have a removable ROM card. That one might be a pre-production unit. Instead of mask ROMs it has EPROMs, and the manuals it came with are not production level manuals. --===============0485330901460597586==-- From useddec@gmail.com Mon Apr 8 06:48:39 2024 From: Paul Anderson To: cctalk@classiccmp.org Subject: [cctalk] Re: DEC VT340/330 ROM Cartridge Date: Mon, 08 Apr 2024 01:48:24 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5406354273632913495==" --===============5406354273632913495== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I believe the VT340-A has the ROM card, but the VT340-G (or plus) does not. The same goes for the VT330A, B, and C versus the D, E, and F. Paul On Mon, Apr 8, 2024 at 1:07=E2=80=AFAM Glen Slick via cctalk wrote: > On Sat, Apr 6, 2024 at 8:26=E2=80=AFAM Douglas Taylor via cctalk > wrote: > > > > On 4/6/2024 11:14 AM, Tony Duell via cctalk wrote: > > > On Sat, Apr 6, 2024 at 3:54=E2=80=AFPM Douglas Taylor via cctalk > > > wrote: > > >> The DEC VT340 has a slot in the back of the terminal to insert a ROM > > >> cartridge. I can't find any description of what this DEC labeled ROM > > >> cartridge would do for you. I've seen them with V1.1 and V2.1 > markings, > > >> does anyone remember what additional capabilities these ROM cartridge > > >> provide? > > > Will the terminal work at all without that cartridge fitted?. I've had > > > a quick look at the VT330 and VT340 printsets and I can't obviously > > > spot any firmware ROMs on the main board schematics. So my first guess > > > is that said cartridge is the terminal firmware. > > > > > > -tony > > > > Hmm, I have a VT340 that seems to pass POST but no video. It does have > > a cartridge inserted into the slot, you may be exactly correct. > > > > Doug > > The VT340 I have does not have an opening on the back where the ROM > slot would be. Maybe the ROM card is still there in that location, but > the back cover molding was changed to remove the user accessible slot. > I'd have to pull the cover off to see if the ROM board is still in > that location. > > The VT330 I have does have a removable ROM card. That one might be a > pre-production unit. Instead of mask ROMs it has EPROMs, and the > manuals it came with are not production level manuals. > --===============5406354273632913495==-- From mike_t_norris@hotmail.com Mon Apr 8 10:41:31 2024 From: Mike Norris To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Mon, 08 Apr 2024 10:41:24 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1322583569491280089==" --===============1322583569491280089== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Christian, I have sent an email to your personal address (off list). The comments about the beer seem to have started a thread, all good fun!! Regards Mike Norris ________________________________ From: Christian Groessler via cctalk Sent: 07 April 2024 12:57 To: cctalk(a)classiccmp.org Cc: Christian Groessler Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals On 4/6/24 5:37 PM, Mike Norris via cctalk wrote: > Additional > I would like =C2=A35 beer money for this one please! > Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard Szubow= icz I'd take it. I can send you beer money, or could send you 2 or 3 bottles of local beer. I'm living near Munich, Germany. Sending beer will likely be quite more expensive than 5 pounds, but has a fun factor bonus :-) regards, chris --===============1322583569491280089==-- From lproven@gmail.com Mon Apr 8 15:13:59 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Problem with Dell Vostro 1700 Date: Mon, 08 Apr 2024 16:13:43 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1364209254971436890==" --===============1364209254971436890== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 7 Apr 2024 at 20:43, Van Snyder via cctalk wrote: > I know the main focus of the list. No, you don't, because then you say: > The Vostro 1700 is almost old enough > to be a semi-antique. And it isn't. > I don't know another list where people might know > why the display flashes once and then goes black. Then you should go join more communities and not complain about this one -- or upset it. > If you shine a very bright light at the display, you can dimly see what > it's trying to show. So the display works, but the backlight doesn't. So you have identified the problem and did not say so? > It's my brother's only computer. He's destitute and lives in a room > slightly bigger than a postage stamp. Sorry to hear that. > He can't afford a new laptop, and > he is picky about where the USB connectors are. He doesn't get to be picky if he's that poor. That's how life is. > (His hobby is complaining that most stuff other people would say is > good enough isn't perfect.) That is a privilege that comes with being able to afford better. TBH, ISTM that you actively want to annoy people here. It's working on me, I can tell you that. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============1364209254971436890==-- From gavin@learn.bio Mon Apr 8 16:29:11 2024 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking out Joe Rigdon / John Lawson Date: Mon, 08 Apr 2024 11:28:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8116500569207591915==" --===============8116500569207591915== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If it's the conference with many videos here: https://www.youtube.com/@hpcalc/videos Then you could ask Eric as I see him giving a presentation. Or watch all the videos and see if you can spot anyone. On Sun, Apr 7, 2024 at 10:54=E2=80=AFPM Sellam Abraham via cctalk wrote: > > Hi Tony. > > Thank you for the note. > > Is there any way to confirm this? Many people have been seeking out Joe > and when I tell them I'm told he was spotted alive last year there are > going to be many questions, and many people wanting to attempt to reach > him. More than a few people are very concerned about him as they enjoyed > varying relationships with him but none have heard from him for 5+ years. > > Thank you. > > Sellam > > On Sun, Apr 7, 2024 at 8:42=E2=80=AFPM Tony Duell via cctalk > wrote: > > > On Thu, Apr 4, 2024 at 1:48=E2=80=AFAM Sellam Abraham via cctalk > > wrote: > > > > [Sent privately] > > > > > > > > Has anyone communicated with or know a way to communicate with Joe Rigd= on > > > out of Florida? Most here should know him as an old-school ClassicCmp > > > veteran. > > > > I have just heard that he attended the HP Handhelds conference last > > year so is alive and well and still, presumably, interested in such > > machines. But no way to contact him > > > > -tony > > --===============8116500569207591915==-- From bill.gunshannon@hotmail.com Mon Apr 8 19:19:19 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 15:18:32 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5745461114154482025==" --===============5745461114154482025== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I'm having bit of fun with my various CP/M systems but I ran into what I see as an interesting problem. I got Turbo Pascal on two systems. A TRS-80 model 4P running Montezuma Micro CP/M and a TRS-80 Model II running Pickles & Trout CP/M. I tried to compile the version of Kermit written for CP/M using Turbo Pascal. On both systems it runs out of memory and crashes in the same place. Surely the developers would have noticed this. Anybody here have any experience with this? bill --===============5745461114154482025==-- From cisin@xenosoft.com Mon Apr 8 21:00:51 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 14:00:44 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB573750139A1F78BEE1E7401AED002=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0552835252421610370==" --===============0552835252421610370== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 8 Apr 2024, Bill Gunshannon via cctalk wrote: > I'm having bit of fun with my various CP/M systems but I ran into > what I see as an interesting problem. I got Turbo Pascal on two > systems. A TRS-80 model 4P running Montezuma Micro CP/M and a TRS-80 > Model II running Pickles & Trout CP/M. I tried to compile the version > of Kermit written for CP/M using Turbo Pascal. On both systems it > runs out of memory and crashes in the same place. Surely the > developers > would have noticed this. Anybody here have any experience with this? Have you tried it with "CP/M PLUS"? (CP/M 3.0, which Radio Shack sold for the model 4) Does the Turbo Pascal run on those machines with trivial source file? or subsets of the Kermit code? -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============0552835252421610370==-- From gavin@learn.bio Mon Apr 8 21:17:55 2024 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 16:17:40 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB573750139A1F78BEE1E7401AED002=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4620474672573443275==" --===============4620474672573443275== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 8, 2024 at 2:19 PM Bill Gunshannon via cctalk wrote: > I'm having bit of fun with my various CP/M systems but I ran into > what I see as an interesting problem. I got Turbo Pascal on two > systems. If it's an old version of TP that asks "Include error messages (Y/N)?", did you try saying N? --===============4620474672573443275==-- From bill.gunshannon@hotmail.com Tue Apr 9 00:11:52 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 20:11:15 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0286206049406103548==" --===============0286206049406103548== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/8/2024 5:17 PM, Gavin Scott via cctalk wrote: > On Mon, Apr 8, 2024 at 2:19 PM Bill Gunshannon via cctalk > wrote: >> I'm having bit of fun with my various CP/M systems but I ran into >> what I see as an interesting problem. I got Turbo Pascal on two >> systems. > > If it's an old version of TP that asks "Include error messages > (Y/N)?", did you try saying N? Same error, one file further along. bill --===============0286206049406103548==-- From bill.gunshannon@hotmail.com Tue Apr 9 00:19:52 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 20:19:21 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6838220751125080247==" --===============6838220751125080247== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/8/2024 5:00 PM, Fred Cisin wrote: > On Mon, 8 Apr 2024, Bill Gunshannon via cctalk wrote: >> I'm having  bit of fun with my various CP/M systems but I ran into >> what I see as an interesting problem.  I got Turbo Pascal on two >> systems.  A TRS-80 model 4P running Montezuma Micro CP/M and a TRS-80 >> Model II running Pickles & Trout CP/M.  I tried to compile the version >> of Kermit written for CP/M using Turbo Pascal.  On both systems it >> runs out of memory and crashes in the same place.  Surely the developers >> would have noticed this.  Anybody here have any experience with this? > > Have you tried it with "CP/M PLUS"?  (CP/M 3.0, which Radio Shack sold > for the model 4) Not yet. I don't have a 3.0 setup with a hard disk yet and I doubt everything will fit on a floppy. > > Does the Turbo Pascal run on those machines with trivial source file? > or subsets of the Kermit code? Haven't tried any other programs yet as I really wanted Kermit but none of the other CP/M Kermits work on these machines (at least not so far) but the problem does appear to be that the program is just to big. I just can't believe none of he developers noticed or maybe that was the point where they all gave up. :-) bill --===============6838220751125080247==-- From cisin@xenosoft.com Tue Apr 9 00:36:30 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 17:36:25 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737A971F88C9F6470E7659DED072=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5328124125842401568==" --===============5328124125842401568== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> Does the Turbo Pascal run on those machines with trivial source file? >> or subsets of the Kermit code? On Mon, 8 Apr 2024, Bill Gunshannon via cctalk wrote: > Haven't tried any other programs yet as I really wanted Kermit but > none of the other CP/M Kermits work on these machines (at least not > so far) but the problem does appear to be that the program is just > to big. > > I just can't believe none of he developers noticed or maybe that > was the point where they all gave up. :-) Well, there is still the issue of whether it is an incompatability of that version of Turbo Pascal with your machines, . . . Are you running with 128K? On machines that support it, 128K does NOT give you a TPA ("Transient Program Area") larger than 64K, but it does give it almost 64K. I wonder how large the TPA is on DOS based CP/M emulators, . . . ? . . . and, of course, is there somewhere, a pre-compiled version of Kermit for TRS80 CP/M? -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5328124125842401568==-- From doug@doughq.com Tue Apr 9 01:08:30 2024 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Tue, 09 Apr 2024 10:59:17 +1000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1809554951409276195==" --===============1809554951409276195== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Wow, I agree that there is clearly an incompatibility - I wonder how? CP/M should be CP/M... Just the BDOS changed for the individual machine hardware. One thought is the screen RAM may be an issue with overlaying. I suspect that Borland didn't notice, as the TRS80 Model 4 was really late in the 8 bit world, having been released in 1983. The IBM PC was released in 1981, so I suspect that by the time somebody ran CP/M on a Model 4, Borland had moved onto PC/MS-DOS. Kindest regards, Doug Jackson em: doug(a)doughq.com ph: 0414 986878 Follow my amateur radio adventures at vk1zdj.net On Tue, 9 Apr 2024 at 10:36, Fred Cisin via cctalk wrote: > >> Does the Turbo Pascal run on those machines with trivial source file? > >> or subsets of the Kermit code? > > On Mon, 8 Apr 2024, Bill Gunshannon via cctalk wrote: > > Haven't tried any other programs yet as I really wanted Kermit but > > none of the other CP/M Kermits work on these machines (at least not > > so far) but the problem does appear to be that the program is just > > to big. > > > > I just can't believe none of he developers noticed or maybe that > > was the point where they all gave up. :-) > > Well, there is still the issue of whether it is an incompatability of that > version of Turbo Pascal with your machines, . . . > > > Are you running with 128K? > On machines that support it, 128K does NOT give you a TPA ("Transient > Program Area") larger than 64K, but it does give it almost 64K. > > I wonder how large the TPA is on DOS based CP/M emulators, . . . ? > > > . . . and, of course, is there somewhere, a pre-compiled version of Kermit > for TRS80 CP/M? > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com > > > --===============1809554951409276195==-- From wrcooke@wrcooke.net Tue Apr 9 01:16:13 2024 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 20:16:09 -0500 Message-ID: <1339309707.7391436.1712625369271@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0231549601564412790==" --===============0231549601564412790== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You mentioned that the TRS-80(s) have hard disks. Perhaps the extra space ta= ken by the hard disk bios is the culprit. Maybe a floppy-only machine (with = floppy only bios) is the only way to compile it. Will Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince --===============0231549601564412790==-- From jeffrey@vcfed.org Tue Apr 9 01:20:28 2024 From: Jeffrey Brace To: cctalk@classiccmp.org Subject: [cctalk] This weekend: VCF East 2024 - April 12-14 (Wall, NJ) Date: Mon, 08 Apr 2024 21:20:05 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8483696213430461124==" --===============8483696213430461124== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit This year will be bigger than ever with lots of great exhibits, speakers, consignment, Atari Programming Classroom and Glitch Works workshop. VCF East takes place in Wall, NJ at InfoAge Science and History Museums (formerly Camp Evans). For more information: https://vcfed.org/events/vintage-computer-festival-east/ Tickets for VCF East (Eventbrite) – Non- VCF Members should use this link. Discounted tickets for VCF Members Only (VCF’s website) – VCF members should use this link. To get the 20% discount you need to become a VCF member by Clicking Here Don't miss the show! Take care! Jeff Brace Vintage Computer Festival East Showrunner --===============8483696213430461124==-- From cisin@xenosoft.com Tue Apr 9 03:47:44 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Mon, 08 Apr 2024 20:47:39 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737A971F88C9F6470E7659DED072=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4691165594960490992==" --===============4691165594960490992== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 8 Apr 2024, Bill Gunshannon via cctalk wrote: > I just can't believe none of he developers noticed or maybe that > was the point where they all gave up. :-) Presumably, it worked on the machine that they were using. Not everybody tests everything on all possible configurations. SOME companies don't test anything on any configuration other than what they are using. For example, at Microsoft, if a programmer has a hardware problem, they immediately replace the machine. Good working conditions. BUT, that means that they have substantially less experience than we do with problematic machines. Hence, disasters, such as SMARTDRV originally defaulting to having write cacheing ON, which gives data loss (blamed on other components!) EVERY time there is an unrecovered disk error, OR the user turns off the machine (normal practice for most users in the 1980s) before all the buffers are flushed. Proper testing would have found that before release. Beta testers of Windows 3.11 who reported that problem were told, "You have a HARDWARE problem. That's not our responsibility." Those who suggested that the OS at least had a responsibility of reporting and making graceful exit in such conditions were dropped from the Beta program for all future products. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============4691165594960490992==-- From c.murray.mccullough@gmail.com Wed Apr 10 02:53:56 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] IBM 360 Date: Tue, 09 Apr 2024 22:53:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2091911959533405009==" --===============2091911959533405009== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I had not realized the IBM 360 was 60 yrs. old this month. I worked on such a computer in the late 60s in Toronto. What one could do with 8 Kbytes of ram was remarkable! Happy computing Murray 🙂 --===============2091911959533405009==-- From bfranchuk@jetnet.ab.ca Wed Apr 10 05:03:25 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Tue, 09 Apr 2024 23:03:12 -0600 Message-ID: <90fe17c8-d634-4ce5-9456-0d33837efc21@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7757994676598106526==" --===============7757994676598106526== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: > I had not realized the IBM 360 was 60 yrs. old this month. I worked on such > a computer in the late 60s in Toronto. What one could do with 8 Kbytes of > ram was remarkable! > > Happy computing > > Murray 🙂 Real time sharing, not a 16K PDP 8? --===============7757994676598106526==-- From cclist@sydex.com Wed Apr 10 05:22:00 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Tue, 09 Apr 2024 22:21:48 -0700 Message-ID: <95907082-7b23-47be-b885-ccfb99d6e7fa@sydex.com> In-Reply-To: <90fe17c8-d634-4ce5-9456-0d33837efc21@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5563293541207706679==" --===============5563293541207706679== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/9/24 22:03, ben via cctalk wrote: > On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: >> I had not realized the IBM 360 was 60 yrs. old this month. I worked on >> such >> a computer in the late 60s in Toronto. What one could do with 8 Kbytes of >> ram was remarkable! >> >> Happy computing >> >> Murray 🙂 > Real time sharing, not a 16K PDP 8? What model of a 360? 8K sounds a lot like a Model 20, which the purists may not consider to be a "real" member of the family. --Chuck --===============5563293541207706679==-- From artgodwin@gmail.com Wed Apr 10 06:46:25 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 07:46:09 +0100 Message-ID: In-Reply-To: <95907082-7b23-47be-b885-ccfb99d6e7fa@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2610670488363848555==" --===============2610670488363848555== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit And the 'tarpit' book is 50, dated by the preface. On Wed, Apr 10, 2024 at 6:22 AM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 4/9/24 22:03, ben via cctalk wrote: > > On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: > >> I had not realized the IBM 360 was 60 yrs. old this month. I worked on > >> such > >> a computer in the late 60s in Toronto. What one could do with 8 Kbytes > of > >> ram was remarkable! > >> > >> Happy computing > >> > >> Murray 🙂 > > Real time sharing, not a 16K PDP 8? > > What model of a 360? 8K sounds a lot like a Model 20, which the purists > may not consider to be a "real" member of the family. > > --Chuck > > > --===============2610670488363848555==-- From van.snyder@sbcglobal.net Wed Apr 10 06:52:09 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Tue, 09 Apr 2024 23:51:54 -0700 Message-ID: In-Reply-To: <95907082-7b23-47be-b885-ccfb99d6e7fa@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6311897327414051117==" --===============6311897327414051117== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, 2024-04-09 at 22:21 -0700, Chuck Guzis via cctalk wrote: > On 4/9/24 22:03, ben via cctalk wrote: > > On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: > > > I had not realized the IBM 360 was 60 yrs. old this month. I > > > worked on > > > such > > > a computer in the late 60s in Toronto. What one could do with 8 > > > Kbytes of > > > ram was remarkable! > > > > > > Happy computing > > > > > > Murray 🙂 > > Real time sharing, not a 16K PDP 8? > > What model of a 360?  8K sounds a lot like a Model 20, which the > purists > may not consider to be a "real" member of the family. I don't remember whether it was one of the docents at Haus zur Geschichte der IBM Datenverarbeitung at Sindelfingen, or at the Computer History Museum at Mountain View, who told me that IBM was developing a machine to be designated 1480, as part of the 1401-1440- 1460-1410 series, with newer technology, roughly contemporaneously with the 360. When IBM decided to put all its eggs in the 360 basket, The 1480 team somehow survived and produced either the 360/20 or 360/25. An 8k machine would be a bit weird in this series, since 1410 was already 100k. Does anybody know more details about this? Samir Husson wrote a book about the 360/30 that described the microcode. Has anybody built a 360/30 from FPGA? Does anybody have the 360 and 1401 microcode for it? How about the Compatibility Initialization Deck to run the 1401 microcode emulation? > >  --Chuck > > --===============6311897327414051117==-- From cclist@sydex.com Wed Apr 10 07:26:06 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 00:25:53 -0700 Message-ID: <75999389-7809-41b4-a9be-d25cce0fd7d8@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0471986387009564050==" --===============0471986387009564050== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/9/24 23:51, Van Snyder via cctalk wrote: > I don't remember whether it was one of the docents at Haus zur > Geschichte der IBM Datenverarbeitung at Sindelfingen, or at the > Computer History Museum at Mountain View, who told me that IBM was > developing a machine to be designated 1480, as part of the 1401-1440- > 1460-1410 series, with newer technology, roughly contemporaneously with > the 360. When IBM decided to put all its eggs in the 360 basket, The > 1480 team somehow survived and produced either the 360/20 or 360/25. An > 8k machine would be a bit weird in this series, since 1410 was already > 100k. Does anybody know more details about this? The model 20 could have between 4K-16KB memory initially; later it was expanded to a maximum of 32K. The model 30 was configured with a minimum of 8KB up to 64KB. I'm not sure if DOS/360 could run in 8KB; I don't know how common 8KB model 30s were, but I've never seen one. The big difference is that the model 20 is really a 16-bit machine, with 16-bit general registers and a very pruned-down instruction set with a considerable number of differences from the bigger systems. --Chuck --===============0471986387009564050==-- From couryhouse@aol.com Wed Apr 10 07:46:54 2024 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 07:46:42 +0000 Message-ID: <936209755.4501455.1712735202106@mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5820285881745393603==" --===============5820285881745393603== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A 360 front panel sold for over $4,000 I think much more on eBay recently I c= an't believe it I cannot believe it Sent from AOL on Android=20 =20 On Tue, Apr 9, 2024 at 11:46 PM, Adrian Godwin via cctalk wrote: And the 'tarpit' book is 50, dated by the preface. On Wed, Apr 10, 2024 at 6:22=E2=80=AFAM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 4/9/24 22:03, ben via cctalk wrote: > > On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: > >> I had not realized the IBM 360 was 60 yrs. old this month. I worked on > >> such > >> a computer in the late 60s in Toronto. What one could do with 8 Kbytes > of > >> ram was remarkable! > >> > >> Happy computing > >> > >> Murray =F0=9F=99=82 > > Real time sharing, not a 16K PDP 8? > > What model of a 360?=C2=A0 8K sounds a lot like a Model 20, which the puris= ts > may not consider to be a "real" member of the family. > >=C2=A0 --Chuck > > > =20 --===============5820285881745393603==-- From sqrfolkdnc@comcast.net Wed Apr 10 08:45:29 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 03:45:24 -0500 Message-ID: <145869550.1478027.1712738724194@connect.xfinity.com> In-Reply-To: <936209755.4501455.1712735202106@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5186481537688736789==" --===============5186481537688736789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable the model 25 was many years later, and IIRC actually faster then the model 30= . there was also a model 22 that was a full 360. =20 NO, DOS would not run on an 8k machine. the nucleus was 8k (maybe), then 10k= , the 12k, I think even 16k after I had left. there was also BPS, load it in, then load in program (all from cards)\ Or there was BOS, not sure, but I think that was everything loaded on disk, b= ut all run by commands from console then there was TOS in early days, like DOS but from a system tape. the fun job was the 1404 printer which I don't know if any museum have. it w= as wider, and the print head could be moved to the other side and it would fe= ed and print on two tab cards at a time. On a 64k model 30, we ran BG and F1 at 24-26k each, doing batch work, F2 at 2= k invoked by console commands (needed 8k(?) to run job control in a partition= ) for a spooling job, either reading cards to tape or print tape to printer. = the tapes came from the remaining 7010 computer that did not have a printer = on it. The two model 50s in the other room ran 7010 emulation but printed di= rectly. we also had one 32k model 30, it could do one small job nearly ALL jobs were 360 programs that invoked 1401 emulation (we had ONE 140= 1 left) you could also use the console to run 1401 emulation without DOS (i think 2 o= ptions, one loaded in card deck, then allowed typing in config, otherwise jus= t turn dials and store stuff into memory. we briefly had a 3rd party 2311 equivalent, which was cool because it had lig= hts on the front to show (in binary) what cylinder the head was at. later, a= nother matchine briefly had a 3rd party mod to extend memory to 96k (Ibm's li= mit was 64k), which failed so that upgraded to a model 40 as they had to have= more memory for the application. --===============5186481537688736789==-- From g4ajq1@gmail.com Wed Apr 10 10:29:55 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 06:29:48 -0400 Message-ID: <992a8599-1b09-4660-9fc8-8b7e5203d526@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0827516003971742216==" --===============0827516003971742216== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit RAM?  You mean CORE, don't you? On 2024-04-09 22:53, Murray McCullough via cctalk wrote: > I had not realized the IBM 360 was 60 yrs. old this month. I worked on such > a computer in the late 60s in Toronto. What one could do with 8 Kbytes of > ram was remarkable! > > Happy computing > > Murray 🙂 -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============0827516003971742216==-- From Martin.Hepperle@dlr.de Wed Apr 10 11:01:54 2024 From: Martin.Hepperle@dlr.de To: cctalk@classiccmp.org Subject: [cctalk] Turbo Pascal Kermit for CP/M Date: Wed, 10 Apr 2024 10:54:40 +0000 Message-ID: <1e381736b10244b3a0659d38914d6aaf@dlr.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3710238262396175714==" --===============3710238262396175714== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Did you compile in memory or to disk? If you have little RAM, it might be adv= antageous to compile to disk, creating a .COM file. Martin --===============3710238262396175714==-- From phb.hfx@gmail.com Wed Apr 10 11:39:03 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 08:38:52 -0300 Message-ID: <28028230-c6a4-4d70-8840-47881b9dc3f5@gmail.com> In-Reply-To: <95907082-7b23-47be-b885-ccfb99d6e7fa@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0921086191901176216==" --===============0921086191901176216== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-10 2:21 a.m., Chuck Guzis via cctalk wrote: > On 4/9/24 22:03, ben via cctalk wrote: >> On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: >>> I had not realized the IBM 360 was 60 yrs. old this month. I worked on >>> such >>> a computer in the late 60s in Toronto. What one could do with 8 Kbytes of >>> ram was remarkable! >>> >>> Happy computing >>> >>> Murray 🙂 >> Real time sharing, not a 16K PDP 8? > What model of a 360? 8K sounds a lot like a Model 20, which the purists > may not consider to be a "real" member of the family. > > --Chuck > > The IBM Don Mills plant in Toronto built model 20s.  I knew guys who bought their houses with the overtime working on them.  They had accumulated a lot of engineering changes that had not been cut into production, so they would be assembled and then there where teams that would apply the engineering changes before the systems where shipped. Paul. --===============0921086191901176216==-- From phb.hfx@gmail.com Wed Apr 10 11:45:30 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 08:45:22 -0300 Message-ID: In-Reply-To: <992a8599-1b09-4660-9fc8-8b7e5203d526@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3799794898167152246==" --===============3799794898167152246== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Well core memory IS a form of Random Access Memory (RAM) as opposed to things like delay line memory that is sequential access. Paul. On 2024-04-10 7:29 a.m., Nigel Johnson Ham via cctalk wrote: > RAM? You mean CORE, don't you? > > On 2024-04-09 22:53, Murray McCullough via cctalk wrote: >> I had not realized the IBM 360 was 60 yrs. old this month. I worked >> on such >> a computer in the late 60s in Toronto. What one could do with 8 >> Kbytes of >> ram was remarkable! >> >> Happy computing >> >> Murray 🙂 > --===============3799794898167152246==-- From sqrfolkdnc@comcast.net Wed Apr 10 12:18:08 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 07:18:00 -0500 Message-ID: <1388992181.1479453.1712751480296@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2853413976590542093==" --===============2853413976590542093== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nearly all the 360s were microcoded, so adding a bit more microcode let them = emulate 1400/7000 series computers as a standard optional feature. (well the = model 44 emulated the 1620, and probably the 95/195 could not emulate anythin= g since they were hard wired). I do not recall that was documented in the Principles of Operation. Does anybody here know how emulation was turned on (and off)? was there some= special bit or bits in the PSW, or an undocumented instruction? --Carey --===============2853413976590542093==-- From g4ajq1@gmail.com Wed Apr 10 13:00:53 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 09:00:45 -0400 Message-ID: <754669da-5eaa-4431-a3ed-66794dedeb9a@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6515042537955696300==" --===============6515042537955696300== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit But we didn't use the tern back then! On 2024-04-10 07:45, Paul Berger via cctalk wrote: > Well core memory IS a form of Random Access Memory (RAM) as opposed to > things like delay line memory that is sequential access. > > Paul. > > On 2024-04-10 7:29 a.m., Nigel Johnson Ham via cctalk wrote: >> RAM? You mean CORE, don't you? >> >> On 2024-04-09 22:53, Murray McCullough via cctalk wrote: >>> I had not realized the IBM 360 was 60 yrs. old this month. I worked >>> on such >>> a computer in the late 60s in Toronto. What one could do with 8 >>> Kbytes of >>> ram was remarkable! >>> >>> Happy computing >>> >>> Murray 🙂 >> -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============6515042537955696300==-- From bill.gunshannon@hotmail.com Wed Apr 10 13:25:06 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Turbo Pascal Kermit for CP/M Date: Wed, 10 Apr 2024 09:23:54 -0400 Message-ID: In-Reply-To: <1e381736b10244b3a0659d38914d6aaf@dlr.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2461347396347330642==" --===============2461347396347330642== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/10/2024 6:54 AM, Martin.Hepperle--- via cctalk wrote: > Did you compile in memory or to disk? If you have little RAM, it might be a= dvantageous to compile to disk, creating a .COM file. >=20 And the winner is.... It's been so long since I used Turbo anything I had forgotten that option. It compiled fine. Doesn't work, but at least it compiled. :-) Thank you. bill --===============2461347396347330642==-- From paulkoning@comcast.net Wed Apr 10 13:26:19 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 09:26:13 -0400 Message-ID: <57CCBFB9-1591-469F-8CA0-4F498C2BF91F@comcast.net> In-Reply-To: <1388992181.1479453.1712751480296@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2048600332973891445==" --===============2048600332973891445== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 10, 2024, at 8:18 AM, CAREY SCHUG via cctalk wrote: >=20 > Nearly all the 360s were microcoded, so adding a bit more microcode let the= m emulate 1400/7000 series computers as a standard optional feature. (well th= e model 44 emulated the 1620, ... Um, what? In college I used a 360/44, which ran OS/360 (PCP 19.6, all that could fit in= 128 kB of memory), which was made possible by the fact that it had the "emul= ator" option. But that wasn't a 1620 emulation; instead, it added the SS ins= tructions of the standard 360 instruction set back in, those were omitted fro= m the base model 44. Without SS instructions, OS/360 could not run, which is= why the model 44 had an operating system specifically for that machine (PS/4= 4 ? I'm not sure, I never used it). The emulator had a separate chunk of memory and a separate IPL button; unimpl= emented instructions would trap to that memory for the emulator to handle -- = very much like how subset VAX systems like MicroVAX would emulate the missing= instructions. The emulator binary came in a card deck, a standard BPS binary deck preceded = by a single-card loader that was an amazingly clever self-modifying channel p= rogram. The entire logic to interpret the fields of the binary cards and loa= d the entire deck to the right places was implemented in that one-card channe= l program. I read the relevant documentation back then and decoded the loader, but I hav= e never seen any of it since; even just a bare mention of the emulator featur= e is nearly non-existent. paul --===============2048600332973891445==-- From c.murray.mccullough@gmail.com Wed Apr 10 13:36:22 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 09:35:56 -0400 Message-ID: In-Reply-To: <28028230-c6a4-4d70-8840-47881b9dc3f5@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8475319087155645107==" --===============8475319087155645107== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I remember some early days of my computing years. I visited IBM at Eglinton E. & Don Mills Rd., its sprawling complex. I knew a project manager from IBM when he worked at their new facility in Vaughan. I don’t think I truly realized the seminal work done at IBM then(60's&70's). Murray 😊 On Wed, Apr 10, 2024 at 7:39 AM Paul Berger via cctalk < cctalk(a)classiccmp.org> wrote: > > On 2024-04-10 2:21 a.m., Chuck Guzis via cctalk wrote: > > On 4/9/24 22:03, ben via cctalk wrote: > >> On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: > >>> I had not realized the IBM 360 was 60 yrs. old this month. I worked on > >>> such > >>> a computer in the late 60s in Toronto. What one could do with 8 Kbytes > of > >>> ram was remarkable! > >>> > >>> Happy computing > >>> > >>> Murray 🙂 > >> Real time sharing, not a 16K PDP 8? > > What model of a 360? 8K sounds a lot like a Model 20, which the purists > > may not consider to be a "real" member of the family. > > > > --Chuck > > > > > The IBM Don Mills plant in Toronto built model 20s. I knew guys who > bought their houses with the overtime working on them. They had > accumulated a lot of engineering changes that had not been cut into > production, so they would be assembled and then there where teams that > would apply the engineering changes before the systems where shipped. > > Paul. > > --===============8475319087155645107==-- From g4ajq1@gmail.com Wed Apr 10 13:56:12 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 09:56:05 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4191042981452962071==" --===============4191042981452962071== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I remember that building well!   My only visit there was at 2 am though!  I had a 6250bpi GCR mag tape and my drive only did 1600, so a friend who worked there took it from me and converted  it. I thought I would be interrogated by the guard, but apparently small-hours deliveries were commonplace! Funny though, now my friend denies it was him :-) cheers, Nigel On 2024-04-10 09:35, Murray McCullough via cctalk wrote: > I remember some early days of my computing years. I visited IBM at Eglinton > E. & Don Mills Rd., its sprawling complex. I knew a project manager from > IBM when he worked at their new facility in Vaughan. I don’t think I truly > realized the seminal work done at IBM then(60's&70's). > > Murray 😊 > > On Wed, Apr 10, 2024 at 7:39 AM Paul Berger via cctalk < > cctalk(a)classiccmp.org> wrote: > >> On 2024-04-10 2:21 a.m., Chuck Guzis via cctalk wrote: >>> On 4/9/24 22:03, ben via cctalk wrote: >>>> On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: >>>>> I had not realized the IBM 360 was 60 yrs. old this month. I worked on >>>>> such >>>>> a computer in the late 60s in Toronto. What one could do with 8 Kbytes >> of >>>>> ram was remarkable! >>>>> >>>>> Happy computing >>>>> >>>>> Murray 🙂 >>>> Real time sharing, not a 16K PDP 8? >>> What model of a 360? 8K sounds a lot like a Model 20, which the purists >>> may not consider to be a "real" member of the family. >>> >>> --Chuck >>> >>> >> The IBM Don Mills plant in Toronto built model 20s. I knew guys who >> bought their houses with the overtime working on them. They had >> accumulated a lot of engineering changes that had not been cut into >> production, so they would be assembled and then there where teams that >> would apply the engineering changes before the systems where shipped. >> >> Paul. >> >> -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============4191042981452962071==-- From elson@pico-systems.com Wed Apr 10 15:11:12 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 10:11:05 -0500 Message-ID: In-Reply-To: <95907082-7b23-47be-b885-ccfb99d6e7fa@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3266593838680665654==" --===============3266593838680665654== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/10/24 00:21, Chuck Guzis via cctalk wrote: > On 4/9/24 22:03, ben via cctalk wrote: >> > What model of a 360? 8K sounds a lot like a Model 20, which the purists > may not consider to be a "real" member of the family. > Yup, the /20 should have been called a System 180, as it was about half of a 360 instruction set.  But, it only had 4 registers. Jon --===============3266593838680665654==-- From elson@pico-systems.com Wed Apr 10 15:18:02 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 10:17:54 -0500 Message-ID: <882f3bc7-7a13-8ee6-d666-0c04fcfe7ea9@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4622261855481525764==" --===============4622261855481525764== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/10/24 01:51, Van Snyder via cctalk wrote: > On Tue, 2024-04-09 at 22:21 -0700, Chuck Guzis via cctalk wrote: >> On 4/9/24 22:03, ben via cctalk wrote: >>> On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: >>>> I had not realized the IBM 360 was 60 yrs. old this month. I >>>> worked on >>>> such >>>> a computer in the late 60s in Toronto. What one could do with 8 >>>> Kbytes of >>>> ram was remarkable! >>>> >>>> Happy computing >>>> >>>> Murray 🙂 >>> Real time sharing, not a 16K PDP 8? >> What model of a 360?  8K sounds a lot like a Model 20, which the >> purists >> may not consider to be a "real" member of the family. > I don't remember whether it was one of the docents at Haus zur > Geschichte der IBM Datenverarbeitung at Sindelfingen, or at the > Computer History Museum at Mountain View, who told me that IBM was > developing a machine to be designated 1480, as part of the 1401-1440- > 1460-1410 series, with newer technology, roughly contemporaneously with > the 360. When IBM decided to put all its eggs in the 360 basket, The > 1480 team somehow survived and produced either the 360/20 or 360/25. An > 8k machine would be a bit weird in this series, since 1410 was already > 100k. Does anybody know more details about this? The 360/20 had only halfword instructions, no float, no char strings.  But, main storage was 16 bits wide. The 360/30 only had byte-wide memory, and the register file was in a separately addressed part of main storage.  The 360/25 was a very interesting concept.  The microcode was in the top 16 KB of main storage, and 360 and other instruction set emulations could be loaded from cards.  The boot loader for the emulators was in the top 16 bytes (or maybe words) of main storage. Jon --===============4622261855481525764==-- From elson@pico-systems.com Wed Apr 10 15:25:14 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 10:25:06 -0500 Message-ID: <796402ae-48f9-35a9-233e-5f9dff7a1bb7@pico-systems.com> In-Reply-To: <1388992181.1479453.1712751480296@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2992446387994073471==" --===============2992446387994073471== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/10/24 07:18, CAREY SCHUG via cctalk wrote: > Nearly all the 360s were microcoded, so adding a bit more microcode let the= m emulate 1400/7000 series computers as a standard optional feature. (well th= e model 44 emulated the 1620, and probably the 95/195 could not emulate anyth= ing since they were hard wired). > The model 44 was not microcoded.=C2=A0 It had faster floating=20 point than a model /50 but no decimal or string=20 instructions.=C2=A0 Emulation of these was done through trap=20 handlers.=C2=A0 I would assume any other machine emulators were=20 done by something like an emulation wrapper program - like=20 Virtualbox or VMware.=C2=A0 The model 44 had no channels, there=20 was only direct I/O (a set of 32-bit parallel input and=20 output registers) and a pair of cartridge hard drives inside=20 the CPU cabinet.=C2=A0 Think DEC RK05s. Jon --===============2992446387994073471==-- From cclist@sydex.com Wed Apr 10 15:33:39 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 08:27:28 -0700 Message-ID: <7dec3939-ee2f-4b4e-8320-f57bd524274c@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2321539392627406724==" --===============2321539392627406724== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/10/24 08:11, Jon Elson via cctalk wrote: > On 4/10/24 00:21, Chuck Guzis via cctalk wrote: >> On 4/9/24 22:03, ben via cctalk wrote: >>> >> What model of a 360?  8K sounds a lot like a Model 20, which the purists >> may not consider to be a "real" member of the family. >> > Yup, the /20 should have been called a System 180, as it was about half > of a 360 instruction set.  But, it only had 4 registers. I recall after having coded for a time on a Model 40, being offered access to a Model 20 and saying "What the hell is this?" Well, at least you had many of the SS instructions. --===============2321539392627406724==-- From sqrfolkdnc@comcast.net Wed Apr 10 15:44:35 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 10:44:29 -0500 Message-ID: <623153818.1486570.1712763869185@connect.xfinity.com> In-Reply-To: <796402ae-48f9-35a9-233e-5f9dff7a1bb7@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0512789432808746650==" --===============0512789432808746650== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable hmmm, now that you say that, it sounds familiar. was it the model 40 that co= uld do 1620 emulation then? 
--Carey
> On 04/10/2024 10:25 AM CDT Jon Elson via cctalk w= rote: >=20 > =20 > On 4/10/24 07:18, CAREY SCHUG via cctalk wrote: > > Nearly all the 360s were microcoded, so adding a bit more microcode let t= hem emulate 1400/7000 series computers as a standard optional feature. (well = the model 44 emulated the 1620, and probably the 95/195 could not emulate any= thing since they were hard wired). > > > The model 44 was not microcoded.=C2=A0 It had faster floating=20 > point than a model /50 but no decimal or string=20 > instructions.=C2=A0 Emulation of these was done through trap=20 > handlers.=C2=A0 I would assume any other machine emulators were=20 > done by something like an emulation wrapper program - like=20 > Virtualbox or VMware.=C2=A0 The model 44 had no channels, there=20 > was only direct I/O (a set of 32-bit parallel input and=20 > output registers) and a pair of cartridge hard drives inside=20 > the CPU cabinet.=C2=A0 Think DEC RK05s. >=20 > Jon --===============0512789432808746650==-- From cclist@sydex.com Wed Apr 10 16:19:19 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 09:19:06 -0700 Message-ID: <6dcc975e-fa03-4e83-a14c-0ab06df24f90@sydex.com> In-Reply-To: <882f3bc7-7a13-8ee6-d666-0c04fcfe7ea9@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9057252523632613638==" --===============9057252523632613638== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/10/24 08:17, Jon Elson via cctalk wrote: > The 360/20 had only halfword instructions, no float, no char strings.  > But, main storage was 16 bits wide. > I'm not quite sure what you mean by "char strings", but SS instructions MVC, MVN, MVZ, CLC, ED, TR were in the set, (but not, say, TRT, EDMK, etc.) Then there was the much-maligned (probably with reason) MFCM 2560 card mulcher. --Chuck --===============9057252523632613638==-- From paulkoning@comcast.net Wed Apr 10 16:47:58 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 12:47:50 -0400 Message-ID: <091AE633-E075-4C9D-8E7A-3BDA51A26D36@comcast.net> In-Reply-To: <796402ae-48f9-35a9-233e-5f9dff7a1bb7@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4511330074642944962==" --===============4511330074642944962== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 10, 2024, at 11:25 AM, Jon Elson via cctalk wrote: >=20 > On 4/10/24 07:18, CAREY SCHUG via cctalk wrote: >> Nearly all the 360s were microcoded, so adding a bit more microcode let th= em emulate 1400/7000 series computers as a standard optional feature. (well t= he model 44 emulated the 1620, and probably the 95/195 could not emulate anyt= hing since they were hard wired). >>=20 > The model 44 was not microcoded. It had faster floating point than a model= /50 but no decimal or string instructions. Emulation of these was done thro= ugh trap handlers. I would assume any other machine emulators were done by s= omething like an emulation wrapper program - like Virtualbox or VMware. The = model 44 had no channels, there was only direct I/O (a set of 32-bit parallel= input and output registers) and a pair of cartridge hard drives inside the C= PU cabinet. Think DEC RK05s. No channels? That doesn't sound right. The 360/44 I used certain had an RK0= 5-like drive in the CPU cabinet (I only remember one, though). I'm fairly su= re it was a 16-sector pack, so more like an RK08. But the system ran both OS= /360 and TSO, and had three 2311 disk drives, three tape drives (with an amaz= ingly ugly mechanical design), a card reader/punch, and a line printer. Also= some sort of terminal max, but I never used the timesharing feature so I don= 't know what that involved. It certainly had enough of a channel-like I/O system that the emulator progra= m loader could be implemented in a card reader channel program no different f= rom that of other 360s. I remember quite well deciphering it using the CCW d= ocumentation on the "green card". Yes, the emuation of SS instructions was via traps, but specifically by a tra= p into emulator mode in a separate chunk of memory not visible to the main OS. I never saw the cartridge drive in use by anyone. paul --===============4511330074642944962==-- From sqrfolkdnc@comcast.net Wed Apr 10 17:00:53 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 12:00:47 -0500 Message-ID: <754611820.1489420.1712768447492@connect.xfinity.com> In-Reply-To: <091AE633-E075-4C9D-8E7A-3BDA51A26D36@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0847347112689232289==" --===============0847347112689232289== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I thought you could get regular channels as an optional feature? 
--Carey
> On 04/10/2024 11:47 AM CDT Paul Koning via cctalk = wrote: >=20 > =20 > > On Apr 10, 2024, at 11:25 AM, Jon Elson via cctalk wrote: > >=20 ... > >>=20 > > ... The model 44 had no channels, there was only direct I/O (a set of 32= -bit parallel input and output registers) and a pair of cartridge hard drives= inside the CPU cabinet. Think DEC RK05s. >=20 > No channels? That doesn't sound right. The 360/44 I used certain had an R= K05-like drive in the CPU cabinet (I only remember one, though). I'm fairly = sure it was a 16-sector pack, so more like an RK08. But the system ran both = OS/360 and TSO, and had three 2311 disk drives, three tape drives (with an am= azingly ugly mechanical design), a card reader/punch, and a line printer. Al= so some sort of terminal max, but I never used the timesharing feature so I d= on't know what that involved. >=20 > It certainly had enough of a channel-like I/O system that the emulator prog= ram loader could be implemented in a card reader channel program no different= from that of other 360s. I remember quite well deciphering it using the CCW= documentation on the "green card". >=20 > Yes, the emulation of SS instructions was via traps, but specifically by a = trap into emulator mode in a separate chunk of memory not visible to the main= OS. >=20 > I never saw the cartridge drive in use by anyone. >=20 > paul --===============0847347112689232289==-- From elson@pico-systems.com Wed Apr 10 17:20:58 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 12:20:50 -0500 Message-ID: In-Reply-To: <6dcc975e-fa03-4e83-a14c-0ab06df24f90@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1267457209990781006==" --===============1267457209990781006== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/10/24 11:19, Chuck Guzis via cctalk wrote: > On 4/10/24 08:17, Jon Elson via cctalk wrote: > >> The 360/20 had only halfword instructions, no float, no char strings. >> But, main storage was 16 bits wide. >> > I'm not quite sure what you mean by "char strings", but SS instructions > MVC, MVN, MVZ, CLC, ED, TR were in the set, (but not, say, TRT, EDMK, etc.) OK, never worked on one, I did actually see one in a tour once. So, there's a lot I don't know about the /20.  Thanks for the correction. Jon --===============1267457209990781006==-- From paulkoning@comcast.net Wed Apr 10 17:24:03 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 and 1400 series emulation Date: Wed, 10 Apr 2024 13:23:56 -0400 Message-ID: <1F3A88C1-0B57-4C20-891F-AD2C004BC6CF@comcast.net> In-Reply-To: <754611820.1489420.1712768447492@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1106345008706274758==" --===============1106345008706274758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don't know if it was an option. If so, presumably it was included if you e= lected the emulator option, since both are intended for running OS/360. paul > On Apr 10, 2024, at 1:00 PM, CAREY SCHUG via cctalk wrote: >=20 > I thought you could get regular channels as an optional feature? >=20 > 
--Carey
>=20 >> On 04/10/2024 11:47 AM CDT Paul Koning via cctalk wrote: >>=20 >>=20 >>> On Apr 10, 2024, at 11:25 AM, Jon Elson via cctalk wrote: >>>=20 > ... >>>>=20 >>> ... The model 44 had no channels, there was only direct I/O (a set of 32= -bit parallel input and output registers) and a pair of cartridge hard drives= inside the CPU cabinet. Think DEC RK05s. >>=20 >> No channels? That doesn't sound right. The 360/44 I used certain had an = RK05-like drive in the CPU cabinet (I only remember one, though). I'm fairly= sure it was a 16-sector pack, so more like an RK08. But the system ran both= OS/360 and TSO, and had three 2311 disk drives, three tape drives (with an a= mazingly ugly mechanical design), a card reader/punch, and a line printer. A= lso some sort of terminal max, but I never used the timesharing feature so I = don't know what that involved. >>=20 >> It certainly had enough of a channel-like I/O system that the emulator pro= gram loader could be implemented in a card reader channel program no differen= t from that of other 360s. I remember quite well deciphering it using the CC= W documentation on the "green card". >>=20 >> Yes, the emulation of SS instructions was via traps, but specifically by a= trap into emulator mode in a separate chunk of memory not visible to the mai= n OS. >>=20 >> I never saw the cartridge drive in use by anyone. >>=20 >> paul --===============1106345008706274758==-- From cclist@sydex.com Wed Apr 10 17:52:30 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 10:52:17 -0700 Message-ID: <6a732e05-07dc-46e5-94a6-c5c8319cab42@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1476142037643932351==" --===============1476142037643932351== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/10/24 10:20, Jon Elson via cctalk wrote: > OK, never worked on one, I did actually see one in a tour once. So, > there's a lot I don't know about the /20.  Thanks for the correction. In point of fact, given the constraints posed by the small register file and lack of instructions, the primary way to do math on the 2020 was the SS decimal instructions. At least there you had multiply and divide instructions. That sort of figures, given that the object of the 2020 was to replace a lot of the 1401 gear. That's one of the reasons that many don't consider it to be proper member of S/360. In the 1970s, I recall that the USAF Logistics Command was running their old 7080 COBOL-with-Autocoder patches on S/370 gear. When visiting AFLC at Wright-Paterson then, I do recall seeing at least 2 7080s still functioning. It was explained to me that very few of those GSA programmers knew how much of the old system really functioned, so emulation was a logical step. Wasn't the California DMV in a similar situation for years? --Chuck --===============1476142037643932351==-- From seefriek@gmail.com Wed Apr 10 18:13:03 2024 From: Ken Seefried To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Wed, 10 Apr 2024 14:12:47 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CLO0P265MB5859AF6928CCD30C393D7938F0302=40LO0P265MB?= =?utf-8?q?5859=2EGBRP265=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4976679460795625503==" --===============4976679460795625503== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > You can list them for whatever you want, and if you are lucky someone might pay it. I always assumed that the eBay listings that sold for obviously ridiculous amounts are money laundering schemes. On Sat, Mar 23, 2024 at 1:15=E2=80=AFPM David Wade via cctalk wrote: > > > -----Original Message----- > > From: Bill Gunshannon via cctalk > > Sent: Saturday, March 23, 2024 3:24 PM > > To: Bill Gunshannon via cctalk > > Cc: Bill Gunshannon > > Subject: [cctalk] Re: Cleanup time again > > > > > > > > On 3/23/2024 11:16 AM, Bill Gunshannon via cctalk wrote: > > > > > > > > > Here's something operators of older systems might find useful. > > > > > > Allied Telesis CentreCOM 210TS Twisted Pair Transciever > > > IEE 802.3 10 BASE-T (MAU) > > > > > > I have 14 used and another 14 still in the box, never been opened. > > > > > > > > > Wow!!! Maybe I should try eBay again. I was going to let > > them go for $20-$25 but I according to google they are listing for $180 > to $250. > > :-) > > > > bill > > You can list them for whatever you want, and if you are lucky someone > might pay it. > On the other hand, the most one has sold for on E-Bay in the past 90 days > is $50 so if you want to sell them $20-$25 seems a good price point.... > .. and there is one currently listed for $9.99... > > https://www.ebay.com/itm/326023934007 > > ... I think I paid around $30 for the last one I bought but it was a while > ago... > > Dave > G4UGM > --===============4976679460795625503==-- From van.snyder@sbcglobal.net Wed Apr 10 20:03:44 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 13:03:36 -0700 Message-ID: <3742edbbc0464444f18311d0155ee63fb162b849.camel@sbcglobal.net> In-Reply-To: <145869550.1478027.1712738724194@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8947398249268654883==" --===============8947398249268654883== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2024-04-10 at 03:45 -0500, CAREY SCHUG via cctalk wrote: > you could also use the console to run 1401 emulation without DOS (i > think 2 options, one loaded in card deck, then allowed typing in > config, otherwise just turn dials and store stuff into memory. After loading the Compatibility Initialization Deck or CID, a 1401 program could be run from cards by putting 1402 into the IPA dials, or from tape by putting 1729 into the IPA dials, and pushing IPL. The IPA was, IIRC, the address in the microcode. --===============8947398249268654883==-- From osi.superboard@gmail.com Wed Apr 10 20:28:43 2024 From: "osi.superboard" To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 21:28:28 +0100 Message-ID: <900c7a6c-e9a6-4046-b5c5-c855c3caa9df@gmail.com> In-Reply-To: <882f3bc7-7a13-8ee6-d666-0c04fcfe7ea9@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5887322250876321520==" --===============5887322250876321520== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, 1964, amazing. I remember, I must have some vintage IBM=20 training/instruction materials on the 360, 704 and FORTRAN programming=20 systems. This came from a long time computer professor who took these=20 courses in the early 1960s, Dr. William (Bill) M. Myers (University of=20 Montana) It's a massive binder and contains hundreds of pages of official IBM=20 information, charts, brochures and notes. In very good condition, and=20 with original training documents for Northrop Aircraft Inc. in 1966. see: https://drive.google.com/drive/folders/1AwfIo3_FrdkRsD4Qz3X8aiNAdm1D1buj?usp= =3Dsharing It also shows a full IBM system introduction handbook and Quick=20 Reference manual form 1964. Check out the Northrop News-Venture Edition 1966 Northrop Aircraft Inc.=20 article on installation of an IBM360/64 system, where the training took=20 place. As I 'm not so much into the System/360 and FORTRAN IV, if anyone is=20 interested, please let me know. Thomas On 10.04.2024 16:17, Jon Elson via cctalk wrote: > On 4/10/24 01:51, Van Snyder via cctalk wrote: >> On Tue, 2024-04-09 at 22:21 -0700, Chuck Guzis via cctalk wrote: >>> On 4/9/24 22:03, ben via cctalk wrote: >>>> On 2024-04-09 8:53 p.m., Murray McCullough via cctalk wrote: >>>>> I had not realized the IBM 360 was 60 yrs. old this month. I >>>>> worked on >>>>> such >>>>> a computer in the late 60s in Toronto. What one could do with 8 >>>>> Kbytes of >>>>> ram was remarkable! >>>>> >>>>> Happy computing >>>>> >>>>> Murray =F0=9F=99=82 >>>> Real time sharing, not a 16K PDP 8? >>> What model of a 360?=C2=A0 8K sounds a lot like a Model 20, which the >>> purists >>> may not consider to be a "real" member of the family. >> I don't remember whether it was one of the docents at Haus zur >> Geschichte der IBM Datenverarbeitung at Sindelfingen, or at the >> Computer History Museum at Mountain View, who told me that IBM was >> developing a machine to be designated 1480, as part of the 1401-1440- >> 1460-1410 series, with newer technology, roughly contemporaneously with >> the 360. When IBM decided to put all its eggs in the 360 basket, The >> 1480 team somehow survived and produced either the 360/20 or 360/25. An >> 8k machine would be a bit weird in this series, since 1410 was already >> 100k. Does anybody know more details about this? > > The 360/20 had only halfword instructions, no float, no char strings.=C2=A0= =20 > But, main storage was 16 bits wide. > > The 360/30 only had byte-wide memory, and the register file was in a=20 > separately addressed part of main storage.=C2=A0 The 360/25 was a very=20 > interesting concept.=C2=A0 The microcode was in the top 16 KB of main=20 > storage, and 360 and other instruction set emulations could be loaded=20 > from cards.=C2=A0 The boot loader for the emulators was in the top 16 bytes= =20 > (or maybe words) of main storage. > > Jon > --===============5887322250876321520==-- From van.snyder@sbcglobal.net Wed Apr 10 20:52:56 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 13:52:43 -0700 Message-ID: <3f5b5d8ab726974777262d48b5abe570850c7a54.camel@sbcglobal.net> In-Reply-To: <882f3bc7-7a13-8ee6-d666-0c04fcfe7ea9@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2735471741383686871==" --===============2735471741383686871== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2024-04-10 at 10:17 -0500, Jon Elson via cctalk wrote: > The > 360/25 was a very interesting concept. The microcode was in > the top 16 KB of main storage, 360/30 microcode was in capacitive ROM, implemented using standard-size punch cards with little metal rectangles that could be punched out to make zeroes, sandwiched into metal backplanes. I remember a CE coming out, running a few cards through a 026 to dup them, then installing them. He didn't say whether he was repairing bugs in the 360 instruction set, or the 1401 emulation. --===============2735471741383686871==-- From van.snyder@sbcglobal.net Wed Apr 10 20:56:30 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 13:56:20 -0700 Message-ID: <60f3621f76ef62e253df8c52707f91ab7bbd9410.camel@sbcglobal.net> In-Reply-To: <900c7a6c-e9a6-4046-b5c5-c855c3caa9df@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0655400521316241060==" --===============0655400521316241060== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 2024-04-10 at 21:28 +0100, osi.superboard via cctalk wrote: > Yes, 1964, amazing. I remember, I must have some vintage IBM > training/instruction materials on the 360, 704 and FORTRAN > programming systems. This came from a long time computer professor > who took these courses in the early 1960s, Dr. William (Bill) M. > Myers (University of Montana)It's a massive binder and contains > hundreds of pages of official IBM information, charts, brochures and > notes. In very good condition, and with original training documents > for Northrop Aircraft Inc. in 1966.see: > https://drive.google.com/drive/folders/1AwfIo3_FrdkRsD4Qz3X8aiNAdm1D1buj?us= p=3Dsharing > It also shows a full IBM system introduction handbook and Quick > Reference manual form 1964.Check out the Northrop News-Venture > Edition 1966 Northrop Aircraft Inc. article on installation of an > IBM360/64 system, where the training took place. > As I 'm not so much into the System/360 and FORTRAN IV, if anyone is > interested, please let me know. There's a good chance that the Computer History Museum would want these documents. Ask Dag Spicer < spicer(a)computerhistory.org> --===============0655400521316241060==-- From van.snyder@sbcglobal.net Wed Apr 10 21:01:09 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 14:01:00 -0700 Message-ID: In-Reply-To: <900c7a6c-e9a6-4046-b5c5-c855c3caa9df@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5169303101688197799==" --===============5169303101688197799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2024-04-10 at 21:28 +0100, osi.superboard via cctalk wrote: > Check out the Northrop News-Venture Edition 1966 Northrop Aircraft Inc. > article on installation of an IBM360/64 system, where the training took > place. When I was a freshman at Caltech, 1964-65, IBM installed a 360 model 63, I think one of only two ever made. After they finished installation, they executed the "Halt and Catch Fire" instruction, then replaced it with a 360/67. I kept using the 7094 until I left during my sophomore year because computer science was dead at Caltech for (at least) ten years after Don Knuth moved to Stanford. I think the 360/67 replaced "Halt and Catch Fire" with "Rewind and Break Tape." --===============5169303101688197799==-- From paulkoning@comcast.net Wed Apr 10 21:23:45 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 17:23:36 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0676933026065952616==" --===============0676933026065952616== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 10, 2024, at 5:01 PM, Van Snyder via cctalk wrote: >=20 > ... > I think the 360/67 replaced "Halt and Catch Fire" with "Rewind and > Break Tape." I always wondered if that wasn't a standard property of IBM tape drives of th= at era. The ones I remember from our 360/44 had capstans that turned continu= ously, one to each side of the head. The tape was shoved against the capstan= to start tape motion, and against a rubber brake block to stop it. That was= wild enough, but the other crazy aspect is that the vacuum columns were arra= nged so the oxide was facing outward, i.e., rubbing against the side walls of= the vacuum column. I never did wear out a tape, but then again, I never used a tape more than a = half dozen times on that system. paul --===============0676933026065952616==-- From bitwiz@12bitsbest.com Wed Apr 10 21:40:16 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 16:40:00 -0500 Message-ID: <9d17f392-1a4e-45a1-b8cc-54d8b2ca211a@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6710640493845805268==" --===============6710640493845805268== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I want to thank you all for this IBM 360 conversation.=C2=A0 It makes me feel= =20 young=F0=9F=99=82.=C2=A0 My first computer was a PDP-8/L with 4K of core memo= ry and a=20 Teletype ASR-33.=C2=A0 That was 1972 (I was 12). On 4/10/2024 4:23 PM, Paul Koning via cctalk wrote: > >> On Apr 10, 2024, at 5:01 PM, Van Snyder via cctalk wrote: >> >> ... >> I think the 360/67 replaced "Halt and Catch Fire" with "Rewind and >> Break Tape." > I always wondered if that wasn't a standard property of IBM tape drives of = that era. The ones I remember from our 360/44 had capstans that turned conti= nuously, one to each side of the head. The tape was shoved against the capst= an to start tape motion, and against a rubber brake block to stop it. That w= as wild enough, but the other crazy aspect is that the vacuum columns were ar= ranged so the oxide was facing outward, i.e., rubbing against the side walls = of the vacuum column. > > I never did wear out a tape, but then again, I never used a tape more than = a half dozen times on that system. > > paul > > --===============6710640493845805268==-- From w2hx@w2hx.com Wed Apr 10 23:14:30 2024 From: W2HX To: cctalk@classiccmp.org Subject: [cctalk] PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 23:14:21 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8611644623117005656==" --===============8611644623117005656== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, I picked up this PDP-11 thing. Can anyone help me understand what it = is? Pictures are here: https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/ I could not find any designation on the backplane. It is a wire-wrappable bac= kplane. I don't know if it is Qbus, unibus or whether it is 18 or 22 bit addr= essing (this is because I am a newbie in this area). There is only one board with a number on it, the M8189 board. I know that is = a fonz-11 board. https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/M8189/ There are two other boards with no designation on them. Does anyone recognize= them? This first one seems to have no "big chips" on it. But it has two connectors = that seem to allow another dual-height card to be plugged into it. What is it? https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/Board1/ The second one has this 50 pin IDC connector on it. Anyone recognize it? https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/Board2/ Any info appreciated! 73 Eugene W2HX My Youtube Channel: https://www.youtube.com/@w2hx/videos --===============8611644623117005656==-- From michael.99.thompson@gmail.com Wed Apr 10 23:33:43 2024 From: Michael Thompson To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 19:33:15 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CBN9PR12MB52765DEBC7F9DEC4866F746BB5062=40BN9PR12MB?= =?utf-8?q?5276=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7855335488257011187==" --===============7855335488257011187== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The backplane says that it is for a PDP-11/03 The chassis is missing the power supply. The M8189 is a PDP-11/23+ KDF11-B PDP-11 CPU The FC202 is a Charles River Data Floppy Diskette board https://shop-pdp.net/~stuff/Pictures/index.php?dslct=3D/CRDS_FC-202_Floppy_Di= sk_Controller&index=3D0&size=3D0&debug=3D0 On Wed, Apr 10, 2024 at 7:14=E2=80=AFPM W2HX via cctalk wrote: > Hi all, I picked up this PDP-11 thing. Can anyone help me understand what > it is? > Pictures are here: > https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/ > > I could not find any designation on the backplane. It is a wire-wrappable > backplane. I don't know if it is Qbus, unibus or whether it is 18 or 22 bit > addressing (this is because I am a newbie in this area). > > There is only one board with a number on it, the M8189 board. I know that > is a fonz-11 board. > https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/M8189/ > > There are two other boards with no designation on them. Does anyone > recognize them? > This first one seems to have no "big chips" on it. But it has two > connectors that seem to allow another dual-height card to be plugged into > it. What is it? > https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/Board1/ > > The second one has this 50 pin IDC connector on it. Anyone recognize it? > https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/Board2/ > > Any info appreciated! > > 73 Eugene W2HX > My Youtube Channel: https://www.youtube.com/@w2hx/videos > > --=20 Michael Thompson --===============7855335488257011187==-- From c.murray.mccullough@gmail.com Wed Apr 10 23:34:46 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 19:34:19 -0400 Message-ID: In-Reply-To: <9d17f392-1a4e-45a1-b8cc-54d8b2ca211a@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1760290018680629188==" --===============1760290018680629188== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable An excellent trip down memory lane. I no longer have the memory and cognitive skills I once had but there are events in my life I still remember and cherish. The first computer I remember working on was the either the PDP-7 or 8(classmates at that time no longer live here in rural Ontario to consult with) at my high-school where the electronics/electrical teacher had in his office. It was a donation from a wealthy benefactor, an alumni, who saw the future and said computers would revolutionize society! Murray =F0=9F=99=82 On Wed, Apr 10, 2024 at 5:40=E2=80=AFPM Mike Katz via cctalk wrote: > I want to thank you all for this IBM 360 conversation. It makes me feel > young=F0=9F=99=82. My first computer was a PDP-8/L with 4K of core memory = and a > Teletype ASR-33. That was 1972 (I was 12). > > On 4/10/2024 4:23 PM, Paul Koning via cctalk wrote: > > > >> On Apr 10, 2024, at 5:01 PM, Van Snyder via cctalk < > cctalk(a)classiccmp.org> wrote: > >> > >> ... > >> I think the 360/67 replaced "Halt and Catch Fire" with "Rewind and > >> Break Tape." > > I always wondered if that wasn't a standard property of IBM tape drives > of that era. The ones I remember from our 360/44 had capstans that turned > continuously, one to each side of the head. The tape was shoved against > the capstan to start tape motion, and against a rubber brake block to stop > it. That was wild enough, but the other crazy aspect is that the vacuum > columns were arranged so the oxide was facing outward, i.e., rubbing > against the side walls of the vacuum column. > > > > I never did wear out a tape, but then again, I never used a tape more > than a half dozen times on that system. > > > > paul > > > > > > --===============1760290018680629188==-- From glen.slick@gmail.com Wed Apr 10 23:43:51 2024 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 16:43:35 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CBN9PR12MB52765DEBC7F9DEC4866F746BB5062=40BN9PR12MB?= =?utf-8?q?5276=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4494383154599020882==" --===============4494383154599020882== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2024, 4:14=E2=80=AFPM W2HX via cctalk wrote: > Hi all, I picked up this PDP-11 thing. Can anyone help me understand what > it is? > Pictures are here: > https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/ > > I could not find any designation on the backplane. It is a wire-wrappable > backplane. I don't know if it is Qbus, unibus or whether it is 18 or 22 bit > addressing (this is because I am a newbie in this area). > H9270 Backplane, Page 366 (page 376 of the pdf) http://www.bitsavers.org/pdf/dec/qbus/EB-23144-18_QbusIntrfs_1983.pdf --===============4494383154599020882==-- From ken.unix.guy@gmail.com Thu Apr 11 00:00:46 2024 From: KenUnix To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 20:00:24 -0400 Message-ID: In-Reply-To: <9d17f392-1a4e-45a1-b8cc-54d8b2ca211a@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4249086186203324906==" --===============4249086186203324906== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, Hi. My first "computer" was a PDP-8/I with 4k core, high speed reader/punch and an ASR-33 TTY that was in the early 1970's. I got it used from a lab that was closing for $600.00 delivered. Eventually expanded it to 12k core with 2 DEC tape drives. Loads of fun. DECus came in handy. Ken Martin On Wed, Apr 10, 2024 at 5:40=E2=80=AFPM Mike Katz via cctalk wrote: > I want to thank you all for this IBM 360 conversation. It makes me feel > young=F0=9F=99=82. My first computer was a PDP-8/L with 4K of core memory = and a > Teletype ASR-33. That was 1972 (I was 12). > > On 4/10/2024 4:23 PM, Paul Koning via cctalk wrote: > > > >> On Apr 10, 2024, at 5:01 PM, Van Snyder via cctalk < > cctalk(a)classiccmp.org> wrote: > >> > >> ... > >> I think the 360/67 replaced "Halt and Catch Fire" with "Rewind and > >> Break Tape." > > I always wondered if that wasn't a standard property of IBM tape drives > of that era. The ones I remember from our 360/44 had capstans that turned > continuously, one to each side of the head. The tape was shoved against > the capstan to start tape motion, and against a rubber brake block to stop > it. That was wild enough, but the other crazy aspect is that the vacuum > columns were arranged so the oxide was facing outward, i.e., rubbing > against the side walls of the vacuum column. > > > > I never did wear out a tape, but then again, I never used a tape more > than a half dozen times on that system. > > > > paul > > > > > > --=20 End of line JOB TERMINATED --===============4249086186203324906==-- From w2hx@w2hx.com Thu Apr 11 00:07:58 2024 From: W2HX To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Thu, 11 Apr 2024 00:07:49 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5528108666956468522==" --===============5528108666956468522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Great! thank you Glen and also Michael T. for the identifications.=20 So this appears to be a PDP-11/23 with this FC-202 floppy controller.=20 1. I have read that the card and the drives were compatible with the dec rx02= drives. Why would the CRDS even bother to redesign a card where DEC had perf= ectly good working ones? Anyone know if there is any value in keeping the FC-= 202 or just keep with the DEC cards? 2. Any idea on that other card? https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-1= 1-Thing/Board1/ Thanks guys! 73 Eugene W2HX My Youtube Channel:=C2=A0https://www.youtube.com/@w2hx/videos =20 -----Original Message----- From: Glen Slick via cctalk =20 Sent: Wednesday, April 10, 2024 7:44 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Glen Slick Subject: [cctalk] Re: PDP-11 thingy. What is it? On Wed, Apr 10, 2024, 4:14=E2=80=AFPM W2HX via cctalk wrote: > Hi all, I picked up this PDP-11 thing. Can anyone help me understand=20 > what it is? > Pictures are here: > https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/ > > I could not find any designation on the backplane. It is a=20 > wire-wrappable backplane. I don't know if it is Qbus, unibus or=20 > whether it is 18 or 22 bit addressing (this is because I am a newbie in thi= s area). > H9270 Backplane, Page 366 (page 376 of the pdf) http://www.bitsavers.org/pdf/dec/qbus/EB-23144-18_QbusIntrfs_1983.pdf --===============5528108666956468522==-- From lists@glitchwrks.com Thu Apr 11 00:35:23 2024 From: Jonathan Chapman To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Thu, 11 Apr 2024 00:35:04 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB52692F418F9BA8B1B1A60712B5052=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5824245670019679639==" --===============5824245670019679639== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > 1. I have read that the card and the drives were compatible with the dec rx= 02 drives. Why would the CRDS even bother to redesign a card where DEC had pe= rfectly good working ones? Anyone know if there is any value in keeping the F= C-202 or just keep with the DEC cards? A lot of the third-party controllers could talk to Shugart-style 8" floppy dr= ives. They can also usually *format* the diskettes, which the RX01/RX02 syste= ms from DEC can't do -- you have to use preformatted media. This isn't a *hug= e* deal since RX01 is just IBM 3740 and you can format it on CP/M boxes, with= ImageDisk, etc. There's an XXDP utility to upconvert RX01 media to RX02, whi= ch is M2FM and very few things can work with it. Apparently a lot of small shops kept a CP/M box just for the task, the Alspa = ACI-2 I had was supposedly used like that. > 2. Any idea on that other card? https://w2hx.com/?prefix=3Dx/What-Is-It/PDP= -11-Thing/Board1/ Looks like a non-DEC Qniverter -- QBus to Unibus converter. If that's what it= is, you'd plug your Unibus cable into that pair of connectors on top and run= it to whatever Unibus device you were wanting to talk to, potentially anothe= r backplane full of Unibus stuff. Commonish upgrade on e.g. CNC machines that= were originally controlled by a PDP-11/05 or something in one Unibus chassis= , with another Unibus chassis full of machine-specific cards. Thanks, Jonathan --===============5824245670019679639==-- From billdegnan@gmail.com Thu Apr 11 01:31:57 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 21:31:40 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CjB-7bDQHn-xrPdpzSRSQMSnTRMdR=5FnTFabBJPJ16a4P-sfSh?= =?utf-8?q?tM-Ucxq0q88dT9N5r2mIAZAk=5FHVQnC5bUe9OWUjZdOYBB5idfkkxPFi9I68=3D?= =?utf-8?q?=40glitchwrks=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0405321123322829763==" --===============0405321123322829763== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Apr 10, 2024 at 8:35 PM Jonathan Chapman via cctalk < cctalk(a)classiccmp.org> wrote: > > 1. I have read that the card and the drives were compatible with the dec > rx02 drives. Why would the CRDS even bother to redesign a card where DEC > had perfectly good working ones? Anyone know if there is any value in > keeping the FC-202 or just keep with the DEC cards? > > A lot of the third-party controllers could talk to Shugart-style 8" floppy > drives. They can also usually *format* the diskettes, which the RX01/RX02 > systems from DEC can't do -- you have to use preformatted media. This isn't > a *huge* deal since RX01 is just IBM 3740 and you can format it on CP/M > boxes, with ImageDisk, etc. There's an XXDP utility to upconvert RX01 media > to RX02, which is M2FM and very few things can work with it. > > Apparently a lot of small shops kept a CP/M box just for the task, the > Alspa ACI-2 I had was supposedly used like that. > > > 2. Any idea on that other card? > https://w2hx.com/?prefix=x/What-Is-It/PDP-11-Thing/Board1/ > > Looks like a non-DEC Qniverter -- QBus to Unibus converter. If that's what > it is, you'd plug your Unibus cable into that pair of connectors on top and > run it to whatever Unibus device you were wanting to talk to, potentially > another backplane full of Unibus stuff. Commonish upgrade on e.g. CNC > machines that were originally controlled by a PDP-11/05 or something in one > Unibus chassis, with another Unibus chassis full of machine-specific cards. > > Thanks, > Jonathan > Very cool. b --===============0405321123322829763==-- From kantexplain@protonmail.com Thu Apr 11 01:51:50 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] oddity or just early 5160 mobo? Date: Thu, 11 Apr 2024 01:51:34 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8593736303394157813==" --===============8593736303394157813== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I sort of doubt any of these boards were factory supplied this way, but the d= ate codes on the ram in question are consistent with most other ics . the oth= er banks contain chips that are months older, or newer. 64-256KB SYSTEM BOARD 18 TI gold capped 4164-20 chips in banks 0 and 1. Mix of Fujitsu, TI, NEC chips in banks 2 and 3. There are a half dozen numeric codes present on the board. I don't know what = any signify. --===============8593736303394157813==-- From ce.murillosanchez@gmail.com Thu Apr 11 02:22:26 2024 From: Carlos E Murillo-Sanchez To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 21:22:17 -0500 Message-ID: <89323ef8-c1fd-7023-0fd0-ff641e7736c7@gmail.com> In-Reply-To: =?utf-8?q?=3CjB-7bDQHn-xrPdpzSRSQMSnTRMdR=5FnTFabBJPJ16a4P-sfSh?= =?utf-8?q?tM-Ucxq0q88dT9N5r2mIAZAk=5FHVQnC5bUe9OWUjZdOYBB5idfkkxPFi9I68=3D?= =?utf-8?q?=40glitchwrks=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1740207076529502328==" --===============1740207076529502328== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jonathan Chapman via cctalk wrote: >> 1. I have read that the card and the drives were compatible with the dec r= x02 drives. Why would the CRDS even bother to redesign a card where DEC had p= erfectly good working ones? Anyone know if there is any value in keeping the = FC-202 or just keep with the DEC cards? > A lot of the third-party controllers could talk to Shugart-style 8" floppy = drives. They can also usually *format* the diskettes, which the RX01/RX02 sys= tems from DEC can't do -- you have to use preformatted media. This isn't a *h= uge* deal since RX01 is just IBM 3740 and you can format it on CP/M boxes, wi= th ImageDisk, etc. There's an XXDP utility to upconvert RX01 media to RX02, w= hich is M2FM and very few things can work with it. > > Apparently a lot of small shops kept a CP/M box just for the task, the Alsp= a ACI-2 I had was supposedly used like that. > >> 2. Any idea on that other card? https://w2hx.com/?prefix=3Dx/What-Is-It/PD= P-11-Thing/Board1/ > Looks like a non-DEC Qniverter -- QBus to Unibus converter. If that's what = it is, you'd plug your Unibus cable into that pair of connectors on top and r= un it to whatever Unibus device you were wanting to talk to, potentially anot= her backplane full of Unibus stuff. Commonish upgrade on e.g. CNC machines th= at were originally controlled by a PDP-11/05 or something in one Unibus chass= is, with another Unibus chassis full of machine-specific cards. > > Thanks, > Jonathan > . > I spy two AM2901 4-bit slice ALUs, two N82S181 1024x8 PROMs, three=20 AM2911 microprogram sequencers, and an SN74150 3-to-8 line decoder. This=20 thing is doing arithmetic. Carlos. --===============1740207076529502328==-- From glen.slick@gmail.com Thu Apr 11 02:37:44 2024 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 19:37:28 -0700 Message-ID: In-Reply-To: <89323ef8-c1fd-7023-0fd0-ff641e7736c7@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8746207573262958005==" --===============8746207573262958005== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Apr 10, 2024, 7:22 PM Carlos E Murillo-Sanchez via cctalk < cctalk(a)classiccmp.org> wrote: > Jonathan Chapman via cctalk wrote: > >> 1. I have read that the card and the drives were compatible with the > dec rx02 drives. Why would the CRDS even bother to redesign a card where > DEC had perfectly good working ones? Anyone know if there is any value in > keeping the FC-202 or just keep with the DEC cards? > > A lot of the third-party controllers could talk to Shugart-style 8" > floppy drives. They can also usually *format* the diskettes, which the > RX01/RX02 systems from DEC can't do -- you have to use preformatted media. > This isn't a *huge* deal since RX01 is just IBM 3740 and you can format it > on CP/M boxes, with ImageDisk, etc. There's an XXDP utility to upconvert > RX01 media to RX02, which is M2FM and very few things can work with it. > > > > Apparently a lot of small shops kept a CP/M box just for the task, the > Alspa ACI-2 I had was supposedly used like that. > > > >> 2. Any idea on that other card? > https://w2hx.com/?prefix=x/What-Is-It/PDP-11-Thing/Board1/ > > Looks like a non-DEC Qniverter -- QBus to Unibus converter. If that's > what it is, you'd plug your Unibus cable into that pair of connectors on > top and run it to whatever Unibus device you were wanting to talk to, > potentially another backplane full of Unibus stuff. Commonish upgrade on > e.g. CNC machines that were originally controlled by a PDP-11/05 or > something in one Unibus chassis, with another Unibus chassis full of > machine-specific cards. > > > > Thanks, > > Jonathan > > . > > > I spy two AM2901 4-bit slice ALUs, two N82S181 1024x8 PROMs, three > AM2911 microprogram sequencers, and an SN74150 3-to-8 line decoder. This > thing is doing arithmetic. > > Carlos. That is not an unusual bit slice architecture for a drive controller. This Dilog DQ419 also has two AM2901 ALUs and three AM2911 sequencers, and what appears to be six microcode PROMs. https://avitech.com.au/?page_id=847 --===============8746207573262958005==-- From ce.murillosanchez@gmail.com Thu Apr 11 04:36:51 2024 From: Carlos E Murillo-Sanchez To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Wed, 10 Apr 2024 23:36:44 -0500 Message-ID: <2e95568e-0f78-db16-4872-7ef7978bd057@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8290562433796511838==" --===============8290562433796511838== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Glen Slick via cctalk wrote: > On Wed, Apr 10, 2024, 7:22 PM Carlos E Murillo-Sanchez via cctalk < > cctalk(a)classiccmp.org> wrote: > >> Jonathan Chapman via cctalk wrote: >>>> 1. I have read that the card and the drives were compatible with the >> dec rx02 drives. Why would the CRDS even bother to redesign a card where >> DEC had perfectly good working ones? Anyone know if there is any value in >> keeping the FC-202 or just keep with the DEC cards? >>> A lot of the third-party controllers could talk to Shugart-style 8" >> floppy drives. They can also usually *format* the diskettes, which the >> RX01/RX02 systems from DEC can't do -- you have to use preformatted media. >> This isn't a *huge* deal since RX01 is just IBM 3740 and you can format it >> on CP/M boxes, with ImageDisk, etc. There's an XXDP utility to upconvert >> RX01 media to RX02, which is M2FM and very few things can work with it. >>> Apparently a lot of small shops kept a CP/M box just for the task, the >> Alspa ACI-2 I had was supposedly used like that. >>>> 2. Any idea on that other card? >> https://w2hx.com/?prefix=x/What-Is-It/PDP-11-Thing/Board1/ >>> Looks like a non-DEC Qniverter -- QBus to Unibus converter. If that's >> what it is, you'd plug your Unibus cable into that pair of connectors on >> top and run it to whatever Unibus device you were wanting to talk to, >> potentially another backplane full of Unibus stuff. Commonish upgrade on >> e.g. CNC machines that were originally controlled by a PDP-11/05 or >> something in one Unibus chassis, with another Unibus chassis full of >> machine-specific cards. >>> Thanks, >>> Jonathan >>> . >>> >> I spy two AM2901 4-bit slice ALUs, two N82S181 1024x8 PROMs, three >> AM2911 microprogram sequencers, and an SN74150 3-to-8 line decoder. This >> thing is doing arithmetic. >> >> Carlos. > > That is not an unusual bit slice architecture for a drive controller. > > This Dilog DQ419 also has two AM2901 ALUs and three AM2911 sequencers, and > what appears to be six microcode PROMs. > > https://avitech.com.au/?page_id=847 How interesting, thanks! The knowledge in this list never ceases to amaze me. Carlos. --===============8290562433796511838==-- From sqrfolkdnc@comcast.net Thu Apr 11 04:52:57 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 23:52:52 -0500 Message-ID: <305543774.1504423.1712811172492@connect.xfinity.com> In-Reply-To: <3742edbbc0464444f18311d0155ee63fb162b849.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1412425262146577252==" --===============1412425262146577252== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I was an operator (summer job and weekends during college), we had a bunch of= model 30s, each with at least 2 card readers and 2 printers. most work was = BG or F1 running jcl which read in a 1401 program from cards. we also had one model 30 with only 32k memory, usually used for check sortin= g. when not, it sat idle, except I was the only one who read the directions t= o use the switches and could run TWO 1401 emulation jobs on it. 
--Carey
> On 04/10/2024 3:03 PM CDT Van Snyder via cctalk w= rote: >=20 > =20 > On Wed, 2024-04-10 at 03:45 -0500, CAREY SCHUG via cctalk wrote: > > you could also use the console to run 1401 emulation without DOS (i > > think 2 options, one loaded in card deck, then allowed typing in > > config, otherwise just turn dials and store stuff into memory. >=20 > After loading the Compatibility Initialization Deck or CID, a 1401 > program could be run from cards by putting 1402 into the IPA dials, or > from tape by putting 1729 into the IPA dials, and pushing IPL. The IPA > was, IIRC, the address in the microcode. --===============1412425262146577252==-- From joe@barrera.org Thu Apr 11 06:43:08 2024 From: "Joseph S. Barrera III" To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Wed, 10 Apr 2024 23:42:50 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7972050488613083199==" --===============7972050488613083199== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Apr 10, 2024 at 6:36 AM Murray McCullough via cctalk < cctalk(a)classiccmp.org> wrote: > I don’t think I truly realized the seminal work done at IBM then > (60's&70's). *Mandrake:* Well of course the answer to that is, boy, no one ever *does*. --===============7972050488613083199==-- From paulkoning@comcast.net Thu Apr 11 14:00:51 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Thu, 11 Apr 2024 10:00:44 -0400 Message-ID: <4F70A973-403A-42C7-AC3B-540DF9F04004@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1523979051941969604==" --===============1523979051941969604== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 11, 2024, at 2:42 AM, Joseph S. Barrera III via cctalk wrote: >=20 > On Wed, Apr 10, 2024 at 6:36=E2=80=AFAM Murray McCullough via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 >> I don=E2=80=99t think I truly realized the seminal work done at IBM then >> (60's&70's). One interesting historic tidbit is the Dutch connection on the IBM/360. One = of the lead designers on the 360 was Gerrit Blaauw, a Dutch computer engineer= who learned his craft at Harvard (with Aiken), and refined it at the MC in A= msterdam (now CWI) leading the design of several one-off research computers. = Among other things, he taught the other designers that logic needs to be clo= cked to be reliable. :-) After that, he left for IBM and worked on several computer designs, culminati= ng in the 360. Wikipedia says that the choice of 8 bit characters rather tha= n the then-current 6 bits came from him. =20 paul --===============1523979051941969604==-- From jgeorge_cctalk@nbi6.com Thu Apr 11 16:02:34 2024 From: Joe George To: cctalk@classiccmp.org Subject: [cctalk] Re: oddity or just early 5160 mobo? Date: Thu, 11 Apr 2024 11:55:58 -0400 Message-ID: <122BF396-C1D0-4C50-AA23-76F5836686A7@nbi6.com> In-Reply-To: =?utf-8?q?=3CeLqJ7PVxT-3y4JnArlDqlxFppIr=5F77maimnL7-h5kZJ3Mm32?= =?utf-8?q?XVBr=5FFGRY=5Faigrk3htHQQNnTmQi3n479xnCToCx3pV5iwusKAhgnzpfBW5E?= =?utf-8?q?=3D=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3025611840755639590==" --===============3025611840755639590== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Seems logical enough that someone at the time bought a 128K machine and stuff= ed in a bunch of ram chips they may have had laying around at the time. Memor= y was kind of expensive - especially new from IBM. That's totally something I= would have done at the time (and probably did, but it was likely an XT for m= e). Joe > On Apr 10, 2024, at 9:51 PM, Just Kant via cctalk = wrote: >=20 > I sort of doubt any of these boards were factory supplied this way, but the= date codes on the ram in question are consistent with most other ics . the o= ther banks contain chips that are months older, or newer. >=20 > 64-256KB SYSTEM BOARD >=20 > 18 TI gold capped 4164-20 chips in banks 0 and 1. >=20 > Mix of Fujitsu, TI, NEC chips in banks 2 and 3. >=20 > There are a half dozen numeric codes present on the board. I don't know wha= t any signify. --===============3025611840755639590==-- From bill.gunshannon@hotmail.com Thu Apr 11 17:56:31 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 11 Apr 2024 13:55:21 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB573777EB21501CC04FE25F12ED322=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6689524699650176565==" --===============6689524699650176565== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit One last shot. I have an RX Floppy disk unit. Worked fine until one time the last time I had it hooked up and after about an hour it just stopped responding. All I get now is the well known click-click on init and then nothing. I am sure it is repairable either by troubleshooting or just buying another boardset. Anybody interested? I imagine a number of people here will be driving by not far from my home on their way back from VCF. bill --===============6689524699650176565==-- From cisin@xenosoft.com Thu Apr 11 18:01:13 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: 5150 mobo? Date: Thu, 11 Apr 2024 11:01:05 -0700 Message-ID: In-Reply-To: <122BF396-C1D0-4C50-AA23-76F5836686A7@nbi6.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2321982837099707020==" --===============2321982837099707020== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit IIRC, there were two main models of 5150, and a few sub-models. All 5150 were five slot. (5160 (XT) had 8 slots) There was the "16-64KB" that had one row of 4116 soldered in, and three rows of sockets. It could be purchased with those other three rows populated, at a rather high price for 4116s, or could be purchased with those three rows unpopulated. Both Apple2 and TRS80 used 4116s, so the competition had driven the prices way down. Similarly, the Tandon TM100-1 disk drive was available very cheap in the TRS80 after-market. So, the cheapest way into a 5150 was to buy a minimal system, an FDC board, and a CGA video board, and provide your own 4116s, TM100 drives, and a composite monitor. At Merritt College, we had had a PDP11, with an aftermarket drive, being used for not much more than teaching FORTRAN and COBOL. The second time that the machine was down for most of a semester, the college sold it to the Richmond School District (now "West Contra Costa"), and put a few doaen 5150s in its place. While far from comparable, there were never times when there wasn't a computer available for Fortran, COBOL, and then also BASIC. When Richmond installed the machine, something "went wrong", quite likely confusion about delta vs Y three phase power. The official (coverup) story was a "lightning strike" (at that time of year??!?), and PG&E paid for a replacement machine. S, everybody got what they needed. The 5150s were picky about the RAM. Some types of RAM chips would not work in it, although would work fine in Apple, or "memory tester"s. At one point, the college bought some RAM from Fry's, that did not work. But, at the Fry's store, they retested it and insisted there was nothing wrong. We escalated. Fry himself came up to Oakland to bring RAM chips that worked on our 5150s. Then, there was the "64-256KB" motherboard. It had one row of 4164s soldered in, and three rows of sockets. Populating those with 4164s gave you 256K of RAM. BUT, there was an empty socket on the board, that you could populate; I don't know whether it was a PAL or some 74xx logic, that then let you use two rows of 4164s (one row of which was soldered in) and two rows of 41256, giving 640K! 640K was all of the RAM that could be easily used, other than some upper memory space of the other video or bits in between other stuff. We sometimes referred to the two types of motherboards as "16K" and "256K" to lessen ambiguity. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============2321982837099707020==-- From michael.99.thompson@gmail.com Thu Apr 11 18:05:46 2024 From: Michael Thompson To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleanup time again Date: Thu, 11 Apr 2024 14:05:39 -0400 Message-ID: <029D9E4A-7915-4DD2-9BD1-E2C192BC5FFF@gmail.com> In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737CF5BF6FB6B47FD26907DED052=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8661367308022920310==" --===============8661367308022920310== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Clean the connectors and reseat the socketed chips and it will probably work. > On Apr 11, 2024, at 1:55 PM, Bill Gunshannon via cctalk wrote: >=20 >=20 >=20 > One last shot. >=20 > I have an RX Floppy disk unit. Worked fine until one > time the last time I had it hooked up and after about > an hour it just stopped responding. All I get now is > the well known click-click on init and then nothing. I > am sure it is repairable either by troubleshooting or > just buying another boardset. >=20 > Anybody interested? I imagine a number of people here > will be driving by not far from my home on their way back > from VCF. >=20 > bill --===============8661367308022920310==-- From cclist@sydex.com Thu Apr 11 18:21:52 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: 5150 mobo? Date: Thu, 11 Apr 2024 11:21:39 -0700 Message-ID: <12bac889-67ac-4499-86dc-0e7ebb05ea04@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3764681696649294504==" --===============3764681696649294504== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/11/24 11:01, Fred Cisin via cctalk wrote: > Then, there was the "64-256KB" motherboard.  It had one row of 4164s > soldered in, and three rows of sockets.  Populating those with 4164s > gave you 256K of RAM.  BUT, there was an empty socket on the board, that > you could populate; I don't know whether it was a PAL or some 74xx > logic, that then let you use two rows of 4164s (one row of which was > soldered in) and two rows of 41256, giving 640K!  640K was all of the > RAM that could be easily used, other than some upper memory space of the > other video or bits in between other stuff. Bipolar PROM. A few years ago, I published a way for one to use a 22V10 GAL as a substitute to fill in the D000 segment as well as the lower 640K by using 256Kb DRAM. Although the 22V10 is a 24 pin DIP and the PROM being replaced, 16, things could be arranged to let the "tail" end of the 22V10 hang out of the socket and have no changes made to the planar traces themselves. So completely reversible. --Chuck --===============3764681696649294504==-- From van.snyder@sbcglobal.net Thu Apr 11 18:32:29 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Thu, 11 Apr 2024 11:32:19 -0700 Message-ID: <70d15859dc09f81853ab142fe8991843b7ba558d.camel@sbcglobal.net> In-Reply-To: <305543774.1504423.1712811172492@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2068880736218298298==" --===============2068880736218298298== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2024-04-10 at 23:52 -0500, CAREY SCHUG wrote: > I was an operator (summer job and weekends during college), we had a > bunch of model 30s, each with at least 2 card readers and 2 > printers. most work was BG or F1 running jcl which read in a 1401 > program from cards. My boss in my first full-time job had worked at a bank in Dayton, OH. They had an NCR 315, with a device called CRAM, or Card Random Access Machine. That machine used cards the same size as punch cards, but made of mylar and coated with mag-tape oxide. It had a compressed-air-driven mechanism to extract a particular card from a file, drag it through some read-write heads, and put it back. They loved the CRAM sort routines. The machine made a hell of a racket, so they had it in a sound-proof room. An IBM salesman convinced them to try out a 360/30 with a Data Cell. After a month, the salesman came back and noticed the Data Cell in the same sound-proof room as the CRAM. He asked "Why is it in there? It doesn't make any noise!" The answer was "We hope it will learn some software." --===============2068880736218298298==-- From bassmeister3000@gmail.com Thu Apr 11 23:54:54 2024 From: Andre Lewis To: cctalk@classiccmp.org Subject: [cctalk] HP 9825A version of HPL / Roms Date: Thu, 11 Apr 2024 16:54:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3866269447654665983==" --===============3866269447654665983== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howdy all! I'm the new owner if one of the coolest "Calculators" HP ever made. Everything generally works but I would need a new capstan (rubber is now sticky) to use with the tape cartridge. I am running into a hard time tracking down information on using it though, so if anyone can help fill in some gaps, that would be great! I'm looking for: - A manual for HPL, the language used to calculate. Things like for loops don't seem to work, but 'dsp' 'gto' and variable assignment do. - Manuals for any and all of the cartridges, and how to use them - Ideas on replacing the capstan - Ideas on refurbing the tapes (there's a rubber band equivalent to drive the tape on both sides, these have lost their stretch) - Specs for the I/O, as I would love to make custom I/O for it. I would also love to be able to create new cartridges, but I'm not willing to sacrifice any of my existing cartridges to Reverse Engineer them. I have the Plotter / GPIO Cartridge, the Mateix cartridge and the Strings Advanced Programming. Trying to track down an Assembly cartridge or any others. Thanks! Any info is appreciated! ~ Andre --===============3866269447654665983==-- From phb.hfx@gmail.com Fri Apr 12 00:38:51 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Thu, 11 Apr 2024 21:38:42 -0300 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8540863597096564352==" --===============8540863597096564352== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit You will find many manuals for the 9825 at hpmuseum.net  there is a manual for the base machine and manuals for each of the option ROMs.  Usable tapes for the tape drive are very rare and for a 9825A there is only one option for diskettes the 9885.  A machine that says 9825A on the outside may have been upgrades to a 9825B or T, the 9825T model is the most useful as it has the maximum memory and has a lot more options for mass storage.  They are a fun machine I have had a few pass by me, but no longer have one as space constraints dictated I get rid of some of my hardware and I opted to kepp my 9835A. Paul. On 2024-04-11 8:54 p.m., Andre Lewis via cctalk wrote: > Howdy all! > I'm the new owner if one of the coolest "Calculators" HP ever made. > Everything generally works but I would need a new capstan (rubber is now > sticky) to use with the tape cartridge. > > I am running into a hard time tracking down information on using it though, > so if anyone can help fill in some gaps, that would be great! > > I'm looking for: > - A manual for HPL, the language used to calculate. Things like for loops > don't seem to work, but 'dsp' 'gto' and variable assignment do. > - Manuals for any and all of the cartridges, and how to use them > - Ideas on replacing the capstan > - Ideas on refurbing the tapes (there's a rubber band equivalent to drive > the tape on both sides, these have lost their stretch) > - Specs for the I/O, as I would love to make custom I/O for it. > > I would also love to be able to create new cartridges, but I'm not willing > to sacrifice any of my existing cartridges to Reverse Engineer them. > > I have the Plotter / GPIO Cartridge, the Mateix cartridge and the Strings > Advanced Programming. > > Trying to track down an Assembly cartridge or any others. > > Thanks! Any info is appreciated! > > ~ Andre --===============8540863597096564352==-- From phb.hfx@gmail.com Fri Apr 12 00:41:08 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Thu, 11 Apr 2024 21:41:00 -0300 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4565834841706478879==" --===============4565834841706478879== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit You may also wish to join the VintHPcom group on groups.io where a lot of HP 98xx users hang out. Paul. On 2024-04-11 8:54 p.m., Andre Lewis via cctalk wrote: --===============4565834841706478879==-- From kantexplain@protonmail.com Fri Apr 12 01:05:40 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] looking for HP 9836U color monitor Date: Fri, 12 Apr 2024 01:05:28 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4983442148670790369==" --===============4983442148670790369== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Northeast US roughly. --===============4983442148670790369==-- From bassmeister3000@gmail.com Fri Apr 12 04:16:00 2024 From: Andre Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Thu, 11 Apr 2024 21:15:43 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4440528121139583447==" --===============4440528121139583447== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Paul, handy to know! I have a set of tapes that look to be in very good condition, with the exception of the players capstan and the internal tape bands. Mine does also look like it might have been expanded, so I'll see if I can identify any upgrades. Thanks also for the note about the HP list! Regards, Andre On Thu, Apr 11, 2024, 5:48=E2=80=AFPM Paul Berger via cctalk wrote: > You may also wish to join the VintHPcom group on groups.io where a lot > of HP 98xx users hang out. > > Paul. > > On 2024-04-11 8:54 p.m., Andre Lewis via cctalk wrote: > > --===============4440528121139583447==-- From wayne.sudol@hotmail.com Fri Apr 12 04:25:57 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Fri, 12 Apr 2024 04:25:47 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7673027870910733324==" --===============7673027870910733324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For rubber rollers many people swear by Terry=E2=80=99s Rubber Rollers. https://www.terrysrubberrollers.com/ Sent from my iPhone On Apr 11, 2024, at 21:16, Andre Lewis via cctalk w= rote: =EF=BB=BFThanks Paul, handy to know! I have a set of tapes that look to be in very good condition, with the exception of the players capstan and the internal tape bands. Mine does also look like it might have been expanded, so I'll see if I can identify any upgrades. Thanks also for the note about the HP list! Regards, Andre On Thu, Apr 11, 2024, 5:48=E2=80=AFPM Paul Berger via cctalk wrote: You may also wish to join the VintHPcom group on groups.io where a lot of HP 98xx users hang out. Paul. On 2024-04-11 8:54 p.m., Andre Lewis via cctalk wrote: --===============7673027870910733324==-- From organlists1@sonic.net Fri Apr 12 05:12:43 2024 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Thu, 11 Apr 2024 22:12:23 -0700 Message-ID: <918DBBEF-B328-4AD4-A016-BAA08207E764@sonic.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2466067513777069170==" --===============2466067513777069170== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There are several videos about repairs to the 9825 and repairing the tape dri= ve by Marc V. CuriousMarc) on YouTube. Don Resor Sent from someone's iPhone > On Apr 11, 2024, at 9:16 PM, Andre Lewis via cctalk wrote: >=20 > =EF=BB=BFThanks Paul, handy to know! >=20 > I have a set of tapes that look to be in very good condition, with the > exception of the players capstan and the internal tape bands. Mine does > also look like it might have been expanded, so I'll see if I can identify > any upgrades. >=20 > Thanks also for the note about the HP list! >=20 > Regards, > Andre >=20 >> On Thu, Apr 11, 2024, 5:48=E2=80=AFPM Paul Berger via cctalk >> wrote: >>=20 >> You may also wish to join the VintHPcom group on groups.io where a lot >> of HP 98xx users hang out. >>=20 >> Paul. >>=20 >> On 2024-04-11 8:54 p.m., Andre Lewis via cctalk wrote: >>=20 >>=20 >=20 --===============2466067513777069170==-- From bassmeister3000@gmail.com Fri Apr 12 06:35:17 2024 From: Andre Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Thu, 11 Apr 2024 23:34:58 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CMWHPR1001MB219134B65E5BD1D40C2DFFE3E4042=40MWHPR10?= =?utf-8?q?01MB2191=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1509246212346266864==" --===============1509246212346266864== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Excellent! Thanks for the suggestion Wayne! This may be the best option, as the existing one isn't going to an easy fix. For rubber rollers many people swear by Terry’s Rubber Rollers. > https://www.terrysrubberrollers.com/ > > --===============1509246212346266864==-- From lproven@gmail.com Fri Apr 12 09:48:01 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 10:47:45 +0100 Message-ID: In-Reply-To: <70d15859dc09f81853ab142fe8991843b7ba558d.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8283073198314079982==" --===============8283073198314079982== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 11 Apr 2024 at 19:32, Van Snyder via cctalk wrote: > > An IBM salesman convinced them to try out a 360/30 with a Data Cell. No idea what a "data cell" is. I found this: https://www.pcmag.com/encyclopedia/term/data-cell At the Eastercon last week, I met a chap who learned to code on an IBM 1620. He told me of a terrible, terrible storage device which used a robot to load strips of magtape. Cheap but a horrendous failure rate. Is it this thing? -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============8283073198314079982==-- From paulkoning@comcast.net Fri Apr 12 12:31:32 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 08:31:03 -0400 Message-ID: <59FB058B-23A3-4E61-B11E-71FED0BA48AF@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0008580520836283628==" --===============0008580520836283628== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 5:47 AM, Liam Proven via cctalk wrote: >=20 > On Thu, 11 Apr 2024 at 19:32, Van Snyder via cctalk > wrote: >=20 >>=20 >> An IBM salesman convinced them to try out a 360/30 with a Data Cell. >=20 > No idea what a "data cell" is. >=20 > I found this: >=20 > https://www.pcmag.com/encyclopedia/term/data-cell >=20 > At the Eastercon last week, I met a chap who learned to code on an IBM > 1620. He told me of a terrible, terrible storage device which used a > robot to load strips of magtape. Cheap but a horrendous failure rate. > Is it this thing? Yes. See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell . By the sta= ndards of the time it was an unusually high capacity storage device, way fast= er than a room full of tapes and much larger than the 2311 disk drive. paul --===============0008580520836283628==-- From lproven@gmail.com Fri Apr 12 13:48:49 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 14:48:30 +0100 Message-ID: In-Reply-To: <59FB058B-23A3-4E61-B11E-71FED0BA48AF@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3106977909421693478==" --===============3106977909421693478== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 12 Apr 2024 at 13:31, Paul Koning wrote: > Yes. See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell . By the s= tandards of the time it was an unusually high capacity storage device, way fa= ster than a room full of tapes and much larger than the 2311 disk drive. Fascinating. Thank you. It sounds truly awful. A device that effectively tries to push strips of tape into receptacles? --=20 Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============3106977909421693478==-- From paulkoning@comcast.net Fri Apr 12 13:54:18 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 09:53:50 -0400 Message-ID: <4EB981DF-DB0F-457F-B259-4A3124F768C4@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3584576959349330902==" --===============3584576959349330902== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 9:48 AM, Liam Proven via cctalk wrote: >=20 > On Fri, 12 Apr 2024 at 13:31, Paul Koning wrote: >=20 >> Yes. See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell . By the = standards of the time it was an unusually high capacity storage device, way f= aster than a room full of tapes and much larger than the 2311 disk drive. >=20 > Fascinating. Thank you. It sounds truly awful. A device that > effectively tries to push strips of tape into receptacles? I suppose. Or magnetic cards. There were other devices that used magnetic c= ards, like the Olivetti Programma -- world's first programmable calculator. = For that matter, magnetic cards are still around, they are called credit card= s. :-) paul --===============3584576959349330902==-- From sqrfolkdnc@comcast.net Fri Apr 12 13:56:30 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 08:56:01 -0500 Message-ID: <1615078672.1536414.1712930161571@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6652825209115326534==" --===============6652825209115326534== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable No worse than automatic tape loaders that push a long strip of tape trough va= rious feeds and onto a takeup reel where it is made to stick. at least each = of these strips had a handle on it. In later years all serious computer tape drives had autoloaders, and I think = a few for high end consumer tape recorders. 
--Carey
> On 04/12/2024 8:48 AM CDT Liam Proven via cctalk = wrote: >=20 > =20 > On Fri, 12 Apr 2024 at 13:31, Paul Koning wrote: >=20 > > Yes. See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell . By the= standards of the time it was an unusually high capacity storage device, way = faster than a room full of tapes and much larger than the 2311 disk drive. >=20 > Fascinating. Thank you. It sounds truly awful. A device that > effectively tries to push strips of tape into receptacles? >=20 > --=20 > Liam Proven ~ Profile: https://about.me/liamproven > Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com > Twitter/LinkedIn: lproven ~ Skype: liamproven > IoM: (+44) 7624 277612: UK: (+44) 7939-087884 > Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============6652825209115326534==-- From bassmeister3000@gmail.com Fri Apr 12 16:08:39 2024 From: Andre Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: HP 9825A version of HPL / Roms Date: Fri, 12 Apr 2024 09:08:22 -0700 Message-ID: In-Reply-To: <918DBBEF-B328-4AD4-A016-BAA08207E764@sonic.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2978540781433939259==" --===============2978540781433939259== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Ah, ok I'll check into those. Thanks Don! ~ Andre On Thu, Apr 11, 2024, 10:12 PM Don R wrote: > There are several videos about repairs to the 9825 and repairing the tape > drive by Marc V. CuriousMarc) on YouTube. > > Don Resor > > Sent from someone's iPhone > > > On Apr 11, 2024, at 9:16 PM, Andre Lewis via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > Thanks Paul, handy to know! > > > > I have a set of tapes that look to be in very good condition, with the > > exception of the players capstan and the internal tape bands. Mine does > > also look like it might have been expanded, so I'll see if I can identify > > any upgrades. > > > > Thanks also for the note about the HP list! > > > > Regards, > > Andre > > > >> On Thu, Apr 11, 2024, 5:48 PM Paul Berger via cctalk < > cctalk(a)classiccmp.org> > >> wrote: > >> > >> You may also wish to join the VintHPcom group on groups.io where a lot > >> of HP 98xx users hang out. > >> > >> Paul. > >> > >> On 2024-04-11 8:54 p.m., Andre Lewis via cctalk wrote: > >> > >> > > > > --===============2978540781433939259==-- From chris@mainecoon.com Fri Apr 12 16:45:46 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Odd IBM mass storage systems (was: Re: Re: IBM 360) Date: Fri, 12 Apr 2024 09:45:37 -0700 Message-ID: In-Reply-To: <59FB058B-23A3-4E61-B11E-71FED0BA48AF@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4514044255863228513==" --===============4514044255863228513== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/12/24 05:31, Paul Koning via cctalk wrote [snip] > Yes. See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell . By the s= tandards of the time it was an unusually high capacity storage device, way fa= ster than a room full of tapes and much larger than the 2311 disk drive. While on the topic of odd IBM mass storage systems, does anyone recall=20 an IBM system that used rotating carousels holding sheets of magnetic=20 material?=C2=A0 The carousel would rotate to position the selected sheet into= =20 the read/write station, where it would be moved up and down relative to=20 the multiple fixed heads, a weird linear riff on a fixed head disk. LBL had one of these systems, installed in the same room as one of the=20 few examples of the IBM 1360 photo digital storage system. They kept a=20 broom next to the later in order to sweep up the photo chips when the=20 thing occasionally spewed them everywhere. --=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" --===============4514044255863228513==-- From cclist@sydex.com Fri Apr 12 17:28:48 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 10:28:29 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8853980925425174684==" --===============8853980925425174684== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/12/24 09:45, Christian Kennedy via cctalk wrote: > > On 4/12/24 05:31, Paul Koning via cctalk wrote > > [snip] >> Yes.  See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell .  By >> the standards of the time it was an unusually high capacity storage >> device, way faster than a room full of tapes and much larger than the >> 2311 disk drive. > While on the topic of odd IBM mass storage systems, does anyone recall > an IBM system that used rotating carousels holding sheets of magnetic > material?  The carousel would rotate to position the selected sheet into > the read/write station, where it would be moved up and down relative to > the multiple fixed heads, a weird linear riff on a fixed head disk. > > LBL had one of these systems, installed in the same room as one of the > few examples of the IBM 1360 photo digital storage system. They kept a > broom next to the later in order to sweep up the photo chips when the > thing occasionally spewed them everywhere. Isn't that the IBM 2321 Data Cell drive? Having one's files "photostored" at LLL was a chancy proposition. There were bootleg programs to access every file for a user, just to keep them from being consigned to the photostore. --Chuck --===============8853980925425174684==-- From van.snyder@sbcglobal.net Fri Apr 12 17:42:40 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 10:42:31 -0700 Message-ID: <11a22cf34abb37dd344cd0739fe9b083f94275cc.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7041601495752336950==" --===============7041601495752336950== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2024-04-12 at 10:47 +0100, Liam Proven via cctalk wrote: > On Thu, 11 Apr 2024 at 19:32, Van Snyder via cctalk< > cctalk(a)classiccmp.org> wrote: > > An IBM salesman convinced them to try out a 360/30 with a Data > > Cell. > > No idea what a "data cell" is. > I found this: > https://www.pcmag.com/encyclopedia/term/data-cell > > At the Eastercon last week, I met a chap who learned to code on an > IBM1620. He told me of a terrible, terrible storage device which used > arobot to load strips of magtape. Cheap but a horrendous failure > rate.Is it this thing? That's the data cell I mentioned. --===============7041601495752336950==-- From chris@mainecoon.com Fri Apr 12 17:45:22 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 10:45:10 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1649635201504268268==" --===============1649635201504268268== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/12/24 10:28, Chuck Guzis via cctalk wrote: > Isn't that the IBM 2321 Data Cell drive? Same idea, but I recall the cabinets being lower to the floor and the media being more rigid than the 2321 noodles.  Then again, it's been the better part of 50 years, and it could well have been a 2321. Memory rot sucks. > Having one's files "photostored" at LLL was a chancy proposition. There > were bootleg programs to access every file for a user, just to keep them > from being consigned to the photostore. It was chancy at LBL as well.  The mechanical handling of the 1360 photostore cells was something that would have defied the imagination of Rube Goldberg, and chips routinely ended up in places where they didn't belong (although they did make pretty cool bookmarks for my teenage self). -- 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…" --===============1649635201504268268==-- From tom94022@comcast.net Fri Apr 12 18:19:14 2024 From: Tom Gardner To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 11:10:40 -0700 Message-ID: <004801da8d04$bb3b1d10$31b15730$@comcast.net> In-Reply-To: <4EB981DF-DB0F-457F-B259-4A3124F768C4@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7380497372235752496==" --===============7380497372235752496== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Data Cell - Tape, Card or Disk? I'm pretty sure the developers thought of the media of the IBM 2321 as tape rather than cards, although the strips (of tape) were addressed as disk drives (DASD) not tape. It was a mechanical marvel that IMO then (late 60s) only IBM could have successfully built and marketed such a beast. Those interested might want to read the oral history on this machine at https://archive.computerhistory.org/resources/access/text/2013/05/102657934- 05-01-acc.pdf My favorite failure was when they found strips back in the bins but up-side down and backwards - they fixed than and many other problems too and in the end I'm told it was a rather successful product. NCR CRAM (Card Random Access Memory) truly considered magnetic cards as the media, see https://www.computerhistory.org/brochures/m-p/national-cash-register-company -ncr/ Tom -----Original Message----- From: Paul Koning Sent: Friday, April 12, 2024 6:54 AM To: cctalk(a)classiccmp.org Subject: [cctalk] Re: IBM 360 > On Apr 12, 2024, at 9:48 AM, Liam Proven via cctalk wrote: > > On Fri, 12 Apr 2024 at 13:31, Paul Koning wrote: > >> Yes. See also https://en.wikipedia.org/wiki/IBM_2321_Data_Cell . By the standards of the time it was an unusually high capacity storage device, way faster than a room full of tapes and much larger than the 2311 disk drive. > > Fascinating. Thank you. It sounds truly awful. A device that > effectively tries to push strips of tape into receptacles? I suppose. Or magnetic cards. There were other devices that used magnetic cards, like the Olivetti Programma -- world's first programmable calculator. For that matter, magnetic cards are still around, they are called credit cards. :-) paul --===============7380497372235752496==-- From phb.hfx@gmail.com Fri Apr 12 18:28:45 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 15:28:34 -0300 Message-ID: <1f4b6015-30e7-459a-ac60-bb2300aed532@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7621279255506678828==" --===============7621279255506678828== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-12 2:45 p.m., Christian Kennedy via cctalk wrote: > > On 4/12/24 10:28, Chuck Guzis via cctalk wrote: >> Isn't that the IBM 2321 Data Cell drive? > > Same idea, but I recall the cabinets being lower to the floor and the > media being more rigid than the 2321 noodles.  Then again, it's been > the better part of 50 years, and it could well have been a 2321. > > Memory rot sucks. > >> Having one's files "photostored" at LLL was a chancy proposition.  There >> were bootleg programs to access every file for a user, just to keep them >> from being consigned to the photostore. > > It was chancy at LBL as well.  The mechanical handling of the 1360 > photostore cells was something that would have defied the imagination > of Rube Goldberg, and chips routinely ended up in places where they > didn't belong (although they did make pretty cool bookmarks for my > teenage self). > The problem with a lot of these old machines was they relied on a lot of electro-mechanical  devices that would today be replaced by electronics and a few simple actuators.  These mechanical devices need to be adjusted and maintained  and have lots of parts to wear out.  While I only started with IBM in 1979 I still got to work on machines that would now be considered electro-mechanical nightmares. The development of the 2321 (announced 1967?) was long and apparently had to overcome a lot of problems, but they apparently soldiered on with it as it was considered a strategic product all for 400,000,000 characters of storage.  The later 3850 (announce 1974) MSS had  much simpler cartridge retrieval system and had storage capacity up to 472 GB.  The capacity of these seems tiny these days but given disk storage at the time, it would take a lot of DASD devices to equal that and the expense would be enormous if you could even fit that many within the reach of channel cables from the system.  Late in the days of copper channels one data center I knew of was spread over three floors, with the CPU on the middle floor and channel attached devices  surrounding it and as far a channel cables could reach on the floors above and below. The 1360 was apparently developed at the request to Atomic Energy Commission (AEC), I  would guess a forerunner of the DOE.   There where apparently only 5 built 3 for the AEC and 2 for the NSA. Paul. --===============7621279255506678828==-- From chris@mainecoon.com Fri Apr 12 18:35:09 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 11:35:03 -0700 Message-ID: <6b738826-883c-4591-ab57-232106bf1a88@mainecoon.com> In-Reply-To: <1f4b6015-30e7-459a-ac60-bb2300aed532@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1184725742821367559==" --===============1184725742821367559== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/12/24 11:28, Paul Berger via cctalk wrote: > > The 1360 was apparently developed at the request to Atomic Energy > Commission (AEC), I  would guess a forerunner of the DOE.   There > where apparently only 5 built 3 for the AEC and 2 for the NSA. IIRC, the 1360 was developed from Walnut, which was developed for the CIA.  The 1360 was a commercial offering, for which they sold one each to LBL and LLL, then two to the NSA and one to LANL. I had heard that some instances remained in service until 1980, being retired only when IBM refused to maintain them. -- 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…" --===============1184725742821367559==-- From paulkoning@comcast.net Fri Apr 12 19:05:08 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 15:04:59 -0400 Message-ID: <04BB9662-C82A-43B2-9F73-24081A527271@comcast.net> In-Reply-To: <1f4b6015-30e7-459a-ac60-bb2300aed532@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6865979942451976102==" --===============6865979942451976102== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 2:28 PM, Paul Berger via cctalk wrote: >=20 >=20 > On 2024-04-12 2:45 p.m., Christian Kennedy via cctalk wrote: >>=20 >> On 4/12/24 10:28, Chuck Guzis via cctalk wrote: >>> Isn't that the IBM 2321 Data Cell drive? >>=20 >> Same idea, but I recall the cabinets being lower to the floor and the medi= a being more rigid than the 2321 noodles. Then again, it's been the better p= art of 50 years, and it could well have been a 2321. >>=20 >> Memory rot sucks. >>=20 >>> Having one's files "photostored" at LLL was a chancy proposition. There >>> were bootleg programs to access every file for a user, just to keep them >>> from being consigned to the photostore. >>=20 >> It was chancy at LBL as well. The mechanical handling of the 1360 photost= ore cells was something that would have defied the imagination of Rube Goldbe= rg, and chips routinely ended up in places where they didn't belong (although= they did make pretty cool bookmarks for my teenage self). >>=20 > The problem with a lot of these old machines was they relied on a lot of el= ectro-mechanical devices that would today be replaced by electronics and a f= ew simple actuators. These mechanical devices need to be adjusted and mainta= ined and have lots of parts to wear out. While I only started with IBM in 1= 979 I still got to work on machines that would now be considered electro-mech= anical nightmares. Some of the earliest magnetic storage was mechanically simple: magnetic drums= . Nothing moving apart from the spinning media, and quite fast. Fixed head = ("head per track") disk drives are a variation on that theme, DEC had some th= at were successful for a while. I remember a concept for a very fast magnetic storage system that didn't beco= me a product, as far as I know. The scheme was to build a large array of hea= ds, using IC-manufacturing type techniques, and mount that array in contact o= r near-contact with a flat rectangular magnetic plate. The plate (or the hea= ds) could move a small amount in one direction. The idea was "head per secto= r", with the mechanical motion scanning the sector across the head. Given so= mething like piezo-electric actuators it would have been quite fast. There's a neat document in the CWI archives, a course on computer design from= early 1948. It has a section about memories, well before core memory was in= vented. The schemes it describes are quite curious, including photographic m= emories, selectrons, and various other schemes. Also drum memories, includin= g the rather mythical notion of a drum spinning at 60,000 rpm. paul --===============6865979942451976102==-- From cclist@sydex.com Fri Apr 12 19:13:08 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 12:12:57 -0700 Message-ID: <0886588e-363e-4192-a698-a6c9a05cffc2@sydex.com> In-Reply-To: <004801da8d04$bb3b1d10$31b15730$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5446782348651756458==" --===============5446782348651756458== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/12/24 11:10, Tom Gardner via cctalk wrote: problems too and in the end I'm told it was a rather successful product. > > NCR CRAM (Card Random Access Memory) truly considered magnetic cards as the > media, see > https://www.computerhistory.org/brochures/m-p/national-cash-register-company > -ncr/ > I recall a friend whose shop used the CRAM remarking that a cardboard box needed to be kept near the machine. Apparently if card was rejected for some reason, it was simply spat out to the floor. --Chuck --===============5446782348651756458==-- From paulkoning@comcast.net Fri Apr 12 19:13:30 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 15:13:23 -0400 Message-ID: <2E2839E7-BEF5-41D2-BFD2-1283EDF7F991@comcast.net> In-Reply-To: <004801da8d04$bb3b1d10$31b15730$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0442847792128953101==" --===============0442847792128953101== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 2:10 PM, Tom Gardner via cctalk wrote: >=20 > Data Cell - Tape, Card or Disk? >=20 > I'm pretty sure the developers thought of the media of the IBM 2321 as tape > rather than cards, although the strips (of tape) were addressed as disk > drives (DASD) not tape.=20 Actually, they look like a disk. See the 2841 manual on Bitsavers (that's th= e controller which drives 2311 disks as well as 2321 data cell devices). It = says that each strip has 100 tracks, read/written by a movable heads unit tha= t has 20 heads on it, so 5 positions. And it shows the layout of each track,= which is the conventions count/key/data layout of 360 disk drives like the 2= 311. Yes, variable length "sectors", you'd specify in the JCL what you wante= d for blocksize of that particular file. If I remember right, the block leng= th could vary from one block to the next, which is pretty wild. (Contrast wi= th the EL-X8 disk drive, which also has variable length sectors, but more lim= ited: a choice of one of 5 possible sizes, chosen on a per-track basis when y= ou first write or format that track.) Apart from those, I only ever remember= seeing fixed size sectors, though the actual lengths might be strange -- lik= e the CDC mainframe disks with sectors of 322 12-bit words. paul --===============0442847792128953101==-- From cclist@sydex.com Fri Apr 12 19:25:27 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 12:25:17 -0700 Message-ID: <56357452-4761-4167-ab50-85107d8af558@sydex.com> In-Reply-To: <04BB9662-C82A-43B2-9F73-24081A527271@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1812875774717591741==" --===============1812875774717591741== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/12/24 12:04, Paul Koning via cctalk wrote: > I remember a concept for a very fast magnetic storage system that didn't be= come a product, as far as I know. The scheme was to build a large array of h= eads, using IC-manufacturing type techniques, and mount that array in contact= or near-contact with a flat rectangular magnetic plate. The plate (or the h= eads) could move a small amount in one direction. The idea was "head per sec= tor", with the mechanical motion scanning the sector across the head. Given = something like piezo-electric actuators it would have been quite fast. >=20 > There's a neat document in the CWI archives, a course on computer design fr= om early 1948. It has a section about memories, well before core memory was = invented. The schemes it describes are quite curious, including photographic= memories, selectrons, and various other schemes. Also drum memories, includ= ing the rather mythical notion of a drum spinning at 60,000 rpm. That UNIVAC nickel-plated sewer pipe in a box, the Fastrand II used a series of solenoids and lever arms for head positioning. I vaguely remember a FJCC article describing it. But fast? Not so much, at least for drum storage of that era. I believe there were also microphones incorporated into it, called "ping detectors".... --Chuck --===============1812875774717591741==-- From tom94022@comcast.net Fri Apr 12 20:11:37 2024 From: Tom Gardner To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 13:03:15 -0700 Message-ID: <006d01da8d14$77e59d50$67b0d7f0$@comcast.net> In-Reply-To: <2E2839E7-BEF5-41D2-BFD2-1283EDF7F991@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4680557930111715065==" --===============4680557930111715065== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit When I said "addressed as disk drives (DASD)" I was referring to IBM's DASD's (Direct Access Storage Device's) CKD (Count Key Data) format introduced with the System/360 which supported variable length records, or as Paul calls them "variable length sectors" on disk drives, data cells and drums amongst other devices. The Count field of each Record defined the length of both the optional Key field the Data field so that on a single track you could have records of different length - not likely but possible. It was also possible to write a record longer than a track using record overflow. Variable length CKD records are still supported today in IBM's mainframe systems by emulation on arrays of fixed sector HDDs. Tom -----Original Message----- From: Paul Koning Sent: Friday, April 12, 2024 12:13 PM To: t.gardner(a)computer.org; cctalk(a)classiccmp.org Cc: Tom Gardner Subject: Re: [cctalk] IBM 360 > On Apr 12, 2024, at 2:10 PM, Tom Gardner via cctalk wrote: > > Data Cell - Tape, Card or Disk? > > I'm pretty sure the developers thought of the media of the IBM 2321 > as tape rather than cards, although the strips (of tape) were > addressed as disk drives (DASD) not tape. Actually, they look like a disk. See the 2841 manual on Bitsavers (that's the controller which drives 2311 disks as well as 2321 data cell devices). It says that each strip has 100 tracks, read/written by a movable heads unit that has 20 heads on it, so 5 positions. And it shows the layout of each track, which is the conventions count/key/data layout of 360 disk drives like the 2311. Yes, variable length "sectors", you'd specify in the JCL what you wanted for blocksize of that particular file. If I remember right, the block length could vary from one block to the next, which is pretty wild. (Contrast with the EL-X8 disk drive, which also has variable length sectors, but more limited: a choice of one of 5 possible sizes, chosen on a per-track basis when you first write or format that track.) Apart from those, I only ever remember seeing fixed size sectors, though the actual lengths might be strange -- like the CDC mainframe disks with sectors of 322 12-bit words. paul --===============4680557930111715065==-- From paulkoning@comcast.net Fri Apr 12 20:13:48 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 16:13:41 -0400 Message-ID: <2B3C4488-667D-4B80-8669-6073233F71C6@comcast.net> In-Reply-To: <56357452-4761-4167-ab50-85107d8af558@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5003812625326219280==" --===============5003812625326219280== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 3:25 PM, Chuck Guzis via cctalk wrote: >=20 > On 4/12/24 12:04, Paul Koning via cctalk wrote: >=20 >> I remember a concept for a very fast magnetic storage system that didn't b= ecome a product, as far as I know. The scheme was to build a large array of = heads, using IC-manufacturing type techniques, and mount that array in contac= t or near-contact with a flat rectangular magnetic plate. The plate (or the = heads) could move a small amount in one direction. The idea was "head per se= ctor", with the mechanical motion scanning the sector across the head. Given= something like piezo-electric actuators it would have been quite fast. >>=20 >> There's a neat document in the CWI archives, a course on computer design f= rom early 1948. It has a section about memories, well before core memory was= invented. The schemes it describes are quite curious, including photographi= c memories, selectrons, and various other schemes. Also drum memories, inclu= ding the rather mythical notion of a drum spinning at 60,000 rpm. >=20 > That UNIVAC nickel-plated sewer pipe in a box, the Fastrand II used a > series of solenoids and lever arms for head positioning. I vaguely > remember a FJCC article describing it. >=20 > But fast? Not so much, at least for drum storage of that era. I > believe there were also microphones incorporated into it, called "ping > detectors".... Yes, the Univac Model I acoustic delay line memories. The document I mention= ed is MC report CR-3, by A. van Wijngaarden, 1948, which is online in their a= rchive but only as a not particularly clear scanned document in Dutch. It de= scribes six memory technologies: photographic film, fluorescence, electric re= sistance (including the notion of a neon cross-bar, which is another way of d= escribing Bitzer's inherent-memory plasma display panel but more than a decad= e earlier), acoustic waves (such as the Univac memory), magnetic tape, wire, = or drum storage, and electrostatic charges (the Selectron is described in det= ail). Not all that fast, well, it depends on what you're comparing with. Given tub= e logic with cycle times measures in microseconds, quite possibly serial rath= er than parallel organization, those acoustic or drum memory systems weren't = all that terrible. =20 paul --===============5003812625326219280==-- From van.snyder@sbcglobal.net Fri Apr 12 20:58:03 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 13:57:50 -0700 Message-ID: In-Reply-To: <04BB9662-C82A-43B2-9F73-24081A527271@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7216512520863910689==" --===============7216512520863910689== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 2024-04-12 at 15:04 -0400, Paul Koning via cctalk wrote: > Some of the earliest magnetic storage was mechanically simple: > magnetic drums. Nothing moving apart from the spinning media, and > quite fast. Fixed head ("head per track") disk drives are a > variation on that theme, DEC had some that were successful for a > while. From 1968 until almost 2000, Caltech Jet Propulsion Laboratory had Univac mainframes, first 1108 (three of them), then 1110, then 1100/40, then 1100/80, then 2200. We would run 50 time-shariing jobs and ten batch jobs on a 262k machine. Swap was on eleven 4 millisecond FH432 (FH="Flying Head") drums, able to hold one core load each, plus several 7 millisecond FH1782 drums with four core loads each. Users' files were on FASTRAND II™ -- an 5,000 pound drum machine the size of two upright pianos, holding about 22 megawords. With 92 millisecond access time, calling it FASTRAND was obviously a marketing fiction. A bunch of Calcomp disk drives eventually replaced the Fastrand. https://en.wikipedia.org/wiki/UNIVAC_FASTRAND The 1100 series began with the ERA 1101, built for the Navy's "project 13," or 1101 in binary. --===============7216512520863910689==-- From van.snyder@sbcglobal.net Fri Apr 12 21:27:21 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 14:27:11 -0700 Message-ID: <106901e34002be94502d3e4ccb8d618eef6339bf.camel@sbcglobal.net> In-Reply-To: <2B3C4488-667D-4B80-8669-6073233F71C6@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9030845473758127736==" --===============9030845473758127736== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2024-04-12 at 16:13 -0400, Paul Koning via cctalk wrote: > Not all that fast, well, it depends on what you're comparing with. > Given tube logic with cycle times measures in microseconds, quite > possibly serial rather than parallel organization, those acoustic or > drum memory systems weren't all that terrible. Speaking of drum machines.... On the Bendix G-15, memory was logically 20 "long" delay lines, each of 108 words of 29 bits, and four "short" lines of four words each, 27 times faster, used for registers. The "delay line" was not an acoustic mercury delay line. Rather, it was implemented on a drum as a digital delay line, with data read and them immediately written a short distance away on the same track. Data were not retained on the drum when the machine was turned off. It was a serial machine. Even the instructions were designed to minimize how much had to be held in flop flops. The machine was remarkably cost effective for its time. Being five feet tall with a one square yard footprint, it could have been a home computer, but as far as I know, the only "home" version was one that the designer, Harry Huskey, got. It was based on the Automatic Computing Engine, or ACE, designed by Alan Turing. Huskey had worked with Turing for about a year. Huskey also worked on SWAC. He did most of the G-15 design work while he was a professor at UC Berkeley. Nicklaus Wirth was one of his grad students. David Evans, cofounder of Evans and Sutherland, worked for him on the G-15 project. --===============9030845473758127736==-- From sqrfolkdnc@comcast.net Fri Apr 12 21:54:54 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 16:54:26 -0500 Message-ID: <414242053.1550434.1712958866337@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5369636965927134477==" --===============5369636965927134477== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable https://en.wikipedia.org/wiki/List_of_IBM_products for genuine ibm devices. Calcomp (and others?) had automated tape libraries for reel to reel taps. STC (and others?) had automated tape libraries for the 3480 carts plotters? 1404 printer (I've mentioned before) that could print on two tab cards at a t= ime forget who, but an archiving system using 14 inch (?) video disk platters. 7= (?) years of all customer statements were stored on these. 3rd party extensions for main memory (took a 360/30 to 96 KB or more, beyond = IBM's 64 KB limit) The cartridge tape library that staged onto 3350s (and later 3380s?) Of course there were 7 track tape drives for compatibility with prior systems= . When we were down to only one job a week using the 7 track tape, we discov= ered the client we got tapes from had only one 7 track tape, just to send us = tapes. --going beyond mass storage the 2956 check sorter (rpq) that was two complete 1419 sorters connected head= to tail to give twice as many pockets (it had a second read unit, don't thin= k it actually read a second time). the 3890 replacement for the 2956 that was built in modules of 6(?) pockets y= ou choose how many up to 36 (?) 3270 terminals that were only 12 lines of 40 characters my favorite terminal 3190 that was neon gas, so monochrome, but could take 5 = addresses, and flip between 62 lines of 160 characters (always there), to 4 t= erminals of 62x80 any two visible at a time, or 4 terminals of 31x160 charact= ers, any 2 visible at a time, or 4 terminals of 31x80 all visible at once. w= hen given a choice, my new boss was surprised that I chose that instead of th= e color 3279 with graphics that everybody else wanted. Great for running vir= tual systems... 
--Carey
--===============5369636965927134477==-- From cclist@sydex.com Fri Apr 12 22:07:51 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 15:07:40 -0700 Message-ID: <9c896183-b42f-41bc-9ca4-796fbe299e3a@sydex.com> In-Reply-To: <414242053.1550434.1712958866337@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0420187990120648624==" --===============0420187990120648624== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/12/24 14:54, CAREY SCHUG via cctalk wrote: > https://en.wikipedia.org/wiki/List_of_IBM_products for genuine ibm devices. > > Calcomp (and others?) had automated tape libraries for reel to reel taps. > The cartridge tape library that staged onto 3350s (and later 3380s?) The beer-can-in-a-beehive 3850 MSS, perhaps? At a trade show where the thing was being demonstrated (NCC perhaps?), I remember the presenter saying that the advantage of two "picker" assemblies was that one could push the other out of the way should it stop working. MPI/CDC did offer a competing product, but I don't recall the number. --Chuck --===============0420187990120648624==-- From cclist@sydex.com Fri Apr 12 22:12:51 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 15:05:07 -0700 Message-ID: <3dfca589-df7a-4858-9566-1640b2605ae7@sydex.com> In-Reply-To: <106901e34002be94502d3e4ccb8d618eef6339bf.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4180855554196825520==" --===============4180855554196825520== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/12/24 14:27, Van Snyder via cctalk wrote: > On Fri, 2024-04-12 at 16:13 -0400, Paul Koning via cctalk wrote: >> Not all that fast, well, it depends on what you're comparing with. >> Given tube logic with cycle times measures in microseconds, quite >> possibly serial rather than parallel organization, those acoustic or >> drum memory systems weren't all that terrible. > > Speaking of drum machines.... One that comes to mind is the Datatron/Burroughs B-205, used as a prop in several Hollywood productions (or at least pieces of one).. The drum there was divided into two areas; the "main storage" area where each track stored 100 words of 11 digit BCD and the "quick access" tracks that stored only a tenth as much, 20 words. The deal was that writing a word to the quick access tracks would write it 10 times, so that access time to a word was cut by 90%. Clever. --Chuck --===============4180855554196825520==-- From cc@alderson.users.panix.com Fri Apr 12 22:27:51 2024 From: Rich Alderson To: cctalk@classiccmp.org Subject: [cctalk] The Atomic Energy Commission [was Re: Re: Odd IBM mass storage systems] Date: Fri, 12 Apr 2024 18:09:30 -0400 Message-ID: <4VGW2260xlzfYm@panix5.panix.com> In-Reply-To: <1f4b6015-30e7-459a-ac60-bb2300aed532@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1611348750326067548==" --===============1611348750326067548== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Date: Fri, 12 Apr 2024 15:28:34 -0300 > From: Paul Berger via cctalk > The 1360 was apparently developed at the request to Atomic Energy Commission > (AEC), I=C2=A0 would guess a forerunner of the DOE.=C2=A0=C2=A0 There where= apparently only > 5 built 3 for the AEC and 2 for the NSA. The United States Atomic Energy Commission was superseded by the Nuclear Regulatory Commission in the 1970s. The Department of Energy is not the same thing at all. Rich --===============1611348750326067548==-- From van.snyder@sbcglobal.net Fri Apr 12 22:57:13 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 360 Date: Fri, 12 Apr 2024 15:57:05 -0700 Message-ID: In-Reply-To: <2E2839E7-BEF5-41D2-BFD2-1283EDF7F991@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6765080859637722653==" --===============6765080859637722653== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 2024-04-12 at 15:13 -0400, Paul Koning via cctalk wrote: > Yes, variable length "sectors", you'd specify in the JCL what you > wanted for blocksize of that particular file. If I remember right, > the block length could vary from one block to the next, In about 1998, I had to move some data from a VAX to a Unix machine (HP-UX). I copied the data using FTP. What I didn't know in advance was that it was binary (mostly numeric, oddly 360-format floating-point numbers and an EBCDIC header), with variable length records. The VAX Record Manager, sometimes affectionately known as the Record Mangler, kept track of the record lengths which, of course, FTP didn't carry over to the Unix machine. Then I found out that record length was one of the desiderata for the record type. I happened to know one of the engineers responsible for the originalk software, who volunteered to change the format so the record length was within the record, before the VAX was retired. He said "I don't have the files any more, but I have the listings and I can punch it in again. Because keypunch machines were long gone by then, I assume he "punched it in again" using his VT-102. > Apart from those, I only ever remember seeing fixed size sectors, > though the actual lengths might be strange -- like the CDC mainframe > disks with sectors of 322 12-bit words. Or Univac disk formats, with FASTRAND™ sectors of 28 36-bit words and tracks of 64 sectors. --===============6765080859637722653==-- From van.snyder@sbcglobal.net Fri Apr 12 23:00:55 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: The Atomic Energy Commission [was Re: Re: Odd IBM mass storage systems] Date: Fri, 12 Apr 2024 16:00:46 -0700 Message-ID: In-Reply-To: <4VGW2260xlzfYm@panix5.panix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7964626195973761067==" --===============7964626195973761067== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2024-04-12 at 18:09 -0400, Rich Alderson via cctalk wrote: > > Date: Fri, 12 Apr 2024 15:28:34 -0300From: Paul Berger via cctalk < > > cctalk(a)classiccmp.org> > > The 1360 was apparently developed at the request to Atomic Energy > > Commission(AEC), I would guess a forerunner of the DOE. There > > where apparently only5 built 3 for the AEC and 2 for the NSA. > > The United States Atomic Energy Commission was superseded by the > NuclearRegulatory Commission in the 1970s. The Department of Energy > is not the samething at all. > Rich AEC was split up into NRC, mostly now composed of attorneys, gynecologists, architects, and theologians, who see it as their duty to suppress nuclear power, and (initially) ERDA, or Energy Research and Development Agency. ERDA became DoE. So DoE is, along with NRC, a descendant of AEC. --===============7964626195973761067==-- From phb.hfx@gmail.com Fri Apr 12 23:05:26 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: The Atomic Energy Commission [was Re: Re: Odd IBM mass storage systems] Date: Fri, 12 Apr 2024 20:05:17 -0300 Message-ID: In-Reply-To: <4VGW2260xlzfYm@panix5.panix.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6469707065015406716==" --===============6469707065015406716== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-12 7:09 p.m., Rich Alderson via cctalk wrote: >> Date: Fri, 12 Apr 2024 15:28:34 -0300 >> From: Paul Berger via cctalk >> The 1360 was apparently developed at the request to Atomic Energy Commissi= on >> (AEC), I=C2=A0 would guess a forerunner of the DOE.=C2=A0=C2=A0 There wher= e apparently only >> 5 built 3 for the AEC and 2 for the NSA. > The United States Atomic Energy Commission was superseded by the Nuclear > Regulatory Commission in the 1970s. The Department of Energy is not the sa= me > thing at all. > > Rich The Wikipedia article on Department of Energy (DOE) suggests that in=20 1974 the Atomic Energy Commission (AEC) was split into two organizations=20 the Nuclear Regulatory Commision (NRC) and the other for energy research=20 and development and I believe this is what is now known as the DOE.=C2=A0 I=20 book I found information on the IBM 1360 indicates 3 where sold to the=20 AEC and one was installed at Livermore and another at Los Alamos both of=20 which I am pretty sure are DOE facilities now.=C2=A0 So it would seem that=20 the AEC was the ancestor for both the DOE and the NRC. Paul. --===============6469707065015406716==-- From van.snyder@sbcglobal.net Fri Apr 12 23:49:01 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 16:48:50 -0700 Message-ID: In-Reply-To: <3dfca589-df7a-4858-9566-1640b2605ae7@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8279003949147914370==" --===============8279003949147914370== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2024-04-12 at 15:05 -0700, Chuck Guzis via cctalk wrote: > > > One that comes to mind is the Datatron/Burroughs B-205, used as a prop > in several Hollywood productions (or at least pieces of one).. > In the computer center, beside the 7094/7044 Direct Couple, Caltech had a Datatron/Burroughs 220. It had a tape drive for metallic tape. If it detected an error, it backspaced and punched a hole in the tape. By 1964, the 220 had only two jobs: One was to read paper tape from the synchrotron into the 7044. The other was to print on its "whippet" printer, a very fast electrostatic printer that put soot onto a thermal paper that was then heated to "fix" it. There was a huge variac under the printer to adjust the heater. The perfect setting was between two windings. Too cold and the soot fell off. Too hot and it was melted and smeared into an almost illegible mess. But it was very fast -- and only 80 columns wide. It was about the size of a KSR-33. --===============8279003949147914370==-- From paulkoning@comcast.net Sat Apr 13 01:21:47 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 21:21:39 -0400 Message-ID: <4E4D4585-C7AB-4AC7-9A3A-5294553FCB57@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3796565872828303220==" --===============3796565872828303220== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 7:48 PM, Van Snyder via cctalk wrote: >=20 > ... The other was to print on its "whippet" > printer, a very fast electrostatic printer that put soot onto a thermal > paper that was then heated to "fix" it. There was a huge variac under > the printer to adjust the heater. The perfect setting was between two > windings. Too cold and the soot fell off. Too hot and it was melted and > smeared into an almost illegible mess. But it was very fast -- and only > 80 columns wide. It was about the size of a KSR-33. Different beast, but it reminds me of an electrostatic plotter we at on the U= of Illinois PLATO system. That one was by Versatec, either 11 or 17 inches = wide (I forgot), 300 dpi, pretty sure it used wet toner. It also used a chai= n drive for the paper feed, which had enough backlash that starting and stopp= ing would produce visible irregularities in the output. So I wrote a driver = for it that did overlapped I/O to avoid that problem. (File I/O directly fro= m a PPU program, lots of fun!) With that, it did an awesome job printing musical scores. paul --===============3796565872828303220==-- From paulkoning@comcast.net Sat Apr 13 01:23:40 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 21:23:33 -0400 Message-ID: <82030DE6-2770-43F6-8E6C-2542495B9F73@comcast.net> In-Reply-To: <414242053.1550434.1712958866337@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1428643229628288557==" --===============1428643229628288557== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 5:54 PM, CAREY SCHUG via cctalk wrote: >=20 > ... > my favorite terminal 3190 that was neon gas, so monochrome, but could take = 5 addresses, and flip between 62 lines of 160 characters (always there), to 4= terminals of 62x80 any two visible at a time, or 4 terminals of 31x160 chara= cters, any 2 visible at a time, or 4 terminals of 31x80 all visible at once. = when given a choice, my new boss was surprised that I chose that instead of = the color 3279 with graphics that everybody else wanted. Great for running v= irtual systems... Sounds like the plasma panel displays that were invented for the PLATO system= , by Don Bitzer and a few others, at the U of Illinois. Inherent memory: if = you lit a pixel it would stay lit, to turn it off you'd feed it a pulse of th= e opposite polarity. So it was a great way to do 512x512 bitmap graphics wit= h very modest complexity, no refresh memory needed. paul --===============1428643229628288557==-- From bfranchuk@jetnet.ab.ca Sat Apr 13 01:49:57 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Fri, 12 Apr 2024 19:49:44 -0600 Message-ID: <6f5a76f8-b934-4073-a8e5-60a120286ff9@jetnet.ab.ca> In-Reply-To: <82030DE6-2770-43F6-8E6C-2542495B9F73@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2007660277823605273==" --===============2007660277823605273== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-12 7:23 p.m., Paul Koning via cctalk wrote: >=20 >=20 >> On Apr 12, 2024, at 5:54 PM, CAREY SCHUG via cctalk wrote: >> >> ... >> my favorite terminal 3190 that was neon gas, so monochrome, but could take= 5 addresses, and flip between 62 lines of 160 characters (always there), to = 4 terminals of 62x80 any two visible at a time, or 4 terminals of 31x160 char= acters, any 2 visible at a time, or 4 terminals of 31x80 all visible at once.= when given a choice, my new boss was surprised that I chose that instead of= the color 3279 with graphics that everybody else wanted. Great for running = virtual systems... >=20 > Sounds like the plasma panel displays that were invented for the PLATO syst= em, by Don Bitzer and a few others, at the U of Illinois. Inherent memory: i= f you lit a pixel it would stay lit, to turn it off you'd feed it a pulse of = the opposite polarity. So it was a great way to do 512x512 bitmap graphics w= ith very modest complexity, no refresh memory needed. >=20 > paul >=20 But too slow I suspect to run a game like spacewar. --===============2007660277823605273==-- From bfranchuk@jetnet.ab.ca Sat Apr 13 01:55:52 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Other input devices. Date: Fri, 12 Apr 2024 19:55:41 -0600 Message-ID: <13cb2be7-6d81-4577-9989-94169433308f@jetnet.ab.ca> In-Reply-To: <82030DE6-2770-43F6-8E6C-2542495B9F73@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3241329283823068325==" --===============3241329283823068325== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Did any one ever use a keyboard to magtape as input device? --===============3241329283823068325==-- From sellam.ismail@gmail.com Sat Apr 13 04:14:00 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Fri, 12 Apr 2024 21:13:43 -0700 Message-ID: In-Reply-To: <13cb2be7-6d81-4577-9989-94169433308f@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4772657668367740107==" --===============4772657668367740107== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Apr 12, 2024 at 6:55 PM ben via cctalk wrote: > Did any one ever use a keyboard to magtape as input device? > I never got to use it but I used to own one. A Mohawk Data Sciences unit. Sellam --===============4772657668367740107==-- From dave.g4ugm@gmail.com Sat Apr 13 06:59:02 2024 From: dave.g4ugm@gmail.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 07:58:55 +0100 Message-ID: <16f901da8d70$0d11b9d0$27352d70$@gmail.com> In-Reply-To: <13cb2be7-6d81-4577-9989-94169433308f@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8772289471197436055==" --===============8772289471197436055== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ben via cctalk > Sent: Saturday, April 13, 2024 2:56 AM > To: cctalk(a)classiccmp.org > Cc: ben > Subject: [cctalk] Other input devices. >=20 > Did any one ever use a keyboard to magtape as input device? We had one where I worked, with a Honeywell badge on it. We never used it in = that manner, it had a papertape reader attached which was used to convert out= put from Friden Flexowriters to Magtape for a Honeywell H3200. Dave --===============8772289471197436055==-- From als@thangorodrim.ch Sat Apr 13 16:37:06 2024 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Borland Turbo C++ and Turbo Basic - Books and Manuals Date: Sat, 13 Apr 2024 18:28:47 +0200 Message-ID: In-Reply-To: <550d8f4e-319b-4e9b-b00b-09a20e824581@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2592246125392856732==" --===============2592246125392856732== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Apr 07, 2024 at 12:05:32PM -0600, ben via cctalk wrote: > On 2024-04-07 5:57 a.m., Christian Groessler via cctalk wrote: > > On 4/6/24 5:37 PM, Mike Norris via cctalk wrote: > > > Additional > > > I would like £5 beer money for this one please! > > > Writing Open VMS Alpha Device Drivers in C - Margie Sherlock/Leonard > > > Szubowicz > > > > > > I'd take it. > > > > I can send you beer money, or could send you 2 or 3 bottles of local > > beer. I'm living near Munich, Germany. > > > > Sending beer will likely be quite more expensive than 5 pounds, but has > > a fun factor bonus :-) > > > > regards, > > chris > > > I don't think bottles would be ship able. Bottles of beer are perfectly shippable. I ordered bottled beer over the mail plenty of times before. The trick is to use good packaging and pack them well. Or go with cans if you don't trust your packaging skills to reach the level of "Fedex Proof (TM)". ;-) Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============2592246125392856732==-- From paulkoning@comcast.net Sat Apr 13 17:20:11 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sat, 13 Apr 2024 13:20:03 -0400 Message-ID: <91A4828C-EE16-4900-ADEF-04B284B3B128@comcast.net> In-Reply-To: <6f5a76f8-b934-4073-a8e5-60a120286ff9@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5902668330377836148==" --===============5902668330377836148== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 9:49 PM, ben via cctalk wrote: >=20 > On 2024-04-12 7:23 p.m., Paul Koning via cctalk wrote: >>> On Apr 12, 2024, at 5:54 PM, CAREY SCHUG via cctalk wrote: >>>=20 >>> ... >>> my favorite terminal 3190 that was neon gas, so monochrome, but could tak= e 5 addresses, and flip between 62 lines of 160 characters (always there), to= 4 terminals of 62x80 any two visible at a time, or 4 terminals of 31x160 cha= racters, any 2 visible at a time, or 4 terminals of 31x80 all visible at once= . when given a choice, my new boss was surprised that I chose that instead o= f the color 3279 with graphics that everybody else wanted. Great for running= virtual systems... >> Sounds like the plasma panel displays that were invented for the PLATO sys= tem, by Don Bitzer and a few others, at the U of Illinois. Inherent memory: = if you lit a pixel it would stay lit, to turn it off you'd feed it a pulse of= the opposite polarity. So it was a great way to do 512x512 bitmap graphics = with very modest complexity, no refresh memory needed. >> paul >=20 > But too slow I suspect to run a game like spacewar. PLATO was the system where a whole lot of early games first appeared, especia= lly multi-player games. Among them were any number of variations of "Star Tr= ek" inspired ones. While you couldn't refresh a screen full of space ships i= n motion as fast as you can on a dedicated graphics engine, it was certainly = acceptable for the players. And a simpler two-ship game like the original sp= acewar would work even better, because you'd only need a couple of operations= per refresh -- on the classic terminal, 12 output words at 60 per second, so= 200 ms per refresh. Not quite "full motion" but close. paul --===============5902668330377836148==-- From paulkoning@comcast.net Sat Apr 13 17:22:22 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 13:22:16 -0400 Message-ID: <74C8377D-FAB8-4F19-98B3-4DBA7391FC0F@comcast.net> In-Reply-To: <13cb2be7-6d81-4577-9989-94169433308f@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9014467154666698789==" --===============9014467154666698789== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 12, 2024, at 9:55 PM, ben via cctalk wrote: >=20 > Did any one ever use a keyboard to magtape as input device? My wife did, sort of: for a while she worked with IBM MT/ST word processors. = Those were very early word processing systems that used a custom magnetic ta= pe cartridge for storage and a Selectric typewriter for I/O. paul --===============9014467154666698789==-- From uban@ubanproductions.com Sat Apr 13 17:44:12 2024 From: Tom Uban To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sat, 13 Apr 2024 12:44:06 -0500 Message-ID: <61aa4ee9-d395-468b-8a29-05e830bd0935@ubanproductions.com> In-Reply-To: <91A4828C-EE16-4900-ADEF-04B284B3B128@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8632716293645030685==" --===============8632716293645030685== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/13/24 12:20, Paul Koning via cctalk wrote: > >> On Apr 12, 2024, at 9:49 PM, ben via cctalk wrot= e: >> >> On 2024-04-12 7:23 p.m., Paul Koning via cctalk wrote: >>>> On Apr 12, 2024, at 5:54 PM, CAREY SCHUG via cctalk wrote: >>>> >>>> ... >>>> my favorite terminal 3190 that was neon gas, so monochrome, but could ta= ke 5 addresses, and flip between 62 lines of 160 characters (always there), t= o 4 terminals of 62x80 any two visible at a time, or 4 terminals of 31x160 ch= aracters, any 2 visible at a time, or 4 terminals of 31x80 all visible at onc= e. when given a choice, my new boss was surprised that I chose that instead = of the color 3279 with graphics that everybody else wanted. Great for runnin= g virtual systems... >>> Sounds like the plasma panel displays that were invented for the PLATO sy= stem, by Don Bitzer and a few others, at the U of Illinois. Inherent memory:= if you lit a pixel it would stay lit, to turn it off you'd feed it a pulse o= f the opposite polarity. So it was a great way to do 512x512 bitmap graphics= with very modest complexity, no refresh memory needed. >>> paul >> But too slow I suspect to run a game like spacewar. > PLATO was the system where a whole lot of early games first appeared, espec= ially multi-player games. Among them were any number of variations of "Star = Trek" inspired ones. While you couldn't refresh a screen full of space ships= in motion as fast as you can on a dedicated graphics engine, it was certainl= y acceptable for the players. And a simpler two-ship game like the original = spacewar would work even better, because you'd only need a couple of operatio= ns per refresh -- on the classic terminal, 12 output words at 60 per second, = so 200 ms per refresh. Not quite "full motion" but close. > > paul > I cannot count how many hours I spend on the Plato IV terminal at our local u= niversity playing=20 Empire and Dogfight - I was in high school at the time... --tom --===============8632716293645030685==-- From cclist@sydex.com Sat Apr 13 18:08:13 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sat, 13 Apr 2024 11:08:01 -0700 Message-ID: <71906599-0d47-4866-9b3d-27374fbcaf3a@sydex.com> In-Reply-To: <91A4828C-EE16-4900-ADEF-04B284B3B128@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1842165864525619142==" --===============1842165864525619142== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/13/24 10:20, Paul Koning via cctalk wrote: >=20 >=20 > PLATO was the system where a whole lot of early games first appeared, espec= ially multi-player games. Among them were any number of variations of "Star = Trek" inspired ones. While you couldn't refresh a screen full of space ships= in motion as fast as you can on a dedicated graphics engine, it was certainl= y acceptable for the players. And a simpler two-ship game like the original = spacewar would work even better, because you'd only need a couple of operatio= ns per refresh -- on the classic terminal, 12 output words at 60 per second, = so 200 ms per refresh. Not quite "full motion" but close. >=20 The guys down the hall at CDC SVLOPS were the PLATO people for a couple of years in the 70s. CDC had internal training classes that used the orange monster. I recall I took one for Project Manager training. "The Mythical Man Month" was a required text for the course. --Chuck --===============1842165864525619142==-- From michael.99.thompson@gmail.com Sat Apr 13 18:23:05 2024 From: Michael Thompson To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 14:22:45 -0400 Message-ID: In-Reply-To: <74C8377D-FAB8-4F19-98B3-4DBA7391FC0F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4094198967631309470==" --===============4094198967631309470== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > On Apr 12, 2024, at 9:55 PM, ben via cctalk > wrote: > > > > Did any one ever use a keyboard to magtape as input device? > > My wife did, sort of: for a while she worked with IBM MT/ST word > processors. Those were very early word processing systems that used a > custom magnetic tape cartridge for storage and a Selectric typewriter for > I/O. > > paul > > The Rhode Island Computer Museum has two IBM Mag Card Selectric systems, and just got an IBM Cassette Selectric System. -- Michael Thompson --===============4094198967631309470==-- From van.snyder@sbcglobal.net Sat Apr 13 19:42:06 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 12:41:55 -0700 Message-ID: <242f773b455e7c802b7753ee659844cda0731ab0.camel@sbcglobal.net> In-Reply-To: <74C8377D-FAB8-4F19-98B3-4DBA7391FC0F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0263384050576516699==" --===============0263384050576516699== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 2024-04-13 at 13:22 -0400, Paul Koning via cctalk wrote: > > On Apr 12, 2024, at 9:55 PM, ben via cctalk > > wrote: > > Did any one ever use a keyboard to magtape as input device? > > My wife did, sort of: for a while she worked with IBM MT/ST word > processors. Those were very early word processing systems that used > a custom magnetic tape cartridge for storage and a Selectric > typewriter for I/O. The first word processor I heard of was the "Redactron" that ran on the 7044 side of the 7094/7044 Direct Couple at the Caltech Jet Priopulsion Laboratory. I don't know whether it was used anywhere else. I don't know whether documents were ultimately stored on mag tape, or the 1405 RAMAC, or only on paper. > paul --===============0263384050576516699==-- From cclist@sydex.com Sat Apr 13 19:47:41 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 12:47:23 -0700 Message-ID: <26b51884-33e6-4cb2-bdf2-a84e0b635f4b@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0246625817879686913==" --===============0246625817879686913== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/13/24 11:22, Michael Thompson via cctalk wrote: >>> On Apr 12, 2024, at 9:55 PM, ben via cctalk >> wrote: >>> >>> Did any one ever use a keyboard to magtape as input device? >> >> My wife did, sort of: for a while she worked with IBM MT/ST word >> processors. Those were very early word processing systems that used a >> custom magnetic tape cartridge for storage and a Selectric typewriter for >> I/O. The mag card Selectric (MC/ST) was relatively popular also. --Chuck --===============0246625817879686913==-- From van.snyder@sbcglobal.net Sat Apr 13 19:54:50 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 12:54:40 -0700 Message-ID: In-Reply-To: <16f901da8d70$0d11b9d0$27352d70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3738095713661465681==" --===============3738095713661465681== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 2024-04-13 at 07:58 +0100, Dave Wade G4UGM via cctalk wrote: > > -----Original Message-----From: ben via cctalk < > > cctalk(a)classiccmp.org>Sent: Saturday, April 13, 2024 2:56 AMTo: > > cctalk(a)classiccmp.org > > Cc: ben Subject: [cctalk] Other input > > devices. > > Did any one ever use a keyboard to magtape as input device? > > We had one where I worked, with a Honeywell badge on it. We never > used it in that manner, it had a papertape reader attached which was > used to convert output from Friden Flexowriters to Magtape for a > Honeywell H3200. As a freshman, I noticed that the HP Digital Slide Rule 6-digit pocket calculator was only $600. I suggested to myy college buddy Ed Kelm that it ought to be possible to build a desk calculator that used a TV for the display. That never happened, but Ed held onto that thought and eventually designed the Lexitron dedicated-logic word processor. It had a landscape-format screen. Vertical scrolling was done by typewriter- platen-like knobs on both sides of the screen. Margins were set by the same kinds of sliders as on a typewriter. As you can imagine, training for experienced secretaries was less than half a day. Documents were stored on 1/4" three-track tape cassettes using a drive invented by another school-days chum named Cliff Tedder. Because of problems with the Orange County, California, power system, where voltage ranges of 90-130 volts were common, Ed invented the now well-kinown switching power supply -- and Lexitron kept the patents so Ed got nothing but a salary from it. It rectified line voltage, regulated it to 90 volts, which ran a 20 kHz oscillator (so that the transformers required far less iron), and ultimately produced well-regulated power for the electronics. Raytheon bought Lexitron, and pounded it into the ground. Ed ultimately took his instance of it to a landfill because he couldn't find a computer museum that wanted it. > Dave --===============3738095713661465681==-- From van.snyder@sbcglobal.net Sat Apr 13 20:11:36 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 13:11:25 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5042347042237477662==" --===============5042347042237477662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 2024-04-13 at 12:54 -0700, Van Snyder wrote: As a freshman, I noticed that the HP Digital Slide Rule 6-digit pocket calcul= ator was only $600. I suggested to myy college buddy Ed Kelm that it ought to= be possible to build a desk calculator that used a TV for the display. That = never happened, but Ed held onto that thought and eventually designed the Lex= itron dedicated-logic word processor. It had a landscape-format screen.... OOPS, a portrait-format screen. --===============5042347042237477662==-- From sqrfolkdnc@comcast.net Sat Apr 13 20:11:40 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices.--keyboard to mag tape Date: Sat, 13 Apr 2024 15:11:33 -0500 Message-ID: <1624238919.1561355.1713039093200@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2468921931710640758==" --===============2468921931710640758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Memories are fuzzy. I think I remember a device that wrote to a magnetic tape, where the tape wri= tten to just fell into...something like a very wide vacuum column from a tape= drive, not taken up on a spool. Maybe it had a keyboard, but it's input act= ually came in over (dial-up?) tty-like serial data. Like, branch offices or = field sales people called in and upload their daily data? Does anybody remember anything like this? --Carey --===============2468921931710640758==-- From len@shustek.com Sat Apr 13 20:41:51 2024 From: Len Shustek To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sat, 13 Apr 2024 13:11:25 -0700 Message-ID: <7.1.0.9.2.20240413131125.06abe828@shustek.com> In-Reply-To: <171302760887.2847341.15271871784278414126@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0991550909155355226==" --===============0991550909155355226== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit At 10:00 AM 4/13/2024, Paul Berger wrote: >The problem with a lot of these old machines was they relied on a lot of >electro-mechanical devices that would today be replaced by electronics >and a few simple actuators. These mechanical devices need to be >adjusted and maintained and have lots of parts to wear out. For a great example of 1950s electro-mechanical devices, check out this: https://www.computerhistory.org/collections/catalog/102740072 https://www.computerhistory.org/collections/catalog/102740069 "The First Magnetic Random Access Mass Memory with Interchangeable Media" --===============0991550909155355226==-- From cisin@xenosoft.com Sat Apr 13 21:39:32 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 14:39:27 -0700 Message-ID: In-Reply-To: <74C8377D-FAB8-4F19-98B3-4DBA7391FC0F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7706834709551268581==" --===============7706834709551268581== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> Did any one ever use a keyboard to magtape as input device? On Sat, 13 Apr 2024, Paul Koning via cctalk wrote: > My wife did, sort of: for a while she worked with IBM MT/ST word processors= . Those were very early word processing systems that used a custom magnetic = tape cartridge for storage and a Selectric typewriter for I/O. Rather off-topic, and silly (about MT/ST), . . . I gave away one decades ago. A friend wanted it as an advertising prop=20 because he was writing a word processing program called "FULL/ST". --===============7706834709551268581==-- From elson@pico-systems.com Sat Apr 13 21:48:48 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sat, 13 Apr 2024 16:48:42 -0500 Message-ID: In-Reply-To: <4E4D4585-C7AB-4AC7-9A3A-5294553FCB57@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3852609844896787330==" --===============3852609844896787330== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/12/24 20:21, Paul Koning via cctalk wrote: > >> On Apr 12, 2024, at 7:48 PM, Van Snyder via cctalk wrote: >> >> ... The other was to print on its "whippet" >> printer, a very fast electrostatic printer that put soot onto a thermal >> paper that was then heated to "fix" it. There was a huge variac under >> the printer to adjust the heater. The perfect setting was between two >> windings. Too cold and the soot fell off. Too hot and it was melted and >> smeared into an almost illegible mess. But it was very fast -- and only >> 80 columns wide. It was about the size of a KSR-33. > Different beast, but it reminds me of an electrostatic plotter we at on the= U of Illinois PLATO system. That one was by Versatec, either 11 or 17 inche= s wide (I forgot), 300 dpi, pretty sure it used wet toner. It also used a ch= ain drive for the paper feed, which had enough backlash that starting and sto= pping would produce visible irregularities in the output. So I wrote a drive= r for it that did overlapped I/O to avoid that problem. (File I/O directly f= rom a PPU program, lots of fun!) > > With that, it did an awesome job printing musical scores. Yes, there were a number of Versatec models for different=20 paper sizes and pixel density.=C2=A0 I worked with a bunch of=20 1200A units, they could run either roll or fanfold paper at=20 11" width.=C2=A0 The paper was clay coated and felt like a dirty=20 chalkboard.=C2=A0 The toner was quite smelly, some kind of=20 paraffin oil with carbon particles suspended in it.=C2=A0 There=20 was a blower to evaporate the toner solvent.=C2=A0 The 1200A had=20 200 pixels/inch, so you got 2112 pixels across the page,=20 IIRC.=C2=A0 it applied 800 V to the writing electrodes, and=20 something like 400 V to the segmented backplate that was on=20 the opposite side of the paper.=C2=A0 It could print text at=20 about 1200 LPM, which was pretty fantastic for the time. But, I am glad to not have to deal with these things anymore! Jon --===============3852609844896787330==-- From elson@pico-systems.com Sat Apr 13 21:55:06 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sat, 13 Apr 2024 16:54:59 -0500 Message-ID: In-Reply-To: <13cb2be7-6d81-4577-9989-94169433308f@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0462579722566240943==" --===============0462579722566240943== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/12/24 20:55, ben via cctalk wrote: > Did any one ever use a keyboard to magtape as input device? > I bought a surplus desktop key to tape machine made by Pertec.  It had a 7" 9-track drive in it, a small core memory and a field of light bulbs to show the read-back contents, as well as the keyboard.  I tore it apart at the right section and turned it into a mag tape drive for my Z-80 CP/M system.  The basic tape formatting was all done in software, and I took tapes in to work and read them on our VAX to verify what I was doing was readable. I also traded a guy for a Honeywell key to tape system that apparently was used as an off-line tape to line printer unit.  But, it was actually possible to use it as a key to tape machine, too.  I wanted it for the 300 LPM printer, but had to use it in the tape to print mode to decipher the protocol of the printer. Jon --===============0462579722566240943==-- From tarek@infocom.ai Sat Apr 13 23:24:46 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sat, 13 Apr 2024 16:24:07 -0700 Message-ID: <67707AA6-627E-45B2-A640-3F2CC54D81DD@infocom.ai> In-Reply-To: <91A4828C-EE16-4900-ADEF-04B284B3B128@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6378352228328349174==" --===============6378352228328349174== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Plato experience is still active including the games at https://www.cyber1.o= rg/ Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675 https://tarek.computer INFOCOM AI LLC - https://infocom.ai > On Apr 13, 2024, at 10:20, Paul Koning via cctalk = wrote: >=20 > =EF=BB=BF >=20 >> On Apr 12, 2024, at 9:49 PM, ben via cctalk wrot= e: >>=20 >> On 2024-04-12 7:23 p.m., Paul Koning via cctalk wrote: >>>>> On Apr 12, 2024, at 5:54 PM, CAREY SCHUG via cctalk wrote: >>>>>=20 >>>>> ... >>>>> my favorite terminal 3190 that was neon gas, so monochrome, but could t= ake 5 addresses, and flip between 62 lines of 160 characters (always there), = to 4 terminals of 62x80 any two visible at a time, or 4 terminals of 31x160 c= haracters, any 2 visible at a time, or 4 terminals of 31x80 all visible at on= ce. when given a choice, my new boss was surprised that I chose that instead= of the color 3279 with graphics that everybody else wanted. Great for runni= ng virtual systems... >>> Sounds like the plasma panel displays that were invented for the PLATO sy= stem, by Don Bitzer and a few others, at the U of Illinois. Inherent memory:= if you lit a pixel it would stay lit, to turn it off you'd feed it a pulse o= f the opposite polarity. So it was a great way to do 512x512 bitmap graphics= with very modest complexity, no refresh memory needed. >>> paul >>=20 >> But too slow I suspect to run a game like spacewar. >=20 > PLATO was the system where a whole lot of early games first appeared, espec= ially multi-player games. Among them were any number of variations of "Star = Trek" inspired ones. While you couldn't refresh a screen full of space ships= in motion as fast as you can on a dedicated graphics engine, it was certainl= y acceptable for the players. And a simpler two-ship game like the original = spacewar would work even better, because you'd only need a couple of operatio= ns per refresh -- on the classic terminal, 12 output words at 60 per second, = so 200 ms per refresh. Not quite "full motion" but close. >=20 > paul >=20 --===============6378352228328349174==-- From sellam.ismail@gmail.com Sun Apr 14 00:07:43 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems (was: Re: Re: IBM 360) Date: Sat, 13 Apr 2024 17:07:22 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8167260429050840085==" --===============8167260429050840085== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Apr 12, 2024 at 9:45 AM Christian Kennedy via cctalk < cctalk(a)classiccmp.org> wrote: > > While on the topic of odd IBM mass storage systems, does anyone recall > an IBM system that used rotating carousels holding sheets of magnetic > material? The carousel would rotate to position the selected sheet into > the read/write station, where it would be moved up and down relative to > the multiple fixed heads, a weird linear riff on a fixed head disk. > > LBL had one of these systems, installed in the same room as one of the > few examples of the IBM 1360 photo digital storage system. They kept a > broom next to the later in order to sweep up the photo chips when the > thing occasionally spewed them everywhere. > I don't know if you saw it but the video at this link that Len Shustek posted shows a machine very similar to what you describe ==> https://www.computerhistory.org/collections/catalog/102740069 Sellam --===============8167260429050840085==-- From cisin@xenosoft.com Sun Apr 14 00:19:45 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems (was: Re: Re: IBM 360) Date: Sat, 13 Apr 2024 17:19:38 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6313058213745929758==" --===============6313058213745929758== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 12, 2024 at 9:45=E2=80=AFAM Christian Kennedy via cctalk wrote: > While on the topic of odd IBM mass storage systems, does anyone recall > an IBM system that used rotating carousels holding sheets of magnetic > material? The carousel would rotate to position the selected sheet into > the read/write station, where it would be moved up and down relative to > the multiple fixed heads, a weird linear riff on a fixed head disk. Nowhere near as cool, . . . About 30 years ago? (When libraries would DEDICATE a PC for each CDROM that they had) Keith Hensen made a device consisting of a carousel holding 240=20 CD/CD-ROM/DVDs. It had a name something like "Qubik"? It was in a square box with a smoked plexiglass cover, with a drive at=20 each corner. They were stackable. The drives were SCSI, the carousel controls were RS232. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============6313058213745929758==-- From ard.p850ug1@gmail.com Sun Apr 14 06:40:38 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Versatec Electrostatic Printers (was :Re: Re: Odd IBM mass storage systems) Date: Sun, 14 Apr 2024 07:40:21 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5260746486543773485==" --===============5260746486543773485== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Apr 13, 2024 at 10:48 PM Jon Elson via cctalk wrote: > Yes, there were a number of Versatec models for different > paper sizes and pixel density. Does anyone else have one in their collection? I have an ICL-badged V80 which has a GPIB interface to link it to a PERQ. I also have the schematics, etc for the plain V80 but nothing on the GPIB interface (ether user or service data). IIRC the V80 is based round a Texas 16-bit microprocessor with some AM2900-series sequencers and ROMs to control the electrode timing. As Jon said in the bit I deleted, there's a 'nib electrode' under the paper and a segmented backing electrode above it. The charge image is built up on the paper, then the toner is flowed over it and the carbon (I assume) particles adhere to the charged bits. No drying heater in mine. -tony --===============5260746486543773485==-- From useddec@gmail.com Sun Apr 14 07:02:03 2024 From: Paul Anderson To: cctalk@classiccmp.org Subject: [cctalk] Re: Versatec Electrostatic Printers (was :Re: Re: Odd IBM mass storage systems) Date: Sun, 14 Apr 2024 02:01:48 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2768428599743329776==" --===============2768428599743329776== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have a Versatec interface here somewhere, but I don't remember if it is for an 8 or 11. Paul On Sun, Apr 14, 2024 at 1:40=E2=80=AFAM Tony Duell via cctalk wrote: > On Sat, Apr 13, 2024 at 10:48=E2=80=AFPM Jon Elson via cctalk > wrote: > > > Yes, there were a number of Versatec models for different > > paper sizes and pixel density. > > Does anyone else have one in their collection? > > I have an ICL-badged V80 which has a GPIB interface to link it to a > PERQ. I also have the schematics, etc for the plain V80 but nothing on > the GPIB interface (ether user or service data). IIRC the V80 is based > round a Texas 16-bit microprocessor with some AM2900-series sequencers > and ROMs to control the electrode timing. > > As Jon said in the bit I deleted, there's a 'nib electrode' under the > paper and a segmented backing electrode above it. The charge image is > built up on the paper, then the toner is flowed over it and the carbon > (I assume) particles adhere to the charged bits. No drying heater in > mine. > > -tony > --===============2768428599743329776==-- From nico@farumdata.dk Sun Apr 14 07:54:30 2024 From: Nico de Jong To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sun, 14 Apr 2024 09:35:29 +0200 Message-ID: In-Reply-To: <74C8377D-FAB8-4F19-98B3-4DBA7391FC0F@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7508199792385635334==" --===============7508199792385635334== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-13 19:22, Paul Koning via cctalk wrote: > >> On Apr 12, 2024, at 9:55 PM, ben via cctalk wrot= e: >> >> Did any one ever use a keyboard to magtape as input device? > My wife did, sort of: for a while she worked with IBM MT/ST word processors= . Those were very early word processing systems that used a custom magnetic = tape cartridge for storage and a Selectric typewriter for I/O. > > paul In the early 70's, my (then) employer used a number of Mohawk Data Entry=20 systems : keyboard to open-reel tapes. The error rate was horrendous.=20 When unrecoverable errors occurred, the whole tape had to be re-typed.=20 They did not last very long. /Nico --===============7508199792385635334==-- From paulkoning@comcast.net Sun Apr 14 17:15:45 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sun, 14 Apr 2024 13:15:35 -0400 Message-ID: <4C0FF0A3-2542-48BF-A272-BD18E8E354AB@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4244118946627179467==" --===============4244118946627179467== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 13, 2024, at 5:48 PM, Jon Elson via cctalk = wrote: >=20 > On 4/12/24 20:21, Paul Koning via cctalk wrote: >>=20 >>> On Apr 12, 2024, at 7:48 PM, Van Snyder via cctalk wrote: >>>=20 >>> ... The other was to print on its "whippet" >>> printer, a very fast electrostatic printer that put soot onto a thermal >>> paper that was then heated to "fix" it. There was a huge variac under >>> the printer to adjust the heater. The perfect setting was between two >>> windings. Too cold and the soot fell off. Too hot and it was melted and >>> smeared into an almost illegible mess. But it was very fast -- and only >>> 80 columns wide. It was about the size of a KSR-33. >> Different beast, but it reminds me of an electrostatic plotter we at on th= e U of Illinois PLATO system. That one was by Versatec, either 11 or 17 inch= es wide (I forgot), 300 dpi, pretty sure it used wet toner. It also used a c= hain drive for the paper feed, which had enough backlash that starting and st= opping would produce visible irregularities in the output. So I wrote a driv= er for it that did overlapped I/O to avoid that problem. (File I/O directly = from a PPU program, lots of fun!) >>=20 >> With that, it did an awesome job printing musical scores. >=20 > Yes, there were a number of Versatec models for different paper sizes and p= ixel density. I worked with a bunch of 1200A units, they could run either ro= ll or fanfold paper at 11" width. The paper was clay coated and felt like a = dirty chalkboard. The toner was quite smelly, some kind of paraffin oil with= carbon particles suspended in it. There was a blower to evaporate the toner= solvent. The 1200A had 200 pixels/inch, so you got 2112 pixels across the p= age, IIRC. it applied 800 V to the writing electrodes, and something like 40= 0 V to the segmented backplate that was on the opposite side of the paper. I= t could print text at about 1200 LPM, which was pretty fantastic for the time. >=20 > But, I am glad to not have to deal with these things anymore! Indeed. Meanwhile, it turns out my memory was faulty. The printer I was describing s= ounds a lot like the Versatec ones you mentioned, including the funny paper a= nd smelly toner. But it was actually made by Varian, and the driver tells me= it had 1408 pixels across the width of the paper, so at 11 inches wide that = would make it 128 PPI. I wonder if I still have a sample page or two from th= at printer. paul --===============4244118946627179467==-- From mhs.stein@gmail.com Sun Apr 14 17:38:18 2024 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Other input devices. Date: Sun, 14 Apr 2024 13:38:01 -0400 Message-ID: In-Reply-To: <26b51884-33e6-4cb2-bdf2-a84e0b635f4b@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4889668652832580920==" --===============4889668652832580920== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I scrapped a similar Redactron mag card Selectric unit 30-odd years ago; still have the card drives, shoulda kept the Selectric. On Sat, Apr 13, 2024 at 3:47 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 4/13/24 11:22, Michael Thompson via cctalk wrote: > >>> On Apr 12, 2024, at 9:55 PM, ben via cctalk > >> wrote: > >>> > >>> Did any one ever use a keyboard to magtape as input device? > >> > >> My wife did, sort of: for a while she worked with IBM MT/ST word > >> processors. Those were very early word processing systems that used a > >> custom magnetic tape cartridge for storage and a Selectric typewriter > for > >> I/O. > > The mag card Selectric (MC/ST) was relatively popular also. > > --Chuck > > > --===============4889668652832580920==-- From artgodwin@gmail.com Sun Apr 14 18:11:32 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Versatec Electrostatic Printers (was :Re: Re: Odd IBM mass storage systems) Date: Sun, 14 Apr 2024 19:11:17 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3135696833135500072==" --===============3135696833135500072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit It wasn't just Versatec plotters that used this mixture - standard office photocopiers also had clay-coated paper and liquid toner. I don't know what allowed the change to plain-paper copiers (which use an intermediate photosensitive drum, like a laser printer) but it was probably the expiry of a patent, maybe Xerox's. On Sun, Apr 14, 2024 at 8:02 AM Paul Anderson via cctalk < cctalk(a)classiccmp.org> wrote: > I have a Versatec interface here somewhere, but I don't remember if it is > for an 8 or 11. > > Paul > > On Sun, Apr 14, 2024 at 1:40 AM Tony Duell via cctalk < > cctalk(a)classiccmp.org> > wrote: > > > On Sat, Apr 13, 2024 at 10:48 PM Jon Elson via cctalk > > wrote: > > > > > Yes, there were a number of Versatec models for different > > > paper sizes and pixel density. > > > > Does anyone else have one in their collection? > > > > I have an ICL-badged V80 which has a GPIB interface to link it to a > > PERQ. I also have the schematics, etc for the plain V80 but nothing on > > the GPIB interface (ether user or service data). IIRC the V80 is based > > round a Texas 16-bit microprocessor with some AM2900-series sequencers > > and ROMs to control the electrode timing. > > > > As Jon said in the bit I deleted, there's a 'nib electrode' under the > > paper and a segmented backing electrode above it. The charge image is > > built up on the paper, then the toner is flowed over it and the carbon > > (I assume) particles adhere to the charged bits. No drying heater in > > mine. > > > > -tony > > > --===============3135696833135500072==-- From van.snyder@sbcglobal.net Sun Apr 14 18:50:21 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sun, 14 Apr 2024 11:50:08 -0700 Message-ID: In-Reply-To: <4C0FF0A3-2542-48BF-A272-BD18E8E354AB@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4955014688869069109==" --===============4955014688869069109== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 2024-04-14 at 13:15 -0400, Paul Koning via cctalk wrote: > The printer I was describing sounds a lot like the Versatec ones you > mentioned, including the funny paper and smelly toner. But it was > actually made by Varian, and the driver tells me it had 1408 pixels > across the width of the paper, so at 11 inches wide that would make > it 128 PPI. I wonder if I still have a sample page or two from that > printer. American Geophysical had a fleet of trucks fitted with hydraulic "thumpers." They would go out to a potential oil or gas field, lay out a few thousand feet of cables with geophones on them, and drive around thumping the ground. Within the truck, they had Varian V70 computers with microcode to do Fast Fourier Transforms. They also had Varian electrostatic printers fitted for 36-inch paper on hundred-foot rolls. I never visited one, so I don't know whether they had funny paper and smelly toner. --===============4955014688869069109==-- From paulkoning@comcast.net Sun Apr 14 19:11:31 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sun, 14 Apr 2024 15:11:24 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2181091910145853312==" --===============2181091910145853312== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 14, 2024, at 2:50 PM, Van Snyder via cctalk wrote: >=20 > On Sun, 2024-04-14 at 13:15 -0400, Paul Koning via cctalk wrote: >> The printer I was describing sounds a lot like the Versatec ones you >> mentioned, including the funny paper and smelly toner. But it was >> actually made by Varian, and the driver tells me it had 1408 pixels >> across the width of the paper, so at 11 inches wide that would make >> it 128 PPI. I wonder if I still have a sample page or two from that >> printer. >=20 > American Geophysical had a fleet of trucks fitted with hydraulic > "thumpers." They would go out to a potential oil or gas field, lay out > a few thousand feet of cables with geophones on them, and drive around > thumping the ground. Within the truck, they had Varian V70 computers > with microcode to do Fast Fourier Transforms.=20 I remember a Varian computer sitting in a corner of a lab at U of Illinois (c= omputer science department). It looks similar to the ones shown in Bitsavers= but not quite the same -- it had a front panel that had mostly brown colorin= g, and the panel was totally flat. It used membrane pushbuttons for operatio= n, with the button positions marked by circles on the flat plastic front pane= l. Does that ring any bells? I remember being told it had user programmable mic= rocode, but I never used it, in fact I never heard of anyone using it. paul --===============2181091910145853312==-- From van.snyder@sbcglobal.net Sun Apr 14 20:02:50 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Sun, 14 Apr 2024 13:02:39 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2579908896123757749==" --===============2579908896123757749== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 2024-04-14 at 15:11 -0400, Paul Koning wrote: > > On Apr 14, 2024, at 2:50 PM, Van Snyder via cctalk < > > cctalk(a)classiccmp.org> wrote: > > On Sun, 2024-04-14 at 13:15 -0400, Paul Koning via cctalk wrote: > > > The printer I was describing sounds a lot like the Versatec ones > > > youmentioned, including the funny paper and smelly toner. But it > > > wasactually made by Varian, and the driver tells me it had 1408 > > > pixelsacross the width of the paper, so at 11 inches wide that > > > would makeit 128 PPI. I wonder if I still have a sample page or > > > two from thatprinter. > > > > American Geophysical had a fleet of trucks fitted with > > hydraulic"thumpers." They would go out to a potential oil or gas > > field, lay outa few thousand feet of cables with geophones on them, > > and drive aroundthumping the ground. Within the truck, they had > > Varian V70 computerswith microcode to do Fast Fourier Transforms. > > I remember a Varian computer sitting in a corner of a lab at U of > Illinois (computer science department). It looks similar to the ones > shown in Bitsavers but not quite the same -- it had a front panel > that had mostly brown coloring, and the panel was totally flat. It > used membrane pushbuttons for operation, with the button positions > marked by circles on the flat plastic front panel. > > Does that ring any bells? I remember being told it had user > programmable microcode, but I never used it, in fact I never heard of > anyone using it. Varian bought Data Machines Inc, which had a computer called 620i. It fit in a 9U rack unit. When Varian built the V70 series, they fit in a 4U unit. Varian implemented the 620 instruction set, with a few extensions, in microcode ROM, and called it 620f. Writable Control Store (WCS) was an extra-cost option. WCS came in blocks of 512 64-bit words. I think three blocks of WCS could be added. My senior undergraduate project consisted of writing microcode for a V73 to implement the IBM 1130 instruction set. That fit in about 450 words. I did that because the University had replaced their 1130 with the V73, and then discovered that Varian didn't offer a COBOL compiler, and they wanted to continue to teach COBOL. As one would expect, I/O is quite different, and there wasn't room to do it in micocode in the one block of WCS they had bought, so two faculty members, Frank Kollar and Delmorris Blakely, both expert with IBM 1130 and V73, wrote I/O support that ran in 620f mode. 1130 support was put onto the removable paltter in the Winchester drive. A switch was added to exchange the "drive numbers" so the boot key loaded either VORTEX or the 1130 support, so COBOL students didn't need to learn how to use the VORTEX command shell. In the end, the V73 pretending to be an 1130 was up to thirty times faster. If anybody wants the microcode (and flow charts), I can send it. I never had the I/O support in electronic form, and I gave the listings to the Computer History Museum many years ago. Maybe Al Kossow scanned them, maybe not. Varian Data Machines was sold to Unisys, who pounded it into the ground. --===============2579908896123757749==-- From classiccmp@earthlink.net Sun Apr 14 21:51:44 2024 From: "David C. Jenner" To: cctalk@classiccmp.org Subject: [cctalk] Re: Versatec Electrostatic Printers (was :Re: Re: Odd IBM mass storage systems) Date: Sun, 14 Apr 2024 14:46:36 -0700 Message-ID: <8943295f-e750-469c-8691-6202b18d9a4c@earthlink.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4857559879908728471==" --===============4857559879908728471== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The US Letter size of folded Versatec paper came in a cardboard box that was really good for compartmentalizing small stuff and stacking for storage!  I used to scrounge around the waste containers for empty, used boxes. Still have many in use. Dave On 4/13/24 11:40 PM, Tony Duell via cctalk wrote: > On Sat, Apr 13, 2024 at 10:48 PM Jon Elson via cctalk > wrote: > >> Yes, there were a number of Versatec models for different >> paper sizes and pixel density. > Does anyone else have one in their collection? > > I have an ICL-badged V80 which has a GPIB interface to link it to a > PERQ. I also have the schematics, etc for the plain V80 but nothing on > the GPIB interface (ether user or service data). IIRC the V80 is based > round a Texas 16-bit microprocessor with some AM2900-series sequencers > and ROMs to control the electrode timing. > > As Jon said in the bit I deleted, there's a 'nib electrode' under the > paper and a segmented backing electrode above it. The charge image is > built up on the paper, then the toner is flowed over it and the carbon > (I assume) particles adhere to the charged bits. No drying heater in > mine. > > -tony --===============4857559879908728471==-- From cz@bunsen.crystel.com Mon Apr 15 04:52:42 2024 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Thu, 11 Apr 2024 00:14:11 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB52692F418F9BA8B1B1A60712B5052=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0131672252341005015==" --===============0131672252341005015== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Quniverter perhaps? C On 4/10/2024 8:07 PM, W2HX via cctalk wrote: > Great! thank you Glen and also Michael T. for the identifications. > So this appears to be a PDP-11/23 with this FC-202 floppy controller. >=20 > 1. I have read that the card and the drives were compatible with the dec rx= 02 drives. Why would the CRDS even bother to redesign a card where DEC had pe= rfectly good working ones? Anyone know if there is any value in keeping the F= C-202 or just keep with the DEC cards? >=20 > 2. Any idea on that other card? https://w2hx.com/?prefix=3Dx/What-Is-It/PDP= -11-Thing/Board1/ >=20 > Thanks guys! >=20 > 73 Eugene W2HX > My Youtube Channel:=C2=A0https://www.youtube.com/@w2hx/videos > =20 >=20 > -----Original Message----- > From: Glen Slick via cctalk > Sent: Wednesday, April 10, 2024 7:44 PM > To: General Discussion: On-Topic and Off-Topic Posts > Cc: Glen Slick > Subject: [cctalk] Re: PDP-11 thingy. What is it? >=20 > On Wed, Apr 10, 2024, 4:14=E2=80=AFPM W2HX via cctalk wrote: >=20 >> Hi all, I picked up this PDP-11 thing. Can anyone help me understand >> what it is? >> Pictures are here: >> https://w2hx.com/?prefix=3Dx/What-Is-It/PDP-11-Thing/ >> >> I could not find any designation on the backplane. It is a >> wire-wrappable backplane. I don't know if it is Qbus, unibus or >> whether it is 18 or 22 bit addressing (this is because I am a newbie in th= is area). >> >=20 > H9270 Backplane, Page 366 (page 376 of the pdf) >=20 > http://www.bitsavers.org/pdf/dec/qbus/EB-23144-18_QbusIntrfs_1983.pdf --===============0131672252341005015==-- From w2hx@w2hx.com Mon Apr 15 04:52:45 2024 From: W2HX To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Thu, 11 Apr 2024 21:20:55 +0000 Message-ID: In-Reply-To: <2e95568e-0f78-db16-4872-7ef7978bd057@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9204764562669060304==" --===============9204764562669060304== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thanks everyone! 73 Eugene W2HX My Youtube Channel: https://www.youtube.com/@w2hx/videos -----Original Message----- From: Carlos E Murillo-Sanchez via cctalk Sent: Thursday, April 11, 2024 12:37 AM To: Glen Slick via cctalk Cc: Carlos E Murillo-Sanchez Subject: [cctalk] Re: PDP-11 thingy. What is it? Glen Slick via cctalk wrote: > On Wed, Apr 10, 2024, 7:22 PM Carlos E Murillo-Sanchez via cctalk < > cctalk(a)classiccmp.org> wrote: > >> Jonathan Chapman via cctalk wrote: >>>> 1. I have read that the card and the drives were compatible with >>>> the >> dec rx02 drives. Why would the CRDS even bother to redesign a card >> where DEC had perfectly good working ones? Anyone know if there is >> any value in keeping the FC-202 or just keep with the DEC cards? >>> A lot of the third-party controllers could talk to Shugart-style 8" >> floppy drives. They can also usually *format* the diskettes, which >> the >> RX01/RX02 systems from DEC can't do -- you have to use preformatted media. >> This isn't a *huge* deal since RX01 is just IBM 3740 and you can >> format it on CP/M boxes, with ImageDisk, etc. There's an XXDP utility >> to upconvert >> RX01 media to RX02, which is M2FM and very few things can work with it. >>> Apparently a lot of small shops kept a CP/M box just for the task, >>> the >> Alspa ACI-2 I had was supposedly used like that. >>>> 2. Any idea on that other card? >> https://w2hx.com/?prefix=x/What-Is-It/PDP-11-Thing/Board1/ >>> Looks like a non-DEC Qniverter -- QBus to Unibus converter. If >>> that's >> what it is, you'd plug your Unibus cable into that pair of connectors >> on top and run it to whatever Unibus device you were wanting to talk >> to, potentially another backplane full of Unibus stuff. Commonish >> upgrade on e.g. CNC machines that were originally controlled by a >> PDP-11/05 or something in one Unibus chassis, with another Unibus >> chassis full of machine-specific cards. >>> Thanks, >>> Jonathan >>> . >>> >> I spy two AM2901 4-bit slice ALUs, two N82S181 1024x8 PROMs, three >> AM2911 microprogram sequencers, and an SN74150 3-to-8 line decoder. >> This thing is doing arithmetic. >> >> Carlos. > > That is not an unusual bit slice architecture for a drive controller. > > This Dilog DQ419 also has two AM2901 ALUs and three AM2911 sequencers, > and what appears to be six microcode PROMs. > > https://avitech.com.au/?page_id=847 How interesting, thanks! The knowledge in this list never ceases to amaze me. Carlos. --===============9204764562669060304==-- From cz@bunsen.crystel.com Mon Apr 15 04:53:43 2024 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Drum memory on pdp11's? Wikipedia thinks so.... Date: Sat, 13 Apr 2024 21:26:35 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6122996442920262583==" --===============6122996442920262583== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Was reading the Wikipedia article on Drum memories: https://en.wikipedia.org/wiki/Drum_memory#External_links And came across this tidbit. As late as 1980, PDP-11/45 machines using magnetic core main memory and drums for swapping were still in use at many of the original UNIX sites. Any thoughts on what they are talking about? I could see running the RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's talk to memory directly instead of the Unibus, but that's not quite the same as true drum memory. Closest thing I remember was the DF32 on a pdp8 which could be addressed by word as opposed to track/sector. Thoughts? C --===============6122996442920262583==-- From paul@frixxon.co.uk Mon Apr 15 07:23:03 2024 From: Paul Flo Williams To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 08:06:06 +0100 Message-ID: <20240415080606.4303e7d4@chopoc.localdomain> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9171195247090423709==" --===============9171195247090423709== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 13 Apr 2024 17:26:31 -0400 Christopher Zach via cctalk wrote: > Was reading the Wikipedia article on Drum memories: > > https://en.wikipedia.org/wiki/Drum_memory#External_links > > And came across this tidbit. > > As late as 1980, PDP-11/45 machines using magnetic core main memory > and drums for swapping were still in use at many of the original UNIX > sites. This uncited claim was introduced 15 years ago, along with the commit comment "Hey, I saw drums (and core memory!) on PDP 11/45 hardware running UNIX v6 (pre-BSD) in 1980 ... " So, someone anonymous saw some once, somewhere, and promoted this to "many sites." --===============9171195247090423709==-- From cz@bunsen.crystel.com Mon Apr 15 13:02:51 2024 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 08:33:33 -0400 Message-ID: <74fd1404-13ff-40f1-8417-d6a6cf525ac7@bunsen.crystel.com> In-Reply-To: <20240415080606.4303e7d4@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9102544567253948212==" --===============9102544567253948212== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > This uncited claim was introduced 15 years ago, along with the commit > comment "Hey, I saw drums (and core memory!) on PDP 11/45 hardware > running UNIX v6 (pre-BSD) in 1980 ... " > > So, someone anonymous saw some once, somewhere, and promoted this to > "many sites." > Well, I can submit a correction, but does anyone remember /dev/drum? I don't recall that in V6m or V7 Unix, I guess I could fire one of them up and see.... Speaking of which I should make a copy of those disk packs for SIMH. They are genned for a dual RL01 11/34 system and while I recall they also worked on an 11/23 I don't have a pair of RL01's anymore (just an RL02 I can re-jumper to read RL01 packs but NEVER WRITE THEM) --===============9102544567253948212==-- From paulkoning@comcast.net Mon Apr 15 13:25:35 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 09:25:03 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5493048966095864607==" --===============5493048966095864607== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 13, 2024, at 5:26 PM, Christopher Zach via cctalk wrote: >=20 > Was reading the Wikipedia article on Drum memories: >=20 > https://en.wikipedia.org/wiki/Drum_memory#External_links >=20 > And came across this tidbit. >=20 > As late as 1980, PDP-11/45 machines using magnetic core main memory and dru= ms for swapping were still in use at many of the original UNIX sites. >=20 > Any thoughts on what they are talking about? I could see running the RS03/R= S04 on a 11/45 with the dual Unibus configured so the RS03's talk to memory d= irectly instead of the Unibus, but that's not quite the same as true drum mem= ory. >=20 > Closest thing I remember was the DF32 on a pdp8 which could be addressed by= word as opposed to track/sector. >=20 > Thoughts? > C I don't know of any drums on PDP-11 systems. RS03/04 are of course fixed hea= d disks, as are the earlier RF11 and RC11/RS64. All these are functional ana= logs of drums in that they have no seek time. Are drums usually word address= able? That doesn't seem necessary, not unless you use them as main memory. = Even the early ARMAC (1956-ish) which uses a drum for main memory doesn't rea= lly need it to be word-addressable because it had a one-track buffer memory (= think of it as an early cache). If you want word-addressable, the RF11 will = do that. Not the RC11, it has 32 word sectors. paul --===============5493048966095864607==-- From paulkoning@comcast.net Mon Apr 15 13:40:42 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 09:40:13 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8467008396310233871==" --===============8467008396310233871== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 13, 2024, at 5:26 PM, Christopher Zach via cctalk wrote: >=20 > Was reading the Wikipedia article on Drum memories: >=20 > https://en.wikipedia.org/wiki/Drum_memory#External_links I noticed the question was asked (but not answered): what is the largest stor= age capacity found in drums? I commented that it's at least 512k 27-bit word= s, which is the size of the Electrologica X8 drum, circa 1970. That reminded me the TU Eindhoven replaced their X8 by a Burroughs 6700 syste= m, which also had a drum. I remember a cube about a meter wide. But I don't= remember its capacity and can't find anything on Bitsavers that even mention= s drums on any Burroughs mainframe. Does anyone know? paul --===============8467008396310233871==-- From lists@glitchwrks.com Mon Apr 15 13:46:06 2024 From: Jonathan Chapman To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 13:45:04 +0000 Message-ID: In-Reply-To: <74fd1404-13ff-40f1-8417-d6a6cf525ac7@bunsen.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8337306432887939687==" --===============8337306432887939687== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Well, I can submit a correction, but does anyone remember /dev/drum? I > don't recall that in V6m or V7 Unix, I guess I could fire one of them up > and see.... There's at least references to /dev/drum in 2.11BSD, I forget if it was in th= e docs or actually important stuff in the source. I don't have my PDP-11/83 s= et up at the moment to check! Thanks, Jonathan --===============8337306432887939687==-- From bill.gunshannon@hotmail.com Mon Apr 15 13:51:01 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 09:49:41 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CulN9=5FmExYGZ3CSCy0F7=5F9pHyk2PPrlFgklnRM03rE6Biie?= =?utf-8?q?kPtrTJ5Mh5iGNa5yI6yd11iJjENjJ-L6mFOezzqHt3syePfz5QKawe-m3B-E4=3D?= =?utf-8?q?=40glitchwrks=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2562552385013156391==" --===============2562552385013156391== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/15/2024 9:45 AM, Jonathan Chapman via cctalk wrote: >> Well, I can submit a correction, but does anyone remember /dev/drum? I >> don't recall that in V6m or V7 Unix, I guess I could fire one of them up >> and see.... >=20 > There's at least references to /dev/drum in 2.11BSD, I forget if it was in = the docs or actually important stuff in the source. I don't have my PDP-11/83= set up at the moment to check! >=20 I just fired up my running copy and while there is a /dev/drum device there does not appear to be any mention of it anywhere in the file system, not even in the sources. Not sure what that means. Have to try a deeper search but that will take some time to run. bill --===============2562552385013156391==-- From bill.gunshannon@hotmail.com Mon Apr 15 14:00:02 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 09:59:44 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737FECFB920E410048CB259ED092=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2316458379450040516==" --===============2316458379450040516== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit A README in the root of 2.11 says: The following manual pages are NOT in 2.10BSD but ARE in 4.3BSD: and one of them is drum.4 so, I guess we need to look at a 4.3BSD system to find out what drum they are talking about. I have a feeling this is a device that works on the VAX but is actually not found on any PDP-11. Why it automatically makes the device node is beyond me. bill --===============2316458379450040516==-- From billdegnan@gmail.com Mon Apr 15 14:01:03 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 10:00:43 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8738097539850805377==" --===============8738097539850805377== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 15, 2024 at 12:53 AM Christopher Zach via cctalk < cctalk(a)classiccmp.org> wrote: > > > As late as 1980, PDP-11/45 machines using magnetic core main memory > and drums for swapping were still in use at many of the original UNIX > sites. > > Any thoughts on what they are talking about? I could see running the > RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's talk > to memory directly instead of the Unibus, but that's not quite the same > as true drum memory. > > I'll bet the source was talking about large contemporary storage units that looked like drums or may have been called "drums" but were not actual 50's drum memory with tubes and such. There was no rotating drum storage, the media rotates in the PDP era. Take a look at any pdp 11 peripheral handbook, there would be drum memory there if it was an official product. Bill --===============8738097539850805377==-- From dj.taylor4@comcast.net Mon Apr 15 16:06:38 2024 From: Douglas Taylor To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 12:06:06 -0400 Message-ID: <8742bc56-f2c7-43ce-b69e-090110577adb@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3733850028977142186==" --===============3733850028977142186== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit At the VFC East just a few days ago a young man came up to me, I had a PDP11/53 on display, and showed me pictures of his 11/45 and PDP-8 that he had just acquired and needed to learn about.  It was impressive, he said the 11/45 was missing the memory boards.  If he shows up here on the list please help him.  To me, it look like he had stumbled into a Unicorn. Doug On 4/13/2024 5:26 PM, Christopher Zach via cctalk wrote: > Was reading the Wikipedia article on Drum memories: > > https://en.wikipedia.org/wiki/Drum_memory#External_links > > And came across this tidbit. > >  As late as 1980, PDP-11/45 machines using magnetic core main memory > and drums for swapping were still in use at many of the original UNIX > sites. > > Any thoughts on what they are talking about? I could see running the > RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's > talk to memory directly instead of the Unibus, but that's not quite > the same as true drum memory. > > Closest thing I remember was the DF32 on a pdp8 which could be > addressed by word as opposed to track/sector. > > Thoughts? > C --===============3733850028977142186==-- From bitwiz@12bitsbest.com Mon Apr 15 16:53:32 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 11:33:00 -0500 Message-ID: <35cc2a41-eb17-447c-aaaf-e51ca1889066@12bitsbest.com> In-Reply-To: <8742bc56-f2c7-43ce-b69e-090110577adb@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1120376668892690967==" --===============1120376668892690967== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit There was drum storage for the early PDP-8 the "Straight 8", PDP-9 and PDP-10.  Each drum stored 32,768 words.  Up to 8 of them could be connected for a total storage of 262,144 words of storage. IBM made a 5BM drum storage unit that was the side of a small refrigerator: The RAMAC's disk storage unit, the IBM 350, weighed over a ton, had to be moved around with forklifts, and was delivered via large cargo airplanes. It stored approximately 5MB of data: *five million 8-bit characters on fifty 24-inch-diameter disks*, a form of drum memory. On 4/15/2024 11:06 AM, Douglas Taylor via cctalk wrote: > At the VFC East just a few days ago a young man came up to me, I had a > PDP11/53 on display, and showed me pictures of his 11/45 and PDP-8 > that he had just acquired and needed to learn about.  It was > impressive, he said the 11/45 was missing the memory boards.  If he > shows up here on the list please help him.  To me, it look like he had > stumbled into a Unicorn. > Doug > > On 4/13/2024 5:26 PM, Christopher Zach via cctalk wrote: >> Was reading the Wikipedia article on Drum memories: >> >> https://en.wikipedia.org/wiki/Drum_memory#External_links >> >> And came across this tidbit. >> >>  As late as 1980, PDP-11/45 machines using magnetic core main memory >> and drums for swapping were still in use at many of the original UNIX >> sites. >> >> Any thoughts on what they are talking about? I could see running the >> RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's >> talk to memory directly instead of the Unibus, but that's not quite >> the same as true drum memory. >> >> Closest thing I remember was the DF32 on a pdp8 which could be >> addressed by word as opposed to track/sector. >> >> Thoughts? >> C > > --===============1120376668892690967==-- From sellam.ismail@gmail.com Mon Apr 15 17:01:06 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 10:00:50 -0700 Message-ID: In-Reply-To: <35cc2a41-eb17-447c-aaaf-e51ca1889066@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5792723923294007600==" --===============5792723923294007600== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit There were also spinning disk "drum" memories. I used to have one (or most of one at least). Sellam --===============5792723923294007600==-- From imp@bsdimp.com Mon Apr 15 17:10:53 2024 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 11:10:34 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB573777D8DA86CBA7D1821767ED092=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8958673334462560645==" --===============8958673334462560645== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 15, 2024 at 8:00 AM Bill Gunshannon via cctalk < cctalk(a)classiccmp.org> wrote: > > > A README in the root of 2.11 says: > > The following manual pages are NOT in 2.10BSD but ARE in 4.3BSD: > > and one of them is drum.4 > > so, I guess we need to look at a 4.3BSD system to find out what > drum they are talking about. I have a feeling this is a device > that works on the VAX but is actually not found on any PDP-11. > Why it automatically makes the device node is beyond me. > Likely because MAKEDEV was copied over from 4.3's version. We've grown spoiled with dynamic device population, but even 4.4BSD had static creation with MAKEDEV. This is just the paging device for the system. It has nothing to do with old-school hardware, apart from the name. It's a logical device that spills over all the configured swap partitions / disks. The PDP-11 2.*BSD never had /dev/drum that was functional. Warner --===============8958673334462560645==-- From uban@ubanproductions.com Mon Apr 15 17:15:47 2024 From: Tom Uban To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 12:15:40 -0500 Message-ID: In-Reply-To: <35cc2a41-eb17-447c-aaaf-e51ca1889066@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6610909963345714011==" --===============6610909963345714011== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I recall around 1980, the "A" machine at Purdue University Electrical Enginee= ring, a PDP-11/70=20 running Version 7 Unix had a RS04 drum drive used for swap. It was getting lo= ng in the tooth and=20 when a power failure occurred, someone would have to get a wrench to help spi= n it up as the head=20 lubricant was no longer as good as it once was... --tom On 4/15/24 11:33, Mike Katz via cctalk wrote: > There was drum storage for the early PDP-8 the "Straight 8", PDP-9 and PDP-= 10.=C2=A0 Each drum stored=20 > 32,768 words.=C2=A0 Up to 8 of them could be connected for a total storage = of 262,144 words of storage. > > IBM made a 5BM drum storage unit that was the side of a small refrigerator:= The RAMAC's disk=20 > storage unit, the IBM 350, weighed over a ton, had to be moved around with = forklifts, and was=20 > delivered via large cargo airplanes. It stored approximately 5MB of data: *= five million 8-bit=20 > characters on fifty 24-inch-diameter disks*, a form of drum memory. > > On 4/15/2024 11:06 AM, Douglas Taylor via cctalk wrote: >> At the VFC East just a few days ago a young man came up to me, I had a PDP= 11/53 on display, and=20 >> showed me pictures of his 11/45 and PDP-8 that he had just acquired and ne= eded to learn about.=C2=A0=20 >> It was impressive, he said the 11/45 was missing the memory boards.=C2=A0 = If he shows up here on the=20 >> list please help him.=C2=A0 To me, it look like he had stumbled into a Uni= corn. >> Doug >> >> On 4/13/2024 5:26 PM, Christopher Zach via cctalk wrote: >>> Was reading the Wikipedia article on Drum memories: >>> >>> https://en.wikipedia.org/wiki/Drum_memory#External_links >>> >>> And came across this tidbit. >>> >>> =C2=A0As late as 1980, PDP-11/45 machines using magnetic core main memory= and drums for swapping were=20 >>> still in use at many of the original UNIX sites. >>> >>> Any thoughts on what they are talking about? I could see running the RS03= /RS04 on a 11/45 with=20 >>> the dual Unibus configured so the RS03's talk to memory directly instead = of the Unibus, but=20 >>> that's not quite the same as true drum memory. >>> >>> Closest thing I remember was the DF32 on a pdp8 which could be addressed = by word as opposed to=20 >>> track/sector. >>> >>> Thoughts? >>> C >> >> --===============6610909963345714011==-- From rickb@bensene.com Mon Apr 15 17:19:18 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 17:19:08 +0000 Message-ID: <7d975133bc1e4c60850a06822b03d8d5@bensene.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8207306909846494019==" --===============8207306909846494019== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill wrote: > I'll bet the source was talking about large contemporary storage > > units that looked like drums or may have been called "drums" but=20 > were not actual 50's drum memory with tubes and such. There was no > rotat= ing drum storage, the media rotates in the PDP era. > Take a look at any pdp 11 peripheral handbook, there would be drum > memory= there if it was an official product. Remember that there was a very active third-party peripheral device market fo= r the PDP-11 series. Could be that someone offered a head-per-track drum sto= re that the person that made the update to Wikipedia may have spied. =20 On a somewhat related note, many years ago, sometime in the late 1970's to pe= rhaps no later than '81, I toured a local (Portland, OR) timesharing service = that was called "Information Sciences, Inc.". They had their datacenter in a building in downtown Portland. They offered = timeshare services on a well-built-out and heavily-modified DEC PDP-10 (KA-10= ). =20 The machine had a bunch of add-on solid-state memory boxes, as well as a real= drum memory. The drum memory unit was quite large, a box about 5 feet wide,= 4 feet tall, and probably about 3-4 feet deep. =20 The controller for the drum was another box that was about the same size as o= ne of the memory boxes, and was cool because it had a bank of lamps at the to= p of the cabinet that showed the activity of the drum. It was flickering lik= e crazy, as it was during prime-time that I was there, and they had about 180= simultaneous users on the system at the time. =20 I was told that the drum was a head-per-track unit, and revolved at 8,000 RPM= . The KA-10 had been modified to support virtual memory using a pager box of= some sort, and the drum was used to support high-speed paging and swapping. = =20 The drum was kind of ominous, as you could sense the kinetic energy that was = just waiting to be released if a bearing failed catastrophically. It had th= is low frequency resonance that felt as if it permeated the entire data cente= r. =20 The guy that took me on the tour said that the wall behind the drum had to be= specially reinforced as if the drum exited the reinforced cabinet due to som= e kind of failure while at speed, it would have gone through any conventional= wall like it was made of paper, and another wall which was the side of the b= uilding, and would have fallen 6 floors to the ground below, which obviously = would have been disastrous. =20 Apparently if there was a failure, due to the direction the drum rotated it'd= come out the back of the cabinet rather than the front. I was also told th= at the drum cabinet had special mounting that was a large structure of steel = beams in the mezzanine level beneath the datacenter that connected the mounts= to the main support beams for the building, because the gyroscopic effects o= f the drum would have torn out anything else. =20 The mounts had to be inspected every six months to look for cracks or any oth= er sign of stress-induced problems. =20 I don't know who made the drum unit, as I didn't see any tag on it, but the c= abinetry was colored a significantly darker shade of blue than the DEC boxes = were, which tells me that it was probably a third-party device. =20 I was also told that the drum had its own UPS and genset, because it would be= "bad" if it ever shut down in an unplanned way. Apparently there was a pro= cedure that involved slowing down the drum revolution in a stepwise fashion. = This apparently took something like 2 1/2 hours to perform, and was orchestra= ted by the controller. I never heard what "bad" meant in the context of the = drum powering down in an unplanned fashion, but the tone of voice of the guy = explaining it made it clear that it was something to be avoided at all cost. This was the first time that I'd ever seen a PDP-10, notably a KA-10, and I a= bsolutely fell in love with the console of the machine. It's my favorite cl= assic blinkenlights console. -Rick =20 --===============8207306909846494019==-- From van.snyder@sbcglobal.net Mon Apr 15 17:47:12 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 10:47:01 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2400563657847145524==" --===============2400563657847145524== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 2024-04-15 at 09:25 -0400, Paul Koning via cctalk wrote: > Are drums usually word addressable? That doesn't seem necessary, not unles= s you use them as main memory. Univac FH432, FH880, and FH1782 were word-addressable "flying head" drums, usually used for swap, on 1100-series and maybe 1219 as well. --===============2400563657847145524==-- From nw.johnson@ieee.org Mon Apr 15 17:48:42 2024 From: Nigel Johnson To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 13:48:31 -0400 Message-ID: <45CA7695-D294-4B31-917E-31DE9C20416B@ieee.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2875761274573762308==" --===============2875761274573762308== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable And on the humble Univac 418 we had the FH330. I have a picture of them some= where On April 15, 2024 1:47:01=E2=80=AFp.m. EDT, Van Snyder via cctalk wrote: >On Mon, 2024-04-15 at 09:25 -0400, Paul Koning via cctalk wrote: >> Are drums usually word addressable? That doesn't seem necessary, not unle= ss you use them as main memory. > >Univac FH432, FH880, and FH1782 were word-addressable "flying head" >drums, usually used for swap, on 1100-series and maybe 1219 as well. > > --===============2875761274573762308==-- From sellam.ismail@gmail.com Mon Apr 15 17:57:14 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 10:56:57 -0700 Message-ID: In-Reply-To: <7d975133bc1e4c60850a06822b03d8d5@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2379830673846060756==" --===============2379830673846060756== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 15, 2024 at 10:19 AM Rick Bensene via cctalk < cctalk(a)classiccmp.org> wrote: > Bill wrote: > > The guy that took me on the tour said that the wall behind the drum had to > be specially reinforced as if the drum exited the reinforced cabinet due to > some kind of failure while at speed, it would have gone through any > conventional wall like it was made of paper, and another wall which was the > side of the building, and would have fallen 6 floors to the ground below, > which obviously would have been disastrous. > > Apparently if there was a failure, due to the direction the drum rotated > it'd come out the back of the cabinet rather than the front. I was also > told that the drum cabinet had special mounting that was a large structure > of steel beams in the mezzanine level beneath the datacenter that connected > the mounts to the main support beams for the building, because the > gyroscopic effects of the drum would have torn out anything else. > > The mounts had to be inspected every six months to look for cracks or any > other sign of stress-induced problems. > > -Rick > A computer that literally required a specifically steel-reinforced building in order to operate. Now that's what you call Old Iron. Sellam --===============2379830673846060756==-- From paulkoning@comcast.net Mon Apr 15 17:57:24 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 13:57:16 -0400 Message-ID: <70CA36EC-2EFD-48F0-A1AC-0237A5A5CC42@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7564636398387725882==" --===============7564636398387725882== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 15, 2024, at 1:15 PM, Tom Uban via cctalk = wrote: >=20 > I recall around 1980, the "A" machine at Purdue University Electrical Engin= eering, a PDP-11/70 running Version 7 Unix had a RS04 drum drive used for swa= p. It was getting long in the tooth and when a power failure occurred, someon= e would have to get a wrench to help spin it up as the head lubricant was no = longer as good as it once was... RS04 is a fixed head disk, similar properties as a drum but shape-wise it's a= flat platter with heads on one side. The "lubricant" bit reminds me of our college RF11 swap disk (for RSTS/E). Wh= en we got the RP04 it was no longer so interesting so it was not configured i= n, but it was still powered up. One day I noticed that the "timing track error" light was lit, and since the = system was under contract we called DEC field service to repair it. The loca= l tech checked things out and realized the drive was not spinning even though= it had spindle power. Oops. He took the drive apart and discovered that th= e heads had landed, and melted so they were essentially hot-melt-glued to the= platter. Those drives use rather low powered motors, intentionally, so with= the heads stuck it would not spin up. He ended up replacing all the heads and the platter, not sure about the motor= . Got an alignment disk and timing track writer from Maynard, and had to fig= ure out how to use these -- the documentation was sparse, to put it politely.= In the end, everything worked. Oh by the way, I don't think that field rep= air of a drive like that was a standard procedure, but for Jim Newport this w= asn't a big deal. paul --===============7564636398387725882==-- From ethan.dicks@gmail.com Mon Apr 15 17:57:54 2024 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 13:57:37 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5752944341282853227==" --===============5752944341282853227== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 15, 2024 at 12:53 AM Christopher Zach via cctalk wrote: > Was reading the Wikipedia article on Drum memories: > > https://en.wikipedia.org/wiki/Drum_memory#External_links > > And came across this tidbit. > > As late as 1980, PDP-11/45 machines using magnetic core main memory > and drums for swapping were still in use at many of the original UNIX > sites. > > Any thoughts on what they are talking about? I could see running the > RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's talk > to memory directly instead of the Unibus, but that's not quite the same > as true drum memory. Yep. > Closest thing I remember was the DF32 on a pdp8 which could be addressed > by word as opposed to track/sector. Yes. And the RF series (RF08 and RF11). UNIX on the PDP-11 in 1972 required an RF11 for swap. As mentioned in other replies, the media isn't cylindrical but it behaves logically like a drum. -ethan --===============5752944341282853227==-- From cclist@sydex.com Mon Apr 15 18:20:41 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 11:15:07 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9037502097858138827==" --===============9037502097858138827== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Don't know if it's germane, but the CDC STAR-100 (Cyber 200 series) MCU used a small drum. 70s-80s. Don't recall if the stations did also. There was the "STAR Drum" blue sky that was part of the boilerplate in proposals at the time. STAR had a 512-bit wide data channel reserved for a paging device. I recall Neil Lincoln relating that they tinkered with a 100K RPM drum, but could never get it to operate for more than a few minutes. Then there was SCROLL, also mentioned in the proposals. A very wide tape wrapped around a multi-head rotating drum. I don't know if that one ever got past the pencil-and-paper stage. --Chuck --===============9037502097858138827==-- From tom94022@comcast.net Mon Apr 15 22:27:46 2024 From: Tom Gardner To: cctalk@classiccmp.org Subject: [cctalk] IBM 350 disk and 305 drum [WAS:RE: Re: Drum memory on pdp11's? Wikipedia thinks so....] Date: Mon, 15 Apr 2024 15:27:00 -0700 Message-ID: <005f01da8f84$122c9e60$3685db20$@comcast.net> In-Reply-To: <35cc2a41-eb17-447c-aaaf-e51ca1889066@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4394070393925856515==" --===============4394070393925856515== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The IBM 350 disk storage (RAMAC) has 5 million 6-bit characters or 3.75 MB; t= he actual recorded characters were 8-bits in length including a parity bit an= d a stop bit for each recorded 6-bit character =20 It was announced as part of the IBM 305 RAMAC system which had drum memory wh= ich as far as I can tell had 24 tracks of 100 6-bit characters =3D 14,400 bit= s or 1.8 kB Source: http://bitsavers.trailing-edge.com/pdf/ibm/305_ramac/22-6264-1_305_RA= MAC_Manual_of_Operation_Apr57.pdf pgs 17 &18 If anyone has a better number please post it =F0=9F=98=8A =20 Tom =20 -----Original Message----- From: Mike Katz =20 Sent: Monday, April 15, 2024 9:33 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: Douglas Taylor Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... =20 There was drum storage for the early PDP-8 the "Straight 8", PDP-9 and PDP-10= . Each drum stored 32,768 words. Up to 8 of them could be connected for a t= otal storage of 262,144 words of storage. =20 IBM made a 5BM drum storage unit that was the side of a small refrigerator: The RAMAC's disk storage unit, the IBM 350, weighed over a ton,= had to be moved around with forklifts, and was delivered via large cargo air= planes. It stored approximately 5MB of data: *five million 8-bit characters o= n fifty 24-inch-diameter disks*, a form of drum memory. =20 --===============4394070393925856515==-- From cisin@xenosoft.com Mon Apr 15 22:56:33 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: IBM 350 disk and 305 drum [WAS:RE: Re: Drum memory on pdp11's? Wikipedia thinks so....] Date: Mon, 15 Apr 2024 15:56:26 -0700 Message-ID: In-Reply-To: <005f01da8f84$122c9e60$3685db20$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5150380977393391659==" --===============5150380977393391659== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 15 Apr 2024, Tom Gardner via cctalk wrote: > The IBM 350 disk storage (RAMAC) has 5 million 6-bit characters or 3.75 MB;= the actual recorded characters were 8-bits in length including a parity bit = and a stop bit for each recorded 6-bit character > It was announced as part of the IBM 305 RAMAC system which had drum memory = which as far as I can tell had 24 tracks of 100 6-bit characters =3D 14,400 b= its or 1.8 kB > Source: http://bitsavers.trailing-edge.com/pdf/ibm/305_ramac/22-6264-1_305_= RAMAC_Manual_of_Operation_Apr57.pdf pgs 17 &18 > If anyone has a better number please post it =F0=9F=98=8A Here's what info I have on the RAMAC, from multiple sources, but derived=20 at least partially, if not entirely, from some of Tom Gardner's earlier posts. RAMAC 50 user disks (dummy disks at end to reduce turbulent buffeting) 100 sides, 100 user tracks per side (2 test only tracks on inside and=20 outside) A RAMAC character has 8 bits: 1 start bit, 6 data bits, and 1 parity bit.=20 - clarification by Tom Gardner & Joe Feng 5 sectors per track, 100 characters per sector - Grand total of 50 disks x 2 sides/disk x 100 user track/side x 5=20 sectors/track x 100 char/sector =3D 5,000,000 characters Claimed average access time 0.6 seconds, you define "average" movements=20 ;-)) However, the "IBM 650 RAMAC - Manual of Operation - Preliminary Edition"=20 states that the worst case seek, from inner track of top disk to inner track of bottom disk, was 0.8=20 seconds !! (I *really* want to see that!!) ) 2 heads, one for tracks on top side of each disk, one for bottom side - head assembly moves vertically to selected disk, then goes to selected=20 track - about 200 bits per inch - the magnetic tape density of the period. 2 hp drive motor drives the disks at 1200 RPM, 1/3 hp motor at 3450 RPM drives clutches at 1000 RPM one revolution of fully locked clutch drives arm 6 inches either in/out or=20 up down - 100 inches or 8.3 feet per second - 200 disks per second or 2000 tracks per second Wikipedia: RAMAC mechanism at Computer History Museum The IBM 350 disk storage unit, the first disk drive, was announced by IBM=20 as a component of the IBM 305 RAMAC computer system on September 13,=20 1956.[8][9][10][11] Simultaneously a very similar product, the IBM 355 was=20 announced for the IBM 650 RAMAC computer system. RAMAC stood for "Random=20 Access Method of Accounting and Control." The first engineering prototype=20 350 disk storage shipped to Zellerbach in June 1956;[12] however,=20 production shipment announced to begin "mid-1957"[13] may not have=20 occurred until as late as January 1958.[14] Its design was motivated by the need for real time accounting in=20 business.[15] The 350 stored 5 million 6-bit characters (3.75 MB).[16] It=20 has fifty 24-inch (610 mm) diameter disks with 100 recording surfaces.=20 Each surface has 100 tracks. The disks spun at 1200 RPM. Data transfer=20 rate was 8,800 characters per second. An access mechanism moved a pair of=20 heads up and down to select a disk pair (one down surface and one up=20 surface) and in and out to select a recording track of a surface pair.=20 Several improved models were added in the 1950s. The IBM RAMAC 305 system=20 with 350 disk storage leased for $3,200 per month. The 350 was officially=20 withdrawn in 1969. U.S. Patent 3,503,060 from the RAMAC program is generally considered to be=20 the fundamental patent for disk drives.[17] This first-ever disk drive was=20 initially cancelled by the IBM Board of Directors because of its threat to=20 the IBM punch card business but the IBM San Jose laboratory continued=20 development until the project was approved by IBM's president.[18] The 350's cabinet was 60 inches (152 cm) long, 68 inches (172 cm) high and=20 29 inches (74 cm) wide. The RAMAC unit weighs about one ton, has to be moved around with=20 forklifts, and was frequently transported via large cargo airplanes.[19]=20 According to Currie Munce, research vice president for Hitachi Global=20 Storage Technologies (which acquired IBM's storage business), the storage=20 capacity of the drive could have been increased beyond five million=20 characters, but IBM's marketing department at that time was against a=20 larger capacity drive, because they didn't know how to sell a product with=20 more storage. None-the-less double capacity versions of the 350 were=20 announced[8] in January 1959 and shipped later the same year. In 1984, the RAMAC 350 Disk File was designated an International Historic=20 Landmark by The American Society of Mechanical Engineers.[20] In 2002, the=20 Magnetic Disk Heritage Center began restoration of an IBM 350 RAMAC in=20 collaboration with Santa Clara University.[21] In 2005, the RAMAC=20 restoration project relocated to the Computer History Museum in Mountain=20 View, California and is now demonstrated to the public in the museum's=20 Revolution exhibition.[22] My own text, based on newspaper histories: In 1958, Nikita Khruschev visited USA, to try to de-escalet the cold war a=20 little. When he was refused permission to go to Disneyland, Frank Sinatra offered=20 to take Mrs. Khruschev to Disneyland, but that didn't happen. The secret service tried to make it up to him by arranging a tour of an=20 IBM plant in San Jose where the RAMACs were being built. I have a RAMAC platter! It was acquired sometime before 1983 by Wilson Price (one of my cow- orkers) and we used it for decades to convince beginning computer students=20 that there has been progress on size and capacity of disks.=20 It is much too damaged to be restorable. So, I made a patio table out of=20 it. It already has a specific bequest? in my will. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5150380977393391659==-- From couryhouse@aol.com Tue Apr 16 02:04:07 2024 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 02:03:55 +0000 Message-ID: <783482086.5831298.1713233035164@mail.yahoo.com> In-Reply-To: <783482086.5831298.1713233035164.ref@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3335578022847478317==" --===============3335578022847478317== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Bomar 901b My wife  found  in my stuff. Is this as scarce  at it seems?s,? Sent from AOL on Android --===============3335578022847478317==-- From ethan.dicks@gmail.com Tue Apr 16 02:32:15 2024 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP-11 thingy. What is it? Date: Mon, 15 Apr 2024 22:31:56 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CBL1PR12MB52692F418F9BA8B1B1A60712B5052=40BL1PR12MB?= =?utf-8?q?5269=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0759390688566035674==" --===============0759390688566035674== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2024 at 8:07=E2=80=AFPM W2HX via cctalk wrote: > 1. I have read that the card and the drives were compatible with the dec rx= 02 drives. Why would the CRDS even bother to redesign a card where DEC had pe= rfectly good working ones? Anyone know if there is any value in keeping the F= C-202 or just keep with the DEC cards? The easy first answer is DEC's drives were expensive so there was room for competition to bring in a less expensive product and then _they_ would get the profits. The second answer is that DEC's implementation was basic - read and write single-sided floppies and that's it - no media (re)formatting. Third parties could add features to extend what DEC had. The DEC implementation relied on a custom processor board inside the disk drive and a unique/proprietary way to have the controller tell the drives what to do. By the late 80s. Shugart interface drives were plentiful and processors like the Z-80 were totally capable so there were several RX01 and RX02 imitators. I have at least one Qbus card that just has a Shugart interface and was connected to a standard floppy drive mechanism (and it can low-level format disks). In order to work with existing drivers, though, the third party cards did have to emulate them at the I/O register level but as long as it's registers on one end and 8" media on the other, they were free to reimplement the middle part. -ethan --===============0759390688566035674==-- From organlists1@sonic.net Tue Apr 16 05:20:09 2024 From: Don R To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Mon, 15 Apr 2024 22:19:51 -0700 Message-ID: <9ECB4812-FD8A-465A-83D0-15F35972FDD1@sonic.net> In-Reply-To: <783482086.5831298.1713233035164@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2409127153837668112==" --===============2409127153837668112== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable At first I misread the subject as my 901lb wife=E2=80=A6. Man I need my eyes checked! ;o) Don Resor Sent from someone's iPhone > On Apr 15, 2024, at 7:04 PM, ED SHARPE via cctalk = wrote: >=20 > =EF=BB=BFBomar 901b My wife found in my stuff. Is this as scarce at it s= eems?s,? >=20 >=20 > Sent from AOL on Android >=20 --===============2409127153837668112==-- From cc@informatik.uni-stuttgart.de Tue Apr 16 07:17:24 2024 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Tue, 16 Apr 2024 09:17:14 +0200 Message-ID: <5fcbc180-1e1d-528e-1bde-893eee94053@informatik.uni-stuttgart.de> In-Reply-To: <8742bc56-f2c7-43ce-b69e-090110577adb@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0861000237191047573==" --===============0861000237191047573== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 15 Apr 2024, Douglas Taylor wrote: > had just acquired and needed to learn about.=C2=A0 It was impressive, he sa= id the=20 > 11/45 was missing the memory boards.=C2=A0 If he shows up here on the list = please Not unusual; my 11/45 doesn't have memory boards (for the core system),=20 too. Instead, there is a standard 128kW MOS memory board in the Unibus=20 backplane. Christian --===============0861000237191047573==-- From cc@informatik.uni-stuttgart.de Tue Apr 16 07:22:22 2024 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 09:22:14 +0200 Message-ID: <8d4c9976-8dec-8e35-78f8-1ec8eed6955@informatik.uni-stuttgart.de> In-Reply-To: <783482086.5831298.1713233035164@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7448539436234029624==" --===============7448539436234029624== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 16 Apr 2024, ED SHARPE wrote: > Bomar 901b My wife=C2=A0 found=C2=A0 in my stuff. Is this as scarce=C2=A0 a= t it seems?s,? What does that mean in English? Christian --===============7448539436234029624==-- From couryhouse@aol.com Tue Apr 16 10:34:56 2024 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 10:34:45 +0000 Message-ID: <182572525.5882568.1713263685260@mail.yahoo.com> In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185360F2B38060BA7065099E4082=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8450430827669347101==" --===============8450430827669347101== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable No bomar brand Sent from AOL on Android=20 =20 On Mon, Apr 15, 2024 at 7:15 PM, Wayne S wrote: = Bomar as in the Bomber Aircraft? Sent from my iPhone > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk w= rote: >=20 > =EF=BB=BFBomar 901b My wife=C2=A0 found=C2=A0 in my stuff. Is this as scarc= e=C2=A0 at it seems?s,? >=20 >=20 > Sent from AOL on Android =20 --===============8450430827669347101==-- From wrcooke@wrcooke.net Tue Apr 16 10:41:28 2024 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 05:41:23 -0500 Message-ID: <169868360.8237506.1713264083080@email.ionos.com> In-Reply-To: <182572525.5882568.1713263685260@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7202396248465334597==" --===============7202396248465334597== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think he means Bowmar https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk wr= ote: > > > No bomar brand > > Sent from AOL on Android > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S wrote: = Bomar as in the Bomber Aircraft? > > Sent from my iPhone > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk = wrote: > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? > > > > > > Sent from AOL on Android Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince --===============7202396248465334597==-- From couryhouse@aol.com Tue Apr 16 11:31:07 2024 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 11:30:54 +0000 Message-ID: <2085671327.5882607.1713267054945@mail.yahoo.com> In-Reply-To: <169868360.8237506.1713264083080@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2943089776020311885==" --===============2943089776020311885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes. Cell phone horrible typing The Consumer Electronics Hall of Fame: Bowmar 901B Ok can not find b pricevonly c and d Sent from AOL on Android=20 =20 On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk wrote: I think he means Bowmar https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk wr= ote: > > > No bomar brand > > Sent from AOL on Android > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S wrote: = Bomar as in the Bomber Aircraft? > > Sent from my iPhone > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk = wrote: > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? > > > > > > Sent from AOL on Android Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince =20 --===============2943089776020311885==-- From artgodwin@gmail.com Tue Apr 16 11:38:51 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 12:38:34 +0100 Message-ID: In-Reply-To: <2085671327.5882607.1713267054945@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6371338851554121556==" --===============6371338851554121556== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 901B is the first pocket calculator I remember - I don't know if there were earlier ones. I don't think they're exactly rare but later ones such as MX10 are certainly easier to find. They're often in the same case as a 901B but with slightly enhanced functionality such as 10 digits. % key etc. On Tue, Apr 16, 2024 at 12:31=E2=80=AFPM ED SHARPE via cctalk wrote: > Yes. Cell phone horrible typing > The Consumer Electronics Hall of Fame: Bowmar 901B > Ok can not find b pricevonly c and d > > Sent from AOL on Android > > On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk< > cctalk(a)classiccmp.org> wrote: I think he means Bowmar > https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > > > > > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk > wrote: > > > > > > No bomar brand > > > > Sent from AOL on Android > > > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S > wrote: Bomar as in the Bomber Aircraft? > > > > Sent from my iPhone > > > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk > wrote: > > > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? > > > > > > > > > Sent from AOL on Android > > Grownups never understand anything by themselves and it is tiresome for > children to be always and forever explaining things to them, > > Antoine de Saint-Exupery in The Little Prince > > --===============6371338851554121556==-- From couryhouse@aol.com Tue Apr 16 11:57:29 2024 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 11:57:18 +0000 Message-ID: <1227481955.5900068.1713268638774@mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7790725103035602782==" --===============7790725103035602782== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Some one got a deal on a non-working. Sunday 12 orv23 bucks Sent from AOL on Android=20 =20 On Tue, Apr 16, 2024 at 4:38 AM, Adrian Godwin wrote= : 901B is the first pocket calculator I remember - I don't know if there we= re earlier ones.=C2=A0I don't think they're exactly rare but later ones such = as MX10 are certainly easier to find. They're often in the same case as a 901= B but with slightly enhanced functionality such as 10 digits. % key etc. On Tue, Apr 16, 2024 at 12:31=E2=80=AFPM ED SHARPE via cctalk wrote: Yes. Cell phone horrible typing The Consumer Electronics Hall of Fame: Bowmar 901B Ok can not find b pricevonly c and d Sent from AOL on Android=20 =C2=A0 On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk wrote:=C2=A0 =C2=A0I think he means Bowmar https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk wr= ote: > > > No bomar brand > > Sent from AOL on Android > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S wrote: = Bomar as in the Bomber Aircraft? > > Sent from my iPhone > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk = wrote: > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? > > > > > > Sent from AOL on Android Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince =20 --===============7790725103035602782==-- From couryhouse@aol.com Tue Apr 16 11:59:21 2024 From: ED SHARPE To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 11:59:09 +0000 Message-ID: <1570750883.5889922.1713268749181@mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6756750146337928700==" --===============6756750146337928700== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I bought mine 30 years ago at garage sake. For 50 cents Sent from AOL on Android=20 =20 On Tue, Apr 16, 2024 at 4:38 AM, Adrian Godwin wrote= : 901B is the first pocket calculator I remember - I don't know if there we= re earlier ones.=C2=A0I don't think they're exactly rare but later ones such = as MX10 are certainly easier to find. They're often in the same case as a 901= B but with slightly enhanced functionality such as 10 digits. % key etc. On Tue, Apr 16, 2024 at 12:31=E2=80=AFPM ED SHARPE via cctalk wrote: Yes. Cell phone horrible typing The Consumer Electronics Hall of Fame: Bowmar 901B Ok can not find b pricevonly c and d Sent from AOL on Android=20 =C2=A0 On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk wrote:=C2=A0 =C2=A0I think he means Bowmar https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk wr= ote: > > > No bomar brand > > Sent from AOL on Android > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S wrote: = Bomar as in the Bomber Aircraft? > > Sent from my iPhone > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk = wrote: > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? > > > > > > Sent from AOL on Android Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince =20 --===============6756750146337928700==-- From sellam.ismail@gmail.com Tue Apr 16 13:38:59 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 06:38:40 -0700 Message-ID: In-Reply-To: <1570750883.5889922.1713268749181@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0341788586228802608==" --===============0341788586228802608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ed, From now on, when posting to this mailing list, can you please construct complete sentences that actually express ideas and concepts to which an ordinary human can respond? Sellam On Tue, Apr 16, 2024, 4:59=E2=80=AFAM ED SHARPE via cctalk wrote: > I bought mine 30 years ago at garage sake. For 50 cents > > Sent from AOL on Android > > On Tue, Apr 16, 2024 at 4:38 AM, Adrian Godwin > wrote: 901B is the first pocket calculator I remember - I don't know if > there were earlier ones. I don't think they're exactly rare but later ones > such as MX10 are certainly easier to find. They're often in the same case > as a 901B but with slightly enhanced functionality such as 10 digits. % key > etc. > > On Tue, Apr 16, 2024 at 12:31=E2=80=AFPM ED SHARPE via cctalk < > cctalk(a)classiccmp.org> wrote: > > Yes. Cell phone horrible typing > The Consumer Electronics Hall of Fame: Bowmar 901B > Ok can not find b pricevonly c and d > > Sent from AOL on Android > > On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk< > cctalk(a)classiccmp.org> wrote: I think he means Bowmar > https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > > > > > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk > wrote: > > > > > > No bomar brand > > > > Sent from AOL on Android > > > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S > wrote: Bomar as in the Bomber Aircraft? > > > > Sent from my iPhone > > > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk > wrote: > > > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? > > > > > > > > > Sent from AOL on Android > > Grownups never understand anything by themselves and it is tiresome for > children to be always and forever explaining things to them, > > Antoine de Saint-Exupery in The Little Prince > > > > --===============0341788586228802608==-- From mooreericnyc@gmail.com Tue Apr 16 13:46:06 2024 From: Eric Moore To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 08:45:47 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3844023531682453405==" --===============3844023531682453405== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sellam, that was unneccassarily cruel. Please try and exhibit some empathy if not kindness. -Eric On Tue, Apr 16, 2024, 8:39=E2=80=AFAM Sellam Abraham via cctalk < cctalk(a)classiccmp.org> wrote: > Ed, > > From now on, when posting to this mailing list, can you please construct > complete sentences that actually express ideas and concepts to which an > ordinary human can respond? > > Sellam > > On Tue, Apr 16, 2024, 4:59=E2=80=AFAM ED SHARPE via cctalk > wrote: > > > I bought mine 30 years ago at garage sake. For 50 cents > > > > Sent from AOL on Android > > > > On Tue, Apr 16, 2024 at 4:38 AM, Adrian Godwin > > wrote: 901B is the first pocket calculator I remember - I don't know if > > there were earlier ones. I don't think they're exactly rare but later > ones > > such as MX10 are certainly easier to find. They're often in the same case > > as a 901B but with slightly enhanced functionality such as 10 digits. % > key > > etc. > > > > On Tue, Apr 16, 2024 at 12:31=E2=80=AFPM ED SHARPE via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > > Yes. Cell phone horrible typing > > The Consumer Electronics Hall of Fame: Bowmar 901B > > Ok can not find b pricevonly c and d > > > > Sent from AOL on Android > > > > On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk< > > cctalk(a)classiccmp.org> wrote: I think he means Bowmar > > > https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-901b > > > > > > > > > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk > > wrote: > > > > > > > > > No bomar brand > > > > > > Sent from AOL on Android > > > > > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S > > wrote: Bomar as in the Bomber Aircraft? > > > > > > Sent from my iPhone > > > > > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk < > cctalk(a)classiccmp.org> > > wrote: > > > > > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it > seems?s,? > > > > > > > > > > > > Sent from AOL on Android > > > > Grownups never understand anything by themselves and it is tiresome for > > children to be always and forever explaining things to them, > > > > Antoine de Saint-Exupery in The Little Prince > > > > > > > > > --===============3844023531682453405==-- From rice43@btinternet.com Tue Apr 16 13:53:15 2024 From: Joshua Rice To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Tue, 16 Apr 2024 13:53:12 +0000 Message-ID: <5925b3ca-8b6a-4dbb-bf30-e879084d877b@btinternet.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5194664035181497633==" --===============5194664035181497633== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 15/04/2024 15:00, Bill Degnan via cctalk wrote: > I'll bet the source was talking about large contemporary storage units that > looked like drums or may have been called "drums" but were not actual 50's > drum memory with tubes and such. There was no rotating drum storage, the > media rotates in the PDP era. > > Take a look at any pdp 11 peripheral handbook, there would be drum memory > there if it was an official product. > > Bill There is a mention of drum memory storage in the PDP-11 Memory=20 Management handbook:=20 http://www.bitsavers.org/www.computer.museum.uq.edu.au/pdf/DEC-11-HGKTCB-D%20= PDP-1145%20Memory%20Management%20Reference%20Manual.pdf=20 page 21 I imagine that any "drum like storage" attached to an 11/45 would be=20 fixed head disk storage rather than actual drum memory. After all, from=20 a digital perspective they're identical. Josh --===============5194664035181497633==-- From wdonzelli@gmail.com Tue Apr 16 14:08:27 2024 From: William Donzelli To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 10:08:07 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2645235483724752060==" --===============2645235483724752060== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ed has had his chance at kindness. He blew it LONG ago. -- Will On Tue, Apr 16, 2024 at 9:46=E2=80=AFAM Eric Moore via cctalk wrote: > > Sellam, that was unneccassarily cruel. Please try and exhibit some empathy > if not kindness. > > -Eric > > > > > On Tue, Apr 16, 2024, 8:39=E2=80=AFAM Sellam Abraham via cctalk < > cctalk(a)classiccmp.org> wrote: > > > Ed, > > > > From now on, when posting to this mailing list, can you please construct > > complete sentences that actually express ideas and concepts to which an > > ordinary human can respond? > > > > Sellam > > > > On Tue, Apr 16, 2024, 4:59=E2=80=AFAM ED SHARPE via cctalk > > wrote: > > > > > I bought mine 30 years ago at garage sake. For 50 cents > > > > > > Sent from AOL on Android > > > > > > On Tue, Apr 16, 2024 at 4:38 AM, Adrian Godwin > > > wrote: 901B is the first pocket calculator I remember - I don't know = if > > > there were earlier ones. I don't think they're exactly rare but later > > ones > > > such as MX10 are certainly easier to find. They're often in the same ca= se > > > as a 901B but with slightly enhanced functionality such as 10 digits. % > > key > > > etc. > > > > > > On Tue, Apr 16, 2024 at 12:31=E2=80=AFPM ED SHARPE via cctalk < > > > cctalk(a)classiccmp.org> wrote: > > > > > > Yes. Cell phone horrible typing > > > The Consumer Electronics Hall of Fame: Bowmar 901B > > > Ok can not find b pricevonly c and d > > > > > > Sent from AOL on Android > > > > > > On Tue, Apr 16, 2024 at 3:41 AM, Will Cooke via cctalk< > > > cctalk(a)classiccmp.org> wrote: I think he means Bowmar > > > > > https://spectrum.ieee.org/the-consumer-electronics-hall-of-fame-bowmar-90= 1b > > > > > > > > > > > > > On 04/16/2024 5:34 AM CDT ED SHARPE via cctalk > > > wrote: > > > > > > > > > > > > No bomar brand > > > > > > > > Sent from AOL on Android > > > > > > > > On Mon, Apr 15, 2024 at 7:15 PM, Wayne S > > > wrote: Bomar as in the Bomber Aircraft? > > > > > > > > Sent from my iPhone > > > > > > > > > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk < > > cctalk(a)classiccmp.org> > > > wrote: > > > > > > > > > > Bomar 901b My wife found in my stuff. Is this as scarce at it > > seems?s,? > > > > > > > > > > > > > > > Sent from AOL on Android > > > > > > Grownups never understand anything by themselves and it is tiresome for > > > children to be always and forever explaining things to them, > > > > > > Antoine de Saint-Exupery in The Little Prince > > > > > > > > > > > > > > --===============2645235483724752060==-- From wdonzelli@gmail.com Tue Apr 16 14:15:42 2024 From: William Donzelli To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Tue, 16 Apr 2024 10:15:25 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8920894847333295161==" --===============8920894847333295161== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > I'll bet the source was talking about large contemporary storage units that > looked like drums or may have been called "drums" but were not actual 50's > drum memory with tubes and such. There was no rotating drum storage, the > media rotates in the PDP era. > > Take a look at any pdp 11 peripheral handbook, there would be drum memory > there if it was an official product. Key words being "official product". Digital CSS department - Computer Special Systems, where all that weird stuff that was DEC engineered and built came from. Call it "low run semi custom". -- Will --===============8920894847333295161==-- From paulkoning@comcast.net Tue Apr 16 14:39:35 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Tue, 16 Apr 2024 10:39:28 -0400 Message-ID: <1B9552FE-BD65-4312-BB87-CA20525356A2@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0509823432108295794==" --===============0509823432108295794== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 16, 2024, at 10:15 AM, William Donzelli via cctalk wrote: >=20 >> I'll bet the source was talking about large contemporary storage units that >> looked like drums or may have been called "drums" but were not actual 50's >> drum memory with tubes and such. There was no rotating drum storage, the >> media rotates in the PDP era. >>=20 >> Take a look at any pdp 11 peripheral handbook, there would be drum memory >> there if it was an official product. >=20 > Key words being "official product". >=20 > Digital CSS department - Computer Special Systems, where all that > weird stuff that was DEC engineered and built came from. Call it "low > run semi custom". For that matter, there are a lot of DEC products not seen in any Handbook. I= f you want to see everything that was produced by DEC, check the Option/Modul= e list. =20 To pick an example, the typesetting products were certainly official DEC prod= ucts, not CSS, though admittedly low volume. But you won't find the PA611, o= r the VT61/t, or the VT71 or VT20, in any peripheral or other "handbook". paul --===============0509823432108295794==-- From cisin@xenosoft.com Tue Apr 16 14:43:00 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 07:42:54 -0700 Message-ID: In-Reply-To: <9ECB4812-FD8A-465A-83D0-15F35972FDD1@sonic.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5690249807154236832==" --===============5690249807154236832== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 15 Apr 2024, Don R via cctalk wrote: > At first I misread the subject as my 901lb wife…. > Man I need my eyes checked! ;o) > Don Resor > Sent from someone's iPhone Or read it on a larger screen. It clearly says "90lb", not "901lb" Bomar may be offended that you think that she gained 811 pounds. --===============5690249807154236832==-- From van.snyder@sbcglobal.net Tue Apr 16 16:34:35 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 09:34:25 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7897908564884325139==" --===============7897908564884325139== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2024-04-16 at 12:38 +0100, Adrian Godwin via cctalk wrote: > 901B is the first pocket calculator I remember - I don't know if there were > earlier ones. The first one I remember is the HP Digital Slide Rule, about 1965. Six digits. $600. --===============7897908564884325139==-- From bfranchuk@jetnet.ab.ca Tue Apr 16 17:14:08 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 11:13:57 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3172300237386205627==" --===============3172300237386205627== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-04-16 10:34 a.m., Van Snyder via cctalk wrote: > On Tue, 2024-04-16 at 12:38 +0100, Adrian Godwin via cctalk wrote: >> 901B is the first pocket calculator I remember - I don't know if there were >> earlier ones. > > The first one I remember is the HP Digital Slide Rule, about 1965. Six > digits. $600. Keep quiet, now all old calculators will be $600 on ebay. --===============3172300237386205627==-- From swperk@earthlink.net Tue Apr 16 18:36:14 2024 From: Stan To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 11:31:05 -0700 Message-ID: <002501da902c$3e74be50$bb5e3af0$@earthlink.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7435437283245711804==" --===============7435437283245711804== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I've never heard of the HP Digital Slide Rule. Do you have photos and/or more= details? I am familiar with the first HP desktop calculator (9100A) that inspired thei= r first handheld calculator (HP-35). The HP-35 was a ten-digit calculator tha= t was released in 1972 for $395. -----Original Message----- From: Van Snyder via cctalk =20 Sent: Tuesday, April 16, 2024 9:34 AM To: General Discussion: On-Topic and Off-Topic Posts ; ED SHARPE Cc: Adrian Godwin ; Van Snyder Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce= at it seems?s,? On Tue, 2024-04-16 at 12:38 +0100, Adrian Godwin via cctalk wrote: > 901B is the first pocket calculator I remember - I don't know if there=20 > were earlier ones. The first one I remember is the HP Digital Slide Rule, about 1965. Six digits= . $600. --===============7435437283245711804==-- From van.snyder@sbcglobal.net Tue Apr 16 20:11:24 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 13:11:14 -0700 Message-ID: <25c3102dab3b079d510cb2203dc1c8ec24198396.camel@sbcglobal.net> In-Reply-To: <002501da902c$3e74be50$bb5e3af0$@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7293263340435872886==" --===============7293263340435872886== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2024-04-16 at 11:31 -0700, Stan via cctalk wrote: > I've never heard of the HP Digital Slide Rule. Do you have photos > and/or more details? No photos. Sorry, I didn't have an iPhone when I was a college freshman in 1965. I never saw one, anyway. We got by with Monroe and Friden mechanical calculators, full of gears and cams. One of them could even do square roots. > I am familiar with the first HP desktop calculator (9100A) that > inspired their first handheld calculator (HP-35). The HP-35 was a > ten-digit calculator that was released in 1972 for $395. > -----Original Message-----From: Van Snyder via cctalk < > cctalk(a)classiccmp.org> Sent: Tuesday, April 16, 2024 9:34 AMTo: > General Discussion: On-Topic and Off-Topic Posts < > cctalk(a)classiccmp.org>; ED SHARPE Cc: Adrian > Godwin ; Van Snyder Su > bject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as > scarce at it seems?s,? > On Tue, 2024-04-16 at 12:38 +0100, Adrian Godwin via cctalk wrote: > > 901B is the first pocket calculator I remember - I don't know if > > there were earlier ones. > > The first one I remember is the HP Digital Slide Rule, about 1965. > Six digits. $600. --===============7293263340435872886==-- From cisin@xenosoft.com Tue Apr 16 21:21:22 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 14:21:16 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4937160936109094399==" --===============4937160936109094399== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> 901B is the first pocket calculator I remember - I don't know if there were >> earlier ones. On Tue, 16 Apr 2024, Van Snyder via cctalk wrote: > The first one I remember is the HP Digital Slide Rule, about 1965. Six > digits. $600. The HP-35 was marketed with a name of "Electronic Slide Rule" https://www.computerhistory.org/revolution/calculators/1/64/264 Similar title, 52 years ago, not 59 years ago. It came out in 1972. I saw one in late 1972. In 1972, however, you could get a Silent 700, and connect to a timesharing machine over telephone. Although the HP-35 was the first "pocket calculator" from HP, it was not the first handheld calculator. In 1970 or 1971, Wang had a tiny desktop calculator that had a card reader! The card reader was an external peripheral, that clam-shell closed on individual port-a-punch cards (perforated normal sized cards using every other column) In fact, by 1972, there was even a handheld calculator made in France; one of my bosses in 1972 had that. It was kept in my desk drawer, and they called me "Head of computing services" in bidding on at least one contract. A completely undeserved title, just because I did a little programming in FORTRAN and APL, and was the keeper of the calculator. --===============4937160936109094399==-- From doc@vaxen.net Tue Apr 16 22:46:00 2024 From: Doc Shipley To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 17:45:53 -0500 Message-ID: In-Reply-To: <783482086.5831298.1713233035164@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4373822020829887708==" --===============4373822020829887708== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/15/24 21:03, ED SHARPE via cctalk wrote: > Bomar 901b My wife=C2=A0 found=C2=A0 in my stuff. Is this as scarce=C2=A0 a= t it seems?s,? My dad had one of those in '72-ish. IIRC he paid just under $400 for it. It was a complete game-changer. His business sold cotton farming=20 implements, and Dad said that the ability to calculate the bottom line=20 without having to go to a desk almost doubled his new-customer sales. We talk a lot about the technical aspects and advantages of gear like=20 this, but I think it's difficult to remember just how much effect=20 mobilization had in everyday life. Also IIRC, year or so later a TI calculator with more functions, more=20 digits, and twice the battery life cost about $100 Doc --===============4373822020829887708==-- From rickb@bensene.com Tue Apr 16 23:06:32 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: Wang Laboratories calculators (Was Bowmar handheld calculator) Date: Tue, 16 Apr 2024 23:06:19 +0000 Message-ID: <91a873e1619a46979c0c315b4c730987@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0289133726810976923==" --===============0289133726810976923== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Fred Cisin wrote > In 1970 or 1971, Wang had a tiny desktop calculator that had a card=20 > reader! The card reader was an external peripheral, that clam-shell > close= d on individual port-a-punch cards (perforated normal sized > > cards using every other column) It was actually available before 1970. It was Wang Laboratories' 300-Series o= f electronic calculators. =20 The "tiny" part was the visible part, which was just the keyboard and Nixie t= ube display. It connected to an electronics package which was usually put u= nder a desk or sometimes even quite a distance from the keyboard/display unit= . =20 The punched card programming peripheral sat between the keyboard/display and = the calculator electronics package, and effectively "pressed keys" on the key= board designated by the punches on the card, at high speed. =20 On all but the 370 and 380 keyboard devices, the programs punched into the ca= rds were simple linear programs without test & branch capability, or looping.= Looping could be manually done by just restarting the program at the begin= ning, and continuing to do so until the answer converged on the final result.= =20 There were also the somewhat larger 360KT and 360KR keyboards that had built-= in diode ROM programs that calculated trig functions by sending the keycodes = to the electronics package to carry out the operations necessary to perform t= he trig functions. =20 There were a number of different electronics packages that were available, wi= th the low-end model (the 300E) having access to only the basic four math fun= ctions. The 310E added square root and x^2, the 320E added natural logarithm= and e^x functions to the 310. The 360E added four store/recall memory regi= sters along with the functions of the 320E. =20 The last of the 300-series was the 362E electronics package that provided acc= ess to ten memory registers, each of which could be split in half to store tw= o five-digit numbers, along with the math functions of the 360E. =20 Then there were the SE type electronics packages. To my knowledge, there wer= e the 310SE, 320SE, and 360SE. =20 The SE electronics packages took the core calculating logic of the 310E/320E/= 360E and stuffed some multiplexing logic around it, allowing up to four keybo= ard/display units to be connected up to it that operated in a round-robin tim= esharing mode. =20 The 370 Programmer Keyboard Unit included a similar punched card reader, but = there was extra logic inside the keyboard that allowed conditional testing an= d branching capability. Up to four of these card readers could be daisy-chai= ned to the 370 keyboard to allow programs up 320 steps. =20 The program codes consumed 6 bits, so each column of the 40 column card (a st= andard IBM punched card, but with pre-scored holes every other column) could = contain two instructions, allowing 80 instruction steps per card. =20 The 380 Programmer Keyboard Unit was similar to the 370 in terms of capabilit= y, but instead of using punched cards for "storing" the program, the program = steps were recorded on what was essentially an 8-Track tape cartridge that wa= s inserted into a slot on the back panel of the 380. The tape in the cartrid= ge was in a loop, and was positioned by a rather noisy ratcheting system akin= to a stepping relay that moved the tape forward. Branching was accomplished = by moving the tape forward until the target location was found. Depending on= where the branch was targeted, the tape could have to move to the end of the= program, then continue moving until the beginning of the program is found, t= hen searching for the loop target. This operation could consume quite a bit = of time. The tape cartridge allowed for considerably larger programs, but wa= s quite slow in terms of tape positioning for branching and looping. =20 The initial announcement of the 300-series calculator occurred in 1965, with = the 300E/310E/320E electronics units, and 300K, 310K, 320K keyboard units, al= ong with the CP-1 punched card reader, of which up to four could be connected= daisy-chain style between the keyboard unit and the electronics unit. =20 Later the 360E electronics package was added, and the 360K keyboard unit for = the 360E added keys to access the four memory registers. A bit later, the 360KT and 360KR trig keyboards were introduced, with the 360= KT accepting arguments and results in Degrees, and the 360KR in Radians. =20 The 310SE and 320SE four-user electronics packages came out sometime in 1967.= =20 The 360SE four-user electronics package came out in 1968, and also the 370 Pr= ogrammer and 371 card reader as well as the 380 Programmer. =20 Lastly, sometime in late '68 or early '69, the 362E electronics package came = out, and a 362K keyboard (which was identical to a 360K keyboard but with dif= ferent keycap legends for the memory keys) was introduced with the 362E. The = 362E marked the end of the 300-Series. There were a lot of peripheral devices that were available for the 370 and 38= 0 programmers, including a Teletype interface that connected a Model 33ASR Te= letype to the calculator, with ability to accept input from the Teletype and = print output to the Teletype, as well as being able to read program steps fro= m the Teletype's punched paper tape reader, add-on memory units for more regi= ster storage. There was also an Item Counter that connected between any of the keyboard uni= ts and the electronics package that would count depressions of various keys o= n an electromechanical counter to aid in calculations such as averages, etc. = There was also a simple column printer that would provide printed output of = the number in the calculator's display that was also connected between any ke= yboard unit and the electronics package. A specially modified IBM Selectric = typewriter that had Wang-made solenoids and linkages to actuate the keys and = functions of the typewriter was also available that could print output from c= alculations. There are also some peripherals that could be used to interface the calculators to external digital devices such a= s test and measurement equipment made by other manufacturers of such equipmen= t. Wang also would OEM the electronics package guts to other manufacturers. On= e company even made a general purpose computer system that used one of the 30= 0-series electronics packages as its arithmetic unit. Wang also offered a m= odular computer system called the 4000 (originally named the 390, but was cha= nged before introduction) that used a standardized bus structure to connect t= he logic of an electronics package as the arithmetic unit, along with other m= odules that would contain storage, programming capability, and I/O interfaces= . =20 For quite some time, Wang Labs were the only calculator manufacturer that pro= vided built-in calculation of logarithmic functions that were /not/ pre-coded= sequences of keypresses that were executed like a program, but were actually= hard-coded algorithms in the calculator's logic that provided almost instant= aneous results. Dr. Wang invented the logic to do this, and got a patent for= it. It was quite ingenious, and was able to calculate logarithms to twelve = digit accuracy using only addition/subtraction and shift operations, and do s= o in an average of about 300 milliseconds. =20 The weird part about the calculators in the 300-series is that they used loga= rithms to perform multiplication and division (which simplified the operation= s into addition of logarithms of the operands, then an anti-logarithm to get = the result of a multiplication, and subtraction of the logarithm of the secon= d operand from the logarithm of the first operand, followed by an anti-logari= thm to derive the result. The issue with this is that most logarithms are no= t able to be 100% accurately represented in the 14 digit (10 digits displayed= ) capacity of the logic, and as a result, some multiplication and division op= erations that would normally result in an integer answer providing an answer = that was not quite accurate. For example, 3 X 3 would equal 8.999999998, but= a bit of additional logic for multiply and divide would round the result up = to 9.000000000 . =20 In some cases, the error was enough that the rounding wouldn't give the integ= er answer expected, though. All of the answers provided, even with slight er= rors due to imperfect representation of the logarithms were within most toler= ances for engineering and scientific calculations. =20 The logic of the machines was completely transistorized, using diode-transist= or gates. No integrated circuits anywhere. The working memory of the calculators was stored in a magnetic core array in = the electronics package. =20 The electronics packages consisted of a backplane (hand-wired in earlier mach= ines, later on a circuit board) with a bunch of small (roughly 3x5-inch) circ= uit boards packed with components.=20 The power supply was a conventional linear power supply with Zener/transistor= regulation. The basic keyboard units just contained a board with transistor drivers for t= he Nixie tube displays, and diode encoding for the keys on the keyboard. The= key switches were standard micro-switch units with a ring pressed onto the k= ey-stalk that would press down on the actuator for the micro-switch. Key tra= vel was very short, but had a positive "click" as the micro-switch closed whe= n the key was depressed. The 300-Series electronic calculators put Wang Laboratories on the map as a l= eader in higher-end electronic calculators, and made a fortune for the compan= y and its shareholders. =20 In 1968, when HP introduced the 9100A, Dr. An Wang, the founder and CEO of Wa= ng Labs was secretly shown a production version of the 9100A before it was in= troduced. The presentation of the machine was provided to Dr. Wang by Dave = Hewlett, one of the founders of HP. When Dr. Wang saw what the HP 9100A cou= ld do, he was visibly shaken. When the presentation was over, he left the roo= m saying "We've got to get to work", meaning that it was clear that the 300-S= eries was now completely obsoleted by the 9100A, and that Wang Labs had bette= r get busy with a new generation of calculators to counter HP's amazing calcu= lator that was much smaller, much more capable, had computer-like programming= capability, and was still made only with transistors and magnetic core memor= y. Wang did not have their counter to the HP 9100A/B calculators ready until= mid-1970, the Wang 700-Series. The 700-Series calculators were serious mach= ines, very computer-like, with large amounts of core memory, very high speed = using DTL and TTL small-scale integrated circuit logic, and large I/O expansi= on capabilities. They were a solid match for the HP 9100A/B, but by the tim= e they got them to market, HP had already introduced it's 9800-series machine= s, which had the essence of a computer as their main logic, with a "program" = that made the machines run. The computer at the heart of the 9800 series was= a somewhat slimmed down, bit-serial version of HP's first minicomputer, the = HP 2116A. The 9800-series were larger machines than the 9100A/B, but offered = extensive expandability and I/O capabilities. The pinnacle of the 9800 serie= s was the 9830A, which was programmable by the user in the BASIC computer lan= guage, and was more a computer than a calculator, but HP still considered it = a calculator to make it more marketable because the term "computer" had conno= tations of being a very expensive piece of capital equipment, while a calcula= tor was basically an expense item. You can learn more about the Wang 300-Series calculators by going to=20 https://oldcalculatormuseum.com/calcman.html#MFG-WANG . There is also inform= ation on HP's 9100B, as well as most of the 9800-series that can be found by = scrolling up on that same page, as well as many other electronic calculators = exhibited in the Old Calculator Museum website, as well as physically in the = Old Calculator Museum. Rick Bensene The Old Calculator Museum https://oldcalculatormuseum.com Beavercreek, Oregon USA=20 P.S. Some of the dates above may not be exactly correct, and there may be so= me other minor errors or missing information because I typed this strictly st= raight out of my head without access to any reference material. The website= has the correct information to the greatest extent possible given the amount= of time that has elapsed since these machines were new. --===============0289133726810976923==-- From artgodwin@gmail.com Wed Apr 17 00:00:02 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Wed, 17 Apr 2024 00:59:46 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3973983788565180246==" --===============3973983788565180246== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, Apr 16, 2024 at 10:21 PM Fred Cisin via cctalk < cctalk(a)classiccmp.org> wrote: > > Although the HP-35 was the first "pocket calculator" from HP, it was not > the first handheld calculator. > > I think it was the first *scientific* pocket calculator though. --===============3973983788565180246==-- From cisin@xenosoft.com Wed Apr 17 00:12:51 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 17:12:45 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7828870988025204911==" --===============7828870988025204911== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> Although the HP-35 was the first "pocket calculator" from HP, it was not >> the first handheld calculator. On Wed, 17 Apr 2024, Adrian Godwin wrote: > I think it was the first *scientific* pocket calculator though. I believe that that is correct. and Casio CFX-40/CFX-400 (1984?) was the first scientific calculator watch. Epson RC-20 (1985) was the first wrist computer (Z80 compatible, with a little RAM (2K?), touch screen, and a serial port) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============7828870988025204911==-- From sqrfolkdnc@comcast.net Wed Apr 17 02:32:43 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Wang programmable calculator [was: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?] Date: Tue, 16 Apr 2024 21:32:37 -0500 Message-ID: <194180889.1636995.1713321157181@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0894850438852365013==" --===============0894850438852365013== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The wang calculator was hardly tiny, at least not the one I used in 1970-71. = IIRC the size of a large lunchbox or maybe an attache case. AND...it could connect to four display units, an early timesharing system. I= think you could have several programs on the card and choose which program = to execute from any of the 4 display units. We had one in the Freshmman phy= sics lab at Northwestern university. I was a graduate student and in charge = of a lab section. I picked up one of the card readers in a junk box at a retro computer fair, m= inus the electronics. I figured I could connect it to some parallel ports to read tab cards in two passes (read half = the columns, reverse the card and read the others). Does anybody want a pictu= re of it? 
--Carey
> On 04/16/2024 4:21 PM CDT Fred Cisin via cctalk w= rote: >=20 > ... >=20 > In 1970 or 1971, Wang had a tiny desktop calculator that had a card=20 > reader! The card reader was an external peripheral, that clam-shell closed = > on individual port-a-punch cards (perforated normal sized cards using=20 > every other column) > --===============0894850438852365013==-- From cisin@xenosoft.com Wed Apr 17 02:52:18 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Wang programmable calculator [was: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?] Date: Tue, 16 Apr 2024 19:52:11 -0700 Message-ID: In-Reply-To: <194180889.1636995.1713321157181@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2631148743297653935==" --===============2631148743297653935== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 16 Apr 2024, CAREY SCHUG via cctalk wrote: > The wang calculator was hardly tiny, at least not the one I used in 1970-71= . IIRC the size of a large lunchbox or maybe an attache case. > AND...it could connect to four display units, an early timesharing system. = I think you could have several programs on the card and choose which progra= m to execute from any of the 4 display units. We had one in the Freshmman p= hysics lab at Northwestern university. I was a graduate student and in charg= e of a lab section. > I picked up one of the card readers in a junk box at a retro computer fair,= minus the electronics. I figured I could > connect it to some parallel ports to read tab cards in two passes (read hal= f the columns, reverse the card and read the others). Does anybody want a pic= ture of it? On the one that I got achance to play with, the part on top of the=20 table was tiny, and the rest was underneath the table, as Rick mentioned.=20 There were probably other models. It has been said that when Radio Shack's engineers showed the working=20 prototype of the TRS80 to the execs, that the CEO looked under the table=20 to try to "see where the rest of it is". I also got one of the card readers from some junk! (at the Foothill swap) My plan was exactly the same as yours. But, life got in the way, and it never came to be. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============2631148743297653935==-- From sqrfolkdnc@comcast.net Wed Apr 17 03:39:55 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Wang Laboratories calculators (Was Bowmar handheld calculator) Date: Tue, 16 Apr 2024 22:39:28 -0500 Message-ID: <1425202688.1638266.1713325168633@connect.xfinity.com> In-Reply-To: <91a873e1619a46979c0c315b4c730987@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4254871694272868434==" --===============4254871694272868434== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable https://www.oldcalculatormuseum.com/wang360.html I had remembered it as one programmer shared by all 4 displays, I guess wrong= . We must have had 4 programmer units. 
--Carey
> On 04/16/2024 6:06 PM CDT Rick Bensene via cctalk = wrote: >=20 > =20 > Fred Cisin wrote >=20 > > In 1970 or 1971, Wang had a tiny desktop calculator that had a card=20 > > reader! The card reader was an external peripheral, that clam-shell > clo= sed on individual port-a-punch cards (perforated normal sized > > > cards using every other column) >=20 > It was actually available before 1970. It was Wang Laboratories' 300-Series= of electronic calculators. =20 >=20 > The "tiny" part was the visible part, which was just the keyboard and Nixie= tube display. It connected to an electronics package which was usually put= under a desk or sometimes even quite a distance from the keyboard/display un= it. =20 >=20 > The punched card programming peripheral sat between the keyboard/display an= d the calculator electronics package, and effectively "pressed keys" on the k= eyboard designated by the punches on the card, at high speed. =20 >=20 > On all but the 370 and 380 keyboard devices, the programs punched into the = cards were simple linear programs without test & branch capability, or loopin= g. Looping could be manually done by just restarting the program at the beg= inning, and continuing to do so until the answer converged on the final resul= t.=20 >=20 > There were also the somewhat larger 360KT and 360KR keyboards that had buil= t-in diode ROM programs that calculated trig functions by sending the keycode= s to the electronics package to carry out the operations necessary to perform= the trig functions. =20 >=20 > There were a number of different electronics packages that were available, = with the low-end model (the 300E) having access to only the basic four math f= unctions. The 310E added square root and x^2, the 320E added natural logarit= hm and e^x functions to the 310. The 360E added four store/recall memory re= gisters along with the functions of the 320E. =20 >=20 > The last of the 300-series was the 362E electronics package that provided a= ccess to ten memory registers, each of which could be split in half to store = two five-digit numbers, along with the math functions of the 360E. =20 >=20 > Then there were the SE type electronics packages. To my knowledge, there w= ere the 310SE, 320SE, and 360SE. =20 >=20 > The SE electronics packages took the core calculating logic of the 310E/320= E/360E and stuffed some multiplexing logic around it, allowing up to four key= board/display units to be connected up to it that operated in a round-robin t= imesharing mode. =20 >=20 > The 370 Programmer Keyboard Unit included a similar punched card reader, bu= t there was extra logic inside the keyboard that allowed conditional testing = and branching capability. Up to four of these card readers could be daisy-ch= ained to the 370 keyboard to allow programs up 320 steps. =20 >=20 > The program codes consumed 6 bits, so each column of the 40 column card (a = standard IBM punched card, but with pre-scored holes every other column) coul= d contain two instructions, allowing 80 instruction steps per card. =20 >=20 > The 380 Programmer Keyboard Unit was similar to the 370 in terms of capabil= ity, but instead of using punched cards for "storing" the program, the progra= m steps were recorded on what was essentially an 8-Track tape cartridge that = was inserted into a slot on the back panel of the 380. The tape in the cartr= idge was in a loop, and was positioned by a rather noisy ratcheting system ak= in to a stepping relay that moved the tape forward. Branching was accomplishe= d by moving the tape forward until the target location was found. Depending = on where the branch was targeted, the tape could have to move to the end of t= he program, then continue moving until the beginning of the program is found,= then searching for the loop target. This operation could consume quite a bi= t of time. The tape cartridge allowed for considerably larger programs, but = was quite slow in terms of tape positioning for branching and looping. =20 >=20 > The initial announcement of the 300-series calculator occurred in 1965, wit= h the 300E/310E/320E electronics units, and 300K, 310K, 320K keyboard units, = along with the CP-1 punched card reader, of which up to four could be connect= ed daisy-chain style between the keyboard unit and the electronics unit. =20 >=20 > Later the 360E electronics package was added, and the 360K keyboard unit fo= r the 360E added keys to access the four memory registers. >=20 > A bit later, the 360KT and 360KR trig keyboards were introduced, with the 3= 60KT accepting arguments and results in Degrees, and the 360KR in Radians. = =20 >=20 > The 310SE and 320SE four-user electronics packages came out sometime in 196= 7. =20 >=20 > The 360SE four-user electronics package came out in 1968, and also the 370 = Programmer and 371 card reader as well as the 380 Programmer. =20 >=20 > Lastly, sometime in late '68 or early '69, the 362E electronics package cam= e out, and a 362K keyboard (which was identical to a 360K keyboard but with d= ifferent keycap legends for the memory keys) was introduced with the 362E. Th= e 362E marked the end of the 300-Series. >=20 > There were a lot of peripheral devices that were available for the 370 and = 380 programmers, including a Teletype interface that connected a Model 33ASR = Teletype to the calculator, with ability to accept input from the Teletype an= d print output to the Teletype, as well as being able to read program steps f= rom the Teletype's punched paper tape reader, add-on memory units for more re= gister storage. > There was also an Item Counter that connected between any of the keyboard u= nits and the electronics package that would count depressions of various keys= on an electromechanical counter to aid in calculations such as averages, etc= . There was also a simple column printer that would provide printed output o= f the number in the calculator's display that was also connected between any = keyboard unit and the electronics package. A specially modified IBM Selectri= c typewriter that had Wang-made solenoids and linkages to actuate the keys an= d functions of the typewriter was also available that could print output from= calculations. There are also some peripherals that > could be used to interface the calculators to external digital devices such= as test and measurement equipment made by other manufacturers of such equipm= ent. >=20 > Wang also would OEM the electronics package guts to other manufacturers. = One company even made a general purpose computer system that used one of the = 300-series electronics packages as its arithmetic unit. Wang also offered a= modular computer system called the 4000 (originally named the 390, but was c= hanged before introduction) that used a standardized bus structure to connect= the logic of an electronics package as the arithmetic unit, along with other= modules that would contain storage, programming capability, and I/O interfac= es. =20 >=20 > For quite some time, Wang Labs were the only calculator manufacturer that p= rovided built-in calculation of logarithmic functions that were /not/ pre-cod= ed sequences of keypresses that were executed like a program, but were actual= ly hard-coded algorithms in the calculator's logic that provided almost insta= ntaneous results. Dr. Wang invented the logic to do this, and got a patent f= or it. It was quite ingenious, and was able to calculate logarithms to twelv= e digit accuracy using only addition/subtraction and shift operations, and do= so in an average of about 300 milliseconds. =20 >=20 > The weird part about the calculators in the 300-series is that they used lo= garithms to perform multiplication and division (which simplified the operati= ons into addition of logarithms of the operands, then an anti-logarithm to ge= t the result of a multiplication, and subtraction of the logarithm of the sec= ond operand from the logarithm of the first operand, followed by an anti-loga= rithm to derive the result. The issue with this is that most logarithms are = not able to be 100% accurately represented in the 14 digit (10 digits display= ed) capacity of the logic, and as a result, some multiplication and division = operations that would normally result in an integer answer providing an answe= r that was not quite accurate. For example, 3 X 3 would equal 8.999999998, b= ut a bit of additional logic for multiply and divide would round the result u= p to 9.000000000 . =20 >=20 > In some cases, the error was enough that the rounding wouldn't give the int= eger answer expected, though. All of the answers provided, even with slight = errors due to imperfect representation of the logarithms were within most tol= erances for engineering and scientific calculations. =20 >=20 > The logic of the machines was completely transistorized, using diode-transi= stor gates. No integrated circuits anywhere. > The working memory of the calculators was stored in a magnetic core array i= n the electronics package. =20 >=20 > The electronics packages consisted of a backplane (hand-wired in earlier ma= chines, later on a circuit board) with a bunch of small (roughly 3x5-inch) ci= rcuit boards packed with components.=20 >=20 > The power supply was a conventional linear power supply with Zener/transist= or regulation. >=20 > The basic keyboard units just contained a board with transistor drivers for= the Nixie tube displays, and diode encoding for the keys on the keyboard. T= he key switches were standard micro-switch units with a ring pressed onto the= key-stalk that would press down on the actuator for the micro-switch. Key t= ravel was very short, but had a positive "click" as the micro-switch closed w= hen the key was depressed. >=20 > The 300-Series electronic calculators put Wang Laboratories on the map as a= leader in higher-end electronic calculators, and made a fortune for the comp= any and its shareholders. =20 >=20 > In 1968, when HP introduced the 9100A, Dr. An Wang, the founder and CEO of = Wang Labs was secretly shown a production version of the 9100A before it was = introduced. The presentation of the machine was provided to Dr. Wang by Dav= e Hewlett, one of the founders of HP. When Dr. Wang saw what the HP 9100A c= ould do, he was visibly shaken. When the presentation was over, he left the r= oom saying "We've got to get to work", meaning that it was clear that the 300= -Series was now completely obsoleted by the 9100A, and that Wang Labs had bet= ter get busy with a new generation of calculators to counter HP's amazing cal= culator that was much smaller, much more capable, had computer-like programmi= ng capability, and was still made only with transistors and magnetic core mem= ory. Wang did not have their counter to the HP 9100A/B calculators ready unt= il mid-1970, the Wang 700-Series. The 700-Series calculators were serious ma= chines, very computer-like, with large amounts of core memory, very high s peed using DTL and TTL small-scale integrated circuit logic, and large I/O e= xpansion capabilities. They were a solid match for the HP 9100A/B, but by t= he time they got them to market, HP had already introduced it's 9800-series m= achines, which had the essence of a computer as their main logic, with a "pro= gram" that made the machines run. The computer at the heart of the 9800 seri= es was a somewhat slimmed down, bit-serial version of HP's first minicomputer= , the HP 2116A. The 9800-series were larger machines than the 9100A/B, but of= fered extensive expandability and I/O capabilities. The pinnacle of the 9800= series was the 9830A, which was programmable by the user in the BASIC comput= er language, and was more a computer than a calculator, but HP still consider= ed it a calculator to make it more marketable because the term "computer" had= connotations of being a very expensive piece of capital equipment, while a c= alculator was basically an expense item. >=20 > You can learn more about the Wang 300-Series calculators by going to=20 > https://oldcalculatormuseum.com/calcman.html#MFG-WANG . There is also info= rmation on HP's 9100B, as well as most of the 9800-series that can be found b= y scrolling up on that same page, as well as many other electronic calculator= s exhibited in the Old Calculator Museum website, as well as physically in th= e Old Calculator Museum. >=20 > Rick Bensene > The Old Calculator Museum > https://oldcalculatormuseum.com > Beavercreek, Oregon USA=20 >=20 > P.S. Some of the dates above may not be exactly correct, and there may be = some other minor errors or missing information because I typed this strictly = straight out of my head without access to any reference material. The websi= te has the correct information to the greatest extent possible given the amou= nt of time that has elapsed since these machines were new. --===============4254871694272868434==-- From wayne.sudol@hotmail.com Wed Apr 17 09:28:45 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Bomar 901b My wife found in my stuff. Is this as scarce at it seems?s,? Date: Tue, 16 Apr 2024 02:15:03 +0000 Message-ID: In-Reply-To: <783482086.5831298.1713233035164@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5881160911235128711==" --===============5881160911235128711== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bomar as in the Bomber Aircraft? Sent from my iPhone > On Apr 15, 2024, at 19:04, ED SHARPE via cctalk w= rote: >=20 > =EF=BB=BFBomar 901b My wife found in my stuff. Is this as scarce at it s= eems?s,? >=20 >=20 > Sent from AOL on Android --===============5881160911235128711==-- From cz@bunsen.crystel.com Wed Apr 17 09:28:58 2024 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Mon, 15 Apr 2024 14:05:27 +0000 Message-ID: <1504de28-62b6-44b7-90a5-f8f4e5aba772@bunsen.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0383439061415775492==" --===============0383439061415775492== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >If you want word-addressable, the RF11 will do that. Not the RC11, it has 3= 2 word sectors. Oh yeah, the pdp11 world had a DF32 like thing with the RF11. Totally=20 forgot about that one. C --===============0383439061415775492==-- From cz@bunsen.crystel.com Wed Apr 17 09:29:14 2024 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Tue, 16 Apr 2024 11:26:30 -0500 Message-ID: <933366A0-D9E7-4158-9621-E9C9D44F7391@bunsen.crystel.com> In-Reply-To: <1B9552FE-BD65-4312-BB87-CA20525356A2@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6702301093454303794==" --===============6702301093454303794== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Always fun to see some of the flameouts that came from css. Sha tin always po= ps to mind.=20 Sent from my iPhone > On Apr 16, 2024, at 9:39 AM, Paul Koning via cctalk wrote: >=20 > =EF=BB=BF >=20 >>> On Apr 16, 2024, at 10:15 AM, William Donzelli via cctalk wrote: >>>=20 >>> I'll bet the source was talking about large contemporary storage units th= at >>> looked like drums or may have been called "drums" but were not actual 50's >>> drum memory with tubes and such. There was no rotating drum storage, the >>> media rotates in the PDP era. >>>=20 >>> Take a look at any pdp 11 peripheral handbook, there would be drum memory >>> there if it was an official product. >>=20 >> Key words being "official product". >>=20 >> Digital CSS department - Computer Special Systems, where all that >> weird stuff that was DEC engineered and built came from. Call it "low >> run semi custom". >=20 > For that matter, there are a lot of DEC products not seen in any Handbook. = If you want to see everything that was produced by DEC, check the Option/Mod= ule list. =20 >=20 > To pick an example, the typesetting products were certainly official DEC pr= oducts, not CSS, though admittedly low volume. But you won't find the PA611,= or the VT61/t, or the VT71 or VT20, in any peripheral or other "handbook". >=20 > paul >=20 --===============6702301093454303794==-- From rodsmallwood52@btinternet.com Wed Apr 17 13:32:11 2024 From: Rod Smallwood To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Wed, 17 Apr 2024 13:32:07 +0000 Message-ID: <547a3f4e-c2cb-4c74-8035-596b29067c40@btinternet.com> In-Reply-To: <20240415080606.4303e7d4@chopoc.localdomain> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2965788555691993006==" --===============2965788555691993006== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Core memory yes - Drum memory I dont think so. Rod Smallwood  (Digital Equipment Corporation 1975 - 1985) On 15/04/2024 08:06, Paul Flo Williams via cctalk wrote: > On Sat, 13 Apr 2024 17:26:31 -0400 > Christopher Zach via cctalk wrote: > >> Was reading the Wikipedia article on Drum memories: >> >> https://en.wikipedia.org/wiki/Drum_memory#External_links >> >> And came across this tidbit. >> >> As late as 1980, PDP-11/45 machines using magnetic core main memory >> and drums for swapping were still in use at many of the original UNIX >> sites. > This uncited claim was introduced 15 years ago, along with the commit > comment "Hey, I saw drums (and core memory!) on PDP 11/45 hardware > running UNIX v6 (pre-BSD) in 1980 ... " > > So, someone anonymous saw some once, somewhere, and promoted this to > "many sites." > --===============2965788555691993006==-- From paulkoning@comcast.net Wed Apr 17 13:40:29 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Drum memory on pdp11's? Wikipedia thinks so.... Date: Wed, 17 Apr 2024 09:40:19 -0400 Message-ID: <6F4169C4-BCA5-4CB9-B5D6-B806F3445582@comcast.net> In-Reply-To: <1504de28-62b6-44b7-90a5-f8f4e5aba772@bunsen.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6303307297184303285==" --===============6303307297184303285== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 15, 2024, at 10:05 AM, Christopher Zach via cctalk wrote: >=20 >> If you want word-addressable, the RF11 will do that. Not the RC11, it has= 32 word sectors. >=20 > Oh yeah, the pdp11 world had a DF32 like thing with the RF11. Totally forgo= t about that one. >=20 > C The RC11 is the controller; the drive was called RS64. It may be basically a= double-capacity derivative of the DF32. RC11 is quite an obscure device, because it was only around very briefly at t= he start of the PDP11 era. We had one on the physics lab computer at my coll= ege; I think they got it in 1972, running DOS. I wanted to run RT BASIC on i= t so I worked on getting RT11 V2 to run on it, which required writing a devic= e driver and boot driver. Fortunately, Anton Chernoff was working at the col= lege that year. I asked him why he didn't write an RC11 driver when he was c= reating RT11 V2 at DEC -- his answer "because we couldn't find one". The 32 word blocksize was a bit of a nuisance because of the RT11 requirement= that partial-block writes have to be zero-filled to the next 512 byte bounda= ry. On disks like the RK05, the controller handles that, but on the RC11 the= driver had to do any filling from the sector boundary to the 512 byte block = boundary. The other thing about the RC11 is that it was so small that few people wanted= to deal with it. RSTS only ever supported it as a non-file-structured swap = disk, not as a file system. It was handled as a weird appendage to the syste= m disk (boot disk) file structure. paul --===============6303307297184303285==-- From athornton@gmail.com Thu Apr 18 20:56:48 2024 From: Adam Thornton To: cctalk@classiccmp.org Subject: [cctalk] Apple II Date: Thu, 18 Apr 2024 13:56:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6243747149123567715==" --===============6243747149123567715== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Mostly to Bill, but also anyone else hanging out here who's got a surfeit of 8-bit Apple stuff: If you're planning on selling the Apple II, and it's not a ][+, I'd be interested in buying. Not, perhaps, at optimistic eBay prices, but I have a lot of ][+s and //es, most of them in working shape, some of which are parts machines; however, I don't have either a II or a //c . Also happy to trade if I've got things you want. I don't have anything super-exotic, but feel free to HMU and ask. Adam --===============6243747149123567715==-- From paul.kimpel@digm.com Thu Apr 18 21:01:26 2024 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Thu, 18 Apr 2024 21:01:23 +0000 Message-ID: <171347408316.4006402.14738626306768244130@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7272191596254982937==" --===============7272191596254982937== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The tape for the Burroughs 220 drives was not metallic. It was 3/4-inch wide,= and I think a Mylar sandwich. It could be spliced much the same way you woul= d have spliced quarter-inch reel-to-reel audio tape back in the day. If the tape controller detected a parity error, it would backspace the block = and retry twice. If the error persisted on the second retry, the tape would s= top with the head ready to read the bad block (hanging the processor in the m= iddle of its I/O instruction), and the operator would have to take manual act= ion. If the drive punched a hole in the tape, then the drive needed service -= - probably a bad capstan pinch-roller solenoid. --===============7272191596254982937==-- From paul.kimpel@digm.com Thu Apr 18 21:29:18 2024 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Thu, 18 Apr 2024 21:29:14 +0000 Message-ID: <171347575472.4006402.17971577251552765687@classiccmp.org> In-Reply-To: <3dfca589-df7a-4858-9566-1640b2605ae7@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3976581308904120459==" --===============3976581308904120459== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The main storage area of the ElectroData/Burroughs Datatron 205 was 20 tracks= of 200 words each for a total of 4000 words. The drum rotated at 3570 RPM, s= o the average access time was about 8.4ms. The four quick-access tracks (or "loops" as they were called) were 20 words e= ach and worked as a delay line, much like the Bendix G-15's drum. These track= s had separate read and write heads. When writing was not taking place, the d= igits from the read head were simply copied to the write head 36 degrees beh= ind on the surface of the drum. So as the last digit of the track was written= , the first digit of the track was coming under the read head, yielding an av= erage access time of 0.84ms. When writing, digits from the processor were shunted to the write head in lie= u of those coming from the read head. When power was removed from the system,= the 4000-word main memory was preserved, but the data in the high-speed band= s was lost. The 205 had instructions to transfer 20-word blocks between the main memory a= nd the high-speed tracks. There were even a couple of instructions to move a = block to one of the high-speed tracks and branch to a word in that high-speed= track. The high-speed tracks were addressed modulo 20 (i.e., word 4005 was t= he same as 4025, 4045, 4065, ... 4985). You had to get good at dealing with a= ddresses that were congruent modulo 20. The high-speed tracks were so much faster than main storage that most program= mers went to a lot of effort to "block" 20-word segments of the program to th= e high-speed tracks and execute at least the most active code from the faster= storage. --===============3976581308904120459==-- From billdegnan@gmail.com Thu Apr 18 21:36:00 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple II Date: Thu, 18 Apr 2024 17:35:43 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9028758243484851068==" --===============9028758243484851068== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Not sure if you mean me, "Bill", but I sold or gave away all of the Apple's that I had for sale, about 15 or so all gone. I did not have any original II's for sale. Only surplus II+, IIe, IIc, original MACs (mac plus, SE, classic, SE FD and that style. This was all a fundraiser for kennett Classic non profit. What's left is here Kennettclassic.com/surplus/ Bill On Thu, Apr 18, 2024, 4:56 PM Adam Thornton via cctalk < cctalk(a)classiccmp.org> wrote: > Mostly to Bill, but also anyone else hanging out here who's got a surfeit > of 8-bit Apple stuff: > > If you're planning on selling the Apple II, and it's not a ][+, I'd be > interested in buying. Not, perhaps, at optimistic eBay prices, but I have > a lot of ][+s and //es, most of them in working shape, some of which are > parts machines; however, I don't have either a II or a //c . > > Also happy to trade if I've got things you want. I don't have anything > super-exotic, but feel free to HMU and ask. > > Adam > --===============9028758243484851068==-- From wayne.sudol@hotmail.com Thu Apr 18 21:44:51 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple II Date: Thu, 18 Apr 2024 21:44:42 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3592382533235948286==" --===============3592382533235948286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill, so the disk drives are gone? Sent from my iPhone > On Apr 18, 2024, at 14:36, Bill Degnan via cctalk = wrote: >=20 > =EF=BB=BFNot sure if you mean me, "Bill", but I sold or gave away all of th= e Apple's > that I had for sale, about 15 or so all gone. >=20 > I did not have any original II's for sale. Only surplus II+, IIe, IIc, > original MACs (mac plus, SE, classic, SE FD and that style. >=20 > This was all a fundraiser for kennett Classic non profit. >=20 > What's left is here > Kennettclassic.com/surplus/ >=20 > Bill >=20 >> On Thu, Apr 18, 2024, 4:56 PM Adam Thornton via cctalk < >> cctalk(a)classiccmp.org> wrote: >>=20 >> Mostly to Bill, but also anyone else hanging out here who's got a surfeit >> of 8-bit Apple stuff: >>=20 >> If you're planning on selling the Apple II, and it's not a ][+, I'd be >> interested in buying. Not, perhaps, at optimistic eBay prices, but I have >> a lot of ][+s and //es, most of them in working shape, some of which are >> parts machines; however, I don't have either a II or a //c . >>=20 >> Also happy to trade if I've got things you want. I don't have anything >> super-exotic, but feel free to HMU and ask. >>=20 >> Adam >>=20 --===============3592382533235948286==-- From cclist@sydex.com Thu Apr 18 22:57:32 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Odd IBM mass storage systems Date: Thu, 18 Apr 2024 15:57:16 -0700 Message-ID: <9e5d31fc-0b6d-4835-9409-2725ea3990d8@sydex.com> In-Reply-To: <171347408316.4006402.14738626306768244130@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7635218520009891066==" --===============7635218520009891066== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/18/24 14:01, paul.kimpel--- via cctalk wrote: > The tape for the Burroughs 220 drives was not metallic. It was 3/4-inch wid= e, and I think a Mylar sandwich. It could be spliced much the same way you wo= uld have spliced quarter-inch reel-to-reel audio tape back in the day. >=20 The Datamatic 1000 tapes were definitely a Mylar sandwich affair. 3" wide and 2700' long. https://www.smecc.org/honeywell_datamatic_1000.htm A few reels of the stuff are still around. --Chuck --===============7635218520009891066==-- From pschow@gmail.com Fri Apr 19 18:55:24 2024 From: Peter Schow To: cctalk@classiccmp.org Subject: [cctalk] Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 12:55:07 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6667711984506174062==" --===============6667711984506174062== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit In case you missed it, Zilog has issued a Last Buy notification for the Z80: https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf Looks like Mouser and Digikey still have decent inventory of them. --===============6667711984506174062==-- From cclist@sydex.com Fri Apr 19 21:17:38 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 14:17:08 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7077202926296023273==" --===============7077202926296023273== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/19/24 11:55, Peter Schow via cctalk wrote: > In case you missed it, Zilog has issued a Last Buy notification for the Z80: > > https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf > > Looks like Mouser and Digikey still have decent inventory of them. There should still be a reliable supply from licensed second sources, no? Is anyone designing new mass-production products with the original Z80? --Chuck --===============7077202926296023273==-- From cclist@sydex.com Fri Apr 19 21:19:51 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 14:19:41 -0700 Message-ID: <0ea4adc8-882d-4687-8af9-013710942247@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5043862685804880422==" --===============5043862685804880422== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/19/24 11:55, Peter Schow via cctalk wrote: > > https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf > I should add parenthetically that in my wildest fevered dreams did I ever think that Zilog would be a division of Littlefuse--even after the Exxon debacle. --Chuck --===============5043862685804880422==-- From billdegnan@gmail.com Sat Apr 20 01:57:17 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 21:57:00 -0400 Message-ID: In-Reply-To: <0ea4adc8-882d-4687-8af9-013710942247@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6404705019485772370==" --===============6404705019485772370== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit As it is now, running z80 production must no longer be profitable for Zilog, but some other manufacturer can license z80 production. Right? If there is a demand someone will produce them It was a good run though. Bill On Fri, Apr 19, 2024, 5:19 PM Chuck Guzis via cctalk wrote: > On 4/19/24 11:55, Peter Schow via cctalk wrote: > > > > https://www.mouser.com/PCN/Littelfuse_PCN_Z84C00.pdf > > > > I should add parenthetically that in my wildest fevered dreams did I > ever think that Zilog would be a division of Littlefuse--even after the > Exxon debacle. > > --Chuck > > --===============6404705019485772370==-- From cisin@xenosoft.com Sat Apr 20 02:07:40 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 19:07:34 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7285539213115738153==" --===============7285539213115738153== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Gee! Have sales gone down? One more reason to use the 8080 subset when writing CP/M programs. Aren't there already some licensed second sources? --===============7285539213115738153==-- From bfranchuk@jetnet.ab.ca Sat Apr 20 02:39:46 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 20:39:36 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2316476941047103962==" --===============2316476941047103962== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-19 8:07 p.m., Fred Cisin via cctalk wrote: > Gee!  Have sales gone down? > > One more reason to use the 8080 subset when writing CP/M programs. > There still are RADIO SHACK 8080A's still on ebay, with @RARE@ prices. NO thank you, z80's are the way to go. > Aren't there already some licensed second sources? > > Now is a good time to stock up for any z80 projects or repair, while they are $10 or less on epay. --===============2316476941047103962==-- From cclist@sydex.com Sat Apr 20 04:34:54 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Fri, 19 Apr 2024 21:34:42 -0700 Message-ID: <50e9219a-bd85-41d1-98b8-5e97e8838fd8@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1607326104885729934==" --===============1607326104885729934== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/19/24 19:39, ben via cctalk wrote: > There still are RADIO SHACK 8080A's still on ebay, with @RARE@ prices. > NO thank you, z80's are the way to go. I found 8085 generally easier to work with, but that's just me. > Now is a good time to stock up for any z80 projects > or repair, while they are $10 or less on epay. I seem to remember that in the mid 80s, OEM quantity price for a Z80A was less than a buck a chip. --Chuck --===============1607326104885729934==-- From abuse@cabal.org.uk Sat Apr 20 09:08:35 2024 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 10:37:51 +0200 Message-ID: In-Reply-To: <50e9219a-bd85-41d1-98b8-5e97e8838fd8@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3646870827795971632==" --===============3646870827795971632== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Apr 19, 2024 at 09:34:42PM -0700, Chuck Guzis via cctalk wrote: > On 4/19/24 19:39, ben via cctalk wrote: [...] >> Now is a good time to stock up for any z80 projects or repair, while they >> are $10 or less on epay. Unless people start panic-buying them, Z80 chips are likely to languish in Mouser etc's warehouses for years. After all, Zilog wouldn't stop production of something in high demand. > I seem to remember that in the mid 80s, OEM quantity price for a Z80A was > less than a buck a chip. There's this thing called "inflation", which does tend to become somewhat significant after four decades. In the mid-80s, a pint of beer cost about 70 pence. I've escaped that benighted island, but according to friends who were not so lucky it is now now seven quid in London these days. That's enough to drive you to drink, except, well... --===============3646870827795971632==-- From emu@e-bbes.com Sat Apr 20 12:17:48 2024 From: emanuel stiebler To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 08:17:40 -0400 Message-ID: <031e0131-7108-49c7-8c8d-eacc419f5e8c@e-bbes.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7567087775494445213==" --===============7567087775494445213== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-04-20 04:37, Peter Corlett via cctalk wrote: > Unless people start panic-buying them, Z80 chips are likely to languish in > Mouser etc's warehouses for years. After all, Zilog wouldn't stop production > of something in high demand. They will be still at Mouser/DigiKey for a while, then be moved to Rochester & alike for the time being. You won't be able to buy single quantities anymore, that's all. --===============7567087775494445213==-- From elson@pico-systems.com Sat Apr 20 14:53:55 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 09:53:48 -0500 Message-ID: <9cd78ea9-45f0-8651-0e0c-eef94b953bc1@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0991862719928110850==" --===============0991862719928110850== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/19/24 20:57, Bill Degnan via cctalk wrote: > As it is now, running z80 production must no longer be profitable for > Zilog, but some other manufacturer can license z80 production. Right? If > there is a demand someone will produce them > Rochester Electronics might buy up the masks and uncut wafers. That's their business model. Jon --===============0991862719928110850==-- From elson@pico-systems.com Sat Apr 20 14:55:08 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 09:55:01 -0500 Message-ID: <5f44d68d-8441-f4e5-baf9-44c5a4a4c639@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7833546472894638113==" --===============7833546472894638113== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/19/24 21:07, Fred Cisin via cctalk wrote: > Gee! Have sales gone down? > > One more reason to use the 8080 subset when writing CP/M > programs. > > Aren't there already some licensed second sources? > > Harris also made an all-CMOS plug-compatible Z-80.  I used it in a low-power project. Jon --===============7833546472894638113==-- From cclist@sydex.com Sat Apr 20 16:05:13 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 09:05:01 -0700 Message-ID: <793cc5a4-6fbb-430a-9183-50f40863fdf7@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8885246822749741191==" --===============8885246822749741191== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/20/24 01:37, Peter Corlett via cctalk wrote: > There's this thing called "inflation", which does tend to become somewhat > significant after four decades. > > In the mid-80s, a pint of beer cost about 70 pence. I've escaped that > benighted island, but according to friends who were not so lucky it is now > now seven quid in London these days. That's enough to drive you to drink, > except, well... Absent the price of a pint at the local pub, the sub-$1.00 price for a Z-80 was remarkable for the time. Well within the range of the price range of MSI or even DRAM chips. I note that at the time, Zilog was being run as a subsidiary of Exxon, the oil giant. Other acquisitions of the time, (Qyx, Qwip and Vydec in the Office Systems, Ray Point uranium ore processing) fared as badly from mismanagement as did Zilog. After the relative flop of the Z8000, it seems that the Z80 remained the bread-and-butter part of the whole venture. The other acquisitions appear to be consigned to the dustbin of history. Zilog was fortunately saved from that fate by a buy-back by employees and management in 1989. Still, the succeeding years were pretty rocky, including a Chapter 11 bankruptcy. That Zilog survives today is remarkable. --Chuck --===============8885246822749741191==-- From brain@jbrain.com Sat Apr 20 17:54:37 2024 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 12:54:32 -0500 Message-ID: <915cb586-cec1-4ba3-9c9f-4b9eba55360f@jbrain.com> In-Reply-To: <5f44d68d-8441-f4e5-baf9-44c5a4a4c639@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3187691208141696561==" --===============3187691208141696561== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/20/2024 9:55 AM, Jon Elson via cctalk wrote: > On 4/19/24 21:07, Fred Cisin via cctalk wrote: >> Gee! Have sales gone down? >> >> One more reason to use the 8080 subset when writing CP/M programs. >> >> Aren't there already some licensed second sources? >> >> > Harris also made an all-CMOS plug-compatible Z-80.  I used it in a > low-power project. > > Jon This was my line of thinking... * Aren't there second/third sources for the original? * I understand the core lives on in ez80 and other lines. Is it possible to make a small PCB with a 40 pin DIP footprint and put one of these other designs on there? (I admit I have not looked at the other cores, so perhaps they can't be coaxed to act like just a Z80, just wondering). Jim -- Jim Brain brain(a)jbrain.com www.jbrain.com --===============3187691208141696561==-- From wayne.sudol@hotmail.com Sat Apr 20 18:16:24 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 18:16:17 +0000 Message-ID: In-Reply-To: <915cb586-cec1-4ba3-9c9f-4b9eba55360f@jbrain.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2122140170246197624==" --===============2122140170246197624== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Who still uses the Z80 line for new projects? Wouldn=E2=80=99t it be easier a= nd cheaper to just use an Arduino or Raspberry Pi? =20 Sent from my iPhone > On Apr 20, 2024, at 10:54, Jim Brain via cctalk w= rote: >=20 > to --===============2122140170246197624==-- From brain@jbrain.com Sat Apr 20 18:20:13 2024 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 13:20:06 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185E7665BE416FDE2C1758DE40C2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1495780376297511548==" --===============1495780376297511548== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/20/2024 1:16 PM, Wayne S wrote: > Who still uses the Z80 line for new projects? Wouldn=E2=80=99t it be easier= and cheaper to just use an Arduino or Raspberry Pi? Given the list you're posting on... :-) Jim --===============1495780376297511548==-- From wayne.sudol@hotmail.com Sat Apr 20 18:28:46 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 18:28:36 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4472225413217925054==" --===============4472225413217925054== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Good point but i=E2=80=99m not an trained EE, just a hobbyist so i=E2=80=99m= just curious. I buy Z80=E2=80=99s and other=E2=80=99s for repair projects bu= t =E2=80=A6 Sent from my iPhone > On Apr 20, 2024, at 11:20, Jim Brain wrote: >=20 > =EF=BB=BFOn 4/20/2024 1:16 PM, Wayne S wrote: >> Who still uses the Z80 line for new projects? Wouldn=E2=80=99t it be easie= r and cheaper to just use an Arduino or Raspberry Pi? >=20 > Given the list you're posting on... :-) >=20 > Jim --===============4472225413217925054==-- From bfranchuk@jetnet.ab.ca Sat Apr 20 22:54:17 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 16:54:05 -0600 Message-ID: <3e7e9214-cdad-4af4-97f2-711c39969f8a@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9213939467731062703==" --===============9213939467731062703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-20 12:20 p.m., Jim Brain via cctalk wrote: > On 4/20/2024 1:16 PM, Wayne S wrote: >> Who still uses the Z80 line for new projects? Wouldn’t it be easier >> and cheaper to just use an Arduino or Raspberry Pi? > > Given the list you're posting on... :-) > > Jim True, but the Z80 is 5 volt logic. Still important in my mind plus timing is easy to figure out if you just need 8 bit logic. --===============9213939467731062703==-- From doc@vaxen.net Sat Apr 20 23:30:24 2024 From: Doc Shipley To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 18:30:13 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185E7665BE416FDE2C1758DE40C2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0439555744613260492==" --===============0439555744613260492== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/20/24 13:16, Wayne S via cctalk wrote: > Who still uses the Z80 line for new projects? Wouldn=E2=80=99t it be easier= and cheaper to just use an Arduino or Raspberry Pi? I dissected a dead coffee maker last week that has a current-design 8051=20 clone running the control board. Well-known instruction sets and "Nobody cares if I clone this" make=20 powerful arguments Doc --===============0439555744613260492==-- From bitwiz@12bitsbest.com Sun Apr 21 02:33:47 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 21:33:11 -0500 Message-ID: <8e3f290a-19a4-42ed-bbfc-29c57b2d4765@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3183340035552422208==" --===============3183340035552422208== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit For anything more sophisticated than your coffee pot the RP2040 from Raspberry Pie is a fantastic little chip, dual core 133 MHz Cortex M0+ with 8 PIO engines, 264K of RAM, ADC, UART, SPI, I2C all for under a dollar.  I designed a fully functional RP2040 with 16 Mb flash for under $2.00.  In large enough quantities that's encroaching on 8 bit PIC territory at over 1000 times the memory and CPU power. On 4/20/2024 6:30 PM, Doc Shipley via cctalk wrote: > On 4/20/24 13:16, Wayne S via cctalk wrote: >> Who still uses the Z80 line for new projects? Wouldn’t it be easier >> and cheaper to just use an Arduino or Raspberry Pi? > > I dissected a dead coffee maker last week that has a current-design > 8051 clone running the control board. > > Well-known instruction sets and "Nobody cares if I clone this" make > powerful arguments > > > Doc --===============3183340035552422208==-- From bfranchuk@jetnet.ab.ca Sun Apr 21 06:09:59 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 00:09:47 -0600 Message-ID: <47993635-fe7a-4b0a-8054-8f8e77dce245@jetnet.ab.ca> In-Reply-To: <8e3f290a-19a4-42ed-bbfc-29c57b2d4765@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2214170403201781942==" --===============2214170403201781942== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-20 8:33 p.m., Mike Katz via cctalk wrote: > For anything more sophisticated than your coffee pot the RP2040 from > Raspberry Pie is a fantastic little chip, dual core 133 MHz Cortex M0+ > with 8 PIO engines, 264K of RAM, ADC, UART, SPI, I2C all for under a > dollar.  I designed a fully functional RP2040 with 16 Mb flash for under > $2.00.  In large enough quantities that's encroaching on 8 bit PIC > territory at over 1000 times the memory and CPU power. I am wishing for a Quality Product, cheap crap is not always better. USB comes to mind. 256Kb ram is only 32K 64 bit words. Cache memory never works. My $5 internet toaster, just exploded after 3 days. So what? Just buy the new model that works with windows 12. Download a buggy new tool chain. The Z80 tools worked. The PDP8 was built to last. 50+ years and going strong. NOT the crappy PI PDP-8 or PDP-10. I give it 2 years max. Now a PI style computer with compact FLASH x 2, NO USB and 2 MEG ram , real serial and printer ports that will work in a noisy industrial setting, would be quite usefull. I'd pay even $3 for it. :) --===============2214170403201781942==-- From bfranchuk@jetnet.ab.ca Sun Apr 21 06:15:52 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP8 @ 50 Date: Sun, 21 Apr 2024 00:15:41 -0600 Message-ID: <8e875ece-241d-4187-86e3-2a97c37a6c32@jetnet.ab.ca> In-Reply-To: <47993635-fe7a-4b0a-8054-8f8e77dce245@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6863336750554995939==" --===============6863336750554995939== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit https://www.youtube.com/watch?v=YXTQvlkYJvI&t=4s --===============6863336750554995939==-- From bitwiz@12bitsbest.com Sun Apr 21 15:08:13 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 09:45:23 -0500 Message-ID: <62283ced-75c8-484d-9df6-d4e5e88189c8@12bitsbest.com> In-Reply-To: <47993635-fe7a-4b0a-8054-8f8e77dce245@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1360545285816584776==" --===============1360545285816584776== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Well my PDP-8 was built in 1974 and is still running (with careful maintenance).  My PiDP-8/I has been up and running continuously with a Raspberry PI 3B running it for about 5 years now.  My PiDP-11 has been up and running with a PI-4B for more than 4 years continuously. Though I agree with your comment that the PDP-8 was built to last (just ignore the disintegrated foam used between the motherboard and the case or on the case top) I have PCs that are more than 10 years old that are still running. As for the RP2040 being cheap crap, I beg to differ with you.  It is a solid chip, produced in 10s of millions at least.  And, I would bet, a better quality chip than your Z-80, if due only to improved IC manufacturing technologies. Just because it's old doesn't make it good.  I worked on a 32KHz 4 Bit CPU (about 20 years ago) where the development hardware was very unstable and the tool chain not a whole lot better. Early Microsoft and Lattice C compilers for the PC were buggy as hell.  If you want I can list a few bugs from each of them in another thread. One of the biggest features of the Z-80, the extra register set, was rarely used in open source software in order to maintain compatibility with the 8080. Some of the early Z-80 CP/M tools did not work because they were derived from 8080 tools.  After time the tools got better.  That is the case with any piece of software.  If it doesn't become obsolete and if maintained it will get better over time. On 4/21/2024 1:09 AM, ben via cctalk wrote: > On 2024-04-20 8:33 p.m., Mike Katz via cctalk wrote: >> For anything more sophisticated than your coffee pot the RP2040 from >> Raspberry Pie is a fantastic little chip, dual core 133 MHz Cortex >> M0+ with 8 PIO engines, 264K of RAM, ADC, UART, SPI, I2C all for >> under a dollar.  I designed a fully functional RP2040 with 16 Mb >> flash for under $2.00.  In large enough quantities that's encroaching >> on 8 bit PIC territory at over 1000 times the memory and CPU power. > > I am wishing for a Quality Product, cheap crap is not always better. > USB comes to mind. > 256Kb ram is only 32K 64 bit words. Cache memory never works. > My $5 internet toaster, just exploded after 3 days. > So what? Just buy the new model that works with windows 12. > Download a buggy new tool chain. The Z80 tools worked. > > > The PDP8 was built to last. 50+ years and going strong. > NOT the crappy PI PDP-8 or PDP-10. I give it 2 years max. > Now a PI style computer with compact FLASH x 2, NO USB > and 2 MEG ram , real serial and printer ports that will work > in a noisy industrial setting, would be quite usefull. > I'd pay even $3 for it. :) > > > > --===============1360545285816584776==-- From cclist@sydex.com Sun Apr 21 16:27:36 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 09:27:25 -0700 Message-ID: In-Reply-To: <62283ced-75c8-484d-9df6-d4e5e88189c8@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3762811283180337479==" --===============3762811283180337479== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/21/24 07:45, Mike Katz via cctalk wrote: > One of the biggest features of the Z-80, the extra register set, was > rarely used in open source software in order to maintain compatibility > with the 8080. My understanding of the extra (partial) set of registers on the Z80 was that they were intended for a quick context switch particularly when processing interrupts--another interesting feature of the Z80 that was rarely used. So, for ordinary user code, they were a no-go. The alternative on the Intel MPUs was to push each 16-bit register pair at the entry of the interrupt routine and then pop them at the end; a relatively slow process, made worse by the requirements for extra stack space. Of course, the extra register feature went largely unused, as relatively few consumer- or hobbyist-level products actually made much use of the interrupt feature, much less, the 256-level vectored interrupt facility. The 8086 continued this trend of requiring explicit saves; some of the NEC V-series chips (e.g. V25), however, did implement extra register sets (8 total, IIRC) for fast context switches. --Chuck --===============3762811283180337479==-- From bitwiz@12bitsbest.com Sun Apr 21 16:37:17 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 11:37:07 -0500 Message-ID: <1db9aae2-0880-4d4c-bb30-55388f3bbad2@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1141540153898777312==" --===============1141540153898777312== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Even the 6809 could push up to 8 registers (up to 10 bytes) at once on one of two stacks in a single two byte instruction. On 4/21/2024 11:27 AM, Chuck Guzis via cctalk wrote: > On 4/21/24 07:45, Mike Katz via cctalk wrote: > >> One of the biggest features of the Z-80, the extra register set, was >> rarely used in open source software in order to maintain compatibility >> with the 8080. > My understanding of the extra (partial) set of registers on the Z80 was > that they were intended for a quick context switch particularly when > processing interrupts--another interesting feature of the Z80 that was > rarely used. So, for ordinary user code, they were a no-go. The > alternative on the Intel MPUs was to push each 16-bit register pair at > the entry of the interrupt routine and then pop them at the end; a > relatively slow process, made worse by the requirements for extra stack > space. > > Of course, the extra register feature went largely unused, as relatively > few consumer- or hobbyist-level products actually made much use of the > interrupt feature, much less, the 256-level vectored interrupt facility. > > The 8086 continued this trend of requiring explicit saves; some of the > NEC V-series chips (e.g. V25), however, did implement extra register > sets (8 total, IIRC) for fast context switches. > > --Chuck --===============1141540153898777312==-- From cclist@sydex.com Sun Apr 21 17:16:45 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 10:16:32 -0700 Message-ID: <60b5efcc-adda-4584-a91c-c49480a0e27f@sydex.com> In-Reply-To: <1db9aae2-0880-4d4c-bb30-55388f3bbad2@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7896249921082515221==" --===============7896249921082515221== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/21/24 09:37, Mike Katz wrote: > Even the 6809 could push up to 8 registers (up to 10 bytes) at once on > one of two stacks in a single two byte instruction. The 6809 was introduced the same year as the 8086. The 80186, introduced in 1982, did have the "PUSHA POPA" instructions and was considerably faster and more complex than the 8086. As far as I could tell, the 6809 was an evolutionary dead-end, meant to fill the gap between the very slow 6800 and the very advanced 68000; that made the OEMs a bit uneasy, hence its limited adoption. It was also very expensive for an 8 bit MPU--a key criterion for adoption. --Chuck --===============7896249921082515221==-- From bfranchuk@jetnet.ab.ca Sun Apr 21 19:11:40 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 13:11:28 -0600 Message-ID: <37d6db33-6234-44be-b82b-8a49871ea404@jetnet.ab.ca> In-Reply-To: <62283ced-75c8-484d-9df6-d4e5e88189c8@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3677065736433437460==" --===============3677065736433437460== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-21 8:45 a.m., Mike Katz wrote: > As for the RP2040 being cheap crap, I beg to differ with you.  It is a > solid chip, produced in 10s of millions at least.  And, I would bet, a > better quality chip than your Z-80, if due only to improved IC > manufacturing technologies. > The pi looks like parts were picked for lowest cost,biggest profit, like most products today. RISC chips have been around for 40 years, and yet versions change like hotcakes every year. I just want a product that is more robust, than the bleeding edge of technology. I product must meet my needs,not what some sales man said I need. I keep finding I still need 74XX just for having 10 TTL loads, and 74LSXX just does not have the power. > Just because it's old doesn't make it good.  I worked on a 32KHz 4 Bit > CPU (about 20 years ago) where the development hardware was very > unstable and the tool chain not a whole lot better. > > Early Microsoft and Lattice C compilers for the PC were buggy as hell. > If you want I can list a few bugs from each of them in another thread. > The PC was buggy as hell. Other than the 68000 and the National 16032 I can't think what real cpu is with more than 64Kb. The 386 has problems. The IBM 360 or VAX never made it the home market. The ARM was UK product. > One of the biggest features of the Z-80, the extra register set, was > rarely used in open source software in order to maintain compatibility > with the 8080. > I thought the main problem was you could not keep track of what set you were using. > Some of the early Z-80 CP/M tools did not work because they were derived > from 8080 tools.  After time the tools got better.  That is the case > with any piece of software.  If it doesn't become obsolete and if > maintained it will get better over time. Most places only up grades software, if somebody pays for it. You can never get the OK to upgrade of fix software, but when you do they want it yesterday. Ben. PS: Looking the reply email, I say 20 bits is the best. --===============3677065736433437460==-- From paulkoning@comcast.net Sun Apr 21 20:11:34 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 16:11:25 -0400 Message-ID: <1AB90607-ABAF-4A1C-A74B-53404BC3AF1A@comcast.net> In-Reply-To: <37d6db33-6234-44be-b82b-8a49871ea404@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5246610490116978801==" --===============5246610490116978801== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 21, 2024, at 3:11 PM, ben via cctalk wrote: >=20 > On 2024-04-21 8:45 a.m., Mike Katz wrote: >=20 >> As for the RP2040 being cheap crap, I beg to differ with you. It is a sol= id chip, produced in 10s of millions at least. And, I would bet, a better qu= ality chip than your Z-80, if due only to improved IC manufacturing technolog= ies. > The pi looks like parts were picked for lowest cost,biggest profit, like mo= st products today. RISC chips have been around for 40 years, and yet versions= change like hotcakes every year. Raspberry Pi and Raspberry Pico are entirely different and unrelated devices. I've been using the original Pico and also the Pico-W (with WiFi for one more= dollar) for a bunch of projects; they work well and the price is hard to bea= t. The PIO (programmable state machine) subsystem is particularly impressive= ; for example, I used it to implement a DDCMP sync line interface. paul --===============5246610490116978801==-- From organlists1@sonic.net Sun Apr 21 20:46:47 2024 From: "D. Resor" To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sat, 20 Apr 2024 02:44:50 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5175423722374962367==" --===============5175423722374962367== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here is the article I found, but I suppose others have already seen this? The legendary Ziglog Z80 CPU is being discontinued after nearly 50 years https://www.techspot.com/news/102684-zilog-discontinuing-z80-microprocessor-a= fter-almost-50-years.html Seems while the Ziglog EZ80 is compatible and four times faster, it is in a m= ore modern package, how dare they! =F0=9F=98=89 https://www.zilog.com/docs/um0077.pdf Warning: Do not use Life Support.=20 Who would-ah thunk. Don Resor -----Original Message----- From: Fred Cisin via cctalk =20 Sent: Friday, April 19, 2024 7:08 PM To: cctalk(a)classiccmp.org Cc: Fred Cisin Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Gee! Have sales gone down? One more reason to use the 8080 subset when writing CP/M programs. Aren't there already some licensed second sources? --===============5175423722374962367==-- From jsw@ieee.org Sun Apr 21 21:27:19 2024 From: Jerry Weiss To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 16:27:02 -0500 Message-ID: In-Reply-To: <47993635-fe7a-4b0a-8054-8f8e77dce245@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8278868453850564646==" --===============8278868453850564646== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit While intention might have been to last XX years, I am becoming increasingly pessimistic about longevity of most electronic devices. A crystal radio with an open air capacitor seems like the only good bet. Between electrolytic capacitor aging challenges, discrete and integrated circuit hermetic failures, cost or other inherent technical flaws, I fear most electronics will become inert over time. Many of us have the skills to identify and replace bits to extend the lifetime of many items. I only hope the skills and suitable replacement parts are available as time goes on. --===============8278868453850564646==-- From bfranchuk@jetnet.ab.ca Sun Apr 21 23:10:37 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 17:10:17 -0600 Message-ID: <8dadc27e-db88-427e-85a1-9b56717b44b4@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0751978890400285246==" --===============0751978890400285246== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-21 3:27 p.m., Jerry Weiss wrote: > While intention might have been to last XX years, I am becoming > increasingly pessimistic about longevity of most electronic devices.  A > crystal radio with an open air capacitor seems like the only good bet. > Between electrolytic capacitor aging challenges, discrete and integrated > circuit hermetic failures, cost or other inherent technical flaws, I > fear most electronics will become inert over time.  Many of us have the > skills to identify and replace bits to extend the lifetime of many > items. I only hope the skills and suitable replacement parts are > available as time goes on. But if you want upgrade your radio, try here: http://www.r-type.org/articles/art-028.htm Most electronic devices have a known life time, sadly most of this information is never on the data sheet. --===============0751978890400285246==-- From cclist@sydex.com Sun Apr 21 23:26:45 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 16:26:35 -0700 Message-ID: <3af241bc-2898-4e47-b131-33bc3c223e16@sydex.com> In-Reply-To: <37d6db33-6234-44be-b82b-8a49871ea404@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2854368184286081710==" --===============2854368184286081710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/21/24 12:11, ben via cctalk wrote: > I keep finding I still need 74XX just for having 10 TTL loads, > and 74LSXX just does not have the power. Ever try BiCMOS chips? IIRC, the 74ABTxxx will drive loads of up to 60 ma, far in excess of old 74xx parts. --Chuck --===============2854368184286081710==-- From tarek@infocom.ai Mon Apr 22 00:16:42 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] PDP 8 / 11 via Raspberry Pi Date: Sun, 21 Apr 2024 17:08:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2129176035670334370==" --===============2129176035670334370== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, any tips or guidelines for running an emulated PDP on a Raspberry Pi ? Regards, Tarek Hoteit > On Apr 21, 2024, at 08:08, Mike Katz via cctalk w= rote: >=20 > =EF=BB=BFWell my PDP-8 was built in 1974 and is still running (with careful= maintenance). My PiDP-8/I has been up and running continuously with a Raspb= erry PI 3B running it for about 5 years now. My PiDP-11 has been up and runn= ing with a PI-4B for more than 4 years continuously. >=20 > Though I agree with your comment that the PDP-8 was built to last (just ign= ore the disintegrated foam used between the motherboard and the case or on th= e case top) I have PCs that are more than 10 years old that are still running. >=20 > As for the RP2040 being cheap crap, I beg to differ with you. It is a soli= d chip, produced in 10s of millions at least. And, I would bet, a better qua= lity chip than your Z-80, if due only to improved IC manufacturing technologi= es. >=20 > Just because it's old doesn't make it good. I worked on a 32KHz 4 Bit CPU = (about 20 years ago) where the development hardware was very unstable and the= tool chain not a whole lot better. >=20 > Early Microsoft and Lattice C compilers for the PC were buggy as hell. If = you want I can list a few bugs from each of them in another thread. >=20 > One of the biggest features of the Z-80, the extra register set, was rarely= used in open source software in order to maintain compatibility with the 808= 0. >=20 > Some of the early Z-80 CP/M tools did not work because they were derived fr= om 8080 tools. After time the tools got better. That is the case with any p= iece of software. If it doesn't become obsolete and if maintained it will ge= t better over time. >=20 >=20 >=20 >> On 4/21/2024 1:09 AM, ben via cctalk wrote: >>> On 2024-04-20 8:33 p.m., Mike Katz via cctalk wrote: >>> For anything more sophisticated than your coffee pot the RP2040 from Rasp= berry Pie is a fantastic little chip, dual core 133 MHz Cortex M0+ with 8 PIO= engines, 264K of RAM, ADC, UART, SPI, I2C all for under a dollar. I designe= d a fully functional RP2040 with 16 Mb flash for under $2.00. In large enoug= h quantities that's encroaching on 8 bit PIC territory at over 1000 times the= memory and CPU power. >>=20 >> I am wishing for a Quality Product, cheap crap is not always better. >> USB comes to mind. >> 256Kb ram is only 32K 64 bit words. Cache memory never works. >> My $5 internet toaster, just exploded after 3 days. >> So what? Just buy the new model that works with windows 12. >> Download a buggy new tool chain. The Z80 tools worked. >>=20 >>=20 >> The PDP8 was built to last. 50+ years and going strong. >> NOT the crappy PI PDP-8 or PDP-10. I give it 2 years max. >> Now a PI style computer with compact FLASH x 2, NO USB >> and 2 MEG ram , real serial and printer ports that will work >> in a noisy industrial setting, would be quite usefull. >> I'd pay even $3 for it. :) >>=20 >>=20 >>=20 >>=20 >=20 --===============2129176035670334370==-- From bfranchuk@jetnet.ab.ca Mon Apr 22 00:44:29 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 18:44:15 -0600 Message-ID: <765ff1a1-c2be-460a-b52b-46c05ff55515@jetnet.ab.ca> In-Reply-To: <3af241bc-2898-4e47-b131-33bc3c223e16@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4233318756875944481==" --===============4233318756875944481== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-04-21 5:26 p.m., Chuck Guzis via cctalk wrote: > On 4/21/24 12:11, ben via cctalk wrote: >> I keep finding I still need 74XX just for having 10 TTL loads, >> and 74LSXX just does not have the power. > > Ever try BiCMOS chips? IIRC, the 74ABTxxx will drive loads of up to 60 > ma, far in excess of old 74xx parts. > > --Chuck Thru the hole and 5 volt and cheap and easy to find ( at one time ) and low edge rates , are important for me as I have kitchen table kind of projects. Before you say use XXX , I don't have the skills or the tools to layout and debug high tech boards or parts. I am very unlucky with FPGA stuff. My current bit slice computer design has some sort of dynamic problem, as only some instructions will run or read correctly. Halt and STOP don't work. Front panel works mostly. I need to rethink a whole new design,as something I can build and test and find parts for. The goal is a 20 bit word length computer, with 10 bit bytes,bit slices, Compact flash , UART's and blinking light front panel. I may run in emulation, until I can get hardware built and debugged but I have not found a host computer I like. So if any one wishes to take on this project, feel free using modern parts. Ben. * april 21 2024 sdc 1 Small Data Processor 1 .815 uS CYCLE TIME - BYTE BASED COMPUTER - INDEX REG'S - REGISTER OPS - CARRY BIT - AUTO/INDEX - LOGIC OPERATIONS - HEX FRONT PANEL MM 00 0 0 10 2 1 01 WRD wrd 11 SEX sx 5 4 3 2 1 +----+----+----+----+----+ |OOOO:AAAA|XXXX:B321|+###| NORMAL +----+----+----+----+----+ OP TC 0 ST SUB ADD 1 ADD ADD RAMU Z SUB 2 SUB SUB RAMU C SBR 3 CAD SBR RAMU S OR 4 LD OR AND 5 OR OR RAMD Z BIT 6 AND AND RAMD C XOR 7 XOR XOR RAMD S XNR F C 0 0 0... CF F C 0 0 1... UART i = index , 0 # CCC COND TRAP (0) <- PC PC <- 2 ADR LOAD N 0 H/Z ST 1 A LD RAMU Z 2 B ADD RAMU C 3 C(carry)SUB RAMU S 4 G OR 5 X AND RAMD Z 6 Y XOR RAMD C 7 F/F JMP RAMD S REG C is CARRY IR PC CTL 0 0 TEST 0 1 DSP 1 0 HLT 1 1 DI/EI ----------------------- M1 = a/m1 M2 = b/m2 M3 = idx ---- M3,M2,M1 ST OP 0 0 0 CTL OP # 0 8 bits 0 0 1 HLT SCC 1 0 1 0 ST R+ OP R+ 2 0 1 1 JSV R+2 JCC R+2 3 1 0 0 - REG 4 1 0 1 - SFT 5 1 1 0 ST @R+ OP @R+ 6 1 1 1 ST X ST X 7 ----------------------- '/' LINE COMMENT 'star' BLOCK COMMENT BEGIN/END ONLY #OOO OCTAL PROGRAM COUNTER ______________ | KROMA.PLD | CP x---|1 24|---x Vcc AD7 x---|2 23|---x WR AD6 x---|3 22|---x PRA0 AD5 x---|4 21|---x PRA1 AD4 x---|5 20|---x PRA2 AD3 x---|6 19|---x PRA3 AD2 x---|7 18|---x PRA4 AD1 x---|8 17|---x PRA5 AD0 x---|9 16|---x PRA6 AUX x---|10 15|---x PRA7 x---|11 14|---x M3 GND x---|12 13|---x CLR_ |______________| [II8,sft,no,ld,ra,m2,m1,op,w,WR] ______________ | KROMB.PLD | CP x---|1 24|---x Vcc AD7 x---|2 23|---x BY AD6 x---|3 22|---x PRB0 AD5 x---|4 21|---x PRB1 AD4 x---|5 20|---x PRB2 AD3 x---|6 19|---x PRB3 AD2 x---|7 18|---x PRB4 AD1 x---|8 17|---x PRB5 AD0 x---|9 16|---x PRB6 aux x---|10 15|---x PRB7 x---|11 14|---x RD GND x---|12 13|---x CLR_ |______________| [RD,ctl,rx,rd',in',ir,mar,rd,b,BY] OCTAL CPU FOR 20 BITS ( RUN,ST)(M3,M2,M1) (cnt 3,2,1) 7 6 5 4 3 2 1 0 * / TIMES ARE IN MICROSECONDS #100 / IDLE PANEL ALL 4 CLOCKS 3.26 AC SW MAR NO PC CTL PC IR #110 / LOAD ADR AC LD WRD PC LD WRD MAR / DON'T CARE TERM AC PC IR #120 / READ MEM -> AC AC WRD LD PC 1 Y MAR AC RD IN AC LD WRD IR #130 / WRITE MEM -> AC AC WRD LD PC 1 Y MAR AC WR RD PC IR #200 / QUICK # 2 CLOCKS 1.63 PC 1 Y MAR AC OP SX BY RD IR #210 / SCC 3 CLOCKS 2.45 PC 1 Y MAR AC CTL AC LD IR RD PC / MET CC AC SX LD IR RD #220 / R+ 4 CLOCKS 3.26 IX SX Y MAR AC RD IN BY PC 1 Y MAR AC WRD OP IR RD #230 / JCC R+ 4 CLOCKS 3.26 CONDITION NOT MET IX 1 Y MAR AC CTL SX RD IN // ADD CONSTANT PC 1 Y MAR PC IR RD / MET CC SW NO MAR / 6 CLOCKS 5.4 CONDITION MET PC CTL / DISPLAY AC PC PC LD WRD MAR PC 1 IR RD #240 / REG OP 4 CLOCKS 2.26 IX NO WR IN / put IX on the bus PC 1 Y MAR AC OP WRD IR RD #250 / SHIFT x 1 2 CLOCKS 1.63 PC 1 Y MAR AC SFT IR RD #260 / MEM @ R+ 4 CLOCKS 3.26 IX SX Y MAR AC RD IN PC NO LD WRD MAR AC RD IN BY PC 1 Y MAR AC OP WRD IR RD #270 / MEM X 6 CLOCKS 4.89 PC 1 Y MAR PC RD IN IX NO WRD MAR AC RD IN BY PC 1 Y MAR AC OP WRD IR RD / store ops #300 / DI 2 CLOCKS 1.63 PC 1 Y MAR SW CTL RD IR #302 /TRAP / pc -> 0 pc = 1 PC LD NO MAR SW CTL RD WR PC LD 1 MAR PC RD IN PC LD WRD MAR PC 1 RD IR #310 / hlt 2 CLOCKS 1.63 PC 1 Y MAR IX CTL RD IR #320 / ST # 4 CLOCKS 3.26 IX SX Y MAR AC RD WR BY PC 1 Y MAR AC IR RD #330 JSV R+ 6 CLOCKS 4.89 IX 2 Y MAR PC RD IN AC 1 SUB MAR PC WR RD PC LD WRD MAR PC 1 IR RD #340 / NOP PC 1 Y MAR PC RD IR #350 / NOP PC 1 Y MAR AC IR RD #360 / ST @ R+ IX SX Y MAR AC RD IN PC NO LD WRD MAR AC RD WR BY PC MAR PC 1 IR RD #370 / MEM X 6 CLOCKS 4.89 PC 1 Y MAR AC RD IN IX NO WRD MAR AC RD WR BY PC 1 Y MAR PC IR RD / ALL DONE $ --===============4233318756875944481==-- From cctalk@beyondthepale.ie Mon Apr 22 00:50:22 2024 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 01:06:42 +0100 Message-ID: <01T4ONTDB83U8WVYW0@beyondthepale.ie> In-Reply-To: =?utf-8?q?=3C!=26!AAAAAAAAAAAYAAAAAAAAABO5wTM7/NRDgk/3nPo+uv7Cg?= =?utf-8?q?AAAEAAAAJhLkxRLBbROg14P/KlQa5EBAAAAAA=3D=3D=40sonic=2Enet=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2479046029553477829==" --===============2479046029553477829== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My first exposure to a computer at home was a BBC Micro with 32kB of RAM and 32kB of ROM. Included in this was a 16kB BASIC ROM which was regarded as fast and powerful, featuring 32 bit integer variables, 40 bit floating point variables, variable length strings, structured programming constructs and everything accessed by keyword statements rather than PEEK this and POKE that. This was implemented by a humble 6502 running at (mostly) 2MHz, with one 8 bit arithmetic register, two 8 bit index registers, one 8 bit stack pointer, a 16 bit program counter and a few flag bits. I would have expected that a computers featuring a Z80 with its larger regist= er set, 16 bit arithmetic operations, richer instruction set and general bells and whistles would have been able to produce a much superior implementation in terms of speed or features or both but I never came across one. Why is that? Did the Z80 take more cycles to implement it's more complex instructions? Is this an early example of RISC vs CISC? Regards, Peter Coghlan --===============2479046029553477829==-- From wrcooke@wrcooke.net Mon Apr 22 01:17:12 2024 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Sun, 21 Apr 2024 20:17:05 -0500 Message-ID: <28682700.8880622.1713748625716@email.ionos.com> In-Reply-To: <01T4ONTDB83U8WVYW0@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0726948092879707229==" --===============0726948092879707229== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 04/21/2024 7:06 PM CDT Peter Coghlan via cctalk wrote: > > > > Why is that? Did the Z80 take more cycles to implement it's more complex > instructions? Is this an early example of RISC vs CISC? > > Regards, > Peter Coghlan I'm certainly no authority, but I have programmed both processors in assembly= and studied them somewhat. It took many years for me to believe that the 65= 02 was "faster" than the Z80, but now I'm (mostly) a believer. So here is my= take. First, yes, the Z80 takes roughly 4 times as many clock cycles per instructio= n. Where the 6502 can complete a simple instruction in a single clock, the Z= 80 takes a minimum of four. The 02 certainly has a simpler architecture, but calling it a RISC machine wo= uld probably make the RISC believers cringe. It is simple, but it doesn't fo= llow the pattern of lots of registers (well, maybe) and a load/store architec= ture. But that may be its strongest point. The zero page instructions effec= tively make the first 256 bytes of RAM into a large (128 or 256) register fil= e. Along with all those pseudo-registers in page zero, the 02 has some really ni= ce addressing modes. In effect, all those pseudo registers can be used as in= dex registers in addition to directly holding operands. The simple, fast ins= tructions operating on 8 bit registers runs fast. In the Z80, there are a fa= ir number of registers, but most are limited to what they can be used for. Y= ou almost always have to go through the accumulator (register A.) So you end= up moving stuff between memory and various registers, often shuffling stuff = around once loaded, then store it back to memory. The Z80 has the IX and IY = index registers, but they are even slower, adding another machine cycle (4 cl= ocks?) to an already slowish instruction just for the fetch, then another mem= ory cycle. If you have to load the operand then store the result, that doubl= es the extra time needed. So all of that leads to faster assembly language on the 02. Good 6502 progra= mmers (I'm NOT one of them) know tons of tricks to get the most out of it, to= o. People spent years learning the ins and outs of that particular processor= . I think the Z80 didn't get that kind of love, at least not as much. Most = Z80 machines were running CP/M and most didn't have the graphics and sound th= at made the 02 machines no nice for home computers and games. In addition, a= n awful lot of Z80 code/programmers were part time, moving to and from the 80= 80 which was really a different machine. As a rough approximation I would say that a Z80 would require somewhere betwe= en 4 to 8 times the clock for equivalent assembly language performance. No d= oubt others will have other opinions. However, the Z80 was probably more likable by the computer science people. A= nd it was a LOT easier to write a halfway decent compiler for. It didn't nee= d as many "tricks" to make it perform. If you look at compiled code for the = two, you will usually either find severe limitations on the 02 or very slow c= ode. Especially if you are looking at any "modern" language (Algol family, s= uch as C or Pascal.) A BASIC (or perhaps even Fortran) compiler that doesn't= have all the local variables and nested structure will usually fare better. Anyway, that's my 1/2 cent worth. Take it for what its worth. Will Grownups never understand anything by themselves and it is tiresome for child= ren to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince --===============0726948092879707229==-- From cclist@sydex.com Mon Apr 22 02:27:03 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Sun, 21 Apr 2024 19:26:47 -0700 Message-ID: In-Reply-To: <765ff1a1-c2be-460a-b52b-46c05ff55515@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3298455193239017231==" --===============3298455193239017231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/21/24 17:44, ben via cctalk wrote: > On 2024-04-21 5:26 p.m., Chuck Guzis via cctalk wrote: >> On 4/21/24 12:11, ben via cctalk wrote: >>> I keep finding I still need 74XX just for having 10 TTL loads, >>> and 74LSXX just does not have the power. >> >> Ever try BiCMOS chips?   IIRC, the 74ABTxxx will drive loads of up to 60 >> ma, far in excess of old 74xx parts. >> >> --Chuck > > Thru the hole and 5 volt and cheap and easy to find ( at one time ) and > low edge rates , are important for me as I have  kitchen table kind of > projects. > Before you say use XXX , I don't have the skills or the tools to layout > and debug high tech boards or parts. I am very unlucky with FPGA stuff. Look at my Pertec-interface controller board. All through-hole, but for the MCU board (easier to buy than to build). You can see the 74ABT573 drivers for the drive cable. I run my own on 3m cables with no problems. --Chuck --===============3298455193239017231==-- From billdegnan@gmail.com Mon Apr 22 02:39:23 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: PDP 8 / 11 via Raspberry Pi Date: Sun, 21 Apr 2024 22:39:05 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7991529947017739542==" --===============7991529947017739542== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Tarek I made a post with some tips for the pidp8 https://vintagecomputer.net/browse_thread.cfm?id=663 BIll On Sun, Apr 21, 2024 at 8:16 PM Tarek Hoteit via cctalk < cctalk(a)classiccmp.org> wrote: > Mike, any tips or guidelines for running an emulated PDP on a Raspberry Pi > ? > > Regards, > Tarek Hoteit > > --===============7991529947017739542==-- From paulkoning@comcast.net Mon Apr 22 13:26:14 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 09:26:05 -0400 Message-ID: <6C317320-CE91-4E51-9B38-83EF091F7B9C@comcast.net> In-Reply-To: <28682700.8880622.1713748625716@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7196979040906947002==" --===============7196979040906947002== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 21, 2024, at 9:17 PM, Will Cooke via cctalk wrote: >=20 >=20 >=20 >> On 04/21/2024 7:06 PM CDT Peter Coghlan via cctalk wrote: >>=20 >>=20 >>=20 >> Why is that? Did the Z80 take more cycles to implement it's more complex >> instructions? Is this an early example of RISC vs CISC? >>=20 >> Regards, >> Peter Coghlan >=20 > I'm certainly no authority, but I have programmed both processors in assemb= ly and studied them somewhat. It took many years for me to believe that the = 6502 was "faster" than the Z80, but now I'm (mostly) a believer. So here is = my take. >=20 > First, yes, the Z80 takes roughly 4 times as many clock cycles per instruct= ion. Where the 6502 can complete a simple instruction in a single clock, the= Z80 takes a minimum of four. >=20 > The 02 certainly has a simpler architecture, but calling it a RISC machine = would probably make the RISC believers cringe. It is simple, but it doesn't = follow the pattern of lots of registers (well, maybe) and a load/store archit= ecture. But that may be its strongest point. The zero page instructions eff= ectively make the first 256 bytes of RAM into a large (128 or 256) register f= ile. > ... Cycles per instruction is one aspect of RISC vs. CISC but there are more, and= cycles per instruction may not be the most significant one. Given enough silicon and enough brainpower thrown at the problem, CISC machin= es can be made to run very fast. Consider modern x86 machines for example. = But the key point is "given enough silicon...". =20 I think the significance of RISC isn't so much in cycles per instruction but = rather in simplicity of implementation (for a given level of performance). I= t's not just single cycle instructions. In RISC architectures it is often ea= sier to achieve pipelining and parallelism. Consider what's arguably the fir= st example, the CDC 6600 with its parallelism, and its sibling the 7600 which= made the rather obvious addition of pipelining. Simplicity of implementation means either lower cost for a given level of per= formance, or higher achievable performance for a given level of technology, o= r lower power per unit of performance, or easier power management optimizatio= n, or any combination of the above. Consider ARM machines vs. x86. It's not= so much that ARM machines go faster but that they do so on a fraction of the= power, and that they require only a small amount of silicon to do so. One other factor is that RISC machines rely on simple operations carefully ar= ranged by optimizing compilers (or, in some cases, skillfull programmers). A= multi-step operation can be encoded in a sequence of RISC operations run thr= ough an optimizing scheduler more effectively than the equivalent sequence of= steps inside the micro-engine of a CISC processor. paul --===============7196979040906947002==-- From lowen@pari.edu Mon Apr 22 15:42:10 2024 From: Lamar Owen To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 11:36:16 -0400 Message-ID: In-Reply-To: <01T4ONTDB83U8WVYW0@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1123399134871255262==" --===============1123399134871255262== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/21/24 20:06, Peter Coghlan via cctalk wrote: > Why is that? Did the Z80 take more cycles to implement it's more complex > instructions? Is this an early example of RISC vs CISC? Z80 is blessed with a 4-bit ALU, verified by reverse engineering dieshots ( https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html ). Die real estate forced the design to do without a full 8-bit ALU. When=20 you have a 4-bit ALU, and you are doing 16-bit math, you will need 4=20 cycles through the ALU. Neither 6502 nor Z80 are RISC.=C2=A0 6502 simply runs very efficiently thanks= =20 to the design decisions made; 8 bit ALU, 8 bit registers for everything,=20 including stack.=C2=A0 Math is fast.=C2=A0 Biphase clocking allows what could= be=20 considered a precursor of double-data-rate designs. The Visual6502=20 project shows the 'tick-tock' of it very well. If you want to see what can be done with sufficient real estate on the=20 chip and using more modern design methodologies, pick up a copy of Monte=20 Dalrymple's book "Microprocessor Design using Verilog HDL' (=20 https://www.elektor.com/products/microprocessor-design-using-verilog-hdl-e-bo= ok=20 )in either ebook or paperback form (I bought both); Monte was=20 responsible for Z380 among other designs, and they are very efficient.=C2=A0 = Today's eZ80 builds on that, and is as efficient as the 6502 and much,=20 much faster. There are many softcores out there, so Z80 lives on in both those as=20 well as the Z180 (several parts are EoL (either last-time-buy or=20 obsolete) but some parts are still Active) and the eZ80 (most=20 instructions on eZ80 are single-cycle, and the chip is pipelined; eZ80=20 has a 24-bit ALU; plus, eZ80 is a very capable microcontroller).=C2=A0 The=20 Z84015, in both 6 and 10MHz variants, still shows as Active at Digikey.=C2=A0= =20 ALL are of course surface mount. Through-hole anything is a dying breed. The Z80 is dead; long live the Z80. --===============1123399134871255262==-- From wdonzelli@gmail.com Mon Apr 22 16:14:45 2024 From: William Donzelli To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 12:14:30 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4889961427078872838==" --===============4889961427078872838== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > The Z80 is dead; long live the Z80. They said that about the UX-201A...and every year hundreds or thousands of new ones show up. -- Will --===============4889961427078872838==-- From cclist@sydex.com Mon Apr 22 16:18:39 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 09:18:13 -0700 Message-ID: <136e50ca-6ee6-436d-9942-52f489dd89ba@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4653464241779315722==" --===============4653464241779315722== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/22/24 08:36, Lamar Owen via cctalk wrote: > Die real estate forced the design to do without a full 8-bit ALU. When > you have a 4-bit ALU, and you are doing 16-bit math, you will need 4 > cycles through the ALU. I don't know if this applies to the Z80, but on the 8080, 16-bit increment/decrement is handled by a separate increment block (also used to advance the P-counter and stack operations). Probably one of the reasons that INX/DCX doesn't set any flags. --Chuck --===============4653464241779315722==-- From glen.slick@gmail.com Mon Apr 22 16:51:31 2024 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 09:51:13 -0700 Message-ID: In-Reply-To: <136e50ca-6ee6-436d-9942-52f489dd89ba@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0512640272535623545==" --===============0512640272535623545== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 22, 2024 at 9:18 AM Chuck Guzis via cctalk wrote: > > On 4/22/24 08:36, Lamar Owen via cctalk wrote: > > > Die real estate forced the design to do without a full 8-bit ALU. When > > you have a 4-bit ALU, and you are doing 16-bit math, you will need 4 > > cycles through the ALU. > > I don't know if this applies to the Z80, but on the 8080, 16-bit > increment/decrement is handled by a separate increment block (also used > to advance the P-counter and stack operations). Probably one of the > reasons that INX/DCX doesn't set any flags. All sorts of interesting details are covered in several of Ken Shirriff's blog posts. Here are a few: The Z-80 has a 4-bit ALU. Here's how it works. https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html Reverse-engineering the Z-80: the silicon for two interesting gates explained https://www.righto.com/2013/09/understanding-z-80-processor-one-gate.html The Z-80's 16-bit increment/decrement circuit reverse engineered https://www.righto.com/2013/11/the-z-80s-16-bit-incrementdecrement.html Why the Z-80's data pins are scrambled https://www.righto.com/2014/09/why-z-80s-data-pins-are-scrambled.html --===============0512640272535623545==-- From lowen@pari.edu Mon Apr 22 16:54:52 2024 From: Lamar Owen To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 12:54:46 -0400 Message-ID: In-Reply-To: <136e50ca-6ee6-436d-9942-52f489dd89ba@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2990782350244135190==" --===============2990782350244135190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/22/24 12:18, Chuck Guzis via cctalk wrote: > I don't know if this applies to the Z80, but on the 8080, 16-bit > increment/decrement is handled by a separate increment block (also used > to advance the P-counter and stack operations). Probably one of the > reasons that INX/DCX doesn't set any flags. 16-bit INC and DEC are indeed handled by a separate block, which also gets used to increment PC and decrement SP at the appropriate times.  Ken's page on the 4-bit ALU has a 'mapped' dieshot showing it. Ken covers it operation in the blog article https://www.righto.com/2013/11/the-z-80s-16-bit-incrementdecrement.html --===============2990782350244135190==-- From cclist@sydex.com Mon Apr 22 17:27:05 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 10:26:51 -0700 Message-ID: <810fad9a-dc24-4465-bb6c-de934e1a6c9f@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6947845658313525843==" --===============6947845658313525843== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/22/24 09:54, Lamar Owen via cctalk wrote: > On 4/22/24 12:18, Chuck Guzis via cctalk wrote: >> I don't know if this applies to the Z80, but on the 8080, 16-bit >> increment/decrement is handled by a separate increment block (also used >> to advance the P-counter and stack operations).  Probably one of the >> reasons that INX/DCX doesn't set any flags. > 16-bit INC and DEC are indeed handled by a separate block, which also > gets used to increment PC and decrement SP at the appropriate times.  > Ken's page on the 4-bit ALU has a 'mapped' dieshot showing it. Ken > covers it operation in the blog article > https://www.righto.com/2013/11/the-z-80s-16-bit-incrementdecrement.html Interesting document. Ken also documents the K and V flags in the 8085. I was aware of the use of the K flag with the 16-bit INX/DCX operations as an over/underflow indicator for 16-bit inc-decrements. He also points out that it comes into play with the usual 8-bit ALU operations. https://www.righto.com/2013/02/looking-at-silicon-to-understanding.html One question that I've long had is if the K flag is set in case of a "wraparound" situation with the PC or stack pointer. I have never checked that (and 8085 programming is in my dimming past), but I suspect that it does indeed get set, since the "wrap" of those registers would be pretty uncommon in normal-functioning code. Managing underflow with a 16-bit decrement is certainly useful and can cut out a few instructions to test that situation. However, the K flag being restricted to the 8085 pretty much limits its use when viewed in the universe of other x80 CPUs. Somewhat akin to the packed BCD string instructions on the NEC V-series CPUs. Useful? You bet--but not implemented on any of the strict Intel hardware so left to molder away in a dusty corner. --Chuck --===============6947845658313525843==-- From cclist@sydex.com Mon Apr 22 17:29:27 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 10:29:14 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0466217041292542508==" --===============0466217041292542508== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit A bit of a postscript: The ALU on the 8085 according to Ken is 8 bits wide. https://www.righto.com/2013/01/inside-alu-of-8085-microprocessor.html --Chuck --===============0466217041292542508==-- From bill.gunshannon@hotmail.com Mon Apr 22 18:10:05 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 14:09:50 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5191433764011583263==" --===============5191433764011583263== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Following along this line of thought but also in regards all our other small CPUs.... Would it not be possible to use something like a Blue Pill to make a small board (small enough to actually fit in the CPU socket) that emulated these old CPUs? Definitely enough horse power just wondered if there was enough room for the microcode. It would bring an even more interesting concept to the table. The ability to add modifications to some of these chips to see just where they might have gone. While I don't mind the VAX, I always wondered what the PDP-11 could have been if it had been developed instead. :-) bill --===============5191433764011583263==-- From paulkoning@comcast.net Mon Apr 22 18:30:18 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 14:30:11 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737127CE19002266BC0F664ED122=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1414454808308202917==" --===============1414454808308202917== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 2:09 PM, Bill Gunshannon via cctalk wrote: >=20 >=20 >=20 > Following along this line of thought but also in regards all our > other small CPUs.... >=20 > Would it not be possible to use something like a Blue Pill to make > a small board (small enough to actually fit in the CPU socket) that > emulated these old CPUs? Definitely enough horse power just wondered > if there was enough room for the microcode. Microcode? > It would bring an even more interesting concept to the table. The > ability to add modifications to some of these chips to see just where > they might have gone. While I don't mind the VAX, I always wondered > what the PDP-11 could have been if it had been developed instead. :-) >=20 > bill Of course the VAX started out as a modified PDP-11; the name makes that clear= . And I saw an early document of what became the VAX 11/780, labeled PDP-11/= 85. Perhaps that was obfuscation. Anyway, I would think such a small microprocessor could emulate a PDP-11 just= fine, and probably fast enough. The issue isn't so much the instruction set= emulation but rather the electrical interface. That's what would be needed = to be a drop-in replacement. Ignoring the voltage levels, there's the matter= of implementing whatever the bus protocols are. =20 Possibly an RP2040 (the engine in the Raspberry Pico) would serve for this, w= ith the PIO engines providing help with the low level signaling. Sounds like= a fun exercise for the student.=20 paul --===============1414454808308202917==-- From cclist@sydex.com Mon Apr 22 18:34:45 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 11:34:35 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737127CE19002266BC0F664ED122=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1785716507197590111==" --===============1785716507197590111== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/22/24 11:09, Bill Gunshannon via cctalk wrote: > > Following along this line of thought but also in regards all our > other small CPUs.... > > Would it not be possible to use something like a Blue Pill to make > a small board (small enough to actually fit in the CPU socket) that > emulated these old CPUs?  Definitely enough horse power just wondered > if there was enough room for the microcode. Blue pills are so yesterday! There are far more small-footprint MCUs out there. More RAM than any Z80 ever had as well as lots of flash for the code as well as pipelined 32-bit execution at eye-watering (relative to the Z80) speeds. Could it emulate a Z80? I don't see any insurmountable obstacles to that. Could it be cycle- and timing- accurate? That's a harder one to predict, but probably. But I'd wonder what the point was. There are still lots of Z80s out there in captivity. --Chuck --===============1785716507197590111==-- From lowen@pari.edu Mon Apr 22 18:41:58 2024 From: Lamar Owen To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 14:41:53 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737127CE19002266BC0F664ED122=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0281450760694644711==" --===============0281450760694644711== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 14:09, Bill Gunshannon via cctalk wrote: > Would it not be possible to use something like a Blue Pill to make > a small board (small enough to actually fit in the CPU socket) that > emulated these old CPUs?=C2=A0 Definitely enough horse power just wondered > if there was enough room for the microcode. Microcore Labs has done this using a Teensy plus a small adapter board;=20 see=20 https://microcorelabs.wordpress.com/2022/05/11/mclz8-zilog-z80-emulator-in-tr= s-80-model-iii/=20 (Github repo: https://github.com/MicroCoreLabs/Projects/tree/master/MCLZ8 ). There are others there as well. --===============0281450760694644711==-- From paulkoning@comcast.net Mon Apr 22 18:46:19 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 14:46:12 -0400 Message-ID: <7D814FDB-CBC2-4866-9B80-9B90D1D076C8@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2352921646240945210==" --===============2352921646240945210== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 2:34 PM, Chuck Guzis via cctalk wrote: >=20 > On 4/22/24 11:09, Bill Gunshannon via cctalk wrote: >=20 >>=20 >> Following along this line of thought but also in regards all our >> other small CPUs.... >>=20 >> Would it not be possible to use something like a Blue Pill to make >> a small board (small enough to actually fit in the CPU socket) that >> emulated these old CPUs? Definitely enough horse power just wondered >> if there was enough room for the microcode. >=20 > Blue pills are so yesterday! There are far more small-footprint MCUs > out there. More RAM than any Z80 ever had as well as lots of flash for > the code as well as pipelined 32-bit execution at eye-watering (relative > to the Z80) speeds. >=20 > Could it emulate a Z80? I don't see any insurmountable obstacles to > that. Could it be cycle- and timing- accurate? That's a harder one to > predict, but probably. Probably not. Cycle accurate simulation is very hard. It's only rarely been= done for any CPU, and if done it tends to be incredibly slow. I remember on= ce using a MIPS cycle-accurate simulator (for the SB-1, the core inside the S= B-1250, later called BCM-12500). It was needed because the L2 cache flush co= de could not be debugged any other way, but it was very slow indeed. Almost = as bad as running the CPU logic model in a Verilog or VHDL simulator. I don'= t remember the numbers but it probably was only a few thousand instructions p= er second. Then again, for the notion of a drop-in replacement for the original chip, yo= u don't need a cycle accurate simulator, just one with compatible pin signall= ing. That's not nearly so hard -- though still harder than a SIMH style ISA = simulation. paul --===============2352921646240945210==-- From cclist@sydex.com Mon Apr 22 19:02:57 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 12:02:42 -0700 Message-ID: <9091e379-0dbf-46fa-b722-5a60a8dbb728@sydex.com> In-Reply-To: <7D814FDB-CBC2-4866-9B80-9B90D1D076C8@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6979773090706717623==" --===============6979773090706717623== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 11:46, Paul Koning wrote: > > Probably not. Cycle accurate simulation is very hard. It's only rarely be= en done for any CPU, and if done it tends to be incredibly slow. I remember = once using a MIPS cycle-accurate simulator (for the SB-1, the core inside the= SB-1250, later called BCM-12500). It was needed because the L2 cache flush = code could not be debugged any other way, but it was very slow indeed. Almos= t as bad as running the CPU logic model in a Verilog or VHDL simulator. I do= n't remember the numbers but it probably was only a few thousand instructions= per second. Then again, the Z80 isn't a very sophisticated chip. No cache, pipelining, speculative execution, etc. A cheap 32 bit MCU, running at 400 MHz might be able to pull it off pretty well. But then again, there are FPGA cores for the Z80, etc. I'd like to see a Z80 implemented with UV-201 vacuum tubes... :) --Chuck --===============6979773090706717623==-- From bfranchuk@jetnet.ab.ca Mon Apr 22 19:31:25 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:31:11 -0600 Message-ID: <54b94ced-29ca-482a-a436-3a49c8c85cb5@jetnet.ab.ca> In-Reply-To: <6C317320-CE91-4E51-9B38-83EF091F7B9C@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0017411911493323792==" --===============0017411911493323792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >One other factor is that RISC machines rely on simple operations >carefully arranged by optimizing compilers (or, in some cases, >skillful programmers). A multi-step operation can be encoded in a >sequence of RISC operations run through an optimizing scheduler more >effectively than the equivalent sequence of steps inside the >micro-engine of a CISC processor. Lets call them LOAD/STORE architectures. Classic cpu designs like the PDP-1, might be better called RISC. Back then you matched the cpu word length to data you were using. 40 bits made a lot of sense for real computing, even if you had no RAM memory at the time, just drum. IBM set the standard for 8 bit bytes, 16, 32 bit words and 64 bit floating point. Things are complex because you need to pack things to fit the standard size boxes. Every thing is trade off. Why? Because the IBM 7030 Stretch (64 bits) was a flop. Save memory, CISC. Use memory, RISC. Simple memory, Microprocessors. Processor development, is always built around what memory you have around at the time, is my argument. How many Z80's can you think of USE core memory? I think only 1 8080A ever used core memory, from BYTE magazine. Improvements in memory often where improvements in logic as well for CPU design. If CPU's were designed for high level languages, why are there no stack based architectures around like for Pascal's P-code? (1970's yes, but not today) The Z80 may be gone, but the 8080 still can be emulated by bitslices. Did anyone ever use them? Ben. --===============0017411911493323792==-- From bfranchuk@jetnet.ab.ca Mon Apr 22 19:43:43 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:43:32 -0600 Message-ID: In-Reply-To: <9091e379-0dbf-46fa-b722-5a60a8dbb728@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0354584105884818560==" --===============0354584105884818560== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-04-22 1:02 p.m., Chuck Guzis via cctalk wrote: > I'd like to see a Z80 implemented with UV-201 vacuum tubes... :) > --Chuck Real computers use glow tubes like the NE-2 or the NE-77.:) --===============0354584105884818560==-- From cisin@xenosoft.com Mon Apr 22 19:52:28 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 12:52:22 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3277250907666598076==" --===============3277250907666598076== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > On 2024-04-22 1:02 p.m., Chuck Guzis via cctalk wrote: >> I'd like to see a Z80 implemented with UV-201 vacuum tubes... :) --Chuck On Mon, 22 Apr 2024, ben via cctalk wrote: > Real computers use glow tubes like the NE-2 or the NE-77.:) I thought that real computers use gears --===============3277250907666598076==-- From cclist@sydex.com Mon Apr 22 19:53:58 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 12:53:49 -0700 Message-ID: <93c015c9-5193-4839-b419-1b2c377be8a7@sydex.com> In-Reply-To: <54b94ced-29ca-482a-a436-3a49c8c85cb5@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4510660822077711455==" --===============4510660822077711455== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/22/24 12:31, ben via cctalk wrote: > > > Classic cpu designs like the PDP-1, might be better called RISC. > Back then you matched the cpu word length to data you were using. > 40 bits made a lot of sense for real computing, even if you > had no RAM memory at the time, just drum. I'd call the CDC 6600 a classic RISC design, at least as far as the CPU went. Classes were given to programming staff on timing code precisely; I spent many happy hours trying to squeeze the last few cycles out of a loop (where the biggest bang for the buck was possible). I think bitsavers (I haven't looked) has a document or two on how to time code for that thing. --Chuck --===============4510660822077711455==-- From paulkoning@comcast.net Mon Apr 22 19:57:26 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 15:57:19 -0400 Message-ID: <7A968926-3B59-4842-B432-0D2A991A8CF9@comcast.net> In-Reply-To: <0e6d8e74-1ee2-42a1-97d7-035482e597ab@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5526822386203810577==" --===============5526822386203810577== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 3:45 PM, Mike Katz wrote: >=20 > Cycle accurate emulation becomes impossible in the following circumstances: > =E2=80=A2 Branch prediction and pipelining can cause out of order executio= n and the execution path become data dependent. ... I disagree. Clearly a logic model will do cycle accurate simulation. So an = abstraction of that which still preserves the details of out of order executi= on, data dependency, etc., will also be cycle accurate. It certainly is true that modern high performance processors with all those c= omplexities are hard to simulate, but not impossible. paul --===============5526822386203810577==-- From wayne.sudol@hotmail.com Mon Apr 22 20:02:27 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 20:02:08 +0000 Message-ID: In-Reply-To: <93c015c9-5193-4839-b419-1b2c377be8a7@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3256907587542934165==" --===============3256907587542934165== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I read somewhere that the cable lengths were expressly engineered to provide = that signals arrived to chips at nearly the same time so as to reduce chip = =E2=80=9Cwait=E2=80=9D times and provide more speed.=20 So that begs a question. Older chips like the Z80 and 8080 lines required oth= er support chips that added latency to a system waiting for the support chips= to =E2=80=9Csettle=E2=80=9D. Does that imply that newer microprocessors tha= t have support on the chip are just generally faster because of that? Sent from my iPhone > On Apr 22, 2024, at 12:54, Chuck Guzis via cctalk = wrote: >=20 > =EF=BB=BFOn 4/22/24 12:31, ben via cctalk wrote: >>=20 >=20 >>=20 >> Classic cpu designs like the PDP-1, might be better called RISC. >> Back then you matched the cpu word length to data you were using. >> 40 bits made a lot of sense for real computing, even if you >> had no RAM memory at the time, just drum. >=20 > I'd call the CDC 6600 a classic RISC design, at least as far as the CPU > went. Classes were given to programming staff on timing code precisely; > I spent many happy hours trying to squeeze the last few cycles out of a > loop (where the biggest bang for the buck was possible). >=20 > I think bitsavers (I haven't looked) has a document or two on how to > time code for that thing. >=20 > --Chuck >=20 >=20 --===============3256907587542934165==-- From bitwiz@12bitsbest.com Mon Apr 22 20:03:33 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 14:45:50 -0500 Message-ID: <0e6d8e74-1ee2-42a1-97d7-035482e597ab@12bitsbest.com> In-Reply-To: <7D814FDB-CBC2-4866-9B80-9B90D1D076C8@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5115897945952843646==" --===============5115897945952843646== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cycle accurate emulation becomes impossible in the following circumstances: * Branch prediction and pipelining can cause out of order execution and the execution path become data dependent. * Cache memory.=C2=A0 It can be very difficult to predict a cache flush or cache miss or cache look aside buffer hit * Memory management can inject wait states and cause other cycle counting issues * Peripherals can inject unpredictable wait states * Multi-core processors because you don't necessarily know what core is doing what and possibly one core waiting on another core. * DMA can cause some CPUs to pause because the bus is busy doing DMA transfers (not all processors have this as an issue). * Some CPUs shut down clocks and peripherals if they are not used and they take time to re-start. * Any code that waits for some kind of external input. When I was working for a 6800 C compiler company we could simulate all=20 68000 CPUs before the 68020.=C2=A0 The 68020 with it's pipelining and branch = prediction made it impossible to do cycle accurate timing. On 4/22/2024 1:46 PM, Paul Koning via cctalk wrote: > >> On Apr 22, 2024, at 2:34 PM, Chuck Guzis via cctalk wrote: >> >> On 4/22/24 11:09, Bill Gunshannon via cctalk wrote: >> >>> Following along this line of thought but also in regards all our >>> other small CPUs.... >>> >>> Would it not be possible to use something like a Blue Pill to make >>> a small board (small enough to actually fit in the CPU socket) that >>> emulated these old CPUs? Definitely enough horse power just wondered >>> if there was enough room for the microcode. >> Blue pills are so yesterday! There are far more small-footprint MCUs >> out there. More RAM than any Z80 ever had as well as lots of flash for >> the code as well as pipelined 32-bit execution at eye-watering (relative >> to the Z80) speeds. >> >> Could it emulate a Z80? I don't see any insurmountable obstacles to >> that. Could it be cycle- and timing- accurate? That's a harder one to >> predict, but probably. > Probably not. Cycle accurate simulation is very hard. It's only rarely be= en done for any CPU, and if done it tends to be incredibly slow. I remember = once using a MIPS cycle-accurate simulator (for the SB-1, the core inside the= SB-1250, later called BCM-12500). It was needed because the L2 cache flush = code could not be debugged any other way, but it was very slow indeed. Almos= t as bad as running the CPU logic model in a Verilog or VHDL simulator. I do= n't remember the numbers but it probably was only a few thousand instructions= per second. > > Then again, for the notion of a drop-in replacement for the original chip, = you don't need a cycle accurate simulator, just one with compatible pin signa= lling. That's not nearly so hard -- though still harder than a SIMH style IS= A simulation. > > paul > > --===============5115897945952843646==-- From cisin@xenosoft.com Mon Apr 22 20:13:05 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:12:57 -0700 Message-ID: In-Reply-To: <0e6d8e74-1ee2-42a1-97d7-035482e597ab@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6095519053043944323==" --===============6095519053043944323== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 22 Apr 2024, Mike Katz via cctalk wrote: > Cycle accurate emulation becomes impossible in the following circumstances: > * Branch prediction and pipelining can cause out of order execution > and the execution path become data dependent. > * Cache memory.=C2=A0 It can be very difficult to predict a cache flush or > cache miss or cache look aside buffer hit > * Memory management can inject wait states and cause other cycle > counting issues > * Peripherals can inject unpredictable wait states > * Multi-core processors because you don't necessarily know what core > is doing what and possibly one core waiting on another core. > * DMA can cause some CPUs to pause because the bus is busy doing DMA > transfers (not all processors have this as an issue). > * Some CPUs shut down clocks and peripherals if they are not used and > they take time to re-start. > * Any code that waits for some kind of external input. Ridiculously impractical, but not impossible. All of those things could be calculated, and worked around. Admittedly, we might not have a machine fast enough to do so. Whereas, emulation that doesn't need to do those can be done with systems=20 not extremely faster than the one being emulated. > When I was working for a 6800 C compiler company we could simulate all 6800= 0=20 > CPUs before the 68020.=C2=A0 The 68020 with it's pipelining and branch pred= iction=20 > made it impossible to do cycle accurate timing. Again, not impossible, but very likely not feasable. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============6095519053043944323==-- From cclist@sydex.com Mon Apr 22 20:21:33 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:21:22 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB218560BE21413B9FC3B47145E4122=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9151720262210282376==" --===============9151720262210282376== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 13:02, Wayne S wrote: > I read somewhere that the cable lengths were expressly engineered to provid= e that signals arrived to chips at nearly the same time so as to reduce chip = =E2=80=9Cwait=E2=80=9D times and provide more speed.=20 That certainly was true for the 6600. My unit manager, fresh out of UofMinn had his first job with CDC, measuring wire loops on the first 6600 to which Seymour had attached tags that said "tune". But then, take a gander at a modern notherboard and the lengths (sic) to which the designers have routed the traces so that timing works. --Chuck --===============9151720262210282376==-- From bitwiz@12bitsbest.com Mon Apr 22 20:21:57 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 15:21:47 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB218560BE21413B9FC3B47145E4122=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8975733626283604077==" --===============8975733626283604077== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Once CPUs became faster than memory the faster the memory the faster the=20 CPU could run. That is where CACHE came in.=C2=A0 Expensive small high speed ram chips would= =20 be able to feed the CPU faster except in case of a cache miss and then=20 the cache had to reload from slow memory.=C2=A0 That is why multiple cache=20 buffers were implemented so one could be filling (predicatively) while=20 another buffer was being used. Some early CPU's were run slowly enough so that the memory could keep up=20 and some had built in hardware handshaking.=C2=A0 For example the 68000 had a= =20 signal called DTACK which was used by the memory/peripheral to say that=20 it had latched the data on the bus (on writes) or that the data is=20 stable on the bus (on reads). Or used quadrature clocks (like the 6809 [the 6809E ran a 2 phase=20 non-quadrature clock]) that gave memory more than one cycle time to respond. On 4/22/2024 3:02 PM, Wayne S via cctalk wrote: > I read somewhere that the cable lengths were expressly engineered to provid= e that signals arrived to chips at nearly the same time so as to reduce chip = =E2=80=9Cwait=E2=80=9D times and provide more speed. > > So that begs a question. Older chips like the Z80 and 8080 lines required o= ther support chips that added latency to a system waiting for the support chi= ps to =E2=80=9Csettle=E2=80=9D. Does that imply that newer microprocessors t= hat have support on the chip are just generally faster because of that? > > > Sent from my iPhone > >> On Apr 22, 2024, at 12:54, Chuck Guzis via cctalk wrote: >> >> =EF=BB=BFOn 4/22/24 12:31, ben via cctalk wrote: >>> Classic cpu designs like the PDP-1, might be better called RISC. >>> Back then you matched the cpu word length to data you were using. >>> 40 bits made a lot of sense for real computing, even if you >>> had no RAM memory at the time, just drum. >> I'd call the CDC 6600 a classic RISC design, at least as far as the CPU >> went. Classes were given to programming staff on timing code precisely; >> I spent many happy hours trying to squeeze the last few cycles out of a >> loop (where the biggest bang for the buck was possible). >> >> I think bitsavers (I haven't looked) has a document or two on how to >> time code for that thing. >> >> --Chuck >> >> --===============8975733626283604077==-- From bitwiz@12bitsbest.com Mon Apr 22 20:25:07 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 15:24:56 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0861257658247276874==" --===============0861257658247276874== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > Again, not impossible, but very likely not feasable. Well not possible with the hardware available at the time. If one cycle per minute or less is acceptable then I guess it was possible. That is why we used in circuit emulators to do cycle accurate counting on more complex machines.  This machines were clunky and unreliable but they worked for the most part. On 4/22/2024 3:12 PM, Fred Cisin via cctalk wrote: > On Mon, 22 Apr 2024, Mike Katz via cctalk wrote: >> Cycle accurate emulation becomes impossible in the following >> circumstances: >> * Branch prediction and pipelining can cause out of order execution >>   and the execution path become data dependent. >> * Cache memory.  It can be very difficult to predict a cache flush or >>   cache miss or cache look aside buffer hit >> * Memory management can inject wait states and cause other cycle >>   counting issues >> * Peripherals can inject unpredictable wait states >> * Multi-core processors because you don't necessarily know what core >>   is doing what and possibly one core waiting on another core. >> * DMA can cause some CPUs to pause because the bus is busy doing DMA >>   transfers (not all processors have this as an issue). >> * Some CPUs shut down clocks and peripherals if they are not used and >>   they take time to re-start. >> * Any code that waits for some kind of external input. > > Ridiculously impractical, but not impossible. > All of those things could be calculated, and worked around. > Admittedly, we might not have a machine fast enough to do so. > Whereas, emulation that doesn't need to do those can be done with > systems not extremely faster than the one being emulated. > >> When I was working for a 6800 C compiler company we could simulate >> all 68000 CPUs before the 68020.  The 68020 with it's pipelining and >> branch prediction made it impossible to do cycle accurate timing. > > Again, not impossible, but very likely not feasable. > > -- > Grumpy Ol' Fred             cisin(a)xenosoft.com --===============0861257658247276874==-- From chris@mainecoon.com Mon Apr 22 20:29:06 2024 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:28:59 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2510280532438284772==" --===============2510280532438284772== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/22/24 13:12, Fred Cisin via cctalk wrote: > On Mon, 22 Apr 2024, Mike Katz via cctalk wrote: [Big snip -- hopefully I managed to get attribution right, apologies in advance if I borked it] > >> When I was working for a 6800 C compiler company we could simulate >> all 68000 CPUs before the 68020.  The 68020 with it's pipelining and >> branch prediction made it impossible to do cycle accurate timing. > > Again, not impossible, but very likely not feasable. Having done cycle accurate simulation of a pipelined superscalar processor, I can assure you it's possible, particularly with hardware assist a la Quickturn . It's also a lot like watching paint dry. -- 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…" --===============2510280532438284772==-- From cisin@xenosoft.com Mon Apr 22 20:36:17 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:36:11 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5267504135231939357==" --===============5267504135231939357== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> Again, not impossible, but very likely not feasable. On Mon, 22 Apr 2024, Mike Katz wrote: > Well not possible with the hardware available at the time. Some stuff is getting faster, . . . Can you estimate how much faster it would need to be? (perhaps then, log(2) of that, times 18 months? :-) 'course, with Moore no longer around, who's gonna enforce his law? :-) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5267504135231939357==-- From paulkoning@comcast.net Mon Apr 22 20:42:25 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:42:18 -0400 Message-ID: <9BD054B3-9C74-4ECE-87FC-DF5D31646351@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6244459934774025007==" --===============6244459934774025007== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 4:21 PM, Chuck Guzis via cctalk wrote: >=20 > On 4/22/24 13:02, Wayne S wrote: >> I read somewhere that the cable lengths were expressly engineered to provi= de that signals arrived to chips at nearly the same time so as to reduce chip= =E2=80=9Cwait=E2=80=9D times and provide more speed.=20 >=20 > That certainly was true for the 6600. My unit manager, fresh out of > UofMinn had his first job with CDC, measuring wire loops on the first > 6600 to which Seymour had attached tags that said "tune". Not so much "to arrive at the same time" but rather "to arrive at the correct= time". And not so much to reduce chip wait times, because for the most part= that machine doesn't wait for things. Instead, it relies on predictable tim= ing, so that an action set in motion is known to deliver its result at a spec= ific later time, and when that signal arrives there will be some element acce= pting it right then. A nice example is the exchange jump instruction processing, which fires off a= bunch of memory read/restore operations and sends off current register value= s across the various memory buses. The memory read completes and sends off t= he result, then 100 ns or so later the register value shows up and is inserte= d into the write data path of the memory to complete the core memory full cyc= le. (So it isn't a read/restore actually, but raher a "read/replace".) Another example is the PPU "barrel" which books like Thornton's show as a pas= sive thing except at the "slot" where the arithmetic lives. In reality, abou= t 6 positions before the slot the current memory address (PC or current opera= nd) is handed off to the memory so that just before that PP rotates to the sl= ot the read data will be available to it. And then the output of the slot be= comes the restore, or update, data for the write part of the memory full cycl= e. > But then, take a gander at a modern notherboard and the lengths (sic) to > which the designers have routed the traces so that timing works. Indeed, and with multi-Gb/s interfaces this stuff really matters. Enough so = that high end processors document the wire lengths inside the package, so tha= t "match interconnect lengths" doesn't mean "match etch lengths" but rather "= match etch plus in-package lengths". The mind boggles at the high end.... FPGAs with dozens of interfaces running = at data rates up to 58 Gb/s. paul --===============6244459934774025007==-- From paulkoning@comcast.net Mon Apr 22 20:45:59 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:45:50 -0400 Message-ID: <149CA92D-6E6F-4D8B-93DC-100929714261@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2505176868919541667==" --===============2505176868919541667== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 4:24 PM, Mike Katz via cctalk = wrote: >=20 >> Again, not impossible, but very likely not feasable.=20 >=20 > Well not possible with the hardware available at the time. >=20 > If one cycle per minute or less is acceptable then I guess it was possible. >=20 > That is why we used in circuit emulators to do cycle accurate counting on m= ore complex machines. This machines were clunky and unreliable but they work= ed for the most part. Well, the SB-1 is a multi-core pipelined machine with multiple caches and all= sorts of other complications. And the company certainly had a cycle accurat= e simulator. They were reluctant to let it out to customers, but we leaned h= ard enough. It was slow, indeed. Certainly not a cycle per minute; I'm pret= ty sure it was a whole lot more than a cycle per second. Given that the code= I was debugging was only a few hundred instructions long, it was quite accep= table. Speaking of slow emulation: a CDC 6600 gate level model, in VHDL, is indeed s= low. Now we're indeed talking about a cycle per second. I'm thinking I coul= d translate the VHDL to C and have it go faster (by omitting irrelevant detai= l that VHDL carees about but the simulation doesn't). paul --===============2505176868919541667==-- From paulkoning@comcast.net Mon Apr 22 20:47:58 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:47:51 -0400 Message-ID: <0BC97EDD-C6C2-4CBC-BA80-6A58F663CB90@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8263667043733536956==" --===============8263667043733536956== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 4:21 PM, Mike Katz via cctalk = wrote: >=20 > Once CPUs became faster than memory the faster the memory the faster the CP= U could run. >=20 > That is where CACHE came in. Expensive small high speed ram chips would be= able to feed the CPU faster except in case of a cache miss and then the cach= e had to reload from slow memory. That is why multiple cache buffers were im= plemented so one could be filling (predicatively) while another buffer was be= ing used. An early cache, though not called that, is the track buffer in the ARMAC, a 1= 955 or so research computer built at CWI (then called MC) in Amsterdam. Its = main memory was a drum, like its predecessors, but it would keep the most rec= ently accessed track in memory (core?) for fast access. That was handled in = hardware if I remember right, so it's exactly like a one-entry cache with a l= ine size of whatever the track length is (32 words?). paul --===============8263667043733536956==-- From ethan.dicks@gmail.com Mon Apr 22 20:52:53 2024 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:52:37 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8208650616953312150==" --===============8208650616953312150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 22, 2024 at 2:30=E2=80=AFPM Paul Koning via cctalk wrote: > Anyway, I would think such a small microprocessor could emulate a PDP-11 ju= st fine, and probably fast enough. The issue isn't so much the instruction s= et emulation but rather the electrical interface. That's what would be neede= d to be a drop-in replacement. Ignoring the voltage levels, there's the matt= er of implementing whatever the bus protocols are. Emulating an F-11 chip or a J-11 chip is certainly possible with a modern MCU, just need TTL-friendly I/O. F-11 is 40-pins (and can have additional instructions added by adding microcode ROMs next to the CPU) and the J-11 is 64 pins on a fat chip carrier. > Possibly an RP2040 (the engine in the Raspberry Pico) would serve for this,= with the PIO engines providing help with the low level signaling. Sounds li= ke a fun exercise for the student. Could be a good start but would still need level shifters. J-11 runs at 15-18Mhz for an idea on how fast the bus implementation has to b= e. -ethan --===============8208650616953312150==-- From paulkoning@comcast.net Mon Apr 22 20:54:07 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:53:58 -0400 Message-ID: In-Reply-To: <54b94ced-29ca-482a-a436-3a49c8c85cb5@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1677216270805978751==" --===============1677216270805978751== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 3:31 PM, ben via cctalk wrote: >=20 >=20 > >One other factor is that RISC machines rely on simple operations >carefull= y arranged by optimizing compilers (or, in some cases, >skillful programmers)= . A multi-step operation can be encoded in a >sequence of RISC operations ru= n through an optimizing scheduler more >effectively than the equivalent seque= nce of steps inside the > >micro-engine of a CISC processor. >=20 > Lets call them LOAD/STORE architectures. >=20 > Classic cpu designs like the PDP-1, might be better called RISC. Um, no. Load-store machines like the PDP-1, or many other machines of that e= ra, have instructions where typically one operand is a register and the other= is a memory location. That means arithmetic operations necessarily include = a memory reference, implying a memory wait. A key part of RISC is arithmetic on registers only, and enough registers so y= ou can schedule the loads and stores to run concurrently with other arithmeti= c operations. The CDC 6600 is the pioneering example. A very simple scenari= o would be a memory move loop, where you'd issue two loads to two different r= egisters, then two register-register move operations that use different funct= ional units, followed by two store operations from two different registers. = (The move operations because the 6600 would do loads to one set of registers = and stores from a different set.) Keeping two memory operations in flight co= ncurrently made quite a difference. In COMPASS: MORE SA1 A1+B2 (B2 =3D 2) SA2 A2+B2 BX6 X1 LX7 X2 SB3 B3-2 SA6 A6+B2 SA7 A7+B2 PL b3,MORE paul --===============1677216270805978751==-- From cclist@sydex.com Mon Apr 22 20:57:29 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:57:19 -0700 Message-ID: <6e546791-335b-4404-a854-61669dcae636@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3420759264269642058==" --===============3420759264269642058== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/22/24 13:53, Paul Koning via cctalk wrote: > In COMPASS: > > MORE SA1 A1+B2 (B2 = 2) > SA2 A2+B2 > BX6 X1 > LX7 X2 > SB3 B3-2 > SA6 A6+B2 > SA7 A7+B2 > PL b3,MORE --===============3420759264269642058==-- From cclist@sydex.com Mon Apr 22 20:59:24 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 13:59:12 -0700 Message-ID: <17d50bc5-0b60-469a-aab4-ca2b098d42dc@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1378245974099232577==" --===============1378245974099232577== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/22/24 13:53, Paul Koning via cctalk wrote: > In COMPASS: > > MORE SA1 A1+B2 (B2 = 2) > SA2 A2+B2 > BX6 X1 > LX7 X2 > SB3 B3-2 > SA6 A6+B2 > SA7 A7+B2 > PL b3,MORE My recollection is that putting the stores at the top of the loop and the loads at the bottom managed to save a few cycles. Of course, you have to prime the loop... --Chuck --===============1378245974099232577==-- From paulkoning@comcast.net Mon Apr 22 21:04:46 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 17:04:39 -0400 Message-ID: In-Reply-To: <17d50bc5-0b60-469a-aab4-ca2b098d42dc@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3505464051793984286==" --===============3505464051793984286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 4:59 PM, Chuck Guzis via cctalk wrote: >=20 > On 4/22/24 13:53, Paul Koning via cctalk wrote: >> In COMPASS: >>=20 >> MORE SA1 A1+B2 (B2 =3D 2) >> SA2 A2+B2 >> BX6 X1 >> LX7 X2 >> SB3 B3-2 >> SA6 A6+B2 >> SA7 A7+B2 >> PL b3,MORE >=20 > My recollection is that putting the stores at the top of the loop and > the loads at the bottom managed to save a few cycles. Of course, you > have to prime the loop... >=20 > --Chuck Might well be, I don't remember. Or moving the SB3 (the loop counter) to be = right after the loads is probably helpful. The full answer depends on unders= tanding the timing, both of the instructions and of the memory references tha= t are set in motion by them.=20 I never had my hands on a 6600, only a 6400 which is a single unit machine. = So I had to do some thinking to understand why someone would do a register tr= ansfer with L (shift operation) rather than B (boolean operation) when I firs= t saw that in my code reading. The answer is that both instructions take 300= ns, but they are in different functional units on the 6600 so they can start= 100 ns apart. paul --===============3505464051793984286==-- From phb.hfx@gmail.com Mon Apr 22 21:06:42 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 18:06:34 -0300 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4707583413808782633==" --===============4707583413808782633== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-22 5:21 p.m., Chuck Guzis via cctalk wrote: > On 4/22/24 13:02, Wayne S wrote: >> I read somewhere that the cable lengths were expressly engineered to provi= de that signals arrived to chips at nearly the same time so as to reduce chip= =E2=80=9Cwait=E2=80=9D times and provide more speed. > That certainly was true for the 6600. My unit manager, fresh out of > UofMinn had his first job with CDC, measuring wire loops on the first > 6600 to which Seymour had attached tags that said "tune". > > But then, take a gander at a modern notherboard and the lengths (sic) to > which the designers have routed the traces so that timing works. > > --Chuck > > Shortly after I started at IBM I assisted one of the senior CEs doing=20 engineering changes on a 3031 and the back of the logic gates was a mass=20 of what IBM called tri-lead, when I saw it I wonder how it could=20 possibly work.=C2=A0 The tri-lead is basically a 3 wire ribbon cable that has= =20 the two outer wires grounded and is precisely made to have reliable=20 characteristics.=C2=A0 It was explained to me that sometimes they would=20 change the length of the tri-lead in a connection to adjust signal timing. I am not sure when IBM started using tri-lead but I also recall seeing a=20 168 that had some third party memory that was in a box hung on the end=20 of a frame and had a large bundle of tri-lead coming out of it that=20 disappeared under the covers.=C2=A0 The site CE told me that those tri-leads = where all plugged into specific locations on the back of the boards on=20 one of the card gates, and if they had a problem with memory, they would=20 call in the techs that looked after the third party memory and have them=20 disconnect it all. =C2=A0 The last system I saw with tri-lead was a 3081 most= =20 of the logic was in TCMs but the memory was on a separate card gate and=20 connected to teh main CPU board with tri-lead. Paul. --===============4707583413808782633==-- From bitwiz@12bitsbest.com Mon Apr 22 21:13:43 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:13:35 -0500 Message-ID: In-Reply-To: <17d50bc5-0b60-469a-aab4-ca2b098d42dc@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9112254423749326438==" --===============9112254423749326438== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Compilers do that with what is called loop rotation optimization. On 4/22/2024 3:59 PM, Chuck Guzis via cctalk wrote: > On 4/22/24 13:53, Paul Koning via cctalk wrote: >> In COMPASS: >> >> MORE SA1 A1+B2 (B2 = 2) >> SA2 A2+B2 >> BX6 X1 >> LX7 X2 >> SB3 B3-2 >> SA6 A6+B2 >> SA7 A7+B2 >> PL b3,MORE > My recollection is that putting the stores at the top of the loop and > the loads at the bottom managed to save a few cycles. Of course, you > have to prime the loop... > > --Chuck > --===============9112254423749326438==-- From bitwiz@12bitsbest.com Mon Apr 22 21:15:24 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 15:08:33 -0500 Message-ID: In-Reply-To: <7A968926-3B59-4842-B432-0D2A991A8CF9@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1821483435422282141==" --===============1821483435422282141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable True, if 1 cycle per second or minute is an acceptable emulation speed=F0=9F= =99=82. For that kind of emulation to work the emulator needs to be fed the same=20 tasks in the same order and for the same core.=C2=A0 This is even more true=20 when the CPU is waiting on internal or external resources.=C2=A0 If you can=20 emulate all of the cores, all 3 (or more) levels of cache, all possible=20 branch prediction, all possible out of order execution and all possible=20 external influences then yes you can emulation anything.=C2=A0 But that would= =20 be like using one of today's petaflop hyper computers to emulate an ARM=20 9 running at the speed of a Z-80 or even slower. On 4/22/2024 2:57 PM, Paul Koning wrote: > >> On Apr 22, 2024, at 3:45 PM, Mike Katz wrote: >> >> Cycle accurate emulation becomes impossible in the following circumstances: >> =E2=80=A2 Branch prediction and pipelining can cause out of order executi= on and the execution path become data dependent. ... > I disagree. Clearly a logic model will do cycle accurate simulation. So a= n abstraction of that which still preserves the details of out of order execu= tion, data dependency, etc., will also be cycle accurate. > > It certainly is true that modern high performance processors with all those= complexities are hard to simulate, but not impossible. > > paul > > --===============1821483435422282141==-- From paulkoning@comcast.net Mon Apr 22 21:17:15 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 17:17:08 -0400 Message-ID: <075A81AC-9B25-40BB-8D47-B0E6866CF678@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0447017534231222666==" --===============0447017534231222666== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable They sure do now, but not back in 1964. :-) paul > On Apr 22, 2024, at 5:13 PM, Mike Katz via cctalk = wrote: >=20 > Compilers do that with what is called loop rotation optimization. >=20 > On 4/22/2024 3:59 PM, Chuck Guzis via cctalk wrote: >> On 4/22/24 13:53, Paul Koning via cctalk wrote: >>> In COMPASS: >>>=20 >>> MORE SA1 A1+B2 (B2 =3D 2) >>> SA2 A2+B2 >>> BX6 X1 >>> LX7 X2 >>> SB3 B3-2 >>> SA6 A6+B2 >>> SA7 A7+B2 >>> PL b3,MORE >> My recollection is that putting the stores at the top of the loop and >> the loads at the bottom managed to save a few cycles. Of course, you >> have to prime the loop... >>=20 >> --Chuck >>=20 >=20 --===============0447017534231222666==-- From cclist@sydex.com Mon Apr 22 21:24:37 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 14:24:28 -0700 Message-ID: <0c4d5f49-34f5-4f0f-9c38-ab668085666e@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1166590827118689628==" --===============1166590827118689628== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 14:04, Paul Koning wrote: > I never had my hands on a 6600, only a 6400 which is a single unit machine.= So I had to do some thinking to understand why someone would do a register = transfer with L (shift operation) rather than B (boolean operation) when I fi= rst saw that in my code reading. The answer is that both instructions take 3= 00 ns, but they are in different functional units on the 6600 so they can sta= rt 100 ns apart. Jack Neuhaus taught the timing course at SVLOPS, at least to the SSD crowd. It got to be fun after awhile. We tried to do the same for the STAR, but the timing was pretty complex and not a good subject for pencil-and-paper work. There, the biggest performance gains there came from vectorization. Of course, if you had ECS, large block memory moves were easy. Lower CYBER (e.g. 73) with CMU might have also benefited from its use; I don't recall if it was used for storage move early on. I do recall that the standard test for CMU presence packing a jump in the lower 30 bits of a ginned-up CMU instruction word was broken by the Cyber 170. --Chuck --===============1166590827118689628==-- From dkelvey@hotmail.com Mon Apr 22 21:34:58 2024 From: dwight To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 21:34:50 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6521620155189830678==" --===============6521620155189830678== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable ________________________________ From: ben via cctalk Sent: Monday, April 22, 2024 12:43 PM To: cctalk(a)classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. On 2024-04-22 1:02 p.m., Chuck Guzis via cctalk wrote: > I'd like to see a Z80 implemented with UV-201 vacuum tubes... :) > --Chuck Real computers use glow tubes like the NE-2 or the NE-77.:) For those that don't know what a UV(UX)201 was, it was most commonly used for= audio amplification in early battery powered radios. These used a lot of fil= ament current, not like later miniature tubes. They had a UV(UX)200 tube for RF detections that worked better as a grid leak= detector, I think because of less cutoff voltage needed as a detector. The A series used a better getter and lower current filament ( one or both? )= but still used a lot of filament current. Dwight --===============6521620155189830678==-- From bitwiz@12bitsbest.com Mon Apr 22 22:37:09 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 15:50:48 -0500 Message-ID: <3886dc7d-e38c-4928-ad4f-e7e7206f0657@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7582495666244662233==" --===============7582495666244662233== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Well, it was beyond the PC's and Sparc stations we had access to at the time. On 4/22/2024 3:28 PM, Christian Kennedy via cctalk wrote: > > On 4/22/24 13:12, Fred Cisin via cctalk wrote: >> On Mon, 22 Apr 2024, Mike Katz via cctalk wrote: > [Big snip -- hopefully I managed to get attribution right, apologies > in advance if I borked it] >> >>> When I was working for a 6800 C compiler company we could simulate >>> all 68000 CPUs before the 68020. The 68020 with it's pipelining and >>> branch prediction made it impossible to do cycle accurate timing. >> >> Again, not impossible, but very likely not feasable. > > Having done cycle accurate simulation of a pipelined superscalar > processor, I can assure you it's possible, particularly with hardware > assist a la Quickturn . > > It's also a lot like watching paint dry. > --===============7582495666244662233==-- From cclist@sydex.com Mon Apr 22 23:03:14 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 16:03:03 -0700 Message-ID: <1e404f02-6ed4-4410-8653-99536ab592fc@sydex.com> In-Reply-To: =?utf-8?q?=3CSA1PR11MB69414A97CE902B4D0CA43A90A3122=40SA1PR11MB?= =?utf-8?q?6941=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5577478095627283261==" --===============5577478095627283261== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 14:34, dwight via cctalk wrote: > For those that don't know what a UV(UX)201 was, it was most commonly used f= or audio amplification in early battery powered radios. These used a lot of f= ilament current, not like later miniature tubes. > They had a UV(UX)200 tube for RF detections that worked better as a grid le= ak detector, I think because of less cutoff voltage needed as a detector. > The A series used a better getter and lower current filament ( one or both?= ) but still used a lot of filament current. I've long considered it to be an interesting coincidence that the filament voltage of the UV201 was 5V, just like much later TTL logic. Folks don't recall that RCA was formed to get around a patent issue on the basic idea of a triode. --Chuck --===============5577478095627283261==-- From elson@pico-systems.com Mon Apr 22 23:08:05 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 18:07:58 -0500 Message-ID: <321d5ec7-498a-5b17-a426-081bdcaa873e@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2788122339859562525==" --===============2788122339859562525== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/22/24 16:06, Paul Berger via cctalk wrote: > > On 2024-04-22 5:21 p.m., Chuck Guzis via cctalk wrote: >> On 4/22/24 13:02, Wayne S wrote: >>> I read somewhere that the cable lengths were expressly >>> engineered to provide that signals arrived to chips at >>> nearly the same time so as to reduce chip “wait” times >>> and provide more speed. >> That certainly was true for the 6600.  My unit manager, >> fresh out of >> UofMinn had his first job with CDC, measuring wire loops >> on the first >> 6600 to which Seymour had attached tags that said "tune". >> >> But then, take a gander at a modern notherboard and the >> lengths (sic) to >> which the designers have routed the traces so that timing >> works. >> >> --Chuck >> >> > Shortly after I started at IBM I assisted one of the > senior CEs doing engineering changes on a 3031 and the > back of the logic gates was a mass of what IBM called > tri-lead, when I saw it I wonder how it could possibly > work.  The tri-lead is basically a 3 wire ribbon cable > that has the two outer wires grounded and is precisely > made to have reliable characteristics.  It was explained > to me that sometimes they would change the length of the > tri-lead in a connection to adjust signal timing. > > I am not sure when IBM started using tri-lead IBM 360's used Chabin TLC (transmission line cable) that were essentially a ribbon cable version of tri-lead.  18 signals wide, terminating in the standard 24-pin connectors just like the SLT cards had.  I think that the Tri-lead and TLC both had a 91 Ohm impedance.  The reason for splitting the ribbons into individual signals was to reduce crosstalk.  Interesting note, 370's version of ECL used a +1.25 V and -3V power supply that shifted the logic levels to +400 mV and -400 mV, and were terminated to ground.  If you wanted to scope a signal, you could unplug a tri-lead and connect it to a scope with a 91 Ohm terminator. Jon --===============2788122339859562525==-- From bill.gunshannon@hotmail.com Tue Apr 23 00:14:21 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 20:14:09 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2480793197085544573==" --===============2480793197085544573== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/2024 2:30 PM, Paul Koning wrote: >=20 >=20 >> On Apr 22, 2024, at 2:09 PM, Bill Gunshannon via cctalk wrote: >> >> >> >> Following along this line of thought but also in regards all our >> other small CPUs.... >> >> Would it not be possible to use something like a Blue Pill to make >> a small board (small enough to actually fit in the CPU socket) that >> emulated these old CPUs? Definitely enough horse power just wondered >> if there was enough room for the microcode. >=20 > Microcode? Well, that's what I would have called it. :-) >=20 >> It would bring an even more interesting concept to the table. The >> ability to add modifications to some of these chips to see just where >> they might have gone. While I don't mind the VAX, I always wondered >> what the PDP-11 could have been if it had been developed instead. :-) >> >> bill >=20 > Of course the VAX started out as a modified PDP-11; the name makes that cle= ar. And I saw an early document of what became the VAX 11/780, labeled PDP-1= 1/85. Perhaps that was obfuscation. I have never seen anything but the vaguest similarity to the PDP-11 in the VAX. I know it was called a VAX-11 early on but I never understood why. >=20 > Anyway, I would think such a small microprocessor could emulate a PDP-11 ju= st fine, and probably fast enough. The issue isn't so much the instruction s= et emulation but rather the electrical interface. That's what would be neede= d to be a drop-in replacement. Ignoring the voltage levels, there's the matt= er of implementing whatever the bus protocols are. >=20 > Possibly an RP2040 (the engine in the Raspberry Pico) would serve for this,= with the PIO engines providing help with the low level signaling. Sounds li= ke a fun exercise for the student. I wasn't thinking just the PDP-11. I was thinking about the ability to replace failing CPU's of other flavors once production come to an end. I suspect that is far enough in the future that I won't have to worry about it, but it sounded like an interesting project. bill --===============2480793197085544573==-- From paulkoning@comcast.net Tue Apr 23 00:36:05 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 20:35:54 -0400 Message-ID: In-Reply-To: <1e404f02-6ed4-4410-8653-99536ab592fc@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0455531540640770900==" --===============0455531540640770900== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 7:03 PM, Chuck Guzis via cctalk wrote: >=20 > On 4/22/24 14:34, dwight via cctalk wrote: >=20 >> For those that don't know what a UV(UX)201 was, it was most commonly used = for audio amplification in early battery powered radios. These used a lot of = filament current, not like later miniature tubes. >> They had a UV(UX)200 tube for RF detections that worked better as a grid l= eak detector, I think because of less cutoff voltage needed as a detector. >> The A series used a better getter and lower current filament ( one or both= ? ) but still used a lot of filament current. >=20 > I've long considered it to be an interesting coincidence that the > filament voltage of the UV201 was 5V, just like much later TTL logic. What about the coincidence that a lot of today's logic runs on 3.3 volts, jus= t about the same as the first generation of IC logic (RTL). > Folks don't recall that RCA was formed to get around a patent issue on > the basic idea of a triode. Interesting! paul --===============0455531540640770900==-- From paulkoning@comcast.net Tue Apr 23 00:39:34 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 20:39:26 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737C4CD35029AAA9D8EEABFED112=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3663788159678130627==" --===============3663788159678130627== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 22, 2024, at 8:14 PM, Bill Gunshannon wrote: >=20 > On 4/22/2024 2:30 PM, Paul Koning wrote: >>> ... >> Of course the VAX started out as a modified PDP-11; the name makes that cl= ear. And I saw an early document of what became the VAX 11/780, labeled PDP-= 11/85. Perhaps that was obfuscation. >=20 > I have never seen anything but the vaguest similarity to the PDP-11 in > the VAX. I know it was called a VAX-11 early on but I never understood > why. Hm. I thought it was pretty obvious. The addressing modes are similar but a= superset, it has similar registers, just twice as many and twice as big. Th= e instructions are similar but extended. And the notation used to describe t= he instruction set was used earlier on the PDP-11. For me as a PDP-11 assemb= ly language programmer the kinship was obvious and the naming made perfect se= nse. >> Anyway, I would think such a small microprocessor could emulate a PDP-11 j= ust fine, and probably fast enough. The issue isn't so much the instruction = set emulation but rather the electrical interface. That's what would be need= ed to be a drop-in replacement. Ignoring the voltage levels, there's the mat= ter of implementing whatever the bus protocols are. >> Possibly an RP2040 (the engine in the Raspberry Pico) would serve for this= , with the PIO engines providing help with the low level signaling. Sounds l= ike a fun exercise for the student. >=20 > I wasn't thinking just the PDP-11. I was thinking about the ability > to replace failing CPU's of other flavors once production come to an > end. I suspect that is far enough in the future that I won't have to > worry about it, but it sounded like an interesting project. >=20 > bill It certainly would be. And if you needed to replace a failed F-11 or single = chip PDP-8, it might be useful now. paul --===============3663788159678130627==-- From cclist@sydex.com Tue Apr 23 00:58:22 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 17:58:11 -0700 Message-ID: <370ceb42-834f-4fd7-ac59-e0d6f49620ea@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4669558424197152177==" --===============4669558424197152177== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 17:35, Paul Koning wrote: > What about the coincidence that a lot of today's logic runs on 3.3 volts, j= ust about the same as the first generation of IC logic (RTL). I think I still have some survivors from the Motorola HEP mwRTL kit. TO-100, I think. RTL was pretty cool--slow, even by standards then, but you could operate it in the linear region to make amplifiers and whatnot. --Chuck --===============4669558424197152177==-- From elson@pico-systems.com Tue Apr 23 01:56:00 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 20:55:52 -0500 Message-ID: <00dba10f-5f94-7b63-453f-5258d3cfc69f@pico-systems.com> In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737C4CD35029AAA9D8EEABFED112=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6726964869984474519==" --===============6726964869984474519== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/22/24 19:14, Bill Gunshannon via cctalk wrote: > > > On 4/22/2024 2:30 PM, Paul Koning wrote: >> >> >>> On Apr 22, 2024, at 2:09 PM, Bill Gunshannon via cctalk >>> wrote: >>> >>> >>> >>> Following along this line of thought but also in regards >>> all our >>> other small CPUs.... >>> >>> Would it not be possible to use something like a Blue >>> Pill to make >>> a small board (small enough to actually fit in the CPU >>> socket) that >>> emulated these old CPUs?  Definitely enough horse power >>> just wondered >>> if there was enough room for the microcode. >> >> Microcode? > > Well, that's what I would have called it.  :-) > >> >>> It would bring an even more interesting concept to the >>> table.  The >>> ability to add modifications to some of these chips to >>> see just where >>> they might have gone.  While I don't mind the VAX, I >>> always wondered >>> what the PDP-11 could have been if it had been developed >>> instead.  :-) >>> >>> bill >> >> Of course the VAX started out as a modified PDP-11; the >> name makes that clear.  And I saw an early document of >> what became the VAX 11/780, labeled PDP-11/85.  Perhaps >> that was obfuscation. > > I have never seen anything but the vaguest similarity to > the PDP-11 in > the VAX.  I know it was called a VAX-11 early on but I > never understood > why. > Umm, the VAX was a very obvious extension of the PDP-11 instruction layout to 32 bits.  The PDP-11 had a 3 bit register address and 3 bit addressing mode.  On the VAX these were each extended to 4 bits.  On the 11, the opcode field was 4 bits, although more bits were available on unary instructions.  On the VAX, the opcode could be either 8 or 16 bits. Quoting from the VAX11/780 Hardware Handbook Preface "VAX-11/780 is DIGITAL's 32 bit extension to its 11 family of minicomputers." This is the first sentence in the book. As somebody who programmed PDP-11s and VAXes in assembly language (Macro 11 and VAX Macro) I found the similarities VERY strong. Just that the 32-bit architecture took the constraints of the 16-bit PDP-11 away. Jon --===============6726964869984474519==-- From chrise@pobox.com Tue Apr 23 03:45:30 2024 From: Chris Elmquist To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 22:36:06 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2841942352128151866==" --===============2841942352128151866== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, I did that on Sunday afternoons on the Star-100 with Lincoln and his son= PD when I was in 8th grade. I never became a manager though :-) Chris -- Chris Elmquist > On Apr 22, 2024, at 3:22=E2=80=AFPM, Chuck Guzis via cctalk wrote: >=20 > =EF=BB=BFOn 4/22/24 13:02, Wayne S wrote: >> I read somewhere that the cable lengths were expressly engineered to provi= de that signals arrived to chips at nearly the same time so as to reduce chip= =E2=80=9Cwait=E2=80=9D times and provide more speed. >=20 > That certainly was true for the 6600. My unit manager, fresh out of > UofMinn had his first job with CDC, measuring wire loops on the first > 6600 to which Seymour had attached tags that said "tune". >=20 > But then, take a gander at a modern notherboard and the lengths (sic) to > which the designers have routed the traces so that timing works. >=20 > --Chuck >=20 --===============2841942352128151866==-- From cclist@sydex.com Tue Apr 23 04:01:55 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 22 Apr 2024 20:55:07 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7445106888589118375==" --===============7445106888589118375== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/22/24 20:36, Chris Elmquist wrote: > Hey, I did that on Sunday afternoons on the Star-100 with Lincoln and his s= on PD when I was in 8th grade. I never became a manager though :-) >=20 > Chris Trying to remember, was the star the same as the 6000 as far as wiring? That is, twisted pair and taper-pin? Gad, that was what, 50 years ago? I remember hunkering between the SBUs at ADL with a pillow during the OPEC oil embargo, with my pillow from the Ramada and a book. It was the warmest place in town... This California boy wasn't used to Twin Cities winters... --Chuck --===============7445106888589118375==-- From abuse@cabal.org.uk Tue Apr 23 11:27:54 2024 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 13:27:45 +0200 Message-ID: In-Reply-To: <01T4ONTDB83U8WVYW0@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9059089928801011775==" --===============9059089928801011775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Apr 22, 2024 at 01:06:42AM +0100, Peter Coghlan via cctalk wrote: [...] > This was implemented by a humble 6502 running at (mostly) 2MHz, with one 8 > bit arithmetic register, two 8 bit index registers, one 8 bit stack > pointer, a 16 bit program counter and a few flag bits. > I would have expected that a computers featuring a Z80 with its larger > register set, 16 bit arithmetic operations, richer instruction set and > general bells and whistles would have been able to produce a much superior > implementation in terms of speed or features or both but I never came > across one. > Why is that? Did the Z80 take more cycles to implement it's more complex > instructions? Is this an early example of RISC vs CISC? Technically yes, but the implicit assumption in the question is wrong. The Z80 takes three or four memory cycles to perform a memory access versus the 6502 accessing memory on every cycle, but Z80 systems tend to be clocked 3-4 times faster so the memory bandwidth is pretty much the same. This shouldn't be too surprising: they were designed to use the same RAM chips. So the Z80 takes more cycles, but it was designed to use a faster clock and do simpler operations per clock as that saved die space. Clock speeds have *never* been a good way to compare CPUs. In the hands of an expert in their respective instruction sets, both architectures perform about as well as each other for a given memory bandwidth (which was and still remains the limiting factor on CPUs without caches). The 6502 could be said to "win" only in as much as the modern drop-in replacement is the 14Mhz 65C02S, whereas the Z80's is the Z804C00xx which tops out at 20MHz so is only equivalent to a ~5MHz 6502. For the same reason, a 14MHz 65C02S will leave a 68000 (maximum 16.67Mhz) in the dust, especially when working with byte-oriented data such as text where the wider bus doesn't help. The 68000 takes four cycles to perform a memory access, and inserts a couple of extra cycles of dead time for certain addressing modes which require extra work in the address-generation circuitry. Even back in the day, it was noted that the Sinclair's ZX Spectrum with its 3.5MHz Z80 could outperform their later QL with its 7.5MHz 68008. --===============9059089928801011775==-- From chrise@pobox.com Tue Apr 23 13:42:00 2024 From: Chris Elmquist To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 08:41:46 -0500 Message-ID: <20240423134146.GT5463@n0jcf.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7294093535394637945==" --===============7294093535394637945== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Monday (04/22/2024 at 08:55PM -0700), Chuck Guzis wrote: > On 4/22/24 20:36, Chris Elmquist wrote: > > Hey, I did that on Sunday afternoons on the Star-100 with Lincoln and his= son PD when I was in 8th grade. I never became a manager though :-) > >=20 > > Chris >=20 > Trying to remember, was the star the same as the 6000 as far as wiring? > That is, twisted pair and taper-pin? I seem to remember (poorly) that it was very small diameter coax but I don't remember the termination method. I remember more about the Tek oscilloscope on a cart that we used than what we were actually doing. I don't recall that we actually cut and terminated any cables. We were just measuring the skew and writing it down and then I think a "professional" was going to come around later and actually adjust the line length. Entirely possible we were just doing busy work to stay out of trouble and not going to be part of the actual solution. But it was still educational. > Gad, that was what, 50 years ago? I remember hunkering between the SBUs > at ADL with a pillow during the OPEC oil embargo, with my pillow from > the Ramada and a book. It was the warmest place in town... Close. I think 48 yrs. I first met PD Lincoln in 1976 when I moved into the Mounds View School district. Then I discovered his dad was doing some pretty cool stuff at work... I think they were working on the CY203 then too but there was still a Star on the floor which is what we "played" with. For those playing along, this was the CDC Arden Hills Operations (ARHOPS) in St. Paul, MN. The CDC Advanced Design Lab (ADL) was here and it's where all the supercomputing hardware development took place after Seymour left CDC. So, they did the Star-100, CY203, and CY205 there and then in 1983 spun the entire ADL off into what became ETA Systems and we did the LN2 cooled ETA10 there. > This California boy wasn't used to Twin Cities winters... Understood. It's all I know except for recently experiencing summer in Albuquerque so we might be 180 degrees (so to speak) out of phase on that :-) Chris --=20 Chris Elmquist --===============7294093535394637945==-- From sqrfolkdnc@comcast.net Tue Apr 23 17:45:16 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Voyager 1 revived. [was: Z80 vs other microprocessors of the time. ] Date: Tue, 23 Apr 2024 12:45:09 -0500 Message-ID: <1001356174.1855528.1713894309859@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0452318456226084310==" --===============0452318456226084310== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry, I guess this should dead end, it is too far off track. I will still p= ost this since I was among those misled into thinking it had an 1802 micropro= cessor. The galileo had an 1802, but it suicided. from Wikipedia: It has been erroneously reported[41] on the Internet that the Voyager space p= robes were controlled by a version of the RCA 1802 (RCA CDP1802 "COSMAC" micr= oprocessor), but such claims are not supported by the primary design document= s. The CDP1802 microprocessor was used later in the Galileo space probe, whic= h was designed and built years later. The digital control electronics of the = Voyagers were not based on a microprocessor integrated-circuit chip. 
--Carey
--===============0452318456226084310==-- From van.snyder@sbcglobal.net Tue Apr 23 20:27:35 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Voyager 1 revived. [was: Z80 vs other microprocessors of the time. ] Date: Tue, 23 Apr 2024 13:27:26 -0700 Message-ID: <58f690ccd0c3a3cb7638b57a090b8f9a2ae962fb.camel@sbcglobal.net> In-Reply-To: <1001356174.1855528.1713894309859@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6055954830785850198==" --===============6055954830785850198== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 2024-04-23 at 12:45 -0500, CAREY SCHUG via cctalk wrote: > Sorry, I guess this should dead end, it is too far off track. I will still= post this since I was among those misled into thinking it had an 1802 microp= rocessor. The galileo had an 1802, but it suicided. >=20 > from Wikipedia: >=20 > It has been erroneously reported[41] on the Internet that the Voyager > space probes were controlled by a version of the RCA 1802 (RCA > CDP1802 "COSMAC" microprocessor), but such claims are not supported > by the primary design documents. The CDP1802 microprocessor was used > later in the Galileo space probe, which was designed and built years > later. The digital control electronics of the Voyagers were not based > on a microprocessor integrated-circuit chip. >=20 > 
--Carey
NASA has an article about the Voyager computers (two each of three different kinds) at=20 https://voyager.jpl.nasa.gov/frequently-asked-questions/ Look for the pop-open "What kind of computers are used on the Voyager spacecraft?" The last paragraph is "Voyager was built in-house at JPL; the computers were manufactured by General Electric to JPL specifications." --===============6055954830785850198==-- From van.snyder@sbcglobal.net Tue Apr 23 23:08:09 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 16:08:00 -0700 Message-ID: <78c4d8e69529ab14032101d5b7516cbc483b6746.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7994755285550812019==" --===============7994755285550812019== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2024-04-23 at 13:27 +0200, Peter Corlett via cctalk wrote: > The Z80 takes three or four memory cycles to perform a memory access versus > the 6502 accessing memory on every cycle, I shared an office with a lady who got a computer from Ohio Scientific that had both a Z80 and a 6502. It also had two 5/25" floppy drives. She also got a tee-shirt that said "I have two floppies." Except she didn't. --===============7994755285550812019==-- From spectre@floodgap.com Tue Apr 23 23:46:26 2024 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 16:38:11 -0700 Message-ID: <53be95d3-bded-4318-83ea-654974628d47@floodgap.com> In-Reply-To: <78c4d8e69529ab14032101d5b7516cbc483b6746.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6120479792447863534==" --===============6120479792447863534== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I shared an office with a lady who got a computer from Ohio Scientific > that had both a Z80 and a 6502. The Commodore 128 says hi. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- If you're too open-minded, your brains will fall out. --------------------= -- --===============6120479792447863534==-- From cisin@xenosoft.com Wed Apr 24 00:00:41 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 17:00:37 -0700 Message-ID: In-Reply-To: <78c4d8e69529ab14032101d5b7516cbc483b6746.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3616572563359851737==" --===============3616572563359851737== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: > I shared an office with a lady who got a computer from Ohio Scientific > that had both a Z80 and a 6502. It also had two 5/25" floppy drives. > She also got a tee-shirt that said "I have two floppies." Except she > didn't. aside from her floppies, . . . a significant portion (I remember at one time, somebody at Apple said 20%) of Apple users had the Microsoft SoftCard Z80, or imitations thereof. At least one of the Apple imitations had both 6502 and Z80. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============3616572563359851737==-- From bitwiz@12bitsbest.com Wed Apr 24 00:05:08 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 19:04:58 -0500 Message-ID: <716b1717-55e7-4f96-b60b-61c5fe1bca54@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2133199205021745274==" --===============2133199205021745274== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I think Ohio Scientific made a computer called the 3B or something like that that had a 6502, a Z-80 and a 6800 in it.  If my memory serves. On 4/23/2024 7:00 PM, Fred Cisin via cctalk wrote: > On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: >> I shared an office with a lady who got a computer from Ohio Scientific >> that had both a Z80 and a 6502. It also had two 5/25" floppy drives. >> She also got a tee-shirt that said "I have two floppies." Except she >> didn't. > > aside from her floppies, . . . > a significant portion (I remember at one time, somebody at Apple said > 20%) > of Apple users had the Microsoft SoftCard Z80, or imitations thereof. > > At least one of the Apple imitations had both 6502 and Z80. > > -- > Grumpy Ol' Fred             cisin(a)xenosoft.com > --===============2133199205021745274==-- From cisin@xenosoft.com Wed Apr 24 00:06:53 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 17:06:48 -0700 Message-ID: In-Reply-To: <716b1717-55e7-4f96-b60b-61c5fe1bca54@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2416764548752149685==" --===============2416764548752149685== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? Commodore 128 had Z80 and 6502 On Tue, 23 Apr 2024, Mike Katz wrote: > I think Ohio Scientific made a computer called the 3B or something like tha= t=20 > that had a 6502, a Z-80 and a 6800 in it.=C2=A0 If my memory serves. > > On 4/23/2024 7:00 PM, Fred Cisin via cctalk wrote: >> On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: >>> I shared an office with a lady who got a computer from Ohio Scientific >>> that had both a Z80 and a 6502. It also had two 5/25" floppy drives. >>> She also got a tee-shirt that said "I have two floppies." Except she >>> didn't. >>=20 >> aside from her floppies, . . . >> a significant portion (I remember at one time, somebody at Apple said 20%) >> of Apple users had the Microsoft SoftCard Z80, or imitations thereof. >>=20 >> At least one of the Apple imitations had both 6502 and Z80. >>=20 >> --=20 >> Grumpy Ol' Fred=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 cisin(a)xenosoft.com --===============2416764548752149685==-- From bill.gunshannon@hotmail.com Wed Apr 24 00:18:17 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 20:18:08 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6663292331635809596==" --===============6663292331635809596== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/23/2024 8:06 PM, Fred Cisin via cctalk wrote: > Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? > What about the Tandy 16 and 6000. M68K and Z80. bill --===============6663292331635809596==-- From cisin@xenosoft.com Wed Apr 24 00:29:00 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 17:28:54 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737322EAA955B12769A3CC0ED102=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2318323740717687190==" --===============2318323740717687190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? On Tue, 23 Apr 2024, Bill Gunshannon via cctalk wrote: > What about the Tandy 16 and 6000. M68K and Z80. Yes. But the original comment that I was responding to was asking Z80 and 6502. Cromemco also had a 68000 and Z80 machine. a friend of a friend had one, and turned up his nose at the thought of a Tandy machine. BTW, I found out about the Dimension 68000; it was rather expensive https://en.wikipedia.org/wiki/Dimension_68000 68000, Z80, 8086 -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============2318323740717687190==-- From van.snyder@sbcglobal.net Wed Apr 24 01:13:04 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 18:12:53 -0700 Message-ID: <8281ae313cbe6f240175d573d8b1f1d61cc60af9.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4267168205036099033==" --===============4267168205036099033== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2024-04-23 at 17:06 -0700, Fred Cisin via cctalk wrote: > a significant portion (I remember at one time, somebody at Apple said 20%) > > > of Apple users had the Microsoft SoftCard Z80, or imitations thereof. I had a "Magic Sac" thing-y that plugged into the ROM port of my Atari 1040. When I put a Mac ROM into its socket, I could run most Mac programs that I had. --===============4267168205036099033==-- From cisin@xenosoft.com Wed Apr 24 01:20:05 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 18:19:57 -0700 Message-ID: In-Reply-To: <8281ae313cbe6f240175d573d8b1f1d61cc60af9.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1105668615786786199==" --===============1105668615786786199== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 23 Apr 2024, Van Snyder via cctalk wrote: > I had a "Magic Sac" thing-y that plugged into the ROM port of my Atari > 1040. When I put a Mac ROM into its socket, I could run most Mac > programs that I had. That was pretty cool The developer of it said that when he met with Apple's lawyers, "Magic Sack" was as close to "Mac" as they would let him be. --===============1105668615786786199==-- From cclist@sydex.com Wed Apr 24 02:41:11 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 19:40:58 -0700 Message-ID: <011f5098-e8a6-4990-8035-1adbb7fef8fb@sydex.com> In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737322EAA955B12769A3CC0ED102=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7046379614549393426==" --===============7046379614549393426== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/23/24 17:18, Bill Gunshannon via cctalk wrote: > > > On 4/23/2024 8:06 PM, Fred Cisin via cctalk wrote: >> Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? Couldn't Bill Godbout's CPU-68K board co-exist with other CPU boards? --Chuck --===============7046379614549393426==-- From bfranchuk@jetnet.ab.ca Wed Apr 24 04:07:09 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Tue, 23 Apr 2024 22:06:54 -0600 Message-ID: <3bbb8728-244c-46d9-9d38-94261118df45@jetnet.ab.ca> In-Reply-To: <011f5098-e8a6-4990-8035-1adbb7fef8fb@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2341797969372137235==" --===============2341797969372137235== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-04-23 8:40 p.m., Chuck Guzis via cctalk wrote: > On 4/23/24 17:18, Bill Gunshannon via cctalk wrote: >> >> >> On 4/23/2024 8:06 PM, Fred Cisin via cctalk wrote: >>> Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? > > Couldn't Bill Godbout's CPU-68K board co-exist with other CPU boards? > > --Chuck > I remember Bill Godbout's PACE ads. Now I got the $$$ and time I can't find any chips. --===============2341797969372137235==-- From cclist@sydex.com Wed Apr 24 15:00:53 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 08:00:34 -0700 Message-ID: In-Reply-To: <3bbb8728-244c-46d9-9d38-94261118df45@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8461794365157615145==" --===============8461794365157615145== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/23/24 21:06, ben via cctalk wrote: >> > I remember Bill Godbout's PACE ads. Now I got the $$$ and time I can't > find any chips. National was handing the chips with manuals out for free at on WESCON--I got mine there, built up an S100 board with all of the interface logic (I think the PACE was originally PMOS) and never could really get the thing working reliably. It wasn't clear to me, after all was said and done that PACE offered any substantial improvement over the 8 bit chips. A later version used standard TTL levels and should still be findable--and a lot easier to put into a design. One thing that NSI could be depended on for--absolute volatility in the choice of design du jour. --Chuck --===============8461794365157615145==-- From r_a_feldman@hotmail.com Wed Apr 24 17:54:43 2024 From: Robert Feldman To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 17:54:36 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5398513675353550584==" --===============5398513675353550584== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The Otrona Attache 8:16 had a Z80A and an 8086 on a daughter card. Bob --===============5398513675353550584==-- From cclist@sydex.com Wed Apr 24 18:30:37 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 11:30:22 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CLV2PR12MB57275FC7A583ABD85234F430B5102=40LV2PR12MB?= =?utf-8?q?5727=2Enamprd12=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2286664392244861586==" --===============2286664392244861586== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/24/24 10:54, Robert Feldman via cctalk wrote: > The Otrona Attache 8:16 had a Z80A and an 8086 on a daughter card. Of course, Godbout offered the S100 85/88 board in the same vein. --CHuck --===============2286664392244861586==-- From cisin@xenosoft.com Wed Apr 24 18:34:20 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 11:34:15 -0700 Message-ID: In-Reply-To: <011f5098-e8a6-4990-8035-1adbb7fef8fb@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4250809543254103126==" --===============4250809543254103126== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >>> Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? On Tue, 23 Apr 2024, Chuck Guzis via cctalk wrote: > Couldn't Bill Godbout's CPU-68K board co-exist with other CPU boards? Did he, or anybody else, make an S100 6502 CPU board? --===============4250809543254103126==-- From cclist@sydex.com Wed Apr 24 18:41:21 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 11:41:10 -0700 Message-ID: <77ff00b8-c6e8-47fe-a061-f7d77678f792@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5781688391609905457==" --===============5781688391609905457== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/24/24 11:34, Fred Cisin wrote: >>>> Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? > > On Tue, 23 Apr 2024, Chuck Guzis via cctalk wrote: >> Couldn't Bill Godbout's CPU-68K board co-exist with other CPU boards? > > Did he, or anybody else, make an S100 6502 CPU board? Early on, yes, there was at least one 6502 board, but I don't recall who offered it--a couple of friends had them. Perhaps SSM; I didn't find them that interesting, given the lack of any sort of software support. --Chuck --===============5781688391609905457==-- From abs@absd.org Wed Apr 24 20:10:49 2024 From: David Brownlee To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 21:10:28 +0100 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737322EAA955B12769A3CC0ED102=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1827464595200958253==" --===============1827464595200958253== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 24 Apr 2024 at 01:18, Bill Gunshannon via cctalk wrote: > > On 4/23/2024 8:06 PM, Fred Cisin via cctalk wrote: > > Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? > > > > What about the Tandy 16 and 6000. M68K and Z80. If we're talking about machines with a Z80 and 6502, it would be remiss not to link back to the machine mentioned in the original message - the BBC micro, with its onboard 6502 and "Tube" interface which could take a second processor option, including - Z80 - 65C02 / 65C102 - NS 16032 (ahem 32016) - 8088 (Torch) / 80186, 80286 (last developed but never released) - ARM1 (Original ARM development board. Rare as hens teeth :) / ARM7 (someone having a laugh in later years) Typically the second processor would run as primary, using the original 6502 to handle input, display and I/O (and on 32016 you *really* wanted someone else to deal with anything time critical like interrupts :) David --===============1827464595200958253==-- From gordon+cctalk@drogon.net Wed Apr 24 21:01:26 2024 From: Gordon Henderson To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 21:55:01 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5063659391576775350==" --===============5063659391576775350== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 24 Apr 2024, David Brownlee via cctalk wrote: > If we're talking about machines with a Z80 and 6502, it would be > remiss not to link back to the machine mentioned in the original > message - the BBC micro, with its onboard 6502 and "Tube" interface > which could take a second processor option, including > - Z80 > - 65C02 / 65C102 > - NS 16032 (ahem 32016) > - 8088 (Torch) / 80186, 80286 (last developed but never released) > - ARM1 (Original ARM development board. Rare as hens teeth :) / ARM7 > (someone having a laugh in later years) > > Typically the second processor would run as primary, using the > original 6502 to handle input, display and I/O (and on 32016 you > *really* wanted someone else to deal with anything time critical like > interrupts :) "later years" is .. Today where we connect a Raspbery Pi to the BBC Micros Tube interface and emulate all those CPUs and several more like the PDP/11. One of the 6502 emulations runs at the equivalent of a 275Mhz CPU... So if you want a Z80 then emulate it - it runs CP/M just as well as any other CP/M system. The original ARM2 is there too. The current list: n Processor - *FX 151,230,n 0 * 65C02 (fast) 1 65C02 (3MHz, for games compatbility) 2 65C102 (fast) 3 65C102 (4MHz, for games compatbility) 4 Z80 (1.21) 5 Z80 (2.00) 6 Z80 (2.2c) 7 Z80 (2.30) 8 80286 9 MC6809 11 PDP-11 12 ARM2 13 32016 14 Disable 15 ARM Native 16 LIB65C02 64K 17 LIB65C02 256K Turbo 18 65C816 (Dossy) 19 65C816 (ReCo) 20 OPC5LS 21 OPC6 22 OPC7 24 65C02 (JIT) 28 Ferranti F100-L Cheers, -Gordon --===============5063659391576775350==-- From bfranchuk@jetnet.ab.ca Wed Apr 24 21:07:20 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 15:06:56 -0600 Message-ID: <546893bd-3f31-4d25-ade2-42b355982268@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6227335691281909976==" --===============6227335691281909976== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-04-24 2:55 p.m., Gordon Henderson via cctalk wrote: > On Wed, 24 Apr 2024, David Brownlee via cctalk wrote: > >> If we're talking about machines with a Z80 and 6502, it would be >> remiss not to link back to the machine mentioned in the original >> message - the BBC micro, with its onboard 6502 and "Tube" interface >> which could take a second processor option, including >> - Z80 >> - 65C02 / 65C102 >> - NS 16032 (ahem 32016) >> - 8088 (Torch) / 80186, 80286 (last developed but never released) >> - ARM1 (Original ARM development board. Rare as hens teeth :) / ARM7 >> (someone having a laugh in later years) >> >> Typically the second processor would run as primary, using the >> original 6502 to handle input, display and I/O (and on 32016 you >> *really* wanted someone else to deal with anything time critical like >> interrupts :) > > "later years" is .. Today where we connect a Raspbery Pi to the BBC > Micros Tube interface and emulate all those CPUs and several more like > the PDP/11. One of the 6502 emulations runs at the equivalent of a > 275Mhz CPU... > > So if you want a Z80 then emulate it - it runs CP/M just as well as any > other CP/M system. > > The original ARM2 is there too. > > The current list: > >  n   Processor - *FX 151,230,n >  0 * 65C02 (fast) >  1   65C02 (3MHz, for games compatbility) >  2   65C102 (fast) >  3   65C102 (4MHz, for games compatbility) >  4   Z80 (1.21) >  5   Z80 (2.00) >  6   Z80 (2.2c) >  7   Z80 (2.30) >  8   80286 >  9   MC6809 > 11   PDP-11 > 12   ARM2 > 13   32016 > 14   Disable > 15   ARM Native > 16   LIB65C02 64K > 17   LIB65C02 256K Turbo > 18   65C816 (Dossy) > 19   65C816 (ReCo) > 20   OPC5LS > 21   OPC6 > 22   OPC7 > 24   65C02 (JIT) > 28   Ferranti F100-L > > Cheers, > > -Gordon This would be great, but I live on the other side of the pond and BBC anything is hard to find, let alone Micro's. Where is my "Dr. Who". Ben. --===============6227335691281909976==-- From cisin@xenosoft.com Wed Apr 24 21:37:10 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] OFF TOPIC: Doctor Who (was: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 14:37:03 -0700 Message-ID: In-Reply-To: <546893bd-3f31-4d25-ade2-42b355982268@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8692692081231663563==" --===============8692692081231663563== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 24 Apr 2024, ben via cctalk wrote: > This would be great, but I live on the other side of the pond > and BBC anything is hard to find, let alone Micro's. > Where is my "Dr. Who". > Ben. I was able, quite easily, to order DVDs from Amazon.co.uk. That got me "Shada" (Doctor who written by Douglas Adams), and the 2023 specials, LONG before they were released in USA. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============8692692081231663563==-- From cclist@sydex.com Wed Apr 24 22:11:05 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Wed, 24 Apr 2024 15:10:53 -0700 Message-ID: <3413a88c-accd-42b4-b2be-d42d8c6880d0@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4250866282043330613==" --===============4250866282043330613== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/24/24 13:10, David Brownlee via cctalk wrote: > Typically the second processor would run as primary, using the > original 6502 to handle input, display and I/O (and on 32016 you > *really* wanted someone else to deal with anything time critical like > interrupts :) Thats the way we did it on the Poppy--the 80186 did the I/O for the 80286. You could run CP/M-86 or MSDOS without the 80286. I never did figure out if the 80286 at 6MHz was outperformed on MSDOS by the 8MHz 80186. --Chuck --===============4250866282043330613==-- From bfranchuk@jetnet.ab.ca Wed Apr 24 22:32:41 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: OFF TOPIC: Doctor Who Date: Wed, 24 Apr 2024 16:32:24 -0600 Message-ID: <5c9df7cc-0e0e-4944-80ae-1611bc81d580@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5751131273242307975==" --===============5751131273242307975== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit https://www.youtube.com/watch?v=iJeu3LCo-6A Dr who ads for prime. --===============5751131273242307975==-- From cclist@sydex.com Wed Apr 24 22:53:06 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: OFF TOPIC: Doctor Who Date: Wed, 24 Apr 2024 15:52:56 -0700 Message-ID: In-Reply-To: <5c9df7cc-0e0e-4944-80ae-1611bc81d580@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4455099181285615922==" --===============4455099181285615922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/24/24 15:32, ben via cctalk wrote: > https://www.youtube.com/watch?v=iJeu3LCo-6A > Dr who ads for prime. I think old Dr. Who shows are also on Pluto TV. --Chuck (not a fan) --===============4455099181285615922==-- From jimliu@umich.edu Thu Apr 25 13:43:50 2024 From: James Liu To: cctalk@classiccmp.org Subject: [cctalk] CDC and IBM Schoonschip Date: Thu, 25 Apr 2024 09:43:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7152803925950714862==" --===============7152803925950714862== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, As some of you may recall, a few years ago I asked for assistance reading a 9 track tape containing IBM S/360 source for Martinus Veltman's computer algebra program, Schoonschip (https://en.wikipedia.org/wiki/Schoonschip). With Chuck's assistance, we recovered all the code from the tape. After working with the principals involved, I am pleased to announce that the source code is now publicly available at: https://vsys.physics.lsa.umich.edu/ Actually, I was always more interested in the original CDC 6600 source code, as that is the more historically significant code. While that was not contained on the 9 track tape, I did receive a copy from the Veltman family, and that is also available from the above website. I have limited experience with big iron, but I had very good success getting Schoonschip compiled and running on dtCyber. Veltman also provided example Schoonschip programs (YNGLING), and as far as I can tell they run perfectly in CDC Schoonschip on dtCyber. However, I have not been fully successful in getting IBM Schoonschip to run on hercules under OS/360 MVT. The main issue I had was that the Fortran part of Schoonschip uses REAL*16, which apparently requires the H extended Fortran compiler that does not seem to be freely available. I did patch the Fortran code to avoid extended precision and managed to get Schoonschip running, but it would sometimes crash on some input files. I do not know if that is a problem with my patches or an actual bug in the original code (as the IBM version of Schoonschip was still a work in progress at the time development stopped). In any case, anyone who is interested is welcome to have their own go at the code. The third evolution of Schoonschip (m68k code, which was written after Veltman came to the University of Michigan) is also available at the same website. - jim -- James T. Liu, Professor of Physics 3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040 Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu(a)umich.edu --===============7152803925950714862==-- From paulkoning@comcast.net Thu Apr 25 13:54:07 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: CDC and IBM Schoonschip Date: Thu, 25 Apr 2024 09:53:36 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7564284597685811553==" --===============7564284597685811553== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 25, 2024, at 9:43 AM, James Liu via cctalk = wrote: >=20 > Hi, >=20 > As some of you may recall, a few years ago I asked for assistance > reading a 9 track tape containing IBM S/360 source for Martinus > Veltman's computer algebra program, Schoonschip > (https://en.wikipedia.org/wiki/Schoonschip). With Chuck's assistance, > we recovered all the code from the tape. After working with the > principals involved, I am pleased to announce that the source code is > now publicly available at: > https://vsys.physics.lsa.umich.edu/ Neat. I vaguely remember that program name from long ago, though I haven't u= sed it. (Part of why it's familiar is that it's a nice Dutch word hard to pr= onounce for most others... :-) ) I wonder how difficult it would be to port to a present-day compiler like gfo= rtran. paul --===============7564284597685811553==-- From lists@skogtun.org Thu Apr 25 14:15:23 2024 From: Harald Arnesen To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Thu, 25 Apr 2024 16:15:15 +0200 Message-ID: <4eb85ea4-ca96-4531-85ec-478feb124b5f@skogtun.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6413267213870973776==" --===============6413267213870973776== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Fred Cisin via cctalk [24/04/2024 02.06]: > Did the Dimension 68000 (a multi-processor machine) have Z80 and 6502? > > Commodore 128 had Z80 and 6502 Z80 and 8502, actually. -- Hilsen Harald --===============6413267213870973776==-- From jimliu@umich.edu Thu Apr 25 14:17:47 2024 From: James Liu To: cctalk@classiccmp.org Subject: [cctalk] Re: CDC and IBM Schoonschip Date: Thu, 25 Apr 2024 10:17:29 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7019997392302637814==" --===============7019997392302637814== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2024 at 9:54=E2=80=AFAM Paul Koning via cctalk wrote: > > Neat. I vaguely remember that program name from long ago, though I haven't= used it. (Part of why it's familiar is that it's a nice Dutch word hard to = pronounce for most others... :-) ) Done on purpose of course :-) > I wonder how difficult it would be to port to a present-day compiler like g= fortran. I think the code is mostly interesting for historical reasons. It was originally written mostly in COMPASS assembly with the Fortran handling input/output sort of stuff and then translated (in a somewhat unusual manner) into IBM BAL by Hugo Strubbe. Later, when Tini realized that the CDC mainframes were on their way out, he ported Schoonschip to m68k assembly. In fact, he wrote his own m68k toolchain (ie assembler and linker) in order to do so! Tini Veltman is probably best known for his work on dimensional regularization and the Standard Model which led to his Nobel Prize. However, he also had a computing side to him. Of course, he had his own way of doing things .. like not trusting any high level languages. He was apparently quite proud of optimizing his code for the CDC 6600. But tying Schoonschip to the bare metal is probably one of the main reasons it hasn't survived beyond an important historical milestone. - jim --=20 James T. Liu, Professor of Physics 3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040 Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu(a)umich.edu --===============7019997392302637814==-- From wh.sudbrink@verizon.net Thu Apr 25 16:26:06 2024 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Altair 8800 50th birthday... Date: Thu, 25 Apr 2024 12:25:32 -0400 Message-ID: <08c701da972d$329ec780$97dc5680$@verizon.net> In-Reply-To: <08c701da972d$329ec780$97dc5680$.ref@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5197443063519317500==" --===============5197443063519317500== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Based on what I have read, along with a few discussions I have had with people involved in the early S-100 "scene" around now is the 50th birthday (or conception day) of the Altair 8800. Certainly, next year could properly be called its 50th birthday. Anyway, I'm thinking about "painting the show blue" with Altairs and IMSAIs for the next few vintage computer festivals. Anyone else interested? Bill S. -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============5197443063519317500==-- From paulkoning@comcast.net Thu Apr 25 20:28:03 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: CDC and IBM Schoonschip Date: Thu, 25 Apr 2024 16:27:56 -0400 Message-ID: <0D491D4D-66AE-4D36-A48E-4F1ADE5FA389@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5499170249314296691==" --===============5499170249314296691== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Looking at the webpage for the CDC version, I noticed the comment about SB0 B= 0 vs. NO and the "lore" about the divide unit. That issue is reported in Tho= rnton's book. It wouldn't surprise me if it were a real issue on the "prepro= duction serial number 3" system where that code was first created. =20 It clearly was fixed soon after, though. In the 6600 block diagrams manual w= here the flow of the execution machinery is documented in detail, it's quite = clear that NO does not do any functional unit reservations (but SB0 does). S= o at least starting with serial number 8, and possibly on earlier machines af= ter suitable FCOs were applied, NO is indeed the preferred pass instruction. = On the other hand, 30 bit pass has by convention been done with SB0 B0+0, su= ggesting it's faster to do that than to do two NO instructions. I guess that= 's right in the absence of increment unit conflicts: 3 minor cycles for the S= B0 vs. 4 for the pair of NO instructions. paul --===============5499170249314296691==-- From rtomek@ceti.pl Fri Apr 26 02:25:05 2024 From: Tomasz Rola To: cctalk@classiccmp.org Subject: [cctalk] Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Fri, 26 Apr 2024 04:18:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2541201513415058212==" --===============2541201513415058212== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, if you are into this kind of stuff (I am)... Stross is an s-f author, formerly a programmer (ages ago but I think it still shows - perhaps he secretly writes his own tools in Perl) and he has a blog. This time, he explores the idea that internet "bub" delivered on its promises, rather than sucking investors up. http www.antipope.org charlie/blog-static/2024/04/the-radiant-future-of-1995.= html Of course, readers make comments, so it gets a bit more interesting. --=20 Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com ** --===============2541201513415058212==-- From paulkoning@comcast.net Fri Apr 26 16:49:48 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: CDC and IBM Schoonschip Date: Fri, 26 Apr 2024 12:49:40 -0400 Message-ID: <80225E0E-3F4D-45AD-AD57-2BDA2F3B8FEE@comcast.net> In-Reply-To: <0D491D4D-66AE-4D36-A48E-4F1ADE5FA389@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5444285063026011910==" --===============5444285063026011910== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 25, 2024, at 4:27 PM, Paul Koning via cctalk wrote: >=20 > Looking at the webpage for the CDC version, I noticed the comment about SB0= B0 vs. NO and the "lore" about the divide unit. That issue is reported in T= hornton's book. It wouldn't surprise me if it were a real issue on the "prep= roduction serial number 3" system where that code was first created. =20 >=20 > It clearly was fixed soon after, though. In the 6600 block diagrams manual= where the flow of the execution machinery is documented in detail, it's quit= e clear that NO does not do any functional unit reservations (but SB0 does). = So at least starting with serial number 8, and possibly on earlier machines = after suitable FCOs were applied, NO is indeed the preferred pass instruction= . On the other hand, 30 bit pass has by convention been done with SB0 B0+0, = suggesting it's faster to do that than to do two NO instructions. I guess th= at's right in the absence of increment unit conflicts: 3 minor cycles for the= SB0 vs. 4 for the pair of NO instructions. >=20 > paul >=20 Thinking about the NO instruction: it sure seems odd that it takes 3 cycles g= iven that it doesn't reserve anything. You'd think it would just take up an = issue cycle but nothing else, i.e., 1 minor cycle total. If that were the ca= se then two NO instructions would be the correct way to do 30 bit padding. Curious. Something to look at some day. paul --===============5444285063026011910==-- From sellam.ismail@gmail.com Fri Apr 26 20:52:06 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Fri, 26 Apr 2024 13:51:48 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2356012745938184535==" --===============2356012745938184535== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Apr 25, 2024 at 7:25 PM Tomasz Rola via cctalk < cctalk(a)classiccmp.org> wrote: > Well, if you are into this kind of stuff (I am)... Stross is an s-f > author, formerly a programmer (ages ago but I think it still shows - > perhaps he secretly writes his own tools in Perl) and he has a > blog. This time, he explores the idea that internet "bub" delivered on > its promises, rather than sucking investors up. > > http www.antipope.org > charlie/blog-static/2024/04/the-radiant-future-of-1995.html > > Of course, readers make comments, so it gets a bit more interesting. I stopped reading when I got to this part: "...and it's clearly being pumped up by fascist-adjacent straight white males with an unadmitted political agenda, namely to shore up the structures of privilege and entitlement that keep them wealthy." Seems like a hormonal problem. Sellam --===============2356012745938184535==-- From rtomek@ceti.pl Fri Apr 26 23:01:51 2024 From: Tomasz Rola To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 01:01:41 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1286992103224309562==" --===============1286992103224309562== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Apr 26, 2024 at 01:51:48PM -0700, Sellam Abraham via cctalk wrote: > On Thu, Apr 25, 2024 at 7:25 PM Tomasz Rola via cctalk < > cctalk(a)classiccmp.org> wrote: > > > Well, if you are into this kind of stuff (I am)... Stross is an s-f > > author, formerly a programmer (ages ago but I think it still shows - > > perhaps he secretly writes his own tools in Perl) and he has a > > blog. This time, he explores the idea that internet "bub" delivered on > > its promises, rather than sucking investors up. [...] > I stopped reading when I got to this part: "...and it's clearly being > pumped up by fascist-adjacent straight white males with an unadmitted > political agenda, namely to shore up the structures of privilege and > entitlement that keep them wealthy." > > Seems like a hormonal problem. Oh? Maybe. The thing is, I may read Stross (and other people) to feed my own opinion making machine but I do not necessarily endorse all of theirs. In a "good old bad times" I was growing up with agitprop coming at me in full spectrum - from things which were obvious manipulation to subtle, gentle pulling of strings with one or two words. I guess my brain learned to notice what was transparent enough to be noticed, mark it with red circle and move on - thus I noticed the words you mentioned and moved on to his remarks about OS/2, Linux and Newton (because my brain found those to be more interesting). As of his mentioning of fas*-leaning groups who want to use AI (and other modern tech) in order to propel themselves, I am not sure if you agree that such groups exist or not. Myself, I am willing to believe that yes, humans have wast potential to misuse any good invention... and while some humans may think it is good to screw some "others", I believe it all comes back to them, only later and no matter if they want it or allow it, they still receive it. Probably. I do not mean some higher being and legendary Judgement, I only mean laws of physics, psychology and other such things (kind of, if one shits too much into a river, because it all flows down to other guy, one may finally notice that rain became somewhat smelly - as it becomes obvious when watching the news nowadays). Looking back, what seemed great around 1995, like certain Manifestos from that time, nowadays seem to me as very naive, now that I grew older and learned a bit about ways of the world (i.e. ways of the people). -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com ** --===============1286992103224309562==-- From sellam.ismail@gmail.com Sat Apr 27 03:49:46 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Fri, 26 Apr 2024 20:49:30 -0700 Message-ID: In-Reply-To: <08c701da972d$329ec780$97dc5680$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3434727220214134572==" --===============3434727220214134572== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Apr 25, 2024 at 9:26 AM William Sudbrink via cctalk < cctalk(a)classiccmp.org> wrote: > Based on what I have read, along with a few discussions I have had with > people involved in the early S-100 "scene" around now is the 50th birthday > (or conception day) of the Altair 8800. Certainly, next year could > properly > be called its 50th birthday. Anyway, I'm thinking about "painting the show > blue" with Altairs and IMSAIs for the next few vintage computer festivals. > Anyone else interested? > > Bill S. > Hi Bill. It really is a momentous event, and should be properly honored and celebrated. Wow, half a century. Thanks for bringing this up. Sellam --===============3434727220214134572==-- From cisin@xenosoft.com Sat Apr 27 04:05:52 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Fri, 26 Apr 2024 21:05:46 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1057915592487578508==" --===============1057915592487578508== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 26 Apr 2024, Sellam Abraham via cctalk wrote: > It really is a momentous event, and should be properly honored and > celebrated. Wow, half a century. > Thanks for bringing this up. Is this half a century from when they said, "Hey, you know what would be neat to build?" or from when they started designing? or got a preliminary design done? built a prototype? announced it? started taking orders? started filling orders? --===============1057915592487578508==-- From wh.sudbrink@verizon.net Sat Apr 27 07:56:54 2024 From: wh.sudbrink@verizon.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Sat, 27 Apr 2024 07:56:24 +0000 Message-ID: <1754040190.4448455.1714204584842@mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2358386798141302204==" --===============2358386798141302204== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mr. Solomon started talking to Mr. Roberts and Mr. Yates about the Altair pr= oject. What could and could not be done given budget, availability of parts, = complexity of construction, etc. What the potential market would look like. A= nd, maybe most importantly, the promotion of the project in Popular Electroni= cs.=C2=A0 On Saturday, April 27, 2024 at 12:05:57 AM EDT, Fred Cisin via cctalk wrote: =20 =20 On Fri, 26 Apr 2024, Sellam Abraham via cctalk wrote: > It really is a momentous event, and should be properly honored and > celebrated.=C2=A0 Wow, half a century. > Thanks for bringing this up. Is this half a century from when they said, "Hey, you know what would be=20 neat to build?" or from when they started designing? or got a preliminary design done? built a prototype? announced it? started taking orders? started filling orders? =20 --===============2358386798141302204==-- From billdegnan@gmail.com Sat Apr 27 11:43:51 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Sat, 27 Apr 2024 07:43:33 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0667562542601715141==" --===============0667562542601715141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Magazine cover january, and into 1975 the revolution. So I'd say all year. Not one specific date Bill On Sat, Apr 27, 2024, 12:05 AM Fred Cisin via cctalk wrote: > On Fri, 26 Apr 2024, Sellam Abraham via cctalk wrote: > > It really is a momentous event, and should be properly honored and > > celebrated. Wow, half a century. > > Thanks for bringing this up. > > Is this half a century from when they said, "Hey, you know what would be > neat to build?" > or from when they started designing? > or got a preliminary design done? > built a prototype? > announced it? > started taking orders? > started filling orders? > > --===============0667562542601715141==-- From lproven@gmail.com Sat Apr 27 12:48:16 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 13:47:59 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4670748156929710365==" --===============4670748156929710365== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 26 Apr 2024 at 03:25, Tomasz Rola via cctalk wrote: > > Well, if you are into this kind of stuff (I am)... Stross is an s-f > author, formerly a programmer (ages ago but I think it still shows - > perhaps he secretly writes his own tools in Perl) He wrote the Linux column in the UK version of Computer Shopper from its launch until the late 1990s, when his novel-writing career took off. That's when I met him; I worked for sister mag PC Pro, from the same publisher on another floor of the same building. Charlie's been a mate ever since and I've stayed at his place a few times. I still own 2 of his cast-off Macs. :-) He is very _very_ smart and also extremely technically knowledgeable. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============4670748156929710365==-- From lproven@gmail.com Sat Apr 27 12:49:54 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 13:49:37 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2930264988856545453==" --===============2930264988856545453== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 26 Apr 2024 at 21:52, Sellam Abraham via cctalk wrote: > > Seems like a hormonal problem. No, there is a problem, but it's your knee-jerk reactions. Sorry, man, but it is. Charlie's bang on. Also, he's very British and very sarcastic, in that British way many Americans of my personal acquaintance find hard to parse and hard to handle. I have some very close American friends, but they're the bitter sarcastic type. :-D Try finishing it. It's worth it. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============2930264988856545453==-- From bill.gunshannon@hotmail.com Sat Apr 27 14:14:28 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Sat, 27 Apr 2024 10:14:14 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7783036955897435469==" --===============7783036955897435469== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/27/2024 7:43 AM, Bill Degnan via cctalk wrote: > Magazine cover january, and into 1975 the revolution. So I'd say all > year. Not one specific date I had that magazine. Wish I hadn't thrown it away oh so many years ago. But even at that, nothing for me to celebrate. I couldn't afford one then and I still can't afford one. The same goes for the IMSAI-8080. And the Heath H-8 falls into the same category. :-( bill --===============7783036955897435469==-- From wh.sudbrink@verizon.net Sat Apr 27 14:42:00 2024 From: wh.sudbrink@verizon.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Sat, 27 Apr 2024 14:41:22 +0000 Message-ID: <1521492940.4516690.1714228882960@mail.yahoo.com> In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737E5D5A2A6035257B4FE29ED152=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8529417574543971422==" --===============8529417574543971422== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm sorry to hear that. Some of the best parts of my S100 collection came to= me by way of either "please take care of this for me" or "come get this or i= t goes to the dump".=C2=A0 Remember the old "classic computer rescue list"?= =C2=A0 I suppose I've been fortunate that I have had storage space and a symp= athetic spouse.=C2=A0 On Saturday, April 27, 2024 at 10:14:35 AM EDT, Bill Gunshannon via cctal= k wrote: =20 =20 =20 On 4/27/2024 7:43 AM, Bill Degnan via cctalk wrote: > Magazine cover january, and into 1975 the revolution.=C2=A0 So I'd say all > year.=C2=A0 Not one specific date I had that magazine.=C2=A0 Wish I hadn't thrown it away oh so many years ago. But even at that, nothing for me to celebrate.=C2=A0 I couldn't afford one then and I still can't afford one.=C2=A0 The same goes for the IMSAI-8080.=C2=A0 And the Heath H-8 falls into the same category.=C2=A0 :-( bill =20 --===============8529417574543971422==-- From tarek@infocom.ai Sat Apr 27 15:14:23 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Sat, 27 Apr 2024 08:14:04 -0700 Message-ID: In-Reply-To: <1521492940.4516690.1714228882960@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2224138273897012939==" --===============2224138273897012939== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I managed to find and buy a fair copy of the magazine on eBay for $150 two we= eks ago.=20 Regards, Tarek Hoteit, PhD Principal AI Consultant https://tarek.computer INFOCOM AI https://infocom.ai > On Apr 27, 2024, at 07:42, wh.sudbrink--- via cctalk wrote: >=20 > =EF=BB=BF I'm sorry to hear that. Some of the best parts of my S100 collect= ion came to me by way of either "please take care of this for me" or "come ge= t this or it goes to the dump". Remember the old "classic computer rescue li= st"? I suppose I've been fortunate that I have had storage space and a sympa= thetic spouse.=20 > On Saturday, April 27, 2024 at 10:14:35 AM EDT, Bill Gunshannon via ccta= lk wrote: =20 >=20 >=20 >=20 >> On 4/27/2024 7:43 AM, Bill Degnan via cctalk wrote: >> Magazine cover january, and into 1975 the revolution. So I'd say all >> year. Not one specific date >=20 > I had that magazine. Wish I hadn't thrown it away oh so many > years ago. >=20 > But even at that, nothing for me to celebrate. I couldn't afford > one then and I still can't afford one. The same goes for the > IMSAI-8080. And the Heath H-8 falls into the same category. :-( >=20 > bill >=20 --===============2224138273897012939==-- From cz@alembic.crystel.com Sat Apr 27 15:57:17 2024 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 11:57:10 -0400 Message-ID: <2ed6a8a4-65ab-464b-8af5-2da59c009496@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7465808708737632846==" --===============7465808708737632846== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It is funny, but truth be told we dodged a massive bullet by going with the "Internet" and TCP/IP as opposed to the nightmare of AT&T Connect, IPX, and the blazing speeds of TWO! ISDN B channels. I was there. I remember X.400, and how NDS was going to be the directory system that bound us all together in hell forever. I remember everything... We missed living in that crap-sack universe by six months or so. CZ --===============7465808708737632846==-- From c.murray.mccullough@gmail.com Sat Apr 27 16:20:40 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Sat, 27 Apr 2024 12:20:20 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6288675089730210986==" --===============6288675089730210986== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The Altair 8800 used a microprocessor, the 8080, and came to public prominence in Jan. 1975 in Popular Electronics magazine: "World's First Minicomptuer Kit to Rival Commercial Models." I have the original magazine from that era and I remember this quite well as it brought attention to a mass-consumer audience - a device called a microcomputer though not what PE called it! Here in Canada the price was very expensive but I had a dear friend, an electronics engineer, who purchased one. It was very limited, hardware and software-wise, and my friend found it a ‘nightmare’ to build but what a momentous reward when it finally worked. To this 23 year-old it certainly sparked my interest with what we now call classical computing. Happy computing all. 🙂 On Sat, Apr 27, 2024 at 11:53 AM Tarek Hoteit via cctalk < cctalk(a)classiccmp.org> wrote: > I managed to find and buy a fair copy of the magazine on eBay for $150 two > weeks ago. > > Regards, > Tarek Hoteit, PhD > Principal AI Consultant > https://tarek.computer > > INFOCOM AI https://infocom.ai > > > > On Apr 27, 2024, at 07:42, wh.sudbrink--- via cctalk < > cctalk(a)classiccmp.org> wrote: > > > >  I'm sorry to hear that. Some of the best parts of my S100 collection > came to me by way of either "please take care of this for me" or "come get > this or it goes to the dump". Remember the old "classic computer rescue > list"? I suppose I've been fortunate that I have had storage space and a > sympathetic spouse. > > On Saturday, April 27, 2024 at 10:14:35 AM EDT, Bill Gunshannon via > cctalk wrote: > > > > > > > >> On 4/27/2024 7:43 AM, Bill Degnan via cctalk wrote: > >> Magazine cover january, and into 1975 the revolution. So I'd say all > >> year. Not one specific date > > > > I had that magazine. Wish I hadn't thrown it away oh so many > > years ago. > > > > But even at that, nothing for me to celebrate. I couldn't afford > > one then and I still can't afford one. The same goes for the > > IMSAI-8080. And the Heath H-8 falls into the same category. :-( > > > > bill > > > --===============6288675089730210986==-- From tarek@infocom.ai Sat Apr 27 17:23:01 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 10:15:47 -0700 Message-ID: <29094D76-20B7-4BF7-ACE0-22AE3C5AE53A@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1898981678226075749==" --===============1898981678226075749== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I came across this paragraph from the July 1981 Popular Science magazine edit= ion in the article titled =E2=80=9CCompute power - pro models at almost home-= unit prices.=E2=80=9D=20 =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it home, = and then spend the rest of their time looking for things it can do=E2=80=99, = said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around. Here= you know the job, you have to find a machine that will do it. More precisely= , you have to find software that will do the job. Finding a computer to use t= he software you=E2=80=99ve selected becomes secondary.=E2=80=9D.=20 Do you guys* think that software drove hardware sales rather than the other w= ay around for businesses in the early days? I recall that computer hardware s= alespeople would be knocking on businesses office doors rather than software = salesmen. Just seeking your opinion now that we are far ahead from 1981.=20 (*I do wish we have female gender engaged in the classic computing discussio= ns threads as well. Maybe there is.)=20 Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675 --===============1898981678226075749==-- From wayne.sudol@hotmail.com Sat Apr 27 17:39:19 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 17:39:12 +0000 Message-ID: In-Reply-To: <29094D76-20B7-4BF7-ACE0-22AE3C5AE53A@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7085516475427302993==" --===============7085516475427302993== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable When you say =E2=80=9Csoftware drove hardware sales=E2=80=9D do you mean com= plete software application systems or do you mean compilers available for the= hardware so the software teams had variety in what they could program?=20 Up to the =E2=80=9890=E2=80=99s, companies had big, expensive hardware and li= ttle to no canned software applications so companies also had relatively chea= per software developers to make custom programs.=20 Sent from my iPhone > On Apr 27, 2024, at 10:23, Tarek Hoteit via cctalk wrote: >=20 > =EF=BB=BFI came across this paragraph from the July 1981 Popular Science ma= gazine edition in the article titled =E2=80=9CCompute power - pro models at a= lmost home-unit prices.=E2=80=9D=20 >=20 > =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it home= , and then spend the rest of their time looking for things it can do=E2=80=99= , said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around. He= re you know the job, you have to find a machine that will do it. More precise= ly, you have to find software that will do the job. Finding a computer to use= the software you=E2=80=99ve selected becomes secondary.=E2=80=9D.=20 >=20 > Do you guys* think that software drove hardware sales rather than the other= way around for businesses in the early days? I recall that computer hardware= salespeople would be knocking on businesses office doors rather than softwar= e salesmen. Just seeking your opinion now that we are far ahead from 1981.=20 >=20 > (*I do wish we have female gender engaged in the classic computing discussi= ons threads as well. Maybe there is.)=20 >=20 > Regards, > Tarek Hoteit > AI Consultant, PhD > +1 360-838-3675 >=20 --===============7085516475427302993==-- From tarek@infocom.ai Sat Apr 27 17:41:51 2024 From: Tarek Hoteit To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 10:41:14 -0700 Message-ID: In-Reply-To: =?utf-8?q?=3CMWHPR1001MB2191A2EC4A8F704CA4277B6BE4152=40MWHPR10?= =?utf-8?q?01MB2191=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7101659232047559210==" --===============7101659232047559210== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi. Meant complete software application systems, but, of course, it is eventu= ally powered by language compilers=20 Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675 > On Apr 27, 2024, at 10:39, Wayne S wrote: >=20 > =EF=BB=BFWhen you say =E2=80=9Csoftware drove hardware sales=E2=80=9D do y= ou mean complete software application systems or do you mean compilers availa= ble for the hardware so the software teams had variety in what they could pro= gram? > Up to the =E2=80=9890=E2=80=99s, companies had big, expensive hardware and = little to no canned software applications so companies also had relatively ch= eaper software developers to make custom programs. >=20 > Sent from my iPhone >=20 >> On Apr 27, 2024, at 10:23, Tarek Hoteit via cctalk wrote: >>=20 >> =EF=BB=BFI came across this paragraph from the July 1981 Popular Science m= agazine edition in the article titled =E2=80=9CCompute power - pro models at = almost home-unit prices.=E2=80=9D >>=20 >> =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it hom= e, and then spend the rest of their time looking for things it can do=E2=80= =99, said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around.= Here you know the job, you have to find a machine that will do it. More prec= isely, you have to find software that will do the job. Finding a computer to = use the software you=E2=80=99ve selected becomes secondary.=E2=80=9D. >>=20 >> Do you guys* think that software drove hardware sales rather than the othe= r way around for businesses in the early days? I recall that computer hardwar= e salespeople would be knocking on businesses office doors rather than softwa= re salesmen. Just seeking your opinion now that we are far ahead from 1981. >>=20 >> (*I do wish we have female gender engaged in the classic computing discuss= ions threads as well. Maybe there is.) >>=20 >> Regards, >> Tarek Hoteit >> AI Consultant, PhD >> +1 360-838-3675 >>=20 --===============7101659232047559210==-- From wayne.sudol@hotmail.com Sat Apr 27 18:13:06 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 18:12:57 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7451531179993201938==" --===============7451531179993201938== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable IMHO, having started programming in 1977, the thing that drove sales was the = promise of reduced costs just by having a computer that could be programmed t= o do accounting type work that would eliminate jobs and thus costs. Mainframe= s were very expensive back then so there weren=E2=80=99t many companies that = developed software just to be marketed to other companies. A lot if what was = sold had been developed by a company for internal use. Tgen someone got the i= dea that they could recoup some development costs by selling the software. A = lot of payroll systems got started like that. Payroll was a logical starting= point because it was a common function within companies. =20 I would say that software never drove hardware sales. You had hardware alread= y and you might try to find software that ran on it or your team programmed i= t in house. I=E2=80=99ve never been to a company that found software then bou= ght the hardware that it ran on. There would be too much due diligence neede= d to make that happen.=20 Sent from my iPhone > On Apr 27, 2024, at 10:41, Tarek Hoteit wrote: >=20 > =EF=BB=BFHi. Meant complete software application systems, but, of course, i= t is eventually powered by language compilers=20 >=20 > Regards, > Tarek Hoteit > AI Consultant, PhD > +1 360-838-3675 >=20 >=20 >> On Apr 27, 2024, at 10:39, Wayne S wrote: >>=20 >> =EF=BB=BFWhen you say =E2=80=9Csoftware drove hardware sales=E2=80=9D do = you mean complete software application systems or do you mean compilers avail= able for the hardware so the software teams had variety in what they could pr= ogram? >> Up to the =E2=80=9890=E2=80=99s, companies had big, expensive hardware and= little to no canned software applications so companies also had relatively c= heaper software developers to make custom programs. >>=20 >> Sent from my iPhone >>=20 >>>> On Apr 27, 2024, at 10:23, Tarek Hoteit via cctalk wrote: >>>=20 >>> =EF=BB=BFI came across this paragraph from the July 1981 Popular Science = magazine edition in the article titled =E2=80=9CCompute power - pro models at= almost home-unit prices.=E2=80=9D >>>=20 >>> =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it ho= me, and then spend the rest of their time looking for things it can do=E2=80= =99, said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around.= Here you know the job, you have to find a machine that will do it. More prec= isely, you have to find software that will do the job. Finding a computer to = use the software you=E2=80=99ve selected becomes secondary.=E2=80=9D. >>>=20 >>> Do you guys* think that software drove hardware sales rather than the oth= er way around for businesses in the early days? I recall that computer hardwa= re salespeople would be knocking on businesses office doors rather than softw= are salesmen. Just seeking your opinion now that we are far ahead from 1981. >>>=20 >>> (*I do wish we have female gender engaged in the classic computing discus= sions threads as well. Maybe there is.) >>>=20 >>> Regards, >>> Tarek Hoteit >>> AI Consultant, PhD >>> +1 360-838-3675 >>>=20 --===============7451531179993201938==-- From rice43@btinternet.com Sat Apr 27 19:46:18 2024 From: Joshua Rice To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 20:46:09 +0100 Message-ID: <21dd4a9f-7f58-410b-83bb-42419da6718f@btinternet.com> In-Reply-To: <29094D76-20B7-4BF7-ACE0-22AE3C5AE53A@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2469728515513195163==" --===============2469728515513195163== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm a youngster when it comes to this hobby, being manufactured myself=20 in the early years of the 90's. As such i cannot really quote from my=20 experiences "at the time", but i have spent many an hour tinkering with=20 old machines and researching for this vintage (and modern) computing=20 hobby of mine, as well as working with some modern enterprise gear that=20 makes me, in some ways, probably quite well versed in this sort of subject. The demands for software and hardware definitely differ greatly between=20 business requirements and home user requirements. Businesses have always=20 had strict needs that must be fulfilled by the hardware they purchase,=20 namely performing the operations they require. In the "early days", this=20 might have been payroll tasks, document processing, inventory, computer=20 aided manufacturing etc. Software to perform such tasks was often=20 developed "in house", especially in the 60's, and the demands from the=20 software would often dictate what hardware was required. Remember,=20 computers were (and in some senses still are) expensive bits of kit, and=20 savings should be made where possible. Sure, you could use an IBM=20 System/360 to do manufacturing automation, but it would be much more=20 cost effective to use a PDP-8, PDP-11, or DG Nova. On the flip side,=20 that PDP-8 is not going to have the hardware support or speed to handle=20 large volumes of ASCII characters to run a flight booking system for a=20 major airline. You purchase the hardware that runs the software you=20 require. Of course, in the later years of the "early days", more=20 software was available "off the shelf", which would definitely steer=20 more purchasers to a certain platform, with the System/360 and PDP-11=20 being two notable examples of major platforms for which a multitude of=20 software was available from 3rd parties, which would have no doubt=20 bolstered their dominance. Even today, a modern rack of servers will be specced for the tasks it=20 will run. Whilst the differences are by no means what they used to be,=20 there's still no point putting a 96 core Threadripper in a machine=20 running an Exchange server for a medium sized business. Some servers=20 will be built specifically for the tasks they will run, and embedded=20 applications being a prime example of commercial gear which has to cater=20 for the software market. For the industrial and embedded market, for=20 example, a lot of software still exists and is distributed that runs on=20 MS-DOS and compatibles, requiring even modern boards to support BIOS=20 level calls, as well as ISA and PCI slots for custom hardware.=20 Industrial and embedded is a prime example of where the software needs=20 dictate the hardware solution. For some companies that /still/ rely on=20 PDP-11 gear, there are vendors out there that can interface your custom=20 QBUS and UNIBUS hardware to interact with a virtualised PDP-11 running=20 on an Intel PC box. "technical debt", as some call it, is rife in many=20 industrial sectors, and will not be fully replaced with a "modern"=20 solution for decades to come. However, lets contrast it with the home market. For most, it's not the=20 "computer you want", but the "computer you can afford". Back in the=20 "early days" (and i'm calling the early days the mid 70's here),=20 computers were still very new and novel for the home user. Those that=20 might have been used to VAXen and PDP-11's at work may have lusted after=20 one to tinker with at home, but their budget probably stretched to an=20 Altair 8800 at best. Which is great if all you're doing is tinkering=20 with it and writing some assembly yourself, as many hobbyists did. Of=20 course, each platform gained it's own following and software became=20 available, but for the home user, there was largely no "killer apps"=20 that dictated the hardware purchase. Later on in the 80's, as home=20 computers became more mature, some platforms became more powerful and=20 dominant than others, but for those that couldn't afford a top end home=20 computer, the cheaper end often sufficed. Most of the tasks that home=20 users wanted to complete (gaming, word processing, maybe some=20 spreadsheets) had software packages available for most home computing=20 systems, with lower graphical performance or computing power usually=20 correlating with what the user could afford at the time. Every system=20 had it's own quirks, and users often had to sacrifice something. Compare it to the world of modern home computing. Whether your own a=20 Macbook or Windows PC, each has competent software packages for=20 performing your tasks. In some ways, for most non-gaming tasks, the=20 platform just does not matter any more. If you're a gamer, the size of=20 your paycheck will be the biggest determining factor in your hardware=20 purchases, and whether you can support running games in 4K at 144FPS or=20 if you can access the full library of modern console titles. So in some senses, nothing has changed. Business are always worried=20 about costs, so will often buy exactly what they require, and nothing=20 more, dictated by the task it will perform. However, home users will buy=20 what they can afford, and live with the platform limitations and=20 software library available to them. Thanks for reading my TED talk, Josh Rice On 27/04/2024 18:15, Tarek Hoteit via cctalk wrote: > Do you guys* think that software drove hardware sales rather than the other= way around for businesses in the early days? I recall that computer hardware= salespeople would be knocking on businesses office doors rather than softwar= e salesmen. Just seeking your opinion now that we are far ahead from 1981. > > (*I do wish we have female gender engaged in the classic computing discus= sions threads as well. Maybe there is.) > > Regards, > Tarek Hoteit > AI Consultant, PhD > +1 360-838-3675 > --===============2469728515513195163==-- From als@thangorodrim.ch Sat Apr 27 20:00:24 2024 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Sat, 27 Apr 2024 21:49:15 +0200 Message-ID: In-Reply-To: <0e6d8e74-1ee2-42a1-97d7-035482e597ab@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1564811408677286688==" --===============1564811408677286688== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Apr 22, 2024 at 02:45:50PM -0500, Mike Katz via cctalk wrote: > Cycle accurate emulation becomes impossible in the following circumstances: > > * Branch prediction and pipelining can cause out of order execution > and the execution path become data dependent. > * Cache memory.  It can be very difficult to predict a cache flush or > cache miss or cache look aside buffer hit > * Memory management can inject wait states and cause other cycle > counting issues > * Peripherals can inject unpredictable wait states > * Multi-core processors because you don't necessarily know what core > is doing what and possibly one core waiting on another core. > * DMA can cause some CPUs to pause because the bus is busy doing DMA > transfers (not all processors have this as an issue). > * Some CPUs shut down clocks and peripherals if they are not used and > they take time to re-start. > * Any code that waits for some kind of external input. That was the reason (or so it was explained to me) why automotive ECUs stuck to relatively simple microcontrollers[0] for a long time because you could do simple cycle counting to precisely predict timing for instruction flow - getting the timing wrong for firing the spark plugs because your execution path takes 1ms longer than expected tends have Expensive Consequences (TM). Kind regards, Alex. [0] No cache, no branch prediction, no speculative execution, ... -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============1564811408677286688==-- From phb.hfx@gmail.com Sat Apr 27 20:24:22 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 17:24:13 -0300 Message-ID: <4e41486d-9adf-48ec-853a-4a7287050e91@gmail.com> In-Reply-To: =?utf-8?q?=3CMWHPR1001MB2191A2EC4A8F704CA4277B6BE4152=40MWHPR10?= =?utf-8?q?01MB2191=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9112504452007427056==" --===============9112504452007427056== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-27 2:39 p.m., Wayne S via cctalk wrote: > When you say =E2=80=9Csoftware drove hardware sales=E2=80=9D do you mean c= omplete software application systems or do you mean compilers available for t= he hardware so the software teams had variety in what they could program? > Up to the =E2=80=9890=E2=80=99s, companies had big, expensive hardware and = little to no canned software applications so companies also had relatively ch= eaper software developers to make custom programs. > > Sent from my iPhone Well I know of some systems where software sure helped with hardware=20 sales and that is with the IBM System/34 and System/36 and perhaps even=20 the System/32 before them.=C2=A0 The basic hardware in all three was similar = S/32 was single user with 64K of memory and a 10MB disk S/34 added=20 multi-user as well as more memory and storage and S/36 was an improved=20 S/34 with more speed and memory still more storage and a very user=20 friendly OS, but the big selling point was the very wide variety of=20 software available including=C2=A0 very customizable business packages such=20 as MAPICS and BPCS.=C2=A0 The hardware in these systems was to put it mildly = was unspectacular, but user friendly and available software seemed to=20 close the deal. By comparision, one time I took a call on a S/32, that a customer was=20 using long after end of support.=C2=A0 This customer also had a Data General = system that was quite a bit newer, that they had purchased because it=20 was the coolest machine at the time, but they where not using it because=20 there was no software available for it. Paul. --===============9112504452007427056==-- From paulkoning@comcast.net Sat Apr 27 20:29:27 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 16:29:19 -0400 Message-ID: In-Reply-To: <29094D76-20B7-4BF7-ACE0-22AE3C5AE53A@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7485553954476689417==" --===============7485553954476689417== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 27, 2024, at 1:15 PM, Tarek Hoteit via cctalk wrote: >=20 > I came across this paragraph from the July 1981 Popular Science magazine ed= ition in the article titled =E2=80=9CCompute power - pro models at almost hom= e-unit prices.=E2=80=9D=20 >=20 > =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it home= , and then spend the rest of their time looking for things it can do=E2=80=99= , said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around. He= re you know the job, you have to find a machine that will do it. More precise= ly, you have to find software that will do the job. Finding a computer to use= the software you=E2=80=99ve selected becomes secondary.=E2=80=9D.=20 >=20 > Do you guys* think that software drove hardware sales rather than the other= way around for businesses in the early days? I recall that computer hardware= salespeople would be knocking on businesses office doors rather than softwar= e salesmen. Just seeking your opinion now that we are far ahead from 1981.=20 Not PCs, but the first systems I worked on for DEC were turnkey PDP-11 based = systems for newspaper production. Clearly the customer wanted to publish new= spapers, and the hardware involved wasn't what drove the decision. A lot of = our competitors were specialized companies concentrating on that particular b= usiness, not computer makers. For example, arguably the top company at the t= ime (Atex, if I remember right) also used PDP-11s. That was around 1978. Also about that time, I worked with some people running a computer store in t= he LA area ("Rainbow Computing") on a proposal for a business application. T= hat was a work scheduling and routing system for hospitals, and there too the= point of it was the application needed to solve the business problem, not th= e hardware on which it would run. paul --===============7485553954476689417==-- From glg@grebus.com Sat Apr 27 21:08:22 2024 From: Gary Grebus To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 16:58:15 -0400 Message-ID: <0965480b-aa39-4f3f-94c9-c2721023889f@grebus.com> In-Reply-To: =?utf-8?q?=3CMWHPR1001MB21911203FEFC748AB4E2DC70E4152=40MWHPR10?= =?utf-8?q?01MB2191=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2156331395010208792==" --===============2156331395010208792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable By the time frame mentioned in the article (1981) there were many=20 commercially available applications. There was also hardware (e.g. from=20 DEC, DG, HP) that was of a scale where it would be dedicated to one=20 application. At that time I worked for a company that developed a=20 database system. I can think of a few trips I made to help customers=20 bring up a new data center dedicated to running our product. On 4/27/24 14:12, Wayne S via cctalk wrote: > IMHO, having started programming in 1977, the thing that drove sales was th= e promise of reduced costs just by having a computer that could be programmed= to do accounting type work that would eliminate jobs and thus costs. Mainfra= mes were very expensive back then so there weren=E2=80=99t many companies tha= t developed software just to be marketed to other companies. A lot if what wa= s sold had been developed by a company for internal use. Tgen someone got the= idea that they could recoup some development costs by selling the software. = A lot of payroll systems got started like that. Payroll was a logical starti= ng point because it was a common function within companies. > I would say that software never drove hardware sales. You had hardware alre= ady and you might try to find software that ran on it or your team programmed= it in house. I=E2=80=99ve never been to a company that found software then b= ought the hardware that it ran on. There would be too much due diligence nee= ded to make that happen. >=20 > Sent from my iPhone >=20 >> On Apr 27, 2024, at 10:41, Tarek Hoteit wrote: >> >> =EF=BB=BFHi. Meant complete software application systems, but, of course, = it is eventually powered by language compilers >> >> Regards, >> Tarek Hoteit >> AI Consultant, PhD >> +1 360-838-3675 >> >> >>> On Apr 27, 2024, at 10:39, Wayne S wrote: >>> >>> =EF=BB=BFWhen you say =E2=80=9Csoftware drove hardware sales=E2=80=9D do= you mean complete software application systems or do you mean compilers avai= lable for the hardware so the software teams had variety in what they could p= rogram? >>> Up to the =E2=80=9890=E2=80=99s, companies had big, expensive hardware an= d little to no canned software applications so companies also had relatively = cheaper software developers to make custom programs. >>> >>> Sent from my iPhone >>> >>>>> On Apr 27, 2024, at 10:23, Tarek Hoteit via cctalk wrote: >>>> >>>> =EF=BB=BFI came across this paragraph from the July 1981 Popular Science= magazine edition in the article titled =E2=80=9CCompute power - pro models a= t almost home-unit prices.=E2=80=9D >>>> >>>> =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it h= ome, and then spend the rest of their time looking for things it can do=E2=80= =99, said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around.= Here you know the job, you have to find a machine that will do it. More prec= isely, you have to find software that will do the job. Finding a computer to = use the software you=E2=80=99ve selected becomes secondary.=E2=80=9D. >>>> >>>> Do you guys* think that software drove hardware sales rather than the ot= her way around for businesses in the early days? I recall that computer hardw= are salespeople would be knocking on businesses office doors rather than soft= ware salesmen. Just seeking your opinion now that we are far ahead from 1981. >>>> >>>> (*I do wish we have female gender engaged in the classic computing discu= ssions threads as well. Maybe there is.) >>>> >>>> Regards, >>>> Tarek Hoteit >>>> AI Consultant, PhD >>>> +1 360-838-3675 >>>> --===============2156331395010208792==-- From bfranchuk@jetnet.ab.ca Sat Apr 27 22:02:53 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 16:02:36 -0600 Message-ID: <989db26f-4062-4639-a7e2-e5db9e2f76db@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5382363538840915101==" --===============5382363538840915101== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-04-27 2:29 p.m., Paul Koning via cctalk wrote: >=20 >=20 >> On Apr 27, 2024, at 1:15 PM, Tarek Hoteit via cctalk wrote: >> >> I came across this paragraph from the July 1981 Popular Science magazine e= dition in the article titled =E2=80=9CCompute power - pro models at almost ho= me-unit prices.=E2=80=9D >> >> =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it hom= e, and then spend the rest of their time looking for things it can do=E2=80= =99, said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around.= Here you know the job, you have to find a machine that will do it. More prec= isely, you have to find software that will do the job. Finding a computer to = use the software you=E2=80=99ve selected becomes secondary.=E2=80=9D. >> >> Do you guys* think that software drove hardware sales rather than the othe= r way around for businesses in the early days? I recall that computer hardwar= e salespeople would be knocking on businesses office doors rather than softwa= re salesmen. Just seeking your opinion now that we are far ahead from 1981. >=20 > Not PCs, but the first systems I worked on for DEC were turnkey PDP-11 base= d systems for newspaper production. Clearly the customer wanted to publish n= ewspapers, and the hardware involved wasn't what drove the decision. A lot o= f our competitors were specialized companies concentrating on that particular= business, not computer makers. For example, arguably the top company at the= time (Atex, if I remember right) also used PDP-11s. That was around 1978. >=20 > Also about that time, I worked with some people running a computer store in= the LA area ("Rainbow Computing") on a proposal for a business application. = That was a work scheduling and routing system for hospitals, and there too t= he point of it was the application needed to solve the business problem, not = the hardware on which it would run. >=20 > paul >=20 Did any one need REAL BCD math like the Big Boys had? --===============5382363538840915101==-- From gavin@learn.bio Sat Apr 27 22:49:03 2024 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 17:48:46 -0500 Message-ID: In-Reply-To: <29094D76-20B7-4BF7-ACE0-22AE3C5AE53A@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7363154107914719232==" --===============7363154107914719232== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 27, 2024 at 12:23=E2=80=AFPM Tarek Hoteit via cctalk wrote: > Do you guys* think that software drove hardware sales rather than the other= way around for businesses in the early days? For medium and large multi-user systems absolutely. At least once we got out of the era where there basically was no software so as a business you bought a machine and wrote your own. Which followed the era in which the machine probably didn't come with an operating system either lol. I worked as a developer / system programmer for an HP OEM from 1980-1986 or so. Our company made what would later be called ERP systems (on the HP 3000) for companies that did warehouse distribution and retail sales, etc. and covered pretty much all aspects of the business (Inventory, Order Processing, AP/AR/GL, etc., etc.). These were the days when a medium sized company may have only owned ONE central business computer that was used for practically everything. A customer would start their acquisition process for a new system by developing an RFP laying out their requirements for software (and possibly hardware capacity, features etc.) and companies like ours would respond to these and the selection process would proceed from there. Some customers started out with hardware manufacturer preferences, or quite often working with the salespeople of a hardware vendor, because if you were selling, say, VAXes, you needed the customer to be able to solve some problem in order to complete a sale and that usually meant finding a 3rd party software company who could provide the application software. So how a particular company ended up with a particular brand of hardware could have multiple explanations, but generally nobody bought a machine without having a prerequisite software solution available. It was an endless dance between hardware vendors and software houses and the potential customers. As an OEM for HP, we (on paper) resold the HP hardware to the customer along with the software, and that got us a cut of the hardware sale as well as software and any application customization (everyone wanted the system to work THEIR way, and that's how the total functionality of the software increased over time). The sales lead times for big system sales were often months long and the implementation typically would last several months as well so you ended up having a very close relationship with the customer, people working on site for weeks or months etc. There's a lot of very interesting history surrounding all of this, and it rarely gets considered in the history of medium to large systems. The applications, how the systems were used day-to-day, and the customers themselves and their interactions with the systems they ran, all have really interesting aspects. But yes, business customers bought solutions, not VAXes, or PR1MEs, or DGs, or HP 3000s, or IBM Midrange boxes. Each platform had at least a few key applications that had been developed there (usually by 3rd parties) that were what actually sold those hardware platforms. --===============7363154107914719232==-- From cisin@xenosoft.com Sat Apr 27 23:07:58 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 16:07:48 -0700 Message-ID: In-Reply-To: <0965480b-aa39-4f3f-94c9-c2721023889f@grebus.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1929078486555986183==" --===============1929078486555986183== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 27 Apr 2024, Gary Grebus via cctalk wrote: > By the time frame mentioned in the article (1981) there were many=20 > commercially available applications. There was also hardware (e.g. from DE= C,=20 > DG, HP) that was of a scale where it would be dedicated to one application.= =20 > At that time I worked for a company that developed a database system. I ca= n=20 > think of a few trips I made to help customers bring up a new data center=20 > dedicated to running our product. I consider the introduction of the IBM PC/5150 (August 1981) to be=20 significant. Although word processing was readily available, and Visicalc ran on the=20 Apple (later TRS80 versions), "home computers" didn't get any respect, and=20 were not taken seriously by business. With the introduction of the 5150, business started taking microcomputers=20 more seriously. Before that time, a tiny auto parts store, would be hard sold an=20 mini-computer, when a micro with word processing, spreadsheet, and dBase2=20 would do wuite adequately. In 1979, I was using a TRS80 in my auto repair business. And also I and a partner had a business ("Elcompco") selling hardware=20 (RAM, drives, lower-case mod, etc. and reselling software. When we split the partnership, I became "Berkeley Microcomputer", and=20 sold the auto repair business to two of my employees. After writing "XenoCopy" (1984), I renamed my company "XenoSoft". But, also, starting in 1983, I was also teaching community college=20 full-time (FORTRAN, BASIC, Microcmputer operatoing system, etc.) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============1929078486555986183==-- From gavin@learn.bio Sat Apr 27 23:14:52 2024 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 18:14:37 -0500 Message-ID: In-Reply-To: <2ed6a8a4-65ab-464b-8af5-2da59c009496@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8452166362453390906==" --===============8452166362453390906== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Apr 27, 2024 at 10:57 AM Chris Zach via cctalk wrote: > It is funny, but truth be told we dodged a massive bullet by going with > the "Internet" and TCP/IP as opposed to the nightmare of AT&T Connect, > IPX, and the blazing speeds of TWO! ISDN B channels. > > I was there. I remember X.400, and how NDS was going to be the directory > system that bound us all together in hell forever. I remember everything... > > We missed living in that crap-sack universe by six months or so. Fortunately, in the US the net wasn't run by the Post Office so the mammals were out of the bag and fruitfully multiplying long before the rest of the world caught on and started forming committees to create camel-shaped dinosaurs to perform the same functions. As a result most of those things were fairly short-term distractions for most of the internet as, for example, it quickly became evident that nobody was going to pay postage on email haha. --===============8452166362453390906==-- From cz@alembic.crystel.com Sat Apr 27 23:34:44 2024 From: Chris Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 19:34:37 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6312478633481576281==" --===============6312478633481576281== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Fortunately, in the US the net wasn't run by the Post Office so the > mammals were out of the bag and fruitfully multiplying long before the > rest of the world caught on and started forming committees to create > camel-shaped dinosaurs to perform the same functions. As a result most > of those things were fairly short-term distractions for most of the > internet as, for example, it quickly became evident that nobody was > going to pay postage on email haha. Funny you should mention that. See I met Doug Humphrey and Alan Frisbee at a fire sale in 1986 or so when we split up a set of 10 RM02 disk drives and a pile of Plessy equipment that was from a failed US Postal service contract in the early 1980's. Seems the USPS was trial building a system where you could bring a letter into a Post Office, they would scan it, then send it to another post office in MINUTES using a big packet switched network based on PDP11/23's connected to RM02's (yes, with Quuniverters).... That was the future of "Electronic mail" Post office style. I still have the docs somewhere.... Missed another bullet we did. Lot of fun stories with that one.... --===============6312478633481576281==-- From gavin@learn.bio Sat Apr 27 23:59:12 2024 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Sat, 27 Apr 2024 18:58:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6600176392539659929==" --===============6600176392539659929== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 27, 2024 at 6:34=E2=80=AFPM Chris Zach = wrote: > Seems the USPS was trial building a system where you could bring a > letter into a Post Office, they would scan it, then send it to another > post office in MINUTES using a big packet switched network based on > PDP11/23's connected to RM02's (yes, with Quuniverters).... FedEx did this for a while in '84-'86 and managed to lose $320M in the proces= s. https://en.wikipedia.org/wiki/Zapmail --===============6600176392539659929==-- From elson@pico-systems.com Sun Apr 28 01:47:07 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 20:46:55 -0500 Message-ID: In-Reply-To: <989db26f-4062-4639-a7e2-e5db9e2f76db@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4173643263110112652==" --===============4173643263110112652== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/27/24 17:02, ben via cctalk wrote: > Did any one need REAL BCD math like the Big Boys had? > > No, this is a fallacy.  Binary arithmetic is as "accurate" as decimal.  Handling VERY large numbers in floating point loses some precision, but any computer can do multiple word binary quite well.  And, the obvious example is doing division in decimal still can end up with remainders.  Back in the day, banks were terribly worried about defalcation by the guys who maintain the daily interest program.  The classic story is the guy who adjusts the code to take those fractional cents that get rounded back to the bank and sends 10% to their own account.  Now, there are so many really serious ways fraudsters can steal from banks and their customers that nobody is too worried about that sort of inside job. Jon --===============4173643263110112652==-- From cisin@xenosoft.com Sun Apr 28 02:09:57 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 19:09:51 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8268522186159202873==" --===============8268522186159202873== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> Did any one need REAL BCD math like the Big Boys had? On Sat, 27 Apr 2024, Jon Elson via cctalk wrote: > No, this is a fallacy.=C2=A0 Binary arithmetic is as "accurate" as decimal.= =C2=A0=20 > Handling VERY large numbers in floating point loses some precision, but any= =20 > computer can do multiple word binary quite well.=C2=A0 And, the obvious exa= mple=20 > is doing division in decimal still can end up with remainders.=C2=A0 Back i= n the=20 > day, banks were terribly worried about defalcation by the guys who maintain= =20 > the daily interest program.=C2=A0 The classic story is the guy who adjusts = the=20 > code to take those fractional cents that get rounded back to the bank and=20 > sends 10% to their own account.=C2=A0 Now, there are so many really serious= ways=20 > fraudsters can steal from banks and their customers that nobody is too=20 > worried about that sort of inside job. A common beginer mistake was to use floating point for money. i told my students to use a long int, and then print a period before the=20 last two digits. On the PC, I used a little decimal arithmetic in the "Sales Tax=20 Genie" TSR, but mostly, I just used AAM and DAA in binary/decima=20 conversion. How many know that AAM is a two byte instruction, with te second byte=20 beint 0Ah? Changing the second byte to 8 gave division by 8, etc. What is the smallest code to screen display a 16 bit number in hex? anything smaller than?: (I expect some clever alternatives) PUSH CX MOV CX, 0404h ; CH and CL are independent N1: ROL AX, CL PUSH AX AND AL, 0Fh DAA ADD AL, 0F0h ADC AL, 40h MOV AH, 0Eh ;displays char in AL at cursor position INT 10h POP AX DEC CH JNZ N1 PO CX -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============8268522186159202873==-- From cclist@sydex.com Sun Apr 28 02:27:24 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 19:27:14 -0700 Message-ID: <0a567be2-aa86-48b0-a768-de3a4149b37c@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4495755672486954888==" --===============4495755672486954888== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/27/24 18:46, Jon Elson via cctalk wrote: > On 4/27/24 17:02, ben via cctalk wrote: >> Did any one need REAL BCD math like the Big Boys had? >> >> > No, this is a fallacy.  Binary arithmetic is as "accurate" as decimal.  > Handling VERY large numbers in floating point loses some precision, but > any computer can do multiple word binary quite well.  And, the obvious > example is doing division in decimal still can end up with remainders.  > Back in the day, banks were terribly worried about defalcation by the > guys who maintain the daily interest program.  The classic story is the > guy who adjusts the code to take those fractional cents that get rounded > back to the bank and sends 10% to their own account.  Now, there are so > many really serious ways fraudsters can steal from banks and their > customers that nobody is too worried about that sort of inside job. The issue comes about because money is based on decimal fractional units. Were we to have 128 cents to the dollar, there would be no problem. But one-tenth in decimal is a repeating fraction in base 2. There were two ways of addressing this. The first is to do arithmetic in scaled integers and post-scaling the result. Thus, $1.00 is kept as 100 internally (COBOL would have it as pic 999..9V99). When I wrote the math package for SuperCalc, the demand was that the arithmetic be done in BCD. So that's what I did. CBASIC back in the 8080 days did its math in floating point decimal, as did a number of other BASICs. I lead a team that produced a business basic for the 8085 and x86--math was decimal. Indeed, FPGAs have be used for decimal math recently; cf.https://www.hindawi.com/journals/ijrc/2010/357839/ The NEC V-series x86 CPUs implement decimal string instructions. There's still a healthy suspicion of binary math in the finance world. --Chuck --===============4495755672486954888==-- From cclist@sydex.com Sun Apr 28 02:36:47 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 19:36:34 -0700 Message-ID: <27dd4f70-790c-44c6-b3fc-53d63624ee03@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4516564338498393278==" --===============4516564338498393278== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/27/24 19:09, Fred Cisin via cctalk wrote: > How many know that AAM is a two byte instruction, with the second byte > being 0Ah? > Changing the second byte to 8 gave division by 8, etc. Only for sure on Intel x86 processors. I believe that the NEC V20 assumes that the second byte is 0x0a and ignores the byte completely. I would not be surprised to find that other non-Intel CPUs behave the same way. --Chuck --===============4516564338498393278==-- From cclist@sydex.com Sun Apr 28 02:45:11 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 19:45:00 -0700 Message-ID: <35c97dff-5ddf-4b14-8959-bc2cae37ff6a@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0754121468316700542==" --===============0754121468316700542== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 4/27/24 19:09, Fred Cisin via cctalk wrote: > How many know that AAM is a two byte instruction, with te second byte > beint 0Ah? > Changing the second byte to 8 gave division by 8, etc. Argh! I said earlier that the NEC V20 assumed that the value of the second byte of AAM was always 0x0a. If I'dve checked my notes from 2016, I'd find that I tried this on a NEC V20 and it worked fine with other values. The "assumed" 0x0a for the V20 is apparently a rumor that nobody bothered to verify. My wetware must be leaking, if I can't remember that I checked this one out 8 years ago. --Chuck --===============0754121468316700542==-- From cisin@xenosoft.com Sun Apr 28 02:54:32 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 19:54:28 -0700 Message-ID: In-Reply-To: <27dd4f70-790c-44c6-b3fc-53d63624ee03@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1582327681702460634==" --===============1582327681702460634== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit >> How many know that AAM is a two byte instruction, with the second byte >> being 0Ah? >> Changing the second byte to 8 gave division by 8, etc. On Sat, 27 Apr 2024, Chuck Guzis via cctalk wrote: > Only for sure on Intel x86 processors. I believe that the NEC V20 > assumes that the second byte is 0x0a and ignores the byte completely. I > would not be surprised to find that other non-Intel CPUs behave the same > way. Thank you I had checked it on an NEC V20, but not on MANY other CPUs. But, there was always the possibility that something like that COULD occur at any time in the future, so I never used that in any released product. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============1582327681702460634==-- From cisin@xenosoft.com Sun Apr 28 03:21:52 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sat, 27 Apr 2024 20:21:48 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1093466800956099101==" --===============1093466800956099101== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 27 Apr 2024, Fred Cisin via cctalk wrote: > I had checked it on an NEC V20, but not on MANY other CPUs. at least, I think that it was a V20. The code that I had written to try to identify which processor was running thought that it was. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============1093466800956099101==-- From tom94022@comcast.net Sun Apr 28 19:05:57 2024 From: Tom Gardner To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Sun, 28 Apr 2024 12:05:51 -0700 Message-ID: <002d01da999f$1708e680$451ab380$@comcast.net> In-Reply-To: <29094D76-20B7-4BF7-ACE0-22AE3C5AE53A@infocom.ai> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2584858116595250324==" --===============2584858116595250324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Interesting discussion, but don't forget software was free until on June 23, = 1969, when IBM announced its unbundled offerings! The computer manufacturers= then separately priced their software but at it is what sold the hardware fo= r some time thereafter. It was, for quite some time, always safe for business to buy IBM, regardless = of price. But the 1970s represented a transition period when independent software vendo= rs starting selling software for specific machines but then thanks to Unix (?= ) across hardware. There were plug compatible computers for IBM and even DEC= . The price of the hardware was such that this was business oriented commerc= e and I think hardware drove the sales, but with specific software sometimes = being a requirement for a specific application. =20 The advent of personal computers in the late 70s made computing available to = the home but I'm not sure whether the impulse to buy was the hardware, Apple = v IBM. or software, possibly games or more likely software one needed at home= for work purposes, WordPress, VisiCalc, etc And the plug compatible PCs changed the market all again. Tom -----Original Message----- From: Tarek Hoteit =20 Sent: Saturday, April 27, 2024 10:16 AM To: cctalk(a)classiccmp.org Subject: [cctalk] PCs in home vs businesses (70s/80s) I came across this paragraph from the July 1981 Popular Science magazine edit= ion in the article titled =E2=80=9CCompute power - pro models at almost home-= unit prices.=E2=80=9D=20 =E2=80=9C =E2=80=98Personal-computer buffs may buy a machine, bring it home, = and then spend the rest of their time looking for things it can do=E2=80=99, = said =E2=80=A6. =E2=80=98In business, it=E2=80=99s the other way around. Here= you know the job, you have to find a machine that will do it. More precisely= , you have to find software that will do the job. Finding a computer to use t= he software you=E2=80=99ve selected becomes secondary.=E2=80=9D.=20 Do you guys* think that software drove hardware sales rather than the other w= ay around for businesses in the early days? I recall that computer hardware s= alespeople would be knocking on businesses office doors rather than software = salesmen. Just seeking your opinion now that we are far ahead from 1981.=20 (*I do wish we have female gender engaged in the classic computing discussio= ns threads as well. Maybe there is.)=20 Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675 --===============2584858116595250324==-- From lewissa78@gmail.com Mon Apr 29 05:59:36 2024 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 29 Apr 2024 00:59:20 -0500 Message-ID: In-Reply-To: <01T4ONTDB83U8WVYW0@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0430965679021025278==" --===============0430965679021025278== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit After learning more about the PALM processor in the IBM 5100, it has a similarity to the 6502 in that the first 128 bytes of RAM is a "register file." All its registers (R0 to R15, across 4 interrupt "layers") occupy those first addresses. In addition, they are physically on the processor itself (not in actual RAM). I've been meaning to come up with a sample PALM program that verifies if there is any performance advantage on that (that is, something that "does stuff" with data in addresses 0 to 127, then "does that same stuff" in a higher address like $800+ and see if there is a noticeable performance difference). The earliest document I can find on PALM is from 1972 (or just a few months after the 8080 - the actual initial production date of PALM is unknown, the 1972 date is just when IBM documented the instruction set). But I think the IBM System/3 had a similar design (or at least, just I recall a mention of the System/3 registers are in RAM -- not sure if that's literal or just address-access-wise, but in any case the System/3 was said to be pretty difficult to program for). Anyhow, to me the PALM may be an earlier "RISC" approach in that its instructions are always 2-bytes (4-bits for a main opcode -- yes only 16 categories, then a few bits for a "modifier" while the middle pair of bits specify a register R0 to R15 that the instruction involves), in contrast to the variable instruction length used by the System/360. There is one exception in PALM where a kind of "long jump" instruction is followed by another 2-bytes that is the target address. You won't hear much about PALM - though I am excited that emulation support for it has recently been added into MAME! I ponder if maybe Chuck Peddle somehow crossed paths with PALM in his early engineering career, or if in some indirect way there was some lineage or connection there (in a "dude, your processor doesn't need to be that complicated, I know a system that in 16 instructions does all sort of stuff" kind of way). BTW, IBM's costs list during the IBM SCAMP development put the PALM processor card costing about $300 (in c. 1973). All that said, in early 1970s, I don't think anyone was yet using the term RISC vs CISC. -Steve v* On Sun, Apr 21, 2024 at 7:50 PM Peter Coghlan via cctalk < cctalk(a)classiccmp.org> wrote: > My first exposure to a computer at home was a BBC Micro with 32kB of RAM > and > 32kB of ROM. Included in this was a 16kB BASIC ROM which was regarded as > fast > and powerful, featuring 32 bit integer variables, 40 bit floating point > variables, variable length strings, structured programming constructs and > everything accessed by keyword statements rather than PEEK this and POKE > that. > > This was implemented by a humble 6502 running at (mostly) 2MHz, with one 8 > bit > arithmetic register, two 8 bit index registers, one 8 bit stack pointer, > a 16 bit program counter and a few flag bits. > > I would have expected that a computers featuring a Z80 with its larger > register > set, 16 bit arithmetic operations, richer instruction set and general bells > and whistles would have been able to produce a much superior > implementation in > terms of speed or features or both but I never came across one. > > Why is that? Did the Z80 take more cycles to implement it's more complex > instructions? Is this an early example of RISC vs CISC? > > Regards, > Peter Coghlan > > --===============0430965679021025278==-- From julf@julf.com Mon Apr 29 06:08:18 2024 From: Johan Helsingius To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Mon, 29 Apr 2024 08:01:27 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4261626442048883380==" --===============4261626442048883380== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 28/04/2024 01:14, Gavin Scott via cctalk wrote: > Fortunately, in the US the net wasn't run by the Post Office No, but fore a very long time the phone network was run by a government-granted monopoly, Ma Bell. Hadn't the divestiture happened, AT&T had their own dinosaur ideas and would have done everything they could to enforce the output of those international committees... US was also the home of AOL and several other walled gardens. But OK, this discussion is really for the internet-history list, except it has been had so many times already... Julf --===============4261626442048883380==-- From paulkoning@comcast.net Mon Apr 29 13:25:20 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Z80 vs other microprocessors of the time. Date: Mon, 29 Apr 2024 09:25:11 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2475735318070459887==" --===============2475735318070459887== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Apr 29, 2024, at 1:59 AM, Steve Lewis via cctalk wrote: >=20 > After learning more about the PALM processor in the IBM 5100, it has a > similarity to the 6502 in that the first 128 bytes of RAM is a "register > file." All its registers (R0 to R15, across 4 interrupt "layers") occupy > those first addresses. In addition, they are physically on the processor > itself (not in actual RAM). =20 That sort of thing goes way back. There is of course the PDP-6 and PDP-10 wh= ere the 16 registers alias to the low 16 memory locations. And the notion of= registers per interrupt level also appears in the Philips PR-8000, a 24 bit = minicomputer from the 1960s aimed (among other things) at industrial control = applications. That sort of architecture makes interrupt handling very effici= ent since it eliminates state saving. Unfortunately there's very little docu= mentation of that machine anywhere; the little I found is on Bitsavers. paul --===============2475735318070459887==-- From drwho@virtadpt.net Mon Apr 29 16:12:53 2024 From: The Doctor To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Mon, 29 Apr 2024 16:12:37 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR17MB5737E5D5A2A6035257B4FE29ED152=40SA1PR17MB?= =?utf-8?q?5737=2Enamprd17=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6087998880140606884==" --===============6087998880140606884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Saturday, April 27th, 2024 at 07:14, Bill Gunshannon via cctalk wrote: > > Magazine cover january, and into 1975 the revolution. So I'd say all >=20 > I had that magazine. Wish I hadn't thrown it away oh so many > years ago. This one? https://archive.org/details/197511PopularElectronics The Doctor [412/724/301/703/415/510] WWW: https://drwho.virtadpt.net/ Don't be mean. You don't have to be mean. --===============6087998880140606884==-- From brianb1224@aol.com Mon Apr 29 16:39:35 2024 From: brianb1224 To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Mon, 29 Apr 2024 11:39:21 -0500 Message-ID: <1769739104.708702.1714408769094@aol.com> In-Reply-To: =?utf-8?q?=3CckcOUo=5FJJ0zL45oDPAuf4sOmvk4TBFVRpT-LaeIbn=5FBVQ1?= =?utf-8?q?QdipIZEi6dfjiP-8hx9t00bJ9O2Ip4k5r8pNpaY1fHH=5Fxftk6dzSg0Ovi7gPw?= =?utf-8?q?=3D=40virtadpt=2Enet=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7763667691198699446==" --===============7763667691198699446== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Me too !Also another Issue where computer company publicized their private re= searched architecture in the ad on the back page in simplified form. Woops !!! -------- Original message --------From: The Doctor via cctalk Date: 4/29/24 11:12 AM (GMT-06:00) To: "General Discussion: On-T= opic and Off-Topic Posts" Cc: The Doctor Subject: [cctalk] Re: Altair 8800 50th birthday... On Saturday, = April 27th, 2024 at 07:14, Bill Gunshannon via cctalk wrote:> > Magazine cover january, and into 1975 the revolution. So I'd say= all> > I had that magazine. Wish I hadn't thrown it away oh so many> years a= go.This one?https://archive.org/details/197511PopularElectronicsThe Doctor [4= 12/724/301/703/415/510]WWW: https://drwho.virtadpt.net/Don't be mean. You don= 't have to be mean. --===============7763667691198699446==-- From sellam.ismail@gmail.com Mon Apr 29 17:39:07 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Mon, 29 Apr 2024 10:38:49 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8761300047002048311==" --===============8761300047002048311== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Apr 27, 2024 at 11:53 AM Bill Degnan via cctalk < cctalk(a)classiccmp.org> wrote: > Magazine cover january, and into 1975 the revolution. So I'd say all > year. Not one specific date > Bill > > On Sat, Apr 27, 2024, 12:05 AM Fred Cisin via cctalk < > cctalk(a)classiccmp.org> > wrote: > > > On Fri, 26 Apr 2024, Sellam Abraham via cctalk wrote: > > > It really is a momentous event, and should be properly honored and > > > celebrated. Wow, half a century. > > > Thanks for bringing this up. > > > > Is this half a century from when they said, "Hey, you know what would be > > neat to build?" > > or from when they started designing? > > or got a preliminary design done? > > built a prototype? > > announced it? > > started taking orders? > > started filling orders? > > > > Fred > In my experience, talking with many older computer people during the earlier years that I began collecting in earnest (late 90s, early 00s), their introduction to computing came by way of buying and building an Altair 8800 kit based on the cover of the January 1975 issue of Popular Electronics, or at least being captivated by it. I call it the Big Bang of the Microcomputer Era. Sellam --===============8761300047002048311==-- From sellam.ismail@gmail.com Mon Apr 29 17:50:10 2024 From: Sellam Abraham To: cctalk@classiccmp.org Subject: [cctalk] Re: PCs in home vs businesses (70s/80s) Date: Mon, 29 Apr 2024 10:49:54 -0700 Message-ID: In-Reply-To: <21dd4a9f-7f58-410b-83bb-42419da6718f@btinternet.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1896969557848109239==" --===============1896969557848109239== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Apr 27, 2024 at 1:03 PM Joshua Rice via cctalk < cctalk(a)classiccmp.org> wrote: > I'm a youngster when it comes to this hobby, being manufactured myself > in the early years of the 90's. As such i cannot really quote from my ... > > Thanks for reading my TED talk, > > Josh Rice > Nice write-up. Sellam --===============1896969557848109239==-- From billdegnan@gmail.com Mon Apr 29 18:20:30 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Mon, 29 Apr 2024 14:20:12 -0400 Message-ID: In-Reply-To: =?utf-8?q?=3CckcOUo=5FJJ0zL45oDPAuf4sOmvk4TBFVRpT-LaeIbn=5FBVQ1?= =?utf-8?q?QdipIZEi6dfjiP-8hx9t00bJ9O2Ip4k5r8pNpaY1fHH=5Fxftk6dzSg0Ovi7gPw?= =?utf-8?q?=3D=40virtadpt=2Enet=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0573325191822455390==" --===============0573325191822455390== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Apr 29, 2024, 2:08 PM The Doctor via cctalk wrote: > > On Saturday, April 27th, 2024 at 07:14, Bill Gunshannon via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > Magazine cover january, and into 1975 the revolution. So I'd say all > > > > I had that magazine. Wish I hadn't thrown it away oh so many > > years ago. > > This one? > > https://archive.org/details/197511PopularElectronics > > The Doctor [412/724/301/703/415/510] > WWW: https://drwho.virtadpt.net/ > Don't be mean. You don't have to be mean > https://vintagecomputer.net/altair-poptronics.cfm (Jan and Feb) > --===============0573325191822455390==-- From dce@skynet.be Tue Apr 30 15:47:13 2024 From: Dominique Carlier To: cctalk@classiccmp.org Subject: [cctalk] Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 17:46:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6573125468918870841==" --===============6573125468918870841== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello everyone I need your help to identify an issue on my Diablo Model 40 Series. I don't know where to look, it's so vast ! Here's the problem: When RUN is activated, the drive begins its spin up and simultaneously deploys the heads (normal) but instead of stabilizing them, the Head Positioner receives a burst of reverse/forward micro signals. The heads "vibrate", this creates an audible frequency "BRRRRRRRRRRRRRRRRRR", and it is infinite, the heads are never loaded and the drive never reaches READY. At first I thought that perhaps the track zero sensor was defective or something of the same order but when I disengage RUN mode, the drive unloads the heads and they should be in a fixed position, here they continue to reverse/forward but more slowly than in RUN mode. Because the heads continues to mess around even in unload mode, this a priori excludes alignment problems. Here is a video of that issue: https://youtu.be/HzzxLnSdEOg Other information, if I cut the power while the drive is in RUN mode, it does not do an emergency retraction of the heads, related problem? I was hoping for a power supply problem but all the voltages and even on the main board cage seem ok (with a multimeter). If one of you had already encountered this problem of lack of head stabilization and continuous reverse/forward on this type of drive? Thanks ! Dominique --===============6573125468918870841==-- From bitwiz@12bitsbest.com Tue Apr 30 17:00:04 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 11:43:12 -0500 Message-ID: <51fb3f93-b8ec-4b0a-8a12-db7c56629d48@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0716302256643399933==" --===============0716302256643399933== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Does anybody have any extra 720K (double sided, double density) 3.5" Floppy Disks that could use a good home? If so, please email me directly at bitwiz(a)12bitsbest.com. Thank you,              Mike --===============0716302256643399933==-- From elson@pico-systems.com Tue Apr 30 17:06:06 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 12:05:56 -0500 Message-ID: <8253d8f1-9d49-df85-f4af-9108b90a66e9@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6597019243741735378==" --===============6597019243741735378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 4/30/24 10:46, Dominique Carlier via cctalk wrote: > Hello everyone > > I need your help to identify an issue on my Diablo Model > 40 Series. I don't know where to look, it's so vast ! > > Here's the problem: > When RUN is activated, the drive begins its spin up and > simultaneously deploys the heads (normal) but instead of > stabilizing them, the Head Positioner receives a burst of > reverse/forward micro signals. The heads "vibrate", this > creates an audible frequency "BRRRRRRRRRRRRRRRRRR", and it > is infinite, the heads are never loaded and the drive > never reaches READY. > > At first I thought that perhaps the track zero sensor was > defective or something of the same order but when I > disengage RUN mode, the drive unloads the heads and they > should be in a fixed position, here they continue to > reverse/forward but more slowly than in RUN mode. > Because the heads continues to mess around even in unload > mode, this a priori excludes alignment problems. Well, I don't know this particular drive, but I can think of a few things to check.  Presumably, this drive has some sort of velocity sensor, either part of the voice coil assembly or the head motion motor.  It is possible that the velocity sensor has gone bad, or that a wire to the sensor has broken. Another possibility is that the track position encoder has gone bad.  They often are quadrature optical encoders, and possibly a light bulb has failed or a photodiode has gone bad or has a broken wire or bad sensor conditioning circuit. If you have drawings for this drive, it should be easy to follow this circuit.  If not, then you will have to find drawings and tech info.  Hopefully, bitsavers has what you need. Jon --===============6597019243741735378==-- From anders.k.nelson@gmail.com Tue Apr 30 17:08:29 2024 From: Anders Nelson To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:08:13 -0400 Message-ID: In-Reply-To: <51fb3f93-b8ec-4b0a-8a12-db7c56629d48@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5196923940697208220==" --===============5196923940697208220== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Having grown up with 1.44MB 3.5" floppies, I have a question: is it possible to use a 1.44MB disk and just format it as a 720K disk? =3D] -- Anders Nelson www.andersknelson.com On Tue, Apr 30, 2024 at 1:00=E2=80=AFPM Mike Katz via cctalk wrote: > Does anybody have any extra 720K (double sided, double density) 3.5" > Floppy Disks that could use a good home? > > If so, please email me directly at bitwiz(a)12bitsbest.com. > > Thank you, > > Mike > --===============5196923940697208220==-- From rice43@btinternet.com Tue Apr 30 17:20:47 2024 From: Joshua Rice To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 18:20:40 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5149997064321466675==" --===============5149997064321466675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 30/04/2024 18:08, Anders Nelson via cctalk wrote: > Having grown up with 1.44MB 3.5" floppies, I have a question: is it > possible to use a 1.44MB disk and just format it as a 720K disk? I think it's entirely possible. I'd definitely format them in a 720kb drive though to be extra safe. Though original 720KB disks written/formatted  in 1.44MB drives seem perfectly cromulent from my experience. However don't quote me on it, The only double density drives i have are super early Sony ones built in 1982 and they get pampered with NOS 720kb media (with the sliders sellotaped open because no auto opening shutters on my drives!) Josh Rice --===============5149997064321466675==-- From dce@skynet.be Tue Apr 30 17:37:26 2024 From: Dominique Carlier To: cctalk@classiccmp.org Subject: [cctalk] Re: Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 19:37:17 +0200 Message-ID: In-Reply-To: <8253d8f1-9d49-df85-f4af-9108b90a66e9@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4521236584135548843==" --===============4521236584135548843== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks for your response Jon :! The technical documentation is available on Bitsavers here: http://www.bitsavers.org/pdf/diablo/disk/model_40/81603_Diablo4xMaint_Apr75.p= df But also here: https://www.wang2200.org/docs/external/DiabloSeries40DiskDriveFieldLevelMaint= enanceGuide.03-0057.pdf I thought like you about the sensors, but here the reverse/forward=20 movements even after unloading the heads lead me to think that the issue=20 is at the level of the circuitry involved in the control of the head=20 positionner linear motor. I would like to be able to follow the diagrams easily, but it is=20 incredibly complex. The only good news is that it is perhaps easily identifiable for those=20 who specifically know the Diablo model 40 series disc drives, in the=20 video we can observe very briefly that these reverse/forward movements=20 start as soon as I press RUN, even before the machine begins to deploy=20 the heads. Precisely here: https://youtu.be/HzzxLnSdEOg?t=3D4 We could deduce that this is a problem at the very base of what balances=20 the voltages for controlling the linear motor.But even in this case, my=20 limited skills do not allow me to direct my research, which is why I=20 need some advice ;) On 30/04/2024 19:05, Jon Elson via cctalk wrote: > On 4/30/24 10:46, Dominique Carlier via cctalk wrote: >> Hello everyone >> >> I need your help to identify an issue on my Diablo Model 40 Series. I=20 >> don't know where to look, it's so vast ! >> >> Here's the problem: >> When RUN is activated, the drive begins its spin up and=20 >> simultaneously deploys the heads (normal) but instead of stabilizing=20 >> them, the Head Positioner receives a burst of reverse/forward micro=20 >> signals. The heads "vibrate", this creates an audible frequency=20 >> "BRRRRRRRRRRRRRRRRRR", and it is infinite, the heads are never loaded=20 >> and the drive never reaches READY. >> >> At first I thought that perhaps the track zero sensor was defective=20 >> or something of the same order but when I disengage RUN mode, the=20 >> drive unloads the heads and they should be in a fixed position, here=20 >> they continue to reverse/forward but more slowly than in RUN mode. >> Because the heads continues to mess around even in unload mode, this=20 >> a priori excludes alignment problems. > > Well, I don't know this particular drive, but I can think of a few=20 > things to check.=C2=A0 Presumably, this drive has some sort of velocity=20 > sensor, either part of the voice coil assembly or the head motion=20 > motor.=C2=A0 It is possible that the velocity sensor has gone bad, or that = > a wire to the sensor has broken. > > Another possibility is that the track position encoder has gone bad.=C2=A0 = > They often are quadrature optical encoders, and possibly a light bulb=20 > has failed or a photodiode has gone bad or has a broken wire or bad=20 > sensor conditioning circuit. > > If you have drawings for this drive, it should be easy to follow this=20 > circuit.=C2=A0 If not, then you will have to find drawings and tech info.= =C2=A0=20 > Hopefully, bitsavers has what you need. > > Jon > --===============4521236584135548843==-- From organlists1@sonic.net Tue Apr 30 17:44:21 2024 From: "D. Resor" To: cctalk@classiccmp.org Subject: [cctalk] Re: Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 10:43:48 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0929735382024641022==" --===============0929735382024641022== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What is the purpose of the two microswitches seen in the upper right of the v= ideo view? =20 Could one or both of those be intermittent? Have they been tested for contin= uity/intermittence with an analog VOM? Don Resor -----Original Message----- From: Dominique Carlier via cctalk =20 Sent: Tuesday, April 30, 2024 8:47 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: Dominique Carlier Subject: [cctalk] Diablo Model 40 Series - Disturbed head positioning Hello everyone I need your help to identify an issue on my Diablo Model 40 Series. I don't k= now where to look, it's so vast ! Here's the problem: When RUN is activated, the drive begins its spin up and simultaneously deploy= s the heads (normal) but instead of stabilizing them, the Head Positioner rec= eives a burst of reverse/forward micro signals. The heads "vibrate", this cre= ates an audible frequency "BRRRRRRRRRRRRRRRRRR", and it is infinite, the head= s are never loaded and the drive never reaches READY. At first I thought that perhaps the track zero sensor was defective or someth= ing of the same order but when I disengage RUN mode, the drive unloads the he= ads and they should be in a fixed position, here they continue to reverse/for= ward but more slowly than in RUN mode. Because the heads continues to mess around even in unload mode, this a priori= excludes alignment problems. Here is a video of that issue: https://youtu.be/HzzxLnSdEOg Other information, if I cut the power while the drive is in RUN mode, it does= not do an emergency retraction of the heads, related problem? I was hoping for a power supply problem but all the voltages and even on the = main board cage seem ok (with a multimeter). If one of you had already encountered this problem of lack of head stabilizat= ion and continuous reverse/forward on this type of drive? Thanks ! Dominique --===============0929735382024641022==-- From jrr@flippers.com Tue Apr 30 17:48:46 2024 From: John Robertson To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 10:48:39 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3270042003796936797==" --===============3270042003796936797== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024/04/30 10:08 a.m., Anders Nelson via cctalk wrote: > Having grown up with 1.44MB 3.5" floppies, I have a question: is it > possible to use a 1.44MB disk and just format it as a 720K disk? > > =3D] > -- > Anders Nelson > www.andersknelson.com As I recall you had to bulk erase the old diskette and then you could=20 format it as 720 - covering the 1.44 hole of course. Not bulk erasing (the side of a Weller soldering gun works just fine)=20 led to erratic results. We all have Weller guns for fixing computers, eh? John :-#)# > > > On Tue, Apr 30, 2024 at 1:00=E2=80=AFPM Mike Katz via cctalk > wrote: > >> Does anybody have any extra 720K (double sided, double density) 3.5" >> Floppy Disks that could use a good home? >> >> If so, please email me directly at bitwiz(a)12bitsbest.com. >> >> Thank you, >> >> Mike >> --=20 John's Jukes Ltd. 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 Call (604)872-5757 (Pinballs, Jukes, Video Games) flippers.com "Old pinballers never die, they just flip out" --===============3270042003796936797==-- From barythrin@gmail.com Tue Apr 30 18:12:46 2024 From: John Herron To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:12:32 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6285159595471073608==" --===============6285159595471073608== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Apr 30, 2024, 12:48 PM John Robertson via cctalk < cctalk(a)classiccmp.org> wrote: > On 2024/04/30 10:08 a.m., Anders Nelson via cctalk wrote: > > is it > > possible to use a 1.44MB disk and just format it as a 720K disk > (Snip) > you could > format it as 720 - covering the 1.44 hole > > Yup, that's all I used to do. Some scotch tape over the floppy disk hole to make the system see it as DD. If it didn't automatically format as 720, you could specify size or sector count with format.com in dos. I did hear folks say it wasn't always reliable (similar to 5.25 disks being formated on a high density drive) but I never saw any problems in my limited use. --===============6285159595471073608==-- From bitwiz@12bitsbest.com Tue Apr 30 18:15:36 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:15:24 -0500 Message-ID: <320fa8fe-0632-4743-852e-7f3416427ec1@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4060061649367814061==" --===============4060061649367814061== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable No, this is for use in an HJP9114A HP-IL Floppy Drive. On 4/30/2024 12:08 PM, Anders Nelson via cctalk wrote: > Having grown up with 1.44MB 3.5" floppies, I have a question: is it > possible to use a 1.44MB disk and just format it as a 720K disk? > > =3D] > -- > Anders Nelson > www.andersknelson.com > > > On Tue, Apr 30, 2024 at 1:00=E2=80=AFPM Mike Katz via cctalk > wrote: > >> Does anybody have any extra 720K (double sided, double density) 3.5" >> Floppy Disks that could use a good home? >> >> If so, please email me directly at bitwiz(a)12bitsbest.com. >> >> Thank you, >> >> Mike >> --===============4060061649367814061==-- From bitwiz@12bitsbest.com Tue Apr 30 18:17:20 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:17:10 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0848675926373217336==" --===============0848675926373217336== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Bulk Erasing is the first thing I tried On 4/30/2024 12:48 PM, John Robertson via cctalk wrote: > On 2024/04/30 10:08 a.m., Anders Nelson via cctalk wrote: >> Having grown up with 1.44MB 3.5" floppies, I have a question: is it >> possible to use a 1.44MB disk and just format it as a 720K disk? >> >> =] >> -- >> Anders Nelson >> www.andersknelson.com > > As I recall you had to bulk erase the old diskette and then you could > format it as 720 - covering the 1.44 hole of course. > > Not bulk erasing (the side of a Weller soldering gun works just fine) > led to erratic results. We all have Weller guns for fixing computers, eh? > > John :-#)# > >> >> >> On Tue, Apr 30, 2024 at 1:00 PM Mike Katz via cctalk >> >> wrote: >> >>> Does anybody have any extra 720K (double sided, double density) 3.5" >>> Floppy Disks that could use a good home? >>> >>> If so, please email me directly at bitwiz(a)12bitsbest.com. >>> >>> Thank you, >>> >>>                Mike >>> > --===============0848675926373217336==-- From anders.k.nelson@gmail.com Tue Apr 30 18:18:38 2024 From: Anders Nelson To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 14:18:22 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4795654835438674664==" --===============4795654835438674664== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Ha! You mean using the transformer's magnetic field to bamboozle the media? -- Anders Nelson www.andersknelson.com On Tue, Apr 30, 2024 at 1:48 PM John Robertson via cctalk < cctalk(a)classiccmp.org> wrote: > On 2024/04/30 10:08 a.m., Anders Nelson via cctalk wrote: > > Having grown up with 1.44MB 3.5" floppies, I have a question: is it > > possible to use a 1.44MB disk and just format it as a 720K disk? > > > > =] > > -- > > Anders Nelson > > www.andersknelson.com > > As I recall you had to bulk erase the old diskette and then you could > format it as 720 - covering the 1.44 hole of course. > > Not bulk erasing (the side of a Weller soldering gun works just fine) > led to erratic results. We all have Weller guns for fixing computers, eh? > > John :-#)# > > > > > > > On Tue, Apr 30, 2024 at 1:00 PM Mike Katz via cctalk < > cctalk(a)classiccmp.org> > > wrote: > > > >> Does anybody have any extra 720K (double sided, double density) 3.5" > >> Floppy Disks that could use a good home? > >> > >> If so, please email me directly at bitwiz(a)12bitsbest.com. > >> > >> Thank you, > >> > >> Mike > >> > > -- > John's Jukes Ltd. > 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 > Call (604)872-5757 (Pinballs, Jukes, Video Games) > flippers.com > "Old pinballers never die, they just flip out" > > --===============4795654835438674664==-- From dce@skynet.be Tue Apr 30 19:21:44 2024 From: Dominique Carlier To: cctalk@classiccmp.org Subject: [cctalk] Re: Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 21:21:30 +0200 Message-ID: <9fd36e2b-ddd7-450b-b83d-92450a975106@skynet.be> In-Reply-To: <82f29131-00e6-4912-ace3-dbb4822d6079@skynet.be> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8262370953307539761==" --===============8262370953307539761== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Don ! Good suggestion, these microswitches are used to indicate that the heads are completely retracted. Unfortunately, that would have been too simple, both microswitches work perfectly :-/ On 30/04/2024 19:43, D. Resor wrote: > What is the purpose of the two microswitches seen in the upper right > of the video view? > > Could one or both of those be intermittent? Have they been tested for > continuity/intermittence with an analog VOM? > > Don Resor > > -----Original Message----- > From: Dominique Carlier via cctalk > Sent: Tuesday, April 30, 2024 8:47 AM > To: General Discussion: On-Topic and Off-Topic Posts > > Cc: Dominique Carlier > Subject: [cctalk] Diablo Model 40 Series - Disturbed head positioning > > Hello everyone > > I need your help to identify an issue on my Diablo Model 40 Series. I > don't know where to look, it's so vast ! > > Here's the problem: > When RUN is activated, the drive begins its spin up and simultaneously > deploys the heads (normal) but instead of stabilizing them, the Head > Positioner receives a burst of reverse/forward micro signals. The > heads "vibrate", this creates an audible frequency > "BRRRRRRRRRRRRRRRRRR", and it is infinite, the heads are never loaded > and the drive never reaches READY. > > At first I thought that perhaps the track zero sensor was defective or > something of the same order but when I disengage RUN mode, the drive > unloads the heads and they should be in a fixed position, here they > continue to reverse/forward but more slowly than in RUN mode. > Because the heads continues to mess around even in unload mode, this a > priori excludes alignment problems. > > Here is a video of that issue: > > https://youtu.be/HzzxLnSdEOg > > Other information, if I cut the power while the drive is in RUN mode, > it does not do an emergency retraction of the heads, related problem? > I was hoping for a power supply problem but all the voltages and even > on the main board cage seem ok (with a multimeter). > > If one of you had already encountered this problem of lack of head > stabilization and continuous reverse/forward on this type of drive? > > Thanks ! > > Dominique > --===============8262370953307539761==-- From bitwiz@12bitsbest.com Tue Apr 30 19:29:30 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:16:27 -0500 Message-ID: <5441b324-5e6f-4596-88ab-a8833b5becf4@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8884594641657032733==" --===============8884594641657032733== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I have tried bulk erasing 1.44 MB disks and they still won't format in the HP9114A battery operated HP-IL Floppy Disk drive. On 4/30/2024 12:20 PM, Joshua Rice via cctalk wrote: > On 30/04/2024 18:08, Anders Nelson via cctalk wrote: > >> Having grown up with 1.44MB 3.5" floppies, I have a question: is it >> possible to use a 1.44MB disk and just format it as a 720K disk? > > I think it's entirely possible. I'd definitely format them in a 720kb > drive though to be extra safe. Though original 720KB disks > written/formatted  in 1.44MB drives seem perfectly cromulent from my > experience. > > However don't quote me on it, The only double density drives i have > are super early Sony ones built in 1982 and they get pampered with NOS > 720kb media (with the sliders sellotaped open because no auto opening > shutters on my drives!) > > Josh Rice --===============8884594641657032733==-- From elson@pico-systems.com Tue Apr 30 19:38:27 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 14:38:20 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7819432563900998927==" --===============7819432563900998927== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/30/24 12:37, Dominique Carlier via cctalk wrote: > Thanks for your response Jon :! > > The technical documentation is available on Bitsavers here: > http://www.bitsavers.org/pdf/diablo/disk/model_40/81603_Diablo4xMaint_Apr75= .pdf=20 > > > But also here: > https://www.wang2200.org/docs/external/DiabloSeries40DiskDriveFieldLevelMai= ntenanceGuide.03-0057.pdf=20 > > > I thought like you about the sensors, but here the=20 > reverse/forward movements even after unloading the heads=20 > lead me to think that the issue is at the level of the=20 > circuitry involved in the control of the head positionner=20 > linear motor. > I would like to be able to follow the diagrams easily, but=20 > it is incredibly complex. > > The only good news is that it is perhaps easily=20 > identifiable for those who specifically know the Diablo=20 > model 40 series disc drives, in the video we can observe=20 > very briefly that these reverse/forward movements start as=20 > soon as I press RUN, even before the machine begins to=20 > deploy the heads. Precisely here: > > https://youtu.be/HzzxLnSdEOg?t=3D4 > > We could deduce that this is a problem at the very base of=20 > what balances the voltages for controlling the linear=20 > motor.But even in this case, my limited skills do not=20 > allow me to direct my research, which is why I need some=20 > advice ;) > > On 30/04/2024 19:05, Jon Elson via cctalk wrote: >> On 4/30/24 10:46, Dominique Carlier via cctalk wrote: >>> Hello everyone >>> >>> I need your help to identify an issue on my Diablo Model=20 >>> 40 Series. I don't know where to look, it's so vast ! >>> >>> Here's the problem: >>> When RUN is activated, the drive begins its spin up and=20 >>> simultaneously deploys the heads (normal) but instead of=20 >>> stabilizing them, the Head Positioner receives a burst=20 >>> of reverse/forward micro signals. The heads "vibrate",=20 >>> this creates an audible frequency "BRRRRRRRRRRRRRRRRRR",=20 >>> and it is infinite, the heads are never loaded and the=20 >>> drive never reaches READY. >>> >>> At first I thought that perhaps the track zero sensor=20 >>> was defective or something of the same order but when I=20 >>> disengage RUN mode, the drive unloads the heads and they=20 >>> should be in a fixed position, here they continue to=20 >>> reverse/forward but more slowly than in RUN mode. >>> Because the heads continues to mess around even in=20 >>> unload mode, this a priori excludes alignment problems. >> >> Well, I don't know this particular drive, but I can think=20 >> of a few things to check.=C2=A0 Presumably, this drive has=20 >> some sort of velocity sensor, either part of the voice=20 >> coil assembly or the head motion motor.=C2=A0 It is possible=20 >> that the velocity sensor has gone bad, or that a wire to=20 >> the sensor has broken. >> OK, without looking at the docs, generally these types of=20 drives have a linear amplifier that takes a velocity command=20 from some control logic and a velocity feedback signal from=20 a sensor.=C2=A0 When the run switch is turned on, the servo amp=20 might be enabled, and then the amp gets a zero velocity=20 command.=C2=A0 When the disc is up to speed, the velocity command=20 is set so that the heads load onto the pack, and then track=20 counting logic moves the heads to the desired track.=C2=A0 With=20 the heads advancing as SOON as the run switch is flipped on,=20 then it seems like the command to the amp is happening at=20 the wrong time.=C2=A0 It seems pretty clear the velocity servo is=20 working properly, as the motion looks very smooth.=C2=A0 But, the=20 heads move toward the pack, and then some kind of safety=20 circuit must be tripping as the pack is not up to speed yet. This will take some careful debugging. Jon --===============7819432563900998927==-- From wayne.sudol@hotmail.com Tue Apr 30 19:41:39 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 19:41:31 +0000 Message-ID: In-Reply-To: <5441b324-5e6f-4596-88ab-a8833b5becf4@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8635415015211428800==" --===============8635415015211428800== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What errors are you seeing? Sent from my iPhone > On Apr 30, 2024, at 12:29, Mike Katz via cctalk w= rote: >=20 > =EF=BB=BFI have tried bulk erasing 1.44 MB disks and they still won't forma= t in the HP9114A battery operated HP-IL Floppy Disk drive. >=20 >> On 4/30/2024 12:20 PM, Joshua Rice via cctalk wrote: >>> On 30/04/2024 18:08, Anders Nelson via cctalk wrote: >>>=20 >>> Having grown up with 1.44MB 3.5" floppies, I have a question: is it >>> possible to use a 1.44MB disk and just format it as a 720K disk? >>=20 >> I think it's entirely possible. I'd definitely format them in a 720kb driv= e though to be extra safe. Though original 720KB disks written/formatted in = 1.44MB drives seem perfectly cromulent from my experience. >>=20 >> However don't quote me on it, The only double density drives i have are su= per early Sony ones built in 1982 and they get pampered with NOS 720kb media = (with the sliders sellotaped open because no auto opening shutters on my driv= es!) >>=20 >> Josh Rice >=20 --===============8635415015211428800==-- From bitwiz@12bitsbest.com Tue Apr 30 20:07:07 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 15:06:58 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB218541FC99CE65BBFBF439E6E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8402067258238108886==" --===============8402067258238108886== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you for trying to help.=C2=A0 My situation is unusual at best and I'm=20 apologize for the extra bandwidth my question is causing. I am formatting the floppies in an HP-9114A battery operated floppy=20 drive connected to an HP-41 calculator over the HP_IL serial interface. The HP9114A drive uses a modified Sony 3.5" floppy drive running at 600=20 RPM instead of the normal 300 RPM.=C2=A0 This is an extremely unusual=20 configuration that is different from any PC/MAC/Commodore/Amiga situation. I have been working with floppies since 1980.=C2=A0 I have written floppy low= =20 level formatters (WD1771 & WD1791 controllers).=C2=A0 I currently use a=20 greaseweasel connected to a pair of 8" drives to create and copy=20 floppies for the RX02 on my PDP-8.=C2=A0 I fully understand about density and= =20 number of tracks, sectors per track, tracks per inch, fm/mfm/gcr=20 encoding, etc. I'm sure if I tried enough 1.44MB floppies I would find a few that might=20 work on the HP9114A drive.=C2=A0 However, that was not my question. I am looking for a dozen or two Double Sided, Double Density 720K=20 (formatted capacity) disks to use with this drive. I appreciate all of the suggestions and help but let's keep the=20 bandwidth down and take any floppy compatibility discussions off of the=20 group. Than you again everyone for offering to help, =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 Mike On 4/30/2024 2:41 PM, Wayne S wrote: > What errors are you seeing? > > > Sent from my iPhone > >> On Apr 30, 2024, at 12:29, Mike Katz via cctalk = wrote: >> >> =EF=BB=BFI have tried bulk erasing 1.44 MB disks and they still won't form= at in the HP9114A battery operated HP-IL Floppy Disk drive. >> >>> On 4/30/2024 12:20 PM, Joshua Rice via cctalk wrote: >>>> On 30/04/2024 18:08, Anders Nelson via cctalk wrote: >>>> >>>> Having grown up with 1.44MB 3.5" floppies, I have a question: is it >>>> possible to use a 1.44MB disk and just format it as a 720K disk? >>> I think it's entirely possible. I'd definitely format them in a 720kb dri= ve though to be extra safe. Though original 720KB disks written/formatted in= 1.44MB drives seem perfectly cromulent from my experience. >>> >>> However don't quote me on it, The only double density drives i have are s= uper early Sony ones built in 1982 and they get pampered with NOS 720kb media= (with the sliders sellotaped open because no auto opening shutters on my dri= ves!) >>> >>> Josh Rice --===============8402067258238108886==-- From mhs.stein@gmail.com Tue Apr 30 20:07:18 2024 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 16:07:01 -0400 Message-ID: In-Reply-To: <5441b324-5e6f-4596-88ab-a8833b5becf4@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4590621113474550068==" --===============4590621113474550068== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Should work; DD and HD are pretty similar, unlike the 5.25 versions. Did you cover the density hole? With what are you using that 9114A drive? And where are you located? I've got a couple of 9114s; I'll have to try HD disks (if I can find the drives ;-) m On Tue, Apr 30, 2024 at 3:29=E2=80=AFPM Mike Katz via cctalk wrote: > I have tried bulk erasing 1.44 MB disks and they still won't format in > the HP9114A battery operated HP-IL Floppy Disk drive. > > On 4/30/2024 12:20 PM, Joshua Rice via cctalk wrote: > > On 30/04/2024 18:08, Anders Nelson via cctalk wrote: > > > >> Having grown up with 1.44MB 3.5" floppies, I have a question: is it > >> possible to use a 1.44MB disk and just format it as a 720K disk? > > > > I think it's entirely possible. I'd definitely format them in a 720kb > > drive though to be extra safe. Though original 720KB disks > > written/formatted in 1.44MB drives seem perfectly cromulent from my > > experience. > > > > However don't quote me on it, The only double density drives i have > > are super early Sony ones built in 1982 and they get pampered with NOS > > 720kb media (with the sliders sellotaped open because no auto opening > > shutters on my drives!) > > > > Josh Rice > > --===============4590621113474550068==-- From mhs.stein@gmail.com Tue Apr 30 20:11:00 2024 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 16:10:44 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2787845122132960744==" --===============2787845122132960744== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I could probably spare a few disks, but postage from Canada is outrageous; let me know if no one else comes up with any. m On Tue, Apr 30, 2024 at 4:07=E2=80=AFPM Mike Katz via cctalk wrote: > Thank you for trying to help. My situation is unusual at best and I'm > apologize for the extra bandwidth my question is causing. > > I am formatting the floppies in an HP-9114A battery operated floppy > drive connected to an HP-41 calculator over the HP_IL serial interface. > > The HP9114A drive uses a modified Sony 3.5" floppy drive running at 600 > RPM instead of the normal 300 RPM. This is an extremely unusual > configuration that is different from any PC/MAC/Commodore/Amiga situation. > > I have been working with floppies since 1980. I have written floppy low > level formatters (WD1771 & WD1791 controllers). I currently use a > greaseweasel connected to a pair of 8" drives to create and copy > floppies for the RX02 on my PDP-8. I fully understand about density and > number of tracks, sectors per track, tracks per inch, fm/mfm/gcr > encoding, etc. > > I'm sure if I tried enough 1.44MB floppies I would find a few that might > work on the HP9114A drive. However, that was not my question. > > I am looking for a dozen or two Double Sided, Double Density 720K > (formatted capacity) disks to use with this drive. > > I appreciate all of the suggestions and help but let's keep the > bandwidth down and take any floppy compatibility discussions off of the > group. > > Than you again everyone for offering to help, > > Mike > > On 4/30/2024 2:41 PM, Wayne S wrote: > > What errors are you seeing? > > > > > > Sent from my iPhone > > > >> On Apr 30, 2024, at 12:29, Mike Katz via cctalk > wrote: > >> > >> =EF=BB=BFI have tried bulk erasing 1.44 MB disks and they still won't fo= rmat in > the HP9114A battery operated HP-IL Floppy Disk drive. > >> > >>> On 4/30/2024 12:20 PM, Joshua Rice via cctalk wrote: > >>>> On 30/04/2024 18:08, Anders Nelson via cctalk wrote: > >>>> > >>>> Having grown up with 1.44MB 3.5" floppies, I have a question: is it > >>>> possible to use a 1.44MB disk and just format it as a 720K disk? > >>> I think it's entirely possible. I'd definitely format them in a 720kb > drive though to be extra safe. Though original 720KB disks > written/formatted in 1.44MB drives seem perfectly cromulent from my > experience. > >>> > >>> However don't quote me on it, The only double density drives i have > are super early Sony ones built in 1982 and they get pampered with NOS > 720kb media (with the sliders sellotaped open because no auto opening > shutters on my drives!) > >>> > >>> Josh Rice > > --===============2787845122132960744==-- From dce@skynet.be Tue Apr 30 20:36:05 2024 From: Dominique Carlier To: cctalk@classiccmp.org Subject: [cctalk] Re: Diablo Model 40 Series - Disturbed head positioning Date: Tue, 30 Apr 2024 22:35:54 +0200 Message-ID: <55f85d19-5db9-4ae5-8d5c-d05354edef8d@skynet.be> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9000695596009653900==" --===============9000695596009653900== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I also thought about it first, but in the documentation it is clearly=20 explained that during the startup sequence, the deployment of the heads=20 is done at the same time as the spin up, during this deployment the=20 heads are raised, they are normally loaded on disc only after one minute=20 +- after the brush cycle, after the nominal speed is reached. On 30/04/2024 21:38, Jon Elson via cctalk wrote: > On 4/30/24 12:37, Dominique Carlier via cctalk wrote: >> Thanks for your response Jon :! >> >> The technical documentation is available on Bitsavers here: >> http://www.bitsavers.org/pdf/diablo/disk/model_40/81603_Diablo4xMaint_Apr7= 5.pdf=20 >> >> >> But also here: >> https://www.wang2200.org/docs/external/DiabloSeries40DiskDriveFieldLevelMa= intenanceGuide.03-0057.pdf=20 >> >> >> I thought like you about the sensors, but here the reverse/forward=20 >> movements even after unloading the heads lead me to think that the=20 >> issue is at the level of the circuitry involved in the control of the=20 >> head positionner linear motor. >> I would like to be able to follow the diagrams easily, but it is=20 >> incredibly complex. >> >> The only good news is that it is perhaps easily identifiable for=20 >> those who specifically know the Diablo model 40 series disc drives,=20 >> in the video we can observe very briefly that these reverse/forward=20 >> movements start as soon as I press RUN, even before the machine=20 >> begins to deploy the heads. Precisely here: >> >> https://youtu.be/HzzxLnSdEOg?t=3D4 >> >> We could deduce that this is a problem at the very base of what=20 >> balances the voltages for controlling the linear motor.But even in=20 >> this case, my limited skills do not allow me to direct my research,=20 >> which is why I need some advice ;) >> >> On 30/04/2024 19:05, Jon Elson via cctalk wrote: >>> On 4/30/24 10:46, Dominique Carlier via cctalk wrote: >>>> Hello everyone >>>> >>>> I need your help to identify an issue on my Diablo Model 40 Series.=20 >>>> I don't know where to look, it's so vast ! >>>> >>>> Here's the problem: >>>> When RUN is activated, the drive begins its spin up and=20 >>>> simultaneously deploys the heads (normal) but instead of=20 >>>> stabilizing them, the Head Positioner receives a burst of=20 >>>> reverse/forward micro signals. The heads "vibrate", this creates an=20 >>>> audible frequency "BRRRRRRRRRRRRRRRRRR", and it is infinite, the=20 >>>> heads are never loaded and the drive never reaches READY. >>>> >>>> At first I thought that perhaps the track zero sensor was defective=20 >>>> or something of the same order but when I disengage RUN mode, the=20 >>>> drive unloads the heads and they should be in a fixed position,=20 >>>> here they continue to reverse/forward but more slowly than in RUN=20 >>>> mode. >>>> Because the heads continues to mess around even in unload mode,=20 >>>> this a priori excludes alignment problems. >>> >>> Well, I don't know this particular drive, but I can think of a few=20 >>> things to check.=C2=A0 Presumably, this drive has some sort of velocity=20 >>> sensor, either part of the voice coil assembly or the head motion=20 >>> motor.=C2=A0 It is possible that the velocity sensor has gone bad, or=20 >>> that a wire to the sensor has broken. >>> > OK, without looking at the docs, generally these types of drives have=20 > a linear amplifier that takes a velocity command from some control=20 > logic and a velocity feedback signal from a sensor.=C2=A0 When the run=20 > switch is turned on, the servo amp might be enabled, and then the amp=20 > gets a zero velocity command.=C2=A0 When the disc is up to speed, the=20 > velocity command is set so that the heads load onto the pack, and then=20 > track counting logic moves the heads to the desired track.=C2=A0 With the=20 > heads advancing as SOON as the run switch is flipped on, then it seems=20 > like the command to the amp is happening at the wrong time.=C2=A0 It seems = > pretty clear the velocity servo is working properly, as the motion=20 > looks very smooth.=C2=A0 But, the heads move toward the pack, and then some= =20 > kind of safety circuit must be tripping as the pack is not up to speed=20 > yet. > > This will take some careful debugging. > > Jon > --===============9000695596009653900==-- From cisin@xenosoft.com Tue Apr 30 20:49:37 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:49:31 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6120136325573068795==" --===============6120136325573068795== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A 720K 3.5" is about 600 Oersted; a 1.4M 3.5" is about 720-750 Oersted. You can format a 1.4M as 720K, and often, maybe even usually, get away=20 with it; it will be just like a poor quality 720K. On drives with a media sensor, you can cover the hole during formatting. On Tue, 30 Apr 2024, Anders Nelson via cctalk wrote: > Having grown up with 1.44MB 3.5" floppies, I have a question: is it > possible to use a 1.44MB disk and just format it as a 720K disk? > > =3D] > -- > Anders Nelson > www.andersknelson.com > > > On Tue, Apr 30, 2024 at 1:00=E2=80=AFPM Mike Katz via cctalk > wrote: > >> Does anybody have any extra 720K (double sided, double density) 3.5" >> Floppy Disks that could use a good home? >> >> If so, please email me directly at bitwiz(a)12bitsbest.com. >> >> Thank you, >> >> Mike >> --===============6120136325573068795==-- From bitwiz@12bitsbest.com Tue Apr 30 20:54:36 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 15:54:26 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0427732677723227567==" --===============0427732677723227567== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thank you for your help.  This drive is not a normal drive. Please see my other answers as to why this is the case. On 4/30/2024 3:49 PM, Fred Cisin via cctalk wrote: > A 720K 3.5" is about 600 Oersted; > a 1.4M 3.5" is about 720-750 Oersted. > You can format a 1.4M as 720K, and often, maybe even usually, get away > with it; it will be just like a poor quality 720K. > On drives with a media sensor, you can cover the hole during formatting. > > > On Tue, 30 Apr 2024, Anders Nelson via cctalk wrote: > >> Having grown up with 1.44MB 3.5" floppies, I have a question: is it >> possible to use a 1.44MB disk and just format it as a 720K disk? >> >> =] >> -- >> Anders Nelson >> www.andersknelson.com >> >> >> On Tue, Apr 30, 2024 at 1:00 PM Mike Katz via cctalk >> >> wrote: >> >>> Does anybody have any extra 720K (double sided, double density) 3.5" >>> Floppy Disks that could use a good home? >>> >>> If so, please email me directly at bitwiz(a)12bitsbest.com. >>> >>> Thank you, >>> >>>               Mike >>> --===============0427732677723227567==-- From cisin@xenosoft.com Tue Apr 30 20:55:24 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 13:55:18 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3968720436362542070==" --===============3968720436362542070== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 30 Apr 2024, John Herron via cctalk wrote: > Yup, that's all I used to do. Some scotch tape over the floppy disk hole to > make the system see it as DD. If it didn't automatically format as 720, you > could specify size or sector count with format.com in dos. Somemedia sensors are optical; use opaque taps. > I did hear folks say it wasn't always reliable (similar to 5.25 disks being > formated on a high density drive) but I never saw any problems in my > limited use. 3.5" are 600 VS 750 oersted; 5.25" are 300 vs 600 Oersted; a low density 5.25 formatted as "high density" won't do well; a high density 5.25" (1.2M) formatted as low density ("360K") sill self erase VERY soon, sometimes before you can even get it over to another machine. We had a college purchasing agent in bed with "Roytype", who kept giving us "1.2M" floppies ofr out TRS80s; they self erased very soon. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============3968720436362542070==-- From wayne.sudol@hotmail.com Tue Apr 30 21:07:51 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 21:07:45 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6531256374631131797==" --===============6531256374631131797== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What kind of floppies did Hp recommend to use with this drive? Sent from my iPhone > On Apr 30, 2024, at 13:55, Fred Cisin via cctalk = wrote: >=20 > =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: >> Yup, that's all I used to do. Some scotch tape over the floppy disk hole to >> make the system see it as DD. If it didn't automatically format as 720, you >> could specify size or sector count with format.com in dos. >=20 > Somemedia sensors are optical; use opaque taps. >=20 >> I did hear folks say it wasn't always reliable (similar to 5.25 disks being >> formated on a high density drive) but I never saw any problems in my >> limited use. >=20 > 3.5" are 600 VS 750 oersted; > 5.25" are 300 vs 600 Oersted; > a low density 5.25 formatted as "high density" won't do well; > a high density 5.25" (1.2M) formatted as low density ("360K") sill self era= se VERY soon, sometimes before you can even get it over to another machine. = We had a college purchasing agent in bed with "Roytype", who kept giving us "= 1.2M" floppies ofr out TRS80s; they self erased very soon. >=20 > -- > Grumpy Ol' Fred cisin(a)xenosoft.com --===============6531256374631131797==-- From wayne.sudol@hotmail.com Tue Apr 30 21:22:10 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 21:22:03 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB218505BDB3D83C3460A1EF26E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1175555810143620396==" --===============1175555810143620396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Also this article refers to a set of commands for this drive. The NEWM comman= d formats a new disk. Link is https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read= =3D78 Sent from my iPhone On Apr 30, 2024, at 14:07, Wayne S wrote: =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? Sent from my iPhone On Apr 30, 2024, at 13:55, Fred Cisin via cctalk wr= ote: =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: Yup, that's all I used to do. Some scotch tape over the floppy disk hole to make the system see it as DD. If it didn't automatically format as 720, you could specify size or sector count with format.com in dos. Somemedia sensors are optical; use opaque taps. I did hear folks say it wasn't always reliable (similar to 5.25 disks being formated on a high density drive) but I never saw any problems in my limited use. 3.5" are 600 VS 750 oersted; 5.25" are 300 vs 600 Oersted; a low density 5.25 formatted as "high density" won't do well; a high density 5.25" (1.2M) formatted as low density ("360K") sill self erase= VERY soon, sometimes before you can even get it over to another machine. We= had a college purchasing agent in bed with "Roytype", who kept giving us "1.= 2M" floppies ofr out TRS80s; they self erased very soon. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============1175555810143620396==-- From bitwiz@12bitsbest.com Tue Apr 30 21:39:34 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 16:39:23 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185F2C990E0849FC17A29E1E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7983761609749870888==" --===============7983761609749870888== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you for your help. That is the command I am using on the 41 to try and format the disk.=C2=A0=20 With a directory size of 60. On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: > Also this article refers to a set of commands for this drive. The NEWM comm= and formats a new disk. > Link is https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read= =3D78 > > > Sent from my iPhone > > On Apr 30, 2024, at 14:07, Wayne S wrote: > > =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? > > Sent from my iPhone > > On Apr 30, 2024, at 13:55, Fred Cisin via cctalk = wrote: > > =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: > Yup, that's all I used to do. Some scotch tape over the floppy disk hole to > make the system see it as DD. If it didn't automatically format as 720, you > could specify size or sector count with format.com in dos. > > Somemedia sensors are optical; use opaque taps. > > I did hear folks say it wasn't always reliable (similar to 5.25 disks being > formated on a high density drive) but I never saw any problems in my > limited use. > > 3.5" are 600 VS 750 oersted; > 5.25" are 300 vs 600 Oersted; > a low density 5.25 formatted as "high density" won't do well; > a high density 5.25" (1.2M) formatted as low density ("360K") sill self era= se VERY soon, sometimes before you can even get it over to another machine. = We had a college purchasing agent in bed with "Roytype", who kept giving us "= 1.2M" floppies ofr out TRS80s; they self erased very soon. > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com --===============7983761609749870888==-- From wayne.sudol@hotmail.com Tue Apr 30 22:14:05 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 22:13:56 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8262144484263805771==" --===============8262144484263805771== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There is also these 2 procedures to try=E2=80=A6. From https://literature.hpc= alc.org/community/hp9114a-ms-en.pdf TheHP9114Ausesdouble-sideddiscs.Dataiswrittenonboth sides of the disc. Thus t= he normal formatting procedure is double- sided formatting. Single-sided form= atting is allowed for transferring data from older systems. See the next sect= ion for single-sided formatting. Before a flexible disc can be used for the first time, it must be formatted. = Formatting establishes the directory and volume label as wellasverifyingthatt= hemediaisnotdamaged.Shownnextare two ways to format discs. Insert a blank dis= c into the disc drive. From the P.A.M. display, pressing the =E2=80=9CFile Manager=E2=80=9D (f2) sof= tkey gets you to a =E2=80=9CFormat=E2=80=9D softkey. Press the key labeled = =E2=80=9C=E2=80=9CFormat=E2=80=9D (f5) and answer the next questions. =E2=80=9CEnter the disc to format=E2=80=9D. The first disc drive is assigned = the letter C. Type C: and press return. =E2=80=9CEnter a volume label (optional).=E2=80=9D The volume label is the na= me you want to call the disc. This can be up to 11 characters. For example, l= et=E2=80=99s call this disc =E2=80=9CFirst=E2=80=9D. Type First and press Ret= urn. The information is displayed on the first two lines below the cursor.Pressth= eStartFormatkey(f1)ifthesetwolinesarecorrect. =E2=80=9CFormatting Disc. Please wait.=E2=80=9D appears on the display. Forma= tting a disc takes about 1 1/2 minutes. The interleave used with this formatt= ingmethodis8,theoptimalforHP Portable/9114A operation. After formatting is complete, pressing the =E2=80=9C=E2=80=99Exit Format=E2= =80=9D (f8) softkey returns you to the main File Manager display. To exit Fil= e Manager press the =E2=80=9CExit File Manager=E2=80=9D softkey. This ends th= e format procedure. ThesecondmethodofformattingdiscsistousetheMSDOS Format command. From the init= ial P.A.M. display, tabbing over to the area called =E2=80=9CDOS Commands=E2= =80=9D and pressing =E2=80=9CReturn=E2=80=9D allows you to use the DOS comman= d called Format. The interleave used inthiscommand is8whichisoptimalforyourHP= Portable/9114A system. Type FORMAT C: and press Return. =E2=80=9CPress any key to begin formatting C:=E2=80=9D is displayed. Press an= y key on the keyboard. Formatting takes about 1 1/2 minutes. After formatting is complete there is another prompt on the display =E2=80=9C= =E2=80=9CVolume label (11 characters, Enter for none)?. *=E2=80=9CPress =E2= =80=9CReturn=E2=80=9Dif you don=E2=80=99t want a label or enter the name and = press =E2=80=9CReturn=E2=80=9D if you want to label the volume. When completed =E2=80=9CFormat another (Y/N)?=E2=80=9D appears on the display= . Typing =E2=80=9CN=E2=80=9D gets you back to entering MS DOS commands. Type = =E2=80=9CEXIT=E2=80=9D to return to P.A.M. Formatting Single-sided TheHPPortable/9114Asystemcanformatdouble-sideddiscsina single-sided format. T= his is allowed for data compatability with other 3 1/2-inch disc systems. The= re is a utility called =E2=80=9CFormat.Com=E2=80=9Dontheutilitydiscsuppliedwi= thyourHP Portable computer.Youmustloadthe=E2=80=9CFormat.Com=E2=80=9Dutilityi= ntoyourHP Portable. Use the following sequence. PlacetheUtilitydiscintoyourHP9114A. TabovertotheDOS Command blockandpressStar= tApplic. From theMS DOS command displaytype: COPY C: FORMAT.COM A: and press Return This loads the utility and allows you to use the extra parameters explainedin= thefollowingFORMATcommand. TheMS DOS command thatallowsthiscompatibilitywithits parameters isshown next. Format C:/W -Single-sided /X -Double-sided with 256 byte sectors /Y -Double-sided with 512 byte sectors /Z -Double-sided with 1024 byte Sent from my iPhone On Apr 30, 2024, at 14:39, Mike Katz wrote: =EF=BB=BFThank you for your help. That is the command I am using on the 41 to try and format the disk. With a = directory size of 60. On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: Also this article refers to a set of commands for this drive. The NEWM comman= d formats a new disk. Link is https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read= =3D78 Sent from my iPhone On Apr 30, 2024, at 14:07, Wayne S wrote: =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? Sent from my iPhone On Apr 30, 2024, at 13:55, Fred Cisin via cctalk wr= ote: =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: Yup, that's all I used to do. Some scotch tape over the floppy disk hole to make the system see it as DD. If it didn't automatically format as 720, you could specify size or sector count with format.com in dos. Somemedia sensors are optical; use opaque taps. I did hear folks say it wasn't always reliable (similar to 5.25 disks being formated on a high density drive) but I never saw any problems in my limited use. 3.5" are 600 VS 750 oersted; 5.25" are 300 vs 600 Oersted; a low density 5.25 formatted as "high density" won't do well; a high density 5.25" (1.2M) formatted as low density ("360K") sill self erase= VERY soon, sometimes before you can even get it over to another machine. We= had a college purchasing agent in bed with "Roytype", who kept giving us "1.= 2M" floppies ofr out TRS80s; they self erased very soon. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============8262144484263805771==-- From kantexplain@protonmail.com Tue Apr 30 22:22:12 2024 From: Just Kant To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 22:21:57 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185D57DE747F746077AEA86E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1513313587401432396==" --===============1513313587401432396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Format it more then once. That may afford additional stability. Try formatting it in a pc. Then switch over to the HP. --===============1513313587401432396==-- From wayne.sudol@hotmail.com Tue Apr 30 22:29:34 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 22:29:27 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CQ7UEJvbqAjpL2O3i13Xo0bDEuHvIT1HF0OBqYrxfkgT6=5FPDa?= =?utf-8?q?IN9Mo1QpwePsmiawQA4aOU=5FQJQxb1zGWSEzsmSCe7MvtbhCHdXdV4lb-ceE=3D?= =?utf-8?q?=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8258532695168871899==" --===============8258532695168871899== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Are these the disks you need? https://www.ebay.com/itm/303254321218?var=3D0&mkevt=3D1&mkcid=3D1&mkrid=3D711= -53200-19255-0&campid=3D5338590836&toolid=3D10044&customid=3Dbb4f007d293e1254= 33cd664c59b413a4 Sent from my iPhone On Apr 30, 2024, at 15:22, Just Kant via cctalk wro= te: =EF=BB=BFFormat it more then once. That may afford additional stability. Try formatting it in a pc. Then switch over to the HP. --===============8258532695168871899==-- From phb.hfx@gmail.com Tue Apr 30 22:35:28 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 19:35:18 -0300 Message-ID: <74414b4a-31f7-4e28-9f65-8b42c1c9c27c@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2325533601119437635==" --===============2325533601119437635== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Mike, You can get new and guaranteed recycled 720K diskettes at floppydisk.com. As you probably already know the drive in the 9114A is known to have issues with lubricants becoming gummy and the mechanism not operating properly, one particularly nasty effect is it may result in the upper head not retracting when the diskette is ejected and then gets damaged or pulled off when the diskette is removed from the drive. Paul. On 2024-04-30 5:06 p.m., Mike Katz via cctalk wrote: > Thank you for trying to help.  My situation is unusual at best and I'm > apologize for the extra bandwidth my question is causing. > > I am formatting the floppies in an HP-9114A battery operated floppy > drive connected to an HP-41 calculator over the HP_IL serial interface. > > The HP9114A drive uses a modified Sony 3.5" floppy drive running at > 600 RPM instead of the normal 300 RPM.  This is an extremely unusual > configuration that is different from any PC/MAC/Commodore/Amiga > situation. > > I have been working with floppies since 1980.  I have written floppy > low level formatters (WD1771 & WD1791 controllers).  I currently use a > greaseweasel connected to a pair of 8" drives to create and copy > floppies for the RX02 on my PDP-8.  I fully understand about density > and number of tracks, sectors per track, tracks per inch, fm/mfm/gcr > encoding, etc. > > I'm sure if I tried enough 1.44MB floppies I would find a few that > might work on the HP9114A drive.  However, that was not my question. > > I am looking for a dozen or two Double Sided, Double Density 720K > (formatted capacity) disks to use with this drive. > > I appreciate all of the suggestions and help but let's keep the > bandwidth down and take any floppy compatibility discussions off of > the group. > > Than you again everyone for offering to help, > >               Mike > > On 4/30/2024 2:41 PM, Wayne S wrote: >> What errors are you seeing? >> >> >> Sent from my iPhone >> >>> On Apr 30, 2024, at 12:29, Mike Katz via cctalk >>> wrote: >>> >>> I have tried bulk erasing 1.44 MB disks and they still won't format >>> in the HP9114A battery operated HP-IL Floppy Disk drive. >>> >>>> On 4/30/2024 12:20 PM, Joshua Rice via cctalk wrote: >>>>> On 30/04/2024 18:08, Anders Nelson via cctalk wrote: >>>>> >>>>> Having grown up with 1.44MB 3.5" floppies, I have a question: is it >>>>> possible to use a 1.44MB disk and just format it as a 720K disk? >>>> I think it's entirely possible. I'd definitely format them in a >>>> 720kb drive though to be extra safe. Though original 720KB disks >>>> written/formatted  in 1.44MB drives seem perfectly cromulent from >>>> my experience. >>>> >>>> However don't quote me on it, The only double density drives i have >>>> are super early Sony ones built in 1982 and they get pampered with >>>> NOS 720kb media (with the sliders sellotaped open because no auto >>>> opening shutters on my drives!) >>>> >>>> Josh Rice > --===============2325533601119437635==-- From bitwiz@12bitsbest.com Tue Apr 30 22:39:36 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 17:39:21 -0500 Message-ID: <65965e90-fb0b-4f9d-b9e9-d69747148740@12bitsbest.com> In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185D57DE747F746077AEA86E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2968380430471366422==" --===============2968380430471366422== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you.=C2=A0 I didn't see any new procedures that I have already tried. I do not have a problem with the drive or with trying to format a HD=20 disk with the HP-41 and therefore I was looking for a few DSDD disks=20 instead of DSHD disks. On 4/30/2024 5:13 PM, Wayne S wrote: > There is also these 2 procedures to try=E2=80=A6. From=20 > https://literature.hpcalc.org/community/hp9114a-ms-en.pdf > > > > TheHP9114Ausesdouble-sideddiscs.Dataiswrittenonboth sides of the disc.=20 > Thus the normal formatting procedure is double- sided formatting.=20 > Single-sided formatting is allowed for transferring data from older=20 > systems. See the next section for single-sided formatting. > Before a flexible disc can be used for the first time, it must be=20 > formatted. Formatting establishes the directory and volume label as=20 > wellasverifyingthatthemediaisnotdamaged.Shownnextare two ways to=20 > format discs. Insert a blank disc into the disc drive. > From the P.A.M. display, pressing the =E2=80=9CFile Manager=E2=80=9D (f2) s= oftkey gets=20 > you to a =E2=80=9CFormat=E2=80=9D softkey. Press the key labeled =E2=80=9C= =E2=80=9CFormat=E2=80=9D (f5) and=20 > answer the next questions. > =E2=80=9CEnter the disc to format=E2=80=9D. The first disc drive is assigne= d the=20 > letter C. Type C: and press return. > =E2=80=9CEnter a volume label (optional).=E2=80=9D The volume label is the = name you=20 > want to call the disc. This can be up to 11 characters. For example,=20 > let=E2=80=99s call this disc =E2=80=9CFirst=E2=80=9D. Type First and press = Return. > > =C2=A0The information is displayed on the first two lines below the=20 > cursor.PresstheStartFormatkey(f1)ifthesetwolinesarecorrect. > =E2=80=9CFormatting Disc. Please wait.=E2=80=9D appears on the display. For= matting a=20 > disc takes about 1 1/2 minutes. The interleave used with this=20 > formattingmethodis8,theoptimalforHP Portable/9114A operation. > After formatting is complete, pressing the =E2=80=9C=E2=80=99Exit Format=E2= =80=9D (f8) softkey=20 > returns you to the main File Manager display. To exit File Manager=20 > press the =E2=80=9CExit File Manager=E2=80=9D softkey. This ends the format= procedure. > ThesecondmethodofformattingdiscsistousetheMSDOS Format command. From=20 > the initial P.A.M. display, tabbing over to the area called =E2=80=9CDOS=20 > Commands=E2=80=9D and pressing =E2=80=9CReturn=E2=80=9D allows you to use t= he DOS command=20 > called Format. The interleave used inthiscommand=20 > is8whichisoptimalforyourHP Portable/9114A system. > Type FORMAT C: and press Return. > =E2=80=9CPress any key to begin formatting C:=E2=80=9D is displayed. Press = any key on=20 > the keyboard. Formatting takes about 1 1/2 minutes. > After formatting is complete there is another prompt on the display=20 > =E2=80=9C=E2=80=9CVolume label (11 characters, Enter for none)?. *=E2=80=9C= Press =E2=80=9CReturn=E2=80=9Dif=20 > you don=E2=80=99t want a label or enter the name and press =E2=80=9CReturn= =E2=80=9D if you=20 > want to label the volume. > When completed =E2=80=9CFormat another (Y/N)?=E2=80=9D appears on the displ= ay. Typing=20 > =E2=80=9CN=E2=80=9D gets you back to entering MS DOS commands. Type =E2=80= =9CEXIT=E2=80=9D to return=20 > to P.A.M. > Formatting Single-sided > TheHPPortable/9114Asystemcanformatdouble-sideddiscsina single-sided=20 > format. This is allowed for data compatability with other 3 1/2-inch=20 > disc systems. There is a utility called=20 > =E2=80=9CFormat.Com=E2=80=9DontheutilitydiscsuppliedwithyourHP Portable=20 > computer.Youmustloadthe=E2=80=9CFormat.Com=E2=80=9DutilityintoyourHP Portab= le. Use the=20 > following sequence. > PlacetheUtilitydiscintoyourHP9114A. TabovertotheDOS Command=20 > blockandpressStartApplic. > > =C2=A0From theMS DOS command displaytype: COPY C: FORMAT.COM A: and press=20 > Return > This loads the utility and allows you to use the extra parameters=20 > explainedinthefollowingFORMATcommand. > TheMS DOS command thatallowsthiscompatibilitywithits parameters=20 > isshown next. > Format C:/W -Single-sided > /X -Double-sided with 256 byte sectors > /Y -Double-sided with 512 byte sectors /Z -Double-sided with 1024 byte > > Sent from my iPhone > >> On Apr 30, 2024, at 14:39, Mike Katz wrote: >> >> =EF=BB=BFThank you for your help. >> >> That is the command I am using on the 41 to try and format the disk.=C2=A0= =20 >> With a directory size of 60. >> >> On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: >>> Also this article refers to a set of commands for this drive. The=20 >>> NEWM command formats a new disk. >>> Link is=20 >>> https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=3D78 >>> >>> >>> Sent from my iPhone >>> >>> On Apr 30, 2024, at 14:07, Wayne S wrote: >>> >>> =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? >>> >>> Sent from my iPhone >>> >>> On Apr 30, 2024, at 13:55, Fred Cisin via cctalk=20 >>> wrote: >>> >>> =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: >>> Yup, that's all I used to do. Some scotch tape over the floppy disk=20 >>> hole to >>> make the system see it as DD. If it didn't automatically format as=20 >>> 720, you >>> could specify size or sector count with format.com in dos. >>> >>> Somemedia sensors are optical; use opaque taps. >>> >>> I did hear folks say it wasn't always reliable (similar to 5.25=20 >>> disks being >>> formated on a high density drive) but I never saw any problems in my >>> limited use. >>> >>> 3.5" are 600 VS 750 oersted; >>> 5.25" are 300 vs 600 Oersted; >>> a low density 5.25 formatted as "high density" won't do well; >>> a high density 5.25" (1.2M) formatted as low density ("360K") sill=20 >>> self erase VERY soon, sometimes before you can even get it over to=20 >>> another machine. =C2=A0We had a college purchasing agent in bed with=20 >>> "Roytype", who kept giving us "1.2M" floppies ofr out TRS80s; they=20 >>> self erased very soon. >>> >>> -- >>> Grumpy Ol' Fred =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0cisin(a)xenosoft.com >> --===============2968380430471366422==-- From wayne.sudol@hotmail.com Tue Apr 30 23:15:43 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 23:15:35 +0000 Message-ID: In-Reply-To: <65965e90-fb0b-4f9d-b9e9-d69747148740@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5765258178130411127==" --===============5765258178130411127== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If it=E2=80=99s any help, i second the reformat completely a disk in a old pc= . I had some issues many years ago where disks formatted on an ibm pc didn=E2= =80=99t work correctly on a non- ibm pc. Reformatting and doing the error che= cking by reading and writing all sections fixed it. A quick format didn=E2=80= =99t.=20 There are lotsa 720k diskette=E2=80=99s available for sale=E2=80=A6 prices va= ry. Even Amazon has them!=20 Sent from my iPhone > On Apr 30, 2024, at 15:39, Mike Katz wrote: >=20 > =EF=BB=BFThank you. I didn't see any new procedures that I have already tr= ied. >=20 > I do not have a problem with the drive or with trying to format a HD disk w= ith the HP-41 and therefore I was looking for a few DSDD disks instead of DSH= D disks. >=20 >> On 4/30/2024 5:13 PM, Wayne S wrote: >> There is also these 2 procedures to try=E2=80=A6. From https://literature.= hpcalc.org/community/hp9114a-ms-en.pdf >>=20 >>=20 >>=20 >> TheHP9114Ausesdouble-sideddiscs.Dataiswrittenonboth sides of the disc. Thu= s the normal formatting procedure is double- sided formatting. Single-sided f= ormatting is allowed for transferring data from older systems. See the next s= ection for single-sided formatting. >> Before a flexible disc can be used for the first time, it must be formatte= d. Formatting establishes the directory and volume label as wellasverifyingth= atthemediaisnotdamaged.Shownnextare two ways to format discs. Insert a blank = disc into the disc drive. >> From the P.A.M. display, pressing the =E2=80=9CFile Manager=E2=80=9D (f2) = softkey gets you to a =E2=80=9CFormat=E2=80=9D softkey. Press the key labeled= =E2=80=9C=E2=80=9CFormat=E2=80=9D (f5) and answer the next questions. >> =E2=80=9CEnter the disc to format=E2=80=9D. The first disc drive is assign= ed the letter C. Type C: and press return. >> =E2=80=9CEnter a volume label (optional).=E2=80=9D The volume label is the= name you want to call the disc. This can be up to 11 characters. For example= , let=E2=80=99s call this disc =E2=80=9CFirst=E2=80=9D. Type First and press = Return. >>=20 >> The information is displayed on the first two lines below the cursor.Pres= stheStartFormatkey(f1)ifthesetwolinesarecorrect. >> =E2=80=9CFormatting Disc. Please wait.=E2=80=9D appears on the display. Fo= rmatting a disc takes about 1 1/2 minutes. The interleave used with this form= attingmethodis8,theoptimalforHP Portable/9114A operation. >> After formatting is complete, pressing the =E2=80=9C=E2=80=99Exit Format= =E2=80=9D (f8) softkey returns you to the main File Manager display. To exit = File Manager press the =E2=80=9CExit File Manager=E2=80=9D softkey. This ends= the format procedure. >> ThesecondmethodofformattingdiscsistousetheMSDOS Format command. From the i= nitial P.A.M. display, tabbing over to the area called =E2=80=9CDOS Commands= =E2=80=9D and pressing =E2=80=9CReturn=E2=80=9D allows you to use the DOS com= mand called Format. The interleave used inthiscommand is8whichisoptimalforyou= rHP Portable/9114A system. >> Type FORMAT C: and press Return. >> =E2=80=9CPress any key to begin formatting C:=E2=80=9D is displayed. Press= any key on the keyboard. Formatting takes about 1 1/2 minutes. >> After formatting is complete there is another prompt on the display =E2=80= =9C=E2=80=9CVolume label (11 characters, Enter for none)?. *=E2=80=9CPress = =E2=80=9CReturn=E2=80=9Dif you don=E2=80=99t want a label or enter the name a= nd press =E2=80=9CReturn=E2=80=9D if you want to label the volume. >> When completed =E2=80=9CFormat another (Y/N)?=E2=80=9D appears on the disp= lay. Typing =E2=80=9CN=E2=80=9D gets you back to entering MS DOS commands. Ty= pe =E2=80=9CEXIT=E2=80=9D to return to P.A.M. >> Formatting Single-sided >> TheHPPortable/9114Asystemcanformatdouble-sideddiscsina single-sided format= . This is allowed for data compatability with other 3 1/2-inch disc systems. = There is a utility called =E2=80=9CFormat.Com=E2=80=9Dontheutilitydiscsupplie= dwithyourHP Portable computer.Youmustloadthe=E2=80=9CFormat.Com=E2=80=9Dutili= tyintoyourHP Portable. Use the following sequence. >> PlacetheUtilitydiscintoyourHP9114A. TabovertotheDOS Command blockandpressS= tartApplic. >>=20 >> From theMS DOS command displaytype: COPY C: FORMAT.COM A: and press Return >> This loads the utility and allows you to use the extra parameters explaine= dinthefollowingFORMATcommand. >> TheMS DOS command thatallowsthiscompatibilitywithits parameters isshown ne= xt. >> Format C:/W -Single-sided >> /X -Double-sided with 256 byte sectors >> /Y -Double-sided with 512 byte sectors /Z -Double-sided with 1024 byte >>=20 >> Sent from my iPhone >>=20 >>>> On Apr 30, 2024, at 14:39, Mike Katz wrote: >>>=20 >>> =EF=BB=BFThank you for your help. >>>=20 >>> That is the command I am using on the 41 to try and format the disk. Wit= h a directory size of 60. >>>=20 >>> On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: >>>> Also this article refers to a set of commands for this drive. The NEWM c= ommand formats a new disk. >>>> Link is https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?r= ead=3D78 >>>>=20 >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Apr 30, 2024, at 14:07, Wayne S wrote: >>>>=20 >>>> =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>> On Apr 30, 2024, at 13:55, Fred Cisin via cctalk wrote: >>>>=20 >>>> =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: >>>> Yup, that's all I used to do. Some scotch tape over the floppy disk hole= to >>>> make the system see it as DD. If it didn't automatically format as 720, = you >>>> could specify size or sector count with format.com in dos. >>>>=20 >>>> Somemedia sensors are optical; use opaque taps. >>>>=20 >>>> I did hear folks say it wasn't always reliable (similar to 5.25 disks be= ing >>>> formated on a high density drive) but I never saw any problems in my >>>> limited use. >>>>=20 >>>> 3.5" are 600 VS 750 oersted; >>>> 5.25" are 300 vs 600 Oersted; >>>> a low density 5.25 formatted as "high density" won't do well; >>>> a high density 5.25" (1.2M) formatted as low density ("360K") sill self = erase VERY soon, sometimes before you can even get it over to another machine= . We had a college purchasing agent in bed with "Roytype", who kept giving u= s "1.2M" floppies ofr out TRS80s; they self erased very soon. >>>>=20 >>>> -- >>>> Grumpy Ol' Fred cisin(a)xenosoft.com >>>=20 >=20 --===============5765258178130411127==-- From mhs.stein@gmail.com Tue Apr 30 23:16:10 2024 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 19:15:48 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2587216993364876661==" --===============2587216993364876661== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just wondering: I see 9114 and 9114A being used interchangeably (mine are 9114s); are they the same or actually different drives? m On Tue, Apr 30, 2024 at 5:39=E2=80=AFPM Mike Katz via cctalk wrote: > Thank you for your help. > > That is the command I am using on the 41 to try and format the disk. > With a directory size of 60. > > On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: > > Also this article refers to a set of commands for this drive. The NEWM > command formats a new disk. > > Link is > https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=3D78 > > > > > > Sent from my iPhone > > > > On Apr 30, 2024, at 14:07, Wayne S wrote: > > > > =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? > > > > Sent from my iPhone > > > > On Apr 30, 2024, at 13:55, Fred Cisin via cctalk > wrote: > > > > =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: > > Yup, that's all I used to do. Some scotch tape over the floppy disk hole > to > > make the system see it as DD. If it didn't automatically format as 720, > you > > could specify size or sector count with format.com in dos. > > > > Somemedia sensors are optical; use opaque taps. > > > > I did hear folks say it wasn't always reliable (similar to 5.25 disks > being > > formated on a high density drive) but I never saw any problems in my > > limited use. > > > > 3.5" are 600 VS 750 oersted; > > 5.25" are 300 vs 600 Oersted; > > a low density 5.25 formatted as "high density" won't do well; > > a high density 5.25" (1.2M) formatted as low density ("360K") sill self > erase VERY soon, sometimes before you can even get it over to another > machine. We had a college purchasing agent in bed with "Roytype", who kept > giving us "1.2M" floppies ofr out TRS80s; they self erased very soon. > > > > -- > > Grumpy Ol' Fred cisin(a)xenosoft.com > > --===============2587216993364876661==-- From bitwiz@12bitsbest.com Tue Apr 30 23:27:29 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 18:27:15 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185610895F3B6EE2F6DF283E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8866569301456373204==" --===============8866569301456373204== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you. My goal is not to use HD floppies on a drive not designed for them. I=20 saw some on ebay and amazon but I thought I would try here to see if=20 anybody had some they don't need.=C2=A0 I would help keep them out of the tra= sh. Thank you again. On 4/30/2024 6:15 PM, Wayne S wrote: > If it=E2=80=99s any help, i second the reformat completely a disk in a old = pc. I had some issues many years ago where disks formatted on an ibm pc didn= =E2=80=99t work correctly on a non- ibm pc. Reformatting and doing the error = checking by reading and writing all sections fixed it. A quick format didn=E2= =80=99t. > There are lotsa 720k diskette=E2=80=99s available for sale=E2=80=A6 prices = vary. Even Amazon has them! > > Sent from my iPhone > >> On Apr 30, 2024, at 15:39, Mike Katz wrote: >> >> =EF=BB=BFThank you. I didn't see any new procedures that I have already t= ried. >> >> I do not have a problem with the drive or with trying to format a HD disk = with the HP-41 and therefore I was looking for a few DSDD disks instead of DS= HD disks. >> >>> On 4/30/2024 5:13 PM, Wayne S wrote: >>> There is also these 2 procedures to try=E2=80=A6. From https://literature= .hpcalc.org/community/hp9114a-ms-en.pdf >>> >>> >>> >>> TheHP9114Ausesdouble-sideddiscs.Dataiswrittenonboth sides of the disc. Th= us the normal formatting procedure is double- sided formatting. Single-sided = formatting is allowed for transferring data from older systems. See the next = section for single-sided formatting. >>> Before a flexible disc can be used for the first time, it must be formatt= ed. Formatting establishes the directory and volume label as wellasverifyingt= hatthemediaisnotdamaged.Shownnextare two ways to format discs. Insert a blank= disc into the disc drive. >>> From the P.A.M. display, pressing the =E2=80=9CFile Manager=E2=80=9D (f2= ) softkey gets you to a =E2=80=9CFormat=E2=80=9D softkey. Press the key label= ed =E2=80=9C=E2=80=9CFormat=E2=80=9D (f5) and answer the next questions. >>> =E2=80=9CEnter the disc to format=E2=80=9D. The first disc drive is assig= ned the letter C. Type C: and press return. >>> =E2=80=9CEnter a volume label (optional).=E2=80=9D The volume label is th= e name you want to call the disc. This can be up to 11 characters. For exampl= e, let=E2=80=99s call this disc =E2=80=9CFirst=E2=80=9D. Type First and press= Return. >>> >>> The information is displayed on the first two lines below the cursor.Pr= esstheStartFormatkey(f1)ifthesetwolinesarecorrect. >>> =E2=80=9CFormatting Disc. Please wait.=E2=80=9D appears on the display. F= ormatting a disc takes about 1 1/2 minutes. The interleave used with this for= mattingmethodis8,theoptimalforHP Portable/9114A operation. >>> After formatting is complete, pressing the =E2=80=9C=E2=80=99Exit Format= =E2=80=9D (f8) softkey returns you to the main File Manager display. To exit = File Manager press the =E2=80=9CExit File Manager=E2=80=9D softkey. This ends= the format procedure. >>> ThesecondmethodofformattingdiscsistousetheMSDOS Format command. From the = initial P.A.M. display, tabbing over to the area called =E2=80=9CDOS Commands= =E2=80=9D and pressing =E2=80=9CReturn=E2=80=9D allows you to use the DOS com= mand called Format. The interleave used inthiscommand is8whichisoptimalforyou= rHP Portable/9114A system. >>> Type FORMAT C: and press Return. >>> =E2=80=9CPress any key to begin formatting C:=E2=80=9D is displayed. Pres= s any key on the keyboard. Formatting takes about 1 1/2 minutes. >>> After formatting is complete there is another prompt on the display =E2= =80=9C=E2=80=9CVolume label (11 characters, Enter for none)?. *=E2=80=9CPress= =E2=80=9CReturn=E2=80=9Dif you don=E2=80=99t want a label or enter the name = and press =E2=80=9CReturn=E2=80=9D if you want to label the volume. >>> When completed =E2=80=9CFormat another (Y/N)?=E2=80=9D appears on the dis= play. Typing =E2=80=9CN=E2=80=9D gets you back to entering MS DOS commands. T= ype =E2=80=9CEXIT=E2=80=9D to return to P.A.M. >>> Formatting Single-sided >>> TheHPPortable/9114Asystemcanformatdouble-sideddiscsina single-sided forma= t. This is allowed for data compatability with other 3 1/2-inch disc systems.= There is a utility called =E2=80=9CFormat.Com=E2=80=9Dontheutilitydiscsuppli= edwithyourHP Portable computer.Youmustloadthe=E2=80=9CFormat.Com=E2=80=9Dutil= ityintoyourHP Portable. Use the following sequence. >>> PlacetheUtilitydiscintoyourHP9114A. TabovertotheDOS Command blockandpress= StartApplic. >>> >>> From theMS DOS command displaytype: COPY C: FORMAT.COM A: and press Ret= urn >>> This loads the utility and allows you to use the extra parameters explain= edinthefollowingFORMATcommand. >>> TheMS DOS command thatallowsthiscompatibilitywithits parameters isshown n= ext. >>> Format C:/W -Single-sided >>> /X -Double-sided with 256 byte sectors >>> /Y -Double-sided with 512 byte sectors /Z -Double-sided with 1024 byte >>> >>> Sent from my iPhone >>> >>>>> On Apr 30, 2024, at 14:39, Mike Katz wrote: >>>> =EF=BB=BFThank you for your help. >>>> >>>> That is the command I am using on the 41 to try and format the disk. Wi= th a directory size of 60. >>>> >>>> On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: >>>>> Also this article refers to a set of commands for this drive. The NEWM = command formats a new disk. >>>>> Link is https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?= read=3D78 >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Apr 30, 2024, at 14:07, Wayne S wrote: >>>>> >>>>> =EF=BB=BFWhat kind of floppies did Hp recommend to use with this drive? >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On Apr 30, 2024, at 13:55, Fred Cisin via cctalk wrote: >>>>> >>>>> =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: >>>>> Yup, that's all I used to do. Some scotch tape over the floppy disk hol= e to >>>>> make the system see it as DD. If it didn't automatically format as 720,= you >>>>> could specify size or sector count with format.com in dos. >>>>> >>>>> Somemedia sensors are optical; use opaque taps. >>>>> >>>>> I did hear folks say it wasn't always reliable (similar to 5.25 disks b= eing >>>>> formated on a high density drive) but I never saw any problems in my >>>>> limited use. >>>>> >>>>> 3.5" are 600 VS 750 oersted; >>>>> 5.25" are 300 vs 600 Oersted; >>>>> a low density 5.25 formatted as "high density" won't do well; >>>>> a high density 5.25" (1.2M) formatted as low density ("360K") sill self= erase VERY soon, sometimes before you can even get it over to another machin= e. We had a college purchasing agent in bed with "Roytype", who kept giving = us "1.2M" floppies ofr out TRS80s; they self erased very soon. >>>>> >>>>> -- >>>>> Grumpy Ol' Fred cisin(a)xenosoft.com --===============8866569301456373204==-- From bitwiz@12bitsbest.com Tue Apr 30 23:29:02 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 18:28:52 -0500 Message-ID: <801df173-9eea-44a1-b16a-6445141c4f7a@12bitsbest.com> In-Reply-To: =?utf-8?q?=3CDM5PR1001MB2185C1661016EC1067E6FF42E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4148297107388752869==" --===============4148297107388752869== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes but hopefully less than $45 for 10 disks. On 4/30/2024 5:29 PM, Wayne S via cctalk wrote: > Are these the disks you need? > > https://www.ebay.com/itm/303254321218?var=3D0&mkevt=3D1&mkcid=3D1&mkrid=3D7= 11-53200-19255-0&campid=3D5338590836&toolid=3D10044&customid=3Dbb4f007d293e12= 5433cd664c59b413a4 > > > Sent from my iPhone > > On Apr 30, 2024, at 15:22, Just Kant via cctalk w= rote: > > =EF=BB=BFFormat it more then once. That may afford additional stability. > > Try formatting it in a pc. Then switch over to the HP. --===============4148297107388752869==-- From bitwiz@12bitsbest.com Tue Apr 30 23:29:15 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 18:29:03 -0500 Message-ID: <65125332-e6d7-4dba-9699-e512850dabb1@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4191890602466653655==" --===============4191890602466653655== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I am not familiar with a 9114 only the 9114A and 9114B. On 4/30/2024 6:15 PM, Mike Stein wrote: > Just wondering: I see 9114 and 9114A being used interchangeably (mine > are 9114s); are they the same or actually different drives? > > m > > > On Tue, Apr 30, 2024 at 5:39 PM Mike Katz via cctalk > wrote: > > Thank you for your help. > > That is the command I am using on the 41 to try and format the disk. > With a directory size of 60. > > On 4/30/2024 4:22 PM, Wayne S via cctalk wrote: > > Also this article refers to a set of commands for this drive. > The NEWM command formats a new disk. > > Link is > https://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/articles.cgi?read=78 > > > > > > Sent from my iPhone > > > > On Apr 30, 2024, at 14:07, Wayne S wrote: > > > > What kind of floppies did Hp recommend to use with this drive? > > > > Sent from my iPhone > > > > On Apr 30, 2024, at 13:55, Fred Cisin via cctalk > wrote: > > > > On Tue, 30 Apr 2024, John Herron via cctalk wrote: > > Yup, that's all I used to do. Some scotch tape over the floppy > disk hole to > > make the system see it as DD. If it didn't automatically format > as 720, you > > could specify size or sector count with format.com > in dos. > > > > Somemedia sensors are optical; use opaque taps. > > > > I did hear folks say it wasn't always reliable (similar to 5.25 > disks being > > formated on a high density drive) but I never saw any problems in my > > limited use. > > > > 3.5" are 600 VS 750 oersted; > > 5.25" are 300 vs 600 Oersted; > > a low density 5.25 formatted as "high density" won't do well; > > a high density 5.25" (1.2M) formatted as low density ("360K") > sill self erase VERY soon, sometimes before you can even get it > over to another machine.  We had a college purchasing agent in bed > with "Roytype", who kept giving us "1.2M" floppies ofr out TRS80s; > they self erased very soon. > > > > -- > > Grumpy Ol' Fred cisin(a)xenosoft.com > --===============4191890602466653655==-- From bitwiz@12bitsbest.com Tue Apr 30 23:46:56 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 18:46:47 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CQ7UEJvbqAjpL2O3i13Xo0bDEuHvIT1HF0OBqYrxfkgT6=5FPDa?= =?utf-8?q?IN9Mo1QpwePsmiawQA4aOU=5FQJQxb1zGWSEzsmSCe7MvtbhCHdXdV4lb-ceE=3D?= =?utf-8?q?=40protonmail=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5711352564427669013==" --===============5711352564427669013== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I tried formatting multiple times (standard operating procedure).  I don't have a PC with a 3.5" floppy attached any more but I did try bulk erasing the disk first. On 4/30/2024 5:21 PM, Just Kant via cctalk wrote: > Format it more then once. That may afford additional stability. > > Try formatting it in a pc. Then switch over to the HP. --===============5711352564427669013==-- From abs@absd.org Fri May 3 08:19:10 2024 From: David Brownlee To: cctalk@classiccmp.org Subject: [cctalk] Fwd: CG14 and 16bit colour Date: Tue, 23 Apr 2024 09:05:58 +0000 Message-ID: In-Reply-To: <20240423025528.2b0010c2@bushmills> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5694051907474328653==" --===============5694051907474328653== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit In case anyone is interested in poking their cg14/sx in new and exciting ways :-p ---------- Forwarded message --------- From: Michael Date: Tue, 23 Apr 2024 at 07:55 Subject: CG14 and 16bit colour To: Hello, I did a lot of work on the cgfourteen, sx and xf86-video-suncg14 drivers, one thing I didn't expect was people asking for 8bit acceleration in X, mostly because with a 4MB cg14 you're limited to 1152x900 in 24bit colour, in 8bit you could go all the way to 1920x1200. So I wrote code for that. Looking at the headers files, it looks like at least the DAC supports 16bit colour as well, which would allow 1600x1200 in more than 8bit colour. Getting SX to deal with 16bit quantities is not difficult, at least for basic stuff like copy, fill and ROP operations. Xrender would be more difficult since there is no easy way to separate / re-unite the colour channels of a 16bit pixel. For 32bit it's trivial, SX has instructions to split 32bit accesses to four registers, even lets you pick which byte to take. So we wouldn't get xrender acceleration. Then again, we don't have that in 8bit either. The DAC is an Analog Devices ADV7152, and I just found the datasheet - in 16bit mode we get R5G5B5, nothing unusual here. That said, cg14 seems to use the DAC only for gamma correction, we don't mess with it at all even when switching to 8bit, so who knows what exactly cg14 feeds it when we set pixel mode to 16bit. Shouldn't be difficult to figure out though. I guess what I'm getting at is - does anyone particularly care about this? I don't mind doing this as yet another Just Because I Can(tm) project but if anyone cares I'd welcome their input. have fun Michael --===============5694051907474328653==-- From bduncan@beachnet.org Fri May 3 08:19:46 2024 From: Bill Duncan To: cctalk@classiccmp.org Subject: [cctalk] Re: Last Buy notification for Z80 (Z84C00 Product line) Date: Wed, 24 Apr 2024 22:35:41 +0000 Message-ID: <20240424221225.GA107722@linda> In-Reply-To: <60b5efcc-adda-4584-a91c-c49480a0e27f@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6549546096888295834==" --===============6549546096888295834== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The 6809 was my fav 8 bitter to program. Relocatable code, many addressing modes, the index registers, stack pointers, consistent instruction set.. There was a decent C compiler, Introl. It's a shame that it never really caught on. I've often wondered whether the RCA 1802 could've been considered "RISC". Lots of registers (for the time). Simple instructions executing in 1 or 1.5 cycles if I recall. LoL, it even had a "SEX" instruction.. Cheers! On Sun, Apr 21, 2024 at 10:16:32AM -0700, Chuck Guzis via cctalk wrote: > On 4/21/24 09:37, Mike Katz wrote: > > Even the 6809 could push up to 8 registers (up to 10 bytes) at once on > > one of two stacks in a single two byte instruction. > > The 6809 was introduced the same year as the 8086. The 80186, > introduced in 1982, did have the "PUSHA POPA" instructions and was > considerably faster and more complex than the 8086. As far as I could > tell, the 6809 was an evolutionary dead-end, meant to fill the gap > between the very slow 6800 and the very advanced 68000; that made the > OEMs a bit uneasy, hence its limited adoption. It was also very > expensive for an 8 bit MPU--a key criterion for adoption. > > --Chuck > > -- Bill Duncan, | http://billduncan.org/ bduncan(a)beachnet.org | - linux/unix/network/cloud +1 416 697-9315 | - performance engineering, SRE --===============6549546096888295834==-- From cz@bunsen.crystel.com Fri May 3 08:20:20 2024 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: Charles Stross, replay the bubble of 1995, alt history plus retrocomp Date: Fri, 26 Apr 2024 03:23:14 +0000 Message-ID: <659de8d0-23e4-4e43-82a1-ddbe4bd66570@bunsen.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3500787525926582546==" --===============3500787525926582546== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It is funny, but truth be told we dodged a massive bullet by going with the "Internet" and TCP/IP as opposed to the nightmare of AT&T Connect, IPX, and the blazing speeds of TWO! ISDN B channels. I was there. I remember X.400, and how NDS was going to be the directory system that bound us all together in hell forever. I remember everything... We missed living in that crap-sack universe by six months or so. CZ --===============3500787525926582546==-- From rich.cini@gmail.com Fri May 3 08:20:32 2024 From: Richard Cini To: cctalk@classiccmp.org Subject: [cctalk] Looking for Lomas docs Date: Sun, 28 Apr 2024 00:04:32 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7249050026004969747==" --===============7249050026004969747== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable All =E2=80=94 =E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82I lurk mostly on the li= st now, but I=E2=80=99m looking for a copy of the manual for the Lomas Lightn= ingOne 8086 CPU card and schematics. It doesn=E2=80=99t seem to be anywhere o= n-line so if someone has a copy they=E2=80=99d be willing to scan, it=E2=80= =99d be greatly appreciated. Thanks! Rich -- Rich Cini http://cini.classiccmp.org --===============7249050026004969747==-- From rich.cini@gmail.com Fri May 3 08:20:40 2024 From: Richard Cini To: cctalk@classiccmp.org Subject: [cctalk] Looking for Lomas board manual Date: Sun, 28 Apr 2024 02:19:31 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0225801278486670730==" --===============0225801278486670730== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable All =E2=80=94 =E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82=E2=80=82I mostly lurk on the li= st now, but I am looking for a manual for the Lomas LightningOne 8086 CPU boa= rd. There doesn=E2=80=99t seem to be a good archive of manuals for the Lomas = boards (and what=E2=80=99s out there is only partial). I have a project I=E2= =80=99m working on with Lomas boards so looking to collect info, etc. Thanks! Rich -- Rich Cini http://cini.classiccmp.org --===============0225801278486670730==-- From wayne.smith@wbd.com Fri May 3 08:21:08 2024 From: "Smith, Wayne" To: cctalk@classiccmp.org Subject: [cctalk] Re: Altair 8800 50th birthday... Date: Tue, 30 Apr 2024 18:07:27 +0000 Message-ID: In-Reply-To: <171449641220.2847341.2249230163342757483@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1234648215140079930==" --===============1234648215140079930== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I looked up the Jan. 1975 issue of Popular Electronics in the Copyright Offic= e's Periodicals Digest. It was published on Nov. 19, 1974 if you are looking= for an actual anniversary date. -W > On Saturday, April 27th, 2024 at 07:14, Bill Gunshannon via cctalk <=20 > cctalk(a)classiccmp.org> wrote: > > > > Magazine cover january, and into 1975 the revolution. So I'd say=20 > > > all > > > > I had that magazine. Wish I hadn't thrown it away oh so many years=20 > > ago. > > This one? > > https://urldefense.com/v3/__https://archive.org/details/197511PopularE > lectronics__;!!AQdq3sQhfUj4q8uUguY!jsVD6bkUUnjpF4d8AeRUKyiCW6qk8LAqFsj > dYW5cjAK-kOsMp32O4FfrPI5l1lqnTNp6sXQsHpX35FsPAzYDMIHhl-uy-NSC5w$ > > The Doctor [412/724/301/703/415/510] > WWW:=20 > https://urldefense.com/v3/__https://drwho.virtadpt.net/__;!!AQdq3sQhfU > j4q8uUguY!jsVD6bkUUnjpF4d8AeRUKyiCW6qk8LAqFsjdYW5cjAK-kOsMp32O4FfrPI5l > 1lqnTNp6sXQsHpX35FsPAzYDMIHhl-u9z1M8kw$ > Don't be mean. You don't have to be mean > https://urldefense.com/v3/__https://vintagecomputer.net/altair-poptronics.cfm= __;!!AQdq3sQhfUj4q8uUguY!jsVD6bkUUnjpF4d8AeRUKyiCW6qk8LAqFsjdYW5cjAK-kOsMp32O= 4FfrPI5l1lqnTNp6sXQsHpX35FsPAzYDMIHhl-uUDVte_w$ (Jan and Feb) --===============1234648215140079930==-- From bitwiz@12bitsbest.com Fri May 3 08:21:16 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Double Density 3.5" Floppy Disks Date: Tue, 30 Apr 2024 21:22:43 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CDM5PR1001MB218505BDB3D83C3460A1EF26E41A2=40DM5PR10?= =?utf-8?q?01MB2185=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5867547972502921338==" --===============5867547972502921338== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 4/30/2024 4:07 PM, Wayne S via cctalk wrote: > What kind of floppies did Hp recommend to use with this drive? > > Sent from my iPhone > >> On Apr 30, 2024, at 13:55, Fred Cisin via cctalk = wrote: >> >> =EF=BB=BFOn Tue, 30 Apr 2024, John Herron via cctalk wrote: >>> Yup, that's all I used to do. Some scotch tape over the floppy disk hole = to >>> make the system see it as DD. If it didn't automatically format as 720, y= ou >>> could specify size or sector count with format.com in dos. >> Somemedia sensors are optical; use opaque taps. >> >>> I did hear folks say it wasn't always reliable (similar to 5.25 disks bei= ng >>> formated on a high density drive) but I never saw any problems in my >>> limited use. >> 3.5" are 600 VS 750 oersted; >> 5.25" are 300 vs 600 Oersted; >> a low density 5.25 formatted as "high density" won't do well; >> a high density 5.25" (1.2M) formatted as low density ("360K") sill self er= ase VERY soon, sometimes before you can even get it over to another machine. = We had a college purchasing agent in bed with "Roytype", who kept giving us = "1.2M" floppies ofr out TRS80s; they self erased very soon. >> >> -- >> Grumpy Ol' Fredcisin(a)xenosoft.com --===============5867547972502921338==--