*start*
00426 00024 US 
Date: 24 July 1982 3:09 pm PDT (Saturday)
From: Stewart.PA
Subject: Re: Question
In-reply-to: ornstein's message of 23 July 1982 5:32 pm PDT (Friday)
To: ornstein
cc: Swinehart, Stewart

Lark can pick up the Telewall interface by closing the 'other' relay (there are
two) which connects the A and A1 leads together and connects the hybrid
transformer to Tip and Ring, causing DC loop current to flow.

*start*
00308 00024 US 
Date: 26 July 1982 4:46 pm PDT (Monday)
From: ornstein.PA
Subject: Downloading Lark
To: Swinehart, Stewart
cc: ornstein

Is it your intention to have Thrush (eventually) be the place from which Lark
gets down-loaded, or does all this fit into the general "boot server" mechanism?

S.
*start*
00451 00024 US 
Date: 27 July 1982 6:52 am PDT (Tuesday)
From: Swinehart.PA
Subject: Re: Downloading Lark
In-reply-to: ornstein's message of 26 July 1982 4:46 pm PDT (Monday)
To: ornstein
cc: Swinehart, Stewart

We hope it fits into the general boot server mechanism. There'll be room enough
in the ROM for the kind of EFTP implementation needed (the one on the Alto
takes 512 bytes of code or something.)  Otherwise, we'll put it in Thrush.

*start*
00619 00024 US 
Date: 27 July 1982 9:39 am PDT (Tuesday)
From: Stewart.PA
Subject: Re: Downloading Lark
In-reply-to: ornstein's message of 26 July 1982 4:46 pm PDT (Monday)
To: ornstein
cc: Swinehart, Stewart

I haven't thought very much about that.  Traditionally, boot servers must be on
the same net as the served, so they can be reached by broadcast packets. 
However, we have sufficient EPROM space (8K bytes) to store a quite complex
boot requester.  It could ask Thrush or use the local gateway.  The code does not
exist yet for Lark to use the standard EFTP boot protocol, but that is
straightforward.

*start*
02027 00024 US 
Date: 27 July 1982 5:31 pm PDT (Tuesday)
From: Quan.pa
Subject: Rework Stitchweld Board Request
To: SDD-HDW^,Conway, (C. Currie c/o) SDowns.es, (G. Day c/o) Lawler,
 Geschke, Hagstrom, Meuli, Taylor, Urbach
cc: Curry, DNCurry, Diebert, Garner, Gifford, Kowalski, Murray, Ornstein, Orr,
 Overton,
 Petit, Pier, Pirogowicz, Pugh, Sosinski, Stafford, Stewart, Thacker, Vest,
 Rosemary, RRicci, Quan
Reply-To: Quan

In order to ensure that the correct amount of updating is performed when
submitting a rework Stitchweld board request, please also include the old revision
from which the new version is to be made and add a note under "Special
Instructions" on the form; if it is necessary to incorporate the in-between
revision levels (Rev A to Rev C; 'Also incorporate Rev B' and give file name) or
if they are already included in the new file ( Rev B included in new file) or
not required (Rev B not required).

I have added a placeholder to fill-in the old revision from which the new
version is to be made. The modified form is stored on
[Iris]<Quan>StitchweldOrder2.form. Please use this updated form for all future
request by Laurel. I will also be modifying the .bravo and .press files to include
the listing of the rework from revision level in the near future. 

One further reminder on rework Stitchweld orders. If the boards you supply for
rework have the components inserted and you want the stitchwelder to remove
and re-insert and/or add components, you must supply a placement diagram (file
tobe retrieved) or assembly sketch that clearly shows where the components are
to be inserted on the board. Even if all the components are re-inserted in the
same places as before, as there is a high risk for error if the stitchwelder makes
her own skecth. You may wish to remove the components proir to giving us the
board and re-insert them yourself to eliminate this problem (you are charged for
each IC/item removed and each IC/item inserted).

Thank you for your continued cooperation.

Dick   

*start*
01436 00024 US 
Date: 4 Aug. 1982 2:16 pm PDT (Wednesday)
From: Stewart.PA
Subject: Stitchweld Work Request
To: Quan.pa
cc: RRicci, Stewart, VoiceProject^.pa 

XEROX	STITCHWELD WORK ORDER	(submitt one order per board)

To Engineering Support	Engrg Sprt Appvl		LOG NO.	

				Priority 2=Nor

Submitted By: L. Stewart	Ext. 4477	MS 35-2088  Date 8/4/82

Organization PARC/CSL	 Project Voice	 Budget Center 55

Board Type ETT	Rev Ag	Date Required 8/9/82

Serial No. 2    New [   ]  or  Rework From Bd Rev Af [ X ] (check one)

Special Instructions: 

Retrieve File	[   ]    or    Load Dump File [ X ]  (check one) 	

ETP-Rev-Ag.ad from	[Indigo]<Voice>ETP>ETP-Rev-Ag.dm


Work Performed:					Date Completed     /    /

	Continuity Check:	(     ) Pins @ 0.5 units/pin =	(     ) Units.
	Trace Cuts:		(     ) Cuts @ 2 units/cut =	(     ) Units.
	New Welds:		(     ) Welds @ 1 unit/weld =	(     ) Units.
	IC Removal:		(     ) Removals @ 1 unit/IC =	(     ) Units.
	Weld Removal:	(     ) Welds @ 2 units/weld =	(     ) Units.
	Rework Welds:	(     ) Welds @ 1 unit/Weld =	(     ) Units.
	IC Insertions:	(     ) IC's @ 2 units/IC =		(     ) Units.
							   Total:	(     ) Units.
	Other (describe):


			Total:	(	) Units @ ($ 	)/unit =  ($ 		)
				(   	) Hours @ ($ 	)/hr. =   ($  	)

							Total This Job:  ($		)

[Iris]<Quan>StitchweldOrder2.form

*start*
01436 00024 US 
Date: 4 Aug. 1982 2:17 pm PDT (Wednesday)
From: Stewart.PA
Subject: Stitchweld Work Request
To: Quan.pa
cc: RRicci, Stewart, VoiceProject^.pa 

XEROX	STITCHWELD WORK ORDER	(submitt one order per board)

To Engineering Support	Engrg Sprt Appvl		LOG NO.	

				Priority 2=Nor

