return to main page

Core Memory e-mail

Table of Contents
     - Introduction
     - Memory drawings
     - Tubes
     - Memory For Card Reader
     - How the 1401 system reads punch cards by Anonymous
     - Tales & Memories

A quick introduction
Apparently T.J. Watson sent a company directive - starting the slogan "Solid State in '58".
The 1401 was all "solid State", except for one vacuum tube in an alignment aid circuit in the 1403 Card Reader/Punch - hidden away in a little aluminum box.

Coincident current magnetic core memory had been used in other computers, but because of "interesting" drive requirements, for the X and Y drives, had been driven by vacuum tubes.

Memory drawings

Tubes - From Rick Dill (8/12/09)
...
On old TUBE computers (yes I cut my teeth on them) the usual discussion is about filament burn-out (which was usually only a small portion of the tube failures). When we went to transistors, we counted the number of diodes used, but in most of the tube computers, diodes were used to do the logic and the tubes were just there to bring the output signals back up to the levels needed for the next logic stage (diodes again).

...
In the 1950's, most silicon transistors were grown junction type. These were totally uncompetitive. There is no reason to think that they were good for computers. The saving grace was being able to operate at higher temperatures. In the 1960's all that changed with the use of photolithogaphy along with diffused junctions for both emitter and base regions, along with epitaxial growth to allow higher voltage collectors (low doping in the epitaxial collector ) along with the low contact resistance of a highly doped wafer.

Memory For Card Reader - From Guy Fedorkow < guy.fedorkow@gmail.com > Date: Sun, Jun 21, 2015 11:57 am
Now incorporated into IBM 1401, A Modern Theory of Operation by Guy Fedorkow, as of June 28, 2015
hi Ken, I think we're getting there... if I can push just one more step...
I can see how the current passing through a read brush can directly magnetize the corresponding core. But it still seems like there needs to be some control over when that write current flows, or else the read phase wouldn't work.
I'm not sure where to find the clue, but it seems like there could be two possibilities:
  • maybe they run read cycles during the gap between rows when no read-brushes should be active. Seems kinda risky, but maybe it could work.
  • maybe there's a relay in the 1402 that pulses the current supply to all 80 write lines when the card is likely to be on the center of the row, and then turns the write current off so the row bits can be read out.
Seen anything that would offer a guess as to how that part works?

As to whether the design is "good" or not... I assume the 9-edge-first mechanical design, and the initial plan with blocking reads (i.e., no overlap), all the extra read and write cycles are "free". Seems not bad...

Thanks,
/guy 


On 6/20/2015 7:05 PM, Ken Shirriff wrote:
>
>
> On Sat, Jun 20, 2015 at 3:23 PM, Claunch,Carl  wrote:
>
>     Hi Ken
>
>      
>
>     Your message is clear and complete. I can t say this makes sense, 
because that would give credit to the design of the 1401. Your message makes sense
 but is describing a byzantine, bizarre almost Rube Goldbergian process. 
I am amazed to see the machine do all those (complement) additions for each 
digit/row time. So incredibly many cycles are used compared 
to the eighty memory cycles that modern designers would expect this to take.
>
>
> My interpretation of the card reading process is that mechanically reading the 
card is extremely slow compared to the time it takes for processing and 
memory cycles, so they didn't worry about efficiency. In other words, 
why not read and write each character storage location a dozen times per card, 
there's plenty of time while the card moves through the reader. 
If they could save some hardware by using the adder 80 times for each row, 
then it was probably a reasonable idea.
>  
>
>     I did expect re-use of the core logic and physical structure as 
much as possible, which is why an entire 4K bit plane would be used 
to hold 80 bits (and a second 4K plane for the 80 check bits).  
Are those depopulated planes, having just eight cores strung 
on them? Plus the extra wire from the card reader for each one?
>
 





	
Depopulated Core Plane


 The "extra" planes are depopulated planes with 80 cores, 
plus cores for other random things (1410 brushes, 1403 hammers, 
printer error checking,  punch brushes). 
I'm not sure exactly how many core are in each plane.
 The following picture of the core module shows a partially 
