Re: Plane of core memory

[Curious Marc via cctalk]

I believe 3 wire memory was first introduced by IBM in their 360 systems, and 
it was a very large development effort. They would almost certainly have 
patented their way to do it, but I have not checked.

Marc

 

From: cctalk  on behalf of 
"cctalk@classiccmp.org" 
Reply-To: Jon Elson , "cctalk@classiccmp.org" 

Date: Thursday, April 18, 2019 at 7:08 PM
To: Noel Chiappa , , 
"cctalk@classiccmp.org" 
Subject: Re: Plane of core memory

 

On 04/18/2019 03:15 PM, Noel Chiappa via cctalk wrote:

  > From: Jon Elson

 

  > As soon as somebody figured out that you could combine the sense and

  > inhibit wires, everybody immediately went to 3-wire planes.

 

I"m suprised the idea wasn't patented. Or maybe it was, and they made the

license widely available at modest terms?

 

 

I was thinking the same thing, but can't find any references 

to who invented it.  it certainly sounds like the sort of 

thing to get a patent on.

 

Point of interest, my freshman advisor was Bill Papian, who 

was Jay W. Forrester's grad student when he invented 

coincident-current core memory.

 

Jon

 

Re: that AGC DSKY auction

[Jim Manley via cctalk]

Bidding hasn't ended on the display electronics, but, it's not clear when
bidding will end, so, bid high and often! :D

On Thu, Apr 18, 2019 at 8:05 PM Adrian Stoness via cctalk <
cctalk@classiccmp.org> wrote:

> weird this only went for 220 bucks
> https://www.rrauction.com/bidtracker_detail.cfm?IN=5109
>

Re: PDP-11/93 and PMI Memory

[Jerry Weiss via cctalk]

The second memory boards CSR should be viable in ODT.

The toggle switch internal contacts may be tarnished with age. Cycle 
each switch, that is used in the on position, multiple times and see if 
the CSR appears.
Try another CSR if necessary to confirm the memory board is responsive 
to Q-bus requests.


Which memory board and rev? MSV11-JE (M8637-E)?

Jerry


On 4/18/19 8:20 PM, Bill Gunshannon via cctalk wrote:

Well, I was finally able to get a PMI memory board to expand my
11/93 to the full 4 Meg.  (Thanks Paul!)

I thought it would be as simple as configuring what bank I wanted
it to fill and inserting it (in front of the CPU).  Sadly, that
didn't work.  First problem is the only document i could find is
not for the actual version of the board I  have.  It has the same
switch sets so I tried it anyway.  Set it to be in the upper 2Meg
and gave it the next CSR after the on board memory.  No luck.
11/93 still reports 1024KWords and the Map command shows neither
the additional memory or the second memory CSR.

Anybody have any experience with this? Is there a switch I have to
change on the CPU module to make it recognize the additional external
memory?  IS there something about PMI that I am missing?

Any advice gratefully appreciated.

bill

Re: Plane of core memory

[dwight via cctalk]

Although, after written, there is little magnetism lost out side of the ring, 
while being magnetized, there is quite a bit of stray magnetism. By placing the 
the rings at 90 degrees, it minimizes the magnetism induced in the adjacent 
ring. The fields follow the inverse square law so the effect drops off quite 
quickly. Also the ring tend to pull the magnetic field into the ring, at least 
until saturated. At that time the field can leak into a neighbor and flip its 
state. Not being aligned with the direction of the ring also minimizes this 
stray field.
Dwight


From: cctalk  on behalf of Anders Nelson via 
cctalk 
Sent: Thursday, April 18, 2019 6:01 PM
To: paulkon...@comcast.net; General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Plane of core memory

I believe I read they weaved the planes this way to minimize crosstalk, EMI
or heat.

=]

On Thu, Apr 18, 2019, 1:13 PM Paul Koning via cctalk 
wrote:

>
>
> > On Apr 18, 2019, at 11:47 AM, Jon Elson via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > On 04/18/2019 04:49 AM, Brent Hilpert via cctalk wrote:
> >> It's a 4-wire 3D planar array. By topology and construction I would
> guess it date it from the 60s.
> > Make that EARLY '60s.  As soon as somebody figured out that you could
> combine the sense and inhibit wires, everybody immediately went to 3-wire
> planes.
> >
> > Jon
>
> Is that true even for the highest speed designs?
>
> CDC 6000 series memory is unusual in that it has 5 wires per core.
> Instead of the classic X, Y, Inhibit, Sense it has two inhibit wires,
> routed in the X and Y direction.  There are four X and four Y inhibit
> wires, each of which run through 1/4th of the cores, so a given inhibit
> pair acts on 1/16th of the cores.
>
> The documentation doesn't spell out why this is done.  My guess is that it
> makes the various driven wires more alike in how many cores they pass
> through.  X and Y, in the 12 bit stack, pass through 64 * 12 cores.  Each
> inhibit wire passes through 64 * 16 cores, i.e., nearly the same number.
> And the driver circuits for all these wires are the same.
>
> A regular full-plane inhibit wire would pass through 4k cores, meaning the
> inductance is far higher than that of the X and Y wires.  So either the
> drive circuit would require a lot more power, or it would be significantly
> slower than the X/Y drive.
>
> As for separate sense, split inhibit obviously requires that, but even
> with conventional inhibit, keeping sense separate avoids the overhead of
> switching the signal path between two very different bits of circuitry.
>
> Compared to many other core memory designs of that same era, the 6000
> memory is quite fast, with access times of a few hundred nanoseconds and
> full cycle (read plus restore) in one microsecond.  Actually, comfortably
> under 1 microsecond, allowing for magic like read and update in one cycle
> (for the exchange instruction in the CPU) or read and write new data in one
> cycle via the ALU data path (in the PPUs).  I suspect the unusual core
> plane design was a factor in making this speed possible.
>
> paul
>
>

Re: Plane of core memory

[Jon Elson via cctalk]

On 04/18/2019 03:15 PM, Noel Chiappa via cctalk wrote:

 > From: Jon Elson

 > As soon as somebody figured out that you could combine the sense and
 > inhibit wires, everybody immediately went to 3-wire planes.

I"m suprised the idea wasn't patented. Or maybe it was, and they made the
license widely available at modest terms?


I was thinking the same thing, but can't find any references 
to who invented it.  it certainly sounds like the sort of 
thing to get a patent on.


Point of interest, my freshman advisor was Bill Papian, who 
was Jay W. Forrester's grad student when he invented 
coincident-current core memory.


Jon

Re: that AGC DSKY auction

[Adrian Stoness via cctalk]

