8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / SWIFTLNK.MSG.ARC / 00SWIFTLNK.MSGS next >

Wrap

Text File | 2019-04-13 | 33.5 KB | 803 lines

************ Topic 7 Thu Oct 24, 1991 C128.JBEE [* Sysop *] at 04:52 EDT Sub: Swift Link-232 Serial Cartridge A place to post questions, answers, comments, and suggestions for the Swift Link interface 180 message(s) total. ************ ------------ Category 12, Topic 7 Message 2 Tue Nov 26, 1991 C128.JBEE [* Sysop *] at 23:41 EST It is a cartridge. It is the size of a game cartridge and plugs into the expansion port. It has a 9 pin AT connector for a serial (ibm) modem cable. You can find more information in this category and also in CMD's full page ads in run. ------------ Category 12, Topic 7 Message 3 Thu Nov 28, 1991 CMD-DOUG at 22:03 EST Ditto on the 'it's a cartridge' part. The product is usually only available direct from us, as there is such a small mark-up on it that it is unattractive for sale through dealers. ------------ Category 12, Topic 7 Message 4 Mon Jan 06, 1992 B.ENNIS1 at 03:06 PST Is there any way of making the RS-232 cartridge more compatible with programs that don't have special programming? Are you guys going to release a program chip or something to help with the incompatibility problem? ------------ Category 12, Topic 7 Message 5 Tue Jan 07, 1992 C128.JBEE [* Sysop *] at 04:55 EST Doug is on vacation but I feel safe answering this one for him. There is no way to make the Swiftlink carridge compatible with programs that are not designed to take advantage of it. It either is Swiftlink compatible or it is not. The best thing to do is find a shareware or commercial program that takes advantage of the cartridge. There are probably close to a dozen GOOD programs that take advantage of the cartridge including Wizard64 and Wizard128. ------------ Category 12, Topic 7 Message 6 Sun Feb 02, 1992 CMD-DOUG at 20:37 EST This is pretty much as JBEE as stated it. While a different Kernal ROM could probably be produces with SwiftLink communications routines built into it, it is quite likely that would not be enough to make most terminal programs work with it - special programming would still be required. There are just too many different ways of going about utilizing the user port, and even if we somehow managed to trick the computer into using SwiftLink in every case, that would probably create compatibility problems with other software. Since nearly all the best and well supported terminal programs now have SwiftLink support, we suggest you look to these. ------------ Category 12, Topic 7 Message 7 Mon Feb 03, 1992 B.ENNIS1 at 23:40 PST It's mainly for my BBS program that I would like to have the ROMS. ------------ Category 12, Topic 7 Message 8 Mon May 04, 1992 B.LUCIER [bill l.] at 22:24 EDT I have a swiftlink-232 and today I was reading a review of it in Run magazine. It indicated that a rs-232 printer could be connected to my 128 with the swiftlink. Is this true? If it is what device number would it be? Would it still be 4. I want to buy a letter quality printer to print off resumes. It would be great to be able to use the swiftlink rather then buy another interface. Thanks Bill L. ------------ Category 12, Topic 7 Message 9 Tue May 05, 1992 HOWIE-CBM at 04:25 EDT Bill, Seems like it would work, except that I don't know of any software that will let you print that way. For the most universal compatibility I'd recommend using the Xetec Super Graphic jr., and printing to device #4 on the serial bus. An other option would be to use an interface like Omnitronic's RS-232, which can either connect to a modem, or a printer, using the User Port. However, not all software will address a printer this way either. Digital's Pocket programs will, and some others. Adding a printer buffer is a big convenience when doing lots of ascii text printing. It frees the computer for other activities. (For example, I have to print out batches of cards for each NYOUG meeting. Once the merged addresses are dumped, I can get on with other things, while my ole Epson slowly rolls out the cards. Some fancy ascii stuff in there takes time.) Howie ------------ Category 12, Topic 7 Message 10 Tue May 05, 1992 C128.JBEE [* Sysop *] at 14:45 EDT I agree with Howie and just want to throw in that Paperclip iii will work fine with a RS232 printer with the proper interface. ------------ Category 12, Topic 7 Message 11 Tue May 05, 1992 HOWIE-CBM at 19:22 EDT ha! JBEE's still try'n to get me to convert from my Pocket Writer3 to Paperclip iii... :) Howie ------------ Category 12, Topic 7 Message 12 Wed May 06, 1992 B.LUCIER [bill l.] at 01:03 EDT Ok thank Howie and Jbee...I thought that I might be able to save some coin...but it probaly would be easier to just get the interface.. Thanks.. Bill L. ------------ Category 12, Topic 7 Message 13 Wed May 06, 1992 C128.JBEE [* Sysop *] at 01:42 EDT ;) ------------ Category 12, Topic 7 Message 14 Sat May 09, 1992 CMD-DOUG at 11:25 EDT Yes, I'm not sure where RUN came up with that particular comment. While what they say is technically true, as others have mentioned there are no software drivers to support printing via the SwiftLink cartridge. ------------ Category 12, Topic 7 Message 15 Sun May 10, 192 CBM-ED [e.g.bell] at 22:48 EDT Wouldn't any package that already printed out to an RS232 printer work with a SwiftLink. If the interfaces you use for that now do no translation, seems like the SwiftLink would serve. >not an expert!< ------------ Category 12, Topic 7 Message 16 Mon May 11, 1992 HOWIE-CBM at 09:55 EDT Ed, The SwiftLink interfaces through the Expansion port. It can share it with a REU or other device like CMD's RAMLink. The SwiftLink lets the user determine which of the three possible addresses it will get assigned. I do not see any reason why a printer driver cannot use it. It is only that no one has written one, since no one ever asked for one before. I am pretty sure that all of the existing RS-232 drivers are pumping out their stuff to the other side of the computer. :) Howie ------------ Category 12, Topic 7 Message 17 Mon May 11, 1992 B.LUCIER [bill l.] at 23:01 EDT Funny... I wonder where run got that from. Maybe they know something the rest of us don't know. I think I'll drop them a line and see if they had a reason for making that claim. Later Bill. ------------ Category 12, Topic 7 Message 18 Tue May 12, 1992 CMD-DOUG at 01:56 EDT Most likely they made an assumption Bill... Howie is correct. All the current RS-232 drivers pump out via the User Port, often using Device # 2. SwiftLink would require special ML routines of its own. Anybody up to it? :) ------------ Category 12, Topic 7 Message 19 Wed May 13, 1992 B.ENNIS1 at 22:45 EDT Why doesn't someone write a modification to the Kernal so that when you OPEN a channel to #2 it will automatically go over to the Swiftlink rather than using the built in port? ------------ Category 12, Topic 7 Message 20 Thu May 14, 1992 CMD-DOUG at 11:39 EDT Any such modification would have to be done in the Kernal ROM itself, otherwise the chances of having it work with any terminal program would be slim. Such a thing might be somewhat useful to programmer who is creating his own software for use with SwiftLink, but since the speed of SwiftLink will often require machine code throughout the rest of the program anyway, it was assumed that such programmers would simply write their own drivers for it. ------------ Category 12, Topic 7 Message 21 Fri May 15, 1992 CBM-ED [e.g.bell] at 03:55 EDT I did work with the SwiftLink when it first came out to implement it in my terminal prg. They included a little wedge written by Dr. Evil LABS that snuggled into the NMI vector. Again, I am *not* an expert, but it sure seems to me like it would be quick work to do the same thing with a printer driver, maybe even using a terminal programs ASCII translation routines, or whatever. All of the Kernal i/o routines are vectored. I know I am rambling, but am I making sense? Just seems that if you can translate for the modem so easily, you could do it for a printer too, tho I don't see any real benefit to it. ------------ Category 12, Topic 7 Message 22 Sun Oct 04, 1992 CBM-ED [e.g.bell] at 15:33 EDT I have a question to ask someone at CMD... I have developed/implemented wedges for the SwiftLink now for the C64 and the C128. However, doing this for most people is impossible without some kind of documentation. I signed a NDA when I got my developers package. However there are new programs coming out that could benefit from the same information tho the 'development' is done. Would it be alright for me to release the data on programming the chips for use in terminal programs. Two examples are Intelligentsia BBS and VortexNet BBS, both for the c128, one of which, VortexNet, supports FIDO networking. I would like to help these guys, but not at the expense of violating anyone's rights. I do think it would be in in CMD's interest for me to do this, or for them to do it in PD. So, can anyone give me a greenlight to make this info available to the few programmers writing stuff that could use it? ------------ Category 12, Topic 7 Message 23 Sun Oct 04, 1992 CMD-DOUG at 21:17 EDT This info was never kept under non-disclosure after we took over. This had been done originally by Dr. Evil Labs since someone had been developing a competing product using the same hardware, and they didn't want the other company to have easy access to such code. The other cartridge never really presented much competition once we took over SwiftLink, and the programmers notes have been available from us for $5 ever since. That was pretty much to cover printing and shipping/handling. I had _THOUGHT_ that I uploaded ASCII text versions of the programmers notes, but after checking just now, I guess I didn't put them up here (must have only been on the CMD BBS). I just looked in my U/D area on my own hard drive, and I have only one of the two files that made up the ASCII version, so I'll have to locate the other, then I'll upload them. But as for you giving them to others, I don't have any problem with that, no. ------------ Category 12, Topic 7 Message 24 Mon Oct 05, 1992 F.OGLE [Fred Ogle] at 20:39 EDT Thaks, Doug - My partner, Anthony Tolle (the primary programmer for Color64 bbs) would mucho appreciate any notes. ------------ Category 12, Topic 7 Message 25 Tue Oct 06, 1992 CBM-ED [e.g.bell] at 10:38 EDT Thanks Doug. And Fred, since Greg was one of the original developers, he may have the notes already in whatever he passed along to you. Doug, your mention of availability of the notes is the first I ever heard of it, and I am going to recommend that route for those interested on FIDO. Heck, I'd like to see your files myself if you upload them, tho I hve gotten my stuff finished and finally an understanding of what it is I did. Hopefully it will make things easier for anyone developing stuff now. BTW, the HART cart was a VERY different ballgame than SwiftLink, if that is the one you are referring to. Programming it is a whole 'nuther ballgame. They use a true UART and a dual set of registers for xmit and receive. For what it is worth, SwiftLink is a world easier to work with, and I have both, so I know what I'm talking about. Thanks! I'll pass the info along immediately. ------------ Category 12, Topic 7 Message 26 Tue Oct 20, 1992 K.SULLIVAN6 [Kent] at 03:54 EDT Greg Pfountz definitely did have the SL-232 developer's notes at one time-- I sent them to him. He actually sent us the code and we had a look at it. To be frank, it is going to be a serious challenge to get it to work (esp. work *well*) with the SL-232. So much of his basic I/O was fragmented (partially ML, partially BASIC) that large sections really needed rewriting in order to remove bottlenecks that were sure to occur once the throughput went up (due to the SL-232 and higher baud rates). . Doug was right in spirit about the reason for the NDA for the developer's notes--we didn't want to let the cat out of the bad about what we were doing until we were sure it was going to get done. We knew the HART used a different chip; we just figured a NDA was a good all-around precaution to keep the lid on things until we were ready to announce. . Kent (former GM of the former Dr. Evil Labs) ------------ Category 12, Topic 7 Message 27 Fri Oct 23, 1992 B.ENNIS1 at 21:43 EDT A local sysop here would like to ask Kent a question. He wants to know if he knows of any Swiftlink compatible drivers that are under develope- ment for C- Net 128 either by Dr. Evil, or by Perspective Software (which writes C-Net). ------------ Category 12, Topic 7 Message 28 Sat Oct 24, 1992 CBM-ED [e.g.bell] at 00:12 EDT Isn't CNET user adjustable. The interface for SwiftLink is laughably small... it is just a whole new NMI interface, but very small because everything bitlevel is done by the chip. Doug Cotton has already said a developers sheet can be had from CMD for $5 to cover postage and copying. That would be the route I'd suggest. At this late date, I'm surprised CNet hasn't already implemented it. ------------ Category 12, Topic 7 Message 29 Sat Oct 24, 1992 CMD-DOUG at 00:55 EDT Perspective Software South (current developers of C-Net 128) have indeed expressed interest, and I believe they have the info. I think they had hoped to get it into v6.0, but it was a bit too late by the time they considered it. ------------ Category 12, Topic 7 Message 30 Sat Oct 24, 1992 F.OGLE [Color 64 BBS] at 17:00 EDT Kent - Yes, we have all the stuff from Greg [even your handwritten note :) ] , and as far as Color 64 goes, the ML has been entirely re-written for v8.0 (originally, our ml + overlays were simply an upgrade package, available ONLY to existing owners of Color 64 BBS, and out of the blue, Greg Pfountz asked us (Anthony Tolle and myself) if we were interested in "taking over" Color 64, since he was ready for a break - He also stated that he thought our upgrade should be the next version of Color 64, and that with his free time dwindling, along with mine and Tony's commitment to Color 64, it was an opportune time for a "passing of the guard".). The only reason that the SL compatibility won't be offered with the current version is simple; Our SysOps have been waiting a LONG TIME for an upgrade, and we feel that the additional wait will seriously discourage some SysOps - We will, however, begin FULL IMPLIMENTATION of Swiftlink compatibility with the version immediately following v8.0. Fred Ogle ------------ Category 12, Topic 7 Message 31 Sat Nov 14, 1992 M.BARNETT4 [BUBBA] at 20:55 EST I have the SL and use it with my SupraModem when the Amiga isn't hogging it. My question is can I connect the Amiga and C=64 together through the SL cartridge and transfer data between the two. My reason for wanting this is that Aladdin for the Amiga is much quicker and easier to use than Wizard for the '64. I'd appreciate any feedback. Bubba ------------ Category 12, Topic 7 Message 32 Sun Nov 15, 1992 C128.JBEE [* Sysop *] at 01:55 EST Rob answered this question in Category #8! ------------ Category 12, Topic 7 Message 33 Sun Nov 15, 1992 CMD-DOUG at 20:11 EST Yes he did, and I saw it, but out of courtesy I'll also reply. Yes, you can. Just use a null-modem cable or adaptor between the SL and your Amiga. Use terminal software on each end set to the same speed and parameters. You can then transfer files using whatever file transfer methods that the two programs can agree upon. :) ------------ Category 12, Topic 7 Message 34 Thu Nov 19, 1992 R.NEAZER [ReubN] at 22:04 EST Is swiftlink compatible with Aprotek C24 modem? Reub....... ------------ Category 12, Topic 7 Message 35 Fri Nov 20, 1992 CBM-MARK at 01:06 EST The Swiftlink cartridge plugs into the C64 or C128's cartridge port and is an interface between the C= and any IBM compatiple external modem. So no, it can't be used with the Aprotek C2400 modem since that one is already fuly compatiple with Commodore computers by being able to plug directly into the user (modem) port. ~~Mark~~ ------------ Category 12, Topic 7 Message 36 Sat Nov 21, 1992 M.BARNETT4 [BUBBA] at 09:26 EST Thanks Doug. I was wrong. There are four people on this board.=) Bubba ------------ Category 12, Topic 7 Message 37 Fri Nov 27, 1992 C128.JBEE at 00:22 EST Topic 20 Mon Nov 23, 1992 L.BAILEY9 at 04:33 EST Sub: Swiftlink and Image BBS Are there any mods available for Image V1.2 on the C128 to use the Swiftlink Cartridge? If so, where can they be obtained? 2 message(s) total. ************ ------------ Category 12, Topic 20 Message 1 Mon Nov 23, 1992 L.BAILEY9 at 04:35 EST Any help would be appreciated. Also, if anyone is looking for a 64 BBS program that supports Swiftlink, DTJ BBS does. ------------ Category 12, Topic 20 Message 2 Thu Nov 26, 1992 CMD-DOUG at 04:37 EST To my knowledge, Image never released the SwiftLink mods they wrote, but a couple boards were running them. Think they avoided a release because it required changes in one of the serialized files, so that would have meant generating a new file for each registered owner who wanted to run with SwiftLink. That is only a guess on my part, though, and you'd have to ask the Image folks themselves for the real reason. ------------ <moved from Cat12 topic 20> ------------ Category 12, Topic 7 Message 38 Sun Jan 24, 1993 AMFORD at 11:29 EST Just got my Swiftlink and began playing with it. My setup is C128, ramlink (4meg ramcard), 512k REU, and Swiftlink. And I think that I have lost my ability to use the REU as a direct accessed buffer from within Dialogue 128. Is that correct, or do I have to change options? I normally had the RL normal/direct switch set to direct, but to use the Swiftlink, it has to be set to normal. Correct? ------------ Category 12, Topic 7 Message 39 Sun Jan 24, 1993 C128.JBEE at 18:00 EST Correct, you can not use the REU and S/L at the same time within the Ramlink, though some people use them both at the same time by using one of those cable/cartridge expanders. ------------ Category 12, Topic 7 Message 40 Mon Jan 25, 1993 CMD-DOUG at 00:23 EST Correct, just as JBEE stated. When in DIRECT mode, RAMLink switches off some control lines on the PASS-THRU port while activating those lines on the RAM port. This was done to avoid conflicts between cartridges using the same address space. Hardware hackers have also simply used jumpers to connect those lines on the two ports to get around this (an REU and SwiftLink CAN co-exist peacefully). Just don't try this if your RAM port holds a GEORAM. ------------ Category 12, Topic 7 Message 41 Thu Feb 18, 1993 CAPT.CARL [Carl] at 03:24 EST ::duh mode:: Lemme get this straight.. my little C=64 can modem at 9600+ baud by using Swift Link and the proper modem/terminal? (pardon my ignorance, the very existence of SL just came to my attention) --- Carl ------------ Category 12, Topic 7 Message 42 Thu Feb 18, 1993 CBM-ED [e.g.bell] at 08:35 EST yes, Carl, the C64 will handle 9600 with the SwiftLink, and up to 38,400 if you want to use null-modems for intercomputer transfers. The SwiftLink is an ACIA chip (6551) in a cartridge that performs the bit-level rs232 operations, cutting down interrupts required for a transmitted/received byte from thousands to just 1. There are several terminal programs that support the cartridge including NovaTerm, Terminal 1, and BellTerm, all for the C64. ------------ Category 12, Topic 7 Message 43 Thu Feb 18, 1993 CMD-DOUG at 21:07 EST Thanks Ed, for filing that reply. Now I'm wondering if any of the current 64 terminal programs that support SwiftLink will also allow for RTS/CTS handshaking, since using the latest batch of 9600 baud modems with v.32/ v.42bis will actually allow you get up close to that 38,400 baud mark through the modem's 4:1 compression. I've been doing this on the 128 with Dialogue 128, and the speed is, well, breathtaking. At those rates it no longer looks as if you're telecommunicating... looks just as if you were running a program on the computer with the screen being updated apparently just about as fast as the computer can print it. ------------ Category 12, Topic 7 Message 44 Fri Feb 19, 1993 CAPT.CARL [Carl] at 00:39 EST Thanks for the info.. I'm sold. I don't wish to get off-topic, but can you, Ed, Doug, or anyone, recommend a high speed modem that works well with Swift Link, or at least tell me what your own setup is? ------------ Category 12, Topic 7 Message 45 Fri Feb 19, 1993 CMD-DOUG at 01:22 EST I'm using the SupraFAXmodem 9600 v.32/v.42bis model. It sells for around $300 without the extra bells (sorry Ed!) and whistles such as Caller ID and Silent Answer modules. There is also a v.32bis model that can manage higher connect rates, but I personnally don't see the need, and from all I've heard it isn't quite as reliable as the straight v.32 model. ------------ Category 12, Topic 7 Message 46 Fri Feb 19, 1993 CBM-ED [e.g.bell] at 07:32 EST I am using an Supra 2400... the old kind, that now sells for between $80 and $100. I would like to go to 9600 or 14,400 or higher, but to be honest, there is no where I could use it even if I had it. 2400 is nice compared to 1200 though, and the price is right. I've never had a bit of trouble with my modem and have been using it for years, and Supra is a good name. ------------ Category 12, Topic 7 Message 47 Fri Feb 19, 1993 CAPT.CARL [Carl] at 19:44 EST Again, thanks! I've got some shopping to do. :) ------------ Category 12, Topic 7 Message 48 Sat Feb 20, 1993 F.OGLE [Color 64 BBS] at 00:03 EST I like Supra too -- I use the same modem that Doug does, and will be upgrading to the 14,400 baud ... Nothing beats the speed, and you'll be surprised at how much you love it! ------------ Category 12, Topic 7 Message 49 Sat Feb 20, 1993 HOWIE-CBM at 02:56 EST Well, I cannot explain the `why' of it, however, when connecting to CMD's BBS at 2400 it just seems too fly. Go figure? :) Howie ------------ Category 12, Topic 7 Message 50 Sat Feb 20, 1993 C.OGLE2 [breadstick] at 20:33 EST CMD'S BBS? Does this mean it's back up? Last I heard they were still waiting on the Software... ------------ Category 12, Topic 7 Message 51 Sat Feb 20, 1993 CMD-DOUG at 23:58 EST It is back up, yes, but I've been avoiding announcing that fact officially until we can shake the system down a little for any possible problems, get the libraries and info files in shape, and get a module installed that we are still waiting on which will assist users in giving us the info we need to get them the proper access quickly. Keeping in mind that we're not quite done with all of those objectives, it is online and available to call. The HD, FD, RL and RD libs are ready and usable, about half the text files are in place, and validation may take a couple days with the way things are. The number is the same as it has always been, as listed in most of our manuals. ------------ Category 12, Topic 7 Message 52 Tue Feb 23, 1993 HOWIE-CBM at 00:14 EST Did I put the horse before the cart? Forget to close the barn door? Spill the beans? All of the above? None of the above? :/ Either way, CMD's BBS is *SUPER* fast responding. :) Howie ------------ Category 12, Topic 7 Message 53 Tue Feb 23, 1993 CBM-ED [e.g.bell] at 02:51 EST Doug: Kent Sullivan finally replied to my Email wrt the SL and a transmit buffer, and he kind of referred me to you. But he seems to be saying the same thing that you did... that no one has really had success with an output buffer... I am wondering about it... The docs say a transmit interrupt is signaled (or triggered???) when one of the bits of one of the registers is toggled on... don't remember which. However I have not been able to figure out how a user could trigger an interrupt by tripping a bit. Here is the idea I am toying with now... Use the normal NMI stuff to process incoming bytes. Use the IRQ to send bytes, using the transmit buffer pointers as the irq 'flag'. I believe it should work. I have had limited success using an output buffer based on Kents wedge, but it seems to get contrary when dialing the modem. I believe a transmit handler in the system irq wedge would do the trick, not relying on an interrupt but rather a condition (start of buffer < end of buffer) to continue sending. This would also be easily toggled off. I know there is a bit in one of the registers to enable transmit interrupts. I just wish I had the information on exactly what happens when this bit is set. ------------ Category 12, Topic 7 Message 54 Tue Feb 23, 1993 CMD-DOUG at 22:23 EST I'm afraid I won't be much help here, Ed. With all due respect to Kent, his comment that we (CMD) are more up to date on programming SwiftLink is far from correct. We took it on as a 'canned' product, and our own experimentation with the device was limited strictly to writing a more efficient test program to assure that new units worked correctly. Other than that, our only information on the programming aspect has been what little feedback we've had from authors such as yourself trying to implement SwiftLink support in one way or another. I think that perhaps the 6551 spec sheet might shed a 'little' light on the use of the bit you mention, and will check for that. I'll also talk to a couple of the other programmer's I know who have implemented SwiftLink to see what I can find out about any attempts to use an output buffer. But reading between the comments I've had from Kent and authors during the time we've had this product, it sounds like no-one has had much luck with an output buffer, perhaps because of quirks in the way the 6551 operates. ------------ Category 12, Topic 7 Message 55 Thu Feb 25, 1993 CBM-ED [e.g.bell] at 03:00 EST I'll let you know today how I make out, Doug, wrt the SwiftLink transmit buffer, but to recap, here is what I'm doing... My RSOUT routine is not in any kind of interrupt code. It is just a routine that buffers the character (doing translation if specified). My IRQ routine 1] Checks to see if it the SwiftLink is being used via a flag set at start up, 2] checks to see if the start pointer of the output buffer is equal to the end pointer. If those conditions are met, the register is polled to see if the chip is ready to send the byte. If all of these conditions are met, the byte is sent, otherwise the irq continues, checking next time through again to see if the byte can be The code is in... I just need to test it, but I can't see any reason why it will not work, and since it *is* interrupt driven, the problems I had before will hopefully be resolved. Here's hoping! ------------ Category 12, Topic 7 Message 56 Sat Feb 27, 1993 CBM-ED [e.g.bell] at 01:53 EST First returns are not encouraging... I am starting to think the chip cannot handle data at the rate it is pushed into the chip register. Does that make sense? I need to know what happens when transmit interrupts are enabled... exactly! It seems from what I can see of the paperwork I have that the interrupt bit is maintained partly by my code (when I send the first byte to the buffer) and partly by the NMI, when a byte is received, the interrupt is maintained IF the buffer indices are not equal. The problem that strikes me, unless I am reading things wrong, is that the only time a byte will be sent is when a received byte triggers an NMI interrupt UNLESS setting the interrupt in the chip register forces an NMI interrupt continuously so that transmit bytes may be processed. My concern, based on what I have observed since I reimplemented the transmit buffer in my Rs232 code (George Hug's wedge), is that the rs232 code is much 'quicker'... then the transmitted code from the SwiftLink... noticeably so. The incoming data is very nice, but the SwiftLink does not seem to be operating as fast as it could on the outbound part. To get the package you mentioned before, do I just send $5 to CMD, or what. I am thinking of going back to Kent Sullivan too for some more detail on this transmit interrupt. I wonder if I could get in touch with Noel Nyman too... he was the electronics guy behind that wasn't he? Do you know, and would you have any idea how I could get in touch with him? ------------ Category 12, Topic 7 Message 57 Sat Feb 27, 1993 HOWIE-CBM at 02:44 EST Ed, You can reach Noel Nyman on INet at 71350.3376@CompuServe.COM. However, I suspect that Kent would know more about these things. And, speaking of Kent and Noel have you examined the new version of Kermit, the one especially written for running with a SwiftLink? While Kermit protocol is not the fastest, this may offer some insights. Howie ------------ Category 12, Topic 7 Message 58 Sat Feb 27, 1993 CBM-ED [e.g.bell] at 10:26 EST got an update on this SwiftLink stuff.... and it does seem now to be a limit of the chip as to how much data can be sent to it quickly. I have a mode in RTCMaster that sends data as it is typed instead of buffering it and sending the whole buffer (1 character at a time of course). Anyway, my transmit buffer routine works fine with this... Obviously I can't type at machine language speed, and that seems to be the key. Now, does this seem to make any sense to you Doug? I mean is it possible that the chip just can't handle streams of data going to it on an interrupt type basis. I would have thought that the bibit that signalled the chip was ready would have been enough for it. It seems kind of ironic, if it is the case, that the chip that has allowed such phenomonal reception rates hits the wall when the host tries to send out a stream of data. :( ------------ Category 12, Topic 7 Message 59 Sat Feb 27, 1993 CBM-ED [e.g.bell] at 11:27 EST Got the end of the story Doug... I am now using my SwiftLink with a transmit buffer and I know where the problem has been. The problem is only present when there is no carrier, and all that is needed to fix it is to put a little delay loop in the RSOUT routine when no carrier is present. I'm on with it right now at full steam. I used a script to log on, and previously tested it with a keyboard entry. I am going to test now for the lowest possible delay setting. I will also have to add it to my Hug wedge code to avoid having a delay accumulation from routines that did not expect it in the output routine previously. But this is very good news at least for me. ------------ Category 12, Topic 7 Message 60 Sat Feb 27, 1993 CMD-DOUG at 12:55 EST Ed, How is it that you manage to answer your own questions before I even get a chance to read them? :) As for your earlier speculations, Noel is much more technically knowledgable about how the SwiftLink operates. Kent was pretty much the general manager of Dr. Evil, and was more concerned with the business end of things - not to say that Kent didn't have technical knowledge, just that the business aspect kept him from getting as involved in writing code and such. Shame we can't have someone like Noel online here, as his expertise in MANY areas would be a real plus for us all. ------------ Category 12, Topic 7 Message 61 Sat Feb 27, 1993 CBM-ED [e.g.bell] at 17:32 EST As I said, Doug... I figured Noel was the guy to ask. I met him and Kent both at a WOC in 1990. Kent is sharp, but I know from all of the stuff I have read over MANY issues of the old Transactors that Noel was the guy to talk to. On the other hand, I have the problem solved do the whole thing is moot. I'll clean up my code and upload it to PD so you can have it for your disks if you want and other developers can skip the hard part and move to things they would rather work with. I am just EXTREMELY happy I got it fixed! ------------ Category 12, Topic 7 Message 62 Sat Feb 27, 1993 CBM-MARK at 22:29 EST WOW, Ed!!! You must be extremely pleased with yourself! I know I would be if I were you, coming up with code nobody else has been able to. Congratulations!! :D ~~Mark~~ ------------ Category 12, Topic 7 Message 63 Sat Feb 27, 1993 CBM-ED [e.g.bell] (Forwarded) Wow! That sounds GREAT if it can be worked out. I will have the code ready I believe in a day or so and will upload it for you into your lib to do with as you see fit! I'll just have to document it totally, tho it is already pretty well commented. Thanks if it works out like that!!! ------------ Category 12, Topic 7 Message 64 Sat Feb 27, 1993 CMD-DOUG (Forwarded) ~