[Coco] Undocumented NitrOS9 system call (Boisy?)

[Bill Pierce]

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