Re: Android Headset specification

Den Thu, 24 Jan 2019 19:21:12 +0200 skrev Marko Mäkelä
<msmakela@gmail.com>:
> On Thu, Jan 24, 2019 at 10:36:08AM +0100, Mia Magnusson wrote:
> >>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?
> 
> For c2nload, the limit is the processing speed on a PAL C64, I think 
> with the screen enabled. Before I found a tweak to the code, I was 
> unable to get a reliable transfer. My transfer routine does bank 
> switching, so it can write to any RAM location, including $d000-$dfff 
> where the CIA is mapped.

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.

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

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.

> >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.
> 
> Yes, that would be a possibility. If I remember correctly, the 264 
> series had something strange about the signals, compared to the
> others. Maybe it was that the CASS READ signal is connected to a GPIO
> pin, and not to the FLAG input of the VIA or CIA that is only able to
> detect falling edges. Also the tape format is radically different on
> the 264 series (slower if my memory serves).

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

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