Re: Android Headset specification

Den Wed, 23 Jan 2019 20:53:46 +0200 skrev Marko Mäkelä
<msmakela@gmail.com>:
> On Mon, Jan 21, 2019 at 05:41:09PM +0100, Mia Magnusson wrote:
> >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.)

Ouch. Had a look, it's COL3 / PB3 which is also used as CASS_WRITE.
CASS_READ is connected to CA1 and doesn't share that pin with anything
else. CASS_SWITCH is shared with a user port pin, which shouldn't cause
much problems. CASS_MOTOR is connected to CA2 on the "non-keyboard" CIA.

The RUN/STOP key seems to be on COL 3. If the Kernal would do things
the best way possible, the keyboard ports would be set up in a way that
makes it impossible to disturb tape writes. This assumes that the
pullup on inputs of the VIA is low enough to not affect the signal to
the datasette even if many keys are pressed simultaneously.

> >> 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).

My idea is that a bridge rectifier would be good enough. I would be
very surprised if it's not possible to send a sine/square wave signal
or just silence on one output channel while the other sends "datasette"
sounds.

> 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 CASS_MOTOR signal is probably rather slow as compared to the
others, due to that it is amplified in a circuit only intended for the
super slow settle time of the mechanical motor. It might be rather fast
but that's probably something that has to be tested on every single
revision of every single Commodore 8-bit computer before we can really
count on that.

But if the goal is to cheaply read as fast as possible from a mobile
phone, then the bandpass filter or something similar comes into play.
Some circuit that just holds CASS_SENSE active if a low frequency
signal is detected from the mobile phone, holds it inactive if no
signal is detected, but any signal with a higher frequency is just
"1-bit A/D converted" the same way as for CASS_READ (but of course from
the other channel on the mobile phone). That way it would be possible
to double the transfer rate as it would be a two bit parallell
transfer. Not sure if it would be reasonable simple to write the loader
for the Commodore though.

> 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.

I would be (happily) surprised if this is true on any mobile phone. The
only digital devices I'd expect being able to send audio at a higher
frequency would be those that are specified to produce higher
frequencies, like 24/96 sound cards, DVD Audio players, SACD players
and similar. (Of course there are also analogue stuff that can produce
higher frequencies, for example in the 70's there were vinyl records
with a FM signal with a carrier frequency at about (IIRC) 30kHz which
contained the front-rear difference signal for true four channel audio.
Good reel-to-reel players running at the higher speeds are surely also
able to reproduce signals quite a bit above 20kHz.

For audio CD players, there are more or less three different ways the
signal can be processed. One can nowdays be ignored, and that is the
analogue low pass filter cutting at about 20kHz, giving a terrible
phase shift. The other which is what most CDs probably do is some kind
of digital filter, which causes ringing on the signal. I'd assume that
mobile phones do that too. The third could also probably be ignored -
the "legato link" thing that Pioneer had in some CD players, which
simply is a low pass filter at a higher frequency.

Btw, I believe that the reason that "legato link" is said to give a
better sound is due to what happens in the speakers and especially the
amplifier with the digitally low pass filtered signal from any common
CD player, with it's ringning. I think that the ringing might trigger
TIM or other kinds of distortion more easy than the signal from a
"legato link" player would do.

> But I don't think that it could be faster than the 38,400bps that
> c2nload achieves with its custom protocol.

What limits it to 38400? Is that due to that there being no selectable
frequency between 38400 and 115200 on a PC, the Commodore is too slow
for 115200 and the C2N232 is intended to work with the standard speeds
of a PC? If so it might be a good idea to try using an Amiga or
anything else which can do more variable baud rates?

> 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.

Some kind of hardware that has enough pins to do either the serial
port or IEEE-488 (or the subset that Commodore uses, iirc two or three
signals aren't needed) would be nice.

But if it anyway should have a microprocessor and connect to the
cassette port, it might be able to use some of the pins in some
unusual way. We have already seen that CASS_WRITE is connected to a
standard port of one of the VIAs in a VIC 20, so that could be used
both as an input and an output. The same is true for CASS_SENSE on the
VIC 20. Any first-stage loader should be able to detect which
Commodore model it's running on and adapt to the hardware capabilities. 



-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.