Re: Android Headset specification

From: Marko Mäkelä <msmakela_at_gmail.com>
Date: Fri, 25 Jan 2019 08:44:00 +0200
Message-ID: <20190125064400.GA3397@jyty>
On Thu, Jan 24, 2019 at 08:02:37PM +0100, Mia Magnusson wrote:
>Does it bank switch rather often? If it loads a really large program, 
>it might be better of to start with the $D000-$DFFF section and receive 
>that block to some other location in memory, and then just copy the 
>memory, so it doesn't have to bank switch too often.

It switches on every byte. The same routine is used in cbmlink, and I 
did not want it to trash any additional memory there.

>> On Linux, it seemed to me that a write() call cannot really be 
>> interrupted; neither XON/XOFF nor CTS/RTS flow control seemed to have 
>> any effect on it. It would be written in multiples of 4096 bytes even 
>> if you killed the process. So, I tried to ensure that the Commodore 
>> side is fast enough so that the 124-byte buffer in the AT90S2313 or 
>> ATtiny2313 never fills up.
>
>That must be some kind of bug in the serial port driver. Perhaps not 
>detected due to modern modems probably has a large enough buffer that 
>the "oversend" won't cause problems.

Yes, it felt like so. And that was with a 16550-compatible port.  
USB-based RS-232 interfaces are even more problematic, each driver 
having its own quirks. Maybe the situation has improved since then; I do 
not know. I got bad experience from the FTDI driver (I would not have 
expected, given that their interfaces are so expensive) and better from 
the Prolific PL-2303. Nowadays there could be more adapters that can use 
the standard USB Communications Device Class (CDC) driver. I have no 
experience from those.

>If it would be easier to make the timing work more exact, the sender 
>could somehow account for the badlines and just pause during a badline.
>
>On the PET and the VIC 20 this shouldn't be a problem, and the same
>goes for C128 users using the VDC output and running at 2MHz.

Yes, the slowest of them all is the PAL C64.

>Oh, that is a surprise to me. I had assumed that all commodores that 
>can use a Datasette uses about the same format. But I honestly have 
>only used a Datasette on a PET, VIC-20, C64 and C128 (i.e. the 
>relatively common 8-bit Commodores).

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

	Marko
Received on 2019-01-25 08:00:04

Archive generated by hypermail 2.2.0.