test-drb

test-drb@ccmp.vtda.org

101090 discussions

Saving 1962(year) mainframe data

by roger.holmes＠microspot.co.uk

> From: Oliver Lehmann <lehmann at ans-netz.de> > >> Before doing this I would like to put these into modern machine >> readable form so they can be published on the web. > > Maybe the person(s) behind http://www.ict1301.co.uk/ have some > interest > in this too? That is the web site of my project and describes the computer I have kept. Two of us work on the project, Rod Brown being the other person, and he does the web design, but he has not enough web space for anywhere near the amount of data which needs to be published.

17 years, 5 months

Who wants to help read a Saturn V core stack?

by RodSmallwood＠mail.ediconsulting.co.uk

It had both core and rope http://en.wikipedia.org/wiki/Core_rope_memory Rod -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] On Behalf Of Chuck Guzis Sent: 11 November 2008 07:40 To: General Discussion: On-Topic and Off-Topic Posts Subject: RE: Who wants to help read a Saturn V core stack? On 10 Nov 2008 at 22:37, dwight elvey wrote: > Reading shouldn't be too difficult. Outputs could be recorded by a > digital scope. The rise times of the address and inhibit lines are > mostly to be slow enough that it doesn't cause the sense amplifier to > trip on the coupling in the selected address line. > Other addresses are protected by the matching signal on the inhibit > line. Any reasonably slow ramp would work since one is using a scope > to record and not a sense amp. Putting to bed the idea of the "core rope" program store, the 1964 document on the launch computer is pretty clear that this is ordinary read-write core storing the program: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19730063841_19730 63841.pdf In particular, item 2-37 begins "Reading a ferrite-core memory destroys the information in the memory." It then goes on to describe the restore part of a read operation. No mention of "core rope" is made. The document, all 200-some pages contains a great deal of detail on the computer, including memory operation and organization. Cheers, Chuck

17 years, 5 months

Wanted: some HP 9000/3xx bits

by classiccmp＠crash.com

I just received what I believe is an HP 9000/380 (thanks Stan!), details below. I'd like to get hold of the following: - Any 98229 RAM (4, 8, or 16MB) (or Kingston KTH400t/16, Dataram DRH9400 or 69310/69311) - A 3-button HP-HIL mouse - A 98550A framebuffer (or something compatible that'll do 1280x1024 with at least 8 bit color - SRX would be grand) - matching SCSI disk enclosure What I've got is: 98574Y enclosure - classic 9000/3xx look 98574-66511 rev C system board (25MHz 68040, 1818-5062 ROM) w/ 2 98229C 4MB memory cards (98229-66521) 98549A Catseye framebuffer (1024x768, 6 bits) 98626A RS-232 Serial Port (DIO-I ?) card 46021A HP-HIL keyboard (courtesy Weirdstuff Warehouse) Can try for trades, but a lot of my stuff is inaccessible these days so cash-equivalents may be easier. Thanks, --Steve.

17 years, 5 months

Wanted: some HP 9000/3xx bits

by jeff.kaneko＠juno.com

-- Steven M Jones <classiccmp at crash.com> wrote: >I've been using a Dell 2001FP so far. > >I'd better make clear that without a disk, I've only been bringing >it up >in the PROM monitor. The story might be radically different if I >could >actually fire up a windowing environment. > >Hope that omission hasn't caused any problems. Oh, no, I was just curious, because finding a monitor that will do sync-on-green seems to be something of a hit-and-miss proposition. ____________________________________________________________ Access from anywhere - Satellite Internet. Click here http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw2XGao1VzpB65liFC56puaWgvg…

17 years, 5 months

seeking SS20

by james＠jdfogg.com

