*start*
00986 00024 US 
Date: 8 March 1982 3:51 pm PST (Monday)
From: Stewart.PA
Subject: Delay Lines
To: VoiceProject^.pa
cc: Stewart

We ordered Bel Fuse Inc. 0447-0100-10, TTL compatible, 10 tap 10 ns per tap
delay lines, at about $40 each.

I talked to R. Thompson, a Los Gatos rep for Bel Fuse,  408-395-7171

He told me that the 10 tap parts are hybrids, with 2 chips in the same package.  

The 0447-0100-02, a 5 tap 20 ns per tap part, is $10-$12 at 100 quantity.

Our design, (ETR06.sil) uses the following taps:

tap 10 -  turn off CAS after the end of RAS
tap 20 -  extend RAS during writes from the encryption chip to memory
tap 30 -  switch from row addresses to column addresses
tap 40 -  start CAS 40 ns after RAS during reads
tap 100 - start CAS 100 after RAS during writes

CAS turnoff can be immediate or tap 20
Address switching can be tap 20

So we can use the 5 tap, 20 ns per tap devices!

Mike will talk to Joe Patti tomorrow about switching the order.

	-Larry

*start*
00424 00024 US 
Date: 8 March 1982 4:04 pm PST (Monday)
From: ornstein.PA
Subject: Re: Delay Lines
In-reply-to: Stewart's message of 8 March 1982 3:51 pm PST (Monday)
To: Stewart
cc: Ornstein

Great!

Does that mean we should abandon the 8203 approach - especially given the
SLC's untestedness re. fielding Ready? Or are you close enough to the end of
that road anyway that we can look and compare costs, etc? 

S.

*start*
01584 00024 US 
Date: 9 March 1982 9:09 am PST (Tuesday)
From: Stewart.PA
Subject: practical voice recognition
To: VoiceInterest^.pa
cc: Stewart
Reply-To: Stewart

------------------------------
Date: 2 March 1982 19:36 est
From: Frankston.SoftArts at MIT-MULTICS
Reply-to: Frankston at MIT-MULTICS (Bob Frankston)
Subject: Major breakthrough -- practical voice recognition

Or at least, ABC TV thinks so.  From an article in the Boston Globe,
Tuesday, March 2, 1982, page 31.  The article is by Bill Collins,
Kight-Ridder Service. It is discussing why NBC is planning to drop
close captioning.

     ABC, however, believes that Real Time is a breakthrough.  it
     works by way of an electronic stenographic device that feeds
     spoken words into a computer, which translates them almost
     instantly into printing.  This happens so quickly that the
     captions can be fed into the television signal even though they
     are transmitted from NCI headquarters in Falls Church, Va., and
     the TV show comes from thousands of miles away.

     "It not only turns spoken words into writing, but will pick up
     the usage fo the word and spell it right," said AVC spokesman
     Herb Wurth.  "For instance, it will pick the difference bewteen a
     color that is `red' and a book that is `read.'"

Possibilities:
     1. There is one born every minute.

     2. There is a major breakthrough of which I am totally unaware.

     3. There is a little person inside a machine in Falls Church,
        Va typing at a furious pace.

Anyone know anything more about it?

*start*
00979 00024 US 
Date: 10 March 1982 6:49 pm PST (Wednesday)
From: Stewart.PA
Subject: ETT ??
To: VoiceProject^.pa
cc: Stewart

I am pondering the effects of plugging in 8 MHz 8088s into the ETR (delay line)
design.

1)  Main CPU would need 1 wait state for IO references and ROM reads.
2)  Memory control simplified because Encryption writes need not be extended.
3)  Slave CPU can get by without any of the tricks, removing 3 or four chips
4)  Main CPU performance increased 40% - 60%, since the 150 ns rams are fast
enough to run with either 0 or (possibly 1 if we screw up) wait states.
5)  We could spend a few of those cycles by using interrupt based refresh,
eliminating both the DMA channel arbiter and the hardware refresh controller.
An alternative might be one of the execute in parallel slave cpu controlled
refresh schemes.  I have to think about it.
6)  The timing comes close to not needed CAS tap switching for writes, but not
quite!

	Stay tuned - Larry

*start*
05256 00024 US 
Date: 11-Mar-82 15:11:29 PST (Thursday)
From: verplank.pa
Subject: Re: Voice volumes
In-reply-to: Swinehart's message of 11 March 1982 8:05 am PST (Thursday)
To: Swinehart, Stewart, Pasco
cc: verplank, dalal, ndsmith, purvy.es, trigoboff, roberts

Dan, Larry, Rich,

I've had very little response to my request for info/opinions on voice volumes; more would be useful.  Any news on 32 or 16kb/s codecs?  Here's what I got:

----------
Date:  4-Mar-82 18:25:12 PST (Thursday)
From: Murray.PA
Subject: Re: Voice volumes
In-reply-to: Your message of 4-Mar-82 16:15:57 PST (Thursday)
To: verplank
cc: Murray.PA

I'd like to know if you get any info.  Those numbers seem low to me -- they reflect the ugliness of talking to somebody while a message is written down by hand.  I'd guess that voice will take off shortly after it works.
----------
Date: 5 March 1982 11:01 am PST (Friday)
From: Elkind.PA
Subject: Re: Voice volumes
In-reply-to: Your message of 4-Mar-82 16:15:57 PST (Thursday)
To: verplank
cc: Elkind

Bill,

I have two suggestions: 1) Get data on the use patterns of telephone answering
devices.  Several groups in the company routinely use these to accept telephone
messages.  2) See what happens if you take "typical" Luarel traffic and assume
that it was all transmitted by voice instead of text.  I bet you could get some
interesting traffic volumes from these two sources that would be more relevant
than off the wall estimates.

Jerry
----------
Date: 5 March 1982 11:25 am PST (Friday)
From: Halbert.PA
Subject: Re: Voice volumes
In-reply-to: Your message of 4-Mar-82 16:15:57 PST (Thursday)
To: verplank

I find the predictions shortsighted, just as I'm sure the original predictions about
text electronic mail were too. Text electronic mail is a non-instrusive form of
communication. Voice mail could be, too. If the system were able to queue voice
at any time, not just when a phone didn't answer, or was busy, then it might be
used for all sorts of messages. We can't predict what kind without trying it.
People who can't type would be very inclined to use it for many of things we
now use text mail for, for instance. Etc.

