March 2023 - COFF - www.tuhs.org

Restarting 3b2/400 Network Install Unix V r3

by KenUnix

Hi. I made an error on data entry installing TCP Networking on a 3b2/400 on a SIM. Is there a way to re-start the CONFIGURATION process without having to start over from scratch re-installing the entire system? The section covering hostname,host's network number, etc. Thanks, Ken -- WWL 📚

1 month, 3 weeks

1
0
0 0

Re: [TUHS] Re: Origins of the frame buffer device

by Rob Gingell

[Redirected to COFF for some anecdotal E&S-related history and non-UNIX terminal room nostalgia.] On 3/7/23 9:43 PM, Lars Brinkhoff wrote: > Noel Chiappa wrote: >>> The first frame buffers from Evans and Sutherland were at University >>> of Utah, DOD SITES and NYIT CGL as I recall. Circa 1974 to 1978. >> >> Were those on PDP-11's, or PDP-10's? (Really early E+S gear attached to >> PDP-10's; '74-'78 sounds like an interim period.) > > The Picture System from 1974 was based on a PDP-11/05. It looks like > vector graphics rather than a frame buffer though. > > http://archive.computerhistory.org/resources/text/Evans_Sutherland/EvansSut… E&S LDS-1s used PDP-10s as their host systems. LDS-2s could at least in principle use several different hosts (including spanning a range of word sizes, e.g., a SEL-840 with 24 bit words or a 16 bit PDP-11.) The Line Drawing Systems drove calligraphic displays. No frame buffers. The early Picture Systems (like the brochure referenced by Lars) also drove calligraphic displays but did sport a line segment "refresh buffer" so that screen refreshes weren't dependent on the whole pipeline's performance. At least one heavily customized LDS-2 (described further below) produced raster output by 1974 (and likely earlier in design and testing) and had a buffer for raster refresh which exhibited some of what we think of as the functionality of a frame buffer fitting the time frame referenced by Noel for other E&S products. On 3/8/23 10:21 AM, Larry McVoy wrote: > I really miss terminal rooms. I learned so much looking over the > shoulders of more experienced people. Completely agree. They were the "playground learning" that did all of educate, build craft and community, and occasionally bestow humility. Although it completely predates frame buffer technology, the PDP-10 terminal room of the research computing environment at CWRU in the 1970s was especially remarkable as well as personally influential. All (calligraphic) graphics terminals and displays (though later a few Datapoint CRTs appeared.) There was an LDS-1 hosted on the PDP-10 and later an LDS-2 (which was co-located but not part of the PDP-10 environment.) The chair of the department, Edward (Ted) Glaser, had been recruited from MIT in 1968 and was heavily influential in guiding the graphics orientation of the facilities, and later, in the design of the customized LDS-2. Especially remarkable as he had been blind since he was 8. He had a comprehensive vision of systems and thinking about them that influenced a lot about the department's programs and research. When I arrived in 1972, I only had a fleeting overlap with the LDS-1 to experience some of its games (color wheel lorgnettes and carrier landings!). The PDP-10 was being modified for TENEX and the LDS-1 was being decommissioned. I recall a tablet and button box for LDS-1 input devices. The room was kept dimly lit with the overhead lighting off and only the glow of the displays and small wattage desk lamps. It shared the raised floor environment with the PDP-10 machine room (though was walled off from it) and so had a "quiet-loud" aura from all the white noise. The white noise cocooned you but permitted conversation and interaction with others that didn't usually disturb the uninvolved. The luxury terminals were IMLAC PDS-1s. There was a detachable switch and indicator console that could be swapped between them for debugging or if you simply liked having the blinking lights in view. When not in use for real work the IMLACs would run Space War, much to the detriment of IMLAC keyboards. They could handle pretty complex displays, like, a screen full of dense text before flicker might set in. Light pens provided pointing input. The bulk of the terminals were an array of DEC VT02s. Storage tube displays (so no animation possible), but with joysticks for pointing and interacting. There were never many VT02s made and we always believed we had the largest single collection of them. None of these had character generators. The LDS-1 and the IMLACs drew their own characters programmatically. A PDP-8/I drove the VT02s and stroked all the characters. It did it at about 2400 baud but when the 8 got busy you could perceive the drawing of the characters like a scribe on speed. If you stood way back to take in the room you could also watch the PDP-8 going around as the screens brightened momentarily as the characters/images were drawn. I was told that CWRU wrote the software for the PDP-8 and gave it to DEC, in return DEC gave CWRU $1 and the biggest line printer they sold. (The line printer did upper and lower case, and the University archivists swooned when presented with theses printed on it -- RUNOFF being akin to magic in a typewriter primitive world.) Until the Datapoint terminals arrived all the devices in the room either were computers themselves or front-ended by one. Although I only saw it happen once, the LDS-1 with it's rather intimate connection to the -10 was particularly attuned to the status of TOPS-10 and would flash "CRASH" before users could tell that something was wrong vs. just being slow. (We would later run TOPS-10 for amusement. The system had 128K words in total: 4 MA10 16K bays and 1 MD10 64K bay. TENEX needed a minimum of 80K to "operate" though it'd be misleading to describe that configuration as "running". If we lost the MD10 bay that meant no TENEX so we had a DECtape-swapping configuration of TOPS-10 for such moments because, well, a PDP-10 with 8 DECtapes twirling is pretty humorously theatrical.) All the displays (even the later Datapoints) had green or blue-green phosphors. This had the side effect that after several hours of staring at them made anything which was white look pink. This was especially pronounced in the winter in that being Cleveland it wasn't that unusual to leave to find a large deposit of seemingly psychedelic snow that hadn't been there when you went in. The LDS-2 arrived in the winter of 1973-4. It was a highly modified LDS-2 that produced raster graphics and shaded images in real-time. It was the first system to do that and was called the Case Shaded Graphics System (SGS). (E&S called it the Halftone System as it wouldn't do color in real-time. In addition to a black & white raster display, It had a 35mm movie camera, a Polaroid camera, and an RGB filter that would triple-expose each frame and so in a small way retained the charm of the lorgnettes used on the LDS-1 to make color happen but not in real-time.) It was hosted by a PDP-11/40 running RT-11. Declining memory prices helped enable the innovations in the SGS as it incorporated more memory components than the previous calligraphic systems. The graphics pipeline was extended such that after translation and clipping there was a Y-sort box that ordered the polygons from top to bottom for raster scanning followed by a Visible Surface Processor that separated hither from yon and finally a Gouraud Shader that produced the final image to a monitor or one of the cameras. Physically the system was 5 or maybe 6 bays long not including the 11/40 bay. The SGS had some teething problems after its delivery. Ivan Sutherland even came to Cleveland to work on it though he has claimed his main memory of that is the gunfire he heard from the Howard Johnson's hotel next to campus. The University was encircled by several distressed communities at the time. A "bullet hole through glass" decal appeared on the window of the SGS's camera bay to commemorate his experience. The SGS configuration was unique but a number of its elements were incorporated into later Picture Systems. It's my impression that the LDS systems were pretty "one off" and the Picture Systems became the (relative) "volume, off the shelf" product from E&S. (I'd love to read a history of all the things E&S did in that era.) By 1975-6 the SGS was being used by projects ranging from SST stress analyses to mathematicians producing videos of theoretical concepts. The exaggerated images of stresses on aircraft structures got pretty widely distributed and referenced at the time. The SGS was more of a production system used by other departments and entities rather than computer graphics research as such, in some ways its (engineering) research utility was achieved by its having existed. One student, Ben Jones, created an extended ALGOL-60 to allow programming in something other than the assembly language. As the SGS came online in 1975 the PDP-10 was being decommissioned and the calligraphic technologies associated with it vanished along with it. A couple of years later a couple of Teraks appeared and by the end of the 1970s frame buffers as we generally think of them were economically practical. That along with other processing improvements rendered the SGS obsolete and and so it was decommissioned in 1980 and donated to the Computer History Museum where I imagine it sits in storage next to a LINC-8 or the Ark of the Covenant or something. One of the SGS's bays (containing the LDS-2 Channel Control, the front of the pipeline LDS program interpreter running out of the host's memory) and the PDP-11 interface is visible via this link: https://www.computerhistory.org/collections/catalog/102691213 The bezels on the E&S bays were cosmetically like the DEC ones of the same era. They were all smoked glass so the blinking lights were visible but had to be raised if you wanted to see the identifying legends for them.