weird this only went for 220 bucks
https://www.rrauction.com/bidtracker_detail.cfm?IN=5109

On Thu, Apr 18, 2019 at 9:03 PM Brent Hilpert via cctalk <
cctalk@classiccmp.org> wrote:

> So it appears it went for 168 K$ at hammer.
>
> With buyer's premium, that puts the sale price at 210 K$.
>
> https://www.rrauction.com/bidtracker_detail.cfm?IN=5222
>
>
>

that AGC DSKY auction

[Brent Hilpert via cctalk]

So it appears it went for 168 K$ at hammer.

With buyer's premium, that puts the sale price at 210 K$.

https://www.rrauction.com/bidtracker_detail.cfm?IN=5222

PDP-11/93 and PMI Memory

[Bill Gunshannon via cctalk]

Well, I was finally able to get a PMI memory board to expand my
11/93 to the full 4 Meg.  (Thanks Paul!)

I thought it would be as simple as configuring what bank I wanted
it to fill and inserting it (in front of the CPU).  Sadly, that
didn't work.  First problem is the only document i could find is
not for the actual version of the board I  have.  It has the same
switch sets so I tried it anyway.  Set it to be in the upper 2Meg
and gave it the next CSR after the on board memory.  No luck.
11/93 still reports 1024KWords and the Map command shows neither
the additional memory or the second memory CSR.

Anybody have any experience with this? Is there a switch I have to
change on the CPU module to make it recognize the additional external
memory?  IS there something about PMI that I am missing?

Any advice gratefully appreciated.

bill

Re: Plane of core memory

[Anders Nelson via cctalk]

I believe I read they weaved the planes this way to minimize crosstalk, EMI
or heat.

=]

On Thu, Apr 18, 2019, 1:13 PM Paul Koning via cctalk 
wrote:

>
>
> > On Apr 18, 2019, at 11:47 AM, Jon Elson via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > On 04/18/2019 04:49 AM, Brent Hilpert via cctalk wrote:
> >> It's a 4-wire 3D planar array. By topology and construction I would
> guess it date it from the 60s.
> > Make that EARLY '60s.  As soon as somebody figured out that you could
> combine the sense and inhibit wires, everybody immediately went to 3-wire
> planes.
> >
> > Jon
>
> Is that true even for the highest speed designs?
>
> CDC 6000 series memory is unusual in that it has 5 wires per core.
> Instead of the classic X, Y, Inhibit, Sense it has two inhibit wires,
> routed in the X and Y direction.  There are four X and four Y inhibit
> wires, each of which run through 1/4th of the cores, so a given inhibit
> pair acts on 1/16th of the cores.
>
> The documentation doesn't spell out why this is done.  My guess is that it
> makes the various driven wires more alike in how many cores they pass
> through.  X and Y, in the 12 bit stack, pass through 64 * 12 cores.  Each
> inhibit wire passes through 64 * 16 cores, i.e., nearly the same number.
> And the driver circuits for all these wires are the same.
>
> A regular full-plane inhibit wire would pass through 4k cores, meaning the
> inductance is far higher than that of the X and Y wires.  So either the
> drive circuit would require a lot more power, or it would be significantly
> slower than the X/Y drive.
>
> As for separate sense, split inhibit obviously requires that, but even
> with conventional inhibit, keeping sense separate avoids the overhead of
> switching the signal path between two very different bits of circuitry.
>
> Compared to many other core memory designs of that same era, the 6000
> memory is quite fast, with access times of a few hundred nanoseconds and
> full cycle (read plus restore) in one microsecond.  Actually, comfortably
> under 1 microsecond, allowing for magic like read and update in one cycle
> (for the exchange instruction in the CPU) or read and write new data in one
> cycle via the ALU data path (in the PPUs).  I suspect the unusual core
> plane design was a factor in making this speed possible.
>
> paul
>
>

Re: Digital Standard Mumps

[Paul Koning via cctalk]

> On Apr 18, 2019, at 7:41 PM, Warner Losh  wrote:
> 
> 
> 
>> On Thu, Apr 18, 2019 at 5:11 PM Paul Koning  wrote:
>> 
>> ...
>> Poor man's hypervisor, I like that.
>> 
>> That's reasonably accurate.  RSTS/E had "run-time systems", originally the 
>> interpreter, support library, and user interface of the BASIC-PLUS language 
>> machinery.  Starting in, I think, RSTS/E V5B, it was generalized step by 
>> step to become a collection of such things: a user interface, execution 
>> environment, and other stuff.  It might be very narrowly tailored, like the 
>> TECO run-time system, it might be the interpreter library for a language, 
>> like the FORTH and ALGOL run-time systems, or it might be a fairly complete 
>> emulation of a different OS, like the RT11 and RSX run-time systems.
>> 
>> I know I ran BASIC-Plus, TECO and RT-11 binaries (FORTRAN code) on the 
>> RSTS/E system I started out on (6C or 7.0, iirc). We also had some RSX-11 
>> binaries too for something I've long-ago forgotten.
>>  
>> I first used a very primitive version of this feature in V5B around 1975, to 
>> run an assembly language program before there was any general RSTS support 
>> for doing that.
>> 
> Yea, I couldn't recall if it was tailored or generic. I think it was, as you 
> say, tailored from  massaged versions of the original executives, iirc, but 
> maybe they were reimplementations like the crazy glue code that we had at 
> university that was an RT-11 .SAV file with some weird glue to make it run in 
> 7th Edition Unix that we ran on a VAX 11/750 using the pdp-11 emulator 
> hardware it had...
> 
> Warner

Each runtime system was a separate construct.  The kernel has a number of 
services to enable various things that need to be done, though.  Here are a few.

1. Each executable file has an attribute naming the runtime system that will 
execute it. For example, PIP.SAV would be handled by the RT11 runtime system 
not because of the .SAV extension but because of the runtime system setting.  
This is vague like the #! line in Unix shell scripts.

2. Various exceptions and interrupts during execution would be directed by the 
kernel to "pseudo-vectors" in the currently active runtime system.  For 
example, traps to 4 or 10 or breakpoint traps would be handled that way, as 
would control/C interrupts.

3. The RSTS/E kernel uses EMT for syscalls, but any unknown syscall would go to 
the EMT pseudo-vector.  This directly enables RSX emulation because that uses a 
non-RSTS EMT (377).  But RT11 uses many of the same EMT codes that RSTS does, 
so there an escape technique was used ("prefix EMT").  If RSTS saw EMT 377 with 
another EMT in the next word, it would handle that as a kernel request.  Any 
other EMT (not preceded by 377) would go to the RT11 runtime system.  So EMT 0 
is an RT11 request, EMT 377; EMT 0 is a RSTS kernel request.

