home *** CD-ROM | disk | FTP | other *** search
/ Simtel MSDOS 1992 September / Simtel20_Sept92.cdr / msdos / sysutl / tryst.arc / TRYST2.DOS < prev    next >
Text File  |  1988-03-31  |  13KB  |  229 lines
  1.                 TRYST DOS #2
  2.  
  3.      In the first TRYST DOS article, I covered a few things about how
  4. systems boot up and what errors may occur.  In this article, I will
  5. cover a few more items about booting and what you might try if you get
  6. errors.
  7.  
  8.      Sometimes when you try to boot your system, you get an error
  9. message produced by the boot record on your boot disk.  ALL disks
  10. (including all hard disks and all floppy disks) have boot records;  a
  11. boot record is created during the formatting process.  The boot record
  12. contains instructions describing the kind of disk you are using so
  13. that it may access files on it, and it contains the following error
  14. messages:  "Non-System disk or disk error, Replace and strike any key
  15. when ready" and "Disk Boot failure".
  16.  
  17.      If the boot record can not find IBMBIO.COM and IBMDOS.COM on the
  18. disk you are trying to boot on, you will get the "Non-System disk..."
  19. error.  IBMBIO.COM and IBMDOS.COM are parts of the DOS operating
  20. system.  They are hidden, system files, so you normally do not see
  21. them if you perform a directory.  Utilities such as Norton's will
  22. allow you to look at them, and you can even change the attributes so
  23. they are no longer hidden and can still boot on the disk.  They are
  24. only required to be present and in a particular location to enable the
  25. user to boot up.  If you have just forgotten to put the operating
  26. system on your boot disk, you should do so using either FORMAT B:/S or
  27. SYS B:.  If your boot disk (which can be either a floppy or a hard
  28. disk) already has files on it, there is no longer any room for the
  29. operating system, so you must either copy the files to another floppy
  30. and then reformat the boot disk using the /S parameter with the FORMAT
  31. command (for example, FORMAT B:/S) or delete everything on the boot
  32. disk (DEL *.*) and use SYS to put the operating system on the disk,
  33. (SYS B:).  If you use SYS, remember to copy COMMAND.COM onto the disk
  34. as well.
  35.  
  36.      You may also get the "Non-System disk..." message if the
  37. IBMBIO.COM and/or IBMDOS.COM have become corrupted and are no longer
  38. able to run.  Thankfully, this does not happen often, but if you are
  39. trying to boot and you are sure you have an operating system on the
  40. boot disk, then it is possible that this has happened and you can just
  41. perform another SYS command to put fresh copies of the operating
  42. system back on your boot disk.  (Also, remember to use your backup
  43. copy of the original DOS diskette to perform the SYS or FORMAT
  44. operations, just in case you accidentally tell it to format or perform
  45. the SYS on the wrong drive!) Also, since IBMBIO.COM and IBMDOS.COM are
  46. both hidden, system files, there is really no way of knowing if you
  47. really do have the operating system on your disk, unless you look at
  48. it with Norton's Utilities or some other disk utility that lets you
  49. look at hidden files.  The presence of COMMAND.COM usually indicates
  50. that you do have the system on the disk, but not always.  You can copy
  51. COMMAND.COM to a disk that does not have IBMBIO.COM AND IBMDOS.COM on
  52. it.  COMMAND.COM alone does not make a bootable disk.
  53.  
  54.      The error message "Disk Boot failure" may happen if the boot
  55. record has problems reading the disk, but generally it indicates that
  56. something may have happened to the boot record itself and it can not
  57. call up IBMBIO.COM and IBMDOS.COM to finish the booting process.  When
  58. this occurs, most users find that they must reformat the boot disk,
  59. which means reformatting their hard disk, if they are using one.
  60. (This is where a backup is very nice to have, otherwise you may never
  61. see that data on your hard disk again.) There is one other trick that
  62. you can try though, if you have planned ahead.  You can use DEBUG to
  63. make a copy of your boot record and store that copy on a floppy.
  64. Then, if worse comes to worse, you can attempt to replace a bad boot
  65. record with this copy and see if that cures the "Disk Boot failure"
  66. problem.  The boot record is 512 bytes long, which means it occupies
  67. exactly 1 sector on a disk.  To make a copy of the boot record on a
  68. hard disk, where the hard disk is the C:  drive, you would do the
  69. following, <Enter> means to hit the ENTER key, DON'T TYPE "< E N T E R
  70. >":
  71.  
  72. DEBUG <Enter>                   Start up debug at the prompt
  73. -                               "-" is Debug's prompt
  74. L 100 2 0 1 <Enter>             Enter L for "load"
  75.                                         100 for the address where the
  76.                                                 "loaded" information
  77.                                                 will be stored
  78.                                          2 is the C: drive (0 is A:, 1 is
  79.                                                 B:)
  80.                                          0 is the first sector on the disk
  81.                                          1 is how many sectors you want
  82.                                                 (Boot records are 1 sector
  83.                                                 long, or 512 bytes)
  84. D 100 <Enter>                  *Optional, just to see what has been loaded,
  85.                                         generally, it will at least show
  86.                                         the DOS version, such as IBM 2.1,
  87.                                         on the far right-hand portion of
  88.                                         the screen.  The rest will just be
  89.                                         "garbage" to us, though it means
  90.                                         something to the computer.
  91. N BOOT.REC <Enter>              Enter N for "name" and the name of the
  92.                                         file you want to make out of the
  93.                                         boot record, when you save it.
  94. R CX <Enter>                    Enter R for "register" and CX for the
  95.                                         register name.  You must put the
  96.                                         length of the file in this
  97.                                         register.  The length is 512 bytes,
  98.                                         which is 200 in Hex.  Debug uses
  99.                                         Hex.
  100. 200 <Enter>                     Enter 200 at the ":" prompt.
  101. W 100 <Enter>                   Enter W for "write" to write the data which
  102.                                         starts at 100 (where you loaded
  103.                                         it).  This saves the boot record in
  104.                                         the file you named in the N
  105.                                         command.
  106. Q <Enter>                       Enter Q to "quit" and exit from Debug.
  107.  
  108.      The reason you placed the boot record data at the offset address
  109. 100 in Debug is to enable you to use the N command to name the file
  110. you will create.  This is necessary because N stores the name at 80
  111. hex, so if you loaded the boot record starting at 0, then the part of
  112. the boot record at 80 hex would be overlaid with this file name (which
  113. would, naturally, destroy the data and make the boot record invalid).
  114.  
  115.      The addresses in Debug are really offsets within a particular 64K
  116. section of memory.  This is why you see two numbers on the left-most
  117. portion of the screen when you do a D to "dump" or look at what is in
  118. memory at any point.  Debug displays the addresses as nnnn:nnnn.  The
  119. first 4 digits are WHICH 64Kb segment you are talking about and the
  120. last 4 digits after the colon are an OFFSET within that segment.  So
  121. 100 hex is actually 256 decimal bytes into the segment (the 256th
  122. byte).
  123.  
  124.      Next to the addresses on the line are 16 bytes displayed in hex
  125. and then on the far right is the ASCII (plain english) interpretation
  126. of those data bytes.  Since most of the boot record is data for the
  127. computer's use, it is not in english and just looks like nonsense.
  128. Only the version number and the error messages which may be displayed
  129. to the user can actually be displayed in an understandable form.
  130.  
  131.      If you wish, before you quit from Debug, you can display the boot
  132. records error messages by using the command "D 270" to display what is
  133. in memory starting at 270 hex.  When the boot record is loaded, this
  134. is approximately the address where the error messages are stored.  The
  135. entire boot record itself runs from 100h to 300h if you loaded it into
  136. Debug at offset 100h.  (300h - 100h = 200h which is the length of the
  137. boot record, 512 decimal is 200 in hex).  You can display the entire
  138. boot record by entering "D 100 300").
  139.  
  140.      To use BOOT.REC, you would again go into DEBUG, but this time,
  141. you would load it with BOOT.REC, and then write the data from that
  142. file directly into the first sector on the boot disk.  For example:
  143.  
  144. DEBUG BOOT.REC <Enter>  At the DOS prompt begin Debug with BOOT.REC
  145. -                               this automatically loads BOOT.REC
  146.                                 starting at Hex 100
  147. D 100 <Enter>           *Optional, you can display it if you want
  148. W 100 2 0 1 <Enter>     Enter W to write the data starting at 100 hex
  149.                                 to drive 2 (C:, A: = 0, B: = 1, etc.)
  150.                                 0 means sector 1 on the disk specified
  151.                                 1 for a length of 1 sector (512 bytes)
  152. Q <Enter>
  153.  
  154.      If this doesn't solve the booting problem, you will probably just
  155. have to reformat with the /S parameter to put the operating system and
  156. a fresh boot record on your boot disk.  But, before you do this, just
  157. try doing a SYS and then copy the COMMAND.COM to the boot disk
  158. (presumably the hard disk, it's silly to do this much work for a
  159. floppy).
  160.  
  161.                 What is Actually in the Boot Rec?
  162.  
  163.      Here is the first line of a boot record, shown as Debug would
  164. display it.
  165.  
  166. 255C:0100 EB 34 90 49 42 4D 20 20-33 2E 32 00 02 04 01 00  .4.IBM 3.2.....
  167.  
  168.  
  169.      The 255C:0100 is the address, we are looking at the data starting
  170. at 100h.  The next few double digits are the hex codes for the data,
  171. 49 is the hex for the letter "I", 42 is "B", etc.  On the right is the
  172. ASCII, or english, translation of what those hex codes mean.  If there
  173. is no real english translation for a code, it just displays a ".".
  174. You'll notice that the computer's instructions appear mostly as dots.
  175. You won't see the instructions in english unless you unassemble them.
  176. As a test, you could enter "U 100" to see the first computer
  177. instruction which is a jump to a particular location.  The 90 hex is
  178. simply a NOP, or no operation, code which the computer inserts with a
  179. jump instruction in case the address takes two bytes instead of 1
  180. byte.  (A far address would require two bytes, this address is near).
  181.  
  182.      The boot record begins with a two byte jump instruction which
  183. gets the computer "around" the text and data and into the actual
  184. instructions for it.  On the boot record for my AT's hard disk, the
  185. first two bytes are "EB 34" in hex.  The EB is a jmp instruction and
  186. the 34 is the offset address for the "real" instructions.  When the
  187. ROM BIOS finishes checking the hardware, it looks for a boot record on
  188. either the hard disk or a floppy and then it lets the boot record find
  189. IBMBIO.COM and IBMDOS.COM to finish the boot up process.  So, after
  190. the ROM BIOS finds the boot record on my disk, it starts executing it,
  191. and the first thing that happens is that it jumps to 34 hex and
  192. continues with the instructions it finds there.  It must do this jump
  193. because the stuff after the jump instruction are not computer
  194. instructions at all, but actual data which the user can read.
  195.  
  196.      Following the jump instruction is the version number for the type
  197. of DOS you are using.  On my boot record, it is IBM 3.2.
  198.  
  199.      After the text "IBM 3.2", the data indicates how the disk is
  200. formatted.  The 11th and 12th bytes indicate the number of bytes per
  201. sector (0200h is 512 bytes).  The 13th is the number of sectors per
  202. cluster (on a hard disk with 3.2, it is 04, on a floppy it may be 01
  203. or 02).  The 14th and 15th bytes are the number of reserved sectors at
  204. the beginning of the disk (01 00).  The 16th byte is the number of
  205. copies of the File Allocation Table (FAT) there are (02).  The 17th is
  206. the number of root directory entries (64 or 112, or 0002 which is read
  207. as 200 = 512 entries).  The 19th and 20th contains the total number of
  208. sectors on the disk (07F8 hex).  The 21st is the format ID (F8 on my
  209. hard disk running DOS 3.2).  The 22nd and 23rd are the number of
  210. sectors per FAT (29 00) The 24th and 25th contain the number of
  211. sectors per track (00 11 which is 17 in decimal).  The 26th and 27th
  212. contain the number of heads.  The 28th and 29th bytes contain the
  213. number of special reserved sectors (11 00).
  214.  
  215.      That is a total of 8 fields, which takes up 32 bytes.  After all
  216. the data described here, the boot record has instructions which the
  217. ROM BIOS uses to find whether this is really a boot disk at all
  218. (contains IBMBIO and IBMDOS) or whether one of the error messages
  219. listed above should be sent to the user.
  220.  
  221. The next part of the boot up process is performed by IBMBIO.COM and
  222. IBMDOS.COM.  Since TRYST2.DOS is already too long, TRYST3.DOS will
  223. cover what they do, what error messages you might receive if something
  224. goes wrong with those files, and this will hopefully finish up the
  225. booting process.
  226.  
  227. Amy J. Goebel
  228. ges are stored.  The
  229. entire boot re