[cctalk] Re: 14 DZ11's for sale/whatever
HKJC, now there's a designation I haven't seen in many years. Were you on that project? I oddly enough have a report that was a root cause analysis as to the failure of the whole thing. Fascinating reading, it's like a 1970's DEC CSS hardware orgy gone mad. C
[cctalk] Re: 14 DZ11's for sale/whatever
> On Nov 1, 2022, at 7:59 PM, Chris Zach via cctalk > wrote: > > On 11/1/2022 11:49 AM, Ethan Dicks via cctalk wrote: >> I don't think the 11/750 could have handled that many users on DZ-11s. > > I think this is why COMM-IO-P systems were sold. They basically acted like > front end processors for a stack of DZ11's to interface to a Unibus system. > > Problem was those communications processor boards only had enough microcode > to handle either block lines or async lines but not both. When the fruitcakes > at HKJC demanded that they support the betting systems (polled block oriented > devices) and async terminals (for betting odds and displays and such) for the > mighty Sha Tin Totalizer (multiple 11/74 type systems and a boat-ton of 11/04 > front ends connected by those weird IPC connections) all hell broke loose. > > Literally. You'd think the obvious answer would be to use two KMC11s rather than just one... The big win from those coprocessors is that they could offload not just simple DMA, but also protocol processing like DDCMP or even BISYNC. HKJC, now there's a designation I haven't seen in many years. paul
[cctalk] Re: 14 DZ11's for sale/whatever
On 11/1/2022 11:49 AM, Ethan Dicks via cctalk wrote: I don't think the 11/750 could have handled that many users on DZ-11s. I think this is why COMM-IO-P systems were sold. They basically acted like front end processors for a stack of DZ11's to interface to a Unibus system. Problem was those communications processor boards only had enough microcode to handle either block lines or async lines but not both. When the fruitcakes at HKJC demanded that they support the betting systems (polled block oriented devices) and async terminals (for betting odds and displays and such) for the mighty Sha Tin Totalizer (multiple 11/74 type systems and a boat-ton of 11/04 front ends connected by those weird IPC connections) all hell broke loose. Literally. CZ -ethan
[cctalk] Re: Is this a RIFA (uV3100-10 PSU)?
On 24/10/2022 21:07, Antonio Carlini via cctalk wrote: the bitsbox one may be a teensy bit to large but the ebay one should fit nicely. Neither is too expensive even with postage so I'll buy a few, given that I do have a fair few PSUs knocking around. Turns out both sets of X2 caps I bought were identical and they fit perfectly. As I was putting the PSU back together I thought I could hear something loose rattling inside. So I decided to dismantle it completely. I managed to get the bottom board out, with some fiddling, but it would be much easier if I could get the fans off. However, they seem to be held on with some fasteners that I've not seen before. On the inside they are some sort of trilobe fastener that seems to yield under any sort of pressure (so I stopped) and on the outside they have a small hole with three thin slots, but my tri-wing bits only seem to turn them in the "tighten" direction, almost as though the whole thing is supposed to be "fit and forget". I suppose if I had to get the fans out of the way I could destroy those fittings and replace with some suitable M bolts. I'm just wondering now whether I'm missing a trick for removing the fans? I thought those things that hold the fans on were a variation on pop rivets but now that you mention it, I can see the "three sided slot" on the outside. Perhaps there is something preventing them from unscrewing, so that vibration from the fans will not end up loostening them or something like that? I've taken the boards out of a whole bunch of H7821 and H7822 PSUs to replace the electrolytics without removing the fans. It was difficult at first but the more I did, the easier it got. I did come across one seized fan along the way but I haven't a replacement yet so I haven't got around to removing the bad one. I should look into it. Regards, Peter Coghlan. As I write this I realise that a photo or two wouldn't go amiss, so I'll try to take a few close ups tomorrow in daylight. Antonio -- Antonio Carlini anto...@acarlini.com
[cctalk] Re: Is this a RIFA (uV3100-10 PSU)?
On 24/10/2022 21:07, Antonio Carlini via cctalk wrote: the bitsbox one may be a teensy bit to large but the ebay one should fit nicely. Neither is too expensive even with postage so I'll buy a few, given that I do have a fair few PSUs knocking around. Turns out both sets of X2 caps I bought were identical and they fit perfectly. As I was putting the PSU back together I thought I could hear something loose rattling inside. So I decided to dismantle it completely. I managed to get the bottom board out, with some fiddling, but it would be much easier if I could get the fans off. However, they seem to be held on with some fasteners that I've not seen before. On the inside they are some sort of trilobe fastener that seems to yield under any sort of pressure (so I stopped) and on the outside they have a small hole with three thin slots, but my tri-wing bits only seem to turn them in the "tighten" direction, almost as though the whole thing is supposed to be "fit and forget". I suppose if I had to get the fans out of the way I could destroy those fittings and replace with some suitable M bolts. I'm just wondering now whether I'm missing a trick for removing the fans? As I write this I realise that a photo or two wouldn't go amiss, so I'll try to take a few close ups tomorrow in daylight. Antonio -- Antonio Carlini anto...@acarlini.com
[cctalk] Re: 14 DZ11's for sale/whatever
> On Nov 1, 2022, at 3:38 PM, Ethan Dicks via cctalk > wrote: > > On Tue, Nov 1, 2022 at 12:01 PM Paul Koning via cctalk > wrote: >>> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk >>> wrote: >>> >>> The difference between dz and dh interfaces is that the dh used dma instead >>> of interrupts to get characters to the cpu... >> >> No, it doesn't. I was confused about this but was recently corrected. >> >> The DH11 does DMA output, but not DMA input. I don't know any DEC serial >> port devices that have DMA input; it would make very little sense to do that >> since input generally is one character at a time. > > Yes. I was going to mention this in my previous reply but got sidetracked. > > The big benefit for DH11 and DMF32 and 3rd-party DH11 work-alikes > (Emulex CS-21...) is that since under normal workflow, many times more > chars go out than come in so DMA-out saves a lot of overhead when > blasting screens of stuff (like refreshing your page in EDT...) and > people don't type all that fast by comparison. > > Where we used to have problems is having multiple Kermit sessions on > our serial ports. Those hammer both ways. > > Fortunately, I wasn't trying to support PDP-11s with split baud rates > like 1200/150 that were used to _really_ reduce input interrupt > frequency. Our machines kept up at 9600/9600. A DEC product that shows this sort of scenario is Typeset-11 (TMS-11) which has VT71 block transfer terminals at 9600 bps. I'm 98% sure those were on DH11s. So with those, when the user hit the key to send the completed file back to the host, a bulk transfer of whatever the file size was (a complete newspaper article, in the typical case) would occur. I'm not sure if DDCMP was used for that, probably yes. It certainly adds up to a pretty significant workload. I suppose there was an occasional FIFO overflow under peak load (reporters frantically finishing articles as the deadline approaches...) paul
[cctalk] Re: 14 DZ11's for sale/whatever
On Tue, Nov 1, 2022 at 12:01 PM Paul Koning via cctalk wrote: > > On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk > > wrote: > > > > The difference between dz and dh interfaces is that the dh used dma instead > > of interrupts to get characters to the cpu... > > No, it doesn't. I was confused about this but was recently corrected. > > The DH11 does DMA output, but not DMA input. I don't know any DEC serial > port devices that have DMA input; it would make very little sense to do that > since input generally is one character at a time. Yes. I was going to mention this in my previous reply but got sidetracked. The big benefit for DH11 and DMF32 and 3rd-party DH11 work-alikes (Emulex CS-21...) is that since under normal workflow, many times more chars go out than come in so DMA-out saves a lot of overhead when blasting screens of stuff (like refreshing your page in EDT...) and people don't type all that fast by comparison. Where we used to have problems is having multiple Kermit sessions on our serial ports. Those hammer both ways. Fortunately, I wasn't trying to support PDP-11s with split baud rates like 1200/150 that were used to _really_ reduce input interrupt frequency. Our machines kept up at 9600/9600. -ethan
[cctalk] Re: 14 DZ11's for sale/whatever
Just to clarify, my surmising was in response to “ The DH11 does DMA output, but not DMA input. ” in one of the earlier messages. Sent from my iPhone > On Nov 1, 2022, at 12:03, Wayne S wrote: > > Paul said “But the DZ doesn't do DMA.” > I apologize. I used DZ in responses when i meant DH. > > > Sent from my iPhone > >> On Nov 1, 2022, at 11:56, Paul Koning via cctalk >> wrote: >> >> >> On Nov 1, 2022, at 2:32 PM, ben via cctalk wrote: >>> On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: >>> tents. The result is that the OS only has to deal with the device every 30 >>> characters or so (RSTS case) or even less often if the buffer size is >>> larger. Consider disk for another example. With very rare exceptions, disks do DMA: the OS points to the place where the data lives, supplies a transfer length and starting disk position, and says "go do it and tell me when it's finished". Newer devices like the MSCP controllers support a queue of requests, but even simple devices like the RK05 will do a full transfer without CPU involvement. >>> How mqny old systems required partial transfer for disk io, for swapping >>> overlays in and out? >> >> Arbitrary size reads are common; as you said overlay loads require that. >> Partial block writes are not so common. In RSTS, the base OS write >> operation does not allow that. But I found out early that RT11 does, and >> depends on it. In RT11, if you do a partial block write, the rule is that >> the rest of the block is zero-filled. In some disks the controller takes >> care of that. In the RF11, the driver does because the device does any word >> count, so the driver sets up a separate transfer for the rest of the block >> using a word containing zero as the source buffer, and "inhibit bus address >> increment" set so all the DMA cycles use that same word. In the RC11, the >> sector size is 64 bytes, so the device zero-fills to the end of the sector >> but the driver has to do the same sort of stuff as the RF11 driver if there >> are any additional 64-byte sectors left before the 512-byte block boundary. >> >> It turns out RT11 Fortran depends on this, though I don't remember the >> details. >> >> paul >>
[cctalk] Re: 14 DZ11's for sale/whatever
Paul said “But the DZ doesn't do DMA.” I apologize. I used DZ in responses when i meant DH. Sent from my iPhone > On Nov 1, 2022, at 11:56, Paul Koning via cctalk > wrote: > > > >> On Nov 1, 2022, at 2:32 PM, ben via cctalk wrote: >> >> On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: >> tents. The result is that the OS only has to deal with the device every 30 >> characters or so (RSTS case) or even less often if the buffer size is larger. >>> Consider disk for another example. With very rare exceptions, disks do >>> DMA: the OS points to the place where the data lives, supplies a transfer >>> length and starting disk position, and says "go do it and tell me when it's >>> finished". Newer devices like the MSCP controllers support a queue of >>> requests, but even simple devices like the RK05 will do a full transfer >>> without CPU involvement. >> How mqny old systems required partial transfer for disk io, for swapping >> overlays in and out? > > Arbitrary size reads are common; as you said overlay loads require that. > Partial block writes are not so common. In RSTS, the base OS write operation > does not allow that. But I found out early that RT11 does, and depends on > it. In RT11, if you do a partial block write, the rule is that the rest of > the block is zero-filled. In some disks the controller takes care of that. > In the RF11, the driver does because the device does any word count, so the > driver sets up a separate transfer for the rest of the block using a word > containing zero as the source buffer, and "inhibit bus address increment" set > so all the DMA cycles use that same word. In the RC11, the sector size is 64 > bytes, so the device zero-fills to the end of the sector but the driver has > to do the same sort of stuff as the RF11 driver if there are any additional > 64-byte sectors left before the 512-byte block boundary. > > It turns out RT11 Fortran depends on this, though I don't remember the > details. > >paul >
[cctalk] Re: 14 DZ11's for sale/whatever
> On Nov 1, 2022, at 2:32 PM, ben via cctalk wrote: > > On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: > tents. The result is that the OS only has to deal with the device every 30 > characters or so (RSTS case) or even less often if the buffer size is larger. >> Consider disk for another example. With very rare exceptions, disks do DMA: >> the OS points to the place where the data lives, supplies a transfer length >> and starting disk position, and says "go do it and tell me when it's >> finished". Newer devices like the MSCP controllers support a queue of >> requests, but even simple devices like the RK05 will do a full transfer >> without CPU involvement. > How mqny old systems required partial transfer for disk io, for swapping > overlays in and out? Arbitrary size reads are common; as you said overlay loads require that. Partial block writes are not so common. In RSTS, the base OS write operation does not allow that. But I found out early that RT11 does, and depends on it. In RT11, if you do a partial block write, the rule is that the rest of the block is zero-filled. In some disks the controller takes care of that. In the RF11, the driver does because the device does any word count, so the driver sets up a separate transfer for the rest of the block using a word containing zero as the source buffer, and "inhibit bus address increment" set so all the DMA cycles use that same word. In the RC11, the sector size is 64 bytes, so the device zero-fills to the end of the sector but the driver has to do the same sort of stuff as the RF11 driver if there are any additional 64-byte sectors left before the 512-byte block boundary. It turns out RT11 Fortran depends on this, though I don't remember the details. paul
[cctalk] Re: 50 Years of the HP 3000
From: Gavin Scott Subject: [cctalk] 50 Years of the HP 3000 Well, here we are. If you boot up a classic HP 3000 system and simply hit return when it asks you for the date and time, it will default to: As it turns out, I have a complete, working HP 3000 917/LX system, with printers, a line printer with stand, 14-port terminal concentrator, four HP 700-series terminals (one new in box, one likely dead), SCSI disk storage module with a couple of 2GB drives, DAT drive, and all of the necessary cables. It all seems to work perfectly (with the exception of the one worn-out terminal), and I booted it up a couple of months ago with no problems. The passwords have been removed from the MANAGER.SYS account, so the system is now wide open. There's also some software: ASK/ManMan, FORTRAN, and of course TurboIMAGE and Query; also a copy of Reflection (Windows emulator for HP terminals). There's also in excess of 100 pounds of documentation, and some boxes of paper, including green-bar (remember that?). The thing is, despite aspirations from my youth, I really don't need a complete timesharing computer system in my house, so I'm looking to sell the whole thing as a package. It seems possible that someone on this list might be interested, and I'm also open to suggestions about other places I could list it. I took it to the west coast Vintage Computer Faire this year, and there were several nibbles, but obviously I still have it. It's currently located in the San Francisco Bay area, but I commute semi-regularly between there and Portland OR, and could be fairly easily persuaded to deliver it anywhere in either of those areas, or in between. (The system will fit in a mini-van - barely - or comfortably in a full-sized pick-up truck with room to spare.) I'd like to see $2000, but will cheerfully entertain offers (cheerfully if they're reasonable, or met with hysterical laughter if not). Feel free to contact me off-list if you'd like more details and/or pictures. Thanks! ~~ Mark Moulding
[cctalk] Re: 14 DZ11's for sale/whatever
On 2022-11-01 11:20 a.m., Paul Koning via cctalk wrote: tents. The result is that the OS only has to deal with the device every 30 characters or so (RSTS case) or even less often if the buffer size is larger. Consider disk for another example. With very rare exceptions, disks do DMA: the OS points to the place where the data lives, supplies a transfer length and starting disk position, and says "go do it and tell me when it's finished". Newer devices like the MSCP controllers support a queue of requests, but even simple devices like the RK05 will do a full transfer without CPU involvement. How mqny old systems required partial transfer for disk io, for swapping overlays in and out? paul Ben.
[cctalk] Re: 14 DZ11's for sale/whatever
> On Nov 1, 2022, at 1:05 PM, Wayne S wrote:
>> ...
>>> On Nov 1, 2022, at 09:01, Paul Koning via cctalk
>>> wrote:
>>>
>>>
>>>
> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk
> wrote:
The difference between dz and dh interfaces is that the dh used dma
instead of interrupts to get characters to the cpu. It would be
transparent to any software.
>>>
>>> No, it doesn't. I was confused about this but was recently corrected.
>>>
>>> The DH11 does DMA output, but not DMA input. I don't know any DEC serial
>>> port devices that have DMA input; it would make very little sense to do
>>> that since input generally is one character at a time. Block mode
>>> terminals do exist in DEC's world but they are rare, and even those are
>>> hard to operate with simple DMA.
>>>
>>> DZ is programmed I/O in both directions, which makes the difference. In
>>> typical usage, the bulk of the terminal traffic is output, so doing that
>>> with DMA is a big win.
>>>
>>> paul
>>>
> Also, can you define what the phrase “programmed io” refers?
> AFAIK, pretty much everything does that, so a clarification would help.
Yes, in the sense that all I/O happens under control of some program. The term
"programmed I/O" normally means I/O where the entire job is done in software,
as opposed to DMA or similar schemes where the software initiates the process
but the I/O device then does a lot of the detail work autonomously, without
bothering the CPU.
Take terminal interfaces. With interactive terminals (standard usage in DEC
systems) it's unavoidable that the software has to do work for each character,
so programmed I/O is normal. It typically has a FIFO to deal with interrupt
latency, and as a result also tends to do interrupt coalescing (under hight
load each interrupt results in several characters being taken from the FIFO and
acted on).
Terminal output often comes in bursts, for example an application may write a
line of text or even a larger chunk of data. If so, the OS can do block
transfers for those bursts. Even if it has to copy from user to kernel
buffers, it can fill such a buffer and the start a DMA transfer of the entire
buffer contents. The result is that the OS only has to deal with the device
every 30 characters or so (RSTS case) or even less often if the buffer size is
larger.
Consider disk for another example. With very rare exceptions, disks do DMA:
the OS points to the place where the data lives, supplies a transfer length and
starting disk position, and says "go do it and tell me when it's finished".
Newer devices like the MSCP controllers support a queue of requests, but even
simple devices like the RK05 will do a full transfer without CPU involvement.
The one notorious exception is the Pro, where the disk controllers use
programmed I/O: the OS has to move every word one at a time to or from a
controller CSR. So the CPU overhead of disk I/O in that system is much higher
than on every other DEC machine, and partly for that reason the Pro is utterly
incapable of transferring consecutive sectors. Instead, it is forced to use
interleaving, where logically-adjacent sectors are actually 5 sectors apart
("4:1 interleave"). That too contributes to pathetic performance.
paul
[cctalk] Re: 14 DZ11's for sale/whatever
Sent from my iPhone > On Nov 1, 2022, at 10:01, Wayne S wrote: > > Hi Paul. Who “corrected” you about DMA input? I’d like to read about that as > nothing i read about the DZ mentioned that. Got any Cites? > > Sent from my iPhone > >> On Nov 1, 2022, at 09:01, Paul Koning via cctalk >> wrote: >> >> >> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk wrote: >>> >>> The difference between dz and dh interfaces is that the dh used dma instead >>> of interrupts to get characters to the cpu. It would be transparent to any >>> software. >> >> No, it doesn't. I was confused about this but was recently corrected. >> >> The DH11 does DMA output, but not DMA input. I don't know any DEC serial >> port devices that have DMA input; it would make very little sense to do that >> since input generally is one character at a time. Block mode terminals do >> exist in DEC's world but they are rare, and even those are hard to operate >> with simple DMA. >> >> DZ is programmed I/O in both directions, which makes the difference. In >> typical usage, the bulk of the terminal traffic is output, so doing that >> with DMA is a big win. >> >> paul >> Also, can you define what the phrase “programmed io” refers? AFAIK, pretty much everything does that, so a clarification would help. >>
[cctalk] Re: 14 DZ11's for sale/whatever
Hi Paul. Who “corrected” you about DMA input? I’d like to read about that as nothing i read about the DZ mentioned that. Got any Cites? Sent from my iPhone > On Nov 1, 2022, at 09:01, Paul Koning via cctalk > wrote: > > > >> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk >> wrote: >> >> The difference between dz and dh interfaces is that the dh used dma instead >> of interrupts to get characters to the cpu. It would be transparent to any >> software. > > No, it doesn't. I was confused about this but was recently corrected. > > The DH11 does DMA output, but not DMA input. I don't know any DEC serial > port devices that have DMA input; it would make very little sense to do that > since input generally is one character at a time. Block mode terminals do > exist in DEC's world but they are rare, and even those are hard to operate > with simple DMA. > > DZ is programmed I/O in both directions, which makes the difference. In > typical usage, the bulk of the terminal traffic is output, so doing that with > DMA is a big win. > >paul > >
[cctalk] Re: 14 DZ11's for sale/whatever
> On Oct 30, 2022, at 2:49 PM, Wayne S via cctalk wrote: > > The difference between dz and dh interfaces is that the dh used dma instead > of interrupts to get characters to the cpu. It would be transparent to any > software. No, it doesn't. I was confused about this but was recently corrected. The DH11 does DMA output, but not DMA input. I don't know any DEC serial port devices that have DMA input; it would make very little sense to do that since input generally is one character at a time. Block mode terminals do exist in DEC's world but they are rare, and even those are hard to operate with simple DMA. DZ is programmed I/O in both directions, which makes the difference. In typical usage, the bulk of the terminal traffic is output, so doing that with DMA is a big win. paul
[cctalk] Re: 14 DZ11's for sale/whatever
On Sun, Oct 30, 2022 at 2:49 PM Wayne S via cctalk wrote: > The difference between dz and dh interfaces is that the dh used dma instead > of interrupts to get characters to the cpu. It would be transparent to any > software. > I did a write up on them 40 years ago justifying the replacement of a dz with > dh saying that decreasing interrupts would increase performance on my VAX > 780. It did, but just a bit. To make a big difference, you’d have to have a > LOT of people banging away on serial terminals and rs-232 connected printers. When I ran Unibus VAXen in the 80s every day at work, our small machines had 5-9 serial ports for 1-4 users and our largest machine had 57 serial ports (multiple Emulex CS/21 and at least one DEC DMF32 plus the console) and several dozen users. We never moved to terminal servers or other external connection management. It was all individual serial connections routed to offices and workrooms. I think our peak usage was 50-60 active users but at that point, the 8MB of physical memory started to be a constraint. I don't think the 11/750 could have handled that many users on DZ-11s. -ethan
[cctalk] Re: LC:M+L (Living Computer Museum)
> Date: Sun, 30 Oct 2022 21:50:42 -0700 > From: Sellam Abraham via cctalk > I'm hoping Rich Alderson will pipe in and give us the actual story as to > what's going on with the LCM and its collection, but there's a possibility > that he may be legally constricted from giving comment at this time. > Date: Mon, 31 Oct 2022 15:31:43 +0800 > From: Tom Hunter via cctalk > The Internet is wonderful for misinformation and a good laugh. > Here even Paul Allen's sister Jody can morph into Paul's wife.:-) Yeah, I was going to correct that ;-) > Rich Alderson please provide the LCM facts if you can to stop the silly > rumours. First, let me thank Sellam and Tom for inviting me to comment on this topic. LCM+L closed its doors to the public in March 2020, at the height of the initial pandemic (in the sense that it had become clear that the Covid-19 virus was not a passing thing), because our entire mission was to make possible actual physical contact between visitors to the museum and vintage computing engines of various stripe. There was no way to allow visitors to continue to touch all the hardware which would protect both visitors and the equipment. Tour guides and front desk personnel were immediately let go, because it was clear that it would be several months, up to a year, before we could open again. Professional museum staff (curator, educational coordinator, etc.) were retained for a short while, to wind things down. The engineers were put to work winding things down: Creating power-down-bring-up documentation, backing up software on those systems for which that was necessary, and generally making it possible to close up shop with an eye to opening again in a year (the target period). This project was the response to the original order simply to turn everything off. We pointed out vociferously how much damage that would do to the dinosaurs, reminding the nontechnical powers-that-be of just how long it had taken to make most of the vintage hardware work again, and that they could plan on a month of restoration per month of down time, before the museum could be reopened after the decision was made to do so. All of the engineers, which the exception of the manager of the department, were laid off as of 1 July 2020. None of us was allowed to return to the museum at any future time, and no one associated with the mothballed museum was allowed to talk to any of us. All of that is by way of saying that I have no information on the internal state of the collection, or of the museum which we built on it. As for the status of the collection: While we built the museum, there was a private foundation set up which acquired items for the collection, generally by purchase. After 5 years of successful operations, with year over year increases in visitor counts, ongoing relationships with several school districts for instructional field trips, and worldwide acclaim, the decision was to taken to move to a 501(c)(3) public charity. This transition was under way when Paul died suddenly; that placed things into limbo because the transition was incomplete, and the estate could not do things that he could have done in person. That's as much as I know. Rich Alderson
[cctalk] 50 Years of the HP 3000
Well, here we are. If you boot up a classic HP 3000 system and simply hit return when it asks you for the date and time, it will default to: HP32002E.01.00 WHICH OPTION ? COO ANY CHANGES? N DATE (M/D/Y)? WED, NOV 1, 1972, 12:00 AM LOG FILE NUMBER 64 ON *WELCOME* :HELLO OPERATOR.SYS;HIPRI 0:00/13/SP#6/SPOOLED OUT 0:00/#S1/14/LOGON FOR: OPERATOR.SYS,OPERATOR ON LDEV #20 HP3000 / MPE V E.01.00 (BASE E.01.00). WED, NOV 1, 1972, 12:00 AM which is exactly 50 years ago today. November 1972 was the month that the very first HP 3000 systems were shipped to customers. Shortly after this, those initial deliveries were all hastily recalled when it quickly became clear that they were not yet capable of living up to their specifications. The 3000 however would go on to recover from this event and eventually became one of HP's most successful and profitable product lines, and one of the most beloved computer systems of all time, regularly beating out IBM, DEC, DG, and others in customer satisfaction surveys. For some stories about the earliest days of the platform, I refer you to the words of Bob Green http://www.robelle.com/smugbook/classic.html and Bill Foster http://www.teamfoster.com/hewlett-packard who were there. The original "Classic" CISC HP 3000 systems live on today through Dave Bryan's most excellent SIMH simulation http://simh.trailing-edge.com/hp/ and I have a turn-key setup which will let you have your own 1980-vintage HP 3000 system up and running in a couple minutes which is downloadable from my Google Drive at https://drive.google.com/file/d/16vaNUrmfs2aQpjdQijG4PZmJaNu3hfcz (Save the zip file using the download link in the upper right then extract it anywhere convenient and see the README file for further instructions) This only includes a SIMH binary for Windows, but you can also build a SIMH executable from Dave Bryan's source above for your platform of choice and use the rest of my infrastructure. MPE Forever. G.
[cctalk] Re: LC:M+L (Living Computer Museum)
Thank you for sheding some light on what transpired. Regards, Pontus On 2022-11-01 00:31, Rich Alderson via cctalk wrote: First, let me thank Sellam and Tom for inviting me to comment on this topic. LCM+L closed its doors to the public in March 2020, at the height of the initial pandemic (in the sense that it had become clear that the Covid-19 virus was not a passing thing), because our entire mission was to make possible actual physical contact between visitors to the museum and vintage computing engines of various stripe. There was no way to allow visitors to continue to touch all the hardware which would protect both visitors and the equipment. Tour guides and front desk personnel were immediately let go, because it was clear that it would be several months, up to a year, before we could open again. Professional museum staff (curator, educational coordinator, etc.) were retained for a short while, to wind things down. The engineers were put to work winding things down: Creating power-down-bring-up documentation, backing up software on those systems for which that was necessary, and generally making it possible to close up shop with an eye to opening again in a year (the target period). This project was the response to the original order simply to turn everything off. We pointed out vociferously how much damage that would do to the dinosaurs, reminding the nontechnical powers-that-be of just how long it had taken to make most of the vintage hardware work again, and that they could plan on a month of restoration per month of down time, before the museum could be reopened after the decision was made to do so. All of the engineers, which the exception of the manager of the department, were laid off as of 1 July 2020. None of us was allowed to return to the museum at any future time, and no one associated with the mothballed museum was allowed to talk to any of us. All of that is by way of saying that I have no information on the internal state of the collection, or of the museum which we built on it. As for the status of the collection: While we built the museum, there was a private foundation set up which acquired items for the collection, generally by purchase. After 5 years of successful operations, with year over year increases in visitor counts, ongoing relationships with several school districts for instructional field trips, and worldwide acclaim, the decision was to taken to move to a 501(c)(3) public charity. This transition was under way when Paul died suddenly; that placed things into limbo because the transition was incomplete, and the estate could not do things that he could have done in person. That's as much as I know. Rich Alderson P. S. After the layoff, I looked for work for a few months, with nary a nibble. I've officially been retired for tax purposes since September 2021.
[cctalk] Re: LC:M+L (Living Computer Museum)
Thank you Rich for shedding light on this. Most of it makes sense to me, but the secrecy part where you weren't allowed to talk to those still at the museum is weird. I can't see any possible commercial reason for preventing former engineering staff to talk with their former colleagues or replacements. If anything you would think that any new staff would be encouraged to talk to the engineers who left to benefit from their experience. As I said this appears to be rather strange. On Tue, 1 Nov 2022, 7:31 am Rich Alderson via cctalk, wrote: > First, let me thank Sellam and Tom for inviting me to comment on this > topic. > > LCM+L closed its doors to the public in March 2020, at the height of the > initial pandemic (in the sense that it had become clear that the Covid-19 > virus > was not a passing thing), because our entire mission was to make possible > actual physical contact between visitors to the museum and vintage > computing > engines of various stripe. There was no way to allow visitors to continue > to > touch all the hardware which would protect both visitors and the equipment. > > Tour guides and front desk personnel were immediately let go, because it > was > clear that it would be several months, up to a year, before we could open > again. Professional museum staff (curator, educational coordinator, etc.) > were > retained for a short while, to wind things down. The engineers were put to > work winding things down: Creating power-down-bring-up documentation, > backing > up software on those systems for which that was necessary, and generally > making > it possible to close up shop with an eye to opening again in a year (the > target > period). > > This project was the response to the original order simply to turn > everything > off. We pointed out vociferously how much damage that would do to the > dinosaurs, reminding the nontechnical powers-that-be of just how long it > had > taken to make most of the vintage hardware work again, and that they could > plan > on a month of restoration per month of down time, before the museum could > be > reopened after the decision was made to do so. > > All of the engineers, which the exception of the manager of the department, > were laid off as of 1 July 2020. None of us was allowed to return to the > museum at any future time, and no one associated with the mothballed > museum was > allowed to talk to any of us. > > All of that is by way of saying that I have no information on the internal > state of the collection, or of the museum which we built on it. > > As for the status of the collection: While we built the museum, there was > a > private foundation set up which acquired items for the collection, > generally by > purchase. After 5 years of successful operations, with year over year > increases in visitor counts, ongoing relationships with several school > districts for instructional field trips, and worldwide acclaim, the > decision > was to taken to move to a 501(c)(3) public charity. This transition was > under > way when Paul died suddenly; that placed things into limbo because the > transition was incomplete, and the estate could not do things that he could > have done in person. > > That's as much as I know. > > Rich > Alderson > > P. S. After the layoff, I looked for work for a few months, with nary a >nibble. I've officially been retired for tax purposes since > September 2021. >
