Tursi Posted April 19, 2022 Share Posted April 19, 2022 1 hour ago, RXB said: So how do you read more then 127 files on a disk like Classic99 or TIPI? Am I going to have to do sector by sector to read all the file names on a disk as >80 is not allowed in Bytes 6 & 7 of PAB? Hence why RXB Catalog or Directory both stop at 127th filename! The directory limit of 127 files is a limitation of the TI Disk Controller. 2 bytes are used for each file entry, and only a single sector is allocated to the directory, so 127 files plus 2 bytes for the list end. (And I see Lee already wrote this!) In Classic99, the index sector is emulated with the first 127 files in the folder, and the directory sectors are likewise emulated. However, this has all the limits of the TI disk system. If you open the directory as a file (ie: "DSK1.") instead of reading sectors directly, however, there are no limits (just the 32767 record limit). So Classic99 (and presumably TIPI) can return as many files as exist, without limit. This is what the common BASIC directory program does, and why it can dump everything. 5 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 19, 2022 Share Posted April 19, 2022 1 hour ago, Lee Stewart said: Bytes 6 & 7 of a PAB have to do with record number and, you are correct, the left-most bit of byte 6 must be 0, i.e., the record number is either a signed number or the left bit is just ignored by the TI DSR. On the other hand, the number of files on a disk has nothing to do with the PAB. The TI DSR uses sector 1 as the FDIR (File Descriptor Index Record) and uses 16-bit (2-byte) entries for pointers to individual FDRs. Because this alphabetically ordered list must end with a 0 entry, there is only room for 127 entries. DSRs for third-party controllers could differ, obviously. ...lee So you did not answer the question. I do know if I use sector access to jump past 127th filename in directory to next sector I find the next filename and next sector the next one? Quote Link to comment Share on other sites More sharing options...
RXB Posted April 19, 2022 Share Posted April 19, 2022 1 hour ago, Tursi said: The directory limit of 127 files is a limitation of the TI Disk Controller. 2 bytes are used for each file entry, and only a single sector is allocated to the directory, so 127 files plus 2 bytes for the list end. (And I see Lee already wrote this!) In Classic99, the index sector is emulated with the first 127 files in the folder, and the directory sectors are likewise emulated. However, this has all the limits of the TI disk system. If you open the directory as a file (ie: "DSK1.") instead of reading sectors directly, however, there are no limits (just the 32767 record limit). So Classic99 (and presumably TIPI) can return as many files as exist, without limit. This is what the common BASIC directory program does, and why it can dump everything. Hmm once PAB byte 6 & 7 of the PAB hits >80 >00 it stops reading as the is 128 which stops the reading! If does not matter if there are >FF >FF files it will always stop at >80 >00 every time. And opening with "DSK1." makes no difference at all. So sorry but confused about how I am supposed to read all of then in a Catalog? Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted April 19, 2022 Share Posted April 19, 2022 (edited) I believe that the sign BIT of bytes 6 & 7, impose a limit of 32K, as opposed to 64K, on the number of records that can exist within a single file. While the number of directories, and directory entries, are a function of both the disk's layout and the DSR's predicate. Edited April 19, 2022 by HOME AUTOMATION re-worded somewhat 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 19, 2022 Share Posted April 19, 2022 19 minutes ago, HOME AUTOMATION said: I believe that the sign BIT of bytes 6 & 7, impose a limit of 32K, as opposed to 64K, on the number of records that can exist within a single file. While the number of directories, and directory entries, are a function of both the disk's layout and the DSR's predicate. So if I open the file as if it had more then 127 then I should be able to read it? But not allowed to do that.... 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted April 20, 2022 Share Posted April 20, 2022 3 hours ago, RXB said: Hmm once PAB byte 6 & 7 of the PAB hits >80 >00 it stops reading as the is 128 which stops the reading! If does not matter if there are >FF >FF files it will always stop at >80 >00 every time. I am really not understanding what you are getting at. Bytes 6 & 7 of a PAB are read as ONE 16-bit, signed number. The fact that byte 6 by itself has a value of >80, which happens to be decimal 128, is totally irrelevant. However, if the 16-bit word that is composed of bytes 6 & 7 contains >8000, that is definitely not allowed because it is decimal -32768, a negative number. The maximum record number is 32767 (>7FFF), not 127. One other thing to understand is that the catalog “file” does not actually exist. It is an on-demand creation of the DSR and, for the TI DSR, it is limited by the FDIR entries, which can only hold 127 16-bit file pointers plus the list ender. Per @Tursi (if I understand his explanation above), Classic99’s implementation of opening the catalog will allow you to list as many files as are in a given directory as long as that number is not more than 32767. ...lee 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 20, 2022 Share Posted April 20, 2022 @RXB, I modified this extended basic program in line 250 from 127 to 32765 and started cataloging files beyond the filecount of 127. Beery CATALOG1 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted April 20, 2022 Share Posted April 20, 2022 10 hours ago, RXB said: Hmm once PAB byte 6 & 7 of the PAB hits >80 >00 it stops reading as the is 128 which stops the reading! If does not matter if there are >FF >FF files it will always stop at >80 >00 every time. And opening with "DSK1." makes no difference at all. So sorry but confused about how I am supposed to read all of then in a Catalog? Works in Classic99. Classic99 doesn't use the TI Disk Controller DSR. The TI Disk Controller DSR is what imposes the limits - not the TI console. This program happily lists the 876 files in my DSK1 folder. It is a commented copy of the directory program in the disk controller manual (and with directory tags added). 100 CALL CLEAR 110 COUNT=0 120 DIM TYPE$(6) 130 TYPE$(1)="DIS/FIX" 140 TYPE$(2)="DIS/VAR" 150 TYPE$(3)="INT/FIX" 160 TYPE$(4)="INT/VAR" 170 TYPE$(5)="PROGRAM" 175 TYPE$(6)=" <DIR> " 180 INPUT "DEVICE:":DEV$ 190 IF SEG$(DEV$,LEN(DEV$),1)="." THEN 210 200 DEV$=DEV$&"." 210 REM THIS OPENS AS IF/0 - WHICH BECOMES IF/38 220 OPEN #1:DEV$,INPUT ,RELATIVE,INTERNAL 230 REM 'ZERO' IS ALWAYS 0 240 INPUT #1:DISKNAME$,ZERO,DISKSECTORS,FREESECTORS 250 DISPLAY "DSK0 - DISKNAME= ";DISKNAME$:"AVAILABLE= ";FREESECTORS;" USED= ";DISKSECTORS-FREESECTORS 260 DISPLAY :"FILENAME SIZE TYPE P":"---------- ---- ---------- -"; 270 REM A FILETYPE OF 0 ALSO MEANS END OF DIRECTORY 280 REM FILETYPE IS NEGATIVE FOR A PROTECTED FILE 290 INPUT #1:FILENAME$,FILETYPE,FILESECTORS,RECORDLENGTH 300 IF LEN(FILENAME$)=0 THEN 400 310 COUNT=COUNT+1 320 DISPLAY :COUNT;FILENAME$;TAB(12);FILESECTORS;TAB(17);TYPE$(ABS(FILETYPE)); 330 REM PROGRAM FILES DON'T HAVE A RECORD LENGTH 340 IF ABS(FILETYPE)>=5 THEN 370 350 B$=" "&STR$(RECORDLENGTH) 360 DISPLAY SEG$(B$,LEN(B$)-2,3); 370 IF FILETYPE>0 THEN 290 380 DISPLAY TAB(28);"Y"; 390 GOTO 290 400 CLOSE #1 You open the directory as Internal, Fixed, 38, with the file name "DSK1." (the period is important.) Then you read it like any other record file. (IF0 is also legal and will default to IF38). If it's not working in your Classic99, you probably have "Dir: Allow more than 127 files" turned off. Some software will crash with more than 127 files, so it's off by default: 2 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 20, 2022 Share Posted April 20, 2022 Tursi thanks I did have it turned off. So how would I do that with TIPI is there a trick? Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 21, 2022 Share Posted April 21, 2022 Rich, If you want to store and present more files for the display listing, can you test for the SAMS, and if present, buffer a larger listing of files into that memory. Then, page in/out memory to VDP? 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 21, 2022 Share Posted April 21, 2022 2 hours ago, 9640News said: Rich, If you want to store and present more files for the display listing, can you test for the SAMS, and if present, buffer a larger listing of files into that memory. Then, page in/out memory to VDP? Yea but I have to be backwards compatible with Console alone with no 32K or SAMS. You can do some wild stuff with RXB and TAPE alone. Look at my speedy CALL's like HCHAR, VCHAR, HPUT, VPUT, CLEAR, CLEARPRINT, ROLL's and SCROLL's. All faster than any other XB versions and no 32K or SAMS needed. (But you can use them too if needed.) Quote Link to comment Share on other sites More sharing options...
+9640News Posted April 21, 2022 Share Posted April 21, 2022 7 hours ago, RXB said: Yea but I have to be backwards compatible with Console alone with no 32K or SAMS. You can do some wild stuff with RXB and TAPE alone. Look at my speedy CALL's like HCHAR, VCHAR, HPUT, VPUT, CLEAR, CLEARPRINT, ROLL's and SCROLL's. All faster than any other XB versions and no 32K or SAMS needed. (But you can use them too if needed.) Yeah, that is why I suggested a test for the SAM's. If a user is console only, then they are not going to have to deal with more than 127 files and thus no need for a larger display of files than your current method. Then, you just need to differentiate between a 32K system and SAMS setup if a user cataloging a device with more than 127 files and if 1) more than 127 files, and 2) if SAMS is present, buffer the file listing in SAMS. Not sure if there are any TIPI users out there that would NOT have a 32K or SAMS on their system, so the buffering I suggested would just need to differentiate between those two memory configurations. It is just a suggestion to a solution if you want to be able to handle a device path with huge numbers of files. I have no skin in the game and it was just a suggestion since you were trying to handle a larger file count. 1 1 Quote Link to comment Share on other sites More sharing options...
RXB Posted April 21, 2022 Share Posted April 21, 2022 5 hours ago, 9640News said: Yeah, that is why I suggested a test for the SAM's. If a user is console only, then they are not going to have to deal with more than 127 files and thus no need for a larger display of files than your current method. Then, you just need to differentiate between a 32K system and SAMS setup if a user cataloging a device with more than 127 files and if 1) more than 127 files, and 2) if SAMS is present, buffer the file listing in SAMS. Not sure if there are any TIPI users out there that would NOT have a 32K or SAMS on their system, so the buffering I suggested would just need to differentiate between those two memory configurations. It is just a suggestion to a solution if you want to be able to handle a device path with huge numbers of files. I have no skin in the game and it was just a suggestion since you were trying to handle a larger file count. XB (RXB included) does this automatically when 32K is detected for XB programs. i.e. moved from VDP to RAM in upper 24K. And that is a great idea for REA (Rich Editor Assembler) as without 32K expansion that cart is not really useful. Working on a updated version of REA Catalog now thanks! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.