Jump to content
IGNORED

Is the file limit of 127 for all disk types?


majestyx

Recommended Posts

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.

 

  • Like 5
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

:ponder:

Edited by HOME AUTOMATION
re-worded somewhat
  • Thanks 1
Link to comment
Share on other sites

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.

:ponder:

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....

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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:

 

image.png.fc704be7990fcf4ae43b8a7173ca0359.png

 

image.thumb.png.da57e7a34a870c16ab44c48265cd7c4f.png

 

  • Like 2
Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

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!

  • Like 1
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...