From tuhs at tuhs.org Tue Sep 1 15:03:46 2026 From: tuhs at tuhs.org (Warner Losh via TUHS) Date: Mon, 31 Aug 2026 23:03:46 -0600 Subject: [TUHS] 32V-x86 Message-ID: Greetings, Going through the old archives, I found references to 32V being ported to x86 in 2003 by Pat Villani and Wesley Parish. The latest I can find is this: > Latest is 32v-031102-01.tar.gz. Available via anonymous ftp at sever.opensourcedepot.com. opensourcedepot.com is parked for sale at $800. There's a reference by Larry McVoy to 32vi.bkbits.net. But work seems to have trailed off in early 2004. So was this effort saved? This effort is unrelated to Robert Nordier's v7x86. When he released it, Pat popped up and reported on his efforts..., but I couldn't find anything else. Anybody save / have a copy? Warner From tuhs at tuhs.org Tue Sep 1 15:37:01 2026 From: tuhs at tuhs.org (Wesley Parish via TUHS) Date: Tue, 1 Sep 2026 17:37:01 +1200 Subject: [TUHS] 32V-x86 In-Reply-To: References: Message-ID: <6034fb7d-e72e-4c55-b0a7-304602224eec@gmail.com> Hi all The last traces of my part of it are on a hard drive that I haven't accessed since 2012. I remember compiling some of the user-level utilities, which proved that gcc could compile source as old as that. But I hadn't done much after that, and I don't think Pat Villani took it any further - he would've been the guy working on the x86-specific stuff. Wesley Parish On 01/09/2026 17:03, Warner Losh via TUHS wrote: > Greetings, > > Going through the old archives, I found references to 32V being ported to > x86 in 2003 by Pat Villani and Wesley Parish. > > The latest I can find is this: >> Latest is 32v-031102-01.tar.gz. Available via anonymous ftp at > sever.opensourcedepot.com. > > opensourcedepot.com is parked for sale at $800. > > There's a reference by Larry McVoy to 32vi.bkbits.net. > > But work seems to have trailed off in early 2004. > > So was this effort saved? > > This effort is unrelated to Robert Nordier's v7x86. When he released it, > Pat popped up and reported on his efforts..., but I couldn't find anything > else. > > Anybody save / have a copy? > > Warner From tuhs at tuhs.org Wed Sep 2 05:15:39 2026 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Tue, 1 Sep 2026 12:15:39 -0700 Subject: [TUHS] mag tapes Message-ID: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> during a belated round of cleanup around the house, i have come across 3 mag tapes: 1) 2400’ reel: cpio 5281x512 blocks, 800 BPI 2) 2400’ reel: cpio -oc 32b, 1600BPI 3) 600(or maybe 800)’ reel: unknown i would REALLY like to get the info of tape 1. all tapes were made around 1980, and have been stored in good residential temp/humidity. where might i be able to process these tapes? or pointers to other places i might ask? andrew hume From tuhs at tuhs.org Wed Sep 2 06:42:06 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 01 Sep 2026 20:42:06 +0000 Subject: [TUHS] mag tapes In-Reply-To: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: Obviously, getting it off the physical media is key. Once you have the raw records decoding the CPIO is pretty trivial. Hell, my Mac even has cpio on it (haven’t used that in years). Alas, I no gave up all my old collection of tape drives (9 track, QIC, DAT, Exabyte, etc….). The sad truth is that tape is not a long-lived storage format. The fact that this stuff is low density may help. I don’t know who does recovery. I did recover some old real-to-real audio tapes and the company had to “bake” them to make sure they’d unwind. ------ Original Message ------ >From "andrew--- via TUHS" To "The Eunuchs Hysterical Society" Date 9/1/2026 3:15:39 PM Subject [TUHS] mag tapes >during a belated round of cleanup around the house, i have come across 3 mag tapes: > >1) 2400’ reel: cpio 5281x512 blocks, 800 BPI >2) 2400’ reel: cpio -oc 32b, 1600BPI >3) 600(or maybe 800)’ reel: unknown > >i would REALLY like to get the info of tape 1. >all tapes were made around 1980, and have been stored in good residential temp/humidity. > >where might i be able to process these tapes? >or pointers to other places i might ask? > > andrew hume > From tuhs at tuhs.org Wed Sep 2 06:42:08 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 01 Sep 2026 20:42:08 +0000 Subject: [TUHS] mag tapes In-Reply-To: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: ------ Original Message ------ >From "andrew--- via TUHS" To "The Eunuchs Hysterical Society" Date 9/1/2026 3:15:39 PM Subject [TUHS] mag tapes >during a belated round of cleanup around the house, i have come across 3 mag tapes: > >1) 2400’ reel: cpio 5281x512 blocks, 800 BPI >2) 2400’ reel: cpio -oc 32b, 1600BPI >3) 600(or maybe 800)’ reel: unknown > >i would REALLY like to get the info of tape 1. >all tapes were made around 1980, and have been stored in good residential temp/humidity. > >where might i be able to process these tapes? >or pointers to other places i might ask? > > andrew hume > From tuhs at tuhs.org Wed Sep 2 10:08:24 2026 From: tuhs at tuhs.org (andrew--- via TUHS) Date: Tue, 1 Sep 2026 17:08:24 -0700 Subject: [TUHS] mag tapes In-Reply-To: <20260901151122.1d83f588@TheHughesLogcabin.net> References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> <20260901151122.1d83f588@TheHughesLogcabin.net> Message-ID: <37F377B1-51B7-4F1B-94CE-5539423730D4@humeweb.com> i am in southern california. > On Sep 1, 2026, at 1:11 PM, Michael Hughes wrote: > > On Tue, 1 Sep 2026 12:15:39 -0700 > andrew--- via TUHS wrote: > >> during a belated round of cleanup around the house, i have come >> across 3 mag tapes: >> >> 1) 2400’ reel: cpio 5281x512 blocks, 800 BPI >> 2) 2400’ reel: cpio -oc 32b, 1600BPI >> 3) 600(or maybe 800)’ reel: unknown >> >> i would REALLY like to get the info of tape 1. >> all tapes were made around 1980, and have been stored in good >> residential temp/humidity. >> >> where might i be able to process these tapes? >> or pointers to other places i might ask? >> >> andrew hume >> >> > > I have two tape drives, one is connected to a VAX 3800 and the other is > an HP SCIS drive that I connect to a FreeBSD system. > > I have pulled data of tapes for other people in the past with the HP > drive. > > Where are you located? > > > -- > Michael D Hughes From tuhs at tuhs.org Wed Sep 2 11:21:44 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Tue, 1 Sep 2026 20:21:44 -0500 Subject: [TUHS] Regex archaeology Message-ID: All, I've been doing some experimentation to test my language, aiki, a small interpreted language. Most of my pressure tests have begun to move toward emulation because emulating machines is challenging in an interpreter (can you say sllllloooooowwwww?). Anyhow, when I had the regex implemented by my outsourced team (claude & chatgpt), I lacked any comprehension of how it actually worked beyond textbook level (which is to say, names of things that I didn't truly comprehend). So, I went looking to primary sources, as I usually do and I came across a sweet little regex implementation by none other than Ken Thompson, in his well known article, Regular Expression Search Algorithm, CACM v. 11, No. 6, June 1968. I found a decent copy and transcribed it so I could use it's examples more directly. It's a piece of work - an Algol 60 three stage program that emits IBM 7094 machine code that processes a string and produces signals. What I really appreciate is that the code "works", it's not a fragment, not partial implementation, but serious work, the core third stage. Anyhow, I wrote a small 7094 processor (only enough instructions to execute thompson's search) in aiki, and tried it out and it's glorious (to me) running the machine code it generates and producing expected results (as provided in this exceptional article). This like all shiny objects took me down a rabbit trail. My language is interpreted remember? I have been thinking about compilers - didn't think I wanted one originally, but man slow is so not me, but not just any implementation. My language is grammar bound, I already have an IR in the AST output, it's closed and therefore, I can prolly just emit it or better yet, follow Thompson with a bytecode emit (something for a go vm, for example). Anyhow, I started wondering, what about algol 60, it's always popping up in any serious language discussion and that took to Randell & Russell's 1964 Algol 60 implementation where translation is discussed, confirming my suspicion on how I might do the compiler for Aiki and preserve it's exact semantic representation and profiling capabilities dtrace style. Then I came back to Thompson, and that's hopefully where y'all come in... Do any of you know what implementation of algol-60 he might have used on the 7094? BC Algol is out in the wild and could be right, but I'm really jazzing to implement the search on an emulated 7094 using an actual algol and preferably the one he was using. I know, on topic? maybe a little stretch for folks only interested in bandying about in the userland/kernel, but regex and it's implementation in ed and elsewhere were surely influenced by this exact work. Thanks! Will From tuhs at tuhs.org Wed Sep 2 12:44:49 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Tue, 1 Sep 2026 22:44:49 -0400 Subject: [TUHS] Regex archaeology In-Reply-To: References: Message-ID: Will, CCing COFF and SIMH which is really where this question belongs and BCC: TUHS.org On Tue, Sep 1, 2026 at 9:21 PM Will Senn via TUHS wrote: > All, > > I've been doing some experimentation to test my language, aiki, a small > interpreted language. Most of my pressure tests have begun to move > toward emulation because emulating machines is challenging in an > interpreter (can you say sllllloooooowwwww?). Anyhow, when I had the > regex implemented by my outsourced team (claude & chatgpt), I lacked any > comprehension of how it actually worked beyond textbook level (which is > to say, names of things that I didn't truly comprehend). So, I went > looking to primary sources, as I usually do and I came across a sweet > little regex implementation by none other than Ken Thompson, in his well > known article, Regular Expression Search Algorithm, CACM v. 11, No. 6, > June 1968. I found a decent copy and transcribed it so I could use it's > examples more directly. It's a piece of work - an Algol 60 three stage > program that emits IBM 7094 machine code that processes a string and > produces signals. > > What I really appreciate is that the code "works", it's not a fragment, > not partial implementation, but serious work, the core third stage. > Anyhow, I wrote a small 7094 processor (only enough instructions to > execute thompson's search) in aiki, and tried it out and it's glorious > (to me) running the machine code it generates and producing expected > results (as provided in this exceptional article). > > This like all shiny objects took me down a rabbit trail. My language is > interpreted remember? I have been thinking about compilers - didn't > think I wanted one originally, but man slow is so not me, but not just > any implementation. My language is grammar bound, I already have an IR > in the AST output, it's closed and therefore, I can prolly just emit it > or better yet, follow Thompson with a bytecode emit (something for a go > vm, for example). Anyhow, I started wondering, what about algol 60, it's > always popping up in any serious language discussion and that took to > Randell & Russell's 1964 Algol 60 implementation where translation is > discussed, confirming my suspicion on how I might do the compiler for > Aiki and preserve it's exact semantic representation and profiling > capabilities dtrace style. Then I came back to Thompson, and that's > hopefully where y'all come in... Do any of you know what implementation > of algol-60 he might have used on the 7094? BC Algol is out in the wild > and could be right, but I'm really jazzing to implement the search on an > emulated 7094 using an actual algol and preferably the one he was using. > As I understand it, there are at least three: - IBM ALGOL 60 (System Monitor Compiler) for the IBSYS operating system - SHARE ALGOL 60 Translator targeting the IBM 709/7090/7094 hardware and I thought could run on CTSS - ALCOR ALGOL 60 European-American consortium dedicated to standardized ALGOL deployment for the for the 7090/7094 You might ask Ken what he remembers. I haven't read the paper inm a few years, did he say which OS he was using that might help you track it down. Google tells me that ALCOR-Illinois 7090/7094 compiler project has some influence in CTSS. But it also says: *"**While standard ALGOL 60 dialects like ALCOR existed on the hardware, they were not the primary way people wrote algorithmic code on CTSS day-to-day. CTSS users heavily favored two deeply related "ALGOL-cousin" systems. ... MAD (Michigan Algorithm Decoder - ALGOL 58, and compiled unbelievably fast): was one of the most popular high-level languages on CTSS ... AED (Algol Extended for Design): created at MIT, AED was an explicit, major extension of ALGOL 60 designed specifically to run under CTSS."* > I know, on topic? maybe a little stretch for folks only interested in > bandying about in the userland/kernel, but regex and it's implementation > in ed and elsewhere were surely influenced by this exact work. > > Thanks! > > Will > > From tuhs at tuhs.org Wed Sep 2 13:27:58 2026 From: tuhs at tuhs.org (Lars Brinkhoff via TUHS) Date: Wed, 02 Sep 2026 03:27:58 +0000 Subject: [TUHS] mag tapes In-Reply-To: (Ron Natalie via TUHS's message of "Tue, 01 Sep 2026 20:42:06 +0000") References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: <7wwlt449j5.fsf@junk.nocrew.org> Ron Natalie wrote: > Once you have the raw records decoding the CPIO is pretty trivial. You'd think so. But I have come across several cpio tapes that wouldn't decode with a regular modern cpio. So I wrote this. https://github.com/larsbrinkhoff/tools-for-unusual-tape-formats/blob/master/cpio.c From tuhs at tuhs.org Wed Sep 2 21:19:08 2026 From: tuhs at tuhs.org (Dan Cross via TUHS) Date: Wed, 2 Sep 2026 07:19:08 -0400 Subject: [TUHS] mag tapes In-Reply-To: References: <1C4B4889-E1C9-4249-8DDB-0F11CB55E561@humeweb.com> Message-ID: On Tue, Sep 1, 2026 at 4:50 PM Ron Natalie via TUHS wrote: > Obviously, getting it off the physical media is key. Once you have the > raw records decoding the CPIO is pretty trivial. Hell, my Mac even has > cpio on it (haven’t used that in years). > [snip] cpio remains surprisingly relevant in the modern age; I believe the Linux initramfs is a cpio archive, and I know for sure that Oxide machines read a compressed cpio archive out of flash containing the kernel image that initializes our machines (I know because I wrote the code that reads the archive, loads and maps the kernel, and jumps into it to initialize the world; we pull a ramdisk image for the root filesystem off of an NVMe device once we've initialized the PCIe subsystem and kicked off link training and so forth). - Dan C. From tuhs at tuhs.org Fri Sep 4 17:27:05 2026 From: tuhs at tuhs.org (Arnold Robbins via TUHS) Date: Fri, 04 Sep 2026 01:27:05 -0600 Subject: [TUHS] Plan 9 C compilers for Linux/mac/windows Message-ID: <202609040727.6847R5xa087700@freefriends.org> This may be of interest to this crowd. NOTE that this is NOT my work, I am simply passing the info on. Arnold > From: yoann.padioleau at gmail.com > To: 9fans <9fans at 9fans.net> > Date: Thu, 3 Sep 2026 16:24:08 -0400 > Subject: [9fans] Goken9cc update, support for Linux, macOS, windows and 11 > archs! > > This is an update for the Goken9cc project I've announced a few months > ago on 9fans (and presented at IWP9): https://github.com/aryx/goken9cc > > To summarize: goken9cc is a portable, multi-architecture toolchain — C > compilers, assemblers, and linkers — together with a minimalist C > library, rooted in Ken Thompson's legendary work on the Plan 9 and > Inferno operating systems. First extended by Go developers, this > toolchain now brings cross-platform support for Linux, macOS, and > Windows while preserving the simplicity, elegance, and efficiency of > the original Plan 9 tools. > > In the future work section of my talk I was talking about the > support to produce Linux ELF binaries, macOS Mach-O binaries, > and windows PE binaries and it's now all working! > > There is also a multiplatform libc similar to the original Plan 9 libc > that can work on 11 architectures (i386, amd64, arm, arm64, riscv32, riscv64, > mips, powerpc, sparc, alpha, m68k) across 4 operating systems (Linux, > darwin, windows, plan9, with xv6 in the work). > > We can now even bootstrap goken using goken, that is using it to compile > itself on Linux, macOS, and windows (and we can still bootstrap it > using gcc and clang, the original goal of goken9cc). > > The included multiplatform libc is pretty complete as it > can be used to compile goken itself which contains not only the toolchain > but also the code of mk, rc, as well as many Plan 9 utilities. > > My plan now is to add a multiplatform libdraw to also produce > Linux, macOS, and windows binaries using graphics (relying on > Russ cox port of libdraw in plan9port and in drawterm). > > Happy to answer questions or requests for the project. > > PS: the code of goken is synced with my other principia softwarica project > so the code of goken is also fully explain in the principia books > at https://principia-softwarica.org/ > > > AI disclaimer: > 95% of the code in goken9cc was written by humans (mostly Ken > Thompson, Rob Pike, Charles Forsyth, Richard Miller, and other Plan 9 > contributors), and for the most part written more than 30 years > ago. What I did was essentially to package those old toolchains > together and then use AI to write the remaining 5% so that the > toolchains could work not just on Plan 9 for Plan 9 but also on and > for Linux, macOS, and Windows (imitating for the most part what was > done by Go developers for the Go language). > > All the clerical work of finding the right syscall numbers for each > architecture and operating systems for the multiplatform C library in > goken9cc (see lib_core/libc/{arch,syscall,os}) was done by Claude > Code, inspired by what Go developers did for Go (see the > GO/pkg/{syscall,runtime} directories). > > Most of the code written by AI is clearly marked with a special > claude: comment at the front and part of a commit authored by Claude > code. You can use the scripts/ai_percentage.py to get authorship LOC > statistics across the different directories in goken9cc. > > ------------------------------------------ > 9fans: 9fans > Permalink: https://9fans.topicbox.com/groups/9fans/T2bd4bdf3bed27839-Mba276412b5bb732bb23582de > Delivery options: https://9fans.topicbox.com/groups/9fans/subscription From tuhs at tuhs.org Sat Sep 5 03:02:19 2026 From: tuhs at tuhs.org (Jacob Moody via TUHS) Date: Fri, 4 Sep 2026 12:02:19 -0500 Subject: [TUHS] Plan 9 C compilers for Linux/mac/windows In-Reply-To: <202609040727.6847R5xa087700@freefriends.org> References: <202609040727.6847R5xa087700@freefriends.org> Message-ID: <34ffdc4f-1de5-4cf2-bf69-eca1cc0e8746@posixcafe.org> One thing to note, this starts from an older fork and some perusing through the git commit log I don't see any backports of a lot of the fixes that were found and fixed in the 9front variants of these compilers. I could also be wrong exactly what is taken from the old kencc-fork repo and what is taken from go is not super clear and I have little interest to review AI code. There were some pretty nasty latent bugs that only tend to show up once you start to tow these compilers outside their environment. I found a decent chunk of bugs only once we started porting some games (I talk about some in my iwp9 talk on NPE). My favorite was how a packed struct assignment copy mistake resulted in Heretic having a broken inventory system. I am biased so take my grumbles with a grain of salt. However 9front has the advantage of folks living with and scrutinizing these compilers "in production" for the last 15 years... - moody On 9/4/26 02:27, Arnold Robbins via TUHS wrote: > This may be of interest to this crowd. NOTE that this is NOT > my work, I am simply passing the info on. > > Arnold > >> From: yoann.padioleau at gmail.com >> To: 9fans <9fans at 9fans.net> >> Date: Thu, 3 Sep 2026 16:24:08 -0400 >> Subject: [9fans] Goken9cc update, support for Linux, macOS, windows and 11 >> archs! >> >> This is an update for the Goken9cc project I've announced a few months >> ago on 9fans (and presented at IWP9): https://github.com/aryx/goken9cc >> >> To summarize: goken9cc is a portable, multi-architecture toolchain — C >> compilers, assemblers, and linkers — together with a minimalist C >> library, rooted in Ken Thompson's legendary work on the Plan 9 and >> Inferno operating systems. First extended by Go developers, this >> toolchain now brings cross-platform support for Linux, macOS, and >> Windows while preserving the simplicity, elegance, and efficiency of >> the original Plan 9 tools. >> >> In the future work section of my talk I was talking about the >> support to produce Linux ELF binaries, macOS Mach-O binaries, >> and windows PE binaries and it's now all working! >> >> There is also a multiplatform libc similar to the original Plan 9 libc >> that can work on 11 architectures (i386, amd64, arm, arm64, riscv32, riscv64, >> mips, powerpc, sparc, alpha, m68k) across 4 operating systems (Linux, >> darwin, windows, plan9, with xv6 in the work). >> >> We can now even bootstrap goken using goken, that is using it to compile >> itself on Linux, macOS, and windows (and we can still bootstrap it >> using gcc and clang, the original goal of goken9cc). >> >> The included multiplatform libc is pretty complete as it >> can be used to compile goken itself which contains not only the toolchain >> but also the code of mk, rc, as well as many Plan 9 utilities. >> >> My plan now is to add a multiplatform libdraw to also produce >> Linux, macOS, and windows binaries using graphics (relying on >> Russ cox port of libdraw in plan9port and in drawterm). >> >> Happy to answer questions or requests for the project. >> >> PS: the code of goken is synced with my other principia softwarica project >> so the code of goken is also fully explain in the principia books >> at https://principia-softwarica.org/ >> >> >> AI disclaimer: >> 95% of the code in goken9cc was written by humans (mostly Ken >> Thompson, Rob Pike, Charles Forsyth, Richard Miller, and other Plan 9 >> contributors), and for the most part written more than 30 years >> ago. What I did was essentially to package those old toolchains >> together and then use AI to write the remaining 5% so that the >> toolchains could work not just on Plan 9 for Plan 9 but also on and >> for Linux, macOS, and Windows (imitating for the most part what was >> done by Go developers for the Go language). >> >> All the clerical work of finding the right syscall numbers for each >> architecture and operating systems for the multiplatform C library in >> goken9cc (see lib_core/libc/{arch,syscall,os}) was done by Claude >> Code, inspired by what Go developers did for Go (see the >> GO/pkg/{syscall,runtime} directories). >> >> Most of the code written by AI is clearly marked with a special >> claude: comment at the front and part of a commit authored by Claude >> code. You can use the scripts/ai_percentage.py to get authorship LOC >> statistics across the different directories in goken9cc. >> >> ------------------------------------------ >> 9fans: 9fans >> Permalink: https://9fans.topicbox.com/groups/9fans/T2bd4bdf3bed27839-Mba276412b5bb732bb23582de >> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription From tuhs at tuhs.org Wed Sep 9 09:36:22 2026 From: tuhs at tuhs.org (Warren Toomey via TUHS) Date: Wed, 9 Sep 2026 09:36:22 +1000 Subject: [TUHS] Possible Unsubscribe Spam E-mails Message-ID: All, I've had a few TUHS/COFF people e-mail me to say that they have received a "please confirm you want to unsubscribe from this list" e-mail. As far as I'm aware, these e-mails haven't been generated by the Mailman software behind the TUHS & COFF lists. Please assume that they are spammers and delete the e-mails. We will see what, if anything, we can do about them. Thanks, Warren and the TUHS team. From tuhs at tuhs.org Wed Sep 9 10:24:34 2026 From: tuhs at tuhs.org (Dave Horsfall via TUHS) Date: Wed, 9 Sep 2026 10:24:34 +1000 Subject: [TUHS] [COFF] Possible Unsubscribe Spam E-mails In-Reply-To: References: Message-ID: Shouldn't be too hard for recipients to check the headers to see whether or not it came from Warren's box; also, your MTA (for those running their own mail servers) can use a variety of anti-spoofing measures (check the docs). And again, if you run your own server then simply block the offending IP (I block the entire CIDR meself) and move on. -- Dave On Wed, 9 Sept 2026 at 09:45, Warren Toomey via COFF wrote: > All, I've had a few TUHS/COFF people e-mail me to say that they have > received a "please confirm you want to unsubscribe from this list" e-mail. > > As far as I'm aware, these e-mails haven't been generated by the > Mailman software behind the TUHS & COFF lists. Please assume that > they are spammers and delete the e-mails. > > We will see what, if anything, we can do about them. > > Thanks, Warren and the TUHS team. > -- Dave Horsfall 13/71-79 Glennie St North Gosford NSW 2250 02 4326 1079 (preferred) 0490 095 371 (SMS only) From tuhs at tuhs.org Wed Sep 9 20:42:07 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Wed, 9 Sep 2026 06:42:07 -0400 Subject: [TUHS] Pic semantics Message-ID: I have been surprised by the handling of Pic macro arguments, quite different from m4, although Brian had a hand in both. I wonder if Gnu differs from the original. Would someone who can run a Research version of Pic be willing to try it and send me Pic's (not groff's) output from the example below? The issue is whether macro calls in arguments are evaluated when the arguments are collected. For example, is the argument collected for the macro call m(x) below x or "A"? In Gnu, it's x, so the two instances of $1 ultimately become different text. .PS define x {"A"} define m {$1; move; define x {"B"}; $1} m(x) .PE Thanks, Doug From tuhs at tuhs.org Thu Sep 10 08:06:26 2026 From: tuhs at tuhs.org (Noel Hunt via TUHS) Date: Thu, 10 Sep 2026 08:06:26 +1000 Subject: [TUHS] Pic semantics In-Reply-To: References: Message-ID: I just compiled 'pic' from the 'v10a' distribution, and it compiled suprisingly easily. I was expecting lots of prototype errors etc. Here is what it outputs: .lf 1 test.pic ... 0 0 0.5 0 ... 0.000i 0.000i 0.500i 0.000i .nr 00 \n(.u .nf .PS 0.000i 0.500i .lf 6 \v'.2m'\h'-\w'A'u/2u'A .sp -1 \h'0.500i'\v'.2m'\h'-\w'B'u/2u'B .sp -1 .sp 1+0.000i .PE .if \n(00 .fi .lf 6 On Wed, 9 Sept 2026 at 20:42, Douglas McIlroy via TUHS wrote: > > I have been surprised by the handling of Pic macro arguments, quite > different from m4, although Brian had a hand in both. I wonder if Gnu > differs from the original. > > Would someone who can run a Research version of Pic be willing to try > it and send me Pic's (not groff's) output from the example below? The > issue is whether macro calls in arguments are evaluated when the > arguments are collected. For example, is the argument collected for > the macro call m(x) below x or "A"? In Gnu, it's x, so the two > instances of $1 ultimately become different text. > > .PS > define x {"A"} > define m {$1; move; define x {"B"}; $1} > m(x) > .PE > > Thanks, > Doug From tuhs at tuhs.org Thu Sep 10 10:26:57 2026 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Thu, 10 Sep 2026 10:26:57 +1000 Subject: [TUHS] Pic semantics In-Reply-To: References: Message-ID: I tested and got the identical output from plan9port pic, which is the Plan 9 version. -rob On Thu, Sep 10, 2026 at 8:07 AM Noel Hunt via TUHS wrote: > I just compiled 'pic' from the 'v10a' distribution, and it compiled > suprisingly easily. > I was expecting lots of prototype errors etc. > > Here is what it outputs: > > .lf 1 test.pic > ... 0 0 0.5 0 > ... 0.000i 0.000i 0.500i 0.000i > .nr 00 \n(.u > .nf > .PS 0.000i 0.500i > .lf 6 > \v'.2m'\h'-\w'A'u/2u'A > .sp -1 > \h'0.500i'\v'.2m'\h'-\w'B'u/2u'B > .sp -1 > .sp 1+0.000i > .PE > .if \n(00 .fi > .lf 6 > > On Wed, 9 Sept 2026 at 20:42, Douglas McIlroy via TUHS > wrote: > > > > I have been surprised by the handling of Pic macro arguments, quite > > different from m4, although Brian had a hand in both. I wonder if Gnu > > differs from the original. > > > > Would someone who can run a Research version of Pic be willing to try > > it and send me Pic's (not groff's) output from the example below? The > > issue is whether macro calls in arguments are evaluated when the > > arguments are collected. For example, is the argument collected for > > the macro call m(x) below x or "A"? In Gnu, it's x, so the two > > instances of $1 ultimately become different text. > > > > .PS > > define x {"A"} > > define m {$1; move; define x {"B"}; $1} > > m(x) > > .PE > > > > Thanks, > > Doug > From tuhs at tuhs.org Fri Sep 11 08:17:45 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Thu, 10 Sep 2026 18:17:45 -0400 Subject: [TUHS] Pic semantics In-Reply-To: References: Message-ID: Thanks all for helping to suss out Pic macro semantics. A v10 trial confirms the consensus that Gnu Pic is faithful to the original. On Wed, Sep 9, 2026 at 6:07 PM Noel Hunt wrote: > > I just compiled 'pic' from the 'v10a' distribution, and it compiled > suprisingly easily. > I was expecting lots of prototype errors etc. > > Here is what it outputs: > > .lf 1 test.pic > ... 0 0 0.5 0 > ... 0.000i 0.000i 0.500i 0.000i > .nr 00 \n(.u > .nf > .PS 0.000i 0.500i > .lf 6 > \v'.2m'\h'-\w'A'u/2u'A > .sp -1 > \h'0.500i'\v'.2m'\h'-\w'B'u/2u'B > .sp -1 > .sp 1+0.000i > .PE > .if \n(00 .fi > .lf 6 > > On Wed, 9 Sept 2026 at 20:42, Douglas McIlroy via TUHS wrote: > > > > I have been surprised by the handling of Pic macro arguments, quite > > different from m4, although Brian had a hand in both. I wonder if Gnu > > differs from the original. > > > > Would someone who can run a Research version of Pic be willing to try > > it and send me Pic's (not groff's) output from the example below? The > > issue is whether macro calls in arguments are evaluated when the > > arguments are collected. For example, is the argument collected for > > the macro call m(x) below x or "A"? In Gnu, it's x, so the two > > instances of $1 ultimately become different text. > > > > .PS > > define x {"A"} > > define m {$1; move; define x {"B"}; $1} > > m(x) > > .PE > > > > Thanks, > > Doug From tuhs at tuhs.org Mon Sep 14 09:44:58 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Sun, 13 Sep 2026 18:44:58 -0500 Subject: [TUHS] v6 basic did graphics? Message-ID: <8b496e9c-ce09-4f01-a697-3499a7400abf@gmail.com> Will wonders never cease? I learned today that bas, v6's basic did graphics on a vt01 connected via another pdp-11/20. I thought, if they could do it back in the day, why not today :). So, after a bit of AI enhanced learning and some tweaks to simh, I got it working as a v6vt endpoint leveraging simh's existing code for display. The post: https://decuser.github.io/posts/v6-basic-with-graphics/ This is the bottom line result in v6: # bas 10 erase 20 draw .2 .2 0 30 draw .8 .2 1 40 draw .8 .8 1 50 draw .2 .8 1 60 draw .2 .2 1 70 draw .35 .5 0 80 display "UNIX V6 BASIC" 90 done run UNIX V6 BASIC in PDP-11 V6VT - NG Display Window For me it was just, wow! now, I can do graphics in v6, who'd of thunk it. Later, Will From tuhs at tuhs.org Mon Sep 14 11:41:39 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Sun, 13 Sep 2026 18:41:39 -0700 Subject: [TUHS] v6 basic did graphics? In-Reply-To: <8b496e9c-ce09-4f01-a697-3499a7400abf@gmail.com> References: <8b496e9c-ce09-4f01-a697-3499a7400abf@gmail.com> Message-ID: we also had graphics on v6 via the famed tektronix green screen terminals. Not sure how widely the programs were distributed, but they were used at udel. On Sun, Sep 13, 2026 at 4:44 PM Will Senn via TUHS wrote: > Will wonders never cease? I learned today that bas, v6's basic did > graphics on a vt01 connected via another pdp-11/20. I thought, if they > could do it back in the day, why not today :). So, after a bit of AI > enhanced learning and some tweaks to simh, I got it working as a v6vt > endpoint leveraging simh's existing code for display. > > The post: https://decuser.github.io/posts/v6-basic-with-graphics/ > > This is the bottom line result in v6: > > # bas > 10 erase > 20 draw .2 .2 0 > 30 draw .8 .2 1 > 40 draw .8 .8 1 > 50 draw .2 .8 1 > 60 draw .2 .2 1 > 70 draw .35 .5 0 > 80 display "UNIX V6 BASIC" > 90 done > run > > UNIX V6 BASIC in PDP-11 V6VT - NG Display Window > > > For me it was just, wow! now, I can do graphics in v6, who'd of thunk it. > > Later, > > Will > From tuhs at tuhs.org Tue Sep 15 10:22:48 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Mon, 14 Sep 2026 19:22:48 -0500 Subject: [TUHS] v6 basic did graphics? In-Reply-To: References: <8b496e9c-ce09-4f01-a697-3499a7400abf@gmail.com> Message-ID: Ah, fascinating. I see that graph is documented in V6, but I don't see the executable in the distribution. bas and FORTRAN both use /dev/vt0 for graphics, while the docs also mention Tektronix 4014, GSI/Diablo, and vt0 backends. graph(6) names gsip, tek, and vt0 as plotting filters. I don't see those executables either, but presumably they existed somewhere in the Bell Labs tree. The vt0 case is especially interesting because it apparently was not a VT01 directly attached to the V6 machine. DMR's vt.c says: /*  * VT01 driver via DR11C to 11/20  */ My reading is that the V6 machine talked over DR11-C to a PDP-11/20, and that machine in turn drove the VT01, presumably through the AA11 interface. The graphics protocol appears to have been a byte stream carrying the operations described in plot(6): m  move p  point l  line t  label a  arc c  circle e  erase f  linemod d  dotline Does anyone remember this Bell Labs setup, or know what program ran on the 11/20 to interpret that stream and drive the VT01? Regards, Will On 9/13/26 8:41 PM, ron minnich wrote: > we also had graphics on v6 via the famed tektronix green screen > terminals. Not sure how widely the programs were distributed, but they > were used at udel. > > On Sun, Sep 13, 2026 at 4:44 PM Will Senn via TUHS wrote: > > Will wonders never cease? I learned today that bas, v6's basic did > graphics on a vt01 connected via another pdp-11/20. I thought, if > they > could do it back in the day, why not today :). So, after a bit of AI > enhanced learning and some tweaks to simh, I got it working as a v6vt > endpoint leveraging simh's existing code for display. > > The post: https://decuser.github.io/posts/v6-basic-with-graphics/ > > This is the bottom line result in v6: > > # bas > 10 erase > 20 draw .2 .2 0 > 30 draw .8 .2 1 > 40 draw .8 .8 1 > 50 draw .2 .8 1 > 60 draw .2 .2 1 > 70 draw .35 .5 0 > 80 display "UNIX V6 BASIC" > 90 done > run > > UNIX V6 BASIC in PDP-11 V6VT - NG Display Window > > > For me it was just, wow! now, I can do graphics in v6, who'd of > thunk it. > > Later, > > Will > From tuhs at tuhs.org Tue Sep 15 14:47:30 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Mon, 14 Sep 2026 23:47:30 -0500 Subject: [TUHS] speak and speech synthesis Message-ID: In a similar investigation to my graphics dive, this time into speech synthesis, I found that |/dev/vs| talks to the synthesizer through a DC-11. I’m trying to determine the interrupt/vector assignment for that device—specifically the Federal Screw Works Votrax interface. There is quite a bit of useful material scattered across UNIX V4 through V6. From that, I can reconstruct the system generically: add the |vs| driver to the kernel, create |/dev/vs|, add PCM audio support to SIMH, and translate the historical phoneme stream into approximate speech based on what can be pieced together from the source and documentation. This "should" work and get speak working... I’d prefer, though, to reproduce the original interface somewhat more faithfully. The V4/V6 |vs.c| sources give the CSR address (|0174150|) and the receive/transmit interrupt routines (|vsrintr| and |vsxintr|), but I haven’t yet found the actual interrupt vector assignment used for the Votrax/DC-11 installation. If anyone has an old kernel configuration, |mkconf| entry, low-core |l.s|, hardware note, or other documentation showing how the Screw Works Votrax interface was actually vectored, I’d be very interested in seeing it. Also, Doug, you wrote technical report 14, which seems canonical about how speak worked. Is that the best source you or anyone else knows of vis a vis v6's implementation? Thanks, Will From tuhs at tuhs.org Tue Sep 15 21:22:20 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Tue, 15 Sep 2026 07:22:20 -0400 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: Message-ID: > Also, Doug, you wrote technical report 14, which seems canonical about > how speak worked. Is that the best source you or anyone else knows of > vis a vis v6's implementation? That''s the only documentation I know of. I also have C source and driver tables for several points in time. I cam pass them to tuhs if needed. Doug On Tue, Sep 15, 2026 at 12:47 AM Will Senn via TUHS wrote: > > In a similar investigation to my graphics dive, this time into speech > synthesis, I found that |/dev/vs| talks to the synthesizer through a > DC-11. I’m trying to determine the interrupt/vector assignment for that > device—specifically the Federal Screw Works Votrax interface. > > There is quite a bit of useful material scattered across UNIX V4 through > V6. From that, I can reconstruct the system generically: add the |vs| > driver to the kernel, create |/dev/vs|, add PCM audio support to SIMH, > and translate the historical phoneme stream into approximate speech > based on what can be pieced together from the source and documentation. > This "should" work and get speak working... > > I’d prefer, though, to reproduce the original interface somewhat more > faithfully. The V4/V6 |vs.c| sources give the CSR address (|0174150|) > and the receive/transmit interrupt routines (|vsrintr| and |vsxintr|), > but I haven’t yet found the actual interrupt vector assignment used for > the Votrax/DC-11 installation. > > If anyone has an old kernel configuration, |mkconf| entry, low-core > |l.s|, hardware note, or other documentation showing how the Screw Works > Votrax interface was actually vectored, I’d be very interested in seeing it. > > Also, Doug, you wrote technical report 14, which seems canonical about > how speak worked. Is that the best source you or anyone else knows of > vis a vis v6's implementation? > > Thanks, > > Will > From tuhs at tuhs.org Wed Sep 16 01:24:52 2026 From: tuhs at tuhs.org (Marco Moock via TUHS) Date: Tue, 15 Sep 2026 17:24:52 +0200 Subject: [TUHS] uname meaning Message-ID: <8459d9c3-a35c-4d01-88d2-e9f708bbe479@dorfdsl.de> Hello! What does the command uname mean? Is it UNIX name or something else? -- kind regards Marco Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Wed Sep 16 01:34:48 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Tue, 15 Sep 2026 15:34:48 +0000 Subject: [TUHS] uname meaning In-Reply-To: <8459d9c3-a35c-4d01-88d2-e9f708bbe479@dorfdsl.de> References: <8459d9c3-a35c-4d01-88d2-e9f708bbe479@dorfdsl.de> Message-ID: Yes. Checking the System III man page for it: NAME uname - print name of current UNIX From tuhs at tuhs.org Wed Sep 16 01:37:11 2026 From: tuhs at tuhs.org (Marco Moock via TUHS) Date: Tue, 15 Sep 2026 17:37:11 +0200 Subject: [TUHS] uname meaning In-Reply-To: References: <8459d9c3-a35c-4d01-88d2-e9f708bbe479@dorfdsl.de> Message-ID: <08b6eaea-024f-441b-9044-a5d84ffea7ae@dorfdsl.de> Am 15.09.26 um 17:34 schrieb Ron Natalie: > Yes.   Checking the System III man page for it: > > >  NAME > uname - print name of current UNIX Thanks! Linux and FreeBSD do not mention this, they call it operating system implementation (FreeBSD) oder just system information (Fedora) -- Gruß Marco Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Wed Sep 16 02:16:57 2026 From: tuhs at tuhs.org (segaloco via TUHS) Date: Tue, 15 Sep 2026 16:16:57 +0000 Subject: [TUHS] uname meaning In-Reply-To: <08b6eaea-024f-441b-9044-a5d84ffea7ae@dorfdsl.de> References: <8459d9c3-a35c-4d01-88d2-e9f708bbe479@dorfdsl.de> <08b6eaea-024f-441b-9044-a5d84ffea7ae@dorfdsl.de> Message-ID: On Tuesday, September 15th, 2026 at 08:37, Marco Moock via TUHS wrote: > Am 15.09.26 um 17:34 schrieb Ron Natalie: > > Yes.   Checking the System III man page for it: > > > > > >  NAME > > uname - print name of current UNIX > > Thanks! > > Linux and FreeBSD do not mention this, they call it operating system > implementation (FreeBSD) oder just system information (Fedora) > > -- > Gruß > Marco > > Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de > My understanding is this either originates with PWB or SCCS UNIX. PWB 1.0 has a "pwbname(I)" utility that operates along similar lines. The underlying structure feeding uname(1) is called "utsname" owing to its UNIX/TS origins. Eventually this was used to identify the variant of system (System V vs. BSD vs. AIX vs. UTS vs....etc) but in the early days it seems it may have been used a little more like a hostname. Historic documentation implies USG UNIX may have had a similar mechanism but I don't think its in the manuals. - Matt G. From tuhs at tuhs.org Wed Sep 16 11:42:50 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Tue, 15 Sep 2026 20:42:50 -0500 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: Message-ID: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> It'd be great to have the files archived. If you point me at them I can collect, otherwise, if you like, you can send them to me and I'll work with the team to find a home. BTW, I got it working through some gymnastics, V3/V4 had quite a bit of the necessary files, dspinellis had speak.c/speak.v. It's not 100% faithful in my current environment for a couple of reasons - 1) I'm using SC01A as exemplar, not having a pre SC01 pot around, and 2) it hurt my ears without minimal smoothing from one phoneme into another. Oh, and I'm leveraging simh's sdl for the audio out. I'll work on packaging it up with explanation but right now, bas has all of the graphics it knows about, fortran extends and uses more of the graphic functions that I've implemented (the full set), and now, I have added /dev/vs into the mix and speak lives: from v6 with the adapted simh and appropriate mkconf stuff: echo 'all your base are belong to us. Research Unix V6 is speaking aloud in 2026' | /bin/speak result in all of its glory (tell me it sounds as glorious to your ears): https://decuser.github.io/assets/audio/votrax-v6.wav Later, Will On 9/15/26 6:22 AM, Douglas McIlroy wrote: >> Also, Doug, you wrote technical report 14, which seems canonical about >> how speak worked. Is that the best source you or anyone else knows of >> vis a vis v6's implementation? > That''s the only documentation I know of. I also have C source and > driver tables for > several points in time. I cam pass them to tuhs if needed. > > Doug > > On Tue, Sep 15, 2026 at 12:47 AM Will Senn via TUHS wrote: >> In a similar investigation to my graphics dive, this time into speech >> synthesis, I found that |/dev/vs| talks to the synthesizer through a >> DC-11. I’m trying to determine the interrupt/vector assignment for that >> device—specifically the Federal Screw Works Votrax interface. >> >> There is quite a bit of useful material scattered across UNIX V4 through >> V6. From that, I can reconstruct the system generically: add the |vs| >> driver to the kernel, create |/dev/vs|, add PCM audio support to SIMH, >> and translate the historical phoneme stream into approximate speech >> based on what can be pieced together from the source and documentation. >> This "should" work and get speak working... >> >> I’d prefer, though, to reproduce the original interface somewhat more >> faithfully. The V4/V6 |vs.c| sources give the CSR address (|0174150|) >> and the receive/transmit interrupt routines (|vsrintr| and |vsxintr|), >> but I haven’t yet found the actual interrupt vector assignment used for >> the Votrax/DC-11 installation. >> >> If anyone has an old kernel configuration, |mkconf| entry, low-core >> |l.s|, hardware note, or other documentation showing how the Screw Works >> Votrax interface was actually vectored, I’d be very interested in seeing it. >> >> Also, Doug, you wrote technical report 14, which seems canonical about >> how speak worked. Is that the best source you or anyone else knows of >> vis a vis v6's implementation? >> >> Thanks, >> >> Will >> From tuhs at tuhs.org Thu Sep 17 01:31:02 2026 From: tuhs at tuhs.org (Cameron Tyre via TUHS) Date: Wed, 16 Sep 2026 15:31:02 +0000 Subject: [TUHS] speak and speech synthesis In-Reply-To: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> References: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> Message-ID: Hi Will, I appreciate your efforts. I think it's easy to forget how impressive that would have sounded in the early 1980s or thereabouts. It reminds me of the Speak & Spell! Best regards, Cameron Sent from Proton Mail for Android. -------- Original Message -------- On Wednesday, 09/16/26 at 02:42 Will Senn via TUHS wrote: It'd be great to have the files archived. If you point me at them I can collect, otherwise, if you like, you can send them to me and I'll work with the team to find a home. BTW, I got it working through some gymnastics, V3/V4 had quite a bit of the necessary files, dspinellis had speak.c/speak.v. It's not 100% faithful in my current environment for a couple of reasons - 1) I'm using SC01A as exemplar, not having a pre SC01 pot around, and 2) it hurt my ears without minimal smoothing from one phoneme into another. Oh, and I'm leveraging simh's sdl for the audio out. I'll work on packaging it up with explanation but right now, bas has all of the graphics it knows about, fortran extends and uses more of the graphic functions that I've implemented (the full set), and now, I have added /dev/vs into the mix and speak lives: from v6 with the adapted simh and appropriate mkconf stuff: echo 'all your base are belong to us. Research Unix V6 is speaking aloud in 2026' | /bin/speak result in all of its glory (tell me it sounds as glorious to your ears): https://decuser.github.io/assets/audio/votrax-v6.wav Later, Will On 9/15/26 6:22 AM, Douglas McIlroy wrote: >> Also, Doug, you wrote technical report 14, which seems canonical about >> how speak worked. Is that the best source you or anyone else knows of >> vis a vis v6's implementation? > That''s the only documentation I know of. I also have C source and > driver tables for > several points in time. I cam pass them to tuhs if needed. > > Doug > > On Tue, Sep 15, 2026 at 12:47 AM Will Senn via TUHS wrote: >> In a similar investigation to my graphics dive, this time into speech >> synthesis, I found that |/dev/vs| talks to the synthesizer through a >> DC-11. I’m trying to determine the interrupt/vector assignment for that >> device—specifically the Federal Screw Works Votrax interface. >> >> There is quite a bit of useful material scattered across UNIX V4 through >> V6. From that, I can reconstruct the system generically: add the |vs| >> driver to the kernel, create |/dev/vs|, add PCM audio support to SIMH, >> and translate the historical phoneme stream into approximate speech >> based on what can be pieced together from the source and documentation. >> This "should" work and get speak working... >> >> I’d prefer, though, to reproduce the original interface somewhat more >> faithfully. The V4/V6 |vs.c| sources give the CSR address (|0174150|) >> and the receive/transmit interrupt routines (|vsrintr| and |vsxintr|), >> but I haven’t yet found the actual interrupt vector assignment used for >> the Votrax/DC-11 installation. >> >> If anyone has an old kernel configuration, |mkconf| entry, low-core >> |l.s|, hardware note, or other documentation showing how the Screw Works >> Votrax interface was actually vectored, I’d be very interested in seeing it. >> >> Also, Doug, you wrote technical report 14, which seems canonical about >> how speak worked. Is that the best source you or anyone else knows of >> vis a vis v6's implementation? >> >> Thanks, >> >> Will >> From tuhs at tuhs.org Thu Sep 17 02:21:49 2026 From: tuhs at tuhs.org (Johan Helsingius via TUHS) Date: Wed, 16 Sep 2026 18:21:49 +0200 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> Message-ID: <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> On 16/09/2026 5:31 pm, Cameron Tyre via TUHS wrote: > I appreciate your efforts. I think it's easy to forget how impressive that would have sounded in the early 1980s or thereabouts. It reminds me of the Speak & Spell! I always remember Peter Langston's "Eddie & Eedie and reggaebots", (as featured on the CD that came with the USENIX Computing Systems special on computer music. https://www.youtube.com/watch?v=1l0Ko1GUiSo&list=RD1l0Ko1GUiSo Julf From tuhs at tuhs.org Thu Sep 17 05:53:43 2026 From: tuhs at tuhs.org (ron minnich via TUHS) Date: Wed, 16 Sep 2026 13:53:43 -0600 Subject: [TUHS] speak and speech synthesis In-Reply-To: <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> References: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> Message-ID: at udel, we once set up to have the votrax call the student radio station and talk to the DJ. They were quite unconvinced that it was a computer talking to them. We never figured out what made it not credible. On Wed, Sep 16, 2026 at 9:22 AM Johan Helsingius via TUHS wrote: > On 16/09/2026 5:31 pm, Cameron Tyre via TUHS wrote: > > I appreciate your efforts. I think it's easy to forget how impressive > that would have sounded in the early 1980s or thereabouts. It reminds me of > the Speak & Spell! > > I always remember Peter Langston's "Eddie & Eedie and reggaebots", > (as featured on the CD that came with the USENIX Computing Systems > special on computer music. > > https://www.youtube.com/watch?v=1l0Ko1GUiSo&list=RD1l0Ko1GUiSo > > Julf > > From tuhs at tuhs.org Thu Sep 17 05:55:48 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Wed, 16 Sep 2026 19:55:48 +0000 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> Message-ID: Edie and Eddie were a blast, as was the rest of the Redphone system. The thing answered the phone… Bell Communications Research (long pause) Yes, Operator! I’ll accept the charges. Of course, we had to try calling it collect. From tuhs at tuhs.org Thu Sep 17 06:19:30 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Wed, 16 Sep 2026 15:19:30 -0500 Subject: [TUHS] v6 draws and speaks and now it's available to you Message-ID: <1bb7cab5-1f1e-4a35-a901-e7f4f3caaf2f@gmail.com> Hi all, I put up a repo on github with the full process of developing the endpoints along with a bunch or provenance and traces of the exploration. With a little bit of ingenuity and understanding and a lot of AI power directed at reverse engineering and grunt work, the result is a slight tweak to simh to provide the endpoints - one for graphics primitives over /dev/vt and the other for speech synthesis over /dev/vs. Neither is technically a device so much as an endpoint for the device byte streams interpretation (graphic commands needing to be displayed on a VT01 or speech commands - phonemes, inflections, etc needing to be "spoken" by a Votrax). OpenSIMH conveniently supplies two abstractions that make it painless - an XY plotting screen device and an SDL audio interface, both were leveraged in the work. My main commitment was that v6 wouldn't know or care about the implementation, it would simply run mkconf and tweak low.s (cuz vs was very special), create special devices, build speak, plot, etc. just as would have been required with the original distribution. Here's the summary announcement: https://decuser.github.io/posts/v6-basic-with-graphics-and-speak/ And the repo: https://github.com/decuser/v6vtvs From tuhs at tuhs.org Thu Sep 17 08:55:31 2026 From: tuhs at tuhs.org (Jay Logue via TUHS) Date: Wed, 16 Sep 2026 15:55:31 -0700 Subject: [TUHS] v6 draws and speaks and now it's available to you In-Reply-To: <1bb7cab5-1f1e-4a35-a901-e7f4f3caaf2f@gmail.com> References: <1bb7cab5-1f1e-4a35-a901-e7f4f3caaf2f@gmail.com> Message-ID: This is awesome, Will.  Thanks for putting this together.  Are there any plans to upstream changes to the OpenSIMH project? The speech seems a little more chopped than other Votrax output I've heard (e.g. "two" sounds like "ooo").  Is that accurate for devices of this era? Of course, glancing over the source tree, my mind immediately goes to "How can I port the back end to run on a UniBone and drive this from Mini-Unix on my 11/05?" :) Then I remind myself I have too many projects already. Jay On 9/16/26 13:19, Will Senn via TUHS wrote: > Hi all, > > I put up a repo on github with the full process of developing the > endpoints along with a bunch or provenance and traces of the > exploration. With a little bit of ingenuity and understanding and a > lot of AI power directed at reverse engineering and grunt work, the > result is a slight tweak to simh to provide the endpoints - one for > graphics primitives over /dev/vt and the other for speech synthesis > over /dev/vs. Neither is technically a device so much as an endpoint > for the device byte streams interpretation (graphic commands needing > to be displayed on a VT01 or speech commands - phonemes, inflections, > etc needing to be "spoken" by a Votrax). OpenSIMH conveniently > supplies two abstractions that make it painless - an XY plotting > screen device and an SDL audio interface, both were leveraged in the > work. > > My main commitment was that v6 wouldn't know or care about the > implementation, it would simply run mkconf and tweak low.s (cuz vs was > very special), create special devices, build speak, plot, etc. just as > would have been required with the original distribution. > > Here's the summary announcement: > > https://decuser.github.io/posts/v6-basic-with-graphics-and-speak/ > > And the repo: > > https://github.com/decuser/v6vtvs > > > From tuhs at tuhs.org Thu Sep 17 11:08:21 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Wed, 16 Sep 2026 20:08:21 -0500 Subject: [TUHS] v6 draws and speaks and now it's available to you In-Reply-To: References: <1bb7cab5-1f1e-4a35-a901-e7f4f3caaf2f@gmail.com> Message-ID: Hi Jay, Thanks! Call me timid on suggesting SIMH changes. Yes, it does what I want it to, and likely what other V6 folks would want too, but the RSTS/TOPS/etc. folks maybe not. It isn't really general. Both the VT01 endpoint and the Votrax endpoint are more than devices in my implementation. They're translators standing in for whatever server/device combinations Bell Labs had in operation—likely a PDP-11/20 with a VT01 attached in one case, and something with the Votrax connected in the other—listening over parallel and serial interfaces respectively for these byte streams. I basically black-boxed those service mechanics and translated the streams into the appropriate realization: XY plot commands for graphics, and SC-01 phonemes/inflections rendered to SDL PCM for speech. That's based on my reconstruction of the protocols and what the sparse source, manpages, and related material imply those services had to do. The graphics side is comparatively easy to validate. Yes, the XY display is clearer than an actual VT01 would have been, but the conversion is principled: analog deflections become discrete plotted points. The service could have been working from the same ideal coordinates even though the physical realization would differ. I'm pretty happy with that result. Speech is much knottier. I compared mine with the 1980 Votrax recording on Wikipedia and at least convinced myself that it's recognizably the same sort of voice. My ruleset comes from Diomidis Spinellis's reconstruction in speak.v/speak.c, while my output mapping targets the SC-01A, which is later than the Votrax hardware Bell Labs would have had. There is also an unavoidable mapping between different-sized phoneme spaces: Doug McIlroy's V6 rules on one side and the later Votrax inventory on the other. Any of those could account for artifacts such as the chopped "two." I'm not an expert in speech synthesis. I know enough language and linguistics to reason about what I'm seeing, but not at the same level as someone who works in synthesis. Diomidis has done work on this as well, from more of a reconstruction/modernization angle, and I think there's probably real value in comparing the two approaches and seeing where they converge. Mine is more naive in some respects, but independently arriving at similar results is useful evidence. As for the UniBone: yes, that is exactly the sort of thought this stuff provokes. :) Will On 9/16/26 5:55 PM, Jay Logue wrote: > This is awesome, Will.  Thanks for putting this together.  Are there > any plans to upstream changes to the OpenSIMH project? > > The speech seems a little more chopped than other Votrax output I've > heard (e.g. "two" sounds like "ooo").  Is that accurate for devices of > this era? > > Of course, glancing over the source tree, my mind immediately goes to > "How can I port the back end to run on a UniBone and drive this from > Mini-Unix on my 11/05?" :) > > Then I remind myself I have too many projects already. > > Jay > > On 9/16/26 13:19, Will Senn via TUHS wrote: >> Hi all, >> >> I put up a repo on github with the full process of developing the >> endpoints along with a bunch or provenance and traces of the >> exploration. With a little bit of ingenuity and understanding and a >> lot of AI power directed at reverse engineering and grunt work, the >> result is a slight tweak to simh to provide the endpoints - one for >> graphics primitives over /dev/vt and the other for speech synthesis >> over /dev/vs. Neither is technically a device so much as an endpoint >> for the device byte streams interpretation (graphic commands needing >> to be displayed on a VT01 or speech commands - phonemes, inflections, >> etc needing to be "spoken" by a Votrax). OpenSIMH conveniently >> supplies two abstractions that make it painless - an XY plotting >> screen device and an SDL audio interface, both were leveraged in the >> work. >> >> My main commitment was that v6 wouldn't know or care about the >> implementation, it would simply run mkconf and tweak low.s (cuz vs >> was very special), create special devices, build speak, plot, etc. >> just as would have been required with the original distribution. >> >> Here's the summary announcement: >> >> https://decuser.github.io/posts/v6-basic-with-graphics-and-speak/ >> >> And the repo: >> >> https://github.com/decuser/v6vtvs >> >> >> > From tuhs at tuhs.org Thu Sep 17 11:13:12 2026 From: tuhs at tuhs.org (G. Branden Robinson via TUHS) Date: Wed, 16 Sep 2026 20:13:12 -0500 Subject: [TUHS] v6 draws and speaks and now it's available to you In-Reply-To: References: <1bb7cab5-1f1e-4a35-a901-e7f4f3caaf2f@gmail.com> Message-ID: <20260917011312.ov5cxp5dvctyfhh3@illithid> At 2026-09-16T15:55:31-0700, Jay Logue via TUHS wrote: > The speech seems a little more chopped than other Votrax output I've > heard (e.g. "two" sounds like "ooo").  Is that accurate for devices of > this era? It sounds like the same voice synthesis as used by _Gorf_ (the upright arcade cabinet) to me. But I agree that initial consonants seem clipped. I think Will said earlier in the thread that he thought the sound was harsher than he remembered. It occurred to me that the straight, authentic waveform, put through a high-fidelity DAC like we have these days, might be the culprit. Squarish waves do funny things when connected to speaker cabinets. It's possible that the speaker the Votrax used, if it came with one, or the sort it was typically connected to otherwise, had physical or electromagnetic properties that "rounded off" the sound considerably. I would never have believed that "speaker cabinet modeling" was in any way an important thing until I had an awakening experience playing guitar with a bunch of musicians who were also Rush fans. My amp was too feeble for the room, a problem that was solved by running my amp straight into the mixing desk. When it was time for me to play my part, the bit at 5:45 in "Cygnus X-1", what hit everyone in the room smack in the face sounded more like...Exodus. I'm sure I'd have found that hysterical if it weren't so mortifying. Anyway, the Votrax signal might need some shaping. Maybe a proper audio production engineer can help. Regards, Branden -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tuhs at tuhs.org Thu Sep 17 23:10:02 2026 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Thu, 17 Sep 2026 15:10:02 +0200 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> Message-ID: <7E309CEC-B263-4993-9F23-A7EF9692F8AC@agercasa.nl> I do have the CD that usenix public with that had this (and other music stuff) on it somewhere > Edie and Eddie were a blast, as was the rest of the Redphone system. The thing answered the phone… > > Bell Communications Research > (long pause) > Yes, Operator! I’ll accept the charges. > > Of course, we had to try calling it collect. Being on the receiving end of the redphone tests I once got the number to dial the first version of this. I complained that it was fun but, given I was on another continent and the time to took to listen all it, it was a bit hard on the phone bill. The reaction was, try again, and then it started with the Yes operator bit, jaap From tuhs at tuhs.org Thu Sep 17 23:19:55 2026 From: tuhs at tuhs.org (Jaap Akkerhuis via TUHS) Date: Thu, 17 Sep 2026 15:19:55 +0200 Subject: [TUHS] speak and speech synthesis In-Reply-To: <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> References: <848095c3-5cf3-46a2-9f71-7e9a85343ac7@gmail.com> <1ce27985-c581-484a-a93a-fbb81a629651@Julf.com> Message-ID: > I always remember Peter Langston's "Eddie & Eedie and reggaebots", > (as featured on the CD that came with the USENIX Computing Systems > special on computer music. Note that the Eddie and Eedie was part of the experiment trying to have two DECtalks sing in harmony. jaap From tuhs at tuhs.org Fri Sep 18 00:23:46 2026 From: tuhs at tuhs.org (William Cheswick via TUHS) Date: Thu, 17 Sep 2026 10:23:46 -0400 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: Message-ID: > On Sep 15, 2026, at 7:22 AM, Douglas McIlroy via TUHS wrote: > >> Also, Doug, you wrote technical report 14, which seems canonical about >> how speak worked. Is that the best source you or anyone else knows of >> vis a vis v6's implementation? > > That''s the only documentation I know of. I also have C source and > driver tables for > several points in time. I cam pass them to tuhs if needed. > > Doug I am still hoping that the Disney stoplist of bad words shows up. From tuhs at tuhs.org Fri Sep 18 01:01:02 2026 From: tuhs at tuhs.org (Douglas McIlroy via TUHS) Date: Thu, 17 Sep 2026 11:01:02 -0400 Subject: [TUHS] speak and speech synthesis Message-ID: Clipped consonants, not necessarily initial, were always a problem. They made many single-word Votrax utterances unintelligible. One of my favorite examples was cheek, chief, cheat, cheap which which was essentially indistinguishable from cheep, cheep, cheep, cheep Another favorite bad example was a list of composers. Failure there was due to the pronunciation rules' ignorance of foreign names. Bach, Brahms, Beethoven, Respighi, Tchaikowsky came out Batch, Brams, Beet Oven, Ress Spy E, Chay Kowsky Doug From tuhs at tuhs.org Fri Sep 18 01:25:27 2026 From: tuhs at tuhs.org (Wendt Alan via TUHS) Date: Thu, 17 Sep 2026 08:25:27 -0700 Subject: [TUHS] https://www.usenet-rewind.com/ Message-ID: This site is archiving and searchable for all usenet posts back to 1981. I was able to find two of my favorite posts pretty fast, a poem about the Village Moose and an article entitled Town Deals With Alien Donuts. Alan Wendt From tuhs at tuhs.org Fri Sep 18 01:27:58 2026 From: tuhs at tuhs.org (Marco Moock via TUHS) Date: Thu, 17 Sep 2026 17:27:58 +0200 Subject: [TUHS] https://www.usenet-rewind.com/ In-Reply-To: References: Message-ID: Am 17.09.26 um 17:25 schrieb Wendt Alan via TUHS: > This site is archiving and searchable for all usenet posts back to 1981. Also current ones? -- Gruß Marco Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri Sep 18 01:38:26 2026 From: tuhs at tuhs.org (Wendt Alan via TUHS) Date: Thu, 17 Sep 2026 08:38:26 -0700 Subject: [TUHS] https://www.usenet-rewind.com/ In-Reply-To: References: Message-ID: Yes On Thu, Sep 17, 2026 at 8:35 AM Marco Moock via TUHS wrote: > > Am 17.09.26 um 17:25 schrieb Wendt Alan via TUHS: > > This site is archiving and searchable for all usenet posts back to 1981. > > Also current ones? > > > -- > Gruß > Marco > > Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de From tuhs at tuhs.org Fri Sep 18 03:52:55 2026 From: tuhs at tuhs.org (Ron Natalie via TUHS) Date: Thu, 17 Sep 2026 17:52:55 +0000 Subject: [TUHS] https://www.usenet-rewind.com/ In-Reply-To: References: Message-ID: There’s one there from me asking about a TI-960 assembler dated Dec 27, 1981. That was while I was still working for Martin Marietta (prior to going back to BRL), though that one might be a crosspost from the UNIX-WIZARDS mailing list. ------ Original Message ------ >From "Wendt Alan via TUHS" To tuhs at tuhs.org Date 9/17/2026 11:25:27 AM Subject [TUHS] https://www.usenet-rewind.com/ >This site is archiving and searchable for all usenet posts back to 1981. > >I was able to find two of my favorite posts pretty fast, a poem about >the Village Moose >and an article entitled Town Deals With Alien Donuts. > >Alan Wendt From tuhs at tuhs.org Fri Sep 18 05:48:31 2026 From: tuhs at tuhs.org (Marco Moock via TUHS) Date: Thu, 17 Sep 2026 21:48:31 +0200 Subject: [TUHS] https://www.usenet-rewind.com/ In-Reply-To: References: Message-ID: <8d1d22cf-9c60-41b4-8ee8-2d1f80a735b6@dorfdsl.de> Am 17.09.26 um 17:25 schrieb Wendt Alan via TUHS: > This site is archiving and searchable for all usenet posts back to 1981. We (the big 8 Usenet management board) added that to our website. Hopefully this archive stays a long time. -- Gruß Marco Muell und Spam bitte an abfalleimer2002 at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From tuhs at tuhs.org Fri Sep 18 13:28:54 2026 From: tuhs at tuhs.org (Rob Pike via TUHS) Date: Fri, 18 Sep 2026 13:28:54 +1000 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: Message-ID: So many examples. Quinlan became Finland, for example. Ultraviolet had a long 'a', infrared sounded as a past participle. I enjoyed typing unpronounceable sequences of letters to it, such as lfvbm (all labials) and seeing what happened. I forget the sequence that got it to whistle but we did make Kernighan sound even stranger than most strangers mangle it by putting a chirp on the tail. -rob On Fri, Sep 18, 2026 at 1:01 AM Douglas McIlroy via TUHS wrote: > Clipped consonants, not necessarily initial, were always a problem. > They made many single-word Votrax utterances unintelligible. One of my > favorite examples was > cheek, chief, cheat, cheap > which which was essentially indistinguishable from > cheep, cheep, cheep, cheep > > Another favorite bad example was a list of composers. Failure there > was due to the pronunciation rules' ignorance of foreign names. > Bach, Brahms, Beethoven, Respighi, Tchaikowsky > came out > Batch, Brams, Beet Oven, Ress Spy E, Chay Kowsky > > Doug > From tuhs at tuhs.org Fri Sep 18 14:15:41 2026 From: tuhs at tuhs.org (Peter Yardley via TUHS) Date: Fri, 18 Sep 2026 14:15:41 +1000 Subject: [TUHS] speak and speech synthesis In-Reply-To: References: Message-ID: One of my friends initials, the name he went by, was SBG. The text to speech pronounced that as Spug. So he was known as Spug ever after. Sent from my iPhone > On 18 Sep 2026, at 1:29 pm, Rob Pike via TUHS wrote: > > So many examples. Quinlan became Finland, for example. Ultraviolet had a > long 'a', infrared sounded as a past participle. > > I enjoyed typing unpronounceable sequences of letters to it, such as lfvbm > (all labials) and seeing what happened. I forget the sequence that got it > to whistle but we did make Kernighan sound even stranger than most > strangers mangle it by putting a chirp on the tail. > > -rob > > >> On Fri, Sep 18, 2026 at 1:01 AM Douglas McIlroy via TUHS >> wrote: >> >> Clipped consonants, not necessarily initial, were always a problem. >> They made many single-word Votrax utterances unintelligible. One of my >> favorite examples was >> cheek, chief, cheat, cheap >> which which was essentially indistinguishable from >> cheep, cheep, cheep, cheep >> >> Another favorite bad example was a list of composers. Failure there >> was due to the pronunciation rules' ignorance of foreign names. >> Bach, Brahms, Beethoven, Respighi, Tchaikowsky >> came out >> Batch, Brams, Beet Oven, Ress Spy E, Chay Kowsky >> >> Doug >> From tuhs at tuhs.org Sat Sep 19 08:25:17 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 18 Sep 2026 17:25:17 -0500 Subject: [TUHS] berkeley unix version hosting Doug Cooper's Standard Pascal Environment Message-ID: Hi all, My algol60 dive took me into uncharted (for me) waters. It was fun, but eventually I tacked back and came across, Oh! Pascal!, a recommendation I believe Clem gave me. Well, interestingly enough, but not directly unix related, the code in that book runs with fpc -Miso, meaning the free pascal compiler with the iso option for 7185. So, I'm covered on running it in the modern world, but as usual, I'd prefer to run it like it was run back when, on a system that might have been used, at the time to work through the book. My first step back from today took me to 211bsd, it has a reasonable environment, has pi and px and oughtta work, but... it doesn't really. It'll do basic stuff, sure. But it lacks pc and a more complete compiler, particularly function as argument: program FunctionArgumentDemo; function Square(x: integer): integer; begin   Square := x * x end; function Cube(x: integer): integer; begin   Cube := x * x * x end; function Apply(function f(x: integer): integer;                value: integer): integer; begin   Apply := f(value) end; begin   writeln(Apply(Square, 5));   writeln(Apply(Cube, 3)) end. # pi -s arg.p      1  program FunctionArgumentDemo; E ----------------------------------^--- Expected '('     13      function Apply(function f(x: integer): integer; e -----------------------------------^--- Replaced '(' with a ',' E 13 - Procedure/function parameters not implemented Which is reasonable, turbo pascal 3 didn't have function arguments, but Standard Pascal iso 7185 supports it... I want it :). So, my question is, does this ring a bell for anyone? ChatGPT seems to think that a VAX 4.1 might be in use around the '82-'85 timeline of the 1st and 2nd edition. Cooper references quite a rarified list of folks in the preface to the 82 edition, so I'm inclined to think he had access to what was current at Berkeley at the time (he calls McKusick one of the "Kompiler Kids"). From tuhs at tuhs.org Sat Sep 19 09:08:21 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 18 Sep 2026 18:08:21 -0500 Subject: [TUHS] berkeley unix version hosting Doug Cooper's Standard Pascal Environment In-Reply-To: References: Message-ID: <03796d42-1be8-4c6b-93f1-4d9264eb5108@gmail.com> All, 4.2 works just fine and is reasonable if not precisely the machine in use. Thanks, Will On 9/18/26 5:25 PM, Will Senn wrote: > Hi all, > > My algol60 dive took me into uncharted (for me) waters. It was fun, > but eventually I tacked back and came across, Oh! Pascal!, a > recommendation I believe Clem gave me. Well, interestingly enough, but > not directly unix related, the code in that book runs with fpc -Miso, > meaning the free pascal compiler with the iso option for 7185. So, I'm > covered on running it in the modern world, but as usual, I'd prefer to > run it like it was run back when, on a system that might have been > used, at the time to work through the book. > > My first step back from today took me to 211bsd, it has a reasonable > environment, has pi and px and oughtta work, but... it doesn't really. > It'll do basic stuff, sure. But it lacks pc and a more complete > compiler, particularly function as argument: > > program FunctionArgumentDemo; > > function Square(x: integer): integer; > begin >   Square := x * x > end; > > function Cube(x: integer): integer; > begin >   Cube := x * x * x > end; > > function Apply(function f(x: integer): integer; >                value: integer): integer; > begin >   Apply := f(value) > end; > > begin >   writeln(Apply(Square, 5)); >   writeln(Apply(Cube, 3)) > end. > > # pi -s arg.p >      1  program FunctionArgumentDemo; > E ----------------------------------^--- Expected '(' >     13      function Apply(function f(x: integer): integer; > e -----------------------------------^--- Replaced '(' with a ',' > E 13 - Procedure/function parameters not implemented > > Which is reasonable, turbo pascal 3 didn't have function arguments, > but Standard Pascal iso 7185 supports it... I want it :). > > So, my question is, does this ring a bell for anyone? ChatGPT seems to > think that a VAX 4.1 might be in use around the '82-'85 timeline of > the 1st and 2nd edition. > > Cooper references quite a rarified list of folks in the preface to the > 82 edition, so I'm inclined to think he had access to what was current > at Berkeley at the time (he calls McKusick one of the "Kompiler Kids"). > From tuhs at tuhs.org Sat Sep 19 12:38:46 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Fri, 18 Sep 2026 22:38:46 -0400 Subject: [TUHS] berkeley unix version hosting Doug Cooper's Standard Pascal Environment In-Reply-To: References: Message-ID: When we taught CS40 in 1982 I want to say that it was still the first edition of Oh Pascal (which I still content is the best introduction to >>programing<< I know). Mike and Doug did a super job with it. In my mind, the fact that they are using Pascal is secondary to their method of how to think about and write real programs. At that time our students were using the Cory Hall 11/70, which was V7+2BSD and the Pascal implementation would have been close to what is on the 2BSD tape. And yes, Kirk and Joy had been students of Sue Graham. IIRC Joy took the original Ken Thompson code and extended it. Kirk retargeted it the vax. By that time the Vaxes had taken over for the grad students, with Ernie being the primary system running 4.1BSD. 4.1A,B,C are still a few years away. But the Berkeley Pascal system was in heavy development by Sue's students. There was probably a divergence of features from what was on Cory and what was on Ernie from a Pascal standard. For instance Mark Linton was working on his thesis which became dbx and pdx (and was what the Gnu folks started with for the later gdb). Also remember the original book and compilation suite was before either BS6192 (British Pascal Standard of 1982) or ISO Pascal which was at least a year or two later. FWIW: My memory is hazy as to when pc showed up. It would have had to have been a few years after Johnson's PCC was at UCB since it used the PCC code generator and libc, although it had its own libpc which supported Pascal I/O semantics that then called into the C runtime. Note: our students used pi/pix. But the autocorrect stuff in the front end (which was a bad idea in practice) was already there, which I have talked about in other messages. Clem Sent from a handheld expect more typos than usual On Fri, Sep 18, 2026 at 6:24 PM Will Senn via TUHS wrote: > Hi all, > > My algol60 dive took me into uncharted (for me) waters. It was fun, but > eventually I tacked back and came across, Oh! Pascal!, a recommendation > I believe Clem gave me. Well, interestingly enough, but not directly > unix related, the code in that book runs with fpc -Miso, meaning the > free pascal compiler with the iso option for 7185. So, I'm covered on > running it in the modern world, but as usual, I'd prefer to run it like > it was run back when, on a system that might have been used, at the time > to work through the book. > > My first step back from today took me to 211bsd, it has a reasonable > environment, has pi and px and oughtta work, but... it doesn't really. > It'll do basic stuff, sure. But it lacks pc and a more complete > compiler, particularly function as argument: > > program FunctionArgumentDemo; > > function Square(x: integer): integer; > begin > Square := x * x > end; > > function Cube(x: integer): integer; > begin > Cube := x * x * x > end; > > function Apply(function f(x: integer): integer; > value: integer): integer; > begin > Apply := f(value) > end; > > begin > writeln(Apply(Square, 5)); > writeln(Apply(Cube, 3)) > end. > > # pi -s arg.p > 1 program FunctionArgumentDemo; > E ----------------------------------^--- Expected '(' > 13 function Apply(function f(x: integer): integer; > e -----------------------------------^--- Replaced '(' with a ',' > E 13 - Procedure/function parameters not implemented > > Which is reasonable, turbo pascal 3 didn't have function arguments, but > Standard Pascal iso 7185 supports it... I want it :). > > So, my question is, does this ring a bell for anyone? ChatGPT seems to > think that a VAX 4.1 might be in use around the '82-'85 timeline of the > 1st and 2nd edition. > > Cooper references quite a rarified list of folks in the preface to the > 82 edition, so I'm inclined to think he had access to what was current > at Berkeley at the time (he calls McKusick one of the "Kompiler Kids"). > > From tuhs at tuhs.org Sat Sep 19 13:25:20 2026 From: tuhs at tuhs.org (Will Senn via TUHS) Date: Fri, 18 Sep 2026 22:25:20 -0500 Subject: [TUHS] berkeley unix version hosting Doug Cooper's Standard Pascal Environment In-Reply-To: References: Message-ID: <4f607f31-547a-4a50-b2a5-97662c09ea31@gmail.com> Fascinating. I have a first edition (9th printing) and second edition (3rd printing) from 82 and 85 respectively. The first edition preface says: Every program and most subprograms, have been run without error or warning messages using the -s option (Standard Pascal only) of the Berkeley Pascal compiler (pc) and interpreter (pi). All program output displayed was produced by the actual source programs shown in the text as it was being typeset.  All examples and definitions conform to the Draft ANSI/IEEE Pascal Standard (X3J9/81-093). Then, in the second edition, in the Preface to the First Edition, it says: Every program and most subprograms, have been run without error or warning messages using the -s option (Standard Pascal only) of the Berkeley Pascal compiler (pc) and interpreter (pi). All program output displayed was produced by the actual source programs shown in the text as it was being typeset.  All examples and definitions conform to the ISO and ANSI Pascal standards. This is funny, cuz usually when you include a preface from a prior edition, you keep it verbatim. Regardless, I confirmed the function argument program runs in both 4.2BSD and 4.3BSD. Will On 9/18/26 9:38 PM, Clem Cole wrote: > When we taught CS40 in 1982 I want to say that it was still the first > edition of Oh Pascal (which I still content is the best introduction > to >>programing<< I know).  Mike and Doug did a super job with it.  In > my mind, the fact that they are using Pascal is secondary to their > method of how to think about and write real programs. > > > At that time our students were using the Cory Hall 11/70, which was > V7+2BSD and the Pascal implementation would have been close to what >  is on the 2BSD tape.  And yes, Kirk and Joy had been students of Sue > Graham. IIRC Joy took the original Ken Thompson code and extended it. > Kirk retargeted it the vax. > > By that time the Vaxes had taken over for the grad students, with > Ernie being the primary system running 4.1BSD.   4.1A,B,C are still a > few years away.    But the Berkeley Pascal system was in heavy > development by Sue's students.  There was probably a divergence of > features fromwhat was on Cory and what was on Ernie from a Pascal > standard.   For instance Mark Linton was working on his thesis which > became dbx and pdx (and was what the Gnu folks started with for the > later gdb). > > Also remember the original book and  compilation suite was before > either BS6192 (British Pascal Standard of 1982) or ISO Pascal which > was at least a year or two later. > > FWIW: My memory is hazy as to when pc showed up.  It would have had to > have been a few years after Johnson's PCC was at UCB since it used the > PCC code generator and libc, although it had its own libpc which > supported Pascal I/O semantics that then called into the C runtime. > > Note: our students used pi/pix. But the autocorrect stuff in the front > end (which was a bad idea in practice) was already there, which I have > talked about in other messages. > > Clem > > > Sent from a handheld expect more typos than usual > > On Fri, Sep 18, 2026 at 6:24 PM Will Senn via TUHS wrote: > > Hi all, > > My algol60 dive took me into uncharted (for me) waters. It was > fun, but > eventually I tacked back and came across, Oh! Pascal!, a > recommendation > I believe Clem gave me. Well, interestingly enough, but not directly > unix related, the code in that book runs with fpc -Miso, meaning the > free pascal compiler with the iso option for 7185. So, I'm covered on > running it in the modern world, but as usual, I'd prefer to run it > like > it was run back when, on a system that might have been used, at > the time > to work through the book. > > My first step back from today took me to 211bsd, it has a reasonable > environment, has pi and px and oughtta work, but... it doesn't > really. > It'll do basic stuff, sure. But it lacks pc and a more complete > compiler, particularly function as argument: > > program FunctionArgumentDemo; > > function Square(x: integer): integer; > begin >    Square := x * x > end; > > function Cube(x: integer): integer; > begin >    Cube := x * x * x > end; > > function Apply(function f(x: integer): integer; >                 value: integer): integer; > begin >    Apply := f(value) > end; > > begin >    writeln(Apply(Square, 5)); >    writeln(Apply(Cube, 3)) > end. > > # pi -s arg.p >       1  program FunctionArgumentDemo; > E ----------------------------------^--- Expected '(' >      13      function Apply(function f(x: integer): integer; > e -----------------------------------^--- Replaced '(' with a ',' > E 13 - Procedure/function parameters not implemented > > Which is reasonable, turbo pascal 3 didn't have function > arguments, but > Standard Pascal iso 7185 supports it... I want it :). > > So, my question is, does this ring a bell for anyone? ChatGPT > seems to > think that a VAX 4.1 might be in use around the '82-'85 timeline > of the > 1st and 2nd edition. > > Cooper references quite a rarified list of folks in the preface to > the > 82 edition, so I'm inclined to think he had access to what was > current > at Berkeley at the time (he calls McKusick one of the "Kompiler > Kids"). > From tuhs at tuhs.org Sat Sep 19 13:47:26 2026 From: tuhs at tuhs.org (Eric E. Bowles via TUHS) Date: Sat, 19 Sep 2026 12:47:26 +0900 Subject: [TUHS] berkeley unix version hosting Doug Cooper's Standard Pascal Environment In-Reply-To: References: Message-ID: I took CS50 in 1985 and we used Oh! Pascal! as a textbook; I don't recall whether it was the first or second edition. I still remember being irritated that "programming" was spelled with a singular "m". We did use pc (and pi/pix) in class. From the pc(1) man page, HISTORY: "The pc appeared in 4.0BSD." --eric > On Sep 19, 2026, at 11:38, Clem Cole via TUHS wrote: > > When we taught CS40 in 1982 I want to say that it was still the first > edition of Oh Pascal (which I still content is the best introduction to >>> programing<< I know). Mike and Doug did a super job with it. In my > mind, the fact that they are using Pascal is secondary to their method of > how to think about and write real programs. > > > At that time our students were using the Cory Hall 11/70, which was V7+2BSD > and the Pascal implementation would have been close to what is on the 2BSD > tape. And yes, Kirk and Joy had been students of Sue Graham. IIRC Joy took > the original Ken Thompson code and extended it. Kirk retargeted it the vax. > > By that time the Vaxes had taken over for the grad students, with Ernie > being the primary system running 4.1BSD. 4.1A,B,C are still a few years > away. But the Berkeley Pascal system was in heavy development by Sue's > students. There was probably a divergence of features from what was on > Cory and what was on Ernie from a Pascal standard. For instance Mark > Linton was working on his thesis which became dbx and pdx (and was what the > Gnu folks started with for the later gdb). > > Also remember the original book and compilation suite was before either > BS6192 (British Pascal Standard of 1982) or ISO Pascal which was at least a > year or two later. > > FWIW: My memory is hazy as to when pc showed up. It would have had to have > been a few years after Johnson's PCC was at UCB since it used the PCC code > generator and libc, although it had its own libpc which supported Pascal > I/O semantics that then called into the C runtime. > > Note: our students used pi/pix. But the autocorrect stuff in the front end > (which was a bad idea in practice) was already there, which I have talked > about in other messages. > > Clem > > > Sent from a handheld expect more typos than usual > > On Fri, Sep 18, 2026 at 6:24 PM Will Senn via TUHS wrote: > >> Hi all, >> >> My algol60 dive took me into uncharted (for me) waters. It was fun, but >> eventually I tacked back and came across, Oh! Pascal!, a recommendation >> I believe Clem gave me. Well, interestingly enough, but not directly >> unix related, the code in that book runs with fpc -Miso, meaning the >> free pascal compiler with the iso option for 7185. So, I'm covered on >> running it in the modern world, but as usual, I'd prefer to run it like >> it was run back when, on a system that might have been used, at the time >> to work through the book. >> >> My first step back from today took me to 211bsd, it has a reasonable >> environment, has pi and px and oughtta work, but... it doesn't really. >> It'll do basic stuff, sure. But it lacks pc and a more complete >> compiler, particularly function as argument: >> >> program FunctionArgumentDemo; >> >> function Square(x: integer): integer; >> begin >> Square := x * x >> end; >> >> function Cube(x: integer): integer; >> begin >> Cube := x * x * x >> end; >> >> function Apply(function f(x: integer): integer; >> value: integer): integer; >> begin >> Apply := f(value) >> end; >> >> begin >> writeln(Apply(Square, 5)); >> writeln(Apply(Cube, 3)) >> end. >> >> # pi -s arg.p >> 1 program FunctionArgumentDemo; >> E ----------------------------------^--- Expected '(' >> 13 function Apply(function f(x: integer): integer; >> e -----------------------------------^--- Replaced '(' with a ',' >> E 13 - Procedure/function parameters not implemented >> >> Which is reasonable, turbo pascal 3 didn't have function arguments, but >> Standard Pascal iso 7185 supports it... I want it :). >> >> So, my question is, does this ring a bell for anyone? ChatGPT seems to >> think that a VAX 4.1 might be in use around the '82-'85 timeline of the >> 1st and 2nd edition. >> >> Cooper references quite a rarified list of folks in the preface to the >> 82 edition, so I'm inclined to think he had access to what was current >> at Berkeley at the time (he calls McKusick one of the "Kompiler Kids"). >> >> From tuhs at tuhs.org Sat Sep 19 14:14:47 2026 From: tuhs at tuhs.org (Clem Cole via TUHS) Date: Sat, 19 Sep 2026 00:14:47 -0400 Subject: [TUHS] berkeley unix version hosting Doug Cooper's Standard Pascal Environment In-Reply-To: <4f607f31-547a-4a50-b2a5-97662c09ea31@gmail.com> References: <4f607f31-547a-4a50-b2a5-97662c09ea31@gmail.com> Message-ID: Since PCC hit the streets as part of V7 in 1979, one of Sue's students started to create pc after that, but I don't remember who. But 1982 works out that it was around for the first edition. But it does mean that it was likely done on the PDP-11 version. As I said I don't remember using it which is why I don't remember its status. The only memory I really have of it, ISTR that to use Mark's pdx, that required pc; not pi/pix. But dbx/pdx was still very much in its infancy and was started on Ernie under 4.1. Mark didn't finish them until after I had left. I think they are in 4.2BSD, but they are less likely to be in 4.1A,B,C. Glad you have it working on the Vax, but given the dates it was tested and used pretty hard (daily) on PDP-11s. Given your experience with 2.11BSD, I suspect the issue is bit rot / skew in later 2.XBSD editions. My memory is that by the time of 2.8BSD and later, UCB had stopped using PDP-11s to teach the undergrads. The users of 2.8BSD and follow ons were probably less interested in the Pascal subsystem and testing was undoubtedly less. Sent from a handheld expect more typos than usual On Fri, Sep 18, 2026 at 11:24 PM Will Senn wrote: > Fascinating. I have a first edition (9th printing) and second edition (3rd > printing) from 82 and 85 respectively. The first edition preface says: > > Every program and most subprograms, have been run without error or warning > messages using the -s option (Standard Pascal only) of the Berkeley Pascal > compiler (pc) and interpreter (pi). All program output displayed was > produced by the actual source programs shown in the text as it was being > typeset. All examples and definitions conform to the Draft ANSI/IEEE > Pascal Standard (X3J9/81-093). > > Then, in the second edition, in the Preface to the First Edition, it says: > > Every program and most subprograms, have been run without error or warning > messages using the -s option (Standard Pascal only) of the Berkeley Pascal > compiler (pc) and interpreter (pi). All program output displayed was > produced by the actual source programs shown in the text as it was being > typeset. All examples and definitions conform to the ISO and ANSI Pascal > standards. > > This is funny, cuz usually when you include a preface from a prior > edition, you keep it verbatim. > > Regardless, I confirmed the function argument program runs in both 4.2BSD > and 4.3BSD. > > Will > > > > On 9/18/26 9:38 PM, Clem Cole wrote: > > When we taught CS40 in 1982 I want to say that it was still the first > edition of Oh Pascal (which I still content is the best introduction to > >>programing<< I know). Mike and Doug did a super job with it. In my > mind, the fact that they are using Pascal is secondary to their method of > how to think about and write real programs. > > > At that time our students were using the Cory Hall 11/70, which was > V7+2BSD and the Pascal implementation would have been close to what is on > the 2BSD tape. And yes, Kirk and Joy had been students of Sue Graham. IIRC > Joy took the original Ken Thompson code and extended it. Kirk retargeted it > the vax. > > By that time the Vaxes had taken over for the grad students, with Ernie > being the primary system running 4.1BSD. 4.1A,B,C are still a few years > away. But the Berkeley Pascal system was in heavy development by Sue's > students. There was probably a divergence of features from what was on > Cory and what was on Ernie from a Pascal standard. For instance Mark > Linton was working on his thesis which became dbx and pdx (and was what the > Gnu folks started with for the later gdb). > > Also remember the original book and compilation suite was before either > BS6192 (British Pascal Standard of 1982) or ISO Pascal which was at least a > year or two later. > > FWIW: My memory is hazy as to when pc showed up. It would have had to > have been a few years after Johnson's PCC was at UCB since it used the PCC > code generator and libc, although it had its own libpc which supported > Pascal I/O semantics that then called into the C runtime. > > Note: our students used pi/pix. But the autocorrect stuff in the front end > (which was a bad idea in practice) was already there, which I have talked > about in other messages. > > Clem > > > Sent from a handheld expect more typos than usual > > On Fri, Sep 18, 2026 at 6:24 PM Will Senn via TUHS wrote: > >> Hi all, >> >> My algol60 dive took me into uncharted (for me) waters. It was fun, but >> eventually I tacked back and came across, Oh! Pascal!, a recommendation >> I believe Clem gave me. Well, interestingly enough, but not directly >> unix related, the code in that book runs with fpc -Miso, meaning the >> free pascal compiler with the iso option for 7185. So, I'm covered on >> running it in the modern world, but as usual, I'd prefer to run it like >> it was run back when, on a system that might have been used, at the time >> to work through the book. >> >> My first step back from today took me to 211bsd, it has a reasonable >> environment, has pi and px and oughtta work, but... it doesn't really. >> It'll do basic stuff, sure. But it lacks pc and a more complete >> compiler, particularly function as argument: >> >> program FunctionArgumentDemo; >> >> function Square(x: integer): integer; >> begin >> Square := x * x >> end; >> >> function Cube(x: integer): integer; >> begin >> Cube := x * x * x >> end; >> >> function Apply(function f(x: integer): integer; >> value: integer): integer; >> begin >> Apply := f(value) >> end; >> >> begin >> writeln(Apply(Square, 5)); >> writeln(Apply(Cube, 3)) >> end. >> >> # pi -s arg.p >> 1 program FunctionArgumentDemo; >> E ----------------------------------^--- Expected '(' >> 13 function Apply(function f(x: integer): integer; >> e -----------------------------------^--- Replaced '(' with a ',' >> E 13 - Procedure/function parameters not implemented >> >> Which is reasonable, turbo pascal 3 didn't have function arguments, but >> Standard Pascal iso 7185 supports it... I want it :). >> >> So, my question is, does this ring a bell for anyone? ChatGPT seems to >> think that a VAX 4.1 might be in use around the '82-'85 timeline of the >> 1st and 2nd edition. >> >> Cooper references quite a rarified list of folks in the preface to the >> 82 edition, so I'm inclined to think he had access to what was current >> at Berkeley at the time (he calls McKusick one of the "Kompiler Kids"). >> >>