Bill Garber writes ... > > "Rubywand" wrote in message .... > : > : Yep. I did a test using an 800k /RAM5. Added two extra blocks > : to the Volume Directory (and marked the blocks as allocated in Block > : 6) and was able to store 77 files there before getting the "Volume > : Full" error. > > Could we get a procedure on how this is done? > Thanks. > .... Sure. As Michael mentioned, you can extend the Volume Directory by adding blocks. In my tryout, the disk was a freshly Inited /RAM5 RAM disk. Using a block editor (like Block Warden) you go to the last block of the Volume Directory, Block 5. You change the second pointer from 00 00 to point to some available block, like Block 9. (Bytes 2 and 3 are changed to 09 00.) Then, you go to Block 9 and point to another block. The Previous Pointer points to Block 5 and the Next Pointer points to, say, Block A (10 decimal). (Bytes 0-3 are 05 00 0A 00.) In Block A, you set the pointers (Bytes 0-3) to 09 00 00 00. The 00 00 for the Next Pointer makes it the last block of the Volume Directory. Finally, you go to the Volume Bit Map allocation table in Block 6 and zero the bits for the blocks you've added to the Volume Directory. For the test, I just set the first two bytes to zero (00 00) which marks all 16 of the first 16 blocks as in use. Evidently, bits are set in left-right order. So, to mark just Blocks 9 and A, you are in the second byte which is set to 1001 1111 = 9F. Now, the disk has two additional Volume Directory blocks, which is space for 26 more file entries. Rubywand ------------------------------------------------- 'ProDOS directories, quoted from Ewen Wannop.' ------------------------------------------------- "Apple, in their infinite wisdom, decided to limit the main directory in ProDOS to 51 files. Sub-directories can of course be of any size, and will dynamically grow as needed as files are added. They do not shrink when files are deleted however, so disk space, once consumed is lost as far as storing files is concerned." "I suspect the 51 file limit was probably due to the fact the ProDOS historically grew out of SOS, the Apple /// operating system." "It is very easy to increase the size of the main directory, and many, many years ago, I wrote a little utility to do this. I can't remember now what I called it, and it may or may not be found on the TABBS Library Archive CD sold by Syndicomm. A quick search did not show anything that matched where I thought it might be, but a closer search may find it." "With that small utility, you could increase the main directory to any size you liked. Having tried this, I found various problems ensued. ProDOS does not expect the size of the main directory to be increased, and although most operations seemed to work smoothly, AppleWorks, and other applications that operate directly on the directory blocks, would cause corruption of filenames and worse, when you tried to write that 52nd file." "So increase the size of the directory at your own peril, and be prepared for some corruption of the directory with certain applications!" 'End Quote' Bill @ GarberStreet Enterprizez };-) Web Site - http://garberstreet.netfirms.com Email - willy4SPAM6pa@comXcast.net Remove - SPAM and X to contact me --- This email ain't infected, dude! Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.588 / Virus Database: 372 - Release Date: 2/14/04 John B. Matthews wrote: >In article <4033D78A.931F3ECB@swbell.net>, > Rubywand wrote: > >> Bill Garber writes ... >>>[perils of extending top level directory] >> Interesting info. Wonder if Ewen tried moving the Volume Bit Map so >that >> he would have contiguous Volume Directory blocks. If he did, then the >failures >> may have been due to Appleworks's assumption that the VBM would start at >Block >> 6. It would be writing file entries to Block 6 _and_ marking the VBM at >Block >> 6-- sure to mess up the directory. > >It's possible, but the location of the pointer to the first VBM >block was well documented in the ProDOS technical reference >manual. For example, see procedure FreeCount in the code at > >http://www.wright.edu/~john.matthews/apple2.html#df > >I always speculated that the limit was a compromise to >accomodate 140K floppies. But why not fixed-allocate just the _first_ block of the Volume Directory, and let it be automatically extended as needed like any subdirectory? This would provide an even lower limit on Volume Directory size (1 block) for small disks and accommodate any size appropriate for large ones. Perhaps the designers were simply hinting at the maximum size they expected for _any_ directory, by enforcing it for the Volume Directory. Linked-list searches on disk are not a very efficient data organization for directory lookups. A fixed-size directory of four contiguous blocks allows for a lookup routine to read the entire directory in as a single I/0 (or at least, without having to seek), then search in the buffer. On the other hand, the links allow for flexible directory size. Perhaps the choice of a fixed-size, contiguous, but linked Volume Directory was just the designer's way to say, "You are free to make subdirectories of any size, but I think that a reasonable practical limit is four blocks worth." This hybrid approach is actually more complex than simply making the Volume Directory the "root" subdirectory, so there must have been some motivation for it. Whatever the reason, the assumption of fixed Volume Directory size has been made for so long that it would be impractical to change it now, except under special circumstances (like the Appleworks 5.25" disk ;-). -michael Check out amazing quality sound for 8-bit Apples on my Home page: http://members.aol.com/MJMahon/ In <20040219034144.11576.00002170@mb-m12.aol.com> Michael J. Mahon wrote: > Perhaps the designers were simply hinting at the maximum > size they expected for _any_ directory, by enforcing it for > the Volume Directory. Linked-list searches on disk are not > a very efficient data organization for directory lookups. > > A fixed-size directory of four contiguous blocks allows for > a lookup routine to read the entire directory in as a single I/0 > (or at least, without having to seek), then search in the buffer. A think you're likely right with your last statement. Whereas DOS was stored on the disk as a nice easy-to-load set of complete tracks at the start of the disk, with ProDOS the OS is stored in a file which can be anywhere on the disk. The only restriction is that the directory entry has to be in the root directory. So the code stored in the boot blocks has to be able to find the OS file and load it into memory, and this code has to fit into just two blocks. Apple's original boot code would load PRODOS if it was booted on an Apple II, or SOS.KERNEL on an Apple III. Most formatting programs, including later ones from Apple, dropped the Apple III support. On these disks the boot code fits in just the first boot block, or less than 512 bytes. It's hardly suprising they wanted the root directory to be in a fixed location! -- Roger Johnstone, Invercargill, New Zealand Apple II - FutureCop:LAPD - iMac Game Wizard http://homepages.ihug.co.nz/~rojaws/ ________________________________________________________________________ Real programmers don't document. If it was hard to write, it should be hard to understand.