IBM 3705 and UC.5

Henk Stegeman

unread,

Nov 27, 2004, 1:57:47 AM11/27/04

to

On this newsgroup multiple entries say the IBM 3705 had a UC.5 processor.
Yesterday I found in my archive the IBM 3704/3705-I/3705-II Principles
Of Operations.

I compared the instruction set of the 3705 with the UC.5 reference card I have.
They don't match at all.
The UC.5 has a 4 bit opcode and a 4 bit extention code.
The 3705 has a 5 bit opcode.

Was the UC.5 and the 3705 CPU's only compatible at assembler level ?
Again a problem: the 3705 had only 7 reg per interupt level
while the UC.5 had 16 regs.

Any other views...

I am trying to compile a list where IBM used the UC.x in.
Sofar:
IBM 8100
IBM 3274
IBM 3081 (service processor)
IBM 3683 & 3684 (checkout counter)
????

Any other machines ?

Henk Stegeman

Peter Flass

unread,

Nov 27, 2004, 7:16:21 AM11/27/04

to

Henk Stegeman wrote:
> On this newsgroup multiple entries say the IBM 3705 had a UC.5 processor.
> Yesterday I found in my archive the IBM 3704/3705-I/3705-II Principles
> Of Operations.
>
> I compared the instruction set of the 3705 with the UC.5 reference card I have.
> They don't match at all.
> The UC.5 has a 4 bit opcode and a 4 bit extention code.
> The 3705 has a 5 bit opcode.
>

I thought the 3705 resembled a System/7, but I have only a superficial
(or less) acquaintence with both. What's a UC.5?

Anne & Lynn Wheeler

unread,

Nov 27, 2004, 10:46:37 AM11/27/04

to

Peter Flass <Peter...@Yahoo.com> writes:
> I thought the 3705 resembled a System/7, but I have only a superficial
> (or less) acquaintence with both. What's a UC.5?

UC ... universal controller

I had some vague recollection of somebody saying that 3705 was a uc.5
microprocessor.

there were somebody in the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

that was in the process of doing the stuff for the internal
network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and had done some stuff with both an 1130 and system/7.

they got involved in some discussion about pushing peachtree (which
became the series/1) as opposed to (I thot) uc.? for the 3705. I have
some vague recollection of part of the argument that at least
peachtree had hardware interrupt levels (with save/restore) while the
processor while the 3705 processor didn't.

note this was after i was involved as undergraduate on building 360
controller replacement using an interdata.
http://www.garlic.com/~lynn/subtopic.html#360pcm
the project originally started off reverse engineering the channel
interface and building a channel interface card for an interdata/3.
later the project evolved into collection of interdata/3s as dedicated
line-scanners and interdata/4 handling the processor interface (which
provided a lot more processor sophistication than whatever was
eventually selected for the 3705).

brief mention of universal controllers
http://www.sciencedaily.com/encyclopedia/ibm_8100

slight drift with respect to above ... my wife had gotten assigned to
do a technical audit of 8100 ... and shortly after, 8100 was killed.

long ago and far away i did have a specific reference that the service
processor in the 3081 was uc.5. then there was some contention with
the group selecting 4331/vmcms for the service processor for the 3090
(instead of continuing with uc.5 stuff from the 3081). part of the
issue was field service requirement needing an on-site diagnostic
process that starts with scoping individual components. when the main
processors no longer had scopable parts ... a service processor that
had hardware diagnostic visability into all parts of the system became
a requirement .... where it was possible to do a bootstrapped
diagnostic processor starting with being able to scope the service
processor ... and then use the service processor to diagnose the main
processor. the 4331/vmcms (as service processor) for the 3090 grew
into a pair of 4361/vmcms systems i.e. replicated service processors
... so a service processor failure didn't become critical path in
diagnosing the main processor (also the main processor was becoming
more and more dependent on the service processor for normal
operation).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Anne & Lynn Wheeler

unread,

Nov 27, 2004, 11:02:52 AM11/27/04

to

for some additional topic drift .... check 3704/3705 tales at vmshare
archive
http://vm.marist.edu/~vmshare/

Dave Tuttle's Memoirs
http://vm.marist.edu/~vmshare/browse?fn=VMHIST07&ft=NOTE

"Tales of the IBM 3704/3705" (from above)

My first run-in with the IBM 3704/3705 Programmable
Communication Control Units (PCCUs) was sometime towards the
end of 1970, I think. The CSC work on S/360 communications
was apparently recognized within the rest of IBM, since the
controller hardware group in Raleigh, North Carolina, sent a
couple of people up to Cambridge to talk to us about their
plans for a new front-end controller product. They
described it as a state-of-the-art, multi-line
communications control unit, capable of supporting many
different line types and protocols, "programmable" through
user-specified parameters. We called it "the great step
forward into the past!"

