Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site topaz.ARPA Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ihnp4!cbosgd!cbdkc1!desoto!packard!topaz!prindle@nadc From: prindle@nadc Newsgroups: net.micro.cbm Subject: Re: Problems with 1200 baud Kermit Message-ID: <2478@topaz.ARPA> Date: Wed, 3-Jul-85 16:00:34 EDT Article-I.D.: topaz.2478 Posted: Wed Jul 3 16:00:34 1985 Date-Received: Fri, 5-Jul-85 07:12:25 EDT Sender: daemon@topaz.ARPA Organization: Rutgers Univ., New Brunswick, N.J. Lines: 48 From: prindle@NADC 1200 Baud is no major problem on the 64, provided you know the "wrinkles", and Kermit does (at least the assembly version, not the forth). By now it's no big secret - 1. use assembly language, 2. use non-standard baud rate to compensate for kernel bugs, 3. carefully control when bytes are transmitted relative to incoming data, 4. time outgoing bytes so they are not written to the rs-232 buffer faster than 120/sec. Once you do all this, it always works great (in fact, so many programs, commercial and otherwise, now depend on the aforementioned kernel bug, that Commodore doesn't dare fix it, even in the 128!). I suspect that 2400 baud is possible, although I haven't heard of anyone with the requisite equipment having tried it out - the tough part is deriving the correct non-standard baud rate constant, mostly by trial and error. The only possible hitch is that the kernel will have to contend with an interrupt every 415 microseconds instead of every 830, and it's beginning to approach the point where the kernel overhead may leave very little CPU time for the comm program itself. Full duplex (ie. hitting a key while incoming data is being displayed) further increases the number of interrupts to be serviced. Also, scrolling the screen takes sufficiently long that flow control (xon,xoff) will be a necessity at 2400 if it works at all. As for the person who was having trouble with kermit at 1200 baud on the foreign model c64, there are two possibilities. 1. The first few releases of c64 kermit did not support 1200 baud, so you may have one of those. 2. The kernel is supposed to take care of the different CPU/DOT clock rates when dealing with PAL standard c64s, but if they could screw up the baud rate clock settings in general, they probably screwed this up too. As further proof of the feasability of 1200 baud, I took the crude terminal program from the C64 PRG (written in BASIC), and literally translated it to C, modified for 1200 baud, compiled it with Brian Hilchie's C-Power, and it works just fine. In spite of the relatively unoptimized code generated, it's main loop was still fast enough to keep up with 1200 baud with half the loop spent idle. Much of the "bad-press" regarding the c64 and 1200 baud resulted from early commercial terminal programs whose authors made the fatal mistake of believing something they read in a piece of Commodore documentation without testing it! Even the first two versions of Compuserve's VIDTEX program suffered from this effect - they made up some pretty ridiculous excuses (for 1200 baud anomalys) in their documentation before they figured out what they were really doing wrong. Lastly, to be technically correct, replace "baud" in all the previous discussion with the correct term: "bits per second". Cheers, Frank Prindle