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.) MarkoReceived on 2019-01-25 08:00:04
Archive generated by hypermail 2.2.0.