I think the code in the runtime system would typically not be the original OS 
code or taken from it.  Exceptions might be things like the executable file 
loader.  But syscall handling is different partly because it isn't concerned 
with scheduling or execution blocking (those are kernel concerns) and partly 
because it is mapping the request to the equivalent RSTS kernel request, not to 
device operations or things like that.

It's interesting that no Unix RTS was attempted that I know of.  Perhaps that 
was too hard because the OS services are so different (nothing like fork or 
pipe in RSTS, which would be a concern).  Even so, one of the RSTS developers 
converted csh into a runtime system, so you could run shell scripts and csh 
command parsing -- but the programs would still be DEC programs, not Unix ones. 
 Unfortunately that code has been lost as far as I know.

paul

Re: Digital Standard Mumps

[John Willis via cctalk]

DSM went to InterSystems Corp. during their spree of buying up every MUMPS 
implementation vendor they could get their hands on. They got DataTree (DTM), 
Micronetics (MSM), and DSM. They already had ISM. They merged ISM and features 
from the others into OpenM, which evolved into Caché, their current MUMPS 
product.

M21, GT.M, MUMPSv1, FreeM, YottaDB, and Mumps-II remain independent and current 
as of today.

I'm the station chair for the validation and testing suite for the MUMPS 
Development Committee, which is the organization responsible for the ISO and 
formerly ANSI standards for the language.

Re: Digital Standard Mumps

[Warner Losh via cctalk]

On Thu, Apr 18, 2019 at 5:11 PM Paul Koning  wrote:

>
>
> > On Apr 18, 2019, at 3:06 PM, Warner Losh  wrote:
> >
> > On Thu, Apr 18, 2019 at 12:41 PM Dan Veeneman via cctalk <
> cctalk@classiccmp.org> wrote:
> > On 4/18/2019 2:27 PM, Paul Koning via cctalk wrote:
> > > my memory is that DSM-11 is an operating system all its own, not just
> a language processor running on top of a standard OS like RSTS.
> >
> > In the late 1980s and early 1990s, we used DSM running on VMS 4.7 for a
> > nationwide (United States) mortgage credit reporting system.
> >
> > The big claim to fame for RSTS/e  was I thought that it let you load
> 'foreign' executives so you could run RT-11 or RSX-11 or whatever binaries
> all on one system. I'd imagine DSM-11 images would be easy if it were a
> real OS. I'd always thought of RSTS/e as a poor-man's hypervisor. But maybe
> I'm misremembering how much it could do...
>
> Poor man's hypervisor, I like that.
>
> That's reasonably accurate.  RSTS/E had "run-time systems", originally the
> interpreter, support library, and user interface of the BASIC-PLUS language
> machinery.  Starting in, I think, RSTS/E V5B, it was generalized step by
> step to become a collection of such things: a user interface, execution
> environment, and other stuff.  It might be very narrowly tailored, like the
> TECO run-time system, it might be the interpreter library for a language,
> like the FORTH and ALGOL run-time systems, or it might be a fairly complete
> emulation of a different OS, like the RT11 and RSX run-time systems.
>

I know I ran BASIC-Plus, TECO and RT-11 binaries (FORTRAN code) on the
RSTS/E system I started out on (6C or 7.0, iirc). We also had some RSX-11
binaries too for something I've long-ago forgotten.


> I first used a very primitive version of this feature in V5B around 1975,
> to run an assembly language program before there was any general RSTS
> support for doing that.
>

Yea, I couldn't recall if it was tailored or generic. I think it was, as
you say, tailored from  massaged versions of the original executives, iirc,
but maybe they were reimplementations like the crazy glue code that we had
at university that was an RT-11 .SAV file with some weird glue to make it
run in 7th Edition Unix that we ran on a VAX 11/750 using the pdp-11
emulator hardware it had...

Warner

Re: Digital Standard Mumps

[Paul Koning via cctalk]

> On Apr 18, 2019, at 3:06 PM, Warner Losh  wrote:
> 
> On Thu, Apr 18, 2019 at 12:41 PM Dan Veeneman via cctalk 
>  wrote:
> On 4/18/2019 2:27 PM, Paul Koning via cctalk wrote:
> > my memory is that DSM-11 is an operating system all its own, not just a 
> > language processor running on top of a standard OS like RSTS.
> 
> In the late 1980s and early 1990s, we used DSM running on VMS 4.7 for a
> nationwide (United States) mortgage credit reporting system.
> 
> The big claim to fame for RSTS/e  was I thought that it let you load 
> 'foreign' executives so you could run RT-11 or RSX-11 or whatever binaries 
> all on one system. I'd imagine DSM-11 images would be easy if it were a real 
> OS. I'd always thought of RSTS/e as a poor-man's hypervisor. But maybe I'm 
> misremembering how much it could do...

Poor man's hypervisor, I like that.

That's reasonably accurate.  RSTS/E had "run-time systems", originally the 
interpreter, support library, and user interface of the BASIC-PLUS language 
machinery.  Starting in, I think, RSTS/E V5B, it was generalized step by step 
to become a collection of such things: a user interface, execution environment, 
and other stuff.  It might be very narrowly tailored, like the TECO run-time 
system, it might be the interpreter library for a language, like the FORTH and 
ALGOL run-time systems, or it might be a fairly complete emulation of a 
different OS, like the RT11 and RSX run-time systems.

I first used a very primitive version of this feature in V5B around 1975, to 
run an assembly language program before there was any general RSTS support for 
doing that.  

paul

Re: Plane of core memory

[William Donzelli via cctalk]

>Stewart-Warner (I think) vector graphics terminals
> from the 1960s. Check Ebay in a week or three...

Correction: Hazeltine.

--
Will

RE: Plane of core memory

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk  On Behalf Of Chuck Guzis via
> cctalk
> Sent: 18 April 2019 17:30
> To: Jim Manley via cctalk 
> Subject: Re: Plane of core memory
> 
> On 4/18/19 9:02 AM, Jim Manley via cctalk wrote:
> > Jussi Kilpelainen's page cited above (
> > https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduin
> > o/) refers to the work of Ben North and Oliver Nash to create another
> > core memory shield for Arduino Unos.  Their site inspired Jussi to
> > create his shield kit, which can be viewed at:
> >
> > http://www.corememoryshield.com
> > 
> 
> I remember seeing that one some time ago.
> 
> Anyone with a Williams tube project?  Mercury delay lines?

Whilst MSI Manchester run the Manchester Baby replica several days a week, and 
it does have (mostly) working Williams tubes, its often operated on 
semi-conductor memory as that allows us to talk to visitors, and not have to 
keep tweaking the store. 

