Core memory has another complication ........
Reading a core memoryline from the matrix means you also
have to write the line back because reading from core memory
is a data destructive operation. This means that any read cycle
is in fact a read+write memory cycle. This has also concequences
for the total speed of subsequent read operations (like a program
running from core). The read access may be reasonably fast but
the next read cycle can only start after the internal write-cycle
has completed................
A kind of page interleave may solve this problem but:
Obviously you'll have to cook up all the extra logic to execute
all this in hardware ..............
Regards,
Sipke de Wal
---------------------------------------------------------
http://xgistor.ath.cx
---------------------------------------------------------
----- Original Message -----
From: Bill Richman <bill_at_timeguy.com>
To: <classiccmp_at_classiccmp.org>
Sent: Wednesday, April 03, 2002 7:41 PM
Subject: Core Memory Interfacing?
> 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?
>
>
>
Received on Thu Apr 04 2002 - 13:53:58 BST