Submitted By: L. Stewart	Ext. 4477	MS 35-2088  Date 8/4/82

Organization PARC/CSL	 Project Voice	 Budget Center 55

Board Type ETT	Rev Ag	Date Required 8/9/82

Serial No. 3    New [   ]  or  Rework From Bd Rev Af [ X ] (check one)

Special Instructions: 

Retrieve File	[   ]    or    Load Dump File [ X ]  (check one) 	

ETP-Rev-Ag.ad from	[Indigo]<Voice>ETP>ETP-Rev-Ag.dm


Work Performed:					Date Completed     /    /

	Continuity Check:	(     ) Pins @ 0.5 units/pin =	(     ) Units.
	Trace Cuts:		(     ) Cuts @ 2 units/cut =	(     ) Units.
	New Welds:		(     ) Welds @ 1 unit/weld =	(     ) Units.
	IC Removal:		(     ) Removals @ 1 unit/IC =	(     ) Units.
	Weld Removal:	(     ) Welds @ 2 units/weld =	(     ) Units.
	Rework Welds:	(     ) Welds @ 1 unit/Weld =	(     ) Units.
	IC Insertions:	(     ) IC's @ 2 units/IC =		(     ) Units.
							   Total:	(     ) Units.
	Other (describe):


			Total:	(	) Units @ ($ 	)/unit =  ($ 		)
				(   	) Hours @ ($ 	)/hr. =   ($  	)

							Total This Job:  ($		)

[Iris]<Quan>StitchweldOrder2.form

*start*
01436 00024 US 
Date: 4 Aug. 1982 2:17 pm PDT (Wednesday)
From: Stewart.PA
Subject: Stitchweld Work Request
To: Quan.pa
cc: RRicci, Stewart, VoiceProject^.pa 

XEROX	STITCHWELD WORK ORDER	(submitt one order per board)

To Engineering Support	Engrg Sprt Appvl		LOG NO.	

				Priority 2=Nor

Submitted By: L. Stewart	Ext. 4477	MS 35-2088  Date 8/4/82

Organization PARC/CSL	 Project Voice	 Budget Center 55

Board Type ETT	Rev Ag	Date Required 8/9/82

Serial No. 4    New [   ]  or  Rework From Bd Rev Af [ X ] (check one)

Special Instructions: 

Retrieve File	[   ]    or    Load Dump File [ X ]  (check one) 	

ETP-Rev-Ag.ad from	[Indigo]<Voice>ETP>ETP-Rev-Ag.dm


Work Performed:					Date Completed     /    /

	Continuity Check:	(     ) Pins @ 0.5 units/pin =	(     ) Units.
	Trace Cuts:		(     ) Cuts @ 2 units/cut =	(     ) Units.
	New Welds:		(     ) Welds @ 1 unit/weld =	(     ) Units.
	IC Removal:		(     ) Removals @ 1 unit/IC =	(     ) Units.
	Weld Removal:	(     ) Welds @ 2 units/weld =	(     ) Units.
	Rework Welds:	(     ) Welds @ 1 unit/Weld =	(     ) Units.
	IC Insertions:	(     ) IC's @ 2 units/IC =		(     ) Units.
							   Total:	(     ) Units.
	Other (describe):


			Total:	(	) Units @ ($ 	)/unit =  ($ 		)
				(   	) Hours @ ($ 	)/hr. =   ($  	)

							Total This Job:  ($		)

[Iris]<Quan>StitchweldOrder2.form

*start*
01926 00024 US 
Mail-from: Arpanet host USC-ISIB rcvd at 29-JUL-82 1656-PDT
Date: 29 Jul 1982 1649-PDT
From: Stephen Casner <Casner at USC-ISIB>
Subject: Re: Arpa wideband STNI
To: Stewart at PARC-MAXC
cc: Casner at USC-ISIB
In-Reply-To: Your message of 21 Jul 1982 16:25 PDT

Larry,
	We had run out of copies of our STNI manual, but I made a copy
of the text and schematic portions for you.  I didn't bother to copy
the Z80 firmware listing because it sounds like you aren't really
interested in that part.  If that is wrong, we can easily send a
listing to you via the network.

	I have marked some corrections on the copy.  Note that a balance
circuit is part of the 2/4-wire hybrid.  The balance required varies with
the coupler used to connect to the phone line, with the phone line itself,
with the distance one is calling, and with time.  So, the choice of values
is not absolute nor optimal, but only acceptable.  You may want to use
different values than we did.

	What are you using to couple legally to the phone line?  We use a
"Voice Coupler" made by PCI, but we're not very happy with its performance.
We are also experimenting with a device made by Novation called a PLI
(Phone Line Interface).  We have done enough to verify that it works, but
have not completed our test installation of an STNI with the PLI.  The PLI
is a 2"x2"x.5" FCC-registered module which provides protection in both
directions.  In addition, it includes a ring detector with logic output
and some other control functions which may interest you.  It does not
include the hybrid function, and to use it with the hybrid the balance
must be different.  However, it does seem to be a nice means of legally
coupling to the phone line.  If it had been available when we were designing
the STNI, we probably would have included it on-board and left off some of
what we needed in its place (such as ring detect).

						-- Steve
-------
*start*
01067 00024 US 
Date: 30 Jul 1982 10:38 PDT
From: Stewart at PARC-MAXC
Subject: Re: Arpa wideband STNI
In-reply-to: Your message of 29 Jul 1982 1649-PDT
To: Stephen Casner <Casner at USC-ISIB>
cc: Stewart

We were thinking of hiring a consultant and registering the thing, but that
seems like a lot of work for just a few.

I have some information on the Cermetek CH1812 Direct connect protective
hybrid, which is like what the Novation PLI sounds like.  (You might call them
at 408-734-8150 for data sheets on the CH1810 and CH1812.)  I hadn't known
about the Novation.  Can you give me their part number and phone number?

I have heard a rumor that there is a tariff for certain lines to be designated
"experimental" in some way, for development of registered equipment.  I have not
tracked it down, but that might fill the bill too.  I noticed that in an
interpretation of Part 68, the FCC has said there is no requirement that test
equipment be registered before you can use it.  That might match with the
existance of the "experimental" loops.

	-Larry