The EDSAC replica at TNMOC uses delay lines as a ton of Mercury was too 
expensive and had health and safety implications.

> Magnetostrictive delay memory?
> 
> --Chuck

 Dave

Dave

Re: PDP-11/83 w/FPU?

[allison via cctalk]

On 04/18/2019 04:19 PM, Noel Chiappa via cctalk wrote:
> > From: Allison
>
> > Experience is that an 11/23 or 23+ will run V6 as mine does.
>
> What changes did you make to get it to run? (I assume the stock binary
> wouldn't run.)
>
>   Noel

The hardest part was was getting it on a RL02 from the PUPs library.
The binary was stock for that device, its only been maybe 15 or more years.

V6 was low enough in requirements that a valid mass storage was the big
thing.
Choices were RK05, RL01/02, and maybe RX01(way too small).

Allison

Re: PDP-11/83 w/FPU?

[Noel Chiappa via cctalk]

> From: Allison

> Experience is that an 11/23 or 23+ will run V6 as mine does.

What changes did you make to get it to run? (I assume the stock binary
wouldn't run.)

Noel

Re: Plane of core memory

[Noel Chiappa via cctalk]

> From: Jon Elson

> As soon as somebody figured out that you could combine the sense and
> inhibit wires, everybody immediately went to 3-wire planes.

I"m suprised the idea wasn't patented. Or maybe it was, and they made the
license widely available at modest terms?

Noel

Re: Plane of core memory

[Brent Hilpert via cctalk]

On 2019-Apr-18, at 9:30 AM, Chuck Guzis via cctalk wrote:
> On 4/18/19 9:02 AM, Jim Manley via cctalk wrote:
>> Jussi Kilpelainen's page cited above (
>> https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduino/)
>> refers to the work of Ben North and Oliver Nash to create another core
>> memory shield for Arduino Unos.  Their site inspired Jussi to create his
>> shield kit, which can be viewed at:
>> 
>> http://www.corememoryshield.com
>> 
> 
> I remember seeing that one some time ago.
> 
> Anyone with a Williams tube project?  Mercury delay lines?
> Magnetostrictive delay memory?


- The Manchester Baby replica recreated Williams tube memory (aka 
Williams-Kilburn tube memory).
Williams tube memory uses conventional oscope CRTs, so it wasn't that difficult.
(i.e. it's Williams 'tube memory', rather than 'Williams tube' memory.)

Holding-beam CRT memory ala Whirlwind would be another matter as the tubes were 
highly specialised.


- The EDSAC replica is using a new-production magnetostrictive delay-line 
memory to substitute for the mercury tanks.
From what I've seen of it (utube), it's a standard MR looped-wire design using 
modern components and production techniques.

Re: Plane of core memory

[Brent Hilpert via cctalk]

On 2019-Apr-18, at 8:47 AM, Jon Elson wrote:
> On 04/18/2019 04:49 AM, Brent Hilpert via cctalk wrote:
>> It's a 4-wire 3D planar array. By topology and construction I would guess it 
>> date it from the 60s.
> Make that EARLY '60s.  As soon as somebody figured out that you could combine 
> the sense and inhibit wires, everybody immediately went to 3-wire planes.


Well, not everybody - I have a 4-wire, diagonal-sense module with IC date codes 
extending from 1974 to 1978.
Certainly it's an outlier, on the tail-end of the distribution curve of 
production of such design,
but that's why I expressed dating it to the 60s as a likelihood, not an 
absolute surety.

(The ICs are 711 comparators and diode arrays. The 711 does go back to at least 
1969 so it's conceivable
 the design of the module goes back to the late 60s, although that's seems less 
likely considering production into 1978.)

Re: Digital Standard Mumps

[Bill Gunshannon via cctalk]

On 4/18/19 2:41 PM, Dan Veeneman wrote:
> On 4/18/2019 2:27 PM, Paul Koning via cctalk wrote:
>> my memory is that DSM-11 is an operating system all its own, not just a 
>> language processor running on top of a standard OS like RSTS.
> 
> In the late 1980s and early 1990s, we used DSM running on VMS 4.7 for a
> nationwide (United States) mortgage credit reporting system.
> 

DSM-11 on the PDP-11 was an OS all its own.  I just looked in my
Software Handbook and on the VAX it was a VMS Language Processor.
That's pretty much what it has become today although it did start
out as a complete system running on bare iron.

bill

Re: Digital Standard Mumps

[Warner Losh via cctalk]

On Thu, Apr 18, 2019 at 12:41 PM Dan Veeneman via cctalk <
cctalk@classiccmp.org> wrote:

> On 4/18/2019 2:27 PM, Paul Koning via cctalk wrote:
> > my memory is that DSM-11 is an operating system all its own, not just a
> language processor running on top of a standard OS like RSTS.
>
> In the late 1980s and early 1990s, we used DSM running on VMS 4.7 for a
> nationwide (United States) mortgage credit reporting system.
>

The big claim to fame for RSTS/e  was I thought that it let you load
'foreign' executives so you could run RT-11 or RSX-11 or whatever binaries
all on one system. I'd imagine DSM-11 images would be easy if it were a
real OS. I'd always thought of RSTS/e as a poor-man's hypervisor. But maybe
I'm misremembering how much it could do...

Warner

Re: Digital Standard Mumps

[Dan Veeneman via cctalk]

On 4/18/2019 2:27 PM, Paul Koning via cctalk wrote:
> my memory is that DSM-11 is an operating system all its own, not just a 
> language processor running on top of a standard OS like RSTS.

In the late 1980s and early 1990s, we used DSM running on VMS 4.7 for a
nationwide (United States) mortgage credit reporting system.


Cheers,
Dan

Re: PDP-11/83 w/FPU?

[Paul Koning via cctalk]

> On Apr 18, 2019, at 2:19 PM, allison via cctalk  wrote:
> 
> ...
> There may be other versions that place less of a burden on requiring I&D.
> However I've not encountered a need for FPU connected to OS.  Also
> the assumption for many unix is MMU support but not all DEC OS have
> that requirement.

Indeed.  

MMU required: RSTS/E, RSX-11/M+, RSX-11/D, IAS, RT-11/XM. Also RSX-11/M ?
Not required: RSTS-11, DOS-11, RT-11/SJ and /FB, RSX-11/S, MicroPower/Pascal, 
IOX, CAPS-11.

paul

Re: Digital Standard Mumps

[Paul Koning via cctalk]

> On Apr 18, 2019, at 1:56 PM, Bill Gunshannon via cctalk 
>  wrote:
> 
> 
> Does anyone know what the current status of this might be?  I am
> fairly certain Mentec didn't get this and I am not sure anyone
> did.  Did it merely die when everyone thought Mumps was on the
> down hill slide? Was it ever really a DEC product or was it
> something DEC picked up along the way after Mass General let it
> out of its cage?

I'm pretty sure it was a DEC product.  For that matter, it was used as the 
foundation for at least one DEC product.

When I joined DEC in 1978, the group next to mine (Typeset-11) was the 
Assist-11 product team.  Assist-11 was a turnkey product for phone company 
directory assistance, allowing names to be looked up in a large (million or so 
entries) database quickly.  I have a clear memory that this was built on top of 
DSM-11.

Curiously, a data sheet I recently saw for Assist-11 says it runs on top of 
RSTS.  I'm puzzled by that, because my memory is that DSM-11 is an operating 
system all its own, not just a language processor running on top of a standard 
OS like RSTS.  Perhaps it was a separate OS at first and over time it was 
turned into a language subsystem on RSTS?  Apart from running into the 
Assist-11 team once or twice around 1978, I never had any other exposure to 
that or any other aspect of DSM-11.

paul

Re: PDP-11/83 w/FPU?

[allison via cctalk]

On 04/18/2019 10:56 AM, Noel Chiappa via cctalk wrote:
> > From: W2HX
>
> > i have a few CPUs available to me, a 11/23+, an 11/73 and I also have
> > available to me an 11/83
> > I would like to try to run as many different OS's as may interest me,
> > including some unixes as possible (bsd...etc).
>
> Early Unixes in general will run on those machines - but not straight off the
> tape (since they didn't exist then, and have quirks which aren't supported).
>
> I've brought up V6 on a /23 (which must have the KTF11-A MMU chip); here:
>
>   http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23
>
> are instructions on exactly what (minor) changes need to be made for it to
> run.
>
> The /73 and /83 should be subsets of that, although you'll want to start with
> m45.s, because those machines support the split-I-D MMU of the -11/45. (A /23
> Unix binary would boot/run on them, if you don't feel like doing a special one
> for them.) I haven't yet tried V6 on them; if you want me to, and do a
> writeup, let me know. The /73 and /83 have LTC registers, so on those you
> won't need the LTC hack.
>
> Also, you may know this already, but if not, note that the /83 is a PMI:
>
>   http://gunkies.org/wiki/Private_Memory_Interconnect
>
> machine, and _MUST_ be plugged into a Q/CD backplane _only_; plugging into
> a standard Q/Q backplane will _damage_ it.
>
>
> > would I see any improvement in performance with the FPU compared to
> > without it? Or does the application running need to be something like
> > fortran to see any perceivable difference?
>
> As someone noted, the /73 and /83 implement thefloating point instructions in
> microcode, so the code can't tell if the optional FPJ11 FP hardware
> accelerator is plugged in or not. In general, only on applications (the
> language is not relevant) which are heavy users of FP would you see any
> difference.
>
> On the /23, with no KEF11-A FPU chip plugged in, there are no floating point
> instructions at all, so any application which tries to use them will blow out
> (although under V6 there's an emulator); see here:
>
>   http://gunkies.org/wiki/Setting_up_UNIX_-_Sixth_Edition
>
> and search for 'floating point' to see discussion of it).
>
>
> > From: Ethan Dicks
>
> > v5, v6, and v7 UNIX shouldn't require any sort of math hardware.
>
> Don't know v5/v7 in detail, but AFAIK that's accurate. V6 can _support_
> FP hardware on machines which have it, and is otherwised prepared to
> emulate those instructions (see above).
>
> > From: Paul Koning
>
> > I think that was typically called "EAE" (extended arithmetic element),
> > a Unibus peripheral that implemented integer mul/div ... It only
> > applies to 11/20 and 11/05 since all the other machines have the
> > relevant instructions built into the CPU.
>
> Also the -11/04 and -11/03 were both missing the EIS; the former could use
> the EAE, for the latter the optional KEV11-A or KEV11-B microcode chips both
> provide it.
>
> > From: Josh Dersch
>
> > The EAE was also an option on the 11/40.
>
> Technically, on any UNIBUS machine; on the /40, the EIS (added instructions,
> not the device model of the EAE) was available via an optional board in
> the CPU.
>
>   Noel
All,


Experience is that an 11/23 or 23+ will run V6 as mine does.  REason it
does is V6 does not require I&D support

The usual issue is not FPU for Unix as questioned but if there is a need
for I&D spaces.  The 11/23 (f11 chipset)
does not support that but the J11 (11/73 and 11/83) do support that.  I
have a 11/73 so I could run BSD and a few
others commonly found that require I&D support.

There may be other versions that place less of a burden on requiring I&D.
However I've not encountered a need for FPU connected to OS.  Also
the assumption for many unix is MMU support but not all DEC OS have
that requirement.

Allison

Re: Plane of core memory

[Dennis Boone via cctalk]

 >   * Is there a way to "read" the core non destructively using any kind
 > of passive method (I know, it would be tedious, no doubt, but I just
 > feel like I should "backup" the core before I go messing with it)?

I'm having trouble figuring out what typical magnetic field strengths on
the cores would be, but I wonder if you could wave some ferrofluid over
individual cores and get movement.  Some ferrofluid particles are
apparently on the order of 10 nM in diameter, so wouldn't be all that
hard to move with a weak magnetic field.

 >   * Along with the above, might there be a way to extend the passive
 > read to be a worthy "exhibit" I could take to shows? Core memory is
 > impressive just to look at, but reading it out using the PC and
 > displaying the contents is so easy to fake that I think people will
 > assume the core memory is not really being used.  Some way of
 > showing the actual magnetic changes in a small matrix (the large
 > plane I have is probably not a good candidate unless there is a way
 > to show such minute cores fields) would I think make the exhibit far
 > more interesting, especially if I arranged the grid in a square and
 > created a really slow version of something like "Tetris" on the plane.

Showing the read pulse and sense transition waveforms on a 'scope might
be of some interest.

De

Digital Standard Mumps

[Bill Gunshannon via cctalk]

Does anyone know what the current status of this might be?  I am
fairly certain Mentec didn't get this and I am not sure anyone
did.  Did it merely die when everyone thought Mumps was on the
down hill slide? Was it ever really a DEC product or was it
something DEC picked up along the way after Mass General let it
out of its cage?

bill

Re: Plane of core memory

[Al Kossow via cctalk]

On 4/18/19 10:33 AM, dwight via cctalk wrote:
> I don't believe there is a simple non-destructive way to read the state.

https://patents.google.com/patent/US3924248

Re: Plane of core memory

[dwight via cctalk]

I don't believe there is a simple non-destructive way to read the state. If you 
could remove the cores, I believe you could put each core in a weak magnetic 
field. As the field passes from side to side, one should be able to determine 
the direction of the saturated cores because one side would allow more of the 
field to enter the core while the other side would act as non-magnetic.
As for reading the data, you'd need to experiment to determine the minimum 
current that particular core required to flip a bit. With careful adjusting, I 
suspect one could sample the first bit.
Once knowing the levels used, the entire array can be read.
Dwight


From: cctalk  on behalf of Jim Brain via cctalk 

Sent: Thursday, April 18, 2019 10:19 AM
To: cctalk@classiccmp.org
Subject: Re: Plane of core memory

I am the enviable owners of a plane of memory (procured a few years back
at VCF-East, when there were a bunch of 32K? boards int he consignment pile.

(Sorry, not currently interested in selling :-)

But, I am thankful for the links, as I have wanted to interface this
with a CPU or PC of some kind.

A few questions, though:

  * Is there a way to "read" the core non destructively using any kind
of passive method (I know, it would be tedious, no doubt, but I just
feel like I should "backup" the core before I go messing with it)?
  * Along with the above, might there be a way to extend the passive
read to be a worthy "exhibit" I could take to shows? Core memory is
impressive just to look at, but reading it out using the PC and
displaying the contents is so easy to fake that I think people will
assume the core memory is not really being used.  Some way of
showing the actual magnetic changes in a small matrix (the large
plane I have is probably not a good candidate unless there is a way
to show such minute cores fields) would I think make the exhibit far
more interesting, especially if I arranged the grid in a square and
created a really slow version of something like "Tetris" on the plane.

Ideas appreciated.

Jim

Re: Plane of core memory

[William Donzelli via cctalk]

> Or still do a fluid one, but take Turing's suggestion
> and use gin as the medium.

Better use some good error correction.

--
Will

Re: Plane of core memory

[William Donzelli via cctalk]

> (Sorry, not currently interested in selling :-)

Well, I am. And I have a LOT of 8K core system modules (planes and
drivers) from old Stewart-Warner (I think) vector graphics terminals
from the 1960s. Check Ebay in a week or three...

--
Will

Re: Plane of core memory

[William Donzelli via cctalk]

> I don't expect that any EBAM has survived--I think all of the stuff I
> saw at CDC ADL was scrapped. Seems that the technology is all but
> forgotten today:
>
> https://bit.ly/2KOOl82

How was the CDC EBAM different from the other memory tubes, like the Radechon?

--
Will

Re: Plane of core memory

[Chuck Guzis via cctalk]

My mention of electron-beam memory devices left off GE's BEAMOS and
RCA's Selectron.

WikiPedia has a nice article on the Selectron, but BEAMOS took a bit of
looking:

http://rcaselectron.com/GEBEAMOS.html

Too bad that neither RCA nor GE were in the computer business in 1978.

--Chuck

Re: Plane of core memory

[Jim Brain via cctalk]

I am the enviable owners of a plane of memory (procured a few years back 
at VCF-East, when there were a bunch of 32K? boards int he consignment pile.


(Sorry, not currently interested in selling :-)

But, I am thankful for the links, as I have wanted to interface this 
with a CPU or PC of some kind.


A few questions, though:

 * Is there a way to "read" the core non destructively using any kind
   of passive method (I know, it would be tedious, no doubt, but I just
   feel like I should "backup" the core before I go messing with it)?
 * Along with the above, might there be a way to extend the passive
   read to be a worthy "exhibit" I could take to shows? Core memory is
   impressive just to look at, but reading it out using the PC and
   displaying the contents is so easy to fake that I think people will
   assume the core memory is not really being used.  Some way of
   showing the actual magnetic changes in a small matrix (the large
   plane I have is probably not a good candidate unless there is a way
   to show such minute cores fields) would I think make the exhibit far
   more interesting, especially if I arranged the grid in a square and
   created a really slow version of something like "Tetris" on the plane.

Ideas appreciated.

Jim

Re: Plane of core memory

[Brian L. Stuart via cctalk]

On Thu, 4/18/19, dwight via cctalk  wrote:
> My understanding was that the mercury delay lines
> needed periodic repairs ( not sure what the cause
> was but mercury does dissolve into many metals ).
> If I were going to make a delay line memory, I'd go with
> the magnetostrictive. These are practical to make. One just
> needs a little ingenuity and a spool of piano wire.
> Dwight

Or still do a fluid one, but take Turing's suggestion
and use gin as the medium.

BLS

Re: Plane of core memory

[Paul Koning via cctalk]

> On Apr 18, 2019, at 11:47 AM, Jon Elson via cctalk  
> wrote:
> 
> On 04/18/2019 04:49 AM, Brent Hilpert via cctalk wrote:
>> It's a 4-wire 3D planar array. By topology and construction I would guess it 
>> date it from the 60s.
> Make that EARLY '60s.  As soon as somebody figured out that you could combine 
> the sense and inhibit wires, everybody immediately went to 3-wire planes.
> 
> Jon

Is that true even for the highest speed designs?

CDC 6000 series memory is unusual in that it has 5 wires per core.  Instead of 
the classic X, Y, Inhibit, Sense it has two inhibit wires, routed in the X and 
Y direction.  There are four X and four Y inhibit wires, each of which run 
through 1/4th of the cores, so a given inhibit pair acts on 1/16th of the cores.

The documentation doesn't spell out why this is done.  My guess is that it 
makes the various driven wires more alike in how many cores they pass through.  
X and Y, in the 12 bit stack, pass through 64 * 12 cores.  Each inhibit wire 
passes through 64 * 16 cores, i.e., nearly the same number.  And the driver 
circuits for all these wires are the same.

A regular full-plane inhibit wire would pass through 4k cores, meaning the 
inductance is far higher than that of the X and Y wires.  So either the drive 
circuit would require a lot more power, or it would be significantly slower 
than the X/Y drive.

As for separate sense, split inhibit obviously requires that, but even with 
conventional inhibit, keeping sense separate avoids the overhead of switching 
the signal path between two very different bits of circuitry.

Compared to many other core memory designs of that same era, the 6000 memory is 
quite fast, with access times of a few hundred nanoseconds and full cycle (read 
plus restore) in one microsecond.  Actually, comfortably under 1 microsecond, 
allowing for magic like read and update in one cycle (for the exchange 
instruction in the CPU) or read and write new data in one cycle via the ALU 
data path (in the PPUs).  I suspect the unusual core plane design was a factor 
in making this speed possible.

paul

Re: Plane of core memory

[Chuck Guzis via cctalk]

On 4/18/19 9:42 AM, Al Kossow via cctalk wrote:

> 
> The 1401 guys at CHM were working on one using a real 701 tube.
> I don't think it was ever finished.

I don't expect that any EBAM has survived--I think all of the stuff I
saw at CDC ADL was scrapped. Seems that the technology is all but
forgotten today:

https://bit.ly/2KOOl82

It's mentioned in a proposal by Neil Lincoln back in the 1970s:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19770084287.pdf

I've long thought that a scan converter tube  (e.g. 7912)  might make a
good electrostatic memory.

--Chuck

Re: Plane of core memory

[Grant Taylor via cctalk]

On 4/18/19 2:08 AM, Andrew Luke Nesbit wrote:

This is great and I will look into this.


I'm generally not into SBCs.  (I do more with virtualization than have 
SBCs proliferate.)  But the idea of having core memory, and it working, 
is quite appealing to me.



But my original request was for something a little bit different.


I agree that the spirit of your request was for something older. 
However, nothing  you wrote actually dictated it.  -  Letter of the law 
vs the spirit of the law type thing.  ;-)


That is, a properly specified core memory plane in working condition, 
because I would very much like to interface with it from a modern 
computer.


Friendly nit pick (meant in good fun):

What is "properly specified" in this context?  That just means that you 
need to know where it came from.  -  I feel like "a shield for an 
Arduino (insert more model details here)" qualifies as "properly specified".


It is, or very well should be, in working condition.

You should be able to interface with it from an Arduino, which is very 
much so a modern computer.


;-)

I know that it's not old.  Which was not actually specified.  In fact, 
you functionally removed the old specification by saying "… S/360 … this 
is not necessary."


So, IMHO it did check the hard requirements as written in your original 
message.  :-D




--
Grant. . . .
unix || die

Re: Plane of core memory

[dwight via cctalk]

My understanding was that the mercury delay lines needed periodic repairs ( not 
sure what the cause was but mercury does dissolve into many metals ). If I were 
going to make a delay line memory, I'd go with the magnetostrictive. These are 
practical to make. One just needs a little ingenuity and a spool of piano wire.
Dwight


From: cctalk  on behalf of Al Kossow via cctalk 

Sent: Thursday, April 18, 2019 9:42 AM
To: cctalk@classiccmp.org
Subject: Re: Plane of core memory



On 4/18/19 9:30 AM, Chuck Guzis via cctalk wrote:

> Anyone with a Williams tube project?

The 1401 guys at CHM were working on one using a real 701 tube.
I don't think it was ever finished.

@tubetimeus built a small core array with Bulgarian cores
https://twitter.com/TubeTimeUS/status/1053424445463752704

Discussion of the EDSAC rebuild
https://www.youtube.com/watch?v=xGEAPVCuwvY

Haven't heard if anyone has tried to get one of the Russian MR
lines on eBay to do anything, or if anyone has a running Packard-Bell PB-250

Re: Plane of core memory

[Bob Smith via cctalk]

Not any dec core memory stack board I know of, - fingers are not gold
plated. - it is 8 bit.
I could speculate it might be from a low cost system from the late 70s
or early 80s but
in that time, everything core was in the many thousands of dollars.

On Thu, Apr 18, 2019 at 12:30 PM Chuck Guzis via cctalk
 wrote:
>
> On 4/18/19 9:02 AM, Jim Manley via cctalk wrote:
> > Jussi Kilpelainen's page cited above (
> > https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduino/)
> > refers to the work of Ben North and Oliver Nash to create another core
> > memory shield for Arduino Unos.  Their site inspired Jussi to create his
> > shield kit, which can be viewed at:
> >
> > http://www.corememoryshield.com
> > 
>
> I remember seeing that one some time ago.
>
> Anyone with a Williams tube project?  Mercury delay lines?
> Magnetostrictive delay memory?
>
> --Chuck
>

