jmg@cernvax.UUCP (jmg) (07/01/85)
Has anyone out there got either Kermit or any terminal emulator working at 1200 baud? I have tried several versions of Kermit without success. Normal typed input goes OK, but high speed input (holding down the key) seems not to work. The output of any command is recognisable (just) but garbled in a random fashion. Leads me to believe that the 64 has problems to handle 1200 baud: 2400 seems an eternity away. Maybe it has to do with the fact that I am on the European standard, but the RS232 routines supposedly handle this. Any information welcome.
percus@acf4.UUCP (Allon G. Percus) (07/02/85)
I would suppose that the 64 would have MUCH trouble handling
1200 baud. Remember, that's 1200 bps, or 150 characters per
second. Very fast for the 64, considering that a routine
put in the interupt will only strike 60 times per second.
Hence, some sort of "wrinkle" is necessary to make things
faster by several orders of magnitude, and I don't think
KERMIT provides it.
A. G. Percus
(ARPA) percus@acf4
(NYU) percus.acf4
(UUCP) ...!ihnp4!cmcl2!acf4!percusGMW@psuvm.BITNET (07/03/85)
I have been using Eric Lavitsky's C64-Kermit at 1200 baud for months now
with absolutely no ill effects. I have heard that terminal programs written
in Basic can't keep up with 1200 baud, but Kermit is written in 6502 assembler,
and certainly doesn't use the 60 Hz interrupt for RS-232 I/O. Don't forget
that the 64's 1 Mhz CPU can process a couple hundred thousand instructions per
second.
Has anyone tried Kermit at 2400 baud?
George M. Weaver
Penn State Astronomy Dept.
GMW at PSUVM.BITNET
...!allegra!psuvax1!gmw@psuvm.bitnet
prindle@nadc (07/03/85)
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
jeff@gatech.CSNET (Jeff Lee) (07/04/85)
> I would suppose that the 64 would have MUCH trouble handling > 1200 baud. Remember, that's 1200 bps, or 150 characters per > second. Very fast for the 64, considering that a routine > put in the interupt will only strike 60 times per second. 1200 bps (asynchronous) is not quite 150 chars per second. Depending on the number of stop bits or the length of the character, the data rate drops fairly quickly. Asynchronous transmission normally uses 1 start bit (to let the hardware know that another character is coming) plus the number of bits in the character followed by 1 or 2 stop bits to finish the character and get ready for another. This means that a single character could require from 9 to 11 bits for transfer. The following assume 1200 bps transmission: 1 start + 7 data + 1 stop = 9 bits = 133.3 chars per second 1 start + 7 data + 2 stop = 10 bits = 120.0 chars per second 1 start + 8 data + 1 stop = 10 bits = 120.0 chars per second 1 start + 8 data + 2 stop = 11 bits = 109.1 chars per second. These also drop lower if you start sending parity bits. I don't have a Commodore modem, but I doubt that since it is an 8 bits machine that it uses anything but 7 or 8 bit transmission and almost anything higher than 110 uses only 1 stop bit. This would put it in the 9-10 bit range per character. Enjoy..... -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff
adam@utcs.UUCP (Adam R. Iles) (07/06/85)
Hello, and yes, I use my 64 to talk at 1200 baud. The effects
that were mentioned (grabled characters when a key is repeating, or
a large passage is being sent) seem to fit with what I experience
from time to time. The cause(s) for this can be explianedby the fact
that there isn't a communication chip in the 64 (i.e.; rs232 is handeled
by software), and if you are using a 64 made for Europe the clock
speed isn't even at one Mhz (the television signals are timed differently)
I get around this by turning off the vic ii chip, and use an 80-col
adapter, this seeme to work alright (but kiss parity good-bye).
Since it was mentioned that you are using a European 64, I'd
suggest that that is what is killing the proffesional programs from
working on your machine, since they tend to adjust the number of
interupts that hit in a given amount of time. As far as fixes for
this go (I use a Canadian 64, so I don't have any).
--
If god had meant for 64's to communicate he would have given
them communications chips, 80 columns, faster clockspeeds, ...
Any opinions stated above may, or may not, refect those
of any sane person living, dead, or just sleeping.
Adam R. Iles:
...{decvax,ihnp4,utcsri,{allegra,linus}!utzoo}!utcs!adam