*start*
01219 00024 US 
Date: 16 Jan. 1982 6:20 pm PST (Saturday)
From: Stewart.PA
Subject: Note on digital audio from INFO-AUDIO
To: VoiceInterest^.pa

Found this item in a description of personalities present at the Consumer
Electronics Show:

Date: 15 Jan 1982 2032-PST
From: Adam N. Rosenberg <OR.ROSENBERG at SU-SCORE>

Ivor Tiefenbrun (spelling?) is a character himself.  He told Clay Barclay
  (now with Crown since his store went under) that the digital sound he
  was working on was "a lie" and that "every step forward is really a
  step backward."  He panned newer tapes and newer records and newer
  recording techniques.  (I happen to agree with almost everything he
  said.)  He defines dynamic range as the difference between two sounds
  the hifi can resolve at the same time and claims that the loudest
  signal on a record acetate is 95 dB over the noise level (which is
  yet 20 dB over the softest audible sound, giving lowly records (when
  well pressed) a maximum loudest to softest range of 115 dB).  Since
  the last 12 dB of digital is just abrasive noise, a 16 bit system
  only has 84 dB to offer of low resolution sound.


Maybe we should go straight to 32 bit samples at 100 KHz?

	-Larry

*start*
00649 00024 US 
Date: 18 Jan. 1982 10:01 am PST (Monday)
From: Stewart.PA
Subject: Alto Naming
To: NetSupport.Wbst
cc: VoiceProject^.pa


************************ CHANGES or MOVES ***************
Use this entry if you want to change some information, such as the location (as
a result of a move), or name of your machine.

BEFORE CHANGE:
Dahlia2 = Parc-Net3+112#	;Location: "35-2061", Owner: "VoiceProject^.pa"

AFTER CHANGE:
Dahlia2 = Parc-Net3+112#	;Location: "35-2061", Owner: "VoiceProject^.pa"
Dahlia2 = Nest-Net+112#	;Location: "35-2061", Owner: "VoiceProject^.pa"

Note:  This machine is a gateway and has two network addresses.





*start*
00769 00024 US 
Date: 19 Jan. 1982 10:46 am PST (Tuesday)
From: Nelson.PA
Subject: Remote voice interfaces
To: Swinehart
cc: Stewart, Ousterhout

Dan,

Im getting close the the stage where I wish to run your stuff through Lupine to
make sure the stubs look OK, compile OK, and dont break the translator.  I want
to do this whether you have any cursory implementations with which to run a
test or not.

If you can flesh out some of the interfaces in the next 2 weeks, it would be very
helpful.  Be sure to get all the nitty types in there; even though you know what
you want to do, the data structures are what make a difference to Lupine.

A DF file that names the remote interfaces (and any auxiliary stuff needed for
their compilation) would be ideal.

Bruce
*start*
01337 00024 US 
Date: 19 Jan. 1982 11:33 am PST (Tuesday)
From: Swinehart.PA
Subject: Re: Remote voice interfaces
In-reply-to: Nelson's message of 19 Jan. 1982 10:46 am PST (Tuesday)
To: Nelson
cc: Swinehart, Stewart, Ousterhout

See [ivy]<swinehart>thrush>thrush.df.  It includes a compile order, and a place to
put a call to Lupine after compiling ThrushSmarts (the only one I've applied to
your thing.)  I've successfully exported a ThrushSmarts, and was working on
importing one (New... yet) when I had to go put out fires, stop mudslides, repair
planetary orbits, etc.  So I'm fairly confident that I'm in business.

The only thing even mildly controversial that I think I need for Thrush is
"handles" -- the ability to pass REFs to the "server" in a way that won't break
the server's garbage collector.  The server will never dereference, but will
simply supply as an identifier once in a while.  If this has problems, I'll loophole
them to LONG UNINTERESTINGs, so I'm covered.

It's WONDERFUL!!!!

P.S. The interfaces that will have remote callers include

ThrushNet, ThrushFone, ThrushConversation, and ThrushSmarts.  Also the
Larkxxx interfaces, although I'm not sure they compile right now -- the others
do.

Let me know if what's there doesn't work, is not interesting enough, or has any
other troubles.

Thanks,
Dan

*start*
01619 00024 US 
Date: 19 Jan. 1982 1:29 pm PST (Tuesday)
From: Nelson.PA
To: Swinehart.PA
cc: Nelson, Stewart, Ousterhout
Subject: Re: Remote voice interfaces


I just translated ThrushNet, ThrushFone, ThrushConversation, and ThrushSmarts
(LarkXX do not compile).  There were no apparent problems, but there are a lot
of TBD types in there, too.  Some comments:

Handles.  Lupine is happy to marshal handles as such, although it always gives
a warning msg during translation.  Whether or not an invalid ref causes
problems for the other machine depends, I belive, on what you do.  For instance,
I think that just storing a ref off the stack will create chaos.  To use handles,
you must declare them as follows:

Fone: TYPE = HANDLEFone;  HANDLEFone: TYPE = REF FoneObject.

The scheme is that HANDLE must appear at the front of some type def, not
necessarily the top level.  Similar for VAR, VALUE, and RESULT params.

Ropes.  If you know that most of your strings are Rnames, or some other
always-short type, declare them to be Rpc.ShortRope (or ShortString or
ShortAtom).  A ShortRope is identical to a ROPE, and interchangeable with it
except for RPC.  This will get you faster calls.  It's possible the scheme will
change, so I'd use your own, different, type names for RNames, indefinite length
strings, etc.  Your defining NetworkAddress as a rope is wierd, as you note.

For secure calls, you will want to use Rpc Conversations, which add another
parameter to the FRONT of every call.  If this interferes with your object style
access, then we should talk.

Thanks for the quick response,

					Bruce



*start*
00827 00024 US 
Date: 19-Jan-82 15:17:50 PST (Tuesday)
From: Ousterhout.PA
Subject: Bluejay Status
To: VoiceProject^
Reply-To: Ousterhout

As of today, I have the jukebox facilities running in Bluejay (recall
that the jukebox is my homebrew Unix-like file system).  I ran a
simple test to see how it performs.  A program writes out 100 seconds
of speech to a tune (the jukebox-equivalent of a file) as fast as it
can.  The first time, this takes about 3.5 seconds, which is about
30 times as fast as real time.  The second time it only takes about 2.5
seconds, or about 40 times as fast as real time.  The first time is
slower because it has to allocate space within the jukebox.  This
test uses all of the disk bandwidth but only about 25% of the CPU,
leaving 75% of the CPU left to handle the Ethernet.

						-John-
*start*
00289 00024 US 
Date: 19 Jan. 1982 5:57 pm PST (Tuesday)
From: Dalal.PA
Subject: Electronics Design article
To: VoiceInterest^
cc: Dalal
Reply-To: Dalal

FYI: "Coax local network carries both voice and data." A paper by Donald Melvin
from Intel on telephony using the Ethernet.



*start*
01060 00024 US 
Date: 20 Jan. 1982 12:56 pm PST (Wednesday)
From: Stewart.PA
Subject: speechgrams
To: VoiceProject^.pa
Reply-To: Stewart

From the MITRE section of the monthly Arpa Internet report:


   2.  Mike O'Connor has the LPCM speech codec once again working
   and can record and play back 2400-bps speech using our LSI-11
   fuzzballs and standard files and access methods.  The LPCM
   device interface and data formats are intended to conform to
   the spirit of NVP and the old CONFER program used on SATNET,
   but can be modified easily.  In order to give us more insight
   into the real-time and operator-interface issues, we are
   integrating this modality into our existing internet message
   system so as to be able to send speechgrams (with LPCM data
   encoded horribly in 7-bit ASCII) to ourselves and Paal
   Spilling at NDRE.  The goal of this simple excersize is to
   evaluate candidate speech/facsimile/text composition program
   ideas.  Later we expect to be able to switch to more
   appropriate multi-media formats.



*start*
00267 00024 US 
From: ogus.pa
Date: 21-Jan-82 15:29:00 PST
Subject: Re: Intel 2764 Prom Blowing
In-reply-to: ornstein's message of 21 Jan. 1982 3:03 pm PST (Thursday)
To: ornstein
cc: Ogus, Stewart

I believe we do.  The person to ask is Clark Hallgren.

Roy.*start*
00267 00024 USm
From: ogus.pa
Date: 21-Jan-82 15:29:00 PST
Subject: Re: Intel 2764 Prom Blowing
In-reply-to: ornstein's message of 21 Jan. 1982 3:03 pm PST (Thursday)
To: ornstein
cc: Ogus, Stewart

I believe we do.  The person to ask is Clark Hallgren.

Roy.*start*
00967 00024 US 
Date: 24 JAN 1982 2318-PST
From: GONSALVES.PA
Subject: Ethernet unsuitable for voice?
To:   voiceinterest^



From Baxter & Baugh (of Bell Labs), "A Comparison of Architectural
Alternatives for Local Voice/Data Communications", IEEE Communications
Magazine, Jan. 1982 :

Speaking of bus architectures for integrated LAN's, the authors have to
say:
	"For local or intra-office switching, packetized voice has two