Re: Plane of core memory

[Al Kossow via cctalk]

On 4/18/19 9:30 AM, Chuck Guzis via cctalk wrote:

> Anyone with a Williams tube project?

The 1401 guys at CHM were working on one using a real 701 tube.
I don't think it was ever finished.

@tubetimeus built a small core array with Bulgarian cores
https://twitter.com/TubeTimeUS/status/1053424445463752704

Discussion of the EDSAC rebuild
https://www.youtube.com/watch?v=xGEAPVCuwvY

Haven't heard if anyone has tried to get one of the Russian MR
lines on eBay to do anything, or if anyone has a running Packard-Bell PB-250

Re: Plane of core memory

[Chuck Guzis via cctalk]

On 4/18/19 9:02 AM, Jim Manley via cctalk wrote:
> Jussi Kilpelainen's page cited above (
> https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduino/)
> refers to the work of Ben North and Oliver Nash to create another core
> memory shield for Arduino Unos.  Their site inspired Jussi to create his
> shield kit, which can be viewed at:
> 
> http://www.corememoryshield.com
> 

I remember seeing that one some time ago.

Anyone with a Williams tube project?  Mercury delay lines?
Magnetostrictive delay memory?

--Chuck

Re: Plane of core memory

[Jim Manley via cctalk]

