*start*
00334 00024 US
Date: 27 APR 1982 2237-PDT
From: STEWART.PA
Subject: Files Archived
To: VoiceProject↑
[Maxc]<Voice>LarkETPSoftware.dm contains all my Lark code
to date. Most of it is for the 'old' design, ETP. I intend to
decommission it soon and will delete all the old software. It can be
retrieved from tape.
-Larry
*start*
01451 00024 US
Date: 29 April 1982 8:26 am PDT (Thursday)
From: KARLSSON.ES
Subject: Re: 8086 tools
In-reply-to: Your message of 19 April 1982 3:24 pm PST (Monday)
To: Stewart.PA
cc: Karlsson
Larry,
I apologize for not responding to you sooner.
Assembler:
The 8086 and 8051 ALTO based assemblers are currently available.
However, there is no linker available to handle the object file output by the
assembler. I will be converting the assembler to change the format of the object
code file it is generating as soon as the format for EDR's binder is stabilized.
Depending on when EDR gets their binder complete, I probably will have the
assembler changed by the end of July.
Linker:
The linker that out group was doing was dropped at a near completed
stage. We are planning on using the binder being developed by EDR. There
binder has been up and working; however, they are changing the format of
their input and output files. This hasn't been completed yet. According to them,
they will be done any day now.
Debugger:
Our group has been working on a primitive debugger to handle many
different microproccesors, one of which is the 8086. The first version of the
debugger is being released on April 30, 1982. EDR will be providing a symbolic
debugger which will be available in September.
If there are any other questions or if you would like further information or
documentation on any of these projects, please ask
Marita
*start*
00913 00024 US
Date: 29 April 1982 10:10 am PDT (Thursday)
From: ornstein.PA
Subject: Sil Libraries
To: Stewart
cc: ornstein
Larry,
I have stored three files on my <Ornstein> Ivy directory:
ETTLb9.sil The font 9 library itself (with the 64 K RAM fixed to match yours
from ETT-rev-Ac)
EAN31.sil Pictures of all the font 9 macros up through letter "v"
EAN32.sil A list of what all the font 9 macros are - plus the pictures of
font9 macros "w" and "x" (which wouldn't fit on EAN31.sil)
There is no more room in font 9, so I'm going to start defining further macros in
font 8 (ETTLb8.sil). I will include their pictures and names on EAN32.sil (and
will clearly distinguish font 8's and font 9's). As I don't plan to further touch
font 9, unless you find you need further macros yourself, I don't think you
particularly care about ETTLb8.sil or the corresponding additions to EAN32.sil.
Severo
*start*
00514 00024 US
Date: 29 April 1982 12:14 pm PDT (Thursday)
From: ornstein.PA
Subject: Correction
To: Stewart
cc: ornstein
I decided to clean things up and move the "w" and "x" font 9 macros into font 8
as macros "A" and "B". (There is no easy way I know of to remove them from the
"w" and "x" macro definition slots in ETTLb9.sil, but no matter, they can be
redefined if wanted).
I cleaned up Ean32.sil accordingly - removing the pictures and leaving two lists
(fonts 8 and 9) of macro identities.
S.
*start*
00586 00024 US
Date: 29 April 1982 3:23 pm PDT (Thursday)
From: Pasco.PA
Subject: Auburn Files?
To: Stewart
cc: Pasco
Larry, do you know what happened to the Sil files, manual, etc. for Auburn?
It used to be on [Ivy]<Audio>Auburn>. That directory is not there any more.
There is no Auburn stuff on [Indigo]<Audio> either. There is very little on
[Ivy]<Speech>.
P.S. I'm going to turn access to [Ivy]<Speech> over to you. Use it in good
health, but please don't delete anything (especially IC layouts) until I've gone,
and then only if they're safely archived.
- Rich
*start*
00318 00024 US
Date: 29 April 1982 3:54 pm PDT (Thursday)
From: Stewart.PA
Subject: Re: Auburn Files?
In-reply-to: Your message of 29 April 1982 3:23 pm PDT (Thursday)
To: Pasco
cc: Stewart
Everything should be on [Maxc]<Voice> or more probably [Indigo]<Voice>.
[Indigo]<Audio> is my thesis stuff.
-Larry
*start*
00514 00024 US
Date: 29 April 1982 4:10 pm PDT (Thursday)
From: Pasco.PA
Subject: Re: Auburn Files?
In-reply-to: Your message of 29 April 1982 3:54 pm PDT (Thursday)
To: Swinehart, Stewart
cc: Pasco
[Indigo]<Voice>Auburn>WhoHasAuburns.Bravo is obsolete. A somewhat less
obsolete version is on [Ivy]<Speech>Auburn>.
I'd like to get rid of [Ivy]<Speech>Auburn> and will do so as soon as someone
copies the two files on it to [Indigo]<Voice>Auburn>. {I'd do so myself except I
don't know the password}.
*start*
00879 00024 US
Date: 29 April 1982 6:34 pm CDT (Thursday)
From: slade.wbst
Subject: Hallelujah!!!!
To: Sunriseforum↑.dlos
cc: slade
Reply-To: slade
Two days ago I sent out a cryptic message about speaker phones without Codecs.
I'm here to tell ya, folks, the forum works. George Maney of ED wrote right
back with the right stuff. Only this kind of communication net would have
unearthed someone who had recently been with Matsushita and knew all about
speaker phones. End of problem, and (possibly but I hope not) end of CODEC
inside Unicorn, but the heartening thing is that specific technical questions bear
fruit fast.
You will get a summary of the probable results of the current, Mike
Slade-moderated technical issues discussion tomorrow. Please put your oar in.
Unicorn's final form is now being frozen in concrete.
Thanks for your attention,
Robin.
*start*
01615 00024 US
Date: 30 April 1982 10:20 am PDT (Friday)
From: Stewart.PA
Subject: Golly
To: VoiceProject↑.pa
Let this one speak for itself.
---------------------------
Mail-from: Arpanet host MIT-ML rcvd at 29-APR-82 1647-PDT
Date: 29 Apr 82 19:06:14-EDT (Thu)
From: Michael Muuss <mike@BRL>
Subject: New PCM Newsgroup
To: Gurus at brl-bmd, Info-Audio at Mit-Ai
From unc!mcnc!duke!decvax!cca!sri-unix!hplabs!menlo70!nsc!hyperspace Sat Apr 17
15:58:20 1992
Subject: New PCM newsgroup
Newsgroups: net.music
Announcing net.pcm, a newsgroup for the sharing of new audio releases.
Each week you will recieve approx. 360 million bytes of logarithmically
compressed PCM data (at 20khz sample rate) which will wholly reproduce
a complete LP. A wide selection of releases is intended, to appeal to
classical, country, and rock tastes.
Requests for selections should be sent to:
ucbvax!randvax!paramountvax!usenet←releases -or-
ucbvax!randvax!warner←bros!vp←releases -or-
ucbvax!columbia!rca!red←label
Note: network connections with less than 10k baud links should probably
not subscribe. Hard copy analogue form is widely available in those cases.
Format note: Near future releases will all be in the standard SONY PCM
format, but eventually conversion will be made to CIA reference 7-298.212
when that becomes available...
Nick Fumbly
Vice President, Intercompany Network Digital Releases
Paramount Recordings.
Hollywood,CA (uucp: ucbvax!randvax!paramountvax!fumbly
arpa: fumbly@paramount@telenet-gateway)
------------------------------------------------------------
*start*
00741 00024 US
Date: 30 April 1982 5:03 pm PDT (Friday)
From: Stewart.PA
Subject: Remote audio service via Auburn
To: VoiceProject↑
cc: Verplank, Trigoboff, NDSmith, Stewart
I've added a new command, 'Z', (for "BSP Stuff"), to the Audio program which
permits one to set up an Auburn equipped Alto II as a remote A/D and D/A
system. It will accept Pup BSP connections for play-out and record-in of audio.
A companion program is RemoteAudio which runs on any Alto/Mesa machine
and can play and record local disk files via a remote Auburn/Alto.
See [Indio]<Voice>Mesa6> Audio.bcd and RemoteAudio.bcd and associated source
files Audio.config, AudioMain.mesa, AudioBSP.mesa and RemoteAudioImpl.mesa
and RemoteAudio.config.
-Larry
*start*
01804 00024 US
Mail-from: Arpanet host SU-AI rcvd at 3-MAY-82 1647-PDT
Date: Sun May 2 20:35:47 1982
To: info-micro at mit-ai
From: decvax!duke!unc!jqw at CCA
Subject: Intel Hex Format
Article-I.D.: unc.3389
Source-Info: From (or Sender) name not authenticated.
Thanks to all the replies to my question, here is the complete (?)
Intel hex format.
Note that bytes are stored as ASCII hex nybbles,
00 to FF
All calculations (length and checksum) are made with original bytes, not ASCII
representation.
The general form of a record is as follows:
:LLaaaaRRdddd..ddCC
where LL is the number of bytes of data between RR and CC,
not including RR or CC.
aaaa is an address (see below),
RR is a record type,
dd are data bytes,
and CC is a checksum, calculated as follows:
CC = - ( LL + aaaa + RR + dd + dd + ... ( modulo 256 ) )
That is, adding all the bytes LL to CC (inclusive), you should get zero.
For sixteen-bit address files (for 8080 and Z80) these are the record types
needed:
RR = 00 record type = data. aaaa is the load address for the data.
RR = 01 record type = end of file.
aaaa is the beginning execution address.
LL is 00.
:00aaaa01CC
For extended address files (for 8086, etc.), there are two more record types.
RR = 02 record type = Extended Address
:02000002eeeeCC
where "eeee" is bits 4 to 19 of the address where data should
be loaded. All addresses in data records are added to this
to form the full address. If there is no extended address
record, the base address is assumed to be zero.
RR = 03 record type = Start Address
:04000003PPPPiiiiCC
where PPPP is the 8086 code segment register,
and iiii is the Instruction pointer register.
If this record is used, the address in the end
of file record should be set to zero.
*start*
00558 00024 US
Date: 4 May 1982 11:44 am CDT (Tuesday)
From: Kelley.DLOS
Subject: Cross Compiler for C
To: UNIXInterest↑.WBST
cc: Kelley
I am interested in locating a cross-compiler (and a Linker) for the
C language. The target microprocessor would preferably be an Intel 8086
or Motorola 68000. Hopefully, it would be written in a higher level
language itself because I am want to run it on a DEC2020.
Thus, portability is of interest.
Also of interest is the possibility that the cross-compiler runs on an Alto
or Star workstation.
----
Dale
*start*
00714 00024 US
Date: 4 May 1982 10:17 am PDT (Tuesday)
From: Stewart.PA
Subject: Re: Cross Compiler for C
In-reply-to: Kelley.DLOS's message of 4 May 1982 11:44 am CDT (Tuesday)
To: Kelley.DLOS
cc: Stewart
Please let me know what you find out!
I am using Bill Duvall's (Duvall.pa) Alto based 8086 C compiler/ assembler/
linker. It works, but has a sizeable number of gotchas, bugs, and limitations.
ED in El Segundo has an Alto based (written in Mesa 6) assembler for the 8086
and 8051, but there is no linker for it yet. Contact Karlsson.es about that one.
There are commercially available 8086 C compilers which run on VAX VMS or
Unix as well as a number of academic community versions.
-Larry
*start*
01827 00024 US
Date: 4 May 1982 2:14 pm EDT (Tuesday)
From: Gottwald.Henr
Subject: Re: Cross Compiler for C
In-reply-to: Kelley.DLOS's message of 4 May 1982 11:44 am CDT (Tuesday)
To: Kelley.DLOS
cc: UNIXInterest↑.WBST
Reply-To: Gottwald
The best 8086 C compiler package that I've seen is the one sold by Advanced
Digital products. The compiler supports the full C language. Floating point for
the 8087 is supported. Optionally, memory can be allocated for use with the 8088.
Output is symbolic assembly language similar to (but not the same as) Intel's
asm86.
The package also includes a cross-assembler, linker, librarian and down-line
loader. Loader output is standard Intel hex format.
A simulator/debugger is also available. Capabilities include display, breakpoints,
interpretive execution, etc.
The package is sold for PDP-11's under RSX-11M, UNIX/V6 or V7, IAS and
RT-11** or VAX machines under VMS or UNIX/32V. The price they quoted me
was $1750 for the binarie of each of the above three packages. Source licences
are also available.
The company was set up by Darryl Foster - a CS prof at Vanderbilt U. Their
address is:
Advanced Digital Products
1701 21st Ave. S. - Suite 222
Nashville TN 37212
Tel: (615) 383-7520
SuperSoft has an optimizing 8086 C compiler for CP/M. Don't know how
applicable that would be for a DEC machine...
Bill Duvall wrote an 8086 C compiler in BCPL for the Alto. It generates asm86
assembler source. An asm86 assembler, linker/loader and dump program are also
provided. You can find starter documentation in:
[Erie]<Keesom>C-86>ISL8086Support.bravo
Contact Keesom.wbst for details. In my opinion, Duvall blew it by using BCPL
and by deviating rather significantly from "standard" C.
*start*
00497 00024 US
Date: 4 May 1982 3:54 pm EDT (Tuesday)
From: Ziobro.Henr
Subject: Re: Cross Compiler for C
In-reply-to: Kelley.DLOS's message of 4 May 1982 11:44 am CDT (Tuesday)
To: Kelley.DLOS
cc: UNIXInterest↑.WBST
We have a 68000 C compiler on the unix Vax. TonyWest.Pa brought it up
and has given it some use. We also have an 8086 C compiler which I cannot
make any promises for. I think it is a derivative of the Whitesmith 8086 C.
Is there a DEC20 somewhere in Xerox?
//Z\\
*start*
00874 00024 US
Date: 4 May 1982 2:47 pm PDT (Tuesday)
From: ornstein.PA
Subject: Progress and Todays Meeting
To: VoiceProject↑
Reply-To: ornstein
My feeling is that we should take a hard look at where we stand at the end of
June - to see where we are with respect to our predictions. The claim is that by
then we will have a couple of working prototypes of the hardware, that we will
be able to pass voice between them, that we will be within a week of having the
control protocols ready for starting to try to work with Thrush - which is
predicted to be ready to handle simple phone calls by then (albeit without much
robustness).
We also agreed to stop seeking alternatives to Duval's C compiler (unless an
obvious better alternative walks up and grabs us) and to make financial
arrangements with Duval to work on the linker and generally support us.
Severo
*start*
00859 00024 US
Date: 4 May 1982 3:03 pm PDT (Tuesday)
From: ornstein.PA
Subject: This and That
To: Stewart
cc: ornstein
1. When shall we go see Duval? Do you have clearly in mind just what we want
to ask him to do? If not, what steps will get us there?
2. Don't forget to ask Gill to snoop around among the electronicers for possible
help with the analog stuff.
3. I think maybe we SHOULD talk to Mike about the "packaging" issues. It will
clarify what needs to be done.
4. It was rude/selfish to arrive late and make others wait for and look for you -
and I found your general demeanor in the meeting more defensive than
cooperative. I realize you are working hard on this stuff and are presently the
one under the gun most. I appreciate that fully, but it doesn't give you the
prerogative to behave badly. Shape up Goddamit!
Cheers,
Severo
*start*
00332 00024 US
Date: 6 May 1982 4:26 pm PDT (Thursday)
From: Pasco.PA
Subject: [Ivy] directories
To: RWeaver
cc: Stewart, Paeth, Pasco
Ron, I bequeath the following files-only directories as follows. Would you please
change the "Owner" as indicated?
<Icarus> to Al Paeth
<Lyon> to Al Paeth
<Speech> to Larry Stewart
*start*
01738 00024 US
Date: 6 May 1982 7:50 pm PDT (Thursday)
From: Pasco.PA
Subject: Where is it?
To: VLSI↑
cc: LSIInterest↑
Reply-to: Pasco
This message is to leave pointers to everything I've done!
Magic (IC design analysis):
Manual on: [Indigo]<DA>Magic>Magic.Press, .Bravo
Files on: [Indigo]<DA>DStar>
Not maintained. In emergency: Robert <Garner.PA>
Ramtek plotter:
Files on: [Indigo]<DA>RamtekPlotter>
Maintained by: Al <Paeth.PA>
Versatec plotter:
Files on: [Indigo]<DA>VersatecPlotter>
Maintained by: Al <Paeth.PA>
Nuts (CIF-to-Chipmonk utility):
Files on: [Indigo]<DA>Nuts>
Maintained by: Phil <Petit.PA>
IcTester (software) and ATester (hardware)
(Alto-based, Smalltalk-coded IC testing):
Files on: [Ivy]<Icarus>Testing>
Hardware not maintained. Software: Al <Paeth.PA>.
Auburn (Alto Audio board):
Files on: [Indigo]<Voice>Auburn>
Maintained by: Larry <Stewart.PA>
Speech first-order-filter section project:
Files on: [Ivy]<Speech>FOS>
Not maintained.
Speech "Parrot" synthesizer project:
Files on: [Ivy]<Speech>Parrot>
Not maintained.
Unicorn Project:
Files on: [Cactus]<SunriseExchange>
VLSI system Design area involvement: Garner, Paeth, & Borriello
Display controller: Dan <Putman.PA> & Glen <Williams.PA>
Optical Mouse:
Maintaned by: Robert <Garner.PA>
VLSI Systems Design laboratory resources: Gaetano <Borriello.PA>
Integrated Ethernet Controller:
Files on: [Ivy]<IEC>
Maintained by: <ABell.PA>, <Garner.PA>, & <Borriello.PA>
Messages about Xerox 820 Information Processor
Files on: [Indigo]<Services>820.mail, 820-81.mail
Maintained by: Eric <Pugh.ES>, Brian <Waldron.WBST>
Various other mail files archived under [Maxc]<Pasco>*.mail
*start*
04092 00024 US
Date: 7 May 1982 7:38 pm PDT (Friday)
From: Stewart.PA
Subject: Lark Hardware news
To: VoiceProject↑.pa
cc: Stewart
DMA Encryption now works. One hardware bug and two "software" bugs.
The hardware problem was amusing. The IO device decode logic was active
during encryption DMA transfers. Thus when the DMA chip happened to do a
memory operation to or from a memory address corresponding to an existing IO
device port address, the IO device would be selected and written to or read from.
IO devices normally live in a separate address space controlled by a CPU pin
called IO/M'. The Ethernet chip also has such a pin, the DMA chip doesn't,
perhaps since it naturally wants to select both memory and some IO device.
When neither the processor nor the Ethernet chip was in control, the IO/M' net
would float to tri-state off, and be pulled up by a resistor. Pulled up to the "IO"
state, enabling the IO decoder... The fis was to add a gate to set the IO/M' net
low when dma encryption was in progress.
The first software problem didn't cause any harm, only consternation. The
assembler encryption driver carefully loaded the AL register with the encrypt
vs. decrypt control pattern and then wrote over AL. Later, the control pattern
was picked up from CL, which was uninitialized. Apparently though, the C
program which called the driver happened to leave something "close enough" in
CL so that encryption still worked. (This code worked in the ETP Lark.)
The second software problem had the appearance of a hardware problem. The
observed effect was that dma encryption failed about 30% of the time when
operating on 160 byte blocks (always the same data). Putting a dip clip on the
DMA device brought down the error rate to about 0.3%, and touching pin 1 of
the DMA chip (the PRd' net) brought the error rate even lower. Evidently a
timing problem, since capacitance on the memory/io data strobe signals made
such a difference.
Later, I finished the EPROM for the Slave CPU and pluggin in all the rest of the
parts (I've not yet tried the Slave CPU.). The main processor still worked, but
DMA encryption now failed solidly on 160 byte blocks. This made sense since
one of the added parts was the transceiver between the memory data bus and the
slave cpu processor bus. Even though the transceiver was always turned off, it
added capacitance to the memory bus.
I finally got a scope picture showing that data from the encryption chip did not
arrive at the memories until after (more or less) Column Address Strobe. That
was too late. Since this was supposed to work, I went back to the timing analysis
(one of those exceeding long messages two months ago) to see what went wrong.
Right there it said "DMA chip must not use extended writes". Extended writes
are a mode of the DMA chip that starts the memory write strobe one cycle earlier
in order to make it longer. By not using this mode, one gives the encryption
chip an extra 255 nanoseconds to get its data on the bus.
I changed the encryption driver to use the right DMA mode and now
everything works fine. I've dma encrypted and decrypted about 240 megabits
with no errors.
Incidently, the timing analysis suggested using different DMA modes for reads
from memory and for writes to the memory (writes to the encryption chip or
reads from it, respectively). This can't be done, because the read and write
cycles are all interleaved during a ciphering operation and there is only one
mode for the whole DMA chip, not independent modes per channel. One of the
other timing constraints of the encryption chip is a 175 nanosecond minimum
width write pulse. Making the write pulse from the DMA chip narrower in
order to make memory writes work at all makes it uncomfortably close to this
limit. I've measured it at about 210 nanoseconds and the DMA chip spec seems
to say that it will always be at least 195. ("Seems" because this value can only
be obtained by subtracting two other specs!)
-Larry
PS: Encryption runs at just over 900 Kbps now, up from 640 with the old
design.
*start*
01189 00024 US
Date: 10 May 1982 2:43 pm PDT (Monday)
From: ornstein.PA
Subject: Alanog Consultant for Voice
To: VoiceProject↑
cc: Taylor, ornstein
Reply-To: ornstein
At Butler's suggestion, I contacted Prof. Marty Graham at UC Berkeley. He would
have a conflict of interest problem so he recommended one Ron Tolmei of
"Innovation" (a small consulting outfit) in Walnut Creek. I spoke to Tolmei on
the phone just now and told him VERY generally what our problem was. I am
sending off a suitable disclosure agreement form and as soon as we get that back
from him signed, we are to call and discuss the problem in detail - together with
methodology for working together, terms, conditions, fees, etc. We'll proceed from
there depending on how that goes.
Probably before anything is finally concluded (contract signed) we would want
him to come for a day to see things and so we could meet him and size him up.
As he lives so far away it would be a whole day for him but I assume it would
not be a problem for us to pay him some fee for the day. Bob, is that correct?
I wish I could find someone closer by but I don't know of any other sources.
Suggestions are welcome.
Severo
*start*
02964 00024 US
Date: 15 May 1982 8:23 pm PDT (Saturday)
From: Stewart.PA
Subject: How to make a Lark Slave CPU EPROM
To: VoiceProject↑.pa
Making the 8K x 8 EPROM for the Slave processor is an involved process:
The code is called "Loop3ml.asm" because it handles three outgoing voice streams,
as for a four party conference call. This program is assembled and loaded by a
command file Loop3ls.cm, resulting in a binary Intel format absolute object file.
The program is loaded under control of the link command file Loop3.ld, which
specifies that the code segment is to be placed at address E000 (the base of the
eventual EPROM) and that the Data segment is to be placed at C800. The data
segment hold the shared memory variables used by the slave program:
C800 -- InGain -- gives table address of input gain reduction table (read)
C802 -- OutGain -- gives table address of output gain reduction table (read)
C804 -- Bptr -- Current ring buffer offset (write)
C806 -- SilVal -- Silence indication (write)
Read/Write are as seen by the slave CPU.
Loop3ml.asm has wired in assumptions about the EPROM addresses of the silence
detection translation table and the linear to U255 conversion table. The other
tables (input and output gain reduction) are not wired, as their addresses are
read from shared memory. Loop3ml.asm also wires the ring buffer addresses in
shared memory:
C000 Input ring buffer (microphone)
C200 Output buffer 1
C400 Output buffer 2
C600 Output buffer 3
The various translation tables are constructed by the Cedar system under control
of [Indigo]<Voice>EP>U255.df. The program LarkTables.bcd writes a number of
binary files with the memory images of the various tables. LarkTables.bcd
handles byte swapping of word tables, but does not swap byte tables.
The code and the tables are combined into LarkSlave.mb by the Cedar system
under control of [Indigo]<Voice>EP>ObjToMb.df, which is a fairly general tool
for combining this and that to construct an mb file. The command line for
ObjToMb.bcd is in
[Indigo]<Voice>ETP>MakeMon.cm as
objtomb -both -baseaddress E000 -romsize 8192 -fixup FFF0 00EA -fixup FFF2
00E0 -fixup FFF4 0000 -outputfile LarkSlave.mb -hexfile Loop3.obj -binaryfile
LarkLinear00.table EA00 512 -binaryfile LarkLinear03.table EC00 512 -binaryfile
LarkLinear06.table EE00 512 -binaryfile LarkMuLaw.table F000 2048 -binaryfile
LarkSilence.table F800 512 -binaryfile LossTable00.table FA00 256 -binaryfile
LossTable05.table FB00 256 -binaryfile LossTable10.table FC00 256 -binaryfile
LossTable15.table FD00 256 -binaryfile LossTable20.table FE00 256
The "fixup" clauses allow arbitrary data at any address. The fixups place an 8088
long jump instruction to E000 at address FFF0, the system restart address.
The mb file is then run through the PROM blower under control of the
command file [Indigo]<Voice>ETP>MakeLarkSlaveMonitor.cm, which accounts for
the various bit reversals etc.
*start*
09538 00024 US
Date: 15 May 1982 9:18 pm PDT (Saturday)
From: Stewart.PA
Subject: Bringing up the Slave CPU
To: VoiceProject↑.pa
More war stories:
I constructed an EPROM for the Lark slave cpu and plugged in all the parts.
The slave CPU can be reset and unreset under control of the main cpu by
changing a parallel port bit. In addition, the DMA controller must be set up in
cascade mode to allow the slave CPU access to shared memory.
I used the main CPU monitor program to unreset the slave to see what would
happen. One would expect the slave program to go into an extende wait state
waiting for access to shared memory. Instead, it took off running and the
pattern of IO references (to the audio shift registers) and reads/writes seemed
reasonable. I eventually determined that the bipolar PROM which generates
control signals for the slave had its output data bit reversed. The organization of
the output bits was such that it behaved reasonably. When I made the PROM, I
had to guess at the bit reversals because the prom blowing program doesn't know
about the TI 18S030 PROM. Reversing the bits was a matter of changing the
prom command file. The program, now hung, as expected.
I leafed through the Intel components book and wrote down a sequence of main
cpu monitor commands that would put the DMA chip into cascade mode on
channel 0. On trying the sequence several times, the slave program seemed to
run briefly and then die.
I unplugged all components that connected the slave and main systems, bus
transceivers, address drives, control signals, and bus grant logic, and built a
small kludge to loop back bus request to bus grant. On starting the slave again,
it ran fine. I looked more closely at the IO reference patterns and discovered
that the slave program was using the wrong IO addresses for the input and
output shift registers. In addition, the organization of the slave program was
such that it referenced the input shift register on the second instruction after
every wakeup. Since wakeup happens at the beginning of TSN (TimeSlotN), the
program would read the shift register while it was shifting. I made a new slave
monitor EPROM. The slave still ran fine with the loopback.
I left most of the components unplugged, but connected the bus grant back
through the dma chip. Ran for 1/2 to 1 second and quit. I tried it several times
and it failed in several ways (or seemed to). Once the main CPU had gone
not-ready, apparently by trying to reference a nonexistant location inside the
Ethernet chip. Several times it appeared that the main system monitor had
rebooted itself, resetting the slave cpu in the process. Sometimes the main cpu
console would start printing garbage.
This should have worked, because the Ethernet chip used cascade mode in the
dma chip sucessfully. There were several far fetched possibilities: the way the
slave control lines were disabled was to bend up and pull up a select pin on the
control line mux. This resulted in the selection of the DMA chip's memory
control lines when the slave supposedly had control. I noticed that the DMA
control lines were not pulled up, in cascade mode they would float to tristate
OFF. It seemed conceivable that they could store enough charge to glitch the
system control lines briefly, so I added pullups - no change.
I tried slowing down the main system clock from 23.53 MHz to 15 MHz, the main
system refused to work at all. Since refresh timing is controlled by counting the
system clock, this made sense, memory was going away due to too seldom
refresh.
A scary possibility was that the 8237 dma chip was touchy about getting a
request signal that was synchronized to the system clock - perhaps the request
signal happened to lie in a window of synchronizer vulnerability and would fail
after a second or so.
I wondered about leaving the address bus floating on the main cpu, so I plugged
back in all the components except the read and write control signals - no change.
Some additional thought and rechecking of first principles revealed that the
sequence of monitor commands I was using to set up the DMA chip were in
error. The cascade mode directive supposedly sent to the mode register was in
fact going to the chip software reset register. I fixed the command sequence and
the slave cpu ran without hanging. The presumed effect of resetting the DMA
chip instead of putting it into cascase mode was to clear all the address and word
counters and to put it into a mode where it would actually do memory writes.
Since the control signals were connected to the DMA chip, the writes took place.
The slace processor program made 10 requests per audio sample, or 80,000 requests
per second. Starting with the address register = 0, the dma chip would quickly
clobber the memory refress interrupt vector and 64K/80K second later would
write over the monitors stack and data area. Either effect could explain the
"working for 1 second" observation.
I should note that the slave processor does not depend on any data read from
shared memory for control of its program, but that pointers read from shared
memory are used as addresses sometimes. All 1's or all 0's would generate
addresses referencing the slave EPROM, which would have no effect on the
pattern of shared references.
I connected the slave control signals back to the main system and tried again.
The slave CPU was seemingly referencing the correct addresses in shared
memory, but with some odd flaws. First, the ring buffers were one byte too
long. That was due to a > instead of >= in the end test (fencepost error).
Second, all writes seemed to be mostly 1's. I found that the data transceiver
between the shared memory data bus and the slave cpu processor bus was
backwards: it would point towards the slave during a write and towards the
memory during a read. The direction control signal was SlaveRd'. Since SlaveRd
was not available, I connected the transceiver to SlaveWr', which would reverse
matters.
Now more sensible data seemed to appear in main memory, but the slave
processor was stepping on OutGain, a supposedly read-only location, and only
the low order byte of the ring buffer pointer was right. I filled regions of
memory with distinctive values and established that one byte transfers were
working, but that only the low order byte of word transfers were working. Even
locations got clobbered, but odd locations were never changed. I realized that
SlaveWr' was a bad choice for the transceiver control signal: The 8088 has a
multiplexed address/data bus. Addresses are generated by the CPU and latched
into external registers by a signal called ALE. Thereafter, the read or write
signal activates to do a data transfer. Using SlaveWr' for the transceiver left the
transceiver normally pointed towards the slave CPU, turning it around only for
the duration of writes. The address for byte transfers and the address for the
first byte of word transfers escaped unscathed because the transceiver enable
signal (bus grant) did not arrive until after the address was decoded anyway.
However, the slave does not release the main bus between the cycles of a word
transfer, so the data transceiver stepped on the low 8 bits of the address for odd
bytes. This also was a good explanation for the clobbering of the read-only
location. I found an inverter and used SlaveRd for transceiver control.
Now the shared memory seemed to be in shape, but there was no sound. Silence
detection didn't work, garbage was showing up in the input buffer, writing large
numbers into the output buffers produced no clicks, etc. Looking first at the
hardware, I found the input shift register shifting the wrong direction. This was
easy to fix, as it is a bidirectional register. I moved the input to the other end,
etc. Still garbage in the input buffer.
I realized that all the word tables in the slave EPROM were byte-reversed, since
I had generated them with a Cedar program. I modified the generating program
to reverse them. That could explain output not working as well as silence
detection. I also discovered that the silence detection lookup table was using a
byte index, so I added a shift left instruction to correctly compute the word table
index. In addition, the input gain computation used the 8088 XLAT instruction,
and the table base was in the wrong register. I also found that the overflow test
in conference call merging was off by a bit, which would lead to wraparound on
overflow.
I made a new Slave EPROM and tried again. By this time, I had also written
AudEcho, a program for the main CPU that permitted changing around the table
pointers and echoing the audio in more convenient ways that using the main
cpu monitor program. Silence detection was now doing something, the input
buffer seemed to work, and output still did not work. I stared at the program
some more and discovered that the high half of the register used for silence table
indexing was uninitialized. Cost one instruction. Also, the U255 to linear
conversions were using byte indices into the word table, cost 3 instructions (shift
left). Before making the new EPROM I also noticed that the shift left for
conferee 1 would pollute the left half of the register that conferee 2 and 3 also
needed, cost 2 more instructions. The marginal cost of a conferee is five
instructions including two shared memory references.
After these changes, the slave CPU audio seems to work fine, at l;east for local
echoing.
*start*
02224 00024 US
Date: 15 May 1982 9:31 pm PDT (Saturday)
From: Stewart.PA
Subject: Lark Interrupts
To: VoiceProject↑.pa
Reply-To: Stewart
Lark (ETT) hardware interrupts now work. I modified the program Test8259.c to
check out the interrupt controller in the new system. I was able to check out
the program by generating software interrupts, but when I enabled interrupts
after setting up the 8259, the system hung right away. I slowed down the timer
channel which was generatig interrupts to toggle every 2 seconds and was able
to turn on interrupts while the signal was low then turn them off again before it
went high without failure. This meant that the trouble was in the actual
generation of an interrupt. I crashed it again and inspected the machine state.
It was stuck in Not-Ready, as though an IO reference had been made to the
Ethernet chip. It seemed as though that might happen, since the IO address
decoder might have been enabled and the address bus might have had an
Ethernet like address, so I ran the program on the Dorado board (ETP) system to
see what interrupt acknowledge cycles looked like. The IO/Memory control line
was in the IO state, (which would enable the IO address decoder), and neither
the read nor the write control lines were active. IntA' IS active for an interrupt
acknowledge cycle.
A bad CPU or Interrupt chip were possibilites, but every other test indicated that
they worked fine. I determined that in the hung system the Ethernet chip chip
was NOT selected, so that was out. I noticed/remembered that because some of
the IO devices are not prepared to keep up with the 8 MHz 8088, we added a
single wait state for all IO references not directed to the Ethernet chip (The
Ethernet chip handles wait states by itself.). The wait states were started by the
occurrance of an IO reference and stopped by the arrival of read or write,
delayed one clock by a flipflop. Since interrupt acknowledge cycles are like IO
cycles, the wait states were begun, but since the cpu does not assert read ro
write, the system just sat there. The fix was to use a three input OR gate, so
that any of read, write, or interrupt acknowledge would cause the system to start
up again.
*start*
06303 00024 US
Date: 15 May 1982 10:32 pm PDT (Saturday)
From: Stewart.PA
Subject: Lark main CPU
To: VoiceProject↑.pa
cc: Stewart
This is out of order, but documents what I remember of debugging the main
memory system of Lark.
After writing the main CPU monitor, I was able to essentially debug the monitor
on the old (ETP) Lark processor by making a few modificaitons to allow testing
of refresh and non-maskable interrupt.
After writing a program to convert the main CPU monitor object file into an mb
file (ObjToMb.df), I made the 2764 EPROM using Tom Chang's new version of
PNEW. It consistantly reported improper verify on the first bit of the first word,
but since it was a weekend, I decided PNEW was in error and pressed on. Since
the prom machinery gives very little assurance that the bits aren't upside down
or backwards in the PROM, I built a small proto-board jig that allowed me to
assert small numbers of addresses and observe the data with a voltmeter. I
determined that both the EPROM and the main CPU control PROM were correct
(verifying, incidently, that PNEW erroneously reported the error in the EPROM).
I plugged in a minimum complement of parts into the Lark, to avoid complicating
matters. The monitor did not boot. Rather than rig up a repetitive system reset,
to try debugging with the scope, I dug out the ancient HP logic analyzer
(couldn't find the new HP or the Biomation). Half of the probes didn't work,
and 6 were too few. Ed Taft found me a Tek plugin logic analyzer but I
couldn't make it do anything. Ed helped, and by unplugging the display
controller advanced features box, we got it to displayt something reasonable. I
hooked up the analyzer to the address bus (there were not enough bits to handle
the data bus too.) and set it up to trace execution of the program. I had seen
bursts of control signals, so I felt that the busses themselves were working.
Occasionally, the CPU would even get into loops and run consistantly, although
not sensibly.
It proved to be very difficult to get sensible triggers. Following reset, the CPU
seemed to execute off the end of memory and back around. Once in a while, it
started executing at the beginning of the EPROM where the monitor was and
proceeded in reasonable ways. I followed the execution trace for quite a while,
through several subroutine calls, and established that main memory wasn't
working. Subroutine returns didn't work and a POP of an argument used as a
pointer made the reference to a wierd place (with many 1's). I had unplugged
the memory bus pullups in order to get the dip clip on the EPROM so even if
the memory chips weren't working I didn't expect all 1's. I looked at the memory
control signals for a liong time, but didn't notice anything outrageous. The most
alarming note was that the column addresses did not seem to meet the setup times
before CAS. It's hard to be sure because we don't have the data sheet for the
chips we are using. I assumed they were much like other 64K rams. The poor
timing was a result of using the wrong delay line. The ones we have are 100
nanosecond ten tap devices (taps every 10 ns), but the board is wired for 100
nanosecond 5 tap devices, which are cheaper. I had thought that enough of the
taps were in similar places so that it would work. The problem appeared only for
reads because there is a tap switching multiplexor that delays CAS for writes to
allow other devices more time to present memory data. I bent up the mux select
pin and grounded it so that the later timing is always used. This would not
matter unless we were using a 3 MHz Ethernet chip, which needs very fast
reads. By that time (whenever) we'll have the right delay lines. No dice. All
the memory chip pins seemed to have the correct signals, so I began to worry
about not having the data sheet. I considered plugging in TI 64 K rams from the
Dorado stock, but they are possibly too slow even for the main CPU of the Lark.
I went back to the Intel documentation and learned that on power up, the 8088
begins execution at address FFFF0 "where there will normally be a long jump to
the actual program". I had read that as "put the address of the code at FFFF0". I
made a new EPROM with that fix, causing reliable reset. I also added a kludge
so that if the ethernet host ID switches were set to an even value, the monitor
would go into a tight loop making main memory reads and writes. This was to
no avail, the main memory chips acted like they weren't even being selected.
Finally I checked the wiring pin for pin against the TI data sheet and
establ;ished (horrors) that power and ground were reversed on all the memories!
It seems that 64K rams have ground on pin 16 and +5 on pin 8, which is exactly
backwards from TTL standards. Since the data sheet is marked "Vdd" and "Vss"
rather than "Vcc" and "GND", I didn't give it a thought while making the sil
dictionary entries.
I build a kludge out of 16 dip sockets that allowed me to rewire the power, and
plugged in a new set of memory chips. The old ones MAY not be blown, but I
haven't tried them.
The monitor booted but died. It appeared that refresh didn't work and that the
timer chip wan't producing the refresh signal. I found that power wasn't getting
to the timer chip (having learned from the memory, I checked that fairly early).
There was a melted wire going to the power pin. I must have dropped a scope
ground clip there. I put a temporary power wire in and the monitor booted and
ran. This also tested the RS-232 chip.
The Ethernet chip did not work. I found that the Ethernet clocks were not
running because the clock divider chip did not seem to be getting ground. I
discovered that the Sil dictionaries listed the LS393 as a 16 pin chip instead of a
14 pin chip. This resulted in miswired ground and miswired half of the signal
pins as well. I built a 14 to 16 pin adapter socket to fix it. Still no Ethernet. As
the DMA chip is necessary for the Ethernet, I tried reading and writing DMA
controller registers, but it was very flakey. I discovered that the DMA was
wired to SysClock, at 7.843 MHz, well above the chip design limit of 5 Mhz. I
rewired to to PClock, at just below 4 MHz and the DMA controller started to
work, as did the Ethernet.
*start*
08380 00024 US
Date: 15 May 1982 11:19 pm PDT (Saturday)
From: Stewart.PA
Subject: Lark DMA interference
To: VoiceProject↑.pa
The program TestWorld is intended to test audio and encryption and Ethernet all
at once by grabbing voice, encrypting it, ethernet-transmitting it to onesself,
decrypting, and playing out again.
Severo and I worked on this one together.
After a sizeable number of program bugs were fixed, audio local loopback works
fine with or without encryption. When the ethernet is enabled (in place of a
local BLT) one is still able to hear one's voice, but there is a "click" every time
the Ethernet is active. Apparently, the ethernet DMA activity interferes with
the slave CPU's access to shared memory sufficiently to disrupt the audio
(although the Ethernet still works fine.)
The slave cpu has essentially no buffering, it wakes up once per voice sample,
every 125 microseconds, and must complete processing of each sample before the
next is ready. In the absense of ethernet activity, the processing takes about 85
microseconds, plus a little bit more once per voice packet as the silence detection
value is stored in shared memory for the use of the main cpu.
When the Ethernet was active, the scope patterns became too scrambled to puzzle
out, but the general impression was that the slave cpu was taking too long.
By slowing down the timer chip's generation of the audio clocks to one sample
every 300 microseconds, the patterns were simplified (made non overlapping).
Within the period of Ethernet activity, the slave cpu running time was extended
to at most about 180 microseconds, clearly too long.
For a particular voice sample, the slave cpu makes 10 distinct references to
shared memory, some reads and some writes, some byte references and some word
references. Without the ethernet, each one appears to take about 3 microseconds,
most of which is arbitration delay.
The slave cpu is the highest priority dma device. Next is the Ethernet, and last
is the encryption. The order is sensible since the slave cpu has real-time
requirements but no buffering, the Ethernet has real-time requirements but has
16 bytes of buffering in each direction, and the encryption chip has not
particular real-time requirements.
Since the slave running time was extended from 85 to 180 microseconds, the
marginal cost of an (intrfered with) reference would seem to be 10 microseconds,
so that without other changes, we could afford four to six of them. (more than
(125-85)/10 since a reduced number would also reduce the 85 to something
smaller. Obvious technique number one is to simplify the slave processor
program. We'll return to that later.
In normal operation, the Ethernet chip runs at 1.47 Mbps, so it needs a byte
transfer every 5.44 microseconds. In this program, the Ethernet chip transmits to
itself, (full duplex) doubling the requirement to one byte every 2.7
microseconds. This might seem to be an odd circumstance, but it could easily
occur in normal operation. If the Ethernet chip ever transmits a broadcast packet
it will be received. Further, the only way to handle multicast for a conference
call is for each conferee to use the same address. Tjhus each party will receive
(and have to discard) his own audio packets. it is conceivable that the Ethernet
driver could be written "half duplex", disabling the receiver during transmission,
but this would seem to lead to a long transmit to receive turnaround time. (The
Ethernet chip has problems such as: enabling the receiver while the transmitter
is running aborts the transmission.)
General solutions:
Reduce the number of slave references per loop, either by better coding/clever
tricks or by removing slave cpu program features.
Remove the realtime requirements from the slave program by adding audio
buffering somewhere. The Ethernet is not used enough to bring the average
loop running time above 125 microseconds...
Remove the dma contention by some form of DMA burst accessing, either by the
slave or by the Ethernet. It is not that the number of dma cycles is so high, it
is just that the bus arbitration is very expensive.
Comments:
Adding audio buffering could be done, with some complesity, by using
something like the Fairchild serial FIFO chip to hold perhaps 16 audio samples (2
milliseconds) in each direction. This would increase end to end delay by 4
milliseconds. The slave program would have to keep track of the fifo levels
somehow, which could take still more logic. This has not been completely
worked out.
Severo and I dreamed up a scheme taking one or two more chips on the main
Lark board that would use the timer chip to generate an Ethernet-DMA-Holdoff
signal for the first so-many microseconds of each voice sample time. The
Ethernet would run off its buffering for this period, leaving the slave cpu free
access to the bus. The slave program would be reorganized to bunch the
references as much as possible to the front. After the end of the holdoff signal,
the Ethernet chip would generate burst DMA references to refill its buffers.
Since burst references require fewer arbitrations than single references, this
would actually take less bus time.
It seems difficult to bunch the slave references into bursts. The slave cpu is just
executing instructions. Some of the data references are to regions of its address
space which reference the shared memory. These automatically generate bus
requests and put the slave to sleep until they are granted. Since the 8088 has an
instruction prefetch queue it is possible that more than one instruction's shared
memory reference might occur together if the second instruction had been
prefetched. However, the queue is very short and the data reference instructions
which contain addresses are fairly long.
There are several possibilities for reducing the number of slave references.
Here are the present references, whether read or write, and whether byte or
word. Word references take about 500 nanoseconds longer than byte references,
which is practically free, considering the 2.5 microsecond arbitration times.
Number Type Size Reason
---------------------------------------------
1 write word write buffer pointer to shared mem.
2 read word pick up pointer to output gain table
3 read byte read conferee 1 voice sample
4 write byte zero sample location just read
5 read byte read conferee 2 voice sample
6 write byte zero sample location just read
7 read byte read conferee 3 voice sample
8 write byte zero sample location just read
9 read word pick up pointer to input gain table
10 write byte store incoming voice sample
once per packet:
11 write word store per packet silence indication
Notes:
Ref 1, the buffer pointer can be stored less often, perhaps every 5 or 10 samples.
The main cpu uses it to determine where packet boundaries are and to find the
current end of buffer for restarting after silence. It is even possible to eliminate
it and make the main cpu use an independent clock such as the timer chip to
keep track of the slave cpu. The clocks should track exactly, but it would be
fairly easy for the main cpu to occasionally check for phase synchronism.
Ref 2, the output gain, will not change more frequently than once per packet, so
it can certainly be read less often.
Ref 9, the input gain, is similar. The phasing of input gain changes must be
done carefully though, since input gain at "this" end of the call is used to
control echo at the far end.
It might be possible to eliminate refs 4, 6, and 8 altogether, but then the main
cpu would have to SetBlock zero the buffers if packets did not arrive. This
could be done by DMA by having a block of pre-encrypted zeros lying around.
More palatable is to use word references to do the zeroing every other sample
time. That would reduce the peak reference rate by 1 and the average by 1.5.
(It would be nicer if the number of outgoing voice streams were even!)
It might be possible to use word references for the voice data, but the slave
program is very short on registers and the slave cpu has no local ram. Adding
local ram is a possibility. There is room on the Lark board for 1k bytes or so.
It might also be possible to add the read-modify-write logic that was discussed
for the ETR and ETS designs and thus to the zeroing automatically.
*start*
00293 00024 US
Date: 11 May 1982 11:38 am PDT (Tuesday)
From: RWeaver.PA
Subject: [Indigo]<Voice>
To: Stewart
cc: Swinehart, RWeaver, Taft
A new access control group (31) has been created for [Indigo]<Voice>. It uses
the established DL VoiceProject↑.pa per your request.
Ron...
*start*
00835 00024 US
Date: 12-May-82 10:08:43 PDT (Wednesday)
From: Dalal.PA
Subject: if you have a phone answering machine, read on ...
To: AllPA↑
Reply-To: Verplank.PA, Dalal.PA
Sorry to bother those of you who don't have a phone answering machine.
Bill Verplank, I, and others in SDD are looking at the problem of multi-media documents, in particular those that have voice annotations or are "voice messages." We want to know what the length of typical voice messages might be, and so hoped that those of you with phone answering machines would participate in a little experiment.
We would like you to tell us how many messages you receive everyday for a week, and a distribution of the length of the messagse. We would also like to know if your answering machine has a maximum length for a message.
Thanks,
/Yogen Dalal
*start*
00784 00024 US
Date: 12 May 1982 2:15 pm PDT (Wednesday)
From: ornstein.PA
Subject: Re: if you have a phone answering machine, read on ...
In-reply-to: Dalal's message of 12-May-82 10:08:43 PDT (Wednesday)
To: Verplank, Dalal
cc: ornstein, VoiceProject↑
Reply-To: ornstein
I think you will get some misleading answers from your survey.
Most answering machines today have hostile aspects, many of which would be
improved or eliminated in the sorts of systems we're envisioning with the
Etherphone. In fact, that's the main point of our explorations. A typical
phone-mate message today might be simply a name, topic, and phone number -
get off the phone as quickly as possible. If voice message systems become more
benign, that's likely to change - dramatically.
Severo
*start*
00631 00024 US
Date: 12 May 1982 4:57 pm PDT (Wednesday)
From: ornstein.PA
Subject: Chat with Butler
To: VoiceProject↑
Reply-To: ornstein
I have scheduled us for a chat with Butler next Tuesday at 1:30 PM. I want to
bring him up to date on where we stand and on our plans (particularly
concerning Lark software - use of RPC, etc.) and generally let him ask questions
and try to spot potential troubles. The conclusion is that this will be more
helpful than gathering the entire Vigilante group.
Larry and Dan and I need to be there. It would be useful but not necessary for
Susan and John to be there.
Cheers,
Severo