MEELISSE@HROEUR5.BITNET (04/15/88)
I have written a short BASIC program to read the contents of a ProDOS directory and put it in a string array (see below). All works fine until I try reading my /RAM disk... Just after the filenames have been read and before the "Blocks free..." line should be read, I get an OUT OF DATA error and the program stops executing. Why does this happen? Is there anything I can do to prevent it? The program looks like this: 100 D$=CHR$(4): PRINT D$"OPEN/RAM,TDIR" 110 PRINT D$"READ/RAM" 120 INPUT S1$ : INPUT S2$ : INPUT S3$ : INPUT S4$ 130 I=1 140 INPUT F$(I) : IF F$(I)<>"" THEN I=I+1 : GOTO 140 150 INPUT BLOCKS$ 160 PRINT D$"CLOSE" (I use an Apple //c and ProDOS 1.2) Danny Lagrouw, MEELISSEN@HROEUR5.BITNET
carlb@pro-avalon.cts.COM (Carl Boernecke) (04/17/88)
Try something like: 10 D$=CHR$(4):PRINT D$"OPEN /RAM,TDIR":PRINT D$"READ /RAM" 20 INPUT DN$:INPUT I$:REM DN$=DIRECTORY NAME, I$=DUMMY INPUT 30 ONERR GOTO 50:I=1 40 INPUT F$(I):I=I+1:GOTO 40 50 CALL 62248:POKE 216,0:PRINT D$"CLOSE" 60 BLOCKS$=F$(I):NF=I-3:REM BLOCKS$="BLOCKS FREE...", NF=NUMBER OF FILES 70 END Of course, you must add a DIM F$(###) statement at the beginning of this program if you have more than nine files in the directory you are reading. Also, the CALL 62248:POKE 216,0 is just a fix to the AppleSoft ONERR routine.
jetzer@studsys.mu.edu (jetzer) (04/18/88)
In article <8804152230.aa12184@SMOKE.BRL.ARPA>, MEELISSE@HROEUR5.BITNET writes: > I have written a short BASIC program to read the contents of a ProDOS > directory and put it in a string array (see below). All works fine until I > try reading my /RAM disk... Just after the filenames have been read and > before the "Blocks free..." line should be read, I get an OUT OF DATA error > and the program stops executing. Why does this happen? Is there anything > I can do to prevent it? > The program looks like this: > 100 D$=CHR$(4): PRINT D$"OPEN/RAM,TDIR" > 110 PRINT D$"READ/RAM" > 120 INPUT S1$ : INPUT S2$ : INPUT S3$ : INPUT S4$ > 130 I=1 > 140 INPUT F$(I) : IF F$(I)<>"" THEN I=I+1 : GOTO 140 > 150 INPUT BLOCKS$ > 160 PRINT D$"CLOSE" This is a bug in the ProDOS /RAM driver, which has existed since the birth of ProDOS. It has something to do with the fact that, in order to maximize storage space and avoid conflicts with certain memory locations in aux mem, the first blocks (volume directory, bitmap, etc) are non-standard. A more thorough discussion of this is presented in the November 1986 issue of NIBBLE magazine. A fix for this is also included, but it's a program that has to be run every time you boot. Don't you hate line counters? ??????? -- Mike Jetzer "If you can't be right, be forceful"
lazarus@igloo.UUCP (David Sugar) (04/18/88)
In article <8804152230.aa12184@SMOKE.BRL.ARPA>, MEELISSE@HROEUR5.BITNET writes: > I have written a short BASIC program to read the contents of a ProDOS > directory and put it in a string array (see below). All works fine until I > try reading my /RAM disk... Just after the filenames have been read and > before the "Blocks free..." line should be read, I get an OUT OF DATA error > and the program stops executing. Why does this happen? Is there anything > I can do to preve There is a 'strange' bug in ProDOS. It always assumes a volume directory is 4 blocks long, even if, as in the case of the /ram volume, it is not. If a volume directory is less than the preset maximum, the next directory 'block' is all zero'd except for the backlink, which does point to the previous directory block. Every extra block after this is zero as well, including the link fields. A simple file dump program (not block editor) will show this parculiarity. It does also occur if you format 'regualr' ProDOS devices (3.5, 5 1/4, etc) with smaller directories (I created a utility awhile back that let me resize volume directories). Dave ..igloo!lazarus n
brsmith@umn-cs.cs.umn.edu (Brian R. Smith) (04/25/88)
In article <8804152230.aa12184@SMOKE.BRL.ARPA> MEELISSE@HROEUR5.BITNET writes: >I have written a short BASIC program to read the contents of a ProDOS >directory and put it in a string array (see below). All works fine until I >try reading my /RAM disk... Just after the filenames have been read and >before the "Blocks free..." line should be read, I get an OUT OF DATA error >and the program stops executing. Why does this happen? Is there anything >I can do to prevent it? > >Danny Lagrouw, >MEELISSEN@HROEUR5.BITNET I've got an idea; The directory on /RAM is shorter than what is on standard floppies (only 12 entries). If you ever need more than that, it'll grow, but as /RAM is only 60K, it's not often. Brian brsmith@umn-cs.cs.umn.edu brsmith@umn-cs.UUCP brsmith%umn-cs@UMNACVX.BITNET