Jussi Kilpelainen's page cited above (
https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduino/)
refers to the work of Ben North and Oliver Nash to create another core
memory shield for Arduino Unos.  Their site inspired Jussi to create his
shield kit, which can be viewed at:

http://www.corememoryshield.com



Ben's and Oliver's home page contains a link to the files:

http://www.corememoryshield.com/Core-Memory-Shield.zip

It also contains a link to a page with the detailed explanations and
schematics for core memory circuitry needed to read and write to core:

http://www.corememoryshield.com/report.html


Wayne Holder shows how to build the most minimal circuit using an SN754410
driver IC (http://focus.ti.com/docs/prod/folders/print/sn754410.html, about
$2.50 each for one, and a bit over $2.00 each for 10) and an Arduino Nano
(about $5.00 each for one, and around $3.50 each for 10) to address one bit
of core memory and, more importantly, how to expand the circuit to address
larger numbers of bits/cores using more SN754410s:

https://sites.google.com/site/wayneholder/one-bit-ferrite-core-memory

There's enough information on Wayne's page to build the circuitry to access
any arbitrary number of cores, with the number of cores/bits being
addressable increasing by a factor of four for each doubling of the number
of driver ICs.  ePrey has lots of old core memory planes available for as
little as $30 each for about 500 bits, with intact wiring (from Russia or
the Ukraine, which developed much of the Soviet Union's weapons systems and
advanced commercial electronics).  So, you can just wire the above circuits
to their pins instead of going through the hate and discontent of testing a
ziplock bag of 500 ~2,000 teensy-weensy cores (from Bulgaria) to find
enough with the right properties, and then having to weave your own plane.

