8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / 01CAT8MSGS.SFX / 02cat8msgs next >

Wrap

Text File | 1990-02-12 | 32.7 KB | 753 lines

************ Topic 16 Thu Oct 08, 1992 R.BRYAN10 (Forwarded) Sub: ZMODEM overlay for Desterm 2.00 I am looking for a ZMODEM overlay for Desterm 2.00 or someone who knows how to make same. I need to do multi-file transfers to an Amiga board for the Minnesota Commodore Users Association which I am vice president of, to use on our DOM 36 message(s) total. ************ ------------ Category 8, Topic 16 Message 1 Thu Oct 08, 1992 R.BRYAN10 (Forwarded) Can anyone help with an overlay to Desterm 2.00 which enables ZMODEM protocol multi-file transfers? I am trying to use an Amiga BBS in my region to sendfiles to the library of the MCUA user group. The BBS only will allow me to upload multi-files using ZMODEM protocol. Trying to send XMODEM one at a time is simply too time consuming. Does such an animal exsist or can it be written? Where do I begin? Leave mail for me on GEnie RBRYAN10 if you can help. Thanks... *** RCB *** ------------ Category 8, Topic 16 Message 2 Thu Oct 08, 1992 C128.JBEE [* Sysop *] (Forwarded) Zmodem isn't currently available on the Commodore computers using any terminal program. BTW:this topic will be moved to Cat#8. ------------ Category 8, Topic 16 Message 3 Sat Feb 27, 1993 R.BRYAN10 at 00:57 EST ------------ Category 8, Topic 16 Message 4 Sat Feb 27, 1993 CBM-ED [e.g.bell] at 20:54 EST At present, there is no Zmodem overlay for any 8 bit Commodore computer. I wonder sometimes if Matt is not developing one, only because of the enormous amount of time that has elapsed since the last release. It is something like 2 years since DesTerm 2.00 was released. Maybe longer. As I recall, DesTerm 2.00 was released about the same time the SwiftLInk cartridge was introduced. However, if you are interested in doing batch uploads, Ymodem would definitely be the ticket. However there may still be a snag. The only software that I know of currently that lets you do batch uploads is DLG for the Amiga, and ironically, DesTerm has problems uploading to this bbs, I suspect because Matt and Geoff decided that it was 'silly' to include a filesize in the header. (BellTerm works with this software to do batch uploads, but it is for the C64) ------------ Category 8, Topic 16 Message 5 Sun Feb 28, 1993 C.OGLE2 [breadstick] at 23:01 EST Don't forget Z-Modem for the 128 in CP/M mode. I personally haven't used it, but have heard good things about it... ------------ Category 8, Topic 16 Message 6 Mon Mar 01, 1993 CBM-ED [e.g.bell] at 00:08 EST I have told people about this and they refuse to believe me, but this has been around as far back as 1990.... tho I hear it is SLOW! ------------ Category 8, Topic 16 Message 7 Tue Mar 02, 1993 B.ENNIS1 [Torby] at 05:08 EST CP/M is slow... ------------ Category 8, Topic 16 Message 8 Wed Apr 07, 1993 MIKE.DUNCAN at 21:50 EDT CP/M on a Commodore 128 is slow. ------------ Category 8, Topic 16 Message 9 Thu Apr 08, 1993 R.KNOP1 [Rob Knop] at 01:24 EDT CP/M on the 128 as shipped by Commodore is a lot slower than it has to be. There are a bunch of real simple improvements you can make to substantially improve your system performance. (See Twin Cities 128 issue #28 for an article about that.) Also, if you take the time to install BIOS-R6, ZPM, and ZCCP (all in the libraries here), the system performance will get even better. -Rob ------------ Category 8, Topic 16 Message 10 Wed Sep 08, 1993 G.CORREA [RAMRunner] at 21:53 EDT I have not had any success in getting ANY implimentation of YMODEM on a Commodore to fly on an Amiga BBS- the BBS software tends to use external protocol modules (XPR's) and there's something funky with the YMODEM XPR and Commodores. I have yet to see any explination on the subject, the local sysops just shrug and say I Dunno... ------------ Category 8, Topic 16 Message 11 Wed Sep 08, 1993 CBM-ED [e.g.bell] at 23:26 EDT I believe the solution is what I recently posted on a local board... most of the terms do not send a file size in the header packet. RTCMaster and BellTerm do, and thus work with Amiga BBS's. DesTerm and NovaTerm do not. (I know this from personal experience about DesTerm and have heard it about NovaTerm). The Ami protocols expect this parameter passed in the header packet when spec only says it is optional. I bet you would find Ed Parry's term works with it also. ------------ Category 8, Topic 16 Message 12 Wed Sep 08, 1993 R.MURPHY1 [Maharishi] at 23:32 EDT As of the present there are no known ZMODEM protocols functioning in the C64 or C128 platforms although there might be for the AMIGA. RAMRunner, You neglected to mention whether or not you are trying to upload or download to/from the Amiga. I have used YMODEM quite a bit and have only experienced problems on a local VBBS system but that was corrected when I selected a different YMODEM protocol available on the host. Murphy ------------ Category 8, Topic 16 Message 13 Thu Sep 09, 1993 G.NOGGLE [Greg] at 22:41 EDT There are lots of zmodem term programs for the amiga greg ------------ Category 8, Topic 16 Message 14 Thu Sep 09, 1993 CBM-ED [e.g.bell] at 23:23 EDT There is no Zmodem overlay for DesTerm. RTCMaster will do batch transfers to an Amiga BBS, either uploaded or downloaded. ------------ Category 8, Topic 16 Message 15 Wed Oct 06, 1993 D.SCHWARTZ at 04:20 EDT I have a ZMODEM source code for the C-64 that allows RECEIVEING of files only. Someone cross-assembled it from an MS-DOS source into 6510 source and claims that it works, but has some bugs. Still, it would be a nice start for anyone thinking of trying to write a fully operation Z-MODEM for the C-64 or C-128! I'm surprised that noone has developed one yet! It is the nicest transfer protocol I have ever used! Wanna hear something sad?!... I was reading messages in the Atari 8-bit message bases and they have Z-MODEM for the Atari 400/800 computers which have been out of production for years!!! Sheesh!! If I knew enough about protocol programming, I'd try it myself, but it seems that most of the source codes out there are written in "C"... ------------ Category 8, Topic 16 Message 16 Wed Oct 06, 1993 CBM-ED [e.g.bell] at 08:12 EDT Derek: DS> ZMODEM source code for the C-64 that allows RECEIVEING of files DS> only. We have that on GEnie, and I have already listed it out and studied it. None of us on staff could get it to work with GEnie (of those who tried) so I suspect that there is something that GEnie is insisting on that this implementation does not support. I don't know if anyone is going to do this protocol. It is probably nice for the bigger platforms, but not as great on the 8 bits, even if it was easy to do, because our files are smaller. The overhead on Zmodem is actually more per packet than the other protocols even tho the receiver does not ack them. There is a lot more to the CRC that comes from the sender than in any of the other protocols, the idea being that the ack/nak packets need crc protection too. If I could have gotten that code to work, I would have worked at getting it to work w/the 128. However, I kept getting an 'unsupported feature' message... something like that. ------------ Category 8, Topic 16 Message 17 Wed Oct 06, 1993 THE.OUTLAW at 15:39 EDT Another option (if possible for you) is a terminal to terminal file transfer using Y-Modem. I've done it several times using Desterm and a friend using Dialogue. I don't know how it would work with an Amiga. I imagine the same. ------------ Category 8, Topic 16 Message 18 Fri Oct 08, 1993 D.SCHWARTZ [FORBIN ONE] at 03:19 EDT Sorry, I just realized that it was on here after I wrote that message. Well, I'm glad that someone got it assembled, because I couldn't seem to! When I was calling Amiga boards with my A-500, I don't think I would have EVER used another protocol unless ZMODEM wasn't supported by the BBS. The thing that I thought was the best about it was the you could set your terminal to AUTO ZMODEM mode so that the BBS would send a control string that would make your terminal automatically jump to receive mode without you having to give any commands to your terminal program!! I got spoiled and found that ZMODEM was the main thing I missed when I threw my malfunctioning A-500 in the corner and went back to my C-128... I have been looking everywhere for someone who is working on a ZMODEM source and know of only one person: A local SysOp who is selling a BBS program called Supra-128. He let me know (just to annoy me) that he is working on a ZMODEM protocol for his program and he's keeping all the results secret. He said that he got it to receive but hasn't perfected the send part, so I was guessing that he was using that cross-assembled source code as a base. Since he was asking all his users to upload source codes from any other 6502- based system, I guess he could have found another way... ------------ Category 8, Topic 16 Message 19 Fri Oct 08, 1993 CMD-DOUG at 22:37 EDT Well, I guess if he keeps it a secret, you won't have to worry much about being able to use it unless he's going to provide you with a terminal program as well? ------------ Category 8, Topic 16 Message 20 Thu Oct 14, 1993 D.TUOMI [Doctor] at 03:07 EDT Currently the author of the BBS program OMNI-128 has been working on Zmodem for the 128. It's somewhat difficult to impliment on the 128 due to the fact you can't have drive activity and modem activity going at the same time. This precludes the use of file streaming mode which is one of Zmodem's chief advantages during long files. As for the problem with GEnie's Zmodem send, I would suspect it's because GEnie is being ran over a packet service. So, Zmodem's packet sizes would be smaller, like 512 bytes instead of 1024 bytes. If the Zmodem protocol doesn't support the change in packet byte size or if it's timing tempermental, then it could cause a failure in the protocol. As for all this, I might be wrong. Protocols are not my speciaty. However, after running a board for a number of years, one gets accustomed to how they're used. And you're right, most people prefer Zmodem. I can't stress to the authors of terminal programs and BBS's for the Commodore more to stop making excuses and start making a working version. Even if there is no advantage to it, or if it would be slower with our small file sizes. People here that this is the protocol to use, and if it's not there you're in trouble. (that is hear as in listening as opposed to here as in where) Doc. ------------ Category 8, Topic 16 Message 21 Thu Oct 14, 1993 CBM-ED [e.g.bell] at 07:11 EDT Doc: DT> you can't have drive activity and modem activity going at the DT> same time. This precludes the use of file streaming mode That is a big problem with it. Some people have suggested the use of faster devices and buffering to RAM. In some cases, this could capture the whole file w/o ever having to go to the drive. Streaming is never 'precluded' because of the fact that Zmodem recognizes Xon/Xoff flow control. I'm talking about streaming in the sense of not having to wait for an ACK from the receiver for every packet. DT> I would suspect it's because GEnie is being ran over a packet DT> service. So, Zmodem's packet sizes would be smaller, like 512 DT> bytes instead of 1024 bytes The pacekt service I can't comment on, but the 512 byte packets are the recommended size of Zmodem packets at 2400 baud if memory of the specs serves me right, particularly at baud rates at or above 2400 baud. There are tables in the document with recommended baudrates. DT> stop making excuses and start making a working version. Even if DT> there is no advantage to it, or if it would be slower with our DT> small file sizes. I dallied with it briefly once or twice. But you should realize that 'making excuses' to one person is 'reasonable explanation' to another, and the latter is going to be how those who would be doing the work are more likely to see things. The authors who have written the term programs to this point have been woefully unrewarded, including DesTerm. The small reward in terms of speed and advantage that you mention would come at an immense cost in terms of time. Someone may do this. I know that years ago it was implemented on the CP/M side. The author who has taken up the upgrades of DesTerm, Steve Cuthbert, has openly stated that Zmodem will be done for DesTerm. I hope he does it, but I have seen many people make the same claim over the last few years. There must be a good reason it has not yet been done. The people clamoring loudest for it are people who don't have to write and debug the code. I understand that. Perhaps someone will do it. Wonder then if they will release it to PD like Steve Punter or Ward Christensen did, particularly a BBS author who has something to gain from doing that, but my bet would be that they don't. ------------ Category 8, Topic 16 Message 22 Fri Oct 15, 1993 D.BURR at 00:57 EDT Well, I must admit that ZModem doesn't really thrill me as a feature. Sure it is the defacto standard now, but something else will displace IT at some time too. Heck, if you want truly universal transfer capability then Kermit is it in the Internet world. From a 128 users perspective, Zmodem offers me no major advantages that I can think of. Ymodem-batch at 14.4k is more than satisfactory for my needs. Zmodem would be an added plus, sure, but not the most valuable thing. I fear many of us C= users get wrapped up in PC-envy; they have it so we want it. It's a compensation syndrome ;) ------------ Category 8, Topic 16 Message 23 Sat Oct 16, 1993 D.TUOMI [Doctor] at 07:13 EDT As I stated in my text, I'm not an expert on the programming of protocols. However, I feel that if Zmodem could be implimented on CP/M and even the 8088 XT's, which have many of the same limitations as the 64's and 128's in terms of speed and hardware difficulties, then I feel that the 64 and 128 are capable of having a version implimented for them. As for my personal complaints, I'm more hopeful for a BBS program which supports it than a terminal program. WHile the average terminal user can get by on Ymodem Batch, the BBS sysop has to listen to his whining 12 year old users whose mommy and daddys have bought 486 66 mhz machines for. As for the purely problematical (is that a word?) I think that the general implimentation allows for a non-streaming mode which acts very similar to Ymodem. Basically, waiting for the ACK 'sHowever, I might be wrong on that. I've read the notes for Zmodem, but I can't say to fully understand them. I do know that packet problems over PC Persuit make Punter C1 unstable. So, it's possible that the alpha version of Zmodem for the Commodore might encounter similar timing problems when using GEnie. As for the compensation. Programming is the least appreciated and lowest paid part of the industry. Even on the PC, many shareware programmers have a lot of difficulties recouping their investment in time on a program. It's no surprise that a smaller market like the Commodore would be even tougher. I can only say that there are many things that are done in this world, not because they are overwhelmingly profittable, but often because there is a need in the world for it to be done. There is a need in this world for continued support for the Commodore machines. I tell my user group to support the authors that are left, but it's difficult for many of them. The don't relize that if you were to download the same program (or a similar one) for the PC that it would be crippled in some way, while the Commodore versions are working. It's hard to remember the authors of the programs you take for granted. At least, until they're gone. Doc. ------------ Category 8, Topic 16 Message 24 Sat Oct 16, 1993 CBM-ED [e.g.bell] at 08:41 EDT Doc: DT> more hopeful for a BBS program which supports it than a DT> terminal program Perhaps someone will. IMO, it would serve a person who wrote such an animal to immediately release the source code to public domain. I can see a terminal program author not doing that, but a BBS prog author it seems has a vested interest in widespread circulation. DT> general implimentation allows for a non-streaming mode which DT> acts very similar to Ymodem. Basically, waiting for the ACK ' That is correct, and in such an implementation, it would be noticably slower than Ymodem batch because there is a LOT more overhead involved in the ACK packet for Zmodem than in the ACK byte for Ymodem. DT> a need in this world for continued support for the Commodore DT> machines Yes, but not really a *need* for Zmodem. The main advantage in it is not the streaming, but the ability to resume a failed file transfer. However, this is easier in PC DOS than in CBM DOS if I understand things correctly wrt to EOF pointers in MS-DOS. By the time you synch the file positions, you negate the benefit of Zmodem. I'm inclined to agree with the earlier post mentioning 'PC Envy'. That is a nice turn of a phrase. If I had the 6502 source code, I'd implement it. Your point about the CP/M version is not quite valid. The source code for Zmodem has long been available in C, and is apparently more easily ported to that operating system. Given that type of situation going in, it was obviously easier to port over in CP/M. If Zmodem had been written sooner, when there were still all of the power programmers working on the 8 bits, it would be here now. Most are gone, many for the reason you mention... no support. ------------ Category 8, Topic 16 Message 25 Mon Oct 18, 1993 F.OGLE [Color BBS] at 20:48 EDT Zmodem will probably never be a priority for Color bbs -- Too much development time with too little return. Ed is right, Ymodem batch at 14,400 bps is fine, and frankly, if you were to get booted while a 1,000 block (256K) were being downloaded, re- downloading it would only take 10 (or so) minutes. The way I see it, the smaller file sizes the 64 & 128 make Zmodem even less of a factor... Just my two cents :) ------------ Category 8, Topic 16 Message 26 Tue Oct 19, 1993 D.TUOMI [Doctor] at 04:21 EDT I think the reason for the popularity of Zmodem isn't because of its superiority as a file transfer protocol. Why it's so popular is because it's easy to use. Once setup, Zmodem can automatically initiate transfer, without user intervention. If anything goes wrong, you can call back next time and get the rest of the file. I think there is as much a need for the ease and flexibility of Zmodem on the Commodore as there is for any other computer. As for the purely practical concerns of how the protocol would operate on the Commodore I have a couple of suggestions. Now, I'm not an expert, so these might not be completely reasonable. However, in my view you could impliment a streaming protocol by placing the drive and the modem on the same interrupt. If both disk an modem I/O were synced, it might be easier to impliment that feature. Of course, this might be impractical since processor overhead might get excesive. But, I think that if you could get music to play while a drive is loading, you should be able to bring data in through a modem while the drive is saving. For the last place feature. That feature which allows you to transfer a file where you left off. Could the Commodore DOS's Append feature work in a download situation to add on to the file? And in an upload situation, couldn't you scan block by block until the appropriate block is reached. Since you're dealing with 254 byte blocks it shouldn't take that long for a dedicated algorhythm to scan blocks. You wouldn't even need to load them into the computer. Simply incriment the counter in the drive itself. The downside to all this brainstorming is that it might make the protocol very proprietary, requring particular hardware to function. But, if you were running a BBS (which is where I've stated the major advantage for the protocol would be), it would be an acceptable burden. For the average terminal user, I think enough of them have "standard" equipment where if you were to just devote yourself to the compatibility of major Commodore drives, and the CMD stuff you would have a large enough market of support. DOc. ------------ Category 8, Topic 16 Message 27 Tue Oct 19, 1993 C128.JBEE at 05:43 EDT >D.TUOMI [Doctor] >I think there is as much a need for the ease and flexibility of Zmodem >on the Commodore as there is for any other computer. I think I can agree with that :) Of course if all C= word processors would load and run straight ASCII text files even if they were marked as PRG files, life would be 10x simplier for everyone. Even when using YMODEM. ------------ Category 8, Topic 16 Message 28 Thu Oct 21, 1993 D.TUOMI [Doctor] at 04:04 EDT I think the ZED editor program will load a straigt ASCII file as a prg file. I know the buffer in DESTerm definately does. Doc. ------------ Category 8, Topic 16 Message 29 Thu Mar 03, 1994 BADCO at 23:38 EST Well, I just got a message the other day saying Nick is holding up NOVATERM 9.5 because he is putting Zmodem DL support in. (which from what I have seen in the spec file I have, is a bit simpler than Zmodem UL.) So if this message I recieved is not bogus, perhaps ZMODEM will be everywhere for 8 bits soon For certainly once one program has it, everyone can steal it. (probably why no one has done it, spend all that time implementing it, and you might get 6 months before someone like E.G.Bell has figured out your code and implemented it himself :-) But I wish him luck on it. ------------ Category 8, Topic 16 Message 30 Sat Mar 05, 1994 CBM-ED [e.g.bell] at 08:31 EST Sean: SP> Nick is holding up NOVATERM 9.5 because he is putting Zmodem SP> DL support in. (which from what I have seen in the spec file SP> I have, is a bit simpler than Zmodem UL What everyone else has heard is that this is finished, and that he is working on the upload part. SP> everyone can steal it. (probably why no one has done it, spend SP> all that time implementing it, and you might get 6 months SP> before someone like E.G.Bell has figured out your code and SP> implemented it himself :-) But I wish him luck on it Sean, if I didn't know you personally, I might have taken offense at that. First, I believe Nick had help with his code from Brian Bell who did it ion Omni BBS... I don't have anything more than hearsay on that, but from someone reliable. Second, I don't think it would take 6 months... maybe 1 or 1 and a half because I already know basically what to look for and what the routines are supposed to do. But I still don't think I would 'steal' Nick's code for 2 reasons. First, the money is not there, and reverse engineering, regardless of what anyone might think, is not all that easy in terms of time after you get beyond 1K or so of code. Second, I would want to be sure it worked. :) There are still fixes being done to the Ymodem and that came out just a tad before mine did in 1990. Actually, it would not be a whole lot more work to just do my own code IFF I were going to do it. I had been looking at it again, but I just have so many other things to do. I hope Nick gets the reward for this.... and Brian too, for that matter. Being the pessimist I am, I tend to think he won't. :) k Maybe now it will be apparent that the gain is not all that much over Ymodem. ------------ Category 8, Topic 16 Message 31 Sat Mar 05, 1994 BADCO at 10:23 EST Well, Ed, the comment was not meant to be an insult, I hope you don't take it that way. It was simply meant to be a simple statement that once working code exists to do something, it is only a matter of time before it is disected and basically public knowlege. I commend everyone involved in the Zmodem Project, I had just started rereading the specs again 2 months ago, as graduation is not far off, I am thinking that finally I will get more time than 1 day a week to play with programming on the 8 bit. (did you catch my message on the PCG concerning your Swiftlink NMI example code?) I think I found a flaw in the nmi logic that was causing my high speed problems, you might be interested in it. Zmodem is a nice protocal as far as user friendliness is concerned, I certainly love using it on the systems I have that support it. I do have a question on a lighter note, do you have any example BURST code, my 1581 will not read th source code of the 1581 DEMO DISK properly and the 1571/81 manuals are far from overtly helpful on this subject. I would like to implement burst PROGRAM READ and PROGRAM WRITE if there is a way of doing this, to speed up DL's, but from what I see of the BURST commands it appears you can only do block read/block write which would have high overhead on the PC end of things for the limited use I want them for. *s ------------ Category 8, Topic 16 Message 32 Sat Mar 05, 1994 CBM-ED [e.g.bell] at 18:45 EST Sean: sP> the comment was not meant to be an insult, I hope you don't sP> take it that way. It was simply meant to be a simple statement sP> that once working code exists to do something, it is only a sP> matter of time before it is disected and basically public sP> knowlege Well,since I know you personally, I knew it was not an insult, but I did want to make sure everyone else understood that. :) I don't think I agree about things becoming public knowledge tho... Ymodem has been done since 1990 on the 8 bit machines and there is no publicly available source code as far as I know. sP> I think I found a flaw in the nmi logic that was causing my sP> high speed problems, you might be interested in it If it is in my code, I think you should post it here as there may be a lot of people using it now that it is available publicly. I'll reply to the rest of your message in a different topic as even this reply is skirting the fringe of off-topic. :) ------------ Category 8, Topic 16 Message 33 Sat Mar 05, 1994 CBM-ED [e.g.bell] at 19:00 EST I started a new topic, topic 19 in category 5, to make a start of collecting some info for you on burst loads. ------------ Category 8, Topic 16 Message 34 Sun Mar 06, 1994 C128.JBEE at 04:14 EST I had uploaded the Bellterm source code and it is available on disk to registered users. I pulled it from GEnie after finding someone selling it overseas (hence Lib#10). ------------ Category 8, Topic 16 Message 35 Mon Mar 07, 1994 F.OGLE [Color BBS] at 21:50 EST :( ------------ Category 8, Topic 16 Message 36 Fri Dec 30, 1994 THE.OUTLAW at 14:15 EST This topic started out as Zmodem for Desterm, read on... dated 12/27/94 -------------- Matt also told me a few other things which were. 1) Mathew can be reached at mdesmond@can4.rcl.ray.com he said that he will reply to E-Mail on the Internet and welcomes suggestions on some upgrades... with a few exceptions. a) don't ask for Z-modem he is not going to write any more protocall moduales. See Topic 11 Message 80 for the full posting... ------------ 8 ? ************ Topic 20 Thu Jul 29, 1993 A.PAGLIACCI [Albert] (Forwarded) Sub: Help!!! With RSCARDS 128 This is for people who need help with RSCARDS 128. 10 message(s) total. ************ ------------ Category 8, Topic 20 Message 1 Thu Jul 29, 1993 A.PAGLIACCI [Albert] (Forwarded) I recently downloaded RSCARDS 128 and would like to know if it runs in 40 or 80 col. mode and if I can use WIZARD terminal settings with the built in terminal program. Thanks. Albert ------------ Category 8, Topic 20 Message 3 Sun Mar 06, 1994 B.HERRING8 at 17:48 EST I downloaded RSCARDS(C) 128 , I am using swiftlink. Is there a way to get this prg. to work with swiftlink? ------------ Category 8, Topic 20 Message 4 Sun Mar 06, 1994 C128-QT.PIE at 22:08 EST B.Herring8 No, RSCARDS is not compatible with a Swiftlink :( ------------ Category 8, Topic 20 Message 5 Mon Mar 07, 1994 C128.JBEE at 01:12 EST The color version was hidden a while ago because with the changes RSCARDS made it no longer works correctly. Hopefully the new version will be done soon, for now you have to use the monochrome version. ------------ Category 8, Topic 20 Message 6 Thu Mar 10, 1994 B.HERRING8 at 00:07 EST Will the new version of RSCARDS support swiftlink? ------------ Category 8, Topic 20 Message 7 Thu Mar 10, 1994 C128.JBEE at 00:57 EST I hope so, I am really pushing for it :) ------------ Category 8, Topic 20 Message 8 Sun Oct 16, 1994 CBM-MARK at 02:10 EDT I'm sure you've all seen the announcement about the latest version of RSCARDS128 now being available ;D For those of you who would like a hard copy of what gets sent to your screen when you run the "RUN.ME" file, here it is: There are two versions of the RScards FE for the C128: Color - only works for 128's having 64K VDC RAMS Monochrome - works on all 128's Each version requires three files to run (note that the data file is the same for both versions): Color: Mono: rscards(c) rscards(m) rscards(c).ml rscards(m).ml rscards.dat rscards.dat To use the RSCards FE on your Commodore 128: 1. Log on to GEnie using your regular communications program or the dumb terminal built into the FE. 2. Move to the GEnie menu page for the game you wish to play. 3. If you are running your own terminal, exit it and load either rscards(m) or rscards(c) as appropriate. 4. Select the "Play" option from the GEnie menu page. 5. The FE should auto-start when it receives a prompt from GEnie. If it doesn't start within 30 seconds or so then press the up arrow key (next to RESTORE). The following special keys are used to control the RSCARDS program: C= s Toggles sound effects on/off. C= b Toggles "moving box" effects on/off. C= u Display usage statistics (in scroll area). C= l View the scrollback buffer. Works only when the scroll area is active. Will display the last 12 lines received. Holding down the C= key will pause the listing. C= e Exit. If in graphics mode you will be returned to the built-in terminal. If in terminal mode the program will abort. INSERT Change foreground color (mono version). There are three different methods of input: a mouse in port #1, a joystick in port #2, or the keyboard. Use the following keys to move the mouse pointer around the screen: HOME mouse button CRSR UP move to first "button" on screen CRSR DOWN move to last "button" on screen CRSR RIGHT move to previous "button" on screen CRSR LEFT move to next "button" on screen Please send us your comments and suggestions (as well as any bug reports) by selecting the "Feedback to Factory Programming" item on any RSCARDS menu page. Make sure that you mention that you are running a C128 version. Thank you for playing RSCARDS games! WC.COLEMANN ------------ Category 8, Topic 20 Message 9 Sun Oct 16, 1994 CBM-MARK at 02:12 EDT Oh, by the way, RSCARDS does *not* support the use of Swiftlink :( ------------ Category 8, Topic 20 Message 10 Sun Oct 16, 1994 CBM-ED [e.g.bell] at 04:18 EDT I guess this means that Bill is supporting RSCARDS again, huh? Great! ------------ 8 ?