home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / BEEHIVE / ZCAT / DSTAT01.LBR / DSTAT.DOC < prev   
Text File  |  2000-06-30  |  5KB  |  101 lines
  1. DSTAT.DOC                        06/03/86
  2.  
  3. Every library should have a DOC file...
  4.  
  5. This program dumps all available information in the Disk Parameter
  6. Header and Disk Parameter Block.  It can be run with no arguments to
  7. report on the current disk, or with one argument which is the disk
  8. name.  Note that since this is NOT a ZCPR utility, named directories
  9. are not supported.  Nor have I tried this under CP/M 3.0, I have a
  10. feeling that at best it would return incorrect data.
  11.  
  12. This is in response to an inquiry by Jay Sage, sysop of the Newton
  13. Centre ZNode: (617) 965-7259.  See the end of this file for his
  14. suggestions and comments.
  15.  
  16. One thing this program does NOT do is trace the vectors in the DPH
  17. (the Translation Vector, the Scratch Pad Vector, and the Allocation
  18. Vector).  Two reasons for this are: I consider their information of
  19. limited usefulness, and the single reference I used to write this
  20. program, the CP/M 2.2 Operating System Manual, was vague as to the
  21. format and size of those vectors.  I have A. Johnson-Laird's book,
  22. The Programmer's Guide to CP/M_, but it's at home today.
  23.  
  24. Two other things this program does not do are: report on all available
  25. disks in the system, and dump the directory buffer.  Both things were
  26. left out to reduce verbosity.
  27.  
  28. I wrote this in C for one reason: speed in development.  Nobody should
  29. have any complaints about execution time for this program, and I'll be
  30. the first to say that it's Too Damn Big, but you can't beat the time it
  31. took to write: three hours, with interruptions.  No kidding, I was on
  32. the phone to Jay's ZNode at 3:00pm, and it's now 6:15pm.  Also, it's a
  33. natural for C: only one extra routine (to print a number in binary),
  34. no special library routines aside from direct BDOS and BIOS calls,
  35. no include files... piece of cake.  If I were  really concerned with
  36. this program, I'd probably re-do it in assembler, using the C source
  37. as an outline.  However, I view this as one of those utilities you put
  38. on the "Miscellaneous" disk, and only drag it out on rare occasions.
  39.  
  40. I compiled it with the Aztec compiler - to be nice to the world at large,
  41. I used the 8080 compiler, rather than the Z80 compiler (not a big deal).
  42. One fix, however: Aztec uses lower-case letters for their Hex numbers;
  43. I patched these (at location A26) to use upper-case.
  44.  
  45. Feel free to elaborate on this program - take my code, please!
  46.  
  47. Wilson H. Bent, Jr.
  48. 39 Maple Ave.
  49. Fair Haven, NJ  07701
  50. Work: (201) 949-1277
  51. UN*X: ... ihnp4!hoh-1!whb
  52. RCP/M: Lillipute: (312) 649-1730 Chicago
  53.  
  54.  
  55. Msg 095 is 19 line(s) on 05/16/86 from JAY SAGE
  56. to PROGRAMMERS about PROPOSAL FOR CP/M BIOS UTILITY
  57.  
  58. I would like to propose a CP/M utility program.  There are a number of
  59. programs that will print for the user information about his operating
  60. system, such as the location of the CCP, BDOS, and BIOS.  Some will even
  61. display the addresses of the actual BIOS routines as extracted from the
  62. initial jump table.  I have not seen a program that will work its way
  63. through the disk parameter header (DPH) and disk parameter block (DPB)
  64. tables for all supported drives and display all the information contained
  65. in them for the user.  STAT, DU, PATCH, and some other programs will
  66. display information about the data format on the drives, but they do not
  67. give the addresses of the directory buffer, allocation vector tables, etc.
  68.  
  69. The reason why I wanted this kind of information recently is that I was
  70. looking for places in the BIOS to squeeze in the coldboot initialization
  71. code for a ZCPR3 installation.  This is a handy way to get ZCPR3 running
  72. when you have no source for the BIOS but do have a MOVCPM that will move
  73. the BIOS.  I got the information the hard way (just as the proposed
  74. utility would do it), but a ready-made utility would have been nice.
  75.  
  76. The next message has some ideas on how this program would work.
  77.  
  78. Msg 096 is 19 line(s) on 05/16/86 from JAY SAGE
  79. to PROGRAMMERS about HOW BIOS UTILITY WOULD WORK
  80.  
  81. Here is how I think the total BIOS information utility would work
  82.  
  83. Basically, the BIOS SELDSK routine (pointed to by the jump at BIOS+1BH)
  84. would be called for each disk in turn (0..15 in the C register).  This
  85. code returns in HL the address of the disk parameter header or 0 if the
  86. drive is not a valid drive.  With that information the program would
  87. simply work its way through the DPH table, following the pointers it
  88. contains to the skew translation table, the directory buffer, the disk
  89. parameter block (DPB), the directory check vector, and the allocation
  90. vector.  The DPB would be queried to determine all the disk format
  91. information (at least what CP/M knows about it).  See David Cortesi's book
  92. "Inside CP/M" for good technical information on the BIOS calls and the
  93. tables.  And note his caution about calling the BIOS SELDSK routine
  94. directly.  Make sure that the program determines what drive is selected at
  95. the beginning and that there is a last call to SELDSK using that drive.  I
  96. think that should take care of that possible pitfall.
  97.  
  98. One might even make a menu-driven version of this program that would allow
  99. the user to specify what information is desired.
  100. 
  101. One might even make a menu-driven version of this program