3 Apr
2002
3 Apr
'02
6:08 a.m.
Bill,
You're a man after my own heart! I've been thinking about this for some time. I
once had some NICE small core planes (16k I think) out of a HP communications analyzer and
I think they would have been just about perfect for this. I had too many other projects at
the time so I sold them but I know where there are some more analyzers so I may grab them
and swipe the core from them. I found the service manual for the analyzer so I had the
pin out for the entire machine including the core. (I still have it). IIRC the core module
was about 5 inches square and had all the drivers and sense amps on it so that might make
things easier. However there are some things that you have to do with core and I don't
know if they handled in hardware or if the OS had to take care of it. For example, reading
core is destructive, that is it erases the contents so you have to store the contents back
into it before you do anything else (unless you don't care if it's lost). That
seems like it would be easy enough to do in HW but I don't know if that's what
they did.
Joe
At 11:41 AM 4/3/02 -0600, you wrote:
Right off, let me say that I know next to nothing about
the realities of
using core memory. I only know that it looks like pretty cool stuff to
play with. Would I be completely off my tree to try to build a core
memory interface from scratch, assuming I had a pre-strung core frame with
all the cores and wires intact? When I say "interface", I mean basically
something that will let me talk to the core from a PC or from my
recently-completed Mark-8 using TTL or CMOS levels. If I have a 64x64
frame, would I just need something on the order of 256 driver transistors
(one to drive each of the X and Y wires in either direction) plus some
kind of op-amp or comparator circuit to monitor the sense wire (is there
just one of these per frame?) and determine whether or not a bit has
flipped during a read pulse? Or are there all sorts of ghosts and goblins
lurking in core memory that I don't want to confront?