> > I have one that is maxed out. It has everything you > > could want in a SS20, incl. VSIMM. I have never booted > > it, but I got it directly from when it was retired. > > Sounds nice. What processor cards are installed? Can you > tell me anything about the VSIMM capacity? I haven't touched the box in a long time. What I remember is that it had two processors, and they were the fastest available for that model. It had the largest VSIMM available (8Mb?). It had 2 disks. As I recall, it had the maximum possible memory compliment. Everything I remember about the box says that as SS20's go, it couldn't get any better. > > I'd mostly be interested in trades. > > What sort of stuff are you looking to acquire? My interests are wide and varied: Old computers (pretty well set with Sun and DEC), radio (ham radio and tube receivers like All American 5's), photography (film/digital) and interesting old tidbits of technology. The one thing I have yet to find is anything from Data General. I have family that wrote AOS/VS for DG and finding and example would be really nice. One need I have is for a microscope capable of 200x or 400x for working with my barnyard animals (I'll spare you the details of what I need to look for at the microscopic level).

17 years, 5 months

N8VEM Backplane - a set on Flickr

by lynchaj＠yahoo.com

Hi! I just noticed this excellent photo set on Flickr (Thanks Twylo!) and thought some of the people on CCTALK might be interested. http://flickr.com/photos/twylo/sets/72157608408069347/ Thanks! Have a nice day! Andrew Lynch

17 years, 5 months

Who wants to help read a Saturn V core stack?

by roger.holmes＠microspot.co.uk

> From: dwight elvey <dkelvey at hotmail.com> > >> From: ard at p850ug1.demon.co.uk >> >>> >>> Those of you with experience reading cores, we need your help in >>> reading out a LVDC core stack. >> >> Ouch!. I don't have much experience of reading core, but I've >> worked on >> core memory systems (I guess many others here have too). >> >> Rememebr that reading core is destructive. Basically, the read >> operation >> is to write a 0 to each core and see if there was a change in >> magnetic >> flux in that core. If there was, it _was_ a 1. If not, it was (and >> still >> is) a 0. Normally you then write the 1 back if appropriate. >> > > Hi > Reading shouldn't be too difficult. Outputs could be recorded by > a digital scope. Shouldn't that be one digital scope channel for every bit in the word? > The rise times of the address and inhibit lines Do we know this core memory has "inhibit lines"? My only core experience is with 2D planes and I've not heard of inhibit lines, maybe they are the magic that allowed 3D stacks to be made. On my core, half the current required is supplied on two separate wires, if you don't know the current required and you send the critical amount down one wire you will clear the entire memory in one go. > > are mostly to be slow enough that it doesn't cause the sense > amplifier to trip on the coupling in the selected address line. > Other addresses are protected by the matching signal on the inhibit > line. Any reasonably slow ramp would work since one is using a > scope to record and not a sense amp. > The levels needed can be determined experimentally since the amplitude > of the read signal is indepedent of the address signal size > ( assumming > that there is sufficient signal to cause the core to switch ). > There is little leakage of flux outside of the cores. Any method > to read an exterenal flux would be difficult to detect. I doubt > a hall efect would be sensitive enough. Maybe a SQUID could be used. > There are ones that are used to detect small shorts inside of > IC packages. > Still, I think the easiest method is as I described, using an > electrical > method and tries using small increments in the current. > Dwight

17 years, 5 months

Trying again, wanted: volker-craig terminals

by jrowland＠sterlingpipeandtube.com

Hi, I came across your post while looking for information for a VC4404 that came to us. If you are still looking for one, drop me an e-mail. Regards, Jim

17 years, 5 months

seeking SS20

by john_finigan＠yahoo.com

