That doesn't sound right. The fundamental property of core memory is that the cores have a threshold flux level (hence magnetizing current level) that causes them to flip state, while currents modestly below the threshold (like 1/2 of it) have no effect. A "concident current" core memory has a grid of X and Y wires for addressing. The word address is split in half. One part selects one of the X wires, the other one of the Y wires. Each selected wire receives a current pulse half the threshold current. Result: the addressed core (at the intersection of the two selected wires) flips state to match the direction of magnetization for the X/Y currents, if it wasn't already in that state. For a read, the current direction is one way which is defined to represent zero. If the addressed core was in the "one" state, the state flip induces a current into the "sense" wire -- which runs through all the cores in the plane. So read is actually "read and clear". For a write, the current direction is the other way, representing "one". Write is done after read, and only to the planes of the core where you want a 1 bit in that word. So in the simplest case, you end up having to have per-plane control over the X/Y drivers to select whether a write will write a 1 (current is on) or a 0 (no action). The inhibit wire offers a different approach. In that case, the X/Y drivers simply select the word, and are unconditionally on for both read and write. To determine whether a 1 bit or a 0 bit will be written, the inhibit current is either off, or on, respectively. The inhibit current runs opposite the X/Y current. So if the inhibit current is off, the core at the X/Y intersection sees 0.5 + 0.5 times the threshold current, or 1x, so it flips state (to "one" in the case of a write). If the inhibit current is on, the core at the X/Y intersection sees 0.5 + 0.5 - 0.5 times the threshold, or 0.5, so it does not change state. None of this has anything to do with margin. Coincident core memory is absolutely dependent on the property that the 0.5 current level doesn't change the core state. Instead, the inhibit scheme simplifies the circuitry. I've seen some variants. The CDC 6000 series core memory doesn't use one inhibit wire, but rather two per core (so 5 wires per core total: X, Y, two inhibits, and sense). The memory plane is split into 16 squares (4 x 4). There are four separate "X" inhibit wires and four "Y" inhibits. So the word address does two things: it selects a specific X and Y address wire, and two of X and two of the Y bits select a specific pair of inhibit wires. I think the reason for doing this is to reduce the inductance of the inhibit wires (they only pass through 1024 cores rather than the full 4096) which allows higher speed operation. And the use of pairs of inhibit wires means that each inhibit wire carries 0.25 times the threshold current, which may also help the drive circuitry. One of these days I should take some of the material from the old (apparently uncopyrighted) 6600 training manual and adapt it for the core memory article in Wikipedia... paul

IBM 1620? That acronym fits it nicely, because the 1620 (model I that is) did add and multiply by table lookup, so it couldn't add unless the right data were first loaded into memory. paul -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mike Loewen Sent: Wednesday, November 12, 2008 3:53 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: IBM 1602 Does anyone have any pictures of the IBM 1602 system? It was the same vintage as the 1401 (1959), and briefly known as the CADET (Can't Add, Doesn't Even Try), before the name was pulled. :-) Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/

Yup, the 1620. More specifically, the 1620 Model I. Later versions of the machine didn't require in-memory tables to do arithmetic. But the original version required at least the addition table and, if multiply was used, the multiplication table. This was a decimal machine, addressed by digit, with 6 bits per digit (8421+word mark+parity). Core was 12 bits wide, with odd-even locations in the same word. The neat thing is that the 1620 was a variable-word-length machine; numbers were addressed by the location of their least significant digit and terminated by the occurrence of a work mark on the most significant digit (a word mark on the least signficant signified a negative number). Records were addressed by the lowest address position and terminated by a record mark. One could manipulate numbers with thousands of digits with no particular special programming effort. Or, one could alter the arithmetic tables to do arithmetic in a different radix (sometimes this happened accidentally). Clearing memory was a matter only one instruction. A machine that was great fun, if not glacially slow. Dijkstra hated it. Here's a sample program: http://99-bottles-of-beer.net/language-ibm-1620-sps-916.html Cheers, Chuck