*start*
00510 00024 US 
Mail-from: Arpanet host USC-ISIB rcvd at 30-JUL-82 1053-PDT
Date: 30 Jul 1982 1047-PDT
From: Stephen Casner <Casner at USC-ISIB>
Subject: Re: Arpa wideband STNI
To: Stewart at PARC-MAXC
cc: Casner at USC-ISIB
In-Reply-To: Your message of 30 Jul 1982 10:38 PDT

Larry,
	The Novation PLI is part number 409-278.  Phone is 213-996-5060.
I'll forward the pointers on the Cermetek devices to our hardware guys,
thanks.  The experimental lines sound interesting, too.

						-- Steve
-------
*start*
00565 00024 US 
Mail-from: Arpanet host USC-ISIB rcvd at 30-JUL-82 1159-PDT
Date: 30 Jul 1982 1149-PDT
From: Robert H. Parker <PARKER at USC-ISIB>
Subject: Re: [Stewart at PARC-MAXC: Re: Arpa wideband STNI]
To: casner
cc: PARKER
In-Reply-To: Your message of 30 Jul 1982 1134-PDT
Remailed-date: 30 Jul 1982 1155-PDT
Remailed-from: Stephen Casner <Casner at USC-ISIB>
Remailed-to: Stewart at PARC-MAXC

We chose to not use the Cermetek unit because of our dismal experiences
with the Cermetek modems. You might pass that bit of data back to Parc.

BP
-------
*start*
01031 00024 US 
Date: 1 Aug. 1982 3:32 am PDT (Sunday)
From: Swinehart.PA
Subject: RPC Stuff; where to find it.
To: Stewart
cc: Swinehart

[Indigo]<Voice>Top>LarkComm (and LarkBase, of course), describe the RPC
package and some tests, including RPCTest (TestRPC.ld.)  RPCTest uses only RPC
initialization routines and the capabilities of RPCFir -- it's a pretty good example.

[Ivy]<Swinehart>LarkRPC>MesaRPC.df describes the TestLupine interface,
TestLupineImpl (server) and TestLupineUserImpl, and the TestLup config.  It
also includes all the Lupine-derived files.  It is configured for Cedar 3.1; not
sure how much work is involved in conversion to 3.2.

Start TestLup, set Bugbane to consider TestLupineUserImpl, then call Main,
followed by Loop or by calls on TestLupineRPCClientImpl.InterfaceProc[]....

If you want to test specific things via RPC, I'd suggest making the intstance field
be "173#55#" or "3#xxx#", etc., corresponding to the pair of machines being
used, rather than toying with "broadcast binding."

*start*
00427 00024 US 
Date: 17 Aug. 1982 11:12 am PDT (Tuesday)
From: Stewart.PA
Subject: U255 software
To: Purvy.ES
cc: Stewart

Look on [Indigo]<Voice>EP>.

Probably most interesting are the DEFs file U255.mesa and its implementation
U255Impl.mesa.

The file LarkSlaveTableImpl.mesa uses them to compute various tables used by
the signal processing part of the Lark.  There is a 'silence' computing table there.

	-Larry


*start*
00548 00024 US 
Date: 20 Aug. 1982 10:03 am PDT (Friday)
From: Swinehart.PA
Subject: DoCC
To: Stewart
cc: Swinehart

DoCC (via CTools.df) now will not try to compile or assemble a file that does not
exist.  It will still try to assemble a file that did not compile correctly, however,
being unable to predict the future and unwilling to run twice.

I now know where to find the standard Alto/Mesa emulator; is there a reasonable
place in DoCC to put a loadmb that will restore normality, or should we just
install it as a keyX.cm command?

*start*
00273 00024 US 
Date: 20 Aug. 1982 10:14 am PDT (Friday)
From: Stewart.PA
Subject: Re: DoCC
In-reply-to: Your message of 20 Aug. 1982 10:03 am PDT (Friday)
To: Swinehart
cc: Stewart

I'm happy to type a command.  Running LoadMB is faster than tripleboot.

	-Larry

*start*
00322 00024 US 
Date: 20 Aug. 1982 10:51 am PDT (Friday)
From: Swinehart.PA
Subject: Re: DoCC
In-reply-to: Your message of 20 Aug. 1982 10:14 am PDT (Friday)
To: Stewart
cc: Swinehart

CTools now includes mesa.mb and LoadStdMb.cm, the latter of which should be
copied to a keyx.cm file for one-button invocation.

*start*
00469 00024 US 
Date: 21 Aug. 1982 11:22 pm PDT (Saturday)
From: Stewart.PA
Subject: Teledeb6
To: VoiceProject^.pa
cc: Stewart
Reply-To: Stewart

[Indigo]<Voice>EP>
	Teleload6.df
	Teledeb6.bcd

is a Mesa 6 version of the Etherphone downloading software.

User typein is generally via IODefs.ReadID so type escape for the default string:

Open => Skylark
Parse => previous filename

".obj" will be added if the object file name does not contain a '. .

	-Larry

*start*
23139 00024 US 
Date: 22 Aug. 1982 2:39 am PDT (Sunday)
From: Stewart.PA
Subject: Tale of the interrupts
To: VoiceProject^.pa
cc: Stewart

I had gotten tired of working on the analog stuff last weekend, so I decided to
finish checking out interrupts.  This effort took up most of the week...

A while ago, when I first began to check out interrupts I found the first design
bug rather easily.  The 8088 sets the IO/M pin to the IO state for interrupt
acknowlege cycles.  This caused the cycle decoding logic to enable the wait state
generator.

Lark has some IO devices, notably the encryption chip, which are too slow for
an 8 MHz 8088.  IO references are extended by one cycle by the wait state
generator.  The system goes not-ready soon after the IO line is asserted and goes
ready again after RD' or WR' get through a one cycle delay.

Unfortunately, interrupt acknowlege cycles do not assert either RD' or WR', but a
third signal (with similar timing) called INTA'.  The system never became ready
again.  I fixed this by including INTA' among the collection of signals ending a
wait.

Later, my very first interrupts often seemed to cause "Divide by Zero at XXXXH"
messages to be printed.  This message is from the Lark monitor's divide error
mousetrap.  On the 8088, divide overflows cause an interrupt of type 0 and the
monitor provides a handler for it, just in case.

The symptoms seemed to imply that the 8259 interrupt controller was correctly
dealing with an interrupt acknowlege cycle, but that someone was stepping on
the interrupt type code as it passed over the bus from the 8259 to the 8088, but
who?