negative consequences that nearly always rule it out as a practical method
of voice communication. ... The overhead associated with processing the
digital voice samples into packets, transmitting them and depacketizing
them is usually expensive compared to straightforward circuit switching.
The second consideration has to do with conference calls . . . an awkward
operation in a packet network.  For these reasons, it is unlikely that
local systems containing any appreciable amount of voice traffic will use
packetized voice."

*start*
01039 00024 US 
Date: 26 Jan. 1982 5:53 pm EST (Tuesday)
From: Carroll.WBST
Subject: Re: Query re phone usage statistics
In-reply-to: GONSALVES.PA's message of 26 JAN 1982 1345-PST
To: GONSALVES.PA
cc: voiceinterest^.PA

Tim,

A good source for voice statistics, methods of analysis, etc. is the Bell Systems
Technical Journal.  Relevant trade publications such as Telephony and
Telecommunications also feature articles that would address your interests.   I
have seen articles describing residential usage patterns, commercial usage by
industry (i.e. hotel, sales offices, and buildings of various class sizes) and
methods of calculating phone usage (CCS, erlangs, etc.), trunk sizings, levels of
performance, PBX options and configurations, etc.

Xerox is also a large, representative sample of telephone use.  The manager of
Voice Communications in Xerox is Fred Bolton 8*223-4422 whose organization
routinely measures Xerox usage and may be able to provide or direct you toward
more information.

Hope this helps,
Tim Carroll

*start*
00482 00024 US 
Date: 27 JAN 1982 0043-PST
From: STEWART.PA
Subject: Lark redesign notes
To:   VoiceProject^

Let's get rid of the 8274 and keep the 8251.  If we're not going to 
use Belleville's computer, then we don't need two RS-232 ports, only
one.  The 8251 can provide it and only costs $2.30 vs. $20 for an 8274.
We should count the number of input and output control lines needed to
operate the analog stuff and provide one or two more 8255s to handle
the load.
-ly
*start*
05296 00024 US 
Date: 28 Jan. 1982 5:43 pm PST (Thursday)
From: ornstein.PA
Subject: Lark Redesign Notes - In Progress
To: Stewart, ornstein

1. We are now probably going to absorb Belleville's logic into our own rather
than largely adopting his wholesale. The details have to be thought out but it
would mean we don't need the 8274 Serial Line controller. That had two
purposes: communication with Belleville's logic and communicating with the
Lark IIB display/keyboard. We'll now probably use 8255 or equivalent for the
former and a cheaper 8251 for the latter. We had thought, once Ethernet
downloading was ready, to eliminate the 8251 we currently have. However it's
nice to have the monitor functions, at least during debugging.   

2. Fix Prom code so that on Reset, first thing it does is set up the 9513 (timer) to
run the 8251 at the proper speed. This lets us eliminate the divide by ten counter
presently producing the 8251's clock. 

3. We should put in dip switch. One switch says whether, on Reset, we go
directly to the Ethernet down-loader or to the monitor. Another one of the
switches enables/disables the WatchDog Timer.

4. Dynamic Memory vs. Static. Static is simpler but, depending on how much
you need, takes more acerage. Main argument for Dynamic seems to be to
overwhelm the uncertainty in how much memory we'll need. If we bite the
bullet and use Dynamic, then we can get 64K which is oceans so we can forget
worrying. (Otherwise we get into questions of how much space to leave for
expansion, etc.) So Larry and I pretty well agreed to go for Dynamic. We then
addressed the refresh issue (from which stem the complications). There seemed to
be 4 general possible ways to do refresh:

	1. Let the 8203 Memory controller handle it. This means we have to worry
about fielding not-ready whenever anyone tries to use the memory when the
8203 is refreshing. We didn't like it for that reason.

	2. Use a DMA channel to periodically reference the next set of addresses.
But with the slave processor, we had eliminated the 2nd. DMA and the first is
thus left full (2 channels for encryption, one for SLC cascade, and one for Slave
cascade). So we would have to add an extra (40 pin) DMA if we went this way.

	3. Interrupt the main processor periodically and let it make refresh
references. This is a terrible burden on the main processor program - got to be
careful locking interrupts and if anything goes wrong - Blam!

	4. (This is the one we like) - Let the Slave do the refreshing. It gets
roused every 125us for the next voice sample. For 64K Rams, the wrost case array
needs to have 256 RAS tickles every 4 ms. That's 8 row (successive byte - i.e. 4
successive word) references every voice sample time.
		A) The Slave could just do (refreshing) data references in the main
memory, perhaps taking advantage for some of them of the voice data references
required anyway. But that lengthens the Slave's loop just for refreshing.

				OPEN ISSUE
		B) We thought about putting some of the slave code
