DSTAT.DOC 06/03/86 Every library should have a DOC file... This program dumps all available information in the Disk Parameter Header and Disk Parameter Block. It can be run with no arguments to report on the current disk, or with one argument which is the disk name. Note that since this is NOT a ZCPR utility, named directories are not supported. Nor have I tried this under CP/M 3.0, I have a feeling that at best it would return incorrect data. This is in response to an inquiry by Jay Sage, sysop of the Newton Centre ZNode: (617) 965-7259. See the end of this file for his suggestions and comments. One thing this program does NOT do is trace the vectors in the DPH (the Translation Vector, the Scratch Pad Vector, and the Allocation Vector). Two reasons for this are: I consider their information of limited usefulness, and the single reference I used to write this program, the CP/M 2.2 Operating System Manual, was vague as to the format and size of those vectors. I have A. Johnson-Laird's book, The Programmer's Guide to CP/M_, but it's at home today. Two other things this program does not do are: report on all available disks in the system, and dump the directory buffer. Both things were left out to reduce verbosity. I wrote this in C for one reason: speed in development. Nobody should have any complaints about execution time for this program, and I'll be the first to say that it's Too Damn Big, but you can't beat the time it took to write: three hours, with interruptions. No kidding, I was on the phone to Jay's ZNode at 3:00pm, and it's now 6:15pm. Also, it's a natural for C: only one extra routine (to print a number in binary), no special library routines aside from direct BDOS and BIOS calls, no include files... piece of cake. If I were really concerned with this program, I'd probably re-do it in assembler, using the C source as an outline. However, I view this as one of those utilities you put on the "Miscellaneous" disk, and only drag it out on rare occasions. I compiled it with the Aztec compiler - to be nice to the world at large, I used the 8080 compiler, rather than the Z80 compiler (not a big deal). One fix, however: Aztec uses lower-case letters for their Hex numbers; I patched these (at location A26) to use upper-case. Feel free to elaborate on this program - take my code, please! Wilson H. Bent, Jr. 39 Maple Ave. Fair Haven, NJ 07701 Work: (201) 949-1277 UN*X: ... ihnp4!hoh-1!whb RCP/M: Lillipute: (312) 649-1730 Chicago Msg 095 is 19 line(s) on 05/16/86 from JAY SAGE to PROGRAMMERS about PROPOSAL FOR CP/M BIOS UTILITY I would like to propose a CP/M utility program. There are a number of programs that will print for the user information about his operating system, such as the location of the CCP, BDOS, and BIOS. Some will even display the addresses of the actual BIOS routines as extracted from the initial jump table. I have not seen a program that will work its way through the disk parameter header (DPH) and disk parameter block (DPB) tables for all supported drives and display all the information contained in them for the user. STAT, DU, PATCH, and some other programs will display information about the data format on the drives, but they do not give the addresses of the directory buffer, allocation vector tables, etc. The reason why I wanted this kind of information recently is that I was looking for places in the BIOS to squeeze in the coldboot initialization code for a ZCPR3 installation. This is a handy way to get ZCPR3 running when you have no source for the BIOS but do have a MOVCPM that will move the BIOS. I got the information the hard way (just as the proposed utility would do it), but a ready-made utility would have been nice. The next message has some ideas on how this program would work. Msg 096 is 19 line(s) on 05/16/86 from JAY SAGE to PROGRAMMERS about HOW BIOS UTILITY WOULD WORK Here is how I think the total BIOS information utility would work Basically, the BIOS SELDSK routine (pointed to by the jump at BIOS+1BH) would be called for each disk in turn (0..15 in the C register). This code returns in HL the address of the disk parameter header or 0 if the drive is not a valid drive. With that information the program would simply work its way through the DPH table, following the pointers it contains to the skew translation table, the directory buffer, the disk parameter block (DPB), the directory check vector, and the allocation vector. The DPB would be queried to determine all the disk format information (at least what CP/M knows about it). See David Cortesi's book "Inside CP/M" for good technical information on the BIOS calls and the tables. And note his caution about calling the BIOS SELDSK routine directly. Make sure that the program determines what drive is selected at the beginning and that there is a last call to SELDSK using that drive. I think that should take care of that possible pitfall. One might even make a menu-driven version of this program that would allow the user to specify what information is desired.