I called Intel to ask how the 8088 generates interrupt acknowlege cycles, as the
books are none too specific.  I learned that the 8088 sets the bus to tri-state,
generates an ALE and an INTA' for each of the two cycles involved. (On the
second cycle, the 8259 returns the type code, as though INTA' were RD').  DT/R'
is low and DEN' is active.  Interrupt acknowlege cycles look exactly like IO reads
except that INTA' is used instead of RD'.  In 8088 minimum mode there is no way
to tell the difference until INTA' arrives.  In addition, the 8088 generates ALEs
which latch the (floating!) bus as an address.  The address is undefined!  In
Lark, there are 20K pullup resistors on the bus, so I felt that the latched address
would tend to be all 1's.

I patched out the divide error handler with one that just did an IRET (return
from interrupt) so I could poke around.  The culprit was the off board bus data
transceiver.  The IO address decoders were getting an address with LAddr08 = 1
and enabling the off board IO bus.  The transceiver was then controlled by
DT/R' for direction and DEN' for enable.  Since the off board IO bus is low true
and was floating high, the transceiver generated an all-zero on the CPU side. 
Since the 8287 transceiver is a big husky chip compared to the 8259, it won.  I
fixed this by using RD' to control the transceiver direction.  (It still turns on, but
is pointed away from the action.)

Interrupts now seemed to work fine, but I noticed that the base of the hardware
interrupts caused by the 8259 was 020H.  This made me a bit worried, since 020H
is the address of the Ethernet chip.  The IO address decoder was not disabled
during interrupt acknowlege cycles, since they look like IO reads and I was
worried that the interrupt type code might get to the decoder.  This would be
bad, because selecting the Ethernet chip disables the wait state generator.  I
changed the interrupt types to 070H - 077H to play it safe.

Several weeks pass.

Friday the 13th, the Lark processor board was sent out for PC.

Saturday, as mentioned earlier, I got tired of analog stuff and decided to check
out interrupts some more.  This was expected to be a purely software enterprise.

I dusted off the half-written interrupt driver for the 8274 RS-232 chip and started
to work on it.  After a number of bugs, I got to the point where I could type a
few characters and get interrupts back, but after 10 or 20 characters, the system
would crash.  Non-maskable interrupt didn't work and after booting, the contents
of memory were gone.  I fiddled around with the code for a while and seemed to
improve matters to some degree, transmit interrupts would nearly always work
but receive interrupts would only work for a while.

It looked a lot like a software problem, but I finally got out the scope to see if I
could learn anything by looking around after one of the crashes.  It took about
30 seconds to discover that the system was hung not-ready during an interrupt
acknowlege cycle.   Sure enough, a 020H from somewhere had gotten to the IO
address decoder, selected the ethernet chip, and disabled the wait state
generator.  The CPU had asserted INTA' and was patiently waiting for READY. 
The ethernet chip was patiently waiting for RD' or WR' so it could produce
READY.  The memory chips, with refresh disabled by this situation, had long
since faded away.  I adopted a brutal fix -- a gate in front of the IO address
decoder that would definitely disable it as soon as INTA' arrives.  This fixed the
problem and 8274 interrupts work fine now.  I also noticed that the 8274 has an
open collector interrupt request line, and Lark had no pullup (this would tend to
work anyway).

One might think that the short (100 ns) chip selects that come out of the address
decoder might be bad, but I don't think this is so.  All the IO chips wait for RD'
or WR' before doing anything, so random chip selects should not hurt.  Even if
the Ethernet chip becomes selected, it will wait for RD' or WR', and the 8088 will
assert INTA' and correct the erroneous select before looking at READY.

It seems that there is no way around this kludgery other than 8088 maximum
mode, which is overkill for us and a considerable redesign anyway.  Apparently
the 20K bus pullups take quite a while to charge the bus capacitance, so the
address latched by an interrupt acknowlege can be anything.

The next interrupt was encryption.  I had never tried it before, but had
essentially no trouble.  The interrupt encryption driver accepts encryption
control blocks and hangs them on a queue if the encryption chip is busy.  The
encryption end interrupt handler disposes of the just finished control block by
calling a procedure passed in the block and then starts the chip working on the
next control block, if there is one.  The raw hardware runs at about 900,000 bits
per second and the software manages to get 800,000 average out of it.  The peak
load for Lark is around 300,000, so there is plenty left over.

I let the test run all night, generating about 600 interrupts per second.

Ethernet interrupts next.

I reread the SLC documentation and puzzled out my best guess about how it
worked.  (Even found some old notes from a previous reading -- I agreed with
myself!)

I wrote receive and transmit interrupt handlers that simply printed an 'r' or a 't'
on the terminal, reset the interrupt, and returned.  Otherwise, the Ethernet
driver was unchanged.  I tried the Pup Echo program EchoUser -- instant
failure.  I got one 'r' and a couple of 't's and then the world caved in. 
Typically, the Lark would print some trash on the terminal and die, or boot
itself, or just stop.  Sometimes non-maskable interrupt would work and sometimes
not.  Sometimes scraps of sensible messages would be printed.  Nearly always the
program would be trashed and have to be reloaded.

It seemed to work a little better when echoing to the gateway instead of itself, so
I wondered if the full-duplex DMA load might be too much.  (Mind, it didn't
work very well either way!)

I editted the program to enable only transmit interrupts, then only receive
interrupts, and tried all permutations of the two versions with echoing to the
gateway or itself.  Receive interrupts worked very badly under all circumstances,
but transmit interrupts worked fairly well if the receiver was not running
concurrently.  Now it so happens that the transmit interrupt occurs after the end
of the transmission, hence after the end of all transmit DMA activity.  However,
when transmitting full duplex, the receiver is still running after the transmitter
finishes, so the interrupt occurs while the receiver is still doing DMA.  Suppose
there was DMA/interrupt interference somehow.  A clobbered interrupt type
code could cause the CPU to pick up uninitialized memory as an address and
jump into hyperspace.  Perhaps the Hold/HoldA DMA interlocks didn't work for
the memory cycles imediately after an interrupt.  The Ethernet chip could be
clobbering the interrupt handler address or the saved return address or
something.  On several occasions when I managed to get into the monitor by
NMI or booting, the 8088 code segment register (CS) had a non-zero value. 
Normally, Lark operates with CS = 0.  There is only one instruction is all of the
Lark code that tampers with CS (loading a 0, actually).  However, interrupts
cause CS to be loaded from low memory and return from interrupt restores the
previous value.  DMA interference could smash CS either coming or going.