populated plane. 
Note the missing cores at the bottom of the photo. 
The lower half of the  plane (not in photo) is entirely unpopulated. 
The planes wired directly to brushes is in the middle of the module 
(planes 10 and 12 of 16) so unfortunately I couldn't get a photo 
showing the wiring, 
even after a bunch of attempts to focus on that plane specifically. 


 
>  
>
>      
>
>     While I thought this clarified everything, I see mention that each hole 
will flip the core, reversing its state. I don t understand the physical mechanism 
that will do that   
sending a current in a given direction will flip a core in a specific direction. 
If it is already set in that direction, it just stays set. Yet, the writeup 
makes it sound like each pulse is a toggle, turning a 1 bit off or a 0 bit on. 
Any idea how that is accomplished?
>
>
> I know the text you're referring to. I'm reluctant to state that the 
manual is wrong, but I'm convinced that the text is at best misleading. 
The core is flipped from 1 to 0 and not the other direction, 
so it's not really a toggle.
>
>     Thank you for the pointer to the diagrams and flowchart. I am sorry 
to say that I am getting a much better picture of how this works   in 
hindsight I wish I hadn t asked.
>
>      
>
>     Carl
>
>      
>
>     From: Ken Shirriff [mailto:ken.shirriff@gmail.com]
>     Sent: Saturday, June 20, 2015 1:18 PM
>     To: Claunch,Carl
>     Cc: ...
>     Subject: Re: How does that Card Reader work...
>
>      
>
>      
>
>      
>
>     On Sat, Jun 20, 2015 at 11:04 AM, Claunch,Carl  wrote:
>
>         Hi Ken
>
>          
>
>         Couple of questions  
>
>          
>
>         The row bit cores   how are they reset to 0 before a read cycle?
>
>      
>
>     The row bit cores are cleared when they are read (same as the destructive 
	read with regular cores).
>
>      
>
>         How are the addressed and read when picking off the bit for each column 
	sequentially as the BCD character values are stored in regular core planes 
	for the same column address?
>
>      
>
>     All the planes have the same addressing lines. The row bit cores are addressed 
	as 001 through 080, the same as the other card locations, 
	but have a separate output line. So when the character is read from 
	a location (e.g. 001), the row bit cores and check planes at that address 
	are read at the same time.
>
>      
>
>         Are they organized as 80 x 12 with gating to inhibit all but the row 
	being read, or are they organized as 80 x 1 and they have to be read 	
	12 times for each card?
>
>      
>
>     The row bit cores are 80x1. The row bit cores are processed 12 times 
	for each card, as are the actual characters in storage, 
	which are built up one row at a time.
>
>      
>
>     I hope this makes sense. The process seems a bit crazy. For the exact 
	step-by-step flowchart of the read process, see page 49 of 1401 Dataflow.
>
>      
>
>     Ken
>
>      
>
>          
>
>         Carl
>
>          
>
>         From: Ken Shirriff [mailto:ken.shirriff@gmail.com]
>         Sent: Friday, June 19, 2015 5:19 PM
>         To: Guy Fedorkow
>         Cc: ...
>         Subject: Re: How does that Card Reader work...
>
>          
>
>          
>
>          
>
>         On Fri, Jun 19, 2015 at 11:43 AM, Guy Fedorkow  wrote:
>
>             hi Ken,
>               Thanks for working on this.
>               I'm afraid I'm still not quite getting the complete picture.
>             The part of the story that has to be the hardest to grok, at 
	least for me, is how the data is initially transferred from the 
	read brushes to the core storage.
