From drb@msu.edu Tue Dec 3 20:07:44 2024 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] List outage Date: Tue, 03 Dec 2024 15:07:36 -0500 Message-ID: <20241203200736.6370748C9D1@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0148549915225334112==" --===============0148549915225334112== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Folks, Apologies for the list outage. Jason thinks this has been going on since roughly 11/16. I guess the sense of relief at no inbound list emails kept me from realizing there were no list emails. :) I think it's better. Will keep an eye on it. De --===============0148549915225334112==-- From wrcooke@wrcooke.net Tue Dec 3 20:25:07 2024 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] A bit of humor to test the list Date: Tue, 03 Dec 2024 15:19:56 -0500 Message-ID: <2044054011.295344.1733257196597@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3610791609356909012==" --===============3610791609356909012== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I found the picture on the front page of this web site humorous. It's a plac= e that sells old Jeep parts. Note the computer surfing the web. https://www.kaiserwillys.com/ Will --===============3610791609356909012==-- From cisin@xenosoft.com Tue Dec 3 20:35:34 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] A bit of humor to test the list Date: Tue, 03 Dec 2024 12:35:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3164728229808756214==" --===============3164728229808756214== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit They seem to have upgraded the video output! > I found the picture on the front page of this web site humorous. It's a > place that sells old Jeep parts. Note the computer surfing the web. > https://www.kaiserwillys.com/ --===============3164728229808756214==-- From dave.g4ugm@gmail.com Tue Dec 3 20:57:43 2024 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Cleaning Card Punch Date: Tue, 03 Dec 2024 20:57:26 +0000 Message-ID: <31f61d17-1465-44b7-9bb0-b985358767f9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5956472402184740231==" --===============5956472402184740231== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Folks, I have been trying to restore a manual card punch. The type with 12=20 "Buttons" or "Plungers" that operate a lever which pushes a punch "pin"=20 through a die to create a hole in a card. Its almost identical to this one:- https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Machine= /=20 so despite lots of cleaning some of the pins stick down. Does any one=20 have any suggestions how to clean the small square slots? Any idea how the holes were made? Dave G4UGM --===============5956472402184740231==-- From paulkoning@comcast.net Tue Dec 3 21:39:09 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleaning Card Punch Date: Tue, 03 Dec 2024 16:38:36 -0500 Message-ID: In-Reply-To: <31f61d17-1465-44b7-9bb0-b985358767f9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6164987739052671993==" --===============6164987739052671993== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Dec 2, 2024, at 4:00 AM, David Wade via cctalk = wrote: >=20 > Folks, > I have been trying to restore a manual card punch. The type with 12 "Button= s" or "Plungers" that operate a lever which pushes a punch "pin" through a di= e to create a hole in a card. > Its almost identical to this one:- >=20 > https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Machi= ne/=20 >=20 > so despite lots of cleaning some of the pins stick down. Does any one have = any suggestions how to clean the small square slots? > Any idea how the holes were made? >=20 > Dave > G4UGM Do you mean the rectangular holes that guide the punches, or that receive the= punch below the card (the die)? Or are there square rods that carry the but= tons, in a square hole? The obvious solution would be a solvent. Paint thinner might work. If not, = you may want something stronger, but if so you'd need to remove any plastic p= arts (like the keycaps). Laquer thinner is potent, I use it a lot, but only= on insoluble items. Rectangular holes can be cast, or machined with a broach. The same goes for = square holes, but in addition it's possible to drill square holes, using tria= ngular drills. Watt Brothers Tool Works has made these for ages (see https:/= /www.scribd.com/doc/67999953/Watts-Bros-Manual). paul --===============6164987739052671993==-- From barythrin@gmail.com Tue Dec 3 22:06:12 2024 From: John Herron To: cctalk@classiccmp.org Subject: [cctalk] Re: List outage Date: Tue, 03 Dec 2024 16:05:53 -0600 Message-ID: In-Reply-To: <20241203200736.6370748C9D1@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3473863203938576970==" --===============3473863203938576970== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Ironically I feel like there's often a lull in traffic around this holiday so wasn't sure if outage or everyone was enjoying family instead of hobby. Thanks to all of you who keep our group alive and chatting! On Tue, Dec 3, 2024, 2:17 PM Dennis Boone via cctalk wrote: > Folks, > > Apologies for the list outage. Jason thinks this has been going on > since roughly 11/16. I guess the sense of relief at no inbound list > emails kept me from realizing there were no list emails. :) > > I think it's better. Will keep an eye on it. > > De > --===============3473863203938576970==-- From ard.p850ug1@gmail.com Wed Dec 4 16:46:38 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 16:46:21 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5245054938370192092==" --===============5245054938370192092== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, Dec 3, 2024 at 8:42 PM Fred Cisin via cctalk wrote: > > They seem to have upgraded the video output! Is it a CoCo or the Videotex terminal? The latter was never sold in the UK for obvious reasons, but looking at the service manual for it, it does seem to have the same video circuitry as the CoCo. > > > > I found the picture on the front page of this web site humorous. It's a > > place that sells old Jeep parts. Note the computer surfing the web. > > https://www.kaiserwillys.com/ -tony --===============5245054938370192092==-- From g4ajq1@gmail.com Wed Dec 4 16:50:50 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 11:50:44 -0500 Message-ID: <813e10a4-3049-4e00-8edf-01af5c746007@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0684314386682509570==" --===============0684314386682509570== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit What is not well known is that the CoCo was actually designed by Motorola, and appeared in their Microprocessor data book as a double-page schematic to promote the 6809! cheers, Nigel On 2024-12-04 11:46, Tony Duell via cctalk wrote: > On Tue, Dec 3, 2024 at 8:42 PM Fred Cisin via cctalk > wrote: >> They seem to have upgraded the video output! > Is it a CoCo or the Videotex terminal? > > The latter was never sold in the UK for obvious reasons, but looking > at the service manual for it, it does seem to have the same video > circuitry as the CoCo. > >> >>> I found the picture on the front page of this web site humorous. It's a >>> place that sells old Jeep parts. Note the computer surfing the web. >>> https://www.kaiserwillys.com/ > -tony -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============0684314386682509570==-- From ard.p850ug1@gmail.com Wed Dec 4 16:55:37 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 16:55:21 +0000 Message-ID: In-Reply-To: <813e10a4-3049-4e00-8edf-01af5c746007@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3299521744546595303==" --===============3299521744546595303== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 4:50 PM Nigel Johnson Ham via cctalk wrote: > > What is not well known is that the CoCo was actually designed by > Motorola, and appeared in their Microprocessor data book as a > double-page schematic to promote the 6809! Wasn't it actually a suggested schematic for the 6883 synchronous address multiplexer chip? -tony --===============3299521744546595303==-- From bitwiz@12bitsbest.com Wed Dec 4 17:46:30 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 11:46:20 -0600 Message-ID: <9ed2a66f-9a3b-4bf5-8c7a-5d18bf9f640e@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8047963166397695284==" --===============8047963166397695284== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The story I heard is that Motorola went to Tandy asking them to use their 6809 chip. Tandy said, ok, you design a system for us with a cost of $xxx and we will sell it. Motorola then designed the color computer using the 6883 SAM chip which handled almost all of the glue logic for the system.  This includes address decoding, DRAM refresh, system clock, etc. The CoCo was made up of 3 main chips: * 6809E CPU (The E used a 2 phase clock so they could alternate cycle main RAM and video RAM) * 6883 Synchronous Address Mutiplexor (took care of all of the glue logic) * 6845 Graphics Controller Chip Add RAM and a few Misc. chips and discretes and you have a CoCo! Great machine but no one at Tandy realized the power of the 6809.  Maybe the CoCo III came close to exploiting all that the 6809 could do. On 12/4/2024 10:55 AM, Tony Duell via cctalk wrote: > On Wed, Dec 4, 2024 at 4:50 PM Nigel Johnson Ham via cctalk > wrote: >> What is not well known is that the CoCo was actually designed by >> Motorola, and appeared in their Microprocessor data book as a >> double-page schematic to promote the 6809! > Wasn't it actually a suggested schematic for the 6883 synchronous > address multiplexer chip? > > -tony --===============8047963166397695284==-- From ard.p850ug1@gmail.com Wed Dec 4 17:52:08 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 17:51:51 +0000 Message-ID: In-Reply-To: <9ed2a66f-9a3b-4bf5-8c7a-5d18bf9f640e@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2270846733509452805==" --===============2270846733509452805== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 4, 2024 at 5:46=E2=80=AFPM Mike Katz wr= ote: > > The story I heard is that Motorola went to Tandy asking them to use their 6= 809 chip. > > Tandy said, ok, you design a system for us with a cost of $xxx and we will = sell it. > > Motorola then designed the color computer using the 6883 SAM chip which han= dled almost all of the glue logic for the system. This includes address deco= ding, DRAM refresh, system clock, etc. > > The CoCo was made up of 3 main chips: > > 6809E CPU (The E used a 2 phase clock so they could alternate cycle main RA= M and video RAM) > 6883 Synchronous Address Mutiplexor (took care of all of the glue logic) > 6845 Graphics Controller Chip Actually a 6847 which is a rather different device > > Add RAM and a few Misc. chips and discretes and you have a CoCo! True. The schematic in the datasheet I pointed to also shows the ROMs and a pair of 6821 PIAs as in the CoCo. > > Great machine but no one at Tandy realized the power of the 6809. Maybe th= e CoCo III came close to exploiting all that the 6809 could do. Tandy did sell Microware OS-9, BASIC-09. Pascal and C for the CoCo. That was a rather nice mutliuser OS. I remember at the tme I was runing OS-9 (initially leval 1 on a 64K CoCo 2, then level 2 on a 512K CoCo 3) and had to use MS-DOS on a computer at a company I was doing some work for. The latter felt so primitve by comparison. -tony --===============2270846733509452805==-- From ard.p850ug1@gmail.com Wed Dec 4 17:53:41 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 17:53:23 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4156000738686254830==" --===============4156000738686254830== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 4, 2024 at 5:51=E2=80=AFPM Tony Duell w= rote: > The schematic in the datasheet I pointed to also shows the ROMs and a > pair of 6821 PIAs as in the CoCo. Sorry that never went to the list. The datasheet I refer to is here : https://archive.org/details/Motorola_MC6883_Synchronous_Address_Multiplexer_A= dvance_Sheet_19xx_Motorola/page/n23/mode/2up -tony --===============4156000738686254830==-- From bitwiz@12bitsbest.com Wed Dec 4 17:59:05 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 11:58:54 -0600 Message-ID: <8b71cccc-2eb1-4f14-a749-1be08c1a8cc7@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5190960800071902932==" --===============5190960800071902932== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You are correct.=C2=A0 The 6845 was monochrome and the 6847 was the color chi= p. If you count a maximum of 16 colors as a color chip=F0=9F=99=82.=C2=A0 4 Colo= rs with=20 artifacting in the highest resolution mode. On 12/4/2024 11:51 AM, Tony Duell wrote: > On Wed, Dec 4, 2024 at 5:46=E2=80=AFPM Mike Katz = wrote: >> The story I heard is that Motorola went to Tandy asking them to use their = 6809 chip. >> >> Tandy said, ok, you design a system for us with a cost of $xxx and we will= sell it. >> >> Motorola then designed the color computer using the 6883 SAM chip which ha= ndled almost all of the glue logic for the system. This includes address dec= oding, DRAM refresh, system clock, etc. >> >> The CoCo was made up of 3 main chips: >> >> 6809E CPU (The E used a 2 phase clock so they could alternate cycle main R= AM and video RAM) >> 6883 Synchronous Address Mutiplexor (took care of all of the glue logic) >> 6845 Graphics Controller Chip > Actually a 6847 which is a rather different device > >> Add RAM and a few Misc. chips and discretes and you have a CoCo! > True. > > The schematic in the datasheet I pointed to also shows the ROMs and a > pair of 6821 PIAs as in the CoCo. > > > >> Great machine but no one at Tandy realized the power of the 6809. Maybe t= he CoCo III came close to exploiting all that the 6809 could do. > Tandy did sell Microware OS-9, BASIC-09. Pascal and C for the CoCo. > That was a rather nice mutliuser OS. I remember at the tme I was > runing OS-9 (initially leval 1 on a 64K CoCo 2, then level 2 on a 512K > CoCo 3) and had to use MS-DOS on a computer at a company I was doing > some work for. The latter felt so primitve by comparison. > > -tony --===============5190960800071902932==-- From ard.p850ug1@gmail.com Wed Dec 4 18:13:46 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 18:13:29 +0000 Message-ID: In-Reply-To: <8b71cccc-2eb1-4f14-a749-1be08c1a8cc7@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5787144288040036922==" --===============5787144288040036922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 5:58 PM Mike Katz wrote: > > You are correct. The 6845 was monochrome and the 6847 was the color chip. The 6845 was called the 'CRT Controller'. It was basically a set of programmable counters that would address the video RAM, generate sync signals, latch the address if a lightpen detected a 'hit' and so on. It did not do anything with the data from the video RAM, that was handled by other circuitry. It could certainly be used in colour systems, the BBC micro, IBM CGA card and so on. The 6847 was the the video display generator. It could generate the video addresses and timing (e.g. the Acorn Atom) but didn't have to. It did handle the data from the video RAM, it had an internal upper-case only character generator, block graphics, etc. It did generate colour video. -tony --===============5787144288040036922==-- From bitwiz@12bitsbest.com Wed Dec 4 18:25:58 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 12:24:45 -0600 Message-ID: <92a87279-bb97-4bcb-bec5-18997c015392@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6856001245208233912==" --===============6856001245208233912== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Tony, Thank you for the education.  I did some minimal programming of the 6847 on the CoCo and nothing really on the 6845. A majority of the 6809 programming that I did was for Gimix, when I worked there in the early 1980's. And then on embedded 6809 based system, also in the early 1980's.           Mike On 12/4/2024 12:13 PM, Tony Duell wrote: > On Wed, Dec 4, 2024 at 5:58 PM Mike Katz wrote: >> You are correct. The 6845 was monochrome and the 6847 was the color chip. > The 6845 was called the 'CRT Controller'. It was basically a set of > programmable counters that would address the video RAM, generate sync > signals, latch the address if a lightpen detected a 'hit' and so on. > It did not do anything with the data from the video RAM, that was > handled by other circuitry. It could certainly be used in colour > systems, the BBC micro, IBM CGA card and so on. > > The 6847 was the the video display generator. It could generate the > video addresses and timing (e.g. the Acorn Atom) but didn't have to. > It did handle the data from the video RAM, it had an internal > upper-case only character generator, block graphics, etc. It did > generate colour video. > > -tony --===============6856001245208233912==-- From ard.p850ug1@gmail.com Wed Dec 4 18:30:59 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 18:30:41 +0000 Message-ID: In-Reply-To: <92a87279-bb97-4bcb-bec5-18997c015392@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7167700413352050136==" --===============7167700413352050136== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 6:24 PM Mike Katz wrote: > > Tony, > > Thank you for the education. I did some minimal programming of the 6847 > on the CoCo and nothing really on the 6845. > > A majority of the 6809 programming that I did was for Gimix, when I > worked there in the early 1980's. > > And then on embedded 6809 based system, also in the early 1980's. In the second half of the 1980s I did a few embedded 6809 projects, my final year project at university and then some designs a for a company I did a summer job for. I developped all the code on my CoCo system under OS-9 and burnt the binaries into EPROMs using a home-made programmer on the CoCo. I still have all the hardware, still all works. My Motorola databook is still on the shelf, although the pages are falling out due to all the use it has had. Still love the 6809. -tony --===============7167700413352050136==-- From ard.p850ug1@gmail.com Wed Dec 4 18:49:55 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleaning Card Punch Date: Wed, 04 Dec 2024 18:49:37 +0000 Message-ID: In-Reply-To: <31f61d17-1465-44b7-9bb0-b985358767f9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1948878875188576980==" --===============1948878875188576980== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 4, 2024 at 6:41=E2=80=AFPM David Wade via cctalk wrote: > > Folks, > I have been trying to restore a manual card punch. The type with 12 > "Buttons" or "Plungers" that operate a lever which pushes a punch "pin" > through a die to create a hole in a card. > Its almost identical to this one:- > > https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Machi= ne/ I know it. Mine has an ICT (International Computers and Tabulators) badge on the front > > > so despite lots of cleaning some of the pins stick down. Does any one > have any suggestions how to clean the small square slots? From memory there's the stem of the key in circular holes. There's a flat on the stem to engage the punch lever which is pivoted at the left hand side. And the punch pin in the die block. Do you know what is sticking? There's a unit with 12 slots with ball bearings between some of them to the left of the buttons.. It prevents you pressing more than 1 digit key down at once. That cam cause the levers to stick. -tony --===============1948878875188576980==-- From bitwiz@12bitsbest.com Wed Dec 4 18:49:59 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 12:49:47 -0600 Message-ID: <6ab0541b-c47b-4540-ab01-2695ca22bd2d@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8672812556562931759==" --===============8672812556562931759== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Tony, I still say the 6809 was the best 8 bit micro ever. Though I don't have any 6809 systems here I still have my 6809/6809E Microprocessor Programming Manual from 1981. Lately I do more with my PDP-8's then anything recent like the 6809🙂 On 12/4/2024 12:30 PM, Tony Duell wrote: > On Wed, Dec 4, 2024 at 6:24 PM Mike Katz wrote: >> Tony, >> >> Thank you for the education. I did some minimal programming of the 6847 >> on the CoCo and nothing really on the 6845. >> >> A majority of the 6809 programming that I did was for Gimix, when I >> worked there in the early 1980's. >> >> And then on embedded 6809 based system, also in the early 1980's. > In the second half of the 1980s I did a few embedded 6809 projects, my > final year project at university and then some designs a for a company > I did a summer job for. I developped all the code on my CoCo system > under OS-9 and burnt the binaries into EPROMs using a home-made > programmer on the CoCo. > > I still have all the hardware, still all works. My Motorola databook > is still on the shelf, although the pages are falling out due to all > the use it has had. Still love the 6809. > > -tony --===============8672812556562931759==-- From ard.p850ug1@gmail.com Wed Dec 4 18:53:34 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 18:53:19 +0000 Message-ID: In-Reply-To: <6ab0541b-c47b-4540-ab01-2695ca22bd2d@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8324440581997437613==" --===============8324440581997437613== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 6:49 PM Mike Katz wrote: > > Tony, > > I still say the 6809 was the best 8 bit micro ever. No dispute from me on that point :-) > > Though I don't have any 6809 systems here I still have my 6809/6809E > Microprocessor Programming Manual from 1981. I still have my CoCos and a Acorn System with a 6809 CPU board in it. And of course plenty of them in embedded systems -- mosr HP disk or tape units contain one. So does my HP1630 logic analyser. > > Lately I do more with my PDP-8's then anything recent like the 6809🙂 Another elegant processor design. -tony --===============8324440581997437613==-- From bitwiz@12bitsbest.com Wed Dec 4 19:00:53 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 13:00:21 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2086211757190096621==" --===============2086211757190096621== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I remember trying to hack the HP9114 3.5" HP-IL floppy drive to handle two drives in a single enclosure back in the day. On 12/4/2024 12:53 PM, Tony Duell wrote: > On Wed, Dec 4, 2024 at 6:49 PM Mike Katz wrote: >> Tony, >> >> I still say the 6809 was the best 8 bit micro ever. > No dispute from me on that point :-) > > >> Though I don't have any 6809 systems here I still have my 6809/6809E >> Microprocessor Programming Manual from 1981. > I still have my CoCos and a Acorn System with a 6809 CPU board in it. > And of course plenty of them in embedded systems -- mosr HP disk or > tape units contain one. So does my HP1630 logic analyser. > >> Lately I do more with my PDP-8's then anything recent like the 6809🙂 > Another elegant processor design. > > -tony --===============2086211757190096621==-- From g4ajq1@gmail.com Wed Dec 4 19:06:48 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 14:06:43 -0500 Message-ID: <6bdf5b26-2f66-4b99-8808-7c293d15213d@gmail.com> In-Reply-To: <6ab0541b-c47b-4540-ab01-2695ca22bd2d@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1364158650013072861==" --===============1364158650013072861== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-04 13:49, Mike Katz via cctalk wrote: > Tony, > > I still say the 6809 was the best 8 bit micro ever. > > Though I don't have any 6809 systems here I still have my 6809/6809E > Microprocessor Programming Manual from 1981. > > Lately I do more with my PDP-8's then anything recent like the 6809🙂 > > > On 12/4/2024 12:30 PM, Tony Duell wrote: >> On Wed, Dec 4, 2024 at 6:24 PM Mike Katz wrote: >>> Tony, >>> >>> Thank you for the education.  I did some minimal programming of the >>> 6847 >>> on the CoCo and nothing really on the 6845. >>> >>> A majority of the 6809 programming that I did was for Gimix, when I >>> worked there in the early 1980's. >>> >>> And then on embedded 6809 based system, also in the early 1980's. >> In the second half of the 1980s I did a few embedded 6809 projects, my >> final year project at university and then some designs a for a company >> I did a summer job for. I developped all the code on my CoCo system >> under OS-9 and burnt the binaries into EPROMs using a home-made >> programmer on the CoCo. >> >> I still have all the hardware, still all works. My Motorola databook >> is still on the shelf, although the pages are falling out due to all >> the use it has had. Still love the 6809. >> >> -tony > I agree. The user stack pointer was a killer feature. Our repeater controller controlled, in real time, a 16 x 16 crosspoint matrix connecting audio and keying from receivers to transmitters, timeout timers for all RF gear individually, DTMF decode, and separate morse callsign generation for each transmitter.  It could decode on one channel while it was executing a DTMF command on another. We originally tried to do his with a 6800 but we needed one more 16-bit register to achieve real time and the morse sounded like it was being sent by a duink sailor with his left foot.! I heard they only discontinued it because the factory burned down, and never came up with its replacement. cheers, Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============1364158650013072861==-- From ard.p850ug1@gmail.com Wed Dec 4 19:10:07 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 19:09:50 +0000 Message-ID: In-Reply-To: <6bdf5b26-2f66-4b99-8808-7c293d15213d@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1282734667313953468==" --===============1282734667313953468== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via cctalk wrote: [6809] > I agree. The user stack pointer was a killer feature. I like(d) the progam counter relative addressing mode along with the long branch instructions so you could write position-independant code. -tony --===============1282734667313953468==-- From g4ajq1@gmail.com Wed Dec 4 19:14:22 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 14:14:07 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8310180294267449157==" --===============8310180294267449157== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-04 14:09, Tony Duell wrote: > On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via cctalk > wrote: > [6809] >> I agree. The user stack pointer was a killer feature. > I like(d) the progam counter relative addressing mode along with the > long branch instructions so you could write position-independant code. > > -tony Yes, a reminder of my pdp-11 days :-) -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============8310180294267449157==-- From cclist@sydex.com Wed Dec 4 19:31:00 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 19:30:52 +0000 Message-ID: In-Reply-To: <6ab0541b-c47b-4540-ab01-2695ca22bd2d@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4816261173107546992==" --===============4816261173107546992== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 12/4/24 10:49, Mike Katz via cctalk wrote: > I still say the 6809 was the best 8 bit micro ever. Perhaps, but it was also one of the last new 8-bit CPU designs, so there's that. The die had already been cast in favor of 16 bit CPUs by the time of its introduction. And it was far more *expensive* when compared with other commodity 8-biy CPUs. I recall that by 1984 or so, the OEM 10K pricing for a Z80A was under a dollar per unit. No way that the 6809, with a price north of $20 could compete with that. It was pretty much common knowledge that the 6809 was just a stopgap product, with a larger, more capable CPU in development due to be released Real Soon Now. Given the price differential of the 6809 against already established 8 bit CPUs and the specter of obsolescence, most vendors elected to wait or go with another already-established 8-bit chip. And then there's the idea that ya dance with the one that brung ya--which, in many cases was Intel or Zilog. --Chuck --===============4816261173107546992==-- From bfranchuk@jetnet.ab.ca Wed Dec 4 19:34:09 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 12:33:59 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0639937694615791630==" --===============0639937694615791630== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-04 12:14 p.m., Nigel Johnson Ham via cctalk wrote: > On 2024-12-04 14:09, Tony Duell wrote: >> On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via cctalk >> wrote: >> [6809] >>> I agree. The user stack pointer was a killer feature. >> I like(d) the progam counter relative addressing mode along with the >> long branch instructions so you could write position-independant code. >> >> -tony > > Yes, a reminder of my pdp-11 days :-) > But that really does not fix code and data relocation. You need a segment registers for that. --===============0639937694615791630==-- From bitwiz@12bitsbest.com Wed Dec 4 20:19:28 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 14:19:19 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8110561647683479749==" --===============8110561647683479749== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I'm sorry but you don't need segment registers for position independent code at all. Address all data off of the index registers or off the PC and all branches are relative. You can even have local stack for data using the U stack register. OS/9 was all relocatable, position independent code.  The only addresses that were absolute in OS/9 were the address of the I/O devices. OS/9 was a multi tasking, multi user operating system on the 6809. Level 1 ran in 64K, level 2 needed more and used Dynamic Address Translation to extend the addressing space to 1Mbyte. On 12/4/2024 1:33 PM, ben via cctalk wrote: > On 2024-12-04 12:14 p.m., Nigel Johnson Ham via cctalk wrote: >> On 2024-12-04 14:09, Tony Duell wrote: >>> On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via cctalk >>> wrote: >>> [6809] >>>> I agree. The user stack pointer was a killer feature. >>> I like(d) the progam counter relative addressing mode along with the >>> long branch instructions so you could write position-independant code. >>> >>> -tony >> >> Yes, a reminder of my pdp-11 days :-) >> > But that really does not fix code and data relocation. > You need a segment registers for that. > > --===============8110561647683479749==-- From ard.p850ug1@gmail.com Wed Dec 4 20:24:40 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 20:24:23 +0000 Message-ID: In-Reply-To: <7344d388-abab-42a4-bb33-04bb9382039b@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3899115169897320166==" --===============3899115169897320166== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 8:13 PM Mike Katz wrote: > And of course the best instruction in the chip was Sign Extend B into > A. That instruction was SEX in the Motorola assembler. > > CLR B > SEX > > was the same as > > CLR A > CLR B > > But then you could have sex in your code🙂 > > Hey, when I was in my 20's and programing the 6809 that was fun. In the UK there was a home computer based on the same Motorola schematic called the Dragon. Similar to the CoCo, but not identical. Anyway it was well-known at the time 'You can have SEX with a Dragon' -tony --===============3899115169897320166==-- From dave.g4ugm@gmail.com Wed Dec 4 20:54:07 2024 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleaning Card Punch Date: Wed, 04 Dec 2024 20:53:57 +0000 Message-ID: <8abd1ae3-c896-4d5b-b5b2-e06764ea041b@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4799820841702104397==" --===============4799820841702104397== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 04/12/2024 18:49, Tony Duell wrote: > On Wed, Dec 4, 2024 at 6:41=E2=80=AFPM David Wade via cctalk > wrote: >> Folks, >> I have been trying to restore a manual card punch. The type with 12 >> "Buttons" or "Plungers" that operate a lever which pushes a punch "pin" >> through a die to create a hole in a card. >> Its almost identical to this one:- >> >> https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Mach= ine/ > I know it. Mine has an ICT (International Computers and Tabulators) > badge on the front Mine says "Made In India" as well... >> >> so despite lots of cleaning some of the pins stick down. Does any one >> have any suggestions how to clean the small square slots? > From memory there's the stem of the key in circular holes. There's a > flat on the stem to engage the punch lever which is pivoted at the > left hand side. And the punch pin in the die block. > > Do you know what is sticking? The punch pin in the die block. After lots of cleaning the slots with a=20 very small file and lubricating with a modern lubricant with PTFE it now=20 seems to punch but the mechanism that controls the card advance seems to=20 stick.. > There's a unit with 12 slots with ball bearings between some of them > to the left of the buttons.. It prevents you pressing more than 1 > digit key down at once. That cam cause the levers to stick. It doesn't have this.... ... and I need to clean the rest... > -tony Dave --===============4799820841702104397==-- From bitwiz@12bitsbest.com Wed Dec 4 22:15:16 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 16:15:08 -0600 Message-ID: <8fbe9ccc-8d04-4f2b-9ec9-76a9e666b15a@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5842041384106779437==" --===============5842041384106779437== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit This reminded me of an instruction on the Power PC Micro Processor: Enforce In-Order Execution of I/O with the assembler code of EIEIO I considered this to be the Old McDonald of instructions. On 12/4/2024 2:24 PM, Tony Duell wrote: > On Wed, Dec 4, 2024 at 8:13 PM Mike Katz wrote: > >> And of course the best instruction in the chip was Sign Extend B into >> A. That instruction was SEX in the Motorola assembler. >> >> CLR B >> SEX >> >> was the same as >> >> CLR A >> CLR B >> >> But then you could have sex in your code🙂 >> >> Hey, when I was in my 20's and programing the 6809 that was fun. > In the UK there was a home computer based on the same Motorola > schematic called the Dragon. Similar to the CoCo, but not identical. > Anyway it was well-known at the time 'You can have SEX with a Dragon' > > -tony --===============5842041384106779437==-- From elson@pico-systems.com Wed Dec 4 23:08:25 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 17:08:17 -0600 Message-ID: <2bebbe76-dd55-0bcf-dadf-7417f580909a@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7456734582581201573==" --===============7456734582581201573== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/4/24 14:19, Mike Katz via cctalk wrote: > I'm sorry but you don't need segment registers for > position independent code at all. > > Address all data off of the index registers or off the PC > and all branches are relative. > The PDP-11 had short relative jumps, etc. that were +/- 128 words, so subroutines with small loops, etc. could run anywhere in memory without rerunning the compiler/assembler. The IBM 360 had a base register that was used in all memory references, so the entire object deck (program section, data section, constants) could be loaded anywhere in memory, then the base register was set to the beginning of the partition, and it was all relocatable.  However, if the code stored a physical address at any time (really common in 360 code) then the program could NOT be moved after it started running. Jon --===============7456734582581201573==-- From bitwiz@12bitsbest.com Thu Dec 5 01:19:16 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 14:13:10 -0600 Message-ID: <7344d388-abab-42a4-bb33-04bb9382039b@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3456528423075035929==" --===============3456528423075035929== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I liked the index modes, with accumulator and auto increment/decrement. The multi-byte push and pop off of the U register for block moves was nice. And of course the best instruction in the chip was Sign Extend B into A.  That instruction was SEX in the Motorola assembler. CLR    B SEX was the same as CLR    A CLR    B But then you could have sex in your code🙂 Hey, when I was in my 20's and programing the 6809 that was fun. On 12/4/2024 1:14 PM, Nigel Johnson Ham via cctalk wrote: > On 2024-12-04 14:09, Tony Duell wrote: >> On Wed, Dec 4, 2024 at 7:06 PM Nigel Johnson Ham via cctalk >> wrote: >> [6809] >>> I agree. The user stack pointer was a killer feature. >> I like(d) the progam counter relative addressing mode along with the >> long branch instructions so you could write position-independant code. >> >> -tony > > Yes, a reminder of my pdp-11 days :-) > --===============3456528423075035929==-- From spectre@floodgap.com Thu Dec 5 01:44:07 2024 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 17:43:59 -0800 Message-ID: <10cfa51a-afe8-4375-8338-62dfc44d68be@floodgap.com> In-Reply-To: <8fbe9ccc-8d04-4f2b-9ec9-76a9e666b15a@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1064284210934515922==" --===============1064284210934515922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > This reminded me of an instruction on the Power PC Micro Processor: Enforce > In-Order Execution of I/O with the assembler code of EIEIO >=20 > I considered this to be the Old McDonald of instructions. eieio is a classic, but my favourite new Power ISA instruction is xxlxor (a vector XOR instruction). --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Who ever said the human race was logical? -- Gillian, Star Trek IV -------= -- --===============1064284210934515922==-- From bitwiz@12bitsbest.com Thu Dec 5 02:56:27 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Wed, 04 Dec 2024 20:21:02 -0600 Message-ID: <1551e8ba-a39f-4d72-af30-4b3c2ff80caf@12bitsbest.com> In-Reply-To: <2bebbe76-dd55-0bcf-dadf-7417f580909a@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0994786521411328245==" --===============0994786521411328245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The 6809 has an 8 bit Direct Page register.  This allows short memory reference instructions on any 256 byte area in memory. This would save both program bytes and CPU cycles. On 12/4/2024 5:08 PM, Jon Elson via cctalk wrote: > On 12/4/24 14:19, Mike Katz via cctalk wrote: >> I'm sorry but you don't need segment registers for position >> independent code at all. >> >> Address all data off of the index registers or off the PC and all >> branches are relative. >> > The PDP-11 had short relative jumps, etc. that were +/- 128 words, so > subroutines with small loops, etc. could run anywhere in memory > without rerunning the compiler/assembler. > > The IBM 360 had a base register that was used in all memory > references, so the entire object deck (program section, data section, > constants) could be loaded anywhere in memory, then the base register > was set to the beginning of the partition, and it was all > relocatable.  However, if the code stored a physical address at any > time (really common in 360 code) then the program could NOT be moved > after it started running. > > Jon > > --===============0994786521411328245==-- From ard.p850ug1@gmail.com Thu Dec 5 03:59:54 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Thu, 05 Dec 2024 03:59:37 +0000 Message-ID: In-Reply-To: <8fbe9ccc-8d04-4f2b-9ec9-76a9e666b15a@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6881104669907102895==" --===============6881104669907102895== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 10:15 PM Mike Katz wrote: > > This reminded me of an instruction on the Power PC Micro Processor: > Enforce In-Order Execution of I/O with the assembler code of EIEIO > > I considered this to be the Old McDonald of instructions. Not an instruction, but the common I/O board in a PERQ2 is the EIO (Ethernet and Input/Output). There was also OIO (Optional Input/Output) which provided the 16 bit PERQlink parallel port and a Canon laser printer interface. Ths led to 'Old McDonald had a PERQ E-I-O-I-O' -tony --===============6881104669907102895==-- From lproven@gmail.com Thu Dec 5 13:20:41 2024 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Thu, 05 Dec 2024 13:20:24 +0000 Message-ID: In-Reply-To: <6ab0541b-c47b-4540-ab01-2695ca22bd2d@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8685968744831350414==" --===============8685968744831350414== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 4 Dec 2024 at 18:56, Mike Katz via cctalk w= rote: > > I still say the 6809 was the best 8 bit micro ever. By "micro" here you mean "microprocessor" rather than the more usual "microcomputer", yes? Not being an assembly level programmer, I never cared, but this may interest 6809 fans: Arguably the greatest 6502 machine, the Atari XE, with a 6809 brain transplan= t: http://liber809.blogspot.com/ https://github.com/boisy/liber809/tree/master/atari --=20 Liam Proven ~ Profile: https://about.me/liamproven Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 227612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053 --===============8685968744831350414==-- From ethan.dicks@gmail.com Thu Dec 5 21:37:36 2024 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: A bit of humor to test the list Date: Thu, 05 Dec 2024 16:37:20 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4324786260771637056==" --===============4324786260771637056== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, Dec 4, 2024 at 11:55 AM Tony Duell via cctalk wrote: > > What is not well known is that the CoCo was actually designed by > > Motorola, and appeared in their Microprocessor data book as a > > double-page schematic to promote the 6809! > > Wasn't it actually a suggested schematic for the 6883 synchronous > address multiplexer chip? Huh... talk about synchronicity... Minutes ago I collected a packet from my mailbox with some vintage chips... CDP1802CD, CDP1852, Hitachi 68450, MC6860, and an MC6883. ... and then I see a list thread talking about the MC6883. Wild. -ethan --===============4324786260771637056==-- From bitwiz@12bitsbest.com Thu Dec 5 22:43:19 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] VT-100 Text Windows library Date: Thu, 05 Dec 2024 16:43:10 -0600 Message-ID: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4779630881989013374==" --===============4779630881989013374== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I am looking for a C library that implements a crude windowing system on a VT-100 or compatible terminal via the serial port.  I've seen such things before but not recently. I will be running this on bare metal (no operating system). Preferably the package would use the regional scrolling capabilities of the VT-100 for faster screen updates. I might be able to get Txwindows to work but I am looking for something a bit simpler? Any ideas would be greatly appreciated. Thank you....        Mike --===============4779630881989013374==-- From wayne.sudol@hotmail.com Thu Dec 5 23:17:07 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 23:16:57 +0000 Message-ID: In-Reply-To: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6156758204215586287==" --===============6156758204215586287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Under VMS i think the smg$ routines did that. Sent from my iPhone > On Dec 5, 2024, at 14:43, Mike Katz via cctalk wr= ote: >=20 > =EF=BB=BFI am looking for a C library that implements a crude windowing sys= tem on a VT-100 or compatible terminal via the serial port. I've seen such t= hings before but not recently. >=20 > I will be running this on bare metal (no operating system). Preferably the = package would use the regional scrolling capabilities of the VT-100 for faste= r screen updates. >=20 > I might be able to get Txwindows to work but I am looking for something a b= it simpler? >=20 > Any ideas would be greatly appreciated. >=20 > Thank you.... >=20 > Mike --===============6156758204215586287==-- From bitwiz@12bitsbest.com Thu Dec 5 23:20:51 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 17:20:42 -0600 Message-ID: <067fa105-29a5-4d50-98a6-9415bdeac130@12bitsbest.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181F880910CE71A7AE741E8E4302=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4712651754478252519==" --===============4712651754478252519== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you i don't think an ESP32 has the horsepower to run VMS=F0=9F=99=82 On 12/5/2024 5:16 PM, Wayne S wrote: > Under VMS i think the smg$ routines did that. > > Sent from my iPhone > >> On Dec 5, 2024, at 14:43, Mike Katz via cctalk w= rote: >> >> =EF=BB=BFI am looking for a C library that implements a crude windowing sy= stem on a VT-100 or compatible terminal via the serial port. I've seen such = things before but not recently. >> >> I will be running this on bare metal (no operating system). Preferably the= package would use the regional scrolling capabilities of the VT-100 for fast= er screen updates. >> >> I might be able to get Txwindows to work but I am looking for something a = bit simpler? >> >> Any ideas would be greatly appreciated. >> >> Thank you.... >> >> Mike --===============4712651754478252519==-- From wayne.sudol@hotmail.com Thu Dec 5 23:51:44 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 23:51:37 +0000 Message-ID: In-Reply-To: <067fa105-29a5-4d50-98a6-9415bdeac130@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4818517764712430899==" --===============4818517764712430899== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Oh. You didn=E2=80=99t specify the host type, although an esp MAY be fast eno= ugh. The Vax wasn=E2=80=99t that fast to begin with and ran in less than 4 MB= memory so maybe=E2=80=A6 Sent from my iPhone > On Dec 5, 2024, at 15:20, Mike Katz wrote: >=20 > =EF=BB=BFThank you >=20 > i don't think an ESP32 has the horsepower to run VMS=F0=9F=99=82 >=20 >> On 12/5/2024 5:16 PM, Wayne S wrote: >> Under VMS i think the smg$ routines did that. >>=20 >> Sent from my iPhone >>=20 >>>> On Dec 5, 2024, at 14:43, Mike Katz via cctalk = wrote: >>>=20 >>> =EF=BB=BFI am looking for a C library that implements a crude windowing s= ystem on a VT-100 or compatible terminal via the serial port. I've seen such= things before but not recently. >>>=20 >>> I will be running this on bare metal (no operating system). Preferably th= e package would use the regional scrolling capabilities of the VT-100 for fas= ter screen updates. >>>=20 >>> I might be able to get Txwindows to work but I am looking for something a= bit simpler? >>>=20 >>> Any ideas would be greatly appreciated. >>>=20 >>> Thank you.... >>>=20 >>> Mike >=20 --===============4818517764712430899==-- From wayne.sudol@hotmail.com Fri Dec 6 00:41:31 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Fri, 06 Dec 2024 00:41:23 +0000 Message-ID: In-Reply-To: <7f1be09e-40ea-4f3f-bb43-972dd2f94cbd@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6339914422410002771==" --===============6339914422410002771== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yep. I missed the =E2=80=9Cbare metal=E2=80=9D Sent from my iPhone > On Dec 5, 2024, at 16:31, Mike Katz wrote: >=20 > =EF=BB=BFI'm sorry I thought bare metal (no operating system) was descripti= ve enough. >=20 > To clarify I will be running this on an Doit ESP32 Devkit V1 Board with a d= ual core Tensilica Xtensa L6 CPU running at 240 MHz with 4MB Flash and 520K R= AM. >=20 > The code is Arduino based (it's not my original code). >=20 >> On 12/5/2024 5:51 PM, Wayne S wrote: >> Oh. You didn=E2=80=99t specify the host type, although an esp MAY be fast = enough. The Vax wasn=E2=80=99t that fast to begin with and ran in less than 4= MB memory so maybe=E2=80=A6 >> Sent from my iPhone >>=20 >>>> On Dec 5, 2024, at 15:20, Mike Katz wrote: >>>=20 >>> =EF=BB=BFThank you >>>=20 >>> i don't think an ESP32 has the horsepower to run VMS=F0=9F=99=82 >>>=20 >>>> On 12/5/2024 5:16 PM, Wayne S wrote: >>>> Under VMS i think the smg$ routines did that. >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>>> On Dec 5, 2024, at 14:43, Mike Katz via cctalk wrote: >>>>> =EF=BB=BFI am looking for a C library that implements a crude windowing= system on a VT-100 or compatible terminal via the serial port. I've seen su= ch things before but not recently. >>>>>=20 >>>>> I will be running this on bare metal (no operating system). Preferably = the package would use the regional scrolling capabilities of the VT-100 for f= aster screen updates. >>>>>=20 >>>>> I might be able to get Txwindows to work but I am looking for something= a bit simpler? >>>>>=20 >>>>> Any ideas would be greatly appreciated. >>>>>=20 >>>>> Thank you.... >>>>>=20 >>>>> Mike >=20 --===============6339914422410002771==-- From bitwiz@12bitsbest.com Fri Dec 6 01:16:06 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 19:15:55 -0600 Message-ID: <80464a54-d1b8-4ea8-97d3-4eea4b20d502@12bitsbest.com> In-Reply-To: <986711F4-7F40-4EFB-85E6-076BA519FA50@kdbarto.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8703302298636826802==" --===============8703302298636826802== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thank you. Screen is a linux utility.  I am writing this on a bare metal (no operating system) ESP32 dev board. Right now the program is text menu driven.  I would like to enhance it with textual windows. The Txwindows package is perfect but over kill and will need some hacking to work in my environment and it doesn't support the VT-100's region scrolling so screen updates might be slow. On 12/5/2024 6:32 PM, David Barto wrote: > > >> On Dec 5, 2024, at 2:43 PM, Mike Katz via cctalk >> wrote: >> >> I am looking for a C library that implements a crude windowing system >> on a VT-100 or compatible terminal via the serial port.  I've seen >> such things before but not recently. >> >> I will be running this on *bare metal (no operating system)*. >> Preferably the package would use the regional scrolling capabilities >> of the VT-100 for faster screen updates. >> >> I might be able to get Txwindows to work but I am looking for >> something a bit simpler? >> >> Any ideas would be greatly appreciated. >> >> Thank you.... >> >>        Mike > > Screen(1) https://manpages.org/screen could do what you are thinking of. > > David > > A: Because it messes up the order in which people normally read text. > Q: Why is it such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > David Barto > barto(a)kdbarto.org > > --===============8703302298636826802==-- From bitwiz@12bitsbest.com Fri Dec 6 01:25:17 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 18:31:19 -0600 Message-ID: <7f1be09e-40ea-4f3f-bb43-972dd2f94cbd@12bitsbest.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21817F626D00291B5C84829EE4302=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6433770746879358135==" --===============6433770746879358135== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm sorry I thought bare metal (no operating system) was descriptive enough. To clarify I will be running this on an Doit ESP32 Devkit V1 Board with=20 a dual core Tensilica Xtensa L6 CPU running at 240 MHz with 4MB Flash=20 and 520K RAM. The code is Arduino based (it's not my original code). On 12/5/2024 5:51 PM, Wayne S wrote: > Oh. You didn=E2=80=99t specify the host type, although an esp MAY be fast e= nough. The Vax wasn=E2=80=99t that fast to begin with and ran in less than 4 = MB memory so maybe=E2=80=A6 > Sent from my iPhone > >> On Dec 5, 2024, at 15:20, Mike Katz wrote: >> >> =EF=BB=BFThank you >> >> i don't think an ESP32 has the horsepower to run VMS=F0=9F=99=82 >> >>> On 12/5/2024 5:16 PM, Wayne S wrote: >>> Under VMS i think the smg$ routines did that. >>> >>> Sent from my iPhone >>> >>>>> On Dec 5, 2024, at 14:43, Mike Katz via cctalk wrote: >>>> =EF=BB=BFI am looking for a C library that implements a crude windowing = system on a VT-100 or compatible terminal via the serial port. I've seen suc= h things before but not recently. >>>> >>>> I will be running this on bare metal (no operating system). Preferably t= he package would use the regional scrolling capabilities of the VT-100 for fa= ster screen updates. >>>> >>>> I might be able to get Txwindows to work but I am looking for something = a bit simpler? >>>> >>>> Any ideas would be greatly appreciated. >>>> >>>> Thank you.... >>>> >>>> Mike --===============6433770746879358135==-- From elson@pico-systems.com Fri Dec 6 02:19:16 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 20:19:09 -0600 Message-ID: <83314eff-bee4-4fd6-7077-f45bf3bfd790@pico-systems.com> In-Reply-To: <7f1be09e-40ea-4f3f-bb43-972dd2f94cbd@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0614591710466964497==" --===============0614591710466964497== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > On 12/5/2024 5:51 PM, Wayne S wrote: >> Oh. You didn’t specify the host type, although an esp MAY >> be fast enough. The Vax wasn’t that fast to begin with >> and ran in less than 4 MB memory so maybe… The first VAX 11/780 I used came with 512 KB of memory.  One Friday afternoon, it crashed and I ran diags and found a memory board had died, and pulled the bad one out.  We had to run on 256KB over the weekend until DEC could come out and swap it.  It ran a HUGE finite element analysis.  I warned everybody to restrict number of logons and other processes. Jon --===============0614591710466964497==-- From bill.gunshannon@hotmail.com Fri Dec 6 02:49:11 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 21:48:21 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181F880910CE71A7AE741E8E4302=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8715753854328244460==" --===============8715753854328244460== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 12/5/2024 6:16 PM, Wayne S via cctalk wrote: > Under VMS i think the smg$ routines did that. > I was going to mention something from the old comp.source.xxx newsgroup but it would have been for Unix and he specifically said bare metal. bill --===============8715753854328244460==-- From bill.gunshannon@hotmail.com Fri Dec 6 02:52:44 2024 From: Bill Gunshannon To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 21:52:22 -0500 Message-ID: In-Reply-To: <83314eff-bee4-4fd6-7077-f45bf3bfd790@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1964783043174850489==" --===============1964783043174850489== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/5/2024 9:19 PM, Jon Elson via cctalk wrote: > >> On 12/5/2024 5:51 PM, Wayne S wrote: >>> Oh. You didn’t specify the host type, although an esp MAY be fast >>> enough. The Vax wasn’t that fast to begin with and ran in less than 4 >>> MB memory so maybe… > > The first VAX 11/780 I used came with 512 KB of memory.  One Friday > afternoon, it crashed and I ran diags and found a memory board had died, > and pulled the bad one out.  We had to run on 256KB over the weekend > until DEC could come out and swap it.  It ran a HUGE finite element > analysis.  I warned everybody to restrict number of logons and other > processes. Your just lucky no one decided to run the Ada compiler. Nothing can bring a VAX to its knees better than that. Not even Eunice!! bill --===============1964783043174850489==-- From johnhreinhardt@thereinhardts.org Fri Dec 6 04:11:17 2024 From: "John H. Reinhardt" To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 22:05:36 -0600 Message-ID: <3fa01ec6-c886-4772-8e7e-a93db071c3ae@thereinhardts.org> In-Reply-To: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5073406940644787455==" --===============5073406940644787455== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Since it's and ESP32 you have, you might look into the screen routines in htt= p://www.fabglib.org/ "FabGL is mainly a Graphics Library for ESP32. It implements several display = drivers (for direct VGA output and for I2C and SPI LCD drivers). FabGL can also get input from a PS/2 Keyboard and a Mouse. ULP core handles P= S/2 ports communications, leaving main CPU cores free to perform other tasks. FabGL also implements: an Audio Engine, a Graphical User Interface (GUI), a G= ame Engine and an ANSI/VT Terminal. This library works with ESP32 revision 1 and upper." The VT132 emulator board from TheHighNibble uses the FabGL package for it's V= T emulator.=C2=A0 It works very well. --=20 John H. Reinhardt On 12/5/2024 4:43 PM, Mike Katz via cctalk wrote: > I am looking for a C library that implements a crude windowing system on a = VT-100 or compatible terminal via the serial port. I've seen such things befo= re but not recently. > > I will be running this on bare metal (no operating system). Preferably the = package would use the regional scrolling capabilities of the VT-100 for faste= r screen updates. > > I might be able to get Txwindows to work but I am looking for something a b= it simpler? > > Any ideas would be greatly appreciated. > > Thank you.... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mike --===============5073406940644787455==-- From johnhreinhardt@thereinhardts.org Fri Dec 6 04:11:20 2024 From: "John H. Reinhardt" To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 22:03:32 -0600 Message-ID: In-Reply-To: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5020216914485293435==" --===============5020216914485293435== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Since it's and ESP32 you have, you might look into the screen routines in htt= p://www.fabglib.org/ "FabGL is mainly a Graphics Library for ESP32. It implements several display = drivers (for direct VGA output and for I2C and SPI LCD drivers). FabGL can also get input from a PS/2 Keyboard and a Mouse. ULP core handles P= S/2 ports communications, leaving main CPU cores free to perform other tasks. FabGL also implements: an Audio Engine, a Graphical User Interface (GUI), a G= ame Engine and an ANSI/VT Terminal. This library works with ESP32 revision 1 and upper." The VT132 emulator board from TheHighNibble uses the FabGL package for it's V= T emulator.=C2=A0 It works very well. --=20 John H. Reinhardt On 12/5/2024 4:43 PM, Mike Katz via cctalk wrote: > I am looking for a C library that implements a crude windowing system on a = VT-100 or compatible terminal via the serial port. I've seen such things befo= re but not recently. > > I will be running this on bare metal (no operating system). Preferably the = package would use the regional scrolling capabilities of the VT-100 for faste= r screen updates. > > I might be able to get Txwindows to work but I am looking for something a b= it simpler? > > Any ideas would be greatly appreciated. > > Thank you.... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mike --===============5020216914485293435==-- From cloos@jhcloos.com Fri Dec 6 05:52:38 2024 From: James Cloos To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Fri, 06 Dec 2024 00:47:24 -0500 Message-ID: In-Reply-To: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0608379585839615824==" --===============0608379585839615824== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit i tried to remind myself of the details of a terminal multiplexer i used back in the early 90's. i think i recall it was named 'term', but that obviously isn't a very useful sesrch term. :) while looking for it i came across: https://github.com/deadpixi/mtm which wilipedia describes as extremely small. perhaps small enough? -JimC -- James Cloos OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc --===============0608379585839615824==-- From bitwiz@12bitsbest.com Fri Dec 6 16:49:21 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Fri, 06 Dec 2024 09:24:30 -0600 Message-ID: <5f7ba027-ce82-4527-96a8-6c6673a164e5@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8387056236151256698==" --===============8387056236151256698== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Thank you. This program will allow me to create an ANSII terminal on a graphics display (LCD or VGA) on an ESP-32. I will be connected a real live terminal (or terminal emulator) via the serial port to the ESP-32 and I need the ESP-32 to send ANSI codes to the terminal to create windows. Txwindows is a superset of what i am looking for. On 12/5/2024 10:03 PM, John H. Reinhardt via cctalk wrote: > Since it's and ESP32 you have, you might look into the screen routines > in http://www.fabglib.org/ > > "FabGL is mainly a Graphics Library for ESP32. It implements several > display drivers (for direct VGA output and for I2C and SPI LCD drivers). > > FabGL can also get input from a PS/2 Keyboard and a Mouse. ULP core > handles PS/2 ports communications, leaving main CPU cores free to > perform other tasks. > FabGL also implements: an Audio Engine, a Graphical User Interface > (GUI), a Game Engine and an ANSI/VT Terminal. > > This library works with ESP32 revision 1 and upper." > > > The VT132 emulator board from TheHighNibble uses the FabGL package for > it's VT emulator.  It works very well. > --===============8387056236151256698==-- From chd@chdickman.com Sat Dec 7 00:10:24 2024 From: Charles Dickman To: cctalk@classiccmp.org Subject: [cctalk] European wire size (slightly off topic) Date: Fri, 06 Dec 2024 19:10:07 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4875387630788768409==" --===============4875387630788768409== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit How are small wire sizes specified in Europe? I have seen that EN 60228 defines wire cross sections down to 0.5mm2. What about smaller than that? Does the standard go smaller? Stranded wire must consist of smaller solid strands. -chuck Off topic, but perhaps edifying for all. --===============4875387630788768409==-- From cclist@sydex.com Sat Dec 7 00:32:09 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: European wire size (slightly off topic) Date: Sat, 07 Dec 2024 00:31:59 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6207708506741950670==" --===============6207708506741950670== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit https://www.rapidtables.com/calc/wire/awg-to-mm.html mm2 seems to be the rule for large wires, and mm (diameter) for smaller ones. --Chuck On 12/6/24 16:10, Charles Dickman via cctalk wrote: > How are small wire sizes specified in Europe? I have seen that EN 60228 > defines wire cross sections down to 0.5mm2. What about smaller than that? > Does the standard go smaller? Stranded wire must consist of smaller solid > strands. > > -chuck > > Off topic, but perhaps edifying for all. --===============6207708506741950670==-- From holm@freibergnet.de Sat Dec 7 09:00:08 2024 From: Holm Tiffe To: cctalk@classiccmp.org Subject: [cctalk] Re: European wire size (slightly off topic) Date: Sat, 07 Dec 2024 09:59:57 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8993987731790799996==" --===============8993987731790799996== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Yes. But the diameter is always meant w/o the isolation. Regards, Holm Chuck Guzis via cctalk wrote: > > https://www.rapidtables.com/calc/wire/awg-to-mm.html > > mm2 seems to be the rule for large wires, and mm (diameter) for smaller > ones. > > --Chuck > > > On 12/6/24 16:10, Charles Dickman via cctalk wrote: > > How are small wire sizes specified in Europe? I have seen that EN 60228 > > defines wire cross sections down to 0.5mm2. What about smaller than that? > > Does the standard go smaller? Stranded wire must consist of smaller solid > > strands. > > > > -chuck > > > > Off topic, but perhaps edifying for all. -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Goethestrasse 15, 09569 Oederan, USt-Id: DE253710583 info(a)tsht.de Tel +49 37292 709778 Mobil: 0172 8790 741 --===============8993987731790799996==-- From osi.superboard@gmail.com Sat Dec 7 10:34:22 2024 From: "osi.superboard" To: cctalk@classiccmp.org Subject: [cctalk] Re: European wire size (slightly off topic) Date: Sat, 07 Dec 2024 10:33:37 +0000 Message-ID: <17bafc50-a261-4ded-a32e-0c46f96e6b15@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7324307539695291297==" --===============7324307539695291297== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Elektrisola provides a good overview https://www.elektrisola.com/en-us Single core wire go down to 0.000078540 mm2 / 0.010 mm in diameter (IEC 60317) or extrudes litz wires down to 0.5 mm in diameter Thomas On 07.12.2024 00:10, Charles Dickman via cctalk wrote: > How are small wire sizes specified in Europe? I have seen that EN 60228 > defines wire cross sections down to 0.5mm2. What about smaller than that? > Does the standard go smaller? Stranded wire must consist of smaller solid > strands. > > -chuck > > Off topic, but perhaps edifying for all. --===============7324307539695291297==-- From mjd.bishop@emeritus-solutions.com Sat Dec 7 14:45:41 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: European wire size (slightly off topic) Date: Sat, 07 Dec 2024 14:43:43 +0000 Message-ID: <14ad7b6e02a04154ab43f3e734b7e91a@emeritus-solutions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0640307529377491241==" --===============0640307529377491241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From the US, the UK is (probably), in Europe ? Beyond simply using US wire / sizes, and ignoring the definition of wire/cabl= e, the main things you can source in the UK are: Tri rated wire https://www.elandcables.com/cables/tri-rated-h05v2-k-h07v2-k-c= able#ProductListing 0.5 mm sq and up UK MoD DefStan wire/cable https://www.elandcables.com/cables/defence-standard= -61-12-cable=20 https://www.elandcables.com/media/39719/defence-standard-61-12-part-6-equipme= nt-wire.pdf https://www.elandcables.com/media/38355/defence-standard-61-12-part-4-cable.p= df eg the Part4 spec offers 0.055 mm sq (7 x 0.1 mm) and 0.22 mm sq (7 x 0.2 mm)= , and Part6 carries on with 16 x 0.2 mm for 0.5 mm sq etc Finally, tinned and enamelled copper wire continue to be sold in Standard Wir= e Gauge (SWG) sizes https://www.engineeringtoolbox.com/swg-standard-wire-gaug= e-d_1779.html eg https://www.rapidonline.com/unistrand-tinned-copper-wire-62485 and https://www.rapidonline.com/unistrand-enamelled-copper-wire-62484 And, for stranded wire the strands are usu 0.2 mm dia, 0.1 mm dia for the sma= llest condiuctors HtH; Best Regards Martin -----Original Message----- From: Charles Dickman via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 07 December 2024 00:10 To: General Discussion: On-Topic and Off-Topic Posts Cc: Charles Dickman Subject: [cctalk] European wire size (slightly off topic) How are small wire sizes specified in Europe? I have seen that EN 60228 defin= es wire cross sections down to 0.5mm2. What about smaller than that? Does the standard go smaller? Stranded wire must consist of smaller solid str= ands. -chuck Off topic, but perhaps edifying for all. --===============0640307529377491241==-- From curiousmarc3@gmail.com Sun Dec 8 03:21:49 2024 From: Curious Marc To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleaning Card Punch Date: Sat, 07 Dec 2024 19:21:32 -0800 Message-ID: In-Reply-To: <8abd1ae3-c896-4d5b-b5b2-e06764ea041b@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1710430767112446103==" --===============1710430767112446103== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Looks like a perfect copy of an IBM 001. They probably copied the defects too= =E2=80=A6 I=E2=80=99d look up IBM 001 manual. Marc > On Dec 4, 2024, at 1:01=E2=80=AFPM, David Wade via cctalk wrote: >=20 > =EF=BB=BF >=20 >> On 04/12/2024 18:49, Tony Duell wrote: >>> On Wed, Dec 4, 2024 at 6:41=E2=80=AFPM David Wade via cctalk >>> wrote: >>> Folks, >>> I have been trying to restore a manual card punch. The type with 12 >>> "Buttons" or "Plungers" that operate a lever which pushes a punch "pin" >>> through a die to create a hole in a card. >>> Its almost identical to this one:- >>>=20 >>> https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Mac= hine/ >> I know it. Mine has an ICT (International Computers and Tabulators) >> badge on the front > Mine says "Made In India" as well... >=20 >>>=20 >>> so despite lots of cleaning some of the pins stick down. Does any one >>> have any suggestions how to clean the small square slots? >> From memory there's the stem of the key in circular holes. There's a >> flat on the stem to engage the punch lever which is pivoted at the >> left hand side. And the punch pin in the die block. >>=20 >> Do you know what is sticking? > The punch pin in the die block. After lots of cleaning the slots with a ver= y small file and lubricating with a modern lubricant with PTFE it now seems t= o punch but the mechanism that controls the card advance seems to stick.. >=20 >> There's a unit with 12 slots with ball bearings between some of them >> to the left of the buttons.. It prevents you pressing more than 1 >> digit key down at once. That cam cause the levers to stick. >=20 > It doesn't have this.... > ... and I need to clean the rest... >=20 >> -tony > Dave --===============1710430767112446103==-- From dave.g4ugm@gmail.com Sun Dec 8 07:57:16 2024 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: Cleaning Card Punch Date: Sun, 08 Dec 2024 07:57:07 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3825686444059797032==" --===============3825686444059797032== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 08/12/2024 03:21, Curious Marc wrote: > Looks like a perfect copy of an IBM 001. They probably copied the defects t= oo=E2=80=A6 I=E2=80=99d look up IBM 001 manual. > Marc I think so, IBM itself didn't sell punched card equipment in the UK or=20 the British Empire until 1948. (Except Canada) Prior to that the British Tabulating Machine Company had the exclusive=20 rights to make and sell its card processing machines. https://en.wikipedia.org/wiki/British_Tabulating_Machine_Company So pre 1948 all of their machines were basically copies of IBM machines. They joined with "Powers-Samas" in 1959 to become "International=20 Calculators and Tabulators" and by this time they were designing their=20 own machines. I expect that as any patents on the Model 001 would have expired they=20 just kept on making them, but with an ICT plate, and later an ICL plate Dave >> On Dec 4, 2024, at 1:01=E2=80=AFPM, David Wade via cctalk wrote: >> >> =EF=BB=BF >> >>> On 04/12/2024 18:49, Tony Duell wrote: >>>> On Wed, Dec 4, 2024 at 6:41=E2=80=AFPM David Wade via cctalk >>>> wrote: >>>> Folks, >>>> I have been trying to restore a manual card punch. The type with 12 >>>> "Buttons" or "Plungers" that operate a lever which pushes a punch "pin" >>>> through a die to create a hole in a card. >>>> Its almost identical to this one:- >>>> >>>> https://www.computinghistory.org.uk/det/38019/ICL-Hand-Key-Punch-Card-Ma= chine/ >>> I know it. Mine has an ICT (International Computers and Tabulators) >>> badge on the front >> Mine says "Made In India" as well... >> >>>> so despite lots of cleaning some of the pins stick down. Does any one >>>> have any suggestions how to clean the small square slots? >>> From memory there's the stem of the key in circular holes. There's a >>> flat on the stem to engage the punch lever which is pivoted at the >>> left hand side. And the punch pin in the die block. >>> >>> Do you know what is sticking? >> The punch pin in the die block. After lots of cleaning the slots with a ve= ry small file and lubricating with a modern lubricant with PTFE it now seems = to punch but the mechanism that controls the card advance seems to stick.. >> >>> There's a unit with 12 slots with ball bearings between some of them >>> to the left of the buttons.. It prevents you pressing more than 1 >>> digit key down at once. That cam cause the levers to stick. >> It doesn't have this.... >> ... and I need to clean the rest... >> >>> -tony >> Dave --===============3825686444059797032==-- From ard.p850ug1@gmail.com Sun Dec 8 18:54:59 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Philips P2000C disk format Date: Sun, 08 Dec 2024 18:54:44 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6518495711962235961==" --===============6518495711962235961== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The quick version : Does anyone know the exact physical and logical disk format used by CP/M on the Philips P2000C portable computer? The long version with explanations : I am having reasonable success transfering files to/from disk images for my Osborne 1A (using cpmtools) and IBM5155 (MS-DOS, of course using editdisk). And I've even got the Greaseweazle to transfer those images to/from real floppies. The Greaseweazle still annoys me in that I know it's capable of a lot more if only I could work out how to do it, but at least it does something useful [The less said about floppy disks shedding oxide and/or suffering from 'sticky shed' the better. I'm spending far too much time dismantling and cleaning drives....] Any, I'd like to do the same for another of my machines, a Philips P2000C cp/m 'portable'. My machine is the version with 2 internal 40 cylinder single head drives (about 160K each, MFM) but I can also plug in an external 80 cylinder double head drive to handle this machine's other native format (about 640K). Unfortunately, this machine is not common, and neither cpmtools nor the greaseweazle software has the formats predefined. I could add them myself -- if I knew what they were. Things like #sectors/track, sector size, #system tracks, skew, etc. It's not obviously given in any of the manuals I have, so does anyone know it before I try to work it out. Alternatively there are rumours that the P2000C could read/write at least one more common cp/m disk type. The hardware should be capable of it, sure. Doe anyone know if software to do something like this exists anywhere for the P2000C. I can't find it on any of the obvious sites -tony --===============6518495711962235961==-- From robert.jarratt@ntlworld.com Sun Dec 8 19:39:51 2024 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Rainbow Z80 firmware Date: Sun, 08 Dec 2024 19:28:58 +0000 Message-ID: <003201db49a7$6df943a0$49ebcae0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2920187080268664550==" --===============2920187080268664550== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello everyone, I am working on a Rainbow 100A which is showing a diagnostic code on the lights at the back of 0110101. This is supposed to be Message 1 "Main Board Video". I have disassembled the 8088 firmware and checked address traces with a logic analyser and my suspicion is that actually this is something to do with the interaction with the Z80 because it is reading a status from the shared memory and then using that to set the status lights. I have been unable so far to work out where in the ROMs the Z80 code lives or where in the 8088 code it transfers it to the shared memory to allow the Z80 to run. Can anyone tell me where the Z80 firmware is in the ROMs? And does anyone have any insight into the above error or have details of the interaction between the Z80 and the 8088? The Technical Manual only goes so far unfortunately. Thanks Rob --===============2920187080268664550==-- From hp-fix@xs4all.nl Sun Dec 8 21:43:07 2024 From: hp-fix@xs4all.nl To: cctalk@classiccmp.org Subject: [cctalk] Re: Philips P2000C disk format Date: Sun, 08 Dec 2024 22:42:59 +0100 Message-ID: <031c01db49ba$267db980$73792c80$@xs4all.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7626783325653149909==" --===============7626783325653149909== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tony, Maybe this software catalogue will help you: https://electrickery.nl/comp/p2000c/doc/PTC_Katalogus.pdf -Rik -----Oorspronkelijk bericht----- Van: Tony Duell via cctalk =20 Verzonden: zondag 8 december 2024 19:55 Aan: General Discussion: On-Topic and Off-Topic Posts CC: Tony Duell Onderwerp: [cctalk] Philips P2000C disk format The quick version : Does anyone know the exact physical and logical disk form= at used by CP/M on the Philips P2000C portable computer? The long version with explanations : I am having reasonable success transfering files to/from disk images for my O= sborne 1A (using cpmtools) and IBM5155 (MS-DOS, of course using editdisk). An= d I've even got the Greaseweazle to transfer those images to/from real floppi= es. The Greaseweazle still annoys me in that I know it's capable of a lot mor= e if only I could work out how to do it, but at least it does something useful [The less said about floppy disks shedding oxide and/or suffering from 'stick= y shed' the better. I'm spending far too much time dismantling and cleaning d= rives....] Any, I'd like to do the same for another of my machines, a Philips P2000C cp/= m 'portable'. My machine is the version with 2 internal 40 cylinder single he= ad drives (about 160K each, MFM) but I can also plug in an external 80 cylind= er double head drive to handle this machine's other native format (about 640K= ). Unfortunately, this machine is not common, and neither cpmtools nor the greas= eweazle software has the formats predefined. I could add them myself -- if I = knew what they were. Things like #sectors/track, sector size, #system tracks,= skew, etc. It's not obviously given in any of the manuals I have, so does anyone know it= before I try to work it out. Alternatively there are rumours that the P2000C could read/write at least one= more common cp/m disk type. The hardware should be capable of it, sure. Doe = anyone know if software to do something like this exists anywhere for the P20= 00C. I can't find it on any of the obvious sites -tony --===============7626783325653149909==-- From imp@bsdimp.com Mon Dec 9 01:01:30 2024 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Rainbow Z80 firmware Date: Sun, 08 Dec 2024 18:01:13 -0700 Message-ID: In-Reply-To: <003201db49a7$6df943a0$49ebcae0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9039548945311043825==" --===============9039548945311043825== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 8, 2024 at 12:39=E2=80=AFPM Rob Jarratt via cctalk < cctalk(a)classiccmp.org> wrote: > Hello everyone, > > > > I am working on a Rainbow 100A which is showing a diagnostic code on the > lights at the back of 0110101. This is supposed to be Message 1 "Main Board > Video". > OK That's likely a failure of the main VT100 chips that's are buried inside the Rainbow. > I have disassembled the 8088 firmware and checked address traces with a > logic analyser and my suspicion is that actually this is something to do > with the interaction with the Z80 because it is reading a status from the > shared memory and then using that to set the status lights. > The video controller is connected directly to the 8088 side of the world. The Z80 has to make calls to the 8088 to output to the screen. > I have been unable so far to work out where in the ROMs the Z80 code lives > or where in the 8088 code it transfers it to the shared memory to allow the > Z80 to run. > https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/8086_DISA= SSEMBLY_from_23-020e5-00 has disassembled 8088 code. https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/Z80_DISAS= SEMBLY_from_23-020e5-00 has the Z80 code (so both are in the ROMs). This may be the 100B code, but the two models are quite similar in this detail. You can look through the 8086 assembly, I think to find where this error code is generated. I looked at this stuff ages ago when I was getting Venix to run under emulation, but that was 5 years ago now I think. > Can anyone tell me where the Z80 firmware is in the ROMs? And does anyone > have any insight into the above error or have details of the interaction > between the Z80 and the 8088? The Technical Manual only goes so far > unfortunately. > You might look at the mame emulation of the Rainbow. It does a decent job of things. There's a 2k shared memory area between the Z80 and 8088 that they use to do I/O. The floppy is connected to the Z80, while the hard disk, keyboard and video are connected to the 8088. The 8088 loads the Z80 code by writing a magic value that 'flips' the mapping. It then writes to the 'flipped' RAM and flips things back and restarts the Z80. bitsavers also has the schematics for both the 100A and 100B models. You really need them because they have the only documentation (or best documentation) for the I/O ports that are mapped. There is some registers documented in the TRM, but it's incomplete in some details at least if you are trying to write an emulator. It's a bit of a shame that the MAME efforts have run into personality issues that I'm not close enough to to positively affect. As such, all rainbow efforts have stalled for a couple of years now and the port uses older interfaces that have proven resistant to recoding in the new APIs. Warner --===============9039548945311043825==-- From robert.jarratt@ntlworld.com Mon Dec 9 06:58:07 2024 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: Rainbow Z80 firmware Date: Mon, 09 Dec 2024 06:57:58 +0000 Message-ID: <006f01db4a07$aec58b90$0c50a2b0$@ntlworld.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4185273439436399604==" --===============4185273439436399604== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Warner, =20 Thanks for your detailed reply. =20 I forgot to mention that I do get a display of sorts, it looks like this: htt= ps://robs-old-computers.com/wp-content/uploads/2024/11/img_20241127_222706.jpg =20 I had assumed that this would mean the DC011 and DC012 were OK, otherwise it = wouldn=E2=80=99t seem possible for it to be able to display this message. Do = you still think it could be one of those two chips? =20 Thanks =20 Rob =20 From: Warner Losh =20 Sent: 09 December 2024 01:01 To: rob(a)jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts Cc: Rob Jarratt Subject: Re: [cctalk] Rainbow Z80 firmware =20 =20 =20 On Sun, Dec 8, 2024 at 12:39=E2=80=AFPM Rob Jarratt via cctalk > wrote: Hello everyone, I am working on a Rainbow 100A which is showing a diagnostic code on the lights at the back of 0110101. This is supposed to be Message 1 "Main Board Video". =20 OK That's likely a failure of the main VT100 chips that's are buried inside t= he Rainbow. =20 I have disassembled the 8088 firmware and checked address traces with a logic analyser and my suspicion is that actually this is something to do with the interaction with the Z80 because it is reading a status from the shared memory and then using that to set the status lights. =20 The video controller is connected directly to the 8088 side of the world. The= Z80 has to make calls to the 8088 to output to the screen. =20 I have been unable so far to work out where in the ROMs the Z80 code lives or where in the 8088 code it transfers it to the shared memory to allow the Z80 to run. =20 https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/8086_DISA= SSEMBLY_from_23-020e5-00 has disassembled 8088 code. https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/Z80_DISAS= SEMBLY_from_23-020e5-00 has the Z80 code (so both are in the ROMs). This may be the 100B code, but th= e two models are quite similar in this detail. =20 You can look through the 8086 assembly, I think to find where this error code= is generated. I looked at this stuff ages ago when I was getting Venix to run under emulati= on, but that was 5 years ago now I think. =20 Can anyone tell me where the Z80 firmware is in the ROMs? And does anyone have any insight into the above error or have details of the interaction between the Z80 and the 8088? The Technical Manual only goes so far unfortunately. =20 You might look at the mame emulation of the Rainbow. It does a decent job of = things. =20 There's a 2k shared memory area between the Z80 and 8088 that they use to do = I/O. The floppy is connected to the Z80, while the hard disk, keyboard and video a= re connected to the 8088. The 8088 loads the Z80 code by writing a magic value that 'flips= ' the mapping. It then writes to the 'flipped' RAM and flips things back and restarts the Z8= 0. =20 bitsavers also has the schematics for both the 100A and 100B models. You real= ly need them because they have the only documentation (or best documentation) for the I/O = ports that are mapped. There is some registers documented in the TRM, but it's incomplete in= some details at least if you are trying to write an emulator. =20 It's a bit of a shame that the MAME efforts have run into personality issues = that I'm not close enough to to positively affect. As such, all rainbow efforts have stalled for= a couple of years now and the port uses older interfaces that have proven resistant to recoding in = the new APIs. =20 Warner --===============4185273439436399604==-- From epekstrom@gmail.com Mon Dec 9 13:02:30 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: Philips P2000C disk format Date: Mon, 09 Dec 2024 08:02:10 -0500 Message-ID: In-Reply-To: <031c01db49ba$267db980$73792c80$@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0251460995730550518==" --===============0251460995730550518== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit This one seems to have information on the diskette layout starting on page 230: https://electrickery.nl/comp/p2000c/doc/P2000C-SystemRefServiceManual.pdf -Peter On Sun, Dec 8, 2024 at 4:52 PM Rik Bos via cctalk wrote: > Tony, > > Maybe this software catalogue will help you: > https://electrickery.nl/comp/p2000c/doc/PTC_Katalogus.pdf > > -Rik > > -----Oorspronkelijk bericht----- > Van: Tony Duell via cctalk > Verzonden: zondag 8 december 2024 19:55 > Aan: General Discussion: On-Topic and Off-Topic Posts < > cctalk(a)classiccmp.org> > CC: Tony Duell > Onderwerp: [cctalk] Philips P2000C disk format > > The quick version : Does anyone know the exact physical and logical disk > format used by CP/M on the Philips P2000C portable computer? > > The long version with explanations : > > I am having reasonable success transfering files to/from disk images for > my Osborne 1A (using cpmtools) and IBM5155 (MS-DOS, of course using > editdisk). And I've even got the Greaseweazle to transfer those images > to/from real floppies. The Greaseweazle still annoys me in that I know it's > capable of a lot more if only I could work out how to do it, but at least > it does something useful > > [The less said about floppy disks shedding oxide and/or suffering from > 'sticky shed' the better. I'm spending far too much time dismantling and > cleaning drives....] > > Any, I'd like to do the same for another of my machines, a Philips P2000C > cp/m 'portable'. My machine is the version with 2 internal 40 cylinder > single head drives (about 160K each, MFM) but I can also plug in an > external 80 cylinder double head drive to handle this machine's other > native format (about 640K). > > Unfortunately, this machine is not common, and neither cpmtools nor the > greaseweazle software has the formats predefined. I could add them myself > -- if I knew what they were. Things like #sectors/track, sector size, > #system tracks, skew, etc. > > It's not obviously given in any of the manuals I have, so does anyone know > it before I try to work it out. > > Alternatively there are rumours that the P2000C could read/write at least > one more common cp/m disk type. The hardware should be capable of it, sure. > Doe anyone know if software to do something like this exists anywhere for > the P2000C. I can't find it on any of the obvious sites > > -tony > > --===============0251460995730550518==-- From ard.p850ug1@gmail.com Mon Dec 9 13:44:10 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Philips P2000C disk format Date: Mon, 09 Dec 2024 13:43:51 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8072015429175669226==" --===============8072015429175669226== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Dec 9, 2024 at 1:02 PM Peter Ekstrom via cctalk wrote: > > This one seems to have information on the diskette layout starting on page > 230: > > https://electrickery.nl/comp/p2000c/doc/P2000C-SystemRefServiceManual.pdf Unofortunately that doesn't go far enough. It doesn't give the number of sectors/track or their size (I think it's 16 sectors, each of 256 bytes) It also doesn't give the 'skew. Under CP/M the sectors may not be used in numerical order, maybe it uses every third one until all are used then goes on to the next track. This is something that is very hard to determine by lookng at the disk but is obviously essential to know to make use of the diak image. -tony --===============8072015429175669226==-- From epekstrom@gmail.com Mon Dec 9 14:27:12 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: Philips P2000C disk format Date: Mon, 09 Dec 2024 09:26:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5882656818581204250==" --===============5882656818581204250== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Out of curiosity I downloaded the P2000C system disk images from Dave Dunfield's archive and looked through them in Linux using the strings command. Turns out, in the 4th disk image (P2000_4.IMD) there appears to be the assembler source for a format command that can handle multiple diskette formats. There are table entries for the P2000C's 160KB format as well. I haven't had time to look through it all and figure out all the values but perhaps that can be a good starting point? As an example, a couple of snippets of what I found: ;============================================== ;THIS FILE HAS THE DISK TABLES FOR UTILITY ;THE TABLE HAS FOLLOWING STRUCTURE: ;BYTES 00-01 LENGTH OF TH B 0E5H ;FORMAT INFO DEFB 10H ; OF SECTORS ON SIDE-0 DEFB 1,02H,03H,04H,05H,06H,07H,08H ;SECTORS IN TRACK FORMAT DEFB 9,0AH,0BH,0CH,0DH,0EH,0FH,10H DEFB 10H ; OF SECTORS ON SIDE-1 DEFB 1,02H,03H,04H,05H,06H,07H,08H ;SECTORS IN TRACK FORMAT DEF ;DESCRIPTOR FOR 2000C 160K DISK DT2: DEFB DT3-DT2 ;TABLE LENGTH DEFT 'P2000C 160K - CP/M' ;NAME FORMATTING INFO (E5, OR F6) ; 1 BYTE FOR THE OF SECTORS ON SIDE-0 ; BYTES FOR THE SECTOR NUMBERS ON SIDE-0 ; 1 BYTE FOR THE OF SECTORS ON SIDE-1 ; BYTES FOR THE SECTOR NUMBERS ON SIDE-1 ; SYSTEM IDENTIFIER 1=CP/M ; 3=MSDOS ; IF MSDOS: 1 DEFB 81H ;FLAG FOR SINGLE SIDED DEFB 28H ;NUMBER OF TRACKS DEFB 1 ;TR MULTIPLIER ACTIVE SRL H RET ;TRANSL SUBR FOR BIOS DEFB 0 ;TO MAKE UP 4 BYTES DEFB 1 ;1 SUBTABLE DT21: DEFB DT22-DT21 ;LENGTH OF SUBTABLE DEFT 'CP/M' ;SUBTABLE NAME DEFB 1 ;SECT LGTH = 256 BYTES DEFB 0E5H ;FORMAT INFO DEFB 10H ; OF SECTORS ON SIDE-0 DEFB 1,02H,03H,04H,05H,06H,07H,08H ;SECTORS IN TRACK FORMAT DEFB 9,0AH,0BH,0CH,0DH,0EH,0FH,10H DEFB 0 ; OF SECTORS ON SIDE-1 DEFB 1 ;FOR CP/M DEFB 20H,0, 7,08,11,12,15,16 DEFB 19,20,23,24,27,28,31,32 On Mon, Dec 9, 2024 at 8:44 AM Tony Duell wrote: > On Mon, Dec 9, 2024 at 1:02 PM Peter Ekstrom via cctalk > wrote: > > > > This one seems to have information on the diskette layout starting on > page > > 230: > > > > > https://electrickery.nl/comp/p2000c/doc/P2000C-SystemRefServiceManual.pdf > > Unofortunately that doesn't go far enough. It doesn't give the number > of sectors/track or their size (I think it's 16 sectors, each of 256 > bytes) > > It also doesn't give the 'skew. Under CP/M the sectors may not be used > in numerical order, maybe it uses every third one until all are used > then goes on to the next track. This is something that is very hard to > determine by lookng at the disk but is obviously essential to know to > make use of the diak image. > > -tony > --===============5882656818581204250==-- From imp@bsdimp.com Mon Dec 9 18:34:59 2024 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Rainbow Z80 firmware Date: Mon, 09 Dec 2024 11:34:40 -0700 Message-ID: In-Reply-To: <006f01db4a07$aec58b90$0c50a2b0$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7089128372488171348==" --===============7089128372488171348== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 8, 2024 at 11:58=E2=80=AFPM Rob Jarratt wrote: > Hello Warner, > > > > Thanks for your detailed reply. > > > > I forgot to mention that I do get a display of sorts, it looks like this: > https://robs-old-computers.com/wp-content/uploads/2024/11/img_20241127_2227= 06.jpg > > > > I had assumed that this would mean the DC011 and DC012 were OK, otherwise > it wouldn=E2=80=99t seem possible for it to be able to display this message= . Do you > still think it could be one of those two chips? > Given that the video attribute for the S is messed up and the T has both the video attribute and the character messed up, and the anomaly runs the full height of the screen, I'd say something is wrong with the character generation or the video ram that it uses (which I think is dual ported to the 8088). So maybe not the chips, per se, but there's clearly something wonky in that area. I've not read through the 8088 BIOS in a while to see what tests it does to come to this conclusion, however. However, you originally said 011 0101. The upper 3 bits of the diag code is controlled by the Z80. I think this is Z80 controlled parts of the fail code... but I'm not entirely sure, but that's what I get from reading the 100B schematic at https://bitsavers.org/pdf/dec/rainbow/MP01722_PC100-B_Rainbow_Schematic_Jul84= .pdf (The SH8 ZDx data is routed to E28 on sheet 10, so this may also be the data when E28 is latched on sheet 10 when SH8 ZDIAG WR L is active). Warner > Thanks > > > > Rob > > > > *From:* Warner Losh > *Sent:* 09 December 2024 01:01 > *To:* rob(a)jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts > > *Cc:* Rob Jarratt > *Subject:* Re: [cctalk] Rainbow Z80 firmware > > > > > > > > On Sun, Dec 8, 2024 at 12:39=E2=80=AFPM Rob Jarratt via cctalk < > cctalk(a)classiccmp.org> wrote: > > Hello everyone, > > > > I am working on a Rainbow 100A which is showing a diagnostic code on the > lights at the back of 0110101. This is supposed to be Message 1 "Main Board > Video". > > > > OK That's likely a failure of the main VT100 chips that's are > buried inside the Rainbow. > > > > I have disassembled the 8088 firmware and checked address traces with a > logic analyser and my suspicion is that actually this is something to do > with the interaction with the Z80 because it is reading a status from the > shared memory and then using that to set the status lights. > > > > The video controller is connected directly to the 8088 side of the world. > The Z80 > > has to make calls to the 8088 to output to the screen. > > > > I have been unable so far to work out where in the ROMs the Z80 code lives > or where in the 8088 code it transfers it to the shared memory to allow the > Z80 to run. > > > > > https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/8086_DI= SASSEMBLY_from_23-020e5-00 > > has disassembled 8088 code. > > > https://github.com/shattered/retro-bios/blob/master/dec-rainbow100b/Z80_DIS= ASSEMBLY_from_23-020e5-00 > > has the Z80 code (so both are in the ROMs). This may be the 100B code, but > the two > > models are quite similar in this detail. > > > > You can look through the 8086 assembly, I think to find where this error > code is generated. > > I looked at this stuff ages ago when I was getting Venix to run under > emulation, but that was 5 > > years ago now I think. > > > > Can anyone tell me where the Z80 firmware is in the ROMs? And does anyone > have any insight into the above error or have details of the interaction > between the Z80 and the 8088? The Technical Manual only goes so far > unfortunately. > > > > You might look at the mame emulation of the Rainbow. It does a decent job > of things. > > > > There's a 2k shared memory area between the Z80 and 8088 that they use to > do I/O. > > The floppy is connected to the Z80, while the hard disk, keyboard and > video are connected > > to the 8088. The 8088 loads the Z80 code by writing a magic value that > 'flips' the mapping. > > It then writes to the 'flipped' RAM and flips things back and restarts the > Z80. > > > > bitsavers also has the schematics for both the 100A and 100B models. You > really need them > > because they have the only documentation (or best documentation) for the > I/O ports that are > > mapped. There is some registers documented in the TRM, but it's incomplete > in some details > > at least if you are trying to write an emulator. > > > > It's a bit of a shame that the MAME efforts have run into personality > issues that I'm not close > > enough to to positively affect. As such, all rainbow efforts have stalled > for a couple of years now > > and the port uses older interfaces that have proven resistant to recoding > in the new APIs. > > > > Warner > --===============7089128372488171348==-- From cisin@xenosoft.com Mon Dec 9 21:09:33 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Philips P2000C disk format Date: Mon, 09 Dec 2024 13:09:28 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5837579194999082209==" --===============5837579194999082209== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Teaching granny to suck eggs: STAT DSK: on a running CP/M machine gives some information, including the number of reserve tracks, and the records per block, which is useful when parsing the DIRectory entries. The "sectors per track" is actually 128 byte records, not the physical sectors. Although if it has an odd number of physical sectors per track, that could help. On Mon, 9 Dec 2024, Tony Duell via cctalk wrote: > Unofortunately that doesn't go far enough. It doesn't give the number > of sectors/track or their size (I think it's 16 sectors, each of 256 > bytes) For bytes per sector, and sectors per track, write some trivial code. Or, on the PC, you could use the 765 "read ID" command. or, on a machine with WD controller, try a track read. OR write some trivial code with Int1Eh and Int13h to read a 256 byte sector. (NOT one of the ones in the reserve tracks; those sometimes have a different format) > It also doesn't give the 'skew. Under CP/M the sectors may not be used > in numerical order, maybe it uses every third one until all are used > then goes on to the next track. This is something that is very hard to > determine by lookng at the disk but is obviously essential to know to > make use of the diak image. Statements found on the web can be misleading, or even wrong. I have seen "skew of 3" used to mean every third sector, skip three sectors between one and the next, or that the track is broken into three passes. If you have the WD "track read", you can look at it, looking for text, source code, or other recognizable content that extends past the end of a sector, and look for which sector it continues in. Otherwise, you need to write, or find, a sector editor that can be patched for different sector sizes. For example, I patched Roxton Baaker's "TRAKCESS" on the TRS80. And the first function that I implemented/completed in the never completed XenoXap was displaying sectors of various sizes. I kept adding extravagant new functions, and never finished more than I needed at the time of the functions (cf Randy Cook's "TRS-DOS" and "VTOS") Use sectors past the reserved tracks, as some formats have a different format on the reservec tracks. Then you can look for the "half a worm", to try to find what sequence the sectors are. Watch out for any "deleted files" whose content is still on the disk. They could work, or they could tend to be misleading. ("Which of these two almost identical sectors is the real next one, and which is residual content from previous edits") Disks that have been used in one format, and then re-formatted in another format can be misleading. (a disk with 256 byte sectors on the first side and 512 byte sectors on the second side, is probably a re-used disk) Text, even the messages in a program, and/or source code work well. If you really know your machine language, you can look for the first byte(s) of a multi-byte instruction. I never got skilled at that. For double sided disks, ANOTHER issue that will require looking at some sectors is how the disk handles using the second side. You will need a disk that is over half full. Over half full, but not completely full is by far the easiest. Some formats fill the first side, and then start at track 0 of the second side going up. Some formats fill the first side, and then start after the reserve tracks of the second side, and go up. Some formats fill the first side, and then start at track 79, 39, or 34 of the second side going down. Some formats fill the first track of the first side, and then have a track on the second side. Some formats treat both track of each cylinder as if it were one large track. Skew can bridge both sides of the cylinder. Some formats will come up with even weirder approaches. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============5837579194999082209==-- From gianluca.bonetti@gmail.com Mon Dec 9 21:25:54 2024 From: Gianluca Bonetti To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Thu, 05 Dec 2024 23:12:56 +0000 Message-ID: In-Reply-To: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7387343529426002679==" --===============7387343529426002679== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Mike Isn't ncurses doing what you look for? Cheers Gianluca On Thu, 5 Dec 2024 at 23:01, Mike Katz via cctalk wrote: > I am looking for a C library that implements a crude windowing system on > a VT-100 or compatible terminal via the serial port. I've seen such > things before but not recently. > > I will be running this on bare metal (no operating system). Preferably > the package would use the regional scrolling capabilities of the VT-100 > for faster screen updates. > > I might be able to get Txwindows to work but I am looking for something > a bit simpler? > > Any ideas would be greatly appreciated. > > Thank you.... > > Mike > --===============7387343529426002679==-- From barto@kdbarto.org Mon Dec 9 21:26:07 2024 From: David Barto To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Fri, 06 Dec 2024 00:32:33 +0000 Message-ID: <986711F4-7F40-4EFB-85E6-076BA519FA50@kdbarto.org> In-Reply-To: <6a13586f-202d-4af5-9d20-59e0fe1b1256@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1189590415849019619==" --===============1189590415849019619== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Dec 5, 2024, at 2:43=E2=80=AFPM, Mike Katz via cctalk wrote: >=20 > I am looking for a C library that implements a crude windowing system on a = VT-100 or compatible terminal via the serial port. I've seen such things bef= ore but not recently. >=20 > I will be running this on bare metal (no operating system). Preferably the = package would use the regional scrolling capabilities of the VT-100 for faste= r screen updates. >=20 > I might be able to get Txwindows to work but I am looking for something a b= it simpler? >=20 > Any ideas would be greatly appreciated. >=20 > Thank you.... >=20 > Mike Screen(1) https://manpages.org/screen could do what you are thinking of. David A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? David Barto barto(a)kdbarto.org --===============1189590415849019619==-- From brain@jbrain.com Tue Dec 10 01:23:15 2024 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Mon, 09 Dec 2024 19:18:07 -0600 Message-ID: <4e39dafb-6dc4-4efd-adca-11ac9e5c6b39@jbrain.com> In-Reply-To: <986711F4-7F40-4EFB-85E6-076BA519FA50@kdbarto.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5023897706276569419==" --===============5023897706276569419== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 12/5/2024 6:32 PM, David Barto via cctalk wrote: I think the operative sentence in the original request is: >> I will be running this on bare metal (no operating system). Preferably the= package would use the regional scrolling capabilities of the VT-100 for fast= er screen updates. screen and ncurses I believe expect a POSIX subsystem to operate. Jim --=20 Jim Brain brain(a)jbrain.com www.jbrain.com --===============5023897706276569419==-- From bfranchuk@jetnet.ab.ca Tue Dec 10 02:03:10 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Mon, 09 Dec 2024 19:03:00 -0700 Message-ID: <94e939ca-52e3-445a-a386-b026e28becf1@jetnet.ab.ca> In-Reply-To: <4e39dafb-6dc4-4efd-adca-11ac9e5c6b39@jbrain.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6183666333393068600==" --===============6183666333393068600== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit What about porting the old share-ware window libraries for dos? --===============6183666333393068600==-- From wayne.sudol@hotmail.com Tue Dec 10 02:29:27 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 02:29:20 +0000 Message-ID: In-Reply-To: <94e939ca-52e3-445a-a386-b026e28becf1@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9004252931581778755==" --===============9004252931581778755== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Mike, is the system really without an operating system? So no cursor control at all? Sent from my iPhone > On Dec 9, 2024, at 18:03, ben via cctalk wrote: > > What about porting the old share-ware window libraries for dos? > > --===============9004252931581778755==-- From henry.r.bent@gmail.com Tue Dec 10 02:40:58 2024 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Mon, 09 Dec 2024 21:40:43 -0500 Message-ID: In-Reply-To: <80464a54-d1b8-4ea8-97d3-4eea4b20d502@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7881806129029424349==" --===============7881806129029424349== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk wrote: > Thank you. > > Screen is a linux utility. I am writing this on a bare metal (no > operating system) ESP32 dev board. > > Right now the program is text menu driven. I would like to enhance it > with textual windows. > > The Txwindows package is perfect but over kill and will need some > hacking to work in my environment and it doesn't support the VT-100's > region scrolling so screen updates might be slow. > What might be helpful is if you could be more specific about what it is you're trying to achieve. Do you want arbitrarily sized, overlapping windows or do you just want the screen divided up into discrete segments? -Henry --===============7881806129029424349==-- From ard.p850ug1@gmail.com Tue Dec 10 04:23:25 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Philips P2000C disk format Date: Tue, 10 Dec 2024 04:23:09 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5071883518847491786==" --===============5071883518847491786== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Dec 9, 2024 at 7:52 PM Peter Ekstrom via cctalk wrote: > > Out of curiosity I downloaded the P2000C system disk images from Dave > Dunfield's archive and looked through them in Linux using the strings > command. > Turns out, in the 4th disk image (P2000_4.IMD) there appears to be the > assembler source for a format command that can handle multiple diskette > formats. > There are table entries for the P2000C's 160KB format as well. I haven't > had time to look through it all and figure out all the values but perhaps > that can be > a good starting point? Interesting, I will take a look. -tony --===============5071883518847491786==-- From henry.r.bent@gmail.com Tue Dec 10 05:17:38 2024 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 00:17:22 -0500 Message-ID: In-Reply-To: <14b4c079-05a8-4eb5-bee2-cc7ebaeada51@email.android.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2338653687494075843==" --===============2338653687494075843== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit If this were my project, I would start by getting newlib going and then seeing if I could use that to run an older (presumably more simple, with fewer requirements) version of screen. -Henry On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: > Overlapping would be amazing, different screen quadrants at a minimum. I > am going to try to port Txwindows as that is the only package I could find > > On Dec 9, 2024 8:40 PM, Henry Bent wrote: > > On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk > wrote: > > Thank you. > > Screen is a linux utility. I am writing this on a bare metal (no > operating system) ESP32 dev board. > > Right now the program is text menu driven. I would like to enhance it > with textual windows. > > The Txwindows package is perfect but over kill and will need some > hacking to work in my environment and it doesn't support the VT-100's > region scrolling so screen updates might be slow. > > > What might be helpful is if you could be more specific about what it is > you're trying to achieve. Do you want arbitrarily sized, overlapping > windows or do you just want the screen divided up into discrete segments? > > -Henry > > > --===============2338653687494075843==-- From ccth6600@gmail.com Tue Dec 10 07:14:01 2024 From: Tom Hunter To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 15:13:46 +0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7993858177474948223==" --===============7993858177474948223== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If this were my project, I would read the VT100 manual and design and implement a serial driver and basic text window library from scratch running on the bare hardware. It wouldn't be more than 1000 lines of C, more likely something like 500 lines. I am a retired embedded software engineer and did these things for a living. I would budget 2 to 3 days including reading the manual. Tom On Tue, 10 Dec 2024, 1:27=E2=80=AFpm Henry Bent via cctalk, wrote: > If this were my project, I would start by getting newlib going and then > seeing if I could use that to run an older (presumably more simple, with > fewer requirements) version of screen. > > -Henry > > On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: > > > Overlapping would be amazing, different screen quadrants at a minimum. I > > am going to try to port Txwindows as that is the only package I could > find > > > > On Dec 9, 2024 8:40 PM, Henry Bent wrote: > > > > On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk > > > wrote: > > > > Thank you. > > > > Screen is a linux utility. I am writing this on a bare metal (no > > operating system) ESP32 dev board. > > > > Right now the program is text menu driven. I would like to enhance it > > with textual windows. > > > > The Txwindows package is perfect but over kill and will need some > > hacking to work in my environment and it doesn't support the VT-100's > > region scrolling so screen updates might be slow. > > > > > > What might be helpful is if you could be more specific about what it is > > you're trying to achieve. Do you want arbitrarily sized, overlapping > > windows or do you just want the screen divided up into discrete segments? > > > > -Henry > > > > > > > --===============7993858177474948223==-- From bfranchuk@jetnet.ab.ca Tue Dec 10 08:05:54 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 01:05:45 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0075063128050800991==" --===============0075063128050800991== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-12-10 12:13 a.m., Tom Hunter via cctalk wrote: > If this were my project, I would read the VT100 manual and design and > implement a serial driver and basic text window library from scratch > running on the bare hardware. It wouldn't be more than 1000 lines of C, > more likely something like 500 lines. I am a retired embedded > software engineer and did these things for a living. I would budget 2 to 3 > days including reading the manual. > > Tom How may days using a assembler? How many days to find the manual? How many days to write a simple driver? Joking aside, I wonder how bare metal the original project is? Knowing what hardware is rather important, just to know what will fit. Sounds like a OS is needed, not a just screen display software. I am working on a bare metal machine here, just one step up from toggling the bootstrap loader from the front panel. Once was ample. Any one know the fine details of bit-banging a micro SD card, mostly the reset sequence and where to sample or set CS_ , MSO , MSI and clock. The boiler plate code is there, I just need Initialize data, write 80 clocks, read byte, write byte routines, to reset the SD card. Ben. Another midnight snack a 1 AM. --===============0075063128050800991==-- From bitwiz@12bitsbest.com Tue Dec 10 20:29:56 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 14:29:47 -0600 Message-ID: <1a8a0ca6-c52d-4264-9e55-e033d1120d54@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3783989153557112579==" --===============3783989153557112579== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Most of the functionality of Newlib is either in the GCC standard libraries or, in this case, built into the Arduino environment. I really dislike the arduino environment but the base code that I am using is written in it. I also almost never use printf/scanf and its derivatives in embedded code because printf/scanf are among the biggest space hogs in the C library.  I have written my own set of text input and output routines that replaces all of the printf/scanf functionality that I need in an embedded system. Thank you for your advice.  I will look into screen, if I an find it.           Mike On 12/9/2024 11:17 PM, Henry Bent wrote: > If this were my project, I would start by getting newlib going and > then seeing if I could use that to run an older (presumably more > simple, with fewer requirements) version of screen. > > -Henry > > On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: > > Overlapping would be amazing, different screen quadrants at a > minimum.  I am going to try to port Txwindows as that is the only > package I could find > > On Dec 9, 2024 8:40 PM, Henry Bent wrote: > > On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk > wrote: > > Thank you. > > Screen is a linux utility.  I am writing this on a bare > metal (no > operating system) ESP32 dev board. > > Right now the program is text menu driven.  I would like > to enhance it > with textual windows. > > The Txwindows package is perfect but over kill and will > need some > hacking to work in my environment and it doesn't support > the VT-100's > region scrolling so screen updates might be slow. > > > What might be helpful is if you could be more specific about > what it is you're trying to achieve.  Do you want arbitrarily > sized, overlapping windows or do you just want the screen > divided up into discrete segments? > > -Henry > > --===============3783989153557112579==-- From henry.r.bent@gmail.com Tue Dec 10 20:42:32 2024 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 15:42:13 -0500 Message-ID: In-Reply-To: <1a8a0ca6-c52d-4264-9e55-e033d1120d54@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6601362817323903002==" --===============6601362817323903002== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit https://ftp.gnu.org/gnu/screen/ Looks like version 3.9 was when they added split-screen support. -Henry On Tue, 10 Dec 2024 at 15:29, Mike Katz wrote: > Most of the functionality of Newlib is either in the GCC standard > libraries or, in this case, built into the Arduino environment. > > I really dislike the arduino environment but the base code that I am using > is written in it. > > I also almost never use printf/scanf and its derivatives in embedded code > because printf/scanf are among the biggest space hogs in the C library. I > have written my own set of text input and output routines that replaces all > of the printf/scanf functionality that I need in an embedded system. > > Thank you for your advice. I will look into screen, if I an find it. > > Mike > > > On 12/9/2024 11:17 PM, Henry Bent wrote: > > If this were my project, I would start by getting newlib going and then > seeing if I could use that to run an older (presumably more simple, with > fewer requirements) version of screen. > > -Henry > > On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: > >> Overlapping would be amazing, different screen quadrants at a minimum. I >> am going to try to port Txwindows as that is the only package I could find >> >> On Dec 9, 2024 8:40 PM, Henry Bent wrote: >> >> On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk >> wrote: >> >> Thank you. >> >> Screen is a linux utility. I am writing this on a bare metal (no >> operating system) ESP32 dev board. >> >> Right now the program is text menu driven. I would like to enhance it >> with textual windows. >> >> The Txwindows package is perfect but over kill and will need some >> hacking to work in my environment and it doesn't support the VT-100's >> region scrolling so screen updates might be slow. >> >> >> What might be helpful is if you could be more specific about what it is >> you're trying to achieve. Do you want arbitrarily sized, overlapping >> windows or do you just want the screen divided up into discrete segments? >> >> -Henry >> >> >> > --===============6601362817323903002==-- From bitwiz@12bitsbest.com Tue Dec 10 23:10:44 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Tue, 10 Dec 2024 14:54:30 -0600 Message-ID: <6a4c27d9-fd73-477d-9000-596c7438f1f5@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6668248599519534392==" --===============6668248599519534392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Screen is primarily for multiple shells on a single VT-100 with independent tasks/shells running in each window. Since I'm not running an operating system and I really don't need multiple tasks this doesn't look like it will meet my needs. TxWindows looks the best of what I have found.  I will have to try their Linux version and see if i can pull out all of the operating system stuff so that it runs with nothing more than a serial port driver. https://ecsoft2.org/txwindows-library Thank you... On 12/10/2024 2:42 PM, Henry Bent wrote: > https://ftp.gnu.org/gnu/screen/ > > Looks like version 3.9 was when they added split-screen support. > > -Henry > > On Tue, 10 Dec 2024 at 15:29, Mike Katz wrote: > > Most of the functionality of Newlib is either in the GCC standard > libraries or, in this case, built into the Arduino environment. > > I really dislike the arduino environment but the base code that I > am using is written in it. > > I also almost never use printf/scanf and its derivatives in > embedded code because printf/scanf are among the biggest space > hogs in the C library.  I have written my own set of text input > and output routines that replaces all of the printf/scanf > functionality that I need in an embedded system. > > Thank you for your advice.  I will look into screen, if I an find it. > >           Mike > > > On 12/9/2024 11:17 PM, Henry Bent wrote: >> If this were my project, I would start by getting newlib going >> and then seeing if I could use that to run an older (presumably >> more simple, with fewer requirements) version of screen. >> >> -Henry >> >> On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: >> >> Overlapping would be amazing, different screen quadrants at a >> minimum.  I am going to try to port Txwindows as that is the >> only package I could find >> >> On Dec 9, 2024 8:40 PM, Henry Bent >> wrote: >> >> On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk >> wrote: >> >> Thank you. >> >> Screen is a linux utility.  I am writing this on a >> bare metal (no >> operating system) ESP32 dev board. >> >> Right now the program is text menu driven.  I would >> like to enhance it >> with textual windows. >> >> The Txwindows package is perfect but over kill and >> will need some >> hacking to work in my environment and it doesn't >> support the VT-100's >> region scrolling so screen updates might be slow. >> >> >> What might be helpful is if you could be more specific >> about what it is you're trying to achieve.  Do you want >> arbitrarily sized, overlapping windows or do you just >> want the screen divided up into discrete segments? >> >> -Henry >> >> > --===============6668248599519534392==-- From cctalk@emailtoilet.com Wed Dec 11 00:00:06 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Old mainframe humor Date: Tue, 10 Dec 2024 23:59:59 +0000 Message-ID: <173387519915.1294.1544252031966632900@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1101591881854319850==" --===============1101591881854319850== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit NEAT/3 instructions www.myimagecollection.com/webdocs/neat3.pdf Misc instructions www.myimagecollection.com/webdocs/pl-o.pdf Misc Assembler www.myimagecollection.com/webdocs/miscassembler.pdf IBM beginnings www.myimagecollection.com/webdocs/beginning.pdf New IBM OS www.myimagecollection.com/webdocs/newibmos.pdf --===============1101591881854319850==-- From cisin@xenosoft.com Wed Dec 11 00:22:33 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 16:22:28 -0800 Message-ID: In-Reply-To: <173387519915.1294.1544252031966632900@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7678917541206969351==" --===============7678917541206969351== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 10 Dec 2024, Donald Whittemore via cctalk wrote: > NEAT/3 instructions > www.myimagecollection.com/webdocs/neat3.pdf > Misc instructions > www.myimagecollection.com/webdocs/pl-o.pdf > Misc Assembler > www.myimagecollection.com/webdocs/miscassembler.pdf > IBM beginnings > www.myimagecollection.com/webdocs/beginning.pdf > New IBM OS > www.myimagecollection.com/webdocs/newibmos.pdf Thank you for the info on undocumented instructions. But, to what extent can we count on second-source and after-market manufacturers to implement them in compatable forms? -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============7678917541206969351==-- From cctalk@emailtoilet.com Wed Dec 11 00:32:34 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 00:32:31 +0000 Message-ID: <173387715115.1294.4039200769876066512@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3269066627522729516==" --===============3269066627522729516== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Been waiting 45 years for the new IBM OS. Not holding my breath. :) --===============3269066627522729516==-- From henry.r.bent@gmail.com Wed Dec 11 01:28:17 2024 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 20:28:00 -0500 Message-ID: In-Reply-To: <173387519915.1294.1544252031966632900@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5032727938510656795==" --===============5032727938510656795== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 10 Dec 2024 at 19:17, Donald Whittemore via cctalk < cctalk(a)classiccmp.org> wrote: > NEAT/3 instructions > www.myimagecollection.com/webdocs/neat3.pdf > > Misc instructions > www.myimagecollection.com/webdocs/pl-o.pdf > > Misc Assembler > www.myimagecollection.com/webdocs/miscassembler.pdf > > IBM beginnings > www.myimagecollection.com/webdocs/beginning.pdf > > New IBM OS > www.myimagecollection.com/webdocs/newibmos.pdf Do you have approximate dates for any of these? The fictional 360 instructions seem to be quite similar between iterations, and I'm curious where they initially came from. If an original source were to be found, it would seem to be the origin of the phrase "halt and catch fire." -Henry --===============5032727938510656795==-- From rickb@bensene.com Wed Dec 11 01:30:07 2024 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 01:21:14 +0000 Message-ID: <219a6681f5014f84873fa4c0b1d0a218@bensene.com> In-Reply-To: <173387715115.1294.4039200769876066512@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5028794861506259266==" --===============5028794861506259266== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Been waiting 45 years for the new IBM OS. Not holding my breath. :) Ahhh...but are you sure we're all not already running as tasks under OS/VR? :-) -Rick --===============5028794861506259266==-- From cctalk@emailtoilet.com Wed Dec 11 01:35:36 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 01:35:32 +0000 Message-ID: <173388093279.1294.14963525299739465031@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1973922522336565618==" --===============1973922522336565618== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Has to be the mid to late 80s. The new OS paper is 1989. I wrote it. :) --===============1973922522336565618==-- From ataylor@subgeniuskitty.com Wed Dec 11 01:39:49 2024 From: Aaron Taylor To: cctalk@classiccmp.org Subject: [cctalk] Sequent RAM identification help Date: Tue, 10 Dec 2024 17:32:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5398571886844971109==" --===============5398571886844971109== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, While cleaning my garage I ran across 100+ sticks of RAM that I can't identif= y. Does anyone recognize these? Are they of use to anyone? https://imgur.com/a/xUnBuEg Note that there are two types of RAM in the photos and they have different keying notches in the middle of the connector. One has a PCB copyright of 1997 and the other is 1999. Both are marked "Sequent Computer Systems", and are buffered, ECC, 256 MB, 50 ns, EDO RAM. Aaron --===============5398571886844971109==-- From bitwiz@12bitsbest.com Wed Dec 11 01:43:06 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 19:42:57 -0600 Message-ID: <411100b3-1626-4ad8-922f-f1ca32abe74b@12bitsbest.com> In-Reply-To: <219a6681f5014f84873fa4c0b1d0a218@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5582453024894471106==" --===============5582453024894471106== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Or, more importantly, are we all living in a VR? What is reality? On 12/10/2024 7:21 PM, Rick Bensene via cctalk wrote: > >> Been waiting 45 years for the new IBM OS. Not holding my breath. :) > > > Ahhh...but are you sure we're all not already running as tasks under OS/VR? > > > > :-) > > > > -Rick --===============5582453024894471106==-- From henry.r.bent@gmail.com Wed Dec 11 01:45:14 2024 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 20:44:59 -0500 Message-ID: In-Reply-To: <173388093279.1294.14963525299739465031@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1975933784460312987==" --===============1975933784460312987== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, 10 Dec 2024 at 20:35, Donald Whittemore via cctalk < cctalk(a)classiccmp.org> wrote: > Has to be the mid to late 80s. The new OS paper is 1989. I wrote it. :) > Interesting, I would have guessed older. Wikipedia links to Creative Computing from April 1980 which has a list of them ( https://archive.org/details/creativecomputing-1980-04/page/n205/mode/2up?view= =3Dtheater ) but I doubt that's the real origin. -Henry --===============1975933784460312987==-- From spectre@floodgap.com Wed Dec 11 01:56:20 2024 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 17:51:00 -0800 Message-ID: In-Reply-To: <411100b3-1626-4ad8-922f-f1ca32abe74b@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8230702481583726519==" --===============8230702481583726519== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Or, more importantly, are we all living in a VR? "Knowledge for the peop...pupil, he said. Give them a light and they'll follow it anywhere. We think that is a fair and a wise guide, rule, to be guided by = ..." > What is reality? --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- The whippings shall continue until morale improves. ----------------------= -- --===============8230702481583726519==-- From bitwiz@12bitsbest.com Wed Dec 11 03:28:15 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 18:31:19 -0600 Message-ID: <51a99d60-31b4-439e-8b59-04e80a33d6f7@12bitsbest.com> In-Reply-To: <173387519915.1294.1544252031966632900@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8816768467401257944==" --===============8816768467401257944== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I believe in the late 70's or early 80's Byte magazine did an April Fool's issue that had many of those instructions but other than Halt and Catch Fire I think the best one was: EXOP    Execute Operator  (Use of this instruction has been deprecated due to shrinking programmer pool) /The fact that that is a double entendre just makes it even better than any of the others that I have seen./ A few others I liked: HALTI   Halt Intermittently SPEOT  Seek Past End of Tape (Common DECTAPE problem) A few other related things I have seen: "On a clear disk you can seek forever" "Dark Emitting Diode" "Stop this RIM RAM or I will DEC you" And a couple of acronyms: *M*aybe *I* *C*an *R*ip *O*ff *S*ome *O*ther *F*ailed *T*echnology *W*hy *I*nvest *N*eedless *D*ollars *O*n *W*orking *S*oftware On 12/10/2024 5:59 PM, Donald Whittemore via cctalk wrote: > NEAT/3 instructions > www.myimagecollection.com/webdocs/neat3.pdf > > Misc instructions > www.myimagecollection.com/webdocs/pl-o.pdf > > Misc Assembler > www.myimagecollection.com/webdocs/miscassembler.pdf > > IBM beginnings > www.myimagecollection.com/webdocs/beginning.pdf > > New IBM OS > www.myimagecollection.com/webdocs/newibmos.pdf --===============8816768467401257944==-- From bfranchuk@jetnet.ab.ca Wed Dec 11 05:19:50 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Tue, 10 Dec 2024 22:19:40 -0700 Message-ID: <5ac20ad1-7817-470b-bea9-750a34188894@jetnet.ab.ca> In-Reply-To: <411100b3-1626-4ad8-922f-f1ca32abe74b@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5254185385344231156==" --===============5254185385344231156== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-12-10 6:42 p.m., Mike Katz via cctalk wrote: > Or, more importantly, are we all living in a VR? > > What is reality? > > > On 12/10/2024 7:21 PM, Rick Bensene via cctalk wrote: >> >>> Been waiting 45 years for the new IBM OS. Not holding my breath. :) >> >> >> Ahhh...but are you sure we're all not already running as tasks under >> OS/VR? >> >> >> -Rick > Where is a the PDP stuff? Today; DEC 10 model 2024 feels right for VR. --===============5254185385344231156==-- From doug@doughq.com Wed Dec 11 07:21:13 2024 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 18:04:01 +1100 Message-ID: In-Reply-To: <173388093279.1294.14963525299739465031@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8398068806043639606==" --===============8398068806043639606== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Haven't the really big machines been virtualise under a specialised version of Linux. I recall Andrew Tridgal working for IBM 15 years ago porting it to their Z series. On Wed, 11 Dec 2024, 12:35 pm Donald Whittemore via cctalk, < cctalk(a)classiccmp.org> wrote: > Has to be the mid to late 80s. The new OS paper is 1989. I wrote it. :) > --===============8398068806043639606==-- From dave.g4ugm@gmail.com Wed Dec 11 10:11:04 2024 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 10:10:56 +0000 Message-ID: In-Reply-To: <173387519915.1294.1544252031966632900@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8115456519605979129==" --===============8115456519605979129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 10/12/2024 23:59, Donald Whittemore via cctalk wrote: > NEAT/3 instructions > www.myimagecollection.com/webdocs/neat3.pdf > > Misc instructions > www.myimagecollection.com/webdocs/pl-o.pdf > > Misc Assembler > www.myimagecollection.com/webdocs/miscassembler.pdf > > IBM beginnings > www.myimagecollection.com/webdocs/beginning.pdf > > New IBM OS > www.myimagecollection.com/webdocs/newibmos.pdf There are a few on the VMSHARE Archives... http://vm.marist.edu/~vmshare/vmshare.cgi tick the "browse" box, type "humor*" in the box and click LIST... ... a few will appear e.g. http://vm.marist.edu/~vmshare/browse.cgi?fn=HUMOR94&ft=MEMO&args=KEYS#hit ... has a few interspersed with real questions, so topic drift isn't new... Dave --===============8115456519605979129==-- From dave.g4ugm@gmail.com Wed Dec 11 10:17:08 2024 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Wed, 11 Dec 2024 10:16:58 +0000 Message-ID: <28508129-fd3e-4b04-bee8-ee61ef720b66@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7083547504494343925==" --===============7083547504494343925== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 10/12/2024 07:13, Tom Hunter via cctalk wrote: > If this were my project, I would read the VT100 manual and design and > implement a serial driver and basic text window library from scratch > running on the bare hardware. It wouldn't be more than 1000 lines of C, > more likely something like 500 lines. I am a retired embedded > software engineer and did these things for a living. I would budget 2 to 3 > days including reading the manual. > > Tom I was wondering why no one else suggested this. I did something similar=20 for the memory mapped displays on my 6809 way back when.... .. as for doing it on a VT it might not be as simple as it sounds. If=20 you are going to allow side-by-side windows you will need to keep a copy=20 of the window text in memory and re-write each window every time you=20 want to scroll the windows. Dave > On Tue, 10 Dec 2024, 1:27=E2=80=AFpm Henry Bent via cctalk, > wrote: > >> If this were my project, I would start by getting newlib going and then >> seeing if I could use that to run an older (presumably more simple, with >> fewer requirements) version of screen. >> >> -Henry >> >> On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: >> >>> Overlapping would be amazing, different screen quadrants at a minimum. I >>> am going to try to port Txwindows as that is the only package I could >> find >>> On Dec 9, 2024 8:40 PM, Henry Bent wrote: >>> >>> On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk >> >>> wrote: >>> >>> Thank you. >>> >>> Screen is a linux utility. I am writing this on a bare metal (no >>> operating system) ESP32 dev board. >>> >>> Right now the program is text menu driven. I would like to enhance it >>> with textual windows. >>> >>> The Txwindows package is perfect but over kill and will need some >>> hacking to work in my environment and it doesn't support the VT-100's >>> region scrolling so screen updates might be slow. >>> >>> >>> What might be helpful is if you could be more specific about what it is >>> you're trying to achieve. Do you want arbitrarily sized, overlapping >>> windows or do you just want the screen divided up into discrete segments? >>> >>> -Henry >>> >>> >>> --===============7083547504494343925==-- From cctalk@emailtoilet.com Wed Dec 11 13:24:44 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 13:24:40 +0000 Message-ID: <173392348085.1294.3570602084998000533@classiccmp.org> In-Reply-To: <5ac20ad1-7817-470b-bea9-750a34188894@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0840841206737244672==" --===============0840841206737244672== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Sorry, I was a mainframe guy. Did not mess with those ‘toys.’ --===============0840841206737244672==-- From g4ajq1@gmail.com Wed Dec 11 13:37:58 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 08:37:51 -0500 Message-ID: <3a4ae57b-8f2e-4a05-bf8e-af24c3f297cc@gmail.com> In-Reply-To: <51a99d60-31b4-439e-8b59-04e80a33d6f7@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2736513505473646706==" --===============2736513505473646706== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To add my .02 worth there was also the programmer that thought seek times referred to a New Delhi newspaper In EE, a stable 'Q' point was often understood to mean where the horses lined up for their oats. and DeMorgan's theorem can be reduced to 'change everything and it will still do the same' My all-time favourite was the PDP11 processor manual that actually got out before the footnote 'plus 20 minutes on a Saturday night' referring to the Sign Extend signal delayed for 40 ns after MSync was caught by marketing and the manuals ordered recalled! sorry, Nigel On 2024-12-10 19:31, Mike Katz via cctalk wrote: > I believe in the late 70's or early 80's Byte magazine did an April > Fool's issue that had many of those instructions but other than Halt > and Catch Fire I think the best one was: > > EXOP    Execute Operator  (Use of this instruction has been deprecated > due to shrinking programmer pool) > /The fact that that is a double entendre just makes it even better > than any of the others that I have seen./ > > A few others I liked: > > HALTI   Halt Intermittently > SPEOT  Seek Past End of Tape (Common DECTAPE problem) > > A few other related things I have seen: > > "On a clear disk you can seek forever" > "Dark Emitting Diode" > "Stop this RIM RAM or I will DEC you" > > And a couple of acronyms: > > *M*aybe *I* *C*an *R*ip *O*ff *S*ome *O*ther *F*ailed *T*echnology > > *W*hy *I*nvest *N*eedless *D*ollars *O*n *W*orking *S*oftware > > > > On 12/10/2024 5:59 PM, Donald Whittemore via cctalk wrote: >> NEAT/3 instructions >> www.myimagecollection.com/webdocs/neat3.pdf >> >> Misc instructions >> www.myimagecollection.com/webdocs/pl-o.pdf >> >> Misc Assembler >> www.myimagecollection.com/webdocs/miscassembler.pdf >> >> IBM beginnings >> www.myimagecollection.com/webdocs/beginning.pdf >> >> New IBM OS >> www.myimagecollection.com/webdocs/newibmos.pdf -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============2736513505473646706==-- From bitwiz@12bitsbest.com Wed Dec 11 18:58:29 2024 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Wed, 11 Dec 2024 12:58:20 -0600 Message-ID: <277e7091-46fa-4877-91d8-95b4b2b49f00@12bitsbest.com> In-Reply-To: <28508129-fd3e-4b04-bee8-ee61ef720b66@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0105987058905639593==" --===============0105987058905639593== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit David, Were you using a Gimix Video Board per chance? I worked for Gimix in 1980/1981. There was a very good screen based editor called the Programma Improved Editor (Pie) written by John F. Wakerly that made excellent use of the Gimix Video Board.  There was also a version for serial terminals. One nice thing about the VT-100 is that you can scroll a region without affecting other regions on the display.  A well written driver that takes this into account can be fairly fast even at 9600 board. My goal here is to improve the application and not to write an entire VT-100 windowing package. The Txwindows package is more than I need but I am going to take the linux version of it and see if I can get it working via a serial port on a Raspberry Pi.  I will convert all of the printf() and fwrite() calls to my output routine. Since the code was designed to run on Windows/Linux/OS2 it also has a bunch of sprintf() calls.  In general I avoid printf()/scanf() like the plague because they are big and slow and I have found that i rarely need that level of sophisticated output formatting in an embedded system. I have written a set of functions (input and output) that fulfill most of my text formatting needs.  I will put it up on git one of these days. Thank you,               Mike On 12/11/2024 4:16 AM, David Wade via cctalk wrote: > > > On 10/12/2024 07:13, Tom Hunter via cctalk wrote: >> If this were my project, I would read the VT100 manual and design and >> implement a serial driver and basic text window library from scratch >> running on the bare hardware. It wouldn't be more than 1000 lines of C, >> more likely something like 500 lines. I am a retired embedded >> software engineer and did these things for a living. I would budget 2 >> to 3 >> days including reading the manual. >> >> Tom > I was wondering why no one else suggested this. I did something > similar for the memory mapped displays on my 6809 way back when.... > .. as for doing it on a VT it might not be as simple as it sounds. If > you are going to allow side-by-side windows you will need to keep a > copy of the window text in memory and re-write each window every time > you want to scroll the windows. > > Dave > > > > >> On Tue, 10 Dec 2024, 1:27 pm Henry Bent via cctalk, >> >> wrote: >> >>> If this were my project, I would start by getting newlib going and then >>> seeing if I could use that to run an older (presumably more simple, >>> with >>> fewer requirements) version of screen. >>> >>> -Henry >>> >>> On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: >>> >>>> Overlapping would be amazing, different screen quadrants at a >>>> minimum.  I >>>> am going to try to port Txwindows as that is the only package I could >>> find >>>> On Dec 9, 2024 8:40 PM, Henry Bent wrote: >>>> >>>> On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk >>>> >>> >>>> wrote: >>>> >>>> Thank you. >>>> >>>> Screen is a linux utility.  I am writing this on a bare metal (no >>>> operating system) ESP32 dev board. >>>> >>>> Right now the program is text menu driven.  I would like to enhance it >>>> with textual windows. >>>> >>>> The Txwindows package is perfect but over kill and will need some >>>> hacking to work in my environment and it doesn't support the VT-100's >>>> region scrolling so screen updates might be slow. >>>> >>>> >>>> What might be helpful is if you could be more specific about what >>>> it is >>>> you're trying to achieve.  Do you want arbitrarily sized, overlapping >>>> windows or do you just want the screen divided up into discrete >>>> segments? >>>> >>>> -Henry >>>> >>>> >>>> > --===============0105987058905639593==-- From wayne.sudol@hotmail.com Wed Dec 11 20:16:10 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: VT-100 Text Windows library Date: Wed, 11 Dec 2024 20:16:03 +0000 Message-ID: In-Reply-To: <277e7091-46fa-4877-91d8-95b4b2b49f00@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1923751709413094369==" --===============1923751709413094369== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Mike, you might want to just write the vt stuff from scratch. The vt uses escape sequences for control and there=E2=80=99s really not much = to it as the terminal will do all the work for you. We used to do it using DEC DIBOL to do data entry in fields from RSTS. The M= CBA Accounting programs written in DIBOL do that. Might take a look at the co= de. They sold you the source code so it=E2=80=99s available online somewhere. I=E2=80=99ll have to look. Sent from my iPhone > On Dec 11, 2024, at 10:58, Mike Katz via cctalk w= rote: >=20 > =EF=BB=BFDavid, >=20 > Were you using a Gimix Video Board per chance? >=20 > I worked for Gimix in 1980/1981. >=20 > There was a very good screen based editor called the Programma Improved Edi= tor (Pie) written by John F. Wakerly that made excellent use of the Gimix Vid= eo Board. There was also a version for serial terminals. >=20 > One nice thing about the VT-100 is that you can scroll a region without aff= ecting other regions on the display. A well written driver that takes this i= nto account can be fairly fast even at 9600 board. >=20 > My goal here is to improve the application and not to write an entire VT-10= 0 windowing package. >=20 > The Txwindows package is more than I need but I am going to take the linux = version of it and see if I can get it working via a serial port on a Raspberr= y Pi. I will convert all of the printf() and fwrite() calls to my output rou= tine. >=20 > Since the code was designed to run on Windows/Linux/OS2 it also has a bunch= of sprintf() calls. In general I avoid printf()/scanf() like the plague bec= ause they are big and slow and I have found that i rarely need that level of = sophisticated output formatting in an embedded system. >=20 > I have written a set of functions (input and output) that fulfill most of m= y text formatting needs. I will put it up on git one of these days. >=20 > Thank you, >=20 > Mike >=20 >=20 >=20 >=20 >=20 >> On 12/11/2024 4:16 AM, David Wade via cctalk wrote: >>=20 >>=20 >>> On 10/12/2024 07:13, Tom Hunter via cctalk wrote: >>> If this were my project, I would read the VT100 manual and design and >>> implement a serial driver and basic text window library from scratch >>> running on the bare hardware. It wouldn't be more than 1000 lines of C, >>> more likely something like 500 lines. I am a retired embedded >>> software engineer and did these things for a living. I would budget 2 to 3 >>> days including reading the manual. >>>=20 >>> Tom >> I was wondering why no one else suggested this. I did something similar fo= r the memory mapped displays on my 6809 way back when.... >> .. as for doing it on a VT it might not be as simple as it sounds. If you = are going to allow side-by-side windows you will need to keep a copy of the w= indow text in memory and re-write each window every time you want to scroll t= he windows. >>=20 >> Dave >>=20 >>=20 >>=20 >>=20 >>> On Tue, 10 Dec 2024, 1:27=E2=80=AFpm Henry Bent via cctalk, >>> wrote: >>>=20 >>>> If this were my project, I would start by getting newlib going and then >>>> seeing if I could use that to run an older (presumably more simple, with >>>> fewer requirements) version of screen. >>>>=20 >>>> -Henry >>>>=20 >>>> On Mon, Dec 9, 2024, 22:04 Mike Katz wrote: >>>>=20 >>>>> Overlapping would be amazing, different screen quadrants at a minimum. = I >>>>> am going to try to port Txwindows as that is the only package I could >>>> find >>>>> On Dec 9, 2024 8:40 PM, Henry Bent wrote: >>>>>=20 >>>>> On Thu, 5 Dec 2024 at 20:26, Mike Katz via cctalk >>>>=20 >>>>> wrote: >>>>>=20 >>>>> Thank you. >>>>>=20 >>>>> Screen is a linux utility. I am writing this on a bare metal (no >>>>> operating system) ESP32 dev board. >>>>>=20 >>>>> Right now the program is text menu driven. I would like to enhance it >>>>> with textual windows. >>>>>=20 >>>>> The Txwindows package is perfect but over kill and will need some >>>>> hacking to work in my environment and it doesn't support the VT-100's >>>>> region scrolling so screen updates might be slow. >>>>>=20 >>>>>=20 >>>>> What might be helpful is if you could be more specific about what it is >>>>> you're trying to achieve. Do you want arbitrarily sized, overlapping >>>>> windows or do you just want the screen divided up into discrete segment= s? >>>>>=20 >>>>> -Henry >>>>>=20 >>>>>=20 >>>>>=20 >>=20 >=20 --===============1923751709413094369==-- From dave.g4ugm@gmail.com Wed Dec 11 22:11:52 2024 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 22:11:42 +0000 Message-ID: <33fbf8bb-9b83-4128-8e44-b4a388e46b3c@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4810010772720952235==" --===============4810010772720952235== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 11/12/2024 07:04, Doug Jackson via cctalk wrote: > Haven't the really big machines been virtualise under a specialised version > of Linux. I recall Andrew Tridgal working for IBM 15 years ago porting it > to their Z series. Whilst Linux runs on Z its either in a virtual machine created by zVM or in an LPAR which is in effect a virtual machine created by the microcode of the Z box. As far as I know none of the modern Linux virtualization systems work on zVM. The main difference between a zVM Virtual Machine and an LPAR is in the management facilities. They use the same underlying microcode and hardware support, but zVM is more flexible, especially when sharing parts of disks. > On Wed, 11 Dec 2024, 12:35 pm Donald Whittemore via cctalk, < > cctalk(a)classiccmp.org> wrote: > >> Has to be the mid to late 80s. The new OS paper is 1989. I wrote it. :) >> Dave G4UGM --===============4810010772720952235==-- From drb@msu.edu Thu Dec 12 01:03:40 2024 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: Old mainframe humor Date: Wed, 11 Dec 2024 20:03:35 -0500 Message-ID: <20241212010335.0C38D50CCA2@yagi.h-net.msu.edu> In-Reply-To: <33fbf8bb-9b83-4128-8e44-b4a388e46b3c@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9103443923552016348==" --===============9103443923552016348== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > As far as I know none of the modern Linux virtualization systems work on > zVM. The main difference between a zVM Virtual Machine and an LPAR is in > the management facilities. Actually, KVM and qemu exist: https://docs.kernel.org/virt/kvm/s390/index.html https://qemu.readthedocs.io/en/v8.1.5/system/target-s390x.html though why you'd use them instead of the VM or LPAR stuff on a z machine is beyond me. I imagine the usual linux cgroup&friends stuff probably works too, for containerization. De --===============9103443923552016348==-- From malcolmc.home@gmail.com Thu Dec 12 17:52:04 2024 From: Malcolm Clark To: cctalk@classiccmp.org Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Facit 4060 Punch Date: Thu, 12 Dec 2024 12:48:11 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8379711710052492836==" --===============8379711710052492836== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Martin, I am looking for a manual for the above tape reader and found your details from a discussion on cctalk from July 2022. I am a volunteer at The National Museum of Computing and an ex Ferranti engineer. I am currently restoring an Argus 500 computer and trying to get it back to its original configuration. I have recently restored 2 Trend HSR 500 readers and now have acquired 2 UDR 700 readers that need to be fixed and set up. My latest video on YouTube https://youtu.be/8HtRqe6jzc8?si=MmRL4qbh_7PZjVff In the email you said you had scanned the document into a file. Would it be possible to upload it to Google Drive and send me the link so I can download it? Ultimately I would like to upload it to the Museum archive and make it available for everyone to view. I am assuming that there are no copyright issues as Trend was finally wound up as a company in December 2022. Hope to hear from you soon Kind Regards Malcolm Clark --===============8379711710052492836==-- From ard.p850ug1@gmail.com Thu Dec 12 18:28:57 2024 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Facit 4060 Punch Date: Thu, 12 Dec 2024 18:28:42 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0262628247652886924==" --===============0262628247652886924== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 12, 2024 at 6:02=E2=80=AFPM Malcolm Clark via cctalk wrote: > > Hi Martin, > I am looking for a manual for the above tape reader and found your details > from a discussion on cctalk from July 2022. > > I am a volunteer at The National Museum of Computing and an ex Ferranti > engineer. I am currently restoring an Argus 500 computer and trying to get > it back to its original configuration. I have recently restored 2 Trend > HSR 500 readers and now have acquired 2 UDR 700 readers that need to be > fixed and set up. I've uploaded the UDR350/UDR700 manual to my google drive here : https://drive.google.com/file/d/1tqFbQ9S1SJd4DwsR6J7qlBiEWVpbmKnc/view?usp=3D= sharing It's a _LARGE_ file, you might be able to compress it somehow. Please let me know when you've taken it so I can delete it to save space on the googled drive, of course I'll keep a copy on my machine. Do you also need the HSR500/HSR500P manual? I have that too. > My latest video on YouTube > > https://youtu.be/8HtRqe6jzc8?si=3DMmRL4qbh_7PZjVff > > In the email you said you had scanned the document into a file. Would it > be possible to upload it to Google Drive and send me the link so I can > download it? Ultimately I would like to upload it to the Museum archive > and make it available for everyone to view. I am assuming that there are > no copyright issues as Trend was finally wound up as a company in December > 2022. It's probably still under copyright owned by somebody, but my experience is that companies don't normally care about 50-year-old service manuals. -tony --===============0262628247652886924==-- From mjd.bishop@emeritus-solutions.com Thu Dec 12 22:43:17 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Facit 4060 Punch Date: Thu, 12 Dec 2024 22:43:08 +0000 Message-ID: <30ffe361985b4a0096480e83108f1844@emeritus-solutions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8563948834049536912==" --===============8563948834049536912== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tony Thank you for responding to this query earlier, as you did to my query in Sum= mer '22. I have had a quick "go" at compressing the big pdfs, brute force Acrobat Pro = looks not to cut it, to avoid pixelation the circuits require little compress= ion and to reduce volume the text requires more compression. Therefore, eith= er human effort or a better tool is required ... FWIW having downloaded your google drive version of the file I could not open= it. Martin -----Original Message----- From: Tony Duell via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 12 December 2024 18:29 To: General Discussion: On-Topic and Off-Topic Posts Cc: Malcolm Clark ; Tony Duell Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Faci= t 4060 Punch On Thu, Dec 12, 2024 at 6:02=E2=80=AFPM Malcolm Clark via cctalk wrote: > > Hi Martin, > I am looking for a manual for the above tape reader and found your=20 > details from a discussion on cctalk from July 2022. > > I am a volunteer at The National Museum of Computing and an ex=20 > Ferranti engineer. I am currently restoring an Argus 500 computer and=20 > trying to get it back to its original configuration. I have recently=20 > restored 2 Trend HSR 500 readers and now have acquired 2 UDR 700=20 > readers that need to be fixed and set up. I've uploaded the UDR350/UDR700 manual to my google drive here : https://drive.google.com/file/d/1tqFbQ9S1SJd4DwsR6J7qlBiEWVpbmKnc/view?usp=3D= sharing It's a _LARGE_ file, you might be able to compress it somehow. Please let me = know when you've taken it so I can delete it to save space on the googled dri= ve, of course I'll keep a copy on my machine. Do you also need the HSR500/HSR500P manual? I have that too. > My latest video on YouTube > > https://youtu.be/8HtRqe6jzc8?si=3DMmRL4qbh_7PZjVff > > In the email you said you had scanned the document into a file. Would=20 > it be possible to upload it to Google Drive and send me the link so I=20 > can download it? Ultimately I would like to upload it to the Museum=20 > archive and make it available for everyone to view. I am assuming=20 > that there are no copyright issues as Trend was finally wound up as a=20 > company in December 2022. It's probably still under copyright owned by somebody, but my experience is t= hat companies don't normally care about 50-year-old service manuals. -tony --===============8563948834049536912==-- From jfsebastian@null.net Fri Dec 13 01:51:50 2024 From: jfsebastian@null.net To: cctalk@classiccmp.org Subject: [cctalk] very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 01:51:45 +0000 Message-ID: <173405470523.1294.931209225963525937@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2073747856729465926==" --===============2073747856729465926== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello I have been doing a several years effort to save (very) old software for post= erity, researchers, students. Mostly early 90s UNIXes, SunOS, Solaris, DG-UX,= HP-UX, AIX, DEC-UNIX, some VMS software even. I uploaded some things to the = Archive, and elsewhere, but I would rather get this off my shoulders, for mor= tality affects us all. This vanishing would be a loss, with many of these thi= ngs are nowhere to be found anymore. I tried contacting the admin(?) bear at typewritten dot org, offering a few t= hings for archiving, without results. Do any of the users here have any means= to contact the admin there? I would very much like to access some of the UNI= Xes software there, and would gladly offer a quid pro quo.=20 Similarly, if you have any software for Solaris (2.6, earlier) and other UNIX= es, regardless of licensing status, I would be very much interested. Some things probably are lost forever though, such as Proliant PL/I, VisualWo= rks 2.5, Tibco S-PLUS, Harlequin WebWorks and such.=20 Thanks in advance, and all the best Seb. --===============2073747856729465926==-- From cam.k801@gmail.com Fri Dec 13 02:28:56 2024 From: Cameron Kelly To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Thu, 12 Dec 2024 21:28:30 -0500 Message-ID: <5708AF56-011A-4DA7-B8A8-AE1920F0FF62@gmail.com> In-Reply-To: <173405470523.1294.931209225963525937@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8606038871860425444==" --===============8606038871860425444== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have a QIC tape that I=E2=80=99m looking to get the contents off of and was= pointed in bear=E2=80=99s direction and he=E2=80=99s ignored my emails too. = I guess it is best not to bother him.=20 >=20 > On Dec 12, 2024, at 8:51 PM, jfsebastian--- via cctalk wrote: >=20 > =EF=BB=BFHello >=20 > I have been doing a several years effort to save (very) old software for po= sterity, researchers, students. Mostly early 90s UNIXes, SunOS, Solaris, DG-U= X, HP-UX, AIX, DEC-UNIX, some VMS software even. I uploaded some things to th= e Archive, and elsewhere, but I would rather get this off my shoulders, for m= ortality affects us all. This vanishing would be a loss, with many of these t= hings are nowhere to be found anymore. >=20 > I tried contacting the admin(?) bear at typewritten dot org, offering a few= things for archiving, without results. Do any of the users here have any mea= ns to contact the admin there? I would very much like to access some of the U= NIXes software there, and would gladly offer a quid pro quo.=20 >=20 > Similarly, if you have any software for Solaris (2.6, earlier) and other UN= IXes, regardless of licensing status, I would be very much interested. > Some things probably are lost forever though, such as Proliant PL/I, Visual= Works 2.5, Tibco S-PLUS, Harlequin WebWorks and such.=20 > Thanks in advance, and all the best > Seb. --===============8606038871860425444==-- From henry.r.bent@gmail.com Fri Dec 13 02:58:50 2024 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Thu, 12 Dec 2024 21:58:35 -0500 Message-ID: In-Reply-To: <5708AF56-011A-4DA7-B8A8-AE1920F0FF62@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5107432274719332395==" --===============5107432274719332395== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, 12 Dec 2024 at 21:37, Cameron Kelly via cctalk < cctalk(a)classiccmp.org> wrote: > I have a QIC tape that I’m looking to get the contents off of and was > pointed in bear’s direction and he’s ignored my emails too. > > I guess it is best not to bother him. > I stumbled on his website many years ago and emailed him several times. Like the rest of you, I never got a response. I can only conclude that he is someone who enjoys having a private collection and showing it off, but is entirely uninterested in sharing - or perhaps, playing well - with others. -Henry --===============5107432274719332395==-- From cam.k801@gmail.com Fri Dec 13 03:14:18 2024 From: Cameron Kelly To: cctalk@classiccmp.org Subject: [cctalk] QIC Archival Date: Thu, 12 Dec 2024 22:13:51 -0500 Message-ID: <3D185A14-C9CC-4AA9-AB43-1CED141AE6F1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2612266745547344783==" --===============2612266745547344783== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I have a QIC tape of an interesting piece of software that doesn=E2=80=99t se= em to be archived anywhere. I don=E2=80=99t have experience using QIC tape so= I=E2=80=99m inquiring if anyone here would be willing to offer the service. = The software in question is =E2=80=9CCorelDraw For Unix=E2=80=9D.=20 Thanks, Cameron --===============2612266745547344783==-- From lewissa78@gmail.com Fri Dec 13 04:11:23 2024 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Thu, 12 Dec 2024 22:11:05 -0600 Message-ID: In-Reply-To: <3D185A14-C9CC-4AA9-AB43-1CED141AE6F1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2859949144958600726==" --===============2859949144958600726== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Seek out AJ (of Forgotten Machines), I saw his "portable self-made QIC reader" in operation and it's very fantastic. He's active on his Discord channel. I think the device he made could handle 7 tracks? But the IBM tapes were investigating at the time were only 2 track. There is a bit of context difference between earlier DC (data cartridge) and the later generation QIC. My view: QIC became a kind of organization that formalized the media format, and offered longer tapes. While DC is generally the earlier 300 or 600ft variety. It's not a very good "long shelf life" format, since that rubber band can eat into the tape. But when it does work, it really is much faster and better than the smaller audio tapes. The Wang-folks seem to have decoded the QIC format for their systems. But I'm not sure if any Wang system ever ran Unix. But CorelDraw, on a QIC tape? Makes me want to write "AutoCAD for VIC-20" on an old cassette tape and toss it on the free pile at a VCF :P On Thu, Dec 12, 2024 at 9:14 PM Cameron Kelly via cctalk < cctalk(a)classiccmp.org> wrote: > Hello, > > I have a QIC tape of an interesting piece of software that doesn’t seem to > be archived anywhere. I don’t have experience using QIC tape so I’m > inquiring if anyone here would be willing to offer the service. The > software in question is “CorelDraw For Unix”. > > Thanks, > > Cameron --===============2859949144958600726==-- From cclist@sydex.com Fri Dec 13 04:40:17 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Fri, 13 Dec 2024 04:34:22 +0000 Message-ID: <10dded32-0358-4c46-9803-47b3ae887569@sydex.com> In-Reply-To: <3D185A14-C9CC-4AA9-AB43-1CED141AE6F1@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6039578023192180710==" --===============6039578023192180710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 12/12/24 19:13, Cameron Kelly via cctalk wrote: > Hello, >=20 > I have a QIC tape of an interesting piece of software that doesn=E2=80=99t = seem to be archived anywhere. I don=E2=80=99t have experience using QIC tape = so I=E2=80=99m inquiring if anyone here would be willing to offer the service= . The software in question is =E2=80=9CCorelDraw For Unix=E2=80=9D.=20 >=20 I do quite a few quarter-inch cartridges as part of my business. There's an incredible variety of formats; for example, Iotamat carts look just like a DC600 cartridge, but do not use optical sensing--BOT/ET etc is all recorded as special patterns on the tape. If you get stuck, I'd be happy to have a look at the tape. --Chuck --===============6039578023192180710==-- From malcolmc.home@gmail.com Fri Dec 13 05:55:38 2024 From: Malcolm Clark To: cctalk@classiccmp.org Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Facit 4060 Punch Date: Thu, 12 Dec 2024 21:48:41 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8784924080008019452==" --===============8784924080008019452== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tony, Many thanks for this manual. I've already identified some dried out capacitors in my readers, once they have been replaced I can use the manual to go through the setup procedures. Thanks for the offer of the HSR500 manual but I already have an electronic copy of it, I think from Bitsavers. I have been able to compress your manual down to under 8Mb using a free trial of an online Adobe utility. https://www.adobe.com/uk/acrobat/online/compress-pdf.html Thanks once again for your help. As an aside, I saw in the conversation thatsomeone thought the UDR700 was used on the Ferranti FM1600B. When I was a Ferranti apprentice in the early 1970s I worked in the FM1600B commissioning area in Doncastle Road Bracknell. The only reader used then was a rebadged ICL TRM 1000. With this reader you really did have to aim the tape into the collection basket!! Kind Regards, Malcolm Clark On Thu, 12 Dec 2024 at 18:28, Tony Duell wrote: > On Thu, Dec 12, 2024 at 6:02=E2=80=AFPM Malcolm Clark via cctalk > wrote: > > > > Hi Martin, > > I am looking for a manual for the above tape reader and found your > details > > from a discussion on cctalk from July 2022. > > > > I am a volunteer at The National Museum of Computing and an ex Ferranti > > engineer. I am currently restoring an Argus 500 computer and trying to > get > > it back to its original configuration. I have recently restored 2 Trend > > HSR 500 readers and now have acquired 2 UDR 700 readers that need to be > > fixed and set up. > > I've uploaded the UDR350/UDR700 manual to my google drive here : > > > https://drive.google.com/file/d/1tqFbQ9S1SJd4DwsR6J7qlBiEWVpbmKnc/view?usp= =3Dsharing > > It's a _LARGE_ file, you might be able to compress it somehow. Please > let me know when you've taken it so I can delete it to save space on > the googled drive, of course I'll keep a copy on my machine. > > > Do you also need the HSR500/HSR500P manual? I have that too. > > > My latest video on YouTube > > > > https://youtu.be/8HtRqe6jzc8?si=3DMmRL4qbh_7PZjVff > > > > In the email you said you had scanned the document into a file. Would it > > be possible to upload it to Google Drive and send me the link so I can > > download it? Ultimately I would like to upload it to the Museum archive > > and make it available for everyone to view. I am assuming that there are > > no copyright issues as Trend was finally wound up as a company in > December > > 2022. > > It's probably still under copyright owned by somebody, but my > experience is that companies don't normally care about 50-year-old > service manuals. > > -tony > --===============8784924080008019452==-- From robert.jarratt@ntlworld.com Fri Dec 13 06:26:53 2024 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 06:26:46 +0000 Message-ID: <001901db4d27$fc65b9b0$f5312d10$@ntlworld.com> In-Reply-To: <173405470523.1294.931209225963525937@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4088491554767391866==" --===============4088491554767391866== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: jfsebastian--- via cctalk > Sent: 13 December 2024 01:52 > To: cctalk(a)classiccmp.org > Cc: jfsebastian(a)null.net > Subject: [cctalk] very old UNIXes software, contact at typewritten? >=20 > Hello >=20 > I have been doing a several years effort to save (very) old software for > posterity, researchers, students. Mostly early 90s UNIXes, SunOS, Solaris, = DG- > UX, HP-UX, AIX, DEC-UNIX, some VMS software even. I uploaded some things > to the Archive, and elsewhere, but I would rather get this off my shoulders, > for mortality affects us all. This vanishing would be a loss, with many of = these > things are nowhere to be found anymore. >=20 > I tried contacting the admin(?) bear at typewritten dot org, offering a few > things for archiving, without results. Do any of the users here have any me= ans > to contact the admin there? I would very much like to access some of the > UNIXes software there, and would gladly offer a quid pro quo. >=20 > Similarly, if you have any software for Solaris (2.6, earlier) and other UN= IXes, > regardless of licensing status, I would be very much interested. > Some things probably are lost forever though, such as Proliant PL/I, > VisualWorks 2.5, Tibco S-PLUS, Harlequin WebWorks and such. > Thanks in advance, and all the best > Seb. Have you tried sending the material you want to archive to bitsavers? Rob --===============4088491554767391866==-- From smbaker@gmail.com Fri Dec 13 06:30:01 2024 From: Scott Baker To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Thu, 12 Dec 2024 22:29:42 -0800 Message-ID: In-Reply-To: <10dded32-0358-4c46-9803-47b3ae887569@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3110763443389198860==" --===============3110763443389198860== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Agree with seeking out AJ. Either he or Chuck were the ones who told me how to do it. I was able to successfully read a few tapes by using a SCSI QIC drive and reading a tape under linux. Two things to beware of are that 1) the rubber rollers in old QIC drives will sometimes turn to sticky goo, and 2) the tension bands inside the tapes themselves will sometimes break. Back when I was pursuing these QIC tapes as a hobby a couple years ago, I found that most of the new tapes I found had tension bands either broken or that broke immediately on use. Brand new tapes still in shrinkwrap, from multiple manufacturers. Both of these problems are solvable with appropriate caution (AJ has a video; VCF hass some threads). QIC did seem to have its niche in software distribution, for things that were too big/inconvenient for floppies, before CDs came out. Scott On Thu, Dec 12, 2024 at 8:40 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 12/12/24 19:13, Cameron Kelly via cctalk wrote: > > Hello, > > > > I have a QIC tape of an interesting piece of software that doesn’t seem > to be archived anywhere. I don’t have experience using QIC tape so I’m > inquiring if anyone here would be willing to offer the service. The > software in question is “CorelDraw For Unix”. > > > I do quite a few quarter-inch cartridges as part of my business. > > There's an incredible variety of formats; for example, Iotamat carts > look just like a DC600 cartridge, but do not use optical sensing--BOT/ET > etc is all recorded as special patterns on the tape. > > If you get stuck, I'd be happy to have a look at the tape. > > --Chuck > > --===============3110763443389198860==-- From jrr@flippers.com Fri Dec 13 06:30:44 2024 From: John Robertson To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Thu, 12 Dec 2024 22:25:31 -0800 Message-ID: In-Reply-To: <173405470523.1294.931209225963525937@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9098379961921866429==" --===============9098379961921866429== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Archive.org or bitsavers.org? John :-#)# On 2024-12-12 5:51 p.m., jfsebastian--- via cctalk wrote: > Hello > > I have been doing a several years effort to save (very) old software for po= sterity, researchers, students. Mostly early 90s UNIXes, SunOS, Solaris, DG-U= X, HP-UX, AIX, DEC-UNIX, some VMS software even. I uploaded some things to th= e Archive, and elsewhere, but I would rather get this off my shoulders, for m= ortality affects us all. This vanishing would be a loss, with many of these t= hings are nowhere to be found anymore. > > I tried contacting the admin(?) bear at typewritten dot org, offering a few= things for archiving, without results. Do any of the users here have any mea= ns to contact the admin there? I would very much like to access some of the U= NIXes software there, and would gladly offer a quid pro quo. > > Similarly, if you have any software for Solaris (2.6, earlier) and other UN= IXes, regardless of licensing status, I would be very much interested. > Some things probably are lost forever though, such as Proliant PL/I, Visual= Works 2.5, Tibco S-PLUS, Harlequin WebWorks and such. > Thanks in advance, and all the best > Seb. --=20 John's Jukes Ltd. 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 Call (604)872-5757 (Pinballs, Jukes, Video Games) flippers.com "Old pinballers never die, they just flip out" --===============9098379961921866429==-- From doug@doughq.com Fri Dec 13 06:42:33 2024 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 17:42:13 +1100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3954504238399269775==" --===============3954504238399269775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Both - Assume one goes down. Kindest regards, Doug Jackson em: doug(a)doughq.com ph: 0414 986878 Follow my amateur radio adventures at vk1zdj.net On Fri, 13 Dec 2024 at 17:30, John Robertson via cctalk < cctalk(a)classiccmp.org> wrote: > Archive.org or bitsavers.org? > > John :-#)# > > On 2024-12-12 5:51 p.m., jfsebastian--- via cctalk wrote: > > Hello > > > > I have been doing a several years effort to save (very) old software for > posterity, researchers, students. Mostly early 90s UNIXes, SunOS, Solaris, > DG-UX, HP-UX, AIX, DEC-UNIX, some VMS software even. I uploaded some things > to the Archive, and elsewhere, but I would rather get this off my > shoulders, for mortality affects us all. This vanishing would be a loss, > with many of these things are nowhere to be found anymore. > > > > I tried contacting the admin(?) bear at typewritten dot org, offering a > few things for archiving, without results. Do any of the users here have > any means to contact the admin there? I would very much like to access some > of the UNIXes software there, and would gladly offer a quid pro quo. > > > > Similarly, if you have any software for Solaris (2.6, earlier) and other > UNIXes, regardless of licensing status, I would be very much interested. > > Some things probably are lost forever though, such as Proliant PL/I, > VisualWorks 2.5, Tibco S-PLUS, Harlequin WebWorks and such. > > Thanks in advance, and all the best > > Seb. > > > -- > John's Jukes Ltd. > 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 > Call (604)872-5757 (Pinballs, Jukes, Video Games) > flippers.com > "Old pinballers never die, they just flip out" > > --===============3954504238399269775==-- From cclist@sydex.com Fri Dec 13 07:28:46 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Fri, 13 Dec 2024 07:28:37 +0000 Message-ID: <36226f91-fa1f-418d-9e26-7308be707f2e@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6688280687507445853==" --===============6688280687507445853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 12/12/24 22:29, Scott Baker wrote: > 1) the rubber rollers in old QIC drives will sometimes turn to sticky goo, Thoae can usually be repaired. Tandberg drives seem to be immune to this, so I use them whenever possible. --Chuck --===============6688280687507445853==-- From mjd.bishop@emeritus-solutions.com Fri Dec 13 09:04:55 2024 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Facit 4060 Punch Date: Fri, 13 Dec 2024 09:04:48 +0000 Message-ID: <0842c6fc50e84211bdd138b910e27bea@emeritus-solutions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6994908040357759570==" --===============6994908040357759570== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The Centre for Computing History at Cambridge, UK have have a UDR700 https://= www.computinghistory.org.uk/det/16227/Ferranti-Paper-Tape-Reader/ and interfa= ce drawings for a Ferranti FM1600B; I believe they also have the machine : al= l extracted from HMS Dryad in the 90's IIRC. With notice they can provide ac= cess to the paperware (for the interfaces) - I have photographed the ccts. H= owever, it has been through technical writers and I could find no insightful = prose. I doubt what I have adds to Tony's UDR700 manual and your Argus knowl= edge. Martin -----Original Message----- From: Malcolm Clark via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 12 December 2024 21:49 To: Tony Duell Cc: General Discussion: On-Topic and Off-Topic Posts ; Malcolm Clark Subject: [cctalk] Re: Information on Trend UTR 700 Paper Tape Reader and Faci= t 4060 Punch Hi Tony, Many thanks for this manual. I've already identified some dried out capacito= rs in my readers, once they have been replaced I can use the manual to go thr= ough the setup procedures. Thanks for the offer of the HSR500 manual but I already have an electronic co= py of it, I think from Bitsavers. I have been able to compress your manual down to under 8Mb using a free trial= of an online Adobe utility. https://www.adobe.com/uk/acrobat/online/compress-pdf.html Thanks once again for your help. As an aside, I saw in the conversation thatsomeone thought the UDR700 was use= d on the Ferranti FM1600B. When I was a Ferranti apprentice in the early 197= 0s I worked in the FM1600B commissioning area in Doncastle Road Bracknell. T= he only reader used then was a rebadged ICL TRM 1000. With this reader you r= eally did have to aim the tape into the collection basket!! Kind Regards, Malcolm Clark On Thu, 12 Dec 2024 at 18:28, Tony Duell wrote: > On Thu, Dec 12, 2024 at 6:02=E2=80=AFPM Malcolm Clark via cctalk=20 > wrote: > > > > Hi Martin, > > I am looking for a manual for the above tape reader and found your > details > > from a discussion on cctalk from July 2022. > > > > I am a volunteer at The National Museum of Computing and an ex=20 > > Ferranti engineer. I am currently restoring an Argus 500 computer=20 > > and trying to > get > > it back to its original configuration. I have recently restored 2=20 > > Trend HSR 500 readers and now have acquired 2 UDR 700 readers that=20 > > need to be fixed and set up. > > I've uploaded the UDR350/UDR700 manual to my google drive here : > > > https://drive.google.com/file/d/1tqFbQ9S1SJd4DwsR6J7qlBiEWVpbmKnc/view > ?usp=3Dsharing > > It's a _LARGE_ file, you might be able to compress it somehow. Please=20 > let me know when you've taken it so I can delete it to save space on=20 > the googled drive, of course I'll keep a copy on my machine. > > > Do you also need the HSR500/HSR500P manual? I have that too. > > > My latest video on YouTube > > > > https://youtu.be/8HtRqe6jzc8?si=3DMmRL4qbh_7PZjVff > > > > In the email you said you had scanned the document into a file. =20 > > Would it be possible to upload it to Google Drive and send me the=20 > > link so I can download it? Ultimately I would like to upload it to=20 > > the Museum archive and make it available for everyone to view. I am=20 > > assuming that there are no copyright issues as Trend was finally=20 > > wound up as a company in > December > > 2022. > > It's probably still under copyright owned by somebody, but my=20 > experience is that companies don't normally care about 50-year-old=20 > service manuals. > > -tony > --===============6994908040357759570==-- From cliendo@gmail.com Fri Dec 13 10:10:28 2024 From: Christian Liendo To: cctalk@classiccmp.org Subject: [cctalk] IEEE Spectrum: When IBM Built a War Room for Executives A new video captures a remarkable 1968 demo of =?utf-8?q?IBM=E2=80=99s?= Executive Terminal Date: Fri, 13 Dec 2024 11:10:14 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2672422921092467967==" --===============2672422921092467967== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit As time goes on new things are found. When IBM Built a War Room for Executives A new video captures a remarkable 1968 demo of IBM’s Executive Terminal https://spectrum.ieee.org/ibm-demo --===============2672422921092467967==-- From elson@pico-systems.com Fri Dec 13 15:45:11 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Fri, 13 Dec 2024 09:45:02 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0515327966315978345==" --===============0515327966315978345== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/12/24 22:11, Steve Lewis via cctalk wrote: > Seek out AJ (of Forgotten Machines), I saw his "portable self-made QIC > reader" in operation and it's very fantastic. He's active on his Discord > channel. I think the device he made could handle 7 tracks? But the IBM > tapes were investigating at the time were only 2 track. > I ran into AJ (?Palmgen? I think) at the recent VCFMW.  Very interesting guy, and very nice!  He has a lot of restoration projects in progress. Jon --===============0515327966315978345==-- From cctalk@ibm51xx.net Fri Dec 13 20:03:08 2024 From: Ali To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 11:58:04 -0800 Message-ID: <01ae01db4d99$52c9e620$f85db260$@net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2565634838102379141==" --===============2565634838102379141== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I can only conclude that > he > is someone who enjoys having a private collection and showing it off, > but > is entirely uninterested in sharing - or perhaps, playing well - with > others. >=20 > -Henry That is a strange assumption. My experience has been totally different. Long = before I got on this list or seriously into vintage computers I got my hand o= n an Everex EISA system. I was looking everywhere for the CFG and OVL file fo= r the system and found an old usenet post from Bear indicating he had been al= so looking and finally found the files. I e-mailed him not really expecting a= response (since the posting was a few years old by then). Not only did he re= spond, he also sent me the ECU disk and I was able to get the system up and r= unning. I know Bear does frequent the list and he posts here once in a while= . He may have just missed those emails. Maybe do a search of the archive and = make sure you are using a current email of his? -Ali --===============2565634838102379141==-- From wayne.sudol@hotmail.com Fri Dec 13 20:10:33 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 20:10:26 +0000 Message-ID: In-Reply-To: <01ae01db4d99$52c9e620$f85db260$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0337353141317195765==" --===============0337353141317195765== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Kinda wierd site. It looks like it=E2=80=99s a listing of documents and softw= are but you can=E2=80=99t download or request anything.=20 Sent from my iPhone > On Dec 13, 2024, at 12:03, Ali via cctalk wrote: >=20 > =EF=BB=BF >>=20 >> I can only conclude that >> he >> is someone who enjoys having a private collection and showing it off, >> but >> is entirely uninterested in sharing - or perhaps, playing well - with >> others. >>=20 >> -Henry >=20 > That is a strange assumption. My experience has been totally different. Lon= g before I got on this list or seriously into vintage computers I got my hand= on an Everex EISA system. I was looking everywhere for the CFG and OVL file = for the system and found an old usenet post from Bear indicating he had been = also looking and finally found the files. I e-mailed him not really expecting= a response (since the posting was a few years old by then). Not only did he = respond, he also sent me the ECU disk and I was able to get the system up and= running. I know Bear does frequent the list and he posts here once in a whi= le. He may have just missed those emails. Maybe do a search of the archive an= d make sure you are using a current email of his? >=20 > -Ali >=20 >=20 >=20 --===============0337353141317195765==-- From cam.k801@gmail.com Fri Dec 13 20:22:52 2024 From: Cameron Kelly To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 15:22:34 -0500 Message-ID: In-Reply-To: <01ae01db4d99$52c9e620$f85db260$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1286828269091970695==" --===============1286828269091970695== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I tried emailing the one that is on his site.=20 >=20 > On Dec 13, 2024, at 2:58 PM, Ali wrote: >=20 > =EF=BB=BF >>=20 >> I can only conclude that >> he >> is someone who enjoys having a private collection and showing it off, >> but >> is entirely uninterested in sharing - or perhaps, playing well - with >> others. >>=20 >> -Henry >=20 > That is a strange assumption. My experience has been totally different. Lon= g before I got on this list or seriously into vintage computers I got my hand= on an Everex EISA system. I was looking everywhere for the CFG and OVL file = for the system and found an old usenet post from Bear indicating he had been = also looking and finally found the files. I e-mailed him not really expecting= a response (since the posting was a few years old by then). Not only did he = respond, he also sent me the ECU disk and I was able to get the system up and= running. I know Bear does frequent the list and he posts here once in a whi= le. He may have just missed those emails. Maybe do a search of the archive an= d make sure you are using a current email of his? >=20 > -Ali >=20 >=20 >=20 --===============1286828269091970695==-- From cam.k801@gmail.com Fri Dec 13 23:36:17 2024 From: Cameron Kelly To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Fri, 13 Dec 2024 18:36:00 -0500 Message-ID: <5C6C42B0-08DC-4532-8AC5-5415A3CECD1E@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5686308755208530425==" --===============5686308755208530425== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Would it be possible to do something like this myself? I=E2=80=99ve been high= ly advised to get someone who knows what they are doing, do it but some other= people seem to imply that as long as the right precautions are taken place t= hen it=E2=80=99s alright to do it yourself.=20 I have a drive but have no experience using it.=20 Sent from my iPhone > On Dec 13, 2024, at 1:37 AM, Scott Baker via cctalk wrote: >=20 > =EF=BB=BFAgree with seeking out AJ. Either he or Chuck were the ones who to= ld me how > to do it. >=20 > I was able to successfully read a few tapes by using a SCSI QIC drive and > reading a tape under linux. Two things to beware of are that 1) the rubber > rollers in old QIC drives will sometimes turn to sticky goo, and 2) the > tension bands inside the tapes themselves will sometimes break. Back when I > was pursuing these QIC tapes as a hobby a couple years ago, I found that > most of the new tapes I found had tension bands either broken or that broke > immediately on use. Brand new tapes still in shrinkwrap, from multiple > manufacturers. Both of these problems are solvable with appropriate caution > (AJ has a video; VCF hass some threads). >=20 > QIC did seem to have its niche in software distribution, for things that > were too big/inconvenient for floppies, before CDs came out. >=20 > Scott >=20 >> On Thu, Dec 12, 2024 at 8:40=E2=80=AFPM Chuck Guzis via cctalk < >> cctalk(a)classiccmp.org> wrote: >>=20 >>> On 12/12/24 19:13, Cameron Kelly via cctalk wrote: >>> Hello, >>>=20 >>> I have a QIC tape of an interesting piece of software that doesn=E2=80=99= t seem >> to be archived anywhere. I don=E2=80=99t have experience using QIC tape so= I=E2=80=99m >> inquiring if anyone here would be willing to offer the service. The >> software in question is =E2=80=9CCorelDraw For Unix=E2=80=9D. >>>=20 >> I do quite a few quarter-inch cartridges as part of my business. >>=20 >> There's an incredible variety of formats; for example, Iotamat carts >> look just like a DC600 cartridge, but do not use optical sensing--BOT/ET >> etc is all recorded as special patterns on the tape. >>=20 >> If you get stuck, I'd be happy to have a look at the tape. >>=20 >> --Chuck >>=20 >>=20 --===============5686308755208530425==-- From wayne.sudol@hotmail.com Fri Dec 13 23:43:34 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Fri, 13 Dec 2024 23:43:27 +0000 Message-ID: In-Reply-To: <5C6C42B0-08DC-4532-8AC5-5415A3CECD1E@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6883256757588662637==" --===============6883256757588662637== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Is this the same software? Sent from my iPhone > On Dec 13, 2024, at 15:36, Cameron Kelly via cctalk wrote: >=20 > =EF=BB=BFWould it be possible to do something like this myself? I=E2=80=99v= e been highly advised to get someone who knows what they are doing, do it but= some other people seem to imply that as long as the right precautions are ta= ken place then it=E2=80=99s alright to do it yourself. >=20 > I have a drive but have no experience using it. >=20 > Sent from my iPhone >=20 >> On Dec 13, 2024, at 1:37 AM, Scott Baker via cctalk wrote: >>=20 >> =EF=BB=BFAgree with seeking out AJ. Either he or Chuck were the ones who t= old me how >> to do it. >>=20 >> I was able to successfully read a few tapes by using a SCSI QIC drive and >> reading a tape under linux. Two things to beware of are that 1) the rubber >> rollers in old QIC drives will sometimes turn to sticky goo, and 2) the >> tension bands inside the tapes themselves will sometimes break. Back when I >> was pursuing these QIC tapes as a hobby a couple years ago, I found that >> most of the new tapes I found had tension bands either broken or that broke >> immediately on use. Brand new tapes still in shrinkwrap, from multiple >> manufacturers. Both of these problems are solvable with appropriate caution >> (AJ has a video; VCF hass some threads). >>=20 >> QIC did seem to have its niche in software distribution, for things that >> were too big/inconvenient for floppies, before CDs came out. >>=20 >> Scott >>=20 >>> On Thu, Dec 12, 2024 at 8:40=E2=80=AFPM Chuck Guzis via cctalk < >>> cctalk(a)classiccmp.org> wrote: >>>=20 >>>>> On 12/12/24 19:13, Cameron Kelly via cctalk wrote: >>>>> Hello, >>>>>=20 >>>>> I have a QIC tape of an interesting piece of software that doesn=E2=80= =99t seem >>> to be archived anywhere. I don=E2=80=99t have experience using QIC tape s= o I=E2=80=99m >>> inquiring if anyone here would be willing to offer the service. The >>> software in question is =E2=80=9CCorelDraw For Unix=E2=80=9D. >>>>=20 >>> I do quite a few quarter-inch cartridges as part of my business. >>>=20 >>> There's an incredible variety of formats; for example, Iotamat carts >>> look just like a DC600 cartridge, but do not use optical sensing--BOT/ET >>> etc is all recorded as special patterns on the tape. >>>=20 >>> If you get stuck, I'd be happy to have a look at the tape. >>>=20 >>> --Chuck >>>=20 >>>=20 --===============6883256757588662637==-- From wayne.sudol@hotmail.com Fri Dec 13 23:45:39 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: QIC Archival Date: Fri, 13 Dec 2024 23:45:33 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCY4PR1001MB21819126E1CF1351823D496BE4382=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3942917638566998244==" --===============3942917638566998244== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Forgot the link winworldpc.com [X] Sent from my iPhone On Dec 13, 2024, at 15:43, Wayne S wrote: =EF=BB=BFIs this the same software? Sent from my iPhone On Dec 13, 2024, at 15:36, Cameron Kelly via cctalk = wrote: =EF=BB=BFWould it be possible to do something like this myself? I=E2=80=99ve = been highly advised to get someone who knows what they are doing, do it but s= ome other people seem to imply that as long as the right precautions are take= n place then it=E2=80=99s alright to do it yourself. I have a drive but have no experience using it. Sent from my iPhone On Dec 13, 2024, at 1:37 AM, Scott Baker via cctalk = wrote: =EF=BB=BFAgree with seeking out AJ. Either he or Chuck were the ones who told= me how to do it. I was able to successfully read a few tapes by using a SCSI QIC drive and reading a tape under linux. Two things to beware of are that 1) the rubber rollers in old QIC drives will sometimes turn to sticky goo, and 2) the tension bands inside the tapes themselves will sometimes break. Back when I was pursuing these QIC tapes as a hobby a couple years ago, I found that most of the new tapes I found had tension bands either broken or that broke immediately on use. Brand new tapes still in shrinkwrap, from multiple manufacturers. Both of these problems are solvable with appropriate caution (AJ has a video; VCF hass some threads). QIC did seem to have its niche in software distribution, for things that were too big/inconvenient for floppies, before CDs came out. Scott On Thu, Dec 12, 2024 at 8:40=E2=80=AFPM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: On 12/12/24 19:13, Cameron Kelly via cctalk wrote: Hello, I have a QIC tape of an interesting piece of software that doesn=E2=80=99t se= em to be archived anywhere. I don=E2=80=99t have experience using QIC tape so I= =E2=80=99m inquiring if anyone here would be willing to offer the service. The software in question is =E2=80=9CCorelDraw For Unix=E2=80=9D. I do quite a few quarter-inch cartridges as part of my business. There's an incredible variety of formats; for example, Iotamat carts look just like a DC600 cartridge, but do not use optical sensing--BOT/ET etc is all recorded as special patterns on the tape. If you get stuck, I'd be happy to have a look at the tape. --Chuck --===============3942917638566998244==-- From hupfadekroua@gmail.com Fri Dec 13 23:54:49 2024 From: hupfadekroua To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Sat, 14 Dec 2024 00:54:32 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0910929577498803069==" --===============0910929577498803069== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Look at https://winworldpc.com/library/operating-systems But the problem with privately operated sites could be, that they might vanis= h at some point. Andreas > Am 13.12.2024 um 21:47 schrieb Cameron Kelly via cctalk : >=20 > =EF=BB=BFI tried emailing the one that is on his site. >=20 >>=20 >> On Dec 13, 2024, at 2:58 PM, Ali wrote: >>=20 >> =EF=BB=BF >>>=20 >>> I can only conclude that >>> he >>> is someone who enjoys having a private collection and showing it off, >>> but >>> is entirely uninterested in sharing - or perhaps, playing well - with >>> others. >>>=20 >>> -Henry >>=20 >> That is a strange assumption. My experience has been totally different. Lo= ng before I got on this list or seriously into vintage computers I got my han= d on an Everex EISA system. I was looking everywhere for the CFG and OVL file= for the system and found an old usenet post from Bear indicating he had been= also looking and finally found the files. I e-mailed him not really expectin= g a response (since the posting was a few years old by then). Not only did he= respond, he also sent me the ECU disk and I was able to get the system up an= d running. I know Bear does frequent the list and he posts here once in a wh= ile. He may have just missed those emails. Maybe do a search of the archive a= nd make sure you are using a current email of his? >>=20 >> -Ali >>=20 >>=20 >>=20 --===============0910929577498803069==-- From d44617665@hotmail.com Sat Dec 14 01:34:26 2024 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: Seeking Remex RRS3300 Paper Tape Reader info Date: Sat, 14 Dec 2024 01:34:20 +0000 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1887680608122258016==" --===============1887680608122258016== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If anyone has info on this model, please reply or contact me. Thanks. I recorded video of my RRS3300 reading and winding. Since my initial post, I= discovered that the machine needed even more civilizing, and I ended up redu= cing the reeler speed from 200IPS to 100IPS. Link here: https://www.youtube.= com/watch?v=3DdmWAguLki6o . The spiral-wrapped cables at the top go to a mic= rocontroller, which reads the sprocket-hole signal and retards the phase cont= rol ramp. [https://www.bing.com/th?id=3DOVP.qNKj3Byj-dGoXSwjoQbt0AHgFo&pid=3DApi] Remex RRS3300 Paper Tape Reader Demonstrating my Remex RRS3300 paper tape reader, made in 1970 with discrete/= TTL/DTL technology. The 300cps reader section uses capstan drive and electrom= agnetic brake instead of a stepper and pinwheel. The spooler is permanent spl= it capacitor AC induction motors, electromagnetic brakes, relays (mechanical = and discrete solid-state ... www.youtube.com --===============1887680608122258016==-- From bfranchuk@jetnet.ab.ca Sat Dec 14 02:38:05 2024 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 13 Dec 2024 19:37:55 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1731011963725827971==" --===============1731011963725827971== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-12-13 4:54 p.m., hupfadekroua via cctalk wrote: > Look at https://winworldpc.com/library/operating-systems >=20 > But the problem with privately operated sites could be, that they might van= ish at some point. >=20 > Andreas And how is that different from a Commercial Site? Geo-cities comes to mind. The only thing worse is computer science books, same old stuff revised for the latest trend of the day. --===============1731011963725827971==-- From cc@informatik.uni-stuttgart.de Tue Dec 17 13:16:18 2024 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] List problems Date: Tue, 17 Dec 2024 14:16:05 +0100 Message-ID: <497c582d-6774-5dda-ff40-d77a42ccc083@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4691688223651906297==" --===============4691688223651906297== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Basically, this message is just a test. The list server seems to be utterly buggy and broken at the moment. What is the reason? Christian --===============4691688223651906297==-- From cc@informatik.uni-stuttgart.de Tue Dec 17 13:21:50 2024 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] List problems Date: Tue, 17 Dec 2024 14:21:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0937506129882632873==" --===============0937506129882632873== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit And worse, I do see some messages in the Mailman frontend, but I don't receive any email from the list server any more. Christian --===============0937506129882632873==-- From cc@informatik.uni-stuttgart.de Tue Dec 17 14:15:44 2024 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: List problems Date: Tue, 17 Dec 2024 15:15:13 +0100 Message-ID: In-Reply-To: <497c582d-6774-5dda-ff40-d77a42ccc083@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8492727341422283623==" --===============8492727341422283623== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 17 Dec 2024, Christian Corti wrote: > Basically, this message is just a test. > The list server seems to be utterly buggy and broken at the moment. What is > the reason? Two problems came at the same time here: 1. classiccmp went down 2. mail certificate chain got broken on my side Now both seem to be fixed again. Sorry for the noise :-) Christian --===============8492727341422283623==-- From paulkoning@comcast.net Tue Dec 17 16:19:10 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: List problems Date: Tue, 17 Dec 2024 11:10:55 -0500 Message-ID: <735B1D5E-D240-4CDD-B370-A737DFAD7309@comcast.net> In-Reply-To: <497c582d-6774-5dda-ff40-d77a42ccc083@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7845584274431131923==" --===============7845584274431131923== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I haven't seen "buggy and broken"... paul > On Dec 17, 2024, at 8:16 AM, Christian Corti via cctalk wrote: >=20 > Basically, this message is just a test. > The list server seems to be utterly buggy and broken at the moment. What is= the reason? >=20 > Christian --===============7845584274431131923==-- From cliendo@gmail.com Tue Dec 17 20:57:10 2024 From: Christian Liendo To: cctalk@classiccmp.org Subject: [cctalk] From Punch Cards to Python Grace =?utf-8?q?Hopper=E2=80=99?= =?utf-8?q?s?= A-0 compiler paved the way for modern programming languages Date: Tue, 17 Dec 2024 21:56:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6372606626284167795==" --===============6372606626284167795== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From Punch Cards to Python Grace Hopper’s A-0 compiler paved the way for modern programming languages https://spectrum.ieee.org/from-punch-cards-to-python --===============6372606626284167795==-- From aperry@snowmoose.com Wed Dec 18 18:29:06 2024 From: Alan Perry To: cctalk@classiccmp.org Subject: [cctalk] Any Burroughs B5000/A Series NEWP programmers out there? Date: Wed, 18 Dec 2024 10:18:46 -0800 Message-ID: <8F250F14-463A-4807-B7AC-6088303367E9@snowmoose.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8545947203713462876==" --===============8545947203713462876== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, Did any of you do NEWP programming on Burroughs/Unisys A Series systems? I will be attempting to put together some presentation material (for VCF or s= imilar talks) on MCP internals programming. However I haven=E2=80=99t done it= since 1989, so am looking for others who have experience in this area to hel= p me remember details. I took the MCP internals class and still have the class exercises and my note= s. Recently a A12/A15 Hardware Operations manual popped up on eBay. I scanned= it and submitted the scan to bitsavers. I am hoping to get my hands back on = some system architecture documents that I once had. So, if anyone here worked on this stuff and wants to help out on this, let me= know. alan --===============8545947203713462876==-- From billdegnan@gmail.com Wed Dec 18 19:47:54 2024 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Any Burroughs B5000/A Series NEWP programmers out there? Date: Wed, 18 Dec 2024 14:47:34 -0500 Message-ID: In-Reply-To: <8F250F14-463A-4807-B7AC-6088303367E9@snowmoose.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3987402125115700841==" --===============3987402125115700841== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There may be a Burroughs alumni group in the Phila area, it was big around here in the 60/70s Bill On Wed, Dec 18, 2024 at 2:08=E2=80=AFPM Alan Perry via cctalk wrote: > > Hey, > > Did any of you do NEWP programming on Burroughs/Unisys A Series systems? > > I will be attempting to put together some presentation material (for VCF > or similar talks) on MCP internals programming. However I haven=E2=80=99t d= one it > since 1989, so am looking for others who have experience in this area to > help me remember details. > > I took the MCP internals class and still have the class exercises and my > notes. Recently a A12/A15 Hardware Operations manual popped up on eBay. I > scanned it and submitted the scan to bitsavers. I am hoping to get my hands > back on some system architecture documents that I once had. > > So, if anyone here worked on this stuff and wants to help out on this, let > me know. > > alan > > --===============3987402125115700841==-- From epekstrom@gmail.com Thu Dec 19 14:41:57 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Trouble with DEQNA adapter Date: Thu, 19 Dec 2024 09:41:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7705047906216690961==" --===============7705047906216690961== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi all, This may be a dumb question but I am a bit stumped. I can't seem to find any helpful info in the manuals. I have a DEQNA installed in my 11/23+ and I have run a NETGEN using the QNA driver. When NETINS runs I start seeing messages like these on the console: Event type 5.14, Send failed Occurred 19-DEC-24 09:30:11 on node 10.1 (TYCHO) Line QNA-0 Failure reason = Collision detect check failed So obviously the link isn't working, but I find nothing helpful about where to start looking regarding the failed collision detect check. The line is on: NCP>show line qna-0 status Line status as of 19-DEC-24 09:36:31 Line State QNA-0 On I have an Ethernet transceiver (I have 2 and have tried both, they worked last time I used them) connected to the DEQNA harness, and a cable connecting it to an old 10Base-T hub. I know that hub works because I have a couple of other systems (OS/2 laptop and an AS/400) connected to it. So does anyone have any ideas of where I can start? Thanks in advance! Peter --===============7705047906216690961==-- From epekstrom@gmail.com Thu Dec 19 22:03:12 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: Trouble with DEQNA adapter Date: Thu, 19 Dec 2024 17:02:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0821178145997834887==" --===============0821178145997834887== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I just learned what SQE does. I had to enable it on my AUI and it seems the collision detection is happy now. -Peter On Thu, Dec 19, 2024 at 9:41 AM Peter Ekstrom wrote: > Hi all, > > This may be a dumb question but I am a bit stumped. I can't seem to find > any helpful info in the manuals. I have a DEQNA installed in my 11/23+ and > I have run a NETGEN using the QNA driver. When NETINS runs I start seeing > messages like these on the console: > > Event type 5.14, Send failed > Occurred 19-DEC-24 09:30:11 on node 10.1 (TYCHO) > Line QNA-0 > Failure reason = Collision detect check failed > > So obviously the link isn't working, but I find nothing helpful about > where to start looking regarding the failed collision detect check. The > line is on: > > NCP>show line qna-0 status > > Line status as of 19-DEC-24 09:36:31 > > Line State > > QNA-0 On > > I have an Ethernet transceiver (I have 2 and have tried both, they worked > last time I used them) connected to the DEQNA harness, and a cable > connecting it to an old 10Base-T hub. I know that hub works because I have > a couple of other systems (OS/2 laptop and an AS/400) connected to it. > > So does anyone have any ideas of where I can start? > > Thanks in advance! > Peter > --===============0821178145997834887==-- From paul.kimpel@digm.com Thu Dec 19 22:04:25 2024 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Any Burroughs B5000/A Series NEWP programmers out there? Date: Thu, 19 Dec 2024 22:04:21 +0000 Message-ID: <173464586140.1294.3884133033037281376@classiccmp.org> In-Reply-To: <8F250F14-463A-4807-B7AC-6088303367E9@snowmoose.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1523467859520906190==" --===============1523467859520906190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I haven't done any NEWP programming to speak of, but am still active with the= current successors to the A Series, now known as Unisys ClearPath MCP system= s. I am pretty familiar with the hardware architecture and the high-level asp= ects of the MCP architecture, and am still programming in ALGOL. I have a few= references for the internals, but they're woefully out of date. I'd be happy= to offer any assistance I can to your effort. --===============1523467859520906190==-- From imp@bsdimp.com Thu Dec 19 22:15:59 2024 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Trouble with DEQNA adapter Date: Thu, 19 Dec 2024 15:15:41 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4610573583799458014==" --===============4610573583799458014== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It's always SQE with thicknet. Too much or too little. On Thu, Dec 19, 2024, 3:03=E2=80=AFPM Peter Ekstrom via cctalk < cctalk(a)classiccmp.org> wrote: > I just learned what SQE does. I had to enable it on my AUI and it seems the > collision detection is happy now. > > -Peter > > On Thu, Dec 19, 2024 at 9:41=E2=80=AFAM Peter Ekstrom wrote: > > > Hi all, > > > > This may be a dumb question but I am a bit stumped. I can't seem to find > > any helpful info in the manuals. I have a DEQNA installed in my 11/23+ > and > > I have run a NETGEN using the QNA driver. When NETINS runs I start seeing > > messages like these on the console: > > > > Event type 5.14, Send failed > > Occurred 19-DEC-24 09:30:11 on node 10.1 (TYCHO) > > Line QNA-0 > > Failure reason =3D Collision detect check failed > > > > So obviously the link isn't working, but I find nothing helpful about > > where to start looking regarding the failed collision detect check. The > > line is on: > > > > NCP>show line qna-0 status > > > > Line status as of 19-DEC-24 09:36:31 > > > > Line State > > > > QNA-0 On > > > > I have an Ethernet transceiver (I have 2 and have tried both, they worked > > last time I used them) connected to the DEQNA harness, and a cable > > connecting it to an old 10Base-T hub. I know that hub works because I > have > > a couple of other systems (OS/2 laptop and an AS/400) connected to it. > > > > So does anyone have any ideas of where I can start? > > > > Thanks in advance! > > Peter > > > --===============4610573583799458014==-- From paulkoning@comcast.net Fri Dec 20 00:49:31 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Trouble with DEQNA adapter Date: Thu, 19 Dec 2024 19:41:14 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4441826718345215287==" --===============4441826718345215287== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Collision check test is, if I remember right, a feature that wasn't in the Et= hernet spec but got added by IEEE 802.3. So old transceivers may not have it= . In spite of what the event says, it's not a send failure because the SQE t= est signal occurs right after the packet is finished. If you have such a tra= nsceiver, you may want to look into disabling the check. Failing that, turn = off the event. If the transceiver does have SQE, then its failure might be due to a cable pr= oblem. Check the Ethernet cable. It needs to be terminated at both ends and= nowhere else :-) and it needs to be grounded at exactly one point. paul > On Dec 19, 2024, at 5:15 PM, Warner Losh via cctalk wrote: >=20 > It's always SQE with thicknet. Too much or too little. >=20 > On Thu, Dec 19, 2024, 3:03=E2=80=AFPM Peter Ekstrom via cctalk < > cctalk(a)classiccmp.org> wrote: >=20 >> I just learned what SQE does. I had to enable it on my AUI and it seems the >> collision detection is happy now. >>=20 >> -Peter >>=20 >> On Thu, Dec 19, 2024 at 9:41=E2=80=AFAM Peter Ekstrom wrote: >>=20 >>> Hi all, >>>=20 >>> This may be a dumb question but I am a bit stumped. I can't seem to find >>> any helpful info in the manuals. I have a DEQNA installed in my 11/23+ >> and >>> I have run a NETGEN using the QNA driver. When NETINS runs I start seeing >>> messages like these on the console: >>>=20 >>> Event type 5.14, Send failed >>> Occurred 19-DEC-24 09:30:11 on node 10.1 (TYCHO) >>> Line QNA-0 >>> Failure reason =3D Collision detect check failed >>>=20 >>> So obviously the link isn't working, but I find nothing helpful about >>> where to start looking regarding the failed collision detect check. The >>> line is on: >>>=20 >>> NCP>show line qna-0 status >>>=20 >>> Line status as of 19-DEC-24 09:36:31 >>>=20 >>> Line State >>>=20 >>> QNA-0 On >>>=20 >>> I have an Ethernet transceiver (I have 2 and have tried both, they worked >>> last time I used them) connected to the DEQNA harness, and a cable >>> connecting it to an old 10Base-T hub. I know that hub works because I >> have >>> a couple of other systems (OS/2 laptop and an AS/400) connected to it. >>>=20 >>> So does anyone have any ideas of where I can start? >>>=20 >>> Thanks in advance! >>> Peter >>>=20 >>=20 --===============4441826718345215287==-- From epekstrom@gmail.com Fri Dec 20 02:38:49 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: Trouble with DEQNA adapter Date: Thu, 19 Dec 2024 21:38:33 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4025610723939646199==" --===============4025610723939646199== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I have 3 AUIs: two 10BaseT and one 10Base2 (don't have any 10Base2 stuff anymore though). I tested with both the 10BaseT units and it so happens they both had SQE turned off. So after flipping the tiny switch to on, they both work and no more message. I used them with some old Sun Sparc IPC machines in the past and clearly they didn't care. So I must have turned them both off back then. I'm glad it was that simple. On Thu, Dec 19, 2024 at 7:49 PM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > Collision check test is, if I remember right, a feature that wasn't in the > Ethernet spec but got added by IEEE 802.3. So old transceivers may not > have it. In spite of what the event says, it's not a send failure because > the SQE test signal occurs right after the packet is finished. If you have > such a transceiver, you may want to look into disabling the check. Failing > that, turn off the event. > > If the transceiver does have SQE, then its failure might be due to a cable > problem. Check the Ethernet cable. It needs to be terminated at both ends > and nowhere else :-) and it needs to be grounded at exactly one point. > > paul > > > On Dec 19, 2024, at 5:15 PM, Warner Losh via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > It's always SQE with thicknet. Too much or too little. > > > > On Thu, Dec 19, 2024, 3:03 PM Peter Ekstrom via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > >> I just learned what SQE does. I had to enable it on my AUI and it seems > the > >> collision detection is happy now. > >> > >> -Peter > >> > >> On Thu, Dec 19, 2024 at 9:41 AM Peter Ekstrom > wrote: > >> > >>> Hi all, > >>> > >>> This may be a dumb question but I am a bit stumped. I can't seem to > find > >>> any helpful info in the manuals. I have a DEQNA installed in my 11/23+ > >> and > >>> I have run a NETGEN using the QNA driver. When NETINS runs I start > seeing > >>> messages like these on the console: > >>> > >>> Event type 5.14, Send failed > >>> Occurred 19-DEC-24 09:30:11 on node 10.1 (TYCHO) > >>> Line QNA-0 > >>> Failure reason = Collision detect check failed > >>> > >>> So obviously the link isn't working, but I find nothing helpful about > >>> where to start looking regarding the failed collision detect check. The > >>> line is on: > >>> > >>> NCP>show line qna-0 status > >>> > >>> Line status as of 19-DEC-24 09:36:31 > >>> > >>> Line State > >>> > >>> QNA-0 On > >>> > >>> I have an Ethernet transceiver (I have 2 and have tried both, they > worked > >>> last time I used them) connected to the DEQNA harness, and a cable > >>> connecting it to an old 10Base-T hub. I know that hub works because I > >> have > >>> a couple of other systems (OS/2 laptop and an AS/400) connected to it. > >>> > >>> So does anyone have any ideas of where I can start? > >>> > >>> Thanks in advance! > >>> Peter > >>> > >> > > --===============4025610723939646199==-- From paulkoning@comcast.net Fri Dec 20 19:15:50 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Trouble with DEQNA adapter Date: Fri, 20 Dec 2024 14:15:42 -0500 Message-ID: <4A22F2F4-C585-43BE-94E6-8F7197E35079@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1033196150173683807==" --===============1033196150173683807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Collision detect check failure is a warning, not a send failure -- the messag= e is misleading There are several possible causes. 1. The transceiver predates SQE check, it doesn't implement the signal. If s= o, turn off the message, you're fine. 2. The transceiver can do SQE but it's turned off. Turn it on. 3. The collision signal circuitry in the transceiver is broken. Or the colli= sion wires in the transceiver cable are. If so, on a half-duplex link with s= everal other stations on it all busy talking, you might see lost packets, and= the other stations would likely be reporting "late collision" errors. If so= , replace the cable or transceiver. I'm not sure if a bad coax segment (not properly terminated or damaged cable)= can do this, or if it would only cause false collision signals which is a di= fferent message. BTW, in all these cases you're probably communicating just fine. For 1 and 2= , no one else would be reporting any errors. Also: if your collision counts = are non-zero it's not #3. paul > On Dec 19, 2024, at 9:41 AM, Peter Ekstrom via cctalk wrote: >=20 > Hi all, >=20 > This may be a dumb question but I am a bit stumped. I can't seem to find > any helpful info in the manuals. I have a DEQNA installed in my 11/23+ and > I have run a NETGEN using the QNA driver. When NETINS runs I start seeing > messages like these on the console: >=20 > Event type 5.14, Send failed > Occurred 19-DEC-24 09:30:11 on node 10.1 (TYCHO) > Line QNA-0 > Failure reason =3D Collision detect check failed >=20 > So obviously the link isn't working, but I find nothing helpful about where > to start looking regarding the failed collision detect check. The line is > on: >=20 > NCP>show line qna-0 status >=20 > Line status as of 19-DEC-24 09:36:31 >=20 > Line State >=20 > QNA-0 On >=20 > I have an Ethernet transceiver (I have 2 and have tried both, they worked > last time I used them) connected to the DEQNA harness, and a cable > connecting it to an old 10Base-T hub. I know that hub works because I have > a couple of other systems (OS/2 laptop and an AS/400) connected to it. >=20 > So does anyone have any ideas of where I can start? >=20 > Thanks in advance! > Peter --===============1033196150173683807==-- From kevin.bowling@kev009.com Fri Dec 20 21:35:20 2024 From: Kevin Bowling To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 20 Dec 2024 14:35:01 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1991682895946489112==" --===============1991682895946489112== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Dec 12, 2024 at 7:58 PM Henry Bent via cctalk wrote: > > On Thu, 12 Dec 2024 at 21:37, Cameron Kelly via cctalk < > cctalk(a)classiccmp.org> wrote: > > > I have a QIC tape that I’m looking to get the contents off of and was > > pointed in bear’s direction and he’s ignored my emails too. > > > > I guess it is best not to bother him. > > > > I stumbled on his website many years ago and emailed him several times. > Like the rest of you, I never got a response. I can only conclude that he > is someone who enjoys having a private collection and showing it off, but > is entirely uninterested in sharing - or perhaps, playing well - with > others. It's a bit presumptuous to be generous with other people's time. I've transacted with him, no issues and he has a remarkable and particularly well maintained collection. He seems active on some web forums like VCF. Maybe the email is not working or overwhelmed. > -Henry --===============1991682895946489112==-- From kevin.bowling@kev009.com Fri Dec 20 21:39:49 2024 From: Kevin Bowling To: cctalk@classiccmp.org Subject: [cctalk] Digital lemac (de203) datasheet? Date: Fri, 20 Dec 2024 14:39:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0600939783255541129==" --===============0600939783255541129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Was a datasheet ever offered for the DEC 'lemac' series (de203/de204/de205)? Like the thing with all the registers and programming information not the installation guide. Regards, Kevin --===============0600939783255541129==-- From classiccmp@fjl.co.uk Fri Dec 20 22:55:14 2024 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 20 Dec 2024 22:35:23 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8499630786742974935==" --===============8499630786742974935== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20 December 2024 21:35:01 GMT, Kevin Bowling via cctalk wrote: >On Thu, Dec 12, 2024 at 7:58=E2=80=AFPM Henry Bent via cctalk > wrote: >> >> On Thu, 12 Dec 2024 at 21:37, Cameron Kelly via cctalk < >> cctalk(a)classiccmp.org> wrote: >> >> > I have a QIC tape that I=E2=80=99m looking to get the contents off of an= d was >> > pointed in bear=E2=80=99s direction and he=E2=80=99s ignored my emails t= oo. >> > >> > I guess it is best not to bother him. I have quite a few odd storage devices from Personal Computer World days. Man= ufacturers used to send them to me, and I kept the spares in my loft because = they might be useful one day. If your in no hurry I can keep my eyes open but my loft isn't organized. You = don't say what QIC it is. TR1-3 are very likely, others I couldn't say.=20 But it'd be a slow burn endeavour. Regards, Frank.=20 --===============8499630786742974935==-- From van.snyder@sbcglobal.net Sat Dec 21 00:36:31 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Print chain for 1403 Date: Fri, 20 Dec 2024 16:36:19 -0800 Message-ID: <818206f16180aa7b76563516d4b5752c0bcb1a9a.camel@sbcglobal.net> In-Reply-To: <818206f16180aa7b76563516d4b5752c0bcb1a9a.camel.ref@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4241485940210111556==" --===============4241485940210111556== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The IBM 1403 printer had interchangeable print chains. I know of only four 1403 printers still working — two at the Computer History Museum in Mountain View, CA, one at the IBM Technology Center in Böblingen, Germany, and one near Endicott, NY. All four have the 48-character "A" or "Business" chain, and CHM has a 16-character numeric chain that allows the printer to run twice as fast for numeric-only output. CHM doesn't have an "H" or "Fortran" chain, and as far as I know, none of the others do. The difference is that parentheses are % and "lozenge" — a square with indented edges — apostrophe is @, and = is # on the "A" chain. IBM also had a 64- character chain that included box and line drawing graphics. BTW, nobody seems to know what "lozenge" was meant to represent. Does anybody know of an existing "H" chain or graphics chain for a 1403? Van Snyder --===============4241485940210111556==-- From cclist@sydex.com Sat Dec 21 01:42:11 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 01:35:56 +0000 Message-ID: <60d0fb14-3526-4023-a78a-8ed152863856@sydex.com> In-Reply-To: <818206f16180aa7b76563516d4b5752c0bcb1a9a.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1579422440375652100==" --===============1579422440375652100== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/20/24 16:36, Van Snyder via cctalk wrote: > The IBM 1403 printer had interchangeable print chains. I know of only > four 1403 printers still working — two at the Computer History Museum > in Mountain View, CA, one at the IBM Technology Center in Böblingen, > Germany, and one near Endicott, NY. > > All four have the 48-character "A" or "Business" chain, and CHM has a > 16-character numeric chain that allows the printer to run twice as fast > for numeric-only output. CHM doesn't have an "H" or "Fortran" chain, > and as far as I know, none of the others do. The difference is that > parentheses are % and "lozenge" — a square with indented edges > — apostrophe is @, and = is # on the "A" chain. IBM also had a 64- > character chain that included box and line drawing graphics. BTW, > nobody seems to know what "lozenge" was meant to represent. I recall only learning once not to leave a cup of coffee atop a running 1403. I think the lozenge-character print train was mostly used on the BCD machines like the 1401, but I could be mistaken. I recall one of the old timers at CDC relating that try as they might, they couldn't get a train printer of their own design without the print train disintegrating. I believe that CDC quietly purchased a 1403 on the gray market and took it to pieces. The result was the CDC 512. Up until this time, the standard high-speed printer at CDC was the 501--a drum printer. It was interesting to note that hammer firing differences on a drum printer resulted in characters being vertically displaced, which was very annoying to the eye. Whereas the train printers could displace characters horizontally and was not nearly as unsightly. --Chuck --===============1579422440375652100==-- From jeffrey@vcfed.org Sat Dec 21 01:49:47 2024 From: Jeffrey Brace To: cctalk@classiccmp.org Subject: [cctalk] VCF East 2025 - April 4-6, Wall, NJ - Exhibitor Registration Date: Fri, 20 Dec 2024 20:49:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8413014363601271258==" --===============8413014363601271258== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable VCF East 2025 Exhibitor Registration is open: https://docs.google.com/forms/d/e/1FAIpQLSedyn-m5gSCc0Sifce0O_HnVYtWu7s9u7D7J= xPzFLHjyxcMbg/viewform?usp=3Dsf_link The show will be April 4-6 in Wall, NJ @ InfoAge Science and History Museums Check the web page for updates over the next few weeks https://vcfed.org/events/vintage-computer-festival-east/ --===============8413014363601271258==-- From phb.hfx@gmail.com Sat Dec 21 03:39:35 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Fri, 20 Dec 2024 23:39:25 -0400 Message-ID: <2a28a85f-cbaf-4c4a-b787-fcda1f1b2257@gmail.com> In-Reply-To: <60d0fb14-3526-4023-a78a-8ed152863856@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5599816911054242941==" --===============5599816911054242941== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-20 21:35, Chuck Guzis via cctalk wrote: > On 12/20/24 16:36, Van Snyder via cctalk wrote: >> The IBM 1403 printer had interchangeable print chains. I know of only >> four 1403 printers still working — two at the Computer History Museum >> in Mountain View, CA, one at the IBM Technology Center in Böblingen, >> Germany, and one near Endicott, NY. >> >> All four have the 48-character "A" or "Business" chain, and CHM has a >> 16-character numeric chain that allows the printer to run twice as fast >> for numeric-only output. CHM doesn't have an "H" or "Fortran" chain, >> and as far as I know, none of the others do. The difference is that >> parentheses are % and "lozenge" — a square with indented edges >> — apostrophe is @, and = is # on the "A" chain. IBM also had a 64- >> character chain that included box and line drawing graphics. BTW, >> nobody seems to know what "lozenge" was meant to represent. > I recall only learning once not to leave a cup of coffee atop a running > 1403. I think the lozenge-character print train was mostly used on the > BCD machines like the 1401, but I could be mistaken. > > I recall one of the old timers at CDC relating that try as they might, > they couldn't get a train printer of their own design without the print > train disintegrating. I believe that CDC quietly purchased a 1403 on > the gray market and took it to pieces. The result was the CDC 512. Up > until this time, the standard high-speed printer at CDC was the 501--a > drum printer. > > It was interesting to note that hammer firing differences on a drum > printer resulted in characters being vertically displaced, which was > very annoying to the eye. Whereas the train printers could displace > characters horizontally and was not nearly as unsightly. > > --Chuck > The chain with box drawing characters mention in the original post where used to print the ALD.  The 1403 had logic that limited the number of hammers that could fire at once, there was a test routine that would repeatedly fire the maximum number of hammers it was called the "Chain Breaker Routine".  The only drum printer I ever saw operating I think it was a Honeywell printer and the person demoing it printed out some pictures, the printer could fire most if not all hammers at once which made quite a racket. Paul. --===============5599816911054242941==-- From norwayjose@mac.com Sat Dec 21 13:23:13 2024 From: Rod Bartlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 08:15:59 -0500 Message-ID: In-Reply-To: <2a28a85f-cbaf-4c4a-b787-fcda1f1b2257@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0727414564545347644==" --===============0727414564545347644== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Dec 20, 2024, at 10:39=E2=80=AFPM, Paul Berger via cctalk wrote: >=20 > The chain with box drawing characters mention in the original post where us= ed to print the ALD. The 1403 had logic that limited the number of hammers t= hat could fire at once, there was a test routine that would repeatedly fire t= he maximum number of hammers it was called the "Chain Breaker Routine". The = only drum printer I ever saw operating I think it was a Honeywell printer and= the person demoing it printed out some pictures, the printer could fire most= if not all hammers at once which made quite a racket. >=20 > Paul. As a field engineer for Honeywell, I always dreaded the holidays because so m= any people would launch print jobs which used repeated overstrikes to create = pictures. Those jobs sometimes fired the maximum number of hammers at a time= to speed up the picture creation which would sometimes cause multiple hammer= actuator fuses to blow. More than once I had to buy all the 2 amp fuses fro= m multiple Radio Shacks to get the printer operational again. Those overstri= kes also caused the paper to become more saturated with ink which resulted in= more paper/ink residue getting deposited in the print chain, which required = heavier than normal cleanings during the next preventative maintenance window. Another thing which caused more work for field engineers around the holidays = were jobs sent to the card punches to play Jingle Bells by punching fully lac= ed cards in time to the music. It was entertaining unless they caused card j= ams too bad for the operators to be able to clear by themselves. Fully laced= punch cards are too flexible to pass through the punch path cleanly. - Rod --===============0727414564545347644==-- From cctalk@emailtoilet.com Sat Dec 21 13:53:09 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 13:53:01 +0000 Message-ID: <173478918102.1294.11658563220844798378@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2648308479780629434==" --===============2648308479780629434== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Rod Bartlett wrote: > > On Dec 20, 2024, at 10:39=E2=80=AFPM, Paul Berger via cctalk > > <cctalk(a)classiccmp.org> wrote: > > =20 > > The chain with box drawing characters mention in the original post where= used to print > > the ALD. The 1403 had logic that limited the number of hammers that coul= d fire at once, > > there was a test routine that would repeatedly fire the maximum number of= hammers it was > > called the "Chain Breaker Routine". The only drum printer I ever saw ope= rating > > I think it was a Honeywell printer and the person demoing it printed out = some pictures, > > the printer could fire most if not all hammers at once which made quite a= racket. > > =20 > > Paul.=20 > As a field engineer for Honeywell, I always dreaded the holidays because so= many people > would launch print jobs which used repeated overstrikes to create pictures.= Those jobs > sometimes fired the maximum number of hammers at a time to speed up the pic= ture creation > which would sometimes cause multiple hammer actuator fuses to blow. More t= han once I had > to buy all the 2 amp fuses from multiple Radio Shacks to get the printer op= erational > again. Those overstrikes also caused the paper to become more saturated wi= th ink which > resulted in more paper/ink residue getting deposited in the print chain, wh= ich required > heavier than normal cleanings during the next preventative maintenance wind= ow. >=20 > Another thing which caused more work for field engineers around the holiday= s were jobs > sent to the card punches to play Jingle Bells by punching fully laced cards= in time to the > music. It was entertaining unless they caused card jams too bad for the op= erators to be > able to clear by themselves. Fully laced punch cards are too flexible to p= ass through the > punch path cleanly. >=20 > - Rod You mean like this? https://www.ibmjunkman.com/cards/?Holder=3D6309&Img=3D1 --===============2648308479780629434==-- From norwayjose@mac.com Sat Dec 21 14:49:09 2024 From: Rod Bartlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 09:49:00 -0500 Message-ID: In-Reply-To: <173478918102.1294.11658563220844798378@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0114213914599587565==" --===============0114213914599587565== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Dec 21, 2024, at 8:53=E2=80=AFAM, Donald Whittemore via cctalk wrote: >=20 > Rod Bartlett wrote: >>>=20 >> As a field engineer for Honeywell, I always dreaded the holidays because s= o many people >> would launch print jobs which used repeated overstrikes to create pictures= . Those jobs >> sometimes fired the maximum number of hammers at a time to speed up the pi= cture creation >> which would sometimes cause multiple hammer actuator fuses to blow. More = than once I had >> to buy all the 2 amp fuses from multiple Radio Shacks to get the printer o= perational >> again. Those overstrikes also caused the paper to become more saturated w= ith ink which >> resulted in more paper/ink residue getting deposited in the print chain, w= hich required >> heavier than normal cleanings during the next preventative maintenance win= dow. >>=20 >> Another thing which caused more work for field engineers around the holida= ys were jobs >> sent to the card punches to play Jingle Bells by punching fully laced card= s in time to the >> music. It was entertaining unless they caused card jams too bad for the o= perators to be >> able to clear by themselves. Fully laced punch cards are too flexible to = pass through the >> punch path cleanly. >>=20 >> - Rod >=20 > You mean like this? > https://www.ibmjunkman.com/cards/?Holder=3D6309&Img=3D1 That's it. As far as I know, fully laced cards were only useful for producin= g a deep percussive sound while punching the card. Trying to push cards rend= ered flexible by so many holes at 300 cards per minute caused some spectacula= r card jams which occasionally required partial disassembly to fully clear. --===============0114213914599587565==-- From frank@fjl.co.uk Sat Dec 21 17:04:11 2024 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: very old UNIXes software, contact at typewritten? Date: Fri, 20 Dec 2024 22:25:09 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2631027556726924854==" --===============2631027556726924854== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 20 December 2024 21:35:01 GMT, Kevin Bowling via cctalk wrote: >On Thu, Dec 12, 2024 at 7:58=E2=80=AFPM Henry Bent via cctalk > wrote: >> >> On Thu, 12 Dec 2024 at 21:37, Cameron Kelly via cctalk < >> cctalk(a)classiccmp.org> wrote: >> >> > I have a QIC tape that I=E2=80=99m looking to get the contents off of an= d was >> > pointed in bear=E2=80=99s direction and he=E2=80=99s ignored my emails t= oo. >> > >> > I guess it is best not to bother him. I have quite a few odd storage devices from Personal Computer World days. Man= ufacturers used to send them to me, and I kept the spares in my loft because = they might be useful one day. If your in no hurry I can keep my eyes open but my loft isn't organized. You = don't say what QIC it is. TR1-3 are very likely, others I couldn't say.=20 But it'd be a slow burn endeavour. Regards, Frank.=20 --===============2631027556726924854==-- From elson@pico-systems.com Sat Dec 21 17:07:42 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 11:07:33 -0600 Message-ID: In-Reply-To: <818206f16180aa7b76563516d4b5752c0bcb1a9a.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2695817586236820895==" --===============2695817586236820895== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/20/24 18:36, Van Snyder via cctalk wrote: > The IBM 1403 printer had interchangeable print chains. I know of only > four 1403 printers still working — two at the Computer History Museum > in Mountain View, CA, one at the IBM Technology Center in Böblingen, > Germany, and one near Endicott, NY. > > All four have the 48-character "A" or "Business" chain, and CHM has a > 16-character numeric chain that allows the printer to run twice as fast > for numeric-only output. CHM doesn't have an "H" or "Fortran" chain, > and as far as I know, none of the others do. The difference is that > parentheses are % and "lozenge" — a square with indented edges > — apostrophe is @, and = is # on the "A" chain. IBM also had a 64- > character chain that included box and line drawing graphics. BTW, > nobody seems to know what "lozenge" was meant to represent. > > Does anybody know of an existing "H" chain or graphics chain for a > 1403? > > Van Snyder My understanding is that the 1403 N1 used a "train" and the 1403 N3 used a chain.  I have seen a 1403 N1 train up close, and there was no chain that connected the type blocks, 2 characters to a block. Jon --===============2695817586236820895==-- From elson@pico-systems.com Sat Dec 21 17:20:07 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 11:19:57 -0600 Message-ID: <06a1eb9b-a496-6d7a-d882-ad839c048dab@pico-systems.com> In-Reply-To: <2a28a85f-cbaf-4c4a-b787-fcda1f1b2257@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5299626214475102139==" --===============5299626214475102139== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/20/24 21:39, Paul Berger via cctalk wrote: > > The chain with box drawing characters mention in the > original post where used to print the ALD.  The 1403 had > logic that limited the number of hammers that could fire > at once, there was a test routine that would repeatedly > fire the maximum number of hammers it was called the > "Chain Breaker Routine".  The only drum printer I ever saw > operating I think it was a Honeywell printer and the > person demoing it printed out some pictures, the printer > could fire most if not all hammers at once which made > quite a racket. > > Paul. > > I had a BIG Honeywell drum printer on my S-100 Z80 system.  It was from a system used to print from tapes, offline.  It had some odd characters for making boxes on printed forms.  There were shift registers that controlled the hammer transistors in pairs. Even column characters on the drum lined up with the hammers alternately with the odd columns.  The same driver transistor was used for adjacent hammers, but the hammers were actually fired by big SCRs that alternately powered two power rails.  The SCRs were commutated by big Germanium transistors.  While getting this beast running, I managed to disconnect an important signal cable and it caused all hammers to fire every character time, and the hammers pounded the thin metal shield in front of them.  The noise could probably have been heard a block away!  It also blew out the commutating transistors.  I was able to replace them with some TO-3 transistors out of my junk box, and it worked fine for the rest of the time I had it.  I did use overprints to create some of the extended ASCII characters, so my Pascal listings could only be read by me.  Such things as curly braces were overprints of ( and <, for instance.  If you printed a full line of * or _ it made a loud "bump" noise! Jon --===============5299626214475102139==-- From elson@pico-systems.com Sat Dec 21 17:26:44 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 11:26:36 -0600 Message-ID: In-Reply-To: <173478918102.1294.11658563220844798378@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1215828445100248311==" --===============1215828445100248311== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 12/21/24 07:53, Donald Whittemore via cctalk wrote: > Rod Bartlett wrote: >>> On Dec 20, 2024, at 10:39=E2=80=AFPM, Paul Berger via cctalk >>> <cctalk(a)classiccmp.org> wrote: >>> =20 >>> The chain with box drawing characters mention in the original post wher= e used to print >>> the ALD. The 1403 had logic that limited the number of hammers that coul= d fire at once, >>> there was a test routine that would repeatedly fire the maximum number of= hammers it was >>> called the "Chain Breaker Routine". The only drum printer I ever saw ope= rating >>> I think it was a Honeywell printer and the person demoing it printed out = some pictures, >>> the printer could fire most if not all hammers at once which made quite a= racket. >>> =20 >>> Paul. >> As a field engineer for Honeywell, I always dreaded the holidays because s= o many people >> would launch print jobs which used repeated overstrikes to create pictures= . Those jobs >> sometimes fired the maximum number of hammers at a time to speed up the pi= cture creation >> which would sometimes cause multiple hammer actuator fuses to blow. More = than once I had >> to buy all the 2 amp fuses from multiple Radio Shacks to get the printer o= perational >> again. Those overstrikes also caused the paper to become more saturated w= ith ink which >> resulted in more paper/ink residue getting deposited in the print chain, w= hich required >> heavier than normal cleanings during the next preventative maintenance win= dow. >> >> Another thing which caused more work for field engineers around the holida= ys were jobs >> sent to the card punches to play Jingle Bells by punching fully laced card= s in time to the >> music. It was entertaining unless they caused card jams too bad for the o= perators to be >> able to clear by themselves. Fully laced punch cards are too flexible to = pass through the >> punch path cleanly. >> >> - Rod > You mean like this? > https://www.ibmjunkman.com/cards/?Holder=3D6309&Img=3D1 I made these by hand on a 514AD duplicating card punch.=C2=A0 I=20 would make cards on a regular keypunch with 4 rows of holes=20 (all the same character 80 times), such that when flipped=20 and run through the duplicator 3 times onto the same output=20 deck, it would punch all holes.=C2=A0 Occasionally the 514 would=20 jam, but it was not that hard to open up and clean out. Jon --===============1215828445100248311==-- From g4ajq1@gmail.com Sat Dec 21 17:42:48 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 12:42:29 -0500 Message-ID: <5f5a19a9-b501-4327-84a3-30a894aa74cb@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4896604643263057432==" --===============4896604643263057432== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-12-21 09:49, Rod Bartlett via cctalk wrote: >> On Dec 21, 2024, at 8:53=E2=80=AFAM, Donald Whittemore via cctalk wrote: >> >> Rod Bartlett wrote: >>> As a field engineer for Honeywell, I always dreaded the holidays because = so many people >>> would launch print jobs which used repeated overstrikes to create picture= s. Those jobs >>> sometimes fired the maximum number of hammers at a time to speed up the p= icture creation >>> which would sometimes cause multiple hammer actuator fuses to blow. More= than once I had >>> to buy all the 2 amp fuses from multiple Radio Shacks to get the printer = operational >>> again. Those overstrikes also caused the paper to become more saturated = with ink which >>> resulted in more paper/ink residue getting deposited in the print chain, = which required >>> heavier than normal cleanings during the next preventative maintenance wi= ndow. >>> >>> Another thing which caused more work for field engineers around the holid= ays were jobs >>> sent to the card punches to play Jingle Bells by punching fully laced car= ds in time to the >>> music. It was entertaining unless they caused card jams too bad for the = operators to be >>> able to clear by themselves. Fully laced punch cards are too flexible to= pass through the >>> punch path cleanly. >>> >>> - Rod >> You mean like this? >> https://www.ibmjunkman.com/cards/?Holder=3D6309&Img=3D1 > That's it. As far as I know, fully laced cards were only useful for produc= ing a deep percussive sound while punching the card. Trying to push cards re= ndered flexible by so many holes at 300 cards per minute caused some spectacu= lar card jams which occasionally required partial disassembly to fully clear. > > You're lucky, Rod.=C2=A0 When I was a trainee FE at a Univac site, we had a=20 smart instructor that accidentally managed to block the reset signal of=20 the hammers on a 1004 drum printer.=C2=A0 All 132 columns struck the drum,=20 gouged the surface, and blew hundreds of power transistors!=C2=A0 Univac had = to fly parts (and an FE) from all around the world to get us going.=C2=A0=C2= =A0=20 The sad part is that the 1004 was used for billing blue chip companies=20 that used our store-and-forward message switcher (using teletype=20 machines)! After that episode, they bought another 1004 for the backup=20 system! Oh! The memories! cheers, Nigel --=20 Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============4896604643263057432==-- From sqrfolkdnc@comcast.net Sat Dec 21 17:50:03 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 11:41:47 -0600 Message-ID: <1873252823.858365.1734802907018@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7261648391853396807==" --===============7261648391853396807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable my recollection from being a computer operator at the time was the the earlie= r 1403s did NOT have an interchangeable chain. Also curious if any 1404 printers still exist. They were wider and you could = shift the print mechanism to the side where there was a mechanisms to print o= n tabulating cards, one or two at a time. 
--Carey
> On 12/21/2024 11:07 AM CST Jon Elson via cctalk w= rote: >=20 > =20 > On 12/20/24 18:36, Van Snyder via cctalk wrote: > > The IBM 1403 printer had interchangeable print chains. I know of only > > four 1403 printers still working =E2=80=94 two at the Computer History Mu= seum > > in Mountain View, CA, one at the IBM Technology Center in B=C3=B6blingen, > > Germany, and one near Endicott, NY. > > > > All four have the 48-character "A" or "Business" chain, and CHM has a > > 16-character numeric chain that allows the printer to run twice as fast > > for numeric-only output. CHM doesn't have an "H" or "Fortran" chain, > > and as far as I know, none of the others do. The difference is that > > parentheses are % and "lozenge"=C2=A0=E2=80=94 a square with indented edg= es > > =E2=80=94=C2=A0apostrophe is @, and =3D is # on the "A" chain. IBM also h= ad a 64- > > character chain that included box and line drawing graphics. BTW, > > nobody seems to know what "lozenge" was meant to represent. > > > > Does anybody know of an existing "H" chain or graphics chain for a > > 1403? > > > > Van Snyder --===============7261648391853396807==-- From cclist@sydex.com Sat Dec 21 18:30:10 2024 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 18:29:58 +0000 Message-ID: <88499e29-c7ec-46ea-bf22-5e8092de3dc4@sydex.com> In-Reply-To: <06a1eb9b-a496-6d7a-d882-ad839c048dab@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7461221243641930290==" --===============7461221243641930290== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/21/24 09:19, Jon Elson via cctalk wrote: > I had a BIG Honeywell drum printer on my S-100 Z80 system.  It was from > a system used to print from tapes, offline. Just wondering if anyone but yours truly used the Teletype Dataspeed 40 band printer on their PCs. 150 LPM if memory serves. I still have the schematics for the thing. I ditched mine along with my daisywheel printer when laser printers became the state of the art. --Chuck --===============7461221243641930290==-- From paulkoning@comcast.net Sat Dec 21 20:30:54 2024 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 15:30:45 -0500 Message-ID: In-Reply-To: <1873252823.858365.1734802907018@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4575305872058125491==" --===============4575305872058125491== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Dec 21, 2024, at 12:41 PM, CAREY SCHUG via cctalk wrote: >=20 > my recollection from being a computer operator at the time was the the earl= ier 1403s did NOT have an interchangeable chain. Interesting. I was an occasional operator on a 360 model 44 in 1974, and it = had an interchangeable chain. That installation had several, including an up= per/lower case one (TN perhaps) which I used to print one of my college paper= s (formatted with RUNOFF on a PDP-11 system, carried to the 360 on tape and p= rinted there). The printer also had a film ribbon, basically a 17 inch wide = version of the ribbons used on Selectric typewriters for quality work. > Also curious if any 1404 printers still exist. They were wider and you coul= d shift the print mechanism to the side where there was a mechanisms to print= on tabulating cards, one or two at a time. Speaking of wider: I remember the curious line printers on the Electrologica = computer at TU Eindhoven, where I did my first programming. Those had 144 co= lumns, though I think the paper was the usual 17 inches wide. I don't have a= ny of those printouts anymore, unfortunately. paul --===============4575305872058125491==-- From van.snyder@sbcglobal.net Sat Dec 21 21:22:15 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 13:22:04 -0800 Message-ID: <04d3d21b3a6c79c7b2894a795d06d3b1d06f826d.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4861871182640318296==" --===============4861871182640318296== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2024-12-21 at 11:07 -0600, Jon Elson via cctalk wrote: > On 12/20/24 18:36, Van Snyder via cctalk wrote: > > The IBM 1403 printer had interchangeable print chains. I know of > > only > > four 1403 printers still working — two at the Computer History > > Museum > > in Mountain View, CA, one at the IBM Technology Center in > > Böblingen, > > Germany, and one near Endicott, NY. > > > > All four have the 48-character "A" or "Business" chain, and CHM has > > a > > 16-character numeric chain that allows the printer to run twice as > > fast > > for numeric-only output. CHM doesn't have an "H" or "Fortran" > > chain, > > and as far as I know, none of the others do. The difference is that > > parentheses are % and "lozenge" — a square with indented edges > > — apostrophe is @, and = is # on the "A" chain. IBM also had a 64- > > character chain that included box and line drawing graphics. BTW, > > nobody seems to know what "lozenge" was meant to represent. > > > > Does anybody know of an existing "H" chain or graphics chain for a > > 1403? > > > > Van Snyder > > My understanding is that the 1403 N1 used a "train" and the > 1403 N3 used a chain.  I have seen a 1403 N1 train up close, > and there was no chain that connected the type blocks, 2 > characters to a block. The 1403s at the Computer History Museum definitely have chains, not trains. > > Jon > --===============4861871182640318296==-- From sqrfolkdnc@comcast.net Sat Dec 21 21:54:31 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sat, 21 Dec 2024 15:46:17 -0600 Message-ID: <825649438.861475.1734817577528@connect.xfinity.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6937721910374819895==" --===============6937721910374819895== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Remember, it is called the 1403 because it was originally built for the 1401 = computer. IIRC there were several iterations of speed before the 360 came out, and the = N1 with the power lid and sound baffling. from AI:=20 No, not all IBM 1403 printers had interchangeable type chains: Note that while the IBM 1403 Models 2 and 7 do offer a feature known as the I= nterchangeable Train Cartridge Adapter, which allows the operator to easily r= emove and insert a chain cartridge with a different font or character set arr= angement, this feature does not have a separate machine type. Yes, I had forgotten the name, we had a TN chain we used for one or two jobs. The IBM 1443 printer could also do 144 columns. With the 1404 printer, one could install blocks to print on the shortie 51 co= lumn cards. We hated doing that, it did not fit well. 
--Carey
> On 12/21/2024 2:30 PM CST Paul Koning wrote: >=20 > =20 > > On Dec 21, 2024, at 12:41 PM, CAREY SCHUG via cctalk wrote: > >=20 > > my recollection from being a computer operator at the time was the the ea= rlier 1403s did NOT have an interchangeable chain. >=20 > Interesting. I was an occasional operator on a 360 model 44 in 1974, and i= t had an interchangeable chain. That installation had several, including an = upper/lower case one (TN perhaps) which I used to print one of my college pap= ers (formatted with RUNOFF on a PDP-11 system, carried to the 360 on tape and= printed there). The printer also had a film ribbon, basically a 17 inch wid= e version of the ribbons used on Selectric typewriters for quality work. >=20 > > Also curious if any 1404 printers still exist. They were wider and you co= uld shift the print mechanism to the side where there was a mechanisms to pri= nt on tabulating cards, one or two at a time. >=20 > Speaking of wider: I remember the curious line printers on the Electrologic= a computer at TU Eindhoven, where I did my first programming. Those had 144 = columns, though I think the paper was the usual 17 inches wide. I don't have= any of those printouts anymore, unfortunately. >=20 > paul --===============6937721910374819895==-- From jgeorge_cctalk@nbi6.com Sun Dec 22 00:17:09 2024 From: Joe George To: cctalk@classiccmp.org Subject: [cctalk] FTGH IBM 4245 Printer Bands Date: Sat, 21 Dec 2024 19:08:08 -0500 Message-ID: <45E0C0E9-AA5B-48B1-B363-34EEA3578D01@nbi6.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8691139129301030677==" --===============8691139129301030677== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Anyone have an IBM 4245 printer? I came into a box of NOS print bands and hav= e zero use for them. Don't want to hard them, don't want to throw them out. F= TGH, pitch in a couple of bucks for shipping and they're yours. I can get par= t numbers and quantities if there's interest. There's about a dozen of them a= nd I think they're all the same belt, but do not know for sure. --===============8691139129301030677==-- From jwsmail@jwsss.com Mon Dec 23 04:34:05 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Sun, 22 Dec 2024 22:26:39 -0600 Message-ID: In-Reply-To: <818206f16180aa7b76563516d4b5752c0bcb1a9a.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1866869859643107921==" --===============1866869859643107921== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/20/24 18:36, Van Snyder via cctalk wrote: > The IBM 1403 printer had interchangeable print chains. I know of only > four 1403 printers still working — two at the Computer History Museum > in Mountain View, CA, one at the IBM Technology Center in Böblingen, > Germany, and one near Endicott, NY. > > Van Snyder I don't know what chain we used at University of Mo, Rolla.  We had a 360/50 with 512K of memory and a 1mb LCS so could run a lot of stuff. they had Fortran H as well as the other compiler languages, would assume they had that chain.  I don't recall any changes of chains other than perhaps failures. The fun story I have was from when I was playing one night and had accidentally done a skip to channel, 12, which on our printer had no stops, so it would jet paper out as fast as it could go. The first run of it jammed a big mess in the back output feed.  The operator guy, Dennis Ditch asked me after he had cleaned up the mess if there were any other runs queued, and I thought there weren't. He had the back up, (mentioned in other posts could  mess up your time if you had something sitting on the case. Anyway people may recall that there was a set of controls on the back by the takeup, and he was sitting there when he asked me about the other runs.  The system was MVT and was running jobs w/o anyone attending the console of course. He went ahead and put it back online.  The thing that impressed me was that the paper flew over his head and didn't touch the floor for 20'.  Oops, guess it was still queue.  He hit the offline very quickly, but probably 30 or 40 pages were ejected, luckily not jamming the printer again. He left if offline and went over and killed that job, and checked that there weren't any others. thanks Jim --===============1866869859643107921==-- From phb.hfx@gmail.com Mon Dec 23 07:45:32 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 03:45:21 -0400 Message-ID: <96d30d5f-1fec-476f-9a56-247520fd6eea@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3021801115137460623==" --===============3021801115137460623== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-23 00:26, jim stephens via cctalk wrote: > I don't know what chain we used at University of Mo, Rolla.  We had a > 360/50 with 512K of memory and a 1mb LCS so could run a lot of stuff. > > they had Fortran H as well as the other compiler languages, would > assume they had that chain.  I don't recall any changes of chains > other than perhaps failures. > > The fun story I have was from when I was playing one night and had > accidentally done a skip to channel, 12, which on our printer had no > stops, so it would jet paper out as fast as it could go. > > The first run of it jammed a big mess in the back output feed. The > operator guy, Dennis Ditch asked me after he had cleaned up the mess > if there were any other runs queued, and I thought there weren't. He > had the back up, (mentioned in other posts could  mess up your time if > you had something sitting on the case. > > Anyway people may recall that there was a set of controls on the back > by the takeup, and he was sitting there when he asked me about the > other runs.  The system was MVT and was running jobs w/o anyone > attending the console of course. > > He went ahead and put it back online.  The thing that impressed me was > that the paper flew over his head and didn't touch the floor for 20'.  > Oops, guess it was still queue.  He hit the offline very quickly, but > probably 30 or 40 pages were ejected, luckily not jamming the printer > again. > > He left if offline and went over and killed that job, and checked that > there weren't any others. > > thanks > Jim The carriage control tapes had the sprocket holes dead center which lead to people putting them on backwards by accident  and since most people only used a couple channels for any given form, this would lead to paper runaways, as would neglecting to lower the brush block after mounting the carriage control tape. I once saw one of the large system CEs repairing a print train that the customer had neglected to fill the oiler and the train seized.  The filling the oiler was the customer's responsibility so the repair of the train was billable.  The type slugs I saw where not coupled together and had helical gear teeth on the bottom that coupled with a gear in the train that was driven by the motor.  I am not sure what model of 1403 this came from but it was one of the models that had covers that went all the way to the floor.  The print trains had a separate machine type and I seem to recall that the customer was obliged to purchase them even if the 1403 was leased.  The 3203 printer used the same print trains as 1403. Paul. --===============3021801115137460623==-- From nico@farumdata.dk Mon Dec 23 10:57:54 2024 From: Nico de Jong To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 10:11:15 +0100 Message-ID: <6d2bcef1-4684-4a9b-89d8-e62c2b8e0b70@farumdata.dk> In-Reply-To: <96d30d5f-1fec-476f-9a56-247520fd6eea@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8302379149773144606==" --===============8302379149773144606== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > > The carriage control tapes had the sprocket holes dead center which > lead to people putting them on backwards by accident  and since most > people only used a couple channels for any given form, this would lead > to paper runaways, as would neglecting to lower the brush block after > mounting the carriage control tape. > > I once saw one of the large system CEs repairing a print train that > the customer had neglected to fill the oiler and the train seized.  > The filling the oiler was the customer's responsibility so the repair > of the train was billable.  The type slugs I saw where not coupled > together and had helical gear teeth on the bottom that coupled with a > gear in the train that was driven by the motor.  I am not sure what > model of 1403 this came from but it was one of the models that had > covers that went all the way to the floor.  The print trains had a > separate machine type and I seem to recall that the customer was > obliged to purchase them even if the 1403 was leased.  The 3203 > printer used the same print trains as 1403. > > Paul. > When I was an operator, we once had a visit from a CE who had to repair the carriage control mechanism. In order to do that, he had to use a big screwdriver, and of course he lost it. It hit the 1403 N1's power supply, blew all fuses. This was not enough; the screwdrive hit obviously the plus and minus pole of the main capacitor (it's about 55 years ago), so the current was so large that, after the things had cooled down, he could lift the capactor out of the printer just by lifting the screwdriver It was by the way the same CE that got his tie wrapped up in the print chain.... The same company once had a bunch of visitors who were allowed to visit the machine room, which normally was a bit nono. One of the guests took his coffeecup with him, put it on top of the 1403, and while things were explained to the crowd, the cover lifted and .... well you can guess the rest. He was quite pisssed off, but it was his own fault Another thing I'll never forget, was the 2540. It had 5 bins, and the middle one could be used for accepting read cards and punched cards. Once an operated started to read cards while cards were being punched, and both routines used the middle bin. That is not to be recommended ! /Nico --===============8302379149773144606==-- From cctalk@emailtoilet.com Mon Dec 23 12:53:41 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 12:53:36 +0000 Message-ID: <173495841654.1294.12567103197130815149@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3969916699064859123==" --===============3969916699064859123== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The slug had 3 characters. I have a picture of one. --===============3969916699064859123==-- From cctalk@emailtoilet.com Mon Dec 23 13:04:08 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 13:04:02 +0000 Message-ID: <173495904257.1294.1556368278346218563@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7154609682939273859==" --===============7154609682939273859== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 1403 prior to 1403N1 used a chain. Plastic band with imbedded type slugs. Not= user modifiable. The thing that held it in the printer was user replaceable.= The N1 used a 1416 train cartridge. Also could be swapped by the operator. I= t had a gate that could be opened to remove/replace a slug. Looks like a CE w= ould have to do it. https://tangiblemediacollection.com/_images/typewriter-font/ibm-printer-chain= /ibm-printer-chain-5.jpg?ver=3D1661774460 The CHM 1403s use chain devices. They are paranoid about what they print in c= ase they break one. The plastic is 50+ years old. No OEM replacements around. --===============7154609682939273859==-- From cctalk@emailtoilet.com Mon Dec 23 13:16:34 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 13:16:29 +0000 Message-ID: <173495978942.1294.644277997728305292@classiccmp.org> In-Reply-To: <6d2bcef1-4684-4a9b-89d8-e62c2b8e0b70@farumdata.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8066500278426595130==" --===============8066500278426595130== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I thought the whole idea of the middle pocket on the 2540 was to allow a mast= er deck to be read in and fed to the middle pocket. A total card in the deck = could be selected into read pocket 1 and a new total card punched and fed to = the middle pocket merging it into the master deck in the right place. A fun reader was the 2501. The card read in 9 edge first then changed directi= on and passed by the light based reader column 1 first and then shot up into = the stacker. The card was stopped by 2 fingers hanging down. Tape the fingers= up out of the way, run a program that read cards and you could have a game o= f 2000 card pickup in 2 minutes. Cleanup was a pain. =F0=9F=98=8A https://en.wikipedia.org/wiki/IBM_2501 --===============8066500278426595130==-- From phb.hfx@gmail.com Mon Dec 23 15:47:19 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 11:47:11 -0400 Message-ID: <23319bd2-4660-46f3-9fe2-c0cdec83e8dc@gmail.com> In-Reply-To: <6d2bcef1-4684-4a9b-89d8-e62c2b8e0b70@farumdata.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7439611699997664429==" --===============7439611699997664429== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-23 05:11, Nico de Jong via cctalk wrote: >> > When I was an operator, we once had a visit from a CE who had to > repair the carriage control mechanism. In order to do that, he had to > use a big screwdriver, and of course he lost it. It hit the 1403 N1's > power supply, blew all fuses. This was not enough; the screwdrive hit > obviously the plus and minus pole of the main capacitor (it's about 55 > years ago), so the current was so large that, after the things had > cooled down, he could lift the capactor out of the printer just by > lifting the screwdriver > > It was by the way the same CE that got his tie wrapped up in the print > chain.... > > The same company once had a bunch of visitors who were allowed to > visit the machine room, which normally was a bit nono. One of the > guests took his coffeecup with him, put it on top of the 1403, and > while things were explained to the crowd, the cover lifted and .... > well you can guess the rest. He was quite pisssed off, but it was his > own fault > > Another thing I'll never forget, was the 2540. It had 5 bins, and the > middle one could be used for accepting read cards and punched cards. > Once an operated started to read cards while cards were being punched, > and both routines used the middle bin. That is not to be recommended ! > > /Nico > My experience with a capacitor occurred early in my time as a CE.  Before the days of switching regulators IBM used a lot of power supplied that where regulated by a resonant winding on the input transformer.  If the capacitor on that winding goes short you get no output from the transformer.  I was working on a banking terminal that had no power.  Where I was working I was behind a row of machines and cabinets for things like signature cards, in a narrow isle against the windows, so no one in the branch could see me.  I had already been caught once by a shorted resonant capacitor so first thing I did pop off one of the leads to the capacitor and sure enough it powered up, but I didn't leave it at that I started to second guess it so I turned off the machine and reattached the wire to the capacitor, and it powered up again.  Then I started thinking that it probably went short due to heating up, so I thought it best to leave it disconnected until I could get a replacement, the machine would work fine without it for a day or two.  It was then that I made the mistake, I thought I should discharge the capacitor, so I shorted the leads with the shank of a screwdriver and there was a load crack and a bright flash and next thing some of the banks staff where looking over the machine and asking if I was OK.  I still have that screwdriver some 45 years later. You quickly learned to tuck in you tie and roll up your sleeves not just to keep them out of the mechanisms, but also to keep them out of the oil and grease.  The worst things I worked on for getting dirty was proof machines.  The endorsers used a purple indelible ink and they would get gummed up with a mixture of ink and paper dust and working with gloves was impossible so you would end up with your hands stained purple.  Later someone stumbled on the idea of using a ultrasonic cleaner which we could use to clean everything except the endorsement plate, the ultrasonic cleaner would cause the endorsement plate to delaminate, but it was easy to clean by hand. Paul. --===============7439611699997664429==-- From wayne.sudol@hotmail.com Mon Dec 23 20:42:37 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 20:42:30 +0000 Message-ID: In-Reply-To: <23319bd2-4660-46f3-9fe2-c0cdec83e8dc@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8076692196650656010==" --===============8076692196650656010== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For the people who worked at IBM, what was the difference between an =E2=80= =9CFE=E2=80=9D and =E2=80=9CCE=E2=80=9D ? Sent from my iPhone > On Dec 23, 2024, at 07:47, Paul Berger via cctalk = wrote: >=20 > =EF=BB=BF > On 2024-12-23 05:11, Nico de Jong via cctalk wrote: >>>=20 >> When I was an operator, we once had a visit from a CE who had to repair th= e carriage control mechanism. In order to do that, he had to use a big screwd= river, and of course he lost it. It hit the 1403 N1's power supply, blew all = fuses. This was not enough; the screwdrive hit obviously the plus and minus p= ole of the main capacitor (it's about 55 years ago), so the current was so la= rge that, after the things had cooled down, he could lift the capactor out of= the printer just by lifting the screwdriver >>=20 >> It was by the way the same CE that got his tie wrapped up in the print cha= in.... >>=20 >> The same company once had a bunch of visitors who were allowed to visit th= e machine room, which normally was a bit nono. One of the guests took his cof= feecup with him, put it on top of the 1403, and while things were explained t= o the crowd, the cover lifted and .... well you can guess the rest. He was qu= ite pisssed off, but it was his own fault >>=20 >> Another thing I'll never forget, was the 2540. It had 5 bins, and the midd= le one could be used for accepting read cards and punched cards. Once an oper= ated started to read cards while cards were being punched, and both routines = used the middle bin. That is not to be recommended ! >>=20 >> /Nico >>=20 > My experience with a capacitor occurred early in my time as a CE. Before t= he days of switching regulators IBM used a lot of power supplied that where r= egulated by a resonant winding on the input transformer. If the capacitor on= that winding goes short you get no output from the transformer. I was worki= ng on a banking terminal that had no power. Where I was working I was behind= a row of machines and cabinets for things like signature cards, in a narrow = isle against the windows, so no one in the branch could see me. I had alread= y been caught once by a shorted resonant capacitor so first thing I did pop o= ff one of the leads to the capacitor and sure enough it powered up, but I did= n't leave it at that I started to second guess it so I turned off the machine= and reattached the wire to the capacitor, and it powered up again. Then I s= tarted thinking that it probably went short due to heating up, so I thought i= t best to leave it disconnected until I could get a replacement, the machine = would work fine without it for a day or two. It was then that I made the mis= take, I thought I should discharge the capacitor, so I shorted the leads with= the shank of a screwdriver and there was a load crack and a bright flash and= next thing some of the banks staff where looking over the machine and asking= if I was OK. I still have that screwdriver some 45 years later. >=20 > You quickly learned to tuck in you tie and roll up your sleeves not just to= keep them out of the mechanisms, but also to keep them out of the oil and gr= ease. The worst things I worked on for getting dirty was proof machines. Th= e endorsers used a purple indelible ink and they would get gummed up with a m= ixture of ink and paper dust and working with gloves was impossible so you wo= uld end up with your hands stained purple. Later someone stumbled on the ide= a of using a ultrasonic cleaner which we could use to clean everything except= the endorsement plate, the ultrasonic cleaner would cause the endorsement pl= ate to delaminate, but it was easy to clean by hand. >=20 > Paul. >=20 --===============8076692196650656010==-- From van.snyder@sbcglobal.net Mon Dec 23 21:10:52 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 13:10:40 -0800 Message-ID: <5edebea48835dd11591a880d9bccdd9c73034d5a.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6819147973821151989==" --===============6819147973821151989== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2024-12-22 at 22:26 -0600, jim stephens via cctalk wrote: > The fun story I have was from when I was playing one night and had > accidentally done a skip to channel, 12, which on our printer had no > stops, so it would jet paper out as fast as it could go. The 1403 has a carriage control tape loop.  It's about two inches wide, mounted at the top right. Each row corresponds to one print line. There are twelve columns along the tape, called "channels." Channel 1 is "top of form." That's the one the carriage skips to when you push the "carriage skip" button on the printer, or execute the "skip to channel 1" instruction in the 1401 (I don't know the 360 instruction). You can add punches in any other columns, for example you might want to skip to channel 3, four lines down the page, after printing a header. Maybe if you're printing statements or invoices you might want to skip to channel 5 to print the customer's address, and channel 7 to print the details etc. On the 1401, channel 12 is usually used to detect the bottom of the page. There's an instruction to ask if the printer is at column 12, called "branch if carriage overflow."  But you can skip to any channel, so "skip to channel 12" would work. Indeed, that might be used to print footers, which have been what that program was trying to do. Why so many channels? It seems unlikely that any program would want to have twelve different carriage positions. But you could reserve channel 1 for top of page, and twelve for bottom of page, and then use the other odd ones for one program, and even ones for another program, so you wouldn't need to change carriage tapes. --===============6819147973821151989==-- From van.snyder@sbcglobal.net Mon Dec 23 21:13:20 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 13:13:08 -0800 Message-ID: <05e7836afe80071238993acda6ddd013c8910557.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0004915422671070393==" --===============0004915422671070393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2024-12-22 at 22:26 -0600, jim stephens via cctalk wrote: > He had > the back up, (mentioned in other posts could  mess up your time if > you > had something sitting on the case. I had put a box with a SORT 7 deck in it on the side of the cover. I opened the cover and spilled the cards. Fortunately, there was a card sorter nearby. I never left a coffee cup — or anything else — there after that experience. --===============0004915422671070393==-- From cctalk@emailtoilet.com Mon Dec 23 21:31:05 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 21:31:00 +0000 Message-ID: <173498946010.1294.10698141718683739646@classiccmp.org> In-Reply-To: <5edebea48835dd11591a880d9bccdd9c73034d5a.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1062417547918751876==" --===============1062417547918751876== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Skip to a Channel was faster than printing blank lines to get to the same pla= ce on the form.=20 I modified a program for a client and left the job to run over night at a ser= vice bureau. Went in the next morning and they blessed me with a whole box of= used paper. Seems the program skipped to channel 1 and then printed 1 charac= ter in position 1. Then repeated. After 1 box of paper the operator decided t= o cancel the job. =F0=9F=98=8A --===============1062417547918751876==-- From phb.hfx@gmail.com Mon Dec 23 22:20:26 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 18:20:18 -0400 Message-ID: <564243c6-7660-4786-baba-e2aceb0f7b30@gmail.com> In-Reply-To: <5edebea48835dd11591a880d9bccdd9c73034d5a.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4365151626764836381==" --===============4365151626764836381== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2024-12-23 17:10, Van Snyder via cctalk wrote: > On Sun, 2024-12-22 at 22:26 -0600, jim stephens via cctalk wrote: >> The fun story I have was from when I was playing one night and had >> accidentally done a skip to channel, 12, which on our printer had no >> stops, so it would jet paper out as fast as it could go. > The 1403 has a carriage control tape loop.  It's about two inches wide, > mounted at the top right. Each row corresponds to one print line. There > are twelve columns along the tape, called "channels." Channel 1 is "top > of form." That's the one the carriage skips to when you push the > "carriage skip" button on the printer, or execute the "skip to channel > 1" instruction in the 1401 (I don't know the 360 instruction). You can > add punches in any other columns, for example you might want to skip to > channel 3, four lines down the page, after printing a header. Maybe if > you're printing statements or invoices you might want to skip to > channel 5 to print the customer's address, and channel 7 to print the > details etc. On the 1401, channel 12 is usually used to detect the > bottom of the page. There's an instruction to ask if the printer is at > column 12, called "branch if carriage overflow."  But you can skip to > any channel, so "skip to channel 12" would work. Indeed, that might be > used to print footers, which have been what that program was trying to > do. > > Why so many channels? It seems unlikely that any program would want to > have twelve different carriage positions. But you could reserve channel > 1 for top of page, and twelve for bottom of page, and then use the > other odd ones for one program, and even ones for another program, so > you wouldn't need to change carriage tapes. > From what I recall customers might have several different forms and they might not be all the same length, so they would need a different tape for each form length at least.  The way it would work is a brush would look for a hole in the tape and if it did not find a hole it would skip until there was no more forms.  This kind of run away was caused by A)  improper punching of the tape, B) putting the tape on wrong or C) not loading the brushes that look for the hole after putting on a tape. Twelve channels does seem excessive but would make the skip function very flexable and using skip intelligently could greatly increase throughput. I never serviced 1403 saw lots of them, I did service 3203 which using the same print trains, but used an electronic skip setup and 4245 which was basically the same printer as 3203 but was a belt printer instead of a train. Paul. --===============4365151626764836381==-- From van.snyder@sbcglobal.net Mon Dec 23 22:37:53 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 14:37:44 -0800 Message-ID: <317beb43c607b723ef620de773b1030ad6a0b19d.camel@sbcglobal.net> In-Reply-To: <173495978942.1294.644277997728305292@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0816485225583289410==" --===============0816485225583289410== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2024-12-23 at 13:16 +0000, Donald Whittemore via cctalk wrote: > I thought the whole idea of the middle pocket on the 2540 was to > allow a master deck to be read in and fed to the middle pocket. A > total card in the deck could be selected into read pocket 1 and a new > total card punched and fed to the middle pocket merging it into the > master deck in the right place. The "2/8" center stacker on the 2540, modeled on the 1402 or maybe a 1402 with a different cover, worked for both the reader and punch. But the reader and punch operate at different speeds. It was not recommended to stack from both the reader and punch into the center stacker, but it could be done if appropriate timing loops were included. This could be useful if your 1401 had the "read punch feed" feature and your computer room didn't have a model 88 collator. > A fun reader was the 2501. The card read in 9 edge first then changed > direction and passed by the light based reader column 1 first and > then shot up into the stacker. The card was stopped by 2 fingers > hanging down. Tape the fingers up out of the way, run a program that > read cards and you could have a game of 2000 card pickup in 2 > minutes. Cleanup was a pain. 😊 > https://en.wikipedia.org/wiki/IBM_2501 It sounds like the 2501 was the same as 1442 model 4, a read-only version of other models of the 1442. Models 1, 2, and 3 were read-and- then-punch machines. The punch station was downstream from the read station. So it was possible to read a card, then punch stuff onto the same card — usually in blank columns. Programs that would do things like read details and punch summaries were difficult with 1442, but not with the 1402. --===============0816485225583289410==-- From van.snyder@sbcglobal.net Mon Dec 23 23:21:46 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 15:21:36 -0800 Message-ID: <6b047b21411b18ead9dbc7e2bb5f7834e8b6ea2a.camel@sbcglobal.net> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181A902526AAA03AA536B1EE4022=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4181381310122255613==" --===============4181381310122255613== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2024-12-23 at 20:42 +0000, Wayne S via cctalk wrote: > For the people who worked at IBM, what was the difference between an > “FE” and “CE” ? When my employer had a 7094/7044 Direct Couple, all the IBM guys who worked on it were called "CE" for "Customer Engineer." When it was replaced with Univac 1108, all the guys who worked on it were called "FE" for "Field Engineer." I never heard the IBM guys called FE, or the Univac guys called CE. --===============4181381310122255613==-- From norwayjose@mac.com Mon Dec 23 23:22:12 2024 From: Rod Bartlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 18:21:55 -0500 Message-ID: <20C5020E-8ED4-427B-B3C3-6AD8835B53FE@mac.com> In-Reply-To: =?utf-8?q?=3CCY4PR1001MB2181A902526AAA03AA536B1EE4022=40CY4PR10?= =?utf-8?q?01MB2181=2Enamprd10=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2546104402684723198==" --===============2546104402684723198== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think IBM always called their service techs CEs, didn't they? Honeywell an= d at least one small company (Atex) which serviced DEC PDP-11 machines called= the same position a Field Engineer. One site I used to service (USGS in Reston, VA) had a split computer room. T= he left side was for IBM gear while the right side held a Honeywell Multics m= achine which allowed me to see how my counterparts at IBM worked. When the I= BM machine was down, there were a group of conservatively dressed CEs investi= gating the problem. When the Multics system had hardware problems, it was ju= st me working on it and I never wore a suit. - Rod > On Dec 23, 2024, at 3:42=E2=80=AFPM, Wayne S via cctalk wrote: >=20 > For the people who worked at IBM, what was the difference between an =E2=80= =9CFE=E2=80=9D and =E2=80=9CCE=E2=80=9D ? >=20 > Sent from my iPhone >=20 >> On Dec 23, 2024, at 07:47, Paul Berger via cctalk wrote: >>=20 >> =EF=BB=BF >> On 2024-12-23 05:11, Nico de Jong via cctalk wrote: >>>>=20 >>> When I was an operator, we once had a visit from a CE who had to repair t= he carriage control mechanism. In order to do that, he had to use a big screw= driver, and of course he lost it. It hit the 1403 N1's power supply, blew all= fuses. This was not enough; the screwdrive hit obviously the plus and minus = pole of the main capacitor (it's about 55 years ago), so the current was so l= arge that, after the things had cooled down, he could lift the capactor out o= f the printer just by lifting the screwdriver >>>=20 >>> It was by the way the same CE that got his tie wrapped up in the print ch= ain.... >>>=20 >>> The same company once had a bunch of visitors who were allowed to visit t= he machine room, which normally was a bit nono. One of the guests took his co= ffeecup with him, put it on top of the 1403, and while things were explained = to the crowd, the cover lifted and .... well you can guess the rest. He was q= uite pisssed off, but it was his own fault >>>=20 >>> Another thing I'll never forget, was the 2540. It had 5 bins, and the mid= dle one could be used for accepting read cards and punched cards. Once an ope= rated started to read cards while cards were being punched, and both routines= used the middle bin. That is not to be recommended ! >>>=20 >>> /Nico >>>=20 >> My experience with a capacitor occurred early in my time as a CE. Before = the days of switching regulators IBM used a lot of power supplied that where = regulated by a resonant winding on the input transformer. If the capacitor o= n that winding goes short you get no output from the transformer. I was work= ing on a banking terminal that had no power. Where I was working I was behin= d a row of machines and cabinets for things like signature cards, in a narrow= isle against the windows, so no one in the branch could see me. I had alrea= dy been caught once by a shorted resonant capacitor so first thing I did pop = off one of the leads to the capacitor and sure enough it powered up, but I di= dn't leave it at that I started to second guess it so I turned off the machin= e and reattached the wire to the capacitor, and it powered up again. Then I = started thinking that it probably went short due to heating up, so I thought = it best to leave it disconnected until I could get a replacement, the machine= would work fine without it for a day or two. It was then that I made the mi= stake, I thought I should discharge the capacitor, so I shorted the leads wit= h the shank of a screwdriver and there was a load crack and a bright flash an= d next thing some of the banks staff where looking over the machine and askin= g if I was OK. I still have that screwdriver some 45 years later. >>=20 >> You quickly learned to tuck in you tie and roll up your sleeves not just t= o keep them out of the mechanisms, but also to keep them out of the oil and g= rease. The worst things I worked on for getting dirty was proof machines. T= he endorsers used a purple indelible ink and they would get gummed up with a = mixture of ink and paper dust and working with gloves was impossible so you w= ould end up with your hands stained purple. Later someone stumbled on the id= ea of using a ultrasonic cleaner which we could use to clean everything excep= t the endorsement plate, the ultrasonic cleaner would cause the endorsement p= late to delaminate, but it was easy to clean by hand. >>=20 >> Paul. >>=20 --===============2546104402684723198==-- From van.snyder@sbcglobal.net Mon Dec 23 23:29:29 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Multics on Intel, was Re: Print chain for 1403 Date: Mon, 23 Dec 2024 15:29:17 -0800 Message-ID: <1f8f59c145487eac76a2e8919f111afea9d62cc2.camel@sbcglobal.net> In-Reply-To: <20C5020E-8ED4-427B-B3C3-6AD8835B53FE@mac.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3748188496676574837==" --===============3748188496676574837== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2024-12-23 at 18:21 -0500, Rod Bartlett via cctalk wrote: > One site I used to service (USGS in Reston, VA) had a split computer > room.  The left side was for IBM gear while the right side held a > Honeywell Multics machine Stuart Feldman, formerly of Bell Labs where he claimed credit for Make and the first (and slowest) FORTRAN 77 compiler, told me that Unix was developed by some MIT students who thought Multics was too big and too complicated, so they wanted to develop a small single-user system. They called it Unix. Now Unix (and Linux) are far bigger and more complicated than Multics. I don't remember which of the Unix gurus said "Version 7 was an improvement on all of its successors," but I think maybe Multics was an improvement on all of its successors. Has anybody gotten Multics to work on Intel? --===============3748188496676574837==-- From cctalk@emailtoilet.com Mon Dec 23 23:32:55 2024 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 23:32:51 +0000 Message-ID: <173499677101.1294.11992274720446733877@classiccmp.org> In-Reply-To: <20C5020E-8ED4-427B-B3C3-6AD8835B53FE@mac.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4178719948582474169==" --===============4178719948582474169== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, I have proof IBM used the Field Engineer term. See the punch card used = to report an Incident. https://www.ibmjunkman.com/cards/?Holder=3D774&Img=3D1 --===============4178719948582474169==-- From wayne.sudol@hotmail.com Tue Dec 24 00:00:23 2024 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Tue, 24 Dec 2024 00:00:13 +0000 Message-ID: In-Reply-To: <173499677101.1294.11992274720446733877@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0414506064834921625==" --===============0414506064834921625== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We were a fairly big IBM site and we had a full-time CE on site with his own = office/storage room in the computer room. He could go to any other site if IB= M needed him to do that. Periodically, Field Engineers would visit as well. I= couldn=E2=80=99t tell the difference from those guys. They even dressed the = same as the IBM male sales people. The IBM female salespeople, though, were HOT.=20 Word got around when they were in the building.=20 Sent from my iPhone > On Dec 23, 2024, at 15:33, Donald Whittemore via cctalk wrote: >=20 > =EF=BB=BFWell, I have proof IBM used the Field Engineer term. See the punch= card used to report an Incident. >=20 > https://www.ibmjunkman.com/cards/?Holder=3D774&Img=3D1 --===============0414506064834921625==-- From phb.hfx@gmail.com Tue Dec 24 01:37:33 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 21:37:25 -0400 Message-ID: In-Reply-To: <173499677101.1294.11992274720446733877@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7980547259754588968==" --===============7980547259754588968== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2024-12-23 19:32, Donald Whittemore via cctalk wrote: > Well, I have proof IBM used the Field Engineer term. See the punch card use= d to report an Incident. > > https://www.ibmjunkman.com/cards/?Holder=3D774&Img=3D1 It says "Field Engineering Incident Report"=C2=A0 (IR) which it would seem to= =20 me is referring to an organization, while on the bottom line there is a=20 space for the "CE Serial" where the CE would enter his part number.=C2=A0 So = the individual was being referred to as CE. When I was filling out IRs=20 they where not card stock but where just paper slips about the size of a=20 punch card and where read by a 1287 optical reader and we mailed ours to=20 Box 1287 at one of the Toronto post offices.=C2=A0 We where scored on the=20 number of documents that where rejected due to malformed numbers or=20 writing outside the boxes on the form.=C2=A0 I was then out of field service = for about seven years and when I returned a a midrange=C2=A0 Customer Service= =20 Rep (CSR) we where reporting out time using a portable terminal made by=20 Motorola loving referred to as "The Brick" because it was about the size=20 and weight of a brick.=C2=A0 After I had left the field again for a support=20 role, the brick was replaced by a smaller clam shell portable terminal=20 made by RIM and still later they where replaced by smart phones which I=20 believe the field personal use to this day to receive calls and report=20 time. Paul. --===============7980547259754588968==-- From cisin@xenosoft.com Tue Dec 24 01:44:43 2024 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 17:44:36 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1205250691233978059==" --===============1205250691233978059== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 2024-12-23 19:32, Donald Whittemore via cctalk wrote: >> Well, I have proof IBM used the Field Engineer term. See the punch card=20 >> used to report an Incident. >> https://www.ibmjunkman.com/cards/?Holder=3D774&Img=3D1 On Mon, 23 Dec 2024, Paul Berger via cctalk wrote: > It says "Field Engineering Incident Report"=C2=A0 (IR) which it would seem = to me=20 > is referring to an organization, while on the bottom line there is a space = > for the "CE Serial" where the CE would enter his part number.=C2=A0 So the = > individual was being referred to as CE. So, IBM referred to the individual as CE, and the organization as FE. To have full symmetry, did anybody else refer to the individual as FE, and=20 the organization as CE? --===============1205250691233978059==-- From sqrfolkdnc@comcast.net Tue Dec 24 01:54:24 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] 2540 [was: Print chain for 1403] Date: Mon, 23 Dec 2024 19:54:12 -0600 Message-ID: <1250521477.888910.1735005252373@connect.xfinity.com> In-Reply-To: <6d2bcef1-4684-4a9b-89d8-e62c2b8e0b70@farumdata.dk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0391182228552330294==" --===============0391182228552330294== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable we had one job that read cards into the middle bin, then punched totals or so= mething into that bin too. other times, as a college student and operator, under DOS/360 we seldom used = the 2K F2 partition, so I wrote a program so, after I altered storage to ALSO= assign the punch to F2, I would type in my programs and punch them to the mi= ddle bin. ran them through the interpreting card punch later. 
--Carey
> On 12/23/2024 3:11 AM CST Nico de Jong via cctalk = wrote: >=20 > =20 > > > > The carriage control tapes had the sprocket holes dead center which=20 > > lead to people putting them on backwards by accident=C2=A0 and since most= =20 > > people only used a couple channels for any given form, this would lead=20 > > to paper runaways, as would neglecting to lower the brush block after=20 > > mounting the carriage control tape. > > > > I once saw one of the large system CEs repairing a print train that=20 > > the customer had neglected to fill the oiler and the train seized.=C2=A0 = > > The filling the oiler was the customer's responsibility so the repair=20 > > of the train was billable.=C2=A0 The type slugs I saw where not coupled=20 > > together and had helical gear teeth on the bottom that coupled with a=20 > > gear in the train that was driven by the motor.=C2=A0 I am not sure what = > > model of 1403 this came from but it was one of the models that had=20 > > covers that went all the way to the floor.=C2=A0 The print trains had a=20 > > separate machine type and I seem to recall that the customer was=20 > > obliged to purchase them even if the 1403 was leased.=C2=A0 The 3203=20 > > printer used the same print trains as 1403. > > > > Paul. > > > When I was an operator, we once had a visit from a CE who had to repair=20 > the carriage control mechanism. In order to do that, he had to use a big=20 > screwdriver, and of course he lost it. It hit the 1403 N1's power=20 > supply, blew all fuses. This was not enough; the screwdrive hit=20 > obviously the plus and minus pole of the main capacitor (it's about 55=20 > years ago), so the current was so large that, after the things had=20 > cooled down, he could lift the capactor out of the printer just by=20 > lifting the screwdriver >=20 > It was by the way the same CE that got his tie wrapped up in the print=20 > chain.... >=20 > The same company once had a bunch of visitors who were allowed to visit=20 > the machine room, which normally was a bit nono. One of the guests took=20 > his coffeecup with him, put it on top of the 1403, and while things were=20 > explained to the crowd, the cover lifted and .... well you can guess the=20 > rest. He was quite pisssed off, but it was his own fault >=20 > Another thing I'll never forget, was the 2540. It had 5 bins, and the=20 > middle one could be used for accepting read cards and punched cards.=20 > Once an operated started to read cards while cards were being punched,=20 > and both routines used the middle bin. That is not to be recommended ! >=20 > /Nico --===============0391182228552330294==-- From van.snyder@sbcglobal.net Tue Dec 24 01:58:09 2024 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 17:57:51 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6603414413367455236==" --===============6603414413367455236== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2024-12-23 at 17:44 -0800, Fred Cisin via cctalk wrote: > So, IBM referred to the individual as CE, and the organization as FE. > To have full symmetry, did anybody else refer to the individual as > FE, and > the organization as CE? I think Univac called the organization "Field Engineering" and the crew "Field Engineers" or FE. --===============6603414413367455236==-- From g4ajq1@gmail.com Tue Dec 24 02:05:19 2024 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Mon, 23 Dec 2024 21:05:01 -0500 Message-ID: <2990ded6-66cf-42cc-b454-acb040ccfd0b@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6195390966271120835==" --===============6195390966271120835== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2024-12-23 20:57, Van Snyder via cctalk wrote: > On Mon, 2024-12-23 at 17:44 -0800, Fred Cisin via cctalk wrote: >> So, IBM referred to the individual as CE, and the organization as FE. >> To have full symmetry, did anybody else refer to the individual as >> FE, and >> the organization as CE? > I think Univac called the organization "Field Engineering" and the crew > "Field Engineers" or FE. > > Yup. I trained as a Univac FE on the 418, except that I worked for Bell Canada and had to be classed as 'Craft Technician 1A'! Management got in a bit of a tizz when we called ourselves FEs -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============6195390966271120835==-- From cube1@charter.net Tue Dec 24 15:33:41 2024 From: Jay Jaeger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Tue, 24 Dec 2024 09:26:25 -0600 Message-ID: <8c36e07a-88fc-d30e-7b3e-bd74c637cd97@charter.net> In-Reply-To: <1873252823.858365.1734802907018@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1643779579398743305==" --===============1643779579398743305== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 12/21/2024 11:41 AM, CAREY SCHUG via cctalk wrote: > my recollection from being a computer operator at the time was the the earl= ier 1403s did NOT have an interchangeable chain. > > Also curious if any 1404 printers still exist. They were wider and you coul= d shift the print mechanism to the side where there was a mechanisms to print= on tabulating cards, one or two at a time. > > 
--Carey
> The older 1403's did have a *feature* one could order so that print=20 chains were interchangeable.=C2=A0 So, presumably not all 1403's were ordered= =20 that way.=C2=A0 But the IBM 1403 on the IBM 1410 ordered for the U. Wisconsin= =20 Registrar, and later used at the UW School of Business did have that=20 chain interchange feature.=C2=A0 The chain came in a wooden box. JRJ --===============1643779579398743305==-- From jwsmail@jwsss.com Wed Dec 25 03:36:43 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: 2540 [was: Print chain for 1403] Date: Tue, 24 Dec 2024 21:36:35 -0600 Message-ID: <690ad5a6-5f00-407c-95eb-f219b453cdb5@jwsss.com> In-Reply-To: <1250521477.888910.1735005252373@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8463852841676798812==" --===============8463852841676798812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable There was a fellow from one of the research buildings who had an xray=20 crystalography project ongoing, and some of his research is still=20 textbook for the subject. Anyway he had been running for years in 72 on, and was generating=20 massive amount of data.=C2=A0 He had two full handtrucks of 2000 card decks=20 with his program and at a box or two of data in the pile.=C2=A0 He did a lot = of matrix processing on the 360/50 (512k of main memory, and 1mb of=20 LCS), which was in the scheme of things not a lot of computing to do=20 such with. He took measurements with sensors at a large number of points on the=20 back side of an irradiated crystal and entered information about the=20 position and result. anyway, the computer center had job cost controls in place, and he had=20 an account on both the 360, and later 370 TSO with no limits. He shared=20 his login with me for the system, so I could do jobs any time for our=20 computer project, which had a minicomputer lab, and half inch tape.=C2=A0 Our= =20 use of the mainframe was preparing jobs on our minicomputer, and=20 creating job tapes and submitting them or data via the 9 track half inch=20 tape. Anyway used it thru the mid 80s when the TSO for the university was shut=20 down and the dialin went away. The 2540 in this case was hooked to the 360/50 and the job he had was=20 read into the 360's 2314 subsystem.=C2=A0 We ran what I was told was the only= =20 HASP workstation with a remote running on an actual 360. It fed into=20 HASP, later JES on the 370 145 at another university. He could submit his job to run either locally on the 360, or transmit it=20 to the other system to run, and route the results back to our 360/50 for=20 printing on our local 1403.=C2=A0 The one which could fire paper across the=20 room from earlier in the thread. I don't recall the reason for the channel 12 being blank and unlimited,=20 or if it was as simple as my recolletion.=C2=A0 I=C2=A0 believe there was som= e=20 channel control fiddling involved, and I like to play with obscure thing=20 like that when I discovered documentation about such. One thing I found and fiddled with for instance was a utility exit in=20 the tape subsystem library called SPIE.=C2=A0 Turned out I could submit a=20 SPIE handler which could get control when a tape fault occurred in=20 supervisor mode.=C2=A0 Wasn't hard to generate a fault on the tape and get=20 the exit triggered. The system programmers added code to block that after I reported it to them. Thanks jim On 12/23/24 19:54, CAREY SCHUG via cctalk wrote: > we had one job that read cards into the middle bin, then punched totals or = something into that bin too. > > other times, as a college student and operator, under DOS/360 we seldom use= d the 2K F2 partition, so I wrote a program so, after I altered storage to AL= SO assign the punch to F2, I would type in my programs and punch them to the = middle bin. ran them through the interpreting card punch later. > > 
--Carey
> >> On 12/23/2024 3:11 AM CST Nico de Jong via cctalk wrote: >> >> =20 >>> The carriage control tapes had the sprocket holes dead center which >>> lead to people putting them on backwards by accident=C2=A0 and since most >>> people only used a couple channels for any given form, this would lead >>> to paper runaways, as would neglecting to lower the brush block after >>> mounting the carriage control tape. >>> >>> I once saw one of the large system CEs repairing a print train that >>> the customer had neglected to fill the oiler and the train seized. >>> The filling the oiler was the customer's responsibility so the repair >>> of the train was billable.=C2=A0 The type slugs I saw where not coupled >>> together and had helical gear teeth on the bottom that coupled with a >>> gear in the train that was driven by the motor.=C2=A0 I am not sure what >>> model of 1403 this came from but it was one of the models that had >>> covers that went all the way to the floor.=C2=A0 The print trains had a >>> separate machine type and I seem to recall that the customer was >>> obliged to purchase them even if the 1403 was leased.=C2=A0 The 3203 >>> printer used the same print trains as 1403. >>> >>> Paul. >>> >> When I was an operator, we once had a visit from a CE who had to repair >> the carriage control mechanism. In order to do that, he had to use a big >> screwdriver, and of course he lost it. It hit the 1403 N1's power >> supply, blew all fuses. This was not enough; the screwdrive hit >> obviously the plus and minus pole of the main capacitor (it's about 55 >> years ago), so the current was so large that, after the things had >> cooled down, he could lift the capactor out of the printer just by >> lifting the screwdriver >> >> It was by the way the same CE that got his tie wrapped up in the print >> chain.... >> >> The same company once had a bunch of visitors who were allowed to visit >> the machine room, which normally was a bit nono. One of the guests took >> his coffeecup with him, put it on top of the 1403, and while things were >> explained to the crowd, the cover lifted and .... well you can guess the >> rest. He was quite pisssed off, but it was his own fault >> >> Another thing I'll never forget, was the 2540. It had 5 bins, and the >> middle one could be used for accepting read cards and punched cards. >> Once an operated started to read cards while cards were being punched, >> and both routines used the middle bin. That is not to be recommended ! >> >> /Nico --===============8463852841676798812==-- From jwsmail@jwsss.com Wed Dec 25 03:39:01 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Tue, 24 Dec 2024 21:38:55 -0600 Message-ID: In-Reply-To: <173495978942.1294.644277997728305292@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0208640163634106078==" --===============0208640163634106078== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 12/23/24 07:16, Donald Whittemore via cctalk wrote: > I thought the whole idea of the middle pocket on the 2540 was to allow a ma= ster deck to be read in and fed to the middle pocket. A total card in the dec= k could be selected into read pocket 1 and a new total card punched and fed t= o the middle pocket merging it into the master deck in the right place. > > A fun reader was the 2501. The card read in 9 edge first then changed direc= tion and passed by the light based reader column 1 first and then shot up int= o the stacker. The card was stopped by 2 fingers hanging down. Tape the finge= rs up out of the way, run a program that read cards and you could have a game= of 2000 card pickup in 2 minutes. Cleanup was a pain. =F0=9F=98=8A > https://en.wikipedia.org/wiki/IBM_2501 Someone on this list or on one of the Facebook groups had one in Europe=20 which he was going to attach to something like a PC or such. He had it=20 up and running and reading cards, but haven't seen any other mention since. Also someone sold one of the weights which were distinctive on epay some=20 years ago. thanks Jim --===============0208640163634106078==-- From jwsmail@jwsss.com Wed Dec 25 03:49:08 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Tue, 24 Dec 2024 21:49:00 -0600 Message-ID: <7c392343-02fc-4eb5-9666-9586ea895350@jwsss.com> In-Reply-To: <6b047b21411b18ead9dbc7e2bb5f7834e8b6ea2a.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8687464111334910086==" --===============8687464111334910086== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/23/24 17:21, Van Snyder via cctalk wrote: > On Mon, 2024-12-23 at 20:42 +0000, Wayne S via cctalk wrote: >> For the people who worked at IBM, what was the difference between an >> “FE” and “CE” ? > When my employer had a 7094/7044 Direct Couple, all the IBM guys who > worked on it were called "CE" for "Customer Engineer." When it was > replaced with Univac 1108, all the guys who worked on it were called > "FE" for "Field Engineer." I never heard the IBM guys called FE, or the > Univac guys called CE. > > > I don't know if there was a difference, but at our school, when we ordered and later took delivery of a 360/50 (purchased), IBM called up the local Selectric repair guy (his primary duty at the time) and shipped him to school to service our systems.  We had a 360/40 from about 68 till the /50 was delivered in about 1970.  So he had to fix both.  It speaks volumes that a typewrite repairman could move to servicing a system like the 360 with the training provided by IBM. And how good he was at it.  Worth noting that the console, 1052 was always running perfectly. He was our "CE" and I don't think he had any other systems to service. We were in Rolla, Mo about 80 miles from St Louis so not practical to call him up for routine calls. He continued servicing all other IBM products when not working on the /50. The later experience we had we didn't have a term for the IBM personnel.  Our service on a number of IBM systems was much more we fix and IBM come in seldom.  We had a 4381 and a 9221 as well as two 9370s.  We did not have much hardware issues in the way of faults or the like IBM expected us to handle all aspects of configuration and the like as we were supporting an IBM approved third party operating system which required testing in various configurations that our and later their customers would encounter. The system was Ultimate Pick on the mainframe, and ran directly on the hardware, or in our case for development on VM and VM/ESA.  We had it configured to be bootable if need be on both the bare machine as well as under VM for each developer. But when the IBM guys showed up it was typically for larger jobs. For instance we upgraded to the 9221 and they shipped in an upgrade kit and installed it for us. And periodically they'd have to work on our tape drives which were 3420s. thanks Jim --===============8687464111334910086==-- From jwsmail@jwsss.com Wed Dec 25 03:56:56 2024 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Multics on Intel, was Re: Print chain for 1403 Date: Tue, 24 Dec 2024 21:56:48 -0600 Message-ID: <035d9bc6-1e0b-4926-9fd0-7a2da1c27b74@jwsss.com> In-Reply-To: <1f8f59c145487eac76a2e8919f111afea9d62cc2.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8404381821499488807==" --===============8404381821499488807== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/23/24 17:29, Van Snyder via cctalk wrote: > On Mon, 2024-12-23 at 18:21 -0500, Rod Bartlett via cctalk wrote: >> One site I used to service (USGS in Reston, VA) had a split computer >> room.  The left side was for IBM gear while the right side held a >> Honeywell Multics machine > Stuart Feldman, formerly of Bell Labs where he claimed credit for Make > and the first (and slowest) FORTRAN 77 compiler, told me that Unix was > developed by some MIT students who thought Multics was too big and too > complicated, so they wanted to develop a small single-user system. They > called it Unix. > > Now Unix (and Linux) are far bigger and more complicated than Multics. Linux and Unix still have along way to go to approach that statement.  Though large code bases, they are nowhere near as complicated as what Multics achieved. There is a public system run by Eric S which allows anonymous logins, or he will assign you a user ID on his system and let you have at it. The security is the best of any system ever developed. > > I don't remember which of the Unix gurus said "Version 7 was an > improvement on all of its successors," but I think maybe Multics was an > improvement on all of its successors. Not sure what that means.  The main quibble I have with current Linux is the systemd, which is mostly unnecessary as well as the introduction of "snap" for the Linux system.  The later is an attempt to mitigate a security problem which  creates a number of very bad features worse than the problem it attempts to solve. The kernel is large, but most of the "complication" is straightforward within the discipline available in the kernel structure. > Has anybody gotten Multics to work on Intel? > > There is an emulator for the Honeywell 6180 with the Multics hardware support that runs a tape image and backup released by a three letter agency, and uses the source from the MIT release of such from Honeywell. As far as performance it seems to run about as well as ever when hosted on Intel as it did on the actual hardware. It also runs quite well on a Raspberry Pi. Thanks Jim --===============8404381821499488807==-- From linimon@portsmon.org Wed Dec 25 05:09:09 2024 From: Mark Linimon To: cctalk@classiccmp.org Subject: [cctalk] Re: Multics on Intel, was Re: Print chain for 1403 Date: Tue, 24 Dec 2024 22:57:02 -0600 Message-ID: <2008923577.168932.1735102622646@privateemail.com> In-Reply-To: <035d9bc6-1e0b-4926-9fd0-7a2da1c27b74@jwsss.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7329899799180328393==" --===============7329899799180328393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 12/24/2024 9:56 PM CST jim stephens via cctalk = wrote: > The main quibble I have with current Linux is the systemd Stop by and visit us over on FreeBSD sometime, we abhor systemd :-) mcl --===============7329899799180328393==-- From elson@pico-systems.com Wed Dec 25 17:58:25 2024 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: 2540 [was: Print chain for 1403] Date: Wed, 25 Dec 2024 11:58:15 -0600 Message-ID: <730f7378-3f97-7b9c-d7de-6f5e95e404f0@pico-systems.com> In-Reply-To: <690ad5a6-5f00-407c-95eb-f219b453cdb5@jwsss.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4121029939448910485==" --===============4121029939448910485== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 12/24/24 21:36, jim stephens via cctalk wrote: > > > One thing I found and fiddled with for instance was a > utility exit in the tape subsystem library called SPIE.  > Turned out I could submit a SPIE handler which could get > control when a tape fault occurred in supervisor mode.  > Wasn't hard to generate a fault on the tape and get the > exit triggered. > > The system programmers added code to block that after I > reported it to them. Yup, the original OS 360 had so many security and reliability holes you could drive 5 Queen Mary ocean liners abreast through them.  The SPIE code gave you the PSW where the exception occurred, let you do anything you wanted, and then let you alter the PSW as desired with no checks.  This would allow you to clear the "P" bit and return to your program in supervisor mode.  That was surely one of the biggest security holes.  You could trigger the exception with a simple divide by zero.  (SPIE stands for Specify Program Interruption Exit.) Jon --===============4121029939448910485==-- From julf@julf.com Wed Dec 25 20:57:31 2024 From: Johan Helsingius To: cctalk@classiccmp.org Subject: [cctalk] Re: Multics on Intel, was Re: Print chain for 1403 Date: Wed, 25 Dec 2024 21:50:58 +0100 Message-ID: In-Reply-To: <2008923577.168932.1735102622646@privateemail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1223298492768608594==" --===============1223298492768608594== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 25/12/2024 05:57, Mark Linimon via cctalk wrote: > Stop by and visit us over on FreeBSD sometime, we abhor systemd :-) And there is of course Devuan - systemd-free debian. That's what I run on my laptop and desktop, servers are all freebsd. Julf --===============1223298492768608594==-- From sqrfolkdnc@comcast.net Thu Dec 26 08:02:48 2024 From: CAREY SCHUG To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Thu, 26 Dec 2024 02:02:41 -0600 Message-ID: <332660351.910281.1735200161039@connect.xfinity.com> In-Reply-To: <2990ded6-66cf-42cc-b454-acb040ccfd0b@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3330705592735646463==" --===============3330705592735646463== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think we called the people FEs sometimes. Maybe the regular guy that did m= aintenance was a CE and when the had to bring in a specialist from National, = that was an FE? THen there were the PSRs...weren't they the people that helped figure out why= the system kept crashing? Or am I losing it in my old age. 
--Carey
> On 12/23/2024 8:05 PM CST Nigel Johnson Ham via cctalk wrote: >=20 > =20 > On 2024-12-23 20:57, Van Snyder via cctalk wrote: > > On Mon, 2024-12-23 at 17:44 -0800, Fred Cisin via cctalk wrote: > >> So, IBM referred to the individual as CE, and the organization as FE. > >> To have full symmetry, did anybody else refer to the individual as > >> FE, and > >> the organization as CE? > > I think Univac called the organization "Field Engineering" and the crew > > "Field Engineers" or FE. > > --===============3330705592735646463==-- From phb.hfx@gmail.com Thu Dec 26 20:55:05 2024 From: Paul Berger To: cctalk@classiccmp.org Subject: [cctalk] Re: Print chain for 1403 Date: Thu, 26 Dec 2024 16:54:55 -0400 Message-ID: <41318f97-6f6e-400c-9c45-7be216f49015@gmail.com> In-Reply-To: <332660351.910281.1735200161039@connect.xfinity.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4174009739194776059==" --===============4174009739194776059== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes there where people call Program Support Rep (PSR) in the early 80s=20 in Canada at least there was an attempt made to push them into working=20 in support centers.=C2=A0 The large system PSR in the branch I was in was=20 eligible for retirement so he retired and started working as a=20 consultants for all the same customers.=C2=A0 When I transferred to the=20 Toronto Lab=C2=A0 I met some former midrange PSRs there that had been=20 recruited to support the S/34 OS and later write software for S/36 and=20 S/38 and still later AS/400. Paul. On 2024-12-26 04:02, CAREY SCHUG via cctalk wrote: > I think we called the people FEs sometimes. Maybe the regular guy that did= maintenance was a CE and when the had to bring in a specialist from National= , that was an FE? > > THen there were the PSRs...weren't they the people that helped figure out w= hy the system kept crashing? Or am I losing it in my old age. > > 
--Carey
> >> On 12/23/2024 8:05 PM CST Nigel Johnson Ham via cctalk wrote: >> >> =20 >> On 2024-12-23 20:57, Van Snyder via cctalk wrote: >>> On Mon, 2024-12-23 at 17:44 -0800, Fred Cisin via cctalk wrote: >>>> So, IBM referred to the individual as CE, and the organization as FE. >>>> To have full symmetry, did anybody else refer to the individual as >>>> FE, and >>>> the organization as CE? >>> I think Univac called the organization "Field Engineering" and the crew >>> "Field Engineers" or FE. >>> --===============4174009739194776059==-- From epekstrom@gmail.com Mon Dec 30 00:22:03 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] I need some RSX11M+ TKB help Date: Sun, 29 Dec 2024 19:21:46 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5079981161983685710==" --===============5079981161983685710== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have RSX11M+ 4.6 BL87 installed and running on my real PDP 11/23+ and have gotten DECnet to work as well. But recently a need to access a TU58 tape has come up, and turns out the DD driver on disk isn't built against the correct RSX11M.STB file. So I need to, I guess, recreate the DDDRV.TSK file. I have tried some very simplistic TKB commands but keep getting an error saying a required file is missing. I don't have the sysgen stuff on this disk... What I have comes from the pregenned RL02 image. Does anyone know how the TKB command line should look for this? I know, I am looking for the easy way out. I have skimmed through some manuals but nothing has stood out to me (I'm sure I missed it). Any help would be greatly appreciated. - Peter --===============5079981161983685710==-- From seefriek@gmail.com Mon Dec 30 19:49:14 2024 From: Ken Seefried To: cctalk@classiccmp.org Subject: [cctalk] Re: Multics on Intel, was Re: Print chain for 1403 Date: Mon, 30 Dec 2024 14:48:59 -0500 Message-ID: In-Reply-To: <035d9bc6-1e0b-4926-9fd0-7a2da1c27b74@jwsss.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8259682540458281506==" --===============8259682540458281506== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, Dec 24, 2024 at 10:56 PM jim stephens via cctalk < cctalk(a)classiccmp.org> wrote: > > The kernel is large, but most of the "complication" is straightforward > within the discipline available in the kernel structure. > The majority of LoC in "the Linux kernel" as most people think about it (i.e. the tarball you download) are device drivers. Much of the rest is the machine dependent layer (/arch). Neither change the 'complexity' of Linux (though they represent their own complexity). I recall at one point a decade or so ago those two hierarchies amounted to significantly more than 75% of the LoC. The actual '/kernel' dir at that time contained something like 250K LoC (tho that didn't include a lot of things we'd consider kernel code like various filesystems and networking). KJ --===============8259682540458281506==-- From mark@matlockfamily.com Mon Dec 30 20:20:14 2024 From: Mark Matlock To: cctalk@classiccmp.org Subject: [cctalk] Re: I need some RSX11M+ TKB help Date: Mon, 30 Dec 2024 14:20:07 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1655532418568139933==" --===============1655532418568139933== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter, The command file below is from a SYSGEN driver build of DDDRV from my syst= em but I think it should work for yours. Note that OU: is defined by the SYSG= EN process and should be set as a logical to your system disk (DL0:) or perha= ps more simply just edited to be SY: Also, note that it uses RSXVEC.STB which= should work on the pregenned RL02 RSX11M+. [200,200]DDDRVBLD.CMD ; ; DDDRVBLD.CMD -- RSX-11M-PLUS loadable DD: driver build command file ; ; Created on 01-NOV-2024 at 14:00:05 ; OU:[1,54]DDDRV/-MM/-HD,SY:[1,34]DDDRV/SH/-SP,OU:[1,54]DDDRV=3D SY:[1,24]RSX11M/LB:DDDRV:DDTAB LB:[3,54]RSXVEC.STB/SS LB:[1,1]EXELIB/LB / STACK=3D0 PAR=3DDRVPAR:120000:20000 / If for some reason you need to assemble the DDDRV driver below is the SYSGEN = produced assembly command files. [200,200]DDDRVASM.CMD ; ; DDDRVASM.CMD -- RSX-11M-PLUS loadable DD: driver assembly command file ; ; Created on 01-NOV-2024 at 12:56:02 ; OU:[11,24]DDDRV,LS:[11,34]DDDRV/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,DDDRV OU:[11,24]DDTAB,LS:[11,34]DDTAB/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,DDTAB Good Luck, Mark >=20 > 1. I need some RSX11M+ TKB help (Peter Ekstrom) >=20 > From: Peter Ekstrom > Subject: [cctalk] I need some RSX11M+ TKB help > Date: December 29, 2024 at 6:21:46 PM CST > To: "General Discussion: On-Topic and Off-Topic Posts" > Reply-To: "General Discussion: On-Topic and Off-Topic Posts" >=20 > I have RSX11M+ 4.6 BL87 installed and running on my real PDP 11/23+ and > have gotten DECnet to work as well. But recently a need to access a TU58 > tape has come up, and turns out the DD driver on disk isn't built against > the correct RSX11M.STB file. So I need to, I guess, recreate the DDDRV.TSK > file. I have tried some very simplistic TKB commands but keep getting an > error saying a required file is missing. >=20 > I don't have the sysgen stuff on this disk... What I have comes from the > pregenned RL02 image. >=20 > Does anyone know how the TKB command line should look for this? I know, I > am looking for the easy way out. I have skimmed through some manuals but > nothing has stood out to me (I'm sure I missed it). >=20 > Any help would be greatly appreciated. >=20 > - Peter --===============1655532418568139933==-- From epekstrom@gmail.com Mon Dec 30 22:21:34 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: I need some RSX11M+ TKB help Date: Mon, 30 Dec 2024 17:21:17 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4329329639502433752==" --===============4329329639502433752== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mark, Thank you so much for this information! Seeing this, I was on the right track but was missing a few items. I typed this into a file on the PDP and ran it, but now it turns out I don't have the RSX11M.OLB file, so I guess I am just going to have to work on getting the sysgen stuff onto my disk. Again, thank you very much for the info! -Peter On Mon, Dec 30, 2024 at 3:20=E2=80=AFPM Mark Matlock wrote: > Peter, > The command file below is from a SYSGEN driver build of DDDRV from my > system but I think it should work for yours. Note that OU: is defined by > the SYSGEN process and should be set as a logical to your system disk > (DL0:) or perhaps more simply just edited to be SY: Also, note that it uses > RSXVEC.STB which should work on the pregenned RL02 RSX11M+. > > [200,200]DDDRVBLD.CMD > ; > ; DDDRVBLD.CMD -- RSX-11M-PLUS loadable DD: driver build command file > ; > ; Created on 01-NOV-2024 at 14:00:05 > ; > OU:[1,54]DDDRV/-MM/-HD,SY:[1,34]DDDRV/SH/-SP,OU:[1,54]DDDRV=3D > SY:[1,24]RSX11M/LB:DDDRV:DDTAB > LB:[3,54]RSXVEC.STB/SS > LB:[1,1]EXELIB/LB > / > STACK=3D0 > PAR=3DDRVPAR:120000:20000 > / > > If for some reason you need to assemble the DDDRV driver below is the > SYSGEN produced assembly command files. > > > [200,200]DDDRVASM.CMD > ; > ; DDDRVASM.CMD -- RSX-11M-PLUS loadable DD: driver assembly command file > ; > ; Created on 01-NOV-2024 at 12:56:02 > ; > > OU:[11,24]DDDRV,LS:[11,34]DDDRV/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,DD= DRV > > OU:[11,24]DDTAB,LS:[11,34]DDTAB/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,DD= TAB > > Good Luck, > Mark > > > 1. I need some RSX11M+ TKB help (Peter Ekstrom) > > *From: *Peter Ekstrom > *Subject: **[cctalk] I need some RSX11M+ TKB help* > *Date: *December 29, 2024 at 6:21:46 PM CST > *To: *"General Discussion: On-Topic and Off-Topic Posts" < > cctalk(a)classiccmp.org> > *Reply-To: *"General Discussion: On-Topic and Off-Topic Posts" < > cctalk(a)classiccmp.org> > > I have RSX11M+ 4.6 BL87 installed and running on my real PDP 11/23+ and > have gotten DECnet to work as well. But recently a need to access a TU58 > tape has come up, and turns out the DD driver on disk isn't built against > the correct RSX11M.STB file. So I need to, I guess, recreate the DDDRV.TSK > file. I have tried some very simplistic TKB commands but keep getting an > error saying a required file is missing. > > I don't have the sysgen stuff on this disk... What I have comes from the > pregenned RL02 image. > > Does anyone know how the TKB command line should look for this? I know, I > am looking for the easy way out. I have skimmed through some manuals but > nothing has stood out to me (I'm sure I missed it). > > Any help would be greatly appreciated. > > - Peter > > --===============4329329639502433752==-- From mark@matlockfamily.com Tue Dec 31 15:15:02 2024 From: Mark Matlock To: cctalk@classiccmp.org Subject: [cctalk] Re: I need some RSX11M+ TKB help Date: Tue, 31 Dec 2024 09:14:44 -0600 Message-ID: <2AC14BF2-569F-4BC5-9B46-D8D0CAA9C60D@matlockfamily.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2305450599202697659==" --===============2305450599202697659== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Peter, I just set up a pregenned RL02 based RSX11M+ and took a look at the DD dr= iver. It is a vectored driver and needs to have the /VEC switch to tell it no= t to use the default RSX11M.STB but instead use RSXVEC.STB I was able to load the DDDRV with: >LOA DD:/VEC/PAR=3DGEN/HIGH The /PAR=3DGEN overrides trying to put the driver in DRVPAR that won=E2=80=99= t have room for it unless you reVMR The /HIGH puts the driver at highest available memory in GEN to avoid fragmen= ting the memory in GEN Best, Mark > On Dec 30, 2024, at 4:21=E2=80=AFPM, Peter Ekstrom = wrote: >=20 > Hi Mark, >=20 > Thank you so much for this information! Seeing this, I was on the right tra= ck but was missing a few items. > I typed this into a file on the PDP and ran it, but now it turns out I don'= t have the RSX11M.OLB file, so I guess I am just going to have to work on get= ting the sysgen stuff onto my disk. >=20 > Again, thank you very much for the info! >=20 > -Peter >=20 >=20 > On Mon, Dec 30, 2024 at 3:20=E2=80=AFPM Mark Matlock > wrote: >> Peter, >> The command file below is from a SYSGEN driver build of DDDRV from my s= ystem but I think it should work for yours. Note that OU: is defined by the S= YSGEN process and should be set as a logical to your system disk (DL0:) or pe= rhaps more simply just edited to be SY: Also, note that it uses RSXVEC.STB wh= ich should work on the pregenned RL02 RSX11M+. >>=20 >> [200,200]DDDRVBLD.CMD >> ; >> ; DDDRVBLD.CMD -- RSX-11M-PLUS loadable DD: driver build command file >> ; >> ; Created on 01-NOV-2024 at 14:00:05 >> ; >> OU:[1,54]DDDRV/-MM/-HD,SY:[1,34]DDDRV/SH/-SP,OU:[1,54]DDDRV=3D >> SY:[1,24]RSX11M/LB:DDDRV:DDTAB >> LB:[3,54]RSXVEC.STB/SS >> LB:[1,1]EXELIB/LB >> / >> STACK=3D0 >> PAR=3DDRVPAR:120000:20000 >> / >>=20 >> If for some reason you need to assemble the DDDRV driver below is the SYSG= EN produced assembly command files. >>=20 >>=20 >> [200,200]DDDRVASM.CMD >> ; >> ; DDDRVASM.CMD -- RSX-11M-PLUS loadable DD: driver assembly command file >> ; >> ; Created on 01-NOV-2024 at 12:56:02 >> ; >> OU:[11,24]DDDRV,LS:[11,34]DDDRV/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,D= DDRV >> OU:[11,24]DDTAB,LS:[11,34]DDTAB/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,D= DTAB >>=20 >> Good Luck, >> Mark >>=20 >>>=20 >>> 1. I need some RSX11M+ TKB help (Peter Ekstrom) >>>=20 >>> From: Peter Ekstrom > >>> Subject: [cctalk] I need some RSX11M+ TKB help >>> Date: December 29, 2024 at 6:21:46 PM CST >>> To: "General Discussion: On-Topic and Off-Topic Posts" > >>> Reply-To: "General Discussion: On-Topic and Off-Topic Posts" > >>>=20 >>> I have RSX11M+ 4.6 BL87 installed and running on my real PDP 11/23+ and >>> have gotten DECnet to work as well. But recently a need to access a TU58 >>> tape has come up, and turns out the DD driver on disk isn't built against >>> the correct RSX11M.STB file. So I need to, I guess, recreate the DDDRV.TSK >>> file. I have tried some very simplistic TKB commands but keep getting an >>> error saying a required file is missing. >>>=20 >>> I don't have the sysgen stuff on this disk... What I have comes from the >>> pregenned RL02 image. >>>=20 >>> Does anyone know how the TKB command line should look for this? I know, I >>> am looking for the easy way out. I have skimmed through some manuals but >>> nothing has stood out to me (I'm sure I missed it). >>>=20 >>> Any help would be greatly appreciated. >>>=20 >>> - Peter --===============2305450599202697659==-- From epekstrom@gmail.com Tue Dec 31 15:26:55 2024 From: Peter Ekstrom To: cctalk@classiccmp.org Subject: [cctalk] Re: I need some RSX11M+ TKB help Date: Tue, 31 Dec 2024 10:26:37 -0500 Message-ID: In-Reply-To: <2AC14BF2-569F-4BC5-9B46-D8D0CAA9C60D@matlockfamily.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4166047398433213670==" --===============4166047398433213670== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Mark, Ooo! Awesome! It turns out my setup is missing a lot of things so rebuilding drivers doesn't seem to work. I am looking at redoing the install in a SIMH pdp11 to see if I can get a more complete installation. But this looks like it should solve the immediate problem. I will definitely try this later today when I get back home from work. Thank you! - Peter On Tue, Dec 31, 2024 at 10:14=E2=80=AFAM Mark Matlock wrote: > Peter, > I just set up a pregenned RL02 based RSX11M+ and took a look at the DD > driver. It is a vectored driver and needs to have the /VEC switch to tell > it not to use the default RSX11M.STB but instead use RSXVEC.STB > > I was able to load the DDDRV with: > > >LOA DD:/VEC/PAR=3DGEN/HIGH > > The /PAR=3DGEN overrides trying to put the driver in DRVPAR that won=E2=80= =99t have > room for it unless you reVMR > The /HIGH puts the driver at highest available memory in GEN to avoid > fragmenting the memory in GEN > > Best, > Mark > > On Dec 30, 2024, at 4:21=E2=80=AFPM, Peter Ekstrom = wrote: > > Hi Mark, > > Thank you so much for this information! Seeing this, I was on the right > track but was missing a few items. > I typed this into a file on the PDP and ran it, but now it turns out I > don't have the RSX11M.OLB file, so I guess I am just going to have to work > on getting the sysgen stuff onto my disk. > > Again, thank you very much for the info! > > -Peter > > > On Mon, Dec 30, 2024 at 3:20=E2=80=AFPM Mark Matlock > wrote: > >> Peter, >> The command file below is from a SYSGEN driver build of DDDRV from my >> system but I think it should work for yours. Note that OU: is defined by >> the SYSGEN process and should be set as a logical to your system disk >> (DL0:) or perhaps more simply just edited to be SY: Also, note that it uses >> RSXVEC.STB which should work on the pregenned RL02 RSX11M+. >> >> [200,200]DDDRVBLD.CMD >> ; >> ; DDDRVBLD.CMD -- RSX-11M-PLUS loadable DD: driver build command file >> ; >> ; Created on 01-NOV-2024 at 14:00:05 >> ; >> OU:[1,54]DDDRV/-MM/-HD,SY:[1,34]DDDRV/SH/-SP,OU:[1,54]DDDRV=3D >> SY:[1,24]RSX11M/LB:DDDRV:DDTAB >> LB:[3,54]RSXVEC.STB/SS >> LB:[1,1]EXELIB/LB >> / >> STACK=3D0 >> PAR=3DDRVPAR:120000:20000 >> / >> >> If for some reason you need to assemble the DDDRV driver below is the >> SYSGEN produced assembly command files. >> >> >> [200,200]DDDRVASM.CMD >> ; >> ; DDDRVASM.CMD -- RSX-11M-PLUS loadable DD: driver assembly command file >> ; >> ; Created on 01-NOV-2024 at 12:56:02 >> ; >> >> OU:[11,24]DDDRV,LS:[11,34]DDDRV/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,D= DDRV >> >> OU:[11,24]DDTAB,LS:[11,34]DDTAB/-SP=3DIN:[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,D= DTAB >> >> Good Luck, >> Mark >> >> >> 1. I need some RSX11M+ TKB help (Peter Ekstrom) >> >> *From: *Peter Ekstrom >> *Subject: **[cctalk] I need some RSX11M+ TKB help* >> *Date: *December 29, 2024 at 6:21:46 PM CST >> *To: *"General Discussion: On-Topic and Off-Topic Posts" < >> cctalk(a)classiccmp.org> >> *Reply-To: *"General Discussion: On-Topic and Off-Topic Posts" < >> cctalk(a)classiccmp.org> >> >> I have RSX11M+ 4.6 BL87 installed and running on my real PDP 11/23+ and >> have gotten DECnet to work as well. But recently a need to access a TU58 >> tape has come up, and turns out the DD driver on disk isn't built against >> the correct RSX11M.STB file. So I need to, I guess, recreate the DDDRV.TSK >> file. I have tried some very simplistic TKB commands but keep getting an >> error saying a required file is missing. >> >> I don't have the sysgen stuff on this disk... What I have comes from the >> pregenned RL02 image. >> >> Does anyone know how the TKB command line should look for this? I know, I >> am looking for the easy way out. I have skimmed through some manuals but >> nothing has stood out to me (I'm sure I missed it). >> >> Any help would be greatly appreciated. >> >> - Peter >> >> > --===============4166047398433213670==--