home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 10: Diskmags / nf_archive_10.iso / MAGS / ST_USER / 1990 / USERNV90.MSA / TEXT_CLINIC.DOC < prev    next >
Text File  |  1990-05-24  |  10KB  |  243 lines
  1. Stuck with a stick ST problem? Mathew Lodge and his readers can sort it out -
  2. from tough GEM and C troubles to files from BASIC. This month, C programmers
  3. are put right, GEM is queried, and the new Atari file selector is explained.
  4.  
  5.  
  6.  
  7. Mind Your Handles
  8. =================
  9.  
  10. David Mycroft from Cosham, Portsmouth, and Roland Givan of Brentwood in Essex
  11. both reply to Simon May, who, in the first RunTime clinic, had problems with C
  12. standard file handles.
  13.  
  14. "Simon's problem of not being able to send text to the printer with fprintf is
  15. due to confusion over 'standard handles' on the ST.
  16.  
  17. All input / output under GEMDOS / TOS uses handles to refer to the files /
  18. devices that are to be used. Handles are returned by Fopen call, but a number
  19. of standard handles are considered to be open before your program runs. These
  20. are called stdin, stdout, stderr, stdprn and stdaux. GEMDOS / TOS doesn't
  21. really support a stderr device, but see later. Sozobon uses Dale Schumacer's
  22. Dlibs 1.2 package for runtime support, and the stdxxx handles are defined in
  23. that package. This table hopefully explains:
  24.  
  25. File/Device              GEMDOS    GULAM     DLIBS
  26. --------------------------------------------------
  27. Console input (stdin)      0         0         0
  28. Console output (stdout)    1         1         1
  29. Error (stderr)             -         2        -1
  30. RS-232 port (stdaux)       2         4         3
  31. Printer (stdprn)           3         3         2
  32.  
  33. We can see that some disagreement exists between the various elements that are
  34. involved in output to a device. UNIX defines standard handle 2 to refer to the
  35. standard error (stderr) device, and Gulam, being a UNIX lookalike, redirects
  36. handle 2 to the console as part of its initialisation.
  37.  
  38. Hence, when Simon uses the Dlibs fprintf to output to stdprn (for which Dlibs
  39. uses handle 2) and runs under Gulam, the output gets redirected to the screen.
  40. However, when he runs his program direct from the Desktop, GEMDOS handle 2 is
  41. used which unfortunately refers to the AUX: device (RS-232 port). Assuming that
  42. Simon has no device attached here, and that the default handshake protocol for
  43. the serial port (no handshake) is in effect, the ST will just pour his output
  44. down a black hole. This is why he says his output just disappears."
  45.  
  46. Roland suggested inserting the following line just after you include stdio:
  47.  
  48. #include stdprn stdaux
  49.  
  50. Sozobon will issue a warning about redefining an already defined symbol, but
  51. your program will now work.
  52.  
  53. Simon's other problem was auto-starting Gulam on a standard STFM. Lucky STE
  54. owners don't have this problem, nor do those with new STFMs that have TOS 1.4
  55. ('Rainbow TOS') fitted. The solutions list, in decreasing order of cost and
  56. desirability, is therefore
  57.  
  58. i)   Buy an STE
  59. ii)  Fit TOS 1.4 ROMs, available from Atari UK Spares Dept. and Ladbroke
  60. Computing at around £40 (fit them yourself - I did), or have them      fitted
  61. by Ladbroke for £50, or by Gasteiner Technologies at £99.
  62. iii) Buy Headstart from Codehead software
  63.  
  64.  
  65. Change Warning
  66. ==============
  67.  
  68. The next query comes from Michael Conrad of Bushey, Herts, who is writing a
  69. desk accessory, but having trouble with resolution changes.
  70.  
  71. "My accessory re-directs some TOS vectors to my own code, in order to provide a
  72. keyboard macro facility. When my own handlers have been called, they execute
  73. the previous routine that was pointed to by the vector I've redirected. In this
  74. way, my accessory is fully integrated with TOS.
  75.  
  76. However, when the user changes resolution, GEM is reloaded, and my accessory
  77. along with it. The TOS vectors I use now point to garbage, since the accessory
  78. code has, in effect, moved. When my accessory re-installs itself, the handlers
  79. it installs attempt to execute this garbage after they have run, because this
  80. is what is contained in the appropriate vectors. The result is that as soon as
  81. the user presses a key, the machine crashes.
  82.  
  83. Is there any way to detect a resolution change before it happens? At the
  84. moment, the user has to remember to deinstall my accessory before changing
  85. resolution."
  86.  
  87. A difficult problem, but one that I'm sure someone has encountered and
  88. surmounted before. Suggestions to the address given at the end of the column.
  89.  
  90.  
  91. Gem Patching
  92. ============
  93.  
  94. Conrad Bessant of Carlton, Bedfordshire, has a query about replacement file
  95. selectors and the like.
  96.  
  97. "There are many programs around in the public domain and elsewhere, which alter
  98. the way GEM works. Replacement file selectors are a typical example. I would
  99. like to alter the Desktop's Show/Print/Cancel dialogue box, displayed when the
  100. user clicks on a non-executable file. There must obviously be some way that
  101. things like calls to the file selector can be detected or patched over. My
  102. question is: How is this done, and is it possible to get the GEM Desktop to
  103. call a routine of mine written in C instead of the Show/Print/Cancel box?"
  104.  
  105.  
  106. Mix 'n Match
  107. ============
  108.  
  109. Waikei Chung wanted to use assembler code in his C programs, but wondered about
  110. how to do it. Jim Rolfe of the 13th Signal Regiment, BFPO 42 has come to the
  111. rescue, as has Kevin Watson of West Drayton, Middlesex.
  112.  
  113. Kevin notes that Waikei will require a separate assembler package, and suggests
  114. that he upgrade to Lattice 5, which includes an assembler in the package. Jim
  115. explains how to call the assembler routine:
  116.  
  117. "The simplest way to access an assembly routine from a C program is to call it
  118. as a normal function. For example:
  119.  
  120. #include <stdio.h>
  121.  
  122. main()
  123. {
  124.    printf("Now is the time\n");
  125.    line_2();   /* Assembly language module */
  126.    printf("to come to the aid of their party");
  127. }
  128.  
  129. line_2 is the name of our separately written machine code routine which prints
  130. the second line of the famous quote.
  131.  
  132. In simple terms, the function call acts like a subroutine branch in assembler.
  133. The address of the next instruction is placed on the stack, and the program
  134. branches to the label line_2. Armed with this knowledge we can now go ahead and
  135. write our assembly module.
  136.  
  137. line_2:   move.l    #text,-(sp)    ;Put address of text onto stack
  138.           move.w    #9,-(sp)       ;GEMDOS function 9 (Cconws)
  139.           trap      #1             ;Call GEMDOS
  140.           addq.l    #6,sp          ;Repair stack
  141.           rts                      ;Return to C program
  142. text:     dc.b      "for all good men",13,10,0
  143.           end
  144.  
  145. This module is then assembled using the +L directive, producing linkable code.
  146. You can now use either the Lattice or Devpak linker to link your modules into
  147. an executable file.
  148.  
  149. Parameters are also passed on the stack. Consider the following C extract:
  150.  
  151. int a,b
  152. a = 5; b = 8;
  153.  
  154. add (a,b);     /* Assembly routine */
  155.  
  156. C will move the value of a and b onto the stack followed by the return address
  157. before branching to the label add. The add module could be:
  158.  
  159. add:      move.w    4(sp),d1  ; Value of b
  160.           move.w    6(sp),d2  ; Value of a
  161.           add       d1,d2     ; Add them together
  162.           rts                 ; Return to calling program
  163.           end                                                    "
  164.  
  165. However, Kevin commented that in Lattice 3, all parameters are placed on the
  166. stack as 32-bit values, regardless of their size in the C program, and that the
  167. return value must be placed in register d0. This is also my experience, and it
  168. means that the add routine above should actually read
  169.  
  170. add:      move.l    4(sp),d1  ; Value of b (extended to 32 bits)
  171.           move.l    8(sp),d0  ; Value of a (ditto)
  172.           add.l     d1,d0     ; Add, return result in d0
  173.           rts                 ; Return to C program
  174.           end
  175.  
  176.  
  177. Name It In One
  178. ==============
  179.  
  180. Now that the latest revisions (versions 1.4, 1.6 1.62 and 3.0) of the ST's
  181. operating system, TOS, are more widely available, I'm starting an occasional
  182. series of articles within the clinic on how to use the new features added by
  183. Atari. If you use GFA Basic, then you'll find much of these features present in
  184. the latest version, but I hope everyone else will find these snippets useful.
  185.  
  186. This month I'll cover the new file selector, which while being exactly the same
  187. size as its predecessors, has many more features. One of these is that the
  188. programmer can change the title across the top from FILE SELECTOR to whatever
  189. he likes, up to a maximum length of thirty characters.
  190.  
  191. This is supported by a new AES function called FSEL_EXINPUT, with the following
  192. parameters:
  193.  
  194. control(0) = 91
  195. control(1) = 0
  196. control(2) = 2
  197. control(3) = 3
  198. control(4) = 0
  199.  
  200. int_out(0) = fs_ireturn   -- 0 = an error occurred, otherwise OK
  201. int_out(1) = fs_iexbutton -- 0 = Cancel clicked, 1 = OK clicked
  202.  
  203. addr_in(0) = fs_iinpath   -- Pointer to string holding initial path
  204. addr_in(1) = fs_innsel    -- Pointer to string holding initial file name
  205. addr_in(2) = fs_label     -- Pointer to string that will be displayed
  206.                              across the top of the File Selector box
  207.  
  208.  
  209. The appropriate C binding would be:
  210.  
  211. fs_ireturn = fsel_exinput(fs_iinpath,fs_innsel,&fs_iexbutton,fs_label);
  212.  
  213.  
  214. That's All Folks
  215. ================
  216.  
  217. Keep the letters coming - especially the solutions and comments on other
  218. people's problems and ideas, but don't forget that the clinic depends on your
  219. problems too! Remember to include your full name (or title, if preferred), and
  220. give your phone number if possible.
  221.  
  222. If you have a listing longer than about 25 lines then please include it on a
  223. disk - I don't have time to type long listings in. Putting the text of your
  224. letter on disk is doubly helpful - First Word or First Word Plus format if
  225. possible, but straight ASCII is fine. Whilst on the subject of file formats,
  226. note that I can't decipher tokenised Fast Basic .BSC files - please send an
  227. ASCII version.
  228.  
  229. If you are sending a complete program, then I also like to see it running
  230. before putting it into the column, so please include a double-
  231. clickable version of your program if at all possible. If you want the disk
  232. and/or listing back, also include a stamped addressed envelope. No SAE, no
  233. disk.
  234.  
  235. Mathew Lodge
  236. "Programmer's Clinic"
  237. "Maen Melin"
  238. Holmes Chapel Road
  239. Lach Dennis
  240. Northwich
  241. Cheshire
  242. CW9 7SZ
  243.