fred@cbmvax.UUCP (Fred Bowen) (10/01/87)
> I think that my C64 clock frequency may be slightly off. I have also heard > that the 1200 baud rate that modems expect is not the same as what the 1200 > baud rate is that Commodore programmed into the C64 "bit-busting" routine. > Can somebody from Commodore shed some light on this? I doubt your clock frequency is off. a baud rate of 1200 is easy enough to handle on a C64, and a rate of 2400 is possible on a C128 in FAST (2MHz) mode. When you consider it's a software emulation, it's really not bad. As you had indicated, there is substantial differences in performance among the many terminal packages- the C64/128 is rather constant if programmed correctly. Few people realize there is a difference, too, between direct connections and communicating with a modem. A modem typically communicates at the high end of the spec-ed range of any data rate. For example, at a baud rate of 1200, a modem communicates with the terminal at something like 1210. This is why you have to "tweak" the C64/128's data rate- it's dead-nuts-on 1200, and the +/- range it can accomodate is small. Hence you see alot of garbage. If the terminal package allows you to adjust the rate for communicating with a modem you should, especially for the more critical faster rates. Earlier C64's did not take into account the different clock rates in Europe. This was corrected a long time ago, and unless you have a very old (pre-1983) C64, you need not concern yourself with this. There was no error in the baud rate tables other than this, and I can find not mention of any such bug in the book someone mentioned, "Mapping the Commodore 64". Perhaps the greatest limitations of the software UART are the small buffer sizes- 256 bytes each for input and output, and no built-in flow control. When you consider a single 40x25 line screen is 1000 characters, them little buggers are really humping! Admittedly, a screenful is usually something less than full, but that is not the point- for communications like editing or reading email, it works pretty well. For dumping to the screen a hugh file without utilizing flow control, yer gonna lose. This where the particular terminal package you choose plays a big part. Same holds true for whatever you use to up/download stuff. But the software UART has been flexible enough to grow beyond that which for it was originally intended. -- -- Fred Bowen uucp: {ihnp4|rutgers|caip}!cbmvax!fred arpa: beats me tele: 215 431-9100 Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380
elg@killer.UUCP (Eric Green) (10/03/87)
in article <2442@cbmvax.UUCP>, fred@cbmvax.UUCP (Fred Bowen) says: > Few people realize there is a difference, too, between direct connections > and communicating with a modem. A modem typically communicates at the high > end of the spec-ed range of any data rate. For example, at a baud rate of > 1200, a modem communicates with the terminal at something like 1210. This > is why you have to "tweak" the C64/128's data rate- it's dead-nuts-on 1200, > and the +/- range it can accomodate is small. Hence you see alot of garbage. > If the terminal package allows you to adjust the rate for communicating with > a modem you should, especially for the more critical faster rates. That is one problem, dealing with recieving. There is another problem, fairly famous and well-documented by Steve Punter, in transmitting characters to the fake RS232. The way I heard it described was as a synchronization error. I don't know, but I do know that it is "solved" by just waiting for the current character to be completely outputted before adding another character to the output buffer (necessary anyhow for implementing software flow control -- after all, you're sitting in a loop looking for ^S anyhow!). If you dump characters too fast to the buffer, they get garbled. Steve Punter has a more sophisticated fix, that, I assume, makes sure that the NMIs don't grab a byte while the CHROUT routine is trying to save a byte. However, I haven't spent much time deciphering Punter's routine (the guy documents like a demon -- one comment per 1,000 lines, just like in Unix sources!). All of this would, of course, be solved quite readily just by hanging a real UART off the cartridge port. Only problem is that most disk speedup products live there, too..... they'd have to be designed to live together in peace. And, considering that most C-64 terminal software doesn't bother poking the fake UART with numbers anymore (just shoving numbers into the "user defined baud rate" bytes), compatibility might be a real problem.... -- Eric Green elg@usl.CSNET "... hanging on in quiet desperation {cbosgd,ihnp4}!killer!elg is the english way, Snail Mail P.O. Box 92191 the time is gone, the song is over, Lafayette, LA 70509 thought I'd something more to say....."