[Coco] Undocumented NitrOS9 system call (Boisy?)

[Aaron Wolfe]

In the rbf module you can see what SS.FDinf does:

SSFDInf cmpb #SS.FDInf
bne L056B
lbsr L0D72 check for sector flush
bcs Gst5FF
ldb R$Y,u get MSB of sector #
ldx R$U,u get LSW of sector #
lbsr L0CEB read the sector
bcs Gst5FF error, return
ldu PD.RGS,y get register stack pointer
ldd R$Y,u get length of data to move
clra clear MSB
bra L0564 move it to usr

Basically just reading some bytes from the sector specified into your
process memory, which makes sense given how the RBF file system works,
basically a directory is just a file with the filenames and the lsn of the
sector containing that file's descriptor.  Looks like you have the
arguments correct to me.  Should work fine and much faster than opening
files.

On Wed, Nov 4, 2015, 9:19 PM Bill Pierce via Coco <coco at maltedmedia.com>
wrote:

> In messing with my directory read in MShell, I was looking at the NitrOS9
> "dir" cmd to see if I could use that code to make my directory reads faster
> by using ML code instead of C. My problem is I want to read the file
> descriptor info for each dir entry when I read the dir (similar to "dir
> -e").
> I have a routine that does this, but it's so slow, I can't use it when the
> dir is read. I use it when the user requsts file stats, then it reads just
> that file's descriptor, but I really need them read all at once. To read
> this info in C, inline in my program, it takes about 3 minutes on a dir of
> 592 files (my cmds dir :-), and this is reading it into a memory buffer.
> The nitrOS9 dir cmd scrolls the info on the screen in just a few seconds,
> and with all the print stuff happening as well.
> My program uses the getstat "SS.FD" call which returns the file descriptor
> data, but to use this call, the file has to be opened. So my program would
> have to open and close 592 files on my cmds dir to get all the info in one
> shot.
> In looking at the NitrOS9 dir cmd, it uses "SS.FDInfo", which according to
> the changelog, is a new getstat that was added by Boisy in Nov of 2005. I'm
> not sure if it was actually new, or just undocumented and never used until
> then.
> This call does not seem to require the file to be opened. The directory
> itself is already open, so it seems to load each file descriptor location
> from the tail end of the filename in the directory listing (bytes 30-32 of
> the dir entry).
> Now my question is... what are the calling parameters of this getstat?
> The list in the dir cmd is:
>
> * Use SS.FDInf to get the file descriptor sector
> pshs  u
> lda   <dent+DIR.FD
> ldb   #FD.Creat-FD.ATT
> tfr   d,y
> leax  <fdsect,u
> lda   <dirpath
> ldb   #SS.FDInf
> ldu   <dent+DIR.FD+1
> os9   I$GetStt
>
> dent is the 32 byte buffer in which the dir entry is stored. DIR.FD is the
> last 3 bytes of this buffer (file descriptor offset). #FD.Creat-FD.ATT is
> equivilent to 16 (size of the descriptor buffer). So from the above
> listing, I'm assuming (after all regs are loaded) that:
>
> A=path
> B=SS.FDInfo (getstat cmd)
> Y: Y/MSB=MSB of file descriptor offset (24 bit) Y/LSB=Number of bytes to
> retrieve
> X=Address of destination buffer
> U=LSW of file descriptor offset (24 bit)
>
> Does this seem correct to you NitrOS9 asm gurus?
>
>  If this is correct, I can do the equivilent in C or even asm and not have
> to open and close every file in a dir as that's what's slowing down my
> current method. This just seems to do direct reads from the file descriptor
> without opening the file... correct? (Boisy maybe?)
>
>
> Thanks :-)
>
>
>
> Bill Pierce
> "Charlie stole the handle, and the train it won't stop going, no way to
> slow down!" - Ian Anderson - Jethro Tull
>
>
>
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> https://sites.google.com/site/dabarnstudio/
> Co-Contributor, Co-Editor for CocoPedia
> http://www.cocopedia.com/wiki/index.php/Main_Page
> Global Moderator for TRS-80/Tandy Color Computer Forums
> http://www.tandycoco.com/forum/
>
> E-Mail: ooogalapasooo at aol.com
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>