4 Apr
2002
4 Apr
'02
5:53 a.m.
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(a)timeguy.com>
To: <classiccmp(a)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?