--Dan
----------
Date:  5-Mar-82 14:35:51 PST (Friday)
From: Purvy.ES
Subject: Re: Voice volumes
In-reply-to: verplank.pa's message of 4-Mar-82 16:22:50 PST (Thursday)
To: verplank.pa
cc: Dalal.pa, NDSmith.pa, Trigoboff.pa, Purvy, Roberts.pa, Braun

I found it kind of hard to understand all of this.  What does "On the basis of statistics gathered by BBN's computerized PBX, we estimate that approximately 1500 call attempts (including internal and external calls either receive no answer, or receive a busy signal, or are picked up by BBN's Message Center" mean,  aside from the unbalanced parentheses?  How many people are on the net, or does it matter?  Etc?

What's an erlang?

But I guess the bottom line is that you need 100 megabytes of storage per day for voice messages, if you have 500 messages of 30 seconds each per day?  That says that a T-300 will hold three days of messages.  If you assume that most messages are played and deleted on the same day they're sent, or the next day, then there shouldn't be any problem of running out of space.

Whether all this puts too much of a burden on the Ethernet is something for Yogen to answer.

Bob  
----------
Date: 7 March 1982 12:17 pm PST (Sunday)
From: sasmith.PA
Subject: Re: Voice volumes
In-reply-to: Your message of 4-Mar-82 17:48:09 PST (Thursday)
To: verplank
cc: SASmith

Bill,

I can give you some comments on the projections in Richer's article and a few
numbers that may help project voicemail traffic.

Richer's figures on telephone calls per day per person seem pretty typical. 
Average calls per day per person are often estimated at three to four, with 60 to
75% unsuccessful in reaching the desired person.

The number of these that would show up on a store-and-forward voice system,
plus new volume that might appear, is a matter of conjecture at this point.  Our
Laurel study is showing a little over one text message originated per day per
person over all classes of users in Xerox.  Some other studies have observed as
many as four per day in non-research environments.  My own best guess is that
most of the unsuccessful calls (i. e., 2 to 3 per person per day) would appear as
messages, either text or voice, because once a voice msg systems are widespread,
they would tend to eliminate the current pink slip system.
Much traffic on text message systems (about 80% of msgs rec'd on Laurel) is
generated from distribution lists.  Thus, whether or not voice systems include
this feature and whether or not multiple copies of msgs are stored are very
important factors. 

Richer's estimate of 30 secs. per msg may be too high,  based on how long it
takes to tell somebody to call you back and why.  However, his total estimate of
30 secs per day per person is not a large % of the standard business voice traffic
per person per day (520 call seconds).

Clearly the 64 kbps sampling rate is unreasonable for voice msg systems, as
Richer points out.  Something in the 2.5 to 8 kbps range should be achievable.  I
believe Rich Pasco has a lot of technical information on sampling rates.

Steve S.
----------
*start*
01257 00024 US 
Date: 11 March 1982 4:20 pm PST (Thursday)
From: Stewart.PA
Subject: Re: Voice volumes
In-reply-to: verplank's message of 11-Mar-82 15:11:29 PST (Thursday)
To: verplank
cc: Swinehart, Stewart, Pasco, dalal, ndsmith, purvy.es, trigoboff, roberts

I disagree with "64 Kbps is too high for a voice message system."

A 300 Mb pack will hold 10.4 hours of speech at 64 Kbps.

64 Kbps is easy to build using standard Codecs etc.

64 Kbps is the standard for interactive voice.  Any move to incorporate lower bit
rate codecs into terminal equipment (telephones) will have to maintain the same
quality.  (I think we should keep the 64 Kbps bit rate and improve the quality
with better coding.)

If you don't put the low rate codecs into the terminal equipment, then you have
to put them into the server.

If you record messages at 64 Kbps and compress them at your leasure you may
save on coders, but the file server will still need adequate numbers of decoders
to decode in real time all simultaneous file retrieves.

I suspect that in the near term it will be easier to buy more disks than to get
involved in speech compression.  It can always be added later. (With the
compression at the server.)

	-Larry

Stick with big disks for now!

*start*
12609 00024 US 
Date: 11 March 1982 4:40 pm PST (Thursday)
From: Stewart.PA
Subject: Lark memory control, ETR+8 MHz CPU
To: VoiceProject^

What would be the effects of using 8 MHz CPUs in the ETR design?
We'd like to eliminate the tricks on the slave system and eliminate some
complexity of the memory control on the master system.

1)  Try to eliminate delayed CAS during writes.  (probably still need it)
2)  Try to eliminate extended RAS during DMA writes  (looks OK)

Lark main memory consists of 8 64K dynamic rams to hold the bits, an Am2964B
dynamic RAM controller to generate the address, a delay line to generate RAS
and CAS timing, and some small scale logic to sort out the various kinds of
cycles.

We have ordered RAMs with 120 ns RAS access time, but suspect that 150 ns
chips would work in all cases.  TImings below are worked out for the 150 ns
chips.

A DRAM cycle consists of RAS, which must last at least 150 ns.  40 ns after
RAS, CAS starts and lasts until slightly after RAS  (They can end at the same
time).  If the WriteEnable RAM pin is activated at the start of CAS, the cycle in
a write.  In this case, the RAM output remains in tri-state and data at the input
is latched at the beginning of CAS.  During a read (no WriteEnable), the chip
output leaves tristate after the start of CAS and remains enabled until the end of
CAS.  A refresh cycle does not need a CAS, but may have one, in which case it
is a normal read as well.  Not using CAS saves chip power.

Reads:

Main CPU and SLC

These devices get special treatment on reads.  When IO is low (a memory cycle),
and PDT is low (a read), then the signal EarlyRead' is asserted at the end of
ALE'.  This serves to get the memory cycle started a bit early to compensate for
the fast memory requirements of the SLC running at 2.94 Mbps.  When the
actual Rd' signal comes along, it both takes over the job of providing RAS and
clears the EarlyRead flipflop.

PDT and IO have the same timing as addresses, they can be safely latched with
ALE.  Whenever there is an ALE, there is guaranteed to be a cycle coming, and
PDT will always accurately reflect whether it will be a read or a write.

We want the system to work with a 2.94 Mbps SLC.  The timing requirements for
memory read are:

SLC:
Tlc1 NALE end to NSTROBE				 45
Trd NRD low to data valid					105
The formula is  Trd = 3/2T - K6, where
K6 <= 150 ns.  Frank Nelson mentioned that if its gonna work at 12 MHz, then
K6 is probably smaller, but probably not as small as 75.

