From cctalk@emailtoilet.com Sat Feb 1 00:05:53 2025 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] A baudy tale Date: Sat, 01 Feb 2025 00:05:48 +0000 Message-ID: <173836834899.1304.15578533715867905179@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6441251773461526247==" --===============6441251773461526247== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In the early 70s my employer used stand alone data entry tape units in our re= mote locations. We started with NCR units but then switched to Tally. In the = late afternoon the data would be transmitted to the home office in Chicago fo= r processing. Also using NCR/Tally units. We used Racal-Milgo modems. These t= hings were about the size of a large home stereo receiver. We started at 2400= baud. The units could do 3600 or 4800 (I don=E2=80=99t remember which) if a = circuit board strap was moved.=20 We had locations in many cities/towns all the way out to Montana. It was deci= ded that we needed to have the ability to switch between 2400 and the faster = speed when possible. We did not want to have the locals power off the modem, = open it up, remove a card and move the strap. So I got volunteered to come up= with a plan.=20 I found a place in the modem where I could mount a switch. Luckily the modem = had a sliding panel on the front so the locals would not have to open the box= top. Went to our fleet garage where they had the tools I needed. I made a bu= nch of aluminum brackets for a tiny toggle switch. Added wires to the switch.= =20 It was also decided that we could not trust the locals to do the switch insta= ll. So part of the plan included me going to all the locations and doing the = install. I did not have a car at the time so I got a fleet car. Headed south = to Kentucky then turned west. Don=E2=80=99t remember all the states I hit but= I believe the last place I hit on the way home was Rockford. I remember bein= g on a back road in Montana and I took a picture of my speedometer. I was doi= ng 65. This was when there was a countrywide speed limit of 55. I can=E2=80= =99t be limited by the Man. :) Back at the home office we had 6 NCR/Tally machines and only 4 modems. I buil= t a plug panel box that had everything wired to it and used telephone jack pl= ugs to connect the Tally=E2=80=99s to an available modem. The box also had sw= itches for the modem speed. I now forget how long the whole process took. Put my DeVry AAS degree to good= use. :) --===============6441251773461526247==-- From cclist@sydex.com Sat Feb 1 00:26:06 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 00:20:46 +0000 Message-ID: <91e82788-ada5-43f8-9b3f-8af5446bf47a@sydex.com> In-Reply-To: <173836834899.1304.15578533715867905179@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2189933254841007619==" --===============2189933254841007619== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 1/31/25 16:05, Donald Whittemore via cctalk wrote: > In the early 70s my employer used stand alone data entry tape units in our = remote locations. We started with NCR units but then switched to Tally. In th= e late afternoon the data would be transmitted to the home office in Chicago = for processing. Also using NCR/Tally units. We used Racal-Milgo modems. These= things were about the size of a large home stereo receiver. We started at 24= 00 baud. The units could do 3600 or 4800 (I don=E2=80=99t remember which) if = a circuit board strap was moved.=20 Those rack-mount Milgo units were built like battleships and very well regarded in the industry. My first "high-speed" modem was a Racal/Vadic 3451 that, IIRC, could do 2000 bps when talking to another 3451 using RV's proprietary protocol. --Chuck --===============2189933254841007619==-- From bitwiz@12bitsbest.com Sat Feb 1 01:01:01 2025 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Fri, 31 Jan 2025 18:20:54 -0600 Message-ID: <8a2c3912-c72a-4757-bf3e-dd45d28825b4@12bitsbest.com> In-Reply-To: <173836834899.1304.15578533715867905179@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0133841826267692889==" --===============0133841826267692889== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Definitely baudy the modem were switch hitters even back then=F0=9F=A4=A3 On 1/31/2025 6:05 PM, Donald Whittemore via cctalk wrote: > In the early 70s my employer used stand alone data entry tape units in our = remote locations. We started with NCR units but then switched to Tally. In th= e late afternoon the data would be transmitted to the home office in Chicago = for processing. Also using NCR/Tally units. We used Racal-Milgo modems. These= things were about the size of a large home stereo receiver. We started at 24= 00 baud. The units could do 3600 or 4800 (I don=E2=80=99t remember which) if = a circuit board strap was moved. > > We had locations in many cities/towns all the way out to Montana. It was de= cided that we needed to have the ability to switch between 2400 and the faste= r speed when possible. We did not want to have the locals power off the modem= , open it up, remove a card and move the strap. So I got volunteered to come = up with a plan. > > I found a place in the modem where I could mount a switch. Luckily the mode= m had a sliding panel on the front so the locals would not have to open the b= ox top. Went to our fleet garage where they had the tools I needed. I made a = bunch of aluminum brackets for a tiny toggle switch. Added wires to the switc= h. > > It was also decided that we could not trust the locals to do the switch ins= tall. So part of the plan included me going to all the locations and doing th= e install. I did not have a car at the time so I got a fleet car. Headed sout= h to Kentucky then turned west. Don=E2=80=99t remember all the states I hit b= ut I believe the last place I hit on the way home was Rockford. I remember be= ing on a back road in Montana and I took a picture of my speedometer. I was d= oing 65. This was when there was a countrywide speed limit of 55. I can=E2=80= =99t be limited by the Man. :) > > Back at the home office we had 6 NCR/Tally machines and only 4 modems. I bu= ilt a plug panel box that had everything wired to it and used telephone jack = plugs to connect the Tally=E2=80=99s to an available modem. The box also had = switches for the modem speed. > > I now forget how long the whole process took. Put my DeVry AAS degree to go= od use. :) --===============0133841826267692889==-- From drb@msu.edu Sat Feb 1 01:44:47 2025 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Fri, 31 Jan 2025 20:44:43 -0500 Message-ID: <20250201014443.09EF551E576@yagi.h-net.msu.edu> In-Reply-To: <91e82788-ada5-43f8-9b3f-8af5446bf47a@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6224760644337280450==" --===============6224760644337280450== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Those rack-mount Milgo units were built like battleships and very > well regarded in the industry. My first "high-speed" modem was a > Racal/Vadic 3451 that, IIRC, could do 2000 bps when talking to > another 3451 using RV's proprietary protocol. Vadic had a variant 1200 baud system that wasn't compatible with 212, too, as I recall. De --===============6224760644337280450==-- From doug@doughq.com Sat Feb 1 02:22:31 2025 From: Doug Jackson To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 13:15:22 +1100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6801611603910026624==" --===============6801611603910026624== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I own my entire working career to some random happenings as a kid with interfacing equipment to IBM PC clones using RS232. As a late teenager I used to hang out at the local computer store who sold Toshiba gear. I had a knack for making cables that allowed them to connect brother printers using RS232. One day a person from the local university dropped in asking if they knew anybody who could help interface a piece of lab gear to their Toshiba PC... I got recommended.. Then I helped to write the software to do the analysis work for them... That was in about 1986.. and here we are in 2025 some 40 years later... Remember 2 to 3 3 to 2 7 to 7 4, 5 to 6 6 to 4, 5 8 to 20 And 20 to 8... And if that didn't work. Just tie those pesky handshaking inputs to their nearest output and use software handshaking =F0=9F=98=9C... Built a career on that.. I cringe a little now I understand the intent of the signals. Doug On Fri, 31 Jan 2025, 7:20=E2=80=AFpm Steve Lewis via cctalk, wrote: > Hey all! So, I've found myself studying up on RS-232 this year for a few > reasons. > > I'm mulling over doing an RS232 themed talk at June VCF. Not a super > exciting topic, but I do think that RS232 has an interesting history: In > the SAGE relationship, and as a follow up to (essentially) prior telegraph > communication. > > From what I've read, "50 baud" was a kind of an initial goal to beat, since > that's what the top telegraph operators could achieve (in small burst, > probably not all day). And those operators did have to also deal with > things like start/stop "bits". Maybe it wasn't an intentional goal, but > just that it establishes why "50 baud" is generally the lowest we ever see > mentioned (or, if you go slower than that, might as well use the older > tech). > > Then 75/110/130 baud to have digital-systems interoperate with classic > mechanical teletypes. Going any faster and those systems jam up or > overheat? These weren't yet called "serial ports", so I'm not sure what a > late 50s system would even call their equipment that facilitate this data > exchange (since I'm not sure what kind of crystal-clock they even had > yet). > > Then, was it the SAGE program that demonstrated the idea of doing this kind > of data exchange across copper phone lines? That is, the idea of computers > collaborating not just in a room, but across long distances (miles)? And > doing so by using an audio tone presentation? (they settled on around > 3100MHz, which ended up translating to 300 baud? hence, that's basically > why the first digital to digital system data exchange settled on that baud > rate, which was reliable on both 50 and 60Hz power systems, and > meaningfully faster than prior 110 baud - so a good milestone to turn it > into a product, which was the Bell Model 103?). > > I couldn't find much details (like a manual) on the Bell 101 equipment > (anyone seen one or have a manual?). But I did find the Bell 103 manual - > the photo of its innards is grainy, so I don't understand how the Bell 103 > did 300 baud without a UART (and one of the pinout lines I see did run > power, so not sure if that's-yet RS232 or not; I know RS232 was evolving > right at that same time circa 1962). I've about the 1970ish TR1402 > initial DIP UART, with anything prior being an experiment (like a full > board concept by DEC). > > I know from 1962, both RS232 and ASCII standards still took maybe another > decade to really gain traction as standards (at least, from what I've > read). Getting the world to comply with any standard always takes a lot of > effort (for a practical reason of everyone still having invested in the > older tooling that was still functional). But it's interesting how those > two standards are still in use (not in their original form, but least the > 1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs. > > Does anyone know of any grocery stories using RS232 in the 1960s? I think > barcode scanning was just introduced in that era. I can just imagine a > smart grocery store owner, in the backroom programming their minicomputer > for payroll and inventory management. In FORTRAN and without a CRT? > Actually, in the 60s, I think included software would be negotiated with > the provider of the computer (well, I'm not sure how that differed between > minis and mainframes). > > I know early microcomputers used RS232 for keyboards (1974-1976 era). The > IBM PC keyboard is essentially another form of serial. > > Well, sorry for the rambling - have other RS232 related questions, but > first wanted to focus on the historical aspects (and see if I'm somewhat on > the right track at least). > > -Steve > --===============6801611603910026624==-- From roger@arrick.com Sat Feb 1 02:31:20 2025 From: roger arrick To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 02:31:10 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3898157100824562835==" --===============3898157100824562835== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In 1977, at age 16, I went to work for Noakes Data Communications in Irving T= exas. We built an 8080 industrial computer, made modems, and repaired lots of comm = gear. RS232 was what we lived and breathed. And back then almost all the control = signals were actually used, not just jumpered or ignored. I remember thinking at the time that the bipolar signal levels were such a wa= ste of time for office and personal computers. They should have just gone to= a TTL version for everything local like printers, and modems, and keyboards = and terminals. Back then we had to use 1488 and 1489 level converters with += /-12v power supplies. Such a costly hassle. Of course, many years later we = got MAX232 with 4 .1uf caps and 5v which solved the cost problem. I still have my blue breakout box from that year. It cost something like $30= 0 at the time which was the price of a used car =F0=9F=99=82 I documented the company here: https://www.rogerarrick.com/noakes/ [https://www.rogerarrick.com/noakes/noakes_label.png] Noakes Data Communications - Irving Texas - 1970s-1980s Noakes Data Communications. 1 May 2023. Click images for larger view 1973-198= 7 Noakes Data Communications 3330 Stovall St, Irving, TX 75061 214-790-1050 www.rogerarrick.com -- Roger Arrick -- Tyler, Texas, USA -- Roger(a)Arrick.com -- ________________________________ From: Doug Jackson via cctalk Sent: Friday, January 31, 2025 8:15 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Steve Lewis ; Doug Jackson Subject: [cctalk] Re: RS232 then and now I own my entire working career to some random happenings as a kid with interfacing equipment to IBM PC clones using RS232. As a late teenager I used to hang out at the local computer store who sold Toshiba gear. I had a knack for making cables that allowed them to connect brother printers using RS232. One day a person from the local university dropped in asking if they knew anybody who could help interface a piece of lab gear to their Toshiba PC... I got recommended.. Then I helped to write the software to do the analysis work for them... That was in about 1986.. and here we are in 2025 some 40 years later... Remember 2 to 3 3 to 2 7 to 7 4, 5 to 6 6 to 4, 5 8 to 20 And 20 to 8... And if that didn't work. Just tie those pesky handshaking inputs to their nearest output and use software handshaking =F0=9F=98=9C... Built a career on that.. I cringe a little now I understand the intent of the signals. Doug On Fri, 31 Jan 2025, 7:20=E2=80=AFpm Steve Lewis via cctalk, wrote: > Hey all! So, I've found myself studying up on RS-232 this year for a few > reasons. > > I'm mulling over doing an RS232 themed talk at June VCF. Not a super > exciting topic, but I do think that RS232 has an interesting history: In > the SAGE relationship, and as a follow up to (essentially) prior telegraph > communication. > > From what I've read, "50 baud" was a kind of an initial goal to beat, since > that's what the top telegraph operators could achieve (in small burst, > probably not all day). And those operators did have to also deal with > things like start/stop "bits". Maybe it wasn't an intentional goal, but > just that it establishes why "50 baud" is generally the lowest we ever see > mentioned (or, if you go slower than that, might as well use the older > tech). > > Then 75/110/130 baud to have digital-systems interoperate with classic > mechanical teletypes. Going any faster and those systems jam up or > overheat? These weren't yet called "serial ports", so I'm not sure what a > late 50s system would even call their equipment that facilitate this data > exchange (since I'm not sure what kind of crystal-clock they even had > yet). > > Then, was it the SAGE program that demonstrated the idea of doing this kind > of data exchange across copper phone lines? That is, the idea of computers > collaborating not just in a room, but across long distances (miles)? And > doing so by using an audio tone presentation? (they settled on around > 3100MHz, which ended up translating to 300 baud? hence, that's basically > why the first digital to digital system data exchange settled on that baud > rate, which was reliable on both 50 and 60Hz power systems, and > meaningfully faster than prior 110 baud - so a good milestone to turn it > into a product, which was the Bell Model 103?). > > I couldn't find much details (like a manual) on the Bell 101 equipment > (anyone seen one or have a manual?). But I did find the Bell 103 manual - > the photo of its innards is grainy, so I don't understand how the Bell 103 > did 300 baud without a UART (and one of the pinout lines I see did run > power, so not sure if that's-yet RS232 or not; I know RS232 was evolving > right at that same time circa 1962). I've about the 1970ish TR1402 > initial DIP UART, with anything prior being an experiment (like a full > board concept by DEC). > > I know from 1962, both RS232 and ASCII standards still took maybe another > decade to really gain traction as standards (at least, from what I've > read). Getting the world to comply with any standard always takes a lot of > effort (for a practical reason of everyone still having invested in the > older tooling that was still functional). But it's interesting how those > two standards are still in use (not in their original form, but least the > 1967 revisions) - extending from Baudot.and late 1800s-tech on telegraphs. > > Does anyone know of any grocery stories using RS232 in the 1960s? I think > barcode scanning was just introduced in that era. I can just imagine a > smart grocery store owner, in the backroom programming their minicomputer > for payroll and inventory management. In FORTRAN and without a CRT? > Actually, in the 60s, I think included software would be negotiated with > the provider of the computer (well, I'm not sure how that differed between > minis and mainframes). > > I know early microcomputers used RS232 for keyboards (1974-1976 era). The > IBM PC keyboard is essentially another form of serial. > > Well, sorry for the rambling - have other RS232 related questions, but > first wanted to focus on the historical aspects (and see if I'm somewhat on > the right track at least). > > -Steve > --===============3898157100824562835==-- From macro@orcam.me.uk Sat Feb 1 03:37:28 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 03:37:21 +0000 Message-ID: In-Reply-To: <3DAD564A-3091-4094-81D7-00F205D7A968@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8274158209007556052==" --===============8274158209007556052== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 31 Jan 2025, Paul Koning wrote: > > FWIW I was able to get reliable serial communication under Linux of up to= =20 > > 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz=20 > > despite that line drivers used with said hardware (soldered onboard) were= =20 > > spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven = > > operation, but then the UARTs used had decent FIFO sizes of 128 character= s=20 > > and the FIFO trigger level for the interrupt was reasonably set. > >=20 > > Finally at 4.0Mbps data corruption reproducibly triggered, but it was=20 > > garbled rather than lost characters, so I conclude the reason was either = > > line drivers finally giving up or the transmission frequency hitting the = > > bandwidth limit of the serial communication cable used. >=20 > Was that with an actual RS232 port, i.e., a device using RS232 signal=20 > levels, or a "TTL" logic level serial port? I'm guessing the latter. I'm not sure what you mean by 'a "TTL" logic level serial port', please=20 elaborate. Do you mean signalling used between the UART and line drivers=20 by any chance, such as with a serial connection made between UARTs without=20 actual line drivers in between? I've only seen such serial connections between onboard devices, such as a=20 SoC's onchip UART wired to an FTDI-like device soldered next to it on the=20 PCB for a USB serial console, which seems an industry's recent workaround=20 with development hardware for the usual lack of serial ports with modern=20 general-purpose computers. I don't expect this to work very well over a=20 cable unless very short. > In my high speed experiments, I found that the limit for RS232 data=20 > rates comes from the relatively slow rise/fall times implemented in=20 > RS232 drivers. If you have a port that uses logic levels the=20 > transitions are likely to be much faster so loss of signal integrity=20 > occurs only at much higher speeds. With the RS232 drivers I have used=20 > (MAX3222), 250 kbps is roughly the upper limit. The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F=20 line driver, which according to the manufacturer's datasheet signals at=20 =C2=B15V minimum transmitter voltage levels and accepts up to =C2=B125V recei= ver=20 voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT V.28/V.24=20 Specifications for VCC at +3.3V =C2=B110% and +5V =C2=B110% Operations." Whi= le the=20 transmitter voltage levels are not the highest recognised by the standard=20 I do believe this line driver does comply with RS-232. As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps,"=20 and according to my findings quoted above it is indeed the case (and well=20 beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a mental=20 slip I suppose.] NB I've also used the TI TRS3122E line driver, suitable for operation=20 with 1.8V signalling per my requirement, and it is also documented to=20 handle "data rates up to 1000kbps, while maintaining RS-232-compatible=20 output levels." I haven't got a chance to go beyond 230400bps with this=20 device though, but these two samples do suggest that supported operation=20 at 1Mbps isn't that uncommon for currently available RS-232 line drivers. I've looked up the MAX3222 datasheet and it does say 250kbps max though; I guess it's older technology then? Does this answer your question? Maciej --===============8274158209007556052==-- From imp@bsdimp.com Sat Feb 1 04:12:06 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Fri, 31 Jan 2025 21:11:46 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5456282543311081962==" --===============5456282543311081962== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Jan 31, 2025, 8:37 PM Maciej W. Rozycki via cctalk < cctalk(a)classiccmp.org> wrote: > On Fri, 31 Jan 2025, Paul Koning wrote: > > > > FWIW I was able to get reliable serial communication under Linux of up > to > > > 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at > 62.5MHz > > > despite that line drivers used with said hardware (soldered onboard) > were > > > spec'd for up to 1MHz only[1]. This was with plain PIO > interrupt-driven > > > operation, but then the UARTs used had decent FIFO sizes of 128 > characters > > > and the FIFO trigger level for the interrupt was reasonably set. > > > > > > Finally at 4.0Mbps data corruption reproducibly triggered, but it was > > > garbled rather than lost characters, so I conclude the reason was > either > > > line drivers finally giving up or the transmission frequency hitting > the > > > bandwidth limit of the serial communication cable used. > > > > Was that with an actual RS232 port, i.e., a device using RS232 signal > > levels, or a "TTL" logic level serial port? I'm guessing the latter. > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > elaborate. Do you mean signalling used between the UART and line drivers > by any chance, such as with a serial connection made between UARTs without > actual line drivers in between? > Yes. That's the overwhelming majority of usage these days. At least for me when not dealing with retro gear. I've only seen such serial connections between onboard devices, such as a > SoC's onchip UART wired to an FTDI-like device soldered next to it on the > PCB for a USB serial console, which seems an industry's recent workaround > with development hardware for the usual lack of serial ports with modern > general-purpose computers. I don't expect this to work very well over a > cable unless very short. > Yea, line drivers are to make runs over a few feet. Warner > In my high speed experiments, I found that the limit for RS232 data > > rates comes from the relatively slow rise/fall times implemented in > > RS232 drivers. If you have a port that uses logic levels the > > transitions are likely to be much faster so loss of signal integrity > > occurs only at much higher speeds. With the RS232 drivers I have used > > (MAX3222), 250 kbps is roughly the upper limit. > > The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F > line driver, which according to the manufacturer's datasheet signals at > ±5V minimum transmitter voltage levels and accepts up to ±25V receiver > voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT V.28/V.24 > Specifications for VCC at +3.3V ±10% and +5V ±10% Operations." While the > transmitter voltage levels are not the highest recognised by the standard > I do believe this line driver does comply with RS-232. > > As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps," > and according to my findings quoted above it is indeed the case (and well > beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a mental > slip I suppose.] > > NB I've also used the TI TRS3122E line driver, suitable for operation > with 1.8V signalling per my requirement, and it is also documented to > handle "data rates up to 1000kbps, while maintaining RS-232-compatible > output levels." I haven't got a chance to go beyond 230400bps with this > device though, but these two samples do suggest that supported operation > at 1Mbps isn't that uncommon for currently available RS-232 line drivers. > > I've looked up the MAX3222 datasheet and it does say 250kbps max though; > I guess it's older technology then? > > Does this answer your question? > > Maciej > --===============5456282543311081962==-- From classiccmp@earthlink.net Sat Feb 1 06:28:19 2025 From: "David C. Jenner" To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple & History (Was: Microsoft 50 years) Date: Fri, 31 Jan 2025 22:23:08 -0800 Message-ID: <7ae8bff7-cd32-4eff-9693-fe3fc691e48b@earthlink.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5112813308195204056==" --===============5112813308195204056== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You mean you don't have an old Mac that can do all this? I just went=20 through collecting old data on 3 old Mac OS X versions and Mac OS 9 on a=20 G4 tower that's 25 years old. It also runs an older, very expensive=20 Nikon film scanner that works great. Networking on this still works=20 great, and I can send to newer Macs/Windows as needed. Dave On 1/31/25 2:29 PM, Zane Healy via cctalk wrote: > On Jan 31, 2025, at 11:24 AM, Cameron Kelly via cctalk wrote: >> >> I'm glad Microsoft is paying respects to their history. It feels like Appl= e barely does, or acts as if things that they produced before their current p= roduct cycle don't exist. >=20 > My primary problem is that they do things that are openly hostile to those = of us that have been running on the Mac for 30+ years. Recently I needed to = access some older data, and it turned into a large project when I discovered = that not only couldn=E2=80=99t newer versions of MacOS not access the floppie= s, they couldn=E2=80=99t access Mac CD-R=E2=80=99s. I ended up copying every= thing over to a Hard Drive 100=E2=80=99s of floppies and CD=E2=80=99s from DO= S and Mac. Then I discovered that the latest version of Microsoft Office *ON= THE MAC* can=E2=80=99t read MS Office 4.2 documents (such as MS Word 6.0). = In the end I had to create emulation environments for my old Mac and DOS syst= ems on my current Mac laptop. It=E2=80=99s been useful having access to the = original dBase databases, rather than trying to access the converted FileMake= r Pro databases. >=20 > Of course prior to this, in the early days of Mac OS X, they dropped suppor= t for AppleTalk, then AppleTalk printing. Then MacOS 9 apps, and now more re= cently 32-bit MacOS Apps. >=20 > Of course Windows isn=E2=80=99t perfect for Backwards compatibility, a lot = of us have to keep Windows XP running (in my case as a VM on my 2010 Mac Pro)= , in order to drive things like vintage film scanners. >=20 > Zane >=20 >=20 >=20 --===============5112813308195204056==-- From lewissa78@gmail.com Sat Feb 1 08:42:01 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 02:41:47 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3889146326740019241==" --===============3889146326740019241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > elaborate. Do you mean signalling used between the UART and line drivers > by any chance, such as with a serial connection made between UARTs without That confused me at first as well. As you concluded: yes, not a "classic" (or "real" serial port), but something adjusted to TTL-logic levels. Reading the async-expansion for the IBM 5110, it talks about -25 to +25V (the original spec of RS232?). On the 1980 Color Computer 1, I noticed it uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to sip less less power, and I think RS-232 revisions allowed for as low as -3V to +3V swings? So those -5/+5V or 3.3 integrations get referred to as more modern "TTL logic level serial port" (such as generally a USB/serial adapter) to contrast from prior legacy devices. But I suppose it means these devices have less range (max cable distance) than the original spec? I don't recall all the specifics of the original SAGE, but I think it was an array of IBM704s across buildings. Or at least across floors of a building. So the gobs of voltage maybe made sense back then. If P=IV, the using less Voltage should conserve some power, while also being faster to "swing" (transition +/-) and allow greater speeds (but at more limited range). On Fri, Jan 31, 2025 at 9:37 PM Maciej W. Rozycki via cctalk < cctalk(a)classiccmp.org> wrote: > On Fri, 31 Jan 2025, Paul Koning wrote: > > > > FWIW I was able to get reliable serial communication under Linux of up > to > > > 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at > 62.5MHz > > > despite that line drivers used with said hardware (soldered onboard) > were > > > spec'd for up to 1MHz only[1]. This was with plain PIO > interrupt-driven > > > operation, but then the UARTs used had decent FIFO sizes of 128 > characters > > > and the FIFO trigger level for the interrupt was reasonably set. > > > > > > Finally at 4.0Mbps data corruption reproducibly triggered, but it was > > > garbled rather than lost characters, so I conclude the reason was > either > > > line drivers finally giving up or the transmission frequency hitting > the > > > bandwidth limit of the serial communication cable used. > > > > Was that with an actual RS232 port, i.e., a device using RS232 signal > > levels, or a "TTL" logic level serial port? I'm guessing the latter. > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > elaborate. Do you mean signalling used between the UART and line drivers > by any chance, such as with a serial connection made between UARTs without > actual line drivers in between? > > I've only seen such serial connections between onboard devices, such as a > SoC's onchip UART wired to an FTDI-like device soldered next to it on the > PCB for a USB serial console, which seems an industry's recent workaround > with development hardware for the usual lack of serial ports with modern > general-purpose computers. I don't expect this to work very well over a > cable unless very short. > > > In my high speed experiments, I found that the limit for RS232 data > > rates comes from the relatively slow rise/fall times implemented in > > RS232 drivers. If you have a port that uses logic levels the > > transitions are likely to be much faster so loss of signal integrity > > occurs only at much higher speeds. With the RS232 drivers I have used > > (MAX3222), 250 kbps is roughly the upper limit. > > The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F > line driver, which according to the manufacturer's datasheet signals at > ±5V minimum transmitter voltage levels and accepts up to ±25V receiver > voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT V.28/V.24 > Specifications for VCC at +3.3V ±10% and +5V ±10% Operations." While the > transmitter voltage levels are not the highest recognised by the standard > I do believe this line driver does comply with RS-232. > > As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps," > and according to my findings quoted above it is indeed the case (and well > beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a mental > slip I suppose.] > > NB I've also used the TI TRS3122E line driver, suitable for operation > with 1.8V signalling per my requirement, and it is also documented to > handle "data rates up to 1000kbps, while maintaining RS-232-compatible > output levels." I haven't got a chance to go beyond 230400bps with this > device though, but these two samples do suggest that supported operation > at 1Mbps isn't that uncommon for currently available RS-232 line drivers. > > I've looked up the MAX3222 datasheet and it does say 250kbps max though; > I guess it's older technology then? > > Does this answer your question? > > Maciej > --===============3889146326740019241==-- From lars@nocrew.org Sat Feb 1 08:52:13 2025 From: Lars Brinkhoff To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Sat, 01 Feb 2025 08:13:11 +0000 Message-ID: <7w8qqqytew.fsf@junk.nocrew.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2416400950698184503==" --===============2416400950698184503== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think these 1979 photos are interesting. https://web.archive.org/web/20200815021031/http://www.sound-photo.com/microso= ft/microsoft.htm --===============2416400950698184503==-- From lewissa78@gmail.com Sat Feb 1 09:36:10 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 03:35:55 -0600 Message-ID: In-Reply-To: <6d8c9013-132c-42f0-a012-275098f63512@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0461163676551043830==" --===============0461163676551043830== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I wasn't aware of current loop, been reading about it today. I also came across an article on how RS232 is reasonable for non-noisy environments, but for a busy industrial floor interference can become an issue. Read through some old GoogleGroup archive, discussions in 1997 of the buggy 8250 support in the IBM BIOS (or rather, the tragic situation of the ROM BIOS adjusted to address the bug, but then couldn't fully utilize the fixed hardware that came later). I tried using the X00 FOSSIL driver on the '286 to see if it sped up performance, and it actually did not (it did seem to work but I had to actually step down to 38400 instead of 57600 to get a reliable data exchange). But if I understand the intent of the FOSSIL driver, it essentially adds a user defined receive/send buffer beyond whatever the UART might provide. And that is convenient, since all programs that use the serial port could benefit from that (or have to implement their own). I was running MSD and noticed it could detect if a mouse is a present, and I wondered how does that work on a general serial port and pre-PNP days? And a comment here made me realize it probably "play games" with one of those unused pins like RI or DTR. I imagine Microsoft Mouse started some convention along those lines that others followed? I could see at least identifying the attached device is not a modem. Thanks for the collective clarification that, from its beginning, RS232 was focused on supporting modem interaction, moreso than raw data exchange. On Fri, Jan 31, 2025 at 5:26 AM Frank Leonhardt via cctalk < cctalk(a)classiccmp.org> wrote: > > On 31/01/2025 08:20, Steve Lewis via cctalk wrote: > > Hey all! So, I've found myself studying up on RS-232 this year for a few > > reasons. > > > > I'm mulling over doing an RS232 themed talk at June VCF. Not a super > > exciting topic, but I do think that RS232 has an interesting history: In > > the SAGE relationship, and as a follow up to (essentially) prior > telegraph > > communication. > > > > >From what I've read, "50 baud" was a kind of an initial goal to beat, > since > > that's what the top telegraph operators could achieve (in small burst, > > probably not all day). And those operators did have to also deal with > > things like start/stop "bits". Maybe it wasn't an intentional goal, but > > just that it establishes why "50 baud" is generally the lowest we ever > see > > mentioned (or, if you go slower than that, might as well use the older > > tech). > > > > Then 75/110/130 baud to have digital-systems interoperate with classic > > mechanical teletypes. Going any faster and those systems jam up or > > overheat? These weren't yet called "serial ports", so I'm not sure what > a > > late 50s system would even call their equipment that facilitate this data > > exchange (since I'm not sure what kind of crystal-clock they even had > > yet). > > > > Then, was it the SAGE program that demonstrated the idea of doing this > kind > > of data exchange across copper phone lines? That is, the idea of > computers > > collaborating not just in a room, but across long distances (miles)? And > > doing so by using an audio tone presentation? (they settled on around > > 3100MHz, which ended up translating to 300 baud? hence, that's basically > > why the first digital to digital system data exchange settled on that > baud > > rate, which was reliable on both 50 and 60Hz power systems, and > > meaningfully faster than prior 110 baud - so a good milestone to turn it > > into a product, which was the Bell Model 103?). > > > > I couldn't find much details (like a manual) on the Bell 101 equipment > > (anyone seen one or have a manual?). But I did find the Bell 103 manual > - > > the photo of its innards is grainy, so I don't understand how the Bell > 103 > > did 300 baud without a UART (and one of the pinout lines I see did run > > power, so not sure if that's-yet RS232 or not; I know RS232 was evolving > > right at that same time circa 1962). I've about the 1970ish TR1402 > > initial DIP UART, with anything prior being an experiment (like a full > > board concept by DEC). > > > > I know from 1962, both RS232 and ASCII standards still took maybe another > > decade to really gain traction as standards (at least, from what I've > > read). Getting the world to comply with any standard always takes a lot > of > > effort (for a practical reason of everyone still having invested in the > > older tooling that was still functional). But it's interesting how those > > two standards are still in use (not in their original form, but least the > > 1967 revisions) - extending from Baudot.and late 1800s-tech on > telegraphs. > > > > Does anyone know of any grocery stories using RS232 in the 1960s? I > think > > barcode scanning was just introduced in that era. I can just imagine a > > smart grocery store owner, in the backroom programming their minicomputer > > for payroll and inventory management. In FORTRAN and without a CRT? > > Actually, in the 60s, I think included software would be negotiated with > > the provider of the computer (well, I'm not sure how that differed > between > > minis and mainframes). > > > > I know early microcomputers used RS232 for keyboards (1974-1976 era). > The > > IBM PC keyboard is essentially another form of serial. > > > > Well, sorry for the rambling - have other RS232 related questions, but > > first wanted to focus on the historical aspects (and see if I'm somewhat > on > > the right track at least). > > > > -Steve > > > Hi Steve, > > I don't find RS232 boring - it's what started my career :-) > > A couple of points you might like to consider, which you may already > know but stuff you've said above doesn't spell it out: > > RS232 is not serial - make yourself clear. Before RS232 the same data > format was used in current loop (often 20mA or 60mA). > > RS232 (AKA V.24) is only understandable when you realise it was > connecting a terminal (or later computer) to a modem. It's very > specific, yet like most technology has been subverted for other > purposes. I've kept at last one full RS232 modem in my loft (it was > government surplus, and I used to to run a BBS in 1980). Things got > weird later, particularly with the Hayes Smartmodem, but modems were > dumb devices. The lines went straight through. There were two > oscillators (for FM) and the appropriate one was switched in by the TX > line being high or low. Likewise the data separator looked for a high or > low tone and flipped RX between -12V and +12V. These were all individual > boards! > > Then there's the line control board, which operated RI when a high > voltage was connected and DTR looped the phone line through. > > Most of this makes no sense in other applications! > > RS232, being voltage based, was only suitable for short distances > compared to current loop. Basic electronics - voltages drop over > distance due to resistance so after a while you don't know what you'll > get at the other end. A current flowing through a loop being turned off > and on has to be the same when measured at any point on the loop. The > "break key", of course, simply broke the current loop while you held it > down signalling whatever was required. > > The speed of transmission is interesting. A purely analogue modem (or > current loop) can operate at any speed as long as both ends agree. The > original limit was the mechanical terminal. 110 baud makes sense as a > target as it's a nice round 10cps for ASCII - start bit, and seven data > bits, one parity bit and two stop bits. Two stop bits were necessary for > mechanical timing. > > If you do five bit Baudot with no parity you've got about 75 baud for > 10cps. When the V.23 standard was being developed (asymmetric 1200/75) > it was considered that 75bps was the fastest typing speed required which > is another reason why 50 was the bear minimum and 75 a better target. My > the time I was involved 75 was the "standard" for teleprinters so most > people couldn't out-type them. > > UART? Crystal? Much later. Originally the timing came from a fixed speed > motor in the terminal. Have a look at how a teleprinter works. It wasn't > uncommon to adjust the speed of the motor at both ends to go as fast as > it could without errors. > > And for amusement, someone wrote in the PCW saying they'd heard a > salesperson at Radio Shack trying to convince a punter that RS is RS232 > stood for Radio Shack. > > Hope the talk goes well. I assume you're a long way off - otherwise you > could borrow some of the kit hereabouts (but it's Very Heavy). > > Regards, Frank. > --===============0461163676551043830==-- From artgodwin@gmail.com Sat Feb 1 09:56:06 2025 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 09:55:48 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1987925285883407858==" --===============1987925285883407858== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I wouldn't call them 'adjusted' to TTL levels. They're simply the levels that are used between UART and line buffers, which, yes, are TTL but not something arranged particularly for these devices. Of course, they aren't any more suitable for external connections than any other internal board-level signal. It's a hack, useful for making a short connection but it's the USB part that's intended to be exposed externally. Note that they're also inverted relative to the RS232 levels because line buffers convert logic 1 to -15V. Some USB-serial chips have the ability to choose whether the signals are inverted. They also tolerate negative input voltages. This allows them to interoperate with buffered lines which interpret 0v as a negative voltage, but with extremely bad noise margins. On Sat, Feb 1, 2025 at 8:48=E2=80=AFAM Steve Lewis via cctalk wrote: > > > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > > elaborate. Do you mean signalling used between the UART and line drivers > > by any chance, such as with a serial connection made between UARTs > without > > > > That confused me at first as well. As you concluded: yes, not a "classic" > (or "real" serial port), but something adjusted to TTL-logic levels. > Reading the async-expansion for the IBM 5110, it talks about -25 to +25V > (the original spec of RS232?). On the 1980 Color Computer 1, I noticed it > uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to > sip less less power, and I think RS-232 revisions allowed for as low as -3V > to +3V swings? So those -5/+5V or 3.3 integrations get referred to as > more modern "TTL logic level serial port" (such as generally a USB/serial > adapter) to contrast from prior legacy devices. > > But I suppose it means these devices have less range (max cable distance) > than the original spec? I don't recall all the specifics of the original > SAGE, but I think it was an array of IBM704s across buildings. Or at least > across floors of a building. So the gobs of voltage maybe made sense back > then. If P=3DIV, the using less Voltage should conserve some power, while > also being faster to "swing" (transition +/-) and allow greater speeds (but > at more limited range). > > > > > > > > > On Fri, Jan 31, 2025 at 9:37=E2=80=AFPM Maciej W. Rozycki via cctalk < > cctalk(a)classiccmp.org> wrote: > > > On Fri, 31 Jan 2025, Paul Koning wrote: > > > > > > FWIW I was able to get reliable serial communication under Linux of > up > > to > > > > 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at > > 62.5MHz > > > > despite that line drivers used with said hardware (soldered onboard) > > were > > > > spec'd for up to 1MHz only[1]. This was with plain PIO > > interrupt-driven > > > > operation, but then the UARTs used had decent FIFO sizes of 128 > > characters > > > > and the FIFO trigger level for the interrupt was reasonably set. > > > > > > > > Finally at 4.0Mbps data corruption reproducibly triggered, but it was > > > > garbled rather than lost characters, so I conclude the reason was > > either > > > > line drivers finally giving up or the transmission frequency hitting > > the > > > > bandwidth limit of the serial communication cable used. > > > > > > Was that with an actual RS232 port, i.e., a device using RS232 signal > > > levels, or a "TTL" logic level serial port? I'm guessing the latter. > > > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > > elaborate. Do you mean signalling used between the UART and line drivers > > by any chance, such as with a serial connection made between UARTs > without > > actual line drivers in between? > > > > I've only seen such serial connections between onboard devices, such as > a > > SoC's onchip UART wired to an FTDI-like device soldered next to it on the > > PCB for a USB serial console, which seems an industry's recent workaround > > with development hardware for the usual lack of serial ports with modern > > general-purpose computers. I don't expect this to work very well over a > > cable unless very short. > > > > > In my high speed experiments, I found that the limit for RS232 data > > > rates comes from the relatively slow rise/fall times implemented in > > > RS232 drivers. If you have a port that uses logic levels the > > > transitions are likely to be much faster so loss of signal integrity > > > occurs only at much higher speeds. With the RS232 drivers I have used > > > (MAX3222), 250 kbps is roughly the upper limit. > > > > The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F > > line driver, which according to the manufacturer's datasheet signals at > > =C2=B15V minimum transmitter voltage levels and accepts up to =C2=B125V r= eceiver > > voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT > V.28/V.24 > > Specifications for VCC at +3.3V =C2=B110% and +5V =C2=B110% Operations." = While the > > transmitter voltage levels are not the highest recognised by the standard > > I do believe this line driver does comply with RS-232. > > > > As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps," > > and according to my findings quoted above it is indeed the case (and well > > beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a > mental > > slip I suppose.] > > > > NB I've also used the TI TRS3122E line driver, suitable for operation > > with 1.8V signalling per my requirement, and it is also documented to > > handle "data rates up to 1000kbps, while maintaining RS-232-compatible > > output levels." I haven't got a chance to go beyond 230400bps with this > > device though, but these two samples do suggest that supported operation > > at 1Mbps isn't that uncommon for currently available RS-232 line drivers. > > > > I've looked up the MAX3222 datasheet and it does say 250kbps max though; > > I guess it's older technology then? > > > > Does this answer your question? > > > > Maciej > > > --===============1987925285883407858==-- From classiccmp@fjl.co.uk Sat Feb 1 10:31:52 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 10:31:44 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0409103493130744398==" --===============0409103493130744398== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 31/01/2025 18:55, Steve Lewis via cctalk wrote: > re: on UARTS.. > > Didn't it basically standardize the process of that task of converting a > byte to bits and vice versa, in a fashion specified by RS232? > And do so at the above-300-baud rates, since that task was too stressful > for 1MHz processors to pull off on its own (in addition to whatever else it > was doing, like flashing a cursor on a CRT?)? > And the buffer just gave grace time for if one of the systems got overly > busy? (like when scrolling said CRT)? > > Might a UART be an early example of an ASIC? As I've mentioned elsewhere, "UART" is Intel's term for an ACIA; and other names exist from other manufacturers. Just a buffered shift register and other logic in the same chip. I wouldn't call it an ASIC myself, but other definitions are available. It isn't specific to a user application. I built a disk controller using a 6550 to serialise the data so you can't even say it's specific to RS-232. And before MSI you could (and did) serialise data in a standard from using a shift register. Before that discreet logic. Before that transistors, and before that mechanically. So I don't think it's fair to say that single chip UARTS/ACIA/SCI/SCC standardised anything - they just made things easier to implement using a standard that existed for twenty years or more. --===============0409103493130744398==-- From joe@barrera.org Sat Feb 1 12:39:05 2025 From: "Joseph S. Barrera III" To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple & History (Was: Microsoft 50 years) Date: Sat, 01 Feb 2025 04:38:47 -0800 Message-ID: In-Reply-To: <7ae8bff7-cd32-4eff-9693-fe3fc691e48b@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3470260162699744774==" --===============3470260162699744774== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Half the time, I hear from my family, "why do you spend all this time working with obsolete stuff?" The other half, I hear, "if you can do it, why can't I? Don't make it complicated, just tell me the two or three steps I need to do." On Fri, Jan 31, 2025 at 10:28=E2=80=AFPM David C. Jenner via cctalk < cctalk(a)classiccmp.org> wrote: > You mean you don't have an old Mac that can do all this? I just went > through collecting old data on 3 old Mac OS X versions and Mac OS 9 on a > G4 tower that's 25 years old. It also runs an older, very expensive > Nikon film scanner that works great. Networking on this still works > great, and I can send to newer Macs/Windows as needed. > > Dave > > On 1/31/25 2:29 PM, Zane Healy via cctalk wrote: > > On Jan 31, 2025, at 11:24 AM, Cameron Kelly via cctalk < > cctalk(a)classiccmp.org> wrote: > >> > >> I'm glad Microsoft is paying respects to their history. It feels like > Apple barely does, or acts as if things that they produced before their > current product cycle don't exist. > > > > My primary problem is that they do things that are openly hostile to > those of us that have been running on the Mac for 30+ years. Recently I > needed to access some older data, and it turned into a large project when I > discovered that not only couldn=E2=80=99t newer versions of MacOS not acces= s the > floppies, they couldn=E2=80=99t access Mac CD-R=E2=80=99s. I ended up copy= ing everything > over to a Hard Drive 100=E2=80=99s of floppies and CD=E2=80=99s from DOS an= d Mac. Then I > discovered that the latest version of Microsoft Office *ON THE MAC* can=E2= =80=99t > read MS Office 4.2 documents (such as MS Word 6.0). In the end I had to > create emulation environments for my old Mac and DOS systems on my current > Mac laptop. It=E2=80=99s been useful having access to the original dBase > databases, rather than trying to access the converted FileMaker Pro > databases. > > > > Of course prior to this, in the early days of Mac OS X, they dropped > support for AppleTalk, then AppleTalk printing. Then MacOS 9 apps, and now > more recently 32-bit MacOS Apps. > > > > Of course Windows isn=E2=80=99t perfect for Backwards compatibility, a lo= t of us > have to keep Windows XP running (in my case as a VM on my 2010 Mac Pro), in > order to drive things like vintage film scanners. > > > > Zane > > > > > > > > --===============3470260162699744774==-- From cliendo@gmail.com Sat Feb 1 12:52:42 2025 From: Christian Liendo To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Sat, 01 Feb 2025 07:52:27 -0500 Message-ID: In-Reply-To: <7w8qqqytew.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9151844405735929326==" --===============9151844405735929326== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Wow. Yes they are and according to the website, he has pictures of the Northwest Computer Society, Pacific Science Center Computer Fair and Northwest Computer Society Computer Fair. I wonder if he is still around, he must have some great stories. On Sat, Feb 1, 2025 at 3:13=E2=80=AFAM Lars Brinkhoff wro= te: > > I think these 1979 photos are interesting. > > https://web.archive.org/web/20200815021031/http://www.sound-photo.com/micro= soft/microsoft.htm --===============9151844405735929326==-- From classiccmp@fjl.co.uk Sat Feb 1 13:37:47 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 13:37:40 +0000 Message-ID: <7d0243ed-19ac-49f5-b26d-6a424e4b26fc@fjl.co.uk> In-Reply-To: =?utf-8?q?=3CDM6PR14MB34495B647332D3EF2C910647D8EB2=40DM6PR14MB?= =?utf-8?q?3449=2Enamprd14=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7028905422925837593==" --===============7028905422925837593== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 01/02/2025 02:31, roger arrick via cctalk wrote: > In 1977, at age 16, I went to work for Noakes Data Communications in Irving= Texas. > > We built an 8080 industrial computer, made modems, and repaired lots of com= m gear. > > RS232 was what we lived and breathed. And back then almost all the contro= l signals were actually used, not just jumpered or ignored. > > I remember thinking at the time that the bipolar signal levels were such a = waste of time for office and personal computers. They should have just gone = to a TTL version for everything local like printers, and modems, and keyboard= s and terminals. Back then we had to use 1488 and 1489 level converters with= +/-12v power supplies. Such a costly hassle. Of course, many years later w= e got MAX232 with 4 .1uf caps and 5v which solved the cost problem. > > I still have my blue breakout box from that year. It cost something like $= 300 at the time which was the price of a used car =F0=9F=99=82 > > I documented the company here: > https://www.rogerarrick.com/noakes/ > [https://www.rogerarrick.com/noakes/noakes_label.png] > Noakes Data Communications - Irving Texas - 1970s-1980s > Noakes Data Communications. 1 May 2023. Click images for larger view 1973-1= 987 Noakes Data Communications 3330 Stovall St, Irving, TX 75061 214-790-1050 > www.rogerarrick.com I certainly agree TTL would have made sense for microprocessors but=20 earlier computers ran at much higher voltages, and lots of them :-) It was always a pain getting -ve on non-Intel/Zilog machines like 6502.=20 Why? 'cos Z80s already had it for dynamic RAM anyway. We've all been talking about the voltage being +/-12V but the standard=20 was much higher (15V or 25V IIRC depending on the year). But that had=20 two effects - the input pins needed to stand the voltage swing, but the=20 output voltages could be whatever you liked - including +/- 5V. Quite a=20 lot of them were at this level in microcomputers. Why? Because the=20 voltage would drop in the cable and the receiver really didn't care as=20 long as it was one side or the other of GND by the time it arrived. A=20 long cable starting at +15V would look the same as a short one starting=20 at +5V. IME +/- 12V was a de-facto standard on microcomputers because they=20 already had a +12V and -12V rail, along with +5V. The ubiquitous 4116=20 DRAM needed +5V, -5V and +12V so +/- 5V was a popular option too. These days you can, of course, get RS-232 driver chips that take TTL in=20 on one side, +5V, and derive the correct voltages internally. For only a=20 few pence. Problem gone (except they tend to be SMD and a PITA to mount=20 on strip-board. Grrr). Regards, Frank. --===============7028905422925837593==-- From bfranchuk@jetnet.ab.ca Sat Feb 1 15:14:13 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 08:14:05 -0700 Message-ID: <9ba4b872-99f8-4ec6-8486-bd7c9ae9ba07@jetnet.ab.ca> In-Reply-To: <7d0243ed-19ac-49f5-b26d-6a424e4b26fc@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8231577935240958985==" --===============8231577935240958985== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-01 6:37 a.m., Frank Leonhardt via cctalk wrote: > IME +/- 12V was a de-facto standard on microcomputers because they > already had a +12V and -12V rail, along with +5V. The ubiquitous 4116 > DRAM needed +5V, -5V and +12V so +/- 5V was a popular option too. Apple was smart with their switching power supply. I picked up a S100 bus kit, and all I could build was the +8? supply that later exploded taking out every thing. The real pain was that most memory was static ram with like 8K per card. > These days you can, of course, get RS-232 driver chips that take TTL in > on one side, +5V, and derive the correct voltages internally. For only a > few pence. Problem gone (except they tend to be SMD and a PITA to mount > on strip-board. Grrr). That was ok when you had one brand of max232, now you have several, and not all connections are the same. I pulled a schematic off the web and got burned when I used the wrong brand. Worked like 10 minutes before it died. > Regards, Frank. --===============8231577935240958985==-- From classiccmp@fjl.co.uk Sat Feb 1 15:38:26 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Sat, 01 Feb 2025 15:38:20 +0000 Message-ID: <80775422-3230-4158-a2a5-ce61e1d447c2@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3062168562458745467==" --===============3062168562458745467== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 31/01/2025 18:19, Christian Liendo via cctalk wrote: > I was debating sending this, but Microsoft is part of computing > history and fifty years is a milestone. > > https://news.microsoft.com/microsoft-50/ My early Microsoft story. I noticed a problem in Microsoft 6502 BASIC 1.0 rev 3.2 (I saw the banner every day!) supplied by OSI in ROM. Basically after using string arrays for while the machine hung, with the screen "twitching", requiring a reset and warm start. It looked like the garbage collector. I called OSI and they told me to call this number Microsoft as they'd heard about this before. This was in 1978. This was a really expensive transatlantic phone call. I got through and asked to speak to someone about their ROM BASIC.... "No, it wasn't a Commodore PET and I was directed their by OSI." After an expensive wait I got through to a friendly chap who vaguely knew of the issue. Apparently when it was ported to the 6502 the string length became two bytes instead of one and this may have broken it. Unfortunately Rick, the guy who did the 6502 port wasn't around and they guy I was talking to had done the 8080 version. Realising I was talking to someone useless, and the call was costing a bomb, I cut things short (politely) and hung up. It turns out it was Richard Wieland who did the 6502 port. So who did I hang up on? --===============3062168562458745467==-- From cclist@sydex.com Sat Feb 1 16:28:31 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 16:28:21 +0000 Message-ID: <7adbeb87-2d63-4db5-b923-619593ebbee3@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3911799461628256799==" --===============3911799461628256799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/1/25 02:31, Frank Leonhardt via cctalk wrote: > On 31/01/2025 18:55, Steve Lewis via cctalk wrote: > As I've mentioned elsewhere, "UART" is Intel's term for an ACIA; and > other names exist from other manufacturers. Just a buffered shift > register and other logic in the same chip. The veneered and generated Intel 8251 is a USART--as were other similar chips (8274, Zilog SIO, etc.)--capable of both asynchronous and asynchronous data transfer. Synchronous for block/bulk transfer is far superior in terms of carrying capacity (no start/stop "bits"; note the quotes; asynchronous "stop" is simply a pause between characters) and was very common in the 1960s and 1970s. Many a hobbyist has scrounged a "good deal" used terminal only to find that it was block-mode synchronous. As far as integration, the original LSI chipsets employed separate devices for transmitting and receiving data. Current-loop is probably still employed extensively in heavy industry--better noise immunity and distance. One used to (in the 1970s) be able to purchase off-the-shelf "long haul" modems that converted between EIA signal levels and current-loop. One of the benefits of CL is that detecting a break in the line is simple--not so for the voltage-oriented EIA signalling (RS-442, 232, 449, etc.). The disadvantage is that signalling is done over a single wire pair--no "handshaking signals. If the 25-way DSUB connector bothers you, have a look at RS-449, which employs a 37-way (DC37) connector: https://en.wikipedia.org/wiki/RS-449 --Chuck --===============3911799461628256799==-- From drb@msu.edu Sat Feb 1 16:43:12 2025 From: Dennis Boone To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 11:43:08 -0500 Message-ID: <20250201164308.ED9E152007C@yagi.h-net.msu.edu> In-Reply-To: <7adbeb87-2d63-4db5-b923-619593ebbee3@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3629777968584257386==" --===============3629777968584257386== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > One used to (in the 1970s) be able to purchase off-the-shelf "long > haul" modems that converted between EIA signal levels and > current-loop. Sometimes called "line drivers", because that's not confusingly overloaded terminology or anything. I was about to say "e.g. Gandalf LDS family", but iirc those were actually _leased_, not purchased. > If the 25-way DSUB connector bothers you, have a look at RS-449, > which employs a 37-way (DC37) connector Some may be amused to remember that the DB/DC/... family of connectors were known as "D-subminiature" when introduced. De --===============3629777968584257386==-- From roger@arrick.com Sat Feb 1 17:05:10 2025 From: roger arrick To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:05:00 +0000 Message-ID: In-Reply-To: <20250201164308.ED9E152007C@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4226321865435409031==" --===============4226321865435409031== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'm happy to see people using the correct shell letter for DSubs around here!= Oldschool wisdom. I get irritated hearing people on the vintage computing groups calling everyt= hing DB. Here's a quick write up about it - there is no DB9! =F0=9F=99=82 https://www.rogerarrick.com/dcon/ [https://www.rogerarrick.com/dcon/dcon_1000.png] RogerArrick.com D-Subminiature Connectors Explained D-Subminiature Connectors. In the 1950's the D-subminiature connector was int= roduced and became popular on computers for communications. The pins are smal= l and designed to carry low-voltage signals, not for power, although pins can= carry an amp or more. www.rogerarrick.com ________________________________ From: Dennis Boone via cctalk Sent: Saturday, February 1, 2025 10:43 AM To: General Discussion: On-Topic and Off-Topic Posts Cc: Dennis Boone Subject: [cctalk] Re: RS232 then and now > One used to (in the 1970s) be able to purchase off-the-shelf "long > haul" modems that converted between EIA signal levels and > current-loop. Sometimes called "line drivers", because that's not confusingly overloaded terminology or anything. I was about to say "e.g. Gandalf LDS family", but iirc those were actually _leased_, not purchased. > If the 25-way DSUB connector bothers you, have a look at RS-449, > which employs a 37-way (DC37) connector Some may be amused to remember that the DB/DC/... family of connectors were known as "D-subminiature" when introduced. De --===============4226321865435409031==-- From macro@orcam.me.uk Sat Feb 1 17:11:57 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:11:51 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CDM6PR14MB344947AE07F09BAF7ED5284DD8EB2=40DM6PR14MB?= =?utf-8?q?3449=2Enamprd14=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1630257413077235793==" --===============1630257413077235793== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 1 Feb 2025, roger arrick via cctalk wrote: > I'm happy to see people using the correct shell letter for DSubs around > here! Oldschool wisdom. You kinda have to when you get at things such as DA-3W3. Maciej --===============1630257413077235793==-- From cclist@sydex.com Sat Feb 1 17:33:27 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:33:17 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CDM6PR14MB344947AE07F09BAF7ED5284DD8EB2=40DM6PR14MB?= =?utf-8?q?3449=2Enamprd14=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2013948330549750812==" --===============2013948330549750812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/1/25 09:05, roger arrick via cctalk wrote: > I'm happy to see people using the correct shell letter for DSubs around her= e! Oldschool wisdom. > I get irritated hearing people on the vintage computing groups calling ever= ything DB. > Here's a quick write up about it - there is no DB9! =F0=9F=99=82 In fact, if "keeping up with the times" is a thing, then this 35-year old IEC standard should dictate what we call these beasts: http://file.yzimgs.com/383992/2013022116300293.pdf But then, the simple D-sub 25-way male connector would be a real mouthful. Brevis esse laboro, obscurus fio. Another pet gripe of mine is calling the old 50-way SCSI/etc. connector a "Centronics" connector,regardless of application or number of connections. I prefer to refer to them as "blue ribbon" connectors, developed by Amphenol in 1950 and used extensively in commercial telephone systems long before Centronics or SCSI. But in my dotage, I've learned not to beat a dead horse. --Chuck --===============2013948330549750812==-- From bfranchuk@jetnet.ab.ca Sat Feb 1 17:36:54 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 10:36:47 -0700 Message-ID: <05b67107-975b-4bea-bc31-d29b698689e0@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5434172294137350139==" --===============5434172294137350139== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-01 10:11 a.m., Maciej W. Rozycki via cctalk wrote: > On Sat, 1 Feb 2025, roger arrick via cctalk wrote: > >> I'm happy to see people using the correct shell letter for DSubs around >> here! Oldschool wisdom. > > You kinda have to when you get at things such as DA-3W3. > > Maciej I have no idea what that is, but I am sure that has no SUB-MINIATURE price. --===============5434172294137350139==-- From macro@orcam.me.uk Sat Feb 1 17:39:14 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:39:06 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9207853388605851475==" --===============9207853388605851475== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 31 Jan 2025, Warner Losh wrote: > > > Was that with an actual RS232 port, i.e., a device using RS232 signal > > > levels, or a "TTL" logic level serial port? I'm guessing the latter. > > > > I'm not sure what you mean by 'a "TTL" logic level serial port', please > > elaborate. Do you mean signalling used between the UART and line drivers > > by any chance, such as with a serial connection made between UARTs without > > actual line drivers in between? > > > > Yes. That's the overwhelming majority of usage these days. At least for me > when not dealing with retro gear. As a matter of interest what are the use cases if I may ask and you are allowed and willing to share this information? Maciej --===============9207853388605851475==-- From classiccmp@fjl.co.uk Sat Feb 1 17:42:15 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:42:09 +0000 Message-ID: <62797da6-232b-482a-befd-4b115247b66f@fjl.co.uk> In-Reply-To: <5c9e4614-6048-4cbe-81c5-a6b03d789104@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0997174959008606975==" --===============0997174959008606975== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 31/01/2025 23:07, Chuck Guzis via cctalk wrote: > On 1/31/25 13:57, Tony Duell via cctalk wrote: >> On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk >> wrote: >> >>> The first parallel printers might have been Centronics. Hence the >>> interface and blue ribbon connector being called "Centronics parallel" >> The first printer that Radio Shack/Tandy sold for the TRS-80 (at least >> in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of >> course) -- was a rebadged Cantronics with the obvious parallel >> interface. I have the Centronics version here and repair it using the >> Radio Shack service manual. > Out in the field during the late 60s and 70s, I found that the > Dataproducts interface was more common than the Centronics. I think the Epson MX80 was responsible for standardising the Centronics interface :-) Not only was it TTL only and therefore easier to implement in hardware, but it was much faster than RS-232. You could get other interfaces as add-on boards, including RS-232, Apple, TRS-80 and IEE488. I believe they got a 50% of market share for printers with this, from a standing start. --===============0997174959008606975==-- From macro@orcam.me.uk Sat Feb 1 17:51:32 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:51:25 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5867470862156421264==" --===============5867470862156421264== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 1 Feb 2025, Steve Lewis wrote: > Reading the async-expansion for the IBM 5110, it talks about -25 to +25V > (the original spec of RS232?). On the 1980 Color Computer 1, I noticed it > uses -12V to +12V for its RS232. Later in the 1990s, laptops wanted to > sip less less power, and I think RS-232 revisions allowed for as low as -3V > to +3V swings? So those -5/+5V or 3.3 integrations get referred to as > more modern "TTL logic level serial port" (such as generally a USB/serial > adapter) to contrast from prior legacy devices. I don't think referring to ±5V or ±3.3V as TTL levels is correct by any means: you can't feed it to any TTL input and expect correct operation. I'm not sure even whether a TTL circuit would survive supplying negative voltage; it has been decades since I had a look at how a TTL gate looks like at the transistor level and I don't remember the details anymore. Maciej --===============5867470862156421264==-- From macro@orcam.me.uk Sat Feb 1 18:11:25 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 18:11:18 +0000 Message-ID: In-Reply-To: <05b67107-975b-4bea-bc31-d29b698689e0@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6809685365311923753==" --===============6809685365311923753== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 1 Feb 2025, ben via cctalk wrote: > > > I'm happy to see people using the correct shell letter for DSubs around > > > here! Oldschool wisdom. > > > > You kinda have to when you get at things such as DA-3W3. > > I have no idea what that is, but I am sure that has no SUB-MINIATURE price. D-sub gear comes at varying prices; I guess consumer DE-9 stuff will be cheap, but not necessarily when you ask for the wire-wrap variant. As to DA-3W3 the first hit on the search engine is Farnell/Newark and you'll get the prices there: nothing out of the ordinary IMHO. Maciej --===============6809685365311923753==-- From paulkoning@comcast.net Sat Feb 1 18:21:04 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 13:20:50 -0500 Message-ID: In-Reply-To: <8c0e72b9-9cf6-41d1-826c-c59a35d2c2f4@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2544782810258293594==" --===============2544782810258293594== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Jan 31, 2025, at 6:19=E2=80=AFPM, Cameron Kaiser via cctalk wrote: >=20 >=20 >> Low speed modems are just analog devices that can pass any signal up to=20 >> whatever the design speed limit is. For example, a 103 modem is good up >> to 300 bps, but will happily carry anything less. A 202 modem (see=20 >> below) is designed for 1200 but also will work at lower speeds, and has=20 >> been used at 1260 bps. >=20 > I'd argue those are differing situations, though. Bell 103 and Bell 101 mod= ems > use the same AFSK frequencies, just at different speeds. Bell 202 modems ha= ve > specific hardware to support Bell 103, effectively two modems in the same c= ase. That's not the case for the 202 modem I have; it is definitely 202 only and d= oes not offer 103 compatibility. paul --===============2544782810258293594==-- From classiccmp@fjl.co.uk Sat Feb 1 18:25:09 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 18:25:01 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2222278712443080760==" --===============2222278712443080760== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 01/02/2025 17:33, Chuck Guzis via cctalk wrote: > Another pet gripe of mine is calling the old 50-way SCSI/etc. connector > a "Centronics" connector,regardless of application or number of > connections. > > I prefer to refer to them as "blue ribbon" connectors, developed by > Amphenol in 1950 and used extensively in commercial telephone systems > long before Centronics or SCSI. I've always called them Amphenol connectors, although strictly speaking Amphenol made more than one design. My #1 annoyances are IT types referring non-volatile RAM as CMOS and motherboard configuration utilities as a BIOS. --===============2222278712443080760==-- From classiccmp@fjl.co.uk Sat Feb 1 18:25:59 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 18:25:53 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2284312040856205233==" --===============2284312040856205233== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 31/01/2025 08:20, Steve Lewis via cctalk wrote: > > > Then, was it the SAGE program that demonstrated the idea of doing this kind > of data exchange across copper phone lines? That is, the idea of computers > collaborating not just in a room, but across long distances (miles)? And > doing so by using an audio tone presentation? (they settled on around > 3100MHz, which ended up translating to 300 baud? Almost forgot - why 300 baud? The modem the RS232 was driving was modulating over standard telephone lines, which are obviously audio.The original ones used Frequency Shift Keying (FSK)- basically switching between high and low tones for zero and one. You need a certain amount of tone to be present for a bit to register. Given you want full duplex you need four frequencies (two each for high and low). These were 1080Hz, 980Hz, 1750Hz and 1650Hz - i.e. 100Hz apart for two pairs. The pairs needed a gap of around 600Hz between them so they wouldn't be confused after the telephone system had mangled the sound. In Europe the POTS bandwidth was around 3K, in the USA it was 2K (but not starting at zero) so these frequencies were sufficiently inside the available bandwidth to get to the other side. If you up the bps you come to a point where there won't be enough of the mark frequency to be detected - it won't have enough complete cycles. And that point was basically 300 baud. 980Hz divided by 300 gives about 3 complete cycles to indicate a mark, which is the minimum you need for easy detection by an analogue circuit. Incidentally, the US had Bell 103 at up to 300 baud, Europe and V.21 which was slightly better but used the same frequencies. When originally launched they were used at 110. You also get problems squirting tones through the telephone system it also uses tones for internal signalling and if you send harmonics you'll re-route the call. Bell 212 at 600/1200bps (aka V.22) used more complex QPSK modulation to encode more than one bit per cycle. That's the one that sounded like someone being sick down the phone line, as one of my colleagues put it. Eventually more complex standards got to a total data rate of 56Kbps. Given the telephone network by this time digitised at 64kbps, you'd be breaking the laws of physics if you got a higher rate than that. Getting 56K was pretty impressive in the circumstances. Regards, Frank. --===============2284312040856205233==-- From paulkoning@comcast.net Sat Feb 1 18:28:55 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 13:28:40 -0500 Message-ID: <25B5E087-30C2-408A-9D7C-46642E83F346@comcast.net> In-Reply-To: <20250201014443.09EF551E576@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7910344374555610890==" --===============7910344374555610890== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Jan 31, 2025, at 8:44=E2=80=AFPM, Dennis Boone via cctalk wrote: >=20 >> Those rack-mount Milgo units were built like battleships and very >> well regarded in the industry. My first "high-speed" modem was a >> Racal/Vadic 3451 that, IIRC, could do 2000 bps when talking to >> another 3451 using RV's proprietary protocol. >=20 > Vadic had a variant 1200 baud system that wasn't compatible with 212, > too, as I recall. I remember Vadic, though vaguely. Incidentally, starting with the 212 modem and much more so with higher speed = ones, using "baud" as a synonym for "bits per second" is incorrect. Baud, co= rrectly used, is signaling units per second. For 103 and 202 modems which ju= st use plain FSK, the two match. But the 212 uses QPSK, which means it does = 1200 bits per second using 600 baud signaling. And the same, only more so, g= oes for the more complex modulation systems of faster modems.=20 This applies to various modern high speed networks as well. Original Etherne= t is one bit per baud. But that's not true for the higher speed ones. =20 If you see a link that uses, say, QAM256 coding, you're looking at something = that does 8 bits per baud (ignoring any ECC overhead, if the signaling scheme= does such a thing). paul --===============7910344374555610890==-- From cclist@sydex.com Sat Feb 1 18:33:54 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 18:33:44 +0000 Message-ID: <9c4c95fe-b997-4d10-90f8-89448bcb33bb@sydex.com> In-Reply-To: <62797da6-232b-482a-befd-4b115247b66f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4623864930925076358==" --===============4623864930925076358== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/1/25 09:42, Frank Leonhardt via cctalk wrote: > You could get other interfaces as add-on boards, including RS-232, > Apple, TRS-80 and IEE488. I believe they got a 50% of market share for > printers with this, from a standing start. I vaguely recall that the MX-80 came with the parallel interface as the default; serial EIA was an option. I rigged something up using a 9V battery and some random logic added to the printer to get serial to work without buying the option. --Chuck --===============4623864930925076358==-- From paulkoning@comcast.net Sat Feb 1 19:01:41 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:01:27 -0500 Message-ID: <15B846E6-FF86-4D66-94E2-1FD4508EC5B9@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4061281240014862707==" --===============4061281240014862707== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Jan 31, 2025, at 10:37=E2=80=AFPM, Maciej W. Rozycki wrote: >=20 > On Fri, 31 Jan 2025, Paul Koning wrote: >=20 >>> FWIW I was able to get reliable serial communication under Linux of up to= =20 >>> 3.5Mbps with off-the-shelf proper PCIe UART hardware clocked at 62.5MHz=20 >>> despite that line drivers used with said hardware (soldered onboard) were= =20 >>> spec'd for up to 1MHz only[1]. This was with plain PIO interrupt-driven = >>> operation, but then the UARTs used had decent FIFO sizes of 128 character= s=20 >>> and the FIFO trigger level for the interrupt was reasonably set. >>>=20 >>> Finally at 4.0Mbps data corruption reproducibly triggered, but it was=20 >>> garbled rather than lost characters, so I conclude the reason was either = >>> line drivers finally giving up or the transmission frequency hitting the = >>> bandwidth limit of the serial communication cable used. >>=20 >> Was that with an actual RS232 port, i.e., a device using RS232 signal=20 >> levels, or a "TTL" logic level serial port? I'm guessing the latter. >=20 > I'm not sure what you mean by 'a "TTL" logic level serial port', please=20 > elaborate. Do you mean signalling used between the UART and line drivers=20 > by any chance, such as with a serial connection made between UARTs without = > actual line drivers in between? What I meant is that a lot of modern computer modules come with serial ports = that are not RS232 but rather using standard logic levels (TTL 0 and 5 volts,= or perhaps lower voltages such as 0 and 3.3 volts) for their signaling. Tho= se basically just expose the logic level I/O of the UART or the embedded seri= al port. Vendors like FTDI make adapters for this. You can get their UART to USB adap= ter with actual RS232 interfacing, but also with 5 volt or 3.3 volt logic lev= els. That last one is what you'd use to plug into the console port of a Beag= lebone Black microcomputer board, for example. paul --===============4061281240014862707==-- From paulkoning@comcast.net Sat Feb 1 19:03:48 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:03:35 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7319912041497527973==" --===============7319912041497527973== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Jan 31, 2025, at 10:37=E2=80=AFPM, Maciej W. Rozycki wrote: >=20 >> ... >=20 > The serial port hardware I refer to uses a UART wired to a Zywyn ZT3243F=20 > line driver, which according to the manufacturer's datasheet signals at=20 > =C2=B15V minimum transmitter voltage levels and accepts up to =C2=B125V rec= eiver=20 > voltage levels and: "Meets or Exceeds the EIA/TIA-232F and CCITT V.28/V.24 = > Specifications for VCC at +3.3V =C2=B110% and +5V =C2=B110% Operations." W= hile the=20 > transmitter voltage levels are not the highest recognised by the standard=20 > I do believe this line driver does comply with RS-232. >=20 > As I say the datasheet explicitly says: "Guaranteed data rate 1000kbps,"=20 > and according to my findings quoted above it is indeed the case (and well=20 > beyond). [Yes, I got it wrong by writing 1MHz rather than 1Mbps, a mental = > slip I suppose.] >=20 > NB I've also used the TI TRS3122E line driver, suitable for operation=20 > with 1.8V signalling per my requirement, and it is also documented to=20 > handle "data rates up to 1000kbps, while maintaining RS-232-compatible=20 > output levels." I haven't got a chance to go beyond 230400bps with this=20 > device though, but these two samples do suggest that supported operation=20 > at 1Mbps isn't that uncommon for currently available RS-232 line drivers. >=20 > I've looked up the MAX3222 datasheet and it does say 250kbps max though; > I guess it's older technology then? >=20 > Does this answer your question? Sure does. I don't know if the MAX3222 is older, or just different. The RS232 standard = doesn't apply to those high rates. And I vaguely remember seeing words that = imply the line drivers should have controlled rise/fall times. So I think th= e MAX3222 limits come from implementing those rate limited edges, not from th= e age of the design. paul --===============7319912041497527973==-- From paulkoning@comcast.net Sat Feb 1 19:10:13 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:10:00 -0500 Message-ID: In-Reply-To: <7d0243ed-19ac-49f5-b26d-6a424e4b26fc@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7861057910838283694==" --===============7861057910838283694== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 1, 2025, at 8:37=E2=80=AFAM, Frank Leonhardt via cctalk wrote: >=20 > On 01/02/2025 02:31, roger arrick via cctalk wrote: >> In 1977, at age 16, I went to work for Noakes Data Communications in Irvin= g Texas. >>=20 >> We built an 8080 industrial computer, made modems, and repaired lots of co= mm gear. >>=20 >> RS232 was what we lived and breathed. And back then almost all the contr= ol signals were actually used, not just jumpered or ignored. >>=20 >> I remember thinking at the time that the bipolar signal levels were such a= waste of time for office and personal computers. They should have just gone= to a TTL version for everything local like printers, and modems, and keyboar= ds and terminals. Back then we had to use 1488 and 1489 level converters wit= h +/-12v power supplies. Such a costly hassle. Of course, many years later = we got MAX232 with 4 .1uf caps and 5v which solved the cost problem. >>=20 >> ... >=20 > I certainly agree TTL would have made sense for microprocessors but earlier= computers ran at much higher voltages, and lots of them :-) So did early logic ICs. TTL happens to be very well known because it was far= more successful than others, but it was preceded by DTL (6 volts) and RTL (3= .6 volts). Also, in the days of TTL, you might also find high end systems wi= th ECL in them (-3 volts??? I forgot). And yes, of course in discrete transistor computers the voltages would be all= over the map. 6 volts in the CDC 6000 mainframes, who knows what else in ot= her machines of that era. paul --===============7861057910838283694==-- From g4ajq1@gmail.com Sat Feb 1 19:40:37 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:40:30 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4345983807250259634==" --===============4345983807250259634== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-01 13:25, Frank Leonhardt via cctalk wrote: > On 01/02/2025 17:33, Chuck Guzis via cctalk wrote: >> Another pet gripe of mine is calling the old 50-way SCSI/etc. connector >> a "Centronics" connector,regardless of application or number of >> connections. >> >> I prefer to refer to them as "blue ribbon" connectors, developed by >> Amphenol in 1950 and used extensively in commercial telephone systems >> long before Centronics or SCSI. > > I've always called them Amphenol connectors, although strictly > speaking Amphenol made more than one design. > > My #1 annoyances are IT types referring non-volatile RAM as CMOS and > motherboard configuration utilities as a BIOS. > > Actually, in 1971 they were originally marked A-MP, which stood for Aero-MarineProducts. And as far as the statement that Epson standarised the Centronics connector goes, I say 'hogwash' - it was being used by Centronics many years before Epson came on to the market.  I was servicing teh Centronics 101, 103 and 306 back in 1975, including making cables to hook them up to PDP11s.  I still remeember the connector part nuer, it was 57-10360 - the 36 meaning 36 pins, which is why I said there was never a 50-pin Centronics connector.  Centronics printers did sometimes ship with another parallel interface, it was Dataproducts printer comp and had a Winchester-style connector I believe, but I never worked on one. And yes, the 50-pin version was called a blue-ribbon, I saw enough of those while working for Bell!  Common on key sets in small businesses! cheers Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============4345983807250259634==-- From wdonzelli@gmail.com Sat Feb 1 19:46:37 2025 From: William Donzelli To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:46:20 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2621447528596107658==" --===============2621447528596107658== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit AMP and Amphenol were different companies, officially. -- Will On Sat, Feb 1, 2025 at 2:40 PM Nigel Johnson Ham via cctalk wrote: > > On 2025-02-01 13:25, Frank Leonhardt via cctalk wrote: > > On 01/02/2025 17:33, Chuck Guzis via cctalk wrote: > >> Another pet gripe of mine is calling the old 50-way SCSI/etc. connector > >> a "Centronics" connector,regardless of application or number of > >> connections. > >> > >> I prefer to refer to them as "blue ribbon" connectors, developed by > >> Amphenol in 1950 and used extensively in commercial telephone systems > >> long before Centronics or SCSI. > > > > I've always called them Amphenol connectors, although strictly > > speaking Amphenol made more than one design. > > > > My #1 annoyances are IT types referring non-volatile RAM as CMOS and > > motherboard configuration utilities as a BIOS. > > > > > Actually, in 1971 they were originally marked A-MP, which stood for > Aero-MarineProducts. > > And as far as the statement that Epson standarised the Centronics > connector goes, I say 'hogwash' - it was being used by Centronics many > years before Epson came on to the market. I was servicing teh > Centronics 101, 103 and 306 back in 1975, including making cables to > hook them up to PDP11s. I still remeember the connector part nuer, it > was 57-10360 - the 36 meaning 36 pins, which is why I said there was > never a 50-pin Centronics connector. Centronics printers did sometimes > ship with another parallel interface, it was Dataproducts printer comp > and had a Winchester-style connector I believe, but I never worked on one. > > And yes, the 50-pin version was called a blue-ribbon, I saw enough of > those while working for Bell! Common on key sets in small businesses! > > cheers > > Nigel > > > -- > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU > Amateur Radio, the origin of the open-source concept! > Skype: TILBURY2591 > --===============2621447528596107658==-- From julf@julf.com Sat Feb 1 19:58:38 2025 From: Johan Helsingius To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 20:49:47 +0100 Message-ID: <99bab650-e4d0-451a-ade4-fb62f4deec4f@Julf.com> In-Reply-To: <62797da6-232b-482a-befd-4b115247b66f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3590720111611585579==" --===============3590720111611585579== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 01/02/2025 18:42, Frank Leonhardt via cctalk wrote: > I think the Epson MX80 was responsible for standardising the Centronics > interface :-) Ooh yes, fond memories, that was the first printer I could actually afford. Julf --===============3590720111611585579==-- From healyzh@avanthar.com Sat Feb 1 20:40:36 2025 From: Zane Healy To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple & History (Was: Microsoft 50 years) Date: Sat, 01 Feb 2025 12:40:20 -0800 Message-ID: <0230C1BB-DEE0-4C3B-95AE-3422844D61AA@avanthar.com> In-Reply-To: <7ae8bff7-cd32-4eff-9693-fe3fc691e48b@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3352047852966877090==" --===============3352047852966877090== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Jan 31, 2025, at 10:23 PM, David C. Jenner via cctalk wrote: >=20 > You mean you don't have an old Mac that can do all this? I just went throu= gh collecting old data on 3 old Mac OS X versions and Mac OS 9 on a G4 tower = that's 25 years old. It also runs an older, very expensive Nikon film scanne= r that works great. Networking on this still works great, and I can send to = newer Macs/Windows as needed. >=20 > Dave I have all my old Macs, though I don=E2=80=99t think the original dual 2Ghz G= 5 PowerMac works. It=E2=80=99s a question of space and noise. It=E2=80=99s = a lot easier to use VM=E2=80=99s and emulation where possible. I don=E2=80= =99t have room in my office for more computers, and I=E2=80=99ve grown to app= reciate the quietness of modern systems. Even most of my OpenVMS systems hav= e been migrated over to an ESXI cluster and are running under emulation on Li= nux VM=E2=80=99s. Though I still have one VAX running 24x7. I also find it = amusing to Raspberry Pi boards for mainframe emulation. As for your Nikon film scanner (mine finally died), take a look at VueScan, i= t will run on any modern OS. My =E2=80=9Cproblem=E2=80=9D scanner is a Pakon= F-135 Plus, which only works with WinXP. Zane --===============3352047852966877090==-- From elson@pico-systems.com Sat Feb 1 20:40:55 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:40:49 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0566573190669577981==" --===============0566573190669577981== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/1/25 13:10, Paul Koning via cctalk wrote: > > you might also find high end systems with ECL in them (-3 > volts??? I forgot). If you ran Motorola ECL the Motorola way, with Vcc at gnd and Vee at -5.2 for MECL 10K and -4.5 for 100K) logic levels were -0.8 V for a 1 and -1.6 V for a zero. If you ran it the IBM MST4 way (Vcc at +1.25 V and Vee at -3V) then logic levels were +400 mV for 1 and -400 mV for zero. Jon --===============0566573190669577981==-- From elson@pico-systems.com Sat Feb 1 20:44:41 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:44:35 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1831529272497133787==" --===============1831529272497133787== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/1/25 13:10, Paul Koning via cctalk wrote: > you might also find high end systems with ECL in them (-3 volts??? I forg= ot). > > If you ran Motorola ECL the Motorola way, with Vcc at gnd=20 and Vee at -5.2 for MECL 10K and -4.5 for 100K) logic levels=20 were -0.8 V for a 1 and -1.6 V for a zero. If you ran it the IBM MST4 way (Vcc at +1.25 V and Vee at=20 -3V) then logic levels were +400 mV for 1 and -400 mV for zero. Jon --===============1831529272497133787==-- From d44617665@hotmail.com Sat Feb 1 21:12:56 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 21:12:49 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8143827295407540561==" --===============8143827295407540561== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I used the 1488 and 1489 RS232 chips as level shifters on the semiconductor R= AM board I designed for the IBM 1620. Handy. Dave Wise ________________________________ --===============8143827295407540561==-- From d44617665@hotmail.com Sat Feb 1 21:17:31 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 21:17:22 +0000 Message-ID: In-Reply-To: <25B5E087-30C2-408A-9D7C-46642E83F346@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3010993020637654009==" --===============3010993020637654009== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I remember the Vadic modem fondly. In the 1980's, on weekends I'd take home = a terminal and a modem from work, and dial up the Tektronix Information Displ= ay Division's mainframe to play Rogue. However, I think that was 2400 not 12= 00. Dave Wise ________________________________ From: Paul Koning via cctalk Sent: Saturday, February 1, 2025 10:28 AM To: cctalk(a)classiccmp.org Cc: Paul Koning Subject: [cctalk] Re: A baudy tale > On Jan 31, 2025, at 8:44=E2=80=AFPM, Dennis Boone via cctalk wrote: > >> Those rack-mount Milgo units were built like battleships and very >> well regarded in the industry. My first "high-speed" modem was a >> Racal/Vadic 3451 that, IIRC, could do 2000 bps when talking to >> another 3451 using RV's proprietary protocol. > > Vadic had a variant 1200 baud system that wasn't compatible with 212, > too, as I recall. I remember Vadic, though vaguely. Incidentally, starting with the 212 modem and much more so with higher speed = ones, using "baud" as a synonym for "bits per second" is incorrect. Baud, co= rrectly used, is signaling units per second. For 103 and 202 modems which ju= st use plain FSK, the two match. But the 212 uses QPSK, which means it does = 1200 bits per second using 600 baud signaling. And the same, only more so, g= oes for the more complex modulation systems of faster modems. This applies to various modern high speed networks as well. Original Etherne= t is one bit per baud. But that's not true for the higher speed ones. If you see a link that uses, say, QAM256 coding, you're looking at something = that does 8 bits per baud (ignoring any ECC overhead, if the signaling scheme= does such a thing). paul --===============3010993020637654009==-- From classiccmp@fjl.co.uk Sat Feb 1 21:31:53 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 21:31:47 +0000 Message-ID: <4e25450a-76ac-4754-a6a0-e3a91849b74d@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4342885093788149437==" --===============4342885093788149437== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 01/02/2025 19:10, Paul Koning via cctalk wrote: > On Feb 1, 2025, at 8:37=E2=80=AFAM, Frank Leonhardt via cctalk=20 > wrote: >> I certainly agree TTL would have made sense for microprocessors but earlie= r computers ran at much higher voltages, and lots of them :-) > So did early logic ICs. TTL happens to be very well known because it was f= ar more successful than others, but it was preceded by DTL (6 volts) and RTL = (3.6 volts). Also, in the days of TTL, you might also find high end systems = with ECL in them (-3 volts??? I forgot). > > And yes, of course in discrete transistor computers the voltages would be a= ll over the map. 6 volts in the CDC 6000 mainframes, who knows what else in = other machines of that era. > > paul I started with minilogs which were +/- 10V logic. Anyone remember those? --===============4342885093788149437==-- From classiccmp@fjl.co.uk Sat Feb 1 21:33:21 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 21:33:10 +0000 Message-ID: In-Reply-To: <173836834899.1304.15578533715867905179@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0773253194215023905==" --===============0773253194215023905== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 01/02/2025 00:05, Donald Whittemore via cctalk wrote: > Also using NCR/Tally units. We used Racal-Milgo modems. These things > were about the size of a large home stereo receiver. We started at 2400 > baud. The units could do 3600 or 4800 (I don’t remember which) if a > circuit board strap was moved. Okay, you've got me interested. Was this on a leased line or POTS? I remember the first 1200bps full duplex modem appearing on my desk around 1980, and it was exotic. It became more common over the next few years. But you're talking about ten years earlier than this. I know Racal Vadic (later Thomson then Thales) made some pretty fast and expensive gear, but I didn't realise they'd gone above 1200bps until V.22bis in the 1980s. But that's over POTS - leased line? --===============0773253194215023905==-- From d44617665@hotmail.com Sat Feb 1 21:35:50 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 21:35:43 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3087040066286577129==" --===============3087040066286577129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit My experience (Tektronix mainframe via Vadic 2400) was POTS, early 1980's. Dave Wise ________________________________ From: Frank Leonhardt via cctalk Sent: Saturday, February 1, 2025 1:33 PM To: Donald Whittemore via cctalk Cc: Frank Leonhardt Subject: [cctalk] Re: A baudy tale On 01/02/2025 00:05, Donald Whittemore via cctalk wrote: > Also using NCR/Tally units. We used Racal-Milgo modems. These things > were about the size of a large home stereo receiver. We started at 2400 > baud. The units could do 3600 or 4800 (I don’t remember which) if a > circuit board strap was moved. Okay, you've got me interested. Was this on a leased line or POTS? I remember the first 1200bps full duplex modem appearing on my desk around 1980, and it was exotic. It became more common over the next few years. But you're talking about ten years earlier than this. I know Racal Vadic (later Thomson then Thales) made some pretty fast and expensive gear, but I didn't realise they'd gone above 1200bps until V.22bis in the 1980s. But that's over POTS - leased line? --===============3087040066286577129==-- From cisin@xenosoft.com Sat Feb 1 22:54:05 2025 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 14:53:58 -0800 Message-ID: In-Reply-To: <62797da6-232b-482a-befd-4b115247b66f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0512843018463205083==" --===============0512843018463205083== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 1 Feb 2025, Frank Leonhardt via cctalk wrote: > I think the Epson MX80 was responsible for standardising the Centronics > interface :-) > Not only was it TTL only and therefore easier to implement in hardware, but > it was much faster than RS-232. > You could get other interfaces as add-on boards, including RS-232, Apple, > TRS-80 and IEE488. I believe they got a 50% of market share for printers > with this, from a standing start. The IBM "Graphics Printer" was a REBADGED MX80, at least for the first few years. That might also confuse any data about how many MX80s there were. I don't know whether the IBM printer had any minor internal (firmware?) differences from the commercially available models. IBM used a DB25 socket for their printer port at the computer end, (male on the card for serial, female on the card for parallel "Centronics") THAT, of course caused some idiots to attempt to use the parallel port for serial and vice versa. "I just need a 'gender changer'!" :-) Similarly, IBM used DE9 male sockets for serial (previously a DB25 male) and DE9 female sockets for CGA, MDA. The earliest Microsoft mouse had DE9 female plug or DB25 female on its cord for serial, and DE9 male plug on the cord for "BUS mouse". THAT, of course led some users to accidentally plug a bus mouse into a DE9 video socket, and vice versa. They later changed the design, changed the name to "Inport", and changed the connector to Mini-DIN so that it could be confused with PS/2 connectors. TRS80 used a 34 pin card edge (in order to be confusable with their 34 pin card edge for floppy disk) on the "Expanion Interface" for printer, but 36 pin Blue ribbon at the printer end, for most, but not all of their printers. The pinout was close enough to permit insulation displacement crimp on connectors on a ribbon cable (cable number 26-1411? or 26-4401?) Radio shack also came out with a special adapting cable to connect to the 40 pin expansion connector for those who didn't have the Exansion Interface. TRS80 also had more of the same issues of multiple same connectors for different purposes, such as Power/Video/Cassette Sorry, if I have errors in this (unrefreshed dynamic wetware memory) -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============0512843018463205083==-- From cclist@sydex.com Sat Feb 1 22:57:52 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 22:57:43 +0000 Message-ID: In-Reply-To: <4e25450a-76ac-4754-a6a0-e3a91849b74d@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6858468605815087790==" --===============6858468605815087790== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/1/25 13:31, Frank Leonhardt via cctalk wrote: > I started with minilogs which were +/- 10V logic. > > Anyone remember those? I remember HTL (15V) being basically a high-voltage version of DTL. --Chuck --===============6858468605815087790==-- From cclist@sydex.com Sat Feb 1 23:01:43 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 23:01:34 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCYXPR84MB351597C67956C7DDB0832110AEEB2=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7661092716409091822==" --===============7661092716409091822== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/1/25 13:12, David Wise via cctalk wrote: > I used the 1488 and 1489 RS232 chips as level shifters on the semiconductor= RAM board I designed for the IBM 1620. Handy. In the 1970s/80s, there seemed to be two camps of though WRT EIA receivers/drivers. There was the Motorola 1488/1489 crowd than there was the TI crowd (75150/75154). Never bothered to ask which had advantages over the other. --Chuck --===============7661092716409091822==-- From cisin@xenosoft.com Sat Feb 1 23:03:10 2025 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 15:03:03 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4076778877840552911==" --===============4076778877840552911== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit >>> Another pet gripe of mine is calling the old 50-way SCSI/etc. connector >>> a "Centronics" connector,regardless of application or number of >>> connections. >>> I prefer to refer to them as "blue ribbon" connectors, developed by >>> Amphenol in 1950 and used extensively in commercial telephone systems >>> long before Centronics or SCSI. >> I've always called them Amphenol connectors, although strictly speaking >> Amphenol made more than one design. On Sat, 1 Feb 2025, Nigel Johnson Ham via cctalk wrote: > Actually, in 1971 they were originally marked A-MP, which stood for > Aero-MarineProducts. > > And as far as the statement that Epson standarised the Centronics connector > goes, I say 'hogwash' - it was being used by Centronics many years before > Epson came on to the market.  I was servicing teh Centronics 101, 103 and > 306 back in 1975, including making cables to hook them up to PDP11s.  I Centronics had already STANDARDIZED the connector, but Epson made it known to the general public. I loved the 101. When I retired mine, I tried unsuccessfully to get $25 each at swaps. So, I donated them to a community colege that was desperate for sturdier more rugged printers for their lab, and took $1000 each tax deduction. --===============4076778877840552911==-- From cclist@sydex.com Sat Feb 1 23:11:43 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 23:11:35 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0942672965882857150==" --===============0942672965882857150== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit One mystery to me was why did the industry stick with the EIA-232 levels for terminals and whatnot long after differential EIA-422 was introduced. Higher-speed, better noise immunity, single-ended power supply... Seems that the popular places were Appletalk and ST506 data lines. But not on DTE/DCE. If you were using full-voltage (±15-±25) at high speeds (>500Kbps), the slew rates were ridiculous. Inertia? My old 80286 motherboard had junper-selectable 232 or 422. Still have a couple of tubes of 422 drivers/receivers. --Chuck --===============0942672965882857150==-- From g4ajq1@gmail.com Sat Feb 1 23:13:24 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 18:13:17 -0500 Message-ID: <206bf0d4-8c4c-4e40-8dd4-7524574166ee@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7397076785808415662==" --===============7397076785808415662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-01 18:11, Chuck Guzis via cctalk wrote: > One mystery to me was why did the industry stick with the EIA-232 levels > for terminals and whatnot long after differential EIA-422 was > introduced. Higher-speed, better noise immunity, single-ended power > supply... Seems that the popular places were Appletalk and ST506 data > lines. But not on DTE/DCE. If you were using full-voltage (±15-±25) > at high speeds (>500Kbps), the slew rates were ridiculous. > > Inertia? My old 80286 motherboard had junper-selectable 232 or 422. > > Still have a couple of tubes of 422 drivers/receivers. > > --Chuck > DEC had RS422 available on their DLJ11J four-port interface, but I never saw it used in the field. -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============7397076785808415662==-- From rickb@bensene.com Sun Feb 2 01:11:16 2025 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sun, 02 Feb 2025 01:11:09 +0000 Message-ID: In-Reply-To: <20250201014443.09EF551E576@yagi.h-net.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2743681753106679219==" --===============2743681753106679219== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Vadic had a variant 1200 baud system that wasn't compatible with 212, too,= as I recall. Yup, they did. Can't remember the model number, but I used one of these to d= ial-in to work way back then with a Tektronix 4010 DVST graphics terminal. = Having 1200 baud that worked really well over phone lines at a time when most= people with home computers were getting by with 110 or at most 300 baud we g= reat. But, it only worked at 1200 baud connecting to work. Connecting to= BBS's and such maxed out at 300 baud. At least it was backwards compatible = that way. If I remember correctly, it was about 12 inches deep, about 2 inch= es tall, and perhaps 8 inches wide, and the front panel had a bunch of LEDs t= hat indicated all of the normal RS232 signaling lines (CD, CTS, DSR, RTS, DTR= , RX and TX) along with a few that showed the speed (110, 300, or 1200) that = it was operating at. The "screech" it made when connecting up at 1200 baud w= as very unique sounding. Much more harsh than 103 FSK signaling, but nothing= nearly as complex as the training that went on when modems started getting u= p to 9600 baud. =20 I remember having my first Telebit Trailblazer 9600 baud modem. Reliable 9600= baud over voice-grade POTS lines. They were very remarkable devices for th= eir time. I used it on my home Unix system way back when for UUCP connection= s (for email and USENET) to a number of local UUCP hubs. The training tones= for it were pretty crazy sounding, very unique.=20 I feel old. -Rick =20 --===============2743681753106679219==-- From cctalk@emailtoilet.com Sun Feb 2 01:20:06 2025 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sun, 02 Feb 2025 01:20:01 +0000 Message-ID: <173845920124.1304.1670738806457094118@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2070914917531611106==" --===============2070914917531611106== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It was POTS. --===============2070914917531611106==-- From chris@mainecoon.com Sun Feb 2 01:28:18 2025 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 17:22:23 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4023738638317307662==" --===============4023738638317307662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/1/25 17:11, Rick Bensene via cctalk wrote: > I remember having my first Telebit Trailblazer 9600 baud modem. Reliable 96= 00 baud over voice-grade POTS lines. They were very remarkable devices for = their time. I used it on my home Unix system way back when for UUCP connecti= ons (for email and USENET) to a number of local UUCP hubs. The training ton= es for it were pretty crazy sounding, very unique. IIRC the Trailblazer spoofed the UUCP 'g' protocol which resulted in=20 higher throughput. > I feel old. You and me both, brother. Chris --=20 Christian Kennedy, Ph.D. chris(a)mainecoon.com AF6AP | DB00000692 | PG00029419 http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration=E2=80=A6" --===============4023738638317307662==-- From cz@alembic.crystel.com Sun Feb 2 04:34:26 2025 From: cz To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 23:34:14 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1467722218500058701==" --===============1467722218500058701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit They did. I used a Trailblazer myself back in the day. The concept of super fast transfer in one direction with slow acks in the other was amazing. I think they could also do Kermit acceleration (which was pretty cool even with sliding windows). C On 2/1/2025 8:22 PM, Christian Kennedy via cctalk wrote: > > On 2/1/25 17:11, Rick Bensene via cctalk wrote: >> I remember having my first Telebit Trailblazer 9600 baud modem. >> Reliable 9600 baud over voice-grade POTS lines.   They were very >> remarkable devices for their time.  I used it on my home Unix system >> way back when for UUCP connections (for email and USENET) to a number >> of local UUCP hubs.   The training tones for it were pretty crazy >> sounding, very unique. > IIRC the Trailblazer spoofed the UUCP 'g' protocol which resulted in > higher throughput. >> I feel old. > > You and me both, brother. > > Chris > --===============1467722218500058701==-- From ard.p850ug1@gmail.com Sun Feb 2 07:29:31 2025 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 07:29:15 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7314946259263968914==" --===============7314946259263968914== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Feb 1, 2025 at 10:54 PM Fred Cisin via cctalk wrote: > > IBM used a DB25 socket for their printer port at the computer end, > (male on the card for serial, female on the card for parallel "Centronics") > THAT, of course caused some idiots to attempt to use the parallel port for > serial and vice versa. "I just need a 'gender changer'!" :-) The worst screw-up there (IMHO) came from HP in the HP150 series. This machine had 2 RS232 serial ports as standard on DB25 sockets, wired for some inexplicable reason as DTEs. There was an add-on board that included a parallel printer port. To avoid confusion, this was a DB25 plug. But the board had been laid out for a DB25 socket using the IBM PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12, and so on. -tony --===============7314946259263968914==-- From dave.g4ugm@gmail.com Sun Feb 2 09:57:10 2025 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 09:57:02 +0000 Message-ID: <3ae2fd3b-8787-48d5-9d61-7ed4504bfc80@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5956290935556379543==" --===============5956290935556379543== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 02/02/2025 07:29, Tony Duell via cctalk wrote: > On Sat, Feb 1, 2025 at 10:54 PM Fred Cisin via cctalk > wrote: > > >> IBM used a DB25 socket for their printer port at the computer end, >> (male on the card for serial, female on the card for parallel "Centronics") >> THAT, of course caused some idiots to attempt to use the parallel port for >> serial and vice versa. "I just need a 'gender changer'!" :-) Once saw an IBM Quietwriter damaged by that very action. It was not happy with 12v on its Centronics port.. > The worst screw-up there (IMHO) came from HP in the HP150 series. This > machine had 2 RS232 serial ports as standard on DB25 sockets, wired > for some inexplicable reason as DTEs. There was an add-on board that > included a parallel printer port. To avoid confusion, this was a DB25 > plug. But the board had been laid out for a DB25 socket using the IBM > PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12, > and so on. > > -tony Dave G4UGM --===============5956290935556379543==-- From abuse@cabal.org.uk Sun Feb 2 12:41:55 2025 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 13:41:46 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3815496143938301277==" --===============3815496143938301277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, Feb 01, 2025 at 11:01:34PM +0000, Chuck Guzis via cctalk wrote: > On 2/1/25 13:12, David Wise via cctalk wrote: [...] >> I used the 1488 and 1489 RS232 chips as level shifters on the >> semiconductor RAM board I designed for the IBM 1620. Handy. > In the 1970s/80s, there seemed to be two camps of though WRT EIA > receivers/drivers. There was the Motorola 1488/1489 crowd than there was > the TI crowd (75150/75154). Never bothered to ask which had advantages > over the other. They're still sold and the datasheets are readily-available, so the advantages can be quickly determined: On paper, the 75150 is faster and slightly less power-thirsty than the 1488, but contains just two drivers instead of four. It also costs over twice as much. So between the two of them, the 1488 is the winner, especially if you need more than TxD and RTS. My experience with ye olde Amiga was that its 1488/1489 serial drivers got rather toasty and would occasionally go bang. I've not knowingly used the 75150, but that might just mean that it quietly gets on with its job without incident and I haven't had to desolder the crunchy remains... These days, the MAX232 (or better, one of the clones which doesn't need chunky electrolytics) is the obvious choice, even if you have +/-12V available on your board: it's cheaper and takes much the same board space as than the two-chip 1488/1489 (if five-wire serial is good enough), works off the +5V that's everywhere on your board so you save having to make space to route the +/-12V to it, and doesn't burn your finger when you touch it. Also, the number 1488 is somewhat unfortunate, especially given current events. --===============3815496143938301277==-- From classiccmp@fjl.co.uk Sun Feb 2 13:43:17 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sun, 02 Feb 2025 13:43:09 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCYXPR84MB351500743E47000345F3D9C1AEEB2=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6197444495269400909==" --===============6197444495269400909== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 01/02/2025 21:35, David Wise wrote: > > My experience (Tektronix mainframe via Vadic 2400) was POTS, early 1980's. By the early 1980s V.22 and V.22bis were common (I had a desk full). This bing in the early 1970s, is what's intriguing me. People with large budgets had better toys and I want to know about them :-) --===============6197444495269400909==-- From frank@fjl.co.uk Sun Feb 2 14:45:24 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 13:43:48 +0000 Message-ID: <938cf30d-3d55-4493-9c75-bbec22f92fda@fjl.co.uk> In-Reply-To: <5c9e4614-6048-4cbe-81c5-a6b03d789104@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5810754098461492155==" --===============5810754098461492155== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 31/01/2025 23:07, Chuck Guzis via cctalk wrote: > On 1/31/25 13:57, Tony Duell via cctalk wrote: >> On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk >> wrote: >> >>> The first parallel printers might have been Centronics. Hence the >>> interface and blue ribbon connector being called "Centronics parallel" >> The first printer that Radio Shack/Tandy sold for the TRS-80 (at least >> in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of >> course) -- was a rebadged Cantronics with the obvious parallel >> interface. I have the Centronics version here and repair it using the >> Radio Shack service manual. > Out in the field during the late 60s and 70s, I found that the > Dataproducts interface was more common than the Centronics. I think the Epson MX80 was responsible for standardising the Centronics interface :-) Not only was it TTL only and therefore easier to implement in hardware, but it was much faster than RS-232. You could get other interfaces as add-on boards, including RS-232, Apple, TRS-80 and IEE488. I believe they got a 50% of market share for printers with this, from a standing start. --===============5810754098461492155==-- From frank@fjl.co.uk Sun Feb 2 14:45:33 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Sat, 01 Feb 2025 14:31:14 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7519541745897293082==" --===============7519541745897293082== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 31/01/2025 18:19, Christian Liendo via cctalk wrote: > I was debating sending this, but Microsoft is part of computing > history and fifty years is a milestone. > > https://news.microsoft.com/microsoft-50/ My early Microsoft story. I noticed a problem in Microsoft 6502 BASIC 1.0 rev 3.2 (I saw the banner every day!) supplied by OSI in ROM. Basically after using string arrays for while the machine hung, with the screen "twitching", requiring a reset and warm start. It looked like the garbage collector. I called OSI and they told me to call this number Microsoft as they'd heard about this before. This was in 1978. This was a really expensive transatlantic phone call. I got through and asked to speak to someone about their ROM BASIC.... "No, it wasn't a Commodore PET and I was directed their by OSI." After an expensive wait I got through to a friendly chap who vaguely knew of the issue. Apparently when it was ported to the 6502 the string length became two bytes instead of one and this may have broken it. Unfortunately Rick, the guy who did the 6502 port wasn't around and they guy I was talking to had done the 8080 version. Realising I was talking to someone useless, and the call was costing a bomb, I cut things short (politely) and hung up. It turns out it was Richard Wieland who did the 6502 port. So who did I hang up on? --===============7519541745897293082==-- From frank@fjl.co.uk Sun Feb 2 14:45:44 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sat, 01 Feb 2025 17:40:35 +0000 Message-ID: <5c361631-070e-4e5e-865e-7c25d42f9011@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0765742291672458216==" --===============0765742291672458216== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 01/02/2025 17:33, Chuck Guzis via cctalk wrote: > Another pet gripe of mine is calling the old 50-way SCSI/etc. connector > a "Centronics" connector,regardless of application or number of > connections. > > I prefer to refer to them as "blue ribbon" connectors, developed by > Amphenol in 1950 and used extensively in commercial telephone systems > long before Centronics or SCSI. I've always called them Amphenol connectors, although strictly speaking Amphenol made more than one design. My #1 annoyances are IT types referring non-volatile RAM as CMOS and motherboard configuration utilities as a BIOS. --===============0765742291672458216==-- From frank@fjl.co.uk Sun Feb 2 14:45:54 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sat, 01 Feb 2025 19:55:43 +0000 Message-ID: <969a6b39-fa1b-4fc6-baa5-ae8796b972cf@fjl.co.uk> In-Reply-To: <173836834899.1304.15578533715867905179@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5946949153304753563==" --===============5946949153304753563== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 01/02/2025 00:05, Donald Whittemore via cctalk wrote: > Also using NCR/Tally units. We used Racal-Milgo modems. These things > were about the size of a large home stereo receiver. We started at 2400 > baud. The units could do 3600 or 4800 (I don’t remember which) if a > circuit board strap was moved. Okay, you've got me interested. Was this on a leased line or POTS? I remember the first 1200bps full duplex modem appearing on my desk around 1980, and it was exotic. It became more common over the next few years. But you're talking about ten years earlier than this. I know Racal Vadic (later Thomson then Thales) made some pretty fast and expensive gear, but I didn't realise they'd gone above 1200bps until V.22bis in the 1980s. But that's over POTS - leased line? --===============5946949153304753563==-- From frank@fjl.co.uk Sun Feb 2 14:46:01 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sun, 02 Feb 2025 13:45:09 +0000 Message-ID: <3e4b7aa1-3205-4f1a-b703-aa1591241e85@fjl.co.uk> In-Reply-To: <173845920124.1304.1670738806457094118@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1450082883149555097==" --===============1450082883149555097== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 02/02/2025 01:20, Donald Whittemore via cctalk wrote: > It was POTS. So I wonder how it worked in the early 1970s. Multiple lines? Interesting modulation? QAM before it was mainstream? FSK half duplex? --===============1450082883149555097==-- From g4ajq1@gmail.com Sun Feb 2 15:48:26 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 10:48:18 -0500 Message-ID: In-Reply-To: <938cf30d-3d55-4493-9c75-bbec22f92fda@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7547949908985143640==" --===============7547949908985143640== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-01 08:43, Frank Leonhardt via cctalk wrote: > > On 31/01/2025 23:07, Chuck Guzis via cctalk wrote: >> On 1/31/25 13:57, Tony Duell via cctalk wrote: >>> On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk >>> wrote: >>> >>>> The first parallel printers might have been Centronics.  Hence the >>>> interface and blue ribbon connector being called "Centronics parallel" >>> The first printer that Radio Shack/Tandy sold for the TRS-80 (at least >>> in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of >>> course) -- was a rebadged Cantronics with the obvious parallel >>> interface. I have the Centronics version here and repair it using the >>> Radio Shack service manual. >> Out in the field during the late 60s and 70s, I found that the >> Dataproducts interface was more common than the Centronics. > > I think the Epson MX80 was responsible for standardising the > Centronics interface :-) > > Not only was it TTL only and therefore easier to implement in > hardware, but it was much faster than RS-232. > > You could get other interfaces as add-on boards, including RS-232, > Apple, TRS-80 and IEE488. I believe they got a 50% of market share for > printers with this, from a standing start. > > Why can you not acknowledge that it was standardised by Centronics years before Epson came on the scene? -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============7547949908985143640==-- From classiccmp@fjl.co.uk Sun Feb 2 15:52:02 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 15:51:55 +0000 Message-ID: <7f1ff8fd-ace3-4bcd-9da7-176461d0f227@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0489446131351672373==" --===============0489446131351672373== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 02/02/2025 15:48, Nigel Johnson Ham via cctalk wrote: > On 2025-02-01 08:43, Frank Leonhardt via cctalk wrote: >> >> On 31/01/2025 23:07, Chuck Guzis via cctalk wrote: >>> On 1/31/25 13:57, Tony Duell via cctalk wrote: >>>> On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk >>>> wrote: >>>> >>>>> The first parallel printers might have been Centronics.  Hence the >>>>> interface and blue ribbon connector being called "Centronics parallel" >>>> The first printer that Radio Shack/Tandy sold for the TRS-80 (at least >>>> in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of >>>> course) -- was a rebadged Cantronics with the obvious parallel >>>> interface. I have the Centronics version here and repair it using the >>>> Radio Shack service manual. >>> Out in the field during the late 60s and 70s, I found that the >>> Dataproducts interface was more common than the Centronics. >> >> I think the Epson MX80 was responsible for standardising the >> Centronics interface :-) >> >> Not only was it TTL only and therefore easier to implement in >> hardware, but it was much faster than RS-232. >> >> You could get other interfaces as add-on boards, including RS-232, >> Apple, TRS-80 and IEE488. I believe they got a 50% of market share >> for printers with this, from a standing start. >> >> > Why can you not acknowledge that it was standardised by Centronics > years before Epson came on the scene? > Did you miss the :-) ? --===============0489446131351672373==-- From mhs.stein@gmail.com Sun Feb 2 16:18:36 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 11:18:15 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0792768257513412967==" --===============0792768257513412967== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Same here! Had a 101 in the basement connected to my PET upstairs because of space and noise, with a 35-40 foot long ribbon cable far exceeding the recommended maximum cable length; never a problem. m On Sat, Feb 1, 2025 at 6:03=E2=80=AFPM Fred Cisin via cctalk wrote: > >>> Another pet gripe of mine is calling the old 50-way SCSI/etc. connector > >>> a "Centronics" connector,regardless of application or number of > >>> connections. > >>> I prefer to refer to them as "blue ribbon" connectors, developed by > >>> Amphenol in 1950 and used extensively in commercial telephone systems > >>> long before Centronics or SCSI. > >> I've always called them Amphenol connectors, although strictly speaking > >> Amphenol made more than one design. > > On Sat, 1 Feb 2025, Nigel Johnson Ham via cctalk wrote: > > Actually, in 1971 they were originally marked A-MP, which stood for > > Aero-MarineProducts. > > > > And as far as the statement that Epson standarised the Centronics > connector > > goes, I say 'hogwash' - it was being used by Centronics many years > before > > Epson came on to the market. I was servicing teh Centronics 101, 103 > and > > 306 back in 1975, including making cables to hook them up to PDP11s. I > > Centronics had already STANDARDIZED the connector, but Epson made it known > to the general public. > > I loved the 101. > When I retired mine, I tried unsuccessfully to get $25 each at swaps. So, > I donated them to a community colege that was desperate for sturdier more > rugged printers for their lab, and took $1000 each tax deduction. --===============0792768257513412967==-- From mhs.stein@gmail.com Sun Feb 2 16:40:08 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: A baudy tale Date: Sun, 02 Feb 2025 11:39:47 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7929984111007945392==" --===============7929984111007945392== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Anybody remember Bunker Ramo? Still have one of their two-shoebox-sized modems somewhere... On Sat, Feb 1, 2025 at 8:28 PM Rick Bensene via cctalk < cctalk(a)classiccmp.org> wrote: > > > Vadic had a variant 1200 baud system that wasn't compatible with 212, > too, as I recall. > > Yup, they did. Can't remember the model number, but I used one of these > to dial-in to work way back then with a Tektronix 4010 DVST graphics > terminal. Having 1200 baud that worked really well over phone lines at a > time when most people with home computers were getting by with 110 or at > most 300 baud we great. But, it only worked at 1200 baud connecting to > work. Connecting to BBS's and such maxed out at 300 baud. At least it > was backwards compatible that way. If I remember correctly, it was about > 12 inches deep, about 2 inches tall, and perhaps 8 inches wide, and the > front panel had a bunch of LEDs that indicated all of the normal RS232 > signaling lines (CD, CTS, DSR, RTS, DTR, RX and TX) along with a few that > showed the speed (110, 300, or 1200) that it was operating at. The > "screech" it made when connecting up at 1200 baud was very unique > sounding. Much more harsh than 103 FSK signaling, but nothing nearly as > complex as the training that went on when modems started getting up to 9600 > baud. > > I remember having my first Telebit Trailblazer 9600 baud modem. Reliable > 9600 baud over voice-grade POTS lines. They were very remarkable devices > for their time. I used it on my home Unix system way back when for UUCP > connections (for email and USENET) to a number of local UUCP hubs. The > training tones for it were pretty crazy sounding, very unique. > > I feel old. > > -Rick > --===============7929984111007945392==-- From g4ajq1@gmail.com Sun Feb 2 16:43:15 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 11:43:07 -0500 Message-ID: <6176a16e-7739-4ee2-892e-7dd7cc99a2b3@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9096682237530546825==" --===============9096682237530546825== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-02 11:18, Mike Stein via cctalk wrote: > Same here! > > Had a 101 in the basement connected to my PET upstairs because of space and > noise, with a 35-40 foot long ribbon cable far exceeding the recommended > maximum cable length; never a problem. > > m > > On Sat, Feb 1, 2025 at 6:03=E2=80=AFPM Fred Cisin via cctalk > wrote: > >>>>> Another pet gripe of mine is calling the old 50-way SCSI/etc. connector >>>>> a "Centronics" connector,regardless of application or number of >>>>> connections. >>>>> I prefer to refer to them as "blue ribbon" connectors, developed by >>>>> Amphenol in 1950 and used extensively in commercial telephone systems >>>>> long before Centronics or SCSI. >>>> I've always called them Amphenol connectors, although strictly speaking >>>> Amphenol made more than one design. >> On Sat, 1 Feb 2025, Nigel Johnson Ham via cctalk wrote: >>> Actually, in 1971 they were originally marked A-MP, which stood for >>> Aero-MarineProducts. >>> >>> And as far as the statement that Epson standarised the Centronics >> connector >>> goes, I say 'hogwash' - it was being used by Centronics many years >> before >>> Epson came on to the market. I was servicing teh Centronics 101, 103 >> and >>> 306 back in 1975, including making cables to hook them up to PDP11s. I >> Centronics had already STANDARDIZED the connector, but Epson made it known >> to the general public. >> >> I loved the 101. >> When I retired mine, I tried unsuccessfully to get $25 each at swaps. So, >> I donated them to a community colege that was desperate for sturdier more >> rugged printers for their lab, and took $1000 each tax deduction. My first printer was a TeleType ASR35 (with typing reperforator!)=C2=A0=C2=A0= =C2=A0 I=20 got a few shocks being careless with the 20mA loop at 130VDC! The ease of paper tape meant I was very late getting into the cassette=20 for backup, although I did build a kansas city interface for my 6800 dev=20 kit! cheers, Nigel --=20 Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============9096682237530546825==-- From cclist@sydex.com Sun Feb 2 17:34:28 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 17:34:17 +0000 Message-ID: In-Reply-To: <6176a16e-7739-4ee2-892e-7dd7cc99a2b3@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5611456022121595677==" --===============5611456022121595677== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/2/25 08:43, Nigel Johnson Ham via cctalk wrote: > My first printer was a TeleType ASR35 (with typing reperforator!)    I > got a few shocks being careless with the 20mA loop at 130VDC! > > The ease of paper tape meant I was very late getting into the cassette > for backup, although I did build a kansas city interface for my 6800 dev > kit! My first personal printer was a Diablo Hitype I with the OEM 12-bit interface. I used two S100 parallel ports (don't recall the card) and wrote my own logic-seeking bidirectional driver. Still have the code somewhere. While that produced very nice copy, I lusted after the Teletype DataSpeed 40 line printer. Almost bought one, but got sidetracked by other shiny baubles. --Chuck --===============5611456022121595677==-- From macro@orcam.me.uk Sun Feb 2 18:08:14 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 18:08:04 +0000 Message-ID: In-Reply-To: <15B846E6-FF86-4D66-94E2-1FD4508EC5B9@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5371755330052207930==" --===============5371755330052207930== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 1 Feb 2025, Paul Koning wrote: > >> Was that with an actual RS232 port, i.e., a device using RS232 signal=20 > >> levels, or a "TTL" logic level serial port? I'm guessing the latter. > >=20 > > I'm not sure what you mean by 'a "TTL" logic level serial port', please=20 > > elaborate. Do you mean signalling used between the UART and line drivers= =20 > > by any chance, such as with a serial connection made between UARTs withou= t=20 > > actual line drivers in between? >=20 > What I meant is that a lot of modern computer modules come with serial=20 > ports that are not RS232 but rather using standard logic levels (TTL 0=20 > and 5 volts, or perhaps lower voltages such as 0 and 3.3 volts) for=20 > their signaling. Those basically just expose the logic level I/O of the=20 > UART or the embedded serial port. That makes sense to me since you can then choose what "phy" to attach to=20 it: RS-232, RS-422, IrDA, etc. It's been done since forever, for example=20 I think all DEC Alpha machines had their CPU's debug UART wired to a pin=20 header, but it was up to you to add a line driver if you wanted to make it=20 a real serial port. More recently e.g. the SiFive HiFive Unmatched RISC-V development board=20 has this arrangement for UART #1 (UART #0 is the console port, wired to an=20 onboard dual FTDI USB device already; the other FTDI port being used to=20 carry JTAG over USB) and I had to wire my own line driver along with a=20 DE-9 connector to make it a serial port. But I wouldn't call a bare UART a serial port or use it for external=20 connections: it's just a UART you need to wire to make it a serial port. > Vendors like FTDI make adapters for this. You can get their UART to USB=20 > adapter with actual RS232 interfacing, but also with 5 volt or 3.3 volt=20 > logic levels. That last one is what you'd use to plug into the console=20 > port of a Beaglebone Black microcomputer board, for example. This makes sense to me too: depending on application you can use an FTDI=20 device which is just a UART with a USB interface (as with the console port=20 for the RISC-V device mentioned above) or one that actually implements a=20 serial port with a USB interface, which I'd expect to see with say a USB=20 RS-232 dongle the contents of which you want to keep to the minimum, so a=20 single ASIC with probably just a bunch of external passive components fits=20 perfectly. Just my point of view, thanks for sharing yours! Maciej --===============5371755330052207930==-- From macro@orcam.me.uk Sun Feb 2 18:26:21 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 18:26:06 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6584292270173184415==" --===============6584292270173184415== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 1 Feb 2025, Paul Koning wrote: > I don't know if the MAX3222 is older, or just different. The RS232 > standard doesn't apply to those high rates. And I vaguely remember > seeing words that imply the line drivers should have controlled > rise/fall times. So I think the MAX3222 limits come from implementing > those rate limited edges, not from the age of the design. Fair enough. FWIW I have a couple of configurations of these I/O port cards: dual serial, single serial/single parallel, the latter also in the ExpressCard form factor, all with the relevant D-sub connectors. They all had the 921600bps rate advertised, so clearly the line drivers used had to support it. I was quite surprised though they could go so far beyond. Sadly the PCIe UART/parallel port ASIC went out of production many years ago and it's only residual hardware that's still available to purchase brand new. It was a really good one: it went up to 15.625Mbps, with DMA support, 128-byte FIFOs, etc. Maciej --===============6584292270173184415==-- From paulkoning@comcast.net Sun Feb 2 18:32:52 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 13:32:37 -0500 Message-ID: <75D8259C-BFDC-4345-A69D-2DE4F1F5596A@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3001416894538494209==" --===============3001416894538494209== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 1, 2025, at 5:57=E2=80=AFPM, Chuck Guzis via cctalk wrote: >=20 > On 2/1/25 13:31, Frank Leonhardt via cctalk wrote: >=20 >> I started with minilogs which were +/- 10V logic. >>=20 >> Anyone remember those? >=20 > I remember HTL (15V) being basically a high-voltage version of DTL. >=20 > --Chuck Similarly, early CMOS logic IC, both the original Philips 4000 series and the= 74HC series, support a surprisingly wide range of supply voltages. 3-15 vol= ts for the 4000 series (according to my Radio Shack reference that is), 2 to = 6 volts for 74HC. The speed drops off dramatically with lower voltages, thou= gh, as I found out when using a 74HC bus driver in a 3.3 volt logic design. paul --===============3001416894538494209==-- From macro@orcam.me.uk Sun Feb 2 18:42:19 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 18:42:11 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1878734869120466083==" --===============1878734869120466083== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 2 Feb 2025, Maciej W. Rozycki wrote: > > What I meant is that a lot of modern computer modules come with serial > > ports that are not RS232 but rather using standard logic levels (TTL 0 > > and 5 volts, or perhaps lower voltages such as 0 and 3.3 volts) for > > their signaling. Those basically just expose the logic level I/O of the > > UART or the embedded serial port. > > That makes sense to me since you can then choose what "phy" to attach to > it: RS-232, RS-422, IrDA, etc. It's been done since forever, for example > I think all DEC Alpha machines had their CPU's debug UART wired to a pin > header, but it was up to you to add a line driver if you wanted to make it > a real serial port. I forgot to mention: MIDI has been another notable example where you want to wire a UART to another kind of line driver. I also have a computer where one of USARTs is multiplexed (software-configurable) between an RS-232 line driver with an external DE-9 connector (with pins multiplexed between synchronous-mode TxC/RxC clock lines and asynchronous-mode CTS/DSR inputs respectively) and an AC'97 audio codec (the codec uses the USART's synchronous mode with internal clocking). This one obviously also uses regular voltage levels to talk to the AC'97 device. FWIW, Maciej --===============1878734869120466083==-- From classiccmp@fjl.co.uk Sun Feb 2 19:05:00 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 19:04:45 +0000 Message-ID: <119d16ec-1a2f-4a3f-9efc-ee9a02765c36@fjl.co.uk> In-Reply-To: <75D8259C-BFDC-4345-A69D-2DE4F1F5596A@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6213933985545599472==" --===============6213933985545599472== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 02/02/2025 18:32, Paul Koning via cctalk wrote: > On Feb 1, 2025, at 5:57=E2=80=AFPM, Chuck Guzis via cctalk=20 > wrote: >> On 2/1/25 13:31, Frank Leonhardt via cctalk wrote: >> >>> I started with minilogs which were +/- 10V logic. >>> >>> Anyone remember those? >> I remember HTL (15V) being basically a high-voltage version of DTL. >> >> --Chuck > Similarly, early CMOS logic IC, both the original Philips 4000 series and t= he 74HC series, support a surprisingly wide range of supply voltages. 3-15 v= olts for the 4000 series (according to my Radio Shack reference that is), 2 t= o 6 volts for 74HC. The speed drops off dramatically with lower voltages, th= ough, as I found out when using a 74HC bus driver in a 3.3 volt logic design. > > paul 74HC run on +5V is not the same as TTL, which I fell over recently. The=20 CMOS version can push the output to Vcc whereas TTL can't quite get=20 there. Sometimes it matters - and in the spirit of the RS232 thread, I=20 was interfacing TTL to an ISP interface on an old MCU, which is done=20 using TTL level "RS232"; and you can have DTR flip it into programming=20 mode. Except the "switch to programming mode" pin on the MCU really did=20 need to be Vcc high, not the TTL '1' that the DTR line on the=20 USB->Serial adapter was putting out. Buffered it through an HC gate and the cable worked. 74C (without the H) has a much wider supply voltage range (same as 4000=20 series) Shame no one else hereabouts used minilogs :-( --===============6213933985545599472==-- From lewissa78@gmail.com Sun Feb 2 19:47:21 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sun, 02 Feb 2025 13:47:05 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4573424231418586117==" --===============4573424231418586117== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I came across the following more recent discussion: 2022-05-05 Bit banging on a Tandy CoCo1 - Wikistix And it reminded me of some of my own past exploration into systems that did RS232 without an UART. One example is the NEC PC-8001 (system from about 1979). I recall having trouble getting it past 600 baud for some reason. Another example is the Color Computer 3. UltimateTerm 2.4 from 1987 could bit-bang reliably 9600 baud (also Twilight Term from 1996). The CoCo3 had a higher speed CPU option than its original. "bit banging" (imo) is the host system doing the work of producing the start/stop bits on its own. Which seems to be a "lost art" and why I've wondered if anyone has tried bit-banging on a modern-day 3GHz system - but bit-bang onto what? They took away our serial and parallel ports, like talking directly to a pin is now taboo (literally a security risk, as some networks lock out CD drives and USB also - "no information out" policies). With the UART assist of the RS232Pak cartridge, a CoCo3 managed 115200 baud using a very optimized NetMate terminal written in 2021. That's with the 6551 ACIA doing the serializing work (but I don't think it has any FIFO at all). I've been curious how much faster Interlink/Laplink/FastLynx really was across a parallel cable (I've yet to find reliable bytes-per-second rate info on those). On modernPC to modernPC I really was able to achieve 45KBps (bytes per second) on a 460Kbps serial connection (USB/serial adapters; ones with 128 byte FIFO) using regular ZModem protocol. There are "laplink-style-USB" things, but I'm still curious if we did USB/parallel adapters and a classic laplink cable on two modern PCs, could it surpass the 45KBps serial connection? Still a relic approach, as modern day WiFi+samba should be faster. But where is any modern-make software to even try? -Steve On Fri, Jan 31, 2025 at 2:13=E2=80=AFPM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > > > > On Jan 31, 2025, at 2:18=E2=80=AFPM, Wayne S via cctalk > wrote: > > > > Steve, remember that digital electronics ( I.E. integrated circuits like > uarts) weren=E2=80=99t around during the early days of data transmission. = It was > all analog back then, coils, capacitors, and resistors, so then ideas > regarding fast transmission had to wait for the technology to evolve. Then > as ic=E2=80=99s became available, what you could do with them sparked new i= deas. > Example: data compression within the modem using a microprocessor, thus > getting higher overall throughput than the theoretical maximum of just the > modulation rate. > > True, though "digital electronics" and "integrated circuits" are not > directly related. Digital circuits were first built with relays and with > tubes. What makes them "digital" is that they deal in ones and zeroes > rather than with continuous real-valued signals. > > paul --===============4573424231418586117==-- From kiwi_jonathan@yahoo.com Sun Feb 2 20:23:55 2025 From: Jonathan Stone To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sun, 02 Feb 2025 20:23:48 +0000 Message-ID: <350158596.7510033.1738527828517@mail.yahoo.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7026946282156439296==" --===============7026946282156439296== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk wrote: > [...] "bit banging" (imo) is the > host system doing the work of producing the start/stop bits on its own. > Which seems to be a "lost art" and why I've wondered if anyone has tried > bit-banging on a modern-day 3GHz system - but bit-bang onto what? CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was design= ed before the Philips(?) patents expired. I know there are controllers for SPI that eliminate the need for bit-banging= , and message-layer CAN controllers; but some people still do low-speed bit-b= anging implementations, or subset implementations. IMHO hardware controllers = are so cheap that bit-banging doesn't make sense, given development time, and= that it consumes a dedicated CPU core while sending or receiving. =20 --===============7026946282156439296==-- From paulkoning@comcast.net Sun Feb 2 20:45:29 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sun, 02 Feb 2025 15:45:13 -0500 Message-ID: <66F99C9D-4E8A-4253-B3C2-9F39F64FE2C4@comcast.net> In-Reply-To: <350158596.7510033.1738527828517@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0256590551723673085==" --===============0256590551723673085== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 2, 2025, at 3:23=E2=80=AFPM, Jonathan Stone via cctalk wrote: >=20 >=20 > On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk wrote: >=20 >=20 >> [...] "bit banging" (imo) is the >> host system doing the work of producing the start/stop bits on its own. >> Which seems to be a "lost art" and why I've wondered if anyone has tried >> bit-banging on a modern-day 3GHz system - but bit-bang onto what? >=20 > CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was desi= gned before the Philips(?) patents expired. >=20 > I know there are controllers for SPI that eliminate the need for bit-bangin= g, and message-layer CAN controllers; but some people still do low-speed bit-= banging implementations, or subset implementations. IMHO hardware controllers= are so cheap that bit-banging doesn't make sense, given development time, an= d that it consumes a dedicated CPU core while sending or receiving. Bit banging also works if you have devices that specialize in it. A nice exa= mple is the Programmable I/O (PIO) engines in the Raspberry Pico microcontrol= ler. I did a DDCMP implementation with those, including the "integral modem" featu= re. That includes clock recovery and demodulation of the FM signal, at speed= s up to 10 Mb/s or so though of course no DEC DDCMP device ever ran nearly th= at fast. It looks like it could also do 10 Mb/s Ethernet directly (handling = AUI waveforms in software) -- I haven't tried that but I might just for fun. It would also be an easy way to do the 10 bit UART and 19 bit USRT needed to = drive a PLATO terminal. I also used this machinery to drive a software-defined radio chip from Harris= /Intersil, on a board I originally designed for EPP mode parallel printer por= t interfacing. It has a 16 bit serial port that just runs continously, and t= he PIO handles that nicely. Similar but different is the bit-serial interfac= e you'll find on audio DAC devices, that too would be a very simple case. As for SPI, the standard driver for the CYW43439 WiFi chip on the Pico uses P= IO to deal with the not quite standard SPI used by that device. Or at least = the mismatch in expectations. =20 SPI is only barely standardized and it suffers very badly from the Dave Clark= effect ("so many standards to choose from"). For example, the ENC28J60 Ethe= rnet MAC chip has a SPI interface that does multi-byte transfers with the CS = signal asserted for the entire time, while the "mode 0" SPI standard apparent= ly says it's dropped in between every byte. One solution is to ignore the bu= ilt-in SPI blocks and use the PIO; another is to use the standard SPI block b= ut override the CS pin in software so it remains asserted even though the SPI= block dropped the assert. Ugh. This sort of bit banging design is very effective as well as cost-effective, = considering that a Pico sells for $4 (quantity one, a whole module -- the chi= p alone is under a dollar if I remember right). paul --===============0256590551723673085==-- From mhs.stein@gmail.com Sun Feb 2 21:10:42 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 16:10:22 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5652115928340449933==" --===============5652115928340449933== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable These days you can get rs232<>TTL converter modules for less than the price of a MAX... chip; 3.3-5V (no 12V), only slightly larger than a MAX chip only; for an extra buck or so you can get it with a DE-9 connector https://www.amazon.ca/Converter-Breakout-Computer-Electronic-Components/dp/B0= B19ZCDSL/ref=3Dasc_df_B0B19ZCDSL/?tag=3Dgoogleshopc0c-20&linkCode=3Ddf0&hvadi= d=3D706760541787&hvpos=3D&hvnetw=3Dg&hvrand=3D9876119930178959204&hvpone=3D&h= vptwo=3D&hvqmt=3D&hvdev=3Dc&hvdvcmdl=3D&hvlocint=3D&hvlocphy=3D9000789&hvtarg= id=3Dpla-2202433602635&psc=3D1&mcid=3D9cd0d7ea75903e8fa5cba0a1f9bd24a6&gad_so= urce=3D1 https://www.amazon.ca/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ= C3R6/ref=3Dasc_df_B07BJJC3R6/?tag=3Dgoogleshopc0c-20&linkCode=3Ddf0&hvadid=3D= 706724917578&hvpos=3D&hvnetw=3Dg&hvrand=3D9876119930178959204&hvpone=3D&hvptw= o=3D&hvqmt=3D&hvdev=3Dc&hvdvcmdl=3D&hvlocint=3D&hvlocphy=3D9000789&hvtargid= =3Dpla-1678037092455&psc=3D1&mcid=3Dde32eb91285c3d41b5f4851be222c963&gad_sour= ce=3D1 On Sun, Feb 2, 2025 at 7:41=E2=80=AFAM Peter Corlett via cctalk < cctalk(a)classiccmp.org> wrote: > On Sat, Feb 01, 2025 at 11:01:34PM +0000, Chuck Guzis via cctalk wrote: > > On 2/1/25 13:12, David Wise via cctalk wrote: > [...] > >> I used the 1488 and 1489 RS232 chips as level shifters on the > >> semiconductor RAM board I designed for the IBM 1620. Handy. > > In the 1970s/80s, there seemed to be two camps of though WRT EIA > > receivers/drivers. There was the Motorola 1488/1489 crowd than there was > > the TI crowd (75150/75154). Never bothered to ask which had advantages > > over the other. > > They're still sold and the datasheets are readily-available, so the > advantages can be quickly determined: On paper, the 75150 is faster and > slightly less power-thirsty than the 1488, but contains just two drivers > instead of four. It also costs over twice as much. So between the two of > them, the 1488 is the winner, especially if you need more than TxD and RTS. > > My experience with ye olde Amiga was that its 1488/1489 serial drivers got > rather toasty and would occasionally go bang. I've not knowingly used the > 75150, but that might just mean that it quietly gets on with its job > without > incident and I haven't had to desolder the crunchy remains... > > These days, the MAX232 (or better, one of the clones which doesn't need > chunky electrolytics) is the obvious choice, even if you have +/-12V > available on your board: it's cheaper and takes much the same board space > as > than the two-chip 1488/1489 (if five-wire serial is good enough), works off > the +5V that's everywhere on your board so you save having to make space to > route the +/-12V to it, and doesn't burn your finger when you touch it. > Also, the number 1488 is somewhat unfortunate, especially given current > events. > > --===============5652115928340449933==-- From mhs.stein@gmail.com Sun Feb 2 21:12:43 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 16:12:19 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2249468717443276390==" --===============2249468717443276390== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit after all, it's not the Epson interface ;-) On Sun, Feb 2, 2025 at 10:48 AM Nigel Johnson Ham via cctalk < cctalk(a)classiccmp.org> wrote: > On 2025-02-01 08:43, Frank Leonhardt via cctalk wrote: > > > > On 31/01/2025 23:07, Chuck Guzis via cctalk wrote: > >> On 1/31/25 13:57, Tony Duell via cctalk wrote: > >>> On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk > >>> wrote: > >>> > >>>> The first parallel printers might have been Centronics. Hence the > >>>> interface and blue ribbon connector being called "Centronics parallel" > >>> The first printer that Radio Shack/Tandy sold for the TRS-80 (at least > >>> in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of > >>> course) -- was a rebadged Cantronics with the obvious parallel > >>> interface. I have the Centronics version here and repair it using the > >>> Radio Shack service manual. > >> Out in the field during the late 60s and 70s, I found that the > >> Dataproducts interface was more common than the Centronics. > > > > I think the Epson MX80 was responsible for standardising the > > Centronics interface :-) > > > > Not only was it TTL only and therefore easier to implement in > > hardware, but it was much faster than RS-232. > > > > You could get other interfaces as add-on boards, including RS-232, > > Apple, TRS-80 and IEE488. I believe they got a 50% of market share for > > printers with this, from a standing start. > > > > > Why can you not acknowledge that it was standardised by Centronics years > before Epson came on the scene? > > > -- > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU > Amateur Radio, the origin of the open-source concept! > Skype: TILBURY2591 > > --===============2249468717443276390==-- From spectre@floodgap.com Sun Feb 2 22:18:28 2025 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sun, 02 Feb 2025 14:18:20 -0800 Message-ID: <6fece563-0262-4b64-8cad-6448840dea91@floodgap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6547646991271604270==" --===============6547646991271604270== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > And it reminded me of some of my own past exploration into systems that did > RS232 without an UART. >=20 > One example is the NEC PC-8001 (system from about 1979). I recall having > trouble getting it past 600 baud for some reason. Infamously also the Commodore 64, which a) had the wrong prescaler value for 1200 baud in ROM and b) wasn't particularly efficient, such that software 2400 baud routines were widely used in place of the ROM ones. Part of b) was a well-intentioned but incomplete and not well-implemented attempt at acting li= ke a 6551 ACIA in software. Until those 2400 baud routines started appearing, mo= st people drove the system at 300 baud and no faster (admittedly the VICMODEM and 1660 were only 300 baud themselves). With a real ACIA cartridge, or a system like the Plus/4 which had an ACIA built-in, the 64 had no trouble with faster rates. I used a Turbo232 with a 5= 6K modem for awhile. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Actually, we can overcome gravity (just not the paperwork involved). -----= -- --===============6547646991271604270==-- From cclist@sydex.com Sun Feb 2 22:24:35 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 22:24:26 +0000 Message-ID: <75f4541d-4289-41f7-be73-dc2b01ba6447@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3362421164707377289==" --===============3362421164707377289== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/2/25 10:42, Maciej W. Rozycki via cctalk wrote: > On Sun, 2 Feb 2025, Maciej W. Rozycki wrote: > I forgot to mention: MIDI has been another notable example where you want > to wire a UART to another kind of line driver. I also have a computer > where one of USARTs is multiplexed (software-configurable) between an > RS-232 line driver with an external DE-9 connector (with pins multiplexed > between synchronous-mode TxC/RxC clock lines and asynchronous-mode CTS/DSR > inputs respectively) and an AC'97 audio codec (the codec uses the USART's > synchronous mode with internal clocking). This one obviously also uses > regular voltage levels to talk to the AC'97 device. Except that MIDI is a current-driven interface, not voltage like RS232. 5 ma currentloop, if memory serves.Voltage is secondary. --Chuck --===============3362421164707377289==-- From macro@orcam.me.uk Sun Feb 2 23:07:11 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 23:07:03 +0000 Message-ID: In-Reply-To: <75f4541d-4289-41f7-be73-dc2b01ba6447@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1766069237428906701==" --===============1766069237428906701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 2 Feb 2025, Chuck Guzis via cctalk wrote: > > I forgot to mention: MIDI has been another notable example where you wan= t=20 > > to wire a UART to another kind of line driver. I also have a computer=20 > > where one of USARTs is multiplexed (software-configurable) between an=20 > > RS-232 line driver with an external DE-9 connector (with pins multiplexed= =20 > > between synchronous-mode TxC/RxC clock lines and asynchronous-mode CTS/DS= R=20 > > inputs respectively) and an AC'97 audio codec (the codec uses the USART's= =20 > > synchronous mode with internal clocking). This one obviously also uses=20 > > regular voltage levels to talk to the AC'97 device. >=20 > Except that MIDI is a current-driven interface, not voltage like RS232. > 5 ma currentloop, if memory serves.Voltage is secondary. Sure, I just gave it as another example that you can wire a UART that=20 uses TTL or other standard digital circuit signalling to different line=20 drivers ("phys"). It all boils down to the application. Maciej --===============1766069237428906701==-- From elson@pico-systems.com Mon Feb 3 00:25:31 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 18:25:24 -0600 Message-ID: <3c0c8648-67ff-8257-f057-33c2c93217e9@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0097641601118797375==" --===============0097641601118797375== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/2/25 11:34, Chuck Guzis via cctalk wrote: > > My first personal printer was a Diablo Hitype I with the OEM 12-bit > interface. I used two S100 parallel ports (don't recall the card) and > wrote my own logic-seeking bidirectional driver. Still have the code > somewhere. > > While that produced very nice copy, I lusted after the Teletype > DataSpeed 40 line printer. Almost bought one, but got sidetracked by > other shiny baubles. A guy at work traded me a HUGE Honeywell drum printer for a Centronics 101. That printer was so huge and heavy there was NO WAY it could be in my upstairs computer room.  It was part of a key to tape system that was used as an off-line printer at an insurance company.  I had both the key to tape central unit and the printer.  I dragged a scope down there and ran some tapes through it while scoping the signals.  Then, I made up a paddle card with 25-pair phone cable and designed an interface to my Z80 S-100 system.  I had a scheme of overprinting various punctuation to simulate curly braces and such stuff.  300 LPM printing on a Z80 CP/M system. Jon --===============0097641601118797375==-- From r_a_feldman@hotmail.com Mon Feb 3 00:29:31 2025 From: Robert Feldman To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 00:29:21 +0000 Message-ID: In-Reply-To: <173851921117.1298.6535004696610754859@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3193711693531850439==" --===============3193711693531850439== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >Message: 26 >Date: Sat, 1 Feb 2025 18:13:17 -0500 >From: Nigel Johnson Ham >Subject: [cctalk] Re: RS232 then and now > >On 2025-02-01 18:11, Chuck Guzis via cctalk wrote: >> One mystery to me was why did the industry stick with the EIA-232 levels >> for terminals and whatnot long after differential EIA-422 was >> introduced. Higher-speed, better noise immunity, single-ended power >> supply... Seems that the popular places were Appletalk and ST506 data >> lines. But not on DTE/DCE. If you were using full-voltage (=C2=B115-=C2= =B125) >> at high speeds (>500Kbps), the slew rates were ridiculous. >> >> Inertia? My old 80286 motherboard had junper-selectable 232 or 422. >> >> Still have a couple of tubes of 422 drivers/receivers. >> >> --Chuck >> >DEC had RS422 available on their DLJ11J four-port interface, but I never >saw it used in the field. > The Otrona Attache has two serial ports, DA-15 female, that are jumper select= able between RS-232C, RS-422 or RS-423. Bob --===============3193711693531850439==-- From r_a_feldman@hotmail.com Mon Feb 3 00:42:37 2025 From: Robert Feldman To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 00:42:28 +0000 Message-ID: In-Reply-To: <173851921117.1298.6535004696610754859@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2027927175695805193==" --===============2027927175695805193== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >Message: 31 >Date: Sun, 2 Feb 2025 07:29:15 +0000 >From: Tony Duell >Subject: [cctalk] Re: RS232 then and now > >On Sat, Feb 1, 2025 at 10:54=E2=80=AFPM Fred Cisin via cctalk > wrote: > > >> >> IBM used a DB25 socket for their printer port at the computer end, >> (male on the card for serial, female on the card for parallel "Centronics") >> THAT, of course caused some idiots to attempt to use the parallel port for >> serial and vice versa. "I just need a 'gender changer'!" :-) > >The worst screw-up there (IMHO) came from HP in the HP150 series. This >machine had 2 RS232 serial ports as standard on DB25 sockets, wired >for some inexplicable reason as DTEs. There was an add-on board that >included a parallel printer port. To avoid confusion, this was a DB25 >plug. But the board had been laid out for a DB25 socket using the IBM >PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12, >and so on. > >-tony > My vote for the worst connector screw-up is the AT&T (Olivetti) 6300. Its mon= ochrome monitor used a DB25 to supply both the signals and 12 volts to power = the monitor. Bob --===============2027927175695805193==-- From chris@mainecoon.com Mon Feb 3 01:07:12 2025 From: Christian Kennedy To: cctalk@classiccmp.org Subject: [cctalk] Bit-banging nightmares, wa: Re: Re: RS232 then and now (bitbanging) Date: Sun, 02 Feb 2025 17:07:02 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4195103289835892866==" --===============4195103289835892866== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I am reminded of the Regitel system, a POS system from the early 1970's.  We ran 64 model 33's off of a three-or-four board Regitel mux on a Nova 800; you'd basically load a bunch of registers with the current bit for each port and it would bang them out; input was the reverse.  It was on the processor to the requisite mask-and-shift operations to get the bits to the right place. An image of the cover of the Registel System glossy simply screams 1970's: https://learninglab.si.edu/resources/view/4446092 -- Christian Kennedy, Ph.D. chris(a)mainecoon.com AF6AP | DB00000692 | PG00029419 http://www.mainecoon.com PGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration…" --===============4195103289835892866==-- From wrcooke@wrcooke.net Mon Feb 3 01:22:59 2025 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sun, 02 Feb 2025 20:22:53 -0500 Message-ID: <1917449418.24307.1738545773480@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3489264998250438458==" --===============3489264998250438458== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/02/2025 2:47 PM EST Steve Lewis via cctalk = wrote: > ... > > Another example is the Color Computer 3. UltimateTerm 2.4 from 1987 could > bit-bang reliably 9600 baud (also Twilight Term from 1996). The CoCo3 had > a higher speed CPU option than its original. "bit banging" (imo) is the > host system doing the work of producing the start/stop bits on its own. > Which seems to be a "lost art" Not quite lost. The 1802 crowd is doing amazing things. See https://groups.io/g/cosmacelf/message/33678 And if you know anything about the 1802, it's, uh, not so speedy. Will You just can't beat the person who never gives up. Babe Ruth --===============3489264998250438458==-- From classiccmp@earthlink.net Mon Feb 3 02:59:12 2025 From: "David C. Jenner" To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple & History (Was: Microsoft 50 years) Date: Sun, 02 Feb 2025 18:54:04 -0800 Message-ID: In-Reply-To: <0230C1BB-DEE0-4C3B-95AE-3422844D61AA@avanthar.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8264687155028973860==" --===============8264687155028973860== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My stable of old Macs running BOINC network computing projects keeps the=20 upstairs of my shop heated in the Winter. Fans running to cut out=20 wildfire air pollution are often noisier than the computers. I've been using VueScan for 19 years. A great program. You can even do=20 RAW scans with it and control most photometric parameters within the=20 capabilities of the scanner detector. Dave On 2/1/25 12:40 PM, Zane Healy via cctalk wrote: > On Jan 31, 2025, at 10:23 PM, David C. Jenner via cctalk wrote: >> >> You mean you don't have an old Mac that can do all this? I just went thro= ugh collecting old data on 3 old Mac OS X versions and Mac OS 9 on a G4 tower= that's 25 years old. It also runs an older, very expensive Nikon film scann= er that works great. Networking on this still works great, and I can send to= newer Macs/Windows as needed. >> >> Dave >=20 > I have all my old Macs, though I don=E2=80=99t think the original dual 2Ghz= G5 PowerMac works. It=E2=80=99s a question of space and noise. It=E2=80=99= s a lot easier to use VM=E2=80=99s and emulation where possible. I don=E2=80= =99t have room in my office for more computers, and I=E2=80=99ve grown to app= reciate the quietness of modern systems. Even most of my OpenVMS systems hav= e been migrated over to an ESXI cluster and are running under emulation on Li= nux VM=E2=80=99s. Though I still have one VAX running 24x7. I also find it = amusing to Raspberry Pi boards for mainframe emulation. >=20 > As for your Nikon film scanner (mine finally died), take a look at VueScan,= it will run on any modern OS. My =E2=80=9Cproblem=E2=80=9D scanner is a Pak= on F-135 Plus, which only works with WinXP. >=20 > Zane >=20 >=20 --===============8264687155028973860==-- From lewissa78@gmail.com Mon Feb 3 04:32:12 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 22:31:55 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CIA1PR02MB9613A5B468E0C12B99E677E1B5F52=40IA1PR02MB?= =?utf-8?q?9613=2Enamprd02=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3893380228268362592==" --===============3893380228268362592== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Didn't the original TRS-80 have a kind of screw up, where the tape and display connector were the same? Actually, years later the Atari Lynx had a similar mishap - the power charger and headphone jack port look identical? (something like that, and would cause damage if used incorrectly) Steve On Sun, Feb 2, 2025 at 6:53 PM Robert Feldman via cctalk < cctalk(a)classiccmp.org> wrote: > >Message: 31 > >Date: Sun, 2 Feb 2025 07:29:15 +0000 > >From: Tony Duell > >Subject: [cctalk] Re: RS232 then and now > > > >On Sat, Feb 1, 2025 at 10:54 PM Fred Cisin via cctalk > > wrote: > > > > > >> > >> IBM used a DB25 socket for their printer port at the computer end, > >> (male on the card for serial, female on the card for parallel > "Centronics") > >> THAT, of course caused some idiots to attempt to use the parallel port > for > >> serial and vice versa. "I just need a 'gender changer'!" :-) > > > >The worst screw-up there (IMHO) came from HP in the HP150 series. This > >machine had 2 RS232 serial ports as standard on DB25 sockets, wired > >for some inexplicable reason as DTEs. There was an add-on board that > >included a parallel printer port. To avoid confusion, this was a DB25 > >plug. But the board had been laid out for a DB25 socket using the IBM > >PC pinout. The result was that stb/ ended up on pin 13, D0 on pin 12, > >and so on. > > > >-tony > > > > My vote for the worst connector screw-up is the AT&T (Olivetti) 6300. Its > monochrome monitor used a DB25 to supply both the signals and 12 volts to > power the monitor. > > Bob > > --===============3893380228268362592==-- From lewissa78@gmail.com Mon Feb 3 06:02:28 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Mon, 03 Feb 2025 00:02:00 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3350720323337630767==" --===============3350720323337630767== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I might be banished for saying - but, I actually like Microsoft. It's had up's and downs for sure. Multitasking MS-DOS 4.0, mmhmmm.... I like CRLF line endings :) It's more "OG"! It is two separate actions - if you want to LineFeed and THEN CarriageReturn. Just because we now have a super fast CRT, don't presume that I want to CR all the time :P But yes, the whole 8.3 filename thing was a bit of an embarrassment for too long. But hey, it forces you to be creative with limited resources! What Microsoft did to DR (Digital Research) and Stacker was a bit cold (making Windows difficult to use with DR-DOS in the 90's, and basically straight up theft of Stacker's tech). Allegedly Microsoft also deliberately made Net"Scrape" slower than their own IE.. In early 90s, I did switch from MS-DOS to DR-DOS because at the time, DR-DOS did just have better features (like the 4DOS features/command line scroll back, tab to complete, stuff like that). I tried "Chicago" early beta, but had OS/2 Warp and happily multitasking a year before Win95 came out. But the appeal of DirectX eventually drew me back over for Win98. OS/2 was doing the long-file name support early well. For those bash the entire concept of "closed source" and all that: I don't mind paying a little licensing fee for MPEG (or whatever encoder it is that part of the cost of Microsoft OS covers). And nope, I've not reviewed a single line of code in how any of those encoders work. I'm ok with that. I also don't bust out WireShark after installing any new app or connecting any new device. I don't pour over the schematics of my hardware either. Sure, there is some pride in compiling everything you run from source- OTHO, life is short, at some point I have to have some faith in my fellow man (just mirror all your stuff before installing anything new) Did Microsoft save Apple, twice? Once in 1980 with the Z80 SoftCard, then (allegedly) again as Apple struggled in 1997? The latter has been debunked, that it didn't "save Apple" per se, but a solid 7% stake didn't hurt. I know the whole topic ruffles a lot of feathers. Still, that Z80 card, I do think it was a bit of a life saver at the time (combined with VisiCalc, sure). All the hoopla aside - what I like about Microsoft is (or at least in years past) their manuals, and commitment to helping people learn their systems. The volumes of software Interrupt books! Those were epic. Books on VB, Access, Office, or when DirectX came along - tons of literature on all that, tons of literature about .NET (though the whole Managed C++ thing drove me nuts). They had mountains of fairly well written books, even back in BASIC days. Or MS-DOS 5.0, go read that thing again - it's fantastic, detailing each and every command. I'm slightly biased since I visited the Microsoft Campus in Seattle (twice), meeting with the Visual Studio team. They asked for developers to come by and give direct feedback (around 2005, when VS sucked and they were focused on revamping it). Watching the guy compile Visual Studio, using Visual Studio, was awesome (and debating with the core compiler author about why VS still could only show what row your error was on and not what column; Borland's compiler could tell you which column also, how hard could it be!). Copy and Paste is one of my favorite aspects of Windows. I've tried Linux a number of times over the years - it's terrific for a headless file server or maybe a router, but otherwise, No Thanks.... If you really learn Windows, there are so many short-cut keys, I'm still rarely touching the mouse. One thing I'll nit is when Microsoft does things like Microsoft Bob or Cortana. A while back I picked up a year 2000 Presario, and it has WindowsME with Clippy! (that "taps the screen" for your attention). I'm stuck with WindowsME on that Presario, because it has a proprietary 50-pin "Apple-sized" hard drive, but it's not SCSI - no one has figured it out yet. But that's Presario's fault. As long as we can confidently disable this crap - which so far, we've been able to. Or another nit: how they screwed up Search in Explorer. Then the worst thing was a rumor that Microsoft was going to remove Paint!! That really boiled me, I use Paint so often. I'd probably commit to Linux if they removed Paint :) Yes, Microsoft could have done a lot of things better - but after meeting the Visual Studio team, at least then they really did have some top tier programmers (most with strong Eastern Europe accents, but still). And I don't think asking for money for your work/time is evil, especially if in return you're going to document and support that thing at least for a while (MFC had a good run...) How coupled their GUI has become to their OS is a drag, but I'm ok with it - the consistency is good, I can help family members over the phone. Navigating someone remotely with "this-distro-flavor-of-xterm" suxs. (though there was a time when I was big into Solaris) That said, I'll confess: I've only ever bought Windows twice in my lifetime (I mean as standalone, not included with a system), and one of those times was using a gift-shop voucher that they provided. The secret is that the old Windows serial numbers on abandoned laptops often still work on newer versions of Windows. I was never much into XBox. And while I had an original Surface (the "wrong one" that wasn't very x86 compatible, that original ARM trash one I guess) - and respect that they are still supporting the line - but the name is just annoying: search "what is the best Surface?" and you just get results about countertops. (I'm teasing, plenty of ways to learn about the Surface line - and everyone I've met that actually has and uses one, has always spoken favorably about it). I have numerous co-workers that bash Microsoft all day long. And yeah, I've had my Windows hourglass twirl around inexplicitly. "I'm not DOING anything, why am I hourglassed?" But I respect the challenge of trying to get millions of people to use your platform - and all those drivers involved. And it's not like *nix and macOS side isn't without frustrating issues of their own. So, Cheers to Microsoft's 50 :) May they never remove Paint. -SteveL On Fri, Jan 31, 2025 at 12:19 PM Christian Liendo via cctalk < cctalk(a)classiccmp.org> wrote: > I was debating sending this, but Microsoft is part of computing > history and fifty years is a milestone. > > https://news.microsoft.com/microsoft-50/ > --===============3350720323337630767==-- From cclist@sydex.com Mon Feb 3 06:09:38 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Mon, 03 Feb 2025 06:09:28 +0000 Message-ID: <4add8193-fb88-4eb1-934c-a7820bcbc1a3@sydex.com> In-Reply-To: <1917449418.24307.1738545773480@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6216110509631942625==" --===============6216110509631942625== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/2/25 17:22, Will Cooke via cctalk wrote: > > > Not quite lost. The 1802 crowd is doing amazing things. > See https://groups.io/g/cosmacelf/message/33678 > > And if you know anything about the 1802, it's, uh, not so speedy. At its introduction,it was one of few static CMOS CPUs. You could run it from batteries and stop the clock when not needed. Perfect for telemetry. I think the Intersil 6100 was another, but required 12-bit wide memory. --Chuck --===============6216110509631942625==-- From cclist@sydex.com Mon Feb 3 06:11:16 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Bit-banging nightmares, wa: Re: Re: RS232 then and now (bitbanging) Date: Mon, 03 Feb 2025 06:11:05 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9083328711997139456==" --===============9083328711997139456== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/2/25 17:07, Christian Kennedy via cctalk wrote: > I am reminded of the Regitel system, a POS system from the early > 1970's.  We ran 64 model 33's off of a three-or-four board Regitel mux > on a Nova 800; you'd basically load a bunch of registers with the > current bit for each port and it would bang them out; input was the > reverse.  It was on the processor to the requisite mask-and-shift > operations to get the bits to the right place. Exactly what else (other than bit-bang serial) did people think that the 8085 SID/SOD pins were intended for? --Chuck --===============9083328711997139456==-- From cisin@xenosoft.com Mon Feb 3 06:56:35 2025 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 22:56:29 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8446533045609540804==" --===============8446533045609540804== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 2 Feb 2025, Steve Lewis via cctalk wrote: > Didn't the original TRS-80 have a kind of screw up, where the tape and > display connector were the same? > Actually, years later the Atari Lynx had a similar mishap - the power > charger and headphone jack port look identical? (something like that, and > would cause damage if used incorrectly) > Steve On the back (starboard side), there are THREE 5 pin DIN connectors. Power (external cord-wart), video (composite), and cassette. yes there were incidents regarding those. The original IBM 5150 (PC) had two 5 pin DIN connectors on the back. For keybpoard, and cassette IBM didn't sell a cable, but the Radio Shack cassette cable for TRS80 worked fine.. --===============8446533045609540804==-- From frank@fjl.co.uk Mon Feb 3 07:26:56 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 02 Feb 2025 15:50:33 +0000 Message-ID: <6be2561d-93c2-492b-88c7-af7a2baa37d0@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3285939058783462479==" --===============3285939058783462479== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 02/02/2025 15:48, Nigel Johnson Ham via cctalk wrote: > On 2025-02-01 08:43, Frank Leonhardt via cctalk wrote: >> >> On 31/01/2025 23:07, Chuck Guzis via cctalk wrote: >>> On 1/31/25 13:57, Tony Duell via cctalk wrote: >>>> On Fri, Jan 31, 2025 at 9:38 PM Fred Cisin via cctalk >>>> wrote: >>>> >>>>> The first parallel printers might have been Centronics.  Hence the >>>>> interface and blue ribbon connector being called "Centronics >>>>> parallel" >>>> The first printer that Radio Shack/Tandy sold for the TRS-80 (at least >>>> in the UK) -- the 'TRS-80 Line Printer' (it was nothng of the sort, of >>>> course) -- was a rebadged Cantronics with the obvious parallel >>>> interface. I have the Centronics version here and repair it using the >>>> Radio Shack service manual. >>> Out in the field during the late 60s and 70s, I found that the >>> Dataproducts interface was more common than the Centronics. >> >> I think the Epson MX80 was responsible for standardising the >> Centronics interface :-) >> >> Not only was it TTL only and therefore easier to implement in >> hardware, but it was much faster than RS-232. >> >> You could get other interfaces as add-on boards, including RS-232, >> Apple, TRS-80 and IEE488. I believe they got a 50% of market share >> for printers with this, from a standing start. >> >> > Why can you not acknowledge that it was standardised by Centronics > years before Epson came on the scene? > Understand the :-) --===============3285939058783462479==-- From lewissa78@gmail.com Mon Feb 3 07:45:11 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Mon, 03 Feb 2025 01:44:51 -0600 Message-ID: In-Reply-To: <66F99C9D-4E8A-4253-B3C2-9F39F64FE2C4@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4689413091709742146==" --===============4689413091709742146== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well... From what I've seen (in these 1980 microprocessor cases), they are using "bit shifters" to help pull off their bit banging. So it's not a true self sufficient kind of bit banging. I'm defining a UART as something that also does the work of applying the start/parity and stop bit. The earliest "spec" of a UART that I'm finding is the 1972-ish WD1402A, which does use that term "UART" and has that feature of adding in these bits as programmed (e.g. No Parity would not have the parity bit, and "two stop bits" if so programmed). But it doesn't have its own "baud generator" like later UARTs, the baud rate is "externally selectable". Then on receive, does the opposite so that the host is just handed a nice packaged byte. The CoCo relies on the 6521 PIA (early Commodore's used something similar, later ones using VIA's - still similar), a category of "bit shifters." If they take a full byte, then you may need two bytes to formulate a proper RS232 signal (since they need up to 10 or 11 bits with parity). If it's normal 8-N-1, maybe with some really creative bit twiddling you could make use of the extra 6-bits in the second byte (if it was a streamed buffer of data, so that you knew the next byte to send). Anyway, doing this without even a "bit shifter" assist is truly bit-banging! And now I understand better that to make this RS232, it has to be "level shifted" and the components involved have to be fast enough to provide that kind of "voltage swing." And this swing makes the signal loud and clear, even in noisy industrial environments, across fairly long distances. All that's kind of a waste for a modem that's just a foot away in a quiet room. For telescope work, I recall experienced setups running 100+ meter serial lines to a remote observatory across the property (and not being able to do so with USB; but now-a-days there are powered USB repeaters - though not sure how I'd feel about burying those compared to long serial cables). Well, all this RS232 conversation also revealed to me about the current-loop interface on the IBM serial card. Never noticed that before! IBM 5150 Technical Reference 6025005 AUG81 Page 2-126 (specifies 20mA and what pins) And 2-146 shows how to set the jumper (shunt module). Sort of like the RCA-out pins on CGA cards- an obscure left over part. Which I still never quite figured out how to adapt those 4-pins over to an RCA round connector. -Steve On Sun, Feb 2, 2025 at 2:45=E2=80=AFPM Paul Koning via cctalk wrote: > > > > On Feb 2, 2025, at 3:23=E2=80=AFPM, Jonathan Stone via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > > > On Sunday, February 2, 2025 at 11:47:24 AM PST, Steve Lewis via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > > >> [...] "bit banging" (imo) is the > >> host system doing the work of producing the start/stop bits on its own. > >> Which seems to be a "lost art" and why I've wondered if anyone has tried > >> bit-banging on a modern-day 3GHz system - but bit-bang onto what? > > > > CAN bus (low-speed, subset, like CANhack); GPIB; I^C hardware that was > designed before the Philips(?) patents expired. > > > > I know there are controllers for SPI that eliminate the need for > bit-banging, and message-layer CAN controllers; but some people still do > low-speed bit-banging implementations, or subset implementations. IMHO > hardware controllers are so cheap that bit-banging doesn't make sense, > given development time, and that it consumes a dedicated CPU core while > sending or receiving. > > Bit banging also works if you have devices that specialize in it. A nice > example is the Programmable I/O (PIO) engines in the Raspberry Pico > microcontroller. > > I did a DDCMP implementation with those, including the "integral modem" > feature. That includes clock recovery and demodulation of the FM signal, > at speeds up to 10 Mb/s or so though of course no DEC DDCMP device ever ran > nearly that fast. It looks like it could also do 10 Mb/s Ethernet directly > (handling AUI waveforms in software) -- I haven't tried that but I might > just for fun. > > It would also be an easy way to do the 10 bit UART and 19 bit USRT needed > to drive a PLATO terminal. > > I also used this machinery to drive a software-defined radio chip from > Harris/Intersil, on a board I originally designed for EPP mode parallel > printer port interfacing. It has a 16 bit serial port that just runs > continously, and the PIO handles that nicely. Similar but different is the > bit-serial interface you'll find on audio DAC devices, that too would be a > very simple case. > > As for SPI, the standard driver for the CYW43439 WiFi chip on the Pico > uses PIO to deal with the not quite standard SPI used by that device. Or > at least the mismatch in expectations. > > SPI is only barely standardized and it suffers very badly from the Dave > Clark effect ("so many standards to choose from"). For example, the > ENC28J60 Ethernet MAC chip has a SPI interface that does multi-byte > transfers with the CS signal asserted for the entire time, while the "mode > 0" SPI standard apparently says it's dropped in between every byte. One > solution is to ignore the built-in SPI blocks and use the PIO; another is > to use the standard SPI block but override the CS pin in software so it > remains asserted even though the SPI block dropped the assert. Ugh. > > This sort of bit banging design is very effective as well as > cost-effective, considering that a Pico sells for $4 (quantity one, a whole > module -- the chip alone is under a dollar if I remember right). > > paul --===============4689413091709742146==-- From lewissa78@gmail.com Mon Feb 3 08:03:15 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 02:02:58 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8129499236470711241==" --===============8129499236470711241== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ah, I wrote all about the IBM PC 5150 tape deck capability here: 5150: Setting up Tape Deck Connection (because the 5150 can) =E2=80=94 voidst= ar Indeed it is exactly the same as the Tandy cable. I always assumed since Microsoft had already ported BASIC to the earlier NEC PC-8001 and Tandy Color Computer 1, the same developers ended up being involved in the IBM PC project (and thus seeing the speed and urgency of that project, they just suggest using that same connector and cable-- which in turn made it easier for Microsoft to test and integrate their tape support on that systems BASIC), so a schedule-win for both sides.. As a nit, it was always irritating that IBM (and similar) put that keyboard jack all the way in the back side of the system. The Tandy 1000 finally put that in the front - I never really looked into what board-layout compromise they had to do to make that happen. -Steve On Mon, Feb 3, 2025 at 12:56=E2=80=AFAM Fred Cisin via cctalk wrote: > On Sun, 2 Feb 2025, Steve Lewis via cctalk wrote: > > Didn't the original TRS-80 have a kind of screw up, where the tape and > > display connector were the same? > > Actually, years later the Atari Lynx had a similar mishap - the power > > charger and headphone jack port look identical? (something like that, > and > > would cause damage if used incorrectly) > > Steve > > On the back (starboard side), there are THREE 5 pin DIN connectors. Power > (external cord-wart), video (composite), and cassette. > > yes there were incidents regarding those. > > The original IBM 5150 (PC) had two 5 pin DIN connectors on the back. For > keybpoard, and cassette IBM didn't sell a cable, but the Radio Shack > cassette cable for TRS80 worked fine.. > > > --===============8129499236470711241==-- From bfranchuk@jetnet.ab.ca Mon Feb 3 10:50:44 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Mon, 03 Feb 2025 03:50:35 -0700 Message-ID: In-Reply-To: <4add8193-fb88-4eb1-934c-a7820bcbc1a3@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8910116565017241194==" --===============8910116565017241194== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-02 11:09 p.m., Chuck Guzis via cctalk wrote: > On 2/2/25 17:22, Will Cooke via cctalk wrote: >> >> >> Not quite lost. The 1802 crowd is doing amazing things. >> See https://groups.io/g/cosmacelf/message/33678 >> >> And if you know anything about the 1802, it's, uh, not so speedy. > > At its introduction,it was one of few static CMOS CPUs. You could run > it from batteries and stop the clock when not needed. Perfect for > telemetry. I think the Intersil 6100 was another, but required 12-bit > wide memory. > > --Chuck But then you could buy 12 bit wide memory. 9 bit memory also was rare. Did any use a INDUSTRY STANDARD UART, with a external FIFO chip? --===============8910116565017241194==-- From bfranchuk@jetnet.ab.ca Mon Feb 3 11:01:47 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Mon, 03 Feb 2025 04:01:39 -0700 Message-ID: <96e2a88d-1756-4fce-beb3-ebeaed63f1fe@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1337106497445213848==" --===============1337106497445213848== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-02 11:02 p.m., Steve Lewis via cctalk wrote: > I have numerous co-workers that bash Microsoft all day long. And yeah, > I've had my Windows hourglass twirl around inexplicitly. "I'm not DOING > anything, why am I hourglassed?" But I respect the challenge of trying to > get millions of people to use your platform - and all those drivers > involved. And it's not like *nix and macOS side isn't without > frustrating issues of their own. So, Cheers to Microsoft's 50 :) May they > never remove Paint. I am still *censorsed* with microsoft when they went to 64 bits. A lot of my favorite programs stopped working, mostly because they lost the help files. Sometimes your software is never upgraded, to the latest version, or is over priced for the next version. --===============1337106497445213848==-- From ard.p850ug1@gmail.com Mon Feb 3 11:28:37 2025 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Mon, 03 Feb 2025 11:28:21 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2643422235133874571==" --===============2643422235133874571== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2025 at 10:58=E2=80=AFAM ben via cctalk wrote: > > On 2025-02-02 11:09 p.m., Chuck Guzis via cctalk wrote: > > On 2/2/25 17:22, Will Cooke via cctalk wrote: > >> > >> > >> Not quite lost. The 1802 crowd is doing amazing things. > >> See https://groups.io/g/cosmacelf/message/33678 > >> > >> And if you know anything about the 1802, it's, uh, not so speedy. > > > > At its introduction,it was one of few static CMOS CPUs. You could run > > it from batteries and stop the clock when not needed. Perfect for > > telemetry. I think the Intersil 6100 was another, but required 12-bit > > wide memory. > > > > --Chuck > > But then you could buy 12 bit wide memory. > 9 bit memory also was rare. Is that the meanng of 'a bit on the side' ? > Did any use a INDUSTRY STANDARD UART, with a external FIFO chip? The DEC DZ11 uses the standard 40 pin 'dumb UARTS' and feeds the receive data into FIFO ICs. I am sure there are others. -tony > > > --===============2643422235133874571==-- From billdegnan@gmail.com Mon Feb 3 14:36:27 2025 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Mon, 03 Feb 2025 09:36:06 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9161098468877361233==" --===============9161098468877361233== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Steve/All Part of being a historian is to be dispassionate about what the actual truth is vs, what we'd like, or how we feel about the subject personally. It's kind of a bummer that you feel that you have to apologize about praising MS's accomplishments. But that's the world we live in. Bill On Mon, Feb 3, 2025 at 1:13=E2=80=AFAM Steve Lewis via cctalk wrote: > I might be banished for saying - but, I actually like Microsoft. It's had > up's and downs for sure. Multitasking MS-DOS 4.0, mmhmmm.... > > I like CRLF line endings :) It's more "OG"! It is two separate actions - > if you want to LineFeed and THEN CarriageReturn. Just because we now have > a super fast CRT, don't presume that I want to CR all the time :P But > yes, the whole 8.3 filename thing was a bit of an embarrassment for too > long. But hey, it forces you to be creative with limited resources! > > What Microsoft did to DR (Digital Research) and Stacker was a bit cold > (making Windows difficult to use with DR-DOS in the 90's, and basically > straight up theft of Stacker's tech). Allegedly Microsoft also > deliberately made Net"Scrape" slower than their own IE.. In early 90s, I > did switch from MS-DOS to DR-DOS because at the time, DR-DOS did just have > better features (like the 4DOS features/command line scroll back, tab to > complete, stuff like that). > > I tried "Chicago" early beta, but had OS/2 Warp and happily multitasking a > year before Win95 came out. But the appeal of DirectX eventually drew me > back over for Win98. OS/2 was doing the long-file name support early well. > > For those bash the entire concept of "closed source" and all that: I don't > mind paying a little licensing fee for MPEG (or whatever encoder it is that > part of the cost of Microsoft OS covers). And nope, I've not reviewed a > single line of code in how any of those encoders work. I'm ok with that. > I also don't bust out WireShark after installing any new app or connecting > any new device. I don't pour over the schematics of my hardware either. > Sure, there is some pride in compiling everything you run from source- > OTHO, life is short, at some point I have to have some faith in my fellow > man (just mirror all your stuff before installing anything new) > > Did Microsoft save Apple, twice? Once in 1980 with the Z80 SoftCard, then > (allegedly) again as Apple struggled in 1997? The latter has been > debunked, that it didn't "save Apple" per se, but a solid 7% stake didn't > hurt. I know the whole topic ruffles a lot of feathers. Still, that Z80 > card, I do think it was a bit of a life saver at the time (combined with > VisiCalc, sure). > > > All the hoopla aside - what I like about Microsoft is (or at least in years > past) their manuals, and commitment to helping people learn their systems. > The volumes of software Interrupt books! Those were epic. Books on VB, > Access, Office, or when DirectX came along - tons of literature on all > that, tons of literature about .NET (though the whole Managed C++ thing > drove me nuts). They had mountains of fairly well written books, even back > in BASIC days. Or MS-DOS 5.0, go read that thing again - it's fantastic, > detailing each and every command. I'm slightly biased since I visited the > Microsoft Campus in Seattle (twice), meeting with the Visual Studio team. > They asked for developers to come by and give direct feedback (around 2005, > when VS sucked and they were focused on revamping it). Watching the guy > compile Visual Studio, using Visual Studio, was awesome (and debating with > the core compiler author about why VS still could only show what row your > error was on and not what column; Borland's compiler could tell you which > column also, how hard could it be!). Copy and Paste is one of my favorite > aspects of Windows. I've tried Linux a number of times over the years - > it's terrific for a headless file server or maybe a router, but otherwise, > No Thanks.... If you really learn Windows, there are so many short-cut > keys, I'm still rarely touching the mouse. > > One thing I'll nit is when Microsoft does things like Microsoft Bob or > Cortana. A while back I picked up a year 2000 Presario, and it has > WindowsME with Clippy! (that "taps the screen" for your attention). I'm > stuck with WindowsME on that Presario, because it has a proprietary 50-pin > "Apple-sized" hard drive, but it's not SCSI - no one has figured it out > yet. But that's Presario's fault. As long as we can confidently disable > this crap - which so far, we've been able to. > > Or another nit: how they screwed up Search in Explorer. Then the > worst thing was a rumor that Microsoft was going to remove Paint!! That > really boiled me, I use Paint so often. I'd probably commit to Linux if > they removed Paint :) > > Yes, Microsoft could have done a lot of things better - but after meeting > the Visual Studio team, at least then they really did have some top tier > programmers (most with strong Eastern Europe accents, but still). And I > don't think asking for money for your work/time is evil, especially if in > return you're going to document and support that thing at least for a while > (MFC had a good run...) How coupled their GUI has become to their OS is a > drag, but I'm ok with it - the consistency is good, I can help family > members over the phone. Navigating someone remotely with > "this-distro-flavor-of-xterm" suxs. (though there was a time when I was > big into Solaris) > > That said, I'll confess: I've only ever bought Windows twice in my lifetime > (I mean as standalone, not included with a system), and one of those times > was using a gift-shop voucher that they provided. The secret is that the > old Windows serial numbers on abandoned laptops often still work on newer > versions of Windows. > > I was never much into XBox. And while I had an original Surface (the > "wrong one" that wasn't very x86 compatible, that original ARM trash one I > guess) - and respect that they are still supporting the line - but the name > is just annoying: search "what is the best Surface?" and you just get > results about countertops. (I'm teasing, plenty of ways to learn about the > Surface line - and everyone I've met that actually has and uses one, has > always spoken favorably about it). > > I have numerous co-workers that bash Microsoft all day long. And yeah, > I've had my Windows hourglass twirl around inexplicitly. "I'm not DOING > anything, why am I hourglassed?" But I respect the challenge of trying to > get millions of people to use your platform - and all those drivers > involved. And it's not like *nix and macOS side isn't without > frustrating issues of their own. So, Cheers to Microsoft's 50 :) May they > never remove Paint. > > > -SteveL > > > > > > > > > > > > On Fri, Jan 31, 2025 at 12:19=E2=80=AFPM Christian Liendo via cctalk < > cctalk(a)classiccmp.org> wrote: > > > I was debating sending this, but Microsoft is part of computing > > history and fifty years is a milestone. > > > > https://news.microsoft.com/microsoft-50/ > > > --===============9161098468877361233==-- From wh.sudbrink@verizon.net Mon Feb 3 16:41:50 2025 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Mon, 03 Feb 2025 11:40:58 -0500 Message-ID: <093801db765a$679cb8e0$36d62aa0$@verizon.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2178474904536477473==" --===============2178474904536477473== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I'll give Microsoft one thing... I _HATE_ case sensitive file names. MSDOS/Windows had/has that right. Bill S. -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============2178474904536477473==-- From paulkoning@comcast.net Mon Feb 3 18:09:47 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 13:09:34 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CIA1PR02MB9613A5B468E0C12B99E677E1B5F52=40IA1PR02MB?= =?utf-8?q?9613=2Enamprd02=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0139265775098375950==" --===============0139265775098375950== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 2, 2025, at 7:42=E2=80=AFPM, Robert Feldman via cctalk wrote: >=20 >=20 > My vote for the worst connector screw-up is the AT&T (Olivetti) 6300. Its m= onochrome monitor used a DB25 to supply both the signals and 12 volts to powe= r the monitor. >=20 > Bob DEC did something similar with the Pro, except they used a DA-15 connector to= carry video (monochrome as well as RGB), keyboard data (4800 bps UART) and 1= 2 volt power. paul --===============0139265775098375950==-- From d44617665@hotmail.com Mon Feb 3 18:26:43 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 18:26:31 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3720756351701654659==" --===============3720756351701654659== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes. The chips I used were the engineering sweet spot for my task. The 1620 logic= levels are {ground, resistive pulldown to -12V}. The 1488 (plus clamp diode= s) makes the right levels. Shame about the part number but it's not the chip= 's fault. By injecting current on the 1489's Response Control pins, I could = level shift from 1620 to TTL with low cost and part count. Dave Wise ________________________________ From: Mike Stein via cctalk Sent: Sunday, February 2, 2025 1:10 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Peter Corlett ; Mike Stein Subject: [cctalk] Re: RS232 then and now These days you can get rs232<>TTL converter modules for less than the price of a MAX... chip; 3.3-5V (no 12V), only slightly larger than a MAX chip only; for an extra buck or so you can get it with a DE-9 connector https://www.amazon.ca/Converter-Breakout-Computer-Electronic-Components/dp/B0= B19ZCDSL/ref=3Dasc_df_B0B19ZCDSL/?tag=3Dgoogleshopc0c-20&linkCode=3Ddf0&hvadi= d=3D706760541787&hvpos=3D&hvnetw=3Dg&hvrand=3D9876119930178959204&hvpone=3D&h= vptwo=3D&hvqmt=3D&hvdev=3Dc&hvdvcmdl=3D&hvlocint=3D&hvlocphy=3D9000789&hvtarg= id=3Dpla-2202433602635&psc=3D1&mcid=3D9cd0d7ea75903e8fa5cba0a1f9bd24a6&gad_so= urce=3D1 https://www.amazon.ca/NOYITO-Module-Conversion-Arduino-communicates/dp/B07BJJ= C3R6/ref=3Dasc_df_B07BJJC3R6/?tag=3Dgoogleshopc0c-20&linkCode=3Ddf0&hvadid=3D= 706724917578&hvpos=3D&hvnetw=3Dg&hvrand=3D9876119930178959204&hvpone=3D&hvptw= o=3D&hvqmt=3D&hvdev=3Dc&hvdvcmdl=3D&hvlocint=3D&hvlocphy=3D9000789&hvtargid= =3Dpla-1678037092455&psc=3D1&mcid=3Dde32eb91285c3d41b5f4851be222c963&gad_sour= ce=3D1 On Sun, Feb 2, 2025 at 7:41=E2=80=AFAM Peter Corlett via cctalk < cctalk(a)classiccmp.org> wrote: > On Sat, Feb 01, 2025 at 11:01:34PM +0000, Chuck Guzis via cctalk wrote: > > On 2/1/25 13:12, David Wise via cctalk wrote: > [...] > >> I used the 1488 and 1489 RS232 chips as level shifters on the > >> semiconductor RAM board I designed for the IBM 1620. Handy. > > In the 1970s/80s, there seemed to be two camps of though WRT EIA > > receivers/drivers. There was the Motorola 1488/1489 crowd than there was > > the TI crowd (75150/75154). Never bothered to ask which had advantages > > over the other. > > They're still sold and the datasheets are readily-available, so the > advantages can be quickly determined: On paper, the 75150 is faster and > slightly less power-thirsty than the 1488, but contains just two drivers > instead of four. It also costs over twice as much. So between the two of > them, the 1488 is the winner, especially if you need more than TxD and RTS. > > My experience with ye olde Amiga was that its 1488/1489 serial drivers got > rather toasty and would occasionally go bang. I've not knowingly used the > 75150, but that might just mean that it quietly gets on with its job > without > incident and I haven't had to desolder the crunchy remains... > > These days, the MAX232 (or better, one of the clones which doesn't need > chunky electrolytics) is the obvious choice, even if you have +/-12V > available on your board: it's cheaper and takes much the same board space > as > than the two-chip 1488/1489 (if five-wire serial is good enough), works off > the +5V that's everywhere on your board so you save having to make space to > route the +/-12V to it, and doesn't burn your finger when you touch it. > Also, the number 1488 is somewhat unfortunate, especially given current > events. > > --===============3720756351701654659==-- From imp@bsdimp.com Mon Feb 3 19:02:35 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 12:02:14 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8694122204482347210==" --===============8694122204482347210== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 3, 2025 at 11:09 AM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > > > > On Feb 2, 2025, at 7:42 PM, Robert Feldman via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > > > My vote for the worst connector screw-up is the AT&T (Olivetti) 6300. > Its monochrome monitor used a DB25 to supply both the signals and 12 volts > to power the monitor. > > > > Bob > > DEC did something similar with the Pro, except they used a DA-15 connector > to carry video (monochrome as well as RGB), keyboard data (4800 bps UART) > and 12 volt power. > DEC Rainbow too... And it's easy to short power to another line and take out the line drivers in the keyboard... Warner --===============8694122204482347210==-- From ethan.dicks@gmail.com Mon Feb 3 19:05:31 2025 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 14:05:13 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6056415165634720200==" --===============6056415165634720200== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, Feb 1, 2025 at 6:03 PM Fred Cisin via cctalk wrote: > I loved the 101. > When I retired mine, I tried unsuccessfully to get $25 each at swaps. I had a Centronics 101 back in college. I'm sure I got it because nobody wanted it. Probably got it for $25 or less at a Hamfest or just "get this out of here!" I left it behind when I moved from one college rental to another because I couldn't get help getting it back down the stairs. It was way too heavy for me to lift solo, even when I was 20. -ethan --===============6056415165634720200==-- From ethan.dicks@gmail.com Mon Feb 3 19:08:29 2025 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 14:08:10 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2649374420661192747==" --===============2649374420661192747== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Feb 2, 2025 at 11:38 AM Mike Stein via cctalk wrote: > Had a 101 in the basement connected to my PET upstairs because of space and > noise, with a 35-40 foot long ribbon cable far exceeding the recommended > maximum cable length; never a problem. I ran my 101 off the User Port on my Commodore 64. Wrote a driver to intercept IEC device 4 that fit in the cassette buffer. I still have that driver and that printer cable (left the 101 behind 38 years ago, as mentioned, because of weight). -ethan --===============2649374420661192747==-- From cctalk@emailtoilet.com Mon Feb 3 19:08:49 2025 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Open source a panacea? Date: Mon, 03 Feb 2025 19:08:32 +0000 Message-ID: <173860971242.1304.952682186864839706@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6353848111795943282==" --===============6353848111795943282== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am an old mainframe guy. I could give you my COBOL deck of cards or the com= pile listing. You could pour through the code looking for nefarious/malicious= code. I then hand you the object deck. You have no idea if it matches the co= de you looked at. The only way you could be sure is to compile the code I gav= e you and use your own object deck. So why is open source these days such a beneficial thing? DeepSeek may be ope= n source but I have no way to create my own executable. Besides, I don=E2=80= =99t know what language it is written in but I bet I have no expertise in it.= No way to for me to identify nasty code.=20 Yes, many people may have reviewed the code but that does not mean what I am = running is the result of that code. --===============6353848111795943282==-- From paulkoning@comcast.net Mon Feb 3 19:25:40 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 14:25:28 -0500 Message-ID: In-Reply-To: <173860971242.1304.952682186864839706@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5832123267772002159==" --===============5832123267772002159== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2025, at 2:08=E2=80=AFPM, Donald Whittemore via cctalk wrote: >=20 > I am an old mainframe guy. I could give you my COBOL deck of cards or the c= ompile listing. You could pour through the code looking for nefarious/malicio= us code. I then hand you the object deck. You have no idea if it matches the = code you looked at. The only way you could be sure is to compile the code I g= ave you and use your own object deck. >=20 > So why is open source these days such a beneficial thing? DeepSeek may be o= pen source but I have no way to create my own executable. Besides, I don=E2= =80=99t know what language it is written in but I bet I have no expertise in = it. No way to for me to identify nasty code.=20 >=20 > Yes, many people may have reviewed the code but that does not mean what I a= m running is the result of that code. Open source, properly defined, means not just that you can see the code but t= hat you have the possibility of building it. If DeepSeek is advertised as op= en source but you can't create your own executable, that's clearly false adve= rtising. The language doesn't matter so long as it's an available one. If you don't k= now it you can learn. For example, you could write open source code in COBOL= , that's perfectly valid. Not a whole lot of people are left who can check y= our work, but anyone who wants to can learn the necessary basics. BTW, strictly speaking you should also suspect the compiler. See "Reflection= s on trusting trust". paul --===============5832123267772002159==-- From cisin@xenosoft.com Mon Feb 3 19:36:40 2025 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 11:36:34 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1052469800731624596==" --===============1052469800731624596== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> On Feb 3, 2025, at 2:08=E2=80=AFPM, Donald Whittemore via cctalk wrote: >> >> I am an old mainframe guy. I could give you my COBOL deck of cards or the = compile listing. You could pour through the code looking for nefarious/malici= ous code. I then hand you the object deck. You have no idea if it matches the= code you looked at. The only way you could be sure is to compile the code I = gave you and use your own object deck. On Mon, 3 Feb 2025, Paul Koning via cctalk wrote: > Open source, properly defined, means not just that you can see the code but= that you have the possibility of building it. If DeepSeek is advertised as = open source but you can't create your own executable, that's clearly false ad= vertising. > The language doesn't matter so long as it's an available one. If you don't= know it you can learn. For example, you could write open source code in COB= OL, that's perfectly valid. Not a whole lot of people are left who can check= your work, but anyone who wants to can learn the necessary basics. > BTW, strictly speaking you should also suspect the compiler. See "Reflecti= ons on trusting trust". > paul There is, or was, a COBOL compiler "ported" (prob'ly just keywords and=20 messages translated) to chinese. Although it is doubtful that Deepseek was written in COBOL, it=20 nevertheless is possible. That deck would be difficult to even source enough blank cards for. :-) --===============1052469800731624596==-- From tony@tonyjones.com Mon Feb 3 19:37:05 2025 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 11:36:47 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1437447816321698268==" --===============1437447816321698268== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 3, 2025 at 11:25 AM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > > > > On Feb 3, 2025, at 2:08 PM, Donald Whittemore via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > I am an old mainframe guy. I could give you my COBOL deck of cards or > the compile listing. You could pour through the code looking for > nefarious/malicious code. I then hand you the object deck. You have no idea > if it matches the code you looked at. The only way you could be sure is to > compile the code I gave you and use your own object deck. > > > > So why is open source these days such a beneficial thing? DeepSeek may > be open source but I have no way to create my own executable. Besides, I > don’t know what language it is written in but I bet I have no expertise in > it. No way to for me to identify nasty code. > > > > Yes, many people may have reviewed the code but that does not mean what > I am running is the result of that code. > > Open source, properly defined, means not just that you can see the code > but that you have the possibility of building it. If DeepSeek is > advertised as open source but you can't create your own executable, that's > clearly false advertising. > "but I have no way to create my own executable" it's a model, not an executable. Per the github page "6. How to Run Locally" ... "DeepSeek-V3 can be deployed locally using the following hardware and open-source community software" Broadly I gave up on the original post at " I am an old mainframe guy" --===============1437447816321698268==-- From wrcooke@wrcooke.net Mon Feb 3 19:57:23 2025 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 14:57:17 -0500 Message-ID: <1003144160.126897.1738612637756@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1989473674064095709==" --===============1989473674064095709== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/03/2025 2:36 PM EST Fred Cisin via cctalk w= rote: > > That deck would be difficult to even source enough blank cards for. :-) I suspect for the several million cards you'd need you could easily get some= local paper company to tool up and make them fairly reasonably :-) Will You just can't beat the person who never gives up. Babe Ruth --===============1989473674064095709==-- From cctalk@emailtoilet.com Mon Feb 3 20:42:40 2025 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 20:42:36 +0000 Message-ID: <173861535631.1304.1046164667091333436@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1940907926471339167==" --===============1940907926471339167== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I was not being specific on language or the app. I was questioning the genera= l impression that open source is safe(r). If I am not proficient in the sourc= e language or have the ability to create my own executable I don=E2=80=99t se= e how open source is =E2=80=98safer=E2=80=99 for the average Joe or app. --===============1940907926471339167==-- From als@thangorodrim.ch Mon Feb 3 20:45:22 2025 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 21:40:24 +0100 Message-ID: In-Reply-To: <173860971242.1304.952682186864839706@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1516967725693011932==" --===============1516967725693011932== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 03, 2025 at 07:08:32PM -0000, Donald Whittemore via cctalk wrote: > I am an old mainframe guy. I could give you my COBOL deck of cards or the > compile listing. You could pour through the code looking for > nefarious/malicious code. I then hand you the object deck. You have no idea > if it matches the code you looked at. The only way you could be sure is to > compile the code I gave you and use your own object deck. > > So why is open source these days such a beneficial thing? The idea of Open Source is that not only do you have the source code (which you could get before even for closed source products, e.g. various DEC source distributions on e.g. microfiche - which was of course still owned and copyrighted by DEC), but you can build your own binaries from it, you can change it (and build updated binaries) and - depending on license - are usually encouraged to share you changes. > DeepSeek may be > open source but I have no way to create my own executable. It's a model, not source code. There is no binary in the usual sense. Calling it Open Source is definitely misleading as here it only means you can legally (maybe - that whole LLM space is a bunch of already ongoing lawsuits and an avalanche of more lawsuits waiting to happen due to their creators approach to intellectual property and privacy) run the model yourself without paying whoever built it. > Besides, I don’t > know what language it is written in but I bet I have no expertise in it. No > way to for me to identify nasty code. It's worse than that. It's not written in any language as such. It is a trained machine learning model (specifically, a transformer based LLM), that is essentially an undebuggable black box. Don't like the output the model produces? Adjust the training and retrain. Additionally, all the publicly available hosted LLMs (e.g. ChatGPT) are wrapped in filter layers that both filter the input (i.e. queries against the model) and the output of the model to keep the worst outrages (e.g. "I asked ChatGPT how to build a bomb and it gave me detailed instructions!") somewhat contained. On top of that: A lot of those LLMs are build on theft at an epically large scale. They hovered up everything in sight (and then some) without even pretending to care about intellectual property rights - e.g. the NY Times has taken OpenAI to court because they managed to make the OpenAI LLMs spit out long verbatim fragments of NY Times content. The hilarious part is that DeepSeek essentially stole from OpenAI that which OpenAI previously stole from everyone else and OpenAI is very angry about the lack of honor among thieves or something ;-) > Yes, many people may have reviewed the code but that does not mean what I am > running is the result of that code. Aside from the classic "Reflections on trusting trust", you are far more likely to get bitten by wonky compiler optimizations than an actually malicious compiler. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============1516967725693011932==-- From tony@tonyjones.com Mon Feb 3 20:46:32 2025 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 12:46:13 -0800 Message-ID: In-Reply-To: <173861535631.1304.1046164667091333436@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8815947714821539711==" --===============8815947714821539711== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2025 at 12:42=E2=80=AFPM Donald Whittemore via cctalk < cctalk(a)classiccmp.org> wrote: > If I am not proficient in the source language or have the ability to > create my own executable I don=E2=80=99t see how open source is =E2=80=98sa= fer=E2=80=99 for the > average Joe or app. > I'm not seeing what *your* abilities (to understand, to create your own version etc) has to do with code safety? --===============8815947714821539711==-- From wayne.sudol@hotmail.com Mon Feb 3 20:51:16 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 20:51:07 +0000 Message-ID: In-Reply-To: <173861535631.1304.1046164667091333436@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5465675415420439912==" --===============5465675415420439912== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Open source is only safer in that the source code is available to be analyzed= and compiled into something usable. Even if you compile the source, there st= ill might be =E2=80=9Cunsafe=E2=80=9D things in it, hence it should be analyz= ed first. If safety is of paramount importance, a supplied object or executable should = never be used. That=E2=80=99s just common sense. =20 Sent from my iPhone > On Feb 3, 2025, at 12:42, Donald Whittemore via cctalk wrote: >=20 > =EF=BB=BFI was not being specific on language or the app. I was questioning= the general impression that open source is safe(r). If I am not proficient i= n the source language or have the ability to create my own executable I don= =E2=80=99t see how open source is =E2=80=98safer=E2=80=99 for the average Joe= or app. --===============5465675415420439912==-- From cctalk@emailtoilet.com Mon Feb 3 20:51:25 2025 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 20:51:14 +0000 Message-ID: <173861587475.1304.667012532590635515@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6787674925719559840==" --===============6787674925719559840== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable If I don=E2=80=99t have the code expertise or compiling capability how do I k= now the executable is safe? --===============6787674925719559840==-- From paulkoning@comcast.net Mon Feb 3 20:51:44 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 15:51:24 -0500 Message-ID: In-Reply-To: <173861535631.1304.1046164667091333436@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7943540890409795023==" --===============7943540890409795023== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2025, at 3:42=E2=80=AFPM, Donald Whittemore via cctalk wrote: >=20 > I was not being specific on language or the app. I was questioning the gene= ral impression that open source is safe(r). If I am not proficient in the sou= rce language or have the ability to create my own executable I don=E2=80=99t = see how open source is =E2=80=98safer=E2=80=99 for the average Joe or app. That's true but that's because of your limitations, not because of the nature= of open source. Open source is the "thousand eyeballs" notion that more review is better. Th= ose eyeballs need to be skilled, not just in the programming language used bu= t more importantly in the subject matter of the code. You can't be a good op= en source compiler reviewer if you're not skilled in compilers. You can't ve= rify the correctness of, say, GPG, if you don't know cryptography. The general population of software users is the beneficiary of all those eyeb= alls; it isn't necessary for every last one of them to do the reviewing. paul --===============7943540890409795023==-- From paulkoning@comcast.net Mon Feb 3 20:54:45 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 15:54:31 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0477984050234347318==" --===============0477984050234347318== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2025, at 3:40=E2=80=AFPM, Alexander Schreiber via cctalk wrote: >=20 > ... > On top of that: A lot of those LLMs are build on theft at an epically large > scale. They hovered up everything in sight (and then some) without even > pretending to care about intellectual property rights - e.g. the NY Times > has taken OpenAI to court because they managed to make the OpenAI LLMs > spit out long verbatim fragments of NY Times content. The hilarious part > is that DeepSeek essentially stole from OpenAI that which OpenAI previously > stole from everyone else and OpenAI is very angry about the lack of honor > among thieves or something ;-) Excellent point. I tend to refer to LLMs as "derived work generators" to poi= nt out the copyright problems that are fundamental to what they do. I also tend to wonder about web hoovering as a training scheme, given that a = lot of web content is fiction. And I don't mean "misinformation", I just mea= n novels and the like. What happens to an LLM that inhales "The Martian" or = "Ringworld" ? paul --===============0477984050234347318==-- From wayne.sudol@hotmail.com Mon Feb 3 20:55:03 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 20:54:49 +0000 Message-ID: In-Reply-To: <173861587475.1304.667012532590635515@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4934424031723225361==" --===============4934424031723225361== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable You do not have that absolute ability to know. You can rely on a virus scanne= r to help but that=E2=80=99s not absolute either.=20 Sent from my iPhone > On Feb 3, 2025, at 12:51, Donald Whittemore via cctalk wrote: >=20 > =EF=BB=BFIf I don=E2=80=99t have the code expertise or compiling capability= how do I know the executable is safe? --===============4934424031723225361==-- From tony@tonyjones.com Mon Feb 3 20:56:49 2025 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 12:56:33 -0800 Message-ID: In-Reply-To: <173861587475.1304.667012532590635515@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2716623105815139031==" --===============2716623105815139031== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 3, 2025 at 12:51 PM Donald Whittemore via cctalk < cctalk(a)classiccmp.org> wrote: > If I don’t have the code expertise or compiling capability how do I know > the executable is safe? > How do you know a closed-source executable is safe? Hackers have installed vulnerabilities into closed source software. As previously said, even if you have the code expertise and ability to re-compile you're trusting your compiler. You seem to be looking for a guarantee that doesn't exist. Now whether 1,000,000 eye balls looking for bugs in open source code results in a "safer" end product given that there are an arbitrary number of bad actors who can also look for vulnerabilities is an issue of legitimate debate. Of course many of these are already looking through closed source binaries for vulnerabilities. --===============2716623105815139031==-- From ethan.dicks@gmail.com Mon Feb 3 20:57:50 2025 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 15:57:34 -0500 Message-ID: In-Reply-To: <173860971242.1304.952682186864839706@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3934870440868388804==" --===============3934870440868388804== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2025 at 2:08=E2=80=AFPM Donald Whittemore via cctalk wrote: > I am an old mainframe guy. I could give you my COBOL deck of cards or the c= ompile listing. You could pour through the code looking for nefarious/malicio= us code. I then hand you the object deck. You have no idea if it matches the = code you looked at. The only way you could be sure is to compile the code I g= ave you and use your own object deck. That's basically true but "why Open Source" goes way beyond that. From the start, Open Source wasn't focused on "this is good for security" but "I should have the right to repair". In the face of 100% proprietary software, users have to beg the vendor to fix bugs, add features, then there's what happens to products that are abandoned and the OS moves on and updates are mandatory (system calls, adding SMP spinlocking (done that myself), and more). At the root of Open Source is you, the user, have the right to the source cod= e. In the early days, that's as far as it went but especially after the Morris Worm, security became very important, Open Source afforded users the ability to inspect the code for vulnerabilities in ways that you could not if all you had was the binaries. . > So why is open source these days such a beneficial thing? Because it allows those folks with skills (or money to hire out) the _ability_ to modify software, to build on the work of others. Now, it's not just one person or company writing code, anyone it touches can have a shot. > DeepSeek may be open source but I have no way to create my own executable. = Besides, I don=E2=80=99t know what language it is written in but I bet I have= no expertise in it. No way to for me to identify nasty code. Not all things are for all people. I don't know COBOL (I decided that back in 1978) so I would be the wrong person to evaluate or extend that, but there's plenty of stuff I can and do work on. I'm a contributor to several Open Source projects. I'm happy to help on them because I have the skills and I have the interest. Not everyone does. Some people just download and consume, and that's fine too. > Yes, many people may have reviewed the code but that does not mean what I a= m running is the result of that code. That's on you. -ethan --===============3934870440868388804==-- From wayne.sudol@hotmail.com Mon Feb 3 21:02:08 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 21:01:56 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8185985363346384648==" --===============8185985363346384648== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To all, i do think the meaning of =E2=80=9CSafer=E2=80=9D needs to be explain= ed in the context of this debate. Sent from my iPhone > On Feb 3, 2025, at 12:57, Ethan Dicks via cctalk = wrote: >=20 > =EF=BB=BFOn Mon, Feb 3, 2025 at 2:08=E2=80=AFPM Donald Whittemore via cctalk > wrote: >> I am an old mainframe guy. I could give you my COBOL deck of cards or the = compile listing. You could pour through the code looking for nefarious/malici= ous code. I then hand you the object deck. You have no idea if it matches the= code you looked at. The only way you could be sure is to compile the code I = gave you and use your own object deck. >=20 > That's basically true but "why Open Source" goes way beyond that. >=20 > From the start, Open Source wasn't focused on "this is good for > security" but "I should have the right to repair". In the face of > 100% proprietary software, users have to beg the vendor to fix bugs, > add features, then there's what happens to products that are abandoned > and the OS moves on and updates are mandatory (system calls, adding > SMP spinlocking (done that myself), and more). >=20 > At the root of Open Source is you, the user, have the right to the source c= ode. >=20 > In the early days, that's as far as it went but especially after the > Morris Worm, security became very important, Open Source afforded > users the ability to inspect the code for vulnerabilities in ways that > you could not if all you had was the binaries. > . >> So why is open source these days such a beneficial thing? >=20 > Because it allows those folks with skills (or money to hire out) the > _ability_ to modify software, to build on the work of others. Now, > it's not just one person or company writing code, anyone it touches > can have a shot. >=20 >> DeepSeek may be open source but I have no way to create my own executable.= Besides, I don=E2=80=99t know what language it is written in but I bet I hav= e no expertise in it. No way to for me to identify nasty code. >=20 > Not all things are for all people. I don't know COBOL (I decided that > back in 1978) so I would be the wrong person to evaluate or extend > that, but there's plenty of stuff I can and do work on. I'm a > contributor to several Open Source projects. I'm happy to help on > them because I have the skills and I have the interest. Not everyone > does. Some people just download and consume, and that's fine too. >=20 >> Yes, many people may have reviewed the code but that does not mean what I = am running is the result of that code. >=20 > That's on you. >=20 > -ethan --===============8185985363346384648==-- From ethan.dicks@gmail.com Mon Feb 3 21:02:15 2025 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 16:01:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3950932700925783470==" --===============3950932700925783470== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2025 at 2:43=E2=80=AFPM Paul Koning via cctalk wrote: > Open source, properly defined, means not just that you can see the code but= that you have the possibility of building it. If DeepSeek is advertised as = open source but you can't create your own executable, that's clearly false ad= vertising. If you can't afford enough RAM/disk/CPUs to create and run it, that doesn't mean "not Open Source". Likewise with access to sufficient volume of training data in the case of an LLM. --===============3950932700925783470==-- From cclist@sydex.com Mon Feb 3 21:08:44 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 21:08:34 +0000 Message-ID: <13f6dd6c-e219-4bc2-b39a-b0a449d6390a@sydex.com> In-Reply-To: =?utf-8?q?=3CBN6PR04MB08996CC0167466EFB0E67432E4F52=40BN6PR04MB?= =?utf-8?q?0899=2Enamprd04=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6739171538774799633==" --===============6739171538774799633== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/3/25 12:51, Wayne S via cctalk wrote: > If safety is of paramount importance, a supplied object or executable shoul= d never be used. That=E2=80=99s just common sense. > =20 > Sent from my iPhone Seems to be a cognitive disconnect, here. --===============6739171538774799633==-- From tony@tonyjones.com Mon Feb 3 21:09:21 2025 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 13:09:05 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0450724107236368722==" --===============0450724107236368722== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 3, 2025 at 12:45 PM Alexander Schreiber via cctalk < cctalk(a)classiccmp.org> wrote: > On Mon, Feb 03, 2025 at 07:08:32PM -0000, Donald Whittemore via cctalk > wrote: > > On top of that: A lot of those LLMs are build on theft at an epically large > scale. They hovered up everything in sight (and then some) without even > pretending to care about intellectual property rights - e.g. the NY Times > has taken OpenAI to court because they managed to make the OpenAI LLMs > spit out long verbatim fragments of NY Times content. The hilarious part > is that DeepSeek essentially stole from OpenAI that which OpenAI previously > stole from everyone else and OpenAI is very angry about the lack of honor > among thieves or something ;-) > My understanding was that OpenAI accused DeepSeek of "distilling" their model. Via presumably making API queries to OpenAIs service. However normally 'distillation" is the process of generating a smaller ("student") model from a larger ("teacher") model except in this case DeepSeek apparantly created something more of a peer to the teacher. Maybe there was some "veneer" final training but the basic assertion of "they stole our work" is probably more of OpenAI trying to control the narrative. Now whether DeepSeek stole N different entities IP, that's a different question. As you said there is no way to reproduce the model, so what's on github isn't "open source" in most peoples understanding. Still it's better than Microsoft/OpenAI where the model is "closed" behind an API. --===============0450724107236368722==-- From smbaker@gmail.com Mon Feb 3 21:14:39 2025 From: Scott Baker To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 13:14:20 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8458513589212829136==" --===============8458513589212829136== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable My own thoughts as a sometimes-opensource developer: 1. Opensource allows you to leverage the community. They will sometimes research problems, fix bugs, or develop features. 2. Opensource allows people to answer their own questions. Documentation always drifts from implementation. If you want to know how something works, read the code. It may take some effort, but you'll know how it works. 3. Opensource inhibits "security through obscurity" by preventing obscurity. You're less likely to do dumb things in plain sight, and more likely to get caught if you do. Being able to "build it yourself" is the benefit that seems to have most been talked about in this thread, but then you go down the rabbit-hole of "... but did you build the compiler yourself?" and "... but did you build the compiler that compiled the compiler yourself?". Scott On Mon, Feb 3, 2025 at 1:03=E2=80=AFPM Tony Jones via cctalk wrote: > On Mon, Feb 3, 2025 at 12:51=E2=80=AFPM Donald Whittemore via cctalk < > cctalk(a)classiccmp.org> wrote: > > > If I don=E2=80=99t have the code expertise or compiling capability how do= I know > > the executable is safe? > > > > How do you know a closed-source executable is safe? Hackers have > installed vulnerabilities into closed source software. > > As previously said, even if you have the code expertise and ability to > re-compile you're trusting your compiler. > > You seem to be looking for a guarantee that doesn't exist. > > Now whether 1,000,000 eye balls looking for bugs in open source code > results in a "safer" end product given that there are an arbitrary number > of bad actors who can also look for vulnerabilities is an issue of > legitimate debate. Of course many of these are already looking through > closed source binaries for vulnerabilities. > --===============8458513589212829136==-- From paulkoning@comcast.net Mon Feb 3 21:14:59 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 16:14:42 -0500 Message-ID: <86A47B04-01D5-4322-8FC5-F7662EA84F57@comcast.net> In-Reply-To: <13f6dd6c-e219-4bc2-b39a-b0a449d6390a@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1354477580047098190==" --===============1354477580047098190== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2025, at 4:08=E2=80=AFPM, Chuck Guzis via cctalk wrote: >=20 > On 2/3/25 12:51, Wayne S via cctalk wrote: >> If safety is of paramount importance, a supplied object or executable shou= ld never be used. That=E2=80=99s just common sense. >>=20 >> Sent from my iPhone >=20 > Seems to be a cognitive disconnect, here. There is something there, though. If you use a binary supplied by a packager= you have to worry not just about the bugs in the original open source projec= t, but also about bugs added by patches created by the packager. There is a = notorious example of one of the Linux distributions (Debian?) inserting a fat= al security bug into openSSL. The original was right, but someone made a patc= h that clearly demonstrated an utter lack of clue. paul --===============1354477580047098190==-- From als@thangorodrim.ch Mon Feb 3 21:15:16 2025 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 22:12:10 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5221726453500995174==" --===============5221726453500995174== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 03, 2025 at 03:54:31PM -0500, Paul Koning via cctalk wrote: >=20 >=20 > > On Feb 3, 2025, at 3:40=E2=80=AFPM, Alexander Schreiber via cctalk > > wrote: > >=20 > > ... On top of that: A lot of those LLMs are build on theft at an epically > > large scale. They hovered up everything in sight (and then some) without > > even pretending to care about intellectual property rights - e.g. the NY > > Times has taken OpenAI to court because they managed to make the OpenAI > > LLMs spit out long verbatim fragments of NY Times content. The hilarious > > part is that DeepSeek essentially stole from OpenAI that which OpenAI > > previously stole from everyone else and OpenAI is very angry about the la= ck > > of honor among thieves or something ;-) >=20 > Excellent point. I tend to refer to LLMs as "derived work generators" to > point out the copyright problems that are fundamental to what they do. I just call them "bullshit generators", based on Harry Frankfurt's "On Bullshit". > I also tend to wonder about web hoovering as a training scheme, given that a > lot of web content is fiction. And I don't mean "misinformation", I just > mean novels and the like. What happens to an LLM that inhales "The Martian" > or "Ringworld" ? That's probably a lot less harmless than what already happened: More than one model had to be pulled back and deleted (as well as the corpus it was trained from) because its makers had unknowingly hovered up CSAM content, trained the model with it and it was cheerfully spitting that filth out again. If you blindly hover up the entire Internet, you're going find stuff that you probably don't want to have on your systems. Kind regards, Alex. --=20 "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============5221726453500995174==-- From als@thangorodrim.ch Mon Feb 3 21:15:25 2025 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 22:04:45 +0100 Message-ID: In-Reply-To: =?utf-8?q?=3CBN6PR04MB0899D6DC4E6E95FF6049C878E4F52=40BN6PR04MB?= =?utf-8?q?0899=2Enamprd04=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6373495078771606442==" --===============6373495078771606442== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 03, 2025 at 08:54:49PM +0000, Wayne S via cctalk wrote: > You do not have that absolute ability to know. You can rely on a virus > scanner to help but that’s not absolute either. Except those also have a lovely track record off becoming entry points for malicious software by themselves due to the deep system access and privileges they tend to require. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============6373495078771606442==-- From wayne.sudol@hotmail.com Mon Feb 3 21:28:00 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 21:27:51 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2887240193447770135==" --===============2887240193447770135== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Feb 3, 2025, at 13:15, Alexander Schreiber via cctalk wrote: >=20 > =EF=BB=BFOn Mon, Feb 03, 2025 at 03:54:31PM -0500, Paul Koning via cctalk w= rote: >>=20 >>=20 >>> On Feb 3, 2025, at 3:40=E2=80=AFPM, Alexander Schreiber via cctalk >>> wrote: >>>=20 >>> ... On top of that: A lot of those LLMs are build on theft at an epically >>> large scale. They hovered up everything in sight (and then some) without >>> even pretending to care about intellectual property rights - e.g. the NY >>> Times has taken OpenAI to court because they managed to make the OpenAI >>> LLMs spit out long verbatim fragments of NY Times content. The hilarious >>> part is that DeepSeek essentially stole from OpenAI that which OpenAI >>> previously stole from everyone else and OpenAI is very angry about the la= ck >>> of honor among thieves or something ;-) >>=20 >> Excellent point. I tend to refer to LLMs as "derived work generators" to >> point out the copyright problems that are fundamental to what they do. >=20 > I just call them "bullshit generators", based on Harry Frankfurt's "On > Bullshit". >=20 >> I also tend to wonder about web hoovering as a training scheme, given that= a >> lot of web content is fiction. And I don't mean "misinformation", I just >> mean novels and the like. What happens to an LLM that inhales "The Martia= n" >> or "Ringworld" ? >=20 > That's probably a lot less harmless than what already happened: More than > one model had to be pulled back and deleted (as well as the corpus it was > trained from) because its makers had unknowingly hovered up CSAM content, > trained the model with it and it was cheerfully spitting that filth out aga= in. > If you blindly hover up the entire Internet, you're going find stuff that > you probably don't want to have on your systems. >=20 > Kind regards, > Alex. > -- > "Opportunity is missed by most people because it is dressed in overalls and > looks like work." -- Thomas A. Edison --===============2887240193447770135==-- From wayne.sudol@hotmail.com Mon Feb 3 21:30:10 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 21:30:03 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2268831403575719882==" --===============2268831403575719882== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Alex, your posts come over with the =E2=80=9Cflag=E2=80=9D set (i get a red = =E2=80=9Cflag=E2=80=9D on my iphone). Did you mean to flag all your responses= for some reason ?=20 Sent from my iPhone > On Feb 3, 2025, at 13:15, Alexander Schreiber via cctalk wrote: >=20 > =EF=BB=BFOn Mon, Feb 03, 2025 at 03:54:31PM -0500, Paul Koning via cctalk w= rote: >>=20 >>=20 >>> On Feb 3, 2025, at 3:40=E2=80=AFPM, Alexander Schreiber via cctalk >>> wrote: >>>=20 >>> ... On top of that: A lot of those LLMs are build on theft at an epically >>> large scale. They hovered up everything in sight (and then some) without >>> even pretending to care about intellectual property rights - e.g. the NY >>> Times has taken OpenAI to court because they managed to make the OpenAI >>> LLMs spit out long verbatim fragments of NY Times content. The hilarious >>> part is that DeepSeek essentially stole from OpenAI that which OpenAI >>> previously stole from everyone else and OpenAI is very angry about the la= ck >>> of honor among thieves or something ;-) >>=20 >> Excellent point. I tend to refer to LLMs as "derived work generators" to >> point out the copyright problems that are fundamental to what they do. >=20 > I just call them "bullshit generators", based on Harry Frankfurt's "On > Bullshit". >=20 >> I also tend to wonder about web hoovering as a training scheme, given that= a >> lot of web content is fiction. And I don't mean "misinformation", I just >> mean novels and the like. What happens to an LLM that inhales "The Martia= n" >> or "Ringworld" ? >=20 > That's probably a lot less harmless than what already happened: More than > one model had to be pulled back and deleted (as well as the corpus it was > trained from) because its makers had unknowingly hovered up CSAM content, > trained the model with it and it was cheerfully spitting that filth out aga= in. > If you blindly hover up the entire Internet, you're going find stuff that > you probably don't want to have on your systems. >=20 > Kind regards, > Alex. > -- > "Opportunity is missed by most people because it is dressed in overalls and > looks like work." -- Thomas A. Edison --===============2268831403575719882==-- From wdonzelli@gmail.com Mon Feb 3 21:56:45 2025 From: William Donzelli To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 16:56:30 -0500 Message-ID: In-Reply-To: <1003144160.126897.1738612637756@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4000278377241967982==" --===============4000278377241967982== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I suspect for the several million cards you'd need you could easily get so= me local paper company to tool up and make them fairly reasonably :-) Likely not. Proper paper for punch cards is NOTORIOUSLY difficult to make. Cardamation tried after the supply ran out, and they failed. I have about 200,000 and they really do not take up much room. -- Will --===============4000278377241967982==-- From bfranchuk@jetnet.ab.ca Mon Feb 3 22:08:54 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 15:08:44 -0700 Message-ID: <6cf34fa6-8bcd-4534-838e-0d190f45a4ae@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1678104538310868435==" --===============1678104538310868435== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > > At the root of Open Source is you, the user, have the right to the source code. > > In the early days, that's as far as it went but especially after the > Morris Worm, security became very important, Open Source afforded > users the ability to inspect the code for vulnerabilities in ways that > you could not if all you had was the binaries. But open source should have fixed versions, if possible. Look at C compilers. I need a K&R C compiler for say 8088 build. I might not want the latest C standard. What version has the fewest bugs. --===============1678104538310868435==-- From tony@tonyjones.com Mon Feb 3 22:28:29 2025 From: Tony Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 14:28:12 -0800 Message-ID: In-Reply-To: <6cf34fa6-8bcd-4534-838e-0d190f45a4ae@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9120558260515699353==" --===============9120558260515699353== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2025 at 2:08=E2=80=AFPM ben via cctalk wrote: > > But open source should have fixed versions, if possible. > I'm not really sure what this means. Most open source projects have defined release versions. I might not want the latest C standard. > For gcc this is what --std is for. Though I'm not sure it can be forced to only accept K&R. What version has the fewest bugs. > Proprietary info for most closed source code, no? --===============9120558260515699353==-- From aperry@snowmoose.com Mon Feb 3 22:46:22 2025 From: Alan Perry To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 14:39:51 -0800 Message-ID: In-Reply-To: <6cf34fa6-8bcd-4534-838e-0d190f45a4ae@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1936906730647318489==" --===============1936906730647318489== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2025, at 14:09, ben via cctalk wrote: >=20 > =EF=BB=BF> > > At the root of Open Source is you, the user, have the right to the source= code. >=20 Open Source projects these days have short release cycles and are often aband= oned for the new hotness. Part of my day job is supporting products that were developed years ago and a= re still selling and are being updated now because a component in it has been= EOL=E2=80=99ed and replaced with a part the old kernel can=E2=80=99t handle.= When I worked at Sun, code of this age was still supported. However for the = open source software used in this product even the upstream repos and SDK tar= balls are nowhere to be found on the internet. alan --===============1936906730647318489==-- From cclist@sydex.com Mon Feb 3 22:53:00 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 22:52:51 +0000 Message-ID: In-Reply-To: <86A47B04-01D5-4322-8FC5-F7662EA84F57@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5478864975716262883==" --===============5478864975716262883== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/3/25 13:14, Paul Koning wrote: >=20 >=20 >> On Feb 3, 2025, at 4:08=E2=80=AFPM, Chuck Guzis via cctalk wrote: >> >> On 2/3/25 12:51, Wayne S via cctalk wrote: >>> If safety is of paramount importance, a supplied object or executable sho= uld never be used. That=E2=80=99s just common sense. >>> >>> Sent from my iPhone >> >> Seems to be a cognitive disconnect, here. >=20 > There is something there, though. If you use a binary supplied by a packag= er you have to worry not just about the bugs in the original open source proj= ect, but also about bugs added by patches created by the packager. There is = a notorious example of one of the Linux distributions (Debian?) inserting a f= atal security bug into openSSL. The original was right, but someone made a pa= tch that clearly demonstrated an utter lack of clue. You miss my tongue-in-cheek observation. iPhone software isn't, to bhe best of my knowledge, open-source. How does one know or determine that there's not malware in vendor-supplied software? --Chuck --===============5478864975716262883==-- From spc@conman.org Mon Feb 3 22:56:58 2025 From: Sean Conner To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 17:32:56 -0500 Message-ID: <20250203223256.GB8796@brevard.conman.org> In-Reply-To: <6cf34fa6-8bcd-4534-838e-0d190f45a4ae@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0741840649595240217==" --===============0741840649595240217== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It was thus said that the Great ben via cctalk once stated: > > > > At the root of Open Source is you, the user, have the right to the > source code. > > > > In the early days, that's as far as it went but especially after the > > Morris Worm, security became very important, Open Source afforded > > users the ability to inspect the code for vulnerabilities in ways that > > you could not if all you had was the binaries. > > But open source should have fixed versions, if possible. > Look at C compilers. I need a K&R C compiler for say 8088 build. > I might not want the latest C standard. > What version has the fewest bugs. You will have to evaluate the C compiler in question. The C Standard covers not only the C language, but of a library as well, so your concerns about bugs applies to both the compiler and the library that comes with it. And it's not like there's just one C compiler everybody uses. While a C99 compiler will work with K&R style code, and may very well generate better code, there may still be issues because newer C compilers take advantage of undefined behavior to optimize the code, to the degree that once valid C code now exhibits bugs. For instance, this fragment of code: /* a and b are signed integers */ if (a + b < a) /* check for overflow */ handle_it(); may very well be removed because signed overflow in C is undefined, and by definition (per the compiler writers) a programmer will never intentionally invoke undefined bahavior, the code can be removed because it will never be true (and this is current behavior! Really!). So it could be that C99 will work for you, it might not. A C89-only compiler will work---it'll still accept K&R style code, and it will be old enough to avoid the "exploit undefined behavior for better benchmarks" compilers we have today. Or find an old K&R C compiler. They still exist, but generate very bad code. -spc --===============0741840649595240217==-- From bfranchuk@jetnet.ab.ca Mon Feb 3 23:47:28 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 16:47:19 -0700 Message-ID: <23cc519d-6c74-4701-8889-a59922bfef21@jetnet.ab.ca> In-Reply-To: <20250203223256.GB8796@brevard.conman.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5627176887894219366==" --===============5627176887894219366== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-03 3:32 p.m., Sean Conner via cctalk wrote: > It was thus said that the Great ben via cctalk once stated: >>> >>> At the root of Open Source is you, the user, have the right to the >> source code. >>> >>> In the early days, that's as far as it went but especially after the >>> Morris Worm, security became very important, Open Source afforded >>> users the ability to inspect the code for vulnerabilities in ways that >>> you could not if all you had was the binaries. >> >> But open source should have fixed versions, if possible. >> Look at C compilers. I need a K&R C compiler for say 8088 build. >> I might not want the latest C standard. >> What version has the fewest bugs. > > You will have to evaluate the C compiler in question. The C Standard > covers not only the C language, but of a library as well, so your concerns > about bugs applies to both the compiler and the library that comes with it. > And it's not like there's just one C compiler everybody uses. > > While a C99 compiler will work with K&R style code, and may very well > generate better code, there may still be issues because newer C compilers > take advantage of undefined behavior to optimize the code, to the degree > that once valid C code now exhibits bugs. For instance, this fragment of > code: > > /* a and b are signed integers */ > if (a + b < a) /* check for overflow */ > handle_it(); > > may very well be removed because signed overflow in C is undefined, and by > definition (per the compiler writers) a programmer will never intentionally > invoke undefined bahavior, the code can be removed because it will never be > true (and this is current behavior! Really!). > > So it could be that C99 will work for you, it might not. A C89-only > compiler will work---it'll still accept K&R style code, and it will be old > enough to avoid the "exploit undefined behavior for better benchmarks" > compilers we have today. Or find an old K&R C compiler. They still exist, > but generate very bad code. > > -spc So where does on find a older version, on a current Linux build. we don't support it!!! We only port the latest intel CPU. You have 32 bit compilers, or bigger. I might want a 16 bit compiler under Linux. I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler and the 6809 code generator, but NO they had to rewrite it just for the 386. Open source is popular because it was free. No compiler generates bad code,just some hardware was never meant to have stack based addressing, like the 6502 or the 8088/8086. Look at the mess that small C has for 8088/8086 code gen. Self hosting never seems to be important for C compiler on a small machine. --===============5627176887894219366==-- From bfranchuk@jetnet.ab.ca Mon Feb 3 23:54:56 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 16:54:47 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2375766223444019070==" --===============2375766223444019070== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-03 3:52 p.m., Chuck Guzis via cctalk wrote: > You miss my tongue-in-cheek observation. iPhone software isn't, to bhe > best of my knowledge, open-source. How does one know or determine that > there's not malware in vendor-supplied software? > I use a LAND LINE, I know the phone works. I need it top secret I have shoe phone. > --Chuck It is not malware, but good marketing to have to upgrade on every release. Ben. PS. is me or just the internet browsing getting so full of ads and questionable redirects that on can't use it any more. --===============2375766223444019070==-- From cclist@sydex.com Tue Feb 4 00:07:25 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 00:06:57 +0000 Message-ID: <1b5a1080-ee6c-428c-b5a5-099e1da760cc@sydex.com> In-Reply-To: <23cc519d-6c74-4701-8889-a59922bfef21@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1670052414470562354==" --===============1670052414470562354== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/3/25 15:47, ben via cctalk wrote: > No compiler generates bad code,just some hardware was never meant to > have stack based addressing, like the 6502 or the 8088/8086. Really? The x86 family does indeed have stack-based addressing. In particular, The BP register holds the base of the stack frame and the assumed segment is SS. Even the lowly 8085 has some (undocumented) nod toward stack addressing. --Chuck --===============1670052414470562354==-- From spc@conman.org Tue Feb 4 00:37:07 2025 From: Sean Conner To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 19:37:01 -0500 Message-ID: <20250204003701.GC8796@brevard.conman.org> In-Reply-To: <23cc519d-6c74-4701-8889-a59922bfef21@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0914492689904859792==" --===============0914492689904859792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit It was thus said that the Great ben via cctalk once stated: > On 2025-02-03 3:32 p.m., Sean Conner via cctalk wrote: > > > > So it could be that C99 will work for you, it might not. A C89-only > >compiler will work---it'll still accept K&R style code, and it will be old > >enough to avoid the "exploit undefined behavior for better benchmarks" > >compilers we have today. Or find an old K&R C compiler. They still exist, > >but generate very bad code. > > > > -spc > > So where does on find a older version, on a current Linux build. > we don't support it!!! We only port the latest intel CPU. > > You have 32 bit compilers, or bigger. I might want a 16 bit compiler > under Linux. Do you mean you want a compiler to generate 16-bit code? Or be compiled as a 16-bit program to run under Linux? If the later, it's not supported, or at least, not supported by default [1]. > I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler > and the 6809 code generator, but NO they had to rewrite it just for the > 386. It took me only a few minutes to find it. There's the GIT repository at https://github.com/lkundrak/dev86 Yes, it requires git to initially download it, but it's available. And it *still* has 6809 code generation. The code seems to be originally written for Unix anyway, or at least it appears so from the initial importation into git [2]: /* bcc.c - driver for Bruce's C compiler (bcc) and for CvW's C compiler */ /* Copyright (C) 1992 Bruce Evans */ #define _POSIX_SOURCE 1 #include #include #include #include #include #include #include The latest version was ported to MS-DOS at some point. I was able to compile the latest version (on a 32-bit Linux system---I no longer have a MS-DOS C compiler so I couldn't test on that), but the code is C89, so in theory, you could use any MS-DOS C compiler post 1989 to compile the code if you so wish. When I did the compile, there compiler did throw up some warning even though none were specified because the code is that old, but I did get an executable: [spc]matrix:~/repo/dev86/bcc>./bcc Usage: ./bcc [-ansi] [-options] [-o output] file [files]. > Open source is popular because it was free. > > No compiler generates bad code,just some hardware was never meant to > have stack based addressing, like the 6502 or the 8088/8086. > Look at the mess that small C has for 8088/8086 code gen. > Self hosting never seems to be important for C compiler on a small machine. The 8086/8088 was never meant to have stack based addressing? Um, the 8086/8088 has an entire register dedicated to that (BP by the way). The limitation with BP is that it's bound to the SS segment by default, and in some memory models that becomes an issue, but to say it doesn't have stack based addressing? Methinks you are misrembering here. And self-hosting a C compiler on a small system isn't easy with 64K of RAM total. The PDP-11 had at least 64K code space and 64K data space to work with. -spc [1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on a 32b x86-based Linux system with a custom program I wrote to run it. I even had to emulate several MS-DOS system calls to get it to work (since I needed input from a Unix program to be piped in, I couldn't use DOSBox for this). [2] Dated July 27, 2002, which is before git existed, but this repository was converted to git at some point. --===============0914492689904859792==-- From paulkoning@comcast.net Tue Feb 4 01:09:26 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 20:09:11 -0500 Message-ID: In-Reply-To: <20250203223256.GB8796@brevard.conman.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4755156186480008612==" --===============4755156186480008612== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 3, 2025, at 5:32=E2=80=AFPM, Sean Conner via cctalk wrote: >=20 > It was thus said that the Great ben via cctalk once stated: >>>=20 >>> At the root of Open Source is you, the user, have the right to the >> source code. >>>=20 >>> In the early days, that's as far as it went but especially after the >>> Morris Worm, security became very important, Open Source afforded >>> users the ability to inspect the code for vulnerabilities in ways that >>> you could not if all you had was the binaries. >>=20 >> But open source should have fixed versions, if possible. >> Look at C compilers. I need a K&R C compiler for say 8088 build. >> I might not want the latest C standard. >> What version has the fewest bugs. >=20 > You will have to evaluate the C compiler in question. The C Standard > covers not only the C language, but of a library as well, so your concerns > about bugs applies to both the compiler and the library that comes with it. > And it's not like there's just one C compiler everybody uses. >=20 > While a C99 compiler will work with K&R style code, and may very well > generate better code, there may still be issues because newer C compilers > take advantage of undefined behavior to optimize the code, to the degree > that once valid C code now exhibits bugs. For instance, this fragment of > code: >=20 > /* a and b are signed integers */ > if (a + b < a) /* check for overflow */ > handle_it(); >=20 > may very well be removed because signed overflow in C is undefined, and by > definition (per the compiler writers) a programmer will never intentionally > invoke undefined bahavior, the code can be removed because it will never be > true (and this is current behavior! Really!). In a great many cases, this isn't "code that once was valid C" but rather cod= e that always was invalid but in ways that old compilers did not catch or tak= e advantage of in optimization. There probably are some exceptions, given th= e evolving standards. There are various compiler warning options that are helpful for dealing with = these errors, so you're told that there's something wrong rather than the com= piler just silently doing things you probably didn't expect. I remember gett= ing a lot of benefit out of the GCC warnings about pointer aliasing -- the ru= le that T1 * and T2 * where T1 and T2 are different types won't point to the = same memory location. paul --===============4755156186480008612==-- From bfranchuk@jetnet.ab.ca Tue Feb 4 01:43:38 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 18:43:31 -0700 Message-ID: <9460dece-c8e1-47e9-8efd-a06b34eb921b@jetnet.ab.ca> In-Reply-To: <1b5a1080-ee6c-428c-b5a5-099e1da760cc@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5093009583818770102==" --===============5093009583818770102== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-03 5:06 p.m., Chuck Guzis via cctalk wrote: > On 2/3/25 15:47, ben via cctalk wrote: >> No compiler generates bad code,just some hardware was never meant to >> have stack based addressing, like the 6502 or the 8088/8086. > > Really? The x86 family does indeed have stack-based addressing. In > particular, The BP register holds the base of the stack frame and the > assumed segment is SS. Even the lowly 8085 has some (undocumented) nod > toward stack addressing. I don't like to have to play around with, DS and SS and that index register mess. The 6809 or the PDP-11 makes for easy indexing. > --Chuck Was the X86 family meant for pascal type languages? Other than the small model, every thing is a hack. --===============5093009583818770102==-- From cisin@xenosoft.com Tue Feb 4 01:57:01 2025 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 17:56:48 -0800 Message-ID: In-Reply-To: <9460dece-c8e1-47e9-8efd-a06b34eb921b@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4428873172185894536==" --===============4428873172185894536== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > On 2025-02-03 5:06 p.m., Chuck Guzis via cctalk wrote: >> Really? The x86 family does indeed have stack-based addressing. In >> particular, The BP register holds the base of the stack frame and the >> assumed segment is SS. Even the lowly 8085 has some (undocumented) nod >> toward stack addressing. On Mon, 3 Feb 2025, ben via cctalk wrote: > I don't like to have to play around with, DS and SS > and that index register mess. The 6809 or the PDP-11 makes > for easy indexing. > Was the X86 family meant for pascal type languages? > Other than the small model, every thing is a hack. It was generally agreed on many of the new features needed. Motorola abandoned their previous code base, and designed the 68000. Intel realized that they could "get away with" just adding patches and kluges. Yes, a "flat" memory model is simpler. For getting started, you can set CS, DS, ES. and SS to the same; org your program at 100h. --===============4428873172185894536==-- From bfranchuk@jetnet.ab.ca Tue Feb 4 02:05:30 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 19:05:20 -0700 Message-ID: <5da86e25-28e7-45f4-85c3-9034fd506a3e@jetnet.ab.ca> In-Reply-To: <20250204003701.GC8796@brevard.conman.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2141885011265907968==" --===============2141885011265907968== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-03 5:37 p.m., Sean Conner via cctalk wrote: > Do you mean you want a compiler to generate 16-bit code? Or be compiled > as a 16-bit program to run under Linux? If the later, it's not supported, > or at least, not supported by default [1]. >=20 >> I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler >> and the 6809 code generator, but NO they had to rewrite it just for the >> 386. >=20 > It took me only a few minutes to find it. There's the GIT repository at > =09 > https://github.com/lkundrak/dev86 >=20 > When I did the compile, there compiler did throw up some warning even > though none were specified because the code is that old, but I did get an > executable: >=20 > [spc]matrix:~/repo/dev86/bcc>./bcc > Usage: ./bcc [-ansi] [-options] [-o output] file [files]. >=20 I think back then the code was 16 bit rather than 32 bit for the C=20 compiler. >> Open source is popular because it was free. >> >> No compiler generates bad code,just some hardware was never meant to >> have stack based addressing, like the 6502 or the 8088/8086. >> Look at the mess that small C has for 8088/8086 code gen. >> Self hosting never seems to be important for C compiler on a small machine. >=20 > The 8086/8088 was never meant to have stack based addressing? Um, the > 8086/8088 has an entire register dedicated to that (BP by the way). The > limitation with BP is that it's bound to the SS segment by default, and in > some memory models that becomes an issue, but to say it doesn't have stack > based addressing? Methinks you are misrembering here. >=20 The PDP-11 and 6809 has the S+,-S the X86 is missing. POP BX; ADD AX BX compared to ADDD S++ for the 6809. > And self-hosting a C compiler on a small system isn't easy with 64K of R= AM > total. The PDP-11 had at least 64K code space and 64K data space to work > with. >=20 That is true. The C compiler for the 6809 fit in a 64K memory space=20 under OS9. > -spc >=20 > [1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on a > 32b x86-based Linux system with a custom program I wrote to run it. > I even had to emulate several MS-DOS system calls to get it to work > (since I needed input from a Unix program to be piped in, I couldn't > use DOSBox for this). >=20 > [2] Dated July 27, 2002, which is before git existed, but this > repository was converted to git at some point. --===============2141885011265907968==-- From spectre@floodgap.com Tue Feb 4 02:06:40 2025 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 18:06:30 -0800 Message-ID: <77a5c4e1-cd6f-4b66-b2b4-a0279a319bd0@floodgap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2537680119568238607==" --===============2537680119568238607== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> DEC did something similar with the Pro, except they used a DA-15 connector >> to carry video (monochrome as well as RGB), keyboard data (4800 bps UART) >> and 12 volt power. >> > DEC Rainbow too... And it's easy to short power to another line and take > out the line drivers in the keyboard... Pretty sure the Pro as well (at least, I don't need to run any power to the V= R201). --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Watch your mouth, kid, or you'll find yourself floating home. -- Han Solo = -- --===============2537680119568238607==-- From imp@bsdimp.com Tue Feb 4 02:50:29 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 03 Feb 2025 19:50:07 -0700 Message-ID: In-Reply-To: <20250204003701.GC8796@brevard.conman.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9118340769711684839==" --===============9118340769711684839== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2025, 5:37=E2=80=AFPM Sean Conner via cctalk wrote: > It was thus said that the Great ben via cctalk once stated: > > On 2025-02-03 3:32 p.m., Sean Conner via cctalk wrote: > > > > > > So it could be that C99 will work for you, it might not. A C89-only > > >compiler will work---it'll still accept K&R style code, and it will be > old > > >enough to avoid the "exploit undefined behavior for better benchmarks" > > >compilers we have today. Or find an old K&R C compiler. They still > exist, > > >but generate very bad code. > > > > > > -spc > > > > So where does on find a older version, on a current Linux build. > > we don't support it!!! We only port the latest intel CPU. > > > > You have 32 bit compilers, or bigger. I might want a 16 bit compiler > > under Linux. > > Do you mean you want a compiler to generate 16-bit code? Or be compiled > as a 16-bit program to run under Linux? If the later, it's not supported, > or at least, not supported by default [1]. > I have Vexix86 emulator that does much the same thing. > I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler > > and the 6809 code generator, but NO they had to rewrite it just for the > > 386. > > It took me only a few minutes to find it. There's the GIT repository at > > https://github.com/lkundrak/dev86 > > Yes, it requires git to initially download it, but it's available. And it > *still* has 6809 code generation. The code seems to be originally written > for Unix anyway, or at least it appears so from the initial importation > into > git [2]: > Bcc was written by Bruce Evans to have a compiler for 386BSD for the boot loader (among other reasons). It dates back to the late 80s or so. It's one of the reasons we in FreeBSD held onto K&R constructs in certain areas of the tree for so long. Well after gcc / binutils could generate the small bits of 16bit code the loader eventually required.. Warner /* bcc.c - driver for Bruce's C compiler (bcc) and for CvW's C > compiler */ > > /* Copyright (C) 1992 Bruce Evans */ > > #define _POSIX_SOURCE 1 > > #include > #include > #include > #include > #include > #include > #include > > The latest version was ported to MS-DOS at some point. I was able to > compile the latest version (on a 32-bit Linux system---I no longer have a > MS-DOS C compiler so I couldn't test on that), but the code is C89, so in > theory, you could use any MS-DOS C compiler post 1989 to compile the code > if > you so wish. > > When I did the compile, there compiler did throw up some warning even > though none were specified because the code is that old, but I did get an > executable: > > [spc]matrix:~/repo/dev86/bcc>./bcc > Usage: ./bcc [-ansi] [-options] [-o output] file [files]. > > > Open source is popular because it was free. > > > > No compiler generates bad code,just some hardware was never meant to > > have stack based addressing, like the 6502 or the 8088/8086. > > Look at the mess that small C has for 8088/8086 code gen. > > Self hosting never seems to be important for C compiler on a small > machine. > > The 8086/8088 was never meant to have stack based addressing? Um, the > 8086/8088 has an entire register dedicated to that (BP by the way). The > limitation with BP is that it's bound to the SS segment by default, and in > some memory models that becomes an issue, but to say it doesn't have stack > based addressing? Methinks you are misrembering here. > > And self-hosting a C compiler on a small system isn't easy with 64K of > RAM > total. The PDP-11 had at least 64K code space and 64K data space to work > with. > > -spc > > [1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on a > 32b x86-based Linux system with a custom program I wrote to run > it. > I even had to emulate several MS-DOS system calls to get it to work > (since I needed input from a Unix program to be piped in, I > couldn't > use DOSBox for this). > > [2] Dated July 27, 2002, which is before git existed, but this > repository was converted to git at some point. > --===============9118340769711684839==-- From imp@bsdimp.com Tue Feb 4 02:57:28 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Mon, 03 Feb 2025 19:57:09 -0700 Message-ID: In-Reply-To: <77a5c4e1-cd6f-4b66-b2b4-a0279a319bd0@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4897275559289995791==" --===============4897275559289995791== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, Feb 3, 2025, 7:06 PM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org> wrote: > > >> DEC did something similar with the Pro, except they used a DA-15 > connector > >> to carry video (monochrome as well as RGB), keyboard data (4800 bps > UART) > >> and 12 volt power. > >> > > DEC Rainbow too... And it's easy to short power to another line and take > > out the line drivers in the keyboard... > > Pretty sure the Pro as well (at least, I don't need to run any power to > the VR201). > Yes. And VT240 too. Warner -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckaiser(a)floodgap.com > -- Watch your mouth, kid, or you'll find yourself floating home. -- Han > Solo -- > > --===============4897275559289995791==-- From cclist@sydex.com Tue Feb 4 03:28:20 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 03:28:10 +0000 Message-ID: <2512382a-f520-456f-94d3-5fe22fddd140@sydex.com> In-Reply-To: <9460dece-c8e1-47e9-8efd-a06b34eb921b@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7912004474519189891==" --===============7912004474519189891== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/3/25 17:43, ben via cctalk wrote: > On 2025-02-03 5:06 p.m., Chuck Guzis via cctalk wrote: >> On 2/3/25 15:47, ben via cctalk wrote: >>> No compiler generates bad code,just some hardware was never meant to >>> have stack based addressing, like the 6502 or the 8088/8086. >> >> Really?  The x86 family does indeed have stack-based addressing.  In >> particular, The BP register holds the base of the stack frame and the >> assumed segment is SS.   Even the lowly 8085 has some (undocumented) nod >> toward stack addressing. > > Was the X86 family meant for pascal type languages? > Other than the small model, every thing is a hack. I get the feeling that you haven't done much x86 programming. Look at some real code where arguments are pushed on the stack before a call, local storage is allocated (stack frame) by setting BP, and addressing of any member of the stack can be accomplished with {BP+displacement] addressing. If DS and CS are different, you can address 128KB without issues (why would one want to change the executable code? If you want a private stack area, set SS to something different. To push the point a bit further, one need not have explicit stack hardware if a generous enough register file is provided and register-displacement addressing is implemented. Witness, for example, IBM 370. --Chuck --===============7912004474519189891==-- From lewissa78@gmail.com Tue Feb 4 05:40:29 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Mon, 03 Feb 2025 23:40:11 -0600 Message-ID: In-Reply-To: <093801db765a$679cb8e0$36d62aa0$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3779455575661424093==" --===============3779455575661424093== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit That's a good point about the case-insensitive convention of Windows - yeah, I appreciate that aspect as well. My favorite experience with Microsoft was Windows XP and the included "Internet Backgammon." I'd come home, launch that, and get paired up with a random person within minutes. No chat, but you could "feel" how it was another person making their game-play choices (there was a very limited pre-selected chat option, taunts like "Better luck next time" and such). No popup ads. And it was a good rendition of Backgammon. As for the 32-bit to 64-bit transition- well, emulating a Win3.X, 9X, or XP 32-bit is fairly easy today. But if you mean a legacy device no longer functioned, yeah, devices under emulators is a hit or miss. But I think a lot of people overlook the "thunking' wizardry that Microsoft did to fairly seamlessly support both 32- and 64-bit runtimes (that WoW Windows on Windows subsystem stuff). Remember you can still CTRL-ALT-DEL, do Task Manager, and in the list of processes look for that "(32 bit)" after the name to see what is still actually a 32-bit app. It's sort of like lingering FastEthernet (100Mbit) nodes: get that legacy stuff off my system/network :| (I'm actually not really that particular, but it is interesting info). It's more disappointing to me that they dropped 16-bit support (no more InterSvr or QBasic, at least out-of-the-box). BTW main reason I like MS Paint is because of the Transparent Selection option, makes it easy to mosaic pictures together (and the Resize). Quick and simple, doesn't have to load in a ton of other DLLs for other features I won't need. Good for draft things, then CS6 for heavier stuff. -Steve On Mon, Feb 3, 2025 at 10:41 AM William Sudbrink via cctalk < cctalk(a)classiccmp.org> wrote: > I'll give Microsoft one thing... > I _HATE_ case sensitive file names. MSDOS/Windows had/has that right. > > Bill S. > > > -- > This email has been checked for viruses by Avast antivirus software. > www.avast.com > --===============3779455575661424093==-- From lewissa78@gmail.com Tue Feb 4 07:34:08 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 01:33:48 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3319893466334838869==" --===============3319893466334838869== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Beyond just the compiler, there are also optimization and other settings (like the multitude levels of C-compliance or how strict to be about warnings, or conditional-builds to tailor it specific situations). Regardless, proper binary deliveries come with CRC checksums. This isn't just to verify that you downloaded the file correctly, but to also help verify that you've used the exact same "Bill of software material" (SBOM), versions of dependencies, and other settings to produce that same binary. The "more safe" isn't necessarily that "millions of anonymous eyes" have scanned the code for mistakes or anything bad. (yes, that can help, but no guarantee it is actively taking place). Rather, IF something does happen, you now have a kind of paper-trail to investigate where things went wrong. A form of accountability (provided you can obtain that source, that compiler version and its runtime support for whatever OS is involved - and produce a build consistent with that CRC). Running a prebuild from RandomPlace.com is always risky (even if things go fine that day, "sleeper code" could park itself somewhere). But for me, it's like buying a used car. Yep, it's a lot of risk on if the prior owner is telling the truth. I just have to use good judgement that the car isn't laced with something, doesn't have a tracker hidden on it, or isn't just about to blow a gasket. Part of that good judgement is looking at other community involvement by said theoretical "RandomPlace.com" and a virus scan - akin to kicking the tires. First adopters can use virtual machines and look for anomalies there, then after that, it's off to posting product reviews. It's odd to me that people cry about environmental harm of crypto, but not a word about all the extra power wasted recompiling from source over and over. Maybe if they just combine the two - that solving a crypto block somehow involved recompiling something :) Can I patent that idea? (in a nutshell, crypto is computing a massive complex-CRC of a ton of transaction info). We're still in the infancy of all this computer-stuff. The hoopla about Rust bugged me and this term "memory safe languages." Syntax sugar altogether bugs me, as I think shoveling ASCII text around in a text-editor is not the ultimate in how software is create. UML failed us for various reasons. I think the step past high level languages is moving into VR, and using virtual constructs to "build" instead of "write" software. In doing so, now you can actively monitor the dependencies between modules (lines between declarations, and a real time memory-model of their arrangement), and decorate AST nodes (floating in 3-space) with optional tags (like exception policy, whose doing range checks on inputs, or how any logging is handled) instead of cluttering up all the core business logic. This system would also allow actively monitoring resource requirements - to answer a question like: this code can run on a RPi Nano with 128MB. Then you add one aspect (or equivalent to a line of code), now suddenly whatever your code is requires an RTX9090 in the system somewhere - so maybe you want to re-think your approach. But maybe I'm wrong and "writing software" will always be necessary. Time will tell. [ imo, UML "failed" because 2D huge plotter size maps of class relationships wasn't really that helpful - it was just a different format of what interface code already told you; and a bunch of class relationships isn't really the meaningful part of a design ] -Steve On Mon, Feb 3, 2025 at 8:58=E2=80=AFPM Warner Losh via cctalk wrote: > On Mon, Feb 3, 2025, 5:37=E2=80=AFPM Sean Conner via cctalk > > wrote: > > > It was thus said that the Great ben via cctalk once stated: > > > On 2025-02-03 3:32 p.m., Sean Conner via cctalk wrote: > > > > > > > > So it could be that C99 will work for you, it might not. A > C89-only > > > >compiler will work---it'll still accept K&R style code, and it will be > > old > > > >enough to avoid the "exploit undefined behavior for better benchmarks" > > > >compilers we have today. Or find an old K&R C compiler. They still > > exist, > > > >but generate very bad code. > > > > > > > > -spc > > > > > > So where does on find a older version, on a current Linux build. > > > we don't support it!!! We only port the latest intel CPU. > > > > > > You have 32 bit compilers, or bigger. I might want a 16 bit compiler > > > under Linux. > > > > Do you mean you want a compiler to generate 16-bit code? Or be > compiled > > as a 16-bit program to run under Linux? If the later, it's not > supported, > > or at least, not supported by default [1]. > > > > I have Vexix86 emulator that does much the same thing. > > > I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler > > > and the 6809 code generator, but NO they had to rewrite it just for the > > > 386. > > > > It took me only a few minutes to find it. There's the GIT repository > at > > > > https://github.com/lkundrak/dev86 > > > > Yes, it requires git to initially download it, but it's available. And > it > > *still* has 6809 code generation. The code seems to be originally > written > > for Unix anyway, or at least it appears so from the initial importation > > into > > git [2]: > > > > Bcc was written by Bruce Evans to have a compiler for 386BSD for the boot > loader (among other reasons). It dates back to the late 80s or so. It's one > of the reasons we in FreeBSD held onto K&R constructs in certain areas of > the tree for so long. Well after gcc / binutils could generate the small > bits of 16bit code the loader eventually required.. > > Warner > > /* bcc.c - driver for Bruce's C compiler (bcc) and for CvW's C > > compiler */ > > > > /* Copyright (C) 1992 Bruce Evans */ > > > > #define _POSIX_SOURCE 1 > > > > #include > > #include > > #include > > #include > > #include > > #include > > #include > > > > The latest version was ported to MS-DOS at some point. I was able to > > compile the latest version (on a 32-bit Linux system---I no longer have a > > MS-DOS C compiler so I couldn't test on that), but the code is C89, so in > > theory, you could use any MS-DOS C compiler post 1989 to compile the code > > if > > you so wish. > > > > When I did the compile, there compiler did throw up some warning even > > though none were specified because the code is that old, but I did get an > > executable: > > > > [spc]matrix:~/repo/dev86/bcc>./bcc > > Usage: ./bcc [-ansi] [-options] [-o output] file [files]. > > > > > Open source is popular because it was free. > > > > > > No compiler generates bad code,just some hardware was never meant to > > > have stack based addressing, like the 6502 or the 8088/8086. > > > Look at the mess that small C has for 8088/8086 code gen. > > > Self hosting never seems to be important for C compiler on a small > > machine. > > > > The 8086/8088 was never meant to have stack based addressing? Um, the > > 8086/8088 has an entire register dedicated to that (BP by the way). The > > limitation with BP is that it's bound to the SS segment by default, and > in > > some memory models that becomes an issue, but to say it doesn't have > stack > > based addressing? Methinks you are misrembering here. > > > > And self-hosting a C compiler on a small system isn't easy with 64K of > > RAM > > total. The PDP-11 had at least 64K code space and 64K data space to work > > with. > > > > -spc > > > > [1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on > a > > 32b x86-based Linux system with a custom program I wrote to run > > it. > > I even had to emulate several MS-DOS system calls to get it to > work > > (since I needed input from a Unix program to be piped in, I > > couldn't > > use DOSBox for this). > > > > [2] Dated July 27, 2002, which is before git existed, but this > > repository was converted to git at some point. > > > --===============3319893466334838869==-- From als@thangorodrim.ch Tue Feb 4 12:20:44 2025 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 13:07:23 +0100 Message-ID: In-Reply-To: =?utf-8?q?=3CBN6PR04MB089975095B45E3AEB85DAB75E4F52=40BN6PR04MB?= =?utf-8?q?0899=2Enamprd04=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3459613597894428350==" --===============3459613597894428350== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 03, 2025 at 09:30:03PM +0000, Wayne S wrote: > Alex, your posts come over with the =E2=80=9Cflag=E2=80=9D set (i get a red= =E2=80=9Cflag=E2=80=9D on my > iphone). Did you mean to flag all your responses for some reason ?=20 Interesting. Do you just get a red flag or is there also some message text displayed? I don't have an iPhone to test and nothing shows up in GMail (nor mutt, for that matter). I'm setting a bunch of custom headers in my mail and the most likely culprit here is this one: X-message-flag: Please send plain text messages only. Thank you. I discovered ~20y ago that with this, one could insert a custom message into the email display of the MS Outlook client and since Outlook users where the canonical offenders for only sending HTML back then, that's what I did. Kind regards, Alex. --=20 "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============3459613597894428350==-- From als@thangorodrim.ch Tue Feb 4 13:05:33 2025 From: Alexander Schreiber To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 13:49:35 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3722352241631772245==" --===============3722352241631772245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, Feb 04, 2025 at 01:33:48AM -0600, Steve Lewis via cctalk wrote: > Beyond just the compiler, there are also optimization and other settings > (like the multitude levels of C-compliance or how strict to be about > warnings, or conditional-builds to tailor it specific situations). > > Regardless, proper binary deliveries come with CRC checksums. This isn't Nitpick: Not CRC checksums, as those are only good to detect gross data corruption (e.g. an entire page/sector being zeroed). The standard these days is proper cryptographic hashes that are still known to be strong (e.g. not MD5, as it is known to be weak and collisions can be generated, but SHA256/SHA512) and the hashes cryptographically signed. > just to verify that you downloaded the file correctly, but to also help > verify that you've used the exact same "Bill of software material" (SBOM), > versions of dependencies, and other settings to produce that same binary. Reproducible builds is an issue by itself and requires careful attention to the build systems. But it should be a base standard. Kind regards, Alex. -- "Opportunity is missed by most people because it is dressed in overalls and looks like work." -- Thomas A. Edison --===============3722352241631772245==-- From dave.g4ugm@gmail.com Tue Feb 4 14:32:19 2025 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 14:32:10 +0000 Message-ID: <82cb7da0-9a0e-4682-bda6-5ae90fc0938c@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1551138182970062842==" --===============1551138182970062842== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 03/02/2025 23:54, ben via cctalk wrote: > On 2025-02-03 3:52 p.m., Chuck Guzis via cctalk wrote: > >> You miss my tongue-in-cheek observation. iPhone software isn't, to bhe >> best of my knowledge, open-source.  How does one know or determine that >> there's not malware in vendor-supplied software? >> > > I use a LAND LINE, I know the phone works. Not available in many locations... > > I need it top secret I have shoe phone. --Chuck > > It is not malware, but good marketing to have to upgrade > on every release. > Ben. > PS. is me or just the internet browsing getting so full of ads > and questionable redirects that on can't use it any more. > I find I need a blocker... Dave --===============1551138182970062842==-- From lproven@gmail.com Tue Feb 4 14:44:42 2025 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Apple & History (Was: Microsoft 50 years) Date: Tue, 04 Feb 2025 15:44:25 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3501469512851980760==" --===============3501469512851980760== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 1 Feb 2025 at 13:58, Joseph S. Barrera III via cctalk wrote: > > Half the time, I hear from my family, "why do you spend all this time > working with obsolete stuff?" > > The other half, I hear, "if you can do it, why can't I? Don't make it Oh that's good. That is almost T-shirt worthy. -- 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 --===============3501469512851980760==-- From lproven@gmail.com Tue Feb 4 15:10:48 2025 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Tue, 04 Feb 2025 16:10:31 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2961029723013361718==" --===============2961029723013361718== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 3 Feb 2025 at 07:02, Steve Lewis via cctalk wrote: > > I might be banished for saying - but, I actually like Microsoft. It's refreshing to hear that. I don't like the company, I am not wild about the modern products, its criminal record is shameful... but it has done some fantastic products over the years, some of which re-defined the industry. > What Microsoft did to DR (Digital Research) and Stacker was a bit cold > (making Windows difficult to use with DR-DOS in the 90's, and basically > straight up theft of Stacker's tech). Allegedly Microsoft also > deliberately made Net"Scrape" slower than their own IE.. In early 90s, I > did switch from MS-DOS to DR-DOS because at the time, DR-DOS did just have > better features (like the 4DOS features/command line scroll back, tab to > complete, stuff like that). Agreed, and me too. > I've tried Linux a number of times over the years - > it's terrific for a headless file server or maybe a router, but otherwise, > No Thanks.... If you really learn Windows, there are so many short-cut > keys, I'm still rarely touching the mouse. I am a Linux professional these days and work with it all the time. The keyboard UI is so vastly inferior it's not even funny. Windows rules the world in keyboard UI, and this extends to support for people with disabilities, such as blind and partially sighted users, people with motor problems preventing use of pointing devices, etc. Linux -- *all* the GUIs -- is so bad at this it is _shameful_. But then I also prefer DOS and NT CMD to any xNix shell I've ever seen. Coming up on 40 years of xNix use now and I still hate the shell. -- 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 --===============2961029723013361718==-- From classiccmp@fjl.co.uk Tue Feb 4 15:58:00 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Microsoft 50 years Date: Tue, 04 Feb 2025 15:57:49 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3405918189291640134==" --===============3405918189291640134== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 04/02/2025 15:10, Liam Proven via cctalk wrote: > On Mon, 3 Feb 2025 at 07:02, Steve Lewis via cctalk > wrote: >> I might be banished for saying - but, I actually like Microsoft. > It's refreshing to hear that. > > I don't like the company, I am not wild about the modern products, its > criminal record is shameful... but it has done some fantastic products > over the years, some of which re-defined the industry. > >> What Microsoft did to DR (Digital Research) and Stacker was a bit cold >> (making Windows difficult to use with DR-DOS in the 90's, and basically >> straight up theft of Stacker's tech). Allegedly Microsoft also >> deliberately made Net"Scrape" slower than their own IE.. In early 90s, I >> did switch from MS-DOS to DR-DOS because at the time, DR-DOS did just have >> better features (like the 4DOS features/command line scroll back, tab to >> complete, stuff like that). > Agreed, and me too. > >> I've tried Linux a number of times over the years - >> it's terrific for a headless file server or maybe a router, but otherwise, >> No Thanks.... If you really learn Windows, there are so many short-cut >> keys, I'm still rarely touching the mouse. > I am a Linux professional these days and work with it all the time. > > The keyboard UI is so vastly inferior it's not even funny. Windows > rules the world in keyboard UI, and this extends to support for people > with disabilities, such as blind and partially sighted users, people > with motor problems preventing use of pointing devices, etc. > > Linux -- *all* the GUIs -- is so bad at this it is _shameful_. > > But then I also prefer DOS and NT CMD to any xNix shell I've ever > seen. Coming up on 40 years of xNix use now and I still hate the > shell. As a matter of social history, in the 1970s and into the 1980s Microsoft was heroic. IBM and the corporate data processing department had a stranglehold, and Microsoft (+CP/M) represented freedom. And Microsoft's version of everything tended to be the best. It fell apart with some people when they licensed PC-DOS to IBM, and the world got a PC that wasn't the big leap forward from CP/M that people were hoping for. The cool kids were running on a 68000 by then, which Microsoft largely ignored. I felt OS/2 showed Microsoft understood, but was following the money, which I guessed was okay. Bill Gates also got one over on IBM by enabling the PC clone market - providing multi-sourced standardised platform that exploded the world of Personal Computers. This is overlooked too often. As Intel CPUs improved (possibly dragged forward by AMD) and some good Windows versions (3.11, 98SE and XP) turned up, I felt Microsoft got their shine back. Now Microsoft is doing the stuff IBM was hated for - centralised IT, subscription services and lock-in. The poacher is now the gamekeeper. But as the princess put it, the more Microsoft tightens its grip, the more will slip through its fingers. Regards, Frank. --===============3405918189291640134==-- From lewissa78@gmail.com Tue Feb 4 17:21:22 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 11:21:06 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2218524704622999352==" --===============2218524704622999352== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > > Nitpick: Not CRC checksums, as those are only good to detect gross data Fair, "hash" would be the better term that I meant. On Tue, Feb 4, 2025 at 7:00 AM Alexander Schreiber wrote: > On Tue, Feb 04, 2025 at 01:33:48AM -0600, Steve Lewis via cctalk wrote: > > Beyond just the compiler, there are also optimization and other settings > > (like the multitude levels of C-compliance or how strict to be about > > warnings, or conditional-builds to tailor it specific situations). > > > > Regardless, proper binary deliveries come with CRC checksums. This isn't > > Nitpick: Not CRC checksums, as those are only good to detect gross data > corruption (e.g. an entire page/sector being zeroed). The standard these > days is proper cryptographic hashes that are still known to be strong > (e.g. not MD5, as it is known to be weak and collisions can be generated, > but SHA256/SHA512) and the hashes cryptographically signed. > > > just to verify that you downloaded the file correctly, but to also help > > verify that you've used the exact same "Bill of software material" > (SBOM), > > versions of dependencies, and other settings to produce that same binary. > > Reproducible builds is an issue by itself and requires careful attention > to the build systems. But it should be a base standard. > > Kind regards, > Alex. > -- > "Opportunity is missed by most people because it is dressed in overalls and > looks like work." -- Thomas A. Edison > --===============2218524704622999352==-- From wayne.sudol@hotmail.com Tue Feb 4 18:54:49 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 18:54:40 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0003882077841480478==" --===============0003882077841480478== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Re: flag. I just get a red flag 🚩 as a high priority alert. Sent from my iPhone > On Feb 4, 2025, at 04:15, Alexander Schreiber wrote: > > for --===============0003882077841480478==-- From milovelimirovic@gmail.com Tue Feb 4 19:10:12 2025 From: Milo =?utf-8?q?Velimirovi=C4=87?= To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Tue, 04 Feb 2025 13:09:54 -0600 Message-ID: <11658D05-42F9-4F9D-96FC-3C251D5245DF@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5505706326485022784==" --===============5505706326485022784== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 4, 2025, at 6:49=E2=80=AFAM, Alexander Schreiber via cctalk wrote: >=20 > On Tue, Feb 04, 2025 at 01:33:48AM -0600, Steve Lewis via cctalk wrote: >> Beyond just the compiler, there are also optimization and other settings >> (like the multitude levels of C-compliance or how strict to be about >> warnings, or conditional-builds to tailor it specific situations). >>=20 >> Regardless, proper binary deliveries come with CRC checksums. This isn't >=20 > Nitpick: Not CRC checksums, as those are only good to detect gross data > corruption (e.g. an entire page/sector being zeroed). The standard these > days is proper cryptographic hashes that are still known to be strong > (e.g. not MD5, as it is known to be weak and collisions can be generated, > but SHA256/SHA512) and the hashes cryptographically signed. Further nitpick. A CRC can do more than detect =E2=80=9Conly . . . gross data= corruption.=E2=80=9D A properly designed CRC polynomial of length n should detect all errors in a message block from a single-bit to a burst that is n bits long. A CRC would be computed for each block of a message as opposed to a crypto- graphic hash which is usually computed over the entire message. =E2=80=94Milo --===============5505706326485022784==-- From n5rvzsama@gmail.com Fri Feb 7 06:30:10 2025 From: Tony White To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for IBM 2723 Date: Fri, 07 Feb 2025 00:23:48 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6775419633522590164==" --===============6775419633522590164== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit You can use a 2838 card instead of the 2723. --===============6775419633522590164==-- From wh.sudbrink@verizon.net Fri Feb 7 16:42:59 2025 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Use (abuse?) of a 7924 in a +24 PS... Date: Fri, 07 Feb 2025 11:42:08 -0500 Message-ID: <0af701db797f$3b53b270$b1fb1750$@verizon.net> In-Reply-To: <0af701db797f$3b53b270$b1fb1750$.ref@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7877485765026227279==" --===============7877485765026227279== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I'm repairing/restoring a later model MITS 8 inch floppy drive. I can not seem to find schematics for it. It is the same as Bill Degnan has here: https://vintagecomputer.net/MITS/88-DCDD/ You can see in his photos (and mine match) that the _plus_ 24 volt DC supply on the board uses a 7924 (note the 9. negative) voltage regulator, with a small heat sink, directly on the circuit board. Along with a couple of 7805s, there is a .Motorola 2n6045 screwed to the large black heat sink. All three of the devices drop into sockets on the circuit board to allow the heat sink to be easily installed/removed. On my unit, the socket for the 2n6045 was burnt to a crisp. I have replace the socket, the 2n6045, the 7924 and the electrolytic caps. When I test the +24 volt rail with a dummy load, it measures +41 volts. I don't understand this circuit. I know MITS was notorious for its power supplies. Does anyone have the schematics for this version of the 8 inch floppy? Any suggestions? Thanks, Bill S. -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============7877485765026227279==-- From ard.p850ug1@gmail.com Fri Feb 7 17:18:24 2025 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Use (abuse?) of a 7924 in a +24 PS... Date: Fri, 07 Feb 2025 17:18:05 +0000 Message-ID: In-Reply-To: <0af701db797f$3b53b270$b1fb1750$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0073138838531062799==" --===============0073138838531062799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Feb 7, 2025 at 5:08 PM William Sudbrink via cctalk wrote: > > I'm repairing/restoring a later model MITS 8 inch floppy drive. I can not > seem to find schematics for it. It is Is it simple enough to trace out the schematic? > > the same as Bill Degnan has here: > > > > https://vintagecomputer.net/MITS/88-DCDD/ > > > > You can see in his photos (and mine match) that the _plus_ 24 volt DC supply > on the board uses a 7924 (note the > > 9. negative) voltage regulator, with a small heat sink, directly on the > circuit board. Along with a couple of 7805s, Remember 'There is no such thing as ground' You can take any point in a circuit as your reference. The so-called positive 3-terminal regulators have the negative terminal common between input and output. The negative regulators have the positive input and output terminals commoned. So if the input to a 7924 comes from a 'floating' supply (neither side of the input supply connected to anything else) it would be fine to connect the output of the regulator to the connection which is commonly regarded as ground, at which point the common terminal of the regulator (and the +ve terminal of the floating supply that feeds it) is +24V. -tony --===============0073138838531062799==-- From ard.p850ug1@gmail.com Fri Feb 7 17:40:52 2025 From: Tony Duell To: cctalk@classiccmp.org Subject: [cctalk] Re: Use (abuse?) of a 7924 in a +24 PS... Date: Fri, 07 Feb 2025 17:40:35 +0000 Message-ID: In-Reply-To: <0af701db797f$3b53b270$b1fb1750$@verizon.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6262076909001841017==" --===============6262076909001841017== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, Feb 7, 2025 at 5:08 PM William Sudbrink via cctalk wrote: > > I'm repairing/restoring a later model MITS 8 inch floppy drive. I can not > seem to find schematics for it. It is > > the same as Bill Degnan has here: > > > > https://vintagecomputer.net/MITS/88-DCDD/ > > > > You can see in his photos (and mine match) that the _plus_ 24 volt DC supply > on the board uses a 7924 (note the > > 9. negative) voltage regulator, with a small heat sink, directly on the > circuit board. Along with a couple of 7805s, > > there is a .Motorola 2n6045 screwed to the large black heat sink. All three > of the devices drop into sockets on the > > circuit board to allow the heat sink to be easily installed/removed. On my > unit, the socket for the 2n6045 was burnt > > to a crisp. I have replace the socket, the 2n6045, the 7924 and the > electrolytic caps. When I test the +24 volt rail > > with a dummy load, it measures +41 volts. Page 137 of the MITS manual on that site gives the schematic of a power supply using a 7824 and a PNP darlington power transitor (to inclrease the availabl output current). It runs off a floating supply from the transormer T1. My guess is that using the 7924 in a similar circuit allows the circuit to be turned upside-down and use a more common NPN darlington transistor. Is that what you have? Is the common pin of the regultor firmly connected to the +24 output rail? If not the output wlll go sky-hgh. -tony --===============6262076909001841017==-- From n5rvzsama@gmail.com Fri Feb 7 19:22:13 2025 From: Tony White To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for IBM 2723 Date: Fri, 07 Feb 2025 00:29:58 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5940643980425247108==" --===============5940643980425247108== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit A 2838 card can be used instead of a 2723. keith --===============5940643980425247108==-- From wh.sudbrink@verizon.net Fri Feb 7 21:13:24 2025 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Re: Use (abuse?) of a 7924 in a +24 PS... Date: Fri, 07 Feb 2025 16:12:27 -0500 Message-ID: <0b2001db79a4$fe0ec5a0$fa2c50e0$@verizon.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8864936532410524144==" --===============8864936532410524144== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tony, Thanks for the reply. This is what it looks like to me (I hope this comes ou= t): AC--- + ---------------------------------------------------FD400 +24 | | | | ---------------- |+ left| |right | BR2 C4 2200uf 50V 7924 | |- |center | | | | | B | AC--- - ----------------------E 2n6045 C--------------FD400 common 2n6045 E/B/C are according to the silkscreen. The actual physical pins are: = B-left, C-center, E-right. Left, right, center designations are with the tab up for both devices. As fa= r as I can tell, there are no other components (capacitors, resistors, diodes) involved in the circuit. I'= m measuring a smooth +41 volts at the FD400 connector with some 24volt automotive bulbs as load. In case the above is illegible, Circuit is: AC to bridge rectifier. BR+ goes= straight to FD400 +24. BR- goes to 2n6045 right pin. BR +/- connected with a 2200uf 50V electrolytic cap. 7= 924 left pin goes to BR+. 7924 center pin goes to 2n6045 left pin. 7924 right pin goes to FD400 common.= 2n6045 center pin goes to FD400 common. Maybe I'm not loading it enough? I'm very hesitant to reattach the FD400 unt= il I understand this. By the way, plus and minus five volts are fine. Bill --=20 This email has been checked for viruses by Avast antivirus software. www.avast.com --===============8864936532410524144==-- From wh.sudbrink@verizon.net Fri Feb 7 22:45:55 2025 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Re: Use (abuse?) of a 7924 in a +24 PS... Date: Fri, 07 Feb 2025 17:44:58 -0500 Message-ID: <0b2501db79b1$eb1c6300$c1552900$@verizon.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0029383661508063874==" --===============0029383661508063874== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Looking at this circuit, it occurred to me that 41 volts is about what you wo= uld expect to see if the 2n6045 was just shorted, E to C (center to right). = I checked with the diode tester in my meter and it looked bad. This 2n6045 w= as out of a box of random unused transistors that I've had around forever. I= looked through the box again, and through a couple of other boxes but no luc= k for a 2n6045 or equivalent. I did have a new pack of 2n6043s. The only di= fference I can see is that the 45 is rated for 100V and the 43 is only 60. S= ince the circuit seems to be running at 41, I decided to try a 43. Now I hav= e a nice clean 24 volts. I wondering whether it will go bad under heavy load= , but I think I'm willing to very quickly test the FD400 in it. Will report = results. -----Original Message----- From: William Sudbrink [mailto:wh.sudbrink(a)verizon.net]=20 Sent: Friday, February 07, 2025 4:12 PM To: 'General Discussion: On-Topic and Off-Topic Posts' Cc: 'Tony Duell' Subject: RE: [cctalk] Re: Use (abuse?) of a 7924 in a +24 PS... Hi Tony, Thanks for the reply. This is what it looks like to me (I hope this comes ou= t): AC--- + ---------------------------------------------------FD400 +24 | | | | ---------------- |+ left| |right | BR2 C4 2200uf 50V 7924 | |- |center | | | | | B | AC--- - ----------------------E 2n6045 C--------------FD400 common 2n6045 E/B/C are according to the silkscreen. The actual physical pins are: = B-left, C-center, E-right. Left, right, center designations are with the tab up for both devices. As fa= r as I can tell, there are no other components (capacitors, resistors, diodes= ) involved in the circuit. I'm measuring a smooth +41 volts at the FD400 con= nector with some 24volt automotive bulbs as load. In case the above is illegible, Circuit is: AC to bridge rectifier. BR+ goes= straight to FD400 +24. BR- goes to 2n6045 right pin. BR +/- connected with= a 2200uf 50V electrolytic cap. 7924 left pin goes to BR+. 7924 center pin goes to 2n6045 left pin. 7924 right pin goes to FD400 common.= 2n6045 center pin goes to FD400 common. Maybe I'm not loading it enough? I'm very hesitant to reattach the FD400 unt= il I understand this. By the way, plus and minus five volts are fine. Bill --=20 This email has been checked for viruses by Avast antivirus software. www.avast.com --===============0029383661508063874==-- From lewissa78@gmail.com Sun Feb 9 18:09:08 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] RS232 - parallel modems!? Date: Sun, 09 Feb 2025 12:08:47 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7583172214603756051==" --===============7583172214603756051== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I was about to ask if anyone ever built a "Parallel Modem" - but I searched around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c. 1996) The drivers refer to Win3.1/Win95 era (I'm not seeing where they had DOS support). But I'm still not sure if I'm understanding the product (which I found described here Microcom Parallel Port Modem From a programming perspective, you just set your parallel bits and mash the STROBE pin, right? Then figure some reasonable delay between iterations of doing that. You don't need starts/stop or parity bits. So I get how that is more efficient (but question is, why wasn't it built sooner? I think it's a long answer when you look at the historical build up of modems, and that serial-port based modems were "fast enough" at the time) So.. If you had a slow system that couldn't really take advantage of a ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an older UART) That might be the use-case where this parallel v.fast might help (by being able to "feed the modem" fast enough to actually take advantage of the faster modem speed?) Or is there some other scenario NOTE, in the articled linked above, it does mention that it is only "value added" if you have this parallel-modem on both sides of the connection. (this is because you'll be flow controlled to whatever is the slower device in the connection?) Related but different question: Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 baud-equivalent modem an accelerated-by-enhanced-encoding version of 300 bps? and 9600 likewise an accelerated-by-encoding version of 2400? is 300bps itself some kind of special accelerated-by-encoding? I see 1200 baud was also still sub 3KHz (did any modem protocol go above 3KHz?). Or maybe I need to ask it this way: did 300 baud modems use a more 1:1 translation of the data-word bits into Hz signal over the modem (giving a more "natural" translation rate?) But then beyond that speed, does a modem need to "cache" a few bytes and determine some encoding scheme to then give modems an apparent speed boost? (is that "kind-of" like USB's 8B/10B? (not in implementation, but in the general concept that a different encoding can result in improved data throughput, without actual faster movement of that data?) I guess it gets into the "secret sauce" approaches of how vendors figured out these encoding approaches (v.32bis, etc), and give their product competitive advantages (but only if you could convince enough ISPs to adopt your protocol, by buying your modem device). My daughter made me finally watch Blackberry recently, it's an interesting telling of that story (of a small business selling their tech to USR, and also that they tackled a version of encryption) -Steve --===============7583172214603756051==-- From wrcooke@wrcooke.net Sun Feb 9 19:24:59 2025 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 14:24:44 -0500 Message-ID: <670644902.34120.1739129084186@email.ionos.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8421384123134147061==" --===============8421384123134147061== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Steve, In my opinion that article leaves a LOT to be desired from a technical standp= oint. I think a lot of the stuff he states as facts are misleading at best. I remember when those came out. IIRC they were mostly marketed toward laptop= s without serial ports. But as stated some desktops did use problematic (slo= w) 8250 UARTs which had trouble over 9600bps. > On 02/09/2025 1:08 PM EST Steve Lewis via cctalk = wrote: > > > From a programming perspective, you just set your parallel bits and mash > the STROBE pin, right? Then figure some reasonable delay between > iterations of doing that. You don't need starts/stop or parity bits. So Writing to a UART (e.g. 8250, 16450, etc) is in general faster than writing t= o a parallel port. For the uart, you simply write a byte and you're done. A= s you say, for the parallel port, you write the data, then you have to write = the control port to turn on strobe, then write the control port again to turn= it off, possibly with (short) delays in between. You probably need to read = a status from both to see if the port is ready, but that is similar in both c= ases. Reading is even worse. A "standard" parallel port only had 4(or 5) input bit= s so you had to read at least twice to get a byte. Also, many of the pins we= re open collector (resistor pullups) intended to drive longish external cable= s, so that made the parallel port itself relatively slow. But plenty fast fo= r V34. > > > So.. If you had a slow system that couldn't really take advantage of a > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an > older UART) That might be the use-case where this parallel v.fast might > help (by being able to "feed the modem" fast enough to actually take > advantage of the faster modem speed?) Or is there some other scenario > As hinted at above, it is probably a faster system (cpu wise) that could do t= he best with a parallel modem. Keep in mind, the modem MUST have the equival= ent of a uart built in. But three writes for each byte and probably 3 or 4 r= eads per byte will slow down a slower computer. > NOTE, in the articled linked above, it does mention that it is only "value > added" if you have this parallel-modem on both sides of the connection. > (this is because you'll be flow controlled to whatever is the slower device > in the connection?) > Reading that stuff made me wonder if microcom was paying him. I find that a = wee bit fishy. Anyway. My 1/2 cent worth. Will --===============8421384123134147061==-- From paulkoning@comcast.net Sun Feb 9 19:35:21 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 14:35:00 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0536292782371157680==" --===============0536292782371157680== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 9, 2025, at 1:08=E2=80=AFPM, Steve Lewis via cctalk wrote: >=20 > I was about to ask if anyone ever built a "Parallel Modem" - but I searched > around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c. > 1996) I don't know what "parallel modem" would mean. Can you explain? > ...Related but different question: >=20 > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300 > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is > 300bps itself some kind of special accelerated-by-encoding? I see 1200 > baud was also still sub 3KHz (did any modem protocol go above 3KHz?). >=20 > Or maybe I need to ask it this way: did 300 baud modems use a more 1:1 > translation of the data-word bits into Hz signal over the modem (giving a > more "natural" translation rate?) But then beyond that speed, does a modem > need to "cache" a few bytes and determine some encoding scheme to then give > modems an apparent speed boost? (is that "kind-of" like USB's 8B/10B? > (not in implementation, but in the general concept that a different > encoding can result in improved data throughput, without actual faster > movement of that data?) For the most part the answer is "no". The job of a modem is to carry a digital signal over a wire, at a given speed= and given level of data integrity, and with a given channel bandwidth. When the channel bandwidth in Hz is well above the bit rate in bps, the job i= s easy, an FSK modem can do the job. That's what the first modems looked lik= e (and perhaps even earlier devices used to deal with radio transmission for = Baudot teleprinters, commonly referred to as "tuning units"). When data rates go up and bandwidth doesn't, you need more complex modulation= schemes. Modulating a carrier produces sidebands, so roughly speaking your = baud rate can't exceed half the channel bandwidth. (I'm sure I'm handwaving = a lot here.) You can't do 9600 bps FSK in a voice channel, it won't fit. It= would fit just fine if you have a 40 kHz channel, so it's certainly possible= to do FSK over VHF radio at that speed if you're authorized that much bandwi= dth. So for high speed on a telephone line the exercise becomes "more bits per bau= d" -- not one bit per signal element as you get from FSK or PSK, but two (QPS= K) or 4 (QAM16) or even 8 (QAM256). Note that those hairy modulation schemes= require a pretty clean channel; you're not likely to find them on shortwave = radio systems for that reason. Indeed, doing data transmission over radio is= an entirely separate art with a host of interesting and exotic methods. Som= e of them can reliably send data using transmission weak enough you can't hea= r them if you listen to the signal with an ordinary audio receiver. paul --===============0536292782371157680==-- From lewissa78@gmail.com Sun Feb 9 23:04:45 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 17:04:26 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6343470189899506107==" --===============6343470189899506107== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Interesting stuff. I ran a BBS in the early 1990s - but I never really dug into the technicals of how a modem worked. So, I'll describe a Parallel Modem like this: how the data from your PC is sent/received to/from the modem is independent of how that same data is communicated over the (then) copper phone line. As Will mentioned, if you didn't have a local UART, then you could instead put that hardware on the modem side and let it handle the byte-to-bit translation. But ever since the IBM PC (and really even a few years earlier, as I'm reading about the S-100 serial card of the POLY-88 c. 1976, or the 0.916Hz clocked UART used on late model PDP's), nearly every system had a serial card with a "local UART" (or similar, like the VIA/PIA shift-register some other economy systems used; these shifters can let you kind of "emulate a UART in software" by at least doing the byte-to-bit conversion for you, you just have to bit-twiddle in the start/stop bits yourself). So why add that cost into a modem (of an additional UART that an end-users probably already has), and also: what would you connect it to? If you connect it to a serial port, then you've defeated the whole purpose. Well, a UART itself is basically a parallel device (from the bus lines to the processor - or memory?). So if you built such a thing, it would make sense to connect it to the host systems parallel port. Hence, a parallel-modem is just one that send/receives its byte across a parallel-port connection. There is a cross-over point where the performance of the local system (a combination of its raw CPU speed, memory, and getting data from a hard drive into said memory) isn't suitable - maybe less so on the TX/send side, but moreso on the RX/receive side. The article mentioned is talking 486-era systems. In the early days, a 1MHz CPU system would be "bogged down" on something as "simple" as scrolling the screen. By the time of 486-days, a system would be bogged down by normal multi-tasking (not Win95 style, but maybe OS/2?). But as mentioned, a UART is a mostly "fire and forget" thing - write your byte, it gets packed into start/data/parity/stop sequence (the data probably reversed). But on the receive side, your system has to do something with the data, and do it before the UART FIFO becomes full (or better, before it becomes halfway full). The modem gets that byte, strips off the "extra" bits, reverses the data back, and modulates it on out (at a rate that it-and-whatever-modem-it-has-connected-to has negotiated as an acceptable speed; your serial port might be set to 19200, but that BBS on the other end might be using a 2400 baud modem; hence all that modem-noise during an initial connection as they fight it out, and the BBS-host software might spew a few garbage bytes as it tries to match on its serial connection and asks "can you comprehend me now?" type questions; in the end, your Carrier Detect lights goes on). But, you're right - I'm still not yet rationalizing out how this parallel-connected-modem would help (even if a corporate or classroom scenario, with a room of 50 systems). I do know that "laplink" style parallel cables were said to be faster than null-modem cables in raw data transfer between systems. BTW, every "DB25" connector in the PC world I've seen, it's got 8-pins for data. Even the UserPort in the Commodore world has that - I've not commonly seen 4-data-pin parallel cables? So yes, you could "talk to a modem faster" using a parallel exchange (is it faster because of the 8-data-pins or faster because of not having to deal with the start/parity/stop bits? or both). -Steve On Sun, Feb 9, 2025 at 1:35 PM Paul Koning wrote: > > > > On Feb 9, 2025, at 1:08 PM, Steve Lewis via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > I was about to ask if anyone ever built a "Parallel Modem" - but I > searched > > around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c. > > 1996) > > I don't know what "parallel modem" would mean. Can you explain? > > > ...Related but different question: > > > > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300 > > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is > > 300bps itself some kind of special accelerated-by-encoding? I see 1200 > > baud was also still sub 3KHz (did any modem protocol go above 3KHz?). > > > > Or maybe I need to ask it this way: did 300 baud modems use a more 1:1 > > translation of the data-word bits into Hz signal over the modem (giving a > > more "natural" translation rate?) But then beyond that speed, does a > modem > > need to "cache" a few bytes and determine some encoding scheme to then > give > > modems an apparent speed boost? (is that "kind-of" like USB's 8B/10B? > > (not in implementation, but in the general concept that a different > > encoding can result in improved data throughput, without actual faster > > movement of that data?) > > For the most part the answer is "no". > > The job of a modem is to carry a digital signal over a wire, at a given > speed and given level of data integrity, and with a given channel bandwidth. > > When the channel bandwidth in Hz is well above the bit rate in bps, the > job is easy, an FSK modem can do the job. That's what the first modems > looked like (and perhaps even earlier devices used to deal with radio > transmission for Baudot teleprinters, commonly referred to as "tuning > units"). > > When data rates go up and bandwidth doesn't, you need more complex > modulation schemes. Modulating a carrier produces sidebands, so roughly > speaking your baud rate can't exceed half the channel bandwidth. (I'm sure > I'm handwaving a lot here.) You can't do 9600 bps FSK in a voice channel, > it won't fit. It would fit just fine if you have a 40 kHz channel, so it's > certainly possible to do FSK over VHF radio at that speed if you're > authorized that much bandwidth. > > So for high speed on a telephone line the exercise becomes "more bits per > baud" -- not one bit per signal element as you get from FSK or PSK, but two > (QPSK) or 4 (QAM16) or even 8 (QAM256). Note that those hairy modulation > schemes require a pretty clean channel; you're not likely to find them on > shortwave radio systems for that reason. Indeed, doing data transmission > over radio is an entirely separate art with a host of interesting and > exotic methods. Some of them can reliably send data using transmission > weak enough you can't hear them if you listen to the signal with an > ordinary audio receiver. > > paul > > --===============6343470189899506107==-- From cisin@xenosoft.com Sun Feb 9 23:27:49 2025 From: Fred Cisin To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 15:27:40 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7372908153420418932==" --===============7372908153420418932== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 9 Feb 2025, Steve Lewis via cctalk wrote: > BTW, every "DB25" connector in the PC world I've > seen, it's got 8-pins for data. Even the UserPort in the Commodore world > has that - I've not commonly seen 4-data-pin parallel cables? The stock IBM 5150 parallel port has 8 pins of data. BUT, that's 8 pins of OUTPUT (plus 4 pins of handshake) The "handshake" lines could be used as input, but not the data lines. THAT is why you hear "only 4 pins of data input" BUT, there is a trivial hardware modification that you can make to the IBM 5150 parallel port to make the 8 data pins usable as bi-directional. (Many aftermarket parallel ports doo not need that nodification) The need for that modificaation is WHY you keep hearing that the parallel port only has four bits of input. IFF you make a "Centronics" TO parallel port adapter (36 pin female blue ribbon input to 25 pin DB25 male output with appropriate wiring in the adapter, then it is possible to be able to take a machine that has parallel [Centronics compatible] output, but no serial port, etc. (there did used to be such!) And tell it that it is connected to a printer. The PC would then need to act as a "printer emulator", to take incoming data from the parallel port and save it. I built such 30+ years ago, but I never got the software to be adequate to make it a commercial product. Hardly anybody could even uderstand what or why it was. 'course, you could accomplish the same task with an external parallel to serial printer buffer, and come in through the serial port. -- Grumpy Ol' Fred cisin(a)xenosoft.com --===============7372908153420418932==-- From imp@bsdimp.com Sun Feb 9 23:58:12 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 16:57:43 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3073162264826910782==" --===============3073162264826910782== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 9, 2025, 4:04=E2=80=AFPM Steve Lewis via cctalk wrote: > Interesting stuff. I ran a BBS in the early 1990s - but I never really > dug into the technicals of how a modem worked. > > So, I'll describe a Parallel Modem like this: how the data from your PC > is sent/received to/from the modem is independent of how that same data is > communicated over the (then) copper phone line. > > As Will mentioned, if you didn't have a local UART, then you could instead > put that hardware on the modem side and let it handle the byte-to-bit > translation. But ever since the IBM PC (and really even a few years > earlier, as I'm reading about the S-100 serial card of the POLY-88 c. 1976, > or the 0.916Hz clocked UART used on late model PDP's), nearly every system > had a serial card with a "local UART" (or similar, like the VIA/PIA > shift-register some other economy systems used; these shifters can let you > kind of "emulate a UART in software" by at least doing the byte-to-bit > conversion for you, you just have to bit-twiddle in the start/stop bits > yourself). > > So why add that cost into a modem (of an additional UART that an end-users > probably already has), and also: what would you connect it to? If you > connect it to a serial port, then you've defeated the whole purpose. Well, > a UART itself is basically a parallel device (from the bus lines to the > processor - or memory?). So if you built such a thing, it would make sense > to connect it to the host systems parallel port. Hence, a parallel-modem > is just one that send/receives its byte across a parallel-port connection. > > > There is a cross-over point where the performance of the local system (a > combination of its raw CPU speed, memory, and getting data from a hard > drive into said memory) isn't suitable - maybe less so on the TX/send side, > but moreso on the RX/receive side. The article mentioned is talking > 486-era systems. In the early days, a 1MHz CPU system would be "bogged > down" on something as "simple" as scrolling the screen. By the time of > 486-days, a system would be bogged down by normal multi-tasking (not Win95 > style, but maybe OS/2?). But as mentioned, a UART is a mostly "fire and > forget" thing - write your byte, it gets packed into start/data/parity/stop > sequence (the data probably reversed). But on the receive side, your > system has to do something with the data, and do it before the UART FIFO > becomes full (or better, before it becomes halfway full). > > The modem gets that byte, strips off the "extra" bits, reverses the data > back, and modulates it on out (at a rate that > it-and-whatever-modem-it-has-connected-to has negotiated as an acceptable > speed; your serial port might be set to 19200, but that BBS on the other > end might be using a 2400 baud modem; hence all that modem-noise during an > initial connection as they fight it out, and the BBS-host software might > spew a few garbage bytes as it tries to match on its serial connection and > asks "can you comprehend me now?" type questions; in the end, your Carrier > Detect lights goes on). > > But, you're right - I'm still not yet rationalizing out how this > parallel-connected-modem would help (even if a corporate or classroom > scenario, with a room of 50 systems). I do know that "laplink" style > parallel cables were said to be faster than null-modem cables in raw data > transfer between systems. BTW, every "DB25" connector in the PC world I've > seen, it's got 8-pins for data. Even the UserPort in the Commodore world > has that - I've not commonly seen 4-data-pin parallel cables? So yes, you > could "talk to a modem faster" using a parallel exchange (is it faster > because of the 8-data-pins or faster because of not having to deal with the > start/parity/stop bits? or both). > Not necessarily. Uarts work great for dialup because the fifo handles all the offload from the CPU. Parallel ports are half duplex with terrible async interfaces to get the CPU's attention. Also, the bit banging you need to do is CPU inefficient. While there were layer DMA things, they were all half duplex too. The Parallel Port is great when you are dumping images to the page. Or when you send a request and expect a reply soon. It's not so good for having random characters show up, maybe in the middle of sending data... and the modem would need a buffet which would make latence interesting. After dealing with parallel port zip drives and ethernet drivers (which had the same issues a parallel modem wiuld have had), i love the simplicity of the 16550 UART interface. So possible, but a boatload more driver code and some tricky timing and compat issues. Warner -Steve > > > > > On Sun, Feb 9, 2025 at 1:35=E2=80=AFPM Paul Koning wrote: > > > > > > > > On Feb 9, 2025, at 1:08=E2=80=AFPM, Steve Lewis via cctalk < > > cctalk(a)classiccmp.org> wrote: > > > > > > I was about to ask if anyone ever built a "Parallel Modem" - but I > > searched > > > around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c. > > > 1996) > > > > I don't know what "parallel modem" would mean. Can you explain? > > > > > ...Related but different question: > > > > > > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > > > baud-equivalent modem an accelerated-by-enhanced-encoding version of > 300 > > > bps? and 9600 likewise an accelerated-by-encoding version of 2400? > is > > > 300bps itself some kind of special accelerated-by-encoding? I see > 1200 > > > baud was also still sub 3KHz (did any modem protocol go above 3KHz?). > > > > > > Or maybe I need to ask it this way: did 300 baud modems use a more 1:1 > > > translation of the data-word bits into Hz signal over the modem > (giving a > > > more "natural" translation rate?) But then beyond that speed, does a > > modem > > > need to "cache" a few bytes and determine some encoding scheme to then > > give > > > modems an apparent speed boost? (is that "kind-of" like USB's > 8B/10B? > > > (not in implementation, but in the general concept that a different > > > encoding can result in improved data throughput, without actual faster > > > movement of that data?) > > > > For the most part the answer is "no". > > > > The job of a modem is to carry a digital signal over a wire, at a given > > speed and given level of data integrity, and with a given channel > bandwidth. > > > > When the channel bandwidth in Hz is well above the bit rate in bps, the > > job is easy, an FSK modem can do the job. That's what the first modems > > looked like (and perhaps even earlier devices used to deal with radio > > transmission for Baudot teleprinters, commonly referred to as "tuning > > units"). > > > > When data rates go up and bandwidth doesn't, you need more complex > > modulation schemes. Modulating a carrier produces sidebands, so roughly > > speaking your baud rate can't exceed half the channel bandwidth. (I'm > sure > > I'm handwaving a lot here.) You can't do 9600 bps FSK in a voice > channel, > > it won't fit. It would fit just fine if you have a 40 kHz channel, so > it's > > certainly possible to do FSK over VHF radio at that speed if you're > > authorized that much bandwidth. > > > > So for high speed on a telephone line the exercise becomes "more bits per > > baud" -- not one bit per signal element as you get from FSK or PSK, but > two > > (QPSK) or 4 (QAM16) or even 8 (QAM256). Note that those hairy modulation > > schemes require a pretty clean channel; you're not likely to find them on > > shortwave radio systems for that reason. Indeed, doing data transmission > > over radio is an entirely separate art with a host of interesting and > > exotic methods. Some of them can reliably send data using transmission > > weak enough you can't hear them if you listen to the signal with an > > ordinary audio receiver. > > > > paul > > > > > --===============3073162264826910782==-- From abuse@cabal.org.uk Mon Feb 10 00:09:39 2025 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 01:09:29 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4076076369540931252==" --===============4076076369540931252== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote: [...] > So.. If you had a slow system that couldn't really take advantage of a > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an > older UART) That might be the use-case where this parallel v.fast might > help (by being able to "feed the modem" fast enough to actually take > advantage of the faster modem speed?) Or is there some other scenario Note that all but the dumbest modems reclock the data before transmission and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in the modem as necessary. At faster speeds there's no longer a 1:1 relationship between the signal level on the RS-232 cable and the screeches going down the phone line. Start and stop bits are not transmitted, giving a 25% speed boost from that alone. A parallel-connected modem is a bit pointless except in weird environments where one's serial port is broken or otherwise unusable. Information theory tells us that you can't get more than 64kb/s out of a dialup link, because that's the speed of the underlying digital channel used by the PSTN. Due to the reclocking, you actually need a serial port capable of 80kbaud to not drop data, and the next-highest standard baud rate is 115,200 baud, which any half-decent PC serial port can handle. To pre-empt the obvious retorts from the peanut gallery, sure, one may well have an original IBM XT or BBC Micro or whatever whose serial port drops bytes when driven faster than 9600 baud. Guess what: the machine's so slow that it can't handle the firehose of data even if its serial port wasn't a basket case. I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and predecessors) sample the incoming serial signal with a clock 16x the baud rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that this is a standard crystal frequency and also the maximum speed of a lot of UARTs. [...] > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300 > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is > 300bps itself some kind of special accelerated-by-encoding? I see 1200 > baud was also still sub 3KHz These easy-to-ask questions have very long answers. But mostly, it was *not* a case of merely increasing the baud rate or the number of bits per baud with a different modulation scheme, but multiple concurrent advances which did those *plus* some other techniques which would maintain signal integrity despite the reduced SNR. If you want the full gory detail, the relevant ITU standards are freely-available. Bring a good signal-processing textbook. > (did any modem protocol go above 3KHz?). V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even the frequency extremes which were heavily-attenuated by the line filters. It'd just listen much harder. --===============4076076369540931252==-- From macro@orcam.me.uk Mon Feb 10 00:47:53 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 00:47:30 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3325278176665706978==" --===============3325278176665706978== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 9 Feb 2025, Paul Koning via cctalk wrote: > > I was about to ask if anyone ever built a "Parallel Modem" - but I search= ed > > around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c. > > 1996) >=20 > I don't know what "parallel modem" would mean. Can you explain? In the simplest case I can certainly envisage delegating the input and=20 output shift registers to an integrated external modem unit talking some=20 kind of protocol (which could be Hayes even at the software level) to the=20 host computer over a parallel port, just as printers used to, some even=20 offering the choice between a parallel and a serial connection. A UART could then be integrated within the external unit, or skipped altogether, just as it used to be the case with "winmodems" where all the=20 modulation/demodulation stuff was done directly by the host CPU and sent=20 or received to or from the modem chipset just for DCA/ADC conversion, such=20 as with sound cards (the MC'97 codec standard was developed exactly for=20 this purpose, complementing AC'97 for audio devices). Maciej --===============3325278176665706978==-- From lewissa78@gmail.com Mon Feb 10 03:02:27 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 21:01:51 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0735044328392071235==" --===============0735044328392071235== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit > > I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and > predecessors) sample the incoming serial signal with a clock 16x the baud > rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that > this > is a standard crystal frequency and also the maximum speed of a lot of > UARTs. I was meaning something like the later modem SIIG serial cards that used a 7.3728 MHz clock (4x the 1.8432 "original"). I have one of these that is combined with a 16550 UART. Even before the IBM PC of c. 1981, I've come across PDP-11 systems with 3.6864MHz clocked UART (and some S-100 based systems, at this ~3 and also ~5 MHz clocks). Another PDP card that I have has a 0.9216 MHz clock (so 57600 bps cap). And yes, the PC-market settled on that 1.8432MHz tempo. I just recently realized, the earlier POLY-88 system (8080-based) had a "native" clock rate of exactly 1.8432 MHz, that being about 5 years earlier than the IBM PC. So maybe it's not really fair to blame that on the pick on IBM. In my experience, a 12MHz '286 couldn't fully utilize the 1.8432MHz 8250 (i.e. in my testing, I was able to receive at 57600 over a null modem cable on said '286, in a sustain {ZModem} stream without any errors; but at 115200 the system just got too many errors to be a worthwhile transfer). That's how I mean there is a crossing point where the combined CPU, memory speed, hard drive speed of the system is "under powered" for the full potential of its UART. But it was a number of years before "modulation-tech" modems blasted past even 9600 baud (at least at the consumer level), so that 1.8432 MHz pick was fine for most of the 80's. Bit of a tangent: I noticed those modern-era FTDI USB/serial adapters, their specs list 128 byte FIFOs. Maybe those "parallel modem" Microm devices just had larger onboard buffers, kind of "leap-frogging" the 16 byte buffer that many 16550 UARTs had? I've noticed those more modern FTDI USB/serial adapters have 128 bytes buffers (some 64 byte). Anyway, if your multi-tasking 386 or 486 was struggling to support a higher baud rate - I've read you could desolder a 8250 and plop in a 16550 directly, and gain the 16 byte buffer at least. If that still doesn't help, then try one of those new 7.3728 MHz equipped 16550's?? In the README docs included with the A00 FOSSIL driver c. 1990 (who ran a multi-line FIDO BBS), I recall that author mentioning options like this - and how it was the increase in multi-tasking operating systems causing stability issues in older serial cards. Anyway, the "parallel modem" is interesting in that makes it clear that RS-232 isn't essential for modem communication. RS-232 was just a "means to an end" of delivering data quickly to/from a modem device. I guess using RS-232 gave the benefit that your modem didn't need to be physically nearby (and I recall ISP offices where the modems in a closest down the hall) - due to "screaming" at +/-12V ? This might be relevant in situations where you didn't have a phone line in every room (not just in homes, but also old offices) -Steve On Sun, Feb 9, 2025 at 6:18 PM Peter Corlett via cctalk < cctalk(a)classiccmp.org> wrote: > On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote: > [...] > > So.. If you had a slow system that couldn't really take advantage of a > > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an > > older UART) That might be the use-case where this parallel v.fast might > > help (by being able to "feed the modem" fast enough to actually take > > advantage of the faster modem speed?) Or is there some other scenario > > Note that all but the dumbest modems reclock the data before transmission > and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in > the modem as necessary. At faster speeds there's no longer a 1:1 > relationship between the signal level on the RS-232 cable and the screeches > going down the phone line. Start and stop bits are not transmitted, giving > a > 25% speed boost from that alone. > > A parallel-connected modem is a bit pointless except in weird environments > where one's serial port is broken or otherwise unusable. Information theory > tells us that you can't get more than 64kb/s out of a dialup link, because > that's the speed of the underlying digital channel used by the PSTN. Due to > the reclocking, you actually need a serial port capable of 80kbaud to not > drop data, and the next-highest standard baud rate is 115,200 baud, which > any half-decent PC serial port can handle. > > To pre-empt the obvious retorts from the peanut gallery, sure, one may well > have an original IBM XT or BBC Micro or whatever whose serial port drops > bytes when driven faster than 9600 baud. Guess what: the machine's so slow > that it can't handle the firehose of data even if its serial port wasn't a > basket case. > > I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and > predecessors) sample the incoming serial signal with a clock 16x the baud > rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that > this > is a standard crystal frequency and also the maximum speed of a lot of > UARTs. > > [...] > > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300 > > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is > > 300bps itself some kind of special accelerated-by-encoding? I see 1200 > > baud was also still sub 3KHz > > These easy-to-ask questions have very long answers. But mostly, it was > *not* > a case of merely increasing the baud rate or the number of bits per baud > with a different modulation scheme, but multiple concurrent advances which > did those *plus* some other techniques which would maintain signal > integrity > despite the reduced SNR. > > If you want the full gory detail, the relevant ITU standards are > freely-available. Bring a good signal-processing textbook. > > > (did any modem protocol go above 3KHz?). > > V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even > the > frequency extremes which were heavily-attenuated by the line filters. It'd > just listen much harder. > > --===============0735044328392071235==-- From lewissa78@gmail.com Mon Feb 10 03:27:42 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 09 Feb 2025 21:27:24 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2754616280127925001==" --===============2754616280127925001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > > The stock IBM 5150 parallel port has 8 pins of data. BUT, that's 8 pins > of OUTPUT (plus 4 pins of handshake) > The "handshake" lines could be used as input, but not the data lines. > THAT is why you hear "only 4 pins of data input" Thanks for the clarification. Had forgotten about all that. On Sun, Feb 9, 2025 at 5:27=E2=80=AFPM Fred Cisin via cctalk wrote: > On Sun, 9 Feb 2025, Steve Lewis via cctalk wrote: > > BTW, every "DB25" connector in the PC world I've > > seen, it's got 8-pins for data. Even the UserPort in the Commodore world > > has that - I've not commonly seen 4-data-pin parallel cables? > > The stock IBM 5150 parallel port has 8 pins of data. BUT, that's 8 pins > of OUTPUT (plus 4 pins of handshake) > The "handshake" lines could be used as input, but not the data lines. > THAT is why you hear "only 4 pins of data input" > > BUT, there is a trivial hardware modification that you can make to the IBM > 5150 parallel port to make the 8 data pins usable as bi-directional. > (Many aftermarket parallel ports doo not need that nodification) > The need for that modificaation is WHY you keep hearing that the parallel > port only has four bits of input. > > IFF you make a "Centronics" TO parallel port adapter (36 pin female blue > ribbon input to 25 pin DB25 male output with appropriate wiring in the > adapter, then it is possible to be able to take a machine that has > parallel [Centronics compatible] output, but no serial port, etc. (there > did used to be such!) > And tell it that it is connected to a printer. The PC would then need to > act as a "printer emulator", to take incoming data from the parallel port > and save it. I built such 30+ years ago, but I never got the software to > be adequate to make it a commercial product. Hardly anybody could even > uderstand what or why it was. > > 'course, you could accomplish the same task with an external parallel to > serial printer buffer, and come in through the serial port. > > -- > Grumpy Ol' Fred cisin(a)xenosoft.com > --===============2754616280127925001==-- From lewissa78@gmail.com Mon Feb 10 07:14:20 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 01:14:02 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5436908260782226812==" --===============5436908260782226812== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Peter Corlett: > These easy-to-ask questions have very long answers. But mostly, it was > *not* > a case of merely increasing the baud rate or the number of bits per baud > with a different modulation scheme, but multiple concurrent advances which > did those *plus* some other techniques which would maintain signal > integrity > despite the reduced SNR. Apologies for the very open ended question. I found some old 1992 newsgroups thread that guided me towards the answer (including a long excerpt from "Computer Select CD-ROM" with lots of CCITT referencing). Interesting on comparing 1992 perspectives and contemporary confusion, versus today's modern references on the topic. If I'm understanding it right, a "sort of" answer to my own question is: 2400 baud (v.22bis) was an "amplification" (not the right word, but "phase magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a similar "amplification" of 2400 baud. One thing I didn't realize was v.32bis (14400) was a dynamic speed (it could slow down and speed up based on line quality). I don't recall experiencing that, as far as varied transfer rates. Someone here mentioned "Winmodem" and wow, I recall using one of those - I think it was maybe one of the last modems I used, at around 28,800 baud? I never got to experience the 33.6K or "57.6K" stuff. Even back then I recall the v.42 "compression" stuff being confusing (to me), since I didn't know what the dial-up ISP at the time would support. And if I recall correctly, the "WinModem" was somehow tied or dependent on Windows OS (or they only build drivers for Windows) and it started to hit me how "DOS is dead." Neat review. -Steve On Sun, Feb 9, 2025 at 6:18 PM Peter Corlett via cctalk < cctalk(a)classiccmp.org> wrote: > On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote: > [...] > > So.. If you had a slow system that couldn't really take advantage of a > > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an > > older UART) That might be the use-case where this parallel v.fast might > > help (by being able to "feed the modem" fast enough to actually take > > advantage of the faster modem speed?) Or is there some other scenario > > Note that all but the dumbest modems reclock the data before transmission > and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in > the modem as necessary. At faster speeds there's no longer a 1:1 > relationship between the signal level on the RS-232 cable and the screeches > going down the phone line. Start and stop bits are not transmitted, giving > a > 25% speed boost from that alone. > > A parallel-connected modem is a bit pointless except in weird environments > where one's serial port is broken or otherwise unusable. Information theory > tells us that you can't get more than 64kb/s out of a dialup link, because > that's the speed of the underlying digital channel used by the PSTN. Due to > the reclocking, you actually need a serial port capable of 80kbaud to not > drop data, and the next-highest standard baud rate is 115,200 baud, which > any half-decent PC serial port can handle. > > To pre-empt the obvious retorts from the peanut gallery, sure, one may well > have an original IBM XT or BBC Micro or whatever whose serial port drops > bytes when driven faster than 9600 baud. Guess what: the machine's so slow > that it can't handle the firehose of data even if its serial port wasn't a > basket case. > > I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and > predecessors) sample the incoming serial signal with a clock 16x the baud > rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that > this > is a standard crystal frequency and also the maximum speed of a lot of > UARTs. > > [...] > > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300 > > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is > > 300bps itself some kind of special accelerated-by-encoding? I see 1200 > > baud was also still sub 3KHz > > These easy-to-ask questions have very long answers. But mostly, it was > *not* > a case of merely increasing the baud rate or the number of bits per baud > with a different modulation scheme, but multiple concurrent advances which > did those *plus* some other techniques which would maintain signal > integrity > despite the reduced SNR. > > If you want the full gory detail, the relevant ITU standards are > freely-available. Bring a good signal-processing textbook. > > > (did any modem protocol go above 3KHz?). > > V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even > the > frequency extremes which were heavily-attenuated by the line filters. It'd > just listen much harder. > > --===============5436908260782226812==-- From imp@bsdimp.com Mon Feb 10 07:34:10 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 00:33:52 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3551773443570348884==" --===============3551773443570348884== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2025, 12:14=E2=80=AFAM Steve Lewis via cctalk wrote: > Peter Corlett: > > > These easy-to-ask questions have very long answers. But mostly, it was > > *not* > > a case of merely increasing the baud rate or the number of bits per baud > > with a different modulation scheme, but multiple concurrent advances > which > > did those *plus* some other techniques which would maintain signal > > integrity > > despite the reduced SNR. > > > > Apologies for the very open ended question. I found some old 1992 > newsgroups thread that guided me towards the answer (including a long > excerpt from "Computer Select CD-ROM" with lots of CCITT referencing). > Interesting on comparing 1992 perspectives and contemporary confusion, > versus today's modern references on the topic. > > If I'm understanding it right, a "sort of" answer to my own question is: > 2400 baud (v.22bis) was an "amplification" (not the right word, but "phase > magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a > similar "amplification" of 2400 baud. > > One thing I didn't realize was v.32bis (14400) was a dynamic speed (it > could slow down and speed up based on line quality). I don't recall > experiencing that, as far as varied transfer rates. > > Someone here mentioned "Winmodem" and wow, I recall using one of those - I > think it was maybe one of the last modems I used, at around 28,800 baud? I > never got to experience the 33.6K or "57.6K" stuff. Even back then I > recall the v.42 "compression" stuff being confusing (to me), since I didn't > know what the dial-up ISP at the time would support. And if I recall > correctly, the "WinModem" was somehow tied or dependent on Windows OS (or > they only build drivers for Windows) and it started to hit me how "DOS is > dead." > Yes and no. Winmodem lacked the smarts to generate or decode the signals needed for v..33, etc. Instead, the modulation and demodulation was all in software that then was played much like a sound card. Way cheaper to make, but that took a lot of CPU. And the mod/demod ran only under Windows at first. Not under DOS, Linux or FreeBSD, at least not until much later for Linux... Warner > > Neat review. > > -Steve > > > > > > On Sun, Feb 9, 2025 at 6:18=E2=80=AFPM Peter Corlett via cctalk < > cctalk(a)classiccmp.org> wrote: > > > On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote: > > [...] > > > So.. If you had a slow system that couldn't really take advantage of a > > > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with > an > > > older UART) That might be the use-case where this parallel v.fast might > > > help (by being able to "feed the modem" fast enough to actually take > > > advantage of the faster modem speed?) Or is there some other scenario > > > > Note that all but the dumbest modems reclock the data before transmission > > and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in > > the modem as necessary. At faster speeds there's no longer a 1:1 > > relationship between the signal level on the RS-232 cable and the > screeches > > going down the phone line. Start and stop bits are not transmitted, > giving > > a > > 25% speed boost from that alone. > > > > A parallel-connected modem is a bit pointless except in weird > environments > > where one's serial port is broken or otherwise unusable. Information > theory > > tells us that you can't get more than 64kb/s out of a dialup link, > because > > that's the speed of the underlying digital channel used by the PSTN. Due > to > > the reclocking, you actually need a serial port capable of 80kbaud to not > > drop data, and the next-highest standard baud rate is 115,200 baud, which > > any half-decent PC serial port can handle. > > > > To pre-empt the obvious retorts from the peanut gallery, sure, one may > well > > have an original IBM XT or BBC Micro or whatever whose serial port drops > > bytes when driven faster than 9600 baud. Guess what: the machine's so > slow > > that it can't handle the firehose of data even if its serial port wasn't > a > > basket case. > > > > I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and > > predecessors) sample the incoming serial signal with a clock 16x the baud > > rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that > > this > > is a standard crystal frequency and also the maximum speed of a lot of > > UARTs. > > > > [...] > > > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400 > > > baud-equivalent modem an accelerated-by-enhanced-encoding version of > 300 > > > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is > > > 300bps itself some kind of special accelerated-by-encoding? I see 1200 > > > baud was also still sub 3KHz > > > > These easy-to-ask questions have very long answers. But mostly, it was > > *not* > > a case of merely increasing the baud rate or the number of bits per baud > > with a different modulation scheme, but multiple concurrent advances > which > > did those *plus* some other techniques which would maintain signal > > integrity > > despite the reduced SNR. > > > > If you want the full gory detail, the relevant ITU standards are > > freely-available. Bring a good signal-processing textbook. > > > > > (did any modem protocol go above 3KHz?). > > > > V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even > > the > > frequency extremes which were heavily-attenuated by the line filters. > It'd > > just listen much harder. > > > > > --===============3551773443570348884==-- From brain@jbrain.com Mon Feb 10 09:03:50 2025 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 02:58:43 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1265868945932324095==" --===============1265868945932324095== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote: > If I'm understanding it right, a "sort of" answer to my own question is: > 2400 baud (v.22bis) was an "amplification" (not the right word, but "phase > magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a > similar "amplification" of 2400 baud. Not sure if it's been linked, but I found a list of baud->bps mappings at Wikipedia: https://en.wikipedia.org/wiki/Modem For those who are OK using that resource to answer questions.  I found it interesting at 1200 bps had two options (1200baud * 2 tones or 600 baud * 4 tones) Jim -- Jim Brain brain(a)jbrain.com www.jbrain.com --===============1265868945932324095==-- From paulkoning@comcast.net Mon Feb 10 16:09:12 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 11:08:55 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3127984607134348378==" --===============3127984607134348378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 10, 2025, at 3:58=E2=80=AFAM, Jim Brain via cctalk wrote: >=20 > On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote: >> If I'm understanding it right, a "sort of" answer to my own question is: >> 2400 baud (v.22bis) was an "amplification" (not the right word, but "phase >> magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a >> similar "amplification" of 2400 baud. >=20 > Not sure if it's been linked, but I found a list of baud->bps mappings at W= ikipedia: >=20 > https://en.wikipedia.org/wiki/Modem >=20 > For those who are OK using that resource to answer questions. I found it i= nteresting at 1200 bps had two options (1200baud * 2 tones or 600 baud * 4 to= nes) Not 4 tones; 4 modulation states per signal element, that is what QPSK means. The difference is that the 202 standard was designed to run half duplex over = a standard phone line, or full duplex if you had a 4 wire (leased line) circu= it. It's a very simple device that actually works at any speed up to 1200 bp= s (or a hair more, as PLATO did). The 212 modem using QPSK is a clocked syst= em, but it can carry 1200 bps full duplex over a single phone line, with half= the channel bandwidth used for one direction and half for the other. The 202 specification was used in early amateur radio packet radio systems, F= SK over shortwave radio links or AFSK (FSK modulated audio tones modulated on= to an FM radio channel) for VHF. That works nicely because amateur radio is = normally half duplex, and 202 modems were readily available at the time or co= uld be easily built by amateurs if needed. The only additional work is recei= ve clock recovery, because 202 modems aren't clocked so for synchronous trans= mission (packet radio is HDLC) you need to recover the bit clock. paul --===============3127984607134348378==-- From brain@jbrain.com Mon Feb 10 16:46:28 2025 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 10:46:21 -0600 Message-ID: <0d44f393-40f0-449e-a32f-14b215e536e1@jbrain.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2076764083300024983==" --===============2076764083300024983== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/10/2025 10:08 AM, Paul Koning wrote: > >> On Feb 10, 2025, at 3:58=E2=80=AFAM, Jim Brain via cctalk wrote: >> >> On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote: >>> If I'm understanding it right, a "sort of" answer to my own question is: >>> 2400 baud (v.22bis) was an "amplification" (not the right word, but "phase >>> magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a >>> similar "amplification" of 2400 baud. >> Not sure if it's been linked, but I found a list of baud->bps mappings at = Wikipedia: >> >> https://en.wikipedia.org/wiki/Modem >> >> For those who are OK using that resource to answer questions. I found it = interesting at 1200 bps had two options (1200baud * 2 tones or 600 baud * 4 t= ones) > Not 4 tones; 4 modulation states per signal element, that is what QPSK mean= s. Apologies, I was trying to use simpler terminology, given the writer's=20 attempt to understand the overall relationship. > > The difference is that the 202 standard was designed to run half duplex ove= r a standard phone line, or full duplex if you had a 4 wire (leased line) cir= cuit. It's a very simple device that actually works at any speed up to 1200 = bps (or a hair more, as PLATO did). The 212 modem using QPSK is a clocked sy= stem, but it can carry 1200 bps full duplex over a single phone line, with ha= lf the channel bandwidth used for one direction and half for the other. I realize it's extremely late and probably of no value except for=20 historical purposes, but having a way to visualize the various standards=20 in this space with respect to duplex, baud/bps rate, etc. would be of so=20 much value. Like the poster I replied to, how a modem worked always=20 seemed so oblique, especially as the speeds increased beyond 9600, even=20 without the added complexity of things like MNP and the negotiation=20 "dance" later modems held on the line.=C2=A0 It was fascinating to hear about= =20 and use, but I always felt I should know more about it. Yet, most=20 material in the day either waved a hand over the whole topic, or tried=20 to regurgitate the CCITT documentation.=C2=A0 Specifically, in your above=20 statement, I'm still struggling to understand the duplex aspect of the=20 various standards.=C2=A0 As a ham operator and having went through my EE=20 degree, I understand duplex, but since I always thought of the phone=20 line as a full duplex medium, how it would be used as a half duplex=20 channel eludes me.=C2=A0 I'm OK with some terminology simplification, as=20 shown above, if it could help show how the bandwidth of the telephone=20 line was divided up in the various standards and how a 202 standard=20 managed to emulate a full duplex conversation (if it actually did this)=20 over the half duplex 2 wire telephone circuit.=C2=A0 (And I use emulate in a = loose sense, I suppose.=C2=A0 Back in the day, when IBM and LU.2 was a thing,= =20 I worked at a company that created a general comms package that could=20 pass data over various protocols, including TCP/IP, LU6.2, NetBIOS, IPX,=20 and LU.2, which I believe was half duplex. But, the generic package=20 promised full duplex comms, so we (not me, but the team) had to build a=20 way to emulate a full duplex connection over that half duplex=20 technology. It worked, at least well enough to support the apps used=20 with it, but even it was "magic" to me, and I read all the source code) Jim --=20 Jim Brain brain(a)jbrain.com www.jbrain.com --===============2076764083300024983==-- From paulkoning@comcast.net Mon Feb 10 19:51:00 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 14:50:42 -0500 Message-ID: In-Reply-To: <0d44f393-40f0-449e-a32f-14b215e536e1@jbrain.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2708652184208008324==" --===============2708652184208008324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 10, 2025, at 11:46=E2=80=AFAM, Jim Brain wrote: >=20 > On 2/10/2025 10:08 AM, Paul Koning wrote: >> ... >> The difference is that the 202 standard was designed to run half duplex ov= er a standard phone line, or full duplex if you had a 4 wire (leased line) ci= rcuit. It's a very simple device that actually works at any speed up to 1200= bps (or a hair more, as PLATO did). The 212 modem using QPSK is a clocked s= ystem, but it can carry 1200 bps full duplex over a single phone line, with h= alf the channel bandwidth used for one direction and half for the other. > I realize it's extremely late and probably of no value except for historica= l purposes, but having a way to visualize the various standards in this space= with respect to duplex, baud/bps rate, etc. would be of so much value. Like = the poster I replied to, how a modem worked always seemed so oblique, especia= lly as the speeds increased beyond 9600, even without the added complexity of= things like MNP and the negotiation "dance" later modems held on the line. = It was fascinating to hear about and use, but I always felt I should know mor= e about it. Yet, most material in the day either waved a hand over the whole = topic, or tried to regurgitate the CCITT documentation. Specifically, in you= r above statement, I'm still struggling to understand the duplex aspect of th= e various standards. As a ham operator and having went through my EE degree,= I understand duplex, but since I always thought of the phone line as a full = duplex medium, how it would be used as a half duplex channel eludes me. I'm = OK with some terminology simplification, as shown above, if it could help sho= w how the bandwidth of the telephone line was divided up in the various stand= ards and how a 202 standard managed to emulate a full duplex conversation (if= it actually did this) over the half duplex 2 wire telephone circuit. (And I= use emulate in a loose sense, I suppose. Back in the day, when IBM and LU.2= was a thing, I worked at a company that created a general comms package that= could pass data over various protocols, including TCP/IP, LU6.2, NetBIOS, IP= X, and LU.2, which I believe was half duplex. But, the generic package promis= ed full duplex comms, so we (not me, but the team) had to build a way to emul= ate a full duplex connection over that half duplex technology. It worked, at = least well enough to support the apps used with it, but even it was "magic" t= o me, and I read all the source code) Yes, a phone line is full duplex, to humans. What actually happens is that t= he line carries both directions, superimposed -- you hear both sides in the h= eadphone. That works well for us because we know how to sort the two signals. A telephone line modem can be done three ways, roughly: 1. Half duplex: the channel is only active in one direction at a time. (202 = modem) 2. Full duplex band split: one direction uses the lower half of the bandwidth= , the other the upper half. (212 modem) 3. Full duplex full bandwidth: each direction uses the full bandwidth but ca= refully subtracts the local signal from what is seen on the line to arrive at= the signal from the other side. (V.32 etc., I believe) The "negotiation" you're referring to may include things like equalization an= d calibrating the local side suppression for case (3), since those things var= y from one connection to the next (and, possibly, over time even for one cont= inuing connection). A 202 modem, on a POTS line, did not emulate full duplex. It could only run = half duplex, with the usual RS-232 modem control signal handshakes to do line= turnaround. Some (perhaps most or all, I don't know) of 202 modems can be c= onnected to a 4-wire channel, essentially two phone lines in parallel where e= ach pair carries one direction, the two pairs in opposite directions. You co= uld get that sort of line from Ma Bell but it would be a permanent circuit, n= ot a dialed phone line. As for datacomm protocols like TCP/IP and such: IP sits above the data link l= ayer so it's not really in the picture. Looking at DECnet, the original data= link (DDCMP) has support for both half and full duplex. Interestingly enoug= h, multipoint involves one station (the "master") polling the others ("tribut= aries") for traffic, so it seems an obvious half duplex setup, but DDCMP 4.0 = supports multipoint both on half and full duplex lines. Above the data link you'd typically see what looks like a full duplex system,= but if the data link is half duplex then at that layer the "both directions = at the same time" property disappears. Since it's packet switching with inde= terminate timing that is fine. If you want hard-synchronous transmisson it i= sn't, but that isn't in the domain of IP. The distinction doesn't just appear in modems: DDCMP over "integral modem" co= ax links can be half duplex (one coax) or full duplex (two coax cables). Ori= ginal coaxial cable Ethernet is half duplex, while the introduction of twiste= d pair enabled full duplex but at least in the lower speeds doesn't require i= t. The various token schemes (802.5, 802.4, FDDI) are all inherently half du= plex. paul --===============2708652184208008324==-- From rickb@bensene.com Mon Feb 10 22:40:50 2025 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 22:40:43 +0000 Message-ID: <6e7d0aef4e35419b8e54d31aa0f5489a@bensene.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3998741255647664876==" --===============3998741255647664876== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Steve wrote: > I was about to ask if anyone ever built a "Parallel Modem" - but I searched= around first, and lo and > behold, Microcom did ! (v.fast / v.34 era, c. 19= 96) There was a company called Xircom that made parallel port modems. These were = full modems that were small enough that they plugged into a laptop serial por= t, and got their power from the laptop via the external mouse/keyboard port. = They had a feed-though connector so you could still connect and external mou= se/keyboard if you wanted. The idea was portability, and not having to have = extra cables (e.g., serial cable) to carry around. I think that these may h= ave been available up to 2400 baud, maybe higher, but can't remember. This = was at a time before laptops only had black and white LCD screens, floppy dri= ve (no hard disk), and a parallel and serial port, and huge batteries that di= dn't run the machines for very long. I did use one of these Xircom modems o= n a Tandy Radio Shack Model 100 portable computer, and it worked well and did= not seriously impact runtime on battery when it was being used. There was a= special machine language program that you had to load that logically switche= d out the serial port to go through the parallel port as needed by the modem.= I used on briefly on an old Toshiba Win95 laptop with a color display (don'= t remember the model), and it also worked well there. After laptops started= having PCMCIA ports, Xircom made some modem cards in PCMCIA form-factor, and= they had a little dongle that plugged into them that provided the RJ11 jack = to plug the phone line into. I think these could go up to 14.4Kb, maybe mor= e. I have at least one of the old Xircom parallel modems, and perhaps a cou= ple of the Xircom PCMCIA modem cards in a box somewhere. Definitely devices= that aged out fairly quickly as technology advanced and modems were built-in= to laptops for a while. Then modems, serial ports, floppy drives, optical med= ia, and even parallel ports disappeared from laptops in favor of USB and WiFi= , and even built in cellular Internet. Rick --===============3998741255647664876==-- From lewissa78@gmail.com Tue Feb 11 04:10:26 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Mon, 10 Feb 2025 22:10:06 -0600 Message-ID: In-Reply-To: <0d44f393-40f0-449e-a32f-14b215e536e1@jbrain.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3047916605902053458==" --===============3047916605902053458== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Jim Brain > I realize it's extremely late and probably of no value except for > historical purposes, but having a way to visualize the various standards > in this space with respect to duplex, baud/bps rate, etc. would be of so I recently came across this on YouTube - it's from 13 years ago, but I found it insightful . It's a Spectrogram of a modem dial-in connection. I'm not sure if it's from simulation or an actual measurement - either way, I think it's reasonably representative of the idea of tones being split into signal, all involving FFT's. Dial Up Modem Handshake Sound - Spectrogram - YouTube (the first comment on that video is helpful) And from the above video, that led me to this: dialup-final.png (2500=C3=971304) Then from the CCITT standards, I recall the verbiage of it talking specifying "re-serializing" the signal. So in a way, these modulated signals are another form of parallel back to the serial? Or "serial to multi-phase back to serial" ? But - but - I thought we needed quantum computers to represent more states than 0 and 1 at the same time? ;) But the CCITT get dizzying to try to categorize - there seems to be a "synchronous" and "asynchronous" version of nearly all of them, or half vs hull duplex variants? But one thing I did come across in exploring them: the concept of echoing? I'm just guessing, but I recall one issue with parallel ports is that a close enough wires and high speeds, you get "cross-talk"? I suspect TX/RX lines of serial end up close together, is "echoing" somehow residual of a RX echo'ing back out on the TX? (I'm really guessing on it, speculating before I read up more about it) In short, this echo'ing effect I think partially explains why at high speeds they could TX faster than RX? Another thing I've recently read: 1200 baud v.22 isn't noted until 1980. Maybe it was technically available a couple years earlier (you still see that today, how WiFi vendors claim some new fast speed, chomping at the bit to jump the market before competitors - and doing so at risk before the standard is really ratified; that game was played also with modems -- ending up with a "mixed bag" on performance, especially when using devices across vendors?). Anyway, thinking on it: 1980-ish makes sense. You had 300 baud modems from 1963 to 1980, because to pull off any fancier modulation - you need a clever FFT on a chip, a general-processor CPU (up to that point) wasn't fast enough to pull it off. [ and I do mean in the more consumer-grade stuff ] Is that a reasonable characterization? (on why 300 baud was "the standard" for so long, and then suddenly the next decade after that with incrementally better multi-phase encoding to could sustain faster equivalent baud rates?) -Steve On Mon, Feb 10, 2025 at 10:46=E2=80=AFAM Jim Brain via cctalk wrote: > On 2/10/2025 10:08 AM, Paul Koning wrote: > > > >> On Feb 10, 2025, at 3:58=E2=80=AFAM, Jim Brain via cctalk < > cctalk(a)classiccmp.org> wrote: > >> > >> On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote: > >>> If I'm understanding it right, a "sort of" answer to my own question > is: > >>> 2400 baud (v.22bis) was an "amplification" (not the right word, but > "phase > >>> magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) > was a > >>> similar "amplification" of 2400 baud. > >> Not sure if it's been linked, but I found a list of baud->bps mappings > at Wikipedia: > >> > >> https://en.wikipedia.org/wiki/Modem > >> > >> For those who are OK using that resource to answer questions. I found > it interesting at 1200 bps had two options (1200baud * 2 tones or 600 baud > * 4 tones) > > Not 4 tones; 4 modulation states per signal element, that is what QPSK > means. > Apologies, I was trying to use simpler terminology, given the writer's > attempt to understand the overall relationship. > > > > The difference is that the 202 standard was designed to run half duplex > over a standard phone line, or full duplex if you had a 4 wire (leased > line) circuit. It's a very simple device that actually works at any speed > up to 1200 bps (or a hair more, as PLATO did). The 212 modem using QPSK is > a clocked system, but it can carry 1200 bps full duplex over a single phone > line, with half the channel bandwidth used for one direction and half for > the other. > I realize it's extremely late and probably of no value except for > historical purposes, but having a way to visualize the various standards > in this space with respect to duplex, baud/bps rate, etc. would be of so > much value. Like the poster I replied to, how a modem worked always > seemed so oblique, especially as the speeds increased beyond 9600, even > without the added complexity of things like MNP and the negotiation > "dance" later modems held on the line. It was fascinating to hear about > and use, but I always felt I should know more about it. Yet, most > material in the day either waved a hand over the whole topic, or tried > to regurgitate the CCITT documentation. Specifically, in your above > statement, I'm still struggling to understand the duplex aspect of the > various standards. As a ham operator and having went through my EE > degree, I understand duplex, but since I always thought of the phone > line as a full duplex medium, how it would be used as a half duplex > channel eludes me. I'm OK with some terminology simplification, as > shown above, if it could help show how the bandwidth of the telephone > line was divided up in the various standards and how a 202 standard > managed to emulate a full duplex conversation (if it actually did this) > over the half duplex 2 wire telephone circuit. (And I use emulate in a > loose sense, I suppose. Back in the day, when IBM and LU.2 was a thing, > I worked at a company that created a general comms package that could > pass data over various protocols, including TCP/IP, LU6.2, NetBIOS, IPX, > and LU.2, which I believe was half duplex. But, the generic package > promised full duplex comms, so we (not me, but the team) had to build a > way to emulate a full duplex connection over that half duplex > technology. It worked, at least well enough to support the apps used > with it, but even it was "magic" to me, and I read all the source code) > > > Jim > > -- > Jim Brain > brain(a)jbrain.com > www.jbrain.com > > --===============3047916605902053458==-- From brain@jbrain.com Tue Feb 11 06:27:14 2025 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Tue, 11 Feb 2025 00:27:07 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3074309260351789239==" --===============3074309260351789239== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/10/2025 10:10 PM, Steve Lewis via cctalk wrote: > dialup-final.png (2500×1304) > This is the one I remember seeing in the past, though seeing this (like a spectrograph like you see on some PSK31 apps) in the video format with the annotations as they appear would be the coolest thing ever to help understand this.  Yes, the first comment on the video was very helpful, though I had to keep stopping the video at the various times to get a handle on the portion of the sequence Jim -- Jim Brain brain(a)jbrain.com www.jbrain.com --===============3074309260351789239==-- From abuse@cabal.org.uk Tue Feb 11 16:32:18 2025 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Tue, 11 Feb 2025 17:32:10 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5774789038388518998==" --===============5774789038388518998== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Feb 09, 2025 at 09:01:51PM -0600, Steve Lewis via cctalk wrote: [...] > In my experience, a 12MHz '286 couldn't fully utilize the 1.8432MHz 8250 > (i.e. in my testing, I was able to receive at 57600 over a null modem > cable on said '286, in a sustain {ZModem} stream without any errors; but > at 115200 the system just got too many errors to be a worthwhile > transfer). That's how I mean there is a crossing point where the combined > CPU, memory speed, hard drive speed of the system is "under powered" for > the full potential of its UART. But it was a number of years before > "modulation-tech" modems blasted past even 9600 baud (at least at the > consumer level), so that 1.8432 MHz pick was fine for most of the 80's. The actual clock speed of the UART is an implementation detail. The limiting factor to reliable PC serial throughput is often interrupt latency rather than raw baud rate, and that is due to cheaping out on implementation and not that the CPU is too slow to process a piddling 12K of data per second. The 8250, 6551, Amiga serial port, etc do not have FIFOs and so generate one interrupt per byte. The CPU has to respond to the interrupt and retrieve the incoming byte before the next byte has arrived. At 9600 baud, that needs to happen within 1ms. At 115,200 baud, it's 87µs. Older operating systems -- especially from the era where non-FIFO serial ports were still standard -- would leave interrupts disabled for extended periods. It was a cheap way for single-CPU systems to perform uninterruptable critical sections. A special kind of critical section is the handling of some other interrupt (e.g. keyboard or disk). Thus the maximum potential interrupt latency is increased by these little bits of work which randomly pop up at inconvenient times. You would have probably observed that the serial error rate increased during disk I/O. 1ms is a fairly reasonable rule-of-thumb for maximum interrupt latency on a general-purpose computer of the mid-80s, and thus 9600 baud or so is about all you're going to get reliably. So you could have an infinite UART clock and infinite baud rate, but so long as the data comes in no faster than 1ms per byte, it'll still work reliably. Your specific 286 was doing somewhat better than that; perhaps your terminal client was disabling interrupts and bit-banging the serial port during transmission of ZMODEM blocks. (As to that 87µs, I wouldn't rely on even the latest whizz-bang machine to consistently beat that deadline. The interrupt has to wend its way through the PCI bridge and the IO-APIC, and then the CPU has to notice the interrupt, then complete whatever work is stuck in the pipeline or otherwise get into a state where it can do a mode switch and call the ISR. Most interrupts will be handled in a handful of microseconds, and maybe even mere hundreds of nanoseconds, but the worst-case interrupt latency is rather closer to infinity than we'd all like. But this is classiccmp, not moderncmp.) Doubling the UART clock rate will double the maximum baud rate, but that wins you nothing if the machine can't handle all of those interrupts in time. In the case of the PC, it also means that the wrong value will be programmed into the UART's divider for a given baud rate because a 1.8432MHz base clock is assumed. The proper solution to dodgy PC serial port performance was of course to upgrade to the 16550 which had a FIFO which could buffer a few bytes while the PC got round to answering the interrupt. It's not the greatest UART and adds novel failure modes, but it does have the extremely useful property that it is register-compatible with the 8250 and so older software can still drive it without needing to be patched. The 16550 (at 1.8432Mhz) still has the same top speed of 115,200 baud, but that's just fine for the kind of applications which use physical RS-232-compatible serial ports such as dialup modems and serial mice. RS-232 only guarantees up to 20 kilobaud anyway, and anything faster is out of spec and works through luck. Fortunately, we had a lot of luck by the late 1990s when V.90 dialup came around. Want to go even faster over long cable runs? We have Ethernet for that sort of thing, and it's rather more reliable at it. --===============5774789038388518998==-- From bfranchuk@jetnet.ab.ca Tue Feb 11 16:49:30 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Tue, 11 Feb 2025 09:49:23 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6780091362549701681==" --===============6780091362549701681== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-11 9:32 a.m., Peter Corlett via cctalk wrote: > The proper solution to dodgy PC serial port performance was of course to > upgrade to the 16550 which had a FIFO which could buffer a few bytes while > the PC got round to answering the interrupt. It's not the greatest UART and > adds novel failure modes, but it does have the extremely useful property > that it is register-compatible with the 8250 and so older software can still > drive it without needing to be patched. I thought many 16550 had dud fifo's. Interrupts under DOS was hit and miss. > The 16550 (at 1.8432Mhz) still has the same top speed of 115,200 baud, but > that's just fine for the kind of applications which use physical > RS-232-compatible serial ports such as dialup modems and serial mice. RS-232 > only guarantees up to 20 kilobaud anyway, and anything faster is out of spec > and works through luck. Fortunately, we had a lot of luck by the late 1990s > when V.90 dialup came around. Want to go even faster over long cable runs? > We have Ethernet for that sort of thing, and it's rather more reliable at > it. > Sneaker net with van is better yet, moving large data.(10 TB per tape) :). --===============6780091362549701681==-- From spectre@floodgap.com Tue Feb 11 17:42:37 2025 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Tue, 11 Feb 2025 09:42:31 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5156770312808848100==" --===============5156770312808848100== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > The 8250, 6551, Amiga serial port, etc do not have FIFOs and so generate one > interrupt per byte. The CPU has to respond to the interrupt and retrieve the > incoming byte before the next byte has arrived. At 9600 baud, that needs to > happen within 1ms. At 115,200 baud, it's 87=C2=B5s. >=20 > Older operating systems -- especially from the era where non-FIFO serial > ports were still standard -- would leave interrupts disabled for extended > periods. At least for the 6551 cartridges on the Commodore 64/128, they were wired to send NMIs. 57600bps generally worked just fine with later ones like the Turbo232 (the SwiftLink was limited to 38400). The 6551 in the Plus/4 is rigged to send IRQs, but I've not used one for seri= al communications, so I can't say if it was substantially different in its performance. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Furious activity is no substitute for understanding. -- H. H. Williams ---= -- --===============5156770312808848100==-- From cz@alembic.crystel.com Tue Feb 11 17:44:32 2025 From: Christopher Zach To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Tue, 11 Feb 2025 12:44:22 -0500 Message-ID: <00E867EA-0F31-4163-95BA-E99E1DFEEC19@alembic.crystel.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2755079170410485727==" --===============2755079170410485727== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 16450 was the one with buffer issues On February 11, 2025 11:49:23 AM EST, ben via cctalk wrote: >On 2025-02-11 9:32 a.m., Peter Corlett via cctalk wrote: > >> The proper solution to dodgy PC serial port performance was of course to >> upgrade to the 16550 which had a FIFO which could buffer a few bytes while >> the PC got round to answering the interrupt. It's not the greatest UART and >> adds novel failure modes, but it does have the extremely useful property >> that it is register-compatible with the 8250 and so older software can sti= ll >> drive it without needing to be patched. > >I thought many 16550 had dud fifo's. >Interrupts under DOS was hit and miss. > >> The 16550 (at 1.8432Mhz) still has the same top speed of 115,200 baud, but >> that's just fine for the kind of applications which use physical >> RS-232-compatible serial ports such as dialup modems and serial mice. RS-2= 32 >> only guarantees up to 20 kilobaud anyway, and anything faster is out of sp= ec >> and works through luck. Fortunately, we had a lot of luck by the late 1990s >> when V.90 dialup came around. Want to go even faster over long cable runs? >> We have Ethernet for that sort of thing, and it's rather more reliable at >> it. >>=20 >Sneaker net with van is better yet, moving large data.(10 TB per tape) :). > > --===============2755079170410485727==-- From imp@bsdimp.com Tue Feb 11 19:10:08 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Tue, 11 Feb 2025 12:09:48 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1228480316642098093==" --===============1228480316642098093== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, Feb 11, 2025 at 9:49 AM ben via cctalk wrote: > On 2025-02-11 9:32 a.m., Peter Corlett via cctalk wrote: > > > The proper solution to dodgy PC serial port performance was of course to > > upgrade to the 16550 which had a FIFO which could buffer a few bytes > while > > the PC got round to answering the interrupt. It's not the greatest UART > and > > adds novel failure modes, but it does have the extremely useful property > > that it is register-compatible with the 8250 and so older software can > still > > drive it without needing to be patched. > > I thought many 16550 had dud fifo's. > Interrupts under DOS was hit and miss. > No. The 16550''s were good enough to do line rate 115200 on a 16MHz 386 under both FreeBSD and Linux (though the clist overhead was a little high on FreeBSD in comparison to Linux). > > The 16550 (at 1.8432Mhz) still has the same top speed of 115,200 baud, > but > > that's just fine for the kind of applications which use physical > > RS-232-compatible serial ports such as dialup modems and serial mice. > RS-232 > > only guarantees up to 20 kilobaud anyway, and anything faster is out of > spec > > and works through luck. Fortunately, we had a lot of luck by the late > 1990s > > when V.90 dialup came around. Want to go even faster over long cable > runs? > Yea, 16550 compatible UARTs are still around, and go up to baud rates of 10Mbps at least in the embedded space where you often use it to jam in the first bootstrap program (or the unbricking program). Warner > > We have Ethernet for that sort of thing, and it's rather more reliable at > > it. > > > Sneaker net with van is better yet, moving large data.(10 TB per tape) :). > > > --===============1228480316642098093==-- From macro@orcam.me.uk Wed Feb 12 17:10:03 2025 From: "Maciej W. Rozycki" To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Wed, 12 Feb 2025 17:09:56 +0000 Message-ID: In-Reply-To: <00E867EA-0F31-4163-95BA-E99E1DFEEC19@alembic.crystel.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9200717303207979977==" --===============9200717303207979977== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 11 Feb 2025, Christopher Zach via cctalk wrote: > 16450 was the one with buffer issues The 16450 was hardly different from 8250: "The NS 16450 is an improved specification version of the INS8250A Universal Asynchronous Receiver/Transmitter (UART). The improved specifications ensure compatibility with the NS32032 and other state-of-the-art CPUs. Functionally, the NS16450 is equivalent to the INS8250A." The broken-FIFO one was the short-lived 16550, while 16550A was the fixed one. Also I do believe it was NS, having been guilty for the broken FIFO, that only used the 16550 vs 16550A terminology and other implementers just called their functional-FIFO parts 16550, which is why people commonly say 16550 having one with a FIFO in mind. Maciej --===============9200717303207979977==-- From jeffrey@vcfed.org Thu Feb 13 06:12:08 2025 From: Jeffrey Brace To: cctalk@classiccmp.org Subject: [cctalk] Vintage Computer Festival Montreal Survey Date: Thu, 13 Feb 2025 01:11:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8877466724362347117==" --===============8877466724362347117== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit We invite you to take part in a brief, anonymous survey about VCF Montreal. Click here https://bit.ly/vcfm2026pre-en Nous vous invitons à participer à un bref sondage anonyme sur VCF Montréal. Cliquez ici https://bit.ly/vcfm2026pre-fr Jeff Brace Vintage Computer Federation Vice President --===============8877466724362347117==-- From vaxorcist@googlemail.com Thu Feb 13 08:25:16 2025 From: Hans-Ulrich =?utf-8?q?H=C3=B6lscher?= To: cctalk@classiccmp.org Subject: [cctalk] Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 09:24:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2514652583732729568==" --===============2514652583732729568== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Does anyone know anything about the whereabouts of Megan Gentry, former RT-11 developer? She left her last trace in 2020, when she ported ZEMU to RT-11. --===============2514652583732729568==-- From pdp11@saccade.com Thu Feb 13 09:28:33 2025 From: "J. Peterson" To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 01:13:26 -0800 Message-ID: <6f8b1c04-5cac-4f94-aae6-b53baa8f61c1@saccade.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0844347574756871926==" --===============0844347574756871926== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit This link has an update from 2023, along with an email address. https://www.pdp-11.nl/fieldguide.html On 2/13/2025 12:24 AM, Hans-Ulrich Hölscher via cctalk wrote: > Megan Gentry --===============0844347574756871926==-- From vaxorcist@googlemail.com Thu Feb 13 13:37:17 2025 From: Hans-Ulrich =?utf-8?q?H=C3=B6lscher?= To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 14:36:59 +0100 Message-ID: In-Reply-To: <6f8b1c04-5cac-4f94-aae6-b53baa8f61c1@saccade.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2579805027657014353==" --===============2579805027657014353== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Unfortunately both addresses do not work, but thanks anyway! Ulli Am Do., 13. Feb. 2025 um 10:28 Uhr schrieb J. Peterson via cctalk < cctalk(a)classiccmp.org>: > This link has an update from 2023, along with an email address. > > https://www.pdp-11.nl/fieldguide.html > > On 2/13/2025 12:24 AM, Hans-Ulrich Hölscher via cctalk wrote: > > Megan Gentry > --===============2579805027657014353==-- From michael.99.thompson@gmail.com Thu Feb 13 17:12:09 2025 From: Michael Thompson To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 12:11:49 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2061605442744294530==" --===============2061605442744294530== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Try Gentry, Megan or "mbg2(a)verizon.net" < mbg2(a)verizon.net> On Thu, Feb 13, 2025 at 8:37 AM Hans-Ulrich Hölscher via cctalk < cctalk(a)classiccmp.org> wrote: > Unfortunately both addresses do not work, but thanks anyway! > > Ulli > > Am Do., 13. Feb. 2025 um 10:28 Uhr schrieb J. Peterson via cctalk < > cctalk(a)classiccmp.org>: > > > This link has an update from 2023, along with an email address. > > > > https://www.pdp-11.nl/fieldguide.html > > > > On 2/13/2025 12:24 AM, Hans-Ulrich Hölscher via cctalk wrote: > > > Megan Gentry > > > -- Michael Thompson --===============2061605442744294530==-- From paul@frixxon.co.uk Thu Feb 13 18:22:24 2025 From: Paul Flo Williams To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 17:35:42 +0000 Message-ID: <20250213173542.768d7ea6@chopoc.localdomain> In-Reply-To: <6f8b1c04-5cac-4f94-aae6-b53baa8f61c1@saccade.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7001470172989715065==" --===============7001470172989715065== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 13 Feb 2025 01:13:26 -0800 "J. Peterson via cctalk" wrote: > This link has an update from 2023, along with an email address. > > https://www.pdp-11.nl/fieldguide.html Megan used to be one of the maintainers of that list, but I don't think that was recent. She renewed her ham radio license in 2020 for callsign KB1FCA but, other than that, you may need to send her an actual letter to her address in Leominster, MA. --===============7001470172989715065==-- From g4ajq1@gmail.com Thu Feb 13 18:41:56 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 13:41:47 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8308116388773402086==" --===============8308116388773402086== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-13 12:11, Michael Thompson via cctalk wrote: > Try Gentry, Megan or"mbg2(a)verizon.net" < > mbg2(a)verizon.net> > > On Thu, Feb 13, 2025 at 8:37 AM Hans-Ulrich Hölscher via cctalk < > cctalk(a)classiccmp.org> wrote: > >> Unfortunately both addresses do not work, but thanks anyway! >> >> Ulli >> >> Am Do., 13. Feb. 2025 um 10:28 Uhr schrieb J. Peterson via cctalk < >> cctalk(a)classiccmp.org>: >> >>> This link has an update from 2023, along with an email address. >>> >>> https://www.pdp-11.nl/fieldguide.html >>> >>> On 2/13/2025 12:24 AM, Hans-Ulrich Hölscher via cctalk wrote: >>>> Megan Gentry > Her FCC registration expires in April 2030, so it must have been renewed recently and has her Leominster (Assuming they have to give it a watchdog tick every some years as we do in  G-land) cheers Nigel -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============8308116388773402086==-- From paulkoning@comcast.net Thu Feb 13 18:49:21 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Looking for information on Megan Gentry, former RT-11 developer Date: Thu, 13 Feb 2025 13:49:02 -0500 Message-ID: <1BB98175-4319-468F-8306-CFC371D1DDDE@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5532135530889464716==" --===============5532135530889464716== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 13, 2025, at 1:41=E2=80=AFPM, Nigel Johnson Ham via cctalk wrote: >=20 > On 2025-02-13 12:11, Michael Thompson via cctalk wrote: >> Try Gentry, Megan or"mbg2(a)verizon.net" < >> mbg2(a)verizon.net> >>=20 >> On Thu, Feb 13, 2025 at 8:37=E2=80=AFAM Hans-Ulrich H=C3=B6lscher via ccta= lk < >> cctalk(a)classiccmp.org> wrote: >>=20 >>> Unfortunately both addresses do not work, but thanks anyway! >>>=20 >>> Ulli >>>=20 >>> Am Do., 13. Feb. 2025 um 10:28 Uhr schrieb J. Peterson via cctalk < >>> cctalk(a)classiccmp.org>: >>>=20 >>>> This link has an update from 2023, along with an email address. >>>>=20 >>>> https://www.pdp-11.nl/fieldguide.html >>>>=20 >>>> On 2/13/2025 12:24 AM, Hans-Ulrich H=C3=B6lscher via cctalk wrote: >>>>> Megan Gentry >>=20 > Her FCC registration expires in April 2030, so it must have been renewed re= cently and has her Leominster >=20 > (Assuming they have to give it a watchdog tick every some years as we do in= G-land) >=20 > cheers >=20 > Nigel US licenses are good for 10 years. paul --===============5532135530889464716==-- From rickb@bensene.com Thu Feb 13 23:44:41 2025 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 23:44:27 +0000 Message-ID: <495f63442c444ebdbeeb21f46d7ecf07@bensene.com> In-Reply-To: <6e7d0aef4e35419b8e54d31aa0f5489a@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4091390791148648230==" --===============4091390791148648230== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Correction to my posting of 2/10/2025 There was a company called Xircom that made parallel port modems. These were = full modems that were small enough that they plugged into a laptop serial port, and got their power from the laptop via the external mouse/keyb= oard port. They had a feed-though connector so you could still connect and e= xternal mouse/keyboard if you wanted. ... -Rick --===============4091390791148648230==-- From imp@bsdimp.com Thu Feb 13 23:50:34 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 16:50:17 -0700 Message-ID: In-Reply-To: <495f63442c444ebdbeeb21f46d7ecf07@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5029680758126521277==" --===============5029680758126521277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2025, 4:44=E2=80=AFPM Rick Bensene via cctalk wrote: > Correction to my posting of 2/10/2025 > > > > There was a company called Xircom that made parallel port modems. These > were full modems that were small enough that they plugged into a laptop > serial port, and got their power from the laptop via the > external mouse/keyboard port. They had a feed-though connector so you > could still connect and external mouse/keyboard if you wanted. ... > So which is it? My memory of the time was they were RS-233 devices that got their power from the keyboard port via a pass through cable. If they were parallel port, the PP provides enough power... Xircom also had parallel port ethernet products... I never saw a modem that was connected that way from them. Warner > > -Rick > > > --===============5029680758126521277==-- From henry.r.bent@gmail.com Thu Feb 13 23:54:30 2025 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 18:54:11 -0500 Message-ID: In-Reply-To: <495f63442c444ebdbeeb21f46d7ecf07@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8725719880606877872==" --===============8725719880606877872== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 13 Feb 2025 at 18:44, Rick Bensene via cctalk wrote: > > There was a company called Xircom that made parallel port modems. These > were full modems that were small enough that they plugged into a laptop > serial port, and got their power from the laptop via the > external mouse/keyboard port. They had a feed-though connector so you > could still connect and external mouse/keyboard if you wanted. ... > I remember those, and when I went searching to look for more information on them I found something I hadn't stumbled on before - apparently Xircom made a parallel port ethernet adapter. It must have been pretty painful. The parallel port wasn't a great high speed interface; I unfortunately had a parallel port ZIP drive and it was a dog. -Henry --===============8725719880606877872==-- From glen.slick@gmail.com Fri Feb 14 00:24:31 2025 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 16:24:13 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4029031684756812841==" --===============4029031684756812841== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2025 at 3:50=E2=80=AFPM Warner Losh via cctalk wrote: > > On Thu, Feb 13, 2025, 4:44=E2=80=AFPM Rick Bensene via cctalk > wrote: > > > Correction to my posting of 2/10/2025 > > > > > > > > There was a company called Xircom that made parallel port modems. These > > were full modems that were small enough that they plugged into a laptop > > serial port, and got their power from the laptop via the > > external mouse/keyboard port. They had a feed-though connector so you > > could still connect and external mouse/keyboard if you wanted. ... > > > > So which is it? My memory of the time was they were RS-233 devices that got > their power from the keyboard port via a pass through cable. If they were > parallel port, the PP provides enough power... > > Xircom also had parallel port ethernet products... The Xircom PE3 (Pocket Ethernet Adapter III) needed power either from a PS/2 port or an AC adapter. Phantom Power Cable The Phantom Power Cable supplied with the Pocket Ethernet Adapter III allows you to power all Adapter models (except PE3-10BX) directly from a PS/2-style C6-pin mini-DIN) mouse port on your computer. The cable includes a pass-through connector that allows a mouse to be plugged in on top of the Phantom Power Cable connection. Wall-Mount AC Power Adapter AC power adapter specifications are listed below for the US.A. and Canada Input Voltage: 120 VAC / 60 Hz Output Voltage: 12 VDC unregulated, 300ma (500ma for Model PE3-10BX) https://www.minuszerodegrees.net/manuals/Xircom/Xircom%20Pocket%20Ethernet%20= Adapter%20III%20(PE3)%20-%20Users%20Guide%20-%20NOV95.pdf https://www.brutman.com/Dos_Networking/xircom_pe3.html --===============4029031684756812841==-- From rickb@bensene.com Fri Feb 14 00:32:53 2025 From: Rick Bensene To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 00:32:43 +0000 Message-ID: <1438ef747a424cff88515f03ef6cdca8@bensene.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1800205505421412963==" --===============1800205505421412963== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Henry wrote: > I remember those, and when I went searching to look for more information on= them I found something I > hadn't stumbled on before - apparently Xircom mad= e a parallel port Ethernet adapter.=C2=A0 It must have > been pretty painful.=C2=A0 The parallel port wasn't a great high speed inte= rface=E2=80=A6 ---- Yes, I have one of those parallel port Ethernet devices too. But, remember, = back at that time, Ethernet was commonly 10Mb/Sec. I think that 100Mb/Sec wa= s only located in high-end datacenters and was very expensive. For a laptop = that didn=E2=80=99t have a PCMCIA port, and you wanted it on an Ethernet netw= ork, this was an acceptable way to go. Performance wasn=E2=80=99t great, but= most of the time laptops like this were used for TELNET connections to other= hosts on the local network for =E2=80=9CGREEN SCREEN=E2=80=9D type applicati= ons that ran entirely on the remote host. Performance in such cases wasn=E2= =80=99t nearly as much of a concern as it would be in the not too distant fut= ure. I will try to find my Xircom parallel port Modem and Ethernet adapters in a b= ox somewhere in my storage area and take a photo of them. If I can find them= , I=E2=80=99ll post a link here to the photos so those in disbelief can see t= hem. -Rick From: Henry Bent [mailto:henry.r.bent(a)gmail.com]=20 Sent: Thursday, February 13, 2025 3:54 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Rick Bensene Subject: Re: [cctalk] Re: RS232 - parallel modems!? --===============1800205505421412963==-- From imp@bsdimp.com Fri Feb 14 00:43:27 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 17:43:10 -0700 Message-ID: In-Reply-To: <1438ef747a424cff88515f03ef6cdca8@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0833518990031048565==" --===============0833518990031048565== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2025, 5:32=E2=80=AFPM Rick Bensene via cctalk wrote: > Henry wrote: > > > I remember those, and when I went searching to look for more information > on them I found something I > hadn't stumbled on before - apparently Xircom > made a parallel port Ethernet adapter. It must have > > been pretty painful. The parallel port wasn't a great high speed > interface=E2=80=A6 > > ---- > > Yes, I have one of those parallel port Ethernet devices too. But, > remember, back at that time, Ethernet was commonly 10Mb/Sec. I think that > 100Mb/Sec was only located in high-end datacenters and was very expensive. > For a laptop that didn=E2=80=99t have a PCMCIA port, and you wanted it on an > Ethernet network, this was an acceptable way to go. Performance wasn=E2=80= =99t > great, but most of the time laptops like this were used for TELNET > connections to other hosts on the local network for =E2=80=9CGREEN SCREEN= =E2=80=9D type > applications that ran entirely on the remote host. Performance in such > cases wasn=E2=80=99t nearly as much of a concern as it would be in the not = too > distant future. > > I will try to find my Xircom parallel port Modem and Ethernet adapters in > a box somewhere in my storage area and take a photo of them. If I can find > them, I=E2=80=99ll post a link here to the photos so those in disbelief can= see > them. > That would be cool. I found this link for all the networking gear: https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html And found parallel port multiplexers. Do you have drivers for them? Warner -Rick > > > > From: Henry Bent [mailto:henry.r.bent(a)gmail.com] > Sent: Thursday, February 13, 2025 3:54 PM > To: General Discussion: On-Topic and Off-Topic Posts < > cctalk(a)classiccmp.org> > Cc: Rick Bensene > Subject: Re: [cctalk] Re: RS232 - parallel modems!? > --===============0833518990031048565==-- From paulkoning@comcast.net Fri Feb 14 00:53:12 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 19:52:54 -0500 Message-ID: <35F24DAF-3C11-41A2-BEBD-0860A28B8C97@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4023232036378595261==" --===============4023232036378595261== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 13, 2025, at 6:54=E2=80=AFPM, Henry Bent via cctalk wrote: >=20 > On Thu, 13 Feb 2025 at 18:44, Rick Bensene via cctalk > wrote: >=20 >>=20 >> There was a company called Xircom that made parallel port modems. These >> were full modems that were small enough that they plugged into a laptop >> serial port, and got their power from the laptop via the >> external mouse/keyboard port. They had a feed-though connector so you >> could still connect and external mouse/keyboard if you wanted. ... >>=20 >=20 > I remember those, and when I went searching to look for more information on > them I found something I hadn't stumbled on before - apparently Xircom made > a parallel port ethernet adapter. It must have been pretty painful. The > parallel port wasn't a great high speed interface; I unfortunately had a > parallel port ZIP drive and it was a dog. >=20 > -Henry The later parallel ports include several faster modes than the original one. = The best of these is "EPP" mode which is fully bidirectional, with interlock= ed high speed handshakes. I think you can get fairly close to (original) Et= hernet speeds with those. I once built a software-defined radio using one of= those for its baseband data/control interface, it worked quite well. The st= ate machine fits in a small CPLD (Lattice isp2032). paul --===============4023232036378595261==-- From glen.slick@gmail.com Fri Feb 14 01:14:16 2025 From: Glen Slick To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 17:13:59 -0800 Message-ID: In-Reply-To: <1438ef747a424cff88515f03ef6cdca8@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8632685332497976358==" --===============8632685332497976358== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2025 at 4:32=E2=80=AFPM Rick Bensene via cctalk wrote: > > I will try to find my Xircom parallel port Modem and Ethernet adapters in a= box somewhere in my storage area and take a photo of them. If I can find th= em, I=E2=80=99ll post a link here to the photos so those in disbelief can see= them. I was initially skeptical that Xircom made a parallel port modem. Apparently they actually did, at least a combo Ethernet+Modem. Don't know if they also made a modem only version. https://archive.org/details/pem113 Welcome to a new level of connectivity convenience. Xircom's Pocket Ethernet+Modem provides PE3 equivalent Ethernet LAN adapter functionality for DOS and Windows combined with a fully featured V.32bis modem. The PEM is available in two models, the PEM-10BT(for the 10BASE-T twisted pair with RJ-45 connector) and the PEM-10B2(for the 10BASE-2 thin Coax with BNC connector). --===============8632685332497976358==-- From chris@groessler.org Fri Feb 14 01:20:00 2025 From: Christian Groessler To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 01:47:15 +0100 Message-ID: <24a4ed84-b9e2-4117-a8fa-db677748c07e@groessler.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0200680863767939412==" --===============0200680863767939412== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/14/25 1:43 AM, Warner Losh via cctalk wrote: > > That would be cool. I found this link for all the networking gear: > https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html > And found parallel port multiplexers. > > Do you have drivers for them? I think DOS packet drivers supported the PE3. I haven't found the source code of it, although the packet drivers are GPL and source should be available (unless Xircom cheated). regards, chris --===============0200680863767939412==-- From jeffrey@vcfed.org Fri Feb 14 02:37:09 2025 From: Jeffrey Brace To: cctalk@classiccmp.org Subject: [cctalk] Mid-Atlantic Retro Computing Hobbyists Hack-a-Thon Date: Thu, 13 Feb 2025 21:36:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6321491571014998091==" --===============6321491571014998091== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit DATE: March 8 & 9, 2025 LOCATION: InfoAge Science and History Museums, Wall, NJ Fee: None *More info here*: https://vcfed.org/2025/02/13/march-hack-a-thon/ --===============6321491571014998091==-- From brain@jbrain.com Fri Feb 14 04:16:46 2025 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Thu, 13 Feb 2025 22:16:38 -0600 Message-ID: <778f1cae-f574-4615-ba08-1ca2d3c0551e@jbrain.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4243523552855604615==" --===============4243523552855604615== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/13/2025 5:54 PM, Henry Bent via cctalk wrote: > On Thu, 13 Feb 2025 at 18:44, Rick Bensene via cctalk > wrote: > >> There was a company called Xircom that made parallel port modems. These >> were full modems that were small enough that they plugged into a laptop >> serial port, and got their power from the laptop via the >> external mouse/keyboard port. They had a feed-though connector so you >> could still connect and external mouse/keyboard if you wanted. ... >> > I remember those, and when I went searching to look for more information on > them I found something I hadn't stumbled on before - apparently Xircom made > a parallel port ethernet adapter. It must have been pretty painful. The > parallel port wasn't a great high speed interface; I unfortunately had a > parallel port ZIP drive and it was a dog. > > -Henry Yep, I used both the PEII and the PE3. https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html Hard to install on a parallel port, due to the little thumbscrews, but=20 worked fine The PE3 was awesome, though, for a device without Ethernet.=C2=A0 The=20 track-like thumbscrew was awesome if you needed to detach the unit. At=20 the time, I was using a PC110 IBM Pocket COMputer with two docking=20 stations and some store and forward packet SW to have my personal data=20 at work and home. Using the PEIII on the dock was so helpful.=C2=A0 The PC110= =20 had 2 Type I-II/1 Type III PCMCIA slot, and it needed the whole slot for=20 the 260MB PCMCIA drive, so using a PC card for Ethernet was not possible. Not sure if that dock had EPP, but even the simple Parallel port was=20 acceptable on speed for me, even for early Windows 95 web browsing. The link above shows they made a ArcNet adapter, a Token Ring Adapter,=20 and it says there was an EtherTalk adapter, not sure of the use case. Here's a link to some drivers for the PEIII: https://retrocmp.de/transfer/xircom-pe3.htm Never saw the combo modem+ethernet, but the I was impressed by the=20 PEIII.=C2=A0 When I finally was able to get a Type II HDD, I was able to use = a PC card Ethernet adapter and the PEIII I think got shared with someone=20 at a show. Jim --=20 Jim Brain brain(a)jbrain.com www.jbrain.com --===============4243523552855604615==-- From billdegnan@gmail.com Fri Feb 14 15:27:32 2025 From: Bill Degnan To: cctalk@classiccmp.org Subject: [cctalk] Re: Mid-Atlantic Retro Computing Hobbyists Hack-a-Thon Date: Fri, 14 Feb 2025 10:27:15 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2211798178784048792==" --===============2211798178784048792== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I am surprised S-100 8-bit systems are not explicitly listed and that a person needs to get approval for things like the Altair, Sol, Imsai to participate. But that's a sign of the hobby kind of moving on from 70s to 80s focus. Bill On Thu, Feb 13, 2025 at 9:43 PM Jeffrey Brace via cctalk < cctalk(a)classiccmp.org> wrote: > DATE: March 8 & 9, 2025 > > LOCATION: InfoAge Science and History Museums, Wall, NJ > > Fee: None > *More info here*: https://vcfed.org/2025/02/13/march-hack-a-thon/ > --===============2211798178784048792==-- From lproven@gmail.com Fri Feb 14 15:38:47 2025 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Fri, 14 Feb 2025 16:38:31 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5522074039288634709==" --===============5522074039288634709== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 4 Feb 2025 at 00:55, ben via cctalk wrote: > PS. is me or just the internet browsing getting so full of ads > and questionable redirects that on can't use it any more. FWIW, I find the combination of Firefox and the uBlock Origin extension stops me seeing most of them. I also have Privoxy installed and configured, but I think nobody tests it any more in Ubuntu. It doesn't seem to work in 22.04 or 24.04. -- 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 --===============5522074039288634709==-- From artgodwin@gmail.com Fri Feb 14 15:57:08 2025 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Fri, 14 Feb 2025 15:56:52 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4062982782582482050==" --===============4062982782582482050== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I can't believe people do use it any more without filtering. I've used an ad-blocking web browser for some years but I occasionally see the real thing when setting up a new machine. Absurd. On Fri, Feb 14, 2025 at 3:48 PM Liam Proven via cctalk < cctalk(a)classiccmp.org> wrote: > On Tue, 4 Feb 2025 at 00:55, ben via cctalk wrote: > > > PS. is me or just the internet browsing getting so full of ads > > and questionable redirects that on can't use it any more. > > FWIW, I find the combination of Firefox and the uBlock Origin > extension stops me seeing most of them. I also have Privoxy installed > and configured, but I think nobody tests it any more in Ubuntu. It > doesn't seem to work in 22.04 or 24.04. > > -- > 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 > --===============4062982782582482050==-- From elson@pico-systems.com Fri Feb 14 15:58:42 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 09:58:36 -0600 Message-ID: <1e240486-1bfd-edc2-e19c-9010c8ed3a00@pico-systems.com> In-Reply-To: <35F24DAF-3C11-41A2-BEBD-0860A28B8C97@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1242306575855168451==" --===============1242306575855168451== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/13/25 18:52, Paul Koning via cctalk wrote: > > The later parallel ports include several faster modes than the original one= . The best of these is "EPP" mode which is fully bidirectional, with interlo= cked high speed handshakes. I think you can get fairly close to (original) = Ethernet speeds with those. I once built a software-defined radio using one = of those for its baseband data/control interface, it worked quite well. The = state machine fits in a small CPLD (Lattice isp2032). > I'm pretty much an expert on EPP mode operation.=C2=A0 (I make a=20 line of CNC motion control boards that interface to the PC=20 via EPP-mode parallel port.)=C2=A0 Mostly, you can get up to=20 about 1 mbyte /second with this.With no cable between the=20 external device and PC, it might go a little faster. Jon --===============1242306575855168451==-- From lproven@gmail.com Fri Feb 14 16:01:57 2025 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 17:01:39 +0100 Message-ID: In-Reply-To: <6e7d0aef4e35419b8e54d31aa0f5489a@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2863663401304292398==" --===============2863663401304292398== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, 10 Feb 2025 at 23:48, Rick Bensene via cctalk wrote: > > There was a company called Xircom that made parallel port modems. These wer= e full modems that were small enough that they plugged into a laptop serial p= ort, and got their power from the laptop via the external mouse/keyboard port. Er, is it possible that you are mixing up modems with Ethernet adaptors? Xircom was well known for parallel-port Ethernet adaptors, such as seen here: https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html I supported several and they worked very well, even with Linux. With an ECP/EPP+ port they could be quite fast. https://en.wikipedia.org/wiki/Parallel_port#EPP_and_ECP > After laptops started having PCMCIA ports, Xircom made some modem cards in= PCMCIA form-factor, and they had a little dongle that plugged into them that= provided the RJ11 jack to plug the phone line into. Sure, many companies did. Xircom was far from alone. Most had dongles. Indeed one of the only type II cards that _didn't_ were 3Com XJACK cards. https://en.wikipedia.org/wiki/XJACK > I think these could go up to 14.4Kb, maybe more. (!) Far more. I am not sure I ever saw one that slow. 28.8 was normal, 33.6 briefly, and the one I used longest was 56K. For me the nifty device was their RealPort range which needed a type III slot: https://docs.rs-online.com/04a6/0900766b8002b85f.pdf They also did very clever "Realport 2" cards which could be mirrored, one inserted upside down, so you could insert 2 of them into a pair of type 2 slots in one physical type 3 slot *with one running upside down,* for 2 x full-sized connectors. https://www.ebay.com/itm/312549616539 Xircom was also one of vanishingly few companies to offer working USB drivers _for Windows NT 4_ -- an OS that did not support USB. https://forums.scotsnewsletter.com/index.php?/topic/7054-usb-on-nt4/ -- 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 --===============2863663401304292398==-- From lewissa78@gmail.com Fri Feb 14 17:27:09 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 11:26:52 -0600 Message-ID: In-Reply-To: <1438ef747a424cff88515f03ef6cdca8@bensene.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8324690538337903096==" --===============8324690538337903096== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Rick Bensene: > I will try to find my Xircom parallel port Modem and Ethernet adapters in > a box somewhere in my storage area and take a photo of them. If I can find > them, I’ll post a link here to the photos so those in disbelief can see > them. That'd be neat to see, if you do find the Xircom parallel modem. I've seen combo ones and their "parallel-ethernet" devices (which seem to go for quite a premium these days), but not the modem only. Suppose they weren't too popular, as even laptops started to have built in modems. These days, I do use an SDLPT, that lets you use SD-cards to transfer data into a system over the parallel port. I suppose that's the same general principle (of read/writing one full byte at a time to a device). I haven't measured its performance yet (but would characterize it as being comparable to a physical 3.5" floppy disk drive kind of performance - I think copying Quake took over 40 minutes, something like that; but I'd like to get more accurate about it, down to an actual bytes-per-second rate). Measuring that might give me an answer on how fast something like Laplink/Interlink cable should be able to perform. As another experiment, I'll drop that ~7MHz 16550 serial card into a 386, and see if I can get a 386 to push data out on RS-232 faster than 115200. It should, but we'll see! And I think I will do an RS-232 themed talk in June VCF, if a spot is still open - I think I have enough now to make it interesting. One area I'm a little stuck on is verifying that anyone actually did make an RS-232 keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that as RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to the PDP-1, but might not be accurate to call that RS-232 (but can't a current loop based thing be adapted to voltage?). I thought the POLY-88 keyboard was RS-232, but it'll be awhile before I can get back to that equipment. -Steve On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk < cctalk(a)classiccmp.org> wrote: > Henry wrote: > > > I remember those, and when I went searching to look for more information > on them I found something I > hadn't stumbled on before - apparently Xircom > made a parallel port Ethernet adapter. It must have > > been pretty painful. The parallel port wasn't a great high speed > interface… > > ---- > > Yes, I have one of those parallel port Ethernet devices too. But, > remember, back at that time, Ethernet was commonly 10Mb/Sec. I think that > 100Mb/Sec was only located in high-end datacenters and was very expensive. > For a laptop that didn’t have a PCMCIA port, and you wanted it on an > Ethernet network, this was an acceptable way to go. Performance wasn’t > great, but most of the time laptops like this were used for TELNET > connections to other hosts on the local network for “GREEN SCREEN” type > applications that ran entirely on the remote host. Performance in such > cases wasn’t nearly as much of a concern as it would be in the not too > distant future. > > I will try to find my Xircom parallel port Modem and Ethernet adapters in > a box somewhere in my storage area and take a photo of them. If I can find > them, I’ll post a link here to the photos so those in disbelief can see > them. > > -Rick > > > > From: Henry Bent [mailto:henry.r.bent(a)gmail.com] > Sent: Thursday, February 13, 2025 3:54 PM > To: General Discussion: On-Topic and Off-Topic Posts < > cctalk(a)classiccmp.org> > Cc: Rick Bensene > Subject: Re: [cctalk] Re: RS232 - parallel modems!? > --===============8324690538337903096==-- From commodorejohn@gmail.com Fri Feb 14 18:46:34 2025 From: John To: cctalk@classiccmp.org Subject: [cctalk] Ad-blocking (was Re: Open source a panacea?) Date: Fri, 14 Feb 2025 10:46:23 -0800 Message-ID: <20250214104623.000056bf@gmail.com> In-Reply-To: <173955600761.1298.1966974965405220192@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0084407914939488012==" --===============0084407914939488012== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 14 Feb 2025 12:00:07 -0600 cctalk-request(a)classiccmp.org wrote: > I can't believe people do use it any more without filtering. I've > used an ad-blocking web browser for some years but I occasionally see > the real thing when setting up a new machine. Absurd. It really is astonishing how bad it's gotten - fully the equal of the early '00s when sites might just spawn a dozen pop-ups and only one of the major browsers let you block them, only now there's a pile of JS mining crypto in the background, to boot :/ Been running with NoScript and an ad-blocker as my standard configuration for many, many years now, but it's always sobering to get a look at what other people see... --===============0084407914939488012==-- From mattislind@gmail.com Fri Feb 14 20:51:33 2025 From: Mattis Lind To: cctalk@classiccmp.org Subject: [cctalk] NCR EM-D2 Card reader manual Date: Fri, 14 Feb 2025 21:50:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5311045962618919810==" --===============5311045962618919810== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am about to get a NCR EM-D2 card reader, but I can not find much documentation on it. Is there anyone here that has documentation on it? Preferably a maintenance manual. A couple of years ago (perhaps in February 2021 if one studies how they indexed the file in their storage) there was a sale of a maintenance manual on Ebay according to the below Worthpoint link. https://www.worthpoint.com/worthopedia/1965-ncr-em-d2-punched-card-reader-378= 6730455 Did anyone here buy this manual? I am very interested in a scan of this manual or possibly to purchase the manual. /Mattis --===============5311045962618919810==-- From cctalk@emailtoilet.com Fri Feb 14 21:11:37 2025 From: Donald Whittemore To: cctalk@classiccmp.org Subject: [cctalk] Re: Ad-blocking (was Re: Open source a panacea?) Date: Fri, 14 Feb 2025 21:11:33 +0000 Message-ID: <173956749397.1304.2550346510289595809@classiccmp.org> In-Reply-To: <20250214104623.000056bf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7862611310348557819==" --===============7862611310348557819== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Not sure where you are going. =F0=9F=98=8A I use Safari on my iPad and Firefo= x on my PC. I have no real problem with pop-ups. --===============7862611310348557819==-- From barythrin@gmail.com Fri Feb 14 21:58:46 2025 From: John Herron To: cctalk@classiccmp.org Subject: [cctalk] Re: Ad-blocking (was Re: Open source a panacea?) Date: Fri, 14 Feb 2025 15:58:29 -0600 Message-ID: In-Reply-To: <173956749397.1304.2550346510289595809@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5544833540816018227==" --===============5544833540816018227== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I forget how bad things are without any adblockers, such as almost the entire first page of google results are paid/spam results vs the actual search. I don't see that with the filters I have on so I get to naively sift through the more and more incorrect opinions to my question, but at least I can keep ads and false results to a minimum. I've been using noscript for such a long time but honestly it just breaks every website and I have to play whack-a-mole with 30 different URLs to get things to work right, but I still use it with ublock origin and have a mostly good experience. On Fri, Feb 14, 2025 at 3:11 PM Donald Whittemore via cctalk < cctalk(a)classiccmp.org> wrote: > Not sure where you are going. 😊 I use Safari on my iPad and Firefox on my > PC. I have no real problem with pop-ups. > --===============5544833540816018227==-- From mhs.stein@gmail.com Fri Feb 14 23:28:13 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 18:27:54 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4316625947457310690==" --===============4316625947457310690== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I believe that at least Kaypro used a TTL form of RS-232 for the keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a keyboard in distant days. On Fri, Feb 14, 2025 at 12:27=E2=80=AFPM Steve Lewis via cctalk < cctalk(a)classiccmp.org> wrote: > Rick Bensene: > > > I will try to find my Xircom parallel port Modem and Ethernet adapters in > > a box somewhere in my storage area and take a photo of them. If I can > find > > them, I=E2=80=99ll post a link here to the photos so those in disbelief c= an see > > them. > > > That'd be neat to see, if you do find the Xircom parallel modem. I've seen > combo ones and their "parallel-ethernet" devices (which seem to go for > quite a premium these days), but not the modem only. Suppose they weren't > too popular, as even laptops started to have built in modems. > > These days, I do use an SDLPT, that lets you use SD-cards to transfer data > into a system over the parallel port. I suppose that's the same general > principle (of read/writing one full byte at a time to a device). I > haven't measured its performance yet (but would characterize it as being > comparable to a physical 3.5" floppy disk drive kind of performance - I > think copying Quake took over 40 minutes, something like that; but I'd like > to get more accurate about it, down to an actual bytes-per-second rate). > Measuring that might give me an answer on how fast something like > Laplink/Interlink cable should be able to perform. > > As another experiment, I'll drop that ~7MHz 16550 serial card into a 386, > and see if I can get a 386 to push data out on RS-232 faster than 115200. > It should, but we'll see! > > > And I think I will do an RS-232 themed talk in June VCF, if a spot is still > open - I think I have enough now to make it interesting. One area I'm a > little stuck on is verifying that anyone actually did make an RS-232 > keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that as > RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to the > PDP-1, but might not be accurate to call that RS-232 (but can't a current > loop based thing be adapted to voltage?). I thought the POLY-88 keyboard > was RS-232, but it'll be awhile before I can get back to that equipment. > > > -Steve > > > > On Thu, Feb 13, 2025 at 6:32=E2=80=AFPM Rick Bensene via cctalk < > cctalk(a)classiccmp.org> wrote: > > > Henry wrote: > > > > > I remember those, and when I went searching to look for more > information > > on them I found something I > hadn't stumbled on before - apparently > Xircom > > made a parallel port Ethernet adapter. It must have > > > been pretty painful. The parallel port wasn't a great high speed > > interface=E2=80=A6 > > > > ---- > > > > Yes, I have one of those parallel port Ethernet devices too. But, > > remember, back at that time, Ethernet was commonly 10Mb/Sec. I think > that > > 100Mb/Sec was only located in high-end datacenters and was very > expensive. > > For a laptop that didn=E2=80=99t have a PCMCIA port, and you wanted it on= an > > Ethernet network, this was an acceptable way to go. Performance wasn=E2= =80=99t > > great, but most of the time laptops like this were used for TELNET > > connections to other hosts on the local network for =E2=80=9CGREEN SCREEN= =E2=80=9D type > > applications that ran entirely on the remote host. Performance in such > > cases wasn=E2=80=99t nearly as much of a concern as it would be in the no= t too > > distant future. > > > > I will try to find my Xircom parallel port Modem and Ethernet adapters in > > a box somewhere in my storage area and take a photo of them. If I can > find > > them, I=E2=80=99ll post a link here to the photos so those in disbelief c= an see > > them. > > > > -Rick > > > > > > > > From: Henry Bent [mailto:henry.r.bent(a)gmail.com] > > Sent: Thursday, February 13, 2025 3:54 PM > > To: General Discussion: On-Topic and Off-Topic Posts < > > cctalk(a)classiccmp.org> > > Cc: Rick Bensene > > Subject: Re: [cctalk] Re: RS232 - parallel modems!? > > > --===============4316625947457310690==-- From lewissa78@gmail.com Sat Feb 15 05:43:55 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Fri, 14 Feb 2025 23:43:38 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2015634676266775548==" --===============2015634676266775548== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom" 4-pin wire (one of them being 5V power). So just level-shift the TX/RX pins through a MAX232 IC and it would talk to another R-232 system at 300 baud eh? Might have to seek out a lone Kaypro keyboard to give it a try. I suspect some of the "serial style" mid-1980s IBM Model M keyboards are similar. But I'm still wondering if anyone used this concept in the late 1960s - teletypes were expensive, flipping switches was tedious, so keyboard alternates were hot items by early 70's (hence the TVT popularity). On Fri, Feb 14, 2025 at 5:28=E2=80=AFPM Mike Stein wr= ote: > I believe that at least Kaypro used a TTL form of RS-232 for the keyboard; > in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a keyboard in > distant days. > > On Fri, Feb 14, 2025 at 12:27=E2=80=AFPM Steve Lewis via cctalk < > cctalk(a)classiccmp.org> wrote: > >> Rick Bensene: >> >> > I will try to find my Xircom parallel port Modem and Ethernet adapters >> in >> > a box somewhere in my storage area and take a photo of them. If I can >> find >> > them, I=E2=80=99ll post a link here to the photos so those in disbelief = can see >> > them. >> >> >> That'd be neat to see, if you do find the Xircom parallel modem. I've >> seen >> combo ones and their "parallel-ethernet" devices (which seem to go for >> quite a premium these days), but not the modem only. Suppose they weren't >> too popular, as even laptops started to have built in modems. >> >> These days, I do use an SDLPT, that lets you use SD-cards to transfer data >> into a system over the parallel port. I suppose that's the same general >> principle (of read/writing one full byte at a time to a device). I >> haven't measured its performance yet (but would characterize it as being >> comparable to a physical 3.5" floppy disk drive kind of performance - I >> think copying Quake took over 40 minutes, something like that; but I'd >> like >> to get more accurate about it, down to an actual bytes-per-second rate). >> Measuring that might give me an answer on how fast something like >> Laplink/Interlink cable should be able to perform. >> >> As another experiment, I'll drop that ~7MHz 16550 serial card into a 386, >> and see if I can get a 386 to push data out on RS-232 faster than 115200. >> It should, but we'll see! >> >> >> And I think I will do an RS-232 themed talk in June VCF, if a spot is >> still >> open - I think I have enough now to make it interesting. One area I'm a >> little stuck on is verifying that anyone actually did make an RS-232 >> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that as >> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to >> the >> PDP-1, but might not be accurate to call that RS-232 (but can't a current >> loop based thing be adapted to voltage?). I thought the POLY-88 keyboard >> was RS-232, but it'll be awhile before I can get back to that equipment. >> >> >> -Steve >> >> >> >> On Thu, Feb 13, 2025 at 6:32=E2=80=AFPM Rick Bensene via cctalk < >> cctalk(a)classiccmp.org> wrote: >> >> > Henry wrote: >> > >> > > I remember those, and when I went searching to look for more >> information >> > on them I found something I > hadn't stumbled on before - apparently >> Xircom >> > made a parallel port Ethernet adapter. It must have >> > > been pretty painful. The parallel port wasn't a great high speed >> > interface=E2=80=A6 >> > >> > ---- >> > >> > Yes, I have one of those parallel port Ethernet devices too. But, >> > remember, back at that time, Ethernet was commonly 10Mb/Sec. I think >> that >> > 100Mb/Sec was only located in high-end datacenters and was very >> expensive. >> > For a laptop that didn=E2=80=99t have a PCMCIA port, and you wanted it o= n an >> > Ethernet network, this was an acceptable way to go. Performance wasn=E2= =80=99t >> > great, but most of the time laptops like this were used for TELNET >> > connections to other hosts on the local network for =E2=80=9CGREEN SCREE= N=E2=80=9D type >> > applications that ran entirely on the remote host. Performance in such >> > cases wasn=E2=80=99t nearly as much of a concern as it would be in the n= ot too >> > distant future. >> > >> > I will try to find my Xircom parallel port Modem and Ethernet adapters >> in >> > a box somewhere in my storage area and take a photo of them. If I can >> find >> > them, I=E2=80=99ll post a link here to the photos so those in disbelief = can see >> > them. >> > >> > -Rick >> > >> > >> > >> > From: Henry Bent [mailto:henry.r.bent(a)gmail.com] >> > Sent: Thursday, February 13, 2025 3:54 PM >> > To: General Discussion: On-Topic and Off-Topic Posts < >> > cctalk(a)classiccmp.org> >> > Cc: Rick Bensene >> > Subject: Re: [cctalk] Re: RS232 - parallel modems!? >> > >> > --===============2015634676266775548==-- From ethan.dicks@gmail.com Sat Feb 15 08:46:17 2025 From: Ethan Dicks To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sat, 15 Feb 2025 03:46:02 -0500 Message-ID: In-Reply-To: <24a4ed84-b9e2-4117-a8fa-db677748c07e@groessler.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3276669397236806282==" --===============3276669397236806282== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Thu, Feb 13, 2025 at 8:20 PM Christian Groessler via cctalk wrote: > On 2/14/25 1:43 AM, Warner Losh via cctalk wrote: > > > > That would be cool. I found this link for all the networking gear: > > https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html > > Do you have drivers for them? > > I think DOS packet drivers supported the PE3. Yes, They did. I used them in the 90s. We used them at work in 1995-97 for laptops to go out in the field before most laptops had PCMCIA (we were still supporting 386 and 486 laptops at the time, very few of them were good enough to run Windows 95). At home, I have a Zenith dual-"720K" 8088 laptop and I used to mostly use it as a telnet "terminal" with DOS 3.3, Kermit, and the PE3 packet driver. > I haven't found the source > code of it, although the packet drivers are GPL and source should be > available (unless Xircom cheated). I don't have source AFAIK. I'm in favor of it, but I was unlikely to be rebuilding DOS drivers at any time. Cheers, -ethan --===============3276669397236806282==-- From bduncan@beachnet.org Sat Feb 15 11:49:17 2025 From: Bill Duncan To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sat, 15 Feb 2025 04:10:03 -0500 Message-ID: <20250215091003.GA261815@linda> In-Reply-To: <4add8193-fb88-4eb1-934c-a7820bcbc1a3@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6605355436107106453==" --===============6605355436107106453== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Feb 03, 2025 at 06:09:28AM +0000, Chuck Guzis via cctalk wrote: > On 2/2/25 17:22, Will Cooke via cctalk wrote: > > > > > > Not quite lost. The 1802 crowd is doing amazing things. > > See https://groups.io/g/cosmacelf/message/33678 > > > > And if you know anything about the 1802, it's, uh, not so speedy. > > At its introduction,it was one of few static CMOS CPUs. You could run > it from batteries and stop the clock when not needed. Perfect for > telemetry. I think the Intersil 6100 was another, but required 12-bit > wide memory. > > --Chuck ..and it had a "sex" instruction. IMO, one of the original RISC cpus.. LoL.. -- Bill Duncan | http://billduncan.org/ bduncan(a)beachnet.org | - linux/unix/networking/cloud +1 416 697-9315 | - performance/reliability engineering, SRE --===============6605355436107106453==-- From classiccmp@fjl.co.uk Sat Feb 15 14:43:27 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Elliott Algol Date: Sat, 15 Feb 2025 14:43:15 +0000 Message-ID: <0fd5ac37-ad58-4b01-9f60-3402625ea70a@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4144419345147824323==" --===============4144419345147824323== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit As those of us with a few years will know, Tony Hoare (and Jill's) implementation of Algol 60 on the Elliott 803 was a highly significant event in the history of computer languages. It was the first practical commercial Algol compiler, launched block structures languages, and played a part in Elliott selling nearly 300 803B computers at a time when 300 computers was a big number. Obviously the US preferred Fortran and COBOL for commercial use, and there were other Algol compilers in some shape or other knocking about in universities. But I'd say this implementation put block structured programming into the mainstream. (And it was the first high level language I used, but that's beside the point). Now some kid on Wikipedia thinks it's not notable and is trying to delete it because he can't find much on it doing a Google search. Wikipedia may be sinking under activists and egos, but I think we need to put this misapprehension straight. Unfortunately we may be arguing with an idiot. https://en.wikipedia.org/wiki/Elliott_ALGOL If course, if anyone thinks it wasn't significant, that's an opinion too, but I'd like to hear why. Thanks, Frank. --===============4144419345147824323==-- From paulkoning@comcast.net Sat Feb 15 14:47:01 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sat, 15 Feb 2025 09:46:40 -0500 Message-ID: In-Reply-To: <20250215091003.GA261815@linda> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5222546254156292018==" --===============5222546254156292018== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 15, 2025, at 4:10=E2=80=AFAM, Bill Duncan via cctalk wrote: >=20 > On Mon, Feb 03, 2025 at 06:09:28AM +0000, Chuck Guzis via cctalk wrote: >> On 2/2/25 17:22, Will Cooke via cctalk wrote: >>>=20 >>>=20 >>> Not quite lost. The 1802 crowd is doing amazing things. >>> See https://groups.io/g/cosmacelf/message/33678 >>>=20 >>> And if you know anything about the 1802, it's, uh, not so speedy. >>=20 >> At its introduction,it was one of few static CMOS CPUs. You could run >> it from batteries and stop the clock when not needed. Perfect for >> telemetry. I think the Intersil 6100 was another, but required 12-bit >> wide memory. >>=20 >> --Chuck >=20 > ..and it had a "sex" instruction. The PDP-11 almost did, but it was caught before release and renamed ""SXT". > IMO, one of the original RISC cpus.. LoL.. I would apply that label to the CDC 6600 (1964). paul --===============5222546254156292018==-- From tdk.knight@gmail.com Sat Feb 15 14:52:10 2025 From: Adrian Stoness To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 08:51:53 -0600 Message-ID: In-Reply-To: <0fd5ac37-ad58-4b01-9f60-3402625ea70a@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6015514905609403753==" --===============6015514905609403753== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit wiki has always been this way. it has stricks standards if something doesnt fallow they clear it u need to start a talk thread under talk about this issue not just have a spat back and fourth deleting and reposting On Sat, Feb 15, 2025 at 8:43 AM Frank Leonhardt via cctalk < cctalk(a)classiccmp.org> wrote: > As those of us with a few years will know, Tony Hoare (and Jill's) > implementation of Algol 60 on the Elliott 803 was a highly significant > event in the history of computer languages. It was the first practical > commercial Algol compiler, launched block structures languages, and > played a part in Elliott selling nearly 300 803B computers at a time > when 300 computers was a big number. > > Obviously the US preferred Fortran and COBOL for commercial use, and > there were other Algol compilers in some shape or other knocking about > in universities. But I'd say this implementation put block structured > programming into the mainstream. (And it was the first high level > language I used, but that's beside the point). > > Now some kid on Wikipedia thinks it's not notable and is trying to > delete it because he can't find much on it doing a Google search. > Wikipedia may be sinking under activists and egos, but I think we need > to put this misapprehension straight. Unfortunately we may be arguing > with an idiot. > > https://en.wikipedia.org/wiki/Elliott_ALGOL > > If course, if anyone thinks it wasn't significant, that's an opinion > too, but I'd like to hear why. > > Thanks, Frank. > > > --===============6015514905609403753==-- From jonesthechip@logicmagic.co.uk Sat Feb 15 14:59:08 2025 From: Sid Jones To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 14:52:10 +0000 Message-ID: <0274D62140A647B3BAB38A527DAFE846@LM010> In-Reply-To: <0fd5ac37-ad58-4b01-9f60-3402625ea70a@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8438761944052203854==" --===============8438761944052203854== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five-hole tape in a drawer somewhere in my untidy office... As used in UCNW Bangor, 1971-1974. Regards Sid -----Original Message----- From: Frank Leonhardt via cctalk Sent: Saturday, February 15, 2025 2:43 PM To: cctalk(a)classiccmp.org Cc: Frank Leonhardt Subject: [cctalk] Elliott Algol As those of us with a few years will know, Tony Hoare (and Jill's) implementation of Algol 60 on the Elliott 803 was a highly significant event in the history of computer languages. It was the first practical commercial Algol compiler, launched block structures languages, and played a part in Elliott selling nearly 300 803B computers at a time when 300 computers was a big number. Obviously the US preferred Fortran and COBOL for commercial use, and there were other Algol compilers in some shape or other knocking about in universities. But I'd say this implementation put block structured programming into the mainstream. (And it was the first high level language I used, but that's beside the point). Now some kid on Wikipedia thinks it's not notable and is trying to delete it because he can't find much on it doing a Google search. Wikipedia may be sinking under activists and egos, but I think we need to put this misapprehension straight. Unfortunately we may be arguing with an idiot. https://en.wikipedia.org/wiki/Elliott_ALGOL If course, if anyone thinks it wasn't significant, that's an opinion too, but I'd like to hear why. Thanks, Frank. --===============8438761944052203854==-- From g4ajq1@gmail.com Sat Feb 15 15:22:05 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now (bitbanging) Date: Sat, 15 Feb 2025 10:21:47 -0500 Message-ID: <42088e59-6b68-48db-879e-0f44d7cb01c3@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0781916828583509264==" --===============0781916828583509264== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-15 09:46, Paul Koning via cctalk wrote: > >> On Feb 15, 2025, at 4:10=E2=80=AFAM, Bill Duncan via cctalk wrote: >> >> On Mon, Feb 03, 2025 at 06:09:28AM +0000, Chuck Guzis via cctalk wrote: >>> On 2/2/25 17:22, Will Cooke via cctalk wrote: >>>> >>>> Not quite lost. The 1802 crowd is doing amazing things. >>>> See https://groups.io/g/cosmacelf/message/33678 >>>> >>>> And if you know anything about the 1802, it's, uh, not so speedy. >>> At its introduction,it was one of few static CMOS CPUs. You could run >>> it from batteries and stop the clock when not needed. Perfect for >>> telemetry. I think the Intersil 6100 was another, but required 12-bit >>> wide memory. >>> >>> --Chuck >> ..and it had a "sex" instruction. > The PDP-11 almost did, but it was caught before release and renamed ""SXT". Maybe, but not before some manuals got out with it included.=C2=A0 I have=20 seen one of the manuals that got printed and hastily withdrawn, with a=20 footnote 'plus 20 minutes on Saturday night'. > >> IMO, one of the original RISC cpus.. LoL.. > I would apply that label to the CDC 6600 (1964). I think Bill was thinking in terms of RISC as what could been avoided by=20 using a wrapper! cheers, Nigel --=20 Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============0781916828583509264==-- From elson@pico-systems.com Sat Feb 15 16:42:19 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 10:35:42 -0600 Message-ID: In-Reply-To: <0fd5ac37-ad58-4b01-9f60-3402625ea70a@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5072505008172969788==" --===============5072505008172969788== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/15/25 08:43, Frank Leonhardt via cctalk wrote: > As those of us with a few years will know, Tony Hoare (and > Jill's) implementation of Algol 60 on the Elliott 803 was > a highly significant event in the history of computer > languages. It was the first practical commercial Algol > compiler, launched block structures languages, and played > a part in Elliott selling nearly 300 803B computers at a > time when 300 computers was a big number. > > Obviously the US preferred Fortran and COBOL for > commercial use, and there were other Algol compilers in > some shape or other knocking about in universities. But > I'd say this implementation put block structured > programming into the mainstream. (And it was the first > high level language I used, but that's beside the point). > The Bendix G15 (introduced in 1956) had ALGO, their variant of Algol.  Not sure when this was available, but likely after 1958 or so.  I think it was the only high level language available on that computer. Jon --===============5072505008172969788==-- From classiccmp@fjl.co.uk Sat Feb 15 18:27:41 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 18:27:28 +0000 Message-ID: <47d8bb02-f259-42c0-851e-d83a9ab7bc3f@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8202720473768939883==" --===============8202720473768939883== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 15/02/2025 16:35, Jon Elson via cctalk wrote: > On 2/15/25 08:43, Frank Leonhardt via cctalk wrote: >> As those of us with a few years will know, Tony Hoare (and Jill's) >> implementation of Algol 60 on the Elliott 803 was a highly >> significant event in the history of computer languages. It was the >> first practical commercial Algol compiler, launched block structures >> languages, and played a part in Elliott selling nearly 300 803B >> computers at a time when 300 computers was a big number. >> >> Obviously the US preferred Fortran and COBOL for commercial use, and >> there were other Algol compilers in some shape or other knocking >> about in universities. But I'd say this implementation put block >> structured programming into the mainstream. (And it was the first >> high level language I used, but that's beside the point). >> > The Bendix G15 (introduced in 1956) had ALGO, their variant of Algol.  > Not sure when this was available, but likely after 1958 or so.  I > think it was the only high level language available on that computer. > Running anything like Algol on a machine with drum memory seems a bit optimistic! --===============8202720473768939883==-- From classiccmp@fjl.co.uk Sat Feb 15 18:35:23 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 18:35:08 +0000 Message-ID: <5ae2bc61-93b5-4a8f-8e63-0d02091a4e21@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5020353551385901515==" --===============5020353551385901515== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 15/02/2025 14:51, Adrian Stoness via cctalk wrote: > wiki has always been this way. it has stricks standards if something > doesnt fallow they clear it > > u need to start a talk thread under talk about this issue not just have a > spat back and fourth deleting and reposting It's not my article. I was simply watching it with a view to expanding on it one day if I have no other work to do and got a notification. There's a discussion about removal page for people to object. If anyone else objects, please feel free add comments. Not only are these historic computers being scrapped, but now all reference is being erased. --===============5020353551385901515==-- From brain@jbrain.com Sat Feb 15 19:29:10 2025 From: Jim Brain To: cctalk@classiccmp.org Subject: [cctalk] Dan Sokol (and bits about the Apple I and the 6502 procurement) Date: Sat, 15 Feb 2025 13:29:03 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5969423162442849923==" --===============5969423162442849923== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit https://thisistrue.com/sokol-behind-scenes/ It's probably not overly important how the 6502s got sourced for the Apple I, but here's a different take. Debate as you see fit, I'm just the messenger. Jim -- Jim Brain brain(a)jbrain.com www.jbrain.com --===============5969423162442849923==-- From bfranchuk@jetnet.ab.ca Sat Feb 15 19:53:53 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 12:53:45 -0700 Message-ID: In-Reply-To: <47d8bb02-f259-42c0-851e-d83a9ab7bc3f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2357487792983696790==" --===============2357487792983696790== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-15 11:27 a.m., Frank Leonhardt via cctalk wrote: > Running anything like Algol on a machine with drum memory seems a bit > optimistic! > Remove "Like Algol" and the statement is even more valid. I guess that was why the PDP-1 was successful, it had early core memory. I keep forgetting about drum memory, on most early machines. Around what time did core memory drop in price that one had ample main memory to compile with? I am guessing the late 60's. The PDP 8/e, being simple could have a fast cycle time 1.2 uS. I have a rather full featured, 18 bit design being run in real hardware using 10 ns CPLD's (emulating ROM) and the best speed I can do is 1.6 uS core memory cycle time with a 2 phase clock.5 Mhz Oscillator. Most of the delay is with the slow 74LS219 register file and ROM accesses time. Working backwards, ballpark timing for a 70's design using SSI is a 2.17 uS. 3.6864 Mhz clock. I keep finding out how the early computers got away with so little hardware and memory and did so much with that. I wonder how much progress computers would have made had ACSII and Algol not kept changing standards every few years? Some how 6 bit characters seems more standard, text wise, compared with the mess with accented characters and money characters of today. Is there any thing a ALGOL compiler needs for good code generation other than ample index and GP resisters? Ben. --===============2357487792983696790==-- From tdk.knight@gmail.com Sat Feb 15 19:59:53 2025 From: Adrian Stoness To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 13:59:36 -0600 Message-ID: In-Reply-To: <5ae2bc61-93b5-4a8f-8e63-0d02091a4e21@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3516169044052063095==" --===============3516169044052063095== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit we need websites to reference this stuff to like museums and such for the artical to survive On Sat, Feb 15, 2025 at 12:35 PM Frank Leonhardt via cctalk < cctalk(a)classiccmp.org> wrote: > On 15/02/2025 14:51, Adrian Stoness via cctalk wrote: > > wiki has always been this way. it has stricks standards if something > > doesnt fallow they clear it > > > > u need to start a talk thread under talk about this issue not just have a > > spat back and fourth deleting and reposting > > It's not my article. I was simply watching it with a view to expanding > on it one day if I have no other work to do and got a notification. > > There's a discussion about removal page for people to object. If anyone > else objects, please feel free add comments. Not only are these historic > computers being scrapped, but now all reference is being erased. > --===============3516169044052063095==-- From elson@pico-systems.com Sat Feb 15 20:09:46 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 14:09:38 -0600 Message-ID: In-Reply-To: <47d8bb02-f259-42c0-851e-d83a9ab7bc3f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1989218173945941252==" --===============1989218173945941252== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/15/25 12:27, Frank Leonhardt via cctalk wrote: > On 15/02/2025 16:35, Jon Elson via cctalk wrote: >> On 2/15/25 08:43, Frank Leonhardt via cctalk wrote: >>> As those of us with a few years will know, Tony Hoare >>> (and Jill's) implementation of Algol 60 on the Elliott >>> 803 was a highly significant event in the history of >>> computer languages. It was the first practical >>> commercial Algol compiler, launched block structures >>> languages, and played a part in Elliott selling nearly >>> 300 803B computers at a time when 300 computers was a >>> big number. >>> >>> Obviously the US preferred Fortran and COBOL for >>> commercial use, and there were other Algol compilers in >>> some shape or other knocking about in universities. But >>> I'd say this implementation put block structured >>> programming into the mainstream. (And it was the first >>> high level language I used, but that's beside the point). >>> >> The Bendix G15 (introduced in 1956) had ALGO, their >> variant of Algol.  Not sure when this was available, but >> likely after 1958 or so.  I think it was the only high >> level language available on that computer. >> > Running anything like Algol on a machine with drum memory > seems a bit optimistic! Compiles were supposed to take about 2 DAYS!  With constant changing of compiler phase tapes.  We never got our G15 close to running enough to try it.  It had two badly scored drum tracks. Jon --===============1989218173945941252==-- From julf@julf.com Sat Feb 15 20:15:47 2025 From: Johan Helsingius To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 21:14:42 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2131691413962786666==" --===============2131691413962786666== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 15/02/2025 20:53, ben via cctalk wrote: > Some how 6 bit characters seems more standard, text wise, > compared with the mess with accented characters and money characters > of today. 6 bit characters were fine if you didn't care about proper capitalization and your only language was English. Julf --===============2131691413962786666==-- From van.snyder@sbcglobal.net Sat Feb 15 20:29:53 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 12:29:42 -0800 Message-ID: <9f99ab490f71ccc89deed1e4a80eb2fa517f90aa.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2404271193072642751==" --===============2404271193072642751== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 2025-02-15 at 08:51 -0600, Adrian Stoness via cctalk wrote: > wiki has always been this way. it has stricks standards if something > doesnt fallow they clear it > > u need to start a talk thread under talk about this issue not just > have a > spat back and fourth deleting and reposting The founder of Wikipedia, who is no longer involved, is disgusted by what it has become. --===============2404271193072642751==-- From van.snyder@sbcglobal.net Sat Feb 15 20:34:08 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 12:33:55 -0800 Message-ID: <9565fa700e2c43fb5cf37cb33f08be70dfd4f8cd.camel@sbcglobal.net> In-Reply-To: <0274D62140A647B3BAB38A527DAFE846@LM010> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6485749272378865630==" --===============6485749272378865630== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 14:52 +0000, Sid Jones via cctalk wrote: > IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five- > hole > tape in a drawer somewhere in my untidy office... > > As used in UCNW Bangor, 1971-1974. There might be a reader somewhere. If anybody has (or developes) an 803B emulator, it would be nice to have the compiler. Paul Pierce read several IBM 1401 tapes. The Computer History Museum in Mountain View, CA has two operating 1401s, and the SimH project has an emulator. It's nice to have the Autocoder assembler, FORTRAN II and FORTRAN IV compilers, COBOL compiler, … to use. There are students at San Jose State University who go to classes in 1401 programming at CHM. Maybe Paul has a paper tape reader too. --===============6485749272378865630==-- From wayne.sudol@hotmail.com Sat Feb 15 20:34:25 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 20:34:17 +0000 Message-ID: In-Reply-To: <9f99ab490f71ccc89deed1e4a80eb2fa517f90aa.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0678765110609133097==" --===============0678765110609133097== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 6 bit characters were used by CDC 24 bit machines. 4 chars per 24 bit word.=20 Sent from my iPhone > On Feb 15, 2025, at 12:29, Van Snyder via cctalk = wrote: >=20 > =EF=BB=BFOn Sat, 2025-02-15 at 08:51 -0600, Adrian Stoness via cctalk wrote: >> wiki has always been this way. it has stricks standards if something >> doesnt fallow they clear it >>=20 >> u need to start a talk thread under talk about this issue not just >> have a >> spat back and fourth deleting and reposting >=20 > The founder of Wikipedia, who is no longer involved, is disgusted by > what it has become. >=20 --===============0678765110609133097==-- From henry.r.bent@gmail.com Sat Feb 15 20:37:07 2025 From: Henry Bent To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:36:48 -0500 Message-ID: In-Reply-To: <9f99ab490f71ccc89deed1e4a80eb2fa517f90aa.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3552651127258488062==" --===============3552651127258488062== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 15 Feb 2025 at 15:29, Van Snyder via cctalk wrote: > On Sat, 2025-02-15 at 08:51 -0600, Adrian Stoness via cctalk wrote: > > wiki has always been this way. it has stricks standards if something > > doesnt fallow they clear it > > > > u need to start a talk thread under talk about this issue not just > > have a > > spat back and fourth deleting and reposting > > The founder of Wikipedia, who is no longer involved, is disgusted by > what it has become. I presume you're referring to Larry Sanger, who was the co-founder of Wikipedia. In any case, the process appears to be working as designed - someone thought that the article should be deleted, but once the nomination was made the article got more eyes on it, and it's looking like it will end up being kept. -Henry --===============3552651127258488062==-- From bfranchuk@jetnet.ab.ca Sat Feb 15 20:39:07 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 13:38:59 -0700 Message-ID: <5d11105f-9e76-480c-abf0-5ae53cd15510@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3112822099875235754==" --===============3112822099875235754== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-15 1:14 p.m., Johan Helsingius via cctalk wrote: > On 15/02/2025 20:53, ben via cctalk wrote: >> Some how 6 bit characters seems more standard, text wise, >> compared with the mess with accented characters and money characters >> of today. > > 6 bit characters were fine if you didn't care about proper > capitalization and your only language was English. IT IS MORE AMERICAN THAN ENGLISH. MY TWO ¢'S WORTH OF COMMENT. The point is you have a different national code page under ASCII. Accents should have been like hard copy terminals, as a over strike character for video terminals. Oddly it is the loss of [] that I complain about, with the pre-IBM PC ASCII. >     Julf > Ben. --===============3112822099875235754==-- From van.snyder@sbcglobal.net Sat Feb 15 21:15:21 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 13:15:10 -0800 Message-ID: <852114fa898875d098fbd2e0bc8195b38ba7070e.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4306008756740398885==" --===============4306008756740398885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 10:35 -0600, Jon Elson via cctalk wrote: > > > The Bendix G15 (introduced in 1956) had ALGO, their variant > of Algol.  Not sure when this was available, but likely > after 1958 or so.  I think it was the only high level > language available on that computer. > > Jon It was a subset called "ALGO." It punched miles of paper tape as an intermediate, even for dinky programs (which were, of course, all that could fit anyway). I used a G15 at a summer class in 1963. We used Intercom 1000. I found a manual for Intercom 2000 and wrote an emulator (not a G15 emulator). Let me know if you want it. --===============4306008756740398885==-- From classiccmp@fjl.co.uk Sat Feb 15 21:19:45 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 21:19:33 +0000 Message-ID: <3461d209-25ea-4d20-8369-4bb59f2087d5@fjl.co.uk> In-Reply-To: <9565fa700e2c43fb5cf37cb33f08be70dfd4f8cd.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5807298949755422644==" --===============5807298949755422644== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 15/02/2025 20:33, Van Snyder via cctalk wrote: > On Sat, 2025-02-15 at 14:52 +0000, Sid Jones via cctalk wrote: >> IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five- >> hole >> tape in a drawer somewhere in my untidy office... >> >> As used in UCNW Bangor, 1971-1974. > There might be a reader somewhere. If anybody has (or developes) an > 803B emulator, it would be nice to have the compiler. > > Paul Pierce read several IBM 1401 tapes. The Computer History Museum in > Mountain View, CA has two operating 1401s, and the SimH project has an > emulator. It's nice to have the Autocoder assembler, FORTRAN II and > FORTRAN IV compilers, COBOL compiler, … to use. There are students at > San Jose State University who go to classes in 1401 programming at CHM. > > Maybe Paul has a paper tape reader too. > Peter Onion has a rather fine 803 emulator, and the Algol tapes. And a working 803. I've only got bits of one in my shed. https://www.peteronion.org.uk/Elliott/ --===============5807298949755422644==-- From mhs.stein@gmail.com Sat Feb 15 21:22:25 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sat, 15 Feb 2025 13:37:49 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0110930718122000132==" --===============0110930718122000132== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In the keyboard section of the attached document there are instructions for testing with a terminal & USB>TTL RS-232 adapter. On Sat, Feb 15, 2025 at 12:43=E2=80=AFAM Steve Lewis = wrote: > Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom" > 4-pin wire (one of them being 5V power). So just level-shift the TX/RX > pins through a MAX232 IC and it would talk to another R-232 system at 300 > baud eh? Might have to seek out a lone Kaypro keyboard to give it a try. > > I suspect some of the "serial style" mid-1980s IBM Model M keyboards are > similar. But I'm still wondering if anyone used this concept in the late > 1960s - teletypes were expensive, flipping switches was tedious, so > keyboard alternates were hot items by early 70's (hence the TVT popularity). > > On Fri, Feb 14, 2025 at 5:28=E2=80=AFPM Mike Stein = wrote: > >> I believe that at least Kaypro used a TTL form of RS-232 for the >> keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a >> keyboard in distant days. >> >> On Fri, Feb 14, 2025 at 12:27=E2=80=AFPM Steve Lewis via cctalk < >> cctalk(a)classiccmp.org> wrote: >> >>> Rick Bensene: >>> >>> > I will try to find my Xircom parallel port Modem and Ethernet adapters >>> in >>> > a box somewhere in my storage area and take a photo of them. If I can >>> find >>> > them, I=E2=80=99ll post a link here to the photos so those in disbelief= can see >>> > them. >>> >>> >>> That'd be neat to see, if you do find the Xircom parallel modem. I've >>> seen >>> combo ones and their "parallel-ethernet" devices (which seem to go for >>> quite a premium these days), but not the modem only. Suppose they >>> weren't >>> too popular, as even laptops started to have built in modems. >>> >>> These days, I do use an SDLPT, that lets you use SD-cards to transfer >>> data >>> into a system over the parallel port. I suppose that's the same general >>> principle (of read/writing one full byte at a time to a device). I >>> haven't measured its performance yet (but would characterize it as being >>> comparable to a physical 3.5" floppy disk drive kind of performance - I >>> think copying Quake took over 40 minutes, something like that; but I'd >>> like >>> to get more accurate about it, down to an actual bytes-per-second rate). >>> Measuring that might give me an answer on how fast something like >>> Laplink/Interlink cable should be able to perform. >>> >>> As another experiment, I'll drop that ~7MHz 16550 serial card into a 386, >>> and see if I can get a 386 to push data out on RS-232 faster than 115200. >>> It should, but we'll see! >>> >>> >>> And I think I will do an RS-232 themed talk in June VCF, if a spot is >>> still >>> open - I think I have enough now to make it interesting. One area I'm a >>> little stuck on is verifying that anyone actually did make an RS-232 >>> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that >>> as >>> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to >>> the >>> PDP-1, but might not be accurate to call that RS-232 (but can't a current >>> loop based thing be adapted to voltage?). I thought the POLY-88 keyboard >>> was RS-232, but it'll be awhile before I can get back to that equipment. >>> >>> >>> -Steve >>> >>> >>> >>> On Thu, Feb 13, 2025 at 6:32=E2=80=AFPM Rick Bensene via cctalk < >>> cctalk(a)classiccmp.org> wrote: >>> >>> > Henry wrote: >>> > >>> > > I remember those, and when I went searching to look for more >>> information >>> > on them I found something I > hadn't stumbled on before - apparently >>> Xircom >>> > made a parallel port Ethernet adapter. It must have >>> > > been pretty painful. The parallel port wasn't a great high speed >>> > interface=E2=80=A6 >>> > >>> > ---- >>> > >>> > Yes, I have one of those parallel port Ethernet devices too. But, >>> > remember, back at that time, Ethernet was commonly 10Mb/Sec. I think >>> that >>> > 100Mb/Sec was only located in high-end datacenters and was very >>> expensive. >>> > For a laptop that didn=E2=80=99t have a PCMCIA port, and you wanted it = on an >>> > Ethernet network, this was an acceptable way to go. Performance wasn= =E2=80=99t >>> > great, but most of the time laptops like this were used for TELNET >>> > connections to other hosts on the local network for =E2=80=9CGREEN SCRE= EN=E2=80=9D type >>> > applications that ran entirely on the remote host. Performance in such >>> > cases wasn=E2=80=99t nearly as much of a concern as it would be in the = not too >>> > distant future. >>> > >>> > I will try to find my Xircom parallel port Modem and Ethernet adapters >>> in >>> > a box somewhere in my storage area and take a photo of them. If I can >>> find >>> > them, I=E2=80=99ll post a link here to the photos so those in disbelief= can see >>> > them. >>> > >>> > -Rick >>> > >>> > >>> > >>> > From: Henry Bent [mailto:henry.r.bent(a)gmail.com] >>> > Sent: Thursday, February 13, 2025 3:54 PM >>> > To: General Discussion: On-Topic and Off-Topic Posts < >>> > cctalk(a)classiccmp.org> >>> > Cc: Rick Bensene >>> > Subject: Re: [cctalk] Re: RS232 - parallel modems!? >>> > >>> >> --===============0110930718122000132==-- From frank@fjl.co.uk Sat Feb 15 21:22:28 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 21:16:31 +0000 Message-ID: <919ba44f-2163-402f-93ae-e59e13cec3f8@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0424325283341985477==" --===============0424325283341985477== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 15/02/2025 20:09, Jon Elson via cctalk wrote: > On 2/15/25 12:27, Frank Leonhardt via cctalk wrote: >> On 15/02/2025 16:35, Jon Elson via cctalk wrote: >>> On 2/15/25 08:43, Frank Leonhardt via cctalk wrote: >>>> As those of us with a few years will know, Tony Hoare (and Jill's) >>>> implementation of Algol 60 on the Elliott 803 was a highly >>>> significant event in the history of computer languages. It was the >>>> first practical commercial Algol compiler, launched block >>>> structures languages, and played a part in Elliott selling nearly >>>> 300 803B computers at a time when 300 computers was a big number. >>>> >>>> Obviously the US preferred Fortran and COBOL for commercial use, >>>> and there were other Algol compilers in some shape or other >>>> knocking about in universities. But I'd say this implementation put >>>> block structured programming into the mainstream. (And it was the >>>> first high level language I used, but that's beside the point). >>>> >>> The Bendix G15 (introduced in 1956) had ALGO, their variant of >>> Algol.  Not sure when this was available, but likely after 1958 or >>> so.  I think it was the only high level language available on that >>> computer. >>> >> Running anything like Algol on a machine with drum memory seems a bit >> optimistic! > > Compiles were supposed to take about 2 DAYS!  With constant changing > of compiler phase tapes.  We never got our G15 close to running enough > to try it.  It had two badly scored drum tracks. Elliott Algol was pretty quick (and therefore practical) - feed the compiler tape in (8-hole) and then feed in your program on five hole. It's been a long time but it was compiling at several cps and your program ran in a few minutes. Then feed in another. You could compile to tape for larger programs. The 803 had 4K or 8K by 39-bit core, but I have a feeling it needed the full 8K for Algol. The later 503 (1963?) was a lot faster. I had access to one but never got it working. This must have been three or four years after the Bendix! --===============0424325283341985477==-- From classiccmp@fjl.co.uk Sat Feb 15 21:22:32 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 21:22:11 +0000 Message-ID: <808a36c5-2bed-41a9-93fc-32c3ac6273f7@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6638225670343329413==" --===============6638225670343329413== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 15/02/2025 20:09, Jon Elson via cctalk wrote: > On 2/15/25 12:27, Frank Leonhardt via cctalk wrote: >> On 15/02/2025 16:35, Jon Elson via cctalk wrote: >>> On 2/15/25 08:43, Frank Leonhardt via cctalk wrote: >>>> As those of us with a few years will know, Tony Hoare (and Jill's) >>>> implementation of Algol 60 on the Elliott 803 was a highly >>>> significant event in the history of computer languages. It was the >>>> first practical commercial Algol compiler, launched block >>>> structures languages, and played a part in Elliott selling nearly >>>> 300 803B computers at a time when 300 computers was a big number. >>>> >>>> Obviously the US preferred Fortran and COBOL for commercial use, >>>> and there were other Algol compilers in some shape or other >>>> knocking about in universities. But I'd say this implementation put >>>> block structured programming into the mainstream. (And it was the >>>> first high level language I used, but that's beside the point). >>>> >>> The Bendix G15 (introduced in 1956) had ALGO, their variant of >>> Algol.  Not sure when this was available, but likely after 1958 or >>> so.  I think it was the only high level language available on that >>> computer. >>> >> Running anything like Algol on a machine with drum memory seems a bit >> optimistic! > > Compiles were supposed to take about 2 DAYS!  With constant changing > of compiler phase tapes.  We never got our G15 close to running enough > to try it.  It had two badly scored drum tracks. Elliott Algol was pretty quick (and therefore practical) - feed the compiler tape in (8-hole) and then feed in your program on five hole. It's been a long time but it was compiling at several cps and your program ran in a few minutes. Then feed in another. You could compile to tape for larger programs. The 803 had 4K or 8K by 39-bit core, but I have a feeling it needed the full 8K for Algol. The later 503 (1963?) was a lot faster. I had access to one but never got it working. This must have been three or four years after the Bendix! --===============6638225670343329413==-- From wayne.sudol@hotmail.com Sat Feb 15 21:27:01 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sat, 15 Feb 2025 21:26:53 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2209932899518773761==" --===============2209932899518773761== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t see the attachment. Sent from my iPhone > On Feb 15, 2025, at 13:22, Mike Stein via cctalk = wrote: >=20 > =EF=BB=BFIn the keyboard section of the attached document there are instruc= tions for > testing with a terminal & USB>TTL RS-232 adapter. >=20 >> On Sat, Feb 15, 2025 at 12:43=E2=80=AFAM Steve Lewis wrote: >>=20 >> Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom" >> 4-pin wire (one of them being 5V power). So just level-shift the TX/RX >> pins through a MAX232 IC and it would talk to another R-232 system at 300 >> baud eh? Might have to seek out a lone Kaypro keyboard to give it a try. >>=20 >> I suspect some of the "serial style" mid-1980s IBM Model M keyboards are >> similar. But I'm still wondering if anyone used this concept in the late >> 1960s - teletypes were expensive, flipping switches was tedious, so >> keyboard alternates were hot items by early 70's (hence the TVT popularity= ). >>=20 >>> On Fri, Feb 14, 2025 at 5:28=E2=80=AFPM Mike Stein wrote: >>>=20 >>> I believe that at least Kaypro used a TTL form of RS-232 for the >>> keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a >>> keyboard in distant days. >>>=20 >>> On Fri, Feb 14, 2025 at 12:27=E2=80=AFPM Steve Lewis via cctalk < >>> cctalk(a)classiccmp.org> wrote: >>>=20 >>>> Rick Bensene: >>>>=20 >>>>> I will try to find my Xircom parallel port Modem and Ethernet adapters >>>> in >>>>> a box somewhere in my storage area and take a photo of them. If I can >>>> find >>>>> them, I=E2=80=99ll post a link here to the photos so those in disbelief= can see >>>>> them. >>>>=20 >>>>=20 >>>> That'd be neat to see, if you do find the Xircom parallel modem. I've >>>> seen >>>> combo ones and their "parallel-ethernet" devices (which seem to go for >>>> quite a premium these days), but not the modem only. Suppose they >>>> weren't >>>> too popular, as even laptops started to have built in modems. >>>>=20 >>>> These days, I do use an SDLPT, that lets you use SD-cards to transfer >>>> data >>>> into a system over the parallel port. I suppose that's the same general >>>> principle (of read/writing one full byte at a time to a device). I >>>> haven't measured its performance yet (but would characterize it as being >>>> comparable to a physical 3.5" floppy disk drive kind of performance - I >>>> think copying Quake took over 40 minutes, something like that; but I'd >>>> like >>>> to get more accurate about it, down to an actual bytes-per-second rate). >>>> Measuring that might give me an answer on how fast something like >>>> Laplink/Interlink cable should be able to perform. >>>>=20 >>>> As another experiment, I'll drop that ~7MHz 16550 serial card into a 386, >>>> and see if I can get a 386 to push data out on RS-232 faster than 115200. >>>> It should, but we'll see! >>>>=20 >>>>=20 >>>> And I think I will do an RS-232 themed talk in June VCF, if a spot is >>>> still >>>> open - I think I have enough now to make it interesting. One area I'm a >>>> little stuck on is verifying that anyone actually did make an RS-232 >>>> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that >>>> as >>>> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to >>>> the >>>> PDP-1, but might not be accurate to call that RS-232 (but can't a current >>>> loop based thing be adapted to voltage?). I thought the POLY-88 keyboard >>>> was RS-232, but it'll be awhile before I can get back to that equipment. >>>>=20 >>>>=20 >>>> -Steve >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Feb 13, 2025 at 6:32=E2=80=AFPM Rick Bensene via cctalk < >>>> cctalk(a)classiccmp.org> wrote: >>>>=20 >>>>> Henry wrote: >>>>>=20 >>>>>> I remember those, and when I went searching to look for more >>>> information >>>>> on them I found something I > hadn't stumbled on before - apparently >>>> Xircom >>>>> made a parallel port Ethernet adapter. It must have >>>>>> been pretty painful. The parallel port wasn't a great high speed >>>>> interface=E2=80=A6 >>>>>=20 >>>>> ---- >>>>>=20 >>>>> Yes, I have one of those parallel port Ethernet devices too. But, >>>>> remember, back at that time, Ethernet was commonly 10Mb/Sec. I think >>>> that >>>>> 100Mb/Sec was only located in high-end datacenters and was very >>>> expensive. >>>>> For a laptop that didn=E2=80=99t have a PCMCIA port, and you wanted it = on an >>>>> Ethernet network, this was an acceptable way to go. Performance wasn= =E2=80=99t >>>>> great, but most of the time laptops like this were used for TELNET >>>>> connections to other hosts on the local network for =E2=80=9CGREEN SCRE= EN=E2=80=9D type >>>>> applications that ran entirely on the remote host. Performance in such >>>>> cases wasn=E2=80=99t nearly as much of a concern as it would be in the = not too >>>>> distant future. >>>>>=20 >>>>> I will try to find my Xircom parallel port Modem and Ethernet adapters >>>> in >>>>> a box somewhere in my storage area and take a photo of them. If I can >>>> find >>>>> them, I=E2=80=99ll post a link here to the photos so those in disbelief= can see >>>>> them. >>>>>=20 >>>>> -Rick >>>>>=20 >>>>>=20 >>>>>=20 >>>>> From: Henry Bent [mailto:henry.r.bent(a)gmail.com] >>>>> Sent: Thursday, February 13, 2025 3:54 PM >>>>> To: General Discussion: On-Topic and Off-Topic Posts < >>>>> cctalk(a)classiccmp.org> >>>>> Cc: Rick Bensene >>>>> Subject: Re: [cctalk] Re: RS232 - parallel modems!? >>>>>=20 >>>>=20 >>>=20 --===============2209932899518773761==-- From tdk.knight@gmail.com Sat Feb 15 21:31:42 2025 From: Adrian Stoness To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:31:25 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7318753208353527851==" --===============7318753208353527851== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable u had a bendix running or still running? On Sat, Feb 15, 2025 at 2:09=E2=80=AFPM Jon Elson via cctalk wrote: > On 2/15/25 12:27, Frank Leonhardt via cctalk wrote: > > On 15/02/2025 16:35, Jon Elson via cctalk wrote: > >> On 2/15/25 08:43, Frank Leonhardt via cctalk wrote: > >>> As those of us with a few years will know, Tony Hoare > >>> (and Jill's) implementation of Algol 60 on the Elliott > >>> 803 was a highly significant event in the history of > >>> computer languages. It was the first practical > >>> commercial Algol compiler, launched block structures > >>> languages, and played a part in Elliott selling nearly > >>> 300 803B computers at a time when 300 computers was a > >>> big number. > >>> > >>> Obviously the US preferred Fortran and COBOL for > >>> commercial use, and there were other Algol compilers in > >>> some shape or other knocking about in universities. But > >>> I'd say this implementation put block structured > >>> programming into the mainstream. (And it was the first > >>> high level language I used, but that's beside the point). > >>> > >> The Bendix G15 (introduced in 1956) had ALGO, their > >> variant of Algol. Not sure when this was available, but > >> likely after 1958 or so. I think it was the only high > >> level language available on that computer. > >> > > Running anything like Algol on a machine with drum memory > > seems a bit optimistic! > > Compiles were supposed to take about 2 DAYS! With constant > changing of compiler phase tapes. We never got our G15 > close to running enough to try it. It had two badly scored > drum tracks. > > Jon > --===============7318753208353527851==-- From tdk.knight@gmail.com Sat Feb 15 21:32:42 2025 From: Adrian Stoness To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:32:25 -0600 Message-ID: In-Reply-To: <9f99ab490f71ccc89deed1e4a80eb2fa517f90aa.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4173014964882724764==" --===============4173014964882724764== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable thats what happens with the rules u get people who are sticklers on it and they go crazy same thing happens in government all the time its human nature On Sat, Feb 15, 2025 at 2:29=E2=80=AFPM Van Snyder via cctalk wrote: > On Sat, 2025-02-15 at 08:51 -0600, Adrian Stoness via cctalk wrote: > > wiki has always been this way. it has stricks standards if something > > doesnt fallow they clear it > > > > u need to start a talk thread under talk about this issue not just > > have a > > spat back and fourth deleting and reposting > > The founder of Wikipedia, who is no longer involved, is disgusted by > what it has become. > > --===============4173014964882724764==-- From paulkoning@comcast.net Sat Feb 15 22:20:01 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 17:19:44 -0500 Message-ID: <3BDAF0A9-0E72-4553-9D70-35FD250848A7@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6165089864898785536==" --===============6165089864898785536== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 15, 2025, at 2:53=E2=80=AFPM, ben via cctalk wrote: >=20 > On 2025-02-15 11:27 a.m., Frank Leonhardt via cctalk wrote: >=20 >> Running anything like Algol on a machine with drum memory seems a bit opti= mistic! >=20 > Remove "Like Algol" and the statement is even more valid. Oh? Certainly by today's standards a drum memory machine is quite slow. But= in their day they were used for serious work. To pick one example, the ARMAC machine developed at CWI in Amsterdam (then ca= lled MC, Mathematical Center) had a drum main memory coupled with a one entry= cache to hold the most recently accessed drum track. That was the main mach= ine at MC for a couple of years, until the Electrologica X-1 (with instructio= n times in the 20-30 microsecond range) replaced it. Before the ARMAC came the ARRA 2, which had drum memory without the cache. I= t worked well enough that Dutch aircraft manufacturer Fokker commissioned a c= opy, named FERTA. It was used to do the design of at least one of their majo= r commercially successful airliners. > I guess that was why the PDP-1 was successful, it had early core memory. Yes, it did, though commercial core memory machines appeared a number of year= s before that. For example, the EL-X1, which was a core memory fully transis= torized computer, came out in 1958. It appears to be the first commercial co= mputer with interrupts as a standard feature, which prompted Dijkstra to writ= e his Ph.D. thesis on the problem of how to create reliable code with interru= pts. He wrote the ROM BIOS for that machine. > I keep forgetting about drum memory, on most early machines. > Around what time did core memory drop in price that one had ample main memo= ry to compile with? I am guessing the late 60's. 1958. The X1 is where Dijkstra and Zonneveld created the first ALGOL compile= r, in 1960. Unlike a number of early compilers that one was a full implemen= tation except for the one or two small "features" that by then had already be= en recognized as mistakes. That compiler ran in 4 kW 27 bit words, requiring several passes. A later ve= rsion that took advantage of a memory upgrade -- to 16 kW -- was a full compi= le-load-execute system. So "ample memory" is a bit of a debatable question. It depends a lot on who = is doing the work. For Dijkstra and Zonneveld, 4 kW was useable and I suspec= t they would have considered 8 kW "ample". For the creators of the DEC PDP-1= 1 operating systems DOS-11 and RT-11, 8 kW (16 bits, so 16 kB) was ample; IBM= engineers required 128 kW for something not as good (OS/360 PCP v19.6). Tod= ay's programmers often think in terms of megabytes if not gigabytes as the mi= nimum tolerable, while many of those who hang out on this list enjoy the chal= lenge of squeezing stuff into a small microcontroller, or the boot block of s= ome disk device. For an extreme example, consider the "programmable I/O" state machines in the= Raspberry Pico microcontroller. It has two or three engines, each with 4 st= ate machines that share the program memory -- 32 words of 16 bits. With care= , you can do a lot with those. I'm thinking of doing a "bit banging" impleme= ntation of Ethernet with that device... > The PDP 8/e, being simple could have a fast cycle time 1.2 uS. Keep in mind that cycle time in those days wasn't necessarily constrained by = the logic but by the memory. Early core memories had cycle times of many mic= roseconds (the X1 for example had 8 microsecond core, I think). CDC delivere= d 1 microsecond core memory cycle time in 1964, but it took some rather mind = bending electronic circuitry to make that possible. > ... > I wonder how much progress computers would have made had ACSII > and Algol not kept changing standards every few years? Algol-60 never changed after the Revised Report of 1962, which was really the= "V1.0" release. Algol-68 is an entirely different language, just as Pascal = is an entirely different language. As for ASCII, that is exactly what it was originally. There have been lots o= f other character set definitions since then, though the mind bending variety= of language-specific sets was finally fixed once and for all with Unicode. = Yes, Unicode keeps growing to add more obscure character sets, but it's still= the same standard. > Some how 6 bit characters seems more standard, text wise, Which one? Electrologica had several, CDC had a bunch, as did every other ve= ndor. > Is there any thing a ALGOL compiler needs for good code generation > other than ample index and GP resisters? Some things make life simpler, such as stack operations and subroutine call i= nstructions that support recursion. But none of those are required; the EL-X= 1 had none of these. Its successor the X8 did because it was designed with t= he knowledge of Algol in mind (the X1 predates Algol). And as a result, the = transformation from Algol source code to machine code is in a number of place= s more straightforward. But you can compile anything you want to any machine= you want; if it's good enough to be considered a general purpose computer it= can be handled. =20 Another example is the CDC 6000 series mainframes, for which a bunch of compi= lers were created including Algol 60 as well as Algol 68. That machine has n= o index registers, no stack, no recursion; it only has 8 primary registers an= d its subroutine call overwrites memory. Not very friendly, but it just mean= s a bit more work for the compiler writer. paul --===============6165089864898785536==-- From paulkoning@comcast.net Sat Feb 15 22:23:06 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 17:22:42 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CCO1PR08MB7208A0264DC981E87534432CE4F92=40CO1PR08MB?= =?utf-8?q?7208=2Enamprd08=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2018902667035172004==" --===============2018902667035172004== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 15, 2025, at 3:34=E2=80=AFPM, Wayne S via cctalk wrote: >=20 > 6 bit characters were used by CDC 24 bit machines. 4 chars per 24 bit word.= =20 Lots of companies created 6 bit character sets, all different. For extra fun take a look at 6-bit (punched tape) codes used for typesetting = machines. They include shift codes (for shifting between Roman and Italic), = upper and lower case letters, all manner of interesting punctuation marks, an= d more. There too you're likely to find a different code set for any given m= anufacturer, and possibly changing from one machine model to the next. paul --===============2018902667035172004==-- From van.snyder@sbcglobal.net Sat Feb 15 22:47:22 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 14:47:12 -0800 Message-ID: <9b879f9d2055af0adaffcea0be2c040774ab5ed5.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3770047718851663849==" --===============3770047718851663849== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 12:53 -0700, ben via cctalk wrote: > Around what time did core memory drop in price that one had ample > main > memory to compile with? I am guessing the late 60's. The IBM 704, first delivered in 1956, had 8,192 words of 36-bit core  memory. The IBM 701, developed in in 1951 and delivered in 1953, had  memory consisting of 72 Williams Tube CRTs; some were later converted to core. Like SWAC, there was a tendency of zero bits to leak into adjacent words, so every ten milliseconds or so, programs would swap CRT memory to drum and back. The first IBM 1401 was announced in October 1959 and delivered shortly thereafter, with 4k characters of of 12.5 microsecond core memory. One could eventually get 1401, 1440, and 1460 with 16k memory. 1410, and the faster but functionally identical 7010, could be gotten with 100k memory. --===============3770047718851663849==-- From van.snyder@sbcglobal.net Sat Feb 15 22:58:13 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 14:58:03 -0800 Message-ID: In-Reply-To: <5d11105f-9e76-480c-abf0-5ae53cd15510@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8008326087463477399==" --===============8008326087463477399== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 13:38 -0700, ben via cctalk wrote: > > > 6 bit characters were fine if you didn't care about proper > > capitalization and your only language was English. An Icelandic chain could be gotten for an IBM 1403. I reverse engineered a program that converted numbers to Icelandic words, for check printing. So I added an Icelandic encoding to my Autocoder cross assembler. The Computer History Museum has a 1401 that was originally German — so it needs 50hz power. AFAIK, they didn't get a German chain that included umlauts. The usual 1403 setuip on a 1401 was to use a 47- character chain, but it was possible to get 63-character chains that included box-drawing characters. Those kinds of chains were used to print the Automated Logic Diagrams, or ALDs. Maybe IBM offered chains for Germany and France with more than 47 characters, to have all the accents. But they would print slower. IBM also offered a 15-character chain that had only digits plus five other characters — minus sign, dollar sign, comma, decimal, asterisk — for printing numeric-only reports. It was much faster than the 47-character chain. Of course, all the chains had the same number of links (I don't remember how many), but more repetitions with smaller character sets. --===============8008326087463477399==-- From mjd.bishop@emeritus-solutions.com Sat Feb 15 23:02:12 2025 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 23:02:06 +0000 Message-ID: In-Reply-To: <0274D62140A647B3BAB38A527DAFE846@LM010> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5756978693024496027==" --===============5756978693024496027== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sid If it serves any purpose I could read the 5 track tape, I have a 5/6/8 hole s= procket drive reader - in Dorset, UK - and an 8 hole friction drive reader (p= erhaps kinder on tapes, but n/a in this instance). Martin -----Original Message----- From: Sid Jones via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 15 February 2025 14:52 To: General Discussion: On-Topic and Off-Topic Posts Cc: Sid Jones Subject: [cctalk] Re: Elliott Algol IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five-hole tap= e in a drawer somewhere in my untidy office... As used in UCNW Bangor, 1971-1974. Regards Sid -----Original Message----- From: Frank Leonhardt via cctalk Sent: Saturday, February 15, 2025 2:43 PM To: cctalk(a)classiccmp.org Cc: Frank Leonhardt Subject: [cctalk] Elliott Algol As those of us with a few years will know, Tony Hoare (and Jill's) implementa= tion of Algol 60 on the Elliott 803 was a highly significant event in the his= tory of computer languages. It was the first practical commercial Algol compi= ler, launched block structures languages, and played a part in Elliott sellin= g nearly 300 803B computers at a time when 300 computers was a big number. Obviously the US preferred Fortran and COBOL for commercial use, and there we= re other Algol compilers in some shape or other knocking about in universitie= s. But I'd say this implementation put block structured programming into the = mainstream. (And it was the first high level language I used, but that's besi= de the point). Now some kid on Wikipedia thinks it's not notable and is trying to delete it = because he can't find much on it doing a Google search. Wikipedia may be sinking under activists and egos, but I think we need to put= this misapprehension straight. Unfortunately we may be arguing with an idiot. https://en.wikipedia.org/wiki/Elliott_ALGOL If course, if anyone thinks it wasn't significant, that's an opinion too, but= I'd like to hear why. Thanks, Frank. --===============5756978693024496027==-- From van.snyder@sbcglobal.net Sat Feb 15 23:06:50 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:06:41 -0800 Message-ID: <42f008ae4e05ce8c72ac277c1c759a133a7876d1.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0485227629102618293==" --===============0485227629102618293== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 17:22 -0500, Paul Koning via cctalk wrote: > For extra fun take a look at 6-bit (punched tape) codes used for > typesetting machines.  They include shift codes Teletype machines used 5-bit Baudot code, including shifts between "Figs" and "Letters." The ILLIAC I console was a TTY. ILLIAC used hexadecimal input. But instead of 0-9 and A-F, it used letters that were 10-15 in binary in Baudot "Figs" mode: KSNJFL. There were two mnemonics to remember that: "King Size Numbers Just For Laughs" and "Kind Souls Never Jostle Fat Ladies." --===============0485227629102618293==-- From van.snyder@sbcglobal.net Sat Feb 15 23:10:25 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:10:15 -0800 Message-ID: <9aed0f0b580f20c52772906dc88a52c759fe0bca.camel@sbcglobal.net> In-Reply-To: <3461d209-25ea-4d20-8369-4bb59f2087d5@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5219591224120181072==" --===============5219591224120181072== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 21:19 +0000, Frank Leonhardt via cctalk wrote: > > There might be a reader somewhere. If anybody has (or developes) an > > 803B emulator, it would be nice to have the compiler. > > > > Paul Pierce read several IBM 1401 tapes. The Computer History > > Museum in > > Mountain View, CA has two operating 1401s, and the SimH project has > > an > > emulator. It's nice to have the Autocoder assembler, FORTRAN II and > > FORTRAN IV compilers, COBOL compiler, … to use. There are students > > at > > San Jose State University who go to classes in 1401 programming at > > CHM. > > > > Maybe Paul has a paper tape reader too. > > > Peter Onion has a rather fine 803 emulator, and the Algol tapes. And > a > working 803. I've only got bits of one in my shed. > > https://www.peteronion.org.uk/Elliott/ Paul Pierce just told me that Al Kossow has a paper tape reader at CMH. CHM can also read 7-track mag tapes on their 1401s. --===============5219591224120181072==-- From van.snyder@sbcglobal.net Sat Feb 15 23:13:54 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:13:46 -0800 Message-ID: <182d1cb3d361fd349c5022e33e22fa17a43e4116.camel@sbcglobal.net> In-Reply-To: <3BDAF0A9-0E72-4553-9D70-35FD250848A7@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7289129430382176597==" --===============7289129430382176597== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 17:19 -0500, Paul Koning via cctalk wrote: > Oh?  Certainly by today's standards a drum memory machine is quite > slow.  But in their day they were used for serious work. For more than 16 years at JPL, we used Univac 1108, later 1110, 1100/40, then 1100/80, then Clearpath 2200 (CMOS ICs instead of bipolar discrete). In the 1108s, we had eleven core-loads of swap on FH432 (4 millisecond) drums. We ran fifty demand jobs and ten batch jobs, pretty much 24/7. Univac said it was impossible to do that much, but they weren't interested in having Tom Lang's modifications or tunings to EXEC 8 (later OS/1100). --===============7289129430382176597==-- From cclist@sydex.com Sat Feb 15 23:19:16 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 23:19:07 +0000 Message-ID: In-Reply-To: =?utf-8?q?=3CCO1PR08MB7208A0264DC981E87534432CE4F92=40CO1PR08MB?= =?utf-8?q?7208=2Enamprd08=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5621077105587261931==" --===============5621077105587261931== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/15/25 12:34, Wayne S via cctalk wrote: > 6 bit characters were used by CDC 24 bit machines. 4 chars per 24 bit word. There were *many* six-bit codes, even differing among systems offered by the same vendor. exempli gratia: IBM 1401/1620/7090 CDC 1604/3000/6000; all different between the various machines. CDC 6000 Display code is an interesting one; as the 00 code could either be an end-of-record/line or a colon, depending on the placement in a 60 bit word. CDC also supported 6 bit ASCII subset on some of their systems. I recall a proposal in the 70s being circulated around CDC CPD as to what should be done to extend the nominally 63/64 character set to 8 bits. The scheme that was eventually adopted repurposed some codes as "escape" or prefix codes. But there were proposals for 10 bit characters (6 per word) and one that I was particularly fond of: 7.5 characters per word, each word being called a "snaque" (get it? bit/byte/snaque...) Univac used Fieldata well into the 80s, ISTR. --Chuck --===============5621077105587261931==-- From van.snyder@sbcglobal.net Sat Feb 15 23:50:47 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 15:50:38 -0800 Message-ID: <3f038ceabdc159ff0ea60c2f8d1dff660bb56d85.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5495758759484883620==" --===============5495758759484883620== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 2025-02-15 at 23:19 +0000, Chuck Guzis via cctalk wrote: > Univac used Fieldata well into the 80s, ISTR. Well beyond then. The Clearpath 2200 went out the door in the early 2000's, when Angus McRonald retired. He was the last one left who was using old Voyager codes that were trapped in the Univac because nobody wanted to pay to revise them for newer computers. Univac also had a quarter-word mode for ASCII, even as far back as 1108. The newer FORTRAN V compiler was called the ASCII compiler because CHARACTER type was, by default, quarter-word instead of sixth-word. --===============5495758759484883620==-- From elson@pico-systems.com Sun Feb 16 01:05:33 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 19:05:25 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2913786296544993885==" --===============2913786296544993885== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/15/25 15:31, Adrian Stoness via cctalk wrote: > u had a bendix running or still running? > Nope.  In about 1973 or so, one of the guys in our group spotted a NASA listing of a Bendix G15 free for the cost of shipping (which was not insignificant!) He convinced the Engineering School to pay for it.  It had been on a NASA spaceflight tracking ship, and was "supposed" to be operational.  We got it delivered, hooked up to massive 240 V power feed, and started trying to learn how to run the thing. Nobody ever really got the hang of it, they were all used to lights and switches consoles.  The G15 did almost everything through the typewriter.  You could dump a block of drum tracks with a written command. I spent a few days poking at it and I really couldn't get it to do a whole lot.  Very likely dirty contacts in the keyboard were garbling the commands I thought I was entering.  I THINK the typewriter dutifully printed whatever you typed via mechanical coupling, even if the computer did not register those keystrokes. There was a huge box of telephone-style relays that sat under the typewriter that I think encoded the key contacts to a binary code.  So, PLENTY of contacts that could foul up the encoding. Anyway, I got pretty frustrated, and eventually pulled the cover off the drum and discovered there were two tracks totally scored down to the brass, and a couple more that were a bit scored.  The cover on the drum was just deep drawn aluminum with caterpillar grommets around the cable entries.  NOWHERE NEAR a hermetic seal! After that discovery, there was not much interest in the beast. Jon --===============2913786296544993885==-- From d44617665@hotmail.com Sun Feb 16 02:15:50 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 02:15:41 +0000 Message-ID: In-Reply-To: <9aed0f0b580f20c52772906dc88a52c759fe0bca.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8174763065173894972==" --===============8174763065173894972== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I want a piece of the action. I have an 8-channel paper tape reader and I'm = happy to archive any tape you care to bring by. Dave Wise in Hillsboro Oregon ________________________________ From: Van Snyder via cctalk Sent: Saturday, February 15, 2025 3:10 PM To: cctalk(a)classiccmp.org Cc: Van Snyder Subject: [cctalk] Re: Elliott Algol On Sat, 2025-02-15 at 21:19 +0000, Frank Leonhardt via cctalk wrote: > > There might be a reader somewhere. If anybody has (or developes) an > > 803B emulator, it would be nice to have the compiler. > > > > Paul Pierce read several IBM 1401 tapes. The Computer History > > Museum in > > Mountain View, CA has two operating 1401s, and the SimH project has > > an > > emulator. It's nice to have the Autocoder assembler, FORTRAN II and > > FORTRAN IV compilers, COBOL compiler, =E2=80=A6 to use. There are students > > at > > San Jose State University who go to classes in 1401 programming at > > CHM. > > > > Maybe Paul has a paper tape reader too. > > > Peter Onion has a rather fine 803 emulator, and the Algol tapes. And > a > working 803. I've only got bits of one in my shed. > > https://www.peteronion.org.uk/Elliott/ Paul Pierce just told me that Al Kossow has a paper tape reader at CMH. CHM can also read 7-track mag tapes on their 1401s. --===============8174763065173894972==-- From d44617665@hotmail.com Sun Feb 16 02:18:21 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 02:18:15 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0484136365655029208==" --===============0484136365655029208== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Usagi Electric on youtube has restored a G15 if I understand correctly. Incl= uding a project to re-coat a crashed drum. ________________________________ From: Jon Elson via cctalk Sent: Saturday, February 15, 2025 5:05 PM To: Adrian Stoness via cctalk Cc: Jon Elson Subject: [cctalk] Re: Elliott Algol On 2/15/25 15:31, Adrian Stoness via cctalk wrote: > u had a bendix running or still running? > Nope. In about 1973 or so, one of the guys in our group spotted a NASA listing of a Bendix G15 free for the cost of shipping (which was not insignificant!) He convinced the Engineering School to pay for it. It had been on a NASA spaceflight tracking ship, and was "supposed" to be operational. We got it delivered, hooked up to massive 240 V power feed, and started trying to learn how to run the thing. Nobody ever really got the hang of it, they were all used to lights and switches consoles. The G15 did almost everything through the typewriter. You could dump a block of drum tracks with a written command. I spent a few days poking at it and I really couldn't get it to do a whole lot. Very likely dirty contacts in the keyboard were garbling the commands I thought I was entering. I THINK the typewriter dutifully printed whatever you typed via mechanical coupling, even if the computer did not register those keystrokes. There was a huge box of telephone-style relays that sat under the typewriter that I think encoded the key contacts to a binary code. So, PLENTY of contacts that could foul up the encoding. Anyway, I got pretty frustrated, and eventually pulled the cover off the drum and discovered there were two tracks totally scored down to the brass, and a couple more that were a bit scored. The cover on the drum was just deep drawn aluminum with caterpillar grommets around the cable entries. NOWHERE NEAR a hermetic seal! After that discovery, there was not much interest in the beast. Jon --===============0484136365655029208==-- From van.snyder@sbcglobal.net Sun Feb 16 02:41:31 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 18:41:21 -0800 Message-ID: <333ec299072213b1743e3ec80a56c8bcc5b94948.camel@sbcglobal.net> In-Reply-To: =?utf-8?q?=3CCYXPR84MB3515915FFEE63923FD3A7E6AAEF82=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4556521097717492898==" --===============4556521097717492898== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 02:18 +0000, David Wise via cctalk wrote: > Usagi Electric on youtube has restored a G15 if I understand > correctly.  Including a project to re-coat a crashed drum. Harry Husky, the G15 designer, was one of the computer design pioneers. He became a professor (maybe adjunct) at UC Berkeley. When he retired from Bendix they gave him a G15 that he kept at home. It was, AFAIK, the first "home computer," even before Honeywell's. I wonder if Husky's G15 still works? Maybe it's the one at CHM, which appears to be no longer on display — probably sitting in a warehouse. --===============4556521097717492898==-- From cclist@sydex.com Sun Feb 16 02:59:40 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 02:59:32 +0000 Message-ID: <38a8de0c-7e8b-4911-b263-491ebba54258@sydex.com> In-Reply-To: <3f038ceabdc159ff0ea60c2f8d1dff660bb56d85.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1342140989711139121==" --===============1342140989711139121== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/15/25 15:50, Van Snyder via cctalk wrote: > On Sat, 2025-02-15 at 23:19 +0000, Chuck Guzis via cctalk wrote: >> Univac used Fieldata well into the 80s, ISTR. > > Well beyond then. The Clearpath 2200 went out the door in the early > 2000's, when Angus McRonald retired. He was the last one left who was > using old Voyager codes that were trapped in the Univac because nobody > wanted to pay to revise them for newer computers. Univac also had a > quarter-word mode for ASCII, even as far back as 1108. The newer > FORTRAN V compiler was called the ASCII compiler because CHARACTER type > was, by default, quarter-word instead of sixth-word. I remember the 1108--you could have 6, 9 or 12 bit "bytes". The PDP-10 used 7 bit ASCII--5 characters/word. But not 8. --Chuck --===============1342140989711139121==-- From imp@bsdimp.com Sun Feb 16 03:41:53 2025 From: Warner Losh To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 20:41:34 -0700 Message-ID: In-Reply-To: <38a8de0c-7e8b-4911-b263-491ebba54258@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5891924775670419093==" --===============5891924775670419093== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, Feb 15, 2025, 7:59=E2=80=AFPM Chuck Guzis via cctalk wrote: > On 2/15/25 15:50, Van Snyder via cctalk wrote: > > On Sat, 2025-02-15 at 23:19 +0000, Chuck Guzis via cctalk wrote: > >> Univac used Fieldata well into the 80s, ISTR. > > > > Well beyond then. The Clearpath 2200 went out the door in the early > > 2000's, when Angus McRonald retired. He was the last one left who was > > using old Voyager codes that were trapped in the Univac because nobody > > wanted to pay to revise them for newer computers. Univac also had a > > quarter-word mode for ASCII, even as far back as 1108. The newer > > FORTRAN V compiler was called the ASCII compiler because CHARACTER type > > was, by default, quarter-word instead of sixth-word. > > I remember the 1108--you could have 6, 9 or 12 bit "bytes". > The PDP-10 used 7 bit ASCII--5 characters/word. > > But not 8. > Well... the pdp-10 could use any number of bits per character... the underlying instructions made packing and unpacking easy. Warner > --Chuck > > > --===============5891924775670419093==-- From van.snyder@sbcglobal.net Sun Feb 16 04:11:34 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 20:11:21 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6075194568639419366==" --===============6075194568639419366== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 2025-02-15 at 20:41 -0700, Warner Losh via cctalk wrote: > Well... the pdp-10 could use any number of bits per character... the > underlying instructions made packing and unpacking easy. I think the Burroughs (Who?) 1700 had instructions that made accessing any sequence of bits easy — maybe up to a word length but not necessarily in the same word. --===============6075194568639419366==-- From lewissa78@gmail.com Sun Feb 16 04:11:40 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sat, 15 Feb 2025 22:11:18 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CCO1PR08MB72086D61EC020A91FE644008E4F92=40CO1PR08MB?= =?utf-8?q?7208=2Enamprd08=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2024510757873617816==" --===============2024510757873617816== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Wayne, the attachment has showed up for me (using regular "gmail" web client). I'm not sure what part of the system here decides to filter out attachments. But to Mike, I wanted to report Thanks for the attachment, it did work for me at least. Had an interesting talk with Usagi today around his LGP-21 (yes from 1963), debating whether the ASR-33 was RS-232 or not. He thinks not all ASR-33 were current-loop, but whether they were adapted after the fact, we're not sure (there was also KSR-33 and RO-devices). Also, today I discovered the world of early building security systems that used RS-232 to do biometrics (hand scanners of literal hands and such). -Steve On Sat, Feb 15, 2025 at 3:26 PM Wayne S wrote: > I don’t see the attachment. > > Sent from my iPhone > > > On Feb 15, 2025, at 13:22, Mike Stein via cctalk > wrote: > > > > In the keyboard section of the attached document there are instructions > for > > testing with a terminal & USB>TTL RS-232 adapter. > > > >> On Sat, Feb 15, 2025 at 12:43 AM Steve Lewis > wrote: > >> > >> Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom" > >> 4-pin wire (one of them being 5V power). So just level-shift the TX/RX > >> pins through a MAX232 IC and it would talk to another R-232 system at > 300 > >> baud eh? Might have to seek out a lone Kaypro keyboard to give it a > try. > >> > >> I suspect some of the "serial style" mid-1980s IBM Model M keyboards are > >> similar. But I'm still wondering if anyone used this concept in the > late > >> 1960s - teletypes were expensive, flipping switches was tedious, so > >> keyboard alternates were hot items by early 70's (hence the TVT > popularity). > >> > >>> On Fri, Feb 14, 2025 at 5:28 PM Mike Stein > wrote: > >>> > >>> I believe that at least Kaypro used a TTL form of RS-232 for the > >>> keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of > a > >>> keyboard in distant days. > >>> > >>> On Fri, Feb 14, 2025 at 12:27 PM Steve Lewis via cctalk < > >>> cctalk(a)classiccmp.org> wrote: > >>> > >>>> Rick Bensene: > >>>> > >>>>> I will try to find my Xircom parallel port Modem and Ethernet > adapters > >>>> in > >>>>> a box somewhere in my storage area and take a photo of them. If I > can > >>>> find > >>>>> them, I’ll post a link here to the photos so those in disbelief can > see > >>>>> them. > >>>> > >>>> > >>>> That'd be neat to see, if you do find the Xircom parallel modem. I've > >>>> seen > >>>> combo ones and their "parallel-ethernet" devices (which seem to go for > >>>> quite a premium these days), but not the modem only. Suppose they > >>>> weren't > >>>> too popular, as even laptops started to have built in modems. > >>>> > >>>> These days, I do use an SDLPT, that lets you use SD-cards to transfer > >>>> data > >>>> into a system over the parallel port. I suppose that's the same > general > >>>> principle (of read/writing one full byte at a time to a device). I > >>>> haven't measured its performance yet (but would characterize it as > being > >>>> comparable to a physical 3.5" floppy disk drive kind of performance - > I > >>>> think copying Quake took over 40 minutes, something like that; but I'd > >>>> like > >>>> to get more accurate about it, down to an actual bytes-per-second > rate). > >>>> Measuring that might give me an answer on how fast something like > >>>> Laplink/Interlink cable should be able to perform. > >>>> > >>>> As another experiment, I'll drop that ~7MHz 16550 serial card into a > 386, > >>>> and see if I can get a 386 to push data out on RS-232 faster than > 115200. > >>>> It should, but we'll see! > >>>> > >>>> > >>>> And I think I will do an RS-232 themed talk in June VCF, if a spot is > >>>> still > >>>> open - I think I have enough now to make it interesting. One area > I'm a > >>>> little stuck on is verifying that anyone actually did make an RS-232 > >>>> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize > that > >>>> as > >>>> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) > to > >>>> the > >>>> PDP-1, but might not be accurate to call that RS-232 (but can't a > current > >>>> loop based thing be adapted to voltage?). I thought the POLY-88 > keyboard > >>>> was RS-232, but it'll be awhile before I can get back to that > equipment. > >>>> > >>>> > >>>> -Steve > >>>> > >>>> > >>>> > >>>> On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk < > >>>> cctalk(a)classiccmp.org> wrote: > >>>> > >>>>> Henry wrote: > >>>>> > >>>>>> I remember those, and when I went searching to look for more > >>>> information > >>>>> on them I found something I > hadn't stumbled on before - apparently > >>>> Xircom > >>>>> made a parallel port Ethernet adapter. It must have > >>>>>> been pretty painful. The parallel port wasn't a great high speed > >>>>> interface… > >>>>> > >>>>> ---- > >>>>> > >>>>> Yes, I have one of those parallel port Ethernet devices too. But, > >>>>> remember, back at that time, Ethernet was commonly 10Mb/Sec. I think > >>>> that > >>>>> 100Mb/Sec was only located in high-end datacenters and was very > >>>> expensive. > >>>>> For a laptop that didn’t have a PCMCIA port, and you wanted it on an > >>>>> Ethernet network, this was an acceptable way to go. Performance > wasn’t > >>>>> great, but most of the time laptops like this were used for TELNET > >>>>> connections to other hosts on the local network for “GREEN SCREEN” > type > >>>>> applications that ran entirely on the remote host. Performance in > such > >>>>> cases wasn’t nearly as much of a concern as it would be in the not > too > >>>>> distant future. > >>>>> > >>>>> I will try to find my Xircom parallel port Modem and Ethernet > adapters > >>>> in > >>>>> a box somewhere in my storage area and take a photo of them. If I > can > >>>> find > >>>>> them, I’ll post a link here to the photos so those in disbelief can > see > >>>>> them. > >>>>> > >>>>> -Rick > >>>>> > >>>>> > >>>>> > >>>>> From: Henry Bent [mailto:henry.r.bent(a)gmail.com] > >>>>> Sent: Thursday, February 13, 2025 3:54 PM > >>>>> To: General Discussion: On-Topic and Off-Topic Posts < > >>>>> cctalk(a)classiccmp.org> > >>>>> Cc: Rick Bensene > >>>>> Subject: Re: [cctalk] Re: RS232 - parallel modems!? > >>>>> > >>>> > >>> > --===============2024510757873617816==-- From lewissa78@gmail.com Sun Feb 16 04:24:54 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 22:24:39 -0600 Message-ID: In-Reply-To: <0fd5ac37-ad58-4b01-9f60-3402625ea70a@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4493809756688163200==" --===============4493809756688163200== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit I'm not very familiar with ALGOL, but just today I met someone at VCF who has essentially built a replica of the LGP-30 (in FPGA form, more on that to come down the road, but it is a system from 1955/1956). Then related to that, two different people mentioned to me of an early ALGOL compiler being available for the LGP-30. I don't know if that was of a form to be considered any kind of "block structure" as you mentioned. But it is sad that the ego of those who "hold the pen" (as it were) for Wikipedia is influencing the content. While Google can pretty far and wide, the testimony of "someone who was there" should be considered (and can be in a section noted as such). -Steve On Sat, Feb 15, 2025 at 9:09 AM Frank Leonhardt via cctalk < cctalk(a)classiccmp.org> wrote: > As those of us with a few years will know, Tony Hoare (and Jill's) > implementation of Algol 60 on the Elliott 803 was a highly significant > event in the history of computer languages. It was the first practical > commercial Algol compiler, launched block structures languages, and > played a part in Elliott selling nearly 300 803B computers at a time > when 300 computers was a big number. > > Obviously the US preferred Fortran and COBOL for commercial use, and > there were other Algol compilers in some shape or other knocking about > in universities. But I'd say this implementation put block structured > programming into the mainstream. (And it was the first high level > language I used, but that's beside the point). > > Now some kid on Wikipedia thinks it's not notable and is trying to > delete it because he can't find much on it doing a Google search. > Wikipedia may be sinking under activists and egos, but I think we need > to put this misapprehension straight. Unfortunately we may be arguing > with an idiot. > > https://en.wikipedia.org/wiki/Elliott_ALGOL > > If course, if anyone thinks it wasn't significant, that's an opinion > too, but I'd like to hear why. > > Thanks, Frank. > > > --===============4493809756688163200==-- From prp@teleport.com Sun Feb 16 06:05:36 2025 From: Paul Pierce To: cctalk@classiccmp.org Subject: [cctalk] "Re: Re: Elliott Algol" Date: Sat, 15 Feb 2025 22:02:21 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4673408138079327129==" --===============4673408138079327129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Al has a reader at CHM. They can read tapes too, my 7-track setup is now at S= ystem Source. Paul > On Sat, 2025-02-15 at 14:52 +0000, Sid Jones via cctalk wrote: > > IIRC, I have a copy of the Elliot 803 A-103 Algol compiler on a five- > > hole=20 > > tape in a drawer somewhere in my untidy office... > >=20 > > As used in UCNW Bangor, 1971-1974. >=20 > There might be a reader somewhere. If anybody has (or developes) an > 803B emulator, it would be nice to have the compiler. >=20 > Paul Pierce read several IBM 1401 tapes. The Computer History Museum in > Mountain View, CA has two operating 1401s, and the SimH project has an > emulator. It's nice to have the Autocoder assembler, FORTRAN II and > FORTRAN IV compilers, COBOL compiler, =C3=A2=C2=80=C2=A6 to use. There are = students at > San Jose State University who go to classes in 1401 programming at CHM. >=20 > Maybe Paul has a paper tape reader too. >=20 >=20 >=20 >=20 --===============4673408138079327129==-- From curiousmarc3@gmail.com Sun Feb 16 07:21:56 2025 From: Curious Marc To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sat, 15 Feb 2025 23:21:40 -0800 Message-ID: In-Reply-To: <333ec299072213b1743e3ec80a56c8bcc5b94948.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2995249723623787350==" --===============2995249723623787350== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable We have two G15=E2=80=99s at CHM, one currently on exhibit and one in the war= ehouse. Lovely machine. Very huggable.=20 Marc > On Feb 15, 2025, at 6:48=E2=80=AFPM, Van Snyder via cctalk wrote: >=20 > =EF=BB=BFOn Sun, 2025-02-16 at 02:18 +0000, David Wise via cctalk wrote: >> Usagi Electric on youtube has restored a G15 if I understand >> correctly. Including a project to re-coat a crashed drum. >=20 > Harry Husky, the G15 designer, was one of the computer design pioneers. > He became a professor (maybe adjunct) at UC Berkeley. When he retired > from Bendix they gave him a G15 that he kept at home. It was, AFAIK, > the first "home computer," even before Honeywell's. I wonder if Husky's > G15 still works? Maybe it's the one at CHM, which appears to be no > longer on display =E2=80=94 probably sitting in a warehouse. >=20 --===============2995249723623787350==-- From classiccmp@fjl.co.uk Sun Feb 16 10:53:24 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 10:53:08 +0000 Message-ID: <5ba6b420-2ed6-4eab-97e0-7a80678093d9@fjl.co.uk> In-Reply-To: =?utf-8?q?=3CCYXPR84MB35155D17D0E262E6738256CFAEF82=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2491380629896270663==" --===============2491380629896270663== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 16/02/2025 02:15, David Wise via cctalk wrote: > I want a piece of the action. I have an 8-channel paper tape reader and I'= m happy to archive any tape you care to bring by. > > Dave Wise in Hillsboro Oregon > > ________________________________ > From: Van Snyder via cctalk > Sent: Saturday, February 15, 2025 3:10 PM > To:cctalk(a)classiccmp.org > Cc: Van Snyder > Subject: [cctalk] Re: Elliott Algol > > On Sat, 2025-02-15 at 21:19 +0000, Frank Leonhardt via cctalk wrote: >>> There might be a reader somewhere. If anybody has (or developes) an >>> 803B emulator, it would be nice to have the compiler. >>> >>> Paul Pierce read several IBM 1401 tapes. The Computer History >>> Museum in >>> Mountain View, CA has two operating 1401s, and the SimH project has >>> an >>> emulator. It's nice to have the Autocoder assembler, FORTRAN II and >>> FORTRAN IV compilers, COBOL compiler, =E2=80=A6 to use. There are students >>> at >>> San Jose State University who go to classes in 1401 programming at >>> CHM. >>> >>> Maybe Paul has a paper tape reader too. >>> >> Peter Onion has a rather fine 803 emulator, and the Algol tapes. And >> a >> working 803. I've only got bits of one in my shed. >> >> https://www.peteronion.org.uk/Elliott/ > Paul Pierce just told me that Al Kossow has a paper tape reader at CMH. > CHM can also read 7-track mag tapes on their 1401s. That's one of the parts I have in my shed :-) --===============2491380629896270663==-- From classiccmp@fjl.co.uk Sun Feb 16 14:46:33 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 14:46:17 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1232258662713272961==" --===============1232258662713272961== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 16/02/2025 04:24, Steve Lewis via cctalk wrote: > I'm not very familiar with ALGOL, but just today I met someone at VCF who > has essentially built a replica of the LGP-30 (in FPGA form, more on that > to come down the road, but it is a system from 1955/1956). Then related to > that, two different people mentioned to me of an early ALGOL compiler being > available for the LGP-30. I don't know if that was of a form to be > considered any kind of "block structure" as you mentioned. I had the impression from talking to people (quite possibly Tony Hoare, but I don't want to put words in his mouth) that Algol was not, initially, a programming language - it was a structured English to express algorithms. As such it was natural for academics to try and make their computers understand it, whether it was practical or not. This is relying on my memory of conversations that took place decades ago, and the opinion of whoever I was as taking to. But it does fit the evidence. Firstly there were multiple dialects of Algol - just like things like UML. It didn't crystallise until Algol 60 (and then only loosely). Secondly, at the time it first showed up there wasn't a computer available with the power to run it. As people have pointed out, there were instances of people implementing subsets on machines with a drum store. Pioneering stuff indeed. Without evidence otherwise, I believe all of these student Algol implementations to be interesting research rather than practical high level languages. I'd be happy to hear of any evidence otherwise - in other words third-parties using them from real-world application programming. As to the Librascope Algol 30 written it Dartmouth, I'm sure it was wasn't a full implementation. It probably did include BEGIN/END (I'd love to see some examples) but there was a lot of stuff that was very tricky to implement and most "tiny Algol" implementations missed most of it off. Incidentally, I'm very sure that Algol 58 was the first language to implement the BEGIN...END structure. The DO element was also new, but dropped (and the keyword repurposed) in Algol 60. Otherwise 58 was a subset of 60. --===============1232258662713272961==-- From lewissa78@gmail.com Sun Feb 16 15:25:57 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 09:25:41 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0758214652999664532==" --===============0758214652999664532== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul Koning > It would be great to learn more about that. It's a rather early machine > for ALGOL to show up there, though a precedessor of ALGOL (IAL, > "International Algebraic Language") appeared in 1958. That was a bit of a > mess and the 1960 Report on ALGOL-60 is quite different. Apparently IAL > served as the inspiration for JOVIAL, though in my view the designer of > JOVIAL clearly demonstrated that he didn't at all understand the core > principles of IAL or ALGOL. I had the pleasure of using JOVIAL on one of the F-16 subsystems. I recall its "A" type, a kind of user-defined fixed type (where you controlled the amount of precision/resolution you needed). On Sun, Feb 16, 2025 at 8:32=E2=80=AFAM Paul Koning wrote: > > > > On Feb 15, 2025, at 11:24=E2=80=AFPM, Steve Lewis via cctalk < > cctalk(a)classiccmp.org> wrote: > > > > I'm not very familiar with ALGOL, but just today I met someone at VCF who > > has essentially built a replica of the LGP-30 (in FPGA form, more on that > > to come down the road, but it is a system from 1955/1956). Then related > to > > that, two different people mentioned to me of an early ALGOL compiler > being > > available for the LGP-30. I don't know if that was of a form to be > > considered any kind of "block structure" as you mentioned. > > It would be great to learn more about that. It's a rather early machine > for ALGOL to show up there, though a precedessor of ALGOL (IAL, > "International Algebraic Language") appeared in 1958. That was a bit of a > mess and the 1960 Report on ALGOL-60 is quite different. Apparently IAL > served as the inspiration for JOVIAL, though in my view the designer of > JOVIAL clearly demonstrated that he didn't at all understand the core > principles of IAL or ALGOL. > > A lot of early "ALGOL" compilers did major subsetting because it was > considered to hard to do the real language. Those subsets may not actually > bear any real resemblance to the actual language. For example, a "subset" > that omits recursion is not ALGOL but rather a mongrel joke. > > One of the major contributions of Dijkstra and Zonneveld isn't just that > they built the first compiler for the full ALGOL-60, but that they invented > all the major compiler construction mechanisms to make that possible. This > is analyzed very well and in impressive detail in the Ph.D. Thesis of > Gauthier van den Hove. > > paul > > --===============0758214652999664532==-- From elson@pico-systems.com Sun Feb 16 15:49:08 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 - parallel modems!? Date: Sun, 16 Feb 2025 09:48:58 -0600 Message-ID: <2cc32466-b1cc-24cc-e364-ea17c5e35359@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6152248584544511647==" --===============6152248584544511647== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/15/25 22:11, Steve Lewis via cctalk wrote: > > Had an interesting talk with Usagi today around his LGP-21 (yes from 1963), > debating whether the ASR-33 was RS-232 or not. He thinks not all ASR-33 > were current-loop, but whether they were adapted after the fact, we're not > sure (there was also KSR-33 and RO-devices). I believe there was an optional RS-232 to current loop converter board that could be supplied by Teletype so the ASR33 could be used with a standard RS-232 modem for dial-up use.  It was a fairly small card about the size of a credit card IIRC. Jon --===============6152248584544511647==-- From paulkoning@comcast.net Sun Feb 16 16:20:18 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 09:32:30 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5365710059982978184==" --===============5365710059982978184== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 15, 2025, at 11:24=E2=80=AFPM, Steve Lewis via cctalk wrote: >=20 > I'm not very familiar with ALGOL, but just today I met someone at VCF who > has essentially built a replica of the LGP-30 (in FPGA form, more on that > to come down the road, but it is a system from 1955/1956). Then related to > that, two different people mentioned to me of an early ALGOL compiler being > available for the LGP-30. I don't know if that was of a form to be > considered any kind of "block structure" as you mentioned. It would be great to learn more about that. It's a rather early machine for = ALGOL to show up there, though a precedessor of ALGOL (IAL, "International Al= gebraic Language") appeared in 1958. That was a bit of a mess and the 1960 R= eport on ALGOL-60 is quite different. Apparently IAL served as the inspirati= on for JOVIAL, though in my view the designer of JOVIAL clearly demonstrated = that he didn't at all understand the core principles of IAL or ALGOL. A lot of early "ALGOL" compilers did major subsetting because it was consider= ed to hard to do the real language. Those subsets may not actually bear any = real resemblance to the actual language. For example, a "subset" that omits = recursion is not ALGOL but rather a mongrel joke. One of the major contributions of Dijkstra and Zonneveld isn't just that they= built the first compiler for the full ALGOL-60, but that they invented all t= he major compiler construction mechanisms to make that possible. This is ana= lyzed very well and in impressive detail in the Ph.D. Thesis of Gauthier van = den Hove. paul --===============5365710059982978184==-- From paulkoning@comcast.net Sun Feb 16 16:20:22 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 09:56:41 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8494721254382885926==" --===============8494721254382885926== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 9:46=E2=80=AFAM, Frank Leonhardt via cctalk wrote: >=20 > On 16/02/2025 04:24, Steve Lewis via cctalk wrote: >> I'm not very familiar with ALGOL, but just today I met someone at VCF who >> has essentially built a replica of the LGP-30 (in FPGA form, more on that >> to come down the road, but it is a system from 1955/1956). Then related to >> that, two different people mentioned to me of an early ALGOL compiler being >> available for the LGP-30. I don't know if that was of a form to be >> considered any kind of "block structure" as you mentioned. >=20 > I had the impression from talking to people (quite possibly Tony Hoare, but= I don't want to put words in his mouth) that Algol was not, initially, a pro= gramming language - it was a structured English to express algorithms. As suc= h it was natural for academics to try and make their computers understand it,= whether it was practical or not. My father (a metrologist and professor of mechanical engineering) would read = ALGOL programs written by others, based on their resemblance to English. An= d yes, it was for years the choice for expressing algorithms in journals such= as CACM. The fashion of rendering keywords as bold text fits that usage ver= y well. On the other hand, it's clear that, at least starting with ALGOL 60, we're de= aling with a programming language meant to be run on actual computers, and if= there was any doubt about that the work of Dijkstra et al. should settle the= question. > This is relying on my memory of conversations that took place decades ago, = and the opinion of whoever I was as taking to. But it does fit the evidence. = Firstly there were multiple dialects of Algol - just like things like UML. It= didn't crystallise until Algol 60 (and then only loosely). Secondly, at the = time it first showed up there wasn't a computer available with the power to r= un it. As people have pointed out, there were instances of people implementin= g subsets on machines with a drum store. Pioneering stuff indeed. >=20 > Without evidence otherwise, I believe all of these student Algol implementa= tions to be interesting research rather than practical high level languages. = I'd be happy to hear of any evidence otherwise - in other words third-parties= using them from real-world application programming. >=20 > As to the Librascope Algol 30 written it Dartmouth, I'm sure it was wasn't = a full implementation. It probably did include BEGIN/END (I'd love to see som= e examples) but there was a lot of stuff that was very tricky to implement an= d most "tiny Algol" implementations missed most of it off. If a language doesn't have blocks (whether with begin/end keywords or somethi= ng equivalent, as ALGOL 68 allows) it can't reasonably be called ALGOL or eve= n a subset. > Incidentally, I'm very sure that Algol 58 was the first language to impleme= nt the BEGIN...END structure. The DO element was also new, but dropped (and t= he keyword repurposed) in Algol 60. Otherwise 58 was a subset of 60. Well, "ALGOL 58" is not a thing. The document describing the 1958 language c= alled it "International Algebraic Language". I only glanced at it -- the fir= st time I saw an actual description is when I read the 1958 report in an appe= ndix of Gauthier's thesis -- but my memory is that it can't be thought of as = a subset of Algol 60 but rather a dead end relative that went off in a wrong = direction that the 1960 report abandoned. paul --===============8494721254382885926==-- From bfranchuk@jetnet.ab.ca Sun Feb 16 16:56:58 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 09:56:50 -0700 Message-ID: <09488324-61f3-4875-991d-6f815815ff7d@jetnet.ab.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1895657672430609601==" --===============1895657672430609601== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-16 7:32 a.m., Paul Koning via cctalk wrote: > A lot of early "ALGOL" compilers did major subsetting because it was consid= ered to hard to do the real language. Those subsets may not actually bear an= y real resemblance to the actual language. For example, a "subset" that omit= s recursion is not ALGOL but rather a mongrel joke. >=20 I disagree here, recursion is just one method of problem solving. While I think, function nesting is too complex for most use, the use of=20 stack based local variables in blocks was a important step foreword. Playing around with META-II, compiler compiler I discovered it had no way of handling local variables and symbol tables, as it just moved=20 text around.I could parse fine, but not generate code. Did many people believe back then that one could just shuffle text=20 around to solve new programing languages like Algol, where it might work=20 with something like Fortran, with some sort of macro processing language. > paul >=20 --===============1895657672430609601==-- From cclist@sydex.com Sun Feb 16 16:59:14 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 16:59:05 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1041833280050248420==" --===============1041833280050248420== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/16/25 06:56, Paul Koning via cctalk wrote: > My father (a metrologist and professor of mechanical engineering) would rea= d ALGOL programs written by others, based on their resemblance to English. = And yes, it was for years the choice for expressing algorithms in journals su= ch as CACM. The fashion of rendering keywords as bold text fits that usage v= ery well. CALGO ever since the beginning has also allowed algorithms in FORTRAN, it being the only language a lot of number-heavy shops use (e.g. JPL). Algol had the reputation of being a language used mostly by Europeans. --Chuck --===============1041833280050248420==-- From paulkoning@comcast.net Sun Feb 16 18:08:48 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 13:08:29 -0500 Message-ID: <8D1E249F-2294-4A25-884A-08F47C12CFAE@comcast.net> In-Reply-To: <09488324-61f3-4875-991d-6f815815ff7d@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0414341467914216480==" --===============0414341467914216480== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 11:56=E2=80=AFAM, ben via cctalk wrote: >=20 > On 2025-02-16 7:32 a.m., Paul Koning via cctalk wrote: >=20 >> A lot of early "ALGOL" compilers did major subsetting because it was consi= dered to hard to do the real language. Those subsets may not actually bear a= ny real resemblance to the actual language. For example, a "subset" that omi= ts recursion is not ALGOL but rather a mongrel joke. >=20 > I disagree here, recursion is just one method of problem solving. That's true but not my point. Yes, you can solve it in Fortran II, without r= ecursion, even if the most natural solution is a recursive one. My point is that support for recursion, and nested blocks, and nested scopes,= is the essence of ALGOL and what makes it different from FORTRAN II. So a l= anguage that omits one of those elements cannot legitimately call itself a va= riant or subset of ALGOL, any more than a language without pointers can legit= imately call itself a subset of C. > While I think, function nesting is too complex for most use, the use of sta= ck based local variables in blocks was a important step foreword. Function nesting is an important mechanism in some scenarios, but admittedly = much work doesn't need it. It's useful enough that GNU C added it as a compi= ler extension. > Playing around with META-II, compiler compiler I discovered it had > no way of handling local variables and symbol tables, as it just moved text= around.I could parse fine, but not generate code. Parsing -- splitting text into tokens (lexing) and building parse trees -- is= part of the compiler's job but usually the easiest part. Not quite as easy = if you want good error messages or error recovery. Code generation is an independent problem, and something that parses programs= without generating code isn't a compiler, it's at best just a front end. You might want to look at the GCC internals manual. GCC has an explicit laye= ring, with front end processing steps that construct parse trees which are th= en transformed in stages, until they reach the "target" code which converts t= he final internal representation into actual machine code. > Did many people believe back then that one could just shuffle text around t= o solve new programing languages like Algol, where it might work with somethi= ng like Fortran, with some sort of macro processing language. I doubt it. Compiler compilers (or more accurately, parser generators, like = the famous YACC) are a later development. By the time that compiler writing = textbooks like the "dragon book" (Hopcroft and Ullman, if I remember right) c= ame out, the relevant theory was well understood. But writing early compiler= s required inventing elements of that theory along the way. Again, the Dijks= tra/Zonneveld Algol compiler is an example, and Gauthier van den Hove spells = it out in detail. Dijkstra invented a stack based parser, somewhat like a re= cursive descent parser, which he called the "shunting yard" algorithm after r= ailroad yards, as a mechanism for parsing Algol. He also invented "displays"= which are a way to find the stack frame for the current static nesting of re= cursive function calls. paul --===============0414341467914216480==-- From d44617665@hotmail.com Sun Feb 16 18:13:31 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 18:13:23 +0000 Message-ID: In-Reply-To: <8D1E249F-2294-4A25-884A-08F47C12CFAE@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2229973626353107637==" --===============2229973626353107637== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Wikipedia policy excludes what they call "original research". Unless your ar= ticle was published by some major mainstream outlet, you're toast, even if yo= u are literally the last person on Earth who knows the stuff. ________________________________ From: Paul Koning via cctalk Sent: Sunday, February 16, 2025 10:08 AM To: cctalk(a)classiccmp.org Cc: Paul Koning Subject: [cctalk] Re: Elliott Algol > On Feb 16, 2025, at 11:56=E2=80=AFAM, ben via cctalk wrote: > > On 2025-02-16 7:32 a.m., Paul Koning via cctalk wrote: > >> A lot of early "ALGOL" compilers did major subsetting because it was consi= dered to hard to do the real language. Those subsets may not actually bear a= ny real resemblance to the actual language. For example, a "subset" that omi= ts recursion is not ALGOL but rather a mongrel joke. > > I disagree here, recursion is just one method of problem solving. That's true but not my point. Yes, you can solve it in Fortran II, without r= ecursion, even if the most natural solution is a recursive one. My point is that support for recursion, and nested blocks, and nested scopes,= is the essence of ALGOL and what makes it different from FORTRAN II. So a l= anguage that omits one of those elements cannot legitimately call itself a va= riant or subset of ALGOL, any more than a language without pointers can legit= imately call itself a subset of C. > While I think, function nesting is too complex for most use, the use of sta= ck based local variables in blocks was a important step foreword. Function nesting is an important mechanism in some scenarios, but admittedly = much work doesn't need it. It's useful enough that GNU C added it as a compi= ler extension. > Playing around with META-II, compiler compiler I discovered it had > no way of handling local variables and symbol tables, as it just moved text= around.I could parse fine, but not generate code. Parsing -- splitting text into tokens (lexing) and building parse trees -- is= part of the compiler's job but usually the easiest part. Not quite as easy = if you want good error messages or error recovery. Code generation is an independent problem, and something that parses programs= without generating code isn't a compiler, it's at best just a front end. You might want to look at the GCC internals manual. GCC has an explicit laye= ring, with front end processing steps that construct parse trees which are th= en transformed in stages, until they reach the "target" code which converts t= he final internal representation into actual machine code. > Did many people believe back then that one could just shuffle text around t= o solve new programing languages like Algol, where it might work with somethi= ng like Fortran, with some sort of macro processing language. I doubt it. Compiler compilers (or more accurately, parser generators, like = the famous YACC) are a later development. By the time that compiler writing = textbooks like the "dragon book" (Hopcroft and Ullman, if I remember right) c= ame out, the relevant theory was well understood. But writing early compiler= s required inventing elements of that theory along the way. Again, the Dijks= tra/Zonneveld Algol compiler is an example, and Gauthier van den Hove spells = it out in detail. Dijkstra invented a stack based parser, somewhat like a re= cursive descent parser, which he called the "shunting yard" algorithm after r= ailroad yards, as a mechanism for parsing Algol. He also invented "displays"= which are a way to find the stack frame for the current static nesting of re= cursive function calls. paul --===============2229973626353107637==-- From classiccmp@fjl.co.uk Sun Feb 16 18:17:27 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 18:17:11 +0000 Message-ID: <280eccc3-4898-4168-a01e-0b7d973e7d05@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5396547135325335327==" --===============5396547135325335327== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 16/02/2025 14:56, Paul Koning via cctalk wrote: >> On Feb 16, 2025, at 9:46=E2=80=AFAM, Frank Leonhardt via cctalk wrote: >> >> I had the impression from talking to people (quite possibly Tony Hoare, bu= t I don't want to put words in his mouth) that Algol was not, initially, a pr= ogramming language - it was a structured English to express algorithms. As su= ch it was natural for academics to try and make their computers understand it= , whether it was practical or not. > My father (a metrologist and professor of mechanical engineering) would rea= d ALGOL programs written by others, based on their resemblance to English. = And yes, it was for years the choice for expressing algorithms in journals su= ch as CACM. The fashion of rendering keywords as bold text fits that usage v= ery well. > > On the other hand, it's clear that, at least starting with ALGOL 60, we're = dealing with a programming language meant to be run on actual computers, and = if there was any doubt about that the work of Dijkstra et al. should settle t= he question. > >> This is relying on my memory of conversations that took place decades ago,= and the opinion of whoever I was as taking to. But it does fit the evidence.= Firstly there were multiple dialects of Algol - just like things like UML. I= t didn't crystallise until Algol 60 (and then only loosely). Secondly, at the= time it first showed up there wasn't a computer available with the power to = run it. As people have pointed out, there were instances of people implementi= ng subsets on machines with a drum store. Pioneering stuff indeed. >> >> Without evidence otherwise, I believe all of these student Algol implement= ations to be interesting research rather than practical high level languages.= I'd be happy to hear of any evidence otherwise - in other words third-partie= s using them from real-world application programming. >> >> As to the Librascope Algol 30 written it Dartmouth, I'm sure it was wasn't= a full implementation. It probably did include BEGIN/END (I'd love to see so= me examples) but there was a lot of stuff that was very tricky to implement a= nd most "tiny Algol" implementations missed most of it off. > If a language doesn't have blocks (whether with begin/end keywords or somet= hing equivalent, as ALGOL 68 allows) it can't reasonably be called ALGOL or e= ven a subset. > >> Incidentally, I'm very sure that Algol 58 was the first language to implem= ent the BEGIN...END structure. The DO element was also new, but dropped (and = the keyword repurposed) in Algol 60. Otherwise 58 was a subset of 60. > Well, "ALGOL 58" is not a thing. The document describing the 1958 language= called it "International Algebraic Language". I only glanced at it -- the f= irst time I saw an actual description is when I read the 1958 report in an ap= pendix of Gauthier's thesis -- but my memory is that it can't be thought of a= s a subset of Algol 60 but rather a dead end relative that went off in a wron= g direction that the 1960 report abandoned. Certainly, it's the BEGIN/END (or compound statements) that Algol=20 introduced which matter. Algol 58 had it. As to 58 not being a thing - as I said it didn't crystallise until Algol=20 60 but I'd still argue it was a thing... The origin of IAL later Algol later Algol 58 was described in the Perlis=20 and Samuelson report published by the ACM at the time (Association for=20 Computer Machinery). I'll spare you the details (I have a copy on paper=20 in front of me reproduced in Jean Sammet's "Programming languages:=20 History and Fundamentals - "Preliminary Report - International Algebraic=20 Language" from Vol 1 Issue 12). I'd love to see the "1958 report in an=20 appendix of Gauthier's thesis", but I'm sure I don't have it. =C2=A0Apart from the history, part 1 it ends: 1. The new language should be as close as possible to standard=20 mathematical notation and be readable with little further explanation.=20 [We've heard that one since!] 2. It should be possible to use it for the description of computing=20 processing in publications. 3. The new language should be mechanically translatable into machine=20 programs. It's heavily implied that the ACM/GAMM committee intended it to be a=20 standard but they don't quite say so. Algol 60 enhanced the 58 specification, but mostly by adding=20 input/output and practical stuff. As I said, as far as I can make out=20 from the 58 report, Algol 60 simply dropped DO statements, and blank=20 parameter positions. Unfortunately the preliminary report published by=20 the ACM was never followed up by another as far as I know (as mentioned=20 above the appendix to Gauthier's thesis, of which I'm unfamiliar, would=20 be of great interest!!!) It's worth noting that the Algol 58 specification was the basis for=20 other languages like JOVIAL, CLIP, NELIAC and MAD. But one really interesting first about Algol (apart from it being the=20 first inter-organisational attempt at standardising a language) is that=20 it explicitly broke it into a reference language, a publication language=20 and hardware representation. I believe the reference language was the=20 most significant, as it could be used to publish algorithms in a=20 standard form before hardware and compilers were developed to run them=20 directly. It was the only language permissible for the publication of=20 algorithms in the ACM Bulletin through most of the 1960s. I believe that=20 stuff published in the Algol Bulletin was translated into Fortran in=20 order to test it! --===============5396547135325335327==-- From paulkoning@comcast.net Sun Feb 16 18:21:00 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 13:20:42 -0500 Message-ID: <66FEBAAD-B4C3-4E5B-90E5-4C91FE6F5A22@comcast.net> In-Reply-To: =?utf-8?q?=3CCYXPR84MB3515E296AAD91EE914C820B6AEF82=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4317881603019354277==" --===============4317881603019354277== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think that was a reply to someone else's comment. You're right that "original research" doesn't go into Wikipedia. But "major = mainstream outlet" is not required. For example, the Electrologica X1 articl= e cites sources for its content, most of which are rather obscure publication= s such as tech reports in the CWI archives. The point is that it has to be p= ublished elsewhere. One of these days I'm going to redo my edits on the Frequency Modulation arti= cle to capture the earlier work by Hanso Idzerda (more than a decade before = Edwin Armstrong). Last time I did it got kicked out on BS grounds, but now t= here is a published article I can cite. In Dutch, but that doesn't matter. = :-) paul > On Feb 16, 2025, at 1:13=E2=80=AFPM, David Wise w= rote: >=20 > Wikipedia policy excludes what they call "original research". Unless your = article was published by some major mainstream outlet, you're toast, even if = you are literally the last person on Earth who knows the stuff. >=20 > From: Paul Koning via cctalk > Sent: Sunday, February 16, 2025 10:08 AM > To: cctalk(a)classiccmp.org > Cc: Paul Koning > Subject: [cctalk] Re: Elliott Algol > =20 >=20 >=20 > > On Feb 16, 2025, at 11:56=E2=80=AFAM, ben via cctalk wrote: > >=20 > > On 2025-02-16 7:32 a.m., Paul Koning via cctalk wrote: > >=20 > >> A lot of early "ALGOL" compilers did major subsetting because it was con= sidered to hard to do the real language. Those subsets may not actually bear= any real resemblance to the actual language. For example, a "subset" that o= mits recursion is not ALGOL but rather a mongrel joke. > >=20 > > I disagree here, recursion is just one method of problem solving. >=20 > That's true but not my point. Yes, you can solve it in Fortran II, without= recursion, even if the most natural solution is a recursive one. >=20 > My point is that support for recursion, and nested blocks, and nested scope= s, is the essence of ALGOL and what makes it different from FORTRAN II. So a= language that omits one of those elements cannot legitimately call itself a = variant or subset of ALGOL, any more than a language without pointers can leg= itimately call itself a subset of C. >=20 > > While I think, function nesting is too complex for most use, the use of s= tack based local variables in blocks was a important step foreword. >=20 > Function nesting is an important mechanism in some scenarios, but admittedl= y much work doesn't need it. It's useful enough that GNU C added it as a com= piler extension. >=20 > > Playing around with META-II, compiler compiler I discovered it had > > no way of handling local variables and symbol tables, as it just moved te= xt around.I could parse fine, but not generate code. >=20 > Parsing -- splitting text into tokens (lexing) and building parse trees -- = is part of the compiler's job but usually the easiest part. Not quite as eas= y if you want good error messages or error recovery. >=20 > Code generation is an independent problem, and something that parses progra= ms without generating code isn't a compiler, it's at best just a front end. >=20 > You might want to look at the GCC internals manual. GCC has an explicit la= yering, with front end processing steps that construct parse trees which are = then transformed in stages, until they reach the "target" code which converts= the final internal representation into actual machine code. >=20 > > Did many people believe back then that one could just shuffle text around= to solve new programing languages like Algol, where it might work with somet= hing like Fortran, with some sort of macro processing language. >=20 > I doubt it. Compiler compilers (or more accurately, parser generators, lik= e the famous YACC) are a later development. By the time that compiler writin= g textbooks like the "dragon book" (Hopcroft and Ullman, if I remember right)= came out, the relevant theory was well understood. But writing early compil= ers required inventing elements of that theory along the way. Again, the Dij= kstra/Zonneveld Algol compiler is an example, and Gauthier van den Hove spell= s it out in detail. Dijkstra invented a stack based parser, somewhat like a = recursive descent parser, which he called the "shunting yard" algorithm after= railroad yards, as a mechanism for parsing Algol. He also invented "display= s" which are a way to find the stack frame for the current static nesting of = recursive function calls. >=20 > paul --===============4317881603019354277==-- From spectre@floodgap.com Sun Feb 16 18:45:53 2025 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 10:45:46 -0800 Message-ID: <45d32e27-3e88-49d1-b459-f9b638520362@floodgap.com> In-Reply-To: <66FEBAAD-B4C3-4E5B-90E5-4C91FE6F5A22@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7649820546473491636==" --===============7649820546473491636== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > You're right that "original research" doesn't go into Wikipedia. But "majo= r mainstream outlet" is not required. For example, the Electrologica X1 arti= cle cites sources for its content, most of which are rather obscure publicati= ons such as tech reports in the CWI archives. The point is that it has to be= published elsewhere. On the other hand, site policy has a long list of what publishers they'll accept and not accept. Amateur and hobbyist postings to blogs, for example, a= re not accepted, even if it's verifiable or reproducible or otherwise high quali= ty. I admit to a bit of pique here: I don't even bother updating Wikipedia articl= es anymore because they'll always get reverted by someone with less of a life th= an me for any number of specious reasons. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- Understanding is a three-edged sword. -- Babylon 5, "Deathwalker" --------= -- --===============7649820546473491636==-- From paulkoning@comcast.net Sun Feb 16 18:49:31 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 13:49:10 -0500 Message-ID: <136DF916-47AA-426D-A1C3-0019A6936550@comcast.net> In-Reply-To: <45d32e27-3e88-49d1-b459-f9b638520362@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6469853787941351529==" --===============6469853787941351529== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 1:45=E2=80=AFPM, Cameron Kaiser via cctalk wrote: >=20 >=20 >> You're right that "original research" doesn't go into Wikipedia. But "maj= or mainstream outlet" is not required. For example, the Electrologica X1 art= icle cites sources for its content, most of which are rather obscure publicat= ions such as tech reports in the CWI archives. The point is that it has to b= e published elsewhere. >=20 > On the other hand, site policy has a long list of what publishers they'll > accept and not accept. Amateur and hobbyist postings to blogs, for example,= are > not accepted, even if it's verifiable or reproducible or otherwise high qua= lity. I haven't explored that, but in the example I gave I was thinking about a pub= lication in a national magazine. And a lot of content is covered by citation= s from rather obscure sources -- for example, I added a whole lot of material= to the Linotype article based on citations of (and illustrations copied from= ) a book published by the manufacturer. > I admit to a bit of pique here: I don't even bother updating Wikipedia arti= cles > anymore because they'll always get reverted by someone with less of a life = than > me for any number of specious reasons. Yes, hence my gripe about my FM contribution, rejected because "it's not wide= band FM". Nor was Armstrong's original patent. I think the real objection = was "it's not American". :-( paul --===============6469853787941351529==-- From tdk.knight@gmail.com Sun Feb 16 18:55:39 2025 From: Adrian Stoness To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 12:55:21 -0600 Message-ID: In-Reply-To: <45d32e27-3e88-49d1-b459-f9b638520362@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7368802710630875968==" --===============7368802710630875968== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit do you start discussions around u redits on the articles complaining about the removal ofthe info On Sun, Feb 16, 2025 at 12:45 PM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org> wrote: > > > You're right that "original research" doesn't go into Wikipedia. But > "major mainstream outlet" is not required. For example, the Electrologica > X1 article cites sources for its content, most of which are rather obscure > publications such as tech reports in the CWI archives. The point is that > it has to be published elsewhere. > > On the other hand, site policy has a long list of what publishers they'll > accept and not accept. Amateur and hobbyist postings to blogs, for > example, are > not accepted, even if it's verifiable or reproducible or otherwise high > quality. > > I admit to a bit of pique here: I don't even bother updating Wikipedia > articles > anymore because they'll always get reverted by someone with less of a life > than > me for any number of specious reasons. > > -- > ------------------------------------ personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckaiser(a)floodgap.com > -- Understanding is a three-edged sword. -- Babylon 5, "Deathwalker" > ---------- > > --===============7368802710630875968==-- From van.snyder@sbcglobal.net Sun Feb 16 19:44:22 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 11:44:05 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8514779414255026009==" --===============8514779414255026009== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 09:56 -0500, Paul Koning via cctalk wrote: > Well, "ALGOL 58" is not a thing.  The document describing the 1958 > language called it "International Algebraic Language".  I only > glanced at it -- the first time I saw an actual description is when I > read the 1958 report in an appendix of Gauthier's thesis -- but my > memory is that it can't be thought of as a subset of Algol 60 but > rather a dead end relative that went off in a wrong direction that > the 1960 report abandoned. Jules Schwartz chaired a committee at SDC that extended IAL. It came to be called Jules Own Version of the International Algorithmic Language, or JOVIAL. It was standardized in 1973 as MIL-STD-1589, and revised in 1984. It's still in use in embedded applications, mostly military vehicles and aircraft. --===============8514779414255026009==-- From mhs.stein@gmail.com Sun Feb 16 19:48:34 2025 From: Mike Stein To: cctalk@classiccmp.org Subject: [cctalk] Re: RS232 then and now Date: Sun, 16 Feb 2025 14:48:17 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5989984201438233788==" --===============5989984201438233788== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable And several RS computers and peripherals used 4-pin DIN connectors for RS-232 serial... On Mon, Feb 3, 2025 at 1:56=E2=80=AFAM Fred Cisin via cctalk wrote: > On Sun, 2 Feb 2025, Steve Lewis via cctalk wrote: > > Didn't the original TRS-80 have a kind of screw up, where the tape and > > display connector were the same? > > Actually, years later the Atari Lynx had a similar mishap - the power > > charger and headphone jack port look identical? (something like that, > and > > would cause damage if used incorrectly) > > Steve > > On the back (starboard side), there are THREE 5 pin DIN connectors. Power > (external cord-wart), video (composite), and cassette. > > yes there were incidents regarding those. > > The original IBM 5150 (PC) had two 5 pin DIN connectors on the back. For > keybpoard, and cassette IBM didn't sell a cable, but the Radio Shack > cassette cable for TRS80 worked fine.. > > > --===============5989984201438233788==-- From van.snyder@sbcglobal.net Sun Feb 16 19:54:44 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 11:54:35 -0800 Message-ID: <77ffdaafcc7b789845c8648f71c2f4d5cd9af2bc.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2207084443672254596==" --===============2207084443672254596== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 2025-02-16 at 09:32 -0500, Paul Koning via cctalk wrote: > A lot of early "ALGOL" compilers did major subsetting because it was > considered to hard to do the real language. IBM invented PL/1. IBM (or at least IBM Canada) wrote their excellent Fortran compilers in a subset of PL/1 called PLIX, that is PL.9. I guess a full language was too hard even for the inventors of the language. At committee meetings I would pester the IBM delegate "When are you going to make your compiler available for Linux on Intel?" His answer was always NEVER! --===============2207084443672254596==-- From erik@baigar.de Sun Feb 16 20:23:49 2025 From: "Dr. Erik Baigar" To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:17:36 +0100 Message-ID: <2ccd418c-e0a8-974e-bbf9-8ae2a839f237@baigar.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6446848164789972716==" --===============6446848164789972716== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Van, just wanted to point out, that there is a 803 emulator out there: https://www.peteronion.org.uk/Elliott/ I have got a real 900 series machine running, which is from the very early 1970ies and also runs a form of Elliott Algol: https://www.youtube.com/watch?v=v-gF5g0nnoE Best wishes, Erik. ---------------------------------------------------------------------- ''~`` ( o o ) +--------------------------.oooO--(_)--Oooo.-------------------------+ | Dr. Erik Baigar Inertial Navigation & | | Salzstrasse 1 .oooO Vintage Computer | | D87616 Marktoberdorf ( ) Oooo. Hobbyist / Physicist | | erik(a)baigar.de +------\ (----( )---------------------------+ | www.baigar.de | \_) ) / +----------------------+ (_/ --===============6446848164789972716==-- From van.snyder@sbcglobal.net Sun Feb 16 20:24:14 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 12:24:04 -0800 Message-ID: <3cbb4a34491afbded2e584d486cc5b2b328727af.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4181178941409108054==" --===============4181178941409108054== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 16:59 +0000, Chuck Guzis via cctalk wrote: > CALGO ever since the beginning has also allowed algorithms in > FORTRAN, > it being the only language a lot of number-heavy shops use (e.g. > JPL). The JPL suite of navigation software — orbit and trajectory determination, trajectory planning, … — started out in FAP and IBMAP on IBM 709 and 7090 and 7094 computers. It was converted to Fortran by about 1966. It eventually grew to more than sixty programs, encompassing about six million lines. In the mid 1990's a middle manager got a wasp up his ass and decreed it all had to be re-written in C++. I urged them to study Les Hatton's measurements that the average C++ program cost six times more during its entire life cycle than an equivalent program written in Fortran, C, or Ada. They did it anyway. They asked for 120 work years of funding. Fifteen years later they said "we're about 90% finished. We have a few loose ends. We only need another 120 work years of funding." It was used side-by-side with the legacy code for the Phoenix Mars lander. One of the navigators whispered to me "It doesn't work!" Instead of the original ODP (Orbit Determination Program) name, it's now called MONTE (Mission analysis, Operations, and Navigation Toolkit Environment). It works now. There's a python program that's helpful for preparing its input. Of course, that program is called MONTE Python. The Fortran-based ODP was maintained by a staff of 6.5 full-time equivalent. The MONTE staff is more than thirty. The Fortran standard has remained under development. FORTRAN 66 was the first language standardized by ANSI. Since then, standards were published in 1977, 1990, 2003, 2008, 2018, and 2023. A revision is under development. Intel provides free compilers for Windoze and Linux. The GNU compiler — gfortran — is available for many programs, but has an "interesting" definition of standard conformance. Sun offered a free compiler, but that got the axe when Oracle bought Sun. NVidia offers a compiler that includes CUDA extensions. And of course Cray (now part of HP/E) has one. --===============4181178941409108054==-- From van.snyder@sbcglobal.net Sun Feb 16 20:30:51 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 12:30:39 -0800 Message-ID: <633a93ed26e29806b4995f7f24dd6e89b11b6190.camel@sbcglobal.net> In-Reply-To: <8D1E249F-2294-4A25-884A-08F47C12CFAE@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2853869684148005364==" --===============2853869684148005364== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 2025-02-16 at 13:08 -0500, Paul Koning via cctalk wrote: > Parsing -- splitting text into tokens (lexing) and building parse > trees -- is part of the compiler's job but usually the easiest part.=C2=A0 > Not quite as easy if you want good error messages or error recovery. I put an LR parser generator that includes Tom Pennello's Forward Move Algorithm for error recovery at=C2=A0https://sourceforge.net/projects/lr-and-lex-gen-fortran/files//?uploa= d_just_completed=3Dtruehttps://sourceforge.net/projects/lr-and-lex-gen-fortra= n/files// It uses Dave Pager's algorithm to generate LALR where possible, and LR where necessary, that is, when states with identical core cannot be merged because of lookahead conflicts. I stopped working on it when I retired. The full exploitation of the extra information in the LR table isn't implemented in the simple parser inside of the parser generator. --===============2853869684148005364==-- From spectre@floodgap.com Sun Feb 16 20:33:46 2025 From: Cameron Kaiser To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 12:33:39 -0800 Message-ID: <41321489-9f9b-4e22-8769-15ab8b3693b3@floodgap.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1762502307280850776==" --===============1762502307280850776== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > do you start discussions around u redits on the articles complaining about > the removal ofthe info I used to. Then I realized they enjoy that. --=20 ------------------------------------ personal: http://www.cameronkaiser.com/ = -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.c= om -- The truth is out there. The speculation, however, is really out there. ---= -- --===============1762502307280850776==-- From paul.kimpel@digm.com Sun Feb 16 20:40:08 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 20:40:05 +0000 Message-ID: <173973840508.1304.4568218659100627667@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3026450901188620797==" --===============3026450901188620797== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Yes, the B1700/1800/1900 systems had bit-addressable memory, but I think the = data registers were limited to 24 bits. --===============3026450901188620797==-- From van.snyder@sbcglobal.net Sun Feb 16 20:41:15 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 12:41:02 -0800 Message-ID: <2c2fb7b9874ec34ccfde6c72856e9307210ff673.camel@sbcglobal.net> In-Reply-To: <8D1E249F-2294-4A25-884A-08F47C12CFAE@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6880935470411769205==" --===============6880935470411769205== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 13:08 -0500, Paul Koning via cctalk wrote: > You might want to look at the GCC internals manual.  GCC has an > explicit layering, with front end processing steps that construct > parse trees which are then transformed in stages, until they reach > the "target" code which converts the final internal representation > into actual machine code. The IBM 1401 FORTRAN II compiler consisted of 63 phases. It read the program into core, then loaded phases that massaged what it had in core until it eventually had machine code. It ran from a deck of about 2,500 cards, or from one tape. I have source code for it, and for a version I revised for the Computer History Museum. I reverse engineered operational tapes for two versions. Then the original author, Gary Mokotoff, found listings he thought he had lost when he retired. I transcribed his listings and assembled them. My code has more comments. --===============6880935470411769205==-- From wayne.sudol@hotmail.com Sun Feb 16 20:44:39 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 20:44:31 +0000 Message-ID: In-Reply-To: <2c2fb7b9874ec34ccfde6c72856e9307210ff673.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5912481810841203552==" --===============5912481810841203552== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Is it posted anywhere? Sent from my iPhone > On Feb 16, 2025, at 12:41, Van Snyder via cctalk = wrote: >=20 > =EF=BB=BFOn Sun, 2025-02-16 at 13:08 -0500, Paul Koning via cctalk wrote: >> You might want to look at the GCC internals manual. GCC has an >> explicit layering, with front end processing steps that construct >> parse trees which are then transformed in stages, until they reach >> the "target" code which converts the final internal representation >> into actual machine code. >=20 > The IBM 1401 FORTRAN II compiler consisted of 63 phases. It read the > program into core, then loaded phases that massaged what it had in core > until it eventually had machine code. It ran from a deck of about 2,500 > cards, or from one tape. I have source code for it, and for a version I > revised for the Computer History Museum. I reverse engineered > operational tapes for two versions. Then the original author, Gary > Mokotoff, found listings he thought he had lost when he retired. I > transcribed his listings and assembled them. My code has more comments. >=20 >=20 >=20 >=20 --===============5912481810841203552==-- From paul.kimpel@digm.com Sun Feb 16 20:52:01 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 20:51:57 +0000 Message-ID: <173973911799.1304.9522080095578946365@classiccmp.org> In-Reply-To: <5d11105f-9e76-480c-abf0-5ae53cd15510@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2153924684717519748==" --===============2153924684717519748== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I don't understand -- ASCII had only two versions, 1963 and 1967, and both ha= d square brackets. The IBM PC used ASCII, but had nothing to do with its stan= dardization. --===============2153924684717519748==-- From seefriek@gmail.com Sun Feb 16 20:55:59 2025 From: Ken Seefried To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 15:55:41 -0500 Message-ID: In-Reply-To: <45d32e27-3e88-49d1-b459-f9b638520362@floodgap.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5286600035997434853==" --===============5286600035997434853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Feb 16, 2025 at 1:53 PM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org> wrote: > > I admit to a bit of pique here: I don't even bother updating Wikipedia > articles > anymore because they'll always get reverted by someone with less of a life > than > me for any number of specious reasons. > > This is an almost perfect description of my experience of Wikipedia. --===============5286600035997434853==-- From paul.kimpel@digm.com Sun Feb 16 21:06:54 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:06:49 +0000 Message-ID: <173974000990.1304.8284966560402326510@classiccmp.org> In-Reply-To: <3BDAF0A9-0E72-4553-9D70-35FD250848A7@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0446269475893785132==" --===============0446269475893785132== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The thing you really need for good ALGOL code generation is a target architec= ture designed to support it. All of the early implementations I know about th= at attempted full support of ALGOL-60 targeted a virtual machine at run time.= The outstanding counter-example, of course, are the Burroughs B5000/6000/700= 0 stack machines, later known as Unisys A Series, and currently still being m= arketed and supported by Unisys as their ClearPath MCP line. The B5000 was designed in the early '60s, with first customer delivery on 1 A= pril 1963. The ALGOL code generation was good enough (from a one-pass compile= r, no less) that it became the assembly language. There never was an assemble= r that ran on those systems, although there was a basic assembler (termed OSI= L) for it that ran on the older Burroughs 220 and was used to bootstrap early= versions of the ALGOL compiler and OS. Once ALGOL could compile itself, OSIL= was abandoned. The Burroughs ALGOL dialect is heavily extended, but at its core it was still= a quite complete implementation of Revised ALGOL-60. --===============0446269475893785132==-- From dave.g4ugm@gmail.com Sun Feb 16 21:21:39 2025 From: David Wade To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:21:31 +0000 Message-ID: <35557b1c-63c4-4a89-a6c9-1565a8608581@gmail.com> In-Reply-To: <173973911799.1304.9522080095578946365@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2636875321286579093==" --===============2636875321286579093== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 16/02/2025 20:51, paul.kimpel--- via cctalk wrote: > I don't understand -- ASCII had only two versions, 1963 and 1967, and both = had square brackets. The IBM PC used ASCII, but had nothing to do with its st= andardization. I can't find the context for this, but it was early EBCDIC devices which=20 lacked square brackets, and there was a big debate in the academic world=20 where to put them in the code page... https://x3270.miraheze.org/wiki/Why_are_the_square_bracket_characters_display= ed_wrong%3F ... and here is a 3270 keyboard.... https://sharktastica.co.uk/directory?id=3D94OROEAU Dave --===============2636875321286579093==-- From paul.kimpel@digm.com Sun Feb 16 21:34:24 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:34:18 +0000 Message-ID: <173974165892.1304.12069345351460437928@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2653241627013954948==" --===============2653241627013954948== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It's true that what we now call ALGOL 58 was never a specification, let along= a standard. But it wasn't a dead end, either. The title of the report that d= escribed it was "Preliminary Report--International Algebraic Language" (Commu= nications of the ACM, Volume 1, Number 12 (December 1958), pages 8-22). It wa= s a progress report on the effort to design a new language. The ACM-GAMM comm= ittee kept refining their ideas and eventually came up with ALGOL 60. The problem was that the ideas proposed by the committee's progress report we= re so interesting that the report quickly spawned numerous implementations, e= ach with their own dialect and limitations, including JOVIAL, NELIAC, ALGO fo= r the Bendix G-15, and two versions from Burroughs known as BALGOL, one for t= he 220 and one for the Datatron 205. --===============2653241627013954948==-- From paul.kimpel@digm.com Sun Feb 16 21:42:28 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:42:23 +0000 Message-ID: <173974214383.1304.3285259843784927083@classiccmp.org> In-Reply-To: <47d8bb02-f259-42c0-851e-d83a9ab7bc3f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9043317963278697957==" --===============9043317963278697957== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Donald Knuth wrote an ALGOL compiler for the ElectroData/Burroughs Datatron 2= 05, a drum-memory machine with 4080 words of memory, in 1960. It was based on= ALGOL 58, though. --===============9043317963278697957==-- From paul.kimpel@digm.com Sun Feb 16 21:46:34 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:46:30 +0000 Message-ID: <173974239044.1304.9339404793271215399@classiccmp.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7209088850842899590==" --===============7209088850842899590== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Except for all of those people in the U.S. and elsewhere who were actively us= ing ALGOL for serious work on their Burroughs/Unisys stack-oriented machines,= and are still doing so today. It's not yet a dead language. --===============7209088850842899590==-- From cclist@sydex.com Sun Feb 16 21:52:00 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:51:51 +0000 Message-ID: In-Reply-To: <77ffdaafcc7b789845c8648f71c2f4d5cd9af2bc.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8633335188194102261==" --===============8633335188194102261== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/16/25 11:54, Van Snyder via cctalk wrote: > On Sun, 2025-02-16 at 09:32 -0500, Paul Koning via cctalk wrote: >> A lot of early "ALGOL" compilers did major subsetting because it was >> considered to hard to do the real language. > > IBM invented PL/1. IBM (or at least IBM Canada) wrote their excellent > Fortran compilers in a subset of PL/1 called PLIX, that is PL.9. I > guess a full language was too hard even for the inventors of the > language. At committee meetings I would pester the IBM delegate "When > are you going to make your compiler available for Linux on Intel?" His > answer was always NEVER! A co-worker from long ago who was part of the IBM COMTRAN project once told me that the IBM PL/I group was the biggest bunch of misfits that had ever been assembled. I won't go any further on that, because I'd be engaging in gossip. --Chuck --===============8633335188194102261==-- From paulkoning@comcast.net Sun Feb 16 21:54:00 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 16:53:38 -0500 Message-ID: In-Reply-To: <77ffdaafcc7b789845c8648f71c2f4d5cd9af2bc.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6573202370727142526==" --===============6573202370727142526== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 2:54=E2=80=AFPM, Van Snyder via cctalk wrote: >=20 > On Sun, 2025-02-16 at 09:32 -0500, Paul Koning via cctalk wrote: >> A lot of early "ALGOL" compilers did major subsetting because it was >> considered to hard to do the real language. >=20 > IBM invented PL/1. IBM (or at least IBM Canada) wrote their excellent > Fortran compilers in a subset of PL/1 called PLIX, that is PL.9.=20 I remember PL/C, a compiler for student use created at Cornell U. My compile= r class was at first required to build on that, because the prof had been the= lead implementer of PL/C. We finally got excused from that requirement beca= use we had to use lots of macros, and the macro processing in that compiler o= ften caused the compiler to crash. The problem is the macro expander (foolis= hly) tried to honor the "source margins" property of the original input text. So we switched to Pascal on the PDP-10, which was vastly superior in every wa= y, and I haven't been tempted to touch PL/I since. paul --===============6573202370727142526==-- From cclist@sydex.com Sun Feb 16 21:54:07 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:53:57 +0000 Message-ID: In-Reply-To: <173973840508.1304.4568218659100627667@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5408446725961994903==" --===============5408446725961994903== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/16/25 12:40, paul.kimpel--- via cctalk wrote: > Yes, the B1700/1800/1900 systems had bit-addressable memory, but I think th= e data registers were limited to 24 bits. As did the CDC STAR/CYBER 200 systems, as well as the ETA machines. Pretty much a requirement if one has bitmapped control/sparse vectors on a vector processor. --Chuck --===============5408446725961994903==-- From paulkoning@comcast.net Sun Feb 16 21:56:18 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 16:56:00 -0500 Message-ID: <516F3803-15BC-4E95-B425-30503A5F2560@comcast.net> In-Reply-To: <173974000990.1304.8284966560402326510@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8881385407995841039==" --===============8881385407995841039== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 4:06=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >=20 > The thing you really need for good ALGOL code generation is a target archit= ecture designed to support it. All of the early implementations I know about = that attempted full support of ALGOL-60 targeted a virtual machine at run tim= e.=20 That's a bit of an exaggeration. True, the first compiler (for the EL-X1) us= ed a mix of machine code and subroutines that looked a lot like a virtual mac= hine. But the EL-X8 compilers all generated straight machine code. Now you = could argue that the X8 was a machine with an ISP designed for Algol. Then a= gain, the CDC 6000 surely isn't, and I would be surprised if the CDC Algol co= mpilers weren't machine code generators. paul --===============8881385407995841039==-- From cclist@sydex.com Sun Feb 16 21:56:28 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:56:14 +0000 Message-ID: <5708adb2-48b5-4db5-af44-eed85f4ad804@sydex.com> In-Reply-To: <2c2fb7b9874ec34ccfde6c72856e9307210ff673.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5246952885176190805==" --===============5246952885176190805== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/16/25 12:41, Van Snyder via cctalk wrote: > The IBM 1401 FORTRAN II compiler consisted of 63 phases. It read the > program into core, then loaded phases that massaged what it had in core > until it eventually had machine code. It ran from a deck of about 2,500 > cards, or from one tape. I have source code for it, and for a version I > revised for the Computer History Museum. I reverse engineered > operational tapes for two versions. Then the original author, Gary > Mokotoff, found listings he thought he had lost when he retired. I > transcribed his listings and assembled them. My code has more comments. It also had better diagnostics than say, the S/360 USA Basic FORTRAN compiler. --Chuck --===============5246952885176190805==-- From paul.kimpel@digm.com Sun Feb 16 22:30:26 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 22:30:22 +0000 Message-ID: <173974502243.1304.17815195267266705611@classiccmp.org> In-Reply-To: <516F3803-15BC-4E95-B425-30503A5F2560@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0633859470924099312==" --===============0633859470924099312== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The question concerned good ALGOL code generation, not the feasibility of ALG= OL code generation. --===============0633859470924099312==-- From seefriek@gmail.com Sun Feb 16 23:18:00 2025 From: Ken Seefried To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 18:17:40 -0500 Message-ID: In-Reply-To: <516F3803-15BC-4E95-B425-30503A5F2560@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2970386529113803384==" --===============2970386529113803384== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, Feb 16, 2025 at 4:56 PM Paul Koning via cctalk < cctalk(a)classiccmp.org> wrote: > > Then again, the CDC 6000 surely isn't, and I would be surprised if the CDC > Algol compilers weren't machine code generators. > > > The 6000 was a bit before my time, but as I recall the CDC Algol-60 compiler on the 170/180 machines was. KJ --===============2970386529113803384==-- From bfranchuk@jetnet.ab.ca Sun Feb 16 23:28:23 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 16:28:12 -0700 Message-ID: In-Reply-To: <173973911799.1304.9522080095578946365@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5088513604793248782==" --===============5088513604793248782== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-16 1:51 p.m., paul.kimpel--- via cctalk wrote: > I don't understand -- ASCII had only two versions, 1963 and 1967, and both = had square brackets. The IBM PC used ASCII, but had nothing to do with its st= andardization. https://archive.org/details/enf-ascii-1965-1966/page/n47/mode/2up --===============5088513604793248782==-- From paulkoning@comcast.net Sun Feb 16 23:52:48 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 18:52:25 -0500 Message-ID: <27E23383-0159-455F-B17E-6302269E734E@comcast.net> In-Reply-To: <173974502243.1304.17815195267266705611@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6921001749150023576==" --===============6921001749150023576== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 5:30=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >=20 > The question concerned good ALGOL code generation, not the feasibility of A= LGOL code generation. I know that, but just as RISC machines can run very fast no matter what appli= cations you feed them, compilers created with skill can produce excellent cod= e no matter the target machine. ALGOL running on a machine designed for the language is likely to be shorter,= but not necessarily faster. For example, the EL-X8 has an addressing mode = for resolving references through the "display" of static scopes in what looks= like a single operation. But just as "single" CISC instrutions under the co= ver require a lot of work, so does that addressing mode. The same thing, exp= anded out to its atomic elements in a RISC instruction set, certainly require= s a half dozen instructions but they will probably run just as fast. paul --===============6921001749150023576==-- From van.snyder@sbcglobal.net Mon Feb 17 00:39:06 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 16:38:55 -0800 Message-ID: <4b60ac1cd8ba63fa2001ad27526601455803ec0f.camel@sbcglobal.net> In-Reply-To: <173974165892.1304.12069345351460437928@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0220580870376616117==" --===============0220580870376616117== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 21:34 +0000, paul.kimpel--- via cctalk wrote: > one for the 220 and one for the Datatron 205. When I was an undergraduate there was a B220 in the computer room, beside the IBM 7094.7044 direct couple. It was used to read paper tapes from the synchrotron into the 7044. It had a magnetic tape drive with permalloy ­— not mylar — tape. If it got a permanent read error, the program could issue a command to punch a hole in the record. It also had a thermal printer called "teledotis." It was very fast, so some called it the Whippet. It electrostatically deposited soot onto special paper, which was then fused by a heat roller. If it was too cold, the soot fell off. If it was too hot you got a big smudge. The temperature was adjusted by a giant Variac under the table. On most days, the ideal setting was between two windings. --===============0220580870376616117==-- From van.snyder@sbcglobal.net Mon Feb 17 00:41:21 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 16:41:11 -0800 Message-ID: <1a5a9943247e75334ca6d39091a39820ef663fc3.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4294912399817367559==" --===============4294912399817367559== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 21:51 +0000, Chuck Guzis via cctalk wrote: > On 2/16/25 11:54, Van Snyder via cctalk wrote: > > On Sun, 2025-02-16 at 09:32 -0500, Paul Koning via cctalk wrote: > > > A lot of early "ALGOL" compilers did major subsetting because it > > > was > > > considered to hard to do the real language. > > > > IBM invented PL/1. IBM (or at least IBM Canada) wrote their > > excellent > > Fortran compilers in a subset of PL/1 called PLIX, that is PL.9. I > > guess a full language was too hard even for the inventors of the > > language. At committee meetings I would pester the IBM delegate > > "When > > are you going to make your compiler available for Linux on Intel?" > > His > > answer was always NEVER! > > A co-worker from long ago who was part of the IBM COMTRAN project > once > told me that the IBM PL/I group was the biggest bunch of misfits that > had ever been assembled.  I won't go any further on that, because I'd > be > engaging in gossip. I guess Honeywell got enough PL/1 working to write most of Multics in it. Has anybody gotten Multics going on a PC? --===============4294912399817367559==-- From bfranchuk@jetnet.ab.ca Mon Feb 17 01:00:45 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 18:00:35 -0700 Message-ID: In-Reply-To: <27E23383-0159-455F-B17E-6302269E734E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1987693231298962137==" --===============1987693231298962137== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-16 4:52 p.m., Paul Koning via cctalk wrote: >=20 >=20 >> On Feb 16, 2025, at 5:30=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >> >> The question concerned good ALGOL code generation, not the feasibility of = ALGOL code generation. >=20 > I know that, but just as RISC machines can run very fast no matter what app= lications you feed them, compilers created with skill can produce excellent c= ode no matter the target machine. >=20 > ALGOL running on a machine designed for the language is likely to be shorte= r, but not necessarily faster. For example, the EL-X8 has an addressing mod= e for resolving references through the "display" of static scopes in what loo= ks like a single operation. But just as "single" CISC instrutions under the = cover require a lot of work, so does that addressing mode. The same thing, e= xpanded out to its atomic elements in a RISC instruction set, certainly requi= res a half dozen instructions but they will probably run just as fast. >=20 > paul With all the cache's used on modern machines, accessing memory is a=20 Forbidden operation. I have trouble understanding the fine points of accessing a local=20 variable in Algol with a display. Books tend to spend more time on the evils of a dangling else, and gloss over the run time action of a display. Have a good example or reference book I can find free on line. Also is there a ENGLISH description of the EL-X8? Ben. --===============1987693231298962137==-- From van.snyder@sbcglobal.net Mon Feb 17 01:03:47 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 17:03:39 -0800 Message-ID: <4b0fff079eeecf2d824d90445d811472c59e1277.camel@sbcglobal.net> In-Reply-To: <27E23383-0159-455F-B17E-6302269E734E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9032656894622806741==" --===============9032656894622806741== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-16 at 18:52 -0500, Paul Koning via cctalk wrote: > For example, the EL-X8 has an addressing  mode for resolving > references through the "display" of static scopes in what looks like > a single operation. When Tom Pennello was a grad student studying under Frank de Remer at ACSC, he collected a big pile of codes in languages that had nested lexical and dynamic scopes (such as recursive internal functions). He found that chasing up-links was much faster than displays. In some cases, creating and destroying the display took six times longer than executing the function. I mentioned this to Malcolm Cohen and me mumbled something about a "trampoline." I have no idea what that is. --===============9032656894622806741==-- From cclist@sydex.com Mon Feb 17 03:47:12 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 03:39:50 +0000 Message-ID: <436f74d2-3989-417e-b429-81658ad59457@sydex.com> In-Reply-To: <27E23383-0159-455F-B17E-6302269E734E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5185561123875882413==" --===============5185561123875882413== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/16/25 15:52, Paul Koning via cctalk wrote: >=20 >=20 >> On Feb 16, 2025, at 5:30=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >> >> The question concerned good ALGOL code generation, not the feasibility of = ALGOL code generation. >=20 > I know that, but just as RISC machines can run very fast no matter what app= lications you feed them, compilers created with skill can produce excellent c= ode no matter the target machine. CDC 6000-series turned in better performance benchmarks on COBOL that did the high-end IBM S/370 iron. There are huge advantages to fast instruction set execution operating on large word sizes. Just ask Don Nelson (he who played the bass drum in the Los Trancos Woods marching band). Two things that worked to CDC's advantage in addition to the simple instruction set was that the 6000 was a three-address architecture with no condition code register (conditional branches were made on the content of a register). --Chuck --===============5185561123875882413==-- From bfranchuk@jetnet.ab.ca Mon Feb 17 05:12:40 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Classic computers with more than one stack pointer, but not FORTH machines. Date: Sun, 16 Feb 2025 22:12:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4511057398823168686==" --===============4511057398823168686== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Did any classic computers have a subroutine call as (S++)=PC, PC=(EFA) as well as the standard call (--S)=PC,PC=(EFA) ? One could have a virtual stack machine, using helper functions without having to deal with return addresses on the stack. Ben. --===============4511057398823168686==-- From van.snyder@sbcglobal.net Mon Feb 17 05:19:28 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 21:19:16 -0800 Message-ID: <020bb9ee35b711513c76295c3f739a1ce100b8ae.camel@sbcglobal.net> In-Reply-To: <436f74d2-3989-417e-b429-81658ad59457@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3056042005605001015==" --===============3056042005605001015== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2025-02-17 at 03:39 +0000, Chuck Guzis via cctalk wrote: > CDC 6000-series turned in better performance benchmarks on COBOL tha > did the high-end IBM S/370 iron In the mid 1970s at JPL, we were using Uniac 1108 for scientific computing and IBM 370 for administrative computing. My group go a task to develop some benchmarks to choose the next big computers. We wrote COBOL and FORTRAN benchmarks. Univac was faster on the COBOL benchmarks, and IBM was faster on the FORTRAN benchmarks. But we stuck with Univac for scientific computing and IBM for administrative computing. What ultimately carried the day was software compatibility. The administrative COBOL software used proprietary IBM extensions. Univac double precision is 18 digits, while 370 double precision is 14 digits. --===============3056042005605001015==-- From van.snyder@sbcglobal.net Mon Feb 17 06:29:42 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Sun, 16 Feb 2025 13:13:38 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CCO1PR08MB720844ABE61B58D98FA15CB6E4F82=40CO1PR08MB?= =?utf-8?q?7208=2Enamprd08=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2657444918353101458==" --===============2657444918353101458== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, 2025-02-16 at 20:44 +0000, Wayne S wrote: > Is it posted anywhere? It's at=C2=A0http://vandyke.mynetgear.com/1401/progs/Fortran/=C2=A0but not re= ally organized well. The ones I reverse engineered are in directories named v3m0 and v3m4. Gary's code is in Mokotoff. The version I revised for CHM is in v4. There's a paper from IBM System Journal that describes it, at=C2=A0http://vandyke.mynetgear.com/1401/docs/FortranII_1401_SerialCompiler_= IBMJR&D_Haines_1965.pdf > >=20 > > The IBM 1401 FORTRAN II compiler consisted of 63 phases. It read > > the > > program into core, then loaded phases that massaged what it had in > > core > > until it eventually had machine code. It ran from a deck of about > > 2,500 > > cards, or from one tape. I have source code for it, and for a > > version I > > revised for the Computer History Museum. I reverse engineered > > operational tapes for two versions. Then the original author, Gary > > Mokotoff, found listings he thought he had lost when he retired. I > > transcribed his listings and assembled them. My code has more > > comments. --===============2657444918353101458==-- From cc@informatik.uni-stuttgart.de Mon Feb 17 07:49:33 2025 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Open source a panacea? Date: Mon, 17 Feb 2025 08:33:56 +0100 Message-ID: <28ecbd42-3c6-34aa-1765-172266d1c21d@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7810689052949045718==" --===============7810689052949045718== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 14 Feb 2025, Liam Proven wrote: > On Tue, 4 Feb 2025 at 00:55, ben via cctalk wrote: >> PS. is me or just the internet browsing getting so full of ads >> and questionable redirects that on can't use it any more. > FWIW, I find the combination of Firefox and the uBlock Origin > extension stops me seeing most of them. I also have Privoxy installed > and configured, but I think nobody tests it any more in Ubuntu. It > doesn't seem to work in 22.04 or 24.04. To complete the setup, I always install those three extensions: µBlock Origin, NoScript and Cookie Autodelete. Christian --===============7810689052949045718==-- From cc@informatik.uni-stuttgart.de Mon Feb 17 07:59:16 2025 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 08:59:06 +0100 Message-ID: In-Reply-To: <47d8bb02-f259-42c0-851e-d83a9ab7bc3f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2169087399455288594==" --===============2169087399455288594== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 15 Feb 2025, Frank Leonhardt wrote: >> The Bendix G15 (introduced in 1956) had ALGO, their variant of Algol.=C2= =A0 Not=20 >> sure when this was available, but likely after 1958 or so.=C2=A0 I think i= t was=20 >> the only high level language available on that computer. >>=20 > Running anything like Algol on a machine with drum memory seems a bit=20 > optimistic! There was an ALGOL compiler for the Z22 released in 1958. As you all know,=20 the Z22 was a tube-based magnetic drum computer from 1955. Christian --===============2169087399455288594==-- From cc@informatik.uni-stuttgart.de Mon Feb 17 08:07:19 2025 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 09:07:09 +0100 Message-ID: <433e66a5-2b60-9887-1f58-58d790b6ef57@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6239470577033293481==" --===============6239470577033293481== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sat, 15 Feb 2025, Jon Elson wrote: > Anyway, I got pretty frustrated, and eventually pulled the cover off the dr= um=20 > and discovered there were two tracks totally scored down to the brass, and = a=20 > couple more that were a bit scored.=C2=A0 The cover on the drum was just de= ep=20 > drawn aluminum with caterpillar grommets around the cable entries.=C2=A0 NO= WHERE=20 > NEAR a hermetic seal! Magnetic drums usually have a couple of spare tracks exactly for this=20 reason. You can move a head to a different unused track in case that one=20 track has gone bad. The LGP-30 for example has around 4-5 spare tracks=20 IIRC. And no, it isn't hermetically sealed, either ;-) Christian --===============6239470577033293481==-- From classiccmp@fjl.co.uk Mon Feb 17 12:45:20 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 12:45:23 +0000 Message-ID: <0d3768b9-95e2-4345-8fa3-05874a83a13d@fjl.co.uk> In-Reply-To: <35557b1c-63c4-4a89-a6c9-1565a8608581@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1580448812054432393==" --===============1580448812054432393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 16/02/2025 21:21, David Wade via cctalk wrote: > On 16/02/2025 20:51, paul.kimpel--- via cctalk wrote: >> I don't understand -- ASCII had only two versions, 1963 and 1967, and=20 >> both had square brackets. The IBM PC used ASCII, but had nothing to=20 >> do with its standardization. > I can't find the context for this, but it was early EBCDIC devices=20 > which lacked square brackets, and there was a big debate in the=20 > academic world where to put them in the code page... > > https://x3270.miraheze.org/wiki/Why_are_the_square_bracket_characters_displ= ayed_wrong%3F=20 > > > ... and here is a 3270 keyboard.... > > https://sharktastica.co.uk/directory?id=3D94OROEAU=20 I was assuming it was a reference particular machines that had limited=20 ASCII. Square brackets were missing from a lot of keyboards, but not the=20 IBM PC, which turned up with "everything" and function keys too. Before=20 then I felt I was lucky when I had lower case. And don't start on ASCII=20 hard copy terminals. --===============1580448812054432393==-- From paulkoning@comcast.net Mon Feb 17 13:23:55 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 08:23:34 -0500 Message-ID: <5D7293B7-4CC1-4DE1-B5A7-AD18B2908F14@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6319741875278872747==" --===============6319741875278872747== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 12:12=E2=80=AFAM, ben via cctalk wrote: >=20 > Did any classic computers have a subroutine call as (S++)=3DPC, PC=3D(EFA) > as well as the standard call (--S)=3DPC,PC=3D(EFA) ? > One could have a virtual stack machine, using helper functions without hav= ing to deal with return addresses on the stack. > Ben. I don't know of any with what you describe. But there are machines that have= more than one flavor of subroutine call. VAX is one: CALL instruction that = buils a stack frame, and BSB that doesn't. Both use the SP, decrementing, fo= r the return information. Then there is the Electrologica X8, which has a stack based subroutine call -= - with the stack growing upward. But it also retains the EL-X1 style call in= structions that store the return address in one of 16 fixed low core location= s. I haven't seen code that used this, but one could certainly do so. paul --===============6319741875278872747==-- From paulkoning@comcast.net Mon Feb 17 13:53:51 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 08:53:29 -0500 Message-ID: <5E33651A-03C7-44EA-86D7-077A46515CC1@comcast.net> In-Reply-To: <4b60ac1cd8ba63fa2001ad27526601455803ec0f.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4490858037772882736==" --===============4490858037772882736== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 7:38=E2=80=AFPM, Van Snyder via cctalk wrote: >=20 > .... It also > had a thermal printer called "teledotis." It was very fast, so some > called it the Whippet. It electrostatically deposited soot onto special > paper, which was then fused by a heat roller. I would call that an "electrostatic printer" -- xerographic printer work that= way, depositing plastic soot that is then melted onto the paper. At U of Il= linois I used a printer very much like what you describe, made by Varian. Th= at was a dot matrix line printer -- a row of pixels across the page at once -= - we used for printing music scores. 100 dpi or so if I remember right. paul --===============4490858037772882736==-- From classiccmp@fjl.co.uk Mon Feb 17 14:01:58 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 14:02:01 +0000 Message-ID: <08e0ce83-b24e-4b21-bc1c-2a79fb13624f@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4959201393172905604==" --===============4959201393172905604== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 17/02/2025 05:12, ben via cctalk wrote: > Did any classic computers have a subroutine call as (S++)=PC, PC=(EFA) > as well as the standard call (--S)=PC,PC=(EFA) ? > One  could have a virtual stack machine, using helper functions > without having to deal with return addresses on the stack. On the more than "one stack pointer" in the subject, it was a bit arbitrary on the PDP-11 (or VAX) as the pre/post indexed indirect addressing made every register a stack pointer. But this is where I get hazy between DEC and 68K, and I did a lot more 68K. I'm pretty sure you could do a move.l PC, An and you could certainly do an indirect jmp (An), so effectively you could have multiple call stacks if you wanted. --===============4959201393172905604==-- From strick@yak.net Mon Feb 17 14:07:48 2025 From: StricK To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 09:07:32 -0500 Message-ID: In-Reply-To: <08e0ce83-b24e-4b21-bc1c-2a79fb13624f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2460124987202367035==" --===============2460124987202367035== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Probably ruled out by the "no forth" rule, the 6809 had data register stacking instruction for either the S or the extra U stack pointer PSHS | PULS | PSHU | PULU X,Y,D,CC,... and I think you could use PULU PC,... for return, just like you commonly use PULS PC,... as a quicker way of the standard return sequence PULS ... RET Saving time stacking the data registers might make up the extra time for nonstandard call resolution sequences. -- strick --===============2460124987202367035==-- From paulkoning@comcast.net Mon Feb 17 14:11:39 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 09:11:17 -0500 Message-ID: <17C602E7-DAD9-4B9D-9C6F-71DC98F52545@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0906460571095324996==" --===============0906460571095324996== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 8:00=E2=80=AFPM, ben via cctalk wrote: >=20 > ... > I have trouble understanding the fine points of accessing a local variable = in Algol with a display. Books tend to spend more time > on the evils of a dangling else, and gloss over the run time action of > a display. Displays are a solution to the problem of finding variables in an ancestor fu= nction block. It doesn't appear in C since (standard) C doesn't have nested = functions. I'll use C notation here for simplicity, though. Suppose you have: int f1(int i) { int j; int f2(int x) { int y; y =3D j*2; ... f1(x+1); } f2(...); } f1(42); The local variables go into stack frames, one for each call of each function.= So when recursive calls are made as in this example, there are multiple sta= ck frames belonging to calls of f1 and of f2. Each f1 frame has a j in it. = So how does the code for f2 find "the right f1 frame" to resolve the referenc= e to j that I showed? The answer is to have a display, which is a vector of pointers, indexed by "s= tatic scope", in other words by textual nesting level. In this case that vec= tor would have three entries: one for the program, f1, and f2. When a call t= o f1 is made, the stack frame is created. In the stack frame the previous va= lue of the display entry for f1 is saved, and that entry is then set to the s= tack frame address. On function return, the previous display entry is restor= ed. To resolve the reference to j in f2, the code would load the display entry fo= r f1 (the second entry in the display vector), and add the offset to j in the= stack frame. On the X8 a reference to j through the display is a single instruction using = a specialized addressing mode that does the whole job. It assumes no more th= an 63 statically nested blocks, but that's quite a reasonable limitation. > Have a good example or reference book I can find free on line. > Also is there a ENGLISH description of the EL-X8? There's the article in Wikipedia. Apart from that, find the "EWD archive" at= UT Austin. Many of the early EWD papers, up to number 150 or so, deal with = the development of the THE operating system. Some are in English, some in Du= tch, for no obvious reason. A number of the Dutch ones have been translated = by volunteers working on that archive. I think there are some useful summari= es of the machine in there. One thing you should not miss is the paper "The structure of the THE operatin= g system". It describes the design principles and why they were used; it lay= s the foundation for techniques that were used by many others afterwards. paul --===============0906460571095324996==-- From paulkoning@comcast.net Mon Feb 17 14:13:40 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 09:13:19 -0500 Message-ID: In-Reply-To: <4b0fff079eeecf2d824d90445d811472c59e1277.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8674461597987644739==" --===============8674461597987644739== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 8:03=E2=80=AFPM, Van Snyder via cctalk wrote: >=20 > On Sun, 2025-02-16 at 18:52 -0500, Paul Koning via cctalk wrote: >> For example, the EL-X8 has an addressing mode for resolving >> references through the "display" of static scopes in what looks like >> a single operation. >=20 > When Tom Pennello was a grad student studying under Frank de Remer at > ACSC, he collected a big pile of codes in languages that had nested > lexical and dynamic scopes (such as recursive internal functions). He > found that chasing up-links was much faster than displays. In some > cases, creating and destroying the display took six times longer than > executing the function. I mentioned this to Malcolm Cohen and me > mumbled something about a "trampoline." I have no idea what that is. I'm puzzled by that, since the display is a static data structure and updatin= g it takes only a few instructions for each call and fewer for a return. "Trampolines" are how GCC handles nested functions, or at least that is the t= raditional mechanism. I never really understood them other than to realize t= hey involve executable code on the stack -- which means they only work in som= e machines and some operating systems. I think there is now a replacement me= chanism that avoids this issue but I don't remember the details. Why GCC did= n't adopt displays isn't clear to me. paul --===============8674461597987644739==-- From paulkoning@comcast.net Mon Feb 17 14:17:27 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 09:17:06 -0500 Message-ID: In-Reply-To: <436f74d2-3989-417e-b429-81658ad59457@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6172012067178047040==" --===============6172012067178047040== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 16, 2025, at 10:39=E2=80=AFPM, Chuck Guzis via cctalk wrote: >=20 > On 2/16/25 15:52, Paul Koning via cctalk wrote: >>=20 >>=20 >>> On Feb 16, 2025, at 5:30=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >>>=20 >>> The question concerned good ALGOL code generation, not the feasibility of= ALGOL code generation. >>=20 >> I know that, but just as RISC machines can run very fast no matter what ap= plications you feed them, compilers created with skill can produce excellent = code no matter the target machine. >=20 > CDC 6000-series turned in better performance benchmarks on COBOL that > did the high-end IBM S/370 iron. There are huge advantages to fast > instruction set execution operating on large word sizes. Just ask Don > Nelson (he who played the bass drum in the Los Trancos Woods marching band). >=20 > Two things that worked to CDC's advantage in addition to the simple > instruction set was that the 6000 was a three-address architecture with > no condition code register (conditional branches were made on the > content of a register). Also multiple functional units, seriously interleaved memory, and a bucket fu= ll of other tricks. The way loads and stores are requested by the programmer= naturally makes them background operations, and the "stunt box" handles that= background process. Not directly tied to application performance but very nice for the OS is an a= mazingly efficient way to switch between processes, the "exchange jump". VAX= almost got this, but the 6000 does it better, taking advantage of the read/= restore cycle to do a read/update and run the context switch at memory speed.= Ignoring initiation time it takes less than 3 microseconds (in 1964!!). paul --===============6172012067178047040==-- From paulkoning@comcast.net Mon Feb 17 14:19:29 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 09:19:07 -0500 Message-ID: <4954CE0E-297D-4552-B138-9687207F6BEA@comcast.net> In-Reply-To: <08e0ce83-b24e-4b21-bc1c-2a79fb13624f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8413667689117532857==" --===============8413667689117532857== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 9:02=E2=80=AFAM, Frank Leonhardt via cctalk wrote: >=20 > On 17/02/2025 05:12, ben via cctalk wrote: >> Did any classic computers have a subroutine call as (S++)=3DPC, PC=3D(EFA) >> as well as the standard call (--S)=3DPC,PC=3D(EFA) ? >> One could have a virtual stack machine, using helper functions without ha= ving to deal with return addresses on the stack. >=20 > On the more than "one stack pointer" in the subject, it was a bit arbitrary= on the PDP-11 (or VAX) as the pre/post indexed indirect addressing made ever= y register a stack pointer.=20 Indeed, but the subroutine call instructions were hardwired to auto-decrement= on a particular register, conventionally called SP (register 6 in the PDP-11= ). So while you could create data stacks that grow in either direction, with= a pointer of your choice, you could only do calls via SP and only downward. paul --===============8413667689117532857==-- From paulkoning@comcast.net Mon Feb 17 14:26:38 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 09:26:18 -0500 Message-ID: <33727A8E-0666-4E7E-8E8A-C26F4D68544E@comcast.net> In-Reply-To: <0d3768b9-95e2-4345-8fa3-05874a83a13d@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5811441643137021573==" --===============5811441643137021573== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 7:45=E2=80=AFAM, Frank Leonhardt via cctalk wrote: >=20 > On 16/02/2025 21:21, David Wade via cctalk wrote: >> On 16/02/2025 20:51, paul.kimpel--- via cctalk wrote: >>> I don't understand -- ASCII had only two versions, 1963 and 1967, and bot= h had square brackets. The IBM PC used ASCII, but had nothing to do with its = standardization. >> I can't find the context for this, but it was early EBCDIC devices which l= acked square brackets, and there was a big debate in the academic world where= to put them in the code page... >>=20 >> https://x3270.miraheze.org/wiki/Why_are_the_square_bracket_characters_disp= layed_wrong%3F=20 >>=20 >> ... and here is a 3270 keyboard.... >>=20 >> https://sharktastica.co.uk/directory?id=3D94OROEAU >=20 > I was assuming it was a reference particular machines that had limited ASCI= I. Square brackets were missing from a lot of keyboards, but not the IBM PC, = which turned up with "everything" and function keys too. Before then I felt I= was lucky when I had lower case. And don't start on ASCII hard copy terminal= s. I've never seen an ASCII terminal that was missing square brackets. But in t= heory those codes were "national use" codes, and for non-English language use= they would be redefined as A with umlaut or stuff like that. This is why RS= TS/E at some point introduced parentheses as alternates for the square bracke= ts it had always used as directory name delimiters. For us in the US that wa= s never interesting. The problem was fixed fairly well with the introduction of the DEC Multinatio= nal Character Set, which later morphed into ISO Latin-1 (with the curious om= ission of the oe ligature) and later the various other Latin- sets. And t= he problem was solved completely with Unicode. paul --===============5811441643137021573==-- From abuse@cabal.org.uk Mon Feb 17 15:36:25 2025 From: Peter Corlett To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 16:36:18 +0100 Message-ID: In-Reply-To: <17C602E7-DAD9-4B9D-9C6F-71DC98F52545@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2748588978687169378==" --===============2748588978687169378== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, Feb 17, 2025 at 09:11:17AM -0500, Paul Koning via cctalk wrote: [...] > int f1(int i) { > int j; > int f2(int x) { int y; y = j*2; ... f1(x+1); } > f2(...); > } > f1(42); > > The local variables go into stack frames, one for each call of each > function. So when recursive calls are made as in this example, there are > multiple stack frames belonging to calls of f1 and of f2. Each f1 frame > has a j in it. So how does the code for f2 find "the right f1 frame" to > resolve the reference to j that I showed? > > The answer is to have a display, which is a vector of pointers, indexed by > "static scope", in other words by textual nesting level. In this case that > vector would have three entries: one for the program, f1, and f2. When a > call to f1 is made, the stack frame is created. In the stack frame the > previous value of the display entry for f1 is saved, and that entry is > then set to the stack frame address. On function return, the previous > display entry is restored. > > To resolve the reference to j in f2, the code would load the display entry > for f1 (the second entry in the display vector), and add the offset to j > in the stack frame. That's the very old-school approach for weird CISC architectures which were mainly programmed in assembly language or with naivee compilers. It's most definitely not a *good* way to do it, performance-wise. So of course x86 supports it. When I first encountered x86's ENTER and LEAVE instructions, I thought "that's on crack". Being x86, it almost never removes features and often even doubles-down, and so this still works and is even supported in 64-bit long mode. Although the exact terminology and implementations can vary by language, these days that inner function would normally be called a "closure" which "captures" variables from the outer function. In your example, j but not i is captured by f2, and so f2 doesn't need access to all of f1's stack frame, just its j. I wrote a contrived test program in Rust and inspected the machine code, and what it did was to pass the address of j as a hidden parameter to f2. This meant that f2 already had that address in a register and didn't need to do an extra memory access to find it. The nested call used the normal CALL/RET instructions which do not do the slow and complex microcoded operations on stack frames that ENTER does. How slow are we talking? ENTER/LEAVE is also at least order of magnitude slower than CALL/RET on modern x86. On my Haswell, CALL is ~2 cycles, whereas ENTER is ~80. It's a bit better on e.g. Zen 4 at ~20 cycles, but still not great. However, I'd contrived the code so that it didn't get optimised away. Since j is not modified by the code (unless your "..." elision does it), the compiler could have passed the *value* of j as a parameter as the changed value doesn't need to be propagated back up the call stack, saving another memory access. Or most likely it'd have noticed that f2 was a good candidate for inlining and now f1 and f2 share the same stack frame and can trivially access each other's variables. ENTER/LEAVE might have perhaps been more useful on the 286 and mitigated some of its many performance problems in protected mode, but I'd rather just use pretty much anything else, possibly even pen and paper, in preference to segmented x86. --===============2748588978687169378==-- From d44617665@hotmail.com Mon Feb 17 16:26:41 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 16:26:34 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4092607977490054740==" --===============4092607977490054740== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In my case, the self-appointed gatekeeper rejected material from the AES Disk= Recording Anthology. ________________________________ From: Ken Seefried via cctalk Sent: Sunday, February 16, 2025 12:55 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Ken Seefried Subject: [cctalk] Re: Elliott Algol On Sun, Feb 16, 2025 at 1:53=E2=80=AFPM Cameron Kaiser via cctalk < cctalk(a)classiccmp.org> wrote: > > I admit to a bit of pique here: I don't even bother updating Wikipedia > articles > anymore because they'll always get reverted by someone with less of a life > than > me for any number of specious reasons. > > This is an almost perfect description of my experience of Wikipedia. --===============4092607977490054740==-- From paulkoning@comcast.net Mon Feb 17 16:28:38 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 11:28:13 -0500 Message-ID: <8F0F1097-5ECF-4B59-9833-2A67BE3703BC@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3735967530535609269==" --===============3735967530535609269== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 10:36=E2=80=AFAM, Peter Corlett via cctalk wrote: >=20 > On Mon, Feb 17, 2025 at 09:11:17AM -0500, Paul Koning via cctalk wrote: > [...] >> int f1(int i) { >> int j; >> int f2(int x) { int y; y =3D j*2; ... f1(x+1); } >> f2(...); >> } >> f1(42); >>=20 >> The local variables go into stack frames, one for each call of each >> function. So when recursive calls are made as in this example, there are >> multiple stack frames belonging to calls of f1 and of f2. Each f1 frame >> has a j in it. So how does the code for f2 find "the right f1 frame" to >> resolve the reference to j that I showed? >>=20 >> The answer is to have a display, which is a vector of pointers, indexed by >> "static scope", in other words by textual nesting level. In this case that >> vector would have three entries: one for the program, f1, and f2. When a >> call to f1 is made, the stack frame is created. In the stack frame the >> previous value of the display entry for f1 is saved, and that entry is >> then set to the stack frame address. On function return, the previous >> display entry is restored. >>=20 >> To resolve the reference to j in f2, the code would load the display entry >> for f1 (the second entry in the display vector), and add the offset to j >> in the stack frame. >=20 > That's the very old-school approach for weird CISC architectures which were > mainly programmed in assembly language or with naivee compilers. It's most > definitely not a *good* way to do it, performance-wise. Could be. Optimizing compilers weren't much of a thing in the mid-1960s. I just found a good descrption in EWD 101 https://www.cs.utexas.edu/~EWD/ewd0= 1xx/EWD101.PDF starting with "simple variable addressing" (page 2). Fortunat= ely that is in English. The D register mentions points to the display; the addressing modes M[i]= are references to frame offset i via display entry "num", and MA[i] is index= ed addressing with offset i from the A register. (That's odd, I would have e= xpected the B register which is the default stack pointer.) paul --===============3735967530535609269==-- From elson@pico-systems.com Mon Feb 17 17:03:36 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 11:03:27 -0600 Message-ID: <57b66a3b-a307-3858-d484-98843b74454d@pico-systems.com> In-Reply-To: <5E33651A-03C7-44EA-86D7-077A46515CC1@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8661281587001801292==" --===============8661281587001801292== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> On Feb 16, 2025, at 7:38=E2=80=AFPM, Van Snyder via cctalk wrote: >> >> .... It also >> had a thermal printer called "teledotis." It was very fast, so some >> called it the Whippet. It electrostatically deposited soot onto special >> paper, which was then fused by a heat roller. Teledeltos paper had a silver layer over a carbon layer, and=20 a spark blew off the silver to expose the black carbon.=C2=A0 (I=20 think that's how it worked, I haven't seen this stuff in=20 decades!)=C2=A0 It was used in early machines for sending weather=20 facsimile maps, for instance. Jon --===============8661281587001801292==-- From bfranchuk@jetnet.ab.ca Mon Feb 17 17:04:11 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 10:04:02 -0700 Message-ID: <5b484e1b-1a50-493d-84a3-9f992b22ab99@jetnet.ab.ca> In-Reply-To: <33727A8E-0666-4E7E-8E8A-C26F4D68544E@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7468646362876466124==" --===============7468646362876466124== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-17 7:26 a.m., Paul Koning via cctalk wrote: > I've never seen an ASCII terminal that was missing square brackets. But in= theory those codes were "national use" codes, and for non-English language u= se they would be redefined as A with umlaut or stuff like that. This is why = RSTS/E at some point introduced parentheses as alternates for the square brac= kets it had always used as directory name delimiters. For us in the US that = was never interesting. I live in western Canada, and they (windows) keeps wanting me not have=20 the US character set. > The problem was fixed fairly well with the introduction of the DEC Multinat= ional Character Set, which later morphed into ISO Latin-1 (with the curious = omission of the oe ligature) and later the various other Latin- sets. And= the problem was solved completely with Unicode. Could you point me to a Unicode Terminal ? There must be thousands in dumpsters with unicode 1.0. > paul >=20 I use TeraTerm 4, as termial. Could you supply a windows "DEC=20 Multinational Character Set" font so I know the program will work correctly. Ben. --===============7468646362876466124==-- From elson@pico-systems.com Mon Feb 17 17:07:00 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 11:06:52 -0600 Message-ID: In-Reply-To: <08e0ce83-b24e-4b21-bc1c-2a79fb13624f@fjl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8677755900747090413==" --===============8677755900747090413== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/17/25 08:02, Frank Leonhardt via cctalk wrote: > On 17/02/2025 05:12, ben via cctalk wrote: >> Did any classic computers have a subroutine call as >> (S++)=PC, PC=(EFA) >> as well as the standard call (--S)=PC,PC=(EFA) ? >> One  could have a virtual stack machine, using helper >> functions without having to deal with return addresses on >> the stack. > > On the more than "one stack pointer" in the subject, it > was a bit arbitrary on the PDP-11 (or VAX) as the pre/post > indexed indirect addressing made every register a stack > pointer. But this is where I get hazy between DEC and 68K, > and I did a lot more 68K. I'm pretty sure you could do a > move.l PC, An and you could certainly do an indirect jmp > (An), so effectively you could have multiple call stacks > if you wanted. Yes, on the PDP11, any register could be used as an autoincrement/decrement indirect pointer.  So, the use of R6 was merely a convention, baked into the macros in the assembler.  R7 was firmly fixed in the CPU logic as the PC, however. Jon --===============8677755900747090413==-- From cclist@sydex.com Mon Feb 17 17:30:20 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 17:30:10 +0000 Message-ID: <84d6f707-8109-4fd0-affd-8e4d809b622d@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6448118522166951195==" --===============6448118522166951195== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/17/25 06:17, Paul Koning wrote: > Also multiple functional units, seriously interleaved memory, and a bucket = full of other tricks. The way loads and stores are requested by the programm= er naturally makes them background operations, and the "stunt box" handles th= at background process. Even on the lower 6000 (6400/6500), the architecture made a large difference. Three-address architecture (c=3Da+b vs. a=3Da+b) and the lack of condition codes enabled more code "movement". That is, you could, for example, compute a value at the top of a loop and have the branch on condition at the bottom. Hand optimization for the 6600 was a big thing for standard product development (cf. Jack Neuhaus' code optimization classes) and it gave one a chance to be "clever". Rick James and Richard Frank came up with a lot of "interesting" code, such as doing 10-digit display code addition/subtraction as a parallel operation. I was pretty good at hand optimization, but for complex loops, I'd write the code in FORTRAN so that FTN and look at the generated code and work from there. On the subject of exchange jumps, I should point out that for a very long time, use of the feature was restricted to the PPUs--i.e. the CEJ/MEJ switch on the deadstart panel was "off"--OS user requests were exclusively through the RA+1 mechanism. One of most ingenious coding tricks to me was the problem of saving and restoring all registers without resorting to an exchange jump. We used that one as a test for applicants. All in all, I'd consider the CDC 6600 to be the crowning glory of Seymour Cray's career. --Chuck --===============6448118522166951195==-- From cclist@sydex.com Mon Feb 17 17:35:56 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 17:35:47 +0000 Message-ID: <0135aba4-d41a-4bf8-851d-fe1ab0df5fd2@sydex.com> In-Reply-To: <57b66a3b-a307-3858-d484-98843b74454d@pico-systems.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4589085825664206175==" --===============4589085825664206175== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/17/25 09:03, Jon Elson via cctalk wrote: > Teledeltos paper had a silver layer over a carbon layer, and a spark > blew off the silver to expose the black carbon.  (I think that's how it > worked, I haven't seen this stuff in decades!)  It was used in early > machines for sending weather facsimile maps, for instance. I think the stuff may still be available in single sheets for physics demonstrations and perhaps for use in kymographs not using ink. I checked up on availability perhaps 20 years ago, but not recently. --Chuck --===============4589085825664206175==-- From cclist@sydex.com Mon Feb 17 17:41:17 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 17:41:07 +0000 Message-ID: In-Reply-To: <4954CE0E-297D-4552-B138-9687207F6BEA@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0067362129964515117==" --===============0067362129964515117== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit While a hardware stack may be useful, I don't consider it to be essential and perhaps counter-productive. (dodging brickbats). I say that because if a recursive solution to a problem is available on a stack-oriented architecture, the natural impulse is to program a recursive solution. Lack of hardware support for recursion might otherwise push one toward an iterative approach, which in many cases can perform better. --Chuck --===============0067362129964515117==-- From mjd.bishop@emeritus-solutions.com Mon Feb 17 17:44:50 2025 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 17:44:44 +0000 Message-ID: <667f5e4eb12a4e06956c2383a5981822@emeritus-solutions.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0852015341794524267==" --===============0852015341794524267== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable R6 (SP) is a magic register in the PDP-11 architecture. Its use is baked into JSR, RTS, MARK, BPT, RTI, etc, traps and aborts. You are quite correct that all registers provide address inc/dec However, some instructions / actions (eg aborts) make implicit use of SP Martin -----Original Message----- From: Jon Elson via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 17 February 2025 17:07 To: Frank Leonhardt via cctalk Cc: Jon Elson Subject: [cctalk] Re: Classic computers with more than one stack pointer, but= not FORTH machines. On 2/17/25 08:02, Frank Leonhardt via cctalk wrote: > On 17/02/2025 05:12, ben via cctalk wrote: >> Did any classic computers have a subroutine call as (S++)=3DPC,=20 >> PC=3D(EFA) as well as the standard call (--S)=3DPC,PC=3D(EFA) ? >> One=C2=A0 could have a virtual stack machine, using helper functions=20 >> without having to deal with return addresses on the stack. > > On the more than "one stack pointer" in the subject, it was a bit=20 > arbitrary on the PDP-11 (or VAX) as the pre/post indexed indirect=20 > addressing made every register a stack pointer. But this is where I=20 > get hazy between DEC and 68K, and I did a lot more 68K. I'm pretty=20 > sure you could do a move.l PC, An and you could certainly do an=20 > indirect jmp (An), so effectively you could have multiple call stacks=20 > if you wanted. Yes, on the PDP11, any register could be used as an autoincrement/decrement i= ndirect pointer.=C2=A0 So, the use of R6 was merely a convention, baked into = the macros in the assembler.=C2=A0 R7 was firmly fixed in the CPU logic as th= e PC, however. Jon --===============0852015341794524267==-- From bfranchuk@jetnet.ab.ca Mon Feb 17 17:56:59 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 10:56:50 -0700 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0629068422971468547==" --===============0629068422971468547== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-17 10:41 a.m., Chuck Guzis via cctalk wrote: > > While a hardware stack may be useful, I don't consider it to be > essential and perhaps counter-productive. (dodging brickbats). A jump to subroutine is convenient , but could be omitted. > I say that because if a recursive solution to a problem is available on > a stack-oriented architecture, the natural impulse is to program a > recursive solution. Lack of hardware support for recursion might > otherwise push one toward an iterative approach, which in many cases can > perform better. A recursive solution is fine, if you have bounds checking on the calls. On a iterative approach, one can recover from bad input. > --Chuck > Ben. --===============0629068422971468547==-- From bitwiz@12bitsbest.com Mon Feb 17 18:05:26 2025 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 12:05:18 -0600 Message-ID: <5cce5772-d421-4f65-baa8-de77c78aaeaf@12bitsbest.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6201683806541000988==" --===============6201683806541000988== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Recursion is normally limited to stack depth.  On systems with limited stack space or where the recursion depth may exceed the stack size, iteration may work better. Also, many compilers can optimize loops where has optimizing recursion is a much more difficult thing.  Some optimizers can use iteration machine language instructions (such as loop) to even further optimize iteration. Recursion requires the stacking and unstacking of registers (PC, frame pointer, parameters, etc.).  This will also slow down recursion vs iteration. Recursion has its uses but should not be used just to be cute or clever.  The programmer should weigh the benefits of both before deciding. For example, I wrote a function to display directories and when it encountered a sub-directory it called itself to display the sub-directory. On 2/17/2025 11:41 AM, Chuck Guzis via cctalk wrote: > While a hardware stack may be useful, I don't consider it to be > essential and perhaps counter-productive. (dodging brickbats). > > I say that because if a recursive solution to a problem is available on > a stack-oriented architecture, the natural impulse is to program a > recursive solution. Lack of hardware support for recursion might > otherwise push one toward an iterative approach, which in many cases can > perform better. > > --Chuck > --===============6201683806541000988==-- From bitwiz@12bitsbest.com Mon Feb 17 18:08:20 2025 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 12:08:10 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7374287125073879863==" --===============7374287125073879863== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The PDP-8 didn't have a stack pointer at all.  Many interpreters and compilers implemented their own software stack. Architectures like the 6809 and PDP-11 and 68000 lend themselves to creating multiple software stacks. On 2/17/2025 11:56 AM, ben via cctalk wrote: > On 2025-02-17 10:41 a.m., Chuck Guzis via cctalk wrote: >> >> While a hardware stack may be useful, I don't consider it to be >> essential and perhaps counter-productive. (dodging brickbats). > > A jump to subroutine is convenient , but could be omitted. > >> I say that because if a recursive solution to a problem is available on >> a stack-oriented architecture, the natural impulse is to program a >> recursive solution.  Lack of hardware support for recursion might >> otherwise push one toward an iterative approach, which in many cases can >> perform better. > > A recursive solution is fine, if you have bounds checking on the calls. > On a iterative approach, one can recover from bad input. > >> --Chuck >> > > Ben. > --===============7374287125073879863==-- From frank@fjl.co.uk Mon Feb 17 18:14:40 2025 From: Frank Leonhardt To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Mon, 17 Feb 2025 13:51:35 +0000 Message-ID: <21e53315-938c-4b08-b40f-9fa77b0436fd@fjl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8662887230162781641==" --===============8662887230162781641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 17/02/2025 05:12, ben via cctalk wrote: > Did any classic computers have a subroutine call as (S++)=PC, PC=(EFA) > as well as the standard call (--S)=PC,PC=(EFA) ? > One  could have a virtual stack machine, using helper functions > without having to deal with return addresses on the stack. On the more than "one stack pointer" in the subject, it was a bit arbitrary on the PDP-11 (or VAX) as the pre/post indexed indirect addressing made every register a stack pointer. But this is where I get hazy between DEC and 68K, and I did a lot more 68K. I'm pretty sure you could do a move.l PC, An and you could certainly do an indirect jmp (An), so effectively you could have multiple call stacks if you wanted. --===============8662887230162781641==-- From artgodwin@gmail.com Mon Feb 17 18:22:34 2025 From: Adrian Godwin To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 18:22:17 +0000 Message-ID: In-Reply-To: <0135aba4-d41a-4bf8-851d-fe1ab0df5fd2@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0152862801696053245==" --===============0152862801696053245== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit There was one of those in the CAD system at Acorn when I joined in about 1990, though it was fairly quickly replaced by HP plotters and laser printers (laser printers were the HP engine used in the LW4 but with our own rasterizer in an ARM-based machine). On Mon, Feb 17, 2025 at 5:35 PM Chuck Guzis via cctalk < cctalk(a)classiccmp.org> wrote: > On 2/17/25 09:03, Jon Elson via cctalk wrote: > > > Teledeltos paper had a silver layer over a carbon layer, and a spark > > blew off the silver to expose the black carbon. (I think that's how it > > worked, I haven't seen this stuff in decades!) It was used in early > > machines for sending weather facsimile maps, for instance. > > I think the stuff may still be available in single sheets for physics > demonstrations and perhaps for use in kymographs not using ink. I > checked up on availability perhaps 20 years ago, but not recently. > > --Chuck > > --===============0152862801696053245==-- From paulkoning@comcast.net Mon Feb 17 19:31:00 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 14:30:37 -0500 Message-ID: <0FC6271E-B082-4CB0-92F3-70B54C0571FF@comcast.net> In-Reply-To: <5b484e1b-1a50-493d-84a3-9f992b22ab99@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8901555434011733533==" --===============8901555434011733533== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 12:04=E2=80=AFPM, ben via cctalk wrote: >=20 > On 2025-02-17 7:26 a.m., Paul Koning via cctalk wrote: >=20 > ... >> The problem was fixed fairly well with the introduction of the DEC Multina= tional Character Set, which later morphed into ISO Latin-1 (with the curious= omission of the oe ligature) and later the various other Latin- sets. An= d the problem was solved completely with Unicode. >=20 > Could you point me to a Unicode Terminal ? > There must be thousands in dumpsters with unicode 1.0. No, since current Unicode is an upware compatible extension of the original. = Typical modern terminal emulator programs handle Unicode; my Mac certainly d= oes and there are even examples for Windows (like Putty). >> paul >=20 > I use TeraTerm 4, as termial. Could you supply a windows "DEC Multinationa= l Character Set" font so I know the program will work correctly. No, but you could make one up easily enough. Start with Latin-1, and replace= the few characters that are different. A VT220 reference will tell you the = ones to replace. Any font editor should do this easily. paul --===============8901555434011733533==-- From paulkoning@comcast.net Mon Feb 17 19:39:09 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 14:38:47 -0500 Message-ID: In-Reply-To: <84d6f707-8109-4fd0-affd-8e4d809b622d@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7184707479674345151==" --===============7184707479674345151== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 12:30=E2=80=AFPM, Chuck Guzis wrot= e: >=20 > On 2/17/25 06:17, Paul Koning wrote: >=20 >> Also multiple functional units, seriously interleaved memory, and a bucket= full of other tricks. The way loads and stores are requested by the program= mer naturally makes them background operations, and the "stunt box" handles t= hat background process. >=20 > Even on the lower 6000 (6400/6500), the architecture made a large > difference. Three-address architecture (c=3Da+b vs. a=3Da+b) and the lack > of condition codes enabled more code "movement". That is, you could, > for example, compute a value at the top of a loop and have the branch on > condition at the bottom. Yes, though it's possible to enable such things with condition code machines = if the setting of the condition code is selective. The Electrologica machine= s have this: there is an instruction modifier bit that tells the machine to u= pdate the condition flag based on result zero, result positive, or a third op= tion that I never remember -- or to leave it untouched. Subroutine calls sav= e the flag and the return can restore it if you want, or not if you don't. F= inally, almost all instructions can be conditional on the flag if you want, e= ither "execute if flag set" or "execute if flag clear" or unconditional. The= EL-X1 Wikipedia article shows an example. > Hand optimization for the 6600 was a big thing for standard product > development (cf. Jack Neuhaus' code optimization classes) and it gave > one a chance to be "clever". Rick James and Richard Frank came up with > a lot of "interesting" code, such as doing 10-digit display code > addition/subtraction as a parallel operation. I don't know that one, but there is the famous OTOD -- convert a 60-bit value= to a 20 digit octal string. I did a variation on that (not quite as slick) = to convert a 60-bit value to a 15 digit hex string. > I was pretty good at hand optimization, but for complex loops, I'd write > the code in FORTRAN so that FTN and look at the generated code and work > from there. Interesting. I worked on a 6500 so a lot of optimizations were not relevant,= but I spent a while studying code in NOS to learn how to do it. One thing t= hat did matter was shuffling instructions around to avoid NOP padding. I onc= e had a piece of code that was subject to hard real time constraints -- which= I did not know -- so when I broke it I had to revise it to get rid of all th= e NOPs. Then it was fast enough again. > On the subject of exchange jumps, I should point out that for a very > long time, use of the feature was restricted to the PPUs--i.e. the > CEJ/MEJ switch on the deadstart panel was "off"--OS user requests were > exclusively through the RA+1 mechanism. Really? I never heard of anyone who ran with CEJ disabled -- why would you w= ant to do that? > One of most ingenious coding tricks to me was the problem of saving and > restoring all registers without resorting to an exchange jump. We used > that one as a test for applicants. Oh yes... > All in all, I'd consider the CDC 6600 to be the crowning glory of > Seymour Cray's career. Indeed, though I sure would like to know how to make the timing work. If you= do what's documented in the schematics (in a VHDL model) it doesn't work. paul --===============7184707479674345151==-- From van.snyder@sbcglobal.net Mon Feb 17 19:58:47 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 11:58:35 -0800 Message-ID: <14080331a201ff211da0f2bd63823de2e50c662c.camel@sbcglobal.net> In-Reply-To: <5E33651A-03C7-44EA-86D7-077A46515CC1@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0096017916481802029==" --===============0096017916481802029== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2025-02-17 at 08:53 -0500, Paul Koning wrote: > > > > On Feb 16, 2025, at 7:38 PM, Van Snyder via cctalk > > wrote: > > > > .... It also > > had a thermal printer called "teledotis." It was very fast, so some > > called it the Whippet. It electrostatically deposited soot onto > > special > > paper, which was then fused by a heat roller. > > I would call that an "electrostatic printer" -- xerographic printer > work that way, depositing plastic soot that is then melted onto the > paper.  At U of Illinois I used a printer very much like what you > describe, made by Varian.  That was a dot matrix line printer -- a > row of pixels across the page at once -- we used for printing music > scores.  100 dpi or so if I remember right. One of my university classmates worked for American Geophysical. They would lay out a few thousand feet of cables with "geophones" on them, then drive around with "thumper" trucks. They analyzed the data using Varian V70 computers with FFT in microcode. They printed the resulting maps on 36" wide scrolls using — you guessed it — Varian electrostatic printers. My senior undergraduate project was to convince a V70 that it was actually an IBM 1130. The university had replaced an aging 1130 with a V70, then discovered that Varian didn't have a COBOL compiler — but they wanted to continue to teach COBOL. The 1130 emulator fit in less than 512 words of control store. And, as you might expect, it was much faster than the real McCoy. I also developed somewhat better 630f microcode, but Varian didn't want it — and in the process discovered their diagnostic program had a bug: It couldn't tell the difference between "load" and "and.". The V70 microcode design was well done. Then Univac boiught Varian Data Machines. I thought they were planning on doing what CDC did, using 18-bit versions of V70s as "peripheral processors" for data channels. But they just pounded it into the ground. Kind of like they did with the RCA Spectra 70. All they wanted was the customer address database so they could sell 9000's, not RCA technology. One of the steps in curing my prostate cancer was treatment using — again you guessed it — a Varian X-ray machine. The Varian brothers were true geniuses. --===============0096017916481802029==-- From van.snyder@sbcglobal.net Mon Feb 17 20:08:46 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 12:08:36 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7566090056747037748==" --===============7566090056747037748== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2025-02-17 at 09:13 -0500, Paul Koning wrote: > > When Tom Pennello was a grad student studying under Frank de Remer > > at > > ACSC, he collected a big pile of codes in languages that had nested > > lexical and dynamic scopes (such as recursive internal functions). > > He > > found that chasing up-links was much faster than displays. In some > > cases, creating and destroying the display took six times longer > > than > > executing the function. I mentioned this to Malcolm Cohen and me > > mumbled something about a "trampoline." I have no idea what that > > is. > > I'm puzzled by that, since the display is a static data structure and > updating it takes only a few instructions for each call and fewer for > a return. The display isn't static for nested recursive functions (as in Pascal) and you want to have "deep binding," not "shallow binding." The "up link" for a recursive function passed to another recursive procedure as an actual argument should be the "up link" as of the moment of invocation of the procedure getting the nested one, not as of the moment the nested one finally gets invoked by way of the formal argument during a recursion by the procedure that got it as an actual argument. Pennello had some Pascal "compiler breaker" codes that he would use to test compilers. After he graduated, he worked for Frank de Remer at MetaWare. They marketed Pascal compilers for many machines. Tom called it "overextended Pascal." I don't know whether the Algol 60 Report or the Algol 68 standard or the Pascal Report explicitly specified deep binding, but it's more useful than shallow binding. The Fortran standards explicitly require deep binding, but not using those words. > "Trampolines" are how GCC handles nested functions, or at least that > is the traditional mechanism.  I never really understood them other > than to realize they involve executable code on the stack -- which > means they only work in some machines and some operating systems.  I > think there is now a replacement mechanism that avoids this issue but > I don't remember the details.  Why GCC didn't adopt displays isn't > clear to me. --===============7566090056747037748==-- From bfranchuk@jetnet.ab.ca Mon Feb 17 20:11:40 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 13:11:29 -0700 Message-ID: <4e2a2259-d0f7-41cb-a804-4cdbacebff03@jetnet.ab.ca> In-Reply-To: <0FC6271E-B082-4CB0-92F3-70B54C0571FF@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4698092789171454600==" --===============4698092789171454600== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2025-02-17 12:30 p.m., Paul Koning wrote: >=20 >=20 >> On Feb 17, 2025, at 12:04=E2=80=AFPM, ben via cctalk wrote: >> >> On 2025-02-17 7:26 a.m., Paul Koning via cctalk wrote: >> >> ... >>> The problem was fixed fairly well with the introduction of the DEC Multin= ational Character Set, which later morphed into ISO Latin-1 (with the curiou= s omission of the oe ligature) and later the various other Latin- sets. A= nd the problem was solved completely with Unicode. >> >> Could you point me to a Unicode Terminal ? >> There must be thousands in dumpsters with unicode 1.0. >=20 > No, since current Unicode is an upware compatible extension of the original= . Typical modern terminal emulator programs handle Unicode; my Mac certainly= does and there are even examples for Windows (like Putty). >=20 If I wanted a terminal emulation I would not ask for hardware. >>> paul >> >> I use TeraTerm 4, as termial. Could you supply a windows "DEC Multination= al Character Set" font so I know the program will work correctly. >=20 > No, but you could make one up easily enough. Start with Latin-1, and repla= ce the few characters that are different. A VT220 reference will tell you th= e ones to replace. Any font editor should do this easily. >=20 For now I am stuck with US ASCII 1969. I got a WYSE terminal I can use,=20 but for now need to transfer files to a remote computer, thus the PC. > paul=20 >=20 Is there any one working on a stand alone terminal that will emulate hard copy over strikes? What are people using to replace the ageing hard copy devices paper tape and printers. --===============4698092789171454600==-- From van.snyder@sbcglobal.net Mon Feb 17 20:27:19 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 12:27:09 -0800 Message-ID: <13c5b90f12bbd6c8a64fe287b5ff821d3ba9c937.camel@sbcglobal.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3692169015456685825==" --===============3692169015456685825== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2025-02-17 at 09:17 -0500, Paul Koning via cctalk wrote: > Also multiple functional units, seriously interleaved memory, and a > bucket full of other tricks.  The way loads and stores are requested > by the programmer naturally makes them background operations, and the > "stunt box" handles that background process. I remember the "stunt box" also being called the "traffic cop." The Denelcor HEP had asynchronous memory access. It had several (sixteen, IIRC) functional units and hardware thread switching. When a memory access occurred, the register file was saved (or maybe there were more register files than hardware processors — my memory is foggy here) and another thread was put into a functional unit. When the memory access was completed, the register file was put into the functional unit queue. Arvind at MIT was a dataflow investigator. Greg Papadopolous (later Chief Technical Officer at Sun Microsystems) developed the Monsoon tagged-token dataflow computer as his PhD project. Rishiyur Nikhil described a RISC architecture that was augmented with asynchronous memory access and automatic thread switching.  Burton Smith and James Rottsalk founded Tera Computing to develop a computer called the Multi Tread Architecture or MTA, IIRC based on Nikhil's ideas. They bought the ashes of Cray and promptly changed their name to Cray. But the MTA had a fatal flaw that neither Tera nor the Cray engineers they absorbed were able to resolve: It had a 100 MHz bottleneck. Even so, it was faster than the "supercomputer" that IBM was offering at the time — but only on a sort benchmark. --===============3692169015456685825==-- From paulkoning@comcast.net Mon Feb 17 20:52:57 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 15:52:36 -0500 Message-ID: <7B3FA7A3-7E4F-4D1D-867F-03F8400E90D9@comcast.net> In-Reply-To: <14080331a201ff211da0f2bd63823de2e50c662c.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4236225478374347962==" --===============4236225478374347962== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 2:58=E2=80=AFPM, Van Snyder wrote: >=20 > On Mon, 2025-02-17 at 08:53 -0500, Paul Koning wrote: >>=20 >>=20 >>=20 >>=20 >>> On Feb 16, 2025, at 7:38=E2=80=AFPM, Van Snyder via cctalk wrote: >>>=20 >>> .... It also >>> had a thermal printer called "teledotis." It was very fast, so some >>> called it the Whippet. It electrostatically deposited soot onto special >>> paper, which was then fused by a heat roller. >>=20 >> I would call that an "electrostatic printer" -- xerographic printer work t= hat way, depositing plastic soot that is then melted onto the paper. At U of= Illinois I used a printer very much like what you describe, made by Varian. = That was a dot matrix line printer -- a row of pixels across the page at onc= e -- we used for printing music scores. 100 dpi or so if I remember right. >=20 >=20 > One of my university classmates worked for American Geophysical. They would= lay out a few thousand feet of cables with "geophones" on them, then drive a= round with "thumper" trucks. They analyzed the data using Varian V70 computer= s with FFT in microcode. They printed the resulting maps on 36" wide scrolls = using =E2=80=94 you guessed it =E2=80=94 Varian electrostatic printers. > ... > The Varian brothers were true geniuses. Indeed. There's a wonderful photo of them by Ansel Adams. Look for it; it s= hows the two of them doing a mad-genius imitation, with a random collection o= f waveguides and the like in their hands. The Varian printer had one interesting issue. It had a chain drive, with som= e slack in the chain. If you fed it data non-stop it worked great, but if yo= u ever had to pause the data stream, the stop and start of the paper would le= ave a gap in the output. Very visible if you were trying to plot continuous= lines (like the 5 horizontal lines in a music score). The original applicat= ion to feed that printer on the PLATO system was a batch job that routinely g= ot pre-empted by the scheduler, just long enough for its buffer to go empty. = I ended up doing the whole job in PPUs (reading the input file as well as fe= eding the printer). paul --===============4236225478374347962==-- From paulkoning@comcast.net Mon Feb 17 20:55:03 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 15:54:43 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4776040894035032282==" --===============4776040894035032282== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 3:08=E2=80=AFPM, Van Snyder wrote: >=20 > On Mon, 2025-02-17 at 09:13 -0500, Paul Koning wrote: >>=20 >>>=20 >>> When Tom Pennello was a grad student studying under Frank de Remer at >>> ACSC, he collected a big pile of codes in languages that had nested >>> lexical and dynamic scopes (such as recursive internal functions). He >>> found that chasing up-links was much faster than displays. In some >>> cases, creating and destroying the display took six times longer than >>> executing the function. I mentioned this to Malcolm Cohen and me >>> mumbled something about a "trampoline." I have no idea what that is. >>=20 >> I'm puzzled by that, since the display is a static data structure and upda= ting it takes only a few instructions for each call and fewer for a return. >=20 > The display isn't static for nested recursive functions (as in Pascal) and = you want to have "deep binding," not "shallow binding." I meant static as in allocation, not content. Yes, it changes for every call= , but that change is only 2 or 3 instructions. paul --===============4776040894035032282==-- From cclist@sydex.com Mon Feb 17 20:58:40 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 20:58:32 +0000 Message-ID: <58d3604d-4d70-4ab2-a094-4cde119917ef@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7682519848196902423==" --===============7682519848196902423== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/17/25 11:38, Paul Koning wrote: > Yes, though it's possible to enable such things with condition code machine= s if the setting of the condition code is selective. The Electrologica machi= nes have this: there is an instruction modifier bit that tells the machine to= update the condition flag based on result zero, result positive, or a third = option that I never remember -- or to leave it untouched. Subroutine calls s= ave the flag and the return can restore it if you want, or not if you don't. = Finally, almost all instructions can be conditional on the flag if you want,= either "execute if flag set" or "execute if flag clear" or unconditional. T= he EL-X1 Wikipedia article shows an example. Didn'r know about the EL one, thanks. > I don't know that one, but there is the famous OTOD -- convert a 60-bit val= ue to a 20 digit octal string. I did a variation on that (not quite as slick= ) to convert a 60-bit value to a 15 digit hex string. Yes, I recall that one. > Interesting. I worked on a 6500 so a lot of optimizations were not relevan= t, but I spent a while studying code in NOS to learn how to do it. One thing= that did matter was shuffling instructions around to avoid NOP padding. I o= nce had a piece of code that was subject to hard real time constraints -- whi= ch I did not know -- so when I broke it I had to revise it to get rid of all = the NOPs. Then it was fast enough again. I seem to remember that using non-zero registers in the no-op (46000) instruction could affect the timing. It was a long time ago and before the CMU. > Really? I never heard of anyone who ran with CEJ disabled -- why would you= want to do that? I assume that CE MACE had some tests that required it to be disabled. At least I recall taking the system after CE time and having to remember to check the CEJ/MEJ switch as well as the deadstart code switches. Greg Mansfield might recall details, but I don't know if he's still around--he'd be in advanced golden years now. > Indeed, though I sure would like to know how to make the timing work. If y= ou do what's documented in the schematics (in a VHDL model) it doesn't work. My section manager from the 70s, Mike Miller, had the job as a wet-behind-the-ears EE fresh from UM had the job of measuring the backplane loops to which Seymour had attacked a tag that said "TUNE". One doesn't normally think of wire length being critical to operation, but apparently it was on the 6600. I don't know if the schematics show that. One architecture not actively discussed even donkey's years back was the 7600. You couldn't run a 6000-series deadstart tape on it, because of substantial architectural differences. The PPUs were assigned buffer areas in SCM and couldn't stray out of them, so a PPU-oriented operating system wasn't possible. 7000 SCOPE used the idea of nested field lengths to implement the OS. So you had Job Supervisor, Buffer Manager, Record Manager...and so on until the user program on the innermost FL, something like one of those Russian matryoshka dolls . Apparently, it was very inefficient in practice, particularly given the relatively small amount of SCM. --Chuck --===============7682519848196902423==-- From van.snyder@sbcglobal.net Mon Feb 17 21:08:36 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 13:08:27 -0800 Message-ID: <501e8b5e536996e804e18765a94984146bd7254d.camel@sbcglobal.net> In-Reply-To: <0135aba4-d41a-4bf8-851d-fe1ab0df5fd2@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7151091033863525848==" --===============7151091033863525848== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2025-02-17 at 17:35 +0000, Chuck Guzis via cctalk wrote: > > Teledeltos paper had a silver layer over a carbon layer, and a > > spark > > blew off the silver to expose the black carbon.  (I think that's > > how it > > worked, I haven't seen this stuff in decades!)  It was used in > > early > > machines for sending weather facsimile maps, for instance. I think the printer beside the B220 in the Caltech Boothe computer center was probably mistakenly called a teledotis printer. It definitely deposited soot on the paper, and then thermally fused it. > --===============7151091033863525848==-- From paul@mcjones.org Mon Feb 17 22:02:35 2025 From: Paul McJones To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 14:02:28 -0800 Message-ID: In-Reply-To: <173972880918.1298.9258629262107476474@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4414032516049066607==" --===============4414032516049066607== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 15 Feb 2025 18:41:21 -0800,Van Snyder > wrote: >=20 > Harry Husky, the G15 designer, was one of the computer design pioneers. > He became a professor (maybe adjunct) at UC Berkeley.=20 As far as I know, Huskey was a regular professor. Two of his Ph.D. students w= ent on to win the ACM Turing Award: Niklaus Wirth and Butler Lampson: https://mathgenealogy.org/id.php?id=3D10185 Huskey went on to found the Computer Science department at U.C. Santa Cruz. --===============4414032516049066607==-- From cclist@sydex.com Mon Feb 17 22:23:57 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 22:23:46 +0000 Message-ID: <67946753-b7b6-4c22-9bb7-8fb932090c19@sydex.com> In-Reply-To: <4e2a2259-d0f7-41cb-a804-4cdbacebff03@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5814135240916453413==" --===============5814135240916453413== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/17/25 12:11, ben via cctalk wrote: > Is there any one working on a stand alone terminal that will > emulate hard copy over strikes?  What are people using to replace > the ageing hard copy devices paper tape and printers. I believe that this was a feature for a limited set of characters in Videotex. Namely, a diacritic mark followed by a character produced the character with the diacritic attached. Of course, this would be trivial on a bitmapped graphics terminal. --Chc --===============5814135240916453413==-- From paul@mcjones.org Mon Feb 17 22:27:28 2025 From: Paul McJones To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 14:27:22 -0800 Message-ID: <4B135F7C-3821-45A0-B581-B2FD9FEB988A@mcjones.org> In-Reply-To: <173981521042.1298.3721855835524792824@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3471914010324803811==" --===============3471914010324803811== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 16 Feb 2025 18:00:35 -0700,ben > wrote: >=20 > I have trouble understanding the fine points of accessing a local=20 > variable in Algol with a display. Books tend to spend more time > on the evils of a dangling else, and gloss over the run time action of > a display. > Have a good example or reference book I can find free on line. The original book on that subject is ALGOL 60 Implementation by B. Randell an= d L. J. Russell. It=E2=80=99s available here with permission from the copyrig= ht holder: https://www.softwarepreservation.org/projects/ALGOL/algol60impl/#ALGOL_60_Imp= lementation --===============3471914010324803811==-- From mjd.bishop@emeritus-solutions.com Mon Feb 17 22:32:10 2025 From: Martin Bishop To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 22:32:01 +0000 Message-ID: In-Reply-To: <501e8b5e536996e804e18765a94984146bd7254d.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8223244456482523238==" --===============8223244456482523238== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Once upon a time - 35 - 45 years ago - I had the pleasure (sic) of working wi= th: https://archive.org/details/TNM_Versatec_printers_and_plotters_-_Versatec_a_X= _20180227_0009 for temperamental plots of telemetry traces https://www.ebay.co.uk/itm/404623414575 manual for sale EPC Graphic Recorder 1600 Series product data see https://mitmuseum.mit.edu/c= ollections/object/2014.028.0253.01 The "gram writers" https://www.usni.org/magazines/naval-history-magazine/2021= /february/66-years-undersea-surveillance probably use a near relative Magic paper, two styli on a belt (one burning, one returning), pour in 1+? bi= t data and hope to see what you are looking for I built an interface box for an EPC 1600 a few years before the technology wa= s superceeded (by thermal "fax" printers) Both technologies had the great merit of producing long time histories, diffi= cult to store by excellent for analysis Martin -----Original Message----- From: Van Snyder via cctalk [mailto:cctalk(a)classiccmp.org]=20 Sent: 17 February 2025 21:08 To: cctalk(a)classiccmp.org Cc: Van Snyder Subject: [cctalk] Re: Elliott Algol On Mon, 2025-02-17 at 17:35 +0000, Chuck Guzis via cctalk wrote: > > Teledeltos paper had a silver layer over a carbon layer, and a spark=20 > > blew off the silver to expose the black carbon.=C2=A0 (I think that's how= =20 > > it worked, I haven't seen this stuff in decades!)=C2=A0 It was used in=20 > > early machines for sending weather facsimile maps, for instance. I think the printer beside the B220 in the Caltech Boothe computer center was= probably mistakenly called a teledotis printer. It definitely deposited soot= on the paper, and then thermally fused it. >=20 --===============8223244456482523238==-- From wrcooke@wrcooke.net Tue Feb 18 00:32:23 2025 From: wrcooke@wrcooke.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 19:32:19 -0500 Message-ID: <1364588546.114794.1739838739032@email.ionos.com> In-Reply-To: <7B3FA7A3-7E4F-4D1D-867F-03F8400E90D9@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1833933360748208963==" --===============1833933360748208963== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On 02/17/2025 3:52 PM EST Paul Koning via cctalk = wrote: > > Indeed. There's a wonderful photo of them by Ansel Adams. Look for it; it= shows the two of them doing a mad-genius imitation, with a random collection= of waveguides and the like in their hands. > I believe that photo is here: https://www.apollo-magazine.com/silicon-valley-portraits-publicity-artificial= -intelligence/ Will --===============1833933360748208963==-- From paulkoning@comcast.net Tue Feb 18 01:00:54 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 20:00:30 -0500 Message-ID: <350FE21E-3F3B-4A96-9A2B-1E95317A6A44@comcast.net> In-Reply-To: <1364588546.114794.1739838739032@email.ionos.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1547859566367738970==" --===============1547859566367738970== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 7:32=E2=80=AFPM, Will Cooke via cctalk wrote: >=20 >=20 >> On 02/17/2025 3:52 PM EST Paul Koning via cctalk = wrote: >=20 >>=20 >> Indeed. There's a wonderful photo of them by Ansel Adams. Look for it; i= t shows the two of them doing a mad-genius imitation, with a random collectio= n of waveguides and the like in their hands. >>=20 >=20 > I believe that photo is here: > https://www.apollo-magazine.com/silicon-valley-portraits-publicity-artifici= al-intelligence/ >=20 > Will Yes, that's the one. Impressive photo. paul --===============1547859566367738970==-- From van.snyder@sbcglobal.net Tue Feb 18 01:25:36 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 17:25:24 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5896912567656598338==" --===============5896912567656598338== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Mon, 2025-02-17 at 14:02 -0800, Paul McJones wrote: > > On 15 Feb 2025 18:41:21 -0800,Van Snyder > > wrote: > > > > Harry Husky, the G15 designer, was one of the computer design > > pioneers. > > He became a professor (maybe adjunct) at UC Berkeley.  > > As far as I know, Huskey was a regular professor. Two of his Ph.D. > students went on to win the ACM Turing Award: Niklaus Wirth and > Butler Lampson: Was he a Bendix employee also, perhaps before he was a professor, or was he a consultant to Bendix while he was a professor? > > https://mathgenealogy.org/id.php?id=10185 > > Huskey went on to found the Computer Science department at U.C. Santa > Cruz. --===============5896912567656598338==-- From paul@mcjones.org Tue Feb 18 02:13:35 2025 From: Paul McJones To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Mon, 17 Feb 2025 18:13:27 -0800 Message-ID: <9A902F14-CF7A-4A57-9B7D-523CCD282E20@mcjones.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1097271637310003270==" --===============1097271637310003270== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 17, 2025, at 5:25=E2=80=AFPM, Van Snyder wrote: >=20 > On Mon, 2025-02-17 at 14:02 -0800, Paul McJones wrote: >>> On 15 Feb 2025 18:41:21 -0800,Van Snyder > wrote: >>>=20 >>> Harry Husky, the G15 designer, was one of the computer design pioneers. >>> He became a professor (maybe adjunct) at UC Berkeley.=20 >>=20 >> As far as I know, Huskey was a regular professor. Two of his Ph.D. student= s went on to win the ACM Turing Award: Niklaus Wirth and Butler Lampson: >=20 > Was he a Bendix employee also, perhaps before he was a professor, or was he= a consultant to Bendix while he was a professor? According to Mathematics at Berkeley: A History by Calvin C. Moore, after des= igning and building the SWAC computer between December 6, 1948 and July 1950,= =20 "Huskey stayed on at UCLA with the title of assistant director of the institu= te for Numerical Analysis (INA), helping people use the machine. During 1952-= 1953, he took a one-year leave of absence from INA to go to Wayne State Unive= rsity, where, as founding director of the computational laboratory, he establ= ished a first-rate operation. At the same time, he dusted off some old ideas = and designed the first =E2=80=98personal computer,=E2=80=99 which he sold to = the Bendix Corporation. Bendix produced and marketed this machine as the G-15= for a price of about $50,000, and it was a commercial success. =E2=80=A6 This book, which I highly recommend, describes Huskey=E2=80=99s earlier work = on ENIAC and the Pilot Ace. And it says Huskey was initially hired as an acti= ng associate professor for the 1954-55 academic year (jointly in mathematics = and engineering), was hired as an associate professor in July 1955 and promot= ed to full professor in 1958. https://epdf.pub/mathematics-at-berkeley-a-historya94c16b23316199e68e103a3fa0= 0a1563288.html --===============1097271637310003270==-- From lewissa78@gmail.com Tue Feb 18 05:24:08 2025 From: Steve Lewis To: cctalk@classiccmp.org Subject: [cctalk] VCF SoCal 2025 recap Date: Mon, 17 Feb 2025 23:23:53 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6225740280309322484==" --===============6225740280309322484== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Happened to be in the area, so I checked out VCF SoCal last weekend. Glad I did, wow Lee Felsenstein was able to present ! What a treat. VCF SoCal 2025 — voidstar https://voidstar.blog/vcf-socal-2025/ --===============6225740280309322484==-- From hupfadekroua@gmail.com Tue Feb 18 07:44:20 2025 From: hupfadekroua To: cctalk@classiccmp.org Subject: [cctalk] HAWLEY X063X Mark II and XEROX Star mice Date: Tue, 18 Feb 2025 08:43:57 +0100 Message-ID: <3334CDF3-27EA-4A70-B4C0-4B1A2A04FCF4@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1519164318737199833==" --===============1519164318737199833== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi all, I‘m offering HAWLEY X063X, XEROX Star rollerball and optical mice. If interested contact me offlist please. Best Andreas --===============1519164318737199833==-- From jwsmail@jwsss.com Tue Feb 18 07:45:01 2025 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Tue, 18 Feb 2025 01:44:52 -0600 Message-ID: <18fbc92a-32a2-47a9-a45b-388e25f6776b@jwsss.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6643407158336719189==" --===============6643407158336719189== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/16/25 23:12, ben via cctalk wrote: > Did any classic computers have a subroutine call as (S++)=PC, PC=(EFA) > as well as the standard call (--S)=PC,PC=(EFA) ? > One  could have a virtual stack machine, using helper functions > without having to deal with return addresses on the stack. > Ben. > > The Microdata 32/S had a stack 5 deep.  There was a sort of "classic" register which was one of the general 16 bit registers and was the stack head.  There was a 4 deep hardware stack and hardware implemented pointer to allow the "top" of the 4 stack head registers and that stack top perform and operation, pop or push the result (manipulate the stack register) and leave the result in the stack head. Flags allowed for efficient popping of the "bottom" of the stack to roll to memory, so there wasn't just a 4(5) level stack. Firmware implemented an environment base register indexing option to allow a version of XPL for the machine called MPL to have local environment registers. There was other indexing and one of those registers addressed the entire stack space to implement external variables. There was very little assembly in the system software.  the Operating system for the original machine was called Genisys.  It was implemented from the boot in MPL. A later product based on the 32/S which they called 'Express' ran an OS called EMOS and an enhanced compiler (system implementation) called EPL. There was a CSPI implemented ANSI Cobol and Fortran native to the EMOS system.  The system was a contemporary to the 11/4x etc generations.  Stupid marketing and inept managment failed to take advantage over the DEC OS and language support and products, and eventually was abandoned and sold to Olivetti. The performance was a good bit better than  the DEC products, but were ineptly marketed, very few sold, and horrible manufacturing doomed it. I was one of the OS implementers. Went to Italy quite a bit supporting the product transition. --===============6643407158336719189==-- From elson@pico-systems.com Tue Feb 18 16:53:59 2025 From: Jon Elson To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Tue, 18 Feb 2025 10:53:52 -0600 Message-ID: <83070ede-7c75-02f9-eb3c-5e39c8f76104@pico-systems.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4544844770910032599==" --===============4544844770910032599== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/17/25 16:32, Martin Bishop via cctalk wrote: > Once upon a time - 35 - 45 years ago - I had the pleasure (sic) of working = with: > > https://archive.org/details/TNM_Versatec_printers_and_plotters_-_Versatec_a= _X_20180227_0009 for temperamental plots of telemetry traces > https://www.ebay.co.uk/itm/404623414575 manual for sale > 30 years ago or so, I had THREE Versatec 1200A printers at=20 home. I did have one running for a while, but if you didn't=20 use it frequently, the liquid toner would settle out and=20 there was not a great way to re-suspend the toner=20 particles.=C2=A0 I was glad to retire them for laser printers,=20 and get rid of the smelly toner and chalky paper. Jon --===============4544844770910032599==-- From commodorejohn@gmail.com Tue Feb 18 19:17:29 2025 From: John To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Tue, 18 Feb 2025 11:17:19 -0800 Message-ID: <20250218111719.00007a45@gmail.com> In-Reply-To: <173990161058.1298.6932551476415861952@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6223541432039159303==" --===============6223541432039159303== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 18 Feb 2025 12:00:10 -0600 cctalk-request(a)classiccmp.org wrote: > On the more than "one stack pointer" in the subject, it was a bit > arbitrary on the PDP-11 (or VAX) as the pre/post indexed indirect > addressing made every register a stack pointer. But this is where I > get hazy between DEC and 68K, and I did a lot more 68K. I'm pretty > sure you could do a move.l PC, An and you could certainly do an > indirect jmp (An), so effectively you could have multiple call stacks > if you wanted. Almost, kinda-sorta. The JSR and RTS instructions are hard-wired to use R6/SP, and there's nothing you can do about that. You *can* implement a return off another "stack" by doing e.g. MOV @(Rn)+, PC as long as you save the return address by hand, first - but this affects the flags, unlike JSR/RTS. --===============6223541432039159303==-- From gavin@learn.bio Wed Feb 19 03:45:16 2025 From: Gavin Scott To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Tue, 18 Feb 2025 21:45:00 -0600 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4311195065327615259==" --===============4311195065327615259== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 16, 2025 at 11:12=E2=80=AFPM ben via cctalk wrote: > > Did any classic computers have a subroutine call as (S++)=3DPC, PC=3D(EFA) > as well as the standard call (--S)=3DPC,PC=3D(EFA) ? The Classic stack-based HP 3000 has both PCAL (Procedure Call) which lays down a complete stack marker and creates a new local stack frame, and SCAL (Subroutine Call) which just takes an address (technically a Local PLABEL) off the stack and leaves the return address. There are corresponding EXIT and SXIT instructions. There's also a PARC (Paragraph Call) and ENDP for use by COBOL (because COBOL allows nutty things). --===============4311195065327615259==-- From cclist@sydex.com Wed Feb 19 16:49:19 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Wed, 19 Feb 2025 16:44:01 +0000 Message-ID: <2090b116-529b-4157-8bff-30e449da9fe0@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6548602151678957349==" --===============6548602151678957349== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Don't know if it was mentioned, but the NS16032 (later renamed to NS32016) employed two stack pointers (SP0 and SP1), but the implmentation was one for user stack and the other for interrupts. Which only made sense--you don't want your privileged-mode ISRs corrupting the user stack or vice-versa. --Chuck --===============6548602151678957349==-- From strick@yak.net Wed Feb 19 18:30:16 2025 From: StricK To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Wed, 19 Feb 2025 13:30:01 -0500 Message-ID: In-Reply-To: <2090b116-529b-4157-8bff-30e449da9fe0@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4127072055148651081==" --===============4127072055148651081== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit And the exception to every rule, the RCA 1802 COSMAC, doesn't really have stack instructions, doesn't have standard call & return instructions, but does let you pick which of 16 registers is your stack pointer (: -- strick --===============4127072055148651081==-- From paulkoning@comcast.net Wed Feb 19 19:59:35 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Wed, 19 Feb 2025 14:59:16 -0500 Message-ID: In-Reply-To: <2090b116-529b-4157-8bff-30e449da9fe0@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3454080610716468627==" --===============3454080610716468627== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 19, 2025, at 11:44=E2=80=AFAM, Chuck Guzis via cctalk wrote: >=20 > Don't know if it was mentioned, but the NS16032 (later renamed to > NS32016) employed two stack pointers (SP0 and SP1), but the > implmentation was one for user stack and the other for interrupts. > Which only made sense--you don't want your privileged-mode ISRs > corrupting the user stack or vice-versa. >=20 > --Chuck So do PDP-11 and VAX, but that isn't really what the original question was ab= out. For those, there is only one stack at a time, but a different internal = register in the CPU is referenced when the "stack pointer" is needed, dependi= ng on the current mode. An interesting variation of that is the Philips PR8000, which has 8 general r= egisters (well, one of the 8 is the PC, like on the PDP11) though no stack. = But actually it has 8 sets of 8 registers, one for each processor priority le= vel. So an interrupt automatically preserves the previous registers, and the= interrupt handler address is simply the value found in R0 (the PC) for that = level. paul --===============3454080610716468627==-- From bitwiz@12bitsbest.com Wed Feb 19 20:31:03 2025 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Wed, 19 Feb 2025 14:25:27 -0600 Message-ID: <6270c917-e8e2-4555-bc30-a6614cb94a6d@12bitsbest.com> In-Reply-To: <2090b116-529b-4157-8bff-30e449da9fe0@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9172787838618383928==" --===============9172787838618383928== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The 68000 CPUs also had two stacks, one system and one user. On 2/19/2025 10:44 AM, Chuck Guzis via cctalk wrote: > Don't know if it was mentioned, but the NS16032 (later renamed to > NS32016) employed two stack pointers (SP0 and SP1), but the > implmentation was one for user stack and the other for interrupts. > Which only made sense--you don't want your privileged-mode ISRs > corrupting the user stack or vice-versa. > > --Chuck --===============9172787838618383928==-- From glg@grebus.com Wed Feb 19 21:13:49 2025 From: Gary Grebus To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Wed, 19 Feb 2025 16:08:18 -0500 Message-ID: <9dfa2a2e-44ee-456e-a9c2-885fc300111e@grebus.com> In-Reply-To: <84d6f707-8109-4fd0-affd-8e4d809b622d@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2753737875332353232==" --===============2753737875332353232== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/17/25 12:30, Chuck Guzis via cctalk wrote: > One of most ingenious coding tricks to me was the problem of saving and > restoring all registers without resorting to an exchange jump. We used > that one as a test for applicants. Argh... I know I've seen this trick, but it's been too many years. How about a hint? Interestingly, Google turns up a reference to an article in Software: Practice and Experience on the subject but no free access. My employer at the time subscribed to that journal and it was one of the more useful ones. --===============2753737875332353232==-- From paulkoning@comcast.net Wed Feb 19 21:19:35 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Wed, 19 Feb 2025 16:19:19 -0500 Message-ID: In-Reply-To: <9dfa2a2e-44ee-456e-a9c2-885fc300111e@grebus.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5140155723100207777==" --===============5140155723100207777== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 19, 2025, at 4:08=E2=80=AFPM, Gary Grebus via cctalk wrote: >=20 > On 2/17/25 12:30, Chuck Guzis via cctalk wrote: >=20 >> One of most ingenious coding tricks to me was the problem of saving and >> restoring all registers without resorting to an exchange jump. We used >> that one as a test for applicants. >=20 > Argh... I know I've seen this trick, but it's been too many years. How abo= ut a hint? Apart from the obvious memory store operation, a subroutine call (RJ instruct= ion) does a memory write. paul --===============5140155723100207777==-- From cclist@sydex.com Wed Feb 19 22:38:35 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Wed, 19 Feb 2025 22:38:26 +0000 Message-ID: <2bcb0e99-b261-498a-a43d-4ec75233fa44@sydex.com> In-Reply-To: <9dfa2a2e-44ee-456e-a9c2-885fc300111e@grebus.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0103552447924482284==" --===============0103552447924482284== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/19/25 13:08, Gary Grebus via cctalk wrote: > On 2/17/25 12:30, Chuck Guzis via cctalk wrote: > >> One of most ingenious coding tricks to me was the problem of saving and >> restoring all registers without resorting to an exchange jump.  We used >> that one as a test for applicants. > > Argh... I know I've seen this trick, but it's been too many years.  How > about a hint? It uses the RJ instruction to record register content, bit-by-bit. Think about it--RJ is about the only instruction that can modify memory without fiddling with the A6 and A7 registers. --Chuck --===============0103552447924482284==-- From glg@grebus.com Wed Feb 19 23:45:42 2025 From: Gary Grebus To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Wed, 19 Feb 2025 18:39:08 -0500 Message-ID: <5c6a30de-4b72-4232-9c72-093d130b7bb7@grebus.com> In-Reply-To: <2bcb0e99-b261-498a-a43d-4ec75233fa44@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4207342268532386740==" --===============4207342268532386740== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/19/25 17:38, Chuck Guzis via cctalk wrote: >> >>> One of most ingenious coding tricks to me was the problem of saving and >>> restoring all registers without resorting to an exchange jump.  We used >>> that one as a test for applicants. >> >> Argh... I know I've seen this trick, but it's been too many years.  How >> about a hint? > > It uses the RJ instruction to record register content, bit-by-bit. > Think about it--RJ is about the only instruction that can modify memory > without fiddling with the A6 and A7 registers. > Of course... I vaguely recalled there was a bit-by-bit save, but didn't think of the RJ. Thanks. Gary --===============4207342268532386740==-- From chuck@sydex.com Thu Feb 20 06:28:08 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Wed, 19 Feb 2025 22:49:05 +0000 Message-ID: <49d3ae1d-9034-4fd1-b833-787b2ca05bac@sydex.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5020882551777994543==" --===============5020882551777994543== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On 2/19/25 11:59, Paul Koning wrote: > An interesting variation of that is the Philips PR8000, which has 8 general= registers (well, one of the 8 is the PC, like on the PDP11) though no stack.= But actually it has 8 sets of 8 registers, one for each processor priority = level. So an interrupt automatically preserves the previous registers, and t= he interrupt handler address is simply the value found in R0 (the PC) for tha= t level. Similarly, the NEC V25 (=C2=B5PD70320 and -322 have 8 banks of registers, keyed to the interrupt number. Each bank has a word for the saved PC and segment,so no PUSH needed. End of ISR is signified with a RETRB instruction. --Chuck --===============5020882551777994543==-- From cc@informatik.uni-stuttgart.de Thu Feb 20 10:05:43 2025 From: Christian Corti To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 11:05:31 +0100 Message-ID: <612eb87-1ed4-c171-6965-25c7b92582cd@informatik.uni-stuttgart.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7145618185874426952==" --===============7145618185874426952== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 19 Feb 2025, Paul Koning wrote: > An interesting variation of that is the Philips PR8000, which has 8 > general registers (well, one of the 8 is the PC, like on the PDP11) > though no stack. But actually it has 8 sets of 8 registers, one for > each processor priority level. So an interrupt automatically preserves > the previous registers, and the interrupt handler address is simply the > value found in R0 (the PC) for that level. That is not unusual at all. The IBM PALM processor does this for example, only that is has four sets of 16 registers. An interrupt just "shifts" the register base address to $20 * interrupt level. There is no instruction overhead at all. A "return from interrupt" merely clears the interrupt request line for that level and the processor pops to the next-lower active level, level 0 being the default. Same with the MINCAL 523. The basic machine has eight run levels, expandable to 64 levels. The default and lowest level is 0. You can change the level either by an interrupt to that level (if not masked and no other higher priority level is active) or by a processor instruction (making kinds of subroutine calls effectively overhead-less; no need to save the return address). The registers (also in memory space) are offset by 8, so level 0 has its registers at addresses 0..7, level 1 at 8..15 and so on. But, back to the topic, none of these machines have a hardware stack, although on the MINCAL, you can write additional microcode and create new instructions for what you like. Christian --===============7145618185874426952==-- From paul.kimpel@digm.com Thu Feb 20 18:52:46 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 18:52:40 +0000 Message-ID: <174007756060.1304.8581290801887943633@classiccmp.org> In-Reply-To: <2090b116-529b-4157-8bff-30e449da9fe0@sydex.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8790965563666319385==" --===============8790965563666319385== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable What is the problem with ISRs running in a user stack? The ISR runs, exits, t= he stack is cut back, and net effect on the user's stack is zero. The Burroughs B6000/7000 (later Unisys A Series and now ClearPath MCP) system= s did that, and it works fine. An interrupt acts like a hardware-induced proc= edure call. The user's state is pushed onto the stack, a new stack frame is s= tarted, and the interrupt routine runs in that, calling other OS procedures a= s necessary to do its job. If execution of the user task needs to be suspende= d, say to wait for an I/O, the OS moves the processor to another stack (there= 's a privileged instruction to do this). Once control returns to the original= stack, the OS procedures eventually exit back into the interrupt routine, wh= ich exits back into the user's stack frame, with the hardware restoring the p= rior stack frame's state at each step. There are perhaps two significant differences with this architecture, though,= that help to make this work. First, there are no user-accessible registers. = All registers are dedicated to specific purposes, which is what allows the ha= rdware to save and restore state automatically. Second, the stack on these ma= chines is not part of the user's address space, it IS the user's address spac= e. All push-down expression evaluation and call history is in the stack and i= s managed automatically by the hardware. All addressing is relative to the st= ack. Scalars are typically allocated in the stack. Arrays and other larger st= ructures are allocated in separate segments elsewhere in memory and accessed = through descriptor words in the stack. Procedure parameters are contained in = the callee's stack frame and effectively become local variables for that envi= ronment. The instructions do not have memory addresses, not even virtual addr= esses. All addressing is in terms of offsets from the base of a stack frame o= r from the base memory address in a descriptor word. So the stack is not an afterthought made feasible by auto-incrementing a regi= ster. It's a central tenet of the architecture. --===============8790965563666319385==-- From paulkoning@comcast.net Thu Feb 20 18:59:51 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 13:59:32 -0500 Message-ID: <4E6263A1-EBCC-4F4C-A00B-DFF241F926B8@comcast.net> In-Reply-To: <174007756060.1304.8581290801887943633@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8646247779457461701==" --===============8646247779457461701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 20, 2025, at 1:52=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >=20 > What is the problem with ISRs running in a user stack? The ISR runs, exits,= the stack is cut back, and net effect on the user's stack is zero. A stack access fault in user mode kills the process, in kernel mode (certainl= y in an ISR) it kills the whole system. You can't leave the integrity of the= OS at the mercy of the application having a valid stack. paul --===============8646247779457461701==-- From kiwi_jonathan@yahoo.com Thu Feb 20 19:32:24 2025 From: Jonathan Stone To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 19:32:17 +0000 Message-ID: <431160183.2612584.1740079937315@mail.yahoo.com> In-Reply-To: <174007756060.1304.8581290801887943633@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0878945125402170543==" --===============0878945125402170543== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 On Thursday, February 20, 2025 at 10:52:49 AM PST, paul.kimpel--- via cctalk = wrote: > What is the problem with ISRs running in a user stack? The ISR runs, exits,= the stack is cut back, > and net effect on the user's stack is zero. In general, since the user can write their own address space, a concurrent th= read can attack return-addresses on the user-address-space stack, thus causin= g the privileged interrupt handler to exit arbitrary code. =20 --===============0878945125402170543==-- From aperry@snowmoose.com Thu Feb 20 21:16:52 2025 From: Alan Perry To: cctalk@classiccmp.org Subject: [cctalk] Wikipedia (Was: Elliott Algol) Date: Thu, 20 Feb 2025 13:16:46 -0800 Message-ID: <05b11e45-a3ca-43bd-acbc-393ed84b3e75@snowmoose.com> In-Reply-To: =?utf-8?q?=3CCYXPR84MB3515CB0DD08BAD3821953733AEFB2=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2863659861172011806==" --===============2863659861172011806== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable In these cases, did someone roll back your changes? Was discussion added=20 to the Talk tab? I do enough Wikipedia edits that I get to vote on board membership. Or=20 used to. I have only done a few edits in recent years. The trickiest=20 edit has been the page for a woman who was a child actor in the 70s but=20 is now a doctor. The info in her page was wrong (and unattributed) and=20 she hasn't done any interviews in 20 years or described in any media=20 coverage what she has done since leaving the entertainment business. I=20 got her e-mail address and exchanged messages with her. It was=20 completely surreal. We discussed what she wants the general public to=20 know about her now. I asked if she was sure on a few points, e.g., when=20 I thought it might be too specific on where she is now. What is on the=20 page about her is what she felt comfortable with (as of 2019-2020). To=20 get around the "no original research" thing, I added a Talk tab section=20 explaining all of the above and offered to make the email exchanges=20 available (with her contact info redacted). That was 5-6 years ago and=20 no one has edited the page since. If someone has something they think should be in a Wikipedia page and=20 had it removed, I can help get it added to a Talk tab entry at a minimum. On 2/17/25 8:26 AM, David Wise via cctalk wrote: > In my case, the self-appointed gatekeeper rejected material from the AES Di= sk Recording Anthology. > > ________________________________ > From: Ken Seefried via cctalk > Sent: Sunday, February 16, 2025 12:55 PM > To: General Discussion: On-Topic and Off-Topic Posts > Cc: Ken Seefried > Subject: [cctalk] Re: Elliott Algol > > On Sun, Feb 16, 2025 at 1:53=E2=80=AFPM Cameron Kaiser via cctalk < > cctalk(a)classiccmp.org> wrote: > >> I admit to a bit of pique here: I don't even bother updating Wikipedia >> articles >> anymore because they'll always get reverted by someone with less of a life >> than >> me for any number of specious reasons. >> >> > This is an almost perfect description of my experience of Wikipedia. --===============2863659861172011806==-- From bitwiz@12bitsbest.com Thu Feb 20 22:04:31 2025 From: Mike Katz To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 16:04:22 -0600 Message-ID: <70abcddc-cd42-4bc0-a26a-5f8b7c2dcd53@12bitsbest.com> In-Reply-To: <612eb87-1ed4-c171-6965-25c7b92582cd@informatik.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4852932292805067293==" --===============4852932292805067293== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit The advantage of multiple stacks is that the system stack runs ring 0 protected tasks (main operating system tasks).  The user stack runs the user(s) tasks. On systems with some kind of memory protection this keeps any non system task from accessing any other non-system tasks memory and possibly keeps any individual system task from accessing any other system (or non-system) tasks memory.  On these systems, usually an MMU is involved and an interrupt or trap instruction will cause the MMU to switch its memory map to the system stack.  Usually all interrupts go through the OS even if the eventually interrupts handler code is in user memory. On systems without any kind of protected memory it keeps the user level tasks from accessing system task memory.  On these systems, once the OS enters "protected mode" only an interrupt (or trapped instruction) can cause a switch to the system stack. These statements are very high level and do not discuss the complexity of operating systems that use system memory and user memory. --===============4852932292805067293==-- From paul.kimpel@digm.com Thu Feb 20 22:42:31 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 22:42:27 +0000 Message-ID: <174009134790.1304.13867497125229165467@classiccmp.org> In-Reply-To: <4E6263A1-EBCC-4F4C-A00B-DFF241F926B8@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4175917818605399352==" --===============4175917818605399352== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Ah. In the Burroughs/Unisys architecture I was describing, there's no such th= ing as a running application not having a valid stack. Well, gross hardware o= r OS errors might result in that, but not user actions. A stack is the basis = for all addressing that an application task does, so if there's no stack, the= re's no running application. Also, a user task cannot address above current t= op-of-stack or below bottom-of-stack -- there are bounds registers that enfor= ce that. A user task also cannot mess with the stack linkage words that store= state, the return location, and the link to the prior stack frame, since tho= se words are managed by the hardware and protected as non-writable with memor= y tags. --===============4175917818605399352==-- From paul.kimpel@digm.com Thu Feb 20 23:04:06 2025 From: paul.kimpel@digm.com To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 23:04:01 +0000 Message-ID: <174009264169.1304.14209696675607775155@classiccmp.org> In-Reply-To: <431160183.2612584.1740079937315@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8998568281919604881==" --===============8998568281919604881== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As I mentioned in my last reply to Paul Koning, that can't occur in the Burro= ughs/Unisys stack architecture I was discussing earlier. Application code can= only access what it has created by pushing words onto the stack, and then on= ly access those stack frames that are in the lexicographical scope of the cur= rently-executing procedure. It can't access memory outside of that current sc= ope, except through references and descriptor words, which are protected by m= emory tags and managed only by the combination of the hardware and OS. Those systems do not have threads in the same way that most other systems do.= We call them sub-tasks or dependent asynchronous tasks. They each have their= own stack, which is linked back to the specific stack frame that initiated t= hem (the so-called "critical block"). Addressing within the sub-task is subje= ct to the same scope rules as the parent task, although that scope can extend= across stacks into the parent's stack. If the parent task exits a critical b= lock for which there are active sub-tasks, the parent and all of its children= (and their children -- the whole tree of sub-tasks) is terminated by the OS = because the dependency chains have been broken. Applications are just not all= owed to mess with the structure of their stacks. --===============8998568281919604881==-- From milovelimirovic@gmail.com Thu Feb 20 23:13:37 2025 From: Milo =?utf-8?q?Velimirovi=C4=87?= To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 17:13:20 -0600 Message-ID: <8EA8BFAE-1E51-40E7-B211-94DB44BBDBE2@gmail.com> In-Reply-To: <174009264169.1304.14209696675607775155@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6251048597897227068==" --===============6251048597897227068== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable For those who want more backgound on the architecures that Paul is describing= , I=E2=80=99d recommend reading Henry M. Levy=E2=80=99s _Capability-Based Com= puter Systems_. The Burroughs B5000 shows up in in Ch.2 on early descriptor b= ased architectures. https://homes.cs.washington.edu/~levy/capabook/ =E2=80=94Milo > On Feb 20, 2025, at 5:04=E2=80=AFPM, paul.kimpel--- via cctalk wrote: >=20 > As I mentioned in my last reply to Paul Koning, that can't occur in the Bur= roughs/Unisys stack architecture I was discussing earlier. Application code c= an only access what it has created by pushing words onto the stack, and then = only access those stack frames that are in the lexicographical scope of the c= urrently-executing procedure. It can't access memory outside of that current = scope, except through references and descriptor words, which are protected by= memory tags and managed only by the combination of the hardware and OS. >=20 > Those systems do not have threads in the same way that most other systems d= o. We call them sub-tasks or dependent asynchronous tasks. They each have the= ir own stack, which is linked back to the specific stack frame that initiated= them (the so-called "critical block"). Addressing within the sub-task is sub= ject to the same scope rules as the parent task, although that scope can exte= nd across stacks into the parent's stack. If the parent task exits a critical= block for which there are active sub-tasks, the parent and all of its childr= en (and their children -- the whole tree of sub-tasks) is terminated by the O= S because the dependency chains have been broken. Applications are just not a= llowed to mess with the structure of their stacks. --===============6251048597897227068==-- From paulkoning@comcast.net Fri Feb 21 01:34:55 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Thu, 20 Feb 2025 20:34:36 -0500 Message-ID: <6D83ED8E-F572-4402-8885-F0AF983809A9@comcast.net> In-Reply-To: <70abcddc-cd42-4bc0-a26a-5f8b7c2dcd53@12bitsbest.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6169664326672920164==" --===============6169664326672920164== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 20, 2025, at 5:04=E2=80=AFPM, Mike Katz via cctalk wrote: >=20 > The advantage of multiple stacks is that the system stack runs ring 0 prote= cted tasks (main operating system tasks). The user stack runs the user(s) ta= sks. >=20 > On systems with some kind of memory protection this keeps any non system ta= sk from accessing any other non-system tasks memory and possibly keeps any in= dividual system task from accessing any other system (or non-system) tasks me= mory. On these systems, usually an MMU is involved and an interrupt or trap = instruction will cause the MMU to switch its memory map to the system stack. = Usually all interrupts go through the OS even if the eventually interrupts h= andler code is in user memory. That reminds me that the PDP-11 has the ability to send interrupts to modes o= ther than kernel mode, because the new processor status (which includes the m= ode) is part of the interrupt vector. I doubt that has ever been done, thoug= h. One complication is that an interrupt into user mode that interrupts kern= el mode code would be a dead end, because the RTI instruction can't restore t= he state then: in user mode it can't restore a PSW value that says kernel mod= e. So a user mode vector would work only if the kernel is not interruptible = at all. paul --===============6169664326672920164==-- From mumpsdev@icloud.com Fri Feb 21 03:07:47 2025 From: Tommy Chang To: cctalk@classiccmp.org Subject: [cctalk] IBM 4506 (old message) Date: Thu, 20 Feb 2025 18:59:27 -0800 Message-ID: <48BC38F0-57AD-4B15-B08F-94EF05506383@icloud.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9216361229855638798==" --===============9216361229855638798== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I saw an email posted to the predecessor mail list asking if anyone had a pic= ture of an IBM 4506 terminal. I was looking through the September 1973 issue= Modern Data and saw an article on page 70 about the New York Times=E2=80=99s= indexing efforts. It said that they were using IBM 4506 terminals and it has= a picture of a large workroom (identified as =E2=80=9CThe Times index room= =E2=80=9D) with a bunch of terminals which I assume must be 4506=E2=80=99s (a= lthough the caption does not explicitly state that). The magazine is availab= le on BitSavers. Look for the issue with file name Modern_Data_1973_07.pdf.=20 Tommy Chang --===============9216361229855638798==-- From g4ajq1@gmail.com Fri Feb 21 04:07:09 2025 From: Nigel Johnson Ham To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Thu, 20 Feb 2025 23:06:50 -0500 Message-ID: <40e5322b-7432-488d-8e5d-8a50c18327b5@gmail.com> In-Reply-To: <05b11e45-a3ca-43bd-acbc-393ed84b3e75@snowmoose.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8442244744964956958==" --===============8442244744964956958== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-20 16:16, Alan Perry via cctalk wrote: > > In these cases, did someone roll back your changes? Was discussion > added to the Talk tab? > > I do enough Wikipedia edits that I get to vote on board membership. Or > used to. I have only done a few edits in recent years. The trickiest > edit has been the page for a woman who was a child actor in the 70s > but is now a doctor. The info in her page was wrong (and unattributed) > and she hasn't done any interviews in 20 years or described in any > media coverage what she has done since leaving the entertainment > business. I got her e-mail address and exchanged messages with her. It > was completely surreal. We discussed what she wants the general public > to know about her now. I asked if she was sure on a few points, e.g., > when I thought it might be too specific on where she is now. What is > on the page about her is what she felt comfortable with (as of > 2019-2020). To get around the "no original research" thing, I added a > Talk tab section explaining all of the above and offered to make the > email exchanges available (with her contact info redacted). That was > 5-6 years ago and no one has edited the page since. > > If someone has something they think should be in a Wikipedia page and > had it removed, I can help get it added to a Talk tab entry at a minimum. > > On 2/17/25 8:26 AM, David Wise via cctalk wrote: >> In my case, the self-appointed gatekeeper rejected material from the >> AES Disk Recording Anthology. >> >> ________________________________ >> From: Ken Seefried via cctalk >> Sent: Sunday, February 16, 2025 12:55 PM >> To: General Discussion: On-Topic and Off-Topic Posts >> >> Cc: Ken Seefried >> Subject: [cctalk] Re: Elliott Algol >> >> On Sun, Feb 16, 2025 at 1:53 PM Cameron Kaiser via cctalk < >> cctalk(a)classiccmp.org> wrote: >> >>> I admit to a bit of pique here: I don't even bother updating Wikipedia >>> articles >>> anymore because they'll always get reverted by someone with less of >>> a life >>> than >>> me for any number of specious reasons. >>> >>> >> This is an almost perfect description of my experience of Wikipedia. My only experience in editing was frustrating and a complete waste of time: Somebody posted that there is no legal definition of a pint in Canada, and the fact that their moniker was "National Pist" may give you an idea of their bona fides.  So I got in touch with Measurements Canada, an agency of Innovation, Science and Economic Development Canada (previously Industry Canada).   An inspector replied that a pint is one eighth of a gallon, and a gallon if defined by metric standards as 45609 ten-millionths of a cubic metre.  Doing the math, you can see that this works out to 568.26 cc. So I posted this with reference to the specific regulation that the inspector had quoted to me. One week later, it had been changed back to 'There is no legal definition of a pint in Canada'.  I tried to change it back to the correct legal definition above, but I was locked out.  Naturally the contributor was 'National Pist' again! Then they asked me for money!  I got a [polite rpely to my outraged comment, but still could not log in! In my last ten years as a college professor, anybody quoting wikipedia, despite having been warned,got a healthy dose of red ink from my pen! -- Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU Amateur Radio, the origin of the open-source concept! Skype: TILBURY2591 --===============8442244744964956958==-- From bobh@tds.net Fri Feb 21 06:38:19 2025 From: bobh@tds.net To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 00:17:53 -0500 Message-ID: <70CE855F-45E9-46FF-A200-36EF4FE54CF6@tds.net> In-Reply-To: <40e5322b-7432-488d-8e5d-8a50c18327b5@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1105752931817643282==" --===============1105752931817643282== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I tried to delete an =E2=80=9Cs=E2=80=9D from the word states in an incorrect= quotation. Changed it twice. It was changed back. Changed the whole meaning = of the quote. Sent from my iPhone Robert Harrison bobh(a)tds.net > On Feb 20, 2025, at 11:07=E2=80=AFPM, Nigel Johnson Ham via cctalk wrote: >=20 > =EF=BB=BFOn 2025-02-20 16:16, Alan Perry via cctalk wrote: >>=20 >> In these cases, did someone roll back your changes? Was discussion added t= o the Talk tab? >>=20 >> I do enough Wikipedia edits that I get to vote on board membership. Or use= d to. I have only done a few edits in recent years. The trickiest edit has be= en the page for a woman who was a child actor in the 70s but is now a doctor.= The info in her page was wrong (and unattributed) and she hasn't done any in= terviews in 20 years or described in any media coverage what she has done sin= ce leaving the entertainment business. I got her e-mail address and exchanged= messages with her. It was completely surreal. We discussed what she wants th= e general public to know about her now. I asked if she was sure on a few poin= ts, e.g., when I thought it might be too specific on where she is now. What i= s on the page about her is what she felt comfortable with (as of 2019-2020). = To get around the "no original research" thing, I added a Talk tab section ex= plaining all of the above and offered to make the email exchanges available (= with her contact info redacted). That was 5-6 years ago and no one has edited= the page since. >>=20 >> If someone has something they think should be in a Wikipedia page and had = it removed, I can help get it added to a Talk tab entry at a minimum. >>=20 >>> On 2/17/25 8:26 AM, David Wise via cctalk wrote: >>> In my case, the self-appointed gatekeeper rejected material from the AES = Disk Recording Anthology. >>>=20 >>> ________________________________ >>> From: Ken Seefried via cctalk >>> Sent: Sunday, February 16, 2025 12:55 PM >>> To: General Discussion: On-Topic and Off-Topic Posts >>> Cc: Ken Seefried >>> Subject: [cctalk] Re: Elliott Algol >>>=20 >>> On Sun, Feb 16, 2025 at 1:53=E2=80=AFPM Cameron Kaiser via cctalk < >>> cctalk(a)classiccmp.org> wrote: >>>=20 >>>> I admit to a bit of pique here: I don't even bother updating Wikipedia >>>> articles >>>> anymore because they'll always get reverted by someone with less of a li= fe >>>> than >>>> me for any number of specious reasons. >>>>=20 >>>>=20 >>> This is an almost perfect description of my experience of Wikipedia. >=20 > My only experience in editing was frustrating and a complete waste of time:= Somebody posted that there is no legal definition of a pint in Canada, and t= he fact that their moniker was "National Pist" may give you an idea of their = bona fides. So I got in touch with Measurements Canada, an agency of Innovat= ion, Science and Economic Development Canada (previously Industry Canada). = An inspector replied that a pint is one eighth of a gallon, and a gallon if d= efined by metric standards as 45609 ten-millionths of a cubic metre. Doing t= he math, you can see that this works out to 568.26 cc. So I posted this with = reference to the specific regulation that the inspector had quoted to me. >=20 > One week later, it had been changed back to 'There is no legal definition o= f a pint in Canada'. I tried to change it back to the correct legal definiti= on above, but I was locked out. Naturally the contributor was 'National Pist= ' again! >=20 > Then they asked me for money! I got a [polite rpely to my outraged comment= , but still could not log in! >=20 > In my last ten years as a college professor, anybody quoting wikipedia, des= pite having been warned,got a healthy dose of red ink from my pen! >=20 > -- > Nigel Johnson, MSc., MIEEE, MCSE VE3ID/G4AJQ/VA3MCU > Amateur Radio, the origin of the open-source concept! > Skype: TILBURY2591 >=20 --===============1105752931817643282==-- From jwsmail@jwsss.com Fri Feb 21 08:01:19 2025 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 02:01:12 -0600 Message-ID: <391d47de-3a05-4dac-a876-7c18d23c4c1f@jwsss.com> In-Reply-To: <70CE855F-45E9-46FF-A200-36EF4FE54CF6@tds.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5579046793224592775==" --===============5579046793224592775== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I got challenged by an idiot editor for my three letter login who put=20 some sort of hold on it. After a plea on the discussion for my ID a guy came in with privileges=20 near as I can tell 4 levels higher and asked why that had any justification. Near as I can tell 24 hours later the ID had no edit privileges and in a=20 week gone. Something like this should get a complete ban, but will take a bit of=20 nagging.=C2=A0 I'd definitely pursue it. If I tried to help gang up on the change with my=C2=A0 history with 3=20 letters, I might invite unwarranted attention. Asking for $$ and being a general nitwit (polite for crook) shouldn't be=20 allowed to pass. thanks Jim On 2/20/25 23:17, bobh--- via cctalk wrote: > Then they asked me for money! I got a [polite rpely to my outraged comment= , but still could not log in! --===============5579046793224592775==-- From d44617665@hotmail.com Fri Feb 21 17:17:20 2025 From: David Wise To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 17:17:12 +0000 Message-ID: In-Reply-To: <05b11e45-a3ca-43bd-acbc-393ed84b3e75@snowmoose.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6928261591266213025==" --===============6928261591266213025== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable It was many years ago so my memory is spotty. I think that yes they rolled b= ack my edits and "explained" on the Talk page. Their explanation sounded spe= cious to me. If you want to look, it was about the RIAA playback and recordi= ng curves. I asserted that the Y axis was velocity, not amplitude, backing i= t up with quotes from the DRA and the service manual for a cutting lathe, and= they flatly denied it. When I pushed back they called it original research.= When I pointed out that the info was published, they said it was "too niche= ". I concluded that they regarded the page as their empire, and I haven't l= ooked since. Gotta pick your battles or you wind up in an xkcd cartoon. ________________________________ From: Alan Perry via cctalk Sent: Thursday, February 20, 2025 1:16 PM To: cctalk(a)classiccmp.org Cc: Alan Perry Subject: [cctalk] Wikipedia (Was: Elliott Algol) In these cases, did someone roll back your changes? Was discussion added to the Talk tab? I do enough Wikipedia edits that I get to vote on board membership. Or used to. I have only done a few edits in recent years. The trickiest edit has been the page for a woman who was a child actor in the 70s but is now a doctor. The info in her page was wrong (and unattributed) and she hasn't done any interviews in 20 years or described in any media coverage what she has done since leaving the entertainment business. I got her e-mail address and exchanged messages with her. It was completely surreal. We discussed what she wants the general public to know about her now. I asked if she was sure on a few points, e.g., when I thought it might be too specific on where she is now. What is on the page about her is what she felt comfortable with (as of 2019-2020). To get around the "no original research" thing, I added a Talk tab section explaining all of the above and offered to make the email exchanges available (with her contact info redacted). That was 5-6 years ago and no one has edited the page since. If someone has something they think should be in a Wikipedia page and had it removed, I can help get it added to a Talk tab entry at a minimum. On 2/17/25 8:26 AM, David Wise via cctalk wrote: > In my case, the self-appointed gatekeeper rejected material from the AES Di= sk Recording Anthology. > > ________________________________ > From: Ken Seefried via cctalk > Sent: Sunday, February 16, 2025 12:55 PM > To: General Discussion: On-Topic and Off-Topic Posts > Cc: Ken Seefried > Subject: [cctalk] Re: Elliott Algol > > On Sun, Feb 16, 2025 at 1:53=E2=80=AFPM Cameron Kaiser via cctalk < > cctalk(a)classiccmp.org> wrote: > >> I admit to a bit of pique here: I don't even bother updating Wikipedia >> articles >> anymore because they'll always get reverted by someone with less of a life >> than >> me for any number of specious reasons. >> >> > This is an almost perfect description of my experience of Wikipedia. --===============6928261591266213025==-- From commodorejohn@gmail.com Fri Feb 21 18:55:47 2025 From: John To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Fri, 21 Feb 2025 10:55:37 -0800 Message-ID: <20250221105537.00003b32@gmail.com> In-Reply-To: <174016080779.1298.2421637268840313705@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3727412885445004333==" --===============3727412885445004333== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 21 Feb 2025 12:00:07 -0600 Paul Koning wrote: > > What is the problem with ISRs running in a user stack? The ISR > > runs, exits, the stack is cut back, and net effect on the user's > > stack is zero. > > A stack access fault in user mode kills the process, in kernel mode > (certainly in an ISR) it kills the whole system. You can't leave the > integrity of the OS at the mercy of the application having a valid > stack. Additionally, the ISR could leave potentially sensitive information in user memory, depending on exactly how the stack and memory protection are implemented. Consider an architecture where the stack pointer is a normal address register (as on the -11, the 68k, etc.) and protection is on a per-page basis with no bounds checking (i.e. there's no special address space for the stack, just a particular chunk mapped into normal user memory.) It'd be trivial for a user program to sit and "scrape" the stack for stray bits left by passing ISRs - say, waiting to see if the UART service routine happens to jot down something that looks like an admin password coming off one of the terminals. --===============3727412885445004333==-- From aperry@snowmoose.com Fri Feb 21 19:02:50 2025 From: Alan Perry To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 11:02:15 -0800 Message-ID: In-Reply-To: =?utf-8?q?=3CCYXPR84MB35151D721918585B458DD759AEC72=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4506373225966163977==" --===============4506373225966163977== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hmmm. This may be a minefield that I don=E2=80=99t want to step in. I used to= work with AES folks and there are some strong opinions presented as facts in= that area ;) > On Feb 21, 2025, at 09:17, David Wise via cctalk = wrote: >=20 > =EF=BB=BFIt was many years ago so my memory is spotty. I think that yes th= ey rolled back my edits and "explained" on the Talk page. Their explanation = sounded specious to me. If you want to look, it was about the RIAA playback = and recording curves. I asserted that the Y axis was velocity, not amplitude= , backing it up with quotes from the DRA and the service manual for a cutting= lathe, and they flatly denied it. When I pushed back they called it origina= l research. When I pointed out that the info was published, they said it was= "too niche". I concluded that they regarded the page as their empire, and = I haven't looked since. Gotta pick your battles or you wind up in an xkcd ca= rtoon. >=20 > ________________________________ > From: Alan Perry via cctalk > Sent: Thursday, February 20, 2025 1:16 PM > To: cctalk(a)classiccmp.org > Cc: Alan Perry > Subject: [cctalk] Wikipedia (Was: Elliott Algol) >=20 >=20 > In these cases, did someone roll back your changes? Was discussion added > to the Talk tab? >=20 > I do enough Wikipedia edits that I get to vote on board membership. Or > used to. I have only done a few edits in recent years. The trickiest > edit has been the page for a woman who was a child actor in the 70s but > is now a doctor. The info in her page was wrong (and unattributed) and > she hasn't done any interviews in 20 years or described in any media > coverage what she has done since leaving the entertainment business. I > got her e-mail address and exchanged messages with her. It was > completely surreal. We discussed what she wants the general public to > know about her now. I asked if she was sure on a few points, e.g., when > I thought it might be too specific on where she is now. What is on the > page about her is what she felt comfortable with (as of 2019-2020). To > get around the "no original research" thing, I added a Talk tab section > explaining all of the above and offered to make the email exchanges > available (with her contact info redacted). That was 5-6 years ago and > no one has edited the page since. >=20 > If someone has something they think should be in a Wikipedia page and > had it removed, I can help get it added to a Talk tab entry at a minimum. >=20 >> On 2/17/25 8:26 AM, David Wise via cctalk wrote: >> In my case, the self-appointed gatekeeper rejected material from the AES D= isk Recording Anthology. >>=20 >> ________________________________ >> From: Ken Seefried via cctalk >> Sent: Sunday, February 16, 2025 12:55 PM >> To: General Discussion: On-Topic and Off-Topic Posts >> Cc: Ken Seefried >> Subject: [cctalk] Re: Elliott Algol >>=20 >> On Sun, Feb 16, 2025 at 1:53=E2=80=AFPM Cameron Kaiser via cctalk < >> cctalk(a)classiccmp.org> wrote: >>=20 >>> I admit to a bit of pique here: I don't even bother updating Wikipedia >>> articles >>> anymore because they'll always get reverted by someone with less of a life >>> than >>> me for any number of specious reasons. >>>=20 >>>=20 >> This is an almost perfect description of my experience of Wikipedia. --===============4506373225966163977==-- From bfranchuk@jetnet.ab.ca Fri Feb 21 19:28:51 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Fri, 21 Feb 2025 12:28:43 -0700 Message-ID: <392ed06d-a3dd-43d9-bd40-948730f077f3@jetnet.ab.ca> In-Reply-To: <20250221105537.00003b32@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7661448827020992324==" --===============7661448827020992324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2025-02-21 11:55 a.m., John via cctalk wrote: > On Fri, 21 Feb 2025 12:00:07 -0600 > Paul Koning wrote: > >>> What is the problem with ISRs running in a user stack? The ISR >>> runs, exits, the stack is cut back, and net effect on the user's >>> stack is zero. >> >> A stack access fault in user mode kills the process, in kernel mode >> (certainly in an ISR) it kills the whole system. You can't leave the >> integrity of the OS at the mercy of the application having a valid >> stack. > > Additionally, the ISR could leave potentially sensitive information in > user memory, depending on exactly how the stack and memory protection > are implemented. Consider an architecture where the stack pointer is a > normal address register (as on the -11, the 68k, etc.) and protection > is on a per-page basis with no bounds checking (i.e. there's no special > address space for the stack, just a particular chunk mapped into normal > user memory.) It'd be trivial for a user program to sit and "scrape" > the stack for stray bits left by passing ISRs - say, waiting to see if > the UART service routine happens to jot down something that looks like > an admin password coming off one of the terminals. There is really no safe password system. Mind you it might take 30 years to break it and the OS is no longer around. --===============7661448827020992324==-- From jwsmail@jwsss.com Fri Feb 21 19:31:51 2025 From: jim stephens To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 13:31:43 -0600 Message-ID: In-Reply-To: =?utf-8?q?=3CCYXPR84MB35151D721918585B458DD759AEC72=40CYXPR84MB?= =?utf-8?q?3515=2ENAMPRD84=2EPROD=2EOUTLOOK=2ECOM=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1672885805139012881==" --===============1672885805139012881== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I entered a lot of history with the Pick system and Microdata directly=20 to Wikipedia of which quite a bit were events and situations I=20 personally was involved in. Having that thrown out really pissed me off, and I've not bothered=20 putting much in since.=C2=A0 Mostly typos and minor edits. But it's total BS to not allow authors or those who created the events=20 to enter the history directly. "I Henry VIII R murdered Anne Boleyn" seems if Henry was around and=20 wanted to explain it he should be able to author such and label it. Wouldn't happen with Wikipedia. thanks Jim On 2/21/25 11:17, David Wise via cctalk wrote: > It was many years ago so my memory is spotty. I think that yes they rolled= back my edits and "explained" on the Talk page. --===============1672885805139012881==-- From cclist@sydex.com Fri Feb 21 20:16:50 2025 From: Chuck Guzis To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 20:16:41 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2440151922150177468==" --===============2440151922150177468== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 2/21/25 11:31, jim stephens via cctalk wrote: > Wouldn't happen with Wikipedia. > thanks I gave up editing on WikiP years ago, although I still occasionally toss them some geetus because I think that the purpose is a noble one, no matter the flaws in execution. I do however, actively support archive.org, where there's no question of "he said" or faulty memory. The big problem for me is searching the thing, but I imagine that will eventually improve with technological advances. Right now, archive.org is our best general defense against having our history disappear down the memory hole. CHM does a good job as well, as things pertain to computing, interviewing seminal personalities before they shift off the mortal coil. --Chuck --===============2440151922150177468==-- From aperry@snowmoose.com Fri Feb 21 20:40:21 2025 From: Alan Perry To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 12:40:14 -0800 Message-ID: In-Reply-To: <40e5322b-7432-488d-8e5d-8a50c18327b5@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3680284657863915979==" --===============3680284657863915979== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2/20/25 8:06 PM, Nigel Johnson Ham via cctalk wrote: > On 2025-02-20 16:16, Alan Perry via cctalk wrote: >> >> In these cases, did someone roll back your changes? Was discussion >> added to the Talk tab? >> >> I do enough Wikipedia edits that I get to vote on board membership. >> Or used to. I have only done a few edits in recent years. The >> trickiest edit has been the page for a woman who was a child actor in >> the 70s but is now a doctor. The info in her page was wrong (and >> unattributed) and she hasn't done any interviews in 20 years or >> described in any media coverage what she has done since leaving the >> entertainment business. I got her e-mail address and exchanged >> messages with her. It was completely surreal. We discussed what she >> wants the general public to know about her now. I asked if she was >> sure on a few points, e.g., when I thought it might be too specific >> on where she is now. What is on the page about her is what she felt >> comfortable with (as of 2019-2020). To get around the "no original >> research" thing, I added a Talk tab section explaining all of the >> above and offered to make the email exchanges available (with her >> contact info redacted). That was 5-6 years ago and no one has edited >> the page since. >> >> If someone has something they think should be in a Wikipedia page and >> had it removed, I can help get it added to a Talk tab entry at a >> minimum. >> >> On 2/17/25 8:26 AM, David Wise via cctalk wrote: >>> In my case, the self-appointed gatekeeper rejected material from the >>> AES Disk Recording Anthology. >>> >>> ________________________________ >>> From: Ken Seefried via cctalk >>> Sent: Sunday, February 16, 2025 12:55 PM >>> To: General Discussion: On-Topic and Off-Topic Posts >>> >>> Cc: Ken Seefried >>> Subject: [cctalk] Re: Elliott Algol >>> >>> On Sun, Feb 16, 2025 at 1:53 PM Cameron Kaiser via cctalk < >>> cctalk(a)classiccmp.org> wrote: >>> >>>> I admit to a bit of pique here: I don't even bother updating Wikipedia >>>> articles >>>> anymore because they'll always get reverted by someone with less of >>>> a life >>>> than >>>> me for any number of specious reasons. >>>> >>>> >>> This is an almost perfect description of my experience of Wikipedia. > > My only experience in editing was frustrating and a complete waste of > time: Somebody posted that there is no legal definition of a pint in > Canada, and the fact that their moniker was "National Pist" may give > you an idea of their bona fides.  So I got in touch with Measurements > Canada, an agency of Innovation, Science and Economic Development > Canada (previously Industry Canada).   An inspector replied that a > pint is one eighth of a gallon, and a gallon if defined by metric > standards as 45609 ten-millionths of a cubic metre.  Doing the math, > you can see that this works out to 568.26 cc. So I posted this with > reference to the specific regulation that the inspector had quoted to me. > > One week later, it had been changed back to 'There is no legal > definition of a pint in Canada'.  I tried to change it back to the > correct legal definition above, but I was locked out.  Naturally the > contributor was 'National Pist' again! > > Then they asked me for money!  I got a [polite rpely to my outraged > comment, but still could not log in! > > In my last ten years as a college professor, anybody quoting > wikipedia, despite having been warned,got a healthy dose of red ink > from my pen! Did Measurements Canada indicate that it was a legal definition or a definition established by the agency. If the definition isn't in enacted legislation, Measurements Canada's statements may not be legal definitions. It depends on the authority granted to them under the legislation that created the agency. But asking for money suggests something sketchy is happening. I do a lot of general corrections in Wikipedia, usually when I am watching old movies, looking up stuff about it and noticing something wrong. But I reading up on the stuff that I used to work on at Burroughs/Unisys that is clearly wrong (for example, I was working on the product after the article says that work stopped on it) and haven't yet come up with an attributable way to correct the page other than to add something to the Talk tab. --===============3680284657863915979==-- From a.carlini@ntlworld.com Fri Feb 21 20:49:24 2025 From: Antonio Carlini To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Fri, 21 Feb 2025 20:49:15 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4128980104629743925==" --===============4128980104629743925== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 21/02/2025 19:31, jim stephens via cctalk wrote: > I entered a lot of history with the Pick system and Microdata directly > to Wikipedia of which quite a bit were events and situations I > personally was involved in. > > Having that thrown out really pissed me off, and I've not bothered > putting much in since.  Mostly typos and minor edits. > > But it's total BS to not allow authors or those who created the events > to enter the history directly. You should be able to fish out what you typed from the Wikipedia history (to save you recreating it again) and you could enter it on gunkies (https://gunkies.org/wiki/Main_Page), where it will be better appreciated. Antonio -- Antonio Carlini antonio(a)acarlini.com --===============4128980104629743925==-- From paulkoning@comcast.net Fri Feb 21 21:06:34 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Fri, 21 Feb 2025 16:06:19 -0500 Message-ID: In-Reply-To: <392ed06d-a3dd-43d9-bd40-948730f077f3@jetnet.ab.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2704997453750954821==" --===============2704997453750954821== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 21, 2025, at 2:28=E2=80=AFPM, ben via cctalk wrote: >=20 > On 2025-02-21 11:55 a.m., John via cctalk wrote: >> On Fri, 21 Feb 2025 12:00:07 -0600 >> Paul Koning wrote: >>>> What is the problem with ISRs running in a user stack? The ISR >>>> runs, exits, the stack is cut back, and net effect on the user's >>>> stack is zero. >>>=20 >>> A stack access fault in user mode kills the process, in kernel mode >>> (certainly in an ISR) it kills the whole system. You can't leave the >>> integrity of the OS at the mercy of the application having a valid >>> stack. >> Additionally, the ISR could leave potentially sensitive information in >> user memory, depending on exactly how the stack and memory protection >> are implemented. Consider an architecture where the stack pointer is a >> normal address register (as on the -11, the 68k, etc.) and protection >> is on a per-page basis with no bounds checking (i.e. there's no special >> address space for the stack, just a particular chunk mapped into normal >> user memory.) It'd be trivial for a user program to sit and "scrape" >> the stack for stray bits left by passing ISRs - say, waiting to see if >> the UART service routine happens to jot down something that looks like >> an admin password coming off one of the terminals. >=20 > There is really no safe password system. > Mind you it might take 30 years to break it > and the OS is no longer around. My favorite example of security holes in strange places is the paper describi= ng how to recover the RSA private key used by crypto inside of a smartphone, = by listening to the sounds made by the electronics while it's doing the compu= tation. Adi Shamir was a co-author as I recall -- he's the S in RSA and one = of the world's top cryptographers. paul --===============2704997453750954821==-- From wayne.sudol@hotmail.com Fri Feb 21 21:09:35 2025 From: Wayne S To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Fri, 21 Feb 2025 21:09:25 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0195124942478298105==" --===============0195124942478298105== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That=E2=80=99s a side channel attack. If there ever was one.=20 Was there ever a proof of concept made of that theory ? Sent from my iPhone > On Feb 21, 2025, at 13:06, Paul Koning via cctalk = wrote: >=20 > the --===============0195124942478298105==-- From paul@mcjones.org Fri Feb 21 21:16:35 2025 From: Paul McJones To: cctalk@classiccmp.org Subject: [cctalk] Re: Elliott Algol Date: Fri, 21 Feb 2025 13:16:27 -0800 Message-ID: In-Reply-To: <174007441009.1298.9084286677980040324@classiccmp.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0848156657856797176==" --===============0848156657856797176== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On19 Feb 2025 18:39:08 -0500, Chuck Guzis via cctalk wrote: >=20 >>>=20 >>>> One of most ingenious coding tricks to me was the problem of saving and >>>> restoring all registers without resorting to an exchange jump. We used >>>> that one as a test for applicants. >>>=20 >>> Argh... I know I've seen this trick, but it's been too many years. How >>> about a hint? >>=20 >> It uses the RJ instruction to record register content, bit-by-bit. >> Think about it--RJ is about the only instruction that can modify memory >> without fiddling with the A6 and A7 registers. >>=20 >=20 > Of course... I vaguely recalled there was a bit-by-bit save, but didn't=20 > think of the RJ. Thanks. A full example of this code is in the DEBUG package of CAL SNOBOL , starting at label SAVEREG: Original version: https://mcjones.org/CAL_SNOBOL/UArizona/SNOBOL.MAC.html Revised version: https://mcjones.org/CAL_SNOBOL/UTexas/DEBUG.html --===============0848156657856797176==-- From bfranchuk@jetnet.ab.ca Fri Feb 21 22:43:50 2025 From: ben To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Fri, 21 Feb 2025 15:43:41 -0700 Message-ID: <556981e5-033d-4a11-8a76-cd30d6b2b018@jetnet.ab.ca> In-Reply-To: =?utf-8?q?=3CCO1PR08MB7208CA0D216BBEECDB8BCF00E4C72=40CO1PR08MB?= =?utf-8?q?7208=2Enamprd08=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6650018745788032225==" --===============6650018745788032225== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On 2025-02-21 2:09 p.m., Wayne S via cctalk wrote: > That’s a side channel attack. > If there ever was one. > Was there ever a proof of concept made of that theory ? Only when the BLACK helicopters show up. --===============6650018745788032225==-- From paulkoning@comcast.net Sat Feb 22 18:19:03 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Classic computers with more than one stack pointer, but not FORTH machines. Date: Sat, 22 Feb 2025 13:18:42 -0500 Message-ID: In-Reply-To: =?utf-8?q?=3CCO1PR08MB7208CA0D216BBEECDB8BCF00E4C72=40CO1PR08MB?= =?utf-8?q?7208=2Enamprd08=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7510220544201060492==" --===============7510220544201060492== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > On Feb 21, 2025, at 4:09=E2=80=AFPM, Wayne S wr= ote: >=20 > That=E2=80=99s a side channel attack. > If there ever was one.=20 > Was there ever a proof of concept made of that theory ? Oh yes. The paper describes implementing and executing the attack; it isn't = a theoretical work. It also gives a demonstration of a change to the impleme= ntation to defeat the attack. https://eprint.iacr.org/2013/857 paul --===============7510220544201060492==-- From tom94022@comcast.net Sat Feb 22 19:16:29 2025 From: Tom Gardner To: cctalk@classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) Date: Sat, 22 Feb 2025 11:08:14 -0800 Message-ID: <006501db855d$20a1d0d0$61e57270$@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6543285975763118631==" --===============6543285975763118631== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Any "member" desiring to post original research that is not acceptable to Wik= ipedia might consider the IEEE Engineering and Technology History Wiki, https= ://ethw.org/Main_Page=20 It's not clear what they mean by a member but it looks like most anyone can j= oin and be a member. =20 In theory they will accept OR,=20 from: https://ethw.org/Create =20 =20 "The ETHW enables its members to record their involvement in technological in= novation. Through these articles and First-hand Histories, the ETHW invites a= nd encourages members to share their experiences in developing products and s= ervices -- from invention, R&D, design, testing, production and commercializa= tion -- with the world. Ideally these recollections will also include the bro= ader range of experiences that led to members' successes as professionals, in= cluding their inspirations, educations, and affiliations. Because of the wiki= functionality, the ETHW also enables individuals to contribute their experie= nces as contributors to a collective First-hand History of a group, such as a= n R&D lab or design team within a university or corporation." =20 Haven't tried it yet but once the OR is posted to the ETHW is it then an RS f= or Wikipedia? =20 FWIW I have 8,141 edits on Wikipedia since 2006 with only a very few reversio= ns the most painful having been with {{fact}} litterbugs and vandals. When = challenged I usually can find an RS that is accepted. =20 Tom =20 -----Original Message----- From: Chuck Guzis =20 Sent: Friday, February 21, 2025 12:17 PM To: cctalk(a)classiccmp.org Subject: [cctalk] Re: Wikipedia (Was: Elliott Algol) =20 On 2/21/25 11:31, jim stephens via cctalk wrote: =20 > Wouldn't happen with Wikipedia. > thanks =20 I gave up editing on WikiP years ago, although I still occasionally toss them= some geetus because I think that the purpose is a noble one, no matter the f= laws in execution. =20 I do however, actively support archive.org, where there's no question of "he said" or faulty memory. The big problem for me is searching the thing, but I imagine that will eventually improve with technological advances. =20 Right now, archive.org is our best general defense against having our history= disappear down the memory hole. CHM does a good job as well, as things pert= ain to computing, interviewing seminal personalities before they shift off th= e mortal coil. =20 --Chuck =20 --===============6543285975763118631==-- From van.snyder@sbcglobal.net Sun Feb 23 01:08:56 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Might be antique computer parts Date: Sat, 22 Feb 2025 17:08:44 -0800 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1302734200713031483==" --===============1302734200713031483== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have two SPST time delay 12-volt relays packaged like vacuum tubes with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five seconds). They're in their original boxes. I have no idea what devices used them. It seems a shame to throw them in a recycle bin. Does anybody want them? Van Snyder --===============1302734200713031483==-- From van.snyder@sbcglobal.net Sun Feb 23 01:57:52 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Anybody need a dot matrix impact printer? Date: Sat, 22 Feb 2025 17:57:45 -0800 Message-ID: <5dced2e49566abd8c44217b1464e7d2400848476.camel@sbcglobal.net> In-Reply-To: <5dced2e49566abd8c44217b1464e7d2400848476.camel.ref@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8905424140113312314==" --===============8905424140113312314== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Anybody need a dot matrix impact printer? Do you need to print multi- part forms with carbon paper or NCR paper? I have a Star Micronics SB-10 dot matrix impact printer. It has a parallel port interface. I have the cable, manual, and a spare ribbon. None of my computers have a parallel port so I haven't tried to use it. I put it on EBay, but mostly I don't want to throw it in the E-waste bin. It's yours for pickup or shipping, but I won't complain if you offer me something for it. 30lb. 20x20x10 inch box. --===============8905424140113312314==-- From robert.jarratt@ntlworld.com Sun Feb 23 11:56:08 2025 From: Rob Jarratt To: cctalk@classiccmp.org Subject: [cctalk] Rainbow 100A Video Fault (also posted on VCF) Date: Sun, 23 Feb 2025 11:43:18 +0000 Message-ID: <01c701db85e8$21d0cac0$65726040$@ntlworld.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7246345709904159129==" --===============7246345709904159129== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I have been trying to diagnose a video fault on my Rainbow 100A for some time now. The monitor shows an error message and some of the attributes displayed are wrong and displayed incorrectly on every line down the screen. However, the attributes being presented to the DC012 appear to be correct and the DC012 is good (I have replaced it with a spare and with a known good one, all have the same behaviour), and yet the display is wrong. I have posted this on VCF, but would like to reach a wider audience as I am really at a loss now as to what the problem could be. Picture of the problem here: https://forum.vcfed.org/index.php?threads/video-ram-fault-on-a-rainbow-100a. 1250713/post-1418966 Description of what I have found here: https://forum.vcfed.org/index.php?threads/video-ram-fault-on-a-rainbow-100a. 1250713/post-1433618 Thanks Rob --===============7246345709904159129==-- From paulkoning@comcast.net Sun Feb 23 18:10:11 2025 From: Paul Koning To: cctalk@classiccmp.org Subject: [cctalk] Re: Might be antique computer parts Date: Sun, 23 Feb 2025 13:09:53 -0500 Message-ID: <99099DBE-44E1-4466-8771-538BAF5EB5CB@comcast.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5685684098948874070==" --===============5685684098948874070== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A typical use for those would be either to delay applying plate voltage to a = high power amplifier tube until after the filament current has been on for a = bit, or to cut out a series resistor used to limit the inrush current on a ca= pacitor-input power supply. The delay (especially the 5 seconds) seems to fi= t the second application best. paul > On Feb 22, 2025, at 8:08=E2=80=AFPM, Van Snyder via cctalk wrote: >=20 >=20 > I have two SPST time delay 12-volt relays packaged like vacuum tubes > with octal bases, Amperite models 12N010 (ten seconds) and 12C5 (five > seconds). >=20 > They're in their original boxes. >=20 > I have no idea what devices used them. >=20 > It seems a shame to throw them in a recycle bin. >=20 > Does anybody want them? >=20 > Van Snyder >=20 >=20 --===============5685684098948874070==-- From van.snyder@sbcglobal.net Sun Feb 23 20:15:08 2025 From: Van Snyder To: cctalk@classiccmp.org Subject: [cctalk] Re: Might be antique computer parts Date: Sun, 23 Feb 2025 12:14:58 -0800 Message-ID: <5807b7e5af7fbe4da4b926c591ac24ea21e24797.camel@sbcglobal.net> In-Reply-To: <99099DBE-44E1-4466-8771-538BAF5EB5CB@comcast.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5877318435839629212==" --===============5877318435839629212== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sun, 2025-02-23 at 13:09 -0500, Paul Koning via cctalk wrote: > A typical use for those would be either to delay applying plate > voltage to a high power amplifier tube until after the filament > current has been on for a bit, or to cut out a series resistor used > to limit the inrush current on a capacitor-input power supply.  The > delay (especially the 5 seconds) seems to fit the second application > best. Do you want them? Send a PDF of a shipping label for a small postal- service flat-rate envelope. >         paul > > > On Feb 22, 2025, at 8:08 PM, Van Snyder via cctalk > > wrote: > > > > > > I have two SPST time delay 12-volt relays packaged like vacuum > > tubes > > with octal bases, Amperite models 12N010 (ten seconds) and 12C5 > > (five > > seconds). > > > > They're in their original boxes. > > > > I have no idea what devices used them. > > > > It seems a shame to throw them in a recycle bin. > > > > Does anybody want them? > > > > Van Snyder > > > > > --===============5877318435839629212==-- From jeffrey@vcfed.org Mon Feb 24 00:52:24 2025 From: Jeffrey Brace To: cctalk@classiccmp.org Subject: [cctalk] VCF =?utf-8?q?Montr=C3=A9al?= Survey Date: Sun, 23 Feb 2025 19:52:00 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1453092513690822062==" --===============1453092513690822062== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit This survey is in its final days. You are invited to add your anonymous input by clicking here https://bit.ly/vcfm2026pre-en Ce sondage entre dans ses derniers jours. Vous êtes invité à ajouter vos commentaires anonymes en cliquant ici https://bit.ly/vcfm2026pre-fr DATE: January 25 & 26, 2026. LOCATION: Montréal, QC, Canada Jeff Brace VCF National Board Member Chairman & Vice President --===============1453092513690822062==-- From jeffrey@vcfed.org Mon Feb 24 23:21:17 2025 From: Jeffrey Brace To: cctalk@classiccmp.org Subject: [cctalk] Re: VCF =?utf-8?q?Montr=C3=A9al?= Survey Date: Mon, 24 Feb 2025 18:20:53 -0500 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1391927857169739811==" --===============1391927857169739811== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit And please share this with any groups or people that you think would be interested. We are having a great response and want to get as much feedback as possible from everyone! On Sun, Feb 23, 2025 at 7:52 PM Jeffrey Brace wrote: > This survey is in its final days. You are invited to add your anonymous > input by clicking here https://bit.ly/vcfm2026pre-en > > Ce sondage entre dans ses derniers jours. Vous êtes invité à ajouter vos > commentaires anonymes en cliquant ici https://bit.ly/vcfm2026pre-fr > > DATE: January 25 & 26, 2026. > > LOCATION: Montréal, QC, Canada > Jeff Brace > VCF National Board Member Chairman & Vice President > > --===============1391927857169739811==-- From Bruce@Wild-Hare.com Wed Feb 26 21:53:35 2025 From: Bruce Ray To: cctalk@classiccmp.org Subject: [cctalk] Thousands of new Data General documents added to the on-line archives... Date: Wed, 26 Feb 2025 14:54:42 -0700 Message-ID: <2a95f17c-62de-4cd9-aff5-c65344c7dcf4@Wild-Hare.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3254759651129205060==" --===============3254759651129205060== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thousands of new documents have been added to the DG legacy preservation web site [www.NovasAreForever.org], including new sections for the Nova, SuperNova, Nova 2, Nova 3, microNova, MPT, Eclipse S/130, Eclipse S/140, Eclipse S/230, Eclipse C/330, Eclipse S/280, and Desktop Generation computers.(!) Separate areas also now exist for DG disks, tapes and other peripherals. New archives for 3rd-party, DG-compatible hardware vendors have been started with this release, including those for Keronix, DCC, Bytronix and ROLM. This update reflects Wild Hare's continuing dedication [obsession?] to preserve Data General's significant part of computer history, and to help museums, universities and "restorationists" preserve DG systems worldwide. Bruce Ray www.NovasAreForever.org -- Bruce Ray, President Wild Hare Computer Systems, Inc. Denver, Colorado USA bkr(a)WildHareComputers.com ...preserving the Data General legacy: www.NovasAreForever.org --===============3254759651129205060==-- From rtomek@ceti.pl Thu Feb 27 23:17:52 2025 From: Tomasz Rola To: cctalk@classiccmp.org Subject: [cctalk] FYI: The ongoing, 40 years long search for Aleph Null Date: Fri, 28 Feb 2025 00:08:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6228460812988057675==" --===============6228460812988057675== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Howdy, The subject of Aleph Null's real identity appeared on HN... :: Who was Aleph Null? Posted on 2 September 2013 by Brian Hayes http://bit-player.org/2013/who-was-aleph-null :: https://news.ycombinator.com/item?id=43195308 Intriguing. He must have been known by somebody, back in the day. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com ** --===============6228460812988057675==-- From dce@skynet.be Fri Feb 28 03:52:56 2025 From: Dominique Carlier To: cctalk@classiccmp.org Subject: [cctalk] Re: Thousands of new Data General documents added to the on-line archives... Date: Fri, 28 Feb 2025 04:52:41 +0100 Message-ID: <232aaf95-9ef7-42ee-a689-6ff09d82274f@skynet.be> In-Reply-To: <2a95f17c-62de-4cd9-aff5-c65344c7dcf4@Wild-Hare.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7524709524048801430==" --===============7524709524048801430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit So many thanks Bruce ! It's just wonderful ! Dominique On 26/02/2025 22:54, Bruce Ray via cctalk wrote: > Thousands of new documents have been added to the DG legacy preservation > web site [www.NovasAreForever.org], including new sections for the Nova, > SuperNova, Nova 2, Nova 3, microNova, MPT, Eclipse S/130, Eclipse S/140, > Eclipse S/230, Eclipse C/330, Eclipse S/280, and Desktop Generation > computers.(!)  Separate areas also now exist for DG disks, tapes and > other peripherals. > > New archives for 3rd-party, DG-compatible hardware vendors have been > started with this release, including those for Keronix, DCC, Bytronix > and ROLM. > > This update reflects Wild Hare's continuing dedication [obsession?] to > preserve Data General's significant part of computer history, and to > help museums, universities and "restorationists" preserve DG systems > worldwide. > > > Bruce Ray > www.NovasAreForever.org > > > -- > Bruce Ray, President > Wild Hare Computer Systems, Inc. > Denver, Colorado USA > bkr(a)WildHareComputers.com > > ...preserving the Data General legacy: www.NovasAreForever.org > --===============7524709524048801430==-- From lproven@gmail.com Fri Feb 28 14:43:39 2025 From: Liam Proven To: cctalk@classiccmp.org Subject: [cctalk] Re: Anybody need a dot matrix impact printer? Date: Fri, 28 Feb 2025 15:43:22 +0100 Message-ID: In-Reply-To: <5dced2e49566abd8c44217b1464e7d2400848476.camel@sbcglobal.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2899678185988992417==" --===============2899678185988992417== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 23 Feb 2025 at 02:57, Van Snyder via cctalk wrote: > > It's yours for pickup or shipping, but I won't complain if you > offer me something for it. May I mildly interject that you didn't note where you or it are? -- 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 --===============2899678185988992417==-- From wh.sudbrink@verizon.net Fri Feb 28 15:02:52 2025 From: William Sudbrink To: cctalk@classiccmp.org Subject: [cctalk] Re: FYI: The ongoing, 40 years long search for Aleph Null Date: Fri, 28 Feb 2025 10:01:59 -0500 Message-ID: <066901db89f1$b84317d0$28c94770$@verizon.net> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5311920981696018353==" --===============5311920981696018353== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit The problem is obvious, if you try to dereference "him", you'll crash. -----Original Message----- From: Tomasz Rola via cctalk [mailto:cctalk(a)classiccmp.org] Sent: Thursday, February 27, 2025 6:09 PM To: General Discussion: On-Topic and Off-Topic Posts Cc: Tomasz Rola Subject: [cctalk] FYI: The ongoing, 40 years long search for Aleph Null Howdy, The subject of Aleph Null's real identity appeared on HN... :: Who was Aleph Null? Posted on 2 September 2013 by Brian Hayes http://bit-player.org/2013/who-was-aleph-null :: https://news.ycombinator.com/item?id=43195308 Intriguing. He must have been known by somebody, back in the day. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_rola(a)bigfoot.com ** -- This email has been checked for viruses by Avast antivirus software. www.avast.com --===============5311920981696018353==--