home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 7 Games / 07-Games.zip / VTREK.ZIP / VTREK.DOC < prev    next >
Text File  |  1989-12-26  |  5KB  |  116 lines
  1. December 1989:
  2. -------------
  3.  
  4. Visual Startrek  resurrected and ported to OS/2 (and MSDOS) using
  5. the  Microsoft C compiler version 5.1 and  associated programming
  6. tools.
  7.  
  8. VTREK is  the "make"  file for  Microsoft C.   It will generate a
  9. bound program capable of running under OS/2 or MSDOS. It requires
  10. the ANSI.SYS driver under MSDOS or the equivalent (ANSI ON) under
  11. OS/2.
  12.  
  13. MAKEFILE.HTC is the make file for compiling the CP/M version with
  14. Hi-Tech C.
  15.  
  16. VTREK.EXE is the executable for MSDOS and OS/2.  VTREK.CPM is the
  17. compiled executable for CP/M.  Rename it to VTREK.COM.
  18.  
  19. December 1986:
  20. -------------
  21.  
  22. This  is  the latest version of the public-domain  program  VTREK 
  23. (Visual STARTREK), hot off the UNIX networks.  Have a look at the 
  24. file VTREK.HLP for a description of the game.
  25.  
  26. It  was originally set up to be compiled with 'cc' under UNIX  or 
  27. Aztec  C under CP/M but I have modified the source so that it can 
  28. now also be compiled with Hi-Tech C under CP/M or MS-DOS.
  29.  
  30. The  UNIX and MS-DOS versions will require no changes to suit any 
  31. particular  screen.    The  UNIX  version  will  still  use   the 
  32. 'termcaps'  library  for  screen  control;   the  MS-DOS  version 
  33. requires  that you be using the ANSI.SYS device driver.
  34.  
  35. It  is  only the CP/M version which will require patching and  to 
  36. facilitate  that  task  I  have made  extensive  changes  to  the 
  37. TERMIO.C source module to drive terminals in a much more  general 
  38. way  than  the original program allowed.
  39.  
  40. Unless you really want to recompile the program, the CP/M version 
  41. can be patched using one of the standard debugging tools.
  42.  
  43. Simply load the program under DDT,  SID or whatever and using the 
  44. D  command  look  for the string of characters  "CURSES"  in  the 
  45. object code.  The screen control follows immediately thereafter.
  46.  
  47. A:SID      COM  (User 0)
  48. CP/M 3 SID - Version 3.0
  49. NEXT MSZE  PC  END
  50. 8200 8200 0100 CEFF
  51. #d7b74
  52. 7B74: 61 73 6B 20 2E 20 2E 20 2E 00 43 55 52 53 45 53 ask . . ..CURSES
  53. 7B84: 07 15 17 7F 7F 7F 7F 7F 00 00 00 00 00 00 00 00 ................
  54. 7B94: 06 16 7F 7F 7F 7F 7F 00 00 00 00 00 00 00 00 00 ................
  55. 7BA4: 01 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
  56. 7BB4: 04 7F 7F 7F 7F 00 00 00 01 00 FF FF 25 75 00 00 ............%u..
  57. 7BC4: 00 80 42 00 00 FA 49 76 74 72 65 6B 2E 73 63 72 ..B...Ivtrek.scr
  58. 7BD4: 00 72 2B 00 43 61 6E 6E 6F 74 20 61 63 63 65 73 .r+.Cannot acces
  59.  
  60. As  you can see,  the "CURSES" string ends at 7B83.  The  first 
  61. screen control is at 7B84.
  62.  
  63. Only  three screen controls are used.   The first two are  "clear 
  64. screen and home cursor" and "clear to end of line"  respectively.  
  65. 16 bytes are reserved for each so that in the example above, 7B84 
  66. is  the start of the "clear screen" control and 7B94 is the start 
  67. of the "clear to EOL" control.
  68.  
  69. The  first  byte  of  each  control  determines  the  number   of 
  70. characters to be sent to the terminal.  In the example shown, the 
  71. "clear  screen"  sequence is 7 bytes long and the "clear to  EOL" 
  72. sequence is 7 bytes long.
  73.  
  74. To patch the "clear screen" control for,  say,  a VT52  terminal, 
  75. alter  the  byte  at 7B84 to 1 and the byte at 7B85 to  0C  which 
  76. tells  VTREK that the "clear screen" function is performed  by  a 
  77. single byte (form feed).
  78.  
  79. Immediately  following the "clear to EOL" control (i.e.  at 7BA4) 
  80. is  a  more complex terminal control  for  cursor  movement.   It 
  81. comprises three 8-byte strings,  a set of flags,  and a couple of 
  82. "offset" values.
  83.  
  84. Again,  the first byte of each 8-byte string signifies the length 
  85. of  the following sequence.   The first is the cursor-positioning 
  86. "lead-in"  sequence  which is issued to the  terminal  to  before 
  87. either  cursor  address coordinate.   In the  example  above,  it 
  88. is a 1-byte sequence comprising a single 09h (TAB) character.
  89.  
  90. The  second string is similar and represents the  characters  (if 
  91. any)  to  be sent to the terminal BETWEEN the  cursor-positioning 
  92. coordinates.   Likewise,  the third string determines the charac-
  93. ters to be sent to the terminal AFTER the second co-ordinate.  In 
  94. the  example  above,  you will see that the "between"  string  is 
  95. empty (7BAC) and the "after" string is 4 bytes long (7BB4).
  96.  
  97. The  next  byte (7BBC) should be ZERO if the terminal expects  to 
  98. receive the y-coordinate (line number) first,  or NON-ZERO if  it 
  99. expects the x-coordinate (column number) first.
  100.  
  101. The  next byte (7BBD) should be ZERO if the terminal expects  co-
  102. ordinates  to be single-byte binary numbers,  or NON-ZERO if  the 
  103. terminal expects co-ordinates to be ASCII digits.
  104.  
  105. Finally,  the next two bytes (7BBE and 7BBF) are the 'offsets' to 
  106. add  to  the  x  (column) and y  (line)  coordinates  for  cursor 
  107. addressing.   The  home  position  is  (1,1)  so  that  for  most 
  108. terminals  the offset will be 1Fh (31).   In the example,  it is 
  109. shown as 0FFh (-1).
  110.  
  111. These notes and the aforementioned modifications by:
  112.  
  113.      Jon Saxton,
  114.      Sydney, NSW,
  115.      AUSTRALIA
  116.