[cctalk] Re: Random items on Pascal #3
We were a beta test site for NOS/VE and the hardware (Cyber 180?). CDC sent the machine and a software support engineer to help us do something with it. My one recollection was that the command language was horribly awkward, but I didn't spend much time on the system. I know there are some manuals for NOS/VE on bitsavers, but I wonder if any of the software still exists? Gary On 5/15/24 23:00, Ken Seefried via cctalk wrote: I came to it all a bit later. I do recall the CDC salesthing saying something like "oh, you guys have some Unix around here? Have we got something for you!". And the systems guys brought up NOS/VE on the last CDC machines we ever bought. On Wed, May 15, 2024 at 10:43 PM Chuck Guzis via cctalk < cctalk@classiccmp.org> wrote: On 5/15/24 18:47, Ken Seefried via cctalk wrote: Please...I'm trying very hard not to remember them (or NOS...worse, NOS/VE). I left CDC at around the time that SCOPE 3.4 was being renamed NOS BE and KRONOS was becoming NOS. I remember attending a design meeting for the pager in what was to become NOS/VE. I asked the presenter if he'd conferred with any of the virtual memory pager talent that CDC had in-house. Blank stare. I informed him that the STAR-100 people had lived in that particular hell since about 1969--and that demand paging was not the way to run a shop. STAR had long-since switched to a working set algorithm. Even that wasn't enough. If one selected a large (65 KW) page size and set up certain vector instructions so that addresses crossed page boundaries, it was impossible to get the required pages into memory all at once. The system just sat there and thrashed --Chuck
[cctalk] Re: PCs in home vs businesses (70s/80s)
By the time frame mentioned in the article (1981) there were many commercially available applications. There was also hardware (e.g. from DEC, DG, HP) that was of a scale where it would be dedicated to one application. At that time I worked for a company that developed a database system. I can think of a few trips I made to help customers bring up a new data center dedicated to running our product. On 4/27/24 14:12, Wayne S via cctalk wrote: IMHO, having started programming in 1977, the thing that drove sales was the promise of reduced costs just by having a computer that could be programmed to do accounting type work that would eliminate jobs and thus costs. Mainframes were very expensive back then so there weren’t many companies that developed software just to be marketed to other companies. A lot if what was sold had been developed by a company for internal use. Tgen someone got the idea that they could recoup some development costs by selling the software. A lot of payroll systems got started like that. Payroll was a logical starting point because it was a common function within companies. I would say that software never drove hardware sales. You had hardware already and you might try to find software that ran on it or your team programmed it in house. I’ve never been to a company that found software then bought the hardware that it ran on. There would be too much due diligence needed to make that happen. Sent from my iPhone On Apr 27, 2024, at 10:41, Tarek Hoteit wrote: Hi. Meant complete software application systems, but, of course, it is eventually powered by language compilers Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675 On Apr 27, 2024, at 10:39, Wayne S wrote: When you say “software drove hardware sales” do you mean complete software application systems or do you mean compilers available for the hardware so the software teams had variety in what they could program? Up to the ‘90’s, companies had big, expensive hardware and little to no canned software applications so companies also had relatively cheaper software developers to make custom programs. Sent from my iPhone On Apr 27, 2024, at 10:23, Tarek Hoteit via cctalk wrote: I came across this paragraph from the July 1981 Popular Science magazine edition in the article titled “Compute power - pro models at almost home-unit prices.” “ ‘Personal-computer buffs may buy a machine, bring it home, and then spend the rest of their time looking for things it can do’, said …. ‘In business, it’s the other way around. Here you know the job, you have to find a machine that will do it. More precisely, you have to find software that will do the job. Finding a computer to use the software you’ve selected becomes secondary.”. Do you guys* think that software drove hardware sales rather than the other way around for businesses in the early days? I recall that computer hardware salespeople would be knocking on businesses office doors rather than software salesmen. Just seeking your opinion now that we are far ahead from 1981. (*I do wish we have female gender engaged in the classic computing discussions threads as well. Maybe there is.) Regards, Tarek Hoteit AI Consultant, PhD +1 360-838-3675
[cctalk] Re: RIP: Software design pioneer and Pascal creator Niklaus Wirth
On 1/4/24 19:34, Paul Koning via cctalk wrote: I think the CDC 6000 Algol 68 is still around somewhere. That one was created in Holland. There is NOS/BE install for DtCyber available from retro1.org. It includes binaries of both Algol 60 and Algol 68 compilers. Gary
[cctalk] Re: mainframe vs mini
On 3/10/23 12:26, Lee Courtney via cctalk wrote: Mainframe - Minicomputer = RAS and order magnitude better I/O That I think is the best distinction from the minicomputer era. Even within the same system architecture (e.g. VAX's) there were machines that were solidly mini's and those that tended toward mainframes. Implementation features like redundancy, data path retry, ECC in more places, separate maintenance processors, many I/O buses, and more memory bandwidth distinguished machines that aspired to be "big iron". And of course it all came with a corresponding "big price tag".
Re: DEC OSF/1 for i386?
On 4/29/22 10:45, Dennis Grevenstein wrote: Hi, just recently I found this archive: https://vetusware.com/download/OSF1%20Source%20Code%201.10/?id=11574 Cool! this is a package of source code for DEC OSF/1 V 1.0. I knew that this is supposed to run on DECstations (with MIPS), in fact I have a DS3100 running it myself. However, one thing really puzzled me: This archive apparently includes support for i386. There is even a kernel build log from 1990. Now that was news to me. I never realized that this worked on i386. Can anybody here tell any stories about this? I was working in AlphaServer hardware engineering at that time, so I wasn't directly involved but from what I remember... The i386 parts of the tree are remnants of the OSF consortium code base which derived from Mach. That original code supported the DS3100 (PMAX) so there would never have been any reason to run it on i386 at DEC. I think DEC OSF/1 V1 was only ever an "Advanced Developer" release for the DS3100 (and maybe the DS5000 systems aka 3MAX). The "official" UNIX for all the MIPS platforms was still MIPS Ultrix. At that time (1992), the UNIX strategy was even more chaotic than usual, since DEC had committed to the transition from Ultrix to the "industry standard" OSF/1, at the same time all the MIPS plans were being derailed by the pending arrival of Alpha. This created an incredible headache for the OS development folks. The group actually ended up being split, with most of the team working on keeping Ultrix going, and "productizing" OSF/1, while an "advanced development" team across the river in Hudson, NH did the hardware port to Alpha. That was definitely an "all hands" effort, including software guys who were drafted from the hardware teams, and some folks from the System V UNIX team in New Jersey (oh yeah, DEC also had a System V UNIX product at the same time to sell to the phone companies). FWIW, much, much later, when the product was Compaq Tru64 UNIX, there actually was a port to X86-64 that booted and ran. But it was never more than an engineering prototype.
Re: VAX9000 unearthed
On 2/18/22 15:35, Paul Koning wrote: On Feb 18, 2022, at 3:18 PM, Gary Grebus wrote: On 2/18/22 09:46, Paul Koning wrote: ...The 9000 also had its own I/O bus, XMI, different from BI. I don't know how its performance compares, whether it was worth the effort. XMI already existed as the system bus for the VAX 6000 series machines. I/O on the VAX 6000's was via an XMI-to-BI bridge. I don't remember the exact performance specs on XMI, but it was wider and faster than BI. XMI was then also used as one of the possible I/O buses on the VAX 1 and AlphaServer 7000 and 8000 series machines, via a system bus to XMI bridge. So the XMI I/O adapters were common across all these series of machines. I didn't remember all those details, thanks. There also was an effort at one point to adopt FutureBus in DEC systems. We did a pile of design in the network architecture group to figure out how to handle interrupts and bus cycles efficiently; I don't remember if anything actually shipped with that stuff. There was a FutureBus I/O subsystem for the AlphaServer 8000 series. It was a qualified, orderable option, but I can't imagine we sold very many (if any). It was done supposedly because the US Navy was standardizing on FutureBus for some application. I vaguely recall DEC made an Ethernet adapter that went on FutureBus, but you would have needed another I/O bus to have a usable system. The native I/O interface on the AlphaServer 8000 (aka TurboLaser) was one or more system bus to "hose" modules, where a "hose" was a pair of cables that provided a 32 bit data path in each direction. The hose connected to a bridge module on the target I/O bus. There was support for XMI, PCI, and FutureBus. -- Gary
Re: VAX9000 unearthed
On 2/18/22 09:46, Paul Koning wrote: On Feb 18, 2022, at 7:08 AM, Joerg Hoppe via cctalk wrote: Hi, my computer club c-c-g.de could acquire the remains of a VAX9000 ! The machine ran at the GWDG computing center in G?ttingen, Germany, around 1993. Parts of it were in stock of their museum for 20+ years. See lots of hires-pictures at https://c-c-g.de/fachartikel/359-vax-9000-ein-starker-exot (scroll to the bottom for a slide show). Joerg Excellent photos! I didn't realize the 9000 had a vector processor. One reason the design was so expensive is that it was originally planned as a water-cooled machine -- code name "Aquarius". At some point that idea was dropped and switched to air cooling -- code name "Aridus". I guess those skinny pipes with red and blue markers carry jets of cooling air, but were originally going to carry water. The 9000 also had its own I/O bus, XMI, different from BI. I don't know how its performance compares, whether it was worth the effort. XMI already existed as the system bus for the VAX 6000 series machines. I/O on the VAX 6000's was via an XMI-to-BI bridge. I don't remember the exact performance specs on XMI, but it was wider and faster than BI. XMI was then also used as one of the possible I/O buses on the VAX 1 and AlphaServer 7000 and 8000 series machines, via a system bus to XMI bridge. So the XMI I/O adapters were common across all these series of machines. Gary
Re: VAX/VMS 4.0 source listings scans
On 12/14/21 12:25 PM, Joerg Hoppe wrote: Full micro fiche scans of VAX/VMS 4.0/4.1 source listings are now published at http://www.bitsavers.org/pdf/dec/vax/microfiche/vms-source-listings/AH-BT13A-SE__VAX-VMS_V4.0_SRC_LST_MCRF/AH-BT13A-SE__VAX-VMS_V4.0_SRC_LST_MCRF/ Thanks for doing this! It's great fun to look at these. I spent many hours back in the day in front of the fiche reader... analyzing crash dumps and generally learning about how an operating system is really put together. Gary
Re: archive of DEC Notes
On 2/24/21 3:27 PM, Paul Koning wrote:
>
>
>> On Feb 24, 2021, at 9:08 AM, Antonio Carlini via cctalk
>> wrote:
>>
>> On 24/02/2021 03:26, Eric Smith via cctalk wrote:
>>> Does anyone have contact information for the proprietor of this site:
>>> http://www.activityclub.org/decnotes/
>>> The site has an index of messages archived from DEC's internal "Notes"
>>> (kind of their equivalent of UseNet).
>>>
>>> It appears from the "Download this site" page that at one time it was
>>> possible to download an archive of the actual content, but the hosting used
>>> for that only provides one week of free hosting, which has expired.
>>>
>>> I don't need the entire archive (though I'd like to get it), but I'd
>>> especially like to get messages from milkwy::23class_semiconductor and
>>> ricks::decschips.
>>
>> Well if they ever show up, I'd be interested :-).
>>
>>
>> That archive was largely incomplete: it had the message titles but very few
>> of the actual messages. There were some rather harsh negative comments on an
>> FB group when someone pointed to it. Obviously some people thought that when
>> they were writing their original comments that they would be kept private to
>> the 100,000+ Digital employees :-)
>
> The more significant issue may be that DEC, and its successor companies,
> might have objections to the public posting of company confidential material.
>
> Too bad only a few things were archived. I looked for myself and found
> exactly one notesfile ("fddi") with saved content, which made for some fun
> reading. But other notesfiles that would actually be more interesting at
> this stage, like ones about RSTS, aren't archived.
>
> I wonder if anyone has the full archive dump. If so I'd love to have that.
>
> paul
>
>
I found a few of my postings in there from AlphaServer and Digital UNIX
days. It is fun being reminded of some of the folks I worked with all
those years ago. My other reaction was "I'm sure glad nobody is asking
me to remember some of that trivia now".
Gary
Re: DECimage questions
On 3/17/19 15:36, Chris Hanson wrote: > I recently acquired a DECimage X terminal, which is theoretically a VXT-2000 > with an add-on 2D accelerator. Unfortunately while the terminal is badges as > a DECimage it didn?t include the board, just a frame buffer. > You may not find any software that can actually use the DECimage board. DEC's strategy for using X terminals for image display was based around the X Imaging Extension (XIE). That was an extension to the X protocol that allowed an application to setup a rendering pipeline (decompress, scale, filter, color adjust, etc) and then "transport" the image into the pipeline. If the X server had an accelerator, then the pipeline might get mapped onto the accelerator hardware. It was almost a win on the underpowered VAX's of the day (especially for decompression). So to take advantage of the accelerator, an application had to make XIElib calls (analogous to Xlib). The libraries (and XIE) were part of the VMS and Ultrix products, but I'm not sure there was anything that used them (maybe some example programs). I don't remember if board for the VXT2000 had any other capabilities that might have helped with normal X server operations. -- Gary