There was reason to suspect that the trouble with receiver interrupts could also
be DMA related.  I had noticed months ago that the ethernet receiver controller
status went to idle some time before the control block status in memory changed. 
Apparently the controller registers represent what is happening on the ethernet
side of the receiver FIFO rather than the CPU side.  The receive done interrupt
could be happening while receive DMA was still running.

There was essentially no way to use a scope to check these ideas, because the
event, whatever it was, only happened once and the machine was reduced to
such a rubble that no evidence was left.  I called ED in El Segundo to ask if SLC
interrupts were thought to work. Frank Nelson said he thought so, but would
check with Jim Okazaki and get back to me.  I was reduced to guessing
explanations, looking for supporting evidence, and devising tests.

1.  Clobbering of the interrupt type code.

There was some support for this, as sometimes during the crash Lark would print
fragments of messages from the monitor's interrupt mousetraps: Divide error,
Single step, unknown breakpoint, etc.  This could happen as a result of smashing
the vector to something which had an interrupt handler, even though the wrong
type.

I moved the test program from 0200H to 1000H, and filled all of the vector space
with pointers to code that would print "unknown interrupt".  The machine kept
crashing, but I never saw the message.

2.  Generic interference between DMA and interrupts, not specifically Ethernet
interrupts.

I combined the encryption interrupt test with the Pup echo test and disabled the
Ethernet interrupts.  It worked fine.  I got out the scope and found (as I thought
might happen.)  that the two processes had become phase locked in such a way
that the encryption interrupts never happened at times when the ethernet chip
was running.

At about this time I told Chuck Thacker part of this tale and mentioned the
possibility of DMA interference and that the ethernet chip runs off a different
clock from the processor.  (Actually, it doesn't, it runs off a different submultiple
of the same crystal, but there are 12 different phase relationships possible and an
Ethernet interrupt might come at a bad time.)  This idea raised the spectre of a
synchronizer failure somewhere.  I mentioned that the RS-232 chip worked fine
and generated interrupts from a different clock (It runs off the audio crystal
rather than the CPU crystal.) but admitted that I had only tried a few hundred
interrupts before becoming tired of typing.

3.  Synchronizer failure.

I added handlers for the four 'audio' interrupts to the echo program.  The
handlers were to print the letters a through d.  I hooked up an audio oscillator to
the 'd' interrupt.  The terminal was set to 1200 baud, so I knew that I couldn't
generate more than about 100 interrupts per second, but fewer should be OK. 
Without the Ethernet running, 40-60 interrupts per second would work fine, but
when I cranked the oscillator up to 80 or 90 Hz, the machine would crash
again.  

Clearly this had nothing to do with DMA.  I reread the 8259 documentation and
it said quite clearly that asynchronous interrupts work fine.  

4.  Chip programming and interrupt code.

I had been using the 8259 in "level triggered" mode with "automatic
end-of-interrupt".  All the interrupt requests were either latched or generated by
chips that would hold the request until cleared by software.  Automatic
end-of-interrupt means that the second cycle of the interrupt acknowlege clears
the In-Service register in the 8259.  Since the request is still present, the 8259
would immediately request another interrupt.  Since the interrupt handlers run
with interrupts disabled, nothing would happen.  The handler resets the request
latch or otherwise clears the request and the trailing edge of the request should
trickle through the 8259, removing the erroneous second interrupt by the time
the 8088 re-enabled interrupts on exit from the interrupt service routine.

I looked at my code and found:

InterruptD() { putchar('d');  resetlatch(); };

It doesn't take long from resetting the latch to returning from the machine code
part of the interrupt handler.  I put the resetlatch() first and also made the
corresponding change to the ethernet interrupt handlers.  The encryption
handler cleared the request well in advance of returning.  In addition, I felt it
might be safer to use software end-of-interrupt rather than automatic.  I changed
the 8259 initialization code and the machine code parts of all the interrupt
handlers to specifically clear the 8259 in-service register.

Aside:
I also modified the unknown-interrupt catching code to print which interrupt
had occurred.  I was able to do this still using only one copy of the code by
adopting a strategem I'd heard about from a friend at Convergent Technology. 
The 8088 uses a 16 bit code segment and a 16 bit PC, but they overlap by 12
bits.  There are thus 4096 CS:IP pairs that jump to the same place.  I encoded the
interrupt type in CS and used the appropriately corrected value in PC to cause
control to reach the unknown-interrupt handler, which then restored CS = 0.

After these changes, the audio oscillator interrupts worked fine in the vicinity of
90 Hz.  Ethernet interrupts still failed as before.

I ran the audio oscillator interrupts and the non-interrupt ethernet code at the
same time.  With 90Hz interrupts and 150 packets per second, the machine would
run for 30 seconds or a minute before blowing up.  It could be a synchronizer
failure, but it was more likely that it took that long for an oscillator interrupt to
hit ethernet DMA activity.  Packet transmission or reception takes only about 200
microseconds.  Times 150 packets per second both transmit and receive gives only
0.06 seconds of DMA activity per second.

Perhaps there were two bugs:  poor coding (as above) and DMA troubles as well.

5.  DMA interference part two.

I began to set up to test this business of the transmit interrupt working better
than receive.  I modified the Ethernet transmit routine to toggle a parallel port
bit in the instructions immediately following the start command to the ethernet
chip.  I ran the bit into a pulse generator set to generate a varable delay, and
ran the resulting pulse into the 'D' interrupt.  By varying the delay, I could see
what timing relationships between DMA activity and interrupts caused trouble.

An interrupt occuring during most of the packet transmission worked perfectly
well, but near the end of the packet there were regions during which an
interrupt would fairly reliably cause a crash.

The idea that interrupt acknowlege cycles somehow caused a breakdown in the
8088 DMA interlocks had made me uncomforable somehow, but here was a new
idea.  Perhaps the ethernet chip, during some small period near the end of
operation, failed to observe the bus rules.  (Why this should preferentially cause
trouble with interrupt acknowledge cycles might have something to do with
those momentary chip selects.).

