Info-Atari16 Digest Fri, 9 Aug 91 Volume 91 : Issue 428 Today's Topics: .gem to .img conversion question (other ways) Atari CD-ROM? (2 msgs) Compression in 68000 Assembly Language! Default Font specs.... Dialog Boxes file selector Fractint Info-Atari16 Digest V91 #426 OOPS, Wrong # in Signature File Patch to PCDITTO... TOS (GEM) ... [FSEL wrapper source code] Minor Correction TOS (GEM) file selector windows TOS (GEM) file selector windows [FSEL wrapper source code] (2 msgs) TT Graphics Demo Warning: Two versions of Zoo 2.1 Welcome to the Info-Atari16 Digest. The configuration for the automatic cross-posting to/from Usenet is getting closer, but still getting thrashed out. Please send notifications about broken digests or bogus messages to Info-Atari16-Request@NAUCSE.CSE.NAU.EDU. Please send requests for un/subscription and other administrivia to Info-Atari16-Request, *NOT* Info-Atari16. Requests that go to the list instead of the moderators are likely to be lost or ignored. If you want to unsubscribe, and you're receiving the digest indirectly from someplace (usually a BITNET host) that redistributes it, please contact the redistributor, not us. ---------------------------------------------------------------------- Date: 8 Aug 91 14:00:35 GMT From: noao!asuvax!cs.utexas.edu!samsung!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.a cs.ohio-state.edu!dhbutler@arizona.edu (David H Butler) Subject: .gem to .img conversion question (other ways) To: Info-Atari16@naucse.cse.nau.edu No, .IMG files can be ANY resolution, and are great for DTP. I am very interested in a program that can convert between .PS or .EPS and bit-mapped formats (both ways). If anyone knows some ST or Mac software that does this, please let me know. I need one that converts from .PS or .EPS to Calamus .CVG or .OL VERY BADLY, does anyone know about a product that does this!? || || || - David Butler (dhbutler@magnus.acs.ohio-state.edu) || || || || || || H H RRRR [ High Resolution DTP ] || || || HHHH R R [ 1996 Summit St. Apt. B ] || || || H High RRRR [ Columbus, Ohio 43201 ] ||| || ||| R Resolution [ voice: (614)-297-7967 ] |||| || |||| R R - Desktop Publishing -[ For ST consulting in ]- -(Just a little plug for my company)- -[ the Columbus Ohio ]- -[ area, call (9:00 ]- -[ 5:00 mon-fri), ]- -[ (614)-297-7967 ]- ------------------------------ Date: 7 Aug 91 23:13:26 GMT From: noao!ncar!elroy.jpl.nasa.gov!spacm1!uucp_news@arizona.edu, Sender, Subject: To: Info-Atari16@naucse.cse.nau.edu When I recently upgraded my NeoDesk to patch 3.02, I I seem to recall a discussion of the problem of finding an If Atari ever wants to rerelease WUP, it has a lot to do. Fix Oh yeah, moral of this story, when debugging a NeoDesk Path: elroy.jpl.nasa.gov!sdd.hp.com!wupost!uunet!kira!news From: pegram@kira.UUCP (Robert B. Pegram) Subject: Word Up 3.0 and the PATH Message-ID: <1991Aug5.201253.22070@uvm.edu> Sender: news@uvm.edu Organization: Univ. of Vermont, Eng., Math., and Bus. Admin. (EMBA) Computer Facility Date: Mon, 5 Aug 91 20:12:53 GMT Lines: 8 Sometimes I wonder if it's all worth it; then I look at a bare desktop 8-). Bob Pegram pegram@{griffin,kira,sadye,newton}.uvm.edu or ..!uvm-gen!pegram ------------------------------ Date: 8 Aug 91 07:50:35 GMT From: mcsun!ukc!edcastle!hwcs!neil@uunet.uu.net (Neil Forsyth) Subject: Atari CD-ROM? To: Info-Atari16@naucse.cse.nau.edu In article gjh@hplb.hpl.hp.com (Graham Higgins) writes: >Let's hope that Atari's marketing management make a better job of CD-I than >they did with CD-ROM. I just read in this months ST Luser that Atari UK's marketing manager, Peter Staddon, has just quit. Bearing in mind the massive TV advertising campaign that he *DIDN'T* do and the plethora of double page ST/TT ads in PCW that *NEVER* happened, he will not be missed IMHO. When will Atari get their finger out? In the same purile rag, there is mention that Atari are to provide TOS 2.x as 512K ROM upgrade for all machines including STFM's. They do not say who their 'sources' are but it wasn't Atari. I view this piece of reporting as pure nonsense since we know that the Mega STE ROM is 256K and will take TOS 2.x (Lars has done it!) but the STFM has only 192K of ROM address space. Upgrading an STFM would involve some serious hacking to the machine, including a new GLUE chip, and I doubt that Atari are going to do that. The new Luser hasn't changed much. It's still as gaudy and as game orientated as ever. Maybe it is the best ST mag in the UK but it's still crap. When will ST User get their finger out? >Graham Higgins | gjh%ghiggins@hpl.hp.co.uk >Hewlett-Packard Labs | gjh%ghiggins@hplb.hpl.hp.com >Filton Road, Stoke Gifford | gjh%hplb.csnet@csnet-relay.arpa >Bristol, U.K. | ...!mcvax!ukc!hplb!gjh >Tel: +44 272 799910 x24014 Fax: +44 272 790554 +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK "Without milk or sugar." - "Or tea." ! +----------------------------------------------------------------------------+ ------------------------------ Date: 8 Aug 91 21:29:41 GMT From: agate!darkstar!cats.ucsc.edu!monsoon@ucbvax.berkeley.edu (Monsoon) Subject: Atari CD-ROM? To: Info-Atari16@naucse.cse.nau.edu The Atari CD-ROM drive is (or maybe was) available, at least in San Francisco. I knew of a store, Computer Rock (shameless plug) that sold them (although I don't know if they still carry it) and they also carried a number of CDs to be used with it - some of which were Clip-art CDs which they put together themselves, which contained literally thousands of artwork in several formats; the Current Notes PD collection (about two years worth or something); and a fer others. As for what the CD-ROM did, as I recall, it could read two standard formats (correct me if I'm wrong, please), one of which was the High Sierra Format. I don't remember what the other one was, but I think it's the one that Macs use. The CD-ROM could also be hooked up to your amp and could play regular music CDs. It even has a detatchable remote control, and a desk accesory that acted as one too. -Len DeJesus ------------------------------ Date: 8 Aug 91 23:08:33 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!sun-barr!newstop!exodus!neon -tetra.Eng.Sun.COM!wo91b@arizona.edu (Jim Johnson) Subject: Compression in 68000 Assembly Language! To: Info-Atari16@naucse.cse.nau.edu Netlanders, The 68000 family is actually pretty magnificent, in terms of what they can potentially do. Some people, though, have told me that the 68000 isn't capable of doing 2:1 formatted textfile/spreadsheet compression fast enough to do it on the fly (ie. 4k/sec on 16MHZ). They say it has something to do with manipulating bits. Of course, it takes assembly language to do it, but I think it can be done. I care because I'm trying to come up with compression for some 68k-based communications hardware that a friend is working on. What I need is a pointer or two to a FAST data (such as spreadsheets or Frame files) compression scheme in 68000 assembly language. I'm willing to pay reasonable amounts for source that has reasonable rules regarding distribution (including patents). (Like LZW is patented, so I can't use it). If you know of one, and you can send a quick e-mail message to me, please do it, because I'm running short of leads. Even if all you have is a name! I'll be glad to forward everything I get to interested parties. Thanks, Jim ------------------------------ Date: 8 Aug 91 00:27:00 GMT From: noao!ncar!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia .edu!ira.uka.de!smurf.sub.org!artcom0!hb.maus.de!hh.maus.de!Hayo_Schmidt@arizon a.edu (Hayo Schmidt) Subject: Default Font specs.... To: Info-Atari16@naucse.cse.nau.edu Charles Henry Medley cmedley @ wam.umd.edu wrote: >I have a program that fixes its own resource file(s) up. > I've tried using vqt_attributes, but this fails under MultiDesk, since > that program has everything set up for a 6x6 font. vqt_fontinfo seems > to be a potential winner, but it sounds like it won't be consistent on a > system with GDOS installed (I don't know for sure). The font returned by vqt_attributes (right after v_opnvwk) _is_ the default font. If MultiDesk changes the default font, FORMAT IT! There is no need to use Line A variables in this case. BUT - the default font IS NOT RESPONSIBLE for resources. To fix up resources, use the AES call graf_handle. The first two parameters return the width and the height of the char box (in mono 8 and 16). This is the valid height of the characters in AES dialogs. The GEM-TOS may work practically (but illegally) with different sizes of the default font, the AES font and the console font at the same time. Greetings, Hayo Schmidt (Hamburg/Germany) ------------------------------ Date: 8 Aug 91 05:54:57 GMT From: healy@cod.nosc.mil (Mike Healy) Subject: Dialog Boxes To: Info-Atari16@naucse.cse.nau.edu Let me quote from my Laser C (version 1.01) docs (and probably start a new flame thread): "The GEM desktop program opens a workstation for the screen using raster coordinates. GEM can only have one workstation open for a particular device at a time, and since the desktop program is always run before user applications, there is no way for an application program to open a workstation on the ST. It can however [sic] open a virtual workstation that inherits the device specific information from the currently open workstation." Laser C version 1.01 manual, p. 307 ------------------------------ Date: 8 Aug 91 21:48:22 GMT From: galileo.cc.rochester.edu!ub!ubvmsb.cc.buffalo.edu!v457umve@cs.rochester.edu (Samuel S Saunders) Subject: file selector To: Info-Atari16@naucse.cse.nau.edu Keywords: News-Software: VAX/VMS VNEWS 1.3-4.5 Click in the file area rather than on the bar and you get what you set rather than *.* ------------------------------ Date: 8 Aug 91 05:37:43 GMT From: healy@cod.nosc.mil (Mike Healy) Subject: Fractint To: Info-Atari16@naucse.cse.nau.edu Howard, you've been there a while ( and we miss your posts ). If you could see it in your heart to update fractint, you would make a lot of people happy. It is kind of lame that every 80x86 can rip out fractals using fractint, and we don't have a version that is better, let alone current. Mike Healy healy@cod.nosc.mil ------------------------------ Date: Thu, 08 Aug 91 18:21:50 CDT From: Mike Dorman Subject: Info-Atari16 Digest V91 #426 To: Atari List The best gem set of libraries around for Sozobon C is probably Ian Lepore's GemFast, version 1.5 of which is available at atari.archive. Ian has also just completed an update to Sozobon, and as soon as someone posts the FAQs list, so I can find out how to upload it to a.a, it'll be there. It is faster, optimizes better, supports desktop-based compilation better, comes with a new, desktop-friendly make (Ian *hates* CLIs), has GemFast 1.6 included with it, has a more reliable set of Dlibs, corrected math libraries, some example source for both GEM and TOS programs, an Install program (with source), startup modules for .apps and accessory-or-executable programs. Lotsa neato stuff. Someone want to tell me how to upload it? Mike. ------------------------------ Date: 8 Aug 91 14:45:46 GMT From: noao!asuvax!cs.utexas.edu!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.o hio-state.edu!dhbutler%magnus.acs.ohio-state.edu@arizona.edu (David H Butler) Subject: OOPS, Wrong # in Signature File To: Info-Atari16@naucse.cse.nau.edu Sorry about this... I just posted a file with my *NEW* signature file stuck at the end. However, I stupidly entered my -Home Phone#- as a consultation number for ST users in the Columbus Ohio area. The number below (left side) is the correct number! Sorry to waste space, but the message was posted world-wide (it was not Columbus specific in content), and I had horrible visions of people calling my house all night with weird and puzzling questions. Note, as long as I have to post this anyway, there is consulting for the ST at the number below, so if you have questions (no questions on games PLEASE), you can call, but not unless you are from the Columbus area since that is the area we service. Again, my appologies (I'll get the hang of this eventually). || || || - David Butler (dhbutler@magnus.acs.ohio-state.edu) || || || || || || H H RRRR [ High Resolution DTP ] || || || HHHH R R [ 1996 Summit St. Apt. B ] || || || H High RRRR [ Columbus, Ohio 43201 ] ||| || ||| R Resolution [ voice: (614)-297-7967 ] |||| || |||| R R - Desktop Publishing -[ For ST consulting in ]- -(Just a little plug for my company)- -[ the Columbus Ohio ]- -[ area, call (9:00 ]- -[ 5:00 mon-fri), ]- -[ (614)-292-2919 ]- ------------------------------ Date: 8 Aug 91 20:20:01 GMT From: noao!ncar!elroy.jpl.nasa.gov!usc!chaph.usc.edu!aludra.usc.edu!baffoni@arizona.e du (Juxtaposer) Subject: Patch to PCDITTO... To: Info-Atari16@naucse.cse.nau.edu Hi! A few weeks back, Warwick (down under) said he had gotten a patch for PC-DITTO that allowed it to read ST-formatted hard disk partitions. As I don't have access to Genie (I think that is where he said he got it), and all of my mail seems to bounce off his account, could someone send me this patch if you have it? Use whatever arc/lzh/zoo/uud combination makes you happy, as I can access A.A. for any new compressers you may use. Thanks to any who can help! -Mike ------------------------------ Date: 8 Aug 91 14:25:47 GMT From: haven.umd.edu!wam.umd.edu!dmb@purdue.edu (David M. Baggett) Subject: TOS (GEM) ... [FSEL wrapper source code] Minor Correction To: Info-Atari16@naucse.cse.nau.edu In article <1991Aug8.141851.6114@wam.umd.edu> I stupidly wrote: >/* > * Handy File Selector Wrapper > * by Dave Baggett > [...] > * Example call: > * > * static char path[255] = ".\\*.c", file[14] = "file.c"; > * static char filename[255]; > [...] Wouldn't ya know it? A bug in my comments. Get rid of * static char filename[255]; and replace it with * char *filename; and it makes sense. Sorry, folks. Dave Baggett dmb@wam.umd.edu ------------------------------ Date: 8 Aug 91 14:48:05 GMT From: mcsun!cernvax!chx400!urz.unibas.ch!hofer@uunet.uu.net (Remo Hofer) Subject: TOS (GEM) file selector windows To: Info-Atari16@naucse.cse.nau.edu In article , jansteen@cwi.nl (Jan van der Steen) writes: > I noticed that when giving a relative path to the file selector > of the Atari STe it's impossible to do more "cd .."'s (using the close > box of the window) than the directory where the relative path started. > This has to do with the way the system figures out the parent directory. > > > My question: > > Should one only supply full pathnames to the file selector, > or should the described behaviour be considered a bug? > > Jan van der Steen > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Jan van der Steen jansteen@cwi.nl > Centre for Mathematics and Computer Science (CWI) > Kruislaan 413, 1098 SJ Amsterdam, The Netherlands For my programming in Modula-2, I've written my own library function which calles the file selector after extending the eventually relative path to an absolute path using the default path and device give by some gemdos routines. So I only use full pathnames in my applications. Greetings Remo Hofer -- RFC822: or X.400: S=hofer;OU=urz;O=unibas;P=SWITCH;A=ARCOM;C=CH HEPNET/SPAN: CHGATE::YOGI::HOFER or 20579::48130::HOFER ------------------------------ Date: 8 Aug 91 14:18:51 GMT From: haven.umd.edu!wam.umd.edu!dmb@purdue.edu (David M. Baggett) Subject: TOS (GEM) file selector windows [FSEL wrapper source code] To: Info-Atari16@naucse.cse.nau.edu In article jansteen@cwi.nl (Jan van der Steen) writes: > >I noticed that when giving a relative path to the file selector >of the Atari STe it's impossible to do more "cd .."'s (using the close >box of the window) than the directory where the relative path started. >This has to do with the way the system figures out the parent directory. > [...] >So, it seems that the system code performs the "cd .." command >by stripping *one* directory from the current path. However, >the used algorithm doesn't make sense in this case. > [...] > Should one only supply full pathnames to the file selector, > or should the described behaviour be considered a bug? It does this on TOS 1.4, too. Sure seems like a bug to me. The only instance where this is really a problem is when you want to give the file selector a pathname relative to the current working directory. Calling fsel_input with ".\\" causes the same problems you describe since it's a relative pathname. To solve this, I wrote a wrapper for the file selector that expands an initial . in a pathname to the complete specification for the current working directory. I.e., ".\*.c" -> "d:\usr\src\*.c". The wrapper also puts up a text string prompt. I've included the C source below. Use it in good health! Dave Baggett dmb@wam.umd.edu ------------------------------------------------------------------------------- /* * Handy File Selector Wrapper * by Dave Baggett * * This routine prompts the user for a filename using the GEM file selector * and returns a pointer to a complete path specification for the file. * * ".\" is expanded to the full pathname of the current working directory * to work around the GEM file selctor's problems with relative pathnames. * * The wrapper puts up a text message in the upper left corner telling the * user what he/she/it is selecting. The screen is cleared before and after * file selection. * * Remember to write the \'s as \\ in C; e.g., ".\\*.c" * * Example call: * * static char path[255] = ".\\*.c", file[14] = "file.c"; * static char filename[255]; * * filename = file_select(path, file, "SELECT C SOURCE FILE"); * if (filename) * load_c(filename); * * After the call, _filename_ will contain the complete path, e.g., * "d:\src\bin\foo.c". * * NOTE that the path and file parameters must be static strings (NOT * literals) because the file_select routine modfies them. This is so that * the path and file specification will be the same as the user set them * (with the file selector) in the previous call. A call like * * file_select("d:\\foo\\*.c", "myfile", "PICK A FILE"); * * will NOT work correctly because the path and file parameters are literals. * * This source code is in the public domain. */ #include #include static void remove_wildcard(); /* * Put up a file selector box with prompting text. * * A pointer to the selected pathname is returned. If no filename was * selected (i.e., the user pressed CANCEL), a NULL is returned. * * The path and filename strings will be modified. */ char * file_select(path, filename, message) char *path; char *filename; char *message; { static char p[255]; /* This MUST be static */ int button; if (path[0] == '.') { /* * Expand current working directory for brain-damaged * GEM file selector. */ p[0] = (char) Dgetdrv() + 'A'; p[1] = ':'; Dgetpath(&p[2], 0); strcat(p, &path[1]); } else { strcpy(p, path); } /* * Put info message up */ Cconws("\033f\033E"); Cconws(message); fsel_input(p, filename, &button); /* * Clear the screen once the file has been selected */ Cconws("\033f\033E"); if (button) { strcpy(path, p); remove_wildcard(p); strcat(p, filename); return p; } else return NULL; } /* * Remove wildcards at the end of a pathspec returned by fsel_input */ static void remove_wildcard(p) register char *p; { register char *base = p; /* * Find terminating null */ while (*p) p++; /* * Delete characters until either \ or : are reached. */ while (p != base) { if (*p == '\\' || *p == ':') break; *p-- = '\0'; } } ------------------------------ Date: 8 Aug 91 16:28:40 GMT From: noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.o hio-state.edu!linac!unixhub!stanford.edu!msi.umn.edu!cs.umn.edu!thelake!steve@a rizona.edu (Steve Yelvington) Subject: TOS (GEM) file selector windows [FSEL wrapper source code] To: Info-Atari16@naucse.cse.nau.edu [In article <1991Aug8.141851.6114@wam.umd.edu>, dmb@wam.umd.edu (David M. Baggett) writes ... ] > ... To solve this, I wrote a wrapper for > the file selector that expands an initial . in a pathname to the > complete specification for the current working directory. I.e., > ".\*.c" -> "d:\usr\src\*.c". This is a good thing to do, and thanks for the code. I've had problems with some commercial applications (including PageStream) used across multiple hard drive partitions because the application didn't pass a full and proper path mask to the fsel. ---- Steve Yelvington, Marine on St. Croix, Minnesota (USA) steve@thelake.mn.org ------------------------------ Date: 9 Aug 91 08:43:00 WET DST From: "Brian" Subject: TT Graphics Demo To: "info-atari16" In response to the query about TT demos, I moved a Mandlebrot set generator produced by Alan King onto the TT and uploaded it to the Terminator archive (141.211.164.8). I think I called it TT_MANDL.ZOO but I have noticed that it is stored in the graphics directory rather than in the TT area. Alan's program recursively divides the screen area into ever smaller boxes until pixel sized boxes are obtained or all 'local' boxes are the same colour. This technique reduces the drawing time typically by 40%. Brian Gladman gladman@ccint1.rsre.mod.uk ------------------------------ Date: 8 Aug 91 13:27:25 GMT From: richsun!chuck@uunet.uu.net (Chuck Menard) Subject: Warning: Two versions of Zoo 2.1 To: Info-Atari16@naucse.cse.nau.edu In article muts@fysap.fys.ruu.nl (Peter Mutsaers) writes: > > > There seem to be two versions of zoo 2.1 available for the Atari ST. > > Before zoo21bin.zoo came available from the binaries newsgroup, I > > recovered from atari.archive the following: > > -rw-rw-r-- 1 1401 327325 Jul 14 23:14 zooV21.zoo > > This latter version seems to have trouble with the recent postings: > > lynxlib2.zoo and sokobin2.zoo. > >Could you post which and where is the version of zoo2.1 which works >well? I'm not sure anymore which one I had. I also cannot un-zoo the above files. I've not been able to find zoo 2.1. Can anyone post this to comp.binaries.atari.st? I guess there is souece available also? CUL, Chuck ------------------------------ End of Info-Atari16 Digest ******************************