Talk:MOS Technology 6551

Latest comment: 12 years ago by Klaws in topic Theoretical limits

"EZ232" should be one amongst a handful of circuits exploiting a hack originally invented by Daniel Dallmann (as suggested by, amongst other sources, the comp.sys.cbm faq, http://www.faqs.org/faqs/commodore/main-faq/part3/ , and another implementation: http://zimmers.net/anonftp/pub/cbm/documents/projects/rs232/rs232-userport-9600.zip ). That one (Dallmann's invention that makes it possible to go up to 9600bps on a stock machine) might probably worth mentioning.

94.21.98.100 (talk) 13:15, 19 August 2010 (UTC)Reply

Theoretical limits

edit

Back in the mid to late 1980s, I developed a serial interface for the C64, designed to work at speeds of 9600 and 19200 baud. The hardware consisted of simple level translators. While 19200 baud was the theoretical limit, I mainly used it at 9600 baud.

The software side had some serious limitations. To be able to bit-bang at 19200 baud, VIC-DMA was turned off. The screen would flash when data was received. All received data was buffered to RAM. When the user wanted to see some output, he had to press a key, VIC-DMA would be turned on and data would be rendered in an 80 column mode (hires graphic). Background: VIC-DMA would steal too many cycles to allow for proper operation at 9600 and 19200 baud. So VIC-DMA had to be turned off, disabling screen output. Since the software would have no idea about when to safely reenable the screen, this was left to the user.

Data transmission would be postponed until the user hit the return key, at which time VIC-DMA would be turned off again (the screen going blank again).

Whatever: at 9600 and especially 19200 baud, the RAM of the C64 would fill quite fast. Prolonged communication at this speed makes little sense on an unmodified C64 - the disk drive cannot retrieve or store data at this speed. I used the 9600 baud speed with the ROMWack (kernel debugger) of the Amiga, which operated at a fixed rate of 9600 baud.

--Klaws (talk) 15:09, 13 April 2012 (UTC)Reply