(8-successive-byte-references) into the main memory and jumping back and
forth from the slave's ROM - letting the instruction fetches in the main memory
do the refresh. (You would need 32 copies at suitable different row addresses and
unroll the loop). But the main processor could clobber you. To avert that we
thought to reference the main memory in parallel with the slave's ROM, but
only fetch the data from the ROM. Then to be able to forget about where the
code was located in the ROM and having to have multiple copies (so the
addresses would properly cycle through all the RAS's) Larry thought to add a
Refresh flop and an 8-bit Refresh-address counter. As the Slave enters the
consecutive part of it's loop (where the parallel Main Memory refreshing is to
take place), it sets the Refresh flop. That institutes the parallel referencing and
waiting for DACK's as required. It also causes the Refresh-address counter to be
stepped by slave ALE's and to be used as the low 8 bits of address in making the
refresh references to the Main memory (doesn't affect addresses to the Slave's
ROM). At the end of the "refreshing" instructions, the program turns off the
flop. Larry's final coup was to try to use the 8203's internal counter for this
Slave counter, but (HORRORS) there's no way to do that - and WORSE!! you
can't stop the 8203 from doing refreshes. Either you tell it to do them or it will
do them on its own. There's no way to tell it "just leave refreshing to me".


5. Trick in how to do zeroing of memory behind takeout of the audio sample (for
adding into incoming conferencing). The takeout from main memory does a
single byte reference whose resulting data is used as part of the address into the
Slave's "linearizing" PROM. The linear result requires two references to the
PROM; a complementing flop is used as the low address bit for the PROM - thus
obtaining two sequential locations. If we latch the byte from main memory on the
first reference, then we can use the ciomplementing flop to turn the second
reference (to the Main memory) from a Read into a WRITE. Then we also
provide a zero data source. Since the rest of the address to the main memory
hasn't changed, we've rewrtiien the voice byte with zeros - a read-modify-write.
       

*start*
00682 00024 US 
Date: 29 Jan. 1982 4:32 pm PST (Friday)
From: Stewart.PA
Subject: U255 Encoding routines
To: Trigoboff
cc: VoiceProject^.pa, Stewart

[Indigo]<Voice>EP>U255.df describes a collection of software to do conversion
between U255 encoded bytes and other encodings.

In particular, U255.mesa and U255Impl.mesa (and .bcd) are an interface and
implementation to convert between U255 and integer encodings.

	-Larry

A useful article is "A New Digital Technique for Implementation of any
Continuous PCM Companding Law," by Villeret, Deschenes, and Stephenne, ICC
1973, pp 11-12--11-17.  Reprinted in "Waveform Quantization and Coding," Ed.
N. S. Jayant, IEEE Press.

*start*
00590 00024 US 
Date: 29 Jan. 1982 4:53 pm PST (Friday)
From: Stewart.PA
Subject: Intel Parts prices
To: VoiceProject^.pa

Results of a Hartnet phone call last week about chip prices...

8088	$8.70
8086	$21
8237	$8.60
8202	$14.85
8203	$20 - $30   (new part)

16K rams  essentially free
64K rams	<$10 in a month or two  (new part)

2716	$3    (450 ns version)
2732	$5.50	(450 ns)	$7.20	(250 ns)
2764	$12.50	dropping to $9.50 in a few months  (450 ns)
	$17.50 dropping to $12.25	(250 ns)

8259A-2	$4
8255A-5	$2.30
8251A		$2.30
8274	~$22 dropping to $14.70 in 1983 and to $11 in 1984

*start*
00442 00024 US 
Date: 29 Jan. 1982 5:11 pm PST (Friday)
From: Stewart.PA
Subject: Re: Intel 2764 Prom Blowing
To: Ornstein
cc: Stewart, Voice

Ever follow up?

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

From: ogus.pa
Date: 21-Jan-82 15:29:00 PST
Subject: Re: Intel 2764 Prom Blowing
In-reply-to: ornstein's message of 21 Jan. 1982 3:03 pm PST (Thursday)
To: ornstein
cc: Ogus, Stewart

I believe we do.  The person to ask is Clark Hallgren.

Roy.

*start*
02480 00024 US 
Date: 30 Jan. 1982 8:28 pm PST (Saturday)
From: Stewart.PA
Subject: IBM Personal Computer
To: VoiceProject^.pa
cc: Thacker, McCreight, Gifford, TonyWest, Stewart

I've had an opportunity to look over the circuit diagrams of the IBM Personal
Computer published in the "Technical Reference Manual."

Here are a few interesting things about it:

The 8088 operates in maximum mode.  This has two advantages: first, it permits
operation of the 8087 coprocessor in a supplied socket, and second, maximum
mode provides advance notice of memory cycles, which can reduce the number
of wait states needed in systems using slower (and cheaper) memory chips.

