On Fri, Jan 18, 2019 at 01:07:43PM +0000, smf wrote: >On 18/01/2019 07:15, Marko Mäkelä wrote: >>It could be somewhat of a challenge to implement bidirectional >>transfer. If the interface were to play nice (and emulate the loading >>of tapes), then it would have to connect not only CASS READ but also >>CASS SENSE and CASS MOTOR. With that you would already have exhausted >>the 2 outputs and 1 input that are available in a TRRS connector >>(stereo headphones and microphone). Something magical would be needed >>to additionally connect CASS WRITE. > >You could do it like the hands free kits where the answer buttons use >in band signalling. > >So something like hookup cass write to the mic input when the motor is >running & have some signal level that is used to tell the device that >the motor is stopped. I dug up the relevant information: https://source.android.com/devices/accessories/headset/jack-headset-spec https://source.android.com/devices/accessories/headset/plug-headset-spec I learned that the two wiring standards for 3.5mm TRRS connectors are not tied to specific manufacturers but to time. The OMTP pinout order (tip,ring,ring,sleeve: left,right,microphone,ground) was used by Nokia and also by my 2011 SonyEricsson Xperia Active. My current Samsung Galaxy J5 follows the CTIA or AHJ wiring, where the microphone and ground are swapped. 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). 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. >You may be able to do cass sense in a similar way, rather than >dedicating one ear to cass read and the other to cass sense. I do not think that there is any digital signaling in that direction. Furthermore, given that the 3.5" plug seems to be facing extinction on phones, developing such a product could be a dead end. It might be easier to develop a Bluetooth device that would be powered from the cassette port. Some system-on-chip like this would have more than enough power for the task (also for emulating a disk drive): https://www.nordicsemi.com/Products/Low-power-short-range-wireless/nRF52832 I might prefer a little more powerful system-on-chip that runs GNU/Linux and could be used as a 'modern desktop machine' next to the 8-bit Commodore (or as a gateway to an even more powerful machine). It is a pity that the Raspberry Pi does not have any I/O processor; it could be hard to get stable timing for doing bit-banging over its GPIO pins. MarkoReceived on 2019-01-20 13:00:03
Archive generated by hypermail 2.2.0.