Copy Link
Add to Bookmark
Report
Info-Atari16 Digest Vol. 91 Issue 515
Info-Atari16 Digest Sun, 29 Sep 91 Volume 91 : Issue 515
Today's Topics:
ARJ? K.I.S.S.!
Is Maple still available?
lharc 2.01e vs zoo 2.1: some tests (3 msgs)
Oh boy, more Atari bashing...
PEOPLE DUMPING THEIR MACHINE....
Sozobon > 1.2
WANTED: chart/broker program
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: 28 Sep 91 16:46:50 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: ARJ? K.I.S.S.!
To: Info-Atari16@naucse.cse.nau.edu
In article <3089@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>rosenkra@convex.com (William Rosenkranz) writes:
>True. The problem I have with the archiver situation in the TOS world,
>though, is that so darned many of them exist. TOS versions of Arc have
>long been surpassed in performance by more efficient compressors. Yet
>a lot of the archives I see on BBS's and elsewhere are still ARC format.
>I find LZH situation depressing. I personally have had little luck
>getting a single LZH tool that would deal with the variety of LZH
>formats out there.
i am glad to see a semi-official position on this, ken! i have added
respect for you (and your company :-). but then you _knew_ i would say
that :-).
like it or not, ARC is far more universal than anything else. EVERYONE
has a copy of it. it has been around forever, it seems. i know i used
it in 1985 and it probably goes back at least a dozen years. the "fortran
of archivers": no matter how you try, you just can't get away from it :-).
>This is why I was happy to see ZOO version 2.1 appear, with its high-
>performance option that beats or matches LZH compression. The main
>reason I like zoo is for its superior directory handling and "novice"
>command set.
exactly. the best of all worlds: easy for experts, easy for novices.
feature-rich. high performance. the best thing since...never mind :-).
>Having ARJ available will be even better. After using it under DOS, it
>became apparent to me that it merges all the best features of the
>different archivers I've used. Its compression is phenomenal (you want
>fast? ARJ does fast... you want tiny? you can get that too; slower,
>but not unreasonably so). It has a complete set of options for handling
>directories and for creating self-extracting archives, split-volume
>archives, etc. ad inf.
i, too, look forward to ARJ. i don't particulary love zoo, tho i definitly
like it more than lharc for the reasons u mentioned as well.
however, i forsee the same problem with ARJ as lharc: lot's of people
porting it, and worse, _changing_ file formats and compression schemes.
the only possible salvation would be for Atari Corp. to step up and either
do the port or sanction the port. this body here is far to democratic when
(in this case) totalitarianism is needed. i realize this poses significant
problems, however, not the least of which could be legalities.
i do have faith that in a race, if ARJ is POSIX compliant, anyone using
GNU C would win, and would _certainly_ beat a port to assembler :-).
>Because the compression beats the competition (and after all, that's
>the bottom line in archivers, no?), people will likely latch onto it.
no, it is NOT. it is portablility _and_ speed/size/etc, in that order.
i think we have a rare opportunity here: actually _plan_ the introduction
of a potentially widely used piece of publically available code. "think
of the colors...:-)".
>If, as an added bonus, it has a user-friendly face, more people will
>want to look at it. If it's the best archiver in terms of compression
>vs. speed tradeoffs, and flexibility in file handling, it'd sure be
>nice if it were also the best in terms of ease of use.
agreed.
>Also, while it's true that programs bloat a bit when GEM features are
>added, the rewards are worth the few extra K of disk space consumed.
agreed. i have no problem with GEM-izing anything as long as it is done
with care. that means it should NOT effect non-GEM use, its original
purpose in the first place.
>The extra effort can make a program useful to thousands more people. As
>an example, wiring a non-trivial GEM UI into MicroEMACS costs adds only
>about 20K of disk space to a 100K or so program. That 20% increase in
>size makes the program much, much easier to use (in my experience, and
>in the experience of EMACS users, both novice and pros, on whom I
>foisted the bug-ridden hack :).
not THIS emacs user. i rarely use the mouse in ME. i have no mouse at
work with gnuemacs. even when i did, i didn't use it. the trouble with
relying on special features is when they are not available, you can't
function. i tell this to people at work when the extole the virutes of
X terminals over my arcane vt100 clone. i casually mention a common
scenario: go to do some work at a customer site who does NOT have any
X terminals for you to use. double presure: customer watching+can't
use tools u know=much egg on face :-).
oh, and as bammi pointed out, i,too, may have made a significant error
in my code example that checks the number of args to decide which main
to use. if i said "if (argc < 1) do_gem()" i _really_ meant
"if (argc < 2) do_gem()". i would not suggest using my example anyway
since i can no longer claim expertise in GEM programming. it has been
years since i wrote GEM code, tho when i did, i wrote a LOT of it (a
60,000 line application for starters...). the idea, however, should be ok.
thanx for your comments, ken...
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 28 Sep 91 16:44:05 GMT
From:
noao!asuvax!cs.utexas.edu!samsung!noose.ecn.purdue.edu!vivaldi.ecn.purdue.edu!y
egerleh@arizona.edu (James D Yegerlehner)
Subject: Is Maple still available?
To: Info-Atari16@naucse.cse.nau.edu
Hello Everyone,
Once a long time ago someone in Canada posted that he had bought "Maple"
for his ST at a school bookstore. I have never seen this program
advertised for the ST; does anyone know if it is still available?
Is it a full GEM implementation?
As I understand it, Maple is a math program like Mathematica that does
symbolic and numeric manipulations (as against something like Mathcad
which is entirely numeric).
Any comments are welcome,
Jim
--
__ __ | |
\ / __ __ __ __ | __ |__ __ __ __ Jim Yegerlehner
\/ |--'| ||--'| ||--'| || ||--'| 1132 Hawkins Graduate House
| `-- `--|`-- | |`-- | || |`-- | W. Lafayette IN 47906
------------------------------
Date: 28 Sep 91 15:18:37 GMT
From: noao!asuvax!cs.utexas.edu!convex!rosenkra@arizona.edu (William Rosenkranz)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: Info-Atari16@naucse.cse.nau.edu
In article <VPDy91w164w@ersys.edmonton.ab.ca> mforget@ersys.edmonton.ab.ca
(Michel Forget) writes:
>I can't be positive about this, but I am fairly sure. Gulam uses the
>Mark Williams C Extended Argument Passing system, which is close to the
>system that ARGV uses. It *ISN'T* ARGV though, so that may be why Gulam
>crashes.
gulam _does_ use the MW scheme and it is close to the ARGV spec endorsed
by atari. however, the fact that zoo worked and lharc did not means that
the port of zoo was designed for use by the desktop and in shells like
gulam. lharc was appearently not tested before it was released the way i
did. you cannot disguise the fact that it DID crash my machine as
configured. and there were not TSR/DA problems (i only use AHDI, FOLDRXXX,
and a ramdisk and no DAs, not even control panel, and no funky hardware
setup).
zoo was compiled with GNU C 1.40 which has a nearly-POSIX compliant library.
the gnu library has been painstakingly worked on by a number of people
(bammi, dale schumaker, eric smith, etc), quite a collection of ST talent.
it has also been well tested in a number of environments, including gulam,
desktop, bash, MiNT, etc. it may not be 100% bug free, but then neither is
TOS itself. and it gets updated more often :-). part of the test was to
dispell the notion that to get decent performance you _must_ code in
assembler. this is just not true (in this case). the optimizer in gcc seems
to work pretty well. again a tribute to 1) the FSF (stallman et al),
2) bammi's port, 3) the C language itself. in fact, i'd say that using
any compiler that has a solid runtime library is infinitely preferable over
using one that does not and writing your own, no matter what the possible
difference in performance might be. in gcc's case, it just so happens you
get both: performance and portability.
> Okami supports ARGV Parameter Passing, if you can figure it
>out. I can't read German, so it hasn't been the easiest method to
>use...:)
i do not have okami, tho i hear it is quite good. i never said gulam was
the greatest thing, tho a) it has been around for a long time, b) it is
widely used by CLI types like myself. the fact that lharc does not work
and play well with gulam IMHO makes it problematic because of the number
of people it may effect. i can't read german any more either :-(.
from this point on, i defer all comments about ARGV to experts in this
matter. i am not. however, as i used the programs, within my particular
environment, lharc crashed. and i clearly identified "my environment".
the crash was totally unexpected as well. in fact, i lost some things
in my ramdisk as a result :-(.
if i have to, i _will_ read the complete ARGV spec, the docs regarding
env_style mw in gulam, and the source for crt0.c and main.c in GNU C
and _become_ an expert. however, this will still not make lharc work
correctly with gulam. and the timestamp issue has nothing to do with
gulam anyway. changing a file's timestamp is done with the GEMDOS
Fdatime() function. if i had the source to lharc, i could track this
down.
>Lharc 2.01E works fairly well.
it _does_ work _fairly_ well. just not as well as zoo IMHO. and i still have
not heard about its failure to get the dates correct on unpacking, no matter
how many times i read its manual.
>these problems. All in all, though, Thomas Quester's programs are some
>of the best available for the ST. Especially PFX Pack and AFX Pack.
no dispute here. i _really_like_ PFX and i will even register it if thomas
sends me the source so i don't have to disassemble it myself. i want the
source before i use it because i want source to _any_ archiving system i
might use. i figure it would take at _least_ an hour of time to disassemble
it (correctly) and annotate it. it would easily be worth the $10-20 (or
whatever) nominal registration fee.
>I'll check to see how well Lharc 2.01E supports ARGV, but if the author
>says it is supported it is a good bet that it is.
please do check and let us know. it might support ARGV, but it does not
support ARGV in a gulam environment. it should. zoo does.
>I also read the
>article containing the test, and it did seem very biased toward ZOO. The
>writer perhaps should have read the documentation before complaining
>about the program not being able to do certain things. The actual
ok, i admit it. when i started the test, i was biased by the fact that
lharc has had a bad reputation. but i _honestly_ did not know:
1) relative compression speeds
2) relative decompression speeds
3) relative archive sizes
4) bugs (tho i did suspect the timestamp problem)
and i would have posted the test results even if lharc had beat the pants
off of zoo. i truly did try and be objective by choosing unbiased tests,
i.e. the sorts of things i think many people use archivers to do. you can
either believe this or not. that is certainly your prerogative.
further, i reported what i found. if you find bits and pieces of the report
which indicate _extreme_ bias, it could just as easily be _your_ bias
as well. however, the numbers (times, sizes, timestamps) do not lie nor
did my dead ST after the "lharc a xxx *" test. the only possible bias
could be in how i actually _used_ the programs, and the specific tests
which i admitted (several times) where not exhaustive. i even complimented
TQ on providing the best lharc on the ST.
i could have easily wrote a report that said:
1) compression rates are similar, within 1%
2) archive creation time is similar, within %15
3) archive extraction time is nearly identical, though zoo
was faster in one isolated instance
4) lharc could not unpack files and keep the same timestamp
as the file in the archive
5) lharc crashed the computer (and describe the circumstances)
i provided additional commentary which i thought would be percieved as
reasonably fair by reasonable people. and i provided voluminous raw data
by which you could draw your own conclusions, if need be. and you are
certainly free to do your own (biased or unbiased) tests and report
the results. even a terse report could be percieved as biased. so make
up your own mind using your own tests. i even pointed out further tests
which i thought were needed. i just can't see how this is _very_biased_.
i could read until my eyes fall out of my head. it still won't stop the
problems i mentioned. nor will it run faster nor will it make smaller
archives. if the solution to the ARGV crash it to get another shell,
this is _unacceptable_. perhaps you could show me how to get around the
timestamp problem and the crash problem after reading the docs. i did
skim them (after the report) and found nothing to indicate a way to correct
the timestamp problem. i can probably work around the ARGV thing. but that
is again not the issue. the code has bugs. PERIOD. and if the source were
posted, we could help TQ find these bugs and fix them.
i checked the original copyright notice from yoshi (original author of
lharc). it explicitly states that if modifications to the source code
are made, they MUST be distributed. even if that modification is changing
C to assembler. if i wanted to be nasty, i'd say TQ has violated the terms
of Yoshi's copyright by NOT providing source.
>compression rates seemed fairly even, whih is a good thing. The next
>sries of compression programs will all be trying to beat each other, so
>we might see even better compression routines. There has to be a limit
>on how good compression can be though...
yes, the compression rates _are_ similar, as are the compression times
and decompression times. similar enough to abandon lharc in favor of
a more versatile, less buggy zoo...
thanx for your comments.
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 28 Sep 91 16:08:41 GMT
From:
noao!asuvax!cs.utexas.edu!sun-barr!cronkite.Central.Sun.COM!spdev!texsun!convex
!rosenkra@arizona.edu (William Rosenkranz)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: Info-Atari16@naucse.cse.nau.edu
In article <1991Sep28.132241.17704@actrix.gen.nz> Roger.Sheppard@actrix.gen.nz
(Roger Sheppard) writes:
>One thing you did not test with both Archivers was full i/o, did you
>not state that ZOO 2.1 has a problem with Disk i/o,?
>if this is the case then none of your tests are valid.
yes, i know this, and i mentioned this right up front. the problem with
disk-based io is that it can be extremely hard to duplicate a test
environment. i/o rates on nearly full partitions, especially highly
fragmented ones, can be greatly different than on empty partitions.
then there is also the issue of drive seek rates, interleaving, etc.
a "proper" test would take this into account and further report the
_EXACT_ configuration down to the size of sectors, fragmentation, etc.
unfortunately, people rarely go thru this much trouble. i tried to
side-step the issue by insuring at least an equal playing field. the
comparison should be unbiased for the use of these programs in ramdisks.
it does not, as you correctly point out, say anything about use on
floppies or harddisks.
however, i suspect that zoo (the GNU C version) would be rather efficient.
bill shroka (who did the zoo port) confirmed the change in buffer size
(which i also applied on my unix version) which significantly improved
its speed. also, the GNU C i/o routines in my experience are at least
as efficient as any other C compiler i have used on the ST (alcyon and
sozobon). i say "at least" since the gcc stdio is derived from dlibs
(i think) which is the prefered library for sozobon as well. bill further
explained that zoo was ported in about an hour. the buffer size change is
one line in one file. how long did it take TQ to port lharc from C to
assembler? i would suspect considerably more than an hour.
what i would suggest is that GNU C be tried on the ST on the original
lharc C (only) sources. i would even except lharc if this was done in
the first place way back when, before everyone and his brother got in
the "let's port lharc to the ST" game.
>I think that it would be far better if some one had done these test,
>that was not that biased, you new of the new features in zoo 2.1, but
>you did not bother to find out about any new features of LZH201X..
ok. i invite you to replicate this or perform your own. i really don't
think it matters who does the test. in fact, i'll even offer to do whatever
test you feel is necessary, within reason. you tell me the configuration,
environment, command switches, etc. you want. i can't guarantee i will
have the same hardware, however. the only restriction is that i use
my own choice of zoo, which i will document explicitly by sending you
the source, makefiles, even the frigging compiler!
_what_ new features? did i use lharc incorrectly? there are only so
many ways to pack an archive and i insured that lharc used it's highest
packing algorithm, lh5. this happens to be the default.
and still, i wish you would point out in the documentation where it
shows how to unpack files from an archive and preserve the timestamp.
i did not find it in my docs. nor did i find any mention of alternate
methods to improve speed or packing ratio. please direct my eyes to
the proper citation...
>As far as ZOO is concerned, I find that ZOO is used on only
>about 2-5% of the PD files that I get.
i, however, find it is more like 60-70%. all GNU-derived software on the
ST is packed with zoo. most comp.binaries.ibm.pc stuff is packed with zoo.
once again you are telling us that just because you don't need it, none
of the rest of need it either.
>Also I have never made a ZOO archive, I had so many problems with
>eXtracting ZOO archive that I don't use it as a archiver at all, there
>are too many switches to understand, unless you have a Computer Science
>Degree, so far from what I can see only used by Unix Freeks, they like
>wearing key boards out..:-)..
i did invite name calling, didn't i :-)...
i have not had any problems with zoo (except porting it to a cray-2 :-).
and "unix freeks" like being productive. that often means using our
fingers on keyboards.
for your information, there are about as many switches with lharc as with
zoo (if _you_ read the docs :-). zoo also has "novice" switches. here is
a summary of common ones:
zoo -add archive files... add individual files to new/old arch
zoo -backup archive directory recusive add
zoo -extract archive extract all files from archive
zoo -restore archive extract recursive
zoo -list archive list files in archive
zoo -test archive test files in archive
is this _that_ difficult to comprehend? in fact i suspect the only ones
you really need are -backup, -restore, -list, and -test for 99% of your
needs. i think with little effort, i could teach my 3 year old nephew
these few commands, if i could explain what an archive was to him :-).
and last time i checked, he was bright, but had no CS degree :-). neither
do i for that matter. the switches are _highly_ mnemonic. they are words
for crissakes. this only poses a problem if you don't grok english. in
that case you can resort to their equivalents:
zoo a archive files...
zoo a// archive directory
zoo x archive
zoo x//. archive
etc...
zoo has the added benefit of trying to extract files from damaged archives.
i know of no such capability with lharc, tho i am willing to learn of one.
-bill
rosenkra@convex.com
defender of the faith...
(by the way, "grok" is not a unix command :-)
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!rosenkra
Convex Computer Corp. |ARPA: rosenkra@convex.com
------------------------------
Date: 28 Sep 91 14:51:35 GMT
From:
noao!asuvax!cs.utexas.edu!wupost!zaphod.mps.ohio-state.edu!magnus.acs.ohio-stat
e.edu!usenet.ins.cwru.edu!ncoast!bjsjr@arizona.edu (Bill Shroka)
Subject: lharc 2.01e vs zoo 2.1: some tests
To: Info-Atari16@naucse.cse.nau.edu
In article <A0hm8lck@jonh.wimsey.bc.ca> jhenders@jonh.wimsey.bc.ca writes:
>In <1991Sep26.064525.15427@convex.com>, William Rosenkranz writes:
>>
> < extensive zoo vs lharc test deleted >
>
> Thanks for an excellant test article. The only real world test you
>missed was extraction of existing archives, where lharc is a considerable
>improvement over it's predecesors. I'm sure zoo rates highly there too.
> My one big gripe with zoo is that it breaks multiarc, a nice muli
>archiver shell I discovered shortly before zoo 2.1's release. With the old
>version of zoo, the command x// extracted all files recursively too
>folders, now the only command that does this is -extract, which doesn't
>fit on the multiacr command line. ( one problem with Gem dialogs is that
>the programmer must anticipate the maximum length of any command ever to
>be used. If he underestimates, something always comes along that is too
>long. Another good example is Gus, which truncates long subject lines.)
> Is my version of zoo broken, or is there a switch that I missed?
>
>--
> John Henders jhenders@jonh.wimsey.bc.ca
> Vancouver,B.C or ubc.cs!van-bc!jonh!jhenders
Zoo 2.1 defaults to extracting subdirectories. If you have an archive that
contains pathnames in the archive entries, then any of the following commands
will extract the full pathnames:
zoo x foo.zoo
zoo x// foo.zoo
zoo -extract foo.zoo
zoo -restore foo.zoo <- Atari ST version only
zoo e foo.zoo
zoo e// foo.zoo
If the version of Zoo you have doesn't follow these rules, then you must not
have the version that was posted to comp.[binaries/sources].atari.st.
--
--------------------------------------------------------------------------
Bill Shroka
bjsjr@NCoast.ORG
uunet!usenet.INS.CWRU.Edu!ncoast!bjsjr
------------------------------
Date: 29 SEP 91 10:06:10 CDT
From: Z4648252 <Z4648252%SFAUSTIN@RICEVM1.RICE.EDU>
Subject: Oh boy, more Atari bashing...
To: <INFO-ATARI16@naucse.cse.nau.edu>
Is there any possibility of an address being established so that
posters such as Richard E. Covert can go and rake Atari over the coals,
where these guys can scratch each other's backs as they siren the fact
how much better other systems are than Atari?
First, we had to put with the Amigoids coming here, telling us how
to 'upgrade' to an Amiga and now Mr. Covert comes in, bashing the Atari
laser (I always thought it was pretty fast, especially compared to the
lasers in the Mac world). And now the guy is telling how sorry the
Stacy was since it "never passed FCC Type C testing."
For starters, there is no such thing as Type C approval for computers
such as the Atari. Type A, and also Type B, but no Type C.
Please, Mr. Covert, go to the Mac area and praise the Mac world
there. Enjoy the amazingly expensive software and poor support by
Mac software companies.
Larry Rymal <Z4648252@SFAUSTIN.BITNET> |>Atari ST Users of East Texas<|
Stephen F. Austin State University, Nacogdoches, Texas
------------------------------
Date: Sun, 29 Sep 91 20:16:23 SST
From: "S. Suthipuntha" <AKISUJAR%NUSVM.BITNET@CUNYVM.CUNY.EDU>
Subject: PEOPLE DUMPING THEIR MACHINE....
To: INFO-ATARI16@naucse.cse.nau.edu
Hello from Singapore,
I normally prefer to read rather than writing a long message as it
has to travel half round the world but I could not resist this time.
In article <1991Sep27> Richard Covert writes:
>So, if I get a Mac iici for $4000 ($3300 for a IIci with 5 mgs RAM, 105mg
>hd) + $600 for color monitor/video board + $150 for keyboard I can use
>my Sony SMO optical drive with it for free. then I can put AUX on my
optical drive and run MAc off of my hard drive and off of the optical.
>And for less than a TT030 with ATX would cost. The TT030 ATX package
>.is going to cost $2,000 from what I hear.
Has anybody ever check how much Apple charge for A/UX? I bought a Mac
IICi since December '89 and then fitted with 5MB RAM and 105 Quantum
hard disk. I still keep and using my 16 MHz Atari Mega4/Spectre (Both
are on the same desk and Mac also sharing the Megafile 44 with
Mega4). I bought Mac IICi to run color program such as Renderman,
Strata Vision, Mac Architrion, which do not work on Spectre/Mega4.
However other B & W Mac programs such as MiniCad+, MGM Station run
as fast on my 16MHz Mega4 as when I run on Mac IICi in it 256 color
mode. (Of course in B&W mode Ci will be faster).
Although the total cost of my Mac IICi is still cheaper than the
cost of Mac Architrion(which cost US$6800 here) I sold my Mac IICi 2
weeks ago (at the same price I pay for under AUC) after discovered
how much I would have to spend if I going to buy Cache RAM card to
speed up the color display and/or A/UX (the cheapest disk version is
US$1320 here) and if I get the ethenet card big screen monitor+24-BIT
card and struggle with a single button mouse while running UNIX
(which needs 3 button mouse) on my Mac IICi.
The total added-on cost including the cost of Mac IICi will be more
than what I can buy a Silicon Graphics IRIS INDIGO which is a RISC
workstation running at 30MIPS, comes with cache RAM, Virtual 24-bit
graphics, 16" Sony Trinitron monitor, Ethernet, stereo sound build-
in plus free UNIX and Showcase programs in spite of Silicon Graphics
only give 30% educational discount comparing to 35% AUC prices here.
NeXT Station Color also cheaper than Mac IICi with A/UX and it has
16-BIT color, Ethernet come with 17" Color Monitor, 2.88MB disk
drive, UNIX and enough bundled softwares and using the 68040 CPU
which will be used in the new Mac Quadra which will be released on
October 21st.
I am now waiting to see the new Mac Quadra before making final
decision. I am very relieve to be able to get rid of my Mac IICi
before its price will come down drastically when Apple released 6
new computers next month. I also feel good to have an opportunity
to shop for a new computer again and enjoy using my Mega4/Spectre
more than ever.
What I would like to have are the Mac and Atari emulators for IRIS
or NeXT. Anyone keens to write the emulators for these 2 machine?
It would be nice if Dave Small will do it but I guess he is now
too busy with his SST.
Wonder why Atari never offer an educational discount though? It may
be too late now anyway.
Suthipuntha, School of Architecture, National University of Singapore
AKISUJAR@NUSVM.BITNET
------------------------------
Date: 28 Sep 91 16:51:34 GMT
From:
noao!asuvax!cs.utexas.edu!qt.cs.utexas.edu!zaphod.mps.ohio-state.edu!rpi!news-s
erver.csri.toronto.edu!bonnie.concordia.ca!daily-planet.concordia.ca!agostino@a
rizona.edu (Agostino Deligia)
Subject: Sozobon > 1.2
To: Info-Atari16@naucse.cse.nau.edu
Hi,
Anyone on the net know when the next version ( > 1.2 ) of Sozobon will
be released? Someone mentioned a couple of weeks ago that it was going to be
released in a couple of weeks :~) but nothing has shown up in
comp.binaries.atari.st or atari.archive.umich.edu.
Thanx for any info,
ad
--
Agostino Deligia
agostino@concour.cs.concordia.ca
It was the best of .sigs, it was the worst of .sigs...
------------------------------
Date: 28 Sep 91 18:50:38 GMT
From:
noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!think.com!snorkelwacker.mit.edu!ira.uka
.de!fauern!faui43.informatik.uni-erlangen.de!lsmichae@arizona.edu (Lars
Michael)
Subject: WANTED: chart/broker program
To: Info-Atari16@naucse.cse.nau.edu
Hi folks,
I need a program to visualize broker charts. Monochrome
would be the best. I've scanned the atari.archive, but
nothing found.
Anything is welcome,
---
Larry
+----------------------------------------+----------------------------------+
| lsmichae@faui43.uni-erlangen.de | | | | |
| Lars "Mr. GIF" Michael | | | | "Down with ATARI, |
| Graduate Student of Computer Science | / | \ Long live the ST !" |
| at University of Erlangen/Germany | / | \ |
+----------------------------------------+----------------------------------|
| Bones: "Damn it, Kirk, I'm a doctor, not a very good actor." |
+---------------------------------------------------------------------------+
------------------------------
End of Info-Atari16 Digest
******************************
