Re: Orphan HP Alphaservers looking for a new home
Dear Richard, As soon as I saw this message my heart skipped a few beats, merely at the _possibility_ that I might be able to share in some of this hardware. I have been fascinated by my first HP AlphaServer DS15, ever since an acquaintance at the local hackspace kindly gave it to me. Here are some photos: https://www.dropbox.com/sh/jxxkmh9fiaqdsjw/AAC5QdhR8NXE-Id5A44UYWRya?dl=0 I would love to take it all, and would gladly pay for shipping and insurance to the UK. But I don't want to be greedy either. Maybe there are other people on this list who would like to, or ought to, experience the same exhilaration as owning an AS. Having a small cluster of AlphaServers, plus RAID server and fibre switches, fits in SO PERFECTLY with my side project; it's about formalising methods for distributed computation and then making a libre-friendly distributed computing environment available to interested users in a communal or co-operative environment. I'm currently preparing the x86 portion of the overall project for shipping to colo. Several AS'es in an HA, resilient setup would be such a perfect complement. Please let me what you think! I value comments and questions from all. Kind regards, Andrew Sent from my mobile phone > On 17 Dec 2018, at 23:02, Richard Loken via cctalk > wrote: > > Ladies and gentlemen, > > I have immediate access to four Alphaservers, an RA8000 raid server, > and the associated fibre switches in need of a new home. > > There three servers that were running Tru64 Unix 5 when shut down a week > ago, they are a DS15, and two ES45s. There is also a third ES45 which > has not run in a decade and was kept around as a cold spare. > > None of the RA8000 disk will be available because the present owner is > protecting his data (of course) but all of the unused spare disks are > available and they will fit the internal slots in the DS15 and ES45s > which may or may not have disks depending on the whim of the present owner. > > Lots of paper docs and Tru64 OS installation kits but no licenses. > > They can be had for free but shipping will most assuridly not be free. > > -- > Richard Loken VE6BSV : "...underneath those tuques we wear, > Athabasca, Alberta Canada : our heads are naked!" > ** rllo...@telus.net ** :- Arthur Black
Re: IF you need these old vintage parts, PLEASE grab them before the keyboard keids do!
https://www.elecshopper.com/vintage-computers.html I really would rather these go to someone who needs them to complete a system than to the destroyers of keyboards. I am trying to get more of the vintage stuff listed. If you want to see items as they are listed online, please turn on your RSS feeds. https://www.elecshopper.com/rss/ How can you ask $75 for an untested Osborne keyboard?
Re: Orphan HP Alphaservers looking for a new home
> On Dec 17, 2018, at 4:49 PM, Al Kossow via cctalk > wrote: > > On 12/17/18 4:27 PM, Richard Loken via cctalk wrote: >> Anything >> Tru64 Unix does VMS does better. Anything Linux does Tru64 Unix does >> better. >> >> Have I made my bigotry clear? > > Spoken like a true VMS Jackass > > Some things stay constant over the DECades Face it Al, there is no better OS than VMS. I for one am looking forwards to the completion of the port to Xeon. Zane
Re: Orphan HP Alphaservers looking for a new home
On Mon, 17 Dec 2018, Jacob Ritorto wrote: There are contractors who have the hardware to correctly and contractually perform mil spec data wipe in situations like this. More thorough than leaving sitting on some shelf and crossing fingers that one will find time to burn them or whatever. I seriously don't care what happens to their data or their disks. -- Richard Loken VE6BSV: "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rllo...@telus.net ** :- Arthur Black
Re: Lots of unused CompacTape IV Cartridges Available
On Mon, 17 Dec 2018, Kevin McQuiggin wrote: I have a couple of compatible drives that I use on my Microvaxes, if you could spare say 6 then that?d be great. I live in Vancouver and of course would pay shipping! Good! Six down, 114 to go! I will get six for you. -- Richard Loken VE6BSV: "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rllo...@telus.net ** :- Arthur Black
Re: Hayes Transet Manual and Software
On Mon, Dec 17, 2018 at 10:12 AM geneb via cctalk wrote: > Jason, you can send it my direction for scanning if you like. I built a > book scanner a while back to handle all the Crescent Software manuals I I just watched your video on your DIY scanner - good work! I'll keep it in mind, but I really ought to just do it over here and do a better job of it. I'll get to it. In the meantime, here is the Macintosh software that came with it. I learned a bit about Mac disk formats when trying to image this one on a KryoFlux. It came on a 400K disk, which is MFS, and Ciderpress won't load it that filesystem, making me think it was a bad read. Finally stuck it in MiniVMac and up it came. I transferred the files to an 800K HFS disk image for convenience. Both are posted here: http://nocarrier.net/archive/floppy_images/Hayes It's a bootable disk with Finder 4.1, which I've never seen before. Again, if anyone knows where the PC version of the software is, I'd love to have it. -j
Re: Orphan HP Alphaservers looking for a new home
There are contractors who have the hardware to correctly and contractually perform mil spec data wipe in situations like this. More thorough than leaving sitting on some shelf and crossing fingers that one will find time to burn them or whatever. On Mon, Dec 17, 2018 at 6:02 PM Richard Loken via cctalk < cctalk@classiccmp.org> wrote: > Ladies and gentlemen, > > I have immediate access to four Alphaservers, an RA8000 raid server, > and the associated fibre switches in need of a new home. > > There three servers that were running Tru64 Unix 5 when shut down a week > ago, they are a DS15, and two ES45s. There is also a third ES45 which > has not run in a decade and was kept around as a cold spare. > > None of the RA8000 disk will be available because the present owner is > protecting his data (of course) but all of the unused spare disks are > available and they will fit the internal slots in the DS15 and ES45s > which may or may not have disks depending on the whim of the present owner. > > Lots of paper docs and Tru64 OS installation kits but no licenses. > > They can be had for free but shipping will most assuridly not be free. > > -- >Richard Loken VE6BSV : "...underneath those tuques we > wear, >Athabasca, Alberta Canada : our heads are naked!" >** rllo...@telus.net ** :- Arthur Black >
Re: Orphan HP Alphaservers looking for a new home
On 12/17/18 5:27 PM, Richard Loken via cctalk wrote: Anything Tru64 Unix does VMS does better. Anything Linux does Tru64 Unix does better. If that's true, then I would expect Tru64 to have better support of modern cryptographic ciphers than Linux. Carrying your analogy further, I'd expect to see bleeding edge development on future ciphers on (Open)VMS systems. Have I made my bigotry clear? Yep. Have I? }:-) You will seriously raise your electric bill and somewhat lower your heating bill. All of this hardware is 120V single phase but it would like a couple circuit breakers all to itself. Do the breakers need to come from /my/ breaker panel? Or do the Alphas care if they come from my neighbors house? ...Assuming that there's no sneak current or cross phase issues. I guess I could power them completely from my neighbor's place and just link our houses with optical fiber. :-D Or wireless! Seeing as how Linux sort of supports wireless, (Open)VMS is bound to have support for it. -- Grant. . . . unix || die
Re: Orphan HP Alphaservers looking for a new home
On Mon, Dec 17, 2018 at 3:45 PM Tapley, Mark via cctalk wrote: > > I hope hard enough that this cluster gets saved that if no-one else comes > forward, I’d like to be notified….I’m not certain what I could arrange, but > the thought of running my own personal Alpha supercomputer … wow. Not sure > how to solve the license issue though. I assume OpenVMS doesn’t support that > level of parallelization? > I have two ES47 System Building Block Drawers boxes, each with two 1GHz 21364 EV7 processors, which form a four CPU ES47 Model 4 when the two boxes are connected via the interprocessor hose cables. I didn't have any issues getting OpenVMS 8.4 running on the four CPU system. Maybe the memory is half full, so 8GB in each of the two boxes. The real issue is that each of the two ES47 boxes weigh around 125 pounds and they are almost 3 feet deep, so not something I can pull out and set up for casual use. They were reasonably cheap on their own to acquire at the time, but the freight shipping certainly was not cheap. If someone in the Seattle area is really interested in an ES47 system, let me know, although I wouldn't want to just give them away completely free at this point.
Re: Orphan HP Alphaservers looking for a new home
Dear Richard, As soon as I saw this message my heart skipped a few beats, merely at the _possibility_ that I might be able to share in some of this hardware. I have been fascinated by my first HP AlphaServer DS15, ever since an acquaintance at the local hackspace kindly gave it to me. Here are some photos: https://www.dropbox.com/sh/jxxkmh9fiaqdsjw/AAC5QdhR8NXE-Id5A44UYWRya?dl=0 I would love to take it all, and would gladly pay for shipping and insurance to the UK. But I don't want to be greedy either. Maybe there are other people on this list who would like to, or ought to, experience the same exhilaration as owning an AS. Having a small cluster of AlphaServers, plus RAID server and fibre switches, fits in SO PERFECTLY with my side project; it's about formalising methods for distributed computation and then making a libre-friendly distributed computing environment available to interested users in a communal or co-operative environment. I'm currently preparing the x86 portion of the overall project for shipping to colo. Several AS'es in an HA, resilient setup would be such a perfect complement. Please let me what you think! I value comments and questions from all. Kind regards, Andrew Sent from my mobile phone > On 17 Dec 2018, at 23:02, Richard Loken via cctalk > wrote: > > Ladies and gentlemen, > > I have immediate access to four Alphaservers, an RA8000 raid server, > and the associated fibre switches in need of a new home. > > There three servers that were running Tru64 Unix 5 when shut down a week > ago, they are a DS15, and two ES45s. There is also a third ES45 which > has not run in a decade and was kept around as a cold spare. > > None of the RA8000 disk will be available because the present owner is > protecting his data (of course) but all of the unused spare disks are > available and they will fit the internal slots in the DS15 and ES45s > which may or may not have disks depending on the whim of the present owner. > > Lots of paper docs and Tru64 OS installation kits but no licenses. > > They can be had for free but shipping will most assuridly not be free. > > -- > Richard Loken VE6BSV : "...underneath those tuques we wear, > Athabasca, Alberta Canada : our heads are naked!" > ** rllo...@telus.net ** :- Arthur Black
Re: Lots of unused CompacTape IV Cartridges Available
Hi Richard: I have a couple of compatible drives that I use on my Microvaxes, if you could spare say 6 then that’d be great. I live in Vancouver and of course would pay shipping! Kevin McQuiggin Sent from my iPad > On Dec 17, 2018, at 15:07, Richard Loken via cctalk > wrote: > > I have access to a trove of maybe 10 dozen unused CompacTape IV cartridges. > > These can be had free for the cost of shipping. I may be able to talk > them out of a few DLT4000 and DLT tape drives as well, I don't know about > that part. > > Anybody besides me still backing up his data on DLTs? I have a lifetime > of spare cartridges already. > > -- > Richard Loken VE6BSV : "...underneath those tuques we wear, > Athabasca, Alberta Canada : our heads are naked!" > ** rllo...@telus.net ** :- Arthur Black
Re: Orphan HP Alphaservers looking for a new home
On 12/17/18 4:27 PM, Richard Loken via cctalk wrote: > Anything > Tru64 Unix does VMS does better. Anything Linux does Tru64 Unix does > better. > > Have I made my bigotry clear? > Spoken like a true VMS Jackass Some things stay constant over the DECades
Re: Orphan HP Alphaservers looking for a new home
On Mon, 17 Dec 2018, Tapley, Mark via cctalk wrote: Wikipedia reports there is some variability in ES45 models, including number of CPU and amount of memory. Any idea what model/spec these are? If I recall correctly the ES45s each have 2 CPUs. The three ES45s are not intentical, the one that was purchased first had a CPU upgrade after a couple years but I do not recall either part number. I have no idea what the other two have for CPUs. Two of them have 32Gbyte of RAM, the cold spare is unknown. Also: ?...The AlphaServer SC was a supercomputer constructed from a set of These were single computers that happen to be in the same rack. Two of them have the special HP cluster card whose name and number I forget so they were formed into a TruCluster once upon a time. I hope hard enough that this cluster gets saved that if no-one else comes forward, I?d like to be notified?.I?m not certain what I could arrange, but the thought of running my own personal Alpha supercomputer ? wow. Not sure how to solve the license issue though. I assume OpenVMS doesn?t support that level of parallelization? I assume that VMS does support that level of parallelization. Anything Tru64 Unix does VMS does better. Anything Linux does Tru64 Unix does better. Have I made my bigotry clear? You will seriously raise your electric bill and somewhat lower your heating bill. All of this hardware is 120V single phase but it would like a couple circuit breakers all to itself. -- Richard Loken VE6BSV: "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rllo...@telus.net ** :- Arthur Black
Re: Orphan HP Alphaservers looking for a new home
On Mon, 17 Dec 2018, Grant Taylor via cctalk wrote: On 12/17/2018 04:02 PM, Richard Loken via cctalk wrote: I have immediate access to four Alphaservers, an RA8000 raid server, and the associated fibre switches in need of a new home. Where are the servers located? Are they in Athabasca, Alberta Canada near you? Yes, they are within 1/2 mile of me... In Athabasca, Alberta Canada Is the owner keeping the raw disks or are they disks staying in sleds / enclosures? Read: Are the enclosures sans-disks available? I can get the sleds if they are of use to you. These machines all use the narrow HP Storage Works carriers not the wide blue or green ones. They can be had for free but shipping will most assuridly not be free. Does it need to move as a single lot? Or is someone (you?) willing to passel things out (assuming everything moves relatively quickly)? All the dispersal, packing, and shipping will be done by me. The owner wants no part of it. I am willing to send small quantities of things hither and yon. Shipping a DS15 will be hard work but possible, shipping an ES45 will be seriously hard. I am unwilling to box and ship the RA8000/HSG80 but I am willing to part it out. Anybody who wants to come visit Athabasca with a 1/2 ton truck can have the whole lot including the 7 foot rack or a subset of the whole. I would be thrilled not to have to pack and ship stuff. -- Richard Loken VE6BSV: "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rllo...@telus.net ** :- Arthur Black
Re: Orphan HP Alphaservers looking for a new home
On 12/17/2018 04:45 PM, Tapley, Mark via cctalk wrote: I hope hard enough that this cluster gets saved that if no-one else comes forward, I’d like to be notified….I’m not certain what I could arrange, but the thought of running my own personal Alpha supercomputer … wow. Agreed. Not sure how to solve the license issue though. I assume OpenVMS doesn’t support that level of parallelization? I'm not sure what to make of OpenVMS doesn't support this level of parallelization. I know that (Open)VMS has some impressive clustering abilities. But I don't know how parallel different jobs can be. I would assume that it is highly dependent on the job at hand and how it was coded. -- Grant. . . . unix || die
Re: Orphan HP Alphaservers looking for a new home
> On Dec 17, 2018, at 5:32 PM, Grant Taylor via cctalk > wrote: > > On 12/17/2018 04:02 PM, Richard Loken via cctalk wrote: >> I have immediate access to four Alphaservers, an RA8000 raid server, and the >> associated fibre switches in need of a new home. > > Where are the servers located? Are they in Athabasca, Alberta Canada near > you? > >> There three servers that were running Tru64 Unix 5 when shut down a week >> ago, they are a DS15, and two ES45s. There is also a third ES45 which has >> not run in a decade and was kept around as a cold spare. >> None of the RA8000 disk will be available because the present owner is >> protecting his data (of course) but all of the unused spare disks are >> available and they will fit the internal slots in the DS15 and ES45s which >> may or may not have disks depending on the whim of the present owner. > > Understandable. > > Is the owner keeping the raw disks or are they disks staying in sleds / > enclosures? Read: Are the enclosures sans-disks available? > >> Lots of paper docs and Tru64 OS installation kits but no licenses. > > ACK > >> They can be had for free but shipping will most assuridly not be free. > > Does it need to move as a single lot? Or is someone (you?) willing to passel > things out (assuming everything moves relatively quickly)? > > -- > Grant. . . . > unix || die Wikipedia reports there is some variability in ES45 models, including number of CPU and amount of memory. Any idea what model/spec these are? Also: “...The AlphaServer SC was a supercomputer constructed from a set of individual DS20L, ES40 or ES45 servers (called "nodes") mounted in racks….” I hope hard enough that this cluster gets saved that if no-one else comes forward, I’d like to be notified….I’m not certain what I could arrange, but the thought of running my own personal Alpha supercomputer … wow. Not sure how to solve the license issue though. I assume OpenVMS doesn’t support that level of parallelization? - Mark
Re: Orphan HP Alphaservers looking for a new home
On 12/17/2018 04:02 PM, Richard Loken via cctalk wrote: I have immediate access to four Alphaservers, an RA8000 raid server, and the associated fibre switches in need of a new home. Where are the servers located? Are they in Athabasca, Alberta Canada near you? There three servers that were running Tru64 Unix 5 when shut down a week ago, they are a DS15, and two ES45s. There is also a third ES45 which has not run in a decade and was kept around as a cold spare. None of the RA8000 disk will be available because the present owner is protecting his data (of course) but all of the unused spare disks are available and they will fit the internal slots in the DS15 and ES45s which may or may not have disks depending on the whim of the present owner. Understandable. Is the owner keeping the raw disks or are they disks staying in sleds / enclosures? Read: Are the enclosures sans-disks available? Lots of paper docs and Tru64 OS installation kits but no licenses. ACK They can be had for free but shipping will most assuridly not be free. Does it need to move as a single lot? Or is someone (you?) willing to passel things out (assuming everything moves relatively quickly)? -- Grant. . . . unix || die
Lots of unused CompacTape IV Cartridges Available
I have access to a trove of maybe 10 dozen unused CompacTape IV cartridges. These can be had free for the cost of shipping. I may be able to talk them out of a few DLT4000 and DLT tape drives as well, I don't know about that part. Anybody besides me still backing up his data on DLTs? I have a lifetime of spare cartridges already. -- Richard Loken VE6BSV: "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rllo...@telus.net ** :- Arthur Black
Orphan HP Alphaservers looking for a new home
Ladies and gentlemen, I have immediate access to four Alphaservers, an RA8000 raid server, and the associated fibre switches in need of a new home. There three servers that were running Tru64 Unix 5 when shut down a week ago, they are a DS15, and two ES45s. There is also a third ES45 which has not run in a decade and was kept around as a cold spare. None of the RA8000 disk will be available because the present owner is protecting his data (of course) but all of the unused spare disks are available and they will fit the internal slots in the DS15 and ES45s which may or may not have disks depending on the whim of the present owner. Lots of paper docs and Tru64 OS installation kits but no licenses. They can be had for free but shipping will most assuridly not be free. -- Richard Loken VE6BSV: "...underneath those tuques we wear, Athabasca, Alberta Canada : our heads are naked!" ** rllo...@telus.net ** :- Arthur Black
Re: 8-Update
Thanks Jay, I think this means I’m starting to seriously consider a printer. :-( Zane > On Dec 17, 2018, at 1:31 PM, Jay Jaeger via cctalk > wrote: > > Typically the files on Thingiverse are .STL format, which is portable 3D > model. One feeds it into a slicer program (there are several to choose > from) to produce GCode that uses the specifications of one's particular > printer so that the right GCode gets spit out. > > On 12/17/2018 3:26 PM, Zane Healy via cctalk wrote: >> Are the files “platform independent”? I know very little about 3D printing, >> but have been tempted to get a printer for a while now. Though I’m worried >> about what my kids wanting to use it. :-) >> >> Zane
Re: CDC floppy disks on Ebay.
I suspected they were GE-PAC related. Ended up getting them, we'll see if they are readble He would have made 5x more if he wouldn't have ignored my offer, sucks to be him. On 12/17/18 12:48 AM, Camiel Vanderhoeven via cctalk wrote: > On 12/9/18, 10:40 PM, "cctech on behalf of Mattis Lind via cctech" > wrote: > > Don't know if this worth saving. https://www.ebay.com/itm/283294561797 > > 8 inch CDC disks from 1982. Maybe something interesting? > > I know what the software on those disks is, because I have these floppies too > (and the system they're for). These are diagnostics for a 24-bit Honeywell > 4500 process computer (a successor to the GE PAC 4000 system; some pictures > on my website: https://vaxbarn.com/index.php/other-bits/654-honeywell-4500). > I haven't imaged the ones I have yet, but I will get around to it eventually. > Mine are CDC branded floppies as well, and the diskette drive that came with > the 4500 was a Honeywell-labeled CDC drive. > > Camiel > > >
Re: 8-Update
Typically the files on Thingiverse are .STL format, which is portable 3D model. One feeds it into a slicer program (there are several to choose from) to produce GCode that uses the specifications of one's particular printer so that the right GCode gets spit out. On 12/17/2018 3:26 PM, Zane Healy via cctalk wrote: > Are the files “platform independent”? I know very little about 3D printing, > but have been tempted to get a printer for a while now. Though I’m worried > about what my kids wanting to use it. :-) > > Zane > > > > > On Dec 17, 2018, at 1:12 PM, Torfinn Ingolfsen via cctalk > wrote: >> >> >> FWIW, the easiest way to find out if somebody has made (or has tried >> to make) replacement parts for anything that can be 3D-printed is to >> go to thingiverse.com with your web browser. >> And then search for whatever thing you need (search terms / words are >> a separate subject, try as wide or as many as have time for. >> When you find a part, look at pictures, comments, makes and so on to >> try to figure out if this is a working part or just something somebody >> has mad a 3D model of, and never tested. >> Some relevant examples: >> https://www.thingiverse.com/thing:360853 PDP-8 Panel Switch Toggle >> https://www.thingiverse.com/thing:386762 DEC RL-02 Spindle Ground Brush >> https://www.thingiverse.com/thing:2454690 PDP Stand - Mount >> >> HTH >> On Sun, Dec 16, 2018 at 10:35 PM Al Kossow via cctalk >> wrote: >>> >>> >>> >>> On 12/15/18 11:36 PM, Rod G8DGR via cctalk wrote: >>> However I began to think would it be possible to create a close copy of an 8/e out of modern parts. >>> >>> Redoing the CPU in obtanium TTL would be desirable. >>> >>> >> >> >> -- >> mvh >> Torfinn > >
Re: 8-Update
Are the files “platform independent”? I know very little about 3D printing, but have been tempted to get a printer for a while now. Though I’m worried about what my kids wanting to use it. :-) Zane On Dec 17, 2018, at 1:12 PM, Torfinn Ingolfsen via cctalk wrote: > > > FWIW, the easiest way to find out if somebody has made (or has tried > to make) replacement parts for anything that can be 3D-printed is to > go to thingiverse.com with your web browser. > And then search for whatever thing you need (search terms / words are > a separate subject, try as wide or as many as have time for. > When you find a part, look at pictures, comments, makes and so on to > try to figure out if this is a working part or just something somebody > has mad a 3D model of, and never tested. > Some relevant examples: > https://www.thingiverse.com/thing:360853 PDP-8 Panel Switch Toggle > https://www.thingiverse.com/thing:386762 DEC RL-02 Spindle Ground Brush > https://www.thingiverse.com/thing:2454690 PDP Stand - Mount > > HTH > On Sun, Dec 16, 2018 at 10:35 PM Al Kossow via cctalk > wrote: >> >> >> >> On 12/15/18 11:36 PM, Rod G8DGR via cctalk wrote: >> >>> However I began to think would it be possible to create a close copy of an >>> 8/e out of modern parts. >> >> Redoing the CPU in obtanium TTL would be desirable. >> >> > > > -- > mvh > Torfinn
Re: 8-Update
FWIW, the easiest way to find out if somebody has made (or has tried to make) replacement parts for anything that can be 3D-printed is to go to thingiverse.com with your web browser. And then search for whatever thing you need (search terms / words are a separate subject, try as wide or as many as have time for. When you find a part, look at pictures, comments, makes and so on to try to figure out if this is a working part or just something somebody has mad a 3D model of, and never tested. Some relevant examples: https://www.thingiverse.com/thing:360853 PDP-8 Panel Switch Toggle https://www.thingiverse.com/thing:386762 DEC RL-02 Spindle Ground Brush https://www.thingiverse.com/thing:2454690 PDP Stand - Mount HTH On Sun, Dec 16, 2018 at 10:35 PM Al Kossow via cctalk wrote: > > > > On 12/15/18 11:36 PM, Rod G8DGR via cctalk wrote: > > > However I began to think would it be possible to create a close copy of an > > 8/e out of modern parts. > > Redoing the CPU in obtanium TTL would be desirable. > > -- mvh Torfinn
IF you need these old vintage parts, PLEASE grab them before the keyboard keids do!
https://www.elecshopper.com/vintage-computers.html I really would rather these go to someone who needs them to complete a system than to the destroyers of keyboards. I am trying to get more of the vintage stuff listed. If you want to see items as they are listed online, please turn on your RSS feeds. https://www.elecshopper.com/rss/ Cindy Croxton Electronics Plus 1613 Water Street Kerrville, TX 78028 830-370-3239 cell sa...@elecplus.com --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Core memory emulator using non volatile ram.
On 12/17/18 9:51 AM, Guy Sotomayor Jr wrote: > Except it is *much* more expensive than MRAM. 32x8 NVSRAM is $18.50 in qty 1 > from Digikey. > A 64Kx16 MRAM is $11.84 in qty 1 from Digikey. MRAM requires no additional > circuitry so that > also reduces the overall cost (and has unlimited write endurance). nvSRAM is sole-sourced technology, so there's a premium. The crazy thing is that I was using the Xicor NOVRAM in the late 70s-early 80s. I still have a parts drawer full of X2444 8-pin DIPs from about that time. The technology appears to be roughly the same. Xicor got gobbled up by Intersil V2; Intersil V1 got gobbled up by Harris and then spun off again as Intersil V2 and then gobbled up by Renesas. You really need a program to tell the players apart. FWIW, there seems to be increasing interest in NVDIMMs: https://www.electronicdesign.com/industrial-automation/why-are-nvdimms-suddenly-hot I have no doubt that by the time they're wiping the drool from my face and wheeling me in front of the TeeVee to pass the time, that engineers will be discussing their favorite 20 psec. 8 exabyte non-volatile RAM chips... --Chuck
Re: Core memory emulator using non volatile ram.
> On Dec 17, 2018, at 10:52 AM, Noel Chiappa via cctalk > wrote: > >> From: Paul Koning > >> For that matter, core memory details such as destructive read weren't >> visible to the CPU > > Umm, not quite. If you'd said 'core memory details such as destructive read > weren't visible to the _program_', you'd have been 100% correct. > > But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do > use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in > QBUS) where possible precisely for the benefit of core memory with its > destructive readout. (And there's some hair for interlocking the multiple > CPU's on the -11/74 which I don't recall off the top of my head.) > > And I have a vague memory of something similar on other early DEC machines; > probably some -8 models. But it does *no* harm if the underlying memory does *not* have a destructive read-out. Otherwise all of those (even DEC branded) MOS memory boards wouldn’t work. ;-) The DATIP and friends were an optimization implemented in the bus protocol to allow for it to take advantage of the behavior of core. However, nothing breaks if the memory doesn’t implement a destructive read-out. TTFN - Guy
Re: Core memory emulator using non volatile ram.
> On Dec 17, 2018, at 1:52 PM, Noel Chiappa via cctalk > wrote: > >> From: Paul Koning > >> For that matter, core memory details such as destructive read weren't >> visible to the CPU > > Umm, not quite. If you'd said 'core memory details such as destructive read > weren't visible to the _program_', you'd have been 100% correct. > > But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do > use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in > QBUS) where possible precisely for the benefit of core memory with its > destructive readout. (And there's some hair for interlocking the multiple > CPU's on the -11/74 which I don't recall off the top of my head.) No, that doesn't invalidate what I said. DATAIP/DATAO on the Unibus doesn't depend on the destructive read property. It works just fine with DEC semiconductor memory. It is perfectly valid to implement DATAIP as if it were DATAI, so that transaction simply becomes a read followed by a write. The reason it existed is that it allows core memory to optimize the timing, by running a "half cycle", omitting the restore part. But the DATAO supplies the new content of the word, and so long as the memory does that write you're all set. If PDP-11s ever did a DATAIP without a DATAO, you'd be able to tell the difference between core and semiconductor memory by reading the location afterwards and looking for non-zero. But conforming Unibus masters don't do that. paul
Re: Core memory emulator using non volatile ram.
> From: Paul Koning > For that matter, core memory details such as destructive read weren't > visible to the CPU Umm, not quite. If you'd said 'core memory details such as destructive read weren't visible to the _program_', you'd have been 100% correct. But as I suspect you know, just overlooked, most (all?) of the -11 CPU's do use 'read-modify-write' cycles on the bus (DATIP in UNIBUS terms, DATIO in QBUS) where possible precisely for the benefit of core memory with its destructive readout. (And there's some hair for interlocking the multiple CPU's on the -11/74 which I don't recall off the top of my head.) And I have a vague memory of something similar on other early DEC machines; probably some -8 models. Noel
Re: Core memory emulator using non volatile ram.
I've seen a lot of talk about memory technologies, but as far as I can see, no one has offered any complete solutions. One already exists, thanks to the efforts of Steve Lafferty, Vince Slyngstad, and others. http://so-much-stuff.com/pdp8/32KOmnibus/32KOmnibus.php Yes, it uses a battery. FPGAs and CPLDs are not needed (though a CPLD could reduce all of the logic and drivers to a single chip, with the ATF1508). Numerous Omnibus PDP-8 owners have these cards, and I swear by them in my machines. I'd much rather keep a hefty load off of the power supply and free up 11 card slots, especially in my 8/M. Maybe with enough interest, Vince would consider doing another run of boards. Thanks, Kyle
Re: Core memory emulator using non volatile ram.
> On Dec 17, 2018, at 12:51 PM, Guy Sotomayor Jr via cctalk
> wrote:
>
>
>
>> On Dec 16, 2018, at 10:40 PM, Chuck Guzis via cctalk
>> wrote:
>>
>> On 12/16/18 11:21 AM, Paul Koning wrote:
>>
>>> If you simply want non-volatile memory, the obvious answer is SRAM with
>>> battery backup and a small FPGA to do the interfacing.
>>
>> I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM
>> from flash on power-up and stores into flash at power-down. All that's
>> needed is a capacitor to extend the power-down cycle a bit.
>>
>> Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per
>> package.
>>
>> Claims to be guaranteed for 1M power cycles and doesn't require a battery.
>
> Except it is *much* more expensive than MRAM. 32x8 NVSRAM is $18.50 in qty 1
> from Digikey.
> A 64Kx16 MRAM is $11.84 in qty 1 from Digikey. MRAM requires no additional
> circuitry so that
> also reduces the overall cost (and has unlimited write endurance).
>
> If it sounds like I’m harping on MRAM, maybe I am. I’ve looked at the
> various technologies in
> detail (what’s available, cost, interfacing, etc, etc) for years and for
> anything that requires
> non-volatility, MRAM wins until you get into seriously large sizes at which
> point you need to
> go to FLASH for economics.
I'll go along with that. I worked on a storage product that needed
non-volatile memory in modest sizes for tracking transaction states. The first
product used FRAM for that, the second used SRAM backed by a small battery
("coin cell") and the third used MRAM. All worked fine. FRAM supposedly has
endurance limits but they are high enough they weren't a concern. The main
issue was the size limits, at least at the time (2003-ish).
For simplicity, battery backed SRAM should be just as good as SRAM. In any
case, you presumably will need a CPLD or small FPGA for the interface protocol
conversion.
paul
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 10:40 PM, Chuck Guzis via cctalk > wrote: > > On 12/16/18 11:21 AM, Paul Koning wrote: > >> If you simply want non-volatile memory, the obvious answer is SRAM with >> battery backup and a small FPGA to do the interfacing. > > I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM > from flash on power-up and stores into flash at power-down. All that's > needed is a capacitor to extend the power-down cycle a bit. > > Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per > package. > > Claims to be guaranteed for 1M power cycles and doesn't require a battery. Except it is *much* more expensive than MRAM. 32x8 NVSRAM is $18.50 in qty 1 from Digikey. A 64Kx16 MRAM is $11.84 in qty 1 from Digikey. MRAM requires no additional circuitry so that also reduces the overall cost (and has unlimited write endurance). If it sounds like I’m harping on MRAM, maybe I am. I’ve looked at the various technologies in detail (what’s available, cost, interfacing, etc, etc) for years and for anything that requires non-volatility, MRAM wins until you get into seriously large sizes at which point you need to go to FLASH for economics. TTFN - Guy
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 10:49 PM, Rod G8DGR via cctech > wrote: > > > I’m trying to make a look and feel reproduction PDP-8/e. > So the memory characteristics need to be as close as possible. > > An original ( and I do have one) and the copy when placed side by side > should run in sync. > When executing he same code – What code I couldn’t care. > > Rod All you need for that to be true is to use the same bus timing as the original. What happens behind the scenes is unimportant. At LCM while restoring their CDC 6500 they built replacement memory modules, which actually mimic not just core memory cycle timing but also core memory waveforms -- which took some fiddling with pulse transformers. But behind the interface logic there's simple modern memory, probably SRAM, I forgot. paul
Re: Hayes Transet Manual and Software
On Sun, 16 Dec 2018, Jason T via cctalk wrote: One of my few remaining Holy Grail items, I got a Hayes Transet 1000 this week. My three-part Hayes stack is now complete. I've scanned the manual and quick-ref card. The scan is not up to the quality of my usual work, as I tried a new technique using a DSLR instead of a scanner so I wouldn't have to take the manual apart. The results are good enough to read, but that's about it. I'll re-do it again someday with the proper tools. Here's the link: Jason, you can send it my direction for scanning if you like. I built a book scanner a while back to handle all the Crescent Software manuals I have. Here's a fully processed example: http://annex.retroarchive.org/crescent/PDQ%20Comm.pdf - I did that one this morning. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
Re: Core memory emulator using non volatile ram.
On Sunday (12/16/2018 at 10:40PM -0800), Chuck Guzis via cctalk wrote: > On 12/16/18 11:21 AM, Paul Koning wrote: > > > If you simply want non-volatile memory, the obvious answer is SRAM with > > battery backup and a small FPGA to do the interfacing. > > I proposed nvRAM - CMOS SRAM backed by cell-for-cell flash. Loads SRAM > from flash on power-up and stores into flash at power-down. All that's > needed is a capacitor to extend the power-down cycle a bit. > > Very fast, available in 8 to 32-bit wide architectures, up to 16Mbit per > package. > > Claims to be guaranteed for 1M power cycles and doesn't require a battery. These are pretty neat. Took me a bit to find an example. They like to call it "NvSRAM", http://www.cypress.com/search/psg/1259#/?_facetShow=ss_ppart_family,ss_pinterface,fs_pdensity_kb_,ss_porganization_x_x_y_,ss_ppackage,ss_pfrequency_mhz_,fs_pspeed_ns_,ss_ptemp_classification,fs_pmin_operating_temp_c_,fs_pmax_operating_temp_c_,fs_pmin_operating_voltage_v_,fs_pmax_operating_voltage_v_,fs_pmin_operating_vccq_v_,fs_pmax_operating_vccq_v_,ss_ptape_reel,ss_pautomotive_qualified,fs_part_price_pinterface=Parallel_pmin_operating_voltage_v_=4.5_pmin_operating_voltage_v_=4.5 which is a typical 32K x 8, 5V device. The "flash" subsystem is something they call SONOS / QuantumTrap technology. Takes 8mS to STORE the SRAM to the backing store at power down and 20mS to RECALL it at power up. The storage cap is typically 68uF so nothing monster. Chris -- Chris Elmquist
Re: Core memory emulator using non volatile ram.
> On Dec 16, 2018, at 10:07 PM, ben via cctalk wrote: > > On 12/16/2018 8:00 PM, allison via cctech wrote: > >> In the end, current generation CMOS ram is the easy out, battery is >> small, cost is small, and >> produces much less of the heat that is killer to systems. The only >> reason to do that is core >> cost big if you can find it for your machine. I can cost more if you >> want to run an OS that >> needs a fair amount of it. AC as well as it can help heat the room and >> also power as in >> makes the meter spin. >> So much lathering and speculation about what and how. When the point is >> totally missed. >> Allison > > What programs or operating sytems require non volatile core? > Did DEC have any BOOTSTRAP programs in prom for the 8? > A small prom and regular slow mos memory may be the solution. > Ben. Before boot ROMs, it was standard practice to toggle the boot loader into core where it would be available indefinitely, including across power cycles. You can see this in the PDP-8, and it was also documented in the early days of the PDP-11 (though in 1973 I didn't have to do this, we had a 16-word diode matrix boot ROM). RSTS-11 V4 had optional power fail handling, which would allow it to continue running after a power cycle. Not by rebooting as later versions did, but by continuing from where it left off. It would have to reinitialize the I/O devices since I/O registers are volatile, but the OS in memory would be intact and logged in user sessions would be preserved. I actually saw that work once, pretty neat. For all this, the only necessary memory property is simply that the contents was preserved across power cycles. None of the other details of core memory are important. For that matter, core memory details such as destructive read weren't visible to the CPU; the read/restore cycle was handled inside the core memory logic. That's typical; one exception I know of is the CDC 6000 series peripheral processor, which I mentioned before: there the restore cycle is part of the main execution pipeline. That's why readstart (system reboot) drops a zero in memory, it disrupts that read/restore cycle. paul
Re: flashx20 - Floppy and screen for the Epson HX-20
On 12/16/2018 11:39 PM, Will Cooke via cctalk wrote: > > > > > > On December 16, 2018 at 11:14 PM allison via cctalk > wrote: >>> On Sun, 16 Dec 2018, Norbert Kehrer via cctalk wrote: I have not tested it, but I suppose, that also the PX-8 and PX-4 used the protocol, because the protocol specification defines the following device numbers: - HX-20: 0x20 (probably also used for the HC-20) - PX-8: 0x22 - PX-4: 0x23 >>> >>> >> PX-8! >> > A subject dear to me. I still have the px-8 I bought new (borrowed the money > from my sister) as a young man in 1984. Alas, I could never afford the PF-10 > disk drive. > > >>> However, the PX-8 3.5" had 40 cylinders, with 67.5 tpi, instead of the >>> common 80 cylinder 135 tpi of other 3.5" disks. >>> Those 40 cylinder 3.5" drives are quite rare. > Somewhere in my searches I recall reading that the 3 1/2" drives used the > same format as the 5 1/4" ones. Maybe 40 tracks of 16 256 byte sectors. > Oddly, I believe that 2 tracks are "reserved for CP/M" even though it is in > ROM and not stored on disk. > > >> ceramic magnet lost its stuff over time. When I have time the next >> project will be a Atmega2650 running >> a CF to via serial interface. The drive table can be patched for a >> larger (up to 8mb) drive. > I've been planning something very similar for a while, but using an Arduino > (ATMega 328) or bare AVR chip and probably a smaller/simpler flash chip. I > din't know about the drive table. That's interesting. Would a new ROM have > to be burned with the new table? Do you have an links to the info? The system in the base PX-8 has a system area for user patches. the drive table is part of the BIOS and there are provisions for intercepting the calls to there and patching in changes or extensions. Its detailed in the manuals. >>> With appropriate format handling software on the PC, it should be >>> possible for a PC connected using your system to work with actual >>> Epson diskettes, and emulate the Epson external drives. >>> >> There are several software packages on the net to do the fake of the >> disk via serial and manuals of the system to >> explain the format. Likely that software could do the earlier HX20 (and >> friends) with minor tweaks. > Here is one I am familiar with that runs on Linux. Only does drives, AFAIK, > no display. > https://fjkraan.home.xs4all.nl/comp/px4/vfloppy/ Thats true, but the IO on the PX-8 allows for redirection to the serial port for console and even keyboard. I've many times used it with my VT320 to save my poor eyes. > And if anyone is interested here are some more links: > http://oldcomputer.info/8bit/hx20/index.htm#links > Navigating through some of those links takes you to the protocol: > https://fjkraan.home.xs4all.nl/comp/hx20/epsp.html > Note at the bottom of the page it says the PX-8 and CP/M only use four of the > functions. > This link has lots of HX-20 info. > http://electrickery.xs4all.nl/comp/hx20/doc/index.html > The tms files near the bottom (ch 10-11?) describe the protocol and how it > functions in detail. > > Will > Indeed. its all there.
Re: flashx20 - Floppy and screen for the Epson HX-20
On 12/16/2018 11:56 PM, Fred Cisin via cctalk wrote: >> On December 16, 2018 at 11:14 PM allison via cctalk >> wrote: >>> On Sun, 16 Dec 2018, Norbert Kehrer via cctalk wrote: > I have not tested it, but I suppose, that also the PX-8 and PX-4 used > the protocol, > because the protocol specification defines the following device > numbers: > - HX-20: 0x20 (probably also used for the HC-20) > - PX-8: 0x22 > - PX-4: 0x23 >>> PX-8! >>> >> A subject dear to me. I still have the px-8 I bought new (borrowed >> the money from my sister) as a young man in 1984. Alas, I could >> never afford the PF-10 disk drive. >> I've had one for many decades and 2 more for well, now its two decades. Handy little critter and they do see use. >> However, the PX-8 3.5" had 40 cylinders, with 67.5 tpi, instead of the common 80 cylinder 135 tpi of other 3.5" disks. Those 40 cylinder 3.5" drives are quite rare. > > On Sun, 16 Dec 2018, Will Cooke via cctalk wrote: >> Somewhere in my searches I recall reading that the 3 1/2" drives used >> the same format as the 5 1/4" ones. Maybe 40 tracks of 16 256 byte >> sectors. Oddly, I believe that 2 tracks are "reserved for CP/M" even >> though it is in ROM and not stored on disk. > > It was not uncommon for CP/M disks to have "reserved" or "system" > tracks, even when the particular disk was not a bootable "system" disk. > Standard SSSD 8" that is the case the fist two tracks are for "system" and the system is loaded from those. Most other do a variation depending on format and space. CP/M ( the modules CCP, BDOS, BIOS) fits in about 8k so that defines the size of system tracks. CP/M revolves around logical sectors of 128 bytes so anything larger 2556/512/1k requires blocking and deblocking in the bios. > I don't remember for sure, and don't have convenient access to my > materials, but 16 256 byte physical sectors makes sense. > Yes, it would be enough. Save for the PX8 has CP/M loaded into ROM so the system tracks are largely wasted. I believe there is some drive and system level configuration information there but we are talking less than a sector or two. > The drive manual > http://electrickery.xs4all.nl/comp/px8/doc/PF-10Manual.pdf > SAYS 9 512 byte sectors, but that seems likely to be in error from a > cut and paste boilerplate from a different machine, because the more > specific information is all for "64 sectors", which means CP/M RECORDS > or "logical sectors" of 128 bytes each. THAT would be consistent with > either 8 512 byte PHYSICAL sectors, or 16 256 byte PHYSICAL sectors. > It seems that way as it matches the PF-20 5.25" drive. However the format on the drive also seems consistent at 9x512. Its not uncommon to use the whole system track or two even if it has "excess" space. Often the first sector contains the full disk book rather than a minimal 1 sector boot. There is a lot of latitude and mostly why copy format programs such as yours existed due to same drive and media and many many different formats. I've gotten away from rotating media on a few of my CP/M systems and they go to the edge of what CP/M permits as in EPROM loaded, ROMdisks, RAMdisks and CF. Allison
RE: Hayes Transet Manual and Software
>-Original Message- >From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Jason T via >cctalk >Sent: Monday, December 17, 2018 12:44 AM >To: General Discussion: On-Topic and Off-Topic Posts >Subject: Hayes Transet Manual and Software > >One of my few remaining Holy Grail items, I got a Hayes Transet 1000 >this week. My three-part Hayes stack is now complete. > >... > >-j Excellent! In your Hayes explorations have you come across any technical documentation for the Hayes Micromodem-100, the successor to the 80-103A? All that I've been able to uncover is a marketing brochure. Would like to uncover more ... Thank you, paul
Re: CDC floppy disks on Ebay.
On 12/9/18, 10:40 PM, "cctech on behalf of Mattis Lind via cctech" wrote: Don't know if this worth saving. https://www.ebay.com/itm/283294561797 8 inch CDC disks from 1982. Maybe something interesting? I know what the software on those disks is, because I have these floppies too (and the system they're for). These are diagnostics for a 24-bit Honeywell 4500 process computer (a successor to the GE PAC 4000 system; some pictures on my website: https://vaxbarn.com/index.php/other-bits/654-honeywell-4500). I haven't imaged the ones I have yet, but I will get around to it eventually. Mine are CDC branded floppies as well, and the diskette drive that came with the 4500 was a Honeywell-labeled CDC drive. Camiel
