return to main page
Table of Contents
mainly the Honeywell 200 with Liberator software
- First threat, I/O concurrent with computing
- Second big threat, the Honeywell 200 with Liberator software
- Using Liberator by Edward Terry, received June 7, 2012
- More Liberator from visit by Edward Terry, June 27, 2012
- IBM 1401 Software to fight the Honeywell 200
- Van Snyder Comments
- Don't knock the Honeywell 200
- LaFarr Responds
- Honeywell 200 via the 800
Starting in 1924, and over the next 30 years, T. J. Watson had positioned IBM as the dominate force in "unit record" accounting, punched cards, ... .
Around 1950, the new UNIVAC had made inroads to major IBM customers, and T. J. Watson Jr. was stressing T. J. Watson Sr. about getting into the new field of electronic data processing, using vacuum tube based computers.
By 1955, IBM had largely replaced Remington Rand UNIVAC as the principle producer of computers,
- and magnetic core memory was successfully introduced,
- and transistors were beginning to be inexpensive and reliable enough to replace vacuum tubes.
A Survey of Domestic Electronic Digital Computing Systems BALLISTIC RESEARCH LABORATORIES - REPORT NO. 971 - DECEMBER 1955 documents the Unites States computing world at that time.
IBM's T.J.Watson Jr. issued a directive that after June 1, 1958 all further IBM computer designs would use transistors exclusively.
In 1958 the IBM 1401 was announced and deliveries of this early all transistor machine (with one vacuum tube used in card punch timing alignment amplifier) began.
The IBM 1401 sold very well by any standard in the business computer market place.
(The machine could not compete with anyone in the scientific computer business.)
Over about 8 years of availability (until replaced by the low end of the IBM 360 family) a total of about 13 thousand were in customer hands - making it an early or maybe the first "mass produced" computer.
Many other companies were eager to get into the computer business
"A Third Survey of Domestic Electronic Digital Computing Systems" Report No. 1115, March 1961 - by Martin H. Weik,
- including middle management of General Electric - in the face of a directive by GE CEO Ralph Cordiner, who did not want to compete with, nor antagonize, IBM. That is another story altogether. :-|
First threat, I/O (Input Output ) concurrent with computing
The original 1401 was limited to doing one thing at a time.
Either compute, or read a card, or punch a card, or print, or a magnetic tape operation. Sinple, low cost, easy to understand. However, this serial, one thing at a time, restricted system throughput. - If two or more operations could be done at the same time, more work could be accomplished per second. The 1401 was at a disadvantage relative to competitive systems being introduced.
Soon IBM offered the Print Buffer option which could speed printer limited jobs. The 1401 program would put the data for a print line into the printer part of memory (201 to 332) then issue a print command as normal. With the Print Buffer option, the contents of memory (201 to 332) would be quickly copied to a separate magnetic core print buffer and the printer started. While printing was taking place, the computer was released to do more work, including probably placing another print line into memory (201 to 332). This parallel activity increased the throughput of the system - up to almost 100%. An advantage of the extra hardware was that no programming changes were required - add the option, and presto - many jobs ran faster :-))
Other manufacturers were introducing computing systems with fully buffered I/O which can give significant performance advantage with little extra cost. The general plan was to enable the programmer to fill an area of memory to say print one line, issue a print command to print from that area in memory, then while that line is being printed, start filling another area in memory with the data for the next line. To make life simple, the programmer often used two areas in memory for each peripheral. - The technique was called double buffering. Compilers usually had an option to specify double buffering.
The above technique requires that the I/O command also specifies the starting memory location for the data.
However, 1401 had fixed memory I/O areas. For instance if you issued a card read command, the data from the card went into memory locations 1 through 80. If you issued a print command, the data to the printer is from 200 to 332 in memory.
IBM's response in the 1401 was to introduce a feature called "Overlap". Many functions are relatively simple to design into a computer, but adding them to an existing system later can be a real pain. 1401s with this feature can be very difficult to trouble shoot. The "Overlap" implementation involved added many complex "wired OR" circuits - and trying to determine the cause of an output from the large wired "OR" is very time consuming a tricky :-((
The one week school that lasted for six by John Van Gardner, linked from here.
Second big threat, the Honeywell 200
Many computer products competed with the IBM 1401. The most successful was the Honeywell 200 (sales brochure), with a conversion product called Liberator, introduced in 1963.
The H-200 had an architecture similar to the IBM 1401 - decimal, character serial, variable data field length, ... which made conversion of existing IBM 1401 programs relatively easy. The Honeywell "Liberator" program (actually two, one for converting source code, the other for converting object decks) helped automate the conversion of existing IBM 1401 programs into H-200 programs. With its faster processor and lower price, and ease of conversion, the H-200 was an immediate success. Many IBM customers were attractrd.
Not all programs could be successfully converted - but enough to cause justified excitement in IBM.
Image information - Datamation Aug 1965 image from Dag Spicer
1 page ad
Using Liberator by Edward Terry, < ed-terry at sbcglobal dot net > received June 7, 2012
I welcome the opportunity of visiting your site and expressing my thoughts and recollections of my career in data processing. It spanned 43 years from January, 1955 through October, 1997, and I enjoyed every minute of it including the 30 months of being with Honeywell. I have a strong feeling of nostalgia when I think of the events that I participated in. I miss those days.
After thinking about it for a while I recalled the basic procedure that I followed in converting (i.e. “Liberating”) an IBM 1401 program to a H-200 program. I worked with object code only, even though I required a 1401 program listing of the source code. I also required test data and results, be it a punched deck of cards or a printout of a listing, report, etc. The proof of proper conversion was comparing the output of the 1401 to the output of the H-200. Most of the time they were the same, and was considered a successful “Liberation”. If not, then I had to analyze the program logic in more detail, sometimes coding new subroutines either at the front end (i.e. 1401) or patch the H-200 object deck. The 1401 program listing was the starting point of conversion. It showed the logic the programmer was using and then I could adapt to it with my own logic when required. This was done patching the 1401 object deck before conversion.
After analyzing and patching the 1401 object deck (when required) I then proceeded with the actual conversion. I recall the H-200 liberation program was a two part object deck. You put the 1401 object deck in the middle of the H-200 liberator object deck, therefore it was a two pass operation. I never analyzed the liberator coding (the source code wasn‘t available), but had faith that it worked just fine. And, indeed, it did. The liberator group didn’t want anyone messing with their code (probably a good thing).
I worked on two accounts: Singer Sewing Machine Company (about 400 programs) and Fredan Calculator Company (I forget how many). Both were card systems only (no tape) that made it much easier to convert. The guys that converted tape systems had a much harder time than I did. I fondly recall things that happened during this part of my career in data processing and look forward to relating when my sons and I visit you on the 27th of this month. With warm regards.
More Liberator from visit by Edward Terry, June 27, 2012
Edward had some 45 years of data processing, from wiring up control boards for the IBM 407 Accounting machine through comverting them to IBM 1401 code, through adapting IBM 1401 programs to run on the Honeywell 200 series ... through system analyst supporting the State of California.
Edward Terry and some of his family came to CHM for a visit and informal recording of his adventures, Apparently a good time was had by all, and Edward promised to come back for more discussions about his Liberator experiences.
Photo by Robert Garner
This section focuses on his efforts to support Honeywell competing against the IBM 1401 :-))
Edward Terry was more involved with adapting "tricky" parts of 1401 code - such as address modification - and did not know the internals of Liberator.
There are three main theories of the internals of Liberator:
- Translation of IBM 1401 object code into equivalent Honeywell H-200 series code. The term "port a program" or "translator" would fit here.
- Executing IBM 1401 object code with a 1401 emulator on the Honeywell H-200. The implication is that each instruction and address field and data field is emulated by another program in the somewhat faster H-200.
- Converting IBM 1401 object code to a "bit code" such as an implementation of UCSD Pascal later (or "tokons") and executing the "bit code" (or "tokons") with software in the Honeywell H-200
I think options 2 and 3 are impractical given the circuit amd memory costs and speeds of the era. The H-200 was advertised to save you money - not offer a ten times larger memory and circuits at least 20 times faster.
Not that published documents don't make major blunders ;-)) but he following indicate "translator":
- "Milestones in Computer Science and Information Technology" page 122, contains the following passage
"In 1963, Honeywell capitalized on the success of the IBM 1400 series by making the compatible but faster H-200 series. Existing 1400 softwar was ported to the H-200 series by a program called the "Liberator," a name that Honeywell found amusing but, not surprisingly, IBM did not."
- "A Brief History of Microprogramming" by Mark Smotherman at http://www.cs.clemson.edu/~mark/uprog.html contains
"Initial studies of the simulators, however, indicated that, at best, performance would suffer by factors ranging from ten to two [Pug91]. Competitors were meanwhile seeking to attract IBM customers by providing less intensive conversion efforts using more compatible hardware and automatic conversion tools, like the Honeywell "Liberator" program that accepted IBM 1401 programs and converted them into programs for the 1401-like Honeywell H-200."
- newspaper article
- from "COBOL orientation for management",
"For those firms changing from 1400 series equipment, Honeywell's Liberator technique overcomes this problem by providing direct, one-time conversion of existing programs into vully compatible Series 200 programs.
HONEYWELL 200 - SUMMARY DESCRIPTION, from Bitsavers, page 14, shows a reader/punch that looks similar to an IBM 1402 reader/punch. The text says there are four pockets, two for the punch, two for the reader. the IBM 1402 has a fifth pocket which can merge punched and read cards - apparently little used ??
Looks as though Honeywell provided a reader/punch with closely similar user characteristics to the IBM 1402.
IBM 1401 Software to fight the Honeywell 200 Milton.Nancy at verizon.net wrote
My IBM Captivator software stymied Honeywell 200 Liberator conversions of IBM programs. It was a card box full of subroutines that could be used by Autocoder programmers for many functions. Honeywell's Liberator software could not handle these subroutines. Thus, a number of IBM 1401s stayed on rent in the face of H-200 competition.
Received June 2012
Ed Czerksie's ShowBox of macros did a lot of manipulating the registers that the Liberator could not compile.
The users could have removed his macros from their programs but that was too labor intensive to bother with. And they may not have had an Autocoder trained people to do the rework.
[I asked if Honeywell appeared to have upgraded Liberator in the face of IBMs move to complicate the source code.]
I only knew of one version of the Liberator.
Van Snyder Comments
I found my H-200 programming manual, Honeywell document DSI-214A (H-200 only, not 200-1200-2200). Can be found here - 21 Megabyte .pdf file
In three-character (18-bit) addressing mode, the low-order 15 bits are the address, and the high-order three bits are index register designators. Zero means no indexing, seven means indirect. There was also a two-character (12-bit) addressing mode, without indexing, and a four-character (24-bit) addressing mode with 15 or 30 index registers (models 201-1 and 201-2 only). The address format was entirely different from the 1401 address format, so it was impossible to run 1401 "binaries."
In addition to Easytran (Honeywell's Autocoder-to-Easycoder converter) there was a "bridge" library to simulate infrequently-used 1401 instructions that didn't have direct H-200 counterparts. These were entered by putting the processor in "trap" addressing mode. In this mode, if an instruction begins with a character having both a word mark and an item mark, it is executed as a "change sequence mode" instruction, which exchanges the program counter and the sequence register. The trap handler than interprets the instruction. I don't know which 1401 instructions were handled in this way.
I suspect the processor on the H-200 where I worked was a model 201, not 201-1 or 201-2, with less than 32k memory, because I never heard of four-character addressing mode, or 15 index registers.
Don't knock the Honeywell 200
e-mail to LaFarr Stuart from Rob Sanders May 16, 2010
Subject: Don't knock the Honeywell 200
I was searching the internet for information about the Honeywell 200 and decided to change tack and try looking up the opposition, the IBM 1401. This led me to your website [and 1401]. Thanks for the interesting webpage on that subject, but don't be so hard on the H200. Let me introduce myself.
I live in Kent in England and have just turned 65 and between 1966 and 1969 I was a programmer on a Honeywell 200. It was the first computer that our company owned and the first one that I ever programmed. The assembler language was called Easycoder and that was a good description as it was incredibly easy for even a beginner like me to use. It is said that Honeywell did nothing original with the H200 as their primary target was the IBM 1401 market but whatever the origins of the design the H200 was a great machine in its own right. Of course, to beat the speed of the 1401 they had to push the hardware to the limit and that could cause problems. In particular the control registers, which were magnetic core memory, ran at four times the speed of normal core memory and could overheat if the room was a little too warm. We had a fully air-conditioned computer room but our computer's control memory actually burned out once and had to be replaced.
It appears that the 1401 architecture only had one punctuation bit, the word mark, whereas the H200 had two. The second bit, the item mark, was used to flag particular 1401 operation codes which had to be emulated by software routines, but of course we were a pure Honeywell site and didn't use it for that. Used in conjunction with the word mark it allowed us to define three level data structures in memory which could be intelligently manipulated by the machine code itself. That made the machine language as powerful as COBOL on a small scale.
I didn't understand your comments about difficulties with binary addresses on the H200. The H200 was equally capable of both binary and decimal arithmetic and we were quite used to using both within the same program. In those days we had our unique sterling currency, pounds shillings and pence, with twelve pence to the shilling and twenty shillings to the pound. It wasn't possible to do direct arithmetic with that currency so we converted all sterling amounts to pence as soon as they were read from a punched card and converted them back on output. It was just as easy to convert to binary pence and the binary calculations went faster than BCD ones, so we would often use binary arithmetic even though we were doing simple financial calculations. By 1968 I was using our original H200 with only 4k of memory to carry out twenty year projections of corporate pension funds. As the computer had only been bought to replace our old tabulating machinery, that was well beyond management's expectations.
I can relate to your comments about finding out what the undefined operations actually did. I also checked on the results of BCD arithmetic on non-BCD values and found practical uses for my discoveries. I also experimented with BCD arithmetic using overlapping fields, which was flagged as completely unpredictable in the instruction manual. This resulted in some very fast and compact but apparently meaningless arithmetic functions in some of my programs carrying out critical corporate tasks. One really had to squeeze every last ounce of processing power out of those early computers.
I can also relate to the practicality of variable word boundaries. Just for fun we wrote a very short program to keep doubling a number until it filled the whole of memory and then print it out. I have no precise idea exactly what power of two that four thousand digit number was now. In later years we moved to single-address register-based computers and it was just as well we had high level programming languages to shield us from the horrible code generated.
My main hobby has always been electronics and I have supported this very cheaply by acquiring old electronic office equipment from my company over the years. As a consequence I now still have over a thousand circuit boards from Honeywell equipment dated around 1969. Wondering what to do with them recently, I realised that I probably have enough to build a fair replica of a Honeywell 200! Therefore I am seriously researching the subject at present. Despite scouring the internet I can find no evidence that any H200 actually survived. I only have enough core memory for 2k bytes, so I will have to brush up my old programming skills, but 2k is plenty for us old hands and that was the basic size of the H200 originally marketed. I have tracked down some documentation to help me but I am surprised that there is so little on the internet about the H200, considering that it frightened IBM so much that they rushed into marketing the 360 earlier than planned.
LaFarr Responds to Rob Sanders - May 17, 2010
As you might have deduce from my web page about the 1401, I have no hands on experience with the Honeywell 200. However, I worked for RCA from 1963 through 1968 at their home office for data processing in Cherry Hill, New Jersey. While there I did run lots of test 1401 programs of potential customers through our 1401 emulators and simulators. At least one had been to Honeywell before they came to us, and our emulator stopped on a multi-punched Honeywell 200 control card in their deck. I saw the rounded corner card (At RCA we never used the newer round corner cards because our stupid card reader couldn't handle them!) so I pulled the round corner card from the output hopper and said to the customer, "It doesn't like that card". The potential customer seemed embarrassed an recognized it as a Honeywell control card. Fortunately, it messed up his stop watch timing and we went on--I suspect the H-200 would have been faster. I know Honeywell had a very fast sort. That is the sum of my H-200 experience, but I did have an instruction manual which I looked over.
I am delighted to get your email--even if it took my somewhat uncomplimentary remark to prompt you to write. You are the only one I know who has Honeywell 200 experience.
You might remember Honeywell had an advertising campaign featuring photos of sculptures made from electrical components. The museum has several of the originals on display, in display cases.
I have quite a lot of respect for Honeywell's early computer efforts. I believe they originated the vacuum column buffering for tape drives, they pioneered using limited flexing of metal which doesn't require lubrication and has a long life--? I think they made a card reader using a lot of that technology?
When I reviewed my 1401 page I noticed I didn't mention what I believe was a major factor in the 1401 success: It had great peripherals. Their chain line printer was unequaled, their card reader-punce with it's 5 pocket output and 3000 card input hopper was outstanding. And their tape drives were lots better than anything we had at RCA.
I will stop for now, but there is lots we could discuss.
Honeywell 200 via the 800 from Stan Paddock, May 18, 2010
Between 1969 and 1975 I worked for Honeywell. I have used the Honeywell 200, 1200 and 2000.
Honeywell also had a Honeywell 800. This machine had a split personality. It could be compatible with the 200 series byte orientated or a word machine. The tapes were the size of a Volkswagen wheel with three inch tapes. No inter-record gap. Fixed pre-formatted size records. Wrote on the odd records on the way out and the even blocks on the way back. Weird.
Ten years after the 1401, IBM had clearly won the battle for business data processing. Twenty years later, niche markets of note were low and high end scientific (DEC and CDC), and timesharing. IBM could afford to be a little arrogant ;-)) - this was their decade - Then the current cheap microprocessor, semi-conductor memory and reliable hard drives allowed "rest of us" to own computers. from August 1978 Datamation page 44, courtesy Dag Spicer
return to main page