1401-S, 1470 "last gasp" computers?
hanc...@bbs.cpcn.com
When IBM was planning its System/360, it had to offer
customers something to kill time until the S/360 would
be ready some years down the road.
The 1401 people were fiercely protective of their system.
Consequently, there was talk of:
1) A "1470" machine.
2) A "1401-S" machine.
One aspect that upset other IBMers was the proposed
use of SLT chips for the 1401 to extend their usefulness.
They were afraid this would be compete with the unity
concepted of S/360. In the end, the head guy, John
Haastra, was reassigned elsewhere.
Anyway, would anyone know how far along design and prototype
construction went of these machines? Were any prototype
models built? Was any literature prepared for release upon
announcement? Are there any illustrations or photographs?
Thanks.
Tim Shoppa
> use of SLT chips for the 1401 to extend their usefulness.
> They were afraid this would be compete with the unity
> concepted of S/360.
Yet they were used quite succesfully in the 1130 (which was a very
clever mix of technologies). Any record of protests from the S/360
camp?
Tim.
hanc...@bbs.cpcn.com
I think the differences were that the 1401-S and 1470
would've been direct competition to S/360 models 30 and 40
which they didn't want. They wanted the 14xx users to dump
those machines and get S/360. Once they figured out they
could use microcode for efficient emulation, there was no
reason to retain 14xx. (Many people retained emulation for
YEARS, I wonder if any still run or the last run. We dumped
our last around 1992).
IIRC, the Pugh book mentions the 1130 only in passing
and doesn't provide much detail. (IBM's website has an
exhibit right now on the 1130, BTW).
In a sense, it seems the 1130 was kind of S/360-model 20
for scientific users, but totally not compatible. Perhaps
being a scientific machine it was more "under the radar"
than if a business machine.
I also don't understand is how anynoe found time to develop
software and hardware for the 1130 in those days. The
impression was that S/360 was killing everyone in IBM--
they had trouble making the SLT chips pushing deliveries
behind and the software was a total disaster. They had
problems supporting existing "temporizing" products to tide
people over because people were pulled over to S/360.
Tim Shoppa
> develop software and hardware for the 1130 in
> those days.
My interpretation is that the 1130 system was largely built from
existing technologies/peripherals/parts which were cleverly tacked
together. The use of SLT in the CPU is the notable exception, in that
it was a use of a bleeding-edge technology that may have been in scarce
supply and direct competition with the simultaneous "Big Bang" of the
360.
If IBM was being clever they would've made the 1130 be a testbed for
SLT development/manufacture/integration, but everything I've ever read
about the 360 mindset at the time would've made this impossible.
Tim.
Jim Haynes
was also an odd little machine, low-end scientific computer with of
all things variable word length. And then it also appeared as the 1800
for process control work. Maybe that makes it a forerunner of the
Series/1
--
jhhaynes at earthlink dot net
Anne & Lynn Wheeler
> My understanding is that the 1130 was a replacement for the 1620,
> which was also an odd little machine, low-end scientific computer
> with of all things variable word length. And then it also appeared
> as the 1800 for process control work. Maybe that makes it a
> forerunner of the Series/1
the person at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
that did the internal network software architecture, design,
and implementation
http://www.garlic.com/~lynn/subtopic.html#internalnet
had done an early implementation supporting communication between the
center's 1130 (with attached 2250, aka 2250-4) and 360/67.
there was a later project that involved using a system/7 as
a communication interface for the 360/67 ... a couple system/7
references from search engine:
http://www.ibm1130.net/functional/System7.html
http://domino.research.ibm.com/tchjr/journalindex.nsf/0/4ef2fdb289abe52785256bfa006840d8?OpenDocument
http://www.cit.cornell.edu/computer/history/Newman.html
then "peachtree" came into the picture (pre-announce code name for
series/1) and there were several people that were pushing peachtree
for the basis of new mainframe communication controller ... for what
was to be the 3705 (as having a much better design and architecture
than the leading contendor for 3705 at the time).
somewhat totally unrelated ... i had been part of a project as an
undergraduate that created mainframe clone controller started out
using an interdata/3.
http://www.garlic.com/~lynn/subtopic.html#360pcm
there was a project in the 80s that did implement a 3705 clone
using series/1 ... some past postings:
http://www.garlic.com/~lynn/99.html#63 System/1 ?
http://www.garlic.com/~lynn/99.html#66 System/1 ?
http://www.garlic.com/~lynn/99.html#67 System/1 ?
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#70 Series/1 as NCP (was: Re: System/1 ?)
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Alan Balmer
wrote:
>My understanding is that the 1130 was a replacement for the 1620, which
>was also an odd little machine, low-end scientific computer with of
>all things variable word length. And then it also appeared as the 1800
>for process control work. Maybe that makes it a forerunner of the
>Series/1
The 1800 was really the last successful IBM mini for process control.
At Taylor Instrument, we replaced a number of them for various clients
when it became difficult to get maintenance. There were other
attempts, but I don't think any of them were used that much. As I
remember, the System 7 had no native development software -
development was to be done on a mainframe. OTOH, my memory may not be
that reliable ;-)
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
David Wade
<hanc...@bbs.cpcn.com> wrote in message
news:1114006801.3...@l41g2000cwc.googlegroups.com...
>
> Tim Shoppa wrote:
> > > One aspect that upset other IBMers was the proposed
> > > use of SLT chips for the 1401 to extend their usefulness.
> > > They were afraid this would be compete with the unity
> > > concepted of S/360.
> >
> > Yet they were used quite succesfully in the 1130 (which was a very
> > clever mix of technologies). Any record of protests from the S/360
> > camp?
>
> I think the differences were that the 1401-S and 1470
> would've been direct competition to S/360 models 30 and 40
> which they didn't want. They wanted the 14xx users to dump
> those machines and get S/360. Once they figured out they
> could use microcode for efficient emulation, there was no
> reason to retain 14xx. (Many people retained emulation for
> YEARS, I wonder if any still run or the last run. We dumped
> our last around 1992).
>
> IIRC, the Pugh book mentions the 1130 only in passing
> and doesn't provide much detail. (IBM's website has an
> exhibit right now on the 1130, BTW).
>
> In a sense, it seems the 1130 was kind of S/360-model 20
> for scientific users, but totally not compatible. Perhaps
> being a scientific machine it was more "under the radar"
> than if a business machine.
The 1130 was a real odd ball. I seem to recall it had crippled Fortran that
was called "IV" but actually had fewer features than Fortran II. Not sure
about the other high level languages. I used one at Newcastle Poly, but it
was almost always used as an RJE workstation onto MTS at Newcastle
University. There was a huge "Tardis" like box which I think was the
controller for the line printer (1403?). It also had a 1622? plotter that
was moved from the predecessor a IBM1620, paper tape punch and reader which
I think was used to produce tapes for NC millingg machine type things. The
University also had an 1130 that was used for all kinds of researc. I don't
think it was too popular, some one who was forced to use it instead of the
360/67 and MTS compose a song (to the tune of clouds) moaning about how
unreliable it was. Ours seemed very good, but it was invariably IPLd from
cards, so the disks were seldom used.
>
> I also don't understand is how anynoe found time to develop
> software and hardware for the 1130 in those days. The
> impression was that S/360 was killing everyone in IBM--
> they had trouble making the SLT chips pushing deliveries
> behind and the software was a total disaster. They had
> problems supporting existing "temporizing" products to tide
> people over because people were pulled over to S/360.
>
Perhaps that is why the Fortran was so basic?
hanc...@bbs.cpcn.com
David Wade wrote:
> The 1130 was a real odd ball. I seem to recall it had crippled
Fortran that
> was called "IV" but actually had fewer features than Fortran II.
I was told it was "Fortran II". I didn't like it since I was used
used to logical IF statements and 1130 Fortran required the older
arithmetic IFs.
The I/O of the machine was incredibly slow. In the past, others
here have discussed the internals somewhat, apparently if you knew
1130 assembler and proper technique you could improve the reading and
printing to fit properly within the assigned cycle.
In hindsight, instead of writing programs to read-calculate-print,
I should've read-stored-calc-print to make better use of the machine
cycles of the printer and card reader.
The big thing about the 1130 was that it was the cheapest machine
IBM had at the time. For teaching high school or college kids Fortran,
or serving the computing needs of a small outfit it had good price/
performance _for its time_. IBM probably continued its educational
discount on it for schools which was to its advantage in those days
(to develop more programmers for industry). Advanced kids could
even learn a little on systems programming playing around with
the internals.
In the 1970s other manufacturers came out with minis that supported
Fortran and line printing. For small businesses, IBM introduced
the System/3, but I don't think IBM did anything more for small
engineering needs or the educational market. At that point (mid
1970s) the mini world (PDP, Nova, HP) took over. The Teletype
ASR 33 became the output printer of choice in those days.
Scott Peterson
>The 1130 was a real odd ball. I seem to recall it had crippled Fortran that
>was called "IV" but actually had fewer features than Fortran II. Not sure
>about the other high level languages. I used one at Newcastle Poly, but it
>was almost always used as an RJE workstation onto MTS at Newcastle
>University.
I encountered two of these. The first was at San Diego City College
ca. 1970 It was used for programming instruction. If I remember
correctly we had Fortran, COBOL and ALGOL on it. The ALGOL was a
problem as all the error messages were in French.
The second was handling some business application at the Kodak photo
development and printing facility in Los Angeles.
Scott Peterson
--
I am still waiting for the advent
of the computer science groupie.
320/611
Rob Warnock
+---------------
| My understanding is that the 1130 was a replacement for the 1620,
| which was also an odd little machine, low-end scientific computer
| with of all things variable word length.
What's so odd about that? The 1401 & 1410 had variable word length, too.
The latter had a hardware floating point option, and the variable word
length made it really easy to tweak the precision of your floating-point
operations up or down, depending on the application. [Folks in EBDPAC
at Emory Univ. used to run *huge* non-linear regressions on a 1410.]
No, the *really* odd thing about the 1620 was that the hardware
addition and multiplication was done by table lookup [though not
address arithmetic] and that the table was loaded into memory at
boot time. A favorite BOFH joke on newbies was to turn the machine
over to them after having "adjusted" one or more of the lookup tables,
and wait to see how long it took before they figured out something
was wrong...
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Nick Spalding
IIRC the first model of it was known as CADET, Can't Add Doesn't Even Try.
--
Nick Spalding
Jim Haynes
console spelled out (in hex) "dead beef"
One of the printers offered with it, the 1132 or something like that,
appeared to be a recycled IBM 704 printer, which in turn was a recycled
407 accounting machine printer.
The card reader/punch was as I recall a fairly troublesome machine. It
read the cards column-by-column rather than row-by-row like the big
machines did; and cards were not designed to be read in that direction.
(Although the non-IBM computer makers like GE and Burroughs made
column-by-column card readers even for their big machines, and they
were fairly troublesome.)
David Dyer-Bennet
> The 1130 was a real odd ball. I seem to recall it had crippled
> Fortran that was called "IV" but actually had fewer features than
> Fortran II. Not sure about the other high level languages. I used
> one at Newcastle Poly, but it was almost always used as an RJE
> workstation onto MTS at Newcastle University. There was a huge
> "Tardis" like box which I think was the controller for the line
> printer (1403?). It also had a 1622? plotter that was moved from the
> predecessor a IBM1620, paper tape punch and reader which I think was
> used to produce tapes for NC millingg machine type things. The
> University also had an 1130 that was used for all kinds of
> researc. I don't think it was too popular, some one who was forced
> to use it instead of the 360/67 and MTS compose a song (to the tune
> of clouds) moaning about how unreliable it was. Ours seemed very
> good, but it was invariably IPLd from cards, so the disks were
> seldom used.
The 1622 was a card reader/punch unit for the IBM 1620. The plotter I
worked with wasn't an IBM product; it was a Calcomp pen plotter with a
homebrew local interface to the paper tape interface of an IBM 1620
(at Carleton College).
There was an 1130 across the river at St. Olaf; I used both while in
highschool in Northfield, 1968-1972. I think I used the 1130 around
1970 a little. But it was far away, and less interesting than the
PDP-8/I that Carleton installed around then (and we got a terminal to
it at the highschool, too).
I don't remember details of 1130 Fortran; but then I was used to NCE
Load-and-go Fortran, and AFIT Improved Fortran, on the 1620, none of
this newfangled relational IF statement nonsense there!
Oh, that TARDIS might have been an LP controller I suppose; the base
1130 hardware had a nearly-all-software LP controller, where it made
visible to the software the current chain position, and a bitmap or
some such structure to fire particular hammers, and let the software
driver figure out how to print the intended characters. Which means
there could quite possibly have been benefits from an add-on
controller to take that load off the software!
--
David Dyer-Bennet, <mailto:dd...@dd-b.net>, <http://www.dd-b.net/dd-b/>
RKBA: <http://noguns-nomoney.com/> <http://www.dd-b.net/carry/>
Pics: <http://dd-b.lighthunters.net/> <http://www.dd-b.net/dd-b/SnapshotAlbum/>
Dragaera/Steven Brust: <http://dragaera.info/>
dr...@timesten.com
major student computer for running Fortran (Fortran II) - but that was
way before I got there in 1977. By then it was sitting in a public
keypunch room and was stll used by a VERY small number of engineering
programing classes.
I did some systems programming on it - upgraded the OS to the last
version, and such. The University had modified the "OS" to do job
accounting - the assembler on it was fun to learn. I always wanted to
figure out how to hook it up to a real-time clock; the thing had no
concept of what time it was, which made the "job accounting" software
sort of pointless.
The machine was unique in my experience in that the card reader / punch
could punch on cards after they were read. So the assembler would read
in a program and then think a while; you then fed in the same deck
again and it would punch the object code onto the same cards that held
the source - with the corresponding object being on the proper source
cards!!
I mostly remember being fascinated by the Fortran II compiler. It was
NOT a speed daemon. If I recall correctly it was a TWENTY-FIVE pass
compiler. (RAM was a bit scarce...8 K words @ 16 bits / word, IIRC.)
Each pass wrote the intermediate form back out to disk, so it took a
LONG time. I distinctly remember reading the manual that described the
compiler - pass 1 removed comments; pass 2 removed spaces from the
program; etc. Woof.
However, it was cool to be able to write programs that actually used
Fortran's "sense light" feature to turn lights on on the console, and
to determine the setting of various toggle switches. Not useful (to
me) but fun.
And the 1130 had a very cool APL implementation that I used a few
times. The console was a Selectric printer; by putting a special APL
"ball" on the typewriter you could directly enter and run APL programs.
To type all of the APL characters there were several different "shift"
modes on the keyboard. To indicate which shift modes were in use the
computer lit up various lights on the console. By loading 0x00FF into
the accumulator while waiting for user input, the right-hand register
lights would light up to indicate the right hand shift key was being
pressed - 0xFF00 for left shift; 0x0000 for no shift, etc.
About a dozen students played with the APL - until someone left the APL
ball on the 1130 console overnight and it was stolen. No more
APL...the special balls cost about $100.
Finally, one day when the university library was throwing away old
books and they discarded a bunch of 360 and 370 books but kept the 1130
books - since 1130 > 370, it was obviously a newer computer. Sigh.
...Sam
Steve O'Hara-Smith
hay...@alumni.uark.edu (Jim Haynes) wrote:
> One fun thing about the 1130 was that when it halted the lights on the
> console spelled out (in hex) "dead beef"
> The card reader/punch was as I recall a fairly troublesome machine. It
Oh it was fine as long as the cards were pristine on the leading
edge, otherwise it just distributed three or four cards all over the
mechanism in small pieces to be removed with the card saw.
The card reader that came with the Eclipse that replaced the
1130 I cut my teeth on was also a column by column model but that one
could read a card after it had been crumpled and roughly flattened before
being put back in the deck. The demonstration provoked awed noises from
all of us who were used to the 1130 :)
Joe Morris
>hay...@alumni.uark.edu (Jim Haynes) wrote:
>> The card reader/punch was as I recall a fairly troublesome machine. It
> Oh it was fine as long as the cards were pristine on the leading
>edge, otherwise it just distributed three or four cards all over the
>mechanism in small pieces to be removed with the card saw.
Then there was the 2520 (?) Multi-Function Card Machine (MFCM, although
much of the user community had its own back-formation of a name, based on
the first two letters of the abbreviation, that IBM didn't appreciate).
> The card reader that came with the Eclipse that replaced the
>1130 I cut my teeth on was also a column by column model but that one
>could read a card after it had been crumpled and roughly flattened before
>being put back in the deck. The demonstration provoked awed noises from
>all of us who were used to the 1130 :)
I can't speak for the Eclipse, but in the mid-60s the CDC salesdroids
could make a good impression by showing that the online high-speed
card reader (serial by column) could read cards that the operators
had used to try to demonstrate a MUNG operation. (MUNG := Mash
Until No Good)
OTOH, I have no fond memories whatever of the card reader (the model
of which I've totally forgotten) that was on our DECSystem-10 box.
It had an MTBF of approximately half of whatever deck you were
trying to read.
Joe Morris
spam-e...@the-shredder.invalid
<jcmo...@mitre.org> wrote:
>Steve O'Hara-Smith <ste...@eircom.net> writes:
>
>>hay...@alumni.uark.edu (Jim Haynes) wrote:
>
>>> The card reader/punch was as I recall a fairly troublesome machine. It
>
>> Oh it was fine as long as the cards were pristine on the leading
>>edge, otherwise it just distributed three or four cards all over the
>>mechanism in small pieces to be removed with the card saw.
>
>Then there was the 2520 (?) Multi-Function Card Machine (MFCM, although
>much of the user community had its own back-formation of a name, based on
>the first two letters of the abbreviation, that IBM didn't appreciate).
2560 malfunction card machine
hanc...@bbs.cpcn.com
d...@timesten.com wrote:
> I did some systems programming on it - upgraded the OS to the last
> version, and such. The University had modified the "OS" to do job
> accounting - the assembler on it was fun to learn. I always wanted
to
> figure out how to hook it up to a real-time clock; the thing had no
> concept of what time it was, which made the "job accounting" software
> sort of pointless.
We had some very bright students in high school who wanted
to go beyond Fortran and experiment with assembler on our 1130.
The school district refused to allow any kind of work beyond
the basics. The kids turned into early hackers, sneaking
stuff into the machine, eventually getting caught and into
serious trouble.
I had mixed feelings about how the whole thing was handled.
On the one hand, I don't approve of hacking and sneaking no
matter how 'harmless' it may be. On the other hand, these
kids were extremely bright and I think the School District
should have made provision for them to do advanced work on
the machine, despite the extra work of supervision and control
of such advanced student projects.
Steve O'Hara-Smith
Joe Morris <jcmo...@mitre.org> wrote:
> Steve O'Hara-Smith <ste...@eircom.net> writes:
> Then there was the 2520 (?) Multi-Function Card Machine (MFCM, although
> much of the user community had its own back-formation of a name, based on
Yes I've heard of the MF Card Muncher.
arargh5...@now.at.arargh.com
<jcmo...@mitre.org> wrote:
<snip>
>Then there was the 2520 (?) Multi-Function Card Machine (MFCM, although
>much of the user community had its own back-formation of a name, based on
>the first two letters of the abbreviation, that IBM didn't appreciate).
I originally heard of that one as "Mother Fletchers Card Mangler". I
didn't hear of the other name until later.
<snip>
--
Arargh504 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html
To reply by email, remove the garbage from the reply address.
Kevin G. Rhoads
>addition and multiplication was done by table lookup
There were two versions, first version needed both add and multiply tables.
By putting appropriate values in these tables, a pseudo-binary octal arithmetic
was possible as well as standard decimal arithmetic the machine was designed for.
The second version still had the multiply table, but the add table was no
longer needed. THe addition was handled faster, but the octal arithmetic
capability was, as a side-effect, eliminated.
David Wade
news:YvZ9e.10645$sp3....@newsread3.news.atl.earthlink.net...
> One fun thing about the 1130 was that when it halted the lights on the
> console spelled out (in hex) "dead beef"
>
> One of the printers offered with it, the 1132 or something like that,
> appeared to be a recycled IBM 704 printer, which in turn was a recycled
> 407 accounting machine printer.
>
> The card reader/punch was as I recall a fairly troublesome machine. It
> read the cards column-by-column rather than row-by-row like the big
> machines did; and cards were not designed to be read in that direction.
I don't think cards were designed to be read in any direction. I seem to
recall that the high speed reader had a "plastic" toggle that caught the
cards to stack them. And if this was "removed" (or not installed) the cards
would shoot out at high speed across the room..
> (Although the non-IBM computer makers like GE and Burroughs made
> column-by-column card readers even for their big machines, and they
> were fairly troublesome.)
Why was this? The Honeywell H3200 we had (Which was I think almost a 1401
"clone" ) read along the card.
Peter Flass
> Mmm...the 1130. [snip]
> The machine was unique in my experience in that the card reader / punch
> could punch on cards after they were read. So the assembler would read
> in a program and then think a while; you then fed in the same deck
> again and it would punch the object code onto the same cards that held
> the source - with the corresponding object being on the proper source
> cards!!
1442. Not too fast, but handy. Actually not that uncommon. The 2540
on 360's had a Punch-Feed-Read feature that did the same thing, and IME
lots of places had 'em. I agree that the 1130 was a neat machine, maybe
still my favorite. See http://ibm1130.org (no "www").
Peter Flass
> We had some very bright students in high school who wanted
> to go beyond Fortran and experiment with assembler on our 1130.
> The school district refused to allow any kind of work beyond
> the basics. The kids turned into early hackers, sneaking
> stuff into the machine, eventually getting caught and into
> serious trouble.
>
> I had mixed feelings about how the whole thing was handled.
>
> On the one hand, I don't approve of hacking and sneaking no
> matter how 'harmless' it may be. On the other hand, these
> kids were extremely bright and I think the School District
> should have made provision for them to do advanced work on
> the machine, despite the extra work of supervision and control
> of such advanced student projects.
>
Especially since the whole system resided on one removable disk, and
there ususlly were no others. Just keep a spare for the assembler
kiddies. Tell them that if they clobbered something, it was up to them
to reload it.
Walter Bushell
Scott Peterson <scottp4.remo...@mindspring.com> wrote:
> "David Wade" <g8...@yahoo.com> wrote:
>
> >The 1130 was a real odd ball. I seem to recall it had crippled Fortran that
> >was called "IV" but actually had fewer features than Fortran II. Not sure
> >about the other high level languages. I used one at Newcastle Poly, but it
> >was almost always used as an RJE workstation onto MTS at Newcastle
> >University.
>
> I encountered two of these. The first was at San Diego City College
> ca. 1970 It was used for programming instruction. If I remember
> correctly we had Fortran, COBOL and ALGOL on it. The ALGOL was a
> problem as all the error messages were in French.
O bother it. Error messages in a foreign language, it's hard enough to
figure them out in my native tongue.
>
> The second was handling some business application at the Kodak photo
> development and printing facility in Los Angeles.
>
> Scott Peterson
>
> --
> I am still waiting for the advent
> of the computer science groupie.
>
> 320/611
--
Guns don't kill people; automobiles kill people.
Walter Bushell
dr...@timesten.com wrote:
<snip>
> I mostly remember being fascinated by the Fortran II compiler. It was
> NOT a speed daemon. If I recall correctly it was a TWENTY-FIVE pass
> compiler. (RAM was a bit scarce...8 K words @ 16 bits / word, IIRC.)
> Each pass wrote the intermediate form back out to disk, so it took a
> LONG time. I distinctly remember reading the manual that described the
> compiler - pass 1 removed comments; pass 2 removed spaces from the
> program; etc. Woof.
Ever use Fortran on three pass system using punched tape?
Jeff Jonas
We had 2 at the Cooper Union,
but after a while I combined the best of both into one
- the CPUs were identical: 16k words (I think: had the extended cabinet)
internal hard drive
- 1442 card reader/punch
- 1132 printer
- 1055 paper tape punch (but no reader: I never got around to modifying
the Tally reader from the LGP-21 to the 1130 since it seemed the same)
- 1627 small drum plotter with all the pens and lotsa semilog paper
- 1131 mux to 2 more single platter drives, disconnected for
- Calcomp 11-platter disk pack (each surface was the equivalent of a single
1130 platter, but only 5 at a time were supported by the monitor.
We didn't have the programs to use all surfaces at once).
I can't remember what monitor version I ran:
I kept finding other versions as I sorted the cartrdiges.
>And the 1130 had a very cool APL implementation that I used a few
>times. The console was a Selectric printer; by putting a special APL
>"ball" on the typewriter you could directly enter and run APL programs.
> To type all of the APL characters there were several different "shift"
>modes on the keyboard. To indicate which shift modes were in use the
>computer lit up various lights on the console. By loading 0x00FF into
>the accumulator while waiting for user input, the right-hand register
>lights would light up to indicate the right hand shift key was being
>pressed - 0xFF00 for left shift; 0x0000 for no shift, etc.
I just found the orange manual for that: it was fun!
I used Fortran for the plotting and engineering work,
and assembler for learning the I/O devices
since I used the panel for
- single instruction
- single memory cycle
- single clock cycle
and followed each instruction with the flowchart clock cycle by clock cycle!
I didn't remember the accumulator/extension used for APL shift,
but the machine was normally halted for I/O with the code in the ACC.
John Savard
part:
quoting someone:
>>And the 1130 had a very cool APL implementation that I used a few
>>times. The console was a Selectric printer; by putting a special APL
>>"ball" on the typewriter you could directly enter and run APL programs.
>> To type all of the APL characters there were several different "shift"
>>modes on the keyboard. To indicate which shift modes were in use the
>>computer lit up various lights on the console. By loading 0x00FF into
>>the accumulator while waiting for user input, the right-hand register
>>lights would light up to indicate the right hand shift key was being
>>pressed - 0xFF00 for left shift; 0x0000 for no shift, etc.
>I just found the orange manual for that: it was fun!
Recently, I saw the manual describing that on Al Kossow's site.
Apparently, the reason for this was that the console typewriter on the
1130 had a keypunch-style keyboard rather than a regular keyboard, so it
did not have enough keys for normal APL operation.
John Savard
http://www.quadibloc.com/index.html
_________________________________________
Usenet Zone Free Binaries Usenet Server
More than 120,000 groups
Unlimited download
http://www.usenetzone.com to open account
Robert Billing
> Recently, I saw the manual describing that on Al Kossow's site.
> Apparently, the reason for this was that the console typewriter on the
> 1130 had a keypunch-style keyboard rather than a regular keyboard, so it
> did not have enough keys for normal APL operation.
Also the keyboard generated card punch patterns, which had to be converted
to R/T code to echo on the typewriter and EBCDIC to pass back to the
calling program.
Peter Flass
That was one of the little quirks of thje 1130. *Almost every*
peripheral used a unique code set that had to be translated when doing
I/O. The library was full of functions for translating card-reader
encoding to printer, console keyboard to card-punch, etc. The routines
could sync themselves with the progress of the I/O and translate codes
on the fly as they were received/transmitted.
John Savard
<uncl...@tnglwood.demon.co.uk> wrote, in part:
>Also the keyboard generated card punch patterns, which had to be converted
>to R/T code to echo on the typewriter and EBCDIC to pass back to the
>calling program.
That explains why this was even *possible*. The 2741 terminal was
relentlessly half-duplex, so passwords were echoed - so timesharing
systems had to print "password masks" over the passwords.
Ah, what a sweet and innocent time that was.
In any event, I have finally commemorated this unique achievement of
IBM's on my web site at
http://www.quadibloc.com/comp/kybint.htm
Joe Morris
>That explains why this was even *possible*. The 2741 terminal was
>relentlessly half-duplex, so passwords were echoed - so timesharing
>systems had to print "password masks" over the passwords.
The term commonly used for this was "mask".
ISTR that the 2741 had an optional feature that was probably extra-cost
(the details of which are long gone from my memory) to suppress
the local copy, allowing you to avoid having to make the application
type the mask prior to soliciting a password.
And there was a special feature available that while not providing
any full-duplex data capability, did allow the ATTN key to be used
to interrupt output. My PPOE was a heavy user of ATS (and I used
it to write my MS thesis; the first computer-printed theses to be
accepted by the Graduate Office), and having that interrupt capability
was a lifesaver.
Joe Morris
Norm Aleks
FORTRAN and APL, at
http://ibm1130.org/sim/downloads
(The APL setup is listed in the "news" column, bottom right, still as a
preview -- works pretty well though.)
Sign in through the guestbook and we'll send you updates when we come
up with them ...
Norm Aleks
Dennis Ritchie
"Joe Morris" <jcmo...@mitre.org> wrote in message news:d5nlg9$ckv$1...@newslocal.mitre.org...
....
> ISTR that the 2741 had an optional feature that was probably extra-cost
> (the details of which are long gone from my memory) to suppress
> the local copy, allowing you to avoid having to make the application
> type the mask prior to soliciting a password.
I remember that too. I think the typeball sort of twitched, without
actually printing. It was used on CTSS and probably Multics.
>
> And there was a special feature available that while not providing
> any full-duplex data capability, did allow the ATTN key to be used
> to interrupt output. My PPOE was a heavy user of ATS (and I used
> it to write my MS thesis; the first computer-printed theses to be
> accepted by the Graduate Office), and having that interrupt capability
> was a lifesaver.
Memory says the required option was "reverse break", but in looking
it up, the docs (more logically) imply that this was used by the remote
end to lock the local keyboard asynchronously. Maybe the option
was required in order to have the local ATTN key unconditionally
send a signal in the face of otherwise unstoppable typing, or maybe
I simply misremember the name.
Dennis
Justa Lurker
>
> That was one of the little quirks of thje 1130. *Almost every*
> peripheral used a unique code set that had to be translated when doing
> I/O. The library was full of functions for translating card-reader
> encoding to printer, console keyboard to card-punch, etc. The routines
> could sync themselves with the progress of the I/O and translate codes
> on the fly as they were received/transmitted.
>
IIRC, there was a library routine called "ZIPCO" which performed
character set conversions.
Also, weren't library functions invoked with the assembler mnemonic
opcode "LIBF" ?
Howard S Shubs
Justa Lurker <Justa...@att.net> wrote:
> IIRC, there was a library routine called "ZIPCO" which performed
> character set conversions.
See <http://www.ibm1130.net/functional/AppendixA.html> for the codes
themselves.
--
Though I've tried, I've fallen... / I have sunk so low
I have messed up / Better I should know
Peter Flass
I think there were both "CALL" and "LIBF", some were one, some another.
I'll have to go back and reread the manuals sometine, but I think the
"LIBF" routines were called via a transfer vector, and the "CALL"
routines were called directly.
Anne & Lynn Wheeler
Joe Morris <jcmo...@mitre.org> writes:
> The term commonly used for this was "mask".
>
> ISTR that the 2741 had an optional feature that was probably extra-cost
> (the details of which are long gone from my memory) to suppress
> the local copy, allowing you to avoid having to make the application
> type the mask prior to soliciting a password.
>
> And there was a special feature available that while not providing
> any full-duplex data capability, did allow the ATTN key to be used
> to interrupt output. My PPOE was a heavy user of ATS (and I used
> it to write my MS thesis; the first computer-printed theses to be
> accepted by the Graduate Office), and having that interrupt capability
> was a lifesaver.
dug out users guide ... there was some manual that actually gave the
feature codes ... but can't find it at the moment.
pg. 17:
2741 CHARACTERISTICS
The IBM 2741 Communication Terminal consists of an IBM Selectric
typewriter mounted on a typerwriter stand. The stand includes the
electronic controls needed for communications, a cabinet for mounting
a data-phone, a rack for mounting a roll of paper, and a working
surface. For use with the CP/CMS system, the 2741 should be equipped
with the *Transmit Interrupt* and the *Receive Interrupt* features.
...
pg. 29:
7. Type your password, followed by a carriage return; the password may
be edited. If the 2741 is equipped with the *Print Inhibit* feature, the
password is not typed at the terminal as the keys are hit. The Print
Inhibit feature applies only to the typing of a password. If the
terminal is a Teletype 33 or 35, three lines of characters are
overprinted before you are allowed to enter your password.
...
--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Dennis Ritchie
"Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message news:m3acmwg...@lhwlinux.garlic.com...
.....
> 2741 CHARACTERISTICS
>
> The IBM 2741 Communication Terminal consists of an IBM Selectric
> typewriter mounted on a typerwriter stand. The stand includes the
> electronic controls needed for communications, a cabinet for mounting
> a data-phone, a rack for mounting a roll of paper, and a working
> surface. For use with the CP/CMS system, the 2741 should be equipped
> with the *Transmit Interrupt* and the *Receive Interrupt* features.
This seems to pin the features down satisfactorily.
...
> 7. Type your password, followed by a carriage return; the password may
> be edited. If the 2741 is equipped with the *Print Inhibit* feature, the
> password is not typed at the terminal as the keys are hit. The Print
> Inhibit feature applies only to the typing of a password. If the
> terminal is a Teletype 33 or 35, three lines of characters are
> overprinted before you are allowed to enter your password.
Likewise this. I'm pretty sure that full-duplex (no local echo) on the
TTY 33 and 35 was configurable, but not remotely;
the 37 could be set remotely.
Dennis
Tom Van Vleck
> "Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
> >
> > The IBM 2741 Communication Terminal consists of an IBM Selectric
> > typewriter mounted on a typerwriter stand. The stand includes the
> > electronic controls needed for communications, a cabinet for mounting
> > a data-phone, a rack for mounting a roll of paper, and a working
> > surface. For use with the CP/CMS system, the 2741 should be equipped
> > with the *Transmit Interrupt* and the *Receive Interrupt* features.
>
> This seems to pin the features down satisfactorily.
I have never seen a roll-fed 2741. The ones we used at MIT
on CTSS, Multics, and CP/CMS in the mid to late 60s used
fan-fold paper with either tractor feed or friction feed.
(Annoyingly, the paper was just a little narrower than
regular printer paper, 14 inches instead of 14 7/8, and
more than once I lugged a box home for my home terminal and
discovered I had the wrong size.) Furthermore, our 2741s
did not have a work surface: the furniture the print
mechanism was built into had about 3 inches on each side of
the typewriter. 1050s came with a kind of desk on the
right side of the typer, and some third-party terminals
with the 2741 mechanism also provided a work surface.
> > 7. Type your password, followed by a carriage return; the password may
> > be edited. If the 2741 is equipped with the *Print Inhibit* feature, the
> > password is not typed at the terminal as the keys are hit. The Print
> > Inhibit feature applies only to the typing of a password. If the
> > terminal is a Teletype 33 or 35, three lines of characters are
> > overprinted before you are allowed to enter your password.
>
> Likewise this. I'm pretty sure that full-duplex (no local echo) on the
> TTY 33 and 35 was configurable, but not remotely;
> the 37 could be set remotely.
My memory is otherwise. I believe that printing could be
inhibited remotely on the TTY35s and TTY37s we used at MIT
by sending the PRINTER OFF code, sometimes called PRINT
BYPASS. This was configurable for TTY35s and not all had
it. I remember having to write the code that printed the
"password mask" for terminals without the feature, I think
in the late 60s to support 2741s without the print inhibit
feature. I recall that in Multics we sent PRINTER OFF and
then the mask, so that if you had the feature, a TTY35
would do three lines of air typing after "Password:".
About 1965, CTSS only talked to TTY35s that had a specific
answerback code, something like "MIT xxx xxx," and in those
days that was taken as a guarantee that the M35 had the
"MIT standard" set of options. Multics accepted any
answerback and supported more device options as time went
on.
Joe Morris
>Likewise this. I'm pretty sure that full-duplex (no local echo) on the
>TTY 33 and 35 was configurable, but not remotely;
Operator selection, IIRC. For boxes provisioned with a Dataphone 109
it would have been one of the keys; for non-109 installations you turned
the power switch one way to have local copy and the other for full duplex.
Or it may have been a jumper; it's been 20+ years since I've touched
a TTY33 and mental bitrot has been at work all that time.
Joe Morris
K Williams
th...@multicians.org says...
> "Dennis Ritchie" <d...@bell-labs.com> wrote:
> > "Anne & Lynn Wheeler" <ly...@garlic.com> wrote in message
> > > 2741 CHARACTERISTICS
> > >
> > > The IBM 2741 Communication Terminal consists of an IBM Selectric
> > > typewriter mounted on a typerwriter stand. The stand includes the
> > > electronic controls needed for communications, a cabinet for mounting
> > > a data-phone, a rack for mounting a roll of paper, and a working
> > > surface. For use with the CP/CMS system, the 2741 should be equipped
> > > with the *Transmit Interrupt* and the *Receive Interrupt* features.
> >
> > This seems to pin the features down satisfactorily.
>
> I have never seen a roll-fed 2741. The ones we used at MIT
> on CTSS, Multics, and CP/CMS in the mid to late 60s used
> fan-fold paper with either tractor feed or friction feed.
Every 2741 I've seen used fan-fold w/tractor feed. They were a tad more
than Selectrics, too. The communicating Selectrics were relegated to
the secretary's office and wouldn't have taken the abuse we gave them.
Printing simulation results wore even the 2741s out pretty quickly.
> (Annoyingly, the paper was just a little narrower than
> regular printer paper, 14 inches instead of 14 7/8, and
> more than once I lugged a box home for my home terminal and
> discovered I had the wrong size.) Furthermore, our 2741s
> did not have a work surface: the furniture the print
> mechanism was built into had about 3 inches on each side of
> the typewriter. 1050s came with a kind of desk on the
> right side of the typer, and some third-party terminals
> with the 2741 mechanism also provided a work surface.
ISTR 2741s with a side desk, though it's been a long time. I don't
remember the paper issue, though we likely would have used only the
2741 paper.
<snip>
--
Keith
John Savard
<jcmo...@mitre.org> wrote, in part:
>Or it may have been a jumper; it's been 20+ years since I've touched
>a TTY33 and mental bitrot has been at work all that time.
My initial reaction was to say that to run a Model 33 Teletype - or a
Model 35, or even a Model 28, or a Model 19 - in half-duplex mode, one
simply wired the two input terminals in series with the two output
terminals. In that case, instead of having a plug with four terminals,
one had a plug with two terminals, to connect the device to whatever one
is using it with.
But I do distinctly recall that some Model 33 Teletypes were indeed
fitted with a knob that one could turn to "full" or "half" duplex; that
was on the right side, in the front, and it also served to turn the
device on.
Tom Van Vleck
> ISTR 2741s with a side desk, though it's been a long time. I don't
> remember the paper issue, though we likely would have used only the
> 2741 paper.
Found this picture at the Columbia site:
http://www.columbia.edu/acis/history/2741.html
It shows a 2741 head on.. you can see there is no work
surface, and that the paper has holes... though the
tractors are not visible. Same picture is at a site
at "ufl.edu".
My first home terminal was a 2741, installed in the
third floor of my apartment on Huron Av in Cambridge
in 1967 or so. It weighed over 300 pounds and took
four people to get it up the stairs.
K Williams
th...@multicians.org says...
> K Williams <k...@att.bizzzz> wrote:
> > ISTR 2741s with a side desk, though it's been a long time. I don't
> > remember the paper issue, though we likely would have used only the
> > 2741 paper.
>
> Found this picture at the Columbia site:
> http://www.columbia.edu/acis/history/2741.html
>
> It shows a 2741 head on.. you can see there is no work
> surface, and that the paper has holes... though the
> tractors are not visible. Same picture is at a site
> at "ufl.edu".
I didn't mean to imply they all had side desks (I certainly remember
some as you the link shows), just that I remembered some were
different. They may have been internal modifications though. I also
remember the Communicating Selectrics as being something quite
different.
> My first home terminal was a 2741, installed in the
> third floor of my apartment on Huron Av in Cambridge
> in 1967 or so. It weighed over 300 pounds and took
> four people to get it up the stairs.
300lbs. I never carried one, but I didn't think they were quite *that*
heavy. Some were on casters and didn't seem like a refrigerator. ;-)
> http://www.multicians.org/thvv/terminals.html
Nice site.
--
Keith
Robert Billing
> But I do distinctly recall that some Model 33 Teletypes were indeed
> fitted with a knob that one could turn to "full" or "half" duplex; that
> was on the right side, in the front, and it also served to turn the
> device on.
ISTR the knob went FULL-LOCAL-HALF. The LOCAL position on an ASR was for
offline tape preparation. Above the knob was a panel that could be fitted
with one of several comms options, including one that worked with a UK
Post Office Telephones modem. This modem was about one and a half times
the size of a modern PC.
hanc...@bbs.cpcn.com
John Savard wrote:
> But I do distinctly recall that some Model 33 Teletypes were indeed
> fitted with a knob that one could turn to "full" or "half" duplex;
that
> was on the right side, in the front, and it also served to turn the
> device on.
I recall two types of Model 33 TTYs.
One had a built in modem and automatic control. On the right
side was a panel with a dial (or touchtone pad) along with buttons.
One hit ORIG to start a session. This type of TTY could remotely
answer calls.
The other model had a blank panel. There was a large knob,
my memory is that it was online-off-local. This type required
a modem. Some used acoustic couplings, others had a phone with
a knob that was pulled up.
Underneath on both models was a tiny box with a tiny knob
for half or full duplex. There was a second knob but I don't
recall its function.
co...@austin.rr.com
I had a Portable 2741 in my office in 1968 at the IBM Boston
Programming Center (545 Tech Sq, Cambridge). As I recall it consisted
of two boxes, each weighing 40 lbs,. the maximum weight that a CE was
allowed to lift.
>
>> http://www.multicians.org/thvv/terminals.html
>
>Nice site.
Brian Inglis
hanc...@bbs.cpcn.com wrote:
ISTR a local/remote echo knob, as some systems provided remote
eecchhoo, or could be set to do so (e.g. TOPS-10), while others did
not and required local echo (e.g. GE). I often set (remote) echo off
on systems that allowed it, set the TTY to remote echo, and typed
blind to cut down the amount of output I had to wait for the TTY to
print. It was a good way to learn TECO!
--
Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
Brian....@CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca)
fake address use address above to reply
Joe Morris
>I recall two types of Model 33 TTYs.
>One had a built in modem and automatic control. On the right
>side was a panel with a dial (or touchtone pad) along with buttons.
>One hit ORIG to start a session. This type of TTY could remotely
>answer calls.
That was the box with a DataPhone 109...
>The other model had a blank panel. There was a large knob,
>my memory is that it was online-off-local. This type required
>a modem. Some used acoustic couplings, others had a phone with
>a knob that was pulled up.
...and that's the one without the 109. Some vendors took this model
and installed an acoustic coupler where the blank panel was placed
by the factory; in others the end user connected the RS232 plug to
a data set (in the peak days of the TTY33 wired connections to the
public dial network had to go through WECo data sets, which in many
cases required a separate instrument to establish the phone call).
>Underneath on both models was a tiny box with a tiny knob
>for half or full duplex. There was a second knob but I don't
>recall its function.
Um...that I don't recall. It may have been a special feature on your
systems, or it may have been added by a third party. Or my bitrot
may be getting worse.
Joe Morris
Jeff Jonas
>was also an odd little machine, low-end scientific computer with of
>all things variable word length.
I used and maintained an IBM system 1130 in college and I
don't recall ANY mention of 1620 for legacy code, porting or conversions.
Sadly, only a few pieces of the 1620 remained
so I never saw one in operation or could note any similarities.
> And then it also appeared as the 1800 for process control work.
It would be interesting if there were "internal" needs for such a machine
within IBM to support their own processes/manufacturing.
That would be an interesting motivation.
re: recycling parts:
The 1132 printer was definitely recycled from some accounting machines.
I recognized the knobs and covers from the carrige control tape
from 1950s brochures of dedicated-function accounting machines.
There were gray hammertone parts inside the blue cabinet!
The 1627 plotters were made by Calcomp and were from the 1620 system.
The paper tape reader was made by Tally
and looked identical to the one from the General Precision LGP-21.
The console typewriter was a modified Selectric,
the keyboard a keypunch keyboard.
The internal connectors for the slow speed peripherals
were PC boards from the 1620.
Every peripheral had its own character set,
so software tables converted among them.
Few were EBCDIC.
The console keyboard was card code (no surprise: it was a keypunch keyboard)
but the console typewriter was Selectric golfball-specific.
Jeff Jonas
>> for the line printer (1403?).
That's the 1133 multiplexor: it contained "external" controllers
connected to a really fat cable: the SAC: Storage Access Channel
(kinda a DMA channel or ISA bus).
That cabinet was full of power distribution stuff and racks
for controllers for auxilary disks, printer, etc.
One of Cooper Union's 1130s had that for running 2 additional platters,
but I unplugged it when we got a Calcomp diskpack that plugged directly
into the SAC connector. The clothes-washer sized diskpack drive
had a clear top so I could see the linear motor move the heads!
11 platters, 20 useable surfaces in banks of 5
(mostly due to monitor limititions).
I wish I had saved the 4004 that ran that!
Jeff Jonas
>>> peripheral used a unique code set that had to be translated
>>> when doing I/O.
One technical reason is that I don't think ROM was yet available
(other than diode-arrays or bed-of-nails for a punched card).
The other is that existing devices were easier to interface
without any hardware translation.
And it allowed for fun things like block-lettering
across the paper tape and punched cards.
One of my favorite programs took console keyboard input and
punched it in block letters on punched cards for quick signs!
The console switches selected center/left/right justify,
underline/overline/both/neither, number of spaces between characters.
I think that was a gift from Stuvescent High School to the Cooper Union.
I don't remember getting to swap programs with
Mr. Berlin of Jamaica High School.
I just pulled out my GX26-3566-7
"IBM 1130 reference handbook: programming reference charts"
for it lists the data formats for each device
and how the 16 bits were mapped (not all bits were always used).
>>> The library was full of functions for translating card-reader
>>> encoding to printer, console keyboard to card-punch, etc. The
>>> routines could sync themselves with the progress of the I/O and
>>> translate codes on the fly as they were received/transmitted.
>> IIRC, there was a library routine called "ZIPCO" which performed
>> character set conversions.
I don't recall what manual listed those but I clearly remember
that there were 2 families of translation subroutines.
One was table based, kinda like the 'tr' (translate) instruction
of the IBM 360. I don't recall if it was one subroutine that
took the table as an argument, or a family of subroutines for all the
translation tables (card-code to EBCDIC, EBCDIC to Selectric, etc.)
The other was specific to the 1442 card reader and auto-synchronized
to the card reader. The 1442 card reader was really DUMB!
[but amazing technology for the time: fiber optics illuminated the reader
and photo-interruptor for even lighting and eliminating bulb vibration]
It interrupted once per column (for reading or punching:
could not perform both at once because all the cards advanced together).
Interrupt level 0 was the highest level interrupt (levels were 0-5)
and was ONLY used by the 1442 card reader since it could NOT backspace:
miss that interrupt and it's time to put the card back to re-read!
Once the motion clutch engaged,
the entire card advanced for reading or punching. NO stopping midway!
The 1130's core was word oriented: 16 bits (and parity),
so only 12 bits were filled: the other 4 were zero filled.
So the conversion subroutine ONE FILLED the low 4 bits
and spun-waited for them to become zero
as the interrupt routine moved in each column.
That way, each column was converted as it arrived
using the otherwise dead time between arriving columns.
Just as the system 1130 used parts from earlier machines,
the 1442 card reader was used in many subsequent machines.
I saw one attached to a System 3 instead of the little square cards.
Having 2 stackers (where the cards come out)
was really nice for applications such as deck duplication:
it alternated the outputs between decks
and marked the deck end with a card with "END" across it.
A simple application sorted out blank cards
before recycling decks.
Sigh: I never knew they'd all go away so fast or I'd have
taken more photos and recorded the sounds.
Ah, to have had a camcorder back then!
Steve O'Hara-Smith
Justa Lurker <Justa...@att.net> wrote:
> IIRC, there was a library routine called "ZIPCO" which performed
> character set conversions.
I recall there being two sets of conversions (particularly for
ASCII to EBCDIC for the tape reader). One was fast bloatware (used a
256 byte lookup table - such an extravagent use of memory) and the other
was slower but much smaller as it used tests and arithmetic.
Peter Flass
>>My understanding is that the 1130 was a replacement for the 1620, which
>>was also an odd little machine, low-end scientific computer with of
>>all things variable word length.
>
>
> I used and maintained an IBM system 1130 in college and I
> don't recall ANY mention of 1620 for legacy code, porting or conversions.
> Sadly, only a few pieces of the 1620 remained
> so I never saw one in operation or could note any similarities.
>
They were about the same size, and aimed at the same market, but
otherwise I can't see that they had much in common. Both were the PCs
of their day. I encountered both in college, where they were used to
provide hands-on computer time to science and engineering students for
labs and such.
Carl Lowenstein
Dennis Ritchie <d...@bell-labs.com> wrote:
>
>
>Likewise this. I'm pretty sure that full-duplex (no local echo) on the
>TTY 33 and 35 was configurable, but not remotely;
>the 37 could be set remotely.
>
> Dennis
Hence the name of the Usenix magazine ";login:"
The ";" and ":" come from the the escape sequences that set half-
and full-duplex on a TTY 37. But on a VT05 video terminal, the <esc>
was ignored, and the full ;login: appeared on the screen.
carl
--
carl lowenstein marine physical lab u.c. san diego
clow...@ucsd.edu