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.