rcwlobe@klipper.cs.vu.nl (Reg Lobee) (04/18/89)
I have a Lightspeed 1200 modem which I can't get to work when I use it on 1200 baud with a normal program like vipterminal. (or any other program) The problem seems to be the kernal RS232 routines. I have changed the terminalprogram vipterminal so it uses a user defined baudrate (anyone familiar with the RS232 routines?). I have set the lo-byte to 40 and the hi-byte to 1. Now I can use my modem with 1200 baud, but I have to change all of my communication software to do so. Does anyone know what the problem is? What's the solution? Thanks in advance. |^^\ | Reg Lobee |=====================================| |__/ | rcwlobe@cs.vu.nl | To establish voice contact, don't | |\ | V.U. University | shout at the keyboard. Use a phone! | | \ eg | The Netherlands |=====================================|
izot@f171.n221.z1.FIDONET.ORG (Geoffrey Welsh) (04/19/89)
> From: rcwlobe@klipper.cs.vu.nl (Reg Lobee) > Message-ID: <2166@botter.cs.vu.nl> > > I have a Lightspeed 1200 modem which I can't get to work when I use > it on 1200 baud with a normal program like vipterminal. (or any > other program) The problem seems to be the kernal RS232 routines. > I have changed the terminalprogram vipterminal so it uses a user > defined baudrate (anyone familiar with the RS232 routines?). > I have set the lo-byte to 40 and the hi-byte to 1. Now I can > use my modem with 1200 baud, but I have to change all of my > communication software to do so. > Does anyone know what the problem is? I publish herein, with standing permission, an article by Steve Punter (author of WordPro and PETBBS/BBS64, and a pioneer in both fields): ===== Running a Commodore 64 at 1200 Baud ----------------------------------- If you thought that the only modification necessary to operate your C64 at 1200 was to say: OPEN5,2,0,CHR$(8) Instead of: OPEN5,2,0,CHR$(6) Then you have another think coming. I thought this originally, until I started to do some experimentation. These experiments started with a call to DATAPAC's 1200 baud line at 868-4100. I noticed that I wasn't receiving very well, so I tuned locations 665 and 666 to give me the best "reception". I couldn't explain why I had to "turn up" the port speed, but it appeared to work, until I tried to transmit that is. Not only was DATAPAC having a terrible time receiving what I was sending, but the Hayes Smartmodem, in command mode, would no longer hear me. Everything was fine if I set the port speed back to "normal", but now I couldn't receive error free. A call to Commodore Canada the next day revealed that because the C64 simulated an ACIA (the 6551) in software, higher baud rates lean heavily on NMI. This wouldn't be so bad if it weren't for the fact that the receive routines are affected more than the transmit routines. Great, now I was left with a machine that would transmit at 1200 baud and receive at 1160 baud. I went away grumbling to myself about how stupid Commodore was not to put in a proper ACIA. It then dawned on me that if I could alter the Kernal so that the transmit speed could be tuned independantly of the receive speed, I could lick the problems. I knew it was possible to download the Kernal into the RAM beneath it, and once there, I could do anything I wanted to it. The only drawback to this is that if you switch the Kernal ROMs out, you must switch the BASIC ROMs out too, and this means you have to waste 16K of RAM. I deemed this to be a non- solution. With some help from Dan Nelson (author of VIP Terminal), I quickly found out where the transmit speed was set. After an hour or so of disassembling ROM, I discovered that was accomplished in the CHROUT routine. This was marvelous, for CHROUT is RAM VECTORED and can be put where ever you like. I needed only copy about 200 bytes of the code to somewhere else in RAM and vector CHROUT to it. Did it work? Like a charm, but there was still one other glitch to overcome. I put the BBS up with this modication and designed things so that if someone called in at 1200 baud, the bit counts governing the transmit and receive port speeds were altered to suit. 300 baud mode continued to work flawlessly, but at 1200, users could receive everything fine, but the board couldn't hear them. I just couldn't understand it, so I set to work trying to find out the difference between my board and the terminal program I did the initial tests on. I found it; two locations, supposedly not supported in the Commodore 64, even though the PRG says they are, turned out to be critical. These were locations 661 and 662, the non- standard baud rate counters. Unlike 665 and 666, which must be loaded with a number equal to the clock frequency devided by the baud rate, 661 and 662 must be loaded with a number equal to: INT(CF/BUADRATE/2-100) Where CF is the clock frequency; 1,022,730 hz for North American C64's. With all these problems finally solved, the BBS was put up with automatic 300/1200 capabilities. Similar modifications have been made to my terminal program, and they too operate at 1200 baud, smack on. Downloading occurs at a rate of 21 blocks per minute and is just a joy to watch. If you'd like further information about these modifications, contact me at the board number between 11AM and 5PM, though I'm not always in. Steve Punter : 29-Oct-84 ===== Steve's 1200 bps kludge code was released in V2 of his C1 protocol example program, TERMINAL.C1 V2/TERM.C1 V2. If anyone wishes, I will post relevant sections of code for example. About two years ago I further modified that program to include an RS-232 driver that was good at speeds exceeding 2400 bps and made it available on my system as FASTTERM... the code was ported to the C128 in Chris Smeets' 80-column ANSI terminal that came with his CS-DOS package. The most accurate RS-232 drivers that I know of are the ones that I wrote and, with Matt Desmond, fine-tuned for use in DesTerm 128. If you have any specific questions, feel free to ask. Geoff -- Geoffrey Welsh - via FidoNet node 1:221/162 UUCP: ...!watmath!isishq!171!izot Internet: izot@f171.n221.z1.FIDONET.ORG