The system uses a dynamic ram controller constructed with TTL SSI/MSI and a
delay line.  Refresh is accomplished by use of an 8237A-5 DMA channel
executing RAS only cycles under control of a programmable timer chip (an 8253).

There appear to be three busses: the multiplexed address/data 8088 bus, called
AD, a demultiplexed bus called A and D, and a seond level bus XA and XD. 
The interrupt controller (8259A), 8088, and Coprocessor are the only devices on
the AD bus.  The A and D busses contain the resident RAM and appear at the
connectors for the 5 I/O slots.  The XA and XD busses contain system ROM and
all motherboard I/O (Timer, DMA, PIO).

The bus organization seems to be related to two concerns: IO loading and DMA
bus control.  The former consideration is fairly obvious, the latter is quite
ingeneous.  The use of Maximum mode on the 8088, with its attendant
interpretation of Hold and Holda as RQ/GT0 and RQ/GT1, would normally be
incompatible with the use of an 8237 DMA device, which requires Hold and
Holda.  The IBM designers have arranged things so that DMA activity causes the
Processor to go Not Ready.  This halts execution, but the processor continues to
drive the bus.  This effect is circumvented by isolating the AD bus from the A
and D busses.  The processor is driving, but it isn't connected to anything!  The
interrupt controller is on the AD bus because its interactions with the Int and
Inta signals are too complex to control with the ready line.

The 8237 DMA opeates on a 20 bit address by use of an external LS670 dual port
4 bit ram which holds the high order bits.  A DMA transfer cannot cross a 64K
byte boundary.

The memory incorporates a parity bit.  Parity failure causes a non-maskable
interrupt.  (NMI is actually maskable by a Flip-flop I/O device.)

	-Larry
*start*
01095 00024 US 
Date: 1 Feb. 1982 7:47 pm PST (Monday)
From: Stewart.PA
Subject: 8237 information
To: VoiceProject^.pa
cc: Stewart

Call to Ron Saltzman at Intel applications: 408-496-7360

(Another number is John Epler, 408-987-5528)

Q: What is an 8237-5?

A: 8237-5 is 5 MHz, but different from 8237-2 in that some specs have changed: 
The -5 was created to alert customers of spec changes.  8237-5 info will come in
mail.

Q:  What is Non-A vs. A?

A:  Don't know, will check for you.

Q:   If I am running a Block mode transfer on channel 3 and a request comes in
on channel 0, will it be honored?

A: Don't know, will check for you.

Q:   Does cascade mode on channel 1 work?

A: Don't know, will check for you.

Q:   When is synchronization of Hold between 8237 and CPU needed?

A: Don't know, will check for you.

Q:  Is the citation for 205 ns Read access time for an 8088 correct in the 8202
application note in the Peripheral Design Handbook?  If so, is it true that one
cannot build a no-wait-state memory for the 8088 using the 8203 without
maximum mode or external logic?

*start*
00657 00024 US 
Date: 2 Feb. 1982 10:40 am PST (Tuesday)
From: asprey.PA
Subject: Re: Ethernet unsuitable for voice?
In-reply-to: GONSALVES' message of 24 JAN 1982 2318-PST
To: GONSALVES
cc: voiceinterest^

Yes, all they say appears to be true but it is my view that the second
consideration is not one at all.  It is a well known fact that people who purchase
telephone systems often don't care how WELL a feature is implemented but
rather that it exists.  So give them a feature list as long as their arm and
concentrate on making 'standard' call processing work 'reasonably' well.  I'll just
hedge on the definitions of standard and reasonably.

*start*
02108 00024 US 
Date: 2 Feb. 1982 5:27 pm PST (Tuesday)
From: Stewart.PA
Subject: 8237 data
To: VoiceProject^.pa

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

Date: 2 Feb. 1982 4:17 pm PST (Tuesday)
From: ornstein.PA

I believe that we were told that the 8237 DOES re-prioritize between successive
bytes in single transfer mode  - and that it re-issues ADSTRB on each new byte.

S.


Call from John Epler at Intel, 408-987-5528:

More information about 8237s of various flavors is on the way.  Highlights:

There is a mechanism called Control Override which forces the 8237 to release
the bus, even in the middle of a block transfer.  If Holda going to the 8237 is
dropped after AEN goes low (probably should be ADSTB?), the '37 will complete
the current cycle and relinquish the bus  (take away Hold).   Any transfers that
stopped will not be restarted until a new REQ arrives or a software request is
given.  (Thus the tail of a block mode transfer could be lost if the block mode
request is dropped as soon as DACK arrives.)