On Wed, 12 Nov 2008, Brent Hilpert wrote: 40 some years ago, Merritt College (Oakland, origin of the Black Panthers) was running PDQ FORTRAN and a 1401 emulator on a 1620. Those were the good old days. Even if it was uphill in both directions. My favorite teacher was a real grouch who didn't like me, but he really knew his stuff. ~25 years ago, when I got tenure, I was given a very old wood desk to use. It was still full of papers from my old teacher (who had died about 30 years ago). One of my colleagues had the card decks for the software for the 1620, until the college administrators had it all dumpstered one weekend. -- Grumpy Ol' Fred cisin at xenosoft.com

Is Monitor II available? For even more retrocomputing fun, you could try to dig up the implementation of Dynamo -- one of my fellow students had that running on our 1620 Mod 2, thanks to Fortran probably -- and run the old Club of Rome sims. Good for comic relief. Paul

On 12 Nov 2008 at 18:32, Patrick Finnegan wrote: http://bitsavers.vt100.net/pdf/ibm/1620/C26-5600- 1_Symbolic_Programming_System_Apr63.pdf Strangely, bitsavers doesn't have the Monitor II-D reference. I'll have to put mine in my will so that Al gets it when I come to my own personal BSOD. Cheers, Chuck

On 12 Nov 2008 at 17:22, bfranchuk at jetnet.ab.ca wrote: Nah, just hit "LOAD" and code away at the console typewriter. We don't need no stinking coding forms! Cheers, Chuck

On 12 Nov 2008 at 17:47, bfranchuk at jetnet.ab.ca wrote: That *would* be kind of cool, but no. I wonder if one could take a cheap electronic typewriter and write a simulator to fit in one? Of course, the typewriter wouldn't have the feeling of "going to fly apart after the next carriage return" and no blinkenlights, but it'd be fun. Cheers, Chuck

On 13 Nov 2008 at 10:57, Ian King wrote: Even in the corporate environment, you often only got a max of 2 or 3 runs per day. The height of luxury was composing your programs at the operator's console of a CDC 6600, using the o26 PP utility and assembling/compiling using DIS. Yet, I knew several programmers who worked just this way, myself included. Sometimes, the keypunch was just too far away... If you needed cards, you could always copy the file to the punch queue. For whatever dedicated block time went for back then ($500/hour?) it was better than lighting cigars with $20 bills. I learned very early on to develop a very chummy relationship with the ladies of the keypunch pool. It made all the difference in the end product, my chickenscratches notwithstanding. List the result on a 407, hand-check against your original coding forms. It was surprising how many logic errors you could turn up in this process. Cheers, Chuck

On Wed, 12 Nov 2008, Paul_Koning at Dell.com wrote: I believe I may have been mistaken in the use of "CADET", due to some questionable references on the 'net. I know what a 1620 looks like, and have pictures of the one at the CHM. This is what I'm trying to find: http://sturgeon.css.psu.edu/~mloewen/Oldtech/Panels/IBM1602-L.jpg Mike Loewen mloewen at cpumagic.scol.pa.us Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/

On 12 Nov 2008 at 15:47, Paul_Koning at dell.com wrote: Indeed, there's even a blog entry from a failed bidder who thought this belonged to the 1620. But I've never heard of the 1602 box and a web search of an IBM "processing adapter" shows zip. Was this thing even part of the 1620 line? The number seems to defy the general pattern that has the CPU as the lowest-numbered item. E.g., 1620 = CPU, 1621 = paper tape reader, 1622 = card reader/punch, 1624 = paper tape punch, 1623 + 1625 = auxiliary core storage, 1626 = plotter controller, 1627 = plotter, etc. This thing, whatever it is, sounds more like something associated with unit-record equipment; perhaps related to the 602 calculating punch? Cheers, Chuck

I had experience with one of the programmers for the instrumentation unit for the S5 stage which was in the ring between the first and second stages, I think. I was an expert witness in a lawsuit having nothing at all to do with this, but he was the expert called for the other party. To make a long story short, expert witness' credentials frequently turn out to be who has the best credentials. I talked to him before we went in to a deposition, and I granted him that point before we even started. I feel privileged to have met him, and wish we could have visited more on the subject rather than what we were paid to do. Sadly I was not even supposed to get into anything but luckily this was told to us after we had chatted. I think his name was Tom Follett, and I do not recall ever finding anything about him. I believe that he had a PhD, but I do not recall much else, such as company, or education. I don't know much about what this system had to do other than ground to second stage ignition guidance tasks. Jim