From elson@pico-systems.com Fri Nov 1 00:02:42 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Thu, 31 Oct 2024 19:02:34 -0500 Message-ID: In-Reply-To: <173038533815.4006402.1287859979364517989@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2915188471280876695==" --===============2915188471280876695== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 10/31/24 09:35, Donald Whittemore via cctalk wrote: > If I remember right I was told back in the early 70s by our IBM CE that phy= sical damage could be done to our model 30 or 40 if we ran a program that did= an Assembler instruction, B * For those non-Assembler people that is an i= nstruction to branch to the location of the instruction. I think it might ha= ve caused a heat problem in the core or CCROS or TROS. > > Possible? Or is my 76 year old brain hallucinating? Hammering a single location in core could overheat the=20 select wires, the individual cores or the select driver=20 cards.=C2=A0 I can believe this could happen.=C2=A0 I seriously doubt=20 it could harm the CCROS or TROS.=C2=A0 The model 30 was SLOW, the=20 original version (first 1000 machines) had a 2.5 us memory=20 cycle time.=C2=A0 But, a B instruction occupied 4 bytes.=C2=A0 And the=20 model 30 memory was ONE SINGLE BYTE wide!=C2=A0 So, it would have=20 to access 4 consecutive bytes over a 10 us period to read=20 the entire instruction.=C2=A0 This would involve t different=20 select wires in one axis, but likely the same wire in the=20 other axis. On the model 40, memory was 16 bits wide, so it would still=20 have to access 2 consecutive words. Anyway, I was told that on a model 40 (I think) that if you=20 pressed and held stop, system reset, and load=20 simultaneously, it would pop a component on a circuit card=20 in the machine. Jon --===============2915188471280876695==-- From sqrfolkdnc@comcast.net Fri Nov 1 04:16:23 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Thu, 31 Oct 2024 23:16:16 -0500 Message-ID: <796950032.409170.1730434576422@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7217809291971478828==" --===============7217809291971478828== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable remember, core memory is destructive read out. to read the bits you erase th= em and have to rewrite them. I doubt the B * running for 30 seconds, then cancel the job would be bad, but= if you started it up Friday and it ran all weekend? every time you demagnet= ize and re-magnetize those cores, probably an atom=20 or two gets displaced.=20 
--Carey
> On 10/31/2024 7:02 PM CDT Jon Elson via cctalk wr= ote: >=20 > =20 > On 10/31/24 09:35, Donald Whittemore via cctalk wrote: > > If I remember right I was told back in the early 70s by our IBM CE that p= hysical damage could be done to our model 30 or 40 if we ran a program that d= id an Assembler instruction, B * For those non-Assembler people that is an= instruction to branch to the location of the instruction. I think it might = have caused a heat problem in the core or CCROS or TROS. > > > > Possible? Or is my 76 year old brain hallucinating? >=20 > Hammering a single location in core could overheat the=20 > select wires, the individual cores or the select driver=20 > cards.=C2=A0 I can believe this could happen.=C2=A0 I seriously doubt=20 > it could harm the CCROS or TROS.=C2=A0 The model 30 was SLOW, the=20 > original version (first 1000 machines) had a 2.5 us memory=20 > cycle time.=C2=A0 But, a B instruction occupied 4 bytes.=C2=A0 And the=20 > model 30 memory was ONE SINGLE BYTE wide!=C2=A0 So, it would have=20 > to access 4 consecutive bytes over a 10 us period to read=20 > the entire instruction.=C2=A0 This would involve t different=20 > select wires in one axis, but likely the same wire in the=20 > other axis. >=20 > On the model 40, memory was 16 bits wide, so it would still=20 > have to access 2 consecutive words. >=20 > Anyway, I was told that on a model 40 (I think) that if you=20 > pressed and held stop, system reset, and load=20 > simultaneously, it would pop a component on a circuit card=20 > in the machine. >=20 > Jon --===============7217809291971478828==-- From jwsmail@jwsss.com Fri Nov 1 04:28:21 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Thu, 31 Oct 2024 23:28:14 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4361999703915202390==" --===============4361999703915202390== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 10/31/24 19:02, Jon Elson via cctalk wrote: > On 10/31/24 09:35, Donald Whittemore via cctalk wrote: >> If I remember right I was told back in the early 70s by our IBM CE >> that physical damage could be done to our model 30 or 40 if we ran a >> program that did an Assembler instruction, B *    For those >> non-Assembler people that is an instruction to branch to the location >> of the instruction.  I think it might have caused a heat problem in >> the core or CCROS or TROS. >> >> Possible? Or is my 76 year old brain hallucinating? > > Hammering a single location in core could overheat the select wires, > the individual cores or the select driver cards.  I can believe this > could happen.  I seriously doubt it could harm the CCROS or TROS.  The > model 30 was SLOW, the original version (first 1000 machines) had a > 2.5 us memory cycle time.  But, a B instruction occupied 4 bytes.  And > the model 30 memory was ONE SINGLE BYTE wide!  So, it would have to > access 4 consecutive bytes over a 10 us period to read the entire > instruction.  This would involve t different select wires in one axis, > but likely the same wire in the other axis. > > On the model 40, memory was 16 bits wide, so it would still have to > access 2 consecutive words. > > Anyway, I was told that on a model 40 (I think) that if you pressed > and held stop, system reset, and load simultaneously, it would pop a > component on a circuit card in the machine. > > Jon The Microdata 1600 8k memory boards, and sometimes the 16k core they had would do bad things with continuous half cycle reads. The full cycle was 1ms long and could heat up the resistors, but when you did the half cycle reads it was only 600ns long continuous and could damage the system core. It was used for rippling moves up or down of strings where you'd read a byte from somewhere in core and write it elsewhere with a pointer increment in between. The 1600 was microprogrammed, so there were no machine (macro level) instructions to do damage, so the implementer of the machine language microcode would have had to do the deed to damage the core. Or one could do it from the front panel, as one could execute micro instructions there in 'run" at full speed (200ns) speed.  There was a processor delay if you did reads like that which, so the speed would be 600ns back to back. We had a 360/50 with both 512k internal processor core and an LCS of 1mb, and neither had any restrictions on such instructions, though I don't think I know if there were hardware protections like others in this thread are suggesting. thanks Jim --===============4361999703915202390==-- From jwsmail@jwsss.com Fri Nov 1 04:36:10 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Thu, 31 Oct 2024 23:36:00 -0500 Message-ID: <3fbe2db9-8db4-4e23-a683-ee67baa20484@jwsss.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0800763091551401550==" --===============0800763091551401550== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 10/31/24 07:06, Liam Proven via cctalk wrote: > On Thu, 24 Oct 2024 at 20:24, Wayne S via cctalk = wrote: > >> They had a lot of local numbers so you didn=E2=80=99t have to pay Toll cha= rges. > Only in the USA, or maybe N America. > > Most of the world, AFAIK, we all paid for all calls, local and > long-distance. Local was cheaper but it was by the minute which really > killed off BBS type activity. The Bell system in the 70s had tolls where all but nearly local CO calls=20 were local toll rates. The Kansas City, Mo area from the 60s had mandated since it spanned a=20 state line (Missouri and Kansas) that there be a city=C2=A0 wide rate to call= =20 in about a 20 mile radius w/o toll if you paid a small fee. But some=20 people I knew in the 60s friends of the family couldn't pay that for=20 just the few calls made, so they had to pay tolls to call us from about=20 15 miles away. by the 80s there were long distance carriers who had toll plans which=20 beside long distance (continental US) being flat rate eliminated local=20 tolls as well. I know up to about 84 the Bell system was trying to get you to pay for=20 business accounts, but ended in that time frame at least in the LA area=20 after the system split up and the local "baby Bell" eliminated local=20 toll calls for businesses. My world std (Software Tool and Die) account which was the first in the=20 US to offer a unix shell account and email had a dialup service that is=20 still in existence with local non toll numbers today to get onto the=20 network via dialup. They offer 56k dialup now. I dialed in to a TSO in Columbia, Missouri, and a Multics system upto=20 the late 90s, even after I'd shifted from BBS dialup to internet email=20 and Usenet. > I had to explain this to Netscape Inc on a transatlantic call in 1996. > They had no idea. > > It persisted until the very late 1990s in the UK and Ireland. > > thanks Jim --===============0800763091551401550==-- From cctalk@ibm51xx.net Fri Nov 1 05:13:25 2024 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Dial Up was Re: Ward Christensen NY Times Obituary Date: Thu, 31 Oct 2024 22:13:17 -0700 Message-ID: <01f101db2c1c$c4687c90$4d3975b0$@net> In-Reply-To: <3fbe2db9-8db4-4e23-a683-ee67baa20484@jwsss.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2405193064605749641==" --===============2405193064605749641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > My world std (Software Tool and Die) account which was the first in the > US to offer a unix shell account and email had a dialup service that is > still in existence with local non toll numbers today to get onto the > network via dialup. Huh... This is pretty cool. I just checked them out and they have a number of= "local" numbers to me (ignoring the fact that all of the US is a local talk = on my POTS plan) including one w/ in a 5 mile radius. Called them and actuall= y got the soothing tones of a modem. I may just have to get subscription to b= e able to dial in for nostalgia sake.... And everyone could use an extra shel= l account.=20 -Ali --===============2405193064605749641==-- From barto@kdbarto.org Fri Nov 1 07:12:02 2024 From: David Barto To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Thu, 31 Oct 2024 19:27:09 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3538097235644671041==" --===============3538097235644671041== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The 6502 had a HCF (halt and catch fire) undocumented instruction.=20 I forget the opcode and if you knew what you were doing you could get the ins= truction executed on the chip using any assembler.=20 Security through obscurity back in the 70s.=20 The chip was advanced enough that the DOD wanted to avoid it falling into the= =E2=80=9Cwrong=E2=80=9D hands.=20 David Sent from iPhone Hotblack Desiato > On Oct 31, 2024, at 5:03=E2=80=AFPM, Jon Elson via cctalk wrote: >=20 > =EF=BB=BFOn 10/31/24 09:35, Donald Whittemore via cctalk wrote: >> If I remember right I was told back in the early 70s by our IBM CE that ph= ysical damage could be done to our model 30 or 40 if we ran a program that di= d an Assembler instruction, B * For those non-Assembler people that is an = instruction to branch to the location of the instruction. I think it might h= ave caused a heat problem in the core or CCROS or TROS. >>=20 >> Possible? Or is my 76 year old brain hallucinating? >=20 > Hammering a single location in core could overheat the select wires, the in= dividual cores or the select driver cards. I can believe this could happen. = I seriously doubt it could harm the CCROS or TROS. The model 30 was SLOW, t= he original version (first 1000 machines) had a 2.5 us memory cycle time. Bu= t, a B instruction occupied 4 bytes. And the model 30 memory was ONE SINGLE = BYTE wide! So, it would have to access 4 consecutive bytes over a 10 us peri= od to read the entire instruction. This would involve t different select wir= es in one axis, but likely the same wire in the other axis. >=20 > On the model 40, memory was 16 bits wide, so it would still have to access = 2 consecutive words. >=20 > Anyway, I was told that on a model 40 (I think) that if you pressed and hel= d stop, system reset, and load simultaneously, it would pop a component on a = circuit card in the machine. >=20 > Jon --===============3538097235644671041==-- From epekstrom@gmail.com Fri Nov 1 13:28:50 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: RQDX3 Formatter Date: Fri, 01 Nov 2024 09:28:34 -0400 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3137523487495671498==" --===============3137523487495671498== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Well, I learned that not all drives that look like ST-506, are... Turns out the drive I was going to use is a Micropolis 1355, which is an ESDI drive. So it won't work with the RQDX3. I guess that drive goes back on the shelf until something else comes along. Thanks for all the info on the formatter though! I'm sure I'll find something else down the road I can try that on. -Peter On Sun, Oct 27, 2024 at 5:30 PM David Gesswein via cctalk < cctalk(a)classiccmp.org> wrote: > On Sun, Oct 27, 2024 at 09:32:00AM -0400, Peter Ekstrom wrote: > > Is there such a > > thing as an MFM drive emulator that would plug in to the RQDX3 as > > a real drive would? > > > Yes. > https://www.pdp8online.com/mfm/ > --===============3137523487495671498==-- From cctalk@beyondthepale.ie Fri Nov 1 17:09:44 2024 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Fri, 01 Nov 2024 16:55:33 +0000 Message-ID: <01TC75VYWE048WVYWH@beyondthepale.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7111714120528336863==" --===============7111714120528336863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable David Barto wrote: > > The 6502 had a HCF (halt and catch fire) undocumented instruction.=20 > I forget the opcode and if you knew what you were doing you could get the i= nstruction executed on the chip using any assembler.=20 >=20 > Security through obscurity back in the 70s.=20 > The chip was advanced enough that the DOD wanted to avoid it falling into t= he =E2=80=9Cwrong=E2=80=9D hands.=20 >=20 > David >=20 > Sent from iPhone Hotblack Desiato > Did someone tell you this on April 1st? Regards, Peter Coghlan Sent from my DEC Alphaserver 800 --===============7111714120528336863==-- From barto@kdbarto.org Fri Nov 1 18:08:19 2024 From: David Barto To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Fri, 01 Nov 2024 11:01:15 -0700 Message-ID: <78C0981E-141C-4CBB-8C13-1E79B328F7DF@kdbarto.org> In-Reply-To: <01TC75VYWE048WVYWH@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8282913661206539162==" --===============8282913661206539162== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nope. Read the documentation for the chip. Turns out that the HCF instruction= basically sent the chip into an internal loop which would render parts of it= unusable after about 30-45 seconds. Tried it once and the chip got hot. Very very hot and then just stopped worki= ng. David > On Nov 1, 2024, at 9:55=E2=80=AFAM, Peter Coghlan via cctalk wrote: >=20 > David Barto wrote: >>=20 >> The 6502 had a HCF (halt and catch fire) undocumented instruction.=20 >> I forget the opcode and if you knew what you were doing you could get the = instruction executed on the chip using any assembler.=20 >>=20 >> Security through obscurity back in the 70s.=20 >> The chip was advanced enough that the DOD wanted to avoid it falling into = the =E2=80=9Cwrong=E2=80=9D hands.=20 >>=20 >> David >>=20 >> Sent from iPhone Hotblack Desiato >>=20 >=20 > Did someone tell you this on April 1st? >=20 > Regards, > Peter Coghlan >=20 > Sent from my DEC Alphaserver 800 There is nothing more difficult to carry out, nor more doubtful of success, nor more dangerous to handle, than to initiate a new order of things. For the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new... --Niccolo Macchiavelli, The Prince David Barto barto(a)kdbarto.org --===============8282913661206539162==-- From van.snyder@sbcglobal.net Fri Nov 1 18:12:32 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Fri, 01 Nov 2024 11:12:24 -0700 Message-ID: <70e3c3f73c1ef4fd904960e67d0fce70e0aefd3f.camel@sbcglobal.net> In-Reply-To: <78C0981E-141C-4CBB-8C13-1E79B328F7DF@kdbarto.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6289333904443195557==" --===============6289333904443195557== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2024-11-01 at 11:01 -0700, David Barto via cctalk wrote: > > > The 6502 had a HCF (halt and catch fire) undocumented > > > instruction. > > > I forget the opcode and if you knew what you were doing you could > > > get the instruction executed on the chip using any assembler. Early in 1965 Caltech installed one of only a few 360/63 computers. After they installed it, they discovered that the default instruction when it started up was HCF. It was replaced with a 360/67. --===============6289333904443195557==-- From sqrfolkdnc@comcast.net Fri Nov 1 19:38:18 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] undocumented instructions including HCF [was: System 360 question] Date: Fri, 01 Nov 2024 14:37:45 -0500 Message-ID: <154844328.426723.1730489865178@connect.xfinity.com> In-Reply-To: <01TC75VYWE048WVYWH@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8229573237997974389==" --===============8229573237997974389== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I had remembered the HCF as being a z-80 thing, so I searched for it. All I can find says it was 6800, not 6502. https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing) http://www.ffd2.com/fridge/docs/6502-NMOS.extra.opcodes http://www.z80.info/zip/z80-documented.pdf New question: what do emulators do with these undocumented instructions? I s= eem to recall in the 8086 (?) family tree, some clone cpu chips had actually= useful instructions. =20 
--Carey
> On 11/01/2024 11:55 AM CDT Peter Coghlan via cctalk wrote: >=20 > =20 > David Barto wrote: > > > > The 6502 had a HCF (halt and catch fire) undocumented instruction.=20 > > I forget the opcode and if you knew what you were doing you could get the= instruction executed on the chip using any assembler.=20 > >=20 > > Security through obscurity back in the 70s.=20 > > The chip was advanced enough that the DOD wanted to avoid it falling into= the =E2=80=9Cwrong=E2=80=9D hands.=20 > >=20 > > David > >=20 > > Sent from iPhone Hotblack Desiato > > >=20 > Did someone tell you this on April 1st? >=20 > Regards, > Peter Coghlan >=20 > Sent from my DEC Alphaserver 800 --===============8229573237997974389==-- From sqrfolkdnc@comcast.net Fri Nov 1 19:55:56 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Fri, 01 Nov 2024 14:55:29 -0500 Message-ID: <1966301344.427479.1730490929459@connect.xfinity.com> In-Reply-To: <70e3c3f73c1ef4fd904960e67d0fce70e0aefd3f.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2639527177444314715==" --===============2639527177444314715== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Wikipedia lists models 60, 62, 64, and 66 (never shipped) and 65 and 67 as shipped, but no 63. =20 since I don't remember 65s, I assume not many of them made it out the door? https://en.wikipedia.org/wiki/IBM_System/360 
--Carey
> On 11/01/2024 1:12 PM CDT Van Snyder via cctalk w= rote: >=20 > =20 > On Fri, 2024-11-01 at 11:01 -0700, David Barto via cctalk wrote: > > > > The 6502 had a HCF (halt and catch fire) undocumented > > > > instruction.=20 > > > > I forget the opcode and if you knew what you were doing you could > > > > get the instruction executed on the chip using any assembler.=20 >=20 > Early in 1965 Caltech installed one of only a few 360/63 computers. > After they installed it, they discovered that the default instruction > when it started up was HCF. It was replaced with a 360/67. --===============2639527177444314715==-- From elson@pico-systems.com Fri Nov 1 20:27:02 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Fri, 01 Nov 2024 15:26:56 -0500 Message-ID: <48a0ce4c-849d-1105-1e68-b7515eb1611f@pico-systems.com> In-Reply-To: <1966301344.427479.1730490929459@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6747257679035578363==" --===============6747257679035578363== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/1/24 14:55, CAREY SCHUG via cctalk wrote: > Wikipedia lists models 60, 62, 64, and 66 (never shipped) > and 65 and 67 as shipped, but no 63. > > since I don't remember 65s, I assume not many of them made it out the door? > Uh, no.  The 360/65 was a very popular model, QUITE (4X) a step up from the 360/50.  The /67 was a variant  of the /65, which had an address translator feature pretty identical to what was used in the later 370/168 for demand-paged virtual memory.  The model 65 also allowed two processors to run from shared memory.  This was called the MP65.  The model /60 was only produced for a short time, it was replaced with the model /65. There is a picture of the /65 console in the Wikipedia article. Also, a variant of the 360/65 was part of the FAA's air traffic control computer complexes.  They were called a model 9020. Jon --===============6747257679035578363==-- From julf@julf.com Fri Nov 1 20:42:31 2024 From: Johan Helsingius To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Fri, 01 Nov 2024 21:33:31 +0100 Message-ID: <9e266207-b27a-4e91-a9bf-a755933428db@Julf.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0426427028395595464==" --===============0426427028395595464== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable UNIX might have been unobtainium in your home, but a lot of BBS's used UUCP to get email and USENET connectivity, and a huge amount of students had modem access to an UNIX computer at their university. Julf On 10/24/24 04:36, Doug Jackson via cctalk wrote: > Yes, UUCP was literally a thing, but UNIX was unobtanium in the early > computing eral - The world of the University Minicomputer. >=20 > It certainly wasn't even vaguely accessible by a hobbyist running a > Z80 or 6800 in the late 70's. >=20 > I vividly remember being able to take home a NEC 80386 computer from > my day job (I worked for a computer store selling NEC machines) during > the Christmas shutdown between 1987/1988 - It had SCO Xenix installed > and a new graphical system (To SCO) called 'XWindows' Unheard of - I > did a heap of learning. >=20 > That was probably the point where a UNIX like operating system became > accessible to people. Then 386BSD arrived (1993) and Linux came (1991) > into the scene and suddenly unix was everywhere - I still remember my > first stack of installation media for freeBSD - something like 10 > 1.4MB floppies for the Binaries, and another 10 for the source files. >=20 > So - yea, UUCP was around, but it wasn't alive in hobbyist circles. >=20 > Kindest regards, >=20 > Doug Jackson >=20 > em: doug(a)doughq.com > ph: 0414 986878 >=20 > Follow my amateur radio adventures at vk1zdj.net >=20 >=20 > On Thu, 24 Oct 2024 at 11:39, Bill Gunshannon via cctalk > wrote: >> >> >> >> On 10/23/2024 3:22 PM, Fred Cisin via cctalk wrote: >>> On Wed, 23 Oct 2024, Robert Feldman via cctalk wrote: >>> >>>> Ward Christensen, Early Visionary of Social Media, Dies at 78 >>>> >>>> https://www.nytimes.com/2024/10/21/technology/ward-christensen-dead.html= ?unlocked_article_code=3D1.UU4.nswM.540OUXuySX84&smid=3Durl-share >>> >>> Thank you for sharing that. >>> >>> >>> The author, presumably a heavy Reddit, TikTok and Facebook user, seemed >>> to have never heard about existence of computers before internet, nor >>> about any computer to computer connections other than internet. He does >>> not seem to know about anything except CBBS,and that solely because it >>> "resembles Facebook". >>> "Early Visionary of Social Media" >>> >>> >>> It is an adequately detailed story of his life, and mostly about CBBS >>> ("a forerunner of Reddit, TikTok and Facebook") >>> >>> A dozen paragraphs about CBBS, but XMODEM barely rated a mention, and >>> even there, only about its use on CBBS: >>> >>> "In 1977, he developed a protocol, called XMODEM, for sending computer >>> files across phone lines; it was later used on C.B.B.S." >>> . . . "For decades, his license plate read, XMODEM." >>> >> >> Which had already been done with UUCP in 1976. >> >> bill' >> --===============0426427028395595464==-- From mem@schmem.com Fri Nov 1 21:04:34 2024 From: "Mark E. Mallett" To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Fri, 01 Nov 2024 17:04:03 -0400 Message-ID: In-Reply-To: <9e266207-b27a-4e91-a9bf-a755933428db@Julf.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4854564948837573693==" --===============4854564948837573693== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, Nov 01, 2024 at 09:33:31PM +0100, Johan Helsingius via cctalk wrote: > UNIX might have been unobtainium in your home, but a lot of BBS's > used UUCP to get email and USENET connectivity, and a huge amount > of students had modem access to an UNIX computer at their university. Sure. I ran a BBS on Microport Unix (80286) in the mid-80s. And had usenet account at a small company on an Onyx system as early as about 1981. mm (and had people running uucp on MSDOS systems in the late 80s) --===============4854564948837573693==-- From spectre@floodgap.com Fri Nov 1 21:57:36 2024 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: undocumented instructions including HCF [was: System 360 question] Date: Fri, 01 Nov 2024 14:57:30 -0700 Message-ID: <8293fa4a-1a7a-4d55-8992-737e18ddcf32@floodgap.com> In-Reply-To: <154844328.426723.1730489865178@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3674843605957900141==" --===============3674843605957900141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I had remembered the HCF as being a z-80 thing, so I searched for it. >=20 > All I can find says it was 6800, not 6502. The NMOS 6502 has a number of undocumented lock-up opcodes. However, they ari= se as a consequence of its instruction decoder PLA and weren't intended for testing like the 6800 HCF. They were eliminated in the 65C02, though later versions add the STP opcode as an intentional way to halt the CPU until reset. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Eggheads unite! You have nothing to lose but your yolks. -- Adlai Stevenson --===============3674843605957900141==-- From cctalk@beyondthepale.ie Fri Nov 1 22:21:59 2024 From: Peter Coghlan To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Fri, 01 Nov 2024 22:00:51 +0000 Message-ID: <01TC7GWIRASA8WVYWH@beyondthepale.ie> In-Reply-To: <78C0981E-141C-4CBB-8C13-1E79B328F7DF@kdbarto.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8604612047459256091==" --===============8604612047459256091== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Nope. If you believe this mythical instruction exists, you are the person that gets to spend the time digging up the references to it. I've been writing assembly on the 6502 since the early 1980s and I have never managed to damage one when my programs went off the rails, which they did on many occasions. I have never heard from any other 6502 users about issues like this either. Regards, Peter Coghlan. David Barto wrote: > > Nope. Read the documentation for the chip. Turns out that the HCF instructi= on basically sent the chip into an internal loop which would render parts of = it unusable after about 30-45 seconds. >=20 > Tried it once and the chip got hot. Very very hot and then just stopped wor= king. >=20 > David > >> On Nov 1, 2024, at 9:55=E2=80=AFAM, Peter Coghlan via cctalk wrote: >>=20 >> David Barto wrote: >>>=20 >>> The 6502 had a HCF (halt and catch fire) undocumented instruction.=20 >>> I forget the opcode and if you knew what you were doing you could get the= instruction executed on the chip using any assembler.=20 >>>=20 >>> Security through obscurity back in the 70s.=20 >>> The chip was advanced enough that the DOD wanted to avoid it falling into= the =E2=80=9Cwrong=E2=80=9D hands.=20 >>>=20 >>> David >>>=20 >>> Sent from iPhone Hotblack Desiato >>>=20 >>=20 >> Did someone tell you this on April 1st? >>=20 >> Regards, >> Peter Coghlan >>=20 >> Sent from my DEC Alphaserver 800 > > There is nothing more difficult to carry out, nor more doubtful of success, > nor more dangerous to handle, than to initiate a new order of things. > For the reformer has enemies in all those who profit by the old order, > and only lukewarm defenders in all those who would profit by the new... > --Niccolo Macchiavelli, The Prince > David Barto > barto(a)kdbarto.org >=20 > --===============8604612047459256091==-- From doug@doughq.com Fri Nov 1 22:43:39 2024 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: undocumented instructions including HCF [was: System 360 question] Date: Sat, 02 Nov 2024 09:43:21 +1100 Message-ID: In-Reply-To: <8293fa4a-1a7a-4d55-8992-737e18ddcf32@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0845443733289687831==" --===============0845443733289687831== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit There was a "Killer Poke" on the commodore PET that would alter the video horizontal output frequency, which had the effect of physically damaging the video hardware as the high voltage was generated by the flyback transformer.l and there was no regulation. It's mere existence made my father paranoid about machine code programming. I was probably 10 at the time. On Sat, 2 Nov 2024, 8:57 am Cameron Kaiser via cctalk, < cctalk(a)classiccmp.org> wrote: > > > I had remembered the HCF as being a z-80 thing, so I searched for it. > > > > All I can find says it was 6800, not 6502. > > The NMOS 6502 has a number of undocumented lock-up opcodes. However, they > arise > as a consequence of its instruction decoder PLA and weren't intended for > testing like the 6800 HCF. They were eliminated in the 65C02, though later > versions add the STP opcode as an intentional way to halt the CPU until > reset. > > -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckaiser(a)floodgap.com > -- Eggheads unite! You have nothing to lose but your yolks. -- Adlai > Stevenson > > --===============0845443733289687831==-- From cisin@xenosoft.com Fri Nov 1 23:13:41 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: undocumented instructions including HCF [was: System 360 question] Date: Fri, 01 Nov 2024 16:13:35 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5198919756168855235==" --===============5198919756168855235== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The IBM monochrome monitor could be damaged by putting it into an unsupported mode. The idea of a command that would brick the system is popular. It may be possible, but it's very difficult to track down the details from FOAFs. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5198919756168855235==-- From billdegnan@gmail.com Sat Nov 2 00:16:02 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Fri, 01 Nov 2024 20:15:43 -0400 Message-ID: In-Reply-To: <9e266207-b27a-4e91-a9bf-a755933428db@Julf.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6485277391275650601==" --===============6485277391275650601== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For a few year VMS was the OS of the "internet". I remember wondering in 1991 or 1992 if UNIX would still be around by 2000 On Fri, Nov 1, 2024, 4:42 PM Johan Helsingius via cctalk < cctalk(a)classiccmp.org> wrote: > UNIX might have been unobtainium in your home, but a lot of BBS's > used UUCP to get email and USENET connectivity, and a huge amount > of students had modem access to an UNIX computer at their university. > > Julf > > > On 10/24/24 04:36, Doug Jackson via cctalk wrote: > > Yes, UUCP was literally a thing, but UNIX was unobtanium in the early > > computing eral - The world of the University Minicomputer. > > > > It certainly wasn't even vaguely accessible by a hobbyist running a > > Z80 or 6800 in the late 70's. > > > > I vividly remember being able to take home a NEC 80386 computer from > > my day job (I worked for a computer store selling NEC machines) during > > the Christmas shutdown between 1987/1988 - It had SCO Xenix installed > > and a new graphical system (To SCO) called 'XWindows' Unheard of - I > > did a heap of learning. > > > > That was probably the point where a UNIX like operating system became > > accessible to people. Then 386BSD arrived (1993) and Linux came (1991) > > into the scene and suddenly unix was everywhere - I still remember my > > first stack of installation media for freeBSD - something like 10 > > 1.4MB floppies for the Binaries, and another 10 for the source files. > > > > So - yea, UUCP was around, but it wasn't alive in hobbyist circles. > > > > Kindest regards, > > > > Doug Jackson > > > > em: doug(a)doughq.com > > ph: 0414 986878 > > > > Follow my amateur radio adventures at vk1zdj.net > > > > > > On Thu, 24 Oct 2024 at 11:39, Bill Gunshannon via cctalk > > wrote: > >> > >> > >> > >> On 10/23/2024 3:22 PM, Fred Cisin via cctalk wrote: > >>> On Wed, 23 Oct 2024, Robert Feldman via cctalk wrote: > >>> > >>>> Ward Christensen, Early Visionary of Social Media, Dies at 78 > >>>> > >>>> > https://www.nytimes.com/2024/10/21/technology/ward-christensen-dead.html?un= locked_article_code=3D1.UU4.nswM.540OUXuySX84&smid=3Durl-share > >>> > >>> Thank you for sharing that. > >>> > >>> > >>> The author, presumably a heavy Reddit, TikTok and Facebook user, seemed > >>> to have never heard about existence of computers before internet, nor > >>> about any computer to computer connections other than internet. He > does > >>> not seem to know about anything except CBBS,and that solely because it > >>> "resembles Facebook". > >>> "Early Visionary of Social Media" > >>> > >>> > >>> It is an adequately detailed story of his life, and mostly about CBBS > >>> ("a forerunner of Reddit, TikTok and Facebook") > >>> > >>> A dozen paragraphs about CBBS, but XMODEM barely rated a mention, and > >>> even there, only about its use on CBBS: > >>> > >>> "In 1977, he developed a protocol, called XMODEM, for sending computer > >>> files across phone lines; it was later used on C.B.B.S." > >>> . . . "For decades, his license plate read, XMODEM." > >>> > >> > >> Which had already been done with UUCP in 1976. > >> > >> bill' > >> > --===============6485277391275650601==-- From joe@barrera.org Sat Nov 2 00:34:14 2024 From: "Joseph S. Barrera III" To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Fri, 01 Nov 2024 17:33:56 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6637559561159641203==" --===============6637559561159641203== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable And before that, TENEX/TOPS-20 on the DECSYSTEM-20. But that's slightly before my time. (By the time I entered the CMU Ph.D. program, very few DECSYSTEMs were left, being replaced by 11/780s and then a plethora of microvaxen. Running VMS, but also BSD 4.1 with lots of 4.2 patches.) VMS certainly was better engineered... but you NEEDED those big blue binders. It took me several days with those binders to figure out how to get uncooked keyboard input. On Fri, Nov 1, 2024 at 5:16=E2=80=AFPM Bill Degnan via cctalk wrote: > For a few year VMS was the OS of the "internet". I remember wondering in > 1991 or 1992 if UNIX would still be around by 2000 > > On Fri, Nov 1, 2024, 4:42 PM Johan Helsingius via cctalk < > cctalk(a)classiccmp.org> wrote: > > > UNIX might have been unobtainium in your home, but a lot of BBS's > > used UUCP to get email and USENET connectivity, and a huge amount > > of students had modem access to an UNIX computer at their university. > > > > Julf > > > > > > On 10/24/24 04:36, Doug Jackson via cctalk wrote: > > > Yes, UUCP was literally a thing, but UNIX was unobtanium in the early > > > computing eral - The world of the University Minicomputer. > > > > > > It certainly wasn't even vaguely accessible by a hobbyist running a > > > Z80 or 6800 in the late 70's. > > > > > > I vividly remember being able to take home a NEC 80386 computer from > > > my day job (I worked for a computer store selling NEC machines) during > > > the Christmas shutdown between 1987/1988 - It had SCO Xenix installed > > > and a new graphical system (To SCO) called 'XWindows' Unheard of - I > > > did a heap of learning. > > > > > > That was probably the point where a UNIX like operating system became > > > accessible to people. Then 386BSD arrived (1993) and Linux came (1991) > > > into the scene and suddenly unix was everywhere - I still remember my > > > first stack of installation media for freeBSD - something like 10 > > > 1.4MB floppies for the Binaries, and another 10 for the source files. > > > > > > So - yea, UUCP was around, but it wasn't alive in hobbyist circles. > > > > > > Kindest regards, > > > > > > Doug Jackson > > > > > > em: doug(a)doughq.com > > > ph: 0414 986878 > > > > > > Follow my amateur radio adventures at vk1zdj.net > > > > > > > > > On Thu, 24 Oct 2024 at 11:39, Bill Gunshannon via cctalk > > > wrote: > > >> > > >> > > >> > > >> On 10/23/2024 3:22 PM, Fred Cisin via cctalk wrote: > > >>> On Wed, 23 Oct 2024, Robert Feldman via cctalk wrote: > > >>> > > >>>> Ward Christensen, Early Visionary of Social Media, Dies at 78 > > >>>> > > >>>> > > > https://www.nytimes.com/2024/10/21/technology/ward-christensen-dead.html?un= locked_article_code=3D1.UU4.nswM.540OUXuySX84&smid=3Durl-share > > >>> > > >>> Thank you for sharing that. > > >>> > > >>> > > >>> The author, presumably a heavy Reddit, TikTok and Facebook user, > seemed > > >>> to have never heard about existence of computers before internet, nor > > >>> about any computer to computer connections other than internet. He > > does > > >>> not seem to know about anything except CBBS,and that solely because > it > > >>> "resembles Facebook". > > >>> "Early Visionary of Social Media" > > >>> > > >>> > > >>> It is an adequately detailed story of his life, and mostly about CBBS > > >>> ("a forerunner of Reddit, TikTok and Facebook") > > >>> > > >>> A dozen paragraphs about CBBS, but XMODEM barely rated a mention, and > > >>> even there, only about its use on CBBS: > > >>> > > >>> "In 1977, he developed a protocol, called XMODEM, for sending > computer > > >>> files across phone lines; it was later used on C.B.B.S." > > >>> . . . "For decades, his license plate read, XMODEM." > > >>> > > >> > > >> Which had already been done with UUCP in 1976. > > >> > > >> bill' > > >> > > > --===============6637559561159641203==-- From cclist@sydex.com Sat Nov 2 01:32:52 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Sat, 02 Nov 2024 01:32:43 +0000 Message-ID: <5ee43e4a-a20f-48d2-9b99-6855c3121f19@sydex.com> In-Reply-To: <9e266207-b27a-4e91-a9bf-a755933428db@Julf.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3583882487252886868==" --===============3583882487252886868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/1/24 13:33, Johan Helsingius via cctalk wrote: > UNIX might have been unobtainium in your home, but a lot of BBS's > used UUCP to get email and USENET connectivity, and a huge amount > of students had modem access to an UNIX computer at their university. Back in the day, I used a package called UUPC for email. --Chuck --===============3583882487252886868==-- From julf@julf.com Sat Nov 2 09:27:00 2024 From: Johan Helsingius To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Sat, 02 Nov 2024 10:26:26 +0100 Message-ID: <8e9658ff-340e-46e3-8cd0-37395466e3b3@Julf.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4332361818752216217==" --===============4332361818752216217== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/2/24 01:15, Bill Degnan via cctalk wrote: > For a few year VMS was the OS of the "internet". I remember wondering in > 1991 or 1992 if UNIX would still be around by 2000 From what I can recall, there were a lot of VAXen on the net, but the vast majority was running BSD. Julf --===============4332361818752216217==-- From bill.gunshannon@hotmail.com Sat Nov 2 13:59:56 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Ward Christensen NY Times Obituary Date: Sat, 02 Nov 2024 09:59:34 -0400 Message-ID: In-Reply-To: <8e9658ff-340e-46e3-8cd0-37395466e3b3@Julf.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6807759926061661391==" --===============6807759926061661391== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/2/2024 5:26 AM, Johan Helsingius via cctalk wrote: > On 11/2/24 01:15, Bill Degnan via cctalk wrote: >> For a few year VMS was the OS of the "internet".  I remember wondering in >> 1991 or 1992 if UNIX would still be around by 2000 > > From what I can recall, there were a lot of VAXen on the net, but > the vast majority was running BSD. > While there was UUCP for VMS I think the majority of networked VMS boxes were on BITNET rather than UUCPnet. bill --===============6807759926061661391==-- From charles.unix.pro@gmail.com Sat Nov 2 15:51:01 2024 From: Charles Anthony To: cctalk@classiccmp.org Subject: [cctalk] Re: undocumented instructions including HCF [was: System 360 question] Date: Sat, 02 Nov 2024 08:50:43 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0421969396875100268==" --===============0421969396875100268== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > > The idea of a command that would brick the system is popular. > It may be possible, but it's very difficult to track down the details from > FOAFs. > Not bricking, but breaking: From multicians.org: "The tape drives used on the GE-635 were some of the first self threading drives. As a result they needed an extremely long tape leader before the "reflector spot" and this was a pain for MIT operators when loading the tapes onto the IBM 7094 running CTSS . Lee Varian wrote some tricky code, and we put two load point reflectors on the tapes we shuttled between the 7094 and the 635. The 635 would only sense the farther-in load point; the 7094 would load to the early load point and then Lee's code would space it way out and rewind back to the 635 load point. If we didn't find the right label, his code tried three times and then deliberately broke the tape so the operator would have to put on new load points at the correct places. (You could break a tape on the '94 by putting it into high speed rewind and then doing a reset data channel command, I suppose it's safe to reveal this now.)" -- Charles X-Clacks-Overhead: GNU Terry Pratchett --===============0421969396875100268==-- From raymond.wiker@icloud.com Sun Nov 3 08:30:57 2024 From: raymond.wiker@icloud.com To: cctalk@classiccmp.org Subject: [cctalk] Re: System 360 question Date: Sun, 03 Nov 2024 09:22:01 +0100 Message-ID: <878FEB0B-A9D1-45FD-B65F-322726EF5EC6@icloud.com> In-Reply-To: <01TC7GWIRASA8WVYWH@beyondthepale.ie> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2053180403590102316==" --===============2053180403590102316== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The 6800 had an "HCF" instruction. The 6502 had several KIL instructions that= had similar behaviour. I don't think either of these made any permanent dama= ge. https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing) https://www.pagetable.com/?p=3D39 https://en.wikipedia.org/wiki/Killer_poke > On 1 Nov 2024, at 23:00, Peter Coghlan via cctalk = wrote: >=20 >=20 > Nope. If you believe this mythical instruction exists, you are the > person that gets to spend the time digging up the references to it. >=20 > I've been writing assembly on the 6502 since the early 1980s and I have > never managed to damage one when my programs went off the rails, which > they did on many occasions. >=20 > I have never heard from any other 6502 users about issues like this either. >=20 > Regards, > Peter Coghlan. >=20 > David Barto wrote: >>=20 >> Nope. Read the documentation for the chip. Turns out that the HCF instruct= ion basically sent the chip into an internal loop which would render parts of= it unusable after about 30-45 seconds. >>=20 >> Tried it once and the chip got hot. Very very hot and then just stopped wo= rking. >>=20 >> David >>=20 >>> On Nov 1, 2024, at 9:55=E2=80=AFAM, Peter Coghlan via cctalk wrote: >>>=20 >>> David Barto wrote: >>>>=20 >>>> The 6502 had a HCF (halt and catch fire) undocumented instruction.=20 >>>> I forget the opcode and if you knew what you were doing you could get th= e instruction executed on the chip using any assembler.=20 >>>>=20 >>>> Security through obscurity back in the 70s.=20 >>>> The chip was advanced enough that the DOD wanted to avoid it falling int= o the =E2=80=9Cwrong=E2=80=9D hands.=20 >>>>=20 >>>> David >>>>=20 >>>> Sent from iPhone Hotblack Desiato >>>>=20 >>>=20 >>> Did someone tell you this on April 1st? >>>=20 >>> Regards, >>> Peter Coghlan >>>=20 >>> Sent from my DEC Alphaserver 800 >>=20 >> There is nothing more difficult to carry out, nor more doubtful of success, >> nor more dangerous to handle, than to initiate a new order of things. >> For the reformer has enemies in all those who profit by the old order, >> and only lukewarm defenders in all those who would profit by the new... >> --Niccolo Macchiavelli, The Prince >> David Barto >> barto(a)kdbarto.org >>=20 >>=20 --===============2053180403590102316==-- From ard.p850ug1@gmail.com Sun Nov 3 10:42:52 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Sun, 03 Nov 2024 10:42:37 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5272845928346971700==" --===============5272845928346971700== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, Oct 29, 2024 at 7:10 PM Fred Cisin via cctalk wrote: > Because one couldn't supply drives with an asterisk? > or because they didn't want to use the crappy Qume 142 drives on anything > else? > The Qume 142 was so slow stepping, that that was one of the reasons for > introducing PC-DOS 2.10, to have a slower step time. It is now my considered opinion that there is a special corner of Hades reserved for the designers of said drive. And that they should be forced spend eternity doing radial head alignments on them. You loosen off the stepper motor clamp, try to turn the motor body and find it sticks and then leaps half a dozen tracks. And when you do up the clamps, the alignment shifts. ARGH! -tony --===============5272845928346971700==-- From sqrfolkdnc@comcast.net Sun Nov 3 15:13:25 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] HCF [was: System 360 question] Date: Sun, 03 Nov 2024 09:13:18 -0600 Message-ID: <221669544.1096149.1730646798569@connect.xfinity.com> In-Reply-To: <878FEB0B-A9D1-45FD-B65F-322726EF5EC6@icloud.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1076539815911489702==" --===============1076539815911489702== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm going to suggest that the 1620 had the most HCF instructions of any comme= rcially produced computer, ever. And the most intentionally used on a daily = basis. It is a memory-to-memory computer with no actual registers (the model= II had index registers, but they were in memory). Few machines had disks, a= nd fewer had tape (magnetic or paper), so they were almost always run from ta= bulating cards. I always started my session with the clear memory command be= low, and maybe several more times during my scheduled hour. 1. you could press "insert" on the typewriter and enter a program starting at= location zero which was executed when you hit return. If you wanted to clea= r memory, you typed in 12 digits "310000900010" (transmit record) which meant= copy the character at location 9 to location 10, then 10 to 11, etc until it= found the special character "record mark", which it would never find as you = typed in a zero at the starting address. watch the address lights till it lo= oped and hit reset. Or "TF 9,8" (transmit field) which worked the other dire= ction looking for a field mark, which it would never find either. There was = a two card program you could put in front of your card deck that would zero = memory then load your program, but since the model 1 did addition by table lo= okup in locations 100-199, if there was any chance that table was bad, it wou= ld not work. I think other "catch fire" instruction variants would continue = forever. 2. remember that record mark? if you ever executed an instruction with a reco= rd mark in the address, you got a MAR check red light, a hard reset was requi= red to escape. probably if in the op code also. And some hard stop for any = invalid op code, but these may have been in the category below. 3. there were other errors, but you could press start to continue and there w= as a toggle switch to ignore at least some of them, like a parity error in me= mory. 4. I seem to recall being told "don't do this, it can break the hardware", bu= t don't remember any details, and not an instant thing, it would be like the = "B *" loop, causing issues if left running a long time. The IBM 1401 had a similar architecture (but with 7 useable bits per address = vs 5 for the 1620, and was also memory to memory, so probably had instruction= s that would run forever. No typewriter available on the 1401 AFAIK, so my e= xample would not have been a routine action.. 
--Carey
--===============1076539815911489702==-- From d44617665@hotmail.com Sun Nov 3 18:06:30 2024 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 18:06:22 +0000 Message-ID: In-Reply-To: <221669544.1096149.1730646798569@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1352844851523571218==" --===============1352844851523571218== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1620 owner here. Sure there are ways to cause a CHECK STOP, and one-instruction infinite loops= , including the IBM-sanctioned one you describe below - which everyone used a= ll day to clobber core - but that's all they are, they don't damage hardware. You can make an infinite loop that is sort of less than one instruction. It'= s an instruction with a self-referencing indirect address. (Only applies to = Model II, and Model I machines with the Indirect Addressing feature installed= , like mine.) When it tries to fetch the indirect operand, it loops in the F= etch cycle without ever reaching Execute stage. While that sounds like a cor= e hammer, it is still less than 30% duty cycle on any one address. Also reme= mber the core stack has air blowing through it nonstop. There is a setup on the Customer Engineer switch panel (INC plus BYP) that wi= ll hammer a single address, but I don't remember a warning. The only damage = risk is if one or more of your decode switch transistors are failing to groun= d their A/B/C/D drive line, or you have an open X or Y line. In that case th= ere's an inductive voltage spike that will stress all the other D-S transisto= rs. The CE Reference Manual warns against clocking in this state for more th= an a couple seconds. Dave Wise in Hillsboro Oregon The entire first production run (Suffix B) was paper tape only. Card support= was added at Suffix C. The core memory array is 3D with two-level selection. The main array select = lines are X and Y. They are driven by 10x10 matrix switches which are in tur= n driven by 10 decode switches each on A, B, C, and D. A and B select X, C a= nd D select Y. This is slow but it minimizes the number of costly high-perfo= rmance transistors. The 1401 is the same. ________________________________ From: CAREY SCHUG via cctalk Sent: Sunday, November 3, 2024 7:13 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: CAREY SCHUG Subject: [cctalk] HCF [was: System 360 question] I'm going to suggest that the 1620 had the most HCF instructions of any comme= rcially produced computer, ever. And the most intentionally used on a daily = basis. It is a memory-to-memory computer with no actual registers (the model= II had index registers, but they were in memory). Few machines had disks, a= nd fewer had tape (magnetic or paper), so they were almost always run from ta= bulating cards. I always started my session with the clear memory command be= low, and maybe several more times during my scheduled hour. 1. you could press "insert" on the typewriter and enter a program starting at= location zero which was executed when you hit return. If you wanted to clea= r memory, you typed in 12 digits "310000900010" (transmit record) which meant= copy the character at location 9 to location 10, then 10 to 11, etc until it= found the special character "record mark", which it would never find as you = typed in a zero at the starting address. watch the address lights till it lo= oped and hit reset. Or "TF 9,8" (transmit field) which worked the other dire= ction looking for a field mark, which it would never find either. There was = a two card program you could put in front of your card deck that would zero = memory then load your program, but since the model 1 did addition by table lo= okup in locations 100-199, if there was any chance that table was bad, it wou= ld not work. I think other "catch fire" instruction variants would continue = forever. 2. remember that record mark? if you ever executed an instruction with a reco= rd mark in the address, you got a MAR check red light, a hard reset was requi= red to escape. probably if in the op code also. And some hard stop for any = invalid op code, but these may have been in the category below. 3. there were other errors, but you could press start to continue and there w= as a toggle switch to ignore at least some of them, like a parity error in me= mory. 4. I seem to recall being told "don't do this, it can break the hardware", bu= t don't remember any details, and not an instant thing, it would be like the = "B *" loop, causing issues if left running a long time. The IBM 1401 had a similar architecture (but with 7 useable bits per address = vs 5 for the 1620, and was also memory to memory, so probably had instruction= s that would run forever. No typewriter available on the 1401 AFAIK, so my e= xample would not have been a routine action.. 
--Carey
--===============1352844851523571218==-- From cclist@sydex.com Sun Nov 3 20:55:15 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 20:55:05 +0000 Message-ID: <088c3dd6-a8b6-469a-b3a7-ee90ab9d8740@sydex.com> In-Reply-To: =?utf-8?q?=3CCYXPR84MB3515FD852877C2B4E88E5750AE502=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2146781375462893480==" --===============2146781375462893480== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/3/24 10:06, David Wise via cctalk wrote: > 1620 owner here. >=20 > Sure there are ways to cause a CHECK STOP, and one-instruction infinite loo= ps, including the IBM-sanctioned one you describe below - which everyone used= all day to clobber core - but that's all they are, they don't damage hardwar= e. >=20 > You can make an infinite loop that is sort of less than one instruction. I= t's an instruction with a self-referencing indirect address. (Only applies t= o Model II, and Model I machines with the Indirect Addressing feature install= ed, like mine.) When it tries to fetch the indirect operand, it loops in the= Fetch cycle without ever reaching Execute stage. While that sounds like a c= ore hammer, it is still less than 30% duty cycle on any one address. Also re= member the core stack has air blowing through it nonstop. Sure, there was more than one way to, say, clear memory on a 1620 with a single instruction--and it was common knowledge. One could use a transmit record or transmit field instruction that not only over-wrote general memory, but also clobbered the instruction itself. Such is the glory of variable field/record length architectures. --Chuck --===============2146781375462893480==-- From paul.kimpel@digm.com Sun Nov 3 20:56:34 2024 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 20:56:28 +0000 Message-ID: <173066738854.4006402.265401810374547681@classiccmp.org> In-Reply-To: <221669544.1096149.1730646798569@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7816483856830229554==" --===============7816483856830229554== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable CAREY SCHUG wrote: > I'm going to suggest that the 1620 had the most HCF instructions of any com= mercially > produced computer, ever. And the most intentionally used on a daily basis. > 1. you could press "insert" on the typewriter and enter a program starting = at > location zero which was executed when you hit return. If you wanted to cle= ar memory, you > typed in 12 digits "310000900010" (transmit record) which meant copy the > character at location 9 to location 10, then 10 to 11, etc until it found t= he special > character "record mark", which it would never find as you typed in a zero a= t the > starting address. watch the address lights till it looped and hit reset. Note that, as written, your instruction doesn't clear memory, it shifts memor= y to the left by one digit every complete cycle through memory, because the d= estination address is lower than the source address. What you need to do a "f= orward smear," where the source address is lower than the destination address= , so that the destination digits become source digits as the addresses increa= se, e.g., 310000300002.=20 That would only work on a 1620 Model 1, however. It wouldn't work on a Model = 2. Both models fetched two digits from memory at a time, but for many instruc= tions (including TR and TF) the Model 2 would stash the digit at the odd addr= ess and use it during the odd-address fetch cycle, saving a redundant fetch f= rom the same digit pair in memory. Therefore, the source and destination addr= esses had to differ by at least 2 -- this will work on the Model 2: 310000400= 002. But nobody bothered with that on the Model 2, because it had a hardware memor= y clear mechanism. Simultaneously pressing MODIFY (which wasn't present on th= e Model 1) and CHECK RESET on the console would turn on the CLR MEM control g= ate. Then pressing START would clear all of memory once and halt. > 2. remember that record mark? if you ever executed an instruction with a re= cord mark in > the address, you got a MAR check red light, a hard reset was required to es= cape. probably > if in the op code also. And some hard stop for any invalid op code, but th= ese may have > been in the category below. Shouldn't these be considered good error-trapping features and not in the sam= e league as HCF? An RM had the 8 and 2 bits set, so it wasn't a valid decim= al digit, and couldn't be used in an address. An RM in the Q field of an imme= diate instruction was okay, though. > 3. there were other errors, but you could press start to continue and there= was a toggle > switch to ignore at least some of them, like a parity error in memory. You could press START to continue after a memory parity error or an I/O parit= y error, but not after a MAR CHECK. The PROGRAM/STOP toggle switches (there were four of them, for DISK, MEMORY, = I/O, and arithmetic OVERFLOW) did not cause the errors to be ignored, they ju= st controlled whether the CPU halted when exceptions occurred. In all cases, = internal flags (termed "indicators") were set, which could be interrogated by= the BI and BNI instructions. The MEMORY switch had no effect on a MAR CHECK = -- the CPU always did a hard stop on those and required a RESET. Paul --===============7816483856830229554==-- From paulkoning@comcast.net Sun Nov 3 21:39:42 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 16:39:34 -0500 Message-ID: In-Reply-To: <088c3dd6-a8b6-469a-b3a7-ee90ab9d8740@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0795203194181936429==" --===============0795203194181936429== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 3, 2024, at 3:55 PM, Chuck Guzis via cctalk wrote: >=20 > On 11/3/24 10:06, David Wise via cctalk wrote: >> 1620 owner here. >>=20 >> Sure there are ways to cause a CHECK STOP, and one-instruction infinite lo= ops, including the IBM-sanctioned one you describe below - which everyone use= d all day to clobber core - but that's all they are, they don't damage hardwa= re. >>=20 >> You can make an infinite loop that is sort of less than one instruction. = It's an instruction with a self-referencing indirect address. (Only applies = to Model II, and Model I machines with the Indirect Addressing feature instal= led, like mine.) When it tries to fetch the indirect operand, it loops in th= e Fetch cycle without ever reaching Execute stage. While that sounds like a = core hammer, it is still less than 30% duty cycle on any one address. Also r= emember the core stack has air blowing through it nonstop. >=20 > Sure, there was more than one way to, say, clear memory on a 1620 with a > single instruction--and it was common knowledge. One could use a > transmit record or transmit field instruction that not only over-wrote > general memory, but also clobbered the instruction itself. >=20 > Such is the glory of variable field/record length architectures. Yes, but you don't need such an architecture for this. A PDP-11 can do it al= so. I once assigned that as a a pair of homework questions in an assembly la= nguage programming course: 1. Show a one-word PDP-11 program that writes all of memory, in reverse order. 2. Show a one-word PDP-11 program that clears all of memory, in forward order= , halting on completion. paul --===============0795203194181936429==-- From cclist@sydex.com Sun Nov 3 21:45:44 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 21:45:33 +0000 Message-ID: <2c0f0dc6-4f1e-4c02-bc1d-9845dc413f80@sydex.com> In-Reply-To: <173066738854.4006402.265401810374547681@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3487947788539958409==" --===============3487947788539958409== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/3/24 12:56, paul.kimpel--- via cctalk wrote: > CAREY SCHUG wrote: >> 2. remember that record mark? if you ever executed an instruction with a r= ecord mark in >> the address, you got a MAR check red light, a hard reset was required to e= scape. probably >> if in the op code also. And some hard stop for any invalid op code, but t= hese may have >> been in the category below. >=20 > Shouldn't these be considered good error-trapping features and not in the s= ame league as HCF? An RM had the 8 and 2 bits set, so it wasn't a valid dec= imal digit, and couldn't be used in an address. An RM in the Q field of an im= mediate instruction was okay, though. On card-oriented CADETs, there were a few alternatives to the nuisance of having to multipunch a record or group mark on an 026. I seem to recall that a period read numerically translated to 8-2-1 and worked just as well. Among other shortcomings of the 1620, there was no way to test for numeric blank (8-4). You just had to know that it was there. There were several such bugaboos, with which Dijkstra had issues. Still, the 1620 was capable of doing real work--and its 1710 relative was capable of industrial process control application. --Chuck --===============3487947788539958409==-- From paulkoning@comcast.net Sun Nov 3 22:03:11 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 17:03:03 -0500 Message-ID: In-Reply-To: <20241103215922.CD4FD374034A@freecalypso.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2948114520143730244==" --===============2948114520143730244== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 3, 2024, at 4:59 PM, Mychaela Falconia wr= ote: >=20 > Paul Koning wrote: >=20 >> 1. Show a one-word PDP-11 program that writes all of memory, in reverse or= der. >=20 > MOV -(PC),-(PC) >=20 > I remember this one from late-Soviet/early-Russian BK0010 hacker clubs... > BK0010 was a "home computer" built around 1801VM1 microprocessor, a > Soviet implementation of basic PDP-11 instruction set. No idea exactly > which DEC model it corresponds to, if any. >=20 >> 2. Show a one-word PDP-11 program that clears all of memory, >> in forward order, halting on completion. >=20 > This one I am struggling with - it's been too many decades since I did > any PDP-11 assembly... Hint: you get to pick the initial values of the registers. paul --===============2948114520143730244==-- From falcon@freecalypso.org Sun Nov 3 22:09:32 2024 From: Mychaela Falconia To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 13:59:17 -0800 Message-ID: <20241103215922.CD4FD374034A@freecalypso.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5090655178107472179==" --===============5090655178107472179== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul Koning wrote: > 1. Show a one-word PDP-11 program that writes all of memory, in reverse ord= er. MOV -(PC),-(PC) I remember this one from late-Soviet/early-Russian BK0010 hacker clubs... BK0010 was a "home computer" built around 1801VM1 microprocessor, a Soviet implementation of basic PDP-11 instruction set. No idea exactly which DEC model it corresponds to, if any. > 2. Show a one-word PDP-11 program that clears all of memory, > in forward order, halting on completion. This one I am struggling with - it's been too many decades since I did any PDP-11 assembly... M~ --===============5090655178107472179==-- From bitwiz@12bitsbest.com Sun Nov 3 22:49:01 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Self modifying code was HCF Date: Sun, 03 Nov 2024 16:48:49 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6923799033572905671==" --===============6923799033572905671== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Though not Halt and Catch Fire you guys are forgetting the joy of self=20 modifying code. That is how many PDP-8 programs worked.=C2=A0 Even the bin loader where the=20 jump to loop instruction would be replaced with a jump to loaded program=20 start by the loader itself. There were many programs that were very difficult to figure out what=20 they were doing, due to using this technique. I love the PDP-8 but I don't miss self modifying code at all. On 11/3/2024 4:03 PM, Paul Koning via cctalk wrote: > >> On Nov 3, 2024, at 4:59 PM, Mychaela Falconia w= rote: >> >> Paul Koning wrote: >> >>> 1. Show a one-word PDP-11 program that writes all of memory, in reverse o= rder. >> MOV -(PC),-(PC) >> >> I remember this one from late-Soviet/early-Russian BK0010 hacker clubs... >> BK0010 was a "home computer" built around 1801VM1 microprocessor, a >> Soviet implementation of basic PDP-11 instruction set. No idea exactly >> which DEC model it corresponds to, if any. >> >>> 2. Show a one-word PDP-11 program that clears all of memory, >>> in forward order, halting on completion. >> This one I am struggling with - it's been too many decades since I did >> any PDP-11 assembly... > Hint: you get to pick the initial values of the registers. > > paul > --===============6923799033572905671==-- From cclist@sydex.com Sun Nov 3 23:36:16 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Self modifying code was HCF Date: Sun, 03 Nov 2024 23:36:07 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1689878543013516307==" --===============1689878543013516307== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/3/24 14:48, Mike Katz via cctalk wrote: > Though not Halt and Catch Fire you guys are forgetting the joy of self > modifying code. Indeed, this was the *only* way to do things on early first- and second-generation systems. Even the lowly 1620 CADET, without the optional indirect addressing feature mandated use of code modification. --Chuck --===============1689878543013516307==-- From dkelvey@hotmail.com Sun Nov 3 23:56:53 2024 From: dwight To: cctalk@classiccmp.org Subject: [cctalk] Re: Self modifying code was HCF Date: Sun, 03 Nov 2024 23:56:45 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6269406286752641670==" --===============6269406286752641670== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I/O addresses for the 8080 come to mind. Dwight ________________________________ From: Chuck Guzis via cctalk Sent: Sunday, November 3, 2024 3:36 PM To: Mike Katz via cctalk Cc: Chuck Guzis Subject: [cctalk] Re: Self modifying code was HCF On 11/3/24 14:48, Mike Katz via cctalk wrote: > Though not Halt and Catch Fire you guys are forgetting the joy of self > modifying code. Indeed, this was the *only* way to do things on early first- and second-generation systems. Even the lowly 1620 CADET, without the optional indirect addressing feature mandated use of code modification. --Chuck --===============6269406286752641670==-- From elson@pico-systems.com Mon Nov 4 00:09:11 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 18:09:00 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5035869230246031809==" --===============5035869230246031809== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 11/3/24 15:39, Paul Koning via cctalk wrote: > > Yes, but you don't need such an architecture for this. A PDP-11 can do it = also. I once assigned that as a a pair of homework questions in an assembly = language programming course: > > 1. Show a one-word PDP-11 program that writes all of memory, in reverse ord= er. > 2. Show a one-word PDP-11 program that clears all of memory, in forward ord= er, halting on completion. > Yes, I did something like this when we got our first VAX 11/780. Jon --===============5035869230246031809==-- From spectre@floodgap.com Mon Nov 4 00:19:39 2024 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 16:19:30 -0800 Message-ID: <44a26231-91d7-49a5-b4ac-b44f1b3c9b9e@floodgap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0798516169988439547==" --===============0798516169988439547== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >>> 2. Show a one-word PDP-11 program that clears all of memory, >>> in forward order, halting on completion. >> >> This one I am struggling with - it's been too many decades since I did >> any PDP-11 assembly... > > Hint: you get to pick the initial values of the registers. Can we pick the initial contents of memory? ;) --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Go Computer Now! -- Sphere Corporation -----------------------------------= -- --===============0798516169988439547==-- From lewissa78@gmail.com Mon Nov 4 02:10:55 2024 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Sun, 03 Nov 2024 20:10:37 -0600 Message-ID: In-Reply-To: <0a24e5cc-20bb-4e17-b8a8-4250e75db272@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5786578238254699434==" --===============5786578238254699434== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 5.25" drive, so I'm pretty sure they are actual 360KB disks). That said, I haven't really fully confirmed if it's a 1.2M drive. TEAC FD-55GFR 142-U, because I haven't actually come across any 1.2M formatted media. I've wondered if maybe one of the heads on the D: drive the Sharp PC-5000's dual disk drive might have some kind of issue (either the REad or Write head, not sure which) - just since it seemed more likely to end up with some bad sectors marked when using FORMAT.COM (whereas on other systems, the same disk would format fine with no bad sectors). -Steve On Thu, Oct 31, 2024 at 7:17 AM osi.superboard via cctalk < cctalk(a)classiccmp.org> wrote: > Steve, > > could you please explain, what exact disk media you are using. > > > On 30.10.2024 05:03, Steve Lewis via cctalk wrote: > > Fascinating notes! > > > > I did run into oddities when using a 360KB disks in between a 1.2M 5.25 > > drive on the '386 and the 5.25 drive on the Sharp PC-5000. I forget my > > exact sequence of events, but in short the MS-DOS 2.00 FORMAT.COM on the > > Sharp PC-5000 would start marking a few bad sectors (sometimes just a few > > KB, sometimes as much as 20KB of bad sectors). And yet those same disks > > were formatted as just fine and no bad sectors over the '386. Or, if I > > used IMD and wrote full MS-DOS 2.00 image to the disk, then the disk > would > > work (and boot) fine in the Sharp PC-5000. Without nit-picking the > > specifics here (of whatever I did) - my lesson was there is definitely a > > difference between a completely uninitialized disks, versus something > that > > has been previously formatted. Which, yeah, duh - but my real lesson > was: > > you can't always FORMAT.COM your way back into a bootable disk. If > > something else has "touched" the boot sectors, then another system might > > start flagging those as bad sectors. > > > > I'm not sure if IMD (ImageDisk) trumps all that? Meaning, whatever crap > is > > on the disk, does IMD not care? In otherwords, is using IMD kinda-sorta > > like degaussing (and then applying whatever the image is)? It just > seemed > > to me that however I mangled the format on a disk, IMD was always able to > > get me back into a usable (and bootable) disk. > > > > I do remember (vaguely for me) in the 80s we'd get boxes of uninitialized > > disks, and there were generally warnings along the lines of once it was > > formatted to whatever system you intended to use the disk for, it was > > thereafter basically committed to being used for that system. (but it > > seems only because, back in those days we didn't typically have the > benefit > > of something like IMD software or a Greazeweasal - and I imagine the > > documentation from disk vendors didn't want to get into the weeds of > waving > > magnets around your disk, especially when they already had bold warnings > of > > keeping your disk the heck away from any magnets :) ) > > > > > > > > Regarding the article on SF rail replacing disk drives, to avoid > > "catastrophic failure".... recall a while back, ActionRetro made a RAID > > out of floppy disk drives (3.5"'s). With all the firmware going into > modern > > SSD's and M.2's, I ponder the irony of "old dumb mechanical drives" > > actually being (in a way) more secure. > > > > > > -Steve > > > > > > > > > > > > > > > > > > On Tue, Oct 29, 2024 at 8:35 PM Fred Cisin via cctalk < > cctalk(a)classiccmp.org> > > wrote: > > > >> On Tue, 29 Oct 2024, Chuck Guzis via cctalk wrote: > >>> The location of track 0 is radically different in the 96 tpi and 100 > tpi > >>> conventions--there's about a 6 track offset. 100 tpi drives were also > >>> spec-ed as being 77 track (like their 8" relatives). > >> Are the tracks offset from one side of a disk to the other? > >> > >> > --===============5786578238254699434==-- From cisin@xenosoft.com Mon Nov 4 02:44:13 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Sun, 03 Nov 2024 18:44:06 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4949481117944903645==" --===============4949481117944903645== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 3 Nov 2024, Steve Lewis via cctalk wrote: > Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 5.25" > drive, so I'm pretty sure they are actual 360KB disks). That said, I > haven't really fully confirmed if it's a 1.2M drive. TEAC FD-55GFR > 142-U, because I haven't actually come across any 1.2M formatted media. > I've wondered if maybe one of the heads on the D: drive the Sharp PC-5000's > dual disk drive might have some kind of issue (either the REad or Write > head, not sure which) - just since it seemed more likely to end up with > some bad sectors marked when using FORMAT.COM (whereas on other systems, > the same disk would format fine with no bad sectors). Teac FD-55GFR is a 1.2M drive that can also be used as a 720K 5.25" drive. (FD-55G is 1.2M; FD-55F is 720K) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============4949481117944903645==-- From imp@bsdimp.com Mon Nov 4 03:01:16 2024 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Sun, 03 Nov 2024 20:00:58 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5245351724728845266==" --===============5245351724728845266== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Nov 3, 2024, 7:44 PM Fred Cisin via cctalk wrote: > On Sun, 3 Nov 2024, Steve Lewis via cctalk wrote: > > Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 > 5.25" > > drive, so I'm pretty sure they are actual 360KB disks). That said, I > > haven't really fully confirmed if it's a 1.2M drive. TEAC FD-55GFR > > 142-U, because I haven't actually come across any 1.2M formatted media. > > I've wondered if maybe one of the heads on the D: drive the Sharp > PC-5000's > > dual disk drive might have some kind of issue (either the REad or Write > > head, not sure which) - just since it seemed more likely to end up with > > some bad sectors marked when using FORMAT.COM (whereas on other systems, > > the same disk would format fine with no bad sectors). > > Teac FD-55GFR is a 1.2M drive that can also be used as a 720K 5.25" drive. > (FD-55G is 1.2M; FD-55F is 720K) > I had a pair of FD-55FR in my DEC Rainbow for a while.... Warner -- > Grumpy Ol' Fred cisin(a)xenosoft.com > --===============5245351724728845266==-- From cclist@sydex.com Mon Nov 4 03:18:10 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Self modifying code was HCF Date: Mon, 04 Nov 2024 03:17:57 +0000 Message-ID: <7ceae103-2aba-4ea9-81e3-7801c50e158d@sydex.com> In-Reply-To: =?utf-8?q?=3CSA1PR11MB69410A32FC739D4C7C6DDEB8A3502=40SA1PR11MB?= =?utf-8?q?6941=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8873109071173302144==" --===============8873109071173302144== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/3/24 15:56, dwight wrote: > I/O addresses for the 8080 come to mind. > Dwight Well, in theory you could avoid that one by constructing 256-entry tables for IN and OUT instructions and using a computed CALL/JUMP to access the right one. The 8080 I/O address space is only 256 addresses. Not pretty, but a possible solution. --Chuck --===============8873109071173302144==-- From cclist@sydex.com Mon Nov 4 03:21:04 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 03:20:54 +0000 Message-ID: <9a864390-bd84-4dce-8a2f-e71a762016f5@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6601660239954667421==" --===============6601660239954667421== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/3/24 18:44, Fred Cisin via cctalk wrote: > On Sun, 3 Nov 2024, Steve Lewis via cctalk wrote: >> Non-descript 5.25  DS/DD  (they don't format as 1.2M disk using a 1.2 >> 5.25" >> drive, so I'm pretty sure they are actual 360KB disks).   That said, I >> haven't really fully confirmed if it's a 1.2M drive.  TEAC FD-55GFR >> 142-U, because I haven't actually come across any 1.2M formatted media. >> I've wondered if maybe one of the heads on the D: drive the Sharp >> PC-5000's >> dual disk drive might have some kind of issue (either the REad or Write >> head, not sure which) - just since it seemed more likely to end up with >> some bad sectors marked when using FORMAT.COM (whereas on other systems, >> the same disk would format fine with no bad sectors). > > Teac FD-55GFR is a 1.2M drive that can also be used as a 720K 5.25" drive. > (FD-55G is 1.2M; FD-55F is 720K) Just be sure to set the drive jumpers so that the spindle speed is 300 RPM, not 360, which is the usual default for PC drives. --Chuck --===============6601660239954667421==-- From ard.p850ug1@gmail.com Mon Nov 4 04:34:54 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Self modifying code was HCF Date: Mon, 04 Nov 2024 04:34:37 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR11MB69410A32FC739D4C7C6DDEB8A3502=40SA1PR11MB?= =?utf-8?q?6941=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6348863692073506376==" --===============6348863692073506376== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 4, 2024 at 12:05=E2=80=AFAM dwight via cctalk wrote: > > I/O addresses for the 8080 come to mind. BASIC-09 under OS-9 (6809 processor) lets you execute a system call from a BASIC program. The problem is that a system call is coded as a software interrupt instruction followed by a byte giving the call number. So doing that implies self-modifying code. But under OS-9, code modules are re-entrant and can be called by any process running on the machine. You could find the process is switched between storing the call number byte and executing the instruction. It gets round this by building a trivial program (basically a software interrupt, the call number byte, and a return instructio) on the user stack (which is local to each process) and then calling it there. On the HP9825 with a String Variables ROM and an Advanced Programming ROM, there is a documented instruction to store the contents of a string variable as a program line which of course you can then execute. This is one of the few high level languages I've seen with a specific instruction for self-modifyng code. -tony --===============6348863692073506376==-- From ard.p850ug1@gmail.com Mon Nov 4 04:37:40 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Mon, 04 Nov 2024 04:37:24 +0000 Message-ID: In-Reply-To: <20241103215922.CD4FD374034A@freecalypso.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5620404796919204336==" --===============5620404796919204336== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 4, 2024 at 4:06=E2=80=AFAM Mychaela Falconia via cctalk wrote: > > Paul Koning wrote: > > > 1. Show a one-word PDP-11 program that writes all of memory, in reverse o= rder. > > MOV -(PC),-(PC) Does that work on all models of PDP11? I had an idea that (as in C) the order of the decrements and reads was not specified by the instruction set definition and that on some machines (the 11/45?) it doubly decrements PC before reading or storing. -tony --===============5620404796919204336==-- From bfranchuk@jetnet.ab.ca Mon Nov 4 05:34:28 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 22:34:17 -0700 Message-ID: <7f422832-322b-41e9-a86a-0138acf1a904@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8684949457197413821==" --===============8684949457197413821== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote: > On Mon, Nov 4, 2024 at 4:06=E2=80=AFAM Mychaela Falconia via cctalk > wrote: >> >> Paul Koning wrote: >> >>> 1. Show a one-word PDP-11 program that writes all of memory, in reverse o= rder. >> >> MOV -(PC),-(PC) >=20 > Does that work on all models of PDP11? >=20 > I had an idea that (as in C) the order of the decrements and reads was > not specified by the instruction set definition and that on some > machines (the 11/45?) it doubly decrements PC before reading or > storing. >=20 > -tony Where there any user instructions between models that gave strange=20 behavior on the wrong machine? --===============8684949457197413821==-- From falcon@freecalypso.org Mon Nov 4 07:12:31 2024 From: Mychaela Falconia To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Sun, 03 Nov 2024 23:12:18 -0800 Message-ID: <20241104071225.E6A62374010E@freecalypso.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3143241966558177083==" --===============3143241966558177083== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Tony Duell wrote: [Context: MOV -(PC),-(PC) ] > Does that work on all models of PDP11? No idea, I just know that it worked on Soviet 1801VM1, which is where I learned it. Meanwhile, I am still struggling with the second part of Paul's original challenge: > 2. Show a one-word PDP-11 program that clears all of memory, > in forward order, halting on completion. The problem statement says that the trick must *clear* all of memory, which I read as making it all zeros, rather than some other clobber pattern. The "halting on completion" part makes sense: 000000 is the opcode for HALT, hence if there is a magic instruction running in a loop at the end of memory that writes zeros moving forward, once this write of zeros hits the executing code, halt will occur. But I am still not able to come up with a single-word PDP-11 instruction that does these two functions simultaneously: (1) decrements PC so that the instruction keeps re-executing, and (2) writes zeros moving forward. Paul gave this hint: > Hint: you get to pick the initial values of the registers. I can easily think of something like this: MOV -(PC),(R0)+ But this one won't satisfy the requirement of writing zeros: it does a forward clobber, but writes 014720 (the opcode for this instruction) instead of zeros. I thought of refining it like this: BIC -(PC),(R0)+ This one gets a bit closer in that it will clear _some_ bits to zero in every memory word, but still, it is not a write of all zeros. Then I thought about the XOR instruction that appears in later PDP-11 models; something like: XOR R0,-(PC) If R0 is preset to 074047 (the opcode), the instruction will overwrite itself with 0 word (HALT), and then the halt will happen. But that's only one word, not clearing all of memory, and of course it would be even simpler with: CLR -(PC) Why is there a -(PC) operand in each of my attempts above? Because I don't see another way to make the instruction keep re-executing. If it weren't for this re-execution requirement, the solution would be as simple as CLR (R0)+ but of course that one will result in the CPU executing garbage following this instruction after clearing just one memory word - not interesting... If PDP-11 had 3-operand instructions like VAXen do, we could do an instruction that has -(PC) as one operand, a preset register as the second operand to the addition or XOR or whatever, and something like (R0)+ as the destination operand - but we are talking about PDP-11 here, not VAX, and the requirement is for a single-word instruction. Thus I do not see how a single PDP-11 instruction can accomplish what is asked here - unless I am misinterpreting the problem statement... M~ --===============3143241966558177083==-- From gavin@learn.bio Mon Nov 4 07:15:27 2024 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Self modifying code was HCF Date: Mon, 04 Nov 2024 01:15:11 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2423545858073952882==" --===============2423545858073952882== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Nov 3, 2024 at 10:35 PM Tony Duell via cctalk wrote: > This is one of the few high level languages I've seen with a > specific instruction for self-modifying code. Don't forget the ALTER statement in COBOL which changes a GO TO statement in some paragraph somewhere to point to a different destination than what's written in the source code. COBOL has a few funky features. Another one is that you can have a sequence of Paragraphs: PARA-A. PARA-B. PARA-C. PARA-D. And in one place you can say PERFORM PARA-A THROUGH PARA-C, and in another place PERFORM PARA-B THROUGH PARA-D, etc. which means you have to somehow pass in the paragraph you want to return from and every paragraph has to end with a conditional return based on whether it's the requested exit point. Some machines had special machine instructions for COBOL Paragraph call and return to help deal with these and similar oddities. --===============2423545858073952882==-- From sqrfolkdnc@comcast.net Mon Nov 4 13:31:43 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] model dependent differences [was: HCF [was: System 360 question]] Date: Mon, 04 Nov 2024 07:31:36 -0600 Message-ID: <2074722879.1113357.1730727096541@connect.xfinity.com> In-Reply-To: <7f422832-322b-41e9-a86a-0138acf1a904@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4756156205205864448==" --===============4756156205205864448== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable not wrong, but in my benchmarks, the order of how long it took to clear out a= 255 byte area exactly reversed between the 370/168 and 3033. I hope I remem= ber all the ways, not sure if I remember the order, or the exact syntax. Not= included are the 'costs' of storage required for code and data areas. I did= not think to try with various byte alignments of the fields, or account for= mvcl being interuptable (though i ran during low activity times). this orde= r was fastest to slowest on 3033, slowest to fastest on 168. I did this afte= r reading a claim that the lm/stm was the fastest way. also inspired by a programmer that used a LOOP including "MVC field, field+1)= to left align a large alphanumeric field, that consumed 1/2 of the CPU time = for the main overnight posting run, causing online to not come up on time in = the morning...over 4 hours on the ONE instruction. xc field,field mvc field,field-1 mvc field,=3Dxl255'0' mvcl field,=3Dx'00' (well load the registers to accomplish this) stm/lm (store all but base reg, load them with zeros, several inline stm, res= tore) ...I wonder what the order would be in Hercules...anybody want to take the ch= allenge? I'd guess like the 168 maybe with the XC moved to be faster or fast= est. I had Hercules installed and running several times in the distant past,= but...without access to a legal zVM operating system, not of much interest t= o me now. 
--Carey
> On 11/03/2024 11:34 PM CST ben via cctalk wrote: >=20 > =20 > On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote: > > On Mon, Nov 4, 2024 at 4:06=E2=80=AFAM Mychaela Falconia via cctalk > > wrote: > >> > >> Paul Koning wrote: > >> > >>> 1. Show a one-word PDP-11 program that writes all of memory, in reverse= order. > >> > >> MOV -(PC),-(PC) > >=20 > > Does that work on all models of PDP11? > >=20 > > I had an idea that (as in C) the order of the decrements and reads was > > not specified by the instruction set definition and that on some > > machines (the 11/45?) it doubly decrements PC before reading or > > storing. > >=20 > > -tony >=20 > Where there any user instructions between models that gave strange=20 > behavior on the wrong machine? --===============4756156205205864448==-- From c.murray.mccullough@gmail.com Mon Nov 4 14:24:08 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] Innovations Date: Mon, 04 Nov 2024 09:23:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6742109325088806112==" --===============6742109325088806112== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit A lot happened in the computer industry in early Nov. in the past: Intel's x86 PC architecture was born; lo & behold Windows ME was released upon the world; for the corporate in us the IBM Portable Computer was introduced. The PC world hasn't been the same since. Happy computing, Murray 🙂 --===============6742109325088806112==-- From osi.superboard@gmail.com Mon Nov 4 14:25:05 2024 From: "osi.superboard" To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 14:24:53 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2268668685063592308==" --===============2268668685063592308== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Steve, from my experience, these "Non-descript" are often the cause for format error= s. Look for high quality disk media like Dysan 100 5.25 MD2D 2D/2D "BASF" MD2-DD "Maxell" or DS,DD from "3M" In addition, these "Non-descript" disk are most likely pre-formatted by facto= ry, so Degaussing is recommended or at least formatting on a 360k drive. The D: drive is the one of the external drives that has been in use most of t= he time, I guess. So it might be just the wear, or deposits of dirt on the heads. Careful head = cleaning makes most sense here. Thomas On 04.11.2024 02:10, Steve Lewis via cctalk wrote: > Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 5.25" > drive, so I'm pretty sure they are actual 360KB disks). That said, I > haven't really fully confirmed if it's a 1.2M drive. TEAC FD-55GFR > 142-U, because I haven't actually come across any 1.2M formatted media. > > I've wondered if maybe one of the heads on the D: drive the Sharp PC-5000's > dual disk drive might have some kind of issue (either the REad or Write > head, not sure which) - just since it seemed more likely to end up with > some bad sectors marked when using FORMAT.COM (whereas on other systems, > the same disk would format fine with no bad sectors). > > -Steve > > > On Thu, Oct 31, 2024 at 7:17=E2=80=AFAM osi.superboard via cctalk < > cctalk(a)classiccmp.org> wrote: > >> Steve, >> >> could you please explain, what exact disk media you are using. >> >> >> On 30.10.2024 05:03, Steve Lewis via cctalk wrote: >>> Fascinating notes! >>> >>> I did run into oddities when using a 360KB disks in between a 1.2M 5.25 >>> drive on the '386 and the 5.25 drive on the Sharp PC-5000. I forget my >>> exact sequence of events, but in short the MS-DOS 2.00 FORMAT.COM on the >>> Sharp PC-5000 would start marking a few bad sectors (sometimes just a few >>> KB, sometimes as much as 20KB of bad sectors). And yet those same disks >>> were formatted as just fine and no bad sectors over the '386. Or, if I >>> used IMD and wrote full MS-DOS 2.00 image to the disk, then the disk >> would >>> work (and boot) fine in the Sharp PC-5000. Without nit-picking the >>> specifics here (of whatever I did) - my lesson was there is definitely a >>> difference between a completely uninitialized disks, versus something >> that >>> has been previously formatted. Which, yeah, duh - but my real lesson >> was: >>> you can't always FORMAT.COM your way back into a bootable disk. If >>> something else has "touched" the boot sectors, then another system might >>> start flagging those as bad sectors. >>> >>> I'm not sure if IMD (ImageDisk) trumps all that? Meaning, whatever crap >> is >>> on the disk, does IMD not care? In otherwords, is using IMD kinda-sorta >>> like degaussing (and then applying whatever the image is)? It just >> seemed >>> to me that however I mangled the format on a disk, IMD was always able to >>> get me back into a usable (and bootable) disk. >>> >>> I do remember (vaguely for me) in the 80s we'd get boxes of uninitialized >>> disks, and there were generally warnings along the lines of once it was >>> formatted to whatever system you intended to use the disk for, it was >>> thereafter basically committed to being used for that system. (but it >>> seems only because, back in those days we didn't typically have the >> benefit >>> of something like IMD software or a Greazeweasal - and I imagine the >>> documentation from disk vendors didn't want to get into the weeds of >> waving >>> magnets around your disk, especially when they already had bold warnings >> of >>> keeping your disk the heck away from any magnets :) ) >>> >>> >>> >>> Regarding the article on SF rail replacing disk drives, to avoid >>> "catastrophic failure".... recall a while back, ActionRetro made a RAID >>> out of floppy disk drives (3.5"'s). With all the firmware going into >> modern >>> SSD's and M.2's, I ponder the irony of "old dumb mechanical drives" >>> actually being (in a way) more secure. >>> >>> >>> -Steve >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Oct 29, 2024 at 8:35=E2=80=AFPM Fred Cisin via cctalk < >> cctalk(a)classiccmp.org> >>> wrote: >>> >>>> On Tue, 29 Oct 2024, Chuck Guzis via cctalk wrote: >>>>> The location of track 0 is radically different in the 96 tpi and 100 >> tpi >>>>> conventions--there's about a 6 track offset. 100 tpi drives were also >>>>> spec-ed as being 77 track (like their 8" relatives). >>>> Are the tracks offset from one side of a disk to the other? >>>> >>>> --===============2268668685063592308==-- From paulkoning@comcast.net Mon Nov 4 15:29:26 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Mon, 04 Nov 2024 10:29:18 -0500 Message-ID: <0F1CD976-C96A-4592-AF53-AD47EDD64B8E@comcast.net> In-Reply-To: <7f422832-322b-41e9-a86a-0138acf1a904@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0017915764060838144==" --===============0017915764060838144== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 4, 2024, at 12:34 AM, ben via cctalk wrote: >=20 > On 2024-11-03 9:37 p.m., Tony Duell via cctalk wrote: >> On Mon, Nov 4, 2024 at 4:06=E2=80=AFAM Mychaela Falconia via cctalk >> wrote: >>>=20 >>> Paul Koning wrote: >>>=20 >>>> 1. Show a one-word PDP-11 program that writes all of memory, in reverse = order. >>>=20 >>> MOV -(PC),-(PC) >> Does that work on all models of PDP11? >> I had an idea that (as in C) the order of the decrements and reads was >> not specified by the instruction set definition and that on some >> machines (the 11/45?) it doubly decrements PC before reading or >> storing. >> -tony >=20 > Where there any user instructions between models that gave strange behavior= on the wrong machine? Yes, and they are documented in the PDP-11 architecture manual, in an appendi= x. But it cases that are machine dependent are more exotic, things like mixi= ng a register reference with an auto inc/dec of the same register. The magic= move will work on any of them. On the "one word clear", I missed a detail. I pointed out you get to initial= ize the registers. You can also initiate one memory word. In other words: c= hoose two words in memory, and registers contents, such that execution will g= ive you a memory full of zeroes and a halted machine. paul --===============0017915764060838144==-- From falcon@freecalypso.org Mon Nov 4 17:15:42 2024 From: Mychaela Falconia To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Mon, 04 Nov 2024 09:15:29 -0800 Message-ID: <20241104171537.758383740501@freecalypso.org> In-Reply-To: <0F1CD976-C96A-4592-AF53-AD47EDD64B8E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2345217009277413771==" --===============2345217009277413771== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Paul Koning wrote: > On the "one word clear", I missed a detail. I pointed out you get to > initialize the registers. You can also initiate one memory word. In other > words: choose two words in memory, and registers contents, such that > execution will give you a memory full of zeroes and a halted machine. OK, *now* the problem has a clear solution: 1) Write 000000 into memory word 015720; 2) Write 015720 [ MOV @-(PC),(R0)+ ] into the last word of system RAM; 3) Clear R0; 4) Jump to the last word of RAM where you wrote the 015720 instruction. This solution does require that the system RAM be of certain minimum size. Assuming power-of-2 sizes only, the machine must have at least 8 KiB of RAM, otherwise location 015720 does not exist. What was the smallest RAM configuration on PDP-11? M~ --===============2345217009277413771==-- From bfranchuk@jetnet.ab.ca Mon Nov 4 17:43:18 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Innovations Date: Mon, 04 Nov 2024 10:43:08 -0700 Message-ID: <6863eed4-6d82-4838-8a92-6b4bd8bf72f5@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6192134967727174377==" --===============6192134967727174377== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-11-04 7:23 a.m., Murray McCullough via cctalk wrote: > A lot happened in the computer industry in early Nov. in the past: Intel's > x86 PC architecture was born; lo & behold Windows ME was released upon the > world; for the corporate in us the IBM Portable Computer was introduced. > The PC world hasn't been the same since. > Happy computing, > Murray 🙂 2024 Ben has a new 18 bit computer design, using ATF1508 128 cell CPLD's. Of course I need the latest PeeCee to program them. https://store.rosco-m68k.com/products/little-atf-programmer Of course when I get the low cost programmer the price of 1508's go sky-high. About all I have for software is just the bootstrap in EEprom loaded in from the front panel. Just waiting for a newer memory card PCB's with a write protect switch so I don't lose my data, after I swap out my chips. Ben. ----- [on the phone while all the clocks chime at once] Dr. Emmett Brown: Are those my clocks I hear? Marty McFly: Yeah, it's 8:00. Dr. Emmett Brown: Perfect! My experiment worked! They're all exactly 25 minutes slow! --===============6192134967727174377==-- From bitwiz@12bitsbest.com Mon Nov 4 18:07:51 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] The other dectape Date: Mon, 04 Nov 2024 11:42:37 -0600 Message-ID: In-Reply-To: <20241104171537.758383740501@freecalypso.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8529049518770864149==" --===============8529049518770864149== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The other dectape (image below) 1 bit =- 1/8th inch 1 byte = 1 inch DECtp Tape Measure DEC DIGITAL EQUIPMENT CORPORATION - 1980's - Picture 1 of 5 --===============8529049518770864149==-- From cisin@xenosoft.com Mon Nov 4 18:21:25 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 10:21:17 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6614886656923597618==" --===============6614886656923597618== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 3 Nov 2024, Steve Lewis via cctalk wrote: > Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 5.25" > drive, so I'm pretty sure they are actual 360KB disks). That said, I > haven't really fully confirmed if it's a 1.2M drive. TEAC FD-55GFR > 142-U, because I haven't actually come across any 1.2M formatted media. Do they have hub reinforcing rings? If yes, then they are probably 360K If no, then they are probably 1.2M --===============6614886656923597618==-- From cisin@xenosoft.com Mon Nov 4 18:27:24 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 10:27:17 -0800 Message-ID: In-Reply-To: <9a864390-bd84-4dce-8a2f-e71a762016f5@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7491696831912408147==" --===============7491696831912408147== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit >>> haven't really fully confirmed if it's a 1.2M drive.  TEAC FD-55GFR >>> 142-U, because I haven't actually come across any 1.2M formatted media. >> Teac FD-55GFR is a 1.2M drive that can also be used as a 720K 5.25" drive. >> (FD-55G is 1.2M; FD-55F is 720K) On Mon, 4 Nov 2024, Chuck Guzis via cctalk wrote: > Just be sure to set the drive jumpers so that the spindle speed is 300 > RPM, not 360, which is the usual default for PC drives. Earlier, he mentioned having to switch data transfer rate from 250K bps to 300K bps: " I did have to change the IMD Settings to Sides Two, Double-step On, and the 250kps to300kps. I don't fully understand that last setting, but absolutely it was necessary - the IMD image file wouldn't write to disk otherwise." IFF that is the same drive, then THAT would certainly imply that the drive is currently running at 350 RPM (at 360 RPM, unless the data transfer rate is switched to 300K bps, each track will be too long to fit in a single revolution) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============7491696831912408147==-- From cisin@xenosoft.com Mon Nov 4 18:38:28 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 10:38:23 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3068698345678211321==" --===============3068698345678211321== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 5.25" >> drive, so I'm pretty sure they are actual 360KB disks). That said, I On Mon, 4 Nov 2024, osi.superboard via cctalk wrote: > from my experience, these "Non-descript" are often the cause for format=20 > errors. Look for high quality disk media like > Dysan 100 5.25 MD2D > 2D/2D "BASF" > MD2-DD "Maxell" or > DS,DD from "3M" Any Dysan disks are generally superior to most others. Even Verbatim "Datalife" are substantially more reliable than generics. (Verbatim, BEFORE "Datalife", were worse than generic) Although, in the 1990s, generic disks had improved to the point where they=20 were usually almost as good as the worst of the brand name ones. And=20 certainly better than SOME brand name disks, such as "Wabash', and some=20 batches of "Elephant" > In addition, these "Non-descript" disk are most likely pre-formatted by=20 > factory, so Degaussing is recommended or at least formatting on a 360k driv= e. Since he is trying to write 360K images to them, in a 1.2M drive, he=20 should definitely NOT format them in a 360K drive! Probably bulk erase, with a degausser, then do it again, then do it with a=20 different degausser? If they still won't work (after eliminating drive as problem), then staple=20 them. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============3068698345678211321==-- From bill.gunshannon@hotmail.com Mon Nov 4 20:08:57 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 15:08:35 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8818200081338543715==" --===============8818200081338543715== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/4/2024 1:38 PM, Fred Cisin via cctalk wrote: >>> Non-descript 5.25  DS/DD  (they don't format as 1.2M disk using a 1.2 >>> 5.25" >>> drive, so I'm pretty sure they are actual 360KB disks).   That said, I > > On Mon, 4 Nov 2024, osi.superboard via cctalk wrote: >> from my experience, these "Non-descript" are often the cause for >> format errors. Look for high quality disk media like >> Dysan 100 5.25 MD2D >> 2D/2D "BASF" >> MD2-DD "Maxell" or >> DS,DD from "3M" > > Any Dysan disks are generally superior to most others. > Even Verbatim "Datalife" are substantially more reliable than generics. > (Verbatim, BEFORE "Datalife", were worse than generic) > > > Although, in the 1990s, generic disks had improved to the point where > they were usually almost as good as the worst of the brand name ones. > And certainly better than SOME brand name disks, such as "Wabash', and > some batches of "Elephant" > I used Elephant. Still have piles of them and they are all still readable (and probably writable but I don't want to lose the data they hold.) > >> In addition, these "Non-descript" disk are most likely pre-formatted >> by factory, so Degaussing is recommended or at least formatting on a >> 360k drive. > > Since he is trying to write 360K images to them, in a 1.2M drive, he > should definitely NOT format them in a 360K drive! > > Probably bulk erase, with a degausser, then do it again, then do it with > a different degausser? > If they still won't work (after eliminating drive as problem), then > staple them. > The biggest laugh I ever had was when we complained about a problem writing floppies under UCSD Pascal on a Terak and their answer was to buy Terak Brand Floppies. bill --===============8818200081338543715==-- From cisin@xenosoft.com Mon Nov 4 20:16:41 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Mon, 04 Nov 2024 12:16:27 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CLV8P221MB14691AB1EFDE72238459EB76ED512=40LV8P221MB?= =?utf-8?q?1469=2ENAMP221=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0014641373262501393==" --===============0014641373262501393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 4 Nov 2024, Bill Gunshannon via cctalk wrote: > I used Elephant. Still have piles of them and they are all still > readable (and probably writable but I don't want to lose the data > they hold.) SOME batches of Elephant were quite good. > The biggest laugh I ever had was when we complained about a problem > writing floppies under UCSD Pascal on a Terak and their answer was to > buy Terak Brand Floppies. Sometimes, it is worth having one, just so that you can tell their "support" that their own brand doesn't work either. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============0014641373262501393==-- From paulkoning@comcast.net Mon Nov 4 20:23:55 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: HCF [was: System 360 question] Date: Mon, 04 Nov 2024 15:23:46 -0500 Message-ID: <9B7E2FFD-E86F-45F4-AD19-021D4ABA4A3E@comcast.net> In-Reply-To: <20241104171537.758383740501@freecalypso.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7306683062951058744==" --===============7306683062951058744== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 4, 2024, at 12:15 PM, Mychaela Falconia w= rote: >=20 > Paul Koning wrote: >=20 >> On the "one word clear", I missed a detail. I pointed out you get to >> initialize the registers. You can also initiate one memory word. In other >> words: choose two words in memory, and registers contents, such that >> execution will give you a memory full of zeroes and a halted machine. >=20 > OK, *now* the problem has a clear solution: >=20 > 1) Write 000000 into memory word 015720; > 2) Write 015720 [ MOV @-(PC),(R0)+ ] into the last word of system RAM; > 3) Clear R0; > 4) Jump to the last word of RAM where you wrote the 015720 instruction. >=20 > This solution does require that the system RAM be of certain minimum > size. Assuming power-of-2 sizes only, the machine must have at least > 8 KiB of RAM, otherwise location 015720 does not exist. What was the > smallest RAM configuration on PDP-11? Yes, that's the correct answer. 4 kW is the smallest PDP-11 memory I know of, though I don't have direct expo= sure to the T-11. paul --===============7306683062951058744==-- From cliendo@gmail.com Mon Nov 4 21:25:16 2024 From: Christian Liendo To: cctalk@classiccmp.org Subject: [cctalk] Re: Innovations Date: Mon, 04 Nov 2024 16:25:00 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3844075723684232510==" --===============3844075723684232510== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The prototype of the Altair 8800 was completed in Oct 1974 and was announced in Jan 1975. On Mon, Nov 4, 2024 at 10:01 AM Murray McCullough via cctalk wrote: > > A lot happened in the computer industry in early Nov. in the past: Intel's > x86 PC architecture was born; lo & behold Windows ME was released upon the > world; for the corporate in us the IBM Portable Computer was introduced. > The PC world hasn't been the same since. > Happy computing, > Murray 🙂 --===============3844075723684232510==-- From lproven@gmail.com Tue Nov 5 12:11:49 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Tue, 05 Nov 2024 12:11:31 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CLV8P221MB14691AB1EFDE72238459EB76ED512=40LV8P221MB?= =?utf-8?q?1469=2ENAMP221=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8611107193403301396==" --===============8611107193403301396== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 4 Nov 2024 at 20:09, Bill Gunshannon via cctalk wrote: > > I used Elephant. Still have piles of them and they are all still > readable (and probably writable but I don't want to lose the data > they hold.) This is interesting. I had no recollection at all of Elephant branded media, and I wondered if it might have been a US-only thing... so I Googled them, and as soon as I saw the detailed full-colour logo, I immediately remembered. There is some deeper point about recollection here that is probably doctrine taught in marketing schools... if there are such places. -- 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 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============8611107193403301396==-- From barto@kdbarto.org Tue Nov 5 18:13:47 2024 From: David Barto To: cctalk@classiccmp.org Subject: [cctalk] Re: Innovations Date: Mon, 04 Nov 2024 16:55:41 +0000 Message-ID: <280403EB-7E1B-49AA-B8E7-965B6A6A1169@kdbarto.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1512470159103899664==" --===============1512470159103899664== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable And early November in the present when iNtel was replaced in the DJIA with Nv= idia. David > On Nov 4, 2024, at 6:23=E2=80=AFAM, Murray McCullough via cctalk wrote: >=20 > A lot happened in the computer industry in early Nov. in the past: Intel's > x86 PC architecture was born; lo & behold Windows ME was released upon the > world; for the corporate in us the IBM Portable Computer was introduced. > The PC world hasn't been the same since. > Happy computing, > Murray =F0=9F=99=82 Do the right thing. It will gratify some people and astonish the rest. --Mark Twain. David Barto barto(a)kdbarto.org --===============1512470159103899664==-- From cisin@xenosoft.com Tue Nov 5 20:09:46 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Tue, 05 Nov 2024 12:09:41 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4256798409124656370==" --===============4256798409124656370== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 5 Nov 2024, Liam Proven via cctalk wrote: > This is interesting. I had no recollection at all of Elephant branded > media, and I wondered if it might have been a US-only thing... so I > Googled them, and as soon as I saw the detailed full-colour logo, I > immediately remembered. > > There is some deeper point about recollection here that is probably > doctrine taught in marketing schools... if there are such places. Elephant was supposedly the highest MARGIN for floppy disks. While that might seem to imply a very low cost one sold as premium, a high margin is not necessarily an indicator of low quality. For example, for many years, Apple produced very high quality products, while having the highest margin - they knew that could get people to pay more. I seriously doubt that Leading Edge had a factory, but no idea whose disks they rebranded. Quite possibly a no-name generic. Elephant's marketing was colorful, at a time when all others were very staid. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============4256798409124656370==-- From mhs.stein@gmail.com Wed Nov 6 16:05:31 2024 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 11:05:13 -0500 Message-ID: In-Reply-To: <9a864390-bd84-4dce-8a2f-e71a762016f5@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4676188044118064653==" --===============4676188044118064653== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I use a strobe disk glued to a fridge magnet that I stick on the spindle motor of 5 1/4" drives to confirm the speed; the trouble is that it's becoming difficult these days to find lamps that emit light at 60 Hz. ;-) On Sun, Nov 3, 2024 at 10:21 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 11/3/24 18:44, Fred Cisin via cctalk wrote: > > On Sun, 3 Nov 2024, Steve Lewis via cctalk wrote: > >> Non-descript 5.25 DS/DD (they don't format as 1.2M disk using a 1.2 > >> 5.25" > >> drive, so I'm pretty sure they are actual 360KB disks). That said, I > >> haven't really fully confirmed if it's a 1.2M drive. TEAC FD-55GFR > >> 142-U, because I haven't actually come across any 1.2M formatted media. > >> I've wondered if maybe one of the heads on the D: drive the Sharp > >> PC-5000's > >> dual disk drive might have some kind of issue (either the REad or Write > >> head, not sure which) - just since it seemed more likely to end up with > >> some bad sectors marked when using FORMAT.COM (whereas on other > systems, > >> the same disk would format fine with no bad sectors). > > > > Teac FD-55GFR is a 1.2M drive that can also be used as a 720K 5.25" > drive. > > (FD-55G is 1.2M; FD-55F is 720K) > > Just be sure to set the drive jumpers so that the spindle speed is 300 > RPM, not 360, which is the usual default for PC drives. > > --Chuck > > --===============4676188044118064653==-- From abuse@cabal.org.uk Wed Nov 6 16:32:12 2024 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 17:32:03 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8519998987300057960==" --===============8519998987300057960== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Nov 06, 2024 at 11:05:13AM -0500, Mike Stein via cctalk wrote: > I use a strobe disk glued to a fridge magnet that I stick on the spindle > motor of 5 1/4" drives to confirm the speed; the trouble is that it's > becoming difficult these days to find lamps that emit light at 60 Hz. ;-) Those landfill-grade bulbs from AliExpress will probably do the job just fine. Make sure you don't pay more than a couple of bucks since otherwise they might have spent an extra couple of cents on the necessary smoothing capacitors. I have one rattling about which gives a nice 50Hz flicker, and its main job is to remind me why I don't miss CRTs whenever I get a nostalgia fix and consider acquiring one. It was something like €1.86, and almost certainly exactly $2 at the prevailing exchange rate. --===============8519998987300057960==-- From bear@typewritten.org Wed Nov 6 16:32:23 2024 From: "r.stricklin" To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 08:31:01 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6059008647088757219==" --===============6059008647088757219== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 6, 2024, at 8:05 AM, Mike Stein via cctalk = wrote: >=20 > I use a strobe disk glued to a fridge magnet that I stick on the spindle > motor of 5 1/4" drives to confirm the speed; the trouble is that it's > becoming difficult these days to find lamps that emit light at 60 Hz. ;-) Turns out there are strobe light tachometer apps for smart phones that can be= at least as useful as a lamp. I was able to use one to set the spindle speed= of an Atari 1050 (288 RPM), despite the tach disc being for a 300 RPM drive,= by setting the strobe frequency to 57.6 Hz. ok bear. --===============6059008647088757219==-- From ard.p850ug1@gmail.com Wed Nov 6 16:39:58 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 16:39:41 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3746135495661543041==" --===============3746135495661543041== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Nov 6, 2024 at 4:31 PM Mike Stein via cctalk wrote: > > I use a strobe disk glued to a fridge magnet that I stick on the spindle > motor of 5 1/4" drives to confirm the speed; the trouble is that it's > becoming difficult these days to find lamps that emit light at 60 Hz. ;-) I made a simple circuit (3 common TTL counter chips, a couple of transistors, a 4.91...MHz crystal oscillator module, 7805 regulator and a few passive components) that flashes 4 white LEDs either 100 or 120 times a second wth a 1/16th duty cycle. It runs off a 12V DC supply This will simulate a mains lamp for such a strobe disk, and of course can be used on either '50Hz' or '60Hz' markings no matter what your mains frequency is. The crystall osciltor module is easily accurate enough for setting up such motor speed controllers. I'd be happy to share the schematic but of course I can't post it here. If you want to avoid electronics, then stroboscopic tuning fork? -tony --===============3746135495661543041==-- From dkelvey@hotmail.com Wed Nov 6 17:21:55 2024 From: dwight To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 17:21:44 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6101282779406452703==" --===============6101282779406452703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'd think a diode, white LED and a resistor would make a good enough strobe. Maybe 2 resistors to isolate the AC lines enough a little better. Dwight ________________________________ From: Tony Duell via cctalk Sent: Wednesday, November 6, 2024 8:39 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: Mike Stein ; Tony Duell Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Loo= king for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) On Wed, Nov 6, 2024 at 4:31=E2=80=AFPM Mike Stein via cctalk wrote: > > I use a strobe disk glued to a fridge magnet that I stick on the spindle > motor of 5 1/4" drives to confirm the speed; the trouble is that it's > becoming difficult these days to find lamps that emit light at 60 Hz. ;-) I made a simple circuit (3 common TTL counter chips, a couple of transistors, a 4.91...MHz crystal oscillator module, 7805 regulator and a few passive components) that flashes 4 white LEDs either 100 or 120 times a second wth a 1/16th duty cycle. It runs off a 12V DC supply This will simulate a mains lamp for such a strobe disk, and of course can be used on either '50Hz' or '60Hz' markings no matter what your mains frequency is. The crystall osciltor module is easily accurate enough for setting up such motor speed controllers. I'd be happy to share the schematic but of course I can't post it here. If you want to avoid electronics, then stroboscopic tuning fork? -tony --===============6101282779406452703==-- From ard.p850ug1@gmail.com Wed Nov 6 17:59:53 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 17:59:37 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR11MB6941B5BEB09BD8F6174DBDCFA3532=40SA1PR11MB?= =?utf-8?q?6941=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1322663901128585709==" --===============1322663901128585709== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Nov 6, 2024 at 5:21 PM dwight wrote: > > I'd think a diode, white LED and a resistor would make a good enough strobe. > Maybe 2 resistors to isolate the AC lines enough a little better. Quite likely. Actually the traditional mains lamp stroboscope flashes twice per cycle, so you might want 2 white LEDs in inverse parallel. I wanted something that I could run off a DC supply and which could handle '60Hz' markings in the UK. I have at least one device with a set of black and white bars for 60Hz mains but not for 50Hz. Another advantage is the fact that the LEDs are only on for 1/16th of the time gives a very clear pattern. The bars look sharp and you can easily see if they are jitterng about due to bad bearings, drive belt issues, etc. -tony --===============1322663901128585709==-- From mhs.stein@gmail.com Wed Nov 6 18:10:40 2024 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 13:10:21 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4178071839827803576==" --===============4178071839827803576== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I keep an oldskool fluorescent desk lamp around for that reason; also makes a handy desk lamp ;-) On Wed, Nov 6, 2024 at 12:59 PM Tony Duell wrote: > On Wed, Nov 6, 2024 at 5:21 PM dwight wrote: > > > > I'd think a diode, white LED and a resistor would make a good enough > strobe. > > Maybe 2 resistors to isolate the AC lines enough a little better. > > Quite likely. Actually the traditional mains lamp stroboscope flashes > twice per cycle, so you might want 2 white LEDs in inverse parallel. > > I wanted something that I could run off a DC supply and which could > handle '60Hz' markings in the UK. I have at least one device with a > set of black and white bars for 60Hz mains but not for 50Hz. > > Another advantage is the fact that the LEDs are only on for 1/16th of > the time gives a very clear pattern. The bars look sharp and you can > easily see if they are jitterng about due to bad bearings, drive belt > issues, etc. > > -tony > --===============4178071839827803576==-- From cclist@sydex.com Wed Nov 6 18:22:40 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 18:22:31 +0000 Message-ID: <82dc9cbd-dd19-4dd2-b659-b7d58c210565@sydex.com> In-Reply-To: =?utf-8?q?=3CSA1PR11MB6941B5BEB09BD8F6174DBDCFA3532=40SA1PR11MB?= =?utf-8?q?6941=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2004209609593567801==" --===============2004209609593567801== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/6/24 09:21, dwight via cctalk wrote: > I'd think a diode, white LED and a resistor would make a good enough strobe. > Maybe 2 resistors to isolate the AC lines enough a little better. A lot of the Chinese nightlights use capacitor droppers. I'd opt for a green, blue or red LED rather than a white one. No phosphor after-glow. As a matter of fact, I've got a couple of the blue nightlights and I can see the flicker... --===============2004209609593567801==-- From dkelvey@hotmail.com Wed Nov 6 19:13:11 2024 From: dwight To: cctalk@classiccmp.org Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 19:13:01 +0000 Message-ID: In-Reply-To: <82dc9cbd-dd19-4dd2-b659-b7d58c210565@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2350143216764032578==" --===============2350143216764032578== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'd not though about the 120 hz flashes. A full wave bridge might be better. = Also, a diode, backwards across the LED would be a good idea. Stray capacitan= ce could put a higher voltage on the LED backword that it might not like. A capacitive dropper could be used. There might be an issue with the sharpness ofthe turn on of the LED. This cou= ld be trimmed with a zener in series and a resistor in parallel with the enti= re assembly. It is hard to desribe in text. The idea would be that the resist= or would shunt some of the current until the voltage was high enough to turn = on zener. The current would then pass through LED and the shunt resistor. The= main voltage drop could be a capacitor or a resistor as a maximum of 10 mill= iamps is mostly all that is needed. Other more clever ideas could be used to make it pulse on for the peaks only,= using a diac or such or a pair of transistors. ________________________________ From: Chuck Guzis via cctalk Sent: Wednesday, November 6, 2024 10:22 AM To: dwight via cctalk Cc: Chuck Guzis Subject: [cctalk] Re: Running DOS executables on other versions of DOSRe: Loo= king for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) On 11/6/24 09:21, dwight via cctalk wrote: > I'd think a diode, white LED and a resistor would make a good enough strobe. > Maybe 2 resistors to isolate the AC lines enough a little better. A lot of the Chinese nightlights use capacitor droppers. I'd opt for a green, blue or red LED rather than a white one. No phosphor after-glow. As a matter of fact, I've got a couple of the blue nightlights and I can see the flicker... --===============2350143216764032578==-- From bhilpert@shaw.ca Wed Nov 6 19:28:32 2024 From: Brent Hilpert To: cctalk@classiccmp.org Subject: [cctalk] mains stroboscope / was Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Wed, 06 Nov 2024 11:28:26 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CSA1PR11MB6941485A39D56F79369613C9A3532=40SA1PR11MB?= =?utf-8?q?6941=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8171418218014722463==" --===============8171418218014722463== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The old common standard for a mains stroboscope was a neon bulb (+resistor). They are still widely available, simple and inexpensive. No, they are not very bright and need some shading or otherwise reduced ambie= nt light, but for a tool of infrequent use... --===============8171418218014722463==-- From cclist@sytse.net Thu Nov 7 19:41:28 2024 From: Sytse van Slooten To: cctalk@classiccmp.org Subject: [cctalk] looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 20:36:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1280603760119452009==" --===============1280603760119452009== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi all, I have a HP 1640B that I'm trying to get to work. However I can't find any in= formation about it, and while the machine itself it straightforward enough (a= nd I remember enough from when I was using it in my first dayjob) I can not f= ind anything about how to use the GPIB interface that it has. The reason I'm interested is, we've finally managed to add GPIB support to th= e PDP2011-MINC fpga implementation, and I'd like to test against a different = target than the relatively modern Philips/Fluke counter I'm now using. And th= e 1640B is the only other GPIB instrument I have... The HP doesn't seem to know the ID? command (that causes an error message on = the screen). It does respond to a newline (the standard is-this-listener-pres= ent test that the MINC code implements), so at least something is working. Does anyone here have any docs on the HP 1640B? It'd be very helpful at least= to know which GPIB commands are implemented. thanks in advance! Sytse --===============1280603760119452009==-- From wayne.sudol@hotmail.com Thu Nov 7 21:30:46 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 21:30:36 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8415536761150127442==" --===============8415536761150127442== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There are some available on ebay. Just search =E2=80=9Chp 2640b=E2=80=9D Sent from my Dec Alphastation 200. > On Nov 7, 2024, at 11:41, Sytse van Slooten via cctalk wrote: >=20 > =EF=BB=BFHi all, >=20 > I have a HP 1640B that I'm trying to get to work. However I can't find any = information about it, and while the machine itself it straightforward enough = (and I remember enough from when I was using it in my first dayjob) I can not= find anything about how to use the GPIB interface that it has. >=20 > The reason I'm interested is, we've finally managed to add GPIB support to = the PDP2011-MINC fpga implementation, and I'd like to test against a differen= t target than the relatively modern Philips/Fluke counter I'm now using. And = the 1640B is the only other GPIB instrument I have... >=20 > The HP doesn't seem to know the ID? command (that causes an error message o= n the screen). It does respond to a newline (the standard is-this-listener-pr= esent test that the MINC code implements), so at least something is working. >=20 > Does anyone here have any docs on the HP 1640B? It'd be very helpful at lea= st to know which GPIB commands are implemented. >=20 > thanks in advance! >=20 > Sytse --===============8415536761150127442==-- From holm@freibergnet.de Thu Nov 7 21:33:01 2024 From: Holm Tiffe To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 22:32:43 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5587161643728259110==" --===============5587161643728259110== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sytse van Slooten via cctalk wrote: > Hi all, >=20 > I have a HP 1640B that I'm trying to get to work. However I can't find any = information about it, and while the machine itself it straightforward enough = (and I remember enough from when I was using it in my first dayjob) I can not= find anything about how to use the GPIB interface that it has. >=20 > The reason I'm interested is, we've finally managed to add GPIB support to = the PDP2011-MINC fpga implementation, and I'd like to test against a differen= t target than the relatively modern Philips/Fluke counter I'm now using. And = the 1640B is the only other GPIB instrument I have... >=20 > The HP doesn't seem to know the ID? command (that causes an error message o= n the screen). It does respond to a newline (the standard is-this-listener-pr= esent test that the MINC code implements), so at least something is working. >=20 > Does anyone here have any docs on the HP 1640B? It'd be very helpful at lea= st to know which GPIB commands are implemented. >=20 > thanks in advance! >=20 > Sytse I have an HP1631D Logic Analyzer and it has an HPIB (GPIB) Port too, but as far as I know it is only used to connect a special HP Floppy Disc Drive with HPIB bus, the HP9122 for example, others exist, even a hard drive. It is used to load and store measurements and loading disassemblers. Maybe it can handle a printer too. I've got such an HP9122 later and tested it with the Analyzer...works. (BTW: does someone have Z80 an 6809 Disassemblers for the 1631D?) Regards, Holm --=20 Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,=20 Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583 info(a)tsht.de Tel +49 37292 709778 Mobil: 0172 8790 741 --===============5587161643728259110==-- From cclist@sytse.net Thu Nov 7 21:49:25 2024 From: Sytse van Slooten To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 22:49:18 +0100 Message-ID: <1901B8A3-11AB-4A1F-9FBA-D6472F0E191D@sytse.net> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181A50F7D2ED29852E2B6B2E45C2=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7474809448531880439==" --===============7474809448531880439== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yeah I saw that, but I'm a bit reluctant to blindly pay USD 50 for something = that might not even have any detail on what I'm looking for. After all, I don= 't need a full manual, and certainly not a collector-worthy copy. I just need= this specific information. > On 7 Nov 2024, at 22:30, Wayne S wrote: >=20 > There are some available on ebay. Just search =E2=80=9Chp 2640b=E2=80=9D >=20 > Sent from my Dec Alphastation 200. >=20 >> On Nov 7, 2024, at 11:41, Sytse van Slooten via cctalk wrote: >>=20 >> =EF=BB=BFHi all, >>=20 >> I have a HP 1640B that I'm trying to get to work. However I can't find any= information about it, and while the machine itself it straightforward enough= (and I remember enough from when I was using it in my first dayjob) I can no= t find anything about how to use the GPIB interface that it has. >>=20 >> The reason I'm interested is, we've finally managed to add GPIB support to= the PDP2011-MINC fpga implementation, and I'd like to test against a differe= nt target than the relatively modern Philips/Fluke counter I'm now using. And= the 1640B is the only other GPIB instrument I have... >>=20 >> The HP doesn't seem to know the ID? command (that causes an error message = on the screen). It does respond to a newline (the standard is-this-listener-p= resent test that the MINC code implements), so at least something is working. >>=20 >> Does anyone here have any docs on the HP 1640B? It'd be very helpful at le= ast to know which GPIB commands are implemented. >>=20 >> thanks in advance! >>=20 >> Sytse --===============7474809448531880439==-- From wayne.sudol@hotmail.com Thu Nov 7 22:05:16 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 22:05:10 +0000 Message-ID: In-Reply-To: <1901B8A3-11AB-4A1F-9FBA-D6472F0E191D@sytse.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1291515623125657460==" --===============1291515623125657460== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bitsavers has some manuals for 1630 and 1650. Maybe those will give you enoug= h info to be useful? Sent from my Dec Alphastation 200 > On Nov 7, 2024, at 13:49, Sytse van Slooten via cctalk wrote: >=20 > =EF=BB=BFYeah I saw that, but I'm a bit reluctant to blindly pay USD 50 for= something that might not even have any detail on what I'm looking for. After= all, I don't need a full manual, and certainly not a collector-worthy copy. = I just need this specific information. >=20 >> On 7 Nov 2024, at 22:30, Wayne S wrote: >>=20 >> There are some available on ebay. Just search =E2=80=9Chp 2640b=E2=80=9D >>=20 >> Sent from my Dec Alphastation 200. >>=20 >>>> On Nov 7, 2024, at 11:41, Sytse van Slooten via cctalk wrote: >>>=20 >>> =EF=BB=BFHi all, >>>=20 >>> I have a HP 1640B that I'm trying to get to work. However I can't find an= y information about it, and while the machine itself it straightforward enoug= h (and I remember enough from when I was using it in my first dayjob) I can n= ot find anything about how to use the GPIB interface that it has. >>>=20 >>> The reason I'm interested is, we've finally managed to add GPIB support t= o the PDP2011-MINC fpga implementation, and I'd like to test against a differ= ent target than the relatively modern Philips/Fluke counter I'm now using. An= d the 1640B is the only other GPIB instrument I have... >>>=20 >>> The HP doesn't seem to know the ID? command (that causes an error message= on the screen). It does respond to a newline (the standard is-this-listener-= present test that the MINC code implements), so at least something is working. >>>=20 >>> Does anyone here have any docs on the HP 1640B? It'd be very helpful at l= east to know which GPIB commands are implemented. >>>=20 >>> thanks in advance! >>>=20 >>> Sytse >=20 --===============1291515623125657460==-- From artgodwin@gmail.com Thu Nov 7 23:25:13 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 23:24:56 +0000 Message-ID: In-Reply-To: <1901B8A3-11AB-4A1F-9FBA-D6472F0E191D@sytse.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7040787196874690054==" --===============7040787196874690054== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit You could try https://groups.io/g/VintHPcom/messages https://groups.io/g/HP-Agilent-Keysight-equipment https://groups.io/g/logicanalyzers/messages I couldn't see it on BAMA of K04BB but there are others. The other possibility is to pull and read the ROMs - sometimes HPIB commands show up as literal text. On Thu, Nov 7, 2024 at 9:56 PM Sytse van Slooten via cctalk < cctalk(a)classiccmp.org> wrote: > Yeah I saw that, but I'm a bit reluctant to blindly pay USD 50 for > something that might not even have any detail on what I'm looking for. > After all, I don't need a full manual, and certainly not a collector-worthy > copy. I just need this specific information. > > > On 7 Nov 2024, at 22:30, Wayne S wrote: > > > > There are some available on ebay. Just search “hp 2640b” > > > > Sent from my Dec Alphastation 200. > > > >> On Nov 7, 2024, at 11:41, Sytse van Slooten via cctalk < > cctalk(a)classiccmp.org> wrote: > >> > >> Hi all, > >> > >> I have a HP 1640B that I'm trying to get to work. However I can't find > any information about it, and while the machine itself it straightforward > enough (and I remember enough from when I was using it in my first dayjob) > I can not find anything about how to use the GPIB interface that it has. > >> > >> The reason I'm interested is, we've finally managed to add GPIB support > to the PDP2011-MINC fpga implementation, and I'd like to test against a > different target than the relatively modern Philips/Fluke counter I'm now > using. And the 1640B is the only other GPIB instrument I have... > >> > >> The HP doesn't seem to know the ID? command (that causes an error > message on the screen). It does respond to a newline (the standard > is-this-listener-present test that the MINC code implements), so at least > something is working. > >> > >> Does anyone here have any docs on the HP 1640B? It'd be very helpful at > least to know which GPIB commands are implemented. > >> > >> thanks in advance! > >> > >> Sytse > > --===============7040787196874690054==-- From artgodwin@gmail.com Thu Nov 7 23:38:45 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 23:38:29 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8938049181452599249==" --===============8938049181452599249== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit There's also this one. May be more or less likely to have HPIB commands than the service manuals. https://www.ebay.co.uk/itm/232562875321 On Thu, Nov 7, 2024 at 11:24 PM Adrian Godwin wrote: > You could try > > https://groups.io/g/VintHPcom/messages > https://groups.io/g/HP-Agilent-Keysight-equipment > https://groups.io/g/logicanalyzers/messages > > I couldn't see it on BAMA of K04BB but there are others. > The other possibility is to pull and read the ROMs - sometimes HPIB > commands show up as literal text. > > > On Thu, Nov 7, 2024 at 9:56 PM Sytse van Slooten via cctalk < > cctalk(a)classiccmp.org> wrote: > >> Yeah I saw that, but I'm a bit reluctant to blindly pay USD 50 for >> something that might not even have any detail on what I'm looking for. >> After all, I don't need a full manual, and certainly not a collector-worthy >> copy. I just need this specific information. >> >> > On 7 Nov 2024, at 22:30, Wayne S wrote: >> > >> > There are some available on ebay. Just search “hp 2640b” >> > >> > Sent from my Dec Alphastation 200. >> > >> >> On Nov 7, 2024, at 11:41, Sytse van Slooten via cctalk < >> cctalk(a)classiccmp.org> wrote: >> >> >> >> Hi all, >> >> >> >> I have a HP 1640B that I'm trying to get to work. However I can't find >> any information about it, and while the machine itself it straightforward >> enough (and I remember enough from when I was using it in my first dayjob) >> I can not find anything about how to use the GPIB interface that it has. >> >> >> >> The reason I'm interested is, we've finally managed to add GPIB >> support to the PDP2011-MINC fpga implementation, and I'd like to test >> against a different target than the relatively modern Philips/Fluke counter >> I'm now using. And the 1640B is the only other GPIB instrument I have... >> >> >> >> The HP doesn't seem to know the ID? command (that causes an error >> message on the screen). It does respond to a newline (the standard >> is-this-listener-present test that the MINC code implements), so at least >> something is working. >> >> >> >> Does anyone here have any docs on the HP 1640B? It'd be very helpful >> at least to know which GPIB commands are implemented. >> >> >> >> thanks in advance! >> >> >> >> Sytse >> >> --===============8938049181452599249==-- From guykd@optusnet.com.au Fri Nov 8 02:00:23 2024 From: Guy Dunphy To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Fri, 08 Nov 2024 12:53:35 +1100 Message-ID: <3.0.6.32.20241108125335.017e5890@mail.optusnet.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7690231845671456457==" --===============7690231845671456457== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable How ironic. I have a 1640B _without_ the HPIB option board. I've been trying = to find that board to buy, without any luck so far. But I _did_ buy this: "HP 01281-90904 1640B OPTION 001 install & service manu= al (10281A) (HP-IB)" Now to try to find it, and see if it's short enough to be an easy scan. Guy At 08:36 PM 7/11/2024 +0100, you wrote: >Hi all, > >I have a HP 1640B that I'm trying to get to work. However I can't find any i= nformation about it, and while the machine itself it straightforward enough (= and I remember enough from when I was using it in my first dayjob) I can not = find anything about how to use the GPIB interface that it has. > >The reason I'm interested is, we've finally managed to add GPIB support to t= he PDP2011-MINC fpga implementation, and I'd like to test against a different= target than the relatively modern Philips/Fluke counter I'm now using. And t= he 1640B is the only other GPIB instrument I have... > >The HP doesn't seem to know the ID? command (that causes an error message on= the screen). It does respond to a newline (the standard is-this-listener-pre= sent test that the MINC code implements), so at least something is working. > >Does anyone here have any docs on the HP 1640B? It'd be very helpful at leas= t to know which GPIB commands are implemented. > >thanks in advance! > >Sytse --===============7690231845671456457==-- From glen.slick@gmail.com Fri Nov 8 05:24:28 2024 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 21:24:12 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6026981845047557483==" --===============6026981845047557483== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 7, 2024 at 8:41=E2=80=AFPM Holm Tiffe via cctalk wrote: > > I have an HP1631D Logic Analyzer and it has an HPIB (GPIB) Port too, but > as far as I know it is only used to connect a special HP Floppy Disc Drive > with HPIB bus, the HP9122 for example, others exist, even a hard drive. > It is used to load and store measurements and loading disassemblers. > Maybe it can handle a printer too. The HP 163x logic analyzer GPIB interface can be used for remote control of the analyzer. See Appendix C, Using the HP-IB or HP-IL Interface http://www.bitsavers.org/test_equipment/hp/163x/01630-90907_1630_Operating_Ma= nual_Oct83.pdf See Chapter 10, Using HP-IB or HP-IL Interface: http://www.bitsavers.org/test_equipment/hp/163x/01631-90904_1631oper_Aug85.pdf > (BTW: does someone have Z80 an 6809 Disassemblers for the 1631D?) Yes, those exist. https://www.eevblog.com/forum/testgear/searching-for-a-hp-1630-hp-1631-invers= e-assembler-files/ --===============6026981845047557483==-- From sytse@sytse.net Fri Nov 8 06:28:31 2024 From: Sytse van Slooten To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Thu, 07 Nov 2024 22:55:41 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1608237747220104189==" --===============1608237747220104189== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1640B is a very different thing - I should've added that it's basically a glo= rified RS232 breakout box, and nothing like a 'logic analyzer'.=20 It definitely won't connect to peripherals itself - there's a very obvious la= ck of buttons and menus to configure something like that. I suspect that the GPIB functionality will be about managing what is in the p= rogrammable buffers that it can send out in response to some input on the ser= ial link it is monitoring. But how :-) > On 7 Nov 2024, at 22:32, Holm Tiffe via cctalk wr= ote: >=20 > Sytse van Slooten via cctalk wrote: >=20 >> Hi all, >>=20 >> I have a HP 1640B that I'm trying to get to work. However I can't find any= information about it, and while the machine itself it straightforward enough= (and I remember enough from when I was using it in my first dayjob) I can no= t find anything about how to use the GPIB interface that it has. >>=20 >> The reason I'm interested is, we've finally managed to add GPIB support to= the PDP2011-MINC fpga implementation, and I'd like to test against a differe= nt target than the relatively modern Philips/Fluke counter I'm now using. And= the 1640B is the only other GPIB instrument I have... >>=20 >> The HP doesn't seem to know the ID? command (that causes an error message = on the screen). It does respond to a newline (the standard is-this-listener-p= resent test that the MINC code implements), so at least something is working. >>=20 >> Does anyone here have any docs on the HP 1640B? It'd be very helpful at le= ast to know which GPIB commands are implemented. >>=20 >> thanks in advance! >>=20 >> Sytse >=20 > I have an HP1631D Logic Analyzer and it has an HPIB (GPIB) Port too, but > as far as I know it is only used to connect a special HP Floppy Disc Drive > with HPIB bus, the HP9122 for example, others exist, even a hard drive. > It is used to load and store measurements and loading disassemblers. > Maybe it can handle a printer too. > I've got such an HP9122 later and tested it with the Analyzer...works. > (BTW: does someone have Z80 an 6809 Disassemblers for the 1631D?) >=20 > Regards, > Holm > --=20 > Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,=20 > Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583 > info(a)tsht.de Tel +49 37292 709778 Mobil: 0172 8790 741 >=20 --===============1608237747220104189==-- From guykd@optusnet.com.au Fri Nov 8 07:14:26 2024 From: guykd@optusnet.com.au To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Fri, 08 Nov 2024 07:14:22 +0000 Message-ID: <173105006234.4006402.4096586822876154064@classiccmp.org> In-Reply-To: <3.0.6.32.20241108125335.017e5890@mail.optusnet.com.au> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8995675446540589092==" --===============8995675446540589092== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For some reason my 2nd reply (via email) didn't appear. This: Update: Found it! It's short, I can scan and upload tonight/tomorrow. Manual PN 10281-90904 Jan 1983 Includes HP-IB commands, schematics, etc. Incidentally, if anyone has the actual 10281A board they'd sell, I'm interest= ed. And/or a whole, reasonable condition 1640B. Mine is in very poor condition. Which is not great, since it's mainly for 'vintage HP collection' reasons. Guy --===============8995675446540589092==-- From holm@freibergnet.de Fri Nov 8 10:46:53 2024 From: Holm Tiffe To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Fri, 08 Nov 2024 11:46:41 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3358721114981208524==" --===============3358721114981208524== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Glen Slick via cctalk wrote: > On Thu, Nov 7, 2024 at 8:41=E2=80=AFPM Holm Tiffe via cctalk > wrote: > > > > I have an HP1631D Logic Analyzer and it has an HPIB (GPIB) Port too, but > > as far as I know it is only used to connect a special HP Floppy Disc Drive > > with HPIB bus, the HP9122 for example, others exist, even a hard drive. > > It is used to load and store measurements and loading disassemblers. > > Maybe it can handle a printer too. >=20 > The HP 163x logic analyzer GPIB interface can be used for remote > control of the analyzer. >=20 > See Appendix C, Using the HP-IB or HP-IL Interface > http://www.bitsavers.org/test_equipment/hp/163x/01630-90907_1630_Operating_= Manual_Oct83.pdf >=20 > See Chapter 10, Using HP-IB or HP-IL Interface: > http://www.bitsavers.org/test_equipment/hp/163x/01631-90904_1631oper_Aug85.= pdf >=20 > > (BTW: does someone have Z80 an 6809 Disassemblers for the 1631D?) >=20 > Yes, those exist. > https://www.eevblog.com/forum/testgear/searching-for-a-hp-1630-hp-1631-inve= rse-assembler-files/ Thanks Glen! Regards, Holm --=20 Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe,=20 Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583 info(a)tsht.de Tel +49 37292 709778 Mobil: 0172 8790 741 --===============3358721114981208524==-- From bfranchuk@jetnet.ab.ca Fri Nov 8 14:48:53 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: mains stroboscope / was Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Fri, 08 Nov 2024 07:48:45 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4656782117610789326==" --===============4656782117610789326== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-11-06 12:28 p.m., Brent Hilpert via cctalk wrote: > The old common standard for a mains stroboscope was a neon bulb (+resistor). > They are still widely available, simple and inexpensive. > No, they are not very bright and need some shading or otherwise reduced amb= ient light, but for a tool of infrequent use... >=20 If it works why change it? Don't modern leds use a still glow after being turned off? Ben. --===============4656782117610789326==-- From paulkoning@comcast.net Fri Nov 8 14:56:56 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: mains stroboscope / was Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Fri, 08 Nov 2024 09:56:48 -0500 Message-ID: <5589DFF5-E930-4909-88FD-8921C82AD5F3@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3433216177734125741==" --===============3433216177734125741== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 8, 2024, at 9:48 AM, ben via cctalk wrote: >=20 > On 2024-11-06 12:28 p.m., Brent Hilpert via cctalk wrote: >> The old common standard for a mains stroboscope was a neon bulb (+resistor= ). >> They are still widely available, simple and inexpensive. >> No, they are not very bright and need some shading or otherwise reduced am= bient light, but for a tool of infrequent use... > If it works why change it? > Don't modern leds use a still glow after being turned off? > Ben. White ones do because the white comes from phosphors, excited by blue LEDs. = But plain LEDs (no phosphor) such as red or green ones have very short persis= tence and should serve nicely as strobe lights. paul --===============3433216177734125741==-- From guykd@optusnet.com.au Fri Nov 8 15:23:58 2024 From: guykd@optusnet.com.au To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Fri, 08 Nov 2024 15:23:54 +0000 Message-ID: <173107943423.4006402.1171301451717784391@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0263125500847800461==" --===============0263125500847800461== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Here's the manual for the 1640B HP-IB option board: http://everist.org/archives/scans/HP_1640B_OPT_001/ And as a zip file: http://everist.org/archives/scans/HP_1640B_OPT_001/HP_1640B_OPT_001.zip (4= .4MB) --===============0263125500847800461==-- From ryan@hack.net Fri Nov 8 15:30:49 2024 From: Ryan Brooks To: cctalk@classiccmp.org Subject: [cctalk] Re: mains stroboscope / was Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Fri, 08 Nov 2024 09:18:36 -0600 Message-ID: <62284fb1-cb60-4a30-b74e-ecab82027376@hack.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7420711630165546695==" --===============7420711630165546695== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/8/24 8:48 AM, ben via cctalk wrote: > On 2024-11-06 12:28 p.m., Brent Hilpert via cctalk wrote: >> The old common standard for a mains stroboscope was a neon bulb >> (+resistor). >> They are still widely available, simple and inexpensive. >> No, they are not very bright and need some shading or otherwise >> reduced ambient light, but for a tool of infrequent use... >> > If it works why change it? > Don't modern leds use a still glow after being turned off? > Ben. > Only ones that use a phosphor- e.g. white. IR/Red/Green/"normal eye killing blue" all can be modulated. Super bright whites typically not. --===============7420711630165546695==-- From cclist@sytse.net Fri Nov 8 15:50:38 2024 From: Sytse van Slooten To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Fri, 08 Nov 2024 16:50:31 +0100 Message-ID: In-Reply-To: <173107943423.4006402.1171301451717784391@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3461980206558938514==" --===============3461980206558938514== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Great, thank you so much! There's a lot of very useful information there - including some commands that= I can use to test the interface, so I'm very very happy. It also sort-of con= firms that the ID? command isn't there, so more confidence that my unit is wo= rking correctly. No complete list of the commands (maybe that's in the operator manual after a= ll?), although there's enough to have a solid base to start reverse engineeri= ng from - and maybe make the testing a bit more interesting :-) Again, thanks! Sytse > On 8 Nov 2024, at 16:23, TerraHertz via cctalk wr= ote: >=20 > Here's the manual for the 1640B HP-IB option board: > http://everist.org/archives/scans/HP_1640B_OPT_001/ >=20 > And as a zip file: > http://everist.org/archives/scans/HP_1640B_OPT_001/HP_1640B_OPT_001.zip (4= .4MB) --===============3461980206558938514==-- From glen.slick@gmail.com Fri Nov 8 16:04:29 2024 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Fri, 08 Nov 2024 08:04:12 -0800 Message-ID: In-Reply-To: <173107943423.4006402.1171301451717784391@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6161267624817619464==" --===============6161267624817619464== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Nov 8, 2024, 7:31 AM TerraHertz via cctalk wrote: > Here's the manual for the 1640B HP-IB option board: > http://everist.org/archives/scans/HP_1640B_OPT_001/ > > And as a zip file: > http://everist.org/archives/scans/HP_1640B_OPT_001/HP_1640B_OPT_001.zip > (4.4MB) > The parts list shows an HP 1AA6-6004 HPIB PHI chip. If anyone is curious about that chip, Ken Shirriff has a detailed post about it here: https://www.righto.com/2023/12/HP-silicon-on-sapphire-phi-chip.html > --===============6161267624817619464==-- From ard.p850ug1@gmail.com Fri Nov 8 16:53:23 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: mains stroboscope / was Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Fri, 08 Nov 2024 16:53:06 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0251200028588295673==" --===============0251200028588295673== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Nov 8, 2024 at 2:56=E2=80=AFPM ben via cctalk wrote: > > On 2024-11-06 12:28 p.m., Brent Hilpert via cctalk wrote: > > The old common standard for a mains stroboscope was a neon bulb (+resisto= r). > > They are still widely available, simple and inexpensive. > > No, they are not very bright and need some shading or otherwise reduced a= mbient light, but for a tool of infrequent use... > > > If it works why change it? > Don't modern leds use a still glow after being turned off? Quite possibly white ones do. But thenso do fluorescent lamps which were often recomended as a mains strobe light source 40 years ago. But having used white LEDs to make a stroboscope flashing 100 or 120 times a second, I will assure you there's enough change in intensity between 'on' and 'off'' to give a very clear pattern of the strobe markings even with normal room illumination also on. -tony --===============0251200028588295673==-- From hupfadekroua@gmail.com Fri Nov 8 19:56:12 2024 From: hupfadekroua To: cctalk@classiccmp.org Subject: [cctalk] CDC 152 Logic Card Tester Date: Fri, 08 Nov 2024 20:55:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8264301262606627963==" --===============8264301262606627963== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello All, I got a CDC 152 Logic Card Tester. This one does have some kind of a patch panel to configure the cordwood modul= e test procedure. I did not find any reference to this unit as well as documentation while quer= ying the internet. Any hints to docs? Best Andreas --===============8264301262606627963==-- From guykd@optusnet.com.au Sat Nov 9 02:36:40 2024 From: guykd@optusnet.com.au To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Sat, 09 Nov 2024 02:36:35 +0000 Message-ID: <173111979563.4006402.17773071443979618046@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7109705806412800076==" --===============7109705806412800076== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In actually reading that manual as I scanned it, I first noticed the mention = of the operator's manual. Should have realized before that there would be one= . Searched this morning.. and found this on ebay: 10281-90905 Operator's Guide Model 1640B/Opt 001 Programmable Serial Da This listing was ended by the seller on Fri, Nov 8 at 6:49 AM because the= item is no longer available. Ha ha ha rats. Maybe this thread prompted someone else to find and buy it. Oh well that's life. Now for a presumably very long ebay search string wait. --===============7109705806412800076==-- From guykd@optusnet.com.au Sat Nov 9 02:42:01 2024 From: guykd@optusnet.com.au To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Sat, 09 Nov 2024 02:41:56 +0000 Message-ID: <173112011678.4006402.1357453462891018808@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2345911279602554613==" --===============2345911279602554613== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Btw, if you are looking for other relatively cheap early HP-IB peripherals, t= here are these: Early HP-IB peripherals =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D HP 59000 Series HP-IB Accessory Modules https://www.prc68.com/I/HP59000.shtml When HP first came out with HP-IB they also offered a line of HP-IB "Glue" ac= cessory modules to help in constructing automated test systems. All these in= struments predated IEEE-488.1 and do not have any of the IEEE-488.2 capabilit= y. That's to say they all use the "R2D2" type of commands. The example code= is typically based on something like a 9825 calculator. Most have their cove= rs held on with Pozi Drive 2 screws. eg HP Catatalogs 1978 pg 26, 1989 pg 562 HP 59301A ASCII to Parallel Converter HP 59303A Digital-Analog-Converter HP 59304A Numeric Display HP 59306A HP-IB Relay Actuator HP 59307A Dual VHF Switch HP 59308A Timing Generator HP 59309A HP-IB Digital Clock HP 59313A 4 Chan A/D Converter HP 59401A Bus System Analyzer=20 HP 59403A Common Carrier Interface HP 59500A Multiprogrammer HP-IB Interface HP 59501A Isolated DAC/Power Supply Programmer (Isolated DAC) cat 1979 pg 2= 28 =20 Prices vary; some can be very cheap. The 59309A HP-IB Digital Clock is rare = and expensive, and manuals are even rarer. --===============2345911279602554613==-- From guykd@optusnet.com.au Sat Nov 9 06:43:46 2024 From: guykd@optusnet.com.au To: cctalk@classiccmp.org Subject: [cctalk] Re: looking for HP 1640B GPIB info Date: Sat, 09 Nov 2024 06:43:41 +0000 Message-ID: <173113462116.4006402.4531421699769866923@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3450320151649263427==" --===============3450320151649263427== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ha ha guess what! Turns out I HAVE the OPT 001 Operators manual as well. Background: I bought a very beat-up 1640B (no HP-IB option) early last year. = Started to work on it while also hunting the manuals. Got stuck needing some = parts I didn't have. Put the unit aside, disassembled in a box, till those co= uld be found. Then had major life distractions, including a trip to the USA l= ate last year, and some illness this year. This thread reminded me, I should = resume that restoration. Found the manuals, which I store in big ziplock bags= . One has the 'user manuals' which for the 1640B are small-format black-cove= red booklets. Several copies, since they tend to get included with service ma= nauls and such. I just now thought to check in that bag. And I do have the OPT 001 Operator's= guide after all. Will try to scan it asap. A bit more difficult, as it's staple-bound, and use= s color screening. --===============3450320151649263427==-- From dkelvey@hotmail.com Sun Nov 10 04:50:52 2024 From: dwight To: cctalk@classiccmp.org Subject: [cctalk] Re: mains stroboscope / was Re: Running DOS executables on other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or possibly MZ-80B) Date: Sun, 10 Nov 2024 04:50:45 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8261682443027863808==" --===============8261682443027863808== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Tony, So no special curcuit needed, just drop the voltage with capacitor or resisto= rs and a bridge. Dwight ________________________________ From: Tony Duell via cctalk Sent: Friday, November 8, 2024 8:53 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: Tony Duell Subject: [cctalk] Re: mains stroboscope / was Re: Running DOS executables on = other versions of DOSRe: Looking for Sharp PC-5000 disk drive (CE-510F or pos= sibly MZ-80B) On Fri, Nov 8, 2024 at 2:56=E2=80=AFPM ben via cctalk wrote: > > On 2024-11-06 12:28 p.m., Brent Hilpert via cctalk wrote: > > The old common standard for a mains stroboscope was a neon bulb (+resisto= r). > > They are still widely available, simple and inexpensive. > > No, they are not very bright and need some shading or otherwise reduced a= mbient light, but for a tool of infrequent use... > > > If it works why change it? > Don't modern leds use a still glow after being turned off? Quite possibly white ones do. But thenso do fluorescent lamps which were often recomended as a mains strobe light source 40 years ago. But having used white LEDs to make a stroboscope flashing 100 or 120 times a second, I will assure you there's enough change in intensity between 'on' and 'off'' to give a very clear pattern of the strobe markings even with normal room illumination also on. -tony --===============8261682443027863808==-- From mjd.bishop@emeritus-solutions.com Mon Nov 11 19:44:43 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Fanuc A860-0056-T020 : 24 V supplies Date: Mon, 11 Nov 2024 19:36:17 +0000 Message-ID: <854ddda03339439eabe1a01154d68400@emeritus-solutions.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1227122806851982685==" --===============1227122806851982685== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Bill A few years ago I took your advice on interfacing a Fanuc tape reader without= reels, it has happily read tapes to its host since then. The interface card was the common A20B-007-0750/07B, with 24V, 5V & Gnd on CN= T3, and IO signals on CNT1. Notably the 24V currents can be high, eg 1A2 when in auto. I now have a Fanuc A860-0056-T020 tape reader with reels on the bench and kno= w that several years ago you used the same model. Two specific questions: - does the CNT1 connector harbour any surprises ? I presume at worst i= t is a superset of the A20B-007-0750/07B CNT1 interface - how did you feed 24V into the beastie o via CNT1 p23 and p24 ? ie on two ribbon cable cores o I note that TP2 provides 5V/Gnd terminals, but 24V has no terminals ? The Fanuc 6T "manual", helpfully available on your web site, indicates (Fig 3= .6a) that the tape readers (with/out reels) are fed 24V and 5V over the ribbo= n cable. And, that the with reels motors run at 100V. I would be very grateful for an indication of how you implemented the power h= ook up and intimation of the currents / power levels to be expected. Hopefully, knowledge will keep the magic smoke inside the system. Best Regards Martin --===============1227122806851982685==-- From cclist@sydex.com Mon Nov 11 20:14:08 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Date of IBM 1/2" tape from factory number Date: Mon, 11 Nov 2024 20:13:55 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3286039254081280592==" --===============3286039254081280592== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear list denizens, I've got a mental itch that needs to be scratched. Before me sits a yellow 3-hole reel of IBM 556 bpi 1/2" tape. Fortunately, the leader is intact and carries the number H241032488. Does this perchance give any clue as to when the tape was manufactured? I know that IBM still carried 556-tested tape in their catalog as late as 1966. Any clues? Thanks, --Chuck --===============3286039254081280592==-- From jwsmail@jwsss.com Tue Nov 12 03:57:51 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Date of IBM 1/2" tape from factory number Date: Mon, 11 Nov 2024 21:57:44 -0600 Message-ID: <263d2249-b3be-493d-92cc-574965d1138b@jwsss.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3290365264130675514==" --===============3290365264130675514== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/11/24 14:13, Chuck Guzis via cctalk wrote: > Dear list denizens, > > I've got a mental itch that needs to be scratched. Before me sits a > yellow 3-hole reel of IBM 556 bpi 1/2" tape. Fortunately, the leader is > intact and carries the number H241032488. Does this perchance give any > clue as to when the tape was manufactured? I know that IBM still > carried 556-tested tape in their catalog as late as 1966. > > Any clues? > > Thanks, > --Chuck I know that the EE professor I worked for had 556bpi tapes from an earlier IBM mainframe, pre-68, but no help as to your tape date. It sucked on our 7 track drive had lots of errors.  One of them got me yelled at as they had to clean the drive after using my tape. We had no means to read the tapes though, so I reused them as the system was long gone. thanks jim --===============3290365264130675514==-- From c.murray.mccullough@gmail.com Fri Nov 15 14:30:21 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] Passing of T. Kurtz Date: Fri, 15 Nov 2024 09:29:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3699583846017403136==" --===============3699583846017403136== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Today another giant in the ‘microcomputer’ industry has passed: Thomas Eugene Kurtz a computer scientist, co-creator/inventor with John Kemeny of the BASIC language that I grew up with. Somewhat dates me! Happy computing, Murray 🙂 --===============3699583846017403136==-- From cliendo@gmail.com Fri Nov 15 16:25:50 2024 From: Christian Liendo To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Fri, 15 Nov 2024 11:25:36 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3008066828755328248==" --===============3008066828755328248== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I just saw. https://www.bloomberg.com/news/articles/2024-11-14/thomas-kurtz-co-creator-of= -computer-language-basic-dies-at-96?fbclid=3DIwZXh0bgNhZW0CMTEAAR3KoXLcQfnlYw= Wx9mVvphwgApNi1lj1xGYUCYpCYWWDnQ-bTjmCw50-oWk_aem_fhgnmJCkoiuiIjct1aQPrw On Fri, Nov 15, 2024, 9:36=E2=80=AFAM Murray McCullough via cctalk < cctalk(a)classiccmp.org> wrote: > Today another giant in the =E2=80=98microcomputer=E2=80=99 industry has pas= sed: Thomas > Eugene Kurtz a computer scientist, co-creator/inventor with John Kemeny of > the BASIC language that I grew up with. Somewhat dates me! > > > Happy computing, > > Murray =F0=9F=99=82 > --===============3008066828755328248==-- From bill.gunshannon@hotmail.com Sat Nov 16 01:29:30 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Fri, 15 Nov 2024 20:29:18 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7179440363254134657==" --===============7179440363254134657== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/15/2024 9:29 AM, Murray McCullough via cctalk wrote: > Today another giant in the ‘microcomputer’ industry has passed: Thomas > Eugene Kurtz a computer scientist, co-creator/inventor with John Kemeny of > the BASIC language that I grew up with. Somewhat dates me! > I still have my copy of The Book. bill --===============7179440363254134657==-- From bitwiz@12bitsbest.com Sat Nov 16 01:49:11 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Fri, 15 Nov 2024 19:49:02 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CLV8P221MB146916E8A17FF441C9350744ED252=40LV8P221MB?= =?utf-8?q?1469=2ENAMP221=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4217924982400405123==" --===============4217924982400405123== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Which "The Book" are you talking about. For me it would be Dartmouth Basic 6th Edition that I got in 1972 at Keiwit Computation Center at Dartmouth College in Hanover New Hampshire. Unfortunately my copy of 6th edition is long bone but I still have my copy of TM115 Basic 7 User's Guide Dartmouth College Computing dated 1981. I initially learned BASIC from the book Basic Basic by James S. Coan while programming on a 4K PDP-8/L with an ASR-33 for the console and paper tape "mass" storage in 1972. On 11/15/2024 7:29 PM, Bill Gunshannon via cctalk wrote: > > > On 11/15/2024 9:29 AM, Murray McCullough via cctalk wrote: >> Today another giant in the ‘microcomputer’ industry has passed: Thomas >> Eugene Kurtz  a computer scientist, co-creator/inventor with John >> Kemeny of >> the BASIC language that I grew up with.  Somewhat dates me! >> > > I still have my copy of The Book. > > bill > --===============4217924982400405123==-- From bitwiz@12bitsbest.com Sat Nov 16 02:41:13 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Fri, 15 Nov 2024 19:57:31 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CLV8P221MB146916E8A17FF441C9350744ED252=40LV8P221MB?= =?utf-8?q?1469=2ENAMP221=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7308647192227742648==" --===============7308647192227742648== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Here is T. Kurtz describing the original BASIC syntax: https://www.dartmouth.edu/basicfifty/commands.html On 11/15/2024 7:29 PM, Bill Gunshannon via cctalk wrote: > > > On 11/15/2024 9:29 AM, Murray McCullough via cctalk wrote: >> Today another giant in the ‘microcomputer’ industry has passed: Thomas >> Eugene Kurtz  a computer scientist, co-creator/inventor with John >> Kemeny of >> the BASIC language that I grew up with.  Somewhat dates me! >> > > I still have my copy of The Book. > > bill > --===============7308647192227742648==-- From cclist@sydex.com Sat Nov 16 02:56:18 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Sat, 16 Nov 2024 02:56:09 +0000 Message-ID: <7570448e-3a84-4a94-8a64-45612a1d7dfc@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3301421654908005843==" --===============3301421654908005843== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I wonder how many remember Cliff Shaw and his work at Rand on JOSS. --Chuck --===============3301421654908005843==-- From c.murray.mccullough@gmail.com Sat Nov 16 17:38:06 2024 From: Murray McCullough To: cctalk@classiccmp.org Subject: [cctalk] The 8086 Date: Sat, 16 Nov 2024 12:37:48 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1185933477228671046==" --===============1185933477228671046== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To my knowledge Intel announced the C8086 processor in Nov. 1978. This processor set the stage for the current technological age. It continues to adapt and its future seems bright! Happy computing, Murray 🙂 --===============1185933477228671046==-- From jonesthechip@logicmagic.co.uk Sat Nov 16 18:16:50 2024 From: Sid Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 18:09:53 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1885266654459917511==" --===============1885266654459917511== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Purely as a matter of interest, my first hands-on code-cutting experience with a microprocessor, an 8008, was at a Swansea University seminar in November 1974... Where does the off half-century go? Regards Sid Jones -----Original Message----- From: Murray McCullough via cctalk Sent: Saturday, November 16, 2024 5:37 PM To: cctalk Cc: Murray McCullough Subject: [cctalk] The 8086 To my knowledge Intel announced the C8086 processor in Nov. 1978. This processor set the stage for the current technological age. It continues to adapt and its future seems bright! Happy computing, Murray 🙂 --===============1885266654459917511==-- From elson@pico-systems.com Sat Nov 16 20:20:25 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 14:20:17 -0600 Message-ID: <4aabdc99-e350-a0e1-0cdc-62512954f0c8@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9152925563492365535==" --===============9152925563492365535== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/16/24 12:09, Sid Jones via cctalk wrote: > Purely as a matter of interest, my first hands-on > code-cutting experience with a microprocessor, an 8008, > was at a Swansea University seminar in November 1974... > > Where does the off half-century go? Yup, on my first real job, I did the controller for an air pollution instrument on an 8008 in 1975 bleeding into 1976.  It was a fairly tough slog, I had to write my own integer multiply and divide routines, 7-segment LED driver code, etc. Jon --===============9152925563492365535==-- From bitwiz@12bitsbest.com Sat Nov 16 22:23:52 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 15:43:56 -0600 Message-ID: <924341c2-a4c8-4076-b035-a8f9ad612619@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7754533329262026055==" --===============7754533329262026055== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Think of how much better the state of the microprocessor would be IBM had chosen the 68000 Linear Architecture rather than the 8086 Segment:Offset with separate I/O instructions and only 1 interrupt architecture. I don't mean to start a huge architecture argument so please don't flame me. On 11/16/2024 11:37 AM, Murray McCullough via cctalk wrote: > To my knowledge Intel announced the C8086 processor in Nov. 1978. This > processor set the stage for the current technological age. It continues to > adapt and its future seems bright! > Happy computing, > Murray 🙂 --===============7754533329262026055==-- From elson@pico-systems.com Sat Nov 16 23:14:33 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 17:14:24 -0600 Message-ID: <9d4adc64-1e9c-3466-a933-80ad18c32b4c@pico-systems.com> In-Reply-To: <924341c2-a4c8-4076-b035-a8f9ad612619@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8530352468230944658==" --===============8530352468230944658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/16/24 15:43, Mike Katz via cctalk wrote: > Think of how much better the state of the microprocessor > would be IBM had chosen the 68000 Linear Architecture > rather than the 8086 Segment:Offset with separate I/O > instructions and only 1 interrupt architecture. > > I don't mean to start a huge architecture argument so > please don't flame me. Well, it is all historical.  The 8086 was an extension of a familiar instruction set. They SHOULD have started with a clean sheet, of course.  Now, the X86 is a complete pile of barnacles. Jon --===============8530352468230944658==-- From tony@tonyjones.com Sat Nov 16 23:27:16 2024 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 15:26:57 -0800 Message-ID: In-Reply-To: <9d4adc64-1e9c-3466-a933-80ad18c32b4c@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8736572189190711703==" --===============8736572189190711703== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 16, 2024, 3:14 PM Jon Elson via cctalk wrote: > They SHOULD have started with a clean sheet, of course. I guess the iAPX 432 wasn't sufficiently "clean sheet" :-) --===============8736572189190711703==-- From tony@tonyjones.com Sat Nov 16 23:56:47 2024 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 15:56:31 -0800 Message-ID: In-Reply-To: <147c9d6f-5f59-411d-98e7-078fbe707f08@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1849401485315329563==" --===============1849401485315329563== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Nov 16, 2024, 3:48 PM Mike Katz wrote: > The IAPX432 came out the same year that the IBM PC came out which was 3 > years after the 8086 I'm fairly sure design work on the 432 began first. --===============1849401485315329563==-- From cisin@xenosoft.com Sun Nov 17 00:24:10 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 16:24:04 -0800 Message-ID: In-Reply-To: <924341c2-a4c8-4076-b035-a8f9ad612619@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8055408032559736032==" --===============8055408032559736032== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 16 Nov 2024, Mike Katz via cctalk wrote: > Think of how much better the state of the microprocessor would be IBM had=20 > chosen the 68000 Linear Architecture rather than the 8086 Segment:Offset wi= th=20 > separate I/O instructions and only 1 interrupt architecture. > > I don't mean to start a huge architecture argument so please don't flame me. Well, a blank slate resultsin a better final product, although it takes=20 longer to develop, and all support needs to be re-implemented. By adding a kludge to an existing product, the final result isn't as good,=20 but it is available much more quickly, and hardware and software support=20 requires "minor" updates. For example, when the PC came out, Micropro was=20 able to patch Wordstar VERY quickly; it took them longer (as a=20 word-processor company) to edit the manuals. The Mac was released with MacWrite and MacPaint; how long was it before a=20 spreadsheet program and other word processors were available? So, Intel went with the "quick fix" rather than the long-term good. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============8055408032559736032==-- From bitwiz@12bitsbest.com Sun Nov 17 00:38:54 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 17:48:25 -0600 Message-ID: <147c9d6f-5f59-411d-98e7-078fbe707f08@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5370886262800660819==" --===============5370886262800660819== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The IAPX432 came out the same year that the IBM PC came out which was 3 years after the 8086 and 2 years after the 68000. It was slow and clunky compared to the 68000 and the 8086 was firmly entrenched in the IBM-PC. The 8086 used an extension of the very familiar 8080 instruction set and the 68000 was modeled after the PDP-11 with it's orthogonal instruction set. Though they both had their flaws (the 8086 more so than the 68000) the IAPX432, by comparison, was too little, too complicated & too late. On 11/16/2024 5:26 PM, Tony Jones via cctalk wrote: > On Sat, Nov 16, 2024, 3:14 PM Jon Elson via cctalk > wrote: > >> They SHOULD have started with a clean sheet, of course. > > I guess the iAPX 432 wasn't sufficiently "clean sheet" :-) --===============5370886262800660819==-- From bitwiz@12bitsbest.com Sun Nov 17 01:09:22 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 19:09:12 -0600 Message-ID: <1dd69664-7083-4956-8fec-960f66cc5edd@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4782130241089648537==" --===============4782130241089648537== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit /So, Intel went with the "quick fix" rather than the long-term good.  <-- Grumpy Old Fred /And the world has been putting up with that decision with hardware and software that have gotten klugier and klugier as time goes on. The 6809 was amazing with what could be done with a random logic 8-bit microprocessor.  Instead of resting on their laurels Motorola started with a clean slate and the PDP-11 architecture as their muse and created a microprocessor that was so far beyond anything else at the time.  Not quite as orthogonal as the PDP-11 but elegant in it's simplicity.  It's too bad they went the super complex instruction set route with follow on microprocessors like the 68020, 68030, 68040 and 68060. Just imagine how poorly your cell phone would work and how quickly the battery would run down if our cell phones were based on the Intel 8X86(X) architecture. According to worldmetrics.org there area approximately 2.5 Billion PC's out there.  According to statista.com about 80% of these are Intel based.  That would mean there are approximately 2 billion Intel/AMD based PC's in the world. also According to statista.com there are approximately 18.22 billion cell phones out there.  So by shear numbers the Arm architecture win hands down.  And that doesn't account for all of the embedded systems/Raspberry Pis running ARM CPUs. Intel won the battle but lost the architecture battle. On 11/16/2024 6:24 PM, Fred Cisin via cctalk wrote: > On Sat, 16 Nov 2024, Mike Katz via cctalk wrote: >> Think of how much better the state of the microprocessor would be IBM >> had chosen the 68000 Linear Architecture rather than the 8086 >> Segment:Offset with separate I/O instructions and only 1 interrupt >> architecture. >> >> I don't mean to start a huge architecture argument so please don't >> flame me. > > Well, a blank slate resultsin a better final product, although it > takes longer to develop, and all support needs to be re-implemented. > > By adding a kludge to an existing product, the final result isn't as > good, but it is available much more quickly, and hardware and software > support requires "minor" updates.  For example, when the PC came out, > Micropro was able to patch Wordstar VERY quickly; it took them longer > (as a word-processor company) to edit the manuals. > > > The Mac was released with MacWrite and MacPaint; how long was it > before a spreadsheet program and other word processors were available? > > > So, Intel went with the "quick fix" rather than the long-term good. > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com --===============4782130241089648537==-- From bear@typewritten.org Sun Nov 17 01:10:05 2024 From: "r.stricklin" To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 17:08:46 -0800 Message-ID: <41343EEE-4B5D-4E59-986A-E7ACE03BA1B7@typewritten.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6471749493257273793==" --===============6471749493257273793== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Nov 16, 2024, at 4:24 PM, Fred Cisin via cctalk wrote: >=20 > The Mac was released with MacWrite and MacPaint; how long was it before a s= preadsheet program and other word processors were available? >=20 Not to take away from the main thrust of your argument, which is sound, but= =E2=80=A6 Microsoft had Multiplan for the Mac available pretty quickly. Withi= n a couple months I think.=20 ok bear. --===============6471749493257273793==-- From bfranchuk@jetnet.ab.ca Sun Nov 17 01:14:42 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 18:14:32 -0700 Message-ID: <4b2ac52e-d9a8-4538-bdf8-b1c1122dc384@jetnet.ab.ca> In-Reply-To: <924341c2-a4c8-4076-b035-a8f9ad612619@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5201876016955080252==" --===============5201876016955080252== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-11-16 2:43 p.m., Mike Katz via cctalk wrote: > Think of how much better the state of the microprocessor would be IBM > had chosen the 68000 Linear Architecture rather than the 8086 > Segment:Offset with separate I/O instructions and only 1 interrupt > architecture. > > I don't mean to start a huge architecture argument so please don't flame > me. > Now what was that joke again about hell being run by PC's and Heaven by Macs So if you get flames don't blame the PC. Was just me or did everyone think 32K words was all a single process needed in the 70's? > On 11/16/2024 11:37 AM, Murray McCullough via cctalk wrote: >> To my knowledge Intel announced the C8086 processor in Nov. 1978. This >> processor set the stage for the current technological age. It >> continues to >> adapt and its future seems bright! >> Happy computing, >> Murray 🙂 > --===============5201876016955080252==-- From bill.gunshannon@hotmail.com Sun Nov 17 01:25:29 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Sat, 16 Nov 2024 20:25:21 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3760600599301969974==" --===============3760600599301969974== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/15/2024 8:49 PM, Mike Katz wrote: > Which "The Book" are you talking about. > BASIC PROGRAMMING Second Edition By John G. Kemeny and Thomas E. Kurtz Is there any other authority on BASIC? bill --===============3760600599301969974==-- From cclist@sydex.com Sun Nov 17 01:38:01 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sun, 17 Nov 2024 01:37:53 +0000 Message-ID: <451320c3-bd1a-4807-9083-5268c22c4a18@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5774741000660788173==" --===============5774741000660788173== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 11/16/24 16:24, Fred Cisin via cctalk wrote: > So, Intel went with the "quick fix" rather than the long-term good. Okay, I vass dere and know what we were being told by Intel marketing in the late 70s. The 8086 was not intended to be the eventual migration target for larger-scale applications. Similar claims can be made for the 80186--it was mostly intended for embedded applications. The thing that was supposed to be the architecture to hang one's hat on was the iAPX432. Intel's "Clean Slate" which was a horrible flop. Another "clean slate" was the i860; my i860 reference manual has a statement by BillG saying that MS intended to develop for that platform. It seems that every time that Intel tries to do development from a tabula rasa, they get burned. Witness Itanium/IA64. The thing that saved Intel's bacon on several occasions was their liberal licensing. Would we even have had the IBM 5150 if there weren't a pile of second sources for the 8088? My early 5150 had an AMD CPU in it. --Chuck --===============5774741000660788173==-- From wayne.sudol@hotmail.com Sun Nov 17 01:49:42 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sun, 17 Nov 2024 01:49:36 +0000 Message-ID: In-Reply-To: <451320c3-bd1a-4807-9083-5268c22c4a18@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5788856518348046992==" --===============5788856518348046992== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Why did those processors not catch on? It seems to me that hardware people had a =E2=80=9Cif we build it, they will = come=E2=80=9D mentality and hoped other companies would adopt it and actually= write software to make it useful.=20 Sent from my iPhone > On Nov 16, 2024, at 17:38, Chuck Guzis via cctalk = wrote: >=20 > =EF=BB=BFOn 11/16/24 16:24, Fred Cisin via cctalk wrote: >=20 >> So, Intel went with the "quick fix" rather than the long-term good. >=20 > Okay, I vass dere and know what we were being told by Intel marketing in > the late 70s. The 8086 was not intended to be the eventual migration > target for larger-scale applications. Similar claims can be made for > the 80186--it was mostly intended for embedded applications. >=20 > The thing that was supposed to be the architecture to hang one's hat on > was the iAPX432. Intel's "Clean Slate" which was a horrible flop. > Another "clean slate" was the i860; my i860 reference manual has a > statement by BillG saying that MS intended to develop for that platform. > It seems that every time that Intel tries to do development from a > tabula rasa, they get burned. Witness Itanium/IA64. >=20 > The thing that saved Intel's bacon on several occasions was their > liberal licensing. Would we even have had the IBM 5150 if there weren't > a pile of second sources for the 8088? My early 5150 had an AMD CPU in it. >=20 > --Chuck >=20 >=20 --===============5788856518348046992==-- From bitwiz@12bitsbest.com Sun Nov 17 02:01:16 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 20:01:06 -0600 Message-ID: <702fb0f5-44df-4376-810e-79859495b309@12bitsbest.com> In-Reply-To: <4b2ac52e-d9a8-4538-bdf8-b1c1122dc384@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8933678042178929468==" --===============8933678042178929468== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > Was just me or did everyone think 32K words was all a single process > needed in the 70's? Start with 4K and use paging to give you 32K 12 bit words.  Welcome to the PDP-8 world!!! Wow you could be running in one 4K field and have your data in another 4K field.  Amazing!!!!! And all core memory too. On 11/16/2024 7:14 PM, ben via cctalk wrote: > On 2024-11-16 2:43 p.m., Mike Katz via cctalk wrote: >> Think of how much better the state of the microprocessor would be IBM >> had chosen the 68000 Linear Architecture rather than the 8086 >> Segment:Offset with separate I/O instructions and only 1 interrupt >> architecture. >> >> I don't mean to start a huge architecture argument so please don't >> flame me. >> > > > Now what was that joke again about hell being run by PC's and Heaven > by Macs > So if you get flames don't blame the PC. > > Was just me or did everyone think 32K words was all a single process > needed in the 70's? > >> On 11/16/2024 11:37 AM, Murray McCullough via cctalk wrote: >>> To my knowledge Intel announced the C8086 processor in Nov. 1978. This >>> processor set the stage for the current technological age. It >>> continues to >>> adapt and its future seems bright! >>> Happy computing, >>> Murray 🙂 >> > > --===============8933678042178929468==-- From bitwiz@12bitsbest.com Sun Nov 17 02:03:11 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Sat, 16 Nov 2024 20:03:02 -0600 Message-ID: <3cfe183e-a1c2-462b-ba05-810411d5f7b1@12bitsbest.com> In-Reply-To: =?utf-8?q?=3CLV8P221MB14693E04B531C43E73FD278AED262=40LV8P221MB?= =?utf-8?q?1469=2ENAMP221=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6763079662952352155==" --===============6763079662952352155== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I got my book at the Kiewit Computation Center at Dartmouth in 1972 and by then it was 6th Edition.  Currently I have the 7th Edition book. My first book on basic was Basic Basic by James S. Coan also in 1972. On 11/16/2024 7:25 PM, Bill Gunshannon via cctalk wrote: > > > On 11/15/2024 8:49 PM, Mike Katz wrote: >> Which "The Book" are you talking about. >> > > BASIC PROGRAMMING Second Edition By John G. Kemeny and Thomas E. Kurtz > > Is there any other authority on BASIC? > > bill > --===============6763079662952352155==-- From bitwiz@12bitsbest.com Sun Nov 17 02:04:41 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 20:04:32 -0600 Message-ID: In-Reply-To: <451320c3-bd1a-4807-9083-5268c22c4a18@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1870203188656443319==" --===============1870203188656443319== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It didn't hurt that when IBM decide to go with the 8088 they bought something like 12.5% of Intel's stock. On 11/16/2024 7:37 PM, Chuck Guzis via cctalk wrote: > On 11/16/24 16:24, Fred Cisin via cctalk wrote: > >> So, Intel went with the "quick fix" rather than the long-term good. > Okay, I vass dere and know what we were being told by Intel marketing in > the late 70s. The 8086 was not intended to be the eventual migration > target for larger-scale applications. Similar claims can be made for > the 80186--it was mostly intended for embedded applications. > > The thing that was supposed to be the architecture to hang one's hat on > was the iAPX432. Intel's "Clean Slate" which was a horrible flop. > Another "clean slate" was the i860; my i860 reference manual has a > statement by BillG saying that MS intended to develop for that platform. > It seems that every time that Intel tries to do development from a > tabula rasa, they get burned. Witness Itanium/IA64. > > The thing that saved Intel's bacon on several occasions was their > liberal licensing. Would we even have had the IBM 5150 if there weren't > a pile of second sources for the 8088? My early 5150 had an AMD CPU in it. > > --Chuck > > --===============1870203188656443319==-- From artgodwin@gmail.com Sun Nov 17 02:10:44 2024 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sun, 17 Nov 2024 02:10:30 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181E25AC8C42C063F100371E4262=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3071699392288881733==" --===============3071699392288881733== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Because the majority of buyers were businesses. - they nearly always choose the low risk, low reward option. Only people with vision look forward. On Sun, 17 Nov 2024, 01:56 Wayne S via cctalk, wrote: > Why did those processors not catch on? > It seems to me that hardware people had a =E2=80=9Cif we build it, they wil= l come=E2=80=9D > mentality and hoped other companies would adopt it and actually write > software to make it useful. > > Sent from my iPhone > > > On Nov 16, 2024, at 17:38, Chuck Guzis via cctalk > wrote: > > > > =EF=BB=BFOn 11/16/24 16:24, Fred Cisin via cctalk wrote: > > > >> So, Intel went with the "quick fix" rather than the long-term good. > > > > Okay, I vass dere and know what we were being told by Intel marketing in > > the late 70s. The 8086 was not intended to be the eventual migration > > target for larger-scale applications. Similar claims can be made for > > the 80186--it was mostly intended for embedded applications. > > > > The thing that was supposed to be the architecture to hang one's hat on > > was the iAPX432. Intel's "Clean Slate" which was a horrible flop. > > Another "clean slate" was the i860; my i860 reference manual has a > > statement by BillG saying that MS intended to develop for that platform. > > It seems that every time that Intel tries to do development from a > > tabula rasa, they get burned. Witness Itanium/IA64. > > > > The thing that saved Intel's bacon on several occasions was their > > liberal licensing. Would we even have had the IBM 5150 if there weren't > > a pile of second sources for the 8088? My early 5150 had an AMD CPU in > it. > > > > --Chuck > > > > > --===============3071699392288881733==-- From bitwiz@12bitsbest.com Sun Nov 17 02:15:20 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: The 8086 Date: Sat, 16 Nov 2024 20:15:12 -0600 Message-ID: <4e3a423f-15a1-47ac-9605-f5c337bc7335@12bitsbest.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181E25AC8C42C063F100371E4262=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6169052483803458441==" --===============6169052483803458441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In order to have the "world beat a path" to a new microprocessor is has=20 the be sufficiently better than what is there to justify the time and=20 expense.=C2=A0 Intel doesn't know how to architect a decent CPU.=C2=A0 They j= ust=20 keep kludging their previous successes. From what I heard from some inside sources around the time that the PC=20 came out, IBM didn't pick the 8088 for it's speed or ease of use.=C2=A0 Quite= =20 the contrary, they chose it because it was slow and they could buy part=20 of Intel.=C2=A0 They didn't want their $10,000 computer competing with their = bread and butter main frames. A 68000 could address more memory than a basic IBM 360 (which could only=20 address up to 64K) and was faster as well.=C2=A0 As a matter of fact when IBM= =20 created the System 360 PC card that was an IBM 360 on a card that=20 plugged into an IBM Xt is used a re-microcoded 68000 to emulate the=20 System 360. On 11/16/2024 7:49 PM, Wayne S via cctalk wrote: > Why did those processors not catch on? > It seems to me that hardware people had a =E2=80=9Cif we build it, they wil= l come=E2=80=9D mentality and hoped other companies would adopt it and actual= ly write software to make it useful. > > Sent from my iPhone > >> On Nov 16, 2024, at 17:38, Chuck Guzis via cctalk wrote: >> >> =EF=BB=BFOn 11/16/24 16:24, Fred Cisin via cctalk wrote: >> >>> So, Intel went with the "quick fix" rather than the long-term good. >> Okay, I vass dere and know what we were being told by Intel marketing in >> the late 70s. The 8086 was not intended to be the eventual migration >> target for larger-scale applications. Similar claims can be made for >> the 80186--it was mostly intended for embedded applications. >> >> The thing that was supposed to be the architecture to hang one's hat on >> was the iAPX432. Intel's "Clean Slate" which was a horrible flop. >> Another "clean slate" was the i860; my i860 reference manual has a >> statement by BillG saying that MS intended to develop for that platform. >> It seems that every time that Intel tries to do development from a >> tabula rasa, they get burned. Witness Itanium/IA64. >> >> The thing that saved Intel's bacon on several occasions was their >> liberal licensing. Would we even have had the IBM 5150 if there weren't >> a pile of second sources for the 8088? My early 5150 had an AMD CPU in it. >> >> --Chuck >> >> --===============6169052483803458441==-- From billdegnan@gmail.com Sun Nov 17 02:32:53 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Passing of T. Kurtz Date: Sat, 16 Nov 2024 21:32:37 -0500 Message-ID: In-Reply-To: <3cfe183e-a1c2-462b-ba05-810411d5f7b1@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2998454330101459290==" --===============2998454330101459290== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > > > > > > > On 11/15/2024 8:49 PM, Mike Katz wrote: > >> Which "The Book" are you talking about. > >> > > > > BASIC PROGRAMMING Second Edition By John G. Kemeny and Thomas E. Kurtz > > > > Is there any other authority on BASIC? > > > > bill > > > > Kurtz came to VCF East, did a talk, and gave out signed copies of the first edition of BASIC, the "preliminary manual". I am guessing that was 2014. For the 1965 spring semester Dartmouth College Computation Center put out a BASIC manual, the first formal one that I know of. In June 65 GE produced a version of the same manual with additional details specific to operating timeshare BASIC using a Teletype and connecting remotely to a GE 225/235 computer. I don't think they called the '64/65 version "the first edition" in their manuals specifically, but I cannot confirm this without looking it up, maybe they did. Bill --===============2998454330101459290==--