If a higher priority request is activated during a group of demand mode
transfers, the 8237 will not switch.  No arbitration takes place between cycles of a
demand mode transfer.

At least two problems with the 8237-5:
	Cascade mode only works on channel 0
	DREQ not asyncronous.  If DREQ dropped during state S$, the 8237 may
hang up.

8237A-5 information:
	The 8284A clock out should be inverted for the 8237 in order to meet the
clock low and clock high time specs.
	Hold going into the 8088 should be synchronized
	Carefully check data setup and hold times of the 8237A-5
	If ready is used, be sure to meet the 8237A-5 ready setup and hold times.
	When using an 8 MHz 8088, the half speed clock out of the 8284A can
drive the 8237A-5, but be sure  to add wait states when accessing the 8237A-5
from the CPU

Changes from 8237-5 to the A-5 part:
	Cascade problem fixed, DREQ now asynchronous, no longer require 50 pf
on MRd' for mewmory to memory moves to work.  Drive capability increased to 2
mA.

8237A-5 and 9517A-4 identical except for speed, but the 9517A-4 has 3.2 mA
drivers.
*start*
00407 00024 US 
Date: 2 Feb. 1982 6:29 pm PST (Tuesday)
From: Stewart.PA
Subject: Etherphone.run
To: VoiceProject^.pa
cc: , Stewart

I've modified the version of Etherphone.bcpl .run, and .syms that were on the
Alto disk in the Nursery Alto to send 10 keepalive packets per second.  John is
going to use them as a clock reference for Bluejay.

Dan:  I didn't do anything with .df files...

	-Larry

*start*
01131 00024 US 
Date: 3 Feb. 1982 12:37 pm PST (Wednesday)
From: ornstein.PA
Subject: Re: 8237 data
In-reply-to: Stewart's message of 2 Feb. 1982 5:27 pm PST (Tuesday)
To: Stewart
cc: VoiceProject^.pa
Reply-To: ornstein

I don't understand - if Cascade mode only works on Channel 0 on the 8237-5,
then howcum our Etherphone works at all? Isn't the 8237-5 the one we're using
and don't we cascade both channels 0 and 1 (for extension and SLC)?

Also - when you say that for the 8237-5 DREQ is not asyncronous, does the
ensuing explanation ("DREQ dropped during state S$, the 8237 may hang up")
mean that that's the only problem - i.e. is it still OK to RAISE DREQ
asyncronously? If not, then I again don't understand how we manage to work??

Having thought about it, I now think we (I) probably overdid it with two
synchronizer flops on Hold going into the 8088. Though Hold from the DMA
may come at a bad time with respect to Sysclk, the first synchronizer flop will
guarantee that at Sysclk times it's output is stable. If the 8088 itself strobes its
Hold Request input with Sysclk, the one flop should be sufficient.

S.
*start*
02464 00024 US 
Date: 3 Feb. 1982 3:15 pm PST (Wednesday)
From: Stewart.PA
Subject: 8237 data, more
To: VoiceProject^.pa

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

Date: 2 Feb. 1982 4:17 pm PST (Tuesday)
From: ornstein.PA

I believe that we were told that the 8237 DOES re-prioritize between successive
bytes in single transfer mode  - and that it re-issues ADSTRB on each new byte.

S.

Call from John Epler at Intel, 408-987-5528:

More information about 8237s of various flavors is on the way.  Highlights:

There is a mechanism called Control Override which forces the 8237 to release
the bus, even in the middle of a block transfer.  If Holda going to the 8237 is
dropped after AEN goes low (probably should be ADSTB?), the '37 will complete
the current cycle and relinquish the bus  (take away Hold).   Any transfers that
stopped will not be restarted until a new REQ arrives or a software request is
given.  (Thus the tail of a block mode transfer could be lost if the block mode
request is dropped as soon as DACK arrives.)

If a higher priority request is activated during a group of demand mode
transfers, the 8237 will not switch.  No arbitration takes place between cycles of a
demand mode transfer.

At least two problems with the 8237-5:
	Cascade mode only works on channel 0
	DREQ not asyncronous.  If DREQ dropped during state S$, the 8237 may
hang up.

8237A-5 information:
	The 8284A clock out should be inverted for the 8237 in order to meet the
clock low and clock high time specs.
	Hold going into the 8088 should be synchronized
	Carefully check data setup and hold times of the 8237A-5
	If ready is used, be sure to meet the 8237A-5 ready setup and hold times.
	When using an 8 MHz 8088, the half speed clock out of the 8284A can
drive the 8237A-5, but be sure  to add wait states when accessing the 8237A-5
from the CPU