The time had come to instrument the hardware somehow and pin down the
trouble precisely.  I had thought of a way to produce a repetitive crash and
permit use of a scope.  I could program a new EPROM for Lark with my test
code, and also blow a new address decoding prom which would put the EPROM
at address 0, so it could contain the interrupt vector addresses.  I could then
drive the system reset line with an oscillator.  This would be a good deal of
work.

Rather than start, I borrowed the ISL Biomation logic analyzer and read the
instruction book for an hour or so.  Clearly the interrupt that caused the crash
would be the last one, so the logic analyzer could be set to trigger and remember
various signals at the time.  The Biomation will sample 1024 points of 16 signals
at up to 100 MHz (e.g. 10 microseconds of recording time) and catch 5
nanosecond glitches.  (No wonder it costs umpteen thousand.)  I set it up for 20
nanosecond samples and attached it to all the CPU control signals, ethernet chip
select, and the 8 bit data bus.  I set it to trigger on INTA' and remember 100
samples before and 924 after.  (Logic analyzers are great for remembering what
led up to the triggering event)  Now there was a problem.  The analyzer was
intended to be left running continuously, recording a multiplicity of trigger
events.  You typically return in the morning to see what caused the last trigger
event.  Unfortunately the analyzer would only retrigger about 10 times a second
and the ethernet echo program ran about 100 interrupts a second.  If it didn't
break on the first one, I would not be certain of having a picture of the one that
broke.

I added a "single packet" key to the test program so I would get one interrupt per
key stroke.  Now it wouldn't fail unless I had the receiver running and got two
interrupts per keystroke.  Still, there was a good chance of eventually getting a
picture, if only I knew what to look for.

On the analyzer timing display, because the ethernet runs off a somewhat
different clock, it was easy to see which cycles were CPU generated and which
were Ethernet generated.  I looked at pictures of ethernet dma activity scattered
through and around the interrupt acknowlege cycles, but saw no ungentlemanly
conduct of either the CPU or ethernet.  I saw the memory refresh non-maskable
interrupt happen nearby, but again, no obvious problem.

I carefully stepped through the data display, and watched the CPU fetch the
correct interrupt handler address from the correct location and correctly begin
execution.  Noone seemed to be clobbering the CS value on the way into the
handler.  Was it correct on the way out?  I reset the analyzer to trigger on the
end-of-interrupt command and eventually found the place where the cpu
popped the original CS value off the stack.  All zeros.  (There was a chance that
I'd gotten a picture of the not-last interrupt, so this wasn't conclusive.)

I had got a picture of a crash with a non-zero CS value.  Since hardly anyone
changes it, there was a chance that that value was recorded in the analyzer.  I
scanned for it and found a couple of instances, but in context they seemed to be
legitamate addresses.

