eravin@dasys1.UUCP (10/02/87)
All this talk about 1200 baud problems reminds me... When I was co-writing a Commodore 64 BBS program (known as FROG BBS for those of you who have seen it running in the NYC Metropolitan Area), I came across an interesting problem. The baud rates for a 1200 baud modem vary between receive and transmit, enough that on long data bursts one cannot use the same timing values in the pseudo UART that the Kernal provides. Our BBS program had to do the following kind of kludge in order to avoid data glitches when long streams of data were sent: Since the BBS was usually talking and the user only hitting one or two keys at a time to move through the messages, the baud rate timing was set to a value that worked on transmitting long bursts. When the user decided to enter a message, we switched the timing value to a baud rate that would work when recieving long bursts, since the user might be using macro keys or some kind of upload program to send their message in. However, when a user sent in a macro key or a fast stream of data, the BBS program would receive the data properly, but the echoing would get glitched after ten or twenty characters (remember, the BBS is the host, so it has to echo the data the user types). So the C-64 seems to be able to handle half duplex communications at 1200 baud with no problem, that is, as long as only one side is sending long bursts of data at any one time, nothing goes wrong. As soon as both sides try to send long bursts of data, then things go wrong. Not averse to writing my own device drivers when Commodore's software or hardware has let me down (I have an improved keyscan that fixes the "phantom key" problem, if anyone out there wants it), I grabbed my copy of the ROM listings and began digging in. My guess is that my problem with long bursts of data could be fixed if the RS-232 driver used separate timers on the CIA for the receive and transmit clocks. Has anyone out there ever tried this? I imagine that there would also be numerous "kludgy" solutions to this problem, such as inserting timing delays when transmitting a long character burst while your "user baud rate" is set for receiving long bursts, but I would prefer a solution that gave me the full throughput at 1200 baud in both directions. --