rknop@nntp-server.caltech.edu (Robert Andrew Knop) (02/28/91)
elwin@hubcap.clemson.edu (lawrence brown) writes: >All of the .doc files are in the directory as SEQuential. When >I try to LOAD any of them, preperatory to LISTing them. I get a >file not found error. The problem is, SEQ files can't be loaded like PRG files can. You need some sort of sequential file reading utility to read the documentation, as commodore DOS has no built-in way to do this. A number of these utilities exist. If you are on a 128, the KeyDOS utility by Randy Winchester (found at milton) will do this (and a whole lot else). On the 64, if you have Q-Link, the program omega-q can type sequential files. Another 64 program to type 64 files is called sprint. If you are really stuck, you can cludge it with this BASIC program: 10 open 1,8,1,"filename,s,r" 20 if st<>0 then 50 : rem this line may be wrong, somebody correct me 30 get#1,a$:printa$; 40 goto20 50 close 1 I just threw that off of the top of my head, so there may be something wrong with it, but the basic idea is OK, I think. If there is demand, later (when I am at my 128) I will post sprint here. -Rob Knop rknop@tybalt.caltech.edu
c9037544@cc.newcastle.edu.au (David Williams) (02/28/91)
> The problem is, SEQ files can't be loaded like PRG files can. Actually, it is possible. When using the SAVE and LOAD commands, just inserting a ,s before the end quote in the filename will specify a SEQ file rather than a PRG file. A USR file can be specified by using ,u. This could be used a small way of protecting your programs from others, perhaps. ------------------------------------------------------------------------------- | David Williams | University of Newcastle | | c9037544@cc.newcastle.edu.au | Department of Computer Science (Undergrad) | |-----------------------------------------------------------------------------| | "The decision of Random Numbers is too important to be left to chance !" | -------------------------------------------------------------------------------
dattier@ddsw1.MCS.COM (David W. Tamkin) (03/02/91)
rknop@nntp-server.caltech.edu (Robert Andrew Knop) wrote in <1991Feb27.213545.18354@nntp-server.caltech.edu>: | 10 open 1,8,1,"filename,s,r" | 20 if st<>0 then 50 : rem this line may be wrong, somebody correct me | 30 get#1,a$:printa$; | 40 goto20 | 50 close 1 That won't work; the print statement (to the screen) in line 30 will re-zero st and the loop will not break when the end of the disk file is reached. Try something like this: 10 open1,8,1,"filename":forx=0to1:get#1,a$:x=st:printa$;:next:close1 The for-next loop will execute faster than an if structure with gotos; BASIC is slow enough to need all the help it can get. David Tamkin Box 7002 Des Plaines IL 60018-7002 708 518 6769 312 693 0591 dattier@ddsw1.mcs.com MCI Mail: 426-1818 CIS: 73720,1570 GEnie: D.W.TAMKIN
cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (03/02/91)
In article <1991Mar02.032753.23899@ddsw1.MCS.COM> dattier@ddsw1.MCS.COM (David W. Tamkin) writes: >| 30 get#1,a$:printa$; > >That won't work; the print statement (to the screen) in line 30 will re-zero >st and the loop will not break when the end of the disk file is reached. I can't let this go by...The print statement will NOT change the ST variable at all. Only statements that perform serial or RS-232 I/O will affect ST, meaning only PRINT# or GET# statements. (Well, a POKE to 144 would have an effect...) Anyway, PRINT or GET statements from screen or keyboard do not affect ST. -- David DeSimone, aka "Fuzzy Fox" on some networks. /!/! INET: an207@cleveland.freenet.edu / .. Q-Link: Fuzzy Fox / --* Quote: "Foxes are people too! And vice versa." / ---
CTuna@cup.portal.com (Image - BBS) (03/03/91)
It's ok... printing to the SCREEN leaves ST intact. If you print to a FILE (i.e. printer, disk), then you would want to use that code. But for screen alone, uou are ok.
dattier@vpnet.chi.il.us (David W. Tamkin) (03/03/91)
cs4344af@evax.arl.utexas.edu (David "Fuzzy Fox" DeSimone) wrote in <1991Mar2.115333.11011@evax.arl.utexas.edu>: | In article <1991Mar02.032753.23899@ddsw1.MCS.COM> dattier@ddsw1.MCS.COM | (David W. Tamkin) writes: | >That won't work; the print statement (to the screen) in line 30 will re-zero | >st and the loop will not break when the end of the disk file is reached. | I can't let this go by...The print statement will NOT change the ST | variable at all. Only statements that perform serial or RS-232 I/O will | affect ST, meaning only PRINT# or GET# statements. (Well, a POKE to 144 | would have an effect...) Anyway, PRINT or GET statements from screen or | keyboard do not affect ST. Fuzzy Fox's 64 and mine must have different OS's in ROM then, or at least different BASIC interpreters. In order to use the FOR-NEXT loop instead of gotos (and speed the routine up), one needs x=st somewhere in there, and even if printing to the screen doesn't affect st and you can set x=st after the PRINT, it doesn't hurt to do it between the GET# and the PRINT. Of course, if you are printing a disk file to the printer, my original caution stands uncontested. David Tamkin PO Box 7002 Des Plaines IL 60018-7002 dattier@vpnet.chi.il.us GEnie:D.W.TAMKIN CIS:73720,1570 MCIMail:426-1818 708 518 6769 312 693 0591 "Parker Lewis Can't Lose" mailing list: write flamingo-request@ddsw1.mcs.com
dattier@ddsw1.MCS.COM (David W. Tamkin) (03/03/91)
c9037544@cc.newcastle.edu.au (David Williams) wrote in <9678.27cd0f47@cc.newcastle.edu.au>: | > The problem is, SEQ files can't be loaded like PRG files can. | Actually, it is possible. When using the SAVE and LOAD commands, just | inserting a ,s before the end quote in the filename will specify a SEQ file | rather than a PRG file. A USR file can be specified by using ,u. This could | be used a small way of protecting your programs from others, perhaps. That can be done as long as the file contains program data. If the purpose is to read the contents of a sequential file as text, loading "file,s" will get it into memory but won't be a good way to read it! (You can then examine memory with a machine language monitor but the formatting won't be very good, and you can come up with some screen code vs. character code and even ASCII vs. PETSCII problems, depending on the format of the stores file and the way the MLM displays memory locations.) And if you try to load it and list it, every PETSCII capital in the file will get expanded into whatever BASIC keyword uses that value as its token. What David Williams brought up can be done, but I don't think it's useful for the original poster's intentions. (I've responded in this thread to two other people who share my first name, and their last initials are my first two initials. Curious.) David Tamkin Box 7002 Des Plaines IL 60018-7002 708 518 6769 312 693 0591 dattier@ddsw1.mcs.com MCI Mail: 426-1818 CIS: 73720,1570 GEnie: D.W.TAMKIN "Parker Lewis Can't Lose" mailing list: write flamingo-request@ddsw1.mcs.com
c9037544@cc.newcastle.edu.au (David Williams) (03/04/91)
> | > The problem is, SEQ files can't be loaded like PRG files can. > > | Actually, it is possible. When using the SAVE and LOAD commands, just > | inserting a ,s before the end quote in the filename will specify a SEQ file > | rather than a PRG file. A USR file can be specified by using ,u. This could > | be used a small way of protecting your programs from others, perhaps. > > That can be done as long as the file contains program data. If the purpose > is to read the contents of a sequential file as text, loading "file,s" will > get it into memory but won't be a good way to read it! > And if you try to load it and list it, every PETSCII capital in the file will > get expanded into whatever BASIC keyword uses that value as its token. > What David Williams brought up can be done, but I don't think it's useful for > the original poster's intentions. > (I've responded in this thread to two other people who share my first name, > and their last initials are my first two initials. Curious.) Yes, you are completely correct - I did not look at the question properly, not having much time that day. There does seem to be a few David W's around, still, I happen to think that its a pretty good name to have, don't you agree?! What I would like to know though, is why it took so long for someone to respond to my posting - I am not saying this as I am vain, but to see if it because there is quite some time before a posting from Australia will get to the outside world? We recieve yours within only a short time of being posted. ------------------------------------------------------------------------------- | David Williams | University of Newcastle, Australia | | c9037544@cc.newcastle.edu.au | Computer Science student | | c9037544@jupiter.newcastle.edu.au | | |-----------------------------------------------------------------------------| | "The decision of Random Numbers is too important to be left to chance !" | -------------------------------------------------------------------------------
digdon@ug.cs.dal.ca (Mike Digdon) (03/04/91)
In article <1991Mar02.032753.23899@ddsw1.MCS.COM> dattier@ddsw1.MCS.COM (David W. Tamkin) writes: >rknop@nntp-server.caltech.edu (Robert Andrew Knop) wrote in ><1991Feb27.213545.18354@nntp-server.caltech.edu>: > >| 10 open 1,8,1,"filename,s,r" >| 20 if st<>0 then 50 : rem this line may be wrong, somebody correct me >| 30 get#1,a$:printa$; >| 40 goto20 >| 50 close 1 > >That won't work; the print statement (to the screen) in line 30 will re-zero >st and the loop will not break when the end of the disk file is reached. >Try something like this: > >10 open1,8,1,"filename":forx=0to1:get#1,a$:x=st:printa$;:next:close1 > >The for-next loop will execute faster than an if structure with gotos; BASIC >is slow enough to need all the help it can get. > >David Tamkin Box 7002 Des Plaines IL 60018-7002 708 518 6769 312 693 0591 >dattier@ddsw1.mcs.com MCI Mail: 426-1818 CIS: 73720,1570 GEnie: D.W.TAMKIN Wnat to make that a little faster? If there is a return at the end of each line in the text file, then change the line like this: 10 open1,8,1,"filename,s,r":forx=0to1:input#1,a$:x=st:printa$:next:close1 This will print the text very fast, as (typically, a text file is 80 cols across, for printing purposes) instead of doing 80 i/o's per line, you are in essence only doing 1. Of course, if you want it any faster, ml is the way to go.. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Mike Digdon: digdon@ug.cs.dal.ca + My 64 can still get the + + mike@ac.dal.ca + job at hand completed!! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
digdon@ug.cs.dal.ca (Mike Digdon) (03/04/91)
In article <39733@cup.portal.com> CTuna@cup.portal.com (Image - BBS) writes: >It's ok... printing to the SCREEN leaves ST intact. If you print to a >FILE (i.e. printer, disk), then you would want to use that code. But for >screen alone, uou are ok. Actually, printing to the printer doesn't make any difference either. Since you have to read from the disk first, if a problem occurs, then you have a chance to use ST to end the program before it gets printed. Here is the code that I use when printing SEQ files: 10 open4,4,7:open2,8,2,"filename,s,r" 20 get#2,a$:ifst<>0thenclose2:close4:end 30 print#4,a$;:printa$;:goto20 And it runs with no problems everytime, and it always stops when it is supposed to (IE: at the end of the text file) -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Mike Digdon: digdon@ug.cs.dal.ca + My 64 can still get the + + mike@ac.dal.ca + job at hand completed!! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
bruce@watnxt2.ucr.edu (Ahmon Dancy) (03/05/91)
you're right, that input#2,a$ would be faster but I think everyone knows the problem with the INPUT command like: it stops at colons, commas and I think it is limited to 88 characters. Sometimes that is not sufficient. BRUCE!
CTuna@cup.portal.com (Image - BBS) (03/05/91)
Mike, using the #input instead of the #get will kill any lines that have a comma, semicolon, or colon in them. It will read ONLY as far in the line as the punctuation. That's why I suggested the #get. A lot slower, but will read the whole file. Don
digdon@ug.cs.dal.ca (Mike Digdon) (03/05/91)
Actually, it has no problems like colons and commas at all... the biggest problem is when a line is more than 255 characters long. I have printed thousands of blocks of text files with absolutely no problem at all.. except the problem of too long a line.. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Mike Digdon: digdon@ug.cs.dal.ca + My 64 can still get the + + mike@ac.dal.ca + job at hand completed!! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
digdon@ug.cs.dal.ca (Mike Digdon) (03/06/91)
This is turning out to be quite a discussion... however, I have the ultimate solution.. in the c64 dir on milton, there is a program there called Ultra. This is a seq file reader. It is in basic, but is it ever fast. It will do ASCII conversions and everything. So, if you are looking to read SEQ files, this is the program to look for... quite nice.. -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Mike Digdon: digdon@ug.cs.dal.ca + My 64 can still get the + + mike@ac.dal.ca + job at hand completed!! + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
dattier@vpnet.chi.il.us (David W. Tamkin) (03/06/91)
digdon@ug.cs.dal.ca (Mike Digdon) wrote in <1991Mar4.132134.27485@cs.dal.ca>: | 10 open4,4,7:open2,8,2,"filename,s,r" | 20 get#2,a$:ifst<>0thenclose2:close4:end | 30 print#4,a$;:printa$;:goto20 | And it runs with no problems everytime, and it always stops when it is | supposed to (IE: at the end of the text file) Nope. ST goes nonzero when you read the last character in the file. The code you posted would never print the last character. If the last character is a carriage return, BASIC will stick one in before "ready." (I think), so maybe you haven't noticed the problem. You might get "ready." on the next line after your text without a blank line in between, which wouldn't bother you. But if there is something odd about the text file and the last character is not a CR, you won't see it printed. Earlier Commodore systems (I don't know whether it was the drive's doing or the computer's doing) did give a zero value for ST as long as a character was read and went nonzero only after you tried to read past the end of the file, and for them Mike Digdon's code is correct. You can also change "ifst<>0" [which could have been shortened to "ifst" but that's another matter entirely] to "ifst=66" or "if2andst" [do not use "ifstand2" because BASIC will read the TAN keyword before it recognizes the ST reserved variable; "ifst and2" will work] in line 20. Then you'll get the last character as well. ST goes to 64 when you read the last character and to 66 when you try to read past it. And of course, input# is faster since there are fewer calls to the BASIC interpreter, fewer loops, and fewer serial accesses, but if there is a comma, a colon, or a linefeed in the line, what gets read won't get written. For a BBS I once helped run, we used to add 128 to all risky characters in bulletin files so that INPUT# could read and preserve whole lines. The modem-output routines stripped the high bits, so the callers saw normal text. David Tamkin PO Box 7002 Des Plaines IL 60018-7002 dattier@vpnet.chi.il.us GEnie:D.W.TAMKIN CIS:73720,1570 MCIMail:426-1818 708 518 6769 312 693 0591 "Parker Lewis Can't Lose" mailing list: write flamingo-request@ddsw1.mcs.com