Changes from 8237-5 to the A-5 part:
	Cascade problem fixed, DREQ now asynchronous, no longer require 50 pf
on MRd' for mewmory to memory moves to work.  Drive capability increased to 2
mA.

8237A-5 and 9517A-4 identical except for speed, but the 9517A-4 has 3.2 mA
drivers.

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

Call from Ron Saltzman at Intel,  408-496-7360

A vs. non-A
	Cascade mode fixed
	MWr' no longer needs 50 pf
	Iol now 2.0 mA

Block mode is non-interruptable.
Demand mode is non-interrupta

Synchronization on Hold still don't know

On 8203, 205 ns is right.  8203 same timing as 8202A.

*start*
01006 00024 US 
Date:  4-Feb-82 15:23:27 PST (Thursday)
From: Trigoboff.PA
Subject: VoiceViewer Program
To: NDSmith, Roberts, Stewart, Verplank
cc: Israel, Trigoboff

A new, improved version of VoiceViewer is available, on:

  [Iris]<Trigoboff>Voice>VoiceViewer.bcd, .mesa

New features: display of multiple lines, time compression.

The "Time (msec)" parameter shows the time in milliseconds of the beginning of the display relative to the beginning of voice in the file.  The "Time interval" parameter is how much the "Time (msec)" parameter will be bumped (decremented) by the Next! (Prev!) command.

The "Sample size" parameter shows how many samples to display from each sampling interval.  The "Sample interval" parameter defines the length of the sampling interval.

The "Redisplay" command is used after setting the "Time (msec)", "Sample size", "Sample interval", or "Line height" paramaters.

I think everything else is self-explanatory.  If not, I'll be glad to answer questions.

	Mike
*start*
00499 00024 US 
Date:  4-Feb-82 15:28:06 PST (Thursday)
From: Trigoboff.PA
Subject: Voice Files
To: NDSmith, Roberts, Stewart, Verplank
cc: Israel, Trigoboff

By the way ...

There are voice files you can use with VoiceViewer stored on:

  [Ibis]<Voice>
    Hello.u255
      -- "Hello Mike, this is Larry ..."
    Now.u255
      -- "Now is the time for all good men to come to the aid of their party"
    QBF.u255
      -- "The quick brown fox jumped over the lazy dog"

Have fun ...

	Mike
*start*
03735 00024 US 
Date: 5 Feb. 1982 4:50 pm PST (Friday)
From: Stewart.PA
Subject: SLC timing requirements
To: VoiceProject^.pa

All timing assumes load capacitance of 150 pF.

Using timing as a multiple of 8 kHz
6.144 MHz or 12.288 MHz
								1.5 Mbit	3 Mbit
Input clock							162.8		81.4
T  clock out cycle time = 1/2 clock in			325.5		162.8
Tal address valis to NALE trailing edge			112.8		31.4
Tll NALE width						142.8		61.4
Tla Address valid after NALE				112.8		31.4
Tad Address valid to data valid				663.8		256.9
Tac Address valid to NSTROBE low			275.5		112.8
Trd NRD low to data valid					338.3		94.1
Tary Address valid to NReady valid			472.4		106.2
      NSTROBE low to NREADY valid			266.9		63.45
Tcl  NSTROBE high to next NALE			215.5		52.8
Tca NSTROBE high to change A8-A15			122.8		41.4
Twd write data hold time					122.8		41.4
Tdw write data valid to end of NWR			581		255.5
Trae NRD end to AD driven				245.5		82.8
Tlc1 NALE end to NSTROBE				122.8		41.4

Trys NREADY setup to rising edge of CLOCKOUT	171.4		130.7
Tryh	NREADY hold after rising edge			0		0


Using timing as a multiple of 170 ns (True Ether frequencies)
5.882 MHz or 11.76 MHz
								1.5 Mbit	3 Mbit
Input clock							170		85
T  clock out cycle time = 1/2 clock in			340		170
Tal address valis to NALE trailing edge			120		35
Tll NALE width						150		65
Tla Address valid after NALE				120		35
Tad Address valid to data valid				700		275
Tac Address valid to NSTROBE low			290		120
Trd NRD low to data valid					360		105
Tary Address valid to NReady valid			505		122.5
      NSTROBE low to NREADY valid			285		72.5
Tcl  NSTROBE high to next NALE			230		60
Tca NSTROBE high to change A8-A15			130		45
Twd write data hold time					130		45
Tdw write data valid to end of NWR			610		270
Trae NRD end to AD driven				260		90
Tlc1 NALE end to NSTROBE				130		45

Trys NREADY setup to rising edge of CLOCKOUT	175		132.5
Tryh	NREADY hold after rising edge			0		0
Timing for chip select mode
								min		max
