8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CAT5-MSGS.ARC / 4.CAT5-930915 < prev next >

Wrap

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

can not afford to lose or anything you can not/will not want to reconstruct. Many businesses go bankrupt after a disaster for the simple reason doing that weekly/daily backup was too much trouble ... ------------ Category 5, Topic 20 Message 20 Wed Aug 12, 1992 M.DULSKI1 [Mark @WIZARD] (Forwarded) Excellent advice, JBEE! Something I'm guilty of ignoring, 'for that simple' reason'...too much trouble. And I've been sorry a couple of times :( Being human, I'll go through the trouble of making backups of important stuff for a while but then, I guess you could say, I start to figure that "nah, nothing going to happen". So I neglect making a few of those backups. POW! I get nailed with a corrupted disk or whatever. <sigh> You'ld think I'ld learn. :) Someday? Mark ------------ Category 5, Topic 20 Message 21 Thu Aug 13, 1992 CBM-ED [e.g.bell] (Forwarded) I am still working on my Magic program, and I back it up every morning after work, and perhaps once or twice in the course of my work. That was a BONUS when my 1571 went sour, since I back up onto the other format disk. I don't like the time, but I've lost some really important work. A guy from a Pittsburgh newspaper was directed to me once by the president of our User Group. The guy had lost 8 months of work on a disk he didn't back up. I was able to recover it, but the lessons are not lost on me! And even backing stuff up, I get burned occasionally! ------------ Category 5, Topic 20 Message 22 Fri Aug 14, 1992 HOWIE-CBM (Forwarded) Well everyone who has JiffyDos (or any other DOS enhancement that offers a built in copier) and more than one drive has no excuse. All copying can get done automatically, and often. At least that is the case for often used and changing data files. However while I do Basic programming, and even tho it is so *easy* to make backups of upgrades, I usually don't. I like to think that the most recent changes will give the best running version, so why keep older ones around.... I've been lucky to date... However, luck will go just so ar, which is why I now have a template of `JBEE's Basic' which will get appended to any more stuff I decide to modify. :) Howie ------------ Category 5, Topic 20 Message 23 Fri Aug 14, 1992 C128.JBEE [* Sysop *] (Forwarded) ;) ------------ Category 5, Topic 20 Message 24 Fri Aug 14, 1992 CBM-ED [e.g.bell] (Forwarded) Wanna hear something wild! After I logged off, I went back to my programming and promptly fried the very disk I said I had been backing up. I had already made 2 backups today due to the nature of the work I had done, and thus had VERY LITTLE to restore after the files were copied. I lost a lot of little BASIC files and SOURCE programs, but nothing irreplacable, I just went back over the old disk because what i have is good enough that I don't need to do a recover on the disk itself. Every once in awhile.... Am I beaming or WHAT!? :-D ------------ 5 5 rea 22 nor rea 24 nor rea 33 nor ************ Topic 22 Sat Jan 27, 1990 D.ROHNER (Forwarded) Sub: Zmodem programming for 8 bits??? What started as a discussion of DesTerm blossomed into what would be involved/needed to develop Zmodem on Commodore 8 bit machines. Do you have the ability to do what no one has done **YET**! 21 message(s) total. ************ ------------ Category 5, Topic 22 Message 1 Sat Jul 25, 1992 CBM-ED [e.g.bell] (Forwarded) You can, at least for now, file Zmodem into your book of wishes, at least for the 8 bit machines. None of the current telecommunications authors are willing to attempt it. Not enough benefit for the amount of work. Punter is becoming a bit of a curiosity, except on commodore BBS's. Some ppeople like it because it was written with Commodore DOS in mind, it does not pad, and it is reasonably reliable. Many feel it is faster than Xmodem, an opinion I don't share, because I have worked intimately with both. You are best to stick with Ymodem where available, or Xmodem 1K, both of which Desterm supports. At the world of Commodore show in 1990, I met Gary Farmaner, tho I'm sure he wouldn't know me if I hit him (but he'd remember it. >>grin<< ) He kind of said he had found a way to do concurrent disk/modem access, and that Zmodem was a reasonable expectation. Musta been more there than met the eye. But Ymodem is a solid protocol, YLR.ROSE, and multiple file transfers are GREAT. ------------ Category 5, Topic 22 Message 2 Tue Aug 04, 1992 D.SMITH244 [VOICE] (Forwarded) I am considering purchasing a ZOOM VX v.32 9600 modem (has v.42bis and MNP5 also). I am using DesTerm 128 V2.00 with my Omnitronic RS- 232 interface and a Pocket modem 1200. I think I've heard of folks around who have used DT2.00 at 9600--or is 2400 the best I can expect from my setup (I use my 1750 REU as a ramdisk for downloads, etc.). Also--re: the talk on InterNet about writing a Zmodem external protocol for the 128. Anyone here think it's possible and willing to give it a shot? What would it take to get the specs on the protocol? ------------ Category 5, Topic 22 Message 3 Tue Aug 04, 1992 R.KNOP1 [Rob Knop] (Forwarded) Getting Zmodem specs isn't hard, I don't think; have never searched them out myself, but I think you can find them on one anonymous ftp site or another. I know you can get the source to the Unix version of Zmodem (in C), because I have searched that out. DesTerm should be able to do 9600 buad; Matt and Geoffrey Welsch spent some time with an oscilloscope watching the bits go in and out. However, if it doesn't mesh exactly with your modem, you may have to "tweak it" (mess around with the baud rate fine controls, I forget what DesTerm calls it). If you want to do 9600 baud, you are likely to get better performance with a SwiftLink Cartraige. -Rob ------------ Category 5, Topic 22 Message 4 Tue Aug 04, 1992 CBM-ED [e.g.bell] (Forwarded) Actually, one of the features most heralded about DesTerm from its very first release was being able to handle 9600. I have heard from soooo many people that this is possible w/o a SwiftLink that if I were you, I'd try it before buying one. Will probably work... wrt Zmodem, the consensus on FIDO, with which I happen to agree, is that while a flavor of Zmodem (packets (non-streaming)) would be possible, but no one is going to do it... too much work for too little reward. In the end you won't do much better than Ymodem Batch. The protocol can be set to send in various size blocks, do full handshaking between blocks, use 16 bit CRC, etc. 1 main trouble, the one that kills streaming, is that Commodore computers can't process modem and disk i/o concurrently. Doing packet transfers would remove 1 main advantage of Zmodem. As for the resume, there is a lot of question about the reliability of Commodore DS appending a resumed file. Add to that the fact that one way or the other, Commodore end would have to read through the file being resumed to determine a CRC to make sure both ends are starting at the same place in the file. One more time hog! I wouldn't look for this protocol in the 8 bit commodore line. As has been pointed out.. the people writing the terms/protocols say it won't be done... the people who don't write the programs say it can and how easy it would be. Go figure. I have been in and around these discussions for years. Better someone should do a new protocol that is more friendly for CBM computers, but then, don't expect that either because of what it would take to get other platforms to implement it. Other than Punter, we will have to just emulate whatever the big guys come up with. >>sigh<< ------------ Category 5, Topic 22 Message 5 Tue Aug 04, 1992 C128.JBEE [* Sysop *] (Forwarded) How about the people that don't care what people say can't be done and will just find a way to get it done anyway? ;) LHZ was suppose to only be the domain of all the "big" boys with all the processing power and quite a few 8 bitters including Apples use it now. I am a firm believer in the American way. Offer someone money to to get something done and they will do it :) ------------ Category 5, Topic 22 Message 6 Wed Aug 05, 1992 CBM-ED [e.g.bell] (Forwarded) I agree 100% with what you just said, John. Even Matt Desmond has said as much. Trouble is, no one is offering the kind of cash that would entice an author to spend that kind of time on something like this. I would venture to say that shareware rarely, if ever, reflects usage of a program. Desterm is probably an excellent example. I often wonder how Matt can afford to mail updates to people at no charge for this reason. I didn't mean to imply it can't be done. I meant to imply that it is not worth the effort, except for someone well-paid or very benevolent. If I were retired, I would resume work on it immediately. The specifics of the program are not all that difficult once you wade through Chuck Forsberg's docs. The modem/disk i/o thing are is the single biggest obstacle to overcome or address. wrt the American way, I see you'll be voting Democrat this fall. >>grin<< That is just a **JOKE**! ------------ Category 5, Topic 22 Message 7 Wed Aug 05, 1992 R.KNOP1 [Rob Knop] (Forwarded) Ed- The consensus on Usenet seems to be the same as what you report the consensus on FIDO to be. One has to wonder though: the stated reason for the problems are that the 128 cannot access the disk and the modem at the same time, which is necessary for a streaming protocol like zmodem, and the 128 doesn't have enough memory to create large enough buffers. Also, we know that a 17xx REU DMA will also futz up the incoming data stream on the modem. (Anyone with Dialogue128 can tell this: when you capture text in a Characters RAM2 buffer, sometimes you garble a few characters at the 64K boundry when Dialog is switching REU banks.) So, here are the questions that at this point I would raise. First, can one access a RAMLink and a modem at the same time? In other words, will the incoming stream on the modem remain intact, filling the RS232 buffer, while the computer is writing to the RAMLink/RAMDrive? Second, I expect that one might be able to find enough buffer space in a C=256 or a C=512. Third, could one rewrite the Kernal disk routines such that the _disk_ routines periodically read the user port and stuffed any incoming bytes into the RS232 buffer? This has the problem that the rewritten routines become device specific- and, as DesTerm with its rewritten streamlined disk routines shows, this could introduce incompatabilies with new hardware like RAMLinks. Finally, I don't know the details of ZMODEM (Punter is the only protocol I studied in any depth, and that was a couple of years ago), but does the sending host accept any data back from the receiving computer? It must, so that it can be told when to transmit a new block. Can you sent it a CTRL-S or something that tells it to stop sending briefly? Then, one could fill up a buffer (or several, if on a C=256 or C=512), send the CTRL/S, save the file, etc. Yes, this is sort of going back to the packet approach, but you still gain, because XModem-1K and YModem use 1K packets, whereas ZModem would use effectively 8, 16, 32, 64, etc. K packets. Thoughts, anyone? -Rob ------------ Category 5, Topic 22 Message 8 Wed Aug 05, 1992 CBM-ED [e.g.bell] (Forwarded) To answer as much as I can remember... First, I would not attempt a rewrite of the ROM routines. That is over my head. I am only now coming to a really good understanding of George Hug's code,which I am modifying again for Paul's project. Second, I don't see, and never have, that the buffer space in the C128 or C64 for that matter, is insufficient, for this reason. Zmodem is a streaming protocol, yes, but it 'streams' in blocks, which the spec recommends at 512 bytes for the currently common modem speeds. (i.e. 2400) A packet containing transfer instructions is sent at the start of each of these packets, including CRC and a couple of other things. Hence, more overhead than a Ymodem/Xmodem 1K transfer packet. Zmodem just doesn't necessarily have to wait for a reply from the receiver. Note, I said necessarily. You can, in your header, tell the sender to wait for each block to be acknowledged. As I recall, and as you suspected, Zmodem *will* recognize flow control, so transfer could be stopped while the buffer is being filed. See, the buffer size is really not that critical for this reason. If Zmodem says, in its first header block exchange, that the transfer source is to wait for an ack packet after each block that is how the transfer will take place. The packets are protected, which is where the higher reliability comes in. Normal protocls to this point only CRC'd the packet and sent a 1 byte ack/nak/eot/can, which was not protected. However, if you specify a transfer like this in Zmodem, you start to lose all the speed advantage quickly. compared to Ymodem/Xmodem 1K/Xmodem packet acks, Zmodem's are huge. Forget how many bytes, but I think it is 6 or 8. More of Zmodem's reliability stems from use of 32 bit CRC. I don't even know how you would calculate that on a CBM. I"m sure someone does, from whom I'd have to get the code. >>sigh<<. Zmodem can, however, use 16 bit CRC too, but then you are back at Ymodem level. See how it keeps coming back to that. YOu can't do DMA's any more during modem i/o than you can do disk access. On that note, Gary Farmaner told me personally (wonder if he remembers) at the world ofCommodore show in 1990 (Hunter Group... in Norristown) that he had discoverd that this stuff was possible, but that was the first and last I heard about that. As I mentioned earlier in this thread... another feature of Zmodem is the resume, but the receiver must send an CRC accumulated from the file to be resumed to synch both sides. Can you see what a nightmare that would be. I had considered a workaround for this when I was considering things like this. A download process could keep a running CRC which could be written to disk in some kind of file in the event of a failed transfer. That could be speedily acquired in event of a resumed attempt. I have seen the post earlier here on FIDO that QLink uses APPEND, but I don't know that that is the case, or if it is just what the programmer SAYS on the screen. But I am not totally comfortable appending a prog to resume a transfer. But in all of this, you can see time just building and building. When I was considering a module for BellTerm, I was going to implement a download modue only, which is more useful to more people, IMHO. But Zmodem is incredibly flexible. It has a hundred personalities, so to speak, which the two ends of the transfer can work out to their liking. CBM just kind of stacked the deck against easy implementation with that i/o problem. There was some discussion of that being do-able with the SwiftLink, along with the possiblility of up to 3 phone lines. As it has been said. Anything is possible. Most of the people who could do it, if not all of them, won't for many of these reasons. There *was* a time when Ymodem was just a wish for us, so who knows. As JOhn said, money would talk, but I wonder how much it would take, and if it would really be worth it. I kind of think not. If someone is going to do it, it will just be for the notoriety of doing what can't be done, and I doubt that Matt Desmond, etc. have the time for that. Incidentally, Matt says Kermit will be in a future version, for what that is worth. ------------ Category 5, Topic 22 Message 9 Thu Aug 06, 1992 R.KNOP1 [Rob Knop] (Forwarded) Hi- Ed; re: 32-bit CRC, I have a program by Craig Bruce that calculates and prints a 32 bit CRC of any disk file you specify. You want me to ask him for the source code? I've got the 64/128 executable, and C source code. (The 64/128 executable is in ML; he released it on Usenet so that people would have a way of verifying that their uploads/downloads to/from their Unix or VMS systems (which typically have C compilers) completely succesfully.) I'll upload what I've got tonight (hopefully). Re: packet ack: I agree that if you are going to ack every packet, you lose all the advantages of ZMODEM. Rather, it'd be better to stop the flow after you've filled up your buffer. Although there is greater overhead, you probably don't need a very big buffer (8K? 16K?) to get a gain over Xmodem- 1K. How does Zmodem deal with re-transmitted packets? Can you request retransmission of a specific packet after the fact? Re: append: true, time does add up if you do this to resume transfers. However, this time is not too long if you are running from some sort of 17xx RAMDisk, or a RL/RD. Probably a significant fraction (>= 1/4 ?) of the "power downloaders" that'd want to use Zmodem would have one of these. Ah, well, I'm letting myself get too interested in this ;). If somebody has a hope of being able to write Zmodem, you, Ed, are in line long before I am.... -Rob ------------ Category 5, Topic 22 Message 10 Thu Aug 06, 1992 CBM-ED [e.g.bell] (Forwarded) I am not at the head of the line, believe me! That CRC might be interesting. I understand Punter uses a 32 bit CRC too. I would REALLY be interested in the ZED burst read routines! But in this topic, developing for the Rl/REU owners would be a BIG loser, because there just are not all THAT many, compared to the CBM owners. As a matter of fact, there are not really that many modem users when cmpared to CBM owners as a group. We have probably wasted more time over the years talking about / wishing for Zmodem than we would ever save if it is ever implemented. I'd like to see it done just to see that it could be done, but I'm not going to be the one to do it. I will be in the front row applauding the guy who does! ------------ Category 5, Topic 22 Message 11 Fri Aug 07, 1992 R.KNOP1 [Rob Knop] (Forwarded) Ed- I've uploaded the crc32 stuff to library 4. Turns out the assembly source (in Buddy format, which is the assembler that Craig Bruce uses) is there too, so you're in luck! (What assembler do you use?) Re: ZED burst routines: turns out you _can_ take a look at them! Check out Issue #3 of the Usenet C= Hacking magazine. It's long, broken up into two .sfx's in the library. One article in there is about burst loading, by none other than Craig Bruce. It's a very long article, and has complete routines that you can clip out (he gives a Unix command that'll do it; if you like, I could do the clip on the Unix system I use at work and xmodem it to you separately). Another winner is his dynamic memory article in Issue #2. Those are also routines used in ZED. (Actually, I am not sure that the burst routines in Issue #3 are _exactly_ the ones in ZED; I haven't had a chance to look at it yet, and I don't feel an extremely pressing need since I had previously written my own burst routines :) ). -Rob ------------ Category 5, Topic 22 Message 12 Fri Aug 07, 1992 CBM-ED [e.g.bell] (Forwarded) Rob, and all, I am moving this topic over to cat 21, the programmers den. It will be topic 22. Wil clean it up, etc. there. We're kinda getting away from Desterm. :-) ------------ Category 5, Topic 22 Message 13 Sat Aug 08, 1992 CBM-ED [e.g.bell] (Forwarded) This topic was started from the wandering threads of a Desterm discussion in Category 8 Topic 11. While it *does* concern telecommunications, I think it is more appropriate in the programmers den, because it will take some serious programmers if it is ever to be developed.... so... here is a place we can brainstorm.... ------------ Category 5, Topic 22 Message 14 Fri Aug 21, 1992 HOWIE-CBM (Forwarded) I generally don't cross-post (don't ask why, since I do not know), anyway the following just seemed to be so on target, so here goes: --- begin quote --- Article #9548 (9557 is last): From: rholmes@athena.cs.uga.edu (Robb Holmes) Newsgroups: comp.sys.cbm Subject: Zmodem on C128 Date: Tue Aug 18 23:46:34 1992 I just downloaded a file to my C128D using the Zmodem protocol. True, it was only a 4K file (binary), and I was stuck at 1200 baud, because the protocol runs in CP/M. But it worked. Wilfried Schmitten has written a pair of Unix-like file transfer programs, sz and rz. They work with CP/M 3 systems, like the C128. In order to use these utilities, you must first use the DEVICE command to assign rs232 to auxin: and auxout:. You must also use CONF to set the baud rate. The author has posted a uuencoded library file containing these programs to the newsgroup comp.os.cpm. The subject header of the message containing this library is, "X/Y/ZModem send/rec from command line CP/M 3 only". The following is the author's description from that message: ---begin quote--- szrz100.lbr X/Y/ZModem send/receive from command line CP/M3 Programs for CP/M 3 only sz / rz are a pair of programs send or receive files in X/Y/ZModem protocol. The function is like the wellknown UNIX tools. The only condition: a modem (nullmodem) is connected to the AUX device. Get help with sz -? or rz -? The actual versions in this library are sz v1.11, rz v1.04 ---end quote--- ------- Robb Holmes WUGA-FM Ga. Center for Continuing Ed. Univ. of Georgia rholmes@athena.cs.uga.edu rholmes@uga.cc.uga.edu bitnet:rholmes@uga Signaturally challenged. --- end quote --- Howie ------------ Category 5, Topic 22 Message 15 Fri Aug 21, 1992 CBM-ED [e.g.bell] (Forwarded) Thanks Howie! I know that Zmodem has been available for the C128 in CP/M mode for at least 2 years now. For some reason it is now widely published but I remember at the time I heard about it that the compaint was the slow speed. There has long been C code available to do it. I don't know tho, what it would take in the way of adjustment to port it for the native mode. ------------ Category 5, Topic 22 Message 16 Wed Aug 26, 1992 HOWIE-CBM (Forwarded) Ed, I'd guess that one requisite for a Zmodem under any mode is that it run with SwiftLink. Howie ------------ Category 5, Topic 22 Message 17 Fri Aug 28, 1992 R.KNOP1 [Rob Knop] (Forwarded) Swiftlink from CP/M.... that sounds like a project for Steve Goldsmit! (TC128 #32, p. 23 for those who don't know what I'm talking about.9 -Ronb (Boy, I'm a mess with typos today... 9 not ), Ronb not Rob... geez) ------------ Category 5, Topic 22 Message 18 Fri Aug 28, 1992 HOWIE-CBM (Forwarded) Rob, He *IS* eminently qualified. If anyone will get speedy tasking from the CP/M side, it is Steve! Howie ------------ Category 5, Topic 22 Message 19 Fri Aug 28, 1992 CBM-ED [e.g.bell] (Forwarded) I don't think it will require SwiftLink Howie. Heard from Matt Desmond on the matter recently on FIDO. He said that some PC implementations don't support packet- 'ack'ing. That is one more strike against CBM Zmodem, because if it is ever to happen, it will *depend* on other platforms, where most of the BBS's are run, supporting stuff like this. George Hug's code is just find for 2400. The SwiftLink would make it easier, but it is not the speed of the modem or the computer so much that is the stone wall... it is the inability to write to disk and read from modem and vice versa that is the real snag. Someone should do a ROM that overcomes that if it is possible. WAYYYY out of my league. ------------ Category 5, Topic 22 Message 20 Sat Aug 29, 1992 HOWIE-CBM (Forwarded) ha! I just thought of an interesting approach Ed.... All of the demos and mini-utilities which I've seen that do *real* multi- tasking on our 8-bits rely upon task sharing with the PC's cpu, at the same time that a drive's cpu is doing something different. Possibly this way? One big snag is that it would not work with any of CMD's RamDrives, which are the large storage devices likely to benefit most. I imagine that it would come down to requiring a hardware addition. Maybe something like a print buffer that gets fed the transfer, and writes to disk later. Howie ------------ Category 5, Topic 22 Message 21 Sat Aug 29, 1992 CBM-ED [e.g.bell] (Forwarded) That is a VERY interesting idea Howie! A print buffer. I don't really know what would be involved. It is a bit beyond my understanding of things for now. I think multi-tasking may be pushing the limits pretty far w/o a SwiftLink, but again, I an *not* the expert I'd like to be on that topic. I just did a rework of George Hug's code and am starting to get a decent understanding of the NMI rs232 routines, and also some burst work and am getting a good grasp of that too. Lotz to put toghether tho, and still come up w/ '=4'. ------------ 5 ************ Topic 24 Thu Apr 29, 1993 D.SIMMONS13 [David] (Forwarded) Sub: CS-DOS & 1571 Drives Problems with CS-DOS and a 1571 Disk Drive. 10 message(s) total. ************ ------------ Category 5, Topic 24 Message 1 Thu Apr 29, 1993 D.SIMMONS13 [David] (Forwarded) I've been using CS-DOS for a few days now, and I think it's pretty darn good. However, it only recognizes half of my 1571 drive. When I try do deARC a file which will take more than half, when it fills the disk half way (664 free), it gives me a disk error. I then have to move some of the files to another disk and save a "dummy" file of 1K per file with the same name so when it deARC the file it will think the 1K files are the actual files. But now I'm trying to do this to a LZH file, and it over writes these files. How can I make it reconize the rest of my 1571? Thanks David ------------ Category 5, Topic 24 Message 2 Thu Apr 29, 1993 YLR.ROSE (Forwarded) David.. I'm confused here. You are using 71 formatted disks correct? And you are trying to dearc files to a blank disk? Ok, then I will have to assume you are using two drives? If so, your drive 8 is letter a: drive 9 is letter c: 10 is letter e: etc... you need to set your drive that you want to dearc TO first.. ie: you want to dearc some files on a: to c: So, type c: and return.. now c: is your default destination device.. now, type arc128/x a:filename.arc or lha -s a:filename.lzh etc.. depending on what you are doing. Then CSDOS will look on drive a (8) for the file and dearc it to c: (9). HOpe this helps. Hugs ------------ Category 5, Topic 24 Message 3 Thu Apr 29, 1993 CBM-MARK (Forwarded) You could also send the disk drive command to make sure it is *in* 1571 mode and NOT 1541 mode. Under CS-DOS this would be -> >u0>m1 Mark ------------ Category 5, Topic 24 Message 4 Thu Apr 29, 1993 D.SIMMONS13 [David] (Forwarded) To clarify: I have two drives, but when I'm trying to deARC a file on the same disk that it's on, it runs out of room if it takes more than half the disk. If I'm using two drives it does the same thing, but it usually does not happen, because most files are smaller than 664 bytes. I'll try the >u0>m1 and see if that works. Thanks for the responses. David. ------------ Category 5, Topic 24 Message 5 Fri Apr 30, 1993 CBM-ED [e.g.bell] (Forwarded) David: Maybe I missed the obvious here... how many blocks are free on the disk when it is empty. Could it be that it was formatted in 1541 mode? Another possibility, which I hope is not the case, is that your 1571 mechanism is going bad. What you describe IS a classic symptom of that, and I know because I have had it happen to me. If the problem follows your drives, it has to be the disk format because CS-DOS does work with 1571 and 1581 drives. ------------ Category 5, Topic 24 Message 6 Fri Apr 30, 1993 CMD-DOUG (Forwarded) There was also an early bug on 1571 drives that caused problems when switching sides. Might simply be an origian 1571 ROM causing this. ------------ Category 5, Topic 24 Message 7 Sun May 02, 1993 C128.JBEE (Forwarded) If you have an original 1571 rom I believe I have a replacment ROM for the cost of the UPS shipping ($3). I just have to go into work and check my spare parts box :) ------------ Category 5, Topic 24 Message 8 Mon May 03, 1993 HOWIE-CBM (Forwarded) Personally, it would be my suggestion, if you are going to replace the ROM on a 1571 that you put in a JiffyDos ROM instead of CBM's standard one. Hmm... Thinking about it, this is exactly what I did for the 128D's 1571, and it didn't even need a replacement ROM... Howie ------------ Category 5, Topic 24 Message 9 Thu May 06, 1993 D.SIMMONS13 [David] (Forwarded) Well, it shows tthe normal amount of blocks free. I do not think it is the drive, because this is the only program this happens. I tried to do the >u0>m1 command, and it let me use about 100 more blocks. I also tried it on another 1571, and it does the same with it. I have also tried another CS-DOS disk, and the same thing happens. Is this just me, or what? David. ------------ Category 5, Topic 24 Message 10 Sat May 08, 1993 C128.JBEE (Forwarded) If you wanted to send me your disk with the file on it I could give it a try on a couple of 1571s here to see what the problem might be. ------------ 5 ************ Topic 33 Thu Aug 12, 1993 M.SEABRUM at 05:22 EDT Sub: Help need with Xmodem shell! When a user uploads a program from my BBS, the transfer never comes through. 28 message(s) total. ************ ------------ Category 5, Topic 33 Message 1 Thu Aug 12, 1993 M.SEABRUM at 05:29 EDT I have download a Xmodem shell from here called Append2. The shell works great except when a user uploads a file to the BBS. The BBS is home-made and I have checked every possible soulution. Why isn't the X-modem upload coming thru? When a user downloads something from the board a file must be opened as follows ... Open2,8,2,"0:football,p,r" This file must be opened prior to calling the X- modem ML... This is for ASCII/Xmodem uploading(BBS) and downloading (user). There is a diffrent SYS location for the 3 option of this shell. ASCII Upload, X-Modem Upload, and X-modem Download. When a user uploads something to my board, all is displayed is ":" for bad blocks. Can it be the padding? Do I have the strip the padding before someone can upload something to the BBS? If so, how do I do this? By the way, the program is GM-BBS V4.0, and it is for the C64.... Please help! ------------ Category 5, Topic 33 Message 2 Thu Aug 12, 1993 CBM-ED [e.g.bell] at 08:39 EDT First, you don't have to use the ',p,r' when opening files for downloading. You can just 'open #,#,#,"filename", where the #,#,# are the normal open statement arguments. Second, as I recall now, there is a bug in that code for one or the other directions. I used it at one time and found the bug but don't recall anyone ever mentioning it. The code is designed to test for blitzed BASIC as I recall, and the bug was in there somewhere, but that may not be your problem. The protocol itself will add padding, so you can't strip it before uploading and expect it to stay stripped. The shell you have does not strip padding either. You'll have to do your own routine to do that. As for the file not being opened, er... skip that. that was not what you said... as for transferring blocks successfully, that may be a timing problem on your end. Have you put in George Hug's wedge? The timing on sends (when someone downloads from your board) is not as critical or I should say it is more forgiving than when they try to upload to you. It is the receive function that kills you. The punter protocol included a kludge that made minor changes to the ROM timing routine to operate at 1200. If you are trying at 1200 or 2400, you could be experiencing the need for this. Xmodem, again in my experience, is more forgiving of timing problems than Punter, but it does sound like that may be your problem. You will either a] have to do your homework or b] get a copy of Punter's protocol and study/implement his kludge, or better, get George's wedge and install that. If you have done this and are having this problem, you need to go over your work very carefully... is the file opened on the BBS end? The BBS must open the file before the transfer starts so it has a place to write the data that is coming in. You didn't mention doing that. Did you? Of course that would also not cause what you describe because the dos part of it is separate. You have to disable NMI's before DOS access and reenable them afterward... again, study Punter's code or George's, which is a world better in this regard too... because it is automatic. Try all of this and see how you make out. ------------ Category 5, Topic 33 Message 3 Fri Aug 13, 1993 M.SEABRUM at 02:30 EDT Ok. Can this be the problem? I'm opening a file such as 'open 2,8,2,"games,p,w"' just before calling the Xmodem download(BBS). You stated that I need not to do this so I'm assuming this is done automatcially. The transfer is at 1200 baud. I will be upgrading to 2400 baud in the near future. I have the code presented by Mr. Hug, but no docs came with it. As far as you saying implement his code, I'm totally confused and don't know where to start. I have to rewrite the U/d section and if my memory serves me