>               I understand (although it's hard to believe without seeing) 
	that there's a physical wire made of actual, non-virtualized copper, 
	from each read brush through a couple of big cables to a special 
	segment of the core plane.
>
>          
>






          Yes, each brush has a physical wire going to one particular core. 
	Here's a diagram of the core from ALD 42.41.11.2. Note in the lower middle 
	the wires directly to the core module for RD-PCH-BRUSH and PRT HAMMER DRIVERS. 	
	There are direct wires to the cores from the read and punch brushes, 
	and also from the print hammer drivers (for error checking which I will
	 explain in a writeup about printers soon). ALD 42.40.51.1 lists the 
	connections between each read brush and each row bit core.


         
>
>               Do you think that wire acts as a write-Inhibit?
>
>          
>
>         The wire isn't acting as write-inhibit; the wire flips the core directly.
	 There's no addressing for the write and no write cycle and no inhibit, 
	just a wire through the core making a magnetic field and flipping the core 
	if the brush senses a hole. It's literally as simple as you can possibly get 
	for setting a magnetic core. You can see from the diagram above that there 
	are no inhibit lines to the RD2-PCH plane.
>
>          
>
>               If that's the case, then I think something like this might happen:
>               - when the reader indicates that the next card row is positioned 
	exactly, something would trigger a set of 80 core cycles. I assume that 
	indication comes from the Solar Cell logic that would sense the position 
	of cam in the reader.
>               - as usual for write cycles, the first step is a "read" which sets 
			the core to zero, followed by a write that stores the value 
			read from the brush.
>               - I think that means that there must be one big inhibit driver 
			that activates the 80 inhibit lines at the correct microsecond 
			during the write phase.  Unless maybe the read cycle can clear 
			the core even with inhibit current flowing.
>               - after cycling through the 80 cores, the cores would reflect which 
			rows have holes and which don't.
>              		 This seems to be the magic part.
>
>               The rest is specialized but ordinary logic. 
>               Maybe in a second pass, those same 80 cores are read sequentially, 
			with a number of updates
>               - the two bits of hole-count corresponding to each column are updated.
>               - the value corresponding to the row is or'd into Real Memory 
			if the column had a hole.  I think you said that value is stored 
			in the A register.   That part is kind of cool; 
			it hadn't occurred to me that the codes corresponding to each row 
			could simply be or'd into the main memory one row at a time 
			and come out with the right result.
>
>          
>
>         Yes, that's what happens to process the row. The row-bit cores are scanned 
	from 001 to 080 and the value corresponding to the row is or'd into location 
	001 to 080. (With a few complications for special characters like '0'.)
>
>          
>
>         Ken
>

>         Does this sound plausible, or is there something else going on?
>
>         /guy
>
>             ps, those guys should have pushed back harder on the mechanical team to 
	make them read the card right-way-round :-)
>
>             On 6/12/2015 4:34 PM, Ken Shirriff wrote:
>
>                 Hi Guy! I've typed up what I know about card reading on the 1401, 
	if you want to add it to your document. I'm not sure how much of this is generally 
	interesting versus interesting just to me, but take a look...
>
>                  
>
>                 Hopefully you can just cut-and-paste the text below into your document. 
	If not, let me know and we can work out a better format.
>
>                  
>
>                 Ken
>
>                  
>  The IBM 1401 and the 1402 card reader
>
>        This section discusses how the IBM 1401 reads cards. 
	This section focuses on the interpretation of the holes into characters in storage,
	 rather than the mechanical aspects of the card reader. 
	Punching is ignored in 	this section.
>
>       The card reader has two read stations. A card first passes through 
	read station 1 and then read station 2. 
	Each read station has 80 brushes to detect the presence of a hole in a column; 
	these are also known as circuit breakers. 
	Each read station has 80 wires to the 1401, one for each brush.
>
>       As a card passes through the first read station, 
	the holes in each column are counted. At the second read station, 
	the core storage 	for the card (positions 001 through 080) is updated 
	based on the contents of the card. 
	In addition, the hole counts are verified at the second read station 
	to detect read errors.

>  Understanding the IBM punch card code
>
>       An IBM card consists of 80 characters in 80 columns. The card has 12 rows. 
	The top row is the 12 row, and below that is the 11 row; these are both used for 
	zone punches. Below that row are rows 0 through 9, for numeric data. 
	The top of the card is known as the 12 edge, and the bottom of the card is the 9 edge. 
	This is important to remember, since cards are fed into the card reader face down, 
	9 edge first.
>
>       The punch card code is mostly straightforward, but has a few complications. 
	The overall structure is a character is punched as a BCD part and a zone part.