1 month, 4 weeks

1
0
0 0

Unix System V r1 -> Unix System V r3

by KenUnix

Hi, Has anyone been successful in communicating using cu or some other method to transfer files between two SIMS running Unix V ? If so I would appreciate some help. Thanks, Ken -- WWL 📚

2 months

1
0
0 0

Unix V r3 question

by KenUnix

Hi. Does anyone have the "man" pages for Basic for System-V r3? Thanks, Ken -- WWL 📚

2 months

1
0
0 0

Fortran Question for Unix System-V r3

by KenUnix

Fortran question for Unix System-5 r3. When executing fortran programs requiring input the screen will show a blank screen. After entering input anyway the program completes under Unix System V *r3*. When the same program is compiled under Unix System V *r1* it works as expected. Sounds like on Unix System V *r3* the output buffer is not being flushed. I tried re-compiling F77. No help. Fortran code follows: PROGRAM EASTER INTEGER YEAR,METCYC,CENTRY,ERROR1,ERROR2,DAY INTEGER EPACT,LUNA C A PROGRAM TO CALCULATE THE DATE OF EASTER PRINT '(A)',' INPUT THE YEAR FOR WHICH EASTER' PRINT '(A)',' IS TO BE CALCULATED' PRINT '(A)',' ENTER THE WHOLE YEAR, E.G. 1978 ' READ '(A)',YEAR C CALCULATING THE YEAR IN THE 19 YEAR METONIC CYCLE-METCYC METCYC = MOD(YEAR,19)+1 IF(YEAR.LE.1582)THEN DAY = (5*YEAR)/4 EPACT = MOD(11*METCYC-4,30)+1 ELSE C CALCULATING THE CENTURY-CENTRY CENTRY = (YEAR/100)+1 C ACCOUNTING FOR ARITHMETIC INACCURACIES C IGNORES LEAP YEARS ETC. ERROR1 = (3*CENTRY/4)-12 ERROR2 = ((8*CENTRY+5)/25)-5 C LOCATING SUNDAY DAY = (5*YEAR/4)-ERROR1-10 C LOCATING THE EPACT(FULL MOON) EPACT = MOD(11*METCYC+20+ERROR2-ERROR1,30) IF(EPACT.LT.0)EPACT=30+EPACT IF((EPACT.EQ.25.AND.METCYC.GT.11).OR.EPACT.EQ.24)THEN EPACT=EPACT+1 ENDIF ENDIF C FINDING THE FULL MOON LUNA=44-EPACT IF(LUNA.LT.21)THEN LUNA=LUNA+30 ENDIF C LOCATING EASTER SUNDAY LUNA=LUNA+7-(MOD(DAY+LUNA,7)) C LOCATING THE CORRECT MONTH IF(LUNA.GT.31)THEN LUNA = LUNA - 31 PRINT '(A)',' FOR THE YEAR ',YEAR PRINT '(A)',' EASTER FALLS ON APRIL ',LUNA ELSE PRINT '(A)',' FOR THE YEAR ',YEAR PRINT '(A)',' EASTER FALLS ON MARCH ',LUNA ENDIF END Any help would be appreciated, Ken -- WWL 📚