Some of the earliest IBM data communications work had been
done next door at MIT as part of the CTSS development, using
a beast known as the IBM 7750--a programmable communications
control unit so difficult to handle that there were
reportedly fewer than a dozen people who had ever programmed
it successfully! Ed Hendricks, Craig Johnson, and I had all
talked, at one time or another, to the one person at MIT who
ever did 7750 programming. We all considered the S/360
2701, 2702, and 2703 hard-wired controllers a real benefit;
they made it possible for highly intelligent people to write
communications programs. The IBM 7750 and its brethren
required a genius specialist.

... snip ...

Tom Linden

unread,

Nov 27, 2004, 11:10:32 AM11/27/04

to

On Sat, 27 Nov 2004 09:02:52 -0700, Anne & Lynn Wheeler <ly...@garlic.com>
wrote:

There were several companies that built 270x replacement units
using minicomputers, but I don't recall their names.

>
> ... snip ...
>

--
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Anne & Lynn Wheeler

unread,

Nov 27, 2004, 11:45:43 AM11/27/04

to

"Tom Linden" <t...@kednos.com> writes:
> There were several companies that built 270x replacement units
> using minicomputers, but I don't recall their names.

interdata was bought up by perkin-elmer and sold under the
perkin-elmer name. another was comten. however, the claim
was that the project that i worked on as undergraduate was the
first to create such a plug compatable box
http://www.garlic.com/~lynn/subtopic.html#360pcm

the problem started out when I added tty/ascii terminal support to
cp/67. i looked at the 2702 channel specs ... and looked at the cp/67
code that dynamically decoded whether there was a 2741 (and type of
2741) or 1052 on the line (standard os/360 programming was that it was
"fixed" and you had to specify the terminal type for each line in the
system generation process).

So I got fancy and wrote some programming that attempted to
dynamically decide whether it was a 2741, 1052 or TTY on the end of
the line. I tested it and for the cases I used, it worked, Based on
that, the university wanted to have a single dial-up line pool
... that both 2741s and TTYs could dial into the same number.

That was when the CEs got involved and said that while it was possibly
to dynamically change the line-scanner associated with each line using
the SAD ccws .... the 2702 had taken a short-cut and hardwire
oscillators to each line. The result was while it was possible to
dynamicall change the line-scanner associated with each line ... and
kernel program could tell what kind of terminal was on each line ...
it was not possible to make a common dial-up line pool. As long as
termianls were hard-wired to the correct line ... they got the correct
oscillator for that terminal line-speed.

So the university Interdata project started out with the objective of
having the Interdata/3 being able to dynamically determine the baud
rate on the line. Coupled with the dynamic terminal identification coe
that I had written in CP67 ... they then could have a common dial-up
line pool.

Tom Van Vleck

unread,

Nov 27, 2004, 1:10:55 PM11/27/04

to

Lynn Wheeler <ly...@garlic.com> wrote:
> (quoting Dave Tuttle)

> Some of the earliest IBM data communications work had been
> done next door at MIT as part of the CTSS development, using
> a beast known as the IBM 7750--a programmable communications
> control unit so difficult to handle that there were
> reportedly fewer than a dozen people who had ever programmed
> it successfully! Ed Hendricks, Craig Johnson, and I had all
> talked, at one time or another, to the one person at MIT who
> ever did 7750 programming.

That would be Stan Dunten.
(I have a 7750 manual in my attic, should send it to
bitsavers..)

Anne & Lynn Wheeler

unread,

Nov 27, 2004, 3:27:27 PM11/27/04

to

from fading memory

2702 sad ccw commands selected

sad1 - 2741 line scanner
sad2 - tty/ascii line scanner
sad3 - 1052 line scanner

...

the base cp/67 terminal code could play with sad1 & sad2 & transmitted
data and look at the responses and determine whether the terminal was
2741 or 1052.

when i added tty/ascii support to cp/67 .... i sort of played the same
game ... except figuring out how to dynamically determine tty/ascii
and playing with sad1, sad2, and sad3.

there wasn't a oscillator/baud-rate problem with hard-wired terminals
since you could make sure that the port that the hard-wired terminal
plugged into had the corresponding oscillator wired to it.

there also wasn't a problem with common pool for dialed 1052s & 2741s
since they operated at the same baud rate. the problem was that the
1052s&2741s had a different baud rate from the ttys ... and the sad
command only changed the line scanner on a port ... but there was no
way to change the hardwired oscillator (so the baud rate was fixed).

the university project reverse engineered the ibm channel interface
and built a channel/controller interface board that fit in (initially)
an interdata/3. the interdata/3 then had software programming added to
dynamically determine the terminal baud rate (it strobed for the line
signal rise/drop to calculate the baud rate). The initial
implementation had single interdata/3 handling both the lines and the
channel interface. later there was sort of a cluster with dedicated
interdata/3s for lines and an interdate/4 for the channel interface.

supposedly the university project was the first of this genre
http://www.garlic.com/~lynn/subtopic.html#360pcm

it is the competition from these plug compatable controllers that
supposedly gave birth to both furture system
http://www.garlic.com/~lynn/subtopic.htm#futuresys

and the really baroque, complex pu5/pu4 interface (aka vtam/ncp
... pu5/vtam in the mainframe, pu4/ncp in the 3705).

