What is the simplest usable disk file system to implement? More specifically, if your going to write a disk file system from scratch, what would be the easiest way to implement some basic file system functionality? How did some of the very early DOS systems allocate disk space in the days before FAT tables, etc? Just how simply can this be done?

This sounds just about right, vintage-wise! Ok, so once you have a hole, do you only recover that disk space by SQUEEZEing the disk? I think RT-11 works this way, at least I recall the SQUEEZE command making the disk free space larger. Is a FAT needed for this, or is there a simple way to calculate this on the fly? Jim Battle wrote:

Bob Shannon wrote: yes, although the OS supplied command that does this can't do an in-place squeeze. the command is MOVE, and it copies the first disk to the second disk while removing any SCRATCH'd files along the way. I'm sure people did write their own in-place squeeze programs, but it would be inherently hazardous. Because the file system doesn't have a linked list or indirection table of some kind, you can't incrementally move around pieces of the file safely. You have to atomically move the entire program and update the catalog. So the build in command, MOVE, required the squeeze to happen during a whole-disk copy so that the integrity of the source disk was never compromised.

On Monday, July 28, 2003, at 04:59 AM, Jdavis wrote: Can I have your XL1200 when you do? (; ok bear

I've just spent the afternoon making .dsk images of my Basis 108 disk collection. There is a lot of stuff here, including two different version of the Basis system disks (there were four different MB revisions,) CPM 3.0, and a bunch of Basis User Group Library disks (mostly for CP/M.) There are CPM drivers for the Sider HD, Vista 8" controller card, Saturn 128k, Mountain ThunderClock, and possibly more -special patches had to be made for these cards to work properly with the Basis CP/M 3.0. I haven't cataloged most of these disks, so I'm not entirely sure of what is on them. I've just been systematically making the images but I do know that all of these disks were created on a Basis 108, and were modified to run on the Basis so they probably will not work properly on an Apple II. If anyone has a Basis 108, and you need the system disks, etc., let me know and I'll send you a Zip file with all of this stuff. I'm not completely finished yet but I made images of the important stuff. There are probably close to 100 images. Ernest http://12.228.5.66 leucoplast(a)seanet.NOSPAM.com (remove the NOSPAM to email me.)

ben franchuk wrote: Very tempting, as I'm adding a file system to a threaded interpreter (not FORTH). But a basic block system is just too primative. Named files at a minimum.

Just how much code does this take, and where can I find source? Patrick Rigney wrote:

Fred Cisin wrote: Err, well, ok. I'm adding a file system to a custom programming language and operating system combination. The CPU is an HP minicomputer, ranging from 2116's up through the 21MX machines. Disk drives may range from the HP 7900A to CS/80 drives, as well as a custom ATA disk controller for HP 1000's. So disk sizes range from 5 mb per physical volume to 8 gb (or more) for the ATA disk. Media interchangability is not a factor. Basically a friend of mine and I, with some additional help, have written a threaded interpreter for HP 1000's that is designed to be a tool for bootstrapping and restoring any HP CPU with a full megaword of memory. We already have a sort of 'linear' file system for 7970-series mag tape, and are now working to add a file system to this beast. SIMH recently added (buggy) HP 7900 disk emulation, and in real-hardware land we have working CS-80 and ATA disk subsystems with working low-level code. So the trick is to write a layer between the threaded engine and the low level disk driver code. Having looked at several modern file systems, we can see where a lot of complexity comes from. But the machines we are writing code for predate these file systems by a decade or more. So these approaches don't seem to be a good fit at all. Something more along the lines of the Northstar DOS system looks more attractive. We are looking for a 1960's to 1970's sort of approach, only with reasonable file name sizes. Subdirectories are not mandatory if we can have several named logical units on a large physical drive (like the ATA controller).

Bob, I looked in my archives, and I've got a much older implementation of the library referenced in my earlier posting that does not support directory structure, just flat filesystem--saves a lot. I'll send that under separate cover. --Patrick

On Sun, 27 Jul 2003, Bob Shannon wrote: One such way: Have some portion of the disk set aside for a fixed number of directory entries (the "directory"). Each directory entry has a certain number of characters for a filename (12 is good), a file type byte, a status byte, and a pointer to the portion of the disk where the file is stored. The file data is then stored on consecutive sectors, with the last one or two words (depending on word size implemented) pointing to the next sector of the file. Zero values means "end of file". There also needs to be a map somewhere specifying which sectors are free/used. This is basically how most early microcomputer DOS works. I take my example from Apple DOS 3.3. Anything simpler would involve having files take up static areas of the disk, perhaps defined by track boundries, with a fixed number of directory entries (as defined by the total number of file areas) and a limited file size (as defined by the size of each file area). -- Sellam Ismail Vintage Computer Festival ------------------------------------------------------------------------------ International Man of Intrigue and Danger http://www.vintage.org * Old computing resources for business and academia at www.VintageTech.com *

It was thus said that the Great Bob Shannon once stated: Make the slots too big, and you limit the number of files available and waste much of the space on the disk. Too small, and you have overflow (file is too big for a slot). Fast, efficient (disk space usage), easy (to implement): pick any two 8-) I have come up with a system that is easy to implement, is quite efficient of disk space, but don't bother with measuring the speed because it will be S-L-O-W ... if you want fast and efficient, then possibly a B-tree or B-* disk format would be the way to go, but then that's not too easy to implement. Using a file per track is fast and easy, but doesn't use space efficiently. It also depends upon the size of the disk you are going to use---up to a few meg in size the MS-DOS FAT system (12 or 16 bit variants) will probably be the best bet---well documented with the ability for interoperability between most systems. -spc (my two bits worth ... )