AD setup before end of ALE				50
ALE width							40
AD hold after end of ALE					30
ALE to start of NWR or NRD				40
NCS setup before NWR or NRD				35
NCS hold after NWR or NRD				60
Data hold after end of NWR				60

READ:
NREADY driven after end of NRD					100
Data tristate after end of NRD						90

Data put on bus one PH1 cycle before NREADY driven true

WRITE:
Data valid after start of NWR						170
NREADY driven after end of NWR					100

RESET:
TINT, RINT, HOLD out of tristate after end of NRESET		100

Dma notes:

Looks like, in the absence of Ready, that NWR and NRD are drivebn low for two
cycles of Phi-2.  Write data is driven at the same time as NWR, but there might
be some skew in the two paths.  See Tdw above.

On DMA reads, looks like data is samples 1/2 Phi-2 cycle before the end of
NRD.  That explains the general flawor of Trd above.  Frank Nelson says that
Trd is probably more relaxed than that.  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.

If we call K6=100 ns, then Trd would be 144 ns.  That might work with out 120
ns access time chips, maybe.

We can start reads early by initiating an SLC dma read at the time of NALE
rather than at the time of NRD.  That gives advance warning of a dma read.

Tlc1 above is the additional time available.  94.1+41.4 = 135.5ns.  However, it
seems quite likely that the worst cases of Tlc1 and Trd cannot occur at once.  I'll
ask Frank Nelson.

If we use the true ethernet frequency (separate SLC and audio crystal), and we
use advance read, and we use 100 for K6, then the dma read access time would
be  45+105+50 = 200 ns, which is fine.

	-Larry
*start*
00889 00024 US 
Date: 5 Feb. 1982 6:50 pm PST (Friday)
From: Stewart.PA
Subject: More Lark redesign ideas
To: VoiceProject^.pa

Severo and I got to thinking...

We could:

Use an 8 MHz 8088 but only run it at 5 MHz.  This would reduce some of the
propagation times here and there and perhaps permit use of slower memory chips.

We could run the 8088s at 8 MHz.  This could give us 60% more cycles.  We
would have to run the 8237A-5 DMA controller at half speed (4 MHz) and insert
an 8088 wait state when doing IO space reads and writes.  The memory system
would have to be re-analyzed.

We probably will:

Run the SLC at the correct frequency for Ethernet instead of the nearby
frequency which is a multiple of T1.  This probably costs about 1/2 package. 
(You mean this telephone has two processors and three crystals? )  Maybe four
crystals, since the DTMF decoder has one too.

*start*
01720 00024 US 
Date: 6 Feb. 1982 5:26 pm PST (Saturday)
From: Stewart.PA
Subject: VoiceViewer Program
To: VoiceProject^.pa

A Tajo voice waveform display program

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

Date:  4-Feb-82 15:23:27 PST (Thursday)
From: Trigoboff.PA
Subject: VoiceViewer Program
To: NDSmith, Roberts, Stewart, Verplank
cc: Israel, Trigoboff

A new, improved version of VoiceViewer is available, on:

  [Iris]<Trigoboff>Voice>VoiceViewer.bcd, .mesa

New features: display of multiple lines, time compression.

The "Time (msec)" parameter shows the time in milliseconds of the beginning of
the display relative to the beginning of voice in the file.  The "Time interval"
parameter is how much the "Time (msec)" parameter will be bumped
(decremented) by the Next! (Prev!) command.

The "Sample size" parameter shows how many samples to display from each
sampling interval.  The "Sample interval" parameter defines the length of the
sampling interval.

The "Redisplay" command is used after setting the "Time (msec)", "Sample size",
"Sample interval", or "Line height" paramaters.

I think everything else is self-explanatory.  If not, I'll be glad to answer
questions.

	Mike
------------------------------------------------------------
Date:  4-Feb-82 15:28:06 PST (Thursday)
From: Trigoboff.PA
Subject: Voice Files
To: NDSmith, Roberts, Stewart, Verplank
cc: Israel, Trigoboff

By the way ...

There are voice files you can use with VoiceViewer stored on:

  [Ibis]<Voice>
    Hello.u255
      -- "Hello Mike, this is Larry ..."
    Now.u255
      -- "Now is the time for all good men to come to the aid of their party"
    QBF.u255
      -- "The quick brown fox jumped over the lazy dog"

Have fun ...

	Mike

*start*
00240 00024 US 
Date:  6 FEB 1982 1855-PST
From: STEWART.PA
Subject: ETP-Rev-Ad
To:   VoiceProject^

ETP-Rev-Ad is ready for stitchwelding.  This is a rework of the
Dorado board prototype to get rid of all the little fixes.
	-Larry