Jump to content
IGNORED

Is the file limit of 127 for all disk types?


majestyx

Recommended Posts

Since there's not much info on TI's "DOS" (so to speak) that I know of other than the Disk Memory System manual, I was wondering if the 127 file limit per disk is for all types of diskettes - SSSD through DSDD. I am asking because of my latest project which is most likely going to utilize around 500 text files in addition to the program file(s). My consideration is mainly to figure out if I can make disk images in a way to accommodate the 127 files per disk limitation. I know that the TI Disk Drive Controller only utilizes single-density disks so even double-side ones have this 127 file limit. Maybe a later controller overcame this. If I would want to make a DSDD image, would I still be limited to 127 files or is it dependent on the controller card? It's not really a problem in emulation under Classic99, but I'm thinking of "real world" considerations. I am guessing that by checking the "Allow more than 127 files" box in Classic99 makes the emulator treat the directory as either a hard drive or just simply ignores the 127 file limit. All this wouldn't really matter if there was an easier way to utilize the SAMS expansion from the multiple Extended BASICs available (I'm using T40XB for this project) to either store files like a RAM disk or store variables & arrays that don't eat up program memory.

 

Also, I can't find much info on using hard drives with the TI, probably because I've never used an actual PEB with any of the cool expansions that can be added to it, so I am definitely in the dark about this. I don't think I've ever seen any HDD images for use for the TI, but again, my emulation exposure is mainly Classic99 when it comes to the TI, with very limited use of others such as PC99, Win99Sim, v9t9 & js99er (sorry to mizapf for not using MESS/MAME for TI-99 emulation, as I've only ever used that for arcade emulation, and it's been a few years even for that; I always found configuring it for non-arcade systems a daunting task). Does the limitation also apply to hard disks, or does that depend upon the controller being used? Are hard drives even emulated in any of the emulators or is there really no need to if you can place files into directories? And of course, does the TIPI have a limit on amount of files in a directory?

  • Like 1
Link to comment
Share on other sites

OK, depending upon what you are trying to do.  First, at absolute most, a TI-99/4A Disk Controller will handle at minimum 360 sectors.  It can handle only 127 files.  So, you have 1 sector for sector 0, and sector 1 will be used for the diskmap for the 127 files (256 bytes / 2 bytes (location on disk)).  So, that leaves about 231 sectors to hold the contents of 127 files.  That is 360 - (sector 0) - (sector 1) - 127 (sectors for 127 file bitmaps) leaving 231.  I think my math is right here.

 

If you have a TI-99/4A controller with DS/SD, then take 231 free sectors + the additional 360 sectors, to give you 591 sectors of useable space.

 

If you have a Myarc or CorComp FDC, those can go to double density which gives you up to 1440 sectors.  Again, still limited to 127 files.

 

With a Ramdisk such as a Horizon ramdisk, you still have the same limitations of 127 files even if the image has 3200 sectors.  All you have is more space.

 

Now, if you step to a Myarc HFDC, now you can add three subdirectories on a floppy drive.  So, with the root level of 127 files, plus the 3 directories x 127 files, that gives you around 508 files at absolute maximum.

 

It has been a long time, but I believe with a TI, Myarc, or CorComp floppy disk controller in a Geneve system, you can have 3 subdirectories giving you that total of 508 files at absolute maximum if you have the diskspace.

 

With a Myarc HFDC Hard Drive or a SCSI hard drive, you can have 127 files at the root level, 127 subdirectories at the root level, and each of those subdirectories at their individual root level can have another 127 subdirectories with 127 files until you reach a file-length name of 40 characters including the complete path.  So, something like WDS1.A.A.A.A.A.Filename repeating those A's until you get a full path-length of 40 characters is possible.

 

Things get much simpler with Matt's TIPI structure.  As I understand it, you have no maximum number of files.  You may not be able to catalog the complete listing with most disk managers.  As I understand it, you could put 1000 or more files in one file folder on the TIPI.

 

I should also mention that if you have something you are going to distribute as an application with 500+ files, then the TIPI is probably the method to pursue for development purposes.  It would make it really easy to ZIP up a filepath and distribute a multi-megabyte path that could be unzipped onto the PI. 

 

Let us know if you have additional questions.

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

Thank you, Beery. I do not have a TIPI at this time, but was thinking about how it would work with it should I happen to get one in the future and, more importantly, for those who already have one. Not being able to catalog the files is fine. I just wanted to know if they could be accessed/found when my file reading routine goes to bring each file in.

  • Like 1
Link to comment
Share on other sites

