cj7hawk
Veteran Member
Hi All,
So I'm playing with some of the CP/M routines to complete some final debugging of my code, and working with STAT, I really like what it does, and wanted to be able to use it natively. ( For those who remember my early questions around what CP/M calls I needed to support, STAT was one of the programs expected to use the AV tables and other vectors, which I wasn't originally going to support, then realized I couldn't actually find a better solution. )
So I run STAT on LokiOS ( based on CP/M 2.2 ) and I get the following output ( Standard DR STAT.COM ) - Note- I find it doesn't recognized stat dsk: since it doesn't handle lower case.
M>STAT DSK:
A: Drive Characteristics
5056: 128 Byte Record Capacity
632: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
32: Checked Directory Entries
256: Records/ Extent
16: Records/ Block
32: Sectors/ Track
1: Reserved Tracks
L: Drive Characteristics
464: 128 Byte Record Capacity
58: Kilobyte Drive Capacity
64: 32 Byte Directory Entries
0: Checked Directory Entries
128: Records/ Extent
8: Records/ Block
32: Sectors/ Track
241: Reserved Tracks
M: Drive Characteristics
8192: 128 Byte Record Capacity
1024: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
0: Checked Directory Entries
512: Records/ Extent
32: Records/ Block
32: Sectors/ Track
0: Reserved Tracks
Bad Delimiter
M>
So reading this, and looking at Disk M, where I have 4096 byte sized blocks, hence only use 4 bytes of the allocation vector in the extent, since I'm using single byte descriptors in each allocation.
STAT returns 512 Records/Extent, which technically I guess there are, since 16 x 32 = 512, but of course CP/M doesn't recognize that and only uses the first 4 bytes...
So what is the situation with larger extents? The CR and RC don't support more than 128 records, but STAT reports otherwise, so what is STAT thinking? Was this an aberration caused by simplistic maths within the STAT program, or was there some kind of plan to support super-extents with >128 records?
L: and M: are the same drive, BTW, but L: is a subdirectory of M: and so the number of reserved tracks is correct and not abnormal... And aside from the records/extent all the other data reported by STAT is correct.
Also, just to remind, it's LokiOS - so it's a rewritten CP/M underlying FDOS and it might be caused by my implementation of the BIOS and BDOS, but I am thinking a normal DR written BIOS/BDOS should return the same result, since it's based primarily on the DPB, which is returned as a simple vector to a conforming table in the BIOS.
Thanks
David.
p.s. What are "checked directory entries" also?
p.p.s What is a "bad delimiter" in STAT?
So I'm playing with some of the CP/M routines to complete some final debugging of my code, and working with STAT, I really like what it does, and wanted to be able to use it natively. ( For those who remember my early questions around what CP/M calls I needed to support, STAT was one of the programs expected to use the AV tables and other vectors, which I wasn't originally going to support, then realized I couldn't actually find a better solution. )
So I run STAT on LokiOS ( based on CP/M 2.2 ) and I get the following output ( Standard DR STAT.COM ) - Note- I find it doesn't recognized stat dsk: since it doesn't handle lower case.
M>STAT DSK:
A: Drive Characteristics
5056: 128 Byte Record Capacity
632: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
32: Checked Directory Entries
256: Records/ Extent
16: Records/ Block
32: Sectors/ Track
1: Reserved Tracks
L: Drive Characteristics
464: 128 Byte Record Capacity
58: Kilobyte Drive Capacity
64: 32 Byte Directory Entries
0: Checked Directory Entries
128: Records/ Extent
8: Records/ Block
32: Sectors/ Track
241: Reserved Tracks
M: Drive Characteristics
8192: 128 Byte Record Capacity
1024: Kilobyte Drive Capacity
128: 32 Byte Directory Entries
0: Checked Directory Entries
512: Records/ Extent
32: Records/ Block
32: Sectors/ Track
0: Reserved Tracks
Bad Delimiter
M>
So reading this, and looking at Disk M, where I have 4096 byte sized blocks, hence only use 4 bytes of the allocation vector in the extent, since I'm using single byte descriptors in each allocation.
STAT returns 512 Records/Extent, which technically I guess there are, since 16 x 32 = 512, but of course CP/M doesn't recognize that and only uses the first 4 bytes...
So what is the situation with larger extents? The CR and RC don't support more than 128 records, but STAT reports otherwise, so what is STAT thinking? Was this an aberration caused by simplistic maths within the STAT program, or was there some kind of plan to support super-extents with >128 records?
L: and M: are the same drive, BTW, but L: is a subdirectory of M: and so the number of reserved tracks is correct and not abnormal... And aside from the records/extent all the other data reported by STAT is correct.
Also, just to remind, it's LokiOS - so it's a rewritten CP/M underlying FDOS and it might be caused by my implementation of the BIOS and BDOS, but I am thinking a normal DR written BIOS/BDOS should return the same result, since it's based primarily on the DPB, which is returned as a simple vector to a conforming table in the BIOS.
Thanks
David.
p.s. What are "checked directory entries" also?
p.p.s What is a "bad delimiter" in STAT?