\\
At the last V.I.S.A. meeting the question of the whys and hows of multi-block directories came up. For the benefit of those who were not able to be there, I will repeat a little of what was said, and provide some additional useful information on the subject.\\
\\
With the ADAM, a disk or DDP has two limiting factors in its ability to hold information. The first is the number of blocks on the media. (256 for DDP, 160 for original disk drives) The second factor is the number of 'pigeon holes' set aside to hold file names and related information. \\
\\
If there are no more unused blocks on the media, for the storage of information, then the media is full and cannot hold any further data. If there are no more 'pigeon holes' for file names, ADAM cannot store more files, even if most of the media is blank. Unfortunately, unless the media has been "KRUNCHED", the file names of deleted files still take up these spaces after they no longer show up in the directory. \\
\\
One answer to the "pigeon hole" problem is make the directory longer by allocating more blocks to it, and therefore include space for more file names. \\
\\
There are some costs involved, however; \\
1) The more blocks in the directory, the longer it takes ADAM to read the directory. \\
2) Some of the simpler utility programs (including the P.D. one 'FILEMANAGER') were written to assume one block directories and cannot handle anything longer. and \\
3) space given to the directory is not available for actual file storage. \\
\\
For these reasons, it is best not to go beyond 3 or 4 blocks in directory size. My preference is to stick with smaller directories (one or two blocks) on DDPs that will store files that will be used a lot but not changed, but with media used for short term storage of correspondence, or programs in the development stage, I use 3 or 4 block directories.\\
\\
Now the question arises, how do you go about making enlarged directories? It has to be done during INITializing the media. The DDP or disk on which you choose to install a new, larger- than-normal directory, must have no files on it that you want to keep, because access to them will be lost and the space they occupy will be free to be used again when the new "clean" directory is made. \\
\\
\\
\\
\\
There are several ways to proceed. \\
1) You can use the SmartBASIC 1.0 built in INIT command as per usual after you have typed the following - POKE 25308,X - using the number of blocks you want to use for the directory in place of the X, and of course following it by pressing the RETURN key. The normal number in this location is 1, you can POKE it back in after you are finished using INIT for large directories if you want. It will be back to 1 again the next time you load SmartBASIC. \\
\\
SmartBasic's INIT command has a drawback, in that it assumes that the media to be INITed is a normal DDP-sized media, no matter what drive you execute it to, meaning that your directory on a 160K disk will be set up claiming more BLOCKS LEFT than there are. \\
\\
This is solved by:\\
2) Using the NEWDIR program in our P.D. library. This program makes use of it's own INIT-type machine language routine. You simply RUN the program and answer the questions it asks you. No need to POKE anything. It assumes all DDP's are 256K and all disks are 160K. If that is what you use, then everything is fine
ile SmartDSK asks the drive itself what size of media it is set up to work with. This allows it to correctly handle the larger disk drives, but if and when DDPs longer than 256K come into common use in our little group, we may find that this program is not prepared to handle them. Come to think of it, I think it might have a problem with a flippy DDP.\\
\\
P.S. I just came across some notes I had forgotten about. The volume size problem for the Basic INIT method with 160K disks can be solved by POKEing 25305,160, and switching back to 255 when INITing DDPs.\\
\\
\\
EDITOR'S NOTE. Each block of directory space used will set aside 35 filename spaces. Although I have found that large directories are extremely useful in media such as address records, in most cases I prefer to use flippy datapacks with a standard 1 block directory, because of the time it takes ADAM to "search"or "read".