All the Best and Enjoy!
Jim

Re: Plane of core memory

[Jon Elson via cctalk]

On 04/18/2019 04:49 AM, Brent Hilpert via cctalk wrote:
It's a 4-wire 3D planar array. By topology and 
construction I would guess it date it from the 60s.
Make that EARLY '60s.  As soon as somebody figured out that 
you could combine the sense and inhibit wires, everybody 
immediately went to 3-wire planes.


Jon

Re: PDP-11/83 w/FPU?

[Noel Chiappa via cctalk]

> From: W2HX

> i have a few CPUs available to me, a 11/23+, an 11/73 and I also have
> available to me an 11/83
> I would like to try to run as many different OS's as may interest me,
> including some unixes as possible (bsd...etc).

Early Unixes in general will run on those machines - but not straight off the
tape (since they didn't exist then, and have quirks which aren't supported).

I've brought up V6 on a /23 (which must have the KTF11-A MMU chip); here:

  http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23

are instructions on exactly what (minor) changes need to be made for it to
run.

The /73 and /83 should be subsets of that, although you'll want to start with
m45.s, because those machines support the split-I-D MMU of the -11/45. (A /23
Unix binary would boot/run on them, if you don't feel like doing a special one
for them.) I haven't yet tried V6 on them; if you want me to, and do a
writeup, let me know. The /73 and /83 have LTC registers, so on those you
won't need the LTC hack.