So from the end of ALE to read data required is at least 150 ns and possibly as
much at 200 ns.

8088:
	End of ALE is <= 55 ns after rising edge of SysClock in T1.
	Data must be valid 20 ns before the falling edge of the clock at the end of
T3.  The total time is all of T3 less 20, plus all of T2, plus 1/3 of T1 less 55 =
222.5 ns.

8088 Reads:

Trldv for 7.843 MHz 8088, no accounting for latch/buffer delays

2Tclcl-Tclrl-Tdvcl = 255-100-20=135  Not enough, even for 150 ns RAMs

Alternate config.  (Early read)

2Tclcl+Tchcl-Tchll-Tdvcl=255+42.5-55-20 = 222.5

ROM reads:

Starting at the falling edge starting T1: Tcldv = 3Tclcl-Tdvcl = 382.5-20 = 362.5. 
Allowing 32 for the 8286 data transceiver leaves 330.5, less 250 for the EPROM
leaves 80.5.  However, the addresses don't get through the address latch possibly
until a strobe enable time after ALE, which is two gate delays from the CPU. 
The addresses are valid either Tclav+ T8282data = 60+30 = 90 OR
Tcllh+T8T09+Tls04+T8282strobe = 50+10+15+45 = 120.  Either reason will keep it
from working.  We need one wait state for ROM reads!

Notes: We could move the EPROM to the AD bus, saving 32 ns.  We could use
an S04 to invert ALE', saving about 10 ns.  We could use an S373 in place of the
8282 to get data delay of 13 ns and clock delay of 18.  An LS373 would be data
delay of 27 and clock of 36, but these are for low capacitance on the LA bus. 
(There is only the 8237, the 2964, and the EProm on that bus! 50 or 60 pf might
be right!)

The combination of moving the EPROM to the AD bus and using an S373 would
do it.

Oddly enough, the S373 takes 250 microampere drive while the LS373 takes 400! 
The S part is twice the speed for 4 times the supply current...

Note:  We can use the (faster) 8287 and invert MD by inverting the EPROM
data.   NO!  WD2001 must be on MD bus to allow sufficient data hold time for
fast 8088.

Main memory reads:

The logic chain between ALE' and data on the AD bus is:

		Typ		Max
8T09		10		10		PALE to ALE'  cpu only
S74 		6		9
S20		3		4.5
S02		3.5		5.5
2964B		14		20
Chips		120		120

8287 xcvr	12		22		300 pf on AD bus
tot SLC:	158.5		181
tot CPU:	168.5		191

8286 xcvr	22		30		300 pf on AD bus
tot SLC:	168.5		189
tot CPU:	178.5		199

totCPU:	208.5		229		with 150 ns RAMs and 8286

CPU reads will work using 120 ns RAMs, but not, if using 150 ns RAMs and
worst case times.

The consequence of this logic is that the 3 Mbps SLC will work only if K6 is
somewhat smaller than specified for the 1.5 Mbps part.  We should ask MEC I
guess.

It may also be possible to bypass the 2964 for RAS & CAS, using it only for
address multiplexing.  We need to save 7 ns somewhere if we don't want wait
states for main CPU reads.

Slave CPU

ROM reads:

Starting at the falling edge starting T1: Tcldv = 3Tclcl-Tdvcl = 382.5-20 = 362.5. 
Allowing 250 for the EPROM leaves 112.5.  However, the addresses don't get
through the address latch possibly until a strobe enable time after ALE.  The
addresses are valid either Tclav+ T8282data = 60+30 = 90 OR Tcllh+T8282strobe =
50+45 = 95.  So the Slave CPU can read its own ROM with no wait states.

The slave CPU starts shared memory reads by asserting Rd' after aquiring the
main busses.  There are sufficient wait states in the SlaveDAck path to absorb
the delay between Rd' and the Slave data bus.

The logic chain between GSlaveDAck and data on the SAD bus is:

		Typ		Max
LS125		15		25
S20		3		4.5
S02		3.5		5.5
2964B		14		20
Chips		150		150
8282 latch	22		30		300 pf on AD bus
2764		250		250
Tot:		457.5		485

There are two D-flop stages between GSlaveDAck and SlaveReady, and data is
sampled a full cycle after that less 30 ns for an available budget of 570 ns.

DMA (DMA reads memory and writes into Encryption chip)

8237A-5 specs
TDCL		clock high to Wr' or Rd' low	max 190
TDCTR	clock high to Rd' high		max 190
TDCTW	clock high to Wr' high		max 130

The DMA controller must be set up with normal reads and extended writes.  In
this mode, MRd' and IOWr' are asserted at the same time, and for about 510 ns
each.    Memory data will be available roughly 150 ns after MRd' starts.  Data is
required at the WD2001 130 ns before the end of Wr'.  Thus 280 ns of the
available 450 is used up.

Note:  Minimum specs on TDCTW and TDCTR are not published!  I am assuming
that TDCL and (TDCTW or TDCTR) track.

The nominal Rd' and Wr' widths are 2 cycles wide, 255 ns each.
These totals must be less than 510 ns, the nominal Rd' and Wr' widths.

		Typ		Max
