Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!qantel!hplabs!sdcrdcf!burdvax!bpa!cbmvax!daveh
From: daveh@cbmvax.UUCP
Newsgroups: net.micro.amiga
Subject: Re: AmigaDos...
Message-ID: <160@cbmvax.cbmvax.cbm.UUCP>
Date: Mon, 28-Apr-86 17:58:58 EDT
Article-I.D.: cbmvax.160
Posted: Mon Apr 28 17:58:58 1986
Date-Received: Fri, 2-May-86 06:49:52 EDT
References: <1076@h-sc1.UUCP>
Reply-To: daveh@cbmvax.UUCP (Dave Haynie)
Distribution: net
Organization: Commodore Technology, West Chester, PA
Lines: 71

In article <1076@h-sc1.UUCP> breuel@h-sc1.UUCP (thomas breuel) writes:
>A complaint, and two questions:
>
>I have philosophical problems with the AmigaDos file system.
>The file system appears to be optimised for finding a named entry
>quickly and for making directories small and cheap: the directories
>are hashed and do not contain the filenames. This means that for
>wildcard expansion and select-file-dialog-box'es, one block has
>to be read for each entry in a directory.

Cheap directories are important on a small-disk machine.  And at least this
method allows for essentially unlimited directory sizes, unlike other DOS
systems popular on microcomputers today.

>I'm not writing this purely because I disagree with the file system
>structure in some abstract manner, but because for several applications,
>this file system is almost unusable (e.g. picking characters out of
>a 700k Kanji font file).
>
>It should also be noted that a simple disk cache at the disk driver
>level is not necessarily going to improve matters. What is really needed
>is a way to instruct Dos to keep the allocation tables for a specific
>file in memory.
>
>Ultimately, I find that the current file system should be replaced
>with something more UN*X like (with name/inode pairs in directories,
>inodes, and links). I'm not saying this because I find the UN*X
>file system pleasing to the eye, but because it works, and because
>I can do an 'echo *' or 'ls' and don't have to wait for minutes.

Though, really, when was the last time you hacked on lots of UN*X stuff
on a micro with 3 1/2" floppies.  Most of the VAX or SUN machines would
run even AmigaDOS style directories quite a bit faster.

>So, one question, you have seen already: I need a workaround to access
>random parts of a large file quickly. I would greatly prefer not to split
>the file up... (and that wouldn't necessarily help anyhow).
>
>The other question is: how are the ROM Kernel and AmigaDos actually
>glued together? Where and when is each part of the OS loaded? 
>Are there hooks for user file system code (e.g. to implement a remote
>file system)? Pointers to the documentation or straight answers
>would be appreciated.
>
>						Thomas.

You could directly access below AmigaDOS, which is also the answer to your
last question as well.  The ROM Kernal supports a disk-loaded device, called
"trackdisk.device", as the low-level disk interface.  Going any lower would
put you at in direct contact with the hardware, which is something you 
really don't want.  Anyway, the trackdisk device allows read or write of 
any 512 byte block in the disk, and the RKM gives examples of accessing
this in terms of linear blocks, or in terms of track, sector, and disk
side.  In any case, AmigaDOS builds on top of this, assigning specific
values to certain longwords in every 512 byte block.  The AmigaDOS Technical
Reference Manual (from the developer's kit) is a good pointer to the way
DOS organizes directory, file, and data blocks out on the disk.  Last
weekend I saw a consumer version of this book, called the AmigaDOS Reference
Guide, or something like that, in Walden Books in the Deptford Mall in
NJ.  The book actually contained the developers' AmigaDOS User's Manual,
the Developers' Manual, and the AmigaDOS Technical Reference Guide.  For
a specialized application, its certainly possible to go below the DOS
level, and it might even be reasonable to write your data in a DOS 
compatible format, but where you have control over which blocks get allocated
in which order, to perhaps facilitate faster reading of your files.
-- 

Dave Haynie    {caip,inhp4,allegra,seismo}!cbmvax!daveh
               "There, beyond the bounds of your weak imagination
                Lie the noble towers of my city, bright and gold"
								-Genesis