My friend from CT called to see about dinner, so I left for Chinese food.  He
knows a lot about 8086's so I mentioned these troubles.  He suggested some
things.  Had I got one of the 8088's with the load SS interrupt disable bug?  No,
the 8 MHz parts are supposed to have that fixed and anyway I never execute
those instructions.  Do I ever store things below the stack pointer where they
will be squashed by an interrupt?  No, except that my process switching package
might have a mistake like that.  (I didn't think so though.)  I mentioned that CS
came up non-zero sometimes and we talked about how that could happen: 
Executing so-called "long" calls and returns (we don't use them).  IRET with a
garbled stack, hitting a long call or return in unitialized memory, etc.  We talked
about 8259 programming - he'd never trusted the automatic end-of-interrupt.

Given that I had covered all the interrupt vector area with my
unknown-interrupt handler, it seemed likely that control was getting to the right
interrupt handler.  My friend announced that his gut feeling was that a problem
like this had more to do with the code that might be running when the interrupt
arrived than with the service routines.

I wandered by the office after dinner to look at Contextml.dsm.  After puzzling
for a while over how it was supposed to work, I decided it was ok.  Then what? 
Who calls it?....  oops.

Here is the code for putchar:

putchar(c) char c; {
  while (!sioav()) do Block();
  sioputc(c);
  };

In the case that the 8274 sio was busy on entry to putchar, I had been calling
the process scheduler from an interrupt handler!  I changed the interrupt
handlers to call a busy wait version of putchar and everything worked.

Debriefing:

Calling the scheduler wouldn't disturb the integrity of anyone's stack
immediately, but certain processes execute code with critical sections, which are
intended to run with interrupts disabled.  Lark has machinery like Mesa, with
increment and decrement wakeup disable counter, so critical sections can be
safely nested.  The interrupt handlers do not bother incrementing the counter
because, although they run with interrupts disabled, they expect to exit right
away.  By calling block, other processes were run, which might therefore
execute a critical section with the counter at 0.  Incrementing it to 1 would
disable interrupts (a no-op, interrupts would already be off, since the interrupt
handler had just been running).  Then exiting the critical section would
decrement the counter to 0 and enable interrupts.  We would have switched
stacks, but be logically inside the interrupt handler with interrupts enabled, but
end-of-interrupt not yet signalled.  This would lead to nested interrupts and
unconstrained stack growth.  In not too many milliseconds one or another process
stack would write over another one (or over the program itself.)  Boom.

How does this explain all the symptoms?

Changing the pulse generator delay was not only changing the phase of the
interrupt with respect to the dma activity, but with respect to which process was
executing.  (They execute in fixed round robin order.)

My single packet key didn't cause trouble because the 8274 would always be
free.

Changing the frequency of the oscillator interrupts would either find or not find
the 8274 busy, thus would only sometimes call Block.

Receive and transmit interrupts seemed to behave differently because of the
different code that would be running at the time of the interrupt.

In a way my friend was right -- the observed effects depended on the details of
the running code, but the root cause was probably nested interrupts and stack
overflow.

	-Larry
*start*
01415 00024 US 
Date: 24-Aug-82 16:38:30 PDT (Tuesday)
From: Purvy.ES
Subject: fyi
To: Stewart.pa
cc: Verplank.pa, Purvy

I did an analysis of a 11-second voice file, out of curiosity to see what the distribution of 7-bit absolute values was.  In case you're interested, here it is:

codearray = (128)[6162B, 0, 124056B, 0, 3312B, 0, 2701B, 0, 1711B, 0, 2205B, 0, 1641B, 0, 2044B, 0, 1210B, 1451B, 1435B, 1410B, 1002B, 1231B, 1114B, 1551B, 617B, 1037B, 1002B, 755B, 577B, 751B, 637B, 666B, 1246B, 1452B, 1226B, 1360B, 1041B, 1125B, 1032B, 1177B, 760B, 1052B, 673B, 1064B, 713B, 637B, 567B, 666B, 1407B, 1324B, 1246B, 1263B, 1035B, 1114B, 1046B, 755B, 731B, 707B, 640B, 566B, 537B, 541B, 524B, 500B, 1224B, 1021B, 1070B, 670B, 566B, 567B, 505B, 473B, 375B, 404B, 315B, 326B, 307B, 262B, 261B, 204B, 371B, 333B, 266B, 221B, 214B, 175B, 163B, 140B, 115B, 115B, 55B, 62B, 55B, 35B, 14B, 24B, 26B, 25B, 43B, 46B, 20B, 15B, 20B, 14B, 6, 6, 5, 2, 2, 1, 3, 2, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

The entries are the number of each code value;  thus, there were 6162B zero's, or 3186;  no 1's;  124056B 2's, or 43054;  etc.  In looking at the data on the Alto, it looks like silence is almost all 202B's, with some 0's, 2's, and 4's thrown in.

The interesting thing is that every other code value at the low end is never hit.  Does this mean anything?  like the A/D converter isn't quite right?

Bob  
*start*
00468 00024 US 
Date: 24 Aug. 1982 5:22 pm PDT (Tuesday)
From: Stewart.PA
Subject: Re: fyi
In-reply-to: Purvy.ES's message of 24-Aug-82 16:38:30 PDT (Tuesday)
To: Purvy.ES
cc: Stewart, Verplank

You are quite right.  Every over value never occurs.  The Alto Auburn board
really has a 12 bit linear A/D with conversion done by microcode.  One needs 13
bits to cover all the u255 values and in some sense 14 bits to correctly implement
the "mid riser".

	-Larry
*start*
01435 00024 US 
Date: 26-Aug-82  9:38:30 PDT (Thursday)
From: Purvy.ES
Subject: Silence results
To: Stewart.pa
cc: Verplank.pa, Purvy

I did a first version of silence suppression that simply takes every sample below a certain threshhold, and sets it to zero.  Then, my run-encoding stuff can do its thing on runs of zeros.  This isn't quite what we talked about last week, where I would decide on a block-by-block basis whether something is silent, and omit the whole block if so.

The interesting thing is that the three *.u255 files on [Ibis]<Voice> don't compress hardly at all, but the one I did on my own Alto compresses quite a bit.  I would surmise that I have some leading and trailing silence on mine, and you don't on yours.

Here are the figures for page sizes of the compressed files, for different values of the silence threshhold:

Threshhold	NewT1 (171 pages)	QBF.u255 (61 pages)
----------	----------------	--------
   0		      139		    62
   3		      117		    62
   5		      112		    61
   9		      106		    61
  13		      100		    60

For QBF, it actually gets a little larger with run-encoding, because of the one byte per page overhead of the scheme.   But no value of silence that I tried gets any significant compression for QBF.  On the other hand, silence = 5 gets us 34% compression on NewT1.  I've decompressed the file and listened to it, and I can't hear any difference from the original.

Bob    
*start*
00510 00024 US 
Date: 26 Aug. 1982 9:30 am PDT (Thursday)
From: Swinehart.PA
Subject: New Larkbase.df, Larkcomm.df
To: Stewart
cc: Swinehart

As of a few minutes ago.  Larkbase is yours of 8/25, 1718, with some additional
definitions in Encrypt.h.  Larkcomm includes DES interface software and
modifications to RPC.  It doesn't work right now, probably.

We should probably sandwich each change to these files with a
	(check mail), (change file), (send message) protocol.  This is the first
instance.

*start*
00210 00024 US 
Date: 26 Aug. 1982 10:45 am PDT (Thursday)
From: Swinehart.PA
Subject: Another LarkComm.df
To: Stewart
cc: Swinehart

RPC test program tries to use OS.rel.  LOC runs out of space.

Dan

*start*
00467 00024 US 
Date: 26-Aug-82 14:32:56 PDT (Thursday)
From: Dalal.pa
Subject: Steven Milne
To: Irby, Verplank, Swinehart, Stewart, Koch, Holland (for Skinner)
cc: Dalal.pa

Eric Frank, his headhunter, called to tell me that Steven Milne will not be coming to Xerox.  He accpeted an offer from a start-up called Sysdek or something (here's one that even I haven't heard of) thats been around for 6 months and is building office systems (what else).  Sigh...
*start*
02110 00024 US 
Date: 30 Aug. 1982 3:34 pm PDT (Monday)
From: Stewart.PA
Subject: Analog problems
To: VoiceProject^
cc: Stewart

There are a number of interrelated residual problems with the analog stuff.

Crosstalk and noise.
	Teleset DTMF tones can be heard through the speaker when not intended.
	The GoOffHook relay produces clicks that can be heard in the speaker.

The breadboard has a set of problems like this, that can probably be fixed.  How
do we get to PC board without re-introducing them?

Gains around the system

The codecs tend to clip, producing digital sequences which correspond to
unpleasant distortion.

The codec synthesized touch tones are not loud enough to trip central office
dial-tone.

The Telewall transmit path in general is not loud enough.

The Teleset transmit amplitude is greater than typical receive amplitude.  This
seems to represent some estimate of loop resistance.  Should the Telewall also
have asymmetric levels?  Some of the varistors in a standard telephone are there
to adjusrt the transmit level according to loop resistance.  We have no such
mechanism.

	The Teleset interface has residual problems.  The hybrid echo has a
whine associated with it sometimes.  This seems to be caused by the varistor
enetering non-linear operation.  What is the varistor for anyway?  (I don't
understand the SDD hybrid.)

I don't understand what the voice vs. tone levels should be at the subscriber or
the CO end of a local loop.  How do we find out?

We need to find out about the 'experimental' lines for using non-registered
equipment.  We need to start thinking about registration.  Is SDD's gadget
registered yet?

I have gone to a separate inverter ring oscillator for the DTMF crystal.  is it
really needed?  I had no luck using the built in oscillator in one chip to drive
the others.

The speaker amplifier inputs may be too high impedance, causing noise pickup.

The teleset interface inputs may be too high impedance.

The crossbar switch might be better placed around 0 volts and/or operated from
higher supply voltage, to better accomodate large signals.

*start*
00287 00024 US 
Date: 30 Aug. 1982 5:47 pm PDT (Monday)
From: ornstein.PA
Subject: Re: Tale of the interrupts
In-reply-to: Stewart's message of 22 Aug. 1982 2:39 am PDT (Sunday)
To: Stewart
cc: VoiceProject^
Reply-To: ornstein

I'm glad I was away while this was happening!

S.

*start*
01431 00024 US 
Date: 31 Aug. 1982 1:07 pm PDT (Tuesday)
From: Stewart.PA
Subject: Stitchweld Work Request
To: Quan.pa
cc: RRicci, Stewart, VoiceProject^.pa 

XEROX	STITCHWELD WORK ORDER	(submitt one order per board)

To Engineering Support	Engrg Sprt Appvl		LOG NO.	

				Priority 2=Nor

Submitted By: L. Stewart	Ext. 4477	MS 35-2088  8/31/82

Organization PARC/CSL	 Project Voice	 Budget Center 55

Board Type ETT	Rev Ah	Date Required 9/6/82

Serial No. 2    New [   ]  or  Rework From Bd Rev Ag [ X ] (check one)

Special Instructions: 

Retrieve File	[   ]    or    Load Dump File [ X ]  (check one) 	

ETP-Rev-Ah.ad from	[Indigo]<Voice>ETP>ETP-Rev-Ah.dm


Work Performed:					Date Completed     /    /

	Continuity Check:	(     ) Pins @ 0.5 units/pin =	(     ) Units.
	Trace Cuts:		(     ) Cuts @ 2 units/cut =	(     ) Units.
	New Welds:		(     ) Welds @ 1 unit/weld =	(     ) Units.
	IC Removal:		(     ) Removals @ 1 unit/IC =	(     ) Units.
	Weld Removal:	(     ) Welds @ 2 units/weld =	(     ) Units.
	Rework Welds:	(     ) Welds @ 1 unit/Weld =	(     ) Units.
	IC Insertions:	(     ) IC's @ 2 units/IC =		(     ) Units.
							   Total:	(     ) Units.
	Other (describe):


			Total:	(	) Units @ ($ 	)/unit =  ($ 		)
				(   	) Hours @ ($ 	)/hr. =   ($  	)

							Total This Job:  ($		)

[Iris]<Quan>StitchweldOrder2.form

*start*
01431 00024 US 
Date: 31 Aug. 1982 1:07 pm PDT (Tuesday)
From: Stewart.PA
Subject: Stitchweld Work Request
To: Quan.pa
cc: RRicci, Stewart, VoiceProject^.pa 

XEROX	STITCHWELD WORK ORDER	(submitt one order per board)

To Engineering Support	Engrg Sprt Appvl		LOG NO.	

				Priority 2=Nor

Submitted By: L. Stewart	Ext. 4477	MS 35-2088  8/31/82

Organization PARC/CSL	 Project Voice	 Budget Center 55

Board Type ETT	Rev Ah	Date Required 9/6/82

Serial No. 3    New [   ]  or  Rework From Bd Rev Ag [ X ] (check one)

Special Instructions: 

Retrieve File	[   ]    or    Load Dump File [ X ]  (check one) 	

ETP-Rev-Ah.ad from	[Indigo]<Voice>ETP>ETP-Rev-Ah.dm


Work Performed:					Date Completed     /    /

	Continuity Check:	(     ) Pins @ 0.5 units/pin =	(     ) Units.
	Trace Cuts:		(     ) Cuts @ 2 units/cut =	(     ) Units.
	New Welds:		(     ) Welds @ 1 unit/weld =	(     ) Units.
	IC Removal:		(     ) Removals @ 1 unit/IC =	(     ) Units.
	Weld Removal:	(     ) Welds @ 2 units/weld =	(     ) Units.
	Rework Welds:	(     ) Welds @ 1 unit/Weld =	(     ) Units.
	IC Insertions:	(     ) IC's @ 2 units/IC =		(     ) Units.
							   Total:	(     ) Units.
	Other (describe):


			Total:	(	) Units @ ($ 	)/unit =  ($ 		)
				(   	) Hours @ ($ 	)/hr. =   ($  	)

							Total This Job:  ($		)

[Iris]<Quan>StitchweldOrder2.form

*start*
01431 00024 US 
Date: 31 Aug. 1982 1:07 pm PDT (Tuesday)
From: Stewart.PA
Subject: Stitchweld Work Request
To: Quan.pa
cc: RRicci, Stewart, VoiceProject^.pa 

XEROX	STITCHWELD WORK ORDER	(submitt one order per board)

To Engineering Support	Engrg Sprt Appvl		LOG NO.	

				Priority 2=Nor

Submitted By: L. Stewart	Ext. 4477	MS 35-2088  8/31/82

Organization PARC/CSL	 Project Voice	 Budget Center 55

Board Type ETT	Rev Ah	Date Required 9/6/82

Serial No. 4    New [   ]  or  Rework From Bd Rev Ag [ X ] (check one)

Special Instructions: 

Retrieve File	[   ]    or    Load Dump File [ X ]  (check one) 	

ETP-Rev-Ah.ad from	[Indigo]<Voice>ETP>ETP-Rev-Ah.dm


Work Performed:					Date Completed     /    /

	Continuity Check:	(     ) Pins @ 0.5 units/pin =	(     ) Units.
	Trace Cuts:		(     ) Cuts @ 2 units/cut =	(     ) Units.
	New Welds:		(     ) Welds @ 1 unit/weld =	(     ) Units.
	IC Removal:		(     ) Removals @ 1 unit/IC =	(     ) Units.
	Weld Removal:	(     ) Welds @ 2 units/weld =	(     ) Units.
	Rework Welds:	(     ) Welds @ 1 unit/Weld =	(     ) Units.
	IC Insertions:	(     ) IC's @ 2 units/IC =		(     ) Units.
							   Total:	(     ) Units.
	Other (describe):


			Total:	(	) Units @ ($ 	)/unit =  ($ 		)
				(   	) Hours @ ($ 	)/hr. =   ($  	)

							Total This Job:  ($		)

[Iris]<Quan>StitchweldOrder2.form