Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 428
Info-Atari16 Digest Fri, 9 Aug 91 Volume 91 : Issue 428
Today's Topics:
.gem to .img conversion question (other ways)
<None>
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: <None>
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.91Aug7090308@ghiggins.hpl.hp.com> 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 <MDORMAN1@UA1VM.UA.EDU>
Subject: Info-Atari16 Digest V91 #426
To: Atari List <Info-Atari16@naucse.cse.nau.edu>
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.681649792@piring.cwi.nl>, 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: <hofer@urz.unibas.ch> or <hofer%urz.unibas.ch@CERNVAX.BITNET>
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.681649792@piring.cwi.nl> 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 <stdio.h>
#include <osbind.h>
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" <gladman@ccint1.rsre.mod.uk>
Subject: TT Graphics Demo
To: "info-atari16" <info-atari16@naucse.cse.nau.edu>
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.91Aug7154530@ruunfs.fys.ruu.nl> 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
******************************