2 months

2
1
0 0

3B2/400 Unix System V r3 man

by KenUnix

Hi. Was a man page kit ever made for Unix V r3. I am running it under a 3B2/400 sim. If it is available where could I get it? Thanks, Ken -- WWL 📚

2 months

1
0
0 0

Re: [TUHS] Re: the wheel of reincarnation goes sideways

by Dan Cross

I don't know if a thousand users ever logged in there at one time, but they do tend to have a lot of simultaneous logins. On Mon, Mar 13, 2023 at 6:16 PM Peter Pentchev <roam(a)ringlet.net> wrote: > > On Wed, Mar 08, 2023 at 02:52:43PM -0500, Dan Cross wrote: > > [bumping to COFF] > > > > On Wed, Mar 8, 2023 at 2:05 PM ron minnich <rminnich(a)gmail.com> wrote: > > > The wheel of reincarnation discussion got me to thinking: > [snip] > > > The evolution of platforms like laptops to becoming full distributed systems continues. > > > The wheel of reincarnation spins counter clockwise -- or sideways? > > > > About a year ago, I ran across an email written a decade or more prior > > on some mainframe mailing list where someone wrote something like, > > "wow! It just occurred to me that my Athlon machine is faster than the > > ES/3090-600J I used in 1989!" Some guy responded angrily, rising to > > the wounded honor of IBM, raving about how preposterous this was > > because the mainframe could handle a thousand users logged in at one > > time and there's no way this Linux box could ever do that. > [snip] > > For that matter, a > > thousand users probably _could_ telnet into the Athlon system. With > > telnet in line mode, it'd probably even be decently responsive. > > sdf.org (formerly sdf.lonestar.org) comes to mind... > > G'luck, > Peter > > -- > Peter Pentchev roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

