fitzpatrick@vaxine.DEC (02/27/86)
Well, it looks like Sean already did all the work I was planning to do. Now this means I'm going to have to take all my cute little utilities and clean them up so that someone other than myself can deal with them. Regarding EXEC files, Sean wrote: >... It is important I believe to load the text files into a >wordprocessor and save them before trying to exec them. I tried to >anyway with the DOS Kermit, and all I got were errors untill I did this. >... > >Sean Kamath Keep in mind that DOS 3.3 deals with text in negative (or "high") ASCII, that is all the bytes have the high bit set. Most of the rest of the world (including ProDOS and Aztec C) use positive (or "low") ASCII. If you try to EXEC a file that is low ASCII, DOS will see it as garbage. To get around this, in Kermit-65 SET FILE-BYTE-SIZE SEVEN-BIT before doing the download. Kermit (on the Apple) is designed to set the high bit on text transfers when in seven-bit mode. In eight-bit mode, it saves the bytes as received. I ran into the opposite problem when downloading C sources with ASCII Express and then trying to use them in the Aztec C VED editor. It spits up at hi ASCII, because it can't recognize the EOL characters. I eventually intend to make VED itself insensitive to this (I'm currently working on some other enhancements to it now) but in the mean time wrote a little utility called hitolo to strip hi bits. I only have a version to run under the Aztec shell, but could build a stand-alone version in short order if anyone is interested in it. re: Sean's one-liner to make a text file of a BASIC program I don't believe the POKE 33,33 is correct. This will set the screen width to 33 columns (which is what you want to do if you have to retrace a line in an Applesoft program and don't want to get a lot of extra spaces in a PRINT statement that spans two lines). What Applesoft will do in this case is issue a <CR> (which will go into the text file being written) after 33 columns of a line are listed. You need to POKE 33 with a big number (bigger than the # of chars in the longest line of your program) or the resulting file will not EXEC properly. Be sure also to issue a NOMON O command to DOS to prevent the overly long lines from going to the screen or you could end up clobbering all sorts of memory. Dave FitzPatrick ...decvax!decwrl!dec-rhea!dec-vaxine!fitzpatrick on BIX: B-mail to dave.f (co-moderator, leisure conference)
kamath@reed.UUCP (Sean Kamath) (03/03/86)
In article <1412@decwrl.DEC.COM> fitzpatrick@vaxine.DEC writes: > >Well, it looks like Sean already did all the work I was planning to do. >Now this means I'm going to have to take all my cute little utilities and >clean them up so that someone other than myself can deal with them. > >Regarding EXEC files, Sean wrote: > >>... It is important I believe to load the text files into a >>wordprocessor and save them before trying to exec them. I tried to >>anyway with the DOS Kermit, and all I got were errors untill I did this. >>... >> >>Sean Kamath A clerification. I downloaded them with ASCII Express Pro. I loaded them into AppleWriter and then they worked fine. > [Varioes statements about ASCII & high bits which is correct] > >re: Sean's one-liner to make a text file of a BASIC program > >I don't believe the POKE 33,33 is correct. This will set the screen >width to 33 columns (which is what you want to do if you have to retrace a >line in an Applesoft program and don't want to get a lot of extra spaces >in a PRINT statement that spans two lines). What Applesoft will do in >this case is issue a <CR> (which will go into the text file being >written) after 33 columns of a line are listed. You need to POKE 33 with >a big number (bigger than the # of chars in the longest line of your >program) or the resulting file will not EXEC properly. Be sure also to >issue a NOMON O command to DOS to prevent the overly long lines from >going to the screen or you could end up clobbering all sorts of memory. > > >Dave FitzPatrick Dave is right about everything except the way Applesoft handles the poke 33,33 command. It seems that Applesoft does not issue a <CR> after the right number of characters have been output. I tried three different values for the poke 33,x command and made three different file. I tried 33, 40 and 80. I then loaded them into AppleWriter. Even lines longer than 80 characters were intact (no carriage returns). What I do believe is that on the poke 33,40 file, had I had a line with a print statement on it, and had it been longer than 33 characters, you would notice a large space in the middle of that line. Therefore, it seems that you can use either method, poke 33,33 or poke 33,x where x is 1+the longest line length. -- ________________________________________________________________________________ UUCP {ihnp4,decvax,ucbcad}!tektronix!reed!kamath And I looked again And the monster was me...