You suggest a lot of responses here, so I'm a little shy to respond with only this. BTW nice history lesson. Yes, on order of seconds. 2 secs for an extremely simple problem and 10 secs for a very complex one. Required use of a special third register. The algorithm was a simple one. More to the largest digit and subtract down the number until zero was reached. Every time zero is crossed, one time the divisor was added back and the next lower position of digit was then used. This process was painfully obvious just from the noise it made. P.S. Was this one of the nonbinary "biquinary" machines? I guess one of the determining factors between computer and calculator. John A.

--- Jerome Fine <jhfine(a)idirect.com> wrote: Is this a difference between optical and mechanical readers, or simply a tolerance issue? -ethan ===== Visit "The Seventh Continent" http://penguincentral.com/penguincentral.html __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/

On Tue, 3 Jul 2001, Jerome Fine wrote: What I learned in school 35 years ago: Long ago, IBM patented the shape of the hole, and a few companies attempted to build machines with round holes! But THAT is not the issue. That patent was overturned. Then, in their ongoing efforts to mistreat the competition, IBM patented their brass roller. The IBM card reading system consisted of a brass roller and a group of metal brushes. Which brush made contact was one axis, and the rotational position of the roller was the other axis. IBM's actions backfired. They ALMOST worked - several competitors almost went under when they could no longer use a brass roller. Bizarre, stupid things were tried, such as 960 plungers in a grid. Then one company (CDC?) succeeded in what had previously been too great an engineering challenge, and came out with an optical reader (12 photocells and a roller). In addition to getting around the IBM patent, they also ended up with a card reader that could be made to run much faster than the fastest that IBM had to offer; thus bringing them back from the brink and into the lead. FIX THAT PUNCH! I have never had that problem with a properly aligned 029. But they DO need to be aligned and adjusted occasionally. -- Grumpy Ol' Fred cisin(a)xenosoft.com

I think (i dont have the book handy) that in "A few good men from Univac" the author discusses some of the CDC card reader history. Can someone who has a copy hand verify this? -Lawrence LeMay

On Fri, 6 Jul 2001, John Honniball wrote: Hmmmm. While not explicitly wanting to cast doubt on the credibility of the book, ... Can anyone here confirm whether the book got those particular facts right? From personal experience! NOT from some other book that got its "facts" from this one! 1) At that time, automobile headlights were big, bulky, and inefficient. Halogen bulbs were readily available, (for example, had come out for home movie lighting), but were NOT available YET as automotive headlights. Halogen automotive headlights became available later, but weren't legal for several more decades. The automobile headlight was WAY too big to be practical for that purpose, and the card reader would not have any need for that much light. On the other hand, that was right when automobile TAILlight bulbs reached their all time peak popularity for other uses, such as the "Tensor" or "high intensity" domestic reading light that consisted of a taillight bulb and a transformer. THAT would be a VERY useful size for building into such equipment. I USED TO have a chunk of surplus optics from a card reader (no idea what make) that appeared to be based on a small light source. (such as a halogen movie light bulb, or a TAILlight bulb) 2) Except for voting in Florida, would you want a card that failed to read consistently to be REMOVED FROM SEQUENCE in the deck???!? Having the computer produce an appropriate error message, and maybe even the offset handle it. In a purely data file, where the quantity of data doesn't much matter, it could be OK. But there are too many situations where you would NOT want to continue with the processing of the file if there are corrupted records, and users would be IRATE to have the corrupted records taken out of sequence! ("Hmmmm. Where in the program did this damaged 'N = N + 1' belong?") -- Grumpy Ol' Fred cisin(a)xenosoft.com

