Hardware Project - Not even sure if this is possible!!

[CraigsBar]

Whilst playing around with a CPC Cassette lead and Breaking Baud (loaded from the WAV of the CDT played back on my Phone) I started to think....


We have had many suggested that an MP3 player was an ideal replacement for the old fashioned Tape recorder and this does seem like a great idea. However this got me thinking... Would it be possible to create a cable that used the REMote connections of the CPC to send Start and Stop signals to the 30 pin connector of an iPod (classic or touch pre lightning connector).


I am pretty sure the connections on the 30 pin connector should allow for this, after all the standard dock passes play, pause, stop etc from an apple infrared remote to the ipod this way.


Probably either A: Impractical or B: overly expensive but it would be very slick if it could me made to work


Regards


Craig

[pelrun]

I'm fiddling with this idea, but for android. In any case, you don't want to use the dock connector, but instead the headset jack - the play/pause button on the headset controls is far easier to interface to than the 30-pin connector, and it's compatible with more devices.


Only trick is that the phone will want discrete presses of the pause button, but the cpc 'holds down' the button. To get around that either requires software support, or extra hardware. I was thinking of going the software route, but if I come up with a simple hardware method I'll probably go for that.

[gerald]

I do not own any of these spyware  , but doesn't these players fade the sound when muting on/off ? This may corrupt part of the leading tone or even start playing it when it should stop.
Also, how will the player react to fast on/off/on switching as you may found in some loaders, where this period is just a single audible click on the control relay ?

[pelrun]

Use a player that doesn't have such behaviour?


Also remember that the original tape player doesn't have instantaneous on-off behaviour; there's always a short period where the motor is slowing down/speeding up. Therefore, there *will* be pauses in the audio data where the computer would be stopping the tape, or you'd always lose bits.

[ralferoo]

Yes, the tape input behaves quite oddly if you turn on and off the motor very rapidly! The CPC itself (or at least on the 464) ignores tape signals if the motor is off and you get a buzzing noise from the relay from operating it so quickly (and probably a shortening of its life too)...


I discovered this fact when adding a reset button to the loader - to scan the keyboard, you need to keep switching between read and write mode on port A and the only way of changing the direction of the signals also resets the output data of port C to 0 and so turns off the motor. So, you can tell it in advance which keyboard row to scan, then turn on the motor and then keep reading only that row (so, just scan for ESC or scan one joystick only) during loading.


But sadly, this means that whilst you could have a game whilst loading, it'd have to be without sound, because sound requires you to write to the AY chip and hence you have to change the direction and so the tape motor will be instantaneously turned off...


At one point, I'd planned to doing a streaming-from-tape canabalt style game until I realised it was impossible for this reason...


Anyway, what I'm trying to say is that the motor is designed to stay either on or off for a reasonable period. If your program mutes the tape input whilst the motor state is off or changing, you shouldn't get any worse results than with a real tape, and nobody would really put data deliberately immediately after a motor on because it's most likely it wouldn't be read properly anyway, as the tape takes a short while to get up to speed and that is highly dependant on the deck. (Actually, the pilot tone could start during the motor on/off phase, as long as there's enough of it to still be recognised after the motor gets up to speed)

[SyX]

At one point, I'd planned to doing a streaming-from-tape canabalt style game until I realised it was impossible for this reason...

Don't feel bad, you can always make a floppy version

[CraigsBar]

I'm fiddling with this idea, but for android. In any case, you don't want to use the dock connector, but instead the headset jack - the play/pause button on the headset controls is far easier to interface to than the 30-pin connector, and it's compatible with more devices.

The iPod classic (160gb that I have) does not support anything on the headset other than headphones. On a brighter note however the pause triggered by the remote in the dock is an instant stop, no faiding from the HDD based players.


Craig

[Munchausen]

I'm fiddling with this idea, but for android. In any case, you don't want to use the dock connector, but instead the headset jack - the play/pause button on the headset controls is far easier to interface to than the 30-pin connector, and it's compatible with more devices.


Only trick is that the phone will want discrete presses of the pause button, but the cpc 'holds down' the button. To get around that either requires software support, or extra hardware. I was thinking of going the software route, but if I come up with a simple hardware method I'll probably go for that.

It's a cool idea, you could use a simple monostable circuit to do this in hardware I think.

[karlmag]

Sounds like a neat idea.

Though, one thought that hits me is; with pulse driven start/stop (pause), how would one be able to know the current status of the sound device?
The CPC just assumes "motor on" is just that and vice versa.
I'm not saying it's impossible or even difficult to overcome for all I know, but to just assume a certain status will not necessarily always be true.
That said, worst case you would just have to rewind a bit or restart the loading.

[Bryce]

iPods don't have a "Pause Pin" neither on the 4pin headphone control port, nor on the 20pin connector at the bottom. They use a standard RS232 protocol to send commands to and from the device. So on the CPC side you would need a small PIC or AVR with RS232 to send the correct command. It's also not quite as simple as sending a pause command. There's quite a bit of setting up and handshaking to be done, much like a PS/2 mouse or keyboard involving headers and checksums.

So the code to pause an iPod looks like this:
Header: 0xFF, 0x55
Packet Length: 0x04 (In this case) - Count of Mode and Command Bytes
Mode: 0x02 (Simple Remote mode)
Command: 0x00, 0x00, 0x02 (Pause)
Checksum: 0x08 (In this case) - Sum of all data except header ANDed to 0xFF

Equally there is a set of commands to ask the iPod whether it's playing / paused etc should you need confirmation.

It would be a lot easier to buy a cheap iPod remote and wire the contacts of its pause button across the CPCs remote pins.

Bryce.

[CraigsBar]

The iPod classic (160gb that I have) does not support anything on the headset other than headphones. On a brighter note however the pause triggered by the remote in the dock is an instant stop, no faiding from the HDD based players.

Craig

Allow me to correct myself.... Fiddling with the 160gb Classic today and it DOES support the pause button of an htc Phone headset.


1 tap - Pause / Unpause
2 taps - Next track
3 taps - Previous track


so a quick motor stop start would definitely send the player onto the next track inadvertently. Far from ideal.


Kind Regards


Craig

[Bryce]

so a quick motor stop start would definitely send the player onto the next track inadvertently. Far from ideal.

Only if you were using the physical tap to create the command. If you sent the actual pause command you can send it as fast as you want (up to 19200 Baud) and the iPod will always understand it as a pause.

Bryce.