Also, you may know this already, but if not, note that the /83 is a PMI:

  http://gunkies.org/wiki/Private_Memory_Interconnect

machine, and _MUST_ be plugged into a Q/CD backplane _only_; plugging into
a standard Q/Q backplane will _damage_ it.


> would I see any improvement in performance with the FPU compared to
> without it? Or does the application running need to be something like
> fortran to see any perceivable difference?

As someone noted, the /73 and /83 implement thefloating point instructions in
microcode, so the code can't tell if the optional FPJ11 FP hardware
accelerator is plugged in or not. In general, only on applications (the
language is not relevant) which are heavy users of FP would you see any
difference.

On the /23, with no KEF11-A FPU chip plugged in, there are no floating point
instructions at all, so any application which tries to use them will blow out
(although under V6 there's an emulator); see here:

  http://gunkies.org/wiki/Setting_up_UNIX_-_Sixth_Edition

and search for 'floating point' to see discussion of it).


> From: Ethan Dicks

> v5, v6, and v7 UNIX shouldn't require any sort of math hardware.

Don't know v5/v7 in detail, but AFAIK that's accurate. V6 can _support_
FP hardware on machines which have it, and is otherwised prepared to
emulate those instructions (see above).

> From: Paul Koning

> I think that was typically called "EAE" (extended arithmetic element),
> a Unibus peripheral that implemented integer mul/div ... It only
> applies to 11/20 and 11/05 since all the other machines have the
> relevant instructions built into the CPU.

Also the -11/04 and -11/03 were both missing the EIS; the former could use
the EAE, for the latter the optional KEV11-A or KEV11-B microcode chips both
provide it.

> From: Josh Dersch

> The EAE was also an option on the 11/40.

Technically, on any UNIBUS machine; on the /40, the EIS (added instructions,
not the device model of the EAE) was available via an optional board in
the CPU.

Noel

Re: Plane of core memory

[Will Cooke via cctalk]

> > > Does anybody here have any ideas? For example, what is it? Or, if you 
> > > don't know, could you point me in the right direction so I can do the 
> > > research myself? Thanks!!
> > I have no idea.
> > 
> > The connectors remind me of a DEC machine bus, but I don't know what the 
> > bus name is. I also find it odd that memory would plug into the system bus 
> > like that.
> 

I wouldn't have a clue what that came from, but here's something to consider.  
The seller is in Huntsville, Alabama, home of many, many military and space 
contractors.  It could very well be from some very odd piece of very low volume 
military or space equipment.

Re: Plane of core memory

[Brent Hilpert via cctalk]

On 2019-Apr-17, at 9:47 PM, Grant Taylor via cctalk wrote:
> On 4/17/19 10:30 PM, Andrew Luke Nesbit via cctalk wrote:
>> Hello all,
> 
> Hi,
> 
>> I have been wanting to acquire a plane of magnetic core memory as a piece of 
>> computing history.  My partner actually thinks they look very beautiful and 
>> says we should frame it, if we ever find a plane.
> ...
>> Does anybody here have any ideas?  For example, what is it?  Or, if you 
>> don't know, could you point me in the right direction so I can do the 
>> research myself?  Thanks!!
> 
> I have no idea.
> 
> The connectors remind me of a DEC machine bus, but I don't know what the bus 
> name is.  I also find it odd that memory would plug into the system bus like 
> that.


It doesn't plug into a system bus, it would plug into a dedicated slot 
connected to other dedicated boards.
There's piles of circuitry necessary for it be fully functional: decoded x/y 
drivers, inhibit drivers, sense amplifiers, word latch, cycle sequencer.

It's a 4-wire 3D planar array. By topology and construction I would guess it 
date it from the 60s.
Into the 70s most (American) core production had moved on to simpler weave 
topologies (the crosshatch sense winding, as in this unit, was very laborious 
to weave),
(although it is not precluded from being from the 70s).

From an historic perspective, the 4-wire, 3D, crosshatch sense aspects go back 
to the original core topology,
although here the earlier physical stack for the 3rd dimension is flattened to 
a planar array.

Re: Plane of core memory

[Andrew Luke Nesbit via cctalk]

On 18/04/2019 05:47, Grant Taylor via cctalk wrote:
> If you just want core memory, check out the following link:
> 
> Link - Core Memory Shield for Arduino
>  - https://www.tindie.com/products/kilpelaj/core-memory-shield-for-arduino/
> 
> You can actually use Core Memory on a modern computer.  }:-)

This is great and I will look into this.

But my original request was for something a little bit different.  That
is, a properly specified core memory plane in working condition, because
I would very much like to interface with it from a modern computer.

> The connectors remind me of a DEC machine bus, but I don't know what the
> bus name is.  I also find it odd that memory would plug into the system
> bus like that.

Yes, I agree.  And somebody from a DEC list I'm on said that the number
of connectors and their spacing isn't anything they've personally seen
before.

Andrew
-- 
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9