home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 12: Textmags & Docs / nf_archive_12.iso / MAGS / TEXTMAGS / ATARI16 / INFO91.ZIP / INFO91 / 428.TXT < prev    next >
Text File  |  1997-04-16  |  26KB  |  678 lines
  1. Info-Atari16 Digest         Fri,  9 Aug 91       Volume 91 : Issue 428
  2.  
  3. Today's Topics:
  4.             .gem to .img conversion question (other ways)
  5.                                 <None>
  6.                         Atari CD-ROM? (2 msgs)
  7.                Compression in 68000 Assembly Language!
  8.                         Default Font specs....
  9.                              Dialog Boxes
  10.                             file selector
  11.                                Fractint
  12.                      Info-Atari16 Digest V91 #426
  13.                    OOPS, Wrong # in Signature File
  14.                          Patch to PCDITTO...
  15.       TOS (GEM) ... [FSEL wrapper source code] Minor Correction
  16.                    TOS (GEM) file selector windows
  17.  TOS (GEM) file selector windows [FSEL wrapper source code] (2 msgs)
  18.                            TT Graphics Demo
  19.                    Warning: Two versions of Zoo 2.1
  20.  
  21. Welcome to the Info-Atari16 Digest.  The configuration for the automatic
  22. cross-posting to/from Usenet is getting closer, but still getting thrashed
  23. out.  Please send notifications about broken digests or bogus messages
  24. to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU.
  25.  
  26. Please send requests for un/subscription and other administrivia to
  27. Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
  28. instead of the moderators are likely to be lost or ignored.
  29.  
  30. If you want to unsubscribe, and you're receiving the digest indirectly
  31. from someplace (usually a BITNET host) that redistributes it, please
  32. contact the redistributor, not us.
  33. ----------------------------------------------------------------------
  34.  
  35. Date: 8 Aug 91 14:00:35 GMT
  36. From:
  37.  noao!asuvax!cs.utexas.edu!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.a
  38.  cs.ohio-state.edu!dhbutler@arizona.edu (David H Butler)
  39. Subject: .gem to .img conversion question (other ways)
  40. To: Info-Atari16@naucse.cse.nau.edu
  41.  
  42. No, .IMG files can be ANY resolution, and are great for DTP. I am very
  43. interested in a program that can convert between .PS or .EPS and bit-mapped
  44. formats (both ways). If anyone knows some ST or Mac software that does this,
  45. please let me know. I need one that converts from .PS or .EPS to Calamus .CVG
  46. or .OL VERY BADLY, does anyone know about a product that does this!?
  47.  
  48.  
  49.        || || || - David Butler           (dhbutler@magnus.acs.ohio-state.edu)
  50.        || || ||
  51.        || || ||     H  H    RRRR                   [ High Resolution DTP    ]
  52.       ||  ||  ||    HHHH    R   R                  [ 1996 Summit St. Apt. B ]
  53.      ||   ||   ||   H  High RRRR                   [ Columbus, Ohio 43201   ]
  54.    |||    ||    |||         R   Resolution         [ voice: (614)-297-7967  ]
  55.  ||||     ||     ||||       R    R
  56.                                  - Desktop Publishing
  57.  
  58. -[ For ST consulting in ]-             -(Just a little plug for my company)-
  59. -[ the Columbus Ohio    ]-
  60. -[ area, call (9:00     ]-
  61. -[ 5:00 mon-fri),       ]-
  62. -[   (614)-297-7967     ]-
  63.  
  64. ------------------------------
  65.  
  66. Date: 7 Aug 91 23:13:26 GMT
  67. From: noao!ncar!elroy.jpl.nasa.gov!spacm1!uucp_news@arizona.edu, Sender,
  68. Subject: <None>
  69. To: Info-Atari16@naucse.cse.nau.edu
  70.  
  71.         When I recently upgraded my NeoDesk to patch 3.02, I
  72.         I seem to recall a discussion of the problem of finding an
  73.         If Atari ever wants to rerelease WUP, it has a lot to do.  Fix
  74.         Oh yeah, moral of this story, when debugging a NeoDesk
  75. Path: elroy.jpl.nasa.gov!sdd.hp.com!wupost!uunet!kira!news
  76. From: pegram@kira.UUCP (Robert B. Pegram)
  77. Subject: Word Up 3.0 and the PATH
  78. Message-ID: <1991Aug5.201253.22070@uvm.edu>
  79. Sender: news@uvm.edu
  80. Organization: Univ. of Vermont, Eng., Math., and Bus. Admin. (EMBA) Computer
  81.  Facility
  82. Date: Mon, 5 Aug 91 20:12:53 GMT
  83. Lines: 8
  84.  
  85. Sometimes I wonder if it's all worth it; then I look at a bare desktop
  86. 8-).
  87.  
  88. Bob Pegram
  89.  
  90. pegram@{griffin,kira,sadye,newton}.uvm.edu
  91.         or
  92. ..!uvm-gen!pegram
  93.  
  94. ------------------------------
  95.  
  96. Date: 8 Aug 91 07:50:35 GMT
  97. From: mcsun!ukc!edcastle!hwcs!neil@uunet.uu.net (Neil Forsyth)
  98. Subject: Atari CD-ROM?
  99. To: Info-Atari16@naucse.cse.nau.edu
  100.  
  101. In article <GJH.91Aug7090308@ghiggins.hpl.hp.com> gjh@hplb.hpl.hp.com
  102. (Graham Higgins) writes:
  103. >Let's hope that Atari's marketing management make a better job of CD-I than
  104. >they did with CD-ROM.
  105.  
  106. I just read in this months ST Luser that Atari UK's marketing manager,
  107. Peter Staddon, has just quit. Bearing in mind the massive TV advertising
  108. campaign that he *DIDN'T* do and the plethora of double page ST/TT ads in
  109. PCW that *NEVER* happened, he will not be missed IMHO.
  110.  
  111. When will Atari get their finger out?
  112.  
  113. In the same purile rag, there is mention that Atari are to provide TOS 2.x
  114. as 512K ROM upgrade for all machines including STFM's. They do not say who
  115. their 'sources' are but it wasn't Atari. I view this piece of reporting as
  116. pure nonsense since we know that the Mega STE ROM is 256K and will take
  117. TOS 2.x (Lars has done it!) but the STFM has only 192K of ROM address space.
  118. Upgrading an STFM would involve some serious hacking to the machine, including
  119. a new GLUE chip, and I doubt that Atari are going to do that.
  120.  
  121. The new Luser hasn't changed much. It's still as gaudy and as game orientated
  122. as ever. Maybe it is the best ST mag in the UK but it's still crap.
  123.  
  124. When will ST User get their finger out?
  125.  
  126. >Graham Higgins                  |  gjh%ghiggins@hpl.hp.co.uk
  127. >Hewlett-Packard Labs            |  gjh%ghiggins@hplb.hpl.hp.com
  128. >Filton Road, Stoke Gifford      |  gjh%hplb.csnet@csnet-relay.arpa
  129. >Bristol, U.K.                   |  ...!mcvax!ukc!hplb!gjh
  130. >Tel: +44 272 799910 x24014         Fax: +44 272 790554
  131.  
  132. +----------------------------------------------------------------------------+
  133. ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own !
  134. !                                                                            !
  135. ! Neil Forsyth                      JANET:  neil@uk.ac.hw.cs                 !
  136. ! Dept. of Computer Science         ARPA:   neil@cs.hw.ac.uk                 !
  137. ! Heriot-Watt University            UUCP:   ..!ukc!cs.hw.ac.uk!neil          !
  138. ! Edinburgh, Scotland, UK           "Without milk or sugar." - "Or tea."     !
  139. +----------------------------------------------------------------------------+
  140.  
  141. ------------------------------
  142.  
  143. Date: 8 Aug 91 21:29:41 GMT
  144. From: agate!darkstar!cats.ucsc.edu!monsoon@ucbvax.berkeley.edu (Monsoon)
  145. Subject: Atari CD-ROM?
  146. To: Info-Atari16@naucse.cse.nau.edu
  147.  
  148.      The Atari CD-ROM drive is (or maybe was) available, at least in
  149. San Francisco.  I knew of a store, Computer Rock (shameless plug) that
  150. sold them (although I don't know if they still carry it) and they also carried
  151. a number of CDs to be used with it - some of which were Clip-art CDs which
  152. they put together themselves, which contained literally thousands of
  153. artwork in several formats; the Current Notes PD collection (about two
  154. years worth or something); and a fer others.
  155.  
  156.      As for what the CD-ROM did, as I recall, it could read two standard
  157. formats (correct me if I'm wrong, please), one of which was the High Sierra
  158. Format.  I don't remember what the other one was, but I think it's the one
  159. that Macs use.
  160.  
  161.      The CD-ROM could also be hooked up to your amp and could play regular
  162. music CDs.  It even has a detatchable remote control, and a desk accesory
  163. that acted as one too.
  164.  
  165.      -Len DeJesus
  166.  
  167. ------------------------------
  168.  
  169. Date: 8 Aug 91 23:08:33 GMT
  170. From:
  171.  noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!neon
  172.  -tetra.Eng.Sun.COM!wo91b@arizona.edu (Jim Johnson)
  173. Subject: Compression in 68000 Assembly Language!
  174. To: Info-Atari16@naucse.cse.nau.edu
  175.  
  176. Netlanders,
  177.  
  178. The 68000 family is actually pretty magnificent, in terms of what they can
  179. potentially do.  Some people, though, have told me that the 68000 isn't
  180. capable of doing 2:1 formatted textfile/spreadsheet compression fast enough
  181. to do it on the fly (ie. 4k/sec on 16MHZ).  They say it has something to do
  182. with manipulating bits.
  183.  
  184. Of course, it takes assembly language to do it, but I think it can be done.
  185.  
  186. I care because I'm trying to come up with compression for some 68k-based
  187. communications hardware that a friend is working on.
  188.  
  189. What I need is a pointer or two to a FAST data (such as spreadsheets or
  190. Frame files) compression scheme in 68000 assembly language.  I'm willing to
  191. pay reasonable amounts for source that has reasonable rules regarding
  192. distribution (including patents).  (Like LZW is patented, so I can't use
  193. it).
  194.  
  195. If you know of one, and you can send a quick e-mail message to me, please do
  196. it, because I'm running short of leads.
  197.  
  198. Even if all you have is a name!
  199.  
  200. I'll be glad to forward everything I get to interested parties.
  201.  
  202. Thanks,
  203.  
  204.     Jim
  205.  
  206. ------------------------------
  207.  
  208. Date: 8 Aug 91 00:27:00 GMT
  209. From:
  210.  noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia
  211.  .edu!ira.uka.de!smurf.sub.org!artcom0!hb.maus.de!hh.maus.de!Hayo_Schmidt@arizon
  212.  a.edu (Hayo Schmidt)
  213. Subject: Default Font specs....
  214. To: Info-Atari16@naucse.cse.nau.edu
  215.  
  216. Charles Henry Medley cmedley @ wam.umd.edu wrote:
  217.  
  218. >I have a program that fixes its own resource file(s) up.
  219.  
  220. > I've tried using vqt_attributes, but this fails under MultiDesk, since
  221. > that program has everything set up for a 6x6 font.  vqt_fontinfo seems
  222. > to be a potential winner, but it sounds like it won't be consistent on a
  223. > system with GDOS installed (I don't know for sure).
  224.  
  225. The font returned by vqt_attributes (right after v_opnvwk) _is_ the default
  226. font. If MultiDesk changes the default font, FORMAT IT!
  227. There is no need to use Line A variables in this case.
  228. BUT - the default font IS NOT RESPONSIBLE for resources. To fix up resources,
  229. use the AES call graf_handle. The first two parameters return the width and the
  230. height of the char box (in mono 8 and 16). This is the valid height of the
  231. characters in AES dialogs.
  232. The GEM-TOS may work practically (but illegally) with different sizes of the
  233. default font, the AES font and the console font at the same time.
  234.  
  235. Greetings,
  236. Hayo Schmidt (Hamburg/Germany)
  237.  
  238. ------------------------------
  239.  
  240. Date: 8 Aug 91 05:54:57 GMT
  241. From: healy@cod.nosc.mil (Mike Healy)
  242. Subject: Dialog Boxes
  243. To: Info-Atari16@naucse.cse.nau.edu
  244.  
  245. Let me quote from my Laser C (version 1.01) docs (and probably start a
  246. new flame thread):
  247.  
  248.         "The GEM desktop program opens a workstation for the screen using
  249.         raster coordinates.  GEM can only have one workstation open for a
  250.         particular device at a time,  and since the desktop program is
  251.         always run before user applications,  there is no way for an
  252.         application program to open a workstation on the ST.  It can
  253.         however [sic] open a virtual workstation that inherits the
  254.         device specific information from the currently open workstation."
  255.  
  256.         Laser C version 1.01 manual,  p. 307
  257.  
  258. ------------------------------
  259.  
  260. Date: 8 Aug 91 21:48:22 GMT
  261. From:
  262.  galileo.cc.rochester.edu!ub!ubvmsb.cc.buffalo.edu!v457umve@cs.rochester.edu
  263.  (Samuel S Saunders)
  264. Subject: file selector
  265. To: Info-Atari16@naucse.cse.nau.edu
  266.  
  267. Keywords:
  268. News-Software: VAX/VMS VNEWS 1.3-4.5
  269.  
  270. Click in the file area rather than on the bar and you get what
  271. you set rather than *.*
  272.  
  273. ------------------------------
  274.  
  275. Date: 8 Aug 91 05:37:43 GMT
  276. From: healy@cod.nosc.mil (Mike Healy)
  277. Subject: Fractint
  278. To: Info-Atari16@naucse.cse.nau.edu
  279.  
  280. Howard,  you've been there a while ( and we miss your posts ). If you
  281. could see it in your heart to update fractint,  you would make a lot
  282. of people happy.
  283.  
  284. It is kind of lame that every 80x86 can rip out fractals using fractint,
  285. and we don't have a version that is better,  let alone current.
  286.  
  287. Mike Healy
  288.  
  289. healy@cod.nosc.mil
  290.  
  291. ------------------------------
  292.  
  293. Date: Thu, 08 Aug 91 18:21:50 CDT
  294. From: Mike Dorman <MDORMAN1@UA1VM.UA.EDU>
  295. Subject: Info-Atari16 Digest V91 #426
  296. To: Atari List <Info-Atari16@naucse.cse.nau.edu>
  297.  
  298. The best gem set of libraries around for Sozobon C is probably Ian Lepore's
  299. GemFast, version 1.5 of which is available at atari.archive.
  300.  
  301. Ian has also just completed an update to Sozobon, and as soon as someone
  302. posts the FAQs list, so I can find out how to upload it to a.a, it'll be
  303. there.  It is faster, optimizes better, supports desktop-based compilation
  304. better, comes with a new, desktop-friendly make (Ian *hates* CLIs), has
  305. GemFast 1.6 included with it, has a more reliable set of Dlibs, corrected math
  306. libraries, some example source for both GEM and TOS programs, an Install
  307. program (with source), startup modules for .apps and accessory-or-executable
  308. programs.
  309.  
  310. Lotsa neato stuff.  Someone want to tell me how to upload it?
  311.  
  312. Mike.
  313.  
  314. ------------------------------
  315.  
  316. Date: 8 Aug 91 14:45:46 GMT
  317. From:
  318.  noao!asuvax!cs.utexas.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.o
  319.  hio-state.edu!dhbutler%magnus.acs.ohio-state.edu@arizona.edu (David H Butler)
  320. Subject: OOPS, Wrong # in Signature File
  321. To: Info-Atari16@naucse.cse.nau.edu
  322.  
  323. Sorry about this... I just posted a file with my *NEW* signature file stuck at
  324. the end. However, I stupidly entered my -Home Phone#- as a consultation number
  325. for ST users in the Columbus Ohio area. The number below (left side) is the
  326. correct number! Sorry to waste space, but the message was posted world-wide (it
  327. was not Columbus specific in content), and I had horrible visions of people
  328. calling my house all night with weird and puzzling questions. Note, as long as
  329. I have to post this anyway, there is consulting for the ST at the number below,
  330. so if you have questions (no questions on games PLEASE), you can call, but
  331. not unless you are from the Columbus area since that is the area we service.
  332. Again, my appologies (I'll get the hang of this eventually).
  333.  
  334.  
  335.        || || || - David Butler           (dhbutler@magnus.acs.ohio-state.edu)
  336.        || || ||
  337.        || || ||     H  H    RRRR                   [ High Resolution DTP    ]
  338.       ||  ||  ||    HHHH    R   R                  [ 1996 Summit St. Apt. B ]
  339.      ||   ||   ||   H  High RRRR                   [ Columbus, Ohio 43201   ]
  340.    |||    ||    |||         R   Resolution         [ voice: (614)-297-7967  ]
  341.  ||||     ||     ||||       R    R
  342.                                  - Desktop Publishing
  343.  
  344. -[ For ST consulting in ]-             -(Just a little plug for my company)-
  345. -[ the Columbus Ohio    ]-
  346. -[ area, call (9:00     ]-
  347. -[ 5:00 mon-fri),       ]-
  348. -[ (614)-292-2919       ]-
  349.  
  350. ------------------------------
  351.  
  352. Date: 8 Aug 91 20:20:01 GMT
  353. From:
  354.  noao!ncar!elroy.jpl.nasa.gov!usc!chaph.usc.edu!aludra.usc.edu!baffoni@arizona.e
  355.  du (Juxtaposer)
  356. Subject: Patch to PCDITTO...
  357. To: Info-Atari16@naucse.cse.nau.edu
  358.  
  359.         Hi!
  360.  
  361.         A few weeks back, Warwick (down under) said he had gotten a patch for
  362. PC-DITTO that allowed it to read ST-formatted hard disk partitions.  As I
  363. don't have access to Genie (I think that is where he said he got it), and all
  364. of my mail seems to bounce off his account, could someone send me this patch
  365. if you have it?  Use whatever arc/lzh/zoo/uud combination makes you happy, as
  366. I can access A.A. for any new compressers you may use.
  367.  
  368.         Thanks to any who can help!
  369.  
  370.         -Mike
  371.  
  372. ------------------------------
  373.  
  374. Date: 8 Aug 91 14:25:47 GMT
  375. From: haven.umd.edu!wam.umd.edu!dmb@purdue.edu (David M. Baggett)
  376. Subject: TOS (GEM) ... [FSEL wrapper source code] Minor Correction
  377. To: Info-Atari16@naucse.cse.nau.edu
  378.  
  379. In article <1991Aug8.141851.6114@wam.umd.edu> I stupidly wrote:
  380. >/*
  381. > * Handy File Selector Wrapper
  382. > * by Dave Baggett
  383. > [...]
  384. > * Example call:
  385. > *
  386. > *     static char     path[255] = ".\\*.c", file[14] = "file.c";
  387. > *     static char     filename[255];
  388. > [...]
  389.  
  390. Wouldn't ya know it?  A bug in my comments.  Get rid of
  391.  
  392.   *     static char     filename[255];
  393.  
  394. and replace it with
  395.  
  396.  *      char            *filename;
  397.  
  398. and it makes sense.
  399.  
  400. Sorry, folks.
  401.  
  402. Dave Baggett
  403. dmb@wam.umd.edu
  404.  
  405. ------------------------------
  406.  
  407. Date: 8 Aug 91 14:48:05 GMT
  408. From: mcsun!cernvax!chx400!urz.unibas.ch!hofer@uunet.uu.net (Remo Hofer)
  409. Subject: TOS (GEM) file selector windows
  410. To: Info-Atari16@naucse.cse.nau.edu
  411.  
  412. In article <jansteen.681649792@piring.cwi.nl>, jansteen@cwi.nl (Jan van der
  413.  Steen) writes:
  414. > I noticed that when giving a relative path to the file selector
  415. > of the Atari STe it's impossible to do more "cd .."'s (using the close
  416. > box of the window) than the directory where the relative path started.
  417. > This has to do with the way the system figures out the parent directory.
  418. >
  419. >
  420. > My question:
  421. >
  422. >     Should one only supply full pathnames to the file selector,
  423. >     or should the described behaviour be considered a bug?
  424. >
  425. >       Jan van der Steen
  426. >     -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  427. >      Jan van der Steen                 jansteen@cwi.nl
  428. >      Centre for Mathematics and Computer Science (CWI)
  429. >      Kruislaan 413, 1098 SJ Amsterdam, The Netherlands
  430.  
  431. For my programming in Modula-2, I've written my own library function which
  432. calles the file selector after extending the eventually relative path to an
  433. absolute path using the default path and device give by some gemdos routines.
  434.  
  435. So I only use full pathnames in my applications.
  436.  
  437. Greetings
  438. Remo Hofer
  439. --
  440.        RFC822:  <hofer@urz.unibas.ch> or <hofer%urz.unibas.ch@CERNVAX.BITNET>
  441.         X.400:  S=hofer;OU=urz;O=unibas;P=SWITCH;A=ARCOM;C=CH
  442.   HEPNET/SPAN:  CHGATE::YOGI::HOFER or 20579::48130::HOFER
  443.  
  444. ------------------------------
  445.  
  446. Date: 8 Aug 91 14:18:51 GMT
  447. From: haven.umd.edu!wam.umd.edu!dmb@purdue.edu (David M. Baggett)
  448. Subject: TOS (GEM) file selector windows [FSEL wrapper source code]
  449. To: Info-Atari16@naucse.cse.nau.edu
  450.  
  451. In article <jansteen.681649792@piring.cwi.nl> jansteen@cwi.nl (Jan van der
  452.  Steen) writes:
  453. >
  454. >I noticed that when giving a relative path to the file selector
  455. >of the Atari STe it's impossible to do more "cd .."'s (using the close
  456. >box of the window) than the directory where the relative path started.
  457. >This has to do with the way the system figures out the parent directory.
  458. > [...]
  459. >So, it seems that the system code performs the "cd .." command
  460. >by stripping *one* directory from the current path.  However,
  461. >the used algorithm doesn't make sense in this case.
  462. > [...]
  463. >    Should one only supply full pathnames to the file selector,
  464. >    or should the described behaviour be considered a bug?
  465.  
  466. It does this on TOS 1.4, too.  Sure seems like a bug to me.  The only
  467. instance where this is really a problem is when you want to give the
  468. file selector a pathname relative to the current working directory.
  469. Calling fsel_input with ".\\" causes the same problems you describe
  470. since it's a relative pathname.  To solve this, I wrote a wrapper for
  471. the file selector that expands an initial . in a pathname to the
  472. complete specification for the current working directory.  I.e.,
  473. ".\*.c" -> "d:\usr\src\*.c".
  474.  
  475. The wrapper also puts up a text string prompt.  I've included the
  476. C source below.  Use it in good health!
  477.  
  478. Dave Baggett
  479. dmb@wam.umd.edu
  480. -------------------------------------------------------------------------------
  481. /*
  482.  * Handy File Selector Wrapper
  483.  * by Dave Baggett
  484.  *
  485.  * This routine prompts the user for a filename using the GEM file selector
  486.  * and returns a pointer to a complete path specification for the file.
  487.  *
  488.  * ".\" is expanded to the full pathname of the current working directory
  489.  * to work around the GEM file selctor's problems with relative pathnames.
  490.  *
  491.  * The wrapper puts up a text message in the upper left corner telling the
  492.  * user what he/she/it is selecting.  The screen is cleared before and after
  493.  * file selection.
  494.  *
  495.  * Remember to write the \'s as \\ in C; e.g., ".\\*.c"
  496.  *
  497.  * Example call:
  498.  *
  499.  *      static char     path[255] = ".\\*.c", file[14] = "file.c";
  500.  *      static char     filename[255];
  501.  *
  502.  *      filename = file_select(path, file, "SELECT C SOURCE FILE");
  503.  *      if (filename)
  504.  *              load_c(filename);
  505.  *
  506.  * After the call, _filename_ will contain the complete path, e.g.,
  507.  * "d:\src\bin\foo.c".
  508.  *
  509.  * NOTE that the path and file parameters must be static strings (NOT
  510.  * literals) because the file_select routine modfies them.  This is so that
  511.  * the path and file specification will be the same as the user set them
  512.  * (with the file selector) in the previous call.  A call like
  513.  *
  514.  *      file_select("d:\\foo\\*.c", "myfile", "PICK A FILE");
  515.  *
  516.  * will NOT work correctly because the path and file parameters are literals.
  517.  *
  518.  * This source code is in the public domain.
  519.  */
  520. #include <stdio.h>
  521. #include <osbind.h>
  522.  
  523. static void     remove_wildcard();
  524.  
  525. /*
  526.  * Put up a file selector box with prompting text.
  527.  *
  528.  * A pointer to the selected pathname is returned.  If no filename was
  529.  * selected (i.e., the user pressed CANCEL), a NULL is returned.
  530.  *
  531.  * The path and filename strings will be modified.
  532.  */
  533. char *
  534. file_select(path, filename, message)
  535.         char    *path;
  536.         char    *filename;
  537.         char    *message;
  538. {
  539.         static char     p[255];         /* This MUST be static */
  540.         int             button;
  541.  
  542.         if (path[0] == '.') {
  543.                 /*
  544.                  * Expand current working directory for brain-damaged
  545.                  * GEM file selector.
  546.                  */
  547.                 p[0] = (char) Dgetdrv() + 'A';
  548.                 p[1] = ':';
  549.                 Dgetpath(&p[2], 0);
  550.                 strcat(p, &path[1]);
  551.         }
  552.         else {
  553.                 strcpy(p, path);
  554.         }
  555.  
  556.         /*
  557.          * Put info message up
  558.          */
  559.         Cconws("\033f\033E");
  560.         Cconws(message);
  561.         fsel_input(p, filename, &button);
  562.  
  563.         /*
  564.          * Clear the screen once the file has been selected
  565.          */
  566.         Cconws("\033f\033E");
  567.  
  568.         if (button) {
  569.                 strcpy(path, p);
  570.                 remove_wildcard(p);
  571.                 strcat(p, filename);
  572.                 return p;
  573.         }
  574.         else
  575.                 return NULL;
  576. }
  577.  
  578. /*
  579.  * Remove wildcards at the end of a pathspec returned by fsel_input
  580.  */
  581. static void
  582. remove_wildcard(p)
  583.         register char   *p;
  584. {
  585.         register char   *base = p;
  586.  
  587.         /*
  588.          * Find terminating null
  589.          */
  590.         while (*p) p++;
  591.  
  592.         /*
  593.          * Delete characters until either \ or : are reached.
  594.          */
  595.         while (p != base) {
  596.                 if (*p == '\\' || *p == ':')
  597.                         break;
  598.  
  599.                 *p-- = '\0';
  600.         }
  601. }
  602.  
  603. ------------------------------
  604.  
  605. Date: 8 Aug 91 16:28:40 GMT
  606. From:
  607.  noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.o
  608.  hio-state.edu!linac!unixhub!stanford.edu!msi.umn.edu!cs.umn.edu!thelake!steve@a
  609.  rizona.edu (Steve Yelvington)
  610. Subject: TOS (GEM) file selector windows [FSEL wrapper source code]
  611. To: Info-Atari16@naucse.cse.nau.edu
  612.  
  613. [In article <1991Aug8.141851.6114@wam.umd.edu>,
  614.      dmb@wam.umd.edu (David M. Baggett) writes ... ]
  615.  
  616.  > ... To solve this, I wrote a wrapper for
  617.  > the file selector that expands an initial . in a pathname to the
  618.  > complete specification for the current working directory.  I.e.,
  619.  > ".\*.c" -> "d:\usr\src\*.c".
  620.  
  621. This is a good thing to do, and thanks for the code. I've had problems
  622. with some commercial applications (including PageStream) used across
  623. multiple hard drive partitions because the application didn't pass a
  624. full and proper path mask to the fsel.
  625.  
  626. ----
  627.  Steve Yelvington, Marine on St. Croix, Minnesota (USA)
  628.  steve@thelake.mn.org
  629.  
  630. ------------------------------
  631.  
  632. Date: 9 Aug 91 08:43:00 WET DST
  633. From: "Brian" <gladman@ccint1.rsre.mod.uk>
  634. Subject: TT Graphics Demo
  635. To: "info-atari16" <info-atari16@naucse.cse.nau.edu>
  636.  
  637. In response to the query about TT demos, I moved a Mandlebrot set generator
  638. produced by  Alan King onto the TT and uploaded it to the Terminator archive
  639. (141.211.164.8).  I think I called it TT_MANDL.ZOO but I have noticed that it
  640. is stored in the graphics directory rather than in the TT area. Alan's program
  641. recursively divides the screen area into ever smaller boxes until pixel sized
  642. boxes are obtained or all 'local' boxes are the same colour. This technique
  643. reduces the drawing time typically by 40%.
  644.  
  645.        Brian Gladman       gladman@ccint1.rsre.mod.uk
  646.  
  647. ------------------------------
  648.  
  649. Date: 8 Aug 91 13:27:25 GMT
  650. From: richsun!chuck@uunet.uu.net (Chuck Menard)
  651. Subject: Warning: Two versions of Zoo 2.1
  652. To: Info-Atari16@naucse.cse.nau.edu
  653.  
  654. In article <MUTS.91Aug7154530@ruunfs.fys.ruu.nl> muts@fysap.fys.ruu.nl (Peter
  655.  Mutsaers) writes:
  656. >
  657. >   > There seem to be two versions of zoo 2.1 available for the Atari ST.
  658. >   > Before zoo21bin.zoo came available from the binaries newsgroup, I
  659. >   > recovered from atari.archive the following:
  660. >   > -rw-rw-r--  1 1401       327325 Jul 14 23:14 zooV21.zoo
  661. >   > This latter version seems to have trouble with the recent postings:
  662. >   > lynxlib2.zoo and sokobin2.zoo.
  663. >
  664. >Could you post which and where is the version of zoo2.1 which works
  665. >well? I'm not sure anymore which one I had.
  666.  
  667. I also cannot un-zoo the above files.  I've not been able to find zoo 2.1.  Can
  668. anyone post this to comp.binaries.atari.st?  I guess there is souece available
  669. also?
  670.  
  671. CUL,
  672. Chuck
  673.  
  674. ------------------------------
  675.  
  676. End of Info-Atari16 Digest
  677. ******************************
  678.