2 months, 2 weeks

1
0
0 0

Re: [TUHS] Re: Conditions, AKA exceptions. (Was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

by Bakul Shah

To make exceptional handling robust, I think every exception needs to be explicitly handled somewhere. If an exception not handled by a function, that fact must be specified in the function declaration. In effect the compiler can check that every exception has a handler somewhere. I think you can implement it using different syntactic sugar than Go’s obnoxious error handling but basically the same (though you may be tempted to make more efficient). > On Mar 10, 2023, at 6:21 AM, Larry Stewart <stewart(a)serissa.com> wrote: > TLDR exceptions don't make it better, they make it different. > > The Mesa and Cedar languages at PARC CSL were intended to be "Systems Languages" and fully embraced exceptions. > > The problem is that it is extremely tempting for the author of a library to use them, and equally tempting for the authors of library calls used by the first library, and so on. > At the application level, literally anything can happen on any call. > > The Cedar OS was a library OS, where applications ran in the same address space, since there was no VM. In 1982 or so I set out to write a shell for it, and was determined that regardless of what happened, the shell should not crash, so I set out to guard every single call with handlers for every exception they could raise. > > This was an immensely frustrating process because while the language suggested that the author of a library capture exceptions on the way by and translate them to one at the package level, this is a terrible idea in its own way, because you can't debug - the state of the ultimate problem was lost. So no one did this, and at the top level, literally any exception could occur. > > Another thing that happens with exceptions is that programmers get the bright idea to use them for conditions which are uncommon, but expected, so any user of the function has to write complicated code to deal with these cases. > > On the whole, I came away with a great deal of grudging respect for ERRNO as striking a great balance between ease of use and specificity. > > I also evolved Larry's Theory of Exceptions, which is that it is the programmer's job to sort exceptional conditions into actionable categories: (1) resolvable by the user (bad arguments) (2) Temporary (out of network sockets or whatever) (3) resolvable by the sysadmin (config) (4) real bug, resolvable by the author. > > The usual practice of course is the popup "Received unknown error, OK?" > > -Larry > >> On Mar 10, 2023, at 8:15 AM, Ralph Corderoy <ralph(a)inputplus.co.uk> wrote: >> >> Hi Noel, >> >>>> if you say above that most people are unfamiliar with them due to >>>> their use of goto then that's probably wrong >>> I didn't say that. >> >> Thanks for clarifying; I did know it was a possibility. >> >>> I was just astonished that in a long thread about handling exceptional >>> conditions, nobody had mentioned . . . exceptions. Clearly, either >>> unfamiliarity (perhaps because not many laguages provide them - as you >>> point out, Go does not), or not top of mind. >> >> Or perhaps those happy to use gotos also tend to be those who dislike >> exceptions. :-) >> >> Anyway, I'm off-TUHS-pic so follow-ups set to goto COFF. >> >> -- >> Cheers, Ralph.

