Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 508
Info-Atari16 Digest Fri, 27 Sep 91 Volume 91 : Issue 508
Today's Topics:
CPX Information
Empire - where to get? (Interstel adr. wanted)
Hebrew Fonts
lharc 2.01e vs zoo 2.1: some tests
ST Magazines (was More Lies From Atari?)
ST Magazines (was Re: More Lies From Atari?)
TeX, which do I get? (Now that I kno
Trip-A-Tron (Colourspace)
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: 26 Sep 91 06:31:17 GMT
From: mcsun!news.funet.fi!funic!nic.funet.fi!lahtinen@uunet.uu.net (Kimmo
Lahtinen)
Subject: CPX Information
To: Info-Atari16@naucse.cse.nau.edu
In ST-Computer Magazine there has been several articles about
CPX, but of course in German.
--
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Kimmo Lahtinen E-Mail : lahtinen@gideon.fmi.fi or
Finnish Meteorological Institute kimmo@field.fi
'' Phone : +358 0 758 1322
Possessed by a Spirit G3 Fax : +358 0 758 1396
------------------------------
Date: Fri, 27 Sep 91 14:08:24 MEZ
From: Wolfgang Ley <BWWL%DCZTU1.BITNET@CUNYVM.CUNY.EDU>
Subject: Empire - where to get? (Interstel adr. wanted)
To: Atari ST users forum <Info-Atari16@naucse.cse.nau.edu>
Hi ppl,
I would like to have the Atari-ST Version of Empire (Wargame of the
century - NOT "The empire strikes back").
I can't find a distributor of this game... all i know is that the
programm is from INTERSTEL. Is there anyone out who knows the adress
of Interstel?? Is there an other way to get Empire??
Thanks, Wolfgang.
---------------------------------------------------------------------------
Wolfgang Ley e-mail:
Teichstrasse 9 from BITNET : BWWL@DCZTU1.BITNET
3392 Clausthal-Zellerfeld from Internet: BWWL@ibm.rz.tu-clausthal.de
Tel. 05323/82132 (voice) or BWWL@sun.rz.tu-clausthal.de
---------------------------------------------------------------------------
------------------------------
Date: 26 Sep 91 15:10:07 GMT
From:
europa.asd.contel.com!darwin.sura.net!haven.umd.edu!uflorida!travis!jgj@uunet.u
u.net (Jeff Jackson)
Subject: Hebrew Fonts
To: Info-Atari16@naucse.cse.nau.edu
I wish to thank the numerous people who responded to my posting looking for
a Hebrew Font. I found two sets of freely available ones:
> Date: Thu, 05 Sep 91 13:52:16 IST
> From: YOEL%BGUVM@TAUNIVM.TAU.AC.IL
> Organization: Ben-Gurion University, Beer-Sheva, Israel
> Subject: Re: Hebrew Font Wanted
> To: jgj@travis.csd.harris.com
>
> Hello. You can put Mac hebrew fonts from my FTP anonymous 132.72.20.2
> HEBFONT.HQX fonts
> HEBSYS.HQX Hebrew system 6.03
> RAVKTAV.HQX Hebrew editor
> Michael
and
> Date: Thu, 5 Sep 91 19:35:42 -0400
> From: brecher@husc.harvard.edu (Jonathan Brecher)
> To: jgj@travis.csd.harris.com (Jeff Jackson)
> In-Reply-To: jgj@ssd.csd.harris.com's message of 4 Sep 91 20:04:06 GMT
> Subject: Hebrew Font Wanted
>
> >Is there anywhere I can get a postscript Hebrew Font? PD would be nice
> >but $$$ are not out of the question. Thankx in advance
>
> Oh boy, time to toot my own horn!
> You can get my ShareWare Hebrew fonts from mac.archive.umich.edu in
> /mac/system.extensions/fonts/type.one.fonts.
>
> Look for the files ShalomOldStyle.hqx, ShalomStick.hqx and ShalomScript.hqx
> (or something similar). If you have any problems, drop me a line and I'll
> upload you some fresh copies.
> jonathan brecher
The first one didn't quite fit my needs because I needed full
pointing. The second I found after being better than half way through
designing my own. It has full pointing, though it does it with zero
sized characters with negative offsets (I think). My screen display
software doesn't something about it. I decided I would only be
satisfied if I did my own, so I am completing it.
Those of you who wanted one too, can get one of the above, or wait
till I am finished with mine and I'll email it to you. It will
consist of 12, 18, 24 and 36 pt screen fonts (For Monochrome Atari ST
PageStream), the FM (font metrics) and DMF (dot-matrix font) files as
well as a Type-3 postscript file and the PSF file for interfacing it
to PageStream. My big goal is for it to look good at 12pt on a puny
300dpi printer. I suspect the other two would look much better at
1200dpi.
The way I am handling the overstriking is kerning pairs. There are
two character widths for the consonants. All the vowel points (except
holem, which is special because it goes in the corner instead of the
center), are the same size as the small consanants. "We" would be a
waw with a seghol under it. For the large consonants, a pad character
must be added after the vowel to make up for its smaller size, hence
"Be=". For holem, there is both a small (o) and a large (O) one. It
must be put after the character to its left (BOY) would put a Holem
between Beth and Yodh. Holem-waw is "w".
I have the basic set done, but I am still not happy with Aleph and a
couple others, plus I still discover an occassional bug in my kerning
(lots of pairs).
--
============================================================================
Jeffrey Glen Jackson _|_Satan jeered, "You're dead meat Jesus, I'm gonna
jgj@ssd.csd.harris.com | bust you up tonight."
x5120 | Jesus said, "Go ahead, make my day."
------------------------------
Date: 26 Sep 91 06:45:25 GMT
From: convex!rosenkra@uunet.uu.net (William Rosenkranz)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: Info-Atari16@naucse.cse.nau.edu
friends-
to help understand the claim that lharc is the best thing since sliced
bread, and so much better than zoo 2.1, i ran some tests. this is a rather
long post. if you think i am crazy, hit 'n' now. or put me in your kill
file :-). if you have an open mind, read on for enlightenment...
summary: zoo 2.1 is just about as fast as lharc 2.01e and
makes files about the same size.
rumors dispelled: using assembly language offers huge speed advantages
over C in the problem domain of file archivers.
rumors confirmed: C programs compiled with GNU C offer significant
advantages (read on...). C programs compiled with
GNU C tend to be rather large executables.
tests: 1 archive of archives
2 archive of programs and their docs
3 test wildcard expansion and long command lines
4 handle ~C interrupt
i felt these sorts of tests were important to me. they may or may not be
your cup of tea. in that case do your own tests (and report them to the
rest of us). missing is a test of predominantly text files. also missing
are tests of directory trees and very large files. i've spent far too much
time on this already, just to prove a point.
test platform is mega4 (4 MB) 8 Mhz, TOS 1.2, using gulam CLI. environment
included TMP=ramdisk and TEMP=ramdisk (i confirmed there was no use of
hard disk by observing that no disk access lights went on).
all tests were done with files (executable, data files, and archives) in
a 1.5MB ramdisk. this tends to eliminate the effect of partitions which
are not empty, differences in drive seek rates, etc. knowing that zoo is
sensitive to i/o, i wanted to factor out i/o from the test as much as i
could. i did not want to clear an entire partition for this.
versions of each program were as follows:
lharc 2.01e (questor, Assemblerversion vom 14.07.1991)
zoo 2.1 (1991/07/14 22:39:26)
i would call this "equal" technology since the versions were realized
on the same dates! zoo was compiled with GNU c (gcc) though i do not know
which version. i confirmed this by both "printstk zoo.ttp" which did not
fail, listing a reasonable stacksize (16k) and by "strings -10 zoo.ttp"
which listed ascii strings that would appear if gcc was the compiler.
it also looks like zoo 2.1 was compiled with MiNT so that it could be
"backgrounded" in a multiprocessing environment. i could be way off base
here, however. i just spotted the string "MiNT" in the .ttp. i saw no
evidence that lharc was equally endowed. it also looks like zoo may support
UNIXMODE tho i don't use it myself. UNIXMODE allows configuration so that
forward slashes "/" can be used in file paths as well as backslash "\".
lharc does not appear to support this either. note that if needed, the
zoo program's stack could be increased with the fixstk utility offered
with GNU C. i do not know how lharc does its memory management nor whether
it would ever need stacksize adjustments. my guess is that memory is
either statically allocated with fixed size arrays or with GEMDOS Malloc.
i would know for sure if source was available. i am unable to ascertain
how much memory lharc Mallocs if it does do so. this can be important
in a multiprocessing environment like MiNT. if it Mallocs all memory,
then no other program could be started until lharc finishes.
commands used:
add files: lharc a lll <files> zoo ah zzz <files>
extract files: lharc x lll zoo -extract zzz
list archive: lharc v lll zoo -list zzz
gulam's time command was used to get the times which are all in seconds
unless otherwise noted.
----------------------------------------------------------------------------
test 1:
used these files for data (chosen at random):
-rw------- 1 u 39071 Sep 22 21:10 f1.zoo
-rw------- 1 u 69918 Jul 23 00:46 f2.zoo
-rw------- 1 u 2303 Sep 4 03:16 f3.h
-rw------- 1 u 74183 Sep 22 21:15 f4.zoo
lharc: add files:
this took 82 seconds to complete, resulting in a file of size 181588 bytes.
lharc: extract files:
this took 27 seconds. HOWEVER, the dates and times of the extracted files
were NOT correct. they were the current date and time NOT the times in
the archive:
-rw------- 1 u 39071 Sep 25 21:56 f1.zoo
-rw------- 1 u 69918 Sep 25 21:56 f2.zoo
-rw------- 1 u 2303 Sep 25 21:56 f3.h
-rw------- 1 u 74183 Sep 25 21:56 f4.zoo
lharc: list files:
LHarc 2.01e (c)Yoshi, Quester, 1988-90.(Assemblerversion vom 14.07.1991)
Listing of archive : 'LLL.LZH'
Name Original Packed Ratio Date Time Attr Type CRC
-------------- -------- -------- ------ -------- -------- ---- ----- ----
F1.ZOO
39071 37952 97.1% 91-09-22 21:10:22 ---w -lh5- 3386
F2.ZOO
69918 68195 97.5% 91-07-23 0:46:32 ---w -lh5- E91B
F3.H
2303 1127 48.9% 91-09-04 3:16:56 ---w -lh5- 0526
F4.ZOO
74183 74183 100.0% 91-09-22 21:15:04 ---w -lh0- FA5E
-------------- -------- -------- ------ -------- --------
4 files 185475 181457 97.8% 91-09-25 21:15:48
zoo21: add files:
this took 93 seconds to complete, resulting in a file of size 181865 bytes.
zoo21: extract files:
this took 25 seconds. the times and dates of extracted files were exactly
correct (same dates and times as files in the archive).
zoo21: list files
Archive zzz.zoo:
Length CF Size Now Date Time
-------- --- -------- --------- --------
39071 3% 37954 22 Sep 91 21:10:22+64 3386 f1.zoo
69918 3% 68197 23 Jul 91 00:46:32+64 e91b f2.zoo
2303 51% 1129 4 Sep 91 03:16:56+64 0526 f3.h
74183 0% 74183 22 Sep 91 21:15:04+64 fa5e f4.zoo
-------- --- -------- --------- --------
185475 2% 181463 4 files
----------------------------------------------------------------------------
test 2:
used these files (from mint 0.8 distribution, this was in file f4.zoo in the
test above, by the way, a "zoo ah" archive):
-rw------- 1 u 25636 Apr 17 23:40 bgacc.acc
-rw------- 1 u 2168 Apr 18 00:29 bgacc.doc
-rw------- 1 u 1189 Dec 9 23:05 gem.prg*
-rw------- 1 u 9871 Mar 16 18:12 init.doc
-rw------- 1 u 23586 Apr 5 23:18 init.prg*
-rw------- 1 u 651 Dec 15 00:15 init.rc
-rw------- 1 u 74125 Apr 18 00:19 mint.prg*
lharc: add files:
this took 63 seconds to complete, resulting in a file of size 73820 bytes.
lharc: extract files:
this took 23 seconds. again, dates were wrong:
-rw------- 1 u 25636 Sep 25 22:02 bgacc.acc
-rw------- 1 u 2168 Sep 25 22:02 bgacc.doc
-rw------- 1 u 1189 Sep 25 22:02 gem.prg*
-rw------- 1 u 9871 Sep 25 22:02 init.doc
-rw------- 1 u 23586 Sep 25 22:02 init.prg*
-rw------- 1 u 651 Sep 25 22:02 init.rc
-rw------- 1 u 73820 Sep 25 22:01 lll.lzh
-rw------- 1 u 74125 Sep 25 22:02 mint.prg*
lharc: list files:
LHarc 2.01e (c)Yoshi, Quester, 1988-90.(Assemblerversion vom 14.07.1991)
Listing of archive : 'LLL.LZH'
Name Original Packed Ratio Date Time Attr Type CRC
-------------- -------- -------- ------ -------- -------- ---- ----- ----
BGACC.ACC
25636 13854 54.0% 91-04-20 15:40:26 ---w -lh5- EAF8
BGACC.DOC
2168 1065 49.1% 91-04-20 16:29:00 ---w -lh5- BD8E
GEM.PRG
1189 866 72.8% 90-12-12 14:05:20 ---w -lh5- C714
INIT.DOC
9871 3961 40.1% 91-03-19 9:12:10 ---w -lh5- D569
INIT.PRG
23586 13558 57.5% 91-04-08 14:18:34 ---w -lh5- B325
INIT.RC
651 353 54.2% 90-12-17 15:15:46 ---w -lh5- 21B5
MINT.PRG
74125 39917 53.9% 91-04-20 16:19:22 ---w -lh5- 496E
-------------- -------- -------- ------ -------- --------
7 files 137226 73574 53.6% 91-09-25 22:23:24
zoo21: add files:
this took 74 seconds to complete, resulting in a file of size 74183 bytes.
zoo21: extract files:
this took 23 seconds. dates ok.
-rw------- 1 u 25636 Apr 20 15:40 bgacc.acc
-rw------- 1 u 2168 Apr 20 16:29 bgacc.doc
-rw------- 1 u 1189 Dec 12 14:05 gem.prg*
-rw------- 1 u 9871 Mar 19 09:12 init.doc
-rw------- 1 u 23586 Apr 8 14:18 init.prg*
-rw------- 1 u 651 Dec 17 15:15 init.rc
-rw------- 1 u 74125 Apr 20 16:19 mint.prg*
-rw------- 1 u 74183 Apr 18 00:29 zzz.zoo
zoo21: list files:
Archive zzz.zoo:
Length CF Size Now Date Time
-------- --- -------- --------- --------
25636 46% 13856 17 Apr 91 23:40:26+64 eaf8 bgacc.acc
2168 51% 1067 18 Apr 91 00:29:00+64 bd8e bgacc.doc
1189 27% 868 9 Dec 90 23:05:20+64 c714 gem.prg
9871 60% 3963 16 Mar 91 18:12:10+64 d569 init.doc
23586 43% 13560 5 Apr 91 22:18:34+64 b325 init.prg
651 45% 355 15 Dec 90 00:15:46+64 21b5 init.rc
74125 47% 39919 18 Apr 91 00:19:22+64 496e mint.prg
-------- --- -------- --------- --------
137226 47% 73588 7 files
----------------------------------------------------------------------------
test 3:
i made a dummy directory with enough files so that the command line length
would be longer than 125 chars (which is what Pexec normally can handle).
GNU C programs can exploit ARGV extended argument passing (which is sanctioned
by atari). gulam can handle this as well with "setenv env_style mw" which
i set.
files were:
xxxxxxxx.001 xxxxxxxx.004xxxxxxxx.007 xxxxxxxx.010 xxxxxxxx.013
xxxxxxxx.002 xxxxxxxx.005xxxxxxxx.008 xxxxxxxx.011 xxxxxxxx.014
xxxxxxxx.003 xxxxxxxx.006xxxxxxxx.009 xxxxxxxx.012 xxxxxxxx.015
with zoo i did:
zoo a zzz *
and
zoo a zzz '*'
both worked. that means zoo can handle long lists of file names and
wildcards itself.
i tried:
lharc a lll *
and my system crashed! lharc does NOT handle extended args. and what's more
it crashed my system! i did not want to reboot again so i did not test to
see if it handles wildcards itself. this is TOTALLY unacceptable.
----------------------------------------------------------------------------
test 4:
i tested each program's ability to be interrupted. during archive creation,
i issued a control-C to both. both stopped. however, lharc left a file
behind "lharc.)2(" so it does not really handle signals. zoo does since
it was compiled with GNU C library (another reason why it is better to
use a compiler with a decent library). zoo cleaned up after itself.
----------------------------------------------------------------------------
recap:
create archive extract files comments
time size time
test 1 lharc 82 181588 27 extracted file dates wrong
zoo 93 181865 25
zoo/lharc ratio 1.13 1.0015 0.926
test 2 lharc 63 73820 23 extracted file dates wrong
zoo 74 74183 23
zoo/lharc ratio 1.17 1.0049 1.000
conclusions:
tho hardly an exhaustive test, nevertheless i suspect most tests will show
similar results. i am also sure that someone can find an anomoly where either
one kicks the pants of the other.
i draw these conclusions:
- lharc is no more "blindingly fast" than zoo 2.1. in fact for
extraction it can be SLOWER. extraction is probably used more
often by casual users. assembly language lharc is no more than 15%
faster on average on compression and at best the same or slower
on extraction as the "hands off" C of zoo. in fact given this
problem domain (construct a system to compress and store files)
it appears that C is an excellent choice over assembler. if
lharc was 2 or 3 times faster i would alter this view. but 15% or
less is just not enough to warrant the added inflexibility of
assembler.
- lharc is not especially better at compressing files. i would
hardly call less than 0.5% difference significant. in fact since
you don't store bytes on disk, rather clusters, there may be
no savings at all on average.
- zoo archives appear to be larger because of the headers are
most likely larger for each file. if you examine the sizes of
the compressed files, you will note that lharc is 2 bytes smaller
than zoo, appearently independent of file size when lh5
compression is used.
- the size of the executables is significantly different. about 2x
(lharc being the smaller). however, after packing with pfxpak,
zoo is about 53k and lharc is about 28k. the difference is not
that significant in a 16 MB partition. what i do find fascinating
is that the executable for lharc is itself an archive! this is
a really super hack. incidently pfxpak was written by the very
same thomas questor who provides the lharc under scrutiny. (and
thomas, i DID disassemble it, tho the crash in test 3 wiped it
out since i had the source on the ramdisk. maybe you could mail
me the source now...:-). still, i generally dislike self extracting
archives though this is a twist on that concept.
- lharc's not getting the dates and times of extracted files correct
is unacceptable. PERIOD. if it can't get this correct, it is
of no use to me. i need the timestamps preserved because i use
tools which depend on the relative difference in timestamps
between files (e.g. make and RCS). if this is a case of RTFM,
then i will first say "yes, but..." and mention that getting the
timestamp right should be the default behavior.
- lharc cannot handle long lists of files. and when you do give it
such a list, it crashes the system. this is also nasty, unacceptable
behavior. in contrast, zoo can handle extended args and wildcards
with ease.
- the version of zoo sources i have can easily be ported to any
system with POSIX library and an ANSI C compiler. this includes
scores of systems from the PC and ST to supercomputers. lharc
cannot (even if i did have the source) since it is written in
assembler. note that all assemblers are different on the ST as
well so that it might take significant effort to compile it
with another assembler, even on the ST.
- tho cute and even helpful, the lharc "thermometer" that tracks
progress with *'s messes up redirected output:
lharc a lll file >log
it should be disabled if !isatty(1). zoo has no problem at all
with stdout redirection to files.
- nitpicking: zoo lists files one per line. it is easier to grep
things out for more specialized uses (like making lists of all
.c files with their statistics).
- there is one version of zoo 2.1 (that i know of) for ST, unix,
and PC. i stopped counting the versions of lharc for the ST
alone at about 6 or 8. there is only one author of zoo.
- zoo 2.1 can extract files from ANY zoo archive of equal or
lesser version. older versions of zoo can list any zoo archive
even if made with a newer version. if a newer version is needed
to extract files, the older zoo tells you what version you need.
zoo 2.1 will also (by default) make archives which older versions
of zoo will extract. you have to ask for the high compression
algorithm specifically with the "h" command modifier.
- i can take the zoo 2.1 archive up to a unix (or VMS) system and
extract the archive with no effort. i do not have to track down
a version which will extract it. the original version posted to
the net (source code) works fine. i have tried unlzhing an lh5
archive on unix with LHarc for unix v1.02 with no luck. it complains
that it cannot extract this method. in this case someone is going to
berate me saying "well, you should get this_and_such version and
quit moaning". i would (naturally) respond with "so how often do
i have to update lharc on unix to remain current? i already have
2 versions. how many more do i need? i only need one version of
zoo 2.1!". if it is any consolation, at least 1.02 does not core
dump when it finds this out (0.03 does, at least my port on a
convex does).
- neither program has a particularly consistent set of commandline
switches. after years of use, however, i am at least used to zoo.
and neither program as-is offers any particular advantage over
the other from the desktop from what i can see. i never use the
desktop so don't take my word for this. zoo does expand wildcards
in file lists. i did not test lharc, fearing another system
crash.
- comp.binaries.ibm.pc has used and continues to use zoo as its
primary archiver for posted programs. it also uses zip and
the occasional lharc file as well, however. now that zoo 2.1
is out, i see the use of lharc waning there. zip is still used.
i would compliment thomas on a fairly good program, at least a good
improvement over early lharcs on the ST. he has done significant work
to try and eliminate the inconsistencies between lharc versions. however,
i just don't see a huge advantage in using lharc now that zoo 2.1 is
available. and not getting the timestamp correct on extraction is very
bad indeed. is there a bug fix for this or am i missing somthing here?
and not handling long lists of files and crashing when presented with
such a list is beyond unacceptable. note that if he had used C instead
of assembler, especially GNU c, some of these problems would have been
taken care of by the library. as it stands, he has to do this himself.
consider this "user feedback" when you plan the next upgrade, thomas.
i confess that i did not read the docs for lharc. as far as i know the
questor version docs have always been in german up until 2.01e which i
just got within the past 2 weeks. but then again i did not read the docs
for zoo 2.1 either. the only change in zoo 2.1 has been the "h" modifier
for high compression and the "a//" addition for recursive directory searches
so there was no need to read anything. both of these new features were
mentioned in the README file. the rest functions as it always did. nothing
new to learn. i already knew how to use zoo since i have used it for at
least 2+ years.
i claim no authority in the use of lharc. i just ran it as i would zoo or
arc or lharc on unix (the version i have, at least) like the dumb user i
am. if these results can be bettered, please let me know how.
also, i know of some optimizations for zoo which may not have been applied
in the version i have (posted to comp.binaries.atari.st by steve grimm).
i know the unix version with larger i/o buffers is significantly faster
(at least 20% on a convex C210 with VME disks). if that is also true on
the ST, then the small speed advantage lharc has (only on compression, that
is) over zoo goes away. and zoo 2.1 may be even faster than lharc on
extraction in that case.
i note that the speed difference in both test cases is 11 seconds during
archive creation. it might be possible that this is a constant. if so, then
doubling the amount of work will lower the net speed advantage to under 10%.
also note that this version of zoo appeared within days of being posted
to alt.sources. i am sure it has not been tuned in the slightest. and i
hope it stays that way, so we don't end up with 50 versions of zoo.
it would also be nice to look at each program's i/o efficiency by controlled
tests in cluttered hard disk partitions or on virgin-formatted floppies.
i have not done that nor do i think it is worth the effort at this point.
also each program's handling of directory trees should be tested. zoo 2.1
(on the ST only!) now has an improved method for doing recursive hierarchies
(a//). the unix version still uses the "find . -print | zoo aI archive"
method as far as i know. this is not possible with the ST without CLIs that
support pipes. gulam (and the desktop) do not support pipes.
believe it or not i have tried to be impartial. and the benchmarking process
is not alien to me, tho i would not consider this a very thorough test. that
would require a better set of "calibrated" test files (these do exist). i
did not look at a set of files that were predominantly text, eventhough this
is one of my heaviest uses (source archives). however, the files i chose were
probably more indicative of the casual user's needs (programs with docs, and
other archives).
i try to look past speed and size alone. these are not highest on my
priority list for archivers, though they are important. i remember the
very early versions of lharc which took EXTREMELY long times to compress.
maybe 3-5 times longer than arc or zoo. this lharc is among the best, if
not the best version of lharc, but it is far from being the best archiver
overall, In My Humble Opinion....
comments??? rebuffs??? name calling???
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 26 Sep 91 05:06:48 GMT
From: noao!asuvax!cs.utexas.edu!usc!apple!netcomsv!seitz@arizona.edu (Matthew
Seitz)
Subject: ST Magazines (was More Lies From Atari?)
To: Info-Atari16@naucse.cse.nau.edu
In article <A2995525430@thelake.mn.org> steve@thelake.mn.org (Steve Yelvington)
writes:
>
>There's nothing wrong with the DTP software used to produce these
>magazines. The limiting factors are:
>
> -- The output devices. Typesetting a magazine on a 300dpi laser
> printer isn't going to yield professional-quality output
> regardless of the software used to place the text on the page.
> Some ST magazines (and ``fanzines'' is probably a good description)
> can't afford any better, sad to say.
Can't even afford to take the Postscript files down to the local printshop
for 600 dpi or 1200 dpi output before photocopying? I can't believe the
Atari magazines are hurting that badly.
--
Matthew Seitz
seitz@netcom.com
------------------------------
Date: 26 Sep 91 05:04:35 GMT
From: noao!asuvax!cs.utexas.edu!usc!apple!netcomsv!seitz@arizona.edu (Matthew
Seitz)
Subject: ST Magazines (was Re: More Lies From Atari?)
To: Info-Atari16@naucse.cse.nau.edu
In article <9469@cactus.org> covert@cactus.org (Richard Covert) writes:
>
>The rags you mentioned are the standard examples give by all
>Atari Apologists (AA) (TM by Covert)!! And while they are all
>good mags, they are NOT glossy nationally distributed mags which
>show up in the big bookstores. they are rags which you have to
>hunt to find. SO, novice Atarians wouldn't even know about them.
>
1) If they are "good mags", why do you call them "rags"? To me, "rag" implies
a poor magazine.
2) Personally, I'll take "good mags" over "glossy, nationally distributed mags"
any day of the week. As you point out later, many times the "glossy, nationally
distributed mags" are often little more than cheerleaders.
3) Well, if you were able to hunt enough to buy an Atari ST, I'd think finding
the magazines would be easy. Look on the shelves of the store where you bought
the computer.
Honestly, while I understand the desire for more widespread support for the ST,
I don't see it as a requirement. The ST works and works well, even if its not
advertised. There continues to be new, good software written for it, even if
its
not by big name companies. And there continue to be good magazines, even if
they aren't full color glossies, and you can't find them at Walden Books.
Yes, the ST is a hobby computer, with a small cult following by DOS standards.
But that's a far cry from saying the ST is dead or dying. How many people out
there have ever heard of UseNet? How many slick magazines cover RN? But no one
suggests UseNet is dying. In fact, I'd say its booming.
I think there's still room for the ST to continue to live alongside the big
two (DOS and Mac) and alongside it's cousin the Amiga. You may have to look
a little harder to find support, but it's there.
--
Matthew Seitz
seitz@netcom.com
------------------------------
Date: 22 Sep 91 06:34:46 GMT
From: mcsun!unido!mcshh!malihh!pfunk!blackbox@uunet.uu.net (Michael
Kistenmacher)
Subject: TeX, which do I get? (Now that I kno
To: Info-Atari16@naucse.cse.nau.edu
In <91262.123150ONM07@DMSWWU1A.BITNET>, ONM07@DMSWWU1A.BITNET writes:
>Hu? As far as I know, Lutz Birkhahn has just finished the new version (and
>the newest version of Metafont is 2.7x, isn't it?)
>
Yes, you're right. Sorry, but I got confused of the version-numbers. 2.9
was the release-number of the old Metafont 1.7. I don't know the new
version from Luth Birkhahn, so forgive me that I didn't mention.
Bye....Michael
--
/------------------------------------\
| Michael Kistenmacher / blackbox |
| 2000 Hamburg 61 / Schippelsweg 64 |
| West Germany / ++ 49 40 552 37 66 |
\------------------------------------/
------------------------------
Date: 27 Sep 91 13:22 UT
From: /PN=COLIN.W.HUNT/O=SPRINTINTL/ADMD=TMAILUK/C=GB/@sprint.com
Subject: Trip-A-Tron (Colourspace)
To: info-atari16@naucse.cse.nau.edu
Sometime ago someone posted a message asking for a copy of Trip-A-Tron,
the Light Synth for the ST by Jeff Minter. Well, I can't offer my copy
of Trip-A-Tron but thought that everyone may be interested in the news
that Jeff has made the ST version of Colourspace shareware, and it therefore
should soon be available on PD libraries everywhere.
There are also rumours that Trip-A-Tron _may_ be made PD, but I don't believe
this (but you never know!)
Colin
------------------------------
End of Info-Atari16 Digest
******************************