On Fri, 6 Jul 2001, Tony Duell wrote: Yes, indeed. Two peoples separated by a common language. In the US, "headlamp bulb" MEANS "sealed beam". The US mandated sealed beams. At the time, it was as hard to get a non-sealed beam headlamp as it was to find an acetylene lamp (which would be as likely to be what was referred to when saying "headlamp".) Once found, a non-sealed beam bulb would be a fine choice for such a device. BTW, relatively recently non-sealed beam halogen units became legal, finally. In the US, in typical sloppiness of language, the automotive parts industry lumps together under the heading "taillight": brake light, turn signal, backup light, and RUNNING light (which is what y'all more accurately call "taillight".) Even the FRONT turn signal bulbs are grouped as "taillights". -- Grumpy Ol' Fred cisin(a)xenosoft.com

A non-text attachment was scrubbed... Name: not available Type: text Size: 1845 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010707/94da4be9/at…

I actually dusted the thing off and tried it out for probably the first time in 5 years. After figuring out how to get going (there are still 5+ knobs that I still don't know the function of) and cranking out some more ozone, here's the resullts. Oh, its about 11" cubed and 40~50 lbs dense. Needs more space for its carriage to move around. One place division seems to take about 0.8 seconds and there are ten places, so it may be possible that No division will take more than 8~9 seconds, with a properly tuned machine. If you want, you can set the division place "pointer" just one digit to the left irregardless of the numbers involved and it will "count up". THIS takes much longer (EG 1 minute for a result of 400) since it has to count all the way up the hill instead of counting up each "step" and then stepping to the next digit. (example 345 is 29X that of 3+4+5 in terms of time involved). I could guess that if someone didn't want to beat his machine up quite so much he might use the slow method. Mine in its semi-maintained state will only give 100% correct answers with the slow method. Ouch. My hunch is that duoquinary or whatever was set up to make computer math more palateable for non mathematicians (first C.S. degree = 1966? @UNC) and therefore more customers. I would be not at all surprised if the implementation was just 6 bits per digit (1,2,3,4,5,shift), it is only 80% added waste over pure binary and required less effort for people to work with. IBM was probably worried that its users were base 10 bigots and base 8 wouldn't be as popular. Hunch. I had some conversations with a 6xx user at G.E.20 years ago in case anyone wonders why the interest. John A.

Jerome Fine wrote, regarding the Friden mechanical calculators: A little historical elaboration. First, Friden (it doesn't have an extra 'e' in it) began making mechanical calculators as early as 1934, when the company was founded by Carl Friden. These machines required human intervention to divide. Later, in the 1940's, Friden came out with machines that were electro-mechanical and capable of automatic division. These machines proved very popular. One of the most common fully-automatic four function electromechanical calculators made by Friden was the Friden STW (see http://www.geocities.com/oldcalculators/fridenstw.html). These machines were made between 1949 and 1966. The peak of electro-mechanical technology was the Friden SRW and SRQ machines. The SRW could perform the standard four math functions, along with automatic square root. The SRQ could perform the same operations as the SRW, along with automatic, single-entry squaring. These machines were marketed in the 50's and 60's. The first electronic *desktop* calculator, using miniature Thyratron tubes (see http://www.geocities.com/anitaC-VIII.html), the Sumlock Comptometer Anita Mk 8, was introduced in 1961. In '63, Friden introduced the first all-transistor electronic *desktop* calculator, the Friden 130 (see http://www.geocities.com/oldcalculators/friden130.html). These machines were nearly the same size and weight as their electro-mechanical predecessors, *but*, they were quiet, and much faster. (Imagine the noise created in a large room full of electro-mechanical Friden calculators all running at once! -- such instances were quite common in insurance [calculating actuarial tables] and government/military [projectile trajectory work] during the 1940's). By 1966 to 1968, the trend was very clear...electronic desktop calculators were taking over. But, the machines were still rather large, heavy, and expensive [examples: Sharp Compet 20 (http://www.geocities.com/oldcalculators/comp20.html) and Wang LOCI-2 (http://www.geocities.com/oldcalculators/wangloci)]. Makers of the mechanical works of art such as Monroe, Marchant, and others (Olivetti, Olympia, etc.) had to deeply discount their mechanical machines because the electronic machines, while still more expensive, simply had advantages that made up for their higher price. These mechanical calculaor makers also had to scramble to attain expertise in design and manufacture of electronic machines, by either home-growing it (as with Friden, Olympia, Olivetti), starting out in electronic calculating from the get-go (Wang, Hewlett Packard), or finding someone else (generally in Japan) to help them (Monroe with Canon, Singer with Hitachi, and Burroughs with Sharp). As the '60s wound down, desktop electronic calculators shrunk in size and price, using small and medium-scale integrated circuits [examples being the Brother Calther 412 (http://www.geocities.com/oldcalculators/calther412), and Sharp Compet 16 (http://www.geocities.com/oldcalculators/comp16.html)]. By 1968, electronic circuitry had come to the point where sophisticated scientific desktop electronic calculators were possible, with machines like the Hewlett Packard 9100B (http://www.geocities.com/oldcalculators/hp9100b.html) and Wang 300-series (http://www.geocities.com/oldcalculators/wang360.html). Desktop calculators continued to advance, with HP's later 9800-series machines (http://www.geocities.com/oldcalculators/hp9810a.html) and Wang's 700-series machines (http://www.geocities.com/oldcalculators/wang720.html) blurring the line between the then-popular mini-computers such as the Digital Equipment PDP-8, and the Hewlett Packard 2100) and calculator. In the late 1960's, the advent of Large Scale Integration came into play, and the first 'portable' electronic calculators (though a far cry from 'pocket' calculators) were becoming available...machines such as the Sharp ELSI-8 (http://www.geocities.com/oldcalculators/sharpel-8.html), the Canon Pocketronic (http://www.geocities.com/oldcalculators/pocketronic.html), and others. The first truly 'pocket' calculator came to market in late 1971, made by Bowmar (using a single-chip calculator LSI made by Texas Instruments). So, as you can see, there was quite a lapse of time from when Friden introduced it's first mechanical calculators in 1934, and the time of the first 'pocket' calculator. Even if you consider the 'fully automatic' four function electro-mechanical Friden calculators (which came about in the early 1940's), to the time of the Bowmar pocket calculator, there were still over 30 years of time that progressed between these developments. As we all know, with technology advancing so quickly (even back then), 30 years seems an eternity. You can see more information about a lot of different calculators at my museum at http://www.geocities.com/oldcalculators Sure wish I could find one of those old IBM 604's, or a Casio 14-A relay calculator, as these machines were truly the 'mainframe' predecessor to the early desktop electronic calculators. Rick Bensene The Old Calculator Web Museum

A non-text attachment was scrubbed... Name: not available Type: text Size: 1409 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/20010704/58a453bc/at…