>
>       The BCD part is usually punched as follows:
>
>           0: no punch
>           1-9: punched in that row
>           10: punched as 8-2 or 0, depending on the circumstances.
>           11-15: two punches with 8 and the remainder (i.e., 8-3 to 8-7)
>
>        The zone bits are usually punched as follows:
>
>            no zone bits: no punch
>            zone A: row 0 punched
>            zone B: row 11 punched
>            zone AB: row 12 punched
>
>       The main complication in the code is that the 0 row can indicate a 
	zone (A) or a digit (0). Also, the 1401 stores a blank character as BCD 0, 
	while a zero character is stored as BCD 10. This results in special cases, 	
	which are handled as follows:
>
>             BCD 10 with no zone (digit '0') is punched as 0.
>
>             BCD 10 with zone A (record mark) is punched as 0-8-2 
		(since row 0 can't indicate a zone and a digit at the same time).
>
>             BCD 10 with zone B or zone AB ('!' or '?') are punched as 0-11 and 0-12 
			respectively. 			
	Interestingly, the 029 keypunch handles these differently, 
		using 11-8-2 and 12-8-2.
>
>             BCD 0 with no zone (blank) has no punches.
>
>             BCD 0 with zone A (cent) cannot be read from a card by the 1401 
			(since a 0 punch is interpreted as zero). The 029 keypunch 
			uses an 8-2 punch for this.
>
>             BCD 0 with zone B ('-') has an 11 punch.
>
>             BCD 0 with zone AB ('&') has a 12 punch.
>
>       See 1401 reference page 170 for a summary of the IBM 1401's punch card code.

>   The reading algorithm
>
>         The 1401 uses a surprisingly complex process to read a card into memory. 
	You might expect that the card reader reads each character of the card and 
	sends the character to the 1401 as 6 bits. Or maybe the card reader 	
	sends each character as 12 undecoded positions. But the real mechanism is 
	totally different: the card is read sideways, and all 80 positions in a 
	row are sent to the 1401 in parallel. The card reader is entirely 
	electromechanical, and all the processing happens in the 1401.
>
>       The following is a simplified description of the card reading algorithm. 
	The algorithm is described in detail in 1401 Data Flow, pages 49-54.
>
>       The rows of the card, from 9 through 0, then 11 and 12, 
		are processed one at a time. 
>       After each row is read at read station 2, it is processed as follows: 
>             First, the A register is set to the value of the row: 9 through 1, 
		then zone A (for row 0), zone B (for row 11) and zone AB (for row 12). 
>             Next, the B address register steps through the columns 001 to 080.
 
	For each column, the current memory value is read into B. 
	If the associated row-bit core is set, the A register value is combined 
	with the B register value. The result is written back to memory to 
	update the character according to the hole's value. 

>        At the end of this process, locations 001 through 080 hold the 
		characters from the card.
>
>        Thus, each position of the card is processed individually, 
		from the lower left to the upper right.

>  The read circuitry
>
>         This section discusses some of the card reader circuitry, 
	focusing on the punch card code processing and how exceptions 
	in the punch code are handled. The circuitry is housed in gate 01B4. 
	The Intermediate Level Diagrams (ILD) show the gate-level circuits for 
	the reader/punch in diagrams 60 through 68.
>
>       The value of the A register corresponds to the current row 
	(9 through 1, then zones A, B, and AB). 		
	The B register holds the value currently stored in memory for that character. 
	The signal RD2 at 60B1 indicates a hole at the current row/column.
>
>       Reading a zero needs to be handled specially: 
	it is punched in the zero row (i.e. zone value A), but is stored in BCD as 10. 
	This is handled by the gate at 60B1 (i.e. ILD #60 section B1), 
	which causes BCD 10 (8+2) to be written to memory.
>
>        The IBM 1401 handles MLP punches. MLP (multiple-line printing) 
	was a feature of the IBM 403 tabulating machine (p113). 
	A MLP card was indicated by a 9, 8, and another punch all in a single column. 
	The 1401 ignores the 8-9 punches on an MLP card, 
		reading the remaining value (1401 Reference manual, p170). 
	The gate to handle a 9-8 MLP punch is at 60C1. 
	It causes the read value to be cleared when a 9-8 punch is detected, 
	so the remaining punch will be the value read.
>
>       The gates at 60C1 detect the first row (9 normally, 
	but for column binary, row 3 restarts the process.)
>
>       At 60D3, two digit punches for the same character (excluding 8) 
	triggers a validity check. The gate below triggers a validity check 
	for two zone punches. Note that 11-0 and 12-0 are okay 
	because the 0 will be converted to BCD 10 before the zone row is read. 
	The gate below that triggers a validity check for 8-1.
>
>       The gate at 60B3 triggers a validity check for 8-2, unless it is 0-8-2.
>
>       At 60B4, the gate with puzzling inputs
		"A reg not 4, A reg 1, A reg not C" 
	turns out to match the row 1. 
	It is used to switch procesing from numeric rows to zone rows.
>
>       The data flow to the A and B registers is on ILD pages 10 and 11. 
	The gates at 60D2 control the inhibit lines for A and B, 
	controlling updates to these registers.

> Hole counting for validity checks
>
>       When the card passes through the first read station, 
`		the holes in each column are counted. 
	At the second read station, 
		the hole count is verified to check the validity of the read.
>
>       It turns out, though, that it's not exactly a count 
	but a simpler two-bit value used in this process. 
	The two bits start off cleared. The first bit (denoted U) is set 
	when a hole is encountered. The second bit (denoted L) 
	is toggled on each hole. 
	Thus, three states are distinguished: no holes, odd number of holes, 
	and even number of holes.
>
>        For the second read, the transitions are reversed. 
	The first bit is cleared when a hole is encountered, 
	and the second bit is toggled. 
	If all goes well, both bits will be clear after the second read. 
	Otherwise, there is an error.
>
>       This will catch missing a single hole, or missing all the holes. 
	There are some count errors it will miss, 
	such as reading 1 hole versus 3, since it doesn't store exact counts.
>
>       Hole counting requires two separate sets of storage, 
	since while the first card is being validated, the second card is being read. 
	For each card, the 1401 toggles between two sets of row bit storage planes, 
		labeled X and Y. 
	Thus, the planes used for hole counting are XU, XL, YU, and YL, 
		each consisting of 80 bits.

> The hole counting circuitry
>
>      At ILD 62C1, a trigger switches between row bits X and row bits Y 
	on each card. For state X GATE, row bit X indicates a hole at 
	read station 1 (RD 1) and row bit Y indicates a hole at RD 2. 
	For Y GATE, the bits are swapped. This selection is done by the 
	gates at 62C3. (During punching, the bits come from either 
	Punch Check Decode or B Reg Punch.)
>
>       Latches at 62C3 hold the current state of the bits as read from the cores.
>
>       At 62C4, gates generate the new values for the hole counts. 
	XU (or YU) is set when a hole is detected during the count phase 
	and is cleared when a hole is detected during the verify phase. 
	This will trigger an error if a hole was detected at RD 1 but not RD 2. 
	It ignores the case where a hole was detected at RD 2 but not RD 1. 
	XL (or YL) is generated from the XOR of the old value and the current row bit, 
	so the value is toggled on a hole.
>
>       The gates at 62B6 trigger an error 
		if either hole count bit is set at the end of the process.

> The card reader and core memory
>
>       Card reading uses special core planes separate from the regular memory planes.
	Six additional planes are used: 
		two for the row-bit cores, and four for the hole counting. 
	These planes are not fully populated since there are only 80 columns to store. 
	These planes have separate outputs from the regular memory planes, 
		but use the same addresses (001 through 080).
>
>        Read station 1 is connected to cores in plane RD1 (frame 12) 
	and read station 2 is connected to cores in plane RD2 (frame 10).
	 Surprisingly, each brush is wired directly to a particular core with a separate wire, 
	rather than using the inhibit line like the regular cores. 
	Thus, the row can be written to the row-bit cores in parallel, without addressing. 
	Two separate frames (9 and 11) consisting just of terminals and wiring 
	sit above RD1 and RD2 to handle the connections to individual cores. 
	Four planes are also used to count the holes: 
		XU 11, YU 12, XL 13, YL 14 (frames 13-16). 
	Cores in these planes are written in the standard way, using inhibit lines.
>
>        The sense lines for each plane are shown in ILD 4 
	and the inhibit lines are in ILD 3. 
	The details of the core memory are given in ALD 42 (page 13).

> Conclusion
>
>       Card reading on the IBM 1401 is surprisingly complex. 
	Massive cables connecting the brushes in the card reader directly 
	to individual cores in memory. 
	The logic for this operation is all in the 1401 itself, 
	with the computer processing each of the 80 by 12 card positions individually 
	to generate the card characters in storage. 	
	Multiple validity checks ensure the accuracy of this process.
>
>                  
>
> On Wed, May 27, 2015 at 5:12 AM, Guy Fedorkow  wrote:
>
>         hi Ken,
>       That's cool stuff you've been doing with the 1401!
>        I'm not sure if you've picked up another activity related to this
>         machine -- I've been working, very slowly, with Robert and a number of
>        restoration team members to put together a modern 'theory of operation'
>         for the machine, something that would help a modern reader (or potential
>        restoration team member) understand how the machine works, well enough
>        that they can dig into the primary IBM documents.

>        This work is handicapped some by distance -- I'm based in
>         Massachusetts -- but that does result in a focus on the material
>         available on line.  I already owe you a thanks for the SMS Card index.
>        That, plus Van Snyder's on-line ALDs, plus many other scanned docs make
>        it possible to thread all the way from instructions down to transistors.

>        Anyway, I've attached my current draft / construction-site.  I hope
>        the doc will be well-enough organized some day to answer Randy Bush's
>        request on your blog for more on the machine's architecture.
>
>        Let me know if you see anything in the doc where I'm heading off in a
>        wrong direction.
>
>        /guy fedorkow
>

How the 1401 system reads punch cards by Anonymous
A person not usually regarded as shy has submitted this, "anonymously", with Ron Williams' approval?
Material in brackets [] are "clarifications" by Ed Thelen
How the 1401 reads punch cards
  1. The row cores 1-80 [in the special core plane] are cleared
  2. The data in main memory locations 1-80 is cleared.
  3. A row is read from the current card and each column is read into the corresponding row core [of the special core plane].
    The roller [touching the column brush if a hole punched] is fed 20 VDC in the middle of the row
    and each brush feeds a core [flipping its magnetic orientation] through a 220 ohm resistor.
  4. Before the next row, each row bit [of the special core plane] is [read] out of the row bits serially and fed to the character generator.
  5. The character generator access[es] the existing main memory location [1-80].
  6. Based on the current bit from the row plane and the current data in the corresponding main memory location, the character generator builds the character in main memory [1-80].
  7. Steps 3 through 6 happen 12 times for each card

Tales & Memories
From Michael Albaugh May 02, 2020 8:29 am
     To Alan Palmer: - Sat, May 02, 2020 1:11 pm
    In our IBM Endicott, NY Glendale Lab model shop area in 1956-1959 there were two middle aged, heavy hind quartered US ladies hand wiring 2K core memories. These core arras were used in early proto-type 1401 system process units. By 1959/60, IBM Burlington, VT was producing production wired units for 1401 shipments. I never heard of any IBM off shore skills needed for anything until at least the mid/late 1970's.
Best Regards.
---- Jud McCarthy

JUD - Sat, May 02, 2020 2:26 pm
     When I wrote my comment it was ended up being above the previous one that had questioned the use of off- shore women to wire cores. I was not responding to that comment.
     I wrote my comment as a general one saying that when I worked in Poughkeepsie in 59-61 there was open area where women were stringing the read/write /inhibit x/y wires through the donuts. There was a machine that would be loaded with the cores and would shake them so as to fall in the correct position into the frame that held the donuts for wiring. The had large magnifies and bright lights for their work. You could stand and watch them but it was nothing special to see since you saw it everyday.
Allen Palmer

return to main page