*start*
01181 00024 US
Date: 13-May-82 11:10:11 PDT (Thursday)
From: verplank.pa
Subject: Two-day Voice Meeting, May 24,25
To: NDSmith, Braun.es, Irby, DaveSmith, Dalal, Roberts, Trigoboff, Nagata
cc: verplank.pa, Swinehart, Stewart
Charles has just suggested that we need some intensive discussion before the completion of Goals and Requirements documents and proposes a two-day working meeting. Could we do it Monday and Tuesday, May 24,25? I'll see if I can reserve a conference room in Bldg. 35 or Parc Place -- just to get away a bit.
I just talked to Dan Sweinhart about participating. He could come Monday. I'd like a presentation from Dan and Larry about their work, some of the technical background that we need for decision making (e.g. compression or not), and some idea of the future (PBX vs. Etherphone).
We need to nail down as best we can, some of the architecural alternatives. I'd like Yogen and Mike to present the alternatives and the data gathered so far in helping to decide.
I'd like to work thru some detailed usage scenarios, illustrating the impact of alternative user-interfaces.
Any suggestions? Additions to agenda? Other people? --Bill
*start*
00747 00024 US
Date: 13 May 1982 12:44 pm PDT (Thursday)
From: Birrell.pa
Subject: Maintain
To: Cedarusers↑
cc: , Birrell
Reply-To: Birrell
A version of Maintain that runs under Cedar 3.0 is available. See Maintain.bcd
in [Indigo]<Grapevine>Maintain>Pilot>Maintain.df. Load it with the userexec,
and it registers the command "Maintain". When you give that command, it
creates a typescript viewer, with the same old teletype interface (except that you
use Control-DEL to abort, instead of DEL). Beware: don't use the "Destroy"
button yet: it doesn't clean up properly, and will crash if Maintain is typing at
you at the time.
I still have a vacancy for a volunteer who'd like to build a menu-driven
interface to Maintain.
Andrew
*start*
00503 00024 US
Date: 13-May-82 13:07:10 PDT (Thursday)
From: ndsmith.pa
Subject: Re: Two-day Voice Meeting, May 24,25
In-reply-to: verplank's message of 13-May-82 11:10:11 PDT (Thursday)
To: verplank
cc: NDSmith, Braun.es, Irby, DaveSmith, Dalal, Roberts, Trigoboff, Nagata, Swinehart, Stewart
Bill--
I cannot participate in a voice meeting the week of May 24. The following week would be okay.
I'll think about agenda and participants further and let you know of any good ideas.
Nancy
*start*
01323 00024 US
Date: 17 May 1982 6:14 pm PDT (Monday)
From: ornstein.PA
Subject: Re: Lark DMA interference
In-reply-to: Stewart's message of 15 May 1982 11:19 pm PDT (Saturday)
To: Stewart
cc: VoiceProject↑
Reply-To: ornstein
Larry,
Just for the hell of it I checked the flip-flop to see if I could see any evidence of
glitching and could not. Shouldn't matter anyway as any glitching would take
place after the enable gate was shut off by SLCREQ having gone low.
My guess is that the trouble is indeed not getting the flop off until completion
of the first SLCREQ AFTER TSN. How about experimenting to verify this by
using one of the SIOCLKs to get a delayed start for your TIMER? I'm not clear
about just which Timer channel you're presently using for the holdoff, but it
would seem that with two of them - the second (which would do the actual
holdoff) "triggered" by the first and the first triggered by TSN or equivalent,
you ought to be able to position the holdoff wherever you want so that the
enable flop can get shut off BEFORE TSN - thus permitting the Slave to take
right off and run (hopefully to completion) without interference. I don't know
how we would SOLVE this - what I'm suggesting is only a means of verifying
that if we could get the flop off before TSN, things would be OK.
????
S.
*start*
01532 00024 US
Date: 18 May 1982 10:29 am PDT (Tuesday)
From: ornstein.PA
Subject: Another two thoughts about interference
To: Stewart
cc: ornstein
At 1.47 MB, the Ethernet uses up a byte every 5.44 us. - in each direction. I
don't understand the relative phasing of EthIn and EthOut but assuming the
worst, then the maximum interval between SLCREQ's will be 5.44 us. (I.e., if the
SLC's buffer has just filled, it will make another request no later than 5.44 us
from now). So if we could shift the timer back so that it starts say 6 us. before
the start of TSN, then we're guaranteed to have a SLCREQ during that 6 us
which will shut off the enabling flop - before the TSN arrives to start the Slave
making requests. How wide is FrameSync? 6 us, maybe?
Another idea would be to switch the Slave and SLC's groupings so that the SLC
used the time following TSN and was cut off leaving just enough time for the
slave to do its references before the next TSN. TSN could turn on (DC set) the
enable flop - which would be shut off by the (end of the) first SLCREQ after
the timer ran out. Just as we presently expect (hope) that the Slave will have
finished its requests before the timer runs out, in that new scenario, we would
expect (hope) that the residual time left before the next TSN would suffice. I
have no idea how putting the shared references at the END of the period, as
opposed to the beginning, would screw up the code's phasing. All this makes my
head ache and it's YOU who have to cope with the details.
S.
*start*
02099 00024 US
Date: 18 May 1982 4:42 pm PDT (Tuesday)
From: ornstein.PA
Subject: Consultants for Voice Project
To: Taylor, Averitt, Mitchell
cc: VoiceProject↑
Reply-To: ornstein
1. BILL DUVAL
Several months ago we bought a C compiler from Duval. It's written in BCPL,
runs on an Alto, and compiles 8088 code (for the Etherphone). Duval has been
under contract to SDD, but on the side has fixed a number of bugs in the
compiler for us. It's now at the point where we're crossing the boundary between
fixing bugs and adding features, so we need to begin to pay him - or the work
will never get done. We discussed with him what was needed and concluded we
need about a week's work. However, in case we come up with something further,
I want to leave things a bit open-ended, and would prefer something like time
and materials with maximum of (say) two weeks of his time. He says this cannot
be done under the present SDD contract; wants to negotiate a new fee for this
work (says Xerox is one of his poorest paying customers, etc). I've just talked to
Harlan who is going to consider all this and get back to me. I'd like the
arrangements to be settled ASAP. Meantime we are working up a prioritized list
of tasks for Duval and will discuss them with him.
2. RON TOLMEI
We need some analog circuit design for the Etherphone. Larry COULD do it, but
he's busy as hell with the digital stuff and programming and is not expert in
analog phone circuitry. We got hold of Tolmei (has a 10-man consulting firm in
Walnut Creek) on a recommendation of Marty Graham (UCB Prof.). After signing
a Disclosure agreement we had him over for a chat yesterday and explained what
we need. (His rate is $60/hour; I took it on myself to say we'd find a way to pay
him for yesterday at least). He is going to contact me by Friday and give an
estimate of time/cost to do the job. I spoke to Harlan about this as well and
Harlan's preference is to hire him as a consultant - here again I want time and
materials since I want him to help us fix it until it works. More on this as soon
as we hear back from him.
*start*
04313 00024 US
Date: 19 May 1982 11:03 am PDT (Wednesday)
From: ornstein.PA
Subject: Problems with the C environment:
To: Duvall
cc: VoiceProject↑, Averitt
Reply-To: ornstein
Bill,
The following is a memo that Larry and Dan prepared containing their requests
and complaints. Contact Larry if you have questions. The test cases are on
[Indigo]<Voice>Larksw>.
I called Harlan and told him I thought we would need about a week of your time
- but I wanted an arrangement whereby we could get more if needed. He's to
call me back shortly. Meanwhile I told him we are presenting you with this
list.
Severo
- - - - - - - - - - - - - - - -
Stewart, D. Swinehart, May 18, 1982 3:10 PM
Priority order
Compiler runs out of space.
Test case:
Test122.c
Test123.c (same, but most nested structures replaced by int[n])
Ldr86 runs out of space on suitably large programs. Perhaps change it so that all
Externals need not be resolved on the first pass. (e.g. LDR86 should be able to
run multiple passes.) It could be used as the assembler second pass on each file.
Compiler, assembler, loader to run on D-machines. We can getr microcode that
does not implement getframe and storeargs. The remaining problems might be
use of extended memory in alto-specific ways and perhaps diskio.
Direct to memory operations on structure fields don't work. They always
reference the first word of the structure.
Test case:
Test117.c
JUMP range overflows
I have a program that won't link because a short jump won't reach.
Test case:
Test115.c
Test115.ld
Test115ls.cm
Directions: Run @Test115ls.cm@ and observe LOC-86 error message.
I remember having trouble with case statements in other code as well.
If the case statement is too complicated or too long it quits working.
Minor stuff
Sys.bk. Some way to link programs to the separately linked and loaded stuff in
EPROM. Intel loader has something called PUBLICSONLY that might do it.
GROUP directives
I have not been able to link together two C generated programs
Test case:
Test114a.c
Test114b.c
Test114.ld
Test114ls.cm
Directions: Run @Test114ls.cm@ and observe LOC-86 error message.
The problem appears to be that multiple GROUP directives break
the loader. I don't believe that the GROUP directive in the assembler
files produced by the compiler are actually needed. Perhaps the simplest
solution is to take them out.
The loader does not produce an error file. Usually there will be error
messages flashed on the display, but they will scroll off. The .map file
usually winds up empty. Perhaps the problem is that IO is buffered and
doesn't get written to disk.
When there is an undefined external in a link, the linker mentions it, but
then proceeds to produce piles of "Multiply Defined" messages for a lot
of other symbols.
Minor stuff, unordered
The date printed by the C compiler is still July 1, 1981.
.ERR files produced by the compiler have two difficulties. First, the err file says
"C errors for file foo.err" instead of "C errors for file foo.c".
Second, the C compiler prints warning messages for undefined static variables,
but does not stop. Since I use command files, and immediately assemble the
.asm file, the assembler overwrites the .err file produced by the compiler and I
never see it! Perhaps the c compiler could write .CERR files instead, so
the information would not be lost. In my code, undefined statics are usually
bugs.
When there are no errors, the compiler and assembler still produce .err files. It
would be nice if in this case the .err file was deleted. That would permit me to
use the IF.run program in command files to stop on an error. The compiler and
assembler might also include a "don't stop on error" option to further this goal.
Assember thinks AH is the same as AL.
Test case:
Test118ml.asm
Test118.ld
I have not been able to figure out how to make ORG work in the assembler.
Move immediate to memory
I have not been able to generate a move immediate to memory instruction.
Test case: Test112ml.asm
Forward References
I have not been able to get FORWARD to work
Test case: Test 113ml.asm and Test113.ld.
Directions: Assemble and load, then look at .map file
*start*
02146 00024 US
Date: 20 May 1982 1:32 pm PDT (Thursday)
From: ornstein.PA
Subject: Etherphone Locator Decisions
To: VoiceProject↑, Overton, McCreight
Reply-To: ornstein
This is to record a few ideas about the Locator for the Etherphone arrived at
during luncheon discussion a few minutes ago.
1. Physical Arrangement
We expect the Etherphone proper (not counting the telephone handset, speaker,
microphone, etc.) to consist of:
1. a digital board (ETT) roughly 6" x 12", beside which (maybe mounted
on standoffs or maybe hinged from the ETT board), would be
2. an Analog board (EAN), perhaps 4" x 6" (Larry's rough guess).
3. The remaining area (of the second layer), maybe 8" x 6", would be
dedicated to a third board, the locator logic board (LLB) - physically
connected in a similar fashion to ETT.
Edge connectors and short ribbon cable provide electrical connections between
ETT and EAN (about 30 connections), and between ETT and LLB (unknown,
but smaller, number of connections). The LLB will also require connection to
some form of small external antenna. (EAN and ETT include other external
connections not mentioned here). A suitable flat-form power supply might form a
third layer.
This hypothetical physical arrangement is subject to Mike's scrutiny and later
evaluation, modification etc. - the important point being isolation of the LLB
onto a separate board.
2. LLB Logical Interface
The LLB will receive and unravel incoming signals (radio or whatever). The
unraveling will almost certainly imply using its own microprocessor) which will
pass, to the ETT, messages of the form "I just heard X at intensity Y". How these
messages will be passed remains undecided - one possibility being via an
Ethernet connection (a second SLC on the LLB sharing the Lark side of the
Ethernet transceiver line).
3. Power for the LLB
Ed says we should allow him 1.5 amps of +5 volts and .5 amps of +12 volts.
These arrangements permit independent development to proceed; the locator can
be added to the Lark at any convenient time, with only modest negotiations
about actual acerage, details of communication, etc.
*start*
00361 00024 US
Date: 20 May 1982 3:06 pm PDT (Thursday)
From: ornstein.PA
Subject: Ron Tolmei - Analog guy
To: Stewart, Swinehart, Lampson
cc: ornstein
His estimate was 4 weeks and $14,800. I told him please send our drawings back
with his bill for time so far. I'll pursue Gunning's leads. Next one we'll do more
initial probing over the phone.
S.
*start*
00445 00024 US
Date: 21 May 1982 9:38 am PDT (Friday)
From: ornstein.PA
Subject: DTMF Encoder
To: VoiceProject↑
Reply-To: ornstein
This is to record the fact that in discussion yesterday Dan, Larry, and I decided
that, after all, we should include a DTMF encoder (only a few dollars and little
real-estate) on the Lark analog board - to avoid all the hassles of trying to pass
sufficiently accurate tone (segments) from Thrush.
S.
*start*
01571 00024 US
Date: 23 May 1982 3:14 pm PDT (Sunday)
From: Stewart.PA
Subject: DEC Voice Box
To: VoiceProject↑.pa
cc: NDSmith, Braun.es, Irby, DaveSmith, Dalal, Roberts, Trigoboff, Nagata,
Verplank, Stewart
------------------------------
Date: 22 May 1982 1123-EDT
From: John R. Covert <RSX-DEV at DEC-MARLBORO>
To: schauble.multics at MIT-MULTICS
Subject: Voice CBBS
The new DEC personal computer (the Professional 325 and 350) has an
option called the Telephone Management System which consists of line
interfaces for two telephone lines, 103, 212, 202, V.21, & V.23
modems, DTMF (Touch-Tone is a trademark of AT&T) transmitter and
receiver, and CVSD Voice CODEC for voice storage. The device will be
capable of listening for Touch-Tone, timing out (under PDP-11 program
control), and then playing a pre-stored voice message, random accessed
from floppies or winchester. Four minutes of voice uses one megabyte
of disk, so it is handy to have an Ethernet connection to another
machine with more storage if you want to take lots of incoming
messages. The device could theoretically call you wherever you are to
play messages it received for you. This would, of course, be subject
to all the phone network problems previously discussed in this digest
w.r.t. figuring out whether someone had actually answered.
TMS isn't very expensive at all, $895 + $295 for the optional Voice
Unit (a speaker/microphone box for local use of the voice encoding).
The Professional 325 & 350 are competitively priced personal
computers.
------------------------------
*start*
00265 00024 US
Date: 25-May-82 15:08:06 PDT (Tuesday)
From: Verplank.pa
Subject: Thanks for being there.
To: Stewart, Swinehart
cc: DaveSmith, Irby, Verplank
Larry, Dan,
Thanks for just the right amount of stimulating input to our deliberations. -- Bill
*start*
01367 00024 US
Date: 25 May 1982 3:48 pm PDT (Tuesday)
From: ornstein.PA
Subject: Buying Parts for Analog Board
To: Stewart
cc: ornstein
Here's the list I know of.
Motorola MC142100 4 x 4 analog switch
MC1458 dual op-amp
Mostek MK5089 Tone dialer
Mitel MT8860 DTMF decoder
MT8865 DTMF filter
Intel 2910A Codec
2912A PCM filter
Fairchild TIL119 Opto Isolator
PMI SW7510 quad SPST bi-fet Analog switch
National LM319 dual voltage comparator
LM386 low-voltage power amplifier
Questions etc.:
0. Is two each of the above about right, or should it be three or four?
1. What is a 5534 (as for example used in the Microphone pre-amp)?
2. What other parts, used in the telephone and handset interfaces, that I don't
recognize/understand should I order?
3. I will see Mike about finding a +5 volt Dip relay instead of the +12 ones
shown on the telephone and handset interfaces
4. What about the transformers (T1 and T2) shown on the telephone interface?
What is a 671-0313?
5. What is the funny device on the telephone interface marked SV1 with
opposing parallel diodes?
6. Should I assume that all the diodes, resistors and capacitors are standard items
Mike would have in stock or does each one have to be individually checked?
(e.g. is a 1N4737A something special?)
7. I'll ask Mike about the 100uH inductors.
8. Anything else?
S.
*start*
00381 00024 US
Date: 25 May 1982 5:17 pm PDT (Tuesday)
From: ornstein.PA
Subject: Discussion with Thacker
To: Stewart
cc: ornstein, Thacker
In discussing the problem of the analog board - how/whether to get help with it
etc. Chuck suggested the three of us get together at 2 PM this Friday (in
Chuck's office) to talk over what is the problem. This is a reminder.
S.
*start*
00686 00024 US
Date: 25 May 1982 5:23 pm PDT (Tuesday)
From: ornstein.PA
Subject: Duvall assistance
To: Averitt
cc: Stewart, Swinehart, Ornstein, Taylor
Our feeling is that we really need about a week of Duvall's time for really
essential matters. If we have to pay the 500 a day, and you don't get in big
trouble with SDD over it - we'll do it - but feel somewhat taken. At 400/day,
which seems somewhat more reasonable, we would like a little more help -
(though I guess that only really gets us one more day).
I guess in summary, $2500 for necessary help seems worth it - and that should
be accomplishable within a week's work. More $ than that seems excessive.
Severo
*start*
02308 00024 US
Date: 26 May 1982 12:35 am PDT (Wednesday)
From: swinehart.PA
Subject: Hold on request for special Dorado microcode
To: Taft
cc: Stewart, swinehart
There is probably a better way to get the effect we want, at least on the Dorado.
The effect we want is for a class of ideosyncratic programs (Duvall's C-86,
ASM-86, and LDR-86 language processors) to run on the Dorado. As far as we
know, these programs have the following incompatible attributes:
1. They use the Smalltalk-76 style approach to putting the display in bank 1.
This requires that the emulator and display task do the right things with respect
to bank register requests (is bank reg 5 still the right one to indicate the bank
selection for the display task?).
2. They count on a modified version of the getframe microcode, which:
a) allocates two additional words in each stack frame, then:
b) zeroes the word just below the new stack back (the second of the
additional words for the NEXT frame allocated.)
This is used to implement a modern version of the ancient and notorious
POGOS seterror/callerror kludge.
I am rusty, but it's my recollection that the Smalltalk microcode includes the
complete BCPL emulator, and will run BCPL, too. So it would seem that the most
straightforward way to support these programs is to modify a version of that
Smalltalk microcode to allocate frames as specified in step 2. I've sketched the
one or two instruction (depending on what works) addition to the getframe
microcode, but haven't assembled or tested it. Bill's programs currently call
InitBCPLRuntime, but the effects of that would be totally ignored, I believe, on
the Dorado.
The reason for doing things this way is to minimize the amount of work that we
have to ask Bill to do for us under contract. I'm beginning to think that is a
very good strategy, indeed.
Let me know if this approach seems sound to you; if so, clearly you shouldn't
bother to produce the version of the microcode that doesn't trap GetFrame.
Thanks,
Dan
P.S. I assume there's no way to get the effect of
T← (Store←T)+1, DBuf ← 0;
in one Dorado instruction, unless you have put a zero into some R register in a
preceding instruction. If this is the case, the change takes one more
microinstruction. I'm sure we'll notice.
*start*
00332 00024 US
Date: 26 May 1982 8:44 am PDT (Wednesday)
From: ornstein.PA
Subject: Tone Generator
To: Stewart
cc: ornstein
The DTMF generator takes in 4 row lines and 4 column lines to generate tones.
Should we just use up 8 PIO lines for this? Are the names DTMFRow0 -
DTMFRow3, and DTMFCol0 - DTMFCol3 acceptable?
S.
*start*
00707 00024 US
Date: 26 May 1982 8:50 am PDT (Wednesday)
From: Taft.PA
Subject: Re: Hold on request for special Dorado microcode
In-reply-to: swinehart's message of 26 May 1982 12:35 am PDT (Wednesday)
To: swinehart
cc: Stewart
Too late...
[Ivy]<Taft>Swinehart.mb is a vanilla Alto emulator without BCPLRuntime and
with the XMFaultTask that handles Alto-style bank switching for the display.
Retrieve it and [Indigo]<Dorado>LoadRam.run, and then type
> LoadRam Swinehart.mb
to load and start the special microcode.
With regard to your Dorado instruction, you can do precisely that, but the
syntax for an encoded constant includes an appended "C". That is:
T← (Store←T)+1, DBuf ← 0C;
Ed
*start*
01070 00024 US
Date: 26-May-82 9:24:40 PDT (Wednesday)
From: Verplank.pa
Subject: Re: DEC Voice Box
In-reply-to: Stewart's message of 23 May 1982 3:14 pm PDT (Sunday)
To: Stewart, Swinehart
cc: NDSmith, Dalal, Verplank
I would like to get more detail on approaches to compression. As I understand it, we want to use the 64kbs mu-law for it's quality. The CVSD codec that DEC is using does not have adequate quality. (adequate for what?) Our preferred approach(es) to compressions would be:
1) silence suppression/encoding with the option to play back with or without the silence added back in (or better would be some simulation of background noise)
2) a kind of background archiving at the voice server which would compress (and degrade) on some schedule those voice files with low enough priority to not require high quality, and with high enough priority to not be flushed (or put on tape).
What are some of the options for how we do this.
Our current plans are for no compression - I just want to be sure I can answer the obvious questions.
--Bill
*start*
01330 00024 US
Date: 26 May 1982 10:14 am PDT (Wednesday)
From: ornstein.PA
Subject: Parts for Analog Board (#2)
To: ornstein, Overton
cc: Stewart
----------------------
Specials:
Motorola MC142100 4 x 4 analog switch 1 ea.
MC1458 dual op-amp 2 ea.
Mostek MK5089 Tone dialer 1 ea.
Mitel MT8860 DTMF decoder 1 ea.
MT8865 DTMF filter 1 ea.
Intel 2910A Codec 1 ea.
2912A PCM filter 1 ea.
Fairchild TIL119 Opto Isolator 2 ea.
PMI SW7510 quad SPST Analog switch 1 ea.
National LM319 dual voltage comparator 1 ea.
LM386N-1 low-voltage power amp 1 ea.
Signetics NE5534 single op-amp 1 ea.
Midcom 671-0313 hybrid transformer 2 ea.
Schauer VR-60 silicon varistor 1 ea.
----------------------
1. Get prices for above items. Then we will decide how many of each to buy.
Probably get 10 of cheapies and a few of the expensive ones.
2. Find a +5 volt Dip relay - 4PDT - instead of the +12 ones shown on the
telephone and handset interfaces
3. Be sure we've got some 100uH inductors?
4. Discuss building a prototype on vector board with Larry and Mike
----------------------
Assume that all diodes, resistors and capacitors are standard items that we would
have in stock except Zeners. Zener of equivalent voltage rating is OK - else get
the specific one (e.g. 1N4737A)
*start*
03586 00024 US
Date: 26 May 1982 1:19 pm PDT (Wednesday)
From: Stewart.PA
Subject: Re: Compression
In-reply-to: Verplank's message of 26-May-82 9:24:40 PDT (Wednesday)
To: Verplank
cc: VoiceProject↑.pa, NDSmith, Dalal
Before any discussion of quality, let's examine required hardware. It seems clear
that compression of non-interactive voice need not be real-time, and could be
done by software as a background task. De-compression, however, seems to
require real-time service -- you don't want to ask users to give advance notice
of intent to play something back so it can be decompressed.
mu-255 encoding would most naturally use an LSI codec chip (combined A/D,
encoder, decoder, and D/A) at each terminal. There would be no additional
compression hardware anywhere. Silence detection might require a small amount
of hardware at each terminal which records, but none at any playback-only
terminal. Without real-time software silence detection or hardware, silence
suppression could still be accomplished by background software in the file
server. Playing back silence is trivial of course.
CVSD chips are also available (e.g. Motorola). Such a chip would be required at
every terminal to allow real-time playback. These chips supply direct
analog-to-compressed conversion, so if you only want CVSD, you don't need the
mu-255 codec.
Other kinds of compression seem best suited for digital signal processing chips
such as the (new) TI TMS 320. (See Electronic Design May 27, 1982, p 129) The
TMS320 can handle LPC at 2400 bps in real-time and also roughly 10 Kbps
speech with quality approaching that of mu-255 (probably better than 16 Kbps
CVSD by a good margin.)
If you forsee a world with many different speech formats, I suspect a voice
terminal with a reprogrammable (read RAM, not ROM) digital signal processing
chip will be required.
Incidently, the Alto/Auburn has a 12 bit linear A/D and D/A (96 Kbps).
Compression to 64 Kbps mu-255 or to 16 Kbps Adaptively quantized differential
PCM (ADPCM) is done by microcode. If you can burn a workstation microcode
task (and ~20% of the CPU cycles) on voice, you may not need special hardware
to achieve 16 Kbps CVSD quality compression. I imagine the CVSD chip is
cheaper.
I think the reasonable steps are:
96-128 Kbps linear uncompressed, very good quality
64 Kbps mu-255 quality of a very good local phone call
32 Kbps ADPCM/CVSD almost as good, slightly noisier
16 Kbps ADPCM/CVSD noticably noisier
9.6 Kbps APC, Sub-Band signal processing needed, ~equivalent to
32 Kbps CVSD
2.4 - 6 Kbps LPC etc. signal processing needed, speaker recognition
somewhat impaired, some familiarity required
for consistant understanding
If you go for a DSP equipped voice terminal, you can mix and match any of
these. If you go for microcode, you can mix & match above 16 Kbps. If you go
for hardware, you will be limited to mu-255 and/or CVSD depending on which
chips (or both) you put in the terminal.
I suspect the right way to do the deciding is to figure out which is cheaper.
Equipping every terminal with a CVSD chip or DSP in addition to the mu-255
codec or buying more big disk drives. How much will be stored?
(I should mention that if you build 9.6 Kbps or below, you can sell them as
secure (encrypted) digital telephones.)
Perhaps you should build your PC boards with sockets for both a mu-255 codec
and a CVSD chip, then plug in either or both. A DLion Mesa program can
probably approach real time converting from one to the other if it is not doing
anything else.
-Larry
*start*
01504 00024 US
Date: 26 May 1982 5:06 pm PDT (Wednesday)
From: ornstein.PA
Subject: Duvall consulting
To: Stewart, Swinehart
cc: ornstein, Taylor, Averitt
Harlan suggests one of three approaches:
1. Offer $2500 for a specified set of tasks.
Advantage is we know what will get done; disadvantage, no flexibility.
2. Offer $500/day for up to a max. of $2500 - for whatever gets done in 5 days.
Advantage is we limit our max outlay (to less than #4) and have flexibility;
disadvantage, we may not get all we need done.
3. Offer $400/day for up to a max. of $4000 - for whatever gets done in 10 days.
Advantage is we have flexibility, can get more done than under 1 or 2 and at a
lower rate; disadvantage is higher max outlay and less incentive.
Harlan sort of likes #1 but thinks Duvall won't like it or might not satisfy our
minimum needs for that much. I think Harlan's second favorite is #3. The
question is, what do WE think and want? Larry and I talked and concluded that,
given the alternatives, 2500 was about right and 5000 was too much. So I tend to
favor 1 or 2 and, to the extent we think we can judge the size/trust Duvall/etc.,
prefer 2. What do you guys think?
On May 19 I sent Duvall a msg. listing all the things you had listed in your
May 18 "Problems with the C environment". I gather you've given him a couple
more items since then. If we propose 1 or 2, we will need to narrow the list to
what we reasonably expect he can do in a week.
Comments? Suggestions?
S.
*start*
00845 00024 US
Date: 26 May 1982 5:26 pm PDT (Wednesday)
From: ornstein.PA
Subject: Wiring Trouble?
To: Stewart
cc: ornstein
The notebook drawing indicates the output of the LS32 gate goes to SLCDAck (I
assume you meant SLCDAck' - I added the ' to the drawing). However it looks to
me as though you have wired it instead to the input of the inverter in H61
which was used to invert the DMA's SLCDAck' to SLCDAck for the use by the
SLC. That seems fine - except you didn't bend up the input leg of the inverter.
So it seems that that pin is also being driven directly by the DMA's SLCDAck'.
Thus, even though the LS32 tries to pull it up, the DMA's SLCDAck' pulls it
down - so it's as though the flop weren't there.
Is this correct?
S.
P.S. After finding that, I quit looking further - but will continue if that isn't the
problem.
*start*
00632 00024 US
Date: 26 May 1982 7:36 pm PDT (Wednesday)
From: Swinehart.PA
Subject: Re: Hold on request for special Dorado microcode
In-reply-to: Taft's message of 26 May 1982 8:50 am PDT (Wednesday)
To: Taft
cc: swinehart, Stewart
Thank you for your efforts. I hope it didn't take too long to do. I'll ask your
advice in producing my even stranger configuration later on. Sounds like it's
just a matter of pasting the right pieces together.
I would have written the 0C form had I tried it. Mainly I didn't know if there
was enough microinstruction left after issuing the Store to get the constant onto
the B bus.
*start*
02677 00024 US
Date: 1 June 1982 12:11 pm PDT (Tuesday)
From: Swinehart.PA
Subject: Update on C-86 Travails
To: Duvall
cc: VoiceProject↑, Swinehart
Reply-To: Swinehart
Bill,
I'd appreciate it if you could call me (x4473) sometime soon to discuss how long
you think our list of projects (or some rational subset of them) will take. This
will help us with Harlan in trying to get things set up.
I also thought I'd bring you up to date on where we are, since Severo's message
of a week or so ago. Since then, I've discovered the following things:
1. There is a built-in limit on the total number of structure definitions and
structure field definitions (18 and 108, respectively, if you believe symbols
average 16 characters -- in practice, somewhat more than that.) I found the
relevant constants and doubled them. The tables still fit, and all my programs
fall within the doubled limits. Ideally, these values could be made variables
under control of some of your numerical option switches, but the "out of space"
problem can now be relegated to the minor annoyance category, which we can
ignore if we run out of time.
1.5. I managed to get all of my programs (about 8 files, each 4-6 pages long) to
compile, after I raised the limit. It all looks pretty good to me!
2. By inhibiting the call to InitBCPLRuntime in the C compiler, and by
producing a version of the Dorado microcode that implements your variant of
GetFrame along with the appropriate subset of the bank register stuff, I managed
to run the compiler on the Dorado. I haven't tried the assembler and loader, but
I expect no difficulties. I was not able to get your debugger to operate on the
Dorado -- special op codes or something -- but that's not a serious problem if it's
difficult to deal with. 'Twould be nice to have the InitBCPLRuntime decision,
etc., automated, based on machine version information. In any case, the "D
machine" compatibility issue is also now a minor, expendible item.
3. Larry told me that you told him that one could say &P to get the address of
procedure P. I tried it and got "missing (" errors. We need to be able to generate
these addresses (for both local and external procedures). This is a new high
priority item for us.
4. Also, Larry has some functions that will do the calls to these "procedure
variables", but the whole process could be made smoother if a special facility
were provided (a built-in "Call" pseudo-procedure, for instance.) If this seems
like a straightforward thing, we should add it to the "Minor stuff" category;
otherwise, forget the whole thing.
I'll be here most of the week, except after 2 today.
Thanks,
Dan Swinehart
*start*
00588 00024 US
Date: 1-Jun-82 14:21:16 PDT
From: Swinehart.pa
Subject: More "Needed.h"
To: Stewart
cc: Swinehart.pa
I have looked more carefully at the function that I call "MoveBytes" in one of my D programs. What it really is is "MoveBlock" with a boolean parameter that indicates whether the bytes in each word should be swapped or not, so it should probably have a different name. The interface would be:
MoveBytes(dest, source, wordCount, swapBytes)
int *dest, *source;
int wordCount; /* number of WORDS to move, believe it or not */
int /*BOOL*/ swapBytes;
...
*start*
00917 00024 US
Date: 3 June 1982 10:57 am PDT (Thursday)
From: ornstein.PA
Subject: Duvall Consulting on Voice Project
To: Averitt
cc: Stewart, Swinehart, ornstein, Mitchell, Taylor
Harlan,
Dan Swinehart sent Bill Duvall a list of (minimum) needs and Duvall responded
that the list involved 41 hours work. That sounds like a week to me. We would
thus like to arrange that he will do that work for a fixed fee of $2500 (which in
fact amounts to his $500 per day if his time estimate is correct).
We might negotiate with him about one or two small items on the list - possibly
substituting, by mutual agreement, some other equivalent sized items; but that is
a detail.
Unfortunately I have to be gone from town for approximately a week starting
tomorrow. In my absence I would ask that you use Dan Swinehart in my place.
I hope this all works out OK; please let Dan know. Thanks for your help.
Severo
*start*
00567 00024 US
Date: 3 June 1982 3:14 pm PDT (Thursday)
From: Gifford.PA
Subject: Digital Pager
To: McCreight, VoiceProject↑
cc: Gifford
Reply-To: Gifford
I thought I would voice a personal preferance for a digital pager as contrasted
with a locator. By pager I mean a device that would "ring" when my phone
rang. When my pager rang I presumably would head for the nearest
conventient ether-phone, punch in my extension, and answer the call. Pagers
could be used for other things as well (to deliver messages while I am in a
meeting, and so on).
Dave
*start*
00231 00024 US
Date: 3 June 1982 3:46 pm PDT (Thursday)
From: ornstein.PA
Subject: Analog (EAN) board files....
To: Stewart
cc: ornstein
...are stored on [Indigo]<Voice>Ean*.sil - should you want them in my absence.
S.
*start*
00499 00024 US
Date: 4 June 1982 11:02 am PDT (Friday)
From: averitt.PA
Subject: Re: Duvall Consulting on Voice Project
In-reply-to: ornstein's message of 3 June 1982 10:57 am PDT (Thursday)
To: ornstein
cc: Averitt, Stewart, Swinehart, Mitchell, Taylor
Severo,
I'll purpose that Bill accept the fixed fee ($2500) rate to accomplish the job
described. This probably won't get "massaged" until Monday at the earliest, as I
will be out this PM and Friday. I'll keep you informed.
Harlan