Yes, I have one with a pair of SM52Xs somewhere, for quad SuperSparc at 50 MHz with 1 MB cache each. A couple of years ago I put NetBSD 2.0 on it. Compiling Apache, it was just a little bit faster than dual SM71. Of course, SMP was brand new in NetBSD 2.0 The bummer is that with the 50 MHz CPUs, you have to run 40 MHz bus, since the bus must always be lower frequency than the CPU. What I always wondered is, if Sun could run the SM41 at 40.3 MHz and use the 40 MHz bus, why did the SM51 not run at 50.5 and allow 50 MHz bus? I assume the obvious reason was "they tried and it didn't work." John der Mouse wrote: >> I think the 20 can actually do quad-CPU; while it has only two Mbus >> slots, I seem to recall that someone made Mbus modules with two CPUs in >> a single Mbus form factor. Curt wrote: >It can do quad... Sun had the SM52X (2 SM51s on a almost >double wide cpu card... you could the put two of them in. >Downside was you lost 2 sbus slots. The Sun sold Hypersparc >module HS12 was a dual 100mhz cpu (I believe it was normal >width... so you didn't lose sbus slots to go quad). >If you went with Ross Hypersparc modules there were various >dual cpu on one module configurations.... I know there was >2 variants of dual 125mhz modules (256K, 512K, or 1M of cache). >I know there was a dual 142mhz 1M cache module (which I >believe was extra wide). Those are ones I have or have had. >There are many more.

17 years, 5 months

Saving 1962(year) mainframe data

by roger.holmes＠microspot.co.uk

Thanks for your thoughts, yes I think that could work, though a bit slow for 90,000 cards. As some of the cards are printed, might need to scan them twice, once with a black background and once with white. I might use that method for the 160 column cards. For the 80 column cards, I expect to soon have a working card reader. Now I can get to the logic properly it should not take long to find out why the 'zone' is being decoded incorrectly. The 'numeric' is working fine already so I can read cards with columns of just '0' to '9' on them. One day I should even be able to read pure binary cards through the check reading brushes of the online card punch, though for protection I might remove part of the punching mechanism to stop it making more holes by mistake. I have even been toying with the idea of re-building my spare punch mechanism, putting some TTL logic in it and connecting it directly to my Mac laptop through a serial to USB converter. Might be easier than getting my IBM keypunch working without any diagrams for the relay logic. However, the question I was asking was how to encode these special characters. I currently know of two alternatives. One is to put them in pure text files with a two character sequence for the special characters. ACONIT in France have used a character starting Hex F as a marker. The lower nibble holds four of the bits >from the top 4 rows and the second character holds the bottom eight row bits. This means even fully laced cards can be represented. The other is to put them in UTF8 form which has characters with rings around the numbers 10 to 15. I think they probably have the fraction characters, pound sign etc as well. On 14 Nov, 2008, at 15:01, cctalk-request at classiccmp.org wrote: > > Message: 4 > Date: Thu, 13 Nov 2008 12:30:28 -0800 (PST) > From: Mr Ian Primus <ian_primus at yahoo.com> > Subject: Re: Saving 1962(year) mainframe data > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk at classiccmp.org> > Message-ID: <529044.39317.qm at web52705.mail.re2.yahoo.com> > Content-Type: text/plain; charset=us-ascii > > --- On Thu, 11/13/08, Roger Holmes <roger.holmes at microspot.co.uk> > wrote: > >> The punched cards include columns representing all the >> number 0 to 15 plus 1/4, 1/2, 3/4. I even have some 160 >> column cards, same as 80 column cards but with two round >> hole positions in each normal rectangular hole position. I >> can read the 80 column cards but not the 160 column ones. > > I had actually been thinking about this very problem the other day - > how to read in old punch cards without a functional punch card > reader. I was thinking that a modern automatic sheet feeding scanner > could be pressed into service here. Replace the white backing in the > scanner with black material to provide good contrast. Scan the > cards, preserving order, into a good machine readable format, > something easy to decode. Then, with some not-too-complicated > software, one could "read" the scanned image of the cards, producing > binary data. > > It would be a worthwile (pronounced "fun") hack, and while it > probably wouldn't be able to take the place of a good, high quality > card reader, it should substitute for an unusual or unavailable > reader. > > -Ian >

17 years, 5 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb