Re: Android Headset specification

On Sat, Jan 26, 2019 at 07:33:54AM +0100, André Fachat wrote:
>>The 264 series also has the peculiarity that they display 17 bytes of 
>>file name instead of 16, from the 192-byte tape buffer.
>>
>>There are some timing variations even between the non-264 machines, 
>>which you can find in the source code of my "c2n" and "c2nload" 
>>programs. There is also quite a bit of jitter in the pulse widths; I 
>>would say that it is because of sloppily written tape routines. If I 
>>remember correctly, because of this, tapes recorded on a PAL Vic-20 
>>are not reliably playable on a PAL C64. (Some of the short/medium/long 
>>pulses would sometimes be mis-quantized.)
>
>I had assumed it was due to the different clock speeds that tapes were 
>not compatible. I remember advice to transfer files via the PET as its 
>1MHz clock would be "in between" the VIC and C64.

Back when I developed the C2N232, I did not have the patience to reverse 
engineer the Commodore tape routines. It was much easier to type SAVE 
and then capture the pulse stream for analysis. It would be interesting 
to know what exactly caused the noticeable jitter in the pulse widths.

I do not think that my old notes still exist. I do not remember how much 
the jitter exactly was, but I think that it must have been several 
units, maybe even more than 10 units (10*8µs), It could have been more 
on the Vic-20 and C64 than on the CBM 8032. For sampling, I always used 
a frequency of 125kHz, that is, the resolution of the pulse widths was 
8µs. If I remember correctly, this corresponds to what is used in .tap 
files.

I see that in c2n.c, I am using the same pulse widths for all C= 8-bit 
models except the 264 series: 45*8µs, 63*8µs and 83*8µs. For the 264 
series, I used the pulse widths 60*8µs, 120*8µs, 240*8µs. I wonder why 
Commodore degraded the speed that much, and why they chose a different 
encoding to encode data into short,medium,long pulses on the 264 series.

The KIM-1 by the way used 34*8µs and 52*8µs, and it encoded data in 
hexadecimal (expanding 8 bits of payload into 16 bits before encoding to 
pulses).

	Marko