I'd recommend assuming a max of 127 files per disk for the sake of disk only users (there are still many who have a CF7, which is for all intents and purposes a TI disk controller), unless you are explicitly calling out extra hardware.

 

However, if you are thinking about writing new software with hundreds of little files, I'd recommend going with reading parts of larger files instead, again for the sake of floppy users for whom the seek time would be painful (although, this is not much of a CF7 issue, only only true floppies). All methods of accessing a text file allow you to specify a record number, as long as you can get away with fixed-length records. :)

 

(Edit: also, having lots of little files eats a lot of disk space too - at a minimum of 2 sectors per file (one for the file and one for the data). We actually ran out of space on a SSSD in the Megademo just because of all the file descriptors, and went to a single large file instead. ;) )

 

 

 

Edited by Tursi
  • Like 6
  • Thanks 1
Link to comment
Share on other sites

On 2/21/2020 at 5:33 PM, Tursi said:

I'd recommend assuming a max of 127 files per disk for the sake of disk only users (there are still many who have a CF7, which is for all intents and purposes a TI disk controller), unless you are explicitly calling out extra hardware.

 

However, if you are thinking about writing new software with hundreds of little files, I'd recommend going with reading parts of larger files instead, again for the sake of floppy users for whom the seek time would be painful (although, this is not much of a CF7 issue, only only true floppies). All methods of accessing a text file allow you to specify a record number, as long as you can get away with fixed-length records. :)

 

(Edit: also, having lots of little files eats a lot of disk space too - at a minimum of 2 sectors per file (one for the file and one for the data). We actually ran out of space on a SSSD in the Megademo just because of all the file descriptors, and went to a single large file instead. ;) )

 

 

 

I'm now wishing I had asked this question earlier! I'm way too far along to try to combine all the files I have (currently 161) which are each accessed using a specific file name, not to mention having to overhaul the read/display routine, adding more tracking variables, and more.

 

But with that being said, does anyone know the maximum number of RECORDS per file on the TI? I'm thinking about this for future reference.

Link to comment
Share on other sites

35 minutes ago, majestyx said:

 

But with that being said, does anyone know the maximum number of RECORDS per file on the TI? I'm thinking about this for future reference.

My memory is telling me that I read 32,767 somewhere deep in an old TI document.

I will have to search to be certain.  I know the PAB has a 16 bit field to hold the number, so 32,767 fits.

  • Thanks 1
Link to comment
Share on other sites

Not that this is something majesty is concerned with, but the Geneve MDOS PAB was written to be more versatile, however it had issues (bugs) that I discovered in MDOS back around 2004.  The PAB was supposed to allow larger record sizes and more records, but it choked on both I believe.  My intent at the time was to index each verse of the Bible to a specific record and it was just over 32767 records if memory serves me correctly.  Then, record length was the next issue so I had to work within some more limited constraints.

 

I ended up overcoming the issue by creating multiple index files that gave me a sector offset and byte offset into a Program image file for each book/chapter/verse.  I then used sector addressing of the file to locate the information I needed.  The source code is available on the MESS/MAME image I distributed for the various pieces of the program that did the processing should you ever want to look at something along those lines.  There is no reason something like what I did for the Geneve couldn't be done on the 4A as well.  You could use those tools to process into files, and then move them onto something the 4A could handle perhaps on a TIPI drive.

 

Just a FYI, the information I had was a CSV file that had the book, chapter, verse, text laid out for each record.  Program image files were generally about 2000 sectors in length and I think I had something like 8 program image files, and a number of index files.  

 

Source code files for processing and the final program were in the BIBLE directory on the image I distributed.

 

Beery

 

  • Like 2
Link to comment
Share on other sites

8 hours ago, Lee Stewart said:

32,767 records is the correct maximum.              ...lee

 

The only places I could find a reference to the maximum number of records was page 3-3 in the File Management Specification for the TI-99/4 Home Computer in its description of PAB bytes 6 – 7:

Quote

Record number— Only required if the file opened is of the relative record type. Indicates the record number the current I/O operation is to be performed upon (this limits the range of record numbers to 0 – 32767). The highest bit will be ignored by the DSR.

 

This is also paraphrased on page 294 of the E/A Manual. This implies that the actual, maximum number of records is 32768, which is one more than I stated. I could not find an explicitly stated maximum for the 2-byte “number of records” field in the FDR.

 

...lee

  • Like 1
Link to comment
Share on other sites

Well on my SCSI hard drives I have a directory and inside that directory I can put up to 126 sub-directories and each one of those sub-directories I can put 126 more sub-directories and so on...

