Re: Android Headset specification

On Mon, Jan 21, 2019 at 05:41:09PM +0100, Mia Magnusson wrote:
>> It turns out that the Android signaling employs a resistor divider
>> with the phantom power that is fed to the mono microphone. The
>> primary button would directly short the microphone line to ground.
>> Other buttons would use resistors. In any case, it would seem that
>> any audio signal from the microphone needs to be muted while these
>> buttons are being pressed (to get rid of 'pop' sounds when the DC
>> level abruptly changes).
>
>I assume that signal processing in the Android device takes care of
>removing DC pop sounds.
>
>Is there any use case of reading CASS WRITE while CASS MOTOR is 
>inactive? I assume not. That would make it easy, just ground the 
>microphone pin if MOTOR isn't on.

I cannot think of a legitimate use case.

Side note: If I remember correctly, on the Vic-20, CASS WRITE is shared 
with the keyboard matrix. The impatient operator who is playing with the 
keyboard or joystick while a long SAVE operation is in progress would be 
punished with a corrupted tape, to be detected much later when trying to 
read the data. (It could have been CASS READ as well, but CASS WRITE is 
more evil.)

>> One thing that could be done is to tie the microphone line to ground
>> (optionally via a resistor) when the CASS MOTOR signal is not active,
>> and otherwise allow the DC level on the microphone line to remain.
>>
>> So, it would be like this:
>>
>> tip (left audio): CASS READ
>> ring (right audio): CASS SENSE
>> 2nd ring: ground
>> sleeve: CASS MOTOR and CASS WRITE
>>
>> For CASS SENSE, I think that the easiest might be to use a bridge
>> rectifier and a bandpass filter. That is, if a specific 'pilot tone'
>> is present, activate the line. The 'datasette app' would generate
>> this pilot tone whenever the emulated PLAY or RECORD+PLAY buttons are
>> pressed.
>
>Is there even any need for a band pass filter?

Probably not. The C= side should not be interested in transitions on 
CASS SENSE, so it should not hurt to get extra pulses. On the C64, it is 
only checked whenever the transfer of a block has completed (or timed 
out).

A challenge would be to come up with a fast custom protocol for loading 
data. Maybe CASS WRITE or CASS MOTOR could be used as handshake signals, 
to have some flow control for signals coming from CASS READ. The 
transfer speed could be somewhat higher than on the audio CDs that were 
available, because the D/A signal path is simpler than on compact disc 
players. But I don't think that it could be faster than the 38,400bps 
that c2nload achieves with its custom protocol.

Again, I think that something wireless based on Bluetooth or WLAN 
(ESP8266?) would be a better option than a 3.5mm TRRS adapter. And IEC 
could be nicer than the tape port. The main advantage of the tape 
connector is that it is the same on all 8-bit Commodore machines. Only 
the B series is lacking tape routines in the ROM.

	Marko