home *** CD-ROM | disk | FTP | other *** search
/ Piper's Pit BBS/FTP: ibm 0020 - 0029 / ibm0020-0029 / ibm0028.tar / ibm0028 / EPTOOLS1.ZIP / TK.HLP < prev    next >
Encoding:
Text File  |  1989-08-08  |  8.3 KB  |  185 lines
  1.  
  2.  
  3.  
  4. Tookkit  is  a  a  file  oriented  binary editor along with file conversion
  5. utilities to transfer binary data to  or  from  Motorola  S  or  Intel  Hex
  6. format.   The  binary  file  is generally produced by reading an EPROM with
  7. Ross Custom Electronics DumBurner Support software.  This file will then be
  8. a "disk image" of the EPROM.  That is, byte zero of the EPROM will  be  the
  9. first  byte  of the disk file, and so on.  Alternately, the binary file may
  10. be produced by use of an assembler or cross assembler which produces  Intel
  11. Hex  or  Motorola  S code; Menu options 4 or 6 would then be used to create
  12. the binary file.
  13.  
  14. Since the binary file,  which  contains  non-ASCII  characters,  cannot  be
  15. manipulated  with  a  standard  editor such as Wordstar, the Toolkit editor
  16. (menu options 1 and 2) provides a method to manipulate these files.
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23. +EJECT
  24.  
  25.                       Using the Toolkit Binary Editor
  26.  
  27. If you are editing a binary file read from EPROM or  converted  from  Intel
  28. HEX  or Motorola S format, Menu Option 1 (Edit Existing File - no expansion
  29. allowed) will usually be the appropriate choice.  If you are building a new
  30. file or adding on to the end of an existing file Menu Option 2 (Edit File -
  31. Expansion allowed) should be used.  The two  menu  options  are  identical,
  32. except  that  option  1 will not allow the file to "grow".  After selecting
  33. menu option 1 or 2, enter the file name you wish to edit.
  34.  
  35. Those familiar with CP/M's DDT will find the operation of Toolkit's  binary
  36. editor  similar.   The  first  128  bytes  of  the  file  are automatically
  37. displayed.  Data is displayed 16 bytes on a line.  The address of the first
  38. byte is on the left side of the display.  The numbers across the top of the
  39. display represent the least significant part of the address, which must  be
  40. added  to the address on the left to obtain the full address of one byte of
  41. data.  On the far right of the screen, the 16  bytes  of  binary  data  are
  42. interpreted  in ASCII.  This allows much easier observation of the data you
  43. are editing.
  44.  
  45.  
  46. +EJECT
  47.  
  48.  
  49.  
  50. You will be asked whether you want to  modify  the  data  on  the  display,
  51. install  modified  data  to disk, or display another block of data.  If you
  52. are just observing the data in the binary file, pressing return will  bring
  53. up  the  next  block of data; or you may enter any address within the file.
  54. Note that if you enter an address which occurs in the middle of a 128  byte
  55. block,  such  as 3F9, the editor will begin the display at the beginning of
  56. that block, or 380 in this example.  The data for  the  address  3F9  would
  57. occur in the last line of the 128 byte block.
  58.  
  59. Once  you  find  the  block  of  data  you wish to edit, use the M (Modify)
  60. command to begin the edit session.  NOTE THAT NO CHANGES ARE  MADE  TO  THE
  61. DISK  FILE  UNTIL  YOU SPECIFICALLY INSTALL THEM TO DISK WITH THE I OPTION.
  62. You will now be requested to enter the address you  wish  to  modify.   The
  63. address  you  enter must be in the 128 byte block, or an error will result.
  64. The address is entered in hex, and may be from  1  to  4  characters  (i.e.
  65. leading zeros are not required.) Data similar to the following will then be
  66. displayed:
  67.  
  68.  
  69. +EJECT
  70.  
  71.  
  72.      03F9  41  A
  73.  
  74. The  first  number  is the address you requested.  The second number is the
  75. data in that address, represented in hex.  The third number  is  the  ASCII
  76. character  represented by the hex data.  You may now enter the new data, in
  77. hex.  Either one or two digits may be entered.  You may enter the  data  in
  78. ASCII  by  preceeding  the  character  with  a  single quote (i.e. 'B would
  79. replace the ASCII A in the example above with an ASCII B)
  80.  
  81. Once you enter the new data, the editor will automatically advance  to  the
  82. next byte in the 128 byte block of data.  If you just press RETURN, without
  83. entering  any data, the current location will not be modified, and the next
  84. location will be displayed.  If the next location is outside the  128  byte
  85. block  (i.e.  advancing  from  3FF  to  400)  the editor will redisplay the
  86. current block of data with all changes (i.e. it will  not  advance  to  the
  87. next  block).   Remember  that changes have not been installed to disk, and
  88. will not be until you select the Install option.
  89.  
  90.  
  91.  
  92. +EJECT
  93.  
  94.  
  95.  
  96.  
  97.  
  98. You may "back up" to review or reenter data for the  previous  location  by
  99. pressing  -.  Exit by pressing Q or a period.  Exit will cause the question
  100. "Address to Modify?" to again be displayed.  If you do not  wish  to  enter
  101. more  data  in this block, again use Q or a period to exit.  The full block
  102. of data, with all changes, will then be  displayed.   Be  sure  to  INSTALL
  103. these  changes  to  the  disk  (with  the  I  option)  to  make the changes
  104. permanent.  As the changes are installed to the disk, you may  or  may  not
  105. see  indication  of  drive  activity.   Many  CP/M  and MS-DOS systems will
  106. "buffer" several blocks of data before actually writing them to  the  disk.
  107. All  data  will  automatically  be sent to the disk drive when you exit the
  108. editor with the Q option.
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. +EJECT
  116.                          File Conversion Utilities
  117.  
  118. Menu option 3 through 6 are fairly self explanatory.  You will be  required
  119. to  enter  the  name  of  a  binary  file and either an Intel HEX file or a
  120. Motorola S file.  If you are converting from  Intel  HEX  to  binary  (Menu
  121. option  4) or from Motorola S to binary (Menu option 6), a few restrictions
  122. apply.  First, leading characters in the line are not allowed.   Intel  Hex
  123. files  must begin with a : as the first character in each line.  Motorola S
  124. files must begin with an S as the first character in each line.  If leading
  125. characters exist, they can be removed with a standard text editor  such  as
  126. Wordstar.
  127.  
  128. A  characteristic  of  both Intel HEX and Motorola S files is that, since a
  129. new address is specified on each line of the file, it is possible  for  the
  130. data to "jump around" in memory.  It is possible that the first line of the
  131. file  specifies  that  the  data  is  to  be  installed at location 10, for
  132. example, and the second line specifies that the data is to be installed  at
  133. location  8000.   This  would obviously leave many unspecified locations in
  134. the middle.  Toolkit will fill the unspecified locations in the binary file
  135. with nulls (00) in cases such as these.
  136.  
  137.  
  138. +EJECT
  139.  
  140. It is also conceivable that the Intel HEX or Motorola  S  file  jumps  from
  141. location 8000, for example, in the first line, to location 10 in the second
  142. line.   This  will  only  occur  if  the  assembly  language source program
  143. contained an ORG (orgin) instruction to a lower location in memory.  A JUMP
  144. FROM A HIGH ADDRESS TO A LOWER ADDRESS IN AN INTEL HEX OR MOTOROLA  S  FILE
  145. IS NOT ACCEPTED BY THE TOOLKIT FILE CONVERSION UTILITIES, AND WILL GENERATE
  146. AN  ERROR.   If  you  cannot  fix the source code which caused the ORG to a
  147. lower memory address, it is possible to rearrange the lines  in  the  Intel
  148. HEX or Motorola S file with a text editor such as Wordstar.
  149.  
  150. Conversions  from  Binary  to Intel Hex, or from Binary to Motorola S (Menu
  151. Options 3 and 5) are generally unnecessary.  One reason for  this  type  of
  152. conversion  might  be  to  enable  a  binary  file  to  be  sent  across  a
  153. communications link with ASCII characters.  If this is done, you  must  use
  154. Toolkit  at  the other end to convert the file back to binary.  CP/M's LOAD
  155. command should not be used due to address specifications  in  the  0000  to
  156. 0100 range, which is a reserved area in CP/M.
  157.  
  158.  
  159.  
  160.  
  161. +EJECT
  162.  
  163.  
  164.  
  165.  
  166. You  may  use Toolkit's binary editor to examine and/or modify COM files in
  167. both CP/M and MS-DOS.  Remember, however,  that  Toolkit's  editor  assumes
  168. that  the  first byte on the disk file is data for address 0, when in fact,
  169. CP/M assumes that the first byte on the disk file is data for  address  100
  170. hex.   Therefore, all addresses displayed by the Toolkit editor will be off
  171. (low) by 100 hex.  The same thing occurs if a  COM  file  is  converted  to
  172. Intel  HEX  format  using  Toolkit's  Menu option 3.  All Intel HEX address
  173. specifications will be low by 100 hex.  As mentioned earlier, this is not a
  174. problem if Toolkit, rather that CP/M's load, is used to  convert  the  file
  175. back to binary.
  176.  
  177.  
  178.  
  179. +END
  180.  
  181.  
  182.  
  183.  
  184. +EJECT
  185.