*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]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]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.