2 months, 2 weeks

9
17
0 0

Re: [TUHS] the wheel of reincarnation goes sideways

by Dan Cross

[bumping to COFF] On Wed, Mar 8, 2023 at 2:05 PM ron minnich <rminnich(a)gmail.com> wrote: > The wheel of reincarnation discussion got me to thinking: > > What I'm seeing is reversing the rotation of the wheel of reincarnation. Instead of pulling the task (e.g. graphics) from a special purpose device back into the general purpose domain, the general purpose computing domain is pushed into the special purpose device. > > I first saw this almost 10 years ago with a WLAN modem chip that ran linux on its 4 core cpu, all of it in a tiny package. It was faster, better, and cheaper than its traditional embedded predecessor -- because the software stack was less dedicated and single-company-created. Take Linux, add some stuff, voila! WLAN modem. > > Now I'm seeing it in peripheral devices that have, not one, but several independent SoCs, all running Linux, on one card. There's even been a recent remote code exploit on, ... an LCD panel. > > Any of these little devices, with the better part of a 1G flash and a large part of 1G DRAM, dwarfs anything Unix ever ran on. And there are more and more of them, all over the little PCB in a laptop. > > The evolution of platforms like laptops to becoming full distributed systems continues. > The wheel of reincarnation spins counter clockwise -- or sideways? About a year ago, I ran across an email written a decade or more prior on some mainframe mailing list where someone wrote something like, "wow! It just occurred to me that my Athlon machine is faster than the ES/3090-600J I used in 1989!" Some guy responded angrily, rising to the wounded honor of IBM, raving about how preposterous this was because the mainframe could handle a thousand users logged in at one time and there's no way this Linux box could ever do that. I was struck by the absurdity of that; it's such a ridiculous non-comparison. The mainframe had layers of terminal concentrators, 3270 controllers, IO controllers, etc, etc, and a software ecosystem that made heavy use of all of that, all to keep user interaction _off_ of the actual CPU (I guess freeing that up to run COBOL programs in batch mode...); it's not as though every time a mainframe user typed something into a form on their terminal it interrupted the primary CPU. Of course, the first guy was right: the AMD machine probably _was_ more capable than a 3090 in terms of CPU performance, RAM and storage capacity, and raw bandwidth between the CPU and IO subsystems. But the 3090 was really more like a distributed system than the Athlon box was, with all sorts of offload capabilities. For that matter, a thousand users probably _could_ telnet into the Athlon system. With telnet in line mode, it'd probably even be decently responsive. So often it seems to me like end-user systems are just continuing to adopt "large system" techniques. Nothing new under the sun. > I'm no longer sure the whole idea of the wheel or reincarnation is even applicable. I often feel like the wheel has fallen onto its side, and we're continually picking it up from the edge and flipping it over, ad nauseum. - Dan C.

2 months, 2 weeks

5
6
0 0

continue N. (Was: I can't drive 55...)

by Ralph Corderoy

Hi Steffen, COFF'd. > Very often i find myself needing a restart necessity, so "continue > N" would that be. Then again when "N" is a number instead of > a label this is a (let alone maintainance) mess but for shortest > code paths. Do you mean ‘continue’ which re-tests the condition or more like Perl's ‘redo’ which re-starts the loop's body? ‘The "redo" command restarts the loop block without evaluating the conditional again. The "continue" block, if any, is not executed.’ — perldoc -f redo So like a ‘goto redo’ in while (...) { redo: ... if (...) goto redo ... } -- Cheers, Ralph.

2 months, 2 weeks

3
2
0 0

2023

2022

2021

2020

2019

2018

COFF March 2023