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 / ZSUS / Z3HELP-5.LBR / T.LBR / T4GEN.HZP / T4GEN.HLP
Text File  |  2000-06-30  |  3KB  |  78 lines
  1. ;
  2.                                   T4GEN.COM                                   
  3.  
  4.              Size (recs) CRC   Version    Author/Latest Issue      Disk
  5.                3k (19)   44A6  1.0        Ludo VanHemelryck 4/89   Z3COM9 
  6.  
  7.   1- Syntax  2- Notes                                                         
  8.  
  9.  
  10.    T4GEN opens  an alternate  route  to  the generation  of Type-4 object code 
  11. modules.   According  to Jay Sage  (TCJ #34),  the generation  of such modules 
  12. necessitate either advanced utilities or a cumbersome DDT operation.   Using a
  13. pair of Intel HEX format input files which can readily be produced in a number
  14. of ways,  T4GEN directly outputs  a Type-4 module,  incorporating the required 
  15. TYP4LDR header in the process.
  16. :1
  17.  
  18.  
  19.    Syntax:  <[du:|dir:]fn1> [du:|dir:][<fn2>]
  20.  
  21.     where.. fn1 = filename of input file pair:  <fn1>.HX0/<fn2>.HX1
  22.  
  23.             fn2 = filename of output file (optional)  
  24. :2
  25.  
  26. T4GEN Notes:
  27.  
  28.    a.  A Type-4 object code module has three components:
  29.  
  30.        - The actual code, assembled to a defined origin of either 0 (SPR-type) 
  31.          or 100h (PRL-type),
  32.  
  33.        followed by:
  34.  
  35.        - A  bit-map identifying the location sensitive bytes within  the code,
  36.  
  37.        and preceded with:
  38.  
  39.        - A loader  program  which inserts the  code  at the  desired location, 
  40.          adjusting all location sensitive bytes in the process.   In  order to 
  41.          enable it to interpret the relocation bit-map, this loader program is 
  42.          informed both about the length  and the assembly origin of the actual 
  43.          code.
  44.  
  45.  
  46.  
  47. T4GEN Notes (cont'd):
  48.  
  49.    b.  T4GEN obtains its actual code by loading a HEX file, assembled to 100h, 
  50.        and determines the program length at that time.   T4GEN then inserts  a 
  51.        relocation bit-map obtained by comparing the HEX file assembled at 100h 
  52.        to an assembly at org 0 of the same source.   Finally,  T4GEN inserts a 
  53.        PRL compatible loader header into the Type-4 module.
  54.  
  55.    c.  The input HEX files can be generated by assembling the same source file 
  56.        twice,  with both a 0 and a 100h origin.  The source file may have only
  57.        a  single absolute org statement,  all others being relative.   Similar 
  58.        HEX files can  be generated  by linking the  same series of REL modules 
  59.        to *.HEX, with both  a 0 and  a 100h origin.   T4GEN distinguishes both 
  60.        input files  by their <type> extension of *.HX0 (0 org) and *.HX1 (100h 
  61.        org), and it is necessary to rename the HEX files accordingly.
  62.  
  63.  
  64.  
  65. T4GEN Notes (cont'd):
  66.  
  67.    d.  The use of a pair of HEX files is debatable:  a similar procedure could 
  68.        be devised using COM files.   Some  assemblers  will  not  generate COM 
  69.        files directly,  and require  an additional LOAD conversion step.   The 
  70.        HEX format provides exact code length  info,  which can only be defined 
  71.        in terms of records for  a COM file.   The LOAD  conversion  is readily 
  72.        built into T4GEN.
  73.  
  74.    e.  The source for a Type-4 program  must conform to  the ZCPR Type-3 or -4 
  75.        format, particularly  with respect  to the  value at  offset 11.   (See 
  76.        discussion  of the  value stored  at this  address  in TYP4LDR.Z80/.LIB 
  77.        comments)
  78.