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
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.
-- 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…
> > 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).
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
> 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
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
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.
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
>
Hi folks,
I guess people have looked at the pdp-8/m-2 Chassis:
http://hisdeedsaredust.com/pdp/pdp8m-2/04112008359.jpg
There are some interesting goodies as it's completely max'd out!
It appears to have 3x8K memory (a stunning 24K!).
M8320 = OmniBus Bus terminator loads.
G111 = 8K Memory.
M849 = Memory Shield.
M8357 = RX8E (8" Dual Floppy controller).
M8650 = Teletype control.
M847YA = Hardware Bootstrap Loader.
M8350 = Posibus interface (surprising).
M837 = Memory Extension / Timeshare.
M8300 = CPU Regs.
M8310 = CPU Regs Ctrl.
M8330 = CPU Timing.
It was last tested (amazingly) as late as July 1990, a mere 18 years ago.
Again, I'm wondering who took the pdp-8/m: Was it the Surrey Museum or Peter?
Also Peter, you said it was a simple circuit, do you have the circuit diagrams and procedure for converting a normal PC-based 5.25" Floppy drive to work as an RX-50? I did use PUTR recently on a PC to transfer RT-11 to 5.25" disk so I could install it on my pdp-11/73 (before the PSU failed!); so I know they *can* be used in some sense.
Also Johnny, are you actually offering a pdp-8/m or /f!!!!?
-cheers from julz @P