*start*
00459 00024 US
Date: 22 Dec. 1981 3:49 pm PST (Tuesday)
From: Ornstein.PA
Subject: Fast SLC Chips?
To: Stewart
cc: VoiceProject↑, Boggs, Ornstein
Reply-To: Ornstein
I just talked to Bob Markle's holiday substitute. He says Arnold Leon (tests SLC
chips - Intelnet phone: 8-823-7149 - works for Jim Reuter) will select some "fast"
ones and send them off to us early (Tues) next week. I tried to pursue the tester
speed question but got nowhere.
S.
*start*
00392 00024 US
Date: 22 Dec. 1981 5:12 pm PST (Tuesday)
From: Stewart.PA
Subject: Audio crystal requirements
To: Ornstein
cc: Stewart
If we go to an SLC clock of 12.288 MHz, then shouldn't we go to a 24.576 crystal
in order to divide by two and keep the 50% duty cycle? SHould we do this
anyway and add another jumper option to the board for which frequency the
SLC gets?
-Larry
*start*
01685 00024 US
Date: 23 Dec. 1981 10:13 am PST (Wednesday)
From: Stewart.PA
Subject: Re: Voice Box Analog Comments
To: Belleville, Gunning, Lau, NDSmith, Swinehart
cc: Ornstein, Stewart
I've just been reading Bill Gunning's memo of December 18. Everything seems
right except the premises...
1. The memo mentions that annoying clicks would be created when switching
from local power to CO power.
This seems quite true, but I think the only time such switching is done is when
the local telephone set is on hook.
The implication was that rather than use the two hybrids for local calls, one
would sense the hookswitch and then throw the relay to connect the telephone
directly to the CO. If it's done that way, there is no way to tell when the call is
finished, since the hookswitch sensing is gone.
My thought was that the telephone set would operate on local power and be
transformer isolated from the CO loop. The voice path would still be 2-wire, but
isolated from the CO. The curent in the telephone set loop would be sensed as
before for hookswitch and dial pulse.
2. The memo mentions that the DTMF tones would be too loud in the handset.
This is also true, but since the telephone set loop is local to the telephone
management unit, loss can be inserted before the telephone set while DTMFing
is in progress. (Loss should also be inserted on the telephone set side of the
isolation transformer while dial pulsing is in progress on the CO side of the
transformer -- to avoid clicks.)
If this scheme is adopted, there need be only one hybrid: to connect the 4-wire
part of the telephone management unit to the isolated side of the transformer.
-Larry
*start*
00582 00024 US
Date: 23 Dec. 1981 2:38 pm PST (Wednesday)
From: Stewart.PA
Subject: Lark prototype power
To: VoiceProject↑.pa
cc: Stewart
Reply-To: Stewart
I've rewired the Lark prototype to run off a single three voltage power supply.
It takes:
+ 5 volts: 2.2 A
+12 volts: 200 mA
-12 volts: 60 mA
including the rudimentary analog stuff and 16K bytes of memory. This adds up
to about 13 watts I think. I suppose we should get +5 at 5A and +/-12 at 1A
each for the production models.
I added a small regulator circuit to construct -5 from -12...
-Larry
*start*
02070 00024 US
Date: 23 Dec. 1981 5:25 pm CST (Wednesday)
From: Killen.DLOS
Subject: Downloading & Debugging
To: SunriseForum↑.dlos
cc: Stewart.pa,Killen
Reply-To: Killen,Stewart.pa
Larry,
Comments are hereby also solicited from the Sunrise Forum.
SunriseForum,
Those of you who have been considering using the net as a development tool,
two things:
1. I think that Larry's ideas might be useful for us, and
2. Roy Ogus and Co. in PA have told me where an 8085 assembler lives ..
one that runs on DLions, in particular. I know not if it will run on
any lesser device such as an Alto but will ask.
Is anything beginning to take shape here ?
Don
---------------------------
Date: 23 Dec. 1981 2:31 pm PST (Wednesday)
From: Stewart.PA
Subject: Remote debugging etc.
To: CommunicationProtocols↑.pa
cc: VoiceProject↑.pa, Stewart
Reply-To: Stewart
I'm building an 8088 system, and have been debugging it and downloading
software via 1200 baud RS-232. This is quite unsatisfactory. I have finally got
the Ethernet connection working and I want to start debugging and downloading
via network.
I've taken a look at the available protocols:
Teleswat (Alto/bcpl):
Only uses 16 bit addresses. (8088 is a 20 bit machine)
Can only store 1 word at a time. (rather slow for downloading)
Teledebug (Mesa/Pilot):
Only fetches/stores a page at a time (256 words!)
If these are the only options, I'm going to write a new one....
I've been trying to think of ways to fit more machine dependent stuff into the
aegis of Teledebugging. For example, loading and reading processor and I/O
controller registers.
Possibilities:
Send across chunks of code and then execute them (we used to call this
the flying subroutine).
Build register dump and load into the debug kernel and read and write
the appropriate chunk of memory. (Doesn't work for I/O registers if there are
very many.)
Add a MachineType? message to the protocol and have machine
dependent messages.
Comments anyone? -Larry
------------------------------------------------------------
*start*
00674 00024 US
Date: 23 Dec. 1981 4:57 pm PST (Wednesday)
From: Deutsch.PA
Subject: Re: Downloading & Debugging
In-reply-to: Killen.DLOS's message of 23 Dec. 1981 5:25 pm CST (Wednesday)
To: Stewart
Cc: Killen.DLOS
I haven't actually ever tried to do teledebugging, but it seems to me that given
what the world looks like these days, you want something like the following:
- read or write N words starting at location A. 16-bit words, 32-bit
address.
- whatever is appropriate for firing up control and returning control on
breakpoints
Flying subroutines seem like the most plausible way to handle machine registers
'cause they're different on every machine.
*start*
00343 00024 US
Date: 23 Dec. 1981 5:39 pm PST (Wednesday)
From: Stewart.PA
Subject: Compiler bug
To: Duvall
cc: Stewart
[Maxc]<Stewart>TestCalls.c
the code
extern char foo();
char c;
main()
{
c = foo();
};
causes the compiler to generate
CALL ←foo;
MOV ←c,AL;
In all other cases, the result is expected in BL/BX...
*start*
00289 00024 US
Date: 24 Dec. 1981 1:45 pm PST (Thursday)
From: Boggs.PA
Subject: Re: Remote debugging etc.
In-reply-to: Your message of 23 Dec. 1981 2:31 pm PST (Wednesday)
To: Stewart
cc: Boggs
I don't think it's worthwhile to try to use an existing protocol.
Design your own.
*start*
00497 00024 US
Date: 27 DEC 1981 2339-PST
From: STEWART.PA
Subject: Echosrv.c
To: Boggs
cc: Stewart
Got it working around 10 pm. Still working at 11:30...
I think I've discovered another disconcerting SLC feature.
Apparently the controller status register goes to "idle"
somewhat BEFORE the status byte in memory indicates
completion. I wound up with a routine that analyzes
a running ccb chain and figures out whether it has
stopped, and if so, whether it worked or not.
-Larry
*start*
00464 00024 US
Date: 28 DEC 1981 0927-PST
From: MCDANIEL
Subject: Remote debugging
To: Stewart
CSL will purchase a board tester (from Fluke Co.) that has an 8086 with
multibus interface. Chuck Thacker) and I want to be able to
download the 8086 from the Ethernet. Consequently I'm very interested
in what you propose to do. I'd be willing to write some Mesa code if
you're willing to do the 8088 code. How different would the
8086 stuff be?
Gene
*start*
00523 00024 US
Date: 28 Dec. 1981 9:28 am PST (Monday)
From: Stewart.PA
Subject: 8051 environments
To: NDSmith, Belleville, Lau
cc: VoiceProject↑.pa, TonyWest, Stewart
Page 14 of the December 21, 1981 issue of "Electronic Engineering Times," has an
advertisement in the upper left corner for a CP/M based 8051 development
environment. Includes macro assembler, editor, and downloader. $150 on 8" soft
sectored CP/M floppy.
If it runs on a suitable 820 this might be worthwhile for us if not for you.
-Larry
*start*
00745 00024 USm
Date: 28 Dec. 1981 5:04 pm PST (Monday)
From: Ornstein.PA
Subject: To Whom. . .
To: Rider.ES
cc: Stewart, Ornstein
. . . should we talk about the SLC? We have it working but have some
complaints, suggestions, and questions concerning how it works, its
documentation, etc. It may be that we need to contact several different people for
these various matters. We are particularly interested to talk to anyone who has
actually done some application (non-test) programs that actually use the SLC.
Whom do you recommend?
Yours with Christmas cheer,
Severo
P.S. You'll be pleased to know that it looks like a bad day in L.A. out my window
- and smells like it too (I understand they're mucking about with roofing tar...).
*start*
00718 00024 US
Date: 29 Dec. 1981 11:19 am PST (Tuesday)
From: Stewart.PA
Subject: Lark design notes
To: Ornstein
cc: Stewart
I got to thinking. . .
Page 1: We may be able to save a package of N125s by simplifying the MRD'
MWR' IORD' IOWR' stuff. I don't think that we need to generate separate IO and
M signals because only the processor talks to IO and that case is already taken
care of since MemSel' is part of the enables for the IO address decoder.
Those chips that the DMAs talk to are ONLY talked to by DMA so they can
receive separate nets: DIOWR' and DIORD'.
The Western digital chip is a problem, because it is talked to by both the
processor and the DMA. It is the only such chip
-Larry
*start*
00375 00024 US
Date: 29 Dec. 1981 11:26 am PST (Tuesday)
From: Stewart.PA
Subject: Lark design notes (2)
To: Ornstein
cc: Stewart
I got to thinking. . .
We could change the 7474 DREQ flops to use a (4 section) 74279 if we had a
pulse that occurred after TSN. We could use framesync if we changed to use a
time slot near the end of the frame, say 20-24.
-Larry
*start*
00345 00024 US
Date: 29 Dec. 1981 11:29 am PST (Tuesday)
From: Stewart.PA
Subject: Things to buy
To: Ornstein, Swinehart
cc: Stewart
Echo canceller, modified for longer tail circuit. Digital input and output?
Text to speech board to hook into our system so that Thrush can talk to us: "You
got a message from X at time Y."
-Larry
*start*
03212 00024 US
Date: 29 Dec. 1981 3:44 pm PST (Tuesday)
From: Ornstein.PA
Subject: Etherphone
To: Belleville
cc: Ornstein, Swinehart, Stewart
Bob,
We'd like to get together with you after you've had a chance to read this
message. We'll give you a day or so and then will call to arrange a chat.
We want to discuss two closely related items regarding the analog side of our
Etherphone design. We presently have one "working" proto-prototype
Etherphone. I say proto since we are doing some redesign, probably including a
second processor to help with signal processing issues such as silence detection,
merging of simultaneous speech from more than one source during conference
calls, etc.
As you know, we have been hoping to use your voice box - for analog
switching, for connection to the handset, the phone line, etc. The first item we
want to discuss with you is a reflection problem that, because of delay, is much
more serious for us than for you. The second item concerns the schedule for the
50 or so "production" units we are planning to build for trial use in CSL.
1. Reflection concerns
For the present Larry has cobbled up a Codec that allows us to use a handset
and test things out. What we are concerned about is whether, when we have the
full hybrid connection to the phone system, we are going to have troubles with
reflections of delayed voice. Consider what happens when an "outside" call
arrives at an Etherphone and gets forwarded to another Etherphone. The outsider
has no special reflection problems but the inside recipient's voice will travel from
the phone he's at, through the Ethernet to his own phone (on its way to the
caller) and will there bounce off the hybrid and come back (through the
Ethernet) to his ear - some 80 ms. later. It seems likely that there will be enough
reflected delayed signal to be annoying. Up to a point the better the hybrid, the
less the problem but it may well be that even the best hybrid isn't enough and
that we will have to build some sort of echo-suppression into our part of the
Etherphone. Mostly we just want to make you aware of this problem so that
where possible you can take it into account.
2. Schedule
Let's assume that the hybrid problem has been solved and there are no technical
problems with our using your box. We are shooting for an April1 1 date to start
making 50 Etherphones (for July 1 delivery) and are wondering how well your
schedule is going to match ours.
As we see it we have the following four options - listed in order of increasing
pessimism about your rate of progress:
1. Use production copies of your box (perhaps without the tape recorder
but otherwise as-is). This is our option of choice because it is simplest for
us - although it makes a 2-box system and we get slightly more than we
want.
2. Assuming that you won't have production models in time, we could
try to get a second run of 50 of your "prototypes".
3. We could just use your PC board design and worry about packaging it
ourselves.
4. We could steal your design and adapt it for our own use, making
whatever changes and simplifications seem advisable.
We'll call you shortly to discuss these matters.
Severo and Larry
*start*
02244 00024 US
Date: 29 Dec. 1981 4:00 pm PST (Tuesday)
From: Ornstein.PA
Subject: Re: Hybrid notes
In-reply-to: Stewart's message of 29 Dec. 1981 12:59 pm PST (Tuesday)
To: Stewart
cc: Ornstein, Swinehart
I don't think we can "get someone else to work on this stuff in the ways we
would do it if we had free time" unless they joined the team. Committment is
committment and anyway they'd be in the middle of our lap.
My inclination is like yours to "exert a modest level of effort to obtain as good a
hybrid as we can and add some amount of gain reduction (via our processor) to
implement essentially echo supression". If this doesn't work it would seem to
mean that system studies of better forwarding methods are out the window. I
think we should know this before we commit to a production run.
Seems to me we have three choices.
1. IGNORE THE PROBLEM
We could decide that for this generation of Etherphones we will
under no circumstances try to do more than gain reduction - i.e. be
prepared to forget forwarding (does this also mean no attendants?) if
gain reduction is an inadequate cure for the reflections.
2. PRAY FOR A MIRACLE
We can proceed now with the redesign and try out gain reduction as
part of our three-prototype, pre-production exercises - deciding when we
hear the results whether a further redesign involving a more powerful
signal-processing processor is called for.
3. DO FURTHER STUDY
We could conduct an experiment right now that would tell us how well
the "echo supression" works. If it works OK then we could proceed with
the redesign knowing that. If it's terrible, we could decide either to accept
the fact (and forget forwarding) or bite the bullet and take the time to
incorporate the more powerful signal-processing processor
I guess we've decided to do #3 since we're no good at prayer or closing our eyes.
If we continue to think having an echo-canceller is a good idea, and we have a
plan for who's going to do what with it when it arrives, then we should order
one. I like the modular, Etherphone-based POTS server idea but I can't see any
of us doing much with it in the near future. Seems a nice separable thing if we
ever get another full-time member of the team.
S.
*start*
03441 00024 US
Date: 29 Dec. 1981 3:49 pm PST (Tuesday)
From: Ornstein.PA
Subject: Etherphone Status Report
To: Taft, Thacker, Lampson, Levin, McCreight, Schroeder, Dalal, Baskett, Taylor,
Boggs
cc: VoiceProject↑
Reply-To: Ornstein
This is really only about the Etherphone hardware.
The prototype has successfully passed the first hurdle: we can speak into a
phone, the voice is digitized, encrypted, sent out (via the SLC) on the 1.5 MB
ethernet to our special Gateway (thank you David) where a little reflector
program sends it back, it is received (via the SLC again), decrypted, reconverted
to analog and sent to the speaker's ear where it sounds great; three cheers for
Larry Stewart for lots of excellent work.
We are presently reviewing the current design and are considering adding a
second processor which will give us the additional power to do a little signal (i.e.
per-data-byte) processing. This allow us to try out:
1. various silence-detection algorithms and
2. the merging necessary to deal properly with more than one person
speaking simultaneously during conference calls.
We might try to squeeze these out of the 8088 but are reluctant to box ourselves
into (for example) having to write tight assembly level code. To be sure we had
enough cycles for the main program, we carefully avoided requiring the 8088 to
handle the data on a per-byte basis - and we prefer to keep it that way.
There is another problem area that may well also require some signal processing
capability. This has to do with reflections arising from the "back door" interface
to the regular phone line. Consider what happens when an "outside" call
arrives at an Etherphone and gets forwarded to another Etherphone. The outsider
has no special reflection problems but the inside recipient's voice will travel from
the phone he's at, through the Ethernet back to his own phone (on its way to
the caller) and will there bounce off the hybrid interface and come back
(through the Ethernet) to his ear - some 80 ms. later. It seems likely that there
will be enough reflected delayed signal to be annoying. Up to a point the better
the hybrid, the less the problem but it may well be that even the best hybrid
isn't enough and that we will have to build some sort of echo-suppression into
the Etherphone. This is another reason to have some per-byte data handling
capability on board.
The point of all this is to say that while things are going along very well, there
are still hard "telephonish" problems lying ahead that could cause us
considerable grief, not to say delay. The redesign we are now doing is a hedge
against such problems and if it proves adequate, we should remain on schedule
and be able to start quantity (~50) production of Etherphones in April. We are
going to implement the redesign in our first prototype before proceeding to build
the next two prototypes. (We believe we need two more to enable us to try out
all features and configurations). These next two will be built on our forthcoming
Multibus boards. After we get the three prototypes working in conjunction with
the Thrush Etherphone server, we will be in a position to decide whether we
can significantly simplify the design for the "production" run. We are starting to
think about packaging, pwr. supplies, etc. and hope to "subcontract" this to
someone (perhaps to Mike Overton if Chuck thinks he's appropriate).
Severo
For the Voice Project
*start*
11664 00024 US
Date: 29 Dec. 1981 5:07 pm PST (Tuesday)
From: Stewart.PA
Subject: SLC notes
To: Swinehart, Ornstein
cc: Stewart
Old notes:
How many consecutive cycles does the SLC take in DMA mode? We are
cascading the SLC through an 8237 which we think does not enforce single
transfer mode when cascading.
Suppose the SLC ran faster (e.g. 3 Mb). What would that do to the timing
requirements on the processor side? Does it make the Read and Write pulses
shorter in an always READY system?
Page 45 of (some version) of the SLC spec remarks that Holda may be dropped to
hint to the SLC to give up control of the processor bus. What synchronization
requirements are there? Page 57 gives some marks on the timing diagram, but it
is in terms of SSB timing and the internal clock, not the external world.
Nowhere have we found any information on the internal register addresses of
the SLC. What registers are there and at what addresses? What requirements are
there for which piece of processor address space is occupied by the SLC?
There is a remark that when chaining, a ccb must specify at least a 7 byte data
transfer. Does this refer to the ccb before the chain or to the one after the
chain? Can the final ccb of a chain specify less than 7 bytes?
What about inserting an indirect ccb in the middle of a chain? Can a transmit
chain include an indirect ccb "in the middle" of a single outgoing packet?
Does the SLC set the status field of a ccb to 0 as it begins the processing of a ccb
and then set it again when the ccb is finished? Does the processor have to clear
the status byte before submitting the ccb to the SLC? Does this mean that in a
ring buffer set up for receiving that the processor must "chase" the SLC
handling packets and clearing the status bytes? (Otherwise the processor
couldn't tell which ccb the SLC was working on.)
New Notes:
Documents:
Integrated Circuit, Shared Line Controller (SLC) 733W02237
Shared Line Controller (SLC) Functional Specification 156P11875
Input/Output Processor Macro Functional Specification 156P11194
Shared Line Receiver and Transmitter Functional Specification 156P11197
Reading from the addresses 4n+1 and 4n+2 in the SLC return CBAH and CBAL
respectively. Do they return the current address, the original address, or the
"next" address. Can the processor read these registers in order to find out what
the SLC is doing? What happens when there is a carry accross a 256 byte
boundary of the 16 bit CBA? Could the processor read one byte before the carry
and the other after the carry? Is it atomic?
(Operational experience is that after the SLR is started, but before a packet comes
in, the IOPR registers point to the cound field of the ccb. After a packet has
come in, the CBA points to the byte after the status byte.)
Does the SLT depend on getting a collision indication during the first 1 or 2
bytes in order to backoff and retry? Or is a collision near the end of a packet
transmission cause a retransmission from the beginning?
The pin IO/NM is quoted as sometimes being a mask option. Is it or isn't it in
the chips we've got? P. 34 and p. 37 of the SLC FS seems to say that IO/NM is
ignored on input and always low on output (DMA), while p. 11 says there is an
option.
Page 37 of the SLC FS says NCS ignored during DMA cycles.
Page 43 of the SLC FS says that DOut goes to HI-Z during system reset. This has
the effect of jamming the Ether until either the transceiver cuts off or system
reset goes away. Dout may STAY HI-Z up to 3T+100ns after NRESET goes high,
so it would be hard to gate off DOut during RESET.
Page 40 of the SLC FS says Hold goes Hi-Z while NRESET low. Does this cause
us any trouble?
Page 18 of the IOP FS says that a 7 byte transfer is needed to avoid data lates on
chaining. Doesn't this depend on the device data rate? What will happen with
the Ether running at 3 Mbit/s?
When using the IO interrupt, must the IO bit be turned on in all ccbs? What
will happen if an unusual end happends in a ccb with IO turned off?
In the last ccb of an auto chain, does the 08H bit, (Auto/skip) have to be turned
on? (Operational experience is that if not, then the status byte is stored as
though it was a 5 byte ccb rather than a 3 byte ccb. I don't know what
happened to the data address field, whether it was used or skipped.)
When an SLR ccb starts with a count field of zero, the interpretation is that
there is 256 bytes of space available. The count increments to zero or when a
packet ends, the SLR stores the count back into the ccb. By starting at 0, the
size of a packet can be found by count ← IF ccb.count=0 THEN 256 ELSE
ccb.count; What happens if the initial value of the SLR ccb count field is not
zero? Does this indeed tell the SLR that less space is available? What value will
be stored back a) on end of packet. b) after the allow number of bytes are used
up. Is the correct calculation count ← IF ccb.count=0 THEN -initialcount ELSE
ccb.count-initialcount; ?
Does the store-back of the count fields in the input and output-unusual-end
cases mean that the processor must re-initialize those ccb fields before reusing
the ccb?
I don't understand the interaction of Auto/Skip and Indirect given on p. 19 of
the IOP FS.
IOP FS p. 25 (top) Does the IOC set the ccb status byte to zero as it "enters" a
ccb?
(We have noticed that HIO doesn't work on an SLR which has been started but
which has not gotten a packet.)
IOP FS p. 27 What does the "(MMIE = 1)" note in the HIO box mean? Does this
mean that message mode interrupts must be enabled before HIO works?
Is it possible that HIO is not effective until a transfer is in progress?
Does it work to try and receive a packet exactly 256 bytes long? (or exactly the
length of an input ccb).
IOP FS p. 32 "One OR MORE (emphasis mine) messages may be contained in a
single ccb." What does this mean? When we use the SLR and a packet
completes in the "middle" of a ccb. The count is stored and the SLR startes up
again on the next ccb, not the same one.
There are a couple of comments that IO and MM interrupts should not be used
together, yet there seems to be no hardware reason why not -- there are separate
bits for the two kinds of interrupts. Is this advice? One "should not" use them
together because it doesn't make sense?
IOP FS p. 48 There is a flowchart which implies that after an IO interrupt
without a "valid end" bit, one must execute an HIO before checking. What is
the correct interrupt handle sequence for AIO, HIO, RIO, etc?
The code on page 49 that supposedly implements the flowchart does not match
the flowchart.
IOP FS p. 58. The ring buffer example flowchart may hold clues to the
combination of indirect and auto/skip, ccb bits, but there is at least one type in
the code.
SLRT FS page 22 says that "Message End" has to do with ccbs and that ME=0
means message aborted. Is this true?
SLRT FS page 25 flow chart for the SLT seems to say that collisions after the first
2 bytes have been transmitted are fatal (no retry attempt). This makes sense
since there are two bytes of buffering in the SLT ina ddition to the FIFO.
Perhaps the FIFO cannot be backed up!
Since the SLR has some buffering before data enters the FIFO, the SLR could
reject packets shorter than a certain length (runts). DOes it?
SLRT FS p. 38. There are three signals between the SLR and the SLT: Carrier,
Collision, and TestData (SLRTD). What is SLRTD for? Is there some kind of
loopback test?
SLRT FS p. 39 The description of Message End statuys says that ME is set at the
end of a single ccb or chain of ccbs. Does this mean that one cannot queue
multiple packets in the same ccb chain? Why doesn't ME mean "Packet end"
rather than ccb end?
Figure 5-4 says that 00x0 turns off the SLR/T, but also says that 10x0 turns off
the SLR/T "at the end of chain". Isn't 10x0 always the end of a chain?
SLRT FS p. 41. ID address is the source for SLT packets. Does this mean that the
SLT substitutes this value for the 2nd byte of outbound packets? Or does it us
the value in memory, whatever it is?
SLRT p. 42 recomments initializing the SLC by
Load ID
Load SLR mode
Load SLT mode
Start SLR
Start SLT (when packet ready to go)
Is this a required initialization sequence? What can be done differently?
SLRT FS p. 43 describes the IOCT/R as using 24 bit ccb addresses and the Pinout
of the SLC is all wrong.
All the code examples use 24 bit addresses.
SLRT FS p. 48 advocates use of a count field fvalue of 01 for SLR mode setup.
Should'nt this value be FFH since the IOCR increments the count? What should
the count field be for LOAD ID?
SLRT FS p. 49 example of multi-ccb message transmit uses Transmit Message in
the first ccb and Transmit Segmented Message in the second ccb, while on page
51, it is the first ccb that uses Transmit Segmented Message and the second
which uses Transmit Message.
Other comments and questions:
HIO doesn't seem to do anything to the SLR. I wanted to receive a potentially
554 byte Pup, so I set up a 3 ccb chain for the SLR. After receipt of a short Pup,
the SLR went on and started working on the later ccbs. HIO didn't stop it. I
used RIO and completely reinitialized the SLR after every packet.
Does RIO work the same way as system reset? Can I safely use RIO without
reloading the ID and SLR mode? (I checked briefly and it seemed that RIO did
not clear the ID register, but I didn't trust it.)
What should the count ccb fields be set to when loading the SLR ID and Mode?
Is it ok to build a ccb chain to load both the SLR ID and Mode? Is it OK to have
these initialization ccbs in ROM? If in RAM, will the SLR change any of the
fields?
Initializing the SLR while the SLT is transmitting a packet causes Message
Aborts (ccb status E4H). It shouldn't do that should it? How much coupling is
there between the SLR and SLT?
The SLT status register seems to go to condition code available well BEFORE the
status field of the last ccb has been filled in. It shouldn't do that should it?
How does one tell when the SLR and SLT are really idle?
Areas about which I'm confused:
Does it take less time to handle a 3 byte ccb than a 5 byte ccb? Does this
change the 7 byte minimum transfer?
I think I want to use a ring buffer for the receiver and message mode
interrupts. Is a MM interrupt really for "packet complete"? How does the
processor tell where in a ccb chain the SLR is? There is a comment that the
processor must field MM interrupts as fast as they are generated, because if the
processor doesn't issue a CMI before the next one happens it will be missed. This
may happen if short 'runt' packets are not filtered out by the SLR. If it does
happen, the processor could fall farther and farther behind the SLR in running
around a ring buffer. Is the MM only a hint then? Should I use IO interrupt?
On each interrupt, the SLR interrupt handler will have to follow around the ring
of ccbs until it gets to the last ccb with status filled in. It will have to clear the
status as it goes. Will this scheme work?
In the ring buffer, what happens if a packet being received falls accross the
region of the ring with the indirect ccb? Will it work correctly?
What does MM interrupt mean in the SLT?
What is HIO for?
Can the SLR receive back to back packets? When the ccbs are 5 byte? 3 byte?
separated by an indirect ccb? How close can packets be to one another?
Documentation doesn't say anywhere that addressing nonexistant registers in the
SLC hangs the system forever.
We could use examples of operational SLC drivers.
-Larry
*start*
02476 00024 US
Date: 29 Dec. 1981 12:59 pm PST (Tuesday)
From: Stewart.PA
Subject: Hybrid notes
To: Ornstein, Swinehart
cc: Stewart
McCreight says 10 dB is straighforward, 20 dB is quite hard.
My own experience has been that McCreight is about right and that hybrids are
easy to adjust at one frequency. I've never set up to either measure the line
impedance accross the audio band or to tune for the best overall performance.
The phone company chart says that we should have 30-40 dB return loss for 80
ms delay.
I think the eventual 'correct' solution is a digital echo canceller for each outside
connection. That will have to wait until we buy or design a chip to do it. In
the meantime, we should exert a modest level of effort to obtain as good a hybrid
as we can and add some amount of gain reduction (via our processor) to
implement essentially echo supression.
We may want to buy a few echo cancellers modified for longer tail circuit length
to check out that cancelling will really work.
If we did have a programmable digital signal processor for each etherphone, then
we could have it do echo cancelling, fancy silence detection, smoothed gain
changes, AGC, good speakerphone, conferencing, etc. (An echo canceller makes
a tremendous speakerphone.) If we were to design the analog stuff to use in a
couple of years it would digitize everything and do digital processing and
switching. We would also boost the voice data rate and provide better quality.
We should explain the situation to Belleville's group -- that excellent hybrid
performance is important for tandem connection of a 2 wire outside phone line
and an ethernet voice connection. (The better the hybrid, the less echo
supression will be needed, hence the better the quality will be.)
Remember that we can only have our OWN hybrid if we do our own analog
stuff. If we did the hybrid research soon, we might persuade Belleville to
incorporate it into his box.
I suspect that it is not worth much of our (three's) time in the near future to
work on this stuff. We are much too busy and even a 20 dB hybrid wouldn't
make the problem go away.
If we were to have a month free and the inclination to work in this area, I think
we could make a fairly good adaptive hybrid. I don't know if it would be
substantially better than the non-adaptive one that would take a week.
How can we get someone else to work on this stuff in the ways we would do it
if we had free time?
-Larry
*start*
04669 00024 US
Date: 30 Dec. 1981 11:45 am PST (Wednesday)
From: Stewart.PA
To: VoiceProject↑.pa
Subject: 8088 Bus throughput letter to ED
Subject: 8088 Bus throughput
PrintForm: WindowLetter
From: Stewart.pa
To: John Puvogel
Date: 30 Dec. 1981 10:47 am PST (Wednesday)
John Puvogel
LSI Component Engineering
RTG/ED/EED/C&CE
ESDS A2-18/8*823-7664
30 Dec. 1981
Dear John:
Thank you for your memo of November 25 about bus throughput on our 8088
system. Severo's and my impression is that a cycle balancer would not
significantly improve the performance of our system. Let me explain my
reasoning.
Our system includes six DMA devices: three for voice, two for encryption, and
one for the SLC. The three voice DMA channels are connected to one 8237-5
which in turn is connected to a port of a second 8237-5 (in cascade mode). The
SLC uses another port of the second 8237-5 (also in cascade mode). The two
encryption DMA channels, one for the encryption device input and one for
output, are connected to the remaining two channels of the second 8237-5.
Let us first look at the voice channels. Each requires a one byte transfer 8000
times per second, or every 125 microseconds. There is no additional buffering in
the voice circuits, so the voice DMA must be done in a 'single cycle' fashion.
The total voice DMA load, both peak and average, is 192,000 bits/second,
transferred in 24,000 separate DMA cycles of 6 T-cycles each. If we added
additional voice buffering (2 FIFOs perhaps) the cycle balancer could be used
here, but the DMA load is not that high and our judgment is that the
performance gain is not worth the added logic.
Now look at the SLC. In our system, the SLC throughput will be 150,000 -
175,000 bits/second (100 messages/second, each of about 200 bytes). The peak
data rate is 1.5 Mbit, which would require an 8 bit transfer every 5.3
microseconds. Since the SLC has 16 bytes of buffering, it seems possible to use
something like a balancer. The trouble is that it would require additional
circuitry to decide when the SLC had accumulated enough data to fill out a
burst. We don't have enough information about the DMA request behavir of the
SLC to evaluate it very well.
The final case is the encryption device. The total load is slightly under 300,000
bits/second -- all SLC traffic is encrypted, and must both be read from and
written back to memory. We had designed our system to handle either the
Advanced Micro Devices AmZ8068 or the Western Digital WD2001. The AMD
part is sufficiently fast that it would use up the entire bus bandwidth of our
system if unrestricted. We felt that the 8237-5 single transfer mode would be a
useful way of restricting the encryption device to at most half the bus
bandwidth. As you point out, the balancer achieves the same ends. It uses more
logic, but saves cycles.
In fact, we have never tried the AMD part. We have been using the WD2001
because the external logic required was much simpler and because we felt it
would be fast enough. Our test program, counting the key load and DMA setup
time for 160 byte blocks, can encrypt at about 640,000 bits/second, using a total
of 1.28 Mbit/second of bus bandwidth. The WD2001 turns out to be much less
heavily pipelined than the AmZ8068, so that the encryption of a single 64 bit
DES block involves loading 8 bytes, some number of cycles of algorithm
operation, and unloading 8 bytes. We have been able to use demand transfer
mode on the encryption channels of the 8237-5 and essentially achieve 8 byte
DMA bursts without extra logic. (In fact, it seems to be taking a burst of 8
single transfers in any event! The WD2001 Request line, which we have wired
to DMA Request, becomes inactive for the duration of the WR' pulse. The 8237-5
seems to catch the momentary ionactivation of the request signal and release the
bus. It would be more correct to say the the WD2001 would operate in an 8-byte
burst mode if we solve this request inactivation problem.)
Summing up, it seems to us that thecycle balancer might provide some advantage
for the SLC, but not for our other DMA loads. Further, we think that even if
we could apply the balancer to all the DMA devices, the total DMA load, about
667,000 bits/second, is not a significant fraction of the 10,000,000 available bus
bandwidth. (Using 6 T-cycles for each of the DMA transfers, this translates to
about 1 Mbit of the bus.) Even if all devices used a balancer, the advantage
would be about 26% of 10%! We would only gain a 2.6% improvement in
system throughput.
Sincerely,
Lawrence Stewart
cc: S. Ornstein, PARC/CSL
R. Quinn, A3-31
*start*
04545 00024 US
Subject: 8088 Bus throughput
PrintForm: WindowLetter
From: Stewart.pa
To: John Puvogel
Date: 30 Dec. 1981 10:47 am PST (Wednesday)
John Puvogel
LSI Component Engineering
RTG/ED/EED/C&CE
ESDS A2-18/8*823-7664
30 Dec. 1981
Dear John:
Thank you for your memo of November 25 about bus throughput on our 8088
system. Severo's and my impression is that a cycle balancer would not
significantly improve the performance of our system. Let me explain my
reasoning.
Our system includes six DMA devices: three for voice, two for encryption, and
one for the SLC. The three voice DMA channels are connected to one 8237-5
which in turn is connected to a port of a second 8237-5 (in cascade mode). The
SLC uses another port of the second 8237-5 (also in cascade mode). The two
encryption DMA channels, one for the encryption device input and one for
output, are connected to the remaining two channels of the second 8237-5.
Let us first look at the voice channels. Each requires a one byte transfer 8000
times per second, or every 125 microseconds. There is no additional buffering in
the voice circuits, so the voice DMA must be done in a 'single cycle' fashion.
The total voice DMA load, both peak and average, is 192,000 bits/second,
transferred in 24,000 separate DMA cycles of 6 T-cycles each. If we added
additional voice buffering (2 FIFOs perhaps) the cycle balancer could be used
here, but the DMA load is not that high and our judgment is that the
performance gain is not worth the added logic.
Now look at the SLC. In our system, the SLC throughput will be 150,000 -
175,000 bits/second (100 messages/second, each of about 200 bytes). The peak
data rate is 1.5 Mbit, which would require an 8 bit transfer every 5.3
microseconds. Since the SLC has 16 bytes of buffering, it seems possible to use
something like a balancer. The trouble is that it would require additional
circuitry to decide when the SLC had accumulated enough data to fill out a
burst. We don't have enough information about the DMA request behavir of the
SLC to evaluate it very well.
The final case is the encryption device. The total load is slightly under 300,000
bits/second -- all SLC traffic is encrypted, and must both be read from and
written back to memory. We had designed our system to handle either the
Advanced Micro Devices AmZ8068 or the Western Digital WD2001. The AMD
part is sufficiently fast that it would use up the entire bus bandwidth of our
system if unrestricted. We felt that the 8237-5 single transfer mode would be a
useful way of restricting the encryption device to at most half the bus
bandwidth. As you point out, the balancer achieves the same ends. It uses more
logic, but saves cycles.
In fact, we have never tried the AMD part. We have been using the WD2001
because the external logic required was much simpler and because we felt it
would be fast enough. Our test program, counting the key load and DMA setup
time for 160 byte blocks, can encrypt at about 640,000 bits/second, using a total
of 1.28 Mbit/second of bus bandwidth. The WD2001 turns out to be much less
heavily pipelined than the AmZ8068, so that the encryption of a single 64 bit
DES block involves loading 8 bytes, some number of cycles of algorithm
operation, and unloading 8 bytes. We have been able to use demand transfer
mode on the encryption channels of the 8237-5 and essentially achieve 8 byte
DMA bursts without extra logic. (In fact, it seems to be taking a burst of 8
single transfers in any event! The WD2001 Request line, which we have wired
to DMA Request, becomes inactive for the duration of the WR' pulse. The 8237-5
seems to catch the momentary ionactivation of the request signal and release the
bus. It would be more correct to say the the WD2001 would operate in an 8-byte
burst mode if we solve this request inactivation problem.)
Summing up, it seems to us that thecycle balancer might provide some advantage
for the SLC, but not for our other DMA loads. Further, we think that even if
we could apply the balancer to all the DMA devices, the total DMA load, about
667,000 bits/second, is not a significant fraction of the 10,000,000 available bus
bandwidth. (Using 6 T-cycles for each of the DMA transfers, this translates to
about 1 Mbit of the bus.) Even if all devices used a balancer, the advantage
would be about 26% of 10%! We would only gain a 2.6% improvement in
system throughput.
Sincerely,
Lawrence Stewart
cc: S. Ornstein, PARC/CSL
R. Quinn, A3-31
*start*
01015 00024 US
Date: 30 Dec. 1981 3:27 pm PST (Wednesday)
From: Ornstein.PA
Subject: Adendum to SLC notes
To: Swinehart, Stewart
cc: Ornstein
We do not understand the speed limits of the SLC Tester and have gotten
somewhat conflicting stories. The simple version is that the tester can't run fast
ebnough to test an SLC chip that runs at a 12 MHz clock rate (a 3 MB Ethernet).
But at one point when we discussed this in detail (don't recall with whom) we
understood that the limitation was not very deep and that since the SLC almost
immediately divides its clock in half, it should be possible to feed the SLC itself
a 12 MHz clock while feeding the tester logic a divided-by-two (6 MHz) version.
If there's really any chance that some of the redesigned chips will run at 3
MHz, it seems important to understand whether a minor change will enable one
to test the chips at that speed. In any event, it would seem that the tester should
be able to test the chips well beyond the range where they work.
*start*
01945 00024 US
Date: 30 Dec. 1981 5:25 pm PST (Wednesday)
From: Ornstein.PA
Subject: Production Etherphones
To: Thacker
cc: VoiceProject↑, Taylor
Reply-To: Ornstein
Chuck,
It's early still but not too early to get the lay of the land for how we're going to
build the 50 or so Etherphones. I've been assuming that somehow the Garage
would "do it" but I thought I better check whether that's reasonable and to do
that, we have to settle on what "it" is.
My image was that the Garage would take over completed specs, drawings, test
programs and procedures, etc. and do a straight manufacturing and testing job -
except that Tim would be involved in converting the boards to PC for
production. We're planning to build our second and third prototypes on
stitchweld Multibus boards and I hope we will be able to use the same automatic
layout route that Ed and Tim have worked out for the Dorado boards to go
directly from those layouts to PC. I've asked Mike to help us with some of the
intermediate level engineering, in particular the packaging. We're shooting for
starting production in April with the idea that we might then expect to have
some in July. Of course these are approximate and some of the data, such as parts
lists, should be available before April.
We haven't yet given much thought to how to test them, but probably the
operational program (or minor variation thereof) is an adequate verification since
it continuously exercises everything. What to do if it doesn't work is a bit
harder, but there's only a limited amount of stuff and we can probably produce
a relatively small number of simple test programs that will partition it down to
where chip swapping works. Remains to be worked out in detail and tried.
Presently premature.
I just wanted to touch base to be sure that this general scheme was acceptable.
Lemme know if it seems OK and if you forsee any problems or have suggestions
etc.
Thanks,
Severo
*start*
00957 00024 US
Date: 1 Jan. 1982 4:33 pm PST (Friday)
From: Stewart.PA
Subject: Please add these names...
To: NetSupport.wbst
cc: VoiceProject↑.pa
Reply-To: Stewart
Please add the following names to the Pup-Network directory.
Name: Nest
What: Net
Number: 173##
Owner: VoiceProject↑.pa
Location: PARC/CSL
Name: SkyLark
What: Host
Number: 173#125#
Owner: VoiceProject↑.pa
Location: PARC/CSL 35-2061
Name: MeadowLark
What: Host
Number: 173#100#
Owner: VoiceProject↑.pa
Location: PARC/CSL 35-2061
Please change the following name in the Pup-Network directory.
From:
Name: SamSpade
What: Host
Number: 3#6#
To:
Name: SamSpade
What: Host
Number: 173#6#
Owner: VoiceProject↑.pa
Location: PARC/CSL 35-2061
Please add an additional address for the following name.
Name: Dahlia2
What: Host
Number: 3#112#
To:
Number: 3#112#
Number: 173#112#
Owner: VoiceProject↑.pa
Location: PARC/CSL 35-2061
*start*
00233 00024 US
Date: 2 Jan. 1982 10:47 am PST (Saturday)
From: Stewart.PA
Subject: C Compiler bug
To: Duvall
cc: Stewart
Bad code generated for structure references like xxx->yyy +=1. Test case is
[maxc]<Stewart>Test8.c
*start*
00909 00024 US
Date: 2 Jan. 1982 10:53 am PST (Saturday)
From: Stewart.PA
Subject: GROUPS
To: Duvall
cc: Stewart
I think I sent a message about this one earlier. LDR86 blow up if it gets more
than one GROUP directive, and the C compiler puts one in every file.
Yesterday I worked out how to make ROMable code, by moving the C←CODE
segment somewhere and leaving C←DATA in RAM. I created a new SEGMENT
called SPACE, with no contents. I then made a GROUP of SPACE, C←DATA, and
C←CODE. I made a .ld file with ADDRESSES(SPACE(0), C←DATA(2000),
C←CODE(3000)). This convinced LDR86 to put the code and data where I
wanted, but still kept all the segment registers = 0.
So, I will generally want to include a GROUP directive in my runtime startup
file, putting things where I want. Could you remove the GROUP directives put
out by the compiler and return to "ASSUME CS:C←CODE, DS: C←DATA"?
-Larry
*start*
00762 00024 US
Date: 3 JAN 1982 2015-PST
From: STEWART.PA
Subject: EPROM making
To: Belleville, Lau, Ogus
cc: Stewart, Ornstein
I have gotten to the stage where I want to make some EPROMS containing
an 8088 program. (The 8088 program runs when in RAM and I have carefully
isolated all the READONLY stuff from the readwrite stuff.)
Have you guys got any tools for making 2716's from disk-data?
My data is presently in Intel Absolute Loader format, but I have a program
which understands that and which can call a procedure with
each address,data pair.
Unless you fellows have build something more wonderful, I am inclined
to write a mesa program to turn Intel files into .mb files suitable
for PNEW and then figure out how to run it.
-Larry
*start*
00408 00024 US
Date: 3 JAN 1982 2144-PST
From: STEWART.PA
Subject: Etherloading
To: VoiceProject↑
I've loaded a program (very quickly) via ether to the Lark prototype. I
still have to start them by hand via the DLS. Next step: Lark code
to handle the "begin execution" part of the downloading protocol
and things like an EPROM to hold the Lark code so I won't have
to load the loader. -Larry
*start*
00572 00024 US
Date: 4 Jan. 1982 10:18 am PST (Monday)
From: Ogus.PA
Subject: Re: EPROM making
In-reply-to: STEWART's message of 3 JAN 1982 2015-PST
To: STEWART
cc: Belleville, Lau, Ogus, Ornstein
Larry,
We have a Mesa program (runs on an Alto hooked to our Prolog Prom blower)
which blows EProms. If you want to blow 2716s, the program will accept either
of two input formats: Intel standard Hex format (ASCII text), or our own binary
format which was produced using the Alto Mesa WriteBlock procedures. If you
want more information, give me a call.
Roy.