8bitfiles.net/archives

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

/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / CAT5MSGS.ARC / CAT5.3MSGS930520 < prev next >

Wrap

Text File | 2019-04-13 | 24.0 KB | 730 lines

------------ Category 5, Topic 25 Message 44 Fri Nov 27, 1992 CBM-MARK at 21:34 EST Bruce, It was just a 'you had to be there' kind of joke, refering to our own *lively* RTC hostess. :> Oh, oh...Paul (if you see this), you don't think JBEE's humor is contagiuos do you? Sorry Bruce, I won't interrupt again. Carry on ... :D ▐▐Mark▐▐ ------------ Category 5, Topic 25 Message 45 Sat Nov 28, 1992 PAUL-MB at 15:10 EST Contagious? It could be. :D Paul ------------ Category 5, Topic 25 Message 46 Sat Nov 28, 1992 B.VRIELING1 at 19:06 EST Well Ed, I didn't end up using your suggestion. :) Leaving the re-vectored close code in memory all the time was causing a problem, but I reached an even better solution. I wrote a routine called KILL_CLOSE which simply removes the LA, SA, and DEV entries from the OPEN tables. The file on disk stays open, but the computer effectively has no record of it. It's equivalent to a CLOSE executed from BASIC, with the drive unaware of what happened. A new procedure AWAKE_CLOSE re- stuffs the tables with the previously saved LA, SA and DEV. Bingo, the file is open again for access. In the process of the above I discovered that a simple re-vectoring of the CLOSE vector and a bit of code to ensure 1 file was always open doesn't work with CS-DOS. It seems before returning control to the shell, CS-DOS checks location $98 (# of open files), and keeps trying to close files until $98 holds a zero. By forcing $98 to always be at least 1, I was effectivly putting CS-DOS into an infinite loop. Live and learn, eh? Tomorrow I can get back to the meat of the project... ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 47 Wed Dec 02, 1992 D.MCLAUGHLI8 [Black Fire] at 08:47 EST To: B.VRIELING1 I read your problem about having open files with CS-DOS. Well, if you haven't got an answer yet, here's my idea. Try putting a '0' in the open files byte before the end of your CS-DOS proram. This might fool CS-DOS into thinking there are no files open. If you have more than 1 file open, you may be able to find an open byte somewhere and saving it there. Then the next program comes in and does a peek, then a poke to restore open fils. Just a suggestion. Douglas McLaughlin ------------ Category 5, Topic 25 Message 48 Wed Dec 02, 1992 B.VRIELING1 at 21:18 EST Doug, That's sort of what I ended up doing. However, just incrementing and decrementing the open files count is not enough. One must also save the LF, SA, and DEV information from the appropriate tables. This is necessary because otherwise any OPENS CS-DOS does in the meantime (say to read a directory to FIND the chained file you are invoking) will overwrite the vital information, and it will be lost. However, it is STILL not working properly for me. It's almost like CS-DOS knows by itself how many files SHOULD be open. Hmmm. I think I'm going to try opening a totally different file on the same disk, and then overwrite this new file's LF, SA, and DEV with the old file's. That might work... I'll keep you all posted. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 49 Sun Dec 20, 1992 S.CRAIK [Steve] at 20:30 EST Hi Bruce, I'm suppling some CRC checks of the file SEARCH. (below) crc search ==================================================== d:filename type bytes blks crc ==================================================== "z:search" prg 9,171 37 68eb $1c01-3fd2 ==================================================== 1 file(s) 9,171 1317 crc32 enter name of file to take crc32 of: search scanning file... crc32 = 3036348271 I've been having some difficulties in getting SEARCH to work. It starts seemingly OK, but after it finds the filename the color of the "File:" changes to RED and just continues scrolling over over entering "File:" on everyother line (or so). search /c search b:search.txt Is an example of what I have entered on the commandline. This should have ONLY looked for "search.txt" on b: drive. (as I understand it) ..and since I toggled case sensitive with "/c" it should find any "search" irreguardless of case. Do you have any Ideas as to why it never finds the text "search"? Steve Craik (S.Craik) btw.. I installed "search" in the REU the device is a 1581 where the "search.txt" file is. ------------ Category 5, Topic 25 Message 50 Mon Dec 21, 1992 B.VRIELING1 at 19:12 EST Steve, Hmmm. The CRC's you posted ARE correct, so you do not have a corrupt copy of SEARCH. I duplicated your senario exactly. I made my 1581 B:, copied SEARCH.TXT to it, installed SEARCH in my REU, and executed: search /c search b:search.txt It worked exactly like it is supposed to. Are you using a 40 or 80 column screen? I do all my programming on the 80, and don't even have a 40 hookup - maybe I should check that. Tell me more. We'll solve this. :) ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 P.S. V4.0 of the Pack is due to be released within a week. Look for it! ------------ Category 5, Topic 25 Message 51 Mon Dec 28, 1992 S.CRAIK [Steve] at 03:08 EST Hi Bruce, Nope, I'm in 80 columns. Only thing.. perhaps I'm using a 128D, ramlink with latest RL-DOS (that I know of) and it has that CLOCK Hmm? what is supposed to happen? For one I imagine that it shouldn't change colors after it finds SEARCH.TXT ..then the scrolling thing shouldn't happen.. correct. What might a typical display look like? Say for instance that SEARCH.TXT would only have one instance wherein a line contained the text "search". Hmm? could you use the ">" command to output the screen to a SEQ file. Then maybe post it here. Though, this info in itself won't help any as to why I'm getting different results. Hmm? there is NO mention of SEARCH using the REU, but does it expect an area set aside for its use? Maybe cause I have, different pokes for things and different setram setting. Hmm? Steve Craik ------------ Category 5, Topic 25 Message 52 Mon Dec 28, 1992 B.VRIELING1 at 17:12 EST Steve, Yikes. What you describe is certainly strange. I ran a test. I have the following text file (three lines) on drive 8 (a 1581) called STEVE.TXT: **** Start of Quote **** test junk This is a test text file which contains only one instance of the word SEARCH in it (that was it right there) **** End of Quote **** I then exectuted the following: search /c search steve.txt The output from that looked like: **** Start of Quote **** Search string: search FILE: steve.txt ---- [ 3] word SEARCH in it (that was it right there) **** End of Quote In other words, it worked exactly like it is supposed to for me. Very strange. As for your other comments, no, SEARCH does not require any info in the REU at all. As a matter of fact, I recommend that you try disconnecting your REU/RAMLINK entirely from your computer. Run CS- DOS without an REU, and simply execute SEARCH from disk. If that works, then we know there is a problem with the ramdisk. That's about all I can think of for now. Are you experiencing any other problems with the Pack? Or just with SEARCH? Do you have any other extra hardware on your 128? Anything special about the 1581? Try my suggestion, and get back to me. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 53 Tue Dec 29, 1992 S.CRAIK [Steve] at 00:43 EST Hi Bruce, I tried SEARCH again after I logged off last night/morning. It at least found a word in a TEXT file ..that I had in RAMLINK (1581 partition) HOWEVER, it did continue on and changed colors as I described and scrolled on and on.. I did manage to try and use the ">" (output to seq file command) and was able to see that it did find the string in the file. Then I tried the 1581 & 1571cr ..neither worked. Strangely I noticed a error result ?formula to complex. This was after I'd tryied the first time the had just done a RUN/STOP RESTORE (I was in uppercase at this point, with a READY prompt) entered a cs-dos "dir/w" ...I just got another READY repeated the dir/w and somewhere during this portion it started displaying the directory (but very slowly) followed by the error message. I powered down and loaded CS-DOS again then tried the 1581, nothing, just the filename echo'd back no finding of the string.. then the scroll. Powered down and back up repeating same for the 1571, same results. Other files of the CS-XTRA3.SFX.. IBMVIEW on the 1571cr wouldn't work. 1581's OK! I must admit though.. I only have on 5.25" IBM disk to test that. Hmm? I forget if I checked the 5.25 with BBR. I'll check and get back. SEARCH and running it without REU. I'll disable it. I'll get back. Thanks! ------------ Category 5, Topic 25 Message 54 Tue Dec 29, 1992 B.VRIELING1 at 10:43 EST Steve, Re: ?FORMULA TOO COMPLEX error That is a NASTY one. When you do a STOP/RESTORE within certain CS- DOS applications, you TOAST the state of the machine. It seems the zero page locations CS-DOS uses for some functions never get "put back" properly when you STOP/RESTORE - they WOULD have if the program would have terminated normally. In other words, don't STOP/RESTORE. It causes those ?Formula too complex errors during directory listings. If you do STOP/RESTORE, reboot. It's the bext thing. I'll see about putting together a FIX command which will return CS- DOS to an acceptable state. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 55 Tue Dec 29, 1992 S.CRAIK [Steve] at 21:33 EST Hi Bruce, I took you suggestion, and disabled the REU (a RAMLink DACC) out of the picture but, still left RAMLink enabled. SEARCH worked and ended correctly. One thing that I started to think about ..is that perhaps cause I was always (up til now) just in the default drive (RAMLink 1581 11,6 CS-DOS partition) then calling on SEARCH to locate a file on the 1581 10,0. That it might be the problem. So I went back to the REU and before SEARCH'ing I switched to the 1581 as current device. This let it at least find the file and text but still continued the scroll. What I then did after hitting the RUN/STOP RESTORE was to NEW and call on the same SEARCH as I had. It would immediately search the 1581 (10,0) assigned B. But, then quickly go and search A: the 1571. the funny thing is that I RSAVE'd search from the REU ramdisk to a 1571 disk. Then used it by doing a "a:search /c text filename" ..anyway, this would indicate that it isn't the SEARCH file's fault, but something between my RAMLink REU(dacc) that causes the prob. BTW.. I've always left RL-DOS active. I'd thought that it might've been that I ASSIGNed devices but changing /deleting that from the AUTOEXEC doesn't make a diff. Only other thing peculiar about my setup is that I have the SETRAM set for the last three banks of the REU (only 512k, still at the moment) ..I haven't attempted to see if changing the SETRAM back to something more normal to see if that made a diff. Steve Craik ------------ Category 5, Topic 25 Message 56 Wed Dec 30, 1992 HOWIE-CBM at 04:23 EST Steve, I do exactly the same with setram. Lets CS/DOS co-exist with the Pocket programs which use the lower REU banks first. However, when I start stuffing the REU and overwriting upper banks the next entry into CS/DOS then needs a speedy └disk2reu' from RL to REU to be up and running again. Howie ------------ Category 5, Topic 25 Message 57 Wed Dec 30, 1992 B.VRIELING1 at 11:02 EST Howie, Doesn't your AUTOEXEC do this automatically for you? Ie. When it finds that the *IF* command is not in the REU, the logic should cause the batch file to do a GETRAM to restore your ramdisk. Why the need for disk2reu? Steve, Well, if the code works properly with the REU out of the picture, then I would definately have to agree the REU is the problem. At the same time, however, I wonder how that can be the case? Perhaps you should run a verbose description of your RAMLINK setup past CMD- DOUG, and see if he can spot anything wierd. As a matter of fact, post it here so I can see it too. I think we talked in generalities how you have it setup, but be specific - ie. show us how RAMTOOLS says it is configured from the 'display setup' menu item. I hesitate to say CS-DOS is at fault, because I have run code from a NUMBER of different banks (different SETRAM configurations), and have never had a problem like yours. :( ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 58 Wed Dec 30, 1992 HOWIE-CBM at 22:16 EST Bruce, The autoexec does the └if' check. But what has happened is that over the years, as I've seen something I like, I've added it to the ramdisk, with the result that the ramdisk is large. When it requires loading it seems to take a very long time (relatively) even from a RL. So, as a solution I use reu2disk, which as an added bonus puts into the REU the 3 "hidden" modules used by Filer2, and 3 unhidden overlays from Writer3. The reu2disk gets run when I _know_ I've overwritten CS/DOS, usually after some databasing. Otherwise, I enter the normal way and let autoexec decide what to do. Thinking about it an expanded REU might be just the thing I need. Howie ------------ Category 5, Topic 25 Message 59 Wed Dec 30, 1992 S.CRAIK [Steve] at 22:18 EST Hi Bruce, I believe that I ..just happen to stumble on to a CURE to my problem with SEARCH. As you know I have C128D 1571 (8,0) assigned a: 1581 (10,0) assigned b: 1581 (9,0) assigned c: RAMLink w/RTC (11,0) assigned d: (defaulted to 11 and partition 7 so "d:" equals 11,7) Dialogue 1581part. (11,6) assigned e: CS-DOS 1581part. (11,7) assigned f: QWKRR 1581part. (11,8) assigned g: an REU (1.5meg) but switched so only 512k and running thru RAMLink as a DACC (first partition made and used number 31 for its location) setram 21,3 Well upon power-up I use the RL-DOS/Jiffy-Dos, @#11 <return>, to get to the previously setup RAMlink. Since partition 7 is default, all I need do is (SHIFT-RUN/STOP) to load-up CS-DOS. Well, upon you're suggestion, use search not in the REU and or disconnect RAMLink ..check and see if search works then. So I toggled the NORMAL/DIRECT switch to NORMAL, thus eliminating the REU and load/run CS-DOS it put RAMDISK at 01900 something. I then: a: <return> a:search /c filespec *.txt ;all your *.txt files from CS-XTRA4 ;were on a disk in a: (seems I have the BEST results if I make sure whatever device has the files ..is set as current hence the "a: <return>) Well IT WOIKED!! Then I REMOVEd several files from RAMDISK to accommodate the INSTALLing of SEARCH. SEARCH worked installed in the RAMDISK at the 01900 something area. From this point I COLD'ed and toggled NORMAL/DIRECT to DIRECT (bring the REU back in, this RAMDISK is larger and already contained SEARCH..) Well, I decided to check and see what would happen if I toggled out RAMLink. Since CS-DOS is in RAMLink I had to load it from RAMLink once loaded toggle the ENABLE/DISABLE switch to DISABLE. Oh GREAT can't do anything keyboard un-responsive. HIT the RESET.. did a SYS6000 AH,HA! CS-DOS is there! (but, now without any RAMLink partitions) so I proceed: a: <return> search c/ filespec *.txt ;REU was/is active so SEARCH was already ;in the REU. And still had the disk ; with all the files from CS-XTRA4 in ;the drive. It found everything and end correctly. Hmmm? SYS6000? So powered the ol' puter down... set the RAMLink switchs to NORMAL and DIRECT giving me both the REU and RAMlink partitions back again. POWER-UP, @#11 <return>, SHIFT-RUN/STOP Up cmes CS-DOS. I do a COLD then SYS6000. Now I try SEARCH again but this time in a RAMLink partition (at the moment up powerup part 7 is current) so I can ONLY check textfiles that happen to be in that partition. If I want another partition I must use your CP (I've ren'd to rlcp). So it now looks like this when I go: rlcp 8 g: <return> Then to the search on a file in there. IT WORKS! Let do a 1581 drive so I just do a b: <return> ;search for a text in a file on a disk in there BINGO it works there! BOTTOM LINE... It seems I *MUST* do a COLD & then a SYS6000 then SEARCH works for me. Steve Craik ------------ Category 5, Topic 25 Message 60 Thu Dec 31, 1992 HOWIE-CBM at 06:06 EST Steve, I believe you are describing something that I posted about a while ago. That while CS/DOS allows assigning of drives like 16,7, etc., and this works fine with DIR and a few other simple commands, it does not work with ARC nor LHA, etc. For ARC, LHA etc., you must direct access to the default partition. So basically, it sounds like SEARCH is behaving like ARC etc., a function of the CS/DOS system. Howie ------------ Category 5, Topic 25 Message 61 Thu Dec 31, 1992 B.VRIELING1 at 10:17 EST Howie, I have a 1750 expanded to 2 megabytes, and love the extra room. No need for disk2reu, as I never corrupt mine. Just remember that the key to making the expansion 'work' is to keep the new wires inside SHORT. Many people have reported the expansion project is flaky. My wires are super short, and it has worked flawlessly for me - less induction on the shorter wires perhaps? (That's a phrase I've heard, but don't really understand... ;D) Steve, I think Howie hit the nail on the head. I have never tried what Howie suggested, but it is certainly conceivable. And, it would make sense that SEARCH acts like ARC and LHA - it's not a doinky little program like DIR, and is a little bit more 'involved'. I'll bet the problem occurs because for some functions, drive designations other than 0 or 1 are considered 'illegal', but they do work with other functions. Hence a 11,7 would sort of work, but not really, whereas an 11,0 would always be safe. Steve, try doing only what Howie suggested, and get back to us. In essense, he's saying only work with 11,0 - and use the CP or RLCP (as you've renamed it) to change which partition 11,0 (or d:) refers to ie. don't use e: or f: directly, only use the d: designation. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 62 Mon Jan 04, 1993 HOWIE-CBM at 06:42 EST Bruce, I'm convinced! A BIG REU is just the thing I need. Can't figure out why I waited so long! Howie ------------ Category 5, Topic 25 Message 63 Mon Jan 04, 1993 C128.JBEE at 08:37 EST Because you wanted a Ramlink first ;D ------------ Category 5, Topic 25 Message 64 Mon Jan 04, 1993 S.CRAIK [Steve] at 22:33 EST Hi Bruce & Howie, Nope, it doesn't seem to do any good.. anything other than the means I'd discribed.. loading CS-DOS from RAMLink 11,7; doing a COLD, followed by a SYS6000. Is the only can I get SEARCH to work. Steve Craik ------------ Category 5, Topic 25 Message 65 Tue Jan 05, 1993 HOWIE-CBM at 00:40 EST JBEE, Tis too true... I did lust for a RAMLink... :) Steve, I'll try a few SEARCH configs to see what's what. Howie ------------ Category 5, Topic 25 Message 66 Tue Jan 05, 1993 HOWIE-CBM at 02:48 EST Steve, SEARCH ran fine for me, with one hitch. It didn't seem to know when to end. After the end of a file it just kept on running forever. Didn't seem to matter whether SEARCH was run from disk or ramdisk. I duplicated the same steps a second time, using grep. GREP ran properly on the exact same files, all of which were in RL. So, can I be so bold as to suggest that you consider using GREP til SEARCH gets upgraded. GREP and SEARCH use different switches, but they both do the same thing. And, here is a well known but rarely used "bonus" CS/DOS hint for anyone who might happen to be watching this thread, I am replying to you from within the CS/DOS text editor, since it lets me do the testing and conveniently reply at the same time. All in all a very nice computer environment, for just about anything! :) Howie ------------ Category 5, Topic 25 Message 67 Tue Jan 05, 1993 B.VRIELING1 at 19:28 EST Howie, You mean there's a GREP utility that does the same thing as SEARCH? Hmmm. In other words, I've re-invented the wheel. I don't have time to hunt out the differences, if any, between the two commands. What are your impressions? If SEARCH is just another GREP in disguise, I'll dump it from the next release. Comments would be appreciated. ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 68 Wed Jan 06, 1993 HOWIE-CBM at 04:58 EST Bruce, Um.. uh... In a word.... yes.... GREP and SEARCH are identical as to function. Some cosmetic differences tho. It is very easy to miss GREP and some other original CS/DOS tools, since these were released as seperate files. Howie ------------ Category 5, Topic 25 Message 69 Wed Jan 06, 1993 C128.JBEE at 11:50 EST Just search for all files with C.SMEETS as the uploader :) ------------ Category 5, Topic 25 Message 70 Wed Jan 06, 1993 B.VRIELING1 at 20:45 EST Howie, Hmmm. I think it would be wise for me to check out Chris's original tools before writing any more. :)) Let's see... did he ever write a simple ZIP utility? Naw.... ...Bruce GEnie: B.VRIELING1 Internet: bvrieling@undergrad.math.waterloo.edu Fido: Bruce Vrieling @ 1:229/15 ------------ Category 5, Topic 25 Message 71 Thu Jan 07, 1993 HOWIE-CBM at 01:47 EST Bruce, No need for concern there... BVUNZIP is unique, and in fact everything else in the Pack is too! :) Howie ------------ Category 5, Topic 25 Message 72 Thu Jan 07, 1993 B.VRIELING1 at 18:55 EST Howie, If I'm not mistaken (I can't read past messages easily when I'm using Aladdin) my comment was that I hoped that Chris hadn't released any ZIPPER's yet, not UNZIPPER's. ;) In other words, I knew BVUNZIP was unique, but I wanted to make sure my CURRENT project (a zipper) would be unique as well. Before people get excited unnecessarily, this will not be a big thing. I don't plan to COMPRESS files, just zip them by sticking them together (ie. use the STORED type of file). It's only real use would be for those out there who MUST zip files. For example, if one downloads a mail packet (QWRRK?) using ZIP compression, I *THINK* the uploaded packet must be the same compression type. Eg. you set the compression you want to use to be ZIP, and then everything else follows suit. For these people, an unzipper alne doesn't do the job as they need a way to send their replies in zipped form as well. Enter BVZIP. Hope to have this (much smaller project) done soon. ...Bruce ------------ Category 5, Topic 25 Message 73 Fri Jan 08, 1993 HOWIE-CBM at 11:28 EST Bruce, YES!!! A ZIPPER is capability that is NOT now available in any mode. Will be VERY nice to see! :) Howie ------------