my wife had worked on fs and after it was killed, she worked with
moldow and produced AWP39, peer-to-peer networking architecture (there
were rumors that it put some people in Raleigh on tranquilizers).

she then got con'ed into going to pok to be in charge of
loosely-coupled architecture, while there she produced peer-to-peer
shared data architecture
http://www.garlic.com/~lynn/subtopic.html#shareddata

basically SNA, as in pu4/vtam was a terminal control infrastructure
(virtual telecommunications access method as a follow-on to tcam,
terminal control access method) ... not a networking infrastructure.
the first thing resembling networking related to SNA was with APPN in
1986. Note that SNA/Raleigh non-concurred with announcing APPN ... and
the announcement letter was eventually rewritten so that it was very
careful to not state any direct relationship between APPN and SNA.

Henk Stegeman

unread,

Nov 28, 2004, 2:27:29 AM11/28/04

to

Tom Van Vleck <th...@multicians.org> wrote in message news:<thvv-6DB8A6.1...@comcast.dca.giganews.com>...

> (I have a 7750 manual in my attic, should send it to
> bitsavers..)

Please do.
Henk

Anne & Lynn Wheeler

unread,

Nov 28, 2004, 12:25:32 PM11/28/04

to

Anne & Lynn Wheeler <ly...@garlic.com> writes:
> interdata was bought up by perkin-elmer and sold under the
> perkin-elmer name. another was comten. however, the claim

oh, and parts of comten thread from last year
http://www.garlic.com/~lynn/2003c.html#70 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#76 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#77 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003c.html#79 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#13 COMTEN- IBM networking boxes
http://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS

http://www.garlic.com/~lynn/2003d.html#20 COMTEN- IBM networking boxes

--

Anne & Lynn Wheeler

unread,

Nov 29, 2004, 11:18:06 AM11/29/04

to

stege...@12move.nl (Henk Stegeman) writes:
> I checked the 3705 POO with the Functional Characterisics of the
> System/7. They are completely different.
>
> Looks like IBM re-invented the wheel every time.

that was a justification for fort knox ... to converge the wide variety
of microprocessors around the corporation to 801
http://www.garlic.com/~lynn/subtopic.html#801

under fort knox, the follow-on to the (370) 4341 would have been a
801-based microprocessor.

Al Kossow

unread,

Nov 29, 2004, 3:26:52 PM11/29/04

to

stege...@12move.nl (Henk Stegeman) wrote in message news:<7980590c.04112...@posting.google.com>...

> Tom Van Vleck <th...@multicians.org> wrote in message news:<thvv-6DB8A6.1...@comcast.dca.giganews.com>...
>
> > (I have a 7750 manual in my attic, should send it to
> > bitsavers..)
>

I have about six 3705 manuals in the queue. Are these needed?
I can push them up if they are.

Peter Flass

unread,

Nov 29, 2004, 6:09:28 PM11/29/04

to

> I checked the 3705 POO with the Functional Characterisics of the System/7.
> They are completely different.
>
> Looks like IBM re-invented the wheel every time.
>

Glad someone still have the docs. My apologies for what turned out to
be a red herring. My recollections are all 25 or so years old.

Bruce B. Reynolds

unread,

Nov 30, 2004, 8:20:32 PM11/30/04

to

In article <pe_pd.18552$1u.1...@twister.nyroc.rr.com>, Peter Flass
<Peter...@Yahoo.com> writes:

>I thought the 3705 resembled a System/7, but I have only a superficial
>(or less) acquaintence with both. What's a UC.5?

The 3705 shared many physical characteristics with the System/7 (power
supplies, gate design, fans, skin, console knobs, etc.), but I can't think
that
there would be much of the system architecture shared between them: the
System/7 shared its op codes with the System/3...it could be considered
related to the S/3 as the 1800 was related to the 1130, a realtime superset.
--
Bruce B. Reynolds, Trailing Edge Technologies, Glenside PA

Henk Stegeman

unread,

Dec 1, 2004, 6:31:44 AM12/1/04

to

> The 3705 shared many physical characteristics with the System/7 (power
> supplies, gate design, fans, skin, console knobs, etc.), but I can't think
> that
> there would be much of the system architecture shared between them: the
> System/7 shared its op codes with the System/3...it could be considered
> related to the S/3 as the 1800 was related to the 1130, a realtime superset.

I have the POO of the S/3 and the S/7. No match at all.
The S/3 is a real batch string architecure with variable instruction
length, while S/7 is fixed and focussed on fast real time processing.

Regards Henk

Mike Ross

unread,

Dec 1, 2004, 9:31:38 AM12/1/04

to

On 01 Dec 2004 01:20:32 GMT, bbrey...@aol.comedxedl (Bruce B.
Reynolds) wrote:

I beg to differ... the S/3, AFAIK, was a new design - the first
complete processor from Rochester. The S/7 lineage goes:

1800/1130 -> System/7 -> Series/1

Mike
--
http://www.corestore.org
"All I know is that I'm being sued for unfair business practices by Microsoft. Hello pot? It's kettle on line two" -
Michael Robertson