TDCL		190		190
LS125		15		25
S20		3		4.5
S02		3.5		5.5
2964B		14		20
Chips		150		150
8286 xcvr	22		30		200 pf on AD bus
2001 setup	130		130
TDCTW	-130		-130		(negative because AFTER 2nd clock
Tot:		397		425

Chips		150		150
8287 xcvr	12		22		200 pf on AD bus
Tot:		387		417

Chips		120		120
8286 xcvr	22		30		200 pf on AD bus
Tot:		367		395

Chips		120		120
8287 xcvr	12		22		200 pf on AD bus
Tot:		357		387

The DMA controller can use normal writes because the minimum write pulse
width from the 8237A-5 (195 ns) is longer than the minimum write pulse
required by the WD2001 (175 ns).  This is not relevant however, either will
work!

WRITES:

Since data is required at the memory chips when CAS starts (setup time = 0),
CAS is delayed for writes by switching taps on the delay line.  For reads, CAS
follows 40 ns behind RAS.  For writes, the delay is 100 ns.

Can we do without this delay?  (Apparently not, but we might put a delay
where Wr' enters the S20!)

Main CPU:

Beginning of writes:  The data must be there by when the RAMs need it.

Twldv for 7.843 MHz 8088 = Tcldv-Tclctv = [10..70]-[10..60] = [-50..60]
	Data buffers make things worse (lengthen Twldv)
	Wr' buffers make things better (delay Wr')

The worst case would need to delay Wr (CAS) by 20 ns to add to the 40 ns RAS
to CAS delay to get the data to the memories before CAS

End of writes:  The data must still be present when the RAMs grab it

Twhadv for 7.843 MHz 8088, no accounting for latch/ buffer delays
	Data buffers help by keeping the data longer
	Wr' buffers hurt by delaying Wr'

2Tclcl+Tclch+Tchdx-Tclctv = 255+85.4+10-70=280.4

For an 8088 (7.843 MHz), the leading edge of Wr' follows the rising edge of
SysClock by 10 to 70 ns.  Data is valid after the same edge by 15-60 ns.  One
assumes these delays track, but even if they don't, the timing still works.  There
is one bus transceiver between AD and MD, and several gates between PWr' and
the RAS pin of the chips, plus the 100 ns delay.

We'll count delays to the control signal as negative and delays to the data as
positive.  The answer should come out negative, the amount by which the data
is late at the chips should be negative.  I've reversed the 8286 typical and worst
cases because they work the other way...

		Typ		Max
LS125		-15		-25
S20		-3		-4.5
S02		-3.5		-5.5
2964B		-14		-20
CAS		-100		-100		with tap switching
CAS		-40		-40		without tap switching
8286 xcvr	32		22		200 pf on MD bus
8088 data	60		60		assumes worst data, best Wr'
Total:		16.5		-13		without tap switching
Total:		-43.5		-73		with tap switching

So tap switching is needed

SLC

We have been told by El Segundo that the SLC starts to drive the data lines at
the same time Wr' is asserted.  The SLC writes will work unless the differential
skew between the data and Wr' exceeds 100 ns.  (Given tap switching!)

Slave CPU

The slave CPU, when requesting a shared memory write cycle, typically asserts
SlaveWr' and the data (on the slave side of the MD drivers) and then waits for
GSlaveDAck.  This signal simultaneously enables both Wr' and MD' so again, the
skew will not exceed 100 ns.

DMA (DMA reads from Encryption chip and writes to memory)

The DMA operates at 1/2 7.843MHz = 255 ns cycles

The 8237A-5 must be operated with normal reads and normal (short) writes. 
Because the minimum width MWr' from the 8237A-5 is 195 ns, and this signal
directly generates RAS.

The WD2001 delivers data 220 ns after Rd' is activated.  The data must get to the
memory 100 ns after Wr' is activated.  By using the 8237A-5 modes described
above, the Wr' pulse is delayed 255 ns after the Rd' pulse.  Thus the data from
the WD2001 arrives 35ns before RAS, but is not needed until 40 ns after RAS
(even without using tap switching!) and all is well.  The end of RAS is does not
need to be extended extended to meet the specs for 150 ns memory chips.

8237A-5 	-255		-255		due to delay of control signal
LS125		-15		-25
S20		-3		-4.5
S02		-3.5		-5.5
2964B		-14		-20
CAS		-100		-100
WD2001	220		220
8286 xcvr	32		22		200 pf on MD bus
Tot:		-138.5		-168


------------------------------------------------------------
The main CPU will need an IO wait state.  (1 will do, 2 are OK, since there are
few IO cycles.)

IO to SLC:  In this case, the SLC provides SLCReady', which can be directly fed
to the 8284A.  Using the additional SysClock' synchronizer adds an unneccessary
wait state, but there is little IO to the SLC so it doesn't matter.

IO to other devices.  Other devices do not generate Ready.  In order to give other
devices Rd' and Wr' pulses of adequate width, we provide a wait state generator.

		Trldv		Tdvwh	Tdvawh	Trlrh		Twlwh
8255A-5	200 (150pf)	100		30		300		300
8259A-2	120 (100pf)	160		0		160		190
8274		200 (150pf)	150		0		250		250
WD2001F-30	220 (50pf)	130		60 !!		300		175
9513		160 (100pf)	80		0		160		150
8237A-5	140 (100pf)	160		30		200		160

So 1 wait state works in the worst case.  By the same logic used for ROM reads,
if the decoded addresses generate ready, then if the input to the 8284 is valid
after the rising edge of T1 but before the edge of T2, then there will be one wait
state.  Two wait states would be perfectly acceptable since there are few IO
references.

There is a problem with write data hold time for the WD2001.  The  WD2001
needs 60 ns, and the 8088 can only guarantee 55.  One possible solution is to
hang the WD2001 on the memory bus (MD) instead of the processor bus (AD). 
This will provide additional hold time since the bus transceiver would delay the
data from the 8088.  This would require that we use non-inverting transceivers
(e.g. 8286).


*start*
00364 00024 US 
Date: 12 March 1982 12:50 pm PST (Friday)
From: NDSmith.PA
Subject: Re: Voice volumes
In-reply-to: Stewart's message of 11 March 1982 4:20 pm PST (Thursday)
To: Stewart
cc: verplank, Swinehart, Pasco, dalal, ndsmith, purvy.es, trigoboff, roberts

I heartily agree with Larry. Speech compression is a tar pit, at the moment. 

						Nancy


*start*
03714 00024 US 
Date: 12 March 1982 8:21 pm PST (Friday)
From: Stewart.PA
Subject: Chip counts for Lark ETT design
To: Voiceproject^.pa

Second colum is page number on ETT prints.

40 pin packages:
8088		1	Main CPU
8237A-5	1	DMA controller
8274		3	RS-232 controller
9513		4	Programmable Timer
SLC		5	Ethernet controller
8255		7	PIO
8255		7	PIO
8088		9	Slave CPU

	Total:		8

28 pin packages:

WD2001F-30	4	Encryption
8259A-2	4	Interrupts
I2764		7	Main CPU EPROM
I2764		9	Slave CPU EPROM  (250 ns)

	Total:		4

24 pin packages:

20 pin packages:

S373		1	Main CPU and SLC address latch
8282		1	8237A-5 address latch
8286		1	Memory data bus transceiver
8287		2	Offboard bus transceiver
LS240		2	Offboard control line driver
LS240		2	Offboard control line driver/receiver and inverters
8282		9	Shared memory address (high)
8282		9	Shared memory address (low)
8286		9	Shared memory data transceiver
8282		9	Local address latch
LS299		9	Input shift register

LS374		all	synchronizers

	Total:		12

18 pin packages:

8284A		1	Clock generator

	Total:		1

16 pin packages:

LS138		2	IO Address decoding
256x4 rom	2	Main system control signals
LS153		2	Wr' and Rd'
N123		3	Watchdog timer and reset pulser
PLAT		3	Timing components for N123
PLAT		5	Ethernet terminators and pullups
S158		6	CASIn' generator
S158		6	Address multiplexor
S158		6	Address multiplexor
PLAT		6	Damping resistors
PLAT		7	DIP switches
PLAT		7	DIP switches for ID register
26LS31	7	RS-422 drivers
26LS32	7	RS-422 receivers
64K RAM	8	0
64K RAM	8	1
64K RAM	8	2
64K RAM	8	3
64K RAM	8	4
64K RAM	8	5
64K RAM	8	6
64K RAM	8	7
LS166		9	Output shift register
32x8 rom	9	Slave control ROM

	Total:		24

14 pin packages:

1488		3	RS-232 receiver
1489		3	RS-232 driver
12.288MHz	4	Audio clock
23.53MHz	5	Processor and Ethernet clock
100ns		6	Memory control delay line

	Subtotal:	5

	LS00 sections
		2	IO' OR Syn(Rd OR Wr)
		10	PreSlaveReq' OR SynGSlaveDAck'

	Subtotal:	1		(half empty)

	LS02 sections
		2	EnOffBoardBus
		6	RefDAck' AND RefReq'
		10	SelOSR AND SlaveWr'
		10	OSRClk'

	Subtotal:	1		(1 extra section)

	LS04 sections
		1	ALE  clock for main cpu address latch
		1	AEN' output enable for DMA address latch
		2	EnOffBoardBus'
		2	SelROM'
		2	SysClock'
		2	SelSLC
		3	SIOInt to interrupt controller
		5	RcvData'
		5	EtherIn
		5	FClock
		6	CascadeReq'
		9	SynTSN'
using LS240 section:
		2	SLCDAck
		2	Reset'
		2	BAd01'
		2	BAd02'

	Subtotal:	2	(use 20 pin bus inverter?)  also 4 sections of 240 left

	LS08 sections
		2	(Wr' OR Rd')'
		3	res'
		3	WDTReset' OR ManReset'
		9	AudShClk

	Subtotal:	1

	LS11 sections
		4	WD2001 pin A0
		4	WD2001 pin CS'

	Subtotal:	1		(1 extra section)

	S10 sections
		6	RAS0  (start memory cycle)
		6	RAS0'

	Subtotal:	1		(1 extra section)

	LS32 sections
		3	KickWDT OR Reset
		7	SelPIO' AND Wr'
		6	MWE'
		9	GSlaveDAck'

	Subtotal:	1

	LS38 sections
		5	XmtData'  (Ethernet)

	Subtotal:	1

	LS74 sections
		3	ManReset SR flop  (pushbutton debounce)
		4	EncInt

	Subtotal:	1

	S74 sections
		6	EarlyRd'
		7	ManNMI SR flop  (pushbutton debounce)

	Subtotal:	1

	LS393 sections
		4	T1Clk and multiples  (12.288 MHz crystal)
		5	Ethernet clocks

	Subtotal:	1

	8T09 sections
		1	PALE -> ALE'
		2	SLCReady'
		5	SLC pin R/W' -> PDT

	Subtotal:	1

D-flop sections
SysClk'	1	Hold synchronizer
SysClk'	2	Wait state generator
SysClk'	4	SynTSN synchronizer
SysClk'	4	  same
SysClk'	9	SlaveReady
SysClk'	9	SynGSlaveDAck'
SysClk'	9	SlaveReq

	Subtotal:	1	(20 pin)

	Total:		18

SIPS
		7	AD pullups
		7	SAD pullups
		7	MD pullups
		7	ID pullups
		7	extra bus pullups & MOS
		7	TTL pullups
		7	More TTL pullups

Totals:
	40 pin	8
	28 pin	4
	20 pin	20
	18 pin	1
	16 pin	24
	14 pin	18
	SIP		7 or 8 if more MOS pullups needed
*start*
01472 00024 US 
Date: 17 March 1982 10:32 am PST (Wednesday)
From: ornstein.PA
Subject: Update Report on Various Items
To: Stewart
cc: VoiceProject^
Reply-To: ornstein

1. I've got Hartnet's assistant (He was out) working on the problem of getting us
early samples of the 8088-2 and 250 ns. 2764's. She (or he) will call us.

2. I talked to Markle in El Segundo - told him about the ability to transmit but
not receive at nominal 3 MHz (he was very interested) - briefly summarized the
Ready problem (he said they had a problem in some useage that might be
explained by that) - also asked him to expedite the microcode listings which he
said he'd do.

3. Delay lines - it seems the cheaper 20ns tap ones have long delivery (June) as
they have to be made to order. So Mike says he told you we were sticking with
the older ones ($40 each) which are due in April 3 (Joe is checking to see if we
can get them before that - mfgr. is on east coast. So we don't have any order in
for cheaper ones; I think we should place one pronto, no? And change the
present dwgs. to the $40 jobbie for now. (Does this screw up the layout - is the
chip bigger - looks to me as though you allowed room??)

4. I'm waiting for a return call from Joe to check on Prom deliveries - they're
definitely ordered. I'll also ask him to investigate a 74153ALS. 

5. What are the AMD part numbers of the 8286 and 8287 equivalent? Couldn't
spot your AMD catalogue in the (ahem) chaos.

Cheers,

S.
*start*
00844 00024 US 
Date: 18 March 1982 1:07 pm PST (Thursday)
From: ornstein.PA
Subject: Loan of Alto 3K Cram to Bob Belleville
To: Levin
cc: Guibas, Stewart, ornstein, Taylor

Bob Belleville would like to borrow a 3K Cram on extended loan from CSL. We
have four:

	1. Lilac
	2. Etherphone
	3. Guibas'
	4. Spare

The first three seem out of the question as they are devoted to vital special use
and we certainly need a spare for repair.

The 2K Prom he's offering in exchange has Mesa 41 blown in it. I am led to
believe this would satisfy all Leo's needs (includes floating point) and in fact
that Leo wouldn't know the difference. The question is: am I led correctly? And
Leo, do you have any reason to care that you know of? Obviously if we tried it
and any problem materialized we would promptly reverse matters.

Comments?

Severo  

*start*
00340 00024 US 
Date: 19 March 1982 12:33 am PST (Friday)
From: Levin.PA
Subject: Re: Loan of Alto 3K Cram to Bob Belleville
In-reply-to: ornstein's message of 18 March 1982 1:07 pm PST (Thursday)
To: ornstein
cc: Levin, Guibas, Stewart, Taylor

Sounds OK, provided of course that Leo is happy with the proposed
arrangements.

Roy

*start*
01623 00024 US 
Date: 21 March 1982 9:14 pm PST (Sunday)
From: Stewart.PA
Subject: 2764 test patterns
To: Chang
cc: VoiceProject, McCreight, Stewart

[Indigo]<Voice>EP>Test2764.mesa is a Cedar program which generates test .mb
files for 2764s.  Since you probably cannot run it, I'll describe the output:

[Indigo]<Voice>Temp>IncLow.mb

Contains one memory, called IncLow.  It is 8192 8 bit values which repeat 0 - 255
over and over (32 times).  Thus the data is the low 8 bits of address.

[Indigo]<Voice>Temp>IncHigh.mb

Contains one memory, called IncHigh.  It is 8192 8 bit values.  The value 0
occupies the first 32 locations, the value 1 occupies the next 32 locations, and so
on up to the value 255 occupies the last 32 locations.  Thus the data is the high
8 bits of the address.

If you want any other data patterns, let me know.

Our 2764 sil macro has the following pin names:

pin	name
2	A0
23	A1
21	A2
24	A3
25	A4
3	A5
4	A6
5	A7
6	A8
7	A9
8	A10
9	A11
10	A12

11	Q0
12	Q1
13	Q2
15	Q3
16	Q4
17	Q5
18	Q6
19	Q7

1	VPP
27	PGM'
28	VCCA
26	VCCB
14	GND
20	CE'
22	OE'

The idea behind the second VCC pin is to allow plugging any of 2716 2732 and
2764 into the same socket.  Pin one of a 2716 would plug into pin 3 of the 2764
socket.


Notes on the Lark wiring:

In our system, we have wired the lsb data bit to Q0 and the lsb address to A0,
and both address and data are low true.  I should have made Pin 2 be the high
order address.  We will use the address reversal facility of PNEW to make 2764s
for our system for now and will probably require the addresses later.  Until then,
we cannot use 2716s.

	Larry
*start*
00458 00024 US 
Date: 21 March 1982 9:50 pm PST (Sunday)
From: Stewart.PA
Subject: Layout/stuffing/proms
To: VoiceProject^
cc: Stewart

I've marked up an updated ETT42.sil (layout) for Mike's stuffing efforts.

[Indigo]<Voice>ETP>*.mb are probable PROM conetents for the two proms, see
[Indigo]<Voice>EP>LarkProms.df if you are interested.

To do:  Cables for the J2 and J3 connectors:  Ethernet, Audio, Console
pushbutton, NMI pushbutton.

	-Larry

*start*
01092 00024 US 
Date: 21-Mar-82 23:05:54 PST (Sunday)
From: Chang.pa
Subject: New Pnew.run Handling Upto 16Kx16
To: McCreight.pa, Ornstein.pa, Stewart.pa
cc: Thacker.pa, Thompson.pa, Boggs.pa, Swinehart.pa, Pasco.pa, Chang.pa

I just modified Pnew.run to handle upto 16Kx16 PROMS (4Kx16 was the limit). I don't have any chip to try out, so really would like to have volunteers.....

File is on [MAXC]<Chang>Pnew.run. Two PROM-types have been added: #23 for I2732 and #24 for I2764 (assumed that they have nearly identical pin assignment like I2716 so the data output pins are reversed from our assignments). Also, in Diagnostic mode, LISTPROM, COPYPROM are capable to work on those large chips. Due to limited memroy Pnew fuse 4k location at a time and have to reload image in order to fuse the next 4k locations; to fuse a I2764 takes quite a long time.

Please let me known any problems as soon as possible.

P.S. to Servero and Larry: your personality module is in my office. If you have a chip you can try it out here in Bldg 96; the Dandelion Lab. has a ProLog programmer.

Tom 
*start*
00717 00024 US 
Date: 22 March 1982 8:56 am PST (Monday)
From: Stewart.PA
Subject: Speech compression
To: NDSmith, Verplank
cc: VoiceProject^

---------------------------

Date: 22 March 1982 8:25 am PST (Monday)
From: Eldridge.ES
Subject: Re: Voice Output
In-reply-to: Kinkead.DLOS's message of 18 March 1982 9:47 am CST (Thursday)
To: Kinkead.DLOS
cc: JOHNSON.HENR, Hallgren.pa, Griffith.pa, SunriseForum^.DLOS
Reply-To: Eldridge

I have an algorithm that compresses speech data from a Codec and will reduce
the data rate by half with little reduction quality.  Greater data rate reduction is
possible with some degradation in quality.

George

------------------------------------------------------------

*start*
01169 00024 US 
Date: 22 March 1982 9:55 am PST (Monday)
From: ornstein.PA
Subject: Hardware
To: CSL^, ISL^
Reply-To: ornstein

If you never have occasion to handle IC's from Mike's lab, read no further.

Over the past weekend someone borrowed Mike's key, went into the main IC
cabinet, left it unlocked, and put the key back in the wrong place. Also someone
used up the last 74S158 from an IC drawer and failed to notify Mike to order
more. So this morning when he went to stuff our board.......

By now we have some quite expensive and slow or difficult-to-replace stock. (I
know - we're using it in the Etherphone!) There's a small number of us who
have to use Mike's stock - if we don't ALL follow the rules of etiquette and
caution, I'm going to protect those of us who DO, by starting to lock things up
tighter. Nobody wants that so PLEASE - pay attention. 

(For common parts, it's easy to have main stock locked up tight with a few parts
available for general access. That gets harder as the parts become big, less
numerous, more-expensive, electrostatically sensitive, oddball, etc. Nonetheless, if
we have to do it, we will.)   

C'mon guys,

Severo

*start*
00868 00024 US 
Date: 22 March 1982 3:37 pm PST (Monday)
From: Stewart.PA
Subject: TI TBP18S030
To: Chang
cc: Stewart

Our Harris personality module has stopped working.  I used the same command
file (with 0/T substituted for 7/T) to program a TI TBP18S030.  The question is,
will the pinouts be the same?

Here's the original command file.

// MakeLarkSlaveProm.cm
// L. Stewart March 22, 1982  1:57 PM
// Use PM9039A personality card + PA16-2 pinout adapter +
//     32x8 (H) configurator
// Make a Harris 7603 Prom
PNEW LarkSlaveProm.mb/F LarkSlaveProm/M 7/T A/R 0/C 0/B 0/A 0/S

Here's the modified one.

// MakeLarkSlaveTIProm.cm
// L. Stewart March 22, 1982  2:43 PM
// Use PM9046 personality card + PA16-4 pinout adapter +
//     32x8 (L) configurator
// Make a TI TBP18S030 Prom
PNEW LarkSlaveProm.mb/F LarkSlaveProm/M 0/T A/R 0/C 0/B 0/A 0/S

	-Larry
*start*
01521 00024 US 
Date: 26 March 1982 11:45 am PST (Friday)
From: Stewart.PA
Subject: Parts for the ETT Etherphone
To: Overton
cc: VoiceProject^
Reply-To: Stewart

Type		    |    Numbers	| Comments

40 PIN
	I8088-2ES	2		8 MHz Processor		
	I8237A-5	1		DMA
	AM9513	1		Timer Chip
	I8274		1		Serial Line Controller
	I8255A-5	2		Parallel IO Ports
	SLC		1		Ethernet Controller

28 PIN
	8259A-2	1		Interrupt Controller
	WD2001F-30	1		Encryption Chip (or E-02)
	I2764		2		Eprom (250 ns)


20 PIN
	LS240A	2
	LS299		1		(Input) Shift Reg
	LS374		1
	LS373		2		
	S373		3		
	I8286		2
	I8287		1


18 PIN
	I8284A	1


16 PIN
	F93427	1		256 x 4 Prom
	HM4864-1	8		Hitachi 120 ns. 64K memory
	LS166		1		(Output) Shift Reg
	Dip Sw 	2		(16 pin Dip Switches)
	AM26LS31	1
	AM26LS32	1
	LS138		1
	PLAT		3
	N123		1
	LS153		1
	S158		2
	TPB18S030	1		32 x 8 Prom

14 PIN
	Delay Line	1		Bel Fuse 0447-0100-02
	1488		1
	1489		1
	LS38		1
	LS74		1
	LS32		1
	LS04		3
	LS08		1
	8T09		1
	LS00		1
	LS11		1
	LS393		1
	S10		1
	S74		1
	LS02		1

XTALS
	12.288 MHz	1
	23.53 MHz	1

------------------------------------------------------------

*start*
00576 00024 US 
Date: 5 April 1982 10:23 am PST (Monday)
From: Deutsch.pa
Subject: Re: Help!
In-reply-to: Your message of 1 April 1982 9:13 am PST (Thursday)
To: OKI
cc: D0Users^.pa
Reply-To: Deutsch

I have a complete set of microcode and a Bcpl driver program for running the
Dolphin RS232 port in asynchronous mode.  It has worked fine at speeds up to
9600 baud.  It does parity checking and generation, but no more complex
checking or protocols.  See [Phylum]<Deutsch>rs*.mc and rstest.bcpl. 
Documentation is practically non-existent, but I'll answer questions.

*start*
01363 00024 US 
Mail-from: Arpanet host SU-AI rcvd at 5-APR-82 1446-PST
Date: Mon Apr  5 13:37:31 1982
To: info-micro at mit-ai
From: ittvax!qumix!msc at Berkeley
Subject: 8086 compiler and assemblers
Source-Info:  From (or Sender) name not authenticated.


	This is in reply to arpavax:mosher's query. My mail reply was
	returned as undeliverable.

	Try Microtec in Sunnyvale, CA (408 733 2919) for cross
	assemblers written in FORTRAN IV, Virtual Systems in Walnut
	Creek, CA (415 935 4944) for cross assemblers written in
	Macro-11, Boston Systems Office Waltham, MA (617 894 7800) for
	the same, Whitesmiths in New York City (212 799 1200) for a C
	cross-compiler and assembler written in C, and Language
	Resources in Boulder, CO (303 449 8087) for Pascal

	Microtec's advantage is price and they give you the source
	but it's a pain to make it run under f77 (at least on 4.1bsd).
	BSO and Virtual Systems will not release the source.  BSO do not
	have versions to run under any Unix and Virtual can only supply
	versions to run under V7.

	It you want any more info. let me know.  We have the Microtec
	stuff but have had difficulty installing it.  We will be getting
	Whitesmith's stuff soon.  It's only just becoming available.
	We chose Microtec because we have 4.1 bsd and so BSO and Virtuous
	Systems couldn't help.

	Mark Callow
	Qume Corp.


*start*
00433 00024 US 
Mail-from: Arpanet host SU-AI rcvd at 6-APR-82 0550-PST
Date: Mon Apr  5 17:59:22 1982
To: info-micro at mit-ai
From: minow at Berkeley
Subject: Re: 8086 compiler and assemblers
Source-Info:  From (or Sender) name not authenticated.


8086 C compilers (and a Unix lookalike) are available from Mark Williams
Co., 1430 Wrightwood, Chicago IL 60641.  The system is called COHERENT.

Martin Minow
decvax!minow


*start*
00389 00024 US 
Date: 14 APR 1982 0937-PST
From: STEWART.PA
Subject: Code generators
To:   duvall
cc:   stewart

See [Indigo]<Voice>EP>Test117.c.

Roughly speaking,

p->c += 1;

doesn't work unless c is the first item in the structure.  No
indexing code is generated.

Operations like |= and &= doen't seem to work either.

p->c = p->c+1; work, but generate lots of code.

	-Larry
*start*
05126 00024 US 
Date: 15 April 1982 10:20 am PST (Thursday)
From: Stewart.PA
Subject: 8088 Single Step
To: VoiceProject^.pa
cc: Stewart

I've been working on an EPROM monitor for the 8088 Lark processor.  The
monitor has, among other things, facilities for a single breakpoint and for single
stepping.  The process of trying to make it work has been very educational!

Background:

When the 8088 takes an interrupt, the following things happen:
	The CPU Flags (FL) are pushed on whatever stack was set up
	The Code segment register (CS) is pushed
	The instruction pointer (PC or IP) is pushed
	The interrupt enable and single step flags are cleared in the Flag reg.
	A new CS and IP are picked up from the interrupt vector table according
to the "type" of the interrupt.

External interrupts have hardware selected types up to 255.
Divide error is type 0
Single step (Trace trap) is type 1
Non-maskable is type 2
Breakpoint is type 3  (Breakpoint is a one byte instruction that causes a software
interrupt.)

The end of an interrupt handler has an IRET instruction, which pops the
original IP, CS, and Flags off the stack and resumes execution.

The single step handler sets up the machine registers the way it wants, puts the
user IP, CS, and flags on the stack, ORs the trace trap bit into the flag word on
the stack, and executes an IRET.

This works fine except when external interrupts are enabled.

According to the 8088 manual, when an external interrupt occurs during an
instruction which is being single stepped, the external interrupt is recognized
"first", the user FL, CS, and IP are pushed, IF (interrupt flag) and TF (trace
flag) cleared, and IP and CS loaded from the appropriate vector.  Then, before
execution of the first instruction of the external interrupt handler, the CPU
notices that the single step flag used to be on.  Now FL (with TF=0) is pushed,
along with the CS and IP for the external interrupt handler, and control passes to
the first instruction of the single step handler.

Fine, the manual is worded funny, but this scheme makes it possible to either
single step the interrupt handler or not, as you choose.  The single step handler
can detect this case by inspecting the FL word on the stack.  If the trace bit is
set, then it was a vanilla single-step interrupt.  If the trace bit is clear, then it is
an external interrupt on top of the single step.

Since Lark uses interrupts to do memory refresh, we want interrupts to run at
full speed, so my single-step handler does this stack inspection.  If it finds a
combined single-step and external interrupt, it takes the following action:

	Pops the external interrupt handler IP, CS, and FL into temporaries
	Pushes an FL, CS, and IP that will cause control to go to the single-step
handler (itself).
	Pushes the external interrupt handler IP, CS, and FL back
	Executes an IRET

This reorganizes the stack so that the external interrupt handler executes "first"
and at full speed before control returns to the single step handler with the stack
in the simple condition of just a single step trap.

For various reasons, the only active interrupt (the clock) has roughly a 50%
chance of occuring right away if interrupts are enabled at a "random" time. 
Since I was running the monitor with interrupts disabled and enabling them
only for the duration of the single stepped instruction, I expected about half of
single stepped instructions to invoke the stack reordering.

The observed effects of all this are as follows.

Sometimes instructions work correctly, a single instruction is single stepped and
control returns to the monitor with the IP incremented past the instruction.

Other times, the single step code returns to the monitor without incrementing the
IP.

I modified the first instruction of the single step handler to increment a register
on each invocation, and prepared a field of insteructions to single step which
incremented a different register.

With interrupts disabled, both registers count by 1 for each single step.  This is
expected.  This also happens sometimes when interrupts are enabled.

Other times  (those occasions when the user IP does not change), the "user"
counter does not change and the "single-step invocations" counter has counted
by two.

I take this to mean that an external interrupt has been recognized BEFORE
execution of the single-stepped instruction and that further, an extraneous
single-step interrupt is produced.

The manual explicitly says that when IRET operates to enable interrupts, they do
not become enabled until the end of the following instruction.

I remember hearing that early 8088s had a bug in this area, so that loading a
segment register (MOV SS,AX or so), which is supposed to disable interrupts for
one instruction, did not.  I checked the 8088 chip and it indeed was an old one
so I plugged in a new, modern, 8088-2 ES.  No difference.

One possibility is to have the single step handler keep track of the last IP value
and to "keep trying" the single step until it changes.

Another possibility is to only do single step with interrupts turned off.

	-Larry

*start*
00230 00024 US 
Date: 15 APR 1982 1255-PST
From: STEWART.PA
Subject: Assembler bug
To:   Duvall
cc:   Stewart

[Indigo]<Voice>EP>Test118ml.asm and test118.ld

TEST AH,1 generates the same instruction as TEST AL,1.
	-Larry
*start*
00819 00024 US 
Date: 11 April 1982 1:29 pm PST (Sunday)
From: ornstein.PA
Subject: Re: 3K Control Ram
In-reply-to: verplank's message of 9-Apr-82 15:10:42 PST (Friday)
To: verplank
cc: SDSupport, Ornstein, Irby, Purvy.es, Trigoboff, Stewart, DBrown, Guibas, Taft

Bill,

If you will arrange with Darrah Brown (DBrown), our Alto fixer, I think he can
arrange to swap you the 3K Control Ram from Leo Guibas' machine for a regular
2K Cram. It is my understanding that we'll need to swap control boards (as well
as with the Ram board itself) since the control board was modified as part of the
upgrade.

This is a long-term trade but someday we might want it back - so when the
swap is complete, let's record the fact so in future we'll remember. (Although I
presently see no forthcoming requirement...)

Severo 

*start*
00282 00024 US 
Date: 19 April 1982 3:24 pm PST (Monday)
From: Stewart.PA
Subject: 8086 tools
To: Karlsson.es
cc: Stewart

Can you tell me the present status of the 8086 tools?  Assembler/linker/debugger
and whatever else?
	-Larry
(I visited in October last year I think.)

*start*
00638 00024 US 
Date: 25 April 1982 7:32 pm PDT (Sunday)
From: Stewart.PA
Subject: TTLDict.analyze bug.
To: Chang
cc: VoiceProject^, Stewart, Gifford, McCreight

I was surprised to find that the 74LS393 in the Lark processor did not have
ground wired.  I poked around and discovered that the LS393 is a 14 pin dip, but
the dictionary says it is a 16 pin chip.  My board does have a wire to pin "8",
off the end of the chip, and all the signals on the 8-14 side are off by two pins.

I don't know who else might be affected.

How do I get the board fixed?  Is route prepared to deal with a dictionary entry
that changes?

	-Larry

*start*
00527 00024 US 
Date: 25 April 1982 7:36 pm PDT (Sunday)
From: Stewart.PA
Subject: Programming 2764s.
To: Chang
cc: VoiceProject^, Stewart

Something might be wrong with verify.

After you left Friday, the programmer in Bayhill complained about bad bit 0 at
address 0, so I went home.

Saturday, I got the same complaint from the CSL Prolog with two different chips.
I build a small jig to test the EPROM by hand and it seems to have the correct
contents.  I plugged it into my CPU and it seems to work fine.

	-Larry

*start*
00255 00024 US 
Date: 26 April 1982 9:26 am PDT (Monday)
From: Gifford.PA
Subject: Re: TTLDict.analyze bug.
In-reply-to: Stewart's message of 25 April 1982 7:32 pm PDT (Sunday)
To: Stewart

Hmmm.  My TTLDict.analyze says it's a 14 pin dip.

Dave