Last weekend, I implemented fast transfer routines for my C2N232 device. Sending bytes from the C= side to the microcontroller uses a self-timed variable-speed scheme, sending 4 bits at a time by using 16 different pulse widths, which differ from each other by 5 Commodore clock cycles. Receiving bytes from the microcontroller to the C= uses a scheme where the C= toggles the cassette write line and the microcontroller responds by raising cassette read, and if the bit is zero, by again lowering the signal, after a delay of 9/8 microseconds. This scheme works regardless of whether the cassette read signal on the C= side is sensitive to a falling edge or it is a general-purpose input line. There must be some delay between toggling the write line and reading the read line. I've tested it at 985 kHz clock speed (PAL C64/C128) with a 6-cycle implicit delay. I'm trying to shorten the delay further (to allow 2 MHz operation on the C= side without wait states) by re-enabling interrupts earlier in the UART receiver interrupt handler. My test program on the C128 receives a byte in 128 clock cycles plus handshaking. If the whole transfer loop took something like 160 clock cycles, this would correspond to over 6 kilobytes per second transfer speed. So, the 38400 bps serial line (3840 bytes per second) will be the bottleneck. Marko Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.1.