Vintage Computer Festival wrote: <snip> It all comes down to available memory. We are talking about CPU's with a logical address space of 32K words. Much of that is already used, so I need something very small. And how 'correct' would it be to have a modern file system running on an HP2116 anyway? It may be far from practical.

On Sun, 27 Jul 2003, Bob Shannon wrote: What size drive? You might want something different for an 80G drive than for a 100K floppy I thought that you said that you wanted PRACTICAL It is unusual for somebody to set out to write a file system who isn't already familiar with what's been done before. (some say that UCSD P system was the last time that one was written by people who had no idea what they were doing) Do you WANT it to be compatible with anything else? If NOT, then you will also have to write conversion software. Maybe not now, but someday. Greatest compatibility would be to implement the MS-DOS structure. To make it simple, you can wait and add sub-directory support later (like MS did with 2.00) But if you want to roll your own from scratch, . . . Your drive head will spend more time in the DIRectory than anywhere else. (Yes, it could be cached in RAM, but remember the fiasco that resulted in having to release MS-DOS 6.2x!) Does your drive have a track 0 switch? If so, then that's where you oughta put the DIRectory. (CP/M (after reserved track(s)), MS-DOS, MAC 400/800K, etc.) If not, then consider mid-disk. (TRS-DOS, Coco, MS Stand-alone BASIC (NEC-DOS, etc.), OS/2 HPFS, etc.) Putting the DIRectory at the beginning of the usable space simplifies a few things. Decide how large an allocation unit you want. Large ones make for fewer to keep track of, with possible performance benefits, but wast more space if you use a lot of tiny files. You COULD use blocks that are SMALLER than a sector (128 bytes, ...); but you said simple. Decide the DIR structure. Fixed size for each FPDE (File Primary Directory Entry) avoids some unnecessary hassles. Filenames shorter than 8.3 are too short. Long filenames make for a much more complex DIR structure. (NOTE: Windoze does NOT have long filenames. It has 8.3 filenames, PLUS a file can also have a "nickname" that is NOT stored in that file's FPDE (MS stores the nicknames in the space that would otherwise have held FPDEs, but does NOT store it as an FPDE)) UCSD P system stores starting and ending block numbers, and can not have a non-contiguous file. CP/M stores a list of block numbers, and when that overflows the space provided in the FPDE, an additional directory enty is needed for the file. TRS-DOS stores a short list of starting points plus length for each starting point. Apple-DOS stores starting point, and then each file contains IN THE FILE'S SPACE, pointers to the next space. Thus forming a linked list of sectors, but giving you 254? bytes of data in each 256 byte sector. MS Stand-Alone BASIC, MS-DOS, and MAC 400K/800K use a linked list of block numbers stored in a separate section of the DIR. (MAC 400k/800k uses the same structure as MS-DOS, with just enough changes to not be interchangeable. (serious shortage of systems programmers in those days)) If you want full functionality, then nothing is going to be significantly less work to implement than MS-DOS, which would give you disk interchangeability.

On Sun, 27 Jul 2003, Bob Shannon wrote: That was what Jobs intended for the Lisa. backfired. Of course it is an option. IFF you want. "Beginning of usable space" would mean immediately following whatever fixed location stuff there is. MS-DOS and MAC DIR follows the boot record. DEC Rainbow MS-DOS follows a "boot track" This is fixed size for the directory ENTRY, NOT file allocation. Some systems, mostly in order to accomodate long filenames, use a variably sized entry in the directory. Then it sounds like the decision is made!

Is the file size limited to the number of blocks that can be represented in a single map block, or does it allow multiple map blocks? If the latter, how does it chain them? --Patrick

Lets not forget the old machines too often had fixed data areas on media used as scratch storage. A single page of memory often was the only room a OS could use for all device handeling and bootstrapping. You often had to have a system that could load a paper tape image in core memory all ready and then work from disk or mag tape. A fixed file size is not a problem since only with text editing do you need a variable file size.