*start*
00563 00024 US 
Date: 7 May 1981 5:53 pm PDT (Thursday)
From: Pasco.PA
Subject: SPAPS Question
To: Lyon
cc: Pasco

Not clear from SPAPS data sheet:  When should "Extend" control line go high?
I guess it should be true a setup time before the clock edge on which we want
the first copy (i.e. second instance) of the sign bit to appear on the "RightOut"
line.  In other words the same clock edge which caused the original sign bit to
appear on the "RightOut" line should also cause my control logic to bring
"Extend" high.  Please confirm.

	Thanks,
	Rich

*start*
00185 00024 US 
Date: 8 May 1981 10:29 am PDT (Friday)
From: Lyon.PA
Subject: Re: SPAPS Question
In-reply-to: Your message of 7 May 1981 5:53 pm PDT (Thursday)
To: Pasco

 Yes

*start*
01236 00024 US 
From: Pasco.pa
Date: 22-Jun-81 19:24:53 PDT
Subject: Enabled flip-flops
To: Lyon
cc: Pasco

Dick,

I hope that since you work with multiplexed signals a lot, you've already thought of a better way to do this in TTL.  I need many sections of "enabled D flip-flop", with separate enables.  [That is, I need many instances of a box with two inputs, and one output which represents the value (1 or 0) of one input on the last clock when the other input was true.]  This should be super-easy to implement, but I can't think of a way to do it in less than one TTL package per section.

True, enabled D flip-flops do exist, but they have multiple flip-flops per package sharing a common enable line.  My design now uses 1/6 of an LS378 for each instance, and wastes the other five sections.

Another approach is to use a regular D flip-flop and a multiplexer to either steer the old state back or load the new data.  But multiplexer chips per se have a common "select" line for all sections...

Or I could build my own multiplexer, using 3/4 of an LS00 gate pkg.  But by the time I add in the 1/6 pkg. for the flip-flop, I'm back up to one package again, still no better than the LS378.

Any ideas?  Thanks.

	- Rich


*start*
00375 00024 US 
Date: 23 June 1981 8:44 am PDT (Tuesday)
From: Lyon.PA
Subject: Re: Enabled flip-flops
In-reply-to: Your message of 22-Jun-81 19:24:53 PDT
To: Pasco
cc: Lyon

In John D.'s synthesizer we went with half a pack of MUX and half a pack of
DFF for each such function, for sign extension.  You could use fewer packs if
you used ROMs, but why bother?
	Dick

*start*
01284 00024 US 
Date: 23 June 1981 3:37 pm PDT (Tuesday)
From: Pasco.PA
Subject: Parrot Changes
To: Stewart
cc: Cherry, Lyon, Pasco

[Ivy]<Pasco>Parrot>Parrot.Press has been modified to reflect changes in
implementation of the "Frame" command.

There is now an additional number-controlled oscillator (NCO) available to
time fixed-length frames.  It is an overflowing-accumulator, like the Pitch NCO.
Its frequency number comes directly from the input buffer (unlike Pitch, whose
frequency number passes through the Frame Register and Interpolator).

Action on the "Frame" command is now deferred until a low-to-high transition
in the MSB in either the Frame NCO or the Pitch NCO, depending on SyncMode,
a new bit set by the "Frame" command.  The host must keep bus data stable until
Parrot's "Acknowledge" signal indicates completion of the "Frame" command.

The MSBs from both NCOs are available to the host on dedicated wires,
providing square waves at the Pitch frequency and at the Frame rate.

A potential bug exists if Parrot powers-up with SyncMode=PitchSynchronous,
and PitchFrequency=0.  The Frame command is deferred forever, hence neither
PitchFrequency nor SyncMode can be changed.  Suggestions for a clean, elegant
fix to this possibility are welcome.

	- Rich