So with SCSI hard drives the only real limit is the max size of the SCSI hard drive and you can SCSI daisy chain each 7 into another 7 SCSI hard drives thus max out at 49 SCSI hard drives.

 

Now yes it is a pain to address these but if each drive directory name is a letter like 1 or A or X or Y then this is not a real issue.

Example: SCS1.7.X.FILENAME 

This would get SCSI drive 1, directory named 7 then sub-directory named X and from there program FILENAME.

  • Like 1
Link to comment
Share on other sites

32 minutes ago, RXB said:

Well on my SCSI hard drives I have a directory and inside that directory I can put up to 126 sub-directories and each one of those sub-directories I can put 126 more sub-directories and so on...

So with SCSI hard drives the only real limit is the max size of the SCSI hard drive and you can SCSI daisy chain each 7 into another 7 SCSI hard drives thus max out at 49 SCSI hard drives.

 

Now yes it is a pain to address these but if each drive directory name is a letter like 1 or A or X or Y then this is not a real issue.

Example: SCS1.7.X.FILENAME 

This would get SCSI drive 1, directory named 7 then sub-directory named X and from there program FILENAME.

Rich can ou point me to the most up to date docs for thr Wht SCSI controller, I can access it fine with a TI. but last night when I was tryuing to acces it with my Geneve, that I just got back into operation, with mdos 6.70 I kept getting lock up when trying to make a directory under MDOS or copy files .

 

Link to comment
Share on other sites

10 minutes ago, RickyDean said:

Rich can ou point me to the most up to date docs for thr Wht SCSI controller, I can access it fine with a TI. but last night when I was tryuing to acces it with my Geneve, that I just got back into operation, with mdos 6.70 I kept getting lock up when trying to make a directory under MDOS or copy files .

 

Use MDOS 6.50.  Not sure if your issue is related to 6.70, but Tim has warned about usage of the 6.70 as something corrupted his system.

 

Beery

  • Like 1
Link to comment
Share on other sites

4 hours ago, RickyDean said:

Rich can ou point me to the most up to date docs for thr Wht SCSI controller, I can access it fine with a TI. but last night when I was tryuing to acces it with my Geneve, that I just got back into operation, with mdos 6.70 I kept getting lock up when trying to make a directory under MDOS or copy files .

 

Like most SCSI cards the DSR was modified and I lost everything after the update. Turns out originally there was a error in the DSR.

I would suspect your Geneve just got hit with same upgrade.

Link to comment
Share on other sites

May not hurt to run a memory test with the MEMTEST program to see if something is going on.  The original Geneve eprom just checks memory pages >00 to >3F while your onboard 32K ram plus the additional 32K ram that was added is not tested.  I guess there is a chance something could be going on with that memory.

 

Beery

  • Like 3
Link to comment
Share on other sites

Not to keep taking this off topic but MDOS 6.50 does not properly sense the PDMA status of the SCSI card.  Type "PDMA" at the command line. If it is off, type "PDMA ON" then try to catalog the devices.

 

By default, SCS1. corresponds to SCSI ID 0.  SCS2. to ID 1 and SCS3. to ID 2.   Termination is also important.   

 

Probably should move this conversation to one of the Geneve threads from last year...

 

  • Like 3
Link to comment
Share on other sites

  • 2 years later...

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!

Link to comment
Share on other sites

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!

Does RXB Catalog/Directory stop at the first 127 listings, or does it give you 127 filenames plus another 114 directory names as well if they exist?  There is a PI.CONFIG DIR_SORT I think is the name of the option that gives you an option on how reading records for a file/directory listing will be presented.

 

John Johnson wrote a program for the Geneve, XDIR, that uses the DSR to grab the listing of files by reading records.  No requirement to read sectors.  Pretty much the same way extended basic reads files though I do not know if it goes over a count of 127 files/directories.  You may need to modify the routine to look for <End of Record> rather than stopping at a specific count.  I know you want to do things in GPL instead of assembly language, but if you want to look at the code to see the concept, let me know.  You don't want to buffer the listing, rather, just scroll the listing of the files.

 

I've got one TIPI directory with over 2000 filenames in it and I know of a couple of other users with that same cache of files as well.

 

Under MDOS where the DIR command is used, we capped the number of files shown at 127 and directories at 114 and provided a message indicating more files and/or directories exist but are not shown as the file/dir details exceed an 8K buffer that was alloted for the routine.

 

Beery

  • Like 2
Link to comment
Share on other sites

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!

 

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

  • Like 3
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...