8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / 2400.AND.UART.TXT < prev next >

Wrap

Text File | 2019-04-13 | 20.6 KB | 390 lines

************ Topic 17 Date: Thu Dec 19, 1985 DEB [*Sysop/deb!*] Sub: 2400 baud and UartART 2400 baud on a C-64...?! ------------ CHARRINGTON Can anyone pass on some advice on the US Robotics Courier 300/1200/2400 modem? I have one on order...and could use some ideas as to what is a GOOD PD term pgm for it like Comm Term III etc. ------------ LAPTOPS I & a friend both have US Robotics Courier 2400 modems. I've never had any trouble with it & I use many of the arcane S register commands. Its command set is much simpler than the Hayes 2400. (It doesn't let you program European guard tones, CCITT 1200bps, or synchronous operation.) I love the x6 fast dialing mode & the > to redial 10 times. The US Robotics is the modem used by the 5 local 2400 bps BBSs that I know. ------------ DEB Weeel, Courtney, first item on the agenda to note is that a C64 will not *work* at 2400 baud. Some of my favorite 1200 baud PD terminals include XMOBUF, Cand COMMTERM. But Sixth Sense really spoiled me &`I rarely use anythin but 6th or BobsTerm Pro anymore. ------------ CHARRINGTON Hi Deb! I picked up a US Robotics Courier & seems to work great..at 300 & 1200. Question: why won't the 64/128 work at 2400? I had thought 9600 was the top end for data xfer. Don't tell me I gotta buy an Amiga to get 2400?!? There's a C64/128 BBS in Calif that is planning to go 2400 in about 2 weeks. I thought the sysop said he got it all worked out. ------------ DEB Courtney...the C-64/128 is running as HARD & as FAST as it can at 1200. Unless someone completely re-writes the RS-232 drivers/kernal, 2400 baud is not possible. So far, no one has written it that I know of. It just *might* be possible on the c128 in the New Version of Sixth Sense that Rick Sterling is writing, I really know, but could ask. Let's hear it for CBM's Non-UART!!! ------------ CHARRINGTON Please don't be upset...but I up'd a small effort on my part that runs at 300/1200/2400 baud. It should show up in the C64 Telecommunications library in a couple of days. It's called 2400 term & it supports punter or xmodem at all 3 speeds. It does show a few line errors at 2400 when calling long distance, but it successfully downloaded a 73K program between Hawaii & California at 2400. Maybe someone can improve upon it a bit. It's pretty simple, but I was working more to get it completed than get it pretty. Now! Let's see if we can get to 4800 baud!!! Courtney ------------ LFRANKLIN [Mr.Wizard] Why doesn't someone come up with a little UART board for the 64/128 with an on-board baud-rate generator & rs232 level conerters preferably. It shouldn't be too difficult for a halfway decent hardware type. Of course, it wouldn't help those with Commodore modems, but then again, the present hardware doesn't handle anything over 1200 anyway (at least not reliably) so commodore will probably never come out with a 2400 baud modem. But is sure would be a help for those with those non-commodore modems! If anybody is interested, I think I still have 1 or 2 prototyping boards for the expansion socket on the 64/128. ------------ CHARRINGTON I've done a bit more work on the 300/1200/2400 terminal prograam for the c64. It's been uploaded into the telecommunications DB under "300-2400 term". Not Not completely full featured but looks a lot better than the original work. ------------ DEB Courtney...I'll make that term program available right now. Thanks! You ACTUALLY got 2400 baud on the 64 using the existing drivers???! LF...YOU have a board that replaces the UART? Do tell us more..!!! ------------ Message 10 Date: Thu Dec 19, 1985 LFRANKLIN [Mr.Wizard] DEB...no, that's not what I said...what i said (or at least meant to say is that I have a couple of Prototyping boards for the C64 expansion jack in the back...these are perf boards with a card-edge connector to 1 side that plugs into the expansion connector on the back of the C64 or 128. Hardware types can use these to create prototype boards from just looking at the Schematics of the 64, I am thinking that it should not be too difficult to create a UART board for the 64/128...of course, to talk to the board you'd have to talk directly to the hardware, or put in patches to the Kernal RS232 routines to talk to the UART..but this would be the only RELIABLE way I know of to get speeds above 1200 baud....any hardware types out there who want to try it, they are available from Boreas Products in Colorado Springs, Co for 15.95 (the board is 6.5 by 4.5 inches) or 12.95 (for a 4.5 by 4 inch version) &, for those who are interested, the plated thru holes have .100 (vert) by .300 (horz) inch spacing. Their number in Colorado is (303) 593-1274. I'd try to build 1 myself but who has the time? ------------ Message 12 Date: Thu Dec 19, 1985 DAFORMAN I don't know about the C64, but the C128 in FAST mode can do 2400 baud. UART boards for C64 and C128 already exist in all of the MIDI music interfaces. Midi is VERY fast, & the software UART in the computers doesn't have a chance of keeping up so all the MIDI interfaces include a real live hardware UART. I don't know if it would be possible to use a MIDI interface to work with a modem, but it is evidently no big problem to get very high baud rates on a c64 or C128 by adding some hardware. Dean ------------ Message 15 Sun Jan 12, 1986 FAFHRD [Fafhrd] Has anyone seen any Joystick modems for the 64? I seem to recall the Atari being able to handle high bps via joystick port. Any comments? FAF ------------ ------------ BOBR [Bob Retelle] Actually, the real reason for the Atari modems which attaach to the joystick ports is to avoid having to buy the Atari interface module, which is somewhat like the US/ART board being discussed, but costs $100-$200... With the interface module, speeds up to 19K baud can be used. The joyports are parallel, so the serial/parallel conversion has to be done in software, but that's no real problem. Which all goes to say there probably wouldn't be much point in a modem which goes in via the joyports on the 64. When you said 'joystick modem', I thought you were referring to the actual terminal software! My favorite program lets me use a JOYSTICK to control the terminal, so I can just sit back and use the stick to CTRL S, CTRL Q, RETURN, CTRL O & whatever else... I only have to use the keyboard to actually enter text. & at 1200 baud, it's like playing a video game to keep up with the screen! ------------ SPLITR [SpLiT] At one point CBM stated flatly that the C64 would not function at 1200bps, hackers proved them wrong. They also said it would not work at 2400 bps, & again the programmers made it happen. But beyond 2400bps is not possible with the hardware (or lack thereof) present. Mainly because the c644 uses a Soft-U/ART. What do you expect? But a hardware U/ART inerface is not only possible, not only been done (MIDI, as stated earlier), but I am designing a multi-port expansion for the C64. This little baby is a computer in it's own right, & is expandible to 16 ports. We all know the C64 is not multitasking, but a tricky programer can make it multiuser if only he could get more than 1 stuck in the back of the thing. Don't belive me? Diversi-dial for the Apple ][ multiuser but not multitasking of course. With this in place & with the software drivers I am writing, a multiuser RTC or CB or Multiuser game (any maybe a multiuser BBS also) can be rigged. Since the expansion itself is a self contained computer, it handles all I/O (using smart software) & lets the C64 do what it wants until it requests something from the expansion. The system has RAM & EPROM (initilizing) and is capable of running the 6 U/ART system independent of the C64. At this time, most of it is on paper still. The testing prototypes have proved it is possible. My concern is that the system will be more expensive in the end than getting something that could do it already. But in the interest of hacking out the C64, how can I resist? SpLiT/ /iNfInItY ------------ Message 19 Sat Jul 05, 1986 LAPTOPS It says in different messages here that there IS 2400 baud code & then again that there ISN'T 2400-baud code. If any of you DEVELOPERS are interested, I've got 2400 baud code THAT WORKS. Even in full-duplex (both ways at once), it works fine & doesn't slobber all over the machine. The catch is that it's not free. After all, this is the age of Reaganomics (you only get what you pay for), & I'm not a tenured professor. Paul Schick (608) 258 7065 ------------ Message 20 Sat Jul 05, 1986 SURVIVOR [S. Gutknecht] There are some FREE 2400 baud terminal programs, they are not loaded with features, but they DO work. ML is the secret. Question: what are the 2 open bytes for 2400 that are a TRUE 2400?^ ------------ CHARRINGTON There is a 64 terminal program on GEnie that suppots 300/1200/2400. I wrote it. It ain't fancy, but it works. Maybe someone will add some bells & whistles on it. It's called '2400 term' Courtney ------------ Message 22 Tue Jan 13, 1987 PFOUNTZ [Greg] With the prices rapidly dropping on 2400 baud modems ( Ijust found 1 for $229), I feel we are going to see more & more c64 owners wanting to move up to 2400. I just reread the message thread in this topic (no messages posted since last summer) & last comment made was that it does work, but not as good as it should. When sending "AT" commands to the modem, quite often the command will garble and/or not take. Makes autodialing at 2400 a real chore. Once online, communications is pretty good. I have noticed about 25% retrys while receiving a file using XMODEM but zero errors while sending. Guess this kind of confirms the 64 is overtaxed at 2400?? I realize that a C64 running at 1 meg will have a hard time buffering text at that speed & that a 25K or less capture buffer (common in most terms for the 64) will fill up in the blink of an eye. All I am trying to do is get a stable 2400 baud (no garbage when sending the AT commands), then we can worry about keeping up with the flow. Anyway, just thought I would ask again, has anyone made any more progress since Charrington's 300-2400 TERM?? I see the same errant characters when sending AT commands using 300-2400 TERM as I do with the term in my BBS running at 2400. I am hoping to get the baud rate clean enough to make it a regular part of Color 64 BBS. But I need to get a more stable 2400 baud. Any information is appreciated. Also, am interested in any hardware "UART" add-ons for the 64 that would help. ------------ Deb I have used both BTPro 128 & Sixth Sense 128 at 2400 baud..flawlessly. Will keep my eyes open, Greg, I agree with ya, its going to be more & more affordable soon, & I'm glad to know that someone is working on a fix for it now. ------------ Message 24 Wed Jan 14, 1987 KEVIN-S. [KeS] Darn, I remember someone that was putting out an interface for the expansion port that was to include a "real" UART...back in the new products section of 1 of the popular Commodore mags last spring maybe? Of course, then you have to program something to look for it there. ------------ Message 28 Wed Dec 16, 1987 S.PROCTOR1 Greg: I don't know what you've tried with the 2400 baud, but I hve a few suggestions. I found the VIC-20 appears to handle HS much better than the C64. I think the reasons are both the VIC generates 0 wait states, & the nested MNI. On the C64, I occasionally get garbage when typing & receiving data at once, like an echo, and most commonly during a wordwrap. Usually I get 0 error transfers, with my C-64. I've found 1 problem with this nested NMI, the RS232 gets disabled if I hit RESTORE instead of RETURN, requiring a COLD START to restore this. It may help to rewrite the c64 routines to RAM, using no variables, ie. eliminate the variable stop-bits, data-bits, & parity. This will eliminate the constant checking of RAM, but may not add alot of time, I haven't looked into this too closely, yet. It wouldn't be hard to intall a UART in the C-64, but you will have to avoid the I/O lines, as many cartridges use them (between my TURBO LOAD&SAVE, & second SID, its fully addressed, not to mention IEEE and RAM use them.) This would mean multiplexing the high data lines with the chip-select of something, like a SID or CIA, it doesn't matter, as long as your routine knows where it is. This will eliminate the mirrors, for those programs that insist on using them, to try 6 hide what its doing, for a simple protection scheme. I hope I have given you some ideas to work with. I haven't worked too hard in this area, but with a BBS I'm working on I had to consider these problems, & possible solutions I could use in the future. Steve Proctor ------------ Message 29 Thu Feb 23, 1989 DEBS-GUEST I've developed both single-port & multiport UART boards for both the expansion port and the user port The real trick was getting 'true' 8-bit control with the user port. With that done, as you suspect, the rest was pretty cut & dried. You can check on the progress of those boards as a formal product with the boys at SOFTECH in Lexington, or author Bill Brier of Chicago. Both Softech & Bill are working on different releases of the same devices. The four-port device can support 4 ports SIMULTANEOUSLY, in full-duplex at speeds in excess of 2400 baud & can suppot a composite rate of over 11,000 (thousand) baud. The single-port version will do ROCK SOLID 17,800 baud... I use that 1 myself in IBM mainframe to CBM 64 interfacing. Lloyd Sponenburgh ************ Topic 101 Sun Jan 22, 1989 P.HALTON Sub: 1200 baud xmodem upload problems another solution to 1200 xmodem uploading problems you don't have to adjust the baud rate factor ------------ Message 1 Sun Jan 22, 1989 P.HALTON A few weeks ago I started using a 1200 baud modem (the commodore 1670). I adjusted the baud rate factor & opened the modem channel with the settings open2,2,0,chr$(0)+chr$(0)+chr$(61)+chr$(1). Everything worked great except when I tried to upload using XMODEM. I was told that it was a matter of fine tuning the BRF, but no matter what settings I tried, I couldn't get uploading to work. I have discovered that the problem is not with brf. The problem is caused by the number of stop bits appended to the end of each character frame. More precisely, the lack of a sufficient number of stop bits. Here is my reasoning. When you send a byte to the modem it is stored in the UART transmit queue. The UART then sends it to the modem bit serially preceded by 1 start (sync) bit, & followed by 1 or more stop (idle) bits. The start or 'sync' bit has the opposite polarity of the stop bits, & is used by the modem to get in step (synchronize) with the UART. This synchronization allows the modem to correctly receive the subsequent data bits. Stop bits are appended to the data bits to insure that the next start bit will be seen by the modem. The stop bits act as a sort of 'line idle' state. Unfortunately, at 1200 baud on the commodore's software UART, 1 stop bit does not seem to be enough to allow the UART & modem to stabilize in the idle state. Thus, the next 'sync' bit is not always seen by the modem synchronization goes right out the window. This results in garbled information arriving at the modem from the UART. This synchronization problem doesn't show up when typing characters at the keyboard,because, no matter how fast you type, the UART is always way ahead of you, & thus there is always alot of idle time between characters. Uploading often fails because most terminal programs send XMODEM blocks to the UART transmitt queue in 1 qiocl blast. There is no delay between characters of the block, & thus, the only idle time is provided by the single top bit at the end of each character frame. If you are not able to modify the coding of your terminal software, the only suggestion I have is to try setting it for 2 stop bits, or more if possible. If you are writing your own terminal program though, try sending the XMODEM blocks byte by byte, allowing the transmitt queue to empty briefly between bytes. The following code segment has the effect of appending an additional 10 or so stop bits to each character frame. A little math will bear this out. ldx #2 ;modem file # 2 jsr chkout ;connect output channel to modem lda #0 sta 162 ; clear low byte of software jiffy clock wait lda 162 ;let 1/60 second elapse before sending a byte to the UART cmp #1 bcc wait ldy #0 sty 162 ; reset timer for next byte lda (251),y ;assumes that block is pointed to by 251, and is stored ; beginning at an even page boundary jsr chrout ; send to UART inc 251 ; set pointer to next byte dec bytecount ; assumes that 'bytecount' holds # of bytes left to send bne wait jsr clrchn ; reset default I/O channels rts At 1200 baud, the UART can transmit roughly 20 bits per sixtieth of a second. The above routine passes it 1 byte (10 bits with framing) per sixtieth of a second. The remaining 10 bit capacity of this interval is idle. This 10 bit idle time after each byte insures that the modem will 'see' the start bit of the next character frame, & properly synchronize with the UART. The trade off here is that it will take roughly 2.4 seconds to get the entire XMODEM block into the transmit queue, cutting the upload speed in half to about 600 baud. However, it is still a lot better than 300 baud, but just as reliable. Even if this theory is right off the wall, it sounds pretty good to me. More importantly, the introduction of brief delays between charaacters works. I would welcome any discussion on the matter. ------------ C128.CPM [Bill] At 2400 baud, a 1K block takes about 1 second (guessing) to xmit, with a short ACK, then another block. Your brief delay would slow this down too much. You are compensating for the lack of a hardware UART. ------------ H.HERMAN1 PH, The stuff you posted is really out of my league. However, you keep referring to a UART, which is non-existant in both the 64 & 128. I recall having read postings while Bob Lentini had his support BBS running, about how difficult he found writing code to compensate for the lack of the UART. At one time he mentioned that half the time he spent on writing BTP128 was dealing with this prob. He seems to have done very well, since I routinely up/download & post messages at 2400 baud wtih BTP128, without the need to add nulls, delay timing or even fool around with the hi/low trim settings. [BTP seems limited to 2400, but I have read postings by Fred Bowen that he has his 128 running a null-modem at 4800 baud, & I have seen postings by others that have achieved 9600. 9600 baud seems to be the absolute limit, however. So, even without a UART, some nice transmittal speeds can be accomplished thru code control.] Now that I have said all this, watch some line noise come in & mess up this posting..... :( ------------ WC.COLEMAN [GeoOp] 4800 baud is possible in fast mode if the term is pure ML (but it's a near thing)! 9600+ is possible for printer dumps & such where you are only going in one direction & little processing is involved. -WC ------------ EMJAY I used 9600 baud to transfer between my TRS Model 100 & the C=128 using a null modem, CS-DOS for the C=128 & a CRC XMODEM term program with the TRS 100. CS-DOS is the only C=128 terminal program that I know that has settings for more than 2400 baud. Am I mistaken?? I have no problems with these transfers. By the way, I use a Supra 2400 & it has never required any adjustment at all in any of the half dozen term programs that I use. It worked straight out of the box & with no changes to any prior terminal programs other than the change for BT for a Hayes. ------------ C128.CPM [Bill] Yup! CS-DOS is one of the few that can do 9600 Buad. My Supra worked great, out of the box, as described above. ------------ P.HALTON Howe, A uart, universal asynchronous receiver transmitter, is usually a hardware device which converts data from your terminal to a format that can be transmitted over a communications link. At regular intervals, it sends 1 bit of each character to the modem which puts that bit out on the phone line using either frequency or phase shift keying depending on the modem. The c64 doesn't have a hardware uart. To cut costs, they simulated the functions of the uart in software. That's the principle reason why they have so much trouble with timing sensitivity. But nontheless, it is there. It's simply written in software. simply written in software.