*start*
01303 00024 US
Date: 8 Oct. 1981 9:48 am PDT (Thursday)
From: Swinehart.PA
Subject: telephone trivia (suggestion from Paxton)
To: VoiceProject↑
---------------------------
Date: 8 Oct. 1981 8:11 am PDT (Thursday)
From: Paxton.PA
Subject: telephone trivia
To: Swinehart
Dan,
Please add this to your list of features if it's not already there --
I keep forgetting to cancel call forwarding and would really like to say "forward
my calls to x1234 for the next 3 hours" and have it automatically time out.
Trivial feature, but it would sure help me.
Bill
---------------------------
Date: 8 Oct. 1981 8:45 am PDT (Thursday)
From: Swinehart.PA
Subject: Re: telephone trivia
In-reply-to: Your message of 8 Oct. 1981 8:11 am PDT (Thursday)
To: Paxton
cc: Swinehart
Sure. Most systems cancel forwarding every midnight anyhow. We intend to have phones follow your "login" around, which will help sometimes. Ultimately, they may follow YOU around -- which will either be good or bad -- just call us Pandora. In any case, (Motherhood coming, watch out) all these features will be programmable by clients outside the boundaries of our servers and terminals -- e.g., from the workstation. If anything's the main idea, that's it.
------------------------------------------------------------
*start*
03088 00024 US
Date: 7 Oct. 1981 9:27 pm PDT (Wednesday)
Sender: Owicki.PA
Subject: Minutes of meeting on EtherPhone Smarts, 10-7-81
To: VoiceProject↑
cc: Owicki
From: Owicki, Swinehart
Reply-To: Owicki
We now have a rough idea of the state-structure of the Etherphone Smarts. I
hope to start coding next week.
States
Idle
Parsing (interpreting an event sequence from the etherphone)
Initiating (trying to place an outgoing call)
Incoming (an incoming call has arrived and Etherphone is ringing)
Conversing (connection has been established)
DisconnectInitiate (Etherphone has signalled termination)
DisconnectIncoming (Other end of call has signalled termination)
These might be called the "major" states. There will be substates in many cases
-- parsing is the most obvious example. The last two states might disappear, but
we're leaving them in for the time being.
Events that cause a state transition may come from the etherphone or from the
server. Events from the etherphone include offhook, onhook, and some set of
digits, letters, and special characters. Events from the network include
canconnect -- requests information only. Legal in any state, but causes
no state changes, so not listed in transitions below.
alert -- announces an incoming call
abort -- cancel current conversation or connect attempt
converse -- informs of sockets for conversing
{rejected, busy, accepted, OKBut} -- returns from CanConnect and Alert
State transitions
Where an event is not mentioned as a transition from a state, it causes no state
change. It may cause some sort of error report to the initiator of the event.
Event New State Actions
Idle
Off-hook --> Parsing
Alert --> Incoming Send ring to EP (Done by setting up
a process, which is killed when leaving
Incoming state)
Parsing
EP-events --> Parsing Silence to EP
EP-end --> Initiating
On-Hook --> Idle
Initiating
On entry Create conversation
CanConnect
Send RingBack to EP
Alert
rejected --> disconnectIncoming Send error sound to EP
busy --> disconnectIncoming Send busy signal to EP
On-Hook --> disconnectInitiated send abort to server
accepted --> conversing conversation.join
OKBut --> parsing (to be done later!)
Note -- we ultimately plan a work station which is much smarter here. In
particular, a rejected or busy may cause further parsing or may remain in the
Initiating state. The state transitions above should be sufficient for the first cut.
Incoming
Off-hook --> Conversing conversation.join
kill ringing process
Abort --> Idle kill ringing process
Conversing
Abort --> DisconnectIncoming Send dial tone to EP
On-hook --> DisconnectInitiated Send silence to EP
conversation.leave
DisconnectInitiate
At entry conversation.leave
--> Idle
DisconnnectIncoming
Time-expired --> Parsing dialtone to EP
On-hook --> Idle silence to EP
*start*
03979 00024 US
Date: 8 Oct. 1981 12:08 pm PDT (Thursday)
From: Swinehart.PA
Subject: Minutes of an RPC-related conversation with Andrew Birrell
To: VoiceProject↑, Birrell
cc: Swinehart
Susan and I talked with Andrew on Monday 10/5. We clarified our intended use of the RPC. It looks quite doable, although in places a little strange at first.
Basic idea: If a program module wants to use some procedures from (a single or fixed number of instances of) an interface that is to be implemented remotely, the program module just imports the interface and calls the procedures. When the system is configured, a "stub" module is included to export the interface. The stub in turn knows how to turn procedure calls into network communications and to turn network communications into return records.
At run time you have to "bind" the stub to some remote implementation, I think through specific calls. The normal way to do this is to communicate with Grapevine, which associates very specific bindings with very specific names. When a "server" (provider of remote binding) comes up, it enters its net location in this data base. I think the general notion is that such bindings should last a long time, but there's no real problem with their coming and going as various things come on line, etc. Once the bindings are known, they need not be consulted again in order to perform the RPCs; the RPC implementation will use the binding info to create/destroy sequenced connections, etc.
First problem and solution: The Lark program won't be powerful or big enough to crank up a full Pup byte stream for contacting this binding service on Grapevine. So we'll implement a simple packet-exchange thing on a Thrush which will do the binding for its client and return the results.
Second problem and solution: Each Fone will have to initiate communications with time-varying numbers of Smarts (usually 0, 1, or 2), as the Smarts register with it. This kind of thing is not readily doable in Mesa, remote or not, at the "interface record" level -- that's why various object-oriented kludges were invented. In addition, the standard ways of generating "objects" -- as records of procedures and data -- need to be modified a bit in the absence of a shared address space or something known in the language trade as persistent closures of local frames (next time you want to impress your grandmother ...). Our approach: The remote Smarts can use the standard Grapevine means (actually a tuned version that we will provide in Thrush via the Net object -- to which the Smarts WILL bind via Grapevine) to bind to and communicate with its (single) Fone. The first communication will be a Register procedure, whose argument will be a record of other (remote) procedures, bound to that Smart's environment, that the Fone can use to initiate actions later. As long as the Registration procedure is in progress, the record of procedures will remain valid. So the Smarts will have to FORK a process to call the registration procedure. The procedure will not return until a Deregister procedure is called later to destroy the "connection". The Register procedure could return right away when called from a local Smarts -- to save PSB's -- but whether/how to detect the difference is problematical.
A remaining problem: Suppose Smarts[i] calls a Fone action. On occasion, the Fone will want to know which registered Smarts procedure record corresponds to Smarts[i], in order to initiate a later call to that Smarts in particular (it comes up). We'll need some sort of unique identifier that forms a part of the Registered procedure record and is supplied in each Smarts=>Fone call. In previous designs the object handle automatically provided this identifier, but in this design the procedure record is passed by value, so we'll have to make such an identifier explicit, or dredge it out of the RPC implementation.
Have I left anything crucial out, Andrew or Susan?
Dan
*start*
00455 00024 US
Date: 8 Oct. 1981 2:48 pm PDT (Thursday)
From: Stewart.PA
Subject: 1.5 Mbps gateway
To: Boggs
cc: VoiceProject↑.pa
David,
My best guess for when we will need a gateway to 1.5 Mbps is November 10.
Severo will come up with an Alto I when needed.
Besides a gateway, I will want to run a version of Etherwatch and perhaps
Peekpup on the 1.5 net. Given the microcode and an Ethernet controller, that
seems straightforward.
-Larry
*start*
00679 00024 US
Mail-from: Arpanet host SRI-UNIX rcvd at 20-OCT-81 1624-PDT
Date: 20 Oct 81 18:19:55-EDT (Tue)
From: J C Pistritto <jcp.bmd70@BRL>
To: unix-wizards at Sri-Unix
Subject: 8086 C Compiler
Via: BMD70; 20 Oct 81 18:24-EDT
Via: Brl.ArpaNet; 20 Oct 81 15:43-PDT
A group named Virtual Systems Inc. (unsure of the address), will be
marketing a C compiler for the 8086 soon, for an undisclosed price.
This compiler is based on the Whitesmith's Code for the PDP-11, and
generates about 15% more instructions on the 8086 than the 11 version.
Exact availability date is unknown, but thought someone might be
interested.
-Joe Pistritto-
*start*
01078 00024 US
Date: 13 Oct. 1981 3:29 pm PDT (Tuesday)
From: Ornstein.PA
Subject: Memories
To: Stewart
cc: Ornstein
Did you ever get an answer from Thacker to:
- - - - -
Date: 21 Sept. 1981 2:11 pm PDT (Monday)
From: Stewart.PA
Subject: 16Kx1 Static memories
To: Thacker
cc: Ornstein, Stewart
We've been thinking about the Etherphone II memory system. We had been
planning to use a few (e.g. 4) 2Kx8 statics for about 8K bytes. That now seems
tight. The next step is probably 8 16Kx1 statics with space for another row of 8
for up to 32 K bytes. Above that, probably we would need to go to 8 64K
dynamic chips.
Questions:
Is this thinking right?
How hard is it to build a dynamic memory system using one of the new
controller devices?
What is the right 16Kx1 chip to use? (I noticed that the D0 Map uses dynamic
memories).
-Larry
- - - - -
I'm currently planning just for 16K bytes of Ram (eight of the 2K x 8). Should I
allow for more - twice that? It's easy at this stage so if there is any question in
your mind, we probably should- let me know.
S.
*start*
00313 00024 US
Date: 13 Oct. 1981 4:08 pm PDT (Tuesday)
From: Stewart.PA
Subject: Re: Memories
In-reply-to: Your message of 13 Oct. 1981 3:29 pm PDT (Tuesday)
To: Ornstein
cc: Stewart
Plan for 32K for now. Chuck didn't answer. Have you heard from Joe Patti on
the search for slow 16K x 1's?
-Larry
*start*
03408 00024 US
Date: 13 Oct. 1981 6:01 pm PDT (Tuesday)
From: Ousterhout.PA
Subject: Conferencing revisited
To: VoiceProject↑.pa
Here are some thoughts about conferencing and recording of conversations.
The overall idea is to make the transmission protocols simple and uniform
by using multi-casting with a single packet size. Comments are invited, of
course.
1. Dan informs me that it is possible to get Dorado microcode to respond
to multiple Ethernet addresses, so
2. I propose that multi-casting should be used between Etherphones and the
VFS. Each conversation is assigned (by Thrush) an address to be used,
and all Etherphones change their network address to that conversation
address for the duration of the conversation. Thus all Etherphones will
get all packets related to a conversation. Since the VFS may be taking
part in several conversations, it will have to be able to respond to several
addresses.
3. A packet intended for just one element of a conversation will have to
be identified internally with the desired recipient, since all elements of
the conversation will receive it. An example of such a packet is an RPC
from Thrush to make one of the Etherphones leave the conversation. Dan
and Susan: how much will this complicate Thrush and/or RPC? Since
the VFS will respond to multiple addresses, only Thrush/Lark and Lark/Lark
communication will be complicated.
4. Lark and Bluejay will receive their own transmissions, and will have to
throw them away.
5. I think that multi-casting is the simplest way to (eventually) solve or
(initially) ignore the merging problem. By using multi-casting it won't
be necessary to merge and retransmit 3-way conversations from some central
point. I suggest that each element of a conversation be left to its own means
to handle merging. For the VFS, I think it has enough horsepower to do
the merges. For the Etherphones, if one Etherphone has enough horsepower,
then they all do, so it doesn't matter that all of the Etherphones in a
conversation are merging the same stuff at the same time (there's no good
reason for having one Etherphone merge for the others).
6. It seems to me that the necessity for merging will be infrequent and
short-lived. In most conversations, there will be only one active source
at a time. If the Etherphones don't have enough grunts to do merging,
then it might work out OK to use some brute force technique like:
-- bleep when two sources are active
-- alternate back and forth between the various sources on a packet
by packet basis.
These are both pretty gross, but they would at least allow us to do simple
conferencing in the short run. In the long run, there will (?) be faster
8088's that will (?) have enough horsepower.
6. Lastly, I propose that the VFS should receive packets just like Etherphones,
i.e. small packets every 20 ms. I don't know how this will affect its
performance, but I'm certain it will make life a lot simpler during the
initial implementation.
The overall goal behind these suggestions is to keep life as simple as possible
during the early implementation, while still leaving open general schemes
like 3-element conversations. If we implement multiple packet sizes and
central merging, then we pay the implementation cost immediately.
The open question is whether there will be enough horsepower for the
simple implementation.
-John-
*start*
01156 00024 US
Date: 14 Oct. 1981 8:03 am PDT (Wednesday)
From: Owicki.PA
Subject: Re: Conferencing revisited
In-reply-to: Ousterhout's message of 13 Oct. 1981 6:01 pm PDT (Tuesday)
To: Ousterhout
cc: VoiceProject↑
Reply-To: Owicki
John,
Using multicasts makes sense, as long as the merging problem can be solved for
the etherphones. As far as I can see, multicasts do not complicate the server
much if at all. The particular example you mention, where Thrush asks an
Etherphone to leave the conversation, is not a problem because that is control
information, which is going to a different socket than voice information in any
case. Given that control and voice always go to different sockets, I don't see any
case where a voice packet would need to go to just one host. If that's right then
no internal destination id is needed.
I'm assuming that we get some automatic message routing to processes on a
machine in Cedar. Is that valid? What I'm thinking of is that when Thrush and
BlueJay share a Dorado, we need to have incoming messages sent to the
appropriate place, and I have assumed the mechanism for that already exists.
Sue
*start*
00642 00024 US
Date: 14 Oct. 1981 8:13 am PDT (Wednesday)
From: Swinehart.PA
Subject: Re: Conferencing revisited
In-reply-to: Ousterhout's message of 13 Oct. 1981 6:01 pm PDT (Tuesday)
To: Ousterhout
cc: VoiceProject↑
I like this approach better than the other approaches, especially at the beginning, since it most closely approaches the ideal (personal opinion) for doing conferencing. The hard part about the control business will probably not be at the Thrush end but at the Lark end, since it hairs up a hand-tuned Pup package. We should probably get a two-party conversation going first, but aside from that, I'm with you.
*start*
01174 00024 US
Date: 19 Oct. 1981 4:16 pm PDT (Monday)
From: Ornstein.PA
Subject: Frequencies
To: Boggs
cc: VoiceProject↑
There are several fundamental frequencies in the Etherphone:
1. The Processor clock - nominally 5 MHZ
2. The SLC clock for running the Ethernet - nominally 1.5 MHZ
3. A T1 clock for digitizing and re-analogizing voice - 1.536 MHZ
4. Clocks for 2400 and 300 baud asynchronous lines
It would eliminate synchronizers and be quite motherhoody if we could run all
this stuff off one basic clock with various count-downs. Roughly it looks feasible
- say you took 9 x 1.536 as basic clock, that would be appropriate for the
processor (which divides it by three and would thus run the Proc. at 3 x 1.536).
Obviously the T1 line would love it (it was set for T1). You can get close
enough to 300 and 2400 baud by counting down (we were going to do that
anyway). So that leaves the Ethernet - the question being - would we be able to
talk to a divided-by-two 3 MB Alto Gateway if we ran at 1.536? Another form of
the question (I think) is - could we (at 2 x1.536 = 3.072 MB) talk to a regular
Alto "3 MB" ethernet (and could it talk to us)?
Severo
*start*
00366 00024 US
Date: 19 Oct. 1981 11:42 am PDT (Monday)
From: Stewart.PA
Subject: Re: Files archived
To: VoiceProject↑.pa
I was annoyed over the weekend because [Indigo]<Voice> was out of space. I
moved a bunch of stuff to [Maxc]<Voice> and archived it. Mostly obsolete
Auburn stuff. There are now around 900 free IFS pages on [Indigo]<Voice>.
-Larry
*start*
00457 00024 US
Date: 20 Oct. 1981 12:10 pm PDT (Tuesday)
From: Stewart.PA
Subject: Ethernet Voice soon, says Massaro
To: VoiceInterest↑.pa
According to the Oct. 19 Information Systems News, OPD will soon announce a
voice store and forward capability for attachment to STARs. Massaro also notes
that the experimental Ethernet at the Palo Alto Research Center can handle 20
simultaneous telephone calls in addition to a normal data load.
-Larry
*start*
04373 00024 US
Date: 28 Sept. 1981 10:01 am PDT (Monday)
From: Deutsch.PA
Subject: Re: D0 LoadMb
In-reply-to: Your message of 27 Sept. 1981 1:52 pm PDT (Sunday)
To: Stewart
Actually, I have a program that converts Dolphin .MB files to .BR files in the
format that LRJ wants. I'm sure you (or I) could easily modify it to load the
microcode directly. The program is called D0PackMB.Run on my Phylum
directory. The source file is d0packmb.bcpl and the command file for loading it
is loadd0packmb.cm. (It uses several library packages which by now have
undoubtedly been tape-archived, but I can send them to you directly if you
want.) The command line format is
>D0PackMB xxx.MB xxx.BR [startlabel/startaddress [symbol]]
where startlabel/startaddress is the branch address for LRJ (defaults to 0) and
symbol is the external name for the first word of the data in the .BR file
(defaults to RamImage). Since the program is quite short, I'm including a copy of
it with this message. (Ignore the comment which implies that it allows multiple
.MB files.) Good luck.
---------------------------------------------------------
// D0PackMB -- Pack a D0 .MB file for use with LRJ
// last edited August 6, 1980 9:46 AM
// Command line format is:
// D0PackMB xxx.MB xxx.BR [startlabel/startaddress] (xxx.MB
startlabel/startaddress)* [symbol]
get "streams.d"
external
[ // O.S.
Closes
Endofs
MoveBlock
Noop
OpenFile
SetBlock
Wo; Ws; WriteBlock
Zero
fpComCm
// GP
SetupReadParam
ReadParam
// ReadMB
ReadMB
// WriteBR
StartBRfile
StartBRnames; BRname
StartBRlabels; BRlabel
StartBRcode; BRcode
EndBRblock
EndBRfile
]
structure BS: [ length byte; char↑1,255 byte ]
static
[ imx = -1
imap
imv
ni
sa
sav
]
let D0PackMB() be
[ let com = OpenFile(0, ksTypeReadOnly, charItem, 0, fpComCm)
let nv, swv = vec 100, vec 100
SetupReadParam(nv, swv, com, swv)
let inst = ReadParam("IW", ".MB file (input): ", nv, swv)
let outst = ReadParam("OW", ".BR file (output): ", nv, swv)
let svv = vec 100
sav = svv
test Endofs(com)
ifso sa = 0
ifnot
[ ReadParam($P, 0, svv, swv)
sa = readSA(svv)
]
let name = vec 128
MoveBlock(name, "RamImage", 5)
unless Endofs(com) do ReadParam($P, 0, name, swv)
Closes(com)
StartBRfile(outst)
StartBRcode()
BRcode(0) // Bldr zeros the first word! But LRJ wants an extra word
on the front anyway
let imp = vec 10000b // Imaginary to real address map
SetBlock(imp, -1, 10000b)
imap = imp
let imvec = vec 30000b // Holds resulting IM data
imv = imvec
let r = ReadMB(inst, 20, pmemproc, (sa eq -1? psymproc, Noop))
BRcode(imv, ni*3)
let w0, w1, w2 = 7777b lshift 4, sa, sa // Unclear whether word 1 or 2
is the starting address
BRcode(lv w0, 3)
EndBRblock()
StartBRnames()
BRname(#140, 0, name) // entry label xxx
let len = name>>BS.length+1
for i = 0 to 4 do
name>>BS.char↑(len+i) = table[ $L; $a; $s; $t; 0]!i
name>>BS.length = len+3
BRname(#140, 0, name) // entry label xxxLast
EndBRblock()
StartBRlabels()
BRlabel(1, 0) // initialize the initial label
BRlabel(2, 1+ni*3) // initialize the Last label
EndBRblock()
Closes(inst)
EndBRfile()
Closes(outst)
test sa eq -1
ifso [ Ws("Error: starting address not found*N") ]
ifnot
test r eq 0
ifso [ Wo(ni); Ws(" instructions*N") ]
ifnot [ Ws("Error: "); Ws(r); Ws("*N") ]
]
and readSA(sav) = valof
// Read starting address from string, return value if numeric or -1 if not
[ if sav>>BS.length eq 0 resultis -1 // null string
let sa = 0
for i = 1 to sav>>BS.length do
[ let c = sav>>BS.char↑i
test (c ge $0) & (c le $7)
ifso sa = sa*10b+c-$0
ifnot resultis -1
]
resultis sa
]
and pmemproc(memx, width, name) = valof
[ test (name!0 eq 1000b+$I) & (name!1 eq $M*400b)
ifso [ imx = memx; resultis pimproc ]
ifnot resultis Noop
]
and pimproc(addr, data) be
[ let ima = data!3
let p = imv+ni*3
p!0, p!1, p!2 = (ima lshift 4) + (data!2 rshift 12), data!0, data!1
imap!addr = ima
ni = ni+1
]
and psymproc(memx, value, name) be
// Look up a symbolic starting address
if (sa eq -1) & (memx eq imx) then // might have found it already
[ if name>>BS.length ne sav>>BS.length return
for i = 1 to name>>BS.length do
[ let c1 = name>>BS.char↑i
let c2 = sav>>BS.char↑i
if (c1 & not 40b) ne (c2 & not 40b) return // case shift
]
sa = imap!value
Ws(name); Ws(" ="); Wo(sa); Ws("*N")
]
*start*
00887 00024 US
Date: 29 Sept. 1981 10:24 am PDT (Tuesday)
From: Deutsch.PA
Subject: Re: D0 LoadMb
In-reply-to: Your message of 29 Sept. 1981 10:08 am PDT (Tuesday)
To: Stewart
Here's the little program that we use to generate the loader for the Dolphin
Smalltalk-76 microcode.
--------------------------------------
// Load D0 microcode and boot
// last edited April 16, 1981 11:45 AM
// To load up the Smalltalk microcode, the command is:
// >Bldr d0smalltalkmicrocode/s 30000/c d0ram smalltalk
// where smalltalk.BR is the file produced by D0PackMB
external [ RamImage; RamImageLast ]
structure [ blank word 2; blank bit 4; startAddr bit 12 ]
let D0Ram() be
[ let LRJ = table[ #61036 ]
let SDP = table[ #61037; #1401 ]
if SDP(0) ne 1 then // change starting address for partition 2 boot
RamImageLast>>startAddr = RamImageLast>>startAddr + 2
LRJ(RamImage, 1)
]
*start*
01659 00024 US
Date: 15-Oct-81 10:16:14 PDT (Thursday)
From: Murray.PA
Subject: 8085 Assembler and Binder
To: Stewart
cc: Murray
Are you on one DLionMicrocoders↑? Do you know Pat OLMSTEAD? .....
------------------------------
Date: 14 Oct. 1981 4:40 pm PDT (Wednesday)
From: OLMSTEAD.PA
Subject: 8085 Assembler and Binder
To: IOPUsers↑
cc: DLionMicrocoders↑, SDD-WSDes↑, SDD-Arch↑, SDD-Diag↑
Reply-To: OLMSTEAD
I have converted the 8085 assembler and binder to run under Tajo. Along the
way, I plugged many minor and several major storage leaks; I now think I've got
them all.
The programs are I8085AssemblerDLion.bcd and I8085BinderDLion.bcd, stored on
directory [Iris]<Olmstead>8085>.
The interface to both programs is basically the same as it would have been on
the Alto if it had ever worked: To the SimpleExec, type
I8085AssemblerDLion src1 src2 src3...
I8085BinderDLion cfg1 cfg2 cf3...
where the src's are .asm files and the cfg's are .cfg files.
Timing comparisons are difficult, since the Alto-based assembler will die if fed
more than 2 files at a time, or the disk doesn't have enough room for the .lst,
.sym, etc. files. However:
"I8085AssemblerDLion all-the-19-files-in-Domino" took 16 minutes the last
time I checked, and that was with NIL checking on, which I have since turned
off.
"I8085BinderDLion Domino" takes 1 minute; on the Alto it takes from 15 to
20.
"If you use these programs, I would appreciate a message letting me know. This
version has not been extensively tested, so be sure to let me know of any
problems you experience with it."
Pat
----------------------------------------------------------------
*start*
00823 00024 US
Date: 17 Oct. 1981 3:00 pm PDT (Saturday)
Sender: Stewart.PA
Subject: Incoming call management
From: Gifford.PA
To: VoiceProject↑.pa
Reply-To: Stewart
Date: 17 Oct. 1981 12:17 pm PDT (Saturday)
From: Gifford.PA
Subject: Incoming call management
To: Stewart, Swinehart, Ornstein
cc: Gifford
Voice folks,
Although you may have thought of this already, I thought I would pass along
an idea I heard from Al Spector at CMU.
If an outside line is ringing (and not being answered), you may wish to forward
the incoming call to a phone within the Etherphone network. In this case, you
do not have to answer the outside line. Simply ring the Etherphone (or more
than one Etherphone, if you like the shotgun approach), and if it is answered,
pick up the outside line and establish the talk path.
Dave
*start*
01511 00024 US
Date: 19 Oct. 1981 9:55 am PDT (Monday)
From: Swinehart.PA
Subject: Re: Incoming call management
In-reply-to: Gifford's message of 17 Oct. 1981 12:17 pm PDT (Saturday)
To: Gifford
cc: VoiceProject↑
Reply-To: Swinehart
Yes. In fact, once we have real trunks, we could "trip ringing" without actually signalling "answer" (that's done by doing a "reverse battery" operation), and provide various call progress signals -- even recorded announcements about what kinds of forwarding activities were taking place. At present, this would be strictly proscribed by the telco regulations, but these days negotiation is the watchword, so it would be fun to toy with some of this stuff.
-------------------------------------------------------------------------------
Date: 17 Oct. 1981 12:17 pm PDT (Saturday)
From: Gifford.PA
Subject: Incoming call management
To: Stewart, Swinehart, Ornstein
cc: Gifford
Voice folks,
Although you may have thought of this already, I thought I would pass along
an idea I heard from Al Spector at CMU.
If an outside line is ringing (and not being answered), you may wish to forward
the incoming call to a phone within the Etherphone network. In this case, you
do not have to answer the outside line. Simply ring the Etherphone (or more
than one Etherphone, if you like the shotgun approach), and if it is answered,
pick up the outside line and establish the talk path.
Dave
-------------------------------------------------------------------------------
*start*
01121 00024 US
Date: 21 Oct. 1981 5:02 pm PDT (Wednesday)
From: Ornstein.PA
Subject: Hardware Questions
To: Ornstein, Stewart
1. Intel 8237
a. Does 8237 re-prioritize in single transfer mode after each byte transferred -
even if the lower priority guy holds onto his request (in case a higher priority
guy comes in)
b. Similarly - does it re-issue ADSTRB on each new byte (in single transfer
mode) in case the other DMA got in and polluted the latch.
c. on a write from memory to device, how long between stopping write-device
and stopping read-memory? (This gives us some part of the 80ns the 8068 needs
- the memory will give some more delay).
Larry Goss 496-7360
2. AMD 8068
a. is the data hold time really 80 ns. (and adress 60) ? Data Hold = TG1HD1X
and Address = TAHD1X (pgs 11 - 12)
b. what does "synchronous" mean under clocking ( pg 8 under clk pin
description)
c. is port config forced by reset (Master clear, Slave Encrypt) and unsettable in
Direct Control mode? (We'd really like single port)
Chuck Lytle 408-727 1300 applications guy
real engineer is Subodh Banerjee - going to call us
*start*
04566 00024 US
Date: 30 Oct. 1981 9:03 am PST (Friday)
From: Ornstein.PA
Subject: ETP QUESTIONS
To: Stewart
I haven't gotten much done I'm afraid. Other distractions plus now I'm sick. What
I've thought about mostly is the synchronizing of the 8068 and either I don't
understand or there are some serious problems. After thinking about just a few of
these I'm inclined to flick it in and live with the 20% degradation of 4 MHZ
everywhere. I'm afraid the synchronizing/handshaking problems are a bag of
worms - see below. Then let's talk.
1. Is it true that with your scheme, wherein the Processor does the first input or
output from/to the 8068, we don't need the kind of address muxing shown in Fig
37 - because the chip only sees that one MAS? Do other devices need it (the
muxing)? (8274, 8251, 8259?)
2. I don't fully understand the need for the buffering of the AD bus to/from the
8068 (ENCAD) when it runs at 4 MHZ. Suppose, for example, the DMA is trying
to read something from the 8068 to memory. The 8068 stops the show (via
DMA0RDY) until it gets the IORD synced up to make MDS (or SDS) and has the
data ready. Presumably the DMA is giving the memory a giant long MWR while
it's waiting. When the DMA0RDY is finally given, it means the 8068 has its data
on the bus (the IORD got through the synchronizer and made an MDS at about
the same time DMA0RDY came on). So far presumably no problem, right? The
DMA will then shortly take away its MEMWR, and shortly after, the IORD, and
finally the DACK. I assume the problem is making sure the 8068 lets go of the
bus expeditiously for ensuing use? Presumably that's delayed because of the
synchronizing of the trailing edge of IORD to make the trailing edge of MDS
which then causes the 8068 to let go of the bus. In the meantime somebody else
might be trying to use the bus and the 8068n would be dumping onto it. For the
other way - DMA reading memory and writing to the 8068 - I assume the
equivalent problem is that the 8068 (because of the slownes in seeing IOWR go
away thanks to the synchronizing) might still be sucking data off the bus after
the memory quit sending (having more quickly seen the end of MEMRD)?
If these are really the problems, couldn't we fix them easier by making sure that
the trailing edge of IORD and IOWR somehow got around the synchronizers fast?
Anyway I don't understand how the flop enabling the 8282 outputs onto ENCAD
works. Presumably the latch is to hold the local (ENCAD) bus correct (for
writing into the 8068) - even after the rest of the world proceeds. Presumably the
IORD reset of the flop is to get such previously latched contents off the local
(ENCAD) bus for a later IORD of the 8068. But the IORD reset is unqualified.
What if the rest of the world goes on, following an IOWR to the 8068, to do some
other IORD. That'll kill the 8068's local ENCAD, which it maybe hasn't yet
finished putting away.
And what about the chip selects? They aren't synchronized. What happens
when they go away? (N.B. they aren't latched by MAS in Direct Control mode).
In fact it doesn't look like they HAVE to be (synchronized) for their onset -
since they only determine whether or not the chip will respond to the later
arriving synchronized IORD/IOWR. And maybe by having them not
synchronized, the chip automatically falls off the bus immediately when the
DACK disappears - apparently solving the problem discussed above.
3. In any case, I think we can't use ENCMASDACK or ENCSLVDACK just to DC
reset the DMA0RDY flop - since that will hold it reset despite efforts to turn it
back on once we've synchronized IORD (or IOWR). Not easy to fix. Might use a
JK flop and 4MHZ clock - turn it off (not RDY) when you see a
4MHZ-SYNCHRONIZED ENCMASDACK or ENCSLVDACK (must be synced or
will runt) But that syncing may be too slow a response to the DMA. In fact I
don't see any spec about how fast you have to have READY down (to the DMA)
after the IORD or IOWR. They just show set-up and hold times relative to the
DMA clock and it may be that if you take READY up or down asynchronously
with that clock, the DMA doesn't synchronize it.???
4. How can we be sure with our synchronizer that in worst case we don't violate
the max allowable width of MDS? It's an IORD synchronized to 4 mhz but I don't
see any upper limit on how long the IORD might be and in fact with our saying
not Ready, it will stretch way out, no? Will the Z8068 maybe get confused and
think that we're giving another MDS???
From all this you can see my state of confusion.
Welcome home.
S.
*start*
00837 00024 US
Date: 3 Nov. 1981 5:12 pm PST (Tuesday)
From: Swinehart.PA
Subject: Lark.GV
To: Birrell
cc: VoiceProject↑, Swinehart
Reply-To: Swinehart
I think I mentioned in passing once that it might be useful for the voice project to have a registry to play with. Possibly it won't be necessary after things have settled down, but I think it would be a lot safer during the development if we could keep our stuff out of the main stream.
So, would it be possible for you to create the registry Lark.GV, probably residing on Cabernet and Zinfandel, with owners Swinehart, Stewart, Owicki (and one of you ex-Officio, I imagine)? I do not believe we will be sending any messages directly to names in this registry, at least at first -- we'll mainly be using the authentication and the connect-sites.
Thanks,
Dan Swinehart
*start*
00990 00024 US
Date: 3 Nov. 1981 10:50 pm PST (Tuesday)
From: Stewart.PA
Subject: Memory bus data transceiver backwards
To: Ornstein
cc: Stewart
According to my 8286 data book, when the T (transmit) pin is HIGH, the A pins
are inputs and the B pins are outputs. On page one, MWR' is driving T, but the
B pins are on the memory side. We must either use MRD' for T or use the B
pins on the AD0-7 side.
Since the memories present less loading than all the junk we've got on the
processor bus, and since the B pins are beefier, i suggest we turn the transceiver
around, so that the A pins connect to BDATA and the B pins to AD0-7.
Incidently, if we do it that way, and we use the time difference between MEMR'
anmd IOW' on the DMA to provide the 8068 data hopld time, the transceiver
will not be turned off "early", rather the data won't become invalid on the AD
bus until a transceiver propagation delay after MRD' going high disables the
outputs of the memory chips.
-Larry
*start*
00628 00024 US
Date: 3 Nov. 1981 11:55 pm PST (Tuesday)
From: Stewart.PA
Subject: Bugs on page 38
To: Ornstein
cc: Stewart
On page 38, all the control logic for this scheme could be generated by a single
256 by 4 ROM. That would save a couple chips.
page 38 corrections:
MCS' should be GND, not SELENCMAS'. SELENCMAS' doesn't do anything
useful!
The gates generating ENCRDEN' and ENCWREN' have HLDA' as an input. That
should be the bubble input AND of HLDA and SELECMAS'.
Otherwise, if the processor does IO to some OTHER device while an encryption is
in progress, the 8068 would become de-selected.
-Larry
*start*
11236 00024 US
Date: 5 Nov. 1981 11:10 am PST (Thursday)
From: Stewart.PA
Subject: 8068 + 9517
To: Ornstein
cc: Stewart
This message is a series of notes about the encryption chip and DMA controller.
Some of them are copied from earlier messages
We want to use an 8068 encryption chip in an 8088 system. We need to have
DMA driven memory to memory encrypt and decrypt, "Electronic Code Book"
(block ciphering) only.
We would like to run the processor as fast as possible. Today that means 5 MHz,
limited by the 8237-5 (Intel version of AMD 9517. Fastest 9517 is 4 MHz.) and
by the I8259 interrupt controller. Someday, 8 MHz 8088's will be available too.
We can probably live with running the processor at 4 MHz as we do not need
the bus bandwidth (today) and probably will not be running the software within
20 percent of flat out (I hope).
1. Intel 8237/ AM 9517
Since the 8068 is so fast, we would like to give it a bus cycle priority higher
than that of the processor, but lower than any other DMA device. We plan to
encrypt blocks which are long enough to cause data-late errors on our other
DMA devices if the encryption ties up the bus. We plan to run everything in
"single-transfer" mode, so that the processor gets every other bus cycle and (we
hope) the DMAs re-arbitrate DMA request priority between every cycle.
We want to use, then, the two lowest priority DMA channels, one for
memory-to-8068 and the other for 8068-to-memory. The 9517 has a
"Single-transfer" mode that does a one byte DMA transfer each time the processor
grants the bus. The intended purpose appears to be to assure the processor gets
half the cycles. The 9517 data sheet does not say whether or not the 9517
re-prioritizes the DMA requests between such single transfers. Since the 8068 is
so fast, it will always be requesting. If the 9517 does not re-prioritize, the 8068
will lock out the higher priority DMA devices, causing data-late errors.
We have 7 DMA channels, 6 devices plus a cascaded 9517 (one of the other
devices also has built in DMA controllers, so that channel is also "cascade mode"
on the 9517). We want to use the same 8-bit latch for the high order address bits
for both 9517s. Does the 9517 assume that it has a private latch or does it
re-issue ADSTRB on each new byte (in single transfer mode) in case the other
DMA got in and changed the latch contents? (The same question applies when
the 9517 re-arbitrates and switches channels - it must reload the external latch in
such cases. The data sheet doesn't say.)
When you do a DMA transfer from memory to device, the 9517 says MEMR to
the memory and IOWR to the device, the data just flows down the bus. The
9517 appears to hold MEMR active longer than IOWR, providing some data hold
time to the device. How long? The only way to tell seems to be to subtract
TDCTR-TDCTW. I ask because the 8068 needs a very long hold time.
USE OF 8068
MAS': There appear to be no specs relating MAS' to the clock.
min max
32 MAS' width 80
34 MCS' low to MAS' high (CS setup) 0
35 MAS' high to MCS' high (CS hold) 60
36 Addr valid to MAS' high (address setup) 55
37 MAS' high to address invalid (address hold) 60
Ideally, we want to use the 8068 in single-port multiplexed control mode, so that
the processor could load the keys and set up the chip, then we could set up the
input and output dma channels for the actual ciphering operation.
Unfortunately, multiplexed control mode requires that MAS' latch one of the bus
bits (and MCS') to select an internal register.
8088 running at 4 MHz
min max
TCLCL clock period 250
TCLCH clock low 152
TCHCL clock high 85
TLHLL ALE width TCLCH-20 132
TLLAX addr hold after ALE, TCHCL-10 75
TAVAL addr setup to ALE low, TCLCH-60 92
So for the 8088 controlling the cycle, ALE works fine.
Now what about the 8088 controlled RD' and WR' signals? We would OR RD'
and WR' to create MDS' and use 8088 DT/R' for 8068 MR/W' (inverted)
8068 requirements on MR/W' and MDS':
42 MR/W' setup before MDS' low 100
43 MR/W' hold after MDS' high 25
44 MDS' width 200 1000
45 clk low to MDS' high 20 70
47 data setup before MDS' high 125
48 data hold after MDS' high 80
50 MDS' high to read data inval. (hold) 5
8088 RD' and WR' timing
TCLRH clk low to RD' high 10 150 OOPS
TCVCTX clk low to WR' high 10 110 OOPS
TWHDX data hold after WR' TCLCH-30 122
TCLDX-TCLRX data hold time for read 0 -140
DT/R' becomes valid very early, so ok on setup
TCHCTV+TCLCH-TCLRH ok if TCLRH and TCHCTV track (DT/R' hold time)
(I think it is usually fair to assume that a given chip has fast signals or slow
signals, but not a mixture, so TCLRH and TCHCTV probably do track. Should
ask Intel I guess.)
So it appears that the relationship between the 8088's RD' and WR' and the clock
is not strict enough to satisfy the 8068.
Now what about using the 9517A-4 to do DMA transfers with the 8068 in
multiplexed mode?
Problems:
There is no convenient source for MAS'. Suppose for the moment that the 9517
can be forced to issue an ADSTB for every cycle (see discussion above on the
9517 external latch). Since the 9517 is using the data bus for the high order
adress, we must provide a private copy of 8088 AD1 to 8068 pin MP1, which,
during ADSTB, we force LOW to address the data register. We use the
Memory-to-8068 DMA DACK to provide MR/W'.
9517A-4 times:
MR/W' setup and hold are OK:
TDCL DACK to RD' or WR' low 200
DACK appears to remain high after RD' or WR' high by a TCHCL time
or 69 ns. This is TAK+TCH-TDCTR
ADSTB timing (for MAS')
TSTL clk high to ADSTB start 150
TSTT clk high to ADSTB end 110
so ADSTB width is TCY-40 or about 210 ns
One thing to do would be to use the beginning of ADSTB to turn on the private
address going to 8068 MP1 and use the beginning of RD' or WR' to turn it off.
The hold time on the address for MAS' would then be TDCL-TSTT, or 90 ns
MDS' spec to CLK (9517 timings for IOWR' and IORD')
TDCTR clk high to RD' high 210 (127) OOPS
TDCTW clk high to WR' high 150 ( 67)
If the clock is high for exactly one third of 250 ns, then these times can
be referenced to clk low edge by subtracting 83 (in parens) so that WR' is OK,
but RD' may not be.
IOWR' width (extended) 2TCY-100 400
IORD' width (normal) 2TCY-50 450
(I am leery of subtracting specs. Why is the 9517 referenced to CLK high, while
the 8068 is referenced to clock low?)
Data hold time on writes to the 8068:
In our system, we have a bus transceiver between the memory data bus and the
multiplexed address/data bus that the processor, DMAs, and 8068 are on. In
DMA mode, the 9517 would say MEMR' to the memories and IOWR' to the 8068.
Since TDCTR is larger than TDCTW, the 9517 provides some data hold time. If
we subtract:
TDCTR-TDCTW data hold time 60 OOPS
however, this time is extended slightly because the end of IORD' disables the
memory chips, and then the trailing end of valid data has to propagate through
to the 8068 via the bus transceiver. According to Intel, the 8286 transceiver
might add 5 to 20 ns to the hold time, depending on loading. So it might work if
the subtraction procedure is valid!
Data hold time on reads from the 8068:
This does not appear to be a problem, since the memories have essentially 0 hold
time requirement.
Summing up, multiplexed mode problems:
8088 has trouble meeting the MDS' clock sync requirement (45). DMA has the
same problem. In addition, the data hold time on DMA writes to the 8068 may be
a problem.
The circuitry for creating the private address line is fairly ugly (see extra
page). If we give up a requirement to read from the master port, (we would not
be able to read the status or mode registers, and we would have to use dual port
mode always, with master port input and slave port output, then the extra
circuits are simplified slightly, since the gate to allow reading is not needed and
the private "bus" need not be tristate. (Actually, only bit 1 could not be read,
which would save some logic.)
Memory mapped 8068 does not seem feasible:
AMD made a suggestion that we operate the 8068 as a memory mapped device,
rather than as an IO device. We would then use the DMAs to do BLTs into and
out of the 8068. This would let the DMA provide the multiplexed address for the
8068, however, with the "private address line MP1" trick, we can do that with
the 8068 as an IO device.
1. This would take up 4 DMA channels, as two are needed for input and two
for output. Also, only channels 0 and 1 of the 9517 can be used this way.
2. There seems to be no way to hold the destination address fixed in such a
mode. One slight possibility would be to set up the DMA channel for a one byte
transfer in auto-initialize mode... (!!!) This would permit the memory-to-8068
DMA to run past the end of the requested block, since the 8068 pipe would be
kept full and the length of the transfer would be controlled only by the byte
count of the 8068-to-memory DMA.
3. Does single transfer mode work in memory-to-memory mode? If not, is the
8068 fast enough to always be ready when the DMA gets there? Also, if the
DMA must be in block mode, then our other DMA devices would be locked
out...
----------------------
Alternative Multiplexed control mode setup. The idea here is that only the
procesor will issue MAS' to the 8068 (See page 38). Thus the 8068 will be
permanently selected, with the selected register address being whatever the last
register addressed by the processor was. MDS' and MAS' will be carefully
qualified by address information elsewhere, so that only IORD' and IOWR' signals
intended for the 8068 actually get through. This idea requires that the processor
write the first byte of data to the 8068, to set up the register address, and the
"write" DMA handle the 2nd and later bytes. This scheme seems ok, but it
would make a mess of the software.
On page 38, all the control logic for this scheme could be generated by a single
256 by 4 ROM. That would save a couple chips, given a fast ROM.
----------------------
Other stuff:
When reset of 8068 is done by simultaneous MAS' low and MDS' low, is there a
clock sync. requirement? Time spec 6 implies that the reset must go away
syncronized to clk going high...
6 Clk high to (MAS' and MDS') high min 0, max 50 ns
we will have to add more syncronizers to meet this one, as our reset is generated
by a capacitor... (or is it synch'ed by the 8284?)
----------------------
As a parting comment, why does the 8068 have all these clock syncronization
requirements anyway? I would be happier if the algorithm machine inside the
8068 were synchronous and the processor bus interface were asynchronous. If
that were true, there would be no need to synchronize MAS', MDS' KEY/DATA,
and START to the clock. There would have to be some internal synchronizers
(preferably double synchronizers!) inside the 8068 to make the transition accross
the boundary, but at least they are hidden from the poor user! (me) It seems to
me that only a few signals, like "input register full" and "control register valid"
would need to be synchronized.
Larry
*start*
01101 00024 US
Subject: Re: AM 8068
PrintForm: WindowLetter
From: Stewart.pa
To: AMD
Date: 5 Nov. 1981 1:52 pm PST (Thursday)
Dan Fuller
Advanced Micro Devices
360 N. Sepulveda, Suite 2075
El Segundo, CA
90245 5 Nov. 1981
Dear Mr. Fuller:
Attached is the collection of notes I wrote about our problems with the 8068 and 9517. The schematics may be vague, but I think the gist of our troubles are sufficiently described in the text.
I just spoke with Subodh Banerjee on the telephone and he told me a very nice way to handle the address latching problem in multiplexed control DMA mode. The idea is to assign two I/O port addresses to the 8068. One of them generates MAS' and the other MDS'. This means that you must do an output to the "address" port to select the 8068 internal register for subsequent writes (reads) to the "data" address. In this way, the DMA transfers do not need to generate an MAS', since the processor will have previously set up the right register.
Sincerely,
Lawrence C. Stewart
cc: Subodh Banerjee (AMD)
Severo Ornstein (Xerox)
*start*
02148 00024 US
Date: 6 Nov. 1981 2:24 pm PST (Friday)
From: Ornstein.PA
Subject: Lark (Etherphone) Hardware Update
To: VoiceProject↑, Lampson, Taylor, McCreight, Thacker, Taft, Levin, Dalal,
Baskett, Schroeder
Reply-To: Ornstein
Larry and I have got the Lark hardware design beaten more or less into shape
and we're about ready to do layout. The DA system accepts (though not
gracefully!) the set of oddball chip shapes we've got. Within a week or so we
should be ready to have the board built - and then start debugging it.
The most apparently recalcitrant item in the design is the AMD encryption chip
which doesn't speak easily to the other stuff. (It's not clear they've ever hooked
it to ANY computer). We have surrounded it with a cloud of SSI which we hope
will make it happy (but may conceivably obscure problems). Our intention is to
charge ahead with this design in order to try to get at least the central items
working. Various chips (guess which) can be left unplugged until we're ready to
face them. That then will give us a Rev A board that will let Larry get started
on the software.
It seems certain that we will need to rework, improve (maybe even finish parts
of) the design and try out the changes before proceeding to quantity production.
To let us do that without disturbing the software development, we are planning
to build a second (Rev B) prototype board. (We're trying to do both boards in
such a way that they can eventually be stripped and reclaimed since the
underlying boards are scarce and expensive).
We can report that even macro-design with LSI items is a challenging business.
E.g. the designer of AMD's DMA-chip (of which Intel's is a copy) and who
apparently also had a hand in the encryption chip design, is now a student at
Harvard. When you ask deep questions you often get a guess for an answer.
Generally the documentation is VERY spotty - though some is really excellent.
For instance there is a wonderful discussion of synchronizer glitching (warmed
the cockles of my heart) in one of the AMD application sheets - written, of
course, by the guy now at Harvard.
Severo and Larry
*start*
00433 00024 US
Date: 6 Nov. 1981 4:46 pm PST (Friday)
From: Birrell.pa
Subject: Re: Lark.GV
In-reply-to: Your message of 3 Nov. 1981 5:12 pm PST (Tuesday)
To: Swinehart
cc: VoiceProject↑, Schroeder
I've create a "Lark" registry for you, with owners Swinehart, Stewart, Owicki.
The registry is on Cabernet and Zinfandel. Please be careful with it, and ask
Mike or me before you try anything you don't understand.
Andrew
*start*
00816 00024 US
Date: 8 NOV 1981 2109-PST
From: STEWART.PA
Subject: Auburntest help requested...
To: Swinehart
cc: Stewart
My program AITones, which I wrote because I didn't thing Auburntest
handled the DAA stuff, is capable of calling me on the
phone. It goes offhook and feeps at the phone line (4461), making my phone,
(4477) ring. When I answer, I can hear AITones feeping at me as I hit keys.
Auburntest can pick up the phone line, or answer it. When I call auburntest, I
can hear, pretty loud, the feeps, but when I ask Auburntest to call me it doesn't
work. As best I can tell, the tone tables are identical. The feep
frequencies are different in the LSB. I tried to make the clock rates
identical. What is happening? Does auburntest think there is an Alto crystal in
there?
-Larry
*start*
02576 00024 US
Date: 17 Nov. 1981 9:50 am PST (Tuesday)
From: Stewart.PA
Subject: Telephone switching
To: VoiceProject↑
Reply-To: Stewart
I thought this was a nicely written message. I wonder if our system will get this
complicated.
---------------------------
Date: 16 Nov 1981 2046-EST
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: Frankston at MIT-MULTICS
Subject: Newton No. 1 XBar, 110
The 969 exchange in Newton is No. 1 XBar. There are no SXS exchanges
in the Boston Metro dialing area. The acceptance of an infinite
string of 1s is a typical No. 1 and No. 5 XBar feature and has to do
with the early belief that an initial 1 pulse shouldn't do anything at
all. From 1921 Telco documentation:
The use of ... office codes starting with "1" is undesirable
due to the liability of a subscriber causing a "preliminary
pulse" when making a call. A preliminary pulse may be pro-
duced by an unintentional momentary interruption of the
subscriber's line at the switchhook springs after the re-
ceiver is lifted and before dialing is started, as might be
caused by accidentally striking the hook with the receiver.
In No. 1 XBars in places where the "1" is not used (and those places
are disappearing rapidly) an initial "1" does not even make the dial
tone go away.
"1" became used as an access code from SxS areas because it provided
an inexpensive way to send all "1" level calls to the toll switcher.
The SxS exchanges in the Bay Area which do not require "1" have a huge
kludge attached to them to properly process calls. This kludge is
quite unlike a director -- dialing "20" puts you right on a toll trunk
which takes the rest of what you dial. Similar kludges exist for SxS
in areas that have 1+ dialing and also 113 information codes: Dialing
"1" puts you on the toll trunk; the second "1" tears down the
connection to the toll trunk and puts you through to the selector
level for the "11x" services.
In No. 2 ESS, no similar kludges exist because the machine translates
what you dial via one, three, and six digit translate tables. "110"
does not get you the operator EXCEPT when you already have an operator
trunk active, flash for add-on dial-tone, and dial "110". Under any
other circumstance, "110" is an error. In No. 1 ESS, and probably in
No. 2 as well, it is a useful test to see if a trunk is the type trunk
which sends your number down the wire. Operator trunks, number read-
back trunks, and, in some areas, "911" trunks have this property and
all get flashed upon when you flash for add-on and dial "*0" or "110".
*start*
00539 00024 US
Mail-from: Arpanet host SU-AI rcvd at 20-NOV-81 1721-PST
Date: Friday, 20 Nov 1981 17:21-PST
To: Stewart at PARC-MAXC
Subject: 8086 hll
From: ly at ISL
------- Forwarded Message
Date: Friday, 20 Nov 1981 10:10-PST
To: ly at ISL
Cc: gill at ISL
Subject: 8086 HLL
From: gill at ISL
1. Pascal by Language Resources ($4800)
2. C cross compilers (Unix, RT-11, RSX, Unix 32/V, and VMS)
Advanced Digital Products ($1750)
If you can find the addresses or other info, let me know.
------- End of Forwarded Message